OSEK_VDX汽车嵌入式分布式车身执行标准
基于OSEK／VDX的乘用车车身CAN网络管理与实现
第２ ０卷 第 ５ 期 ２０ Ｏ７年 １ ０月 文章编 号 ：￣２４２ （０ ７０—０ ３０ １ －０６ ２０ ）５０５ ．４
山 东 科 学
Ｓ Ｎ ＮＧ Ｓ ｌ ＮＣ ＨＡ Ｄ０ Ｃ Ｅ Ｅ
Ｖ０ ． ０ Ｎｏ． １２ ５
了网络管理的 内容。通过监督 帧的设计 和网络节点 的 Ｃ—Ｍ Ｔ Ｕ Ｅ和 Ｃ—Ａ Ｓ Ｎ Ｂ Ｅ Ｔ计 数器 规则 的 阐述 解决 了车 身 网络管理 的关键技术 ， 通过实际应用 验证 了方法的可靠性 。 关键词 ： Ｓ Ｋ Ｖ Ｘ Ｃ Ｎ总线 ； ＯＥ ／Ｄ ；Ａ 车身 网络 ； 网络管理 ； 网络状态
１ 引言
随着汽车电子技术 的不断发展 ， 车辆上 电控单元 的数量不断增加 ， 而且功能也越来越 复杂， 多个处理器 之间相互连接 、 协调工作并共享信息构成了汽车车载计算机通信 网络。车载网络运用多路传输技术 ， 采用多
条不同速率的总线分别连接不同类型的节点 ， 并使用 网关服务器来实现整车 的信息共享和网络管理。其中，
收稿 日期 ：Ｏ７０ ．０ ２Ｏ ．７１ 基金项 目 ： 山东省重 大科技专项 （０４ Ｇ １４０ １ ２０ Ｇ １０００ ） 作者简介 ： 李研强 （９７一） 男 ， １７ ， 硕士 ， 主要从 事汽车电子 、 嵌入式系统研究 。
维普资讯
５ ４
山
东
科
学
２Ｏ Ｏ７征
在 汽车 车载 网络 中 ，Ａ Ｃ ｎｏｅ ｒ ｅ ｏｋ控 制 型局域 网） Ｃ Ｎ（ｏｔ ｌｒ ｅ Ｎｔ ｒ ｒｌ Ａ ａ ｗ 总线 技术 得 到 了最 广 泛 的应 用 。 Ｃ 总 线 的 Ｎ Ａ 物理 层 协议 和数 据链 路层 协议 作 为 国际标 准 ， 已经 被 大家 广 泛熟 知 ， 且 得 到 国际 大 芯 片 厂商 的支持 ， 并 各种
OSEKOS标准简介
OSEKOS标准简介OSEK OS标准简介1 、OSEK 简介随着社会的进步和汽车工业的飞速发展，汽车在降低能耗、提高安全性和舒适度以及环保等方面的要求越来越高.这些要求刺激了电了技术在汽车_L的应用.而且比重不断增加，其结果是汽车在零部件控制技术、通信和网络方面的复杂性大大增加。
在这个强大的市场需求和激烈竞争的环境下，汽车电子的软硬件产品不断发展并出现多元化格局。
这时一些问题凸显出来，比如，由于处理器( CPU)不断升级导致不同的CPU间的软件移植滞后，由于不同实时操作系统的应用程序接日是口(API)不同，导致应用程序的移植性差等为了改变这种状况，1993年德国汽车工业界提出了OSEK(德文:Offene Systeme and deren Schnittstellen fur die Elektronik im Kraftfahr-zeug)体系，其含义是汽车电子开放式系统及其接口。
这个体系的最早倡导者有：宝马、博世、戴姆勒克莱斯勒、欧宝、西门子、大众和卡尔斯鲁厄大学的工业信息技术研究所，法国的汽车制造商标致和雷诺于1994年加人了OSEK体系，并将法国汽车工业使用的汽车分布式运行系统(Vehicle DistributedeX-ecutivr, V DX)也纳人这一体系，VDX的作用与OSEK相似。
在1995年召开的研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)，本文简称OSEK 规范。
它主要由四部分组成:操作系统规范(OSEK OperatingSystem,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。
此后，各软件生产厂商都相继推出了符合OSEK规范的产品，比较典型的有WINDRIVER公司的OSEKWorks ,ETAS公司的ERCOSEK,MOTOROLA的OSEKturbo和美国密西根大学的EMERALDS-OSEK等。
汽车电子中的嵌入式操作系统
占用资源S2
© 2009. HiRain Technologies. All rights reserved.
试图访问资源S1
举例：优先级反转（Priority Inversion）
激活任务4 优先级 试图访问资源S1，被拒
任务4 任务3 任务2 任务1
susp. susp. susp. run
run ready run
嵌入式操作系统的作用
资源管理
Task1
RAM STACK
Task2
RAM STACK
SCI CAN SPI
合理管理RAM，堆栈等系统资源 防止不同任务对硬件设备的同时使用 实现应用程序和硬件平台的分离
EEPROM 。。。
© 2009. HiRain Technologies. All rights reserved.
实时操作系统
操作系统中的 F1
更小，更快，更高度协调
龙者，大则兴云吐雾,小则隐介藏形
体积可裁减，适应各种硬件资源
真正的实时内核
保证所有重要任务在限制时间内完成
© 2009. HiRain Technologies. All rights reserved.
嵌入式操作系统
无操作系统VS嵌入式实时操作系统
© 2009. HiRain Technologies. All rights reserved.
OSEK/VDX规范
OSEK OS
Operating System
OSEK NM
Network Management
OSEK COM
Communication
OSEK TIME
blocked Susp. run run
OSEK标准
混合抢占任务调度
如果应用程序中的一些任务被指定为抢占任务，而另 一些被指定为非抢占任务，则该程序采用混合抢占任 务调度策略。 在这种策略下，操作系统根据当前运行任务允许的抢 占类型决定是否启动调度程序。 非抢占任务在混合调度中的意义：
– – –
如果任务的执行时间和上下文切换时间差不多 如果为保存任务的上下文需耗费大量内存 应用程序中某个任务被强制指定为非抢占
任务的激活
激活将会使任务从挂起状态到就绪状态。 基本任务有一个独特的特性：多重激活，应用程序可 以对基本任务提出多重激活请求(“Multiple requesting of task activation”)。意思是操作系统 接收并记录已激活基本任务的并发激活请求。操作系 统生成阶段会有一个激活次数的最大值。 基本任务状态转换图中的特殊情况：当一个基本任务 处于非挂起状态时，激活并立即不进入就绪状态。 多重激活允许一个任务终止后然后立即在执行。 缺点：需要(??)一个包含所有优先级的多任务队列。
resource ceiling-priorities bigger numbers refer to higher priorities.
任务的优先级由用户（应用程序开发人员）指定
OSEK体系结构
在OS标准里，符合类也算作了体系结构的一部分 四个符合类：
– – – –
BCC1（基本符合类1） BCC2（基本符合类2） ECC1（扩展符合类1） ECC2（扩展符合类2）
两个任务不能同时占有同一资源（互斥）。 不出现优先级反转 不能出现死锁 访问资源的任务不能进入等待状态。
ISR只有在其所需要的资源全部可用的时候才执行。 The OSEK operating system ensures also that an interrupt service routine is only processed if all resources which might be occupied by that interrupt service routine during its execution have been released。
OSEK标准
全抢占调度的调度点
调度点：
– 一个任务的成功结束（当前任务调用 TerminateTask（）一个任务要结束必须调用它）
– 一个任务成功结束并显示激活一个任务（当前任务 调用ChainTask()）
– 在任务层激活一个任务 – 显示的调用WaitEvent()，并转入等待转态 – 在任务层设置了某个任务正在等待的事件 – 任务层资源的释放 – 从中断层转到任务层运行
调度程序作为资源
如果一个任务在执行期间不想被打断，可以锁定调度 程序。
在系统生成的时候，系统生成一个资源 RES_SHEDULE。
资源管理
资源管理对四个符合类都是必须的。 资源管理的目标：
– 两个任务不能同时占有同一资源（互斥）。 – 不出现优先级反转 – 不能出现死锁 – 访问资源的任务不能进入等待状态。
ISR只有在其所需要的资源全部可用的时候才执行。 The OSEK operating system ensures also that an interrupt service routine is only processed if all resources which might be occupied by that interrupt service routine during its execution have been released。
数字指较高的优先级。For task priorities and resource ceiling-priorities bigger numbers refer to higher priorities.
任务的优先级由用户（应用程序开发人员）指定
OSEK体系结构
在OS标准里，符合类也算作了体系结构的一部分 四个符合类：
OSEK网络管理
ID
ECU 基地址+网 络节点序号
DLC
消息数据长度
Destination OpCode
目的地节点地址 命令和状态
User Data
用户数据
• Alive 报文
• 各节点申明自己要加入逻辑环
• Ring 报文
• 各节点向后续节点传递“令牌”的报文
• Limp home报文
• 各节点不能正常收发报文时，节点进入Limp home，之后节点周期 发送此报文。
OSEK 在ECU软件组件
NM
OSEK网络管理作用
初始化ECU资源，比如网络接口 启动网络 提供网络配置 网络节点监控 侦测，处理网络和节点的运行状态 设置网络或是节点的具体参数 协调网络运行状态，比如睡眠 控制，协调进入到睡眠模式。静态电流是重要的指标。 提供诊断功能
OSEK 网络管理培训
徐峰
什么是OSEK
OSEK，是指德国的汽车电子类开放系统和对应接口标准 (open systems and the corresponding interfaces for automotive electronics)而VDX则是汽车分布式执行标准 (vehicle distributed executive)，后者最初是由法国独自发起 的，后来加入了OSEK团体。两者的名字都反映出 OSEK/VDX的目的是为汽车电子制定标准化接口. 标准定义了三个组件来构成OSEK/VDX标准： 1. 实时的操作系统（OSEK OS） 2. 通讯子系统（OSEK-COM） 3. 网络管理系统（OSEK-NM）
网络管理进行管理
1. 所有的节点都连结在KL30上，直接由VCC供电 2. KL15作为网络消息通知各个节点 3. 各个节点具备OSEK定义的网络管理功能
OSEK OS标准简介
OSEK OS标准简介1 、OSEK 简介随着社会的进步和汽车工业的飞速发展，汽车在降低能耗、提高安全性和舒适度以及环保等方面的要求越来越高.这些要求刺激了电了技术在汽车_L的应用.而且比重不断增加，其结果是汽车在零部件控制技术、通信和网络方面的复杂性大大增加。
在这个强大的市场需求和激烈竞争的环境下，汽车电子的软硬件产品不断发展并出现多元化格局。
这时一些问题凸显出来，比如，由于处理器( CPU)不断升级导致不同的CPU间的软件移植滞后，由于不同实时操作系统的应用程序接日是口(API)不同，导致应用程序的移植性差等为了改变这种状况，1993年德国汽车工业界提出了OSEK(德文:Offene Systeme and deren Schnittstellen fur die Elektronik im Kraftfahr-zeug)体系，其含义是汽车电子开放式系统及其接口。
这个体系的最早倡导者有：宝马、博世、戴姆勒克莱斯勒、欧宝、西门子、大众和卡尔斯鲁厄大学的工业信息技术研究所，法国的汽车制造商标致和雷诺于1994年加人了OSEK体系，并将法国汽车工业使用的汽车分布式运行系统(Vehicle DistributedeX-ecutivr, V DX)也纳人这一体系，VDX的作用与OSEK相似。
在1995年召开的研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)，本文简称OSEK规范。
它主要由四部分组成:操作系统规范(OSEK OperatingSystem,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。
此后，各软件生产厂商都相继推出了符合OSEK规范的产品，比较典型的有WINDRIVER公司的OSEKWorks ,ETAS公司的ERCOSEK,MOTOROLA的OSEKturbo和美国密西根大学的EMERALDS-OSEK等。
基于OSEK_VDX标准的操作系统设计与实现
万方数据
航空计算技术
第４１卷
第２期
１．２．２报警机制 报警是ＯＳＥＫ／ＶＤＸ ＯＳ标准特有的数据结构［２】， 用于定时事件进行处理。其对象结构包括：剩余时间、 启动状态、报警周期、报警服务例程以及对象间的链接 指针。 ｘＯＳＥＫ中报警对象从属于系统定时器，通过差分 时间链的方式组织，如图６所示。报警的实现原理为： 利用时钟中断定时检查报警对象是否超时，若超时则 调用其服务例程（图５）。ｘＯＳＥＫ中报警对象的使用实 例为任务时间片调度管理和紧急任务的处理（图３）。
图３紧急任务处理流程
抢
图４任务调度程序流程图
图５时钟中断例程流程图
Ｓｖｓ Ｔｉｔｉｌｅ Ｓ，Ｉ．ｓｔｅｍ Ｔｉｃｋ Ｐｏｉｎｔｅｒ 气ｌａｌｌｌｌｌ ４
丽翮．厂砸而．厂丽
Ａｌａｒｍ对象序列（差分时间链）
ｌ ｌ一４＝７
Ｉ’１１３—４—７＝２Ｉ’１１６—４＿７—２＝３
一◆
４
ｌｌ
１３
１６
图６系统定时器结构图
ｌ
ｘＯＳＥＫ的设计与实现
ｘＯＳＥＫ内桉站均㈨闭Ｉ所爪。ｘＯＳＥＫ的牲书功
能＿｜；ｌ块为任务恃砰。横块和吲Ⅵ＊：州模块恬静竹理为
ｌ层功能提供点持．，．ｉ－ｒ，Ｉ符理川丁盘脱ｘＯＳＥＫ的宴时 ｔ１．１ｉｉｌｌ柠制
” ｍ
昔 理
窜岸
Ｉ匝壹。。霎亟固
专ｉ产
目Ｉ 内辖结构 ＊”目ｍ：２０１ｌ一０３一∞ｘＯＳＥＫ ‘ｔｍ目：＊十Ｈｆ＊０ｍ¨Ｗｍ（２００６ｚｒ３ｌｏｆｔＩ） ｎ｝∞ｎ：ｌ 目¨口”一）ｗ ｍ“ｎ女＾Ｉ¨目ｒ１６＇ｌ十№Ｊ日Ｍ—ｉｒ，０ｆＲⅣｆｆ，ｌ＊ｉ｝ＷＭ｛ｋ＊
绪最久未被调度的任务；否则表示该优先级下最近被 抢占的任务。
图２就绪任务表ＴＢＬ
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OSEK/VDXOSEK/VDX是应用在模块和静态实时操作系统上的标准，由主要的汽车制造商和供应商，研究机构以及软件开发商发起。
OSEK，是指德国的汽车电子类开放系统和对应接口标准（open systems and the corresponding interfaces for automotive electronics），而VDX则是汽车分布式执行标准（vehicle distributed executive），后者最初是由法国独自发起的，后来加入了OSEK 团体。
两者的名字都反映出OSEK/VDX的目的是为汽车电子制定标准化接口。
该标准完全独立，对目标系统只限制了少量的条件。
这样，就可以应用一些简单的处理器替代那些昂贵的解决方案，来控制任务执行，并不需要任何附加条件。
事实上，在此基础上，也可以合理使用一些更复杂的CPU，于是该标准便对任何可能的目标平台都没有了限制。
标准定义了三个组件来构成OSEK/VDX标准：实时的操作系统（OSEK OS），通讯子系统（OSEK-COM）和网络管理系统（OSEK-NM）。
这样定义的一个好处是方便了各个组件版本的定义，这已在实际应用中得到了体现，例如：现在OSEK-COM（3.0.2）和OSEK-NM（2.5.2）的版本就与OSEK-OS（2.2.1）的版本不同。
图1给出了OSEK/VDX的基本结构和各组件间的关系。
图1 OSEK/VDX标准操作系统基本结构OSEK-OS是个静态的操作系统，不支持在运行过程中动态更改，用户在产生特定的kernel 之间，必须确定所需要资源的准确数目。
另外，OSEK-OS也不需要进行动态的内存管理。
通过这些限制，大大增加了更好的进行代码优化的几率，甚至使得不带内存管理硬件的简单处理器有了用武之地。
用户不需要估算最坏情况下所需的资源——因为，可以容易的定度出静态系统的实际需求是多少，以及这个系统是否能够满足。
OSEK-OS中最重要的资源包括任务、时间和中断。
为此，提供了一个轻量级的API库。
版本2.2对应的API提出了26个用户功能接口。
轻量级的API使得开发者可以轻松上手，并灵活使用。
OSEK-OS中提供了两类任务：基本任务（basic task）和扩展任务（extended task）。
基本任务只有自己终止时才释放处理器，它也不接收更高的事件信号（event）。
因此，常常用来完成那些激活后就必须完整执行的工作。
扩展任务可以接收事件信号，它们只需要启动一次，并接收相关事件的控制。
每个任务会被赋予一个固定的优先级，运行期间不允许更改。
使用事件（event）——也被称为资源（resource）——可以同步任务的执行。
前面提到，扩展任务既可以由事件触发，执行中也会等待事件信号，这样便可以使用事件，达到同步任务的目的。
而基本事件则只能由事件触发，不接收事件信号。
OSEK/VDX术语中提到的资源，是一种确保对全局数据进行互斥访问的数据结构，与信号量有些相似。
开发者可以使用资源防止死锁的出现。
为此，OSEK/VDX提出了优先级最高限制协议，为每个资源指定特定的优先级，并在任务使用相关资源时，把任务的优先级设置为相应的值。
这是同步的一种安全的实现方法，使用资源的任务既不能等待事件也不会终止。
OSEK/VDX中的时间管理采用了计数器（counter）和定时器（alarm），甚至在一个计数器上对应多个定时器。
计时单位是固定长度的tick，定时器在某个特定时刻被激活，从而激活某个任务或者引发某个事件。
定时器可动态的切换成非激活态和激活态。
也可以指定定时器是一次定时，还是周期定时。
除了标准定时器外，也提供了静态定时器，但OSEK-OS中并没有定义静态定时器的API，计数器API也一样。
它们的实现依赖于具体的系统实现。
OSEK/VDX标准的所有文档包括OSEK-OS，OSEK-COM和OSEK-NM的API描述，以及OSEK实现语言OIL规范都免费对公众开放。
网址德国3Soft公司从1996开始开发OSEK操作系统，目前拥有350人，其中70多人专门开发OSEK操作系统平台。
已经为BMW提供了基于OSEK的软件开发平台（BMW Standard Core），为VW/Audi开发了OSEK软件开发平台，同时为DaimlerChrysler提供了首个基于OSEK项目的软件平台，此外提供了各种硬件平台的Bootloader、HIS实现。
3Soft的OSEK产品TresOS ECU创造了很多个第一，第一个商业化OSEK/VDX系统（1997年ProOSEK1.0问世），汽车部件产品生产中使用的第一个OSEK/VDX-OS（1999年Andi A8的dashboard-ECU采用了ProOSEK），整车生产中的第一个OSEK/VDX-OS软件标准核（1998年基于ProOSEK的BMW标准核问世，BMW要求所有的电子产品供应商基于这个标准核来开发软件，基于该标准核的BMW 7系于2001投产），2000年第一个OSEKtime操作系统实现商用，2002年第一个提供HIS I/O库的OSEK/VDX-OS，2003年第一个图形化OSEK的通用配置工具TresOS，2005年第一个AUTOSAR OS，2006年第一个提供基于FlexRay的FTCOM在BMW商用。
TresOS ECU是3Soft针对汽车电子控制单元（ECU）的软件开发者通常要面对客户提供或者需要多个软件组件，而且这些组件需要满足ECU特定的需求，来完成正确的操作，提供给开发者针对标准化组件进行集中配置的一个新途径。
其中包括TresOS Launcher这个集成配置工具和各种配置插件，这些Plug-in包括OSEK-OS 2.2.2（ISO 17356）、OSEKtime 1.0（OSEK/VDX）、I/O-Library 2.0.1（HIS-Specification）、Crypto-Module（RSA,AES,CRC等）、LIN 2.0/1.3 Driver（LIN-Specification）等，并且支持用户进行自定义扩展。
TresOS Launcher把多个配置工具组装成为一个集成开发环境。
用户可以在这些工具中任意转换。
Launcher把重要的数据（例如使用的硬件，配置的引导行）提供给所有的配置工具，以确保一致性。
TresOS Launcher管理存放各个配置工具专有数据的数据库，以分级的文件树形式存放。
在此过程中，对创建，验证，以及有时得标准化格式（例如OIL等）进行保留。
TresOS Launcher使用流程：Tresos概念的优点能在一个小例子得到充分体现。
现在有一位开发者，他想在其应用中使用控制器中的EEPROM。
那么，他只需执行如下步骤：ν在I/O库配置工具中配置EEPROM驱动ν在OSEK配置工具中配置一个访问EEPROM的任务ν在OSEK配置工具中配置一个周期性激活该任务的计时器ν实现这个可访问前面已配置好了驱动EEPROM的任务在TresOS中，任何配置工具可向其它工具提供服务。
OESK配置工具提供的典型服务包括：任务注册和计时器等。
使用这些服务，实现集成的准备和执行。
事件的步骤则简单的多：ν在I/O库配置工具中配置EEPROM驱动下述动作由tresos框架自动执行：ν I/O库配置工具向OSEK配置工具请求访问EEPROM的任务的注册ν I/O库配置工具向OSEK配置工具请求激活该任务的计时器的注册ν I/O库配置工具可能产生源代码，实现访问EEPROM驱动的任务程序会保存开发者已做的工作，此后，开发者不需要在不同工具之间进行转换。
从而使得这一过程中产生错误和集成中间件的风险大大降低。
TresOS有很好的可扩展性：像TresOS这样的系统是否成功取决于其扩展性。
当集成了大量配置工具后，便可完成自动集成。
将来，3SOFT将为TresOS开发所有的配置工具。
所有相关接口将对公众开放，于是用户便可载入所需的库。
这样，任何人都能进行可适用于TresOS的插件的开发，这些插件可以使用那些已有的插件或者自己提供的服务。
所有进行独立插件开发的必要信息都是可用的（可能指没有专利限制）。
所有已有插件严格遵循这些规范，以保证接口的一致性。
3SOFT可对客户向TresOS集成自主开发库提供技术支持。
TresOS ECU OSEK插件是3Soft公司已被广泛验证了的实时操作系统ProOSEK的直接后继者。
它遵循OSEK/VDX规范，得利于3SOFT公司OSEK技术方面的长期经验。
升级了TresOS ECU OSEK插件的操作系统，不仅适用于汽车工业领域，而且在只能提供少量资源的领域也可以广泛使用。
按照应用需求，静态提供所有的操作系统业务。
TresOS ECU的优势在于它的可裁减性，集成的图形架构环境和自动代码生成。
TresOS ECU OSEK支持标准如下：ν OS：严格遵循OSEK/VDX-OS 2.2.2ν配置语言OIL 2.5ν内部通讯遵循COM 3.0.3（所有一致的类：BCC1，BCC2，ECC1，ECC2，CCCA，CCCB）ν支持ORTI 2.0/2.1 (取决于工具链)支持可裁减性：ν可产生满足应用需求的kernelν可生成1KB以下的kernel提供硬件抽象层（I/O库）：ν定义在硬件和应用间抽象层有利于应用的移植。
硬件抽象层以附加Tresos ECU插件的方式提供，符合德国HIS团体的目前规范。
支持扩展调试：ν任务跟踪（TaskTrace）ν栈检查（stack check）ν运行检查（Runtime Checks）支持如下目标系统：ν Motorola: HC08, HC12, Star12, MPC555/56xν Hitachi: SH2, SH2E, H8Sν Infineon: C16X, XC16x, TriCoreν ST Microelectronics: ST10, ST30ν Fujitsu: F2MC – 16LXν Texas Instruments: TMS470ν NEC: V850ν Altera: Excalibur (ARM9)ν Simulation for Windows NT/2K/XP并且可根据客户需要进行移植。
支持主机系统：ν带有JRE1.4.2或者更高版本的任意桌面系统（例如：WindowsXP, Linux）支持其它功能：ν通讯驱动（LIN, CAN, ...）ν适用于无线电，医疗设备，家用等等。