-
Die
Erfindung bezieht sich auf ein Verfahren zur Vollständigkeits-
und Konsistenzprüfung
einer Informationsbibliothek, die einer Anzahl von Modulen zugeordnet
ist, aus welchen entsprechend einer vorgegebenen Konfigurationsstruktur
eine Einrichtung zusammensetzbar ist.
-
Es
ist üblich,
eine komplexe technische Einrichtung, wie z.B. einen Magnetresonanz(MR)-Tomografen modular
zu konzeptionieren. Hierunter wird verstanden, dass die gesamte
Einrichtung aus einer Vielzahl einzelner Module, z.B. Magnetspulen,
Empfänger,
Verstärker,
Behandlungstisch, etc. zusammensetzbar ist. Für jedes dieser vorstehend nur
dem Typ nach spezifizierten Module existieren in der Regel mehrere
Varianten oder Ausführungsformen,
z.B. verschiedene Bauformen des Behandlungstisches, verschiedene
Magnetspulen etc., unter welchen im Zuge der Konzeptionierung eines
konkreten Exemplars der Einrichtung auszuwählen ist. Ein Modul ist dabei
in der Regel selbst wiederum aus Modulen zusammengesetzt. Beispielsweise
besteht der Behandlungstisch aus den Modulen Chassis, Höhenverstellung,
Auflage, etc., wobei für
jedes dieser Module wiederum mehrere Varianten zur Auswahl stehen
können.
Des Weiteren können
auch Verfahrensabläufe
(sogenannte „Workflows"), die zur Einstellung,
Wartung oder Bedienung der Einrichtung vorzunehmen sind, modular
strukturiert sein. Ein Modul kann in diesem Sinne folglich einen
gegenständlichen
Vorrichtungsbestandteil, aber auch einen Software-Bestandteil oder
einen Verfahrensablauf zum Inhalt haben.
-
Eine
Einrichtung der vorstehend beschriebenen Art existiert demnach nicht
in einer einzigen wohldefinierten Bauform. Vielmehr existiert entsprechend
einer jeweils bestimmten Auswahl von Modulen eine Vielzahl unterschiedlicher
Konfigura tionen der Einrichtung. Die Gesamtheit aller Konfigurationen
wird wiedergegeben durch eine so genannte Konfigurationsstruktur.
Die Konfigurationsstruktur enthält
die gegenseitigen Abhängigkeiten
der Module, also beispielsweise welche Module gegebenenfalls Untereinheiten
eines übergeordneten
Moduls sind. Weiterhin ist in der Konfigurationsstruktur spezifiziert,
welches Modul in einer Konfiguration gegebenenfalls das Vorhandensein
eines bestimmten weiteren Moduls erfordert oder welches Modul mit
einem bestimmten weiteren Modul in einer Konfiguration gegebenenfalls
nicht kombinierbar ist. Eine der Konfigurationsstruktur entsprechende
Auswahl von Modulen wird als „gültige" Konfiguration bezeichnet.
In der Regel führt
nur eine solche gültige
Konfiguration zu einer funktionstüchtigen Einrichtung.
-
Es
ist häufig
erforderlich, im Zusammenhang mit einer technischen Einrichtung
einen bestimmten Bestand an Information zu schaffen. Hierunter fällt beispielsweise
die Dokumentation der Einrichtung, also technische Handbücher, Benutzerhandbücher, Programmieranleitungen,
etc. Die im Zusammenhang mit einer technischen Einrichtung erforderliche
Information umfasst des Weiteren aber auch z.B. eine Parametersammlung
zur Parametrierung der Einrichtung, Konfigurationsdateien, Treiber-Software
od.dgl.
-
Herkömmlicherweise
wird die der Einrichtung zugeordnete Information, z.B. also das
Handbuch oder die Parametersammlung, für jede Konfiguration der Einrichtung
individuell erstellt. Bei der Vielzahl möglicher Konfigurationen einer
komplexen technischen Einrichtung, wie des anfangs beispielhaft
genannten MR-Tomografen, ist jedoch eine individuelle Anpassung
der Information an jede mögliche
Konfiguration aufgrund des damit verbundenen Aufwands kaum mehr
möglich.
Alternativ dazu wird häufig
im Zusammenhang mit einer technischen Einrichtung Information geschaffen,
die für
eine Vielzahl von Konfigurationen der Einrichtung gleichermaßen gültig ist,
z.B. in Form eines Universal-Handbuchs, das gleichermaßen alle
möglichen Konfigurationen
der Einrichtung abdeckt. Hierdurch wird jedoch insbesondere bei
hoher Komplexität
der Einrichtung oder bei vielen Konfigurationsmöglichkeiten die Handhabbarkeit
der Information in der Regel beeinträchtigt.
-
Aus
der
DE 202 09 766
U1 ist ein EDV-basiertes Dokumentationssystem für technische
Anlagen bekannt. Es umfasst eine Symboldatenbank, in welcher grafische
Symbole zur Repräsentation
der Anlagenkomponenten speicherbar sind und eine Konfigurationseinheit,
mittels der die Symbole abrufbar, in einem Arbeitsbereich platzierbar
und untereinander verbindbar sind. Derart lässt sich eine Konfiguration
der technischen Anlage nachbilden und speichern. Zur Ansicht der
Konfiguration können
mehrere Detailstufen geladen werden.
-
Die
DE 197 51 273 A1 offenbart
ein Verfahren zum computergestützten
Erstellen und Handhaben einer auf Produkt- oder Prozesslebenszyklen
Bezug nehmenden Datenbank. Dabei wird eine für alle Systemkomponenten einen
Zugriff bildende gemeinsame Datenbank angelegt, wobei die Struktur
und die Tiefe der Adressierung für
die Datenbank auf das jeweilige Prozess- oder Produktmodell und
dessen Funktion ausgerichtet sind. Die Datenbank wird unter einer
einheitlichen und darstellungsseitig bildorientierten Benutzeroberfläche verwaltet,
wobei die Systemkomponenten unter Steuerung durch diese Benutzeroberfläche mindestens teilweise
selbstständig
interaktiv kommunizieren können.
-
Die
DE 196 44 481 A1 offenbart
ein computergestütztes
Arbeits- und Informationssystem, mittels dem ein objektorientiertes
Engineering einer Anlage möglich
ist. Dazu ist ein Datenmodell vorgesehen, das die in der Realität vorkommenden
Objekte des Anlagenbaus in einem physikalischen Produktmodell abbildet.
-
Vor
diesem Hintergrund ist es sinnvoll, bei einer komplexen, modular
strukturierten technischen Einrichtung die zugeordnete Information
im Hinblick auf eine jede konkrete Konfigu ration der Einrichtung
dynamisch, d.h. automatisiert, aus einer Informationsbibliothek
auszuwählen,
in welcher ein alle Konfigurationen abdeckender Informationsbestand
hinterlegt ist. Hierbei stellt sich jedoch das Problem, dass die
einer komplexen Einrichtung zuzuordnende Informationsbibliothek
häufig
derart umfangreich ist, dass sie kaum mehr zu überblicken oder zu kontrollieren
ist. Hierzu trägt
insbesondere auch bei, dass infolge der modularen Strukturierung
der Einrichtung oft eine Vielzahl unterschiedlicher Experten jeweils
Information zu einem Teilbereich der Einrichtung erstellt und in
die Informationsbibliothek einbringt. Gegebenenfalls vorhandene
Fehler oder Lücken
innerhalb der Informationsbibliothek werden daher unter Umständen nicht
oder erst sehr spät
erkannt.
-
Der
Erfindung liegt die Aufgabe zugrunde, ein Verfahren der betreffenden
Art anzugeben, welches die Erstellung und Handhabung einer Informationsbibliothek,
die einer modular strukturierten Einrichtung zugeordnet ist, vereinfacht.
-
Diese
Aufgabe wird erfindungsgemäß gelöst durch
die Merkmale des Anspruchs 1. Danach ist vorgesehen, die Informationsbibliothek
derart zu strukturieren, dass sie eine Anzahl von Informationspaketen
umfasst, deren jedes einen Informationskern und eine Meta-Angabe
enthält.
Der Informationskern enthält
dabei die eigentliche Information, z.B. eine technische Dokumentation
zu einem oder mehreren Modulen der Einrichtung. Diese Zugehörigkeit
des Informationspakets zu einem oder mehreren Modulen wird durch
die Meta-Angabe definiert.
-
Weiterhin
ist die Vorgabe einer Kontextbibliothek vorgesehen, die eine Anzahl
von Kontexteinheiten umfasst. Jede Kontexteinheit enthält dabei
einen Verweis auf eine Kombination von Modulen, für welche
das Vorhandensein eines Informationspakets erforderlich ist. Der
abstrakte Begriff „Kombination" ist hierbei im Sinne
von „ein
einzelnes Modul oder mehrere in Kombination" zu verstehen. Der Verweis kann dementsprechend auch
auf ein einzelnes Modul zeigen.
-
Nach
dem erfindungsgemäßen Verfahren
wird nun getestet, ob für
eine jede gültige
Konfiguration von Modulen und für
jede von dieser Konfiguration betroffene Kontexteinheit ein und
nur ein korrespondierendes Informationspaket vorhanden ist.
-
Eine
Kontexteinheit ist dann von einer Konfiguration „betroffen", wenn sie auf eine in dieser Konfiguration
enthaltene Kombination von Modulen verweist.
-
Ein
Informationspaket „korrespondiert" dann mit einer Kontexteinheit
in Hinblick auf eine Konfiguration, wenn es anhand seiner Meta-Angabe
als kompatibel mit der Konfiguration und als zugehörig zu der
durch die Kontexteinheit ausgewiesene Kombination von Modulen definiert
ist.
-
Weiterhin
ist ein Informationspaket dann „einer Kombination von Modulen
zugehörig", wenn es jedem einzelnen
Modul der Kombination zugehörig
ist. Ein Informationspaket ist dann mit einer gegebenen Konfiguration „kompatibel", wenn es nicht zu
einem oder mehreren Modulen dieser Konfiguration explizit nicht
zugehörig
ist. Die Kompatibilität
oder Inkompatibilität
kann sich dabei auch aus der Konfigurationsstruktur ergeben. Ist
beispielsweise ein Informationspaket einem Modul „System_001" als zugehörig definiert,
welches gemäß der Konfigurationsstruktur
nur alternativ zu einem weiteren Modul „System_002" auszuwählen ist,
so ist das Informationspaket diesem weiteren Modul explizit nicht
zugehörig
und damit inkompatibel mit allen Konfigurationen, die das Modul „System_002" enthalten.
-
Ist
innerhalb einer jeden gültigen
Konfiguration für
jede betroffene Kontexteinheit ein korrespondierendes Informationspaket
vorhanden, so wird die Informationsbibliothek als „vollständig" erkannt. Im Umkehrschluss
ist die Informationsbibliothek „unvollständig", wenn bei einer gültigen Konfiguration zu mindestens einer
betroffenen Kontexteinheit kein korrespondierendes Informationspaket
existiert.
-
Ist
innerhalb einer jeden gültigen
Konfiguration für
jede betroffene Kontexteinheit nur ein korrespondierendes Informationspaket
vorhanden, so wird die Informationsbibliothek als „konsistent" erkannt. Im Umkehrschluss
ist die Informationsbibliothek „inkonsistent", wenn bei einer
gültigen
Konfiguration zu mindestens einer betroffenen Kontexteinheit mindestens
zwei korrespondierende, und damit konkurrierende Informationspakete
existieren.
-
Durch
das erfindungsgemäße Verfahren
ist eine dezentrale und modulbezogene Erstellung einer Informationsbibliothek
durch eine Vielzahl unterschiedlicher Bearbeiter ermöglicht,
ohne dass eine Unvollständigkeit
oder Inkonsistenz der Informationsbibliothek befürchtet werden müsste. So
erlaubt das Verfahren, dass – beispielsweise
durch eine zentrale Projektleitung – mit Hilfe der Kontextbibliothek
eine Anzahl von Situationen definiert werden kann, in welchen ein
Informationspaket vorhanden sein muss. Es wird somit eine Grobstruktur
oder ein Inhaltsverzeichnis der Informationsbibliothek vorgegeben.
Die Erstellung der einzelnen Informationspakete kann davon aber
völlig
unabhängig,
insbesondere durch die für
die Einzelbereiche der Einrichtung zuständigen Experten erfolgen. Insbesondere
kann die Zugehörigkeit
eines jeden Informationspakets zu Modulen der Einrichtung individuell
und unabhängig
von der durch die Kontexteinheiten vorgegebenen Richtlinie definiert
werden. Auf diese Weise ist es möglich,
ein gemein sames Informationspaket für mehrere Kontexteinheiten
zu erzeugen und hierdurch die Erstellung redundanter Information
zu vermeiden. Andererseits ist es aber auch möglich, mehrere Informationspakete
im Hinblick auf dieselbe Kontexteinheit zu erstellen, wobei jedes
dieser Informationspakete für
verschiedene Konfigurationen der Einrichtung relevant ist. Auf diese Weise
können
konfigurationsabhängige
Unterschiede innerhalb desselben Kontextes differenziert ausgeführt werden.
-
Infolge
der vorteilhaften Prüfung
auf Vollständigkeit
und Konsistenz, die bevorzugt automatisiert abläuft, ist dabei auf effektive
Weise sichergestellt, dass die durch die Kontextbibliothek vorgegebenen
Richtlinien eindeutig erfüllt
sind und somit Fehler oder Lücken
der Informationsbibliothek vermieden sind.
-
Zusammengefasst
wird durch das Fehlen einer direkten Abhängigkeit der Informationsbibliothek
von der Kontextbibliothek und die Vollständigkeits- und Konsistenzprüfung auf
effektive Weise ermöglicht,
die Informationsbibliothek so einfach wie möglich, aber dabei so differenziert
wie nötig
zu strukturieren, so dass der Arbeitsaufwand zur Erstellung der
Information erheblich reduziert werden kann. Hierzu trägt auch
bei, dass jeder Bearbeiter dank der automatischen Vollständigkeits-
und Konsistenzprüfung
eines Informationspakets selbstständig die Zugehörigkeit
des Pakets festlegen kann, ohne das Gesamtkonzept der Informationsbibliothek
zu gefährden.
Eine dem Bearbeitungsvorgang vorausgehende Absprache der Bearbeiter,
die mit wachsender Komplexität
der Informationsbibliothek und zunehmender Anzahl von Bearbeitern
zunehmend schwieriger würde,
ist nicht erforderlich. Ebenso können
die Kontextbibliothek oder einzelne Kontexteinheiten jederzeit geändert werden,
ohne dass hierdurch eine Neustruktierung der bestehenden Informationsbibliothek
erforderlich würde.
-
Um
die Fehlerbehebung bei Unvollständigkeit
der Informationsbibliothek zu erleichtern, wird bei Feststellung
der Unvoll ständigkeit
der oder jeder Kontext, für
welchen kein korrespondierendes Informationspaket vorhanden ist,
angezeigt. Dies kann durch Anzeige der entsprechenden Kontexteinheit
oder äquivalenterweise durch
Anzeige der durch diese ausgewiesene Kombination von Modulen, bevorzugt
zusammen mit der Anzeige der entsprechenden Konfiguration erfolgen.
-
Ebenso
werden bevorzugt, wenn die Inkonsistenz der Informationsbibliothek
festgestellt wurde, diejenigen Informationspakete angezeigt, die
im Hinblick auf eine Konfiguration und eine betroffene Kombination konkurrieren.
-
Besonders
vorteilhaft im Hinblick auf eine einfache Verfahrensdurchführung ist
die Hinterlegung sowohl der Konfigurationsstruktur, der Informationsbibliothek
und der Kontextbibliothek in Form von Textdateien, die im XML(eXtensible
Markup Language)-Format vorliegen.
-
Bevorzugt
ist die Konfigurationsstruktur in Form einer Baumstruktur hinterlegt,
an deren Knoten- oder Verzweigungspunkten jeweils ein Modul angeordnet
ist. Als Baumstruktur wird ein hierarchisch geordnetes Beziehungs-
und Abhängigkeitsgeflecht
mit einem oder mehreren „Wurzel"-Modulen in einer
obersten Hierarchieebene verstanden. Zu jedem dieser „Wurzel"-Module stehen dabei
ein oder mehrere Module einer nach- oder untergeordneten Hierarchieebene
in Beziehung, von welchen gegebenenfalls wiederum Module einer weiteren
nachgeordnten Hierarchieebene in Beziehung stehen, etc.
-
Im
Hinblick auf die Verfahrensdurchführung hat es sich als vorteilhaft
erwiesen, die Module der Einrichtung in „Typ"-Module und „Varianten"-Module zu gliedern. Ein „Typ"-Modul (oder: type
node) spezifiziert dabei eine bestimmte Art von Modulen, z.B. „Behandlungstisch". Ein „Varianten"-Modul (oder: item
node) spezifiziert eine konkrete Variante oder Ausführung eines „Typ"-Moduls, z.B. eine
konkrete Bauform des Behandlungstisches. Innerhalb der Konfigurationsstruktur
sind aufeinander folgende Hierarchieebenen bevorzugt alternierend
entweder Typ-Modulen oder Varianten-Modulen zugewiesen, wobei einer „Typ"-Hierarchieebene stets
eine „Varianten"-Hierarchieebene
nachgeordnet ist.
-
Die
Aufgliederung der Konfigurationsstruktur in Typ-Module und Varianten-Module
erlaubt insbesondere eine einfache Überprüfung einer vorgegebenen Konfiguration
auf Gültigkeit.
Diese Prüfung
erfolgt zweckmäßigerweise
mittels eines rekursiven Formalismus, bei welchem eine Konfiguration
von Modulen dann als gültig
erkannt wird, wenn innerhalb dieser Konfiguration jedes Typ-Modul
und jedes Varianten-Modul vorgegebene Gültigkeitskriterien erfüllt. Die
Gültigkeitskriterien
für ein
Typ-Modul sind insbesondere
bevorzugt verschieden von den Gültigkeitskriterien
für ein
Varianten-Modul.
-
Als
Gültigkeitskriterien
für ein
Typ-Modul werden vorzugsweise die folgenden Bedingungen geprüft:
T1:
Die Anzahl der dem Typ-Modul (in der zu testenden Konfiguration)
ausgewählten
nachgeordneten Varianten-Module muss innerhalb eines vorgegebenen
Auswahl-Bereichs liegen.
-
Dieser
Auswahl-Bereich ist dabei bevorzugt durch die Konfigurationsstruktur
für jedes
Typ-Modul individuell bestimmt.
T2: Alle ausgewählten, nachgeordneten
Varianten-Module müssen
vorgegebene Gültigkeitskriterien
für Varianten-Module,
insbesondere die nachfolgend eingeführten Kriterien I1 bis I3,
erfüllen.
T3:
Die Konfiguration darf als Variante des betrachteten Typ-Moduls
keine Varianten-Module umfassen, für welche diese Nachordnung
nicht explizit durch die Konfigurationsstruktur zugelassen ist.
-
Für ein Varianten-Modul
werden vorzugsweise die folgenden Gültigkeitskriterien herangezogen:
I1:
Alle nachgeordneten Typ-Module müssen
vorgegebene Gültigkeitskriterien
für Typ-Module,
insbesondere T1 bis T3, erfüllen.
I2:
Alle dem betrachteten Varianten-Modul zugeordneten Bedingungen müssen erfüllt sein.
-
Unterliegt
also beispielsweise das betrachtete Varianten-Modul der Bedingung,
dass in der Konfiguration ein weiteres Modul enthalten sein muss,
so wird geprüft,
ob dieses Modul in der Konfiguration tatsächlich enthalten ist. Unterliegt
das betrachtete Variantenmodul der Bedingung, das ein weiteres Modul
in derselben Konfiguration nicht vorhanden sein darf, so wird geprüft, ob dieses
Modul in der vorliegenden Konfiguration tatsächlich nicht ausgewählt ist.
I3:
Unreferenzierte Typ-Module und ihre Varianten dürfen in der vorliegenden Konfiguration
nicht verwendet werden.
-
Ein
Typ-Modul wird dabei dann als unreferenziert erkannt, wenn es in
der Konfigurationsstruktur nicht als nachgeordneter (Unter-)Typ
des betrachteten Varianten-Moduls erscheint.
-
Nachfolgend
wird ein Ausführungsbeispiel
der Erfindung anhand einer Zeichnung näher erläutert. Darin zeigen:
-
1 schematisch
ein Informationssystem mit einer Informationsbibliothek, die einer
Anzahl von Modulen zugeordnet ist, aus welchen entsprechend einer
vorgegebenen Konfigurationsstruktur eine Einrichtung zusammensetzbar
ist, sowie mit einer Kontextbibliothek, in welcher eine Anzahl von
Kombinationen von Modulen angegeben ist, für welche das Vorhandensein
jeweils eines Informationspaketes erforderlich ist,
-
2 in
einem Baumdiagramm eine konkrete Ausführung der Konfigurationsstruktur
gemäß 1,
-
3 auszugsweise
eine XML-Kodierung der Konfigurationsstruktur gemäß 2,
-
4 auszugsweise
eine XML-Kodierung eines Informationspaketes gemäß 1 sowie
eine XML-Kodierung einer Kontexteinheit gemäß 1,
-
5 die
Benutzeroberfläche
eines Editors zum Bearbeiten der Informationsbibliothek sowie zum
Anzeigen eines Vollständigkeits-
oder Konsistenzfehlers und
-
6 die
Benutzeroberfläche
eines weiteren Editors zum Bearbeiten der Meta-Angabe eines Informationspakets
der Informationsbibliothek.
-
Einander
entsprechende Teile und Größen sind
in allen Figuren stets mit den gleichen Bezugszeichen versehen.
-
Das
in 1 schematisch dargestellte Informationssystem 1 umfasst
eine Informationsbibliothek 2 mit einer Vielzahl von einzelnen
Informationspaketen 3, 3'. Jedes Informationspaket 3, 3' umfasst einen
Informationskern 4 sowie eine Meta-Angabe 5. Der
Informationskern 4 beinhaltet hierbei die eigentliche Information des
Informationspakets 3, 3'. Anhand der Meta-Angabe 5 ist
die Zugehörigkeit
des Informationspakets 3, 3' zu einem oder mehreren Modulen
Mi (i = 0, 1, 2, 3, ..., 18) einer technischen Einrichtung 6 definiert.
-
Bei
der Einrichtung 6 handelt es sich insbesondere um einen
Magnetresonanz(MR)-Tomografen. Bei den Modulen Mi handelt es sich
insbesondere um Bestandteile des Tomografen (Hardware und Software)
sowie um Verfahrensabläufe
(Workflows), die im Zuge der Einstellung, Wartung oder Bedienung
des Tomografen vorzunehmen sind. Der Informationskern 4 eines
jeden Informationspakets 3, 3' beinhaltet dabei insbesondere technische
Dokumentation zu einem oder mehreren Modulen Mi, insbesondere also
bezüglich
eines Bestandteils des Tomografen und/oder eines Verfahrensablaufs.
-
Die
Module Mi stehen zueinander in Abhängigkeiten, welche durch eine
so genannte Konfigurationsstruktur 7 wiedergegeben werden.
Die in 1 schematisch und ausschnitthaft dargestellte
Konfigurationsstruktur 7 ist nach Art einer Baumstruktur
aufgebaut und umfasst ein „Wurzel"-Modul M0, das alle
weiteren Module M2–M18
als Untereinheiten umfasst.
-
Jede
beliebige Auswahl von Modulen Mi, durch welche die in der Konfigurationsstruktur 7 enthaltenen Abhängigkeiten
erfüllt
sind, und durch welche somit eine vollständige und funktionstüchtige Einrichtung 6 realisiert
ist, wird als gültige
Konfiguration bezeichnet. Eine die Module M0, M1, M3, M4, M6, M7,
M8, M11, M12 und M14 umfassende Konfiguration KF ist in 1 beispielhaft
optisch hervorgehoben.
-
Das
Informationssystem 1 umfasst weiterhin eine Kontextbibliothek 9 mit
einer Anzahl von Kontexteinheiten 10, 10'. Jede Kontexteinheit 10, 10' enthält einen
Verweis 11 auf eine bestimmte Kombination von Modulen Mi
und spezifiziert damit eine bestimmte Situation, für welche
ein korrespondierendes Informationspaket 3, 3' vorhanden sein
muss.
-
Beispielhaft
ist in 1 angedeutet, dass die Kontexteinheit 10' auf eine Kombination
K der Module M12 und M14 verweist und damit festlegt, dass ein Informationspaket 3, 3' für den Fall,
dass die Module M12 und M14 in einer gültigen Konfiguration KF enthalten
sind, zur Verfügung
stehen muss. Die Kontextbibliothek 9 stellt somit quasi
ein Inhaltsverzeichnis einer Dokumentation der Einrichtung 6 dar,
dessen Abschnitte für jede
gültige
Konfiguration der Einrichtung 6 dynamisch mit dem Inhalt
des Informationskerns 4 des jeweils korrespondierenden
Informationspakets 3, 3' ausgefüllt werden kann.
-
Voraussetzung
hierfür
ist, dass die Informationsbibliothek 2 vollständig und
konsistent ist, dass also für
jede gültige Konfiguration
zu jeder betroffenen Kontexteinheit 10, 10' stets genau
ein Informationspaket 3, 3' korrespondiert.
-
In 2 ist
die Konfigurationsstruktur 7 an einem vereinfachten Beispiel
konkret ausgeführt.
In dieser Darstellung ist insbesondere die hierarchische Ordnung
der Konfigurationsstruktur 7 erkennbar. Weiterhin ist erkennbar,
dass die Module Mi in (mit rechteckigen Rahmen symbolisierte) Typ-Module Mk (k = 0,
3, 6–10) sowie
(mit runden Rahmen symbolisierte) Varianten-Module Ml (l = 1, 2,
4, 15, 11–18)
unterteilt sind. Typ-Module Mk einerseits und Varianten-Module Ml
andererseits sind in sechs aufeinander folgenden Hierarchieebenen
Ej (j = 0, 1, 2, ..., 5) alternierend angeordnet, wobei eine mit
Varianten-Modulen Ml besetzte Hierarchieebene E1, E3, E5 stets einer übergeordneten
Hierarchieebene E0, E2, E4 folgt, in welcher die diesen Varianten-Modulen
Ml jeweils zugeordneten Typ-Module Mk angeordnet sind.
-
Aus 2 geht
hervor, dass innerhalb der Konfigurationsstruktur 7 zwei
alternative Varianten des Typs „System" (Modul M3) existieren, nämlich „Harmony" (Modul M4) und „Concerto" (Modul M5). Die „System"-Variante „Harmony" umfasst drei Subkomponenten
vom Typ „MPCU" (Modul M6) bzw. „Receiver" (Modul M7) bzw. „Rx4" (Modul M8). Der
Typ „Receiver" kann wiederum aus
zwei alternativen Varianten „R-2" (Modul M12) und „R-4" (Modul M13) gewählt werden,
wobei letztere Variante mit einer Bedingung 12 verknüpft ist,
gemäß welcher
bei Auswahl von „R-4" gleichzeitig für den Typ „Rx4" (Modul M8) die zugehörige Variante „X2" (Modul 15)
ausgewählt
sein muss.
-
In 3 ist
eine Textdatei 13 auszugsweise dargestellt, in welcher
die in 2 bildhaft dargestellte Konfigurationsstruktur 7 in
einer dem XML(eXtensible Markup Language)-Standard entsprechenden
Textform kodiert ist. Das Typ-Modul M0 ist hier durch die Textsequenz <Type ...> ... </Type> angegeben, ein nachgeordnetes
Typ-Modul M3, M6–M10
entsprechend durch <SubType
...> ... </SubType>. Ebenso ist ein Varianten- Modul durch die Textsequenz <Item ...> ... </Item> angegeben. Die Identifizierung
eines bestimmten Typ-Moduls Mk oder Varianten-Moduls Ml erfolgt
durch Verweis IDREF = „..." auf einen eindeutigen
Identifikationsnamen des jeweiligen Moduls Mi, z.B. IDREF = „INT_ConsoleType" für das Modul
M0, das gemäß 2 als „Type" bezeichnet ist.
Die Hierarchieebenen E0 bis E5 sind in 3 durch
unterschiedliche Einrückungen gekennzeichnet.
Durch Variablen „MinOccurs" und „MaxOccurs" kann für jedes
Typ-Modul Mk ein Auswahlbereich 14 vorgegeben werden, durch
welchen festgelegt ist, wieviele nachgeordnete Varianten-Module
Ml innerhalb einer gültigen
Konfiguration KF gleichzeitig ausgewählt sein dürfen. Die Textsequenz MinOccurs
= „1" MaxOccurs = „1" in der dem Modul
M0 zugeordneten <Type
...>-Sequenz bedeutet
also, dass in einer gültigen Konfiguration
KF stets mindestens und maximal eines der zugehörigen Varianten-Module M1 („Main") oder M2 („Satellite") ausgewählt sein
müssen
bzw. dürfen.
-
Weitere
Module der Konfigurationsstruktur 7, die Verfahrensabläufe (Workflows)
zum Gegenstand haben, sind in der vereinfachten Darstellung gemäß 2 und 3 lediglich
aus Gründen
der Übersichtlichkeit nicht
abgebildet.
-
In 4 ist
eine weitere Textdatei 15 dargestellt, in welcher auszugsweise
und beispielhaft in XML-Kodierung ein Informationspaket 3 und
eine Kontexteinheit 10 angegeben sind.
-
Das
Informationspaket
3 ist durch die Sequenz <Package ...> ... </Package> begrenzt. Der (nicht
im Detail ausgeführte)
Informationskern
4 des Informationspakets
3 ist
innerhalb der Textsequenz <Content> ... </Content> enthalten. Die Meta-Angabe
5 ist
innerhalb der Textsequenz <Dependencies> ... </Dependencies> enthalten.
-
Das
Informationspaket 3 bezieht sich namens der <RefType ...> bzw. <RefItem ...>-Einträge seiner Meta-Angabe 5 auf
die Variante „Tune
Up" des Typs „Workflow" und die Variante „System_003" des Typs „System". Hiermit ist das
Informationspaket 3 jedem Stadium des Workflows „Tune Up" und allen Konfigurationen des
Systems „System_003" als zugehörig definiert.
-
Die
Kontexteinheit 10 wird durch die Textsequenz <Context> ... </Context> begrenzt und enthält namens
ihrer <RefType
...> bzw. <RefItem ...>-Einträge einen
Verweis 11 auf eine Kombination der Typ-Module „System", „Workflow", „WorkflowMode" und „Workflow
Sfp" und ihre jeweils
zugeordneten Varianten-Module „System_003", „Tune Up", „General" bzw. „SfpTuncalOpen". Hierdurch ist festgelegt,
dass für
den Verfahrensschritt „TuncalOpen" in dem „Tune Up"-Verfahren des Systems „System_003" ein Informationspaket 3 erforderlich
ist.
-
Um
die Informationsbibliothek 2 auf Vollständigkeit und Konsistenz zu
testen, werden die vorstehend definierten Kriterien der Vollständigkeit
und der Konsistenz der Informationsbibliothek 2 nachfolgend
in Abhängigkeit
der Kontextbibliothek 9 und der Konfigurationsstruktur 7 als
Boolésche
Ausdrücke
angegeben, die einen binären
Aussagewert „wahr" oder „falsch" als Resultat zurückgeben.
Diese Ausdrücke
werden im Zuge des Testverfahrens auf ihre Erfüllbarkeit getestet.
-
In
den nachfolgend eingeführten
Gleichungen wird Bezug genommen auf Elemente und Attribute der die
Module Mi, Informationspakete 3, 3' und Kontextelemente 10, 10' beschreibenden
XML-Terme. Zu diesem Zweck wird die in TAB 1 schematisch aufgeführte „XPath"-Nomenklatur verwendet.
Im Hinblick auf diese an sich bekannte Nomenklatur wird auf „Xpath
: XML Path Language 2.0. (2002) W3C Working Draft" verwiesen.
-
-
Gemäß der in
TAB 1 eingeführten
Nomenklatur bezeichnet der absolute Pfad /Config/Structure das Element <Structure> ... </Structure> der Konfigurationsstruktur 7 (siehe 3).
Der Rückbezug
Type/Item/.. gibt das übergeordnete
Element (parent element) zu Type/Item, nämlich Type zurück. Die
beispielhafte Attributauswahl Item@MaxOccurs gibt den Wert des Attributs
MaxOccurs eines <Item
...>-Elements wieder.
In TAB 1 bezeichnet a eine Variable für ein beliebiges XML-Attribut
und p eine Variable für
einen beliebigen Hierarchiepfad.
-
Innerhalb
der in den Textdateien 13 und 15 enthaltenen XML-Terme sind auch die
Identifikationsnamen der Module Mi in den Attributen ID bzw. IDREF
enthalten. Jedes IDREF-Attribut ist dabei ein Verweis auf ein gleichnamiges
ID-Attribut, das für
jedes Typ-Modul Mk und Varianten-Modul Ml außerhalb der Konfigurationsstruktur 7 (d.h.
der /Config/Structure-Umgebung gemäß 3) in einer
separaten XML-Umgebung der Form /Inventory/InvTypes/InvType/InvItem
definiert ist.
-
Im
Zuge des vorliegenden Verfahrens wird dem Identifikationsnamen eines
jeden Moduls Mi selbst die Eigenschaft einer Booléschen
Variablen zugeordnet, die den Wert „wahr" hat, wenn das entsprechende Modul in
einer beliebigen Konfiguration ausgewählt ist, und die den Wert „falsch" annimmt, wenn das
entsprechende Modul Mi in der Konfiguration nicht vorhanden ist.
Entsprechend hat die auf ein beliebiges <Type ...>-, <SubType
...>- oder <Item ...>-Element m (und damit
auf ein beliebiges Modul Mi) bezogene Formel m@ID bzw. m@IDREF den
Wert „wahr" oder „falsch", wenn das entsprechende
Element m (bzw. Modul Mi) in einer Konfiguration vorhanden bzw.
nicht vorhanden ist. Die einem <Type
...>- oder <SubType ...>-Element t zugeordnete Variable t@ID
bzw. t@IDREF ist dabei dann wahr, sobald wenigstens eine Variable
i@ID bzw. i@IDREF eines nachgeordneten <Item ...>-Elements i (i ∈ t/Item) wahr ist, sobald
also wenigstens ein Varianten-Modul Ml des betrachteten Typs ausgewählt ist.
-
Um
die Vollständigkeit
oder Konsistenz der Informationsbibliothek
2 zu testen,
wird zunächst
eine Formel hergeleitet, die angibt, ob eine beliebige Konfiguration
entsprechend der Konfigurationsstruktur
7 gültig ist. Diese
Aussage wird durch den Aussagewert der folgenden Formel
wiedergegeben.
ValidConf (GLG 1) hat den Wert „wahr", wenn eine gegebene Konfiguration gültig ist,
ansonsten den Wert „falsch". Die Ausdrücke TypeDefs
und ValConfT(t) sind dabei gegeben durch
-
Eine
Konfiguration ist nach GLG 1 genau dann gültig, wenn alle <Type ...>-Elemente gesetzt sind
und jedes <Type
...>-Element entsprechend
GLG 3 gültig
ist. Die in GLG 3 enthaltenen Ausdrücke CardinalityOK(t) (GLG 4),
SubItemsValid(t) (GLG 5) und ForbidUnrefItems(t) (GLG 6) entsprechen
den vorstehend genannten Gültigkeitskriterien
T1 bis T3 für
ein Typ-Modul:
-
GLG
4 ist nur dann erfüllt,
wenn die Anzahl der ausgewählten,
dem betrachteten Typ-Modul (d.h. <Type
...>- oder <SubType ...>-Element) nachgeordneten
Varianten-Module (d.h. <Item
...>-Elemente) innerhalb des
durch MinOccurs und MaxOccurs aufgespannten Auswahlbereichs 14 liegt
(zur Wirkung des Operators Sa b(M)
in GLG 4 wird auf den Anhang verwiesen).
-
GLG
5 ist nur dann wahr, wenn alle ausgewählten nachgeordneten Varianten-Module
gemäß GLG 7 gültig sind.
-
GLG
6 testet eine gegebene Konfiguration auf unreferenzierte Varianten-Module
(zu der Definition des Ausdrucks unrefItems(t) wird auf den Anhang
verwiesen).
-
Die
Gültigkeit
eines Varianten-Moduls wird durch den Ausdruck ValConfI(i) = SubTypesValid(i)
^ ConditionValid(i) ^ ForbidUnrefTypes(i) GLG 7bestimmt.
Die Ausdrücke
SubTypesValid(i), ConditionValid(i) und ForbidUnrefTypes(i) entsprechen
wiederum den Gültigkeitskriterien
I1 bzw. I2 bzw. I3. Danach ist ein Varianten-Modul innerhalb der
zu testenden Konfiguration dann gültig, wenn alle diesem Modul
nachgeordneten Typ-Module gültig
sind, alle gegebenenfalls mit dem betrachteten Varianten-Modul verknüpfte Bedingungen
erfüllt
sind und nur nachgeordnete Typ-Module ausgewählt sind,
die in der Konfigurationsstruktur 7 dem betrachteten Varianten-Modul
als Unter-Typen zugeordnet sind.
-
Die
Ausdrücke
SubTypesValid(i), ConditionValid(i) und ForbidUnrefTypes(i) sind
gegeben durch
-
Zu
GLG 8 ist insbesondere zu beachten, dass hier wiederum auf den in
GLG 3 definierten Ausdruck ValidConfT(t) Rückbezug genommen wird. Im Gegensatz
zu GLG 1 wird in GLG 8 aber ein <SubType
...>-Element, d.h.
ein nachgeordnetes Typ-Modul, als Argument übergeben, dessen Gültigkeit
wiederum anhand der Kriterien T1 bis T3 getestet wird.
-
Zwischen
den GLG 3 und 7 ist somit ein geschlossener Kreisbezug gebildet,
aufgrund dessen die Gültigkeit
der Konfigurationsstruktur 7 rekursiv bis in die unterste
Hierarchieebene getestet wird.
-
GLG
9 ist trivialerweise wahr (= T), wenn keine Bedingung besteht. Ansonsten
ist GLG 9 erfüllt,
wenn alle Bedingungen erfüllt
sind. Zu der Definition der Funktion DecodeOp(d) wird ebenso wie
im Hinblick auf die in GLG 10 enthaltene Funktion unrefTypes(i)
auf den Anhang verwiesen.
-
Für den Zugriff
auf Informationspakete
3,
3' werden die folgenden drei Grundfunktionen
verwendet:
-
In
den GLG 11 bis 13 stehen p für
ein beliebiges Informationspaket 3, 3' und c für eine beliebige
Kontexteinheit 10, 10'.
-
HelpReq(c)
(GLG 11) definiert, ob eine gegebene Kontexteinheit c für eine beliebige
Konfiguration das Vorhandensein eines Informationspakets 3, 3' erfordert,
während
HelpProv(p) die Situationen bestimmt, mit welchen ein gegebenes
Informationspaket p korrespondiert.
-
Die
Vollständigkeit
der Informationsbibliothek
2 ist nun äquivalent mit der Allgemeingültigkeit
des Ausdrucks
erfüllbar ist.
Dementsprechend ist die Informationsbibliothek
2 konsistent,
wenn GLG 15 für
alle Informationspakete p1 ≠ p2
unerfüllbar
ist.
-
Im
Zuge des Testverfahrens werden aus der XML-Kodierung der Informationsbibliothek 2,
der Kontextbibliothek 9 und der Konfigurationsstruktur 7 die
GLG 14 und 15 entwickelt und auf ihre Erfüllbarkeit getestet. Im Falle
von GLG 14 wird dabei die Erfüllbarkeit
der Negation getestet.
-
Ein
großer
Vorteil dieses Verfahrens besteht darin, dass nicht für jede einzelne
mögliche
Konfiguration und jede betroffenen Kontexteinheit die Vollständigkeit
und Konsistenz der Informationsbibliothek separat geprüft werden
muss. Vielmehr wird die Erfüllbarkeit
der Booéschen
Ausdrücke
gemäß GLG 14
und 15 unter Verwendung gängiger
Methoden der propositionalen Logik, insbesondere SAT, rechnergestützt mit
wesentlich rationalisiertem Rechenaufwand überprüft.
-
Im
Fehlerfall (d.h. bei Unvollständigkeit
oder Inkonsistenz) wird eine Formel erzeugt, die einen Satz von
Situationen, in welchen der Fehler auftritt, beschreibt. Diese Formel
wird unter Verwendung an sich bekannter BDD-Methoden vereinfacht.
-
Bei
einem Vollständigkeitsfehler
wird der oder jeder Kontext, zu welchem ein erforderliches Hilfspaket 3 nicht
existiert, gegebenenfalls zusammen mit der relevanten Konfiguration
angezeigt. Bei einem Konsistenzfehler werden insbesondere die überlappenden
Informationspakete 3, bevorzugt zusammen mit dem relevanten
Kontext, angezeigt.
-
Diese
Anzeige erfolgt bevorzugt mittels eines im Hinblick auf die Erstellung
und Wartung des Informationssystems 1 spezialisierten Editors 16,
dessen Benutzeroberfläche
in 5 dargestellt ist.
-
Der
Editor 16 umfasst ein erstes Anzeigefeld 17 zur
Anzeige der Struktur der Informationsbibliothek 2 und der
darin enthaltenen Informationspakete 3. Der Editor 16 umfasst
weiterhin ein zweites Anzeigefeld 18, in welchem die Meta-Angabe 5 eines
ausgewählten
Informationspakets 3' angezeigt
wird. Der Editor 16 umfasst des Weiteren Funktionselemente 19 zum
Bearbeiten oder Erstellen eines Informationspaketes 3 sowie Funktionselemente 20 und 21 zum
Bearbeiten der Meta-Angabe 5 eines Informationspaketes 3' bzw. zum Starten
des beschriebenen Vollständigkeits-
und Konsistenztests.
-
Wird
ein Konsistenzfehler festgestellt, so werden die überlappenden
Informationspakete 3 in dem Anzeigefeld 17 entsprechend
farblich gekennzeichnet.
-
Zum
Bearbeiten der Meta-Angabe 5 eines Informationspaketes 3` dient
ein in 6 dargestellter weiterer Editor 23. Dieser
Editor 23 umfasst ein erstes Anzeigefeld 24, in
welchem die aktuelle Meta-Angabe 5 angezeigt ist. Um eine
einfache und wenig fehleranfällige
Bearbeitung der Meta-Angabe 5 zu ermöglichen, umfasst der Editor 23 ein
weiteres Anzeigefeld 25. In diesem weiteren Anzeigefeld 25 sind
die Module Mi der Einrichtung 6 aufgelistet. Diese aufgelisteten
Module Mi können,
z.B. per Mausklick, ausgewählt
und in die Meta-Angabe 5 des Informationspakets 3' aufgenommen
werden. Ebenso können
vor handene Zugehörigkeiten zu
Modulen Mi aus der aktuellen Meta-Angabe 5 des Informationspakets 3' entfernt werden.
-
