本篇我们介绍BSW中的ComM模块,它是一个资源管理器,封装了对底层通信服务的控制。ComM模块控制与通信相关的基本软件模块,而不是软件组件或可运行实体。ComM模块收集来自通信请求者(术语“用户”的定义)的总线通信访问请求,并协调总线通信访问请求。同样地,与ComM交互的模块也有很多,下图是ComM与其他模块的交互示意图。
ComM某块在BSW中的位置如下图所示,它被划分到属于系统服务。
这里重点介绍下ComM与EcuM、ComM、BswM、CanSM、NM等模块的交互。
EcuM负责wake-up的验证,如果验证是有效的唤醒事件,那么将验证结果发送到ComM。通信使能和shutdown ECU是由EcuM和BswM合作处理完成的。
BswM实现两种功能模式仲裁和模式控制,以允许应用模式管理和车辆模式管理的应用。如果在BswM的执行列表中配置,能够通过BswM请求ComM模式,BswM将用户请求传递到ComM模块。如果在执行列表中配置了Com_IpduGroupControl调用,则BswM可以控制AUTOSAR通信模块(COM)中的PDU Group。ComM向BswM提示所有通道主状态变化和所有PNC状态变化。如果使用EcuM-Flex,BswM将向ComM指示是否允许通信。
ComM模块使用NVRAM Manager去存储和读取数据。这里需要注意:NvM必须在ComM之前完成初始化,因为当ComM初始化时,即认为NvM已经初始化完成,处于可使用状态。
Can State Manager是ComM模块通信模式对应的CAN总线实际状态的控制者。ComM从CanSM请求通信模式,CanSM将切换总线状态匹配到所请求的通信模式。简而言之就是CanSM是实际执行控制网络通信状态的模块,ComM请求CanSM执行某种通信状态设置,CanSM将实际去执行,从而将总线状态设置为ComM所请求的状态。
ComM通过NM同步网络上的通信能力(同步通信开启和关闭)。此外PNCs的状态信息通过ComM和NM之间专门的APIs进行交互。
另外,ComM与CanSM的交互,在CanSM篇已经描述过。
ComM模块,为它的用户简化了资源管理,它的用户可能是一个runnable实体,一个SWC,BswM(如SW-C通过BswMing求)或Dcm(为了诊断需要通信)等。
ComM模块提供了三种通信模式:
ComM模块为用户提供了唤醒和保持“Paritial Network Cluster(PNC)” 的功能。PNC是逻辑上的一组ECUs,它们必须同时处于活动状态才能实现某些分布式功能。如果使用支持PNC的网关,PNC可以跨越整个网络(网络层次结构上不同拓扑级别上的不同总线)。如果没有PN功能,NM消息只能唤醒并保持唤醒整个总线。
ComM针对每个PNC都实现了状态机去代表该PNC的通信状态。ComM User用于请求和释放PNCs。系统信道节点上所有PNC的状态通过网络管理报文的PNC位向量内交换。
配置项ComMPncSupport勾选时,PNC功能才可用。在post-build阶段使用参数ComMPncEnabled使能或禁止PNC功能。ComM通过调用BswM_ComM_CurrentPncMode()通知BswM PNC状态机的每一次改变。ComM和NM之间使用PNC位向量(PNC Bit Vector)交换PNC状态信息,PNC位向量最长包括504bit。PNC位向量作为对uint8类型数组的引用通过专用的API提供给ComM。PNC位向量中的每一个bit都代表着某个PNC的状态,这些位称为PNC位。PNC位的计算需要用到 byteIndex和bitIndex,byteIndex和bitIndex计算方式如下所示:
byteIndex = ( ComMPncId / 8 ) -
bitIndex = (ComMPncId % 8 )
相应通道的PNC位向量的长度由网络管理模块配置定义。ComM通过回调函数ComM_Nm_UpdateEIRA(
ComM通过回调函数ComM_Nm_UpdateERA(
ComM模块应能在分配的ComM通道上分发特定PNC的状态(PNC状态机的结果)。因此,ComM应通过调用API Nm_UpdateIRA(
如果使能了PNC功能,那么在通道相关动作之前,所有PNC相关的改变应该被执行。每个PNC对应一个PNC状态机,它独立于ComMChannels的数量。ComM最多支持504个PNC状态机。PNC状态机由两个主状态组成:
PNC主状态COMM_PNC_FULL_COMMUNICATION由三个子状态组成:
每个状态改变,除了从PowerOff进入主状态COMM_PNC_NO_COMMUNICATION,都需要使用进入的PNC状态作为参数,调用API BswM_ComM_CurrentPncMode() ,进行通知。在ComM中PNC状态机切换的触发由调用ComM_RequestComMode()实现。该触发函数只可在ComM_MainFunction_
触发器“ComMUser”通过调用API ComM_RequestComMode()来表示关于ComMUser的通信请求的通知。在对于映射到一个或多个PNC的通道,在ComM_MainFunction_
COMM_PNC_NO_COMMUNICATION主状态是上电后默认的PNC状态。当PNC没被外部请求,也没被内部请求时,PNC的目标状态就是COMM_PNC_NO_COMMUNICATION。
当PNC在COMM_PNC_NO_COMMUNICATION状态:
当PNC处在主状态COMM_PNC_NO_COMMUNICATION时,ERAn中至少一个代表该PNC的PNC位变为1,那么满足以下条件时,该PNC将离开状态COMM_PNC_NO_COMMUNICATION,进入子状态COMM_PNC_REQUESTED:
上电后从PowerOff进入主状态COMM_PNC_NO_COMMUNICATION
当PNC在状态COMM_PNC_FULL_COMMUNICATION,PNC通过ComMChannelPerPnc引用的所有通道都要处于COMM_FULL_COMMUNICATION状态。
当从COMM_PNC_NO_COM或COMM_PNC_PREPARE_SLEEP进入COMM_PNC_REQUESTED状态时,这个PNC通过ComMChannelPerPnc至少引用一个ComMChannel,并且该PNC的ComMPncWakeupSleepRequestEnabled设置为TRUE,那么将使用参数COMM_PNC_REQUESTED_WITH_WAKEUP_REQUEST调用BswM_ComM_CurrentPNCMode,而不是使用参数COMM_PNC_REQUESTED调用BswM_ComM_CurrentPNCMode。
当进入子状态COMM_PNC_REQUESTED时,ComM模块将在IRA内对应该PNC的PNC位设置为1,并通过调用Nm_UpdateIRA(
每次从其他状态进入COMM_PNC_REQUESTED,ComM应为所PNC配置通过参数ComMChannelPerPnc引用,且ComMWakeupSleepRequestEnabled为FALSE的所有ComM Channels请求COMM_FULL_COMMUNICATION,而无论通道是否被请求过。
每次由COMM_PNC_NO_COM或COMM_PNC_PREPARE_SLEEP进入COMM_PNC_REQUESTED,ComM应为所PNC配置通过参数ComMChannelPerPnc引用,且ComMWakeupSleepRequestEnabled为TRUE的所有ComM Channels请求COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST,而无论通道是否被请求过。
当从状态COMM_PNC_READY_SLEEP进入状态COMM_PNC_REQUESTED,ComM应为所PNC配置通过参数ComMChannelPerPnc引用,且ComMWakeupSleepRequestEnabled为TRUE的所有ComM Channels请求COMM_FULL_COMMUNICATION REQUEST,而无论通道是否被请求过。
注意从COMM_PNC_READY_SLEEP进入不应导致网络唤醒,因为(处于COMM_PNC_READY_SLEEP的)PNC(就代表)已经被另一个ECU远程请求。
当进入PNC子状态COMM_PNC_REQUESTED且ComMPncGatewayEnabled设置为TRUE时,则
在ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE的所有引用的ComMChannels上,ComM应在IRA内设置该PNC位为‘1’,并通过调用Nm_UpdateIRA(
满足以下条件时,应该离开子状态COMM_PNC_REQUESTED,进入子状态COMM_PNC_READY_SLEEP :
满足以下条件时,应该离开子状态COMM_PNC_REQUESTED,进入子状态COMM_PNC_READY_SLEEP :
在子状态COMM_PNC_REQUESTED,当ComMPncGatewayEnabled设置为TRUE,且分配到PNC的ComMUser中至少有一个请求“Full Communication”,则ComM应在这些ComMChannel:
的IRA内将代表该PNC的PNC位设置为值‘1’,并调用 Nm_UpdateIRA(
的IRA内将代表该PNC的PNC位设置为值‘1’,并调用 Nm_UpdateIRA(
在子状态COMM_PNC_REQUESTED当ComMPncGatewayEnabled设置为TRUE,分配到该PNC的ComMUsers中至少有一个请求“Full Communication”,ComM应为该PNC通过ComMChannelPerTxOnlyPnc引用的ComMChannels请求COMM_FULL_COMMUNICATION。
在子状态COMM_PNC_REQUESTED,当ComMPncGatewayEnabled 设置为TRUE,如果:
则ComM应在这些ComMChannel:
的IRA中将代表该特定PNC的PNC位设置为值“0”,并通过调用 Nm_UpdateIRA(
在子状态COMM_PNC_REQUESTED,当ComMPncGatewayEnabled设置为TRUE,如果:
在子状态COMM_PNC_REQUESTED,当ComMPncGatewayEnabled 设置为TRUE,且分配到该PNC的所有ComMUsers都请求“No Communication”,ComM应为该PNC通过参数ComMChannelPerTxOnlyPnc引用的ComMChannels请求COMM_NO_COMMUNICATION。
当在子状态COMM_PNC_REQUESTED调用ComM_Nm_ForwardSynchronizedPncShutdown(
那么ComM应该执行以下操作:
- ComM将该PNC通过参数ComMChannelPerPnc引用的通道属性ComMPncGatewayType为 COMM_GATEWAY_TYPE_PASSIVE的所有ComMChannel的ERA中该PNC对应的PNC位设为0;
- 在通过参数ComMChannelPerPnc引用的通道属性ComMPncGatewayType为COMM_GATEWAY_TYPE_ACTIVE的通道上,ComM为每个通道使用当前的PNC Handle调用函数 Nm_RequestSynchronizedPncShutdown (
- 离开子状态COMM_PNC_REQUESTED,进入子状态COMM_PNC_READY_SLEEP。
注意:
* 每当中间PNC协调器(具有至少一个ComMChannel且ComMPncGatewayType设置为COMM_GATEWAY_TYPE_PASSIVE的PNC协调器)从顶层PNC协调器接收Nm帧作为PN关闭消息,ComM立即释放PNC,转发PN关闭消息的PNC位向量,并且请求分配到受影响PNC的所有参数ComMPncGatewayType为COMM_GATEWAY_TYPE_ACTIVE的ComMChannels,PNC同步关闭(请求发送一条PN关闭消息)。
* ComM确保尽快处理作为关闭消息的NM报文,以保证PNC同步关闭的延时最小。
* 如果本地user请求受影响的PNC,或通过ComMPncGatewayType属性为COMM_GATEWAY_TYPE_ACTIVE的ComM Channel接收到PNC请求,转发PNC同步关闭的行为都不会执行。无论是本地或者远程PNC请求都将否决PNC同步关闭请求。
* PNC同步关闭仅在PNC处在 COMM_PNC_REQUESTED状态才执行
若该PNC已经调用ComM_Nm_ForwardSynchronizedPncShutdown(
如果ComMSynchronizedPncShutdownEnabled设置为TRUE,且分配到该PNC的所有ComM Channels的参数ComMPncGatewayType设置都为COMM_GATEWAY_TYPE_ACTIVE,那么在如下条件下应调用Nm_RequestSynchronizedPncShutdown (
配置同步PNC关闭且ECU作为该PNC的顶层PNC协调器,每次释放PNC时,必须在受影响的
ComMChannels上发送PN关闭消息。因此,ComM为被分配到该PNC的每个ComMChannel调用
Nm_RequestSynchronizedPncShutdown,将关于释放PNC的检测的PNC位向量转发给NmIf。
NmIf将调用转发到受影响的< Bus>Nm。PN关闭消息在< Bus > Nm_Mainfunction中发送。
只要远程请求PNC(即分配给该PNC的ERAn中至少有一个PNC位等于“1”),并且配置开关
ComMPncGatewayEnabled设置为TRUE,则COMM_PNC_REQUESTED将是当前的PNC目标状态。
只要PNC被请求(即在EIRA内代表该PNC的PNC位等于“1”),并且没有分配给该PNC的ComMUser请求“Full Communication”,COMM_PNC_READY_SLEEP将是当前状态。
只要定时器 ComMPncPrepareSleepTimer在运行,ComMUser,EIRA或ERAn没有改变发生,COMM_PNC_PREPARE_SLEEP就是当前状态。
PNC网关功能用于跨越总线/通信信道边界的(逻辑)PNC,从一个总线/网络路由PNC请求到其他上(因此,对于存在的PNC网关,它需要连接到多个物理通道)。
为此,PNC网关配置包含了每个PNC的信息,PNC物理通道被要求到达PNC的所有成员(PNC-to-channel-mapping),如下图所示。
PNC网关从其多个活动通道收集PNC请求(其被称为主动的,因为如果需要的话,它主动地使它们保持清醒)并聚合它们。PNC网关将网络上的PNC状态的聚合发送到它的所有激活通道,从而使所有节点对全局PNC状态上,具有与网关一样的视角。
如果PNC网关不是网络层次结构中最顶层的PNC网关,PNC网关还会将所有下级节点的聚合PNC请求状态,加上其自己的内部请求状态,发送到其上级PNC协调器,该协调器通过所谓的“被动”通道连接。
上级PNC协调器将汇总下级协调器的PNC请求状态,因此顶层协调器将知道网络中所有活动的PNC请求,并将该信息发送给下级节点。
下级PNC协调器将在它们的被动信道上接收的PNC请求信息转发到它们的主动信道,以将顶层协调器的PNC请求状态的整体视图分发给逻辑层级中的所有叶节点,因此系统中的每个节点都在关于PNC请求状态的信息上保持一致。
PNC协调器决不能聚集和发送回其通过被动通道接收的信息,以免产生“幻像PNC请求”的无限镜像循环。
PNC到通道的映射由配置静态提供。此外,可选特性动态的PNC到通道映射可用于在运行时扩展PNC到通道的映射。
如果PNCs被分配到不同的ComMChannels,且这些ComMChannels不被PNC网关协调,那么网络拓扑和通信设计必须保证受影响ComMChannels能够及时地在同一时间被请求和释放。如果使用PNC,应用不关心ComMChannel状态,此外,对于这个用例,ComM也不会关心ComMChannel状态,因为这些ComMChannel的PNC协调没有执行。或者换句话说,如果PNC被请求(被动地),那么所有引用的ComMChannels也将被请求(被动地),因为应用程序期望分配给该PNC的所有ComMChannels驻留在COMM_FULL_COMMUNICATION中。下图所示为一个PNC网关(Node2)不带协调ComMChannels的例子。
系统通道上的主动PNC网关,应是系统通道上最后一个释放PNC的节点。如果一个PNC的PNC位在所有ERAn中都为零,则表明除了PNC网关之外,没有其他节点正在请求PNC。
被动的协调通道仅存在于当它们被连接到多个PNC网关的情形。如果ComM使能PNC网关功能(ComMPncGatewayEnabled设置为TRUE),映射到该PNC的ComM通道可设置为主动或被动模式(COMM_GATEWAY_TYPE_ACTIVE或COMM_GATEWAY_TYPE_PASSIVE)。如果一个ComM的通道映射到两个不同的PNC,那么只有一个网关主动协调这个通道,其他网关被动协调这个通道。这意味着,PNC网关总是至少映射到一个ComM的主动通道,并且可以映射到一个或多个ComM的被动通道。如果一个本地ComM user请求PNC或源自被动PNC网关的主动协调系统通道的ERA中至少一个PNC位不等于0,PNC网关请求PNC。
PN拓扑总是反应分层架构拓扑,顶层PNC协调器处于最高层,在子层是多个中间PNC协调器和PNC叶节点。下图为一个反映了结构分层的PN拓扑示例:
上图所示PNC-Coor1为顶层PNC协调器,PNC-Coor2为中间PNC协调器,Node1和Node2作为PNC页节点,处于PN拓扑的最底层。例如,若Node1请求PNC1,那么该PNC请求通过PN传播到顶层PNC协调器。顶层PNC协调器“接管”PNC请求,并确保PNC请求发布到整个PN中。因此,顶层协调器会将PNC请求在通道1(PNC-Coor1.Ch1)上“镜像反射”回去,并且将该PNC请求转发到通道2。如果Node1释放PNC1,并且网络上没有其他ECU请求PNC1,Node1将仍然从顶层PNC协调器接收请求PNC1的Nm报文。对PNC叶节点的释放不立即在PN拓扑上转发,从PNC叶节点到顶层PNC协调器。PNC的释放由每个PN拓扑层的PN reset定时器延时,如果顶层PNC协调器检测到某个PNC的PN reset定时器超时,网络上也没有其他ECU请求该PNC。顶层PNC协调器复位所释放的PNC的PN reset定时器,并且发送PNC关闭消息,以保证所有PN层,从顶层PNC协调器往下到PNC叶节点, PNC几乎同步地关闭。中间PNC协调器收到PNC关闭消息后立即反应,因此中间PNC协调器释放指示的PNC,复位PN reset定时器,并在所有分配到受影响的PNC的主动ComM通道上转发PN关闭的消息。因此,几乎同一时刻,从顶层PNC协调器到PNC叶节点的所有PN层上的已释放PNC的所有PNC状态机驻留在COMM_PNC_READY_SLEEP中,并且复位相应的PN reset定时器。这样保证几乎同步的PNC关闭,以避免在应用层的超时。
参考AUTOSAR_SWS_COMMManager.pdf 图17和图18分别描述了在PNC同步关闭时,顶层PNC协调器和中间PNC协调器的行为。
注意:
PN拓扑总是至少存在一个顶层PNC协调器。如果所有被分配到特定PNC的通信信道都将ComMPncGatewayType设置为GATEWAYE_TYPE_ACTIVE,则该特定的PNC为顶层PNC协调器。因此,针对不同的PNC,可能存在不同的顶层PNC协调器。但是针对同一个PNC,它仅支持有一个顶层PNC协调器。多顶层PNC协调器的PN拓扑,必须要保证严格的PNC区分。下图所示为一个多顶层PNC协调器的PN拓扑:
上图中,PNC-Coor1作为PNC1和PNC2的顶层协调器。PNC3-Coor3作为PNC3的顶层协调器。因此,如果同步PNC关闭使能,PNC-Coor1负责发起PNC1和PNC2的同步PNC关闭。PNC-Coor3负责发起PNC3的同步PNC关闭。
该功能使得可以在运行时更新PNC网关的PNC-to-channel-mapping。更新是通过所有参与的节点的request-response的学习过程完成的。当Nm PDUs请求Partial Network 学习,所有参与的节点将在相应通道上返回它们当前的PNC关系,然后PNC网关更新当前的PNC-to-channel-mapping。
如果PNC引用的通道中存在ComMChannelPerTxOnlyPnc属性的通道,那么动态PNC-to-channel-mapping功能不可用。
如果在一个通道上调用了函数ComM_Nm_PncLearningBitIndication,且该通道的ComMDynamicPncToChannelMappingEnabled设置为TRUE,或ComM在一个ComM通道上调用Nm_PnLearningRequest,ComM应该设置相应通道PNC学习阶段为激活状态。
如果ComMDynamicPncToChannelMappingEnabled设置为TRUE,函数ComM_Nm_RepeatMessageLeftIndication被调用后,ComM应设置相应通道PNC学习阶段为非激活状态。
如果ComMPncGatewayEnabled设置为TRUE,为一个通道调用函数ComM_Nm_PncLearningBitIndication后,应执行以下任一动作:
PNC网关需要在运行时可以更新它的PNC-to-channel-mapping。如果ComMPncGatewayEnabled设置是TRUE,在 ComMDynamicPncToChannelMappingEnabled设置为TRUE的通道上,PNC学习激活且ERA中PNC位设置为1。ComM应在相应通道上为所有ComMPnc设置PNC-to-channel Mapping为1,相应的在ERA中相应的PNC位也设置为1。
在PNC学习阶段,每个参与的节点都必须发送当前的PNC成员。PNC网关还需要额外转发从其他通道接受到的PNC成员信息。
如果ComMPncGatewayEnabled设置为FALSE,且PNC学习阶段激活,ComM应在带有当前PNC成员信息的IRA中设置相应的PNC位,并为ComMDynamicPncToChannelMappingEnabled设置为TRUE的所有ComM通道调用Nm_UpdateIRA(, )。
如果ComMPncGatewayEnabled设置为TRUE,当PNC学习激活,ComM应为所有ComMDynamicPncToChannelMappingEnabled设置为TRUE的ComM通道调用函数Nm_UpdateIRA(, ),使用带当前PNC成员信息的IRA集合,并且组合了需要被转发的PNC信息。
如果PNC功能打开,所有PNC动作应该在通道相关动作执行前执行。如果参数ComMPncNmRequest设置为TRUE,当由于PNC状态机进入COMM_PNC_REQUESTED请求“FULL Communication”时,应该调用API NM_NetworkRequest(),即使当前状态已经处于“Full Communication”。
ComM状态机包含三个主状态,对应通信模式:
一个ComM通道可以引用其他ComM通道,引用关系由ComMManageReference设置。ComMManageReference的源ComM通道称为“管理通道”,目标ComM通道称为“被管理通道”。管理通道可以引用0-n个被管理通道,被管理通道只能被一个管理通道引用。一个应用的场景是:管理通道处理与NM的交互,被管理通道不带NM功能。但需要注意以下几点:
在进入COMM_NO_COMMUNICATION时,ComM通道状态机应该进入子状态COMM_NO_COM_NO_PENDING_REQUEST。初始化后进入COMM_NO_COMMUNICATION时,ComM不通知(通过RTE或BswM,此时RTE其实也是没有完成初始化)用户状态改变。在进入COMM_NO_COMMUNICATION状态时,该ComM通道状态机会关闭该通道的报文接收和发送能力,通过请求。在参数配置ComMNmVariant=FULL的通道上,进入COMM_NO_COMMUNICATION时,ComM还需要调用Nm_NetworkRelease()请求释放网络。
注意:如果该通道曾经请求过NM(通过Nm_NetworkRequest or Nm_PassiveStartup),并且此时还未释放,那么就需要调用Nm_NetworkRelease()释放网络。
在子状态COMM_NO_COM_NO_PENDING_REQUEST,用户请求COMM_FULL_COMMUNICATION,且不存在通信限制。ComM通道状态机应该立即进入子状态COMM_NO_COM_REQUEST_PENDING。
在子状态COMM_NO_COM_NO_PENDING_REQUEST中,参数ComM通道参数ComMNmVariant=FULL|LIGHT|NONE,DCM指示ComM_DCM_ActiveDiagnostic,ComM通道状态机应该立即进入子状态COMM_NO_COM_REQUEST_PENDING。
在激活的诊断会话期间,潜在的通信限制应暂时处于非激活状态。
诊断激活时,假设诊断测试仪保持总线唤醒,因此管理的通道不需要特殊处理。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST中,调用了函数ComM_EcuM_WakeUpIndication,而且参数ComMSynchronousWakeUp设置为FALSE,ComM应立即将所请求通道的状态机切换到COMM_NO_COM_REQUEST_PENDING。如果请求的通道是被管理通道,那么管理通道的状态机也应切换到COMM_NO_COM_REQUEST_PENDING状态。
在子状态COMM_NO_COM_NO_PENDING_REQUEST,NM模块通过函数ComM_Nm_RestartIndication()指示重启,ComM通道状态机应立即切换到状态COMM_NO_COM_REQUEST_PENDING。
进入状态COMM_FULL_COMMUNICATION后,ComM通道状态机立即切换到子状态COMM_FULL_COM_NETWORK_REQUESTED。如果没有User请求COMM_FULL_COMMUNICATION,进入子状态COMM_FULL_COM_READY_SLEEP。ComM模块ComMTMinFullComModeDuration定时器可以阻止在可能的用户请求发生前的系统初始化/启动时间段内,状态机在COMM_NO_COMMUNICATION和COMM_FULL_COMMUNICATION之间反复横跳。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST 中调用了ComM_EcuM_WakeUpIndication,参数ComMSynchronousWakeUp设置为TRUE,ComM应将所有ComM通道状态机切换到子状态COMM_NO_COM_REQUEST_PENDING。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST 中调用了ComM_EcuM_PNCWakeUpIndication(),参数ComMSynchronousWakeUp设置为FALSE,且ComMPncSupport设置为TRUE,ComM应将被该PNC所引用的ComM通道状态机切换到子状态COMM_NO_COM_REQUEST_PENDING。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST 中调用了ComM_EcuM_PNCWakeUpIndication(),参数ComMSynchronousWakeUp设置为TRUE,且ComMPncSupport设置为TRUE,ComM应将所有ComM通道状态机切换到子状态COMM_NO_COM_REQUEST_PENDING。
在子状态COMM_NO_COM_REQUEST_PENDING,ComM通道状态机评估其相应的CommunicationAllowedflag,如果为TRUE,ComM通道状态机立即进入状态
COMM_FULL_COMMUNICATION。
在子状态COMM_NO_COM_REQUEST_PENDING,且不再有任何有效的COMM_FULL_COMMUNICATION请求挂起,ComM状态机应切换回到子状态COMM_NO_COM_NO_PENDING_REQUEST。该场景的应用,如:由用户调用ComM_RequestComMode(,COMM_FULL_COMMUNICATION)或DCM通过ComM_DCM_ActiveDiagnostic()指示触发的请求进入COMM_NO_COM_REQUEST_PENDING,但现在通过ComM_RequestComMode(,COMM_NO_COMMUNICATION)或ComM_DCM_InactiveDiagnostic()取消了。
在进入状态COMM_SILENT_COMMUNICATION,ComM通道状态机应关闭总线报文发送能力(保留接收能力)。这是通过ComM模块通过CanSM请求相应的通信模式实现(SM_RequestComMode(network:=
在状态COMM_SILENT_COMMUNICATION,用户请求COMM_FULL_COMMUNICATION,且无通信限制时,ComM通道状态机应切换进入COMM_FULL_COMMUNICATION状态。
在状态COMM_SILENT_COMMUNICATION,配置参数ComMNmVariant=FULL|LIGHT|NONE,DCM指示ComM_DCM_ActiveDiagnostic,ComM通道状态机应切换进入COMM_FULL_COMMUNICATION状态。
当诊断激活会话时,潜在的通信限制应该被临时关闭。
在状态COMM_SILENT_COMMUNICATION,网络管理模块指示ComM_Nm_BusSleepMode(),ComM通道状态机应切花进入COMM_NO_COMMUNICATION状态。
在状态COMM_SILENT_COMMUNICATION,网络管理模块指示ComM_Nm_NetworkMode(),ComM通道状态机应切换进入COMM_FULL_COMMUNICATION状态的子状态COMM_FULL_COM_READY_SLEEP。
在进入COMM_FULL_COMMUNICATION时,没有指定子状态时,ComM通道状态机应进入其子状态COMM_FULL_COM_NETWORK_REQUESTED。
进入COMM_FULL_COMMUNICATION,ComM通道状态机打开报文接收和发送能力,其实现是ComM模块通过CanSM请求相应的通信模式:
从COMM_NO_COM_REQUEST_PENDING进入COMM_FULL_COM_NETWORK_REQUESTED,并且EcuM模块通过ComM_EcuM_WakeUpIndication()或ComM_EcuM_PNCWakeUpIndication() 指示唤醒,ComM模块应从NM模块请求Nm_PassiveStartup()。
如果指示的ComM通道是被管理通道,那么ComM模块应从NM模块请求Nm_PassiveStartup()。
进入COMM_FULL_COM_NETWORK_REQUESTED,且Nm模块已通过ComM_Nm_RestartIndication()指示重启,ComM模块应从网络管理请求Nm_PassiveStartup()。
进入COMM_FULL_COM_NETWORK_REQUESTED,且Nm模块已通过ComM_Nm_NetworkStartIndication()指示启动,ComM模块应从网络管理请求Nm_PassiveStartup()。
从其他状态或子状态进入COMM_FULL_COM_NETWORK_REQUESTED,若配置参数ComMNmVariant=FULL且一个用户已请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION),ComM模块应从网络管理为相应NM通道请求Nm_NetworkRequest()。
进入COMM_FULL_COM_NETWORK_REQUESTED,若配置参数ComMNmVariant=FULL且DCM已经指示ComM_DCM_ActiveDiagnostic(),ComM模块应从网络管理为相应NM通道请求Nm_NetworkRequest()。
在子状态COMM_FULL_COM_NETWORK_REQUESTED,且配置参数ComMNmVariant=LIGHT|NONE,当ComMTMinFullComModeDuration的定时器超时,且此时没有用户请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION),DCM也没指示 ComM_DCM_ActiveDiagnostic(),那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED,且配置参数ComMNmVariant=FULL,此时没有用户请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION),DCM也没指示 ComM_DCM_ActiveDiagnostic(),那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED,且配置参数ComMNmVariant= SLAVE_ACTIVE,没用户请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION),那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED,且配置参数ComMNmVariant= PASSIVE | SLAVE_PASSIVE,那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED,且DCM也没指示 ComM_DCM_ActiveDiagnostic(),且请求了通信限制,那么ComM通道状态机应立即切换到子状态COMM_FULL_COM_READY_SLEEP,并取消ComMTMinFullComModeDuration的定时器。
在进入子状态COMM_FULL_COM_READY_SLEEP,且配置参数ComMNmVariant=FULL时,ComM模块应从网络管理为相应的NM通道请求Nm_NetworkRelease()。
在进入子状态COMM_FULL_COM_READY_SLEEP,且配置参数ComMNmVariant=LIGHT时,应启动ComMNmLightTimeout定时器。
在子状态COMM_FULL_COM_READY_SLEEP,且配置参数ComMNmVariant=LIGHT,该通道没有pnc关系(ComMPncSupport设置为FALSE或该ComMChannel没被PNC引用),且ComMNmLightTimeout定时器超时,ComM通道寄存器应切换到状态COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP,且配置参数ComMNmVariant=LIGHT,该ComMChannel被一个PNC引用,且ComMNmLightTimeout定时器超时,当所有引用的PNCs进入到COMM_NO_COMMUNICATION时,ComM通道也切换到COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP,配置参数ComMNmVariant=LIGHT,这个ComMChannel扮演角色为被管理通道,而且被一个管理通道引用,但是没被任何PNC引用,当定时器ComMNmLightTimeout超时,只要引用它的ComMChannel转换到COMM_PNC_NO_COMMUNICATION状态,那么这个通道的ComM状态应切换到状态COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP,配置参数ComMBusType=COMM_BUS_TYPE_INTERNAL,ComM通道状态应立即切换到COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP,用户请求COMM_FULL_COMMUNICATION,当不存在通信限制时,ComM通道状态机应立即切换到子状态COMM_FULL_COM_NETWORK_REQUESTED。
在子状态COMM_FULL_COM_READY_SLEEP,配置参数ComMNmVariant=FULL|LIGHT|NONE,DCM指示ComM_DCM_ActiveDiagnostic,ComM通道状态机应切换到子状态COMM_FULL_COM_NETWORK_REQUESTED。
(诊断激活时通信限制会被暂时关闭)
在存在多个Channel的系统上,每个ComMUser可以被分配到一个或多个channel上,通过参数ComMUserPerChannel;
在存在多个PNC的系统上,ComMUser可以分配到一个或多个PNC,通过参数ComMUserPerPnc;
一个或多个PNC可以映射到一个或多个ComMChannel,通过参数ComMChannelPerPnc或ComMChannelPerTxOnlyPnc,其中ComMChannel的ComMNmVariants必须时FULL或LIGHT(LIGHT是被管理通道的属性,当被管理通道被关联到某个PNC时,其相应的管理通道(FULL)也要被关联到该PNC)。
被PNC引用的ComMChannel,禁止再被该PNC的ComMUser直接引用。
ComMChannel的ComMNmVariant= SLAVE_PASSIVE时,该通道不允许被任何ComMUser或PNC引用。ComMNmVariant= SLAVE_PASSIVE的通道应总是跟随其master的通信请求,不允许请求其master唤醒通信通道。
这里描述的扩展功能是根据项目具体情况,在运行时实施的特有的配置(如:使能唤醒抑制,但不强制No Communication)。在运行时,为了应对不断变换的条件,需要唤醒抑制/通信限制策略。如通过诊断改变唤醒抑制。
在ComM中,总线唤醒抑制是指ComM模块应采取预防措施,防止通过通信唤醒其他ECUs。唤醒抑制的实施其实就是忽略用户请求,忽略用户请求,意思就是会接收请求,但是不执行请求。当模式抑制接触后,“最高者赢”的策略会立即生效。
当通道的ComM抑制状态为ComMNoWakeup,用户的COMM_FULL_COMMUNICATION通信请求将会被抑制,而通道的状态将是COMM_NO_COMMUNICATION 或 COMM_SILENT_COMMUNICATION。
注意当通道已经处于Active状态时,设置通道的抑制状态,则不会激活(执行)通道抑制。ComM模块永远不能抑制“passive wake-up”的能力。必须保持总能对EcuM指示的总线唤醒的响应。在COMM_NO_COMMUNICATION模式,报文接收能力被关闭,但是是具备唤醒能力的。
ComMNoWakeup状态存储在非易失性内存,在启动时,在通信激活之前访问该储存的ComMNoWakeup状态决定通信抑制是否激活。
若当前状态为COMM_FULL_COM_NETWORK_REQUESTED,且已经请求过模式限制到COMM_NO_COMMUNICATION。ComM模块应该切换到COMM_FULL_COM_READY_SLEEP,发起shutdown,而不管是否有用户请求COMM_FULL_COMMUNICATION。
强制进入COMM_NO_COMMUNICATION模式,需要关闭掉保持总线唤醒的软件组件。限制到COMM_NO_COMMUNICATION只有在通道被主动请求时才执行,在这种情况下,当前所有当前用户的Full Communication请求,甚至于新的请求,都将被忽略。但当ComM由于被动唤醒被远程保持唤醒,则限制到COMM_NO_COMMUNICATION的请求不会执行。
当调用函数ComM_LimitChannelToNoComMode(),ComM模块应为相应通道更新抑制状态(限制到COMM_NO_COMMUNICATION)。
每次请求限制到COMM_NO_COMMUNICATION,抑制状态的更新都必须进行,而不管当前状态是否会执行限制到的COMM_NO_COMMUNICATION状态(限制的动作是否执行?)。
如果ComMResetAfterForcingNoComm设置为TRUE,当ComM状态从COMM_FULL_COM_NETWORK_REQUESTED切换到COMM_FULL_COM_READY_SLEEP之后,被强制进入COMM_NO_COMMUNICATION,由于模式限制到COMM_NO_COMMUNICATION的请求,那么ComM应该调用BswM_ComM_InitiateReset(),调用该函数将触发ECU复位,复位操作执行要求尽快执行,具体却决于要做的动作(例如,存储所有NvM信息)。这么做的原因是因为,加入软件某个模块出现故障,不释放“Full Communication”的请求,持续地“Full Comunication”请求将导致通道在网络关闭和网络启动之间反复横跳,那么此种情况只能通过重启,让软件模块释放请求,实现限制模式到COMM_NO_COMMUNICATION。
ComM使用CanSM相应的接口实现总线通信能力的控制。当配置ComMBusType = COMM_BUS_TYPE_INTERNAL 时,ComM将省略通信控制能力。
当ComMNmVariant = LIGHT | SLAVE_ACTIVE | SLAVE_PASSIVE | NONE 时,ComM模块不具备NM服务。
NM模块支持的Variant:
只有FULL和PASIVE时具有Autosar NM功能。
下图所示为在CAN总线上启动发送和接收的时序图。在LIN,FlexRay,Ethernet上仅是API不同,时序一致。
### 被动唤醒(CAN)
下图所示为被EcuM模块或NM模块指示唤醒CAN通道后行为。在LIN,FlexRay,Ethernet上仅是API不同,时序一致。
### 网络关闭(CAN)
下图所示为CAN网络关闭行为。网络关闭可能来自于最后一个用户释放COMM_FULL_COMMUNICATION请求,或者来自于ComM_LimitChannelToNoComMode(…)被调用。在LIN,FlexRay,Ethernet上仅是API不同,时序一致。
### 通信请求
下图所示为在CAN总线上开始COMM_FULL_COMMUNICATION的行为。开启COMM_FULL_COMMUNICATION可能是因为用户请求COMM_FULL_COMMUNICATION,也可能是DCM指示ComM_DCM_ActiveDiagnostic。在LIN,FlexRay,Ethernet上仅是API不同,时序一致。
下图所示为期望的时序,但并不一定是实现的(实际应用中根据实际配置会有区别)。下图是顶层PNC协调器检测到释放PNC,请求PNC同步关闭的时序图。
Request for a synchronized PNC shutdown in the role of a top-level PNC coordinator
(TLPC)
下图所示为中间PNC协调器接收到PN关闭消息,请求转发接收到的同步PNC关闭的行为: