当汽车内充满电子设备的时候，软件可靠性被提到了一个极为重要的位置。工业组织和工具制造商正在采取行动，帮助工程师确保那些生死攸关的代码的质量。
当电子设备开始控制机械系统，车辆制造商必须确保所有的系统完美无缺地运行。随着软件复杂度的上升，无错误软件的重要程度已经和无缺陷硬件的要求不相上下。[z1]当汽车制造商将越来越多的子系统添加到他们的车辆中时，他们不仅仅要保证每个子系统都能单独正常地工作，还要确保不同子系统可以正常地交互。
软件缺陷会导致相关人员悲剧性的后果，同时那些必须修正的错误也会带来大量的售后成本支出。例如就在去年，Jaguar不得不在北美、欧洲和日本召回了68 000辆汽车，就是因为存在一个系统错误，这个错误会导致控制器在检测到润滑油压力大幅降低后不经意地挂入倒挡。
制造业试图通过主动的方法来定位软件质量问题，例如通过MISRA-C:2004，这是一系列推荐的编程实践方法
，由“汽车制造业软件可靠性协会”（Motor Industry Software Reliability Association，www.misra.org.uk）制定。这个组织在1998年发布了第一个版本，其中包含128条更安全地编写C语言代码的规则。从那个时候开始，这些指导原则已渗入到从太空到矿井的每一应用场合。
作为实施这一规则的结果，许多编译器产商提供了MISRA-C代码检查器，并且修改他们自己的代码以顺应这个标准。同时，MISRA核心小组继续和美国的SAE（汽车工程师联合会，Society of Automotive Engineers），日本的类似组织JSAE、 JAMA （日本汽车制造商联合会，Japanese Automotive Manufacturers Association），以及ISO（国际标准化组织，International Organization for Standardization）一起合作进行不断的改进。新的第2版添加了一些新的算法规则，精炼了原始文档。版本2也特殊指令替换了某些一揽子规则（blanket rules），将一些原来的建议性规则定型为强制性[z2]（do-or-don’t）规则。版本2总共包含了121条强制性规则和20条建议性规则，并在整体框架上和版本1保持兼容。
MISRA
创建软件的理想过程是一个“一次生成即保证无误（correct-by-construction）”的流程，这个流程确保没有任何错误会被遗留到正式发布的代码中。由于这种理想的过程事实上并不存在，汽车工业不得不继续投资于软件测试之中。就像在其他复杂系统验证领域一样，软件测试的革新还没有制造出一个“魔弹”来替代之前的所有方法。相反，在新的测试工具出现的时候，用户倾向于将他们应用在现有方法之上，而不是用它来实现全面的软件验证。
所以工程师们继续使用着最直接的软件验证方法——功能测试以及分析代码本身的被称为“静态”的技术。在2004年的一个调查当中，分析组织VDC调查了软件测试市场上15家重要的提供商，其中最大的是提供Rational代码开发和测试套件的IBM公司。这个市场上的许多工具包费用在平均到每个开发人员（per-seat）的情况下[z3]并不昂贵。
此外，汽车工业就像其它依赖于关键任务处理软件的行业一样，一直在试图发掘每一种可以提高代码可靠性的手段。绝大多数公司出于这个目的至少评估了每一个可能帮助他们解决问题的技术。因此，几乎每一个工具提供商都可以给出一个令人印象深刻的客户名单，名单中包括了许多的汽车制造商和子系统提供商。但是，这些工具中只有极少数被这些厂商实际应用到他们的批量生产线的主流代码开发流程中。
PolySpace Technologies公司发布的“PolySpace for MISRA”是一个符合MISRA-C: 2004描述，适用于静态测试的工具，强调了MISRA-C的重要性。PolySpace是一个最早派生于航空领域工作需求的工具，它使用一项被称为“抽象解释”的技术来分析源代码。通过检查代码中的数据流，以及所有变量可能具有的数值，这个工具可以在没有使用功能测试和回归测试的情况下检测程序的运行期错误。
同样，像Programming Research（PRQA）和LDRA这样的工具提供商，都在他们的软件测试套件中包含了对MISRA标准一致性的检测。在PRQA的产品中，他的“MISRA一致性模块”（MCM）就被包含在一套软件代码分析和质量评估的套件之中，这个套件也可以用于软件创建过程本身的过程管理。
工业观察家们相信，IEC-61508功能安全性标准（www.iec.ch）将会很快替代MISRA-C成为汽车系统事实上的标准。这个标准提供了一系列的指导，目标是在电气和电子系统领域达到功能安全性的要求，减少那些特殊的、可确定的高风险事件的风险。这一标准涵盖了设备设计和工程管理过程，通过检测过程函数的正确性和安全性，提供了风险评估的方法，构成了特殊行业安全性标准的基础。
OSEK和Nexus
近来汽车工业自发地在决定性的操作系统上采用符合OSEK标准的RTOS代码，并且通过使用符合Nexus标准的硬件调试器来获得全面的实时跟踪能力，这些正式的评估手段都是逻辑上的进步。
最早由德国的Karlsruhe大学发起的OSEK/VDX （汽车电子/车辆分布执行开放系统和对应接口，open system and corresponding interfaces for automotive electronics/vehicle distributed executive）项目支持软件在多个项目间的可移植性和可重用性，节约了大量的开发和重新开发ECU（电子控制单元，electronic control unit）软件的成本。
虽然OSEK是Siemens公司的注册商标，其指导委员会和技术委员会的成员却来自于欧洲的汽车制造商、半导体供应商和软件开发商。OSEK包含3个领域：ECU之间的通信、网络管理和操作系统。一个被称为Modistarc的补充内容包含了验证基于OSEK/VDX的分布式结构的方法和工具。这一规范的最新版本可以在www.osek-vdx.org直接下载
