|
本文翻译的是Mathworsk公司撰写的Development of AUTOSAR Software Components with Model-Based Design，希望与大家一起共同学习进步，如有错误请大家指出。 “摘要” 本文展示了工程师如何在已有模型的情况下，在不需要进行模型修改的情况下，创建符合Autosar标准的件模型以及通过软件组件的描述来创建Simulink模型。在介绍之前，本文介绍了基于模型的设计Model-Based-Design（以下使用MBD）与Autosar概念，并建立了一些术语来解释为什么我们要将Autosar与Simulink相结合。 “介绍” 随着整车内ECU数量以及单个ECU内软件的复杂度的逐步增高，汽车软件行业需要一个开放，标准的软件架构来将未来整车、单个ECU内软件的复杂程度限定在一个可以控制的范围内。Autosar （Automotive Open System Architecture，汽车开放系统架构）就是这样的一个组织，目前组织已经联合了超过100个整车厂、零配件供应商、工具链供应商、半导体电子公司来为未来的ECU共同建立一个标准架构。目前已经许多OEMS以及供应商已经开始在部分车内开发、整合、集合符合Autosar标准的功能组件。 Autosar2.1标准已经被许多公司视为是一个较为成熟的标准，其中对于指定的应用层软件组件的概念与信息的定义已经成熟。许多工具链供应商纷纷开始结合自己的技术为Autosar架构开发新的商业工具链。在2006年大众公司已经成功使用MBD方法来设计符合Autosar标准的ECU并整合在已有的E/E电子电气环境中。 为了应对软件、算法的复杂程度指数增加，汽车工程师开始使用MBD方法，这个已经在业内被广泛接受。MBD可以在软件早期开发阶段提供明确、可执行的规范，自动V&V（Verification、Validation）以及自动代码生成这些额外的优点使得开发效率显著提高。 作为ECU网络的标准架构，Autosar在汽车行业变得越来越重要，尽管现阶段大家只是将关注点放在标准的定义与完善，但许多OEMS以及供应商已经开始将Autosar纳入未来软件开发流程中。这就需要一系列完整的工具链，从上到整车级别的ECU的架构设计，下到使用MBD方法设计符合Autosar标准的功能组件，以及开发运行环境与基础软件。 “基于模型设计” 传统的嵌入式软件开发包括书面设计、手工编码，以及如代码检查，单元集成测试等验证工作。其中许多流程缺少工具的自动化需要手工完成，因此既耗时又容易产生错误。工具链的集成的缺失是另一个容易产出错误的方面，此类错误在软件开发过程中往往探测较晚而且需要花费很大代价。 为了应队这些挑战，MBD已经成为汽车行业广泛使用与认可的方法，仿真测试不仅可以洞悉系统的动态、算法方面，而且模型还有如下优点： （1）作为可执行规范 （2）交流软件需求规范，为顾客与供应商之间提供接口定义 （3）为开发算法提供汽车系统以及驾驶员、环境、路况条件等模型提供虚拟原型 （4）产品的自动生成 这些MBD的活动使工程流程更加专注于防查错以及错误的早期检测。项目早期的V&V可以降低晚期发生错误带来的风险。正如图1所示，MBD使得模型位于开发流程中的核心，这样工程师可以创建可执行规范，自动生成嵌入式代码，在模型中执行V&V活动。 “需求与代码追溯” 使用MBD开发嵌入式软件始于客户对软件需求要求的大幅提高，工程师必须确保模型以及最终生成的代码满足系统需求。因此，需要关联每一个需求至相应的模型部分，这种追溯能力是十分重要的。工程师搭建一个详细的软件设计模型，并通过持续不断的V&V流程来确保所搭建的模型是满足需求的！由状态机以及基础模块组成的模型可以双向直接链接到需求文档或者需求管理工具中。测试用例（由工程师定义或者自动生成）也可以被直接链接到对测试覆盖率的需求中。在开发的后期阶段，生成模型代码后，Mathworks公司的Embedded Coder可以产生代码声明与模型之间的链接，正如工业标准IEC61508、Aspice所规定的。 未来待续 |
|
|
