用于经由空中接口稳健地更新车辆的固件的方法和设备与流程

本发明涉及用于经由空中接口稳健地更新车辆的固件的方法。除此之外，本发明涉及相应的设备、相应的计算机程序以及相应的存储介质。

背景技术：

在无线电技术中，数据借助于电磁波、即显然通过介质空气（over the air（空中），OTA）的传输有时被称为空中接口。这种空中接口的特征尤其在于，不使用固体的传输介质、如铜或者光纤电缆，这为了随后的实施的目的不排除真空中的传输。利用这种传输的电信技术方案例如作为空中编程（OTA）、空中服务提供（Over-the-Air Service Provisioning，OTASP）、空中提供（Over-the-Air Provisioning，OTAP）或者空中参数管理（Over-the-Air Parameter Administration，OTAPA）已知。

所提到的技术对于更新所谓的固件（FW）、即被嵌入到电子设备中的这种软件来说是特别有意义的。上面所提到的OTA技术的根据固件被适配的修改方案在电信中以上位概念“固件空中编程（FOTA）”被概括。

DE 10105454 A1提出用于经由空中接口来自动地补充软件的方法，所述方法用于通过新的软件模块来补充在系统上运行的软件，其中这些软件模块首先被测试并且然后从这些软件模块导出应用模块。

技术实现要素：

本发明提供根据独立权利要求的用于经由空中接口稳健地更新车辆的固件的方法、相应的设备、相应的计算机程序以及相应的存储介质。

该解决方案的优点在于软件（SW）的以及尤其固件（FW）的空中更新的稳健性的提高，使得在针对原始设备制造商（original equipment manufacturer, OEM）和终端客户的实际采用中的问题被避免。在这种情况下重要的是理解：OTA场景在没有车间的支持的情况下应当以高的稳健性可靠地运转。一般来说本身功能正常的车辆在这种情况下获得FW更新或者另外的SW更新，以便扩展功能范围或者消除错误并且因此不允许在OTA更新之后变为损坏的、即不能行驶的。这使OTA场景基本上区别于常规的车间场景。根据本发明的一种实施方式的稳健的解决方案满足相应地高的客户期望。

稳健性根据IEEE、ISO/IEC描述系统或组件的、即使当系统和系统环境尤其遭受在系统边界处充分利用的影响和条件或者出现未知的输入值时也正确地保证功能性的程度。

这里所提出的解决方案不仅仅涉及各个SW组件或硬件组件，而是由一系列功能以及尤其其有意义的互相配合和涉及的架构元件构成。

随后的实施方案描述如何与车间中的经典的SW更新以及尤其FW更新类似地自动化地在车辆中进行例如车间人员的活动，所述活动当在车间中执行更新时保证稳健性。用于进一步提高稳健性的选项同样是极好的。

本发明的一个方面涉及用于以下总链中的子活动的稳健的FOTA更新：车辆客户端和后端之间的交互、到车辆中的下载、存储和管理、分发和更新以及事故处理（disaster handling）。作为另外的处理步骤的车辆更新数据集成、后端预处理以及回滚和恢复（recovery）对于本领域技术人员来说充分已知并且不是随后的实施方案的主题。

本发明的另一方面是如下技术系统，所述技术系统由一个或多个后端系统和车辆子系统构成。

因此，所述系统的核心由用于单个车辆中的OTA-SW更新以及尤其FW更新的车辆子系统、用于车辆的车队或群组的更新的后端子系统以及这些组件的交互构成。

附图说明

本发明的实施例在附图中被示出并且在随后的描述中进一步被解释。

图1示出本发明的实施方式所基于的架构。

图2示出具有交互依赖性和责任的自主区域中的功能组件的分配。

图3示出在考虑时提高稳健性的示范性的条件。

图4示出根据本发明的协调层和安装实施功能的透明的处理。

具体实施方式

所述系统加建在图1中所图解的技术架构上，所述技术架构不仅提高模块性、可扩展性和可适配性，而且提高稳健性。数据下载为此在如下组件中被分开，所述组件不仅被实现为后端20中的下载服务器21而且被实现为车辆10中的下载客户端11。设备管理在如下组件中被分开，所述组件不仅被实现为后端20中的设备管理服务器26而且被实现为车辆10中的设备管理客户端16。车辆侧的代理被用于将设备管理——例如在多个域中——的分布式实现方案捆绑成唯一的实现方案。

软件更新和软件管理在如下组件中被分开，所述组件不仅被实现为后端20中的SCOS服务器22和FCOS服务器23而且被实现为车辆10中的应用软件更新客户端12和固件更新客户端13。这里，SCOMO/FUMO将根据OMA-DM的功能性称为示例性的实现。

车辆管理部25用于使“设备”具体化为车辆10，包括其相关的拓扑、即控制设备（electronic control units（电子控制单元），ECU）和子系统。

在后端20侧的专业的数据处理在车辆内容管理部28中被分开，所述车辆内容管理部将数据状态的不同的版本和变体绑定到车辆10上。包括活动控制在内的更新逻辑也被分开，所述更新逻辑不仅被实现为后端20中的车辆更新服务器24而且被实现为车辆10中的车辆更新客户端14。

车辆10中的数据管理作为内容管理部18被分开。相应的内容适用于为了车辆10中的ECU更新而被分开的固件更新组件，所述固件更新组件可以存在于多个变体和实例、例如应用软件更新客户端12或固件更新客户端13的那个变体和实例中并且能够更新不同的系统和技术。

从现在起详细地解释所提及的组件的内容和功能。

车辆管理部25针对所有目的对多个车辆10（在车辆10的集合或群组的意义上）的、一个车辆10本身及其车辆拓扑的认识负责并且能够将设备映射到由设备管理部15、16、26所提供的车辆10上。设备管理部15、16、26识别设备、未必车辆10或已知的车辆10并且为此与设备、未必车辆10或已知的车辆10通信。多个设备在此可以被联合为车辆10。设备管理部15、16、26仍然可以识别其它设备类型、例如割草机。设备管理部15、16、26因此识别设备类型，以便允许转发给其管理功能。在当前示例中在此涉及车辆管理部25。

设备管理服务器26能够利用所属的设备来执行所有的管理行动。为此，协议是必要的，以便将这一类的管理对象运送到设备以及从设备运送这一类的管理对象。

设备管理部15、16、26能够操纵不同类型的多个设备。已知的设备借助于数据管理部27来识别以及确定类型，以便变为“已知的设备”。已知的设备被传递给所属的管理功能、当前被传递给车辆管理部25。为了后续实施的目的假定：所有的设备被确定类型为“道路车辆”并且通过车辆管理部25来处理。设备管理部优选地仍然能够也支持其它的类型和应用情况。

设备管理客户端16实现在所属的运行时环境中从设备管理服务器26出发引入软件组件管理。设备管理驱动器通过设备管理客户端16支持设备识别和参数配置。设备管理客户端16又与如下环境中的一个或多个设备管理代理15相互作用，所述环境经由可选的设备管理代理主管管理活动借助于所提供的软件组件管理对象的执行。设备管理客户端16采用一般的警告机制，以便通知包括管理活动的状态的最终的消息。

如果存在设备管理客户端16的多个实例，则该活动作为尽可能好的替代方案通过设备管理客户端16以及附加的设备管理代理15的唯一的实例来实施。为了在每个车辆10唯一的设备的情况下仍然可以支持多个设备管理客户端16，使用设备管理代理。设备管理代理15的一个实例因此运行在每个有IP能力的系统46上并且利用设备管理客户端16的中央代理。

设备管理代理组件实现避免设备管理客户端16的多个实例。为此，每个设备管理代理将设备管理管理对象引导以及聚集到设备管理客户端16处。设备管理代理可以在不同的运行时环境中运行。代理是主管的并且确保车辆10和设备之间的明确的分配。

车辆内容管理部28在后端20侧主管对内容进行映射、针对传输必要时进行压缩以及针对关于软件更新的使用进行打包。车辆内容管理部从数据管理部27接收数据和内容，该数据管理部以统一的方式存储数据和内容。因此，关于车辆10之内的数据和内容的OEM差异被数据管理部27完全地遮盖。这也导致数据管理部27的输出和车辆10侧的所属的内容管理部18之间的明确的语义的以及句法的关系。

SCOS服务器22负责用于应用软件更新的管理对象的构建和传输。在使用OMA-DM的情况下这可以通过利用SCOMO协议和管理对象来实现。SW更新客户端12主管SCOS指令的实施。所述SW更新客户端使用被提供给设备的软件组件并且保障：传送成功结果或错误结果的警告被引导回到SCOS服务器22处。为了在每个车辆10唯一的设备的情况下仍然可以支持多个SW更新客户端，使用多个变体和实例。所有的SW更新客户端实例12在这种情况下由车辆更新服务器14指挥。因此，SW更新客户端12的实例可以在每个有IP能力的系统上运行。

下载服务器21负责稍后要传输的更新包的提供。下载服务器21从车辆数据管理部27得到其内容，通过车辆更新服务器24来协调。这确保：仅仅车辆10实际上使用以及需要的那些更新包通过下载服务器21是可用的。

通过下载服务器21的价值创造链“车辆更新请求、内容编制、内容提供”因此仅针对在所定义的活动之内活跃的车辆10被执行。

下载客户端11主管软件组件、固件或其它内容到车辆10中的下载。下载客户端11可以支持DLOTA或任何一个其它的例如基于HTTP、HTTPS或FTP的空中接口29。下载客户端11优选地拥有经由内容管理部18到内容存储器17的接口。

车辆更新服务器24主管车辆更新过程的协调层。换言之：所述车辆更新服务器实施一个所定义的更新活动或多个所定义的更新活动。针对确定的车辆10的活动的最初通过OEM数据和服务管理所写的规范能够从数据管理部27得到。该规范将所需的服务和流程连接为所得到的更新过程。当车辆10被车辆管理部25识别出以及注意到时，其状态和状况持久地被数据管理部27监视。

车辆更新客户端14主管车辆更新服务器24的请求的实施。车辆更新客户端14因此协调针对车辆10的车辆更新过程或者其任意的部分，包括应用软件更新。为了实现灵活性和到现有的技术的简单的结合，车辆更新客户端14还实现到设备管理部的管理接口。此外，车辆更新客户端14承担针对所下载的内容的责任，接收涉及车辆10的部分、例如更新过程数据和其它辅助信息，并且将更新和内容布置（delegiert）给客户端12和13。如果例如使用OMA-DM，则可以使用FUMO和/或SCOMO对象。

数据管理部27在后端20侧主管将一致的数据和内容提供给服务。

内容管理部18主管持续地存放车辆10之内的任何类型的内容。所述内容管理部可以说用作车辆10的包括从网络源加载数据的能力在内的网络连接存储器（network-attached storage（附网存储），NAS）。内容存储器17的多个实例可以存在于车辆10之内并且由内容管理部18管理。内容管理部18关心数据的存储、解包以及拼合并且可以被用于车辆10之内的任何类型的应用。

内容存储器17主管持续地存放控制设备（electronic control unit（电子控制单元），ECU）之内的任何类型的内容。可以说如面向字符的设备文件（raw device（裸设备））那样被使用。内容存储器17的多个实例可以存在于车辆10之内并且由内容管理部18管理。内容存储器17关心存储并且可以被用于车辆10之内的任何类型的应用。

控制设备更新客户端12或者13主管针对确定的控制设备或者确定的子区域的应用软件更新或固件更新的实施。控制设备更新客户端12或者13充当客户端并且与车辆更新客户端14连接。所述控制设备更新客户端管理针对确定的控制设备或确定的子区域的包括回滚在内的应用软件更新过程或固件更新过程。除此之外，所述控制设备更新客户端主管：控制设备或子区域的状态随时是已知的。

通过将（车辆子系统的）总功能性划分为封闭的以及去耦的组件，可以把将会导致总功能性的被改变的特性的影响因素减少到子功能性上。为此，作为这种已知的架构模式和设计模式（design patterns）使用诸如无冗余（具有所定义的以及分离的任务范围的相干系统减少冗余）以及松耦合，所述无冗余以及松耦合总得来说将未知的输入值或充分利用的影响和条件的影响限定、减少到涉及的接口上或者在那里使所述影响能够识别。

基于这里所介绍的设计和这里所介绍的架构的技术系统尤其实现以如下方式来处理无效的或者未知的输入值或充分利用的影响因素和条件，即这种影响因素仅对涉及的组件的特性发生作用（局部性）以及该被改变的特性在到上级的、进行监视的以及进行控制的组件的接口处显示出能够识别（透明性）。这实现系统的分级的以及整体的反应。

当SW组件或硬件组件或功能失效或者未在所规定的序列之内以结果向上级的组件发回报告等时，该解决方案系统中的功能的互相配合涉及交互。相反地，例如上级的实例的失效对关于SW更新以及尤其FW更新的具体的并且专门的组件不造成影响或造成小的影响。

被去耦的稳健性在随后的点中详细地加以描述：

系统的稳健性在第一步骤中通过如下方式被提高：在OTA-SW更新以及尤其FW更新期间系统的总特性的稳健性不受充分利用的以及必要时反常的系统环境条件影响，而是已经通过被去耦的组件识别出以及拦截子特性的影响。

总功能性的去耦和对由组件经由其它组件和功能的松耦合提供的子功能性的访问在第二步骤中导致经由松耦合所需要的依赖性关系和责任关系。即OTA-SW更新总功能性以及尤其FW更新总功能性是去耦的并且造成：子功能性必须从上级的组件被布置给下级的被去耦的组件用于实施并且必须从下级的组件被提供给上级的组件。

在这里所提出的系统的第三细节化步骤（Detaillierungsschritt）中进行进展报道（经由松耦合来规定）以及上级的组件和功能的认可的取得。如果出现特殊的条件，那么这是有利的。观察以下示例：所布置的行动必须重复地被实施，因为在实施中出现了错误。

以下组件中的每个基于其专门化（例如数据的稳健的下载或者无错误的存放以及保存）不中断地执行所分配的行动，只要该组件不被上级的组件和功能以其它方式控制（中断、暂停、继续），如在图2中所示出的那样：经由空中接口29与后端20相互作用的连接模块31、车辆10之内的与连接模块31相互作用的稳健的数据保持模块32、与连接模块31和数据保持模块32相互作用的协调层33、与连接模块31和协调层33相互作用的用户交互34和与数据保持模块32和协调层33相互作用的安装35。

连接模块31在此包括与后端20的自主的交互和最后的已知的车辆状态的获悉和分析以及所托付的下载或上载的自主的执行和经由空中接口29的连接的稳健的操纵。数据保持模块32包括自主的存储和存取特许（Einräumung von Zugang）以及存储空间的依赖于协调层33的预留和释放。安装35以由协调层33所授予的允许以及被限于目标对象的控制权限来进行并且包括安装36的控制、支配、决定、实施以及监视。

如下方向一方面在其涉及另外的下级的组件、例如软件更新客户端12、13时由车辆更新客户端14来控制，并且另一方面也由组件本身、例如连接模块31借助于下载客户端11或者设备管理客户端16或者用户交互34来控制，报告递交（handover（移交））以该方向进行。因为如果由于关键的薄弱环节（single point of failure（单点故障））车辆更新客户端14失效并且参与的组件、如用户交互34或连接模块31尝试与车辆更新客户端14交互，但是由于所述失效而未到达所述车辆更新客户端，则这些组件至少独立地能够利用其自身的组件功能性并且执行报告和交互并且将最后的已知的步骤用于另外的行动。在连接管理部31的示例中设备管理客户端16将会在增加最后的已知的步骤和信息的情况下向后端20报告例如车辆更新客户端14的失效。在用户交互34的情况下将会通知用户：存在内部的错误并且车辆更新客户端14不可达（自主性）。

随后示出基于被去耦的稳健性、局部性、透明性和自主性的FOTA总系统的也被示出在图2中的并且已经被解释的稳健性，其方式是针对功能组件中的每个来描述与其它的被去耦的功能组件的互相配合。

借助于车辆更新客户端14的稳健的协调层33处理在ECU层面直至车辆层面上的以及作为另外的选项在事故层面上的问题（要在后端20中解决）。

指挥组件能够针对每个要单独地执行的更新不易混淆地明确地识别、管治所有相应的数据和行动以及实现对其的访问，其方式是，与车间人员将会人工地完成的那样相似地，所述指挥组件管理以及管治关于数据或行动的存在性并且将引用（或者数据本身）提供给数据保持模块32、连接模块31或更新客户端组件。

指挥单元利用数据保持管理部32和连接管理部31的功能性，其方式是，其提供必需的信息，以便可以与协调层33去耦地执行更新数据的下载并且可以将所下载的数据保存在被担保的存储位置处并且针对涉及的以及等待处理的下载存在足够的存储空间，使得只要指挥单元实现并且管理数据的存在性，这些被保存在车辆10中的数据就可以在每个稍后的时间点由其它的被授权的组件使用。

协调层33确保所有必需的输入参量，所述输入参量允许协调层33随时完全地开始、继续更新，或者当针对更新所定义的可供协调层33使用的输入参量和额定值不与ECU、客户端、车辆10或用户交互34的真实的状态一致时也使所述更新停止，或者甚至当协调层33与连续的更新安装并行地从后端20经由连接模块31获得回复时例如不执行并且丢弃已经被分配的更新（图3）。确保所有必需的输入参量也包含：存在必需的车辆环境条件并且允许协调层33主动地激活或去激活车辆功能并且因此例如当这被定义为了必须存在以便可以执行更新的额定值时操作电子手刹。协调层33此外能够当更新被执行了时使用于达到确定的“对于更新过程来说有益的”车辆状态的所有被执行的活跃的行动重新回到原始的状态中并且因此例如重新将电子手刹去激活。

协调层33例如可以参照图3依赖于以下情形中的至少一个：车辆状态50可以被询问（37）并且对应于所预给定的额定值（38）；车主或者车辆10的驾驶员同意安装36（39）；控制设备的状态51可以被询问（40）并且对应于所预给定的额定值（41）；对于安装36来说所需要的时间总得来说以及对于涉及的控制设备来说是已知的（42）；对于回滚（43）来说所需要的时间总得来说以及对于涉及的控制设备来说是已知的（43）；软件更新客户端12、13的进展可以被询问（44）并且对应于所预给定的额定值（45）；控制设备和软件更新客户端12、13的功能性可以被利用（46）；流程逻辑或配置说明应等待不能够访问的信息多长时间（47）；对所有涉及的组件的更新数据和回滚数据的访问是可能的（48）；或者更新数据以及回滚数据是局部地存在的（49）。

所有的软件更新客户端12、13能够以对于ECU来说特定的方式执行该ECU的实际的更新（安装36）。软件更新客户端12、13如其它的是车辆更新客户端14下级的客户端、例如下载客户端11那样能够特定地实施自足式的以及专门的功能（图4）。软件更新客户端12、13此外能够在其功能上确定错误并且引入对策。因此，所述软件更新客户端与车辆更新客户端14相互作用——例如当回滚36必须被实施并且所述回滚对车辆层面上的功能性具有影响或者将报告信息传送给后端20或者经由用户交互34来传送报告信息时获得授权——以便了解车辆状态50并且可以控制所述车辆状态的车辆更新客户端14最后可以控制总更新，在考虑车辆10的行驶能力的可用性的情况下可以保证车辆10的所定义的状态51，或者甚至在不能遵守的关于总系统的条件的情况下或者在不能解决的问题的情况下（例如ECU在更新之后完全不再作出反应并且车辆更新客户端14识别出这一点，因此车辆行驶功能是受损的）可以执行向用户的递交。在软件更新客户端12、13不作出反应的情况下车辆更新客户端14能够引入对策。

车辆更新客户端14在每个相关的更新步骤将报告信息发送给后端20，其方式是，所述车辆更新客户端从下级的组件和功能收集信息并且将这些信息递交给连接模块31，所述连接模块被设计为将这种数据经由存在的通信路径独立地发送给后端20。

车辆更新客户端14以依赖于情形的方式来决定：何时以及经由哪个交互路径——例如经由人机接口（human-machine interace，HMI）或者其它的连接的用户交互34——进行向终端用户的递交。

稳健的数据保持模块32（内容管理部18）由协调层33来控制并且获得关于要为等待处理的下载或者例如为数据的备份提供的存储空间的信息。因为协调层33是上级的组件和功能，所以确保：例如要为等待处理的下载预留的存储空间一直被确保证，直至指挥功能例如在成功的更新安装之后、在回滚36之后或者在更新完全地被丢弃了之后将所述存储空间重新释放。

数据保持模块32向协调层33（以及其它组件、如连接模块31）连续地、例如在错误时或者当所计划的大小的下载完整地存在并且由数据保持模块32完整地保存了时通知报告，使得协调层33可以执行另外的更新步骤和安装步骤并且检查条件（见图3）。替代地，连接模块31也可以代替数据保持管理部32直接向协调层33连续地报告关于下载的错误。

借助于下载客户端11和设备管理客户端16的稳健的连接模块31将能够明确地识别的数据从后端20经由已知的接口和通信可能性加载到车辆10中。所述连接模块能够经由稳健的路径将数据完全地以及无错误地存放到车辆10中，其方式是，所述连接模块可以通过经由松耦合与数据保持模块32的交互来检查确实在车辆10中已经被下载的以及可靠地被保存的数据集并且可以向后端20请求准确的缺少的数据集并且可以从如下字节起继续下载，在所述字节处所述下载当时已停止并且所述下载最后确实可靠地被存放在了车辆10中，以及因此空中接口连接中断和后端20的其它回复无错误地以及稳健地在组件系统边界处被处理。

数据保持模块32实现所下载的数据的存放，所述数据保持模块提供将数据与其被递交了的一样经由明确的引用来完整地以及防伪造地进行保存的功能性。

连接模块31例如当到后端20的连接突然被中断时对不同的输入作出反应，或者对后端20的更特定的应答信息作出反应。当例如所下载的数据的存放和保存造成错误时，所述连接模块例如也对此作出反应并且依赖于数据保持管理部32的输入来控制下载过程和重新开始过程（resume（重新开始））。

连接模块31能够将从后端20所接收的输入转发给其负责的组件。在此情况下，车辆更新客户端14是上级的实例，所述实例控制关于更新的所有涉及车辆10的功能性并且也动用下级的组件的功能性。

后端20给每个车辆10的连接模块31提供特定的更新数据并且提供如下信息，所述信息可以被连接模块31和车辆更新客户端14利用，以便在车辆10中及时地提供对于等待处理的更新来说必要的存储空间并且将涉及的对于车辆10来说明确的以及不易混淆的更新数据的稳健的下载经由空中接口29加载到车辆10中，使得稳健的、节省资源的以及顺利的更新可以进行。

后端子系统除了关于所调用的后端接口的信息之外通过车辆10的连接模块31经由车辆的每个所定义的更新步骤针对涉及的活动附加地获得报告信息。基于可供后端20使用的关于接口调用的信息以及车辆10的关于活动的报告信息，后端20执行这些可用的报告值与在涉及的活动中所规定的阈值的实际-额定比较并且必要时在剩余的车辆10侧获得控制行动（使活动暂停、停止、继续），在所述剩余的车辆中涉及的更新还等待处理或者恰好被执行。通过后端子系统和车辆子系统的互相配合提高稳健性，其方式是，根据预给定数量的车辆10的每个更新步骤的结果推断出更新的稳健的以及正确的实施并且在未来的车辆10处避免有错误的或者错误的更新。

基于报告信息的分析活动负责人和更新负责人甚至可以改进更新活动并且重新展开更新活动。

子系统层面上的功能的所介绍的互相配合（如后端子系统和车辆子系统互相配合）以及车辆层面上的功能的所介绍的互相配合（如组件和功能互相配合）示出：车间人员的传统的步骤如何自动化地在车辆10的OTA场景中自动化地被执行。协调层33主要对应于车间人员，所述车间人员针对稳健的以及正确的更新确保车辆状态50，例如存在足够的供电，其方式是，将外部的备用电池连接在车辆10上（车辆更新客户端14，所述车辆更新客户端被动地并且主动地观察车辆系统环境的实际状态和额定状态并且例如在更新之前检查：电池状态是否对应于等待处理的更新的持续时间并且在更新期间连续地检查所述电池状态），或者其方式是，针对每个涉及的控制设备单独地或者由中央的车间诊断测试器来实施闪存存储器（flashing）的改写，但是给该闪存存储器提供正确的数据（车辆更新客户端14，所述车辆更新客户端将实际的更新安装36布置给涉及的软件更新客户端12、13并且相互作用）并且在每个闪存步骤或者安装步骤之后在单个的ECU处检查：改写和安装36是否无错误地进行（车辆更新客户端14，所述车辆更新客户端在更新之前、期间和之后以及在每次安装36之后了解并且主动地影响在更新时涉及的ECU和软件更新客户端12、13的实际-额定状态51）。

车辆更新的该总协调层33在扩展的形式中是协调层33或者车辆更新客户端14的任务，所述车辆更新客户端可以以及必须在车辆10的行驶运行期间执行所有的指挥工作和管理工作并且必须决定车辆10必须何时针对哪些子行动处于确定的车辆状态50中（并且例如不允许移动），其方式是，所述车辆更新客户端比较涉及的控制设备的额定值并且对所述额定值主动地作出反应。

随后的应用情况（use cases）示例性地示出流程。应用情况包含应当被实施的核心行动和核心步骤。核心步骤对应于已经介绍的功能组件（连接模块31、数据保持模块32、协调层33）或者部分地被包含在这些功能组件中并且与其它功能组件独立地加以描述。

连接模块31从被鉴权的后端20获得数据。在所述数据中包含有FOTA信息，所述FOTA信息从连接模块31被转发以及提供给作为被分配给FOTA数据的单元的协调层33。并行地，连接模块31已中间存储关于获得以及关于FOTA数据向负责的组件的成功的进一步分发的报告数据并且（根据连接模块31如何被配置用于与后端20通信）必要时立即通知后端20。

FOTA更新可用性信息因此不仅到达车辆10（例如因为之前触发了关于终端用户或后端20的更新可用性检查），而且到达车辆10中的负责的目标功能组件（协调层33或者车辆更新客户端14）。这些负责的组件解释FOTA数据并且识别可用的更新，哪个存储空间被需要用于实际的更新数据和回滚数据的下载以及用户交互34必须进行到什么程度以及是否必须进行，例如之前必须从用户取得许可证协定（license agreement），一般地甚至下载必须由用户经由交互来确认，或者涉及用于在背景中实施的“静默更新（Silent-Update）”，而用户不必针对更新被并入，或者因为许可证协定是完全不需要的。

与每个所描述的步骤并行地，将针对后端20所确定的报告信息递交给连接模块31。连接模块31中间存储这些报告信息，以便将所述报告信息在确定的合适的时间点发送给后端20或者必要时在呈递之后立即将这些报告信息发送给后端20。后端20能够解释这些关于车辆10中的更新的实施的报告信息以及在大量另外的车辆10上聚集地利用这种类型的报告信息，以便控制更新活动并且例如当关于确定的更新步骤的报告信息容许识别有错误的实施时暂停更新活动。

协调层33 利用FOTA更新信息并且容许在数据保持模块32中检查所需要的存储空间的可用性并且如果存在，则以能够明确地识别的方式来预留所述存储空间（明确地，因此所述协调层在结束之后或者在任意的情形中必须与所述存储空间被预留了一样重新释放存储空间，因为协调层33检查以及控制车辆状态50并且主管总更新的流程）。

如果协调层33首先已一次性取得其需要的所有所需的信息（在需要时，用户通过交互的确认，或者数据保持管理部32经由可用的存储器的担保等等），则其并行地重新将报告信息呈递给连接模块31，但是也继续平行地实施另外的更新流程步骤，如果这些更新流程步骤被包含在FOTA信息中，并且作为下一步骤将实际的更新数据的下载布置给连接模块31，其方式是，其使用来自FOTA信息的下载描述符——统一资源指示符（uniform resource locator（统一资源定位符），URL），存取信息（credentials（证书））等——并且附加地给连接模块31提供如下信息：要下载的数据应当在哪里以及如何被保存（更确切地说在预留的存储区域中）。

连接模块31实施所布置的任务并且在下载期间必要时考虑更大的兆字节数据或千兆字节数据以及经由OTA空中接口29可能出现的不同的影响。所述连接模块自主地以及独立地起作用并且引起稳健的下载过程以及利用给其上级的或者参与的实例和功能组件（协调层33、数据保持模块32）的报告信息直接地对关于下载过程的查询作出反应。这里在将下载任务布置给连接模块31之后也并行地将用于转发给后端2的报告信息递交给连接模块31。如果必要时必须经由用户交互34将状况转交给用户并且与用户的这种类型的交互被定义在了FOTA信息中并且被协调层33解释了以及因此必须这样来实施，则连接模块31向协调层33和用户交互34通知下载的状况。

一旦下载结束了并且所下载的数据以能够完整地以及可靠地访问的方式待用，就由连接模块31以及必要时也由数据保持模块32通知协调层33。

协调层33解释来自所下载的车辆10更新包的数据部分——所谓的更新流程逻辑（flow（流程））和用于具体的更新安装的所属的条件，所述数据部分说明：在可以完全地开始实际的更新安装之前，当例如之前也必须由终端用户（驾驶员）进行另外的许可证确认时，或者因为车辆10例如必须被置于确定的状态51中并且用户的确认取得是必需的，用户交互34必须继续进行到什么程度以及是否必须取得例如在由协调层33 所提出的时间点以及附加地基于随后的FOTA流程逻辑数据来实施更新的同意。这些信息作为流程逻辑是经由连接模块31所下载的车辆更新数据包的组成部分。其中此外可以包含：例如总更新持续多长时间，涉及哪些安装实施（软件更新客户端12、13），涉及哪些控制设备或者车辆域、例如信息娱乐或车身控制（body control）以及车辆10必须处于哪个状态51中，即由等待处理的更新安装所涉及的控制设备和软件更新客户端12、13中的一些仅允许在例如车辆10的电池状态具有确定的充电状态（level（水平））时被实施，因为控制设备上的更新时间将会要求这一点。

协调层33检查被包含在更新流程逻辑中的额定值并且将这些额定值与车辆10的实际值进行比较，其方式是，其使用必需的车辆接口并且因此例如获得车辆10的电池状态以及必要时电池放电的当前程度并且在额定-实际值比较中决定：安装36是否可以完全被启动。如果安装36已经被启动了并且车辆更新客户端14并行地基于要遵守的额定值连续地以及与各个安装36的实施并行地例如突然地确定：实际值、诸如电池状态与所定义的额定值相比较在所定义的时间点未被超出，于是那个更新安装例如被暂停、中断或者重新被实施——依赖于：当电池未超出额定阈值时，最后在更新流程逻辑中定义了什么以及应如何处理这种情况。如果电池状态的额定阈值的这种未超出对车辆状态50具有影响并且必要对车辆行驶功能性具有影响以及完整的实施作为更新安装的组成部分被定义在更新流程逻辑中，则更新安装可以完全被终止或者立即的中断可以被发起，以及根据例如回滚36可以如何快地被执行以及这是否被定义在更新流程逻辑中以及必须存在哪些附加的条件，例如用于实施的回滚36可以被布置给车辆更新客户端12、13。在暂停的情况下——根据在更新流程逻辑中针对这种特殊情况作为另外的行动定义了什么——车辆更新客户端14以中断命令来操控相应的软件更新客户端12、13。车辆更新客户端14将会根据其特定的功能性将其当前的连续的行动必要时实施至结束并且使ECU留在由车辆更新客户端14所定义的（即使未完全可运转的）状态51中或者必要时中断所有连续的行动并且以状况状态向车辆更新客户端14报告，使得车辆更新客户端14了解软件更新客户端12、13以及控制设备的状态51并且根据其更新流程逻辑规则（以考虑车辆状态50的方式）可以进一步行事。软件更新客户端12、13的暂停意味着：使所述软件更新客户端置入所定义的状态51中，其方式是，软件更新客户端12、13留在关于安装步骤所定义的状态51并且例如存储用于会话（session）的所有必需的信息，以便所述软件更新客户端能够例如当重新存在有效的电池电平时在暂停结束之后在其已停止处继续进行，而因此不重新以最初由车辆更新客户端14所布置的实施开始。软件更新客户端12、13的中断意味着：完全地中断当时所布置的实施行动并且必要时重新以新的输入值开始。

协调层33在开始时检查：所涉及的软件更新客户端12、13中的哪些针对特定的以及分离的更新安装完全根据确定的目标控制设备或者根据目标域被专门化以及这些软件更新客户端12、13中的哪些涉及车辆状态50和车辆行驶功能性以及哪些单独的以及特定的更新安装在顺序实施中依赖于其它更新安装，以便在例如取得了终端用户的起始确认之后因此已经（与其它更新安装的更新安装启动的进一步处理以及确定并行地）实施独立的以及不涉及车辆状态50的单独的更新安装。剩余的以及例如涉及车辆状态50的单独的更新安装可以必要时要求更多的时间，直至针对实际的更新安装的最优的时间点可以出现，因为例如当必须存在确定的电池状态或者涉及的控制设备仅允许在被关闭的车辆状态50中被更新以及因此例如经由涉及的总线通信信道的确定的被要求的数据速率可用，以便也可以遵守在更新流程逻辑中所计划的更新安装时间时，例如车辆10中的较大规模的状态51被要求并且车辆10中的多个额定-实际值比较以及状态51必须被满足（因为例如涉及发动机控制设备）。在影响车辆行驶功能性的情况下更新安装的最优的时间点的确定例如也可以通过如下方式被延迟，即根据车辆功能性的失效在确定的时间通知终端用户并且所述用户必须同意以及即使那时还必须出现如下情形：车辆10确实停止并且只有那时控制设备上的对车辆行驶功能性具有影响的更新安装可以以由相应的软件更新客户端12、13发起的方式由车辆更新客户端14执行。可能的特殊情况如下：驾驶员行驶长的路程并且在高速公路上停车。车辆更新客户端14确定：所有条件被满足并且车辆10例如也停止并且实施发动机控制设备处的更新安装。终端用户登上车辆10中并且想要乘车出发，但是例如必须等待几分钟，因为由车辆更新客户端14人为地导致的车辆状态50（车辆10在更新安装期间不允许启动或者是行驶准备就绪的）不允许继续行驶。一种扩展的特殊情况将会如刚才所描述的那样，区别在于：更新安装失败并且例如发动机控制设备也在回滚36之后不再运转并且车辆10处理事故并且驾驶员在其长的旅途上不再能够继续行驶。由此可见：终端用户的确认和最优的时间点的确定是非常重要的。

因此总得来说车辆更新客户端14将实施行动、诸如存储空间预留、下载过程或更新安装步骤布置给软件更新客户端12、13，所述软件更新客户端主管所涉及的域中或者所涉及的控制设备处的更新安装并且本身确保必需的车辆状态50和ECU状态51，其方式是，其例如不仅布置实施行动，而且容许事先检查例如软件更新客户端12、13和ECU的可达性，检查电池状态和车辆模式（车辆停止或者车辆行驶），将用户交互34和用户回复并入以及将各个返回值一起包括到其额定-实际值比较中。该指挥工作于是可以由协调层33或者由车辆更新客户端14本身来执行，而各个已经被布置的实施继续，并且额定-实际值比较并行地被执行，其方式是，其向功能组件要求状况信息、进展信息和可达性信息并且也提供这些状况信息、进展信息和可达性信息（图3、图4）。

通过其透明的、将关于每个相关的步骤的报告信息提供给其观察者（observer）（连接模块31、用户交互34）的责任来确保：即使在协调层33失效的情况下被去耦的以及自主的功能组件也可以例如向后端20或者直接经由用户交互34向用户转交最后的已知的状态51以及例如失效。

更新流程逻辑定义要么是面向数据的并且在车辆10中存在实现对方位置（Implementierungsgegenstelle）（这里：协调层33或者车辆更新客户端14），所述实现对方位置解释数据并且例如可以理解和实现所有的出现的属性、参数和值，要么更新数据流程逻辑定义针对车辆10及其特定的连续的（end-to-end（端对端），E/E）车辆模型和E/E车辆拓扑包含能够特定地并行地实施的在脚本意义上的规则或更新流程逻辑，所述脚本借助于解释器同样由协调层33来实施。

如果车辆更新客户端14通过车辆10之内的实际-额定值比较在更新——例如当前的SW版本以及尤其FW版本根据目标SW版本以及尤其FW版本的检查——之后已确定：车辆更新成功地进行了，则其能够——根据其如何在更新流程逻辑中被定义了、步骤应何时在哪些条件下在成功的更新之后被实施、例如当SW版本以及尤其FW版本的额定-实际值比较成功了时——重新释放所预留的存储空间并且删除旧的更新数据，其方式是，其与数据保持模块32相互作用。

稳健地处理特殊情况例如也包含以下方面：

在更新已经在车辆10中被实施期间通过后端20的更新可用性中断触发允许：车辆更新客户端14可以中断和取消连续的或者已经被执行的更新，其方式是所述车辆更新客户端容许执行软件更新客户端12、13的回滚行动。

例如当存储空间可用性（出于不同的原因）不再被给定时，车辆更新客户端14获得相应的状况信息并且可以基于其更新流程逻辑来控制车辆10处的更新。

当例如涉及的软件更新客户端12、13或ECU的状态51不再是可用的或者所涉及的ECU和软件更新客户端12、13的状态51不再能够被车辆更新客户端14查询时，车辆更新客户端14确保确定的车辆状态50并且向其观察者报告。

作为附加的元素有助于稳健性的选项包括双重架构，FOTA组件和功能被分布在所述双重架构中。