DE69900993T2

DE69900993T2 - Modulenkompatibilitätsüberprüfung

Info

Publication number: DE69900993T2
Application number: DE69900993T
Authority: DE
Inventors: P. Mayhead; J. Williams
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1998-06-15
Filing date: 1999-06-09
Publication date: 2002-09-12
Anticipated expiration: 2019-06-10
Also published as: EP1088274A1; WO1999066409A1; ATE214174T1; US6216186B1; JP2002518741A; DE69900993D1; EP1088274B1

Description

TECHNISCHER HINTERGRUND DER ERFINDUNG

Die Erfindung betrifft Computersysteme, die steckbare Module aufweisen, und betrifft solche steckbaren Module.
Computersysteme beinhalten typischerweise eine Anzahl von steckbaren Modulen, das sind Module oder Komponenten, die in ein System eingesteckt werden können, um eine bestimmte Funktionalität zur Verfügung zu stellen. Die Verwendung von einsteckbaren Modulen ist bequem, um eine flexible Konfiguration zur Verfügung zu stellen und für langfristige Reparaturanforderungen.
Insbesondere, jedoch nicht ausschließlich, in zuverlässigen Systemen ist es wichtig, in der Lage zu sein, festzustellen, daß die tatsächlich eingesteckten Module kompatibel sind. Hiermit ist gemeint, daß ein Modul, das in ein modulares System eingesetzt werden kann, getestet werden muß, bevor es völlig in das System integriert wird und bevor sich das System auf dieses Modul verläßt. Das Testen wird typischerweise durchgeführt, nachdem das Modul physikalisch in das System eingesetzt worden ist, jedoch bevor das Modul funktional völlig integriert wird. Das Modul kann ein Hardware- oder ein Softwaremodul sein.
Die europäische Patentanmeldung EP-A-0 793 169 beschreibt ein Identifizierungsinterface, das Steuerinformation zwischen einem Controller und einem Optionsmodul, das mit einem Motherboard eines Computers verbunden ist, überträgt. Das Identifizierungsinterface unterstützt die Verbreitung einer Mehrzahl von Bitfeldern, die Informationen enthalten, die zu den Charakteristika des Optionsmoduls gehören, einschließlich, jedoch nicht hierauf begrenzt, seiner Geschwindigkeit, seines Typs und anderen Informationen über seine Charakteristika.
Im Laufe der Jahre können sich die Fähigkeiten eines Moduls ändern, wenn verschiedene Versionen veröffentlicht werden. Beispielsweise kann ein Plattenmodul ursprünglich aus zwei 1 - GByte-Laufwerken bestehen. Später kann es mit einem 2-GByte-Laufwerk hergestellt sein. Diese Veränderung kann in manchen Systemen ohne Konsequenz sein, kann jedoch in anderen wichtig sein.
Wenn Module von unterschiedlichen Herstellungsdaten in dem Feld bzw. Gebiet gemischt werden, könnten Informationen über manche Fähigkeiten gebraucht werden, selbst wenn an diese Fähigkeiten nicht gedacht wurde, als ein Modul gebaut wurde.
Ein Ziel der vorliegenden Erfindung ist es, das Problem des Zurverfügungstellens von Informationen über Kompatibilitätsergebnisse zwischen wechselwirkenden Modulen und des Abbauens solcher Kompatibilitätsereignisse zwischen wechselwirkenden Modulen anzusprechen.

ZUSAMMENFASSUNG DER ERFINDUNG

In Übereinstimmung mit einem Aspekt der Erfindung, der im Detail im angefügten Anspruch 1 definiert ist, wird ein Modul für ein modulares System zur Verfügung gestellt, wobei das Modul mit einem Bauteil bzw. einer Komponente des modularen Systems verbindbar ist und aufweist: Erfordernisanzeigen, welche Eigenschaften des Bauteils definieren, die erforderlich sind, damit das Modul arbeitet; Fähigkeitsanzeigen, welche Merkmale definieren, die von dem Modul bereitgestellt werden; und Handhabbarkeitsanzeigen, welche Merkmale des Bauteils definieren, die für das Modul akzeptabel sind.
Ein Handhabbarkeitsanzeiger definiert effektiv das Können, korrespondierende Fähigkeiten zu akzeptieren. Es versteht sich, daß die oben erwähnten Fähigkeiten als primäre bzw. erste Fähigkeiten bezeichnet werden könnten und die Handhabbarkeitsfähigkeiten als sekundäre bzw. zweite Fähigkeiten bezeichnet werden könnten. Es versteht sich, daß diese alternativen Bezeichnungen äquivalent wären.
Die Kombination der Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeigen liefert eine sehr flexible Struktur für die Anzeige und Testanforderungen, Fähigkeiten und Handhabbarkeitsfähigkeiten derart, daß es die Bestimmung von Anforderungen, Fähigkeiten und das Können, korrespondierende Fähigkeiten zu akzeptieren, erlaubt. Dies ermöglicht effektiv logische Verbindungen zwischen einzelnen Anforderungen und Fähigkeiten, die ausgedrückt und untersucht werden sollen.
In einem modularen System enthalten die zusammengeschalteten Module jeweils einen geeigneten Satz von Anzeigern und eine Kompatibilitätsüberprüfungslogik wird für die Bewertung der Verbindungen zwischen den Erfordernis-, den Fähigkeits- und den Handhabbarkeitsanzeigern zur Verfügung gestellt.
In Übereinstimmung mit einem anderen Aspekt der Erfindung wird ein Verfahren für das Überprüfen der Kompatibilität zwischen zumindest zwei Systemkomponenten zur Verfügung gestellt, wie im Detail im angefügten Anspruch 23 definiert ist.
Die Anzahl der Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeiger kann vorzugsweise von Modul zu Modul variieren. Dies ist von Wert, wenn ein neues Erfordernis, nachdem eine erste Version eines Moduls ausgeliefert wurde, entwickelt wurde. In späteren Modulen kann daher ein anderer Satz von Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeigern zur Verfügung gestellt werden, ohne daß die Funktion des Berechenbarkeits-Schlüsselsystems beeinträchtigt wird. Ein Längenanzeiger kann zur Verfügung gestellt werden, der repräsentativ für die Anzahl von zumindest einem der Erfordernisanzeiger, der Fähigkeitsanzeiger oder der Handhabbarkeitsanzeiger ist.
In einer Ausführungsform kann das Modul eine Erfordernisspezifikation beinhalten, die einen Erfordernisspezifikationslängenanzeiger und eine Anzahl von Erfordernisanzeigern beinhaltet, wobei der Erfordernisspezifikationslängenanzeiger repräsentativ für die Anzahl von Erfordernisanzeigern ist. In gleicher Weise kann eine Fähigkeitsspezifikation zur Verfügung gestellt werden, die einen Fähigkeitsspezifikationslängenanzeiger und eine Anzahl von Fähigkeitsanzeigern beinhaltet, wobei der Fähigkeitsspezifikationslängenanzeiger repräsentativ für die Anzahl von Fähigkeitsanzeigern ist. Ebenso kann eine Handhabbarkeitsspezifikation zur Verfügung gestellt werden, die einen Handhabbarkeitsspezifikationslängenanzeiger und eine Anzahl von Handhabbarkeitsanzeigern, wobei der Handhabbarkeitsspezifikationslängenanzeiger repräsentativ für die Anzahl von Handhabbarkeitsanzeigern ist.
Ablage bzw. Speicherung kann in dem Modul zur Verfügung gestellt werden je Erfordernisstruktur, Fähigkeitsstruktur und Handhabbarkeitsstruktur. Jeder der Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeiger kann durch ein Bit gebildet werden, um den benötigten Speicherplatz zu minimieren.
Ein Modultypanzeiger kann ebenso zur Verfügung gestellt werden, wobei die Bedeutung der entsprechenden Anzeiger von Modultyp zu Modultyp variieren kann, wie von dem Modultypanzeiger angezeigt wird.
Das Modul kann ein Bauteilmodul sein, das mit einer Komponente eines Systems verbindbar ist, z. B. ein Modul, das in ein Bauteil einsteckbar ist. Das Bauteil bzw. die Komponente kann ein Systembauteilmodul sein. Alternativ dazu kann das Modul eine Systemkomponente, wie z. B. ein Motherboard, für das Aufnehmen von einsteckbaren Modulen sein. Des weiteren könnte das Modul mit einer Komponente über eine Schnittstelle verbunden sein, die nicht selbst modular ist, das heißt eine Komponente, die nicht von einem System entfernt werden könnte und ersetzt werden, möglicherweise da sie ein fundamentales Systemframework bildet.
Das Modul kann Kompatibilitätsüberprüfungslogik aufweisen für das Überprüfen der Kompatibilität zwischen dem Modul selbst und einer Systemkomponente. In diesem Fall kann das Modul betrieben werden, um die folgenden Verbindungen zu bewerten und die Kompatibilität festzustellen, wenn alle der folgenden Verknüpfungen erfüllt sind:
MR UND SC = MR;
MA UND SC = SC;
SR UND MC = SR; und
SA UND MC = MC,
wobei UND ein logischer UND-Operator ist, MR und SR die Erfordernisanzeiger für das Modul bzw. die Systemkomponente sind, MC und SC die Fähigkeitsindikatoren für das Modul bzw. die Systemkomponente bilden, und MA und SA die Handhabbarkeitsindikatoren für das Modul bzw. die Systemkomponente bilden.
Die Überprüfungslogik kann jedoch in der Komponente zur Verfügung gestellt werden, in der das Modul eingesteckt ist oder sogar in einem getrennten Mittel, beispielsweise einem Prozessor, der nicht Teil des Moduls oder der Komponente ist.
Wo eine variable Anzahl von Erfordernisanzeigern zur Verfügung gestellt wird, wird angenommen, daß es keine nicht spezifizierten Erfordernisse gibt. In gleicher Weise wird angenommen, wo eine variable Anzahl von Fähigkeitsanzeigern zur Verfügung gestellt wird, daß es keine nicht spezifizierten Fähigkeiten gibt. Wo eine variable Anzahl von Handhabbarkeitsindikatoren zur Verfügung gestellt wird, wird angenommen, daß es normalerweise nicht spezifizierte Handhabbarkeitsfähigkeiten gibt. Nicht spezifizierte Handhabbarkeitsfähigkeiten können jedoch wahlweise als vorhanden oder als nicht vorhanden angenommen werden, abhängig von den Anwendungserfordernissen.
In Übereinstimmung mit einem anderen Aspekt der Erfindung wird ein Computersystem zur Verfügung gestellt, das aufweist:
Eine Systemkomponente, die Systemerfordernisanzeiger, die Merkmale definieren, welche für die Systemkomponente erforderlich sind, Systemfähigkeitsindikatoren, die Fähigkeiten definieren, die von der Systemkomponente zur Verfügung gestellt werden, und Systemhandhabbarkeitsindikatoren, die Merkmale des Moduls definieren, die für die Systemkomponente akzeptabel sind, aufweist,
ein Modul, das Modulerfordernisindikatoren, welche Merkmale eines Systembauteils definieren, die für das Modul erforderlich sind, Modulfähigkeitsindikatoren, die Eigenschaften definieren, die von dem Modul zur Verfügung gestellt werden und Modulhandhabbarkeitsindikatoren aufweist, die Merkmale der Systemkomponente definieren, die für das Modul akzeptabel sind, aufweist, und
eine Kompatibilitätsauswertelogik für das Auswerten der folgenden Beziehungen und für das Feststellen der Kompatibilität, wenn alle der folgenden Beziehungen erfüllt sind:
MR UND SC = MR;
MA UND SC = SC;
SR UND MC = SR; und
SA UND MC = MC.
In Übereinstimmung mit einem weiteren Aspekt der Erfindung wird ein Verfahren zum Überprüfen der Kompatibilität zwischen einem Modul und einer Komponente zur Verfügung gestellt, wobei jedes Modul aufweist Erfordernisanzeiger, die Merkmale einer Komponente definieren, die für die Funktion des Moduls erforderlich sind, Fähigkeitsanzeiger, die Eigenschaften definieren, die von dem Modul zur Verfügung gestellt werden, und Handhabbarkeitsanzeiger, die Merkmale der Komponente definieren, die für das Modul akzeptabel sind, wobei das Verfahren umfaßt:
Bestimmen der folgenden Beziehungen:
MR UND SC = MR;
MA UND SC = SC
SR UND MC = SR; und
SA UND MC = MC und
Feststellen der Kompatibilität, wenn die Beziehungen erfüllt sind.

KURZE BESCHREIBUNG DER FIGUREN

Beispielhafte Ausführungsformen der vorliegenden Erfindung werden im folgenden beispielhaft unter Bezug auf die begleitenden Zeichnungen beschreiben, in denen gleiche Bezugszeichen zu gleichen Elementen gehören und in denen:
Fig. 1 ein Schaubild einer mechanischen Schlüsselanordnung des Standes der Technik ist;
Fig. 2 ein schematisches Blockdiagramm von verschiedenen miteinander verbundenen Modulen ist;
Fig. 3 eine schematische Darstellung eines Registers von Fig. 3 ist;
Fig. 4 eine schematische Darstellung der Wechselwirkung zwischen der Steuerlogik und den Registern für die Module von Fig. 2 ist;
Fig. 5 ein Flußdiagramm ist, das die Funktion der Steuerlogik von Fig. 3 darstellt, und
Fig. 6 ein schematischer Überblick über ein fehlertolerantes Computersystem ist.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN

Fig. 1 ist eine schematische Darstellung einer mechanischen Schlüsselanordnung, die die Kompatibilität zwischen einer Karte 10 und einem Motherboard 12 demonstrieren könnte. Die Karte 10 ist an einer vorbestimmten Position mit einer Kerbe bzw. einem Loch 14 ausgestattet, die dafür vorgesehen ist, anzuzeigen, daß sie eine 5 V-Zuführung benötigt. Das Motherboard 12 kann mit einem Zinken 16 an einer äquivalenten Position ausgestattet sein, der anzeigt, daß es eine 5 V- Zuführung zur Verfügung stellt. Die Übereinstimmung des Zinkens und der Kerbe, wenn die Karte eingefügt wird, stellt die Kompatibilität zwischen der Karte und dem Motherboard sicher. Wenn der Zinken an einem unterschiedlichen Platz auf dem Motherboard wäre (z. B. indem er anzeigt, daß das Motherboard eine 10 V-Zuführung zur Verfügung stellt), würde der Zinken nicht auf eine entsprechende Kerbe treffen und die Karte könnte nicht eingesetzt werden. Wenn kein Zinken auf dem Motherboard zur Verfügung gestellt wird, könnte die Karte eingesetzt werden, sie könnte jedoch oder sie könnte nicht die Zuführung erhalten, die sie benötigt. Es versteht sich, daß, obgleich die physikalische Anordnung, die in Fig. 1 gezeigt ist, eine gewisse Information über die Kompatibilität zur Verfügung stellt, diese sehr begrenzt in der Informationsmenge ist, die sie liefern kann, und keinen Vorrat für zukünftige Erfordernisse zur Verfügung stellt, die nach der Herstellung der Karte und/oder des Motherboards auftreten können.
Eine Ausführungsform der vorliegenden Erfindung trachtet danach, einen flexibleren Ansatz für die Bestimmung der Kompatibilitätsanforderungen zur Verfügung zu stellen.
Bevor eine Ausführungsform der Erfindung im Detail beschrieben wird, folgt eine Beschreibung von Problemen, die von Ausführungsformen der Erfindung angesprochen werden und eine allgemeine Beschreibung der Art und Weise, in der verschiedene Ausführungsformen der Erfindung diese Probleme lösen. Es versteht sich, daß eine Ausführungsform der Erfindung nicht alle der erörterten Probleme lösen muß. Ausführungsformen mit variierenden optionalen Merkmalen können verschiedene Kombinationen der diskutierten Probleme lösen.
Auf einem allgemeinen Niveau betrachte man die Situation, in der ein eingestecktes Modul einen gegebenen Satz von Erfordernissen und Fähigkeiten hat. Beispielsweise "ich brauche eine - 12 V-Leistungsquelle" ist ein Erfordernis und "ich kann mit einem 32-Bit-Bus zusammenarbeiten" ist eine Fähigkeit. Das System, in dem das Modul eingesteckt ist, hat eine ähnliche Liste, wie z. B. "ich stelle eine -12 V-Stromzuführung zur Verfügung" und "ich benötige ein Modul, das mit einem 32-Bit- Bus arbeiten kann".
Es muß zu der Zeit, wenn ein Modul eingesteckt wird, bestimmt werden, daß die Erfordernisse von jedem zusammenpassenden Teil von den Fähigkeiten des anderen zusammenpassenden Teils unterstützt wird.
Es kann vorkommen, daß ein eingesetztes Modul viele Fähigkeiten unterstützt, die nicht von dem System erfordert werden. Ein Modul könnte die Fähigkeit haben "ich kann mit einem 64-Bit-Eus zusammenarbeiten". Wenn das System nicht das Erfordernis hat "ich benötige ein Modul, das mit einem 64-Bit-Bus zusammenarbeiten kann", macht dies nichts. Wenn es jedoch eine Auswahl gibt, wie z. B. "ich kann mit einem 64-Bit-Bus zusammenarbeiten" und "ich kann mit einem 32-Bit-Bus zusammenarbeiten", dann könnte es wünschenswert sein, eine Entscheidung zu treffen hinsichtlich der optimalen Verwendung der gemeinsam unterstützten Merkmale.
Eine Ausführungsform der vorliegenden Erfindung spricht diesen Punkt an. Ein Modul, das einen Satz von Daten zur Verfügung stellt, die mit einem eingesteckten Modul verknüpft sind, und sowohl die Erfordernisse des Moduls als auch seine Fähigkeiten spezifizieren. Ein System, in das das Modul eingesteckt ist, stellt ebenso einen Datensatz zur Verfügung, der seine eigenen Fähigkeiten und Erfordernisse spezifiziert. Ein Mechanismus wird zur Verfügung gestellt, um Kompatibilität sicherzustellen durch Überprüfen, daß jedes Erfordernis von jedem Teil von der äquivalenten Fähigkeit des anderen Teils unterstützt wird.
In einer Ausführungsform sind zwei Listen mit jedem Modul verknüpft, eine Liste mit Erfordernisse und eine Liste mit Fähigkeiten. Ein Softwaremechanismus kann wiederum auf jedes Erfordernis eines Moduls achten, mittels Durchlaufen seiner Erfordernisliste, und Bestätigen, daß die äquivalente Fähigkeit irgendwo in der Fähigkeitsliste des anderen Moduls vorhanden ist. Dies stellt einen vielseitigen Ansatz zur Verfügung, der jedoch signifikante Speicheranfragen auf dem Modul und dem System verursachen kann.
In einer anderen Ausführungsform wird die Kompatibilitätsüberprüfung erreicht unter Verwendung von vorbestimmten Bitpositionen in einer Datenstruktur. Jedes Modul hat eine Fähigkeitsdatenstruktur und eine Erfordernisdatenstruktur. Jedem Bit in der Erfordernisdatenstruktur wird eine Bedeutung zugewiesen, wie z. B. "ich benötige eine 5V-Zuführung". Um zu spezifizieren, daß ein bestimmtes Erfordernis WAHR ist, ist dieses Bit in der Erfordernisdatenstruktur für dieses Modul gesetzt. Dasselbe Bit in der Fähigkeitsstruktur hat die äquivalente Bedeutung, wie z. B. "ich kann eine 5 V-Zuführung akzeptieren". Ein Mechanismus kann zur Verfügung gestellt werden, um die Kompatibilität zu überprüfen, durch Durchführen des logischen UND zwischen den Erfordernissen eines Moduls und den Fähigkeiten der angepaßten Teile, wobei diese die Erfordernisse erfüllen müssen.
Diese Anordnung hat ihre Grenzen. Man betrachte Fähigkeitsfelder betreffend unterschiedliche Versionen eines Merkmals A: "ich habe Merkmal A1", "ich habe Merkmal A2" und "ich habe Merkmal A3". Es wird angenommen, daß jedes einzelne Modul zumindest eines dieser Bits gesetzt hat. Nun betrachte ein System, das Merkmal A1 oder Merkmal A2, nicht jedoch Merkmal A3 erfordert. Dieses System kann nicht das A1- und A2-Erfordernisbit setzen, da sie niemals beide erfüllt sein werden. Es gibt keine Möglichkeit, ein ODER von Fähigkeiten zu spezifizieren.
Eine weitere Ausführungsform der Erfindung überwindet dieses Problem. Wenn die Fähigkeit "ich habe das Merkmal A3" in das Erfordernis "ich benötige ein System, das ein Modul akzeptieren kann mit dem Merkmal A3" umgewandelt wird. Es gibt ein äquivalentes Erfordernis für jede Fähigkeit, so daß es nicht notwendig ist, ein zusätzliches Erfordernisfeld hinzuzufügen. Das Fähigkeitsfeld kann als dieses zweite Erfordernisfeld interpretiert werden. Es besteht jedoch die Notwendigkeit, ein zusätzliches Fähigkeitsfeld zu dem angepaßten Teil hinzuzufügen. In diesem Fall würde dieses zusätzliche Fähigkeitsfeld spezifizieren "ich bin in der Lage, ein Modul mit dem Merkmal A3 zu akzeptieren". Oftmals würde diese zusätzliche "Fähigkeit, die invertierte Fähigkeit zu akzeptieren", WAHR werden, so daß man erwarten würde, daß alle Bits in dem Handhabbarkeitsfeld "111 " wären. In dem Fall der A-Merkmale, die oben erwähnt wurden, die "ich bin in der Lage, ein Modul mit Merkmal A1 zu akzeptieren", "ich bin in der Lage, ein Modul mit Merkmal A2 zu akzeptieren" Bits würden auf "1" gesetzt und das "ich bin in der Lage, ein Modul mit dem Merkmal A3 zu akzeptieren" würde auf "0" gesetzt.
Man betrachte nun den Fall, daß der Hersteller wünscht, Module mit einem Merkmal "A4" zu bauen, einer Fähigkeit, an die man nicht gedacht hatte, als das Modul und die Software, die die Kompatibilität überprüft, konstruiert wurden. Kein Bit entsprechend dem Merkmal "A4" existiert in den abgelegten Daten in existierenden Modulen oder in den Erfordernissen oder Fähigkeiten von bereits bestehenden Systemen.
Um damit umzugehen, werden die Datenfelder erweiterbar gemacht, bestehend aus einem ursprünglichen Längendatum, gefolgt von einem Bitfeld, das in der Länge spezifiziert ist. Neue Module mit dem Merkmal "A4" können mit einem Extra-Bit in dem Datenfeld hergestellt werden, mit einer implizierten Bedeutung für das Fähigkeitsfeld "ich habe das Merkmal A4". Dies entspricht dem Erfordernisfeld "ich benötige ein Modul mit dem Merkmal A4" und dem Handhabbarkeitsfeld "ich bin in der Lage, ein Modul mit einem Merkmal A4 zu akzeptieren". Diese Anordnung wird dadurch zur Verfügung gestellt, daß die Felder erweitert werden, wenn keine Datenbits zur Verfügung gestellt werden, da die Feldlänge geringer als erwartet ist. Das Fähigkeitsfeld eines Moduls wird implizit mit Nullen erweitert, da ein altes Modul keine neuen Fähigkeiten haben wird. Das Erfordernisfeld des Systems wird implizit mit Nullen erweitert, da ein altes System sich nicht um neue Fähigkeiten kümmert. Das Handhabbarkeitsfeld eines Systems wird implizit mit Einsen erweitert, da das alte System in der Lage ist, neue Fähigkeiten von neuen Modulen zu akzeptieren.
In diesem Beispiel würde ein altes System, das nicht auf zur Verfügung gestellte "A"- Merkmale achtet, die alten "A"-Erfordernisbits auf 0 setzen und würde implizit ein A4-Erfordernisbit von 0 haben, so daß hinsichtlich des Erfordernisses keine Begrenzung besteht. Das "A"-Feld der sekundären Erfordernisse des alten Systems würden 1 sein und das implizite sekundäre A4- Erfordernisbit würde 1 sein, so daß die Überprüfungen alle erfolgreich sein würden und ein Modul mit dem Merkmal A4 ohne Veränderung in ein altes System eingesetzt werden könnte, das sich nicht um das Merkmal "A" kümmert.
Ein altes System, das ausdrücklich Module mit dem Merkmal A2 fordert, würde das Modul mit dem Merkmal A4 nicht akzeptieren, da das alte System das "ich benötige ein Modul mit Merkmal A2"-Bit gesetzt hätte und das "ich habe das Merkmal A2"-Bit in dem Modul mit dem Merkmal A4 nicht gesetzt wäre.
Ein altes System, das in der Lage war, Module mit den Merkmalen A2 oder A4, jedoch nicht mit dem Merkmal A3 zu akzeptieren, würde unter Verwendung dieser Anordnung automatisch das A4-Modul akzeptieren, aufgrund des impliziten Setzens des neuen A4-Handhabbarkeitsbits. Dies könnte nicht das sein, was der Benutzer möchte. Das Datensystem könnte implizieren "ich kann Module mit irgendeiner Version des Merkmals A akzeptieren, solange es nicht A3 ist" oder es könnte implizieren "ich kann nur Module akzeptieren mit den Merkmalen A1 oder A2". Es ist wahrscheinlich nicht möglich, zu bestimmen, was hiervon gemeint ist, bis dies mit dem Benutzer abgestimmt ist. Man beachte jedoch, daß es generell wünschenswert ist, abwärts kompatible Module herzustellen, so daß es wahrscheinlich ist, daß der Konstrukteur nicht Module mit dem Merkmal A4 bauen wird, wenn der Benutzer diese nicht mögen wird.
Folgend auf diese allgemeine Diskussion folgt nun eine Beschreibung einer Ausführungsform der Erfindung unter Bezug auf die Fig. 2 bis 4.
Fig. 2 ist eine schematische Darstellung von Komponenten eines Computersystems. Insbesondere Fig. 2 stellt schematisch ein Motherboard 30 dar, das einen Prozessor 32 und Speicher 34, die über einen Bus 36 verbunden sind, als auch andere Komponenten (nicht gezeigt), die typischerweise für solch ein System zur Verfügung gestellt wird, trägt. Ein einsteckbares Modul 40 ist jedoch gezeigt. In dem vorliegenden Beispiel ist das einsteckbare Modul eine Karte, die funktionale Schaltkreiselemente trägt. Es könnte jedoch alternativ dazu irgendeine Form von einsteckbarem Modul sein, wie z. B. eine I/O-Karte, ein RAM-Speicher oder irgendein anderer Speicher oder Schaltkreiselement, wie z. B. ein RAM-Modul oder ein Laufnummern-EEPROM oder ein Prozessor. Das Modul könnte sogar ein Softwaremodul für die Integration mit anderen Softwaremodulen oder mit Hardware sein. In jedem Fall ein Modul und eine kooperierende Komponente (die Hardware oder Software sein könnte) werden jeweils mit einer Struktur, die Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeiger für das Modul definieren, ausgestattet.
In dem gerade dargestellten Beispiel ist das einsteckbare Modul in einen Sockel 38 einsteckbar, der mit dem Bus 36 verbunden ist. Das einsteckbare Element beinhaltet eine Mehrzahl von Registern 42, 44, 46 und 48 für den Fähigkeitstyp, die Modulerfordernisse, die primären Modulfähigkeiten bzw. die sekundären Modulfähigkeiten (das heißt Fähigkeiten und Handhabbarkeitsfähigkeiten). Der Prozessor behält in Speicherregistern 52, 54, 56 und 58 ebenso den Fähigkeitstyp, die Systemerfordernisse, die Systemfähigkeiten bzw. die Systemhandhabbarkeiten. Jedes der Register wird verwendet, um entsprechende Datenfelder zur Verfügung zu stellen, die ein Längendatum 20 und eine Anzahl von Bits 22 umfassen, die durch die Länge des Datums spezifiziert sind. Ein Beispiel von solch einem Register ist in der Fig. 3 gezeigt. Der Zweck der Register ist unten mehr im Detail beschrieben.
Der Prozessor behält ebenso in dem Speicher die steuercodebildende Kompatibilitätsüberprüfungslogik 60 für das Errichten der Kompatibilität zwischen dem System und dem Modul. Die Kompatibilitätsüberprüfungslogik muß nicht von dem Prozessor gesteuert werden, sondern kann durch Hardware für spezielle Zwecke oder durch einen programmierbaren Schaltkreis, wie z. B. ein ASIC, herbeigeführt werden. Die Kompatibilitätsüberprüfungslogik könnte ebenso getrennt auf einem Datenträger, wie z. B. einem Laufwerk oder einem Band zur Verfügung gestellt werden oder könnte über ein Telekommunikationsmedium, wie z. B. ein Draht oder ein optisches Kabel oder durch ein drahtloses oder über Satellit oder irgendein anderes geeignetes Trägermedium geliefert werden. Tatsächlich könnte die Überprüfungslogik von einem getrennten Mittel zur Verfügung gestellt werden, solange das Mittel in der Lage ist, die Erfordernisse, Fähigkeiten und Handhabbarkeiten zu erfassen und die Zwischenverbindungen zwischen diesen zu analysieren.
Fig. 4 ist eine schematische Darstellung der Wechselwirkung zwischen der Überprüfungssteuerlogik und den verschiedenen Registern. Obgleich Bezug genommen wird auf "Register", müssen diese nicht getrennte Register sein, sondern können in dem Arbeitsspeicher definiert sein.
Wie in Fig. 4 gezeigt ist, stellen Module (und die Komponenten, in die diese eingesteckt werden) jeweils drei Datenfelder zur Verfügung. Jedes dieser Felder wird implementiert als ein Längendatum, gefolgt von der spezifizierten Anzahl von Bits.
Für ein Modul:
MP ist ein Feld, das Merkmale einer Systemkomponente definiert, die für das Modul notwendig sind, um zu funktionieren;
MC ist ein Feld, das Eigenschaften definiert, die von dem Modul zur Verfügung gestellt werden, und
MA ist ein Feld, das Merkmale der Systemkomponente definiert, die von dem Modul akzeptiert werden.
Für ein System:
SR ist ein Feld, das Merkmale des Moduls definiert, die für die Akzeptierung durch die Systemkomponente notwendig sind;
SC ist ein Feld, das Merkmale definiert, die von der Systemkomponente zur Verfügung gestellt werden, und
SA ist ein Feld, das Merkmale des Moduls definiert, das von der Systemkomponente akzeptiert wird.
Vor der Benutzung werden alle Felder in jeder Berechnung entsprechend dem längsten verfügbaren Feld zwischen dem Modul und dem System erweitert. R- und C-Felder werden mit Nullen erweitert. A-Felder werden mit Einsen erweitert. Ein Bit in irgendeinem Feld wird gesetzt, wenn das verknüpfte Statement über das Merkmal WAHR ist.
Ein Modul wird definiert als kompatibel, wenn (unter Verwendung der Syntax der Programmiersprache "C"):
((MR & SC) = = MR) *System stellt alle Erfordernisse des Moduls zur Verfügung *
&& ((MA & SC) SC) *Keine Fähigkeit des Systems ist inkompatibel mit dem Modul*
&& ((SR & MC1) = = SR) *Modul stellt alle Erfordernisse des Systems zur Verfügung *
&& ((SA & SC1) = = MC1) *Keine Fähigkeit des Moduls ist mit dem System inkompatibel*
Das Statement bzw. die Erklärung, die mit einem gegebenen Bit in einem Feld verknüpft ist, muß nicht die gleiche für jedes Produkt sein. Beispielsweise kann das Bit 0 der SR- und SA- und MC-Felder für eine Leistungszuführung die Eingangsspannungskompatibilität betreffen.
SR[0] 1 bedeutet "das System erfordert eine PSU, die in der Lage ist, 240 V Eingangsspannung zu akzeptieren"
MC[0] 1 bedeutet "diese PSU kann 240 V Eingangsspannung akzeptieren"
SA[0] 1 bedeutet "das System kann mit PSUs zusammenarbeiten, die in der Lage sind, 240 V Eingangsspannung zu akzeptieren"
Dieses Merkmal ist eindeutig, und daher unnötig zu erwähnen, ein Laufwerksmodul, bei dem wir mehr interessiert an der Speicherkapazität sein könnten und bei dem eine AC-Spannung irrelevant ist.
Um diese Variabilität in der Bedeutung zu implementieren, kann ein "Merkmalstyp"-Code optional als Teil der Kompatibilitätsdaten zur Verfügung gestellt werden. Der Merkmalstyp ist eine Zahl, die beschreibt, wie die Kompatibilität und die Erfordernisdaten zu interpretieren sind. Merkmalstypen müssen präzise übereinstimmen für das Produkt, das kompatibel sein soll. Es hat keinen Sinn, ein Laufwerksmodul in einen Stromquellenzuführungsslot einzustecken. Zusätzlich zu den MR- MC- und MA-Feldern liefert daher in Übereinstimmung mit einer Ausführungsform der Erfindung ein Modul ebenso ein MT-Datum, den Fähigkeitstyp, der mit dem ST-Typ-Datum für das System übereinstimmen muß. Es versteht sich, daß dieser Typcode nicht notwendigerweise mit der Funktion des Moduls verknüpft ist, sondern nur die Art und Weise angibt, wie die Fähigkeits- und Erfordernisdaten interpretiert werden.
So wird auf Module mit radikal unterschiedlicher Funktionsweise Bezug genommen, die in einen einzigen Slot eingesteckt werden können, z. B. ein Laufwerksinterface oder ein Kommunikationsinterface, die beide in einen PCI-Slot eingesteckt werden könnten. Diese könnten entweder einen gemeinsamen Typ teilen, der spezifizieren würde, wie die Fähigkeitsbits zu interpretieren wären, und eine Vielzahl von Fähigkeitsbits würden ungenutzt bleiben. In diesem Fall könnte die Laufwerksschnittstelle die Fähigkeit "ich habe vier Kommunikations-Leitungen" auf 0 setzen.
Alternativ dazu könnten sie unterschiedliche Typen haben und das System würde verstehen, wie die Kompatibilität von jedem Typ berechnet wird unter Verwendung von unterschiedlichen SR-, SC- und SA-Feldern für jeden Typ.
Als ein Beispiel der Vielseitigkeit und der Erweiterbarkeit dieses Schemas betrachte man ein Netzgerät, das hat:
MT 14 - Dies hat Fähigkeiten, die für ein PSU interpretiert werden;
MC[0] 1 - Ich kann 400 W liefern
Das System konnte für dieses selbe Interface setzen:
ST 14 - Dies erfordert Fähigkeiten, die für ein PSU interpretiert werden,
SR[0] 1 - Das System erfordert eine Zuführung von 400 W,
SA[O] 1 - Das System kann Zuführungen akzeptieren, die in der Lage sind, 400 W zu liefern.
Dann, zu einem späteren Zeitpunkt werden Zuführungen mit höherem Ausgang ausgeliefert, die haben:
MT 14 - Dies hat Fähigkeiten, die für ein PSU interpretiert werden,
MC[0] 1 - Ich kann 400 W liefern.
und ebenso die neue Fähigkeit
MC[23] 1 Ich kann 600 W liefern.
Diese Zuführung würde korrekt als kompatibel mit dem alten System angesehen.
Fig. 5 ist ein Flußdiagramm, das die Funktion der Überprüfungslogik 60 von Fig. 2 darstellt.
In Schritt S1 wird das Modul in das System eingesetzt.
In Schritt S2 wird ein Vergleich von dem System zwischen den System- und Modulanforderungen und -fähigkeiten durchgeführt. Somit, wenn bei einem Vergleich der Register festgestellt wird, daß:
das System all die Erfordernisse des Moduls zur Verfügung stellt und
keine Fähigkeit des Systems mit dem Modul inkompatibel ist und
das Modul alle Erfordernisse des Systems zur Verfügung stellt und
keine Fähigkeit des Moduls mit dem System inkompatibel ist,
dann sind das Modul und das System kompatibel.
Dies wird erreicht durch Feststellen, für jede Bitposition in den jeweiligen Registern, daß:
MR UND SC = MR, und
MA UND SC = SC, und
SR UND MC = SR, und
SA UND MC = MC sind,
wobei "UND" eine logische "UND"-Funktion ist.
Wenn die logischen Vergleiche der Erfordernisse, Fähigkeiten und Handhabbarkeitsfähigkeiten WAHR sind, dann akzeptiert das System das Modul als kompatibel in Schritt S3.
Wenn die logischen Vergleiche der Erfordernisse und Fähigkeiten FALSCH sind, dann wird das Modul in Schritt S4 zurückgewiesen. Die Zurückweisung könnte in der Form erfolgen des Blockens aller Zugriffe auf das betreffende Modul, wenn dies geeignet ist, oder alternativ dazu durch Anzeigen der Inkompatibilität beispielsweise durch Einstellen eines hörbaren oder sichtbaren Warnsignals oder durch Anschlagen eines Anzeigers in dem Speicher, auf den durch den Benutzer zugegriffen wird mit oder bevor das betroffene System betrieben wird.
Obwohl in der obigen Beschreibung angenommen wurde, daß die Überprüfungslogik in dem Speicher 34 des Computersystems gehalten wird und von dem Prozessor 32 ausgeführt wird, könnte ein Modul zur Verfügung gestellt werden mit geeigneter Logik, um die notwendige Überprüfung durchzuführen. Wie oben beschrieben wurde, könnte die Überprüfung von einem getrennten Drittmittel oder Dritteinheit durchgeführt werden.
Es wurde ein Beispiel der Modulverbindung in Übereinstimmung mit einer Ausführungsform der Erfindung beschrieben. Obgleich dieses Beispiel in dem Kontext von einsteckbaren Modulen für ein Computersystem beschrieben wurde, findet die Erfindung Anwendung in jedem modularen System oder Apparat mit komplexen Zwischenverbindungen zwischen Erfordernissen, Fähigkeiten und Handhabbarkeiten, insbesondere dann, wenn diese Erfordernisse, Fähigkeiten und Handhabbarkeiten sich mit der Zeit ändern, wenn neue Versionen der jeweiligen Module mit neuen Erfordernissen, Fähigkeiten und/oder Handhabbarkeitsfähigkeiten entwickelt werden.
Die Erfindung findet insbesondere Anwendung in fehlertoleranten Computersystemen, in denen es sehr wünschenswert ist, die hohe Verfügbarkeit des Systems sicherzustellen. In solch einem Fall ist es besonders wichtig, sicherzustellen, daß alle einfügbaren oder einsteckbaren Geräte in dem System überprüft werden können als voll kompatibel mit dem System, bevor sie völlig in das System integriert werden.
Fig. 6 ist ein schematischer Überblick über ein fehlertolerantes Computersystem, in dem eine Ausführungsform der Erfindung implementiert werden kann.
Fig. 6 ist ein schematischer Überblick eines fehlertoleranten Computersystems 110, das eine Mehrzahl von CPU-Sätzen (verarbeitenden Sätzen) 114 und 116 und eine Brücke 112 aufweist. Wie in Fig. 6 gezeigt ist, gibt es zwei verarbeitende Sätze 114 und 116, obgleich es in anderen Ausführungsformen drei oder mehrere verarbeitende Sätze geben kann. Die Brücke 112 bildet eine Schnittstelle zwischen den verarbeitenden Sätzen und den I/O-Geräten, wie z. B. den Geräten 127, 128, 129, 130, 131 und 132. In diesem Dokument wird die Bezeichnung verarbeitender Satz verwendet, um eine Gruppe von einem oder mehreren Prozessoren zu bezeichnen, möglicherweise einschließlich Speicher, die gemeinsame Eingänge und Ausgänge empfangen und ausgeben. Es versteht sich, daß der alternative Term, der oben erwähnt wurde, "CPU-Satz", anstelledessen verwendet werden könnte.
Der erste verarbeitende Satz 114 ist mit der Brücke 112 über einen ersten verarbeitenden Satz-I/O-Bus (PA-Bus) 124 verbunden, in dem vorliegenden Beispiel ein PCI-Bus. Der zweite verarbeitende Satz 116 ist mit der Brücke 112 verbunden über einen zweiten verarbeitenden Satz-I/O- Bus (PB-Bus) 126 desselben Typs wie der PA-Bus 124 (das heißt hier ein PCI-Bus). Die I/O-Geräte sind mit der Brücke 112 über ein I/O-Busgerät (D-Bus) 122 verbunden, in dem vorliegenden Beispiel ebenso ein PCI-Bus.
Obgleich in dem speziellen beschriebenen Beispiel die Busse 122, 124 und 126 alle PCf- Busse sind, ist dies lediglich beispielhaft zu verstehen und in anderen Ausführungsformen können andere Busprotokolle verwendet werden und der D-Bus 122 kann ein unterschiedliches Protokoll von dem des PA-Busses und des PB-Busses (P-Busses) 124 und 126 haben.
Die verarbeitenden Sätze 114 und 116 und die Brücke 112 sind synchron unter der Steuerung eines gemeinsamen Taktes 120 betreibbar, der hiermit über die Taktsignalleitungen 21 angeschlossen ist.
Manche der Geräte 128, 129 einschließlich einer Ethernet- (E-Net-) Schnittstelle 128 und einem Small Computer Systems Interconnect-lnterface (SCSI) 129 sind permanent mit dem Gerätebus 122 verbunden, während andere I/O-Geräte, wie die I/O-Geräte 130, 131 und 132, unter Spannung in einzelne geschaltete Slots 133, 134 und 135 eingesetzt werden können. Schaltung mittels dynamischer Feldeffekttransistoren (FETs) kann für die Slots 133, 134 und 135 zur Verfügung gestellt werden, um die Einfügbarkeit unter Spannung zu gewährleisten und die geographische Adressierung der Geräte, wie z. B. der Geräte 130, 131 und 132. Es versteht sich, daß die Anzahl von I/O-Geräten, die mit dem D-Bus 122 verbunden werden können und die Anzahl von Slots, die hierfür zur Verfügung gestellt werden, entsprechend einer bestimmten Implementierung in Übereinstimmung mit bestimmten Konstruktionserfordernissen eingestellt werden kann.
Die Kompatibilitätsverbindung der vorliegenden Erfindung könnte für das Feststellen der Kompatibilität zwischen den verschiedenen modularen Komponenten, die in Fig. 6 gezeigt sind, verwendet werden oder sogar zwischen einzelnen Modulen, die zusammen die in Fig. 6 gezeigten Komponenten bilden.
Die Module und Komponenten, bei denen die Kompatibilitätsverbindung angewendet wird, können Hardware- oder Softwaremodule und Komponenten sein. Ein Softwaremodul könnte für die Integration mit anderen Softwaremodulen oder mit Hardware da sein. In jedem Fall wird ein Modul und eine zusammenwirkende Komponente (die Hardware oder Software sein könnte) jeweils mit einer Struktur ausgestattet, die die Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeiger für das Modul und die Komponente definiert. Im Falle eines Softwaremoduls könnte dies zur Verfügung gestellt werden auf einem Datenträger, wie z. B. einer Platte oder einem Band oder könnte mittels eines Telekommunikationsmediums übertragen werden, wie z. B. einem Draht oder einem optischen Kabel oder mittels eines drahtlosen oder Satelliten- oder sogar irgendeines anderen geeigneten Trägermediums. Das Trägermedium könnte ebenso ein Halbleiter oder ein anderes Speichergerät sein.
Es versteht sich, daß, obgleich spezielle Ausführungsformen der Erfindung beschrieben wurden, viele Modifikationen/Zusätze und/oder Substitutionen innerhalb des Schutzbereichs der beanspruchten Erfindung vorgenommen werden können.

Claims

1. Modul für ein modulares System, wobei das Modul (40) mit einem Bauteil (30) des modularen Systems verbindbar ist und aufweist:

Erfordernisanzeigen (MR), welche Eigenschaften des Bauteils definieren, die erforderlich sind, damit das Modul arbeitet,

Fähigkeitsanzeigen (MC1), welche Merkmale definieren, die von dem Modul bereitgestellt werden, und

Handhabbarkeitsanzeigen (MC2), welche Merkmale des Bauteils definieren, die für das Modul akzeptabel sind.

2. Modul nach Anspruch 1, das eine erste Anzahl von Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeigen hat, wobei das Modul mit einem Bauteil verbindbar ist, welches eine unterschiedliche Anzahl von Erfordernis-, Fähigkeits- und Handhabbarkeitsanzeigen hat.

3. Modul nach Anspruch 1 oder 2, welcher einen Längenanzeiger aufweist, der für die Anzahl von zumindest einer, nämlich der Erfordernisanzeigen, der Fähigkeitsanzeigen und der Handhabbarkeitsanzeigen kennzeichnend ist.

4. Modul nach einem der vorstehenden Ansprüche mit:

- einer Erfordernisstruktur, welcher ein Erfordernisanzeigenfeld variabler Länge und ein Erfordernislängenfeld für das Anzeigen einer Anzahl von Erfordernisanzeigen in dem Erfordernisanzeigefeld aufweist,

- einer Fähigkeitsstruktur, der ein Fähigkeitsfeld variabler Länge und ein Fähigkeitslängenfeld aufweist, um eine Anzahl von Fähigkeitsindikatoren in dem Fähigkeitsanzeigefeld anzuzeigen, und

- einer Handhabbarkeitsstruktur, der ein Handhabbarkeitsfeld variabler Länge und ein Handhabbarkeits-Längenfeld aufweist, um eine Anzahl von Handhabbarkeitsindikatoren in dem Handhabbarkeitsanzeigefeld anzuzeigen.

5. Modul nach Anspruch 4, wobei

- die Erfordernisstruktur einen Erfordernisspeicher aufweist,

- die Fähigkeitsstruktur einen Fähigkeitsspeicher aufweist, und die Handhabbarkeitsstruktur einen Handhabbarkeitsspeicher aufweist.

6. Modul nach einem der vorstehenden Ansprüche, wobei

- jeder Erfordernisanzeiger ein Erfordernisbit aufweist,

- jeder Fähigkeitsanzeiger ein Fähigkeitsbit aufweist, und

- jeder Handhabbarkeitsindikator ein Handhabbarkeitsbit aufweist.

7. Modul nach einem der vorstehenden Ansprüche, welcher weiterhin einen Anzeiger vom Modultyp aufweist.

8. Modul nach einem der vorstehenden Ansprüche, wobei das Bauteil ein weiteres Modul ist.

9. Modul nach einem der vorstehenden Ansprüche, wobei das Modul in das Bauteil einsteckbar ist.

10. Modul nach einem der vorstehenden Ansprüche, wobei das Bauteil ein Bauteil eines modularen Systems ist.

11. Modul nach einem der vorstehenden Ansprüche, wobei das Modul eine Hauptplatine für die Aufnahme steckbarer modularer Bauteile ist.

12. Modul nach einem der vorstehenden Ansprüche, welcher eine Bestätigungslogik für die Bestätigung der Kompatibilität zwischen dem Modul selbst und einem damit zusammenwirkenden Bauteil aufweist.

13. Modul nach Anspruch 12, wobei das Modul so betreibbar ist, daß es die folgenden Beziehungen auswertet und die Kompatibilität feststellt, wenn alle folgenden Beziehungen erfüllt sind:

MR AND SC = MR;

MA AND SC = SC;

SR AND MC = SR; und

SA AND MC = MC,

wobei AND ein logischer UND-Operator ist, MR und SR die Erfordernisanzeigen für das Modul bzw. das Bauteil sind, MC und SC die Fähigkeitsindikatoren für das Modul bzw. das Bauteil sind und MA und SA die Handhabbarkeitsindikatoren für das Modul bzw. das Bauteil sind.

14. Modul nach Anspruch 13, mit:

- einem Erfordernisaufbau, der ein Erfordernisindikatorfeld variabler Länge und ein Erfordernislängenfeld für das Anzeigen einer Anzahl von Erfordernisindikatoren in dem Erfordernisindikatorfeld aufweist,

- einer Fähigkeitsstruktur, die ein Fähigkeitsfeld variabler Länge und ein Fähigkeitslängenfeld für die Anzeige einer Anzahl von Fähigkeitsindikatoren in dem Fähigkeitsindikatorfeld aufweist, und

- einen Handhabbarkeitsaufbau, der ein Handhabbarkeitsfeld variabler Länge und ein Handhabbarkeitslängenfeld aufweist für das Anzeigen einer Anzahl von Handhabbarkeitsindikatoren in dem Handhabbarkeitsindikatorfeld.

15. Modul nach Anspruch 14, wobei alle äquivalenten Erfordernis-, Fähigkeits- und Handhabbarkeitsindikatoren in den Feldern variabler Länge entsprechend den folgenden Beziehungen verglichen werden:

MR AND SC = MR;

MA AND SC = SC;

SR AND MC = SR; und

SA AND MC = MC.

16. Modul nach Anspruch 15, wobei irgendwelche nicht spezifizierten Erfordernisse als nicht vorhanden behandelt werden.

17. Modul nach Anspruch 15 oder 16, wobei jegliche nicht beschriebenen Fähigkeiten als nicht vorhanden behandelt werden.

18. Modul nach einem der Ansprüche 15 bis 17, wobei nicht spezifizierte Handhabbarkeiten als vorhanden behandelt werden.

19. Modul nach einem der Ansprüche 15 bis 17, wobei irgendwelche nicht spezifizierten Handhabbarkeiten wahlweise als vorhanden oder als nicht vorhanden behandelt werden.

20. Computersystem einschließlich eines Moduls (40) nach einem der vorstehenden Ansprüche, sowie dem Bauteil (30), wobei das Bauteil aufweist:

- Erfordernisindikatoren (SR), die Merkmale definieren, welche für das Bauteil erforderlich sind,

- Fähigkeitsindikatoren, welche Fähigkeiten definieren, die durch das Bauteil bereitgestellt werden, und

- Handhabbarkeitsindikatoren (SC2), welche Merkmale definieren, die für das Bauteil akzeptabel sind.

21. Computersystem nach Anspruch 20, welches weiterhin aufweist: eine Kompatibilitätsauswertelogik, um die Beziehungen zwischen den Erfordernisindikatoren, den Fähigkeitsindikatoren und den Handhabbarkeitsindikatoren des Moduls und des Bauteils auszuwerten, um die Kompatibilität zwischen dem Modul und dem Bauteil zu überprüfen.

22. Computersystem nach Anspruch 20 oder 21, mit:

einem Systembauteil, welches Systemerfordernisanzeiger, welche Merkmale eines Moduls definieren, die für das Systembauteil erforderlich sind, Systemfähigkeitsindikatoren, die Merkmale definieren, welche von dem Systembauteil bereitgestellt werden, und Systemhandhabbarkeitsindikatoren aufweist, welche Merkmale des Moduls definieren, die für die Systembauteile akzeptabel sind,

einem Modul, das Modulerfordernisindikatoren aufweist, welche Merkmale eines Systembauteils definieren, die für das Modul erforderlich sind, Modulfähigkeitsindikatoren, die Merkmale definieren, die von dem Modul bereitgestellt werden, und Modulhandhabbarkeitsindikatoren aufweist, die Merkmale des Systembauteils definieren, die für das Modul akzeptabel sind, und

einer Kompatibilitätsauswertelogik für das Auswerten der folgenden Beziehungen und für das Bestimmen der Kompatibilität, wenn alle folgenden Beziehungen erfüllt sind:

MR AND SC = MR;

MA AND SC = SC;

SR AND MC = SR; und

SA AND MC1 = MC,

wobei AND ein logischer UND-Operator ist, MR und SR die Erfordernisindikatoren für das Modul bzw. das Systembauteil bilden, MC und SC die Fähigkeitsindikatoren für das Modul bzw. für das Systembauteil bilden, und MA und SA die Handhabbarkeitsindikatoren für das Modul bzw. das Systembauteil bilden.

23. Verfahren zum Überprüfen der Kompatibilität zwischen zumindest zwei Systembauteilen bzw. -komponenten, wobei jede Komponente Erfordernisindikatoren aufweist, welche Merkmale definieren, die für die Komponente erforderlich sind, wobei Fähigkeitsindikatoren Merkmale definieren, die durch die Komponente bereitgestellt werden und Handhabbarkeitsindikatoren Merkmale definieren, die für die Komponente akzeptabel sind, wobei das Verfahren aufweist:

logische Auswertebeziehungen zwischen den Erfordernisindikatoren, den Fähigkeitsindikatoren und den Handhabbarkeitsindikatoren der Komponenten, um die Kompatibilität zwischen den Komponenten zu überprüfen, und

Bestimmen der Kompatibilität, wenn eine vorbestimmte logische Beziehung bereitgestellt ist.

24. Verfahren nach Anspruch 23, wobei die folgenden Beziehungen ausgewertet werden:

MR AND SC = MR;

MA AND SC = SC;

SR AND MC = SR; und

SA AND MC1 = MC,

wobei AND ein logischer UND-Operator ist, SR und MR Erfordernisindikatoren für erste bzw. zweite Komponenten sind, SC und MC Fähigkeitsindikatoren für die ersten bzw. zweiten Komponenten sind und SA und MA die Handhabbarkeitsindikatoren für die ersten bzw. zweiten Komponenten sind.

25. Verfahren nach Anspruch 24, wobei die Kompatibilität festgestellt wird, wenn die Beziehungen erfüllt sind.

26. Verfahren nach einem der Ansprüche 23 bis 25, wobei eine Komponente eine Systemkomponente und eine weitere Komponente ein Modul eines modularen Systems ist.

27. Verfahren nach Anspruch 26, wobei

MR und SR jeweils eine Erfordernisstruktur für das Modul bzw. die Komponente aufweisen, wobei jede Erfordernisstruktur ein Erfordernisindikatorfeld variabler Länge und ein Erfordernislängenfeld aufweist für das Anzeigen einer Anzahl von Erfordernisindikatoren in dem Erfordernisanzeigefeld,

MC und SC jeweils eine Fähigkeitsstruktur für das Modul bzw. die Komponente aufweisen, wobei jede Fähigkeitsstruktur ein Fähigkeitsfeld variabler Länge und ein Fähigkeitslängenfeld für die Anzeige einer Anzahl von Fähigkeitsindikatoren in dem Fähigkeitsanzeigefeld aufweist,

MS und SA jeweils einen Handhabbarkeitsaufbau für das Modul bzw. die Komponente aufweist, wobei jeder Handhabbarkeitsaufbau ein Handhabbarkeitsfeld variabler Länge und ein Handhabbarkeitslängenfeld für die Anzeige einer Anzahl von Handhabbarkeitsindikatoren in dem Handhabbarkeitsanzeigefeld aufweist, und

alle äquivalenten Erfordernis-, Fähigkeits- und Handhabbarkeitsindikatoren in den Feldern variabler Länge gemäß den folgenden Beziehungen miteinander verglichen werden:

MR AND SC = MR;

MA AND SC = SC;

SR AND MC = SR; und

SA AND MC = MC.

28. Verfahren nach Anspruch 27, wobei irgendwelche nicht spezifizierten Erfordernisse als nicht vorhanden behandelt werden.

29. Verfahren nach Anspruch 27 oder 28, wobei irgendwelche nicht spezifizierten Fähigkeiten als nicht vorhanden behandelt werden.

30. Verfahren nach einem der Ansprüche 27 bis 29, wobei irgendwelche nicht spezifizierten Handhabbarkeiten als vorhanden behandelt werden.

31. Verfahren nach einem der Ansprüche 27 bis 29, wobei irgendwelche nicht spezifizierten Handhabbarkeiten wahlweise als vorhanden oder abwesend behandelt werden.