自动驾驶汽车安全管理自主框架(二):参考架构

从安全角度来看，自动驾驶汽车的开发和部署是一项极具挑战性的工作。车辆必须在多种情况下导航，防止任何潜在伤害，并且不干扰交通流，才能被社会接受。在完全由计算机控制的情况下安全驾驶，还需要与复杂道路网络中的不同实体进行交互和运行，并恰当应对它们的不同行为。

尽管过去几年取得了很大进展，但大多数工作都集中在为车辆提供自主导航能力上。安全已成为主要挑战，不仅在车辆行为方面需要解决边缘案例（即安全导航），还需要管理故障或外部干扰（即容错）。

目前安全领域的工作已经提出了自动驾驶安全分析、细化、集成和执行的相关方法。将安全视为Leveson等人在STPA/STAMP方法中提出的动态控制问题，在文献中展现出良好的应用和结果。补充研究探讨了与传统危害覆盖故障分析的权衡，而其他研究则在文献中探讨了该方法与当前自动驾驶标准的兼容性。然而，这些工作大多都认为，基于成熟安全分析方法识别安全约束，难以提供可扩展的自动驾驶安全集成和执行。此外，使用自适应行为在运行时进行安全保障，被证明需要自动驾驶系统非功能属性的复杂组合，包括可观测性、可追溯性、可重构性和可扩展性。

本部分文章提出的主要贡献是将自安全概念融入现有自动驾驶汽车的参考架构，并解决前述已识别的非功能属性问题。该架构由两层组成，管理自适配过程以在运行时保障安全。第一层使用一系列可靠流程直接管理扩展的自动驾驶汽车架构的组件，这些流程保证每个并发安全约束指定的需求得到满足。第二层管理这些可靠流程，并根据观察到的上下文动态条件（例如基于道路条件的重构或避免安全约束之间的冲突），保证它们的激活、管理和停用。

这篇文章的这一部分，主要讲了整套框架架构的底层基础，具体包括需求定义、功能设计、自适应相关的功能模块、抽象层设计、知识表示方法，还有一套模板——用来衔接和运行各类安全控制回路，这些回路都是可组合、不绑定具体技术的流程。

第2小节梳理了运行时自适应架构需要满足的要求。这套架构要想守住安全约束，得具备可观测、可追溯、可重构、灵活可调这几个特性，而且这些安全约束在系统设计阶段和实际运行阶段都得能落地执行。

第3小节讲了这套参考架构的核心特点，同时详细拆解了控制方法的整体设计思路。

第4小节则给出了这套参考架构落地到自动驾驶汽车上的具体实现指引。第一步是更新系统需求，把自动驾驶汽车的非功能属性（NFP）整合进带安全管理系统的整体架构里。同时也详细说明了现有相关研究是怎么把这些必需的非功能属性融入到可行方案里，以及系统是靠哪些能力来满足这些要求的。我们这套架构框架，是基于自主计算范式、灵活的微服务架构风格，再加上语义模型和半形式化模型形式的知识表示搭建起来的。文中顺着设计的组合步骤一步步讲清了框架核心模块的设计逻辑和它们之间的交互方式，最终搭出一套灵活可调、可编排、可组合，且不绑定具体技术的微服务架构。除此之外，这一节还详细介绍了各个知识库的结构、各自的作用，以及怎么分配它们来驱动这套不依赖具体技术的系统运行。

最后在第 5 小节，文章给出了对应的研究结论。

我们这套方法的核心目标，是推出一套参考架构，依靠主动自适应流程的运行结果，在系统运行阶段持续提供安全保障。这些自适应流程稳定可靠，初衷就是守住自动驾驶汽车内部和外部的各项安全约束。要满足自动驾驶安全系统必备的几项非功能属性——也就是可观测性、可追溯性、可重构性和可扩展性，我们提出要重点遵循以下四条设计原则：

1.将安全视为控制问题，用这个思路指导设计，才能打造出可以及时响应、甚至降低不良事件影响的高效控制架构。系统安全的落地路径有两种：要么从设计层面直接消除风险，要么通过管控机制约束风险，以此实现安全的强制落地。要在实际运行场景中保障车辆安全，首先得明确对应的安全约束，这些约束必须能在运行时通过状态监控、故障诊断，或是完整的闭环自适应机制来评估校验。

2.根据车辆可能运行的不同上下文强制执行车辆安全行为。系统架构需要提供可行的方案，要么调整自身设计，要么通过运行时的安全保障功能，来满足多重安全约束。毕竟安全约束往往和场景高度绑定——很多安全评估都只在特定场景或用例下才生效，所以架构模型必须具备捕捉、存储这些场景化信息的能力。

3.遵循黑盒方法促进系统功能的集成，各个组件只对外暴露服务内容和接口规范（比如消息的输入输出规则）即可。分配给监控模块、安全评估模块的功能，都可以通过面向组件的架构来发现和接入。举个例子，要集成负责状态观测、数据处理、分析研判、行为预测的组件（比如神经网络、机器学习模型、马尔可夫过程模型这类），只要找到适配的组件插进架构里就能完成，唯一的前提是这个组件已经在知识库完成注册、规范信息齐全。注册信息需要包含组件所需资源、预期输出、安全层面的属性等内容。

4.为各个自动驾驶机制提供内置和附加的监控、诊断和自适应流程，这些流程可以在系统运行时按需组合、统一编排，融入整体设计当中。为了可观测性和可追溯性，我们希望系统能够使用内置或附加的监控、诊断和自适应流程。附加流程可以连接到现有系统，而无需对目标系统的接口进行重大修改；内置流程可能会施加设计要求。它们要求系统提供可扩展和可插拔的架构，其中新组件可以轻松添加其各自的逻辑（例如决策方法的目标和值）。流程的组合和编排有助于跨不同服务提供端到端可见性，并深入了解每个服务的性能和逻辑。

5.在不同的知识库中指定和存储自适应流程的专家知识，分别承担不同的角色：系统架构、接口、目标和运行上下文测量值。内置流程的存在要求系统拥有一个架构规范模型，该模型定义了组件、它们的行为、功能和各自的逻辑，并且与安全管理面向知识的基础完全一致。例如，这些知识库来源于表示系统的架构模型（即基于模型的表示和追踪系统每个功能和物理实体的行为和约束）或运行环境的表示（即用于自我意识的环境可观测状态）。

本节确定了指导自动驾驶架构框架设计和实现的安全保障需求。

在下一节中，我们将介绍符合这些需求的参考架构，详细说明并解决每个系统需求。

基于前述需求分析，本节提出一种适合增强自动驾驶系统的参考架构，通过两级自适应来保证安全约束。首先，我们逐步构建参考架构。最后，详细说明最终参考架构的主要组件。

架构设计过程

我们的基础架构是雷诺现有的车辆架构ADCC（自动驾驶通勤车），它为车辆提供自动驾驶能力。我们选择该架构是因为它可以被增强，以保证安全决策功能，并能够扩展到我们旨在考虑的安全关注范围。

在此基础上，我们提出一种系统增强方案，旨在添加一个额外的组件，通过将外部专业知识集成到现有 ADCC 架构中来管理安全。图1展示了参考架构，并详细说明了通过传感器和执行器实体连接到车辆世界的感知、导航和车辆控制机制（第①部分）。我们将这个组件扩展称为安全管理系统（SMS）。

图1:包含多层自适应层级的参考架构

为了管理安全，需要通过观察现有ADCC架构的组件和数据流来监控系统。为此，我们建议为ADCC增强一个由观察者和测量器组成的接口，如第②部分所示。

由于我们希望对ADCC的组件执行特定的自适应或重构，我们还在第②部分中添加了相应的重构接口。

然后，组件重构可以由控制回路执行，该控制回路将这两个接口分别用作数据输入和动作输出。每个回路中涉及的流程确保遵守一个安全约束，并表达观测与重构动作之间的联系，如第③部分所示。为了降低复杂性，我们建议每个流程专门针对一个安全约束，因此将存在与安全约束数量相同的控制回路流程。该架构产生多个并行流程，它们共享相似的观测源和待重构的组件。

此外，不同的安全约束可能存在冲突，并且可能仅在特定上下文中起作用。为了管理需要保证的并发安全约束，我们提出一个宏流程来管理上下文和冲突（见第④部分）。

最后，为了保证系统支持持续迭代、全程可追溯，同时组件方便接入、互相之间能顺畅交互，我们建议统一遵循通用语义规范（详细内容见第⑤部分）。这套规范既能打通各个接口的通信，也支持对知识做精细化的设计梳理 —— 比如状态观测、系统重构、决策逻辑、安全约束、潜在冲突这类专业知识，都能按这套标准来沉淀。

组件描述

安全管理系统（简称SMS）的架构，是在原有基础架构之上扩展出了核心组成部分。各部分结构如图1所示，具体说明如下：

A.ADCC与SMS的接口：在我们的研究范围内，这套接口负责做数据的双向映射：一方面把传感器采集的原始信息，转换成自动驾驶系统能识别的内容，包括感知到的周边物体（本质就是读取车辆的传感器数据）、车辆的行驶意图（也就是读取车辆规划好的操作动作）、自动驾驶系统的实时运行状态（比如读取车辆的行驶轨迹），还有其他组件的状态（比如车辆的配置参数）。另一方面，系统输出的重构指令也会通过这个接口下发，内容包括推荐的行驶策略、操作动作，或是强制执行的行驶轨迹 —— 这些指令会在不同层面调整自动驾驶系统的功能配置。

B.安全评估流程与行为安全保障：这套参考架构的第一层，运行着多套并行的高可靠流程，在系统运行时严格落实各项安全约束。每一套安全评估流程，都专门负责监控和守住某一项特定的安全要求。每套流程都整合了多环节功能：先做实时状态监控，再根据识别到的异常征兆做诊断，最后通过规划调整或者系统重构，来修正自动驾驶系统的行为。流程的规则设定，是基于对应的安全约束要求，再结合运行场景的限制来制定的。举个例子：在城区道路以30公里/小时行驶时，车辆和行人之间的最小安全距离要保持在5米。

C.安全编排器与安全保障的上下文相关性：第二层自适应机制搭建在第一层的基础上，相当于一个总控的大流程，会根据实时识别到的运行场景，动态调整已经部署的安全评估流程。调整的依据有三个：当前的场景条件、不同安全约束之间的冲突情况，还有系统的可用资源。还是用刚才的场景举例：同样在城区，如果车速提到50公里/小时，车辆和行人的最小安全距离就要调整为12米；要是车辆定位的不确定性太高——也就是定位功能可能工作异常的时候，这个安全距离还要进一步加大到25米。通过这种编排调度，已经部署的流程会自动调整自身结构，适配当下的实际场景，保证系统配置既贴合场景要求，又能守住安全底线。

D.知识模型：前面提到的两级自适应机制，都被设计成了通用流程，只要拿到对应的运行信息就能正常工作。在我们的方案里，这些流程都不绑定具体的技术实现，它们需要的知识都可以从共享知识库中调取，只有真正部署到运行环境之后，才会加载对应的知识启动运行。在这套参考架构中，我们把所有相关内容都整理成标准化模型，存到共享知识库中统一调用，具体包括：各类运行场景、安全约束的部署规则（比如场景适配规则、适用限制）、系统配置参数，还有流程运行需要的各类信息。

小结

本节我们介绍了一套参考架构，用来满足安全管理系统（SMS）在可重构性、灵活性、可追溯性和可观测性上的明确需求。我们提出了一套可接入ADCC的扩展架构，依靠两级自适应机制来统筹管理各类安全保障流程，同时明确了各项流程的规范，既保证了场景适配性，也能应对不同约束之间可能出现的冲突。

基于前面提出的各项需求，再结合这套参考架构的组件设计，我们下一节会重点推进参考实现架构的开发。我们会分析：这套参考架构的设计思路，对应到可重构、灵活、可追溯、可观测的安全管理系统上，具体有哪些落地实现的要求；同时也会明确，要满足前面分析的所有需求，系统需要具备怎样的结构和运行逻辑。

为了实现可重构架构的可观测性、可追溯性和灵活性，本节基于现有解决方案的组合，提出了一种灵活、可组合和可观测的架构方法的实现需求分析。

首先，详细说明连续采用自主计算范式、微服务架构风格和基于语义模型的知识表示，如何有助于设计具有预期属性的自管理系统。然后，第4小节介绍了基于这些结构和行为概念组合的连续收集、组合、分配和编排方案。在我们的案例中，该方法包括将安全约束分解为结构化且可管理的安全保障流程及其各自的功能。同时提供了架构的更详细实现视图，以说明分解和应用于安全的结果。最后，第4小节的最后一部分详细说明了自管理系统的知识应如何结构化，并举例说明其在自动驾驶中的应用。

实现需求分析

我们已经确定系统的可观测性、可重构性、可追溯性和灵活性属性，是我们的自管理系统恰当应对自动驾驶安全不同挑战所必需的。本节基于自主计算、微服务和语义知识表示方法，确定满足这些需求的潜在解决方案。

自主计算

自主计算范式提供了组件之间的分层组织，通过所谓的MAPE-K自主回路执行相关的自适应。这些回路由执行监控（Monitor）、分析（Analyze）、规划（Plan）和执行（Execute）功能的组件链组成，围绕共享知识库运行。每个MAPE-K回路提供一种特定的重构，可以在一个学科内实现（即协调相同类型的自适应，例如自配置、自修复、自优化和自保护）。它们也可以跨不同学科运行，协调多种自*能力。

由更高级别回路管理MAPE-K回路被定义为自主编排。它有助于构建分层决策，这得益于MAPE-K回路的通用性和可组合性。自主计算范式非常适合自管理架构，其中组件或资源需要根据监控的环境条件进行重构，并在策略和目标的指导下运行。

采用分层结构有利于通过不同级别的专门决策实现可重构性，这些决策可以管理其他组件或被管理。自主计算为决策（MAPE）提供了这种分解结构，以及编排的可能性，以开发自适应系统。基于四个MAPE功能和知识库设计自主流程，有助于通过定义具有特定关注点的回路来简化复杂性，使其随时间更易于管理且更易于观测。此外，每个MAPE功能的输入和输出都可以被观测、记录和必要时重放。

我们已经看到，四个MAPE功能和相关的知识库组成了决策过程。因此，组件之间的命令链通过各自的角色定义、指定的输入/输出、调整其功能的目标和策略，以及实现特定技术、方法和算法的操作，变得明确。每个功能的整个定义和结构，有助于在设计和运行时促进系统的可追溯性。

此外，MAPE功能可能不止有一种可能的操作或实现。在给定时间的权衡可能会施加特定的定义，仅允许使用一定范围的机制。然而，未来的设计可以通过在决策过程中替换组件来改变功能的运行方式。只要保持功能和角色，并且恰当地更新输入/输出和知识，就可以替换MAPE-K回路的组件或整个回路。为每个功能拥有可替换的组件，促进了架构在开发迭代或运行期间的可维护性和适当演进，可以选择恰当的流程。

自主计算提供的分层结构也符合需求扩展，因为我们可以添加新的接口化受管资源或新的MAPE回路来执行新的特定流程或监督现有流程。

自主计算范式有助于覆盖我们预期属性的结构范围，因为它指定了自适应系统的决策结构，也有助于行为实现、管理和可追溯性（建模和处理）。

微服务

微服务架构风格应用于IT领域，以减少耦合并分解Web服务架构中的单体应用，从而提高其可扩展性。它强制采用不同的方法来实现能力、功能和特性。每个组件都设计为只做一件事；“专注于一件事，并把它做好”。这种在信息物理系统中的应用，体现在它们的结构和设计上，增强了服务的松耦合和高内聚性。

必然需要额外的知识来描述组件应如何连接、能力和特性如何关联、微服务如何部署（即应用需求的语义）、我们希望确保的属性（例如服务质量、安全）以及微服务如何编排（即目标和策略）。微服务也声称有助于提高软件架构的可扩展性。

可扩展性是任何架构解决方案的主要驱动力之一。根据文献，可扩展性可以通过三个维度实现：(1)水平复制（即通过克隆组件，如运行多个副本）；(2)功能分解（即通过分解组件的功能）；(3)数据分区（即通过拆分数据或知识库和访问）。微服务架构风格主要强调第二点，通过将系统拆分为多个不同的服务来支持功能分解。这样更容易理解服务的功能及其作用范围。

微服务的另一个驱动力是灵活性。事实上，它们可以被单独替换，以便使用新技术或不同语言执行相同的功能。依赖关系和版本控制也更容易单独管理每个微服务。

在微服务通信接口中采用模板设计，提升了整个软件架构的可插拔性。事实上，使用通用或标准接口也通过促进对通信通道的观测和监控，提高了系统的可观测性。

微服务还具有提高故障隔离的相关能力。基于微服务的系统通常不会因单个服务的故障而受到影响。在这种类型的软件架构中，容错机制和测试弹性的对抗机制（例如Netflix的chaos monkey故障注入）的实现变得更加容易。

我们相信，微服务架构允许扩展现有ADCC模块化架构中知识的可追溯性。在该架构中，与大多数自动驾驶架构一样，出于性能和不确定性考虑，公认的自动驾驶功能紧密耦合。它们像黑盒一样运行，行为不透明，降低了我们希望提升的可观测性和可追溯性。事实上，目标和策略等知识源不能直接作为服务被理解或访问。我们希望探索如何在保持可追溯性的同时，实现关注点分离和针对特定关注点的精细规范。为此，微服务在操作与技术无关的知识导向之间的分离方法，可能提供一种可追溯的方式来观测、追踪、验证、确认并最终信任系统。

考虑到所涉及功能的多样性和动态复杂的运行环境，采用微服务架构风格似乎是在自动驾驶中实现自适应系统架构的可扩展性和灵活性的恰当解决方案。微服务有助于覆盖我们预期属性的结构范围，因为它指定了组件之间的内部通信结构和作为微服务的分配方式。

知识表示与语义模型

模型驱动工程（MDE）通过解决表示问题（即灵活性、可扩展性和可追溯性），促进了复杂系统（包括自适应系统）架构的开发。在MDE中，与系统实现分离的系统抽象模型不仅用于文档编制，还作为架构细化的载体（例如理解、设计、开发和维护系统架构）。因此，模型驱动架构（MDA）方法强调系统与其实现之间的分离，目标是保证最终系统架构的可演进性（即可互操作和可重用）、灵活性（即可移植、可扩展）和可追溯性（即包含系统规范和能力）。

本体驱动架构，简称ODA，主张用语义模型或者本体，来呈现模型驱动架构（MDA）里的系统抽象模型。就像系统和软件工程实践里推荐的常规做法一样，这套方法既能帮我们统一领域内的专业词汇体系，也能清晰定义目标系统的各项规范和能力边界。本体可以把各类现有概念、实例之间的语义关系梳理清楚，而且这些关联是支持查询检索的；同时它还能给模型提供一致性检查和验证的能力。采用ODA之后，系统架构的可观测性和可追溯性都会得到提升，原因很简单：它定义的概念人和机器都能读懂，也都能检索调用。

除此之外，在自适应系统里应用ODA，还有助于梳理和调取系统重构所需的各类知识。在我们的设计思路里，它用统一规范的模型把反馈回路做了工程化落地，过程严谨且逻辑一致，因为它完整捕捉了自适应机制本身，还有回路里交互的所有信息。

用语义模型来做知识表示，刚好能覆盖我们期望的各项属性在结构层面的要求，尤其是在知识的采集、记录方式以及知识体系搭建这几个维度上，能很好地匹配需求。

结论

本节评估了所需属性可以通过自主计算、微服务和基于语义模型的知识表示方法来解决。基于此目标，并参考架构组件实现，我们的工作重点是开发多级基于微服务的软件架构动态重构的过程正确规则。

下一节执行这些方法的连续组合，以获得具有我们预期系统属性和各自优势的最终架构。

结构和行为实现

本节通过四个连续步骤介绍框架的结构和行为实现。图2说明了逐步方法论，以从一组安全约束中获得面向微服务的可组合且可编排的参考架构，提供灵活且自适应的运行时安全保障能力。

1.将安全约束并行转换为微服务

2.运行微服务以在组合时提供诊断或安全保障

3.强制执行系统级安全

图2：安全约束在系统中的集成流程

第4小节介绍了最初在模型中表达且可在运行时评估的安全约束，如何被表示为多个需要在运行时保障的安全保障流程的集合。然后，每个流程根据第4小节中的组合方案分解为四个不同的功能。在此步骤中，还识别共享知识和交换信息。第4小节描述了将每个MAPE功能分配给不同类型微服务的步骤。第4小节描述了管理安全约束的编排方案，将其转换为结构化且可管理的安全保障流程及其各自的功能。

最后，第4小节总结了最终架构、已识别的层以及每个系统能力如何覆盖这些属性。

并行管理安全约束：运行时的安全保障

在文章“第一部分”的第3小节中，我们将兴趣集中在自动驾驶系统整体上。通过将安全视为强制执行安全行为的控制问题，我们为我们的L4级自动驾驶汽车和运行设计域确定了安全约束。这些安全约束可以分为两类：一类通过细化设计来消除危害，另一类通过管理控制危害以减少不良事件。我们现在旨在通过对自动驾驶系统执行运行时监控、诊断或自适应，来保障后一类约束。

图3说明了可以在功能系统运行期间执行的安全保障流程。在我们的研究范围内，传感器和执行器可以是真实的或虚拟的。例如，它们可以分别充当来自外部和内部传感器的观测源（例如感知到的物体、组件的本体感受观测）和控制动作的消费者（例如要遵循的新轨迹、要部署的服务、要采用的新配置）。在我们的方法中，这些安全保障流程在运行时并行执行于自动驾驶汽车的功能架构上，如图4所示。

图3：单一约束安全评估示意图

图4：多约束可靠性运行评估

使用MAPE-K作为自动化的架构解决方案：用MAPE-K自主回路分解控制回路

为了提升可观测性，我们将控制回路识别为自主计算范式中的自主管理器。在这方面，我们将其分解为共享各自知识的监控、分析、规划和执行功能。图5提出了一种表示，其中四个部分协同工作，实现执行安全保障流程的自主回路。功能之间的通信以症状、变更请求、变更计划和动作的形式进行，使用回调或共享内存。

图5：控制流程拆解为共享知识库的监控、分析、规划、执行（M、A、P、E）功能模块

需要注意的是，并非所有安全保障流程都必然对自动驾驶系统执行闭环控制。事实上，有些流程可能只旨在执行完整自主回路的一部分，例如测量（监控+知识）、诊断（监控+分析+知识）、规划（监控+分析+规划+知识）或完整回路的自适应（监控+分析+规划+执行+知识）。

监控功能：通过传感器接口访问受管资源的信息。对检索到的信息进行过滤，仅将相关部分传输或存储在知识库中。聚合、关联和过滤确定是否需要分析生成的症状。然后将症状传输给分析功能。需要注意的是，如果关联关系多样或过滤条件不同，一个特定自主回路可能存在多个监控功能。引发的症状可能与来自多个资源的不同消息或事件内容之间的特定组合事件相关。例如，检测到行人存在可以视为一个症状，行人正在过马路也可以视为一个更复杂的症状。监控功能内流程的粒度决定了症状是简单还是复杂。

分析功能：将观测数据与期望值进行比较，例如异常检测。更复杂的分析可能需要使用行为感知技术，例如部分可观测马尔可夫决策过程（POMDP）、概率方法或基于学习库的方法。当某些策略未被满足或即将被违反时，会生成诊断结果，形式为变更请求。变更请求包含分析功能认为必要或有益的修改内容。

规划功能：由诊断触发，选择或确定策略以实现预期目标（创建、纠正、预防）。研究各种计划，并将一个最终计划传输给执行功能。变更计划包括规定要应用于受管资源的一组变更（例如一条轨迹）。

执行功能：通过效应器接口执行纠正动作，并缓存该过程以供未来分析和规划使用。从这一步开始，知识库不仅表示影响决策方式的策略，还包括从观测中检索的信息、环境配置和内部通信（即症状、变更请求、变更计划和动作）。此外，监控功能可以有助于创建关于近期观测的知识，执行功能也可以通过已应用的动作来丰富知识。

将MAPE-K实现为微服务

为了提升最终架构的可组合性和灵活性，我们将每个MAPE功能和知识管理分配给不同的、具有功能描述的独立微服务。就此而言，这种分配方式会创建小型、独立、可部署且简单的类型化服务，每个服务提供不同的功能（即监控、分析、规划和执行）和通信接口。

从功能角度来看，这些微服务继续实现如前所述的自主循环。图6展示了将一个安全约束分解为MAPE-K后，对应的M、A、P、E、K微服务及其各自的通信通道。K微服务即知识库服务（KBS），通过接口提供对知识库的访问。

图6：单条自主闭环由监控、分析、规划、执行（M、A、P、E）实体构成，用于观测、诊断并保障系统安全

图6一个自主循环由M、A、P、E实体组成，用于观测、诊断或保障安全。

因此，系统的结构在设计、实现以及知识的使用和管理方式上都受到了影响。交互不再是回调，而是变成了消息或客户端 - 服务器关系。例如，监控微服务被设计为按照特定的接触点命名规范访问某些观测值，发布症状并将相关信息或直接将症状存储在知识库服务中。

微服务持续运行，执行其功能或等待被触发。

然而，采用这种微服务结构以获得其优势，意味着需要支持面向服务的目标。额外的功能，如服务仓库、服务发现（运行或未运行）、服务契约标准化，都需要纳入框架的逻辑和物理架构中。

使用各自微服务实例的组合来运行多个自主循环的优势有两方面：

超维度：并行运行多个可组合的自主循环 首先，微服务实例可以被重用以运行多个自主循环，这同时影响设计和运行时。这将使服务描述和数据模型变得高度可发现。一方面，使用MAPE-K设计新的安全约束时，只要所需功能相同，就可以重用现有的微服务。另一方面，在运行时，整个系统中同一功能只需部署一个微服务。这种超维度的引入影响了设计，因为系统能够知道当前部署了哪些服务或有哪些服务可供部署。

图7展示了两个安全约束使用MAPE分解方案并行运行的情况。它们独立运行，并涉及多个微服务来执行监控和分析功能。由于其规模较小且映射到特定的 MAPE 角色，它们在系统上的功能可以轻松定义。

图7：基于监控、分析、规划、执行（M、A、P、E）微服务并行运行多条自主闭环，展示超维度架构

图8：多条自主闭环并行运行，复用已部署服务作为监控、分析、规划、执行（M、A、P、E）实体，展示该框架的超维度特性与可复用特性

现在假设这些监控和分析功能的某些角色是相同的，可以在两个安全流程之间共享。图8突出显示了在并行运行的不同循环中，对已部署的M、A、P、E微服务的这种重用。在设计方面，只要操作和观测值保持不变，通信服务就允许重用。

多维度：并行运行涉及不同约束维度的多个自主循环 其次，其他维度（如社会接受度、伦理、法律、性能）也可以通过我们方法中的安全保障流程自主循环与安全维度集成。然而，它们仍然需要使用我们之前介绍的 MAPE-K 微服务方案来表示。图9展示了引入一个需在运行时保障的社会约束作为自主循环的情况。该示例仅在之前的示例基础上增加了一个社会约束。例如，社会约束针对与弱势用户保持社会可接受距离的特性（即与行人保持距离）。

图9：多条自主闭环并行运行，复用已部署服务作为监控、分析、规划、执行（M、A、P、E）实体：展示该框架的多维度特性与可扩展特性

此外，需要注意框架的超维度特性，即来自其他维度的类似服务只要涉及相同的功能和关注点（例如收集过马路行人的道路和车道位置信息），就可以被重用或重用其他服务。

MAPE-K 微服务的编排：管理自主循环

本小节的目的是理解这些方案的结合如何成为监控安全关键软件系统的关键推动因素。我们还将阐明它们在框架中的角色和根本优势，以便最终为我们的关注点定义参考架构。我们使用自主计算中**编排自主管理器（OAM）**的分层协调方式，来执行框架范围内的自主行为，这些行为所属的学科与它所管理的资源完全不同。该编排自主管理器将图9中自主循环的自主管理器（即执行我们的安全和社会评估流程）视为托管资源。它同样执行监控、诊断、规划或自适应功能，并由M、A、P、E、K微服务组成。图10展示了作为托管资源2的安全和社会评估流程与作为更高级别管理实例的编排自主管理器之间的这种分层结构。

图10：面向不同业务领域的多层级自主闭环架构：展示该框架的编排调度特性与可复用特性

一个应用示例是本文章中该层级的预期用途，即作为一个自主循环，为当前上下文重新配置已部署的安全评估流程。我们之前已经了解到，自主管理器会持续执行自主循环，为给定上下文（即它们相关、可部署且足够高效的上下文）实现安全评估流程。然而，上下文的变化可能导致安全约束的评估不再适用于新上下文，甚至无法接受，从而可能导致当前上下文的违规。由于意识到这些安全评估流程的上下文依赖性，编排自主管理器会监控这些自主管理器和当前上下文，以确定并部署最合适的自动驾驶系统安全保障配置（以及其他维度的配置）。该编排自主管理器还可以根据管理的依据（例如系统上下文、自主管理器的性能、一致性、安全保障的稳定性等）纳入超维度和多维度的考量。

最终架构

该架构最终由以下逻辑部分组成：

1.接触点：将系统与自动驾驶系统的功能架构进行接口连接

2.自主管理器层：集体执行安全保障，分配为M、A、P、E微服务网格，代表第一级自适应

3.编排自主管理器层：执行安全保障的重构，以根据上下文进行自适应，代表第二级自适应

4.知识服务层：提供对不同共享知识库的独立访问，其中存储了症状、诊断、变更计划，管理对两个自适应层级各自不同知识源的访问

小结

本节基于安全约束，通过四个连续步骤介绍了参考架构的结构和行为实现。所提出的面向微服务的架构通过使用组合和编排机制，在运行时提供了灵活且自适应的安全管理能力。

然而，运行这些机制所需的不同知识源仍需识别并明确定义边界和语义。下一节将介绍这些不同的源如何被表示为本体（例如系统运行上下文、车辆能力和动作以及接口）。

知识库与语义模型的设计

要让两级自主自适应机制正常运行，MAPE-K循环得依赖知识库提供的各类数据源。实际上，监控、分析、规划、执行这四个环节各有各的运行逻辑，需要不同知识库内的实体之间建立对应关联，按既定规则交互才行。所以我们提出用本体作为语义模型，给两个层级各自对应的知识做建模。

这两个层级针对安全属性的不同维度，定位也不一样。第一级的行为自适应，需要的是安全保障流程执行相关的信息；第二级的结构自适应，则是基于场景的依赖要求，来保证已部署的各个实例能合理组合运行。因为用途不同，我们需要搭建两个独立的知识库，分别支撑两级的自适应机制。不过虽说定位有区别，但像场景抽象、系统表示这类基础内容，其实是可以在两个层级之间共享的。

为了满足MAPE各环节的知识需求，我们沿用了现有文献里针对模型架构提出的五类模型，同时结合参考架构的两个层级分别做了适配调整。我们也梳理清楚了参考架构每一层的对应映射逻辑，还举了它们在自动驾驶汽车安全领域的实际应用案例。最后我们还会说明：设计阶段这些知识模型的信息来源是什么，以及运行阶段这些模型要怎么使用、怎么迭代更新。

运行时模型的主要类型和信息

为了把每个知识源的边界划清楚，我们参考了Aßmann等人在模型架构领域提出的模型抽象方法。他们把模型分成五类，以此覆盖知识表示的各类需求，也明确了各自的边界。下面我们就逐一介绍这几类模型的作用、覆盖范围，以及在我们的方案里对应的运行时知识内容。

·上下文模型：它负责呈现环境的可观测状态，里面包含了和目标系统相关的各类实体信息。监控类的微服务会做语义层面的解析，也就是对当前场景做解读，再把识别到的特征作为异常征兆存到上下文模型里。所以这个模型一般分成两部分：一部分是对场景的抽象定义，作为静态的术语基础；另一部分是运行时动态变化的内容，只记录从环境里检测到的实时征兆。在我们的研究范畴里，上下文模型的概念和自动驾驶里的运行设计域（ODD）很接近，它划定了车辆在设计预期内、可以安全运行的各类条件和场景范围。运行设计域可以分成多个层级来搭建，分别描述动态交通参与者（比如汽车、公交车、行人、滑板车）、定位范围（比如电子围栏）、道路场景（比如道路几何形态、配套基础设施），以及允许的行驶场景（比如高速巡航、自动泊车），能帮我们搭建完整的场景体系。因此，抽象表示可用的术语应包含这些不同的概念。症状也应组合它们以创建已识别的上下文抽象。

·配置模型：描述托管资源的接口，以及如何访问和控制它们。它们有助于表征接触点运行自主循环所需的知识（即可管理性接口）。这些模型可以看作是提供与托管资源交互的架构视图。在通用的面向服务方法中，它们将反映哪些通信通道和托管服务当前可用，以及部署在哪些配置和平台上。在我们的框架中，它们是监控和执行功能初始化的来源，用于与托管系统进行适当的接口连接。它们会影响部署用于管理自动驾驶系统的自主管理器微服务以及构成编排自主管理器的微服务。上下文和配置模型共同助力捕获人类和机器可理解的外部和内部观测表示。

·能力模型：描述可用功能如何通过哪些动作以及涉及哪些执行器接口来影响托管资源（例如调整参数以要求更低的速度、部署新的微服务）。这种模型类型预计相对静态，因为它表达了系统所有可能的能力，但可以更新（例如新设计、新结构）。在我们的范围内，这些功能是在自主管理器中强制安全的机制，以及强制其可接受上下文的机制。

·计划模型：表示作为执行自主自适应的计划的不同动作集合。规划功能有助于将请求的变更存储到模型中，执行功能将其转换为发送给执行器的动作。与定义系统和交互结构的 **术语盒（T-Box）相反，计划模型使用能力模型的结构将每个动作描述为断言盒（A-Box）**中的个体。因此，它们收集了发送给托管系统的所有请求动作的历史记录。

·目标与自适应模型：定义每个 MAPE 功能的执行方式（即指定机制）和调整方式（即指定配置）。例如，它们描述规划功能应如何评估备选的未来配置，以及监控功能应如何触发自身以创建症状。此外，这些模型是设计选择的基础。

事实上，我们决定目标与自适应模型仅描述系统的术语（T-Box），且在运行时不发生变化。这一特定设计选择背后的主要思想是强调不同微服务的配置与上下文（即内部和外部）之间的可追溯性，以及正确编排它们的能力。第一级使用无状态的自主管理器微服务执行安全评估，而第二级持续验证上下文依赖性约束（即特定自主管理器在特定上下文中部署和运行的限制）。因此，只有可用微服务的配置预计会在运行时发生变化和组合。这意味着目标和机制模型为所有微服务指定了它们不同的静态配置和上下文部署限制。

此外，这些模型预计会在设计迭代过程中随时间变化，以在系统生命周期内为特定微服务操作新机制或进行调整。

表1综合了参考架构每个层级各类模型的作用和应用。值得注意的是，关注点和需要表示的知识因参考架构的层级而异。最后，图11展示了框架本体中不同概念模型及其关系的概览。

表1：参考架构每个层级的模型类型和描述

图11：以各模型为模块所表征知识的整体概览

其中详细介绍了应用于后续发布的“第三部分”的案例研究上下文的知识库的需求、建模选择和实现。

语义导向的优势讨论

我们将这种基于知识的方法视为一种可在运行时运行的、可请求和可更新的推理能力。因此，它开启了在系统中进行论证的可能性。它还允许在不同推理器之间进行比较，并执行权衡（即实现语言、本体的使用方式以及我们利用的关系）。新用例、场景或等效规则的添加和集成，可以直接在模型上研究其影响，而无需额外的实现工作。

我们还欣然继承了本体的互操作性，这有助于将基于模型的系统工程工具（如 Capella）中的系统表示，转换为监控、分析、规划和执行本体类。

此外，我们认为表示上下文模型的本体提供了一种合理的方式，将抽象上下文组合为一组场景、情况和其他继承类。它充当了这些不同表示形式和粒度范围的目录。

将本体中的公理表示为类，也满足了它们可以直接作为类导入代码中以实现更好互操作性的需求。通过某些软件包，可以将原始本体概念无缝导入为类并直接使用。这一特定部分属于未来工作范畴，涉及创建工具链以及将知识从模型、本体流畅过渡到实际可执行代码。

最后，自动驾驶汽车社区从近期的碰撞事故、未来的标准、法规和预期行为中吸取的教训，强化了朝着特定运行设计域和验证方向专业化的趋势。我们的方法可以通过可组合的上下文抽象和微服务明确的上下文依赖性限制，将这些需求整合到先验知识中。在此基础上，更新后的模型与实际系统的一致性仍由第二级自适应持续验证。

本部分阐述了我们用于设计自主和认知自动驾驶汽车系统的面向微服务、基于模型驱动的框架。在该框架中，我们结合了一组模式来实现两个层级的自适应及其各自的知识。我们定义了不同的模型及其在自主自适应各功能中的用途。这些模式和模型的定义，是由自动驾驶汽车系统对可追溯性、灵活性和可组合性的需求所驱动的。我们举例说明了组件和知识库模式如何满足这些非功能属性。

下一部分将把介绍的模式和模型应用于行人案例研究的安全评估中。

在该系列文的后续“第三部分”中，我们将描述参考架构在ADCC架构中的实现，所采用的技术和方法包括软件开发、知识表示、场景构建、环境仿真和安全度量。通过一个行人过马路的简单安全用例，对所提出的方法进行评估。请持续关注“猿力部落”公众号后续发布的该系列文章后续篇章。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。