五个MBSE用例｜Five MBSE Use Cases

Use Case 1：System of Systems and Transitioning the Functional Interfaces to Logical Systems 体系和功能接口向逻辑系统过渡 (UC1)

作为系统工程师，我希望将系统系统分解为可管理的系统模型。系统和组件被视为整体系统系统的“黑盒”部分。过渡应包括功能、接口和非功能性需求。

Preconditions/Inputs 前置条件/输入

系统系统规范，设计要求，系统背景，关键系统属性和设计约束，接口控制定义（ICDs），操作场景和用例的要求。

Activities 活动

Post conditions/Outputs 后置条件/输出

一套用于整体系统系统逻辑架构的模型，其中包括用于描述分配的功能需求、接口和整体系统状态定义的各个系统和组件的模型。

Use Case 2: Define System Operational Scenarios 定义系统操作场景 (UC2)

作为系统工程师，我希望能够更好地理解待开发系统的操作背景。因此，需要指定系统操作场景，以描述其预期运行的所有模式和可能条件下所需的系统行为。这些场景是ARCADIA或SysML用例中的操作场景。

Preconditions/Inputs 前置条件/输入

描述整体系统分配功能需求、接口和状态定义的各个系统和组件的模型。

Activities 活动

Post conditions/Outputs 后置条件/输出

描述正在开发中的系统在其上下文使用中的行为的系统操作场景。

Use Case 3: Export System Functional Specifications 导出系统功能规范 (UC3)

作为系统工程师，我希望能够提供一个最终的系统规范包，以便供应商可以进行系统设计。下图突出显示了在V模型中交付内容的位置。用例3描述了通常在OEM和系统供应商之间交换的最低限度的交付内容。

下面的信息描述了“系统A的功能分解”，包括输入和输出结果，代表了用例3。

Preconditions/Inputs 前置条件/输入

• 功能顶层需求
• 系统操作场景
• 清晰的非功能性需求，如性能和认证要求
• 外部接口定义

Activities 活动

作为“系统A的功能分解”显示的活动，其主要部分是对系统规范模型的定义。系统规范模型包括了系统的标称行为的可执行功能模型，其中定义了输入、输出、系统状态，以及性能、设计和安全约束。这个摘要表示可以从项目的目的和需求出发，以文本形式进行定义，或者从观察者的视角进行建模。系统规范模型用于明确陈述系统需求。

用例3的活动需要按照表4中的描述开发图表类型。

1.这些工件的开发程度取决于OEM -系统供应商关系和正在开发的系统类型。在领域知识属于系统供应商的地方，这些工件很可能没有得到充分开发，无法保护专有知识。(注意:ARCADIA子系统转换允许用不同的ARCADIA级别填充模型生成，即，与系统供应商的领域知识相称)

**在每个ARCADIA级别中可用（系统分析、逻辑架构、物理架构）

正如前面的表格所示，对于几个工件，可以使用一个以上的ARCADIA或SysML图表来表示。

为了支持一个最小化、优化的解决方案，项目团队对以下图表进行了优先排序。以下列表是需要用于表示用例3所有艺术品的最小图表集合。

Post conditions/Outputs 后置条件/输出

• 系统规范模型（可能包括参数图）
• 运行场景
• 文字（或模型化的）系统性能
• 认证、安全和其他约束要求

Use Case 4: Pre-Stage the Validate & Verify Process andCo-Develop Behavior Models 预先准备验证和验证过程，并共同开发行为模型 (UC4)

作为系统工程师，我希望能够验证和验证基于模型的功能规范。结果应包括如何验证功能行为的声明，以及根据用例3定义的系统规范的合规性和完整性的报告或其他输出。在下图中定义的观察者模型指定了系统上下文。它为信息场景提供不同的输入，并指定了预期的系统输出行为。使用观察者模型需要可执行的系统规范与之交互和验证。由于需要描述预期的系统行为的不同验证场景，因此观察者模型将被转发给供应商进行产品验证，然后再交付。验证和验证（V＆V）活动应独立于基于模型的系统规范进行定义，参见UC3中图。

Preconditions/Inputs 前置条件/输入

• 系统顶级要求的规范
• 操作场景和用例的建模
• 可执行系统功能规范的建模
• 系统验证场景的建模

Activities 活动

Post conditions/Outputs 后置条件/输出

V&V报告应验证要求和体系结构建模与行为建模之间的关系，并通过模拟或其他手段演示建模行为是否根据要求和体系结构模型内容中提供的参数执行。结果包括与供应商的合作和行为模型的共同开发。

Use Case 5: Export Hardware/Software FunctionalSpecifications 导出硬件/软件功能规范 (UC5)

作为系统工程师，我希望能够提供一个设备规格包，以便供应商可以继续进行详细的系统设计，该设计规定了设备的软件和/或硬件解决方案。图13显示了交付内容在V型模型中的位置。该过程涉及到ICD的共同开发，该ICD定义了网络配置、信号接口、每个接口的协议以及软件通信和消息。

设计过程产生的三个重要交付成果包括以下内容：

• 定义了组件/软件/系统故障模式的功能性危险评估（Functional Hazard Assessments，FHAs）
• 故障隔离图/树
• 在分析系统对故障模式响应时必须考虑的相关操作条件

Preconditions/Inputs 前置条件/输入

• 系统规范模型
• 系统性能的行为模型和衍生文本描述
• 操作场景和场景的模拟
• 认证、安全和其他限制性要求

Activities 活动

Post conditions/Outputs 后置条件/输出

• 设备规范模型
• 文本（或模型化）设备性能
• 认证、安全（功能性危险分析（FHAs）和系统功能测试（SFTs））以及其他限制性要求
• 物理体系结构和系统/软件/设备行为

Use Case Summary of Critical Diagram Types for Interoperability 互操作性关键图类型的用例总结

根据项目的目标和定义的生命周期用例的广泛范围，MBSE项目团队确定了Use Case 3和Use Case 4作为更深入评估的最高优先级。团队重点关注定义了必需的最小系统架构定义图表集，同时使用SysML和ARCADIA语言，以便在OEM与其供应商之间实现双向的基于模型的协作过程（即WHAT）。

SysML互操作性 - 高优先级用例图表

• Block Definition diagrams（块定义图表）
• Internal Block diagrams（内部块图表）
• Activity diagrams（活动图表）
• Sequence diagrams（序列图表）
• Parametric diagrams（参数图表）
• State diagrams（状态图表）

ARCADIA互操作性 - 高优先级用例图表

• Component Breakdown diagrams（组件分解图表）
• Component Interface diagrams（组件接口图表）
• Architecture diagrams（架构图表）
• Functional Data Flow diagrams（功能数据流图表）
• Functional Scenario diagrams（功能场景图表）
• Entity/Functional Scenario diagrams（实体/功能场景图表）
• Logical/Physical Architecture diagrams（逻辑/物理架构图表）
• Mode/State diagrams（模式/状态图表）