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

2401_84254343

于 2024-07-20 16:09:43 发布

阅读量916

点赞数 8

分类专栏：作者文章标签：安全架构

本文链接：https://blog.csdn.net/2401_84254343/article/details/140572949

版权

作者专栏收录该内容

7 篇文章 0 订阅

订阅专栏

常见的几种软件架构安全分析方法包括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%，如果已实现结构覆盖率不能达到目标，可以定义额外的测试用例并提供接受理由。车载智能计算平台软件单元的结构覆盖率测试应采用满足相关安全要求的测试工具，确保在测试过程中测试工具和检测代码不会对测试结果产生影响。
车载智能计算平台软件单元测试应根据测试范围，选用适当的测试环境。测试环境应适合完成测试目标，尽可能接近目标环境，如果不是在目标环境执行，应分析源代码与目标代码的差异、测试环境和目标环境之间的差异，以便在后续测试阶段的目标环境中，定义额外的测试。

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

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

通过实施完善的开发流程可降低车载智能计算平台人工智能的系统性安全风险。车载智能计算平台人工智能的开发包含需求分析、算法设计、数据采集和标注、模型训练、测试验证以及运行等流程。
人工智能的需求分析应包含算法的基本功能需求和功能安全要求（如算法精度目标、算法Fail-Operational等）。算法设计阶段应考虑采用多算法、多模型、多帧数据、多传感器等多种冗余机制的组合以提升安全性。数据采集和标注阶段应确保数据标注精度、数据场景分布，并避免数据错标和漏标，从而确保模型训练不受影响。模型训练阶段采用业界成熟、文档全面的人工智能框架。测试验证阶段对所有需求进行闭环的测试，同时全面考虑各种潜在应用场景及环境影响因素，进行长距离的实车试验。根据测试结果不断重复进行数据的采集、标注、模型训练和测试验证的阶段，通过迭代的方式逐步提高人工智能的安全性。在运行阶段，应持续地对实际运行数据和人工智能的安全性进行监控，通过分析实际运行数据对人工智能算法和模型不断优化。a、Polyspace
Polyspace Bug Finder可以识别嵌入式软件C和C++代码中的运行时错误、并发问题、安全漏洞和其他缺陷。使用静态分析（包括语义分析），Polyspace Bug Finder可分析软件控制流、数据流和进程间行为。通过在检测到缺陷之后立即高亮显示缺陷，可在开发过程的早期阶段鉴别和修复错误。Polyspace Bug Finder可检查是否符合编码规范，如MISRA C、MISRA C++、JSF++、CERT C、CERT C++和自定义命名规范。它可以生成报告，其中包括发现的错误、代码违规和代码质量指标，如圈复杂度。Polyspac eBug Finder可与Eclipse IDE配合使用进行代码分析。
![图片](https:/
作者徽是vip1024c
/img-blog.csdnimg.cn/img_convert/82d7e569315af1e7001500a807b33d80.jpeg)
b、Tessy**
**Tessy软件源自戴姆勒—奔驰公司的软件技术实验室，由德国Hitex公司负责全球销售及技术支持服务，是一款专门针对嵌入式软件动态测试的工具。它可以对C/C++代码进行单元、集成测试，可以自动化搭建测试环境、执行测试、评估测试结果并生成测试报告等。多样化的测试用例导入生成方式和与测试需求关联的特色，使Tessy在测试组织和测试管理上也发挥了良好的作用，目前，Tessy广泛应用汽车电子主流客户中。Tessy满足各类标准（如ISO 26262、IEC61508）对测试的需求，比如Tessy可以满足ISO 26262中各个测试等级对模块测试的要求，当然，Tessy本身也通过了TÜV的认证，证明该软件是安全可靠的，可以在安全相关的软件研发过程中使用。

c、Helix QAC
Helix QAC是静态代码分析工具，依据C和C++编码规则自动扫描代码对规则的违背。在开发过程的早期就可以用它来检测缺陷，因为此时修改代码是最方便也最经济的。Helix QAC自动化强制实施代码编程标准，比如，MISRA保证代码的合规性。Helix QAC识别必须修改的缺陷，提供详细的指导，帮助开发人员修改问题。这是不需要运行程序的。开发人员既然获得了即时的上下文反馈，他们将因此从错误中获得学习，下一次编写新的代码（或者评审代码）时，能力将得到提升。Helix QAC自动审查代码，确保它们符合用户选择的编码标准。合规性报告可视化地提醒用户哪些代码需要多加留意。Helix QAC支持多种C和C++编码标准，提供相应的合规性模块，也支持标准的客户化定制。