上次我们介绍了SafeTLib的一些安全目标（聊一聊SafeTlib的Software Safety Case）今天我们再来分析一些和MCAL相关的功能安全的内容。

根据英飞凌提供的对Aurix的MCAL 安全信息手册MC-ISAR Safety Information Infineon Software Architecture，以及MCAL Safety Case报告，总结Aurix的基于功能安全的MCAL驱动开发的一些Tips。

首先还是先看一下架构。

Aurix的MCAL软件是基于SEooC的方式开发的，top level的安全目标为：基于ASIL B的流程开发基于AutoSAR的MCAL模块，使得他们满足安全相关的use case。

这些Driver分为如下几种类型，其相应的安全等级如下：

1）Microcontroller Driver      

MCU (ASIL B)      

WDG（QM）      

GPT (ASIL B)

2）Memory，Memory Hardware Abstraction Driver 

FLS（QM）      

FEE（QM）

3）IO Driver      

PORT (ASIL B)      

DIO  (ASIL B)      

ADC  (ASIL B)      

PWM  (ASIL B)      

ICU  (ASIL B)

4）Communication Driver， 

Communication Hardware Abstraction Driver      

CAN （QM）      

LIN（QM）      

FR（QM）      

SPI  (ASIL B)      

ETH（QM）      

CANTRCV（QM）

5）AutoSAR Libraries       

CRC  ( ASIL B )       

BFX ( QM )

6）Complex Driver       

DMA（QM）      

FlsLoader（QM）      

UART（QM）      

MSC（QM）      

GTM（QM）      

STDLIN（QM）

7）MCAL Libraries ( ASIL B )

值得注意的是，上述的安全等级为TC2xx系列的，英飞凌最新的Aurix产品，TC3xx系列的MCAL驱动中，FLS和FEE已经达到ASIL B等级了。但这也不妨碍其上层的NvM在需要实现功能安全的需求时，仍然需要采取安全措施，如CRC。

软件架构假设，用于指导我们各个模块按照何种安全等级的假设来开发，在自身ASIL等级为QM的情况下，如何做ASIL的冗余安全需求设计，使其满足安全目标的要求。

1）如上面所说，能达到ASIL B要求的模块有：MCU，GPT，PWM， PORT，DIO，ADC，SPI，CRC，ICU这9个模块，集成者如果想开发安全概念，使用这几个模块，则可以轻松实现ASIL B的安全需求。

2）CAN， CANTrcv，LIN，ETH,，FLEXRAY，这些模块是按照QM来开发的，如果要实现ASIL level的安全概念，则需要在system level做ASIL分解，利用通信协议栈（QM）+安全机制如E2E（ASIL Level）来实现。注：Vector提供的AutoSAR软件包，其E2E保护机制可达到ASIL D

3 ) FEE，FLS，这两个模块是按照QM来开发的。如果要实现安全相关的应用，可以在system level做ASIL分解，如Mem Driver（QM）+安全机制如NVRAM Manager里面的Safety Check，如CRC校验

4）WDG是按照QM来开发的，可以采用ASIL分解，WDG（QM）+安全机制（Safety check, password verification,CPU watchdog hardware）

MCAL driver提供了三种安全机制来使其达到ASIL B的功能安全需求，分别为1) 输入输出的Range Check， 

2) FFI机制，尤其关注的是Memory Domain

关于FFI的一些说明，可以参考另外一篇文章

聊一聊功能安全中的coexist和FFI

3) 对Init函数进行Check

3.1 Range Check

输入和输出参数的Range check是在ISO26262的软件开发章节的内容

以ADC为例，介绍MCAL是如何做Range Check的：在很多函数的开始，都会判断是否使能了Safety Enable功能，如果使能了该功能，则会调用Adc_lValidateParamGroup函数来对参数进行Validate.

函数static uint32 Adc_lValidateParamGroup (uint8 ServiceId, Adc_GroupType Group, uint8 AdcKernel)的工作原理如下：检测参数赋值是否正确，如果出现错误，则置RetErr为ADC_E_PARAM_GROUP。并调用SafeMcal_ReportError函数。

关于SafeMcal_ReportError的具体执行，需要调用SafetyReport.c来执行。

3.2 Freedom from Interference with Respect to Memory

MCAL软件可以通过使用不同的硬件外设或者相互独立的Kernel来对ASIL B和QM的软件进行分区。所以我们在做MCAL配置之前，首先要分析好不同ASIL等级的信号，需要放在不同的分区里面。比如说，我们的ADC采用，有些通道是QM的信号，有些是ASIL B的。我们就要做好这样的处理，TC297支持6个ADC kernel，ADCHwUnit0-5。我们就需要分配好，哪个Kernel是QM的，哪个Kernel是ASIL B的。再者，SPI只支持单个hardware unit为ASIL，其他均为QM。

当我们明确了这一点之后，通过Enable Safety以及各个Kernel里面对Safety功能的enable，从而得到资源使用文档_ConfigDoc.html。Mod = Adc, Mcu, Port, Dio, Icu, Pwm, Gpt, Spi and Crc该文档会解释ASIL B软件variavles，SFR（特殊功能寄存器），以及code section的使用情况。集成人员需要根据该html文档来使能MPU的设置。

以ADC为例子，看看MCAL是如何对其进行分区的：

1）首先是再MCAL里面Enable Safety的功能

2）然后根据实际需求，对不同ADCHwUnit进行Safety功能的使能

使能之后编译会得到Adc_ConfigDoc.html

并在Adc_Cfg.h里面会有如下定义：

#define ADC_QM_KERNEL_USED_COUNT  (4U)

#define ADC_ASIL0_KERNEL_USED_COUNT  (2U)

#define ADC_ASIL1_KERNEL_USED_COUNT  (0U)

这个定义会在Adc_ConvHandle.c这个ADC的库函数里面用到，并且将变量存储到MemMap.h里面

3.3 Initialization Check

初始化函数的检测，也是通过MCAL里面使能的

以ADC模块为例，它是在Adc_HwHandle.c函数里面定义的Adc_InitCheck（）。如果check一切OK，会返回E_OK，否则返回E_NOT_OK。考虑了功能安全之后，初始化的步骤如下：

值得注意的是，PWM没有初始化检测函数，需要自己写Note: Pwm_InitCheck() API is not implemented in PWM driver. The integrator shall implement the check for initialization of PWM or use equivalent measures to detect any failures affecting the functionality (for example, corruption of SFRs, variables). The integrator may refer the initialization check example provided in PWM driver user manual section 9.3.