道路车辆功能安全 ISO 26262标准（4-2）—系统级产品开发

最新推荐文章于 2024-09-28 22:34:31 发布

零零刷

最新推荐文章于 2024-09-28 22:34:31 发布

阅读量812

点赞数 5

分类专栏：汽车功能安全分析文章标签：安全人工智能自动驾驶功能测试汽车

本文链接：https://blog.csdn.net/eblock/article/details/142470624

版权

汽车功能安全分析专栏收录该内容

5 篇文章 0 订阅

订阅专栏

写在前面

本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识，希望能帮助更多的同学认识和了解功能安全标准。

若有相关问题，欢迎评论沟通，共同进步。(*^▽^*)

1. 道路车辆功能安全ISO 26262标准

4. ISO 26262-4 系统级产品开发

三、系统设计

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

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

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

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

系统设计的可验证性
软件硬件的技术实现性
系统集成中的执行测试能力

2. 系统架构设计约束

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

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

3. 系统失效的避免措施

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

Methods		ASIL
Methods		A	B	C	D
1	Deductive analysis（因果分析）	o	+	++	++
2	Inductive analysis（预测分析）	++	++	++	++
Deductive analysis methods include FTA, reliability block diagrams, lshikawa diagram. Inductive analysis methods include FMEA, ETA, Markov modelling.

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

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

可重用、可靠的技术安全概念
可重用、可靠的软件、硬件设计单元
可重用、可靠的检测控制故障机制
可重用、可靠的标准化接口

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

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

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

模块化系统设计属性如下表所示：

Properties		ASIL
Properties		A	B	C	D
1	Hierarchical design（分层设计）	+	+	++	++
2	Precisely defined interfaces（清晰定义的接口）	+	+	+	+
3	Avoidance of unnecessary complexity of hardware components and software components（避免不必要的复杂软硬件组件）	+	+	+	+
4	Avoidance of unnecessary complexity of interfaces （避免不必要的复杂接口）	+	+	+	+
5	Maintainability during service（后期服务的可维护性）	+	+	+	+
6	Testability during development and operation （开发运行过程中的可测试性）	+	+	++	++

4. 运行过程中随机硬件失效的控制措施

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

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 规定要求：对于故障率和诊断覆盖率的目标值应在在单元级中指定以满足下列要求：

ISO 26262-5:2011,第 8 条款中的目标值矩阵
ISO 26262-5:2011, 第 9 条款的流程

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

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

5. 硬件和软件配置

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

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

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

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

硬件设备的工作模式和相关的配置参数，硬件设备的操作模式，如：缺省模式，初始化，测试或高级模式，配置参数，如：增益控制，带通频率或时钟分频器。
确保单元之间的独立性和支持软件分区的硬件特性。
共享和专用硬件资源，如内存映射，寄存器，定时器，中断，I / O 端口的分配。
硬件设备的获取机制，如串口、并口、从、主/从。
每个涉及技术安全概念的时序约束。

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

硬件诊断功能应定义，例，检测过流，短路或过热
在软件中实现的硬件诊断功能

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

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

为了保持安全功能，诊断功能应规定允许故障识别可以由车间员工进行服务时获得。产品运行、维护和关闭要求应包括如下功能：

安装说明要求
安全相关的特殊说明
确保系统或元件正确识别的要求，如标签
产品的核查方法和措施
诊断数据和售后服务要求
关闭要求

8. 系统设计验证

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

Methods		ASIL
Methods		A	B	C	D
1a	System design inspection（系统设计审查）	+	++	++	++
1b	System design walkthrough（系统设计走查）	++	+	o	o
2a	Simulation（仿真）	+	+	++	++
2b	System prototyping and vehicle tests （系统原型和车辆测试）	+	+	++	++
3	System design analyses（系统设计分析）	参考系统设计分析表
Methods 1a and 1b serve as a check of complete and correct implementation of the technical safety requirements. Methods 2a and 2b can be used advantageously as a fault injection technique. For conducting safety analyses,see ls0 26262-9:2011,Clause8.