电子电气架构---智能计算架构和SOA应用

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。

时间不知不觉中，快要来到深秋。国庆假期结束，又开始新的忙碌。成年人的我也不知道去哪里渡自己的灵魂，独自敲击一些文字算是对这段时间做一个记录。

一、车载智能计算基础平台参考架构

车载计算基础平台侧重于系统可靠、运行实时、分布弹性、高算力等特点，实现感知、规划、控制、网联、云控等功能，最终完成安全、实时、可扩展的多等级自动驾驶核心功能。如图所示，车载计算平台的总体架构主要包含车控操作系统和异构分布硬件架构两部分。其中，运行于车载智能计算基础平台硬件及汽车电子控制单元硬件之上，支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合，架构上包括系统软件和功能软件。

车载计算平台的总体架构

车载计算平台的总体架构确实主要包含两大部分：车控操作系统和异构分布硬件架构。这两部分紧密协作，共同支持智能网联汽车的各项功能。

1. 异构分布硬件架构

异构分布硬件架构是车载计算平台的基础，它通常由多种不同类型的硬件组件组成，包括但不限于：

-> 高性能处理器：用于处理复杂的计算任务，如图像识别、路径规划等。

-> 专用集成电路（ASIC）：针对特定任务进行优化，如深度学习加速、传感器数据处理等。

-> 现场可编程门阵列（FPGA）：提供灵活的硬件配置，可根据需求进行编程和重构。

-> 通信模块：支持车辆与外部环境（如V2X通信）、云服务器和其他车辆之间的数据传输。

-> 存储设备：用于存储操作系统、应用程序、数据日志等。

这些硬件组件通过高速总线或网络相互连接，形成一个分布式计算系统，能够高效地处理各种任务。

2. 车控操作系统

车控操作系统是运行在硬件之上的软件层，它负责管理和协调硬件资源，为上层应用提供稳定、可靠的运行环境。车控操作系统通常具有以下特点：

-> 高可靠性：采用冗余设计、故障检测和恢复机制等，确保系统在出现故障时仍能正常运行。

-> 实时性：能够及时处理关键任务，确保自动驾驶的实时响应。

-> 安全性：通过安全认证、数据加密、访问控制等手段，保护系统免受恶意攻击和数据泄露。

-> 可扩展性：支持新功能的添加和旧功能的升级，以适应不断变化的自动驾驶需求。

车控操作系统的架构上通常包括系统软件和功能软件两部分：

-> 系统软件：包括内核、设备驱动程序、网络通信协议栈等，为上层应用提供基本的系统服务。

-> 功能软件：包括感知、规划、控制、网联、云控等自动驾驶相关的功能模块，这些模块通过调用系统服务来实现自动驾驶的各项功能。

实现的核心功能

车载计算平台通过上述架构和组件，实现了以下核心功能：

-> 感知：通过摄像头、雷达、激光雷达等传感器收集周围环境的信息。

-> 规划：根据感知信息生成安全的行驶路径和速度规划。

-> 控制：根据规划结果控制车辆的转向、加速和制动等。

-> 网联：与外部环境（如交通信号灯、其他车辆）进行通信，获取更多信息以优化行驶策略。

-> 云控：与云服务器进行数据传输和交互，实现远程监控、更新和故障诊断等功能。

这些功能的实现使得智能网联汽车能够安全、实时、可扩展地实现多等级自动驾驶。

图 1 车载智能计算基础平台架构框图

二、系统软件层

系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境，如图所示。系统软件一般包含操作系统内核、虚拟化管理（Hypervisor）、POSIX、系统中间件及服务等。

图 2 系统软件架构

1、操作系统内核

车控操作系统内核支持异构芯片，需考虑功能安全、实时性能要求。当前异构分布硬件架构各单元所加载的内核系统功能安全等级有所不同，AI 单元内核系统 QM_{ASILB，计算单元内核系统QM}ASILD，控制单元内核系统 ASILD，因而出现不同安全等级的多内核设计或单内核支持不同安全等级应用的设计。保证差异化功能安全要求的同时满足性能要求，是车控操作系统系统软件设计的关键。另外，车载智能计算基础平台的复杂性也要求内核对功能软件及应用软件的库支持和高度可编程性。

2 虚拟化管理（Hypervisor）

Hypervisor技术是实现跨平台应用、提高硬件利用率的重要途径。Hypervisor 是一种硬件虚拟化技术，管理并虚拟化硬件资源（如CPU、内存和外围设备等）并提供给运行在 Hypervisor 之上的多个内核系统。车控操作系统通过 Hypervisor 实现有效的资源整合和隔离。

3 可移植操作系统接口（POSIX）

POSIX 是被主流操作系统广泛采用和遵守的标准。基于 POSIX的应用可以方便在不同操作系统间移植。POSIX 也能够很好地适应自动驾驶所需要的高性能计算和高带宽通编程。Adaptive AUTOSAR同样采用基于 POSIX 标准的内核系统，可使用 PSE51 子集的标准POSIX API，旨在满足未来高级自动驾驶的需求。车控操作系统系统软件基于实时嵌入式软件单元架构，可借鉴 Adaptive AUTOSAR平台思路，在不同内核系统采用 POSIX API 与应用软件、功能软件交互。

4 系统中间件及服务

系统中间件位于系统软件中，主要是管理计算资源和网络通讯，并为上层应用提供基础的系统服务。其中最主要的中间件是指分布式通信服务，它主要是以发布/订阅方式为 SOA 应用之间提供数据和信息交换服务。车控操作系统可建立跨多内核、多 CPU、多板的通用、高速、高效的通讯和数据共享机制。采用发布/订阅架构的分布式中间间，强调以数据为中心，提供丰富的 QoS 策略，能保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。其中有代表性的分布式通信中间件技术规范为 DDS、SOME/IP等。

5 安全域操作系统及功能服务

安全域操作系统是系统软件层上运行在 MCU 上的实时安全车控操作系统。安全域操作系统主要包含硬件抽象层、基础软件、实时操作系统内核和运行时环境等模块。安全域操作系统最基本的要求是高实时性。系统具备硬实时特性，需要在规定时间内完成资源分配、任务并发、同步等指定动作，可参考 CP 软件架构。

三、功能软件层

功能软件是车控操作系统根据面向服务的架构设计理念，通过提取智能驾驶核心共性需求，形成智能驾驶各共性服务功能模块，高效实现驾驶自动化功能开发的软件模块。如图 12 所示，功能软件由应用软件接口、智能驾驶通用模型、功能软件通用框架，以及数据抽象组成。

图 3 功能软件架构

1 应用软件接口

车辆应用建立在功能软件基础上，功能软件通过统一应用软件接口为应用软件提供调用和服务。应用软件的开发和运行可以不依赖具体传感器和车型。不同的市场参与方（包括政府主管机构、主机厂、供应商、高速路或停车场等交通设施管理者和个人）都可以开发应用。应用可以被打包、部署、启动、调度和升级。应用程序的功能可通过用户、路端以及云端来定义，并通过应用场景触发。借助功能软件层的支撑，应用程序的开发将向轻量化方向发展，越来越聚焦在业务逻辑本身所决定的规则制定上。

应用程序构建在更为抽象的环境模型、车辆模型、任务模型和资源模型之上，相比功能软件有更好的可移植性，能够跨车型、跨计算平台部署。和功能软件相比，应用程序更侧重于业务而不是功能，更偏向用户侧而不是系统侧，更关注目标而非方法。应用程序可以构建在功能软件所提供的服务上，也可以直接构建在环境和车辆模型上。

应用程序接口不仅涉及到应用程序的运行，还应涉及应用的开发和管理类接口。系统软件供应商应该为应用软件开发提供统一的开发环境和工具，可以体现给用户不同形式的 SDK，例如环境模型、功能配置、各种算法 SDK 以及包括应用开发所必要的工具链、软件包、开发接口、开发文档、示范应用和配置等。

2 智能驾驶通用模型

智能驾驶通用模型是对智能驾驶中智能认知、智能决策和智能控制等过程的模型化抽象。智能驾驶通用模型由环境模型、规划模型、以及控制模型组成。

环境模型作为智能认知框架，为智能决策和智能控制提供模型化的广义环境信息描述。环境模型调度各类感知、融合和定位算法，对传感器探测信息，车-路、车-车协同信息，以及高精地图先验信息进行处理加工，提供探测、特性、对象、态势、场景等各级语义的道路交通环境和自车状态信息。

规划模型根据环境模型、自车定位、个性化设置和自车状态反馈等信息，为自车提供未来一段时间内的行驶轨迹，主要分为行为预测、行为决策和运动规划三大部分。行为预测是根据感知和地图数据对其他交通参与者未来的行驶轨迹进行预测，为行为决策提供更全面、可靠的参考信息；行为决策为自车提供行为策略，同时为运动规划提供相应的规划约束条件，保证规划结果不仅满足交通法规等硬性要求，同时更加符合人的驾驶策略；运动规划根据以上信息，为自车规划未来一段时间内的安全、舒适、正确的轨迹。

控制模型主要由常规工况和降级工况组成，其中常规工况主要针对 ODD 以内的动态驾驶任务，降级工况主要针对发生系统性失效或者超出 ODD 以外的动态驾驶任务，均需要进行输入处理、状态决策、控制计算及执行输出等。针对上游及底盘信息的输入，以及控制输出均需要适配层去匹配不同的功能算法框架平台及车辆平台；针对横纵向及紧急控制等算法模块需要进行故障诊断、配置及标定接口模块统一管理。

3 功能软件通用框架

功能软件通用框架是承载智能驾驶通用模型的基础，分为数据流框架和基础服务两部分。

数据流框架向下封装不同的智能驾驶系统软件和中间件服务，向智能驾驶通用模型中的算法提供与底层系统软件解耦的算法框架。数据流框架的主要作用是对智能驾驶通用模型中的算法进行抽象、部署、驱动，解决跨域、跨平台部署和计算的问题。

基础服务是功能软件层共用的基本服务，其主要服务于智能驾驶通用模型或功能应用，但其本身不局限于智能驾驶。基础服务平台包含可靠冗余组件、信息安全服务、网联云控服务，其中可靠冗余组件将系统中其它所有软件和硬件模块都抽象为被管理实体，通过与所有被管理实体的交互，完成对整个系统的监测和故障处理；信息安全基础服务中的数据安全服务为车端数据定义了数据类型和安全等级，为车端功能和应用所需不同类型数据在不同车辆运行场景下制定安全策略和数据处理规则。数据流框架上的算法部署和数据流编排模块，按规则定义控制算法部署和数据交换。网联云控服务可提供操作系统的安全冗余信息、超视距信息和通用模型的信息，通过 LTE-V2X、4G/5G 的通讯方式，实现与车车通讯、车云通讯、车人通讯和车与路侧基础设施通讯。

4 数据抽象

数据抽象通过对传感器、执行器、自车状态、地图以及来自云端的接口等数据进行标准化处理，为上层的智能驾驶通用模型提供各种不同的数据源，进而建立异构硬件数据抽象，达到功能和应用开发与底层硬件的解耦。

02车载智能计算基础平台 SOA 核心架构

SOA 的设计思想是将应用程序分解为特定的功能组件或服务，并且独立于硬件、操作系统，通过标准化协议和应用程序接口（API）进行访问。这些服务设计应该可以被共享而不是受限于特定的硬件和车型。

与云相关的某些组件或服务在设计时应考虑可以运行在本地计算机（计算平台）或分布式联网计算机群（边缘云或中心云服务器）上，在应用和服务组件的设计中可远程访问并独立更新。

而计算平台底层系统和基础软件设计需要为上层服务和应用提供友好而且稳定的 SOA 基础架构。主要包括以下方面：

解耦：操作系统解耦硬件平台，底层软件独立于车型、操作系统以及编程语言。内核/POSIX/中间件独立于业务逻辑，数据源解耦传感器硬件设计。

分层：整个系统应该进行分层架构设计，对系统不同层次和各个基础服务组件间界定清晰的界面，尽量采工业界认同的接口和标准，兼容车辆传统的控制器和操作系统和协议。

模块化：将基础服务软件功能分解成不同类型的一个或多个独立功能，功能间相互独立，方便构建上层应用，如数据收集、数据回传、OTA、信息安全、网联云控。智驾功能的基础服务也可以进行分解，如状态机、模式管理器、算法模块、环境模型。

抽象：对不同的感知硬件实现共性数据抽象，既隔离上次算法模块又可以实现快捷硬件匹配。

标准化：接口和数据标准化。

（一）、软硬件解耦

软硬件解耦是在软件系统和应用设计上独立于硬件设计，通过构建一个通用的软件架构对硬设备接口进行抽象化处理，来兼容不同的硬件设备。

提供传感器抽象机制，支持主流类型主流型号的传感器，对新型传感器具有扩展能力。提供丰富的硬件适配服务软件，硬件适配包括快速适配硬件平台和快速适配车辆平台两个部分，其中快速适配硬件平台又包括内核、中间件、AI、安全域几个方面，快速适配车辆平台包括传感器抽象、执行器抽象、HMI 数据接口。主要包括：

1）平台解耦和适配；

2）AI 模块移植和部署；

3）传感器抽象；

4）执行器抽象;

5）地图数据；

6）中间件适配；

7）HMI 数据；

8）核心车辆信号；

9）V2X 数据。

（二）、智驾功能的基础服务分解

在 SOA 架构设计中，对复杂应用和服务提取共性功能，分解成不同基础服务功能，目的是最大限度的从用现有模块和服务，提高开发效率。功能分解应该遵循：

1）基础服务内高内聚，服务之间低耦合；

2）低耦合服务间尽可能使用标准化的服务化界面；

3）如果某个功能模块复杂度还是很高，通过共性提取，需要继续拆分。

通过对复杂的自动驾驶功能、算法分解，形成基础模块，状态机/模式管理器、算法、环境模型，提供通用的 L0~L4 级自驾功能应用开发的组件化解决方案，支持基于组件的快速开发和验证。

主机厂基于自身策略，在设计和开发功能软件时可以选择不同的功能模块和算法组件，实现拼插式功能组合，灵活构建智能驾驶系统级解决方案。

（三）、网联云控服务

网联云控服务既提供标准的、抽象的信息服务，如红绿灯信息、交通提醒信息、安全预警信息、路侧感知信息、周边车辆行驶信息，也提供可插扩算法的能力，可以新增、转换、适配不同的云控算法和应用。网联云控模块是车内外信息通信的桥梁，车辆平台可把自车状态、行驶意图广播到周围环境中或上传到云平台，同时也可从周围环境或边缘云获得感知信息(如障碍物信息)，决策规划建议，甚至运行轨迹信息。

在设计相关服务设计中，可以遵循 SOA 设计思想，使服务不依赖于平台。运行在平台上的感知算法可以融合来自云端的 V2X 道路信息，实现车路协同。车辆通过订阅云端感知和规划数据，充分利用云端的算力和多维度场景信息，实现运控应用场景。比如拥有感知设备的停车场全自动泊车。

网联云控模块可以通过对基于 SOA 架构设计思想的应用设计，无缝对接现有 V2X 场景，支持云控应用和云车协同应用。通过 5G低延时、高速率的通讯技术支持数字孪生，实现车内计算、应用向云边浮动和扩展。

（四）、信息安全服务

基于信息安全技术（详见第 7 章第五节），可以建立多种遵循SOA 架构设计的信息安全服务，如网络入侵检测，信息安全监控和预警，数据安全、主机安全监测。

在设计信息安全服务时，应该考虑用 SOA 的方法。比如信息安全监控可能运行在平台上，也可能运行在云端。基于 SOA 设计信息安全服务不依赖平台和操作系统，可以和云端的安全应用共享或无缝对接，也可以快速引入第三方信息安全服务。

（五）、系统软件

系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境。系统软件一般包含操作系统内核、虚拟化管理（Hypervisor）、POSIX、系统中间件及服务等。通过系统软件平台集成虚拟化管理、系统内核、中间件等组件，可为上层功能软件提供一个稳定、高效、安全的 SOA 服务运行环境，以及与硬件无关的应用开发接口。

下面从系统分层设计的角度描述：

1）系统内核：隔离了平台硬件，是硬件平台移植和适配的关键。计算平台设计要尽可能兼顾主流的操作系统内核，减少平台移植和适配的代价，满足 OEM 车辆设计根据需要更换平台的需求。

2）虚拟化管理：在 EE 架构从分布式转变成集中式计算平台，采用可保障各类应用系统具备一定隔离性的 Hypervisor 技术，将成为实现高性能智能驾驶操作系统的关键。比如，针对车辆计算和实时控制域采用不同操作系统。

3）中间件：是隔离系统软件和应用服务的关键部分。特别是通讯中间件，是计算平台 SOA 的关键。通讯中间件的设计要兼顾自动驾 驶 大 量 数 据 传 递 的 需 求 （例如 DDS ） ， 也 要 兼 顾 传 统 的AUTOSAR，OSEK 的要求。通讯接口应该包含实时 API，非实时异步 C-S，Restful 等。

（六）、OEM 自动驾驶应用软件 SOA 开发 SDK

自动驾驶开发 SDK 通过一系列的软件组件和工具使 OEM 能够自由选择不同的硬件与软件、算法，自行组装出自己的自动驾驶系统。特别是可以让 OEM 能够专注于构建他们的特定应用程序，满足从 L2 到 L3+自动驾驶对开发机器学习算法的要求，隔离硬件集成，消息传递、可靠的实时执行等问题。

对不同应用分类提供共性的算法集和模型(包括环境模型、规划模型、控制模型)，通过应用软件接口(SDK/API)支撑应用开发者实现高效低成本应用开发。

通过标准化的算法框架兼容多家第三方算法，通过不断丰富的算法生态为 OEM 厂商提供多种选择。

具备完整的仿真测试流程和丰富的场景库，能够支持基于 SIL、MIL、HIL 的仿真测试闭环。用户可以使用这些 SDK，参考目标车辆平台和硬件配置，支持的传感器和其他硬件类型以及所提供的数据抽象、接口服务和开发工具，实现完整的、定制化的自动驾驶应用功能开发（例如 ACC、LKS、HWA 等）。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者