ADAS/AD开发03 - 系统架构设计及通用需求定义

上文中对功能和产品进行了区分。从本文开始，正式开始介绍组成产品的Building Blocks。

本文着重介绍System Architecture Design and General Requirement.

1. Product Overview - 产品概览

以智能前视摄像头模块（IFC，Intelligent Frontal Camera）为例分析系统架构设计，如下图所示：

图1 基于Camera视角的1R1V方案系统架构

 

目前的L1-L2级别智能驾驶，产品配置方案上常采用1R1V方案（注意强调的是产品配置方案，并不是指硬件方案；硬件方案指单个产品的电子电路硬件的架构设计方案），即1xRadar+1xCamera的目标融合方案。具体的，前视摄像头提供视觉信息，包括车道线、路面上的目标（车辆、行人、骑自行车的人等）、道路旁边和道路上空的各种交通信号标志等信息；前向毫米波雷达提供路面上的目标信息；非目标信息之外的视觉信息，如车道线、交通信号标志等，直接发送给上层应用程序使用；来自两种传感器的目标信息，会经过融合算法计算后，再经过跟踪、目标筛选和轨迹预测后，最后生成结构化数据发送给上层应用程序。这里的目标融合方案，一般由Radar提供目标的Range（相对距离）、RangeRate（相对速率）和RangeAccel（相对加速度）信息，摄像头提供目标的Angle（角度）及目标分类（Classification），最后将可融合的目标融合在一起。该融合方案，也可称为Mobileye融合方案（Mobileye公司是ADAS领域、视觉感知方向的、到目前为止的绝对霸主，具体大家自己百度吧...），主要借助EyeQ3视觉算法芯片的VFP（Vision Fusion Processor, 视觉融合处理器）模块，利用私有CAN（Private-CAN，以下简称PCAN）将毫米波雷达模块的原始目标数据传入VFP中，利用目标融合算法和目标筛选算法，获得最终的feature可用的目标信息。在这条技术路线中，如果按照主从关系来描述的话，IFC智能前视摄像头为主模块，前毫米波雷达为从模块。因为所有Features都是放在IFC中的，与整车CAN（Vehicle-CAN，以下简称VCAN）交互的也只有IFC，雷达模块的地位已经削弱到纯粹的传感器的层面，且只能通过PCAN与IFC连接，自身并无法与整车直接取得交互（也无必要）。关键词总结：强者更强、弱者更弱的强耦合型1R1V关系。

值得一提的是，1R1V融合方案中，除了上述技术路线，还存在另一种技术路线。这条技术路线，主要由德国的两个Tier1巨头采用，博世和大陆。这两个公司共同的特点就是，当年ADAS刚开始兴起时，对雷达的需求特别大，而且加上雷达的硬件技术门槛很高，这两个公司利用其技术实力，迅速占领市场，一直霸占雷达模块市场的前两名，直到目前为止仍旧是这样。讲这个背景故事，主要是为了展现雷达产品在这两个公司中的绝对强势地位、雷达团队的强势话语权、资源掌握的优先权。而这两位大哥又不愿意在技术上受制于人，因此在IFC产品上，都采用自己研发视觉检测算法的方式，拒绝采用Mobileye的视觉技术。但是视觉技术上的积累，确实跟Mobileye还有一定差距。因此，两相对比，雷达模块的强势、摄像头的弱势，就导致了它们采用以雷达模块作为主模块，与VCAN通信，同时利用PCAN接收来自IFC的视觉目标信息，融合后用于纵向feature的控制。雷达模块之所以成为主模块，是因为有Safety相关的架构做在了雷达中。而这条技术路线中的IFC也有自己的特点，就是IFC本身并未降级为纯粹的传感器，模块里面仍旧保留了一些安全等级较低、且只依靠视觉感知就能工作的features，例如AHBC智能远光灯控制、LDW/LKA车道偏离报警及车道保持辅助等功能。由于IFC有功能，因此也需要连接至VCAN，跟车辆交互。关键词总结：强者不太强强、弱者不太弱的弱耦合型1R1V关系。

 

2. Power Moding - 电源模块设计需求（硬件实现）

• Power Moding强调硬件范畴；下文还会出现Power Mode Manager，强调软件范畴，指电源管理模块；

• 唤醒需求：IFC所在CAN网络上的所有ECU节点，在有持续高电压输入的情况下（即通信使能线Communication Enable Line），能够自动唤醒；

• 当通信使能线激活时（即处于高电平状态），IFC唤醒后，通信要hold下再开始通信（Bus Wakeup Delay Time），用来等待CAN总线初始化。当通信使能线关闭时（处于低电平状态），IFC应立即停止通信。

• 当通信使能线状态从低电平跳转到高电平后（即允许通信后），IFC应该在XXms之内进入正常通信状态。

 

3. Host MCU Section - 主MCU芯片部分

• MCU：Microcontroller Unit，微控制器单元，即单片机；

• Host MCU可通过SPI接口与其他SoC芯片建立通信、传输信号，例如EyeQ3芯片等；

• Host MCU接收的SPI信号主要包括以下几类：a.来自EyeQ3中的私有MCU的视觉信号；b.来自EyeQ3中的Fusion Tracker（融合跟踪器）的融合行人目标信息；c.来自ETSEL（目标筛选算法）的12个ACC目标（6静态6动态）；d.来自ETSEL的2个FCW/AEB目标（1静1动）

• Host MCU中需要实现的软件模块包括：

1. PowerModeManager（电源模块管理者）

2. ConfigurationManager（配置管理者）

3. FeatureFunctions（功能和功能点），主要包括：a. LORS（即feature与host-sw的参数接口信息）; b. 视觉features（LDW/LKA/TSR）; c. 目标features（FSRA/FCW/AEB）

4. Environmental Conditions Evaluation / Heater Control （环境条件评估/加热控制）： a. 温度处理; b.传感器遮挡处理; c. 镜头加热去雾控制; d. 内部状态处理

图2 环境条件评估数据流图示

 

a.温度处理：在Host MCU与EyeQ3芯片之间，布置了一个温度传感器；EyeQ3芯片上布置了两个温度传感器，一个靠近MIPS（充当MCU）核心，一个靠近VMP（矢量微码处理器）；图像传感器位置，布置了一个温度传感器。利用温度传感状态机（Temperature Sensing State Machine）控制温度：

图3 温度感知数据流图示

 

图4 温度感知状态机

 

图5 温度状态迟滞现象

 

b.传感器遮挡：摄像头的遮挡需要合理的标定来匹配，遮挡时间可重新标定。同时要考虑雨刷状态、车速、阳光直射角度过低导致的反光等因素。一些重要的blockage参数需要底层SoC（EyeQ3）提供，例如：完全遮挡严重度等级、图像模糊严重度等级、液体飞溅斑点严重度等级、阳光直射角度过低导致反光的遮挡严重度等级、阳光衍射导致的遮挡严重度等级、大雾严重度等级、涂抹导致的遮挡严重度等级、自车开远光灯导致的视线炫目的严重度等级、根据目标融合算法-雷达报摄像头低可见度的严重度等级、雷达需要重新标定严重度影响、因为天气条件差-可见度低导致的图像涂抹严重度等级。白天时段（根据光照条件判断）摄像头开机后没有blockage的话，Blockage检测时间一般7分钟一个周期，假如开机后就存在部分blockage，那么每2分钟检测一次。夜晚时段，检测到部分blockage的话，每1分钟运行一次blockage算法；夜晚被检测到完全blockage的话，每15秒检测一次。

图6 遮挡模块与其他模块的关系

 

一旦检测到blockage，系统就会关掉feature功能，若温度低于一定阈值，还会打开加热功能，尝试排除有水雾造成的遮挡等因素。当然，假如并没有水雾，加热操作还是会继续进行，只不过这项操作没有实际效果而已。假如blockage消失，说明加热有效（正好蒙对了，确实是由于水雾造成的遮挡），则开启所有feature。假如加热无效，那么系统会进入临时blockage状态，并继续加热，同时再分配一定时间，看能否尝试解决（或者就是被动的等待，等待一些不知名的因素会在该时间内消失）。如果该时间段内问题仍未解决，则进入blockage状态，并通知驾驶员IFC发生遮挡。

图7 Blockage状态机切换

 

c.光路处理：Optical Path Processing，Mobileye提供的接口（结构体）cads4_active_light_sensor_info_t中包含信号clearFieldOfView，coding值有0/1/2；0代表光路还未评估，1代表模糊不清，2代表光路畅通。

5. 诊断：诊断功能要做到Host MCU中；

6. 初始化完成状态确认：Host MCU需要有能力监控并确认EyeQ3芯片已经初始化完成并可用。EyeQ3中反馈自己初始化状态的接口为cads4_vision_application_init_info_t。

7. 标定/XML/Utility文件刷写功能：Host MCU需要实现标定文件/XML文件/Utility文件的刷写功能。

8. SPI通信接口：HOST MCU应该支持视觉信号/来自融合跟踪器中的行人信号/来自ETSEL算法中的、给ACC功能使用的12个目标信息（6静6动）/来自ETSEL算法中的、给FCW-AEB功能使用的2个目标信息（1静1动）。

9. 与前向毫米波雷达通信的私有CAN：Host MCU应该实现PCAN通信。

10. VCAN通信：Host应该实现与车辆CAN的通信。

11. XCP标定协议：Host要实现XCP协议。

12. 网关功能：Host要实现从VCAN转发数据给前向毫米波雷达的网关功能。

13. 传感器的EOL/Server/Online校准功能：Host MCU要实现三种传感器校准功能。

 

4. EyeQ3 MCU Section - EyeQ3 MCU芯片部分

EyeQ3是Mobileye公司的视觉处理芯片，属于一个多核的SoC（System on Chips, 片上系统芯片），包括4个MIPS和4个VMP。

MIPS：全称Microprocessor without Interlocked Piped Stages，无内部互锁流水级的微处理器，作为MCU，控制外围单元。

VMP：全称Vector Microcode Processor，矢量微码处理器，视觉算法运算核心。架构采用Transmeta全美达的VLIW架构。

图8 EyeQ3内部框架图

 

a. EyeQ3的视觉算法：Mobileye在推广自己的视觉处理算法时，担心算法被抄袭，采用了算法固化在芯片中的方法，以卖芯片的方式卖算法。算法包括：图像处理、创建视觉轨迹、对视觉目标进行分类、与雷达跟踪片段（tracklets）匹配、供融合跟踪器使用的典型视觉跟踪信息等。

b. Tier1的VFP算法部分：如德尔福的ETSEL算法（Enhanced Target Selection，增强型目标选择算法）。

c. Tracklet-Tracker跟踪片段的跟踪器算法：该算法会接收128个目标，并处理成相关跟踪片段。跟踪片段的跟踪滤波器应采用笛卡尔等速加速运动模型。该算法的目的是提供持续的雷达信息。

d. Fusion-Tracker融合跟踪器：融合跟踪器从跟踪片段跟踪器中抓取跟踪片段，并从Mobileye视觉算法中抓取15个与能够与跟踪片段匹配的上的目标信息。之后将这15个融合后的目标信息传给ETSEL目标选择算法。具体地，算法通过雷达和视觉信息生成融合轨迹；对车辆目标使用CTCA模型（Coordinated Turn-Constant Acceleration motion model，协调转弯恒加速度运动模型）进行跟踪滤波，对非车辆目标信息使用CCA模型（Cartesian Constant Acceleration motion model，笛卡尔恒定加速度运动模型）进行跟踪滤波。对一些特定目标，将目标的轨迹与雷达跟踪片段进行关联融合，获得一条融合轨迹。融合轨迹可以有0到1个视觉轨迹以及0到15个雷达跟踪片段。轨迹滤波器一般将车辆目标的前脸和后脸的中心作为参考点。

e. ETSEL增强型目标选择算法：计算车辆侧滑状态；利用自车转向轨迹路径、前车运行轨迹来估算前方道路曲率和自车的heading angle；根据估算曲率获得自车前方车道的估算车道中心线；根据车道中线、计算每个目标的XOHP（X-Offset Host Path, 指前方其他车辆距离自车所在车道的车道中心线的距离）；筛选12个动态和静态目标信息（6动6静给ACC，1动1静给FCW/AEB）。

图9 XOHP和XOLC的定义

 

图10 XOHP详细定义

 

图11 XOLC详细定义

 

f. Mobileye视觉算法与Tier1的VFP之间的接口定义

g. 外部Flash和DDR

h. EyeQ3芯片与前毫米波雷达之间的PCAN通信接口

 

5. Component Functional Requirement 产品零部件需求

不再详细展开，主要是一些一般化的技术需求，例如电源需求、接地需求、ACC/AEB/LKA等功能的硬开关需求、产品外围架构原理图（如图12）、产品内部架构原理图（如图13）等。

 

6. Electrical Requirement 电子需求（硬件需求）

不再详细展开，主要是一些诸如：电气接口定义、微控制器通用需求（时钟频率、供电、Flash、数据刷写保护、NVM、调试、晶体和晶振）、静态电流牵引、EMC等需求。

 

7. Mechanical Requirement 机械需求

不再详细展开，主要是一些诸如：无铅制造要求、保型涂料（conformal coating）、外观、焊点（Solder Joints）、连接器（Connector）、包装、安装位置、固定等需求。

针对于镜头模组（Lens+Imager），无需使用保型涂料。

 

8. Dimensional Requirement 几何尺寸需求

不再详细展开，主要是一些诸如：产品尺寸、连接器的形状尺寸及PIN脚定义、产品在整车上的安装策略等需求。

 

9. General Software Requirement 通用软件需求

不再详细展开，主要是一些诸如：算力（Computing Resources）、检测目标和检测系统的状态权限定义（即通过UDS和XCP对系统进行诊断和标定等要求）、工厂/服务站等校准功能、基于模型的设计（这对feature的开发）等需求。

 

10. System Test Requirement 系统测试需求

TBD

 

10. Environment Requirement 环境需求

不再详细展开，主要是一些诸如：产品在整车的安装位置环境要求、产品运行环境（温度、相对湿度、气压）等需求。

 

11. Recyclability / Substance of Concern Requirement 可回收性和关注物质要求

TBD

 

12. Validation Requirement 验证需求

不再详细展开，主要是一些诸如：验证测试计划、EMC试验、VCRI（Validation Cross-Reference Index，验证交叉引用索引）、支持段（Supporting Paragraphs）、记忆完整性（Memory Integrity）需求等。

其中，验证测试计划需要覆盖上文规定的所有环境需求和机械需求；

VCRI表格，主要用于供应商定义验证步骤。包括分析、开发、验证的计划和对应的报告；

对于记忆完整性验证，所有的NVM需要在刷写过程中，接受至少500次的连接器的插拔测试，来验证记忆完整性需求。

 

13. Manufacturing Requirement 制造需求

不再详细展开，主要是一些诸如：MPI（Manufacturing Process Instructions，生产作业指导）文件创建需求、DFM（Design for Manufacture，可制造设计）需求、DFA（Design for Assembly，可组装设计）需求、PFMEA（过程FMEA）需求、可追溯性需求、老化（Burn-in）需求、焊接过程（Soldering Process）需求、搬运与成型（Handling & Singulation）需求、紧固件（Fasteners）需求、铸造（castings）需求、机械接口的防呆矩阵（Mechanical Interface Error-Proofing Matrix）需求、包装标签（Package Labeling）需求、测试需求。

 

14. Logistic Requirement 逻辑需求

TBD

 

15. Functional Safety Requirement 功能安全需求

后续详细展开。

 

16. Reliability Requirement 可靠性需求

主要包括：REP（Reliability Evaluation Point，可靠性评估点，一般要求10年或16万公里）、长期质量需求（如下表）、RPR（Reliability Performance Requirement，可靠性性能要求，一般要求大于0.97）、可靠性测试需求。

表1 长期质量需求表

 

17. Quality Requirement 质量需求

主要包括：DFMEA需求、质量计划、P-Diagram（参数图表）、PPAP质量要求等。

 

18. Serviceability Requirement 可维护性需求

主要包括：产品维护需求、产品维修需求（即诊断通信，CAN Diagnostic）、产品更换需求、4S店工程需求、交付活动（Delivery Activities）等需求。