用于车辆平台验证的方法和系统与流程

本发明涉及用于评估车辆平台中的软件(sw)和硬件(hw)组件的兼容性的方法和系统。

背景技术：

当车辆设计师对一系列车辆的软件和/或硬件进行改变时，在改变之前评估这些改变是否与现有车辆兼容是有益的。这一系列车辆可能属于相同或不同的车辆平台。例如，在设计新的车辆模型或改变现有车辆模型时需要进行这种兼容性检查。

在售后市场，当涉及车辆修理和对车辆中的软件持续更新时，也需要兼容性检查。例如，当软件更新被推送到车辆时，需要进行兼容性检查以确保车辆在更新后将完全运行。此外，当硬件部件在车辆上改变时，需要检查与车辆其余部件的兼容性以防止故障。

在车载系统、车辆对车辆系统和车辆对基础设施系统中也需要兼容性检查。车辆对基础设施系统的示例可以例如是车辆的信息娱乐系统中的交叉路口或地理广告。

确保对组装车辆交叉开发的兼容部件配置的最常用方法是利用一种公司产品结构。公司产品结构是管理变化点、变化规则并保持所兼容的单一事实的主要(通常是唯一的)结构。公司产品结构传统上以制造和材料源为重点，这使得它非常适合基于变化点字符串和属性及特征组成来选择部件，但不太适合解决由工程/解决方案领域，特别是由sw和机电一体化角度所驱动的兼容性问题。公司产品结构通常反映在r&d结构和不同的制造结构中，并且最终也反映在售后市场结构中。这些结构中的每一个通常都允许一些操纵手段，例如为特定目的引入新的变型或变型规则、时间操纵或其它细微差异。基本上这些更新是基于“现有的”公司产品结构的“附加”。公司产品结构是用于整个产品生命周期管理的基础配置和复杂性管理。因此，在某个方面插入变型或/和变型约束的每个工程师负责使用公司产品结构中所定义的变化点和变型来编制约束。在例如一个拥有数千个部件的现代化复杂电气平台中，变化点、变型和约束从国内结构到公司结构的转变非常具有挑战性，并且对于未正确定义的变型和规则风险很高，并存在其将变得难以管理的风险。根据一种解决方案，工程师可以通过选择适当的通用结构来使变化点和变型的数量最小化并且如此操作使得设计复杂性和设计维护大大降低。可替代地或另外地，为了努力将变化点的数量保持在可管理的量，通常将现存变化点与附加的复杂变化规则进行重复使用。结果是以制造为目标的变化点和规则集。然而，利用不同的变化点集来反映下游结构中基于不同通用结构的这些变化点、变型和依赖性具有挑战性。此外，随着时间的推移，利用“移转(carryover)”和“回收(carryback)”解决方案并交叉不同的车辆程序，质量可能会受到损害，甚至存在车辆可能利用不兼容的解决方案来进行建造或更新的风险。

技术实现要素：

本发明的目的是提供一种增强的对汽车系统中兼容性进行评估的方法。

根据本发明的第一方面，通过评估车辆平台的第一系统组件的兼容性的方法来实现该目的和其它目的，该方法包括以下步骤：提供数据库，该数据库包括：车辆平台配置信息，所述车辆平台配置信息包括关于两个或更多个车辆模型(车辆配置)的配置信息，其中每个车辆模型包括一个或多个方面域方面结构，其中所述方面结构包括方面域，其中每个方面域包括一个或多个系统组件，其中每个系统组件包括配置信息，其中每个配置信息包括一个或多个参数值的集合；其中两个不同车辆模型的至少一个系统组件属于同一方面域；其中每个车辆模型的方面域的数量以及该车辆模型的每个方面域结构的系统组件的数量中的至少一者是二十个或更多；通过将所述第一系统组件的配置信息与所述至少一个其它系统组件的配置信息进行比较来确定所述第一系统组件与所述车辆平台中的至少一个其它系统组件之间的兼容性结果，其中将所述第一系统组件的配置信息中的一个或多个参数值的集合与所述至少一个其它系统组件的配置信息中的一个或多个参数值的集合进行比较，以确定参数值的集合是否具有至少一个兼容参数值；其中可选地，仅对与所述第一系统组件不相同的或者作为与所述第一系统组件不相同的系统组件实例的所述至少一个其他系统组件中的系统组件确定肯定兼容性结果(positivecompatibilityresult)；以及基于所述第一系统组件是否被确定为与所述至少一个其它系统组件兼容来返回兼容性结果。

就本发明而言，如下文所更详细地解释地，术语“评估兼容性”的含义基本上是指确定“第一系统组件”与所述车辆平台中的至少一个其他“系统组件”是“兼容/有效”还是“不兼容/无效”。

就本发明而言，术语车辆平台是指共享的一组共同设计、工程和生产工作，以及通常来自不同但相关型号的多个不同车辆模型甚至车辆类型的主要部件。术语模型则任意的用于区分车辆平台内的系统组件的不同配置，从而定义兼容的一组系统组件，其对于特定的一组兼容性条件有效。它在汽车行业中的实践是通过以较少数量的平台上的这些产品为基础来降低与产品开发相关的成本。这进一步使公司能够从类似的基础设计角度创建不同的模型。

所述数据库包括所述至少一个系统组件并且优选还包括所述第一系统组件，其中所述至少一个系统组件和所述第一系统组件属于相同或不同的车辆模型和/或方面域。

配置信息可以分为两个集合。第一集合是关于为特定特征定义选择哪个有效变量组合的配置信息。该特征集合通常被定义为全局特征库。第二集合是定义和解决技术兼容性(sw对hw约束、sw功能约束、机电一体化约束或其它)的配置信息。通常使用一个或几个结构，以便将车辆平台的不同区域分开(关注点分离)，以最小化和管理不同类型的约束。实例：用于定义和计算最佳帧封装方案的结构基于面向网络的结构。描述这种结构的两种不同的帧编译将在使用这些编译的所有部分中施以约束(不兼容的组合)。为了解决功能依赖性，面向功能的结构更合适。在一个结构中可以解决多于一种类型的技术约束。然而，该成本在配置参数和配置规则方面往往会增加。

方面域指的是结构中解决特定类型的(一个或多个)约束的特定通用模块。这些模块的变量由与车辆平台中的某些功能相关的成组系统组件组成，例如由推进系统、安全系统、锁定系统等组成。系统组件是软件和硬件组件和相关对象，所述对象描述在车辆平台中定义、设计、实施、整合、构建和维护一个或多个车辆模型所需的要求、设计、实施和最终部件，并且可例如在安全系统中为用于安全带的限制器。

就本发明而言，术语“兼容性结果”表示兼容性测试的结果或来自算法的输出，例如，第一系统组件和第二系统组件彼此不兼容或者第一系统组件和第二系统组件彼此兼容。根据一个示例，兼容性结果是兼容或不兼容。

就本发明而言，术语“肯定兼容性结果”用于表示表明兼容或有效的兼容性结果，即既非不兼容也非无效。另外，就本发明而言，术语“否定兼容性结果”用于表示表明不兼容或无效的兼容性结果，即既不兼容也非有效。

就本发明而言，“两个系统组件都是相同的”或者“两个系统组件是相同的系统组件实例”两者都涉及该系统组件的相同实例。显示器和摄像机例如不是相同的系统组件/系统组件实例，而来自两个不同版本的相同显示软件构成相同的系统组件/系统组件实例。另一个示例，当第一个后视摄像机(第一个系统组件)要替代第二个后视摄像机(第二个系统组件)时，两个后视摄像机是相同的系统组件/系统组件实例。

另外地或可替代地，总是对与所述第一系统组件相同或者是与所述第一系统组件相同的系统组件实例的所述至少一个其他系统组件中的系统组件确定否定兼容性结果。这是例如符合确定哪些系统组件适合于彼此的目的，例如确定由一系列配置信息定义的合适的显示器和摄像机对。

根据一个示例，所述系统组件的所述配置信息包括情境特定车辆配置信息并且/或者所述配置信息包括内容配置信息。

就本发明而言，“情境特定车辆配置信息(contextspecificvehicleconfigurationinformation)”是涉及与两个装置彼此通信时所使用的标准或协议不同的某物的配置信息(可以称为协议配置信息或协议兼容性)。相反，其例如可能包括与如下所解释的地理情境和/或技术情境有关的车辆配置信息。另外或可替代地，配置信息和/或所述情境特定车辆配置信息可以包括内容配置信息。

就本发明而言，内容配置信息是例如不是诸如8位或16位的信息格式，而是应如何将信息内容配置为可以利用其他系统组件进行操作(例如，包括正确分析)。图像的宽高比是内容配置信息的一个示例，并且在详细描述中将给出更多示例。

在汽车行业中有很多要求。存在例如有关于因国家而异的汽车安全性的法律约束(例如车辆总重量、座位数量和/或安全气囊要求)；存在将限制置于可以一起使用哪些系统部件上的技术约束(例如安装所需的空间、操作所需的能量、所需的扭矩和/或温度容限)；存在对于不同的车型设定不同的设计约束(例如舒适度，最大速度，如纺织品、塑料的材料)。因此，例如当要交换一个系统组件时，需要确定该系统组件按照与旧协议相同的协议(协议兼容性)进行通信。然而，确定它能够例如关于地理情境(法律约束和/或用户约束，如语言)、技术情境(技术约束和/或设计约束)而在与旧情境相同的情境中运行是有用的。

通常，在汽车系统中，通常在多个电子控制单元(也称为ecu)中实施分布式功能。然而，描述分布的更通用的术语是模块。使用这个术语，ecu将成为面向拓扑的模块结构中的叶模块(leafmodule)。这些模块具有接口(信号、服务、机电一体化或其它)。

许多客户和系统功能是通过模块中的sw来实现的。在系统设计期间，系统功能的改变常常导致模块之间通信需求的改变，从而导致系统的变量。这也经常发生在模型年份之间。因此，取决于模块的功能性变型和通信需求，可以有多个版本(版本指的是变型id和修正id二者)的sw用于特定模块。

如果每个sw的功能相对于另一个模块有不同的通信需求(语义)，那么识别实现具有模块间通信功能的所有模块中使用的sw是否彼此兼容非常重要。驻留在不同ecu上的sw模块使用将ecu互连的网络来传输和接收通信信号。为了正确执行车辆功能，sw模块、机电接口和信号接口需要兼容。对于许多通信网络类型而言，通信信号位于称为帧的定义的运输容器中。帧可以由帧标识符唯一标识。

由于可能需要多于一个帧来传输整组通信信号，所以发射器和接收器被配置为使用相同的帧标识符是很重要的。通常期望模块接收其它模块发送的所有帧的一部分。

如果模块sw所配置用于的帧标识符在发送器和接收器之间不相同，则模块通常不能自身识别这种不匹配的情况。在模块不具有于发送器和接收器之间相同配置的情况下，则预期的通信信号将不会被接收，或者改为接收到另一个模块意图接收的帧。

如果使用不正确的软件或硬件，可将模块配置为具有不兼容的硬件和软件套件。确定配置是否是预期的变量或是不兼容的配置会很重要。不兼容的配置可能会对永久硬件损坏、未定义的系统功能、系统功能受损或根本没有系统功能施加风险。例如，一个帧的内容可能会被错误地解释为“打开侧车窗”，而驾驶员实际请求“关闭侧车窗”，或者“关闭侧车窗”的请求可能被完全忽略。

模块之间的通信可以基于面向服务的通信，其中模块或系统组件彼此通信它们对于系统可用的功能。模块或系统组件之间的通信路径可以在设计时间被静态建立且在启动时间或运行时间被动态建立。系统组件之间的这种通信不是由帧标识符来标识的，而是使用服务标识符来唯一标识服务或功能。

车辆结构和车辆电气系统的设计和所选择变化点可以用方面来描述。每个方面通常都能解决需求，例如提供产品优势、管理制造的入站和出站物流、操控和控制工程或在跟踪回归工程过程中以及稍后从产品生命周期管理角度跟踪系统约束。

解决一个或多个这种方面的许多结构通常得以保存在整个汽车制造商组织(研发，制造，销售，售后市场)中，并由专家进行创制和维护。

电气工程领域内的这些方面的示例是：

-可选客户特征和属性

-用以

-提供产品定义–待创制的需求特征/属性/客户功能

-提供产品规格，销售报价及待在工厂中(最终)组装的选定部件配置

-系统、控制单元、车载网络通信协议之间的接口

-用以关于分布式接口交叉多个ecu定义有效接口定义

-机电一体化

-用以定义ecuhw、传感器、执行器和总线的有效且兼容组合

-功能

-用以定义ecu分配和分布式功能sw单元的有效且兼容组合，使得正确执行车辆功能。

上述在示例中列出的方面(在电气工程领域内的这些方面)是方面域的所有示例。

在日益增多技术复杂的电气系统平台中，ecuhw的数量、系统总线、功能等等及低端和高端产品之间的带宽，以及提供具有成本效益产品的压力、大量增加的变型，并且最重要的是，如果未如本发明所实现的那样由产品生命周期管理系统进行正确禁止，则存在大量可构建但不兼容的变型组合。

结合起来，从电气工程角度来看，车辆制造过程正在改变。以前，从客户订购并在工厂建造的车辆从功能、属性和结构角度来看或多或少都是固定的。在出厂时，只对车辆进行了微小更新，例如故障校正和微小售后特征更新(例如拖钩)。

汽车行业正在接近“持续建设导向过程”，在整个车辆生命周期中，特征和属性以及构造都可以持续更新。这意味着汽车制造商也需要从多个角度跟踪每辆独特车辆。从工程角度来看，需要在不违反系统约束的情况下确保兼容的解决方案。从技术功能的角度来看，在所选解决方案(部件)范围内，车辆独特功能集能够正确执行，并且最后所选客户特征和属性关于所选解决方案和技术功能得以正确执行。这需要在整个车辆生命周期中进行正确编制以确保新引入的特征、属性或客户功能可能不违反由工程解决方案所定义的任何系统约束，或者确保更新的工程解决方案关于期望被执行的技术功能引入不兼容性，或确保预期的客户特征仍以预期方式交付。最终，任何引入的不一致都可能导致车辆功能失常。

如下面所解释的，系统组件的安装可能导致完全运行的车辆，但例如从法律或安全的角度来看仍然可能是不适合的。因此，本发明使得不仅能够检索对两个系统组件是否能够彼此通信的问题的响应，而且还够能检索是否适合将特定的第一组件添加到车辆的问题的响应。

每个参数集合中参数值的数量可以是一个或多个。可替代地，每个参数集合中的参数值的数量可以是两个或更多。

确定车辆平台中的第一系统组件和至少一个其它系统组件之间的兼容性结果的步骤可以包括使用与每个参数值的集合相关的标识符来确定所述第一系统组件的配置信息中的哪个参数值的集合与所述至少一个其它系统组件的配置信息中的哪个参数值的集合进行比较。

确定车辆平台中的第一系统组件和至少一个其它系统组件之间的兼容性结果的步骤可以进一步包括将第一系统组件的配置信息中的多个参数值的集合与所述至少一个其它系统组件的配置信息中的多个参数值的集合进行比较以确定每个经比较的成对参数值的集合在它们之间是否至少具有兼容参数值。

确定车辆平台中的第一系统组件与至少一个其它系统组件之间的兼容性结果的步骤可以进一步包括确定第一系统组件与车辆模型中的所有其它系统组件之间的兼容性结果。

通过确定系统组件是否与车辆模型中的所有其它系统组件兼容或不兼容，可以针对系统组件本地确定它是否与系统的其余部分兼容。

该方法可进一步包括通过将第一系统组件的配置信息与系统主机(systemmaster)的配置信息进行比较来确定车辆平台中的第一系统组件与系统主机之间的兼容性结果的步骤，其中将所述第一系统组件的配置信息中的参数值的集合与所述系统主机的配置信息中的参数值的集合进行比较，以确定参数值的集合在它们之间是否至少具有兼容参数值，并且其中返回兼容性结果的步骤是基于第一系统组件是否被确定为与至少一个其它系统组件和系统主机兼容。

如果结果“不兼容”被返回，则该方法可以进一步包括如下步骤：即如果确定第一系统组件与系统主机不兼容则确定不兼容的原因在于第一系统组件，否则确定不兼容的原因不在于第一系统组件。

通过确定不兼容的原因是否在于第一系统组件本身，可以判定要执行哪些措施以防止故障。

该方法可以在第一系统组件中本地执行，并且该方法可以进一步包括如果返回不兼容的结果则禁用第一系统组件的步骤。此外，兼容性结果可以被本地存储在第一系统组件中，直到获得新的兼容性结果。

根据一个示例，数据库分布在若干实例上，这些实例在空间上设置为彼此分离或彼此远离，其中每个实例具有数据库的相应部分，这些部分可以相互排斥或部分重叠。根据一个示例，数据库分布在多个车辆中，并且可选地分布在每个车辆中的多个存储空间中。

根据一个示例，数据库部分或全部地分布在多个车辆中。即数据库分布在多个车辆上，这些车辆可以属于多个不同的车辆模型和/或不同的制造商，其中每个车辆具有数据库的相应部分，这些部分可以相互排斥或者部分或完全重叠。当数据库部分地分布在多个车辆中时，数据库的一部分可以布置在不是车辆的实例下，例如，云等。这使得个别车辆可以回应它是否与某个系统组件兼容的问题，例如，在车辆中安装此组件之前。

根据一个示例，数据库分布在系统组件之间，并且数据库的相应部分可选地在软件中编译为相应系统组件。

通过在不兼容的情况下禁用系统组件，可以避免故障。将兼容性结果存储在系统组件本身中可以进一步使得诸如禁用和启用系统组件的判定能够在本地执行。

根据本发明的另一实施例，提供了一种执行车辆模型中的所有系统组件的兼容性评估方法的方法，还包括以下步骤：如果所有系统组件都返回兼容的结果，则确定车辆模型是兼容的；否则确定车辆模型不兼容。

通过对所有系统组件执行该方法，可获得包含所有系统组件的整个车辆模型的兼容性结果。还可以确定哪个系统组件或哪些系统组件中存在不兼容的原因，并且可以采取适当的措施来防止车辆发生故障。

许多车辆，例如汽车具有两个启动阶段是基础知识。初始阶段结束于电子装置开启而发动机关闭；而随后阶段则结束于电子装置和发动机都开启。当汽车尚未到达随后阶段结束时，这被称为汽车在车辆启动之后但处于减少功能状况。

该方法可以在车辆系统启动之前执行，并且所识别的不兼容性可能防止车辆的启动。可替代地，该方法可以在车辆系统启动之后的预定时间间隔之中或之内执行，并且不兼容性迫使车辆停车。在启动之后，车辆系统可以以减少的功能运行，直到该方法已返回兼容的结果。

通过在启动之前或直接在启动时执行兼容性评估，可选地在车辆系统以减少的功能运行期间，降低车辆故障的风险。

该方法可以进一步包括又一步骤：如果任何系统组件在被命令执行该方法之后在预定时间间隔内不通信，则确定系统组件的不兼容性。

该方法还可以包括以下步骤：如果车辆模型被确定为不兼容，则评估车辆模型中是否存在替代配置，并且如果是，则获取车辆模型的下一个配置并且重复该方法直到达到兼容性或者直到针对车辆模型的所有配置完成该方法。

通过测试多种配置，车辆可以识别兼容的配置并对配置进行调整，以避免车辆发生故障，同时仍能使车辆行驶。

第一系统组件可以例如是电子控制单元。

根据本发明的第二方面，提供了一种用于评估车辆的第一系统组件的兼容性的系统，所述系统包括：数据库，其包括：车辆平台配置信息，所述车辆平台配置信息包括关于两个或更多个车辆模型的配置信息，其中每个车辆模型包括一个或多个方面域，其中每个方面域包括一个或多个系统组件，其中每个系统组件包括配置信息，其中每个配置信息包括一个或多个参数值的集合；其中两个不同车辆模型的至少两个系统组件属于同一方面域；其中每个车辆模型的方面域的数量和所述车辆模型的每个方面域的系统组件的数量中的至少一者是二十个或更多；处理器，被配置为接收：第一系统组件的配置信息和至少一个其它系统组件的配置信息，并且被配置为基于所述所接收的信息通过将所述第一系统组件的配置信息与所述至少一个其它系统组件的配置信息进行比较而确定所述车辆平台中所述第一系统组件与所述至少一个其它系统组件之间的兼容性结果，其中将所述第一系统组件的配置信息中的一个或多个参数值的集合与所述至少一个其它系统组件的配置信息中的一个或多个参数值的集合进行比较，以确定所述参数值的集合是否至少具有兼容参数值；并且被配置为：基于所述第一系统组件是否被确定为与所述至少一个其它系统组件兼容来返回兼容性结果。

车辆模型的系统组件可以全部是单个车辆的一部分。可替代地，车辆模型的一个或多个系统组件可以不是车辆的一部分。车辆模型还可以包括来自一个以上车辆的系统组件。

车辆平台的系统组件(例如可以是通过通信网络连接的模块)可在彼此间互连，为此需要验证系统组件和系统主机之间的兼容性以及系统组件之间的兼容性。系统主机例如可以是车辆平台中的模块，该模块被分配作为所有其它模块参照的角色。

例如，对于门锁系统而言，了解车辆有多少个门是很重要的，因此门数量信息从中央主机发送到门锁系统。车辆模型的重要信息的另一个例子是轮胎周长，这对速度计和巡航控制系统很重要。

系统组件彼此兼容的含义在于系统组件被配置为使得发送和接收系统组件关于通信信号如何在网络上传输以及通信信号到底表示什么信息具有相同的假设。兼容的另一个含义是每个系统组件具有被设计成一起操作的功能。

本发明可以用于平台开发中，即用于电气工程设计和整合中。它也可以用于制造车辆以及售后市场。

设计中的应用示例包括系统生命周期设计、变量设计以及兼容或不兼容变量的评估。在整合中应用实例为车辆整合、车厢整合和试验台整合。在车辆整合中，可以确定哪些车辆应该部署新的组件。车辆也可以设置为根据那些组件与特定车辆兼容来认购新组件。

在售后市场，无论是车辆服务还是对车辆中的软件进行更新，都需要兼容性检查。例如，当软件更新被推送到车辆时，需要进行兼容性检查以确保车辆在更新后将完全运行。同样，当车辆上的硬件部件更换时，需要检查与车辆其余部件的兼容性，以防止故障。

本发明还可以用于合用汽车(carpools)、车载系统、车辆对车辆系统和车辆对基础设施系统。车辆对基础设施系统的示例可以例如是车辆可以与交叉路口基础设施、基于地理的广告或旅游广告进行通信的交叉路口。

无线更新和升级可以发送给车辆，其例如可能包括原始设备制造商(oem)的更新、第三方更新和客户应用程序定制。

用于本发明的主要用例(uc)包括以下内容：

主要uc1：使用专用的配置信息和相关对象，以便以有序的方式持续更新给定子方案的部分，并且正确且有意识地插入或避免在现有产品组合中插入新的约束(从而引入不兼容性)。为此，需要在(例如)设计环境中进行持续验证。

主要uc2：使用专用配置信息和相关对象，以便在下游工程活动/工装中语义上传输解决方案的有效兼容更新或部分更新，以便进一步分析其它/旧型号中的影响(留存和运回)。

主要uc3：为了能够在车辆平台上正确地整合和验证模块的有效和兼容组合，不仅基于公司特征字典，而且还基于不同的系统限制集合。当需要对所选信息对象进行连续更新时，这在整合和验证场景中特别有用(由于引入针对特定解决方案的可能系统约束，特征变量不会增加)。

主要uc4：在制造情形下，给定工厂针对同一车辆模型在储存方面具有不同版本的交付部件(耗尽的对物流的)。当涉及软件或/和软件的基线时，工厂将在工厂生产线上执行软件下载。为确保在出厂后正确设置软件，无论具体工厂情况如何，有效性和兼容性控制确保了出厂时正确的软件下载版本。

主要uc5：在售后市场情形下确保正确更新的车辆，其中只有一整套sw部分的子集可以在一个实例中加载。此uc的示例是执行错误修复或加载较大的sw部分(例如地图)。当加载大型软件文件时，整个文件被分解为许多“增量文件”。执行更新时，只有修改后的增量文件将被上传。

主要uc6：在售后市场场景中执行“特征更新”(例如将发动机从d4提高至d5)。这是期望增加二手车的零售价格。执行此类更新时，需要承担离线和车载兼容性检查/控制。

主要uc7：多个sw部分已经以如下方式被编译/创建，在于二进制包含至少两个不同的函数集，它们是互斥的。其原因在于，同一sw部分起源于hw单元，存在于具有两个不同功能环境的两种不同配置中。运行哪种配置的解决方案在启动车辆时、在初始化期间的绑定时间做出。然后需要车载验证以确保兼容性。

本质上，本发明的目标在于以下领域：

1、配置框架的定义，其支持多种通用结构，交叉产品生命周期的不同阶段来优化依赖性管理。通过为特定目的选择正确的结构，依赖性的数量和类型可以最小化，并且因此减少随时间进行管理的复杂性，

2、方法：

关于如何定义配置框架，如何在涉及研发工具，制造工具，售后工具的plm工具和特定车辆中的解决方案(根据以前定义的配置框架和方法的离线和在线配置解决方案)两者中定义和解决依赖性，

3、算法，用以在plm工具和车辆中检查并确保兼容产品配置。

本发明定义了用于配置、方法和算法的框架意在所有r&d阶段、制造阶段、维护阶段以及在车辆系统、车辆和平台的操作/更新阶段中确保兼容性并检测不兼容问题。

换言之，本发明至少能够改善车辆工程，尤其是电气工程和电气平台的生命周期的至少4个主要领域：

1、关于如何定义和维护变化点、变型和变型规则以及管理工程系统约束的配置框架的定义。这关于所选择的系统工程和系统工程变型战略，这些战略是由多个(r&d)产品结构所驱动(例如由机械工程、机电一体化工程和sw工程所驱动)。

2、关于如何基于不同的“方面”示例提供有效变化点、变型和变型规则的定义不同工程解决方案的兼容性的足够语义的方法框架：

a.机电一体化工程解决方案的兼容性

b.ee机电一体化工程解决方案的兼容性

c.sw工程解决方案的兼容性

d.机电一体化、ee机电一体化和sw解决方案之间的兼容性

e.满足客户所要求的功能

所有方面都可能基于不同的通用结构。

例如在执行r&d验证时在车辆系统的制造和售后市场更新处用于集成方案中。根据定义的系统约束确保了系统对正确的兼容部件配置的验证。这还包括定义eer&d对象如何与电气工程部件相关，对ee开发阶段及制造阶段和售后市场结构中所定义的编制系统约束进行验证。

3、关于如何基于一个结构选择可构建部件相对如何验证对于在不同结构示例中定义的一个或多个方面的兼容性的定义和方法：

a.从解决方案的角度，在制造中使用公司产品结构来选择“物料清单”(bom)及验证所选bom的兼容性

b.在更新车辆时，读取车辆的机电一体化、ee机电一体化和sw(工程)解决方案，基于解决方案来更新车辆

c.在更新车辆时，读取车辆的机电一体化、机电一体化和sw(工程)解决方案，展示解决方案集提供的技术功能和客户特征(包括无效功能和客户特征)的完整范围，作为额外的客户报价(售后业务情景中的示例)

d.在更新车辆时，如果当前安装的系统解决方案不足，则读取机电一体化、机电一体化和sw(工程)解决方案，验证哪些工程系统需要更新，以满足额外客户特征

4、关于如何向车辆提供/下载系统约束信息以便在继续构建过程中执行车内验证控制的概念的定义

5、如何执行车外和车内(车载)验证控制的算法的定义

a.机电一体化工程解决方案的兼容性

b.ee机电一体化工程解决方案的兼容性

c.sw工程解决方案的兼容性

d.机电一体化、ee机电一体化和sw解决方案之间的兼容性

满足客户所要求的功能。

本发明提供了用于交叉多个车辆系统(和部件)执行“车外”和“车载”兼容控制的手段，这例如就包括从国内结构到公司结构数千个部件，变换点、变型和约束变换的现代化复杂电气平台而言是高度需要的。

汽车制造商也瞄准新的收入来源。一项新的收入来源是为现有业主提供新功能。这意味着“每一天”可以成为特定车辆的新“制造日”。当今传统的工具和流程管理这种来源至多是非常有限的。

在不同的生命周期阶段(例如系统集成、制造、售后服务和本地配置结构)中交叉验证公司产品结构的输出的能力不仅极大地提高了执行更新的灵活性(在新车和现有车辆中)，而且还极大地提高了车辆的质量和功能。

附图说明

将参考附图更详细地描述本发明，所述附图显示了本发明的当前优选实施例。

图1是根据本发明实施例的对根算法的输入的图示。

图2是图1中的实施例的根算法结构(rootalgorithmstructure)的图示。

图3是图1中的实施例的根算法结构的另一个图示。

图4是根据本发明另一实施例的对相关算法的输入的图示。

图5是图4中的实施例的相关算法结构的图示。

图6是图4中的实施例的相关算法结构的另一个图示。

图7是图4中的实施例的相关算法结构的又一图示。

图8是根据本发明实施例的对系统兼容性的集中评估的图示。

图9是根据本发明实施例的具有系统兼容性的分布式评估的系统的图示。

图10是具有系统兼容性的分布式评估的系统的图示，其中带有系统组件结构的详细视图。

图11是具有系统兼容性的分布式评估的系统的图示，其中带有配置信息。

图12是具有系统兼容性的分布式评估的系统的图示，带有配置信息，带有系统组件结构的详细视图。

图13是具有系统兼容性的分布式评估的系统的图示，带有配置信息，带有系统组件结构的详细视图。

图14是与系统功能通信的系统兼容性评估结果的图示。

图15是每个使用系统兼容性功能的多个系统的连接的图示。

图16是使用系统兼容性功能和车辆外部非车载系统的汽车系统的图示。

图17是关于兼容性功能执行的时间视图的图示，其中在系统启动之后进行兼容性评估。

图18是关于兼容性功能执行的时间视图的图示，其中在系统启动之前进行兼容性评估。

图19是兼容性功能执行的时间视图的图示，其中在系统模式改变之后进行兼容性评估。

图20是用于从多个可用系统配置中找到兼容或不兼容配置的搜索算法的图示。

图21是用于从多个可用系统配置中查找所有兼容配置的搜索算法的图示。

图22是gen1的安全系统版本的图示；较高的性能和较低的性能以及相关模块。

图23是用于“较高性能安全系统”gen1的相关算法的兼容变量信息的例子。

图24是用于“较低性能安全系统”gen1的相关算法的兼容变量信息的示例。

图25是用于针对所有版本安全系统gen1的系统判定的兼容变量信息的示例。

图26是一个不兼容变量信息、模块的示例，其来自在较低性能系统gen1中的较高性能系统输入。

图27是gen2的安全系统版本的图示；较高的性能、中等性能和较低的性能以及相关的模块。

图28是变量信息“较高性能安全系统”gen2的一个示例。

图29是车辆平台的图示。

图30是两个车辆平台的图示。

图31是空调系统和推进系统的兼容和不兼容的系统组合的图示。

图32是图31中所示的空调和推进系统的兼容配置的算法结构的图示。

图33是图31中所示的空调和推进系统的不兼容配置的算法结构的图示。

图34是摄像机和处理软件的兼容和不兼容的系统组合的图示。

图35是图34所示系统的相关算法的配置的一部分的图示。

图36是温度传感器和发动机控制模块的兼容和不兼容的系统组合的图示。

图37是用于图36所示系统的相关算法的配置的一部分的图示。

具体实施方式

图29示出了具有两个车辆模型和多个方面域的车辆平台的图示。每个车辆模型在每个方面域中包括多个系统组件。该图仅仅是大幅简化的车辆平台的图示，因为平台通常包括大量的系统组件。车辆平台中会有广泛的车辆模型，并且在不同方面域中包含无数的系统组件的组合。因此，需要确保对于多个方面域中的系统组件的大量组合的兼容性。

例如，存在关于发动机性能套件、安全套件、信息娱乐套件等的修改。也存在需要考虑的地区差异，例如针对不同地区的车辆对基础设施解决方案以及涉及到不同的方面域时需要不同解决方案的当地法规和市场偏好。方面域中的系统组件可能会发生改变，如硬件替换和持续软件更新，因此需要在系统组件之间进行兼容性评估。

图30示出了与图29中类似的两个车辆平台。两个车辆平台包括相同的方面域，并且，车辆平台共享系统组件兼容性评估的相同方法理论。

将会示出许多详细的示例，这些示例一次一个地强调了有效和无效的(兼容或不兼容的)车辆系统的不同方面。在真实的车辆设计中，每个系统和系统组件可能涉及许多附加的方面。为了便于阅读，许多示例已被简化并且系统组件、参数和参数值的数量相当有限，在实际中系统组件的、参数和参数值的数量通常很大。

让我们来看一个涉及两个系统组件(气候系统和推进系统)的车载系统的示例。这两个系统中的每一个都不需要另一个系统来执行其系统功能。气候系统不直接需要推进系统来提供诸如湿度、通风或空气调节的气候功能。推进系统完全不需要气候系统来推进车辆。这两个系统都有不同的变体，但是气候系统和推进系统之间存在非功能性的依赖关系。气候系统有两种变体：具有低电能消耗的2区变体和具有高得多的电流消耗的4区变体。气候系统具有带有参数值的参数标识符“区域类型”，该参数值可以是“2区”或“4区”。推进系统也有两种变体：具有柴油发动机的变体和具有汽油发动机的变体。发动机控制模块具有带有参数值的参数标识符“燃料类型”，该参数值可以是“柴油”或“汽油”。气候系统由车辆电气系统电池供电。电池通过由推进系统中的内燃发动机驱动的交流发电机充电。推进系统因此对气候系统有依赖性。在图31中，用虚线示出了气候系统和推进系统的三种兼容的系统组合。可以做出这些系统组件的比图31中所示的更多的组合，并且所有这些组合都是不兼容的。由图31中的两种不同的气候系统组成的车辆与仅具有气候系统而没有推进系统的车辆或者可能具有不同燃料的两个推进系统的系统是不兼容的。在这该示例中，4区气候系统消耗太多的电力，这严重增加了汽油内燃发动机的排放水平。假设该示例的汽油发动机具有某些特性，如较弱的电力输出能力，需要该汽油发动机使用显著地更多的燃料来产生更多的电力以除了推进车辆之外还驱动交流发电机。额外的燃料需要提供更多的机械动力并且因此需要更多的电力来为电池充电。为了成功认证根据某些市场中的排放法规的车辆，车辆不得建有4区气候系统和汽油发动机的组合。具有4区气候系统的汽油发动机的排放超过了法定的排放水平。因此存在需要避免的系统组件的不兼容的组合。在图31中的该示例中，兼容的系统意味着存在导致车辆不会超过排放法定水平、非功能依赖性的气候系统和推进系统。在图32中以组合视图示出了2区气候系统和柴油推进系统的一种兼容的配置。示出了具有从气候系统和推进系统所得的相关算法和系统算法的参数标识符和参数值的系统配置。在图4和图10中的标记表示为相同的标记。在图33中以组合视图示出了4区气候系统和汽油推进系统的不兼容的配置。示出了具有从气候系统和推进系统所得的相关算法和系统算法的参数标识符和参数值的系统配置。在图4和图10中的标记表示为相同的标记，这将在下面解释。

尽管在以上示例中推进系统和气候系统各自构成了相应的系统组件，但是设计者可以选择每个系统组件的范围，即例如推进系统和/或气候系统可以被分成多个系统组件，例如各包括10至100个之间或者5至500个之间的系统组件。

让我们来看另一个涉及后视摄像机系统的车载系统的示例，该系统以两个系统组件实现：摄像机硬件(产生图像)和执行图像处理以及检测图像中的对象的软件。对象检测的目的可以是用于安全系统，例如检测图像中的人并提醒驾驶员有关人的信息，或者简单地干预车辆推进系统以防止车辆倒车撞到人。该系统有多种变体并且所有有效的变体必须由摄像机和图像处理软件组成。典型的摄像机系统特定属性可以是例如图像尺寸(水平像素、竖直像素)、图像长宽比、图像方向(景观、肖像)或图像刷新频率(每秒帧数)。为了简化，我们讨论一个仅使用图像尺寸作为影响兼容性的参数的示例。根据该示例，存在产生图像的摄像机的两种变体，一种是产生具有320×240像素的图像的变体以及另一种产生具有1080×720像素的图像的变体，图34中的实体表示摄像机。两个摄像机都在tcp/ip通信链路上将图像数据传输到处理软件并且该传输仅包括原始像素数据。摄像机具有带有参数值的参数标识符“摄像机图像尺寸”，该参数值可以是“320×240”或“1080×720”。此外，处理图像的软件有三种变体，一种只能处理320×240像素的图像的变体和另一种只能处理1080×720像素的图像的变体以及一种可处理任何图像尺寸的图像的变体，图34中的实体表示处理。处理软件具有带有参数值的参数标识符“处理图像尺寸”，该参数值可以是“320×240”、“1080×720”或“任意尺寸”。

该系统设计和变体的原因可能是根据图像分辨率与预期的对象检测质量、组件的可用性、成本、复杂性、处理速度、电流消耗等来区分系统性能水平。三种处理软件的其它原因可能在于这是可用的机器视觉技术如何在车辆平台生命周期上演变而来的。在图34中以虚线示出了摄像机和处理软件的兼容系统组件组合，仅有四种兼容配置。在图34中的这个示例中，兼容系统意味着一个摄像机连接到一个处理软件，该摄像机产生该处理软件可以处理和检测来自功能依赖性的对象的图像。可以做出这些系统组件的比图34中所示的更多的组合，并且所有这些组合都是不兼容的。由图34中的三个、四个或五个系统组件组成的系统与仅有一个处理软件的系统或可能有两个不同摄像机的系统是不兼容的。在图35中示出了用于摄像机的两种变体和处理软件的三种变体的相关算法的系统标识符和参数值的一部分配置。各标记指代与图4中相同的标记。对于查看各附图并了解上述预期的兼容配置的人来说，这是显而易见的，但是对于计算机系统并非如此，其必须确定是否存在兼容配置，并且这可以通过合适的参数和参数值的使用对兼容性加上合适的限制来解决，如关于例如图23的一般层面上所解释的，其中使用了参数值“无接收”。此外并且根据一个示例，图34中存在5个系统组件中的每一个的至少三个不同版本，并且这些系统组件的兼容对可以被识别，例如通过使用参数值“无接收(noreception)”并且运行关于图21所描述的算法中的一些或全部系统组件。相同系统组件的两个版本显然是不兼容的，并且这可以通过使用参数值“无接收”来指示，而例如处理sw320×240的任何版本可以与例如摄像机320×240的任何版本兼容。根据另一个示例，只有处理sw320×240的版本1和2与摄像机320×240的版本1兼容；这也可以用例如参数值“无接收”的使用来指示。

我们来看看发动机冷却剂温度传感器和发动机控制模块的另一个示例。除了其它事情之外，发动机控制模块使用温度信息来控制注入内燃发动机中的燃料的量以在各种温度条件下适当地操作燃烧过程。温度传感器有两种变体：一种基于摄氏度的变体和一种基于华氏度的变体。该传感器具有带有参数值的参数标识符“传感器温标”，该参数值可以是“摄氏度”或“华氏度”。两种温度传感器变体都产生由9比特表示的温度输出。该输出是传送给发动机控制模块的从-256到+255范围的整数二进制补码数值。温度传感器没有与发动机控制模块进行通信，而是简单地产生了一个温度值。发动机控制模块也有两种变体：一种基于摄氏度的变体和一种华氏度的变体。发动机控制模块具有带有参数值的参数标识符“模块温标”，该参数值可以是“摄氏度”或“华氏度”。摄氏度变体发动机控制模块只有被连接到基于摄氏度的传感器才能正常工作。同样地，华氏度变体发动机控制模块只有被连接到基于华氏度的传感器才能正常工作。在图36中，以虚线示出了温度传感器和发动机控制模块的两个兼容的系统组合。可以做出这四个系统组件的比图36中所示的更多的组合，并且所有的这些组合都是不兼容的。如果实际的发动机冷却剂温度为0摄氏度，则基于摄氏度的传感器将产生“0”并且基于华氏度的传感器将产生“+32”，因为0摄氏度对应于+32华氏度。如果基于华氏度的温度传感器被连接到基于摄氏度的发动机控制模块，则当实际上是0摄氏度时，发动机控制模块将假定温度为+32摄氏度。这将使得发动机控制模块假定其为+32摄氏度并且将显著地促成对燃烧过程的错误控制，这可能对发动机的驾驶和排放造成负面影响。发动机控制模块无法确定其连接到哪个温度传感器变体，即使通过分析来自温度传感器的温度值也无法确定其连接到哪个温度传感器变体，因为该模块产生+32华氏度的9比特数值并且+32是华氏温标上的有效温度并且也是合理的发动机冷却剂温度。在这种情况下，温度传感器和发动机控制模块都按设计运行但是推进系统级上的结果不是有效的系统。因此存在需要避免的系统组件的不兼容的组合。在图37中，示出了用于摄像机的两种变体和处理软件的三种变体的相关算法的系统标识符和参数值的一部分配置。各标记指代与图4中相同的标记。在图37中的该示例中，兼容的系统意味着温度传感器和发动机控制模块基于相同的温度系统(摄氏度或华氏度)、相同的接口依赖性。

汽车系统可以在车辆的内部和外部之间划分，并在系统性能(即配置)在运行时可能发生改变之处动态地改变。在系统运行期间或系统运行的时间域之间，系统组件性能可能会发生改变，并且系统配置数据可能会动态地改变。例如，至少一个系统组件可能不是车辆的一部分，而是其它部件，或者系统可能由多于一个车辆的系统组件组成，充当系统。

本发明是可扩展的并且使用多达三种算法来实现系统组件中的兼容性评估。

可以在每个系统组件中使用根兼容性算法(rootcompatibilityalgorithm)来确定其相对于系统主机参考配置的兼容性。该算法的结果告诉系统不兼容的根本原因是否在自身的系统组件内。如果需要明确地识别哪个系统组件不兼容，则使用此算法。

在每个系统组件中使用相对兼容性算法来确定其自身对与系统其余部分的兼容性/不兼容性的感知。该算法的结果不能识别本地不兼容性的绝对根本原因是在自身系统组件中还是其它系统组件中。如果需要识别是否有任何系统组件与系统的其余部分不兼容，则使用此算法。

在每个系统组件中使用系统兼容性算法来确定对兼容性/不兼容性的完整系统感知。如果需要一个或多个系统组件注意到整个系统是兼容还是不兼容，则使用此算法。

根据一个示例，根兼容性算法使用系统组件本地配置信息并将其与参考配置信息进行比较。系统中有一个参考配置信息，且该参考配置信息在系统组件各自的根算法中用于所有系统组件。该算法产生了意味着兼容或不兼容的系统组件的结果。

图1显示了根兼容性算法的输入。存在一个参考配置信息1和一个对应的本地存储的配置信息2。该算法比较参考配置信息1和本地存储的配置信息2。

为了知道它是针对该系统、信息1和应该比较的本地存储的配置信息2的参考配置，在参考配置信息1和本地存储的配置信息2的信息集3、4中分别查找源标识符5、6形式的标识符。如果源标识符5的值与源标识符6的值相同，则知道信息集3应与信息集4进行比较。

参照图2，当知道信息集3和4中的哪一个应该被比较时，则参数值集合7a的列表中的每个参数应该与参数值集合7b的列表中的对应参数进行比较。参数值集合7a的列表中的参数的数量和参数值集合7b的列表可以是范围从1到多个参数的任何数量。参数值集合7a的列表中的每个参数和参数值集合7b的列表可以是范围从1到多个参数值的参数值的列表。根据该示例，参数是参数idn；参数idn+1、参数idn+2；并且参数值是[1,2]、[1]、[3]；[1,2，w]、[1,2]、[3]。所述参数值8a、8b、8c、9a、9b、9c可以是多个任意值，例如[1,3，w]和/或参数值的范围、例如覆盖特定的数值区间的参数值范围(例如区间中的所有偶数值)。另外或者可替代地，参数值范围可以基于一个起始值和一个结束值，并且随后参数值范围意味着从起始值到结束值的每个值。将参数集合7a的列表中的每个参数值8a、8b、8c分别与参数集合7b的列表中的对应参数值9a、9b、9c进行比较，例如，参数值8a与参数值9a比较，以及参数值8b与参数值9b比较等等。如果参数值8a中的一个或多个值与参数值9a中的一个或多个值相同则意味着该参数是兼容的，否则它是不兼容的。根据一个示例，如果参数值8a中的一个或多个值与参数值9a中的至少一个值相同则这意味着该参数是兼容的，否则它是不兼容的。根据另一示例，所述参数值9a、9b、9c中的一个或多个是阈值，所有值都达到某个值则被认为是兼容的，并且高于该阈值的任何值被认为是不兼容的。可替代地，所有等于或高于该阈值的值被认为是兼容的，并且低于该阈值的值被认为是不兼容的。另外或者可替代地，如果参数值8a中的值不能在参数值9a中找到则该参数是不兼容的。

参数值集合7a的列表和参数值集合7b的列表中的参数的数量可以是范围从1到许多参数的任何数量。在参数值集合7a的列表中和参数值集合7b的列表中的每个参数8aa、8bb、8cc；9aa、9bb、9cc可以是范围从1到许多参数值的参数值的列表。将参数集合7a的列表中的每个参数值8a、8b、8c分别与参数集合7b的组列表中的对应参数值9a、9b、9c进行比较，例如参数值8a与参数值9a比较，以及参数值8b与参数值9b比较等等。如果参数值8a中的一个或多个参数或值与参数值9a中的一个或多个参数或值相同则意味着该参数8aa是兼容的，否则它是不兼容的。

图3示出了自参数8a+9a、8b+9b、8c+9c的每个比较89a、89b、89c，存在对于信息集3与信息集4的比较而言兼容或不兼容的中间结果89ai、89bi、89ci。如果在比较89中所评估的所有那些中间结果89ai、89bi、89ci是相容的，则最终算法结果890意味着兼容，否则最终算法结果不兼容。最终结果890涉及该系统组件相对于主参考配置的本地兼容性。

相对兼容性算法使用来自所有系统组件的系统组件本地配置信息，并将其与本地配置信息进行比较。该算法产生意味着兼容或不兼容的系统组件的结果。

也可能对配置点(其中仅仅与某些方面域有关的配置点，例如与接口相关的、机电一体化的或功能性的配置点)的子集执行验证。比较89然后可以仅使用来自与相关方面域有关的比较89a、89b、89c的中间结果。可替代地，可以存在关于方面域的定义的验证顺序，即比较89a、89b、89c要运行的顺序。

图4显示了对相对兼容性算法的输入。对于除了系统组件本身之外的每个系统组件，存在接收到的配置信息11和相应的本地存储的配置信息12。来自每个其它系统组件的所有接收到的配置信息集13a、13b、13c、13d等应当是与一个对应的配置信息集14a、14b、14c、14d等进行比较。信息集13a、13b、13c、13d和信息集14a、14b、14c、14d能够形成的信息集对的数量可以是范围从1到许多的任何数量。因此，至少信息集13a和信息集14a用于形成一个信息集对。

如果使用系统标识符，则在信息集13a、13b、13c、13d内查找系统标识符和系统组件标识符以发现于信息集何处信息集13a、13b、13c、13d中的系统标识符和系统组件标识符为与信息集14a、14b、14、14d中的系统标识符和系统组件标识符相同。如果系统标识符15aa的值和系统标识符16aa的值相同，并且系统组件标识符15a和系统组件标识符16a的值相同，则获知信息集13a应当与信息集14a相比较。根据相同的程序查找更多的信息集13b、13c、13d、14b、14c、14d。

如果未使用系统标识符，则在信息集13a、13b、13c、13d内查找系统组件标识符以发现于信息集何处信息集13a、13b、13c、13d中的系统组件标识符与信息集14a、14b、14、14d中的系统组件标识符相同。如果系统组件标识符15a和系统组件标识符16a的值相同，则获知信息集13a应与信息集14a相比较。根据相同的程序查找更多的信息集13b、13c、13d、14b、14c、14d。

参考图5，当已知信息集13a、13b、13c、13d中的哪一个与信息集14a、14b、14c、14d中的哪一个进行比较时，则参数和参数值集合(也称参数值集)17a的列表中的每个参数值18a、18b、18c应当与参数和参数值集合17b的列表中的对应参数值19a、19b、19c进行比较。参数18aa、18bb、18cc；19aa、19bb、19cc和参数值18a、18b、18c；19a、19b、19c可以被配置或设立成如关于图2所解释的。参数集合17a的列表中的参数值列表18a、18b、18c中的每个参数或值分别与参数集合17b的列表中的对应参数值列表19a、19b、19c中的参数或值进行比较，例如，参数值18a与参数值19a比较以及参数值18b与参数值19b比较等等。

如果参数值18a中的一个或多个参数或值与参数值19a中的一个或多个参数或值相同，则该参数18aa是兼容的。该比较可以如关于图2所解释的来执行并且返回相同的兼容结果。

如果来自信息11或信息12的系统标识符不能在其它信息12或信息11中找到，则该信息集(informationset)被忽略并且不能影响相关算法的结果。这意味着这种收到的配置信息不属于该系统。如果系统标识符15aa与系统标识符15bb相同，并且如果来自信息11或信息12的系统组件标识符不能在其它信息12或信息11中找到，则相关算法的最终结果189i不兼容，而不管在相关算法中的中间结果189ai、189bi、189ci如何。类似的情况也适用于图7中的最终结果999。这将意味着该系统中要么太多、或太少或意外的系统组件，是不兼容的一组系统组件。

如果接受配置19a被设置为“n/a”(不适用)，则这意味着对于任何18a的比较结果总是兼容的，而无论是否接收到18a或者未接收到18a。这与19b和19c类似。如果接受配置19a被设置为“无接收”，则这意味着如果接收到18a，那么无论18a的值如何，该比较的结果都是不兼容的。该程序与19b和19c类似。

图6示出了自从参数18a+19a、18b+19b、18c+19c的每个比较189a、189b、189c，存在对于参数18a与参数19a、参数18b与参数19b、参数18c与参数19c而言兼容或不兼容的中间结果189ai、189bi、189ci。如果在12中找到11中的所有系统组件标识符，并且如果所有中间结果189ai、189bi、189ci都是兼容的，则在比较189中确定另外的中间结果189i，该系统组件与一个其它系统组件兼容，如果中间结果189ai、189bi、189ci中的至少一个不兼容，则中间结果189i是不兼容的，该系统组件与一个其它系统组件不兼容。

图7示出了自信息集13a+14a、13b+14b、13c+14c(每一个如图6所示形成)的每个比较，存在中间结果189i。如果所有那些中间结果189i是兼容的，如比较99所评估的，则最终算法结果999意味着兼容，否则最终结果是不兼容。最终结果999涉及此系统组件与所有其它系统组件的相对兼容性。

如果使用根算法，则所有中间结果189i和根算法结果必须兼容以使相关算法最终结果999相容，否则相关算法最终结果是不兼容的。

系统兼容性算法使用兼容或不兼容所有系统组件相关兼容算法(包括此系统组件中的相关算法)的结果。如果系统组件中存在根算法，则除了相关算法结果之外，该算法的结果将用作系统算法的输入。如果所有那些最终结果是兼容的，那么系统算法结果是兼容的。如果系统算法的至少一个输入结果不兼容，则系统算法结果不兼容。最终结果与整个系统组件系统的兼容性有关。

对于所有算法，即对于根算法、相关算法和系统算法，当系统组件之间按顺序通信配置信息时，需要唯一地标识系统标识符、参数标识符和参数值。这可以基于对系统标识符、系统标识符值、参数标识符和参数值进行通信的预定顺序来完成，其中系统标识符和参数标识符未被通信但仅通信它们的数值，因此减少了需要的通信带宽。

可替代地，如果不希望具有预定的顺序，则每个参数标识符及其参数值成对通信，类似于系统组件标识符和系统标识符值。因此，参数标识符/值对(parameteridentifier/valuepairs)和系统组件标识符/值可以以任何顺序通信。在根算法中、相关算法和系统算法中，在这些算法之间传递和使用的参数值可以是符号，或者当在算法之间传递参数值以及评估算法中的兼容性/不兼容性时由其它值表示。即如果参数值具有“低性能”的逻辑意义，则它可以由例如数值1或字符“l”表示，而“高性能”可以由例如数值2或字符“h”表示。算法的输出结果可以是“兼容的”或“不兼容的”，并且可以用数值(例如1或0)表示。因此，算法中传递和使用的实际值可能不同于逻辑意义。其它表示可以是二进制值、文本值、离散电压电平或其它类型的表示。另外或者可替代地，例如参数标识符/值对和/或系统组件标识符/值也可以由不同于其逻辑意义的表示来表示，例如一个或多个数值、二进制值、文本值、离散电压电平，如以上对参数值所解释的。

系统组件兼容性的评估可以在车辆中以几种方式进行。请参阅以下针对替代结构的部分。系统组件可以位于同一个模块hw中，或者系统组件可以位于分离的模块hw中。从这里开始，系统组件和模块意味着同一事物，判定模块是系统主机(systemmaster)的一个示例，而术语变量信息和配置信息可以互换使用。

在集中式系统兼容性检测中，所有模块中的一个模块基于其它模块传输其变量域信息来判定其它模块是否与其兼容。对于变量域，模块可以传输一个或多个变量。对于每个变量域，主机可以接受一个或多个变量作为兼容。主模块将允许或不允许模块根据每个模块是否与其它模块兼容来执行其用户功能。在图8中汽车系统20由模块21、22、23构成。每个模块21、22、23将其变量信息25、26、27发送给判定模块24。判定模块可以是系统主机。每个变量信息25、26、27可以包含描述变量的一个或多个变量参数。模块24比较来自模块21、22、23的变量信息25、26、27，并与存储在模块24中的变量信息进行比较。如果模块24中的兼容性检测结果意味着变量信息25、26、27不兼容，那么结果28、29、30被发送到每个模块21、22、23。当每个模块21、22、23从模块24接收到结果时，则它将禁用其用户功能部件、不兼容的部件，并且存储该结果直到来自模块24的新判定告诉它是兼容的。

在分布式系统兼容性检测中，所有模块都根据其它模块传输其变量域信息的方式做出本地判断其它模块是否分别与每个模块兼容。对于每个配置域，模块可以传输一个或多个变量。对于每个配置域，主机可以接受一个或多个变量作为兼容。取决于其自身的变量信息与其它模块变量信息之间是否存在兼容性或不兼容性，每个模块将允许或不允许自身执行其功能。

在图9中汽车系统40由模块41、42、43构成。每个模块41、42、43将其变量信息发送到每个其它模块。每个变量信息41、42、43可以包含描述该变量的一个或多个变量参数。所有模块41、42、43将变量信息44、45、46发送给彼此，并将其自身的变量信息与从其它模块接收的变量信息进行比较。如果41、42、43装置中的兼容性检测结果不兼容，则分别在每个模块中做出判定。如果做出这样的判定，则每个模块41、42、43将分别禁用其用户功能部件、不兼容的部件，并存储该结果直到做出新的判定。

在图10中汽车系统400由模块410、430、450构成，并且它们与图9中的模块41、42、43相关联。为了简单起见仅示出了模块410的内部功能，并且模块430、450是在内部与模块410相同。描述自身模块变量的本地配置信息被存储在本地配置和接受信息411中并且通过信息401与其它模块通信。接收其它模块本地配置由信息421、422表示。描述模块将哪些本地配置信息作为兼容(接收过滤器)从其它模块接收的本地配置信息被存储在本地配置和接受信息411中并且将其作为信息417提供给相关算法。

相对兼容性判定：每个模块410、430、450在算法412中做出本地判定。算法412中做出的相关算法结果涉及自身模块410变量信息是否与从其它模块接收到的变量信息421、422兼容。如果相对结果418的结果意味着自身模块与其它模块不兼容则它将禁用系统功能414中的系统功能并且在不兼容的情况下将诊断故障代码(dtc)存储在诊断功能416中。通过信息418将该相关算法结果通信至其它模块。接收其它模块的相对兼容性结果由信息423和信息424表示。

系统兼容性判定：每个模块410、430和450在413中产生系统算法结果。系统算法413中产生的系统算法结果涉及自身模块410相对兼容性结果和其它模块430、450兼容性结果是否都意味着它们是全部兼容。来自相关算法结果418和系统算法结果419的结果可以影响系统功能414以在结果不兼容时将其禁用。相关算法结果418和系统算法结果419可以存储在诊断功能416中。

只有相关算法，或者相关算法和系统算法都可以在每个系统组件中实施。如果仅使用相关算法，则算法结果418与系统功能414和诊断功能416一起使用。如果使用相关算法和系统算法，则算法结果419与系统功能414和诊断功能416一起使用。

在图11中，汽车系统50由模块51、52和53以及变量配置主机57构成。每个模块51、52、53将变量信息54、55、56发送到每个其它模块。每个变量信息51、52、53可以包含描述变量的一个或多个变量参数。变量配置主机57将其自身的变量信息与从其它模块接收的变量信息以及从变量配置主机57接收的变量信息58、59、60进行比较。在每个模块中，如果比较结果为意味着配置信息54、55、56不兼容，则分别在每个模块中做出判定。如果做出这样的判定，则每个模块51、52、53将分别禁用其用户功能部件并存储该判定，直到做出新的判定。

在图12中，汽车系统500由模块510、530、550构成，并且它们与图11中的模块51、52、53相关联。为了简单起见仅示出了模块510的内部功能，并且模块530和550是在内部与模块510相同。描述自身模块变量的本地配置信息被存储在本地配置和接受信息511中并且通过信息501被通信至其它模块。接收其它模块本地配置由信息521和信息522表示。描述模块将哪些本地配置信息作为兼容(接收过滤器)从其它模块接收的本地配置信息存储在本地配置和接受信息511中并且作为信息517提供给相关算法。

本地变量信息通过信息501被通信至其它模块。另外，参考系统配置信息被存储在配置信息590中并且作为信息591被通信至所有模块510、520、530。每个变量信息可以包含一个或多个描述变量的变量参数。

相关算法和系统算法类似于图10地被使用。算法512使用相关算法且算法513使用系统算法。另外算法515使用根算法。

在根算法结果不兼容的情况下，该系统可以确定系统的哪个部分具有正确配置以及哪些部分具有不正确的配置因为存在从配置信息590可获得的主参考信息591。该判定在算法515中进行，其中与产生指示系统兼容性/不兼容性的根本原因是否在模块510中的信息520的信息591进行比较。

根算法结果520被转发到诊断功能516。因此，系统50和500比系统40和400具有优势，其中不兼容性的绝对根本原因不能被识别。

该相关算法结果通过信息518通信至其它模块。接收其它模块的相对兼容性结果由信息523和信息524表示。如果使用相关算法和系统算法，则算法结果519与系统功能514和诊断功能516一起使用。

图13显示配置数据可以放置在每个系统组件之外，但仍然与系统组件相关联。系统670由组件614、634、654构成。与那些系统组件614、635、655相关联的配置数据611、631、651处于配置信息680中，其中系统组件与它们的配置数据之间具有关联671、672、673。兼容性输出618、619、620。然后，本发明仅在评估单元610、630、650中在611、631、651中的配置数据上运行。系统670中的所有系统组件614、634、654，配置信息680和评估单元610、630、650可以位于车辆中、部分位于车内或完全位于车辆外部。

描述自身系统组件变量的本地配置信息被存储在本地配置和接受信息611中并且通过信息601被通信至其它评估单元。接收其它系统组件配置信息由信息621和信息622表示。描述评估单元将哪些本地配置信息作为兼容(接收过滤器)从其它评估单元接收的本地配置信息存储在本地配置和接受信息611中并且将其作为信息617提供给相关算法。

通过信息601将本地变量信息通信至其它评估单元。在另一个实施例中，参考系统配置信息被存储在配置信息690中并且作为信息691通信至所有评估单元610、620、630。每个变量信息可以包含描述变量的一个或多个变量参数。

相关算法和系统算法类似于图10地被使用。算法612使用相关算法，而算法613使用系统算法。另外，算法615使用根算法。

在根算法结果为不兼容的情况下，该系统可以确定系统的哪个部分具有正确配置以及哪些部分具有不正确的配置因为存在可从配置信息690获得的主参考信息691。该判定在算法615中进行，其中与产生信息620的信息691进行比较，该信息指示系统兼容性/不兼容性的根本原因是否在评估单元610中。该相关算法结果通过信息618通信至其它评估单元。接收其它评估单元的相对兼容性结果由信息623和信息624表示。如果相关算法和系统算法都被使用，则算法结果619被设置为结果616。

在图14中示出了受模块中的判定信息104影响的车载功能100。功能100对应于图10中的系统功能414和图12中的系统功能514。判定信息104对应于图10中的判定信息419和图12中的判定信息519。判定104被转发给系统功能101，当接收到意味着系统不兼容的判定104时，该系统功能被禁用。

判定信息104被转发到人机界面功能102，人机界面功能可以向驾驶员指示系统是否兼容。驾驶员界面可以是人机界面(hmi)，例如故障指示灯(mil灯)。

在图15中示出了由汽车系统111、112、113构成的车辆110。如前所述，兼容或不兼容的系统判定分别在每个汽车系统111、112、113中基于信息114、115、116做出。汽车系统111、112、113之一的不兼容的汽车系统可能会影响兼容的另一汽车系统111、112、113的操作。如果另一个系统不兼容，可能需要兼容的系统来改变其操作模式或禁用其功能。

在图16中示出了由模块122、123、124构成的汽车系统120。来自模块122、123、124的系统兼容性判定126、127、128被收集在模块125中，该模块可以评估模块126、127和127并将兼容性/不兼容性信息121传输到不是汽车系统120的一部分的系统130。系统130可以是非车载系统，例如信息系统或由汽车制造商、oem访问的软件归档。

如果信息121意味着系统120不兼容，则系统130可以基于兼容/不兼容信息121做出判定，其请求模块125借助于信息131和其它信息132、133、134来禁用或改变模块122、123、124中的功能。信息121可被视为对非车载系统的警告信息。

在启动汽车系统时，可能期望在启动后不久进行兼容性评估，因为运行不兼容的系统可能会施加针对永久性损坏、未定义系统行为的风险或甚至施加针对人身伤害的风险。因此，执行系统兼容性评估可能存在一定的时间间隔。

至少有两种启动系统和启动兼容性评估的方法。第一种方法从启动系统功能开始，在此之后执行兼容性评估，并且只有在结果是兼容系统时系统才会停止。这样做的好处是缩短了系统启动时间，但缺点是不兼容的系统可以启动并运行一段时间。第二种方法从兼容性评估开始，且只有在结果是兼容系统时才启动系统功能。这样做的一个优点是不兼容的系统永远不会启动，而缺点是系统启动时间更长。

在图17中示出了具有三个模块的系统的时序。系统在特定时间tbegin启动，并且特定时间lt1允许系统中的所有模块通信其配置信息、产生本地判定、通信本地判定并最终产生系统判定。系统最初启动时不考虑它是兼容还是不兼容，以便改善系统启动时间。允许的时间lt1可以是任何持续时间。

在图17中事件a、b和c表示三个模块将其自身的配置信息彼此通信，然后需要一些时间进行评估而事件d、e和f表示通信其本地判定的模块。事件g、h和j代表产生系统判定的模块。

可以使用可选的错误处理，以便如果任何模块不通信其配置信息、产生本地判定、传达本地判定并在时间lt1过去之前产生系统判定，则认为这是系统不兼容。超时功能可用于例如图10中的414。

作为替代，可以延迟兼容性评估的执行，直到来自所有系统组件的配置信息都可用。此外，兼容性评估可以利用来自系统的子集的即时可用的配置信息来进行。不可用的配置信息在评估中可被视为兼容、不兼容或仅被忽略，直到该配置信息成为可用。

在图18中示出了具有三个模块的系统的时序。在时间tbegin时系统以没有客户功能的简化模式启动。特定时间lt1允许系统中的所有模块通信其配置信息，以评估系统兼容性。与客户功能有关的系统功能被延迟，直到兼容性评估导致兼容系统，以便例如确保模块化和/或安全性。图18中的lt1不一定与图17中的lt1具有相同的持续时间。

系统组件之间的通信可以以基于事件的方式执行。事件是；系统预启动、系统启动、运行系统时系统模式改变、系统关闭。正在运行或改变其模式的系统组件可以通知该系统中的其它系统组件关于其当前配置数据，例如，功能可用且具有某种配置，或该服务不再可用。图19显示了系统模式在运行时间改变后正在评估的兼容性。

在系统组件启动时或启动之前它将向任何其它系统组件提供其服务以提供其配置数据、相关算法结果、系统算法结果。属于系统的其它系统组件将确认订购该服务。为了识别配置数据属于哪个系统，在系统组件之间使用系统唯一系统标识符，并且只有作为同一系统的一部分的系统组件才会使用同一标识符。

当系统组件从另一个系统组件获得认购时它将向每个订户发送(发布)其当前配置数据、相关算法结果、系统算法结果。

每当作为发布者的系统组件改变其模式以使其可用系统功能发生改变，即变得可用、变得不可用或动态改变其配置数据时，该系统组件将发送(发布)它的当前配置数据、相关算法结果、系统算法结果给每个订户。

每个和所有系统组件可以认购和发布配置数据、相关算法结果、系统算法结果。订户可以通过向发布者发送取消认购消息来取消认购配置数据、相关算法结果、系统算法结果。

模块本地兼容性判定和系统兼容性判定可以以不同的方式进行，并且可以连接到不同的系统事件。如果整个系统可用并传输变量信息，则可立即做出本地兼容性判定和系统兼容性判定。如果部分系统可用且其它部分不可用，则可以推迟本地兼容性判定和系统兼容性判定，直到整个系统可用。系统各部分的可用性可以与系统模式改变、例如与使用模式、电源模式或睡眠/唤醒模式相关。系统各部分的可用性可以与电源、例如与中继电源相关。

在重新配置整个系统或系统的某些部分后，可以再次进行本地兼容性判定和系统兼容性判定。系统可以通过多种不同配置进行有意重新配置，以检测其中完整系统为兼容的配置。一旦初始配置成系统不兼容，这可以用作系统缓解措施，以便尝试实现兼容的系统配置。

系统配置有多种不同的配置，一次配置一种配置。每个配置由不同系统组件的组合组成并且至少为两个系统组件并且至多为所有不同系统组件的总和。对于每种配置，根据本地兼容性判定和系统兼容性判定评估系统是否兼容。系统的配置由例如在图12中的变量配置主机590执行。在图20中示出了用于测试多个配置的算法。目的可能是初始配置被评估为不兼容，并且希望尝试找到另一个兼容的系统配置。“配置系统配置”的步骤可能涉及将软件下载到模块。

图21中的搜索算法可以用于在与属于系统的多个变量的系统组件相关联的多个配置信息中搜索。搜索可以是为了找到一个确定的系统变量的所有兼容系统组件。在610、630、650中的每个相关算法中，使用接受配置，其中所有参数值9a、9b、9c或参数值9a、9b、9c的一部分取自配置信息8a、8b、8c。对于9a、9b、9c中不是从8a、8b、8c获取的参数值，接受配置被设置为“n/a”。

假设安全系统的所有变量都是图23、图24、图28中显示的三种变量的兼容变量。在这个例子中，打算在用于所有三种变量的所有系统组件构成的组中寻找仅用于变量高性能gen1的兼容系统组件。在相关算法的接受配置中，用于安全系统生成的参数值设置为gen1，且安全系统子变量设置为highperf。接受配置中的其它参数值，机电一体化变量、部分网络变量、通用软件变量设置为“n/a”。图21中的搜索算法将用于评估系统所有可用变量的所有系统组件，并仅为较高性能gen1查找与系统组件或系统功能相关的配置信息。只有如下系统组件被放入图21步骤4的列表中，对于所述系统组件而言相关算法610、630、650结果是兼容的且因此系统算法613结果是兼容的以及因而按照较高性能gen1。在图21中创建的那个列表是搜索较高性能gen1的系统组件的结果。

根据本发明的实施例，构建两个版本的第一系统生成gen1的安全系统，即图22中所示的较高性能系统和较低性能系统。较高性能和较低性能涉及客户特征和属性观点。这也许可以是“具有碰撞缓解的安全系统”和“具有碰撞缓解和全自动刹车和大型动物检测的安全系统”。

所述系统由相同数量的电子控制单元(模块)构成，但它们并不相同，存在不兼容的差异在于本发明可以检测到模块是否在系统版本之间混合，即检测不兼容的系统是否放在一起。

所有模块将变量信息(作为发布者)传输到其它模块(作为订户)。所有模块通过基于从其它模块接收到的本地和变量信息的相关算法进行其自身的本地兼容性判定。不接收来自另一模块的预期变量信息被认为是不兼容的变量信息。所有模块传输其自身的相关算法结果(作为发布者)的结果。在系统级别上，在完整的较高性能系统和完整的较低性能系统级别中，系统算法确定整个系统是兼容还是不兼容。这些系统算法结果在每个模块中做出。

图23和图24显示了两个版本的系统，其中每个系统的配置是兼容的。它显示了来自每个模块(每个图的左侧)的传输变量信息以及来自其它模块的变量信息，这些信息包含在每个模块相关算法中并被认为是兼容的(图的右侧)。

较高性能的系统如图23所示，且由模块a、b和c构成。关于每个模块相关算法中使用的变量信息类型，模块之间存在一些差异。当根据此配置系统时，则每个模块将做出意味着它与其它模块兼容的本地判定。

较低性能的系统在图24中示出，并且由模块a、b和c构成。关于在每个模块的相关算法中使用的变量信息类型，模块之间存在一些差异。当根据此配置系统时，则每个模块将做出意味着它与其它模块兼容的本地判定。对于模块a和b，还预计不会接收来自模块a、b和c之外的任何模块的变量信息。对于虚拟模块x，这显示为不接收。模块c忽略从除模块a和b以外的模块接收到的任何变量信息。

图25显示了模块a、b和c的系统算法判定的条件。在每个模块a、b和c中，要求相关算法结果表示兼容，以便每个模块考虑整个系统兼容。这意味着图23和图24中的配置以及图25中的条件一起将导致整个系统兼容。

图23和图24显示了与系统的两个变量、即较高性能系统和较低性能系统兼容的模块c的示例。另外，模块c与两代系统兼容；gen1和gen2，再用的一个例子。

图26显示了检测不兼容系统配置的示例。来自较高性能系统的模块a被放入较低性能的系统中。模块a向模块b和模块c发送变量信息“gen1，highperf，a和x”。根据图24，模块b将期望来自模块a的lowperf但接收到highperf，所以模块a和模块b不兼容，模块b中的相关算法结果将为不兼容，该结果从模块b通信至模块a和模块c。与模块b不兼容的相对结果将适用于所有模块a、b和c各自的系统算法，然后在系统级别上变得不兼容。结果是整个系统中的所有模块都意识到系统中某处存在不兼容性。

模块c在其本地判定中不包含来自模块a的变量信息highperf/lowperf，因为它被设计为忽略该信息。模块c考虑来自模块a的变量信息gen1和gen2是兼容的，从而它是为gen2变量准备的，尽管模块a在此是gen1。如果模块c被放入系统的另一代，例如gen3，它不会与此兼容。

确定条件是仅需要可用配置信息的子集，例如，参照图23、图24、图26，该子集可以仅考虑用于系统安全代(safetysystemgeneration)和系统安全子变量的参数标识符，并且不包括用于确定兼容或不兼容系统的算法中的机电一体化变量、通用软件变量(comswvariant)和部分网络变量。图20中的算法和图13中的算法可用于从所有可用的系统组件中提取一组兼容的系统组件，其满足参数标识符子集的标准。

在图13中，软件670是多个实例，并且它们的配置信息680与软件670相关联并且在算法610、630、650中运行。软件670不被执行。在图20中，对配置信息680的所有排列进行步骤2、3、6，并且只有由图20步骤3中的相关算法和系统算法确定的兼容的排列被添加到步骤4的列表中。

参照图4和图13，系统组件610中的相关算法612在接收到的配置信息11和接受配置信息12的子集上运行，例如，仅仅在信息集13a和信息集14a上运行，而不是在所有信息集13a+14a、13b+14b、13c+14c、13d+14d上运行。系统算法613在系统组件610中运行，并且在系统组件630、650中运行类似的相关算法和系统算法。

当在图20中已经评估了所有可用的排列时则在步骤4中创建的列表包含满足所有定义的域的子集的标准的配置信息680。该列表将具有到可运行软件614、634、654的关联671、672、673。

在图27中显示了安全系统的gen2版本，例如，从前一代gen1发展而来。模块a、b和d与gen1不同，且模块c与gen1中的相同。模块c对模块a和b具有相同的条件，并忽略模块d和任何附加的变量信息。因此，模块c可以在gen2中重新使用，而不会改变模块c。

较高性能的系统如图28所示，且由四个模块构成：模块a、b、c和d。关于每个模块验证中使用哪种类型的变量信息，模块之间存在差异。对于模块a、b和d，还预计不会接收来自除模块a、b和c以外的任何模块的变量信息。对于虚拟模块x而言，这被显示为无接收。模块c忽略从模块a和b以外的模块收到的任何变量信息。

本领域技术人员认识到本发明决不限于上述实施例。相反，在所附权利要求的范围内可以进行许多修改和变型。例如，兼容性验证可用于许多其它应用、软件以及硬件。

另外，通过研究附图、公开内容和所附权利要求，本领域技术人员在实践所要求保护的本发明时可以理解和影响所公开实施例的变型。在权利要求中，词语“包括”并不排除其它元素或步骤，并且不定冠词“一”或“一个”并不排除多个。

各实施例的明细列表

第1条.一种评估车辆的第一系统组件的兼容性的方法，所述方法包括以下步骤：

-提供数据库，所述数据库包括：

车辆平台配置信息，其包括关于两个或更多个车辆模型的配置信息，其中每个车辆模型包括一个或多个方面域，其中每个方面域包括一个或多个系统组件，其中每个系统组件包括配置信息，其中每个配置信息包括一个或多个参数值的集合；

其中两个不同车辆模型的至少两个系统组件属于同一方面域；

其中每个车辆模型的方面域的数量和所述车辆模型的每个方面域的系统组件的数量中的至少一者是二十个或更多；

-通过将所述第一系统组件的配置信息(12)与所述车辆平台中的至少一个其它系统组件的配置信息(11)进行比较来确定所述第一系统组件与所述至少一个其它系统组件之间的兼容性结果，其中将所述第一系统组件的配置信息(12)中的一个或多个参数值(19a)的集合与所述至少一个其它系统组件的配置信息(11)中的一个或多个参数值(18a)的集合进行比较，以确定所述参数值(18a，19a)的集合是否至少具有兼容参数值；

-基于所述第一系统组件是否被确定为与所述至少一个其它系统组件兼容来返回兼容性结果。

第2条.根据第1条所述的方法，其中确定所述第一系统组件与所述车辆平台中的至少一个其它系统组件之间的兼容性结果的步骤包括：使用与每个参数值(18a，19a)的集合相关的标识符(15a，16a)以确定所述第一系统组件的配置信息(12)中的哪个参数值(19a)的集合与所述至少一个其它系统组件的配置信息(11)中的哪个参数值(18a)的集合进行比较。

第3条.根据第2条所述的方法，其中确定所述第一系统组件与所述车辆平台中的至少一个其它系统组件之间的兼容性结果的步骤包括：将所述第一系统组件的配置信息(12)中的多个参数值(19a，19b，19c)的集合与所述至少一个其它系统组件的配置信息(11)中的多个参数值(18a，18b，18c)的集合进行比较以确定每个经比较的成对参数值(18a/19a，18b/19b，18c/19c)的集合在它们之间是否至少具有兼容的参数值。

第4条.根据前述各条中的任一项所述的方法，其中确定所述第一系统组件与所述车辆平台中的至少一个其它系统组件之间的兼容性结果的步骤包括：确定所述第一系统组件与车辆模型中所有其它系统组件之间的兼容性结果。

第5条.根据前述各条中任一项所述的方法，还包括以下步骤：通过将所述第一系统组件的配置信息(2)与系统主机的配置信息(1)进行比较来确定所述第一系统组件与所述系统主机之间的兼容性结果，其中将所述第一系统组件的配置信息(2)中的参数值(9a)的集合与所述系统主机的配置信息(1)中的参数值(8a)的集合进行比较以确定所述参数值(8a，9a)的集合是否至少具有兼容的参数值，并且其中所述返回兼容性结果的步骤是基于所述第一系统组件是否被确定为与所述至少一个其它系统组件以及与系统主机兼容。

第6条.根据前述各条中任一项所述的方法，其中所述方法在所述第一系统组件中本地执行。

第7条.根据前述权利要求中任一项所述的方法，其中如果返回不兼容的结果，则禁用所述第一系统组件。

第8条.根据前述各条中任一项所述的方法，其中所述兼容性结果被本地存储在所述第一系统组件中，直到获得新的兼容性结果。

第9条.一种针对车辆模型中的所有系统组件执行根据前述各条中任一项所述方法的方法，还包括如下步骤：如果所有系统组件返回兼容的结果则确定所述车辆模型是兼容的，否则确定所述车辆模型不兼容。

第10条.根据第9条所述的方法，其中所述方法在车辆系统的启动之前执行，并且不兼容性阻止所述车辆系统的启动。

第11条.根据第9条所述的方法，其中所述方法在车辆系统启动之后的预定时间间隔内执行，并且不兼容性迫使所述车辆系统关闭。

第12条.根据第9条或第11条所述的方法，其中在车辆系统启动之后，所述车辆系统以减小的功能运行，直到所述方法已经返回兼容的结果。

第13条.根据第9至12条中任一项所述的方法，其中如果任何系统组件在被命令执行所述方法之后在预定时间间隔内不通信，则确定所述系统组件的不兼容性。

第14条.根据第9至13条中任一项所述的方法，还包括以下步骤：如果所述车辆模型被确定为不兼容，则评估所述车辆模型中是否存在可用的替代配置，如果存在，则获取用于所述车辆模型的下一配置，并且重复该方法直到达到兼容性或者直到针对车辆模型的所有配置完成该方法。

第15条.根据前述各条中任一项所述的方法，其中所述第一系统组件是电子控制单元。

第16条.一种用于评估车辆的第一系统组件的兼容性的系统，所述系统包括：

-数据库，所述数据库包括：车辆平台配置信息，其包括关于两个或更多个车辆模型的配置信息，其中每个车辆模型包括一个或多个方面域，其中每个方面域包括一个或多个系统组件，其中每个系统组件包括配置信息，其中每个配置信息包括一个或多个参数值的集合；

其中两个不同车辆模型的至少两个系统组件属于同一方面域；

其中每个车辆模型的方面域的数量和所述车辆模型的每个方面域的系统组件的数量中的至少一者是二十个或更多；和

-处理器，被配置为接收：第一系统组件的配置信息(12)和至少一个其它系统组件的配置信息(11)，

并且所述处理器被配置为基于所述接收到的信息，通过将所述第一系统组件的配置信息(12)与所述至少一个其它系统组件的配置信息(11)进行比较来确定所述第一系统组件与所述车辆平台中的至少一个其它系统组件之间的兼容性结果，其中将所述第一系统组件的配置信息(12)中的一个或多个参数值(19a)的集合与所述至少一个其它系统组件的配置信息(11)中的一个或多个参数值(18a)的集合进行比较以确定所述参数值(18a，19a)的集合是否至少具有兼容的参数值；并且所述处理器被配置为：

-基于所述第一系统组件是否被确定为与所述至少一个其它系统组件兼容来返回兼容性结果。