引言
在系统工程模型出现之前很早，著名的现代哲学家路德维希·维特根斯坦[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
联系我们请点击：
数邦客
