汽车电子 - AUTOSAR

概念

https://zhuanlan.zhihu.com/p/542653053?utm_id=0

参考
https://blog.csdn.net/xyfx_fhw/article/details/94611533!!!

手写代码与AutoSAR

手写代码：开发效率低、开发周期长、代码维护难、可重用性差
AutoSAR：软件和硬件隔离，换硬件不用修改代码，通过配置AutoSAR来配置硬件；-> 缩短开发周期，提高开发效率；提高代码重用性，方便维护

AutoSAR (Automotive open system architecture)

汽车开放系统框架
将汽车电子控制单元（ECU）软件底层做了一个标准的封装，通过共用一套底层软件，并通过配置不同的参数，就能匹配不同的硬件，以及应用层软件（应用层功能开发+AutoSAR工程师开发底层）
AutoSAR就是一套写好的底层软件，实现了硬件驱动的封装（STM32库），并实现了操作系统的功能（用户只需要开发操作系统上层的软件应用）（基于安卓开发APP）

AutoSAR工作流程

https://blog.csdn.net/xyfx_fhw/article/details/100112279

基本概念

Task, OS, Event
https://blog.csdn.net/xiandang8023/article/details/129268998?spm=1001.2014.3001.5502 – 没看懂

在 AUTOSAR 中，SWC 是软件组件，包含了可执行的 Runnable；Port 是 SWC 之间交换数据的接口，用于连接不同的软件组件；Event 可以触发 Runnable 的执行，一般用于驱动任务的执行；Task 是实时操作系统中的最小执行单位，其中的任务可以包含多个 Runnable；OS Application 可以包含多个 Task 和 Event，提供操作系统级的服务和资源管理

AutoSAR架构

应用软件层：存放用户代码
RTE实时运行环境：提供应用层所需的资源（接口，数据，可调用函数），同时将应用层和底层隔离
BSW基础软件层：将硬件做封装，并实现操作系统的功能，（相当于操作系统，方便上层进行调度）
注意：操作系统和AutoSAR架构是两回事，Task是不是架构中的概念，而是操作系统中的概念，APP层没有Task这个概念？？？

RTE作为AUTOSAR虚拟功能总线（Virtual Function Bus，VFB）的接口的实现，为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含操作系统（OS）的基本软件组件

虚拟化https://www.bilibili.com/video/BV1b64y1a7wL/?spm_id_from=333.337.search-card.all.click&vd_source=7155082256127a432d5ed516a6423e20

APP层

下面的第二张图很关键

• SWC

多个SWC组成，每个SWC就是一个.c文件，APP层相当于文件夹，每个SWC的功能都是用来实现特定的算法
SWC之间的通讯是通过应用层外进行的 – 虚拟功能总线VFB

VFB是片内外通讯的结合体

• 片内：通过RTE通讯；即.c文件中使用全局变量进行通信 -> ECU内部SWC的通讯看成使用全局变量
• 片外：通过片外总线CAN/LIN通讯

SWC的信息通过RTE连接到其他SWC或者BSW上
ECU内部的SWC是通过RTE的管理来通讯的，而跨ECU的通讯就是通过外部总线CAN/LIN（但是也是通过RTE来进行管理的）（见下面第二个图）

可以把下面的当成SWC (Automic SWC)

• APP，可以通过SensorActuator与传感器或执行器交互
• SensorActuator，直接与ECU抽象层交互
• calibration(parameter SWC) 此SWC用于将其所在的ECU的calibration参数共享给外部设备，与APP SWC或Sensor /Acutorator SWC不同，此SWC没有任何内部行为
• NVM memory block，访问memory
• IO-hardware abstraction，
• CDD
• E2E
• Service SWC https://blog.csdn.net/qq_41908302/article/details/130905910

• runnable

SWC中的函数
runnable可以被触发：定时器触发、被操作调用触发、被接受数据触发等
Runnable是需要OS中的Task做载体：runnable是函数，定义在.c文件中，必须调用才起作用，那么就必须要有操作系统中的任务来执行这个函数（windows中的线程就是Task,runnable就运行在现成上）

• Ports与connector

port为每个SWC的（符合AutoSAR的）接口
connector：ports接口之间的连接线，也就是全局变量（不完全对吧，）
ports，可以是SWC-SWC；也可以是SWC通过RTE和BSW进行通讯

port 与 interface

port主要提供了符合AutoSAR规范的连接点的功能，而具体传递的是什么属性的信息，则由port interface进行细节的定义
interface可以理解为一个包含传递信息的静态结构，定义传递信息的细节，结构体

Send/Receiver 用来传递数据
C/S 用来执行操作的

S/R接口

用于传输数据
通过RTE传输数据，并通过RTE管理数据的传输，避免数据出现问题（同时调用同一数据）
一个接口可以包含多个数据，类似结构体
传输任意类型：int，float，array等

Rte_Read_<Port>_<Data>()
//这里的xx是指的传输的数据内容，比如DoorOpen就是：
SWC_DoorOpen = Rte_Read_Door_DoorOpen();
1
2
3

C/S接口

提供操作
server提供函数供client调用
可以是同步或异步

同步：直接调用，（函数直接插入上下文运行）
异步：需要等待，（相当于让函数再另一个线程中运行，运行完了再返回，原上下文依然运行）

一个接口可以提供多个操作，就是一个接口可以包含多个函数
ECU内部和跨ECU都可以调用，跨ECU也是通过外部总线

Rte_Call_<Port>_<Function>()
//这里的xx是指的调用的函数，比如调用State()就是：
Rte_Call_Door_State();
1
2
3

RTE层

相当于虚拟机（虚拟化技术https://www.bilibili.com/video/BV1b64y1a7wL/?spm_id_from=333.337.search-card.all.click&vd_source=7155082256127a432d5ed516a6423e20 ）
相当于电话转接员
SWC的信息通过RTE连接到其他SWC或者BSW上
RTE作为AUTOSAR虚拟功能总线（Virtual Function Bus，VFB）的接口的实现，为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含操作系统（OS）的基本软件组件
RTE层抽象了操作系统（OS），防止软件组件（SWCs）直接访问OS和基础软件层（BSW）。这意味着SWCs不会直接与操作系统交互，而是通过RTE来实现它们之间的通信和任务调度。此外，RTE还提供了对runnable的管理功能，如触发、唤醒等，并确保数据一致性

RTE可以提供 ECU内部 和 跨ECU的通信管理
提供对runnable的管理（触发、唤醒，runnable需要映射到Task上运行，而这个映射就是通过RTE具体实现的???）
RTE就是VFB的具体实现
RTE可以利用工具自动生成（vector）

下图很重要（结合上面的图查看）
（可以看出通过COM软件组件与BUS总线连接，I/O通过硬线连接）

RTE 与 Runnables

RTE给runnable提供触发事件，runnable是可以被触发的，就是通过RTE来实现这个触发和调用runnable
Runnable是一个接口，代表一个可以被执行的任务。在RTE层中，Runnables是通过事件触发来运行的。例如，当达到某个定时时间或其他条件满足时，相关的Runnable任务会被触发并执行
通过RTE给runnable提供所需的资源，这里的资源说的是，接口通讯ports，RTE将runnable需要的一些资源通过接口传输给runnable
RTE隔绝BSW和SWC，（OS和runnables被隔绝了，runnable的运行条件由RTE提供，不能由OS直接提供？？？）

• runnable触发条件（周期调用，属于定时器事件还是操作调用事件？？？）

初始化事：初始化自动触发（启动时触发）
定时器事件：给一个周期定时器，时间到了就触发（周期触发）
接收数据事件：receiver Port一旦接收数据，就触发（条件触发）
…
操作调用时间C/S：当调用到了该函数的时候就触发（事件触发）
…

周期触发：runnable按照一定的时间间隔周期性地执行。例如，一个车速采集功能的runnable可能每隔100毫秒触发一次，用于获取当前车辆速度并进行相关的处理。
事件触发：runnable在接收到特定的事件时触发执行。这些事件可以是来自其他软件组件、传感器、通信总线等的信号。例如，当收到车门开启的信号时，一个安全系统的runnable可能会触发执行，进行相关的处理或报警操作。
条件触发：runnable在满足特定的条件时触发执行。这些条件可以是系统状态、传感器数据、用户输入等的判断。例如，当发动机温度超过某个阈值时，一个故障诊断系统的runnable可能会触发执行，进行故障检测和诊断操作。
启动时触发：runnable在系统启动时触发执行，用于初始化系统或进行一些必要的预处理。例如，当车辆电源开启时，一个初始化功能的runnable可能会触发执行，进行系统各个模块的初始化设置

RTE / Runnable / OS ???

RTE层与OS的Task之间是通过调用OS提供的服务进行交互的。RTE层可以创建和管理runnable，并与OS的Task进行连接。RTE层通过OS提供的服务进行任务调度和资源管理，确保runnable的合理执行。

而runnable是实际执行车辆功能的最小单元，可以是一个函数、一个任务或者一个独立的线程。runnable通过RTE层调用OS提供的服务来进行任务调度和资源管理。OS的Task则负责为runnable提供执行的上下文，包括分配时间片、管理堆栈、调度权限等。

因此，RTE层充当了runnable与OS之间的中间层，它通过与OS进行交互**，将runnable的执行转化为OS的Task的调度和资源管理。这样就实现了runnable的有序执行，并确保了各个runnable的资源的有效利用和调度顺序的合理性**

RTE 与 Ports

https://blog.csdn.net/xiandang8023/article/details/126107444?spm=1001.2014.3001.5502 ??? 显示模式和隐式模式???

S/R
C/S
ECU内部通讯
跨ECU通讯（通过COM）
（AR-COM???）

对数据一致性管理？？？

AutoSAR接口：Rte_Read_xxx() 类似这种就是AutoSAR接口, Rte_Call()，可以跨ECU
标准接口（AutoSAR规定的C语言API）：Com_SendSignal()类似这种就是AutoSAR接口，（接口函数名是固定不变的，是AutoSAR规定好的，可以由上层调用，但是一般是使用工具配置生成的，做上层应用一般不关心具体实现）(一般是同一个ECU之间，如BSW之间，OS、COM、RTE之间)
标准AutoSAR接口：就是AutoSAR接口，但是是官网规定的不能修改

S/R接口

• 内部信号 S/R

// Bo_Vct_LuggageCtrlLogic.c
Rte_Read_If_Inner_AntiTheftSt_AntiTheft(&tempRead);

// Bo_Vct_LuggageCtrlLogic.h
#define Rte_Read_If_Inner_AntiTheftSt_AntiTheft Rte_Read_BO_VCt_LuggageCtrlLogic_If_Inner_AntiTheftSt_AntiTheft
Std_ReturnType Rte_Read_If_Inner_AntiTheftSt_AntiTheftSt(uint8* u);

--->

// Rte.c
STATIC VAR(uint8,RET_VAR_NOINIT) Rte_Buffer_If_Inner_AntiTheftSt_AntiTheft;

FUNC(Std_ReturnType,RTE_CODE) Rte_Read_BO_VCt_LuggageCtrlLogic_If_Inner_AntiTheftSt_AntiTheftSt(P2VAR(LuggageArea_IDT, AUTOMATIC, RTE_APPL_ATA) data)
{
	Std_ReturnType ret=RTE_E_OK;
	
	Rte_ReadHook_BO_VCt_LuggageCtrlLogic_If_Inner_AntiTheftSt_AntiTheftSt_Start(data);
	*data=Rte_Buffer_If_Inner_AntiTheftSt_AntiTheft;
	Rte_ReadHook_BO_VCt_LuggageCtrlLogic_If_Inner_AntiTheftSt_AntiTheftSt_Return(data);
	
	return ret;
}

--->

// Rte.c
FUNC(Std_ReturnType,RTE_CODE) Rte_Write_BO_VCt_AntiTheftLogic_If_Inner_AntiTheftSt_AntiTheftSt(VAR(uint8, AUTOMATIC) data)
{
	Std_ReturnType ret=RTE_E_OK;
	
	Rte_WriteHook_BO_VCt_AntiTheftLogic_If_Inner_AntiTheftSt_AntiTheftSt_Start(data);
	Rte_Buffer_If_Inner_AntiTheftSt_AntiTheft=data;
	Rte_WriteHook_BO_VCt_AntiTheftLogic_If_Inner_AntiTheftSt_AntiTheftSt_Return(data);
	
	return ret;
}

--->

// Rte_BO_Vct_AntiTheftLogic.h
#define Rte_Write_If_Inner_AntiTheftSt_AntiTheft Rte_Write_BO_VCt_AntiTheftLogic_If_Inner_AntiTheftSt_AntiTheft
Std_ReturnType Rte_Write_If_Inner_AntiTheftSt_AntiTheftSt(uint8 u);

// Rte_BO_Vct_AntiTheftLogic_new.c
(void) Rte_Write_If_Inner_AntiTheftSt_AntiTheft(BO_VCt_AntiTheftLogic_new_B.AntiTheftSt_j);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

• 外部信号 S/R
  

// Bo_Vct_LuggageCtrlLogic.c
Rte_Read_LuggageArea_LuggageArea(&tmpRead_4);

// Bo_Vct_luggageCtrlLogic.h
#define Rte_Read_LuggageArea_LuggageArea Rte_Read_Bo_Vct_LuggageCtrlLogic_LuggageArea_LuggageArea
Std_ReturnType Rte_Read_LuggageArea_LuggageArea(LuggageArea_IDT* u);

--->

// Rte.c
STATIC VAR(LuggageArea_IDT,RET_VAR_NOINIT) Rte_Buffer_LuggageArea_LuggareaArea;

FUNC(Std_ReturnType,RTE_CODE) Rte_Read_Bo_Vct_LuggageCtrlLogic_LuggageArea_LuggageArea(P2VAR(LuggageArea_IDT, AUTOMATIC, RTE_APPL_ATA) data)
{
	Std_ReturnType ret=RTE_E_OK;
	
	Rte_ReadHook_BO_VCt_LuggageCtrlLogic_LuggageArea_LugggageArea_Start(data);
	*data=Rte_Buffer_LuggageArea_LuggareaArea;
	Rte_ReadHook_BO_VCt_LuggageCtrlLogic_LuggageArea_LugggageArea_Return(data);
	
	return ret;
}

--->

// Rte.c
FUNC(Std_ReturnType,RTE_CODE) Rte_Write_COMIF_Receive_LuggageArea_LuggageArea(P2VAR(LuggageArea_IDT, AUTOMATIC) data)
{
	Std_ReturnType ret=RTE_E_OK;
	
	Rte_WriteHook_COMIF_Receive_LuggageArea_LugggageArea_Start(data);
	Rte_Buffer_LuggageArea_LuggareaArea=data;
	Rte_WriteHook_COMIF_Receive_LuggageArea_LugggageArea_Return(data);
	
	return ret;
}

--->
// Rte_COMIF_Receive.h
#define Rte_Write_LuggageArea_LuggageArea Rte_Write_COMIF_Receive_LuggageArea_LuggageArea

--->
// COMIF_Receive.c
Luggage_IDT Write_LuggageArea_LuggageArea;

Com_ReceiveSignal(Com_Cfg_Rx_CAN0_Comfort_PLG_1_LuggageArea,&Write_LuggageArea_LuggageArea);
Rte_Write_LuggageArea_LuggageArea(Write_LuggageArea_LuggageArea);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

C/S接口

可以有不同的调用方式，本质是函数调用关系
同步调用 Rte_Call
异步调用
同步调用和异步调用，是可以直接用工具配置的

异步调用：
循环检测：（直到返回为止，和同步一样，没有意义）
超时检测：定一个时间，事件到了就去读取，没有到的时候，就继续运行程序
事件触发：当服务函数运行结束，RTE可以触发原函数，告诉它被调函数运行完了，可以读取返回值了？？？

// BO_VCt_CrashLogic.c
(void) Rte_Wite_If_F1A3_Wirte_CrashCnt_If_F1A3_Wirte_CrashCnt(BO_VCt_CrashLogic_B.NVM_CrashCnt_Write);

// VBA 22 F1 A3 crash information read
FUNC(Std_ReturnType,RTE_CODE) Rte_Call_Dcm_DataServices_DspData_0xF1A3_0_ReadData(
VAR(Dcm_OpStatusType,AUTOMATIC) OpStatus,
VAR(DataTypeUint8_N_16,AUTOMATIC) Data, 
P2VAR(Dcm_NegativeResponseCodeType,AUTOMATIC,RTE_APPL_DATA) ErrorCode){
	uint8 i;
	
	E2ReadF1A3(&Data[0]);
	
	return E_OK;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Mode Switch Interface接口？？？

模式转换接口：主要用在和模式管理密切相关的模块，一般用于BswM和EcuM中，模式端口用于对ECU中的模式变化做出反应**？？？**

triggerinterface???

代码逻辑？？？

#if define(Rte_ReadHook_func1) && (RTE_VFB_TRACE==RTE_FALSE)
#undef Rte_ReadHook_func1
#endif
#if define(Rte_ReadHook_func1) 
#undef Rte_ReadHook_func1
extern void (Rte_ReadHook_func1(unsigned int *data));
#else
#define Rte_ReadHook_func1(data) ((void)0)
#endif

/*假设有一个项目使用了一种名为 Rte_ReadHook_func1 的读取钩子函数，用于读取某个设备的数据。该项目可能需要在不同的环境下运行，有时需要启用这个读取钩子函数，有时则可能需要禁用它。

例如，如果项目在仿真环境下运行（通过 RTE_VFB_TRACE 定义为 RTE_FALSE），那么需要禁用 Rte_ReadHook_func1。这是因为在仿真环境中，可能无法访问到实际的设备，所以不需要使用该钩子函数。在这种情况下，上面的代码块将会将 Rte_ReadHook_func1 的定义取消，并且将它重新定义为一个空操作，即 ((void)0)。

另一方面，如果项目在实际环境下运行，可能需要启用 Rte_ReadHook_func1，以实现与设备的数据交互。在这种情况下，上面的代码块会将 Rte_ReadHook_func1 的定义取消，并重新定义为一个函数原型 extern void (Rte_ReadHook_func1(unsigned int *data))。这允许在其他地方编写具体的函数实现，并在需要时使用 Rte_ReadHook_func1 调用该函数。

总的来说，上述代码结构可以根据环境的不同来动态地定义或取消定义一个宏，并实现不同的编译效果。通过使用宏的替换功能，可以根据具体需求和环境的不同，在编译时期对代码进行灵活的调整。*/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

COM 片外 软件组件

E2E/COM/COMIF

在汽车电子中，E2E（End-to-End）和COMIF（Communication Interface）是两个常见的术语。

E2E（End-to-End）：E2E 是一种用于保证系统或网络中数据传输完整性和一致性的机制。它确保从源到目标的数据在传输过程中不会丢失、被篡改、或者出现其他错误。在汽车电子中，E2E 通常用于保证车辆内各个电子控制单元（ECU）之间的数据传输的可靠性和安全性。

COMIF（Communication Interface）：COMIF 是指通信接口，它是不同模块之间进行通信的硬件或软件接口。在汽车电子中，COMIF 是各种电子控制单元之间进行数据交换和通信的桥梁。它可以是物理接口，比如 CAN（Controller Area Network）、LIN（Local Interconnect Network）等总线；也可以是软件接口，比如 Ethernet、FlexRay 等网络协议。COMIF 的设计和实现对于车辆内部各个系统和模块之间的数据传输和协同工作起到关键作用。

综上所述，E2E 是一种用于确保数据在系统中端到端传输过程中完整性和一致性的机制，而 COMIF 是指不同车辆模块之间进行数据交换和通信的接口。这两个概念都在汽车电子领域中起到重要的作用，以实现安全可靠的车辆控制和系统协同。

在 AUTOSAR（Automotive Open System Architecture）结构下，通信在软件层面是通过 COM（Communication）模块来实现的，而不是一定通过 COMIF。

COM 模块是 AUTOSAR 中用于处理车辆内部各个电子控制单元（ECU）之间的通信的软件组件。它提供了一组标准化的接口和协议，用于定义和管理 ECUs 之间的数据交换。COM 模块通过不同的通信协议（如 CAN、LIN、FlexRay、Ethernet等）来实现 ECUs 之间的通信。它负责与 COMIF 进行交互，在软件层面处理通信的细节。

COMIF（Communication Interface）是 AUTOSAR 架构中定义的接口，它是 COM 模块与底层物理通信介质之间的接口。 COMIF 定义了软件层与硬件层之间的通信规范，包括物理连接、通信协议、数据传输机制等。COM 模块通过 COMIF 与底层通信硬件（如 CAN 控制器、LIN 转换器等）进行交互，以实现 ECUs 之间的数据交换和通信。

总之，在 AUTOSAR 结构下，ECUs 之间的通信主要由 COM 模块负责管理，它在软件层面通过 COMIF 定义的接口与底层通信硬件进行交互。COM 模块通过不同的通信协议来实现 ECUs 之间的数据传输和通信。

BSW层

BSW就是将整个ECU分层封装起来，一直封装到OS（类似windows,对不同的CPU、GPU、主板等的设备上运行）

ECU芯片：CPU
ECU：主板
AutoSAR OS：windows

• MCAL 硬件抽象层

将芯片的寄存器操作封装成符合AutoSAR规定的库函数API （这套API不同厂商都支持，但是底层硬件如何实现就是芯片厂商的事了）（EB软件通过界面配置MCAL）
相当于stm32库，将芯片上的功能都封装成API函数，供上层调用，API函数是AutoSAR规定好的，使得针对不同的芯片，上层对该层的接口完全一致，通过配置完成，同一个操作可以兼容所有的芯片

• ECU抽象层

MCAL只封装了芯片，ECU抽象层封将硬件上的所有硬件都进行了封装，形成了更高层的API

• 服务层

更高层API，包括操作系统OS，OS将使用ECU抽象层的API，并对上层暴露出服务接口（如嵌入式实时操作系统RTOS）
将所有与硬件相关的功能都抽象成一个具体的应用服务

• 诊断
• 存储管理
• 看门狗管理
• 通信（CAN, LIN, 串口， I2C 统一抽象成COM通信），提供统一的总线通信结构、统一的网络管理服务、统一的诊断通信接口1
• 操作系统
• 调度管理
• ECU状态管理
• 通信通道管理

• CDD复杂驱动

主要将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能

I/O

I/O 包括了DIO(GPIO)、ADC、PWM
博客中的例子！！！https://blog.csdn.net/xyfx_fhw/article/details/98724308（结合接口图看！！！）
https://blog.csdn.net/xyfx_fhw/article/details/102879256(太重要了！！！)
ADC采集->主芯片->软件
MACL->IO抽象层（API读取MACL）-> sensor SWC（C/S接口读取）-> 其他APP SWC（S/R接口读取）

COM通信

https://blog.csdn.net/initiallizer/article/details/130040286
https://zhuanlan.zhihu.com/p/412097964 - 要看
http://www.uml.org.cn/car/2023112444.asp - 要看

COM：APP SWC只需要将他传输给COM即可，这些收发的数据用DBC或ARXML文件定义好了（COM可以理解为主要起信号接口和网关的作用）
COM硬件抽象，将微控制器、板上的所有通信进行了封装，将CAN/LIN/FlexRay等通信方式都进行了抽象定义

PDU

PDU可以理解为一种数据单元，包括L-PDU（Low Layer Protocol Data Unit），N-PDU（Network Layer Protocol Data Unit），I-PDU（Interaction Layer Protocol Data Unit）以及SDU（Service Data Unit）等多种形式
交互层PDU，一般而言对于应用信号类型的通信由xxxIf层与PduR直接交互，对于诊断大数据类型需要经过Tp层中转为N-PDU后再打包重组成I-PDU

I-PDU

I-PDU可以被看作是由多个信号组成的Message
Com模块获取应用层的信号（Signal），经一定处理封装为I-PDU（Interaction Layer Protocol Data Unit）发送到PduR模块。信号I-DPU可以包含一个或多个信号，可以理解为一个I-PDU为一帧CAN消息，信号就是dbc中定义的

N-PDU

N-PDU即网络层PDU，在TP层与If层之间传输，其组成：N_AI + N_PCI + N_Data
N_AI：address information
N_PCI：Protocol control information
N_Data: Data field
根据N_PCI类型的不同可分为单帧/首帧/连续帧/流控帧，https://blog.csdn.net/L_fengzifei/article/details/134625998

L-PDU

L-PDU即数据链路层PDU，由ID，数据长度及数据组成，在以CAN通信为例，在CAN Driver接收总线上传来的信号电平之后生成L-PDU，L-PDU传输至CANIf

PDUR

PDU Router是AUTOSAR核心模块之一，其功能类似于网络中的路由器，作用是对一系列的I-PDUs进行路由选择和转发。而I-PDU的封装和解封装过程则由I-PDU Multiplexer (IpduM)模块负责

存储通信

https://blog.csdn.net/qq_41908302/article/details/130311125

NVM：应用层访问非易失性数据的唯一接口，提供非易失性数据的管理服务，（统一按块编写？？？）
Memory硬件抽象，将片内、片外（板上）的内存资源进行了统一封装，提供了统一的访问机制

看门狗

诊断

假设故障存在E2或FLASH中
读取故障需要CAN通讯，因此需要COM模块与功能（通信功能）
诊断读取的操作，并不是直接由应用层下发的，而是通过DCM，而不是直接通过COM模块

DEM： 诊断事件管理，用来记录和存储诊断事件的，连接NVM管理模块，即将这些诊断事件记录到EEP或FLASH中
DCM：诊断通讯管理，实现诊断通信协议，UDS

其他

IDT / ADT / Base

ADT：Application Data types：达芬奇软件的图像界面上使用的类型，只存在于概念中，不会在代码中体现
IDT：对Base types 改了个名字，方便生成代码时阅读 typedef uint8 Std_ReturnType typedef unsigned char uint8_1 typedef uint8_1 LuggageArea_IDT
Base types： int floatdeng1
Uints： 数据的单位 km, h, g等
Compu Method: 计算方法，将读取采集到的值，转换成实际物理值的公式，显性、非线性、查找表，计算方法在代码中会生成#define
Data Contraints: 数据约束，对数据进行最大、最小值约束

Service interface ？？？ 到底是C/S中的接口，还是BSW中服务层对APPL的接口？？？

ADT是概念上的，一般在图形界面中使用ADT；IDT是代码中，ADT为了生成代码，需要和IDT映射才行，使用Type Mapping Sets

系统架构

https://blog.csdn.net/qq_41908302/article/details/129783218

BSW

- BSW
	- common：Bsw基本函数
	- os：操作系统
	- SYS
		- BswM：模式管理，模式仲裁、模式控制
		- ComM：通信管理系统服务模块，与CanSM,LinSM,Nm交互
		- EcuM：ECU状态管理，负责启动、关闭、唤醒
		
	- Diag
		- Dcm：诊断通信管理，送往DCM模块或swc
		- Dem：诊断事件管理模块
	
	- Mem
		- NvM：MemIf之上，读写数据都统一调用NvM模块，上电后...
		- MemIf：访问E2或flash模拟E2服务统一接口
	
	- COM
		- Com：管理总线信号和信号组的发送和接收，也有网关路由的作用
		- PduR：PDU路由器，通过PDU发送和接收数据
		- Nm：	网络管理
	
	- CAN
		- CanIf：CAN接口层，提供对CAN驱动程序的抽象（基于PDU）访问，用于控制CAN驱动程序(CAN)以及收发器驱动程序（CANTrcv）
		- CanNm：CAN网络管理，负责唤醒和休眠
		- CanTp：CAN传输模块，在Tx方向上分割数据，在Rx方向上收集数据并监视数据流
		- CanSM： CAN总线状态管理，总线特定的错误处理
		
	- LIN
		- LinIf：LIN接口层，提供对LIN硬件的抽象（基于PDU）访问，处理调度表，可作为从机或主机
		- LinNm：LIN网络管理
		- LinSM：LIN总线状态管理：休眠和唤醒
		- LinTp：在Tx方向上分割数据，在Rx方向上收集数据并监视数据流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

MCAL

MACL

base
EcuM
gpt
Mcl
platform
resource

- ADC：AD采集驱动程序
- Can driver：CAN控制器的驱动程序，驱动程序抽象了对CAN硬件的访问，以发送和接收消息以及在控制器状态休眠停止等
- Det：错误检测/追踪管理模块
- Dio：通用的输出输出端口的控制驱动程序
- Fee：flash模拟eep驱动程序
- Fls：flash驱动程序
- Icu：输出捕捉的驱动程序，可以配置采集边沿触发，pwm波采集等功能
- Lin driver：LIN硬件的驱动程序
- Mcu：mcu驱动程序，包括系统时钟配置，芯片工作模式配置，外设始终等mcu通用配置的驱动程序
- port：端口功能配置驱动程序，主要是将端口配置成哪些功能，如配置成Dio(普通io) spi, pwm
- pwm：pwm输出驱动程序
- rte：
- spi：spi驱动程序
- wdg：看门狗驱动程序
- wdgif：ECU抽象层的一部分
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

EXT

外部芯片的驱动程序

- CANtrcv CAN收发器驱动程序
- LINtrcv LIN收发器驱动程序
1
2