关于MATLAB和Simulink开发嵌入式软件的步骤和详细内容

模型质量目标（Model Quality Objectives，以下简称 MQO）的标准是由一流的汽车厂商和 MathWorks 公司共同制定，目的是当在嵌入式软件开发中 OEM 和供应商进行 Simulink 模型共享时，可以清晰定义并简化双方的协作，并最终提高软件产品的质量和完整性。

首先，基于软件开发生命周期的四个不同阶段用到的四种设计模型，本文定义了一套软件开发方法。然后，针对每种模型，提出了一个名为 MQO 的特定质量目标。每个目标被定义为一组质量特征和一些可衡量的标准，称为模型质量要求（Model Quality Requirement，MQR）。此外还提供了一些额外的规范，来管理与 MQO 和 MQR 相关的计划和质量评估活动。在文章最后也对汽车工业采用 MQO 的预期影响进行了总结。

为什么制定模型质量目标

为了加速嵌入式软件的开发，用 Simulink 软件开发的设计模型在业界广泛使用。这些模型使工程师能够完成各种工程任务，如频域分析、桌面仿真、形式验证和自动代码生成。这个开发过程被称为基于模型设计。

出于验证需求和快速地探索设计方案的目的，可以在非常早期的阶段开发设计模型。这些模型也可以逐步改进，直到它们达到一定成熟度，可生成符合国际软件安全标准的代码。为了逐步增加设计模型的成熟度，需要涉及到系统工程、控制工程和软件工程等不同的工程学科。使用相同的语言、工具和模型进行协作，是提高工程师之间的沟通、降低工程费用和缩短开发时间的好方法。然而，由于在不同的项目阶段使用设计模型有不同的规程，可能会出现关于模型的作用和它们代表的内容间的混乱。

对模型代表的内容的错误解释会导致错误地使用这些模型，并最终影响所产生的软件的质量。参与制定 MQO 的 OEM 和一级供应商分享了许多关于成熟度不够或存在漏洞的模型被过早地确定为“可用于编码”的惨痛案例。

因此，有可能出现超出计划的开发人力投入、问题、与职责相关的争论等。为避免这种情况，文章旨在阐明设计模型在嵌入式软件开发中的作用，并规范可测量的标准，以验证其质量。

这种方法的灵感来自于2010 年由一些汽车厂商和 MathWorks 定义的软件质量目标（Software Quality Objectives，SQO）[1]，当时汽车制造商和供应商之间的大多数交流都是基于文本规范和手工代码。在以下方面，这种方法还可更进一步：模型共享的规范化，于 2014 年由 Bosch [2]所定义；ISO 26262-6 等软件安全标准所推荐的技术与措施的实现 [3]。

制定模型质量目标的目的是：

为软件开发定义设计模型的主要用例

根据它们的用例，定义评估模型质量的标准和通用方法

软件开发和模型设计

文章定义了一种基于四类设计模型的开发方法，这些设计模型支持 V 流程的左侧。

图 1：基于模型设计/MQO 软件生命周期

基于模型设计/MQO 的软件开发生命周期包含五个具体阶段，见图 1 中标示的 1 到 5。后面也将讲述有关阶段的更多细节。

图 2 列出了基于模型设计/MQO 的软件开发生命周期与业界其它软件开发生命周期的映射关系。设计模型所支持的阶段已用黑色背景突出显示，基于模型设计（Model-Based Design，简称为 MBD）。

图 2：基于模型设计/MQO 的软件阶段与其他工业标准的对照[3][4][5][6]

软件计划阶段

本节定义了在准备使用设计模型前必须执行的计划活动。这些活动在使用功能模型时是推荐的，在使用架构、组件设计和组件实现模型时是强制要求的。这些概念中的大多数已经在诸如 DO-331[5]之类的安全标准中得到贯彻。

范围定义：不是所有的设计模型都适用于所有的项目。例如，基于模型设计的范围可以简化为单个软件组件的开发，或者只被用于支持软件架构设计规范。项目应定义设计模型所支持的软件开发阶段。在所属的软件开发阶段，每个设计模型都应该作为其所属阶段的工作产品被独立管理。

工具定义：在项目开始时，支持设计模型的开发和验证的工具应该被鉴别和分类。如果项目要求，这些工具应是合格的。

标准定义：在进入软件架构阶段之前，应该定义用于支持设计模型开发的建模标准。在进入软件组件实现阶段之前，应该定义用于支持设计模型开发的编码标准，或者最好在进入软件组件设计阶段之前定义。

MQR 识别和分配：在项目开始时，项目相关方应识别并同意 MQR。一些 MQR 应该随项目需求（例如，模型和代码覆盖度准则）而调整。每个 MQR 都将被分配给项目相关方。

MQR 的实现策略：一旦为项目定义了 MQR，就应该定义实现这些目标的策略。策略可以包括与项目里程碑对应的中间步骤，特定培训，或工具迁移流程。例如，建议逐步提高覆盖度标准；不要等有了软件的最终版本，再执行大部分的测试开发工作。

MQR 一致性证明：在项目结束时，应该规划并证明项目 MQR 的一致性。对每个 MQR 的验证都应提供报告，这些报告由负责 MQR 的项目相关方提交。当不满足 MQR 时，必须提供充分的理由（例如，覆盖度未达标需要被证明是合理的）。负责合规评估的人应当具备理解这些理由的必要技能。

软件需求阶段

本节重点介绍软件需求阶段开发的功能模型。功能模型的作用是澄清和细化复杂的动态行为，这些行为将被转化为软件需求。

在大多数情况下，功能模型和软件需求由负责软件需求的人同时开发。功能模型工程师帮助固化软件需求（what），而在鉴别好的设计方案（how）方面则有待在设计和实现阶段进一步精细化。功能模型通常被称为可执行规范，因为它提供了满足功能需求的功能行为。然而，功能模型并不能取代软件功能需求。功能模型用于软件需求的验证活动。

功能模型侧重于算法和方程的正确性，它不必考虑与嵌入式软件开发相关的设计约束。然而在开发功能模型时，应该预测硬件平台的主要特征及其对软件需求的影响。

如果软件功能需求易于实现，则可能不需要功能模型，也无需在功能模型中表达全部功能需求。图 3 展示了一个连续时间功能模型的例子，它实现了大型软件中的一个小功能。

图3：功能模型的例子（防抱死系统）

软件架构设计阶段

本节重点介绍软件架构设计阶段开发的架构模型。架构模型用于软件体系结构设计规范。

图形符号天然适合定义组件组织结构、表述接口和连接、说明组件的调度。对于复杂的架构，如果没有合适的建模语言，或者是像 Simulink 这样的计算机辅助设计工具，要开发这样的图是无法想象的。

架构模型完全确定了静态软件架构设计（如，组件模型、接口），向将要构建或者已构建好的组件设计模型提供了链接/参考。架构设计模型与数据字典关联，该字典定义了软件及其组件的数据和接口。

架构模型直接用于设计活动，因此要符合行业质量标准、安全标准，及/或架构标准（如，对需求的可追溯性，与架构标准的兼容性。）

图4 架构模型的例子

软件组件设计和测试阶段

本节重点介绍组件设计模型，这些模型是在软件组件设计和测试阶段产生的。组件设计模型的作用是：提供软件组件设计的完整规范，并支持其动态验证和静态分析验证。

使用高级建模和编程语言可以更好地管理复杂的算法，并减少设计错误的可能性。由于支持仿真和静态分析，它有助于消除设计错误。

组件设计模型完全确定了算法和方程式——这将是嵌入式软件的一部分，并且排除了用于调试或原型设计的任何元素，例如测量点或重载机制。每个组件设计模型都与一个数据字典相关联，它定义了模型的接口、参数和监测信号。

组件模型直接用于开发活动，因此需符合行业质量标准、安全标准，及/或设计标准（如，符合建模规范，对需求的可追溯性。）

图 5 展示了一个组件设计模型的例子，它具有完整定义的接口和用状态机实现的子功能。

图 5：组件设计模型的例子

软件组件实现和测试阶段

本节重点介绍组件实现模型，这些模型是在软件组件设计和测试阶段产生的。组件实现模型的作用是：为特定的嵌入式目标和基本软件生成产品代码。

组件实现模型完全确定了软件组件的实现。实现细节被添加到数据字典中，以细化如何在目标内存中表征参数和信号。定义代码配置项和定制项，用于将生成的代码与特定的基本软件功能集成在一起，以便它们与目标的特征（例如字节顺序）匹配，并满足针对该软件组件的代码内存占用和执行性能方面的要求。

组件实现模型生成的代码直接用于开发活动，因此要符合行业质量标准和安全标准、及/或编码标准（如，MISRA C）。每个组件实现模型都与一个定义其接口参数和监视信号的数据字典相关联。

图 6：组件实现模型的代码生成配置的例子

设计模型间的关系

每个设计模型都应该在其所属的软件开发阶段，作为工作产品单独进行管理。与此同时，设计模型可以共享设计信息，并保持一致。例如，图 5 中的组件设计模型与图 4 的架构模型共享接口定义。任何需要一致性的时候，都应该鼓励重用。

图 7 显示了在设计模型间哪些方面可以重用（“reuse” 箭头），它还提供了关于设计模型的哪些方面可以被部分重用（“refine” 箭头）的指导，以加速开发。图 7 中的箭头可以应用于设计模型的以下建模方面：

架构方面：接口、调度、分块、组件间的控制和数据流等

算法方面：数学计算、组件控制和数据流、状态机、真值表等

代码生成方面：内存管理、数据访问、函数原型、代码优化等

因上述方面的成熟度级别和重要性不同，设计模型也各不相同。基于以下定义和描述，图 7 展示了成熟度和重要性的级别：

成熟度：高（产品）/ 低（原型）

重要性：强制（实线）/ 建议（虚线）

图 7：设计模型间的关系及对原型开发和产品开发的作用

功能模型应该有结构化的算法，用于通过建模和仿真来对软件需求进行验证。用于快速原型的模型代码生成配置，对在实时环境下验证软件需求非常有用。开发的重点应该放在软件需求上（没有在图上表示出来）。整个模型应被视为原型。

架构模型应定义软件架构中的组件接口和调度。功能模型的架构设计可以作为启动产品软件架构开发的基线（1a）。功能模型的原型算法可以移植到架构模型，以便在仿真中对模型进行早期动态验证，以评估架构对功能行为的影响（2a）。

可以创建软件架构标准（如 AUTOSAR）的原型代码生成配置，从而在早期验证实时环境和软硬件集成（例如 AUTOSAR RTE）对功能行为的影响。

组件设计模型应对软件组件的结构、调度和算法进行充分设计定义。模型的接口应该与架构模型（1b）一致，并且可以从架构模型中重用。为功能模型开发的原型算法，可以作为定义产品算法（2b）的基线。原型代码生成配置可以用于早期验证，发现设计模型对生成代码的深层次影响（例如，符合编码标准，代码覆盖率与模型覆盖率的级别，代码扩展）。

组件实现模型应该定义软件组件的设计和实现。结构、调度和算法应该从软件组件设计模型（1c、2c）中重用。算法的实现方式能随非功能性需求（例如优化、安全）而调整。代码生成配置将用于产品代码生成，并与软件编码标准和目标硬件兼容。

设计模型的质量

由于设计模型对于采用基于模型设计的软件开发非常关键，其质量必须仔细评估。设计模型可以自动转换为其他设计形式，如文档、源代码或可执行文件。因此，设计模型定义的质量目标应能影响模型本身及其派生产品。各种类型的设计模型各有其特定的质量目标以对应其特定的角色。

表格 1：设计模型的模型质量目标

表格 2 提供了适用于达到各种类型设计模型的质量目标的模型质量要求。

表格 2：模型质量目标的模型质量要求概览

M：强制

R：推荐（对于早期验证）

注：在 DO-331 中需要附加额外从模型到源代码验证的模型质量要求。

表格 2 中所有模型质量要求的详细说明

本文论述了 Simulink 设计模型如何从软件需求规范到软件实施以加速开发和验证活动。介绍了四种服务于特定目的的设计模型类型，每种类型均有特定的质量目标以控制其合适的使用。每个质量目标均为一组带满意度量化标准的可度量指标，以便于促进和规范模型质量评估。

应用本文所述概念的组织将能体验到以下好处：

在组织内部共享基于模型设计的理解

应用合格的模型于基于模型设计项目，且符合行业软件质量和安全规范

在项目不同阶段评估模型质量

与合作伙伴协同实施基于模型设计的组织在应用本文所述概念时将能体验到以下好处：

在项目初期厘清各方责任

达成对模型质量的同等理解

交换模型时达成对模型质量的同等期望