通过危害分析和风险评估，我们得出系统或功能的安全目标和相应的ASIL等级。当ASIL等级确定之后，就需要对每个评定的风险确定安全目标，安全目标是最高级别的安全需求。安全目标确定之后，就需要在系统设计、硬件、软件等方面进行设计、实施和验证。

从安全目标可以推导出开发阶段的安全需求，安全需求继承安全目标的ASIL等级。那么，要如何继承项目的安全需求呢？

接下来我们将先为大家说明如何继承安全需求。

产品开发阶段中功能安全需求的继承

下图为功能安全需求继承的流程图：

1.安全目标设定

如何提出系统安全需求是系统安全设计的第一步，系统安全需求的指导方针在现代安全法规中通常被表述为“安全目标设定”，它描述了所需实现的系统安全目标，并根据系统安全目标选择相应的实现方法和途径。

对所实施ISO 26262的项目，应用危险分析和风险评定以及评估ASIL等级，来避免不可接受的风险，并确定项目的安全目标。所谓的安全目标，就是为了防止在特定驾驶状态下发生危险事件而采取的功能需求。通过危害分析和风险评估，为每一个风险确定一个ASIL等级，而安全目标就是为了每一个风险而设定的。

2.功能安全需求的设定（功能安全概念）

为了符合功能安全目标，在功能安全概念中规定了项目的功能安全需求。

所谓的功能安全概念，是指得出实现安全目标所需的功能安全要求，并将他们分配到初步的设计架构，或者外部减少危险的措施当中去，以确保满足相关的功能安全。

所谓的功能安全需求，是一种安全措施（减少有害影响的活动或解决方案），且该安全措施不依赖于以安全目标为基础的项目安全行为规范和实施。

安全目标和功能安全需求之间的关系是分层的，如下图所示。

3.技术安全需求的设定（技术安全概念）

为了在项目中实现功能安全需求，必须根据技术安全概念，将项目级别的功能安全需求细化为系统级别所需要的技术安全需求。

所谓的技术安全需求，是为了实现功能安全需求，系统应具备的技术性安全措施。

所谓的技术安全概念，是说明如何实现技术安全需求规范。

在整个开发生命周期，技术安全需求是要落实功能安全概念的技术需求，其用意是从细节的单级功能安全需求到系统级安全技术需求。

4.系统设计

在系统设计阶段，系统及子系统需要按上面所定义的贯彻技术安全要求，设计出符合系统规范的开发方法。这里，不仅考虑安全需求，还考虑非安全需求(ASIL等级表中被判定为“QM”的要求)。为了实现技术安全要求，必须考虑到系统设计的可验证性，实现功能安全的技术能力以及系统集成期间的测试可行性。

将实施所需规范中的技术安全要求集合，即为系统规范样式。

系统规范应直接或通过进一步细化到硬件，软件或两者兼有。此外，设计硬件 - 软件接口（HSI），规定硬件和软件的交互，并应与技术安全的概念一致。

另外，系统规范必须验证对技术安全概念的符合性和完整性。

5.硬件安全需求和功能安全的硬件开发

根据分配给硬件的技术安全要求，可以获得硬件安全需求。硬件安全需求主要用于保证控制器内部硬件故障的安全机制的安全要求。

ISO 26262所要求的硬件设计的要点，一是定量地实施对硬件架构指标的评估，二是由于偶发硬件故障而导致的随机失效率的评估。

硬件架构指标，是用于评估硬件架构对硬件的偶然故障的影响（鲁棒性）的指标，且为定量数值，由标准定义的公式来确定。

随即失效率，是基于概率论，用来评价安全机制在安全性的逻辑支持之下的有效性。

6.软件安全需求的规范

软件安全要求以因故障引起技术安全要求偏离的功能为对象，并将其细化定义至可实施/验证软件的等级。

在软件安全要求的设计方面，需要考虑指定的系统和硬件配置，硬件/软件接口，硬件安全要求，时间限制，与项目外部视图的接口，受软件影响的车辆，系统以及硬件涉及的各个动作模式。

软件安全要求规范还必须验证与技术安全概念、系统规范、硬/软件接口规范的兼容性和一贯性。

功能安全的软件级开发

符合功能安全的软件开发有什么不一样的吗？

1.软件安全要求的可追溯性

ISO 26262要求将各危险风险降低设定为安全目标，并且在整个开发过程中，保证测试结果都可以通过其验证测试、实施、规范和要求来追溯。这就是功能安全的可追溯性。可追溯性可通过给需求添加ID号码来识别。

在软件开发中，ID号码用于关联软件安全需求标准的软件安全需求（相当于软件功能设计）、软件架构设计标准的软件组件以及软件单元设计标准的函数（如下图）。 这使得安全需求的关系明确，并且通过验证和试验，可以有效地发现对于上级要求来说的下级要求存在的遗漏，以及对函数不良影响的条件的影响等。

关于需求的可追溯性管理，可使用软件开发中的需求管理工具来实现。

2.设计方法

在ISO 26262中，软件想要达到系统所分配的更高安全目标的ASIL D等级，就需要更加严谨的软件架构。

在软件架构设计中，如果想要达到符合ASIL D等级，就必须满足软件组件的分层化、软件组件大小的限制、适当的调度、软件组件的内聚、耦合限制和中断限制。

在各种软件设计的方法中，结构化设计方法已经不是什么新鲜的方法了。但在ISO 26262中，显然，该方法是处理应对ASIL相应等级的必须手段。

在软件架构级别的错误检测阶段中，对于ASIL D的要求，必须进行输入输出数据的范围检查、数据有效性检查、外部监控、控制流监视和软件冗余设计。

在软件架构级别的错误处理阶段中，对于ASIL D的要求，必须具有发生错误时的缩退功能以及并行的冗余。

在单体软件设计阶段中，对于ASIL D的要求，相关函数只能有1个出入口，限制动态安全对象（例如堆栈区域），执行变量初始化，禁止相同变量名称，限制使用全局变量，限制指针使用，禁止隐式类型转换，禁止隐藏数据流/控制流，禁止无条件跳转，禁止递归调

ISO 26262没有深入涉及建模设计。关于汽车建模设计（基于模型的开发），MATLAB / Simlink被认为是典型方法，尽管如此，执行建模设计并不一定有助于导入功能安全。

不基于模型设计的软件开发代码质量，与基于模型设计的软件开发代码质量是相同的。在建模设计中提高模型的质量，也有助于由此产生的产品（项目）的安全性。关于设计模型时的指南，ISO 26262结合编码指南定义了设计指南的要求。

针对特殊的应用场合，软件安全设计还涉及信息安全，以及面向自动驾驶的预期功能安全等相关考量，具体的实施上需要制定合适的安全机制，安全架构（比如E-GAS安全架构），并进行满足安全标准的测试，软件部分与ASPICE有诸多重叠支出，将二者融合起来执行，能够更加全面的改进软件安全和质量。

3.验证

所谓“验证”，就是确认已“正确”完成产品开发。

在ISO26262中，关于软件架构设计、软件单体设计和实现(编码)，规定需要完成与ASIL等级相对应的验证。

对于软件架构设计验证，如果是ASIL A级别，只要排查就足够了。但如果是达到符合ASIL D级别，则必须进行检查，动态（可执行模型）仿真，原型设计，控制流/数据流分析。

对于软件单一设计和实现（编码）验证，如果是ASIL A级别，只要排查就足够了。但如果是达到符合ASIL D级别，就必须进行检查，半正式验证（使用基于模型的仿真验证等），控制流/数据流分析，静态代码分析。

4.确认

所谓“确认”，就是通过提供客观证据对特定的预期用途或应用要求已得到满足的认定。通过试验来确认是否产生了满足要求的成果物。

对于ASIL D等级要求，无论是软件单元测试还是软件集成测试，都必须进行基于需求的测试、接口测试、故障注入测试、资源测试和背靠背测试。

在测试用例的导出方法中，需求分析，等价类的创建和分析以及边界值分析是对于符合ASIL D等级的基本要求。

对于软件单元测试的覆盖率，ASIL A可以执行100％的C0覆盖（指令覆盖率），而ASIL D则要求100%实施C1覆盖(分支网罗率)及MC/DC(Modified Condition/Decision Coverrage) 。

对于软件集成测试，ASIL D要求100%实施功能覆盖和调用覆盖。

5.软件工具的认证

为了软件开发而使用导入的各种软件工具（以下简称为工具），ISO 26262为它们设定了可靠性评估指标，只有被认定为符合指标的工具才能够用于开发。

所以，首先第一步，我们需要看看工具是否符合ISO 26262的认证标准。

为此，我们需要验证软件工具对于安全功能的影响（TI），也要同时考评软件工具，针对自身可能出现的内部错误的诊断能力（TD），并最终生成该软件工具的置信等级（TCL）。

TI是对软件工具是否对正在开发的设计产生直接的安全相关影响的评估。TI分为两个级别，TI1和TI2。TI1意味着对设计没有直接影响，而TI2则表示对设计有直接影响。当软件工具故障对项目或者组件完全没有影响时，可选择TI1。其他情况则选择TI2。

TD指对工具由于误操作而引起错误输出防护手段，以及工具发生错误时候检测能力的信赖性，,用TD1，TD2，TD3三个等级来评价。当对于误动作以及对应的误输出的防护和检测手段信赖性要求比较高时候，选择TD1；信赖度要求处于中等程度的时候选择TD2，其他情况选择TD3。

例如，假设某工具用于检测设计模型的错误。该工具对模型执行静态分析。当静态分析良好时，该工具不能检测模型中的所有可能违规行为。还有一点值得注意的是，这并不一定意味着该模型是错误的，而仅仅表明需要额外的测试。该例是一种中等程度的置信水平，即TD2。

根据TI和TD，我们可以通过以下矩形表格来确定TCL

判定为TCL1的工具无需认证即可使用，而判定为TCL2和TCL3的工具则需要附加鉴定方法，以下为适用的四种认证方法：

1a 信赖度通过使用而增强

只有提供了标准规定的工具实际应用的有关证据，才能基于使用历史，提升工具的信赖度。

1b  评估工具开发过程

该工具开发的开发过程是否开发流程，开发标准。

1c 软件工具确认确认

确认满足标准所判定的指标的方法。

1d 按照安全标准进行开发

工具开发是否符合ISO26262，IEC61508和RTCA DO-178（航空系统和设备的安全标准）等标准。

事实上，只要执行了附加认证，就可以使用TCL2或TCL3中评估的软件工具。ISO 26262也列出了关于TCL2和TCL3级工具可接受的认证方法。

ISO 26262-8:2011表4列出了对TCL3级工具可接受的认证方法，表5列出了对TCL2级工具可接受的认证方法。（如图）

根据工具中开发的项目或ASIL类别的不同，优先选择应用不同的认证方法。下图为合并的表格，其中突出显示了优选方法并且进行了说明。

++表示该方法被强烈建议用于所对应的ASIL

+表示该方法被建议用于所对应的ASIL

注：*没有如何安全标准完全适用于软件工具的开发。但可以选择安全标准的相关子集要求。

在TCL2的情况下，ASIL A/B/C需要附加验证方法1a和1b，ASIL D需要附加验证方法1c和1d。

在TCL3的情况下，ASIL A/B 需要附加验证方法1a和1b，ASIL C/D需要附加验证方法1c和1d。

实际上，从供应商处购买工具时，用户很难执行认证。因此，引入符合ISO 26262的第三方认证工具是非常符合现实需求的。

6.通过保护功能防止故障的传播

在特定软件组件发生故障时，为了防止对另一软件组件造成不良影响，ISO 26262一个名为“软件隔离”的结构技术。当多个不同ASIL等级的软件组件在同一个MPU上共存时，该技术非常适用。

举个例子：在没有分区的情况下，假设有ASIL A，ASIL B和ASIL C三个不同等级的软件，使用一个MPU和一个资源（共享内存）进行操作，则三个软件必须符合最高的ASIL等级要求（即ASIL C），导致必须承担高于必要的开发成本。同时，低等级的任务修改高等级的数据，会造成高等级使用了不可信的数据，影响安全功能。

如果有分区，即使三个不同ASIL等级的软件在一个MPU上，也可以将最佳的ASIL等级应用于各个软件组件，可以避免浪费的开发成本。

软件分区技术有很多，将软件分区应用于汽车MPU时，从成本方面考虑，一般认为，利用MPU的存储器保护单元的OS方法是最有希望的。

7.流程改进

在嵌入式软件领域，要求不断改进过程标准，如CMMI和Automotive SPICE。

ISO 26262也需要流程改进，但基本上是对现有流程改进的延伸。建议至少通过CMMI Level 2和Automotive SPICE Level 3认证。

在ISO26262中，Part2功能安全的管理规定了确认审查（从技术的观点验证成果）和功能安全审核（从过程的角度确认功能安全活动的实施状态）。通过结合三点功能安全评估的验证策略（S/E/C）实现独立评估ASIL等级，该评估项目可评估功能安全的合规性。

ASIL的独立性被定义为4个级别，最轻的级别是“认证方案应由不同的人实施”，最重的级别是“来自不同部门或组织的人员实施认证”（即并且必须由第三方实施）。根据认证的内容，较高的ASIL级别需要更高的独立性。

第三方组织可以是公司内的独立部门，例如质量保证部门，或是外部第三方认证机构。为应对功能安全认证的市场需求，有许多供应商和工具供应商要求知名第三方认证机构进行审核。

结论

2011年11月15日，ISO 26262 标准正式颁布。2018年，ISO 26262正式上路。

在这一领域，欧洲、日本应用ISO 26262要早于国内，美国则推出SAE J2980标准。技术咨询公司在和国内OEM合作时会要求引入功能安全。国际汽车厂商（宝马、通用、福特等）、汽车零部件供应商（博世、德尔福等）早已采用该标准开发安全相关的电子电器产品，应用在汽车的开发。

ISO 26262涉及汽车电子电气系统的整个安全生命周期及其管理过程，满足该标准对汽车企业及供应商来说必将是巨大的挑战。为满足ISO 26262，必须在公司安全文化、工作流程制定、产品设计与开发等方面进行持续的改进。 

ISO26262标准暂时没有出现官方层面的强制执行要求，但该标准的执行，将减少因为电子器件失效造成的交通事故和降低潜在召回风险，所以目前国际大型车企非常重视ISO26262标准的应用和推广。

遗憾的是，目前国内汽车电子领域的专用功能安全标准尚属空白，虽然部分意识比较超前的民族品牌企业也关注ISO26262标准的制定和发展，然而，有些企业在接触功能安全之后，遇到重重困难后选择了放弃。