自动驾驶汽车安全管理自主框架(一):方法论

本节研究系统工程中如何管理自动驾驶安全。我们通过调研不同领域中仅针对一个或多个属性实现服务质量的研究工作和解决方案，继续进行分析和发现。

自动驾驶中的系统设计复杂性

多种具有不同互补能力的功能组合，促成了自动驾驶汽车的出现。它们的部署受到自身复杂性以及真实环境中面临的具有强烈安全关切的挑战的限制。因此，大规模部署前的一个主要关注点是，如何确保自动驾驶汽车尽管可能遭受内部（例如故障）和外部（例如激进行为）干扰，仍能保障安全。

系统工程在一定程度上有助于解决自主性、上下文、系统架构和知识的复杂性问题。自主性在系统工程方法和知识表示两方面都提出了两个挑战。首先，系统工程提供了管理自动驾驶功能和非功能分解复杂性的方法。系统理论与分析还原和统计学一起，是应对复杂性的一种方式。系统化方法通过定义新的明确需求来管理复杂性：需要提供整体和系统化的工程（通过方法论、工具、流程和定义）。它在整个生命周期中提供架构（系统、组件、功能）的可追溯性和灵活性。此外，它还提供自顶向下、自底向上和中间向外的可能性，以增强和整合学习过程、更新和新法规，从而促进获取和适应自主系统所需的知识。

面向运行时安全表示与保障的“设计即安全”架构

尽管汽车行业对自动驾驶系统的工程实践采用自底向上的方法，首先关注功能和技术，但架构已经开始纳入这些关注点，并朝着这些属性进行设计。它们同时捕捉了自动驾驶的功能分解、非功能分解（即安全）和上下文分解。标准和研究中对符合这些要求的认可，以及对自动驾驶中更高自我意识和安全性的追求，已经在不同的系统自适应规模上相继引入。

混合架构：首先，Albus的4D/RCS框架提出了一种混合控制架构，兼具慎思型（即基于推理和规划的动作）和反应型（即基于对反馈的直接简单条件的快速动作）特点。一方面，该框架结构确保基于控制层次中决策实体的目标和优先级进行推理和规划过程。另一方面，在控制层次的每个级别都引入了反应回路，提供更快和受控的响应，可以局部修改规划的动作以适应新事件。这种方法在概念和结构组成上与IBM提出的自主计算范式相似，后者在IT基础设施中采用了分层的自主编排管理器。

降级状态和模式：Tas等人在定义鲁棒系统架构的工作中，强调了架构设计与降级运行模式使用之间的关系，降级运行模式由文献引入。作者将功能化和分层系统架构的设计，视为自动驾驶应对安全关键挑战的主要焦点之一。此外，他们认为有效的监控系统是必要的，以便向车辆提供关于其状态的适当反馈，并允许做出恰当的决策。运行模式和优雅降级这两块内容，在各类学术文献里还在持续开展研究。

系统能力和局限性的自我意识：就监控层面来说，Reschka 等人的研究指出，自动驾驶车辆得全程在线监测自身的能力状态，同时还要有配套的建模工具，才能支撑系统做出合理、安全的决策。他们这套框架的思路很清晰：先摸清系统的动作范围和能力边界，运行过程中就能实时感知当下的性能表现。参照 ISO 26262 功能安全标准，这些研究者提出，可以用能力图谱和技能图谱来搭建自动驾驶汽车的功能架构。这些技能维度会反馈系统的实际性能表现，反过来又用于实现系统的自我状态感知。除此之外，Colwell 等人还引入了子系统功能降级机制，再加上运行设计域的约束，以此明确系统安全运行的边界。

建构主义和分层可演进架构：针对自动驾驶的长期迭代发展，Behere 等人梳理出了自动驾驶必备的核心功能组件和发展方向，用来搭建一套分层设计、可逐步演进的功能架构。他们认为需要建构主义架构，由人工智能管理，以解决当前工程实践在扩展到更复杂系统方面的局限性。这些所谓的建构主义架构引入了从手动设计到运行时自演进的自组织架构的根本转变。当前的挑战在于运行时推理和期望属性（如安全约束）的运行时验证的可能性。这种架构的设计和实现将涉及非汽车领域的范式和技术。例如，在功能层之上使用基于高层监控器的反射智能控制系统，将允许监控和改变其行为以实现更好的自适应。

这些方法已逐步引入汽车领域，旨在提出恰当决策的解决方案；理解系统动作的范围和局限性；演进结构以提供更好的自适应行为；以及整合非功能维度。研究人员已经开始研究将这些模型应用于运行时环境的可能性，在整个系统及其功能中结合设计即安全和运行时缓解。这种超越典型软件演进方法的软件变革，催生了自适应软件的愿景。

保障安全运行的自适应软件

文献中已经提出了多种用于应对不确定性的运行时模型，它们被认为是解决前述自动驾驶安全关切的恰当解决方案。这种类型的架构涉及建构主义、可演进或动态行为系统，被称为自适应架构。它们充当编排解决方案，能够支持可演进和可重构系统中安全等非功能质量保障的可接受权衡。

可组合且灵活的系统

微服务简介：在软件架构方面，模块化和抽象是将系统复杂性分解为程序和架构的第一步。然而，根据Dragoni等人的观点，这些步骤仍然会导致单体应用的产生，即通常作为单个单元构建，功能分布在模块和组件中，无法独立执行。最终产品和代码导致可扩展性、可维护性和可演进性方面的困难。

为了应对这些问题，建议使用微服务作为软件开发中的架构风格，将单个应用程序创建为一套小型可组合服务。这种方法强制组件仅实现一个功能，从而表达一种能力。受面向服务计算的启发，Martin Fowler等人将这种当前软件开发运动的术语形式化，作为单体风格应用的替代方案。该方法建议将系统的所有业务能力隔离到简单且小型的专用服务中，这些服务类似于组件，但解耦程度足够高，可以通过自动化部署机制独立部署。微服务是一个独立的功能进程，表达一种能力，也被称为内聚性，通过消息进行交互，并在本地拥有其领域逻辑。

自适应或安全关键系统中的微服务：相关文献有微服务架构在无人机中的应用示例。其预期方法能够在运行时发现新服务并提供自动化部署机制，这要求微服务通过语义描述其业务能力（行为）、目标（系统）、逻辑、结构（组件）和接口（通信）来实现自描述。

在设计中使用微服务的优势在于它们能够小范围失效。它们不仅允许基于对这些故障的观察进行智能自适应，还使容错机制更容易界定。

应用范围

目前该领域的工作已经提出了改进、整合和强化自动驾驶安全的相关方法。将安全视为Leveson等人在STPA/STAMP方法中提出的动态控制问题，在文献中展现出良好的应用和结果，而文献则提出了一种与自动驾驶标准和传统故障分析相结合的补充方法，以实现危害覆盖。然而，这些工作的大多数结论都强调，难以提供可扩展的自动化分析、设计、控制和管理。我们将这些在运行时调用的运行时管理流程称为“安全评估流程（SAP）”，它们将是我们研究的重点，因为我们希望它们在上下文需要时能够被部署。

表1：安全工程中的危害缓解方法

然后，通过将该流程应用于这些新版本，以及在系统架构不断被更深入地细化和定义时（自底向上），迭代地执行该过程。

MBSE背景知识

MBSE方法论与技术

前面的内容讨论了设计和维护架构的过程。然而，可以使用什么语言或形式化来描述软件架构呢？

统一建模语言（UML）是软件建模和设计中使用的一种面向对象解决方案。UML 是一种语言（对象建模语言），因此它提供了与该语言相关的表示法和语义（即模型），但没有提供过程方法论（即提出一系列步骤和活动来解决问题的方法）。因此，UML不是一种方法。UML统一了面向对象方法，其设计过程深受其在面向对象编程中的预期用途的影响。它涵盖了整个开发周期：分析、设计和实现，是面向对象的（而非功能的）：系统被分解为协作的对象（而不是分解为更容易执行的任务功能）。然而，它的应用并不特别适合建模复杂系统，也首先不适合系统工程。

Philippe Kruchten设计的架构视图模型，也称为4+1视图模型，表示软件密集型系统的功能和非功能需求。它们在不同的视图中表示，从不同利益相关者（例如最终用户、开发人员、系统工程师和标准）的视角描述系统。该模型的四个视图包括逻辑视图、开发视图、过程视图和物理视图。每个视图都解决特定的系统关注点，此外还有一个用例或场景视图，描述对象之间以及涉及系统的过程之间的交互序列，并指导其他视图。

·逻辑视图：是高层视图，聚焦于抽象和封装，对系统的主要元素和机制进行建模。它识别领域元素以及它们之间的关系和交互（“类和关系的概念”）。

·组件视图：从代码组织的角度表达物理透视图，分为模块、组件，特别是语言或实现环境的概念。从这个角度来看，架构师主要关注代码管理、编译顺序、重用、集成和其他纯粹的开发约束。UML提供了模块、组件、依赖关系、接口等适配概念来表示该视图。

·过程视图：在多任务环境中非常重要，表达并发和并行活动的透视图。

·部署视图：表达系统通过计算机网络和处理逻辑节点的分布。该视图对于描述分布式系统特别有用。

系统建模语言（SysML）是对象管理组织（OMG）定义的新建模语言。它可以看作是UML的扩展，用于建模广泛的复杂系统。它基于UML，用块建模取代了类和对象建模，以提供更适合系统工程的词汇表。块可以包括任何软件、硬件、数据、过程，甚至人员管理概念。

Capella不仅仅是一个简单的建模工具，它是一种基于模型的工程解决方案，已成功部署在各种工业环境中。基于图形化建模，它为系统、软件和硬件架构师提供了基于Arcadia（一种完整的基于模型的工程方法）的丰富方法论建议。领域特定建模语言（DSML）Arcadia/Capella基于UML/SysML和北约架构框架（NAF）标准，并与这些语言共享许多概念。它是由软件系统和架构师在广泛的业务领域（交通、航空电子、航天、雷达等）工作推动下，通过迭代定义过程产生的。许多工业公司，如空客、阿海珐、泰雷兹、大陆集团和雷诺，目前都有兴趣使用Capella并开展试点建模项目。

Arcadia允许：

· 通过共享相同的参考架构，确保工程层面的协作。

· 管理系统和架构的复杂性。

· 通过权衡分析，定义最佳的最优架构。

· 通过信息的自动转换和细化，管理不同级别的工程和可追溯性。

Capella/Arcadia结合了工具和语言：参考MBSE的三个著名支柱，可以说ARCADIA提供了建模语言和建模方法，而Capella完全掌握该语言和方法。

与自适应范围类似，EUREMA是一种集成的模型驱动工程方法，它严谨且一致地使用模型来工程化反馈回路。这些模型用于：(1)表示可适应软件以实现自适应，正如运行时模型思想所提出的；(2)设计反馈回路的各个自适应活动；(3)设计反馈回路整体；(4)协调这些回路之间的关系。最后，(5)这些模型在自适应系统的整个生命周期中使用，即用于指定、执行和演进反馈回路及其自适应活动。这种方法引入了一种模型驱动架构方法，指导复杂和演进系统的设计和开发，同时声称保证最终系统的可移植性、互操作性和可重用性。

使用Arcadia/Capella建模

Arcadia/Capella简介

ARCADIA（架构分析与设计集成方法）是一种用于系统、硬件和软件架构设计的基于模型的工程方法。它由Thales公司在2005年至2010年间开发，通过涉及Thales所有业务领域（交通、航空电子、航天、雷达等）的运营架构师的迭代过程形成。它按照IEEE 1220标准，在连续的工程阶段应用结构化方法，明确区分需求（运行需求分析和系统需求分析）和解决方案（逻辑架构和物理架构）。

ARCADIA建议三个同等重要的强制性相互依存活动：需求分析与建模；架构构建与验证；需求工程。

Arcadia领域特定建模语言（DSML）基于UML/SysML标准和NAF，与这些语言共享许多概念。但为了便于所有利益相关方的掌握，首选使用建模语言而非通用语言。Arcadia主要基于功能分析，然后将功能分配给组件。Arcadia DSML的丰富程度与SysML相当，拥有大约十种类型的图：数据流图、场景图、状态和模式图、组件分布图、功能分布图等。Arcadia在不同级别提供的图在图1中详细说明。

图1：Arcadia方法的核心工程层级

Capella工具提供了不同的工具集，用于执行系统建模，并提供从一个级别到下一个级别的自动转换步骤，在系统模型架构的不同元素细化过程中提供可追溯性。

值得注意的是，Arcadia方法本质上是以自顶向下的方式呈现的。但是，如果从现有系统开始，表示也可以是自底向上的。在接下来的章节中，我们的示例将假设扩展ADCC架构。为此，Arcadia方法论更多地是关于提供关键表示目标的级别，而不是阶段或步骤。此外，并非所有架构级别都是强制性的。由于该方法旨在指导分析和建模过程，根据系统复杂性和模型期望，可以跳过某些级别（例如运行分析、逻辑架构、最终产品分解结构（EPBS）是可选的）。

运行分析

运行分析是Arcadia方法的最高级别，聚焦于回答“未来系统的用户需要完成什么？”的问题。在这个级别，未来系统尚未被表示为建模元素，但系统需求和目标的识别从这一步开始。该级别通过将未来用户的工作建模为活动、需要履行的角色，并明确系统的运行条件，构成了系统环境的第一个表示。一系列活动和交互构成一个流程，并有助于形成运行能力。创建代表不同元素的模型和场景，可以检查系统是否满足这些运行需求。

运行分析级别包括：

1.捕获并形式化来自不同利益相关方的运行需求。

2.定义车辆（系统）需要完成的任务，以及其他参与者如何贡献、影响或产生作用。

3.同时识别每个独立领域中的不同实体（实体、参与者、角色、活动和概念）。

系统分析

系统分析将系统置于与外部参与者交互的数据流表示的中心元素，聚焦于回答“系统必须为用户完成什么？”的问题。系统分析涉及识别满足上一级别定义的运行需求的系统能力和功能。此时，系统仍被视为黑盒，尚未决定内部结构。在此外部功能分析期间，只能分配功能和通信交换。因此，该分析包括细化系统功能，分解顶层功能，并添加非功能属性的约束。在这些方面，Capella上的这些图提供了管理复杂性的丰富机制：高层功能之间的简化链接计算、交换分类等。

功能链也可以显示为高亮路径，它们代表涉及一系列系统功能和交换的特定路径，与分配约束（延迟、关键性等）相关，也用于组织特定系统功能的测试。

系统分析级别包括：

· 定义系统必须为用户完成的任务。

· 识别黑盒系统的边界，整合来自参与者的需求。

· 建模功能数据流和动态行为。

逻辑架构

逻辑架构旨在识别构成系统内部组件结构的不同逻辑组件，聚焦于回答“系统将如何工作以满足期望？”的问题。该级别提供工具来表示组件之间的关系及其内容，独立于任何技术或实现考虑。

上一级别中描述的系统分析模型可以通过自动转换导入到逻辑架构模型中，从而保留所有先前定义的顶层功能和交换。在此基础上，逻辑架构执行内部功能分析，将先前识别的顶层功能所包含的所有子功能，分配给特定的逻辑组件，同时跟踪非功能约束的整合情况。

逻辑架构级别包括：

· 提供系统的白盒视图，识别系统如何满足期望。

· 提出权衡分析的第一步。

物理架构

物理架构级别与逻辑分析具有相同的目标，但定义了系统的最终架构，提供关于系统将如何构建的信息。该级别反映了技术选择，并定义了不同的组件（软件和硬件）。

物理架构级别包括：

· 系统将如何开发和构建。

· 软件与硬件分配、接口规范、部署配置、权衡分析。

EPBS和集成合同

额外的EPBS（最终产品分解结构）级别可用于定义“每个组件必须满足的条件，以满足架构设计约束和在前述阶段建立的限制”。这最后一级回答了“每个组件的供应商需要提供什么”的问题，通常用于分包场景。

在Arcadia/Capella中集成动态安全分析与管理

组合方法概述

我们提出设计一种基于Arcadia的方法论，通过将Arcadia方法论的步骤与针对已定义场景集的STPA分析同步，来恰当表示与安全相关的自适应过程。对于Arcadia的每个步骤，我们建议对任何包含等效控制回路的表示执行STPA分析。

安全分析的集成流程

运行分析：首先，我们的分析必须基于自动驾驶系统和车辆需要完成的行为需求，以及这些需求的来源。事实上，多个参与者是需求的来源，这些需求可能极大地影响车辆的行为方式、设计和实现方式。标准、建议、指南、最新技术水平、汽车制造商、监管机构、租赁公司或最终客户，都对自动驾驶系统施加了多样化的需求，这些需求可以是功能或非功能的，涉及完全不同的学科（例如功能、安全、伦理、社会接受度、网络安全等）。

Arcadia方法论的运行分析有助于捕获来自不同利益相关方的这些运行需求。它定义了车辆需要完成的任务，以及其他参与者如何贡献、影响或产生作用。事实上，我们对参与者和需求的整个过程进行建模，使用特定的实体、参与者、角色、活动和概念词汇，识别每个独立领域中的不同元素。系统的功能部分定义将文献中提供的不同行为能力、物体和事件检测与响应、运行设计域、动态驾驶任务以及来自各利益相关方的需求作为输入。

非功能部分的参与者也同样重要，因为他们要求特定的运行能力，以恰当管理与车辆行为相关的所有危害事件的条件或风险度量。下图有助于说明高层能力、实体、参与者、交互、活动和流程。需要注意的是，图的创建有助于逐步细化系统模型。接下来的图是观察使用Capella工具并遵循Arcadia方法论增量构建的语义模型的视图（或窗口）。

图2：[运行能力框图]运行能力

图2定义了同时涉及功能和安全关注点的运行实体和能力。这个第一个图“运行能力空白图”默认是空的，有助于定义产品周围的领域或业务。在这个级别，我们开始在不考虑架构、设计或技术实现的情况下，描述各利益相关方的“真实”需求。我们用运行能力（OC）、运行实体和运行参与者（OA）以及它们之间的关系来描述模型。对于自动驾驶汽车，利益相关方通常将需求分解为功能和非功能关注点。我们还建议将功能驾驶部分与行为安全策略区分开来，以启动某种核心监控器的技术设计（既在模型中，也在未来的物理架构中）。为此，我们在图2的上半部分识别了一些面向功能的能力（驾驶自动化），在下半部分识别了一些非功能策略（安全和社会维度）。此外，我们通过将每个运行能力细化为多个子运行能力，执行了额外的定义步骤。例如，动态驾驶任务被表示为运行能力，因为它们仍然是运行目标的通用服务高级定义，不能直接转化为活动和后续功能。在我们的案例中，它们的描述和可追溯性通过一些相关活动和运行流程（例如感知、规划、执行）来执行，其他图（例如图4）对此进行了详细说明。

图3：[运行上下文框图]运行上下文

图4：[运行接口框图]能力：“在指定运行设计域(ODD)内运行”

图3定义了运行活动之间的架构以及不同参与者之间的交互，以把握系统的运行上下文。黄色的活动对应于为实体实现精确目标而执行的不同流程步骤。它们可能需要使用未来系统来完成，或者系统可能使用它们（例如提供运行设计域定义）。例如，我们将自动驾驶汽车的运行上下文分配为它可能感知的周围环境（外部观测）以及其内部观测（系统状态）。这些观测随后被功能层的驾驶自动化活动消费。该图还表示了与运行设计域相关的活动，因为它是环境表示和来自不同利益相关方需求形式化的主要来源，这些需求通过表达式体现（例如规则或合同，要求在情况Y下执行行为X，或防止在Y下发生 X）。运行设计域的构建（结构）和定义（内容）在我们的定义中，以及对系统所涉及当前情况的理解中，都发挥着重要作用。最后，还表示了与前述活动交互的额外活动，以解决非功能关注点和要使用的策略。

图5:[运行参与者接口框图]能力：“执行动态驾驶任务”

为了更详细地定义每个能力（运行能力）的活动和各自的交互，Capella提供了创建运行分析交互空白图（OAIB）的功能。图4和图5是OAIB图，分别表示“在给定运行设计域（ODD）中运行”和“执行动态驾驶任务”的能力。

系统分析：下一级别的作用是识别系统所需的不同功能或系统服务，并使用可能的非功能属性约束对其进行规范。首先，我们从将系统定义为黑盒开始，并创建实现上一级别运行活动的功能。图6是我们识别出的父功能的综合视图：执行驾驶自动化、访问ADCC资源（第1层）、使用特定自适应回路监督它们（第2层）、执行运行时自适应以适应运行设计域和安全关注点（第3层）、将这些信息存储在知识库（KB）中以供可能的更新或学习，以及最后显示一些系统内部信息。在这一步，我们已经就设计以及如何构建和组织控制回路做出了一些选择。图7进一步详细说明了架构的设计选择，引入了带有外部知识库和面向服务的MAPE-K回路。

图6:[系统架构框图]顶层系统总览

图7：[系统架构框图]集成了作为功能类型的MAPE-K循环的高层系统总览

逻辑架构和物理架构的下一级别将在文章后续发布的内容中结合框架的实现进行介绍。它们负责整合白盒分析和分配管理，这些内容将在下一章中介绍我们的设计选择和机制。

我们已经提出并实践了一种方法，将自动驾驶架构与安全需求建模为与自动驾驶功能分离的视图。这些需求既影响系统的设计，也影响系统的运行。当一个需求被集成到当前设计中时，其他作为要监控和控制的约束的安全需求仍然存在。

潜在解决方案的依据

这种方法带来了新的需求。

如何实现从功能视图到逻辑和物理架构的过渡？我们需要确定什么类型的架构解决方案能够支持系统内的安全管理回路和缓解措施。此外，我们还需要解决由自动驾驶上下文分析产生的约束的管理问题。确定不同的运行上下文需要对迭代和彻底的安全分析开放。最后，我们需要保证这些约束作为分布式自主流程被执行。

如何评估仍然属于行为层面的安全？因此，我们希望通过管理系统的复杂性来实现与设计时相同的安全性，包括可观测性、可追溯性和灵活性。仅通过调整配置文件或参数可能无法解决问题：需要在系统或子系统的任何自适应级别提供保证。

逻辑视图和物理视图中的潜在技术解决方案

使用抽象处理运行设计域和场景组合：为了降低复杂性，我们建议首先使用抽象在运行设计域中设计层次结构，以包含某些行为。

同样，我们希望将特定情况视为可以叠加的简单情况的集合。因此，我们提出并描述了一小组简单的基本情况，所有更复杂的情况都可以从这些基本情况中获得。

我们建议将道路上其他“物体”——特别是其他车辆——的处理提升到与本车意图同等的水平。使用“车道”概念来表示本车的预期路径，实际遇到的几何形状被降级到第二级，但层次结构的所有其他元素都保持不变。

自管理自主层：该框架在系统的两个规模上执行自主回路，以提供自反性和可演进性。

一层提供由已部署服务能力的安全属性保证驱动的行为自适应回路。通过这种方式，它直接感知并作用于被管理资源（传感器和执行器），在运行时保证属性的满足。

还有一层结构自适应机制，专门用来统筹调度已部署的各项服务，以及待验证的系统属性。系统运行时，这一层会对前文提到的第一层控制回路做统一编排，以此实现系统能力的最优组合，同时在当前运行场景下保障相关属性达标。整个系统在运行过程中，始终由这些自主回路持续调度编排，来匹配最合适的服务组合，确保系统在对应场景下的运行行为安全可控。

能力的上下文相关语义模型：这套新增的自管理自主层，是以三个知识库作为本体模型来驱动运行的。第一个知识库梳理了安全需求、系统能力与系统组件之间的关联关系；第二个负责描述运行场景，覆盖车辆可能遇到的各类用例、工况、边缘案例，以及这些情况的不同组合；最后一个知识库则用半形式化的方式，明确了系统组件和其适用场景之间的依赖关系。按照当前的行业实践，这些知识库会纳入从行为安全推导而来的安全需求规范，同时把系统能力拆解为对应特定场景的服务，再分配到对应的运行设计域当中。

面向微服务的架构风格：这套参考架构采用微服务的设计思路，能为组件服务和知识库提供灵活的运行环境，方便管控它们的动态特性。这些组件服务只实现和自身核心职责紧密相关的功能，支持独立部署，互相之间通过消息进行交互。这样一来，微服务的应用降低了组合门槛，让系统运行时的编排调度更容易落地。把自动驾驶汽车原本以任务为核心的系统架构，转向以能力为驱动的细粒度架构，不仅能带来更强的可扩展性，也有助于优化整体工程开发效率。这里提到的可扩展性，主要受几个因素影响：服务与能力同场景依赖关系的规模和复杂度、服务组件的数量，以及这些知识库在概念设计阶段的可管理难度。

在这一部分，我们探讨了借助基于模型的系统工程（MBSE）来研究和搭建 L4-L5 级自动驾驶汽车的方法，将核心功能与安全考量同时纳入设计阶段和运行阶段的风险应对方案。我们始终围绕支撑自主运行的核心功能展开讨论 —— 各类技术和技术方案不能凌驾于这些功能之上，这样才能把系统复杂度控制在可管理的范围内，同时保障足够的安全覆盖度（包括质量和数量两个层面），也能兼顾各项非功能属性。这种思路也方便我们在架构的不同备选方案、组合方式、变体版本和实现路径之间做权衡取舍。但即便如此，目前我们距离形成一套严谨成熟的设计流程，还有很长的路要走。

总而言之，文中提出的这套自主系统计算模型，可以为基于模型的自主系统设计研究打下基础。但客观来说，我们目前还远远不具备搭建出严谨设计流程的条件。

在该系列文的后续“第二部分”中，我们将提出将自安全概念融入现有自动驾驶汽车的参考架构。详细阐述该架构如何满足已识别的安全管理系统对可重构性、灵活性、可追溯性和可观测性的需求。请持续关注“猿力部落”公众号后续发布的该系列文章后续篇章。

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