让学习成为一种习惯

UDS 0x14服务用于清除存储的故障诊断信息，清除的故障诊断信息可以是某一个特定的故障码，也可以是某个类别的故障诊断码,也可以是所有的故障诊断码。这里所说的某个类别的DTC，其实是DTC Group(比如动力总成，车身，底盘等)，DTC Group的区间范围一般由主机厂的需求确定并在Dem模块进行实现。DTC 状态信息；DTC 相关数据（包括冻结帧数据和扩展数据）；DTC 其他数据（时间，发生次数等）；该响应仅有：SID+0x40 = 0x54。

UDS 0x11服务被client用来请求ECU复位，ECU复位有多种方式，由0x11服务的子功能参数resetType来决定；0x11服务的肯定响应会在执行复位动作之前发出；ECU在复位成功之后，将直接进入默认会话。从ECU复位请求的积极响应消息之后的时间，直到复位成功完成，ISO 14229中没有定义ECU的行为。建议在此期间ECU不接受任何请求消息，也不发送任何响应消息。该服务使用的sub-function如下，并不包含bit7肯定响应抑制位。

UDS 0x10服务主要有以下功能：作为用来切换Server(即ECU)不同诊断会话的一种服务；不同的诊断会话则规定了Server在相应session可以开启的服务权限；在不同的诊断会话则应使用对应的数据链路层的时间参数（ P2ServerMax, P2*ServerMax）；会话状态切换结果会通过Rte，以便恢复通信；按照14229-1标准所述，如下图所示：由上图我们提到10服务会话类型，该会话类型（子服务）可以主要可以分为六种：会话类型取值（hex）解释默认会话0x01。

汽车电子控制器给汽车的发展带来了无限的可能，也即是软件定义汽车功能。汽车电子控制器里的软件越来越复杂，动不动就是几十万行的代码，不免会出现一些软件bug，当出现软件bug时，更新控制器里的软件就成为必需，对控制器开发过程中，刷新功能必不可少。此次就讲一下电子控制器里的刷新功能。根据不同阶段，刷新的种类也不同：1）初次刷新；2）Debug刷新；3）基于UDS刷新；4）OTA刷新；本次文章主要讲述前二种，后面几点再开专题进行讲述。

Reset类型的识别是用来判断上次的复位是Application Reset还是System Reset还是CPU0 Reset。基于复位的原因，启动软件会运行不同的分支逻辑。复位原因可以通过RSTSTAT和RSTCON寄存器来进行判断。SW，STMx，SMU，ESRx，CB3复位源只能产生Application Reset，其他所有的Reset是可以产生System Reset的，但是需要进行软件配置。

，初始化过程是CPU0完成的。用户可以根据不同的复位事件来选择不同的执行路径。用户启动程序是在Boot Firmware之后运行的程序（

在AURIX 2代，总共有4个Boot Mode Header(BMHDx, x=0-3)，他们都是定义在UCB里的，为了防止数据的损坏，每个Boot Mode Header都有其一个备份，即有原始的Boot Mode Header,，UCB_BMHDx_ORIG，也有其备份的UCB_BMHDx_COPY，为了保证正常启动，在UCB里至少有一个存在。对于第二个问题，从Security的角度来说，是不建议用HWCFG的方式来决定启动模式的，防止被暴力刷新；如果BMHD无效，可能会去检查其他的启动模式：。

作为一个，表面上犹如，但是很快这场竞争已经进入，很快就会角逐出一些少数胜利者，大家的方案也会趋向于胜利者的去设计。对于国家就是要扶持一个，从而由点及面的推动全社会产业的升级发展，目前来说上用到的技术比较先进，且汽车产业能拉动的产业也比较多，所以对于来说其就是一个重点扶持对象，其中复杂的更是难于攻克，我们需要才能顺应时代潮流，在一生有限的时间内作出一些成就，一段话分享给大家：一个要跟一个绑定，一个要跟一个绑定，一个要跟绑定。介绍了一些基础知识，本篇就来介绍下国内外的一些及。

ADAS 全称，又称高级驾驶辅助系统，主要依靠包括视觉摄像头、毫米波雷达、计算平台的组合来实现自动驾驶辅助功能。ADAS涉及到12门技术，主要基于三种传感器——摄像头，雷达，激光雷达。在这12门技术中，组合出了感知，控制，决策这自动驾驶三大模块。ADAS的历史最早可以追溯到1948年，机械工程师Ralph Teetor发明了第一款“定速巡航”系统。传感器是车辆感知系统收集环境信息、车辆自身状态信息和位置信息等的重要手段。自动驾驶车辆所配备的传感器可以分为三类：自感知传感器。

ETAS中的优先级数越大优先级越高。

不知道看到的对不对，欢迎一起留言讨论。

— 使用实验环境进行上传/下载标定数据，并观察和编辑标定数据1. 上传/下载标定数据和代码2. 添加测量变量3. 添加标定变量4. 配置测量变量5. 建立存储触发。

为了说明这些粗略数据，INCA必须需要一个描述性文件，用来描述如何把这些粗略数据组织到变量和代码中以及变量的类型，作为整数变量的4字节和作为浮点变量的4字节是有很大区别的。INCA还需要一个标定数据的初始化数据集，注意，这个数据集不是描述文件的一部分。在一个项目内可以有很多的标定数据集，每个数据集都代表着一个不同的标定阶段或者不同的标定概图。当安装第一个HEX文件时，该文件的代码部分被映射到控制单元的项目中，而数据部分被存储到一个主数据集中了，然后这个主数据集用来创建需要的工作数据集。

发动机的行为由ECU中的标定数据决定。在标定过程中，标定工程师通过修改标定数据来优化发动机的行为。2. 控制器使用查表表格来确定执行器设置所需的值来作为测量变量的函数。图9.2显示了INCA的功能模块图表， INCA与控制器连接，并直接访问它的存储器。7. 软件接口（ CAN总线或者ABUS上通信内容的描述，例如： CAN信息的ID及数据内容）5. 通信方法（与ECU建立通信的ASAP器件的参数。6. 硬件分配（ ECU中相关存储器模块的分段。4. 测量通道（用于测量的RAM单元的地址，分辨率和更新率）

客户需要更好的汽车性能政府的法规要求技术需求：- 可以实现更优良的的空燃比控制- 可以实现更精确的点火时间控制- 而机械器件已不能满足精度要求ECU内部的控制算法软件对于某个具体的受控发动机是固定的发动机控制策略与OBD策略包含了约7000至10000个自由参数 (单值参数，二维表格，和三维图表等）对于不同的发动机、不同的车型这些参数都需要进行调整优化，使得发动机和整车达到各种驾驶性能指标并符合国家排放法规发动机匹配标定是一个重复并且投入比较大。

ISOLAR-A (AUTOSAR- ASW集成解决方案)是一个开发AUTOSAR兼容嵌入式软件配置的IDE。在为汽车软件提供AUTOSAR规格的全部功能的同时，它隐藏了AUTOSAR数据格式的复杂性。设计软件组件(SWCs)和组件描述AUTOSAR系统和ECU实例配置生成RTE的系统用于博世内部的DGS适用于博世旗下所有其他UBK部门ISOLAR-A-用于博世外部ISOLAR-A原生支持AUTOSAR XML没有专有的数据库格式、文件类型与三方工具和流程轻松交换数据。

对Mcu的配置主要就是其时钟树的配置，但是EB将GTM、ERU等很多重要的模块也都放在了Mcu里面做配置，所以这里的Mcu是一个很庞大的模块， 我们目前只讲时钟树的部分。

考虑了一下，觉得还是有必要拿出一个代码来具体分析一下，所以我们以最简单的DIO来举例子。但是如果直接贴上源码，可能会有一些版权问题， 所以博主主要以outline的方式带领大家看看其代码的主要结构。具体的代码实现可能就没办法贴上来分析（当然，那么多代码也不可能全部分析）

3. 如果我们生成了代码，可以看到代码中的表述如下面的代码，这里的 DioConf_DioPort_DioPort_0 就是我们重命名之后的名字。双击DioConfig_0进入下面的界面中，我们先看到图中有一个DioPort_0和它的。利用Mask和Offset，我们就可以将一个port里的一部分pin脚组成一个组，我们通过控制组来控制所有组内的pin脚。DioPortId也是0，这里就相当于说我们将单片机中的第0号Port重命名为DioPort_0，方便代码中使用。

这样的话，然后会有一段 #ifdef 被激活，以此方式来使能这个已经写好的API函数（当然，实际情况可能会有很多地 方被激活了，以后我们专门写一篇来分析一下我们的配置项和代码生成之间的关系） 还要说明的一点是这里的Name，是指的是指包含下面配置项的容器名（其实可以看成结构体就行了），一般保持默认名称就比较好，以后的配置里 也差不多。具 体配置我们就不讲了，这些都是我们单片机常用的配置，一般我们是用代码配置，这里用了图形界面，其实都是一样的。这里和上面的安全也差不多，这里主要是一些API的使能。

本章开始，博主准备开始讲解一些大家比较关心的MCAL的问题，将会用大家比较熟悉的ADC、PORT等模块的配置，带领大家看看EB Tresos对Mcal的外设配置方法。博主用的是NXP的S32Kxxx系列作为讲解用的芯片。

本次实验其实新的内容就是导入cdd文件，其他的内容基本上都是以前讲解过的知识，由于大家手里的工程都不统一，所以也没有手把手讲解的必 要，就将流程全部列出来供大家参考。其实诊断的配置并不是很难，因为诊断协议的很多内容都在cdd文件已经定义了，导入cdd后，DaVinci会自动 解析这些内容，然后就自动配置好了大部分内容。所以我们要做的其实也就简单了。当然，在SWC里面还有很多应用层要执行的内容，也都比较复 杂，但就不太属于AutoSAR的范畴了。

应用层一般会通过 Dem_SetEventStatus() 来告诉Dem事件的状态，但是具体状态如何该如何处理要Dem做出处理其他的Bsw模块也可以通过 Dem_ReportErrorStatus() 来报告某些发生的故障为了实现故障的存储功能，Dem还要和Nvm相互联系，来将故障信息保存在NVM里面（NVM如何保存这些信息在上一章讲解过AutoSAR系列讲解（实践篇）11.1-BSW中的存储模块_ManGo CHEN的博客-CSDN博客。

Fim（Function Inhibition Manager，功能禁止管理），主要就是用来当故障或者事件发生的时候，禁止一些功能，防止更坏的情况产生。同样也是比 较简单的模块，对于诊断而言，最重要的应该是Dem模块，我们下节课再详细讲解。

Dcm（Diagnostic Communication manager，诊断通信管理）首先是相对于网络独立的一个模块，它已经不关心底层如何通信了（当然，通信是必不 可少的）。该模块主要就是用来解析和使用诊断服务，它为诊断服务提供了一套公共API函数。同时，它不光能处理我们之前讲到的UDS协议，还能 作用在OBD(ISO 15031-5)诊断协议上。其实之前我们讲解UDS的那些内容，基本上就是在DCM中实现的，比如管理诊断状态，检查诊断服务是否被ECU支持，根据SID去调用应用层服务等等。

CanTP说起来其实重要也不重要，其本身是设计可以用于CAN的很多传输协议，但是目前基本上也就咱们做诊断的时候用用，不过虽然简单，我们也 讲讲。假如现在我们的ECU有诊断的信息发送给诊断上位机，那么我们的诊断报文究竟经历什么，我们上图看看。

老规矩，先复习4.7节（AutoSAR系列讲解（入门篇）4.7-BSW的Diagnostics功能_ManGo CHEN的博客-CSDN博客Diagnostics就是我们常说的诊断，其中最为著名的就是UDS协议。

好，接下来开始我们的实验。本次实验主要就是将我们的里程数和开关门的次数保存到我们的NV里面，

我们在下一节的实验课中讲解这里的具体配置流程，本节主要讲一下这些配置的大致流程和配置项的作用。NvBlockSwComponents是一个可选项，我们这里开始不使用NvBlockSwComponents，将我们的Application SWC直接和NvM通过C/S连接起来使用。并且在模式管理章节中我们介绍了自下而上（Botton-Up，也称作自底向上）的服务映射方法，本节课讲解自上而下（Top-down，也称作自顶向下）的服务映射方法。

如果一个短数据需要被单独存储，那么对Flash而言，它需要先保存原数据，再擦除一个页再写入该页。对Flash而言，效率极低对于一个NV data来说，一般只能分配给一个SWC用，对于多个SWC的数据写入一个NV data中是很困难的不能防止并发访问的情况发生。

上一节讲了NVRAM Block的原理，本节课讲解其在DaVinci中的配置项，由于DaVinci版本等一些问题，大家的配置项可能有些差异，但是主要的功能都相同。配置项在这里面，这些都是一些NVRAM Block，没有的话大家也可以自己添加一个。

目录一、NVRAM BlockNVRAM Block的类型二、Fee Block三、Ea Block四、总结同通信的PDU一样，存储功能也需要一些特殊的数据结构来存放和管理我们的NV数据（NV data）NVRAM Block的作用类似于IPDU，但它们两仅仅只是作用上相似，其功能实现是完全不同的。首先用户是不可能直接操作NV Memory的，所以肯定需要开辟一块RAM区域用于暂存我们的NV data；然后我们的数据需要校验，那么肯定需要有一个空间来存放我们的校验是否正确等必须信息；假如校验出错，我们还需要

最后以一个图来总结一下今天的内容，今天仅仅只是模块的一些介绍，后面还会详细的讲解（NVRAM block后面单独讲解）

今天的内容很简单，但是却很重要，因为我们终于要讲到了。和模式管理的内容关系不大，但却是一个必不可少的步骤。因为BSW的服务层会提供很多，这些接口可以对应用层提供服务，但是不同于我们经常接触到的C/S接口，这些是在BSW中定义好的，因此只需要我们进行Service Mapping即可，其作用相当于将这些接口与应用层连接起来。

我们回头再看开头的那张图。这张图中有两种Mode Manager，一个是BswM，一个是我们的SWC。BswM可以通过定义其Rules和Action来进行模式切换的管理，而SWC就可以通过代码的形式自己手动管理，这两种方法都是符合AutoSAR规定的。

之前讲解了BswM和EcuM，详细讲解了BswM的配置，而大部分的配置都在BswM中做了，EcuM的配置就很简单了，基本上勾一勾就ok了。下面我们来讲解模式管理还可能用到的通信模块。

大家现在都知道了AutoSAR的应用层和底层是隔离开的了，但是一旦隔离开后，我们的BSW中的功能更岂不是都完全一致了吗？显然这是不合理的，每个不同的ECU要完成的功能都不太一样，所以我们的底层BSW需要根据我们的上层功能需求做出相应的实时调整，这个调整的动作我们称为Action；而什么时候调整、怎么触发这个调整的机制我们称为Rules。举个例子：我们有一个信号需要发送到别的ECU上，而这里有两路总线，CANBUS 1 和 CAN BUS2。

本次实验很简单，但实际上通信是很复杂的一套内容，在综合实验中将会教会大家导入dbc到解决其问题，大家会发现需要自己配置的地方其实很少，大部分都在dbc中定义好了。当我们导入dbc的时候，DaVinci就会自动帮我们配置那些dbc里面的内容（比如自动根据dbc中的msg配置IPDU）。说回本次实验内容，大家应该要理解的其实就一点，如何一层一层的将我们Runnable中的数据连接到另一个ECU。大家可以结合下图与刚刚的实验我们的数据是如何层层的传输到总线上，这些跨层级的传递是如何配置的。

本次实验很简单，但实际上通信是很复杂的一套内容，在综合实验中将会教会大家导入dbc到解决其问题，大家会发现需要自己配置的地方其实很少，大部分都在dbc中定义好了。当我们导入dbc的时候，DaVinci就会自动帮我们配置那些dbc里面的内容（比如自动根据dbc中的msg配置IPDU）。说回本次实验内容，大家应该要理解的其实就一点，如何一层一层的将我们Runnable中的数据连接到另一个ECU。大家可以结合下图与刚刚的实验我们的数据是如何层层的传输到总线上，这些跨层级的传递是如何配置的。

在Davinci Cfg中，数据是不能直接放在IPDU上的，必须要映射到相应的Signals上才行。Signals一般是由通信矩阵定义的，但是通信矩阵并不知道程序中究竟用的是哪个数据进行传输的，因此需要将我们在Dev中定义的数据（Data Elements）和Signal（Network Signals）相映射才可以正常使用。在ECU SW Composition这个层级中： 在Cfg和Dev中都可以配置DataMapping；