认真搞搞汽车MCU

2023.10.23最近有很多朋友在反馈这里面的文章有些比较粗略，没有CP AUTOSAR相关基础的话确实有时候不知道文章在说什么，我觉得还是有必要把CP的基础概念整理一下，因此接下来会根据AUTOSAR的框架将一些基本概念介绍一下，打算一共分16篇文章。

作为科普，到这个程度已经差不多了，如果要深入到相关开发，那就必须仔细研究FvM的机制，例如Master、Slave ECU对于FvM的处理机制，对于新鲜度值同步报文的处理方式，例如Slave没有收到Master的同步报文应该如何处理？在新鲜度值同步成功之后（重置周期内），正常情况下，TripCnt和ResetCnt都会保持不变，此时用于发送的安全PDU构建新鲜度值，就只会有一个变化，就是MsgCnt会自增1，发送出去的新鲜度值（假设14bitMsgCnt低位+2bit重置低位）会出现每次自增4的现象。

不止一次碰到过上述情况。之前做VCU需要路由某些关键信号，做座舱需要路由报文给下挂子节点时，本以为使用达芬奇点点点就可以搞定，结果打开Gateway功能，发现采购没购买Add-Ons。抓瞎了，重新提预算的话，不仅成本上去了，开发节点也守不住。怎么办？那就从两头抓，一方面继续追加采购，另一方面考虑根据需求手写。

我们上面讲到了从软件层面考虑如何实现网关功能，接下来我们继续讨论软件实现细节，以及S32G 的LLCE如何实现该功能。我们讲到最好不要去直接修改静态代码，那么再往上层走，有没有这样的接口呢？既然是应用指定的，那我在里面搞gateway功能应该也是可行的。在这里我们就找到了切入点，那么要如何实现gateway功能呢？从通信矩阵入手，做一个类似PduR的示例让系统进行填写，生成类似的路由表CanDriver_RouteTable和对应DBC，先导入到工具里骗骗达芬奇生成pdu handle；

AUTOSAR R23-11发布有一段时间了，不知大家有没有浅尝一下。据发布会介绍，这次版本主要面向下一代E\E架构新增了Safety、Security的特性，因此为了跟上节奏，现将最新CP AUTOSAR关于security机制进行汇总。

在上一篇文章，我们简述了CP autosar的信息安全相关模块和secoc通信，本节我们主要聊关于R22-R23提出来的新的机制。

那么AUTOSAR规定的这个架构具体长什么样呢？示意图如下所示：在BSW、MCAL这一层采用统一的标准接口，同时硬件与软件相互解耦；同时采用RTE的通讯方式，基本实现了应用软件与基础软件、硬件平台的解耦。上面这张图，大家可能还比较陌生，那下面这张图大家一定非常熟悉。上图是基于AUTSRA最新的R22-11。我们着重关注BSW这一层红色部分：MCAL(MicroController Abstraction Layer)；

上面几节，对SWC的通信机制、port类型和数据类型进行描述，有了这些基本概念，基本上在配置RTE的时候我觉得是够用了。 就这样吧，晚安！

先上一个我个人认为很形象的图片​ 所谓任务，就是能够被执行的最基本C函数；同时这些任务对CPU的访问权限是有竞争的，这就引出了任务的优先级概念；任务在执行完毕后释放CPU以供其他任务使用；这种理解角度可能比较新奇，但很有效果；把多个任务想象成多个人物实体，人要使用CPU来处理某种工作，就必须要竞争和释放，这种竞争是有规则的，这就又引出了调度的概念。OS Task的优先级还是源自OSEK OS，根据规范ISO 17356-3定义，数字越小优先级越低，比如0就是最低优先级；

使用startOS来同步两次所有核。第一次同步点：在startupHook前执行，第二次在OS-Application设置StartupHoos完成后，且在调度器开始调度之前。

相信大多数工程师接触AUTOSAR都是从CAN通信开始点点点，如上图所示，通信栈由通信服务层、通信硬件抽象层以及通信驱动层构成；具体而言，包括CAN、LIN、FlexRay、Eth的通信，如下图所示：可以看到，在上图的通信链路出现了I-PDU、N-PDU、L-PDU等等，这些名词是什么意思呢？我们进一步进行分析。Com层位域AUTSOA BSW架构中的服务层，主要就是处理信号，为SWC提供信号级别(Signal)的通信数据服务接口，或者根据信号自定义发送类型来发送PDU。....

本节内容主要是对CAN通信栈、PduR做了介绍，把ComM如何与CanSM、NM、CanNM协调做了一个概述，下一节将详细介绍NM的状态机

我们主要了解了在ECU层级下的错误分级分类、错误上报机制。对故障处理，大家可能首先就想到了DEM和DET；对于API这类虽说也在用，但是还没有上升到故障这种想法；DLT就更不用说了，以前大家有打印log的习惯，但是没有一个统一的标准。

DEM，全称Diagnostic Event Manager，是我们做诊断开发时很关键的一个模块，这个模块在AUTOSAR中所处位置如下图：很明显，它既要服务SWC，还要与BSW保持关联，在错误处理这个环节起到一个承上启下的作用。处理来自SWC或者BSW上报的诊断事件(通常我们叫error)将诊断事件发生时的错误数据保存到NvM当有诊断事件发生时，根据用户定义通知FIM进行功能降级和DCM(UDS/OBD)交互，提供错误数据的访问。

通过前三篇文章，我们对诊断栈有了一个基础认识，但还远达不到做诊断栈开发的程度，还需要熟读标准，结合配置工具和代码进一步熟悉，如果有时间的话，手撸一遍DEM(实在不行就抄)会有新的理解。

以上，我们将诊断栈的基本概念讲述了一遍，让大家了解了诊断其实不止包含DEM和DCM，从软件开发阶段一直到售后市场，诊断无处不在。有了这些基本概念，再深入到代码和文档，诊断栈开发应该难不倒大家

其实从原理上理解起来不是很难，主要是搞清楚RAM Block几种类型，难点在于真正开发的时候搞懂NvM运行机制，例如立即存储和下电存储之间有没有区别？NvM memory request是用什么样的机制，在代码中每一层的mainfunction如何使用？在上电NvM_ReadAll速度太慢，影响启动时间该如何处理。我们在后面一章节会继续讲解。

在中，我们描述了服务层NvM的功能、使用场景，其实对于使用者来说，了解如何使用配置工具完成NvM Block的配置、关联好下层的驱动模块就已经足够了，但是这样当NvM出现问题后，不了解原理定位起来就很麻烦：例如MemIf、MemAcc这些层级结构，基础软件供应商对应这块驱动的客制化代码。因此接下来简述下这些模块的作用，让大家对这块有个大概思路。

在中，我们简单讲了EcuM的状态机，以及每个阶段的用途；那么今天我们继续把每个状态里要干的事情再继续细化。注意这里还是主要讲Flexible的启动顺序（更加灵活，可以直接转角控制权限给BswM），毕竟在4.0.3版本之后，EcuM_Fixed就用的比较少了。

这篇文章聊EcuM第二个大阶段-UP阶段。实际上在StartUp阶段完成后，EcuM就已经将控制权转交给BswM模块，从ECU角度来看，此时其实已经完成了上电动作，可以开始RUN了；至于要RUN哪些APP，需要由BswM来完成条件、规则等仲裁，满足规则、符合条件才会开始执行某些动作，例如监测到NM报文发出后APP报文才发出的动作，再例如座舱域里电压下降到某个阈值后ECU进入某种状态（关闭中控、停发报文等等），这里后面讲BswM时会详细谈。注意在这个阶段里，EcuM的状态始终为RUN。

在AUSOSAR文档里， 模式管理(Mode Management)的所有关联模块有：EcuM、WdgM、ComM和BswM。EcuM：控制AUTOSAR BSW模块、OS等的启动；WdgM：根据控制流状态和Alive状态喂狗；ComM：管理网络状态和资源BswM：负责模式处理、仲裁等这就有点奇怪，上述四个模块干着不同的事情，为什么会统一起来叫模式管理Cluster呢？那么究竟什么叫做模式管理(Mode Management)？我们一步一步来看。1.1 模式定义根据。

上面两句话来源于AUTOSAR文档，当然，我读完了之后也不知道它到底要讲什么。

经过上面宏观的分析，我们知道通过整车ECU的唤醒是多种多样的，因此抽象出一个模块来统一管理和协调不同总线(CAN、FlexRay等)，对于软件分层解耦是十分有必要的，因此NM模块出现了。在BSW层级结构如下红框：ComM：位于网管系统最顶层，为上层服务使用者封装了统一的通信服务接口，主要用于处理总线通信请求、管理通信模式；Generic NM Interface：提供通用NM接口，用于支持底层特定总线NM模块和ComM；

经过上面宏观的分析，我们知道通过整车ECU的唤醒是多种多样的，因此抽象出一个模块来统一管理和协调不同总线(CAN、FlexRay等)，对于软件分层解耦是十分有必要的，因此NM模块出现了。在BSW层级结构如下红框：ComM：位于网管系统最顶层，为上层服务使用者封装了统一的通信服务接口，主要用于处理总线通信请求、管理通信模式；Generic NM Interface：提供通用NM接口，用于支持底层特定总线NM模块和ComM；

今天正式开始AUTOSAR MCAL之旅。首先回顾一下AUTOSAR的分层，如下图：Microcontroller Abstraction Layer(MCAL)：红色部分，AUTOSAR BSW最下层，它可以直接访问µC和内部外设；ECU Abstraction Layer：绿色部分，负责提供统一的访问接口，实现对通信、内存或者I/O的访问，从而无需考虑这些资源由哪些外设或者设备提供；Complex Drivers：绿色部分，非AUTOSAR定义的特殊功能；

之前聊过存储栈，主要是针对NvM以及Fee的讨论，对于Memory Driver里面各模块基本没有介绍。但在我们在讨论功能安全的时候，RAM和Flash的测试是不可能绕开的话题；

经过上面简单的分析，我们把PC\PB等属性搞得七七八八了，不过基于AUTOSAR规范的配置项的PC\PB还比较容易设计，涉及到Vendor自定义的，特别是MCAL里面的，如何来定义PC\PB，这确实需要仔细考量。上面我所提到的通过配置字来更新车型，就是用的Selectable类型，这种方式简单好用，通过诊断工具即可实现，但是需要额外的Flash空间；这个较为简单，今天就不聊了。我举个例子，做过座舱的同学在做整车测试的时候最常刷的DID想必就是配置字了，这个配置字对应的就是同一车型的高中低配置。

橙色部分是在工程构建完成后下载到Flash中，版本稳定了基本就不会再更新了；很明显，AUTOSAR SWC使用变体来根据定义的条件在执行路径中启用或禁用AUTOSAR相关接口或者具体实现。假设现在相同平台出了柴油版本和汽油版本的车型，本质上将除了控制策略上不同，基础平台完全可以不变。上面讲的基本都是BSW这一层级的，其实针对SWC应用层级，我们同样可以使用变体来进行管理。讲解了PostBuild的分类，接下来主要讲一下Loadable的集成要点。这样的设计我想到了，SIMULINK当然也想到了。

1. Crypto Driver概述Crypto Driver处在加密栈中的最底层，负责抽象芯片硬件密码功能或者基于软件封装的密码功能等，层级结构如下图所示：在分析该Driver之前，有几个术语是需要掌握的：Crypto Driver：指定密码硬件\软件的驱动程序；Crypto Driver Object：一个Driver包含一个或者多个Crypto Driver Object(CDO)，CDO用于提供不同的Crypto Primitive(加密原语)；

在上一篇文章24. AUTOSAR MCAL分析(三)--Crypto Driver(1)-优快云博客讲解了CryptoDriver的基本概念，引入了CryptoDriver Object的内容，针对该内容，我们做出了详细的描述。接下来我们继续讲解不同软件供应商对CDO的实现差异，以及Key、job的同步异步的处理方式上文我们简介了CryptoDriver的几个关键概念，该驱动主要实现了同步和异步加密原语的通用接口，支持密钥存储、密钥配置和密钥管理等功能。

NVM模块的创建是为了从应用程序中抽象出非易失性存储器（如EEPROM或Flash）的使用。对NVM的所有访问都是基于block的。

E2E，全称叫做End To End。这个概念的提出是用于保护在ECU运行时与安全相关的数据交换不受通信链路中故障的影响

SecOC(Secure Onboard Communication)模块在PDU级别上建立高效且可行的敏感数据认证机制，用于验证汽车ECU之间基于PDU的通信的真实性和新鲜度

模式管理

搞汽车ECU基础软件开发，ECU的休眠和唤醒是必不能逃掉的一个大坑。从休眠的功耗要再到唤醒时的时间要求，这都好好搞上很久。要理解唤醒不仅要对EcuM模块比较熟悉，还要对目标板子所支持的休眠唤醒功能了如指掌。今天，我们就先来简单聊聊AUTOSAR标准里唤醒源(EcuM章节)。本质上，唤醒就是给ECU供电，那么具体来讲有哪些模块能过启动唤醒的作用呢？常见的，例如KL15硬线唤醒，通常是KL15输入到一个SBC的enable脚，SBC通过另外两个引脚将CAN Trcv、MCU给唤醒；

信号边沿检测唤醒中断的控制周期信号时间测量非周期信号的边沿时间检测边沿计数实际使用中，ICU driver主要用于PWM信号的解调、测量频率和占空比、产生普通中断和唤醒中断。我们今天主要聊产生唤醒中断。既然是driver，那么对应的芯片也必须要有相应的硬件支持。我们以座舱域控用的最多的MCU(RH850-F1KM)为例，来看看它具体是哪个模块支持ICU驱动。ICU driver自己本身不产生唤醒中断，实际上它更像是一个处理唤醒中断的模块。

在AUTOSAR EcuM SWS里对于Sleep阶段做出了一个宏观的流程设计，如下：今天主要聊AUTOSAR规定的sleep两种模式：Halt和Poll，以及这两种模式下，MCU到底是如何工作的。

在之前的工程中，一直用的是一路CAN；最近由于整车拓扑的变化，新增了一路子网CAN，且这路CAN不支持唤醒，但需要中转网络管理报文。在导入DBC之后，通过vector工具点点点，生成代码，下到板子上一看，出问题了。系统不休眠，且报文停发后电流始终在300mA左右。这到底是啥原因呢？

1.1 概述做过AUTOSAR bsw配置同学应该都有这种感觉，BswM属于较为抽象且灵活的模块，在最初配置时完全不知道从何下手。究其原因在于：1、对BswM功能没有整体认识；2、对BswM复杂的专业术语理解；那么今天就从名词解释开始入手BswM通过上一章节AUTOSAR专项 : 模式管理（1） -- EcuM对EcuM模块的介绍，我们知道在StartOS之后，EcuM就将控制权移交给BswM。1.2 BswM状态 BswM...

​ 在模式管理（2） -- BswM我们了解到，BswM_Init由EcuM_StartupTwo调用，这也意味着，在调用该函数之后，BswM此时的状态处于BSWM_INIT。但根据现象来看，INIT的状态是没法收发报文的​