ISO 26262-6-2018 中文版 道路车辆 - 功能安全 第 6 部分：产品开发 at 软件层面

ISO26262-6:2018中文版道路车辆—功能安全第6部分：产品开发at软件层面前言本标准为ISO26262系列标准的第6部分，对应国际标准ISO26262-6:2018《Roadvehicles—Functionalsafety—Part6:Productdevelopmentatthesoftwarelevel》，本中文版为等同采用该国际标准的中文翻译版本，无技术性差异。ISO26262系列标准是国际标准化组织（ISO）针对道路车辆电气电子（E/E）系统功能安全制定的专项标准，源于IEC61508系列标准的汽车行业适配与优化，旨在为道路车辆安全相关E/E系统的全生命周期提供系统化、可追溯、可验证的功能安全开发与管理框架，降低因E/E系统故障导致的车辆安全风险。本部分作为系列标准的核心模块之一，专门聚焦软件层面的产品开发，明确了软件从需求定义到验证确认的全流程要求，适用于所有批量生产道路车辆（不包括轻便摩托车）的安全相关E/E系统软件开发，是汽车行业软件功能安全合规的核心依据。本标准发布于2018年12月，正式实施日期与发布日期一致，替代了2011年发布的ISO26262-6:2011版本，在适用范围、技术要求、验证方法等方面进行了技术性修订，新增了对卡车、客车、挂车等车辆类型的覆盖，完善了可配置软件的使用要求，优化了ASIL等级相关的开发流程，使其更贴合当前汽车智能化、网联化的发展趋势。本标准的实施，对于规范汽车软件功能安全开发流程、提升软件产品可靠性、保障车辆行驶安全具有重要意义，同时也为汽车整车企业、零部件供应商提供了统一的软件功能安全开发准则，助力企业满足全球汽车市场的功能安全准入要求。国内相关标准GB/T34590.6-2022《道路车辆功能安全第6部分：产品开发：软件层面》修改采用本标准，进一步推动了我国汽车软件功能安全与国际接轨。1范围本标准规定了道路车辆安全相关电气电子（E/E）系统在软件层面的产品开发要求，涵盖软件开发的全生命周期，包括软件需求规范、软件架构设计、软件单元设计与实现、软件单元验证、软件集成与验证、嵌入式软件测试等核心环节，同时明确了与可配置软件使用相关的特殊要求。本标准适用于包含一个或多个E/E系统、安装在批量生产道路车辆（不包括轻便摩托车）中的安全相关系统，不适用于特种车辆中独特的E/E系统（如为残疾驾驶员设计的E/E系统）。对于本标准发布前已投入生产或已启动开发的系统及其组件，不纳入本版本的适用范围；但本标准可通过定制安全生命周期，解决对这类现有系统及其组件的变更问题，以及未按本标准开发的现有系统与按本标准开发的系统的集成问题。本标准重点解决由安全相关E/E系统故障行为（包括系统间交互故障）可能引发的危险，不涉及电击、火灾、烟雾、热辐射、毒性、可燃性等与E/E系统故障行为无直接关联的危险。本标准描述的功能安全框架，可用于将功能安全活动集成到企业特定的开发框架中，其中部分要求聚焦技术实现，确保功能安全嵌入产品本身；另一部分要求聚焦开发过程，用于证明组织在功能安全方面的能力。需要注意的是，本标准不涉及E/E系统的标称性能要求。本标准的要求可结合具体项目的实际情况进行裁剪，但裁剪过程需遵循ISO26262系列标准的相关规定，确保裁剪后仍能满足功能安全目标，且裁剪理由需形成正式文档并可追溯。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件；凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO26262-1:2018道路车辆—功能安全第1部分：词汇ISO26262-2:2018道路车辆—功能安全第2部分：功能安全管理ISO26262-3:2018道路车辆—功能安全第3部分：概念阶段ISO26262-4:2018道路车辆—功能安全第4部分：产品开发at系统层面ISO26262-5:2018道路车辆—功能安全第5部分：产品开发at硬件层面ISO26262-7:2018道路车辆—功能安全第7部分：生产、运行、服务和退役ISO26262-8:2018道路车辆—功能安全第8部分：支持过程ISO26262-9:2018道路车辆—功能安全第9部分：ASIL导向与安全导向的开发3术语和定义本标准采用ISO26262-1:2018中定义的所有术语和定义，同时补充以下术语和定义，适用于本部分。3.1软件安全要求（SoftwareSafetyRequirement,SSR）：为实现安全目标，针对软件层面提出的具体要求，包括功能要求、性能要求、接口要求、容错要求等，需明确对应的ASIL等级，确保软件行为不引发危险。3.2软件架构设计（SoftwareArchitecturalDesign,SAD）：将软件安全要求转化为可执行的软件架构，明确软件模块划分、模块间接口、数据流向、安全机制部署等内容，是软件详细设计的基础。3.3软件单元（SoftwareUnit）：软件架构中可独立设计、实现、测试的最小功能模块，是软件集成的基础单元，通常对应一个或多个函数、子程序或类。3.4软件单元验证（SoftwareUnitVerification）：对软件单元的设计和实现进行检查和测试，确保其符合软件详细设计要求和编码规范，无系统性缺陷。3.5软件集成（SoftwareIntegration）：将多个软件单元按照软件架构设计的要求组合成完整的软件系统，逐步集成、逐步测试，确保模块间接口兼容、数据交互正常。3.6静态分析（StaticAnalysis）：不执行软件代码，通过工具或人工检查代码结构、语法、逻辑等，识别潜在的代码缺陷（如缓冲区溢出、未初始化变量等），主要用于软件单元验证和集成验证阶段。3.7动态分析（DynamicAnalysis）：通过执行软件代码，观察软件运行状态和输出结果，验证软件是否符合需求要求，包括基于需求的测试、接口测试、故障注入测试等。3.8结构覆盖率（StructuralCoverage）：用于度量测试用例对软件代码的覆盖程度，包括语句覆盖率、分支覆盖率、MC/DC（修改/判定条件覆盖率）等，是评估软件验证完整性的重要指标。3.9可配置软件（ConfigurableSoftware）：可通过参数配置、模块选择等方式适配不同应用场景或需求的软件，其配置过程需满足功能安全要求，确保配置结果的正确性和安全性。4软件开发的一般要求软件层面的产品开发需遵循ISO26262系列标准的整体要求，建立完整的软件安全生命周期，确保软件开发过程的可追溯性、可验证性和可控性。软件开发需与系统层面、硬件层面的开发同步进行，实现各层面的协同配合，避免出现设计冲突或安全漏洞。软件开发需基于概念阶段和系统层面开发输出的结果，包括安全目标、技术安全概念、系统需求等，确保软件需求与系统需求保持一致，软件设计与系统架构相适配。在软件开发的每个阶段，需明确责任分工，建立独立的验证和确认机制，及时发现并纠正设计和实现中的缺陷。针对不同ASIL等级的软件，需采取对应的开发措施和验证强度：ASIL等级越高，开发过程的严格程度、验证的完整性要求越高。对于ASILB及以上等级的软件，需实施更严格的配置管理、变更管理和文档管理，确保软件开发过程的可追溯性和安全性。软件开发过程中使用的工具（如建模工具、编码工具、测试工具等）需进行资格认证，确保工具的可靠性和适用性，避免因工具缺陷导致软件安全问题。工具资格认证的程度需根据工具使用场景的ASIL等级确定，ASIL等级越高，工具资格认证的要求越严格。软件开发团队需具备相应的功能安全能力，团队成员需接受功能安全培训，熟悉ISO26262系列标准的要求，掌握软件安全开发的方法和技术。对于ASILD等级的软件，需配备独立的安全经理和安全评估人员，负责监督软件开发过程的合规性和安全性。5软件安全需求规范软件安全需求规范是软件开发的基础，需基于系统层面的技术安全概念和系统需求，结合软件层面的特性，明确软件需实现的安全功能和性能要求，确保软件能够支持安全目标的实现。软件安全需求需具备明确性、可验证性、可追溯性和完整性：明确性要求需求描述清晰、无歧义，避免模糊不清的表述；可验证性要求每个需求都能通过测试、分析等方式进行验证，确保其能够被实现和满足；可追溯性要求每个软件安全需求都能追溯到系统需求、技术安全概念和安全目标，同时后续的设计、实现、测试等活动都能追溯到对应的软件安全需求；完整性要求软件安全需求覆盖所有与软件相关的安全目标，无遗漏。软件安全需求需明确对应的ASIL等级，根据ASIL等级确定需求的优先级和验证要求。对于ASIL分解后的需求，需明确分解后的子需求对应的ASIL等级，以及子需求之间的独立性要求，避免共因失效导致安全目标无法实现。软件安全需求应包括以下内容：软件的功能安全要求，即软件需实现的安全功能（如故障检测、故障隔离、容错等）；软件的性能安全要求，即软件的响应时间、处理能力等性能指标需满足安全需求，避免因性能不足导致危险；软件的接口安全要求，即软件与硬件、软件与其他软件模块之间的接口定义、数据交互规则等，确保接口通信的安全性和可靠性；软件的容错要求，即软件在出现故障时，能够采取有效的容错措施，避免故障扩散，确保系统仍能维持安全状态；软件的环境适应性要求，即软件在不同的运行环境（如温度、电压、电磁干扰等）下，仍能正常实现安全功能。软件安全需求规范需经过评审，评审人员包括软件开发人员、验证人员、安全经理等，确保需求的合理性、完整性和可实现性。评审意见需形成文档，对于评审中发现的问题，需及时修改完善软件安全需求规范，并重新进行评审，直至满足要求。6软件架构设计软件架构设计是将软件安全需求转化为具体软件结构的过程，需基于软件安全需求规范，结合系统架构设计的要求，设计出具有良好安全性、可维护性和可扩展性的软件架构。软件架构设计需遵循模块化、分层设计的原则，将软件划分为多个独立的模块，每个模块负责实现特定的功能，模块之间通过明确的接口进行通信，减少模块之间的耦合度，便于模块的独立设计、实现和测试。同时，软件架构需考虑故障隔离和容错机制，确保某个模块出现故障时，不会影响其他模块的正常运行，也不会导致安全目标无法实现。软件架构设计需明确模块的划分、模块的功能职责、模块间的接口定义、数据流向、安全机制的部署等内容。其中，安全机制的部署需根据软件安全需求和ASIL等级确定，包括故障检测机制、故障诊断机制、故障隔离机制、容错机制等，确保软件能够及时发现和处理故障，避免危险发生。对于ASILB及以上等级的软件，软件架构设计需进行安全性分析，包括故障树分析（FTA）、失效模式与影响分析（FMEA）等，识别软件架构中可能存在的安全漏洞和风险，提出改进措施，确保软件架构的安全性。安全性分析结果需形成文档，作为软件架构设计评审的重要依据。软件架构设计文档需经过评审，评审内容包括架构的合理性、安全性、可实现性、可维护性等，评审人员需包括软件开发人员、验证人员、系统工程师、安全经理等。评审中发现的问题，需及时修改软件架构设计，并重新进行评审，直至满足要求。软件架构设计文档需与软件安全需求规范保持一致，确保每个软件安全需求都能在软件架构中得到体现和实现。7软件单元设计与实现软件单元设计与实现是软件架构设计的细化和落地过程，需基于软件架构设计文档，对每个软件单元进行详细设计，并按照编码规范实现软件单元，确保软件单元能够满足软件架构设计和软件安全需求的要求。软件单元详细设计需明确软件单元的内部结构、算法、数据结构、接口实现细节等内容，设计方案需具备可实现性、可测试性和安全性。对于复杂的软件单元，需进行设计仿真，验证设计方案的正确性和合理性。软件单元详细设计文档需经过评审，确保设计方案符合要求，评审通过后，方可进入编码阶段。编码阶段需遵循统一的编码规范，编码规范需结合汽车软件的特点，明确编程语言的选择、代码编写规则、命名规则、注释规则等，避免因编码不规范导致的代码缺陷。编程语言的选择需考虑安全性和可靠性，优先选择经过验证、适合汽车安全相关软件的编程语言（如C语言、C++语言等），避免使用具有安全隐患的编程语言或编程特性。编码过程中，需采取有效的措施避免常见的代码缺陷，如缓冲区溢出、未初始化变量、空指针引用、数组越界等。对于ASILC及以上等级的软件，需采用静态分析工具对代码进行实时分析，及时发现代码中的潜在缺陷，并进行修改。编码完成后，需对代码进行格式化和注释，确保代码的可读性和可维护性。对于可配置软件，其配置逻辑和配置参数的实现需满足软件安全需求，确保配置过程的正确性和安全性。配置参数需进行严格的验证，避免因配置错误导致软件故障。同时，需建立配置管理机制，对配置参数进行版本控制，确保配置的可追溯性。软件单元实现完成后，需进行单元自测，开发人员需对自己编写的软件单元进行测试，验证其是否符合详细设计要求和编码规范，确保软件单元能够正常运行。自测通过后，方可提交进行软件单元验证。8软件单元验证软件单元验证的目的是验证软件单元的设计和实现是否符合软件单元详细设计要求、编码规范和软件安全需求，识别软件单元中的缺陷并进行纠正，确保软件单元的安全性和可靠性。软件单元验证需采用静态分析和动态分析相结合的方式进行。静态分析主要用于检查软件单元的代码结构、语法、逻辑等，识别潜在的代码缺陷，常用的方法包括代码走查、技术评审、静态代码分析等。静态代码分析需使用经过资格认证的静态分析工具，按照预设的编码规范和缺陷规则进行分析，生成静态分析报告，对于发现的缺陷，需及时进行修改，并重新进行静态分析，直至无严重缺陷。动态分析主要用于验证软件单元的功能和性能是否符合要求，常用的方法包括单元测试、接口测试等。单元测试需根据软件单元详细设计要求和软件安全需求，设计测试用例，测试用例需覆盖软件单元的所有功能点和边界条件，确保测试的完整性。对于ASIL等级不同的软件单元，测试覆盖率的要求不同：ASILA等级软件单元需满足语句覆盖率和分支覆盖率要求；ASILB及以上等级软件单元需满足MC/DC覆盖率要求，其中ASILD等级软件单元的MC/DC覆盖率需达到100%。测试用例的设计需遵循等价类划分、边界值分析、错误推测法等原则，确保测试用例的有效性和针对性。测试过程中，需记录测试结果，对于测试中发现的缺陷，需进行跟踪和管理，明确缺陷的严重程度、整改责任人及整改期限，整改完成后，需进行回归测试，确保缺陷已被彻底纠正，且未引入新的缺陷。软件单元验证完成后，需形成软件单元验证报告，报告内容包括验证对象、验证方法、测试用例、测试结果、缺陷统计及整改情况等，确保验证过程的可追溯性。软件单元验证报告需经过评审，评审通过后，软件单元方可进入软件集成阶段。9软件集成与验证软件集成与验证是将多个经过验证的软件单元按照软件架构设计的要求组合成完整软件系统，并验证软件系统的功能、性能、接口等是否符合软件安全需求和软件架构设计要求的过程。软件集成与验证需遵循“逐步集成、逐步测试”的原则，避免一次性集成所有软件单元，便于及时发现和解决集成过程中的问题。软件集成需按照软件架构设计的模块依赖关系，分阶段进行集成：首先集成基础模块，验证基础模块的功能和接口；然后逐步集成其他模块，每次集成后，都需进行集成测试，验证新增模块与已集成模块之间的接口兼容性、数据交互正确性等。集成过程中，需记录集成过程和出现的问题，及时进行排查和解决，确保集成过程的顺利进行。软件集成验证包括功能验证、性能验证、接口验证、安全机制验证等内容。功能验证需验证软件系统的整体功能是否符合软件安全需求，确保软件系统能够实现预设的安全功能；性能验证需验证软件系统的响应时间、处理能力、资源占用（如CPU、RAM、ROM等）等性能指标是否满足要求，避免因性能不足导致软件故障；接口验证需验证软件系统与硬件、软件系统与其他软件模块之间的接口通信是否正常，数据交互是否准确；安全机制验证需验证软件系统中的故障检测、故障隔离、容错等安全机制是否有效，确保软件系统在出现故障时能够及时采取措施，避免危险发生。软件集成验证需采用静态分析和动态分析相结合的方式，其中动态分析包括集成测试、系统测试、故障注入测试等。故障注入测试需模拟软件系统可能出现的故障（如硬件故障、软件模块故障等），验证软件系统的容错能力和故障处理能力，确保软件系统在故障情况下仍能维持安全状态。对于ASILB及以上等级的软件系统，故障注入测试的覆盖率需满足相关要求，确保所有关键故障场景都能被覆盖。软件集成验证完成后，需形成软件集成验证报告，报告内容包括集成过程、验证方法、测试用例、测试结果、缺陷统计及整改情况等。软件集成验证报告需经过评审，评审通过后，软件系统方可进入嵌入式软件测试阶段。10嵌入式软件测试嵌入式软件测试是在目标硬件环境下，对软件系统进行全面测试，验证软件系统与硬件的兼容性、软件系统在实际运行环境中的性能和安全性，确保嵌入式软件能够满足道路车辆的实际运行需求。嵌入式软件测试需在目标硬件平台上进行，测试环境需模拟车辆的实际运行环境，包括温度、电压、电磁干扰等环境因素，确保测试结果的真实性和有效性。测试前，需对测试环境进行检查和校准，确保测试设备的正常运行和测试数据的准确性。嵌入式软件测试包括功能测试、性能测试、可靠性测试、安全性测试等内容。功能测试需验证嵌入式软件在目标硬件环境下的功能是否正常，是否符合软件安全需求；性能测试需验证嵌入式软件在实际运行环境中的响应时间、处理能力、资源占用等性能指标是否满足要求，确保软件在不同运行场景下都能稳定运行；可靠性测试需验证嵌入式软件在长时间运行过程中的稳定性和可靠性，避免出现死机、崩溃等故障；安全性测试需验证嵌入式软件在出现硬件故障、电磁干扰等异常情况下的安全性能，确保软件能够及时发现和处理异常，避免危险发生。嵌入式软件测试的测试用例需基于软件安全需求和实际运行场景设计，覆盖软件系统的所有安全功能和关键运行场景。测试过程中，需记录测试数据和测试结果，对于测试中发现的缺陷，需进行跟踪和整改，整改完成后，需进行回归测试，确保缺陷已被彻底纠正。嵌入式软件测试完成后，需形成嵌入式软件测试报告，报告内容包括测试环境、测试方法、测试用例、测试数据、测试结果、缺陷统计及整改情况等。嵌入式软件测试报告需经过评审，评审通过后，嵌入式软件方可进入后续的生产、运行阶段。11可配置软件的特殊要求对于可配置软件，其开发过程除需遵循本标准的一般要求外，还需满足以下特殊要求，确保配置过程的正确性和安全性，避免因配置错误导致软件故障。可配置软件的配置需求需明确，配置参数的定义、取值范围、默认值等需在软件安全需求规范中明确规定，配置参数的选择需符合软件安全需求，避免因配置参数不当导致软件安全功能失效。配置需求需经过评审，确保配置需求的合理性和完整性。可配置软件的配置机制需具备安全性，配置过程需进行权限控制，只有授权人员才能进行配置操作，避免未授权人员修改配置参数。配置过程需进行日志记录，记录配置操作的人员、时间、配置内容等信息，确保配置过程的可追溯性。可配置软件的配置结果需进行验证，验证配置参数的正确性和有效性，确保配置后的软件能够满足软件安全需求和实际运行需求。配置验证需采用测试、分析等方式进行，对于验证中发现的配置错误，需及时进行修改，并重新进行验证，直至配置结果符合要求。可配置软件的配置文档需完整，文档内容包括配置参数的定义、取值范围、配置方法、配置验证方法等，确保用户能够正确进行配置操作。配置文档需经过评审，确保文档的准确性和可读性。12软件支持过程软件开发过程中，需建立完善的支持过程，包括配置管理、变更管理、文档管理、质量保证等，确保软件开发过程的可控性和可追溯性，保障软件产品的质量和安全性。配置管理需对软件开发过程中的所有工作产品（如需求文档、设计文档、代码、测试用例、测试报告等）进行版本控制，明确每个工作产品的版本号、修改记录等信息，确保工作产品的可追溯性。配置管理需建立配置基线，对软件开发过程中的关键节点进行基线冻结，避免未经授权的修改。同时，需建立配置库，对工作产品进行统一管理，确保工作产品的安全性和完整性。变更管理需对软件开发过程中的所有变更（如需求变更、设计变更、代码变更等）进行控制，变更申请需经过评审，评审内容包括变更的必要性、变更对软件安全的影响等，评审通过后，方可进行变更。变更实施后，需进行回归测试，确保变更不会引入新的缺陷，且不会影响软件的安全功能。变更过程需形成文档，记录变更申请、评审意见、变更实施情况、回归测试结果等信息，确保变更过程的可追溯性。文档管理需建立完善的文档体系，确保软件开发过程中的所有活动都有对应的文档记录，文档内容需准确、完整、清晰，符合标准要求。文档需进行版本控制，及时更新，确保文档与实际开发情况保持一致。同时，需建立文档归档机制，对已完成的文档进行归档管理，确保文档的安全性和可查阅性。质量保证需对软件开发过程的各个阶段进行监督和检查，确保软件开发过程符合ISO26262系列标准和企业内部的开发规范，及时发现和纠正开发过程中的问题。质量保证活动需形成报告，记录检查结果、发现的问题及整改情况，确保质量保证过程的可追溯性。13软件安全文档化软件安全文档化是软件功能安全开发的重要组成部分，需建立完整的软件安全文档体系，确保软件开发过程的可追溯性和可验证性，为软件的验证、确认、维护和安全评估提供依据。软件安全文档体系包括以下核心文档：软件安全计划，明确软件安全开发的目标、范围、组织分工、开发流程、验证计划等内容，是软件安全开发的指导性文档；软件安全需求规范，明确软件的安全需求、对应的ASIL等级等内容；软件架构设计文档，明确软件的架构设计、模块划分、接口定义、安全机制部署等内容；软件单元详细设计文档，明确每个软件单元的内部结构、算法、数据结构等内容；编码规范，明确软件编码的规则和要求；软件单元验证报告，记录软件单元验证的过程、结果、缺陷统计及整改情况等；软件集成验证报告，记录软件集成与验证的过程、结果、缺陷统计及整改情况等；嵌入式软件测试报告，记录嵌入式软件测试的过程、结果、缺陷统计及整改情况等；软件安全分析报告，记录软件安全性分析（如FTA、FMEA等）的过程和结果；可配置软件的配置文档，明确配置参数、配置方法、配置验证等内容；软件安全评估报告，对软件的功能安全符合性进行评估，确认软件是否满足安全目标和标准要求。所有软件安全文档需经过评审，确保文档的准确性、完整性和规范性。文档需进行版本控制，及