车辆（四十二）——ISO26262（四）

随风1

一、系统级产品开发

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

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



二、技术安全需求制定

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

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

技术安全需求规范

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

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

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

3、系统配置要求。

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

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

安全机制

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

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

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

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

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

5、 防止故障被隐藏的措施为使项目达到或维持一个安全状态的安全机制应规定：

1、 安全状态的切换

2、 容错的时间间隔

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

4、 维持安全状态的措施

ASIL 分解

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

潜在故障的避免

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

识别防止故障被潜伏的安全措施的评估标准来自于良好的工程实践。潜在故障的度量，在 ISO26262-5:2011，第 8 条款给出，提供评价标准。适用于 ASIL 的技术安全需求应避免多点故障失效，确定多点故障检测间隔时，应考虑以下因素：

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

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

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

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

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

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

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

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

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

产品 、 运行 、 维护和结束

在生产，经营，维护，维修和关闭的项目或元件的功能安全性的技术安全要求在ISO 26262-7 中规定。

检验和确认

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

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

b）遵守初步体系设计。

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