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

关于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等级的软件需求和软硬件接口规范要求，软件源代码的实现与单元设计一致，不存在非期望的功能和性能，且支持功能和性能实现的相关资源充足。
车载智能计算平台的软件单元验证可参考下表，通过需求分析、等价类的生成与分析、边界值分析和错误推测相结合的方法合理设计测试用例，确保对软件单元进行充分验证。为了评估软件单元验证的完整性，为单元测试的充分性提供证据，应确定在软件单元层面的需求覆盖率，同时对结构覆盖率进行测定。车载智能计算平台软件单元测试的结构覆盖率目标为100%，如果已实现结构覆盖率不能达到目标，可以定义额外的测试用例并提供接受理由。车载智能计算平台软件单元的结构覆盖率测试应采用满足相关安全要求的测试工具，确保在测试过程中测试工具和检测代码不会对测试结果产生影响。
车载智能计算平台软件单元测试应根据测试范围，选用适当的测试环境。测试环境应适合完成测试目标，尽可能接近目标环境，如果不是在目标环境执行，应分析源代码与目标代码的差异、测试环境和目标环境之间的差异，以便在后续测试阶段的目标环境中，定义额外的测试。

软件集成验证需要根据软件验证计划、接口规范、软件架构设计规范、软件验证规范等对软件架构中所描述的集成层次、接口、功能等进行持续测试，以验证其与设计的符合性。由于车载智能计算平台软件的复杂性，实时性、可靠性、安全性既是设计目标也是基础性能，集成测试设计阶段应对其功能、逻辑、性能、边界、接口进行详细分析。车载智能计算平台的软件集成验证参考下表，不仅需涵盖所有应用软件、功能软件、系统软件以及与硬件之间的接口，并且应涵盖软件单元之间的接口。测试用例在测试工作中至关重要，其输出需要考虑功能需求、性能需求、边界值、接口、逻辑关系等。

车载智能计算平台嵌入式软件测试主要是基于软件安全要求的测试可参考下表，针对软件安全要求进行充分的故障注入测试，最终确保软件安全要求的正确实现。为了验证车载智能计算平台软件在目标环境下是否满足软件安全要求，应进行硬件在环测试、车辆电控系统和网络通信环境下的测试以及实车测试。硬件在环测试是将车载智能计算平台软件烧写到目标芯片中，在目标芯片的硬件异构平台环境下验证软件的安全要求。然后，将车载智能计算平台与部分或全部的车辆电子电气设备进行网络通信，在车辆电控系统和网络环境下验证软件的安全要求。最后，将车载智能计算平台安装到实际车辆中，进行软件安全要求的验证与确认。

还有兄弟不知道网络安全面试可以提前刷题吗？费时一周整理的160+网络安全面试题，金九银十，做网络安全面试里的显眼包！

王岚嵚工程师面试题（附答案），只能帮兄弟们到这儿了！如果你能答对70%，找一个安全工作，问题不大。

对于有1-3年工作经验，想要跳槽的朋友来说，也是很好的温习资料！

【完整版领取方式在文末！！】

93道网络安全面试题

内容实在太多，不一一截图了

黑客学习资源推荐

最后给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

😝朋友们如果有需要的话，可以联系领取~

1️⃣零基础入门

① 学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

② 路线对应学习视频

同时每个成长路线对应的板块都有配套的视频提供：

2️⃣视频配套工具&国内外网安书籍、文档

① 工具

② 视频

③ 书籍

资源较为敏感，未展示全面，需要的最下面获取

② 简历模板

因篇幅有限，资料较为敏感仅展示部分资料，添加上方即可获取👆

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！