1 SYS.3 标准原文

过程目的

目的是建立一个符合系统要求的分析系统架构，包括静态和动态两个方面。

过程结果

     1) 设计一个系统架构，包括定义系统元素及其行为、接口、关系和交互。

     2) 根据定义的标准对系统架构进行分析，并确定其特殊性。

     3) 在系统架构和系统需求之间建立一致性和双向可追溯性。

     4) 将商定的系统架构和特殊特性传达给所有相关方。

基本实践

SYS.3.BP1：明确系统架构的静态方面。 根据系统的功能性和非功能性要求，指定并记录系统架构的静 态方面，包括外部接口和一组已定义的系统元素及其接口和关系。

SYS.3.BP2：说明系统架构的动态方面。 根据功能性和非功能性系统要求 (包括系统元素的行为及其在不同系统模式下的交互) ，指定并记录系统架构的动态方面。

注 1：系统元素相互作用的例子是反映机械部件惯性、ECU 处理时间和总线系统信号传播时间的时序图。

SYS.3.BP3：分析系统架构 。 分析与产品生命周期相关的技术设计方面的系统架构，支持项目管理方面 的项目估算，并推导出非软件系统元素的特殊特性。记录系统架构设计决策的理由。

注 2：项目可行性见 MAN.3.BP3，项目估算见 MAN.3.BP5。

注 3：产品生命周期的例子包括产品生命周期阶段的例子包括生产、维护和修理、退役。

注 4：技术方面的例子有：生产的可制造性、已有系统元件的可再利用性或系统元件的可用性。注 5：适合分析技术方面的方法有原型、模拟和定性分析 (如 FMEA 方法) 。

注 6：设计原理的例子包括使用中的验证、产品平台或产品线的重复使用、"要么做要么买 "的决定或

以演进方式发现 (例如，基于集合的设计) 。

SYS.3.BP4：确保一致性并建立双向可追溯性。 确保系统架构元素与代表物理最终产品属性或特征的系统要求之间的一致性并建立双向可追溯性。

注 7：双向可追溯性可进一步支持一致性，并有助于对变更请求进行影响分析和证明验证覆盖范围。仅有可追溯性，如存在链接，并不一定意味着信息之间是一致的。

注 8：系统架构设计可能没有追溯到非功能性需求。例如，不涉及或不代表物理最终产品的直接属性或特征。此类要求仍需验证。

SYS.3.BP5：沟通商定的系统架构。 将商定的系统架构，包括特殊特性，传达给所有相关方。

2 SYS.3 标准解析

2.1 过程目的Process purpose

原文：目的是建立一个符合系统要求的分析系统架构，包括静态和动态两个方面。。

The purpose is to establish an analyzed system architecture, comprising static and dynamic aspects, consistent with the system requirements.

这句话中，有两个关键词叫 “符合系统需求 ”。另一个叫 “ 静态和动态 ”。

1) 符合系统需求，即系统架构设计的上游是系统需求，其来源为系统需求：

2) 静态： 静态概念主要关注系统的结构化元素，包括系统的组件、它们的接口以及这些组件之间的关系。具体来说，静态概念涉及以下几个方面：

     a) 系统及其边界的关系 ： 静态架构图需要描述系统与外部环境之间的关系，包括系统自身和系统外部的相关组件。

     b) 系统与外部环境之间的接口 ： 在系统需求中存在系统外部接口的规格描述，这些接口应在静态架构图中清楚标出。

     c) 子系统和系统元件的标识 ： 根据系统的复杂程度，系统可以被拆解成子系统或直接拆解成系统元件。在静态架构图中，需要清楚标识这些子系统和系统元件。

     d) 子系统/系统元件间的接口 ： 系统元件间的接口通常不存在于系统需求描述中，它们是为了实现特定系统需求而存在的。因此，需要详细描述系统元件及其间的接口。

3) 动态：动态概念则关注 系统的行为和系统元件之间的交互 ，特别是在不同系统模式下的行为。具体来说，动态概念包括以下几个方面：

     a) 状态机图 ： 状态机图描述系统在不同状态之间的行为和动作，常见的状态包括开机、关机、正常模式、校准、诊断等。

     b) 时序图 ： 时序图（Sequence diagram）描述系统元件间的交互，包括机械组件的惯性时序、ECU的处理时间、总线系统的信号传播时间等。

静态和动态概念共同构成了系统架构设计的完整视角， 静态概念提供了系统的结构框架 ，而 动态概念则描绘了系统的行为和交互 。

这两个概念是并行考虑的，以确保系统架构设计与系统需求保持一致，并能够满足所有功能和非功能需求

2.2 过程成果Process outcomes

原文：

     1) 设计一个系统架构，包括定义系统元素及其行为、接口、关系和交互。

     2) 根据定义的标准对系统架构进行分析，并确定其特殊性。

     3) 在系统架构和系统需求之间建立一致性和双向可追溯性。

     4) 将商定的系统架构和特殊特性传达给所有相关方。

     1) A system architecture is designed including a definition of the system elements with their behavior, their interfaces, their relationships, and their interactions.

     2) The system architecture is analyzed against defined criteria, and special characteristics are identified.

     3) Consistency and bidirectional traceability are established between system architecture and system requirements.

     4) The agreed system architecture and the special characteristics are communicated to all affected parties.

基本实践BP代表面向活动的指标 ， 而输出信息OIs是面向结果的指标 ， 它们共同支持过程成果的实现 。 具体详见本文章节2.4。

2.3 基本实践Base Practices

2.3.1 SYS.3.BP1：明确系统架构的静态方面

原文：根据系统的功能性和非功能性要求，指定并记录系统架构的静态方面，包括 系统外部接口 、 系统元素、系统元素接口、系统元素交互关系 。

Specify and document the static aspects of the system architecture with respect to the functional and non-functional system requirements, including external interfaces and a defined set of system elements with their interfaces and relationships.

该BP详细解析如下：

1) 系统外部接口（External Interfaces）：

    系统外部接口是指系统与外部环境或用户之间的交互点。在数字钥匙系统中，这可能包括车辆与智能手机之间的无线通信接口，如NFC、BLE或UWB技术，这些技术允许车辆识别并响应来自授权设备（如智能手机）的信号。

2) 系统元素（System Elements）：

    系统元素是构成系统架构的基本单元，可以是硬件、软件或两者的组合。在数字钥匙系统中，系统元素可能包括车辆的控制单元、数字钥匙管理平台、用户终端（如智能手机）、授权终端以及智能锁终端等。

3) 系统元素接口（System Element Interfaces）：

    系统元素接口定义了系统内部各元素如何相互通信和交互。在数字钥匙系统中，这可能涉及到车辆控制单元与车辆云端之间的安全通信链路，或者是用户设备与车辆之间的配对和通信接口。

4) 系统元素交互关系（System Element Interactions）：

    系统元素交互关系描述了系统元素之间的动态协作方式。在数字钥匙系统中，这可能包括车辆通过无线模块与设备进行配对的过程，以及车主设备通过云端与好友设备分享钥匙的过程。

5) 记录系统架构设计决策的理由：

    需要记录系统架构设计决策的理由。这包括为什么选择特定的技术方案、为什么采用某种设计方法、以及为什么做出特定的权衡等。例如，在数字钥匙系统中，可能需要记录为什么选择NFC作为主要的无线通信技术，以及这种选择如何满足系统的功能性和非功能性需求。

2.3.2 SYS.3.BP2：说明系统架构的动态方面。

原文：根据功能性和非功能性系统要求 (包括系统元素的行为及其在不同系统模式下的交互) ，指定并记录系统架构的动态方面。

Specify and document the dynamic aspects of the system architecture with respect to the functional and non-functional system requirements including the behavior of the system elements and their interaction in different system modes.

注 1：系统元素相互作用的例子是反映机械部件惯性、ECU 处理时间和总线系统信号传播时间的时序图。

Note 1: Examples of interactions of system elements are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus systems.

详细解析如下：

1) 动态方面的指定与记录：

    根据功能和非功能性系统需求，需要具体说明并记录系统架构的动态方面。这包括系统元素的行为以及它们在不同系统模式下如何交互。

2) 系统元素的行为：

    动态方面需要描述系统元素在执行其功能时的行为。例如，一个发动机管理系统（EMS）在启动、运行和关闭等不同模式下的行为。

3) 系统元素的交互：

    需要记录系统元素之间的交互，这些交互定义了它们如何协同工作以实现系统的功能。例如，安全气囊系统在检测到碰撞时如何与传感器和控制单元交互。

4) 不同系统模式下的交互：

    系统可能有不同的操作模式，如正常模式、故障模式、维护模式等。SYS.3.BP2要求分析和记录这些不同模式下系统元素的交互，以确保系统在各种条件下都能正确响应。

5) 时序图和状态转换图：

    动态方面的描述可能包括时序图，反映机械部件的惯性、ECU的处理时间、总线系统的信号传播时间等。状态转换图（State transition Diagram）则描述系统在不同状态之间的行为与动作，如开机、关机、正常模式、校准、诊断等。

6) 使用案例图：

    使用案例图描述系统的高层次功能和范围，展示系统与其他系统组件、外部组件或用户之间的互动情境。这些情境可以根据系统需求的描述而得出。

7) 记录设计决策的理由：

    在系统架构设计过程中，需要记录所有关键决策的理由，包括为什么选择特定的技术方案、为什么采用某种设计方法、以及为什么做出特定的权衡等。

2.3.3 SYS.3.BP3：分析系统架构。

原文：分析与产品生命周期相关的技术设计方面的系统架构，支持项目管理方面的项目估算，并推导出非软件系统元素的 特殊特性 。记录系统架构设计决策的理由。

Analyze the system architecture regarding relevant technical design aspects related to the product lifecycle, and to support project management regarding project estimates, and derive special characteristics for non-software system elements. Document a rationale for the system architectural design decisions.

注 2：项目可行性见 MAN.3.BP3，项目估算见 MAN.3.BP5。

注 3：产品生命周期的例子包括产品生命周期阶段的例子包括生产、维护和修理、退役。

注 4：技术方面的例子有：生产的可制造性、已有系统元件的可再利用性或系统元件的可用性。

注 5：适合分析技术方面的方法有原型、模拟和定性分析 (如 FMEA 方法) 。

注 6：设计原理的例子包括使用中的验证、产品平台或产品线的重复使用、"要么做要么买 "的决定或以演进方式发现 (例如，基于集合的设计) 。

Note 2: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.

Note 3: Examples for product lifecycle phases are production, maintenance & repair, decommissioning.

Note 4: Examples for technical aspects are manufacturability for production, suitability of pre-existing system elements to be reused, or availability of system elements.

Note 5: Examples for methods being suitable for analyzing technical aspects are prototypes, simulations, and qualitative analyses (e.g., FMEA approaches)

Note 6: Examples of design rationales are proven-in-use, reuse of a product platform or product line), a make-or-buy decision, or found in an evolutionary way (e.g., set-based design).

通过该过程进行系统架构分析，具体解析如下：

     1) 分析系统架构： 需要考虑系统从概念到退役的整个生命周期，包括设计、开发、生产、使用和维护等阶段。

     2) 支持项目管理的项目估算： 分析的结果应该能够支持项目管理中的项目估算工作。这涉及到对项目成本、时间和资源需求的预测，以确保项目在预算和时间框架内完成。

     3) 推导非软件系统元素的 特殊特性 ： 特殊特性是指那些对 产品安全性、可靠性、耐久性等方面有重大影响的特性 。 需识别和推导出这些非软件系统元素的特殊特性，以便在后续的设计和验证过程中给予特别关注。

     4) 记录系统架构设计决策的理由： 在系统架构设计过程中，需要记录所有关键决策的理由。这包括为什么选择特定的技术方案、为什么采用某种设计方法、以及为什么做出特定的权衡等。记录这些理由有助于项目的透明度，也为未来的审查和审计提供依据。

     5) 与项目管理的关联： 特别是MAN.3.BP3和MAN.3.BP5，它们分别涉及项目的可行性和项目估算。这表明系统架构的设计和分析需要与项目管理活动紧密结合，以确保项目目标的实现。

备注的详细解析：

1) 注2：项目可行性（MAN.3.BP3）：

    项目可行性涉及到在时间、项目估算和可用资源的约束条件下，从技术可行性方面评估实现目标的可行性。这包括评估技术是否可行，资源是否足够，以及时间是否允许项目按计划进行。

2) 注2：项目估算（MAN.3.BP5）：

    项目估算涉及到对项目工作量、成本、进度和预算的估计。这可能包括工作量的微观估计，即根据项目的工作分解结构估计创建或实施工作包或模块所需的工作量（例如，以人天为单位）。

    进度估算则是根据估计的工作量和可用资源，估算目标日期。成本估算是通过将估计的工作量乘以相关的人员成本率来确定的，同时还需考虑所需资源（如开发环境和材料）的额外成本。

3) 注3：产品生命周期阶段：

    产品生命周期包括生产、维护和修理、退役等阶段。

    在系统架构设计时，需要考虑产品在这些不同阶段的技术要求和特性，以确保产品在整个生命周期中的可维护性和可支持性。

4) 注4：技术方面：

    技术方面的例子包括生产的可制造性、已有系统元件的可再利用性或系统元件的可用性。

    这些因素影响系统架构的设计，因为它们决定了产品如何被制造、维护和最终退役。

5) 注5：适合分析技术方面的方法：

    分析技术方面的方法可以包括原型、模拟和定性分析（如FMEA方法）。

    这些方法有助于评估系统架构在技术实施方面的可行性和潜在风险。

6) 注6：设计原理：

    设计原理的例子包括使用中的验证、产品平台或产品线的重复使用、“要么做要么买”的决定或以演进方式发现（例如，基于集合的设计）。

    这些原理指导系统架构的设计决策，以确保设计符合项目目标和业务需求。

2.3.4 SYS.3.BP4：确保一致性并建立双向可追溯性。

原文：确保系统架构元素与代表物理最终产品属性或特征的系统要求之间的一致性并建立双向可追溯性。

Ensure consistency and establish bidirectional traceability between the elements of the system architecture and the system requirements that represent properties or characteristics of the physical end product.

注 7：双向可追溯性可进一步支持一致性，并有助于对变更请求进行影响分析和证明验证覆盖范围。仅有可追溯性，如存在链接，并不一定意味着信息之间是一致的。

注 8：系统架构设计可能没有追溯到非功能性需求。例如，不涉及或不代表物理最终产品的直接属性或特征。此类要求仍需验证。

Note 7: Bidirectional traceability further supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.

Note 8: There may be non-functional requirements that the system architectural design does not trace to. Examples are do not address, or represent, direct properties or characteristics of the physical end product. Such requirements are still subject to verification.

2.3.5 SYS.3.BP5：沟通商定的系统架构。

原文：将商定的系统架构，包括特殊特性，传达给所有相关方

Communicate the agreed system architecture, including the special characteristics, to all affected parties.

2.4 过程结果/输出信息项/基本实践 对照表

BP 代表面向活动的指标 ， 而OIs是面向结果的指标 。 它们共同支持过程结果的实现 ， 并用于评估员在评估过程中要收集和积累的客观证据。

各自主要负责的方面：

过程结果：负责 描述和验证过程的目的是否已经达成 ， 是评估过程中的 最终目标 。

基本实践：负责定义实现这些过程结果 所需执行的具体活动或步骤 ，是 过程执行的行动指南 。

输出信息项：负责提供过程中产生的 具体结果或信息，作为评估过程中收集客观证据的依据 。

3 总结

本过程域的前3个BP，可以梳理为下图：

系统架构设计文档中，要包含如下内容：

1) 静态图

     a) 包含哪些系统元素

     b) 这些元素的职责描述、元素包含哪些接口，元素间的关系。

2) 动态图

     a) 系统元素间的交互和行为表现；

     b) 体现形式根据具体功能来体现，形式不限，如：时序图、状态机图、功能安全分析图DSC等。

3) 一定要包含设计的结论和设计的理由。

4) 需要从技术方向、项目估算方面入手，得出非软件系统元素的特殊特性。特殊特性是指那些对产品安全性、可靠性、耐久性等方面有重大影响的特性。