AUTOSAR和OSEK关系及网络管理比较

  • AUTOSAR与OSEK的关系
    • AUTOSAR
    • OSEK
  • AUTOSAR和OSEK网络管理比较
    • 1. OSEK - Simplified state transition diagram of the direct NM
    • 2. AutoSAR - CanNm Algorithm
      • NM状态机
      • 报文发送与接受状态
      • 状态机时间参数
    • 3. 共同点：
    • 4. 不同点：
      • 4.1 唤醒帧类型不一样：
      • 4.2 休眠的同步算法不一样：
      • 4.3 PDU结构不一样:
  • 小结
  • 参考

AUTOSAR与OSEK的关系

AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK/VDX是基于ECU开发的操作系统标准，AUTOSAR基于整体汽车电子开发的功能标准。AUTOSAR中规定的操作系统标准就是基于OSEK/VDX，通信和网络管理虽然和OSEK有区别，但是是有继承性的。可以认为，AUTOSAR是基于OSEK/VDX发展出来的，OSEK/VDX被AUTOSAR标准软件架构所包含。

AUTOSAR

AUTOSAR（Automotive Open System Architecture，即汽车开放系统架构）的出现是为了解决汽车电子架构日益增加的ECU单元带来的复杂系统设计问题，让汽车电子系统开发更灵活，更有效率。

2003年汽车行业内的几大巨头（BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO）联合建立了AUTOSAR联盟，一起开发并建立一套真正的开放的汽车电子电器架构，也就是我们现在所说的AUTOSAR标准或者AUTOSAR架构，我们经常提到的AUTOSAR一般就是指AUTOSAR构架/标准，AUTOSAR的全称是AUTomotive Open System ARchitecture，随着多年的发展，越来越多的行业内的公司加入到了AUTOSAR联盟中，这其中有OEM（汽车整车厂），Tier1（汽车零部件供应商），芯片制造商以及工具制造商，AUTOSAR构架/标准也成为了汽车E/E设计的发展方向。

AUTOSAR架构和标准的目标是：

  1. 满足未来汽车的需求，如可用性和安全性、软件升级更新、可维护性等
  2. 增加软件的灵活性和可扩展性来实现软件的集成和整合
  3. 实现商用现成的跨产品线的软件硬件
  4. 控制产品和流程的复杂度和风险
  5. 优化成本

AUTOSAR架构的主要特点是：

  1. 模块化和可配置性
  2. 标准化接口
  3. 提出了RTE的概念
  4. 标准的测试规范

AUTOSAR标准有四个核心内容：

  1. ECU软件构架
  2. 软件组件（software components）
  3. 虚拟功能总线（Virtual Functional Bus）
  4. AUTOSAR设计方法（Methodology）

OSEK

为了解决汽车控制技术通信和网络发展多元化带来的软件移植和不同应用程序的接口协调问题，德国汽车工业界在1993年推出了OSEK（open systems and the corresponding interfaces for automotive electronics）体系，定义汽车开放式系统及接口。1994年法国标致雷诺将汽车分布式运行系统VDX（vehicle distributed executive）纳入OSEK。

在1995年召开的OSEK研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)。它主要由四部分组成:操作系统规范(OSEK Operating System,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。

此后，各软件生产厂商都相继推出了符合OSEK规范的产品。随着该规范应用的不断深入，其结构和功能不断完善和优化，版本也不断升级和扩展。目前OSEK OS2.2 , OSEK COM2.3 , OSEK NM2.3和OIL2.3已经提交ISO审议，即将成为一个国际标准。

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

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

  1. 实时性
  2. 可移植性
  3. 可扩展性

由上我们可以看出，AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK基于ECU开发，AUTOSAR基于整体汽车电子开发。AUTOSAR中规定的操作系统就是OSEK，而通信和网络管理虽然和OSEK有区别，但思路一样的。所以认为，AUTOSAR是基于OSEK提出的（但不仅基于OSEK），OSEK被AUTOSAR标准软件架构包含。

AUTOSAR和OSEK网络管理比较

1. OSEK - Simplified state transition diagram of the direct NM

  • OSEK建立逻辑环
    直接网络管理（以下简称为NM）通过发送和接收两种类型的消息来建立逻辑环：Alive message和Ring message。其中，Alive message是一个节点要加入逻辑环时要发送的消息，Ring message是网络正常工作时的环消息，是从一个节点传递给下一个节点，依次在逻辑环中传递，以表示网络中的节点正常工作。当某一节点功能不正常时，就会周期性的向网络中发送LimpHome message。

    逻辑环的建立通过一种发送“令牌（Token）”的方式来进行，按标识符由小到大的顺序进行传递，最初发送Alive message的节点（或者标识符优先级高的节点）成为逻辑环中的第一个发送节点，消息都是以广播的方式发送的，这就使得每个节点发送的消息，其他节点都可以监测到，以确定自己是否为上一个发送节点的后继节点，并更新节点的运行状态等。

    所有参与建环的ECU在建环初期，发出报文数据的第一字节都是自己的ID ，第二字节都是 0xC9 ，即协议里讲的发出指向自身的 Alive 报文，每个 ECU 都发完 Alive 报文之后，就建立起来逻辑环了，上图的后面几帧报文， ECU25 指向了 ECU17 ， ECU17指向了ECU1D， ECU1D指向了ECU21， ECU21指向ECU22 ， ECU22指向ECU25 ，ECU25 指向 ECU17 ，形成一个封闭的逻辑环，且第二字节都是 Ring 置 1 的 Ring 报文。

  • 正常建环的情况下，上一条NM报文的ID就是下一条NM报文的第一字节的数据，比如划线的3条报文，第一条报文的ID为0x19，数据的第一字节为0xE8，第二条报文的ID为0xE8，数据的第一字节为0xEE，第三条报文的ID为0xEE，数据的第一字节为0x19，所有正常建环的报文的第二字节，其Bit2置1，表示发出了正常建环的Ring报文，这就是所谓的逻辑环。

  • ECU 进入 LimpHome 状态时的情况，下图所示，在网络上只有一个 NM 节点的情况下， ECU上电后，先尝试建立逻辑环，尝试 5 次后，依旧无法建立逻辑环，则 ECU 进入 LimpHome 状态， ECU 按 TError (一般是 1000ms )的周期发送 LimpHome 位置 1 的报文，下图可以看出， LimpHome 报文的第一字节指向自己，第二字节为 0x04 。

  • OSKE网络管理的休眠过程，当我们下到 OFF 档时，控制器满足了休眠条件，就会发出睡眠指示位 (Sleep.Ind) 置 1 的 Ring 报文，如图中的第二字节数据为 0x12 的报文，当所有节点都满足休眠条件，发出 0x12 的报文后，最后一个休眠节点的下一个节点，就会发出睡眠应答位 (Sleep.Ack) 置 1 的 Ring 报文，如图中的第二字节数据为 0x32 的报文，同一网段的控制器收到这个报文后，就会进入睡眠状态，这个时候，会停止发送任何报文到总线，等待 ECU 的内部任务完成后，就会进入低功耗模式，静态电流会变得很小。

2. AutoSAR - CanNm Algorithm

NM状态机

状态机的状态类型可分为“三大三小”。其中“三大”指的是Bus Sleep Mode、Network Mode、Prepare Bus-Sleep Mode；而“三小”则值得是Network Mode下的三个子状态：Repeat Message State、Normal Operation Mode、Ready Sleep Mode。

  • Bus Sleep Mode
    当没有远程唤醒或者本地唤醒请求时，ECU的Controller应当切换至Sleep模式，电流消耗将降低至最低水平，该Mode是ECU启动时的起始状态或者是ECU睡眠时的最终状态。

    在该模式下，NM报文以及应用报文都应该被禁止发送，但是可以被网络上的报文唤醒。

    在此特意说明一点，当Transiver支持并使能了特定帧唤醒时，该ECU只会接受到特定的NM报文才会正常唤醒，否则就会一直处于休眠状态，能够不受网络上应用报文的干扰。

    如果Transiver不支持特定帧唤醒，那么网络的任意报文都可以唤醒该ECU，如果唤醒条件不满足，又会走休眠流程继续睡下去，这样“睡醒交替”的方式就是不支持特定帧唤醒的Transiver的典型特征。当然，如果整车上的NM都可以正常运作，那么就不会频繁出现这种“睡醒交替”的方式，这种方式一般都是在做测试时才会较多的体现出来。

  • Network Mode
    一旦进入Network Mode，计时器T_NM_Timeout就会启动，只要成功接收到来自总线上的NM报文或者成功发送至总线NM报文，都会将该计时器T_NM_Timeout重置。

    该模式又进一步细分为以下三种子状态，RMS、NOS、RSS。

    • Repeat Message State（RMS）

      该状态能够确保当ECU的状态机从Bus-Sleep Mode或者Prepare Bus-Sleep mode切换至Network Mode时能够及时的被网络上其他ECU节点发现，也就是告诉其他ECU，“大家注意了，我成功上线了，请多多指教！”

      当成功进入到RMS状态时，该节点就会重新发送NM报文并开启计时器T_REPEAT_MESSAGE，应用报文则需要等待第一帧网络管理报文发送之后再发送。

      当然，第一帧NM报文可以通过配置参数MSG_CYCLE_ OFFSET来延迟发送，降低在同一时间内的总线负载，这个配置参数默认是0 ，一般根据测试结果来做适当的调整。

      在计时器T_REPEAT_MESSAGE超时之前，该节点就会一直保持在该状态，否则将会离开该状态。

      在该状态下也存在着两个子状态：

      • NM Immediate Transmit State
        在该模式下，ECU的目的是快速唤醒整个网络，同时该节点将会以配置参数T_NM_ImmediateCycleTime的周期发送NM报文，而发送次数则是由配置参数N_ImmediateNM_TIMES来决定，每一次成功发送，该参数就会减1，直至为0，退出该子状态；

      • NM Normal Transmit State
        在该模式下，ECU节点将会以正常报文周期T_NM_MessageCycle的方式来发送NM报文。

    • Normal Operation State（NOS）
      只要ECU节点自身存在网络通信的需要，那么ECU就会一直工作在NOS的状态下。该状态下NM报文的发送将会以T_NM_MessageCycle的周期来发送报文，每次报文的成功发送或接收或者计时器NM-Timeout超时都会重置该计时器NM-Timeout；
      在该状态下的NM报文以及应用报文都应该正常收发通信。

    • Ready Sleep State（RSS）
      在该模式下，ECU节点应当停止发送NM报文。每次成功接受到来自网络上的NM报文，计时器T_NM_TIMEROUT 就会重置，一旦T_NM_TIMEROUT超时，那么就会离开该状态转而进入Prepare Bus-Sleep状态。

  • Prepare Bus-Sleep Mode
    一旦进入该模式，计时器T_WAIT_BUS_SLEEP就会启动。在该模式下禁止网络管理报文的发送，允许接受NM报文。应用报文已经在buffer中的一般允许继续发送，但最终应该是silent bus，该ECU的Controller的状态应当处于operational mode。一旦T_WAIT_BUS_SLEEP超时，就会进入到Bus-Sleep阶段。

  • Passive Mode
    在该模式下只接受NM报文，但不发送任何的NM报文。该模式可以通过配置得到，同时该模式应只存在于开发或者调试过程中，在正式SOP的软件中禁止出现此种模式。

报文发送与接受状态

在测试的过程中，需要针对网络管理每一个状态下的NM报文与APP报文接收与发送进行测试。如下图所示，体现了在不同NM子状态下的报文发送与接受状态。

  • Bus-Sleep阶段，只接收NM报文唤醒，不发送任何报文；
  • Pre-Bus-Sleep阶段，同样仅允许接收NM报文，对于早已在发送Buffer中的APP报文应发送完毕后立刻停止APP报文；
  • Network Mode模式，除了在Ready Sleep阶段不允许发送NM报文之外，其余阶段APP报文与NM报文正常收发；

状态机时间参数

在网络管理各子状态的切换过程中都依赖于各种计时器，相关参数总结如下。

3. 共同点：

  1. 都属于直接网络管理。
  2. 网络管理的目的都是协调各节点同步进入休眠及唤醒（主要是休眠）。
  3. 都依靠特定的网络管理CAN报文，每个节点的网络管理ID都不一样。
  4. 唤醒方法相同，第一个唤醒的节点发送网络管理帧即同时唤醒其它节点。

4. 不同点：

4.1 唤醒帧类型不一样：

  • 网络唤醒后，OSEK要求节点发出的第一帧必须是Alive类型，不能是Ring, Limphome等。
  • AutoSar只要求是网络管理帧就行，条件宽松。

4.2 休眠的同步算法不一样：

  • OSEK网络管理使用令牌环机制，令牌从网络地址低的节点传到网络地址高的节点，如果没有更高的节点，就传给最低地址节点。令牌环根据ECU的网络地址建立。每个ECU都会接受网络管理消息，只有和目的地址相同的一个节点才会得到令牌。

    唤醒后建立逻辑环过程：

    1. 控制器唤醒后想参与网络的节点会先发Alive报文申请加入逻辑环。
    2. 逻辑环建成后，各节点按顺序发Ring报文向后续节点传递“令牌”。

    同步休眠过程：

    1. 如果逻辑环中有节点想休眠，就设置Ring报文中的Sleep.Ind指示位。
    2. 当逻辑环中所有的节点都设置了Sleep.Ind指示位，也意味着任何节点接收到所有其它节点的Sleep.Ind指示位。
    3. 逻辑环中所有的节点设置Sleep.Ack指示位
    4. 任何节点接收到所有其它的节点的Sleep.Ack指示位
    5. 所有节点同步进入等待睡眠状态
    6. tWaitBusSleep时间内没有收到唤醒时间，所有节点同步进入睡眠状态。

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

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

4.3 PDU结构不一样:

  • OSEK网络帧PDU包括自己地址，目标地址（下一个令牌环目标），命令状态，用户选择数据。

    NM messages can have length of 4-8 bytes depending on manufacturer.
    Byte-1: It contains address of logical successor in the ring here. In case node is in Alive Mode or in Limphome mode , it will have the station’s own address here.
    Byte-2: It contains Network state information.
    Bit 0 - Alive State
    Bit 1 - Ring State
    Bit 2 - Limphome state
    Bit 3 - Reserved
    Bit 4 - Sleep indication State
    Bit 5 - Sleep acknowledgement State
    Bit 6 - Reserved
    Bit 7 - Reserved
    Byte-3: Reason for wake up is listed in this byte. Data is interpreted as follows
    00 - No entry
    01 - Wake Up due to Power ON/IGN ON
    02 - Wake Up due to CAN messages
    03 - Wake Up due to external events like door warning
    04 - Wake Up due to internal events like NMWakeUp
    Bytes 4-8 - Reserved

  • AutoSar网络帧PDU只包括自己地址，少量控制信息，用户选择数据。内容简单的多。

    • Bit 0: Repeat Message Request Bit
      0: 代表存在Repeat Message Request ；
      1：代表不存在Repeat Message Request ；
    • Bit 1：PN ShutDown Request Bit（PNSR）
      0：NM报文中不包含同步局部网络管理休眠请求；
      1：NM报文中包含同步局部网络管理休眠请求；
    • Bit 3：NM Coordinator Sleep Bit
      0：未被主协调NM节点请求开始同步休眠；
      1：已被主协调NM节点请求开始同步休眠；
    • Bit 4： Active Wakeup Bit
      0：节点没有唤醒过网络，属于被动唤醒；
      1：节点唤醒过网络，属于主动唤醒；
    • Bit 5: PN Learning Bit(PNL)
      0: PNC learning被请求
      1: PNC learining未被请求
    • Bit 6 PN Information Bit(PNI)
      0: NM报文中包含PN 信息；
      1:NM报文中未包含PN 信息；
      常使用到的也就Bit0，Bit3，Bit4, Bit6这4位。

小结

  1. OSEK同步休眠时刻是所有节点都发送Ring请求休眠帧，且收到其它节点的Ring确认休眠帧。而AutoSar的同步休眠时刻是所有节点都停发NM帧，且不能收到其它节点的NM帧。比较而言，AutoSar要简单一些。
  2. OSEK令牌环中有一个节点异常，其它节点就要重新建立环才能维持正常网络状态，策略比较复杂。而AutoSar网络管理中，一个节点异常时不影响其它节点的网络状态。比较而言，AutoSar要简单一些。

参考

AutoSar和OSEK网络管理比较；
CAN总线报文浅析；
AUTOSAR基础篇之CanNM;
AUTOSAR —— CAN网络管理（CanNm）；
autosar网络管理；
OSEK-NM直接网络管理一：概念部分；
OSEK直接网络管理；

AUTOSAR和OSEK关系及网络管理比较相关推荐

  1. 科普系列：AUTOSAR与OSEK网络管理比较（下）

    在上篇中我们分别在状态机和报文格式方面对OSEK和AUTOSAR网络管理进行了简单介绍,感兴趣的小伙伴请移步至文章<科普系列:AUTOSAR与OSEK网络管理比较(上)>. 三.OSEK与 ...

  2. 科普系列：AUTOSAR与OSEK网络管理比较（上）

    一.前言 汽车网络管理从根本上来说是为了省电的,基本的实现方式就是汽车在没有使用的情况下一些ECU会通过网络管理协调进入低功耗模式或者睡眠模式,从而达到省电的目的.目前主流的网络管理标准有两个,一个是 ...

  3. 汽车行业中的AUTOSAR与OSEK到底是什么，有什么区别

    最近开始接触汽车电子及汽车行业,对其中两个概念有点混淆,特此拿来对比一下. 一.AUTOSAR 现在的汽车正向着更高的安全性.经济环保性.舒适性.便捷性发展,从而为汽车电子系统带来了前所未有的复杂性, ...

  4. can bus 中spn是什么_CP AUTOSAR功能栈简介NM网络管理（Can）

    CanNM模块架构图 1,概述 CP AUTOSAR提供一种直接分布式网络管理方式,有单独的网络管理报文用于网络管理,且总线上各个节点都是平等的,相比于OSEK基于令牌的直接网络管理方式更简单易部署. ...

  5. Canoe-OSEK网络管理自动化测试脚本CAPL 这适用于主流osek nm的测试用例

    Canoe-OSEK网络管理自动化测试脚本CAPL 这适用于主流osek nm的测试用例 1.启动程序 2.加载配置文件 3.选择帧类型(标准帧或扩展帧) 4.修改配置文件,自动弹出配置文件窗口 5. ...

  6. AUTOSAR PN网络管理测试开发实践

    背景介绍 提起"匮电"二字,做测试的老司机定会虎躯一震,而根据过往经验,"网络管理"常是引起匮电的"钉子户",所以针对网络管理的验证是测试的 ...

  7. autosar网络管理_AP AUTOSAR平台设计(11)——网络管理

    点击蓝字右上角      关注置顶不迷路 Hello!大家好!欢迎来到<搞一下汽车电子>本篇是AP AUTOSAR平台设计(11)--网络管理如果觉得不错,"转发" & ...

  8. AutoSar CAN网络管理状态机理解

    AutoSar CAN网络管理状态机理解 前言 网络管理是整车控制很重要的功能.在CAN网络中通常有两种报文,应用数据帧和网络管理帧.应用数据帧只负责网络在正常工作模式下各节点的数据交互,网络管理帧控 ...

  9. AUTOSAR技术分析报告

    AUTOSAR简介 汽车电子领域的软件主要属于嵌入式软件.因此,其发展阶段类似于其他嵌入式系统的软件发展.由于受限于嵌入式硬件本身资源的匮乏,各种硬件产品的种类繁多和各自差异,以及整体嵌入式系统软件的 ...

  10. Classic AUTOSAR概述与目标

    首先,我们来讲一下 "Classic AUTOSAR的概述和目标",通过这个章节,我们详细了解下AUTOSAR的基本背景.历史发展和简单介绍,以及AUTOSAR为什么会被提出来,A ...

最新文章

  1. vue 引入bootstarp --webpack
  2. 水晶报表技术（12）——一个投票系统水晶报表应用
  3. python中语法错误-python中的语法错误是指什么
  4. Spring3中js/css/jpg/gif等静态资源无法找到（No mapping found for HTTP request with URI）问题解决--转载...
  5. Nhibernate中的连接超时时事务回滚引发异常的处理方法
  6. 【译】在您的应用中安全使用Android的篡改检测 （Using Android's tamper detection securely in your app）
  7. ansible register 用法
  8. mysql 视图 数据相加_MySQL
  9. gsoap使用心得![转]
  10. extjs4.0视频教程
  11. 误ghost后手工修改分区表来恢复数据
  12. Ubuntu 配置磁盘挂载到指定目录
  13. 美爆！《自然》公布2018年19张最震撼的科学图片
  14. Prometheus - 普罗米修斯 - 日志监控mtail尝试
  15. UE4中的LookAt
  16. cocos2d-x 音乐音效
  17. 掌财社骑士:顾比均线怎么设置？顾比均线的投资技巧介绍
  18. 论文写作学习之引言章节撰写（学习深度之眼课程笔记，侵删）
  19. 中断优先级分组与抢占优先级和响应优先级的关系
  20. 面向AI 的数据生态系统

热门文章

  1. 数字电路：数据选择器与译码器
  2. php 时间转换时间戳_php时间戳转换日期方法总结
  3. 二广高速公路4标段道路设计--武汉理工大学本科生毕业设计
  4. 无线电监测软件java_大牛干货：软件无线电的设计和测试
  5. ROS2——通信接口（十）
  6. Apollo学习笔记（一）：canbus模块与车辆底盘之间的CAN数据传输过程
  7. 在Mac电脑中配置ios模拟器
  8. JS min文件解压工具
  9. java给链表赋值_Java链表操作代码
  10. c语言实现维吉尼亚密码和希尔密码的加解密