本设计在基于MPC555微控制器硬件平台基础上，构建了一个开放的符合OSEKIVDX标准的汽车电子控制平台。开放式汽车电控单元设计的关键问题根据IEEE的定义，开放式控制系统必须使相应的执行程序能够运行于来源不同的平台，与其他的系统应用进行无缝的连接和相互操纵，并为用户提供一个具有一致风格的交互接口。下面是小编为大家整理的《OSEK网络管理论文(精选3篇)》，供大家参考借鉴，希望可以帮助到有需要的朋友。
OSEK网络管理论文 篇1：
从国内外双视角看我国自主汽车操作系统发展
汽车操作系统是用于控制和管理汽车硬件与软件资源的程序，是保障汽车正常运行和功能、性能的基础和关键，同时也将成为继智能手机操作系统之后又一竞争高地。在此形势下，深入剖析全球及我国汽车操作系统发展现状，以及我国汽车操作系统发展存在问题，研判我国自主汽车操作系统发展的路径对推动我国自主汽车操作系统发展具有重要意义。
车控操作系统是管理车辆动力、底盘、车身等基础硬件系统和软件资源的程序。以欧美为主导，已开展了两轮标准化工作：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网络管理论文 篇2：
基于ＭＰＣ５５５的开放式汽车电子控制平台
本设计在基于MPC555微控制器硬件平台基础上，构建了一个开放的符合OSEKIVDX标准的汽车电子控制平台。开放式汽车电控单元设计的关键问题
根据IEEE的定义，开放式控制系统必须使相应的执行程序能够运行于来源不同的平台，与其他的系统应用进行无缝的连接和相互操纵，并为用户提供一个具有一致风格的交互接口。这一定义明确的提出了开放式控制系统的特点和设计的关键，即可互操作、可复用、可扩展以及可互换。
另外，由于车辆使用环境变化较大，控制系统要求有较强的适应性，能够根据环境的变化进行系统动态配置，在线切换算法组件和改变组件间的互连等。
在硬件方面，由于硬件结构相对固定，系统升级基本采用部件替换或者增减的方式，更新周期也相对较长。因此，其开放性着重考虑的是硬件系统在汽车控制领域的通用性和适应性，也就是说硬件系统应该适应车载控制系统针对不同控制对象和控制模型的资源需要，同时也应注意系统开放互连的硬件支持。
OpenECU的硬件系统设计
系统硬件架构采用Freescale公司的MPC555作为控制核心，由电源模块、存储系统、复位电路和接口模块几部分组成。由于系统是面向汽车电子应用的，为保证系统的在汽车电子领域的开放性，应对汽车电子领域常用的接口信号进行处理，采用相应的专用接口芯片以满足要求。同时，系统提供丰富的I/O资源也有利于满足开放性的要求。系统架构如图1所示。
1 系统CPU选择方案
平台选用专为汽车电子等领域开发的处理器MPC555。基于对MPC500系列微控制器功能分析，选用MPC555的原因有如下几点：CPU处理能力可以满足算法对计算任务和浮点运算能力的需求，片上资源丰富，很多功能模块，如TPU、MDA和CAN等，是专门为汽车电子行业量身定制的，片上多种控制功能模块的集成，使得系统无须过多外接功能驱动芯片，且硬件布线减少，成本降低，有助于提高系统的可靠性；有较大的内部存储器容量，用户可以在满足要求的情况下自由选择是否使用外部存储器，这有利于节约成本，提高可靠性。
2 外扩存储器系统的设计
MPC555微控制器片内有448KBFlash，只提供32KB的SRAM，可能在某些复杂的控制场合存储空间是不够用的，为增强适应性，为用户提供足够的资源，本设计还外接SRAM和Flash存储器芯片。Flash选用AMD公司的AM29LV160DB，共2片。总存储容量为4MB。读写操作供电电压范围2.7～3.6V，访问时间为90ns。SRAM选用ISSI公司的IC61LV5128-10T芯片，共4片，总存储容量为2MB。访问时间为10ns，供电电压3.3V。
MPC555中的存储器控制器提供了对EPROM、静态RAM、Flash、EEPROM和其他外围设备的接口能力，共提供四个存储区段，分别由四根片选信号线CS[0]～CS[3]来进行选择，支持读写操作。CS[0]还作为系统自举时，程序入口地址区段的选择信号线。根据这个特性可以把系统配置成Flash启动方式。CS[1]作为SRAM的外扩片选信号。图2给出MPC555微控制器外扩Flash和SRAM存储器的连接图。其中WE[0:3]/BE[0:3]为写使能／字节使能信号线，其中WE[0]/BE[0]确认数据总线DATA[0:7]上的有效数据，WE[1]/BE[1]确认数据总线DATA[8:15]上的有效数据，WE[2]/BE[2]确认数据总线DATA[16:23]上的有效数据，WE[3]/BE[3]确认数据总线DATA[24:31]上的有效数据。OE为输出有效信号，CE为片选有效信号。由于MPC555微处理器按字寻址，未使用地址线低两位以避免发生地址冲突。
3 Lamda传感器信号调理
LM9040是由两路独立的Lamda氧气传感器采样输入的差分放大器组成的双通道传感器接口电路。Lamda传感器监视发动机废气，根据空燃比产生测量的电压信号。LM9040可以将士2V的传感器差分测量信号转换为适合5V参考电压的A/D变换的输出电压。电路如图3所示。
4 CAN通信总线设计
为了实现动力总成控制系统中的分布式控制和实时数据交换，必须采用高传输速率、抗干扰能力强以及高可靠性的网络总线方式。CAN总线以其突出的实时性、可靠性和灵活性的特点，在目前存在的多种汽车网络通信标准中最具竞争实力。
MPC555中已经内嵌两个CAN总线控制器模块TouCAN，TouCAN符合CAN2.0B技术规范，兼容标准(11位标志符)和扩展(29位标志符)两种报文格式，所以本设计采用集成控制器的方式来实现CAN节点。要进行CAN总线通信，还需要连接一个CAN收发器，在本系统中，选用CAN控制器与物理总线之间的接口芯片PCA82C251。值得注意的是，总线两端需加120Ω的电阻，对于匹配总线阻扰，起着相当重要的作用。忽略掉它们，会使数据通信的抗干扰性及可靠性大大降低，甚至无法通信。通信介质选用双绞线。为了增强抗干扰能力，去除传送信号过程中所产生的噪音，采用TDK公司特别为CAN总线使用而设计的高电感共态滤波器ZJYSS1R5。
OpenECU的软件系统设计
OpenECU的软件系统根据开放性的要求，对用户隐藏底层硬件和设备管理的细节，将系统分层封装为硬件抽象层和操作系统层，系统结构如图4所示。
硬件抽象层管理平台的硬件资源包括三个主要的部分：硬件系统的设备驱动、硬中断管理和系统调试与诊断支持。它是系统的硬件中断的管理者，生成和维护中断向量表，提供操作系统中断管理的支持，通过对硬件设备资源的封装，为操作系统提供设备操作的入口；采用中断驱动的方式响应调试系统的服务，进行系统的状态监视。
OSEKIVDX为车用嵌入式操作系统及其相关服务提供了一系列标准，目的是促进不同设备之间的协调工作能力，为软件开发者提供统一的编程接口，以提高软件的复用性和互换性。OpenECU选择TH-OSEK操作系统作为管理软硬件资源的系统平台和用户控制算法的运行平台。主要是因为其实时性较强，具有规范的应用程序接口，为控制模型提供标准的系统服务，可方便模型的实现和移植。另外，为了适用于广泛的目标处理器，支持运行在广泛硬件基础上的实时程序，OSEK操作系统具备高度模块化和可灵活配置的特性。这些特点显然是与OpenECU开放式开发平台所希望达到的开放性相一致的。OpenECU利用操作系统完成设备的进一步封装，为控制模型提供了规范的服务接口，并满足设备复用和控制实时性的要求，另外TH-OSEK操作系统定义了开放的网络管理和通信系统，可以方便的实现控制节点的动态配置。
对于系统的诊断和测试，本设计侧重于提供一个实现诊断和测试服务的平台和手段，而不关心具体的诊断和测试项目，这部分功能用户可以根据具体情况在系统支持下进行定义。OSEK ORTI实现系统诊断测试应用的基本服务支持，提供对OSEK操作系统进行查询和监控的接口，通过这个接口上层的诊断服务可以获取自己所关心的系统信息，并为诊断服务提供对目标操纵的基本手段。这部分是系统诊断和测试功能的实现基础，与诊断通信服务一起实现对目标的分布式调试与诊断。
结束语
初步的实际使用证明，本平台可以方便用户构建复合汽车控制系统，有效提高系统的可靠性，具有较高的实用价值。
作者：贾雅琼
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.
作者简介
胡佳玺：工程师，研究生。主要研究方向是汽车总线网络测试和汽车电器功能测试。
作者：胡佳玺