嵌入式软件开发全生命周期管理

2019-08-23王飞飞魏倩雯王龙

电子技术与软件工程 2019年13期

文/王飞飞魏倩雯王龙

嵌入式软件在汽车行业得到了越来越广泛的应用，汽车行业由过去的机械与电子的简单组合发展为更为复杂的电控系统，由机械时代进入电控时代，在电控时代，嵌入式软件开发质量直接影响到了产品质量，因此，嵌入式软件开发得到了越来越广泛的关注。

16949 标准是广泛适用于汽车行业的国际标准体系，几乎所有的整车厂及汽车行业供应链上的组织均遵循该标准，新版16949标准：IATF 16949：2016在继承之前的ISO/TS 16949标准的基础上专门新增了针对嵌入式软件的全新要求，用以规范汽车产品中嵌入式软件开发。新版16949标准在8.3.2.3条款中明确指出：组织应有一个质量保证过程，用于其带有内部开发的嵌入式软件的产品。应采用软件开发评估方法来评估组织的软件开发过程。组织应按照风险和对顾客潜在影响的优先级，为软件开发能力自评估保留形成文件的信息。组织应将软件开发纳入其内部审核方案的范围。

由此可见，嵌入式软件开发已然成为国际通用的汽车行业标准中的一项重要内容，每一个涉及嵌入式软件开发的汽车行业的组织都必须保证其组织内部的嵌入式软件开发形成规范的开发流程，配备规范的质量保证工具，具备有效的手段实现对嵌入式软件全生命周期规范管理，并引入满足16949体系要求的软件评估方法（CMMI或者 A SPICE），才可以保证最终交付的嵌入式软件产品满足16949体系的要求。

本文阐述了汽车电控系统嵌入式软件V流程开发模式，明确了汽车电控系统嵌入式软件从需求

定义到系统验证的开发流程；并针对汽车电控系统嵌入式软件开发V流程中各环节的开发及管理工具提供了解决方案，确保通过该解决方案可以实现汽车电控系统嵌入式软件全生命周期的管理。

图1：嵌入式软件开发V流程

图2：嵌入式软件开发及管理工具

1 嵌入式软件V流程

从接收到客户需求，到最终交付满足客户需求并且符合适用的法律法规相关要求的产品，嵌入式软件开发需要经过系统需求定义、系统架构设计、系统详细设计、算法开发、软件实现等一系列环节，而每一个环节均要经过采用相应手段的测试及验证，来保证相关交付的准确性和可靠性。这是个逐层开展及验证的过程，为保证嵌入式软件开发质量，建议采用V流程开发模式，如图1所示。

需求是设计的基础，只有明确了需求，才可能开发出让客户满意的产品。嵌入式软件开发中需通过市场问卷调查、市场调研、客户满意度调查、客户沟通会等方式去挖掘客户需求，形成书面化的客户需求。客户需求文档是客户需求的直观表达，客户需求文档需要得到客户的确认。

客户需求文档是客户需求的直接体现，无法直接用于指导开发，需要由专业系统开发人员将客户需求转化为专业术语描述的条目化需求，用以指导后续的设计及开发工作，即系统需求。在将客户需求转化为系统需求的过程中，需要挖掘分析客户可能并不会直接提出的隐含需求，尤其是国家相关法律法规带来的隐含需求，这些隐含需求同样是系统设计开发的基础，必须得到满足。

由客户需求到系统需求，需建立需求跟踪矩阵，建立客户需求与系统需求的双向跟踪追溯关系，确保客户需求得到了全面的覆盖。

系统需求完成之后，系统架构开发人员需要根据系统需求完成系统架构设计。架构是将需求分配至解决方案的基础，通过架构设计明确各产品组件之间的接口。通常，可以把软件系统中的组件当作一个具备独立功能的物体，做好各个组件分配工作，能够有效提升系统资源应用效率[2]。产品组件得以集成为最终的产品，一个产品包含多个层次的产品组件。嵌入式软件系统架构设计需明确嵌入式软件与硬件之间的接口，同时应明确嵌入式软件内部各产品组件之间的接口，嵌入式软件系统架构设计应按照产品组件的层级逐层开展。

基于系统架构设计，系统开发人员需完成各产品组件的详细设计，用于指导软件开发人员进行软件实现。在详细设计过程中，需明确各产品组件要实现的具体功能以及具体功能的实现方案。

系统详细设计完成后，模型开发人员基于详细设计文档开展算法开发工作，所开发算法需要经过相关人员评审，确认满足系统详细设计文档的要求。

汽车电控系统嵌入式软件的软件实现通常包括基础软件和应用软件两部分，基础软件部分需要完成相关驱动的代码开发，基础软件部分通常通过C语言编写代码实现；而客户绝大多数的控制需求以及诊断需求均是通过应用软件部分实现的，应用软件部分通常通过Mathworks公司的Matlab软件中的simulink & stateflow实现。应用软件部分，首先需要完成浮点模型的搭建，基于完成的浮点模型，完成单元功能测试；单元功能测试通过后，需完成浮点模型定标，将浮点模型转化为定点模型，在此过程中需要注意精度损失问题。

汽车电控系统嵌入式软件基础软件部分，完成手写代码的编制后，需要完成针对手写代码的单元测试，确认手写代码逻辑功能正确性，并出具离线测试报告，单元测试完成后，需完成基础软件预编译，完成基础软件多模型之间的联调；应用软件部分定标完成后，需要将定标后的模型与浮点模型进行对比，确保定标在允许的误差范围内，并开展多模型检查，确认应用软件模型之间的接口、头文件定义等没有冲突。

汽车电控系统嵌入式软件基础软件部分和应用软件部分开发完成后，需要通过集成平台完成基础软件和应用软件的集成，完成集成后的嵌入式软件应该具备了嵌入式软件系统所要求的所有系统功能，集成完成后，需完成集成测试，确保嵌入式软件系统具备进行系统测试的基本条件。

集成测试通过后，嵌入式软件配套相应的汽车电控单元完成系统放行测试，系统放行测试通常在硬件在环系统上完成，通过设计测试用例，完成系统功能以及系统接口的系统级放行测试。

完成系统级放行测试后，需开展基于实际使用环境的验证，将嵌入式软件以及与之相配套的电控单元硬件，置于客户实际使用环境中开展系统验证，确保客户需求得到全面满足和验证。

2 嵌入式软件开发及管理工具

在嵌入式软件开发的整个V流程中，每个环节都需要一定的开发及管理工具，来保证开发的规范性，提高开发效率。本文给出了汽车电控系统嵌入式软件V流程各环节的开发及管理工具，为实现嵌入式软件全生命周期的管理提供了整体解决方案。如图2所示。

2.1 嵌入式软件开发工具

系统需求定义阶段的需求建立及需求管理工具可选用IBM的DOORS或者PTC的ALM，IBM DOORS是一个业界领先的需求管理工具，可以满足系统需求定义阶段，客户需求、系统需求、需求跟踪一系列要求，但IBM DOORS是相对独立的需求管理工具，很难与IBM其他产品集成整合。PTC ALM中需求管理是整个软件的一个组成部分，可以与配置管理、流程管理等其他组成部分有效配合，无缝衔接。

PREEvision是一款汽车电控系统嵌入式软件系统架构设计的理想的开发工具，可实现基于模型的架构设计。与传统的架构设计工具Excel、Visio等相比，PREEvision可以清晰高效的逐层建立系统架构，并使得各层架构形成一个整体。

系统详细设计阶段，可以通过IBM的DOORS来完成系统详细设计；或者通过PTC的ALM完成系统详细设计，两者都是专业的需求管理工具。

在算法设计、软件实现、离线测试阶段，汽车电控系统嵌入式软件基础软件部分和应用软件部分所采用的开发工具有所不同，基础软件部分通常使用C语言进行开发，而应用软件部分采用Matlab作为开发工具，离线测试阶段，基础软件部分可采用Tessy进行单元和集成测试，可以自动搭建测试环境、执行测试、评估测试结果；而应用软件部分，则可以直接利用Matlab生成测试用例，执行单元和集成测试。系统集成阶段，可选用WindRiver作为开发工具，实现基础软件部分和应用软件部分的集成；流程和配置管理可以通过IBM的ClearQuest和ClearCase组合或者PTC的ALM实现。

硬件在环测试阶段，通过HIL平台运行自动测试用例，实现对嵌入式软件的全面放行，自动测试用例的开发及执行通过ECU-Test实现。ECU-TEST是TraceTronic公司开发的一款用于嵌入式系统测试验证的软件工具，ECU-TEST可实现所有测试环境的控制自动化操作，同时支持广泛的测试平台。

2.2 嵌入式软件管理工具

嵌入式软件V流程整个开发过程中的管理工具需要包括流程管理和配置管理两部分内容，IBM的ClearQuest是一款行业里比较通用的流程管理工具，ClearQuest作为流程管理工具，可实现定制化开发，用户可根据实际情况定制流程，实现对需求、设计、缺陷、变更等的流程管理；IBM的ClearCase是一款行业里比较通用的配置管理工具，可有效实现对配置项的存储、版本管理、权限控制等操作，确保配置项的可追溯性。而PTC的ALM提供了流程管理与配置管理一体化解决方案，ALM成功将流程控制与配置管理融合，通过流程控制对配置项的写权限的控制，确保每一次的改动都是受控状态，进一步提升了对产品质量的把控。

PTC的ALM可实现与嵌入式开发过程中的开发工具有效集成，从而实现各工具之间有效衔接，大大节省开发人员开发时间，提高工作效率。本文提到的嵌入式软件的开发工具PREEvision、Matlab、ECU-TEST等均可以实现与PTC的ALM集成，实现相关配置项的共享，可通过ALM去调用相关开发工具实现对相关文件的修改，也可以通过ALM去调用ECU-TEST自动执行ALM上存储的测试用例并将ECU-TEST的执行结果自动回传给ALM，因此在工具集成开发一体化方面，无疑ALM具备更大的优势。