| 编辑推荐: |
本文从泰雷兹集团的产品转型驱动其研发模式的转型开始，详细叙述了泰雷兹探索MBSE的发展历程：从基于UML开展基于模型的方法初次尝试，总结失败吸取教训，最终形成了符合工程师思维，贴合工程实践的MBSE方法：Arcadia。
本文来自于微信iMBSE Online，由火龙果软件Linda译、推荐。 |
|
1 Arcadia方介绍法总体
Arcadia是泰雷兹集团探索MBSE多年后的工业结晶，它是一种经过多个工业部门实践检验的、符合系统工程师思维的MBSE方法论。Arcadia在泰雷兹集团内部有着广泛应用，从航空电子、轨道系统、防务系统、卫星系统、地面站到通信系统等都采用该方法开展系统工程的实践。目前Arcadia方法已趋于成熟，在欧盟及国际大型企业有着广泛的应用，采用Arcadia方法的企业已经超过200家，这其中包括研制运载火箭的阿丽亚娜集团，研制航空发动机的Rolls
Royce公司，法国核电巨头法马通等。该方法论贴合工程，工业部门应用范围广，这也是西门子选择Arcadia方法作为实践MBSE的原因之一。
▲图-1 采用Arcadia实践系统工程的部分企业
2 泰雷兹MBSE发展历程
接下来我们讲述泰雷兹集团探索MBSE的心路历程，主要分为以下几个阶段：
1. 2000s产品转型：由部件级供应商转型为系统级供应商
早在2000s左右，泰雷兹在市场和产品上面临一次巨大转型，从供应分散的零部件再被第三方集成交付给客户，转型为提供“交钥匙”的整体解决方案和综合系统，如空中交通控制系统，防务任务系统，卫星系统，和通讯基础设施和网络系统等。这种产品的转型带来了工程模式的变化，由之前关注于技术性能需求为主，转变为重点关注交付客户所需的运行能力需求；由之前关注于各领域的局部最优转变为全局解决方案最优，综合考虑机械特性、产品性能、算法处理、电气设计、以及运行环境、产品政策、安全可靠性、人因对交付的系统产品的影响。这就是泰雷兹采用系统工程方法的最初原因-解决综合的系统设计问题。
2. 2001-2006年：基于模型的方法初体验
2001年前后，泰雷兹基于UML语言、RUP建模流程开始基于模型的方法探索，以取代基于文档的方式，本阶段的成果物之一是MDSysE（Model-Driven
System Engineering）软件，基于该软件开展架构设计和分析。
▲图-2 泰雷兹最初的基于模型的方法：MDSysE
尽管该方法能够涵盖大部分系统工程流程活动，也能指导系统工程师进行系统思考，但是无法支持功能分析。而且UML对于不是建模专家的系统工程师来说，太复杂了，对工程系统层级的属性和特性表达的支持也不够充分。
3. 2006年-2011年：Arcadia方法的产生
2006年后，泰雷兹对涉及的所有工程人员进行充分的调研，包括运行分析师、需求经理、架构师、软件/硬件开发人员、安全可靠性专家、维护后勤专家以及装配集成人员等。总结出共性问题如下：对客户的需求进行分析，以便准确、更清晰地理解客户的期望、目标和能力，以及解决方案如何满足这些期望；增强架构定义的质量，以及架构师与各领域专家的协同；设计早期能识别出架构定义和设计的缺陷，而不是在后期的集成阶段。
▲图-3 图形化DSML语言VS SysML语言
泰雷兹发现无论是之前基于UML的MDSysE软件，还是基于UML扩展的SysML语言都满足不了他们对基于模型的方式实施系统工程的需求。最终泰雷兹决定开发属于自己的MBSE方法论和系统建模语言，这样就诞生了Arcadia方法和图形化DSML语言。
图形化DSML语言主要借鉴了75%的UML/SysML，5%的NAF，以及AADL架构描述语言和APTE：外部功能分析方法等，增强了系统工程师进行功能分析的能力，对系统工程师不太熟悉的面向对象概念进行了封装，以简化系统建模难度。图形化DSML语言完全融入到Arcadia方法中，这样系统工程师在掌握MBSE方法流程的同时掌握了图形化DSML语言，不用再单独学习系统建模语言SysML了。
在摸索MBSE方法时，其实泰雷兹也走过弯路，如刚开始的时候Arcadia方法比较死板，严格按照自顶向下（top-down）、每步活动都有严格的操作顺序，必须严格按照所规定的步骤来实施。然而在实践中不同的产品可能采用不同的开发方式，如自底向上（bottom-up）、由内向外（middle-out）、渐进式、迭代式或敏捷式等。
泰雷兹根据这些工程师的多种反馈，不断完善，最终形成了符合工程师思维，贴合工程实践的MBSE方法：Arcadia。
4. 2011年-2014年：泰雷兹内部推广和应用
随着Arcadia方法不断成熟，泰雷兹也开发了支撑Arcadia实施的建模工具Capella。目前在泰雷兹内部已经有上千人参加过该方法的系统培训，在航空电子、轨道系统、防务系统、卫星系统和地面站、通信系统等领域有着广泛的应用。
▲图-4 泰雷兹产品系列
5.2014年后，Arcadia方法开源
2014年后，借助于Clarity联盟建立Arcadia方法推广生态圈，该生态圈包含制造型企业、软件开发商、咨询服务公司和高校学术机构等，共同促进该MBSE方法的应用推广和完善。目前Capella的代码也已经开源，成为Polarsys工业组织下的Eclipse平台的一部分。
▲图-5 Arcadia/Capella开源生态系统
3 Arcadia的特点
ARCADIA是ARChitecture Analysis and Design Integrated
Approach的缩写，它是一种架构分析和设计综合方法，是一种适用于工程系统、硬件和软件架构设计的基于模型的工程方法。该方法强调连续性工程，并和ISO/IEC/IEEE
15288，IEEE 1220标准中定义的系统工程流程应用保持一致，在问题域和解决方案域做了明显区分，其中问题域包括两个工程层级活动：运行分析和系统分析，主要关注于业务需要、系统作为“黑盒”的外部功能分析；而解决方案域包括两个工程层级活动：逻辑架构和物理架构定义，主要把系统作为“白盒”，开展内部功能分析，以及系统的组成，组成元件如何实现。
▲图-6 Arcadia方法示意图
运行分析是Arcadia方法中的最高层级工程活动，主要研究“系统的用户需要做什么”。主要活动是识别与系统交互的参与者，参与者的活动和活动间的交互关系，以分析用户的需要和需求问题。
系统分析是Arcadia方法中的第二层级工程活动，主要定义“为满足用户需求，系统必须做什么”。主要活动是开展系统外部功能分析，包括在非功能性属性的限制下，识别用户需要的系统功能（如功能描述一般是动宾短语，如“计算最佳路径”，“检测威胁”）。
逻辑架构是Arcadia方法中的第三层级工程活动，主要定义“系统如何工作才能满足客户期望”。主要活动是内部系统功能分析，包括必须执行哪些子功能，并将这些子功能进行组合，来满足上一层级中确定的用户需要的系统功能。以及考虑非功能性约束下，识别出逻辑组件来执行这些内部子功能。
物理架构是Arcadia方法中的第四层级工程活动，主要定义“系统将如何开发和建造”。物理架构层级的目标和逻辑架构层级是一致的，主要目的是定义系统内部如何工作才能满足客户期望，但除此之外，该层级还定义将要建造的系统最终物理架构。它增加了实施和某些技术选择所需的功能，并突出执行这些功能的行为组件（如软件组件）。进一步地，这些行为组件由实施组件（如处理器板卡）来实现，实施组件为行为组件实现提供必要的材料资源。
最终产品分解结构（EPBS）和集成合同是Arcadia方法中的最低层级工程活动，主要定义“期望从每个组件的提供者得到什么”。该层级的流程活动从物理架构层级导出每个组件必须要满足的条件，以满足在前几个层级中建立的架构设计约束和限制。
与其他MBSE方法或SysML相比，Arcadia具有以下特点：
3.1 强大的功能分析能力
功能分析是系统工程师广泛使用的经典技术，Arcadia提供了相应视图以支持功能分析。
从语义的角度来看，Arcadia的“功能”和SysML的“活动”表达同样的语义。 Arcadia的功能是动词，用于指定分配给组件所期望的操作。本节描述了SysML的活动（Activity）/动作（Action）和Arcadia功能（Function）之间的结构差异。
在SysML中，几个活动图之间的关联依赖于两个主要概念：
活动由不同类型的动作（可以嵌套其他活动图）描述；
属于该活动图的参数可以连接到某动作的输出/输入引脚。
这种活动图嵌套机制有利于在多个上下文中重用活动图，但单个活动图可以表示的内容受到了限制，并使自下而上的工作流难以实施，如下图所示。
▲图-7 SysML-活动图之间的嵌套
在Arcadia中，理念有很大不同：SysML活动图和Arcadia的数据流图之间存在三个主要区别：
1.Arcadia数据流图中没有控制流，也没有控制节点，例如Join，Fork等；
2.功能及其子功能之间的关系是直接的包含关系；
3.Arcadia中每个被分解的功能的端口之间都没有代理机制。
以上这种语言机制的目的是：
通过减轻工程师管理功能树的复杂性，从维持各级别功能间的依赖性和一致性的复杂工作中解放出来，当达到数百个功能时这会成为设计师很大的负担；
允许立即生成简化的视图以进行功能分析；
实现自上而下和自下而上的工作流程之间的自然结合，这对于支持系统工程师的日常工作至关重要。
Arcadia利用这种语言机制来提供几种简化的系统视图。下面的图说明了这些功能：
▲图-8 Arcadia-数据流图
下面的图是基于上面的数据流图自动计算得来的。端口显示在非叶功能上，但仍然属于叶子功能。
▲图-9 Arcadia-数据流图（自动计算端口）
3.2功能到组件、功能交互到物理接口的关联映射
Arcadia方法最重要的目标是通过识别和验证接口来确保架构设计活动。这一目标是通过提供一种并行进行功能、组件和接口建模的全局方法来实现的（见下图）:
确定子系统的功能 (将功能分配给组件)。
识别子系统之间的功能交互关系(功能之间交换的规范)。
将功能交互项分配给子系统之间的交互关系(将功能端口分配给组件端口，将功能交换分配给组件交换，等等)。
通过组件端口定义接口的规范(根据上面提到的所有规范可以自动推导)
▲图-10 Arcadia中功能、组件、接口的关联映射
这种功能/组件/接口的关联映射，在SysML中实现和实施起来并不简单。Arcadia中的这种建模方法还附带了一组辅助工具，用于加强与此集成相关的模型正确性，并提供自动化方法，这是系统架构设计的关键。
3.3类型和实例的封装简化
这里首先说到系统工程师和软件工程师的文化差异：
系统工程师习惯从“实例”的角度思考问题，所有东西默认都是“实例”，只有在需要重用的时候才引入“类型”的概念。
软件工程师习惯从“类型”的角度思考问题，先设计出“类型”，随后在需要的时候进行“实例化”。
SysML的IBD图用于对块的内部结构建模，SysML源于UML，沿袭了对于“类型”和“实例”的处理机制：在内部块图中，一个Block（类型）可以被分解成由其他块定义的Part（实例）。例如，自行车“Block”有“前轮”和“后轮”两部分，它们都是由Block“Wheel”实例化得来。Block“Wheel”，通过实例化形成Part，实现相同的类型可以在系统中多次重用。
Arcadia中可以使用与SysML中相同的机制来处理“类型”与“实例化”。下面的图显示了相机的存储卡盒可以有两个插槽。只有一个“存储卡”组件，但是被引用了两次。组件分解图显示了“存储卡”组件的单一性。
▲图-11 Arcadia中可以和SysML一样处理类型和实例化
然而，Arcadia在默认情况下建立的元素均为实例化的。经调查表明，系统工程师更习惯设计的元素是实例，当需要重用的时候再建立类型。在Arcadia中，“类型”和“实例”的概念被隐藏起来，所有对象都被认为是“实例”，提供简单的“实例建模”机制。
▲图-12 Arcadia中对实例和类型的封装简化
| 
