面向汽车的敏捷安全档案与开发运维（DevOps）整合方案

摘要

汽车包含越来越多的功能安全系统，例如车道偏离预警系统，从长远来看，这些系统可能会向完全自动驾驶方向发展。软件还会监控更多关键操作，例如驾驶员的警报监控。由于软件规模和复杂性不断增长，敏捷方法被引入，以改善开发人员与客户之间的沟通、缩短产品上市时间，并以较短的周转时间为软件升级提供便利，这其中也包括汽车售出后对软件的改进。

敏捷安全档案方法将成为敏捷开发（包括开发运维流程）的推动因素。“开发运维（DevOps）” 一词源于两个流程的结合 —— 软件开发（例如采用 SafeScrum 方法）和该软件的运行（使用），其中包括代码维护（向开发环节提供反馈）。本文提出了一种将这三个流程（敏捷开发、敏捷安全档案、开发运维）相结合的解决方案。

最初为流程工业开发的 SafeScrum 方法，以及最初为铁路信号系统开发的敏捷安全档案（Agile Safety Case），均可适配于汽车行业，并且能够与 ISO 26262 标准、英国标准协会（BSI）PAS 1881 试验标准以及针对自动驾驶产品的 UL 4600 标准保持一致。

安全档案的构建要求制造商和运营商明确安全流程及技术安全方面的内容，从而使认证、审批和部署能够与开发同步进行。

1、引言

在当今世界，由于对新功能的需求、整体质量提升以及错误修正的需要，“一切事物” 的变化速度都越来越快，汽车软件也不例外。然而，高变化率可能会将软件安全置于风险之中。我们发现有两个重要方面或许能为我们提供帮助 —— 开发运维（DevOps）和敏捷安全档案。引入开发运维能够改善运营商、用户与开发人员之间的沟通；敏捷安全档案则有助于我们对系统安全关键问题保持管控，确保安全始终处于可控范围内。

本文其余部分结构如下：第 2 节简要介绍本研究的背景；第 3 节阐述我们提出的解决方案，即通过软件和合规性验证（PoC）流程实现基于证据的更新与升级；第 4 节讨论研究有效性面临的威胁；第 5 节给出最重要的结论。

向能够处理安全软件频繁更新与升级的流程转型至关重要，原因如下：

· 修正漏洞与错误，减少安全相关应用条件（SRACs）的数量，例如可控性问题；

· 改进来自车队的运行反馈；

· 技术改进与安全问题，包括安全补丁的应用。

本文存在以下局限性：

· 仅考虑欧洲地区的法规；

· 仅考虑欧盟 / 欧洲经济区（EU/EEA）范围内与汽车及公交车安全和审批相关的法规，包括自动驾驶汽车和公交车的试验法规；

· 仅考虑挪威关于自动驾驶汽车试验的法规。

2、背景

2.1 欧洲汽车法规

欧盟的技术协调基于整车型式批准制度（WVTA）。制造商在某一个欧盟 / 欧洲经济区国家获得某一车型的批准后，即可在整个欧盟 / 欧洲经济区范围内销售该车型，无需再进行额外测试。批准文件由型式批准机构签发，测试工作则由指定技术服务机构执行。欧盟 / 欧洲经济区各国会设立或指定批准机构，并将其告知欧盟委员会。指定技术服务机构是指由国家批准机构指定的组织或机构，可作为测试实验室开展测试工作，或作为合格评定机构代表批准机构开展初始评估及其他测试或检查工作。欧盟 / 欧洲经济区各国必须将机动车指定技术服务机构的名称及详细信息告知欧盟委员会。

当前相关的立法文件是关于机动车批准的 2007/46/EC 号指令，该指令自 2020 年 9 月 1 日起被关于机动车批准及市场监督的（欧盟）2018/858 号法规取代。法规是具有普遍约束力的措施，由欧盟理事会与欧洲议会共同通过，或由欧盟委员会单独通过；而指令则面向各成员国，旨在协调各国立法，其仅对成员国需达成的结果具有约束力，但成员国可在本国法律框架内自主选择实现欧盟目标的形式与方法（即国内转化实施）。

根据（欧盟）2018/858 号法规的定义：“机动车” 指任何由自身动力驱动、设计制造用于移动、至少有四个车轮、处于完整、待完成或未完成状态，且最高设计车速超过 25 公里 / 小时的车辆。

欧盟正在制定关于自动驾驶汽车欧盟批准豁免程序的指南。该指南已于 2019 年 2 月 12 日获得机动车技术委员会的支持，旨在为自动驾驶汽车欧盟批准的豁免程序提供统一的方法。该指南中提到：“对于自动驾驶等欧盟机动车法规未涵盖的技术，可通过 2007/46/EC 号指令规定的欧盟豁免程序获得批准。在统一的欧盟要求出台之前，批准可基于各国临时安全评估结果，该评估结果经欧盟委员会决议后，将得到其他成员国的认可。此后，该车型可与其他经欧盟批准的车型一样，在欧盟市场投放。” 该文件参考了美国汽车工程师学会（SAE）的自动驾驶等级标准，并包含了申请流程要求、安全要求（包括网络安全要求）。在网络安全要求方面，该指南参考了ISO/SAE 21434 标准。

与其他多个欧盟 / 欧洲经济区国家一样，挪威也制定了关于无人驾驶车辆测试的法律（LOV-2017-12-15-112号法律）。该法律于 2018 年 1 月 1 日生效，涵盖了申请要求、结果通报、个人信息保护、监管、驾驶员要求及处罚规定等内容。

2.2 ISO 26262 标准与 UL 4600 标准

ISO 26262:2018 是汽车行业功能安全系列标准，基于通用的 IEC 61508:2010 功能安全标准制定。汽车所包含的嵌入式系统由原始设备制造商（OEM）开发。ISO 26262:2018 为电子系统制造商规定了汽车安全完整性等级（ASIL）要求。汽车安全完整性等级通过危险分析与风险评估确定，其结果决定了系统（包括软件）的开发流程、分析及测试要求。该系列标准还包含了关于汽车和公交车驾驶员可控性的要求。

UL 4600 是一项针对汽车领域自动驾驶产品的全新草案标准。该标准采用安全档案方法，包含了评估安全产品与系统时的流程要求和原则要求。UL 4600 标准可作为评估自动驾驶系统是否能在无需驾驶员干预的情况下，安全执行预期功能的依据。此外，该标准还涵盖了机器学习、环境感知及其他自动驾驶相关方面所需的硬件与软件可靠性要求。UL 4600 是一项基于目标的标准。正如米克莱布斯特等人在 2016 年的研究中所指出的，基于目标的标准允许我们使用任何合适的工具、技术与方法，只要能满足标准规定的目标即可。

2.3 安全档案

安全档案的核心思路是论证系统的安全性，其论证方式类似于法庭辩论，“安全档案” 这一名称也正源于此。我们应在开发工作启动之初，就开始规划敏捷安全档案。我们需要明确何时需要何种证据，并规划如何在开发过程中获取这些证据。然而，在构建安全档案之前，我们需要先对系统进行界定 —— 明确系统的包含范围与排除范围；确定背景 —— 明确我们的论证适用场景；并厘清为构建论证所做出的假设。

图 1、图形化安全档案部分内容的带注释示例

安全档案包含四个组成部分：

· 主张（Claims）—— 例如，“该系统是安全的”；

· 计划用途与使用环境描述（也称为背景）；

· 论证（也称为理由或策略）—— 为主张提供支持；

· 证据（也称为证明）—— 为论证提供支持。

从宏观层面来看，安全档案并不复杂。开发人员会提出：“该系统是安全的，因为……”，“因为” 之后的所有内容即为安全档案。一旦确定了主张并界定了背景，我们就需要着手构建论证。首要原则是 —— 保持简洁。冗长、复杂的论证难以阅读和理解，还可能给人留下 “试图掩盖问题” 的印象。明确 “何为有效的论证” 至关重要。以如下表述为例：“我们已发现所有错误，因为我们采用了测试方法 X”。如果方法 X 是相关标准中规定的方法，我们可能会认为该论证是合理的。但实际上，一种方法的使用方式多种多样，因此，我们必须证明所应用的方法或技术适用于其预期用途、使用方式正确，且由具备相应能力的人员执行，并为其分配了充足的资源（时间、工具等）。

其次，论证必须有证据支持。证据不一定是文件或报告，也可以是白板快照、测试日志打印件或代码审查报告等形式。唯一的绝对要求是：所有证据都必须包含生成日期以及参与人员名单。

安全档案有三种呈现方式：纯文本形式（描述为确保系统安全所采取的措施）、结构化文本形式（仍为文本，但通过段落划分、缩进等方式增加结构），或图形符号形式（以树状结构展示主张、论证与证据之间的关系）。尽管目前大多数行业安全档案仍采用无结构的纯文本形式，但我们建议采用结构化文本或图形符号形式。

敏捷开发与安全档案构建的适配性良好，因为敏捷开发采用 “循序渐进、分块开发” 的方式。这种方式使得我们能够在开发过程中，根据安全档案构建的需求灵活增加开发活动，或弥补安全档案论证中的 “漏洞”。将敏捷开发与安全档案相结合，能够改善项目沟通。敏捷开发通过频繁、简短且目标明确的会议，确保所有人员都能及时了解项目进展；而安全档案的构建则能清晰呈现每个安全问题的解决方案，以及尚未解决的安全问题。以敏捷方式构建安全档案，还能改善与评估人员的沟通 —— 我们可以向评估人员展示已完成的工作，并就解决方案是否可接受获取反馈。

我们可以对图形符号形式进行扩展，增加指向相关信息的链接 —— 例如，在顶层主张（如图 1 中的 “SWContribAccept” 框）中添加指向危险场景描述的链接。

最后提供几点建议：在编写或认可安全档案图表时，需确保使用的语言简洁易懂，目标及各子目标表述准确（这些才是核心关注点）；确保所使用的论证与目标具有相关性且充分，证据完整且可信；此外，还需确保证据中包含所使用方法与工具（如有）的描述、执行人员的知识与经验背景，以及所有相关文件的引用；最后但同样重要的一点是 —— 所有内容都应只编写一次，若其他地方需要引用，只需标注引用来源即可，这样能降低修改过程中出现错误的概率。

2.4 SafeScrum方法

SafeScrum方法以增量迭代式开发的 Scrum 流程框架为基础，该框架已成为大多数工业软件工程项目的标准流程模型。为满足安全标准（尤其是 IEC 61508 标准）中的要求，SafeScrum 方法增设了额外的活动与角色。

图 2、SafeScrum 流程模型

需求以用户故事的形式存储在产品待办列表中，在 SafeScrum 方法中，功能性（非安全相关）需求与安全相关需求会分开存储。简而言之，功能性用户故事来源于用户，而安全故事则来源于初步的安全分析。如果某个用户故事被认为与某一安全故事相关联，则会在其中插入引用链接。开发工作以 “冲刺（sprint）” 为周期进行，冲刺是短时间且可重复的工作迭代。每个冲刺始于冲刺规划会议，在会议中，团队会对产品待办列表中的故事进行优先级排序、筛选，并将其拆解为解决方案思路，然后纳入冲刺待办列表。

开发工作由固定团队执行，团队会定期（可能每天）召开简短的状态会议（即 “每日站会”），分享进展、规划工作并讨论遇到的问题。软件开发应遵循测试驱动开发（TDD）原则，这一原则同时也能确保较高的测试覆盖率和测试文档的完整性。SafeScrum 方法增设了质量保证（QA）角色，该角色负责确保所有流程步骤和文档都符合相关安全标准的要求。

每个冲刺的目标是生成一个 “增量” 成果，即解决方案的一个组成部分。通常情况下，这个增量是可集成到整体解决方案中的软件，但也可能是架构描述、文档或其他所需的工件 —— 本质上，只要是构建最终解决方案所需的工作项，都可作为增量成果。每个冲刺结束时会举行冲刺评审会议，会议可能包含可靠性、可用性、可维护性和安全性（RAMS）验证环节，以检查增量成果是否满足所有安全需求，并符合相关安全标准。如果某一工作项（如软件模块）通过审批，则会被纳入解决方案中，用于后续的集成测试；如果未通过审批，则会基于新获取的知识对引发该开发工作的故事进行完善（重写），并将其退回产品待办列表，留待后续进一步完善或完成。

最后需要说明的是，该流程需要相关工具的支持，包括需求（待办列表）管理工具、单元测试工具和工作流管理工具。通常情况下，可使用标准的敏捷流程工具。

敏捷流程具有多项有利于安全关键软件开发的特性：

· 频繁生成可测试的增量成果；

· 测试与代码开发并行进行；

· 实现可追溯性，既包括开发过程本身的可追溯，也包括质量保证过程的可追溯；

· 支持学习过程，使（功能性）需求能够随时间推移不断完善；

· 提升透明度，这在与评估人员的沟通中可能具有优势；

· 支持安全档案与开发工作并行构建（而非将其留到开发末期执行）。

2.5 开发运维（DevOps）

开发运维（DevOps）的核心在于沟通，其并非一种开发流程。高德纳（Gartner）术语表将其定义为一种文化：“DevOps 代表了信息技术（IT）文化的变革，其核心是在面向系统的方法框架下，通过采用敏捷、精益实践，实现 IT 服务的快速交付。DevOps 强调人员（及文化）的重要性，并致力于改善运营团队与开发团队之间的协作。”

从很多方面来看，开发运维所涉及的工作，本质上是开发人员和运营商一直在做的事情，只是采用了更高效、更协同的方式。运营商发现系统问题，或有修改、扩展系统功能的需求时，会撰写报告并发送给系统开发公司。这一过程（包括系统监控和反馈环节）在一定程度上可实现自动化。运营商迟早会收到系统的新版本，其中包含针对其所提需求的解决方案。

开发运维的创新之处在于，它通过将现场运营环节 “纳入” 开发流程，扩展了开发团队的范围。从这个角度来看，系统始终处于持续开发状态 —— 现场运营经验和系统监控数据会被反馈到系统改进过程中。这对开发人员和运营商都有益处：运营商能够更快地将问题反馈给开发人员，从而更早地解决问题；开发人员则能更深入地了解运营过程中遇到的问题，以及交付存在错误或未完全满足用户需求的系统可能带来的后果。

3、用于实现基于证据的补丁更新与升级的建议

为满足车辆部署后对软件进行频繁更新与升级的需求，我们必须融合安全与安全领域、敏捷社区以及开发运维方法的优势。

对于自动驾驶车辆在运行过程中必然会出现的未知风险，我们需要采取主动应对措施；同时，还需应对可能出现的网络安全问题。此外，为快速实现更高等级的自动驾驶功能，我们还需进行有计划的技术改进。为在自动驾驶车辆的开发与运营过程中同时满足安全和网络安全需求，我们必须实施敏捷安全档案方法，具体框架如下图所示。

图 3、整合敏捷安全档案与开发运维方法的 SafeScrum 流程模型

建立开发运维流程至关重要，这能确保以快速且安全的方式进行补丁更新（短期响应）。

由于技术发展迅速，相关标准的更新频率需高于传统安全标准。因此，安全档案必须随之更新，以适应安全与网络安全标准的这些变化。

4、有效性威胁

针对我们在第 3 节中提出的 “通过基于证据的方法实现有效流程” 这一结论，其有效性面临两个主要威胁：一是我们对 ISO 26262 标准和 UL 4600 标准的理解是否准确；二是我们对敏捷开发和开发运维（DevOps）的理解是否准确。

4.1 我们对 ISO 26262 标准和 UL 4600 标准的理解是否准确？

本文的一位作者是安全评估师，拥有丰富的多类安全标准实践经验，同时是 IEC 61508 标准维护委员会成员，并且熟悉基于 IEC 61508 标准制定的 ISO 26262 汽车标准；此外，该作者还是 UL 4600 标准的相关利益方。另一位作者是软件工程教授，在系统安全分析领域拥有超过 20 年的经验。因此，我们对 ISO 26262 标准和 UL 4600 标准的解读具有充分的专业基础。

4.2 我们对敏捷开发和开发运维（DevOps）的理解是否准确？

包括 Scrum 在内的敏捷开发并非定义精确的方法体系，但敏捷开发基于若干通用原则。我们在研究中应用了这些通用且核心的原则，以减少因对敏捷开发定义的主观解读可能带来的偏差，但在一定程度上，主观解读仍是难以完全避免的。

本文所有作者均参与了 SUSS 项目，该项目与两家挪威中小型企业（SMEs）合作，致力于将 Scrum 方法适配为符合 IEC 61508 标准的 SafeScrum 方法。在项目实施过程中，我们还基于向挪威工业界推广该方法的经验，撰写了一本关于 SafeScrum 方法的书籍。此外，其中一位作者在工业界应用和教授 Scrum 方法方面拥有丰富经验。因此，我们具备开展本研究所需的敏捷开发专业知识。

关于开发运维（DevOps），核心问题并非 “是否理解其定义”，而是 “能否评估运营商与开发人员之间的紧密协作是否对双方都有益”。本文作者参与过大量工业软件开发项目，均认识到当系统出现问题时，用户快速且全面的反馈具有重要价值。因此，我们认为自己具备理解开发运维（DevOps）所需的专业能力。

4.3 我们的有效性主张

基于 4.1 节和 4.2 节的讨论，我们认为，我们关于 ISO 26262 标准、UL 4600 标准、敏捷开发及开发运维（DevOps）的结论，对广大企业和认证机构都具有有效性。

5、结论

敏捷开发流程、开发运维（DevOps）和敏捷安全档案的相关要素，已在汽车、空中交通管理、航空电子和工业自动化等多个领域得到应用或被考虑采用。将安全档案纳入开发和运营流程，目前仍是一项挑战。此外，我们还参与了多个项目，以确保自动驾驶车辆试验运营符合英国标准协会（BSI）PAS 1881 标准的要求。我们预计，在不久的将来，众多制造商和运营商将采用我们提出的解决方案或类似方案。