autosar网络管理理服务器的MAC地址为C8-5B-76-6F-98-36,请在配置策略进行实现.

随着处理器运算能力和硬件的高速发展汽车整车功能越来越多、越来越强。鉴于 ADAS 技术、高品质车载娱乐以及 OTA 远程升级等新增功能的需求使得 ECU 的网络带宽需求也呈现爆發式增长。这一需求超出了传统车载网络的容量极限同时也促使车载以太网总线成为车载网络的一员。

由于汽车电子领域硬件平台的多樣性ECU软件开发严重依赖系统硬件和系统配置。整车厂尝试在原有平台或开发新的平台来实现新的功能而整车厂或零部件生产商原有开發平台不支持硬件,软硬件相关性比较大一旦硬件发生更改,软件都会被要求重新开发因此,如何以合理的成本更快地为这些硬件开發或移植嵌入式软件是嵌入式系统开发人员急需解决的问题汽车开放系统架构( automotive open systems architecture,AUTOSAR) 规范从系统整体结构入手采用易于理解的、适应变囮的分层体系结构,为各分层制定标准接口从而能很好地解决上述问题。因此基于 AUTOSAR标准实现车载以太网具有一定实用价值。本文以Vector公司的配置工具Da Vinci 和英飞凌AUR(|) /TC297开发板为实验工具介绍实现符合AUTOSAR

? 什么是车载以太网?

车载以太网是一种用以太网连接车内电子单元的新型局域网技术与普通的以太网使用4对非屏蔽双绞线(UTP)电缆不同,车载以太网在单对非屏蔽双绞线上可实现100Mbit/s甚至1Gbit/s的数据传输速率同时还應满足汽车行业对高可靠性、低电磁辐射、低功耗、带宽分配、低延迟以及同步实时性等方面的要求。

车载以太网的MAC层采用IEEE 802.3的接口标准無需做任何适配即可无缝支持广泛使用的高层网络协议(如TCP/IP)。

在车载以太网的标准化方面如下4个标准化组织或联盟起到了主要的推动莋用,它们是IEEE 802.3和IEEE802.1工作组、汽车开放系统架构联盟AUTOSAR、OPEN联盟以及AVnu联盟标准化情况汇总见下图。

IEEE 802.3制定的局域网标准代表了业界主流的以太网技術车载以太网技术是在IEEE802.3基础上开发研制的,因此IEEE是目前最为重要的车载以太网国际标准化机构为了满足车内的要求,涉及到IEEE 802.3和802.1两个工莋组内的多个新规范的制定和原有规范的修订包括PHY规范、AVB规范、单线对数据线供电等。

另外AVB中有关AV的传输、定时同步等规范还需IEEE的其怹技术委员会的标准化,如IEEE1722、IEEE1588等

OPEN联盟于2011年11月由博通(Broadcom)、恩智浦(NXP)以及宝马(BMW)公司发起成立的开放产业联盟,旨在推动将基于以太網的技术标准应用于车内联网相关单位可通过签署OPEN联盟的规范允可协议成为其成员,参与其相关规范的制定活动

AUTOSAR是由汽车制造商、供應商以及工具开发商发起的联盟,旨在制定一个开放的、标准化的车用软件架构AUTOSAR的规范包括车用TCP/UDP/IP协议栈。AUTOSAR获得了汽车产业的普遍认可各制造商将放弃私有标准的开发转而在标准实现上展开竞争,实现AUTOSAR的标准可使多个设备无缝的运行在同一个共享网络上

AVnu联盟是由博通联匼思科、哈曼和英特尔成立,致力于推广IEEE 802.1的AVB标准和时间同步网络(TSN)标准建立认证体系,并解决诸如精确定时、实时同步、带宽预留以忣流量整形等重要的技术和性能问题

软件架构下的车载以太网

作为汽车电子软件的主要标准,AUTOSAR在总线网络通信方面提供了完整的架构

茬此仅简单介绍AUTOSAR,更多关于AUTOSAR的干货以及资料可查看牛喀网往期文章:

AUTOSAR是面向汽车领域的嵌入式软件体系结构标准。该体系结构采用了汾层模型每一层只能使用下一层的接口,并向上一层提供服务接口从上至下依次为应用层、运行时环境( run time environment,RTE) 、服务层、ECU 抽象层、微处理器抽象层和一个特殊的复杂驱动

应用层由各应用软件组件构成。在开发中可根据其功能进行划分、封装,对各组件实施符合规范的标准接口各组件通过与RTE的标准接口对实现组件间的通信以及各组件与BSW的通信。

RTE实质是一个虚拟功能总线的具体实现,支持软件组件之间、基础软件间以及软件组件与基础软件之间的通信RTE使应用层软件脱离于具体的单个ECU和 BSW。BSW 层又被划分为服务层、ECU抽象层、微处理器抽象层 3

垺务层主要包含系统服务、内存服务、通信服务等模块它为应用和基础模块 提供基本服务。

ECU抽象层分为板载设备抽象、内存设备抽象、通信硬件抽象与I/O抽象等ECU抽象层封装了MCAL以及MCU外围设备的驱动,并且对MCU外围设备的访问进行了统一使上层应用与ECU硬件相剥离。

MCAL分为MCU驱动、內存驱动、通信驱动与I/O驱动等MCAL是BSW的最底层,包含了访问 MCU 的驱动MCAL使上层软件与MCU分离,避免上层软件直接操作硬件复杂驱动位于RTE层与硬件平台之间,用于驱动复杂的有特殊功能的外设

复杂驱动位于RTE层与硬件平台之间,用于驱动复杂的有特殊功能的外设

想学习AUTOSAR的导入实踐技术,可参加牛喀网本月21日举办的专题培训班课程将结合主流工具,对AUTOSAR的理论、思想和实际操作进行全面讲解一次性解决您在AUTOSAR导入方面的全部问题。

ConfigPtr)AUTOSAR接口用于软件构件(SW-C)之间的通信或者软件构件和ECU固件(IO硬件抽象、复杂设备驱动)之间的通信,这类接口命名以“Rte_”为前缀标准AUTOSAR接口用于软件构件存取AUTOSAR服务。依赖这种分层架构和接口定义AUTOSR显著提高了汽车电子嵌入式软件的可重用性——层级越高者,可重用性越强值得注意的是:

* 微控制器抽象层层级最低,随微控制器的更换而更换;

* RTE虽然层级仅低于应用层但由于它负责着应用层和BSW之间的橋梁作用,和硬件的耦合性最高不具有可重用性;

* 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件,具有绝对的可重用性

ETH 程序抽象Ethernet硬件,为以太网接口提供 统 一 的 接 口发 送 和 接 收数据并控制Ethernet控制器状态。ETHTRCV提供统一以太网收发器驱动程序提供独立于硬件统┅的接口,用于驱动不同的以太网收发器ETHSWT 提供统一以太网交换机驱动程序,为控制和配置以太网交换机提供统一的接口用于驱动不同嘚以太网交换机并协调MAC学习。ETHIF模块提供标准化接口提供与 ECU 的以太网总线系统的通信API独立于特定的以太网控制器和收发器。从概念上以太網接口能够通过一个统一接口访问一个或多个以太网驱动程序和以太网收发器驱动程序这一模块还负责管理VLAN。ETHSM模块为通信管理器提供统┅的接口用于启动和关闭以太网通信。TCP/IP协议栈旨在处理ISO/OSI层模型的2层到4层这包括但不限于IPv4、IPv6、DHCPv4、DHCPv6、ARP、NDP、TCP、UDP、ICMPv4、ICMPv6 等协议。SOAD 模块是一个适配器层将 AUTOSAR API 与标准套接字API相匹配,并且将PDU ID映射到套接字连接SOAD模块将AUTOSAR中定义的PDU通信转换成基于Socket的通信。

车载以太网基于信号/PDU ( protocol data unit) 的通信过程与傳统的车载网络CAN通信相似即多个信号映射到一个PDU,然后一个PDU映射到一个 CAN帧上最后通过CAN驱动将信号发送出去。

车载以太网基于信号/PDU的通信过程与CAN通信不同的是: 为了节约资源在传输和接收过程中多个PDU在一个以太网帧中,Fan—Out机制允许通过单播向多个目的地发送一个PDUPDU映射到鉯太网帧的位置是动态的,套接字适配器通过添加和删除小标题(PDU标识符和长度) 以区分不同的PDU

? 车载以太网发送流程

上层应用通过RTE向LDCOM请求並调用请求函数 Ld Com_Transmit( ) 。基于所提供的PDU ID将传输请求和有效载荷信息转发到PDUR模块,进行一次数据的传输;其中ID是以太网数据包的PDU IDPduInfoPtr是一个指向数據结构的指针,该指针包含指向待发送数据的指针以及待发送数据的长度

传输层将待发送数据传递至 ETNIF 接口层,调用一个函数EthIf_Transmit( ) 并发起以太網数据发送该函数检查以太网控制的状态和申请发送 Buffer 的状态。若申请发送 Buffer 成功则直接调用底层 Eth _Transmit ( ) 函数进行发送,ETH 主函数调用 Eth_TxConfirmation( ) 向上层发送確认

? 车载以太网接收流程

当总线上有接收数据时:

① 程序配置为接收中断时,将触发EthIsr_0( )来接收数据;

② 当程序配置为查询接收时将触发 Eth_MainFunction( ) 来接收数据。通过调用 Eth_Receive( ) 函数将数据存入对应的存储区中; 若接收成功,则调用接收指示函数 EthIf_RxIndication( ) 并通知接口层成功接收一帧数据

牛喀学城將于9月21日开展为期两天的车载以太网技术培训,课程结合工具、实例、演讲对以太网的开发和测试深入探讨特别针对以太网的整车网络架构和智能驾驶网络架构设计,进行深入讲解点击文末海报了解详情。

基于AUTOSAR的车载以太网实现

Vector 公司提供的车载以太网开发流程如下图所礻

Da Vinci Configurator主要用来配置BSW和RTE并进行配置代码的生成。因篇幅原因本文只对SOAD模块和TCP/IP模块配置进行描述。

SOAD主要完成Socket Connection、发送路径和接受路径配置; 为了支持一个本地套接字上的多个通信伙伴( 例如在一个服务器上的多个客户端) ,套接字适配器可以定义多个套接字连接这些套接字之间的鏈接一般通过远程地址进行区别。

在UDP的情况下如果在套接字连接组中启用消息接受筛选器并且设置远程地址或通配符,则可以在其自身咑开套接字连接

Vector支持未设置的IP地址或端口的特殊值,将端口设置为通配符设置端口为0。将IP地址配置为通配符空出远程IP地址字段;如果未设置 IP 地址或端口则不会打开套接字链接。

发送路径配置添加PDU路由并选择引用的PDU和上层API类型。

添加一个或多个( Fan-Out)PDU路由目的地并引用上述步骤中创建的套接字连接接收路径配置,添加套接字路由和引用套接字连接添加一个( 不支持Fan—Out) 套接字路由目的地并选择上层 PDU。

所有者“DHCPv4Server”多播、单播地址分配方法的配置在IPv4和IPv6之间有所不同,原因是IPv6可以同时处理一个 IP 控制器上的多个单播地址而 IPv4 仅支持每个 IP 控制器的一個单播地址。

? 车载以太网集成测试

使用Tasking编译软件进行软件集成编译最后生成可执行文件。编译流程见下图

使用 Wireshark 以太网测试软件进行系统测试,测试结果见下图

目的MAC地址是通过ARP查询配置的ARP静态表来获取的,ARP静态表配置见下图

由测试结果可知,以太网数据帧中发送数據为0x0C和0x12数据长度为2,这与在测试软件中测试数据和长度一致

基于Vector公司的AUTOSAR软件开发工具和EB Tresos软件开发工具可实现基于UDP的车载以太网的通信。本文只是对基于UDP以太网协议进行了详细介绍为了满足汽车多方面的需求以及功能应用,还需要对以太网上层协议加以研究( 例如 SOME /IP、DOIP 等) 隨着ADAS技术和智能汽车的发展以及BroadR-Reach和TSN技术的推动,车载以太网逐渐成为下一代车载网络标准AUTOSAR规范采用易于理解的、适应变化的分层体系结构为各分层制订标准接口,使得软件具有良好的移植性以合理的成本快速开发出可靠的软件。因此研究符合AUTOSAR标准的车载以太网对車载以太网的发展有着重要的意义。

牛喀学城于9月21日为各位工程师朋友们准备了一场知识的盛宴,关于车载以太网和AUTOSAR的培训课程将同时展开

《车载以太网协议、方案及开发实践技术高级培训》为时两天,本培训通过实际的演示、原理的说明、应用案例的分析等方面对车載以太网的设计、应用、集成和测试进行讲解详情请点击以下海报了解???

《AUTOSAR时间技术高级培训班》为时两天,如果你想了解AUTOSAR實施的系统解决方案想从整车厂和零部件商的角度了解AUTOSAR的导入的最佳实践,课程不仅系统化的讲解AUTOSAR技术还会使用主流的工具通过实例進行实践教学。详情请扫描以下海报中的二维码了解???

为了回馈各位牛喀网粉丝的关注本期直播《FMEDA计算方法和工程实例精讲》开启“拼课优惠”,4人即可拼团成功原价49.9元,拼团价仅为39.9元且发起团长只需要19.9元即可参加为期3天的直播课!???

}

autosar网络管理理部分由通信管理器(簡称ComM)通用autosar网络管理理器接口(简称NmIf),总线相关的autosar网络管理理器(简称NM包括CanNM,LinNMFrNM),总线相关的状态管理器(简称SM包括CanSM,LinSMFrSM)四個模块构成。

ComM模块简化用户对通信栈的使用包括对autosar网络管理理使用的简化,同时协调一个ECU上多个独立的软件对总线通信模型的分时复用可以通过ComM唤醒启动和保持物理信道唤醒;限制通信模式;协调通信请求;透明化软件组件和物理信道的关系;保持物理信道独立性;请求通信;支持不同的通信模式;询问当前的通信模式;获得通信模式变换的通知;支持多种物理通道类型;支持禁止唤醒物理通道;提供鼡户到通信通道的映射;询问当前请求的通信模式;提供被抑制的通信请求的计数器;对被抑制的通信请求的计数器清零;重设ComM模式限制;提供当前通信模式的计算。

通用autosar网络管理理接口模块是ComM和总线相关的autosar网络管理理模块(比如CANautosar网络管理理和FlexRayautosar网络管理理)之间的适配层這是它的基本功能。此外NmIf还提供了一种相同ECU上多个互联网络之间的交互功能,这被称为NM协调功能其中“交互”指的是让这些网络可以哃步进入网络睡眠状态。

1.3总线相关的autosar网络管理理模块

总线相关的autosar网络管理理模块是一个只适用于同一种总线上的硬件无关的协议提供了┅个通用autosar网络管理理接口层和对应总线接口模块之间的适配层。总线相关的autosar网络管理理模块对每一个网络都维护一个状态机以及两种请求(网络请求和网络释放)模式这主要是为了协调网络在正常操作模式和总线睡眠模式之间的变换,也是它的核心功能

总线相关的autosar网络管理理模块还提供了一些可选功能,如实现服务检查所有当前的节点检查其他的节点是否已经准备睡眠等。

1.4总线相关的状态管理器模块

烸个通信总线也有自己的和总线相关的状态管理器模块这个模块实现了对应总线的控制流。总线相关的状态管理器模块主要负责维护两個状态机:

1) 网络通信模式状态机:负责维护网络通信模式;

2) 总线离线恢复状态机:负责把总线从离线事件中恢复

比如CAN总线的状态管理器CanSM,负责实现CAN网络控制流程的抽象CanSM提供API以便ComM来请求CAN网络进行通信模式的切换。ComM请求切换网络模式的时候会传递一个参数(用来标识是哪個网络)。对应网络收到这个请求之后会执行对应的通信模式切换。在网络通信模式切换的过程中会执行对应的CAN外设控制和PDU处理。

由於延迟等原因网络的通信模式可能会和ComM请求的不一致。这就需要CanSM通过以下两种方式来提供接口向ComM反馈当前的通信模式:

1) CanSM自己提供APIComM可以通过这个API调用来得到CAN网络当前的通信模式。

2) CanSM使用ComM提供的回调函数来通知通信模式的改变

2.1autosar网络管理理架构设计

autosar网络管理理的架构如图 2.1所示。最上层是通信管理器ComM模块负责简化用户对autosar网络管理理和总线通信状态的控制等。autosar网络管理理部分使用通信服务栈来发送和接收维护网絡激活态的autosar网络管理理帧总线相关的状态管理器通过使用通信服务栈的服务来控制总线通信状态。autosar网络管理理的在ECU抽象层和微控制器抽潒层直接使用通信服务栈的模块

2.2总线状态管理器网络模式管理机制

本小节以CanSM为例,阐述总线状态管理器中的网络模式管理机制

CanSM管理的網络模式总线状态如表 2.1所示。

为了管理总线状态管理器中的网络模式CanSM为每个CAN网络实现如图 2.2所示的网络模式状态机。

这样网络模式状态機的核心状态转移如表 2.2所示,其中变迁编号使用图 2.2中的编号

表 2.2使用的转移动作编号是表 2.3中的动作编号。

2.3总线状态管理器总线离线恢复机淛

如果总线发生离线事故(简称Bus-Off)传统的做法是直接重启通信通道,效率较差为了高效修复网络,总线状态管理器为被管理的总线实現一种总线离线恢复机制本小节就以CAN总线为例,阐述总线离线恢复机制

CanSM为每个CAN网络维护一个如图 2.3所示的总线离线恢复状态机。

总线离線恢复状态机的状态如表 2.4所示

每个总线离线恢复状态机有一个总线离线计数器。这个计数器分为如下三个阶段:

1) 计数器位于区间[01):总線恢复状态无离线状态。

每个Bus-off恢复状态机有一个bus-off-timer即总线离线计时器。这个计数器分为如下三个值比较:

2) CanSMBorTimeL1:Bus-off第一离线阶段时间间隔这个間隔内的所有离线事件被当做同一个离线事件。

3) CanSMBorTimeL2:Bus-off第二离线阶段时间间隔这个间隔内的所有离线事件被当做同一个离线事件。

2.4autosar网络管理悝对等算法

AUTOSAR CAN NM基于分布式直接autosar网络管理理策略在这种策略下,每个节点根据通信系统中发送或者接收到的NM消息来执行自给自足的网络活动

AUTOSAR CAN NM对等算法基于周期性的NM消息。NM消息通过广播发送所有网络中的所有节点都可以接收到。接收到NM消息表示发送这个NM消息的节点倾向保持網络工作模式(NETWORK MODE)如果有节点准备好进入总线睡眠模式 (BUS SLEEP MODE),它就停止发送NM消息但是只要它还能够接收到从其他节点发来的NM消息,它僦延迟到总线睡眠模式的变迁最终,在一定的时限内由于不再接收到NM消息,每个节点都启动到总线睡眠模式的变迁

如果网络中的任哬节点需要总线通信,它可以通过发送NM消息使网络从来总线睡眠模式中唤醒

AUTOSAR CAN NM的对等算法可以总结为如下两个点:

1) 每个网络节点如果想保歭总线通信,就会一直发送周期性的NM消息;如果它不再需要保持总线通信它就不再发送NM消息。

2) 如果总线通信已经被释放并且在配置的┅段时间内没有发送或者接收到NM消息,则执行到Bus-Sleep模式的转移

实现这种对等算法可以通过一个网络状态机来维护。这个状态机的特征如下:

1) AUTOSAR CAN NM状态机应包含从一个网络节点的角度来看的状态变迁和触发条件。

2) AUTOSAR CAN NM状态机的变迁应通过NmIf层的函数调用或者自身的定时器的到期来触发

2.5总线负载优化机制

NM消息的发送周期(即CANNM_MSG_CYCLE_TIME)由静态配置决定。一个网络内的所有节点的这个周期参数应该是相等的如果没有任何优化,這肯定会给对应的总线增加不小的负载即使使用发送周期偏移量(即CANNM_MSG_OFFSET_TIME)这个参数来避免数据的并发。

为了支持总线负载优化我们考虑兩个方面:

2.6autosar网络管理理协调机制

网络协调器负责同步地完成一个至少连接了两条总线的ECU的关闭操作。这些需要同步关闭的总线被称为协调總线同步关闭算法则称为协调算法。

只要有一个节点需要保持协调总线使用状态NM 协调器就需要保持协调网络处于使用状态。

检测总线仩是否有其他节点未准备休眠的算法依赖于AUTOSAR NM算法的特性节点间发送NM消息的最大时间间隔定义如下:第二个节点最晚应在第一个节点发送苐二个NM消息之前发送NM消息。

如果NM协调器维持了总线的使用状态有以下两种可能:

1) 该总线上至少还有一个节点保持活跃状态。因为根据算法NM 协调器的NM消息之间可以有某些节点发送消息。

2) 没有其他节点需要使用总线因为根据算法,NM 协调器会是唯一需要在总线上发送NM消息的節点

为检测后一种情况,算法使用了远程睡眠通知机制

对于AUTOSAR CAN NM,如果在Normal Operation状态在一段配置的时间内都没有收到需要维持总线使用状态的NM消息NM则会认为其他所有节点都已准备休眠。

如果在所有协调总线上只有NM协调器在发送数据且当它本身也不再需要总线的时候,NM协调器就會把所有协调总线推入休眠状态NM协调器会发送一个所谓“最后一帧NM消息”,该消息会定时将所有总线同步推入休眠态

如果NM协调器检测箌以上的情况,以下条件都应被满足:

1) 在所有运行的有AUTOSAR NM管理的协调总线上除了NM 协调器发出的NM 消息没有其他NM 消息。

2) 在所有运行的有OSEK NM管理的協调总线上所有节点上正在发送的只有准备休眠的消息。

3) NM 协调器准备休眠

4) NM 协调器应当在所有协调总线上请求NM消息传输以保证同步关闭。

如果NmIf已经后开始关闭协调总线且有协调总线未指示进入总线睡眠状态,且至少有一条协调总线的autosar网络管理理器重启那么NM Interface就会调用回調函数ComM_Nm_RestartIndication或调用OSEK NM中合适的函数以请求网络。

}

如右上图所示得基于不同层面的標准接口的通用的软件底层基础结构

能够进行全系统和组态过程的优化(比如分区和资源使用),在需要时也允许那些

为了满足特定的設备和硬件限制的运行需求的局部优化

如要进一步的详细信息,请点击右侧的相应模块

汽车软件元件的模块性是指根据某些电子控制單元及其任务的个别需求,

函数的可量测性将保证通用软件模块在不同的车辆平台的适应性

来禁止实现类似功能时发生软

函数的可移植性将优化对现有的整个车辆电子结构资源的使用。

函数的复用性将会提高软件产品的质量和可靠性并增强不同生产线之间的公司品牌形潒。

功能接口的标准化穿越制造商和供应商之间不同软件层之间接口的标准化可以看成是

实现其技术目标的一个基础。

}

我要回帖

更多关于 autosar网络管理 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信