DE10018327A1 - Mehrprozess-Anwendungsmanagement - Google Patents

Abstract

Zum Mehrprozeß-Anwendungsmanagement sind Einzelanwendungsmodule (EA) vorgesehen, die jeweils eine eigene graphische Benutzerschnittstelle (GUI) haben. Ein Ein-/Ausgabesteuerungsmodul (EAM) hat Zugriff auf einen Monitor (M) und eine Tastatur (T). Ein-/Ausgabeanforderungen, die die einzelnen graphischen Benutzerschnittstellen (GUI) absetzen, werden vom Ein-/Ausgabesteuerungsmodul (EAM) aufgenommen und abhängig von den Vorgaben eines Konfigurationsmoduls (KM) auf den Monitor (M) bzw. die Tastatur (T) geschaltet. Das Konfigurationsmodul (KM) verwirklicht dabei ein Regelwerk (R), das abhängig vom Betriebszustand der Einzelanwendungsmodule (EA) eine Konkurrenz um die Ressourcen Monitor (M) und Tastatur (T) durch eine Priorisierung löst.

Description

Die Erfindung betrifft ein Mehrprozeß-Datenverarbeitungssystem, bei dem mehrere Einzelanwendungsmodule unabhängig voneinander gleichzeitig arbeiten, die jeweils eine eigene graphische Benutzerschnittstelle zur Ausgabe sowie der Ein­ gabe von Einzelanwendungsdaten an mindestens einer Ein-/Ausgabeeinheit haben. Dabei wird unter "graphischer Benutzerschnittstelle" sowohl eine graphisch aus­ gestattete, visuelle Oberfläche mit Symbolen für verschiedene Funktionen, die mit­ tels einem Zeigegerät aufgerufen werden, als auch eine maskengeführte Eingabe- und Darstellungsstruktur, die ohne Zeigegerät bedient wird, verstanden. Die Erfin­ dung betrifft weiter ein Computerprogramm zur Steuerung des Zugriffs mehrerer Einzelanwendungsprozesse auf mindestens eine Ein-/Ausgabeeinheit.

In modernen Datenverarbeitungssystemen laufen in der Regel mehrere Pro­ zesse gleichzeitig ab. Dies ist insbesondere bei Datenverarbeitungssystemen der Fall, die eine Anlage überwachen oder steuern. Die bei einer solchen Anlagensteue­ rung ablaufenden Prozesse können Datenerfassungs- oder Meßanwendungen, Re­ gelapplikationen, Kommunikationsanwendungen o. ä. sein.

Ein weitbekanntes Beispiel für Datenverarbeitungssysteme, auf denen meh­ rere Prozesse gleichzeitig laufen, sind Personal Computer, auf denen beispielsweise ein Textverarbeitungsprogramm, ein Kommunikationsmodul zum Zugriff auf ein Netzwerk, ein Zeichnungsprogramm, ein Spracherkennungsmodul oder vielfältige andere Prozesse unabhängig voneinander arbeiten können.

Bei solchen Mehrprozeß-Datenverarbeitungssystemen stellt sich regelmäßig das Problem, daß jede Einzelanwendung Zugriff auf eine oder mehrere Ein- /Ausgabeeinheiten oder sonstige Systemresourcen verlangt. Jede Einzelanwendung kann abhängig von seinem jeweiligen Betriebszustand die Aus- oder Eingabe von Einzelanwendungsdaten, d. h. Daten, die der jeweiligen Einzelanwendung zugeord­ net oder für diese von Bedeutung sind, benötigen. Die Einzelanwendungen konkur­ rieren also um Resourcen.

Die Resourcenkonkurrenz zur Ein-/Ausgabe über einen Bildschirm mit Tastatur und eventuell auch Zeigegerät wird üblicherweise so gelöst, daß alle Ein­ zelanwendungen einer gemeinsamen graphischen Benutzerschnittstelle untergeord­ net sind, die den Zugriff auf diese Resourcen regelt. Dies ist blockschaltbildartig in Fig. 2 für die Konkurrenz um eine Ein-/Ausgabeeinheit mit einem Monitor M und einer Tastatur T dargestellt. Die einzelnen Einzelanwendungen EA1 bis EAn sind einer gemeinsamen graphischen Benutzerschnittstelle GUI untergeordnet, die die Darstellung auf dem bzw. den Zugriff auf den Monitor M und die Tastatur T ver­ waltet. Diese graphische Benutzerschnittstelle ist üblicherweise Teil des Betriebs­ systems des Datenverarbeitungssystems. Die Einzelanwendungen müssen also auf das jeweilige Betriebssystem zugeschnitten sein und ihre Anforderung zur Ausgabe bzw. Eingabe von Einzelanwendungsdaten gemäß den Vorgaben der graphischen Benutzerschnittstelle an diese mitteilen.

Dieses Konzept hat den Nachteil, daß eine gewisse Unflexibilität hinsichtlich der Einzelanwendungen dahingehend besteht, daß sie sich bei der Anforderung bzw. Ausgabe von Einzelanwendungsdaten nach der graphischen Benutzerschnittstelle richten müssen. Darüber hinaus möchte man ein Schema vorgeben, nach dem die Ein-/Ausgabeanforderungen der Einzelanwendung gegeneinander priorisiert wer­ den. Ein solches Schema wird üblicherweise als Mensch/Maschinen-Schnittstelle oder MMI bezeichnet. Die Anforderungen der MMI müssen in der Benutzerschnitt­ stelle bereits verwirklicht sein, da diese letztlich die Resourcenkonkurrenz der Ein­ zelanwendungen um Ein-/Ausgabeeinheiten durch Prioritätenbildung regelt. Ände­ rungen entweder auf Seiten der Einzelanwendungen oder auf Seiten der Anforde­ rungen der MMI erfordern damit regelmäßig eine Neuprogrammierung der graphi­ schen Benutzerschnittstelle. Die bekannte Lösung ist deshalb sehr unflexibel auf Hinzufügen oder Ändern von Einzelanwendungen.

Dies ist besonders nachteilhaft bei Mehrprozess-Datenverarbeitungssystemen oder Computerprogrammen, die der Überwachung, Steuerung und Regelung sicher­ heitsrelevanter Komponenten einer Anlage dienen. Bei solchen sicherheitsrelevan­ ten Anlagen, beispielsweise Fahrzeugen, ergeben sich häufig Änderungen bei Einzelanwendungen, da sich durch die stark fortschreitende technische Entwicklung deren Fähigkeiten ständig erweitern. Bedingt durch diese neuen Fähigkeiten ergeben sich auch mitunter Änderungen der Anforderungen der MMI. In solchen Fällen muß man dann entweder die graphische Benutzerschnittstelle relativ aufwendig neu programmieren oder auf die erweiterten Fähigkeiten der Einzelanwendungen ver­ zichten. Andererseits muß gerade bei sicherheitsrelevanten Prozessen oder Anlagen eine vorgegebene MMI strikt eingehalten werden, um Fehlbedingungen auszu­ schließen.

Es ist somit Aufgabe der vorliegenden Erfindung, für ein System mit mehre­ ren Einzelanwendungen die Verwirklichung der Vorgaben einer Mensch/Maschinen-Schnittstelle zu ermöglichen und dabei dennoch größtmögliche Flexibilität bei den Einzelanwendungen zu gewährleisten.

Diese Aufgabe wird durch das in Anspruch 1 definierte Datenverarbeitungs­ system und das in Anspruch 11 definierte Computerprogramm gelöst.

Erfindungsgemäß hat jedes Einzelanwendungsmodul eine eigene graphische Benutzerschnittstelle. Prozesse werden in diesem Zusammenhang ebenfalls als Ein­ zelanwendungsmodule bezeichnet. Mehrere Einzelanwendungsmodule mit ihren jeweiligen graphischen Benutzerschnittstellen sind unabhängig voneinander im Mehrprozeß-Datenverarbeitungssystem vorgesehen. Analoges gilt für das erfin­ dungsgemäße Computerprogramm. Die Resourcenkonkurrenz der einzelnen gra­ phischen Benutzerschnittstellen der Einzelanwendungsmodule bzw. -prozesse um die Ein-/Ausgabe von Daten wird von einem übergeordneten Modul gelöst. Die An­ forderungen auf Ein-/Ausgaben von Einzelanwendungsdaten werden einem Ein- /Ausgabesteuerungsmodul zugeführt, das andererseits an mindestens eine Ein- /Ausgabeeinheit angeschlossen ist. Das Ein-/Ausgabesteuerungsmodul löst die Resourcenkonkurrenz der Einzelanwendungsmodule durch entsprechende Priorisie­ rung des Zugriffes der graphischen Benutzerschnittstellen auf die Ein- /Ausgabeeinheit. Die Priorisierung erfolgt nach Vorgaben eines Konfigurationsmo­ duls, das vorzugsweise ein entsprechendes Regelwerk enthält. In diesem Regelwerk ist festgelegt, wann welche graphische Benutzerschnittstelle eines Einzelanwen­ dungsmoduls Zugriff auf die Ein-/Ausgabeeinheit erhält.

Das Ein-/Ausgabesteuerungsmodul teilt vorzugsweise dem Konfigurations­ modul den Betriebszustand der einzelnen Einzelanwendungen mit. Das Konfigura­ tionsmodul ist dann in der Lage, eine betriebszustandsabhängige MMI in seinem Regelwerk zu verwirklichen. Die vom Regelwerk des Konfigurationsmoduls vorge­ gebene Priorisierung zur Lösung der Resourcenkonkurrenz erfolgt betriebszustands­ abhängig. Dies ist besonders bei der Steuerung, Regelung oder Überwachung si­ cherheitsrelevanter Anlagen von Vorteil, da dann abhängig vom Betriebszustand der Anlage die graphischen Benutzerschnittstellen unterschiedlicher Einzelanwendun­ gen Zugriff auf die Ein-/Ausgabeeinheiten erhalten.

Je nach Ausbildung der Ein-/Ausgabeeinheit oder Ein-/Ausgabeeinheiten kann es möglich sein, mehrere graphische Benutzerschnittstellen gleichzeitig auf die Ein-/Ausgabeeinheiten zu schalten. Dies kann beispielsweise in einer Art Fenster­ technik geschehen. Das Ein-/Ausgabesteuerungsmodul führt dazu die Ein-/Ausga­ beanforderungen einzelner oder mehrerer graphischer Benutzerschnittstellen ent­ sprechend zusammen und sorgt für eine geeignete, den Vorgaben des Konfigurati­ onsmoduls entsprechende Fensterdarstellung. Die Art der Fensterdarstellung wird dabei vom Regelwerk des Konfigurationsmoduls vorgegeben. Das Konfigurations­ modul gibt vor, welches Fenster auf einer Dateneingabe unmittelbar reagiert und welche Fenster sozusagen nur im Hintergrund oder Anzeigemodus zu sehen sind. In diesem Zusammenhang wird auch davon gesprochen, daß ein Fenster bzw. eine graphische Benutzerschnittstelle den "Fokus" auf einem Monitor hat.

Das Zusammenführen mehrerer graphischer Benutzerschnittstellen auf einer Ein-/Ausgabeeinheit ist dann besonders vorteilhaft, wenn diese Ein-/Ausgabeeinheit über programmierbare Funktionstasten verfügt, ähnliches gilt für Zeigegeräte. Sol­ che programmierbaren Funktionstasten sind üblicherweise am Rand eines Bild­ schirms vorgesehen, so daß durch entsprechende Darstellung am Rand des Bild­ schirms die aktuell programmierte Funktion einer solchen Funktionstaste angezeigt wird. Das Ein-/Ausgabesteuerungsmodul sorgt in einem solchen Fall für die entsprechende Programmierung der aktuellen Weiterleitung der Funktionstastenbetäti­ gung an die richtige Einzelanwendung und für die korrekte Darstellung. Dies ge­ schieht natürlich wieder abhängig von den betriebszustandsabhängigen Vorgaben des Konfigurationsmoduls.

Das Mehrprozeß-Datenverarbeitungssystem entfaltet seine Stärken besonders vorteilhaft auf Anlagen, die mehrere Datenverarbeitungsgeräte mit entsprechenden Recheneinheiten aufweisen, welche über Datenkommunikationsleitungen oder ein Netzwerk miteinander verbunden sind. In einem solchen Fall kann man ein Ein- /Ausgabesteuerungsmodul vorsehen, das auf einem Datenverarbeitungsgerät läuft, und die Einzelanwendungsmodule beliebig auf verschiedene Datenverarbeitungsge­ räte verteilen. Ein solcher Aufbau nutzt vorteilhaft die Unabhängigkeit, die die Einzelanwendungsmodule voneinander haben. Kein Einzelanwendungsmodul muß die Existenz anderer Einzelanwendungsmodule berücksichtigen. Alle Einzelanwen­ dungsmodule arbeiten parallel und unabhängig mit ihren jeweiligen graphischen Benutzerschnittstellen nebeneinander und werden erst auf der Basis des Ein- /Ausgabesteuerungsmoduls sowie des Konfigurationsmoduls zusammengeführt.

Optional ist es auch möglich, mehrere Ein-/Ausgabensteuerungsmodule vorzusehen, wobei jedes einer Ein-/Ausgabeeinheit zugeordnet ist. Mittels eines zentralen oder mehreren verteilten, jeweiligen Ein-/Ausgabensteuerungsmodulen zugeordneten Kommunikationsmodulen wird dann festgelegt, welche Einzelanwen­ dung auf welcher Ein-/Ausgabeneinheit und in welchem Umfang aktiv ist. Dies er­ reicht hohe Redundanz, wenn die Konfigurationsmodule so ausgebildet sind, daß bei Ausfall eines oder mehrerer Ein-/Ausgabeeinheiten oder -steuerungsmodule die entsprechenden Einzelanwendungsmodule automatisch geeignet umgeleitet werden.

Etwaige Änderungen der Einzelanwendungsmodule erfordern somit keine aufwendige Neuprogrammierung der graphischen Benutzerschnittstelle. Sie müssen lediglich im Regelwerk des Konfigurationsmoduls berücksichtigt werden. Dieses Regelwerk kann insbesondere im Computerprogramm als leicht überarbeitbare Datenbank ausgebildet werden, die nach Eingabe der aktuellen Ein- /Ausgabeanforderungen der graphischen Benutzerschnittstellen der Einzelanwendungsmodule die aktuelle Priorisierung zur Lösung der Resourcenkonkurrenz liefert.

Trotz dieser völligen Unabhängigkeit der Einzelanwendungsmodule ermög­ licht es das Konzept des Mehrprozeß-Datenverarbeitungssystems dennoch, Daten zwischen den Einzelanwendungsmodulen auszutauschen. Dies geschieht vorteil­ hafterweise über die einzelnen graphischen Benutzerschnittstellen. Das Ein- /Ausgabesteuerungsmodul entnimmt dann den graphischen Benutzerschnittstellen der einzelnen Einzelanwendungsmodule entsprechende Einzelanwendungsdaten und gibt sie als Eingaben den graphischen Benutzerschnittstellen anderer Einzelanwen­ dungsmodule ein, die die entsprechenden Einzelanwendungsdaten der anderen Ein­ zelanwendungsmodule benötigen.

Es ist in einer Weiterbildung aber auch möglich, daß jedes Einzelanwen­ dungsmodul zusätzlich zu seiner graphischen Benutzerschnittstelle auch über eine Datenschnittstelle verfügt, über die ein Austausch von Einzelanwendungsdaten er­ folgt. Diese Datenschnittstellen sind dann an ein Informationsaustauschmodul ange­ schlossen, das ähnlich dem Ein-/Ausgabesteuerungsmodul die Kommunikation der Einzelanwendungsmodule über ihre Datenschnittstellen miteinander regelt. Um auch hier die größtmögliche Unabhängigkeit hinsichtlich der Anzahl oder Ausbil­ dung der Einzelanwendungsmodule zu erreichen, ist es vorteilhaft, die über die Da­ tenschnittstelle ausgegebenen Einzelanwendungsdaten derart im Informationsaus­ tauschmodul aufzubereiten, daß sie um eine Information über das Einzelanwen­ dungsmodul ergänzt werden, von dem sie stammen. Diese so erweiterten Daten werden als Container bezeichnet, der die Adresse des absendenden Einzelanwen­ dungsmodul sowie die Einzelanwendungsdaten enthält. Ein solcher Container kann als Einzelanwendungsdaten auch lediglich die Aufforderung enthalten, gewisse Daten an die Datenschnittstelle des absendenden Einzelanwendungsmoduls zu übermitteln. Das Informationsaustauschmodul verwaltet die erhaltenen Container entsprechend und stellt einem eine Information anfordernden Einzelanwendungs­ modul den die entsprechende Information enthaltenden Container zu.

Die wichtigste Eigenschaft des Ein-/Ausgabensteuerungsmoduls besteht darin, daß es nicht in die Verantwortung der integrierten Anwendungen eingreift. Alle betriebenen Anwendungen bleiben autonom und sind für die Inhalte der durch sie erzeugten Fenster allein und ausschließlich verantwortlich. Dies bewirkt, daß einerseits die Verantwortungen im System getrennt sind und erleichtert zum anderen die Einbindung von bereits bestehenden Einzelanwendungsmodulen in einfacher Weise.

Weiter ergibt dies die Skalierbarkeit des Systems in Bezug auf Art und An­ zahl der integrierten Einzelanwendungsmodule. Die sich hier abzeichnende Fülle an anwendungsspezifischen Ausstattungen des Systems bzw. des Programms mit den verschiedensten Zusammenstellungen von bestehenden und neuen Einzelanwen­ dungsmodulen bzw. -prozessen verlangt nach einer vollständigen Konfigurierbar­ keit: Die Integration von neuen Einzelanwendungsmodulen führt so nicht zu insbe­ sondere programmtechnischem Anpassungsbedarf, sondern wird lediglich durch unterschiedlich konfigurierte Einzel-/Ausgabensteuerungsmodule erreicht.

Vorteilhafte Weiterbildungen der Erfindung sind Gegenstand der Unteransprüche.

Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnung in Ausführungsbeispielen näher erläutert. In der Zeichnung zeigt:

Fig. 1 ein Blockschaltbild einer ersten Ausführungsform eines Mehrprozeß- Datenverarbeitungssystems,

Fig. 2 ein Blockschaltbild eines Mehrprozeß-Datenverarbeitungssystems nach dem Stand der Technik,

Fig. 3 ein detailliertes Blockschaltbild der Fig. 1,

Fig. 4 ein Blockschaltbild für ein weiteres Modul der Ausführungsform der Fig. 3,

Fig. 5 ein Blockschaltbild eines Mehrprozeß-Datenverarbeitungssystems, das auf mehrere Datenverarbeitungsanlagen verteilt ist und

Fig. 6 ein Blockschaltbild einer zweiten Ausführungsform eines Mehrprozeß- Datenverarbeitungssystems.

In Fig. 1 ist eine erste Ausführungsform eines Mehrprozeß- Datenverarbeitungssystems dargestellt. Dieses System weist mehrere Einzelanwen­ dungsmodule EA1 bis EAn auf. Jedes Einzelanwendungsmodul (im folgenden auch als Einzelanwendung bezeichnet) EA hat eine eigene graphische Benutzerschnitt­ stelle GUI. Jedes Einzelanwendungsmodul ist somit mit seiner graphischen Benut­ zerschnittstelle prinzipiell in der Lage, autark zu arbeiten.

Für alle Einzelanwendungsmodule ist ein Monitor M und eine Tastatur T vorgesehen. Jede graphische Benutzerschnittstelle GUI setzt Daten ab, die auf dem Monitor M darzustellen sind und erwartet entsprechende Eingaben über die Tastatur T. Diese Daten werden im folgenden als Einzelanwendungsdaten EAD bezeichnet. Da die Einzelanwendungsmodule EA nichts von der Existenz weiterer Einzelan­ wendungsmodule wissen, besteht eine Resourcenkonkurrenz um den Monitor M und die Tastatur T.

Diese Resourcenkonkurrenz wird durch ein Ein-/Ausgabesteuerungsmodul EAM gelöst. Dieses Ein-/Ausgabesteuerungsmodul EAM empfängt die Einzelan­ wendungsdaten der einzelnen graphischen Benutzerschnittstellen GUI1 bis GUIn und schaltet eine Auswahl davon auf den Monitor M bzw. stellt die entsprechende Verbindung zur Tastatur T her. Wie diese Auswahl erfolgt, wird von einem Konfi­ gurationsmodul KM vorgegeben, das ein Regelwerk enthält. Dieses Regelwerk verwirklicht eine Mensch/Maschinen-Schnittstelle (MMI), die genaue Vorgaben enthält, wann welche Einzelanwendung Zugriff auf den Monitor M und/oder die Tastatur T hat.

Beim Monitor M und der Tastatur T kann es sich um beliebige Ein- /Ausgabeeinheiten handeln. In der vorliegenden Ausführungsform besteht der Mo­ nitor M aus einem Bildschirm und einer Tastatur. Diese Tasten können mit unter­ schiedlichen Funktionen belegt werden und werden im folgenden als Funktionstas­ ten oder "Softkeys" bezeichnet. Die aktuelle den Funktionstasten zugewiesene Funktion wird üblicherweise am Bildschirm geeignet dargestellt.

Das Regelwerk des Konfigurationsmoduls KM bestimmt nun abhängig vom Betriebszustand aller oder einiger Einzelanwendungsmodule EA, welche graphischen Benutzerschnittstellen GUI auf den Monitor M geschaltet werden, und wie die aktuellen Funktionen der Tastatur T zu belegen sind. Dazu wertet das Ein- /Ausgabensteuerungsmodul EAM die von den graphischen Benutzerschnittstellen gelieferten Einzelanwendungsdaten EAD aus. Dabei wird z. B. der Titel eines Fen­ sters, das eine graphische Benutzerschnittstelle darstellen möchte, erfaßt, um den Inhalt des Fensters und daraus den Betriebszustand zu ermitteln.

Gemäß den betriebszustandsabhängigen Vorgaben des Konfigurationsmoduls KM sorgt das Ein-/Ausgabesteuerungsmodul EAM für die entsprechende Durch­ schaltung der Einzelanwendungsdaten der graphischen Benutzerschnittstellen auf den Monitor M, für die entsprechende Programmierung der Tastatur T sowie die entsprechende Darstellung der aktuellen Programmierung auf dem Monitor M.

Da jedes Einzelanwendungsmodul EA über seine graphische Benutzer­ schnittstelle GUI die Einzelanwendungsdaten so ausgibt, als hätte es alleinigen Zugriff auf den Monitor M und die Tastatur T - die Einzelanwendungsmodule EA wissen ja nichts von der Existenz weiterer, parallel und unabhängig arbeitender Ein­ zelanwendungsmodule - muß das Ein-/Ausgabesteuerungsmodul EAM die Einzel­ anwendungsdaten EAD der einzelnen Einzelanwendungsmodule entsprechend auf­ bereiten. Das Ein-/Ausgabesteuerungsmodul EAM vergrößert und verkleinert des­ halb abhängig von den Vorgaben des Konfigurationsmoduls KM die in den Einzel­ anwendungsdaten erhaltene Bildschirmdarstellung und stellt sie in Fenstern auf dem Monitor M dar. Dabei sorgt das Ein-/Ausgabesteuerungsmodul auch dafür, daß ent­ sprechend den Vorgaben des Konfigurationsmoduls der Fokus auf dem Monitor M entsprechend liegt. Unter dem "Fokus" wird dabei verstanden, welche Eingaben über die Tastatur T auf welche Fenster am Monitor M und mithin auf welche Ein­ zelanwendungsmodule EA wirken.

Je nach vorgegebener Fokuslage wird eine Eingabe an der Tastatur T vom Ein-/Ausgabesteuerungsmodul an die graphische Benutzerschnittstelle GUI des ent­ sprechenden Einzelanwendungsmoduls EA weitergeleitet. Die Fokuslage kann vom Konfigurationsmodul KM abhängig entweder von aktuellen Einzelanwendungsda­ ten, die von den graphischen Benutzerschnittstellen GUI1 bis GUIn geliefert werden, oder von den an der Verbindung Einzelanwendung-Benutzerschnittstelle mit­ gelesenen Daten entsprechend beeinflußt werden. Dies ermöglicht ein unmittelbares Reagieren auf Änderung der Betriebszustände der Einzelanwendungsmodule. Das ist besonders vorteilhaft, wenn das Mehrprozeß-Datenverarbeitungssystem eine Anlage steuert. Eine Änderung des Betriebszustandes der Anlage, beispielsweise eine Fehler- oder Gefahrmeldung wird dann auf dem Monitor M entsprechend zur Anzeige gebracht und Eingaben eines Benutzers an der Tastatur T werden an das entsprechende oder die entsprechenden Einzelanwendungsmodule EA weitergeleitet und führen zur gewünschten Anlagensteuerungsbeeinflussung.

In einer Abwandlung des Mehrprozeß-Datenverarbeitungssystems der Fig. 1 kann das Ein-/Ausgabesteuerungsmodul EAM die Einzelanwendungsdaten EAD an der Verbindung des jeweiligen Einzelanwendungsmoduls EA mit seiner graphi­ schen Benutzerschnittstelle GUI mitlesen. Dazu muß man aber in die Anbindung des Ein-/Ausgabesteuerungsmoduls EAM an die Kommunikationsleitungen zwi­ schen den Einzelanwendungsmodulen und ihren graphischen Benutzerschnittstellen eingreifen. Dies ist in Fig. 6 dargestellt. Der Betriebszustand der einzelnen Einzel­ anwendungsmodule EA wird dann vom Ein-/Ausgabesteuerungsmodul EAM am Datenverkehr der jeweiligen Einzelanwendung EA mit der jeweiligen Benutzer­ schnittstelle GUI erkannt.

Die Ausbildung eines Mehrprozeß-Datenverarbeitungssystems nach Fig. 1 ist in Fig. 3 detaillierter dargestellt. Dabei handelt es sich um ein Computerprogramm, das auf einer Datenverarbeitungsanlage läuft, wobei der Einsatz auf einer Zugloko­ motive erfolgt. Module bzw. Prozesse oder Programmblöcke (diese Begriffe werden austauschbar verwendet), die den Modulen der Fig. 1 entsprechen, sind dabei mit den gleichen Bezugszeichen bezeichnet.

Die einzelnen Einzelanwendungsmodule EA1 bis EAn haben in dieser Ausbildung über ihre jeweilige graphischen Benutzerschnittstelle GUI1 bis GUIn hinaus noch eine Datenschnittstelle IM1 bis IMn, auf deren Funktion später noch eingegangen werden wird. Die graphischen Benutzerschnittstellen GUI sowie die Datenschnittstellen IM sind an eine Netzwerkverbindung N angebunden, die beispielsweise als Ethernet ausgebildet sein kann. An dieses Ethernet ist das Ein-/Ausgabesteuerungsmodul EAM angebunden. Statt eines Netzwerks kann auch ein beliebiger anderer Datenaustausch verwendet werden, z. B. auf einem Datenbus in einem Rechner, wenn alle Module in einem einzigen Rechner verwirklicht werden.

In Fig. 3 ist ein normaler Datenaustausch zum Netzwerk bzw. zu Peripheriegeräten mit einem dünnen Doppelpfeil gezeichnet. Datenaustausch von Komponenten, die den Zugriff auf Resourcen regeln, sind mit einem dicken Dop­ pelpfeil bezeichnet.

Die graphischen Benutzerschnittstellen GUI kommunizieren somit über die Netzwerkverbindung N ihre Einzelanwendungsdaten EAD an das Ein- /Ausgabesteuerungsmodul EAM. Zur besseren Übersichtlichkeit sind in Fig. 3 le­ diglich Einzelanwendungsdaten EAD2 an den entsprechenden Doppelpfeilen, die die Verbindung zwischen Netzwerkverbindung N und Einzelanwendungsmodul EA2 symbolisieren, eingezeichnet. Natürlich werden entsprechende Einzelanwen­ dungsdaten von allen Einzelanwendungsmodulen EA1 an die Netzwerkverbindung N abgesetzt und von dieser aufgenommen.

Das Ein-/Ausgabesteuerungsmodul EAM hat Zugriff auf einen Monitor M mit Tastatur T. Bei der Tastatur T handelt es sich hierbei wieder um Folientasten, die am Monitor M angebracht sind und deren aktuell programmierte Funktion auf dem Monitor M dargestellt ist. Dies ist schematisch eingezeichnet.

Das Ein-/Ausgabesteuerungsmodul hat Verbindung zu einem Konfigurations­ modul KM. Dieser Datenaustausch ist mit einem Doppelpfeil mit Doppelstrich symbolisch dargestellt.

Das Mehrprozeß-Datenverarbeitungssystem weist noch ein Schnittstellensteuerungsmodul SSM auf, das den Zugriff auf einen Multiplexer MUX regelt, an den Datenkommunikationsleitungen DL angeschlossen sind. Das noch zu beschreibende Schnittstellensteuerungsmodul SSM entspricht in seiner Funktionalität im wesentlichen dem Ein-/Ausgabesteuerungsmodul, jedoch ist die von ihm verwaltete Resource nicht ein Monitor M oder eine Tastatur T, sondern der Multiplexer MUX mit den Datenkommunikationsleitungen DL.

Weiter ist an die Netzwerkverbindung N noch ein Informationsaustauschmo­ dul IAM angeschlossen, das ebenfalls mit dem Konfigurationsmodul KM in Ver­ bindung steht. Die Funktion dieses Informationsaustauschmoduls wird später noch erläutert.

Das Ein-/Ausgabesteuerungsmodul EAM nimmt von der Netzwerkverbin­ dung N die Einzelanwendungsdaten EAD auf, die die einzelnen graphischen Benut­ zerschnittstellen GUI1 bis GUIn der Einzelanwendungsmodule über die Netzwerk­ verbindung N senden.

Das Ein-/Ausgabesteuerungsmodul EAM schaltet auf beschriebene Art und Weise abhängig von den Vorgaben des Konfigurationsmoduls KM die Einzelan­ wendungsdaten auf den Monitor M und sorgt für eine entsprechende Darstellung der aktuellen Funktion der Tasten der Tastatur T.

Die Einzelanwendungsmodule können dabei auch die Fenstertechnik zur Darstellung verwenden. Dazu definiert das EAM einen sog. Anzeigenzustand, der die Anordnung der Fenster auf dem Monitor M festlegt. Die Steuerung der Anzei­ genzustände erfolgt durch das Ein-/Ausgabesteuerungsmodul EAM. Das EAM steu­ ert zentral die Anzeige der Fenster in Abhängigkeit des jeweiligen Displayzustands und kontrolliert die Übergabe der Tasteneingaben oder der Keys an die Fenster.

Zur Kontrolle der Tasteneingaben werden diese, bevor sie an die entsprechenden Einzelanwendungsmodule bzw. Fenster über das jeweilige Win­ dowmanagementsystem übergeben werden, durch das EAM abgefangen, analysiert und nach den Festlegungen des jeweiligen Displayzustands an die entsprechenden Einzelanwendungsmodule weitergeleitet. Ist zu einem Key ein Anzeigezustands­ wechsel definiert, wird dieser wie im folgenden beschrieben durchgeführt.

Zur Steuerung der Fenster wird ständig überprüft, welche Fenster auf dem Monitor M dargestellt sind. Ein Fenster, das nicht in einem aktuellen Anzeigezu­ stand definiert ist, wird dabei erkannt und sofort in den Hintergrund geschaltet, so daß es nicht sichtbar ist. Wird bei der Überprüfung ein Anzeigezustandswechsel erkannt, so wird durch das EAM der neue Anzeigenzustand aufgebaut, indem alle zum neuen Anzeigenzustand gehörenden Fenster in den Vordergrund und alle nicht zum neuen Anzeigenzustand gehörenden Fenster in den Hintergrund geschaltet werden. Beim Anzeigenzustandswechsel kann dabei an eine oder alle Einzelanwen­ dungungsmodule bzw. Fenster, die zum alten oder neuen Anzeigezustand gehören, ein simulierter Key übergeben werden. Hierdurch ist es möglich, daß sowohl die Einzelanwendungsmodule bzw. das Fenster des alten Anzeigezustandes ihre An­ zeige folgerichtig abschließen und daß die zum neuen Anzeigezustand gehörenden Anwendungen bzw. Fenster folgerichtig starten können.

Das Schalten der Fenster in den Vorder- oder Hintergrund durch das EAM erfolgt dabei ohne jegliche Schnittstelle zu den jeweiligen Einzelanwendungsmo­ dulen sondern über Standardfensterbefehle, wie sie dem Fachmann als "window handles" bekannt sind, die über das Fenstermanagement des Betriebssystems zur Verfügung stehen.

Neben den über die Anzeigezustände gesteuerten Fenstern können auch soge­ nannte freie Fenster verwendet werden. Diese Fenster werden unabhängig vom ak­ tuellen Anzeigezustand stets im Vordergrund gelassen. Ein solches freies Fenster, wie es etwa eine Notrufanzeige im Rahmen einer Zugfunkanwendung sein kann, kann dabei durch kein Einzelanwendungsmodul unterdrückt werden. Ein freies Fen­ ster kann nur durch dasjenige Einzelanwendungsmodul, das es erzeugt hat, auch wieder gelöscht bzw. in den Hintergrund geschaltet werden. Konkurrierende freie Fenster werden über die Prioritätsregelung des Regelwerks behandelt.

Durch das gewählte Verfahren ist keine Schnittstelle und keine Anpassung bei den bereits bestehenden Einzelanwendungsmodulen in Bezug auf die Steuerung ihrer Anzeigenzustände erforderlich, da den Einzelanwendungsmodulen verborgen bleibt, daß ihre Fenster sowie die Keys vom EAM kontrolliert werden. Die Voraus­ setzung dafür ist die Identifizierbarkeit aller Fenster, die vom EAM gesteuert wer­ den, über einen eindeutigen Titel, Fenster, die innerhalb eines definierten Fensters angezeigt werden (child windows), müssen dabei keinen Fenstertitel haben, und müssen auch nicht im Anzeigenzustand definiert sein. Hierdurch wird die Definition von Displayzuständen für den Fall mehrerer Einzelanwendungsmodule EA mit mehreren Fenstern auf ein Minimum reduziert.

Zur Darstellung von Fenstern, die in allen Anzeigezuständen benötigt wer­ den, dient ein Dialogsystem Anwendungsmanager DAS. Über dieses Modul erfolgt die Anzeige und Bedienung eines Meldefelds, die Anzeige der Softkeys sowie die Anzeige eines Menus. Durch die Darstellung der Softkeys über das Modul DAS ist es möglich, daß diese nach dem MMI einheitlich für alle Einzelanwendungsmodule dargestellt werden können, wobei bei Bedarf eine Anwendung weiterhin irge eige­ nen Softkeys anzeigen kann. Die Darstellung der Softkeys erfolgt, wie erwähnt, aus­ schließlich nach dem jeweiligen Anzeigezustand.

Das Konfigurationsmodul gibt dem Ein-/Ausgabesteuerungsmodul EAM, wie anhand von Fig. 1 erwähnt, Regeln R vor. Diese Regeln R werden aus einer Datenbank DB gewonnen, in die die aktuellen Einzelanwendungsdaten EAD der Einzelanwendungsmodule eingegeben werden. Die Datenbank DB ist im einfach­ sten Fall eine Datei mit geeigneten Listen. Die Regeln R sind abhängig vom aktuel­ len Betriebszustand der Einzelanwendungsmodule.

Ähnlich dem Ein-/Ausgabesteuerungsmodul EAM empfängt ein Schnittstel­ lensteuerungsmodul SSM die Einzelanwendungsdaten von der Netzwerkverbindung N. Auch hier handelt es sich bei den Einzelanwendungsdaten EAD um Ein- /Ausgabenanforderungen der Einzelanwendung. Im Unterschied zu den Einzelan­ wendungsdaten EAD, die das Ein-/Ausgabesteuerungsmodul EAM aufnimmt, han­ delt es sich bei den vom Schnittstellensteuerungsmodul SSM aufgenommenen bzw. berücksichtigten Einzelanwendungsdaten EAD nicht um Ein- /Ausgabeanforderungen über einen Monitor M oder eine Tastatur T, sondern um Zugriffsanforderungen auf Datenkommunikationsleitungen DL. Über das SSM werden folgende Schnittstellen zur Verfügung gestellt: CAN-BUS, MV-Bus, se­ rielle Schnittstelle (RS232, RS422), parallele Schnittstelle, Ethernet.

Das Schnittstellensteuerungsmodul SSM enthält wiederum vom Konfigurati­ onsmodul KM entsprechende Regeln R, die die Resourcenkonkurrenz durch Priori­ sierung auflösen. Das Schnittstellensteuerungsmodul SSM leitet dann entsprechend den Regeln R die Ein-/Ausgabeanforderungen der Einzelanwendungsmodule EA an einen Multiplexer MUX, der sie an entsprechende Datenkommunikationsleitungen DL durchschaltet. Natürlich kann auf den Multiplexer MUX auch verzichtet wer­ den, er sorgt lediglich für eine bessere Ausnutzung der zur Verfügung stehenden Datenkommunikationsleitungen DL. Ohne Multiplexer MUX wären die Daten­ kommunikationsleitungen DL direkt an das Schnittstellensteuerungsmodul SSM angebunden.

Auch beim Zugriff auf die Datenkommunikationsleitungen DL ist wieder das Konzept verwirklicht, daß die Einzelanwendungsmodule EA völlig eigenständig arbeiten; d. h., sie haben eigene Schnittstellen zum Zugriff auf Datenkommunikati­ onsleitungen DL. Anstelle direkt auf die Datenkommunikationsleitungen DL zu­ zugreifen, was natürlich in Einzelfällen freigeschaltet werden kann, wird der Daten­ kommunikationszugriff auf die Netzwerkverbindung N umgeleitet und vom Schnitt­ stellensteuerungsmodul SSM entsprechend der Priorisierung des Konfigurationsmo­ duls KM verwaltet.

Jedes Einzelanwendungsmodul EA hat parallel zur graphischen Benutzer­ schnittstelle GUI auch eine Datenschnittstelle IM. Über diese Datenschnittstelle for­ dert das Einzelanwendungsmodul die Eingabe von Daten an bzw. will Daten abset­ zen. Hierbei handelt es sich wieder um Einzelanwendungsdaten EAD, die im reinen Datenaustausch, d. h. ohne Benutzermitwirkung, von den Einzelanwendungsmodu­ len EA kommuniziert werden. Die Einzelanwendungsdaten EAD, die über die Da­ tenschnittstelle IM abgesetzt bzw. aufgenommen werden sollen, unterscheiden sich somit von den Einzelanwendungsdaten EAD, die über die graphische Benutzer­ schnittstelle GUI abgesetzt werden, dahingehend, daß sie nicht zur graphischen An­ zeige bzw. Eingabe durch einen Benutzer gedacht sind. Sie haben deshalb meist ein anderes Datenformat. Prinzipiell handelt es sich aber auch hier um Einzelanwen­ dungsdaten EAD, die das Einzelanwendungsmodul EA absetzt bzw. verlangt, ohne Kenntnis von anderen Einzelanwendungsmodulen zu haben. Das Mehrprozeß-Da­ tenverarbeitungssystem sieht deshalb ein Informationsaustauschmodul IAM vor, das an die Netzwerkverbindung N angeschlossen ist. Neben dem Informationsaus­ tauschmodul IAM sind dabei an die Netzwerkverbindung eine zentrale Datenerfas­ sung ZDE und eine Containerverwaltung CTV an die Netzwerkverbindung N angeschlossen, wie dies in Fig. 4 dargestellt ist. Das Informationsaustauschmodul IAM nimmt alle an die Netzwerkverbindung N von den Datenschnittstellen IM abgesetz­ ten Einzelanwendungsdaten EAD auf. Dabei kann es sich um die Ausgabe von Da­ ten oder die Anforderung zur Eingabe von Daten handeln.

Das Informationsaustauschmodul IAM verpackt die Einzelanwendungsdaten EAD in einen sogenannten Container. Ein solcher Container ist ein Datenformat, das neben den jeweiligen Einzelanwendungsdaten EAD auch noch die Adresse bzw. die Identifizierung des Einzelanwendungsmoduls EA enthält, das die Einzelanwen­ dungsdaten EAD abgesetzt hat. Der Container wird vom Informationsaustauschmo­ dul IAM über die Netzwerkverbindung N an die Containerverwaltung CTV ge­ schickt, die im wesentlichen einen Speicher umfaßt, in dem die jeweiligen Contai­ ner abgelegt sind. Hier werden sie so lange geführt, bis sie abgelaufen oder durch ein Update überschrieben werden. Anwendungen, die eine der genannten Informa­ tionen benötigen, stellen über das Informationsaustauschmodul IAM eine entspre­ chende Anfrage an die CTV.

Setzt ein Einzelanwendungsmodul EA über seine Datenschnittstelle IM nun Einzelanwendungsdaten EAD ab, werden diese von dem Informationsaustauschmo­ dul IAM in einen Container verpackt. Fordert ein anderes Einzelanwendungsmodul EA die Eingabe von Daten an seiner Datenschnittstelle IM an, wird diese Anforde­ rung ebenfalls in einem Container verpackt, der dann als Einzelanwendungsdaten die Eingabeanforderung enthält. Dieser Container wird ebenfalls an die Container­ verwaltung CTV über die Netzwerkverbindung N übermittelt.

Die Containerverwaltung CTV erkennt, wenn ein Container die Eingabe von Daten erfordert, die in einem anderen Container als abgesetzte Einzelanwendungs­ daten enthalten sind. Die Containerverwaltung erstellt dann einen neuen Container, die als Adresse bzw. Information das Zielanwendungsmodul enthält und schickt diesen Container über die Netzwerkverbindung N an das Informationsaustauschmo­ dul IAM. Das Informationsaustauschmodul IAM sorgt dann über die Netzwerkver­ bindung N für die Übermittlung der im Container enthaltenen Daten an die Daten­ schnittstelle des betroffenen Einzelanwendungsmoduls EA.

Durch das Informationsaustauschmodul IAM und die Containerverwaltung CTV ist der Datenaustausch zwischen den Einzelanwendungsmodulen möglich, ohne daß Synchronisationsanforderungen zwischen den Einzelanwendungsmodulen EA erforderlich wären. Diese können somit weiterhin unabhängig parallel arbeiten.

Die zentrale Datenerfassung ZDE ist vorgesehen, um wiederkehrende Grund­ daten, die von mehreren oder allen Einzelanwendungsmodulen EA benötigt werden, direkt in einem Container vorzuhalten. Liefert ein Einzelanwendungsmodul an sei­ ner Datenschnittstelle IM Einzelanwendungsdaten, die im Informationsaustausch­ modul IAM als Grunddaten erkannt werden, so werden diese Grunddaten in der zentralen Datenerfassung ZDE in einem geeigneten Format gespeichert. Ist ein Grunddatensatz, der aus mehreren Einzelgrunddaten verschiedener Einzelanwen­ dungsmodule EA bestehen kann, in der zentralen Datenerfassung ZDE zusammen­ gestellt, wird er allen davon betroffenen Einzelanwendungsmodulen EA übermittelt.

Anstelle oder zusätzlich zum Datenaustausch über die Datenschnittstellen IM und das Informationsaustauschmodul IAM ist es natürlich weiterhin, wie anhand von Fig. 1 beschrieben, möglich, die Datenkommunikation zwischen den Einzelan­ wendungsmodulen EA über die graphischen Benutzerschnittstellen GUI und das Ein-/Ausgabesteuerungsmodul EAM abzuwickeln.

Fig. 5 zeigt in einem Blockschaltbild, daß das beschriebene Mehrprozeß- Datenverarbeitungssystem auch auf mehrere Datenverarbeitungsanlagen PC verteilt sein kann. Im Blockschaltbild der Fig. 5 sind beispielhaft zwei Datenverarbeitungs­ anlagen PC1 und PC2 vorgesehen. In einer Datenverarbeitungsanlage PC1 läuft das Ein-/Ausgabesteuerungsmodul EAM, in der anderen Datenverarbeitungsanlage PC2 das Schnittstellensteuerungsmodul SSM. Der Monitor M und die Tastatur T sind in diesem Beispiel an die Datenverarbeitungsanlage PC1 angeschlossen, die Multiple­ xer MUX an die Datenverarbeitungsanlage PC2. Die beiden Datenverarbeitungsan­ lagen sind über eine Netzwerkverbindung N miteinander verbunden. In den Daten­ verarbeitungsanlagen PC1 und PC2 laufen verteilt die Einzelanwendungsmodule EA1 bis EA4. Die in Fig. 5 dargestellte Verteilung der Module ist rein beispielhaft. Auch muß der Multiplexer MUX nicht an eine einzige Datenverarbeitungsanlage angeschlossen werden, sondern es ist auch möglich, mehrere Multiplexer MUX an verschiedenen Datenverarbeitungsanlagen PC vorzusehen.

Besondere Redundanz wird dann erreicht, wenn das Ein- /Ausgabesteuerungsmodul EAM und das Konfigurationsmodul KM im gesamten Mehrprozeß-Datenverarbeitungssystem für jede Ein-/Ausgabeeinheit einmal vorlie­ gen. Sie können dabei auf beliebige Datenverarbeitungsanlagen PC verteilt werden. Dies gilt wie erwähnt auch ebenso für die Resourcen, auf die die Einzelanwen­ dungsmodule EA zugreifen wollen. Zusätzlich kann man die Datenbank DB so aus­ bilden, daß in jedem Konfigurationsmodul dasselbe Regelwerk R vorliegt, welches so umfassend ist, daß bei Ausfällen einzelner Ressourcen automatisch entsprechend Einzelanwendungen EA umgeleitet werden.

Das der Fig. 5 zugrundeliegende Prinzip erlaubt es somit, die einzelnen Ein­ zelanwendungsmodule bzw. Steuerungsmodule des Mehrprozeß-Datenverarbei­ tungssystems beliebig auf Datenverarbeitungsanlagen PC zu verteilen. Dies gibt große Freiheit hinsichtlich der Wahl des Betriebssystems und bestimmter Geräte­ komponenten. Die einzelnen Datenverarbeitungsanlagen PC müssen lediglich in der Lage sein, über eine Netzwerkverbindung N miteinander zu kommunizieren. Man kann somit die Einzelanwendungsmodule EA unter einem Ein- /Ausgabesteuerungsmodul EAM zusammenfassen, die um eine der mehreren Ein- /Ausgabeeinheiten konkurrieren. Dabei sind beliebige Geräte und beliebige Be­ triebssysteme möglich, beispielsweise Unix-Systeme, Windows NT-Systeme, Ma­ cintosh-Systemen DOS-Systeme, VMS-Systeme usw.

Über ein Watchdogsystem WDS werden die Einzelanwendungsmodule überwacht und ggf. neu gestartet. In Verbindung mit dem Diagnose- und Monito­ ringsystem DMS wird die Verfügbarkeit der Einzelanwendungsmodule durch das WDS Modul wesentlich erhöht. Welche Einzelanwendungsmodule überwacht und bei Ausfall neu gestartet werden sollen, kann dabei über das KM konfiguriert wer­ den. So ist es möglich, daß, wenn z. B. zwei Monitore auf einem Führerstand eines Triebfahrzeuges vorhanden sind, ein erhöhter Ausfallschutz erreicht wird. Fällt ein Monitor aus, so kann überdies über das Modul WDS erkannt und die Anzeige auf den noch funktionierenden Monitor umgeleitet werden, damit das höherrangige Ein­ zelanwendungsmodul weiterhin zur Verfügung steht.

Zur Unterstützung der Fehleranalyse und zur Unterstützung der Betriebsfüh­ rung dient ein Diagnose- und Monitoringsystem, welches aus zwei Modulen, dem Diagnose- und Monitoringsystem DMS und einer Offline-Auswertung OAW be­ steht. Über das Modul DMS werden alle signifikanten Ereignisse sowohl des EAM als auch der Einzelanwendungsmodule EA über den Informationsmanager IM als Meldung übernommen, in eine Protokolldatei gespeichert, und bei Bedarf nach Auf­ forderung ausgegeben, z. B. auf eine Chip-Karte. Dabei kann man zum Begrenzen des Speicherplatzbedarfs die Protokolldateien parametrisierbar begrenzen. Bei Er­ reichen der zugelassenen Dateigröße werden automatisch die ältesten Protokollda­ teien gelöscht. Die ausgegebenen Protokolle können über das Modul OAW auf einem herkömmlichen PC ausgewertet werden. Hierzu stehen über eine Datenbank die folgenden Funktionen zur Verfügung: - Daten z. B. von der Chip-Karte lesen, - Protokolle/Meldungen nach auswählbaren Filterkriterien anzeigen, - Protokollda­ teien verwalten (exportieren, löschen, drucken).

Optional kann schließlich noch ein Benutzerschnittstellenmodul (nicht darge­ stellt) vorgesehen sein, das für Einzelanwendungsmodule EA, die keine eigene, gra­ phische Benutzerschnittstelle haben, deren erforderliche Funktionalität bereitstellt. Dies ist insbesondere vorteilhaft für Einzelanwendungen, die explizit auf ein beste­ hendes Mehrprozeß-Datenverarbeitungssystem der beschriebenen Art hin geschaf­ fen werden. So kann unnötiger Programmieraufwand vermieden werden, da das Be­ nutzerschnittstellenmodul mehrere GUI ersetzt.

Nun wird eine beispielhafte Anwendung des anhand von Fig. 3 beschriebe­ nen Mehrprozeß-Datenverarbeitungssystems in einer Zuglok beschrieben.

Durch technische wie auch ergonomische Gegebenheiten hat eine Zuglok üblicherweise nur einen Monitor, mit daran befindlichen Folientasten, deren Funk­ tion programmiert werden kann. Auf einer Zuglok laufen allerdings unterschiedlich­ ste Einzelanwendungsmodule. So gibt es einen elektronischen Fahrplan, der dem Lokführer anzeigt, welche Geschwindigkeiten bzw. Fahrzeiten für den von dieser Lok gezogenen Zug derzeit vorgeschrieben sind.

Ein anderes Einzelanwendungsmodul EA ermittelt aus einem empfangenen Signal den aktuellen Zugstandort. Bei diesem Signal kann es sich beispielsweise um ein GPS-Satellitensignal oder ein entsprechendes Funksignal aus einem am Gleis verlegten kabelförmigen Sender handeln. Als weiteres Einzelanwendungsmodul läuft eine sogenannte Schadvormeldung, die eventuelle Schäden des Zuges meldet, wobei es sich nicht unbedingt um sicherheitsrelevante Schäden handeln muß. Dies ist nur ein kleiner Ausschnitt aus den in einer Lok ständig laufenden Einzelanwen­ dungsmodulen. Diese Einzelanwendungsmodule EA laufen unabhängig voneinan­ der. Beispielsweise überwacht das Einzelanwendungsmodul EA der Schadvormel­ dung ständig entsprechende Überwachungssysteme auf Schadensmeldungen.

Das beschriebene Konfigurationsmodul KM sorgt nun dafür, daß sicherheits­ relevante Einzelanwendungsmodule EA nach MMI-Vorgaben auf dem Monitor M dargestellt werden. Dabei handelt es sich beispielsweise um den elektronischen Fahrplan. Meldet nun das Schadvormeldungsmodul einen Schaden, so sorgt das Konfigurationsmodul KM dafür, daß eine Schadvormeldung erst dann angezeigt wird, wenn sich der Zug in einem Bahnhof befindet. Dann kann sich der Lokführer dieser Anzeige widmen, ohne von der Beachtung des Fahrplanes während des Fah­ rens der Lok abgelenkt zu sein. Daß der Zug sich in einem Bahnhof befindet, er­ kennt das Konfigurationsmodul KM wiederum an den von der graphischen Benutzerschnittstelle GUI des elektronischen Fahrplanes oder des die positionsbe­ stimmenden Einzelanwendungsmoduls abgesetzten Einzelanwendungsdaten EAD. Optional ist es möglich, daß der Kommunikationsmanager diese Schadenmeldung sofort durchschaltet, wenn sie sicherheitsrelevant ist, was aus der Art der Darstel­ lung, die von der graphischen Benutzerschnittstelle in Form von Einzelanwen­ dungsdaten abgesetzt wird, erkannt wird.

Das Mehrprozeß-Datenverarbeitungssystem ermöglicht somit einen sicheren Betrieb mehrerer, parallel arbeitender Einzelanwendungsmodule EA auf der Lok eines Zuges, wobei durch das in der Datenbank DB des Konfigurationsmoduls KM hinterlegte Regelwerk R sichergestellt ist, daß die Darstellung auf dem Monitor M und die entsprechende Belegung der Tastatur T unter Sicherheits- und Ergonomie­ gesichtspunkten erfolgt und eine vorgegebene MMI eingehalten wird.

Claims (19)

1. Mehrprozeß-Datenverarbeitungssystem mit:

• a) mehreren unabhängig arbeitenden Einzelanwendungsmodulen (EA), die jeweils eine eigene graphische Benutzerschnittstelle (GUI) zur Ausgabe sowie der Eingabe von Einzelanwendungsdaten (EAD) haben,
• b) mindestens einer Ein-/Ausgabeeinheit (M, T), an der die Ausgabe und die Eingabe von Einzelanwendungsdaten (EAD) erfolgen kann,
• c) mindestens einem Konfigurationsmodul (KM), das als Vorgabe festlegt, wann und in welchem Umfang bei einzelnen Einzelanwendungsmodulen (EA) deren graphische Benutzerschnittstelle (GUI) auf der Ein-/Ausgabeeinheit (M, T) aktiv sein soll, und
• d) mindestens einem Ein-/Ausgabesteuerungsmodul (EAM), das die graphi­ schen Benutzerschnittstellen (GUI) eines oder mehrerer Einzelanwendungsmodule (EA) abhängig von der Vorgabe des Konfigurationsmoduls (KM) auf die Ein- /Ausgabeeinheit (M, T) schaltet.

2. Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das Ein-/Ausgabesteuerungsmodul (EAM) von den graphischen Benutzerschnitt­ stellen (GUI) der Einzelanwendungsmodule (EA) Anforderungen zur Ausgabe und/oder Eingabe von Einzelanwendungsdaten (EAD) aufnimmt und an das Konfi­ gurationsmodul (KM) leitet.

3. Datenverarbeitungssystem nach Anspruch 1 oder 2, dadurch gekennzeich­ net, daß das Konfigurationsmodul (KM) ein vorzugsweise als Datei oder Datenbank verwirklichtes Regelwerk (R) enthält.

4. Datenverarbeitungssystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß eine Kommunikation der Einzelanwendungsmodule (EA) untereinander über das Ein-/Ausgabesteuerungsmodul (EAM) erfolgt, indem von der graphischen Benutzerschnittstelle (GUI) eines oder mehrerer Einzelanwendungsmodule (EA) als Ausgabe mitgeteilten Einzelanwendungsdaten (EAD) vom Ein-/Ausgabesteuerungsmodul (EAM) einen oder mehreren Einzelanwendungsmo­ dulen (EA) über deren graphische Benutzerschnittstelle (GUI) als Eingabe einge­ spielt werden.

5. Datenverarbeitungssystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Ein-/Ausgabeeinheit mindestens einen Bildschirm (M) und Eingabetasten (T) aufweist, wobei die Eingabetasten (T) je nach Einzelanwen­ dungsmodul (EA) mit unterschiedlichen Funktion belegbar sind.

6. Datenverarbeitungssystem nach Anspruch 5, dadurch gekennzeichnet, daß die Eingabetasten (T) durch das Ein-/Ausgabesteuerungsmodul (EAM) je nach Vor­ gabe des Konfigurationsmoduls (KM) mit Funktionen der entsprechend aktivierten graphischen Benutzerschnittstelle (GUI) belegt werden.

7. Datenverarbeitungssystem nach einem der vorherigen Ansprüche, gekenn­ zeichnet durch ein Schnittstellensteuerungsmodul (SSM), das an eine oder mehrere Datenkommunikationsleitungen (DL) angeschlossen ist und Zugriffe der Einzelan­ wendungsmodule (EA) auf die Datenkommunikationsleitungen (DL) abhängig von den Vorgaben des Kommunikationsmoduls (KM) schaltet.

8. Datenverarbeitungssystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Vorgaben des Konfigurationsmoduls (KM) abhän­ gig von den Anforderungen der Einzelanwendungsmodule (EA) sind.

9. Datenverarbeitungssystem nach einem der vorherigen Ansprüche, gekenn­ zeichnet durch mehrere Datenverarbeitungsanlagen (PC), auf die die Einzelanwen­ dungsmodule (EA) verteilt sind.

10. Datenverarbeitungssystem nach Anspruch 9, gekennzeichnet durch meh­ rere Ein-/Ausgabeeinheiten (M, T) und ein eigenständiges Ein- /Ausgabesteuerungsmodul (EAM) für jede Ein-/Ausgabeeinheit (M, T), wobei das mindestens eine Konfigurationsmodul als Vorgabe festlegt, auf welches Ein- /Ausgabeeinheit die graphischen Benutzerschnittstellen (GUI) welche Einzelan­ wendungsmodule (EA) aktiv sein sollen.

11. Computerprogramm zur Steuerung des Zugriffs mehrerer Einzelanwen­ dungsprozesse auf mindestens eine Ein-/Ausgabeeinheit (M, T), wobei mehrere unabhängig arbeitende Einzelanwendungsprozesse (EA) vorhanden sind, die jeweils Einzelanwendungsdaten (EAD) über eine eigene graphische Benutzerschnittstelle (GUI) ausgeben oder eingegeben erhalten, welches Programm aufweist:

• a) mindestens ein Konfigurationsmodul (KM), das als Vorgabe festlegt, wann und in welchem Umfang einzelne Einzelanwendungsprozesse (EA) über ihre graphische Benutzerschnittstelle (GUI) auf die Ein-/Ausgabeeinheitr (M, T) zugrei­ fen und
• b) mindestens ein Ein-/Ausgabesteuerungsmodul (EAM), das die Zugriffe eines oder mehrerer Einzelanwendungsprozesse (EA) abhängig von der Vorgabe des Konfigurationsmoduls (KM) an die Ein-/Ausgabeeinheit (M, T) leitet.

12. Computerprogramm nach Anspruch 11, dadurch gekennzeichnet, daß das Ein-/Ausgabesteuerungsmodul (EAM) Anforderungen zur Ausgabe und/oder Ein­ gabe von Einzelanwendungsdaten (EAD) der Einzelanwendungsprozesse dem Kon­ figurationsmodul (KM) eingibt.

13. Computerprogramm nach Anspruch 11 oder 12, dadurch gekennzeichnet, daß das Konfigurationsmodul (KM) ein als Datei oder Datenbank verwirklichtes Regelwerk (R) enthält.

14. Computerprogramm nach einem der vorherigen Computerprogramm-An­ sprüche, dadurch gekennzeichnet, daß eine Kommunikation der Einzelanwendungs­ prozesse (EA) untereinander über das Ein-/Ausgabesteuerungsmodul (EAM) er­ folgt, indem von der graphischen Benutzerschnittstelle (GUI) eines oder mehrerer Einzelanwendungsprozesse (EA) als Ausgabe mitgeteilte Einzelanwendungsdaten (EAD) vom Ein-/Ausgabesteuerungsmodul (EAM) einen oder mehreren Einzelan­ wendungsprozessen (EA) über deren graphische Benutzerschnittstelle (GUI) als Eingabe eingegeben werden.

15. Computerprogramm nach einem der vorherigen Computerprogramm-An­ sprüche, gekennzeichnet durch ein Programmodul, das Betätigungen der Eingabe­ tasten (T) der Ein-/Ausgabeeinheit einliest und von der Betätigung und vom Zugriff der Einzelanwendungsprozesse (EA) auf die Ein-/Ausgabeeinheit (M, T) abhängige Werte an die Einzelanwendungsprozesse (EA) weiterleitet.

16. Computerprogramm nach Anspruch 15, dadurch gekennzeichnet, daß die weitergeleiteten Werte von der Vorgabe des Konfigurationsmoduls (KM) abhängen.

17. Computerprogramm nach einem der vorherigen Computerprogramm-An­ sprüche, gekennzeichnet durch ein Schnittstellensteuerungsmodul (SSM), das an eine oder mehrere Datenkommunikationsleitungen (DL) angeschlossen ist und Zugriffe der Einzelanwendungsprozesse (EA) auf die Datenkommunikationsleitun­ gen (DL) abhängig von den Vorgaben des Kommunikationsmoduls (KM) weiter­ leitet.

18. Computerprogramm nach einem der vorherigen Computerprogramm-An­ sprüche, dadurch gekennzeichnet, daß die Vorgaben des Konfigurationsmoduls (KM) abhängig von den Zugriffsanforderungen der Einzelanwendungsprozesse (EA) sind.

19. Computerprogramm nach einem der vorherigen Computerprogramm-An­ sprüche, dadurch gekennzeichnet, daß auf die die Einzelanwendungsprozesse (EA) auf mehreren Datenverarbeitungsanlagen (PC) laufen.