关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
对智能驾驶系统的研发流程上讲，一直希望从顶层系统架构开始到底层之间一次性讲清整个智驾系统是如何进行信息交互、应用调用和过程传递的。整个信息流的传递和过程交互包含行车控制和泊车控制，两种应用在实际的控制上存在一定的差异。本文将针对泊车控制功能模式从底层软件、中间件到应用软件之间的信息交互和过程控制逻辑进行详细讲解。当前不同供应商和主机厂在整个软件架构上基本都是一致的设计方式。通常采用的是从底向上的分层设计方式，如下图所示。我们在这里不详细分析软件架构到底是怎样的构造方式，我们详细说明一下整车开发的软件过程管理和模块调用分工。Tier1通过接收主机厂的硬件架构，包含视频输入、视频输出、超声波、以太网、接插件位置等导致原理图、PCB新设计。Tier1根据主机厂硬件需求和架构需求对传感器进行合适的硬件驱动。如摄像头直连域控时，其驱动方式就是域控通过IIC配合一定的驱动算法直接驱动摄像头开闭。同时，也包含与超声波雷达适配、毫米波雷达适配、车身数据（线控）适配、RTK_SDK集成。这个模块主要tier1/tier2根据感知需求对其处理过程包含相机加速处理、深度学习模型底层服务评估所需要的算力需求，从而对所搭载的硬件平台能力进行总体布局。如果开发是非全栈的话，tier2需要将处理完成的感知数据集成打包并制定好接口给到tier1。一般tier1会根据选型的芯片选择其适配度较好的操作系统，同时配置相应的时间管理、日志管理、安全实时内核、标准信息服务等。对于tier1分解的功能软件来说，主要包含两个层面：一种面向客户级别的顶层功能，这些功能需求主要是通过将客户需求直接拆解到系统需求来实现；另一种个是系统级别拆解到具体软件的识别端。比如感知、定位、环境建模、规控算法参数适配。算法逻辑也涉及ODD检测、ADAS新增元素部分检测能力、相机标定；支持速度、路线距离、动态感知初始化等。从软件架构设计的角度讲，应用软件设计层主要是拆解客户需求（主机厂输入的功能配置表或功能规范），一般会形成一个feature list和sub feature list。开发过程，顶层APP的每个software模块需要如上的feature list相对应，以确保所有feature都是被开发完成的。接下来，将就一个常见的记忆泊车场景来对整个软件架构如何处理ADAS功能进行说明。对于智能泊车（如记忆泊车）而言最重要的几个点就是常规的感知到规控处理、记忆建图处理、时间同步、日志记录、标准通信管理。在总体要求的基础上，智能泊车需要增加停车场动态交通信息、场景融合信息、场内外车辆交接信息、场（路）侧智能设备信息以及自定义的其他扩展信息等相关地图数据信息。停车场动态信息包含停车场内或出入口关联道路上实时发生的，会对泊车过程或行人通行产生影响的一系列动态信息。以上信息都需要专门的视觉感知模块进行有效的检测和处理。对于视觉感知处理这块可以整理一个大概的数据处理通路，本文将针对性的对底层软件角色在自动驾驶软件中的位置及模块划分方式有一个大致说明。智能泊车感知从常规处理手段上一般都是环视+超声波融合的方式进行。而对于记忆泊车而言，还存在建图过程中对前方行驶车辆的轨迹探测和前方碰撞目标的危险程度探测。因此，通常会考虑接入行车前视摄像头信息以增强其前方探测能力。由于通常ADAS高阶系统域控为行泊一体控制器，为了提升运算效能，对于行泊感知源通常会采用分时复用的方式进行感知数据的有效处理。同时，智能泊车内部也是会采用合适的Pipeline进行功能处理。如下图表示了智能泊车的pipeline处理策略模块。对于智驾系统而言，前视摄像头会采用一种异构的大小眼。而对于泊车功能而言，采用其中一种宽视前视即可具备足够的识别能力同时可降低对系统的算力需求，一般只应用到了前视宽角视频图像作为输入来进行目标探测。- Distortion Correction+Resize—>模拟前广角，不丢失视场探测范围，该前视探测信息便可适配智能泊车域；
- Crop+Resize—>模拟前中距，保留一定FOV及像素密度，适用于泊车低速巡航控制；
- Crop—>模拟长焦距，不丢失远处像素密度，适用于智能泊车前方小目标紧急探测；
以上各方感知输入源最后会在中央域控中输入一个总体的感知融合算法模块，从而构建出实时的车身位姿数据以及对应的地图元素感知特征数据。如上图所示的整个Pipeline在顶层软件运行过程中，需要开发包含应用场景分析、精准定位、地点查询、安全预警、路径方式几个方面的软件模块。其中，应用场景模块主要涉及停车场、停车场运营服务平台、MPA、APA、AVP等智能泊车系统。精准定位包括GNSS、RTK、SLAM、VIO（视觉惯性里程计）、FLD（特征定位数据）、UWB等。地点查询包括停车场及车位查询、ODD范围、兴趣点、停靠泊车（如上下车点/充电）等。安全预警部分则包括障碍物、安全冗余、禁区、限制管控、危险路段、预警措施等。每种软件模块在如上三条Pipeline里面都需要调用专门的中间件模块组合来输入到最终的大状态机做状态判断，并执行不同的泊车辅助功能。最后通过地图、定位、感知数据的协同技术输出到整体大状态机的判断逻辑实现功能的激活决策控制。建图定位模块的关键技术主要包括车辆本身定位和车位地图扫描两个部分。该模块需要完成车辆周围信息的感知和建模，车辆自身的定位和跟踪反馈，所建立的地图和定位信息是自动泊车路径规划和控制决策模块的根源基础，也是决定车辆自动泊车质量的直接因素。此外，需要说明的是，如上三个Pipeline的底层软件模块设计中，Pipeline1主要是通过接收完成里程计估算，生成自建地图；Pipeline3是超声波雷达数据输入处理得到的感知语义数据，与全局高精定位输入的原始定位数据进行融合后生成对应的定位相关元素；Pipeline2则是通过输入与泊车相关的视觉感知信息到视觉加速模型数据、并融合Pipeline1和Pipeline3的数据输入并应用恰当的算法进行融合数据更新；最后输入泊车大状态机里面做状态决策判断。通过最终输入的不同数据链路可以决策状态机最终激活何种泊车功能。对于泊车感知视频源处理端主要由摄像头Sensor自身驱动模块、视频接口驱动模块、异构核IPC通信模块以及A核接口构成。摄像头自身驱动主要是进行通用的传感器设置、曝光处理、原始数据白平衡处理、色彩空间转换等原始操作。视频接口驱动需要运行在实时核R上负责整个视频硬件加速，才能保证接入的视频原始数据无延迟。同时，充分利用异构核资源优势，作为专用核来确保视频图像高实时、高可靠性。R核采集的视频数据通过管道通信机制IPC实现数据快速传输到计算A核。最终A核通过通用的事件处理机制，处理所传输过来的视频数据，并将是视频数据进行有效封装并暴露出与硬件无关的接口供上层应用软件调用。下面针对如上图所示的几个由底软实现的功能软件进行说明：总体来说，底层软件的功能相对于之前分析的应用软件，其主要是需要驱动硬件获得原始感知数据，并进行一定的前端处理、封装、打包等操作后生成对应能被上层所感知的软件模块SWC输入给上层应用APP。如下图所示表示了一种完整的泊车控制在底层软件模块中的示意图。首先，对于记忆泊车而言，需要底软调用硬件驱动文件从前端感知硬件获取超声波雷达、环视摄像头、前视摄像头的对应RawData。然后，通过标准的Autosar处理模块进行消息路由PDU、转发等。然后在数据处理模块中需要参照一定的软件处理算法进行数据处理分类。分类结果是输出车道线、车位、环境目标等信息。对于完整的记忆泊车软件架构任务分配来说，擅长高计算能力的SOC需要执行循迹巡航、探索前进、倒车辅助、泊车出库、泊车入库这几个大类的软件任务。这些任务的实现主要是通过环境信息+自车定位信息来实现轨迹规划和控制任务，同时通过中间件模块的场景管理调度原子服务+提供任务参数来补充到整个泊车控制任务中。在底软到中间件的建模过程中，需要构建环境建模模块EM对障碍物信息（freespace、bounding-box），路面信息（车位、阻车器、减速带）的进行有效的建模和封装。改模块对于上层应用软件的调度来说需要封装成统一接口的。且底软可通过顶层软件的不同的功能输入构建不同的配置文件进行不同的环境建模。对定位建图来说，则是需要对位置、姿态、速度、角速度、加速度、车道线的信息重建。对于记忆泊车而言，首先需要建立兼具语义特征稳定、低层特征丰富、环境适应性强的泊车地图。因此，建图过程中，需要充分融合包含行泊车的各方传感器输入（如摄像头感知输出的底层特征图及地图元素的感知输入），既能保证各方传感器相互独立，又能进行相互间的补充校验，从而提高容错性。此外，关于建图过程中需要充分考虑IMU和轮速计之间的预融合（Pre-integration），保持建图尺度的一致性，提升通用性。从底软的角度讲，除了建图结果需要呈现的地图调度接口应该是能够为上层调用外，其建图过程通常实时更新的。因此需要考虑所有的过程是需要被实时记录和可追溯。如果有建图不成功的情况，应该是需要做有效的日志记录Log的。场景管理部分则需要对车辆状态、探索前进任务、巡航任务、示教轨迹、倒车辅助任务、轨迹记录、泊入任务+车位id、泊出任务+出库方式等整个过程控制。底软和中间件需要调度对应的任务分配模块，将对应的任务实现逻辑运用到整个管理过程中。此外，在实时核MCU中需要对控车模块进行仲裁，需要考虑泊车紧急制动功能MEB的激活是否会与行车功能起冲突，因此在执行控制过程中需要进行指令仲裁，实现控车权的仲裁，最后底软接口需要将执行指令封装成总线信号形式发送给执行器执行。我们高阶自动驾驶通常需要搭载高分辨率摄像头，整个Capture驱动主线是基于基础芯片框架实现，开发过程中可以对多输入源的Graph进行支持，异常资源释放等功能。对于视觉感知处理这块可以整理一个大概的数据处理通路，可以对底层软件角色在自动驾驶软件中的位置及模块划分方式有一个大致说明。如下图表示了从底软的角度描述了整个视频流在抓取、存储和取出的整个驱动过程。无论行泊车对于输入的三路虚拟摄像头信息分别需要进行如下方式的处理。关于视频数据流的抓取的驱动过程包含如下几个步骤：摄像头初始化Camera Init——>图像抓取Camera Capture——>完成视频图像采集——>形成摄像头视频序列Camera Quenue——>进行视频序列Buffer管理——>实现处理视频数据的零拷贝；从底层软件架构的角度分析，对于如上图所示的视频序列的存取处理机制（如神经网络CNN）所涉及的几个过程主要是通过CPU对DSP的调度实现。首先，通过CPU实现模型创建生成加载模型，开辟合适的内存；其次，通过CPU实现模型计算，反馈合适的计算结果；最后，模型退出后，CPU又需要释放所占用的的内存资源。最后，通过一个详细的底软架构图分析说明如何对应用软件模块进行调用。①SOC硬件层调度传感器硬件相机驱动，传输原始感知数据流给到上层操作系统。这里的原始感知数据时可以通过感知框架中的任务管理模块（接收所要执行的ADAS任务子项）、相机管理模块（相机输入数据配置、相机硬线配置、相机曝光配置）、配置管理模块（主要是根据输入的ADAS任务管理子项配置合理的传感器输入数据来进行感知检测）进行数据预处理、模型搭建和数据并行处理后，生成了车道线、交通标志、障碍物信息、可行驶区域、泊车位置空间。②为了给上层感知处理模块提供可靠、高效的视频源。中间件需要进行传感器时间同步管理、通信管理、资源管理、配置管理、OTA管理等。时间同步管理：将输入的各类不同的传感数据按照系统自定的时间管理策略标识打上时间戳。这类算法需要参照具体的系统架构来定，比如摄像头作为纯传感器，其曝光、视频输出处理都是完全由域控来打时间戳同步；而如果超声波雷达外接了处理ECU，则其输入输出则需要由子ECU自己控制打时间戳。但是通常底软在这部分时间同步算法上会遵循标准的Autosar标准。通信管理：BCU通过唤醒信号控制相应CAN消息的通信使能（交流、直流帧），RTE将应用层SWC信号转化为通信信号（Com Signals），并通过Com, PduR, CanIf, Can driver之间的标准接口函数实现CAN信号收发。资源管理：对于从底层软件配置、中间件调度、顶层软件调度和运算中需要利用的资源进行相应的存储管理和算力分配。配置管理：配置管理可以用于对输入传感器的数据进行分时控制，从不同的场景角度上讲，这块可以很好的提升对传感数据的处理效率。③在感知处理模块包含三个层面的处理逻辑。视频输入链路进行ISP处理、Camera数据接口、Sensor驱动、输入接口驱动。计算加速模块进行神经网络（CNN/RNN）推理、图像去畸变、图像Crop+Resize预处理、图像颜色空间转换。Display输出模块需要创建数据接口、输出接口底层驱动。④顶层软件调用底层软件封装的软件模块接口对对应的软件模块进行调用。其中通信中间件需要为应用层用户提供统一的调度接口，包含初始化、注册、发送/接收等接口。通信中间件可以基本实现多节点分布式软件模块的发布订阅通信（类似于SOA中面向服务的通信机制进行初始化、订阅注册、发送注册、消息推送、接收），且通常位于SOC和MCU之间的异地通信以及SOC内部的本地通信。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
