【V知】汽车电子-从零开始的知识拼图-1基础构建

从零开始的知识拼图

• 小白扫盲式快速科普
• jigsaw puzzle：拼图游戏
• 

E/E系统的前世今生

• E/E系统：电子电气
• 汽车系统：从没有E/E，到引入ECU并逐渐增多，到ECU通信，交互，网络引入，诊断、标定、智能化等
• 

ECU

• 概念：
  • ECU: electronic control unit 电子控制单元
  • HCP: high-performance computing platform，高性能计算平台，汽车的新一代ECU
  • MCU: microcontroller
• control: 控制
  • 一门工程学科，目的是达到期望的性能水平，通常通过应用规则实现。
  • 规则：how/when -- works；转换值(车轮转速换算为车速)
  • 各种小的控制系统集成在一起：ECU
• 认识ECU:
  • I/O:
    • 输入：特殊硬件，可以将电信号（电压或电流）转换成数字信号
    • 输出：特殊的输出电路，可以接收数字信号，并产生电流或施加电压，使车辆发生变化
  • 共享数据：
    • 使用网络（总线），和其他ECU共享（数字化）数据
• ECU硬件：
  • ECU内部图示，所有电子连接都通过接插件（PIN）
  • 
• ECU软件：
  • 基础软件 BSW：
    • 类似windows/Linux的操作系统
  • 应用软件 ASW or application：
    • 在基础软件之上，并通过基础软件和硬件交互
    • 控制ECU运行的功能
  • RTE(run time environment)：
    • 存储运行时常用数据，如车速、各种温度等，防止重复计算
    • 作为 BSW 和 ASW 交互的桥梁，为 软硬件解耦 提供了可能
    • RTE 实现了软件组件之间、基础软件之间、软件组件与基础软件之间的通信
      • RTE封装了基础软件层的通信和服务
      • 为应用层软件组件提供了标准化的基础软件和通信接口
      • 使得应用层可以通过RTE接口函数调用基础软件的服务
    • RTE 抽象了ECU之间的通信
      • RTE通过使用标准化的接口，将其统一为软件组件之间的通信
      • 由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现

汽车网络的来源

• 网络在汽车中的作用：
  • 可以减少线束
  • 网络协议允许ECU快速、精准地共享数据，降低未检测到错误的风险
    • 抗干扰：发动机的点火系统会产生电子干扰，可能会影响敏感的电子设备
    • 数字信号可以自动检查和纠正某些故障（错误）
  • E/E系统中，ECU通过网络实行串行通信
    • 串行通信：只有一个"流stream"，一次只做一件事
    • 实现：网络/线束上的电压 --> 二进制0/1
• 不同类型的网络：
  • CAN: 1 Mbps，如今还在广泛使用中
  • LIN: 20 kbps，CAN成本高时的低速、便宜的选择
  • FlexRay：10 Mbps，比CAN更快的超高速、实时网络
  • Ethernet以太网：100Mbps，海量数据，高速
    • 首先用于娱乐系统：音频、视频等
    • ADAS系统：海量的视频、雷达、激光雷达数据
  • based on：
    • 基于信号：CAN/LIN/FlaxRay
      • 将信号发送到网络上，不管是否有ECU需要
    • 面向服务的架构(SOA)：以太网
      • 需求方 向 提供方 发送请求，从而获得数据
      • “临时性网络”，可以更容易添加新功能
• 不同网络：通过网关连接在一起
  • 网关：从一个网络中选择数据，并将其转发到另一个网络中

汽车诊断

• 医生问诊 到 ”汽车问诊“
  • requests and responses
• 汽车诊断标准化：
  • OBD标准化问答
  • UDS, ISO 14229-1 (Unified Diagnostic Services)
    • 定义了requests/responses的结构
    • 但由 汽车供应商 定义结构中具体的内容
  • SAE J1939:
    • 另一套标准，供卡车、挖掘机、公路机械、农用车辆等的诊断使用
• 诊断的功能：
  • 诊断能做的事情：
    • 读数据(序列号、零部件号、SW version等)/写数据；
    • 读/复写ECU IO，来查问题；
    • 运行某特殊功能：如打开付费功能、查特殊情况下的问题等。
  • 诊断的重要性：
    • 诊断涵盖了车辆生命周期中的大部分过程，以及大量数据
    • 诊断设计时，需要考虑很多事情：
      • 可能的故障、用到的数据、汽车生产时想做的事情；
      • 诊断对硬件设计和软件设计的影响都很大
• 故障存储/DTC
  • 故障存储 Fault Memory: ECU存储检测到的故障
  • 诊断故障代码 DTC(Diagnostic Trouble Codes)
• ECU在诊断中做了什么：
  • ECU的诊断功能由基础软件和应用程序提供：
    • BSW：负责网络连接和故障存储；
    • ASW：监控功能，以及其他需要的功能
  • BSW接收诊断请求，然后发送诊断回复；
  • 诊断实现需要ECU的硬件支持；
  • ECU升级软件：
    • 用到USD，以及ECU软件中的一个特殊部分--FBL(flash Bootloader)

汽车标定

• 标定
  • 一般标定：
    • 将测量值与标准值进行比较的行为
    • 比较，但不包括任何的后续调整
  • 车载开发中的标定：
    • 默认包括调整的，一般称为"测量与标定"
    • 观察测量值，并进行调整
• 标定的作用：
  • 汽车生产的平台化：
    • 为每个车型开发独立组件是非常昂贵的
    • 不同相似车型，通过平台化实现设计和工程的共享，保证主要部件在多个车型通用
  • 不同车型：需要个性化设置某些参数等
• 标定协议：
  • CCP: CAN Calibration Protocol
  • XCP: Universal Calibration Protocol
    
• 标定实现：
  • 示例1-测量ECU内存的方法
    • 标定工具发送信息，CCP指向一个地址，从memory获取数据后，传回标定工具；
    • ECU的定时器：可以实现将数据重复传送给标定工具。
    • 其他功能：通过标定工具修改memory中的数据，等。
      
  • 示例2-通过振幅改变正弦波的值
    • 在窗口中写入不同的ampl值，将其写入ECU，观察正弦波的值的变化
      

AUTOSAR

• ECU开发标准化的必要性：
  • 汽车开发的标准化：除了诊断和标定，其他都不太统一；
  • ECU开发没有统一标准，迁移困难
• AUTOSAR的不同含义：
  • AUTOSAR开发搭档：
    • development partnership
    • AUTOmotive Open System ARchitecture开发搭档
    • 一种用于汽车电子系统的开放式架构，允许不同厂商的硬件和软件组件相互兼容和互操作
    • 由汽车制造商和主要供应商成立工作组，为ECU软件开发一套标准规范
  • AUTOSAR规范和软件
    • 规范首发于2005年，首项目于2006
    • AUTOSAR也指符合规范的软件，eg.AUTOSAR Classic 4.3
  • AUTOSAR方法论
    • 定义了过程(开发流程)、工具、(工具使用的)文件格式
    • AUTOSAR文件格式：AUTOSAR XML，简称ARXML
• AUTOSAR软件结构
  • 分层结构
    • 整个AUTOSAR都是基础软件，是堆栈的结合体
    • 每个区域都可以细分为模块，每个模块都定义了功能和接口，即AUTOSAR的关注点分离
    • AUTOSAR Classic Platform有超过100个模块
      
      
  • 版本：
    • 4.4后，从X.Y变为A-B，A年份，B月份
    • AUTOSAR Classic Platform / AUTOSAR Adaptive Platform
• AUTOSAR方法论简化版：
  • 定义 功能 及 交互
  • 描述每个功能所需的SWC (software component)
  • 将SWC分配给ECUs，并描述网络如何将它们连接起来
    • 系统描述(system description)
  • 即：定义软件组件，分配给ECU，添加网络
    • 每个软件组件只与RTE通信
    • 所有的数据共享都通过RTE实现
    • 从而拥有可移植的应用程序。
  • 小结为：
    • AUTOSAR向下实现了ECU的软硬件解耦
    • 通过无数接口连接ECU，构建一个标准化RTE环境，让ECU数据在这一层共享
    • 开发者只需要描述应用，就能实现新功能的开发
      
      

更新ECU软件

• ECU软件组成：
  • 前面介绍过的：基础软件、RTE、应用程序
  • FBL(Flash Bootloader): 特殊软件，启动/重启ECU；更新软件
    • 大多数情况下：FBL检查ECU软件主程序，并跳转到主程序 (ECU开始运行)
    • 很少的情况下：刷写ECU软件
  • ECU刷写的必要性：
    • 开发过程中的刷写：功能变更或引入新功能，或者标定参数的修改
    • 车辆销售后的刷写：修复bug等
    • FBL和刷写工具一起提供了通过车载网络修复问题软件的能力，而无需取出ECU
      
• FBL刷写
  • ECU软件存储在NVM(非易失性内存)中：
    • NVM不会在ECU断电时丢失数据
  • FBL提供诊断服务：
    • 允许整个NVM被擦除和重写(刷写)，可以通过车载网络实现
    • FBL会对写入NVM的数据进行确认 verify
  • FBL刷写时会擦除NVM中的数据：
    • 需要先将数据读取并存储，然后再写回，否则存储的数据会丢失(如配置数据等)
  • 需要在刷写前跳转至FBL
    • ECU主程序在运行过程中不能进行软件刷写
    • ECU在刷写时会处于异常状态：原则上不能一边开车、一边进行ECU刷写
  • 内存驱动程序：
    • 对NVM进行操作的软件
    • 并不是FBL的一部分，而是在刷写过程中下载到ECU中
• FBL刷写的鲁棒性
  • FBL必须按照规定的顺序执行，如果顺序不对，ECU会变板砖。
    • 板砖修复：需要把ECU拆下来，换一个新的，非常贵。
  • 鲁棒性很重要：汽车制造商会定义精确的顺序、数据格式、及其他要求。
    • FBL规范实际上是汽车制造商的私有规范。
  • 刷写时需要满足一些稳定的条件：
    • 保持电压稳定：如果电压不稳定，FBL将拒接刷写请求
    • 其他：车辆静止；变速箱处于P档位等。
• OTA: Over-The-Air updates
  • 对车辆(ECU)进行远程刷写
  • 为保证OTA的鲁棒性，ECU需要使用冗余的存储空间：2倍或3倍的存储空间
  • 轮流对2个存储空间进行刷写：
    • 假设有2个存储空间：空间1负责运行程序，空间2进行刷写
      • 空间2失败也没关系；可以在空间1运行时刷写空间2；
    • 当空间2刷写完成并通过验证，则进入激活状态，并在ECU启动时被使用
    • 下一次刷写时，将对空间1进行刷写
    • 注：以上在后台或MCU上进行。
  • 不同的OTA策略：
    • OTA时，经常需要最小化传输的数据，可以节约成本；当把内存驱动程序放在FBL时则需要更多空间
    • 不同OTA策略：
      • 或不要求FBL包含内存驱动程序；
      • 或不需要冗余存储
• FBL的其他功能：提高刷写速度、防止软件被篡改
  • 允许管道刷写 pipeline program：即对NVM进行写操作的同时接收数据
    • 传统的FBL：从网络获取数据并存储在本地，当一组数据完成接收后，开始写操作；
    • 写操作完成后，传送下一组数据。
  • 允许管道验证 pipeline verification：在接收数据或者将数据写入NVM的同时进行验证
    • 传统验证：在所有数据的写操作完成之后，进行验证
  • 实时解压缩 live-decompression：
    • 进一步加速，将数据压缩后传给FBL
    • FBL实时解压缩，将接收到的压缩数据解压缩后写入NVM
  • 身份验证 authentication：
    • 为保护刷写过程，进行身份验证，防止未经授权的软件更新。
  • 实时解密 live-decryption:
    • 防止他人窥探或监视更新包，试图对更新包进行逆向工程，找出其中的内容
    • 将加密数据传输给FBL，FBL在将数据写入NVM之前进行实时解密
  • 安全启动 secure boot：
    • 计算主程序的签名，并将其存储在ECU内的安全存储中
    • ECU每次启动时，都会重新计算签名并进行对比，判断软件是否被篡改；如被篡改，ECU将阻止启动。
  • （以上几点也是vector可以提供的一些高级刷写服务）

HPC

• 高性能计算机：high-performance computing platform, HCP or HPC
  • 必要性：满足 以数据为中心的处理需求
    • 汽车发展方向是自动化，终极目标是基于评估车辆环境的能力的自动驾驶
    • 这就需要并行执行，以及快速处理大量数据
    • 例如：根据来自雷达、摄像头、视频流等的数据，进行识别和预测
  • HPC：
    • 利用硬件实现并行处理/执行，以及高宽带网络与动态通信的结合
      
• 以数据为中心的处理需求 Data-centric processing
  • 某些常见的车辆环境可能需要非常快速的数据评估
  • 当需要快速处理大量数据时的硬件要求：
    • 需要连接到高宽带网络（如以太网），以便收发数据
    • 需要大内存，以便处理数据时保存数据
    • 可能需要GPUs来处理数据：Graphics Processing Units
      • GPU将任务分成数千个部分，然后并行执行
• HCP开发板展示:
  • 更高速的网络接口：千兆以太网，比ECU快十倍
  • 更多的核：GPU有256个核，ECU只有一个单核
  • 更大的内存：HPC 8G存储，支持每秒50G读写，ECU只有几百k
  • 更少的输入/输出接口：20个IO口（ECU有70个IO）
    
• 处理更复杂的数据环境：
  • 当处理涉及到车辆环境的数据时，信号会变得复杂
  • 需要与很多不同 objects的不同属性 进行通信
  • 动态的、面向服务的通信
• ECU仍需存在的意义
  • 不同需求：以数据为中心的处理需求 or 以硬件为中心的处理需求
  • ECU的优势：
    • 针对处理简单数据/简单任务进行优化的，优势在于处理传感器和执行器
    • 以硬件为核心，为软件提供与汽车硬件交互的方式，例如开关、灯等
  • ECU不会被完全取代：
    • 一辆汽车可以同时拥有HCP和许多ECU
• POSIX:
  • IEEE标准，Linux兼容POSIX标准
  • HCP软件：运行在POSIX环境
  • AUTOSAR Adaptive Platform能够在POSIX操作系统上运行
  • ps: ECU使用AUTOSAR Classic Platform

AUTOSAR Adaptive platform

• 嵌入式软件工程的运行方式：
  • 在ECU内部，以软件形式存在的功能或任务按照预定的调度表周期性运行
    • 这意味着，任务task 按照 调度表schedule 周期性运行
  • IO: 当任务运行时，检查相关输入，并根据输入控制输出。
  • deadline：任务必须在规定时间内执行
    • 任务调度表和截止时间通常以 ms毫秒 为单位
    • 电机：微秒us 为单位
    • 任一项任务超时，将导致所有任务超时
  • 硬实时：hard real-time
    • 通过可预测的执行来满足严格时间限制的需求
    • 硬实时行为：意味着没有任务可以错过deadline
    • AUTOSAR可用来帮助实现 硬实时
      • 此外需要做的：调度表和高效编程等，以确保满足deadline
• ACES:
  • 自动驾驶，互联(物联网)，电气化(新能源)，共享(共享汽车和共享数据)
  • OTA是互联、共享的一部分
    
• HCP与ACES:
  • HCP是高性能计算平台，为汽车提供ACES功能
  • HCP软件运行在POSIX环境，如linux
  • 运行AUTOSAR CP的ECU
    • AUTOSAR CP提供硬实时行为
    • ACES处于更上一层，通过动态的面向服务的通信提供其他功能
      
• AUTOSAR两种平台
  • 简称为AUTOSAR CP/AP
• 不同功能需求：
  • AP：为满足未来汽车所需的ACES功能需求提供算力
  • CP：将继续存在于汽车中，以满足ACES功能以外的硬实时需求。
• 不同的操作系统状态：
  • AP：依赖POSIX操作系统
  • CP：本身包含操作系统
• 不同的应用程序运行状态：
  • AP：应用程序作为独立进程运行
    • 可以动态加载/卸载，动态安装/删除，无需重启
    • 可以单独对每个应用程序做任何事
  • CP：必须完全停止所有应用程序 (软件)
    • 例如传统的ECU软件更新 (FBL)，
    • 所有应用程序全部停止后，Bootloader接管权限并刷写
• 不同的base和语言
  • AP：
    • 基于面向服务的通信 和 面向对象的语言(C++)
    • 为应用程序访问提供ARA
    • 允许使用高级功能库，如ACES所需的目标识别
  • CP:
    • 基于信号/服务的通信 和 面向过程的语言(C)
• 不同的运行时：RTE和ARA
  • CP：应用程序运行在RTE之上
  • AP：
    • 定义了API，应用程序通过API访问HCP中的功能集群以及AP服务
    • API和AP服务：为应用程序提供AUTOSAR运行时（ARA）
    • ARA由可以访问功能集群的API和Adaptive平台服务组成
• 不同的platform：
  • CP：定义了超过100个模块，包括行为，彼此交互通信等
  • AP：只规定了API
• 功能平台和功能集群 functional platform/cluster
  • 功能集群：一组相关的功能
    • 例如访问网络数据（收发数据）
    • 在本地保存和检索数据（persistence）
    • 当出现问题时执行内部记录（日志logging）
  • 平台服务：
    • 提供一种标准化的方式来访问AUTOSAR AP提供的功能
      

汽车E/E系统发展历程

• 到1990s：
  • 从没有ECU，到加入ABS，到加入简单ECU控制牵引力等，到引入CAN总线
    
• 到early 2000s：20世纪早期
  • 可以连接到单条CAN总线上的数量有限--引入网关
  • 网关：将单条CAN总线变为多条，从而减少单条总线上的ECU和数据量
    • 网关的作用：在不同网络/总线之间传输路由数据
      
• 到20世纪中期：
  • 新的ECU和新的总线出现
    • 如：FlexRay用于高级底盘控制，包括电子悬架控制和电控转向
    • 如：LIN用于智能组合开关，牵引力开关等
      
• 到20世纪末：
  • 许多ECU开始使用AUTOSAR CP
    
• 到2010s初：
  • 触摸屏出现，娱乐系统，图片、动画等
  • 以太网出现：缩短软件更新时间，提高视频等传输速度
  • DoIP(Diagnostics over Internet Protocol)：缩短下载时间
  • OBD法规要求：保留CAN，即使以太网诊断速度更快
    
• 小结前期的E/E系统
  • 越来越依赖网络通信，使软件更容易共享数据
  • 汽车网络：通过数据共享获得新能力的推动者
  • 不同的汽车网络（CAN/LIN/FlexRay/以太网）为汽车E/E提供所需的功能
• 到2010s的中后期：
  • 开发混合动力汽车，需要传输更多数据
  • FlexRay和多条CAN总线组成的系统已经达到极限
  • 以太网出现，网关变为多层交换机
  • 若干独立的功能被集成到更大的执行平台上，即(功能)域控制器
    • 域控制器：通过以太网连接到交换机
  • 以太网成为系统的骨干网络：
    • 通过以太网连接多个交换机的级联交换机架构
  • 功能转移到域控制器，ECU数量下降到100个
  • 不同的域控制器负责不同的域：
    • 底盘域：通过FlexRay连接底盘系统的其他ECU
    • 混动域：发动机管理和变速箱控制，以及通过CAN连接的电池管理、充电、电机控制
    • 娱乐域：触摸屏，包括视频、音频等
    • 车身域：
      • 通过LIN连接：开关和智能执行器，如车窗、挡风玻璃、雨刷的电机，无需太多线束
      • 通过CAN连接：车门ECU等
    • 域控制器通过线束连接到传感器、执行器和其他ECU
  • 非常现代的ECU架构图：
    
• 2020或如今：将面向服务的通信 SOA 引入域控制器
  • 继而引入运行AUTOSAR AP的HCP
  • 域控制器和其他ECU运行AUTOSAR CP
  • HCP和ECU协同工作：
    • 域控制器连接 面向信号的世界(CAN/LIN/FlexRay)和面向服务的世界(AUTOSAR AP)
    • HCP实现例如离线预测车轮侧滑的反应系统
      • 预测本车，并通过后台计算机共享给其他汽车
        
• 展望：到2020s中期
  • 线束过多、硬件限制导致的功能变更困难等
  • 解决方案：将车辆划分为若干拓扑区域
    • 配备区域控制器，并通过总线连接IO(输入/输出)和少量ECU
    • 交换机放在HCP中
    • ECU(专用硬件)用于完成特定任务
      • 车辆前后、或每个车轮都有电机控制器(M1/M2)
    • IO节点：采集数据和执行输出
      • 节约大量线束，提高灵活性
    • 更多的通用硬件：标准化/商品化硬件
      • 用于HCP/区域控制器/IO节点
    • 加速了SDV(软件定义汽车)的发展
    • CAN依然存在：CAN XL, 10M/s，更快，传输更长的帧
      • 与以太网有一争之力
        
• 展望：到2020s后期 SDV
  • 一旦建立可靠的data-link来连接离线计算资源
    • 汽车或成为 物联网(IoT) 的一部分
    • 之后，越来越多的功能可能会放到云端执行
  • 如果通过数据链接来连接灵活的离线计算与通用硬件：
    • 通用机载硬件：HCP/区域控制器/IO节点
    • 而不是由专用硬件(如ECU) 提供固定功能
    • 有望：实现SDV-软件定义汽车
    • 意味着：汽车的功能可以在汽车生产之后继续变化和发展
• 小结：
  • E/E系统变得越来越软件化
    • 变化越来越明显
    • 汽车网络正在推动这一发展，尤其是汽车以太网
      • 解锁了很多新能力让汽车以全新的方式运行
  • 未来的汽车可能和如今的截然不同：
    • 等待一个技术爆炸
    • 区域控制器、HCP、IO节点：
      • 可能从根本上改变汽车的设计、开发、维护方式。
    • 汽车制造商OEM和供应商supplier之间的关系也可能完全改变
      • 从专用硬件 变为 (基于标准化硬件的)普通商业采购模式

参考链接：

• B站：vector知识充电-合集
  • "从零开始的知识拼图"到"汽车E/E系统发展历程2"

END