SWS_CompilerAbstraction
Memory Class 概念
在CompilerAbstraction中实现的概念，又名memclass。在几乎所有的编译器抽象宏（VAR、CONST、FUNC、P2FUNC等）中引用到了memclass，理解是用于指定Symbol所处的内存空间；如code所处的内存、data所处的内存等。猜测是用于16位机的分段寻址，对于32位机废弃该概念。
在MemoryMapping中提到了该概念。出现在了'memClass Symbol'配置项中，在R21-11版本中该配置项的状态为废弃，可能也能侧面证实在32位机上memclass概念可以废弃。
Pointer Class 概念
在CompilerAbstraction中实现的概念，又名ptrclass。在与指针有关的编译器抽象宏（P2CONST、P2VAR、P2FUNC等）中引用到了ptrclass，理解是用于指定指针所指向的对象所处的内存空间；例如指针变量本身处于一个@near的RAM，而它指向的对象处于一个@far的RAM。同样地，猜测是用于16位机的分段寻址，对于32位机废弃该概念。
SWS_BswM
功能Feature
BswM位于AUTOSAR基础软件架构中的服务层，实现对BSW模块和SW-C的模式管理。
BswM主要提供功能为：模式仲裁、模式控制。通过把各个BSW模块和SW-C模块的模式请求和模式指示收集起来，按一定的模式规则进行计算，得到仲裁结果。模式控制是根据仲裁结果，调用不同的动作列表，在动作列表中调用各BSW模块和SW-C模块的函数或接口。
配置Configuration
BswMArbitration - 模式仲裁
ModeRequestPort：数量0..*的列表，每个Instance是一个可以用来Request或Indicate给BswM的接口。
这些接口是Port或C函数，取决于它是SW-C还是BSW模块。
每个Instance可以配置它的仲裁在何时执行，在模式请求时立即执行还是在Mainfunction中推迟执行。
每个Instance的种类由BswMModeRequestSource下的Container决定。种类定义后，和BswMModeRequestSource同级的BswMModeInitValue的种类也被定义。
ModeCondition ：数量0..*的列表，每个Instance是一个特定Port的特定模式。
每个Instance要选定参考到ModeRequestPort的一个Instance。
每个Instance的判断条件为EQUAL或NOT_EQUAL。
LogicalExpression：数量0..*的列表，每个Instance是一个简单的逻辑表达式。
每个Instance中有个列表，列表中的每个Item是一个条件，参考到ModeCondition。
每个Instance中的列表的这些逻辑条件可以是AND或OR的逻辑关系。
Rule：数量0..*的列表，每个Instance是仲裁规则。
每个Instance中指定了一个LogicalExpression。
每个Instance中最多指定两个ActionList，分别是TrueActionList和FalseActionList，不能指定Action。
BswMModeControl - 模式控制
Action：数量0..*的列表，每个Instance是一个Action。
这些Action可以被ActionList复用。
每个Instance的种类由该BswMAvailableActions下的Container决定。
每个Instance可以用于控制Bsw模块的模式或生成一个用户实现的CallOut。
ActionList：数量0..*的列表，每个Instance可以执行一系列的Action。
每个Instance可以控制执行模式，在判断结果变化时才执行的模式是TRIGGER，在每次判断后都执行的模式是CONDITION。
SwitchPort：数量0..*的列表，暂不清楚作用。
特征Spec
*BswM与Bsw模块交互，如EcuM和xxSM；不与用户交互，涉及到用户交互的场景，BswM会通过CallOut（由用户实现）函数让用户调用EcuM模块进行控制。
BswM的Rule并不是自动执行的，需要调用Api（可能是BswM_ArbitratePortMappingRules）来进行判断。
BswM_Init
初始化Rule的状态为配置的初始化状态，去除推迟执行标志位。
遍历所有Rule，如果是IMMEDIATE类型则直接运行Rule，否则推迟到Mainfunction再运行。
BswM_EcuM_CurrentWakeup
保存唤醒源的状态，由EcuM模块调用。
唤醒源状态保存在BswM模块内部，可以用于BswM条件（Condition）判断。
SWS_EcuM
功能Feature
引导系统初始化和Os启动
处理和检查唤醒源事件
配置Configuration
特征Spec
EcuM_Init，又名StartPreOs processing，是EcuM初始化的第一步
Call EcuM_AL_SetProgrammableInterrupts()，实现关闭可编程中断。
Call EcuM_AL_DriverInitZero()，实现驱动初始化，它在获取（EcuM模块的）PBCfg参数前被Call. 主要用于初始化一些公共基础模块，以及获取PB参数所需的模块驱动。
Call EcuM_AL_DriverInitOne()，实现驱动初始化，它在获取（EcuM模块的）PBCfg参数后被Call. 主要用于初始化一些具有多套配置，且不依赖操作系统的模块。
获取唤醒原因。如果是特殊设计，会Call EcuM_GetLastWakeupSource()；如果是普通设计，直接认为唤醒原因是RESET。
Call EcuM_ValidateWakeupSource，这个函数实际是在满足条件时通知ComM和BswM模块唤醒原因。
设置默认的Shutdown target，由配置界面决定。
Call Os_StartOs()，Os开始接管。
EcuM_StartupTwo，是EcuM初始化的第二步
Call SchM_Init()。
Call BswM_Init()，BswM在初始化时会进行Rule的决策。此处应当由一个BswM的Callout，为BswM_InitBlockIICallout()，用于启动任务等。后续应当由BswM的Action进行进一步的操作。
EcuM_Init()函数中对BswM的唤醒源通知没有成功（由于EcuM初始化阶段未到StartupTwo，猜测该判断是为了避免在BswM没被初始化就被调用），这里重新通知BswM模块唤醒原因。
注：BswM在收到通知后会进行一次决策
对于唤醒需要特别注意，EcuM在初始化阶段无法将唤醒源状态通知到BswM模块。因此CanSm等模块的初始化应当在EcuM初始化状态之后；EcuM初始化状态的离开由BswM模块的规则控制，需要注意InitBlockII的顺序。
EcuM_CheckWakeup（CallOut）
由Mcal唤醒事件调用，用户在此编写对<Ma>_CheckWakeup的调用。
任何唤醒事件都应该首先调用该接口，不论是否需要Validation。
EcuM_SetWakeupEvent（Callback）
是<Ma>_CheckWakeup调用的Callback，当调用<Ma>_CheckWakeup后，函数内判断唤醒源发生，则清除唤醒源标志位，并调用该Callback。
<Ma>_CheckWakeup应当由上层调用。
EcuM_StartWakeupSource（CallOut）
由EcuM_Mainfunction调用，在EcuM_CheckValidation前调用。
e.g. CAN中断产生唤醒事件后，调用EcuM_SetWakupEvent后，进入Validation流程。但此时CanIf和CanDrv仍然处于Sleep状态，不能接收报文。在该Validation过程中，需要临时启动Can控制器用于Validation（Nm报文）。
EcuM_StopWakeupSource（CallOut）
由EcuM_Mainfunction调用，在EcuM_CheckValidation后调用。
EcuM_CheckValidation（CallOut）
由EcuM_Mainfunction调用，用户在此编写对<Ma>_CheckValidation的调用。
EcuM_ValidateWakeupEvent（Callback）
<Ma>_CheckValidation调用的Callback，当调用<Ma>_CheckValidation后，函数内判断唤醒源有效，并调用该Callback完成验证。
<Ma>_CheckValidation应当由上层调用。可以在EcuM的Callout函数EcuM_CheckValidation中调用。
SWS_CanIf
功能Feature
Can报文的来源，抽象CanDrv模块为Pdu。
配置Configuration
一些名词缩写：
HTH：CAN HardwareTransmitHandle；
HRH：CAN HardwareReceiveHandle；
HOH：CAN HardwareObjectHandle，它包含了HTH和HRH。
Ecuc中的ID，可以用于贯穿整个数据链路。例如CanIf-PduR-Com（双向），CanIf-CanTp-PduR-Com（双向）。
RxPdu配置：一个RxPdu包含CanId，CanIdMask，Dlc，UpperLayer，Ecuc中ID等信息，还需要参考到一个CanIf模块定义的HRH。
一般一个RxPdu对应一个HRH。
TxPdu配置：一个RxPdu包含CanId，CanIdMask，Dlc，UpperLayer，Ecuc中ID等信息，还需要参考到一个CanIf模块定义的HTH。
一般多个TxPdu对应一个HTH。
特征Spec
SWS_CanTp
功能Feature
Can传输层，主要用于诊断报文的处理，这是由于诊断报文的不定长性，需要传输层处理流控信息等。
配置Configuration
CanTpChannel：定义一个通信通道。对于一个CAN接口，一般会有两种诊断寻址方式（物理寻址和功能寻址），那么这两种寻址方式可以对应到两个CanTpChannel。
对于物理寻址，可以理解为P2P通信，即诊断设备发出一个物理寻址指令后仅一个ECU会响应。响应所使用的CanId为响应Id。因此这个CanTpChannel的数据方向为单向，应当具有一个RxSdu。
对于功能寻址，可以理解为广播请求，即诊断设备发出一个功能寻址指令后多个ECU会响应。响应所使用的CanId与物理寻址所使用的响应Id相同。因此这个CanTpChannel的数据方向为双向，应当具有一个RxSdu和一个TxSdu。
特征Spec
SWS_CanNm
功能Feature
Can报文的来源，抽象CanDrv模块为Pdu。
配置Configuration
一些名词缩写：
HTH：CAN HardwareTransmitHandle；
HRH：CAN HardwareReceiveHandle；
HOH：CAN HardwareObjectHandle，它包含了HTH和HRH。
Ecuc中的ID，可以用于贯穿整个数据链路。例如CanIf-PduR-Com（双向），CanIf-CanTp-PduR-Com（双向）。
RxPdu配置：一个RxPdu包含CanId，CanIdMask，Dlc，UpperLayer，Ecuc中ID等信息，还需要参考到一个CanIf模块定义的HRH。
一般一个RxPdu对应一个HRH。
TxPdu配置：一个RxPdu包含CanId，CanIdMask，Dlc，UpperLayer，Ecuc中ID等信息，还需要参考到一个CanIf模块定义的HTH。
一般多个TxPdu对应一个HTH。
特征Spec
SWS_Dcm
功能Feature
诊断通信管理模块。
配置Configuration
一些名词缩写：
DSL：Diagnostic Session Layer，负责确认诊断数据流的请求与响应，确保诊断计时以及诊断状态的切换，与PduR和ComM模块交互；
DSD：Diagnostic Service Dispatcher，负责接收网络上的诊断请求并转发到对应的数据处理模块、接收处理模块的响应数据并将数据传递给DSL模块，由DSL模块发送到网路；
DSP：Diagnostic Service Processing，负责处理诊断服务请求。
Dcm的Dsd模块
配置服务ID（10，22，31等）的可用性，包括在哪种寻址方式可用，在哪种会话下可用，在哪种安全等级下可用
配置自服务ID的可用性，可配置项与服务ID类似
Dcm的Dsp模块
DspSessionConfig用来配置有哪些会话等级
DspSecurityConfig用来配置有哪些安全等级
DspDatasConfig用来配置DID的数据Buffer，包括类型、长度、大小端
DspDidInfosConfig用来配置DID的可用性，包括在哪种寻址方式可用，在哪种会话下可用，在哪种安全等级下可用
DspDidsConfig用来将DspDidInfosConfig和DspDatasConfig（DspDidInfo > DspData的包含关系）关联起来，因为一个Did中可能包含多个Data，并且配置了该DID的值
DspRoutinesConfig用来配置31服务可用的例程。
不同于DID的配置，31服务涉及到的信号也在此而不独立出来；每个自服务应当配置In和Out信号，如果没有则信号长度为0；
每个例程可能包含Start、Stop、ReadStatus自服务或者只有Start自服务，取决于厂商需求；
每个子服务可以配置一个CommonAuthorizationModeRule，用于配置哪种寻址方式可用，在哪种会话下可用，在哪种安全等级下可用
Dcm的Dsl模块
DslProtocol用于配置可用的ProtocolRow，可以配置类型（如CAN、ETH等）和一些时间参数
每个ProtocolRow中可以配置多个Connection，每个Connection可以配置多个Rx和Tx，参考到Ecuc中的Pdu编号和ComM中的通道。