功能安全、预期功能安全与信息安全的差异与协同

今天的汽车行业面临最大的挑战之一，就是从过去基于硬件的车辆过渡到软件定义汽车的时代。当软件成为造车行业发展的主要领域，越来越多的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工具自动化分析并修正模型

没有网络安全，就没有相应的功能安全。功能安全和网络安全的协同工程需要全面全生命周期的协作和系统考虑。传统意义上讲，功能安全、网络安全是由不同领域的专业人员从事的不同专业方向研究，也有着不同的专业内容，但在系统的安全层面上，他们又是相互协调统一的整体，应该通盘考虑。汽车知识领域功能安全的管理人员，同时也应协同考虑预期功能安全，网络安全的需求，需要多方互相协调，在矛盾与统一中确定影响系统的主要矛盾与措施优先级，综合全面考虑系统设计方案与安全措施，从而最大限度的保证系统的安全。