更新方法和多域嵌入式系统与流程

本发明涉及一种用于更新多域嵌入式系统的方法以及一种多域嵌入式系统。

背景技术：
从http://de.wikipedia.org/wiki/Update可获得有关软件更新的信息。在PC领域，存在软件更新机制，这些更新机制定期或者在插入新的设备时检查是否需要进行软件更新。通常，软件更新包括微小的改进（如在程序执行速度方面的优化）并消除了特定软件发布版本内的错误，也被称为维修发布版本、补丁或热修复。与计算机安全领域相关的更新被称为安全性更新。安全性更新确保了消除程序中的安全漏洞。对于操作系统，具体来说，应在新的安装之后立刻并在此后以几天的时间间隔定期安装所有可用的安全性更新，以便消除已知的安全漏洞。在这方面，微软公司的PatchDay（补丁日）是已知的例子，在每个月的这一天，将Windows产品更新到最新版本。从http://en.wikipedia.org/wiki/Firmware可获得有关固件的信息。在电子系统和计算中，固件是一个术语，通常用来表示固定的（通常相当小的）从内部控制各种电子设备的程序和/或数据结构。包含固件的设备的典型例子的范围从如遥控器或计算器的最终用户产品至如硬盘、键盘、TFT显示屏或存储卡的计算机部件和设备，一直到科学仪器和工业机器人。另外，更复杂的消费电子设备（如移动电话、数码相机、合成器等）包含固件，以启用设备的基本操作以及实现更高级别的功能。固件和软件之间没有严格的界限，因为二者都是相当宽泛的描述性术语。然而，最初创造固件这个术语是为了与可以在不更换计算机硬件组件的情况下更改的更高级别的软件加以对比，而固件通常涉及非常基本的低级别操作，没有这些操作，设备将完全无法发挥其功能。固件也是相对的术语，因为大多数嵌入式设备包含多个级别的固件。如CPU、闪存芯片、通信控制器、LCD模块等的子系统都有自己的（通常是固定的）程序代码和/或微代码，其被更高级别的固件视为“硬件的一部分”。低级别固件通常驻留在PLA结构或在ROM（或OTP/PROM）中，而较高级别的固件（通常在软件边界上）通常采用快闪存储器以允许更新，至少在现代设备中是这样的。更新固件的常见原因包括修复问题或给设备增加功能。这通常涉及按照特定程序将制造商所提供的二进制映像文件加载到设备中；这有时要由最终用户完成。

技术实现要素：
本发明的目标是尽可能多的改善用于更新多域嵌入式系统的方法。通过具有独立权利要求1的特征的方法实现这个目标。有利的改进是从属权利要求的主题，且包含在具体实施方式中。因此，提供了一种用于更新多域嵌入式系统的方法。在该方法中，确定连接至系统接口的设备的标识。如果系统不支持该设备，则更新系统。在该方法中，确定支持设备的支持驱动程序的支持驱动程序的名称。在该方法中，确定至少一个受影响的域，该域具有支持驱动程序。在该方法中，确定系统的当前配置的配置标签。配置标签具有与受影响的域相关联的文件的域文件列表。在该方法中，配置标签和支持驱动程序名称以及标识被传输到配置数据库。在该方法中，利用配置数据库确定系统的新配置的新的配置标签和文件列表。根据作为输入变量的传输的配置标签和传输的支持驱动程序名称以及传输的标识执行确定。文件列表定义要更新以便从当前的配置迁移到新的配置的驱动程序的文件。在该方法中，驱动程序的文件的二进制数据和文件列表以及新的配置标签被传输到系统。在该系统中，利用二进制数据和文件列表更新驱动程序。由于上文所述方法的具体实施例，例如如在图2中所示，实现了多个优点。通过确定文件列表实现一个最小的方法，使得仅更新所需的必需的驱动程序的文件必须被传输到系统。因此，更新可能会非常迅速地进行。在短暂的更新时间之后，系统便再次就绪以供使用。因此，配备该系统的车辆很快即可就绪以供操作。因为只更新受影响的域的驱动程序，未受影响的域的驱动程序保持不变，因此更新过程中的错误通常不损害系统的其他功能。本发明的进一步目标是提供一种尽可能多的被改进的多域嵌入式系统。通过具有独立权利要求6的特征的系统实现此目标。有利的改进包含在具体实施方式中。因此，提供一种多域嵌入式系统，该系统具有接口，其用来连接设备并用来确定连接到接口的设备的标识。该系统被配置为适于更新。该系统被配置来确定支持设备的支持驱动程序的支持驱动程序名称。该系统被配置来确定至少一个受影响的域。该受影响的域具有支持驱动程序。该系统被配置来确定系统的当前配置的配置标签。该配置标签具有与受影响的域相关联的文件的域文件列表。该系统被配置来将配置标签和支持驱动程序名称以及标识发送到配置数据库。该系统被配置来接收要更新的驱动程序的文件的二进制数据。该系统被配置来接收文件列表和新的配置标签。二进制数据和文件列表以及新的配置标签基于所传输的配置标签和支持驱动程序名称以及标识。文件列表定义要更新以便从当前的配置迁移到新的配置的驱动程序的文件。该系统被配置来利用二进制数据和文件列表更新驱动程序。下文所述的实施例与多域嵌入式系统和更新方法二者相关。系统的功能特征可能源自于方法特征。方法特征可能源自于系统的功能。有利地，域（也被称为应用程序域）是一种机制，其用于将执行的软件应用程序彼此隔离，这样它们就不会互相影响。每个域都有自己的虚拟地址空间，虚拟地址空间为利用该地址空间的应用程序域划定资源范围。根据一个有利的实施例，配置标签、支持驱动程序名称和标识通过网络连接传输到配置数据库。有利地，系统具有用于有线连接或无线连接的在线模块。配置数据库被有利地设置在系统之外。处于中央位置的配置数据库优选地可从大量系统访问。也可以通过存储介质（如U盘）传输配置标签、支持驱动程序名称和标识，以及进一步通过网络连接例如从存储介质传输配置标签、支持驱动程序名称和标识。优选地，通过配置数据库确定新的配置标签，其中，评估域的文件的相互依赖关系并且/或者在表（例如以LUT（查找表）的形式）中定义相互依赖关系，这样，可以从配置数据库读取新的配置标签。在一个优选的实施例中，复制当前的二进制数据。在复制之后，当前的二进制数据被用于更新的传输的二进制覆盖。当前的二进制数据只是系统数据的一部分，其在更新过程中被覆盖，使得对于复制当前的二进制数据也由文件列表定义。在复制之后，当前的二进制数据被传输的二进制数据覆盖。复制的当前的二进制数据优选地在单独的存储空间中被缓冲。如果确定更新已经失败，优选地将缓冲的二进制数据写回。如果更新成功，则删除复制的二进制数据。本实施例实现回滚也相应地迅速执行的优势，因为只需将驱动程序列表中的驱动程序恢复到以前的版本。在有利的实施例中，根据驱动程序列表确定文件列表。根据作为输入变量的传输的配置标签和传输的支持驱动程序名称以及传输的标识，利用配置数据库确定驱动程序列表。驱动程序列表包含要更新以从当前配置迁移到新的配置的所有驱动程序。优选地，驱动程序列表中不包含额外的驱动程序。根据一个有利的实施例，驱动程序列表具有受影响的域的所有文件的子集。受影响的域的所有文件的集合是超集。系统优选地被配置来确定受影响的域的所有文件的子集。根据一个有利的实施例，基于解析驱动程序列表中的驱动程序的驱动程序依赖关系，确定驱动程序列表中包含的每个驱动程序的版本。上述实施例不管单独还是组合运用都特别有利。所有实施例都可以相互组合。在图中示例性实施例的描述中介绍了一些可能的组合。然而，其中示出的用于组合实施例的这些可能性不是最终的。附图说明以下根据附图中示出的实施例更详细地描述了本发明，其中图1示出了包含功能块的示意图；图2示出了方法序列的示意图。具体实施方式图1借助包含功能块的示意图示出了一个示例性实施例。功能块具有多域嵌入式系统1。多域嵌入式系统1具有例如十个域。域用于将执行的软件应用程序彼此隔离，这样它们就不会互相影响。每个域都在系统的存储器中有自己的地址空间。多域嵌入式系统1以下简称为系统1。在图1中的示例性实施例中，系统1具有设备管理器100，其用于检测设备800；更新管理器200，其用于驱动程序管理；驱动程序数据库300；和在线模块400，其用于连接和缓存。多媒体领域正在迅速发展。汽车行业中使用的系统具有很长的生命周期，这就是为什么可能将新型的设备、模块或介质引入到系统1中的原因（例如，新型MP3播放器、新一代设备或新的文件系统，如extFAT等），而系统1的当前配置不支持这些部件。通常，只需进行软件更新便会允许设备的功能。在个别情况下，还需要对硬件做出一些更改。因此，根据图1中的示例性实施例的系统1被配置为适于更新。一旦已通过接口180（例如，由用户、服务站等）将新的设备、新的介质或新的组件插入到汽车系统中，应检查是否新的驱动程序或软件更新是必需的或者是否新的驱动程序或软件更新可因此基于本地（离线）或在线数据库600或通过任何协议和任何介质（例如，有线或无线）从服务提供商处获得。在图1中的示例性实施例中，确定连接到系统1的接口180的设备800的标识dvID。执行通过接口180从设备800到系统1的设备管理器100的数据传输810，其中该数据表征外部设备800。这些新的驱动程序或软件更新半自动地（例如通过提示用户）或全自动地被加载或安装。如果出现不兼容的情况（即，不能进行更新），则将显示相应的消息。为此，确定新设备800的标识dvID的所有必要的参数（如供应商ID、设备ID、序列号、固件版本、软件版本等），并在升级过程中对其加以考虑。这使得当在汽车系统1中检测到新的设备800或介质或新的组件时，可以自动检测并安装所需的驱动程序。甚至也可以检测硬件的变化（例如对新一代的SD卡、SDXC或USB3.0的支持）。这个过程可以通知最终用户把他的车开到最近的服务站进行更新。在图1中的示例性实施例中，如果系统1不支持连接到接口180的设备800，则更新系统1。系统1被配置来确定支持设备800的支持驱动程序的支持驱动程序名称drn。为此，在图1中的示例性实施例中，设备管理器100被连接到更新管理器200，借助于传输120，设备管理器100将标识dvID传输到更新管理器200。系统1被配置来确定至少一个受影响的域aD。该受影响的域aD具有支持驱动程序。为了这个目的，将更新管理器200连接到系统1的驱动程序数据库300，用于支持驱动程序名称drn的传输230。驱动程序数据库300被配置来基于支持驱动程序名称drn来确定受影响的域。例如，与一个域关联的所有驱动程序的名称都以表的形式储存，使得表中的每个名称可以与支持驱动程序名称drn进行比较。如果表包含支持驱动程序名称drn，则域aD受到影响。系统1被配置来确定与受影响的域aD相关联的系统1的当前配置的配置标签cHUcfg。驱动程序数据库300被配置来生成或读出当前配置的配置标签cHUcfg。配置标签cHUcfg具有属于一个或多个受影响的域aD的文件的域文件列表。配置标签cHUcfg借助于传输320到达更新管理器200。系统1被配置来将当前配置的配置标签cHUcfg和支持驱动程序名称drn以及设备800的标识dvID发送至配置数据库600，配置数据库600在系统1的外面。配置数据库600被配置来根据配置标签cHUcfg和支持驱动程序名称drn以及标识dvID输入评估更新所需要的数据。在图1中的示例性实施例中，还提供了用于网络连接的在线门户500。在系统1中，更新管理器200被连接到系统1的在线模块400。通过网络（未示出），借助于传输240将配置标签cHUcfg从更新管理器200传输至在线模块400，而借助于另一个传输450将配置标签cHUcfg从在线模块400传输至在线门户500。系统1被配置来接收驱动程序文件的文件列表flst中的文件的二进制数据bin，并且还接收新的配置标签nHUcfg。为了在稍后的时间点检索二进制数据bin，在线门户500借助于传输560将当前配置标签cHUcfg连同驱动程序名称drn和标识dvID一起传输到配置数据库600，以便确定新的配置标签nHUcfg；而借助于传输650新的配置标签nHUcfg以及驱动程序列表dlst被传输回在线门户500。配置数据库600也可以被称为音响系统配置数据库600。借助于管理人员的相应编程690，被评估以选择包含二进制数据bin的正确文件的依赖关系被储存在音响系统配置数据库600中。例如，依赖关系被储存在依赖关系电子表格中。已确定文件的文件名称在文件列表flst中指定，驱动程序版本vrs由在线门户500确定。如果文件名称和每个驱动程序的版本vrs记录在驱动程序列表dlst中，则可以借助于查询570从驱动程序数据资源库700读取相关二进制数据bin并借助于传输750使得相关二进制数据bin对在线门户500可用。二进制数据bin和文件列表flst以及新的配置标签nHUcfg基于已传输的配置标签cHUcfg和驱动程序名称drn以及标识dvID。文件列表flst定义要更新以便从当前的配置迁移到新的配置的驱动程序的文件。驱动程序列表dlst定义要更新的驱动程序以及其版本vrs，以便从当前的配置迁移到新的配置。一旦已利用传输540将需要的二进制数据bin和文件列表flst传输到系统1，则系统1被配置来借助于驱动程序文件的二进制数据bin和文件列表flst更新驱动程序。由于图1中示例性实施例的方法，可以以较小、逐步的方式调适系统1，以便追随介质情况的变化。因此，系统1可能支持新的设备、新的介质或新的模块，从而可以可靠地检查是否依赖关系或不兼容使得支持不可能。图2示意性地示出了功能块100、200、300、400，即多域嵌入式系统1的设备管理器100、更新管理器200、驱动程序数据库300和在线模块400；以及功能块500、600、700，即网络中存在的在线门户500、音响系统配置数据库600和驱动程序资源库700。另外，图2还示意性地示出了参照功能块100、200、300、400、500、600、700的方法序列。该方法序列显示了当以前不支持的设备800连接到系统1的接口（如图1中的180）时系统1的更新。在第一个步骤11中，设备800连接到系统1，设备800在图1中示意性地示出。设备800是例如USB设备。本方法并不限于特定类型的接口，而是可以用于不同类型的接口，如USB接口、SATA接口、卡接口等。已连接的设备800的标识dvID在进一步的步骤12中确定。标识dvID具有例如设备编号和/或类型指定和/或供应商ID。标识dvID具有确定与设备800兼容的驱动程序的驱动程序版本所需要的所有参数。在进一步的步骤13中，系统1检测到设备800不被支持的事实。在进一步的步骤14中，设备管理器100通过传输标识dvID至更新管理器200将不支持的设备800通知更新管理器200。在进一步的步骤21中，更新管理器200确定支持设备800的驱动程序的驱动程序名称drn。更新管理器200确定支持设备800所需要的驱动程序和驱动程序名称drn，例如所需的USB驱动程序。驱动程序在更新之前和之后通常具有相同的驱动程序名称drn，而驱动程序版本则不同。随后，借助于驱动程序数据库300确定当前配置的配置标签cHUcfg。为此目的，在进一步的步骤22中，更新管理器200将驱动程序名称drn发送至驱动程序数据库300。在进一步的步骤31中，借助于驱动程序数据库300确定一个或多个受影响的域aD。每个受影响的域aD具有支持驱动程序。另外，该受影响的域aD可具有额外的驱动程序，受影响的域aD包括驱动程序名称列表，受影响度基于特定域的驱动程序名称来确定。域aD具有所谓的依赖关系树，该依赖关系树基于文件版本定义文件之间的关系，即在每种情况下相互兼容的二进制文件。在绝大多数情况下，只有一个域aD受到影响。在少数情况下，两个域aD受到影响。在相同步骤31中，确定与一个或多个受影响的域aD关联的系统1的当前配置的配置标签cHUcfg，并在步骤32中将其传输至更新管理器200。配置标签cHUcfg定义与受影响的域aD关联的文件（例如一些可移植的可执行文件(.exe、.dll、.sys、.drv)）的至少一个文件列表。配置标签cHUcfg形成文件的数据结构，并包括特定文件的特定当前文件版本。在进一步的步骤23中产生更新会话。该更新会话是内部系统会话，其一贯地处理当前更新过程中的所有动作。在图2中的示例性实施例中，在该更新会话中配置标签cHUcfg和驱动程序名称drn以及标识dvID被传输到在线模块400，这发生在进一步的步骤24中。在进一步的步骤41中，建立从在线模块400至在线门户500的在线连接。如果已建立了连接，则可跳过步骤41。在图2中的示例性实施例中，如果在线模块400通过无线连接（例如借助于UMTS或WLAN）使用例如TCP/IP协议，则可以在任何时候建立连接。或者，可以提供连接在其间的设备（未示出），该设备建立至在线门户500的连接，并例如借助于USB接收来自系统1的数据/将数据传输至系统1。在进一步的步骤42中，将配置标签cHUcfg和驱动程序名称drn以及标识dvID传输至在线门户500。此外，可以将更新会话标识从在线模块400传输至在线门户500。在在线门户500中也为更新过程创建会话，这发生在进一步的步骤51中。在进一步的步骤52中，将配置标签cHUcfg和驱动程序名称drn以及标识dvID和可选地更新会话标识从在线门户500传输至音响系统配置数据库600。借助于音响系统配置数据库600确定新的配置标签nHUcfg。评估必须使用哪个新的配置来履行受影响的驱动程序的正确更新。新的配置标签nHUcfg包含成功更新后系统1的新配置的所有配置数据。基于已传输的当前配置的配置标签cHUcfg并基于作为输入变量的驱动程序名称drn和设备800的标识dvID，借助于配置数据库600，还确定与新的配置标签nHUcfg相关联的驱动程序列表dlst。通过评估受影响的域aD的文件确定新的配置标签nHUcfg。例如，为此目的，读出LUT（查找表）中的相关条目。驱动程序列表dlst定义更新所需驱动程序的驱动程序名称。在进一步的步骤62中，将驱动程序列表dlst和新的配置标签nHUcfg以及（如适用）会话标识从配置数据库600传输到在线门户500。在进一步的步骤53中，在在线门户500中解析驱动程序列表dlst中的驱动程序的相互依赖关系，并且确定驱动程序的所需版本并将其作为版本标签vrs添加到驱动程序列表dlst。确定从当前的配置迁移到新的配置所需的驱动程序的版本vrs。驱动程序的相互依赖关系对系统1本身来说并不为已知，因此由图2中的示例性实施例中的在线门户500确定外部设备的依赖关系。驱动程序列表dlst中的文件优选地是受影响的域aD的所有驱动程序的子集。一方面，不必传输具有相同版本的驱动程序进行更新，并且（如适用）只需要传输系统1中还没有出现的驱动程序的文件。与常规的固件更新相比，更新系统1要传输的数据量由此显著减少。因此，系统1更迅速地再次可供用户使用。对于驱动程序列表dlst中的每个驱动程序，循环95重复进一步的步骤54和71。在步骤54中，对于要更新的每个驱动程序，将驱动程序名称drnN和版本标签vrs从在线门户500传输至驱动程序数据资源库700。在循环95中，驱动程序数据资源库700返回驱动程序列表dlst中的每个驱动程序的二进制数据列表bdl和二进制数据bin以及驱动程序名称drnN和版本标签vrs。在进一步的步骤55中，所有要更新的驱动程序的所有文件在文件列表flst中列出。文件包含驱动程序列表dlst中每个驱动程序的文件的二进制数据bin。文件列表flst定义要更新以便从当前的配置迁移到新的配置的驱动程序的文件。通过在线门户500和系统1的在线模块400之间的连接将文件列表和新的配置标签nHUcfg传输到系统1。在图2中的示例性实施例中，另外还传输会话标识。会话标识是更新过程的唯一的标识符。文件列表flst包含在该会话中所有要更新的驱动程序的文件。新的配置标签nHUcfg包括所有要更新的驱动程序的名称drnN，包括相应的版本信息vrs。在图2中的示例性实施例中，在进一步的步骤43中将驱动程序列表dlst中的每个驱动程序的驱动程序文件的二进制数据bin和新的配置标签nHUcfg以及文件列表flst和（如适用）会话标识从在线模块400传输至更新管理器200。在进一步的步骤44中，可以清除在线模块400和在线门户500之间的连接。该连接也可以保持建立，用于进一步的功能和服务，在这种情况下，跳过步骤44。在进一步的步骤25中开始实际更新过程。借助于系统1中的驱动程序文件的二进制数据bin，根据文件列表flst更新驱动程序。更新过程的结果在图2中作为备选96示例性地示出。在第一种情况下，更新过程已成功完成的事实在步骤26中建立，使得步骤27被执行。在步骤27中，将新的配置标签nHUcfg传输到系统1的驱动程序数据库300并在步骤33中将其储存在其中。在另一种情况下，更新过程失败，这在进一步的步骤28中确定。基于图2中的示例性实施例所介绍的最小的方法，在更新过程中通过二进制数据bin修改的受影响的少数文件的以前版本在被覆盖之前被复制并被缓冲在更新管理器200的存储器中。这在完整的固件更新时将不可能发生，因此在失败的更新过程之后系统1将可能不再运行。然而，基于图2中的示例性实施例中的最小方法，只有一个域aD受到影响或两个域aD受到影响，而剩余的域保持运行没有变化。所谓的版本回滚在进一步的步骤29中发生，其中更新过程中受影响的文件的以前版本再次覆盖新的二进制数据bin，并且从而将系统1重建至以前的配置而不必为系统1重新加载较旧的完整固件。因此，回退机制确保了系统1的可操作性。在最后的步骤99中，更新会话终止。系统1随后以正常的应用模式运行。本发明并不限于图1和2中示出的示例性实施例。例如，可以将额外的步骤添加至图2中的方法序列，例如以在更新之后首先测试系统，查看是否可以对额外的设备寻址等。也可以在图2中的示例性实施例中提供其他或额外的模块，如存储器元件，用于缓冲可能的更新。根据图1的系统1的功能可以特别有利地用于汽车系统，例如机动车的音响系统。参考数字列表1多域嵌入式系统100设备管理器180接口200更新管理器300驱动程序数据库400在线模块500在线门户600音响系统配置数据库700驱动程序资源库800设备120,230,240,320,420,450,传输540,560,570,650,750,810690编程11,12,13,14,21,22,23,24,方法步骤25,26,27,28,29,31,41,42,43,44,51,52,53,54,55,56,61,62,71,95,96,99dvID标识drn,drnN驱动程序名称aD域cHUcfg,nHUcfg配置标签dlst驱动程序列表bdl二进制数据列表vrs版本bin二进制数据flst文件列表