虽然AUTOSAR不是一个完整的安全解决方案，但它提供了一些安全机制用于支持安全关键系统的开发。本文用于介绍AUTOSAR支持的四种功能安全机制：
内存分区（Memory Partitioning）
时间监控（Timing Monitoring）
逻辑监督（Logical Supervision）
端到端保护（End-2-End Protection）
这些安全机制中，内存分区用于实现不同ASIL等级，安全相关组件和非安全相关组件的彼此独立，时间监控和逻辑监控是软件运行时序错误的常用检测方法，端到端保护实现了安全相关应用在非受信网络或存储之间数据交互的安全。
内存分区
内存分区用于解决不同软件组件之间的互相干扰，造成对内存存储的数据段或代码段的篡改，需要限制对内存和内存映射的硬件外设的访问。
在AUTOSAR架构下，分区是以OS-Application为对象划分的，属于一个OS-Application内的任务可以互相访问，一个OS-Application包括多个任务Task，软件组件SW-C的实现由一组可运行实体Runnable组成，Runnables在其调用者OS-Task的上下文中被循环执行和/或以事件作为触发。下图是OS-Application、Task、Runnable、SW-C之间的关系。
AUTOSAR 操作系统将OS-Application放入独立的内存区域，由操作系统实现不同应用免受内存故障干扰，这种机制称为内存分区。由于在一个OS-Application的内存分区中执行的代码不能修改其他内存区域，因此OS-Application之间相互保护。
具有不同 ASIL等级的软件组件不应分配给同一个 OS-Application。操作系统只是防止其他 OS-Application进行不适当的访问。一个有问题的软件组件不会被阻止修改同一 OS-Application中其他软件组件的内存区域。同一软件组件不能分配到不同的OS-Application中。
内存分区的实现方案是通过CPU的supervisor/ user mode进行分区，基础应用任务运行于supervisor mode，普通应用任务运行于user mode。所有的基本软件模块都在一个trusted/supervisor 模式的内存分区中执行(红色)。一些软件组件在逻辑上被分组，放在单独的non-trusted/user模式的内存分区中（绿色）。选定的软件组件属于与基本软件模块相同的受信任/监督者模式内存分区（见图8中第四个SW-C以红色突出显示）。可能有几个非信任/用户模式分区，每个分区包含一个或多个软件组件。
内存分区功能需要专用硬件支持MPU（memory protection unit），MPU允许非受信的应用访问微控制器地址空间的多个部分，访问控制定义为Read/ Write/Execute访问的组合。MPU的配置只允许在supervisor模式下进行。硬件由操作系统进行适当的配置，以检测和防止错误的内存访问，然后监控在非受信/user模式内存分区中软件组件的执行。
错误处理策略：
如在非受信/user模式分区中出现内存访问违规或CPU指令违规，错误的访问将被阻止，并由微控制器硬件提出一个异常。操作系统和RTE通过执行分区关闭或重新启动该分区的所有SW-C来处理错误的软件分区。
2.时间监控
为避免软件组件之间出现的执行阻塞、死锁、活锁、执行时间的不正确分配、软件元素之间的不同步，需要对软件的运行时间进行监控，以确定软件运行的正确时序。
受监督的软件实体可以是软件组件、基础软件模块或CDD中的一个SW-C或Runnable。受监督实体中的重要位置被定义为checkpoint。受监督实体的代码与看门狗管理器的函数调用交错在一起。这些调用用于向看门狗管理器报告达到了一个checkpoint。
看门狗管理器实现两种监督方式：Alive supervision和Deadline supervision。
Alive Supervision: 周期检查被监督实体的checkpoint是否在给定的范围内到达。这意味着看门狗管理器检查被监督实体的运行频率是否过高或过低。
Deadline Supervision：非周期性或偶发性的被监督实体对两个checkpoint之间的时间有单独的约束。通过Deadline Supervision，看门狗管理器检查被监督实体的两个checkpoint之间的转换时间。这意味着看门狗管理器检查被监督实体的某些步骤所需时间是否在配置的最小和最大范围内。
错误处理策略：
当检测到错误时，看门狗管理器将启动以下错误处理策略的一种：
被监督实体内的错误处理：如果被监督实体是SW-C或CDD，看门狗管理器可以通过RTE模式机制通知被监督实体监督失败的情况，然后，被监督实体可以采取其行动从该故障中恢复。
分区关闭：如果看门狗管理模块检测到位于非信任分区的被监督实体的监督失败，看门狗管理模块可以通过调用BswM请求分区关闭。
由硬件看门狗复位：看门狗管理器向看门狗接口指示看门狗接口何时应不再触发硬件看门狗。在硬件看门狗超时后，硬件看门狗对ECU或MCU进行复位。这将导致ECU和/或MCU硬件的重新初始化和软件的完全重新初始化
立即MCU复位：如果有必要对监控故障做出立即的、全局的反应，看门狗管理器可以直接导致MCU复位。这将导致MCU硬件和整个软件的重新初始化。通常情况下，MCU复位不会重新初始化ECU的其他硬件。
3.逻辑监督
逻辑监督用于检查软件是否按照正确的逻辑顺序执行。如果一条或多条程序指令以不正确的顺序被处理，或者甚至根本没有被处理，就会发生不正确的控制流。例如，控制流错误会导致数据不一致、数据损坏或其他软件故障。程序序列的逻辑监测是ISO26262、IEC61508、MISRA所要求或建议提出。
与时间监控一样，受监督的软件实体可以是软件组件、基础软件模块或CDD中的一个SW-C或Runnable。逻辑监督同样基于checkpoint进行检查，每个被监督实体都有一个或多个checkpoint。一个被监督实体的checkpoint之间的转换形成一个图。
一个图可以有一个或多个初始checkpoint和一个或多个最终checkpoint。假设checkpoint属于同一个图，那么从任何初始checkpoint开始到任何最终checkpoint结束的任何顺序都是正确的。
错误处理策略：逻辑监督的故障处理策略与时间监控的处理策略一致。
4.端到端保护
在一个分布式系统中，发送方和接收方之间的数据交互可能会影响功能安全，如果其安全行为的安全性取决于这些数据的完整性。因此，此类数据的传输应使用保护机制，以防止通信链路内的故障影响。
数据传输存在以下故障类型：
信息的重复：一种通信故障，即信息被接收一次以上
信息的丢失：一种通信故障，即信息或部分信息从传输的信息流中被删除
信息的延迟：一种通信故障，即信息的接收比预期的晚
信息的插入：一种通信故障，即在传输的信息流中插入额外的信息
信息的伪装：一种通信故障，即非真实的信息被传输者当作真实的信息接受。
信息的不正确的寻址：一种通信故障，即信息被不正确的发送者或不正确的接收者所接受。
信息的不正确顺序：一种通信故障，它修改了传输信息流中的信息顺序
信息的破坏：一种通信故障，它改变了信息。
从一个发送方发送至多个接收方的不对称信息：一种通信故障，即接收者确实从同一个发送者那里收到不同的信息
从一个发送方发出的信息只被一个子集的接收方收到：一种通信故障，一些接收者没有收到信息
阻断对一个通信通道的访问：一种通信故障，即对通信通道的访问被阻断。
这些故障类型存在于一个ECU内部的不同软件组件、OS-Application，也存在于不同ECU硬件之间。
实现端到端保护的方法是在通信协议中，数据发送方增加端到端控制信息，控制信息通常包含一个校验和、一个计数器和其他选项。扩展后的数据元素被提供给RTE进行传输。
数据元素在接收方通过处理端到端控制信息的内容与应用数据进行验证。在收到的数据元素被处理并接受为正确后，控制信息被删除，应用数据被提供给目标软件组件，错误处理是在接收方进行的。
端到端的数据保护机制包括：
CRC校验和，用于检验数据是否被破坏；
顺序计数器，在每次传输请求时递增，该值在接收方检查是否正确递增，用于检查数据是否丢失、插入、顺序混乱；
在每个传输请求中增加的alive counter，如果它有任何变化，在接收方检查其值，但不检查正确的增量；
ID:通过端口发送的每一个端口数据元素都有一个特定的ID（对系统来说是全局的，因为系统可能包含几个ECU）；
超时检测，接收器通信超时和发送器确认超时。
AUTOSAR 4.2.1 版还引入了一个状态机，帮助确定所收到的应用数据是否可以接受，并且更加详细。通信状态机用于接收方接收到正确数据、错误数据以及可恢复、不可恢复的状态转换。
端到端保护以软件库的方式提供，可以有不同的解决方案。它们可能取决于RTE、COM或其他基本软件模块的完整性，以及其他SW/HW机制的使用（例如，内存分区）。
错误处理策略：端到端通信保护功能在 AUTOSAR 4.0 中作为标准库实现。这个库提供了End-2-End通信保护机制，使发送方能够在传输前保护数据，接收方能够在运行时检测和处理通信链路中的错误。当接收方检测到通信错误后，将向应用提供错误类型，数据处理方式（丢弃/使用上周期/重启）。
从软件应用层来看，端到端通信保护是一个点对点的连接，但为了达到多点通信的灵活适用性和互通性，300多页的端到端设计规范可以看出，在通信协议的设计上需要考虑很多
总结
以上是AUTOSAR架构提供的四种功能安全机制，用于在内存保护、软件执行的时间和逻辑顺序、数据交互需要考虑的安全机制，这些内容更多是规范性方面的要求，不涉及具体的实现方法，例如时间和顺序监控中，看门狗的checkpoint应该设置多少个，监督检测到错误应该采用何种处理，由各厂商在遵循AUTOSAR框架下去具体实现，为保证互通性，AUTOSAR仅提供统一的外部调用接口；
这些安全措施作为ISO26262中的通用性安全要求，应予以遵循，但AUTOSAR没有从系统层进行结构化的安全分析，这些安全要求并不完备，也没有ASIL等级，还应结合具体的相关项定义进行补充和规定。
从应用方角度来看，安全功能的设计实现不是应用方所关注的，已在AUTOSAR架构中予以实现，应用只要实现对这些功能进行参数配置，按照给定手册中的要求进行调用即可，简化了安全功能的实现过程，另一方面来说，由于对接口做了封装，也了解不到具体的实现细节。
本文主要内容来自于AUTOSAR官方文档《Overview of Functional Safety Measures in AUTOSAR》，如有疏漏，以原文为准。
推荐阅读
带不带功能安全(IS26262)的区别，功能安全要做啥？
谈谈Bootloader自更新
谈谈对两家AUTOSAR工具看法
奥迪首款800V车型技术总览
CAN设计与应用指南
汽车软件需求是如何变成用户功能？
电子电气架构设计需要考虑哪些方面？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
分享不易，恳请点个【👍】和【在看】
