简介
本文主要分三大块：功能安全机制；功能安全措施；硬件诊断。一般来说，只有在理解了功能安全机制以及了解AUTOSAR对于功能安全有哪些必要信息是需要知道的，否则对于开发人员来说，很难在一个项目中能够高效地实现功能安全完备地系统。本文内容非常适合和功能安全工作相关的开发者阅读，同时，作为AUTOSAR的一些概念知识，也非常适合其他AUTOSAR工程相关人员进行阅读，为之后的具体配置打下基础。
功能安全机制
现代ECU包含高度模块化的嵌入式软件，可以组合非功能安全，和功能安全的SWC，它们分别拥有不同的ASIL安全等级。
根据ISO26262，如果嵌入式软件包含不同ASIL等级的SWC，要么整个软件工程都需要基于最高安全等级的要求进行开发，要么需要保证拥有更高安全等级的SWC的操作不会受到其他SWC的干扰，也即需要做到FFI(Freedom from interference)的设计。
ISO26262标准也提供故障示例，这些故障/错误会导致SWC之间产生干涉/干扰：
- 内存 Memory
- 时间 Timing
- 执行 Execution
- 信息交换 Exchange of Information
内存分区 Memory Partitioning
基于更低安全等级要求开发的SWC，可能会出现错误地访问到更高安全等级SWC的内存区域，产生干扰。为此，SWC需要运行在不同的内存区域，或者不同的内存分区，来防止类似的内存访问违例。
在AUTOSAR中，我们需要借助于OS和RTE模块的功能来实现。
故障模式
根据ISO26262，以下内存相关的故障影响被视为SWC之间产生干扰的原因：
- 内容损坏
- 读写区域属于另一个SWC
- 数据不一致
- 栈溢出或栈下溢
内存分区可以通过限制对于内存以及内存对应的硬件的访问，来达到内存保护的目标。内存分区意味着，各OS Application运行在相互保护（不干涉）的内存区域（分区）。也就是说，在某一个分区上运行的代码，无法修改另一个分区的内存。
此外，内存分区也可以保护只读内存段（例如代码执行）以及内存对应的硬件。
内存分区和用户/特权模式可以保证SWC之前互不干扰——即使某一个SWC出现了内存相关的故障，也不会对其他软件模块有影响，如果一个SWC运行在用户模式，那么它对CPU资源/指令的访问也是受限制的。
AUTOSAR中的内存分区
AUTOSAR规范中有这样的描述：一个分区应当用一个OS Application实现；SWC被分组到单独的用户模式内存分区中。所以内存分区的功能需要由RTE和OS来完成。
从架构上来说，应用软件运行在RTE之上，SWC之间相互连接并共同完成功能。
SWC与硬件无关，所以它们可以被集成到任一ECU上，SWC内部的变量和函数调用，都是封装起来，对外界来说是隐藏的，只有外部的RTE调用会作为公开接口。
SWC也有运行时需要被调用的函数，AUTOSAR中，这些函数关联到Runnable上。Runnable无法自己调用自己，它们必须被分配到操作系统的可执行实体上，实际配置当中可以通过将Runnable分配到某一OS任务中。
根据配置的不同，Runnable会周期执行或者以事件驱动的方式被触发，Runnable分配到Task的关系可参考下图：
OS Application
AUTOSAR OS Application是一系列OS对象的组合：Task, ISR，调度表，Counter，Alarm。所属同一OS Application的对象，可以互相访问。
同一OS Application的OS对象，可能会属于不同的SWC，RTE通过实现一个OS Application所有成员都能访问的内存区域，没有限制的方式，来实现SWC之间高效的通信。
OS Application有两类：
1. 授信应用(Trusted OS Application): 可以在运行在监控或者保护功能关闭的状态，它们可以有不受限制的内存和OS API访问权限。当处理器支持时，它们可以运行在特权模式。
2. 非授信应用(Non-Trusted OS Application): 无法运行在监控或者保护功能关闭的状态，它们仅拥有有限的内存和OS API的访问权限，也无法运行在特权模式。
通信和代码共享
一个OS Application可以包含多个SWC和它们对应的Runnable。Runnable只被允许直接访问它所在的SWC的变量或者进行函数调用。
SWC内部的函数调用和变量不被其他SWC所知，代码实现上，它们不会存在于头文件中并提供extern的访问方式。因此，想要直接通过变量或者调用的方式和其他SWC进行通信是不可能的。
上图中，OS Application 1中的Runnable1 就可以执行/使用Runnable 2的内容，而在OS Application 2中，Runnable 4是无法执行/使用Runnable 5的内容。SWC之间的通信应当通过RTE来完成。
AUTOSAR应用的内存分区
AUTOSAR OS规范中相关的需求如下表：
虽然一个项目当中可以有不同ASIL等级的SWC，但是不同ASIL等级的SWC不应当被分配到同一OS Application当中，内存分区无法在这种情况下提供FFI的支持。
SWC内的内存分区
同样，有一种情况是SWC内部有不同ASIL等级的Runnable，但是这种情况无法实现，因为内存分区是基于OS Application的，SWC只能分配到一个OS Application中，那么也就只能有一个内存分区，无法为Runnable提供不同的分区以达到保护：
如果一定有这样的需求，OS Application级别的分区是不足够的，需要在Task级别进行内存分区。也即上图的最右侧部分：
AUTOSAR OS规范中对这种场景也有需求定义，但是需要注意的是，这里的描述都是“可以”/“可能”(may)，也就是说Task级别的分区取决于OS的实现，AUTOSAR本身不做强制要求。
内存分区的实现
一般来说，BSW模块运行在授信模式/监控者模式内存分区当中，部分SWC分组并放置到非授信/用户模式内存分区当中。个别SWC也运行在授信/监控者模式内存分区当中。项目中可以有多个非授信/用户分区，每个分区都可以包含一个或多个SWC。
现代微控制器以专用硬件，也即内存保护单元（MPU），来支持内存分区。
在MPU的支持下，非授信应用可以被允许访问多个微控制器地址空间的分区。访问控制包括读访问，写访问和执行访问。MPU的配置只允许在监控者模式下执行。
有的微控制器上，MPU被集成在处理器的核上，也就是说MPU只控制对应核的访问权限。例如DMA控制器和其他核，则不受这些MPU的控制。
下方列表展示了内存保护单元配置的相关场景：
X-需要保护，O-保护可选
案例1：SWC在同一分区
SWC可以访问相互的RAM区域，因此有可能改变对方内存中的内容。
SWC无法访问外设，因为设计上来说SWC本就不知道底层架构。如果SWC拥有外设的直接访问权限，就意味着系统很可能是不安全的。
案例2：SWC在不同分区
SWC无法访问对方的RAM区域，因此也无法改变对方内存中的内容。
SWC无法访问外设，因为设计上来说SWC本就不知道底层架构。如果SWC拥有外设的直接访问权限，就意味着系统很可能是不安全的。
案例3：MCAL驱动
MCAL组东是读/写/初始化等操作的集合，他们必须由其他实体，例如BSW或者CDD，来调用执行。
MCAL驱动需要外设空间的读写访问权限，根据硬件架构，可能需要在监控者模式运行才能有这些权限。
检测和反应
微控制器硬件必须由OS正确配置，当出现不正确的内存访问情况时能检测到，或者能预防这样的情况。运行在非授信/用户模式内存分区的SWC会被监控。
当这种模式下出现非法内存访问或者CPU指令时，错误操作会被拦截并由硬件产生exception。OS和RTE通过关闭分区或者重启当前分区所有SWC的方式来处理这种情况。
具体情况视项目而定，可以在OS中配置Protection Hook的具体实现。如果想了解规范是如何说明错误处理的，可以阅读“Explanation of Error Handling on Application Level”。
限制
1. ISO26262并未要求同ASIL等级OS Application内SWC的FFI。
2. 授信OS Application不受内存分区影响。
3. 内存分区不支持task级别。
4. 内存分区功能会影响系统整体运行性能。
5. BSW模块分区并不做要求。
时间监控 Timing Monitoring
一个功能安全的系统，要求系统中的动作能在正确的时间执行。SWC无法自己决定自己的正确运行时间，需要依赖于运行时环境以及基础软件，在集成过程中，要保证SWC的时间约束。
失效模式
根据ISO26262，以下时间或执行故障被视为SWC之间的干扰原因：
- 阻塞运行
- 死锁
- 活锁
- 不正确的执行时间分配
- SWC之间的不正确同步
时间保护和监控和以下属性有关：
- 监控任务在特定时间调度
- 不超过预期执行时间
- 不独占OS资源
为了保证功能安全相关功能满足时间约束，应当能够检测并处理某一任务独占CPU（过高的CPU负载，很多中断请求）的情况。
AUTOSAR提供下列时间监控机制：
1. OS提供的时间保护机制
2. Watchdog Manager提供的时间、逻辑链监控的功能
操作系统的时间保护
根据AUTOSAR OS规范，实时操作系统在运行时发生任务或中断没有在预期时间内执行结束，被视为发生了时间故障。
AUTOSAR OS并不提供deadline supervisor来作时间保护，deadline superviosr不足以正确地识别出导致了系统的时间故障的任务或中断，因为实际情况下，有可能是被一个没有关联的任务或中断干扰了执行过程。
在例如AUTOSAR OS这样有固定优先级抢占的操作系统，任务或中断是否在deadline之前能执行完毕，和以下几个因素有关：
- 任务或中断的执行时间
- 因其他低优先级任务或中断锁住了共享的资源，或者是关闭中断这期间而产生的阻塞时间
- 任务或中断的时间间隔
为了实现安全和精确的时间保护，操作系统需要能在运行时控制这些因素，保证任务或中断能够达到deadline的要求。AUTOSAR OS提供以下时间保护机制：
- 执行时间保护。任务执行时间上限，或者Cat2类型中断，它们也被称作为执行计划（Execution Budget），由OS监控来避免时间错误。
- 锁时间保护。资源、锁、中断挂起的时间上限，它们也被称作为锁计划（Lock Budget），由OS监控。
- 时间间隔保护。两次任务被激活或者Cat2类型中断的时间间隔，也被称作为时间框（Time frame），由OS监控。
检测和反应
WdgM模块根据每一个Supervised Entity的本地状态和全局监控状态，可以基于配置进行对应的恢复操作。
限制
- WdgM并不限制Checkpoint的颗粒度，如果一个SWC只有一个checkpoint，代表某一runnable是周期执行的，那么WdgM只能检测这个Runnable是否按照周期在执行。相对的，如果在每一个执行块和分支都加上了Checkpoint，那么WdgM还可以检测SWC的执行流程。当然，更高的颗粒度意味着WdgM的配置和复杂度也会相应地增加和提升。
- Deadline Supervision只检测是否有延时，但是出现根本不调用End Checkpoint而导致的Timeout，则无法检测出来。
- Deadline Supervision不能嵌套使用。—— Start 1, Start 2, End 2, End 1
- WdgM没有指定是否可以在一个Supervised Entity中设置多个Alive Supervision checkpoint。不过推荐的做法是只能由一个Alive Supervision checkpoint。
- 关闭或重启包含Supervised Entity的分区时，集成代码应当调用WdgM的函数关闭（关闭并重启开启）Supervised Entity。
- Library不能调用BSW，所以无法被WdgM监控，但是可以通过在library调用的前后设置checkpoint的方式来作Deadline Supervision.
- BSW模块如何用Supervised Entity ID来识别，并没有标准化。
逻辑监控用来检查软件的正确执行，关注于控制流错误。当发生控制流错误时，会导致走向非预期的程序执行顺序，最终导致数据不一致，数据损坏或者其他软件故障。
限制
- Logical Supervision不支持一个checkpoint存在于多个Graph中。
- WdgM不支持在可以并发调用的Supervised Entity进行Logical Supervision。
- 关闭或重启包含Supervised Entity的分区时，集成代码应当调用WdgM的函数关闭（关闭并重启开启）Supervised Entity。
在分布式系统当中，如果存在一些安全操作依赖于某些数据，那么发送端和接收端的对这些数据进行的交换过程就会影响到功能安全。因此需要想办法保证通信数据发生数据不一致等情况的故障不会影响程序。
故障模式
根据ISO26262，在不同的软件分区和ECU上执行的SWC交换数据时，以下情况被视为信息交换相关故障：
- 信息重复：信息收到不止一次
- 信息丢失：部分信息丢失
- 信息延迟：比预期更久的时间才收到信息
- 信息插入：有额外信息被加入到信息当中
- 信息伪装，或地址错误：不真实的数据被作为真实数据接收；发送给了不正确的接收方或者接收了不正确的发送方的消息
- 信息序列不正确：信息序列被修改
- 信息损坏：信息被修改
- 发送方发送到多个接收方的数据不一致
- 应当从发送方收到消息，但接收方并未收到
- 无法访问通信通道
E2E保护假定安全相关的数据交换应当在运行时被保护起来，可能的故障原因有随机硬件故障（例如CAN收发器寄存器损坏），干扰（例如EMC干扰），或者是软件的错误实现（例如RTE, IOC，COM）。
从SWC角度来说，通过RTE进行数据传输的行为就是简单的点对点连接，然而，实际上通信连接的抽象的具体是由各个软件层，通信协议栈，驱动和底层硬件实现的。基于这样的复杂度，随之而来的是故障可能性的提升。
使用E2E机制是假定安全相关数据需要能在通信过程中保证数据不会受到故障的影响。E2E保护最重要的部分，是保护能力和灵活性的标准化。
E2E保护的架构是这样实现的：包含应用数据的数据元素，在发送方会加上额外扩展的控制信息，也即E2E头部。控制信息一般包含Checksum, Counter和其他选项。扩展后的数据被提供给RTE做传输。
在接收方，会对接收到的数据中的E2E头部和应用数据做检查，如果检查通过，控制信息会被移除，应用数据会被提供给对应的SWC。如果有错误，错误处理是在接收端进行。
E2E Profiles
AUTOSAR指定了一组标准、可配置的E2E profiles，提供不同的保护机制实现，定义了对应E2E头部的格式。
从下列数据保护机制中挑选不同的组合，即不同的E2E Profile：
- CRC checksum，由CRC library提供
- 每次发送请求时都会自加序列Counter，接收方会检查是否正确
- 每次发送请求时会自加Alive Counter，接收方会检查是否改变，但不检查自加值是否正确
- 通过port发送数据时会附上唯一的port ID
- 超时检测：接收方通信超时和接收方确认超时
AUTOSAR标准定义了三种E2E Profile—— Profile 1, Profile 2和 Profile 4，后续发布会更新Profile 5和Profile 6。
应当只在项目当中使用标准E2E Profile，只有在legacy软件当中，由于特殊情况，可以使用非标准E2E Profile配置。
Profile 1描述如下：
虽然Data ID长16bit，可以有很多种ID，但CRC校验值只有8bit，意味着不同的ID有可能计算出相同的CRC校验值，因此实际可用的ID数量是受到限制的。（因此，实际情况是Data ID限制在255以内）
E2E Profile 2则在Data ID保护方面使用了不同的方式。每一对S/R port都有一列Data ID，当前的Counter决定使用哪一个Data ID。这种方案使得检测出地址伪装的情况变为可能，但一共能使用的Data ID仍被限制为256以内。
AUTOSAR最大支持4kB长度的PDU，由于使用了8-bitCRC校验值，Profile 1和Profile 2只支持最大30或42byte PDU长度的ASIL D数据传输。自4.2.1标准以来，定义了Profile 4来适配大数据的传输，CRC校验值为32bit长。
Profile 4的头部结构如上图。
E2E状态机
接收方根据设置的Profile来验证头部信息和应用数据是否匹配，决定当前周期接收的数据是否正确，出现错误时提供额外信息。
4.2.1版本规范以来，引入了状态机的概念，可以帮助决定接收到的应用数据在更高一级的细节上是否可以接收，也就是说应用会收到此次通信的一个整体状态，而不需要去判断每一个消息的状态值。状态机是可配置的，可以设定消息丢失或者重复消息的次数，是否可以故障恢复，通信初始化等待。
E2E Library的集成
E2E Library可以使用E2E Wrapper来完成SWC之间安全相关数据的保护。
E2E Library也可以通过COM回调的方式来保护I-PDU。
当然，你也可以将上述两种方法配合起来使用。
自4.2.1版本规范以来，你也可以使用RTE Data Transformer来基于RTE级别完成复杂数据交换的保护。
E2E Wrapper
为了使用E2E Library完成数据保护，E2E Wrapper通过封装Rte_Write和Rte_Read的方式为SWC提供接口。
在这种方式中，安全相关SWC会有自己额外的sub-layer，负责复杂数据构造到对应的IPDU中。
E2E保护是一种对称式的解决方案，对于实际的通信资源，它并不关心，不同的项目，SWC无需修改逻辑，只需要变更底层配置。使用E2E Wrapper后，即使底层通信软件协议栈不是功能安全的，仍可以为SWC双方提供功能安全的数据通信。不过呢，E2E Wrapper不支持SWC的多实例化。
Transmission Manager
如果在某一个ECU系统中无法为COM和RTE提供操作完整性，还是传输安全数据的解决方案。
在发送方，会有一个称作为Transmission Manager的SWC，它包含E2E Wrapper，Transmission Manager会收集相关SWC的安全数据，使用E2E Wrapper来保护他们，最后将数据提供给RTE。接收方即这个过程反过来执行。
COM E2E回调
E2E Library可以由COM回调来进行调用，保护IPDU，不过这种方式仅限用在提供了COM和RTE操作完整性的系统上。
RTE Data Transformer
这种方案的区别，可以通过示例图很直观的看出：
RTE接收到数据以后，基于配置（例如序列号，E2E保护，加密，压缩）然后进行数据转换，将最终的结果数据交给COM进行处理。RTE Data Transformer的所有配置都在设计arxml的时候完成，实际代码全部都是由工具生成出来的，SWC并不需要关心具体用了哪些保护机制。
这种方案需要在RTE的操作完整性被提供的情况下使用。
限制
只是使用E2E Library并不能保证端到端的安全通信，用户需要说明所选的Profile提供足够的错误检测能力（例如硬件错误率的评估，bit error错误率，网络中的节点数量，消息的重复率，网关的使用）
SWC在RTE之间的通信不仅仅是一个简单的点对对通信，诸如数据转换，过滤，缺少通知，C/S通信参数顺序错误，传输延迟等待也需要被考虑进来。
当运行时负载过高时，有可能会禁止使用E2E保护。
E2E不保证数据的实时性。
功能安全措施
AUTOSAR提供了上述很多功能安全机制，在功能安全软件开发阶段，AUTOSAR也提供功能安全措施来进行支持。
可追溯性是安全相关系统实现的前提。AUTOSAR提供从项目目的到AUTOSAR架构的软件规范的可追溯性。
不由AUTOSAR提供的功能安全措施AUTOSAR并不会提供所有可能需要的在应用开发过程中的安全措施，因此安全相关应用的实现必须保证安全开发生命周期是充足的。
包括但与限于：
- AUTOSAR规范并不定义ISO26262中描述的SEooC
- AUTOSAR并不定义类似于HARA或HAZOP这种风险分析管理等方法
- 没有Safety Case
- 没有功能安全审计
- 没有conformance test
- SWC实现的AUTOSAR feature追踪
- 对于AUTOSAR规范的验证
- 软件集成测试
