• 1959年，集成电路制作的收音机开始在汽车上推广使用，拉开了汽车电子的应用开端。

• 20世纪60年代，硅二级管整流器的出现，交流发电机开始替代汽车上使用的直流发电机。

• 1960年，美国通用汽车公司最先使用晶体管电子电压调节器，从而在车用交流发电机上开始普及。

• 从20世纪60年代起，汽车制造商开始试图用电子技术来改善发动机和汽车的性能。

• 1976年，通用汽车公司在世界范上第一次使用微处理器在汽车上，加上大规模、超大规模集成电路技术的快速的发展，从此极大的改变了汽车的性能。

• 进入21世纪，汽车设计的主要问题依旧为安全和环保。电子技术的发展，为汽车向电子化、智能化、网络化、多媒体的方向发展创造了条件。

•  由于汽车电子的飞速发展，使汽车由机械式汽车向电子式汽车转变。

  技术目标

提高汽车动力性、经济性和安全性并改善汽车行驶的稳定性和舒适性。

• “绿色、环保、通讯是汽车电子的未来”

• “用户的态度、市场和外部条件将影响汽车电子的发展”

• 
  

汽车电子控制系统作为汽车中涉及安全、节能环保等关键系统，已成为目前世界各汽车强国竞相研发的热点。与消费电子和军用电子比较，汽车电子显示出了它的独特性。可以概括为如下几个特点：

特点1：控制系统实时性要求非常高，以满足车辆高速移动时的安全性和发送机精确控制的需要。

如：对发送机的点火正时和喷油脉宽的控制误差在±0.1℃ A的数值范围，即在发动机3000r/min的工作转速下，该曲轴角度对应的时间为±5.56μs。

特点2：必须能满足苛刻的、剧烈变化的环境要求。

        如温度变化：低温-40℃，高温60℃。.

        海拔高度、盐雾、潮湿、震动、光照、辐射、腐蚀气体、液体等等不利影响。而汽车上的电子控制系统必须能适应这些环境要求并能长期稳定工作。

特点3：必须具有高度的灵活性和可靠性。

  为了能够符合越来越严格的各种法规、标准等强制性标准和各种不同需求，必须要求汽车电子控制系统有足够高的灵活性(flexibility)和可靠性(reliability)以适应不同产品的定位要求、多变的外部环境。同时为了保证车辆安全，对电子控制系统也提出了诊断、容错和失效安全等要求。

  产品基本特点

军用电子产品的品质

消费电子产品的价格

汽车电子控制系统基本组成单位是ECU(electronic control unit)电子控制单元,它通过网络连接成一个汽车电子控制系统。

目前汽车电子控制系统在一辆车上形成一个网络化的分布式控制系统。

ECU包括传感器、执行器和控制器等3个主要部分。其中控制器又可以分为微处理器本身、数据处理、和驱动等部分。

传感器：可以测量系统内部和外部状态。

执行器：将对应的控制命令转化为相应的力或运动，作用在被控对象上。有的还可以直接反馈到控制器。

  控制系统基本框架

 ECU硬件框架

内部框架可分为5大部分：

1 –传感器接口电路；

2-单片机及其外围电路；

3-驱动执行器的功率放大器；

4-对外通信电路如CAN总线；

5-电路供电的电源部分。

D-MCU结构：双单片机的结构。

在设计电子控制系统是，尤其是设计数字核心部分，为了保证ECU的安全性和可靠性，往往采用一个主单片机和一个安全监控单片机，形成双单片机的结构。利用安全监控单片机（简单的8位单片机）监控主单片机的工作状态，以确保控制系统的安全性和可靠性。

采用安全监控的双单片机架构，目前在电子节气门的汽油机电子控制系统、共轨柴油发动机控制系统、ABS控制系统、安全气囊控制系统以及变速器控制系统中成为经典应用。

总结：由于汽车电子和半导体工业的发展，汽车级得各种专用芯片越来越多，导致汽车电子和控制系统的硬件设计越来越标准化和规范化，即硬件的可靠性越来越多的在器件的设计层面得到解决。

相应的汽车电子控制系统软件的重要性得到提升。由于MCU的硬件更加直观，其中的器件和PCB板工艺更加容易扩散和仿制。

软件作为控制的灵魂和核心，对其编程、测试、验证和维护研发难度大的多。因此汽车电子与控制系统的软件，已经成为汽车电子控制系统中最核心、最关键部分。

软件作为控制的灵魂和核心，对其编程、测试、验证和维护研发难度大的多。因此汽车电子与控制系统的软件，已经成为汽车电子控制系统中最核心、最关键部分。

基本静态层次框架：层次划分(从底层到高层)：

1 基本输入输出BIOS(basic input output system)；

2 处理器抽象层PAL(processor abstraction layer);

3 硬件抽象层HAL(hardware abstraction layer);

4 部件抽象层CAL(component abstraction layer);

5 整车抽象层VAL(vehicle abstraction layer);

6 操作监控层SUL(supervisor layer)。

从静态层次的划分方法可以引申出：

1 硬件静态层次；

2 软件静态层次;

3 数据静态层次。

处于最底层的是BIOS，在硬件上，对应单片机内部的各个外围模块，如SCI接口、AD模块、SPI模块、定时器模块和I/O接口；

在BIOS和PAL质检的硬件联系对应为MCU内部，从CPU连接到外围模块的电器接口；软件联系对应为信号的采集和输出模块，层序运行时间代表了CPU访问该外围模块的响应时间片，对应的数据为外围模块各个寄存器的物理地址和定义；

在HAL和PAL质检的硬件联系时单片机各个引脚和ECU各个硬件模块之间的电气接口关系，软件联系为BIOS的分配和设置，对应数据为信号处理电路参数；

CAL和HAL之间的硬件联系时ECU对外的输入输出引脚定义；软件联系时电路的转换和处理逻辑关系，对应的数据为传感器的MAP图；

在VAL和CAL之间的硬件联系是物理变量的值，软件联系为对部件的测量和解释，对应数据为被控对象如发动机的MAP图；

在SUL和VAL之间硬件联系时驾驶员的驾驶意图，软件联系为被控对象，对应数据是整车性能参数。

 软件框架之OSEK

实际的汽车电子控制系统的软件是动态运行的，除了按静态层次划分外，还需要保证系统实时性要求的运行时序。

为了保证控制系统多个任务的实时性，通常的软件设计方法有前后台模式和实时嵌入式操作系统模式。

前后台模式(foreground and background mode)

1） 所谓后台，就是一个无限循环，循环的执行多个事件，完成相应的操作，这部分软件通常在主程序main()中被调用；

2 ）所谓前台，一般由中断服务程序组成，中断服务程序处理异步事件。

后台可称为任务级，前台称为中断级。

由于汽车电子控制系统任务多，实时性要求高，因此越来越多的控制器采用嵌入式实时操作系统的设计框架，并且形成了国际标准和规范(ISO 17356).OSEK/VDX嵌入式实时操作系统作为软件平台。

OSEK解释

来源于德语Offene Systeme und deren Schnittstellen fur die Elektronik imKraftfahrzeug的缩写。

    英文意思为Open systems and the corresponding interfaces for automotive electronics。

    中文可译为汽车电子开放式系统及其接口。

OSEK最初由欧洲的汽车制造商于1994年提出，后来逐步发展为汽车工业的全球标准。

OSEK主要包括了4个部分：

1 操作系统；

2可执行语言；

3 通信管理；

4 网络管理。

操作系统(operating system,OS)

   包括操作系统功能元素的描述和定义。如任务、调度、事件、计数器、警报、资源和钩子等基本要数；以及如何定义应用程序接口如功能定义、类型定义、常数变量定义；还包括进程调度、优先级如何确定和优化的方法。通过操作系统的调度，可以灵活的适应汽车控制系统中的各种任务之间的嵌套。

采用实时操作系统(RTOS)的优点是能够协调多个任务之间的系统共享和进程调度，从而实现复杂的混合了事件触发和时间触发汽车电子控制系统的优化控制，保证系统的实时性和可靠性。

可执行语言

可执行语言在OSEK OS 的基础上，帮助开发人员具体定义应用程序。

在嵌入式软件开发中，C/C++是最成熟、使用最广泛的语言。

MISRA标准C

1994年，在英国成立了一个叫做汽车工业软件可靠性联合会MISRA(The Motor Industry Software Reliability Association)的组织。MISRA是一个致力于协助汽车厂商开发安全可靠的软件的跨国协会，成员包括：AB汽车电子、宾利汽车、福特汽车、捷豹汽车、路虎公司、Lotus公司、罗孚汽车、MIRA公司、Ricardo公司、TRW汽车电子、利慈大学和福特VISTEON汽车系统公司。

1998年MISRA发布了一个针对汽车工业软件安全性的C语言编程规范——

《汽车专用软件的C语言编程指南》(Guidelines for the User of the C Language in Vehicle Based Software),其中共有127条规则，称为：MISRA-C:1998

MISRA-C：1998的意义：

国际标准化组织ISO的标准C语言经历从C90、C96到C99的变动，但嵌入式开发很难将ISO标准当做编写安全代码的规则。一个原因是标准C语言并不是针对代码安全，也不是专门为嵌入式应用设计；二来标准C语言内容庞大，很难操作。MISRA-C:1998弥补上上面的不足。

目前MISRA-C被很多汽车厂商所接受和应用。2004年MISRA出版了该规范的新版本——MISRA-C:2004，并将面向的对象由汽车工业扩大到所有的高安全性要求系统。在MISRA-C:2004中共有强制规则121条，推荐规则20条，共141条，删除了15条旧规则。

“正确的观念重于一切”。

MISRA-C规范很重要的意义就是提供一些建议，使开发人员逐步建立一些好的编程习惯和编程思路，并摈弃那些可能存在风险的编程行为，编写出更为安全、强健的代码。

MISRA-C规范是对嵌入式软件开发的一种很好的完善。

下图为基于OSEK实时操作系统的软件开发模式：

通信管理(communication manager, COM)

负责在任务间的数据通信服务或者通过中断服务进行的通信任务。不同的任务通信可以发生在同一个ECU之间，也可以是多个ECU之间进行的外部通信服务。

OSEK COM 的目标是使应用软件具有良好的开放接口、良好的复用性能、良好的协调操作性能。而且通过通信接口能够将内部和外部通信之间的差别、不同的底层通信协议、总线类型和网络的差别隐藏起来，使得上层的应用独立于底层的通信。

网络管理(network manager ,NM):

基本目标是为了保证ECU之间通信的安全性和可靠性。

   网络管理有如下几个功能：

 1） OSEK各个层次之间的接口，如API接口

 2）适应不同总线协议的要求。如CAN、LIN、J1850、K-Bus等协议，以及相应的错误处理、状态统计算法；

3） 适应不同的节点资源，如根据节点的啊哟球对NM进行缩放，或则定制；

4） 适应硬件设计需求，如适应协议电路或物理层电路的特性；

5） 能够使用非OSEK规范的基站管理和节点管理策略。

Automotive Open  System Architecture

汽车开放式系统架构

定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，以便应用于不同的汽车平台，提高软件复用，降低开发成本。

AUTOSAR目前已成为汽车电子控制系统软件架构的全球规范

AUTOSAR的目标

是为了解决汽车电子控制系统中的标准化、兼容性和扩展性等问题，希望控制系统的软件代码能够在不同的供应商之间具有可互换性、不同的车辆平台之间具有可互换性以及不同整车应用之间具有可互换性而提出的汽车软件架构。

• 建立独立于硬件的分层的软件架构；

• 提供方法并将应用软件整合至ECU中；

• 制定各种车辆应用接口规范，作为应用软件整合标准；

• 统一标准、分散实现、集中配置。

• AUTOSAR开发成员在2007年发布了2.1版本使AUTOSAR的发展到达了一个稳定的阶段；随后通过几个不同的开发项目对AUTOSAR的通用性进行了测试；

• 宝马集团已将符合AUTOSAR标准的ECU应用在全新的BMW7系量产车型中；

• 在商业领域里，支持AUTOSAR标准的工具和软件供应商已推出了相应的工具和软件，提供需求管理，系统描述，软件构件算法建模，软件构件算法模型验证，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，帮助OEM实现无缝AUTOSAR系统软件架构开发流程。

• 目前AUTOSAR版本为4.1版

AUTOSAR是为了使用汽车电子系统有如下几个要求：

1） 管理越来越复杂的电气电子控制系统；

2）提高产品改进、升级和更新时的灵活性；

3）提高不同产品之间的移植性和扩展性；

4） 提高产品质量和可靠性。

AUTOSAR要求将电子控制系统的失效概率降低到10⁻⁸件/h

5） 在设计阶段更早地发现错误等。

汽车电子控制系统架构

每个ECU内部的软件划分为:

1）AUTOSAR软件部件（software components,SW-C）

2）实时运行环境（runtime environment,RTE）

3）基本软件模块（basic software,BSW）

        基本软件模块又可分为：服务层（Services Layer）

 ECU抽象层（Abstraction Layer）

 微控制器抽象层（MAL）     

复杂驱动（Complex Layer）

由于对复杂传感器和执行器进行操作的模块涉及到严格的时序问题，在AUTOSAR中这部分没有被标准化。

在上层的SW-C之间通信方式上，还定义了虚拟功能总线(virtual function bus, VFB)

VFB是所有通信机制的总称，即包括了ECU内部的通信，也包括了不同ECU之间的通信，VFB是SW-C能够独立于ECU的具体硬件环境，从而实现自由地移植和扩展。

SW-C层

能够独立于底层硬件、具有标准接口定义的软件模块，通过标准化的描述方法，不同的SW-C通过VFB实现通信。

在网络化地环境下，SW-C可以分配到不同的ECU中，AUTOSAR提供网络环境下不同ECU的资源和配置的描述方式，这些描述方式和SW-C的描述方式是独立的。

基本软件

包括嵌入式实时操作系统、控制器抽象层、ECU抽象层以及复杂设备的驱动模块。

简单地说，基本软件部分包括了操作系统和底层ECU的硬件驱动。

具体说，基本软件部分包括：控制器抽象层、ECU抽象层、系统服务层和实时运行环境。

基本软件——控制器抽象层

是基本软件中最底层的软件层，包括了内部的驱动模块，即直接访问微处理器内部周边模块和外部存储器的软件模块。

该层使得调用它的软件能够独立于挡片的寄存器运行。包括：DIO、ADC、PWM、EEPROM、Flash、WatchDog、SPI、IIC、SCI、CAN等等。

基本软件——ECU抽象层

直接与控制器抽象层接口，同时包含了外部设备的驱动。通过该层，上层程序可以在不知道周边模块和设备地址的单片机引脚情况下，正确地访问和使用这些周边模块和外设。

基本软件——系统服务层

是基本软件中的最高软件层，它通过ECU抽象层访问输入输出信号，并为上层的应用和其他基本软件模块提供服务，从而实现了将上层的应用和底层的硬件彻底分开的目标，也就保证了上层应用即SW-C的兼容性、扩展性、可交换性。

基本软件——实时运行环境

为上层的SW-C之间或则传感器和执行器部件之间提供通信服务，在该层之上的软件，不再成为“层”，而改为部件，包括软件部件和传感器部件或则执行部件。所谓部件就是代表了不能再细分到不同ECU中去的软件模块，是上层算法中最小软件单元。

  AUTOSAR方法论

主要步骤分为两个阶段

1）系统配置阶段

2）ECU配置阶段

1）系统配置阶段

属于系统级设计决策阶段。首先编写系统配置输入文件，为XML类型的文件，应用软件的描述术语在AUTOSAR中为软件构件（Software components),该文件将确定需要使用的软件构件（即系统需要哪些功能）和硬件资源（ECU）,以及整个系统的约束条件。

AUTOSAR提供了一系列模板和标准的信息交换格式，从而简化系统设计的工作，最终系统设计者只要使用工具填充或编辑相应的模板即可到处系统配置输入文件。

系统配置输入包含三部分内容，第一个输入是软件构件描述，定义每个需要的软件构件的接口内容，包括数据类型、端口、接口等；第二个输入是ECU资源描述，定义了每个ECU的资源需求，如处理器、外部设备、存储器、传感器和执行器等；第三个输入是系统约束描述，定义总线信号，拓扑结构和软件构件的映射关系。

系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生成系统配置描述文件，同样为XML文件，这是系统配置阶段的最终工作成果。该文件包含所有的系统信息，包括将软件构件映射到相应的ECU上，以及通信矩阵上。

2）ECU配置阶段

这个阶段需要对系统中每个ECU分别进行。首先是使用第一阶段的工作成果——系统配置描述文件，从中提取与各个ECU相关的系统配置信息，提取的信息包括ECU通信矩阵、拓扑矩阵、顶级功能组合，并放在另一个XML文件中。

然后进入ECU配置的实际工作中，这一步负责往输入对象中添加具体应用所必需的信息，如任务调度、必要的BSW模块、BSW配置信息、给任务分配的可运行实体等。这一步的结果被放在ECU配置描述文件中，包含具体ECU所需的所有信息。

最后一步是生成具体ECU的可执行程序，此步将根据ECU配置描述文件中配置信息构建完成ECU的基础软件的设置和与基于AUTOSAR构件的应用软件的集成，最终生成ECU的可执行代码。

标准化的应用接口

通过RTE实现AUTOSAR软件构件（即应用程序）相互间的通信以及软件构件与基础软件之间的通信的前提是，软件构件必须具有标准的AUTOSAR接口。

目前已经提供了一些典型的汽车电子应用领域的标准接口。按照功能逻辑分别将各个领域的系统划分为若干个模块。这些模块可视为一个软件构件或多个软件构件的组合，这些功能性的软件构件的接口被明确定义，所定义的接口的内容包括名称、含义、范围、数据类型、通信类型、单位等等。应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。

AUTOSAR正在成为现实，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而帮忙企业实现快速的市场反应。在市场上不少工具和软件供应商都已推出了符合AUTOSAR标准的工具和软件支撑，可为AUTOSAR系统的设计和开发提供完整的无缝的解决方案。

AUTOSAR是汽车电子软件平台标准化的历程中的一个巨大飞跃。但在整个汽车行业内打破传统的软件开发平台需要相当长的一个过程。在这个过程中，我们可以混合AUTOSAR和传统软件开发的方法，实现向AUTOSAR平滑升级。这个过程中，理解AUTOSAR的理念和思想最重要，因为它对汽车电子软件开发的工作流程和商业模式都将带来深远的变革。

技术角度定义

以应用为中心，以计算机技术为基础，软件和硬件可裁剪、适应应用系统对功能可靠性、成本、体积、功耗严格要求的专用计算机系统；

系统的角度定义

是设计完成复杂功能的硬件与软件，并使其紧密耦合在一起的计算机系统

术语嵌入式反应了这些系统通常是更大系统中的一个完整部分，称为嵌入的系统。

发展概述

计算机由硬件和软件构成，发展初期用户使用监控程序来使用计算机;

随着计算机技术的发展，为了更好的利用计算机硬件资源和管理软件资源，监控程序发展形成了操作系统（Operation System）

对于基本芯片的软件开发，应用程序就是一个无限的循环，可称为前后台系统或超循环系统

很多基于微处理器的产品都是采用前后台系统设计，如微波炉、电话等，在另外一些基于微处理器应用中，从省电的角度出发，平时微处理器处于停机状态，所有事都靠中断服务来完成。

操作系统是计算机中最基本的程序，操作系统负责计算机系统中软硬资源的分配与回收、控制与协调等并发活动；操作系统提供用户接口，使用户获得良好的工作环境；为用户扩展新的系统功能提供软件平台。

实时操作系统是一段前嵌入式系统启动后首先执行的背景程序，用户的应用程序是运行于ROS之上的各个任务，RTOS根据各个任务的要求，运行资源管理、消息管理、任务调度、异常处理等工作。在RTOS支持的系统中，每个任务均有一个优先权，RTOS根据各个任务的优先级，动态地切换各个任务，保证对实时性的要求。

多任务系统中，内核负责管理各个任务，或者说为每个任务分配CPU时间，并且负责任务之间的通信。内核提供的基本服务是任务切换。使用实时内核可以大大简化应用系统的设计，是因为实时内核允许将应用分成若干个任务，由实时内核来管理他们。内核需要消耗一定的系统资源，比如2~5%的CPU运行时间，RAM和ROM等。

内核提供必不可少的系统服务，比如信号量、消息队列、延时等。

调度室内核的主要职责之一，调度就是决定该轮到哪个任务运行了。多数实时内核是基于优先级调度法的。基于优先级的调度法指CPU总是让处在就绪态的优先级最高的任务先运行。

然而究竟何时让高优先级任务掌握CPU的使用权，有两种不同的情况，这要看用的是设呢类型的内核，是非占先式的还是占先式的内核。

非占先式内核要求每个任务自我放弃CPU的所有权。非占先式调度法也成合作型多任务，每个任务彼此合作共享一个CPU。异步事件还是由中断服务来处理。中断服务可以使一个高优先级的任务由挂起状态变为就绪状态，但中断服务以后控制权还是回到原来那个被中断了的任务，直到该任务主动放弃CPU的使用权时，那个高优先级的任务才能获得CPU的使用权。

当系统响应时间很重要时，要使用占先式内核。因此绝大多数商业上销售的实时内核都是占先式内核。最高优先级的任务一旦就绪，总能得到CPU的控制权。当一个运行着的任务使一个比它优先级高的任务进入了就绪状态，当前任务的CPU使用权就被剥夺了，或者说被挂起了，那个高优先级的任务立刻得到了CPU的控制权。如果是中断服务子程序使一个高优先级的任务进入就绪态，中断完成时，中断了的任务被挂起，优先级高的那个任务开始运行

任务的优先级是表示任务被调度的优先程度。每个任务都具有优先级。任务越重要，赋予的优先级应越高，越容易被调度而进入运行态。

中断是一种硬件机制，用于通知CPU有个异步事件发生了。中断一旦被识别，CPU保存部分或全部上下文即部分或全部寄存器的值，跳转到专门的子程序，称为中断服务子程序（ISR)。中断服务子程序做事件处理，处理完成后，程序回到：

1）在前后台系统中，程序回到后台程序；

2）对非占先式内核而言，程序回到了被中断了的任务；

3）对占先式内核而言，让进入就绪态的优先级最高的任务开始运行。

时钟节拍是特定的周期性中断，这个中断可以看作是系统心脏的脉动。中断之间的时间间隔取决于不同应用，一般在10ms到200ms之间。时钟的节拍式中断使得内核可以将任务延时若干个整数时钟节拍，以及当任务等待事件发生时，提供等待超时的依据。时钟节拍越快，系统的额外开销就越大。

嵌入式实时操作系统在目前的嵌入式应用中用的越来越广泛，尤其在功能复杂、系统庞大的应用中显得越来越重要。在嵌入式应用中，只有把CPU嵌入到系统中，同时把操作系统嵌入进去，才是真正的计算机嵌入式应用，使用实时操作系统主要有以下几个因素

1）嵌入式实时操作系统提高了系统的可靠性；

2）提高了开发效率，缩短了开发周期；

3）嵌入式实时操作系统充分发挥了32位CPU的多任务潜力。

优点：在嵌入式实时操作系统环境下开发实时应用程序使程序的设计和扩展变得容易，不需要大的改动就可以增加新的功能。通过将应用程序分割成若干独立的任务模块、使应用程序的设计过程大为简化；而且对实时性要求苛刻的事件都得到了快速、可靠的处理。通过有效的系统服务，嵌入式实时操作系统使得系统资源得到更好的应用；

 缺点：使用嵌入式实时操作系统还需要额外的ROM/RAM开销，2~5%的CPU额外负荷，以及内核的费用。

常见嵌入式操作系统---嵌入式Linux

Linux是一种很受欢迎的操作系统，它与UNIX系统兼容，开放源代码。它原本被设计为桌面系统，现在广泛应用于服务器领域。而更大的影响在于它正逐渐的应用于嵌入式设备。

uCLinux正是在这种氛围下产生的。在uCLinux这个英文单词中u表示Micro，小的意思，C表示Control，控制的意思，所以uCLinux就是Micro-Control-Linux，字面上的理解就是"针对微控制领域而设计的Linux系统"。与标准Linux在内存管理方面有着本质的区别,uCLinux主要是针对目标处理器没有存储管理单元MMU（Memory Management Unit）的嵌入式系统而设计的。

uCLinux是嵌入式Linux领域非常重要的分支，已成功应用于路由器、机顶盒、PDA等领域。

常见嵌入式操作系统---WINCE

Windows Embedded Compact(即 Windows CE)是微软公司嵌入式、移动计算平台的基础，它是一个开放的、可升级的32位嵌入式操作系统，是基于掌上型电脑类的电子设备操作系统。

Windows CE它精简的Windows 95，它的图形用户界面相当出色。

常见嵌入式操作系统---VxWorks

VxWorks 操作系统是美国WindRiver（风河）公司于1983年设计开发的一种嵌入式实时操作系统(RTOS)，是嵌入式开发环境的关键组成部分。

良好的持续发展能力、高性能的内核以及友好的用户开发环境，在嵌入式实时操作系统领域占据一席之地。

它以其良好的可靠性和卓越的实时性被广泛地应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中，如卫星通讯、军事演习、弹道制导、飞机导航等。在美国的F-16 、FA-18战斗机、B-2隐形轰炸机和爱国者导弹上，甚至连1997年4月在火星表面登陆的火星探测器、2008年5月登陆的凤凰号，和2012年8月登陆的好奇号也都使用了VxWorks。

常见嵌入式操作系统---μC/OS-Ⅱ

 μC/OS-II由Micrium公司提供，是一个可移植、可固化的、可裁剪的、占先式多任务实时内核，它适用于多种微处理器，微控制器和数字处理芯片（已经移植到超过100种以上的微处理器应用中）。同时，该系统源代码开放、整洁、一致，注释详尽，适合系统开发。 μC/OS-II已经通过联邦航空局（FAA）商用航行器认证，符合航空无线电技术委员会（RTCA）DO-178B标准。

μC/OS-II 的前身是μC/OS，最早出自于1992 年美国嵌入式系统专家Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载，并把μC/OS 的源码发布在该杂志的B B S 上。

ISO26262是以IEC61508为基础，为满足道路车辆上特定电子电气系统的需求而编写。

ISO26262适用于道路车辆上特定的由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。

安全是未来汽车发展的关键问题之一，不仅在驾驶员辅助和动力驱动领域，而且在车辆动态控制和主被动安全系统领域，新的功能越来越多地触及到系统安全工程领域。这些功能的开发和集成将强化对安全相关系统开发流程的需求，并且要求提供满足所有合理的系统安全目标的证据。

随着技术日益复杂、软件内容和机电一体化应用不断增加，来自系统性失效和随机硬件失效的风险逐渐增加。ISO26262包含了通过提供适当的要求和流程来避免风险的指导。

2012年10月，国务院常务会议审议通过《缺陷汽车产品召回管理条例(草案)》，正式“升级”为国家法规。

依据新规估算，对于均价10万元的乘用车，按照同一批次1000辆的保守估计数，企业或将面临“千万级罚金”，如果涉及数量多达上万辆，罚金将高达数亿元。

为了防止系统失效的发生，必须有一套严谨且可靠的开发流程来让系统开发工程师遵循，因此车辆领域的专家开始着手发展汽车领域的功能安全标准，ISO26262道路车辆功能安全标准在这样的环境与需求下应运而生

2012年8月，国家标准化委员会发布《关于下达2012年第一批国家标准制定修订计划的通知》中，正式将ISO26262列入国标制定计划，该标准将在3年内陆续出台并发布实施

ISO26262标准主要由欧洲的OEM、供应商和第三方评估机构发起，因此在欧洲贯彻力度最大，主要集中在法国和德国。

即使在ISO26262的草拟版本阶段，OEM仍然要求他们的供应商符合该标准，例如：定期要求合规状态报告，要求第三方评估报告，设置安全经理和相关资质的评审员。

形式认证法规ECER79(转向)包含对功能安全的基本要求。北美的OEM和供应商已经加快了追赶欧洲的步伐，正在依照ISO26262建立自己IDE功能安全体系，SAE组织（美国机动车工程师协会）已经组件汽车功能安全委员会（AFSC：Automotive Functional safety committee）在为欧洲OEM提供产品的一级供应商的驱动下，日本在2010年末至2011年初，主流OEM启动了对ISO26262合规进程的启动会议，由JAMA(一般社团法人日本自动车工业会)和JARI（日本自动车研究所）合作创建通用的工作流程。国内的OEM和一级供应商也非常关注。ISO26262的动态，国标的转化工作正在中国汽车技术研究中心的指导下全面展开。

ISO26262提出了汽车电子电器系统的安全生命周期，即从概念阶段、产品及系统层面以及生产运行的的安全管理做以细分，不同阶段不同的功能安全需求不同。

ISO 26262所避免的风险：

电子/电气系统的失效行为所产生的潜在风险。

安全要求的源头和规范

ASIL(Automotive Safety Integrity Level)车辆安全完整性等级

在达到要求的情况下，应尽量避免

过度验证和重复工作

安全范畴内的竞争压力

随机失效

“硬件安全完整性”要求（例如：PMHF、SPFM、LFM）

系统失效

“系统性安全完整性”要求

系统故障广义的理解为系统工作在不正确的工作状态，无论系统发生任何的异常时，系统表现出未定义的动作，都可以理解为系统或系统的某个部分不能或即将不能完成预订功能的事件或状态，即为故障。在规定的条件下，系统工作时，它的一个或几个性能参数不能保持在正常运行的状态；也就是其结构、组件、元器件等出现破损、断裂、击穿等，使零件丧失了由应用环境和技术条件决定的系统所要完成的功能。

系统故障自诊断是指系统的自身的硬件设计或者程序对系统正常工作状态和工作异常作出判断，并根据故障特征，诊断系统故障通过失效保护及处理程序，准确的定位故障。根据不同的故障类型，使系统进入到安全的工作模式。

故障自诊断系统的主要任务有以下几块：系统对系统自身的故障探测、诊断系统对故障类别的判断、系统故障定位及系统故障失效保护等等。故障探测定义为系统正常工作后，通过周期性地实时监测系统的运行状态，并通过系统设计好的诊断条件，判断系统有没有产生了故障；诊断系统对故障类别的判断就是故障自诊断系统在检测出故障发生后，自动告知系统故障的模式；故障定位认为在故障自诊断系统监测出系统工作异常，并已经进行了系统故障类别的判断，按照系统预定义的诊断条件定义具体故障位置并记录故障诊断条件参数。同时，为系统的失效保护提供输入信息；故障失效保护是系统故障诊断过程中最后一个环节，同时也是最重要的一个环节，使系统能够根据故障原因，采取不同的保护措施。

1）故障等级：通过诊断系统识别，准确定义该故障的故障等级。故障识别度越高，说明诊断系统对故障的定位越准确，也就越方便工程技术人员对故障的评价和维修。

2）故障诊断系统故障自适应：定义为故障诊断系统对于随时改变的的被测试对象具有自适应能力，能够充分、及时的利用改变信息产生来调节自己的诊断策略。

3）故障系统的误报率和漏报率：误报认为系统没有出现故障反而被错误的认为发生了故障；漏报定义为系统发生故障，故障诊断系统未能诊断识别出。好的故障诊断系统和程序应尽可能将误报率和漏报率降低最小。

4）故障诊断系统的故障识别度：定义为故障诊断系统对于系统存在的不同故障的区别能力。故障诊断系统的故障识别度越高，认为故障诊断系统对系统产生不同故障的区别能力越强，从而，故障的定位就越准确。

5）故障诊断系统检测的即时性：定义为当系统在发生故障后，故障诊断系统能够在最短时间内检测到系统存在故障。故障发生的时刻到被检测出的时刻两者的时间差越短，说明故障检测的即时性越高，系统越安全可靠。

6）故障诊断系统的鲁棒性：通常指诊断系统在存在电磁干扰、振动、环境温度变化等各种恶劣复杂的使用情况下，故障诊断系统依然正确诊断故障，与此同时，具有误报及漏报最小化。故障诊断系统的鲁棒性越强，说明故障诊断系统的可靠性越高。

7）故障诊断系统的故障检测的灵敏度：定义为故障诊断系统对系统可能存在各种故障信号的检测的识别能力。故障诊断系统能检测到的故障信号越小，能够说明其故障信号检测的灵敏度越高。

参考文献：电动助力转向系统故障诊断与失效保护 

            作者：张 瑞

            硕士论文   2014.10

            中国科学技术大学