汽车嵌入式系统的高可靠性开发

苏万樯，谢小娟

（奇瑞汽车股份有限公司，安徽 芜湖 241009）

嵌入式系统是一种完全嵌入受控器件内部、为特定应用而设计的专用计算机系统，通常执行的是带有特定要求的预先定义的任务。在汽车上嵌入式系统的应用也是随处可见的：发动机控制、变速器控制、车身控制、ABS、车载导航、车载娱乐系统等，都是嵌入式系统的典型应用。但由于汽车是一种可移动的高速交通工具，是一种涉及到驾驶员、乘客、周边人员及环境的交互复杂系统，对于车上与人身安全相关的嵌入式系统，一旦发生失效或故障，就可能造成车毁人亡的严重后果，相关厂家也要承受巨大的车辆召回损失和商誉损失。因此，汽车上使用的与安全相关的嵌入式系统，比如发动机控制系统EMS、自动制动防抱死系统ABS、安全气囊控制系统等，与一般的嵌入式系统相比，对可靠性的要求更高。与此同时，随着各种新技术的使用，使得汽车嵌入式系统的功能也越来越复杂，采用怎样的流程和方法来高效地开发高复杂度同时又具备高可靠性的车用嵌入式系统，一直成为业内开发人员研究的热点［1］。

1 基于模型的V字开发流程

随着计算机技术的发展，基于模型的V字开发流程，已经成为高可靠性汽车嵌入式系统开发方式的主流。这种方式以模型描述业务逻辑，通过自动代码生成工具，从描述业务逻辑的模型直接生成上层代码，再与底层手写代码及相关硬件集成，有效解决了开发高复杂度嵌入式系统的 难 题［2］。 典 型 的 基于模型的V字开发流程如图1所示。

图1所述各个流程的活动、执行人员及交付物详述如下。

1）系统定义 这个阶段的活动是明确所需要开发的系统的各项性能指标，包括可靠性、成本方面的要求。这些性能指标必须是可量化可验证的。本阶段的输入材料一般为客户合同、项目可行性分析报告、适用的法规标准等文档。本阶段的执行人员一般是项目组织人员及项目管理人员。本阶段的输出交付物为系统定义文档。

2）需求分析 这个阶段的活动是根据系统定义的要求，从系统使用者的角度制定详细的系统开发需求。为便于需求的管理，此处编写的需求以条目的形式呈现，要求制定的每一条需求不重复、不遗漏、可测试。本阶段的输入材料为1）的输出交付物系统定义文档。本阶段的执行人员一般是系统开发方的资深工程师、整体架构设计师等人员。本阶段的输出交付物为需求定义文档。

3）架构设计 这个阶段的活动是根据需求定义，对整体需求划分模块，并制定各模块之间的接口文档。一般可以划分为上层业务逻辑模块、底层手写代码模块、硬件模块，当系统比较复杂的时候，还可以将这3个大模块进一步划分。本阶段的输入材料为2）的输出交付物需求定义文档。本阶段的执行人员一般为系统开发方的架构设计师或总体工程师。本阶段的输出交付物为模块接口文档。

4）模块开发 这个阶段的活动是各模块的开发人员根据划分后的模块需求和接口文档，各自进行所负责模块的开发。一般包括上层业务逻辑模块、底层手写代码模块、硬件模块的开发。上层业务逻辑模块通过建模工具来实现业务逻辑模型，再利用自动代码生成工具，将此业务逻辑模型直接转换为C代码。底层手写代码模块一般是底层硬件驱动及软件服务，根据接口文档开发。硬件模块则是嵌入式系统的硬件实体。本阶段的输入材料为2）的输出交付物需求定义文档和3）的输出交付物模块接口文档。本阶段的执行人员为各模块的责任开发工程师。本阶段的输出交付物为策略模型及自动生成代码、底层软件手写代码、控制器硬件样件及各模块的设计文档。

5）系统集成 这个阶段的活动是将上层业务逻辑模型自动生成的代码和底层软件手写代码集成编译，形成可执行文件，并刷入相应的控制器硬件中，形成一个可运行的控制器样件。本阶段的输入材料为4）的输出交付物策略模型及自动生成代码、底层软件手写代码、控制器硬件样件。本阶段的执行人员为系统集成工程师。本阶段的输出交付物为可运行的控制器样件。

6）单元测试 这个阶段的活动是以各个模块为单元，按各模块的设计文档编写单元测试用例，测试各模块的所有功能是否实现，并对软件模块的代码覆盖率进行评估；对硬件模块的设计性能进行测试，评估硬件各项指标是否达到设计要求。此阶段测试主要为白盒测试。本阶段的输入材料为4）的输出交付物各模块的设计文档。本阶段的执行人员为各模块的责任开发工程师。本阶段的输出交付物为各模块的单元测试报告文档。

7）集成测试 这个阶段的活动是将对集成后的控制系统进行集成测试，重点测试各模块的接口功能。根据模块接口文档编写测试用例和测试计划，对各模块接口进行测试，并测试各模块集成后是否能够正常工作，编写集成测试结果并跟踪反馈，此阶段测试为黑盒测试。本阶段的输入材料为3）的输出交付物模块接口文档及5）的交付物可运行的控制器样件。本阶段的执行人员为集成测试工程师。本阶段的输出交付物为集成测试用例、集成测试计划和集成测试报告。

8）系统测试 这个阶段的活动是根据需求定义文档，编写系统测试用例和系统测试计划，将控制器样件接入硬件在环测试设备进行全面的系统功能和性能测试，最后编写系统测试结果报告并跟踪反馈。本阶段的输入材料为2）的交付物需求定义文档及5）的交付物可运行的控制器样件。本阶段的执行人员为系统测试人员。本阶段的输出交付物为系统测试用例、系统测试计划及系统测试报告。

9）标定验证 这个阶段的活动是根据系统定义文档，在控制器的具体应用环境下，调整控制参数，验证各项性能指标达到要求。本阶段的输入材料为1）的交付物系统定义文档及5）的交付物可运行的控制器样件。本阶段的执行人员为标定验证工程师。本阶段的输出交付物为最终软件参数数据及验收报告。

这种基于模型的V字开发流程，对于多变复杂的业务逻辑，采用图形化的建模方式来实现，图形化的模型可以直接对应需求，便于沟通理解，也能够通过模型仿真等手段验证模型的正确性。验证正确后的模型通过自动代码生成工具直接生成代码，效率极高的同时避免了手工编写业务逻辑代码引入的人工编码错误。底层软件手写代码一般是涉及硬件驱动及标准化的底层软件服务，其代码相对比较固定，可重用度高，往往可以选择以往项目中已经过充分测试和验证的底层手写软件代码，略加修改甚至无需修改来实现。因此可以大大提高整个软件开发的效率及可靠性。对于硬件平台，可以选择业内成熟主流且集成度高的方案，可以保证硬件平台的可靠性。因此这种开发技术和方案，可以保证开发者 “正确地做事”。

在开发流程的这9个阶段中，1～5阶段为开发阶段，遵循自顶向下，逐层细化的原则，下一个阶段的开发依据直接来自上一个阶段，保证了从需求到设计到实现的一致性和可追溯性；6～9阶段为测试验证阶段，遵循自底向上，逐步整合的原则。每一个阶段的测试依据直接来自相应开发阶段的设计输入，即对于每一个被测试的开发阶段，其测试依据和开发依据完全一致，因此可以在流程上保证能通过测试的开发结果一定会符合原来设计时的需求。因此这种流程设计和要求可以保证开发者 “做正确的事”。

此外，对于第6阶段的单元测试，由于属于白盒测试，涉及到代码的具体实现，一般建议由此模块的开发工程师来完成，以保证开发效率。第7、8、9阶段的集成测试、系统测试及标定验证，一般应该由一个独立于开发团队的测试验证团队人员来完成，以保证测试的客观性和有效性。

2 奇瑞艾瑞泽7轿车的ECU开发流程

ECU （Engine Control Unit，发动机控制器）就是典型的一种高复杂度又需要具备高可靠性的车用嵌入式系统。以图2所示的2013年7月26日正式上市的奇瑞艾瑞泽7轿车的ECU开发为例，此ECU为联合汽车电子有限公司提供的ME17型ECU。该公司是中联汽车电子有限公司和德国博世的合资公司，主要从事汽油发动机管理系统、变速器控制系统、车身电子、混合动力和电力驱动控制系统的开发、生产和销售。

1）在系统定义阶段，ECU系统定义文档的内容应该包括目标车型、目标市场，目标市场适用的排放法规及油耗法规，客户要求的动力性及各种配置等内容。

2）在需求分析阶段，以ECU的怠速控制需求为例，可定义为：在发动机达到暖机状态时，不开空调，怠速转速为800r／min，转速波动在±30r／min之内。

3）在架构设计阶段，ECU的模块接口文档包括软件接口文档及硬件接口文档。软件接口文档描述发动机上层应用软件与底层驱动软件之间的接口函数定义、全局变量定义等，硬件接口文档描述ECU硬件需要具备的各个引脚功能及电气性能、电磁兼容性能、环境耐久、机械性能等要求。

4）在模块开发阶段，发动机控制策略的开发人员，通过建模工具，完成喷油逻辑、点火逻辑、怠速控制逻辑等模块的建模，根据发动机应用层软件与底层驱动软件接口文档配置自动代码生成工具的参数，然后通过自动代码生成工具生成能够带相应接口的C代码，可以和底层手写的驱动软件代码集成在一起，同时还能自动生成设计文档。底层软件开发人员根据底层软件需求手工编写代码。硬件设计人员开发ECU硬件。

5）在系统集成阶段，集成工程师将模型自动代码生成的C代码和底层手写的代码放在一个工程里进行编译调试通过，生成一个可执行的S19文件，并刷入到ECU硬件样件里，就形成了一个可运行的ECU样件。

6）在单元测试阶段，由发动机策略开发工程师进行发动机上层应用模型的单元测试，包括模型在环测试 （MIL）、软件在环测试 （SIL）及处理器在环测试 （PIL）。MIL是模型在仿真的环境里执行，验证模型逻辑的正确性；SIL是将模型转换成代码，在仿真环境里验证代码的正确性；PIL是将模型生成的代码通过专门的工具下载到处理器芯片中去，验证模型所生成的代码在真实芯片中执行的正确性。底层软件代码通过单元测试工具进行分支覆盖测试、条件覆盖测试、修正条件判定覆盖等白盒测试。对于ECU硬件样件的测试，按照硬件接口文档和硬件开发需求文档来进行。

7）在集成测试阶段，可以制作一个车辆模拟器来对ECU进行集成测试。这种车辆模拟器可以发出转速信号、相位信号、车速信号、水温信号、进气压力信号等传感器输入信号给ECU。车辆模拟器同时还能接收ECU发出的喷油、点火等执行器控制信号，并在模拟器面板上以指示灯或显示屏的方式显示出来。利用这种模拟器可以测试ECU能否正确读取输入信号、正确处理信号、正确输出控制信号，属于一种开环测试。

8）在系统测试阶段，将ECU接入专用的硬件在环测试 （HIL）设备来进行系统测试。HIL设备的硬件接口能够提供与实车完全一致的实时硬件信号给ECU，也能够实时地读取ECU输出的控制信号。HIL设备上的高速处理器还会运行一个发动机模型来对ECU的控制结果进行实时反馈，真实模拟ECU在实车环境下的工作，实现闭环测试。根据需求编写可运行在HIL设备上的系统测试用例，实现全面高效的系统测试。

9）在标定验证阶段，将ECU装到目标车型上，进行标定参数调整，并通过整车排放测试、整车油耗测试、整车驾驶性评价等试验，验证确定最终开发的产品能够完全满足客户的要求。

3 过程管理在基于模型的V字开发流程中的应用

如前所述，为了开发高可靠性的汽车嵌入式系统，采用了基于模型的V字开发流程。在此流程中要求从系统定义到需求分析到设计实现到测试验证，环环相扣，保持一致性和可追溯性。对于现代汽车上越来越复杂的嵌入式系统而言，涉及到系统定义及需求的条目往往很多，多的可以达到数千条至上万条细化需求，再加上每个需求对应的设计及实现，以及需求对应的测试用例及测试结果，需要保持一致性和可追溯性的内容非常庞大。再加上开发过程中系统定义和需求经常会发生变更，测试中发现问题，设计和实现也经常要修改，而且复杂系统的开发往往是一个团队多人开发，还需要实现大型开发团队的协调工作。这整个开发过程如果采用手工的方式，来维护从系统定义、需求、设计、实现、测试、验证的一致性，对稍微复杂一点的系统都是难以实现的，高可靠性的开发也就无从谈起。因此需要引入需求管理工具和配置管理工具来实现这个流程。

需求管理工具主要实现以需求为中心的对整个开发流程各个阶段信息流的管理。需求管理工具通过建立各个阶段之间的条目的链接关系，从系统定义条目可以通过链接跟踪到需求分析条目跟踪到设计实现，也可以跟踪到相应的测试条目，也可以从测试条目或设计实现追溯回相应的需求分析条目及系统定义条目。当需求发生变更时，需求管理工具要能够自动列出与此需求相关的需要同步更新的其他阶段条目。各阶段信息的链接关系如图3所示。

需求管理工具至少需要实现V字流程的左臂的各开发层级的条目之间的双向链接关系，及V字流程的左臂和右臂之间各层级开发要求和对应层级测试用例及测试结果之间的双向链接关系。

配置管理工具主要实现对开发项目配置及人员的管理，记录产品开发的过程。通过控制、记录、追踪，对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能设定，配置各个开发人员的权限和开发角色，实现并行开发协同工作，达到开发团队的有效管理。一个典型软件配置管理基本流程如图4所示。

4 ISO 26262的要求

ISO 26262是从电子、电气及可编程器件功能安全基本标准IEC 61508派生出来的一个国际标准，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。适用于最大质量不超过3500kg批量生产的乘用车。ISO 26262从2005年11月起正式开始制定，已于2011年11月正式颁布，成为国际标准。中国也正在积极进行相应国标的制定。目前国内越来越多的厂家也开始重视这一标准［3］。

此标准主要针对安全性相关的汽车电子系统进行分析和指导，其概览如图5所示［4］。

可以看到ISO 26262的流程在系统级产品开发部分与我们前面讨论的基于模型的V字开发流程是极为相识的，整体也是一个V字开发流程。除了系统级别的产品开发环节外，ISO 26262还增加了概念阶段和生产及运行阶段的流程开发要求，覆盖了一个项目从概念到设计开发到生产运行到最终报废的全生命周期过程，其流程要求的覆盖更为全面。

ISO 26262中的关键概念是汽车安全完整性等级 （Automotive Safety Integrity Level， 缩 写 为ASIL）。ASIL分为A、B、C、D四个等级，其中ASIL D为最高等级。等级越高，代表一旦此功能失效，导致的人身安全风险越高，则此项功能对应的设计方法、可靠性、测试方法等技术指标就要求越高。ASIL从3个方面进行评估：功能失效造成的危险对驾驶员或其他交通参与人员造成伤害的严重程度S，会出现此种危险的工况出现概率E，危险出现时驾驶员和其他交通参与人员及时采取控制行动以避免危害的可控性C。

因此应用ISO 26262以提高安全相关的嵌入式系统可靠性时，首先要从S、E、C三个维度去分析ASIL等级。如表1所示。

表1 ASIL确定表格

S分为S0、S1、S2、S3四级，从0到3，代表伤害程度逐级增强，S0代表无伤害，S3代表危及生命的重伤或致命伤。E分为E0、E1、E2、E3、E4五级，从0到4代表工况发生概率从小到大，E0代表此工况不可能发生，E4代表此工况是常见工况。C分为C0、C1、C2、C3四级，从0到3代表危险发生时可控制程度从容易到困难，C0代表完全可控，C3代表几乎无法控制。

S0、E0和C0满足任何一个时，认为此项功能不影响安全性，因此表1中没有列出。其他的情况下，根据不同的S、E、C级别组合，可以从表1中查得相应的ASIL等级。其中QM代表在这种组合下，此项功能不影响安全性，通过一般品质管理即可保证。

汽车安全完整性等级分析在项目开发的概念阶段完成，确认当前开发的嵌入式系统涉及的功能需要满足的ASIL等级后，就可以进入产品开发的V字流程。在产品开发的V字流程中，根据确认的ASIL等级，ISO 26262标准详细规定了各个阶段每一种ASIL等级应采取的技术方案、测试方案、过程组织要求，使得最终开发出的产品可以达到所要求的ASIL等级。

因此，对于与人身安全相关的汽车嵌入式系统开发，在前述基于模型的V字开发流程基础上，采用需求管理工具及配置管理工具进行过程管理控制。再按ISO 26262的要求进一步扩展，在概念阶段进行汽车安全完整性等级分析，然后按相应的ASIL等级在V字开发流程的各个阶段采用标准所指定的技术方案，并补充实施生产及运行阶段的要求，就可以使整个项目符合ISO 26262的要求。

仍以奇瑞艾瑞泽7轿车的ECU的开发为例，这个ECU是用于电子节气门的发动机控制，一种可能导致危险发生的失效是ECU对发动机的电子节气门控制失效，导致电子节气门一直处于全开状态。为了确定这种危险对应的安全完整性等级，我们分析这种危险的严重程度，如果电子节气门一直处于全开，会导致车辆一直处于加速状态，可能导致车毁人亡的严重后果，因此严重程度可以设为S3；分析发生这种危险的工况可能性为一般常见，概率等级设为E3；分析发生这种危险时驾驶员对车辆的可控性，一般驾驶员只要不过于慌乱，可以通过猛踩制动、将档位挂入低档、擦撞护栏等方式使车辆停下，可控性设为C2。根据表1可查得，对于这种危险将其汽车安全完整性等级设为ASIL B。

对于ASIL B等级的功能，要求ECU进行软件设计时，对相关信号的可靠性设计专门的在线诊断程序，当发现电子节气门信号不可靠时，ECU将喷油量和点火角限制到一个安全值，使车辆无法持续加速。在硬件可靠性方面，根据

ISO 26262中的要求［4］， 不 同

ASIL等级对随机硬件失效率有不同的要求，如表2所示。因此根据表2，ECU的

ASIL等级被定为B时，其硬件的可靠性设计要按随机硬件失效率低于10-7每小时的要求进行。

表2 随机硬件失效率目标值

5 工具链介绍

要完成前面所述的高复杂度、高可靠性的车用嵌入式系统开发，先进的开发工具链是必不可少的，笔者此处也介绍一些主流的开发工具。对于需求管理及配置管理方面，IBM公司提供的Rational DOORS、 Rational ClearCase、 Rational ClearQuest，是多个行业广泛应用的工具。建模方面Mathwork公司的Matlab产品及ETAS公司的ASCET产品是汽车行业内常用的建模工具，dSPACE公司的Simulator产品及ETAS公司的LABCAR产品是汽车行业内常用的系统测试硬件在环工具。ETAS公司的INCA系列产品是汽车行业内常用的标定工具。

6 总结

为了满足高可靠性汽车嵌入式系统的开发要求，提出了基于模型的V字流程开发方式，这种开发方式采用基于模型的嵌入式软件开发技术，流程上以需求为核心，自顶向下逐层细化开发，由下而上，逐步集成测试，每一层次的开发依据和相应层次的测试依据保持一致，保证所有需求都能够得到正确的实现。引入自动化的需求管理和配置管理工具，形成合理的开发工具链，使得开发过程中庞大的信息流及团队人员组织得到有效的管理，确保系统的高效开发。对于人身安全相关的车用嵌入式系统，进一步引入ISO 26262功能安全标准，通过对汽车安全完整性等级分析，确认功能安全等级，对产品V字流程开发中的各个阶段采用标准规定的相应功能安全等级的技术方案，从而进一步提高最终产品的可靠性和竞争力。

［1］郑宇平，王强.汽车嵌入式系统开发方法体系架构及相关流程探讨［J］.电子制作， 2013 （15）： 209.

［2］魏学哲，戴海峰，孙泽昌.汽车嵌入式系统开发方法、体系架构和流程［J］.同济大学学报 （自然科学版），2012，40 （7）： 1064-1070.

［3］刘佳熙，郭辉，李君.汽车电子电气系统的功能安全标准ISO26262［J］. 上海汽车， 2011 （10）： 57-61.

［4］ ISO 26262， Road vehicles Function safety［S］.2011.