小鱼仙倌的博客

功能安全之“不同SIL软件的隔离原则”

TI 的功能安全开发流程源自 ISO 26262:2018 和 IEC 61508:2010，是一套用于半导体开发的要求和方法。面向客户的工作产品采用这种功能安全合规型流程，并适用于 ISO 26262:2018 和 IEC 61508:2010 之外的许多其 他功能安全标准。• 整合通过多项功能安全组件开发、功能安全标准工作组和 TI 客户专业知识获得的经验教训。• 基于 TI 在功能安全应用组件方面的经验对系统级设计、功能安全概念和要求作出的假设。• 组件开发期间功能安全工作产品的文档。

与ISO 26262不同，该活动应规定FSR，并考虑驱动程序的行为，特别强调其与项目其他组件的交互/依赖性，这有助于在以后的活动中将FSR分配给项目的元素。此外，MAS将包括一个软件系统，该系统能够在适当的时间内分析所有提示信息，以确定驾驶员的操纵是有意的，即它是需求、欲望和/或动机的结果，还是无意的，即没有执行此类操纵的需求、欲望和/或动机。在我们的方法中，该活动被扩展为考虑作为项目的一个组成部分的驱动程序，即，在项目的定义期间，也考虑了驱动程序（组件）和项目的网络和物理组件之间的依赖关系和交互。

随着各行各业在产品开发设计和测试过程中都采用了一套标准化的实践，安全实践也变得越来越规范。汽车行业也不例外，功能安全标准 ISO-26262 满足了针对安全关键零部件的汽车专用国际标准的需求。ISO-26262是电气和电子（E/E）系统的通用功能安全标准。本文将结合ISO-26262，从什么是功能安全、什么是功能安全工程师以及功能安全工程师主要做什么，三个方面展开对功能安全的介绍。

随着自动驾驶道路测试数据和大量的极端场景数据的积累， 自动驾驶核心算法通过数据驱动的深度学习算法模型， 得以持续不断进化， 成为能够提前预判、 安全谨慎驾驶的“老司机”。车辆能够实时接收感知模块提供的环境和障碍物信息， 结合高精度地图， 跟踪并预测周边车辆、 行人、 骑行者或其他障碍物的行为意图和预测轨迹， 综合考虑安全性、 舒适性和效率， 生成驾驶行为决策（跟车、 换道、 停车等） ， 并按照交通规则和文明交通礼仪对车辆进行运行规划（速度、轨迹等） ， 最终输出到控制模块实现车辆加减速和转向动作。

汽车相对地铁列车，控制设备的安装空间较为有限，不同车辆的个体差异较大，其无人驾驶技术的实现方案需要更简约，主流的方案通常是通过多种车载传感器（如摄像头、激光雷达、毫米波雷达、北斗/GPS、惯性传感器等）来识别车辆所处的周边环境和状态，并根据所获得的环境信息自主地控制车辆运动，最终实现无人驾驶。

功能安全在最近几年特别火，搞电子研发特别是汽车电子的，几乎所有的新项目都会被反复提及。但实际上功能安全早在20世纪60~70年代就已经被提出，并最早应用于航空和核技术等对安全可靠性要求极高的领域。随着近些年汽车电子行业高速发展，特别是汽车的新能源化、智能化，已让汽车的本质不再是机械式机器而变为一个电子控制系统，而这个电子系统的故障又极可能导致事故、人员伤害或死亡，所以功能安全已经是新设计车型的一项基本要求。

随着汽车行业复杂性的日益提升，人们加大了开发安全合规系统的力度。例如，现代汽车使用线控系统，如油门线控。司机踩油门时，踏板中的传感器将向电子控制元件发送信号。该控制单元将分析多种因素，如引擎速度、车辆速度及踏板位置。接着，控制单元将向油门传递指令。对油门线控这类系统进行测试和验证，对汽车行业造成了挑战。

安全完整性等级（Safety Integrity Level，SIL）是国际标准IEC61508中定义的一种离散性的等级，它用来衡量安全相关系统成功执行规定的安全功能的概率。概率越高，则安全完整性等级越高。安全完整性等级分为4个级别，即SIL1、SIL2、SIL3和SIL4。其中SIL4最高，SIL1最低。

随着汽车智能化和电气化技术的快速普及，车内控制器和各种电子部件越来越多，而各类电子部件都存在系统性失效和随机硬件失效的风险，因此相应的汽车功能安全变得越来越重要。

冗余是实现安全设计的关键技术之一，本文对于冗余的相关基础知识进行了介绍

简单阐述了车联网信息安全现状，并对电控单元 (ECU) 信息安全概念和空中下载技术 (OTA) 概念进行了简要描述；其后，主要分析了车联网典型应用场景 OTA 数据链路中的安全威胁和风险向量；最后，提出了电控系统网络信息安全架构的整体设计思路，从车载终端、传输链路和云服务器三个层面对安全需求和防护机制进行了详细解析。

在芯片行业总体下行周期，汽车电子赛道保持相对坚挺，在新品推出和投融资方面都表现出积极的态势。细追背后缘由，是软件定义硬件、算力驱动马力、比特管理瓦特的时代变革下，传统汽车产业链格局受到冲击，汽车电子需求不断扩大所致。

简介当今汽车行业的创新正在加速，因为各公司正在竞相成为安全和自动驾驶车辆领域的市场领导者。随着车辆控制正在从人类转变为车辆的主动安全系统，更多传感器 – 摄像头、雷达、激光雷达等 – 正被添加到汽车系统中。更多的传感器需要更大的 SoC 提供的更多计算性能，以处理额外的传入数据，并尽可能降低故障率。因此，自动驾驶汽车要求提高处理性能和安全要求的数量级。这些更大的 SoC 需要最先进的处理器架构，以提供具有最高汽车安全完整性水平 (ASIL) 所需的处理性能。具有传感器的安全系统，其中一个实例是基于雷达的

本文首先简单阐述了车联网信息安全现状，并对电控单元 (ECU) 信息安全概念和空中下载技术 (OTA) 概念进行了简要描述；其后，主要分析了车联网典型应用场景 OTA 数据链路中的安全威胁和风险向量；最后，提出了电控系统网络信息安全架构的整体设计思路，从车载终端、传输链路和云服务器三个层面对安全需求和防护机制进行了详细解析。随着汽车电子控制系统功能复杂度和数据颗粒度呈阶梯式增加，其发展速度逐渐超越网络安全防护方法、技术和标准的发展，现阶段汽车电子正面临巨大的网络信息安全风险，对功能安全的潜在影响也仍在探索

Life Cycle Security /生命周期安全生命周期安全涵盖的安全原则是：从系统生命周期的视角，覆盖了从初始实现系统安全到持续维护系统安全所需要的一些原则，这些原则有助于系统的可理解性、可维护性、完整性。1. Repeatable and Documented Procedures /可重复的文档化流程可重复的文档化流程原则是指：系统组件（或某个工作产品，如：测试结果）被安全构建之后，可以在需要的时候，根据流程（包括相应的技术、方法）再次被重新构建。可重复的文档化流程应用在系统生命周期的各

Security Capability and Intrinsic Behavior /安全的能力与行为安全的能力与行为相关的设计原则是指：为实现安全，必须要定义、设计和实施的系统行为。这些行为通常体现在系统安全需求中。 图片1. Continuous Protection /持续不间断保护持续不间断保护原则是指：实施安全策略的组件或数据，需要被持续的不间断的保护。例如，在如下场景时，都需要考虑持续不间断保护：数据处于不同状态时，如：数据创建、存储、处理或通信时系统处于不同运行模式时，如：初始化

概述开发安全相关系统时，ISO/SAE 21434:2021建议遵循安全领域的设计原则。ISO/SAE 21434:2021 Clause 10.4 [RC-10-06] Established and trusted design and implementation principles should be applied to avoid or minimize the introduction of weaknesses.本文参考如下标准，介绍设计原则的第1部分: Security Archi

在功能安全系统开发中，开发生命周期依据系统工程V模型，分为系统级、硬件级和软件级，将开发生命周期划分为多个阶段，每个阶段包括输入，过程要求、输出、使用的工具方法、验证要求，本文以汽车软件功能安全标准ISO26262-6和轨道交通安全软件EN50128为基础，谈谈不同领域中功能安全软件开发模型的各自特点。在ISO26262-6 2018功能安全软件级的第5节，指出应为汽车安全软件开发定义软件开发阶段，给出了参考模型。将软件开发分为了6个阶段：软件安全需求规范（6-6）；软件架构设计（6-7）；软件单

2016年9月9日，通用汽车网站上一条简短的召回公告显示，由于“负责控制安全气囊和安全带束紧功能的感知和诊断模块（Sensing and Diagnostic Module）存在缺陷，在极少数情况下可能导致安全气囊无法正常弹出”，因此在美国市场召回约364万辆汽车。次日，路透社称通用召回的汽车数量将达430万辆，且该缺陷已造成一人死亡、三人受伤。在当时高田（Takata）安全气囊事件持续发酵、各大厂商召回规模数以千万辆计的背景下，通用汽车的这次「共计花费12亿美元的」“小批量召回”并未得到太多关注。然而

软件级产品开发作为功能安全V流程中的一个重要组成部分，在产品功能安全开发的过程中具有举足轻重的地位。它以技术安全概念（TSC）为直接输入，软件开发V模型的左侧是软件的设计（①软件安全需求规范；②软件架构设计；③软件软件单元设计和实现），V模型的右侧是测试和验证（①软件单元验证；②软件集成和验证；③嵌入式软件测试）。在软件集成和验证部分，道路车辆功能安全标准ISO26262-2018 Part 6推荐ASIL_C和ASIL_D应采用背靠背测试的方法；在嵌入式软件测试部分，道路车辆功能安全标准ISO26262

为了降低汽车碰撞事故，保障交通安全，汽车领域逐步在引入全新的出行概念，自动驾驶技术因此应运而生，并在过去的几年里经历了前所未有的飞速发展。安全，是自动驾驶的初心！国内外自动驾驶玩家似乎也都意识到安全的重要性，自动驾驶安全第一的白皮书在大众、奥迪、百度、宝马、德国大陆集团、戴姆勒、菲亚特克莱斯勒、HERE、英飞凌、安波福和英特尔这11家行业代表的推动下也已发布，然而自动驾驶作为一个相对崭新的领域，不仅涉及传统汽车的动力学控制，而且需要人工智能的感知融合算法，超大算力的数据处理能力，它颠覆了传统的控制技术，

记住重点一：软件架构设计的目的是划分软件层次结构，确定软件各模块及模块之间的相互关系。记住重点二：软件架构设计应与软件需求形成双向追溯关系，确保软件需求实实在在落实到设计里。记住重点三：ISO26262中对软件架构设计提出了一系列如下规则，按照不同的SIL等级可以选择使用。对于强烈推荐的内容，在实际开发过程中应保证完全遵循与使用，如果有些规则没有运用到，需要给出合理的解释与证明，证明即使没有使用这项规则，依然可以通过其他方式保证功能安全性。关于这些规则的运用，很多同学也是充满迷惑。例如，适宜的软件

随着汽车电子行业的发展，源自于IEC61508电子电气通用标准的ISO26262标准于2011年应运而生，标志着汽车电子领域终于有了自己的特定标准。第一版ISO26262发布后，随着应用过程的经验积累，发现了标准中存在有待优化的过程方法与技术，ISO国际标准组织于第一版标准发布五年后，开始着手于第二版标准的修改完善工作，并于2018年底登场。关于ISO26262第二版标准，每一位从事功能安全领域的人都翘首以待，今天本文将系统的给大家归纳总结一下新旧版本差异。旧版：适用范围仅局限在重量不超过3.5吨的乘

在功能安全实践过程中，软件安全至关重要，软件的特殊性在于它的失效不可量化，一个小小的失误在特定环境下就可能无限放大。在功能安全强调软件安全性的时候，往往与软件可靠性密不可分，航空领域一般讲究可靠性，而轨道交通领域和汽车领域通常讲究安全性，那么对于软件而言，安全性与可靠性到底是怎么的关系与区别，很多人存在这方面的疑惑，今天的功能安全小课堂带领大家一起探索研究一下。首先分别从软、硬件安全性与可靠性的关系来区分软件安全性的特点，软件安全性和软件可靠性到底是不是一回事，很多专家大咖仁者见仁智者见智，本文以下内容仅

从事功能安全多年来，经常有人问我如何快速学习安全标准，其实学习本身没有捷径，尤其是针对功能安全学科，最重要的靠项目经验积累。但是任何事情找对方法都可以事半功倍，我个人比较提倡的功能安全学习方法是从宏观到微观，从面到线再到点，前期学习不用过于陷入细节中，要对功能安全形成正确的宏观认识，然后再逐步细化，逐个攻破。今天仅用4张图带你宏观学习ISO26262标准，即使0基础的人，相信看完后也能了解到ISO26262讲了啥。所有的功能安全标准都可以用两个词概括：功能安全技术、功能安全管理。无论IEC61508、E

第一招：人中国有句古话，做一件事需要天时地利人和，其实，搞砸一件事也是如此。天时地利属于客观条件，今天要教大家的是即使客观条件有利于功能安全，我们也要靠主观彻底破坏彻底搞砸的方法。我命由我不由天，所以我们先主要讨论下“人”的问题。如果一个功能安全项目中每一个角色都有很强的责任心和使命感，认真踏实，遵规守纪，技术优秀，能力称职，那么搞砸这个产品的功能安全难度太大了，但是不要灰心，只要你认真挖掘，有些项目中总会有那么几个能够助攻你完成破坏大业的人，如果这样的人又是处在比较重要的角色上，例如处在决策者、总工/

近年来，功能安全似乎变得热门了，从工控行业到轨道交通再到汽车行业，功能安全逐渐成为安全相关产品的必要需求，在热度不断攀升的同时也带来了更多质疑的声音，功能安全是鸡肋还是珍宝？到底是否值得花费大量的人力、资源、成本去实现产品的功能安全呢？表面来看，功能安全好像有点纸上谈兵，因为一切要以证据说话，证据又都是体现在白纸黑字的文档上，由此产生的误解便是功能安全主要是文档功夫。所谓外行看热闹，内行看门道，真正的功能安全一定不能从表面来认知，而要深入到技术里，功能安全与技术息息相关。随机失效和系统失效了解功能安全