OSEK/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规范都免费对公众开放。网址http://www.osek-vdx.org

德国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, ...）

　 　 　 　 适用于无线电，医疗设备，家用等等