ASPICE（4.0）流程之系统工程开发（SYS）

原创汽车电子与软件 2025-01-08 07:45

TI MCU方案：电动汽车实时控制 【应用手册】TI 全新MCU及C29内核的电动汽车应用方案

作者 | 不可说

出品 | 汽车电子与软件

#01

ASPICE介绍

ASPICE是Automotive SPICE的缩写，是一种用于评估和改进汽车软件开发过程的国际标准；ASPICE定义了一组标准化的软件开发过程和最佳实践，适用于整个软件生命周期，包括需求工程、软件设计、编码、测试和维护等各个领域。

#02

SYS介绍

ASPICE过程参考模型

ASPICE SYS（System Engineering Process Group，系统工程过程组）是ASPICE中的一个关键部分，它涵盖了从系统需求挖掘到系统架构设计、系统集成与测试，再到系统合格性测试的全过程，确保了软件开发过程的全面性和完整性。

作为汽车系统开发工程师，应该了解并尽量遵循SYS过程，简单来说，SYS是一个专注于系统工程相关活动的过程集合。系统工程是一种跨学科的工程方法，旨在确保系统的整体性能达到最优，同时满足用户、制造者和其他利益相关者的需求。

处理内部需求的获取和管理：这是系统工程的一个重要环节，它涉及理解并记录关联方对系统的需求和期望。这包括与利益相关者沟通，确保需求被准确捕获，并在整个项目过程中进行管理，以确保最终的系统能够满足这些需求。

系统架构：系统架构是系统的蓝图，它描述了系统的组成部分、它们之间的关系以及它们如何一起工作以满足需求。定义系统架构是系统工程中的一个关键步骤，因为它为系统的开发提供了框架和指导。

系统级别的集成与验证：在系统开发的后期阶段，需要将各个组成部分集成在一起，并进行验证以确保整个系统按预期工作。这包括在系统级别进行功能测试、性能测试、安全性测试等，以确保系统满足其设计要求和目标。

#03

SYS.1 Requirements Elicitation

需求获取；

在系统开发的整个生命周期内，开发者面临的一个重要任务就是不断地收集、深入分析和持续追踪相关方的需求与要求。这里的相关方可能包括产品、企划、硬件团队以及其他内部团队等多个方面。这一过程的目的是为了确保系统能够始终与收到的实际需求保持同步，同时满足各方相关者的期望和标准。

对应这一部分的开发者，需要完成四项BP（Base Practices 基础实践；ASPICE各项流程均定义了不同的BP，需要开发者遵守并完成）：

1. Obtain stakeholder expectations and requests. 获取相关方的期望和要求。

通过直接征求相关方（其实就是指需求提出方）的意见、审查相关的提案（如适用）和其他包含相关方需求的文件，并考虑目标操作和硬件环境，来获取并明确相关方的期望和要求。

2. Agree on requirements. 达成一致需求

将相关者的期望转化为要求，并确保所有受影响方对此达成共识。

3. Analyze stakeholder requirements changes. 分析需求的变更

针对已经达成一致的需求，分析相关者进一步输入要求所做的更改。评估其影响和风险，并启动适当的变更措施。

4. Communicate requirements status. 沟通需求状态

确保所有相关方都能了解他们的要求（包括变更）的状态和处理情况，并能够交流必要的信息和数据。

假设一个汽车项目正在开发一个智能驾驶辅助系统，SYS1阶段可能输出的内容包括：

客户要求系统能够在不同光照和天气条件下准确识别道路标线和车辆。

法律法规要求系统必须符合特定的安全标准和隐私保护规定。

供应商提出系统需要能够与现有的车辆控制系统集成。

#04

SYS.2 System Requirements Analysis

系统需求分析；

其核心目的在于确保所建立的系统需求集合是结构化的、经过详细分析的，并且这些需求与项目相关方的实际要求完全吻合。这样不仅能够确保系统的开发方向正确，还能有效提升系统的实用性和满意度，满足相关方的期望和需求。因此，在进行系统需求分析时，我们需要深入理解相关方的要求，将其转化为具体、可操作的系统需求，从而为系统的后续开发和实施奠定坚实的基础。

该过程的输入来源于SYS.1；

六个BP说明如下：

1. Specify system requirements. 定义系统需求

在开发系统的过程中，我们首先需要明确并理解相关方的各种要求。这些相关方可能包括用户、客户、管理层、开发人员等。他们的需求是系统设计和开发的基础。这一部分应该在SYS.1中就完成了；

接下来，我们需要根据已经定义好的需求特性，对这些要求进行细致的分析。这些特性可能涵盖了需求的优先级、可行性、可测试性等多个方面。

2. Structure system requirements. 结构化系统需求

结构化系统需求的过程，实际上是对需求进行细分和定义的过程。我们需要将大的、笼统的需求拆分成小的、具体的、可实现的子需求。这样做不仅有助于我们更深入地理解系统需求，还能为后续的开发工作提供明确的指导。

3. Analyze system requirements. 分析系统需求

对于系统工程师来说，对系统需求的准确分析是至关重要的。这要求我们对指定的系统需求进行深入的研究，不仅要理解每一个需求的具体内容，还要分析它们之间的相互依赖关系。这种相互依赖关系可能表现为某个需求的实现依赖于另一个需求的完成，或者两个需求之间存在某种逻辑上的联系。

通过详细分析这些需求及其相互依赖关系，我们可以确保需求的正确性。这意味着我们需要验证需求是否完整、清晰，并且没有自相矛盾的地方。同时，我们还要评估这些需求是否可以在现有的技术条件下实现，即检查它们的技术可行性。这是确保项目能够顺利进行，避免后期出现技术难题的关键步骤。

4. Analyze the impact on the system context. 分析需求在系统中的影响

分析系统需求对相关系统环境中各要素的影响，是一个深入且细致的过程。在这个过程中，我们需要全面考虑系统需求与其运行环境之间的相互作用和关联。

首先，我们要明确系统需求的具体内容，这包括系统的功能性需求、性能需求、安全需求等各个方面。这些需求是系统设计和开发的基础，也是后续分析和评估的出发点。

接着，我们需要识别相关系统环境中的关键要素。这些要素可能包括硬件资源、软件平台、网络环境、用户群体等。每个要素都与系统需求之间存在着直接或间接的联系，它们的状态和变化都可能对系统需求的实现产生影响。

然后，我们深入分析系统需求对这些关键要素的具体影响。例如，系统对硬件资源的需求可能会影响设备的选择和配置；对软件平台的需求可能会影响操作系统的选择和应用程序的开发；对网络环境的需求可能会影响网络架构的设计和带宽的分配；对用户群体的需求可能会影响用户界面的设计和用户体验的优化。

5. Ensure consistency and establish bidirectional traceability. 确保一致性和双向可追溯性

建立双向可追溯性也是确保需求管理有效性的关键。一方面，从系统需求可以追溯到相关方需求，这有助于我们理解每个系统需求背后的原因和目的，以及它们如何满足相关方的期望。另一方面，从相关方需求也可以追溯到系统需求，这可以确保我们没有遗漏任何重要的相关方需求，并且这些需求已经在系统设计中得到了充分的体现。

6. Communicate agreed system requirements and impact on the system context. 与利益相关者对系统需求及其影响沟通达成一致

这一BP就是要将已达成一致的系统需求以及系统影响分析的结果传达给所有受影响的各方。

比如针对SYS1收集到的系统需求，做出如下部分的SYS2分析输出结果：

1)设计图像处理和识别算法，该算法能够适应不同的光照条件（如强光、弱光、逆光等）和天气条件（如雨、雾、雪等）；

2)选择或设计合适的传感器（如摄像头、雷达等），以确保在各种条件下都能获取到清晰的道路和车辆图像；

3)设计系统架构，确保图像处理和识别算法能够高效地运行，并实时输出识别结果；

4)设计数据加密和隐私保护机制，确保系统采集和处理的图像数据不会被非法访问或滥用；

5)设计系统接口，以确保能够与现有的车辆控制系统（如发动机控制系统、刹车系统、转向系统等）无缝集成。

#05

SYS.3 System Architectural Design

系统架构设计；

系统架构设计过程旨在建立一个与系统需求一致的且分析过的系统架构，包括静态和动态方面；

输入来源于SYS.1与SYS.2；

同样包含5个BP：

1. Specify static aspects of the system architecture.定义静态的系统架构

在系统架构中，针对功能性和非功能性系统需求，明确并记录其静态方面的特征，这是至关重要的步骤。这包括详细阐述外部接口以及定义一组系统元素，同时明确这些系统元素各自的接口、它们之间的关系。简而言之，此过程要求我们对系统架构中的固定不变的部分进行详尽的规范和记录，这些部分既涉及满足系统功能需求的结构设计，也涵盖那些满足非功能需求（如性能、安全性、可扩展性等）的架构设计。外部接口定义了系统与外部环境之间的交互方式，而系统元素的定义及其接口和关系的明确，则有助于我们理解和构建系统内部各组件之间的连接和协作。通过这样的工作，我们能够确保系统架构设计既满足当前的功能需求，又具备适应未来变化的能力，同时确保系统的整体性能和稳定性。

2. Specify dynamic aspects of the system architecture. 定义动态的系统架构

系统架构的动态方面主要涉及系统元素的行为以及它们在不同系统模式下的交互方式。系统元素可以是硬件组件、软件模块或数据流程等。了解这些元素如何协同工作，以及它们在不同情境下的行为模式，对于确保系统的稳定运行和满足用户需求至关重要。

3. Analyze system architecture. 分析系统架构

系统架构的分析将围绕产品生命周期的各个阶段展开，包括需求分析、设计、开发、测试、部署以及维护等。在这一过程中，我们将关注与产品生命周期紧密相关的技术设计要素，如系统的可扩展性、稳定性、安全性以及易用性等。通过对这些要素的综合考虑，我们可以为项目管理提供准确的项目估算，确保项目能够按时、按质、按量完成。

4. Ensure consistency and establish bidirectional traceability. 确保一致性并建立双向可追溯性

在系统设计与开发过程中，确保系统架构的各个组成部分与系统的实际需求之间保持高度的一致性至关重要。这些系统需求通常反映了最终产品关键属性或特性。为了有效地管理这一过程，必须建立一种机制，使得系统架构中的每一个元素都能与相应的系统需求建立直接的联系。

5. Communicate agreed system architecture. 沟通商定的系统架构

有效的沟通不仅有助于确保各方对系统架构有共同的理解，还能促进合作，减少误解和冲突，从而推动项目的顺利进行。

针对SYS2中分析的前几点系统需求，SYS3的输出应该详细描述图像处理和识别算法、传感器以及系统架构的具体实现步骤、测试验证和性能评估等内容。这些实现内容应该与SYS2中的设计内容紧密对应，并确保系统在实际应用中能够满足设计要求。

#06

SYS.4 System Integration and Integration Verification

系统集成和集成验证；

这一环节目的是集成系统元素，并验证集成的系统元素是否与系统架构一致；

该流程含有5个BP：

1. Specify verification measures for system integration. 明确系统集成验证措施

在系统集成过程中，需要明确指定验证措施，这些措施需基于已定义的顺序和前提条件，以针对系统架构的静态和动态方面进行验证。具体而言，验证措施应包括以下几个方面：

首先，要明确验证所采用的技术手段。这些技术手段可以是测试工具、模拟软件或实验装置等，用于对系统元素进行验证，确保其满足设计要求。

其次，要设定验证措施的通过/失败标准。这些标准用于评估验证结果，判断系统元素是否达到预期的性能和功能要求。通过明确的标准，可以确保验证过程的客观性和准确性。

此外，还需定义验证措施的进入和退出标准。进入标准是指开始验证前必须满足的条件，如系统元素已准备就绪、测试环境已搭建等。退出标准则是指验证结束后达到的条件，如验证结果符合预期、问题已得到解决等。这些标准的设定有助于确保验证过程的有序进行。

2. Select verification measures. 选择验证措施

在选择验证措施时，我们不仅要关注当前集成步骤的特定需求，还要全面考虑整个系统的稳定性和可靠性。记录下来的验证措施选择应当详细、准确，并能够清晰地反映出我们是如何根据发布范围的需求和回归验证的标准来做出决策的。这样一来，我们就可以确保每个集成步骤都得到了充分的验证，从而有效地降低系统发布后出现问题的风险。

3. Integrate system elements and perform integration verification. 集成系统元素并执行集成验证

在系统集成的过程中，需要按照系统元素之间指定的接口和交互方式，以及已经定义的顺序和前提条件，逐步整合各个系统元素，直至整个系统实现完全集成。在系统集成完成后，需要执行选定的系统集成验证措施。这些验证措施可能包括功能测试、性能测试、安全测试等，旨在全面评估系统的集成效果，确保其满足设计要求。在验证过程中，需要记录详细的验证措施数据，包括每项验证措施是否通过（即合格/不合格状态），以及对应的验证数据。

4. Ensure consistency and establish bidirectional traceability. 确保一致性，建立双向可追溯性

在验证过程中，每一项验证措施都应能够清晰地映射到系统架构中的对应部分，同时，系统架构中的每一个关键元素也应能够被追踪到相应的验证措施上。这种双向可追溯性的建立，有助于确保验证工作的全面性和准确性。

5. Summarize and communicate results. 总结并交流结果

需要对系统集成的结果以及验证的结果进行概括总结，并将这些总结信息传达给所有关联方。

所要验证的对象来自于SYS.3的输出；

根据BP，实际操作流程可以如下：

1 收齐输入物，即SYS.2需求，与SYS.3系统架构

2 搭建测试环境

3 导入测试用例

4 执行测试，按照测试case执行测试，记录测试结果；

5 针对测试结果及覆盖度结果补充测试用例；分析测试结果，同步的检查测试用例制定的完整性；

6 回归测试；反馈测试NG项，待系统修改后回归测试

完整的流程过程物/输出物应该还包含详细的测试计划、测试报告分析等内容。

#07

SYS.5 System Verification

系统验证；

这一环节目的是确保系统经过验证符合系统需求。

该环节输入主要是SYS1的输出；

该流程含有五个BP，这五个BP与SYS.4基本一致：

1.Specify verification measures for system verification. 定义系统验证的验证措施。

2.Select verification measures. 选择验证措施。

3.Perform verification of the integrated system. 对集成系统进行验证。

4.Ensure consistency and establish bidirectional traceability. 确保一致性和双向可追溯性。

5.Summarize and communicate results. 总结和沟通结果。

SYS.4与SYS.5均是做软件验证，区别就是侧重点不一样：

SYS.4侧重于系统集成和集成测试的实施，确保系统组件之间的接口连接和通信以及整体功能和性能；

而SYS.5则侧重于系统合格性测试的计划、执行和结果评估，以确保系统在实际运行环境中能够满足预定的质量和性能要求。

#08

总结

ASPICE是一个全面且细致的软件开发评估体系，它涵盖了从需求挖掘到系统合格性测试的软件开发生命周期的各个阶段，确保过程的全面性和完整性。该体系针对系统到软件的需求、设计、测试等流程提出了详细要求，以保障每个环节得到充分关注和执行。此外，ASPICE还强调建立双向可追溯性，确保需求、设计、测试等环节间的一致性和关联性，这点无论是在SWE Process还是SYS Process都有极强的体现，从而有助于覆盖率、一致性和影响分析的实现。

/ END /

登录阅读全文

