DE69209364T2

DE69209364T2 - Verteiltes Mehrknoten-Datenverarbeitungssystem zur Verwendung in einem Oberflächenfahrzeug

Info

Publication number: DE69209364T2
Application number: DE69209364T
Authority: DE
Inventors: Tooren Petrus Maria Antoni Van; Venrooy Roland Theodorus H Van
Original assignee: Philips Electronics NV
Current assignee: Continental Automotive GmbH
Priority date: 1991-05-22
Filing date: 1992-05-12
Publication date: 1996-10-10
Anticipated expiration: 2012-05-13
Also published as: US5860020A; JPH05204890A; US5652911A; EP0514972B1; EP0514972A3; EP0514972A2; DE69209364D1; US6233602B1; ES2086636T3

Description

BEREICH DER ERFINDUNG

Die Erfindung betrifft verteilte Datenverarbeitung in einem Land-Fahrzeug wie einem Automobil. Heutige Kraftfahrzeuginformationssysteme verwalten verschiedene unterschiedliche Datenkategorien, die für den Gebrauch des Fahrzeugs als Ganzes nützlich sind, wie:
- den internen Status des Fahrzeugs unabhängig von seiner tatsächlichen Position;
- mit seiner geographischen Position und Route zusammenhängende Informationen;
- Informationen hinsichffich des Fahrers und der Passagiere, wie sie sich durch Eingabevorgänge und Ausgabearstellungen offenbaren.
Eine Fülle von Teillösungen zur Motor- und Umgebungssteuerung im Fahrzeug, Speicherung zuganglicher geographischer Daten, Routenplanung und -lenkung Straßenzustandssignalisierung, externe Datenkommunikation, Steuerung der Unterhaltungselektronik im Auto, Telefonie, und verschiedene andere ist bereits realisiert worden und soll realisiert werden. Mehrere davon könnten sich in Stand-alone-Geräten wiederfinden, aber Zusammenbeit zwischen ihnen würde ihren Nutzen erhöhen. Zwei Beispiele wären erstens, daß ein niedriges Kraftstoffniveau die Route einen Umweg entlang einer Tankstelle machen lassen würde, die nicht an der vorgewählten Strecke liegt, die an sich optimal wäre. Zweitens könnte ein Autotelefon-Anruf jede andere Audiowiedergabe deaktivieren. Viele andere Möglichkeiten zur Verbesserung der Funktionalität für den Benutzer, zur besseren physiklische Funktionalität des Fahrzeugs oder zur Verbesserung der Datenverarbeitungsfähigkeiten wären denkbar. Eine Schwierigkeit könnte sein, daß verschiedene Teillösungen von unterschiedlichen Herstellern realisiert worden sind, sich in unterschiedlichem Zustand der Realisierung befinden, stark unterschiedliche Grade eingebauter Interngenz aufweisen, wie einen binären Sicherheitsgurtsensor gegenüber einem ausgeklügelten Routenplanungsrechner, wobei all diese Probleme dadurch verschlimmert werden, daß die Software-Entwicklungszeit länger wird und fachkundige Systemanalysierer rar sind.
Ein Beispiel für eine Datenverarbeitungseinrichtung in einem Land-Fahrzeug wird von J.B. Alegiani et al. im Conference Report der First Vehide Navigation & Information Systems, 11. September 1989, S. A3-A8, IEEE, New York, gegeben: "An in-vehicle navigation and information system utilizing defined software services".
Daher liegt der Erfindung unter anderem die Aufgabe zugrunde, ein verteiltes Echtzeitcomputer-Betriebssystem zu verschaffen, das einige oder alle der folgenden Zahl primärer Ziele berücksichtigt:
- Die Systemsoftware des Betriebssystems sollte einfache Wartung ermöglichen. Sie sollte einfach und aus nur wenigen, kleinen Einzelfunktionseinheiten aufgebaut sein.
- Die Software sollte auf unterschiedliche Hardware übertragbar sein, die entweder höher entwickelt oder vereinfacht sein kann. Insbesondere würde das System zwei verschiedene Kommunikationsebenen zulassen. Die erste, niedrigere Ebene beinhaltet das Übertragen eines oder mehrerer aus einer endlichen Menge von Gperatoren (wie Ein, Aus, Lese-Status), woraufhin ein Ziel immer mit einer oder mehrerer aus einer endlichen Menge von Reaktionen reagieren wird. Auf der höheren Ebene weist die Endbestimmung einen gewissen Grad an nichtdeterministischem Verhalten auf, wie es einem Knoten oder einer Station, die von einem lokalen Betriebssystem gesteuert wird, eigen ist. In diesem Fall braucht die Menge von Reaktionen nicht endlich zu sein. Außerdem könnte die Antwort durch verschiedene vom Zielknoten auszuführende Aufgaben oder Prozesse nichtdeterministisch (wie beim anfordernden Knoten zu sehen ist) verzögert sein.
- Die Software sollte deutlich definierte Schnittstellen zwischen ihren verschiedenen Teil-Software-Modulen und auch mit Hinblick auf heutige oder zukünftige Anwendungssoftware haben. Auf diese Weise könnte ein beliebiges Software- Modul verbessert werden, ohne im übrigen Teil Chaos zu verursachen.
- Ein wesentliches Element sollte ein Betriebssystem zur Steuerung der jeweiligen lokalen Einrichtungen sein, das leistungsstark und von einfach zugänglicher Struktur ist, wie z.B. CD-RTOS (Compact Disc Real Time Operating System), das von Microware, DES Momes, Iowa, aus dem früheren OS-9 abgeleitet worden ist, oder ein anderes System mit vergleichbaren Fähigkeiten. Insbesondere ist dieses Betriebssystem in dem CD-I(CD-Interactive)-Teilsystem zur Aufnahme und Präsentation von auf optischer Platte gespeicherten, Geographie und ähnliches betreffenden Informationen entworfen worden.
- Das Netz der Verbindungen untereinander sollte deterministischen Nachrichtenverkehr zulasn, das heißt, daß unter normalen Umständen die Zeitverschiebung zwischen Versenden und Ankunft von Daten ein vorgebbares Maximum für den ungünstigsten Fall haben sollte, was natürlich von solchen allgemeinen Systemeigenschaften wie der Anzahl Knoten abhängen kann. Wie im weiteren erläutert werden soll, ermöglicht das ARCNET-Standard-Busprotokoll eine vorteilhalte Realisierung. Dieses ist von Standard Microsystems Corporation of Hauppage, New York, USA, entwickelt und in dem LAN-Controller COM90 C26, veröffentlicht in ihrem Bauelementekatalog 1988, S. 207-222, implementiert worden.
- Die Schnittstelle zwischen dem Betriebssystem und einem beliebigen Anwendungssoftware-Modul sollte standardisiert sein. Auf diese Weise würde eine Änderung der Anhl, Art und Leistung der Anwendungssoftware-Module keine Änderung des Steuerungssystems erforderlich machen. Außerdem würde eine Anderung der System-Hardware nur eine Änderung der System-Software erfordem, aber nicht der Anwendungs- oder knotenspezifischen Software.

ZUSAMENFASSUNG DER ERFINDUNG

Dementsprechend beabsichtigt die Erfindung, für die zu dem lokalen Modul gehörende, in der Sprache C geschriebenen Software außer Assembler-Mitteln zum Umsetzen von in einer höheren Sprache geschriebenen Befehlen in binären Code, der die lokale Hardware und/oder Datenbasiselemente direkt steuert, eine lokale Bibliothek zu verschaffen, um damit verschiedene Elemente einer begrenzten Menge von Primitiven in ein geeignetes Format, wie es von dem Busprotokoll vorgegeben wird, umzusetzen. Dies ermöglicht, daß jede Änderung auf Bus-Ebene (Hardware oder Software) nur eine Abwandlung der Bibliothek notwendig macht, und eine beliebige Änderung in einem ersten Knoten würde nur eine Abwandlung der Zugriffseinrichtungen des Busses erfordern, aber niemals von Software in irgendeinem zweiten Knoten. Als eine solche begrenzte Menge haben die Erfinder die folgenden neun als ausreichend (und häufig notwendig) erkannt: open, close, read, write, seek, getstat, setstat, signal, create (= create process). Diese neun sind als sogenannte Systemaufrufe (System Calls) in einer UNIX-Umgebung als Teilmenge von 54 zuässigen Systemaufrufen von M.J. Rochkind, Advanced Unix Programming, Prentice-Hall Inc., Englewood Cliffs, N.Y., USA, 1985 beschrieben worden. Insbesondere das Paar getstat/setstat ist eine spezielle Ableitung aus dem octl-Systemaufruf, der bereits in OS-9 entwickelt worden ist. Das Register in dem oben genannten Buch listet alle Systemaufrufe, wie sie im folgenden erläutert werden, auf. Für eine ARCNET-Realisierung braucht die Bibliothek nur die knotengenerierten Gesamtheiten in den geeigneten Systemaufruf zu übersetzen.
Nach einem ihrer Aspekte löst die Erfindung die Aufgabe dadurch, daß sie folgendes verschafft: ein verteiltes Mehrknoten-Datenverarbeitungssystem in einem Land-Fahrzeug mit:
a1. Meßaufnehmermitteln zum Messen mit dem genannten Fahrzeug zusammenhängender physikalischer Größen;
a2. Speicherknotenmitteln zum Speichern physikalisch unterteilter und fester geographischer Datenelemente;
a3. Datenverarbeitungsknotenmitteln zum Verarbeiten der genannten physikalischen Eigenschaften und der genannten geographischen Daten, um Benutzerleitliniendaten zu erzeugen;
a4. Benutzer-E/A-Knotenmitteln zum Empfangen von Anforderungsdaten zur Weiterleitung an einen beliebigen Datenverarbeitungsknoten zur Steuerung der genannten Verarbeitung und zur kontrollierten Weiterleitung der genannten Benutzerleitliniendaten an einen Benutzer;
a5. Benutzer-Eingabelausgabe-Mitteln, die eine Schnittstelle der genannten Benutzer-E/A-Knotenmittel mit Benutzersignalen bilden;
a6. und Netzmitteln, die die genannten Knotenmittel miteinander verbinden, wobei mindestens ein Knoten mit den genannten Meßaufnehmermitteln eine Schnittstelle bildet; und mindestens ein Knoten Anwendungssoftware ausführt; wobei das System die folgenden Einrichtungen hat:
b1. eine Bibliothek aus transferierbaren Systemaufrufen oder Primitiven, mit: open, dose, read, write, seek, getstat, setstat, signal, creat;
b2. ein deterministisches Netzsteuerungssystem zum Bewirken eines eventuellen Netzransports eines Primitivs innerhalb eines vorgegebenen maximalen Zeitintervalls;
b3. eine nachrichtenverarbeitende Organisation, die ausschließlich die Verarbeitung einer vollständig übertragenen Nachricht als einheitliches Ganzes zuläßt;
b4. eine zustandserhaltende Steuerung, um einen eventuellen Dialog zwischen jeweiligen Knoten über den Bus zustandslos zu halten;
b5. ein verteiltes Echtzeitbetriebssystem, um gleichzeitiges Ablaufen einer Vielzahl jewelliger Prozesse zuzulassen, die lokale Verarbeitungsleistung und/oder ein Gerät und/oder Sensor-, E/A- und/oder Datei-Daten gemeinsam nutzen.
Die physikalischen Größen können sich beispielsweise auf die Motortemperatur, Schließen der Tür, Richtung des Erdmagnetfeldes, Anwesenheit anderer Fahrzeuge, Fahrzeuggeschwindigkeit und vieles anderes beziehen. Der Hauptspeicher kann sich auf einem oder mehreren Knoten befinden, als RAM, Platte, Band oder anderes. Das Ergänzen durch veranderliche Daten wie Stau oder lokale Gewitter können vorteilhaft sein, Datenverarbeitung kann auf einem oder mehreren Knoten möglich sein. Benutzer-E/A kann Drucktasten, Sprach-E/A, sichtbare Darstellung, Sperren gewisser Aktivatoren umfassen. Das Netz kann einen oder mehrere Busse umiassen, aber Punkt-zu-Punkt-Verbindungen und andere Organisationsformen könnten ebensogut vorkommen. Bestimmte Knoten könnten mehr als eine der in den Punkten a2, a3 ... genannten Funktionen haben. Die Bibliothek bedeutet, daß das System die Generierung, den Empfang und die Beantwortung dieser Primitiven ermöglicht.
Das deterministische Verkehrsteuerungssystem gemäß dem Vorstehenden kann in einer Vielzahl von Möglichkeiten realisiert werden. Eine sehr einfache Weise ist das Zuweisen einer einzelnen Zeitscheibe an jede voraussichtliche Nachrichtenquellenstation in gleichmäßig umlaufender Folge. Etwas effektiver ist es, zyklische Prioritäten zu stellen, so daß jede Quelle, die keine Anforderung senden will, nahezu unmittelbar übergangen wird. Auch eine Vermittlung zwischen Prioritäten ist eine zulässige Lösung, wenn irgendein Merkmal vorhanden ist, das für Transportmöglichkeiten für Quellen niedriger Priorität sorgt, wie das Erhöhen ihrer Priorität nach einer vorgegebenen Zeitdauer. Diese Steuerungssysteme sind Standardwissen in der Technik von Rechnernetzen.
Der Einheitlichkeitscharakter bedeutet, daß eine Nachricht nur verarbeitet wird, wenn die Übertragung abgeschlossen ist. Im anderen Fall könnte jede Verarbeitungsoperation unterbrochen werden, weil zwischenzeitlich im Netz auftretende Kollisionen oder sogar das Entfernen der ursprünglichen Station der Nachricht die Eingabe- Information dauerhaft und möglicherweise irreparabel unvollständig machen könnten. Im vorliegenden System würde ein solches Entfernen oder Hinzufügen kein fehlerhaftes Funktionieren in einem anderen Knoten bewirken.
Außerdem ist der Dialog zwischen zwei Stationen zustandslos. Das bedeutet, daß, solange eine Nachricht sich in Übertragung befindet, die Stationen ihren Zustand bezüglich dieser Nachricht nicht ändern. Der Quellenknoten wird jede zu der Nachricht gehörende Qperation aussetzen und der Endbestimmungsknoten kann nur in Reaktion auf die einheitliche Nachricht arbeiten, wenn diese vollständig empfangen worden ist. Der Vorteil hiervon ist deutlich, falls die Nachricht nicht in einen Standard- Busrahmen passen würde, was eine nicht vernachlässigbare Verzögerung zwischen dem Senden des ersten Rahmens und dem Empfangen des letzten ergeben könnte.
Durch den Mehrprozessorbetriebscharakter des Netzes, können empfangene Signale oder erzeugte Geräteausgaben unabhängig und gleichzeitig verwaltet werden. Die betreffende Daten-Datei kann sich in den Speichermitteln befinden oder lokal in einem der jeweiligen Prozessoren. Üblicherweise können sich die physikalischen Eigenschaften auf Temperatur, Zündung, Kraftstoffniveau, äußere Bedingungen beziehen. Die geographischen Daten sind datensatz-organisiert und an einer parzellenartigen Organisation der Landkarte orientiert. Es kann einen oder mehrere Datenprozessoren geben. Der Speicher kann ein gesonderter Knoten oder direkt mit einem Prozessor verbunden sein. Benutzer-E/A kann akustisch, LED, CRT mit unterschiedlichen Komplexitätsgraden sein.
Vorteilhafterweise läßt das genannte System Kommunikation zwischen Prozessen auf Basis von Signalen zu. Auch auf der Ebene der Verarbeitung erhöht dies den Grad der Zusammenarbeit.
Vorteilhafterweise läßt der genannte Knoten reversible Kopplung mit einem Massenspeichermedium zu. Optische und andere Massenspeichermedien, vorzugsweise in Plattenform, stellen interessante Lösungen für hohe Speicheranforderungen dar.
Vorteilhafterweise ist das genannte Datenverarbeitungssystem als Mehrbussystem organisiert, in dem mindestens ein Knoten mit mindestens zwei Bussen von jeweils unterschiedlichem Protokoll eine Schnittstelle bildet. Dies erlaubt einfache Schnittstellenbildung mit heutigen Verwaltungssystemen in Autos. Allgemein hat jeder Serverprozeß höchstens eine Warteschlange.
Vorteilhafterweise hat das genannte Datenverarbeitungssystem eine Warteschlangenverwaltung bezüglich eines beliebigen Serverprozesses, die das Vorgeben einer maximalen Zugriffstiefe in der Warteschlange dieses Serverprozesses zuläßt. Dies erlaubt eine flexible Warteschlangenverwaltung.
Vorteilhafterweise hat das genannte Datenverarbeitungssystem einen Serverzuweisungsmechanismus zum automatischen Detektieren einer Notwendigkeit der Generierung eines neuen Serverprozesses. Dies löst reibungslos Konkurrenzprobleme zwischen jeweiligen Benutzerprozessen.
Vorteilhafterweise hat das genannte Datenverarbeitungssystem einen ersten Speicherknoten und Abbildungsmittel zum lokalen Abbilden von mindestens einem Bruchteil des bei dem genannten ersten Speicherknoten vorhandenen Speichers bei einem sich von dem genannten ersten Speicherknoten unterscheidenden, zweiten Knoten. Dies läßt einfachen Speicherzugriff zu.
Die Erfindung betrifft auch ein Datenverarbeitungssystem zur Verwendung als verteiltes Mehrknoten-Datenverarbeitungssystem gemäß dem Vorstehenden. Das System kann allein aus Datenverarbeitung bestehen, d.h. Hardware und Software, aber ohne spezielle Meßaufnehmermittel und Benutzer-E/A-Mittel, die durch die Fahrzeugfunktionalität bestimmt werden, aber nicht durch die reine Datenverarbeitung.
Weitere vorteilhafte Aspekte der Erfindung sind in den Unteransprüchen genannt.

KURZE BESCHREIBUNG DER ZEICHNUNG

Ein bevorzugtes Ausführungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im folgenden näher beschrieben. Es zeigen:
Figur 1 schematisch ein verteiltes Datenverarbeitungssystem und objektorientierte Anwendungsschnittstellen;
Figur 2 Zusammenarbeit zwischen Modulen in einem Fahrzeugnavigationssystem;
Figur 3 ein Beispiel für die Zusammenarbeit zwischen verschiedenen Benutzerprozessen;
Figur 4 die Zuweisung von Serverprozessen;
Figur 5 das Durchlaufen von ARCNET-Paketen;
Figur 6 ein Beispiel für die Struktur einer lokalen Warteschlange;
Figur 7 Prozeß/Weg-Kennung;
Figur 8 eine Erläuterung der momentanen Speicherzuweisung;
Figur 9 das gleiche wie Figur 8 für eine Erweiterungsanforderungswarteschlange.

BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM

Im folgenden wird eine bevorzugte Ausführungsform beschrieben, zunächst hinsichtlich allgemeiner Hardware-Teilsysteme und danach bezüglich seiner allgemeinen Software-Teilsysteme. Danach werden verschiedene vorteilhafte Merkmale der Erfindung im Einzelnen hervorgehoben. Figur 1 zeigt schematisch ein verteiltes Datenverarbeitungssystem und die objektorientierte Anwendungsschnittstelle gemäß der Erfindung. Zur Erläuterung werden zunächst die sieben Ebenen des OSI-Kommunikationsmodells noch einmal kurz betrachtet, nämlich die Bitübertragungs-, die Sicherungs-, die Netzwerk-, die Transport-, die Steuerungs-, die Darstellungs- bzw. die Anwendungsebene, wie folgt:
- die Bitübertragungsebene (physical layer), die Bitströme über die Medien überträgt;
- die Sicherungsebene (data link layer), die Daten zwischen direkt verbundenen Systemen überträgt;
- die Netzwerkebene (network layer), die für das Routing und Vermitteln zwischen Zwischensystemen sorgt;
- die Transportebene (transport layer), die für transparente, fehlerfreie Übertragung von Daten zwischen Endsystemen sorgt;
- die Steuerungsebene (session layer), die den Dialog zwischen kommunizierenden Prozessen organisiert und synchronisiert;
- die Darstellungsebene (presentation layer), die für die Darstellung von Informationen in standardisierter Weise sorgt und
- die Anwendungsebene (application layer), die aus den Schnittstellen und Diensten besteht, die am nächsten beim Benutzer oder einem Anwendungsprogramm liegen, und die den Benutzer mit eigentlichen Netzdiensten versorgt.
All diese Ebenen stellen eine Beschreibung der im Bus oder Netz tatsächlich auftretenden Erscheinungen dar, aber von einem geeigneten organisatorischen Niveau aus gesehen (siehe Computer Design, 15. Februar 1988, S. 511).
Nun ist sich gemäß der vorliegenden Erfindung das verteilte Computersystem nicht des physikalischen Ortes der Hardware bewußt, sondern greift auf alle peripheren Einheiten in gleicher Weise zu. Ob sich eine solche periphere Einheit beim oder bei den Benutzerschnittstellenknoten oder auf dem CD-Spieler befindet, macht keinen Unterschied gegenüber anderen peripheren Einheiten auf der Navigationsplatine.
In Figur 1 stellt jeder Kreis Benutzer-Anwendungssoftware dar, die in einem zugehörigen Prozeß ausgeführt wird. In der Figur sind zwei solcher Anwendungssoftware-Prozeduren oder -Module 24, 26 gezeigt. Funktionsmäßig können sie über die als Paar gestrichelter liinien dargestellte Anwendungschnittstelle 20 miteinander kommunizieren. Das horizontale Paar gestrichelter Unien 22 stellt die Systemschnittstelle dar, die die Schnittstelle zwischen einem beliebigen Anwendungsprozeß mit einem beliebigen Systemprozeß bildet. Physikalisch kommunizieren Anwendungssoftware- Module 24, 26 natürlich über das System, in diesem Fall die Netz- oder Buseinrichtungen. Weitere Rechtecke stellen Systemsoftware-Module dar. Als erstes stellt der Block 28 die Abwicklung aller Anforderungen von den und zu den Anwendungssoftware-Modulen dar. Jede physikalisch lokalisierte Station oder jeder Knoten, der mit dem Netz über eine Schnittstelle verbunden ist, hat ein lokales Betriebssystem 30, 32, 34. Jedes lokalisierte Gerät oder Modul, das direkt (d.h. nicht über das Netz) mit einer der lokalen Stationen kommuniziert, ist durch die jeweiligen Blöcke 36, 38, 40, 42, 44 wiedergegeben, die die zugehörige Software darstellen.
Figur 2, als Hardware-Gegenstück von Figur 1, zeigt die Zusammenarbeit zwischen physikalischen Modulen in einem Fahrzeug-Datenverarbeitungssystem. Es gibt drei wesentliche Stationen, nämlich: Block 50 stellt einen CD-I- oder CD-ROM-Spieler zusammen mit seiner optischen Platte dar. CD-ROM und ähnliche Systeme sind auf dem Markt weit verbreitet. CD-I ist auf optomechanischem Niveau damit identisch; zum Speichern von Bildern sind verschiedene Standards definiert worden, wie z.B. in S. Ropiequet et al., CD-ROM, Optical publishing, Microsoft Press, Redmond, WA, 1987, S. 162/3 beschrieben. Eine solche Platte kann geographische und topologische Kartendaten, Programmdaten, Unterhaltungsdaten, Datenbankinformation, Sprachdaten und anderes enthalten. Block 52 ist der sogenannte Navigationsrechner. Er empfängt, direkt oder über das Netz oder den Bus, Meßaufnehmersignale aus der Sensormenge 54. Dies könnte sich auf einen absoluten oder differentialen Kompaß beziehen, mit den Rädern des Fahrzeugs gekoppelte Odometer, Sensoren für in die Straße eingebaute Signalcodegeber, Temperatur, Kraftstoffniveau, Fehlfunktionssignalisierung oder anderes. Element 56 ist ein Mensch-Maschine-Schnittstellenmodul. Es gibt Benutzerleilliniendaten auf Bildwiedergabeelementen 58 und/oder dem Audiowiedergabe-Element 60 aus. Solche Leitliniendaten können unterschiedlichen Charakter haben. Sie können eine einzelne Leitlinie angeben, und als solche beratende, mahnende, leitende, warnende oder beschimpfende Informationen darstellen. Alternativ können sie eine Auswahl darstellen, wie ein Menü. Weiterhin können sie eine Einadung darstellen, eine offene Wahl zu treffen, wie die Wiedergabe einer Karte, mit einer Vielzahl Parkplätzen, die für ein Fahrzeug frei sind und zwischen denen ein Autofahrer wählen kann. Außerdem empfängt das Schnittstellenmodul 56 Benutzer-Anforderungseingaben vom Eingabeelement 62. Letzteres kann physikalisch eine Taste, eine Tastatur, eine Maus, ein Softtasten- Display oder etwas anderes geeignetes sein. Der Benutzer kann Anforderungssignale eingeben. Diese könnten eine Anforderung für den Zugriff auf eine bestimmte Kartenposition, eine Informationsanforderung, ein Wählersignal, eine Bestätigung oder anderes sein. In bestimmten Fällen, nicht abgebildet, könnte das System physikalische Fahrerausgabe aufweisen, um das Fahrzeug direkt zu anzusteuern, wie Zündungs- oder Lichtsteuerung. Unter der Steuerung der Benutzereingabesignalisierung kann das Mensch- Maschine-Schnittstellenmodul selektiv die Darstellung durch die Elemente 58, 60 steuern. Auch kann es die Weiterleitung von Benutzer-Anforderungssignalen zum Navigationsrechner 52 selektiv steuern, beispielsweise durch Überprüfung der Zulässigkeit oder Ausführbarkeit solches Anforderungssignals. Der Navigationsrechner 52 empfängt Benutzer-Anforderungssignale oder andere Signale auf der Leitung 64, Kartendaten auf der Leitung 66 und Sensordaten auf der Leitung 68. Er kann unter der Steuerung der tatsächlichen Position des Fahrzeugs und vom Benutzer eingegebener Endbestimmungsposition oder Endbestimmungsangabe eine optimale Route für das Fahrzeug planen. Optimierung kann in bezug auf minimale Fahrtdauer, minimale Fahrtstrecke oder irgendein anderes Kriterium stattfinden. Der Navigationsrechner 52 kann auch einen bestimmten Bildschirm in verschiedenen unterschiedlichen Weisen ansteuern, z.B. durch Maßstabsveränderung, Drehung des vorliegenden Bildes, Hervorheben von Karteneinzelheiten, wie Straßennamen oder Tankstellen. Er kann andere Informationen durch Dunkelsteuerung, Öffnen von Fenstern oder Cursorbewegung einfügen. Er kann auszuführende Handlungen berechnen oder ein Menü wiedergeben, aus dem ein Benutzer eines oder mehrere Themen auswählen kann. Die Darstellung in Figur 2 ist jetzt ziemlich schematisch, da nur die Hauptdatenströme wie 64, 65, 66, 67, 68 gezeigt werden. Wie im weiteren erläutert werden wird, können diese Ströme entweder Punkt zu Punkt oder auf einen oder mehre Busse abgebildet werden. Weiterhin könnten bestimmte Funktionen auf einen oder mehrere Knoten abgebildet werden, wie die Mensch-Maschine-Schnittstelle und die Sensoren. Alternativ könnten verschiedene Funktionsblöcke zusammen auf einen einzigen Knoten abgebildet werden. Die Wahl wäre für die Entwickler offen, entsprechend der verfügbaren Hardware und/oder dem geforderten Funktionalitätsniveau.
Nun ist eines der Ergebnisse der Implementierung der vorliegenden Erfindung, daß eine Standardmöglichkeit zum Ergänzen (oder Entfernen) von Hardware eröffnet wird, bei der auf alle Hardware-Einrichtungen von der Anwendungssoftware in nahezu uniformer Weise zugegriffen werden kann. Wenn beispielsweise eine standardmäßig synchrone Verbindung in eine viel schnellere Verbindung abgewandelt würde, würde sich nur die Betriebsgeschwindigkeit erhöhen, aber kein Auftrag würde anders ablaufen. Eine solche Änderung des Systems könnte selbst während des Betriebs (Ablaufs) des Systems erfolgen, ohne daß der Betrieb irgendeiner anderen Station als der der einen oder mehreren direkt betroffenen gefährdet wird. Wenn natürlich eine erste Station die zu einer anderen Station gehörende Hardware oder Software benötigt, würde das Entfernen der zweiten Station den betreffenden Auftrag unausführbar werden lassen, aber da im Prinzip die Möglichkeit der Ausführung gegeben ist, wird diese Ausführung verwirklicht. Das Merkmal, so quer durch das Netz hindurch auf Teildienste zuzugreifen, wird -resource sharing- (gemeinsames Nutzen von Ressourcen) genannt. Die gesamten Mechanismen der Kommunikation zwischen Prozessen von jedem Prozeß auf jedem Knoten zu einem beliebigen anderen Prozeß, gleich ob auf demselben Knoten oder einem anderen Knoten, können verwendet werden, vorausgesetzt, daß die Kommunikationsoperationen von den lokalen Betriebssystemen der beiden beteiligten Knoten unterstützt werden. Wenn das der Fall ist, erzeugen die Transportmechanismen in effektiver Weise ein verteiltes Betriebssystem, das vorteilhaerweise Echtzeitfähigkeit hat. In der Praxis kann ein Benutzerprozeß (Darstellung eines Benutzerprogramms) zu einem zuvor bestimmten Knoten abgegabelt (oder darauf abgebildet) werden, aber durch Senden von Identifikationsinformation kann er auf einen beliebigen anderen Prozeß oder ein anderes Gerät zugreifen. Die hier gegebene Lösung ist unabhängig vom Prozessortyp. Die lokalen Betriebssysteme 30, 32, 34 können von dem bereits erwähnten OS-9/CD- RTOS-System realisiert werden.

FUNKTIONALITÄT

Die Systemebene bietet eine Anzhl allgemeiner Möglichkeiten, wie Prozeßgenerierung, wobei jeder so generierte Prozeß Strecken und/oder Umgebung des generierenden Prozesses erben kann;
- Kommunikation zwischen Prozessen mit Hilfe von Signalen, Semaphoren, Kabeln, Strömen und Paketen;
- Dateioperationen;
- eine Standard-CD-I-Graphik-Schnittstelle;
- und vorzugsweise einen gemeinsam genutzten Speicher (nicht dargestellt) in Figur 2, aber an sich bekannt.
Insbesondere letzteres ermöglicht es, Speicherinformation, die sich physikalisch bei einem anderen Knoten befindet oder einem anderen Knoten zugewiesen ist, lokal abzubilden. Gemäß der bevorzugten Ausführungsform wird der Speicher auf nicht existierenden Raum abgebildet. Ein Zugriff darauf generiert eine Busfehlersignalisierung und daher lokal einen nicht programmierten Sprung (Trap). Daraufhin wird in der Trapdienstroutine der Inhalt des Speichers wie gefordert geholt oder geschrieben. Daher wird dieses Vorgehen nur für solche Prozesse unterstützt, die vollständige Wiederherstellung nach einen Busfehlerzustand ermöglichen. Diese Lösung, obwohl einfach, wird vorzugsweise nur verwendet, wenn das lokale Betriebssystem aus Gründen der Geschwindigkeit und/oder der Systemintegrität keine alternative Lösung für das Problem zuläßt.
Für sich allein genommen könnten verschiedene dieser Möglichkeiten in anderen, bekannten Betriebssystemen gefunden werden, aber die Kombination macht das vorliegende System für eine Verwendung als Betriebssystem-Gateway äußerst geeignet.
Als Beispiel ist die nachfolgende Beschreibung für das CD-RTOS-Betriebssystem speziftziert worden. Eine Übertragung auf andere Betriebssysteme ist einfach. Die vorliegende Erfindung benötigt keine uniforme Benutzer-Schnittstelle; diese können von den Herstellern der verschiedenen für den Benutzer zugänglichen Stationen definiert werden. Die Erfindung schlägt ein Steuerungssystem für eine Kommunikation zwischen Stationen vor, die sich auf der Ebene des Gesamtsystems auswirkt, aber die einzelne Benutzer-Schnittstelle nicht beeinflußt.
Der Zugriff auf entfernt liegende Ressourcen erfolgt jetzt über die gleiche System-Schnittstelle wie der Zugriff auflokale Ressourcen. Der Name des Geräts und die anschiießende Dateispezifikation sind die einzigen Mittel, um festzustellen, ob ein Zugriff ein Fernzugriff oder ein lokaler Zugriff ist. Unter CD-RTOS benennt der dem ersten Schrägstrich folgende Name eines Kennungsausdrucks den den gewählten Manager bestimmenden Deskriptor. Das Abfragen des Rests der Kennung ("identifier", ID) erfolgt durch den letzteren Manager. Wenn zum Beispiel der Name irgendeines Ferndienstes mit /c0/_nodeid_/ beginnt, ist -nodeid- die Nummer des Knotens, an dem sich die Ressource befindet. Die Angabe -c0- ist für das Netz, mit dem der Knoten verbunden ist, einmalig. Jedes Anwendungsprogramm muß jetzt den Ort jedes Teildienstes kennen, den es benötigt. Während einige Ressourcen allgemein an allen Knotenanschlußleitungen verfügbar sind, (ram_disk und so weiter), sind andere Teildienste auf einen bestimmten Knoten beschnkt. Normalerweise werden Geräte durch einen Logik- Namen definiert, der zum geeigneten Zeitpunkt in den echten Namen übersetzt wird. Bei einer Fernprozeßgenerierung bleibt die Schnittstelle auch mit der Standardfunktion identisch, aber dann muß ein Trennsymbol (Schrägstrich) verwendet werden und die Knoten-Kennung (-nodeid-) muß spezifiziert werden. Kommunikation erfolgt durch Verwendung der Gesamtheiten -signals-, -files-, -pipes-, und -packages- in folgender Weise. Signale ("signals") führen elementare Ereignisinformationen zwischen Prozessen. Das allgemeine Informationszeichen ist ein Zwei-Bit-Wort. Jeder Prozeß, der ein Informationssignal empfangen muß, baut einen Signalhantierer auf. Von jedem Knoten können an jedem Knoten Dateien ("files") geöffnet werden und kann auf sie zugegriffen werden. Die Identifikation eines Dateisystems umfaßt die eigene Knotenidentifikation. Rohre ("pipes") sind Kanäle zwischen zwei oder mehr Prozessen zum Übermitteln nicht geschriebener Nachrichten. Pakete ("packages") werden verwendet, um Variable in Prozessen gemeinsam zu nutzen. Jeder Prozeß kann mit dem Paket verknüpft werden.

VERSCHIEDENE ZUSAMMENARBEITSMERKMALE

Figur 3 erläutert schematisch die Zusammenarbeit zwischen verschiedenen Prozessen. Der Kürze halber ist nur der Ablauf der Anforderungen und Antworten dargestellt, nicht der der Lese/Schreib-Daten. In diesem elementaren, aber typischen System gibt es zwei Netze, ein ARCNET-Netz 70 und ein Fahrzeugnetz (Car Area Net: CAN) 2, die beide als Blöcke dargestellt sind. Das CAN ist prinzipiell für durch das System übertragene Nicht-Navigationsinformationsdaten bestimmt. Das System hat drei Knoten, wobei jeder Knoten durch seinen Manager 74, 76, 78 in dem Prozessor des betreffenden Knotens symbolisiert wird. Jeder Knoten benötigt einen gesonderten Netztreiber (80, 82, 84, 86) für jedes Netz, wobei der mittlere Knoten mit beiden Netzen verbunden ist. Weiterhin umfaßt das System Benutzerprozesse 88, 90 und Server 89, 92, 94, 96, 98. Für jedes Netz hat jeder Knoten einen Grundserver. Ein Benutzerprozeß greift auf seinen lokalen Grundserver zu. Ein Grundserver kann notwendigenfalls Teilserver erzeugen und anschließend darauf zugreifen. Nach der Erzeugung von Teilservern kann der Benutzerprozeß anschließend auf einen solchen Teilserver direkt über das Netz zugreifen. Ein solcher Teilserver hat die Datenumgebung seines Erzeugers. Der Benutzerprozeß 88 kann Anforderungen ("requests", REQ) an seinen lokalen Manager 76 senden und von diesem Antworten ("replies" REP) empfangen. Die in sogenannten CAROS-Rahmen (memonisch für CAR Operating System) formatierten Nachrichten werden mit dem geeigneten Treiber (82, 84) übermittelt, der sie an das Netzprotokoll anpaßt. Wenn eine Nachricht von einem Treiber (80, 86) am anderen Ende empfangen wird, weiß letzterer aus dem Inhalt, an welche Server-Warteschlange (91, 100, 102, 106) die Information gesendet werden soll. Jeder Server liest seine eigene Warteschlange aus und führt jedes darin gespeicherte Kommando aus, wobei jede Nachricht auf ein einzelnes Kommando beschränkt ist. Dies bedeutet, daß kein weiteres Kopieren aus einer Warteschlange erforderlich ist, soweit es dem Server direkt vorangeht. Wenn die Ausführung zu einem Ausfall führt, wird dies dem Urheberprozeß signalisiert. Der Server signalisiert sein Ergebnis direkt dem Manager 102 seines Knotens. Anforderungs- und Antwortnachricht enthalten Bezugsinformation, um eine Antwort mit der Anforderung zu verknüpfen, die ursprünglich ihre Ursache war. Der antwortende Manager sorgt für die Antwort und sendet sie an den entsprechenden Treiber. Der Treiber sendet die Antwort zurück zu dem Anforderungsknoten, wo das Weiterleiten von Daten zum Benutzerprozeß abgewickelt wird. Der Manager wird vom Treiber informiert, wenn der Vorgang abgeschlossen ist, und weiß, wann der Benutzerprozeß wieder zu aktivieren ist.
Mit Hinblick auf das Vorstehende sollen im weiteren verschiedene Aspekte eines Servers beschrieben werden. Zunächst kann ein Prozeß an einem spezifizierten Knoten generiert werden. Die vorgesehene System-Bibliothek befaßt sich mit dem Lokalisieren des spezifinerten Knotens, bestimmt, ob dieser lokal oder entfernt ist und führt die entsprechenden Systemaufrufe aus.
Wenn ein Prozeß an einem entfernt liegenden Knoten abgegabelt wird, ist genügend Information für diesen Prozeß vorhanden, so daß er sich als echter Abkömmling verhalten kann, d.h. die richtigen Wege und Umgebung aufweist, wobei er imstande ist, die Prozeß-ID (pid) seiner Abstammung (Eltern) zu bestimmen und eine "pid" an die Abstammung zurückzumelden, die von dieser verwendet werden kann, um Signale an den Abkömmling zu senden.
Der Prozeß der Abgabelung soll durch die folgenden verschiedenen Zustände der Ausführung der Ferngabelungssystemanforderung zum Manager erläutert werden.
1: Der Benutzerprozeß sendet eine Anforderung an den Manager, um einen Prozeß in einem entfernt liegenden Knoten abzugabeln. In der Bibliothek ist festgestellt worden, daß der abzugabelnde Prozeß tatsächlich angefordert ist, um auf einem entfernt liegenden Knoten zu laufen; somit wird der Manager aufgerufen. Die erste Handlung des Bibliothek-Aufrufs ist, einen lokalen "stand-alone"-Server "wegzugabeln", der automatisch alle Wege des Benutzerprozesses erbt, und der nur dazu dient, die Daten zu seinen Wegen hin und von diesen Wegen weg zu kopieren.
2: Die Anforderung wird über ARCNET zum entfernt liegenden Knoten gesendet und bedient. Die zum entfernt liegende Knoten gesendete Nachricht enthält alle Informationen, die notwendig sind, um eine OS-9-Exec-Operation auszuführen, die einem Prozeßgenerierungsaufruf in diesem Knoten entspricht. Der empfangende Grundserver ändert zunächst seine E/A, um die des ursprünglichen Elternprozesses zu wiederzuspiegeln, bevor der Abkömmling abgegabelt wird. Von diesem Augenblick an läuft der Abkömmling mit geerbter E/A und Umgebung ab.
3: Der Abkömmling steigt aus. Wenn der Ablauf des Abkömmlingsprozesses stoppt, wird die lokale Abstammung mittels eines Signals informiert. Dies spezifiziert, wann der Abkömmling abgegabelt war. Der Server reagiert, indem er ein Signal an den Stand-alone-Server in dem Knoten des entfernten Elternprozesses sendet, mit dem er ihn von der Beendigung des Abkömmlings informiert. Der Stand-aloneserver seinerseits informiert die Abstammung und steigt aus. Das von der ursprünglichen Abstammung gesehene Signal spiegelt und deid" und "pid" des Abkömmlings wieder. Dies bedeutet, daß im Falle einer entfernt liegenden Abgabelung vom anfordernden Prozeß nur die erweitere Prozeß-ID des Abkömmlings gesehen wird. Keiner der unterstützenden Prozesse interferiert mit dem ursprünglichen Mechanismus.
Zur Implementation von Kommunikation zwischen Prozessen im Serverprozeß steht für jeden Typ der Kommunikation eine gesonderte Nachricht zur Verfügung.
Signale werden in einfacher Weise abgehandelt. Die Nachricht enthält die folgende Information: Endbestimmungsprozeß-ID, Signalwert und die Prozeß-ID des sendenden Prozesses. Diese letzte Information ist nicht absolut notwendig, aber sehr praktisch, da sie zukünftige Verbesserungen und einfache Fehlersuche ermöglicht. Die Nachricht kann in einen oder mehrere Rahmen passen, die jeder einer Maximallängen- Forderung unterliegen. Wenn die Nachricht nicht in einen einzigen Rahmen paßt, gibt der erste Rahmen die Länge der Nachricht an. Anderenfalls wird nur die notwendige Information gesendet. Die Nachricht wird an den Manager gesendet, der sie an den Grundserver des Endbestimmungsknotens sendet. Der Server sendet sie an den spezifizierten Prozeß.
Die Datei E/A bildet die Basis der meisten verfügbaren Kommunikationsmechanismen. Sie wird in drei Teile unterteilt:
- einen Weg öffnen (open a path)
- Lese-(read), Schreib-(write), und Such-(seek)Operationen, wobei -seek- das Setzen des Dateizeigers auf einen spezifizierten Datensatz beinhaltet
- den Weg schließen (dose the path).
Der -open- -Aufruf hat seine eigene Nachricht. Die Nachricht muß zunächst von dem empfangenden Server verteilt werden. Eine spezielle Funktion, die forward_request genannt wird, sorgt dafür, was anhand von Figur 4 beschrieben wird.
Nachdem die Anforderung bei dem zugewiesenen Server ankommt, wird die -open- -Funktion ausgeführt. Der Serverprozeß ist mit der Standard-E/A-Bibliothek verknüpft, somit ist der zurückgemeldete Wert defmiert. Dieser zurückgemeldete Weg wird mit der Server-ID und der Knoten-ID kombiniert und zum anfordernden Prozeß zurückgesendet.

LESEN UND SCHREIBEN

Lese-, Schreib- und Suchoperationen werden auf einen Weg gerichtet, der wiederspiegelt, zu welchem Knoten und Server die Anforderung versandt werden sollte. Die Manager sowohl am sendenden als auch am empfangenden Knoten kümmern sich hierum. Daher ist eine erneute Wegwahl der Anforderung nicht notwendig. Die Anforderung wird unmittelbar abgehandelt, und die Bytes werden zurückgesendet oder in die Datei geschrieben (oder das Gerät, in welchem Fall eine neue Suchadresse verwendet wird).
-Close- verläuft folgendermaßen. Wenn der Weg existiert, wird der darauffolgende Weg geschlossen. Die lokale Wegnummer wird aus dem Feld in dem Server gelöscht, wodurch Raum für einen neuen Weg generiert wird. Das Feld beherbergt eine Standard-Maximumzahl der erlaubten offenen Dateien. Die im Netzverkehr verwendete Wegnummer ist ein Index in diesem Feld. Normalerweise kann nur ein Prozeß zur Zeit einen bestimmten Server verwenden.
Rohre, Ströme und Pakete werden in gleicher Weise abgehandelt wie Datei-EIA. Da Server von Prozessen beansprucht werden, werden Sackgassen auf verschiedenen Rohren, die von einem einzigen, von vielen anfordernden Prozessen verwendeten Server abgehandelt werden, vermieden. Diese Teildienste gehören zur Kommunikation zwischen Prozessen, aber werden hier wegen ihrer Schnittstelle mit behandelt.
Figur 4 zeigt schematisch die Zuweisung von Serverprozessen an eine Anforderung, beispielsweise eine Dateizugriffsanforderung. Der erste Teil eines solchen Zugriffs ist open_a_path. Dieser Aufruf hat seine eigene Nachricht. Sie wird zunächst von dem empfangenden Server verteilt. Nach der Zuweisung wird die Funktion ausgeführt. Dann wird "read" und/oder "write" auf einen Weg gerichtet, der angibt, zu welchem Knoten und Server die Anforderung gesandt werden muß. Der oder die Manager sowohl an der sendenden als auch an der empfangenden Seite sind hier aktiv. Schließlich schließt die Handlung -close- den Weg, falls er existiert. Anderenfalls wird ein Fehlersignal zurückgesendet. Ob eine Handlung erfolgreich ist oder nicht, wird tatsächlich von der Ablaufzeit-Bibliothek des lokalen Systems bestimmt. Jedenfalls wird beim Schließen die Wegnummer im Server gelöscht. Jetzt, in Figur 4, prüft die Funktion zuerst (110), ob der anfordernde Prozeß Eigentümer des Servers ist, indem eine spezielle Kennung überprüft wird, die die Knoten-Kennung (nid) und Prozeß-Kennung (pid) des anfordernden Prozesses und auch einen Server-Titel ("server handle") umfaßt, der ein spezieller umgebungsbestimmter Kennsatz ist, der z.B. ein gegenwärtig selektiertes Datenverzeichnis angibt. Der Titel gibt auch an, welcher Prozeß der ursprüngliche Eigentümer einer bestimmten Datenumgebung ist. Unter anderem gibt er eine externe oder interne Kanaloperation (chx/chd) an und wird für den Zugriff auf den Server verwendet. Der so erhaltene Informationswert wird im Serverbeschreibungsdatensatz gespeichert. Wenn der Wert korrekt ist, kann die Anforderung aufgenommen werden (112). Ist der Wert nicht korrekt, kann es verschiedene Grade der Fehlanpassung geben. Zunächst (114) wird in der Serverliste überprüft, ob es für diesen Server einen Eigentümerprozeß gibt. Wenn das der Fall ist, wird eine Anforderung für den Server in seine Warteschlange eingegeben und so in der Schwebe gehalten, bis der Server das entsprechende Eiement der Warteschlange (116) erreicht. Wenn nicht, wird überprüft (118), ob die tatsächliche Prozeß-Kennung und Knoten-Kennung sich auf den gegenwärtigen Server beziehen. Falls ja, wird ermittelt, ob ein Titel (120) gefunden werden kann. Wenn das der Fall ist, wird die Umgebung (gewisse Prozeßparameter) kopiert und die Anforderung abgewickelt (122). Falls nicht, wird die Anforderung abgewickelt (124). Wenn das Ergebnis in Block 118 negativ war, wird überprüft (126), ob Prozeß-Kennung und Knoten-Kennung dem Absender der Anforderung auf der Serverliste entsprechen. Falls ja, gehören sie zu einem unterschiedlichen Server, und daher wird die Anforderung zugewiesen: put_request (128). Falls nein, wird überprüft, ob (130) ein Titel gefunden worden ist. Falls ja, wird überprüft (132), ob der Titel mit dem gegenwärtigen Server zusammenhängt. Wenn das der Fall ist, wird ein neuer Server generiert (abgegabelt), wobei der Abkömmling die Umgebung seiner Abstammung erbt, und die Anforderung wird aufgenommen (134). Falls nein, wird die Anforderung dem gewünschten Server (136) zugewiesen. Wenn in Block 130 kein Titel gefunden werden konnte, wird geprüft (138), ob ein leerer Server gefunden werden kann. Falls ja, wird die Anforderung dem betreffenden Server (140) zugewiesen. Falls nicht, wird der vorliegende Server abgegabelt (142), und die Anforderung wird diesem zugewiesen.
Wenn die Knoten-Kennung und die Prozeß-Kennung korrekt sind, aber nicht der Titel, bedeutet das, daß ein neuer Prozeß einen alten Schlitz ("slot") übernommen hat, in dem ein Prozeß mit einem zugewiesenen entfernt liegenden Server ablief. Dann wird der Server dem neuen Prozeß neu zugewiesen, die Serverliste wird nach einem Server mit dem gleichen Titel als der anfordernde Prozeß abgefragt. Wenn dieser Server gefunden worden ist, werden seine vorgegebenen Wege zum gegenwärtigen Server kopiert. Der Nachteil ist, daß ein möglicher Abkömmling des früheren Eigentümers noch einen Titel dieses Typs hat und versuchen kann, Fernzugriff auf diese vorgegebenen Wege zu beanspruchen, von denen die ursprünglichen Umgebungsparameter nicht mehr korrekt sind. Dieses Risiko ist jedoch gering. Der umgekehrte Fall (Titel korrekt, aber nicht die Kennungen) ähnelt dem ersten: zuerst wird die Serverliste nach einem Server mit der richtigen Prozeß-ID und Knoten-ID abgefragt. Falls sie gefunden werden, wird die Steuerung wie sooben übertragen. Werden sie nicht gefunden, dann wird ein neuer Server abgegabelt, der die gleichen Wege von seinem Abstammungsserver erbt. Wenn sowohl der Titel als auch die Kennungen nicht korrekt sind, gibt dies deutlich einen Fehlerzustand wieder, da ein neugeborener Prozeß immer einen Titel 0 verwenden wird, der mit dem Grundserver identisch ist. Der Titel sollte daher immer gefunden werden. In diesem Fall wird, falls verfügbar, ein leerer Server zugewiesen, andernfalls wird ein neuer Server abgegabelt. Allgemein befinden sich der Kundenserver und der anfordernde Benutzerprozeß auf unterschiedlichen Knoten.

SYSTEM-SCHLICHTUNGSEINRICHTUNGEN

Das verteilte Betriebssystem umfaßt eine Bibliothek, die bestimmte Standard-C-Bibliothek-Aufrufe teilweise ablöst, und es umfaßt mehrere Serverprozesse. Diese Bibliothek bestimmt aus dem Aufruf, ob die Dienste-Anforderung bei einem entfernt liegenden Knoten im lokalen Netz ausgeführt werden sollte. Falls nicht, wird der Standard-C-Bibliothek-Aufruf ausgeführt. Bei Fernoperation baut der Manager die notwendigen Pakete auf und leitet die auf diese Information weisenden Zeiger zum ARCNET-Treiber, der seinerseits diese Pakete zum entfernt liegenden Host senden wird.
Die ARCNFR-Pakete werden über einen auf eine Tabelle, wie in Figur 5 gezeigt, weisenden Zeiger zum Manager/Treiber geleitet. Die Schreibhandlung wird schlafend gehalten, bis die vollständige Nachricht gesendet worden ist; dies bedeutet, daß die Nachricht einheitlich ist, wie weiter vorn definiert.
Pfeil 150 gibt die Rahmenbeschreibungsdatensatz-Anforderung an den ARCNET-Manager 151 an, wobei er die Status-Einstellung zum Abwickeln der Anforderung, den gesuchten Weg und den Rahmendeskriptor-Zeiger spezifizert. Der Datensatz umfaßt eine Rahmenanzahlangabe 154, eine Antwortzhlung 156, die die erwartete Anzahl Antwortbytes angibt, wobei ein Antwortzeiger 158 auf eine gegenwärtige Adresse im Antwortpuffer 160 weist, und ähnliche Paare aus Zählung und Zeiger hinsichtlich eines einzelnen Kopftahmenraumes 164, null oder mehr Folgerahmenräume 166 und eventuell noch weitere Räume, auf die symbolisch durch den Pfeil oder die Pfeile 168 zugegriffen wird. Antwortdaten werden vom ARCNET entsprechend Pfeil 170 angeboten. Die Zusammensetzung des Kopftahmens wird bei 172 gezeigt: zuerst ein fester Mehrbyte-Teil 174 für den Manager, Treiber oder Server, gefolgt von einer Folge aus einzeln variablen Bytes, die ausschließlich für den Server bestimmt sind. Es gibt drei Arten von Serverprozessen:
1. Weg-dedizierte Serverprozesse (name=descrname+_prc), wobei jedem Prozeß ein dedizierter Serverprozeß zugewiesen ist. Diese Prozesse werden von einem Grundserver generiert, und jeder besteht aus einem Teilserverprozeß mit seiner zugehörigen Benutzerprozeß-Umgebung.
2. Systemaufruf-dedizierter Prozeß. Die beteiligten Aufrufe sind Fernabgabelungen und Fernsignale. Diese Prozesse werden auch von Grundservern generiert. Grundserver selbst sind auch von diesem Typ.
3. Stand-alone-Serverprozesse. Diese fungieren als Darstellung eines entfernten Abkömmlingprozesses. Wenn sie sich auf dem gleichen Knoten befinden wie ihr Eiternprozeß, erben sie die vollständige Umgebung des letzteren. Im Gegensatz dazu hat ein Grundserver keine zugehörige Benutzerprozeß-Umgebung, sondern nur eine vorgegebene Umgebung.
Die empfangenden Prozesse (Weg/Systemaufruf-dediziert) und Standaloneserverprozesse wickeln Warschlangen ab, die von dem Netz gefüllt worden sind. Die Zuweisung eines oder mehrerer Rahmen an eine spezielle Nachricht ist vorste hend beschrieben worden: Der erste Rahmen signalisiert immer die Länge der Nachricht in Rahmen. Nachdem der erste Rahmen gesendet worden ist, erfolgt keine weitere Übertragung, bevor der Absender ein "xon" empfängt. Auf diese Weise steuern Signale "xon" ei (Beginn Ubertragung) und "xoff" (Ende Übertragung) die Übertragung in einfacher Weise.
Figur 6 zeigt als Beispiel die Struktur einer lokalen Waeteschlange. Die Wareschlangen bestehen aus einem Speicherpeol, der Speicherblöcke fester Länge (36 Bytes) enthält. Ein freies Listenfeld 180 zeigt auf die freien Blöcke in Speicher 182. Weiterhin zeigt ein Register 184 auf den Anfang der Warteschlange, während ein zweites Register 186 auf den Anfang des freien Teils der Warteschlange zeigt. Jedes Element der Warteschlange enthält einen Hinweis auf seinen Nachfolger (next) oder eine -0-, wenn es keinen gibt. Für E/A-Anforderungen, die länger sind als die Standard-Rahmengröße von 36 Bytes, führt der Serverprozeß eine Speicherzuweisung zum Erweiterungsraum 188 aus. Nun erfolgt die Warteschlangenverwaltung auf zwei aufeinanderfolgenden Ebenen. Zunächst wird für kurze Nachrichten (die meisten) eine feste Schlitzgröße zugewiesen. Falls für eine bestimmte Nachricht notwendig, wird der zugehörige Schlitz fester Größe mit einem Erweiterungsschlitz verknüpft. Ersterer ist dynamisch implizit mittels eines "xoff"-Protokolls implementiert. Das Holen von Anforderungen oder Anforderungseinheiten erfolgt auf Basis vollständiger empfangener Anforderungen bis zu einer maximalen Tiefe in der Kette, die in einer Anzhl von Schlitzen fester Länge ausgedrückt wird. Insbesondere erhält dies das deterministische Verhalten der Antwortzeit zum Holen von Anforderungen aus der Warteschlange aufrecht, und läßt so deterministische Nachrichtenübertragung zu. Zweitens ermöglicht dies, auf verschiedene Programm-Module wie Daten-Dateien auf verteilter Ebene zuzugreifen.
Vorstehendes ist für kurze Nachrichten erläutert worden. Für jede Nachricht, die länger als 36 Bytes ist, wird der Absender auf ein "xon" vom Serverprozeß warten, das signalisiert, daß sein "malloc" (Speicherzuweisung) erfolgreich war. Der Absender wird dann automatisch die Erweiterungsinformation übertragen. Die nach einem erfolgreichen "creat/open"-Aufruf zurückgemeldete Prozeß-/Weg-Kennung besteht aus einem langen Wort mit 3 getrennten Feldern wie in Figur 7 gezeigt: die Prozeß-Kennung des Serverprozeses (190), die Knoten-Kennung des Endbestimmungsprozesses (192), und die lokalen Weg-/Prozeß-Kennungen (194). Die Anforderungskennung ist als kurzes Wort dimensioniert. Sie ist nur dem ARCNET-Treiber bekannt und wird von dem Serverprozeß transparent weitergeleitet. Insbesondere gibt Bit 1 an, ob der vorliegende Rahmen der letzte ist oder ob einer oder mehrere Rahmens folgen. Bit 2 gibt an, ob dies der erste Rahmen ist oder ob es eln späterer Rahmen einer Mehrrahmen- Nachricht ist. Bits 3, 4 geben an, ob es sich um einen Anforderungsrahmen, einen Antwortrahmen oder einen Steuerungsrahmen handelt. Die letzten 12 Bits (von 16) identifizieren eine spezielle Anforderung, beispielsweise eine Verknüpfungskennung.

WARTESCHLANGENFUNKTIONEN

Im folgenden werden die elementaren Warschlangenfunktionen aufgelistet. Zuerst wird der Funktionsname angegeben. Danach wird er mit Kennung, Operation(en) und Parametern spezifiziert, während abschließend eine kurze Erläuterung folgt:
Creat_queue(nslot)
SRVRQUEP creat_queue(nslot)
int nslots;
BESCHREIBUNG : Erzeugt eine Warteschlange mit anfänglich zugewiesenen "n Schlitzen" ("nslots").
Del_queue(qhdrp)
int de_queue(qhdrp) *qhdrp;
SRVRQUEP qhdrp;
BESCHREIBUNG : Löscht die durch den passierenden Zeiger spezifizierte Warteschlange. Bestimmt für die Verwendung durch Serverprozesse, falls vorhanden.
Put_queue(srvrid,reqhdrp)
int put_queue(srvrid,reqhdrp)
uchar srvrid;
REQ_HEADER *reqhdrp;
BESCHREIBUNG: Fügt einen Datensatz vom Typ REQ_HEADER in die Warteschlange ein, prüft, ob Erweiterung notwendig ist, falls ja, bereitet die Erweiterungswarteschlange vor, ihn zu empfangen.
Get_queue(frmtp,reqhdrp,depth)
int get_queue(frmtp,reqhdrp,depth)
SRVQUEP frmtp;
REQHDRP *reqhdrp;
int depth;
BESCHREIBUNG : Gewinnt den Anforderungskopf ("request header") aus der Warteschlange. Fragt nur erste "Tiefen"-("depth") Warteschlangenelemente auf vollständig empfangene Anforderungen ab. Wenn get_queue eine Anforderung in der Warteschlange detektiert, aus der der Anforderungskopf empfangen ist, die Erweiterungsraum benötigt, wird diese zugewiesen und ein "xon" wird an die Quelle der Anforderung gesendet.
Put_subframe(frmtp,reqid,framep,cnt,interleave)
int put_subframe(frmtp,reqid,framep,cnt,interleave)
SRVRQUEP frmtp;
short reqid;
unsigned char *framep;
int cnt;
int interleave;
BESCHREIBUNG: Füllt einen zu einer durch "reqid" aus bestimmten, durch "framep", "cnt" und "interleave" spezifizierten, Daten identifizierten Anforderung gehörenden Erweiterungsraum unter Verwendung eines statischen sequentiellen Zeigers. Dieser Zeiger ist ein Teil der gesamten statischen Daten des Treibers. Verschränken ("interleave") beschreibt Lückenraum zwischen 2 aufeinanderfolgenden Bytes in dem die gegebenen Daten enthaltenden Puffer.

FORMAT

Operationscodes. Jede Anforderung hat einen Operationscode ("opcode"), der auf eine bestimmte Operation verweist.
Aufrufe. Die von der Warteschlangen-Kommunikationsbibliothek gelieferten Aufrufe werden folgendermaßen aufgelistet: put_queue; put_subframe; creat_queue; del_queue; get_queue; creat_reqidtbl; creat_reqid; del_reqid; get_reqid; del_reqidtbl. Standard-Kopf. Alle Anforderungen werden von dieser Information begleitet, die folgendermaßen aufgelistet wird: reqid, comprising srcnid, destnid; srvrid; und für den ersten Rahmen: reqsize.
Anforderungs-ID-Struktur-Absender. Die Anforderungs-ID wird für den Absender anders verwendet als für den Empfanger, beispielsweise - reqid-; - reply buffer pomter-; - prcid waiting process-; - reply count-, Attribute. Allgemein gibt es drei verschiedene
Arten einer Nachricht:
Anforderung (request) reqid srvrid Größe ipd Typ opcode Anwendung Daten
Antwort (reply): reqid Typ Größe ipd Anwendung Daten
Steuerung (control):
Kopf (Header) reqid crtl Typ
Figur 8 gibt eine momentane Situation der Speicherzuweisung zur Erläuterung der Warteschlangenverwaltung wieder. Die Spalte 210 ganz links gibt allgemeinen statischen Speicher auf Systemebene an. Dieser statische Charakter beinhaltet, daß jeder Prozeß die von ihm benötigten Informationen lokalisieren kann. Im statischen Speicher sind bei Element 212 gespeichert: "locreqidtblp", die Adresse, unter der die Anforderungskennung und der Tabellen-Bytelängen-Zeiger gespeichert sind. Außerdem gibt bei 212 "locsrvrtblp" die Adresse an, unter der der Servertabellen-Bytelängen-Zeiger gespeichert ist. Schließlich gibt "scrnid" die Quellenktioten-Kennung, und "rootsrvid" die Grundserver-Kennung an. Vom Element 212 aus geben jeweilige Zeiger weitere Gebiete an, wie abgebildet. Im Bereich 214 listet die Anforderungskennungstabelle, "reqidtbl", das erste freie ("first free") Wissenstück ("chunk") auf und danach ("next") weitere freie Wissenstücke, die wie angegeben verkettet sind. Danach enthält der erste Anforderungsschlitz die Urheberprozeßkennung ("initiatorpid"), den Antwortpuffer-Zeiger ("up ufp"), die Anzahl verbleibender freier Plätze ("free cnt") und Attribute ("attributes"). Wie gezeigt, setzt sich diese Struktur fort, bis ein letzter Anforderungsschlitz ("last req. siot") erreicht ist. Das Attributfeld kann einen "xon/xoff"-Anzeiger enthalten und einen "lock/unlock"-Anzeiger. Außerdem wird eine Tabelle mit einer Liste aus freien Anforderungskennungen ("list free reqid"), von einer ersten freien Kennung ("first free rid") bis zu einer letzten freien Kennung ("last free rid") gezeigt. Hinsichtlich der Speicherbenutzung bedeuten hell schraffierte Mittel einen erweiterten Bereich ("extended area"), dunkel schraffiert ist ein gefüllter Schlitz ("filled slot"), nicht schraffiert ist ein freier Schlitz ("free slot"). Weiterhin ist Element 216 eine Server-Tabelle, die ein Register der Server-Kennungen aufstellt, indem sie der Warteschlange entstammende Zeiger ("queuedescp") speichert. Element 216 hat einen Zeiger zum Speicherbereich 218, der für einen Nachkommen der Warteschlange bestimmt ist. Darin sind sequentiell gespeichert: der Warteschlangen-Kopf ("queue hdr"), der Leseschlitz-Zeiger ("read slotp"), der Schreibschlitz-Zeiger ("write slotp"), der letzte freie Zeiger ("last freep"), das Gleiche wiederholt für eine Anforderungswarteschlange für Erweiterungsanforderungen 220 (siehe Figur 9), die Anzahl freier Schlitze ("# free slots"), die Anzahl verwendeter Schlitze ("# used slots"), die Anzahl beanspruchter Schlitze ("# slotsclaim") und das Wissenstückattribut ("chunkattr"), das verwendet werden kann, um auf beanspruchte Wissenstücke ("claim-chunk") zu weisen. Element 222 zeigt beispielsweise das Format eines CAROS- Anforderungswissenstücks. Es enthält einen Wissenstückkopf ("chunk hdr"), eine Menge verknüpfter gefüllter Schlitze, durch die Pfeile rechts angedeutet, und eine Menge ebenfalls verknüpfter leerer Schlitze. Auch die Zeiger zum Leseschlitz (Anfang des ersten gefüllten Schlitzes) und Schreibschlitz (Anfang des ersten leeren Schlitzes) und der zweifache Zeiger zum letzten freien Schlitz sind wiedergegeben.
Figur 9 ähnelt Figur 8 in hohem Maße, bis auf die Tatsache, daß sie sich auf eine Warteschlange für Erweiterungsanforderungen bezieht. Die Elemente 210, 216, 218, 222 von Figur 8 haben ihr Gegenstück 210A, 216A, 218A. Block 224 ist das CAROS-Erweiterungsanforderungswissenstück. Er ähnelt stark dem Block 222, bis auf den Erweiterungsblock 226, der teilweise gefüllt (oben) und für den restlichen Teil leer ist. Zeiger 228 zeigt auf ihn.

Bildinschriften

Figur 3:

91, 100, 102, 104, 106: Warteschlange
70: ARCNET
72: CAN
80, 82, 84, 86: Treiber
74, 76, 78: Manager
92, 96, 89, 98: Grundserver
94: Teilserver
88, 90: Benutzerprozeß

Figur 4

110: gegenwärtiger Server = Eigentümer
114: Eigentümer kommt in Serverliste vor
118: "pid-nid" des gegenwärtigen Servers
120, 130: Titel gefünden
126: "pid-nid" gefunden
132: Titel gegenwärtiger Server
138: leerer Server gefunden

Figur 5:

Rahmenbeschreibungsdatensatz-Anforderung
154: Rahmenanzahl
156: Antwortzählung
158: Antwortzeiger
162: Zählung Zeiger
160: für Antwort reservierter Puffer
164, 172: Kopfrahmen
166: Folgerahmen
170: Antwortdaten

Figur 6:

180: Liste freier Blöcke
182: next = Nachfolger; request = Anforderung; extension = Erweiterung
184: Liste gesamte Warteschlange
186: Liste freie Warschlange
188: Erweiterungsanforderung ("malloc" Server)

Figur 8, 9:

210, 210A: statischer Speicher des Netzes
212: siehe im Text!
214: Anforderungskennungstabelle (Einzelheiten siehe im Text)
216, 216A: Servertabelle
218, 218A: Nachkomme der Warteschlange (Einheiten siehe im Text)
220: Anforderungswarteschlange für Erweiterungsanforderungen
222: CAROS-Anforderungswissenstück
226: Erweiterung
(weitere Einzelheiten siehe im Text)

Claims

1. Verteiltes Mehrknoten-Datenverarbeitungssystem in einem Land-Fahrzeug mit:

Meßaulnehmermitteln zum Messen mit dem genannten Fahrzeug zusammenhängender physikalischer Größen;

Speicherknotenmitteln zum Speichern physikalisch unterteilter und fester geographischer Datenelemente;

Datenverarbeitungsknotenmitteln zum Verarbeiten der genannten physikalischen Eigenschaften und der genannten geographischen Daten, um Benutzerleitliniendaten zu erzeugen;

Benutzer-E/A-Knotenmitteln zum Empfangen von Anforderungsdaten zur Weiterleitung an einen beliebigen Datenverarbeitungsknoten zur Steuerung der genannten Verarbeitung und zur kontrollierten Weiterleitung der genannten Benutzerleitliniendaten an einen Benutzer;

Benutzer-Eingabe/Ausgabemitteln, die eine Schnittstelle der genannten Benut zer-E/A-Knotenmittel mit Benutzersignalen bilden;

und Netzmitteln, die die genannten Knotenmittel miteinander verbinden, wobei mindestens ein Knoten mit den genannten Meßaufnehmermitteln eine Schnittstelle bildet; und mindestens ein Knoten Anwendungssoftware ausführt;

wobei das System die folgenden Einrichtungen hat:

eine Bibliothek aus transferierbaren Systemaufrufen oder Primitiven, mit: open, dose, read, write, seek, getstat, setstat, signal, creat;

ein deterministisches Netzsteuerungssystem zum Bewirken eines eventuellen Netzansports eines Primitivs innerhalb eines vorgegebenen maximalen Zeitintervalls;

eine nachrichtenverarbeitende Organisation, die ausschließlich die Verarbeitung einer vollständig übertragenen Nachricht als einheitliches Ganzes zuläßt;

eine zustandserhaltende Steuerung, um einen eventuellen Dialog zwischen jeweiligen Knoten über einen Bus zustandslos zu halten;

ein verteiltes Echtzeitbetriebssystem, um gleichzeitiges Ablaufen einer Vielzahl jeweiliger Prozesse zuzulassen, die lokale Verarbeitungsleistung und/oder ein Gerät und/oder Sensor-, E/A- und/oder Datei-Daten gemeinsam nutzen.

2. Datenverarbeitungssystem nach Anspruch 1, das außerdem Kommunikation zwischen Prozessen auf Basis von Signalen zuläßt.

3. Datenverarbeitungssystem nach Anspruch 1 oder 2, wobei der genannte Speicherknoten reversible Kopplung mit einem Massenspeichermedium zuläßt.

4. Datenverarbeitungssystem nach Anspruch 1, 2 oder 3 und als Mehrbussystem organisiert, in dem mindestens ein Knoten mit mindestens zwei Bussen von jeweils unterschiedlichem Protokoll eine Schnittstelle bildet.

5. Datenverarbeitungssystem nach einem der Ansprüche 1 bis 4, und mit Warteschlangenverwaltung bezüglich eines beliebigen Serverprozesses, die das Vorgeben einer maximalen Zugriffstiefe in der Warteschlange dieses Serverprozesses zuläßt.

6. Datenverarbeitungssystem nach einem der Ansprüche 1 bis 5 und mit einem Serverzuweisungsmechanismus zum automatischen Detektieren einer Notwendigkeit der Erzeugung eines neuen Serverprozesses.

7. Datenverarbeitungssystem nach Anspruch 6, worin der genannte Zuweisungsmechanismus auf eine lokal empfangene Anforderung für eine spezielle Ressource aus einem Benutzerprozeß anspricht, der nicht eher eine Umgebung bezüglich der genannten speziellen Ressource aufrechterhielt.

8. Datenverarbeitungssystem nach einem der Ansprüche 1 bis 7, und mit einem ersten Speicherknoten und Abbildungsmitteln zum lokalen Abbilden von mindestens einem Bruchteil des bei dem genannten ersten Speicherknoten vorhandenen Speichers bei einem sich von dem genannten ersten Speicherknoten unterscheidenden, zweiten Knoten.

9. Datenverarbeitungssystem zur Verwendung als verteiltes Mehrknoten Datenverarbeitungssystem nach einem der Ansprüche 1 bis 8.