AUTOSAR_SWS_DiagnosticCommunicationManager-2

7 Functional specification

7.3 Diagnostic Session Layer (DSL)

7.3.1 Introduction

DSL模块的功能详细参考ISO14229-1 [2]和ISO15765-3 [4]。

7.3.2 Use cases

7.3.3 Interaction with other modules

与DSL子模块交互的模块有以下几个:
PduR 模块
PduRDSL提供诊断请求的数据。
在诊断请求的响应准备好后,将由 DSL触发 PduR发送诊断响应。
DSD 子模块
PduR提供的诊断请求的数据转发给 DSD
在诊断请求的响应准备好后,将由 DSD通知 DSL发送诊断响应。
SW-Cs / DSP 子模块
DSL提供安全和会话状态的访问通道。
ComM 模块
DSL通过 ComM管理诊断的通信状态等。

7.3.4 Functional description

7.3.4.1 Overview

DSL模块提供的功能有以下几个:

请求处理:
转发请求: 从 PduR接收诊断请求并转发至 DSD
并发"TesterPresent": 保持会话活跃(Keep-Alive Logic)。
响应处理
转发响应:将 DSD生成的诊断响应转发至 PduR
响应时序保证: 确保响应时序。
周期性传输支持: 支持定期数据传输机制。
事件触发响应支持: 实现ResponseOnEvent (ROE) 数据传输。
分段响应支持: 分段响应。
应用触发响应挂起: 支持Application触发的ResponsePending响应。
安全级别管理:
安全管理: 控制并维护诊断安全等级。
会话状态管理:
会话状态控制: 管理会话开启、关闭等状态。
非默认会话追踪: 记录并管理非默认会话状态。
时序调整: 允许修改会话相关的定时参数。
诊断协议处理:
协议处理: 支持多种诊断协议的解析与处理。
资源管理: 合理调配诊断过程中所需资源。
通信模式管理:
模式切换: 控制全通信/静默通信/无通信模式(Full- / Silent- / No Communication)。
诊断状态指示: 标记诊断活动或非活动状态。
传输控制: 启用或禁用所有诊断数据传输功能。
7.3.4.2 Forward requests from the PduR module to the DSD submodule
当前没有其他请求在处理
当前有其他请求在处理
使用了不同的通道
使用了相同的通道
判断成立
Dcm_StartOfReception
返回BUFREQ_OK
判断不成立
Dcm_StartOfReception
返回BUFREQ_E_NOT_OK
缓冲区足够且服务可用
Dcm_StartOfReception
返回BUFREQ_OK
Dcm_StartOfReception
返回BUFREQ_E_OVFL
服务不可用
缓冲区足够且服务可用
Dcm_StartOfReception
返回BUFREQ_OK
Dcm_TpRxIndication
参数Result = E_OK
响应发送成功
Dcm_TpTxConfirmation
参数Result = E_OK
PDUR接收到诊断请求
DcmRxPduId收到请求内容
当前有无请求处理?
DcmDslDiagRespOnSecondDeclinedRequest==Ture?
新请求使用了不同的DcmDslConnection?
且新的请求的优先度与当前处理请求相同或者更低
且处于非默认会话状态
PDUR调用Dcm_StartOfReception
参数包含需要Dcm接收的Sdu数据长度以及首帧或者单帧数据
Check缓冲区大小和服务可用性?
拒绝接收请求
PDUR调用Dcm_CopyRxData
将数据拷贝进DCM的缓冲区
PDUR调用Dcm_TpRxIndication
通知DCM接收已完成
DCM存储PDU寻址信息
转发至DSD, 同时DcmPduId被锁定
相同的DcmDslConnection的后续请求不会被接受
并发的TesterPresent requests-0x78除外
用于后续响应时准确发送到对应的请求地址
同时追踪同一地址的后续请求
PDUR调用Dcm_TpTxConfirmation
缓冲区溢出
Dcm_StartOfReception
返回BUFREQ_E_NOT_OK
由于当前有请求正在处理
这里DCM会回复响应: NRC 0x21
拒绝接受请求
DcmPduId被释放
※Note:
新请求的优先度更高时,是否会直接直接抢占?
以下是诊断通信用到的几种PDU (DcmDslConnection配置相关?)
OBD DcmRxPduId
OBD DcmTxPduId
UDS phys DcmRxPduId
UDS func DcmRxPduId
UDS DcmTxPduId

通过配置DcmDslProtocolRx容器中的DcmDslProtocolRxAddrTypeDCM_FUNCTIONAL_TYPE或者DCM_PHYSICAL_TYPE
并且每个通道分配适当的DcmDslProtocolRxPduId,就可以实现物理寻址和功能寻址的设定。

7.3.4.2.1 Dcm_StartOfReception

参照流程图

※Note1:
当有请求在处理中时,如果收到了来自外部的 TesterPresent诊断请求,无论与正在处理的请求是否源自同一通道,都会被接受(Dcm_StartOfReception返回BUFREQ_OK),但是都不会进行处理(即:不进行S3Server timer的重制)。
※Note2:
Dcm_StartOfReception()可以在中断中调用。
※Note3:
Dcm_StartOfReception()的参数 TpSduLength等于0,函数也会返回BUFREQ_E_NOT_OK,不会再进行下一步的处理。
7.3.4.2.2 Dcm_CopyRxData
※Note1
Dcm_CopyRxData被调用且参数SduLength为0时,函数也会返回BUFREQ_OK,并且通过bufferSizePtr返回当前Dcm的接收缓冲区的剩余大小==
根据前面的 Dcm_StartOfReception的说明,当该函数的参数TpSduLength等于0时,会返回BUFREQ_E_NOT_OK,并且不会进行进一步的处理,这是否意味着当TpSduLength等于0这种情况发生时,根本不存在进行下一步的 Dcm_CopyRxData调用?
猜测: Dcm_CopyRxData可能不仅在接受请求数据时调用,或者是为了保证 Dcm_CopyRxData函数的兼容性。
※Note2:
Dcm_StartOfReception取得Dcm接收缓冲区指针到 Dcm_TpRxIndication 被调用的时间内,是数据拷贝阶段,这段时间内,Dcm模块不能访问Dcm缓冲区。
※Note3:
Dcm_CopyRxData可以在中断中调用。
7.3.4.2.3 Dcm_TpRxIndication
※Note1:
Dcm_TpRxIndication被调用且参数 Std_ReturnType result不是E_OK时,Dcm模块将不对接收该 PduIdType id数据的缓冲区域进行进一步的评估(如计算剩余size等),因为接收的数据无法确认是有效还是无效的,防止引发其他错误。
※Note2:
Dcm_StartOfReception取得Dcm接收缓冲区指针到 Dcm_TpRxIndication 被调用的时间内,是数据拷贝阶段,这段时间内,Dcm模块不能访问Dcm缓冲区。
※Note3:
Dcm_TpRxIndication可以在中断中调用
7.3.4.3 Concurrent ”TesterPresent” (”keep alive logic”)
不是
不是
PduR调用Dcm_TpRxIndication
参数Result=E_OK
是否为TesterPresent请求?
转发到DSD做进一步处理
suppressPosRspMsgIndicationBit==TRUE?
重置S3Server会话计时器
不转发到DSD模
※Note1:
不同于前面的正常的诊断请求的接收流程,对于服务 SID 0x3E的keep-alive logic请求使用独立的DcmRxPduId,并且缓冲区也由Dcm模块内部直接给定,不需要显式的配置。
※Note2:
该服务的DcmRxPduId(UDS func DcmRxPduId)也属于物理寻址的 DcmDslConnection,也正因为有独立的处理过程,所以对于积极响应抑制位为TRUE的情况,不影响其他的物理寻址请求。
7.3.4.3.1 Dcm_CopyTxData

※Note1:
:如果 PduR_DcmTransmit()中请求发送的数据长度大于已经被Dcm_CopyTxData拷贝到发送缓冲区的数据长度,那么说明发送缓冲区的长度不足以容纳请求的数据,在当前发送缓冲区的数据发送成功后,PDUR会继续调用Dcm_CopyTxData拷贝后续数据。

autosar_sws_timesyncovercan是AUTOSAR标准中定义的基于CAN总线的时间同步服务。 在汽车电子系统中,不同的控制单元(ECU)需要按照统一的时间基准进行操作,以确保各个控制单元之间的协调和同步。autosar_sws_timesyncovercan就是为了满足这个需求而被定义的。 autosar_sws_timesyncovercan使用了CAN总线作为通信的介质,通过CAN总线将时间同步消息发送到各个控制单元。通过时间同步消息,各个控制单元可以获取精确的时间信息,并根据这个时间信息进行各种操作,例如数据传输、事件触发等。 autosar_sws_timesyncovercan实现了基于Master-Slave架构的时间同步机制。其中,Master节点负责发送时间同步消息,而Slave节点则负责接收并进行时间同步。Master-Slave架构确保了整个系统中所有控制单元之间的时间保持一致。 autosar_sws_timesyncovercan定义了不同的时间同步模式,包括周期同步模式和非周期同步模式。周期同步模式适用于需要周期性执行任务的应用场景,而非周期同步模式适用于一次性任务的应用场景。 autosar_sws_timesyncovercan还规定了时间同步消息的格式和传输方式,确保消息的可靠性和准确性。同时,还定义了时间同步相关的接口和API,方便控制单元的开发和集成。 总之,autosar_sws_timesyncovercan是一种以CAN总线为基础的时间同步服务,通过统一的时间基准来协调和同步汽车电子系统中的各个控制单元,实现系统的高效运行和协作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值