UCM & UCM Master笔记

一、前言

UCM功能集群通过ara::com中间件向客户机应用程序公开服务。【下图为：UCM对其他功能集群的依赖关系。】

UCM Update and Configuration Management 更新和配置管理
UCM Client 用于涵盖 Diagnostic Application(应用诊断程序) 和 OTA Client
ara::com 负责Application之间通信（面向服务的通信） ，是介于应用程序和硬件设备之间的中间件。
UCM Master 在车辆中分发软件包和协调更新活动
Backend 一个托管软件包的服务器
OTA Client 一个与Backend使用OTA通信的自适应的应用程序
VCI 车辆通信接口

ProcessSwPackage 处理以前转移的软件包
RevertProcessedSwPackages 恢复通过处理一个或多个软件包所做的更改
VehiclePaceageManagement 从OTA Client的角度来看，Campaign的当前状态
VehicledDriverApplication 基于Vehicle Package Manifest，如果在当前状态下需要获得车辆驾驶员的批准，标记用来通知Adaptive Manifest
SafetyPolicy Vehicle State Manager Adaptive Application计算Vehicle Package中的安全策略
GetSwClusterInfo 方法返回一个处于状态为kPresent的软件集群的列表
PackageManagement UCM当前状态

UCM不负责启动更新过程；UCM实现了一个服务接口来实现此操作。UCM接收一个本地可用的软件包进行处理，但不负责其下载，软件包必须使用提供的ara::com接口转移到UCM。

UCM处理的是“物理的”、可上传的软件包。

二、UCM

1. 软件集群生命周期
软件集群的内容是通过引用所有所需的模型元素来定义的。

2. 技术概况
在OTA更新或者garage更新，UCM都是不可见的。UCM Client从UCM中提取用例，并将数据流和序列控制命令转发给UCM。

2.1 软件包管理
1、软件包转移：一个或几个软件包从UCM的客户端应用程序转移到UCM的内部缓冲区。
2、软件包处理：UCM在相关软件集群上执行操作（kInstall, kUpdate, kRemove）。
3、激活：UCM检查参与操作的软件集群的依赖关系，然后激活它们，最后在完成更新之前检查所有的软件集群是否可以正常执行（通过状态管理）。

2.2 软件包的内容
软件包处理一个软件集群（清单、可执行文件、数据）

3. 传输软件包
每个软件包在被转移到UCM时就会有自己的状态；UCM有可能将软件包保持在kTransferred状态，以防失败并稍后重试。
① 软件包生命周期的状态机，有存储选项

② 软件包生命周期，没有存储选项

4. 从流中处理软件包
可以在传输仍在进行中的同时处理一个软件包。

5. 传输软件包
可以同时传输多个软件包，但是只能同时处理一个软件包，以确保系统的一致性。
取消和逆转进程交换包用于回复进程交换包已应用的所有更改。如果一个大型资源文件update “in place”（在同一个分区中），那么恢复更新有可能不可行。则需要执行回滚，触发应用程序下载一个软件包来恢复稳定版本。
软件包由工具生成，并且版本要与UCM相匹配。

6. 激活与回滚
6.1 激活

6.2 回滚
可以在A/B分区的情况下调用回滚，或者UCM使用一些其他的解决方案来维护已更新或已删除的软件包的备份。

6.3 引导选项
执行哪个版本的软件取决于UCM状态，这个状态由UCM管理。系统设计不同可能会使得，执行管理在UCM之前启动，这样UCM和执行管理之间不能有直接的接口来定义执行哪个版本的软件，而需要使用引导选项的持久控件进行控制。
在kActivating状态下，UCM会修改Boot options，以便在下次重启更新的软件时执行新版本；在 kRolling-Back状态下，UCM也会修改Boot options，以便在下次重启更新的软件时执行原始版本。

6.4 完成激活
UCM还应该删除软件包、日志或任何旧版本的更改软件，以节省存储空间。

7. 状态报告
一旦软件包被转移到UCM，它们就可以被处理了，最终将更改应用到自适应平台，可以使用CurrentStatus字段查询UCM的全局状态。【下图为：CurrentStatus的状态机】

三、UCM Master

1. UCM Master功能集群生命周期

2. 技术概况
UCM Master提供标准的有适应能力的autosar解决方案，通过OTA或诊断测试仪安全地更新整车。
UCM Master从后端或诊断工具接收软件包，解析和解释车辆软件包，传输或流软件包到合适的目标（UCM subordinate或诊断应用程序），并协调处理、激活和最终回滚。所有这些行动都是UCM Master正在协调的所谓的活动。【下图为：车辆内的UCM Master架构概述示例】
机器的UCM在一个UCM的统一网络中，候选人的竞选目标，被称为UCM subordinates。

① UCM Master: 可以被认为是一组附加特性，能够丰富任何UCM实例。因此，根据UCM APIs，UCM Master APIs是自适应平台服务的一部分。UCM和UCM Master都有单独的服务实例。

② OTA Client: （一个自适应应用程序）OTA Client在Backend和UCM Master之间建立了一个通信，用于交换车辆中已安装的软件集群和Backend中可用的软件集群的信息（为了发现是否有新的更新或需要安装或删除软件集群，Backend或车辆必须计算UCM Master需要什么操作）。OTA Client可以定期与Backend建立连接，并更新整个车辆安装的软件集群。

③ Vehicle State Manager: （一个自适应应用程序）车辆状态管理器正在从几个车辆ECUs中收集状态，并在根据车辆包中引用的安全策略计算出的安全状态发生变化时通知UCM Master。如果不满足安全策略，UCM Master可以决定：通知车辆驾驶员安全条件不满足安全条件，以继续更新，推迟、暂停或取消更新，直到满足策略。

④ Flashing Adapter:（一个自适应应用程序）在UCM Master更新自动共享经典平台或任何平台，可以使用诊断。它包含OEM特定的诊断序列，并通过ara::com与UCM Master和自动共享服务器自适应平台进行通信，并使用诊断协议数据单元应用程序编程接口（D-PDU API）的实现，通过车辆总线与经典的ECUs进行通信。

⑤ UDS(Unified Diagnostic Services): 本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），ECU反馈给诊断方信息（Response）。车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议。
UDS诊断作为汽车ECU里的一个服务功能，位于应用层，它的实现需要有网络的支撑，我们把基于CAN总线实现的UDS诊断称为DoCAN，基于Ethernet实现的UDS诊断称为DoIP。