ADAS/AD控制器模块开发01 - 行业背景、基本概念名词介绍

一、行业背景介绍：

汽车行业的金字塔供应链体系：

汽车行业作为百年产业，有复杂的供应链体系。位于金字塔顶端的，是OEM（主机厂/整车厂），负责开发、制造、销售汽车；往下是汽车零部件的一级供应商（Tier1）、二级供应商（Tier2）、...等等。

其中OEM即为广为人知的各种整车厂，例如上汽大众、上汽通用、一汽大众、广汽丰田、长安福特、吉利、长城、上汽乘用车、广汽乘用车等等汽车厂；

Tier1即为各种手握真正汽车核心技术的一级零部件供应商，例如博世、采埃孚/天合、大陆、麦格纳、德尔福、电装、爱信、博格华纳、法雷奥、舍弗勒、奥托立夫、伟世通、联合电子等等；

Tier2即为各种给Tier1供应商供货的供应商，以汽车电子零部件中的半导体芯片产业为例，主要是德州仪器（TI）、瑞萨电子（Renesas）、恩智浦（NXP）、英飞凌（Infineon）等等芯片厂家。

汽车的新能源化和智能化：

汽车目前有两个大体的发展方向，一个是新能源化（混合动力、插电混动、电动、燃料电池等），一个是智能化（智能驾驶和智能网联）。

对于新能源化，对于天朝来讲，是必须要搞的。保护环境的因素有，但是效果也不一定明显，更多是宣传口的概念，真正主要还是降低国民经济和民生领域对于石油的依赖。另外，传统内燃机壁垒太高，核心技术都在国外，天朝也想找个由头和方向，创造一些弯道超车的机会。个人认为新能源化的终极目标应该是燃料电池。但是由于目前中国的燃料电池技术太弱，整个世界范围内燃料电池技术最发达的国家又是日本。这就有个问题，如果发展燃料电池，那就相当于天朝撒钱给脚盆鸡（Japanese, 日本英文发音谐音，下同），帮助扶植脚盆鸡发展燃料电池产业链。这种事情当然不能干，只能边走边看，啥时候国内相关技术达到一定临界值，才会重拾这条线路。搞混合动力吧？是挺省油，但是还是脚盆鸡的技术最强，例如丰田普锐斯及其他一众混动版的丰田车（卡罗拉混动、雷凌混动、凯美瑞混动...），况且还是要烧油啊，不符合国家能源战略。搞插电混动？只能前期电动车发展推进不下去时，激活市场使用；因为插电混动的存在，买车的人少些疑虑和担忧，造充电桩的人因为有需求可以多造些充电桩，帮助电动车相关基础设施的铺开。最后找来找去，只能先发展电动车了，毕竟美国（鹰酱）还有个特斯拉作为排头兵，也活了这么多年了，能够帮助天朝人摸着鹰酱过河。况且这个技术路线的技术门槛相对来说最低，君不见一水的新造车势力，全都采用电动车是为嘛吗？

对于智能化，目前包括两个子方向，一个是智能驾驶方向，另一个是智能网联方向。智能驾驶方向又分为ADAS和AD（下文会详细解释）。而对于智能网联方向，终极目标应该是智能驾驶仓的实现，即整个乘坐舱的智能网联化、多媒体化，各种炫酷的HMI显示、各种AR技术、各种屏幕、各种网联设施、各种人性化科技化的设计、各种像蔚来汽车NOMI那样的人工智能机器人（虽然目前功能挫的一逼）...需要说明一点，这两个方向并不是最近才出现的，事实上，在传统汽车电子领域，一直就存在两大类汽车电子，一种是电子控制类，一种信息娱乐类。只不过智能驾驶方向是电子控制类产品的进一步发展，智能网联方向是信息娱乐类的进一步发展。

汽车电子产品开发工具链简介：

TBD

二、概念&名词解释：

谈ADAS/AD之前，首先要将与之相关的各种常见ADAS/AD功能点（features）的缩写和含义贴出来，如下所示：

a. 各种智能驾驶功能点的缩写及全称：

CC: Cruise Control 定速巡航；
ACC: Adaptive Cruise Control 自适应巡航；
FSRA（或 ACC Stop&Go）: Full Speed Range ACC 全速域自适应巡航；
FCW: Front Collision Warning 前向碰撞预警；
AEB: Automatic Emergency Brake 自动紧急制动；
AEB-V: Automatic Emergency Brake - Vehicle AEB-车辆；
AEB-P: Automatic Emergency Brake - Pedestrian AEB-行人；
AEB-C: Automatic Emergency Brake - Cycling AEB-骑自行车；
LDW: Lane Departure Warning 车道偏离预警；
LKA: Lane Keeping Assit 车道保持辅助；
LKA-LDP: LKA - Lane Departure Prevention LKA之车道偏离修正；
LKA-LC: LKA - Lane Centering LKA之车道居中；
ELK: Emergent Lane Keeping 紧急车道保持；
TSR: Traffic Sign Recognition 交通标志识别；
ISA: Intelligent Speed Adaptation 智能车速控制；
IHBC: Intelligent High Beam Control 智能远光灯控制；
DMS: Driving Monitor System 驾驶员监控系统；
TJA: Traffic Jam Assit 交通拥堵辅助；
HWA: Highway Assit 高速公路辅助；
APA: Auto Parking Assist 自动泊车辅助；
RPA: Remote Parking Assist 远程泊车辅助；
TJP: Traffic Jam Pilot 交通拥堵领航（科技公司常称低速自动驾驶功能）；
HWP: Highway Pilot 高速公路领航（科技公司常称高速自动驾驶功能）；
FCTA: Front Crossing Traffic Alert 前向十字交通预警；
RCTA: Rear Crossing Traffic Alert 后向十字交通预警；
BSD: Blind Spot Detection 盲点探测；
LCA: Lane Change Assit 换道辅助；
DOW: Doors Opening Warning 开门报警；
RCW: Rear Collision Warning 后方碰撞预警；

从以上各个feature可以看出明显的小步迭代痕迹，总是从检测-报警-控制的技术路径进行演化。例如TSR（交通标志识别）与ISA（智能车速控制）的关系，先识别出交通信号并展示在HMI上，之后才是对一些交通信号的应用，如车速限制标志的应用（ISA智能车速控制）。同样的成对关系还有FCW/AEB、LDW/LKA等。

还有一种演化趋势，可以表征车辆责任控制权的转移，例如TJA到TJP，HWA到HWP等。

这种掰碎了的各个功能点有个好处，既方便了OEM进行产品配置选择，进行高低端产品搭配；也方便了Tier1供应商报价收钱。

b. ADAS/AD：

又称Advanced Driver Assistant Systems / Autonomous Driving 高级驾驶辅助系统/自动驾驶；其中，ADAS专注于L1/L2/L3级智能驾驶，AD专注于L4/L5级别智能驾驶。L0级代表无智能驾驶功能；L1代表只有报警提醒但不具备车辆干预能力的ADAS功能，例如FCW/LDW/TSR/FCTA/RCTA/BSD/LCA/DOW/RCW等报警提醒功能；L2代表具备单纵向或者单横向车辆干预能力的ADAS功能，例如ACC/FSRA/AEB/LKA/ELK/ISA/IHBC等车辆干预辅助功能，注意这些功能英文中多含有Assit的字眼，代表辅助、助理的意思，也就暗示了驾驶员是车辆的主要负责方，ADAS系统只是辅助方，不承担主要驾驶责任；L3代表具备纵向+横向控制的完整ADAS功能，例如TJA/HWA/APA/RPA等车辆干预辅助功能，但是仍旧强调Assit（辅助），不承担主要驾驶责任，；L4代表具备纵向+横向控制的完整驾驶领航功能，例如TJP/HWP等车辆领航功能，注意这些功能英文中含有Pilot的字眼，代表领航的意思，也就暗示了在这些功能在限定区域内开启时，例如HWP指定只能在高速公路场景下开启，那么在该区域开启AD系统（注意不再以ADAS系统表征，而换成了AD系统）时，AD系统是车辆的主要负责方，驾驶员只有在需要介入时才承担责任；L5代表无限定区域的完全智能驾驶，也是完整意义上的真自动驾驶。

（comment by 小阿狸 @ 2018.11.14： 随着《汽车驾驶自动化分级》国标征求意见稿的推出，分法已经变化：L0代表无驾驶自动化；L1代表驾驶辅助，内涵是只有纵向控制或横向控制，如ACC、AEB、LKA，驾驶员不能脱手脱眼（手扶方向盘、眼睛监控车辆前方视野）；L2代表部分驾驶自动化，内涵是同时具有纵向和横向控制功能，如TJA、HWA，驾驶员不能脱手脱眼；L3代表有条件驾驶自动化，内涵是同时具有纵向和横向控制功能，如TJP、HWP，驾驶员可脱手脱眼打游戏亲嘴车震，但是一旦车辆搞不定一些情况，驾驶员必须立即接手控制权...L4代表高度驾驶自动化，内涵是同时具有纵向横向控制功能，驾驶员可脱手脱眼打游戏亲嘴车震，车辆报警让驾驶员控制车辆时，驾驶员想控制就控制，想继续打游戏页可以不理会车辆的报警提醒；L5代表完全自动驾驶，取消油门刹车方向盘，把车改装成房车，在车里随便震吧...）

c. 高级驾驶辅助/自动驾驶/智能驾驶的名词区别：

根据上述内容可知，汽车在无人驾驶方向上存在两种技术路线。

一种是以传统Tier1供应商采用的ADAS路线，即高级驾驶辅助路线，主要是以小步迭代的方式，逐步发展为完全自动驾驶。该技术路线剑指主流乘用车和商务车的量产车市场，隶属于汽车电子领域，主要依托传统的汽车电子开发流程和工具，即在硬件上，开发各种满足车规的电子控制单元模块（ECU）及外围传感器。软件上，依托于各个芯片供应商提供的嵌入式开发环境，例如德州仪器（TI）、瑞萨电子、英飞凌等，开发车规级嵌入式软件。算法上，一般会分成底层检测算法和上层应用算法，底层检测算法一般都是些传感器环境检测算法，例如Mobileye的EyeQ系列芯片实现的各种视觉检测算法集（车道线检测算法、车辆和行人等目标检测跟踪算法、红绿灯检测算法、交通标志识别算法、可行驶区域检测算法等等），底层检测算法多采用C/C++进行开发；上层应用算法实际是指各种如ACC/AEB/LKA/TJA等功能点（features），也有将上层应用算法叫做车辆控制算法的，功能点与主机厂的功能需求定义紧紧相关，且依托MATLAB/Simulink等可视化开发工具，以MBD（Model Based Design，基于模型的设计）开发流程，开发、管理各种ADAS功能点。ADAS的产品开发相对于AD开发的特点是，开发过程被解耦成很多具体学科模块，存在复杂的开发角色，例如系统工程师（系统需求、系统架构、系统测试）、电子工程师（或者叫做硬件工程师）、嵌入式软件工程师、算法工程师（主要指车道线检测等感知算法）、feature工程师（基于MATLAB/Simulink开发各种功能点）、机械工程师（负责零部件产品的外壳、标签等）、制造工程师（产线制造相关）、测试&验证工程师、匹配工程师等，这些复杂角色按照V-Model（V模型）开发流程，即需求分析、需求开发、系统架构、系统设计、各个学科子模块架构（软件、硬件、机械、匹配、制造、验证、算法、feature等子模块）、子模块设计、子模块实现，子模块测试、子模块集成、子模块集成测试、系统集成、系统集成测试、系统测试（也叫需求测试、功能测试、整车测试）的层级顺序，进行汽车电子产品的开发。ADAS路线目前是正在赚钱的路线，因此玩家主要以各种成熟的、巨型的Tier1公司为主力，如博世、大陆、德尔福、奥托立夫、采埃孚/天合、电装等，它们占领了主要市场，赚取巨额利润；国内公司曾经只能搞一搞360环视、自动泊车等技术门槛不高的ADAS系统，不过目前正在向L1和L2级别的前向功能和产品发力，也取得了不小进展。常见玩家有恒润科技、华域汽车、联创、延锋伟世通等，还包括众多智能驾驶初创公司等。因为硬件核心技术（如毫米波雷达硬件、摄像头CMOS图像传感器、镜头、各种MCU、ARM、DSP芯片等）仍旧在巨型Tier1/Tier2手中，所以大型跨国Tier1仍旧处于稳稳的垄断地位。该路线常见的汽车零部件产品主要有智能前视摄像头模块（FCM, Forward Camera Module）、前向毫米波雷达模块（FRM, Forward Radar Module）、ADAS/AD域控制器（ADC, ADAS/AD Domain Controller）、侧后方毫米波雷达模块（SRR, Side-Rear Radar）、360环视控制器+环视摄像头（BEV, Bird's-Eye View）等等。值得一提的是，这些产品不是简单的单一传感器，而是集成了传感器的ECU（电子控制单元）模块，是一个完整的子系统。一般的汽车电子领域，如果产品用词强调module（模块），而不是强调Sensor（传感器）的话，一般都是指具备各种计算单元和功能的ECU。

另一种是以各种高新科技公司（曾经的高科技公司，应该是泛指计算机技术、生物技术、航空航天技术等领域的高科技，现在的所谓高科技公司应该已经特指各种IT/互联网/软件公司了吧？尤其是在中国），例如谷歌、百度、阿里菜鸟等，采用的AD路线，即自动驾驶路线，主要是以ROS机器人系统为基础、以高精地图技术、人工智能技术、计算机视觉技术的大量应用为特征的L4级别自动驾驶。目前该技术路线主要以Demo为主，也就是基于PC电脑（工控机）的软件来优化打磨自家的软件和算法，并未进行嵌入式化、工业化。该技术路线目前非常偏软件行业，完全不采用传统汽车行业的开发流程和工具链，直接利用自身强大的代码实现能力，以高精地图、全局路径规划、环境感知、定位（RTK、VSLAM）、障碍物预测、局部路径规划、车辆控制等模块，实现各种车辆功能。从业人员多为程序员等软件开发人员，没有复杂的开发人员角色分工。由于L4技术尚未完全成熟，因此高科技公司暂时无法与各种大型Tier1供应商抗衡，目前除了参与乘用车、商用车市场的Demo项目外，也在积极将这种机器人技术用于无人物流车等封闭园区的场景和产品中。严格意义上讲，目前国内科技公司落地的一些无人驾驶物流车等产品，不是大规模量产的真正汽车自动驾驶技术，而是属于消费类的运输机器人，因为这些产品不符合严格的车规，无法落地量产。另外，由于目前大型Tier1财大气粗，担忧在L4技术路径上被新入局者颠覆，也在积极布局自动驾驶技术路线，采用两头下注的方式，一边占领ADAS领域并垄断市场，一边开展AD领域与科技公司积极备战，例如传统Tier1巨头博世，在2017年就开始在苏州大量招聘各种L4级别的开发人员，如路径规划工程师、高精地图工程师、传感器融合工程师等，备战AD路线。而科技公司则由于缺乏深厚的车辆制造经验而放弃ADAS领域，企图在AD领域超越传统Tier1。

综上，为了整合这两种技术路线，命名上方便包含这两种技术路径，最近开始流行“智能驾驶”这个词语，来笼统指代高级驾驶辅助（ADAS）和自动驾驶（AD）。尤其是在各种新造车势力中，内部一般不区分ADAS和AD路线，相关从业人习惯以智能驾驶工程师来称呼。

d. ADAS模块系统工程师、ADAS系统工程师、AD模块系统工程师与AD系统工程师的区别：

最近收到不少猎头的电话，介绍ADAS/AD的系统经理或自动驾驶系统工程师岗位。由于有那么多系统工程师的种类，很多猎头无法准确区分出它们之间的区别，以下做简单澄清。

ADAS模块系统工程师，出身于传统汽车电子行业的Tier1供应商中。这种系统开发人员主要负责如智能前视摄像头模块、前向毫米波雷达模块等汽车零部件产品的需求工程（Requirement Engineering，包括需求分析、需求开发、需求测试、需求管理等需求层面的任务）、产品功能安全（Functional Safety）、产品系统架构开发（System Architecture Design and Test）、产品系统开发（System Design and Test）、产品匹配（Application）、系统验证（System Validation）等工作。控制器系统工程师由于对产品（子系统）负责，因此涉及到的系统范畴较大，强调产品级别的系统，下辖软件、算法、硬件（电子）、机械、制造、匹配、验证等跨学科子模块。主要工作内容包括：对公司外部，作为项目的技术接口人，对接OEM的FOP（Father of part，即零部件负责人，属于德系OEM叫法；也可叫做DRE，即Design Release Engineer，设计释放工程师，属于美系OEM叫法；实质是OEM负责对应供应商产品的产品工程师）；对内，分析来自OEM产品工程师的需求，进行系统架构开发、系统设计开发、系统集成测试、系统测试等系统层面相关工作，并按照Building Blocks（德尔福公司的称谓，其实就是将产品在系统层面上进行分解，分解为各种小系统块儿，便于开发。以智能前视摄像头模块为例，一般Building Blocks大致有30-40多个）编写产品开发文档，将系统需求梳理并固化（文档化），便于开发过程中进行跟踪和管理。另外，由于系统是一个抽象的层面，其设计的落地都要传导至各个具备实物产出的子模块上，（这里所谓的实物产出，是指类似于软件的输出是代码、硬件的输出是电路板、机械的输出是外壳等物理属性的输出物），换句话说，系统的输出物除了产品开发文档，就是产品本身了。因此为了顺利的开发产品，系统工程师天然的作为公司内部的技术项目接口人（Lead System Engineer甚至相当于技术项目经理），主导并推动软件、算法、硬件等子模块的开发，解决各种项目上或技术上的问题。例如，一旦软件开发人员遇到一些非软件的问题，需要跟其他模块（例如硬件）进行交互时，就需要通知系统工程师，让系统工程师作为技术管道，协同其他模块达成Alignment。除此之外，系统工程师也可以直接负责某些具体模块的开发工作，例如直接负责某个feature（ACC、LKA等）的模型开发、测试和标定工作。如下图所示：

ADAS系统工程师，存在于主机厂，这里的系统指整车级别的ADAS系统，貌似很多公司的网络架构人员充当了这个角色），ADAS系统工程师在意的是ADAS相关组件在整车架构上的交互（信息交互、能量交互、材料交互、物理交互）和ACC/AEB/LKA等feature的功能逻辑。例如，在信息交互方面，ADAS系统工程师在意ADAS控制器与其他控制执行器的ECU的交互（例如EPS/ECM/ESP/VCU/BCM），用什么样的通信方式（CAN？CANFD?以太网？）；在物理交互上，在意系统组件的安装位置、安装支架设计、防尘防水等级等；在能量交互上，在意组件的供电方式；在材料交互上，在意组件之间的材料（如高压制动液在油管和主缸之间）的流量、流动方向方式等等。
AD模块系统工程师，其实应该就是特指域控制器系统工程师了。与ADAS模块类似，也可分出很多控制器级别的Building Blocks，只不过它算是一个中央控制器，纯粹的计算单元，没有集成传感器，因此需要雷达、摄像头、激光雷达、高精地图、超声波雷达等这些外围传感器给感知信号。
AD系统工程师，目前大部分自动驾驶初创公司的系统工程师，如谷歌waymo、百度apollo等，应该都属于AD系统工程师，是整车级别的系统工程师，虽然他们都只是Tier1，不造车。AD系统工程师感觉更像（软件）架构师，尤其是在科技公司里的自动驾驶系统工程师。可能是因为IT/互联网科技公司属于软件行业，习惯于用产品经理、架构师、开发工程师（算法、网络、前端、后端、大数据...）等角色划分。

e. SOR/SOW/SSTS/CTS与功能/产品:

SOR, 全称State of Requirement，需求状态。SOW, 全称State of Work, 工作状态。经常作为RFQ（Request For Quotation）的一部分，由技术部门编写，经各部门会签后，由采购部门进行招标定点。其中，SOR强调对产品/硬件/实体的需求，SOW强调软件/算法/服务的需求。

SSTS, 全称Sub System Technical Specification，子系统技术规范，实际是对功能点（feature）的定义。一个务虚的概念。

CTS, 全称Component Technical Specification，零部件技术规范，实际是对智能前视摄像头模块、毫米波雷达模块、域控制器模块等具体产品（零部件）的定义。一个务实的概念。

SSTS与CTS的关系：简单讲，SSTS强调功能（子系统），CTS强调产品（零部件）；功能本身是虚的，它需要一个或几个承载它的实体（产品），换句话说，产品是对功能（或者部分功能）的实现（PS：好像类与对象的关系啊...）。例如，一些复杂的SSTS（ACC/TJA等）功能，一旦要实现这些功能，需要多个CTS（摄像头模块、雷达模块、超声波传感器）参与实现。也有些功能很简单，很小，例如BSD/LCA/DOW等，一个产品（零部件）-侧后雷达模块就可以承载几个功能。

事实上，无论是在主机厂，还是供应商，都是对功能和产品分层定义的。SSTS对应功能层面，CTS对应产品层面。只不过供应商是负责实现产品的，更愿意站在产品的角度看问题，主机厂是负责提供需求的，更愿意站在功能角度看问题。

上文中有提到，底层算法（检测算法）与应用层算法（功能/功能点/feature）会区分开来对待，其实很大一部分原因，也是在于汽车行业对产品与功能进行分层处理导致的。由于OEM强调功能，在与供应商合作过程中，无形之中就把应用层算法（功能/功能点/feature）提高一个等级来强调。

事实上，国外的很多主机厂，早已开始自己使用MATLAB/Simulink来开发应用层算法（就是功能/功能点/feature），例如奥迪、福特、通用等。这是因为功能与客户体验、车辆performance等产品竞争力息息相关，主机厂愿意自己把控；开发完成后的模型，会释放给供应商，供应商负责将产品（零部件）的其他各个Building Blocks打造好后，并将主机厂提供的模型生成autocode（自动代码），集成到产品的软件中，最后将具备完整功能的产品供货给主机厂。

三、写ADAS/AD开发系列文章的动机

在知乎上看了不少关于智能驾驶的文章，但是多是一些IT行业从业人员写的关于L4智能驾驶Demo的开发，更多的是在介绍一些核心算法的开发，例如人工智能、深度学习、感知、定位、规划等。但是不管怎么发展，智能驾驶总要从Demo走向量产；总要从工控机变成嵌入式ECU；总要从只实现核心算法到满足功能安全要求。因此我想从汽车电子产品的角度，按照V模型的开发流程，分享面向量产的智能驾驶产品（智能前视摄像头模块、智能驾驶域控制器等零部件级别）的开发细节。

四、展望

一方面，就目前来看，智能驾驶还是汽车行业的传统势力占优势，如通用、大众、丰田、博世、大陆、德尔福等一众传统OEM和Tier1。毕竟整个车辆的研发、生产体系是它们建立的，而且技术积累也非常深，工程能力非常强。这里的工程能力可不光指软件工程，是整个汽车工业的工程能力，如制造能力、机械工程能力、电子电器工程能力、软件工程能力、安全工程能力、成本控制能力，质量控制能力、系统集成能力等等等等。

另一方面，也有汽车行业的颠覆者存在，如特斯拉。特斯拉作为典型的科技行业代表，经常与谷歌、苹果、亚马逊等科技巨头相提并论。它的造车就有很多创新之举，且作为中国各种造车新势力的偶像，被不断提及。但即便是这样，特斯拉到现在还在产能问题上出现各种各样的问题，这就是制造能力的瓶颈啊！但是不管怎么样，还是期待科技公司利用电动车的机遇，绕过传统内燃机无法逾越的技术壁垒，挤入赛道，并弯道超车，利用科技改变汽车行业，利用代码和软件重写百年汽车。希望谷歌、苹果、亚马逊、BAT等公司，能够成功的从第三产业（科技服务业）的IT行业向第二产业（工业）过渡，重塑整个汽车的架构，例如，可以骑车的软硬件彻底分离，将车身、底盘、电池、动力电机、转向、刹车等机械、液压件彻底机电一体化（Mechatronics）、线控化（X-by-wire）、模块化；将各种ECU电子控制器和信息娱乐ECU集中化简，形成几个甚至一个中央控制器（大型工控机？？？），用以控制机械件等执行器，形成电子件集中化；优化通信架构和系统架构，减少车身线束；软件集中部署在中央控制器中，与机械件和电子件解耦，像一个普通台式机一样，便于迭代开发新功能。

2018年10月31日更新：by 小阿狸

汽车电子领域中的"车规级"描述

什么叫车规级？简单说，就是汽车电子的硬件（不包含软件哦）要满足AEC-Q100，AEC-Q101和AEC-Q200的标准规范。这里的AEC是指automotive electronics council，汽车电子委员会。

ADAS/AD控制器模块开发01 - 行业背景、基本概念名词介绍相关推荐

ADAS/AD控制器模块开发11 - UDS与配置、校准
前言本文讲下与UDS相关的Configuration模块和传感器Alignment模块. Configuration模块即配置模块.什么叫Configuration?即在软件构建过程中,那些能够控制 ...
ADAS/AD控制器模块开发14 - ASPICE流程
前言相信每个从事汽车电子开发的人都会有这样的心路历程:1.刚毕业时,懵懵懂懂的进入公司,跟着公司的培训走,了解自己岗位的内容,以及与其他岗位的交互,还要熟悉V模型开发流程:2.工作几年后,睁开眼睛看 ...
电气simulink常用模块_ADAS/AD控制器模块开发：产品构成要素及产品需求
一.常用缩写: 为了方便描述,以后对下列名称用行业内通用缩写代替: 系统构成要素 - Building Blocks - BB 产品开发文档 - Product Development Documen ...
【读书笔记】AUTOSAR规范与车用控制器软件开发01
ECU(Electronic Control Unit)电子控制单元:汽车专用微机控制器汽车开放系统架构联盟(AUTomotive Open System ARchitecture,AUTOSAR) ...
网站流量日志数据分析系统（模块开发----数据仓库设计）
1．维度建模基本概念维度建模(dimensional modeling)是专门用于分析型数据库.数据仓库.数据集市建模的方法.数据集市可以理解为是一种"小型数据仓库". 维度表 ...
最详细的golang + 私库（gitlab gitee）模块开发这一篇文章解决所有问题
golang独立模块开发流程大纲基本概念与背景模块开发流程总结基于gitee私库基于gitlab私库基本概念与背景 java项目开发过程中,有不同的项目组,有的项目组做业务开发,有的项目组 ...
面向ADAS/AD应用，打造独特的转向手感
文章目录 MXsteerHiL的主要特性 MXsteerHiL 针对以下测试环境进行的优化和验证手动驾驶: 辅助和自动驾驶: MXsteerHiL-软硬件接口信息 MXsteerHiL的模块化设计 ...
ADAS/AD 系统验证方法及策略(dSPACE解决方案)
1.ADAS/AD系统校验概述 ADAS/AD研发面临的挑战从level2到level3/4的ADAS/AD功能评估: 更复杂的功能化,针对多控制器.深度学习技术,和验证单组件和模组间的交互: 百万 ...
LD3320语音识别模块开发
达者为先师者之意 LD3320语音识别模块开发 1 LD3320语音识别模块基本参数 1.1 基本参数 1.2 识别原理 1.3 解决方案: 2 LD3320语音识别模块二次开发 2.1 源码修改 ...

ADAS/AD控制器模块开发01 - 行业背景、基本概念名词介绍

ADAS/AD控制器模块开发01 - 行业背景、基本概念名词介绍相关推荐

最新文章

热门文章