基于模型的软件开发是汽车嵌入式软件标准开发方法。加强软件开发流程并使之符合ISO26262标准是我们面临的一个共同挑战。其中一个挑战来自安全标准本身：作为一个标准，它定义了一个抽象的、通用的要求，软件开发团队要自己来评估标准与项目的相关性，并实施相关标准。ISO26262既考虑了基于代码的软件开发，又考虑基于模型的软件开发，而且还包含了仅适用于两种方案之一的要求，所以必须要进行相关评估。实践中，要求的解释、评估和实施以最新方法的综合知识、市场可用工具和具体项目情况为前提条件。

因为各种方法和相应工具的优缺点存在不确定性，所以如何充分利用紧张的项目预算变得越困难，需要进一步处理的问题还有角色和责任的阐明和分配，以及不同团队和部门之间接口的定义等。

对于大多数软件开发团队来说，因为缺乏项目资源，所以没有合适的机会能一次性解决所有的问题。因此，我们在评估了必要的行动的基础上，提出了一个策略来确定各项要求的优先次序。通过衡量某项开发活动对已开发软件质量的影响，以及引入和开展这一活动所产生的成本。我们希望能够解决两个问题：

1）理解ISO26262标准的测试要求；

2）确定ISO26262标准要求的优先级，高效地满足标准要求。

开发嵌入式软件的方法近年来在汽车领域发生了剧烈变化。基于模型的开发为嵌入式系统的软件开发提供了一种有效方法，并在所有开发阶段使用了可执行的图形模型。图1以简化方式说明了基于模型开发的过程。其中，功能模型是一种可执行的规范，用于说明功能性需求，也可以称之为用于代码生成的实施模型。采用Simulink和Stateflow等通用图形建模语言建模，并结合dSPACE的Targetlink或Mathworks的代码生成器联合使用。

最常用的基于模型的安全开发方法包括指南检查和模型测试。例如，建模指南强制使用与代码生成器兼容的建模模块或避免容易出错的建模模块。模型测试中，MiL（模型在环）确保模型的行为满足需求；SiL（软件在环）确保了代码和模型的等价性，也意味着可以满足需求。

图1：基于模型开发流程

ISO26262第6部分中的一个关键元素是V模型的软件开发流程，其开发阶段众所周知，如图2所示。每个开发阶段都存在一套要求。实际上，ISO26262第6部分的要求并没有给软件开发带来任何技术上的新东西，而是提出了确保软件质量的要求。

图2：以圆圈的形式标记软件开发流程的步骤

我们将这些要求分为三种措施：1）建立系统的开发流程；2）建设型质量保证措施；3）分析型质量保证措施。建设型质量保证措施用于质量内化，实施建设型质量保证的主要目标是避免故障，其典型的案例是根据设计指南避免容易出错的模型。分析型质量保证措施用于识别质量问题，如检测运行失败，测试是分析型质量保证措施的一部分。

我们将ISO26262标准的要求归纳为10个步骤，每个步骤的名称指明了实施要求的重点活动。下面我们按照措施分组介绍这些步骤：

—系统的开发流程

1. 裁剪开发流程

2. 调整工具链

—建设型质量保证

3. 制定设计规范

4. 检查和评估模型

—分析型质量保证

5. 测试重点：需求

6. 背靠背测试

7. 测试重点：接口

8. 测试重点：鲁棒性和资源

9. 测试重点：错误猜测

10. 检查未定义功能

根据我们支持客户实现符合ISO26262标准的MBD软件开发流程的经验，除了总结了这一策略，还有一个重要发现是定义系统的开发流程是一个逐步引入新方法、新工具，并且在实际项目中使用这些工具、根据相关经验不断定义规则和指导方针的过程，因此我们提出一种自下而上的方法来定义适合的开发流程：以检测故障开始，然后避免故障，最后实现合规的过程。下面我们按照优先顺序介绍这些步骤，包括标准要求的活动和我们自身经验的参考。

1. 故障检测

我们把ISO26262标准对检测模型故障的要求看作最重要的，如第1步的测试重点—需求、第2步背靠背测试和第3步测试重点—接口。根据经验，我们认为确保模型质量最明显的效果来自测试，所以我们建议先完成ISO26262需求测试、接口测试和背靠背测试。

1) 测试重点：需求。基于需求的测试允许系统地检测运行故障和因不完整/不符合要求而造成的故障。基于需求测试的一个不可或缺的前提条件是需求文档化和明确的需求管理，需求和测试规范之间的覆盖度和结构化覆盖度是验证测试规范所必需的，只有将测试结果和覆盖数据结合才能可靠的确定模型中是否存在故障。

2) 背靠背测试：这一步骤确保模型生成的代码和模型一致。通过SiL或PiL模式重新进行测试并将这些结果与MiL 的测试结果进行比较。结合MiL和背靠背测试能更容易地检测代码生成相关的模型（如特定目标处理器的数据类型）故障。此外，我们建议除了单元测试和集成测试之外，还要测量需求覆盖度。

3) 测试重点：接口。ISO26262标准要求系统的测试接口，确保接口运行的正确性。我们观察到，测试期间明确内、外部接口能及早发现故障，否则直到集成测试阶段才会注意到这些故障，这个阶段可能更难将这些故障进行定位。对于ASIL C或更高等级的软件而言，ISO26262标准要求应用覆盖度指标来解决软件功能的运行问题，这些覆盖度指标必须用于评估集成测试，而不是单元测试。

2. 故障避免

第2组（第4步-第6步）主要包括标准对避免故障相关的要求。与第1组相比，第2组有不同的优点。这些建设型质量保证能避免特定类型的故障。它们不仅对模型质量和代码产生了积极影响，而且还提高了开发流程的效率。建模指南能避免一些细微错误，如没有注意到错误数据类型转换或未初始化。在测试阶段检测到这些故障后，还需要花费大量时间进行分析。建模指南可以提高模型可读性和可维护性来提高效率，完整的模型布局大大减少了故障检测和故障分析的时间。

3. 检测和评估模型

要求的活动是应用建模指南和对手册进行评估。值得注意的是这些活动是至关重要的。根据经验，我们要在相当长的一段时间内使用、改进和增强模型。我们常用定义指南集的方法,包含从初始指南集开始，并将其应用到可用模型中。我们根据结果调整指南集，如根据项目需要更换指南，用其他指南替代上述指南或将指南参数化。这一过程讨论了指南的相关性，而且该指南从一开始就考虑了公司特定的建模实践。

关于手册评估，我们建议采用独立于软件单元ASIL等级的正式评估方案，这样能获得更好的结果，前提是它以评估检查表为基础。

4. 测试重点：错误猜测和静态代码分析

对错误猜测而言，测试工程师假设了可能的软件故障，并确定了如何解决这些故障。熟练的测试人员根据以往项目经验和模型语言的特定知识定义了测试案例，所以这种方法又称之为基于经验的测试。

另外， ASIL D等级组件的MC/DC覆盖度也放在了这一步，因为ISO26262标准没有规定MC/DC的固定值，只规定要有一个充分的比例，这一要求似乎不太精准，然而定义一个固定值来处理软件的变型也几乎不可能。当然，如果实际MC/DC覆盖度偏离了100%，那么必须要提供一个合理的理由。

此外，这些组件需要静态代码分析，在实践中使用静态代码分析必须限于故障类型和软件特定部分。否则，如果没有足够资源来终止不相关的警告，那么静态代码分析可能会给出不明确的结果。

5. 制定设计规范

要符合ISO26262标准，软件架构和软件单元都要制定设计规范。根据经验，考虑到越来越多的功能复杂性，所以我们需要更多地描述软件架构。我们还发现，软件单元的错误交互导致的故障愈来愈多。因为单元测试无法检测到这些故障，所以我们检测出这些故障的时间比较迟，很难纠正这些故障，且纠正故障成本太大。软件架构设计通过覆盖整个软件，并解释软件单元的细节，从而避免故障的产生。

对模型开发而言，模型本身就是单元规范。在这种情况下，我们需要补充相应的文档，并将它与模型未明确定义的部分结合起来。

6 实施合规流程

最后一组包括第7步-第10步，主要总结了前面的步骤，旨在将它们结合成由无缝工具链支持的高效开发流程，将开发流程文档化尤为重要，特别是将ISO26262标准要求的解释文档进行文档化更为重要。将实施相关要求的决策文档化可以减少开发团队重新解释ISO26262标准要求所需要的时间，而且他们还能集中精力完成开发和质量保证等活动。

7. 检查未定义功能

ISO26262标准要求分析未定义功能的软件，未定义功能包括仪器代码或因为软件变型而停用的功能。ISO26262标准不要求删除这一代码，但是它不能对安全要求产生影响。我们可以通过相应测试或手动检查来完成这一活动，然后还需提供证据来解释如何在运行过程确保这一功能的停用。

8. 调整工具链

根据我们的经验，高级开发团队对工具有严格的使用指南和文档，例如，采用固定的代码生成器配置，因为查找不同配置生成的代码的故障非常困难。此外，ISO26262标准要求鉴定工具：这种鉴定包括评估工具引入故障的能力和不被发现的可能性。根据鉴定的结果，有可能进行全面测试来验证这一工具。

9. 测试重点：鲁棒性和资源

虽然软件是正确的，但是系统可能会因为硬件故障或软件对资源应用不当而产生故障。资源占用测试对软件的非功能属性（如执行时间）或资源（如内存）进行验证。因此，必须在目标处理器上执行测试。故障注入测试可以解决软件的鲁棒性验证问题，也就是说，测试目的是验证充分的故障处理，并且能在任何测试环境中执行。

10. 裁剪开发流程

我们提出类似Lessons Learn阶段一样的开发流程裁剪，因此，需要分析开发活动的顺序、依赖性、安全相关性来定义开发流程。至于如何在文档中组合或展开ISO工作产品的内容标准并没有规定。但为了符合ISO26262标准，将其映射到标准要求的那些工作产品上是必须的。

我们经验表明，开发流程文档化是很有用的，可以针对公司对ISO26262标准要求进行特定解释，也就是说，应该清楚地定义ISO26262所必需做的事情。换句话说，阅读流程定义足以了解如何进行ASIL等级的软件开发。我们相信投入时间和精力来定义开发流程和进行文档化是至关重要的。明确流程和公司关于ISO26262标准的具体规定使开发团队无需考虑标准本身。与标准解释相关的文档化决策使开发人员将精力集中在开发和质量保证方面。

根据我们大量项目经验，总结了10步搞定符合ISO 26262标准的MBD开发的方法。我们采用业界最新的方法来满足ISO26262标准的需求，并在主要的车厂和零部件公司得到应用。这个10步法以ISO26262标准对软件质量要求的优先排序为基础。考虑各个团队的预算约束，我们认为有必要采用这样的优先次序。重要的是，我们的方案对项目预算从两个方面进行优化：缩短ISO26262标准方面可能存在的差距并提高待开发软件的质量。