最新资讯
随着汽车行业电动化、智能化、网联化的发展，车辆中电子电气系统的数量急剧增加，软件在车辆功能中的占比日益提升。车规级项目对软件质量、功能安全的要求愈发严格。ASPICE 3.1 作为汽车行业软件开发过程改进和能力评定的标准，为软件开发提供了过程框架和质量保障；ISO 26262:2018 作为汽车功能安全国际标准，旨在降低因电子电气系统故障导致的风险。将两者融合实施，可实现软件开发过程与功能安全要求的有机结合，提升软件质量和安全性，满足车规级项目的严格需求。
ASPICE 3.1 要求
明确项目目标和范围，确定软件产品的功能和特性。
识别项目干系人，建立有效的沟通机制。
ISO 26262:2018 要求
确定相关项定义，辨识由相关项功能异常表现导致的危险事项。
采用 FMEA、HAZOP、头脑风暴等方式进行危险辨识与危险性评价，按照严重程度、暴露机率与可控性设定 ASIL 级别。
根据安全目标分解出相应 ASIL 等级的安全需求。
融合实施
在明确项目目标和范围时，充分考虑功能安全需求，将安全目标纳入项目整体目标。
干系人识别过程中，纳入功能安全专家，确保功能安全需求在项目沟通中得到有效传递。
输出相关项定义、HARA 分析报告及干系人需求说明书，干系人需求说明书涵盖安全需求，并使用需求管理工具（如 PTC Integrity）进行需求记录、状态管理和实现情况跟踪。
ASPICE 3.1 要求
对需求进行分类分析，明确功能需求、非功能需求和接口需求。
组织专家评审，确定需求的正确性和可验证性。
分析系统需求的优先级，明确实现顺序。
建立客户需求和系统需求的双向追踪关系。
ISO 26262:2018 要求
将干系人需求和安全需求分解成技术需求，定义用于探测故障并防止或减轻系统输出端违反功能安全要求失效的安全机制。
建立系统架构，将安全要求分配给系统各要素，进行需求安全等级分解，明确各条目需求的 ASIL 等级。
对子系统进行安全分析，避免系统性失效。
融合实施
在需求分类分析时，将安全需求作为重要类别单独分析，确保其正确性和可验证性。
需求评审过程中，邀请功能安全专家参与，从功能安全角度评估需求。
建立需求追踪矩阵时，同时追踪功能需求和安全需求，确保安全需求在系统架构中得到落实。
采用结构分析法进行系统架构设计，明确系统各组件之间的程序流和数据流，输出系统需求、系统架构及系统独立失效分析报告，架构设计采用工具如 ENTERPRISE ARCHITECT。
ASPICE 3.1 要求
将系统需求转变为软硬件需求。
分析软件需求之间的依赖关系，保证需求的正确性、技术可行性及可验证性。
构建与系统需求的一致性和可追溯性。
ISO 26262:2018 要求
根据系统需求和安全需求，开发满足软硬件安全要求和其他要求的软件架构设计和硬件架构设计。
对软件架构进行安全分析。
融合实施
在软硬件需求分析过程中，充分考虑安全需求，确保软硬件需求满足功能安全要求。
建立软硬件需求与系统需求的追溯关系，使用需求管理工具进行管理。
输出软件需求、硬件需求、软件架构及架构安全分析报告，明确软件架构和硬件架构设计原则。
ASPICE 3.1 要求
根据软硬件需求进行硬件设计、软件详细设计、代码开发。
代码设计遵循模块化设计思路，将程序软件划分成独立子功能的模块，然后将模块集成形成整体软件程序。
ISO 26262:2018 要求
确保软件开发过程符合功能安全要求，避免引入安全隐患。
融合实施
在详细设计和代码开发过程中，遵循 ASPICE 3.1 的模块化设计原则，同时考虑功能安全要求。
对关键代码和模块进行安全审查，确保其满足相应的 ASIL 等级要求。
代码和模型开发采用工具如 MATLAB/Simulink。
ASPICE 3.1 要求
定义软件单元测试规范，明确单元测试的技术和方法。
制定单元测试验证计划模板及测试报告模板。
软件单元测试包括静态测试和动态测试。
ISO 26262:2018 要求
验证安全机制在故障注入、随机硬件失效、系统级容错等场景下仍能满足 ASIL 等级目标。
融合实施
在单元测试规范中，明确安全功能测试用例的设计要求，确保覆盖安全相关需求。
静态测试借助常用工具（如 Model Analysis、QAC）进行代码静态分析和模型代码审核，依据专家编写的代码或模型 Checklist 进行审核。
动态测试前设计测试案例，基于设计说明或设计模型期望输入输出信号，根据需求分析、等价类的生成和分析、边界值分析、经验等进行开展，测试类型包括基于需求的试验、接口测试、故障注入试验和背靠背的试验等，输出单元测试报告。
硬件调试阶段对硬件模块实施调试，按照调试清单进行调试，调试清单由硬件设计相关专家编写，产出硬件调试报告。
ASPICE 3.1 要求
根据系统需求编写系统测试用例，编制系统测试计划。
通过 HILL 台架或者发动机试验台架开展系统测试，输出系统测试报告。
根据客户需求编写整车验证用例，编制整车验证计划，利用整车资源开展整车验证，输出整车验证报告。
ISO 26262:2018 要求
验证系统在故障条件下的安全行为，确保满足功能安全要求。
融合实施
在系统测试和整车验证用例中，增加安全功能测试用例，确保全面验证系统的功能安全。
使用集成测试工具（如 CANoe、dSPACE）进行测试，实现功能安全与功能需求的自动化验证。
输出系统测试报告和整车验证报告时，同时包含功能安全和功能需求的测试结果。
提升软件质量和安全性
通过融合实施，软件开发过程严格遵循 ASPICE 3.1 标准，确保了软件开发的规范性和可重复性。同时，功能安全要求在各个阶段得到有效落实，降低了软件故障导致的安全风险，提升了软件的整体质量和安全性。
提高开发效率
统一的标准和流程避免了重复工作和沟通成本，提高了开发团队的协作效率。需求追溯和测试验证的自动化工具应用，进一步缩短了开发周期，提高了开发效率。
增强市场竞争力
满足车规级项目对软件质量和功能安全的严格要求，使产品更具市场竞争力。获得 ASPICE 3.1 认证和 ISO 26262:2018 符合性声明，有助于提升企业品牌形象，赢得客户信任。
人员能力要求高
融合实施需要开发人员既具备扎实的软件开发技能，又熟悉功能安全标准和要求。培养既懂 ASPICE 过程改进又懂 ISO 26262 功能安全的复合型人才是一大挑战。
工具链整合难度大
实现需求管理、测试验证、文档管理等工具的数据流打通，避免信息孤岛，需要投入大量的时间和精力进行工具选型、集成和配置。
成本投入增加
融合实施需要增加安全分析、测试验证等环节的成本，包括购买工具、培训人员、开展额外测试等方面的费用，对企业的资源投入提出了更高要求。
车规级项目中 ASPICE 3.1 与 ISO 26262:2018 的融合实施是可行且必要的。通过建立融合实施框架，在各个开发阶段将两者有机结合，可以有效提升软件质量和安全性，提高开发效率，增强市场竞争力。然而，融合实施也面临着人员能力、工具链整合和成本投入等方面的挑战。
分阶段推进融合实施
企业可以根据自身实际情况，优先在关键项目或关键模块中试点融合实施，积累经验后再逐步扩展至全组织。
加强人员培训和能力建设
制定系统的培训计划，加强对开发人员的 ASPICE 过程改进和 ISO 26262 功能安全培训，提高人员的综合能力。
选择合适的工具链并进行有效整合
在选择工具时，充分考虑工具的功能、兼容性和易用性，确保工具能够满足融合实施的需求。同时，投入资源进行工具链的整合和优化，提高工具的使用效率。
合理控制成本
在融合实施过程中，进行成本效益分析，合理规划资源投入。优先保障关键环节的成本需求，避免不必要的浪费。
推荐阅读：
亚远景-ASPICE在供应链管理中的角色：如何利用标准评估和选择供应商
亚远景-从仿真测试到实车验证：ISO/PAS 8800 的测试策略
亚远景-ASPICE评估：汽车软件开发过程评估的方法与经验总结
亚远景-ISO/PAS 8800与全球汽车AI监管趋同下的中国企业合规策略与技术适配
推荐服务：
点击查看亚远景ASPICE、ISO26262实施工具-APMS研发过程管理平台
