汽车工程所面临的一个主要挑战就是汽车安全相关功能的不断复杂化以及如何将这些功能应用到分布式组件上。在颁布ISO26262标准后，相关问题进一步突出。
本文讨论了基于模型的系统工程方法如何能够将安全活动纳入开发过程，以处理日益复杂的问题并提高效率。最后，将产品线工程方法扩展到安全活动的工作产品，引入需要的工作步骤，使工程部门的能力与当前任务的复杂性相匹配。
在过去的25年里，汽车行业中与安全相关的E/E功能数量呈指数级增长。这些功能不仅仅体现在数量的增加上，而且复杂程度、对车辆的控制权限和相互之间的交互程度也在增加（见图1，基于个人经验和观察）。
图1：汽车系统复杂性问题
减少功能，即减少功能本身的数量和操作范围，是降低复杂性的一种方法。然而，由于汽车市场上，汽车制造商追求汽车功能的差异化，因此，在这种压力之下，汽车上就必然会出现更多的创新功能，特别是在主动和被动安全领域。因此，减少汽车功能这种方法，对于降低复杂性的效果有限。但是如果这些功能发生故障，可能会导致与安全有关的事故。
随着汽车行业功能安全专用国际标准ISO 26262的颁布，需要汽车制造商确保在生产汽车过程中采用了最佳实践方法，并为自己开发的系统是否安全提供令人信服的证据。
当前，我们注意到，存在一些因素限制了汽车行业利用现有实践和资源来满足上述要求。汽车行业要开发的系统数量之多，技术变化之快，加上缺乏训练有素、经验丰富的安全工程师，导致开发项目得不到充分的支持。此外，尽管越来越多的人意欲坚持CMMI和SPICE等模型，但往往又缺少必要的严格程度的系统工程所需的流程纪律。导致这种现象的原因，我们不认为是对工程原理本身的很深的抵触，而是因为不合适的流程和工具。
图2：汽车系统工程中的能力问题
由于上述提及的问题和图2中总结的问题，我们认为，在与安全相关的汽车E/E功能的系统工程中，非常有必要对方法进行重大变革。一方面，我们要提高效率，使功能的数量、大小和复杂程度能够开发到足够高的标准，另一方面，要提供一个清晰的框架，在这个框架内，可以对系统的功能安全性开展具有说服力的论证。本文其余部分讨论了如何将安全更好地融入到开发活动中。在产品线开发和模型驱动的系统工程领域取得的进展，可以使系统工程部门的能力与当前任务的复杂性相匹配，从而实现所需的流程变革。
在所有安全标准中，标准的主要要求是能够通过实施适当的系统安全概念来证明系统级安全目标可实现。通常，安全目标是在危险分析的基础上得出的，然后再将目标细化为功能和技术上的安全要求，然后在各个系统组成部分进行分配。
从一定层度上讲，安全目标的实现取决于一些因素，比如软件功能执行不正确或随机硬件失效。使用标准中规定的方法来开发，从而检测和防范这种孤立的失效相对简单。然而，真正的困难在于如何确保系统不受来自不同架构层的各种因素的影响。如以下两个例子所示，传统的、基于文件的流程并不适合处理这些类型的系统相互依赖性。
-软件开发过程中，对两个功能相互作用的通信媒介的完整性给出了不正确的假设。在软件设计中没有充分考虑通信故障、延迟等问题。这可能是因为在ECU和总线之间重新分配已有的功能导致的。
-安装在具有高温或高应力（如温度、振动、电磁干扰）的车辆环境中的汽车硬件故障率出人意料的高。
那么，该如何处理这些复杂问题呢？我们建议的方法是使用基于模型的系统工程技术。这些方法可以从许多不同的角度定义一个系统，并通过使用一个共同的基础模型来联系并保持一致性。这个数据模型涵盖了EE-系统设计中的需求规范，功能架构、硬件和软件技术设计（见图3）等各个方面。这种方法的一个关键是能够对这些不同架构层之间的依赖关系建模，以及对工件的特定属性（如总线负载、硬件故障率、安全完整性水平、安装地点的温度范围等）建模。在这个建模分析的基础上，可以验证一些问题，比如 "是否有电缆穿过车辆中对碰撞情况特别敏感的区域，是否有任何电缆在穿过对信号传输正确性特别敏感的零部件之间。
图3 架构层总览
与传统的基于需求标签的文档跟踪相比，采用这种方法所实现工程活动的整合会更丰富。同时，这种方式又可以提高工程产品之间的一致性。这点是构建具有说服力的安全案例时的一个重要特点。
安全标准要求在系统，软件和硬件级别进行分析，以识别设计中的弱点并确定必要的改进措施，这种分析的方法包括：FMEA（失效模式和影响分析）和FTA（故障树分析），利用这些分析方法，可以确定各个组件的失效行为，并分析其对安全目标和失效率的影响。采用整体系统建模方法在多个层次上优化系统目标，同时保留它们之间的功能依存关系，是进行安全分析的最佳选择。在执行安全分析时，工程师可以利用这些信息，工程师可以使用此信息更好地识别与组件失效相关的潜在危险影响，分析过程中提出的建议改进措施，可以直接与系统模型的对应部分联系起来。从而确保安全案例的可追溯性，以及设计模型的某些部分变更后的影响分析的效率。
基于模型的系统工程方法的扩展，包含描述安全案例和安全概念的元素，这种扩展会延伸到高度交互式的安全工程"往返工程"方法，这时系统设计中的更改将立即指向安全概念、相关分析和安全案例中的需要返工相关元素。此外，通过将特定的设计模式与安全分析和安全案例模式相关联，可以在设计分析的基础上自动生成安全案例结构的各个部分。通过制定替代性设计解决方案，然后分析其对创建安全案例所需的必要证据的影响，可以用到对设计执行“假设分析”的能力。
随着ISO 26262的发布，汽车行业致力于导入功能安全标准。有了功能安全标准，在汽车 E/E 系统开发中，有助于我们对功能安全性的开发过程达成共识。但是该标准仅仅写了几个要求而已，这些要求只是作为建立一个安全的一种手段，提供一个令人信服的论据，证明已实现已开发系统的功能安全性。
许多汽车制造商和供应商的经验表明，执行功能安全标准后，对于开发、维护和记录安全案例而言，其作用、价值和方法几乎都还没有达成共识。在功能安全标准的第2部分中，提供的要求是非常不明确的。在功能安全标准的第10部分中则描述了在其他行业中建立的成熟方法，但又与第2部分脱节，没有一点用处。因此，当前的常见做法仅仅是在项目开发结束时，列出安全相关的文档列表。由于所开发系统的复杂性，显而易见的是此方法会导致一些相关的内在风险，这些风险还包括开发项目在实现安全目标时看不到其进展情况。除此之外，当外部评估人员进行评估时，也很难说服评估人员相信这些方法。因此，安全案例为系统功能安全提供一致性和依据，并指导开发设计的这些潜能还没有发挥出来。
我们相信，采用结构化的方法建立安全案例，有利于证明系统安全性，以及提高开发效率。
我们建议，以结构化论证的形式，将产品和流程依据结合在一起，这样的安全案例可适用于汽车 E/E 系统的开发，并以集成到系统工程生命周期的方式进行扩展。
该方法将为每个系统安全目标构建一个安全案例，描述实现目标的策略并以结构化，自上而下的方式引用假设、理由和证据。如此一来，安全案例将“汇集”系统模型中包含的证据，从而为功能安全提供一个连贯且可辩驳的论据。
在进行与安全相关的系统开发时，我们面临的一个主要障碍就是要做一些与工程项目开发不相关的工作，而这些工作恰恰是标准中所要求的。在概念阶段，我们的工作到涉及进行危害和风险分析，制定适当的系统安全概念，并得出系统及其组件的技术安全要求。这些“额外的工作”通常不在当前的车辆开发项目时间表中，随着项目时间的缩短，执行这些工作，就会导致项目延误。更常见的是在系统架构的后期，直到发现系统缺陷再回过头来执行安全工作，可能会导致投入更多的额外成本。
解决此问题的一种方法是使用产品线工程方法进行系统工程，以利用经过验证的，针对特定领域的安全概念。建立一组跨越整个生命周期的通用的开发工作产品，可以重复使用。然后根据车辆特定的功能、操作条件和体系架构进行裁剪。为了最大限度地提高安全相关系统的产品线工程方法的益处，与车辆的通用功能相关的资产，也应进行危害识别和风险分析以及安全概念开发。这样就可以基于功能、操作条件和体系架构变化的影响分析，再对通用需求规范的进行调整得出项目特定的技术要求。
通过严格控制与功能相关的共性和可变性，可以充分重复利用从安全概念中获得的技术要求，进而充分重用预先开发的组件和软件，进而减少与实施和测试相关的工作 。
为了实施基于模型的、安全案例驱动的系统工程，必须首先解决以下问题：
- 扩展系统工程方法，使其能够对安全案例进行建模（比较理想的是将“目标”结构表示法进行集成），以及定义安全概念（基于体系架构和行为模型）。
- 必须将基于产品线工程的方法集成到模型中（在要求、设计和安全案例级别）。
- 不能用人工创建和管理开发工件之间的依赖关系，包括安全案例的开发和维护，应由支持开发方法的基础工具集自动完成。
- 最后，需要工业级的工具支持，允许工程师创建图形规范，管理基础数据，以确保模型元素之间的一致性，创建基线，允许跨区域协作开发等。
