精华内容
下载资源
问答
  • osek网络管理与autosar
    2021-01-05 18:18:42

    共同点:

    1. 都属于直接网络管理(以下都是以直接网络管理为例,Autosar可以不是直接网络管理)。

    2. 网络管理的目的都是协调各节点同步进入休眠及唤醒(主要是休眠)。

    3. 都依靠特定的网络管理CAN报文,每个节点的网络管理ID都不一样。

    4. 唤醒方法相同,第一个唤醒的节点发送网络管理帧即同时唤醒其它节点。

    不同点:

    1. 唤醒帧类型不一样:

    网络唤醒后,OSEK要求节点发出的第一帧必须是Alive类型,不能是Ring, Limphome等。

    AutoSar只要求是网络管理帧就行,条件宽松。

    1. 休眠的同步算法不一样:

      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模式的转移。
    1. PDU结构不一样

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

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    小结:

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

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

    更多相关内容
  • AUTOSAROSEK 网络管理比较对于共同点:1. 都是直接网络管理。2. 目的均为协调网络中各节点同步进入休眠。3. 均依靠特定 ID 段的网络管理报文,但是每个节点的报文 ID 均不一样。4. 唤醒方法相同,第一个被唤醒...
  • 该资料为原创,结合作者多年的CAN 网络管理开发经验,整理出的autosar NM和osek NM资料,适合于想学习CAN NM的朋友,和刚刚入门CAN的兄弟。
  • AUTOSAROSEK关系及网络管理比较

    千次阅读 2022-02-09 18:08:24
    AUTOSAR与OSEK的关系 ...AUTOSAR中规定的操作系统标准就是基于OSEK/VDX,通信和网络管理虽然和OSEK有区别,但是是有继承性的。可以认为,AUTOSAR是基于OSEK/VDX发展出来的,OSEK/VDX被AUTOSAR标准软件架构所包含。

    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直接网络管理

    展开全文
  • 共同点: 1. 都属于直接网络管理。 2. 网络管理的目的都是协调各节点同步进入休眠及唤醒(主要是休眠)。 3. 都依靠特定的网络...AutoSar只要求是网络管理帧就行,条件宽松。 2. 休眠的同步算法不一样: O...

    共同点:

    1. 都属于直接网络管理。

    2. 网络管理的目的都是协调各节点同步进入休眠及唤醒(主要是休眠)。

    3. 都依靠特定的网络管理CAN报文,每个节点的网络管理ID都不一样。

    4. 唤醒方法相同,第一个唤醒的节点发送网络管理帧即同时唤醒其它节点。

     

    不同点:

    1. 唤醒帧类型不一样:

    网络唤醒后,OSEK要求节点发出的第一帧必须是Alive类型,不能是Ring, Limphome等。

    AutoSar只要求是网络管理帧就行,条件宽松。

     

    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模式的转移。

     

    2. PDU结构不一样

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

    小结:

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

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

    展开全文
  • OSEK网络管理入门

    千次阅读 多人点赞 2020-04-19 23:26:23
    OSEK初级认知 有几个小朋友要玩“击鼓传花”游戏,游戏规则很简单: 1、想玩的人自己随机报个数,所有人报完后自己排个序,花从小数往大数传,最大数者传给最小数,花到谁手里谁发言:表明想继续玩还是想退出。 2、...

    以下分级纯粹个人瞎分,专业人士请忽略

    OSEK初级认知

    有几个小朋友要玩“击鼓传花”游戏,游戏规则很简单:
    1、想玩的人自己随机报个数,所有人报完后自己心里排个序,花从小数往大数传,最大数者传给最小数,花到谁手里谁发言:表明想继续玩还是想退出
    2、第一个报数的人等一段时间后看没人再报数了就可以开始传花了。
    3、花到谁手里发言前,他需要检查一下是否所有人都申请过想退出,如果是,他就通知大家:散场
    4、当然如果中途有人表明:想继续玩,那他之前所有人的申请都作废,大家重新表明态度,直到出现第一个发现所有人都提过申请退出的人,这个人才正式通知大家:散场

    初级中规则其实是为了让大家好几好回忆,理解规则后现在上数据玩真的

    OSEK中级认知

    实际场景中遇到的情况主要有以下四种情况:

    1. 正常上线、建环、传递令牌(Taken)及休眠(初级中描述的情况)
    2. 已建环有新节点插入
    3. 已建环现有节点异常掉线
    4. 上线未发现其他节点建环失败(跛足模式)

    结构说明

    • data[1]表明自己节点当前状态
      • 0x01 Alive(上线,玩游戏前自我报数过程)
      • 0x02 Ring(建环,玩游戏传花中)
      • 0x04 LimpHome(跛足,网络无人响应无法建环)
      • 0x10 SleepIndicatio(休眠申请,游戏中申请退出)
      • 0x20 SleepAcknowledege(应答申请,游戏中通知大伙散场)
      • 以上命令可以组合比如建环中想申请休眠就是0x12
    • OSEK网络管理报文CAN ID 一般为4XX,其中XX就是自己的网络ID,data[0]在Alive状态时填充自己ID,但注意[1]建环前表明身份还是靠监听CAN ID XX而不是Alive时的data[0],在Ring状态时填充传递Taken的ID
      在这里插入图片描述

    1. 正常上线、建环、传递令牌(Taken)及休眠

    注意几个点:

    • 表格中时间是时间间隔,Alive在100ms内随机响应,Ring响应间隔是100ms
    • 当轮到自己发言0x12表明休眠申请后,只需处理3种状态:
      1. Taken未到自己(即下轮发言未轮到自己)时监听到休眠应答(其他节点发22或32)则进入休眠等待(1.5s)
      2. Taken未到自己时监听到有节点不想休眠发02,则退出休眠申请状态,轮到自己时重新发起
      3. Taken到自己时监听并检查所有节点都发出过10休眠申请,则自己发32广播集体休眠,进入休眠等待(1.5s)
    • 发出32休眠应答命令1.5s内有任何报文,则退出休眠重新申请
      -在这里插入图片描述
      [ tWaitBusSleep = 1500ms ]

    2. 已建环有403新节点插入

    在这里插入图片描述

    • 新节点03发Alive表明上线,同时节点00将下家节点从07更新为03
      在这里插入图片描述
    • 03上线后监听到09有发言,就把自己的下家节点更新为09
      在这里插入图片描述
      在这里插入图片描述
    • 03上线后只有09号比自己大,就理所当然到发言时通知09,这让07发现自己被忽略了
      在这里插入图片描述
    • 07继续通知09,不再发02Ring报文,而是发01Alive广播(这就是注意[1]里的原因,Alive时data[0]也不一定代表自己),次时03发现有个07在自己和下家09之间,则更新下家为07
      在这里插入图片描述
      在这里插入图片描述

    3. 已建环现有节点403异常掉线

    • 以下图文是演示403节点掉线又上线的过程,如果403直接掉线,则400把Taken传给403超时未响应时,所有节点重新发Alive报文重新建环
      在这里插入图片描述
      在这里插入图片描述

    4. 上线未发现其他节点建环失败(跛足模式)

    在这里插入图片描述

    • 发Alive报文100m后发特殊Ring报文(正常的Ring报文data[0]应该指示下家节点,现在找不到只能填充自己节点ID)并监听网络,260ms超时后再次重发Alive报文
    • 在这里插入图片描述在这里插入图片描述

    OSEK高级认知

    网络管理分类

    • 直接网络管理(OSEK, AUTOSAR等专门网络报文进行整车节点控制唤醒休眠)
    • 间接网络管理(个人理解就是没有网络管理,IGN ON 发应用报文,OFF停发应用报文)

    (本文中提及的网络管理都是指直接网络管理

    网络管理作用(巧记:同时休眠,提供状态)

    • 协调各ECU节点同时进入休眠
    • 监控网络配置
    • 提供本身系统状态

    时间参数

    1. ECU本地唤醒(IGN等)一般要求150ms内使能CAN接收处理应用报文,并在200ms内发出第一条报文且必须为Alive报文而非应用报文,并在第一条Alive后[60~120ms]间发送第一条应用报文,在700ms内所有周期报文至少发送一次(此要求依赖车厂)
      在这里插入图片描述
      2.ECU远程唤醒(收到网络报文)一般要求50ms内发出第一帧Alive报文,并在700ms内发送完成所有周期报文
      3.ECU休眠 当节点发出休眠申请后开始监听网络,当收到休眠应答(或轮到自己广播休眠应答)后进入1500ms休眠等待时间,时间到后关闭所有发送进入休眠。未避免反复唤醒,唤醒后至少5s才能下一轮休眠
      4.ECU跛足模式 当ECU连续4次发Alive报文无法建环时,进入LimpHome模式,以1000ms周期发送LimpHome 04报文
      在这里插入图片描述
      5.时间参数在这里插入图片描述

    OSEK网络管理总结

    1、建环机制:网络管理报文ID从小到大发送,然后从最大节点到最小节点依次建成逻辑环。

    2、OSEK网络管理报文规则:ID:4xx,其中4代表此帧报文为网络管理报文。xx代表当前节点的基地址,在OSEK网络管理中会给每个节点分配一个基地址(00~FF)

    • Byte0:代表此帧网络管理报文发送的目标地址(一般情况)。通俗说就是这帧网络管理报文是发送给BCM还是给PEPS或者其他节点。

    • Byte1:代表发送的网络管理报文的类型即是ring报文还是Alive报文或者LimpHome报文;

      • 01:代表 Alive报文,在总线上声明自己的存在,请求其他节点与自己建环。

      • 02:代表Ring报文;

      • 12:代表当前节点已无通讯请求(睡眠标志位ind置位),即告知其他节点我已满足睡眠条件;

      • 32:即将其睡眠应答位置1,当检测到其他节点都在发送12ring报文后,最后一个节点发送此应答报文,告知其他节点当前整个网络无通信请求,可以睡眠。此时进入睡眠等待状态即Twbs状态。

      • 04:代表跛行报文,如果网络管理报文接收计数器和发送计数器超限后,发送跛行报文即无其他节点与此节点建环,只有一个节点存在。

    • 其余字节预留。

    3、OSEK网络管理可以被应用报文唤醒。

    展开全文
  • Autosar & OSEK 网络管理学习笔记

    千次阅读 多人点赞 2020-09-14 18:04:30
    OSEK 网络管理学习笔记网络管理的意义Autosar 与OSEK 的区别Autosar 与OSEK 的特点Autosar核心内容报文格式流转状态架构图比对 网络管理的意义 1.使网络中的ECU节点有序地睡眠和唤醒,在没有通信需求的时候睡眠,...
  • 汽车行业中的AUTOSAR与OSEK到底是什么,有什么区别

    万次阅读 多人点赞 2018-06-26 12:00:35
    一、AUTOSAR 现在的汽车正向着更高的安全性、经济环保性、舒适性、便捷性发展,从而为汽车电子系统带来了前所未有的复杂性,因为需求越来越多,更多的数据需要在整车电子系统中被处理被传递,据统计,在现代的汽车...
  • AUTOSAR网络管理

    千次阅读 2020-11-20 13:16:35
    AUTOSAR NM是一种分布式直接网络管理,每个节点根据网络管理帧的状态独立的控制自己的网络状态。 2 策略描述 该策略是基于网络上周期性广播的网络管理帧。 在网络唤醒状态下,当一个节点A需要保持网络唤醒时,节点A...
  • AUTOSAR PN网络管理测试开发实践

    千次阅读 2021-02-03 14:08:25
    国内网络管理应用已从早期OSEK NM过渡到AUTOSAR NM,部分OEM使用了AUTOSAR NM的PN特性,本文从NM概念用途、PN的实现方式、CANoe下实现PN网络管理测试思路几个方面展开介绍。 什么是网络管理 汽车上的ECU在工作的时候...
  • ComM是整个通信的服务管理模块,掌控整个AutoSAR的通信,在通信协议栈中除了ComM之外,网络管理也是主要的通信控制和管理模块,因此本篇主要对CAN的AutoSAR提供的网络管理功能做详细的介绍。 全系内容可在《搞一下...
  • OSEK NM 253.pdf

    2021-11-24 11:26:21
    OSEK/AUTOSAR NM 网络管理
  • AUTOSAR 网络管理

    千次阅读 2020-06-20 14:19:59
    目录一、直接网络管理1. OSEK NM1.1 逻辑环Logical Ring1.2 新的节点如何加入逻辑环1.3 节点状态1.4 地址管理1.5 NM状态流转1.6 告警管理2. AUTOSAR NM 一、直接网络管理 1. OSEK NM 直接网络管理将网络上ECU节点...
  • 总线网络。关注我,获取汽车网络开发及测试方面资料,更新干货!这个博客是讲解搭配TXT测试AutoSar网络管理的流程下面,正文开始!
  • 网络管理部分由通信管理器(简称ComM),通用网络管理器接口(简称NmIf),总线相关的网络管理器(简称NM,包括CanNM,LinNM,FrNM),总线相关的状态管理器(简称SM,包括CanSM,LinSM,FrSM)四个模块构成。...
  • AutoSar网络管理

    千次阅读 2020-03-29 22:16:27
    CAN总线学习-2 最近学习CAN总线AutoSar网络管理,最近做一些总结。派森君 ...AutoSar中规定的操作系统标准就是基于OSEK,通信和网络管理虽然和OSEK有区别,但是有继承性。 OSEK 是德国的汽车电...
  • AUTOSAR NM是一种分布式直接网络管理,每个节点根据网络管理帧的状态独立的控制自己的网络状态。 2 策略描述 该策略是基于网络上周期性广播的网络管理帧。 在网络唤醒状态下,当一个节点A需要保持网络唤醒时,节点...
  • Autosar02 - 网络管理

    千次阅读 2020-11-04 15:26:28
    网络管理部分由通信管理器(简称ComM),通用网络管理器接口(简称NmIf),总线相关的网络管理器(简称NM,包括CanNM,LinNM,FrNM),总线相关的状态管理器(简称SM,包括CanSM,LinSM,FrSM)四个模块构成。...
  • AUTOSAR 网络管理NM

    千次阅读 2019-11-12 22:06:54
    此处说一下AUTOSAR独有的网络通讯规范和网络管理模块NM 一、AUTOSAR COM AUTOSAR COM是AUTOSAR标准的一部分,它是从OSEK COM标准的基础上发展而来的。AUTOSAR COM提供了一种标准化的访问汽车通讯系统和ECU...
  • 标准定义了三个组件来构成OSEK/VDX标准:实时的操作系统(OSEK OS),通讯子系统(OSEK-COM)和网络管理系统(OSEK-NM)。这样定义的一个好处是方便了各个组件版本的定义,这已在实际应用中得到了体现,例如:现在...
  • 近年来,汽车的节能问题备受关注,消减不必要... 当前,大多数的车辆都是遵循OSEK或者AUTOSAR网络管理协议,来实现节点休眠唤醒功能的。由于目前车辆的电子电气系统越来越复杂,KL30节点也越来越多,当前的网络管理

空空如也

空空如也

1 2 3 4 5 ... 8
收藏数 159
精华内容 63
关键字:

osek网络管理与autosar