【V知】汽车电子-从零开始的知识拼图-2

汽车为什么需要功能安全和网络安全

safety and cybersecurity
- 保证车内和车外人员的安全
- 每年有数百万的人死于/受伤，因为道路交通
  - 车辆E/E系统的不良行为是原因之一
车辆E/E系统的安全提升：
- 正常运行和误用时：通过SOTIF提高系统的安全性
  - SOTIF：safety of the intended functionality
- 故障发生时：通过功能安全提高系统的安全性
- E/E系统变得不安全：
  - 可能通过网络攻击泄露机密：黑客攻击、窃取信息等
  - 在设计时考虑网络安全，可以缓解和管理这类问题
ISO发布了很多功能安全和网络安全相关规定

为什么需要“可追溯性” traceability

工程：
- 充分理解问题，并制定合适的解决方案，以解决问题
- 开发解决方案的过程：以数学和科学为基础
- 工程的成果：技术、机器(汽车和计算系统)、结构、过程
探索和理解 problem：
- 拆解问题：大问题拆成小问题，重复多次拆解
- 子问题：关注what/where/who/when, not HOW
- 理解子问题之间、父问题与子问题的关系：可追溯性的一个方面
解决：HOW
- 每个子问题的答案是整体解决方案的一部分
- what和how之间、以及how彼此之间的联系：可追溯性的另一个部分
可追溯性：解决复杂问题时的重要部分
- 对于解决问题的方案探索：
  - 可追溯性：使能判断是否已经完全解决了问题
  - 如对问题的理解发生变化，可追溯性帮助完善解决方案
- 对于变更：
  - 发生变更的原因：包括变更原因、发起者、执行者
- 可追溯性在问题解决
  - 不仅拥有从问题到解决方案的路径
  - 还可以对解决方案的每个部分问为什么
具体的解决问题和可追溯性：
- 正确分解子问题：
  - 测试每个单独的解决方案，以确保子问题被完全解决
  - 可追溯性的一部分：将测试结果与相应的子问题联系起来 (虚线部分)
- 对于车载系统：从问题到解决方案是分层的
  - 车载系统由子系统组成
  - 子系统由组件组成：ECU/线束/保险丝盒等
  - 这些组件由更多的组件组成
  - 每层中：之前的解决方案成为需要解决的新问题
  - 可追溯性：
    - 需要在问题和解决方案的多层之间有可追溯性
    - 最终判断最低层的解决方案是否满足最高层的问题
    - 问题最终变成一个基础科学问题：如物理或化学
vector家族产品
- PREEvision：
  - 开发车辆E/E系统的数字工程平台
  - 可以在整个项目中建立完全的可追溯性
- vTESTstudio and CANoe：
  - 通过测试实施和测试结果跟踪测试需求
- CANoe.DiVa：
  - 针对ECU的诊断部分生成测试用例
  - 确保ECU诊断的正确实现，并为此提供证据
- VectorCAST：
  - 面向软件系统和单元测试
  - 其结果可以链接到软件的原始目标
- Squore：
  - 将项目流程可视化，从而提供可追溯性
- vCDM and vCDMStudio/CANape：
  - 在标定变更中建立可追溯性

网页接口 web-interface

本期：介绍可以提供网页接口的技术
互联网：
- 客户端client 和服务器server：
  - 发送请求，数据返回，这就是互联网
- 后台：客户端使用HTTP从服务器请求数据
  - HTTP：超文本传输协议 Hypertext Transfer Protocol
  - 请求和响应的数据几乎都是基于文本的
  - 为防止被窥探，通常使用TLS，即HTTPS (HTTP-secure)
    - TLS：传输层安全技术 Transport Layer Security
JSON: JavaScript Object Notation
- text-based, human-readable
- 允许在软件中使用基于文本的对象描述传输
- 面向对象的数据传输，即紧凑又易于处理
REST-API (REpresentational State Transfer)
- REST：表示请求中所包含服务所需的所有信息
- 服务器不需要记住过去的任何事，所需信息都在请求中
- 可以同时为来自许多客户端的许多请求提供服务
查询天气时，JSON返回格式
- 返回的数据可以供其他程序或软件使用
与车辆相关的网页接口

诊断数据-诊断开发流程

诊断协议是实现流程自动化的一种方法
- 诊断协议：OBD/UDS
- 自动化什么：一系列流程
- 系统组成：汽车、测试工程师、测试仪
诊断可以从3个视角描述
运行视角：operative perspective
- 考虑系统需要实现的所有目标
- 涵盖了系统在车辆整个生命周期内的一切事情
  - 从进行调试的开发阶段，到实现正确装配的生产阶段
  - 使用和维护过程中，要确保检测到故障并进行维修和更新
  - 此外，需要处理或删除敏感数据(用户ID/密码等)、危险装置(气囊里的小型爆炸物)
- 运行视角的一个重要部分：
  - 确定具体任务涉及的 参与者和做了什么
  - 例如：测试仪可与ECU交互，而工程师的可机动移动性
外部视角：（人类视角）
- 期望测试仪和车内ECU共同完成任务
- ODX：连接诊断仪和车内ECU的诊断接口
  - 标准化数据格式ODX：Open Diagnostic data-eXchange
  - 用于描述测试仪与车辆之间的通信
  - 允许测试仪自动加载一个或多个ECU数据
  - 具体到某个项目，可通过ODX加载并传输大量数据
    - 导致ODX文件庞大且复杂，不易被理解 -- 谨慎使用ODX
  - 当把诊断仪连接到车辆，做诊断操作时 -- ODX非常有用
内部视角：（ECU视角）
- ECU内部是如何进行诊断的
- AUTOSAR规定了内部视角的标准化：DEXT
  - DEXT：AUTOSAR Diagnostic Extract
  - DEXT可以描述诊断请求/响应中的信息与ECU软件的相互关联
- ECU软件描述是AUTOSAR系统描述的一部分：
  - AUTOSAR系统描述是一个单独的文件 SYS-D
  - AUTOSAR系统描述还包括ECU/车辆的网络通信
  - 通常，在DEXT中引用SYS-D，而非复制
- DEXT引用机制
  - 引用AUTOSAR系统描述中的软件/网络信息
- DEXT并不包含单个ECU所需的全部信息：
  - DEXT是一种补充格式，不是完整的独立格式
标准化数据格式实现流程自动化：
- 外部工具测试仪：可以使用ODX自动加载数据
- ECU配置工具：可以从DEXT中自动加载信息，从而配置ECU软件
- 标准化数据格式的设计目的各不相同：
  - 但其实是从不同角度处理同一个问题
  - 这些不同的标准版数据格式无法相互替代
vector的CANdelaStudio
- 采用用户友好的方式，创建/提供诊断的外部和内部视角
- 提供标准化的数据导出
  - 从单一信息源生成ODX和DEXT，从而保证数据同步

ODX

ODX：Open Diagnostic data-eXchange
- ODX: ISO 22901-1
- Exchange：是指诊断仪的参数化
  - 包括诊断仪如何向技术人员展示信息
- ODS定义了多个类：category
  - 每个ODS类与诊断仪需要的一类数据相关联
    - 注意：不是必须使用标准定义的所有类
  - 1个ODX文件：只能包含一个类
ODX常用的类：
- 按照使用的普遍程度排序的ODX类：
  - ODX-D, ODX-C(子集CS), ODX-V, ODX-F, ODX-E, ODX-FD
- ODX-D：诊断相关
  - 对应诊断数据：如诊断仪或ECU发送的请求/响应
  - ODX-D：将请求/响应按照数据流逐个字节进行描述
  - ODX的结构：会对诊断仪展示的内容有影响
- ODX-C/CS：通信相关
  - communication parameters
  - 诊断协议中需要指定的一些值，如定时器或超时
- ODX-V：车辆信息相关
  - vehicle information
  - 两个ECU时：测试仪可通过两个不同的总线技术进行访问
    - 测试仪需要知道使用哪个总线(接口)与哪个ECU通信
- ODX-F：刷写相关
  - software updated (flash) information
  - 更新ECU软件，保存相关刷写信息(如兼容部件号)
  - 注：刷写脚本并不属于ODX-F，必须单独定义
    - ODX-F只需要告诉诊断仪插入到这些请求中的数据
- ODX-E：ECU配置数据
  - ECU configuration data
  - 诊断仪向ECU写入预定义的配置信息，如英里or公里，左驾or右驾
- ODX-FD：
  - function-oriented diagnostics
  - 不同ECU有不同的诊断：
    - ODX-FD将诊断功能与不同ECU的不同功能关联在一起
ODX对信息进行统一定义的机制
- 可以在ODX文件之间和内部进行链接、继承、引用
PDX：
- 1个ODX文件只能包含一个类
  - 但在分发ODX时，希望一个文件包含所有信息
- packaged ODX, 能够包含不同的类的容器
- 包括：ODX文件和索引index
AGL：authoring guidelines
- 必要性：
  - PDX的规模扩大，数据量巨大；ODX功能强大的同时使数据复杂
  - 当需要同流程伙伴合作，或者企业或部门之间数据交换时
- AGL有助于限制标准的复杂性，提高可用性
  - 测试人员不必理解全部标准
  - 只需选择需要支持标准的哪些部分
- checker检查器
  - 配合AGL，以确保工作成果符合AGL
vector工具
- CANdelaStudio：
  - 诊断数据库（遵循诊断规范的）编写工具
  - 可以导出与诊断规范相对应的ODX
- ODXStudio：
  - 成为格式和协议专家，并使用ODX的原生形式
  - 直接在ODX数据模型中处理ODX数据

网络协议

网络协议的不同寻址方式 (addressing)
- 协议：
  - 请求或传输信息的一种形式化方式。
- 单播 unicast
  - one to one，只与一个人对话
- 组播 multicast
  - one to many，和一组人，但不是全部人对话
- 广播 boardcast
  - one to all, 与所有人对话
OSI/OC模型
- 开放系统互连模型 open systems interconnect
- 不同层有不同的目的
  - 5 6 7层可合为一层
- 应用层：application layer
  - 软件/应用程序直接与之交互，提取数据等
  - 应用层不是应用程序本身的位置，而是应用程序使用的协议
  - eg. HTTP协议
- 表示层：presentation layer
  - 与如何编码信息有关
  - eg.在数据传输中加密/压缩数据，用到表示层的功能
- 会话层：session layer
  - 会话层用于启动/停止连接
  - 会话层的协议：涉及启动和结束通信会话
  - eg.下载中断后重新启动下载，用到会话层的功能
- 传输层：transport layer
  - 传输层的内容与传输数据相关
  - 传输层：将数据切成小块，以便通过单个数据帧发送
  - 发送端的传输层：
    - 在信息中添加一个序列号，如1，2，3
  - 接收端的传输层：
    - 根据序列号将小块数据重新组合成原来的大的数据
- 网络层：network layer
  - 网络层负责信息的逻辑寻址
    - 确保信息穿过网络，到达接收端
  - eg.IP 地址
- 数据链路层：data link layer
  - 数字信息的最后一层
  - 数据链路层：从网络层获取数据，转换后交给物理层
  - eg.MAC/LLC
- 物理层：physical layer
  - 网络上传输的实际上是电流或电压脉冲
  - 物理层：电线、射频链路、光纤
    - 将信息从一个地方传输到另一个地方
- 高层协议利用低层协议发送和接收数据
  - 逻辑上讲：发送协议和接收协议的数据传输是在对应层进行的
汽车行业的网络模型
- 基本的联网(通信)能力来自第一层和第二层
  - CAN/LIN/FlexRay总线标准对第一、二层进行定义
- 其他层自行决定是否使用：
  - 如：是否在ECU软件中实现/使用传输层或表示层
- 每层可以更细分为子层
  - 数据链路层：MAC and LLC
    - 子层 MAC: media access control
    - 子层 LLC: link layer control
报文：协议数据单元 PDU
- 报头 Header: 相当于寄信时的address
  - 可在特定网络协议层的报头中插入信息：如地址或数据长度
  - 报头是必选项（报头的一部分是可选的）
- 有效荷载 Payload: 相当于信件的内容
  - 有效荷载是必选项
- 报尾 Trailer：
  - 报尾是可选项：取决于报文属于哪一层或协议类型
  - 报尾的作用：让接收端判断是否正确接收到数据
- 数据链路层的主要工作之一：
  - 确保在网络通信中，从物理信号到数字信号的转换不会被干扰
  - 确保不会因干扰导致位错误，或因不良连接导致位丢失
  - 这就是符号(symbol) 或网络符号的作用
- 协议数据单元 PDU:
  - 报头、有效荷载、报尾合称为PDU
  - PDU用于将（各层的）数据打包，以便发送数据
- PDU在OSI模型中的传递：套娃式
  - 高层协议利用低层协议发送和接收数据
    - 某一层创建一个PDU，将其向下传递到下一层；或从下层接收一个PDU
  - 套娃：每一层增加报头和报尾
  - 上一层的PDU作为下一层PDU的有效荷载
  - 并根据需要添加报头、报尾，然后发送给下一层
  - 直到进入数据链路层，并转换为物理信号，通过物理层发送到网络上
- PDU在数据链路层：通常称为帧Frame
  - 如：以太网帧
- 图示：

OBD

OBD:
- 车载诊断系统，on board diagnostics
- 最初用于 排放控制系统 的诊断
- 不同国家有不同的OBD：EOBD(欧洲)/JOBD(日本)等
OBD2:
- OBD2是SAE的一系列标准
- SAE：society of automoive engineers
OBD2的标准涵盖的内容：
- 关键词：标准化
- SAE J1978：定义诊断测试仪的功能
  - 诊断测试仪发送OBD请求，并解释响应。
- SAE J1962：定义诊断工具与车辆之间的接口(连接器)
- SAE J1979：定义车辆的请求和响应
- SAE J1850：定义连接器和诊断测试仪之间的连接
  - 一种特殊的网络连接方式
- SAE J2012：定义与车载诊断相关的所有故障
如今OBD2在车辆中的使用情况：
- ISO 11898/CAN：定义诊断仪和车辆之间的连接
- ISO 15765-4：定义在OBD中使用的地址
- 如今的OBD大多基于CAN总线
SAE J1979：所包含的请求和响应?
- 能够与车内ECU启动通信
- 获得有关排放系统的信息(OBD关注排放控制)
- 从车辆获取与排放相关的故障、以及故障信息
- 能够重置排放系统
  - 可能对排放系统进行更改、修复故障等
- 其他：
  - 通过控制排放系统内的设备来测试排放系统
SAE J1979：如何定义请求和响应？
- 请求和响应都是协议数据单元 PDU
- OBD2定义了OSI模型中的6层和7层 -- J1979是高层协议
- 所有发送和接收的数据都有根据标准进行编码
典型的请求结构示例
- 通信基于模式、标识符和可选的相关数据
- J1979将PDU分成两部分：模式 and 和模式相关的可选数据
  - 如有与请求相关的数据：模式告诉接收端如何解释数据，即数据的含义
- 许多J1979模式使用ID（标识符）：
  - 不同的ID：PID/TID/MID

UDS

OBD 发展史：
- 从统一标准到 多种KWP。。
- 2004 DoCAN发布：基于UDS的DoCAN实现了标准化
- DoCAN：ISO 15765-x
  - diagnostics communication over CAN
  - 标准有多个部分，主要是通过CAN总线进行诊断通信
  - 1 一般信息：标准结构、相关标准、词汇等
  - 2 网络层服务(传输协议)：收发大于单个CAN帧的数据
  - 3 在CAN总线上实施UDS: unified
  - 4 对排放系统的要求
UDS:
- 统一诊断服务 UDS, ISO 14229-1
  - unified diagnostics services
- 不同版本的UDS:
  - 需要明确是哪个版本的标准，不同版本之间有重要区别
UDS3包含的内容：
- 控制/管理 诊断和诊断通信的能力
  - 安全加密：验证是否允许与ECU交互；
  - 让ECU进入扩展会话：解锁额外功能
  - 让ECU进入编程会话：从而进行编程
- 从ECU内容读写数据：
  - 不是重新编程，是读取或调整数据
- 读取故障存储的能力：
  - 故障存储：fault memory
  - 如果ECU检测到故障，会将故障内容记录到内存中并存储
- 控制ECU输入、输出的能力：
  - 直接与ECU硬件(电子设备)交互的方式
- 通过UDS激活ECU内的用于诊断的特殊软件
  - 一些软件相关的事情
  - 例如允许特殊的测试例程或初始化例程
- 软件更新的能力
  - UDS涵盖向ECU上传和下载信息 (软件或文件) 的功能
- 图示：
UDS和OBD2的区别
- 组成：
  - OBD2: mode头 + 可选data
  - UDS: SID头 + 可选data
  - SID: services ID
- 种类差别：
  - OBD2: mode有10种模式
  - UDS: SID约27种不同的服务
- 服务的子功能：
  - UDS: 为某些服务提供子功能
  - 例如故障存储功能的多个子功能
- ID大小：
  - OBD2: ID为单字节，每个ID有255个值 (FF)
  - UDS: ID为2字节，每个ID有65535个值 (FFFF)
- 请求响应权限：非常不同
  - OBD2: 购买标准后可以向任何支持OBD的车辆发送请求，并获得响应
  - UDS: 不行，除非拥有描述特定ECU和特定车辆的ID的特定数据
- DTC大小：
  - OBD2: J1979只与排放系统有关，因此用 2 bytes 表示DTC
  - UDS: 为DTC增加一个字节，3 bytes 表示DTC，数据量更大
  - 通常，整车厂可以自行定义每个UDS DTC的内容
- 基于UDS，整车厂有更大的自由度

OBD和UDS之后是什么

OBD和UDS的简单对比：
- OBD2 比 UDS 早了大约15年：1991 vs 2004 or 2006
- 交互：10mode vs 27服务 and 子服务
- 标识符/ID：1字节(255) vs 2字节65535
- DTC：2字节(65535) vs 3字节(2^24-1)
- 灵活性：OBD2非常受限 vs UDS非常灵活
现代汽车的特点：(对比1991)
- ECU的处理能力更强，更多软件，更多ECU
  - 对比老式汽车：一个发动机管理系统+制动系统
- 数据种类更多 (软件更多自然导致)
- 排放相关部件更多
  - 发动机更复杂，发动机附属部件更多
  - 空调从选配到现在的标配，空调会增加发动机负荷，从而影响排放
- 旧的OBD协议耗尽了可用的数字空间
  - 但是仍需要OBD用于排放相关诊断
新的OBD发布：
- SAE J1979-2在2021年发布
- 在UDS第3版基础上，引入了OBDonUDS的概念
- OBDonUDS：可通过单一方法访问所有诊断数据
- OBDonUDS提供了从UDS访问排放数据的方法
诊断的趋同形式：
- 通过UDS检索OBD数据
新的J1979-3发布：
- 2022年发布，SAE J1979-3描述J1979-2的一个子集
- ZEVonUDS
- 解决电动车/插电式汽车的电能消耗掉的能源的排放问题
  - 获取插电式车辆数据、电池监测数据；
  - 从电网为汽车充电时可能造成的电网排放数据。。。

软件定义汽车SDV

看起来像SDV但实际不是软件定义汽车的：
- 软件可选配 - 不是
- 修复开发中的bug - 不是
- 应用软件更新，或OTA - 不是
- 更新单个ECU以解决问题 - 不是
- 只是获得可用的新数据，如地图数据更新 - 不是
- 手机镜像技术实现数据连续性 - 不是
- SDV中可能包含上述技术，但远不止这些
什么是软件定义汽车
- 通过不断增强软件和功能，从而不断扩展/增强车辆的性能
- 不仅是短期内，而是长期的
- 随着时间推移，车辆从硬件中挖掘更多潜力，加载更多功能
  - 例如：靠近解锁一些功能、万圣节灯光+恐怖音乐等
- 可能会影响车内的多个ECU
车主与SDV：
- 不需要付费才能解锁部分功能
- 在不使用特殊工具的情况下自行应用它们
- 在移动设备点击，或点击车内娱乐系统，新功能就会出现
- 在购买许多年后，车辆将不断获得新性能，车越开越好
- 软件定义汽车使车主保有汽车的时间更长
车厂：卖车的车
- 仍然持续改进，持续为客户提供更好的服务
- 持续为客户提供新功能

SOVD

面向服务
- service-oriented
传统汽车的软件：
- 以硬件为中心
- eg.风扇控制
  - 监控2个输入：温度传感器；用户设置的温度值
  - 根据两个输入值的差值，控制风扇转速
  - 2个输入值的输入：都是通过硬件(传感器/触摸屏)
  - 输出：风扇和电机，也是硬件
SDV中的软件：
- mechatronics软件层：与硬件交互的层
  - 希望尽量简单，几乎不需要改动本层的软件部分
  - 本层的微控制器和操作系统都不需要频繁更新软件
- 集成和本地控制功能层
- 车辆功能层：
  - 需要频繁变更软件，通过下面的层控制车辆
  - 添加功能，希望快速更新软件和重启功能
- 与云端IT系统进行交互的外部接口
- 真正与硬件交互的只有mechatronics层
  - 其他都是与软件进行交互
- 驱动：基于信号和基于服务
  - 基于信号是事件驱动的另一种说法：灵活性低
  - 面向服务：松耦合，允许轻松添加软件
UDS在面向服务的层：
- UDS在以信号为基础的底层非常有效：
  - 越接近硬件，UDS越适合处理各类问题
- UDS不太适合面向服务的层：
  - 越接近云端，UDS越不能完成所需任务
- UDS不能做好的2方面：编程语言和运行环境
  - 编程所产生的stack trace，UDS无法处理
  - 面向服务的层有文件系统，有log，但没有故障存储
顶层的vehicle API：
- 进入车辆的通道，也是架构中面向服务的部分
- 一个面向服务的接入点
- 任何情况下，对车辆的访问都是服务为导向的
- 需要一种面向服务的车辆诊断（SOVD）
SOVD:
- service-oriented vehicle diagnostics
- 面向服务的车辆诊断
- SOVD要有自描述性/可发现性
  - 具有SOVD的车辆不需要ODX文件
  - 当连接车辆，车辆会告诉你它支持哪些诊断
- SOVD可以进行远程remote 和近距离proximity 诊断
  - SOVD提供了远程访问的标准化方法
- 远程诊断：意味着不需要用线缆连接车辆就能进行诊断
- 近距离诊断：意味着在车辆旁，但不一定与车辆连接
- 当然也可以通过线束连接车辆实现诊断功能