关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
来源： 汽车ECU开发
AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK/VDX是基于ECU开发的操作系统标准，AUTOSAR基于整体汽车电子开发的功能标准。AUTOSAR中规定的操作系统标准就是基于OSEK/VDX，通信和网络管理虽然和OSEK有区别，但是是有继承性的。可以认为，AUTOSAR是基于OSEK/VDX发展出来的，OSEK/VDX被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架构和标准的目标是：
AUTOSAR架构的主要特点是：
AUTOSAR标准有四个核心内容：
为了解决汽车控制技术通信和网络发展多元化带来的软件移植和不同应用程序的接口协调问题，德国汽车工业界在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规范为实现其制定的初衷并满足汽车控制领域对系统安全性和节省有限资源的特殊要求，制定了系统而全面的操作系统规范。其特点主要有以下几个方面：
由上我们可以看出，AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK基于ECU开发，AUTOSAR基于整体汽车电子开发。AUTOSAR中规定的操作系统就是OSEK，而通信和网络管理虽然和OSEK有区别，但思路一样的。所以认为，AUTOSAR是基于OSEK提出的（但不仅基于OSEK），OSEK被AUTOSAR标准软件架构包含。1. OSEK - Simplified state transition diagram of the direct NM直接网络管理（以下简称为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 报文。
OSKE网络管理的休眠过程，当我们下到 OFF 档时，控制器满足了休眠条件，就会发出睡眠指示位 (Sleep.Ind) 置 1 的 Ring 报文，如图中的第二字节数据为 0x12 的报文，当所有节点都满足休眠条件，发出 0x12 的报文后，最后一个休眠节点的下一个节点，就会发出睡眠应答位 (Sleep.Ack) 置 1 的 Ring 报文，如图中的第二字节数据为 0x32 的报文，同一网段的控制器收到这个报文后，就会进入睡眠状态，这个时候，会停止发送任何报文到总线，等待 ECU 的内部任务完成后，就会进入低功耗模式，静态电流会变得很小。2. AutoSAR - CanNm Algorithm状态机的状态类型可分为“三大三小”。其中“三大”指的是Bus Sleep Mode、Network Mode、Prepare Bus-Sleep Mode；而“三小”则值得是Network Mode下的三个子状态：Repeat Message State、Normal Operation Mode、Ready Sleep Mode。当没有远程唤醒或者本地唤醒请求时，ECU的Controller应当切换至Sleep模式，电流消耗将降低至最低水平，该Mode是ECU启动时的起始状态或者是ECU睡眠时的最终状态。在该模式下，NM报文以及应用报文都应该被禁止发送，但是可以被网络上的报文唤醒。在此特意说明一点，当Transiver支持并使能了特定帧唤醒时，该ECU只会接受到特定的NM报文才会正常唤醒，否则就会一直处于休眠状态，能够不受网络上应用报文的干扰。如果Transiver不支持特定帧唤醒，那么网络的任意报文都可以唤醒该ECU，如果唤醒条件不满足，又会走休眠流程继续睡下去，这样“睡醒交替”的方式就是不支持特定帧唤醒的Transiver的典型特征。当然，如果整车上的NM都可以正常运作，那么就不会频繁出现这种“睡醒交替”的方式，这种方式一般都是在做测试时才会较多的体现出来。一旦进入Network Mode，计时器T_NM_Timeout就会启动，只要成功接收到来自总线上的NM报文或者成功发送至总线NM报文，都会将该计时器T_NM_Timeout重置。该模式又进一步细分为以下三种子状态，RMS、NOS、RSS。1、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，退出该子状态；在该模式下，ECU节点将会以正常报文周期T_NM_MessageCycle的方式来发送NM报文。2、Normal Operation State（NOS）只要ECU节点自身存在网络通信的需要，那么ECU就会一直工作在NOS的状态下。该状态下NM报文的发送将会以T_NM_MessageCycle的周期来发送报文，每次报文的成功发送或接收或者计时器NM-Timeout超时都会重置该计时器NM-Timeout；在该状态下的NM报文以及应用报文都应该正常收发通信。在该模式下，ECU节点应当停止发送NM报文。每次成功接受到来自网络上的NM报文，计时器T_NM_TIMEROUT 就会重置，一旦T_NM_TIMEROUT超时，那么就会离开该状态转而进入Prepare Bus-Sleep状态。一旦进入该模式，计时器T_WAIT_BUS_SLEEP就会启动。在该模式下禁止网络管理报文的发送，允许接受NM报文。应用报文已经在buffer中的一般允许继续发送，但最终应该是silent bus，该ECU的Controller的状态应当处于operational mode。一旦T_WAIT_BUS_SLEEP超时，就会进入到Bus-Sleep阶段。在该模式下只接受NM报文，但不发送任何的NM报文。该模式可以通过配置得到，同时该模式应只存在于开发或者调试过程中，在正式SOP的软件中禁止出现此种模式。在测试的过程中，需要针对网络管理每一个状态下的NM报文与APP报文接收与发送进行测试。如下图所示，体现了在不同NM子状态下的报文发送与接受状态。Bus-Sleep阶段，只接收NM报文唤醒，不发送任何报文；
Pre-Bus-Sleep阶段，同样仅允许接收NM报文，对于早已在发送Buffer中的APP报文应发送完毕后立刻停止APP报文；
Network Mode模式，除了在Ready Sleep阶段不允许发送NM报文之外，其余阶段APP报文与NM报文正常收发；
在网络管理各子状态的切换过程中都依赖于各种计时器，相关参数总结如下。3. 共同点：
都属于直接网络管理。
网络管理的目的都是协调各节点同步进入休眠及唤醒（主要是休眠）。
都依靠特定的网络管理CAN报文，每个节点的网络管理ID都不一样。
唤醒方法相同，第一个唤醒的节点发送网络管理帧即同时唤醒其它节点。
4.1 唤醒帧类型不一样：
4.2 休眠的同步算法不一样：
唤醒后建立逻辑环过程：
控制器唤醒后想参与网络的节点会先发Alive报文申请加入逻辑环。
逻辑环建成后，各节点按顺序发Ring报文向后续节点传递“令牌”。
同步休眠过程：
如果逻辑环中有节点想休眠，就设置Ring报文中的Sleep.Ind指示位。
当逻辑环中所有的节点都设置了Sleep.Ind指示位，也意味着任何节点接收到所有其它节点的Sleep.Ind指示位。
逻辑环中所有的节点设置Sleep.Ack指示位
任何节点接收到所有其它的节点的Sleep.Ack指示位
所有节点同步进入等待睡眠状态
tWaitBusSleep时间内没有收到唤醒时间，所有节点同步进入睡眠状态。
每个网络节点如果想保持总线通信，就会一直发送周期性的NM消息；如果它不再需要保持总线通信，它就不再发送NM消息。
如果总线通信已经被释放，并且在配置的一段时间内没有发送或者接收到NM消息，则执行到Bus-Sleep模式的转移。
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 4 - Sleep indication StateBit 5 - Sleep acknowledgement StateByte-3: Reason for wake up is listed in this byte. Data is interpreted as follows01 - Wake Up due to Power ON/IGN ON02 - Wake Up due to CAN messages03 - Wake Up due to external events like door warning04 - Wake Up due to internal events like NMWakeUp0: 代表存在Repeat Message Request ；1：代表不存在Repeat Message Request ；常使用到的也就Bit0，Bit3，Bit4, Bit6这4位。OSEK同步休眠时刻是所有节点都发送Ring请求休眠帧，且收到其它节点的Ring确认休眠帧。而AutoSar的同步休眠时刻是所有节点都停发NM帧，且不能收到其它节点的NM帧。比较而言，AutoSar要简单一些。
OSEK令牌环中有一个节点异常，其它节点就要重新建立环才能维持正常网络状态，策略比较复杂。而AutoSar网络管理中，一个节点异常时不影响其它节点的网络状态。比较而言，AutoSar要简单一些。
AUTOSAR —— CAN网络管理（CanNm）；关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
