登陆

从AUTOSAR看功能安全计算关键技术

来源：上海电气泰雷兹

2023-09-04

AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，旨在建立一个开放的汽车控制器（ECU）标准软件架构，一种分层式，分布式的软件架构。这种架构最大程度地明确各模块间的职责分工，互不干扰。与SOA的概念相似，AUTOSAR也倡导在系统架构中采用模块化、可重用、可配置和可扩展的设计思想。同时，AUTOSAR还提供了一些安全机制，以支持开发安全关键系统。

在计算机系统普遍应用于轨道交通的背景下，研究AUTOSAR中的功能安全计算技术对于轨道交通安全技术的发展具有重要意义。轨道交通属于无障碍交通，运行在封闭且可控的环境中，相较于汽车，其对路的判断逻辑相对简单。而汽车行驶在开放的道路上，其面对的异外情况不胜枚举。另一方面，尽管运行AUTOSAR软件系统的计算机硬件符合车规级别，但是它们仍然属于COTS，即一般市场上可以买到的器件。而在轨道交通控制系统中，计算机系统主要采用具有容错设计的专用硬件，例如ALU、总线控制器等最基础的硬件。因此，在研究AUTOSAR关键技术时，需要考虑如何将其应用到轨道交通系统中，以满足其特殊的安全性能需求，并同时充分利用专用硬件的优势，提高控制系统的性能和可靠性。

对于汽车而言，SOA是一种架构指导，帮助传统分布式汽车架构转变为先进的电子架构。同时，将车辆上的硬件功能、系统功能、软件功能以服务的形式对外提供，让汽车从多个软件独立体整合成一套统一的软硬件体系。

在工业设计领域，大家更愿意接受组件的概念。构件是面向程序设计阶段的，而组件则是面向软件集成阶段的。传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流等观点反映问题的本质，而组件技术关注的是在软件已经“编译”过，即在高层次上复用、分布式异构互操作等。基于组件的软件设计方法学把应用逻辑和实现分离，提供标准接口和框架，使软件开发变成组件的组合，基于组件的软件方法学是以接口为中心、面向行为的、基于体系结构设计的。

组件的定义还包括以下内容：

• 系统中的组件具有临界状态，当组件处于临界状态时，其运行是稳定可靠的。组件也具备一定的环境适应能力。例如，在移动通信中，通信构件若遇到底层协议栈出错而接收到非约定的包，可能会导致上层构件出错。组件需要花费很多时间来检查和维护其运行环境，包括构造和析构。相比之下，构件通常不需要这些额外的开销，它们“无条件”信任环境并进行操作。因此，并不是所有的构件都需要被设计成组件。
• 组件不利用环境的约定，同时也不在运行环境产生运行结果以外的东西。
• 组件检查到内部错误应该隔离这个错误对整个应用的影响。可以利用虚拟机（Virtual Machine）、进程（Process）等对为组件提供运行环境。
• 组件具有受控性、可监测性，能够在确定的资源、确定的时间内完成功能，能够在出现异常时重启，但保持对外服务接口的一致性。组件在可靠性表现上更象硬件。
• SOA是一种基于对象的计算模型，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。构件模型决定了软件系统构架的思维逻辑。构件是已被封装的、可分布的、具有良好接口定义的软件包，在一个SOA模型的系统中，提供具体服务的是对一个对象的数据及逻辑等具体计算机实现的构件。
• 组件的运行时Runtime，可以由中间件提供，无论何时，组件的引用并发量是受控的，从而防止组件遭到拒绝服务(DoS) 攻击这类请求。组件程序的按一定规范要求开发的通用的程序，它的信息安全由中间件保证。
• 组件间的通信是功能安全的，由中间件提供抽象的数据通信支持，该通信具有较好的服务质量（QoS）控制。

AUTOSAR并非一种完整的安全解决方案，但它提供了以下安全机制：

• 内存分区（Memory Partitioning）

内存分区机制可以避免不同软件构件之间的互相干扰，防止软件错误对内存存储的数据段或代码段的篡改，同时也限制对内存和内存映射的硬件外设的访问。

图1 AUTOSAR中的内存分区

如图1所示，AUTOSAR操作系统将OS-Application放入独立的内存区域，保障不同应用免受内存故障干扰。这种机制称为内存分区。由于在一个OS-Application的内存分区中执行的代码不能修改其他内存区域，因此OS-Application实现了分区之间的相互保护。

• 时间监控（Timing Monitoring）

为避免软件构件之间出现的执行阻塞、死锁、执行时间的不正确分配以及软件事务之间的不同步等问题，需要对软件的运行时间进行监控，以确定软件运行的正确时序。

• 逻辑监督（Logical Supervision）

逻辑监督用于检查软件是否按照正确的逻辑顺序执行。如果一条或多条程序指令以不正确的顺序被处理，或者根本没有被处理，就会发生不正确的控制流。

• 端到端保护（End-2-End Protection）

端到端保护用于实现安全相关应用在非受信网络或存储之间数据交互的安全。在一个分布式系统中，发送方和接收方之间的数据交互可能会影响功能安全。因此，端到端的防护可以避免这类问题。

这些安全机制中，内存分区用于实现不同ASIL等级、安全相关构件和非安全相关构件之间的隔离；时间监控和逻辑监督则是软件运行时序错误的常用检测方法；端到端保护则保证了安全相关应用的数据交互安全性。

3.1 应用场景和计算特点对比

实时系统被定义为“在限定时间内提供所需服务水平的能力”。实时系统的特点是同时满足功能需求和时间限制。实时系统分为“硬实时系统”和“软实时系统”。硬实时系统要求任务严格满足时限要求，在系统出现局部错误时，仍然能保证所有任务在截止期限之前产生正确的结果，否则会导致灾难性后果（例如展开气囊过晚或制动压力产生的滑行距离过长）。而软实时系统则指操作系统在平均情况下能支持任务的执行期限，超过截止期限后不会造成系统整体失败。

铁路信号系统是安全苛求系统，应用在铁路信号系统中的安全计算机平台，需要满足长时间不间断连续运行条件下的高安全性和高可用性。它应该具备整体和多层次的安全性和可靠性冗余结构，并满足严格的实时性要求。相比之下，Autosar AP系统中对实时性要求较低，除了刹车和ABS系统等有较高的硬实时性要求，其余的功能对实时性的要求较低。因此，安全关键实时系统中的容错，成为实时系统的研究热点。

3.2 计算上的防护

现在的工业芯片设计厂家质量控制都涵盖了很多CPU出错防护手段，这些手段甚至比相关标准中的要求还严格。

对CPU计算上的防护主要有：

• 取到错误指令，因为指令缓冲区的原因
• 取指超时
• 接到错误的跳转指令，因为取指错误造成
• 分支跳转指令本身错误

3.3 内存的防护

瞬态故障可能导致软错误，例如单事件翻转或者叫随机比特翻转。外围设备的软错误会影响处理器与外界环境的正确数据交互。内存或处理器流水线中的软错误可能会导致应用程序的执行出现错误，包含控制流错误（Control Flow Error, CFE）和数据流错误（Dataflow Error）。

为了应对内存中的软错误，常见做法是采用错误更正码（Error Correcting Code, ECC）来自动修正单个比特翻转。锁步执行是一种依赖硬件支持的双模冗余技术，一个芯片上的两个核可以同步执行一样的代码, 由片上的一个独立的比较器来对比计算结果，如果不吻合，就会产生一个陷入或异常。

3.4 通信的防护

通信的防护更多的是因为CAN、串口这样的直接基于物理设备的通信，而TCP/IP协议栈基本上不会有这类错误。如图2所示，AUTOSAR的构件间通信，不只是通过以太网，还支持多种通信方式。这在轨道交通的车载系统中，也是有这样的设计的，不可能所有设备都是通过以太网连接的。

图2 AUTOSAR通信支持示意图

数据传输存在以下故障类型：

• 信息的重复：信息被接收一次以上；
• 信息的丢失：信息或部分信息从传输的信息流中被删除；
•  信息的延迟：信息的接收比预期的晚；
•  信息的插入：在传输的信息流中插入额外的信息；
•  信息的伪装：非真实的信息被传输者当作真实的信息接受；
•  信息的不正确的寻址：信息被不正确的发送者或不正确的接收者所接受；
•  信息的不正确顺序：信息传输过程中修改了顺序；
•  信息的破坏：改变了信息的内容。
•  从一个发送方发送至多个接收方的不对称信息：接收者确实从同一个发送者那里收到不同的信息；
•  从一个发送方发出的信息只被一个子集的接收方收到：一些接收者没有收到信息；
•  阻断对一个通信通道的访问：对通信通道的访问被阻断。

这些故障类型存在于一个ECU内部的不同软件构件、OS-Application，也存在于不同ECU硬件之间。

AUTOSAR对功能安全标准的理解更加符合当前计算机硬件技术的发展，它引入了内存管理、虚拟机技术等技术，具有探索性。从汽车控制系统和轨道交通控制系统的计算上的差别来进行分析，更有助于从AUTOSAR中借鉴技术成果：

（1）与汽车控制系统完全控制汽车不同，控制列车的不只是车载系统，还有轨旁、车站系统和信号系统等。基于运行图的控制系统本身具有中央控制的特点；
（2）汽车控制系统和轨道交通系统的硬实时策略不同，轨道交通更重视计算的时间可确定性，但计算不快，通常要求20ms计算结果，RBC是500ms的计算周期。
（3）轨道交通组合计算（多传感器，时序、互锁）多，ATP、ATO等多个系统互相监测，只要有一个出错就降级或导向安全状态。这些设施是系统级的，从宏观角度看，这降低了单一控制系统出错处理的风险。

参考文献
[1] 中国汽车基础软件发展白皮书3.0-2022年
[2] 容错计算技术https://zhuanlan.zhihu.com/p/364353547
[3] AUTOSAR的四种功能安全机制https://mp.weixin.qq.com/s/Wy1p5AJOL9RP8C2-IG_Rkw
[4] RT-Cloud: Virtualization Technologies and Cloud Computing for Railway Use-Case

高筱裴喜龙刘慎行
同济大学——上海电气泰雷兹智慧轨道交通联合工程技术研究中心

文章转自公众号“上海电气泰雷兹 TST”

上一篇：安全功能建模与仿真——模型与代码联动下一篇：汽车里的安全关键型ASIC和SoC怎么开发？