作者 | 吴丹丹
出品 | 汽车电子与软件
吴丹丹老师的新书《智能汽车软件功能安全》终于出版了，这是一本从实践角度系统且深入地讲解智能汽车软件功能安全和智能汽车软件研发的著作。吴丹丹在功能安全领域深耕10余年，有扎实的理论基础、丰富的实践经验，用挖掘本质的思维方法来撰写本书，从研发体系、架构设计、开发流程、开发方法、安全措施、创新研究等维度对智能汽车软件功能安全做了深入的讲解。特别推荐给大家！
前言：
本文内容是结合《智能汽车软件功能安全》中第2章智能汽车软件安全痛点和第7章智能汽车软件功能安全的创新研究的内容进行的概括总结，原书这两章节共涉及近4万的文字和10余张图表，如想了解更深层次的痛点原因分析及对应的详细解决方案，可参考查看原书内容。安全一直是智能汽车发展的初心，智能汽车的目标本质就是通过自动驾驶能力的提升，由车辆智能化系统逐步替代人来操作汽车，从而规避由驾驶员因素引起的大量交通事故，达到安全出行的目的，最终实现零事故的愿景。所以，这就要求智能汽车的系统本身在运行过程中能够提供强大的安全保障能力，达到真正的功能安全。智能汽车行业正在蓬勃发展，像一个朝气的少年一路向前奔跑，而功能安全作为一个传统主题，是一套基于经验总结形成的固定规则和规范标准的方法论，它是一种相对保守的思路，就像一个垂暮的老人，有着丰富的人生阅历可以指导年轻人的行为，但同时也有着一些默守陈规的思维方式已不适用于新生事物的特性，没有与时俱进，无法做到与新需求完全匹配。功能安全虽然也在极力开拓新思路适应新事物，在传统功能安全的基础上又衍生出预期功能安全的概念，但是其发展更新速度与智能汽车技术创新速度之间仍然存在很大的差距，就像小步挪动的老人追赶不上大步奔跑的少年，因此，目前智能汽车在功能安全方面存在盲区，给从业人员带来诸多迷茫和困惑，这些内容构成了当下智能汽车的安全痛点，对于这些痛点的解决，行业内还处于一种混沌状态。现实中反映出来的结果就是大多数从业者没有明确意识到痛点的本质是什么，从而无力去确定方案真正解决这些痛点，在实际做法上，要么只是选择局部明确的部分完成局部功能安全，未覆盖的盲区暂且不管；要么选择直接忽视功能安全，先自由发展，而结果是痛点却在那里一直真实的存在，在未来某个时刻这些安全痛点一定会成为制约智能汽车继续发展落地实践的致命要素。剖析痛点根本原因，分为“不适用”和“不确定”两方面，只有找到了这些痛点的本质，才能寻求对应的办法，突破局限，解决痛点。 在智能汽车功能安全领域，工程师经常会在工作过程中感到困惑，对于现实中的一些功能安全问题，目前在标准规范以及各种资料信息里找不到对应的答案，而用现在已有的信息去解决这个问题又会有些力不从心，并不能真正达到功能安全。另外，在设计开发过程中，工程师们也常常会把可靠性设计当做安全性设计，这是有一定关联性但又完全不同的两个概念，如果混为一谈，那么就可能忽略掉真正影响安全的关键要素，从而在设计中留下隐患。还有一种以偏概全的现象，产品中只有一部分内容做到了功能安全就误以为系统整体安全了，但实际从系统工程的角度，存在很多风险和危害，安全无从谈起。这些问题总结来说，就是用一种不适用的标准、概念或方法去完成智能汽车领域的功能安全工作，从而埋下安全隐患。在智能汽车领域，传统功能安全与预期功能安全并行推进，虽然把功能安全的定义补充完整了，但是标准的内容还是不足以完全应对实际应用中的复杂问题，存在诸多问题与局限性，主要表现为以下几点：- 功能安全缺乏整体化的规范要求，即在产品开发过程中传统功能安全和预期功能安全缺乏整体统筹和关联互通。
- 功能安全标准对智能汽车方面积累经验不足，即缺少最佳实践和可参考的足够数据与示例。
- 缺乏人工智能相关的功能安全标准，即当下功能安全标准不足以指导人工智能的安全开发。
除了标准的不适用外，目前在智能汽车领域以及其他领域研发设计与工程实践中，很多人对安全性和可靠性的理解也存在误区，在智能汽车领域这种现象尤为严重，误以为把系统做到了高可靠就可以带来高安全性，或者进行了功能安全设计就认为达到了高可靠性。其实安全性和可靠性是完全独立的两个概念，一定不要混为一谈，否则会陷入一种思维误区，把这种错误的思想应用在设计实践中，最终就会导致无论是功能安全设计还是可靠性设计可能都会处于一种似是而非的状态，做不到真正的安全和真正的可靠，所以在智能汽车的开发过程中必须要从本质上深刻区分安全性和可靠性，才能真正有效运用相关技术，达到相应的安全目标或可靠性目标。
可靠性与安全性之间的关系大致可分为两种情形。首先，可靠性的目标是明确的，即保持完成特定功能或任务的能力。而安全性的目标则有两种可能：一种是通过完成特定功能或任务来实现安全目标；另一种是通过限制或停止特定功能或任务来达到安全目标。在智能汽车领域的应用中，根据具体场景确定所涉及的安全性属于哪一种情况至关重要。若属于第一种情况，则安全性和可靠性在一定程度上互为补充，在某些方面可能会相互促进；若属于第二种情况，则安全性和可靠性可能会出现矛盾。此外，在智能汽车安全问题讨论中，局部安全与系统安全的概念经常被混淆。比如，在介绍智能汽车时，提到“智能驾驶域控制器的功能安全达到ASILD级别”，很多人可能会错误地推断整个智能驾驶系统是安全的。再比如，在产品安全设计过程中，由于时间、成本和技术难度的考虑，常常会牺牲某些部分的安全考量，只集中保障关键部分的安全设计。这些被忽略的部分往往成为潜在的安全风险，在特定条件下可能导致事故。这两个例子反映了现实中常见的问题，无疑会在智能汽车领域引起一些安全隐患。这些问题根本上是因为缺乏对局部安全和系统安全关系的正确理解，导致两者概念上的混淆，成为智能汽车安全领域的一个主要难点。只有准确把握智能汽车中局部安全与系统安全的关系，才能有效进行功能安全工作，确保智能汽车的安全驾驶。 确定性与不确定性实际是一种与风险相关的博弈，当事物具有确定性的时候，可以通过规律来衡量确定性，相应的结果就会以一定的规律分布，当预期内容满足要求时，风险就已经降低到可接受的程度了；而当事物具有不确定性的时候，无法通过规律来确定结果趋势，这种不确定性可能会对以往的经验、习惯、认知产生挑战，导致结果充满风险。安全的本质其实就是在追求一种确定性，通过技术方法、流程规范消除产品中的不确定性，降低风险，让最终的结果以预期的规律满足目标要求。目前在智能汽车领域，随着智能化的发展，众多高新技术的应用，很多创新的内容颠覆了以往的认知，给智能汽车的安全性带来巨大的不确定性。智能汽车应用场景中，道路交通环境复杂，不仅涉及众多的静态交通元素，而且涉及复杂多样的动态交互变化，智能汽车在运行过程中，可能遇到很多不可预测的情况，智能汽车需要基于有限的设计与机器学习的能力来应对千变万化的应用场景，面临极大的不确定性。人工智能技术的本质是让软件具有人类的思维能力，采用机器学习等核心技术、通过神经网络等高级算法实现智能化。而人类的思想存在不确定性，因为人类对每一件事物的认知都是基于每个人的经验阅历形成的，带有各自的主观意识，这种主观意识和客观事物之间可能存在认知偏差，这种偏差就构成了思想结果的不确定性。人工智能技术存在类似不确定性，智能算法模型与客观的实际事物之间也会存在差异，导致最终结果可能存在不同程度的偏差。随着汽车行业“新四化”的发展和智能汽车“硬件趋同、软件定义、数据驱动、车路云协同”的总体趋势，软件在智能汽车领域占据重要地位。同时，软件代码量也在呈爆发式增长，十年前的传统汽车软件代码量可能只有千万行级别，而如今智能汽车的代码量已经达到数亿行的级别，这些海量代码为智能汽车提供多样化功能和服务的同时也带来了巨大的不确定性。首先应基于系统工程进行安全构建。智能汽车的安全性是一个复杂的任务，很多智能技术已经超越了传统功能安全标准的范畴，又不能完全归属于预期功能安全，并且随着人工智能大模型技术在智能汽车领域的发展与应用，智能汽车的安全性可能变得更加复杂，单一采用功能安全防护或预期功能安全防护已经不能完全解决智能汽车的安全问题，或者单一保障某个零部件的安全性也无法确保智能汽车真正安全。因此，基于系统工程的思维进行安全构建是解决智能汽车安全问题的必要途径。对于智能汽车软件功能安全，一方面需要继承传统功能安全、预期功能安全的经验与要求，从流程和技术两方面进行管控。另一方面，对于不适用于标准要求的新技术，功能安全方面也急需突破与创新，建立面向包含大模型的“功能型安全”的管控措施。对于每一个智能汽车安全软件的相关从业人员，安全的目标一定是要将风险控制在可接受的范围里，而不是按部就班的执行哪些步骤，添加哪些措施。在创新的过程中，思维也不能天马行空，而是要坚持“四有”定律：有原则、有依据、有底线、有底气。2. 针对不确定的安全痛点，需要在不确定中寻找确定性智能汽车应用场景的不确定性，本质来源于场景要素及其动态变化的不确定性。而人工智能算法的不确定性，无论是输入的不确定性、特征提取的不确定性，还是处理决策的不确定性，本质是来源于模型和数据的不确定性，而这些不确定性归根结底的一项重要原因是数据的不足，由于没有足够的高质量数据支撑，所以智能汽车在应用时可能会面对未曾遇到的场景，没有相应的处理经验；人工智能模型不能进行足够良好的训练和优化，让算法输出的结果具有一定的未知性。因此“用数据驱动安全”是一种对应的解决方案，这包括场景库、数据库、事故库的详细建设方案，以及数据质量、数据标注精度、对抗性数据的详细要求等内容。 对于人工智能的不确定性的解决方案，是一个综合的话题，它既需要继承与创新，也需要数据驱动安全，还需要用技术加强安全，最后也需要流程来保障安全。在如今的大模型时代下，智能汽车领域也必然需要一定的创新来解决当下难题。随着人工智能大模型的发展，未来在智能汽车领域中可能还会带来更多更新颖且意想不到的应用模式，甚至对产业格局与分工带来颠覆性改变。例如，利用大模型替代部分工程师执行设计、编码及测试工作；基于硅基生态的大模型可能产生更多的主动意识等。这些创新性的内容已经颠覆了传统的汽车产品开发方式与特性。对于智能汽车软件未来的安全性，传统的软件开发流程将不能完全适用于大模型时代的软件开发活动，传统的软件安全防护技术也不能完全防护大模型带来的安全风险及危害，传统的功能安全与预期功能安全也不能完全覆盖大模型的安全问题，所以创新势在必行。针对智能汽车大规模软件的安全痛点，对于广泛使用开源软件和Linux操作系统而无法满足功能安全标准的问题，如果坚决从标准的维度来衡量安全性，那么智能汽车软件发展就会进入一个死胡同，只能回退到按部就班的传统汽车软件开发可能才满足要求，但这显然是不合适的。并且标准的形成来源于行业经验的积累与提炼，智能汽车软件痛点的根本在于新技术的发展使得行业内还未积累足够成熟的经验可供参考借鉴，用原始的经验与标准又存在诸多的不适用。在这种情况下，一边要保证安全，一边也要持续发展先进性，突破与创新思维是必不可少的。解决这些智能汽车的软件困局，一是从第一性原理出发，寻找问题本质，通过技术手段降低风险；二是采用风险管理的ALARP（As Low As Reasonably Practicable）原则。ALARP原则认为，在实际操作中，无法完全消除所有风险，但可以采取合理的措施将风险降低到最低合理水平。 从传统功能安全的角度，规范的软件开发流程是规避系统性失效的有力手段，智能汽车软件领域的痛点在于传统的汽车行业软件开发流程与急需快速迭代的软件研发效率之间存在着矛盾和冲突，而解决痛点的关键就是建立一套高效又规范的软件研发流程，既满足软件开发的规范性，又能够提高研发效率，不能让流程阻碍智能汽车的软件发展，反而要让流程助力发展。用流程保障安全，就是通过规范软件开发流程体系实现软件的熵减，让复杂的大规模软件从无序的特性变得规范有序。针对智能汽车大规模软件开发的不确定性痛点，用流程保障安全应侧重解决两方面的问题：一是平衡软件开发流程的规范性与效率，既保障软件开发过程中的系统性失效能够降低到可接受度的程度，又不影响软件开发效率，保证的软件的快速开发与迭代；二是预防软件修改带来影响，即防止修复一个缺陷的操作却对复杂软件的其他逻辑带来更多的问题，建立软件修改变更的流程，从流程上保障软件修改的安全性。随着新技术的发展，我们需创新解决方案，构建系统思维，并基于系统工程实现整体的安全性。智能汽车需要建立系统化的“功能型安全”解决方案，采用系统工程的思维将“功能型安全”涵盖的各个方面视为一个整体。其中，“功能型安全”概念作为一个统称，包括传统功能安全、预期功能安全、大模型范式下的安全性等所有与功能相关的安全内容。随技术进步，未来可能出现新的范式，引入新型的功能相关安全理念。在进行智能汽车的安全分析时，不应单一考虑失效、功能不全、性能不足或可预见的误操作的影响，也不应只关注大模型的安全影响。相反，应该综合考虑这些因素，实现全面综合分析，确保不遗漏任何一个方面。具体做法上，安全分析环节应将“功能型安全”的各个方面融合进行分析，运用多种分析方法对分析对象进行全面深入的探讨；或者可以分别针对功能安全、预期功能安全、模型安全等进行分析，但必须贯穿一个无形的“功能型安全”系统理念，确保每一步分析都考虑到“功能型安全”的各个方面及其相互间的联系和影响。同样，在设计和测试阶段，也应全面关注“功能型安全”的各个方面。- 确保所有安全相关的部分均做到足够安全，并保证它们之间接口的安全性，以确保系统的整体安全。
- 在系统中设置安全的保底机制，为整个系统设置最后一道防线。
在实际应用中，如果客观条件允许，技术可行的情况下，可以两种方案同时选择；如果客观条件允许，技术可行，但关注成本只能二选一时，优先选择方案一；如果客观条件存在问题，技术实现难度高，无法做到方案一的情况下，可退而求其次选择方案二。在当下智能汽车软件设计方面，方案二是一种可行的机制，在系统中设置一个独立的部分作为安全的保底机制，设计一套单独的判断逻辑，但为了防止安全保底机制的误触发，需要将其监测阈值范围适当宽松，但又要保证在危害发生前能够触发机制动作。在系统能够正常识别到风险，执行安全防护处理的情况下，安全保底机制不执行，只是作为后备保障；只有当系统异常，为识别到风险，危害即将发生时，安全保底机制触发，进行紧急处理，具体处理策略根据实际应用场景设定。 
