您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   模型库  
会员   
   
基于 UML 和EA进行分析设计
9月9-10日 北京+线上
大模型核心技术RAG、MCP与智能体实践
8月14-15日 厦门
图数据库与知识图谱
8月28日-29日 北京+线上
   
 
 订阅
一文掌握Autosar ComStack的精髓!
 
作者:Geeks Tool
  86  次浏览      4 次
 2025-7-31
 
编辑推荐:
本文主要介绍了Autosar ComStack相关内容。希望对您的学习有所帮助。
本文来自于微信公众号汽车电子工具智慧库,由火龙果软件Linda编辑、推荐。

Autosar ComStack概述

在AUTOSAR的分层架构中,通信栈(ComStack)促进了车载网络通信。因此,ComStack可以定义为一个为基础软件模块和应用层/应用软件提供通信服务的软件栈。

一个典型的AUTOSAR通信栈的模块分布在基础软件层的三个子层中:

服务层

ECU抽象层

微控制器抽象层 (MCAL)

在AUTOSAR中,通信栈是一组模块,如:

COM模块(服务层)

PDU路由器模块(服务层)

特定总线接口模块(ECU抽象层),如CanIf、LinIf、FrIf等

外部总线驱动程序(ECU抽象层)

内部总线驱动程序(MCAL层)

ECU通过不同的网络(如CAN、LIN、FlexRay等)发送消息,这些消息被称为PDU(协议数据单元)。

应用程序发送或接收的数据项被映射为signals。

区分I-PDU, N-PDU和 L-PDU

在各层之间传输PDU时,PDU会根据所在的层被赋予相应的名称。PDU的名称包括I-PDU(交互层PDU)、N-PDU(网络层PDU)和L-PDU(数据链路层PDU)。

当PDU位于通信硬件抽象层之上时,称其为I-PDU。

当PDU位于PDUR以下且通信驱动程序层之上时,称其为N-PDU。

当PDU位于通信硬件抽象层之下时,称其为L-PDU。

SDU 与 PCI

SDU是服务数据单元(Service Data Unit)的缩写,PCI是协议控制信息(Protocol Control Information)。

SDU代表要传输的数据。在传输过程中,SDU与PCI一起从上层移动到下层。在接收时,SDU从下层提取并转发到上层。PCI包含有关SDU下一个目的地的重要信息,主要包括SDU的源和目的地的详细信息,指示PDU(协议数据单元)应传递到的下一个层级。

简单来说,PDU在上层和下层之间传输,包含SDU和PCI。

常见的AUTOSAR通信协议

CAN(Controller Area Network)是一种广泛使用的汽车通信协议,以其高速和可靠性著称。它通常用于安全关键的应用,如刹车和转向控制。

FlexRay是一种高速汽车通信协议,以其确定性和鲁棒性而闻名。它通常用于需要高带宽和保证消息传递的应用,如动力总成和底盘控制。

LIN(Local Interconnect Network)是一种低成本的汽车通信协议,通常用于不需要高带宽的应用,如气候控制系统和信息娱乐系统的控制。

MOST(Media Oriented Systems Transport)是一种高速汽车通信协议,通常用于音频和视频应用。

Ethernet(以太网)是一种广泛使用的网络技术,在汽车应用中越来越受欢迎。它通常用于需要高带宽和与外部网络连接的应用,如远程信息处理系统和信息娱乐系统。

AUTOSAR通信栈可以支持多种通信协议,具体取决于应用的需求。这使得AUTOSAR通信栈可以用于各种配置不同的车辆。

选择通信协议时需要考虑以下因素:

需要传输的数据类型:某些协议比其他协议更适合某些类型的数据。例如,CAN非常适合传输小而简单的消息,而FlexRay则更适合传输大而复杂的消息。

带宽要求:系统的带宽要求将决定通信协议必须支持的最大数据传输速率。

可靠性要求:系统的可靠性要求将决定通信协议必须提供的错误检测和纠正级别。

硬件成本:实现通信协议的硬件成本也是选择过程中的一个因素。

如下所示:是不同车载网络协议的汇总比较信息:

AUTOSAR架构中的CAN通信栈

当目标总线类型为符合AUTOSAR的软件是CAN时,ComStack实现会针对CAN总线进行执行。从接口(IF)和状态管理器到低级驱动程序,这些模块都需要为CAN总线进行配置。

CAN通信栈的不同模块列表:

AUTOSAR COM(服务层)

PDU Router(服务层)

CAN State Manager(服务层)

CAN Network Manager(服务层)

CAN Transport Protocol (服务层)

CAN Interface(ECU抽象层)

CAN Transceiver Driver(ECU抽象层)

CAN Driver(MCAL层)

AUTOSAR Com Stack各模块的角色

Com模块:“将信号打包成PDU”

AUTOSAR COM是RTE和PDU路由器之间的一个模块。它基于OSEK COM规范,提供一个统一的CAN网络接口。它负责为应用层提供信号级访问,并为底层提供PDU级访问,无论协议如何。在发送端,它将信号打包成PDU;在接收端,它解包接收到的PDU,以提供信号级访问。COM在PDU级别负责对PDU进行分组,并启动/停止PDU组。

PduR模块:“将PDU路由到不同的通信协议”

PDU路由器(PDU Router)是一个负责将PDU路由到相应总线特定接口模块的模块。在PDU路由器模块之上,所有PDU都是与协议无关的。在PDU路由器下方,所有PDU被路由到协议特定的模块。

PDU路由器也是一个PDU级别的网关,用于将接收到的PDU从一个总线特定接口模块传输到另一个总线特定接口模块。当PDU通过相同协议从一个控制器路由到另一个控制器时,PDU路由器还实现了网关功能。

CanTp模块:“执行大PDU的分段”

CAN TP模块提供的基本服务包括对负载超过8字节的消息进行分段,流控制下的消息传输,以及在接收端重新组装分段消息。

CanIf模块:“将PDU映射到对应的CAN ID”

CAN接口(CANIF)是ECU抽象层中的一个模块,负责传输请求、传输确认、接收指示、控制器模式控制和PDU模式控制等服务。

Can模块:“访问微控制器寄存器以在物理总线上发送实际的CAN帧”

该模块是MCAL层的一部分,为上层服务提供硬件访问,并为上层提供与硬件无关的接口。CANIF是唯一可以访问CAN驱动程序的模块。

下图展示了基于CAN的通信栈(ComStack):

AUTOSAR通信组件的常见使用场景

安全性:AUTOSAR通信组件用于传输安全关键数据,如刹车踏板位置和方向盘角度。这些数据被车辆的电子稳定性控制(ESC)系统和其他安全系统用于保持车辆的控制。

动力系统:AUTOSAR通信组件用于传输与动力系统相关的数据,如发动机转速和燃油水平。这些数据被车辆的发动机控制单元(ECU)用于优化动力系统的性能和节省燃油。

底盘:AUTOSAR通信组件用于传输与底盘相关的数据,如车轮速度和悬挂位置。这些数据被车辆的底盘控制单元(CCU)用于控制刹车、转向和悬挂。

信息娱乐系统:AUTOSAR通信组件用于传输与信息娱乐系统相关的数据,如电台频道和导航指令。这些数据被车辆的信息娱乐系统用于为驾驶员和乘客提供娱乐和信息。

远程信息处理:AUTOSAR通信组件用于传输与远程信息处理系统相关的数据,如车辆的位置和诊断数据。这些数据被车辆的远程信息处理系统用于提供紧急道路援助和远程车辆诊断等服务。

AUTOSAR通信(COM)模块在汽车软件开发中发挥着几个重要作用:

标准化: AUTOSAR COM提供了标准化的接口和通信协议,用于在车辆网络中的不同电子控制单元(ECU)之间交换数据。这种标准化确保了不同供应商开发的组件之间的互操作性,简化了集成过程,缩短了开发时间。

可扩展性和灵活性: 随着车辆变得越来越复杂,ECU和传感器数量的增加,通信需求也变得更加复杂。AUTOSAR COM允许可扩展和灵活的通信架构,适应各种通信模式、消息格式和网络拓扑。

高效的数据交换: COM模块通过提供消息缓冲、路由和优先级机制,优化了ECU之间的数据交换。这有助于管理车辆网络中的信息流,确保关键数据的及时传递,同时优化带宽使用和系统资源。

容错性和鲁棒性: 汽车系统必须在各种条件下可靠运行,包括环境因素和组件故障。AUTOSAR COM包括错误检测、诊断能力和容错通信协议等功能,以增强系统的鲁棒性,并确保在存在故障的情况下继续运行。

实时通信: 许多汽车应用需要实时通信来及时处理关键数据,如发动机控制、刹车系统和高级驾驶辅助系统(ADAS)。AUTOSAR COM通过提供截止日期监控、确定性消息传输和关键数据优先级机制,支持实时通信要求。

简化开发和维护: 通过遵循AUTOSAR标准和使用COM模块,开发人员可以受益于可重用的软件组件、标准化的API和预定义的通信接口。这简化了软件开发、集成和维护任务,加快了上市时间,降低了总体开发成本。

AUTOSAR COM信号

COM通过提供Com_SendSignal函数使RTE能够发送信号。当RTE调用“Com_SendSignal”来发送信号时,COM会将这些信号存储在其内部缓冲区中,然后通过“PduR_ComTransmit”函数将存储的信号传输给PDU路由器(PDU Router)。同样,COM通过提供“Com_ReceiveSignal”函数允许RTE接收信号。当PDU路由器通过“Com_RxIndication”函数通知COM接收到PDU时,COM会分析PDU中的信号,并通过分配的回调函数通知RTE每个接收到的信号。

COM中信号传输和接收的简化模型

交互层--PDU接收

AUTOSAR COM信号组

在AUTOSAR中,COM引入了信号组功能来处理复杂的数据类型。这些组信号形成信号组,由COM管理,以实现高层模块RTE和PDU传输之间的同步,利用 shadow buffer机制。

通过Com_UpdateShadowSignal和Com_SendSignalGroup等函数,COM使RTE能够传输信号组。RTE使用“Com_UpdateShadowSignal”将组信号发送到COM,这些信号会存储在COM的影子缓冲区中。一旦所有组信号都被发送,RTE会触发Com_SendSignalGroup函数进行传输。在这里,COM从影子缓冲区中读取组信号,将其写入I-PDU缓冲区,并通过PduR_ComTransmit函数将I-PDU发送到下层模块PDU路由器。

COM中信号组传输的简化模型

此外,COM还为RTE提供了诸如“Com_ReceiveShadowSignal”和“Com_ReceiveSignalGroup”的函数,以便从COM接收信号组。当PDU路由器通过“Com_RxIndication”通知接收到PDU时,COM会分析PDU中的信号组,并通过分配的回调函数通知RTE信号组的接收。COM使用“Com_ReceiveSignalGroup”将存储在I-PDU中的组信号复制到影子缓冲区,然后RTE根据信号组规范使用“Com_ReceiveShadowSignal”从COM的影子缓冲区中检索这些组信号。

COM中信号组接收的简化模型

PDU组(协议数据单元)

PDU组是一些可以逻辑上分组的PDUs。这些PDUs由COM作为一个组进行处理,该组可以一起激活(启动)或停用(停止)。

信号网关

AUTOSAR COM 模块可以将接收到的 I-PDU 从下层网关并立即发送到相同或另一个下层模块(例如:CAN --> CAN,CAN --> LIN)。

路由关系通过 ComSwMapping 配置容器静态配置。

Large Data Type

Large信号是指数据量大到无法适应底层通信协议单个 PDU 的信号(例如,CAN 协议仅支持单个 CAN 帧中的 8 字节数据)。

Large信号需要配置一个大型 PDU,通过底层总线的传输协议(例如 CanTp、LinTp、FrTp)进行传输。

通信管理关键模块和通信状态

通信管理是汽车开放系统架构(AUTOSAR)中的一个重要方面,它在现代车辆中促进了各种电子控制单元(ECU)之间的高效和可靠的通信。在 AUTOSAR 的背景下,多个模块和术语在管理车辆网络中的通信方面发挥着重要作用。

以下概述了 AUTOSAR 中的通信管理,重点介绍关键模块,如 ComM、CanSM、BSWm 和 EcuM以及不同的通信模式。

ComM(通信管理器)

ComM 负责管理通信模式,并协调 ECUs 之间的通信请求。它使 ECUs 根据系统需求和操作条件在不同的通信状态之间进行转换。ComM 确保通信的高效进行,同时优化功耗和网络带宽。

ComM 在system stack中的主要功能概览:

ComM_RequestComMode:

该函数用于请求指定网络通道的通信模式更改。它触发一个请求,将通信模式转换为 ComMode。

PDU 路由器模块

PDUR 模块提供 I-PDU 的路由服务,用于 COM 和 DCM 模块,使用通信接口模块(如 CanIf、LinIf 和 FlexRayIf)和传输协议模块(如 CanTp 和 FlexRayTp)。

PDU 路由器模块在 BSW 中的位置如下图所示:

最常见的使用 PduR 的上下层模块组合是:

上层模块:DCM 和传输协议模块

:COM 和通信接口模块/传输协议模块/I-PDU 多路复用模块

PDUR 的作用仅限于路由,它不能修改 I-PDU 或执行任何数据检查。它还提供 I-PDU 的网关服务,能够将 I-PDU 从一个源总线(如 CAN、FlexRay、Lin)路由到一个或多个目标总线。

System Stack中的 PDU 路由器:

PDU 从应用层通过 AUTOSAR 通信栈层的简化示例:

应用层 (AP):

源 ECU 上运行的应用层准备引擎温度数据 PDU,并指定源(自身的 ECU 标识符)和目标(接收 ECU 的标识符)。

通信 (COM) 层:

在接收到应用层的 PDU 后,COM 模块验证源地址和目标地址,以确保它们有效且符合系统配置的通信约束。

PDU 路由器 (PDUR):

在 COM 模块验证后,PDU 被传递给 PDUR,PDUR 检查目标地址以确定适当的路由路径。

它查找路由表以确定 PDU 的目标。在本例中,它发现 PDU 需要转发到 CAN 接口 (CANIF) 以通过 CAN 总线进行传输。

PDUR 然后将 PDU 转发到 CANIF。

CAN 接口 (CANIF):

PDUR 将 PDU 转发到 CAN 接口,CANIF 使用目标地址准备 PDU 以通过 CAN 总线进行传输。

它准备 PDU 以通过 CAN 总线进行传输,这可能涉及添加 CAN 标识符和任何必要的控制信息。

CANIF 然后将准备好的 PDU 发送给 CAN 驱动程序进行实际传输。

CAN 驱动程序:

CAN 驱动程序从 CANIF 接收准备好的 PDU。

它与硬件 CAN 控制器交互,将 PDU 通过 CAN 总线进行传输。

CAN 驱动程序监控总线以获取确认并处理传输过程中可能发生的任何错误。

接收 ECU:

在接收 ECU 上,过程会被反转。

在接收时,接收 ECU 上的 CAN 驱动程序从 PDU 中提取目标地址,以确认它是预期的接收者,并将其传递给 CANIF。

CANIF 然后将接收到的 PDU 转发到 PDUR。

PDUR 查找路由表以确定目标应用层。

最后,PDUR 将接收到的 PDU 传递给应用层进行处理,其中引擎温度数据可以被提取并由接收应用程序使用。

CanSM (控制器局域网状态管理器)

CanSM 是一个专门用于管理控制器局域网 (CAN) 通信协议的模块,这在汽车应用中广泛用于 ECU 之间的通信。CanSM 监控 CAN 通信通道的状态,并启动适当的操作以确保数据传输的完整性和可靠性。

CanSM 模块负责 CAN 网络的控制流抽象。一个 ECU 可以在车辆中拥有不同的通信网络。每个网络必须使用唯一的网络句柄进行标识。ComM 模块请求网络的通信模式。根据 AUTOSAR 工具中完成的配置,哪个句柄分配给什么类型的网络?对于 CAN,它使用 CanSM 模块。CAN 状态管理器规范定义了此模块的主要功能。技术上,CanSM 用于根据 Communication Manager (ComM) 模块的请求修改 CAN 网络的通信模式。

CanSm_RequestComMode 函数

此函数用于请求对指定 CAN 网络(NetworkHandle)的通信模式更改。它会触发请求以将通信模式更改为 ComM_Mode。

BSWM (基本软件模式管理模块)

基本软件管理器负责监督各种基本软件模块(BSW)的初始化、配置和协调,这些模块为车辆中的电子控制单元(ECU)的操作提供基本服务和功能。

EcuM (ECU 管理模块)

EcuM 在 AUTOSAR 中负责管理个别 ECU,监督其操作,包括通信接口和协调。它与 ComM 和 CanSM 等模块协作,进行系统集成。ECU 管理模块是一个基本软件模块,管理 ECU 状态的常见方面。在引导程序和 C 初始化代码完成初始化序列后,第一个从 main() 调用的 API 是 EcuM_Init()。

ECU 管理器 (EcuM) 模块:

初始化和去初始化操作系统和 RTE、SchM 和 BswM 以及一些基本软件驱动模块。

根据请求配置 ECU 的 SLEEP 和 SHUTDOWN。

管理 ECU 上的所有唤醒事件。

通信模式

完全通信(Full Communication)

在完全通信模式下,ECU 积极参与网络中的数据交换。它发送和接收消息,响应通信请求,并与其他 ECU 合作以实现系统功能。完全通信模式通常在正常操作条件下启用,当 ECU 需要主动与其他组件通信时。

静默通信(Silent Communication)

静默通信模式允许 ECU 被动地监控网络活动,而不主动发送或接收消息。在静默通信模式下,ECU 可以监听网络流量并收集相关信息,而不会对通信流产生贡献。当满足特定条件时,例如收到关闭请求或进入低功耗状态,ECU 会切换到静默通信模式。在此模式下,ECU 停止主动传输数据,但仍保持与网络的连接,以监控正在进行的通信。在静默通信模式中,ECU 观察网络流量并收集相关信息,为即将到来的关闭过程做准备。这个阶段允许 ECU 确保所有必要的数据传输完成,并在关闭前执行任何所需的清理任务。

无通信(No Communication)

无通信模式涉及 ECU 完全脱离网络通信。在此模式下,ECU 既不发送也不接收消息,保持与网络隔离。无通信模式通常在 ECU 进行维护、修理,或在长时间内不需要参与网络活动时启用。在这种模式下,ECU 进入关闭阶段,断开与网络的连接,并关闭电源或进入低功耗状态。从静默通信到关闭的过渡标志着关闭序列的最后一步。

   
86 次浏览       4
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证

最新活动计划
大模型RAG、MCP与智能体 8-14[厦门]
图数据库与知识图谱 8-28[北京]
OCSMP认证:OCSMP-MBF 8-29[北京]
基于 UML 和EA进行分析设计 9-9[北京]
软件架构设计方法、案例实践 9-24[北京]
需求分析师能力培养 10-30[北京]
 
 
最新文章
iPerson的过程观:要 过程 or 结果
基于模型的需求管理方法与工具
敏捷产品管理之 Story
敏捷开发需求管理(产品backlog)
Kanban看板管理实践精要
最新课程
基于iProcess的敏捷过程
软件开发过程中的项目管理
持续集成与敏捷开发
敏捷过程实践
敏捷测试-简单而可行
更多...   
成功案例
英特尔 SCRUM-敏捷开发实战
某著名汽车 敏捷开发过程与管理实践
北京 敏捷开发过程与项目管理
东方证券 基于看板的敏捷方法实践
亚信 工作量估算
更多...