CN110618671A

CN110618671A - 空中（ota）移动服务平台

Info

Publication number: CN110618671A
Application number: CN201910536639.4A
Authority: CN
Inventors: T·林; P·德塞; R·H·尼尔森; M·阿拉姆; L·晋; R·阿塔姆; L·杜莫夫; S·J·加达姆; A·阿肖克; S·P·阿拉姆; D·莫雷; M·卡尔科里
Original assignee: Aptiv Technologies Ltd
Current assignee: Motional AD LLC
Priority date: 2018-06-20
Filing date: 2019-06-20
Publication date: 2019-12-27
Anticipated expiration: 2039-06-20
Also published as: DK201870700A1; CN116339277A; CN110618671B; US11875144B2; US11403087B2; US20190391800A1; US20220300273A1

Abstract

公开了一种空中(OTA)移动服务平台(MSP)，其提供各种OTA服务，包括但不限于：更新软件OTA(SOTA)；更新固件OTA(FOTA)、客户端连接、远程控制和操作监控。在一些示例性实施例中，MSP是向车辆和IoT设备递送和/或更新配置数据、规则、脚本和其他服务中的一个或多个的分布式计算平台。在一些示例性实施例中，MSP可选地提供数据提取、存储和管理、数据分析、实时数据处理、数据检索的远程控制、保险欺诈验证、预测性维护和社交媒体支持。

Description

空中(OTA)移动服务平台

技术领域

本公开总体上涉及一种用于向移动客户端提供移动服务的基于云的OTA软件平台。

背景技术

虽然在几年内预计大部分新车都会拥有嵌入的连接，但是汽车原始设备制造商(OEM)没有充分利用到远程管理车辆的嵌入的连接以降低保修成本和提高客户满意度。此外，车辆特征和功能复杂性不断增加，导致伴随更多软件的更多电子控制单元(ECU)，该软件需要贯穿车辆寿命周期进行维护和升级。OEM需要用于他们的客户的稳健的、可伸缩的(scalable)和高效的车辆软件更新管理。随着自动驾驶汽车的出现，软件更新管理将变得更具挑战性，因为自动驾驶车辆比有人驾驶车辆具有更多要进行更新的软件。

发明内容

公开了一种空中(OTA)移动服务平台(MSP)，其提供各种OTA服务，包含但不限于：更新软件OTA(SOTA)；更新固件OTA(FOTA)、客户端连接、远程控制和操作监控。在一些示例性实施例中，MSP是分布式计算平台，该分布式计算平台向移动客户端递送和/或更新配置数据、规则、脚本和其他服务中的一个或多个。在一些示例性实施例中，MSP可选地提供数据提取、存储和管理、数据分析、实时数据处理、数据检索的远程控制、保险欺诈验证、预测性维护和社交媒体支持。

公开的移动服务平台的一个或多个实施例提供一个或多个以下的优点。MSP为用户提供可靠、高效、安全、可伸缩的基于云的管理解决方案，用于远程管理和更新移动客户端上的软件和其他数据。MSP提供包括监控、诊断和预测的许多OTA服务，以便优化移动客户端的性能和利用。来自移动客户端的传感器数据与历史数据、人类专业知识和车队以及模拟学习相结合以便改善针对移动客户端的预测结果、发现与OTA操作相关的问题的根本原因并解决这些问题。

以下附图和说明阐述了所公开的实施方式的详情。其他特征、目标和优点从说明书、附图和权利要求中显而易见。

附图说明

图1是根据实施例的包括用于向移动客户端提供移动服务的移动服务平台的系统的框图。

图2是根据实施例的移动服务平台的框图。

图3A是根据实施例的OTA客户端软件架构的概念图。

图3B是示出根据实施例的软件更新程序包的OTA客户端处理的事件图。

图4A是根据实施例的用于软件更新的规划过程的流程图。

图4B是示出根据实施例的软件模型之间的软件依赖性的图。

图5示出根据实施例的包括允许DM绘制用于软件更新分发的地理围栏的地图的可视化。

图6是根据实施例的用于问题检测和解决过程的流程图。

图7示出根据实施例的数据分析仪表板。

图8A示出根据实施例的数据源对象的属性窗格。

图8B示出根据实施例的该数据源对象的映射窗格。

图8C示出根据实施例的过滤器对象的属性窗格。

图8D示出根据实施例的该过滤器对象的映射窗格。

图8E示出根据实施例的连接对象的属性窗格。

图8F示出根据实施例的该连接对象的映射窗格。

图9A是根据实施例的用于使用机器学习算法来生成模型的数据挖掘过程的流程图。

图9B是根据实施例的用于训练和评估模型的过程的流程图。

图10A是根据实施例的用于车辆制动系统的预测性维护过程的流程图。

图10B是根据实施例的用于车辆制动系统的预测性维护过程的更详细的流程图。

图10C是根据实施例的示例预测性维护报告。

图11A是根据实施例的索赔管理系统的框图。

图11B是根据实施例的示例欺诈索赔认证报告。

图12是根据环境的用于使用针对车辆管理的社交数据的过程的流程图。

图13示出根据实施例的用于软件更新包分发的安全过程。

图14是根据环境的包括各种可视化的示例主屏幕。

图15是根据实施例的自动驾驶车辆的系统框图。

图16是根据实施例的用于车辆的分布式计算架构的系统框图。

在各种附图中使用的相同参考符号来表示相同的要素。

具体实施方式

现在将详细参照实施例，在附图中示出这些实施例的示例。在以下详细描述中，阐述了众多具体详情以便提供对各个所描述的实施例的透彻理解。然而，对本领域的普通技术人员将显而易见的是，无需这些具体详情就可实践所描述的各种实施例。在其它实例中，并未对公知方法、程序、组件、电路以及网络进行详细描述以免不必要地模糊各实施例的各方面。

“一个或多个(One or more)”包括由一个要素执行的功能、由多于一个要素例如以分布式方式执行的功能、由一个要素执行的若干功能、由若干要素执行的若干功能或上述的任何组合。

还将理解的是，虽然在一些实例中，术语第一、第二等在本文中用于描述各种要素，但这些要素不应受这些术语的限制。这些术语仅用于将一个要素与另一个区别开来。例如，第一处理器可被称为第二处理器，并且类似地，第二处理器可被称为第一处理器，而没有脱离各个所描述的实施例的范围。第一处理器和第二处理器两者都是处理器，但它们并非相同的处理器。

在对本文中各个所描述的实施例的描述中所使用的术语仅出于描述特定实施例的目的，而非旨在构成限定。如在对各个所描述的实施例和所附权利要求的描述中所使用的，单数形式“一(a)”、“一(an)”和“所述(the)”旨在也包括复数形式，除非上下文另外明确指出。还将理解的是，本文所使用的术语“和/或”是指并且包含相关联的所列项目中的一个或更多个的任何和所有可能的组合。将进一步理解的是，术语“包含(includes)”、“包含有(including)”、“包括(comprises)”和/或“包括有(comprising)”当在本申请文件中使用时指明所陈述的特征、整数、步骤、操作、要素和/或组件的存在，但并不排除一个或多个其它特征、整数、步骤、操作、要素、部件和/或其群组的存在或添加。

如本文中所使用的，取决于上下文，术语“如果(if)”可选地被解释为表示“当…时或”在…后”或“响应于确定”或“响应于检测到”。类似地，取决于上下文，短语“如果被确定”或“如果检测到“[所陈述的状况或事件]”被可选地解释为表示“在确定…后”或“响应于确定”或“在检测到[所陈述的状况或事件]后”或“响应于检测到[所陈述的状况或事件]”。

系统概述

图1是根据实施例的包括用于向移动客户端提供移动服务的移动服务平台的系统的框图。系统100包括移动服务平台(MSP)101、移动客户端102和系统客户端103。这些实体中的每一个通过网络104与其他实体通信。在实施例中，MSP 101是安全的、分布式计算平台，该分布式计算平台提供了各种OTA服务，包括但不限于：更新软件OTA(SOTA)；更新固件(firmware)OTA(FOTA)、客户端连接、远程控制和操作监控。除了软件和固件更新之外，MSP101还可以递送和/或更新配置数据(例如，车辆模型或组件模型)、规则(例如，数据流处理模式)、脚本(例如，安全脚本)和服务(例如，对移动客户端的软件插件)中的一个或多个。MSP 101还提供数据提取、存储和管理、数据分析、实时数据处理和数据检索的远程控制。

移动客户端102包括任何类型的车辆、船只或包括任何物联网(IoT)设备的设备。移动客户端的一些示例包括但不限于：任何类型的车辆或船只(包括电动、混合动力和自动驾驶车辆或船只)、自动递送(delivery)机器人、无人机等。车辆的一些示例包括任何四轮、三轮或两轮车辆(例如，乘用车、摩托车、卡车、公共汽车、越野车、三轮车、反向三轮车、全地形车(ATV)、嘟嘟车(Tuk-Tuks)、移动滑板车)。系统客户端103可以包括向移动客户端102提供软件、数据或内容的任何个体或实体。系统客户端103可以使用网站门户、数据馈送、移动应用或任何其它合适的通信模式与MSP 101进行通信。网络104是适用于数据或SOTA与大量移动客户端双向通信的任何无线通信网络或网络集合。

IoT设备是任何物理设备、车辆、器具或包括电子设备、软件、传感器、致动器和连接性中的一个或多个的其它对象，并且这使得该IoT设备能够连接和交换数据(例如，立体声/单声道相机、激光雷达(LIDAR)、雷达、导航系统、娱乐系统、ECU、TCU等)。

示例移动服务平台(MSP)

图2是根据实施例的MSP 101的框图。MSP 101包括多个互连的处理器、路由器、中枢、网关、存储设备和其他通过一条或多条总线传送数据、命令和信号的硬件。在实施例中，MSP 101是分布式计算平台，该分布式计算平台包括用于使用可伸缩的发布/订阅消息队列作为分布式事务日志来处理实时数据馈送的数据流处理管道架构。

在一些示例性实施例中，MSP 101包括消息总线201、消息引擎202和(多个)数据库207。在一些示例性实施例中，MSP 101可选地包括转换引擎(transformation engine)203。在一些示例性实施例中，MSP 101可选地包括操作引擎204。在一些示例性实施例中，MSP101可选地包括智能引擎205。在一些示例性实施例中，MSP 101可选地包括分析引擎206。在实施例中，一个或多个引擎202-206各自为在MSP 101的一个或多个服务器上运行的软件方法的实例。这些软件实例被配置成用于使用消息总线201彼此通信。引擎202-206的多个实例可以同时运行。引擎202-206提供OTA服务(例如，软件更新、客户端连接、远程控制和操作监控)及数据服务(例如，数据摄取、数据存储/管理、数据分析、实时处理和数据检索控制)。

在实施例中，在一个或多个服务器上运行的负载均衡器(未图示)通过监听连接到移动客户端102的用于访问OTA服务的一个或多个端口来管理来自移动客户端102的连接请求。负载均衡器将请求转发给具有运行的消息引擎202的至少一个实例的后端服务器。在实施例中，负载均衡器保持持久性(服务器亲和性)以确保来自移动客户端102的连接和后续请求在服务中断(例如，由于连接丢失)之后被发送到相同的服务器。由移动客户端102发送的消息可以任何已知的数据交换格式(诸如可扩展标记语言(XML)或脚本对象标记(JSON))被格式化。

在实施例中，消息总线201由分布式流平台实现。分步式流平台发布和订阅消息(也称为“记录”)的流，在(多个)数据库207中存储该消息的流并且提供能够在引擎202-206之间传输消息的流的实时流数据管道。示例消息总线201是阿帕奇卡夫卡(Apache)分布式流平台。在实施例中，消息的消费者可以订阅特定的“主题”以针对该主题从消息总线201检索消息。主题是被发布的消息的类别或馈送(feed)名称。该主题是多订阅者的并且可以具有零个、一个或许多订阅写入到该主题的数据的消费者。原始输入数据从主题被消费，然后被汇总、富集或以其它方式转化成新主题以供MSP 101的其他消费者进一步消费或后续处理。

在实施例中，数据结构208(下文中，也被称为“数字孪生(digital twin)”)是针对移动客户端设备102创建的，并被存储在一个或多个数据库207中。数字孪生是移动客户端的基于云的虚拟表示。数字孪生可以用于监控、诊断和预测以优化移动客户端102的性能和利用。传感器数据可以与历史数据、人类专业知识、车队以及模拟学习相结合，以改善预测的结果。MSP 101使用移动客户端102的数字孪生来发现与OTA操作相关的问题的根本原因以便解决这些问题。每个引擎202-206的每个实例可以创建用于特定移动客户端的数据结构208的副本，并且读取或写入数据到数据结构208中的任何字段208B-208F。用于每个移动客户端102的数据结构208的副本可以存储在多个分布式数据库中。由MSP 101实现的后台进程可以维持存储在分布式数据库上的数据结构208的不同副本之间的一致性。

在实施例中，数据结构208包括用于在移动客户端102和MSP 101之间交换数据的多个字段。在所示的示例中，字段包括但不限于：移动客户端ID字段208a、状态流/状态字段208b、更新信息字段208c、控制信息字段208d、数据信息字段208e和(多个)扩展数据字段208f。这些字段是示例性的，并且数据结构208的其他实施例可以具有更多或更少的字段。

移动客户端ID208a可以是唯一地标识移动客户端的通用唯一标识符(UUID)。在实施例中，移动客户端ID 208a存储可用于唯一地标识移动客户端的车辆标识号码(VIN)。状态流/状态字段208b包括用于持久性(服务器亲和性)的状态和会话特定信息。更新信息字段208c包括与特定软件更新相关联的信息，诸如由智能引擎205提供的下载信息文件。控制信息字段208d包括用于OTA客户端的远程控制的命令，诸如禁用命令以禁用安装在移动客户端上的特定的软件版本。对于入站消息，数据信息字段208e包括移动客户端的名称、时间戳和到存储在一个软件包存储库中的用于移动客户端的软件包的链接。对于出站消息，该数据信息字段208e被用于将数据和命令发送到移动客户端。

(多个)扩展数据字段208f被用于发送和接收数据或服务。扩展数据字段208f可以包括到数据或服务提供者(例如，URI、URL、指针)或应用编程接口(API)的链接。例如，如果移动客户端请求由MSP外部的第三方数据或服务提供者托管的服务或数据，则(多个)扩展数据字段208f可以提供到数据或服务的接口，并且MSP将处理与第三方服务器计算机的必要连接，以请求和接收由第三方服务器计算机生成的结果。以该方式，每个移动客户端基于由该移动客户端订阅的特定服务或应用将具有带有多个定制的扩展数据字段208f的数字孪生。例如，如果移动客户端想要订阅交通或天气服务，则通过针对该移动客户端的数字孪生的(多个)扩展数据字段208提供对交通或天气服务的访问。服务可以托管在第三方服务器计算机上(例如，由服务器场托管)或由MSP服务器计算机托管。可以订阅该服务，以包括通过可由例如智能手机访问的任何移动应用可用的任何服务。该特征是有利的，因为它允许用户已经在他们的智能手机或平板计算机上订阅的移动应用的集成通过例如娱乐系统或车辆计算机而在他们的车辆中可用。

在实施例中，第三方软件可以托管在MSP 101的服务器上，并且该(多个)扩展数据字段208f通过API或其他接口机制提供对服务的访问。在实施例中，可以在(多个)扩展数据字段208f中将用户简档数据发送到MSP 101。个人简档信息可以是与移动客户端的操作者的个人偏好相关的任何数据，包括但不限于：气候控制数据、座位和镜子调节数据、娱乐偏好数据(例如，无线电预设、音乐播放列表)、电话联系人列表、导航数据(例如，历史数据、目的地位置)以及对移动客户端的特定操作者个性化的任何其他数据。

在实施例中，(多个)扩展数据字段208f可以包括多个个人简档。例如，共享移动客户端的家庭的每个成员都可以拥有他们自己的个人简档。此外，如果移动客户端是移动客户端的车队(例如，出租车、租赁汽车、公司车辆)的一部分，则用于每个操作者的个人简档可以存储在(多个)数据库207中。

在另一实施例中，(多个)扩展数据字段208f可用于移动装置管理(MDM)服务。例如，下载到移动客户端上的MDM数据可以允许或限制雇员使用某些特征，包括在移动客户端上强加和实行政策，诸如用于优化移动客户端使用和安全数据的政策。例如，MDM数据可以配置移动客户端以将移动客户端数据报告到MSP 101，在此处可以进一步分析它。移动客户端数据可包括但不限于：位置数据(例如，时间戳、纬度、经度和海拔)、传感器数据(例如，加速度数据、陀螺仪数据)和环境数据(例如，温度数据)。在实施例中，如参考图5描述的，位置数据可以用于确定移动客户端是否已进入或退出一地理围栏(虚拟地理边界)来触发软件包的下载或执行一些其它基于位置的服务。

在实施例中，可以使用地理围栏交叉(geofence crossings)来确定是否违反了公司政策。例如，提供出租车服务的司机可以被禁止行驶到由地理围栏包围的某个地理区域之内或之外。如果移动客户端是自动驾驶车辆，则(多个)扩展数据字段208f可以包括对自动驾驶车辆特定的移动客户端数据，诸如激光雷达(LiDAR)数据、超声传感器数据、雷达数据、全球导航卫星系统(GNSS)数据、立体相机数据和地图数据。在实施例中，如参考图9和10描述的，移动客户端数据可以由分析引擎206使用以检测和预测关于移动客户端102的各种维护问题。

在负载均衡器(未图示)从移动客户端接收到消息之后，负载均衡器将消息发送给正在运行消息引擎202的实例的MSP服务器。消息引擎202提供与一个或多个移动客户端102通信的端点，并支持入站和出站消息处理两者。同时运行的消息引擎201的数量基于与移动客户端102的激活(active)连接的数量。在实施例中，负载平衡器和/或消息引擎202实现用于与移动客户端102进行通信的一个或多个协议，该协议包括但不限于：传输控制协议/网际协议(TCP/IP)、超文本传输协议(HTTP)、安全超文本传输协议(HTTPS)、消息队列遥测传输(MQTT)协议和开放移动联盟设备管理(OMA-DM)协议。

在实施例中，消息引擎202读取消息报头并执行版本验证。集成应用编程接口(API)允许第三方应用通过网络(例如，因特网)与消息引擎202通信。例如，SOTA服务可能不可用，或者软件更新可能是过大的而难以使用SOTA服务进行传输。在这种情况下，集成API可以由在个人计算机或移动设备上运行的应用来使用，以通过网络上传或递送软件包到个人计算机。在将软件包下载到个人计算机之后，可以将其传输到通用串行总线(USB)拇指驱动器。例如，维修店或经销商处的技术人员能够从MSP 101下载软件包到个人计算机，传输该软件包到拇指驱动器，并且然后将拇指驱动器直接连接到车辆计算机的端口以将该软件包传输到车辆。

变换引擎202读取消息主体并将消息主体变换成由消息总线201使用的常见消息数据格式(例如，卡夫卡流格式)。

操作引擎204支持数据操作、软件操作和系统问题管理。操作引擎204提供用于与系统客户端103(例如，OEM、软件开发者)通信的网络门户和移动用户界面(UI)。操作引擎204生成具有可视化(例如，图表、表格)的报告，该可视化可以在网络门户和/或移动UI上查看，并使用各种通信模式(例如，电子邮件、推送通知、文本消息)向系统客户端103发送通知/警报。操作引擎204还提供服务API，该服务API允许系统客户端103使用他们的专有应用访问移动服务。在实施例中，服务API支持支付系统，该支付系统使用通过服务API所检索的数据管理基于计费的软件更新。

智能引擎205支持各种OTA操作，包括软件封装、软件相关性检查、调度和监视。

分析引擎206支持商业智能，包括报告生成和警报检测。如参考图7和图8更全面地描述的，分析引擎206还提供包括仪表板和工作流画布的交互式开发环境(IDE)，这允许数据分析员使用实时消息流或作为数据源的数据库来构建、测试和部署分布式工作流。

在实施例中，(多个)数据库207包括关系数据库(例如，SQL数据库)和分布式NoSQL数据库(例如，带有弹性搜索(Elasticsearch^TM)服务的阿帕奇卡桑德拉(ApacheCassandra^TM)DBMS)，以用于存储消息、数据日志、软件包、操作历史和其他数据。存储的数据可以是结构化的也可以是非结构化的。在实施例中，引擎202-206可以通过数据访问层(DAL)209使用例如EE数据访问对象(DAO)与(多个)数据库207进行通信。

示例OTA客户端软件架构

图3A是根据实施例的OTA客户端软件架构的概念图。如在本说明书中所使用的，术语“更新(updates)”包括任何类型的数字计算机指令或数据，包括但不限于：软件、固件、目标代码、机器代码、脚本、字节码、数据和元数据。以下示例涉及更新电子控制单元(ECU)或传输控制单元(TCU)的固件。ECU和TCU与汽车相关联(参见图16)。然而，接下来的描述也可以适用于任何电子控制器、微控制器单元(MCU)或执行无论是否嵌入在任何电子设备或物联网(IoT)设备中的指令的其它硬件处理器、专用集成电路(ASIC)、片上系统(SoC)和中央处理单元(CPU)。

在实施例中，OTA客户端软件架构300包括OTA客户端模块301、增量(delta)管理器302和安装管理器303。在示例性实施例中，架构300可选地包括通信管理器304。在示例性实施例中，架构300可选地包括ECU管理器305。在示例性实施例中，OTA客户端模块301可选地包括下载管理器306、数据抽象层(DAL)307、本地数据库308和实用模块(Utility modules)309中的一个或多个。在示例性实施例中，增量管理器302可选地包括增量压缩工具310(例如，XDELTA3、BSDIFF)。在示例性实施例中，安装管理器303可选地包括USB模块311和更新器模块312中的一个或多个。在示例性实施例中，通信管理器304可选地包括总线接口313。在示例性实施例中，ECU管理器305可选地包括ECU更新器模块314。

OTA客户端模块301的下载管理器306使用无线协议(例如，OMA-DM2.0协议)通过网络104与MSP 101通信。DAL 307提供连接到本地数据库308(例如，SQLite数据库)的接口。DAL 307是面向对象的系统，其提供将数据库308与外部应用连接的接口并且执行与数据库相关的操作。DAL 307还存储元数据，该元数据与由OTA客户端模块301和ECU管理器305在ECU上的安装操作期间生成的安装日志有关。实用模块309包括用于生成通信日志的记录器(logger)模块、用于管理HTTP连接的HTTP模块、用于管理开放式SSL(OpenSSL)连接的开放式SSL模块和用于管理JSON连接的JSON模块。

增量管理器(Delta manager)302负责使用增量压缩工具310中的一个生成两个文件之间的差异。增量管理器302还能够通过在正被更新的软件的基础文件上应用增量(diff)文件来重建新的更新软件图像。

安装管理器303的更新模块312提供更新和回滚(rollback)操作。该回滚操作提供故障安全机制，使得如果在更新过程中，安装管理器303未能利用新固件更新基础固件，该基础固件通过回滚操作恢复到最后的固件版本。USB模块311管理与USB拇指驱动器的连接以接收更新作为OTA服务的替代。

通信管理器304包括总线接口313，诸如控制器区域网络(CAN)、FlexRay^TM、以太网和DBUS。CAN是一种车辆总线标准，旨在允许微控制器和设备在没有主机的情况下在应用中相互通信。DBUS是进程间通信(IPC)和远程过程调用(RPC)机制，其允许在相同的机器上同时运行的多个计算机程序之间进行通信。

通信管理器304提供应用之间的数据传输操作。在实施例中，通信管理器304是动态库，其中应用可以链接到通信管理器304以使用其服务。通过总线(例如，CAN、DBUS)广播来自与通信管理器304链接的应用的发送数据的请求。类似地，来自与通信管理器304链接的任何应用的接收数据的请求将通过总线读取数据。通过配置文件315来确定信道的选择，配置文件315具有在应用和通信管理器304的相应的服务之间的一对一的映射。接口抽象层被用于支持除了CAN之外的接口，诸如以太网(Ethernet)和FlexRay。

ECU管理器305是核心引擎，其协调OTA客户端模块301与特定目标ECU或数据客户端之间的通信，以及管理其自身的内部状态。ECU更新器模块314负责将新ECU软件传输到目标ECU，该新ECU软件是从OTA客户端模块301接收的。ECU更新器模块314还负责将目标ECU的数据(例如，传感器数据)传输到数据客户端。在实施例中，ECU更新器模块314可被导入到ECU中，以便执行作为OMA-DM标准的一部分的软件组件管理对象(SCOMO)操作。ECU管理器305与目标ECU通信，以使用作为物理层的CAN、FlexRay^TM或以太网上的统一诊断服务(UDS)协议来传输文件。ECU管理器305也响应来自OTA客户端模块301的针对软件版本信息的请求。

示例OTA客户端处理

图3B是示出根据实施例的用于单个ECU升级的更新包的移动客户端处理的事件图。MSP 101将针对不具有相互依赖性的单个ECU的升级发送用于更新软件(在这个实例中是固件)的下载信息文件。在第一下载阶段，OTC客户端模块301从MSP 101检索下载信息文件(例如，JSON文件)，并且，在第二下载阶段，使用在下载信息文件中的链接从数据存储库下载固件。下载信息文件由OTC客户端模块301存储在本地数据库308中(例如，在本地磁盘存储器中)。下载信息文件包括安装命令(例如，脚本)和到存储在数据存储库中的软件文件的链接。

OTA客户端模块301经由通信管理器304调用安装命令。用于安装命令的相关信息(例如，ECU标识符(ID)、固件路径、固件版本)被发送到通信管理器304。通信管理器304通知ECU管理器305以触发更新固件命令。ECU管理器触发该更新固件命令，并经由通信管理器304向OTA客户端模块301汇报更新操作的状态(例如，成功代码或错误代码)。OTA客户端模块301然后向MSP 101报告适当的成功/失败警报。在发送报告之后，触发用于另一ECU ID的下一次更新。对所有接收的命令重复这一系列操作。

在实施例中，使用对称密钥加密或任何其它合适的加密技术(例如，椭圆曲线加密)对从MSP 101检索的下载信息文件针对安全性进行加密。在安装任何更新之前，OTA客户端模块301和MSP 101执行认证过程以确保从MSP 101(可信源)检索了该下载信息文件。例如，如参考图13更全面描述的，下载信息文件可以被数字签名，并且可以使用公共密钥密码学方法对MSP服务器、客户端和下载信息文件执行认证。

在成功认证之后，下载信息文件的内容被解密，并且OTA客户端模块301从数据存储库下载固件。例如，下载信息文件可以包括针对每个固件文件的统一资源标识符(URI)，诸如统一资源定位符(URL)。该URL为OTA客户端模块301提供路径以从该数据存储库下载固件文件。在实施例中，数据存储库是由第三方托管服务托管的数据库，通过网络服务(例如，亚马逊的数据库)可访问该数据库。

在另一实施例中，MSP 101将针对具有相互依赖性的多个ECU升级发送用于升级软件(在本示例中的固件)的下载信息文件(例如，脚本文件)。OTC客户端模块301从MSP 101下载该下载信息文件(例如，JSON文件)并将该文件存储在本地数据库308中。在实施例中，拓扑排序用于构建分层级拓扑，以确保以将保留不同软件模型和/或软件模型的不同版本之间的软件依赖性的方式来安装软件更新。对于独立固件，每个安装命令都是独占的。如参考图4C更全面地描述的，对于从属固件，安装命令的顺序基于使用深度优先搜索(DFS)算法的分层级拓扑。

更新操作如上所述那样针对单个ECU进行。如果相互依赖的固件中的任何一个升级失败，则将先前安装在序列中的所有相关固件进行回滚。OTC客户端模块301将经由通信管理器304利用目标版本信息调用回滚操作。OTA客户端模块301然后分别针对每个固件更新/回滚向MSP 101报告适当的成功/失败警报。

在实施例中，移动客户端内部的专用控制器被配置成用于管理该OTA更新过程，如在于2015年9月8日授权的针对“模块更新设备”的美国专利第9,128,798号中所描述的，该专利通过引用其整体并入本文。

示例数据客户端软件架构

除了OTA客户端之外，MSP 101还支持数据客户端。数据客户端共享OTA客户端软件架构的软件组件中的一些。数据客户端执行物联网(IoT)功能，从各种设备、传感器和数据分析功能收集数据。在实施例中，设备客户端采用OMA-DM协议以用于客户端注册、采用MQTT以用于数据交换并且采用REST API以用于将日志文件上传到因特网。数据客户端处理服务器命令并使用RESTful API经由OMA-DM或使用MQTT的传感器数据将安装日志上传到MSP101。

示例增量压缩

在实施例中，发送到移动客户端的数据被使用增量压缩(delta compression)技术进行压缩。利用增量压缩，可以比较文件的两个版本以确定它们的差异。差异被包括在差异(“diff”)文件或“增量”文件中。可以基于先前版本和可用的增量压缩算法为每个软件更新生成多个diff文件。例如，diff文件的选择可以基于软件的可用的先前版本、文件大小、解码时间和可用的增量压缩算法。存在几种公开可用的增量压缩算法。这些增量压缩工具包括但不限于：BSDIFF(按位减法)和XDELTA3(VCDIFF RFC 3284)。

不是每个更新方案都需要增量压缩。不同的增量压缩算法/工具适用于不同的参数，该参数包括例如文件大小、客户端处的计算限制、带宽要求、软件更新的紧迫性、服务器侧计算限制和重建单元的位置。例如，在使用情况下，向移动客户端快速推出(roll-out)文件以及完全绕过增量压缩可能是重要的。通过考虑对特定应用(例如，汽车行业)重要的参数，可以使用高级自适应选择方法，其中选择最合适的增量压缩工具进行增量压缩。下面的方程式[1]描述了基于函数F()的增量压缩工具的选择：

T_i＝F(S，O，Δt_d，Δt_p，b，P), [1]

其中S是文件大小的减少，O是原始文件大小，Δt_d是生成增量文件的时间，Δt_p是重建原始文件的时间，b是带宽限制，以及P是更新或传输优先级。在实施例中，F()可以是加权参数的线性组合，其中根据如方程式[2]中所示的应用，为参数(S,O,Δt_d,Δt_p,b,P)中的每一个分配权重wi(0和1之间的数字)：

其中N是参数的数量(例如，N＝6)并且F_i是“第i个”参数。从应用方程式[2]得到的T值可以映射到增量压缩工具的查找表。例如，如果T落在第一范围内，则选择BSDIFF工具，以及如果T落在第二范围内，则选择XDELTA3工具，等等。权重w_i可凭经验来确定。

示例远程控制和配置

在实施例中，MSP 101的用户可以使用配置面板来添加一组将被下载到OTA客户端或数据客户端的命令。用户可以使用配置面板来定义操作命令和数据命令。用户(例如，SM)可以配置车辆模型、设备模型和IoT设备模型。为了定义车辆模型，用户使用具有用于输入这些参数的文本字段的GUI来添加车辆型号、品牌、年份、装饰(trim)和款式。此外，用户可以输入配置类型、配置命令脚本和命令名。为定义设备模型或IoT设备模型，用户添加设备名称、制造商、说明书、固件名称以及固件版本。此外，用户可以输入配置类型、配置命令脚本和命令名。

在由用户使模型“激活”之后，由SM设置的配置值被下载到移动客户端(OTA客户端或设备客户端)。移动客户端可以接受、拒绝或推迟应用该配置值。如果移动客户端接受该配置值，则移动客户端应用配置值并向MSP 101发送指示移动客户端接受该值的“接受”状态，并且将该状态存储在(多个)数据库207中。如果移动客户端拒绝或推迟该配置值，则移动客户端不会应用该配置值并向MSP 101发送分别指示该值被移动客户端拒绝或推迟的“拒绝”或“推迟”状态，并且将该状态存储在(多个)数据库207中。SM可以查看SM仪表板中所有配置的状态。

示例软件更新计划

在实施例中，软件更新计划包括五个阶段：软件上传、批准、活动(campaign)任务创建、分发任务(distribution task)创建和安装任务创建。这些阶段中的每一个都是用户类的职责。在下文中，“用户”指的是注册的MSP 101用户。在实施例中，MSP 101支持以下用于软件更新计划的用户类(下文也称为“角色”)：系统管理员、内容管理员、软件管理员、活动审批者、活动管理员、部署管理员和执行者。系统管理员(SA)管理用户和联系人的创建、批准或拒绝用户创建请求、创建或暂停组织以及创建或删除角色。内容管理员(CTM)管理新的移动客户端模型和移动客户端(例如，车辆、物联网(IoT)设备)的创建，处理新的组件模型和组件依赖性的创建，处理新组件的创建，管理软件模型并映射软件依赖性。软件管理员(SM)管理软件上传并将基本版本和最新版本上传到软件模型。活动审批者(CampaignApprover；CA)批准或拒绝上传的软件版本。活动管理员(CM)基于移动客户端组创建和管理用于分发软件更新的活动任务，追踪下载和安装成功与失败的总数的状态。布置管理员(DM)创建和调度分发任务、跟踪安装任务的状态并跟踪安装问题。执行者访问仪表板和可视化(例如，图表、表格)。

每个用户在登录期间需要通过网站门户向MSP 101注册并提供认证信息(例如，用户ID和密码)。在实施例中，每个用户类具有称为“仪表板(dashboard)”的专用图形用户界面(GUI)，其提供静态和/或实时的可视化(例如，图表、表格、2D/3D图形)和针对用户类的任务和职责量身定制的输入机制(例如，菜单、文本输入框、按钮、复选框、链接等)。尽管上述软件更新计划利用人为干预，但在另一实施例中，由人类用户执行的任务可为由MSP 101无需人为干预而完全或部分自动化。

图4A是根据实施例的用于软件更新的计划过程400的流程图。可以使用图2中所示的MSP 101架构来实现过程400。过程400在SM上传软件版本时开始(401)。一旦收到软件版本，新的活动任务自动以“非激活(Inactive)”状态创建(402)。然后为已上传的软件版本自动生成Diff文件，并且“非激活”状态被自动改变成“创建”状态(403)。此时，CM可以编辑活动任务并使用CM仪表板设置活动配置。编辑的一些示例包括活动任务的开始时间和结束时间、以及针对分发任务的默认DM受让人。因为预期可能存在多个DM，所以CM可以分配默认DM，默认DM可以由CM基于默认DM的工作负载稍后重新分配。

该CM可以通过从一个或多个下拉菜单中选择车辆参数(例如，品牌、型号、年份、地理、经销商对(vs.)所有者等等)来配置车辆分组(包括在活动任务中的一组车辆)，然后点击保存按钮来保存选择。当CM完成编辑后，CM可以通过按CM仪表板中的“开始新的活动”按钮来启动新的活动。如参考图3B所述，新的活动任务可以包括对单个ECU的单个更新或对多个ECU的多个更新。在实施例中，非关键更新被捆绑到多个ECU，这些ECU共享具有类似的更新优先级和到期日期的相同车辆配置。

过程400以两个并行组的活动继续。在第一组活动中，活动任务的状态改变成“激活的”(405)。当分发任务被调度时，“激活的”状态改变成“在进行中”状态。当触发活动任务的结束时间时，“在进行中”状态改变成“关闭的”状态(407)。在第二组活动中，创建新的默认分发任务(408)。DM可以编辑默认的分发任务并选择新的结束时间(409)。当触发分发任务的新结束时间时，不允许软件更新(410)。

在实施例中，DM可以使用DM仪表板来创建、添加或编辑分发任务，选择分发方法和创建安装任务。例如，DM可以选择时隙来与车主调度OTA更新预约。DM可以输入批准的更新时间、车辆的总数来接收更新以及与车辆的预约时间。DM可以从分发方法列表中选择分发方法，所述列表包括但不限于：地理区域、组和地理围栏。如果选择了地理区域，则软件更新将被分发到在指定地理区域的车辆分组，诸如美国西部或北加州。如果选择了组，则软件更新将被分发到车辆分组，而不管组中的车辆的位置。如果地理围栏被选中，则软件更新将被递送到仅针对特定的地理围栏内的那些车辆的车辆分组。相应地，可以使软件更新对准车辆分组、地理区域和地理区域内的特定区域。

图4B是示出根据实施例的软件模型之间的软件依赖性的图。使用仪表板，用户(例如，SM)可以添加、编辑、查看、克隆、上传、删除和保存一个或多个软件模型及其依赖性。软件模型由软件模型、软件模型名称、软件类型(例如，应用)、组件模型、供应商、可用软件模型(例如，添加在具有所上传的基础版本的系统内的软件模型列表)和从属模型来定义。用户可以在为所选软件模型上传新软件文件的同时，利用不同版本的从属软件模型定义软件兼容性详情。

参考图4B，假设用户添加软件模型A并且还添加与软件模型B和软件模型C的软件依赖性。在该示例中，软件模型A安装在ECU 411上，软件模型B安装在ECU 412上并且软件模型C是安装在ECU 413上。这就创建了一个软件模型层次结构：软件模型A->软件模型B->软件模型C。此外，假定在一些实施例中，软件模型B具有版本1.0、2.0、3.0和4.0，并且软件模型C具有版本1.0、2.0和3.0。在为软件模型A上传版本2.0时，用户选择软件模型B和/或软件模型C的至少一个版本作为从属于软件模型A的版本2.0。MSP 101基于由移动客户端发送的软件配置详情为软件模型A、B和C检查软件依赖性和兼容性(如果有的话)。如果发现多个从属软件的任何更新，MSP 101发送两套下载链接到移动客户端。

第一组下载链接包括到单个软件包的单个下载链接，该软件包包括用于所有将被更新的软件模块A、B和C的更新。第二组包括到针对每个软件模型的单独的软件更新包的下载链接。到将在移动客户端上执行的软件安装被链接和下载在叶到节点(leaf-to-node)的分层级数据结构。移动客户端上执行的安装顺序是基于由用户在仪表板中所描述的模型依赖性。

参考图4B中的带圈数字，移动客户端上的安装管理器303(图3)首先创建从软件模型层次结构中的最低节点开始的安装任务(针对软件模型C的3个安装任务-版本2.0和版本3.0)。随后安装管理器303为层次结构中的下一个更高节点创建安装任务(针对软件模型B的一个安装任务-版本1.0)。随后安装管理器303为层次结构中的下一个更高节点创建安装任务(针对软件模型A的一个安装任务-版本2.0)。在实施例中，可以在移动客户端上运行拓扑排序算法(例如，Kahn算法)以确定安装顺序。

图5示出根据实施例的用于显示允许DM绘制用于软件更新分发的地理围栏的地图的可视化。在该示例中，所示的动态和交互式可视化500包括移动客户端在地图501上的实时位置502。由移动客户端所行驶的路线503被显示为更厚和/或更暗的线。诸如DM之类的用户可以使用指向设备在地图501上绘制地理围栏区域504。当移动客户端进入地理围栏区域504时，软件更新或待处理的软件更新的通知被发送到移动客户端。

示例问题检测和解决方案

图6是根据实施例的问题检测和解决方案的流程图。MSP 101在用户仪表板中提供问题管理工具，使用户能够查看由MSP 101基于OTA操作期间发生的事件而自动生成的问题列表。问题管理确保标识、分析、确定优先级并在适当的时限(time frame)内解决每个问题，使得OTA操作不会受到负面影响。

参照图6，当检测到问题并记录问题(601)时，过程600开始。例如，移动客户端可以向MSP 101报告更新失败。可以在具有例如以下屏幕字段的仪表板上查看该问题：问题ID、问题名称、问题类型、问题类别、原因、已分配/到、已解决、创建时间、优先级、状态和上次评论。仪表板的其他实施例可以包括更多或更少的屏幕字段。

向CM被通知问题(602)，执行问题的初步分析和基于初步分析分配优先级给该问题(603)。优先级确定问题的紧迫性，以便用户知道首先要解决的哪个问题。在实施例中，高优先级被分配给对OTA操作有很大影响并且有可能完全停止OTA操作的关键问题。中等优先级被分配给对OTA操作有显著影响但不会使OTA操作停止执行的问题。低优先级被分配给不影响关键OTA操作并且如果不马上解决也不会对OTA操作产生负面影响的问题。

分配优先级之后，CM然后基于检测到的问题的类型来分配/转发该问题给另一用户(604)。例如，如果它是部署问题，则SA将问题分配/转发给DM。如果是安装问题，则CM将该问题分配/转发给DM。如果需要数据分析，则CM将把问题分配/转发给数据分析员。将向受让用户通知该分配。用户可以从其仪表板查看问题，并在适用的情况下分配/转发给其他用户。用户还可以为用于问题的评论部分添加评论，以记录关于问题的其他详情，并与其他用户协作。

一旦被分配，受让人将执行问题的更严格的调查并提供诊断(605)。该诊断被应用，并且如果问题得到解决(606)，则问题将被关闭(607)。在问题解决之后，用户可以将问题的状态字段从“在进行中”改变为“已解决”。

示例数据分析工具

图7示出了根据实施例的数据分析仪表板700。可以由数据分析员在MSP 101上调用仪表板700。仪表板700包括功能栏701、选项卡控件(tab control)702、工具组703和工作流画布704。仪表板700使数据分析员能够：通过将工具组703中所列的工作流对象拖放到工作流画布704来创建分布式工作流；配置属性并针对工作流对象执行映射(参见图8A-8F)；保存工作流；运行数据工作流；部署工作流以及选择与加载以前添加的工作流。

在所示的示例中，如由选项卡控件702的欺诈检测选项卡所指示的，用于欺诈检测的分布式工作流705由数据分析员创建并且保存。每个由数据分析员创建的工作流可以被保存为具有用户指定的名称的选项卡，以便稍后可以使用选项卡控件702访问它。功能栏701包括各种功能，各种功能包括添加、加载、保存、运行和部署。在所示示例中，已加载名为欺诈检测的工作流。

工作流705包括在此示例中表示两个的关系数据库管理系统RDBMS-1和RDBMS-2的数据源对象706a、706b。数据源对象706a、706b馈送到第一连接对象707a，从而创建数据的单个流，该数据的单个流然后被输出到过滤器对象708。过滤器对象708被配置成用于从数据流滤除数据。过滤器对象708的输出馈送到第二连接对象707b和执行器对象709，执行器对象709执行由数据分析员选择或开发的算法或状态机。执行器对象709的输出馈送到可视化对象710，可视化对象710产生图表输出或工作流表输出。

数据源的一些示例包括但不限于：关系数据库、非基于SQL的数据库(例如，Cassandra^TM+Elasticsearch^TM)和消息流(例如，消息流)。如参考图8A更全面描述的，图7中所示的数据源编辑器的属性编辑器选项卡801用于配置数据源的属性。

过滤器的一些示例包括但不限于：将数据限制到连续值范围的范围过滤器、使用日历控件来调节时间或日期选择以选择单个连续范围的日期或使用日期范围过滤器以排除指定范围内的日期的日期过滤器和表达式过滤器。表达式过滤器让数据分析员使用SQL表达式来定义更复杂的过滤器。

变换的一些实例包括但不限于：和变换，其计算在数据库架构的列中具有数值数据类型的值的总和；以及连接(join)变换，其提供通过使用FULL、LEFT或INNER连接来连接两个数据集而生成的输出。

执行器的一些示例包括但不限于算法和状态机。在所示的示例中，选择决策树算法以基于属性对分类数据进行分类。可以使用所需的数据挖掘、机器学习和统计学习算法作为执行器，包括但不限于：简单线性回归、多元线性回归、决策树回归、随机森林回归、梯度提升树回归、逻辑回归、多项式回归、线性判别分析(例如，贝叶斯定理)、重采样方法、支持向量机、无监督学习、监督学习(例如，神经网络)。

数据接收器的一些示例包括但不限于：关系数据库、非SQL的数据库、可视化(例如，图表、散点图、3D网格表面)和表格。当数据接收器是可视化时，数据分析员可以以可视化的形式或以表的形式查看工作流输出。

图8A示出根据实施例的数据源编辑器的属性编辑器选项卡801。属性编辑器选项卡801允许数据分析员指定资源、资源类型、主机名、端口号、连接字符串、用户名、密码，并且然后从多个数据架构中选择数据架构。图8B示出根据实施例的数据源编辑器的映射编辑器选项卡802。当数据分析员选择映射编辑器选项卡802时，数据分析员可以选择数据库架构、表格和列。

图8C示出根据实施例的滤波器编辑器的属性编辑器选项卡803。数据分析员可以使用属性编辑器选项卡803来选择过滤器(例如，范围、日期或表达)。在此示例中，选择了过滤器表达式。图8D示出根据实施例的过滤器编辑器的映射编辑器选项卡804。数据分析员可以使用映射编辑器选项卡804来使用条件逻辑表达式设置过滤器表达式。在显示的示例中，数据分析员创建了条件表达式：if[Column 1]<10000then“True”else“False.”如果数据库表的列1存在超过10,000个项目，则此过滤器表达式将导致过滤器输出为“真”。否则，过滤器输出将为“假”。

图8E示出根据实施例的变换编辑器的属性编辑器选项卡805。数据分析员可以使用属性编辑器选项卡805来选择变换(例如，求和、连接)。图8F示出根据实施例的变换编辑器的映射编辑器选项卡806。数据分析员可以使用映射编辑器选项卡806来设置连接表达式。例如，数据分析员可以从相应的表中选择列，并将它们放在“左手侧”或“右手侧”以进行连接。

示例数据挖掘工具

图9A是根据实施例的用于使用机器学习算法来生成模型的数据挖掘过程的流程图。数据挖掘是利用统计、人工智能(AI)、机器学习(ML)技术和智能算法从原始数据中提取隐藏和有用信息的过程。它还涉及使用ML算法在数据元素之间找到频繁的模式、关联和相关性。

参照图9A，来自数据仓库901(例如，非基于SQL的数据库)或由系统客户端902上传的数据被输入到数据分析管道903。使用阿帕奇火花(Apache Spark)数据管道架构来实施数据分析管道903，并且输入数据可以是逗号分隔值(CSV)格式。

数据分析管道903包括数据挖掘算法904、机器学习算法905、模型906和文件系统907(例如，Hadoop分布式文件系统)。输入数据由机器学习算法905使用一个或多个数据挖掘算法904处理。机器学习算法905的输出是模型906，模型906被保存在文件系统907。模型906然后由流处理模块909使用以处理消息流908(例如，卡夫卡(Kafka)消息流)以提供预测910(例如，预测性维护)。

在示出的示例中，数据挖掘算法904是回归算法，分别包括决策树回归、随机森林回归和梯度提升树回归。然而，机器学习算法905可以利用任何已知的数据挖掘算法，包括但不限于：决策树、朴素贝叶斯分类、普通最小二乘回归、逻辑回归、支持向量机(SVM)、聚类算法(例如，k均值)、主成分分析(PCA)、奇异值分解(SVD)、独立分量分析(ICA)等。在实施例中，使用Apache Spark ML^TM实现机器学习算法。

图9B是根据实施例的用于训练和评估模型906的过程的流程图。监督数据可以从文件系统912中检索并输入到特征提取模块913中。特征提取模块913选择用于在构建模型906中使用的相关特征(变量、预测器)。特征的百分比(例如，20％)形成测试数据集914并且剩余的特征(例如，80％)形成训练数据集915。将训练集915输入到机器学习算法905中以训练模型906。模型906的输出被输入到模型评估模块918中，其中针对测试数据集914对该输出进行评估。如果达到期望的准确度919，则将模型906保存在文件系统920中。如果未达到期望的准确度919，则调节模型906的参数，并且通过模型评估模块918再次评估模型906的输出。示例预测性维护

图10A是根据实施例的用于车辆制动系统的预测性维护过程的流程图。车主/驾驶员需要知道何时替换制动衬块或制动流体，以便它们不会发生事故或破坏制动转子，制动转子是制动组合件的金属部分。如果它们等待太长时间，因为金属会碰到金属，所以制动衬块会破坏转子。不能指望驾驶员在每次车辆已经因制动衬块磨损和液位停止时都检查制动器。并且如果驾驶员根据某些预设的时间表更换制动衬块或制动流体，那么他们可能是在浪费钱，因为他们可能太频繁地更换制动衬块和流体。优选实现能够预测何时应该更换制动衬块或制动流体的模型。

预测性维护技术旨在帮助确定服务中的移动客户端的状况以预测何时应当执行维护(诸如制动系统服务)。预测性维护提供的成本节省在常规或基于时间的预测性维护之上，至少因为只有在保证的情况下才执行维护。预测性维护采用监控和预测建模来确定移动客户端的状况，并预测组件是否可能发生故障以及何时发生故障。

在所示的示例中，移动客户端是车辆，并且假设车辆装备有车载诊断(OBD)设备并且所述OBD装置流出实时数据。实时数据通过OBD端口发送并且包括车辆速度、每分钟转数(RPM)、空气温度和来自各种传感器的读数。

参见图10A，制动衬块传感器数据1001、制动流体传感器数据1002和其他传感器数据1003(例如，速度、里程、RPM)被发送到安装在车辆上的OBD设备1004。OBD设备1004聚集传感器数据(1005)并将其发送到MSP(1006)。如参考图7和图8描述的，制动衬块传感器数据1001输入到由数据分析员创建的数据分析管道内，数据分析管道预测制动衬块(1008)的寿命预期。基于预测结果和所限定的状态流来确定针对制动衬块磨损的严重性级别(例如，高、中、低和最佳的)(1009)。类似地，制动流体传感器数据1001被输入到数据分析管道，数据分析管道预测制动流体更换时间(1010)。基于该预测和所限定的状态流(1011)来标识针对制动流体液位的严重性级别。该传感器数据、预测和严重性级别被与其他车辆详情一起存储在数据储存库(1012)中。基于严重性级别，操作引擎204(图2)可以生成一个或多个可视化和/或警报(视觉或音频)以发送到车辆或系统客户端(例如，OEM)。可视化和/或警报可以在车辆仪表板上作为警示灯向用户进行呈现，在电脑屏幕上显示和/或通过扬声器播放。警报的一些示例包括“失效时间”和“推荐的维护时间”。

图10B是根据实施例的用于车辆制动系统的预测性维护过程的更详细的流程图。制动衬块是制动系统中的组件，其提供摩擦以使车辆减速。它们位于制动卡钳中，并通过利用摩擦材料压在盘式制动器转子上来减速和停止车轮。由于它们是接触式磨损件，因此制动衬块最终会随着时间流逝而磨损并需要替换。

预测制动衬块的预期寿命

为了计算制动衬块的预期寿命，我们假定以下值被发送到MSP 101作为OBD数据的一部分。

·制动衬块上的力＝500N(用于计算制动衬块的平均力的系统)

·制动衬块施加在转子上的力(F)＝93.545KN

·制动衬块的接触表面积(A)＝5445.414毫米

·施加在制动衬块上的压力(P)＝F/A＝93.545/5445.414＝17.178Mpa

·转子和衬块之间的摩擦系数(μ)＝0.45

·由垫块施加在转子上的制动扭矩(T)＝5519.188Nm

·等效力(R)的施加点的径向距离＝131mm

·取决于运动类型、负载和速度的修正因子(F1)＝1.8

·考虑温度和清洁度条件的环境因子(F2)＝1

·磨损系数(K)＝1.3*10mm/Nm

·最大负载制动下的转数会导致1mm的衬块厚度磨损(ΔT)＝1mm

基于上述值，该系统将根据方程式[3]计算磨损厚度ΔT：

ΔT＝F1*F2*K*P X R*2πN [3]

通过应用上述值到方程式[3]，我们得到N＝30000转，这意味着制动衬块在充分加载制动(500N)时将持续超过三万转。现在，让我们假定以下的值也发送作为OBD数据的部分。

·车轮的直径(D)＝547mm

·车轮的周长(C)＝1.7米

·车辆的速度(S)＝50KMPH

·汽车从50kmph至零的制动距离(B)＝4米

·每制动的转数，n＝B/C＝4/1.7＝2.35＝2.5(完成)

·每公里应用的刹车次数＝2

基于这些额外值，该制动衬块的寿命L由方程式[4]给出：

L＝N/(2*n). [4]

应用上述值(30000/2*2.5)＝6000KMS的车辆行驶。现在，我们知道制动衬块的预期寿命，现在我们可以定义分别如表1和表2所示的状态流及它们相关的警报。

表1-状态流定义

表2-严重性和警报

状态	状态流名称/严重性	警报
			状态1：	最佳	没有警报
状态2：	低	没有警报
			状态3：	中	没有警报
状态4：	高	警报

基于制动衬块的使用，这些制动衬块的预期寿命可跨越状态前后移动。如表3的示例中所示的，发生的是状态在最佳到高和高到最佳之间切换的总次数。

表3-发生实例

制动衬块的该“失效时间”指定用于部分或组件的完全失效的剩余的时间。时间以天为单位指定，并根据每天驾驶的平均公里数/英里数进行预测。例如，如果预测制动衬块的预期寿命为6000KMS，并且一天内驾驶的平均公里数为100，则推荐的维护时间将为6000/100＝60天。表4显示了此示例的推荐的维护时间。

表4-推荐的维护时间(制动衬块)

预测制动流体更换

制动流体为用在汽车、摩托车、轻型卡车和一些自行车中的液压制动和液压离合器应用中的一种类型的液压流体。制动流体用于将力转换成压力，并放大制动力。在常规维护活动中，流体基于驱动的公里数/英里数而不是流体的粘度而更换。通过预测性维护，可以监控制动流体的实际粘度水平，并且可以预测制动流体的更换。粘度指数和分类如下表5所示：

表5-粘度指数和分类

粘度指数	分类
		在35以下	低
35至80	中
		80至110	高
在110以上	非常高

太低粘度可导致增加的金属对金属的接触、增加的摩擦和磨损、增加的油耗和密封泄漏。粘度太高可能导致增加的流体摩擦、升高的操作温度和降低的能量效率。表6和表7分别为制动流体提供状态流定义和严重性和警报。

表6-状态流定义

表7-严重性和警报

基于制动的使用，这些制动流体的预期寿命可跨越状态前后移动。如表8的示例中所示的，发生的是状态在低到高和高到低之间切换的总次数。

表8-发生实例

该推荐的维护时间明确针对部分或组件的彻底失效所剩余的预测时间或距离(KMS)。表9显示了针对此示例推荐的维护时间。

表9-推荐的维护时间(制动流体)

状态	严重性	推荐的维护时间
			状态1：	低	立即
状态2：	中	NA
			状态3：	高	立即

图10B是根据实施例的用于车辆制动系统的预测性维护过程的更详细的流程图。当车辆正在行驶(1014)并且施加制动(1015)时，基于传感器数据1017来预测(1016)制动衬块的预期寿命。传感器数据1017包括但不限于：车辆的速度、施加在制动衬块上的压力、施加在制动衬块上的力、每次制动的转数和每KM施加的制动次数。然后对预测的剩余制动衬块寿命X执行失效分析，以确定制动衬块的状态(1018)。如果存在高风险状态则需要紧急维护(1019)，并且产生包括失效详情的报告(1020)和/或警报被发送给车辆的操作者、系统客户端或有权访问报告或接收警报的其他感兴趣的一方。

当车辆正在行驶(1014)并且施加制动(1015)时，基于传感器数据1022来计算(1021)制动流体的粘度。传感器数据1022包括但不限于：温度和流体密度。

然后对计算出的粘度进行失效分析，以确定该制动流体的状态(1023)。如果存在高风险状态则需要紧急维护(1024)，并且产生包括失效详情的报告(1025)和/或将警报发送给车辆的操作者、系统客户端或有权访问报告或接收警报的其他感兴趣的一方。

上述的用于单个车辆制动系统的预测性维护可以适用于经受失效或需要替换的任何车辆组件，诸如轮胎压力、平衡、发动机(例如，火花塞)、变速箱(transmission)、电池、燃料系统、燃料过滤器、冷却系统、动力转向流体、油的更换、油滤清器等。另外，上述预测性维护过程可以使用来自车辆组而不是单个车辆的传感器数据。例如，来自车辆组(例如，具有相同的品牌、型号、年份、风格和装饰的车)中的多个车辆的传感器数据可以保存在数据储存库中，并且用来预测用于车辆组的维修以及建立用于车辆组的统计趋势和基线。对于自动驾驶车辆，预测性维护过程可以预测传感器(例如，立体相机、激光雷达、雷达、声纳、加速度计、陀螺仪)何时发生故障或需要重新校准。预测维护过程还可以扩展到预测与车辆无直接关系的事件的发生，诸如基于从众包(crowd sourcing)在特定道路或高速公路上行驶的大量车辆收集的传感器数据来预测交通拥堵。这样的预测可以用于生成具有交通覆盖(例如，颜色编码路径)的地图图块，当移动客户端进入特定地理区域或地理围栏(参见图5)时，可以将地图图块发送到移动客户端。

图10C是根据实施例的示例预测维护报告1014。报告1014包括实时传感器数据(诸如制动衬块力、制动衬块压力、温度、制动流体水平和液压)的多线图1015。在图1015的右侧是包括如下刹车详情1016：制动衬块预期寿命、当前里程、严重性、制动位置、发生、失效时间和推荐的维护时间。车辆的图形使用颜色编码方案以视觉方式指示每个制动器的状况以指示严重性。在报告1014的底部是包括发生次数、严重性、时间戳、失效时间和推荐的维护时间的发生历史表1017。

图11A是根据实施例的索赔管理系统1100的框图。欺诈性活动使保险业每年花费数十亿美元，这也是保险费持续增加的主要原因，特别是在易受欺诈性风险的地理区域。无论是“硬欺诈”(例如，碰瓷(staged accidents))还是“软欺诈”(例如，盗用(embezzlement))，总会有表明针对高风险索赔人的潜在性的指标。这些指标通常很不明显的，但如果发现，可能会对保险公司的底线产生显著的积极影响。在这个示例中，我们假设每辆车都配备有可以流出实时数据的OBD设备，并且保险提供者将通过服务API(参见图2)发送索赔详情。

车辆1101流送传感器数据，传感器数据被保存到数据存储库1102(例如，Cassandra^TM数据库+Elasticsearch^TM)并且历史传感器数据被保存。在索赔管理仪表板(未示出)中，索赔管理员1103以.csv文件(1104)的形式将索赔详情上传到索赔管理系统1100。上传的索赔文件被在索赔管理仪表板中列出。基于上传的该索赔的详情，从数据储存库1102检索车辆1101的制动相关的历史数据。在检索的历史数据(1104)上执行分析，以确定是否该索赔是欺诈的或真实的(1105)。如果该索赔被确定为真正的，则没有记录在索赔管理系统(1106)中创建。

如果该索赔被确定为欺诈的，则系统在索赔管理系统(1107)中保存索赔详情。向索赔管理员1103通知(例如，通过电子邮件通知、仪表板中的警报通知)关于该欺诈性索赔1108。索赔管理员1103登录到索赔管理系统1100并查看索赔详情(1109)。

在仪表板中，索赔管理员查看批准或拒绝索赔(1110)的欺诈分析。根据所提供的原因，该索赔管理员将决定批准或拒绝该欺诈(1111)。如果被拒绝，则索赔详情将被保存在数据存储库中(1112)。如果被批准，则索赔管理员1103下载具有欺诈分析详情(1113)的欺诈验证报告1114，并将报告1114发送给保险提供者。

图11B是根据实施例的示例欺诈索赔认证报告1114。下面描述的欺诈验证报告就是一个示例。可以使用具有更多部分或查看器部分和详情的其他格式，包括一个或多个可视化(例如，图表)的附加。

报告1114包括表1115，表1115通过索赔的ID、索赔类型、索赔的日期和时间和状态(例如，打开、批准、拒绝)列出欺诈索赔记录。当索赔管理员点击表1115中的欺诈索赔记录时，记录的详情填充指示符和读数表1116中的字段。表1116包括指示符(例如，制动踏板力、减速峰值、左到右制动的不平衡等)。表1116的列中包括实际读数、最小读数、最大读数和状态(例如，低、高、最佳)。某些关键指标1117在报告1114中突出显示(例如，发动机负荷、发动机温度、RPM、速度)。报告1114的部分1118包括供索赔管理员输入其欺诈分析结果的文本字段，以及输入其针对结果的原因的评论部分。在实施例中，欺诈分析是自动的且无需用户干预。报告1114的部分1119包括用以输入拒绝评论的评论部分和用于批准或拒绝报告1114的按钮。报告1114的部分1120显示索赔历史，包括日期、索赔ID、索赔人、索赔(例如，制动失效)、欺诈分析结果(例如，是或否)和状态(例如，批准的、拒绝的)。

图12是根据环境的用于为车辆管理而使用社交数据的过程1200的流程图。社交数据是指个人创建的且在社交媒体平台上有意识地和自愿地共享的数据。通过脸书和领英等社交媒体监控在线客户对话可用于捕获有关用户的第一手信息，该信息然后可用于生成有意义的见解。

过程1200开始于从社交媒体(1201)中选择关键词。例如，领域专家分析要研究的概念并标识与概念相关的适当关键词和短语(例如，同义词/形态变体)，以用于从社交媒体流(例如推文(Tweet))中提取关键词来创建关键词的分析语料库(corpus)。例如，概念可以是车辆型号，并且关键词可以是雪佛兰索尼克(Chevy Sonic^TM)、福特嘉年华(FordFiesta^TM)、本田飞度(Honda Fit^TM)等。

流程1200以从社交媒体(1202)导入数据继续。例如，可以经由推文导入工具搜索所选关键词和短语来导入最后N个推文(例如，200)。

过程1200以通过去除多余的符号和词来准备数据(1203)继续。例如，可以从数据中移除引号、逗号和分号。此外，可以去除链接(例如，URL)。然后可以基于车辆型号对清理后的推文进行分组。

过程1200以通过将数据与该关键词进行比较和提取匹配关键词的词来分析数据(1204)继续。例如，内容为“#买了一辆新车“雪佛兰索尼克”，并且我喜欢它#”的推文将匹配关键短语“雪佛兰索尼克”。

过程1200以搜索匹配关键词或短语的车辆的车主并向该车主发送包括或引用与该关键词或短语相匹配的推文的通信(例如，电子邮件、文本消息、推文)继续。例如，可以发送以下内容的电子邮件：

“你好[姓名],

以下是由拥有雪佛兰索尼克的人发布的推文列表。

[推文1]

[推文2]

[推文3]

示例安全过程

图13示出了根据实施例的用于软件更新包分发的安全过程1300。安全性是针对OTA服务的关键考虑。需要对服务器、客户端和下载的软件包进行验证，以避免中间人攻击。将MSP服务器1303的默认URL被提供给移动客户端1301，并且由HTTPS处理根证书。为了验证移动客户端1301，移动客户端1306的私钥1306与移动客户端1306一起存储，并且将移动客户端1301的公钥1307存储在MSP服务器1303上。

由移动客户端1301发送的消息包含在注册过程期间从MSP服务器1303接收到的加密会话令牌。可以使用JSON格式发送该消息。由MSP服务器1303随机生成该会话令牌，并且每个会话是唯一的。由移动客户端1301利用移动客户端1301的私钥1306加密会话令牌。MSP服务器1303利用移动客户端1301的公钥1307解密会话令牌，并且如果会话令牌匹配在注册过程期间发送到移动客户端1301的会话令牌，则移动客户端1301被验证。会话令牌具有到期日期。如果会话令牌到期，则移动客户端1301从MSP服务器1303请求新的会话令牌。

利用文件下载密钥1305加密存储在数据存储库1302中的软件包1304。将文件下载密钥1305作为下载信息的一部分发送到移动客户端1301。移动客户端1301解密文件下载密钥1305。移动客户端1301利用文件下载密钥1305解密下载的软件包1304。

示例具有可视化的主页

图14是根据环境的包括各种可视化的示例主页。由SA经过可视化(例如，线图表、柱状图表、饼状图表)可以使用主页1400来获得OTA操作的完整概述。

在所示的示例中，主页1400包括示出跨过用户指定的时间期间的激活的活动任务、分发任务和安装任务的数量的任务线图表1401。任务线图表1401的下方是示出在用户指定的时间段内的安装任务的状态的安装任务线图1402。以下的安装任务线图表1402是实例条形图表1403，该条形图表1403示出MSP 101中的每个引擎(例如，转换引擎、智能引擎、消息引擎、操作引擎)的实例的数量，以给出系统负载的概述。实例条形图1403的旁边是按百分比示出问题的分解的问题饼图1404。问题饼图1404的旁边是分发任务饼图1405，该分发任务饼图1405按百分比示出分发任务详情，诸如提供、要做的、没有更新、进行中的实现、已安装、进行中的下载、已下载、拒绝、失效和延期的百分比。

上述的主页1400是一个示例，并且其他实施例可以包括更多、更少或不同的可视化。例如，可视化可以包括3D图表(例如，网格图)、动画、水平条形图表、散点图、直方图等。还可以存在文本和音频报告。可以基于显示屏的大小和分辨率来配置主页1400。在实施例中，每个可视化可以由用户手动调整大小和/或围绕显示屏移动以创建定制的屏幕。

示例移动客户端架构

图15是根据实施例的自动驾驶车辆系统1500的系统框图。系统1500是系统拓扑的一个示例，并且其他系统可以包含更多或更少的组件或子系统。

系统1500包括无线收发器(TX)1501、微控制器单元(MCU)1502、外围接口1503、输入/输出设备1504、系统存储器1505、数据存储设备1506、发动机系统1516、转向系统1518和制动系统1519。在一些示例性实施例中，系统1500可选地包括OTA/设备客户端1507、自动驾驶仪控制器1508、立体相机1509、LiDAR1510、GNSS接收器1511、姿态和航向参考系统(AHRS)1512、(多个)车轮编码器1513、(多个)车辆控制器1514、(多个)伺服控制器/驱动器1515、发动机系统1516和四编码器1517中的一个或多个。所有这些系统组件都耦合到一个或多个总线/网络，包括但不限于：CAN总线、FlexRay^TM和以太网。不同类型的总线/网络(例如，使用不同总线/网络协议)可以使用可以在不同总线/网络协议之间转换或映射的网关耦合在一起。

无线TX 1501包括射频(RF)发射机和接收机，RF发射机和接收机用于使用OTA服务提供(OTASP)、OTA配置(OTAP)或OTA参数管理(OTAPA)来传送和发送消息。可以使用任何已经的无线通信协议发送和接收无线传输(例如，消息)，该无线通信协议包括但不限于：OTA、OMA-DM、2G、3G、5G、IEEE802.15.4、WiFi、紫蜂(ZigBee)、蓝牙等。

MCU 1502是集中式处理器，该集中式处理器耦合到无线TX 1501并负责通过外围接口1503访问存储在系统存储器1505和数据存储器1506中的数据。外围接口1503可包括一个或多个I/O控制器并且被耦合到输入/输出设备1504，输入/输出设备1504包括显示屏(例如，LCD、LED、OLED、触摸屏、表面或垫)、指示设备、开关、按钮和任何其他机械或虚拟的输入/输出机制。I/O控制器被配置或编程成用于通过同步或异步总线/接口发送和接收命令和/或数据(单向或双向)，总线/接口包括全双工、半双工、主/从、多主、点对点或对等体、多分支以及多点总线/接口。

在实施例中，系统存储器1505(例如，RAM、ROM、闪存)存储将由MCU 1502执行的指令，所述指令包括操作系统和应用。如在参照图3A和3B所讨论的，系统存储器1505存储用于促进OTA服务的OTA/设备客户端1507。

MCU 1502耦合到自动驾驶仪控制器1508。自动驾驶仪控制器1508负责接收和处理来自立体相机1509、LiDAR/声纳1510、GNSS RX1511、AHRS 1512的传感器数据，并且基于传感器数据的分析生成自动驾驶仪的命令。AHRS 1512包括在三个轴上的传感器，传感器为车辆提供包括在合适的参考坐标系中的滚转、俯仰和偏航的姿态和航向信息。传感器可以是固态或微机电系统(MEMS)陀螺仪、加速计和磁力计。在实施例中，非线性估计器(诸如扩展的卡尔曼滤波器)用于从由AHRS 1512提供的数据计算导航解决方案。其他传感器可以包括在系统1500中，其他传感器包括但不限于温度传感器、压力传感器和环境光传感器。

GNSS RX 1511可以是任何基于卫星的定位系统接收器，包括但不限于：全球定位系统(GPS)、GLONASS、伽利略(Galileo)和北斗。其他定位的技术包括WiFi定位(例如，使用WiFi指纹数据库和贝叶斯预测器)和蜂窝发射塔(例如，使用三边测量、飞行时间(TOF)、到达的角度(AOA))。

自动驾驶仪控制器使用各种用于路由和防撞的AI技术。示例技术是贝叶斯同时定位和映射(SLAM)算法，其将来自多个传感器的数据和离线地图融合到当前位置估计和地图更新中。另一个示例是具有检测和跟踪其他移动物体(DATMO)的SLAM，其也可以处理汽车和行人。更不复杂的系统可以使用路边实时定位系统(RTLS)信标系统来辅助定位。另一个示例是使用机器视觉的视觉对象标识，视觉对象标识包括深度学习或神经网络，该神经网络具有多个从激活网络的环境模拟的神经元的多个阶段或级别。可以对从现实生活驾驶场景中提取的数据训练神经网络。激活神经网络并“学习”以基于驾驶场景执行最佳行动。

(多个)车辆控制器1514可包括TCU、ECU和用于控制车辆子系统的任何控制器。(多个)车辆控制器1514从自动驾驶仪控制器1508接收命令并产生到(多个)服务器控制器/驱动器1515且用于控制/驱动各种车辆子系统的控制命令，各种车辆子系统包括但不限于：发动机系统1516、转向系统1518和制动系统1519。

除了传感器，系统1500包括各种编码器，各种编码器包括用于测量转向角的四编码器1517、和用于测量车轮旋转的轮编码器1513。编码器1513、1517向自动驾驶仪控制器1508提供输出，在计算时将该输出考虑在内。

图16是根据实施例的用于车辆的分布式计算架构的系统框图。系统1600包括耦合到以太网1603的TCU 1602和ECU1601、1605。以太网1603通过网关1604耦合到CAN总线1606。CAN总线包括ECU 1607、1608和1609。系统1600是示例的拓扑结构和可以包括更多或更少的ECU、网关和总线的其他拓扑。

ECU可以控制内燃机上的一系列致动器以通过以下步骤来确保最佳的发动机性能：从发动机舱内的多个传感器读取值，使用多维性能映射(例如，查找表)来解释该值，并且基于解释的值调整发动机致动器。每个ECU包括实时地处理来自各种传感器(例如，发动机传感器)的输入的微处理器。ECU包含包括在印刷电路板(PCB)上的电子组件的硬件。PCB上的主要组件是微控制器单元(MCU)或中央处理单元(CPU)。将软件/固件存储在MCU/CPU缓存或在PCB上的其他存储器芯片，诸如EPROM或闪存。在实施例中，如参考图2和图3所述的，可以通过使用OTA操作下载更新的代码来重新编程(刷新)MCU/CPU。CAN总线1606允许TCU1602与ECU 1601、1605、1607、1608、1609彼此通信而无需使用基于消息的协议的主机。网关1604也是在车辆内部使用的ECU，用于将来自一个车辆总线的交通转换到另一个，诸如在CAN总线1606和以太网1603之间转换。网关1604可以提供到包括CAN、LIN和的多个不同类型的总线的连接性。网关1604将在相同协议的多个总线之间的数据进行翻译或翻译成不同类型的总线，以确保TCU和ECU具有它们所需要的正确的信息以用于车辆按预期操作。

替代OTA更新方法

1.使用SIM/eUICC卡的OTA更新方法

用户标识模块(SIM)卡和嵌入式通用集成电路卡(eUICC)(例如，软SIM、eSIM)通常包括在安装在车辆中用于连接性的蜂窝调制解调器。现代SIM/eUICC卡包括一个智能卡操作系统(例如，Java卡(Java)OS)可用于为小应用运行虚拟机(VM)，并存储蜂窝简档、应用等。因为Java卡为可用于基本的OTA自举(bootstrapping)，所以OTA客户端应用可以安装在eUICC，并且可以从车辆中的主机CPU通过例如应用编程接口(API)进行访问。OTA客户端应用还可以存储用户和/或设备标识数据。例如，eUICC订阅管理系统可以加载或修改eUICC中的用户和/或设备标识数据。用户和/或设备标识数据可以由在主计算机上通过API运行的主机应用访问。

在实施例中，使用SIM/eUICC卡执行OTA更新的装置包括：无线调制解调器，其被配置成与网络建立无线通信链路；集成电路模块，其安全地存储用于标识和认证设备上的用户的移动用户标识和相关密钥；存储器，其嵌入在存储用于操作系统、虚拟机和空中(OTA)客户端软件的指令的集成电路模块中；一个或多个处理器，其执行操作系统、虚拟机和OTA客户端软件的指令以：建立与OTA移动服务平台的通信会话；以及在通信会话期间，利用OTA移动服务平台执行一个或多个OTA操作。

在实施例中，存储器存储用于该装置的标识符。在实施例中，一个或多个OTA操作包括：接收一个或多个图像或文件的广播或组播(multicast)，其中每个图像或文件包括车辆标识符；从OTA移动服务平台获取图像或文件的加密数据(例如，加密的哈希(encryptedhash))；以及使用加密数据验证图像或文件。

2.使用家庭/IoT网关的OTA更新方法

在实施例中，智能电话应用充当OTA分布式计算平台和在车辆中的OTA客户端之间的代理服务器。例如，应用可以通过无线连接(例如，蓝牙连接)或物理端口(例如，USB端口)连接到车辆以获得车辆数据(例如，VIN、ID、软件版本)。智能手机然后通过家庭网关(例如，用户家中的WiFi路由器)连接到OTA分布式计算平台，并获得OTA更新(例如，软件更新)。在方便用户的稍后时间，用户再次将智能手机连接到车辆并且在车辆软件上执行OTA更新。在实施例中，车辆通过无线连接而连接到用户的家庭网关(例如，WiFi连接)并通过连接到家庭网关的智能手机应用控制OTA更新过程。

在实施例中，使用家庭或IoT网关的OTA更新方法包括：由移动设备(例如，移动电话、拇指驱动器)的一个或多个处理器建立与车辆计算机(例如，汽车计算机或TCU或ECU)的第一通信会话(例如，蓝牙、WiFi会话、USB连接)；通过无线连接接收与车辆(例如，VIN)、安装在车辆上的数据标识代码或数据(例如，软件ID和/或版本号)相关联的车辆标识符；由一个或多个处理器建立与空中(OTA)移动服务平台(例如，通过家庭网关)的第二通信会话；在第二通信会话和使用车辆标识符期间，从OTA移动服务平台接收下载信息(例如，用以从基于网络的存储设备检索软件/固件更新的URL)；由一个或多个处理器使用该下载信息，检索对代码或数据的更新(例如，用于更新固件/软件文件的diff文件)；由一个或多个处理器存储可由移动设备访问的存储设备中的更新；由一个或多个处理器建立与车辆的第三通信会话(例如，蓝牙、WiFi会话、USB连接)；并且在第三通信会话期间，将该更新传输到车辆。在实施例中，通过无线局域网建立第二通信会话。在实施例中，第一和第三通信会话是IEEE802.11x、IEEE 802.15.x、近场通信(NFC)或蓝牙通信会话。在实施例中，通过车辆计算机的通信端口(例如，USB端口)建立第一和第三通信会话。

3.使用广播或组播的OTA更新方法

在实施例中，MSP向在块中具有ID的移动客户端提供连续的广播或者组播数字签名OTA图像(例如，增量文件)。移动客户端基于ID收集全部或部分图像，并与MSP建立通信以获得图像的加密的哈希以验证图像签名。与MSP的通常通信(例如，注册、提供、签名等)是所需的位(bit)，持续时间非常短。在实施例中，广播或组播可以通过蜂窝网络完成(例如，使用即时消息服务(IMS))。在实施例中，可以使用附加的或补充的广播网络，包括但不限于无线电(例如，FM无线电)、卫星和WiFi网络。

虽然该文件包含许多具体实施详情，但是该实施详情不应被解释为对可能要求保护的范围的限制，而是作为对特定实施例特定的特征的描述。在单独的实施例的情境下在本说明书中所描述的某些特征还可以组合地实施在单个实施例中。相反，在单一实施例的情境下描述的各个特征也可以被单独的或以任何合适的子组合的方式实施在多个实施例中。此外，虽然诸特征在上文可能被描述为以某些组合的方式起作用且甚至最初是如此要求保护的，但来自所要求保护的组合的一个或多个特征在一些情形中可从该组合被删去，且所要求保护的组合可以针对子组合、或子组合的变体。

类似地，虽然附图中以具体顺序描绘了操作，但这不应被理解成要求这种操作以所示出的具体顺序或以有序顺序执行，或者所有展示的操作可以被执行，以实施令人希望的结果。在某些情况下，多重任务处理和并行处理可能是有利的。而且，上述实施例中的各种软件组件的分离不应被理解成在所有实施例中都要求这种分离，并且应理解的是，所描述的软件组件通常可以一起整合在单个软件程序或多个软件程序中。

本说明书的主题的一些方面可以包括收集和使用来自各种来源的可用数据。本公开预期在某些情况下，该收集的数据可以基于设备使用来标识特定位置或地址。这样的个人信息数据可以包括基于数据的位置、地址、用户帐户标识符或其他标识信息。本公开还预期负责收集、分析、公开、传输、存储或这些个人信息数据的其他使用的实体将遵守公认(well-established)的隐私政策和/或隐私惯例。特别是，此类实体应实施并始终如一地使用通常被认为满足或超过行业或政府要求的隐私政策和做法，以保护个人信息数据的私密性和安全性。

Claims

1.一种方法，包括：

由空中OTA移动服务平台的一个或多个处理器接收指定移动客户端模型和描述与所述移动客户端模型相关联的多个软件模型的多个用户输入，所述移动客户端模型定义安装在移动客户端上的多个硬件组件，其中所述多个硬件组件执行由所述多个软件模型定义的软件，所述多个软件模型还定义所述多个软件模型的一个或多个版本之间的相互依赖性；

由所述一个或多个处理器生成更新文件和下载信息文件，其中所述更新文件用于存储在数据存储库中的软件更新，所述下载信息文件包含用于下载和安装所述更新文件的指令，所述指令定义保留所述多个软件模型的一个或多个版本之间的相互依赖性的安装顺序层次结构；

由所述一个或多个处理器生成分发任务，所述分发任务包含开始时间、结束时间和移动客户端组；

由所述一个或多个处理器为所述移动客户端组中的移动客户端生成安装任务；

根据所述安装任务而：

由所述一个或多个处理器将所述下载信息文件传输给所述移动客户端组中的所述移动客户端；以及

根据所述下载信息文件，将所述更新文件传输给所述移动客户端组中的所述移动客户端。

2.如权利要求1所述的方法，进一步包括：

由所述一个或多个处理器监视所述安装任务以检测伴随所述安装任务的问题；

根据检测到问题并响应于用户输入而：

由所述一个或多个处理器基于问题类型将所述问题分配给所述移动服务平台的用户类的成员；以及

由所述一个或多个处理器在解决所述问题之后改变所述安装任务的状态。

3.如权利要求1-2中任一项所述的方法，进一步包括：

由所述一个或多个处理器基于由所述移动客户端组中的所述移动客户端提供的位置数据，确定所述移动客户端组。

4.如权利要求3所述的方法，其中，基于所述位置数据和地理围栏来确定所述移动客户端组。

5.如权利要求1-4中任一项所述的方法，其中，所述OTA移动服务平台是分布式计算平台，所述分布式计算平台包括数据流处理管道架构，所述数据流处理管道架构用于使用可伸缩的发布/订阅消息队列作为分布式事务日志来处理来自移动客户端的数据馈送。

6.如权利要求1-5中任一项所述的方法，其中，所述OTA移动服务平台包括多个软件实例，所述多个软件实例同时运行并通过消息总线彼此通信。

7.如权利要求1-6中任一项所述的方法，进一步包括：

由所述OTA移动服务平台创建所述移动客户端的虚拟表示，所述虚拟表示包含用于所述移动客户端的唯一标识符和具有一个或多个字段的数据结构，所述一个或多个字段提供可操作用于从所述OTA移动服务平台外部的一个或多个数据或服务提供者发送和接收数据的接口；以及

将所述虚拟表示存储在可由所述OTA移动服务平台访问的一个或多个数据库中。

8.一种方法，包括：

由空中OTA移动服务平台的移动客户端的一个或多个处理器接收包含指令的下载信息文件，所述指令用于从数据存储库下载和安装更新文件并且定义安装顺序层次结构，所述安装顺序层次结构保留定义安装在所述移动客户端上的软件的多个软件模型的一个或多个版本之间的相互依赖性；

根据所述指令，将所述更新文件下载到所述移动客户端；以及

根据所述安装顺序层次结构，由所述一个或多个处理器启动所述更新文件在所述移动客户端上的安装。

9.如权利要求8所述的方法，其中，通过拓扑排序确定所述安装顺序层次结构。

10.如权利要求8-9中任一项所述的方法，其中，所述下载信息文件包含到存储在基于网络的数据存储库中的更新文件的链接。

11.一种空中OTA移动服务平台，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，所述一个或多个程序存储在所述存储器中并包含用于执行如权利要求1-7中任一项所述的方法的指令。

12.一种移动客户端，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，所述一个或多个程序存储在所述存储器中并包含用于执行如权利要求8-10中任一项所述的方法的指令。

13.一种非瞬态计算机可读存储介质，包括一个或多个程序，所述一个或多个程序用于供空中OTA移动服务平台的一个或多个处理器执行并且包含指令，所述指令在由所述一个或多个处理器执行时，使得车辆执行如权利要求1-7中任一项所述的方法。

14.一种非瞬态计算机可读存储介质，包括一个或多个程序，所述一个或多个程序用于供移动客户端的一个或多个处理器执行并且包含指令，所述指令在由所述一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求8-10中任一项所述的方法。

15.一种方法，包括：

由用于更新软件或数据的空中OTA移动服务平台的一个或多个处理器导致在移动客户端上显示包含工作流画布的图形用户界面GUI；

由所述一个或多个处理器接收一个或多个用户输入，所述一个或多个用户输入导致在所述工作流画布上创建或显示分布式工作流，所述分布式工作流包含多个连接的显示对象，每个显示对象表示在所述分布式工作流中的节点；

由所述一个或多个处理器接收用于数据源对象的配置数据，所述配置数据选择数据流管道或数据存储库中的一个，所述数据流管道流送以空中OTA方式从移动客户端接收的移动客户端数据，并且所述数据存储库存储历史移动客户端数据；

根据所述配置数据选择所述数据流管道：

由所述一个或多个处理器将数据处理器应用到所述数据流管道中的所述移动客户端数据，其中所述数据处理器由所述分布式工作流中的所述显示对象中的一个表示；以及

根据所述配置数据选择所述数据存储库：

由所述一个或多个处理器将所述数据处理器应用到存储在所述数据存储库中的所述历史移动客户端数据。

16.如权利要求15所述的方法，其中，所述显示对象中的至少一个表示应用到数据以将所述数据限制成连续值范围的范围过滤器。

17.如权利要求15-16中任一项所述的方法，其中，所述显示对象中的至少一个表示日期过滤器，所述日期过滤器基于落在指定日期或时间范围之内或之外的时间戳来将数据从进一步处理中排除。

18.如权利要求15-17中任一项所述的方法，其中，所述显示对象中的至少一个表示组合一个或多个值、运算符或数据库函数的过滤器表达式。

19.如权利要求15-18中任一项所述的方法，其中，所述配置数据选择所述数据存储库，并且所述显示对象中的至少一个表示数据转换，所述数据转换结合存储在所述数据存储库中的数据库表中的两列或更多列数据值。

20.如权利要求15-19中任一项所述的方法，其中，所述配置数据选择所述数据存储库，并且所述显示对象中的至少一个表示数据转换，所述数据转换将存储在所述数据存储库中的数据库表中的单个列中的数据值进行求和。

21.如权利要求15-20中任一项所述的方法，其中，应用所述数据处理器进一步包括：

从所述数据存储库中的数据中提取特征；

将所述特征分成训练数据集和测试数据集；

使用所述训练数据集训练模型；

使用所述测试数据集测试所述模型；以及

将所述模型存储在所述数据存储库中。

22.如权利要求21所述的方法，其中，应用所述数据处理器进一步包括：

将所述模型应用到所述数据流管道中的所述移动客户端数据；以及

使用所述模型的输出来预测所述移动客户端的状态。

23.如权利要求15-22中任一项所述的方法，其中，所述移动客户端是自动驾驶车辆，并且所述移动客户端数据是由嵌入在所述自动驾驶车辆中的一个或多个传感器提供的传感器数据。

24.如权利要求15-23中任一项所述的方法，其中，所述一个或多个用户输入包含一个或多个拖放操作，其中从所述GUI中的工具集拖出表示所述分布式工作流中的节点的所述一个或多个显示对象并放在所述工作流画布之上。

25.一种空中OTA移动服务平台，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，所述一个或多个程序存储在所述存储器中并包含用于执行如权利要求15-24中任一项所述的方法的指令。

26.一种非瞬态计算机可读存储介质，包括一个或多个程序，所述一个或多个程序用于供空中OTA移动服务平台的一个或多个处理器执行并且包含指令，所述指令在由所述一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求15-24中任一项所述的方法。

27.一种方法，包括：

由空中OTA移动服务平台的一个或多个处理器接收来自移动客户端的传感器数据；

由所述一个或多个处理器将所述传感器数据存储在数据结构中，所述数据结构与用于所述移动客户端的唯一标识符相关联并且是存储在所述移动客户端上的数据结构的副本；

由所述一个或多个处理器将所述数据结构与在所述移动服务平台上运行的数据分析过程的实例相关联，所述分析过程将分析模型应用到所述传感器数据；

由所述一个或多个处理器处理在数据流处理管道架构中的所述传感器数据，所述处理包括将所述数据分析过程应用到所述传感器数据、以及基于所述数据分析过程的输出为所述移动客户端设备预测一个或多个维护事件；

由所述一个或多个处理器为所述一个或多个维护事件中的每一个标识严重性状态；

由所述一个或多个处理器根据所述一个或多个维护事件和严重性状态执行一个或多个动作。

28.如权利要求27所述的方法，其中，所述一个或多个动作包括向所述移动客户端发送警报消息。

29.如权利要求27-28中任一项所述的方法，其中，所述一个或多个动作包括：生成包含所述维护动作的描述和所述传感器数据的图或发生历史中的至少一个的报告。

30.如权利要求27-29中任一项所述的方法，其中，所述数据分析过程包括：将基于决策树回归、随机森林回归或梯度提升树回归中的至少一个的机器学习算法应用到所述传感器数据。

31.如权利要求27-30中任一项所述的方法，其中，所述一个或多个维护事件包含所述移动客户端的一个或多个部分的预测的预期寿命。

32.如权利要求27-31中任一项所述的方法，其中，所述一个或多个维护事件包含替换所述移动客户端的磨损部分或替换所述移动客户端所使用的流体中的至少一个。

33.如权利要求27-32中任一项所述的方法，其中，所述传感器数据包含由制动衬块传感器和制动流体传感器输出的数据，并且所述一个或多个维护事件包含所述制动衬块的预测的预期寿命和预测的制动流体更换时间。

34.如权利要求33所述的方法，其中，所述制动衬块的预测的预期寿命具有基于从所述传感器数据计算的里程范围的严重性状态。

35.如权利要求33所述的方法，其中，所述预测的制动流体更换时间具有基于从所述传感器数据计算的制动流体粘度指数的严重性状态。

36.如权利要求27-35中任一项所述的方法，其中，执行一个或多个动作包括下载数据以配置或重新配置所述移动客户端上的一个或多个软件组件。

37.一种空中OTA移动服务平台，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，所述一个或多个程序存储在所述存储器中并包括用于执行如权利要求27-36中任一项所述的方法的指令。

38.一种非瞬态计算机可读存储介质，包括一个或多个程序，所述一个或多个程序用于供空中OTA移动服务平台的一个或多个处理器执行并且包含指令，所述指令在由所述一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求27-36中任一项所述的方法。

39.一种方法，包括：

由空中OTA移动服务平台的一个或多个处理器获得保险索赔数据；

由所述一个或多个处理器基于所述保险索赔数据确定一个或多个欺诈指标；

由所述一个或多个处理器获得基于所述一个或多个欺诈指标的车辆数据；

由所述一个或多个处理器将所述车辆数据与指标范围进行比较；以及

响应于所述比较，由所述一个或多个处理器产生欺诈验证报告。

40.如权利要求39所述的方法，其中，所述车辆数据被包含在通过OTA服务从车辆收到的车载诊断报告中。

41.如权利要求39-40中任一项所述的方法，其中，所述车辆数据是从所述移动服务平台的数据存储库获得的历史车辆数据。

42.如权利要求39-41中任一项所述的方法，进一步包括：

由所述一个或多个处理器接收基于所述欺诈验证报告指示所述保险索赔的批准或拒绝的用户输入。

43.如权利要求39-42中任一项所述的方法，其中，所述一个或多个欺诈指标包含制动踏板力、减速峰值或制动不平衡中的至少一个。

44.如权利要求39-43中任一项所述的方法，其中，所述车辆数据包含速度、位置或传感器数据中的至少一个。

45.如权利要求39-44中任一项所述的方法，其中，所述比较进一步包括：

将所述车辆数据与所述欺诈指标的最小值和最大值进行比较。

46.如权利要求39-45中任一项所述的方法，其中，所述欺诈验证报告包含与索赔人相关联的索赔历史。

47.如权利要求39-46中任一项所述的方法，其中，由所述OTA移动服务平台向提供了所述保险索赔数据的保险提供者发送所述欺诈验证报告。

48.如权利要求39-47中任一项所述的方法，进一步包括：

由所述OTA移动服务平台利用电子邮件通知、通过由所述OTA移动服务平台提供的仪表板且经由网络服务或文本消息的警报通知中的至少一种，通知索赔管理员。

49.一种空中OTA移动服务平台，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，所述一个或多个程序存储在所述存储器中并包含用于执行如权利要求39-48中任一项所述的方法的指令。

50.一种非瞬态计算机可读存储介质，包括一个或多个程序，所述一个或多个程序用于供空中OTA移动服务平台的一个或多个处理器执行并且包含指令，所述指令在由所述一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求39-48中任一项所述的方法。

51.一种方法，包括：

由空中OTA移动服务平台的一个或多个处理器选择来自一个或多个移动客户端型号的一个或多个关键词；

由所述一个或多个处理器导入从一个或多个社交媒体平台中检索的社交媒体数据；

由所述一个或多个处理器提取所述社交媒体数据中匹配所述一个或多个关键词的部分；

由所述一个或多个处理器标识由所述一个或多个关键词描述或以其他方式标识的移动客户端的一个或多个所有者；以及

由所述一个或多个处理器发送一个或多个通信给所述一个或多个所有者，所述一个或多个通信包含匹配的社交媒体数据的一些或全部。

52.如权利要求51所述的方法，进一步包括：

过滤所述社交媒体数据以去除无关的符号和词。

53.如权利要求51-52中任一项所述的方法，其中，所述一个或多个通信包括电子邮件通信，所述电子邮件通信包含针对所述所有者的消息。

54.如权利要求53所述的方法，其中，所述消息包含所述社交媒体数据的至少一部分。

55.如权利要求51-54中任一项所述的方法，其中，所述社交媒体数据是推文。

56.如权利要求51-55中任一项所述的方法，其中，所述一个或多个关键词包含物联网(IoT)设备名称。

57.如权利要求51-56中任一项所述的方法，其中，所述一个或多个关键词包含车辆的品牌或型号。

58.一种空中OTA移动服务平台，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，所述一个或多个程序存储在所述存储器中并包含用于执行如权利要求51-57中任一项所述的方法的指令。

59.一种非瞬态计算机可读存储介质，包括一个或多个程序，所述一个或多个程序用于供空中OTA移动服务平台的一个或多个处理器执行并且包含指令，所述指令在由所述一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求51-57中任一项所述的方法。