OSEK网络管理入门

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

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网络管理可以被应用报文唤醒。

  • 50
    点赞
  • 300
    收藏
    觉得还不错? 一键收藏
  • 7
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值