OSEK网络管理论文
评职称或毕业的时候，都会遇到论文的烦恼，为此精选了《OSEK网络管理论文(精选3篇)》，供需要的小伙伴们查阅，希望能够帮助到大家。汽车操作系统是用于控制和管理汽车硬件与软件资源的程序，是保障汽车正常运行和功能、性能的基础和关键，同时也将成为继智能手机操作系统之后又一竞争高地。在此形势下，深入剖析全球及我国汽车操作系统发展现状，以及我国汽车操作系统发展存在问题，研判我国自主汽车操作系统发展的路径对推动我国自主汽车操作系统发展具有重要意义。
OSEK网络管理论文 篇1：
汽车CAN节点的低功耗设计及实现
摘要：满足OSEK NM规范的CAN节点进入休眠后，一方面可以被本地唤醒信号唤醒，另一方面可以被总线上的有效显性位唤醒，当本地唤醒信号的滤波电路滤除不掉杂波时，本地唤醒信号线上的杂波会唤醒本地CAN节点。当CAN物理层收发器电路滤除不掉总线上的毛刺时，总线毛刺也会唤醒CAN节点。为了防止CAN节点被错误唤醒，通过设计临时唤醒模式和唤醒确认模式，判断是否存在有效的本地唤醒条件或CAN报文，避免了CAN节点被误唤醒进而唤醒，整个网络，从而大大增加整车电流消耗的问题。
关键词.OSEk：C.AN节点；唤醒信号
0 引言
随着汽车功能和电子电气系统越来越复杂，常电供电节点也越来越多。现代汽车CAN网络大多遵循OSEK直接网络管理协议实现常电供电CAN节点的休眠和唤醒功能[1]。根据OSEK直接网络管理协议，所有常电供电CAN节点都满足休眠条件后，整个CAN网络协同进入睡眠状态，当某个CAN节点被本地唤醒条件唤醒后，它将向CAN网络上发送ALIVE报文唤醒整个CAN网络[2]，其它CAN节点检测到CAN网络上出现有效的显性位时，CAN物理层收发器向CAN控制器的接收脚输出一个下拉脉冲，唤醒MCU和CAN节点，然后，被唤醒的CAN节点向总线上发送ALIVE报文，这些节点通过ALIVE报文完成网络建环。一般情况下，整车静态电流一般为唤醒状态下的几十分之一，甚至几百分之一。
在一个实现了OSEK直接网络管理规范的CAN网络中，当CAN网络进入休眠状态后，CAN节点一方面可以被本地唤醒[3]（一般为开关信号），一方面可以被总线唤醒。总线物理层收发器及其外围电路具备滤波功能，当总线上出现比较短的毛刺时，总线物理层收发器会过滤掉该毛刺，但是，由于CAN物理层规范对CAN信号的上升沿和下降沿有一定要求，它能过滤掉的杂波一般都只是微秒级，当总线上出现时间长度比较宽的毛刺时，物理层收发器便会在MCU的CAN控制器的接收引脚上产生一个低有效电平，这样，该CAN节点便会被唤醒，根据直接网络管理规范，除了自身被唤醒之外，它还会通过ALIVE报文唤醒其它CAN节点，使得整个CAN网络退出休眠状态，使得整车的电流消耗比休眠状态下的整车静态电流大几十倍，甚至上百信，不仅大大增加了整车的电流消耗，还可能会造成蓄电池亏电无法启动发动机的情形[4]。本地唤醒条件也有类似的误唤醒问题。
为了保证CAN节点不会被本地唤醒信号或者CAN信号误唤醒，本文设计了一种方法，只有在确实满足本地唤醒条件的情况下，或者总线上确实存在有效报文的条件下，节点才会被唤醒[5]。
1 方案设计
为CAN节点设计四种工作模式：唤醒模式、休眠模式、临时唤醒模式[6]和唤醒确认模式。其中，唤醒模式为正常工作模式，CAN节点电流消耗最大。休眠模式、临时唤醒模式和唤醒确认模式为低功耗模式，其中，休眠模式下的电流消耗最小。CAN节点的静态电流是指CAN节点在低功耗模式下的电流消耗[7]，即在休眠模式、临时唤醒模式和唤醒确认模式下的平均电流消耗。四种工作模式跳转如图1所示。汽车电子Automotive Electronics
CAN节点上电后自动进入唤醒模式，并在休眠条件不满足的情况下保持唤醒模式。CAN节点满足本地休眠条件且整个CAN网络协同休眠后，CAN节点禁能CAN收发器和控制器[8]，设置唤醒源，然后进入休眠模式。
为了保证本地唤醒信号线上的杂波不会误唤醒CAN节点，进入休眠模式时只设置两个唤醒源——CAN信号和内部定时器。其中，CAN唤醒源能够保证当CAN总线上出现一个有效的显性位时，CAN节点会马上唤醒，内部定时器唤醒源定时值记为Tsleep，能够保证CAN节点被周期唤醒。
临时唤醒模式保持时间为Ttempwake，在临时唤醒模式中轮询本地唤醒条件，不仅可以避免本地唤醒信号线的杂波唤醒MCU，减少了MCU的唤醒次数，降低了静态电流，还降低了对MCU唤醒中断引脚的需求。
Tsleep和Ttempwake。时间根据CAN节点静态电流约束条件和本地唤醒时间定义，为了保证功能的实时性，出现本地唤醒后，CAN节点要在一定的时间内向CAN网络上发送ALIVE报文唤醒其它节点，Tsleep越大，本地唤醒时间越长，Tsleep和Ttempwake的比值越大，CAN节点静态电流越小。
2 唤醒算法设计
为了保证CAN节点不被总线毛刺和本地唤醒信号毛刺误唤醒，设计了临时唤醒模式和唤醒确认模式。在临时唤醒模式下，CAN节点轮询CAN控制器标志位和本地唤醒信号电平，在唤醒确认模式下，CAN节点查询CAN报文接收和本地唤醒条件是否有效。唤醒算法流程如图2所示。
当节点进入休眠后，CAN信号或者内部定时器临时唤醒节点，进入临时唤醒模式，临时唤醒模式保持时间为Ttempwake，在临时唤醒模式期间轮询CAN控制器的唤醒状态位和本地唤醒信号的电平，如果CAN控制器唤醒状态位和本地唤醒信号电平一直无效，Ttempwake后CAN节点再次进入休眠模式。如果CAN控制器唤醒状态位有效或者本地唤醒信号电平有效，进入唤醒确认模式。
在唤醒确认模式中，如果CAN控制器唤醒标志位有效，使能CAN物理层收发器和CAN控制器，根据该CAN网络的波特率，设定一定的滤波时间（记为Tfiter），检查该段时间以内是否接收到CAN报文，如果接收到，说明这是有效的CAN报文唤醒，CAN节点进入唤醒模式，如果没有收到，说明CAN节点是被总线上的毛刺唤醒的，这时，节点返回休眠模式。在唤醒确认模式中，如果本地唤醒信号有效，以2 ms为周期，连续检测三次本地唤醒信号电平，如果均有效，进入唤醒模式。否则，节点返回休眠模式。
Tfiliter根据总线网络的波特率确定，根据CAN协议，CAN报文数据场的最大长度为8字节，一条数据场长度为8字節的CAN报文包含108个总线位，根据波特率可以计算出报文数据场长度为8字节的CAN报文的时长，Tfiiiter设置为最大CAN报文时长的2倍左右。汽车CAN网络的波特率有500 kbps、250 kbps、125 kbps三种，具体而言：
波特率为500 kbps时，CAN报文最大时长为0.216ms，Tfiliter设置为0.5 ms；
波特率为250 kbps时，CAN报文最大时长为0.432ms，Tfiliter设置为1 ms；
波特率为125 kbps时，CAN报文最大时长为0.864ms，Tfiliter设置为2 ms。
3 结论
本文设计了一种汽车CAN节点的低功耗方案，通过设置唤醒确认模式，区分有效的CAN报文和总线毛刺，区分有效的本地唤醒条件和信号毛刺，避免了误唤醒。根据CAN网络的波特率确定CAN报文滤波时间，避免了无效等待。本方法应用在为某车型设计的PEPS中，具有较强的实用性。
参考文献：
[1]蔡营，王永峰，岳意娥，等基于OSEK标准的整车CAN网络管理设计及测试验证[J]汽车电器，2016，（8）：38-41，49
[2]苗斌，王卫华，赵永胜，等具有OSEK功能汽车仪表的睡眠及唤醒管理研究[J]汽车电器，2014.（2）：15-18
[3]刘文英，邹洪波，王东，等一种基于CAN总线的低功耗汽车组合开关[J]机电工程，2013，（11）：1406-1409，1429
[4]付国良整车静态电流设计及验证[J]汽车电器2015，（11）：17-19
[5]山东省科学院自动化研究所一种汽车CAN节点的低功耗设计方法中国，201710458567.7 [P].2017-6-16
[6]马建辉，刘源杨，候冬冬，等汽车BCM的低功耗设计及实现[J]电子产品世界，2016，（11）：55-56，30
[7]山东省科学院自动化研究所一种低功耗车身控制器及其控制方法：中国，201510125944.6[P]2015-03-20
[8]初洪超网络管理在汽车CAN系统的应用[J]汽车实用技术，2016.（5）：114-118
作者：马建辉 张云 胡代荣 孙常青
OSEK网络管理论文 篇2：
从国内外双视角看我国自主汽车操作系统发展
汽车操作系统是用于控制和管理汽车硬件与软件资源的程序，是保障汽车正常运行和功能、性能的基础和关键，同时也将成为继智能手机操作系统之后又一竞争高地。在此形势下，深入剖析全球及我国汽车操作系统发展现状，以及我国汽车操作系统发展存在问题，研判我国自主汽车操作系统发展的路径对推动我国自主汽车操作系统发展具有重要意义。
车控操作系统是管理车辆动力、底盘、车身等基础硬件系统和软件资源的程序。以欧美为主导，已开展了两轮标准化工作：OSEK/VDX和AUTOSAR。OSEK/VDX主要对操作系统和网络管理进行标准化；AUTOSAR从软件架构、开发方法、开发工具三方面进行标准化。目前，德国Vector、ETAS、dSpace，美国Mentor Graphics和芬兰EB等企业都拥有符合上述标准的操作系统产品及成熟解决方案，并在汽车中得到了大量应用。
智能车控操作系统指利用人工智能等相关技术，实现对车辆的智能控制，以实现自动驾驶的目标。目前主要的智能车控操作系统大致分为两类，一类是由机器人开源项目的操作系统进行移植后针对性的研发，如百度的CarOS系统就是由开源ROS系统优化研发而来，另一类是基于开源Linux的，如特斯拉的Autopilot的操作系统。布局智能车控操作系统的公司已有不少：Google、苹果、特斯拉、Uber、百度等互联网企业都已参与其中，宝马、福特、沃尔沃等传统车企也相继加入。
智能车载操作系统由最初的车机联网的需求发展而来，逐步引入互联网汽车的理念，主要用于支撑人与车、车与车、车与互联网等的交互，满足舒适便捷的需求。随着互联网汽车热潮的到来，目前苹果、谷歌等互联网企业，以及大众、福特等传统车企均纷纷涉足这一领域，市场上主要存在的智能车载操作系统包括微软的Windows Automotive、谷歌的Android Auto、黑莓的QNX、苹果的iOS、阿里的YunOS Auto，以及开源的Linux、GENIVI等。
近年来，我国汽车操作系统研发及应用取得了積极进展。在车控操作系统软件方面，“核高基”重大专项部署支持了实时嵌入式操作系统及开发环境、汽车电子控制器嵌入式软件开发平台和国产汽车电子基础软件平台产品。国内软件平台厂商参照 OSEK/VDX 和 AUTOSAR 等国际标准，已经研发了面向 ECU 的操作系统产品及解决方案。同时，百度推出了以CarOS智能车控操作系统为核心的自动驾驶平台Apollo，在自动驾驶领域与国际领先企业展开同台竞争。在车载操作系统方面，阿里云研发了可用于车载终端的YUNOS Auto操作系统，并且和上汽联合发布了两款互联网汽车——荣威RX5 和i6，此外百度也推出了兼容多系统的车机联网系统Carlife。
传统车控操作系统仍是短板。虽然在“核高基”支持下，我国在汽车嵌入式实时操作系统领域取得了一定进展，但由于技术产品基础薄弱、专业人才不足、生态支撑能力差、市场拓展困难等因素，导致我国在传统车控操作系统领域话语权仍然不强。
智能车控、车载操作系统仍处于发展初期。我国在智能车控、车载操作系统领域涌现出了百度、阿里等有实力的企业，但我国智能车控、车载操作系统发展仍处于初期阶段，在智能车控、车载关键核心技术研发、软硬件兼容适配等方面仍需强化。
生态支撑能力有待加强。我国在车控、车载关键核心标准制定、应用软件，以及配套硬件供给方面与国外仍存在一定差距。企业间、企业与科研机构间的技术合作、资本合作等合作模式有待探索，产学研用协同创新体系尚未形成。此外，在公共服务支撑、人才培养等方面也需加强。
支持一汽、长安、奇瑞等车企依托智能汽车发展战略，加强与软件企业、互联网企业、人工智能企业等协同创新，加快布局智能车控操作系统领域。
支持有实力的企业之间开展深度合作，加强智能车控操作系统关键技术研究，研制面向自动驾驶、自主可控的智能车控操作系统平台。
支持互联网企业，以及有实力的操作系统企业，加强智能系统安全机制、交互机制的研究，加快研制、完善智能车载操作系统。
支持软件企业与车企加强合作，继续加强实时嵌入式操作系统的核心技术攻关，加快形成自主可控、安全可靠的汽车电子实时嵌入式操作系统产品体系。
支持操作系统研发企业参照OSEK/VDX和AUTOSAR等国际标准，与车企联合研制符合国际标准车控操作系统产品和整体解决方案，加快拓展国际市场。
支持一汽等车企与软件企业紧密合作，重点突破汽车动力、底盘、安全等相关软件控制技术，加快关键车控应用软件的研发和产业化。
支持科大讯飞、高德等软件企业，以及普华、博思、中科博泰、航盛等车载终端系统供应商，继续加强娱乐、导航等车载应用软件研发和产业化。
加快推进视觉道路环境感知、自适应巡航、车道偏离预警、控制决策等自动驾驶相关车控、车载应用软件的研发和产业化。支持传感器、芯片、零部件厂商加大研发投入力度，加强与汽车操作系统厂商合作， 形成软硬协同推进的局面。
作者：王宇霞
OSEK网络管理论文 篇3：
CAN总线通信系统在混合动力汽车的设计和测试
摘 要：混合动力汽车存在弱电设备的电子干扰强、在信号传递时对实时性要求比较高以及信息量比较大的特性，为了更好的解决这方面的问题，提高混合动力汽车的性能，人们设计了 CAN总线通信协议。该协议符合SAEJ1939标准，主要内容有物理层协议、网络管理协议、交互层协议、应用层协议与故障诊断处理的方案等，在该协议中人们提出了具体的网络通信的性能指标。通过大量的实验也证明了该协议是能够满足混合动力汽车在复杂的电磁环境下的各项需求，并且具有优良的通信性能与对故障的自我诊断能力。
关键词：混合动力汽车；CAN协议；电磁干扰
1 总成控制系统的设计
1.1 控制系统网络设计。
跟大部分的汽车一样，混合动力汽车的控制系统不是单独的存在，它是由诸多控制单元组合而成的车载系统，属于分布式，结构上属于拓扑结构，使用适合的终端电阻作为总线的终端，这样做可以起到对信号反射的阻止作用。而 CAN总线的两端分布着终端电阻，两端的端口也是单独的终端电阻。
1.2 网络管理协议设计。
网络管理对于 CAN网络的正常工作起着至关重要的作用，通过 OSEK与 VDX模型可以看出，网络管理主要包括直接网络管理与间接网络管理两种模式。拥有专业的网络管理报文的是直接网络管理，而通过被检测各个节点的周期性发送应用报文以对整个网络节点进行确定的是间接网络管理。如果在规定的时间之内，网络管理收不到节点发送的报文，便可以确认在这个网络上并没有这个节点。总体来说，间接网络管理可以减少对于总线的负荷。
1.3 CAN总线应用层协议的设计。
相对传统的汽车，混合动力汽车新增了一些设备以及部件，比如驱动电机，动力电池与动力控制单元。在SAEJ1939协议中已经对这些部件进行了定义，本文在这里对这些部件的 ECU源地址给出定义，综合信息帧的优先级与数据页包括ECU的源地址，从而得到所有信息条目的ID。只要信息的更新与接收节点的要求构成了信息的周期，再通过对信息周期进行定义之后，HEV控制系统在CAN总线应用层的协议设计才算完成。
1.4 对故障处理方案的设计。
检测与处理故障有两部分的内容，每个控制单元的ECU主要负责记录每个节点部件的故障检测与CAN通信错误的记录。而动力总成控制单元处在最上层，主要对整个系统故障进行界定与处理。每个单元在得到节点的故障之后就会经过CAN传递到动力控制单元。此时通信使用的报文便是应用层规定的特殊消息，而上层的动力总成控制单元在收到故障之后便会根据不同的故障而使动力系统的工作处在不同的状态，比如正常与停止。
2 系统部件与实车测试
对混合动力汽车CAN总线的测试，根据测试对象的不同可以分成以下几部分：单ECU网络接口的测试，子系统与整车网络台架的测试以及实车网络测试。单独的ECU网络接口的测试主要测试的是独立控制器网络接口的功能。子系统与整车的网络台架测试的则是子网络与整车网络总线的物理层性能与总线的错误检查记录以及处理的机制。实车网络测试则偏重于子网络和整车网络的总线物理层性能以及处理机制、报文的通信参数，对网络管理进行唤醒与休眠的测试。测试工具主要包括， CANoe，CAN-case硬件，CANStress，程控电源与多极性电源等。
总线电压测试的主要内容是对物理电平信号的测试。增加共模电感之后总线的共模干扰很小，波形也相当完整，只有信号在上升与下降的过程中出现了一些轻微的震荡，这点还是需要改进的。对混合动力控制器进行的是位时间的测试，CANScope可以取得76位信号的时间，测试之后就可以通过计算得到在位时间，根据得到的在位时间判断是否符合设计要求的。而对混合动力控制器的测试主要是对信号的周期与结果的分析。如果信息的发送周期最大的误差可以保证不会超过0.56102ms就属于正常的情况，如果统计窗口则说明在总线负载率为百分之九十八的情况下发送周期最大的误差在0.57995ms，这种情况也是能够满足对系统的设计要求的。
3 结语
通过对零部件与实车的综合测试，已经能够证明，CAN总线能够符合混合动力汽车对电磁环境的要求，以及对实时性、大量数据传输的要求。随着国家对新能源汽车开发中的投入不断的加大，以及人们对新能源汽车的认识的不断加深，相信CAN总线通信协议技术会得到越来越广泛的应用，也必将成为新能源汽车在数据传输方面应用的首选。
参考文献：
[1]邬宽明 .CAN总线原理与应用系统设计[M].北京：北京航空航天大学出版社， 2002：25-30.
[2]陈清泉 .混合动力电动汽车结构、原理与维修 [M].北京：化学工业出版社，2008：6-27.
作者简介
胡佳玺：工程师，研究生。主要研究方向是汽车总线网络测试和汽车电器功能测试。
作者：胡佳玺