Verfahren zum Betreiben eines Systems und System

Beschreibung:

Die Erfindung betrifft ein Verfahren zum Betreiben eines Systems und ein System.

Es ist bekannt, Busteilnehmer mittels einer Schnittstelle, wie beispielsweise ein Datenbus, zum Datenaustausch betreibbar zu verbinden. Dies gilt insbesondere für Feldgeräte, wie Umrichter, dezentrale oder zentrale Steuerungen und dergleichen. Meist weisen die Teilnehmer eine individuelle Adresse auf und tauschen die Daten in einem jeweils vorgeschriebenen Busprotokoll aus.

Es ist auch bekannt, Softwaremodule, wie Plugins über eine Schnittstelle zum Datenaustausch zu verbinden. Auch hierbei werden die Daten gemäß einem vorgeschriebenen Protokoll ausgetauscht.

Bei komplexen Systemen, wie umfangreichen Softwaremodulen oder Busteilnehmern, werden meist viele Entwicklungsstadien durchlaufen. Somit ist das überprüfen der Kompatibilität der verschiedenen Protokoll-Versionen aufwändig.

Der Erfindung liegt daher die Aufgabe zugrunde, bei komplexen Systemen die Inbetriebnahme zu vereinfachen.

Erfindungsgemäß wird die Aufgabe bei dem Verfahren nach den in Anspruch 1 und bei dem System nach den in Anspruch 11 angegebenen Merkmalen gelöst.

Wichtige Merkmale der Erfindung bei dem Verfahren sind, dass es zum Betreiben eines Systems, umfassend Teilnehmer, die über eine Schnittstelle Daten austauschen, wobei

jeder Teilnehmer eine Protokoll-Versions-Information oder eine Liste aller seiner, insbesondere seinen vorangegangenen Entwicklungsstadien zugeordneten, vorangegangenen Protokoll-Versions-Informationen speichert,

wobei während der Initialisierungsphase die oder eine, insbesondere neueste, Protokoll- Versions-Information ausgetauscht und verglichen wird.

Von Vorteil ist dabei, dass auch bei Teilnehmern, die verschiedene Versionen in ihrer Entwicklungshistorie durchlaufen haben, ein Vergleich der Versionen auf Kompatibilität der Protokolle ermöglicht ist. Außerdem ist die Inbetriebnahme bei komplexen Systemen vereinfacht und sicherer. Darüber hinaus erkennen die Teilnehmer selbsttätig, also automatisch, wenn sich die Schnittstelle geändert hat und ein Update erforderlich ist.

Bei einer vorteilhaften Ausgestaltung umfasst die Protokoll-Versions-Information, also CIPV, zumindest eine Information über die aktuelle Version, also CurrVer, eine Information über die Kompatibilitätsversion, also CompVer, und eine Information über den Matchcode. Von Vorteil ist dabei, dass als Matchcode eine eindeutig der jeweiligen Version zuordenbare Information vorsehbar ist, beispielsweise das Erstellungsdatum der Version. Andererseits ist auch eine Summe solcher vorangegangener Matchcodes, wie Erstellinformationen verwendbar. Insgesamt wird also in der Initialisierungsphase eine Information ausgetauscht, mit der Kompatibilität feststellbar ist oder eine ältere vorangegangene kompatible Protokollversion auffindbar ist.

Bei einer vorteilhaften Ausgestaltung ist der Matchcode der aktuellen Version CurrVer seiner zugehörigen Protokoll-Versions-Information eindeutig zugeordnet. Von Vorteil ist dabei, dass eine eindeutige Identifizierung ausführbar ist, beispielsweise ein Erstelldatum oder dergleichen.

Bei einer vorteilhaften Ausgestaltung wird als Ergebnis des Vergleichs die volle Kompatibilität, die volle Inkompatibilität, Unplausibilität oder die Kompatibilität mit der jeweils neuesten oder einer älteren Version festgestellt,

insbesondere wobei das weitere Verhalten des anderen Teilnehmers beobachtet und mit ausgewertet wird. Von Vorteil ist dabei, dass eine erhöhte Sicherheit gewährleistbar ist beim Datenaustausch. Außerdem ist es auch ermöglicht, entsprechend einer älteren Protokollversion Daten auszutauschen.

Bei einer vorteilhaften Ausgestaltung ist der Matchcode der ausgetauschten CIPV als Summe aller Matchcodes der in der Liste des jeweiligen Teilnehmers vorangegangenen CIPV gebildet, insbesondere modulo einer Basis. Von Vorteil ist dabei, dass eine Entwicklungshistorie nachvollziehbar ist.

Bei einer vorteilhaften Ausgestaltung wird sukzessive, insbesondere von der neuesten zur ältesten CIPV, mit den Listeneintragungen verglichen, insbesondere bis zumindest teilweise Kompatibilität festgestellt wird. Von Vorteil ist dabei, dass mit einer kompatiblen Version, insbesondere einer möglichst aktuellen aus der Entwicklungshistorie, ein Datenaustausch durchführbar ist.

Bei einer vorteilhaften Ausgestaltung summiert ein Teilnehmer so viele Matchcodes seiner Historie solange auf, bis der jeweils gebildete Summenwert dem Matchcode der aktuellen Version der ausgetauschten CIPV, also der vom anderen Teilnehmer empfangenen, gleicht und somit eine vergleichbare CIPV festgestellt ist, wobei die Aufsummation bei seiner ältesten CIPV begonnen wird und der zeitlichen Rangfolge folgt, insbesondere wobei der nachfolgende Datenaustausch gemäß der aktuellen Version der ausgetauschten CIPV des zu dieser CIPV zugehörigen Teilnehmers erfolgt. Von Vorteil ist dabei, dass die aktuellste kompatible Protokollversion aus der Entwicklungshistorie feststellbar ist.

Bei einer vorteilhaften Ausgestaltung beobachtet bei Nichtauffinden einer vergleichbaren CIPV der Teilnehmer das Kommunikationsverhalten des anderen Teilnehmers während des auf die Initialisierungsphase folgenden Datenaustausches und nimmt dementsprechend Kompatibilität an oder verneint gegebenenfalls. Von Vorteil ist dabei, dass auch bei Nichtfinden einer vergleichbaren CIPV allein durch das Beobachten des Verhaltens des anderen Teilnehmers ein Datenaustausch freigebbar ist.

Bei einer vorteilhaften Ausgestaltung werden abhängig vom Ergebnis des Vergleichens Fehlermeldungen, Warnmeldungen oder dergleichen abgegeben oder es wird der Datenaustausch fortgeführt. Von Vorteil ist dabei, dass der Bediener oder ein mittels Datenaustauschverbindung verbundener Teilnehmer informiert wird und zugehörige

Maßnahmen einleiten kann. Beispielsweise kann die Meldung auch das Erfordernis zum Inhalt haben, dass ein Update erforderlich ist.

Wichtige Merkmale bei dem System sind, dass es Teilnehmer umfasst, die über eine Schnittstelle zum Datenaustausch geeignet betreibbar sind,

wobei jeder Teilnehmer einen Speicher zum Abspeichern einer Protokoll-Versions- Information aufweist,

wobei während der Initialisierungsphase die Protokoll-Versions-Information austauschbar ist,

wobei jeder Teilnehmer Vergleichsmittel für das Vergleichen der Protokoll-Versions- Information, welche im zugehörigen Speicher abgelegt ist, und der empfangenen Protokoll- Versions-Information umfasst.

Von Vorteil ist dabei, dass der Speicherbedarf gering ist, da nur eine CIPV oder eine Liste von CIPV abzuspeichern ist, und trotzdem eine hohe Sicherheit gewährleistbar ist. Außerdem ist die Inbetriebnahme vereinfacht. Der Aufwand bei Erstellen einer neuen Version beim Entwicklungsvorgang des Teilnehmers ist gering, da zu jeder neuen Version nur eine zugehörige CIPV zusätzlich abzuspeichern ist.

Weitere Vorteile ergeben sich aus den Unteransprüchen.

Bezugszeichenliste

T1 Teilnehmer T2 Teilnehmer

Die Erfindung wird nun näher erläutert:

Die Erfindung bezieht sich auf mindestens zwei Objekte, zwischen denen über eine Schnittstelle ein Datenaustausch ausführbar ist.

Objekte sind hierbei in einem ersten erfindungsgemäßen Ausführungsbeispiel Vorrichtungen, wie Automatisierungsgeräte, Umrichter, Steuerungen oder andere Geräte der Anlagentechnik. Allgemein gesprochen sind also Busteilnehmer als Objekte vorsehbar, die über eine Datenbusverbindung im Datenaustausch stehen.

In einem zweiten erfindungsgemäßen Ausführungsbeispiel sind die Objekte als Softwaremodule ausgeführt, beispielsweise als Plugins, Viewer oder entsprechende Softwareprodukte, die zum Datenaustausch befähigt sind.

Bei beiden Varianten von Objekten ist nicht immer gewährleistet, dass zwei Objekte sich richtig verständigen, wenn sie untereinander Daten austauschen. Insbesondere nachdem mindestens eines der Objekte aktualisiert wurde, muss manuell festgestellt werden, ob eine korrekte Verständigung möglich ist und ob die nachfolgend ausgetauschten Daten zueinander passen. Bei Objekten, die Vorrichtungen sind kann die Aktualisierung den Austausch des physischen Geräts oder eines seiner Teilkomponenten betreffen oder ein Software-Update der Software des Geräts.

Bei der Erfindung tauschen beide Objekte vorzugsweise innerhalb ihrer Initialisierungsphase die sogenannte Protokoll-Versions-Information, im Folgenden auch als CIPV bezeichnet, untereinander aus, dann stellen die Objekte dadurch selbstständig fest, inwieweit sie kompatibel zueinander sind. Im Fall der Kompatibilität kann der Datenaustausch fortgesetzt werden, andernfalls verhalten sie sich sicher im Sinne des Systems, in dem sie sich befinden.

Insbesondere sind als Objekte Teilnehmer eines Bussystems vorsehbar mit einer Punkt-zu-Punkt-Schnittstelle zwischen zwei Teilnehmern (beispielsweise zwei Geräte, die über eine beliebige, beispielsweise serielle, Schnittstelle kommunizieren oder

einer Schnittstelle zwischen zwei Komponenten einer Software (beispielsweise Softwaremodule, wie Plug-ins oder DLLs) oder einer Busschnittstelle mit mehreren Teilnehmern. Die Objekte werden daher auch als „Teilnehmer" bezeichnet. Die CIPV besteht grundsätzlich aus drei Elementen, die hier mit

CurrVer, also aktuelle Version, CompVer, also Kompatibilitätsversion und Matchcode bezeichnet werden.

Die Elemente der CIPV sind als Ganzzahlen, Fließkommazahlen, Zeichen, Zeichenketten oder beliebige Kombinationen hieraus wählbar. Wichtig bei der Wahl des Datentyps der Elemente ist nur, dass sich zwei Elemente des Namens CurrVer oder zwei Elemente des Namens CompVer oder ein Element des Namens CurrVer mit einem Element des Namens CompVer so vergleichen lassen, dass bestimmt werden kann ob und welches der beiden Elemente den größeren bzw. den kleineren Wert hat als das andere. Die Positionswahl der Elemente, also die Element-Nummer, ist ebenfalls frei. Wichtig bei der Positionswahl ist nur, dass in dem Gesamtsystem, in dem CIPVs untereinander ausgetauscht werden, die Positionen so gewählt sind, dass der oben genannte Vergleich durchführbar ist.

Im weiteren Verlauf dieser Funktionsbeschreibung werden Beispiele gezeigt, in denen die Elemente der CIPV jeweils aus einem 16-Bit-Wort bestehen, und die Elemente in der Reihenfolge CurrVer, CompVer, Matchcode auftreten.

In Tabelle 1 ist für ein erfindungsgemäßes Ausführungsbeispiel das Format einer Basis-CIPV gezeigt, welche die Grundstruktur der CIPV hat.

Ein konkretes Beispiel ist: {1002, 1000, 12077} steht für Version V1.002 vom 12.07.2007, kompatibel bis V1.000, also eine ältere Version.

Im Folgenden wird nun der Austausch der CIPV, beispielweise während der Initialisierungsphase, und der nachfolgende Vergleich beschrieben: Jeder der Teilnehmer hält am Portal seiner Schnittstelle eine CIPV bereit. In der Initialisierungsphase bzw. der ersten Kontaktaufnahme tauschen sie zumindest auch die CIPV untereinander aus.

Im einfachsten Fall genügt der Vergleich der untereinander ausgetauschten CIPVs, die als Basis-CIPVs ausgeführt sind. Es kann für folgende Fälle beispielsweise adäquat folgendermaßen reagiert werden:

1. Alle drei CIPV-Elemente stimmen überein: Die Teilnehmer sind zueinander kompatibel, es besteht kein Handlungsbedarf, der Datenaustausch kann stattfinden.

2. Die aktuelle Version des Teilnehmers T1 ist höher als die des Teilnehmers T2 und die Kompatibilitätsversion des Teilnehmers T1 ist kleiner oder gleich der aktuellen Version des Teilnehmers T2: Hierzu sei als konkretes Beispiel genannt:

CIPV T1 = {1002, 1000, 12077}, CIPV T2 = {1000, 1000, 25037}, Folgerung: Der Teilnehmer T1 enthält zusätzliche Eigenschaften, die durch den Teilnehmer T2 nicht bedient werden können. Der Teilnehmer T1 ist abwärtskompatibel. Verhalten des Teilnehmers T1 : T1 kann das berücksichtigen z. B. durch

Nichtbenutzung der zusätzlichen Eigenschaften gegenüber der Gegenstelle T2. Gleichzeitig kann er dem Benutzer melden, dass T2 die zusätzlichen Eigenschaften nicht unterstützt. Verhalten des Teilnehmers T2: T2 kann das berücksichtigen z. B. durch Erzeugen einer Fehlermeldung an T1 , sollte T1 die zusätzlichen Eigenschaften benutzen. Gleichzeitig kann T2 dem Benutzer melden, dass die Gegenstelle T1 scheinbar zusätzliche Eigenschaften hat, die T2 nicht unterstützt. Verhalten des Benutzers: Er kann eine Aktualisierung des Teilnehmers T2 durchführen, andernfalls muss er mit Einschränkungen des Funktionalitätsumfangs von T1 rechnen.

3. Die aktuelle Version des Teilnehmers T1 ist höher als die des Teilnehmers T2 und die Kompatibilitätsversion des Teilnehmers T1 ist höher als die aktuelle Version des Teilnehmers T2:

Hierzu sei als konkrete Beispiel genannt: CIPV T1 = {1010, 1003, 47018}, CIPV T2 = {1000, 1000, 25037},

Neben zusätzlichen Eigenschaften von T1 herrscht eine Inkompatibilität bereits vorhandener Eigenschaften, die bei Benutzung wahrscheinlich zu

Fehlfunktionen führen werden.

Verhalten des Teilnehmers T1 : T1 reagiert darauf z. B. durch das Einstellen der Kommunikation zu T2. Gleichzeitig meldet T1 dem Benutzer, dass er zur

Gegenstelle T2 nicht mehr kompatibel ist.

Verhalten des Teilnehmers T2: T2 berücksichtigt das, indem er z. B. so reagiert wie T1.

Verhalten des Benutzers: Er wird aufgefordert eine Aktualisierung des Teilnehmers T2 durchzuführen. Bis dahin werden der Kommunikationsbetrieb zwischen beiden Teilnehmern und die daran gekoppelten Funktionen eingestellt.

4. Unplausible Fälle wie z. B. a) bei mindestens einem der Teilnehmer ist die Kompatibilitätsversion größer als die eigene aktuelle Version oder b) die aktuelle Version sowie die Kompatibilitätsversion beider Teilnehmer stimmt überein, der Matchcode jedoch nicht führen zum sofortigen Einstellen des Kommunikationsbetriebs zwischen beiden Teilnehmern und die daran gekoppelten Funktionen sowie einer Aufforderung an den Benutzer den fehlerhaften Teilnehmer zu aktualisieren.

In der Tabelle 2 ist hierzu, also zum einfachen C I PV- Vergleich eine tabellarische Zusammenfassung gezeigt.

Im Folgenden wird die Sicherheit im Sinne der Kompatibilitätsgarantie beschrieben:

Von den oben genannten unplausiblen Fällen sei ein wahrscheinlicher herausgegriffen:

Die aktuelle Version sowie die Kompatibilitätsversion beider Teilnehmer stimmt überein, der Matchcode jedoch nicht.

Geschildert wird hier ein noch relativ einfacher Fall: Ein solcher Fall kann zustande kommen, wenn sich die Versionen auseinander entwickeln. Man stelle sich hierzu vor, dass zwei am Bus teilnehmende Objekte von unterschiedlichen Instanzen bearbeitet werden. Ursprünglich hatten sie die gleiche Version. Der Teilnehmer T1 wurde weiter entwickelt, insbesondere inklusive der Inkrementierung der Version und änderung des Matchcodes. In ähnlichem Zeitraum wurde Teilnehmer T2 ebenfalls weiter entwickelt, insbesondere inklusive der Inkrementierung der Version und des Matchcodes. Die Entwicklung beider Teilnehmer ging jedoch ohne Absprache untereinander vonstatten. Das Zielsystem wurde bis dato mit keinem der beiden Weiterentwicklungen aktualisiert. Kommt es nun zu einer Aktualisierung beider Teilnehmer auf dem Zielsystem mit den jeweiligen Weiterentwicklungen, dann tritt der oben genannte Fall unter Punkt 4 ein. Der Matchcode legt für diesen Fall den Konflikt offen und der Anwender, also Benutzer, wird aufmerksam.

Dies ist ein Beispiel für zwei Teilnehmer auf einem Zielsystem und insofern relativ überschaubar.

Betrachtet werden soll ein komplexeres Systeme mit folgenden Eigenschaften:

Viele Teilnehmer, beispielsweise bis 10 oder bis über 1000, die nicht nur einfache Punkt-zu-Punkt-Schnittstellen haben, sondern in denen einige Teilnehmer viele Schnittstellen zu mehreren anderen Teilnehmern haben, oder

Bussysteme mit mehreren Teilnehmern.

Das System enthält unterschiedliche Teilnehmerarten: z. B. einige Softwarekomponenten auf einem PC gekoppelt über unterschiedliche Schnittstellen untereinander und über DFü-Schnittstellen an Geräte, die ihrerseits einige Softwarekomponenten enthalten.

Die Teilnehmer werden nicht nur von einer oder zwei, sondern von vielen Instanzen, beispielsweise bis 10 oder mehr, bearbeitet und weiter entwickelt.

Die Entwicklung der Teilnehmer durch die Instanzen erstreckt sich über einen längeren Zeitraum, beispielsweise mehrere Jahre, auch im Rahmen der Weiterentwicklung des Produkts in dessen Lebenszyklus.

Einige der Teilnehmer sind universelle Module, die auch über die Produktgrenzen hinaus verwendet werden.

Dieses System ist in vielerlei Hinsicht nicht mehr überschaubar, aber eher häufig als selten anzutreffen und sicher häufiger als das oben geschilderte einfache Ausführungsbeispiel.

In dem genannten komplexen Fall ist es denkbar, dass viele Teilnehmer innerhalb deren Produktlebenszyklus weiter entwickelt werden, ohne dass eine explizite Absprache zu den Entwicklungsinstanzen der anderen Teilnehmer stattfindet.

So ist es sogar wahrscheinlich, dass mehrere Entwicklungsschritte mit entsprechend mehrfacher änderung der Versionen und des Matchcodes stattgefunden haben werden bevor ein Zielsystem mit dem weiter entwickelte Teilnehmer aktualisiert wird. Der Aufwand zur überwachung aller potentiell angeschlossenen Teilnehmer an die geänderte Schnittstelle des weiter entwickelten Teilnehmers ist unverhältnismäßig hoch und somit für die Praxis untauglich. Besonders bei einem universellen Teilnehmer ist es so gut wie nicht möglich festzustellen, welche Teilnehmer an dessen Schnittstelle oder Schnittstellen angeschlossen werden.

Im Zuge dessen ist es denkbar, dass nach dem überspringen erst mehrerer Entwicklungsschritte zwei Teilnehmer durch eine Aktualisierung im Zielssystem wieder zusammenfinden, möglicherweise sogar unter der gleichen Versionsangabe. Da der Matchcode höchstwahrscheinlich nicht mehr passt, ist es sehr wahrscheinlich, dass zur Aufrechterhaltung des Betriebs nur der letzte Entwicklungsschritt angepasst wird, nicht jedoch die Zwischenschritte: Somit ist der Entwicklungsprozess beider Teilnehmer nicht abgeglichen und eine Kompatibilitätsgarantie ist nicht gegeben.

Um zu gewährleisten, dass die Teilnehmer wirklich kompatibel zueinander sind, ist bei einem Abgleich erforderlich, dass auch der vergangene Entwicklungsprozess in all seinen Schritten berücksichtigt wird. Dies kann nur geschehen, indem die Spezifikationen sämtlicher Zwischenschritte begutachtet und ggf. a postum implementiert werden. Auch das soll durch die CIPV, insbesondere den Matchcode, signiert werden.

Da in der Basis-CIPV nur der Matchcode zur aktuellen Version passt und bei einfacher Sicherheit nur auf diese Weise unter den Teilnehmern ausgetauscht und auf Kompatibilität geprüft wird, kann der Entwicklungsprozess nicht berücksichtigt werden.

Eine Methode wäre zwar, dass alle CIPVs (also auch jene, die während des Entwicklungs- prozesses entstanden sind) untereinander ausgetauscht werden.

Es leuchtet aber ein, dass diese Methode unter Umständen einen unvertretbar hohen Kommunikationsaufwand bedeutet, der entsprechend schlecht verwaltbar ist. Abgesehen davon ist der Kommunikationsaufwand nicht sicher determinierbar, was für viele Kommunikationssysteme nicht zu bewältigen ist. Darüber hinaus wird dadurch Anspruch des CIPV-Systems an dessen Universalität vernichtet und die Hemmschwelle der Benutzung erhöht.

Im Folgenden wird das Format einer Austausch-CIPV beschrieben, die zum Austausch mit der Gegenstelle gemäß Tabelle 3 aufgebaut ist. Diese Form der CIPV ist vom Format her identisch mit der Basis-CIPV. Ebenso ist die Information und Bedeutung der ersten beiden Elemente zur Basis-CIPV identisch.

Allein der Matchcode birgt eine etwas andere Information: Er enthält die Summe der Matchcodes aller vorausgegangenen Versionen und der aktuellen Version. Dabei wird die Summe vorzugsweise modulo einer Basiszahl berechnet. Im Folgenden wird der Austausch der CIPV bei der Initialisierung, der Vergleich der CIPV und die zugehörige Sicherheit beschrieben, insbesondere ist dabei wichtig, dass durch die Bildung der Summe aller Matchcodes der vergangene Entwicklungsprozess berücksichtigbar ist.

Hierzu beherbergt jeder der Teilnehmer für seine Schnittstelle intern eine CIPV-Historie, also beispielsweise eine Liste aller CIPV seiner vorhergehenden Entwicklungsstadien. In der CIPV-Historie sind alle Basis-CIPVs gespeichert, die während des Entwicklungsprozesses zur Veränderung der Schnittstelle geführt haben.

Beispiel:

{1000, 1000, 25037} Serienstart Version 1.000, vom 25.03.2007. {1002, 1000, 12077} Version V1.002 vom 12.07.2007, kompatibel bis V1.000. {1003, 1000, 27117} Version V1.003 vom 27.11.2007, kompatibel bis V1.000. {1004, 1000, 19127} Version V1.004 vom 19.12.2007, kompatibel bis V1.000.

{1010, 1003, 47018} Version V1.010 vom 07.01.2008, kompatibel bis V1.003.

In der Tabelle 4 ist ein Beispiel aufgeführt, bei dem der Vergleich der Austausch-CIPV Vollkompatibilität ergibt. Nach dem Vergleich der Austausch-CIPVs stellen beide Teilnehmer fest, dass sie vollkompatibel zueinander sind.

In Tabelle 5 ist ein Beispiel aufgeführt, bei dem der Vergleich der Austausch-CIPV eingeschränkte Kompatibilität ergibt. Liegt der Teilnehmer T2 gegenüber Teilnehmer T1 um einen Schritt in der Entwicklung zurück, dann ergibt sich für die Historie der beiden Teilnehmer beispielhaft Tabelle 5.

Der Vergleich unter Berücksichtigung des Entwicklungsprozesses findet statt, indem die beiden Teilnehmer die untereinander ausgetauschte CIPV mit jeweils ihrer eigenen Historie nachvollziehen. Es entsteht eine vergleichbare CIPV.

Teilnehmer T1 berechnet die vergleichbare CIPV, indem er so viele Matchcodes seiner Historie solange aufsummiert, bis er auf die aktuelle Version des Teilnehmers T2 trifft, wobei die Aufsummation bei seiner ältesten CIPV begonnen wird und der zeitlichen Rangfolge folgt. Ein Beispiel hierzu ist in Tabelle 6 angegeben.

Dieser Fall entspricht dem oben geschilderten Fall 2, auch was das Verhalten der Teilnehmer und des Anwenders betrifft.

Nach einem Vergleich der vergleichbaren CIPVs stellt Teilnehmer 1 fest, dass er sich echt abwärtskompatibel (auch im Entwicklungsprozess) zu Teilnehmer 2 verhalten kann.

Teilnehmer T2 kann keine vergleichbare CIPV berechnen, weil ihm der Matchcode der aktuellen Version des Teilnehmer T1 {1004, 1000, 19127} fehlt. Den Entwicklungsprozess von T1 kann er also nicht nachvollziehen. Das muss er auch nicht; denn er glaubt, dass T1 abwärtskompatibel zu T2 ist. Die Gewissheit erhält er dadurch, dass T1 weiter mit ihm kommuniziert und in den Datenaustauschbetrieb übergeht, denn T1 konnte die Berechnung der vergleichbaren CIPV inklusive des Entwicklungsprozesses vollständig durchführen.

Würde T1 feststellen, dass eine Abweichung im Entwicklungsprozess stattgefunden hat, stellt er den Kommunikationsbetrieb zu T2 ein, wie auch in dem unter Punkt 3 oder 4 oben beschriebenem Fall..).

Die Situation der Inkompatibilität kann in drei Fälle geteilt werden:

1. Die aktuelle Version des Teilnehmers T1 ist höher als die des Teilnehmers T2 und die Kompatibilitätsversion des Teilnehmers T1 ist höher als die aktuelle Version des Teilnehmers T2. Als Beispiel dienen folgende CIPVs (mit Matchcode-Summe in 16bit)

CIPV T1 = {1010, 1003, 64840}, CIPV T2 = {1000, 1000, 25037}, Dieser Fall ist direkt vergleichbar mit vorbeschriebenem Punkt 3. Entsprechend kann reagiert werden.

2. Der unplausible Fall, dass bei mindestens einem der Teilnehmer die Kompatibilitätsversion größer als die eigene aktuelle Version. Dieser Fall ist direkt vergleichbar mit oben beschriebenen Punkt 4a. Entsprechend kann reagiert werden.

3. Der scheinbar unplausible Fall, dass die aktuelle Version sowie die Kompatibilitätsversion beider Teilnehmer übereinstimmt, der Matchcode jedoch nicht, wird durchaus plausibel, wenn die Austausch-CIPV aus der CIPV-Historie berechnet wurde. Dieser Fall ist vergleichbar mit oben beschriebenem Punkt 4b. Entsprechend kann reagiert werden.

In Tabelle 7 ist ein Beispiel aufgeführt, bei dem der Vergleich der Austausch-CIPV Inkompatibilität ergibt.

Offensichtlich ist im Entwicklungsprozess beider Teilnehmer eine unterschiedliche Zwischenversion implementiert worden. Auch wenn beide Teilnehmer sich mit der Spezifikation der aktuellen Version 1004 einig sind, so kann es doch sein, dass Probleme auftreten, wenn Teile aus der Implementierung der einst aktuellen Version 1003 verwendet werden. Dieser Fall kann mit dem Vergleich der aktuellen Basis-CIPVs {1004, 1000, 19127} nicht aufgedeckt werden, denn der Matchcode legt den Konflikt nicht offen, der Anwender wird über eventuelle Probleme nicht aufmerksam.

Erst der Vergleich einer Austausch-CIPV, die beidseitig aus der Historie gebildet wird, deckt auch diesen Fall auf. Der Entwicklungsprozess beider Teilnehmer ist durch die Einbeziehung der CIPV- Historie in die Austausch-CIPV vollständig abgeglichen. Im Ergebnis kann eine Kompatibilitätsgarantie gegeben werden.