研究 | 基于模型的系统工程:革命还是改良?

2017-09-18 11:51 来源:系统工程方法
浏览量: 收藏:0 分享

引言

  在系统工程模型出现之前很早,著名的现代哲学家路德维希·维特根斯坦[1],就曾经富于远见地指出:人类的语言和现实的图像紧密关联,这些现实的图像描绘出各种各样的“事物的状态”。

  这个看法有意模糊了系统的文本描述和基于模型的描述之间的区别。文本和模型都是语言。事实上,大多数的模型包含文本,而文本文档也经常由某种绘图和图示来补充[2]。工程师使用绘图和模型已经好几百年了,而且已经由简单的概要图发展到精确标出尺寸的绘图,以及计算机自动生成的机械设计和物理特征的模型。那么,基于模型的系统工程到底有什么新奇之处?为什么它被看作一个革命性的概念?

  一、基于模型的系统工程:一个哲学基本构造的转换

  基于模型的系统工程的中心,存在着一个思维转换的问题:即系统的“真理的唯一来源”究竟在哪里。传统方法中,文档被用作权威的信息源,文档包括要求、约束、架构、设计、技术权衡、决策及系统的其它信息。一般而言,要写出一系列的文档,并冠以系统要求文档、分系统规范、系统设计文档等名称,每一个文档都有一个批准的过程,以确保良好的沟通和各方的一致同意。

  当然,这些文档可能包括图示、图表、公式和其它的非文本信息,但是重要的是它们是信息的固定组合,而且某种程度上是“死的”,也就是说,它们与文档内及文档外其他的元素没有任何“活的”关系。在某一个文档内更改某个东西,相对应的改动或作为结果的改动[3],必须在其它文档内手动地更改。因此,对于系统设计相关的文档,很容易变得版本过时、支离破碎甚至自相矛盾[4]。

  基于模型的系统工程的一个重要原则是:模型比文档更好。因为文档经常被要求交付给别人,因此在未来可预见的时间内,文档不会从系统工程工作中剔除出去,但是我们更加期望看到文档从各种各样的模型中被自动地生产出来[5]。把工作的着重点从文档转换到模型,有若干个优势:信息可以在一个大型的项目中被更好地共享和沟通,更改更容易被接纳和适应,而且综合的追溯性可以自动进行。接下来我们详细地来认识这些优势:

  (一)通过协作来建立更好的共识

  系统开发项目的成功,非常依赖于团队成员对系统的高质量的共同理解。尽管并不是每一个人都需要了解系统的每个方面,但是一个不断增长的关键信息的主体,应该成为整个团队的共同知识。比较典型的信息包括:对系统的主要要求、系统的商务和任务环境、使用场景、与外部系统和人的关键接口、主要的架构概念和重要的技术性能度量。小的工程团队,例如企业主的小项目,能够进行地非常有效,是因为在这样的组织内,这种沟通、协作和共同理解能够自然地、自动地进行。在大的项目中,这些必须由详细的谋划来推动。

  当一个项目团队中缺乏共同的理解,会发生什么问题?结果可能是损失惨重、成为头条新闻的系统失败(令人震惊的质量事故),进一步追查,这种失败可能是因为很常见的度量单位的误解[6]。即便没有系统失败,也可能是研制工作的无效率。最近的研究和以往的事实都表明,工程师要花费很大一部分时间来搜寻和汇集现行有效的信息,以便完成他们的工作。创造一个协作的环境,在其中现行有效的信息一直是最新的,而且可以像看到“真理的唯一来源”一样来访问,如果这样的话,模型就能够显著地提升研制工作的有效性。

  若干种原动力使得开发这样一个协作的信息环境,显得比以往更加地必要。系统复杂性的非常明显的增长、由更加复杂的软件来实现系统的功能、系统的系统之间更多的相互联结等,意味着有超过以往任何时候的信息需要管理。有着成百上千条要求的系统,不可能被一个工程师装在脑子里,在仅用要求清单的情况下,也不可能被有效地管理起来。模型可以用更加复杂精密的、相互关联的方式来表示这些信息,并且使这些信息在需要时以更加定制化的方式、以用户的视角来得以应用。

  (二)乐观对待更改

  大多数现有的系统工程过程和方法,尤其是那些基于文档的方法,都无意识地、乐观地看作“没有变化的”。也就是说,它们在事情都不变化时工作地非常好。这意味着一个虚构的世界:所有的要求可以在项目的早期就确定好,并且被锁定,在后来的时间内没有机会发生改变。以同样的方式,基于这些要求的衍生要求、架构和设计,可以被创造出来,并且被保护起来以防止将来的任何变化。这样一个瀑布过程是极端乐观化的。变化不仅是不可避免的,而且是有利的。随着团队通过学习、试验、原型和仿真掌握了更多的知识,更改(甚至是对部分最根本的要求的更改)可能导致一个更好的系统。不幸的是,传统的过程拒绝更改,因为更改是破坏性的,而且要导致大范围的重复工作[7]。

  我们需要的是一个处理的过程、方法和工具,如此以来,更改可以变得像是寿命周期中自然而然的、期望的,甚至是渴望的东西一样被接纳。有很多方面的因素可以帮助实现这一目标,模型是其中重要的一个。一个设计良好的模型,可以轻松地接纳更改,因此对一个元素的更改,可以自动地触发对其它相关元素的必要的更改。模型可以包括数学关系、仿真场景和栩栩如生的模型执行,使得更改的效果很快地呈现出来,并被纳入到设计中。可以使用模型而不是重复地手动分析,来执行各种假设分析和权衡研究。在做出每一个更改并被批准时,表示“真理的单一来源”的模型保持着最新,同时也不需要对相关文档进行大范围的、手动的、重复的修改工作。

  (三)投资未来

  在项目早期投资于高质量的系统工程工作,目的是保证项目在后来不会遇到更大的问题。基于模型的系统工程也认识到、甚至更加重视这一原则。埃里克·霍纳最近的一些优秀的研究表明,追求高质量系统工程工作的投资,和最终的项目的成本和进度绩效之间,存在着非常显著的相关性。可重用的模型,当它被用在产品线和衍生产品中时,可以在以后多次产生回报。在传统方式下,要求和其它模型元素之间的追溯性,以一种单向的、死胡同式的方式来执行,以满足可交付的要求;而在基于模型的模式下,这些追溯性能够变成一组“活”的链接,对要求被满足的程度、影响和依赖关系给出洞察力,借此在项目的整个过程中提供价值。埃里克·霍纳的研究结论是,对系统工程工作的投资占项目总投资的15%,可以得到最好的成本和进度性能绩效。

  二、模型的本质

  模型到底是什么?所有的图示是模型吗?在基于模型的系统工程语境下,模型是什么?先不去寻找一个严格的定义,考虑模型的特征,并且举例说明我们用模型要表示什么。一个简单的例子,考虑使用电子制表软件。我们在单元格中直接写下数字公式,例如在单元格中输入“=100+3*50+2*3*70+3*3*40+4*3*100+5*3*125” ,用它来计算答案。这当然可以计算出结果来,但这样有不足之处,主要是不够灵活、受限于单一的目的。如果一个电子表格中充满了这样的公式,就会要求数量巨大的手动工作,来接纳对于数值的任何变化或数值之间关系的任何变化。隐含在公式后边的基本原理和数值之间的关系(例如,这个100与那个100是相同的吗?),被锁定在设计者的思维中,对于使用者并不是容易看见的[8]。

  可以用更加聪明的方式来使用电子表格。单元格保持公式所示的关系“=-A11*4*(1-B11)+4*C11”,而且象”=NORMDIST(A11,0,1,FALSE)”这样的函数,允许使用者以更加灵活的方式来使用单元格,因为关系被永久地嵌入进去,数值以可感知的方式和明确说明的方式被相互捆在一起。改变一个值和每一件事,依赖于值的立即更改。可以按照你的需要,试验不同的值,或增加新的关系。

  这些道理在电子表格中非常的明显,但是考虑系统工程工作产品会怎么样?在确切值、硬编码、不灵活的方式或更加基于模型的关系和公式方法等中间,系统要求和哪个更类似?与权衡研究、要求分配、设计、架构、部件规范或技术性能度量等相比,系统要求和哪个更类似?一个基于模型的系统工程方法,应该使得这些工作产品用一个相互关联的、互相作用的、直观方式来表示,用一个为该目的而设计的语言来表示。这样的话,一个对要求和性能度量的更改,将会扩散到所有的、贯穿整个系统描述的相关的项目,助推效果分析和合适的调整[9]。

  三、我们能够从模型中期望什么?

  最好在最广阔的意义下思考模型,包括在系统的系统这一层次的高层次的模型、交叉学科的系统工程模型和特定学科如电子、机械和软件的模型。模型,尤其是基于模型的系统工程中的各种各样的模型,服务于多个目的。它们在不同的详略程度上捕捉系统的结构和行为,对于不同的观察者提供合适的视图,这些视图隐藏或展示的细节对于观察者是合适的。它们提升沟通的准确性,因为它们用图形展示架构和设计的重要方面,而不是仅仅简单地叙述。它们也使得错综复杂的权衡研究分析更加地便利,而这些工作在传统模式下可能是非常地困难,甚至不可能完成。

  采用了基于模型方法的组织机构的关键看法之一是,模型可以依据多个目的被创造,而且对于模型创造者的目的更清楚,因为为单一目的创造出的模型,可能并不适合其它的目的。一般来讲,模型可以依据以下目的被创造:

  (一)文档记录

  模型可以被创造出来以记录现有的信息,诸如一组要求、设计、过程和架构等。实际上,一个工程师或团队做出一个决定或设计,随后就创造一个模型来记录它。这中间没有什么问题,但是应该清楚,模型被创造出来,是要记录来自其它地方的一些事情。

  (二)图形展示

  模型可以展示在文本其它地方描述的东西,以提高沟通的效率、提高共识及意见统一的水平。仅用来记录和图形展示的模型,并不能传递基于模型的系统工程所声称的好处,主要是因为它们所展示的,已经在模型创造出来之前就被开发出来并被决定了。它就像在建筑物已经建好之后,画出一个建筑物的设计图,或者至少是在重要的决策做出之后画出设计图。一个基于模型的系统工程方法,将意味着在做出重大决策前,就参与到其中进行建模。

  (三)计算

  模型可以被设计出来以计算简单的值,例如从飞行器的部件计算出整体的质量,或复杂的数据剖面,例如发动机散热或电磁信号传播。

  (四)评价

  通过建立可以更改输入值的模型,模型可以表示各种备选方案,设计可以被比较和评价。当架构被基于元素建造出来之后,这些元素是通过智能的、动态的关系关联起来的,权衡研究还可以作为设计过程的一部分很快地进行,而不是依赖于一次性的分析[10]。

  (五)建造

  一些模型在某个细节层次上被建造出来,足够保有所有的设计内容,因此,可以直接地转换成实际存在的东西。计算机辅助设计/计算机辅助制造的模型,能够控制机器人——这些机器人可以执行制造工作,和软件模型——这些软件模型可以产生软件代码。通常地,系统工程模型在更高的层次,但是在可以预见的未来,可以有更高层次的模型能够通过一系列的转换自动地生成系统。在工厂的一端输入一个模型,在另一端就能够产出一个小轿车、飞机或卫星[11]。

  (六)保有思想

  在设计被创造出来并被精炼、推敲、优化的过程中,模型可以被工程师和架构设计师当作一种共享的思维空间。我们来看一组协作的工程师是如何工作的:他们被召集到白板或活动挂图前,画一张画,轮流地对设计进行批评或在别人工作的基础上进行设计,直至达成设计上的共识。这些模型的优点是:它们是一个共享的工作产出,是共同协作所创造出来的,但是这些模型也通常有特别的缺点:以不特定的建模语言表示出来,要求原始的作者来解释其含义。把这些同样的工作方式转换到一个在线的能力中,使用一个语义丰富的、可执行的建模语言,你可以在工程协作中获得一个有力的工具——即不仅可以工作在一个房间,而且可以扩大工作地域到一个公司甚至不同的国家[12]。

  四、模型关系

  建模语言(如系统建模语言)的一个重要特征是,能够在模型元素之间表示丰富的语义关系。一个模型可以表示一个分系统如何依赖于另一个,一个部件如何成为分系统的一部分,或者一个要求是怎么从另一个要求中推导出来的。在基于模型的系统工程方法中,我们也可以考虑作为一个整体的众多模型之间的关系。一个数学模型,可以从一个更高层次的系统模型中衍生出来。一组机械方面的计算机辅助设计/计算机辅助制造的模型,可以是更高层次架构模型的实现和实施。一个面向对象的软件模型,可以依赖于逻辑架构模型和另一个分系统。从根本上说,多种类型的关系,存在于模型的元素之间和众多模型之间[13]。

  我们可能把这个当作“模型的模型”来考虑,如同系统工程师所讲的“系统的系统”。这样一个模型的模型,将把各种各样的模型互相联结、联系起来。这样的模型集合,不可能被保存在一个单一的建模工具中,也不会用单一的建模语言来建模。需要的是一个方式:通过建立不同模型中元素之间的链接,把离散的模型链接成一个概念上的整体。在这种方式下,来自系统工程的模型,可以被集成到其它的来自设计、开发和制造等系统开发组织的模型。

  五、采用建模方法的危险

  随着技术的进步,容易出现一个危险的“银弹”想法,即宣称发现了一个能够包治百病、能够应对所有已知挑战的新概念。这将带来模型的快速增长的危险。当建模成为主导工作,模型在整个组织内被狂热地开发出来,有些时候没有好的协调和规划。如此以来,模型就出现了和文档一样的问题——臃肿冗长、相互矛盾和陈旧过时。有一个神话说“所有的模型都是好的”,这样所有的模型创造出来后就应该被保留、维持。随便地创造出来的文档并不是项目所需要的真正的文档,也不该在没有意义和目的的情况下建模。建模方法带来它们自己的危险,盲目地投入到任意一个建模方法中,可以创造出某些模型,但并没有给项目增加必要的价值[14]。

  然而,另一个危险,或者至少是限制,就是模型仅仅作为文档来记录某些东西。当用其它的形式来完成真实的工程或设计工作,例如文本文档,特别是绘图甚至是谈话和人的记忆,并且模型可以依据这些信息被创造出来,那么“模型仅仅作为文档来记录某些东西”这种危险就发生了。当这些模型可以和明确的文档一样有用,它们会一直滞后于创造性的工程工作,因此,不会产生基于模型的方法所承诺的好处[15]。

  [1]译者注:此人曾提出“语言图像论”和“语言游戏说”,对语言与哲学之间的关系进行了深入的研究。

  [2]译者注:工程设计文档通常都包括各种各样的结构图、流程图等。

  [3]译者注:在系统研制的整个过程中,系统的文档不仅种类多,而且一直在变化过程中,也就是人们对系统的认识有一个由浅入深、由粗到细的持续的过程,所以文档一直在更改过程中。

  [4]译者注:我们说,系统是复杂的,是牵一发而动全身的,那么,描述系统的文档,也是复杂的,是牵一发而动全身的,如何在由很多人所进行的无数次的、各种各样的修改中,确保文档整体上的一致性、改变的同步性、连贯性等,是一个大难题,还不仅仅是技术状态管理所要解决的问题,更与需求跟踪、团队协作等密切相关。

  [5]译者注:由模型自动地生成文档,是MBSE下一步需要研究和解决的问题。

  [6]译者注:这种案例在国内外型号研制实践中较为常见。

  [7]译者注:需求蠕变(Requirement Creep)是系统工程的难题之一。

  [8]译者注:如同编程,一行代码包含了长长的公式和多个计算步骤,虽然运算的效率高,但其它的开发者、维护者并不容易看懂其含义,也不容易进行改动和维护。实际上这个计算式并没有对现实进行很好地反映,不是一个好的模型,也不是一个好的程序。

  [9]译者注:Excel表格是一个很好的例子。单元格对应一个可变化的值,旁边可以有单元格的说明及输入的限制。若干个单元格就可以表示系统的一个元素。为分层次,可以有不同的sheet,不同的Excel文件,不同的Excel文件包,就可以表示出一个很复杂的系统的各种参数及特征,并且实现自动地关联。

  [10]译者注:模型可以用来进行权衡研究和各种各样的评价

  [11]译者注:本段主要是说工艺模型。工艺模型来源于设计模型,工艺模型可以输入到数控机床和工业机器人中

  [12]译者注:本段主要谈协作方式,由线下到线上,由随意的建模语言到标准的、统一的建模语言

  [13]译者注:框图表示实际系统的零部件,框图中的参数、描述刻画了零部件的性质,因此,实际系统中的零部件之间的关系,可以完全地用框图之间的关系展示出来。框图有一定的格式,相当于一套语法规则,再加上框图中的文本和参数,就有了语义,放在一起就有了特定的含义。框图内的文本、参数,框图间的关系,都被电子化了,就可以借助计算机进行计算。

  [14]译者注:模型不能太多,不能犯和文本文档一样的毛病

  [15]译者注:不能由文档来导出模型,而应该由模型来生成文档,否则就不能发挥系统建模语言的好处。参考:Document the Model, Don’t Model the Document 2012

标签:

投稿人:zhangxiuqin
在线客服