泰雷兹MBSE发展历程—Arcadia方法的产生
Modeler
1、Arcadia方法总体介绍
Arcadia（ Architecture Analysis and Design Integrated Approach ）是泰雷兹集团探索MBSE多年后的工业结晶，它是一种经过多个工业部门实践检验的、符合系统工程师思维的MBSE方法论。Arcadia在泰雷兹集团内部有着广泛应用，从航空电子、轨道系统、防务系统、卫星系统、地面站到通信系统等都采用该方法开展系统工程的实践。目前Arcadia方法已趋于成熟，在欧盟及国际大型企业有着广泛的应用，采用Arcadia方法的企业已经超过200家，这其中包括研制运载火箭的阿丽亚娜集团，研制航空发动机的Rolls Royce公司，法国核电巨头法马通等。该方法论贴合工程，工业部门应用范围广，这也是西门子选择Arcadia方法作为实践MBSE的原因之一。
2、泰雷兹MBSE发展历程
接下来我们讲述泰雷兹集团探索MBSE的心路历程，主要分为以下几个阶段：
2.1、2000s产品转型：由部件级供应商转型为系统级供应商
早在2000s左右，泰雷兹在市场和产品上面临一次巨大转型，从供应分散的零部件再被第三方集成交付给客户，转型为提供“交钥匙”的整体解决方案和综合系统，如空中交通控制系统，防务任务系统，卫星系统，和通讯基础设施和网络系统等。这种产品的转型带来了工程模式的变化，由之前关注于技术性能需求为主，转变为重点关注交付客户所需的运行能力需求；由之前关注于各领域的局部最优转变为全局解决方案最优，综合考虑机械特性、产品性能、算法处理、电气设计、以及运行环境、产品政策、安全可靠性、人因对交付的系统产品的影响。这就是泰雷兹采用系统工程方法的最初原因-解决综合的系统设计问题。
2.2、2001-2006年：基于模型的方法初体验
2001年前后，泰雷兹基于UML语言、RUP建模流程开始基于模型的方法探索，以取代基于文档的方式，本阶段的成果物之一是MDSysE（Model-Driven System Engineering）软件，基于该软件开展架构设计和分析。
尽管该方法能够涵盖大部分系统工程流程活动，也能指导系统工程师进行系统思考，但是无法支持功能分析。而且UML对于不是建模专家的系统工程师来说，太复杂了，对工程系统层级的属性和特性表达的支持也不够充分。
2.3、2006年-2011年：Arcadia方法的产生
2006年后，泰雷兹对涉及的所有工程人员进行充分的调研，包括运行分析师、需求经理、架构师、软件/硬件开发人员、安全可靠性专家、维护后勤专家以及装配集成人员等。总结出共性问题如下：对客户的需求进行分析，以便准确、更清晰地理解客户的期望、目标和能力，以及解决方案如何满足这些期望；增强架构定义的质量，以及架构师与各领域专家的协同；设计早期能识别出架构定义和设计的缺陷，而不是在后期的集成阶段。
泰雷兹发现无论是之前基于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。
2.4、2011年-2014年：泰雷兹内部推广和应用
随着Arcadia方法不断成熟，泰雷兹也开发了支撑Arcadia实施的建模工具Capella。目前在泰雷兹内部已经有上千人参加过该方法的系统培训，在航空电子、轨道系统、防务系统、卫星系统和地面站、通信系统等领域有着广泛的应用。
2.5、2014年后，Arcadia方法开源
2014年后，借助于Clarity联盟建立Arcadia方法推广生态圈，该生态圈包含制造型企业、软件开发商、咨询服务公司和高校学术机构等，共同促进该MBSE方法的应用推广和完善。目前Capella的代码也已经开源，成为Polarsys工业组织下的Eclipse平台的一部分。
3、Arcadia的特点
ARCADIA是Architecture Analysis and Design Integrated Approach的缩写，它是一种架构分析和设计综合方法，是一种适用于工程系统、硬件和软件架构设计的基于模型的工程方法。该方法强调连续性工程，并和ISO/IEC/IEEE 15288，IEEE 1220标准中定义的系统工程流程应用保持一致，在问题域和解决方案域做了明显区分，其中问题域包括两个工程层级活动：运行分析和系统分析，主要关注于业务需要、系统作为“黑盒”的外部功能分析；而解决方案域包括两个工程层级活动：逻辑架构和物理架构定义，主要把系统作为“白盒”，开展内部功能分析，以及系统的组成，组成元件如何实现。
运行分析是Arcadia方法中的最高层级工程活动，主要研究“系统的用户需要做什么”。主要活动是识别与系统交互的参与者，参与者的活动和活动间的交互关系，以分析用户的需要和需求问题。
系统分析是Arcadia方法中的第二层级工程活动，主要定义“为满足用户需求，系统必须做什么”。主要活动是开展系统外部功能分析，包括在非功能性属性的限制下，识别用户需要的系统功能（如功能描述一般是动宾短语，如“计算最佳路径”，“检测威胁”）。
逻辑架构是Arcadia方法中的第三层级工程活动，主要定义“系统如何工作才能满足客户期望”。主要活动是内部系统功能分析，包括必须执行哪些子功能，并将这些子功能进行组合，来满足上一层级中确定的用户需要的系统功能。以及考虑非功能性约束下，识别出逻辑组件来执行这些内部子功能。
物理架构是Arcadia方法中的第四层级工程活动，主要定义“系统将如何开发和建造”。物理架构层级的目标和逻辑架构层级是一致的，主要目的是定义系统内部如何工作才能满足客户期望，但除此之外，该层级还定义将要建造的系统最终物理架构。它增加了实施和某些技术选择所需的功能，并突出执行这些功能的行为组件（如软件组件）。进一步地，这些行为组件由实施组件（如处理器板卡）来实现，实施组件为行为组件实现提供必要的材料资源。
最终产品分解结构（EPBS）和集成合同是Arcadia方法中的最低层级工程活动，主要定义“期望从每个组件的提供者得到什么”。该层级的流程活动从物理架构层级导出每个组件必须要满足的条件，以满足在前几个层级中建立的架构设计约束和限制。
