针对ISO 26262对功能安全软件研发的要求，AUTOSAR将功能安全需求进行了具体拆分。当前的AUTOSAR规范囊括了诸多功能安全组件软件开发的需求概念。
在AUTOSAR系统设计的架构中， 从系统功能设计到ECU功能实现，每个功能特性都需要逐一抽取并分配到对应ECU(如图1所示)，会出现部分功能模块需要较高安全等级的情况。
按照汽车安全完整性等级的要求， 即使绝大多数的功能与安全无关，ECU的所有软件也需要根据所要求的最高ASIL等级进行开发。
典型案例是仅仅一个功能模块需要ASIL D等级，但是整个ECU都需要按照ASIL D等级进行开发，这种情况称之为“ASIL提升效应”，会导致额外的研发工作量。
为了避免这种情况， ISO 26262允许不同ASIL等级的软件模块共存，不过需要充分证明这些模块之间不存在不期望的交互。这种系统称之为混合ASIL系统，采用软件分区的方式来实现，同时确保不同等级模块间的“Freedom From Interference，FFI“(免于干扰)。
图1: 混合ASIL系统ECU的功能模块分配
混合ASIL系统的设计中，不同模块之间的交互越少越好。
系统通过将功能模块进行拆分的形式进行软件分区，在分区之间做边界保护，防止故障传递导致的相互影响，至少做到检测到故障的存在，并将其通知给ASIL软件模块，这样系统可以就此采取一些安全措施。
这意味着只将功能安全相关的软件模块及边界保护部分开发成较高的安全等级即可，其他部分仍可保持较低安全等级(如QM)，软件交互如图2所示。
图2：ASIL 模块和QM模块共存时的边界保护
ISO 26262 对软件模块之间的交互进行了分析并提出了免于干扰的需求，具体落实到软件的边界保护包括：内存越界保护，运行时序保护，端对端通信保护。
分区可用于抑制故障以避免模块间的故障传递。
在混合ASIL系统中，不同安全等级软件模块之间的交互决定了模块间的相互影响，内存越界保护是实现软件模块之间边界保护的重要途经，主要使用微控制器的内存保护单元(Memory Protection Unit，MPU)对软件内存区域的访问进行限制。
根据功能安全的要求，微控制器执行保护和模块间上下文切换的软件必须具备最高安全等级，即ASIL D等级。在此简要介绍MICROSAR解决方案通过OS为软件分区所提供的Memory Protection常见特性及使用简介。
Memory Protection Unit
在MICROSAR 解决方案中，OS SC3/SC4(Scalability Classes )具备Memory Protection 功能特性，可以分别为OS Application 和OS Core 配置其对内存地址及外设的访问权限。
一般来讲，建议将ECU中同一安全等级的软件模块放在一个OS Application中，通过Memory Protection 的设置实现不同安全等级软件模块间的分区，并通过对不同区域设置访问权限来达到限制安全等级较低的软件模块对其他软件模块的访问。
Memory Protection 的实现需要MCU具有Memory Protection System，具备MPU。通过MPU的配置，软件模块将具备对不同内存区域的不同访问权限，主要包括RAM/ROM以及外设寄存器的访问权限。
例如，通过限制低安全等级软件模块对高安全等级软件模块的Flash段/RAM段访问权限，可有效防止低安全等级的软件模块故障对高安全等级模块产生级联性故障威胁。
MPU的配置是通过设置多个MPU Region来实现的，每个MPU Region的可配置选项包括：
一般来讲MPU分两类：System MPU和Core MPU。
System MPU 主要存在于多核系统中，用于对各个Bus Master 设定内存区域的访问权限。一般System MPU在系统启动时设定好，在软件运行过程中不被重新设置，不会在软件运行过程中动态更改Bus Master 对内存的访问权限。
Core MPU 是核内MPU，简称CMPU，一般每个核都具备一定数量的CMPU，可以为运行在该核上的OS Application/Task/ISR分别设定内存区域及外设寄存器的访问权限，从而实现软件模块分区。访问权限包括读/写/执行权限，可根据内存区域存储内容进行设定。在OS运行过程中，CMPU可以随着Application/Task/ISR的切换而动态变更。
当各OS Application的权限被设定好后，OS会在OS Application切换时对MPU相关寄存器进行重新初始化，并设置成即将切换到的OS Application权限。
当出现访问超出MPU允许权限范围时，MCU Exception会被触发并进入其相应的OS处理函数，用户可以根据情况Shutdown OS 或选择进入安全模式，从而有效阻止软件故障的发生。
推荐MPU配置
在OS SC3/SC4中，OS Application分两类：
具备最高安全等级的OS Application可以设定为Trusted Application
其他不具备Trusted 属性的Application属于Non_trusted Application。
OS和Trusted Application 运行在Supervisor Mode下
Non_trusted Application 则运行在User Mode下。
推荐为Trusted Application设定除stack 区域以外的所有地址范围的读/写/执行权限，包括外设地址。
为Non_trusted Application设定属于其私有的Code Flash和RAM段的访问权限，以及共享数据区域的读写权限。在软件运行过程中，OS会占用一个MPU Region来实时监控当前堆栈使用情况。当Task/ISR切换时， OS会重新初始化该MPU Region以进行堆栈溢出的监控。相对于通过堆栈末尾标志的改写情况来判断堆栈溢出的方式，使用MPU进行堆栈溢出保护更加及时。此外，OS 提供一些访问外设寄存器的API，供运行在User Mode下的OS Application调用，并使用OS的Supervisor Mode访问外设寄存器。
常见应用情况为低安全等级的MCAL模块调用OS API访问外设。用户使用时需要对外设地址设定相应的Peripheral Region，其配置选项包括起始/结束地址。
用户可以根据ECU软件各模块安全等级情况，将其合理划分到多个OS Application中，依据MCU资源设定MPU，进而实现不同安全等级的软件模块协同工作，并把故障概率降到允许范围内的需求。
进一步的检测方式可以通过监控ASIL软件模块的运行时序来实现，包括代码执行顺序和时间间隔等。
实现方式为软件看门狗管理模块配合安全的硬件看门狗进行监控：
当软件检测到任何不符合预期的运行时序，都将系统切换到安全状态，例如Fail Safe模式。这不能防止错误的发生，但是可以检测到错误并阻止其造成进一步的人身安全伤害。
运行时序保护采用3种形式的监控来实现：
Alive Supervision以心跳形式监控程序执行情况。例如监控周期处理函数是否按照期望周期运行，可以设置一个Check Point(CP)，在周期函数的某个位置触发该Check Point以通知看门狗管理模块该函数已执行，同时适当配置监控时间参数以做到一定程度的监控。即在一段时间内周期性的函数运行次数的监控。
Deadline Supervision监控程序中两点之间的运行时间间隔。设置两个Check Point并将其分别放在需要监控的程序位置，看门狗管理模块会根据二者分别到达的时间测量得到两点之间的执行时间，与配置的时间参数进行对比查看是否在期望值范围内，从而起到监控作用。
Program Flow 监控程序执行顺序。设置多个Check Point并分别插入不同的代码位置，看门狗管理模块通过各Check Point到达的顺序监控程序的执行顺序。
看门狗管理模块建立监控单元Supervisor Entity(SE)，并通过监控其状态来判断程序运行情况，每个SE通过观测Check Point的到达情况判断软件执行情况。如果出现异常情况则在一定的反应时间内做出处理，将系统调整进入Fail Safe状态。开发人员通过设计一定的Fail Safe模式预防故障造成进一步的安全问题。
ISO26262中列举了信息交互中的相关错误格式，AUTOSAR规范则定义了通过端对端保护来检测到这些错误的算法。
与程序运行时序监控一样，最终目的都是检测出故障，并在故障导致进一步安全问题之前控制局面，将系统控制在安全状态下。
端对端通信保护主要使用序列号和校验和对数据进行保护，通过对二者的检测判断是否有数据丢失、错乱、重复等问题出现。此外，高安全等级的端对端保护模块(End to End，简称E2E)需要配合安全的RTE(Runtime Environment)模块进行使用。
前文描述的混合ASIL系统所使用基于MPU的内存越界保护可以降低软件模块间的干扰，是非常强大的保护机制。但是不同安全等级软件模块之间的交互会导致系统重新初始化MPU硬件寄存器。这种交互越多，系统在上下文切换上消耗的运行时间就越高，从而严重影响系统性能。
针对此问题的解决方案是完全采用ASIL D等级的BSW软件模块，同时开发高安全等级的应用软件，这样各个模块之间的交互就可以直接进行，不需要进行不同软件分区的MPU处理。目前MICROSAR解决方案大部分软件模块已经达到ASIL D等级，如图3所示。
图3：MICROSAR解决方案各模块安全等级
06 总结
目前，根据AUTOSAR和ISO 26262，ASIL D等级的软件开发方法已经比较明确，规范内容覆盖了混合ASIL系统以及ASIL D BSW系统。用户在设计ECU软件时，不必假定每个BSW都有功能安全需求，可以根据实际情况进行设计，在确保功能安全需求实现的情况下，更好地提高系统性能。
————————————————
版权声明：本文为CSDN博主「hpsprger」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_35160923/article/details/112632575
一个系统中有8个模块，模块与模块之间会有很多相互调用的情况，如果其中3个模块是ASLB的，其他都是QM的如何保证QM的模块不影响ASLB的功能安全等级呢？
不同ASIL的Element的共存原则，需要保证其独立性和免干扰性。
主要包含“时间”和“空间”两个维度
时间：高ASIL等级拥有绝对的时间片优先权，不会被低ASIL等级模块占用资源
空间：高ASIL等级可访问低ASIL等级资源，反向禁止。
通常通过MPU(MMU)，实现权限管理以上是运行于同一个Core的处理方式，可以参考Autosar，当然如果能做到物理隔离，不同ASIL等级运行于不同的硬件资源，那是最根本的解决方式。
比如多核，或者运用Hypervisor等另外，从调用（业务部署）的角度说。QM调用ASIL B，以实现QM业务肯定没问题。
ASIL B调用QM，说明这个ASIL B的功能是被降级到QM的。
从模块开发角度，做好FFI即可。
功能安全等级混用要遵循FFI免于干扰原则，即避免低安全等级的模块对高安全等级的产生破坏。
通常高安全等级的模块去调用低安全等级的，如果正常返回ok，如果返回一个错误结果，高安全等级需要能够通过边界检查等方式，发现错误，并能处理这样的返回结果。
低安全等级的模块可以调用高安全等级的模块，但是一般只能读，不能写和修改。这样可以避免了对高安全等级造成破坏或污染。
如果系统中只有一个ASLD的模块，其余所有模块都是QM的。那么开发难度会不会由于一个ASLD的存在，变得非常大？
“通常高安全等级的模块去调用低安全等级的，如果正常返回ok”？
注意串联失效：
这要看具体这个调用的业务部署的。我举个例子，BSW(B)调用MCAL(QM)，以实现数据读取，如果数据读取业务的目标ASIL等级是B，那肯定不符合要求，因为MCAL是QM的。
