基于功能安全的车载计算平台软件层面的开发-EDN 电子技术设计

 车载智能计算平台作为智能汽车的安全关键系统，软件层面的安全性至关重要。

车载智能计算平台作为智能汽车的安全关键系统，软件层面的安全性至关重要。由于车载智能计算平台功能丰富，应用场景复杂，对软件的实时性、安全性、可靠性要求极高，应通过技术和流程两个方面保障软件的功能安全。技术上确保软件层级的每个功能安全相关软件节点都有相应的故障监测和处理机制，流程上按照软件安全生命周期模型规范软件开发过程。基于参考阶段模型,为软件层面产品开发进行生命周期的剪裁。

软件开发参考阶段模型

01 软件安全要求

车载智能计算平台软件安全要求是对软件安全相关的功能和性能的具体要求，主要是通过技术安全要求在软件层面的分配得到，并通过继承或分配得到相应的ASIL等级。另外，在软件架构阶段执行的软件安全分析也可能会识别出额外的软件安全要求。采用专业的需求管理工具来实现需求的编写、评审、管理以及双向追溯性检查可大幅降低软件层面的系统性安全风险。

02 软件架构设计

软件架构设计是对软件需求的设计与实现，用来描述软件的框架要素和软件各分层结构之间的相互作用，其范围层面应到能够识别所有软件单元的程度。软件架构设计不仅需满足相应ASIL等级的软件安全要求，还应满足软件其他非安全要求。在软件架构层面，软件安全要求会分层次地分配给软件组件直到软件单元，每个软件组件应按照分配给它的安全要求中最高的ASIL等级来开发。车载智能计算平台应在软件架构设计阶段进行软件安全分析和相关失效分析，完善错误探测和错误处理的安全机制，以便识别或确认软件安全相关部分，证明软件的安全相关的功能和性能满足相应的ASIL要求，支持安全措施的定义及其有效性。车载智能计算平台软件架构设计完成后，应对其开展验证活动，输出软件验证报告，证明软件架构设计严格遵守设计规则，兼容目标环境，满足相应ASIL等级的需求，并且相关评审证据充足。

软件安全设计依然可以从E-Gas三层架构中提取关键设计理念。E-Gas针对的典型系统，基本的思想是外围系统—内部系统，内部系统分为传感器、控制器和执行器。在这个系统概念里，传感器是加速踏板传感器，控制器是ECU（Engine Control Unit），执行器是节气门。展开安全架构设计的时候，需要时刻关注将系统解耦和模块化，这对于软件的安全设计是非常重要的。

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对软件架构设计提出了一些设计原则。

软件架构设计原则

le0ednc

ISO 26262对软件架构设计验证方法

03 软件单元设计与实现

在软件单元设计与实现阶段，基于软件架构设计对车载智能计算平台的软件单元进行详细设计。软件单元设计应满足其所分配的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软件单元设计和实现的设计原则

04 软件单元验证

软件单元验证是通过评审、分析和测试的方法对功能安全相关的软件单元设计与实现进行验证，证明软件相关安全措施已经在设计与实现中全部落实。软件单元设计满足相应的ASIL等级的软件需求和软硬件接口规范要求，软件源代码的实现与单元设计一致，不存在非期望的功能和性能，且支持功能和性能实现的相关资源充足。

车载智能计算平台的软件单元验证可参考下表，通过需求分析、等价类的生成与分析、边界值分析和错误推测相结合的方法合理设计测试用例，确保对软件单元进行充分验证。为了评估软件单元验证的完整性，为单元测试的充分性提供证据，应确定在软件单元层面的需求覆盖率，同时对结构覆盖率进行测定。车载智能计算平台软件单元测试的结构覆盖率目标为100%，如果已实现结构覆盖率不能达到目标，可以定义额外的测试用例并提供接受理由。车载智能计算平台软件单元的结构覆盖率测试应采用满足相关安全要求的测试工具，确保在测试过程中测试工具和检测代码不会对测试结果产生影响。

车载智能计算平台软件单元测试应根据测试范围，选用适当的测试环境。测试环境应适合完成测试目标，尽可能接近目标环境，如果不是在目标环境执行，应分析源代码与目标代码的差异、测试环境和目标环境之间的差异，以便在后续测试阶段的目标环境中，定义额外的测试。

软件单元验证方法

le0ednc

软件单元测试用例的得出方法

05 软件集成验证

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

软件集成验证方法

le0ednc

软件集成测试用例的得出方法

06 嵌入式软件测试

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

嵌入式软件的测试方法

le0ednc

嵌入式软件测试用例的得出方法

07 人工智能

通过实施完善的开发流程可降低车载智能计算平台人工智能的系统性安全风险。车载智能计算平台人工智能的开发包含需求分析、算法设计、数据采集和标注、模型训练、测试验证以及运行等流程。

人工智能的需求分析应包含算法的基本功能需求和功能安全要求（如算法精度目标、算法Fail-Operational等）。算法设计阶段应考虑采用多算法、多模型、多帧数据、多传感器等多种冗余机制的组合以提升安全性。数据采集和标注阶段应确保数据标注精度、数据场景分布，并避免数据错标和漏标，从而确保模型训练不受影响。模型训练阶段采用业界成熟、文档全面的人工智能框架。测试验证阶段对所有需求进行闭环的测试，同时全面考虑各种潜在应用场景及环境影响因素，进行长距离的实车试验。根据测试结果不断重复进行数据的采集、标注、模型训练和测试验证的阶段，通过迭代的方式逐步提高人工智能的安全性。在运行阶段，应持续地对实际运行数据和人工智能的安全性进行监控，通过分析实际运行数据对人工智能算法和模型不断优化。

08 软件阶段常用工具介绍

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配合使用进行代码分析。

Polyspace软件截图

b、Tessy

Tessy软件源自戴姆勒—奔驰公司的软件技术实验室，由德国Hitex公司负责全球销售及技术支持服务，是一款专门针对嵌入式软件动态测试的工具。它可以对C/C++代码进行单元、集成测试，可以自动化搭建测试环境、执行测试、评估测试结果并生成测试报告等。多样化的测试用例导入生成方式和与测试需求关联的特色，使Tessy在测试组织和测试管理上也发挥了良好的作用，目前，Tessy广泛应用汽车电子主流客户中。Tessy满足各类标准（如ISO 26262、IEC61508）对测试的需求，比如Tessy可以满足ISO 26262中各个测试等级对模块测试的要求，当然，Tessy本身也通过了TÜV的认证，证明该软件是安全可靠的，可以在安全相关的软件研发过程中使用。

Tessy 软件截图

c、Helix QAC

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