功能安全预期功能安全与信息安全的差异与协同
Posted MES模赛思
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了功能安全预期功能安全与信息安全的差异与协同相关的知识，希望对你有一定的参考价值。
今天的汽车行业面临最大的挑战之一，就是从过去基于硬件的车辆过渡到软件定义汽车的时代。当软件成为造车行业发展的主要领域，越来越多的OEM和零部件供应商逐步转型为软件公司。汽车也单纯的从出行工具变成了移动的计算机，汽车的开发越来越像在四个轮子上去开发车载电脑。
随着智能网联汽车的快速发展，新技术不断涌现，如可通过OTA技术远程进行软件更新升级或实现与个人数字设备的集成等等。这些智能网联汽车上新技术的广泛应用对整车的信息技术安全（或称网络安全）提出了额外的要求，典型的如ISO21434国际标准，道路车辆信息安全工程的关于网络安全方面的专业标准，此标准也给工程应用实践提供了一系列的解决方案。
当前大多数OEM 及零部件供应商遵循功能安全的开发过程，考虑基于ISO 26262功能安全和ISO21448的预期功能安全开发过程。结合新增的对网络安全层面的需求，那又如何理解现有的功能安全标准和网络安全标准的关系，各过程之间又应该如何协调呢？对于基于模型的开发(MBD)过程，尤其是当我们在利用MATLAB Simulink或者TargetLink的模型开发框架去构建我们的应用的时候怎样才能保证相关项的功能安全的同时还能保障足够的网络安全，从而最终能确保我们所开发的软件的质量？这是我们接下来要讨论的内容。
先让我们回忆一下相关安全相关的几组重要标准，首先我们从宏观的概念上去理解区分不同的安全概念。为了更方便地描述自动驾驶系统，ISO TR 4804:2020标准当中引入可信性的概念。可信性定义为系统提供服务或功能的能力，包括了可靠性、可用性、可维护性、功能安全性、网络安全性等几大特性（英文简称为RAMSS）。可信性术语涉及了所谓的可靠性、可用性、功能安全、网络安全各方面的知识领域，涵盖了典型汽车工程实践中需要考虑的功能安全、预期功能安全、网络安全等内容，最初定义了安全相关的一些功能的基本要求。功能安全标准ISO 26262旨在源于E/E系统与E/E系统的故障行为引起的危害进而导致的不合理风险；预期功能安全 ISO 21448讨论的是不存在因预期功能的不足或者合由于合理可预见的人员误操作而导致的不合理风险。功能安全和预期功能安全强调要防止因系统功能层面的故障不足或误用导致的不合理风险。ISO 21434从网络安全的角度去评估，侧重于“故意地操纵”导致的危害，描述资产受到充分保护，道路车辆部件或者其功能部件、子部件功能免于威胁的状况。系统安全相关功能当中的可用性也是一个相当重要的话题，ISO26262中涉及到相关部分内容。
图1. 安全标准的可信域涵盖
ISO 26262的标准在功能安全领域已经广泛应用且为人熟知。针对潜在的功能不足和人为的误用，又提出了一个补充的预期功能安全标准ISO 21448，不久前此标准又出了新版本。而针对信息或网络安全规范，业内提出了网络安全标准ISO SAE 21434。除了三大标准以外，对于自动驾驶车辆，主要利益相关方给出了一个综合性的、特定领域的特定标准ISO 48 TR 4804。ISO 48 TR 4804是有关现有安全标准的一个补充，它的目的是实现积极的风险平衡，或者避免不合理风险或者网络安全相关威胁，并给出了相应的建议指南和更具体的方法。当然相关内容更多的是一些技术性的阐述，强调安全设计的重要性，安全系统依赖于安全系统设计方法来保障。此外，标准也给出了一些关于自动驾驶系统的验证和确认的方法。在ISO 48 TR 4804标准中引入可信性的概念，可信性定义为系统提供服务或功能的能力，包括可靠性、可用性、可维护性、功能安全性和网络安全性（RAMSS）。
ISO 26262初版于2011年提出， 18年又进行了修订，现在绝大部分公司开发都遵循该标准。预期功能安全标准最初提出于 2019 年，2022年更新发布了新版的功能安全标准。关于网络安全标准ISO21434，它其实来源于SAE的J3061标准，于2016年提出《信息物理融合系统网络安全指南》，后来被ISO采纳转化为ISO 21434的《道路车辆的网络安全工程》标准，也是本文讨论的网络安全标准的主题内容。关于自动驾驶的ISO的标准，其实来源于更早的名为《自动驾驶系统：安全第一》白皮书，后被ISO纳入ISO/TR4804 的标准。标准日后还在更新，被采纳为ISO/TS 5083的技术规范。功能安全、预期功能安全、网络安全构成可信域的要件如图 1。
那么不同的安全标准之间有怎样的关联？我们摘录了两句话来描述这种关系。第一句摘自Serpanos1教授的一篇文章，当中提到传统上功能安全、网络安全通常认为是不同的知识领域，由不同的专业人士来负责。但是我们观察他们的特征并类比得出的结论是，他们实际上是相互依存的。特别功能安全其实是依赖于信息安全或者网络安全的。或者可以说网络安全是功能安全的保障，也就是说没有网络安全，就无法保证功能安全。另外一句摘录，Aileen Ryan在《There is no safety without security》2一文中也强调网络安全可被视为功能安全的保障，没有网络安全就没有功能的安全。可能之前汽车行业从业者对网络安全关注比较少，但是最近随着智能网联汽车的快速发展，网络安全问题应对越来越重要。这就促使我们不仅要关注功能安全层面的问题，还需要更系统地关注网络安全的问题。
图2. 功能安全、网络安全的概念视图
接下来我们讨论二者如何区分。这里我们提供一个更直观的关于功能安全和网络安全的概念视图来帮助理解，如图2。网络安全强调保护我们的系统，无论是产品还是设备的数字型资产，免受外部威胁。当然这是对于我们中心的系统来说，其更广义上涵盖系统内部和外部的网络安全。威胁则来源于人或外部环境。一个典型的例子是黑客试图通过WIFI无线网络连接汽车来操纵车内的ECU。而功能安全强调的是防止系统故障引起的危害导致的风险。功能安全意在保护人或者环境免受来自系统故障运行导致的伤害。典型例子比如高速行驶的车辆行进过程当中智能防抱死的系统ABS故障系统抱死失效引发危害造成对人的伤害。
为了容易理解，我们引入典型的例子来说明，汽车安全的研究人员发现，我们完全可以通过车载的电脑，以无线的方式来远程控制汽车。曾经有这样的实际发生的情况，研究人员可以通过通用汽车的OnStar，福特的Sync这样的汽车工具访问车载的计算机，通过车载电话的蓝牙网络连接到整个汽车网络，甚至于控制汽车的刹车、门锁、中控仪表等几乎所有安全关键的系统。
所以我们汽车行业的从业人员希望能够更系统地去研究开发网络安全的汽车系统。欧洲在功能安全、网络安全领域的研究项目EmbeddedSafeSec由柏林投资银行和欧洲区域发展基金会资助，专门研究如何更好地实施功能安全和网络安全的协同工程。下面我们分享一些网络安全和功能安全协同工程的框架，以及协同工程的优秀实践。
图3. 功能安全生命周期(ISO 26262)
首先我们来看对于各自的功能安全标准或者信息里是如何去描述相应的生命周期的活动？对于功能安全来说，ISO 26262当中有相应的功能安全生命周期，这里我们倾向关注更多的是系统和软件层面，如图3（当然除此以外还存在同步的硬件开发生命周期，图中没有显示出来）。虚线以上描述系统层面的一些活动，虚线以下描述软件层面的活动，在系统层面，从危害分析风险评估开始，从功能安全的角度出发识别评估系统的潜在危害及相关风险，确定ASIL等级，得出相应的安全目标并作为顶层的安全需求。从功能安全概念推导具体的技术安全概念等一系列相应规范以及如何在硬件和软件层面实现系统功能安全方面的需求。技术安全概念之后，继续深入分解到下面软件层面，指定软件安全需求，进行软件架构设计、软件单元设计、软件实现，然后过渡到对应左侧的不同层次的测试验证，即单元集成系统及整车层面的验证，最后确认是否实现了最初的安全目标。如此构成一个典型的功能安全的产品开发生命周期。另外，后续还有相应的生产运维报废等过程，组成全面的功能安全生命周期的迭代过程。
图4. 网络安全生命周期(ISO SAE 21434)
同样ISO 21434标准中也提出了一种类似的网络安全生命周期，如图4，与功能安全生命周期极其类似。网络安全生命周期从网络安全目标开始，提出网络安全的概念，进行相关项的产品开发，后续的生产运维、报废等一个重复迭代的周期，最终实现预期的网络安全水平。更具体地说，网络安全的目标到网络安全概念再到系统软硬件的设计，如展示了一些通用的步骤，具体因为我们每个公司组织架构的不同，而甚至项目的不同而已。这里面提到了一些关于系统组件的设计，子组件部件的设计，不同层面的设计活动。子组件验证系统验证等，网络安全产品开发的周期经过迭代不断更新，甚至可以通过OTA技术，实现系统的无限的远程更新和快速迭代，直到最终符合预期的网络安全目标。
功能安全和网络安全标准当中，其实也存在一些关于不同知识领域之间交叉引用的通用描述。如ISO 26262标准中提到，标准要求组织应在功能安全、网络安全和其他与实现功能安全相关的知识领域之间建立并保持有效的沟通渠道。而在网络安全标准ISO 21434中也提出：组织应确定与网络安全相关或交互的领域，并建立和维护这些领域之间的沟通渠道，以确定网络安全是否以及如何融入现有流程并协同相关信息的交流。协同包括在领域之间共享流程和策略工具的应用。关于具体的信息，详情请参照相应的章节，还可以在备注当中看到具体对应章节的展开的信息。
同时在标准当中另外体现功能安全、网络安全协同的信息：功能安全和网络安全的开发过程之间的关系取决于项目的组织和范围，因此没有描述交互的方法或技术内容。可由组织确定最适合这种交互的方法。
所以功能安全网络安全的协同考虑引入所谓的协同工程的概念，其思路即如何通盘地考虑功能安全和网络安全及其相关的活动过程（图5），比如哪些相关的系列活动能够协同进行？哪些活动必须是分开进行？可并行的活动之间如何关联？如何交互？对于不同过程之间的沟通，比如典型地关于产品开发阶段软件开发过程的一系列的过程交互，相应的功能安全生命周期与网络安全生命周期的映射关系。
图5. 功能安全和网络安全活动的协同
协同工程当中对应安全生命周期的产品开发阶段，尤其是软件产品开发阶段一系列的活动，遵循V型开发流程从需求到设计到实现及不同层面的验证测试。功能安全和网络安全标准当中都有相关的需求提及，具体到软件单元集成和验证子章节，如网络安全标准ISO 21434中10.4.1章节提到关于产品开发设计阶段需求规范，10.4.2章节当中涉及集成和验证的规范。对应映射到功能安全标准当中的6.9章部分的软件，如软件单元验证部分，如图6。
图6. 功能安全生命周期与网络安全生命周期的活动集映射
比如我们在图7中看到的是关于产品开发阶段软件开发过程的活动。相应功能安全生命周期的活动对应映射到网络安全生命周期的产品开发阶段的活动。如根据网络安全的需求进行架构总体设计及细化设计，对应功能安全过程中的软件产品开发阶段，派生出具体的软件开发需求（这里我们只关注软件层面），进行软件架构设计，实现及软件单元和集成的验证和软件系统的测试。
图7. 协同工程的软件产品开发过程中的软件单元验证
协同工程根据关于相关项操作环境的现有信息，不同的现有的输入信息进行单元和集成层面的验证，最终会形成相应的软件集成和验证的规范。
协同工程在软件单元验证阶段系列活动的目标在于：
- 提供软件单元设计满足分配的软件需求以及网络安全需求并适合实施的证据；
- 验证从安全导向分析中得出的安全措施是否得到正确实施；
- 提供证据证明已实施的软件单元符合单元设计规范，并满足分配的软件需求和相应的ASIL等级；
- 提供足够的证据，证明软件单元不包含非预期的功能或非预期的的功能安全和网络安全属性。
这里我们还着重要强调二者之间在项目当中的沟通协同活动包括了在知识领域之间共享的流程和使用的策略。关于开发验证或者测试的种种策略在各标准中的要求描述中也是类似的，开发测试所用的工具共享可以最大限度的帮助我们高效实现我们的验证目标。
图8. 基于模型的设计V模式的开发迭代过程
在软件开发当中，尤其是应用层软件设计时，我们常用基于模型的设计（MBD）方法，比如我们会借助MATLAB Simulink/Stateflow或TargetLink建模工具实现功能建模。基于模型的设计遵循大家所熟知的V模式的开发迭代过程如图8。建模过程主要包括根据软件的需求，进行相应的行为建模，功能建模和实现建模，继而从模型生成代码。基于模型的设计方法的优势之一是使后续V模型的右侧的各层面的测试验证工作可以前置到V模型的左侧，因而后续对代码的测试可以前置为对模型的测试过程，借助合规的代码生成工具的支持，代码层面的测试在某些情况下可等同于对应模型的测试。通过早期对模型软件的测试，可尽早的发现软件的缺陷，最大限度的保障软件质量的安全。
同时在ISO 21434网络安全的标准当中在开发阶段当中也提到：适用于设计、建模或编程语言而本身未保障符合网络安全需求的准则应由设计、建模和编码指南或开发环境涵盖3。例如对安全编码的要求，应使用MISRA C或CERT C在“C”编程语言中进行安全编码。这方面的网络安全相关的属性由相应的设计、建模或编码的规范保证，如C代码的安全性适用MISRA C和CERT C标准，保证编程语言的安全。
另外，适用于设计建模编程语言的指南如运用语言子集，执行强类型实现，使用防御性的实现的技术等，在MBD的早期开发阶段保障编程语言符合对于网络安全的要求。具体来讲，比如对于强类型实现，假设我们用TargetLink建模工具去开发的应用程序如图9，实现和的加和与饱和限制的运算。TargetLink对于所有整数运算，输出数据类型和中间变量的指定值范围必须足以避免溢出。在TargetLink模块集中，原则上通过使用饱限模块来避免溢出和下溢，通过使用具有足够位长度的数据类型进行输出和保存中间结果，避免整数算术中通过整数溢出饱和选项进行饱和约束。
图9. TargetLink建模算术运算的强类型实现
再比如编码规则CERT C中对于浮点类型数据的限制规则，不应使用对象表示方法比较浮点对象。用Simulink建模比较浮点数的等值性，图10（左下）给出了一个具体形象的反例。在Simulink模型chart图表定义数据类型double时，判断逻辑当中给出比较相等的关系判定，是不允许的。建议的做法是给出相应的误差，确保二者的误差在相应的容差范围之内，图10（右下） 。
图10. Simulink建模关于浮点型数据的比较
当然不管是对模型还是对于代码的规则，怎样去具体的在开发中进行正确的建模或编码检查，我们并不需要手动进行。比如我们可以借助建模检查的高效工具，MES Model Examiner来实现模型对于特定建模规则的一致性。比如ISO 26262或者 ISO 21434中强调的建模编程设所适用的规则或指南，已经全面涵盖在MES Model Examiner的规则库当中。除此以外，MES Model Examiner还集成了功能安全及业界优秀实践的规则规范，指导帮助工程师自动地检查模型并修复模型错误。关于给定的安全规则执行检查，MES Model Examiner可以给出模型违反具体规则的一致性报告结果，并可自动纠正违规模型，帮助建模人员更高效地执行静态分析的各项规则检查并生成独立完整的报告，保障模型对安全性需求的可追溯性，最终符合功能的特定ASIL需求，并保障编程语言的网络安全性。MES Model Examiner工具自动化分析并修正模型报告界面如图11。
图11. MES Model Examiner工具自动化分析并修正模型
没有网络安全，就没有相应的功能安全。功能安全和网络安全的协同工程需要全面全生命周期的协作和系统考虑。传统意义上讲，功能安全、网络安全是由不同领域的专业人员从事的不同专业方向研究，也有着不同的专业内容，但在系统的安全层面上，他们又是相互协调统一的整体，应该通盘考虑。汽车知识领域功能安全的管理人员，同时也应协同考虑预期功能安全，网络安全的需求，需要多方互相协调，在矛盾与统一中确定影响系统的主要矛盾与措施优先级，综合全面考虑系统设计方案与安全措施，从而最大限度的保证系统的安全。
之——1功能安全总则
目录
A.7 ISO 26262- 2018与 ISO 26262-2011的文档差异性
A.8 ISO 26262-2018与 ISO 26262-2011的工作成果差异性
A 先导
A.1 文章提要
本文是针对ISO 26262-2018展开，ISO 26262是以IEC 61508为基础，提供一整套方法和流程，来保证所开发的电子电气系统满足功能安全要求，通过功能安全总则、概念阶段、系统开发、软硬开发等多篇文章总结ISO 26262内容，着重于乘用车的相关内容，此篇为“功能安全总则”的总结。
A.2 关于安全的法规
| SOTIF预期安全 | ISO 21448 |
| EE功能安全 | ISO 26262 GB/T 34590 GB 18384 |
| 机械功能安全 | ISO 13849 |
| V2X安全 | ISO 20077 |
| 信息安全 | ISO 21434 |
A.3 适用范围
ISO 26262-2018适用于安装在乘用车、卡车、公共汽车、两轮机动车的一个或多个电子电气系统。
A.4 ISO 26262的目的
将安全风险和危害降低到可接受范围（风险和危害不可能完全被消除）
A.5 ISO 26262标准的概要
ISO 26262中共12个部分，涵盖车辆的整个生命周期，称为安全生命周期（safety lifecycle）是对管理、开发、生产、经营、维修、报废都有响应要求：
| 章节 | 内容 | 对应英文 |
| part1 | 名词解释 | vocabulary |
| part2 | 功能安全管理 | management of functional safety |
| part3 | 概念阶段 | concept phase |
| part4 | 产品开发在系统层面 | product development at the system level |
| part5 | 产品开发在硬件层面 | product development at the hardware level |
| part6 | 产品开发在软件层面 | product development at the software level |
| part7 | 生产，运营，服务和报废 | production ，operation，service and decommissioning |
| part8 | 支持过程 | supporting processes |
| part9 | 车辆安全完整性等级导向与安全导向分析 | automotive safety integrity level(ASIL)-oriented and safety-oriented analyses |
| part10 | ISO 26262指南 | guidelines on ISO 26262 |
| part11 | ISO 26262对半导体器件的应用指南 | guidelines on application of ISO 26262 to semiconductors |
| part12 | ISO 26262对摩托车的适用性 | adaptation of ISO 26262 for motorcycles |
A.6 功能安全设计中所涉及对象
| 汽车行业开发商 | ●主机厂 ●供应商 —系统开发：如动力控制系统 —零部件开发：电子控制器、电机、电池 —元器件开发：汽车MCU、电源芯片、通讯芯片等 | ||||||||
| 安全相关项目人员 | ●公司管理：产品主管、研发主管、质量主管 ●项目管理：项目经理、产品经理 ●研发人员：系统工程师、软/硬件工程师、测试工程师、质量工程师 | ||||||||
| 涉及相关系统 | ●驾驶辅助 ●动力系统 ●主动和被动安全
|
A.7 ISO 26262- 2018与 ISO 26262-2011的文档差异性
| 序号 | part | 2018 | 2011 | 备注 |
| 1 | 1：vocabulary | 章节目标描述更清晰 | 章节目标描述较为笼统 | 目标细化 |
| 2 | 总共12部分，新增： part11：ISO26262对半导体器件的应用指南 part12：ISO26262对摩托车的适用性 | 总共10个部分 | 增加2个部分 | |
| 3 | 适用范围： 乘用车、卡车、公共汽车、拖车和半拖车道路车辆 | 适用范围： 最大质量为3.5吨的乘用车 | 适用范围扩大 | |
| 4 | 增加“安全异常管理” | 无 | 管理范围扩大 | |
| 5 | 增加“卡车、公共汽车、拖车和半拖车的相关的交互与集成” | 无 | 适用范围扩大 | |
| 1 | 2：功能安全管理 | 2-6：“依赖于项目的安全管理” 2-7：“生产、运行、服务和报废的安全管理” | 2-6：“概念阶段和产品开发过程中的安全管理” 2-7：“相关项生产发布后的安全管理” | 名称变更 |
| 2 | 2-5增加： “关于功能安全的安全异常管理” “建立功能安全和网络安全的沟通渠道” | 无 | 增加 | |
| 3 | 2-6增加： “基于要素的影响分析” “基于相关项的影响分析” “功能安全概念” “技术安全概念”的认可评审 | 无 | 增加 | |
| 4 | 增加“附录E 功能安全与网络安全潜在互动指南” | 无 | 增加 | |
| 5 | “生产发布”调整到2-6 | “生产发布”位于4-11 | 移动 | |
| 6 | “基于要素的影响分析”调整到2-6 | “基于要素的影响分析”位于3-6 | 移动 | |
| 7 | 无 | “附录D 验证评审概览” | 删除 | |
| 1 | 3：概念阶段 | 增加卡车、公共汽车、拖车和半拖车的危害分析和风险评估 | 无 | 增加 |
| 2 | 附录B中，增加“卡车、公共汽车、拖车和半拖车基于运行场景持续时间的暴露概率分级”和“卡车、公共汽车、拖车和半拖车基于运行场景频率的暴露概率分级” | 无 | 增加 | |
| 3 | 如果几个不太可能的情况组合在一起，导致暴露的可能性比E1低，则对E1&S3&C3风险矩阵组合，可以从ASIL A变为QM | E1&S3&C3风险矩阵组合，对应ASIL A | 修改 | |
| 4 | 工作成果“安全分析”位于2018：2-6“依赖于项目的安全管理” | 工作成果“安全分析”位于2018：3-6 | 移动 | |
| 1 | 4：产品研发在系统层面 | “项目计划”、“安全计划”、“相关项集成和测试计划”、“验证计划”、“功能安全评估计划”移动合并到2-6里 | 4-5 工作成功包括：“项目计划”、“安全计划”、“相关项集成和测试计划”、“验证计划”、“功能安全评估计划” | 移动 |
| 2 | 将2011：4-6和2011：4-7合并为2018：4-6“技术安全概念” | 4-6：“技术安全要求的定义” 4-7：“系统设计” | 合并 | |
| 3 | “确认计划”位于2018：2-6“依赖于项目的安全管理” | “确认计划”位于2011：4-9“安全确认” | 移动 | |
| 1 | 5：产品研发在硬件层面 | “安全计划”位于2018：2-6“依赖于项目的安全管理” | “安全计划”位于2011：5-5“启动硬件层面产品开发” | 移动 |
| 2 | 无 | 删除2011：5-附录F“比例因子的应用” | 删除 | |
| 3 | 增加： 2018：5-附录F“满足9.4.2目标的示例”、 2018：5-附录G“由两个系统组成的项目的PMHF预算分配示例”、 2018：5-附录H“潜在故障处理示例” | 无 | 增加 | |
| 1 | 6：产品研发在软件层面 | “软件验证计划”位于2018：2-6“依赖于项目的安全管理” | “软件验证计划”位于2011：6-5“启动软件层面的产品开发” | 移动 |
| 2 | “软件验证报告”位于2018：6-9“软件单元测试” | “软件验证报告”位于2011：6-8“软件单元测试” | 移动 | |
| 3 | 扩充2018：6-附录B“基于模型开发”内容 | 2011：6-附录B“基于模型开发” | 扩充 | |
| 4 | 扩充2018：6-附录E“软件体系架构级安全性分析和依赖性故障分析的应用” | 无 | 增加 | |
| 1 | 7：生产与运行 | 将2011：7-5“生产”拆分为2018：7-5“生产、运营、服务和报废计划”和2018：7-6“生产” | “生产位于2011：7-5 | 拆分 |
| 1 | 8：支持过程 | 新增2018：8-15“与超出ISO26262的应用程序建立接口”，用于卡车、公共汽车、拖车和半拖车 | 无 | 新增 |
| 2 | 新增2018：8-16“未根据ISO26262开发的安全相关系统的集成”，用于卡车、公共汽车、拖车和半拖车 | 无 | 新增 | |
| 1 | 9：基于ASIL和安全的分析 | 新增2018：9-附录B“要素共存和需求分析的示例架构” | 无 | 新增 |
| 2 | 新增2018：9-附录C“识别相关失效的架构” | 无 | 新增 | |
| 1 | 10：ISO 26262指南 | 新增2018：10-12“具有安全相关可行性要求的系统开发指南” | 无 | 新增 |
| 2 | 新增2018：10-13“评价“所使用软件工具的置信度”” | 无 | 新增 | |
| 3 | 新增2018：10-14“安全相关特性指南” | 无 | 新增 | |
| 4 | 无 | 删除2011：10-附录A“ISO26262和微控制器” | 删除 |
A.8 ISO 26262-2018与 ISO 26262-2011的工作成果差异性
| ISO 26262-2018 | ISO 26262-2011 | 对比分析 | ||||
| part2：功能安全管理 | part2：功能安全管理 | |||||
| 章节 | 名称 | 具体内容 | 章节 | 名称 | 具体内容 | |
| 2-5 | 整体安全管理 | 5.5.4已确认的安全异常报告 | 2-5 | 整体安全管理 | / | 增加一个工作成果 |
| 2-6 | 依赖项目的安全管理 | 6.5.1相关项层面的影响分析 | 2-6 | 概念阶段和产品开发过程中的安全管理 | 6.5.2项目计划 | ①增加2个分析成果 ②删除项目计划成果 ③原内容调整，具体见文档差异分析 |
| 6.5.2要素层面上的影响分析 | ||||||
| 2-7 | 生产、运营、服务和报废方面的安全管理 | 7.5.1关于生产、运营、服务和报废的安全管理证据 | 2-7 | 相关项生产发布后的安全管理 | 7.5现场监控的证据 | 章节内容调整，具体见文档差异分析 |
| part3：概念阶段 | part3：概念阶段 | 分析 | ||||
| / | / | / | 3-6 | 安全生命周期启动 | 6.5.1 影响分析 | 删除旧版章节 |
| 6.5.2 安全计划 | ||||||
| 3-6 | 危害分析和风险评估 | / | 3-7 | 危害分析和风险评估 | 7.5.2 安全目标 | 删除旧版里的安全目标成果 |
| part4：产品开发在系统层面 | part4：产品开发在系统层面 | 分析 | ||||
| 4-5 | 系统级产品开发概览 | / | 4-5 | 启动系统层面产品开发 | 5.5.1项目计划 5.5.2安全计划 5.5.3相关项集成和测试计划 5.5.4确认计划 5.5.5功能安全评估计划 | 删除旧版工作成果 |
| 4-6 | 技术安全概念 | / | 4-6 | 技术安全要求的定义 | 6.5.2系统验证报告 | ①旧版第6，7章内容合并到第6章 ②删除旧版3项工作成果 ③新增1项工作成果 |
| / | 6.5.3确认计划 | |||||
| 6.5.6系统架构设计，软硬件接口规范、生产、运行、服务和报废的需求规范和技术安全概念的验证报告 | 4-7 | 系统设计 | 7.5.5系统验证报告 | |||
| 4-7 | 系统与相关项的集成与测试 | 无 | 4-8 | 相关项集成和测试 | 8.5.1相关项集成和测试计划 | 删除旧版的集成和测试计划成果 |
| 4-8 | 安全确认 | 8.5.1包括安全确认环境描述的安全确认规范 | 4-9 | 安全确认 | 9.5.1确认计划 | ①旧版第9、10章内容合并到新版第8章 ②删除旧版第11章 ③删除旧版确认计划 ④新版新增1项确认规范成果 |
| 9.5.2确认报告 | ||||||
| 8.5.2安全确认报告 | 4-10 | 功能安全评估 | 10.5.1功能安全评估报告 | |||
| / | 4-11 | 生产发布 | 11.5.1生产发布报告 | |||
| part5：产品开发在硬件层面 | part5：产品开发在硬件层面 | 分析 | ||||
| / | / | / | 5-5 | 启动硬件层面产品开发 | 5.5安全计划 | 删除旧版章节 |
| 5-10 | 硬件集成和测试 | 10.5.1硬件集成和验证规范 | 5-10 | 硬件集成和测试 | / | 新版新增1项工作成果 |
| part6：产品开发在软件层面 | part6：产品开发在软件层面 | 分析 | ||||
| 6-5 | 软件级产品开发概览 | 5.5.1软件开发环境文档 | 6-5 | 启动软件层面产品开发 | 5.5.1安全计划 5.5.2软件验证计划 5.5.3模型语言和编程语言的设计和编码指南 5.5.4工具应用指南 | ①删除旧版工作成果 ②新版新增1项工作成果 |
| 6-7 | 软件架构设计 | / | 6-7 | 软件架构设计 | 7.5.2安全计划 7.5.3软件安全需求规范 | 删除旧版2项工作成果 |
| 6-8 | 软件单元设计和实现 | / | 6-8 | 软件单元设计和实现 | 8.5.3软件验证报告 | 删除旧版1项工作成果 |
| 6-9 | 软件单元测试 | / | 6-9 | 软件单元测试 | 9.5.1软件验证计划 | 删除旧版1项工作成果 |
| 6-10 | 软件集成和测试 | / | 6-10 | 软件集成和测试 | 10.5.1软件验证计划 | 删除旧版1项工作成果 |
| 6-11 | 软件安全要求验证 | / | 6-11 | 嵌入式软件测试 | 11.5.1软件验证计划 | 删除旧版1项工作成果 |
| 6-附录C | 软件配置 | / | 6-附录C | 软件配置 | C.5.3安全计划 | ①删除旧版2项工作成果 ②新版新增2项工作成果 |
| C.5.6软件验证计划 | ||||||
| C.5.8软件架构设计规范 | / | |||||
| C.5.9软件开发环境文档 | ||||||
| part7：生产与运行 | part7：生产与运行 | 分析 | ||||
| 7-5 | 生产、运行、服务和报废计划 | 5.5.10救援服务说明的安全相关内容 | / | / | / | 新版新增1项工作成果 |
| part8：支持过程 | part8：支持过程 | 分析 | ||||
| 8-12 | 软件组件的鉴定 | 12.5.3软件组件质量验证报告 | 8-12 | 软件组件的鉴定 | 12.5.3安全计划 | ①删除旧版1项工作成果 ②新版新增1项工作成果 |
| 8-14 | 在用证明 | / | 8-14 | 在用证明 | 14.5.1安全计划 | 删除旧版1项工作成果 |
| 8-15 | 与超出ISO26262范围的应用程序的接口 | 15.5.1基本车辆制造商或供应商指南 | / | / | / | 新版增加章节内容 |
| 8-16 | 未按ISO26262开发的安全相关系统的集成 | 16.5.1安全理由 | / | / | / | |
1 术语
1.1 安全
safety，风险降到可接受范围，即认为是安全
1.2 功能安全FS
functional safety，不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险
1.3 风险
risk，伤害的严重性和出现伤害的概率的组合：Risk=严重度*概率
1.4 伤害
-harm，对人身的损害或对人健康的损害
-不考虑对物的影响
1.5 相关项
item，实现整车基本功能的系统或一组系统
1.6 系统
system，一组元素，至少包括传感器、控制器、执行器，如ABS系统、制动系统等
1.7 组件
component，非系统级别的元素，在逻辑上可分离的单元，如速度传感器、雨量光传感器
1.8 硬件组件
hardware part，不能再进一步划分的硬件，如电阻、电容、MCU等
1.9 要素
element，系统或系统的一部分，包含组件、硬件、软件或软件单元
1.10 架构
architecture，相关项、功能、系统或要素的结构的表征，用于识别结构模块及其边界和接口，并包括硬件和软件要素的要求分配
1.11 功能概念FC
functional concept，为实现预期的表现所必须的各功能及其交互的定义
1.12 功能安全概念FSC
functional safety concept，为实现安全目标，定义功能安全要求及相关信息，并将要分配到架构要素上，以及定义要素之间的必要交互
1.13 功能安全要求FSR
functional safety requirement，定义了独立于具体实现方式的安全行为或独立于具体实现方式的安全措施，包括安全相关的属性
1.14 安全状态
safety state，没有不合理风险的相关项的运行模式
1.15 汽车安全完整性等级ASIL
automotive safety integrity level，分A/B/C/D四个等级，每一个等级定义了相关项或要素的必要的要求和安全措施，以避免不合理的残余风险，D最严格，A等级最低
1.16 开发接口协议DIA
development interface agreement，客户与供应商间的协议，协议规定了双方在相关活动中各自承担的责任，应提供给对方的证据或工作成果
1.17 分布式开发
distribute development，在客户和供应商之间分配整个相关项、要素或子系统开发责任的相关项或要素的开发
1.18 技术安全概念TSC
Technical safety concept，制定技术安全需求，满足功能安全要求的系统架构
1.19 技术安全要求TSR
Technical safety requirement，满足安全目标SG或功能安全需求FSR，由功能安全需求FSR在技术层面派生出的可实施的安全需求
1.20 车辆交互VC
vehicle capability
2 功能安全实现的5个步骤
| Step1： 明确产品是否需要功能安全？ | ●先定义产品，产品需要综合单件成本、制造难度、可靠性要求等来明确产品的功能，再从功能明确是否需要功能安全： ①、功能失效会导致危害事件？ ②、功能丧失会导致危害事件？ ③、危害分析和风险评估来证明需要ASIL。 | ||||||||||||||||||||||||
| Step2： 构建安全管理组织架构和项目团队 | ①项目团队： —开发团队与审核团队要独立
②构建管理组织架构： —制定流程制度、为安全工作的协调和监控提供框架
| ||||||||||||||||||||||||
| Step3：确定需要考虑的危害事件 | ①通过系统的危害分析和风险评估，确定需要考虑的危害事件： 例如：高速路行驶时 -安全气囊意外弹开； -制动系统失效，无制动力输出 -... ②对每个可识别的危害事件，定义相应的安全目标（safety goal） 例如安全目标：车辆正常行驶时，安全气囊不能弹开 ③根据危害分析和风险评估确定ASIL等级。 | ||||||||||||||||||||||||
| Step4：进行系统、软硬件设计和开发 | ①根据安全目标，做出安全概念（safety concept），安全概念包括： -系统基本架构； -达到并保持安全的技术措施。 ②根据安全概念，进行系统层、软硬件的设计和开发； ③开发中，采取必要的安全措施和验证活动。 | ||||||||||||||||||||||||
| Step5：验证 | ①通过安全确认的手段和方法，确保所开发的项目满足分配的安全目标； ②产品生产导入、销售。 |
————————————————————————
参考资料：
iso26262之2018版与2011版主要内容对比与分析…_汽车功能安全-商业新知
以上是关于功能安全预期功能安全与信息安全的差异与协同的主要内容，如果未能解决你的问题，请参考以下文章