道路车辆功能安全- - ISO26262 标准（4）

ISO26262-4 系统级产品开发

5、系统级产品开发启动

系统级产品开发启动的目标是确定和规划在系统开发各个子阶段的功能安全活动。这部分内容在 ISO26262-8 中也有描述。系统级安全活动包含在安全计划中。

系统开发的必要活动如下图所示，产品开发启动和技术安全需求说明之后是系统设计。

在系统设计过程中，系统体系结构建立以后，技术安全要求被分配到的硬件和软件部分，如果合适的话，分配到其它技术。从系统架构所增加产生的需求，包括硬件，软件接口（HSI），对技术安全要求进行细化，依据体系结构的复杂性，对子系统的需求依次地导出。之后，硬件和软件部分进行集成和测试，然后进行装车测试。一旦到装车测试的水平，执行安全确认，以提供达到安全目标的功能安全证据。系统级产品开发启动的安全活动是计划设计和集成过程中适当的方法和措施。

6、技术安全需求制定

这个阶段的第一个目标是规范技术安全需求。该技术安全需求说明细化了功能安全的概念，同时考虑功能性的概念和初步的体系架构。第二个目标是通过分析技术安全需要来验证符合功能安全需求。

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

技术安全需求规范

技术安全需求应符合功能安全的概念，项目的初步架构和系统相关属性：

1、外部接口，如通信和用户界面;

2、限制，例如环境条件或功能限制;

3、系统配置要求。

如果其他功能或要求由系统或其部件来实现，除了技术安全需求规范规定的那些功能，那么其他要求应作为他们的规范或做参考。其它要求比如：经济委员会（欧洲经委会）的规则，联邦机动车辆安全标准（FMVSS）或公司的平台战略。

技术安全需求须指明安全相关的依赖关系，系统之间或项目之间，项目与其他系统之间。

安全机制

技术安全需求应指定系统或要素达到安全目标的影响因素，包括每个相关的工作模式和系统定义的状态的失效和相关因素的组合。比如，如果车辆稳定性控制的制动系统是不可用的，自适应巡航控制系统（ACC）ECU 禁用 ACC 功能。

技术安全需求规定的必须的安全机制包括：

1、 系统本身的检测，指示和故障控制措施，包括系统或元件来检测随机硬件故障，检 测系统故障的自我监控措施，包括检测和控制通信信道失效模式的措施（例如，数据接口，通信总线，无线射频链路）。

2、 检测，指示和与该系统交互的外部设备的故障控制的措施，比如，外部设备包括其 它电子控制单元，电源或通信设备。

3、 使系统达到或维持安全状态的措施。这包括在相互冲突的安全机制的情况下优先级 和仲裁逻辑情况。

4、 细化和实现警告和降级概念的措施

5、 防止故障被隐藏的措施

为使项目达到或维持一个安全状态的安全机制应规定：

1、 安全状态的切换

2、 容错的时间间隔

3、 如果安全状态不能立即达到，应确定应急操作的时间间隔

4、 维持安全状态的措施

L ASIL  分解

按照 ISO26262-9:2011，第 5 条款

潜在故障的避免

制定安全机制以防止故障被隐藏。关于随机故障，只有多点故障有可能包含潜在故障，比如，在线测试，在不同的操作模式如上电，掉电，在运行时或在额外的测试模式下，来检测潜在故障，以验证组件状态的安全机制。阀门，继电器或指示灯功能测试是这样的在线测试的例子。

识别防止故障被潜伏的安全措施的评估标准来自于良好的工程实践。潜在故障的度量，在 ISO26262-5:2011，第 8 条款给出，提供评价标准。

适用于 ASIL 的技术安全需求应避免多点故障失效，确定多点故障检测间隔时，应考虑以下因素：

1、根据硬件的可靠性考虑它在体系中的角色

2、相应的危险事件曝光的概率

3、由违反安全目标的硬件随机失效概率规定量化目标值

4、分配的 ASIL 等级对应的安全目标

下列采取的措施依赖于时间限制：

-定期测试运行期间，系统或元件;

-在上电或掉电时在线测试元件;

-维护期间测试系统或元件。

防止双点故障被潜伏的安全机制的开发应符合：

产品 、 运行 、 维护和结束

在生产，经营，维护，维修和关闭的项目或元件的功能安全性的技术安全要求在

ISO 26262-7 中规定。

检验和确认

技术安全要求应按照 ISO26262-8:2011，第 9 条，进行验证：

a）符合的功能安全概念，

b）遵守初步体系设计。

项目的安全确认标准应根据技术安全细化要求。

7 7 、 系统设计

这个阶段的第一个目标是进行系统设计、开发符合项目技术安全需求规范的功能要求。

第二个目标是校验系统设计和功能要求。

系统设计和基于项目技术安全需求规范的技术安全概念来源于功能安全概念。为了开发一个系统架构设计，功能性安全要求，技术安全要求和非安全相关的要求被完成。因此，在这个阶段安全和非安全相关的要求都在这个过程中处理。

系统设计规范和技术安全概念

技术安全要求的应分配给系统设计要素，同时系统设计应完成技术安全要求，关于技术安全要求的实现，在系统设计中应考虑如下问题：

1、 系统设计的可验证性

2、 软件硬件的技术实现性

3、 系统集成中的执行测试能力

系统架构设计约束

系统和子系统架构应该满足各自 ASIL 等级的技术安全需求，每个元素应实现最高的ASIL 技术安全需求，如果一个系统包含的子系统有不同的 ASIL 等级，或者是安全相关的子系统和非安全相关的子系统，那么这些系统应该以最高的 ASIL 等级来处理。

安全相关的内部和外部接口应该被定义，避免其他因素影响安全相关的接口。

系统失效的避免措施

在系统设计安全分析，根据下表和 ISO26262-9:2011，第 8 条款，找出系统故障的原因和系统故障的影响。

这些分析的目的是协助设计。因此，在这个阶段，定性分析很可能是足够的，在需要时可以执行定量分析。这些分析从细节的角度来识别、确定和排除系统故障的原因和影响。从内因和外因进行系统性故障识别来消除或缓解其影响。

为了减少系统故障，应采用良好的值得信赖的汽车系统的设计原则。这些包括以下内容：

1、可重用、可靠的技术安全概念

2、可重用、可靠的软件、硬件设计单元

3、可重用、可靠的检测控制故障机制

4、可重用、可靠的标准化接口

为了确保可靠的设计原则在新的项目单元的适宜性，重用之前应进行影响分析和潜在的假设条件。影响分析包括所确定的诊断，环境的约束和可行性限制，时间限制，所确定的资源的兼容性，并且在系统设计的鲁棒性。

ASIL D 规定：可靠的设计原则不再重用应该是有一定理由的。

ASIL A、B、C、D 规定：为避免高复杂性带来的故障，架构设计应该根据表 2 中的原则来展现下列的属性：模块化，层次化，简单化

运行过程中随机硬件失效的控制措施检测、控制、减轻随机硬件故障的措施在系统设计规范和技术安全概念中给出。例如，硬件诊断功能及其软件这些措施可以用来检测随机硬件故障，直接导致随机硬件故障的情况下硬件设计即使没有检测也是失败的。

ASIL （B）C、D 规定要求：对于单点故障和潜点故障的目标值（见 ISO26262-5:2011，第 8 条款），应在项目级指定最终评估（见要求 9.4.3.4）。

ASIL （B）C、D 规定要求：由于随机硬件故障违反安全目标的评价应该作为替代方法之一（见 ISO26262-5:2011，第 9 条款）目标值应在项目级别中指定为最终评估（见9.4.3.4）。

ASIL （B）C、D 规定要求：对于故障率和诊断覆盖率的目标值应在在单元级中指定以满足下列要求：

a) ISO 26262-5:2011,第 8 条款中的目标值矩阵；

b) ISO 26262-5:2011, 第 9 条款的流程.

ASIL （B）C、D 规定要求：分布式发展（见 ISO26262-8:2011，第 5 条款），派生目标值应送交各相关方。

在ISO26262-5:2011第8和9条款描述中的架构限制，不能直接适用于检测设备（COTS）零部件。这是因为供货商通常不能预见在最终产品其产品的使用和潜在的安全问题。在这种情况下，基本数据，如故障率，故障模式，每故障模式下的故障率分配，内置诊断等都是为了让零部件供应商估算在整体硬件架构层的架构限制。

硬件和软件配置

技术安全要求，应直接或通过进一步细化到硬件，软件或两者兼有。如果技术安全要求被分配到定制的硬件单元包括可编程的行为充足的开发过程（诸如 ASIC，FPGA 或其他形式的数字硬件）有足够的发展，应结合 ISO26262-5 和 ISO26262-6 的要求，来制定和实施。 遵照分配的硬件单元的安全性要求可以依据 ISO26262-8:2011，第 13 条款。

系统的设计应符合分配和分区决策，为了实现独立，避免故障的传播，系统设计时可实现的功能和组件的划分。

硬件和软件接口规范 （ HSI ）

软硬件接口规范应规定的硬件和软件的交互，并与技术安全的概念是一致的，应包括组件的硬件设备，是由软件和硬件资源控制支持软件运行的。软硬件接口规范应包括下面属性：

1、 硬件设备的工作模式和相关的配置参数， 硬件设备的操作模式，如：缺省模式，初始化，测试或高级模式， 配置参数，如：增益控制，带通频率或时钟分频器。

2、 确保单元之间的独立性和支持软件分区的硬件特性

3、 共享和专用硬件资源，如内存映射，寄存器，定时器，中断，I / O 端口的分配。

4、 硬件设备的获取机制，如串口，并口，从，主/从

5、 每个涉及技术安全概念的时序约束

硬件和其使用的软件的相关诊断功能应在软硬件接口规范中规定：

1、硬件诊断功能应定义，例，检测过流，短路或过热

2、在软件中实现的硬件诊断功能

软硬件接口规范在系统设计时制定，在硬件开发和软件开发时被进一步细化。

产品运行 、 维护和关闭要求

诊断功能规定应保存现场运行过程中项目或单元的监测数据，以考虑到安全结果分析和安全机制运行

为了保持安全功能，诊断功能应规定允许故障识别可以由车间员工进行服务时获得。

产品运行、维护和关闭要求应包括如下功能：

1、 安装说明要求

2、 安全相关的特殊说明

3、 确保系统或元件正确识别的要求，如标签

4、 产品的核查方法和措施

5、 诊断数据和售后服务要求

6、 关闭要求

系统设计验证

系统设计应遵守和具备安全概念，使用表 3 中列出的验证方法进行验证。

按照技术安全概念要求，将异常和不完整的情况汇总形成系统设计检测报告。在安全目标下，系统设计未覆盖的新识别的危险，应写入危险分析和风险评估报告，按照ISO26262-8:2011，第 8 条的变更管理要求来进行。

8 8 、 项目集成和测试

集成和测试阶段包括三个阶段和两个主要目标如下所述：第一阶段为每个项目包含的元件的硬件和软件的集成。第二阶段是一个项目的元件的集成以形成一个完整的系统。第三阶段是项目与车辆的周围系统的集成。

集成过程的第一个目标是根据 ASIL 等级和安全需求规范测试符合各项安全要求。第二个目的是验证“系统设计”覆盖的安全要求正确地由整个项实施。项目元件的集成是在从软件硬件集成，系统集成到整车集成系统。 集成测试会在每个阶段的执行来证明系统元件正确交互。根据 ISO26262-5 和 ISO26262-6 完成硬件和软件的开发，然后按照第 8 条款（项目集成和测试）开始进行系统集成。

集成测试计划制定

为了证明该系统设计符合功能和技术安全要求，集成测试活动应按照 ISO26262-8:2011，第 9 条款进行。

测试目标如下：

1、 功能安全和技术安全要求的正确实现

2、 功能特此、精确度和安全机制时序的正确

3、 接口一致性的正确实现

4、 安全机制诊断和故障覆盖度的有效性

5、 鲁棒性

集成和测试策略应该被定义，这是基于系统设计规范，功能安全概念，技术的安全概念，项目集成和测试计划，并且证明测试目标充分覆盖，集成和测试策略应涵盖电子/电气元件，并在安全的概念考虑其他技术元素。

为了使系统集成阶段化，按下列规定进行：

1、集成和测试计划应细化为软硬件集成和测试;

2、项目集成和测试计划应细化到包括系统和车辆级别的集成测试规范。应确保硬件软件验证来解决开放问题;

3、系统及整车级别的项目集成和测试计划应考虑车辆之间的接口、子系统（内部和外部有关项）和环境。

在规划整车级的集成和测试时，应考虑在典型和极端的车辆条件和环境下，车辆的正确行为，表 4 有一部分是足够的。

软硬件集成测试

软硬件集成

根据ISO26262-5所开发的软件和根据ISO26262-6开发的硬件将被集成到表4的主题所列的测试活动中。

ASILs C 和 D 规定：软硬件接口（HSI）需求应在适当范围进行测试，并考虑到 ASIL或相关的人机接口存在的问题。

软硬件测试过程中的测试目标和方法

为了检测在硬件和软件整合时，系统设计中存在的系统故障，应通过大量测试方法的应用程序来测试。

1、软硬件级的技术安全需求的正确执行应使用表 5 给出可行的测试方法来证明。

a 基于需求的测试是指对功能性和非功能性需求的验证。

b 故障注入测试使用特殊的手段在运行时引入到故障到测试对象。这可以在软件中通过一个特殊的测试接口或专门准备的硬件来完成。该方法经常被用于提高安全性的测试覆盖率的要求，因为在正常运行期间的安全机制不会被调用。

c 比较测试比较测试对象和仿真模型在相同的输入下的反应，以检测模型的行为和具体实现之间的差别。

2、软硬件级的功能性能，精度和安全机制的时序的正确性，应使用表 6 给出可行的测试方法证明

a 比较测试比较测试对象和仿真模型在相同的输入下的反应，以检测模型的行为和具体实现之间的差别。

b 性能测试可以在整个测试对象在环境下的性能（例如，任务调度，定时，功率输出），并且可以验证预期的控制软件与硬件上运行的能力。

3、软硬件级的外部和内部接口的一致性和正确性应采用表 7 给出可行的测试方法来证明。

a 测试对象的接口测试，包括模拟和数字输入和输出测试，边界测试和等价类测试，以完全测试测试对象的具体接口，兼容性，定时和其它指定的测试项。ECU 的内部接口可以通过软硬件兼容性的静态测试和串行外设接口-（SPI）或集成电路 - （集成电路）通信或 ECU 的元件之间的任何其他接口的动态测试实现。

4、对于故障模式，软硬件级的安全机制的诊断覆盖率的有效性，应使用表 8 给出可行的测试方法证明。

a 故障注入测试使用特殊的手段在运行时引入故障到测试对象。这可以通过在软件中设置一个特殊的测试接口或专门准备的硬件来完成。该方法经常被用于提高安全性的测试覆盖率的要求，因为在正常运行期间的安全机制不会被调用。

b 错误猜测测试采用专业的经验教训积累的知识和数据来预测在测试对象中错误，然后使用足够的测试设备设计一组测试用例，以检查这些错误。错误推测对于专业测试人员是一种有效的方法。

5、软硬件级的鲁棒性依据表 9 来实现

A 资源使用率测试可以静态地进行（例如，通过检查代码的大小或分析有关中断使用的代码，以验证最坏的情况不会耗尽资源）也可以通过运行时动态地监控。

b 负荷测试验证测试对象高负荷情况，或从高要求环境下的正确运行情况。因此，高负荷情况下测试测试对象，或用特殊接口的负载，或变量（总线负载，电击等），以及在极端温度，湿度或机械冲击测试中，都可以应用

系统集成和测试

系统集成

根据系统的设计，在系统中包含的各个元素应被集成，按照 ISO26262-5 和 ISO26262-6中指定的系统集成测试。

系统测试的测试目标和方法

为检测系统集成过程中的系统故障，依据下面表格中的测试目标和测试方法。

1、 系统级功能安全和技术安全需求验证，表 10

2、 系统级的功能性能，精度和安全机制的时序的正确性，表 11

3、 系统级的外部和内部接口的一致性和正确性，表 12

b 通信和交互测试包括系统元素之间的测试，以及系统和其他车辆系统之间在运行过程中的测试，针对功能性和非功能性需求测试

4、 系统级的安全机制的诊断覆盖率的有效性，表 13

5、 系统级的鲁棒性，表 14

C 干扰性和鲁棒性测试，在一定的环境条件下，是压力测试的一种特殊情况。这 包括EMC和ESD测试 整车集成和测试 整车集成 应进行车内通信网络的接口规范和车内电源网络的验证。

测试目标和测试方法

在整车集成过程中为了检测系统故障，从需求中产生的测试目标，应通过适当的测试方法来解决，下面的表格来阐述。

1、 整车级功能安全验证，表 15

长期测试和用户真实环境是相似的，都是野外体验，但使用更大的样本量，普通人员作为测试人员来测试，并没有指定固定的测试场景，但是在现实生活中日常场景。如果需要的话这些测试可以有限制，以确保测试人员的安全性，如额外的安全措施或禁用驱动器。

2、 整车级的功能性能，精度和安全机制的时序的正确性，表 16

3、 整车级的外部和内部接口的一致性和正确性，表 17

4、 整车级的安全机制的诊断覆盖率的有效性，表 18

5、 整车级的鲁棒性，表 19

9、安全确认

第一个目标是提供符合安全目标和适用于该项目的功能安全概念的功能安全性证据。第二个目标是提供证据证明的安全目标是正确的，完整的，在车辆级别可以实现的。

之前的验证活动（如设计验证，安全分析，硬件，软件和项目集成和测试）的目的是为了提供证据，证明每个特定活动的结果符合规定要求。在代表性的汽车集成项目的验证的目的是对预期用途提供恰当的证据和确认安全措施的充足性。

这个集成的项目包括：系统，软件，硬件，其他技术元素，外部措施。 验证计划应加以完善，包括如下内容：

a） 项目配置经过包括校正数据的验证。（？？）

b） 验证程序，测试用例，驾驶策略等验收标准规范;

c） 装备和必备的环境条件

项目的安全目标应评估以下目标：

a） 可控性

b） 控制随机和系统故障的安全措施的有效性

c） 外部措施的有效性

d） 其他技术中元素的有效性

在项目级，随机硬件故障的验证应在项目级应进行为：

a） 由于 ISO26262-5:2011 第 9 条款所定义的随机硬件故障，安全目标违反评估，根据 由 7.4.4.3 规定的目标值

b） 由于 ISO26262-5:2011 第 8 条款所定义的硬件体系故障，安全目标违反评估，根据 由 7.4.4.2 规定的目标值

在车辆级，基于安全目标，功能安全要求和预期用途的确认，应作为执行计划使用

a）对每个安全目标，验证程序和测试用例都有详细的通过/失败的标准;

b）适用范围。这可能包括诸如配置，环境状况，驾驶情况，操作使用情况等。

下列一组方法应使用：

a） 使用指定的测试程序，测试案例和通过/失败的标准进行重复的测试; 例如：功能和安全要求测试，黑箱测试，模拟，边界条件下测试，故障注入，耐久性测试，压力测试，高加速寿命测试（HALT），模拟外部影响。

b） 分析，例如 FMEA, FTA, ETA, 仿真

c） 长期测试，如车辆行驶时间和测试车队;

d） 在现实生活条件的用户测试，盲目测试，专家测试;

e） 复审

10 、 功能安全评估

本条款的要求目的是评估已通过实现的项目功能安全。与功能安全责任的组织（如车辆制造商或供应商，如果后者是负责功能安全）启动功能安全的评估。

11 、 产品发布

本条款的目的是规定项目开发完成后产品标准发布，产品发布确认该项目在车辆级符合功能安全的要求。 产品发布确认项目准备后后续生产和经营 遵守先决条件批量生产的证据是通过下面提供

1）在开发过程中硬件，软件，系统，物品和车辆级别的验证和确认完成。

2）功能安全的成功整体评估 发布文档作为发布产品的基础，由负责发布的人签署。

产品功能安全发布文档应包含下列信息：

1）负责发布的人的名称和签名;

2）项目发布的版本

3）项目发布的配置

4）相关的参考文档

5）发布日期