Autosar

EcuM_CheckWakeup()这个接口放在Integration Code中，这部分属于Autosar的Callout函数，此函数实现由User定义

Autosar网络管理之前，需要检查唤醒源，并且确保其有效。对唤醒源的操作，一般需要经过Check、Set、Valid三个步骤。

AUTOSAR中有两种回调，一个是Callback，另一个是Callout。
1、Callback:
Callback函数，是AUTOSAR规范里定义好的接口，通常是用于较底层（如PduR）根据需求向上层（如Com）提供通知。例如在Dcm模块中，当PduR调用Dcm_StartOfRecetion()和Dcm_CopyRxData()函数将收到的诊断请求数据放置在Dcm模块的Buffer中，然后PDUR调用Dcm_TpTxConfirmation()函数通知Dcm模块接收到新的诊断请求，其中Dcm_TpTxConfirmation()就是callback函数
2、Callout:
Callout函数没有在AUTOSAR规范中定义，仅提供一个函数指针，通常用于OEM或Tirer1实现特殊的需求，例如在Com模块中，对IPDU进行处理时，提供ComIPDUCallout配置选项，用于设置一个callout函数对CAN或其他总线信号进行处理

---

Autosar中的三种编译方式
Autosar中定义了三种配置参数方法：
1、PreCompile 2、LinkTime 3、PostBuild
这三种方法是在编译的三个不同阶段对软件进行参数配置
Pre-Compile
在预编译阶段，我们知道C语言主要负责处理“宏”，对其进行替换或展开。通过预编译，我们可以对功能进行开关选择，减少软件的代码量。但缺点也是明显的，预编译阶段任何更改，我们都需要重新把软件编译一次
Pre-Compile配置通常在模块的*_Cfg.h、_Cfg.c中实现
Link-Time
在Link阶段就是把编译出来的.o文件，链接成一个整体。我们知道在软件中有许多的常量，宏定义中的常量或内部定义的“const常量”。

---

在startup task里面需要对EcuM two进行初始化，这里面需要对RTE对BswM初始化
SchM_Init();
BswM_Init();
最后会在启动os完后之前调一下StartupHook()。自此os启动完毕，然后就是多核同步，qpi retun
后面软件的运行就是被os接管调度。os接管中会有task的调度，中断的触发，其中中断分为一类和二类。一类中断不受os的控制。
在程序进入App的main函数之前，程序已经完成堆栈，PC指针寄存器，中断，Trap等初始化动作。

---

AUTOSAR的一般开发流程（单个ECU）
流程概况
客户输入
第一步 配置MCAL
第二步 将MCAL集成到Autosar工程
第三步 BSW所需的模块
第四步 DBC文件和CDD文件导入Autosar工程
第五步 协议栈配置
第六步 配置ECUC、OS，RTE
第七步 配置应用层SWC
第八步 连线+Mapping
第九步 集成
第十步 MBD开发
工具链：
工具链主流有Vector、ETAS、EB，这里以Vector和ETAS工具链为例说明。Vector Developer用于应用层架构设计，Vector Configurator 用于BSW+RTE配置;ETAS ISOLAR系列（RTA-RTE RTA-OS）全套开发融合；MCAL目前主要还是使用EB的 Tresos工具。好用度或自动化程度上，Vector>ETAS，价格反之。由于Vector系列占主流，因此以Vector工具链作主要说明，而关键点时也会提到ETAS。
客户的输入内容：
CAN矩阵（DBC文件），诊断表（CDD文件或ODX文件）以及客户需求表（SOR文件等）。ODX(Open Diagnostic Data Exchange)是一种开放式的诊断数据格式标准，用于描述与诊断相关的ECU数据。车辆，ECU和测试仪制造商可以使用ODX格式描述和交换诊断数据。 ODX被设计为用于数据交换的开放格式。CDD(Complex Device Driver or Complex Driver)是复杂设备驱动/复杂驱动的缩写。SOR是Specification Of Requirements 指顾客方针对供应商发出的产品规格要求，一般是一个项目启动后，在供应商招标时发给供应商，其中包含产品的价格、质量、数量等各方面比较详细的要求。
具体流程：
第一步 配置MCAL
根据HSI（软硬件接口），在EB Tresos中配置好MCAL，配置好后可以导出Arxml，方便下一步集成到Vector或ETAS工具。
第二步 将MCAL集成到Autosar工程
将MCAL集成到Autosar工程中，这一步的目的就是将OS依赖芯片相关的内容（计数器、时间等）集成进来，当然也包含一些其他的依赖MCAL的内容，如CAN驱动、EEprom/模拟EEprom、Spi、看门狗等，这些建议在EB工具下配置，自动化程度会好一些（不管是ETAS还是Vector兼容第三方工具都不是特别好）。
第三步 BSW所需的模块
将BSW所需的模块加入到Autosar工程，如BswM、EcuM、WdgM、NvM、Dem、Dcm、Com等所需的的模块加入都工程。
第四步 DBC文件和CDD文件导入Autosar工程
将DBC文件和CDD文件导入Autosar工程（这一步Vector和ETAS最新工具链都是支持的），这一步会将Com协议栈的大部分配置项和Dcm、Dem的大部分配置项生成，可是Vector和ETAS在这里都没有做到完美，很多配置项都需要手动调整。
第五步 协议栈配置
调整COM协议栈以及UDS协议栈配置项，配置NvM/MemIf/FEE/Fls、配置WdgM/WdgIf/Wdg、配置Xcp等。
第六步 配置ECUC、OS，RTE
配置ECUC、OS，RTE，ECUC主要涉及到分区，以及Core Hardware定义等，OS主要涉及Task、Counter、Application等配置，方便后续Mapping，这里说明一下ETAS中OS的管理用的另外一个工具RTA-OS，其一致性做的不够好。
第七步 配置应用层SWC
配置应用层SWC，当然这一步也可以在第一步开始的时候执行，主要配置应用层的组件、接口、函数等。
第八步 连线+Mapping
连线+Mapping，这里主要是将需要调度的Mapping到Task或中断（中断手动放入入口函数），还有就是PRPort口之间的连线（包括SWC与SWC，SWC与BSW组件）。
第九步 集成
至此，Autosar工程基本部署完成，后续只需将MCAL+BSW+RTE+ASW的代码集成到一起即可，说实话，这里的集成过程目前由于工具链的问题，效率自动化程度都不高，尤其是ETAS需要写很多脚本支持。当然，这里还有两个概念提及一下，IO抽象以及CDD，本质上他们就是SWC。
第十步 MBD开发
此外ASW配置完后，其实就是一个代码框架，或者就是这个ASW的架构信息，可以导出Arxml文件，供后续进行MBD开发。

---

OS Application其实就是一个边界或一个保护的功能，基于AUTOSAR开发的ECU内部可以包含功能安全相关与功能安全无关的SWC。ISO26262要求不同的ASIL等级的软件组件之间要避免相互干扰
AUTOSAR OS通过将OS-Application放置在独立的内存区域内，实现避免内存相关的干扰。这个机制叫做内存分区（memory partitioning）
把一系列的之前提到过的所有对象放到一个容器里面，然后默认只有在里面的元素可以相互访问，如果别的application中的元素要访问必须进行显式授权（IOC等），也就是需要通过配置进行关联，这个元素其实和通用操作系统里面的进程概念有些类似。

在AUTOSAR软件基本架构下，无论是单核操作系统还是多核操作系统，都与EcuM模块和BswM模块息息相关。因为这两类模块决定了OS启动，初始化，运行，关闭等状态及其过程。

ECU在上电前处于SHUTDOWN阶段，上电后便进入STARTUP阶段，主要包括StartPreOS与StartPostOS两个子阶段。
StartPreOS子阶段主要完成一些OS启动之前的一些准备工作，如初始化MCU,IO,Watchdog等模块；
StartPostOS子阶段则是启动OS之后的阶段，该阶段主要执行初始化BSW的调度器以及初始化BswM模块两个动作

ECU一般启动过程涉及到Boot，C_Init，EcuM，OS等模块，在这些模块的共同接力下保证BSW以及RTE成功初始化，进而使得整个SWC处于正常running过程。
ECU启动时，首先通过中断向量表运行引导程序boootloader，bootloader在满足一定条件下跳转至APP程序中的C_Init初并指向Main函数。
在Main函数中首先完成堆栈空间初始化，然后调用EcuM_init函数进入到后续的StartPreOS, StartOS阶段。
在开启OS初始化函数中调用EcuM_StartuopTwo进行第二启动阶段初始化，最后就是进入StartPostOS阶段，如完成BswM模块的初始化，进而将控制权转交给BswM模块。
StartPreOS阶段，执行的动作：
调用EcuM_AL_DriverInitZero()， Init Block 0 此函数初始化那些没有使用post-build的BSW模块，在这个函数当中，既可以是驱动的初始化，也可以包含任何需要OS启动之前进行的底层初始化代码
调用EcuM_AL_DriverInitOne Init Block1

---

汽车嵌入式AUTOSAR软件开发之OS
在进行软件架构设计时，需要考虑到时序的分类和排列
一般包含：
1、IdleTask_OsCore0
放置较为优先的系统运行时序
2、Init_Task
放置系统初始化配置时序
3、Appl_Init_Task
E2E和ASW的初始化
4、BSW_Sync_Task
BSW相关时序，如CAN DCM COM ECUM XCP
5、WdgM_MainFunction
看门狗相关功能时序
6、appl_Task
用来执行E2E时序，以及应用层时序
不同时序有不同的可运行时间，如5ms 50ms 10ms 也有不同优先级
如E2E相关的时序需要比ASW有更高的优先级。
***********************************************************************************EcuM模块管理ECU状态
对应ECU的状态管理，还需要和RTE模块（以及其SchM功能），和BswM模块一同工作，管理并控制状态的切换以及具体实现