AUTOSARCOM通信堆栈：汽车总线系统与诊断DCM互联

图7-6-9表示了相当复杂的通信服务结构。AUTOSAR支持总线系统CAN、FlexRay和LIN，但对于MOST的连接还没有准备。总的来看MOST协议堆栈表明了少数其他的结构。因为复杂的面向服务的MOST网络服务应用接口（见3.7节）不能直接地复制相对比较简单、面向数据报文的接口，所以这些接口是由CAN、FlexRay和LIN支持的。

图7-6-9 CAN、FlexRay和LIN中的带专用组件的通信堆栈

与应用软件组件相反的是，一个统一的、独立的接口由专业的总线系统提供。这种接口本质上是由模块式诊断通信管理员（DCM）和AUTOSAR COM组成的。根据ISO 14229和ISO 15031（见5.2节和5.3节），DCM模块式针对的是UDS和OBD诊断服务的离线通信。它不支持较旧的KWP—2000协议。AUTO-SAR COM模型负责在线通信。AUTOSAR的变量由OSEK COM表示出来（见7.2.2节）。置于它下面的协议数据单元（PDU）程序和IPDU的复用层，把数据报文分布在每个总线系统，只要没有中间存储数据报文的必要，那么作为网关把来自总线系统所出现的数据报文直接地传递到其他的总线系统。在PDU层的下面，是专业总线传输协议TP和对应于每一个通信控制器的硬件驱动器。

长期以来对于所有的总线系统，不仅离线而且在线使用的都是传输协议。但目前的传输协议只用于诊断通信。在CAN方面是基于ISO 15765—2（见4.1节）的。对于FlexRay传输协议，很大程度上采用现有的概念（见4.2节）。在LIN中传输协议不是分离的模式，而是按LIN的接口组合成一体。

图7-6-10 带专业总线的状态管理员的通信管理员总线状态（简化图）

对于应用系统，XCP on CAN和XCP on FlexRay（见6.2节）被称为协议，是作为ASAM的一部分，但不是AUTOSAR规程的组成部分。但是对于在线通信的开放式ASAM的描述格式FIBEX和ODX以及对于诊断数据的ASAM格式ODX，这两种格式渐渐地开始受欢迎，而老而专利性的格式逐渐地被祛除，可能不再集成到AUTOSAR中去。但是AUTOSAR配置工具必须准备相应的输入和输出接口。

通信管理员（ComM）对总的通信堆栈进行初始化并按协调的方式管理具有专门总线的状态管理和网络管理，这些将在下一节详细描述。根据其功能，通信管理员可以被理解为是针对负责ECU状态管理员的扩展通信，其中不仅针对总的设备层，也针对每个总线系统的休眠和唤醒片段。对于每一个总线系统而言，其状态是按分离形式进行管理的。在图7-6-10中所示的状态有多个子状态。例如在FlexRay时，实际上所有的协议操作控制状态是如图7-6-11所示的。在CAN时有子状态，这种子状态可以包括有源错误/无源错误和总线断开（Bus Off）的错误（比较3.3.4节）。主要状态是不能通信的（即离线Off line），在这种情况下总线接口是断开的，完全通信状态（即在线Online）不仅包括发送也包括接收。

图7-6-11 诊断通信管理员DCM的结构

但是因为监视机制对于运行时间系统来说加重了微控制器的负载，所以有些应用组，我们称之为被信任的应用，在系统配置时对于这种系统可以关断监视机制。另外用API的功能CallTrustedFunction（）对于非信任应用，有可能按信任应用调用功能。

未来将强化使用带硬件保护机制的微控制器。这种处理器使用有特权和非特权的运行模式（核心模型和用户模型）。在操作系统采用有特权模式期间，应用系统一般就工作在非特权模式，因此不能对一些处理器的控制寄存器进行数据访问，如处理器的时间给定器和中断控制。用类似的方法，这种处理器也能监视存储器的访问（存储器访问保护）。所以应用组只能访问它的被指定的存储器区域，并在访问之前，要对其他的应用组进行保护。这种硬件执行机制的功率比纯基于软件的监视要强。但是在软件配置和运行时间环境RET时，在AUTOSAR 3.0中的存储器访问保护到目前为止还没有完全得到支持。

在配置AUTOSAR OS时，AUTOSAR 2.0是借助于著名的OIL配置语言进行的（表7-2-3），其中对于新添加的功能，规定为OIL 3.x。在AUTOSAR 3.0中，基于XML的配置只是约束在操作系统中。因此现有的OSEK OS系统可以被简单地移植到AUTOSAR中，人们期待着配置工具制造商为OIL的输入/输出接口做出规划。

AUTOSAR OS规程对于一定的任务，如在航海系统或其他带图解用户表面的信息设备中指明了方向，可以使用其他操作系统，如嵌入式Liuxh或Windows CE。对于这种系统建议采用AUTOSAR OS的抽象层（OSAL），因此AUTOSAR功能，如AUTOSAR兼容的通信堆栈或诊断功能，也能在这种系统上建立起来。

基础软件（BSW）调度机

不仅应用层的软件组件而且基础软件模式也采用操作系统的机制。但是在这两种情况下，AUTOSAR架构试图避免直接使用操作系统的API功能，而是接通一个中间层。对于应用系统的软件组件，这个中间层被称为运行时间环境RTE，这将在7.6.4节中描述。而对于基础软件内部，BSW调度机被视作虚拟的中间层。

所有的基础软件模式是由不同的功能组成的，这些功能必须被唯一地或周期性地调用。但在每次调用之后，不用识别内部等待状态就可以重新直接结束。一般每一个模式有初始化、去初始化和主功能，这样就可以实现标准化的功能以及各种呼叫返回和通知功能。

执行BSW调度器程序技术仅仅是少数的C功能，在这些功能中，基本软件功能的调用，是按正常的顺序进行的，并且要对它们的调用频率进行分组。尽管在这里采用了BSW调度机表示真正的操作系统，但这些C功能作为任务是由真正的操作系统SUTOSAR OS调用的。如果控制器的配置人员配置了基础软件，那么C功能在很大程度上可以被自动地产生。如果人们还记得根据AUTOSAR倡导者的设想，基础软件不是被作为完整的软件包来准备，而是与车辆行驶工况的行驶软件一样由不同的供应商组件组合在一起，那么这种中间层的意义就变得十分清楚了。由于BSW的调度机的配置和调用少数C功能组合在一起，对于这种集成化所要负的责任是要确定每一个模型的流程频率和流程的顺序，而不必对于每一个模型使用真正的任务和复杂的同步资源。

还有一种可能性是调节到静默通信状态，这个状态虽然能接收但是不能发送。状态之间的转换是根据应用软件和诊断通信的管理要求进行的，还要考虑网络管理的反馈通知、总线的硬件驱动和出现的错误。反过来通信管理员也可以借助呼叫返回功能通知其他组件有关状态的改变。和ECU的状态管理员一样，在配置时就要确定哪些软件组件允许状态改变。如果有多个不同的要求，则每次把这种要求调节到较高值状态，如发送和接收而不只是接收。

●离线通信：诊断通信管理员

诊断通信管理员（图7-6-11）根据ISO 15031和ISO 14299处理出现的OBD和UDS诊断数据报文。现在在规程中规定，在下一个询问被处理之前，必须应答每一个询问。另外还有一系列的诊断服务限制，在AUTOSAR3.0中现在还不支持一致性的执行。

处理诸如诊断会话、数据访问保护以及要求时间关系的确保时，包括测试当前数据信息和需要首部的应答格式化这些功能，是在DCM的子组件DSL和DSD中独立进行的，诊断服务涉及错误存储器（表5-2-5和表5-3-2），按子组件DSP处理。有关上述诊断事件管理员对错误存储器进行的数据访问见图7-6-7。诊断服务处理的核心是服务标识符表，对于这种表，在进行系统配置时要把每一个服务记入到相应的处理功能。大量的诊断服务如读来自测量值的OBD功能（表5-3-3），将直接在DSP中执行，可获得关于RTE访问的必要测量数据，诊断服务不是在内部处理，而是可以向应用层的软件组件通知返回功能。对于所有的未知服务，模型独立地发送不支持服务通知（表5-1-2）。DCM含有多个服务标识符表，表格之间的运行时间是可以被转换的。根据这个方法，在需要时可以支持多个不同的诊断协议。

人们期望的是在对诊断通信管理员的配置时，按诊断区域对普通的ODX诊断数据项提供可以使用的进口/出口的接口，但这留给了配置工具的制造商，AUTOSAR规程没有为此作规定。

●在线通信：AUTOSAR COM

图7-6-9所示的是根据OSEK COM 3.0版本，基于信号的在线通信接口，但其中少数机制没有被考虑进去，因为通过其他的AUTOSAR概念，已经覆盖了这些少数的机制。队列式的数据报文不属于现有的功能，因为这种队列式报文所必需的中间存储器，现在可以在运行时间环境RTE中完成。另外AUTOSAR COM也不支持改变长度的数据报文（如动态和零长度的报文）以及对于发送端这一边的数据报文的过滤（见7.2.2节）。AUTOSAR COM支持周期性地发送数据报文，但不支持OSEK的StartPeriodic（）和Stop Periodic（）功能。AUTOSAR COM和操作系统不同，对于配置也不采用OIL。因为在AUTOSAR时，对于所有的应用组件，内部和外部的数据交换应该是透明的，且关于运行环境RTE是统一的，但采用相同的配置参数，与OIL是一样的。这些参数在AUTOSAR中仅仅按XML的格式进行复制。通信的启动和停止是通过通信管理员，而不是通过已知的OSEK COM功能StartCOM（）和StopCOM进行的。

RET与应用层不同，它采用的是面向信号的接口（图7-6-12）。哪一种信号与数据报文统一（协议数据单元PDU），在什么条件下发送数据，这些和OSEK COM一样，是在配置时确定的。除了简单的信号以外，信号还能组合成组，所以在发送或接收时，可以传输连续的成组数值。有关的API功能是Com_Send-Signal…（）和Com_ReceiveSignal…（）。其次AUTOSAR COM可以把内部信号分成多个数据报文。

图7-6-12 AUTOSAR协议堆栈的原理(www.zuozong.com)

●协议堆栈、传输堆栈和PDU程序的机制

面向信号的COM层没有采用传输协议，所以在CAN和LIN时的数据报文没有大于8B。在FlexRay时，PDU可能达到254B。相反对于DCM的诊断通信，在CAN时作为ISO 15765—2标准的传输协议ISO TP没有变化地被继续采用（见4.1节）。FlexRay传输协议与ISO TP是前向兼容的。现在因为该协议是唯一已知的用于FlexRay的传输协议，根本与AUTOSAR内部无关，但协议不只是被用在AUTOSAR的应用系统中，这在4.2节中已经讲述过了。

总的协议堆栈（图7-6-12）采用相互独立的与实际总线系统一样的基本概念。在发送时数据报文（PDU）由COM和DCM通过PDU程序，有时是由传输层传送到总线系统的接口。总线系统的接口，通过相应的驱动器指定具有真正发送端的通信控制器发送信息。在指定的发送计划完成之后，发送功能马上返回。之后如果数据报文被实际成功地发送，通过反馈功能指示器得到一个确认（TxConfirma-tion，Tx=Transmit）。如果数据报文被接收，通过反馈功能通知上一层（RxIndica-tion，Rx=Receive）并可以读此数据报文。在发送数据报文时，是否应该采用超时的监视或接收过滤、通过哪些不同的总线系统发送和接收数据报文，这些对于每一个PDU，是在研发阶段确定的并按表格结构进行存储（PID常规表等），也可能由其他的PDU组成（IPDU复用）。在协议软件内部，通过特性数字（PDU ID）识别PDU。数据报文内容的进一步传送，一般是通过单独的层面完成的。在何种条件下，由谁来复制数据和谁来准备必要的缓冲，对于每个总线系统的协议堆栈，在细节上是不同。

●CAN协议堆栈

CAN接口主要负责所有的控制器的CAN信道（图7-6-13）。如果有多个CAN的控制器工作，那么这些信道就由CAN驱动器自己管理，只要相互彼此兼容。相反如果有不同类型的CAN控制器时，那么就由不同的并行工作的CAN驱动器负责。CAN驱动器通过关于地址/数据总线或微控制器的SPI总线，要求CAN控制器对写和读命令作出响应。在数据的发送或接收之后，CAN的反馈通知，或是通过CAN的驱动器或是以中断的工作方式进行周期性询问（轮询）。为了保证轮询的安全性，不同的CAN驱动器内部功能必须由操作系统有规律地调用。在驱动器上面是CAN接口，基本采用同步调用接口。在发送时用CanIfTransmit（），借助于功能CanWrite（）数据报文被直接复制到CAN控制器的发送存储器中并触发发送要求。如果发送存储器没有空，那么CAN接口就把数据报文存储到内部缓冲器中，然后在下一个时间点自己复制到CAN的控制器中。在这两种情况下，在实际发送数据报文之前，先复制数据报文，然后CanIfTransmit（）马上返回数据报文。

反馈通知CAN的上层，如AUTOSAR COM、NM、DCM或TP以及中间接通层PDU和CAN状态管理员，是通过呼叫返回功能进行的。在CAN控制器成功地发送了数据报文之后，CAN驱动器通过调用功能CanIfTxConfirmation（）通知CAN接口并通过功能UserTxConfirmation（）通知应用系统。在通知应用系统之前，CAN报文标识符和被接收的数据报文长度，可以选择在静态配置时检查数据报文的过滤，有时可能被拒绝。根据这一方法，从应用的角度来说，数据报文的接收过滤不取决于被采用的软件式或硬件式CAN控制器的过滤方式（见3.3.6节）。在上层用CanIfReaRxPduData（）读数据并把数据复制到真正的数据报文缓冲器中。

图7-6-13 API功能可选的CAN协议堆栈

CAN状态管理员以协调的方式，对每一个CAN控制器的CAN接口进行管理，如非初始化的、被停止和启动、休眠和总线断开的状态。这些状态之间的转换，是通过功能CanIfSet-ControllerMode（）进行的，或在总线断开和休眠时，自动地通过CAN控制器进行或CAN的转换器的反馈通知通过驱动器进行的。如果CAN控制器多次识别出传输错误就断开总线，或控制器处在省电休眠时，接收一个新的数据报文（唤醒模式）。

●FlexRay协议堆栈

FlexRay的协议堆栈结构（图7-6-14），与CAN是相对应的，而内部功能是有明显偏差的。在事件控制的CAN总线中，数据报文实际是直接调用CanIf_Transmit（）功能发送的，而这在FlexRay时，只有在调用的发送功能FrIf_Trans-mit（）与总线系统通信流程同步时才有可能（直接传输）。因为这种同步在实践中不能持续进行，但一般可以配置成分离式的发送。因此发送功能FrIf_Transmit（），只是先记下后面要发送的数据报文（分离式传输）。此外数据报文的配置可以在没有明确地调用FrIfTransmit（）功能下，有规律地被发送。真正地在总线上发送数据，是在相应的FlexRay时隙内，通过内部流程控制，自动地在FlexRay接口中进行的。因此在系统配置时，要建立FlexRay工作表，即操作表格（Job），操作与FlexRay总线系统的时隙要同步完成。重要的操作有：

●分离式缓冲访问传输：借助于应用准备的呼叫返回功能User_Trigger-Transmit（），把数据报文复制到内部缓冲器，以后再从这里复制到通信控制器的发送缓冲器中。通过这种带中间存储器的机制，应用可以发送数据报文，不必自己强制性地用时间扫描与总线系统同步（分离式传输）。

●提供Tx确认：借助于呼叫返回功能User_TxConfirmation（），确认数据报文的成功发送。

●接收和指示：根据通信控制器的接收缓冲器把接收的报文复制到内部中间存储器，之后调用应用的呼叫返回功能User_RxIndication（），再把数据报文复制到真正的缓冲器中（直接接收）。

●接收和存储、提供Rx指示：内部中间存储器的复制过程分配和下一个时间点，按两个子操作通知应用系统（分离式接收）。

●准备PDU：如果对于在通信周期中要传输的FlexRay格式，通信控制器没有足够的内部缓冲器，那么FlexRay通信控制器就要进行动态的转换配置（见3.5.6节）。

图7-6-14 API功能可选的FlexRay协议堆栈

通信操作的执行是在中断服务程序（FlexRay任务表执行功能）中进行的，中断服务功能经过FlexRay驱动器，在通信控制器与FlexRay总线系统的宏时钟同步时被调用的。为了对调用时间点产生影响并与总线系统的激活同步，FlexRay接口和驱动器使用了一系列的功能，如FrIf_Set…Timer（）或FrIf_Enable…Timer（），其中计时器在这种关系中与FlexRay总线系统的循环和宏时钟的时隙是有关的。

在AUTOSAR FlexRay规程中，人们注意到FlexRay与AUTOSAR是被并行研发出来的。有些通信部分是在CAN和LIN的概念基础上设计出来的。新的FlexRay可能不总是完全可用，所以AUTOSAR通信堆栈内部的数据报文总是根据协议数据单元（PDU）来处理的，它应该与总线系统是无关的。对于CAN和LIN，AUTOSAR COM PDU的长度是不超过8B的。但因为FlexRay与CAN和LIN不同，它能有效地传输254B的数据报文，所以较大的数据报文（FlexRay数据报文）在配置时借助于数据报文的结构规划，将由多个PDU组合在一起。因此接收端知道在数据报文的内部哪些PDU发生了实际的改变而哪些没有改变，能与当前的位区一起传输。为了解决问题，对于FlexRay，AUTOSAR也采用多于8B的PDU，但不能任意转换到其他的总线。在AUTOSAR DCM的数据报文中，在每一种情况下采用相应的传输协议，这样问题就解决了。类似的情况是，在FlexRay中，为能支持安全性要求极高的数据报文进行并行传输，必须对每一个信道的工作表进行手工配置。检查正在发送或接收的这种数据报文是否在两个信道上一致传输。目前在协议的内部对此没有作规定，还必须由应用系统来承担这部分工作。

FlexRay状态管理员按协调的方式，用每个控制器的FlaxRay接口，管理具有不同的FlexRay协议的在线和离线子状态。这些状态之间的转换是用功能FrIf_StartControllerCommunication（）或FrIf_HaltControllerCommunication（）来进行的。与FlexRay的控制器类似，总线收发器也要接到相应的状态。对通信控制器协议状态的数据（见3.5.6节）、同步状态或唤醒模式的发送和其他符号的访问，是用功能FrIf_GetPOCStatus（）、FrIf_GetSyncState（）、FrIf_SendWUO（）、FrIf_AllowColdstart（）等进行的。

●LIN协议堆栈

LIN的协议堆栈（图7-6-15）执行关于LIN的主控制器协议版本LIN V2.x（见3.4节），不支持纯粹的从功能设备。与CAN和FlexRay不同的是LIN传输协议不是分离模式，而是集成在LIN的接口中。关于LIN的网络管理和LIN收发器的控制是规划好的，但在AUTOSAR2.x和3.0中还没有建立好。

操作系统周期性地调用LIN接口的内部功能，数据报文表（调度表）在这个接口上工作，并发送和接收相应的LIN首部或响应数据报文。在LIN规程中建议程序接口LIN AIP（见3.4.8节）不在AUTOSAR中使用，取而代之的是借助于功能LinIf_ScheduleRequest（），不同的预配置数据报文表之间是可以转换的，并可以唯一地或周期性地执行。借助于功能LinIf_Transmit（），可以发送离散帧（见3.4.4节）。功能LinTp_Transmit（）允许诊断帧。这里存在着某些不良情况，在它后面隐藏的是传输协议ISO 15765—2的变量，用这种传输协议也可以传输UDS或KWS 2000诊断数据报文，但一般它适合任意的分组数据（见3.4.5节）。因此使用user_ProvideTx/RxBuffer（）时，和FlexRay一样，要有类似的手工处理的缓冲。

图7-6-15 API功能可选的LIN协议堆栈

与CAN和FlexRay一样，用LinIf_GotoSleep（）和LinIf_WakeUp（）支持总线系统的省电模式。

关于总线系统的配置，和普通的AUTOSAR一样，采用XML的格式。传统的关于LDF和NCF的数据，没有规定用LIN配置语言（见3.4.6节）。为了保持能与其他的LIN规程工具兼容，有时AUTOSAR工具制造商也必须准备转换程序。直接支持从控制器的动态配置（见3.4.7节），这样相应的数据报文就可以按专门的数据报文表进行预先定义，然后在需要时，一次性地对功能LinIf_ScheduleRequest（）进行调用。