本文主要介绍 EVITA 方案构根据需求与应用情况构建的不同用例与对应场景（用例13至用例16）。
本文来自实验室龚思陈、孙伊凡的学习笔记
3.14 Use Case 13 – Nomadic Device｜Personalize the Car
3.14.1 描述
3.14.1.1 概述
-
目的：允许司机自定义车辆
3.14.1.2 通讯实体与关系
-
3个车内实体，1个车外实体
-
移动设备 – 主机：无线连接，如蓝牙
-
主机 – 车内通讯实体：固定连接
3.14.1.3 假设，限制与前置条件
-
已有稳定安全的软件系统，能够保证车辆与移动设备之间连接的安全性与完整性
-
主机中已经有用户档案的数据
3.14.2 场景
3.14.3 需求
3.14.3.1 功能需求
-
移动设备的连接接口
-
车内主机的连接接口
-
车内不同通讯实体的固定连接
3.14.3.2 技术需求
需要两种通讯：
-
无线通讯接口
-
车载网络
3.14.4 安全方面
-
移动设备与车之间的无线联系具有 完整性、不可抵赖性
-
只有注册的移动设备可以与车辆进行交互
-
移动设备只能由授权用户使用，用户与主机内存储的用户档案相关
3.15 Use Case 14 – Aftermarket｜Replacement of Engine ECU
3.15.1 描述
3.15.1.1 概述
-
背景：引擎控制ECU在出现失灵后必须更换
-
处理流程
-
ECU 可以更新：安装正确版本的ECU硬件设备，并下载对应软件
-
没有对应软件提供下载：安装配有正确软件版本的ECU硬件
3.15.1.2 通讯实体与关系
3.15.2 场景
3.15.3 需求
3.15.3.1 功能需求
-
新的ECU与被取代的ECU在功能与通讯模式上保持一致
-
新的ECU必须具有OEM版本
-
新的ECU必须对发动机系统进行自检，保证正确的系统配置
-
如果使用软件刷新，请参见用例 “Flashing per OBD” 中所述的所有功能要求
3.15.3.2 技术需求
-
使用校验和验证所传输数据的完整性
-
如果使用软件刷新，请参见用例 “Flashing per OBD” 中所述的所有技术要求
3.15.4 安全方面
-
在驾驶模式中，传输数据的完整性需要被保证
-
如果使用软件刷新，请参见用例 “Flashing per OBD” 中所述的安全表述
3.16 Use Case 15 – Aftermarket｜Installation Car2x Unit
3.16.1 描述
3.16.1.1 概述
-
背景：装有Car2X通讯单元的车辆需要进行对应的安装工作
-
主要过程
-
机械安装
-
电源连接
-
汽车骨干总线连接
-
天线与天线电缆安装
-
车辆的功能只有在可以接受来自CU的新信息，并将其集成到已安装的汽车系统的过程中的情况下，才能进行更改
-
车辆骨干将会获取通讯单元广播的信息，因此 地盘安全控制器 与 主机 需要在安装过程中进行软件更新
NOTE：处理与CU交互的信息在用例 Safety reaction: Active brake 和 Message leads to safety reaction 中进行了详细说明
3.16.1.2 通讯实体与关系
3.16.2 场景
参考用例 “Safety reac- tion: Active brake” ， “Message leads to safety reaction”
3.16.3 需求
3.16.3.1 功能需求
-
新CU应当是与原CU具有相同的置信度、相同功能的通讯节点
-
新CU应当在CSC与HU中有相同的功能
-
车辆的ECU与总线的安全级别不能产生变化
-
新加的 Car2X 功能不会降低车辆的其他功能
-
新CU不享有优先权
-
车辆广播信息的隐秘性需要保证
-
CU遭受盗窃时，需要保证
-
不能被用于模拟车辆的虚假身份
-
不能被用于模拟使用人的虚假身份
-
不能被用于获取车辆 合法所有者的财务资源
-
通讯单元与中央系统之间不存在永久连接
-
长时间关闭车辆与CU也不会导致功能丢失
3.16.3.2 技术需求
占用底盘与动力系统总线上的附加安全信息占比不超过净数据的15%
3.16.3 安全方面
-
接受他车的信息前需要确认信息的安全性与可信度
-
广播车辆信息的机密性需要保证
3.17 Use Case 16 – Diagnosis｜Remote Diagnosis
3.17.1 描述
3.17.1.1 概述
-
诊断类型
-
车内诊断
-
车外诊断：使用如诊断工具的车外系统进行诊断，也可以通过将诊断工具连接到车内诊断系统进行
-
主要流程
-
概述：车主希望服务中心对车辆进行诊断检查；服务中心收到请求，使用诊断工具与车辆建立起非物理连接。（通过互联网，车辆不在服务中心范围内也同样可以进行诊断）
-
服务中心首先使用互联网或无线局域网与车内网络建立连接服务中心对员工发送连接请求
-
车辆通信单元检查消息的完整性、进行发送方身份认证车辆将连接应答发送给诊断工具
-
连接建立
-
诊断工具发送请求，请求内容包含ECU中所需要的诊断信息（State/Log信息）
-
CU收到连接请求，将消息转发给ECU
-
ECU与诊断工具间进行挑战回应过程（challenge response process），协商出安全会话
3.17.1.2 通讯实体与关系
3.17.2 场景
3.17.3 需求
3.17.3.1 功能需求
-
诊断工具：移动功能
-
车内CU：
-
检查RSU和诊断工具的身份
-
发送、接收外部请求
-
检查数据完整性
-
可靠、安全的的传输
3.17.3.2 技术需求
-
通讯类型：互联网、无线局域网
-
通讯范围：当下最先进
-
通讯时延：取决于通讯范围
3.17.4 安全方面
-
可认证性：车辆必须检查RSU和诊断工具是否允许与之交互
-
数据完整性：防止误诊
-
数据新鲜性
-
不可抵赖性：防止服务中心推卸责任
-
匿名性：防止窃听者监听获得车主的隐私消息
原文始发于微信公众号（轩辕实验室）：欧盟EVITA项目预研 第二章（五）
