OSEK/VDX标准与车控电子产品开发

1 简介

汽车工业是技术密集、资金密集、综合性强、附加值高、经济效益好的产业。汽车工业的水平与规模是一个国家综合国力的体现。据统计，2002年，中国汽车的生产量为325万辆;2003年1至8月，国内汽车产量272.8万辆，同比增长36%;轿车销售量占国内汽车销售量的42.5%。我国已成为世界第五大汽车生产国。

汽车电子化是现代汽车发展的重要标志之一。目前世界每辆汽车采用电子装置的情况已成为衡量这部汽车水平高低的主要标志。国外汽车电子系统在汽车价格中所占比例已达 30%以上(我国目前仅为10%以内)，而且这一比例还在不断扩大。为了加强市场竞争能力，国外广泛采用 16～32位微处理器，以及广泛采用更先进的传感器，使汽车的功能从对汽车自身的控制管理扩大到“汽车-人-环境”这样一个大系统的信息获取、处理和控制。与国外相比，我国的汽车电子工业起点低，技术装备水平较低，没有掌握核心技术。伴随着我国汽车需求的强劲增长，我们应抓住国外汽车生成基地向我国转移的机遇，大力发展自主产权的汽车电子控制技术，促进我国汽车电子控制产品开发水平升级。

2 汽车电子产品的分类及嵌入式技术应用

按照对汽车行驶性能作用的影响划分，可以把汽车电子产品归纳为两类。一类是车控电子——汽车电子控制装置。汽车电子控制装置要和车上机械系统进行配合使用，即所谓“机电结合”的汽车电子装置。它们包括发动机、底盘、车身电子控制，例如电子燃油喷射系统、制动防抱死控制、防滑控制、牵引力控制、电子控制悬架、电子控制自动变速器、电子动力转向等。另一类是车载电子——车载汽车电子装置。车载汽车电子装置是在汽车环境下能够独立使用的电子装置，与汽车本身的性能并无直接关系。它们包括汽车信息系统(行车电脑)、导航系统、汽车音响及电视娱乐系统、车载通信系统、上网设备等。

汽车电子的技术基础是嵌入式技术。在过去的几十年里，嵌入式技术发展迅速。随着后PC时代的来临，计算广泛的嵌入到应用中去，嵌入式系统将成为未来计算的主要存在方式。应用的牵引和计算环境的变迁推动了嵌入式技术的发展。嵌入式技术与行业的结合又带动了行业的发展。汽车的电子化、信息化是嵌入式技术在汽车行业的应用。

车控电子产品是一个个分布在汽车上的电子控制单元(ECU)、智能传感器(Smart Sensor)等功能单元器件。这些器件通过总线连接在一起组成一个子系统。它们可以以适合自己的协议，如Lin、J1939等进行通信。不同的子系统也通过总线组成更大的网络。其中智能传感器(Smart Sensor)是一个以工业现场总线为基础，以CPU为处理核心，以数字通信为变送方式的传感器和变送器的统一体。与传统的Sensor相比，Smart Sensor增加了数字通信功能，面向网络，具有联网功能。

3 车控电子产品系统平台——OSEK/VDX

为了满足日益庞大复杂的汽车电子控制软件的开发需要，实现应用软件的可移植性和不同厂商的控制模块间的可兼容性。1993年，德国汽车工业界联合推出了汽车电子的开放式系统及接口——OSEK/VDX(Open Systems and the Corresponding Interfaces For Automotive Electronics)规范，旨在为汽车上的分布控制单元提供一个开放结构的工业标准。OSEK/VDX 规范从实时操作系统RTOS(RealTime Operating System)、软件接口、通信和网络管理等方面对汽车的电子控制软件开发平台作了较为全面的定义与规定。

它所提出的一整套解决方案是未来汽车电子软件开发的发展方向。目前，一些公司推出了符合OSEK/VDX规范的操作系统并得到了OSEK /VDX委员会的认证，如 OSEK Works、OSEKOS、OSEKTurbo等。OSEK/VDX标准包括以下四部分：OSEK/VDX操作系统规范(OSEK Operating System，OSEK OS), OSEK/VDX通信规范(OSEK Communication，OSEK COM), OSEK/VDX网络管理规范(OSEK Network Management，OSEK NM)以及OSEK/VDX实现语言(OSEK Implementation Language，OSEK OIL)。采用符合OSEK/VDX标准的嵌入式实时操作系统可以提高产品代码的复用率、降低开发成本、缩短产品开发周期。使用兼容OSEK/VDX标准的嵌入式实时操作系统的应用架构如图1所示。

 

 

图1 兼容OSEK/VDX规范的操作系统应用架构

.

下面分别对OSEK规范的操作系统部分(OS)、通信部分(COM)、网络管理部分(NM)、实现语言部分(OIL)、运行调试接口部分(ORTI)等进行介绍。

3.1 OSEK OS规范

OSEK OS规范定义操作系统内核的实现机制和应用编程接口(API)，包括任务管理机制、中断处理机制、事件机制、资源管理机制、报警器管理机制等及相关标准的应用编程接口。OSEK OS规范的实现机制见本刊网站www.dpj.com.cn。

3.2 OSEK COM规范

OSEK COM规范(OSEK Communication Specification)为汽车ECU应用软件提供了统一的通信环境。通过定义应用软件通信接口以及ECU内部通信和ECU外部通信，OSEK COM规范提高了应用软件模块的可移植性。OSEK COM 提供了多种服务，以方便在任务与任务之间、中断服务程序与中断服务程序之间以及任务与中断服务程序之间发送数据。

OSEK COM 规范的目的是支持应用软件的移植性、重用性和相互合作性。应用程序接口隐藏了内部和外部通信的区别，同样也隐藏了不同的通信协议、总线系统和网络。

OSEK COM中的通信是基于消息的。消息包括了特定应用的数据。消息和消息属性通过OSEK实现语言(OIL)静态配置。消息的内容和使用方法与OSEK COM无关。OSEK COM允许0长度的消息存在。在内部通信情况下，交互层IL(Interaction Layer)使消息数据立即发送到接收方。在外部通信情况下，IL将1个或多个消息压缩成指定的交互层协议数据单元(IPDU)，并把它们传递到下层处理，如图2所示。 内部通信的功能性是外部通信功能性的子集。交互层里的消息管理者是基于消息对象的。消息对象存在于发送端的是“发送消息对象”，存在于接收端的是“接收消息对象”。

 

 

图2 OSEK COM中消息发送和接收的简单模型

交互层和下层通信的数据被组织称IPDUs，包括一个或多个消息。一个消息必须占据在IPDU中连续的位而且不能被分离，在IPDUs中交叉。在IPDUs中消息被位排列。消息的大小在位中说明。交互层提供了应用程序接口(API)来处理消息，API包括初始化、数据传送和通信管理的服务。在网络上传送消息的服务是非阻塞的，一个发送消息的服务可能不能返回一个最终的发送状态，因为网络中的传送仍在进行之中。OSEK COM为应用程序提供了通知机制来决定传送或接收的状态。

3.3 OSEK NM规范

对于由不同生产商生产的汽车ECU产品，它们有通过串行数据交换连接成网络的趋势。因此，为了避免重复劳动和缩短开发时间，需要有一个基础性的标准。OSEK NM规范(OSEK Network Management system specification)为提高ECU产品的网络互连能力提供了一个网络连接标准。OSEK NM任务的目的是提高ECU产品网络通信的安全性和可靠性。OSEK NM规范规定了网络管理的机制和应用编程接口(API)。采用OSEK NM规范的ECU产品具有以下功能：

◆ 经过授权后，每一个节点必须是可以访问的;

◆ 在允许访问失败的情况下，具有最大容忍限度;

◆ 支持网络诊断。

作为一个基础的配置，遵守OSEK规范的网络管理实现必须应用在网络的所有节点。每一个节点都能在规定的间隔内获得整个网络的状态信息。 OSEK NM为网络监控提供了两种机制：一种是通过监控应用的消息进行间接监控;另一种是对于特定的网络管理利用标记机制进行直接监控。OSEK NM包括以下部分：

◆ OSEK NM与应用程序的接口(API);

◆ 节点监控的算法;

◆ OSEK NM与OSEK COM的接口;

◆ 转换到睡眠状态的算法;

◆ OSEK NM协议数据单元(NMPDU)。

图3说明了OSEK NM在整个系统中的位置及其与其他部分的关系。

 

 

图3 OSEK NM在系统中的位置

3.4 OSEK实现语言规范

为了达到软件可移植的目标，OSEK OIL规范(OSEK Implementation Language Specification)定义了一种配置和使用OSEK应用的方法。图4表示了一个遵守OSEK规范的应用开发过程。OIL文件可以是手写的或者是系统配置工具产生的。

 

 

图4 基于OSEK规范的应用开发过程

.

OIL提供一种在特定CPU中配置OSEK应用的机制。每个CPU对应一个OIL描述，所有的OSEK系统对象用OIL对象来描述。OSEK应用的OIL描述是一组OIL对象的组合，CPU是这些OIL对象的容器。OIL明确地为每个OIL对象定义了所有标准属性。每个OSEK应用可以定义附加的特殊执行属性和引用。每个OSEK应用可以限制每个属性的取值范围。

OIL中的对象包括：CPU(处理器)、OS(操作系统)、Appmode(应用模式)、Isr(中断服务)、Resource(资源)、 Task(任务)、Counter(记数器)、Event(事件)、Alarm(报警器)、Com(通信子系统)、Message(消息)、Ipdu(交互层协议数据单元)、NM(网络管理)。

3.5 OSEK ORTI规范

OSEK ORTI规范(OSEK RunTime Interface Specification)为OSEK操作系统开发工具提供了统一的接口。通过OSEK ORTI，使调试工具可以获取和显示操作系统的运行状态和性能、各种任务的状态、各种操作系统对象的状态等信息。ORTI文件是由系统生成器在系统生成阶段产生的。ORTI使用KIOL语言将操作系统内核信息传递给调试器，同时为OSEK标准对象定义了一些的语法规则。ORTI信息是通过ASCII文本文件提供的。由于OSEK/VDX是基于静态配置的，因此，ORTI不支持动态的表示和配置数据。

OSEK ORTI规范包括Part A和Part B两部分：Part A介绍了ORTI为调试工具定义的操作系统内核对象的语言(Kernel Object Interface Language，KOIL);Part B描述了OSEK/VDX标准对象、属性和它们的含义。

3.5.1 ORTI文件结构

ORTI文件包含版本信息部分、声明部分和信息部分。版本信息部分描述了KOIL和内核的版本。对于ORTI来讲，内核的版本是ORTI标准的版本号。声明部分声明ORTI实现中使用的内核类型，相当于C语言中的结构声明。它描述了访问内核对象所包含数据的方法。该部分详细说明了给定属性的显示名称。信息部分包含了所有给定系统声明部分所声明的方法，描述了计算或引用所需属性的方法。信息部分还提供了所需属性的静态值和表达式。

3.5.2 标准的ORTI对象及属性

OS对象，包含正在运行的任务、正在运行的优先级、正在运行的中断处理程序、操作系统服务、最近的错误、当前应用的模式等属性。

任务对象，包含优先级、状态、堆栈、活动状态、上下文等属性。

上下文对象，包含地址、大小等两个属性。

堆栈对象，包含大小、基地址、堆栈方向、填充模式等四个属性。

报警器对象，包含报警时间、周期、状态、动作、记数器等五个属性。

资源对象，包含状态、资源锁、优先级等三个属性。

消息容器对象，包含消息名称、类型、队列大小、队列记数器、当前消息地址等五个属性。

4 车控电子产品的开发流程

车控电子产品是软硬件结合的嵌入式系统。为了节约资源，缩短产品开发周期，一般应采取软硬件同步开发的方案，如图5所示。车控电子产品的开发工具对软硬件的同步开发、调试提供了很好的支持。车控电子产品的软件开发分为功能描述、软件设计、代码生成、操作系统环境下高级调试等步骤。车控电子产品的硬件开发分为硬件描述、硬件设计、硬件调试等步骤。当软件设计完成后，通过使用相应的工具，完成在虚拟ECU平台上的验证。当硬件设计完成后，与硬件一起进行软硬件集成调试。通过这种开发方式，缩短了产品上市的时间。

 

 

图5 软硬件并行的开发方案

目前，汽车车控电子产品软件开发流程是“V”形开发流程，如图6所示。“V”形开发流程分为五个阶段，即功能设计、原型仿真、代码生成、硬件在回路仿真——HIL、标定。

 

 

图6 车控电子产品软件开发流程

在功能设计阶段使用的主要工具是MATLAB。通过使用MATLAB提供的Simulink、Stateflow等工具，完成控制方案的设计、功能模块的设计、控制算法的设计等任务，并进行初步的仿真模拟工作。在原型仿真阶段使用的主要工具是dSPACE。使用dSPACE提供的快速控制原型 ——RCP工具完成离线的仿真工作。在开始该阶段之前，需要使用Real Time Workshop、Targetlink等工具完成由Simulink、Stateflow等产生的代码向标准 C代码的转换工作。在进行向标准 C代码的转换过程中，可以根据需要加入符合OSEK规范的嵌入式实时操作系统。在代码生产阶段使用的主要工具是CodeWarrior。通过使用 CodeWarrior提供的编译器、调试器等工具，完成从标准C代码向目标硬件平台上的产品代码的转换工作。图7表示了车控电子产品的代码生成过程。

 

 

图7 车控电子产品代码生成过程

结语

我国自主发展汽车车控产品尚处于起步阶段。本文简要介绍了车控产品的系统平台——OSEK/VDX规范，并给出了一个基于OSEK/VDX规范的简单的车控电子开发模型。在这个模型中，要求开发者熟练使用国际上主流的开发工具，以提高开发效率，缩短开发时间。

参考文献

1 Designing an OSEK/VDX Compliant RTOS for the C16x. Andrew Coombes, CEng,http://www.dspace.com

2 Experience with an Advanced Design Flow with OSEK/VDX compliant Code Generation for Automotive ECU's. Manfred Thanner, Motorola GmbH ; Raz Yerushalmi, I-Logix, http://www.omimo.be/magazine/01q1/2001q1_p006.pdf

3 ModelBased Software Development for Electronic Control Units (ECUs). Peter Bechberger http://www.dspaceinc.com/ww/en/pub/company/ medien/papers/73_e.htm

4 Connecting Simulink to OSEK/VDX: Automatic Code Generation for RealTime Operating Systems with TargetLink, Lutz K ster, Thomas Thomsen, Ralf Stracke, http://www.dspace.com

5 OSEK/VDXCompliant Embedded Development Solution for Automotive Applications. Jennifer Hubert, http://www.dspace.com