• FlexRay网络管理与测试


    随着车载网络发展,ECU的通讯速率相较以往得到飞速提升。现今多数OEM在中高速通讯场景中仍采用CANFD进行过渡,但当同时考虑安全和更高带宽时,CANFD则无法满足,因此FlexRay成为部分OEM的首要选择。其中控制各ECU的睡眠唤醒依旧利用耳熟能详的NM网络管理实现。

    下面跟随小怿一起了解FlexRay网络管理及相关测试吧。

    0FlexRay网络管理简介

    01 报文格式

    FlexRay网段通信时为了表示各ECU表示自身是否加入网络,特意在NM报文中引入Vote投票位,当Vote=1时代表加入网络,Vote位是否有效取决于FlexRay-NM状态机。

    FlexRay-NM报文格式及内容如下所示:

    其中针对CBV字节的BIT信息定义如下:

    02  FlexRay-NM状态机

    POC:Protocol Operation Control,协议操作控制,简称POC状态机

    PNC:Patiral Network Control,局部网络控制,简称PNC状态机

    SWC:Software Component,应用层软件组件,负责实现不同功能

    WUP:Wakeup Pattern,FlexRay唤醒信号,以低高电平呈现

    FlexRay网络管理设计类同于CAN网络管理设计,不同的是FlexRay的网络管理为了更清晰的划分局部网络,同一FlexRay网段下根据ECU功能划分了PNC网关、非PNC网关与不支持PN三种。其中ECU的休眠、唤醒、同步的时机由NM状态机决定;各ECU状态由自身POC状态机控制负责实现;唤醒状态时,各SWC映射至PNC的相关报文是否发送由PNC状态机与ComM channel状态机共同决定。测试时仅关注PNC状态机即可,也就是PNC网关的网络管理报文对应PNCID是否置1,这一信息部分OEM也布置了VFC报文进行体现。

    再简而言之,在FlexRay网络管理与CAN/CANFD网络管理测试不同点为NM状态机跳转与PNC状态机Map-Frame的一致性。今天我们主要介绍FlexRay-NM状态机的跳转机制。

    FlexRay-NM状态机模式有三大三小,后文有关状态描述采用对应缩写:

    BSM:Bus Sleep Mode,总线睡眠模式

    SYM:Synchronize Mode,同步模式

    NM:Network Mode,网络模式

    Network Mode模式中包含三个子状态:

    RMS:Repeat Message State,重复消息状态

    NOS:Normal Operation State,正常操作状态

    RSS:Ready Sleep State,准备睡眠状态

    FlexRay-NM状态机与CAN-NM状态机唯一不同的是取消了PBM预睡眠模式,并引入同步模式给与全局时基同步时间。各个状态跳转的条件基本取决于NM-Timeout-Timer、Repeat-Message-Timer、Wait-Bus-Sleep-Timer及网络是否释放。具体的跳转条件如下:

    Condition1:本地唤醒请求

    Condition2:接收网络管理报文成功

    Condition3:发送网络管理报文成功

    Condition4:Repeat-Message-Timer超时

    Condition5:不进行本地唤醒请求

    Condition6:NM-Timeout-Timer超时

    Condition7:配置FlexRayNmPnEnabled=False并且网络请求

    Condition8:Wait-Bus-Sleep-Timer超时

    Condition9:配置FlexRayNmPnEnabled =True并且重复消息请求

    Condition10:POC状态机完成同步

    Action1:初始化

    Action2:初始化NM-Timeout-Timer

    Action3:开始Repeat-Message-Timer

    Action4:开始Wait-Bus-Sleep-Timer

    了解了FlexRay网络管理的基础知识,下面跟随小编一起学习下网络管理中FlexRay不同于CAN的部分测试吧。

    0FlexRay网络管理测试

    01测试环境搭建

    基于Vector的基础测试环境

    怿星自研的FlexRay自动测试台架由上图Vector基础测试环境再搭配自研ETS6210、EH6466板卡共同构成,可同时实现FlexRay单节点、系统级、网络管理以及诊断刷写测试。基于CDD的诊断实现同样满足OEM在FlexRay节点诊断协议的不一致性,常见的诊断协议为DoIP、FlexRay、CAN。测试中为避免CANoe中POC状态机重启将影响网络管理测试,在Network Hardware中配置如下:

    当被测件为冷启动节点时,为保证网络启动时被测节点的冷启动优先级,还需取消CANoe的冷启动功能:

    02Vote投票位测试

    测试方法:利用CANoe发送WUP唤醒电平,仿真带有请求所有PNC的有效网络管理报文,监测ECU发出网络管理报文中Vote有效性。

    发送唤醒报文后,ECU的NM报文Vote=1

    前文所述,Vote有效代表节点自身加入网络,可以概括为Vote在需要节点通信时总是有效,具体的变化如下:

    · 本地唤醒/网络唤醒进入RMS状态时Vote=1

    · 本地唤醒/网络唤醒维持进入NOS状态时Vote=1

    · 网络被释放且NM-Timeout-Timer超时后Vote=0

    · Wait-Bus-Sleep-Timer超时后Vote不再发送

    03 BSM-RMS测试

    测试方法:利用CANoe发送WUP唤醒电平,仿真vote=1有效网络管理报文,监测ECU发出网络管理报文中Vote的发送次数与PNC信息。

    发送唤醒信号后,ECU的NM报文持续10个NM-Cycle

    FlexRay采用时隙(时间片)传输,因此处于静态段的网络管理报文传输无法像CAN一样在RMS状态设置快发送,但仍然规定了网络管理报文的发送次数,通常配置为10个NM-Cycle。基于FlexRay的10Mbit/传输,网络管理报文周期相较于CAN仍加速3-4倍,相较于CANFD加速1-2倍,这也取决于NM-RepCycle的设置。BSM-RMS状态测试正是检测此项机制。监测实现采用on frframe事件,测试时最好设置同一Cycle中仿真的网络管理报文时隙ID大于被测的网络管理报文,大家可以参照Lin协议的调度表运行考虑不这样做会有什么bug,又有哪种方法可以解决?

    04 PNC掩码测试

    测试方法:利用Arxml解析后的PNC-PDU-Signal Group信息,使用CANoe发送WUP唤醒电平,仿真带有不同PNCID的有效网络管理报文,监测ECU相关PDU的Signal Group是否更新。

    分别发送PNCID=16,17的NM报文

    前文所述,FlexRay节点为安全与高速服务,任何节点的通信都必须保证,因此在整车网络中各冷启动节点常被配置为PNC网关,那PNC掩码唤醒/唤醒维持测试就必不可少了。测试中需注意on frpdu事件无法抓取object::name,必须将Arxml文件中的信息提取并根据object::FR_cycle与object::FR_slotID做匹配。Capl提供主要抓取对象如下:

    on frpdu事件主要对象

    以上,就是本次给大家分享的全部内容啦。小怿相信随着OEM对于整车功耗标准的不断提升,FlexRay的优点与管理用户数据的PNC状态设计在未来将会有更多运用。限于篇幅,内容不详之处如果您还有疑问,欢迎下方留言,也可随时联系我们呦!

    参考资料

    1.《FlexRay Protocol Specification_V2.1》

    2.《Specification of Communication Manager  AUTOSAR CP Release 4.3.0  》

    3.《AUTOSAR SWS CANNetworkManagement-4.3.0》


    喜欢此篇文章欢迎评论、收藏、分享支持小编~

  • 相关阅读:
    9.30 - 每日一题 - 408
    一种基于多神经网络的烟支缺陷分类与定位方法
    面试篇之HR问什么是静态代理?什么是动态代理?
    Kubernetes 的亲和性污点与容忍
    内存泄漏检测组件的实现
    pytorch 训练过程-visdom可视化
    Nvidia 硬件架构
    QT---day3---9.19
    教育类《中学政史地》收稿方向-投稿邮箱
    数据安全前言技术研究联邦学习
  • 原文地址:https://blog.csdn.net/m0_47334080/article/details/127575779