Hello all,
Thank you for joining the webinar presented by COMAC and PGM. Here are the answers to the questions asked during the event (English version below):
问：如果在SA层捕捉系统功能的需求，再由LA功能实现系统功能，可否？ 答：按照ARCADIA方法论，就是在SA层定义系统功能，在LA层实现系统功能，没问题的。
问：这个软件自主可控吗？会不会被美国掐脖子？ 答：软件基于开源软件Capella上完全自主开发，相关算法有论文、专利和软著保护，而且已通过自主可控测评，不会被卡脖子。
问：为什么要用CAPELLA系统，考虑过其他软件吗？ 答：1、Capella作为开源软件可以根据自身需要进行定制化开发和调整；2、Capella的Arcadia方法论与中国商飞系统工程NFRP思想一致，强调从场景和需求出发，逐步落实到功能和设备。
问：AI对于故障树的开发与完善有什么影响？ 答：目前而言，所有的安全性工作最后都落实到故障树上。故障树本质上是对系统架构的一种描述形式，但是每个人的表述方式不同。MBSA的理念就是将系统MBSE搭建的系统模型与故障树建立对应关系。核心就是如何建立故障/失效传播模型，故障树就可以自动生成。也许AI可以通过某些输入，自动建立相应的故障树，但是还需明确需要哪些输入，以什么样的形式。不过AI确实可以帮助我们分析故障树，去做级联影响分析工作。
问：part 3.3那个PPT能再讲一下吗？ 答：中国商飞系统工程NFRP，第一阶段是识别利益相关的需要（Need），将用户的需要转化为系统需要实现的功能（Function）以及应该达到的效果，即功能需求（Requirement），最后落实到具体产品（Product），这与Arcadia的运行分析到系统分析再到逻辑架构和物理架构，比较相近。因为飞机比较复杂和庞大，所以分为飞机级和系统级两大部分。3.3节主要讲的就是如何将这三者有机结合。我们将模型分为两大块，飞机级模型和系统级模型。在飞机级模型中主要是根据飞机的需要（OA）捕获飞机级功能（SA），并将其分配分解给各系统（飞机级LA/系统级SA）。例如，分析飞机运行，需要一个为飞行员提供飞机状态指示的飞机级功能。这个功能再分配给显示系统和飞控系统，由飞控提供需要的数据，显示系统提供显示。然后再由各个系统去细化自己的系统级功能，飞机状态可以拆解为空速、地速等，不同的参数有可能有不同的安全性要求和架构要求，系统在LA层和SA层不断细化自己的架构设计。在飞机级分配完之后，系统级的模型都是各自搭建。显示和飞控系统只知道和对方有接口有交互，但是不知道具体的传输路径。此时引入一个中间态的集成模型，将全机系统的接口需求收集起来，再去合理配置有限的航电网络资源，确定各系统的设备接哪一个交换机、哪一个端口。将这个结果再分配给各个系统。最后就完成整个从数据源到传输到接收端的模型，也保证了功能之间的追溯关系。
问：失效状态定义图长什么样子？能否解决状态爆炸？ 答：失效状态定义是和功能挂钩，也就是加一层失效传播模型，将两个功能拉在一起，做一个父功能。在父功能上关联失效状态。建立的系统架构模型和失效传播模型都是有限空间和确定性过程。
问：COMSPEC开源吗？ 答：COMSPEC是商用软件，具体购买事宜可联系上海仆勾山科技有限公司 renfei.xu@pgmse.com。
Q: Can system functions be captured at the SA level and then implemented by LA functions? A: According to the ARCADIA methodology, system functions are defined at the SA level and implemented at the LA level. This is perfectly valid.
Q: Is this software independently controlled? Could it be restricted by the United States? A: The software is entirely independently developed on top of the open-source platform Capella. The underlying algorithms are protected by papers, patents, and software copyrights, and the software has passed an independent controllability evaluation. It cannot be blocked.
Q: Why use Capella? Were other tools considered? A: 1. As an open-source tool, Capella can be customized and adapted to specific needs. 2. Capella’s ARCADIA methodology aligns with COMAC’s systems engineering NFRP approach, which emphasizes deriving functions and equipment from scenarios and requirements.
Q: What impact does AI have on fault tree development and refinement? A: Currently, all safety work ultimately comes down to fault trees. A fault tree is essentially a description of the system architecture, though different people express it differently. The MBSA concept establishes a correspondence between the system model built in MBSE and the fault tree. The core challenge is how to build a fault/failure propagation model so that fault trees can be generated automatically. AI may be able to automatically generate fault trees from certain inputs, but the required inputs and their format still need to be defined. That said, AI can already help analyze fault trees and perform cascading impact analysis.
Q: Could you explain slide 3.3 again? A: COMAC’s systems engineering NFRP approach works in three stages: identifying stakeholder Needs, translating them into Functions the system must perform and the expected outcomes (Requirements), and finally specifying the concrete Product. This closely mirrors ARCADIA’s progression from Operational Analysis to System Analysis, then to Logical and Physical Architecture. Because aircraft are complex and large, the model is split into two levels: aircraft-level and system-level. Section 3.3 explains how to organically integrate these three elements. At the aircraft level, aircraft-level functions (SA) are captured from operational needs (OA) and allocated to individual systems (aircraft-level LA / system-level SA). For example, analyzing aircraft operations reveals the need for an aircraft-level function to provide the pilot with aircraft status indications. This function is then allocated to the display system and the flight control system — the flight control system provides the required data, and the display system handles the presentation. Each system then refines its own system-level functions. Aircraft status can be broken down into airspeed, ground speed, etc., with different parameters potentially carrying different safety and architecture requirements. Systems continuously refine their architectural design at both the LA and SA levels. After aircraft-level allocation is complete, each system builds its own model independently. The display and flight control systems only know they have an interface and interaction with each other, but not the specific transmission path. An intermediate integration model is then introduced to collect the interface requirements of all aircraft systems and rationally allocate the limited avionics network resources — determining which switch and which port each system’s equipment connects to. This result is then redistributed to each system. The final model covers the complete chain from data source to transmission to receiver, while also ensuring traceability between functions.
Q: What does a failure state definition diagram look like? Can it address state explosion? A: Failure state definitions are linked to functions by adding a failure propagation model layer that connects two functions under a parent function. The failure state is then associated with that parent function. Both the system architecture model and the failure propagation model operate within a finite space and through a deterministic process.
Q: Is COMSPEC open source? A: COMSPEC is commercial software. For purchasing inquiries, please contact Shanghai Pugoushan Technology Co., Ltd. at renfei.xu@pgmse.com.
Please note: this webinar will be conducted in Mandarin.