有一阵子没有跟进汽车电子软件开发了，许久前参与一个项目，本人负责其中软件的设计，算是对此有一定了解，在此总结一下自己的认识。 汽车电子开发中软件内容大致包括三大类：（1）BSP开发，主要针对常见ECU开发平台编写板级支持包，例如Freescale的MPC5xx系列，Microchip的PIC单片机等。（2）操作系统，常见的有OSEK/VDX，例如Vector公司的osCAN，ETAS的RTA-OSEK等，参考[1]。（3）汽车电子应用软件，根据ECU的功能设计实现具体控制任务，此外应用软件还提供一些服务，针对大型的软件如多媒体服务、车载系统诊断、ACC等智能控制系统等。 在之前的设计中一般遵循V字流程，三类软件设计开发有顺序也有迭代。由于汽车电子开发的特殊性，决定了其软件在实时性、安全可靠性、分布式等方面要求较高，所以有了程序分析与验证等特殊要求。 1、OSEK/VDX操作系统:1993年左右针对汽车电子嵌入式系统的一些特性，几个汽车产商推出了OSEk/VDX规范，包括OSEK/VDX操作系统规范、OIL规范、COM通讯规范等。这种静态的支持定制的强实时操作系统，与汽车电子应用紧密结合，在任务编写等方面较常见RTOS特殊。此外，最核心的还是其总线协议规范（如果没有总线协议部分，汽车电子软件开发应该是更加开放、并且没有门槛的）。 2、AutoSAR规范：随着汽车电子开发厂家增加，软件的兼容性更加重要，于是推出了AutoSAR，将操作系统等规范为服务，并且通过RTE进行接口的统一封装。这样，各厂家、特别是广大的第三方软件就可以复用，降低了开发周期与开发成本，有利于整个汽车电子产业。 在AutoSAR中并没有被特别指定操作系统为OSEK/VDX，但绝大部分传统的汽车电子软件还是基于OSEKVDX，运行在低速的ECU上。在可以预见的未来，随着ECU成本降低和其他软件的成熟，可能将QNX或者vxworks、甚至Linux也未尝没有机会。 3、IDE开发环境：社区已经出现了较多版本的开源操作系统，符合OSEK/VDX或AutoSAR规范，其开发难度也随着降低，此外还有一些商用的RTOS可以采用。所以，操作系统的设计关注程度降低。但是如汽车电子等对实时性、安全可靠性有强要求的软件，其开发流程中一些关键点越来越受到重视。如何将基于模型开发融合到传统开发流程中去，是一个值得研究的问题。此外，模型的验证、从模型到代码自动生成，这些都亟待于解决的问题。虽然业界也有一些流程与规范，但是总体较为混乱。例如，ECU控制器的功能通过Simulink和Stateflow进行仿真与验证，然后将模型通过RTW转换为代码。但宿主开发环境如果采用Vector公司的Davinci开发环境进行AutoSAR兼容的软件开发，此时两者之间怎样配合则是问题，就是说RTW生成的代码需要导入到Davinci开发环境中进行集成。并且支持模型的逆向修改等。 4、准备开展的工作基于OSEK/VDX，通过RTE进行封装，满足AutoSAR规范（OSEK/VDX为之前CASOS修改版）；基于Eclipse等框架开发IDE，集成Cygwin下面的工具链，基于GUI方式进行OIL配置，代码编译调试（GNU Toolchains）。集成简单建模功能（或者与simulink进行集成），模型验证（或者与UPPAAL进行集成），代码生成等功能。 阅读了一下网站上的AutoSAR规范，好快，都4.0版本出来了，国内已经有四家在里面了，虽然都是Associate Partener，可是一大可喜进步啊。查找了相关的IDE工具，能够升级一下原来的思路，发现一个不错的开源Arctic[2]。  参考索引：
[1] http://en.wikipedia.org/wiki/OSEK[2] http://arccore.com/[3] http://en.wikipedia.org/wiki/AUTOSAR