唐剑，中国商飞北研中心需求工程部部长，研究员，从事商用飞机概念阶段需求论证，系统工程以及民机航空电子技术研究。“适航思维”在此衷心感谢其无私的知识和经验分享。
在过去的几十年里，系统工程领域的复杂性和挑战性不断增加。随着技术的快速发展，系统工程师们需要协调不断变化的需求、预测未来的技术趋势以及应对潜在的风险。为了应对这些挑战，系统工程领域的专家们提出了一种新的方法，即模型驱动系统工程 (Model-Based Systems Engineering，MBSE)。MBSE旨在通过使用模型作为系统设计和分析的核心，替代传统的文档驱动方法，从而提高效率和减少错误。
尽管MBSE的潜力巨大，但其实施过程中也存在很多痛点，首当其冲的是缺乏有效的方法论指导，设计者常常缺乏清晰的步骤和指南来指导他们从开始到结束的整个建模活动，进而导致一系列后果：首先是缺乏明确的步骤和建模框架，设计者在实施过程中容易迷失方向，不清楚应如何进行下一步工作。其次是工作效率下降，设计者需要花费大量时间和精力去尝试不同方法，而不能有效地专注于实际设计任务。第三是质量和风险影响，缺乏方法指引可能导致在实施过程中出现错误或遗漏，这不仅可能影响系统的质量和性能，而且可能导致需要进行大量的修改和调整，从而增加工程的成本和风险。最后，由于缺乏有效的方法论指导，可能会导致工程师们在实施MBSE时感到困惑和挫败，从而影响他们的积极性和创新性。
为了应对上述痛点，法国Thales集团从2001年开始进行基于模型的尝试，经过近10年的探索，期间尝试了UML/SysML等语言和NAF，UAF框架，以及一些商业建模工具，最后他们认为：没有一种建模语言可达到预期效果，配套工具过于通用且缺乏方法论指导进而导致应用困难。所以经过一段时间决策，Thales决定完全自己构建一套方法论，就是ARCADIA的前身，经过数年的应用迭代，到2008年，Thales又决定定义支持ARCADIA方法论的专用语言 (Domain Specific Language (DSL))，同时启动了建模工具Capella的开发。又经过2年，ARCADIA方法论逐步成型，Thales开始在内部推广使用，直到2015年，Thales向全社会公开了ARCADIA方法论，并开源了Capella工具。之后以其开放、开源、完整的特点，迅速得到了欧洲多个行业应用，不久也得到国内一些科研机构的关注和试点应用。2018 年ARCADIA被法国国家标准化组织 AFNOR 注册为Z67-140 标准。
ARCADIA: Architecture Analysis and Design Integrated Approach
，直译叫做架构分析和设计集成方法，是一种基于建模手段实现复杂系统架构定义和确认的结构化设计方法。所谓架构定义和确认，是指对利益相关方关键需要 (Needs)的捕获和需求 (Requirements)的综合，对被设计系统架构概念方案的协同开发指引。所谓结构化，是强调其过程的有序和预定义。
Capella是ARCADIA配套的建模工具，内置了完整的ARCADIA方法论的建模模板指引。Capella是开源的，但如协同建模功能则需要购买商业版本。Capella使用了一套完全自定义的领域建模语言DSL，一些理念与SysML相似，但工程人员更容易上手。此外，Thales内部的大量在Capella建模工具内部使用插件和检查规则是不公开的。
按照ARCADIA之父Jean-Luc Voirin的说法，ARCADIA的重点，是对复杂系统顶层需求和架构进行定义，所以其用法有几个重要特征。
-
构建对系统需求和架构的顶层统一认识，以此加强内外部设计人员的协同和共识。如果系统存在多种架构，其权衡过程不属于ARCADIA的覆盖范围；
-
通过架构建立特定领域分析（如安全性、可靠性、人为因素、客户服务、保障）关联，但不深入其核心专业（换言之，对应专业使用各自的方法进行分析）；
-
架构定义是复杂系统开发活动的重要构成，包括分析运行需求、搭建系统结构，系统组成分解，软硬件划分等内容，目的是为了：
-
-
对需求分析、系统设计和开发过程有效管理，进而支撑复杂度管理；
-
-
总体而言，ARCADIA方法论将复杂系统需求分析和架构定义分成两大部分、四个层次。首先是需要理解，也就是问题的定义，包含Operational Analysis (OA)运行分析和System needs Analysis (SA)系统需要分析。第二个部分是方案架构定义，包含Logical Architecture (LA)逻辑架构定义和Physical Architecture (PA)物理架构定义。整体关系如图所示：
运行分析 (Operational Analysis (OA))
运行分析是捕获用户在其工作或任务必须达到的目标以及相关条件，与解决方案或用户实现其目标的系统无关。在不预设系统范围前提，最大化客户需求，或者是要创新运行规则时，运行分析是至关重要的。比如：假设客户需求是在墙上挂一面镜子。如果将需求定义为“如何将钉子固定在墙上”，就过早的排除了其他可能性，如使用胶水等。
运行分析只应聚焦于客户需要做的事上，在上面案例中，运行能力特指需要一种固定镜子的能力，而不是具体采用什么方法，那是后续设计需要考虑的问题。
运行分析的产物主要包括用户目标需求的“运行架构”，根据参与者/用户、他们的运行能力和活动、用户使用场景及其约束（包括安全性、安全性、生命周期等）。
系统需要分析 (System needs Analysis (SA))
系统需要分析核心目的是定义系统功能，识别系统与外部的交互，以及分析系统如何满足运行分析所识别的能力要求。系统需要分析的功能分析过程需要注意颗粒度，不应包含任何系统架构的倾向或者系统实现的具体细节。
此过程的主要活动包括三个步骤：（1）能力权衡，针对OA分析得到的运行能力，逐一分析可能的备选方向并进行一定的量化比较，最终找出若干折中方向。此过程最好是与用户合作开展，以此增加最终产品满足用户预期的确定性。在挂镜子案例中，可能备选方向包括钉子、胶泥、双面胶等；（2）需要分析，将系统需要正式化、模型化，识别非功能性约束；（3）综合分析，对前两个步骤的产物进行关联分析，建立追溯关系，按需整合。
逻辑架构定义 (Logical Architecture (LA))
逻辑架构定义是系统架构的初步展开，颗粒度适中，但存在一定程度的抽象。逻辑架构的核心作用，是支撑设计上关于架构的重大决策，所以其颗粒度控制在不影响逻辑架构的结构决策的程度，系统更详细的实现细节留到物理架构进行细化。
可以通过逻辑架构定义，使用模型描述若干个架构选择方案并进行权衡。其主要活动包括：（1）定义影响架构和分析视角的约束，通过参数模型捕获考虑因素、量化并建立上游关联；（2）定义系统行为的基本规则，通过功能分析法对系统的基本行为进行模型化定义，使用逻辑功能 (Logical Function (LF))进行捕获，此处应注意不应简单理解为对SA环节所识别的系统功能进行简单细化，而应该创造性的综合考虑系统应提供的能力。比如挂镜子案例中，在选择钉子作为设计路线情况下，基于对安装人员安全角度考虑，可以创造性的增加对钉子的锋利边角进行保护；（3）搭建系统架构的若干可选方案，基于识别的逻辑功能LF，基于可能的组合原则，识别逻辑部件 (Logical Component (LC))及其组合方式，进而形成若干可选方案；（4）权衡并选择最佳架构方案。
物理架构 (Physical Architecture (PA))
物理架构定义了系统的最终实现架构，以足够的详细程度，描述了所有子系统（部件）的研制或采购方案，还包括系统集成、验证和确认的定义。完成物理架构的定义，系统的研制方案就足够明确，可以开展子部件的研制，或者采购。对于研制而言，子部件的能力要求、外部接口、运行限制、集成和验证要求清晰。
物理架构的定义与逻辑架构一般方法和过程类似，不同在于物理架构的表达要素是实际可实现的，主要活动包括：（1）定义影响物理架构和行为的约束；（2）定义系统行为的详细描述，识别物理功能(Physical Function (PF))，方法类似于逻辑架构的对应步骤，但颗粒度应达到可以支持识别物理部件，使其达到可实现、可采购程度。（3）搭建系统物理架构的若干可选方案，基于识别的物理功能PF，基于可能的组合原则，以及可选的技术途径等因素，定义物理部件 (Physical Component (PC))及其组合方式，进而形成若干可选方案；（4）权衡并选择最佳架构方案。
《基于ARCADIA建模方法的系统架构工程》([法]让·吕克·瓦兰 (Jean-Luc,Voirin))
此书是ARCADIA方法论之父Jean-Luc, Voirin的大作，是唯一专门讲解ARCADIA方法论书籍。此书并不是系统工程的基础读物，也不是一本关于如何建模的书，而是围绕ARCADIA的发展历史、基本概念、典型用法进行论述，所讲内容往往是MBSE其他书籍较少涉及的主题，比如如何进行功能分析、需求工程与建模的关系、不同研制层级之间的衔接、对产品线工程的贡献等等。
《基于Arcadia方法的系统架构建模：Capella实用指南》([法] Pascal Roques)
https://www.eclipse.org/capella/arcadia.html
文章来源：适航思维
当前暂无评论，小编等你评论哦！
