自动驾驶系统安全的软件架构设计（上）

3.4. 车辆建模

本节介绍了根据架构对自动驾驶汽车的实现。为车辆建模时，了解车辆集成的所有不同传感器模块以及这些传感器交换的信息至关重要。

APS功能的实现在模拟环境中进行，具体是在CARLA模拟器中。CARLA是一个开源的自动驾驶模拟器。在这个模拟环境中，CARLA车辆是配置系统的硬件。出于实际考虑，采用逆向工程来确定车辆的配置，以便在集成时所有传感器类型都可用。

在CARLA模拟器中，与自动泊车系统相关且可用的传感器有：（i）摄像头传感器，（ii）GNSS传感器，（iii）IMU传感器，（iv）激光雷达传感器，（v）雷达传感器和（vi）语义激光雷达传感器。此外，由于是模拟环境，可以根据需要使用任意数量的传感器，只需在CARLA模拟器的World实例中进行定义即可。

为了尽可能真实地对车辆进行建模，分析了当前自动驾驶汽车中使用的传感器数量和类型。车辆实现所选择的配置如图15所示。

图15.为车辆硬件建模定位传感器模块

AUTOSAR对大多数常用传感器类型进行了标准化，这样汽车制造商和供应商可以方便地使用传感器，而无需对每个传感器进行单独建模，这也是该标准的目标之一，以便大家最终使用相同的模块。在分析了CARLA模拟器提供的传感器模块的API后，发现它们与AUTOSAR接口不兼容。因此，将CARLA传感器模块的所有API建模为AUTOSAR接口，使架构与用于集成的模拟环境兼容。

对CARLA中使用的传感器接口进行建模，有助于未来开发人员将AUTOSAR架构集成到CARLA模拟器中。以下各节定义了每个传感器模块，以便清楚了解其交换的数据类型。这些定义基于CARLA模拟器提供的信息。

3.4.1. 雷达传感器

雷达传感器是将微波回波信号转换为电信号的设备。与其他传感器不同，雷达传感器不受光照和黑暗的影响，并且能够检测到玻璃等障碍物，它可以“穿透”墙壁，也不受天气条件的影响。雷达传感器相对于其他传感器的最大优势之一，是能够检测周围物体的运动和速度。

为了能够感知车辆周围的所有物体，至少需要在车辆的每个边缘安装一个以上的雷达传感器。为了确保检测到车辆侧面的物体，决定在每一侧安装一个传感器。图15显示了每个传感器模块的确切位置：两个在前面，两个在中间，两个在后面。

CARLA模拟器中使用的传感器模块有四个实例化变量，如表15所示，其中定义了变量、单位和类型。

表15.CARLA模拟器中定义的雷达模块的实例变量

3.4.2. 摄像头传感器

摄像头传感器模块使车辆能够以高分辨率观察，并识别车辆配备的雷达传感器检测到的所有物体。需要注意的是，摄像头并非在所有天气条件下都能有效工作，与雷达和激光雷达不同，后者提供易于分析的数值数据，而摄像头技术需要更复杂的计算来分析图像，以理解环境和所看到的物体。

摄像头的视角非常宽广，可达120度。与其他传感器不同，这使得仅在车辆前后各安装一个摄像头，就能够捕捉和识别车辆周围的大多数组件。

摄像头传感器模块有四个实例变量和两个定义的方法，这些方法作为带参数的函数使用。表16显示了摄像头模块提供的实例变量。

表16.CARLA模拟器中定义的摄像头模块的实例变量

定义这些方法是因为该模块需要车辆的信息，以提供所需类型和格式的数据。该模块需要以下方法：

第一个方法名为Convert，它根据颜色转换模式（colour_converter）对图像进行转换，参数是CARLA模拟器中定义的颜色转换模式。

第二个方法名为save_to_disk，它使用指定的颜色转换模式将获取的图像保存到指定路径，参数是包含图像的路径（字符串）和颜色转换模式。

3.4.3. 激光雷达传感器

LIDAR代表“光探测与测量”，它能够识别周围的物体，因为它可以测量物体的形状、大小和距离。该模块使用激光脉冲扫描环境，与雷达使用的无线电波不同。具体来说，激光雷达模块发射数百万个激光信号，这些信号在周围物体表面反射后，返回模块上的接收器。利用获得的信息，激光雷达能够创建车辆周围环境的3D模型。

激光雷达能够比雷达以更高的分辨率识别物体。然而，对于原始设备制造商（OEM）来说，它是最昂贵的选择。此外，它受天气条件的限制。在雾、雨和降雪等恶劣天气条件下，该模块的性能往往会下降。

依赖激光雷达的自动驾驶汽车应能够实时评估其局限性，并在这种情况下发出警报，以确保安全。目前，为实现自动驾驶系统而开发的车辆，通常在车顶上配备一个大型的360度激光雷达传感器，以提供周围环境的完整视野。因此，决定为车辆模型配备一个激光雷达传感器。

激光雷达传感器模块有六个实例变量和一个定义的方法。表17显示了该模块所需的接口。

激光雷达模块正常工作仅需要一个方法，与摄像头传感器的save_to_disk方法相同。

表17.CARLA模拟器LIDAR模块的实例变量

3.4.4. 语义激光雷达传感器

该传感器模块模拟了一个使用光线投射实现的旋转激光雷达，它会暴露光线击中的所有信息。其行为与激光雷达传感器类似，但它们之间也存在一些差异。语义激光雷达模块在原始数据的每个点上包含更多数据，并且不包含强度、衰减或噪声模型属性。表18显示了语义激光雷达模块的实例化变量。

表18.CARLA模拟器语义激光雷达模块的实例变量

语义激光雷达所需的方法与激光雷达传感器相同，即save_to_disk。该方法的定义可在上一节中找到。与激光雷达一样，决定在车辆建模中仅使用一个语义激光雷达单元。

3.4.5. GNSS传感器

GNSS代表全球导航卫星系统，它能够以自主方式提供全球覆盖的地理空间定位。该模块使用三角测量法，通过计算车辆与多个卫星之间的距离，来确定接收器在三维空间中的位置。

在车辆中安装单个传感器，就足以在模拟和现实生活中获得有效且准确的信息。天气条件对这些GNSS模块的影响极小，因为它们的工作频率约为1.575GHz，这个工作频率对天气条件相对不敏感。然而，挡风玻璃刮水器可能会干扰信号接收，使GNSS设备无法识别来自卫星的完整导航数据字符串，从而导致数据不准确。

CARLA模拟器中使用的GNSS传感器模块有三个实例化变量，如表19所示。

表19.CARLA模拟器中定义的GNSS模块的实例变量

3.4.6. IMU传感器

IMU代表惯性测量单元，由两个传感器组成：加速度计和陀螺仪。加速度计测量车辆的三个线性加速度分量，而陀螺仪测量车辆的三个旋转速率分量。结合GNSS传感器提供的车辆初始位置信息，IMU可以提供车辆当前的位置和方向信息。

与GNSS传感器一样，单个IMU传感器就足以获取车辆的正确方向。尽管实际车辆可能会安装多个IMU传感器以确保数据冗余。该传感器完全不受外部条件的影响，因为它仅取决于车辆的相对运动。

CARLA模拟器中使用的IMU传感器模块有3个实例化变量，如表20所示。vector3D是CARLA模拟器中定义的一个辅助类，用于简化3D操作，定义的实例变量X、Y和Z代表向量每个轴的值。

表20.CARLA模拟器中定义的IMU模块的实例变量

3.5. AUTOSAR中的架构模型

本系列文设计的架构已在AUTOSAR中进行建模，配置用于虚拟集成，并使用C代码实现。专业公司提供了用于此目的的商业产品。本项目使用了ETAS GmbH提供的工具，通过RTA-CAR解决方案为设计的架构生成AUTOSAR运行时环境（RTE）。

RTA-CAR提供了集成环境，用于配置和生成适用于ECU的经典AUTOSAR堆栈。该程序主要关注4个基本概念：（i）应用层的配置，（ii）运行时环境（RTE）的配置和生成，（iii）基础软件层（BSW）的配置和生成，（iv）操作系统（OS）的配置和生成。RTA-CAR针对每个关注的任务都有特定的工具，如表21所述。

表21.ETAS工具说明

设计的架构使用ISOLAR-A工具进行建模。下面详细介绍在ISOLAR-A软件中，按照AUTOSAR标准逐步对架构进行建模的方法。

3.5.1. 车辆配置

首先，需要将架构中的元素建模为软件组件类型，这包括该系列文“上”篇的3.3节中讨论的不同架构组件以及3.4节中讨论的传感器模块。

然后，定义一个配置车辆的组合，并在我们的项目中将其命名为虚拟车辆。3.4节中定义的车辆模型中指定的所有传感器，都作为组件原型插入到这个组合中。组件原型是先前创建的组件类型的实例。当一个组件被多次实例化（如雷达或摄像头）时，其实例名称将被赋予不同的标签，但仍与相同的组件类型相关，如表22所示。

表22.重复组件原型的定义

图16.预览已定义部件的虚拟车辆组合

组件通过端口进行通信，端口由所谓的接口进行类型定义。3.4节中已经定义了要使用的传感器接口，这些接口源自CARLA模拟器的API。

雷达、IMU和其他仅通过变量传输数据的传感器，将使用发送-接收接口进行建模；而像摄像头和激光雷达这类需要向方法传递参数的传感器，则需要两个接口：一个客户端-服务器接口和一个发送-接收接口。

图17展示了摄像头接口建模的示例。变量在发送-接收接口中定义，方法调用在客户端-服务器接口中定义，并详细列出了所有必要信息。变量的单位和其他一些特性，使用SwDataDefProps（软件数据定义属性）进行定义。

图17.架构的组件和模式接口

在为每个模式组定义模式接口之前，需要在项目基础设施中指定每个组的各种模式。模式切换接口类型是必需的，它与其他接口不同，如图17所示。

组件类型通过端口与其他组件进行通信，端口分为两种类型：所需端口和提供端口。每个提供端口连接到相同接口类型的所需端口。完成连接后，虚拟车辆的组合如图18所示。

图18.具有所有连接的虚拟车辆的架构组成

为了使用AUTOSAR运行时环境实现虚拟车辆的通信，可以由RTA-RTE自动生成相关代码。RTE生成器需要一个完全配置好的ECU实例，以及将组件可运行程序映射到操作系统任务的信息。ISOLAR-A提供了生成适配器的功能，用于配置系统以生成RTE。

生成的适配器创建了一个名为CPT_Adapt_VirtualVehicle_Appl的新组件。这个组件包含模型中所有未使用的实例化组件，并生成其余所需的连接，如图18所示。

现在架构已经建模完成，可以定义软件组件类型的内部行为，即可运行程序。以下各节概述了为每个组件定义的可运行程序。

3.5.2. 感知

感知组件本身不作为一个建模组件存在，它代表所有指定的传感器模块。每个传感器为其模块提供一个具有特定接口的端口。需要方法调用的传感器模块，必须提供两个端口，一个用作发送-接收接口，另一个用作服务器接口，如图19所示。

图19.为传感器模块（Perception组件）提供端口

CARLA模拟器中传感器模块生成的数据，必须通过提供的端口进行传输。

3.5.3. 定位

感知组件提供的所有端口都应连接到定位组件，这意味着上述每个提供端口都有其相应定义的所需端口。图20展示了定位组件的最终配置。

图20.本地化组件的端口和可运行配置

定位组件需要一个可运行程序来识别周围元素，该程序名为GetSorrounderObjects，并指定为100毫秒定时事件（TEV 100 ms）。这个可运行程序应能够利用传感器模块提供的信息，识别车辆周围是否存在障碍物。

在车辆的四个边缘，该可运行程序会指示是否有障碍物。因此，应定义四个提供端口（两个在前面，两个在后面），每个边缘一个。通过定义的端口接口，必须提供障碍物距离的值。

3.5.4. 行驶规划

该组件的所需端口，是定位组件提供的端口以及来自ADS模式管理器的选定模式。利用这些信息，行驶规划组件负责选择应执行五个功能中的哪一个。

对于每个操作，都需要一个可运行程序。为简单起见，假设我们的系统将以100毫秒的周期调用代码，这些可运行程序将由100毫秒的定时事件触发。

模式管理在可运行程序级别进行指定，更确切地说，对于启动可运行程序的每个定时事件，都要根据该系列文“上”篇的3.3.6.2节中定义的映射选择应禁用的模式。因此，根据选定的模式，将激活单个功能。

行驶规划组件需要一个提供端口，将选定运行功能的数据发送到AS运动组件。配置的接口有五个布尔变量，每个变量指示一个运行功能何时被激活。图21展示了行驶规划组件的最终配置。

图21.驱动器规划组件的端口和可运行配置

3.5.5. AS运动

AS运动组件在模拟环境中实现期望的运动。行驶规划组件提供要应用的运行功能。

为了设置计划的运动，必须定义一个可运行程序（指定为100毫秒定时事件），它负责将信息发送到CARLA模拟器。

对于这个简化模型，由于CARLA模拟器实现了车辆运动，因此不需要提供端口。图22展示了驱动规划组件的配置。

图22.AS运动组件的端口和可运行配置

3.5.6. ODD处理

ODD处理组件应与CARLA模拟器进行通信，以获取有关环境的所有信息。用于确定车辆倾斜度的IMU传感器模块，是该组件唯一需要的提供端口。

指定一个可运行程序（由100毫秒定时事件调用）来获取该系列文“上”篇的3.3.5节中定义的所有ODD。为了保持数据类型与CARLA中生成的一致，定义了以下四个提供端口：（i）环境对象，（ii）灯光状态，（iii）天气，（iv）ES（外部云服务），（v）初始化。

ECS和初始化包含正确模拟所需的必要变量。由于ECS不在本项目范围内且未进行编程，在CARLA模拟器中开发的APS中集成了对它的模拟。即当APS要被激活时，模拟环境会生成本应从外部云服务流入的值。图23展示了ODD处理组件的配置。

图23.ODD处理组件的端口和可运行配置

3.5.7. ADS模式管理器

ODD处理组件提供的所有用于识别系统环境的端口，对模式管理器来说都是必需的。此外，还需要ECS提供的数据，这些数据已在模拟环境中进行了模拟。

需要一个可运行程序（由100毫秒定时事件调用）来实现该系列文“上”篇的3.3.6 节中描述的状态机。模式管理器负责根据获取的信息，为每个组选择正确的模式。

定义了三个提供端口，将选定的模式发送到其他组件，每个端口对应一个模式组。图24展示了驱动规划组件的最终配置。可运行程序SetCurrentModes是手动编码的，用于实现状态机。

图24.ADS模式管理器的端口和可运行配置

04. 结果

本节旨在展示所建架构及其与自动泊车系统顺利集成的成果。要在硬件上运行所建架构，必须生成实现应用层与基础软件服务之间通信的运行时环境（RTE）。

相关概念在虚拟环境中得到验证，即代码在个人计算机上运行。生成的AUTOSAR运行时环境与模拟环境以及CARLA模拟器实现的自动驾驶汽车进行了集成。

4.1. 运行时环境

ISOLAR-A是用于对软件架构进行建模的AUTOSAR创作工具，它集成了多个工具，如用于生成AUTOSAR运行时环境（RTE）的RTA-RTE。本项目开发过程中，RTE的规范和要求遵循相关文献定义。

RTE生成器实现了用于设置/获取数据的标准化API，并为数据层分配内存。生成的RTE文件如图25所示。

图25.为建模架构生成的RTE文件

这些文件有以下几种格式：（i）ARXML文件，（ii）C头文件和源文件，（iii）LST文件，（iv）XML文件和（v）C源文件。C源文件最为关键，因为它们实现了通信以及可运行程序的执行顺序。

OsTask_100ms.c文件非常重要，因为它根据RTE事件到任务的映射指定了可运行程序的执行顺序。该文件定义了一个100毫秒的重复任务。可运行程序的执行顺序必须符合逻辑，确保在下一步执行之前，所有必要信息都已准备好。这个顺序在ISOLAR-A中的部署和RTE配置过程中进行定义。

以下代码展示了架构中指定的每个可运行程序的执行顺序。首先，系统对车辆及其周围环境进行定位；其次，收集指定ODD的数据；然后，使用接收到的所有数据更新模式组；接着，根据该系列文“上”篇的3.3.6.2节中描述的映射执行五个定义函数之一；最后，执行所选函数指定的运动。OsTask_100ms.c代码如下所示。

Rte.c文件也很重要，它列出了所有可用于读写架构中定义的内部变量的API。RTE仅为每个可运行程序中定义为DataReceivePoints和DataSendPoints的变量生成API。以下展示了降水变量的API：一个API用于在ODD处理组件中写入数据，另一个API用于为模式管理器读取该值。

模式声明组与常规变量不同，因为它们被指定为模式切换接口。可以定义用于读取当前模式（ModeAccesPoints）和切换模式组（ModeSwitchPoints）的相关内容，具体定义方式取决于需求。以下展示了APS模式组的API。

所有由RTE生成器自动生成的文件都不应被编辑。除了这些文件，ISOLAR-A还提供了为每个定义了可运行程序的组件创建组件代码框架的选项，如图26所示。这些文件包含应根据Os_Task_100ms.c执行的可运行程序，需要对其进行编辑，以使设计的架构适应实际实现。在本文中，对AS_ModeManager、DrivePlanning、ODD Handling和VehicleMotion这些文件进行了编辑。

图26.生成的代码帧组件

可运行程序的实现非常简单，下面描述其与CARLA提供的功能之间的交互。

添加到Get_ODD_Context可运行程序（来自ODD Handling代码框架）中的代码片段，将来自CARLA模拟器的所有数据进行分离，并使用Rte.c生成的写入API将其写入每个相关变量。这些信息本应从传感器中提取，但为简化实现过程，直接从CARLA模拟器获取。这些信息以逗号分隔。

添加到SetCurrentModes可运行程序（来自AS Mode Manager代码框架）中的额外代码，用于读取所有必要变量，并实现该系列文“上”篇的3.3.6.4节中定义的状态机。

对于Drive Planning，在五个可运行程序中的每个程序里插入的代码片段，是将与相应运行功能相关的布尔变量设置为true。为确保只有一个功能被激活，将与其他操作相关的变量设置为false。

最后，添加到Set_VehicleMotion可运行程序（来自Vehicle Motion代码框架）中的代码，从Drive Planning读取数据，以确定要激活的操作，并将该信息发送到CARLA模拟器。

为了执行RTE中的指定任务，除了ISOLAR程序已生成的所有文件外，还必须创建一个包含无限循环的新文件，目前仅定义了Os_Task_100ms。此文件的目的是在每个循环中调用要执行的指定任务，该文件名为Server.c（见4.2节）。

4.2. 集成环境

为确保运行时环境与车辆（模拟环境）之间的通信，必须建立虚拟通信协议。RTE使用C编程语言编写，而模拟环境使用Python语言，因此通信协议必须与这两种开发代码兼容。为此，采用传输控制协议（TCP）套接字进行通信。

TCP套接字由计算机的IP地址和使用的端口定义。由于RTE和CARLA模拟器在同一台计算机上运行，因此使用的IP地址是本地主机（127.0.0.1）。端口号选择4455，因为它是TCP常用端口之一。

TCP套接字通常被两种类型的应用程序使用：服务器和客户端。TCP服务器通过监听知名端口（或IP地址和端口对）接受TCP客户端的连接。为了与TCP服务器建立连接，TCP客户端必须向服务器发送连接请求。在APS的实现中，RTE被视为服务器，模拟环境被视为客户端，如图27所示。

图27.TCP套接字通信协议

为执行RTE任务而创建的额外文件被视为APS的服务器，因此命名为Server.c。在无限循环之前，该文件开始监听指定端口，查看是否有客户端请求建立连接。一旦客户端发送连接请求，服务器接受请求，然后执行无限循环以调用Os_Task_100ms。

RTE任务指定了数据流向。服务器在向模拟器提供运行功能之前获取环境信息，因此客户端先提供数据，服务器再进行响应。

如前所述，客户端编码（五个运行功能）不在本系列文范围内。

在ODD Handling代码框架的Get_ODD_Context可运行程序中，编写了接收客户端发送数据的代码。在Vehicle Motion代码框架的Set_VehicleMotion可运行程序中，编写了将选定运行信息发送给客户端的代码。服务器发送一个0到4之间的数字，每个数字对应一个运行功能，如表23所示。

表23.TCP的功能操作编码

4.3. 开发的原型（MVP）

在模拟环境中，将架构与APS完全集成后，得到了一个原型。通过包含足够的功能来吸引早期客户并评估产品理念，整个系统成为了一个最小可行产品（MVP）。

为了简化对数据流的理解，用顺序图表示了MVP的整体概念。图28所示的顺序图不仅展示了架构本身的整个数据流，还展示了它如何通过TCP套接字与CARLA模拟器相关联。通过图28中的顺序图，可以直观地理解该系列文“上”篇的第3节中讨论的所有内容。

图28.集成到架构中的APS的通用序列图

图28顶部突出显示的组件，指的是模拟器（CARLA车辆）和 该系列文“上”篇的3.3 节中定义的架构组件（定位、ODD处理、ADS模式管理器、行驶规划和车辆运动）。

该图展示了传输数据的接口名称，随后用实际传输的详细信息指示了不同的场景。图中的虚线表示通过TCP套接字连接传输的数据。

在开发过程中遇到了一个技术问题，即双方的时钟频率。由于RTE与模拟环境之间的通信必须同步，RTE的运行时钟频率为100毫秒，而模拟环境要求的时钟频率为5毫秒。任何一方都不能违反频率要求，否则会出现异常状态。为解决这一不一致问题，在模拟环境的无限循环中，每20次才调用一次与架构的TCP通信。

下面通过顺序图展示一些案例，以演示产品应有的实际数据流，以及在不同场景下的行为，目的是验证MVP。

图29展示了激活PM_Forward函数所需的数据传输。该图显示天气条件适宜（晴天）且未检测到障碍物，因此可以在不影响安全的情况下执行该运行。

图29.PM_Forward操纵激活的详细顺序图

MVP必须对环境变化做出反应，并验证在新的ODD下指定模式是否仍然可运行，以确保安全性。在上述案例中，在选定的泊车运行过程中，如果突然遭遇暴风雨，伴有大风、降雨和地面积水，系统将切换到APS_SafeMode并执行安全模式功能，因为之前选择的APS模式在新条件下无法运行。

此外，如果在车辆前方（F_L和F_R位置）检测到障碍物，这也是将系统降级到安全模式的另一个原因。定位组件的障碍物检测功能，通过以下变量（F_L（左前方）、F_R、M_R（右中间）、M_L、R_R（右后方）和R_L），将检测到的障碍物位置信息通知给行驶规划组件。图30展示了这种情况下传输的数据流。

图30.激活安全模式的详细顺序图

为了便于理解上述顺序图中的数据流，对系统进行了简化，一些细节（如周围物体）未被考虑。

MVP应使用上述示例进行测试，并且必须确保在任何环境下的安全性。如该系列文“上”篇的3.3.6.3 节中所定义，当无法保证安全时，系统应切换到安全模式，如图30所示。

05. 结论

随着汽车行业向自动驾驶系统转型，此类系统的架构必须适应新的挑战。本系列文全面概述了当前适用于自主系统安全的标准，评估了不同的软件架构标准化方案，并深入分析了AUTOSAR标准——这一在汽车行业广泛应用的参考软件架构，并将其应用于本研究的开发过程中。

为了融合成熟技术与新技术，本研究结合了基于AUTOSAR建模的架构，以及在CARLA模拟器中实现的自动驾驶功能。与仍在开发中的CARLA模拟器不同，AUTOSAR是一个完全成熟的行业标准。

本研究实现的用例，是一个基于《道路车辆-自动驾驶系统的安全与网络安全-设计、验证和确认》（ISO/TR 4804，2020）中提出的指导方针，在自动泊车系统（APS）中实例化的软件架构。然而，该架构具有通用性，能够支持自动驾驶汽车功能的逐步开发。通过调整系统需求，可以添加更多的自动驾驶功能。

本项目的主要贡献在于，探索了AUTOSAR模式管理方法在自主系统（AS）模式管理器组件设计中的适用性。为此，我们将系统简化为描述泊车操作如何通过在配置模式之间切换以适应环境、确保系统安全所需的最少组件数量。

尽管如此，由于所开发的系统具有明确的逻辑架构，因此具有可扩展性。这使得向系统添加新功能更加容易，并且只需进行最少的代码开发。

本系列文展示的结果表明，实施一个明确定义的架构，能够在满足严格安全需求的同时，结合先进的模拟环境，显著降低自动驾驶系统编程的复杂性。

5.1. 未来工作

开发基于AUTOSAR的基本自动驾驶系统安全架构这一目标已达成。当前的工作是为最小自主系统架构奠定基础的第一步。然而，仍有改进和扩展的空间。

在汽车行业中，AUTOSAR经典平台和自适应平台将共存。目前尚不清楚像机器人操作系统（ROS2）这样的其他面向服务的架构是否会被采用。尽管机器人架构具有巨大潜力，但汽车软件工程师似乎常常忽视它。未来的一项工作是，将机器人标准化架构与我们的AUTOSAR架构进行比较评估，以确定哪些特性能够改进我们的工作成果。

AUTOSAR方法在很大程度上依赖于配置和代码生成。在本研究中，实现ADS模式管理器的状态机是手动编码的。我们认为AUTOSAR基础软件模式管理器具备配置ADS模式管理器的能力。如果是这样，状态机的实现可以自动生成，并作为ECU配置的一部分进行集成。

在本研究中，虚拟车辆的架构是通过对CARLA模拟车辆（由多个传感器模块组成）进行逆向工程得到的。未来的工作可以是，从作为AUTOSAR顶层组合建模的虚拟车辆架构生成CARLA车辆的Python代码。还应探索需要哪些元数据，例如，用于描述传感器在物理模拟车辆中的位置。