【摘 要】 CP AUTOSAR作为整个汽车行业一种标准化的开放式架构，随着汽车行业的发展，在车载软件开发中运用得越来越广泛，同时汽车作为人们出行的重要交通工具，汽车的安全性也越来越重要。为了开发满足ISO 26262的车载软件，文章分析ISO 26262对软件安全的要求，并结合CP AUTOSAR开发规范以及CP AUTOSAR的功能安全机制，对CP AUTOSAR的功能安全机制进行深入研究，同时基于ISO 26262的软件安全要求提出基于AUTOSAR架构进行软件安全机制的应用方案，对当前车载软件功能安全的实施具有重大意义。

目前基于CP AUTOSAR架构开发汽车电子软件是主流的主机厂和汽车电子控制器供应商最常见的一种开发方式。由于汽车电子控制器开发难度大，在开发的过程中必须遵循一定的开发和测试流程，目前汽车行业最重要的开发流程是ASPICE和ISO 26262[7]。ASPICE侧重于开发功能安全相关性不大的汽车电子控制器，而ISO 26262作为标准的汽车电子控制器安全开发标准，对于车载电子控制器的安全开发流程做了严格的定义。ISO 26262从系统设计、软硬件设计、测试、项目管理等方面提供了严格的流程和开发标准。在ISO 26262中，和软件开发密切相关的主要有3大角度，分别是软件开发和测试流程、软件安全分析以及接口免于干扰的要求，软件安全机制的实施基于接口免于干扰的要求设计和实现[6]。

针对CP AUTOSAR架构下的软件功能安全的开发必须要明确ISO 26262 内对软件功能安全的要求，基于ISO 26262的要求，将CP AUTOSAR提供的安全机制应用到汽车电子控制器软件开发中[5]。在CP AUTOSAR的软件安全机制中，主要提供了内存保护（Memory Protection）、时间保护（WdgM and OS Timing Protection）、数据一致性（E2E算法）等安全机制来实现ISO 26262对接口免于干扰的要求。最终基于AUTOSAR的安全机制得出应用结论，用于安全机制在项目中的实施[8]。

本文以ISO 26262中对软件开发的安全要求为基础，通过识别和选择CP AUTOSAR内提供的安全机制，并且对安全机制进行应用研究和测试，从而针对CP AUTOSAR下的软件功能安全开发提供一套完整的方案。整体设计架构如图1所示。

图1 整体设计架构图

1 CP AUTOSAR介绍

汽车电子开发不像其他产品的开发，有着自己一套严格的规范和流程，在汽车行业主要是V模型，它定义了汽车电子产品开发一套从需求到软硬件设计开发再到最终测试交付的完整体系。AUTOSAR（Automotive Open System Architecture，汽车开放系统架构）是主流汽车OEM、供应商、芯片企业等制定的一套软硬件可以分离复用、应用算法与底层驱动分离、下层的芯片企业与上层OEM或者ECU供应商基于同样的规范，独立并行开发的软件开发体系。AUTOSAR 标准严格遵循了V 模型的软件开发流程，在AUTOSAR标准中定义了从软件需求（通用全面的需求）到架构设计的完整体系，根据AUTOSAR规范就可以开发满足这些规范的代码程序。在AUTOSAR架构中主要分为3层架构，分别是APP（Application Layer，应用 层）、RTE（Running Environment，运行环境）、BSW（Basic Software，基础软件层）。整个AUTOSAR架构分层如图2所示。

图2 AUTOSAR架构分层图

APP层主要是实现特定ECU功能的逻辑算法，这一层也是CP AUTOSAR架构里定义的各个OEM和供应商在实现上存在竞争的一层。一般在APP层会设计出ECU中各个软件单元模块的上层应用架构，而这部分架构并不是一个统一的CP AUTOSAR架构，OEM和供应商可以根据自己的应用层逻辑去设计自己上层应用需要的SWC数目、各个SWC模块之间的数据流和控制流。在CP AUTOSAR架构中，各个APP的调度、数据交互等通过RTE实现。

RTE提供基础的通信服务，支持SWC之间和SWC到BSW的通信（包括ECU内部的程序调用、ECU外部的总线通信等情况）。RTE同时实现对APP层SWC的函数调度。RTE使应用层的软件架构完全脱离于具体的单个ECU和BSW。

BSW层是整个CP AUTOSAR的核心，内部按架构上的分层主要分为微控制器抽象、复杂驱动层、ECU抽象层、服务层4大部分。各部分的作用如下。

1）微控制器抽象层（Microcontroller Abstraction Layer）是在BSW的最底层，包含了访问微控制器的驱动。微控制器抽象层使上层软件与微控制器相分离，以便应用的移植。

2）复杂驱动（Complex Drivers）可以实现应用层通过RTE直接访问硬件，也可以利用复杂驱动封装已有的非分层的软件，以便向CP AUTOSAR软件架构逐步实施。

3）ECU抽象层（ECU Abstraction Layer）封装了微控制器层以及外围设备的驱动，将微控制器内外设的访问进行统一，使上层软件应用与ECU硬件相剥离。

4）服务层（Service Layer）位于BSW的最上面，将各种基础软件功能以服务的形式封装起来，供应用层调用。服务层包括RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务。

2 ISO 26262对软件安全的要求

ISO 26262是从电子、电气及可编程器件功能安全基本标准IEC 61508派生出来的，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。在汽车电子软件功能安全开发过程中，主要关注ISO 26262的Part6的要求[4]。针对整个ISO 26262-6对软件开发的要求，在图1中已经展示，即软件开发测试流程、接口免于干扰以及安全分析。软件和测试流程的要求需要流程管理进行控制，安全分析主要借助一些专业工具进行分析，而对于接口免于干扰的设计在ISO 26262中提出了明确的要求，而这些接口免于干扰的设计需要在软件开发中提供相关的安全机制来实现。根据ISO 26262的接口免于干扰的要求，主要从Timing and Execution、Memory、Exchange of Information这3个方面进行分析[12]。

2.1 Timing and Execution

ISO 26262中对时间和执行时序相关的要求做了明确的定义，主要从图3 列出的5 个方面进行设计和评估。Timing和Execution的分析主要是防止执行的函数被阻塞的时间过长；防止函数执行超过一定的时间；防止函数调度过快；防止执行时间分配不正确；元素接口等元素不同步。

图3 Timing and Execution分析内容

2.2 Memory

ISO 26262中对Memory相关要求做了明确的定义，主要从图4列出的5个方面进行设计和评估。Memory的分析主要是防止数据在内存中破坏；保证数据访问的一致性；防止内存栈空间的上溢出和下溢出；防止数据读写内存地址越界。

图4 Memory分析内容

2.3 Exchange of Information

ISO 26262中对Exchange of Information相关的要求做了明确的定义，主要从图5列出的5个方面进行设计和评估。Exchange of Information的分析主要是防止数据错误；防止数据重复操作；防止数据丢失；防止数据中插入其他数据；防止数据伪造或者数据地址篡改；防止数据操作序列出错；防止数据一发多收出错；发送的数据被部分接收；数据操作被阻塞。

图5 Exchange of Information分析内容

3 CP AUTOSAR安全机制

CP AUTOSAR中根据ISO 26262的安全相关需求（Timing and Execution、Memory、Exchange of Information），提出了对应的安全机制，即通过时间保护（WdgM and OS Timing Protection）、内存保护（Memory Protection）、数据一致性（E2E算法）等安全机制来实现[12]。

3.1 Timing and Execution的安全机制

针对功能安全对Timing and Execution 的安全机制，AUTOSAR 中主要依靠2 个主要的功能来保证，分别是AURTOSAR的WdgM协议栈以及OS的Timing Protection。每个被监控的函数称之为一个SE（Supervisor Entity）。在WdgM整个协议栈中，主要提供了3种监控手段，具体的监控作用内容如下。

1）Alive Supervisor监控：周期函数在特定的时间内调用不能频率过快或者过慢。SE的WdgM_Checkpoint Reached每调用一次，对应的Checkpoint的Alive Counter就会加1，主函数在定义的监控周期内会去检测Alive Counter的数目。只有Alive Counter在该周期内属于定义的次数范围才认为该SE处于正常的模式，如果Alive Counter小于定义的调度次数最小值则认为所监控的SE 执行太慢，相反Alive Counter大于定义的调度次数最大值，则认为SE执行得太快。

2）Deadline Supervisor监控：监控2个函数调用间隔的时间限制。Deadline Supervision主要用于监控非周期运行的SE，主要定义了某个事件发生后，在特定的时间窗内去执行相应SE的Checkpoint，一般认为在事件发生后在定义的最短时间和最长时间内去执行相应的Checkpoint，认为程序属于正常的执行，如果在事件发生后执行相关SE的Checkpoint时间小于最小的时间，或者大于最大的时间去执行SE的Checkpoint都认为是错误的。

3）Logic Supervisor监控：监控程序按照设计的调用逻辑进行调用。主要用于监控程序是否按照正确的逻辑转换条件去执行。对于每一个Logical Supervision都有一个调用关系图来表示SE中各个Checkpoint点在控制流上的转换关系。

整个WdgM功能安全监控机制如图6所示。

图6 WdgM功能安全监控机制

在WdgM中，每一个SE都有一个自己的Local Status来表示自己SE的Alive／Deadline／Logic Supervision的状态，同时WdgM还有一个全局的Global Status来表示整个监控功能的状态[3]。在WdgM初始化完成后，每个SE的各个子功能监控的Local Status以及Global Status 的状态都是OK 的状态。每个SE的Local Status以及Global Status都包含了OK、DEACTIVATED、FAILED、EXPIRED状态。在每个SE的功能进行监控的时候，会根据监控结果在MainFunction中设置对应的Local Status。其中Alive Supervision有单独的状态设置，而Deadline和Logic Supervision共用一个Local Status。在使用时，可以根据每个SE 的3 个监控设计的条件在MainFunction中设置对应的状态，同时MainFunction根据定义的所有SE的状态输出对应的Global Status，如果最终的Global Status出现错误，User可以认为系统的时间或者函数的调度功能已经导致程序出现了Error，那么可以去触发相应的错误处理以及故障反应。

除了WdgM对程序的执行以及逻辑进行时序的监控之外，在Task执行的时候，可以通过OS的Timing Protection功能实现对函数调度以及Task被Block的时间监控。相比于WdgM的监控，OS Timing Protection的函数监控更侧重于非功能安全的任务Task调度以及被Block时间监控。OS Timing Protection功能安全监控机制如图7所示。

图7 OS Timing Protection功能安全监控机制

图7中绿色的是低优先级的Task，红色的是高优先级的Task。在实时抢占的系统中，低优先级的Task可以被高优先级的Task抢占。OS Timing Protection主要考虑低优先级的Task在被高优先级的Task抢占的情况下执行时间不能超过图中LOW Deadline定义的时间；保证被中断或者高优先级Task Block 的时间不能太长；保证LOW Inter-Arive Time的时间不能调度太快。在OS Timing Protection中，当达到上述定义的错误时，可以选择相应的安全反应（Reset操作、结束函数调用等）来保证程序的正常运行。

3.2 Memory Protection安全机制

在AUTOSAR中为了保证数据访问过程中不能相互篡改，减少低功能安全等级或者QM的数据影响到功能安全的数据，需要增加内存隔离和内存保护。在AUTOSAR提供了基于Application级别的功能安全内存保护机制，通过将不同的软件组件分配到不同的Application中实现内存访问的隔离和内存保护。Memory Protection功能安全监控机制如图8所示。

图8 Memory Protection功能安全监控机制

根据功能安全的目标，将模块划分为QM、ASIL-B、ASIL-D。对于每个等级的模块组件按照功能安全等级进行划分。需要在内存中定义QM、ASIL-B、ASIL-D的3个等级的RAM和ROM空间，并按照图8的模块将模块内的变量和代码分别映射到QM、ASIL-B、ASIL-D的3个等级的RAM和ROM空间，同时结合图8中灰色的图框[硬件MPU（Memory Protection Unit）功能]实现对内存的保护[10]。一旦出现低ASIL等级、QM函数或变量操作到高功能安全等级的，将会触发硬件MPU保护措施，并根据实际应用进行错误处理。基于硬件MPU保护的实现逻辑如图9所示。

图9 基于硬件MPU保护的实现逻辑

如图9所示，内存保护机制是基于OS进行管理的，因此在实现内存保护机制中必须依赖于OS的运行。在集成OS操作系统中程序运行在初始化阶段会根据需要将内存保护的地址设置成默认值，或者将芯片全部内存设置为都可以访问[9]。在OS 使用的嵌入式软件中会存在多个Application，每个Application含有多个Task，OS在运行的时候可以通过调度切换Application和Task的执行，因此OS执行过程中会实时对Application和Task进行判断。当检测到正在运行的Application或者Task存在内存保护机制后根据设计中定义好的地址范围操作MPU硬件的RAM和ROM地址，将该Application或者Task访问的范围写入到MPU的寄存器，一旦程序接下来运行的地址超过了定义的范围，MPU硬件单元便会触发硬件错误，软件集成者便可以捕获该错误，并设计错误回调函数进行错误处理。

3.3 Exchange of Information安全机制

针对功能安全提出的对数据传输和交互过程中出现的要求，在AUTOSAR中提供了E2E（End to End）相关的算法来保证数据在ECU与ECU之间或者ECU内部之间的数据传输的一致性[2]，图10展示了E2E保证数据传输一致性的原理。

图10 Exchange of Information功能安全监控机制

AUTOSAR E2E Lib 提供了多种数据一致性保护的算法，主要包括以下几个方面[11]。CRC Lib：通过填充CRC算法实现；Sequence Counter incremented：发送方增加，接收方Check 是否增加；Alive Counter：发送方增加，接收方Check变化，不Check增加；Data ID：每个IPDU Group表明特定的安全元素，特定的ECU信息，Data ID 也会用于CRC 计算；Timeout Detection：接收方检测数据通信超时。

图10中3种AUTOSAR提供的数据一致性实现的方案采用了E2E Protection Wrap（每一个需要保护的数据都会使用一个单独的E2E接口函数，同时保护数据的传输必须基于结构体进行）[1]。其中，路径①代表在同一个ECU中同一个OS Application对发送和接收的数据进行保护，主要采用E2E中的CRC算法实现。路径②代表数据在同一个ECU不同的OS Application进行数据传递，同时需要增加额外的机制来解决跨OS Application的数据交互，即图10中的IOC模块，通过增加IOC模块来保证不同Application数据传输的一致性。一般只采用CTC算法实现。路径③实现了在不用的ECU之间数据一致性的保护机制，通常这种保护机制一般需要借助ECU之间的通信总线实现，常见的通信总线包括了CAN、LIN、Ethernet等。

4 结论

上文针对功能安全要求以及对AUTOSAR提供的安全机制分析，将功能安全的要求和安全机制进行了一一对应。针对软件功能安全中的时间和时序的保护可以使用AUTOSAR架构中的WdgM协议栈，集成WdgM的Alive监控、Deadline监控以及Logic监控实现对程序的时间监控，集成OS的时间保护机制可以实现对Task级别的时间保护，避免调度时间出错导致功能安全目标的违背；针对软件功能安全要求的内存保护，可以结合AUTOSAR架构中的OS提供的内存保护机制设置Application访问的内存区间，结合MPU硬件模块实现对内存的访问权限隔离，达到内存保护的目的；针对软件功能安全要求的数据交互的保护，主要借助于AUTOSAR提供的E2E算法实现ECU内部数据交互以及ECU与ECU之间数据交互的保护。

本文通过研究ISO 26262 的软件安全要求，结合AUTOSAR提供的安全机制，从时间、内存和数据交互3个方面提出了软件安全机制的实现方案，对当前车载软件功能安全的实施具有重大意义。

参考文献：

[1]陈灿，杨兴达，方菱.基于决策表的AUTOSAR操作系统一致性测试研究[J].计算机工程与科学，2023，45（4）：622-629.

[2]宋俊飞，翟成超，范慧，等.基于AUTOSAR跨ECU平台的E2E保护机制的实现[J].汽车电器，2023（3）：25-28.

[3]李思健，石春，吴刚，等.基于AUTOSAR的控制流检测模块的设计与实现[J].仪表技术，2022（4）：1-6，60.

[4]辛强，朱卫兵，胡璟.基于ISO 26262的新能源汽车电子电器部件功能安全开发简介[J].汽车零部件，2021（6）：63-65.

[5]李争鹏.基于ISO 26262的驱动电机系统功能安全概念设计及测试[J].汽车实用技术，2022，47（23）：160-164.

[6]彭斐.ISO 26262保证汽车功能安全的新思路[J].汽车与配件，2015（37）：30-33.

[7]刘佳熙，于世涛，郭辉.符合ISO 26262要求的汽车起停系统功能安全开发[J].上海汽车，2014（4）：59-62.

[8]ISO 26262—2018，Road vehicles——Functional safety[S].

[9]葛纹材，朱元，王恩东，等.基于AUTOSAR标准的软件内存保护机制实现[J].信息通信，2020（11）：5-7.

[10]谢凌云.基于ISO 26262混合ASIL系统设计应用研究[J].传动技术，2021，35（4）：32-38.

[11]白志浩，张丽，吴肇苏，等.基于ISO 26262的EV用动力电池系统功能安全设计[J].电源技术，2021（5）：626-629.

[12]还宏生.汽车设计中的安全要求及ISO 26262标准[J].汽车零部件，2012（10）：41-43.

[13]方晓颖.基于AUTOSAR标准的E2E保护[J].汽车与驾驶维修（维修版），2020（3）：81-83.

END