谈到基于模型的系统工程（MBSE），自然会考虑什么是模型？为什么需要模型？都有哪些模型？工作中如何按照研发工作的具体业务特点选择适用的模型？笔者在学习过程中思考这些问题，本文阐述了一些认识，近于读书笔记，请大家指点和讨论。目的是在实践中探索如何更好地把握应用模型的方式和范围，既有利于研发工作，又有效控制系统工程工作本身的成本，稳步推进系统工程的工程应用。 (一)语言的局限性 先尝试理解下面的话，看看会不会让您感到困惑: a1)等一会儿我叫他去。 a2)等一会儿我去喊他。 a3)等一会儿我让他去。 b1)理发的是我哥哥。 b2)给人理发的是我哥哥。 b3)请人给自己理发的人是我哥哥。 很容易发现，a1)和b1)都是有歧义的句子。这两个句子想要表达的意思还很简单，不过日常生活中人与人交流时说的话可不总是那么简单，情况远比句子的歧义现象复杂。比如在城市里问路，假如从A处到B处要经过十个路口，拐五道弯。试想一下不同的指路人会有多少种不同的描述?问路的人又会有多少种理解?仅靠问一次路就能找对路的可能性有多大? 可以说，使用语言表达和交流时非常容易产生畸变、噪声和衰减，这在日常生活中会给人带来麻烦，在工作中同样会带来风险。有个说法叫“沟通漏斗”(图1)，是指工作中团队沟通效率下降的一种现象：一个人心里本来的想法计作100%。当他用语言表达时，可能已经漏掉20%，准确说出来的想法只有80%。这80%中也许只有60％被人听清了。真正被别人理解的大概是40％。至于听的人遵照领悟的40％具体行动时，估计只有20％能落实。“沟通漏斗”现象说明了沟通中存在的风险。人应该对它有足够的认识，并尽量减少漏掉的内容。不过笔者觉得“沟通漏斗”的说法不十分准确，称为“沟通畸变、噪声和衰减”似乎更准确些(图2)。因为听的人不仅会漏(衰减)，还会曲解(畸变)，还会加进自己的认识，并且这个认识并非说话人的原意，是“噪声”。 图1 沟通漏斗 图2 沟通畸变、噪声和衰减 “沟通畸变、噪声和衰减”现象对产品研发有不可忽视的重要影响。在产品研发工作中，设计是非常重要的环节。设计是以提供产品或服务所做的想象以及对想象的描述。之所以说“对想象的描述”也属于设计的范畴，是因为目前设计和实现通常是分工合作的，而且设计活动本身通常也由多人完成。在很多情况下，设计师不仅要完成想象，还要对想象作充分的描述，让与其合作的人能准确理解，设计工作才算完成。如果未作充分的描述，团队就无法合作。越是复杂的目标系统，需要合作的人越多，合作的时间越长，“对想象的描述”越复杂，描述对设计的最终实现影响越大。 工程是要精准的。系统工程强调项目团队对项目相关事物的理解一致。研发团队在沟通方面如果有畸变、噪声和衰减，其后果可谓失之毫厘谬以千里。这样负面案例在工程中比比皆是。毫厘之差，后果可能是灾难性的。 (二)思维的局限性 人的思维是 “沟通畸变、噪声和衰减”现象的主要根源。思维的多样性是“沟通畸变、噪声和衰减”现象的内因，语言和理解的差异是思维差异的外在表现。 思维的多样性是柄双刃剑。它的好处是，人的思维有多样性才有了爱因斯坦、贝多芬、达芬奇、孔子、李白、祖冲之…这些人的思维是那么不同，而且异彩纷呈! 工程师要建造越来越复杂的系统，思维的多样性却给这个任务带来巨大的麻烦。人的个体思维就像奇形怪状的石头，一群人的群体思维就是一堆乱石(图3)。要用这些乱石砌个农家院的围墙是可以的，要建高楼大厦却不行。建高楼大厦只能用形状、尺寸规格统一的砖块，否则墙砌不了多高就会塌掉。 图3 思维的多样性 研发对象日益复杂。由于个体思维能力的局限性，个体思维越来越难以胜任研发任务，而只能依靠群体思维。 人的个体思维的多样性使群体思维能力不能自然地随群体中个体数量正比增长，其增长速度会持续趋缓，甚至进入负增长。如果不对群体思维作有效管理，规模庞大的群体思维将构成一个无序的、混乱的思维系统。 系统思维就是对思维的结构化、标准化封装和管理（图4）。封装后的个体思维更容易跟其他个体思维拼接，拼接后形成的群体思维系统比个体思维更强大，强大到能胜任复杂对象的研发任务。 图4 对思维的封装 (三)工程语言 既然自然语言容易造成沟通畸变、噪声和衰减，人们自然会想到在工程中改造自然语言，由此形成了“工程语言”。 事实上语言不仅用于沟通，它首先是用于思考。形成工程语言始于统一思维方式。 工程语言的基本原理是用结构化和可视化的语素定义个体思维及个体思维之间的接口，或者说是对多样性的思维作封装。就像把各种形状的货物装进外形规则的集装箱里，这就能叠到滚装船上，可以叠得很多很高。 封装后的个体思维更容易跟其他个体思维拼接，拼接后形成的群体思维比个体思维更强大，强大到能应付复杂系统设计任务。如果不这样，规模庞大的群体思维将构成一个无序的、混乱的思维系统，这样的思维系统(主体系统)设计出的客体系统必然是扭曲的，甚至会不可用，客体系统的规模大到一定程度时必然会由于主体思维系统的混乱而坍塌。 图5 “封装”的典型案例 (四)模型的概念 模型其实就是封装思维的箱子，其实也是封装语言的箱子。事实上对模型这个重要的概念却有不同的理解。 (美国)国防部体系结构框架(DoDAF)对模型的定义是“模型作为一种模板，以易于理解的格式来组织和显示数据”。并进一步定义“当以此方式来收集和呈现数据的时候，其结果就称为“视图”。按照这个定义，可以将视图理解为数据实体或实例。 综合定义方法(IDEF)对模型的定义是“不管以何种形式，只要M能回答有关实际对象A的所要研究的问题，就可以说M是A的模型”。这个定义揭示了模型的本质，尤其是打破了时常见到的对模型的狭隘的理解，从这一点看这个定义非常经典。IDEF对模型的定义可以理解为等同于DoDAF所说的“视图”。 正如以上两种对模型的阐述，作为模板的“模型“与作为数据实体的“模型”非常容易混淆。为讨论方便，本文采纳DoDAF对模型和视图的定义。 (五)模型的类别 事物是包罗万象的，没办法用一种模型描述所有事物，只能用多种模型分别描述不同类别的事物和事物的不同方面。既然模型用于组织和显示数据，那么模型的类别就应该取决于描述事物之数据的类别。 1）按描述事物的维度划分模型的类别 对事物可以从概念、结构、行为和关系四个方面开展描述。概念、结构、行为和关系也可以称为描述事物的四个数据维度。 概念包括（但不限于）以下类型：
结构用于描述事物的静态特征，结构模型也可以称为静态模型。例如：
行为用于描述事物的行为特征或动态特征，行为模型也可以称为动态模型。例如：
关系用于描述事物之间的联系。事物之间存在广泛的联系，这正是系统复杂性的体现，也是涌现现象的基础。关系包括：
关系的类别包括关联关系、依赖关系、泛化关系、实现关系等。 2）按照可视化形式划分模型的类别 按模型的可视化形式可分为文本、图、音像、表、数学描述等。 说到这里可能会有分歧，“基于模型”就是要用模型思考、分析、描述和传递问题，这里怎么会提到“文本”?难道文本也算模型吗？ 笔者认为模型并不排斥文本。正如IDEF的阐述“不管以何种形式，只要M能回答有关实际对象A的所要研究的问题，就可以说M是A的模型”。事实上概念模型经常用文本描述，有时甚至是唯一可行的、适用的描述形式。模型的关键不在于形式，而是要有完整、准确的、易于理解的描述，并对模型作适当的管理，使项目团队对其有一致的理解。 3）按照载体划分模型的类别 可以按照模型的载体划分模型的类别，如:
4)按视角划分模型类别 DoDAF按照8个视角定义了52个模型。这8个视角是利益攸关者视角，包括全视角、能力视角、作战(业务)视角、系统视角、服务视角、数据和信息视角、标准视角、项目视角。这52个模型是对问题空间和解决方案空间的完整划分。 说明:上述对模型的分类仅是笔者的粗糙理解，未必合理。比如另一种分类可能是物理模型和抽象模型，抽象模型再分为形式化模型(几何模型、逻辑模型等)和非形式化模型(图片、文本等)。本文对模型的分类仅是为了帮助阐述对本文主题的认识。 (六)模型的使用 不同专业领域（可能对应着研发单位不同的部门）的业务特点不同，所研究的对象不同，适用的模型也不同。如总体设计部门侧重关注概念和关系，结构设计部门侧重关注结构和关系，电子系统设计部门侧重关注行为和关系。 一个单位不同专业领域的人在一起讨论MBSE时，大家对模型的认识可能彼此对不上茬，进而导致对MBSE产生不同的认识，甚至差别很大。尤其是当大家并没有意识到存在差别时，会对工作产生非常不利的影响。究其原因可能就是不理解对方的业务特点，不理解对方的业务适用的模型。事实上模型作为工程语言，在使用中通常追求这几个目标:明确、完整、可追溯、一致。只要达到了目标即可，没必要拘泥于模型的形式。 明确。对事物的描述准确、易懂、无歧义。例如使用图形描述事物时往往比自然语言更明确。 完整。首要的是对问题空间中的问题和解决方案空间中的问题有完整的描述。描述不完整就无法把握全局，就会忽视必要的事项，增加风险。例如DoDAF的能力视角(CV)和作战(业务)视角(OV)主要用于描述问题空间，系统视角(SV)用于描述解决方案空间。 可追溯。关注生命周期基线以及事物之间的相关性。如DoDAF中的SV-5a“作战活动到系统功能映射矩阵”就是用于描述关联关系的模型。可追溯使项目和系统成为整体。 一致。至少确保项目团队内对同一个概念有一致的理解。如DoDAF中的AV-2“综合词典”模型就是为了保证一致性。 在接触了系统工程知识后，了解了“基于模型”，知道了UML和SysML，或许还有DOORS、Rhapsody等等。但是SysML、Rhapsody不能代表模型的全部，也不能认为不用SysML、Rhapsody就不是“基于模型”，更不能认为非数字模型就不是“基于模型”。究竟需要使用什么模型，要根据本人、本部门或本单位的业务特点考虑模型的适用性和有效性。比如在结构设计中常用的CATIA、UG、SolidWorks等也是基于模型;以结构化文本描述的综合词典也是基于模型，而且是极其重要的模型。用结构化的元文件描述问题，也许是复杂系统顶层设计工作中易操作且有效的“基于模型”的方式。 说明:笔者在另一篇文章《系统工程的玻璃笼子》里对元文件、集成文件、主体系统和客体系统等概念有详细说明，见“翼知堂”公众号或“系统工程”公众号。 虽然说可以按需选用模型，但也不是随意选用，而是应该遵循一些基本规律。 首先是按照从问题空间到解决方案空间、从整体到局部的顺序。问题空间中最关键的问题是项目目的和高级作战（业务）概念。项目所面临的根本技术矛盾(如能力与资源需求之间的矛盾，技术优势与经济性之间的矛盾等)以及在解决矛盾时的权衡原则，将要构造的产品的竞争优势，这些关键问题必须通过高级作战概念模型作充分描述。 二是必须建立综合词典，确保项目团队对术语有一致的理解。 如果准备以循序渐进的方式推进系统工程，早期要规划系统工程工作的最小范围，那么对项目主要矛盾(高级作战概念模型OV-1)和综合词典(AV-2)作全生命周期的有效管理，这两项工作也许是不能再小的最小范围了。 三是建立合适的模型架构并作统一管理，尽量作到对视图一处定义、多处使用。避免无版本控制地随意使用拷贝。 (七)总结 对“基于模型的系统工程”之“模型”，需要有全面、准确的理解。 MBSE是利用共用模型描述问题并管理研发数据的系统工程方法。所说的“共用模型”是指在项目团队中对模型有共同的理解，理想情况是跨团队甚至跨专业领域也能对模型有共同的理解。 在工程实践中，需要按照自身的业务特点选择使用适用的模型。即使是同一个单位的不同部门，也应该自行选择取舍，而不是必须套用同一套模型。在选择模型时，应该始终将有效性放到首要考虑的因素，模型要能有效解决企业运行和项目运行中的矛盾。不能头痛医脚，不能画蛇添足，不能象武术套路表演选择套路般地选择模型，而是重视实战效果。
(如果想与笔者联系，请在此文后留言)。 声明：本文内容如涉及版权问题烦请告知，文中刊载信息仅供参考。 |
|
|
