基于功能安全的车载计算平台开发：软件层面_e-gas架构(1)

已剪辑自: https://mp.weixin.qq.com/s/SIBvH8u–vCk6W28KrPBmA

车载智能计算平台作为智能汽车的安全关键系统，软件层面的安全性至关重要。由于车载智能计算平台功能丰富，应用场景复杂，对软件的实时性、安全性、可靠性要求极高，应通过技术和流程两个方面保障软件的功能安全。技术上确保软件层级的每个功能安全相关软件节点都有相应的故障监测和处理机制，流程上按照软件安全生命周期模型规范软件开发过程。基于参考阶段模型,为软件层面产品开发进行生命周期的剪裁。**车载智能计算平台软件安全要求是对软件安全相关的功能和性能的具体要求，主要是通过技术安全要求在软件层面的分配得到，并通过继承或分配得到相应的ASIL等级。另外，在软件架构阶段执行的软件安全分析也可能会识别出额外的软件安全要求。采用专业的需求管理工具来实现需求的编写、评审、管理以及双向追溯性检查可大幅降低软件层面的系统性安全风险。
软件架构设计是对软件需求的设计与实现，用来描述软件的框架要素和软件各分层结构之间的相互作用，其范围层面应到能够识别所有软件单元的程度。软件架构设计不仅需满足相应ASIL等级的软件安全要求，还应满足软件其他非安全要求。在软件架构层面，软件安全要求会分层次地分配给软件组件直到软件单元，每个软件组件应按照分配给它的安全要求中最高的ASIL等级来开发。车载智能计算平台应在软件架构设计阶段进行软件安全分析和相关失效分析，完善错误探测和错误处理的安全机制，以便识别或确认软件安全相关部分，证明软件的安全相关的功能和性能满足相应的ASIL要求，支持安全措施的定义及其有效性。车载智能计算平台软件架构设计完成后，应对其开展验证活动，输出软件验证报告，证明软件架构设计严格遵守设计规则，兼容目标环境，满足相应ASIL等级的需求，并且相关评审证据充足。
软件安全设计依然可以从E-Gas三层架构中提取关键设计理念。E-Gas针对的典型系统，基本的思想是外围系统—内部系统，内部系统分为传感器、控制器和执行器。在这个系统概念里，传感器是加速踏板传感器，控制器是ECU（Engine Control Unit），执行器是节气门。展开安全架构设计的时候，需要时刻关注将系统解耦和模块化，这对于软件的安全设计是非常重要的。

关于E-Gas安全架构的核心理念和设计，这里再回顾一下，整体设计分为Level1、Level2和Level3，其定义如下：
E-Gas三层安全架构（带锁步核）（1）Level1：**功能层，包括扭矩的解析、功能的诊断等，最直接的理解就是能够实现设计基本功能的软件及相关硬件资源的组合。

**（2）Level2：**功能监控层，负责监控功能层的输出结论，简单理解来看，就是软件的冗余校验，但是，由于不想消耗太多资源及避免算法共因，所以基于功能结果的监控。

**（3）Level3：**硬件监控层，负责确保Level1和Level2的运行的硬件环境是正常工作的，异常的运行环境会导致Level2的设计起不到很好效果，因此，Level3在整体的监控架构中作用是不可替代的。
下图是Level2算法架构的一个示例（汽油歧管喷射），其整体思想是计算实际系统输出的扭矩和此刻系统允许输出的安全现值之间的差值，当差值大于一定数值及一定时间时，采用相应的故障动作。同时，方案为了避免出现误报或者漏报的情况，每一项用于计算的信号或者相应的传感器都应该具有相应的诊断及故障动作，这也是软件开展功能安全设计很关键的理念，输入信号是需要高完整性和准确性的。
**三层架构Level2算法架构示例
针对Level3的硬件监控层，需要涉及软件和硬件的交互，监控的机制可以通过软件实现，也可以通过硬件实现。这里罗列了E-Gas中涉及软件方面的问题：
**（1）ROM检查：**针对ROM的检查，主要是涉及数据翻转、错误的刷写、错误的数据等，软件在其中扮演着检测对比算法的角色，当然，ROM的检查通过硬件也可以实现。
**（2）应答机制检查：**软件需要在设定时间窗口内正确回答独立硬件监控单元的问题，如果超时或者回答错误一定次数，都会触发重置或者下电。
**（3）指令集检查：**指令集是处理器核心的计算最基本单元，也是Level2监控算法正确执行的基础，确保指令集的正确可以采用软件辅助计算应答方法，或者采用目前诊断覆盖率更高的锁步核机制冗余校验（Lockstep-Core）。
**（4）程序流检查：监控算法、诊断算法等都是周期性按顺序执行的，因此，执行时序也需要进行检查。
通过E-Gas的三层经典架构，我们可以分析出软件层级的功能安全设计需要考虑的软件包括Level1的功能层软件、Level2的监控层软件以及Level3的部分支持硬件监控层软件。
对于Level1功能软件，它本身的失效在整体架构中并不会违反安全目标，理应可以按照QM来开发，但考虑到软件本身的可靠性，建议依照ASIL-A或者ASPICE CL2级进行开发，毕竟，一个产品只确保安全但可靠性很差是没有办法交付给客户的；对于Level2和Level3的软件，按照安全分析，需要依靠系统的最高ASIL等级开发。

当然，并不是说非三层架构设计软件无法实现功能安全开发或者产品无法符合功能安全要求。E-Gas三层架构能够很清晰地实现层级递进式的监控设计，尤其适用于功能软件复杂的产品。如果功能软件相对复杂，高ASIL等级的产品在导致软件开发的工作量大量增加的同时安全性也很难兼顾；当然，如果应用层软件相对简单（例如滤波算法、局部优化、状态机等函数），采用下表所列方式会更好。

对于功能安全软件设计而言，软件架构设计一个重要的目标是使软件需求的实现过程以一种完整的、正确的同时尽可能简单、可理解和可验证的方式展现，从而在软件需求实现过程中，尽可能降低由于设计错误造成违反功能安全需求的可能性。功能安全要求软件架构的设计具备以下属性：可理解性，一致性，简单性，可验证，模块化，层次化，按层逐步细化、封装，低耦合性，可维护性。对于可理解性，ISO 26262中按照不同的ASIL等级规定了不同的软件架构设计的表示方式。

常见的几种软件架构安全分析方法包括SW-FMEA、SW-FTA及SW-DFA。
1、SW-FMEA
SW-FMEA以硬件组件和软件模块之间的接口或软件模块和软件模块之间的接口为分析对象，列举硬件组件接口或软件模块的失效模式，分析失效模式对后续软件模块或者软件需求的影响，尤其是与功能安全相关的影响。在明确失效模式和失效后果的基础上，去寻找造成硬件组件接口或软件模块的原因，并且对原因施加控制措施。
2.SW-FTA
SW-FTA探究的重点是软件架构中多点错的发生对软件功能安全需求的影响。SW-FTA分析过程从软件功能安全需求出发，从软件架构设计中所有软件模块和软件接口的失效模式中去寻找和当前软件功能安全需求相关的失效模式，并且识别出这些失效模式和当前软件功能安全需求的相关性（单点失效还是多点失效）。
**3.SW-DFA
SW-DFA在标准中定义的从属故障（Dependent failure）包括级联故障（Cascading failure）和共因故障（Common cause failure）。通常可以从以下几个方面来考虑Dependent failure 中Cascading failure的部分：
时间和调度问题造成Cascading failure。比如，由于其他模块运行时间过长导致目标模块无法运行，死锁、活锁、饥饿等现象导致模块运行停滞或者延迟，软件模块之间的同步性问题或者优先级问题导致调度次序出现问题。
存储空间问题造成Cascading failure。比如，目标存储区域被其他软件模块误篡改，软件模块之间对于同一存储空间的读写操作配合问题导致数据不一致（读数据的同时允许写数据），栈溢出等问题。
软件模块之间的通信（ 尤其是ECU 间的通信） 问题造成Cascading failure。时间和调度问题造成Cascading failure。
随着ASIL等级的提升，ISO 26262从语法和语义两个维度出发，从最低要求的自然语言描述到半正式的表述方式，逐步加强对表述方式的理解一致性的要求。为了避免系统性失效，ISO 26262对软件架构设计提出了一些设计原则。

ISO 26262对软件架构设计验证方法在软件单元设计与实现阶段，基于软件架构设计对车载智能计算平台的软件单元进行详细设计。软件单元设计应满足其所分配的ASIL等级要求，与软件架构设计和软硬件接口设计相关内容保持一致。为了避免系统性失效，应确保软件单元设计的一致性、可理解性、可维护性和可验证性，采用自然语言与半形式化方法相结合的方式进行描述。说明书应描述实施细节层面的功能行为和内部设计，包括数据存储和寄存器的使用限制。在源代码层面的设计与实施应使得软件单元设计简单易懂，软件修改适宜，具有可验证性和鲁棒性，确保软件单元中子程序或函数执行的正确次序，软件单元之间接口的一致性，软件单元内部及软件单元之间数据流和控制流的正确性。车载智能计算平台软件包含数百个软件单元，软件单元的标准化、单元间解耦是高效实现软件功能安全的基础。车载智能计算平台中不同安全等级的软件可以采用硬件虚拟化、容器、内存隔离等技术进行隔离，防止软件单元之间的级联失效。
软件代码设计过程中应遵守成熟的代码设计规范，例如MISRA C。MISRA C是由汽车产业软件可靠性协会（MISRA）提出的C语言开发标准。其目的是在增进嵌入式系统的安全性及可移植性，针对C++语言也有对应的标准MISRA C++。MISRA C一开始主要是针对汽车产业，不过其他产业也逐渐开始使用MISRA C：包括航天、电信、国防、医疗设备、铁路等领域中都已有厂商使用MISRA C。MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年发行，一般称为MISRA-C:1998.。MISRA-C:1998有127项规则，规则从1号编号到127号，其中有93项是强制要求，其余的34项是推荐使用的规则。在2004年时发行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》（或称作MISRA-C:2004），其中有许多重要建议事项的变更，其规则也重新编号。MISRA-C:2004有141项规则，其中121项是强制要求，其余的20项是推荐使用的规则。规则分为21类，从“开发环境”到“运行期错误”。2012年发布第三版，为当前最新有效的C语言规范版本，称为MISRA C:2012。企业可以基于MISRAC建立一套满足车载智能计算平台安全编码要求的内部编码规范，并严格执行。
ISO 26262软件单元设计和实现的设计原则软件单元验证是通过评审、分析和测试的方法对功能安全相关的软件单元设计与实现进行验证，证明软件相关安全措施已经在设计与实现中全部落实。软件单元设计满足相应的ASIL等级的软件需求和软硬件接口规范要求，软件源代码的实现与单元设计一致，不存在非期望的功能和性能，且支持功能和性能实现的相关资源充足。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注网络安全获取）

助，可以添加VX：vip204888 （备注网络安全获取）**
[外链图片转存中…(img-P97WVxCA-1713057193909)]