Autosar & OSEK 网络管理学习笔记

网络管理的意义

1.使网络中的ECU节点有序地睡眠和唤醒，在没有通信需求的时候睡眠，可以节约整车电池的电量

2.保证网络通信的稳定性

Autosar 与OSEK 的区别

开发基准不同，Autosar 是基于整车开发的，OSEK 是基于 ECU 开发的

白话来讲，Autosar 可以支持一套软件，来控制多种类型的ECU，比如之前A 厂家的ECU 可以被很容易的被B 厂家的ECU 所替代，付出的代价比较小

如果使用OSEK 开发的话，ECU 的替代会产生一系列的软件更新，付出的代价比较昂贵

Autosar同步休眠方式 更简单

OSEK同步休眠时刻是所有节点都发送Ring请求休眠帧，且收到其它节点的Ring确认休眠帧。而AutoSar的同步休眠时刻是所有节点都停发NM帧，且不能收到其它节点的NM帧。比较而言，AutoSar要简单一些。

OSEK令牌环中有一个节点异常，其它节点就要重新建立环才能维持正常网络状态，策略比较复杂。而AutoSar网络管理中，一个节点异常时不影响其它节点的网络状态。比较而言，AutoSar要简单一些。

Autosar 的目标

1. 满足未来汽车的需求，如可用性和安全性、软件升级更新、可维护性等

2. 增加软件的灵活性和可扩展性来实现软件的集成和整合

3. 实现商用现成的跨产品线的软件硬件

4. 控制产品和流程的复杂度和风险

5. 优化成本

Autosar & OSEK 关系
OSEK 中的操作系统被 Autosar 所包括

Autosar 开发
基本上就是RTE 层的开发，RTE 层是应用层与内部ECU 之间通信的桥梁

唤醒方式
OSEK 为逻辑环唤醒
唤醒后建立逻辑环过程：

1. 控制器唤醒后想参与网络的节点会先发Alive报文申请加入逻辑环。

2)逻辑环建成后，各节点按顺序发Ring报文向后续节点传递“令牌”。

同步休眠过程：

1)如果逻辑环中有节点想休眠，就设置Ring报文中的Sleep.Ind指示位。

2)当逻辑环中所有的节点都设置了Sleep.Ind指示位，也意味着任何节点接收到所有其它节点的Sleep.Ind指示位。

3)逻辑环中所有的节点设置Sleep.Ack指示位

4)任何节点接收到所有其它的节点的Sleep.Ack指示位

5)所有节点同步进入等待睡眠状态

6)tWaitBusSleep时间内没有收到唤醒时间，所有节点同步进入睡眠状态。

AUTOSAR 分布式唤醒

AutoSar基于分布式策略，每个节点根据通信系统中发送或者接收到的NM消息来执行自给自足的网络活动。NM消息通过广播发送，所有网络中的所有节点都可以接收到。接收到NM消息表示发送这个NM消息的节点倾向保持网络工作模式（NETWORK MODE）。如果有节点准备好进入总线睡眠模式 （BUS SLEEP MODE），它就停止发送NM消息，但是只要它还能够接收到从其他节点发来的NM消息，它就延迟到总线睡眠模式的变迁。最终，在一定的时限内，由于不再接收到NM消息，每个节点都启动到总线睡眠模式的变迁。如果网络中的任何节点需要总线通信，它可以通过发送NM消息使网络从来总线睡眠模式中唤醒。概括如下：

1. 每个网络节点如果想保持总线通信，就会一直发送周期性的NM消息；如果它不再需要保持总线通信，它就不再发送NM消息。2) 如果总线通信已经被释放，并且在配置的一段时间内没有发送或者接收到NM消息，则执行到Bus-Sleep模式的转移。

Autosar 与OSEK 的特点

AUTOSAR架构的主要特点是：

1、模块化和可配置性

2、标准化接口

3、提出了RTE的概念

4、标准的测试规范

OSEK 的特点：
OSEK规范为实现其制定的初衷并满足汽车控制领域对系统安全性和节省有限资源的特殊要求，制定了系统而全面的操作系统规范。

其特点主要有以下几个方面：

1. 实时性

2. 可移植性

3. 可扩展性

Autosar核心内容

AUTOSAR标准有四个核心内容：

1. ECU软件构架

2. 软件组件（software components）

3. 虚拟功能总线（Virtual Functional Bus）

4. AUTOSAR设计方法（Methodology）

报文格式

OSEK:

AUTOSAR:

OSEK网络帧PDU包括自己地址，目标地址（下一个令牌环目标），命令状态，用户选择数据。而AutoSar网络帧PDU只包括自己地址，少量控制信息，用户选择数据。内容简单的多。

流转状态

OSEK:
总的来说NM包含3个大的状态，分别为NMOff，NMOn，NMShutDown。

ECU上电以后处于NMOff状态，通过任务调用StartNM，启动NM，这时候NM就开始运行，直到调用StopNM接口，状态又会跳到NMShutDown，进而进入NM关闭状态。

如果进入NMOn状态，又会按照图6所示状态进行转换，首先是进行初始化，进行一些网络配置，然后在有通信请求的时候处于NMAwake的状态，没有通信请求的时候就进入NMBusSleep的状态。

AUTOSAR:
（1）Network Mode

Network Mode又包括三个内部状态

1. Repeat Message State
2. Normal Operation State
3. Ready Sleep State

①Repeat Message State

这个模式被用来确保从Bus-Sleep or Prepare Bus-Sleep到Network Mode的节点被总线上面其他节点发现。这个状态可以用来检测总线上的节点。
当进入Repeat Message State时，节点应该开始传送NMPDUs。
在Repeat Message State时，当NM-Timeout Timer溢出，CanNm模块应该重载Timer。
CanNm模块应该在Repeat Message State 下保持一段时间，这段时间可以通过CANNM_REPEAT_MESSAGE_TIME来进行配置。
当离开Repeat Message State的时候，如果节点需要通信，则进入Normal Operation State；如果节点不需要通信，则进入Ready Sleep State。并且清空Repeat Message Bit。

②Normal Operation State

这个状态可以保持总线处于唤醒状态。从Ready sleep state进入这个状态的时候应该发送NMPDUs。
在Normal Operation State当NM-Timeout Timer溢出，CanNm模块应该重载Timer。
如果节点不需要使用通信，则网络应该被释放，节点应该进入Ready Sleep State。
如果节点接收到Repeat Message Request Bit，则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State，则该节点进入Repeat Message State并且设置Repeat Message Request Bit。

③ReadySleep State

这个状态是为了如果本节点已经准备释放总线，而其他节点还需要使用总线的时候，在这个状态下等待其他总线上的节点进入Perpere Bus-Sleep Mode。进入这个状态之后，CanNm模块应该停止NMPDUs的传送。
如果NM-Timeout Timer溢出，节点将会进入Prepare Bus-Sleep Mode。
如果该节点需要使用总线，则节点进入Nomal Operation State。
如果节点接收到Repeat Message Request Bit，则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State，则该节点进入Repeat Message State并且设置Repeat Message Request Bit。

（2）PrepareBus-Sleep Mode

这个状态是为了等待总线上的所有节点能够在进入Bus-Sleep Mode之前，有时间停止节点的active状态如清空队列中为发送的报文。在Prepare Bus –Sleep Mode下，所有节点都静默下来。

当节点进入PrepareBus Mode时，应该通知上层应用。通过配置CANNM_WAIT_BUS_SLEEP_TIME参数，可以改变节点在PrepareBus-Sleep Mode停留的时间，在这段时间之后节点将会进入其他状态。

在Prepare Bus-Sleep Mode下面接收到NMPDU或者被上层应用请求通信时，节点将进入Network Mode中的Normal operation State。

（3）Bus-SleepMode
Bus-Sleep Mode的目的是当没有消息被传送的时候可以减少能量的消耗。在Bus-Sleep Mode下面，节点可以被唤醒（如本地唤醒源和CAN线唤醒源）。CANNM_TIMEOUT_TIME+CANNM_WAIT_BUS_SLEEP_TIME两个参数在整个总线上面的节点都应该时一样的配置，保证了总线上的节点能够统一的进行休眠。

当进入Bus-Sleep Mode时候，应该通知上层应用。

在Bus-Sleep Mode下，如果成功接收到NMPDU，CAN NM模块应该调用Nm_NetworkStartIndication。

如果CanNm_PassiveStartUp被调用，则CAN NM模块进入Network Mode 中的Repeat Message State。

架构图比对

OSEK :

Autosar:

1、 Application Layer（应用层）

应用层中的功能由各软件组件SWC（software component）实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

1） 软件组件SWC（software component）

软件组件SWC（software component）是由Atomic component最小逻辑单元组成。Atomic component最小逻辑单元有Application、Sensor/actuator两种类型。其中Application是算法实现类型，能在各ECU上自由映射；Sensor/actuator是为Application提供I/O端口类型，用于与ECU绑定，但不可像Application那样能在各ECU上自由映射。数个SWC的逻辑集合组合成Composition。图2是SWC组成实例。

图 2

2）端口Ports

端口Ports是用来和其他SWC通信。通信内容分为Data elements与operations。其中，Data elements用Sender/Receiver通信方式；operations用Client/Server通信方式。图3是通信方式

图3

发送—接收端口（Sender/Receiver）用来传输数据，具有一个通信端口可以包含多种数据类型特点。但如果一个数据类型要通过总线传输，那么它必须与一个信号对应起来，数据类型既可以是简单的数据类型(integer, float)，也可以是复杂类型(array, record)。通信方式:1:n或n:1。

图 4

客户端—服务器端口（Client/Serverr）用来提供Operation服务，具有一个客户端—服务器端口可以包含多种Operation和同步或是异步通信特点，一个客户端—服务器端口可以包含多种Operations操作，Operations操作也可被单个调用。通信方式:1:n或n:1。

图 5

3）可运行实体（Runnables entities）

可运行实体（Runnablesentities），简称Runnables。可运行实体包含实际实现的函数，可以是具体的逻辑算法或是实际操作。可运行实体由RTE周期性或是事件触发调用，如当接收到数据。

图 6

2、Runtime environment层 （RTE）

中间件部分给应用层提供了通信手段，这里的通信是一种广义的通讯，可以理解成接口，应用层与其他软件体的信息交互有两种，第一种是应用层中的不同模块之间的信息交互；第二种是应用层模块同基础软件之间的信息交互。而RTE就是这些交互使用的接口的集散地，它汇总了所有需要和软件体外部交互的接口。从某种意义上来看，设计符合AUTOSAR的系统其实就是设计RTE。

SW-C之间的通信是调用RTE API函数而非直接实现的，都在RTE的管理和控制之下。每个API遵循统一的命名规则且只和软件组件自身的描述有关。具体通信实现取决于系统设计和配置，都由工具供应商提供的RTE Generator自动生成的。

在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线VFB（Virtual Functional Bus）。它是对AUTOSAR所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至ECU内部或者是与其他ECU之间的数据传输。

图 7

从图中可以看到，有三种接口描述，我们先从定义的角度来看这三种接口有什么不同。

1. StandardizedInterface（标准接口）：标准接口是在AUTOSAR标准中被标准化的接口，但是并没有使用AUTOSAR接口技术，标准接口通常被用在某个ECU内部的软件模块之间的通讯，不能用于网络通讯。

2. StandardizedAUTOSAR Interface（标准AUTOSAR接口）：标准AUTOSAR接口是在AUTOSAR标准中使用AUTOSAR接口技术标准化的接口，这样的接口的语法和语义都被规定好了，这样的接口通常使用在AUTOSAR服务中，这样的接口是基础软件服务提供给应用程序的。

3. AUTOSARInterface（AUTOSAR接口）：AUTOSAR接口定义了软件模块和BSW模块（仅仅是IO抽象和复杂驱动）之间交互的方式，AUTOSAR接口是以port的形式出现的，AUTOSAR将ECU内部的通讯和网络通讯使用的接口进行了统一。

从上边的定义中我们可以看出不同的接口使用的场景不同，及不同的模块交互会使用到不同的接口。除了将接口归类以外，这样定义究竟有什么实际的意义呢？从实际使用的角度来看，第一和第二类接口都是语法语义标准化的接口，即接口函数的数量、函数的名字、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里边定义好了。不同的公司的软件在实施这些接口的时候虽然内容算法不同，但是它们长相和功能是一致的，接口定义在AUTOSAR规范文档里边是可以查得到的。第三类接口呢，AUTOSAR仅仅规定了简单的命名规则，这类接口高度的和应用相关，比如BCU控制大灯打开的接口可以是Rte_Call_RPort_BeamLight_SetDigOut也可以是Rte_Call_RPort_HeaderLight_Output，公司可以自己定义，又比如仪表想要从CAN总线上获得车速，改接口可以是Rte_IRead_RE_Test_RPort_Speed_uint8也可以是Rte_IRead_Test_RE_RPort_Spd_uint8，这些接口必须通过RTE交互。

图 8

3、Basic software层（BSW）

虽然汽车中有各种不同的ECU，它们具有各种各样的功能，但是实现这些功能所需要的基础服务是可以抽象出来的，比如IO操作，AD操作，诊断，CAN通讯，操作系统等，无非就是不同的ECU功能，所操作的IO、AD代表不同的含义，所接收发送的CAN消息代表不同的含义，操作系统调度的任务周期优先级不同。这些可以被抽象出来的基础服务被称为基础软件。根据不同的功能对基础软件继续可以细分成四部分，分别为服务层（Service Layer），ECU抽象层（ECUAbstract Layer），复杂驱动（ComplexDriver）和MCAL（Microcontroller Absstraction Layer），四部分之间的互相依赖程度不尽相同。

• 服务层（Service Layer），这一层基础软件提供了汽车ECU非应用相关的服务，包括OS，网络通讯，内存管理（NVRAM），诊断（UDS，故障管理等），ECU状态管理模块等，它们对ECU的应用层功能提供辅助支持，这一层软件在不同领域的ECU中也非常相似，例如不同的ECU中的OS的任务周期和优先级不同，不同的ECU中的NVRAM的分区不同，存储的内容不同。

• ECU抽象层（ECU Abstract Layer），这一层软件提供了ECU应用相关的服务，它是对一个ECU的抽象，它包括了所有的ECU的输入输出，比如AD，DIO，PWM等，这一层软件直接实现了ECU的应用层功能，可以读取传感器状态，可以控制执行器输出，不同领域的ECU会有很大的不同。

• MCAL（Microcontroller Absstraction Layer），这一层软件是对ECU所使用的主控芯片的抽象，它跟芯片的实现紧密相关，是ECU软件的最底层部分，直接和主控芯片及外设芯片进行交互，它的作用是将芯片提供的功能抽象成接口，然后把这些接口提供给上边的服务层/ECU抽象层使用。

• 复杂驱动（Complex Drivers），汽车ECU中有一些领域的ECU会处理相当复杂的硬件信号，执行相当复杂的硬件动作，例如发动机控制，ABS等，这些功能相关的软件很难抽象出来适用于所有的汽车ECU，它是跟ECU的应用以及ECU所使用的硬件紧密相关的，属于AUTOSAR构架中在不同的ECU上无法移植的部分。

图10是BSW层中各个子模块说明。

4、Microcontroller层
底层驱动层是由芯片生产厂家提供。

引用：
Autosar 开发手册引用
OSEK 网络管理
四、AUTOSAR的网络通讯规范COM和网络管理NM
基于AUTOSAR标准的网络管理协议的设计
AutoSar和OSEK网络管理比较
基于AUTOSAR的网络管理精简介绍