EP1314070A2

EP1314070A2 - Vorichtung und verfahren zur intergrierten überwachung, steuerung und regelung von komplexen technischen verfahrensabläufen

Info

Publication number: EP1314070A2
Application number: EP01967297A
Authority: EP
Inventors: Markus Gillich; Roland Dirks
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-08-28
Filing date: 2001-08-27
Publication date: 2003-05-28
Also published as: WO2002019044A2; WO2002019044A3

Abstract

Die vorliegende Erfindung betrifft eine Vorrichtung zur integrierten Überwachung, Steuerung und Regelung von komplexen technischen Verfahrensabläufen, wobei sie wenigstens einen Zentralkernel mit jeweils einer integrierten Zugangskontrolle, separater Kontrolle für die Verwaltung von Tasks, Threads, Speicher, Netzwerkkapazitäten und jeweils eine hierarchisch strukturierte Objektbaumverwaltung mit Funktion für die programmgesteuerte oder manuelle Sammlung und Verteilung von Datenelementen, Verwaltung und Kommunikation von Diensten und Zentralkerneln samt zugehörigen Datenstrukturen aufweist.

Description

Vorrichtung und Verfahren zur integrierten Überwachung, Steuerung und Regelung von komplexen technischen Verfahrensabläufen

Die vorliegende Erfindung betrifft eine Vorrichtung und ein Verfahren zur Modellierung, integrierten Überwachung, Steuerung, Regelung und Datenspeicherung von vorzugsweise mehrteiligen Vorrichtungen und komplexen technischen Verfahrensabläufen. Gegenstand der Erfindung ist auch die Verwendung der genannten Vorrichtungen für komplexe technische Verfahrensabläufe.

Es ist bekannt und üblich, in der Prozeßautomatisierung komplexer automatisierter Industrieanlagen zur Bedienung, Beobachtung und Information virtuelle Komponenten von realen Vorrichtungen zu bilden und diese innerhalb einer oder mehrerer vernetzter Datenverarbeitungsanlagen eines verteilten Datenverarbeitungssystems mittels einer übergeordneten Model Istruktur zu einem Gesamtmodell zu verknüpfen. Das entstehende Gesamtmodell bildet dann auf den genannten Datenverarbeitungsanlagen ein Abbild der realen Industrieanlage. Weiterhin ist bekannt, daß durch Kopplung des Modells mit der realen Anlage mit Hilfe von Informationssende- und Empfangsvorrichtungen die technische Anlage bedient und beobachtet werden kann und so ein Steuer- und Regelungssystem für die Industrieanlage entsteht. Weiterhin ist bekannt, daß über Querverweise, die die realen technischen Verknüpfungen der Industrieanlage realisieren, in dem gebildeten Modell entsprechend den technisch/physikalischen Wirkungsflüssen sinnvoll navigiert werden kann. Darüber hinaus ist bekannt, daß über in die Modellstruktur „eingehängte" weitere lokale oder globale Daten (beispielsweise über das Internet) das Steuerungssystem mit ergänzenden Informationen (z.B. Dokumentation) versorgt werden kann. Weiterhin ist bekannt, das solchermaßen gebildete Modelle mittels einer Internetverbindung von beliebigen Standorten in der Welt bedient werden können. Einen entsprechenden Stand der Technik gibt z.B. die Veröffentlichung mit der Nummer DE 19834456 wieder. Als Beispiel für ein verteiltes Daten Verarbeitungssystem mit zentralem Steuerungsbaustein zur Verarbeitung von technischen Prozessen sei auf die Offenlegungsschrift DE 19741959A1 verwiesen.

Die Nachteile des beschriebenen Stands der Technik liegen im wesentlichen in den weitgehend zentralisierten Strukturen begründet. Das gebildete Modell wird aufgrund der vermeintlich einfacheren und übersichtlichen Administration, Sicherheit und Beherrschbarkeit gegenüber vollständig dezentralen Systemen üblicherweise auf nur einer oder wenigen Datenverarbeitungsanlagen gebildet und mit den Aufgaben der Visualisierung, der Bedienung, Beobachtung, der Datenspeicherung, des Informationstransfers und teilweise zusätzlich mit Steuerungs- und Regelungsaufgaben für die gesamte komplexe Automatisierungsanlage belaste. Alle wesentlichen Funktionen werden nur an einem oder wenigen Knotenpunkten angeboten, jedoch nicht an dezentraler Stelle an der Automatisierungsanlage selbst bereitgestellt. Die Skalierbarkeit des Modells wie auch der darauf genutzten Dienste wird durch die technischen Leistungsgrenzen des zentralen Systems stark einschränkt. Die Nachteile der zentralen Knotenpunkte liegen weiterhin darin, daß schnelle und leistungsfähige und damit seht teure Datenverarbeitungsanlagen mit hoher Speicherkapazität benötigt werden. Darüber hinaus ist eine hohe Belastung der Netzinfrastruktur im Bereich der zentralen Datenverarbeitungsanlagen gerade bei schnellen Abtastraten der Überwachung die Folge. Dies macht einen effizienten Einsatz herkömmlicher Systeme auf weit verteilten langsamen Netzen, wie dem weltweiten Internet bei vertretbaren Kosten nahezu unmöglich. Als Beispiel sei die integrierte Überwachung, Steuerung und Regelung mehrerer tausend Windkraftanlagen innerhalb eines virtuellen Großkraftwerks genannt.

Die Ausfallwahrscheinlichkeiten von wenigen hochbelasteten Systemen sind im Vergleich zu vielen dezentralen Systemen deutlich höher. Benötigte Informationen liegen bei zentralisierten Systemen im wesentlichen nur an einigen wenigen Orten, jedoch nicht an den Maschinen vor Ort, wo Sie häufig (z.B. für Regelungsprozesse und bei Wartungs- und Instandhaltungsarbeiten) gebraucht werden. Häufige, eigentlich unnötige Datentransfers sind die Folge. Die Folgen eines Ausfalls zentraler Strukturen sind ungleich höher als bei verteilten Strukturen. Dies beginnt bei der Möglichkeit umfangreicher Datenverluste bei Schäden an Datenträgern reicht über den Ausfall der Erreichbarkeit bei Schäden an der Netzinfrastruktur und kann in den Totalausfall der gesamten Automatisierungsanlage münden, sollten zentrale DV- Strukturen ausfallen oder gewartet werden müssen. Schäden an den zentralen DV-Anlagen müssen dabei nicht nur in den Anlagen selbst begründet liegen, sondern können bei an das Internet angeschlossenen Anlagen auch durch äußere Einwirkungen erfolgen. Häufig wiederkehrende Angriffe unterschiedlichster Art auf große zentrale Webserver mit zum Teil verheerender Wirkung (Totalausfal der betroffenen Systeme) sind im Internet mittlerweile die Regel als die Ausnahme. Komplexe Industrieanlagen mit zentralisierten Datenverarbeitungsfunktionen sind in der gleichen Weise gefährdet, sollten die zentralen Datenverarbeitungsanlagen über das Internet untereinander und mit Benutzern kommunizieren. Weitere Nachteile liegen in der ausschließlich zentralen, sehr arbeitsintensiven und äußerst komplexen Administrierbarkeit großer zentraler Modelle. Eine schnelle und einfache dezentrale Anpassung der Modelle an große strukturelle Änderungen ist durch die zentrale Administration nicht möglich. Das sukzessive Zusammenschalten von mehreren Modellen ist im Allgemeinen ausgeschlossen. Zentrale Modelle ermöglichen auch keine an den jeweiligen Standort angepaßte Informations- und Bedienstruktur (z.B. Global-, Bereichs- und Lokalübersicht) an den technischen Anlagen vor Ort, sondern ermöglichen im Allgemeinen nur eine einzige Standardsicht auf das Modell. Darüber hinaus ist es nicht üblich weitere, dezentral in der Automatisierungsanlage vorhandene DV-Anlagen (z.B. Prozeßsteuerungen) in ein dezentrales, virtuell zentralisiertes Visualisierungs- und Verwaltungsprinzip zu integrieren, sowie Bedien- und Beobachtungsysteme und weitere Dienste für differenzierten Mehrbenutzerbetrieb auszulegen.

Die vorliegende Erfindung hat sich die Aufgabe gestellt, die Leistungsmerkmale des bekannten Stands der Technik auf verteilten Datenverarbeitungsanlagen zu erreichen, bei Vermeidung der oben genannten Nachteile. Darüber hinaus soll die Erfindung zusätzliche Leistungsmerkmale bieten, die den jetzigen Stand der Technik übertreffen und vor allem die Automatisierung und Organisation von verteilten technischen Anlagen in großer Zahl betreffen.

Gegenstand der Erfindung ist eine Vorrichtung zur integrierten Überwachung, Steuerung, Regelung, Analyse und Datenspeicherung von komplexen technischen Verfahrensabläufen basierend auf einzelnen Meß-

Analyse-, Regelungs-, Bedien- und Beobachtungs- und

Speichervorrichtungen.

Gelöst wird diese Aufgabe durch eine Vorrichtung, welche wenigstens einen Zentralkernel mit jeweils einer integrierten Zugangskontrolle, separater Kontrolle für die Verwaltung von Tasks, Threads, Speicher, Netzwerkkapazitäten und jeweils eine hierarchisch strukturierte Objektbaumverwaltung mit integrierter Funktion zur programmgesteuerten oder manuellen Sammlung und Verteilung von Datenelementen, Verwaltung und Kommunikation von Diensten und weiteren Zentralkerneln samt zugehörigen Datenstrukturen aufweist (MetaOS-Knoten). Die Vorrichtung kann räumlich und/oder thematisch zusammengehörige physikalische oder logische Geräte oder weitere Zentralkernel als Client oder Serverdienste des MetaOS Knotens aufweisen, die mit der Objektbaumverwaltung des Zentralkernels bei Bedarf gleichzeitig kommunizieren und mindestens ein Dienst der Vorrichtung kann externe Schnittstellen für Bedienung und Beobachtung des verteilten Datenverarbeitungssystems aufweisen. Die Vorrichtung kann weiterhin darauf ausgestaltet sein, daß ein lokaler Zentralkernel während des Betriebs durch Mountvorgänge um beliebige Datendienste und weitere Zentralkernel bei Bedarf erweitert wird und beliebige Datendienste und weitere Zentralkernel bei Bedarf entfernt werden. Weitere externe Zentralkernel und die Dienste eines Zentralkernels weisen den jeweiligen propretären Einzelvorrichtungen zugeordnete und normierte, hierarchisch strukturierte Objektbäume auf. Die Objektbäume der Dienste oder deren Teile werden der Objektbaum Verwaltung des Zentralkernels an beliebigen Stellen zugeordnet (gemountet) und über einen optional programmgesteuerten, auf Reihenfolgen, Prioritäten, Filtern und Operatoren basierenden Projektionsverfahren zu einem resultierenden Objektbaum mit Elementen, welche aus Objekten mehrerer Dienste kombiniert werden, zusammengefügt (synchronisiert) und gespeichert. Jedes Element der Objektbäume von Diensten und Zentralkerneln kann dabei aus einem beliebigen Datenobjekt und optional einer beliebigen Anzahl dem Datenobjekt zugeordneter Metadatenobjekte bestehen und jedem Daten- und Metadatenobjekt ein hierarchisch strukturierter Baum von Headerdatenobjekten zugeordnet sein. Alle Objektbaumelemente aller Datendienste, Zentralkernel und Headerdatenobjekte der verteilten Datenverarbeitungsanlage weisen dabei immer eine identische Grundstruktur auf.

Objekte, Metadatenobjekte und Headerdatenobjekte eines Elements des Zentralkernels können weiterhin in beliebiger Kombination mit dem grundlegenden Projektionsverfahren aus den Diensten des Zentralkernrels und aus weiteren Zentralkerneln in das Element projiziert werden Die Headerdatenobjekte jedes Daten-, und Metadatenobjekts eines Zentralkernels können Timinginformationen zur Synchronisation, Informationen zu Ressourcen des lokalen Standorts (CPU, Speicher, Netzwerkkapazitäten), Log- und Fehlerinformationen, Informationen zur Benutzerverwaltung und Authentisierung, Sicherheit, Transport-, Popularitäts- und Prioritätseigenschaften und Zustand des Datenobjekts, sowie vollständige Informationen über Art und aktuellen Zustand der Bedien- und Beobachtungsvorrichtungen sowie

Beschreibungsinformationen zu den Objekten und zusammengefaßte Informationen über hierarchisch tiefer liegende Objektstrukturen enthalten, welche aus verschiedenen spezialisierten Datendiensten und weiteren Zentralkerneln in eine gemeinsame Headerobjektstruktur des Elements gemountet und projiziert werden.

Die gleichen Informationstypen der Headerdatenobjekte von beliebigen Zentralkerneln können außerdem durch Mounten, und programmgesteuerte Synchronisation auf ein gemeinsames Headerdatenobjekt projiziert werden.

Daten-, Metadaten- oder Headerdatenobjekte von Objektbäumen, welche von unterschiedlichen Datendiensten und weiteren Zentralkerneln an die gleiche Stelle im Objektverzeichnis des Zentralkernels gemountet werden, können unter Anwendung von Projektionsprioritäten und syntaktischen, semantischen, logischen und numerischen programmgesteuerten Filtern und Operatoren mit dem Zentralkernel synchronisiert und gespeichert werden. Schließlich können beliebige Objekte, Elemente und Teilstrukturen eines Zentralkernels mit beliebigen Objekten, Elementen und Teilstrukturen weiterer lokaler Datendienste, Bedienschnittstellen oder Zentralkernel und mit beliebigen Objekten, Elementen und Strukturen des eigenen Zentralkernels mit Hilfe einer für alle Besen reibungs- und Kommunikationsvorgänge zwischen Objekten, Elementen und Strukturen einheitlichen Kommandsprache gemountet, gefiltert, mit Operatoren verknüpft und synchronisert werden. Bei Bedarf werden Daten-, Metadaten- und Headerdatenobjekte hierarchisch übergeordneter wie auch untergeordneter Baumelemente können durch Angabe relativer Mountmarken gemountet und synchronisiert.

In jedem Zentralkernel der Datenverarbeitungsanlage wird weiterhin ein Index von synchronisierten Objektverzeichnissen, Datenobjekten und Metadatenobjekten angelegt.

Gegenstand der Erfindung ist auch Verfahren zur integrierten Überwachung, Steuerung, Regelung, Analyse und Datenspeicherung von vorzugsweise mehrteiligen komplexen technischen Vorgängen durch beliebige Teilnehmer der verteilten Datenverarbeitungseinrichtung wobei Einzelinformationen, Informationslisten und hierarchisch organisierte Informationsstrukturen aus Daten-, Zustands-, und Funktionsschnittstellen der einzelnen Meß-, Analyse-, Speicher-, Regelungs-, Bedien- und Beobachtungsvorrichtungen und aus Zentralkerneln durch programmgesteuerte Informationsprojektion nach Bedarf in den jeweiligen Objektbäumen der zugeordneten Dienste gekapselt werden. , Erfindungsgemäß können beliebige den Zentralkernel mountende Dienste und weitere Zentralkernel über die in den Zentralkernel projizierten und gespeicherten Informationen aus allen dem Zentralkernel sowie dem Global- und Regionalverzeichnis zugeordneten Vorrichtungen, lesen, beobachten und analysieren und über den entgegengesetzen Vorgang mit Informationen beschreiben und auf diese Weise bedienen, beobachten und regeln.

Weiterhin kann jedes Datenobjekt und Metadatenobjekt eines Datendienstes oder Zentralkernels durch programmgesteuerte Synchronisation zeitveränderliche Informationen aus den technischen Vorrichtungen kapseln

Die programmgesteuerte Synchronisation von Objektstrukturen und Objekten kann durch Scheduler in den Datendiensten gesteuert werden, welche ihre Timinginformationen den Headerdatenobjekten der Ojektbäume entnehmen. Ausgehend von einem anfänglich einzelnen Zentralkernel kann eine logisch verknüpfte Hierarchie von Zentralkerneln aus verteilten Objektbeständen gebildet werden, so daß jeder Zentralkernel der Hierarchie jeweils Zugriff auf einen resultierenden, einheitlich globalen, einem jeweils unterschiedlichen regionalen und einen lokal privaten Objektbaum aus dezentralen Diensten und Elementen erhält, indem jeder Knoten ein Mountschema bildet, so daß jeder Knoten lokale Datendienste in ein lokales privates sowie ein lokales öffentliches Verzeichnis synchronisiert, ein festgelegtes Globalverzeichnis des hierarchisch höherliegenden Verzeichnis an das Wurzelelement seines eigenen Zentralkemel mountet und synchronisiert und öffentliche lokale Objektbestände an die öffentlichen Objektbestände des übergeordneten Knotens im lokalen Globalverzeichnis mountet und synchronisiert und öffentliche regionale Objektbestände der untergeordneten Knoten an den eigenen regionalen Objektbaum mountet. Zusätzlich synchronisert jeder Zentralkernel Datenbestände des virtuellen Zentrums und Datenbestände weiterer Zentralkernel und simuliert mit diesen synchronisierten Datenbständen zeitweise inaktive ausgefallene Zentralkernel für den Zeitraum des Ausfalls. Weiterhin mountet und synchronisiert zur Erhöhung der Strukturstabilität bei Bedarf jeder Zentralkernel im Netz aus einer nur logisch zusammenhängender Gruppe von Zentralkerneln alle Verzeichnisse aller anderen Zentralkernel der Gruppe in einem für die gesamte Gruppe festgelegten Bereichsverzeichnis und bildet mit diesen so eine „Symbiose" Weiterhin können erfindungsgemaß in den Headerobjekten von Diensten dezentral gelagerte Timinginformationen zur Synchronisation, Informationen zu Ressourcen des lokalen Standorts (CPU, Speicher, Netzwerkkapazitäten), Log- und Fehlerinformationen, Informationen zur Benutzerverwaltung und Authentisierung, Sicherheit, Transport-, Popularitäts- und Prioritätseigenschaften und Zustand der Datenobjekte, sowie Informationen über Art und Zustand der Bedien- und Beobachtungsvorrichtungen sowie Beschreibungsinformationen zu den Objekten und zusammengefaßte Informationen über hierarchisch tiefer liegende Objektstrukturen in jeweils eigene private Verzeichnisse, regionale Bereichsverzeichnisse und für alle Zentralkernel immer einheitliche Globalverzeichnisse synchronisiert werden. Änderungen von Datenobjekten, Metadatenobjekten und Headerdatenobjekten in den Objektbäumen von Datendiensten und Zentralkerneln können in den Headerdatenobjekten der jeweiligen Elemente vermerkt werden und der Änderungsvermerk sukzessive an hierarchisch übergeordnete Objekthierarchien übermittelt werden und hierarchisch untergeordnete Objekthierarchien können regelmäßig nach Änderungsvermerken in hierarchisch höheren Elementen nachfragen, so daß Objekt- und Elementveränderungen in allen globalen, regionalen und privaten Objektbaumverzeichnissen bemerkt werden. Gegenstand der Erfindung ist auch eine Vorrichtung zur Bedienung und Beobachtung, welche formell dadurch gekennzeichnet ist, daß eine Gruppe zwei-, oder dreidimensionaler, interaktiver in einem zwei- oder dreidimensionalen Gebiet liegender Komponenten einer grafischen Benutzerschnittstelle a- .. a_m, bestehend wiederum aus Mengen br..bm- von an lokalen und dezentralen Orten generierten zwei- oder dreidimensionalen interaktiven grafischen Benutzerschnittstellen, in der jede Benutzerschnittstelle der Menge b eine für Sie selbst spezifische zugehörige Menge cL.cn grafischer Basiselemente sowie optional eine Menge an frei definierbaren grafischen Zusatzelementen enthält und die Gestaltung mindestens eines der Basiselemente jeder Mengen c derart ist, daß mindestens eine weitere grafische Benutzerschnittstelle vom Typ der Mengen a oder b oder mindestens eine Benutzerschnittstelle mindestens eines Elements der Menge an Benutzerschnittstellen b in einem Teilgebiet von c vollständig abgebildet werden kann, und die Elemente der Mengen a und b als externe Bedien- und Beobachtungsschnittstellen der Elemente eines oder mehrerer Datendienste im verteilten Daten Verarbeitungssystem dienen, indem Daten durch die Schnittstellen aus dem Datendienst synchronisert und präsentiert werden. Mindestens eines der Basiselemente jeder Mengen c stellt dabei eine eigene Bedien- und Beobachtungsoberfläche mit Objektexplorer, einer Objektleiste ausgewählter Objekte und einer Visualisierungsoberfläche für Objekte dar.

Vorzugsweise können die Verzeichnisstrukturen, Datenobjekte, Metadatenobjekte und Headedatenobjeke und Indizes, die zwischen den Objektbäumen ausgetauscht werden verschlüsselt werden und auf Anforderung auch die Übertragungskanäle während der Übertragung verschlüsselt werden.

Die Erfindung dient dazu, eine sich dynamisch ändernde Vielzahl von unterschiedlichen verteilten technischen Vorrichtungen, Ereignissen, und zugeordneten Dokumenten und Anwendungen zu einer strukturierten, technisch organisatorischen Einheit (der verteilten

Datenverarbeitungsanlage) effizient zu verschmelzen und diese Einheit sicher, effizient und dynamisch zu organisieren, administrieren und programmgesteuert wie auch manuell technisch und organisatorisch zu optimieren. Darüber hinaus werden mittels zugeordneter dezentral generierter virtueller Vorrichtungen technische Vorrichtungen und zugehöriger Dokumente, sowie Mischformen aus beiden effizient visualisiert, verwaltet und unter Anwendung von programmgesteuerten technischen (Aufbringen mechanischer Kräfte, Beeinflussung von Strömen und technischer Steuereinrichtungen etc..) und nichttechnischen Maßnahmen beeinflußt. Die Erfindung bildet alle grundlegenden Anforderungen an verteilte reale technischer Vorrichtungen in einem virtuell zentralisierten Modell beliebiger verteilter logisch zusammengehöriger Informationen mittels eines einzigen grundlegenden Verfahrens ab und dient der Modellierung, Administration, Bedienung und Beobachtung der Steuer- und Regelungstechniken dieser Vorrichtungen inklusive der optimierten Organisation, Kommunikation und Verteilung von Dokumenten, die für die optimale Funktionsweise der realen Vorrichtung notwendig sind. Die Erfindung dient insbesondere der sicheren vereinheitlichen Beeinflussung und Kontrolle verteilter technischer Prozesse z.B. einer großen Menge global verteilter Automatisierungsanlagen (z.B. verteilte Industrieanlagen, Windparks, thermische und elektrische Solarzellen, Blockheizkraftwerke, Biogasanlagen, Kohlekraftanlagen, Ölkraftanlagen, Gasturbinenanlagen, Kernkraftanlagen, Brennstoffzellenanlagen Wasserkraftanlagen und andere Energieversorgungsanlagen, auch im gemischten Betrieb, für Mobilfunktstationen, vernetzte Bedien- und Beobachtungsgeräte, Pipelinenetze, Stromnetze, Gebäudeautomatisierung in Stadteilen und Verwaltung technischer Infrastrukturen etc..) oder komplexer Industrieanlagen mit Hilfe des Internets. Die verwalteten und gesteuerten Prozesse der realen Vorrichtungen und die zugehörigen Dokumente dürfen beliebig komplex sein, auf Datenverarbeitungseinrichtungen installiert sein, auf verschiedenen Rechnern verteilt sein und sich in der Anzahl dynamisch ändern. Die Beeinflussung der realen Prozesse und Dokumente erfolgt durch eine beliebige Anzahl autorisierter mit unterschiedlichen Rechten ausgestatteter Nutzer und automatisierter Dienste, zu jedem Zeitpunkt und von jedem Ort. Datentransfer, grafische Benutzerschnittstellen und Verwaltung aller Dienste und Informationen werden hierzu in eine vereinheitlichende sichere, plattform- und ortsunabhängige, ressourcenschonende, Analyse-, Abbildungs-, Vernetzungs- Bedien- und Organisationsmethode gefaßt. Die strukturierte Kontrolle einer großen Anzahl realer Prozesse nebst zugehöriger Dokumente wird mit Hilfe metaobjektbasierter Wissensmanagement-, Verteil- und Suchmethoden verbessert, um benötigte ergänzende Kommunikationswege erweitert und mit schon bestehenden thematisch verwandten internetfähigen Anwendungen zu höher organisierten Anwendungskategorien verknüpft. Durch die geringe Kernkomplexität und Einfachheit der Erfindung, durch hohe Modularisierung und Skalierbarkeit, des sehr geringen Ressourcenverbrauchs der Erfindung auf der Prozessebene und einer vollständigen Dezentralisierung aller Basisfunktionen der verteilten Datenverarbeitungsanlage, die für die Modellierung, Kontrolle und Verwaltung der technischen Vorrichtungen benötigt werden, sowie den sicheren Betrieb auf unsicheren Netzen, eignet sich die Erfindung neben der Kontrolle und Verwaltung beliebig komplexer verteilter Industrieprozesse besonders für die vernetzte, effiziente und elegante Verwaltung einer großen Anzahl weit verteilter technischer Kleinstanwendungen.

Die Erfindung stellt eine sichere, robuste, ressourcenschonende, effiziente Gestaltungslösung für eine Vorrichtung und ein Verfahren zur sicheren, virtuell zentralisierenden Modellierung, Bedienung und Beobachtung, Organisation sowie für den Austausch und Umgang mit einer Vielzahl von verteilten, komplexen internetbasierten Informationen und Prozessen auf Basis realer technischer Vorrichtungen dar. Das erfindungsgemäße System aus Zentralkerneln mit Zentralkontrolle, zugeordneten Diensten und Zugriffskontrolle wird im folgenden „MetaOS" genannt. Die zu verarbeitenden Informationen basieren im wesentlichen auf schnell zeitveränderlichen technischen Prozeß- und Statusinformationen beliebiger Struktur, können jedoch auch Datenbank- und Verzeichnisinformationen etc., technische und organisatorische Dokumente, aber auch beliebige neue und bestehende internetbasierte Anwendungen und Administrationsinformationen enthalten. Die Bündelung der genannten Dienste, Informationen und Anwendungen zu einem übergeordneten, dezentral zu bedienenden, Organisations- und

Kommunikationsprinzip für technische Vorrichtungen, sowie die Vernetzung mehrerer dieser Bündel bildet ein „MetaOS Primärnetz", daß eine verteilte Datenverarbeitungsvorrichtung mit dem Schwerpunkt der dezentralen technischen Prozesskontrolle und Überwachung darstellt. Dieses umgibt alle enthalten Datenobjekte mittels eines einzigen Bedien-, Visualisierungs- und Administrationsprinzips. Bündelungsvorgänge können auf beliebig vielen technischen, logischen und administrativen Ebenen erfolgen und einen standortunabhängigen einheitlichen Zugriff auf alle Basisfunktionen des verteilten Systems ermöglichen. Darüber hinaus soll das MetaOS Primärnetz auf einfache Weise von FTP- und Webservern gelieferte Informationen, die auch zeitveränderliche Prozeßdaten einer technischen Vorrichtung beinhalten können, in die virtuelle Vorrichtung aufnehmen. Die Gesamtheit der Datenobjekte, die von solchen Servern ausschließlich über Standard FTP und HTTP Kommandos übertragen wird, wird im folgenden das „MetaOS Sekundärnetz" genannt. Die Aufgabe des Sekundärnetzes ist es, Datenbestände technischer Kleinanwendungen z.B. weit verteilte Anlagen in der Gebäudeautomation in das Primärnetz zu integrieren. Die virtuelle Vorrichtung soll von kleinsten Prozeßsteuerungen mit HTTP- und FTP-Server bis in die Leitebenen komplexer verteilter Industrie- und Verwaltungsprozesse angewandt werden können. Sie soll in bestehende Infrastrukturen leicht eingefügt werden können, und in der Lage sein, sprunghafte Zunahmen von strukturierten und unstrukturierten Informationen aus einer Vielzahl autarker unzusammenhängender Quellen in den Griff zu bekommen und nutzbringend auszuwerten. MetaOS-Netzwerke aus Primär- und Sekundärnetzen bilden eine vereinheitlichende kompakte Zwischenschicht, die in nahezu beliebige Betriebssystemgruppen, die der Steuerung und Administration technischer Vorrichtungen dienen, eingeklinkt werden können. Dies können spezialisierte Kleinstbetriebssysteme für Prozeßsteuerungen, aber auch komplexe Serverbetriebs-systeme sein. MetaOS fügt sich unterschiedslos in bestehende heterogene Rechnerlandschaften ein. MetaOS-Netze sollen einheitliche Modellierung, Abbildung, Verwaltung, Optimierung, Vernetzung, Mischung und benutzerspezifische Erweiterung beliebiger bestehender lokaler und internetbasierender Dienste und Dokumente von Prozeßebenen bis in Leit- und Verwaltungsebenen ermöglichen.

Mit Hilfe einer Menge unterschiedlich gruppierter, verteilter Objektbäume mit gemeinsamer Kommandosprache, die im weiteren MetaOS-Knoten (Fig.1) genannt werden, werden unterschiedliche Datendienste und Applikationen lokaler, technischer und nichttechnischer Teilprozesse auf eine gemeinsame Datenstruktur (Fig.2) abgebildet bzw. eigene Dienste erzeugt. Die gemeinsame Datenstruktur eines MetaOS-Knotens ist ein virtueller, dynamisch erzeugter, hierarchisch organisierter, veränderlicher Objektbaum (Fig.6) mit integriertem Meta- und Headerobjektkonzept (Fig.12, 13, 16). Datenobjekte eines MetaOS-Knoten werden aus den verschiedenen Informationen der Dienste eines oder mehrerer MetaOS- Knoten virtuell gebildet (Fig. 5,7,8,11 ,12). Die Art der gelieferten Information ist beliebig. Es können neben Datendiensten aus der Prozeßwelt (z.B. über OPC oder direkt von einer AD/DA Wandlerkarte) beispielsweise einfache Dateidienste, Mail, News- und FTP-Dienste, Multimediadienste aber auch Softwarekomponenten, die wiederum auf anderen Informationsdiensten basieren oder über Kommandostrings kommunizieren, sowie komplexe Verzeichnis- und Netzdienste innerhalb einer einzigen Objektstruktur abgebildet werden (Fig.11). Darüber hinaus können Datendienste und Zentralkernel eigene programmgesteuerte Steuer- und Regelvorschriften enthalten und die gelieferten Datenobjekte im virtuellen Objektbaum verarbeiten und verändern. Die Abbildung unterschiedlicher Dienste auf MetaOS-Knoten, die dynamische Vernetzung mehrere MetaOS-Knoten während der Laufzeit und die Interaktion der Objekte untereinander ermöglichst die Bildung eines zeitlich variierenden Verbundes integrierter Multifunktionsgateways. Durch die Möglichkeit des gegenseitigen teilweisen oder vollständigen standortabhängigen «Überdeckens« (im folgenden „mounten" genannt) identischer und ähnlicher Teilmengen virtuell gebildeter Strukturen der verschiedenen MetaOS-Knoten (Fig.4,5) sollen unterschiedliche Datendienststrukturen beispielsweise so gebildet werden können, daß größere physikalische, technische und organisatorische Zusammenhänge von verteilten, sich ändernden realen technischen Vorrichtungen je nach Standort des Nutzers (Bedieners, Administrators etc.) virtuell strukturiert und sinnvoll zusammengeführt werden, dargestellt werden und miteinander in Interaktion treten (Fig.52-55). Es entsteht ein zeit- und ortsabhängiger fluktuierender Informationsverbund unterschiedlichster Informationsquellen, der große Mengen technischer Anlagen effizient verwalten kann. Die Einbindung einer dezentralen, integrierten Cache- und Routingmethode in den Informationsverbund repliziert und verteilt Informationen aus dem Informationsverbund automatisch in Regionen, in denen Sie nachgefragt werden und erhöht so die Leistungsfähigkeit des gesamten virtuellen Vorrichtung (Fig. 26).

Durch die sukzessive Bildung von Gruppen, Untermodellen, Teilmodellen bis hin zur Bildung von Modellen zur vollständigen Abbildung der realer Vorrichtungen inkl. der dazugehörigen Organisations-, Analyse und Verwaltungsstrukturen sollen alle technischen Vorrichtungen von verteilten Unternehmen und Produktionsanlagen nach und nach aus einfachen Komponenten komplett informationstechnisch abgebildet und ständig von jedem Ort zugreifbar angepaßt werden. In dem entstehenden virtuellen technisch-organisatorischen Komplex soll je nach Standort und Betrachtungsweise in den verschiedenen Informationsbeständen wahlweise unterschiedlich oder einheitlich navigiert und gearbeitet, d.h die technische Anlage beeinflußt werden können, sowie über Suchmechanismen nach beliebigen statischen und dynamischen Informationen effizient recherchiert werden und diese bei Bedarf verändert werden können. Bedien- und Beobachtungsmodelle von technischen Vorrichtungen können Mischformen von ortsbeschreibenden, technisch- komponentenbasierten und klassischen Datenstrukturen (z.B. Dateimanagerstrukturen) in flächiger und räumlicher Form beinhalten. Ein in jedem Knoten eingebautes skalierbares dynamisches Meta- und Headerobjektkonzept, daß mit den Cache-, Routing-, und Suchfunktionen zusammenwirkt, mit Möglichkeit zur Bildung von beliebigen Klassifikationsinformationen, Querverweisen in die eigene Informationsstruktur sowie auf fremde Datenstrukturen erweitert die virtuelle Datenstruktur um Fähigkeiten zum technisch organisatorischen Informations- und Wissensmanagement über eine bisher angelegte, dezentral erzeugte Rahmenstruktur hinaus und verbessert das Anwendungs- und Kontrollwissen an den realen technischen Vorrichtungen. Das Metaobjektkonzept ist besonders effizient auf schwachen Netzwerken mit geringer Übertragungsleistung auf denen große Dokumente in Verbindung mit Prozeßdaten gemeinsam genutzt werden sollen.

Das dynamische Meta- und Headerobjektkonzept soll der Vereinfachung und Optimierung von Organisations- und Verwaltungsformen, der Optimierung der Datenübertragung, vereinfachter Informationsgewinnung aus den realen und virtuellen Vorrichtungen und damit letztendlich der Optimierung der Funktionsweise der technischen Vorrichtungen dienen. Weitere Verbesserungen werden durch manuelles „Einhängen" geeigneter zusätzlicher Informationsquellen, durch Verknüpfung verwandter Informationen durch gefilterte Synchronisation im MetaOS-Netzwerk sowie der Nutzung der Cache- und Routingfunktionen erreicht. Beliebige Suchanfragen an die Metaobjekte und Datenobjekte der vernetzten virtuellen Vorrichtung erzeugen strukturierte Informationsuntermengen des Gesamtdatensatzes. Suchergebisse werden in Gebiete mit hoher Nachfrage verteilt, bewertet, verdichtet und bearbeitet und können wiederum an beliebigen Stellen der hierarchischen virtuellen Informationsstrukturen von MetaOS-Knoten eingefügt werden. Das so aus übergeordneten Daten beständen gezogene „Netzwissen" kann zur Optimierung der lokalen realen Prozesse verwandt werden. Die Darstellung von Datenobjekten erfolgt durch eine aus dezentralen Komponenten gebildete, die virtuellen Datenobjekte nutzende, n- dimensionale Gruppe, in einigen Grundeigenschaften einheitlicher im allgemeinen aber sich nur ähnelnder, hierarchisch beliebig schachtel- schicht- und projizierbarer grafischer Benutzterschnittstellen. Jede Benutzterschnittstelle stellt die Ihr zugeordnete Informationsuntermenge aus MetaOS-Knoten auf einem vereinheitlichtem Verzeichnis dar. Die grafischen Objekte der Benutzerschnittstellen können untereinander in Beziehung stehen und ermöglichen die einfache optische Zusammenführung unterschiedlichster verteilter technisch, organisatorisch und syntaktisch/semantisch ähnlicher Informationen zu thematisch zusammenhängenden Informationsobjekten auf unterschiedlichen Organisationsebenen. Aufbau und Anordnung der Benutzerschnittstellen sollen die Verwaltung und Strukturierung von Datenbezügen, von komplexen Datenhierarchien und von zeitlich aufeinander folgenden Bedienfolgen deutlich verbessern. Die Möglichkeit zur weitgehenden Verteilung der Rechenlast für den Aufbau und den Betrieb der Benutzerschnittstellen auf die Rechner, die die Benutzerschnittstellen präsentieren (Fig.7,8), soll den Betrieb von MetaOS-Knoten auch auf sehr leistungsschwachen Datendienstservem sicherstellen.

Die Grundkompomponenten der verteilten Datenverarbeitungsanlage sind im wesentlichen aus verschiedenen Bereichen der Technik und der Informationstechnik bekannt, die effiziente und benutzterfreundliche Art und Weise des integrierten Zusammenspiels, die einfache Verknüpfungsmöglichkeit aller Grundkomponenten und die Anwendung auf technische Gerätschaften ermöglichen die hohe Leistungsfähigkeit und Benutzerfreundlichkeit des MetaOS-Netzes und übertreffen so den aktuellen Stand der Technik.

Alle für die Bedienung, Beobachtung, Regelung, Analyse, Verwaltung und Datenspeicherung der Automatisierungsanlag(en) benötigten elektronischen und computergesteuerten Anlagen werden zu einem plattformübergreifenden Netzwerk, dem MetaOS-Netzwerk (Fig. 52,53,54,55,56) erweitert, daß je nach Größe und Komplexität der technischen Vorrichtung(en) aus beliebig vielen Netzknoten sowie ergänzenden Netzelementen (dem Sekundärnetz) bestehen kann (Fig. 30 Komponente 334, 338)(Fig. 32 Komponente 352, 353, 354) Einzelne MetaOS-Knoten, die neben der Steuerung und Administration der technischen Vorrichtung durch Kopplung mit der realen technischen Vorrichtung, beliebige allgemeine und spezialisierte Aufgaben im Netzwerk übernehmen können, werden auf Wunsch automatisiert mittels Autokonfiguration in die MetaOS Struktur eingebunden (siehe auch Fig. 18 .relative Synchronisation von Objekten über verschiedene Zentralkernel) oder beliebig inhomogen vernetzt. Jedem MetaOS-Knoten kann mindestens ein spezieller Dienst, der Visualisierungsdienst (Fig. 1 Komponente 7, (Fig. 5 Komponente 73, Fig. 8 Komponente 116) zugeordnet werden. Visualisierungsdienste übernehmen die grafische Darstellung von Datenobjekten im Netzwerk. Die identische Grundstruktur aller Knoten und Dienste im Netzwerk, die es allen Netzteinehmem erlaubt alle im Netzwerk benötigte Aufgaben wahrzunehmen, ermöglicht eine wahlfreie Optimierung des Netzwerks oder dessen Teile hinsichtlich Robustheit, Leiatungsfähigkeit, Sicherheit, einfache Navigation und Administration. Je nach auszuführender Funktion und Leistungsfähigkeit wird eine elektronische Einzelanlage einer technischen Vorrichtung dem Primär- oder dem Sekundärnetz zugeordnet (Fig. 30). Objekte, Metaobjekte, Headerobjekte, Elemente, Datendienste, MetaOS-Knoten, MetaOS-Netzwerke (Primär- und Sekundametze) und

Visualisierungsdienste in einem MetaOS-Netzwerk werden mit Hilfe einheitlicher Objekt- .Metaobjekt-, Headerstrukturen,

Visualisierungsprinzipien und einer einheitlichen Kommandosprache so eng miteinander verknüpft, daß MetaOS-Netzwerke aus unterschiedlichsten Elementen den Benutzern wie eine einzige einheitliche Struktur erscheinen, in der alle Dienste genutzt werden können. Die Komplexität des Netzwerkes wird so verborgen. Darüber hinaus erfüllt die Verknüpfungsstrategie der MetaOS-Knoten alle grundlegenden Anforderungen an Effizienz und Robustheit.

Ein MetaOS-Knoten zur Modellierung, integrierten Überwachung, Steuerung, Regelung, Analyse und Datenspeicherung von komplexen technischen Verfahrensabläufen besteht aus einem kompakten Zentralkernel mit jeweils einer integrierten rudimentären Zugangskontrolle, separater Kontrolle für die Verwaltung von Tasks, Threads, Speicher, Netzwerkkapazitäten und jeweils einer hierarchisch strukturierten Objektbaumverwaltung mit integrierter Funktion zur programmgesteuerten oder manuellen Sammlung und Verteilung von Datenelementen, Verwaltung und Kommunikation von Diensten und Zentralkerneln samt zugehörigen Datenstrukturen und einer Sammlung von beliebigen spezialisierten Datendiensten (komponenten 4-10), welche räumlich und/oder thematisch zusammengehörige physikalische oder logische Geräte oder weitere Zentralkernel als Client oder Serverdienste des MetaOS Knotens darstellen und die mit der Objektbaumverwaltung des Zentralkernels bei Bedarf gleichzeitig kommunizieren. Mindestens ein Dienst eines MetaOS Knotens kann externe Schnittstellen für Bedienung und Beobachtung des verteilten Datenverarbeitungssystems aufweisen. Ein lokaler Zentralkernel wird bei Bedarf während des Betriebs um beliebige Datendienste und weitere Zentralkemel erweitert und beliebige Datendienste und weitere Zentralkernel werden bei Bedarf entfernt. Alle dem Zentralkernel zugewiesenen Datendienste erscheinen dem Zentralkernel wie weitere Zentralkernel im MetaOS-Netzwerk (Fig. 10 Komponente 125). Über den Zentralkernel, auf den die Datenobjekte der Datendienste projiziert werden, können Anwender, Anlagen, Anwendungen und andere MetaOS-Knoten mit den Datendiensten kommunizieren. Zentralkernel und Datendienste besitzen eine gemeinsame Kommandosprache. Bootvorgänge eines MetaOS-Knotens, sowie die Verwaltung von Tasks, Threads, Speicherbereiche und Netzwerknutzung des Knotens werden durch eine separate Kontrollinstanz verwaltet (Fig. 6 Komponente 89). Die Datendienste des MetaOS-Knotens übernehmen die Kommunikation mit beliebigen externen logischen oder technischen Diensten (z.B. Filesystemen, OPC-Servern für die Prozesskontrolle, Netzwerkdiensten etc..) in Form von Gateways, regeln die Zugriffskontrolle auf die externen Dienste oder stellen eigene Dienste dem Zentralkernel zu Verfügung (z.B. Prozeßregelungen von technischen Teilbereichen der technischen Anlage) (Fig. 11 Komponente 138-140,142). Die Datendienste eines MetaOS-Knotens stellen darüber hinaus Dienste für sichere Benutzerauthentifizierung (Fig. 1 Komponente 6), Zugriffsrechte (Fig. 1 Komponente 5), Netzwerkadministration und Anwenderkommunikation zu Verfügung. Je nach Leistungsfähigkeit und informationstechnischer Ausstattung der Einzelanlagen kann ein MetaOS- Knoten vollständig auf einem einzelnen Rechner laufen oder Datendienste auf mehrere Rechner verteilen (Fig. 7,8).

Jeder Datendienst eines MetaOS-Knotens ist in zwei Teile aufgeteilt. Der erste Teil des Dienstes greift z.B. auf extern erzeugte Datenobjekte zu und konvertiert bzw. kapselt diese in ein für MetaOS-Knoten gültiges Format bzw. umgekehrt (Fig. 10). Der zweite Teil bildet je nach Funktionalität eine Client und/oder Serverstruktur für den Zentralkernel des MetaOS-Knotens (Fig. 10, Komponente 126). Der zweite Teil erscheint dem Zentralkernel wie ein weiterer Zentralkernel, mit dem dieser kommunizieren kann (Fig. 10 Komponente 125). Im einfachstem Fall stellt ein Datendienst dem Zentralkernel z.B. einfache Werte oder Files, im allgemeinsten Fall komplexe zeitvariante Datenobjekte und Metadatenobjekte bereit und/oder empfängt Sie. Bei Bedarf werden über den Zentralkernel Datenobjekte aus den Datendiensten aufgerufen und verwendet. Datendienste und Zentralkernel stellen Datenelemente, die auch zeitvariante Prozessdaten und Multimediadateien enthalten können, in Form eines, den jeweiligen proprietären Einzelvorrichtungen zugeordneten und normierten, hierarchisch organisierten Objektbaums zur Verfügung, (einer Zerlegung der Schnittstelleninformationen in einfache Elementarobjekte für den Zentralkernel). Einzelinformationen, Informationslisten und hierarchisch organisierte Informationsstrukturen aus Daten-, Zustande-, und Funktionsschnittstellen der einzelnen Meß-, Analyse-, Speicher-, Regelungs-, Bedien- und Beobachtungsvorrichtungen werden hierzu durch programmgesteuerte Informationsprojektion nach Bedarf in den jeweiligen Objektbäumen der zugeordneten Dienste gekapselt. Jedem Element dieser Objektbäume ist im allgemeinsten Fall zusätzlich ein beliebig definierbarer Satz an zeitvarianten Meta- und ein hierarchisch strukturierter Baum von Headerdatenobjekten zugeordnet (Fig. 12).

In die Headerobjekte werden dezentral gelagerte Timinginformationen zur Synchronisation, Informationen zu Ressourcen des lokalen Standorts (CPU, Speicher, Netzwerkkapazitäten), Log- und Fehlerinformationen, Informationen zur Benutzerverwaltung und Authentisierung, Sicherheit, Transport-, Popularitäts- und Prioritätseigenschaften und Zustand der Datenobjekte, sowie Informationen über Art und Zustand der Bedien- und Beobachtungsvorrichtungen sowie Beschreibungsinformationen zu den Objekten und zusammengefaßte Informationen über hierarchisch tiefer liegende Objektstrukturen etc. synchronisiert. Objektbäume bzw. deren Untermengen mit den Elementen der Datendienste werden im einfachsten Fall einfach an beliebigen Stellen einem zentralem, virtuellem hierarchisch organisierten Objektbaum, dessen Rootelement der Zentralkernel bildet, zugeordnet bzw. auf diesen projiziert (Fig. 14). Optional erfolgt dieser Vorgang programmgesteuert unter Zuhilfenahme von Filterlemenen und Operatoren. Dieser Vorgang, der die Abbildungslogik der Datendienste auf dem zentralen Objektbaum definiert, wird im folgenden «mounten« "genannt.

Virtuell "meint, daß der zentrale Objektbaum im Zentralkernel als strukturierender Ordnungsrahmen zum Durchleiten der Objekte und Metadatenobjekte der Datendienste und temporärer Cachespeicher für die Elemente der Datendienste dient. In der Objektstruktur des Zentralkernels sind anfangs nur die Mountpunkte der Datendienste eingetragen, Datenobjekte werden zunächst nicht übertragen. Durch manuelle oder automatisierte Navigation im virtuellen Objektbaum werden dann sukzessive Strukturdaten, Metadatenobjekte und Datenobjekte in den virtuellen Objektbaum übertragen. Dieser Abbildungsvorgang wird im folgenden Synchronisation" genannt. Der entgegengesetzte Vorgang der „Verteilung" von Daten, die von einem Anwender in den zentralen Objektbaum geschrieben werden und in einen oder mehrere gemountete Datendienste geschrieben werden, erfolgt auf analoge Art und Weise. Darüber hinaus können in den virtuellen hierarchischen Objektbaum des Zentralkernels Objekte eingefügt werden, die Verweise auf die Positionen anderer Objekte in Form von symbolischen Links im virtuellen Objektbaum bilden. Die Objekte selber wiederum speichern die Positionen der Verweise in den Ihnen zugeordneten Headerdatenobjekten. Ändert sich die Position eines Zielobjekts im virtuellen Dateibaum, so werden durch den Zentralkernel die Zielpositionen der Verweise so angepaßt, das die symbolischen Links wieder auf das Zielobjekt verweisen. Zeitvariante Daten, die aus Datendiensten gelesen, oder in Datendienste geschrieben werden sollen, werden im virtuellen Objektbaum durch manuell vom Benutzer gesteuerte Refreshzyklen oder alternativ programmgesteuert durch einen Scheduler (Fig. 19) welcher seine Daten aus den Headerdatenobjekten der Objektbäume bezieht aktualisiert. Mehrere Datendienste eines MetaOS-Knotens können an gleicher Stelle im virtuellem Objektbaum gemountet sein.

Die Objektbäume mehrere Datendienste werden in diesem Fall durch virtuelles transparentes „Ubereinanderiegen", d.h. durch Projektion nach verschiedenen Prioritäten und optional unter Anwendung von syntaktischen, semantischen, logischen und numerischen programmgesteuerten Filtern und Operatoren, miteinander verschmolzen, d.h. daß verschiedene Datenobjekte aus verschiedenen Datendiensten, aber gleicher Position in den jeweiligen lokalen Objektbäumen im zentralen Objektbaum in den Elementen eines Verzeichnis gesammelt werden, und verschiedene Objekte gleicher Elemente an gleichen

Positionen in verschiedenen Datendiensten ebenfalls im zentralen

Objektbaum in einem Element zusammengeführt und gespeichert werden. Die Zusammenführung von Objekten, Metadatenobjekten und Headerdatenobjekten eines Elements des Zentralkernels erfolgt in beliebiger Kombination mit dem grundlegenden Projektionsverfahren aus den Diensten des Zentralkernrels und aus weiteren Zentralkerneln. Die Informationen der Headerdatenobjekte jedes Daten-, und Metadatenobjekts eines Zentralkernels werden beispielsweise aus verschiedenen spezialisierten Datendiensten und weiteren Zentralkerneln in eine gemeinsame Headerobjektstruktur des Elements gemountet und synchronisiert.

Der Zugriff auf vom Zentralkemel aus gesehene identische Objekte in verschiedenen Datendiensten wird über den Datendiensten zugeordnete Prioritäten geregelt. Aus mehreren unterschiedlichen Datendienste eines MetaOS-Knotens wird so eine vereinheitliche geordnete Datenstruktur auf dem Zentralkernel abgebildet, die von den Visualisierungsdiensten im MetaOS-Netzwerk vollständig oder in Teilmengen zu Verfügung gestellt wird. Die Vorgehensweise gilt neben den beschriebenen Lesevorgängen aus den Datendiensten, in gleicher Weise für Schreibvorgänge und Ausführungsvorgänge von Programmcode auf den Datendiensten unter Beachtung von eventuellen Schreib, Lese und Ausführungsrechten. Darüber hinaus können verschiedene Objektbäume auch mittels, syntaktisch/semantischer Operatoren (z.B. über Platzhalter in den Objektnamen (Fig. 23)) oder beliebige andere Operatoren synchronisiert werden (siehe auch Kapitel Informationssuche in MetaOS-Netzen), so daß syntaktisch/semantisch ähnliche Objektordner von Datendiensten jeweils zu einem einzigen Objektordner verschmolzen werden, und angesprochen werden können. Datendienste werden so programmiert, daß diese zur Laufzeit eines MetaOS-Knotens in den Knoten eingebracht (gemountet) und wieder entfernt werden können. Ein MetaOS-Primärnetz ist ein beliebiger Zusammenschluß beliebig vieler MetaOS-Knoten, in denen Zentralkernel und zugehörige Datendienste miteinander direkt oder über andere MetaOS-Knotenketten (Proxiketten) kommunizieren (Fig. 4). Vernetzung und Kommunikation im Primärnetz folgen denselben Prinzipien wie die Vernetzung und Kommunikation zwischen Datendiensten und Zentralkernel. Unterschiede bestehen darin, daß im Gegensatz zu einem Datendienst, der nur innerhalb eines MetaOS-Knotens mit dem Zentralkernel und mit den anderen Datendiensten nur eingeschränkt kommunizieren kann, jeder Zentralkernel mit allen anderen Zentralkerneln im MetaOS-Primärnetz kommunizieren kann, wobei gleichzeitige Kommunikation mit mehreren anderen Knoten und lokalen Datendiensten erlaubt ist (Fig. 3,4). Darüber hinaus kann im Gegensatz zu Datendiensten, die Objektbäume anderer Datendienste nur am Wurzelelement Ihres eigenen Objektbaums mounten können, jeder MetaOS-Knoten beliebige Datenobjekte an beliebiger Stelle aus den Zentralkernel jedes anderen MetaOS-Knoten mounten und synchronisieren (Fig. 11). Auf diese Weise können somit Datenobjekte aus externen Datendiensten übernommen werden bzw. Datenobjekte beliebiger MetaOS-Knoten einfach strukturiert und zusammengeführt werden. Da Datenobjekte beim Synchronisieren auf dem Zentralkernel des Zielknotens gecached werden, besteht im Allgemeinen keine Notwendigkeit, Datensätze gezielt zu verschieben oder zu kopieren. Die Mechanismen des Primärnetzes werden neben der technischen, strukturierten Verwaltung der technischen Anlagen im Netzwerk auf gleiche Weise für Zwecke der zentralen und dezentralen Authentifikation, Zugangsverwaltung, Administration sowie für Datenreplizierung zur Erhöhung der Performance und Robustheit des Netzes eingesetzt. Ein Primärnetz wird gebildet, indem von einem anfänglich einzelnen Zentralkernel als virtuellem Zentrum mit weiteren Zentralkerneln ein logisch verknüpftes hierarchisches Netzwerk von Zentralkerneln aus verteilten Objektbeständen gemountet wird, so daß jeder Zentralkernel der Hierarchie jeweils Zugriff auf ein resultierendes, einheitlich netzwerkweit globales Verzeichnis (virtuelle Zentralisierung), ein jeweils unterschiedliches regionales Bereichsverzeichnis logisch zusammenhängender Elemente und ein lokales Verzeichnis gebildet aus den dezentral liegenden Diensten und Elementen erhält, indem jeder Knoten ein Mountschema mit anderem Knoten bildet, so daß jeder Knoten lokale Datendienste in ein lokales privates sowie auf Wunsch in ein lokales öffentliches Bereichsverzeichnis logisch zusammenhängender Elemente synchronisiert, ein festgelegtes Globalverzeichnis eines hierarchisch höherliegenden Zentralkernels an das Wurzelelement seines eigenen Zentralkernels mountet und synchronisiert und öffentliche lokale Bereichsverzeichnisse an die öffentlichen Bereichsverzeichnisse des übergeordneten Knotens im lokalen Globalverzeichnis mountet und synchronisiert und öffentliche regionale Bereichsverzeichnisse von untergeordneten Knoten an das eigene regionale Objektverzeichnis mountet. Für synchronisierte Datenbstände (Objektverzeichnisse, Elemente, Datenobjekte und Metadatenobjekte) auf einzelnen Zentralkerneln wird darüberhinaus jeweils ein Index aller bekannten lokalen und synchronisierter Bereichsdaten pro Zentralkernel angelegt. Auch diese werden virtuell zu einem Globalindex zusammengeschaltet. Änderungen von Datenobjekten, Metadatenobjekten und Headerdatenobjekten in den Objektbäumen von Datendiensten und Zentralkerneln werden in den Headerdatenobjekten der jeweiligen Elemente vermerkt. Änderungsvermerke werden sukzessive an hierarchisch übergeordnete Objekthierarchien übermittelt und hierarchisch untergeordnete Objekthierarchien fragen regelmäßig nach Änderungsvermerken in hierarchisch höheren Elementen. Objekt- und Elementveränderungen werden so in allen globalen, regionalen und privaten Objektbaumverzeichnissen bemerkt, die mit diesen Datenbeständen arbeiten. Zentralkernel m Netzwerk synchronisieren standardmäßig Datenbestände des virtuellen Zentrums und ihrer lokalen Umgebung (hierarchsich höhere und niedere Umgebung). Fällt ein Zentralkernel im Netzwerk aus werden mit diesen gecacheten synchronisierten Datenbständen zeitweise inaktive ausgefallene Zentralkernel für den Zeitraum des Ausfalls simuliert

In der Praxis ist es in vielen Fällen aufgrund vorhandener technischer Strukturen und der strukturellen Einfachheit halber üblich, die physikalischen und logischen Netzwerke zur Steuerung und Überwachung technischer Einrichtungen in Form von verteilten hierarchischen, baumartigen Strukturen aufzubauen. Benutzer des Netzes können so auf einer einzigen Struktur arbeiten. Bei einer sich ändernden hohen Anzahl weit verteilter technischer Anlagen, die zudem noch teilweise auf ungesicherten Netzen betrieben werden, ist diese Vernetzungsstategie jedoch hinsichtlich , Datensicherheit, Ausfallsicherheit, zentraler Administrationsmöglichkeiten und Leistungsfähigkeit (Bildung von Flaschenhälsen auf Teilstrecken des Netzes) problematisch. Bei Ausfall einzelner Verbindungen, schneller Übertragungsstrecken bzw. einzelner MetaOS-Knoten können ganze Teilgebiete aus dem Netzwerk herausfallen oder aufgrund von Bandbreitenproblemen faktisch nicht mehr nutzbar sein. Zentrale benutzerfreundliche Administrations- und Sicherheitskonzepte für das Netzwerk in Form von Verzeichnisdiensten sind in solchen Fällen nicht nutzbar. Ein gezielter manueller Aufbau von redundanten Verbindungen zwischen MetaOS-Knoten ist bei sehr großen Netzwerken hinsichtlich Arbeitsaufwand, struktureller Übersichtlichkeit und Wartbarkeit nur sehr schwierig möglich. Um Stabilität, Robustheit, Sicherheit und zentrale Administrierbarkeit unter den geschilderten Randbedingungen auch in hierarchisch strukturierten MetaOS-Netzen gewährleisten zu können, wird in jedem MetaOS-Knoten die Möglichkeit integriert, sich mit anderen Knoten im Netzwerk zu »Symbiosen«, (kooperiemden Gruppen) zusammenzuschließen, deren Stabilität und Geschwindigkeit die einzelner Knoten übertrifft.

Eine »Symbiose« ist eine Gruppe von MetaOS-Knoten, die im MetaOS- Netzwerk die kleinste funktionsfähige Untermenge mit Möglichkeiten zur zentralen Administration, Authentifizierung, Benutzer- und Ressourcenverwaltung unter den Nebenbedingungen hoher Performance und Robustheit bildet. »Symbiosen« bestehen jedoch nicht notwendigerweise aus geographisch benachbarten Gruppen von MetaOS- Knoten, sondern aus logisch zusammengehörenden MetaOS-KNoten und können über das MetaOS-Netzwerk verstreut angeordnet sein und dem MetaOS- Netzwerk stabile Bereiche aus verteilten, logisch zusammengehörigen Elementen aufprägen. Im folgenden werden die Elemente Ressourcenverwaltung, Performance und Robustheit betrachtet. Jeder Zentralkernel eines MetaOS-Knotens aus einer nur logisch zusammenhängender Gruppe von weiteren Zentralkerneln mountet und synchronisiert alle Verzeichnisse aller anderen Zentralkernel der Gruppe in einem für die gesamte Gruppe festgelegten Bereichsverzeichnis und bildet mit diesen so eine Symbiose (Fig. 28,29). Auf diese Weise entsteht auf jedem Knoten der Symbiose ein einheitlicher Blick auf alle in der Symbiose vorhandenen Daten. Verschiebevorgänge von Datenobjekte und Verzeichnissen von einem Knoten der Symbiose zu einem anderen, oder Kopiervorgänge bleiben für den Benutzer der Symbiose vollständig transparent. Änderungen in der Anordnung der Datenobjekte auf dem Bereichsobjektbaum der Symbiose entstehen nicht und die Notwendigkeit zum Ändern von Mountpunkten, um auf verschobene Datenobjekte zuzugreifen entfällt. Einzelne Knoten einer Symbiose können so sehr leicht gewartet werden, indem Datensätze während der Wartung kurzfristig auf Nachbarknoten ausgelagert werden, und für den Benutzer weiterhin an der gleichen Stelle zu Verfügung stehen. Die Verzeichnisse mit den auf den jeweiligen Knoten lokal vorhandenen Datenobjekte werden in den Headerobjekten gesondert gekennzeichnet um die Übersicht über auf den Knoten original vorhandenen Datenobjekten zu erleichtern. Werden Datenobjekte der Symbiose an einem Konten der Symbiose von einem externen Knoten oder einem Benutzer angefordert, schaut der Symbioseknoten zunächst in den eigenen Datenbeständen und im Cache des Zentralkernels nach. Sind diese nicht in den eigenen Datenbeständen vorhanden, sondern in anderen Knoten der Symbiose, werden die lokalen Datenobjekte mit denen des Zielrechners synchronisiert, und so eine Kopie der Datenobjekte sowie Quellenreferenzen und Angaben über Verfallszeiträume der Datenobjekte und Metadatenobjekte auf dem Cache des Zentral kern eis abgelegt. Angeforderte Datensätze werden so innerhalb einer Symbiose repliziert, und die Leistungsfähigkeit einer Symbiose bezüglich Anfragen erhöht sich. Dies gilt besonders für häufige Suchvorgänge auf Datenbeständen. Sollte der Zielrechner oder dessen Datenobjekte zeitweise nicht oder nur schlecht, z.B. wegen hoher Prozessorlast zugänglich sein, werden die anderen Knoten der Symbiose nach Kopien der Datensätze im Cache (Fig. 31) angefragt. Nur für Teile der Datenkopie, deren Verfallsdatum überschritten ist, wird auf den Originaldatensatz zurückgegriffen. Eine Symbiose von MetaOS-Knoten erfüllt somit grundlegende Anforderungen an ein verteiltes Objektverzeichnis mit dynamischen Objekten. Zum Bezug der Informationen werden, wie bei allen anderen Administrationsvorgängen auch, die Mount- und Synchronisationsmöglichkeiten der einzelnen MetaOS-Knoten genutzt. Andere Knoten im Netzwerk, die nicht zur Symbiose gehören, die jedoch einen Knoten einer Symbiose mounten (z.B. hierarchisch höhere Knoten), empfangen automatisch alle weiteren Adressen der Symbiosemitglieder. Sollte der gemountete Symbioseknoten ausfallen, wird ersatzweise automatisch ein weiterer Knoten der Symbiose gemountet. Der Zugriff auf alle verbliebenen Datenobjekte der Symbiose inklusive der Kopien in den Caches der Zentralkernel bleiben somit erhalten. Der beschriebene Aufbau einer Symbiose ermöglicht einen sehr benutzerfreundlichen Zugriff auf Datenobjekte einer Symbiose, bei noch relativ einfachem und übersichtlichem Mountschema, bei massiver Ausnutzung von Redundanzen und nur lokaler kurzfristiger Zusatzbelastung des Netzes durch Erzeugung von lokalen Datenkopien in der Symbiose. Darüber hinaus können mit dem beschriebenen Verfahren in globalen Mounthierarchien robuste Bereiche gebildet werden.

Ein MetaOS-Sekundämetz besteht aus einer Menge von FTP- und Webservern, die dem Primärnetz zugeordnet sind. Im Unterschied zum Primärnetz sind die Elemente des Sekundärnetzes nicht in der Lage mit MetaOS-Knoten und anderen Primärnetzelementen in der Sprache des Primärnetzes zu kommunizieren. Die Metadatenobjekte beliebiger Datenobjekte des Primämetzes können jedoch durch ergänzende Datenfiles auf den FTP- und Webservern so nachgestellt werden, daß MetaOS-Knoten des Primärnetzes über einen FTP- oder HTTP-fähigen Datendienst in der Lage sind, Datenobjekte aus dem Sekundärnetz ohne Konvertierung zu visualisieren, zu lesen und wieder in das Sekundärnetz zu schreiben. Da Sekundärnetzelemente, wie auch Primärnetzelemente, über einen eigenen Visualisierungsdienst verfügen, der über das Netz zum Benutzer übertragen wird (siehe Kapitel »Die Funktionsweise der grafischen Bedienschnittstellen«), und Metadatenobjekte auf Primär- und Sekundärnetz strukturell identisch verwaltet werden, können für den Benutzer die Elemente des Primär- und Sekundärnetz optisch identisch dargestellt werden. Die Datenelemente des Sekundärnetzes können aufgrund der eigenen Benutzeroberfläche auch eigenständig visualisiert und bearbeitet werden.

Die Bedienung eines MetaOS-Netzwerkes weist, um eine effiziente

Nutzung großer MetaOS Netzwerke mit mehreren tausend MetaOS- Knoten und einer großen Anzahl Benutzer von jedem Ort eines weltweiten Netzwerk zu gewährleisten einige besondere Eigenschaften auf.

Jeder Knoten des Primärnetzes wie auch des Sekundärnetzes kann Träger mindestens einer eigenen Benutzerschnittstelle sein. Diese ist als Datendienst ausgelegt, und wird vom Zentralkernel wie ein weiterer Zentralkernel behandelt, d.h sie verfügt über einen eigenen virtuellen Objektbaum und kommuniziert mit Hilfe der einheitlichen Kommandosprache mit dem Zentralkerneln. Die Benutzerschnittstelle wird bei Bedarf zu den Benutzern übertragen und kann beliebige Teilmengen aller lokalen und lokal gemountete Datenobjekte darstellen, indem sie Datenobjekte aus dem Zentralkernel mountet und synchronisiert. Jedes Element kann darüber hinaus alle benötigten Informationen für seine Darstelllung in seinen Headerdaten speichern. Die Benutzerschnittstelle ist somit integraler Teil eines MetaOS-Knotens. Dem Benutzer stehen am jedem Knoten ohne aufwendige Datenbankabfrage daher im Allgemeinen alle für diesen Knoten bzw. der zugehörigen Symbiose relevanten Datenobjekte bereit.

Die Benutzerschnittstellen aller Knoten arbeiten alle nach demselben Bedien- und Visualisierungsprinzip. Unterschiede zwischen

Benutzeroberflächen bestehen nur in einigen frei definierbaren Designelementen, um z.B. unterschiedliche technische Bereiche visuell zu kennzeichnen.

Die Datenbestände mehrerer gemounteter MetaOS-Knoten eines

MetaOS-Netzwerkes können durch Kommunikation mit den

Nachbarknoten über die Benutzerschnittstelle eines MetaOS-Knotens abgefragt werden.

Um komfortable und schnelle Arbeit auf den Bedienschnittstellen zu ermöglichen, werden Änderungen in der Bedienoberfläche durch den Visualisierungsdienst im Client selbst generiert und nicht durch MetaOS- Knoten generiert. Diese Eigenschaft erlaubt auch den Betrieb der grafischen Bedienschnittstellen auf dem Sekundärnetz.

Alle grundlegenden Mount-, Synchronisations- und Filtermechanismen der Zentralkernel können auch auf die Datenbstände der Benutzerschnittstellen angewendet werden. Die Benutzerschnittstellen erlauben die Ansicht eines oder mehrerer Datenobjekte samt Metadatenobjekte in verschiedenen Standardansichten und in vom Benutzer oder durch Headerdaten beliebig frei definierbaren Ansichten.

Standardansichten: \ Objektübersicht:

In der Objektübersicht werden Teilmengen der Strukturdaten (z.B. Verzeichnistrukturen und enthaltene Dateien) eines MetaOS-Knotens inklusive gemounteter MetaOS-Objekte dargestellt. Diese Darstellungsart entspricht im wesentlichen der Darstellung eines Dateimanagers bzw. Dateiexplorers mit

Zoomfunktion. Durch Anwahl eines Objekts wird in die Ansicht der entsprechenden Unterhierarchie^" bzw. in eine Defaultansicht eines Objekts selbst gewechselt.

X Metaobjektexplorer: Der Metaobjektexplorer erweitert die Objektübersicht um die tabellarische Ansicht,. Vorschau und Bearbeitung von frei definierbaren und wählbaren Metaobjektgruppen. \ Objektansicht:

In der Objektansicht (Fig. 39) wird der Inhalt eines Datenobjekts ohne ihre Metadatenobjekte angezeigt. Die Objektansicht enthält die Möglichkeit, Datenobjekte innerhalb eines „Browsers" anzuzeigen. Unter einem „Browser" wird eine Funktionseineit verstanden, welche . Daten mindestens der

Beschreibungssprache HTML 3.2 oder einer vergleichbaren Sprache oder einer erweiterten Version oder XML 1.0 interpretieren und darstellen kann, eine Scriptsprache wie Javascript 1.0, Phyton oder eine vergleichbare Sprache beherrscht, eine Programmiersprache entsprechend mindestens der Java 1.0 Spezifikation oder eine vergleichbare Sprache beherrscht, die Darstellung von Frames beherrscht und eine Schnittstelle vergleichbar des Netscape LiveConnetct Standards oder eines vergleichbaren Standards enthält, sowie Erweiterungsmodule im Browser verwalten kann.

\ Ansicht Objektmanager:

Die Ansicht »Objektmanager« (Fig. 40) ist die für die effiziente Nutzung großer MetaOS-Netzwerke wichtigste Ansicht. Die Ansicht »Objektmanager« beinhaltet im Grundzustand die

Ansicht »Elementübersicht«, eine mindestens zweidimensionalen Objektübersicht (Fig. 40 Komponente 394), die Symbole und Grafikobjekte mit symbolischen Links in die eigene Elementhierarchie verwalten kann und eine Objektleiste aller ausgewählten bzw. aktiven Elemente im Desktop. Durch

Anwahl eines Objekts in der Elementübersicht oder der Elementleiste erscheinen auf dem Desktop Objekte, die den Inhalt des angewählten Objekts präsentieren (z.B. Inhalte von Dateien und Verzeichnissen). Einzelne Desktopobjekte können durch Vergößerung zeitweise die gesamte grafische

Bedienfläche vollständig belegen, d.h sie legen sich wie ein Blatt über den bisher aktuellen Objektmanager und können in der Ansicht eines neuen Objektmanagers präsentiert werden. Dies liegt an der besondere Eigenschaft der Desktopobjekte , daß diese wiederum in allen möglichen Ansichten der genutzten grafischen Benutzterschnittstelle dargestellt werden können. Auf diese Weise kann ein grafischer Zoomeffekt in den Datenbaum realisiert werden. Darüber hinaus wird ein Mechanismus implementiert, der es erlaubt, in den Desktopobjekten die grafischen Bedienoberflächen des Sekundärnetzes und anderer

MetaOS-Koten einzublenden (Fig. 32 Komponente 353). Im beschriebenen Beispiel kann ein Desktopobjekt also die Ansichten Objektübersicht, Metaobjektexplorer, Objektansicht und Objektmanager als Standardansichten neben den freidefinierten Ansichten darstellen. Mit Hilfe der Objektübersicht ist es also möglich beliebige Objektmanager beliebig oft ineinander zu schachteln und so eine grafische Präsentation von Teilen der Objektbäume zu präsentieren (Fig. 43,44). Durch temporäres Vergrößern können so beliebig viele Objektmanager übereinandergelegt(geschichtet) werden. Es können auf diese

Weise mehrere »Stapel« von Objektmanagern auf einer Benutzerschnittstelle entstehen. Durch Verkleinern auf die Ursprungsgröße der Objekte können die Schachtelungen in einer Ebene vollständig grafisch dargestellt werden. Bezüge zwischen einzelnen geöffneten Datenobjekten bleiben so für den Benutzter erhalten. Da alle Zustandsdaten für die grafische Repräsentation in den angezeigten Objekten selber gelagert werden, können auf mehrere Objektdesktops alle Mount- und

Synchronisationsvorgänge des MetaOS Netzes angewandt werden und diese zu einem resultierenden Desktop projiziert werden. In verallgemeinerter formaler Sprache wird eine Bentuzeroberfläche dadurch gekennzeichnet, daß eine Gruppe zwei-, oder dreidimensionaler, interaktiver in einem zwei- oder dreidimensionalen Gebiet liegender Komponenten einer grafischen Benutzerschnittstelle ai .. a_m, bestehend wiederum aus Mengen br..b_m' von an lokalen und dezentralen Orten generierten zwei- oder dreidimensionalen interaktiven grafischen Benutzerschnittstellen, in der jede Benutzerschnittstelle der Menge b eine für Sie selbst spezifische zugehörige Menge d ..cn grafischer Basiselemente sowie optional eine Menge an frei definierbaren grafischen Zusatzelementen enthält und die Gestaltung mindestens eines der Basiselemente jeder Mengen c derart ist, daß mindestens eine weitere grafische Benutzerschnittstelle vom Typ der Mengen a oder b oder mindestens eine Benutzerschnittstelle mindestens eines

Elements der Menge an Benutzerschnittstellen b in einem Teilgebiet von c vollständig abgebildet werden kann, und die Elemente der Mengen a und b als externe Bedien- und Beobachtungsschnittstellen der Elemente eines oder mehrerer Datendienste im verteilten Datenverarbeitungssystem dienen, indem Daten durch die Schnittstellen aus dem Datendienst synchronisert, verteilt und präsentiert werden.

Mit Tasten für Rückwärts und Vorwärtsbetrieb kann in der Historie jedes geöffneten Desktopobjekts navigiert werden. Ein Aufwärts-Taste ermöglicht ein grfisches »Hochsteigen« in den Elementbäumen. Mit Hilfe der beschriebenen Objektdesktops, die jedem Objekt im Elementbaum zugeordnet werden kpönnen, können Links auf weitere relevante Objekte im Objektbaum gelegt werden. Die Schachtel- und Zoomtechnik des Objektmanagers in Kombination mit den lokalen Historiefunktonen ermöglicht so ein effizientes Navigieren in großen Datenbeständen ohne die Orientierung im Netzwerk zu verlieren. Das Problem des »Lost in

Space«, welches z.B. bei Webbrowsern beim Navigieren im Internet entsteht entfällt vollständig. Die geöffneten Desktopobjekte werden im Desktop automatisch angeordnet und können über die Objektleiste temporär minimiert werden (wie in einer herkömmlichen Benutzeroberfläche). Die automatische Anordnung und die Möglichkeit zur Minimierung umfangreicher geschlachteter Datenstrukturen in der Objektleiste erleichtert die Navigation in den Datenobjekten.

Durch symbolische Links aus der Objekthierarchie auf beliebige URLs und IP-Adressen können neben systemeigenen Informationen z.B. auch externe internetbasierte Anwendungen z.B. in den Objektmanager eingeblendet und bearbeitet werden (z.B. das Sekundärnetz).

Die Kommandosprache ist die flexible einheitliche Basis für das gesamte Geschehen innerhalb eines MetaOS-Netzwerkes. Auf deren einfachen effizienten Struktur basiert die Kommunikation auf den Objektbäumen eines MetaOS-Zentralkemels mit den Datendiensten in der gleichen Weise wie mit den grafischen Benutzerschnittstellen und darüber hinaus die Kommunikation der Zentralkernel im MetaOS-Netzwerk einschließlich der selbstkonfϊgurierenden Bildung von Symbiosen und globalen Verzeichnisbäumen und die Kommunikation von Elementen und Objekten. Sie ist dadurch gekennzeichnet, daß beliebige Objekte, Elemente und Teilstrukturen eines Zentralkernels mit beliebigen Objekten, Elementen und Teilstrukturen weiterer lokaler Datendienste, Bedienschnittstellen oder Zentralkernel und mit beliebigen Objekten, Elementen und Strukturen des eigenen Zentralkernels gemountet, gefiltert, mit Operatoren verknüpft und synchronisert und verteilt werden und daß Daten-, Metadaten- und Headerdatenobjekte hierarchisch übergeordneter wie auch untergeordneter Baumelemente durch Angabe relativer Mountmarken gemountet,synchronisiert und verteilt werden

Auf die Kommandosprache wird darüber hinaus auch die Zugriffsverwaltung, die Benutzerkommunikation und die Administration aller Dienste im Netzwerk abgebildet. Die Mächtigkeit der Kommandosprache kann dadurch erklärt werden, daß alle im MetaOS- Netz verfügbaren Elemente auf einfachen strukturell identischen Objektbäumen mit Objekten und Metaobjekten, welche wiederum die gleiche Struktur haben, abgebildet sind. Alle für verteilte Netzwerke wichtigen internen und extern angekoppelten Dienste lassen sich auf solche Objektbäume als gemeinsame Basis abbilden, und beliebig miteinander verschalten. So entsteht ein einheitliches Objektumfeld, auf deren effizienten Manipulation und Organisation eine Kommandosprache neben einigen wenigen anderen Grundfunktionen sehr einfach zu optimieren ist. Alle der Kommandosprache „wesensfremden" nicht direkt abbildbaren Elemente, die z.B. Benutzerverwaltung,

Wissenmanagementmethoden und spezielle Kommunikationsformen mit externen Diensten betreffen, werden über die den Objekten zugeordneten Metaobjekte durch das MetaOS-Netzwerk transportiert (getunnelt) und erst in den spezialisierten Datendiensten interpretiert.

Zur effizienten und sicheren Nutzung großer weitverteilter MetaOS- Netzwerke mit vielen Benutzern auf unsicheren Netzwerken wird eine auf unterschiedliche Anforderungen anpaßbare flexible und datentechnisch effiziente Benutzer-, Rechteverwaltungs- sowie Authentifizierungsstrategie benötigt. Die Anforderungen bezüglich Sicherheit und Administrierbarkeit können je nach Art der zu steuernden Anlagen und den hierfür benötigten Sicherheitsvorkehrungen in unterschiedlichen Bereichen eines Netzes stark variieren. Ein zentrale Verwaltung ist technisch und wirtschaftlich unrentabel. Aus diesem Grund sind Benutzer- und Rechteverwaltungen und die Authentifizierungsstrategien nur in rudimentärer Form lokal in die Zentralkerneln von Knoten integriert, und weitergehende Dienste werden über die grundlegenden Mount-und Synchronisationsmöglichkeiten der MetaOS-Knoten von speziellen lokalen Datendiensten oder anderen MetaOS-Knoten zu den Elementen im Objektbaum gemountet. MetaOS- Knoten können so auf unterschiedliche Anforderungen angepaßt werden. Darüberhinaus werden dezentral implementierte Benutzer, Rechte und Authentifizierungsstrategien, welche den einzelnen Elemtnen in den Objektbäumen zugeordnet sind durch Mount- und

Synchronisationsvorgänge unter Nutzung von Filtern in globalen und regionalen Verzeichnisbäumen strukturiert und virtuell zentralisiert und so von jedem Ort einfach zugänglich gemacht.

Ein MetaOS-Knoten im Grundzustand .bestehend nur aus dem Zentralkernel und optional der grafischen Benutzerschnittstelle besitzt keine festgelegte Benutzerverwaltung und ist als lokales Einbenutztersystem ausgelegt. Jeder Benutzer, der sich an einem Knoten anmeldet wird als Defaultuser eingestuft und besitzt vollen Zugriff auf alle im MetaOS-Knoten verfügbaren Daten. Eventuelle Zugriffsbeschränkungen bestehen nur auf gemounteten externen Datendiensten deren Zugangsbeschränkungen über Metadatenobjekte auf den Zentralkemel durchgereicht werden. Der einzige für einen MetaOS- Knoten bekannte Benutzer, der Defaultuser, kann nach Einwahl ein Paßwort vergeben, daß auf dem Zentralkernel verschlüsselt gelagert wird. Nach Vergabe eines Paßwortes für den Defaultuser haben weitere Benutzer nach Anmeldung mit einem beliebigen Namen nur Zugriff auf Datenobjekte von vom Zentralkernel freigegebenen besonderen öffentlichen Defaultverzeichnissen (z.B ein Globalverzeichnis und ein Regionalverzeichnis). Dies erlaubt auch nicht angemeldeten und authentifizierten Benutzern die Navigation in MetaOS-Netzwerken. Werden die öffentlichen Verzeichnisse vom Defaultnutzer gesperrt, ist der Zugriff auf den Knoten für andere Nutzer vollständig gesperrt. Jeder mit einem beliebigen Namen an einem MetaOS-Knoten angemeldete Benutzer wird vom Zentralkernel in eine ständig aktualisierte Benutzerliste eingetragen, welche in den Objektbäumen des Zentralkernels selbst gespeichert ist. Alle Benutzerlisten eines MetaOS Netzes können durch ein entsprechendes globales Mountschema virtuell zentralisiert und jedem Knoten zugänglich gemacht werden.

In die Grundstruktur eines MetaOS-Knotens kann vom Defaultuser eine für mehrere Benutzer geeignete Zugriffsverwaltung integriert werden. Der im Zentralkernel verwaltete Defaultuser übernimmt in so einem System die Aufgabe des Administrators. Die Integration einer Benutzerverwaltung erfolgt zunächst durch Generieren eines oder mehrerer spezieller Datendienste (diese Methode wird im wesentlichen für das Primärnetz verwandtem Netzwerk, die im folgenden »Gatekeeper« genannt werden, oder durch Ergänzung von Datenobjekte auf Datendiensten und Sekundärnetzelementen durch spezielle Schlüsseldateien

(Gatekeeperdateien) mit Metaobjekteinträgen, die einzelne Daten und Objekte für festgelegte Benutzter freischalten. Die Gatekeeperdienste, die in Ihrer Objektstruktur frei definierbare Zugriffskontrolllisten in Form von Metadatenobjekte verwalten und über den Zugriff entscheiden, werden anschließend vom Zentralkernel gemountet und vollständig mit den dort vorhanden Datenbeständen in den Headerdaten der Elemente synchronisiert. Es spielt hierbei keine Rolle, ob der Zentralkernel einen Gatekeeper aus seinem eigenen Knoten, aus Administrationsknoten seiner Symbiose bzw. von beliebigen Knoten im Netzwerk mountet. Jedem Element kann so eine eigenen Benutzerverwaltung zugeordnet werden. Durch ein globales Mountschema kann die Benutzerverwaltung dann virtuell zentralisiet werden. Darüber hinaus besteht die Möglichkeit, Standort, bzw. zugangsabhängige Benutzerverwaltungen mit Hilfe von Gatekeeperdiensten zu realisieren, indem ein Gatekeeper nicht nur die Benutzerverwaltung eines einzigen MetaOS-Knotens verwaltet, sondern den Zugang zu mehreren gemounteten MetaOS-Knoten verwaltet, auf denen keine eigene Benutzerverwaltung installiert ist (indirekte Benutzerverwaltung). z.B. um spezielle Zugriffsmöglichkeiten von festgelegten Standorten zu gewährleisten. Die Auslagerung der Zugriffsverwaltung eines MetaOS-Knotens auf Gatekeeperdienste mit anschließender Synchronisation der Administrationsdaten auf die einzelnen Element ermöglicht somit eine für verschiedene Netzwerkbereiche differenzierte, beliebig einfache oder komplexe Verwaltung der Zugriffsmöglichkeiten von MetaOS-Knoten in einem MetaOS-Netzwerk.

Der Vorgang der Benutzerauthentifizierung erfolgt folgendermaßen. Meldet sich ein Benutzer, (nicht der Defaultuser des Zentralkernels) am MetaOS-Knoten an, so wird vom Zentralkernel zunächst geprüft, ob ein synchronisierter Gatekeeperdienste für den Benutzter auf dem Zentralkernel vorhanden ist. Ist dies der Fall, werden bei einem Zugriffsversuch auf die Datenbestände immer als erstes die Headerobjekteinträge des jeweiligen Gatekeepers überprüft, bzw. die Schlüsseldateien auf den Datendiensten und Sekundärnetzelementen. Nur Objekte im Zentralkernel, die in einem dem Benutzter zugeordneten Gatekeeper oder in den Schlüsseldateien eine entsprechende Benutzerkennung aufweisen, werden dem Benutzer zur Verfügung gestellt. Die Authentifizierung erfolgt mit Hilfe der Metadatenobjekte des Gatekeepers, der als Stellvertreter für die zu nutzenden Dienste auf dem Zentralkernel die Authentifizierung des Benutzers übernimmt und einem beliebigen Authentifizierungsverfahren, z.B. Kerberos Version 5 mit einem zentralen Server zur Authentifizierung. (Dieses Verfahren garantiert hohe Sicherheit auch auf unsicheren Netzen.) Die Administration der Netzstruktur und der Benutzerverwaltung sowie die benutzerfreundliche Navigation in den Netzen auch ohne Authentifizierung und die Benutzerfreundlichkeit in großen Netzwerken kann so erleichtert werden, ohne die Sicherheit im Netzwerk zu vernachlässigen. Aufgrund der beschriebenen ausgelagerten Verwaltungsstrukturen können alle Administrationsserver mit sicherheitsrelevanten Daten an externen speziell gesicherten Plätzen betrieben werden.

Die Möglichkeit zur Informationsrecherche wird in beliebige MetaOS- Zentralkemel und Datendienste eines MetaOS-Netzwerkes, in Form von Filtermodulen integriert. Filtermodule nutzen programmgesteuert die durch die grundlegende Kommandosprache bereitgestellten Mount -und Synchronisationsmöglichkeiten eines MetaOS-Knotens. Ergebnisse einer Suchanfrage werden an beliebiger Stelle im virtuellen Objektbaum des jeweiligen lokalen Zentral kern eis und je nach Art der Suchanfrage vollständig oder in Form von Teilmengen der gesuchten Strukturdaten, Metadatenobjekte und/oder Datenobjekte gespeichert und optional in beliebigen, für das jeweilige Objekt verfügbaren Ansichten dargestellt. Suchergebnisse werden nicht nur als gesammelte Datenobjekte betrachtet, sondern werden nach Spezifizierung in der Suchanfrage sowie nach Auswertung von der Verfallsangaben der Suchergebnisse bzw. durch Angabe von Refreshzyklen sofort in zeitveränderlicher Form dargestellt.

Eine Suchanfrage innerhalb eines MetaOS-Knotens wird durch Setzen eines oder mehrerer Mountpunkte (eventuell in Kombination mit Scripten) an beliebiger Stelle im Zentralkernel, der Angabe von verschiedenen Filterkriterien direkt im Zentralkernel oder für verschiedene Datendienste (für Datenstrukturen, Metadatenobjekte und Datenobjekte) für Zentralkernel und Datendienste, der Angabe des Suchbereichs (z.B. Objektverzeichnisse, Anzahl der maximal zu synchronisierenden Objekte eines Typs, Zeitlimits etc.) und der Darstellungswünsche sowie der Angabe der zu durchsuchenden Dienste bzw. Zentralkernel definiert. Alle Angaben für den Suchvorgang werden als Metadatenobjekte einem Element im Zentralkernel zugeordnet (genannt Mountpunkt) und werden somit selbst zu einem Teil des Objekts. Suchanfragen bleiben auf diese Weise langfristig im Objektbaum erhalten und können an sich ändernde Verhältnisse einfach angepaßt und verfeinert werden. Ein kompletter Suchvorgang wird durch Starten eines vollständigen Synchronisiervorgangs (Synchronisieren des spezifizierten

Objektverzeichnisses inklusive aller Unterverzeichnis) durchgeführt. Im Gegensatz dazu wird bei der Navigation in den Objektbäumen, nur das jeweils angewählte Objektverzeichnis synchronisiert. Während des Such- und Synchronisationsvorganges werden die durch die Filterkriterien spezifizierten Datenobjekte synchronisiert, und gegebenenfalls angezeigt. Andere Datenobjekte bleiben unberücksichtigt. Da mehrere Mountpunkt für ein Objekt in Form einer Mountliste oder Mountscripts vergeben werden können, können gezielt aus mehreren Objektverzeichnissen gesuchte Datenobjekte extrahiert werden, in einem Verzeichnis gesammelt und durch »Ubereinanderiegen« in ein Ergebnisverzeichnis synchonisiert werden. Da Suchergebnisse durch das Mount- und Synchronisationsprinzip als Objektbäume übergangslos in das virtuelle Objektverzeichnis eingefügt und grafisch dargestellt werden, können Suchvorgänge auch sukzessive durch manuelles Navigieren im Objektbaum durchgeführt werden und nicht interessierende Ergebnisse manuell aus dem Baum gelöscht werden. Das Auffrischen von Suchergebnissen im Objektbaum kann entweder durch manuelles Navigieren und Neusynchronisation der Teilsuchergebnisse erfolgen oder durch vollständige Neusynchronisation veränderter Daten. An interessierenden Stellen im Objektbaum wird durch weitere spezifizierende Suchanfragen das Suchergebnis weiter eingeschränkt. Durch weiteres Einfügen von Mountpunkten oder Scripten können an Suchergebnisse weitere zugehörige Datenobjekte angefügt werden. Dies können z.B. die übergeordneten Objektverzeichnisse der gefundenen Datenobjekte oder andere verwandte Daten der Suchergebnisse sein (siehe Knowledgemanagement in MetaOS-Netzen). Eine Suchanfrage in anderen Knoten, z.B. in der dem lokalen Knoten zugeordneten Symbiose oder im gesamten MetaOS-Netzwerk wird auf die gleiche Weise durchgeführt wie im lokalen Objektverzeichnis. Unterschiede bestehen zum einem in der Ausweitung der Filterkriterien auf externe MetaOS-Knoten und zum anderen darin, daß Suchparameter an externe MetaOS-Knoten weitergereicht werden und dort lokal ausgeführt werden, um einzelne MetaOS-Knoten und lokale Netze nicht zu stark mit Such- und Synchronisationsvorgängen zu belasten. Suchvorgänge in MetaOS-Knoten nach der beschriebenen Methode sind somit nur Spezialfälle der allgemeinen Mount- und Synchronisations und Filterprinzipien. Um langfristige Untersuchungen bestimmter Kriterien und Prozeßwerte in den einzelnen Knoten mit Hilfe der Suchanfrage durchführen zu können, können Suchanfragen zeitlich unbegrenzt und in den zu durchsuchenden Knoten zyklisch durchgeführt werden, indem Sie nach Ende eines Suchdurchlaufs zyklisch neu gestartet werden. Werden Suchkriterien während eines Durchlaufs erfüllt (z.B. Prozesswert außerhalb eines vorgegebenen Toleranzbereiches) werden die Suchergebnisse an den Anfrageort zurückgegeben. Um die Effizienz der Suchvorgänge zu erhöhen, wird jeder Datensatz in den Datendiensten und im Zentralkernel während des Suchvorganges mit einer eindeutige Suchmarke versehen. Wird ein Suchvorgang wiederholt, werden nur nichtmarkierte Datenobjekte berücksichtigt und synchronisiert. Bei Änderungen in Teilen der markierten Datensätzen oder bei Ablauf von Verfalldaten, werden die entsprechenden Suchmarken gelöscht. Auf diese Weise wird sichergestellt, daß aktualisierte Bereiche von Datensätzen bei wiederholten Such Vorgängen berücksichtigt werden. Suchergebnisse können wie jeder andere beliebige Teil des zentralen Objektbaums eines MetaOS-Knotens wiederum komplett oder teilweise von anderen Knoten im Netzwerk gemountet und auf diese Weise verteilt werden (z.B. für Verteilung der Information in Arbeitsgruppen, die Suchergebnisse gemeinsam nutzen müssen) Die Informationsverteilung in MetaOS-Netzen entspricht größtenteils dem Vorgang der Informationssuche. Der Unterschied besteht darin, daß gefundene Elemente aus allen dem Zentralkernel zugeordneten Diensten sowie dem Global- und Regionalverzeichnis zugeordneten Vorrichtungen im MetaOS-Netzwerk nicht mit dem lokalen Zentralkernel synchronisiert werden, sondern mit benutzterdefinierten Daten beschrieben werden (Fig.25). Auf diese Weise kann z.B. in einem einfachen Fall eine größere Anzahl von speziellen definierten Maschinenkomponenten nach bestimmten ermittelten Kriterien durch einen Benutzter synchron gestartet oder gestoppt werden. Je nach Art der gesendeten Objekte können beliebige Aktionen durchgeführt werden (z.B. Mountskripte in externe Zentralkernel schreiben) und durch programmtechnisch verknüpfte Synchronisation und Verteilung von Informationen beliebige Regelvorgänge implementiert werden. Wie bei Suchvorgängen sind ebenfalls langfristige andauernde, sich zyklisch wiederholende programmgesteuerte Verteilvorgänge möglich.

Durch die Ähnlichkeit der Verfahren der Informationssuche und der Informationsverteilung lassen sich Informationssuche und Verteilung in einem Mountpunkt gemeinsam verwenden (z.B. innerhalb von Mountscripten). Beispielsweise kann eine größere Anzahl verteilter Maschinenkomponenten mit Hilfe eines programmierten Verteilvorgangs aktiviert werden, und dann das Ergebnis der Aktivierung durch einen Suchvorgang verifiziert werden. Benutzern können so im ganzen Netzwerk über den globalen Objektbaum oder in festgelegten Bereichen (regionaler Objektbaum) des MetaOS-Netzwerkes definierte Kontrollmöglichkeiten über Maschinenkomponenten mit Hilfe der Such- und Verteilungvorgänge eingeräumt werden. Die grundlegenden Mechanismen des Mountens, Synchronisierens, Verteilen, Filterns und Projizierens von dynamischen Datenobjekt, Metadatenobjekt und Headerdatenobjekt-strukturen in MetaOS Knoten unter Zuhilfemahme von Scripten auf einem virtuell globalen Objektbaum ermöglichen über die bisher dargestellten Mechanismen hinaus die Unterstützung von über das Netzwerk verteilten unterschiedlichen Kommunikationsformen in beliebig leistungsfähiger Ausprägung. Kommunikationsmittel können über ein MetaOS-Netzwerk verteilt werden und von beliebiger Stelle im Netzwerk genutzt werden. Statische Newsgruppen können z.B. in Form eines Datendienstes in die Objektstruktur eines jeden MetaOS-Knotens gemountet werden (z.B. in Form von hierarchischen Objektstrukturen sowie jeweils eines Metadatenelements für Newstexte und Informationstyp). Für Newsgruppen gelten die gleichen Gesetzmäßigkeiten wie für alle anderen Objekte in den den Objektbäumen. Dezentral eingerichtete Newsgruppen können vollständig oder teilweise von anderen Knoten im Netzwerk gemountet und synchronisiert werden, mit Benutzerverwaltungen und Authentifizierungsverfahren ausgestattet sowie in Form von virtuell zentralisierten Objektverzeichnissen zentral verwaltet und überall im Netzwerk genutzt werden. Andererseits kann z.B. ein Newsnetzwerk so eingerichtet werden, daß ein Administrator alle Newsgruppen eines Netzwerkes zentral einrichten, verwalten und überblicken kann, während technische Servicekräfte vor Ort nur kleine Ausschnitte des gesamten Newsnetzwerkes an festgelegten Stellen im Netzwerk sehen und bearbeiten kann, welche vom Administrator auf den lokalen MetaOS- Knoten gemountet wurde. Da das Newssystem vollständig in das Objektverteichnis integriert wird gelten für die Newsgruppen ebenfalls die allgemeinen Möglichkeiten der Informationssuche und Verteilung.

Da ein Dateibaum im Zentralkernel nur allgemeine Objekte kennt, in denen zwischen Verzeichnissen, Dateien, Newsgruppen und anderen Datenobjekten kein grundlegender Unterschied besteht, können Newsgruppen an Verzeichnisse und Dateien und andere beliebige Objekte angehängt werden. Andererseits können an Newsgruppen angehängte Verzeichnisse und Dateien in einem Newssystem z.B. als (bei Bedarf dynamische) Attachments betrachtet werden, welche die Qualität einer Newsdiskussion deutlich verbessern können.

Auf vergleichbare Art und Weise können hierarchisch geordnete und mit Benutzerverwaltungen versehene dynamische Chats, Instant Messanger Dienste, wie auch technische Abstimmungsprozesse technischer Anlagengruppen in MetaOS-Knoten integriert werden, und in festgelegten Bereichen des Netzwerks oder global verfügbar gemacht werden. Der prinzipielle Unterschied zu einem Newssystem besteht im wesentlichen darin, daß Informationen in solchen Diensten in zyklisch schneller Folge aufgefrischt werden müssen.

Durch die Erfindung werden im wesentlichen folgende Vorteile erzielt: •Ein vereinheitlichtes System aus verteilten vernetzbaren Datenverarbeitungsanlagen mit projizierten dynamischen Metaobjekten und Benutzerschnittstellen aus dezentral generierten strukturierten und gruppierten, modellbasierten Komponenten und zugehörigem Verfahren zur Bedienung, Beobachtung und Verwaltung einer Menge von verteilten technischen Anlagen, Dokumenten und Anwendungen.

•Einheitliche Bedienung, Beobachtung und Verwaltung von komplexen technischen Prozessen wird bisher von zentralisierten Datenverarbeitungsanlagen durchgeführt. Dieses Verfahren erfordert teure leistungsstarke Rechenanlagen, ist empfindlich gegenüber Ausfällen und aufgrund der hohen Netzwerkbelastung, besonders in langsamen Netzen durch zentralisierte Datenübertragung nur eingeschränkt nutzbar und skalierbar. Das Verfahren ist für dezentrale Kontrolle und Verwaltung weit verteilter technischer Anlagen ungeeignet. Das neue dezentrale System und Verfahren vermeidet diese Nachteile und vereinfacht die Steuerung und Organisation komplexer technischer Netzwerke. BProzeßkopplungen, Anwendungen, Datentransfer, Benutzerschnittstellen, Zugriffsverwaltung und Dokumente werden mittels organisierter dynamischer Datenobjekte und zugehörigen Metadatenobjekte in eine vereinheitlichende sichere, ressourcenschonende, Analyse-, Abbildungs-, Vernetzungs-, Bedien- und Organisationsmethode gefaßt. Mittels einer einheitlichen Kommandosprache wird das physikalisch dezentrale System zu einer logischen virtuell globalen Einheit zusammengefaßt, die von jedem dezentralen Standort mittels einer aus verschiedenen dezentralen Komponenten aufbaubaren Bedienschnittstelle in vereinheitlichter Weise genutzt werden kann. «Das System ermöglicht sichere, vereinheitlichte Kontrolle und Verwaltung großer Mengen global verteilter Automatisierungsanlagen (z.B. verteilte Windparks, Mobilfunknetze, Stromnetze, Piplinenetze, Gebäudeautomatisierung, Verwaltung technischer Stadtinfrastrukturen etc.) und eignet sich aufgrund der geringen Komplexität und Einfachheit darüber hinaus zur effizienten und eleganten Verwaltung einer großen

Anzahl weit verteilter technischer Kleinstanwendungen.

Die Erfindung bildet ein vereinheitlichendes strukturierendes Rahmenwerk für Objekttransfers und Objektcaching mit universellen Einsatzmöglichkeiten für sukzessive ortsunabhängige Bündelung und Strukturierung von verschiedensten Datendiensten, Dokumenten und Anwendungen und Kommunikationsformen für verteilte und konzentrierte technische Vorrichtungen innerhalb einer einzigen modularen Informationsstruktur im Internet. Alle über die Grundfunktionalität hinausgehenden Dienste, auch wichtige Systemdienste werden in dezentral Datendienste ausgelagert, sind deshalb flexibel auf unterschiedliche Anforderungen im Netz anpaßbar, können ebenfalls virtuell zentralisiert und können im gesamten Netzwerk vollständig transparent genutzt werden.

Für die Kommunikation innerhalb von MetaOS-Knoten, im MetaOS Netzwerk (Primär- und Sekundärnetz) mit seinen verschiedensten Diensten, in Symbiosen und zur Strukturierung von Verzeichnisdiensten wird nur ein einziges Protokoll genutzt. Beliebige Netzkonfigurationen können so sehr einfach erstellt werden.

Die Modularisierbarkeit der Erfindung in kleinste Einheiten bei gleichzeitiger Ausnutzung aller lokal benötigter

Kommunikationsmöglichkeiten sowie die Abbildung auf ein gemeinsame Datenstruktur maximiert die Anzahl möglicher Freiheitsgrade zur optimalen Anpassung an die reale Vorrichtung und minimiert die Komplexität der Gesamtvorrichtung. Die Komplexität der Gesamtvorrichtung paßt sich der Komplexität der technischen Vorrichtungen an.

Jeder MetaOS-Knoten im Netzwerk kann bei Bedarf alle anfallenden Aufgaben im Netzwerk erfüllen und Dienste für fremde Knoten verfügbar machen.

Da die Suchfunktionen und Informationsverteilfunktionen spezielle Ausprägungen der grundlegenden Funktionen eines MetaOS-Netzwerkes sind, sind die Suchergebnisse vollständig transparent in ein MetaOS- Netzwerk integriert und es kann in Ihnen wie in normalen Objektbäumen navigiert und gearbeitet werden. Nahezu beliebige Kommunikationsanforderungen wie Newsdienste, Chats, Instant Messaging Dienste etc. können mit den grundlegenden Mechanismen eines Meta-OS Netzwerks an beliebigen Stellen im Netzwerk ermöglicht werden und mit beliebigen Benutzerrechten, Authentifizierungen ausgestattet sein.

Beliebige Objekte in einem Objektbaum können beliebig aneinandergehängt werden und sich in Ihren Funktionen ergänzen.

Virtuelle generierte Modelle und Vorrichtungen von komplexen verteilten technischen Prozeß- und Organisationsstrukturen werden einfach sukzessive durch die schrittwiese Vernetzung/ Überdeckung von MetaOS- Objekten bzw. Teilobjekten gebildet, da Modelldaten dezentral (bei Bedarf aber auch zentral) gelagert und aktualisiert werden können.(im Gegensatz zur Veröffentlichung DE 19834456A). Die Organisation der Teilmodelle (eine vernetzte Gruppe von MetaOS-Knoten) zu übergeordneten Modellen(z.B. das gesamte MetaOS-Netzwerk) basiert auf der weitverteilten Interaktion (mounten und synchronisieren) der vielen Bestandteile des Modells. Zentrale virtuelle Modelle können aus dem dezentralen Modell durch Suchen und Sammeln der Modelldaten bei Bedarf abgeleitet werden. Darüber hinaus kann ein zentrales Modell auf ein MetaOS-Netzwerk verteilt werden.

Die Elemente eines MetaOS-Objekt-Modells können unabhängig voneinander auf verschiedenen Prozeß- und Leitrechnern betrieben werden. Mehrere MetaOS Knoten können auf einer Hardware genutzt werden. Es besteht die Möglichkeit MetaOS-Knoten und Dienste für technische und organisatorische Prozesse dynamisch einem Modell hinzuzufügen, (im Gegensatz zur Veröffentlichung DE 19834456A). Deutlich verminderter Administrationsaufwand bei Aufbau und Betrieb der vernetzten virtuellen Vorrichtungen, da alle Netzwerkfunktionen eines MetaOS-Netzwerkes (Mounten, Caching) vollständig dezentralisiert konfiguriert werden können und dennoch durch die virtuelle Zentralisierung global und in strukturierter Form von jedem Knotenpnkt des Netzwerks zugänglich sind.

MetaOS-Netzwerke basieren auf seit langem bekannten Internettechniken und sind daher universell einsetzbar.

Die Erfindung ist aufgrund der dezentralen im wesentlichen autarken und gleichberechtigten Strukturen sowie der Verteilung von Information zum Einen über MetaOS-Proxyketten und zum anderen über die Möglichkeit von Direktzugriffen sehr robust gegen Störungen in einzelnen Prozeß- und Leitrechnern (im Gegensatz zur Veröffentlichung DE 19834456A).

Die Möglichkeit zur Verteilung der im Primär- und Sekundärnetz vorhandenen Gesamtinformation auf beliebig viele dezentrale Datenbanken von Primär- und Sekundärnetz, sowie eine einfach zu realisierende, beliebige und gezielte Verteilung von Einzelinformationen über das Gesamtnetzwerk minimiert das Risiko von Datenverlusten.

Den Prozeßmodellelementen zugeordnete Metadatenobjekte beliebiger Komplexität, ermöglichen optimierte Verwaltung, Organisation und Verteilung einer großen Anzahl unterschiedlicher verteilter Dienste im MetaOS-Netzwerk. Aus einfachen noch nicht optimalen Organisationsprinzipien können sich nach und nach verbesserte Prinzipien herauskristallisieren und stabilisieren (Ergänzung und Veränderung der Mountlisten über längere Zeiträume). Die Benutzeroberfläche kann unabhängig von betriebssystemspezifischen Windowmanagern auf verschiedensten Betriebssystemen eingesetzt werden und ermöglicht gleichzeitiges Arbeiten mit MetaOS-Knoten aus verschiedenen Teilen des Netzwerks.

Da jeder MetaOS-Knoten eine eigene Benutzerschnittstellen aufweist, kann auf jeden Teil des Netzwerkes unabhängig von der Vernetzung der MetaOS-Knoten zugegriffen werden.

Die Verknüpfung der grundlegenden Eigenschaften von MetaOS-Knoten, des Metaobjektkonzepts und der grafischen Bedienoberfläche zu einem integriertem Gesamtkonzept ermöglicht eine deutlich verbesserte Plattform übergreifende Arbeit mit verteilten komplexen technischen Prozeßstrukturen und erweitert technische Modelle um das organisatorische Miteinander von Bedienern, Servicepersonal, Kontrolleuren etc..

Die verteilte Datenstruktur und die Replizierung von Datensätzen sorgt für eine verbesserte Verteilung des Datentransfers auf dem Netzwerk und reduziert den Datenverkehr auf ein notwendiges Minimum. Modelle können deshalb auf sehr schwachen Netzen betrieben werden und sind auch an dezentraler Stelle stets aktuell.

Die Verteilung häufig abgefragter Information im Gesamtnetzwerk, auf mehrere MetaOS-Knoten mit ähnlichen Informationsbeständen (bezüglich Syntax/Semantik und Metadatenobjekten) in Netzgebieten mit hoher Nachfrage erhöht die Leistungsfähigkeit des MetaOS-Netzes.

Das dezentrale Datenmodell kann einfach von beliebiger dezentraler Stelle geändert werden. Die Struktur des virtuellen Gesamtmodell kann sich dezentral dynamisch ändern ohne Eingriff eines zentralen Administrators.

Verschiedene dezentrale virtuelle Vorrichtungen lassen sich mit geringen Aufwand nahtlos zu Gesamtstrukturen zusammenschließen und kombinieren.

1. Mounten, Synchronisieren und Filtern von Datenstrukturen zu einer Gesamtdatenstruktur. 2. Ubereinanderiegen von Datenstrukturen zur Zusammenführung verteilter Eigenschaften von Datenobjekten. 3. Verknüpfung von unterschiedlichen Datenstrukturen in einem Verzeichnis mit Hilfe der Analyse von syntaktisch/semantischer Beziehungen zwischen den Datenstrukturen.

Sehr einfache Updatemöglichkeiten von MetaOS-Netzwerken, da Softwaremodule im Allgemeinen nur punktweise an einigen Rechnern aktualisiert werden müssen. Die Aktualisierung unterschiedlicher Clientsoftwaren entfällt, da jeder MetaOS-Knoten seinen Visualisierungsdienst lokal lagert.

Teilmodelle funktionieren auch noch bei Ausfall einer übergeordneten Verwaltung, und auf Datenkopien kann immer noch zugegriffen werden, wenn deren Quelle ausgefallen ist.

Da jeder Rechnerteil ein Teil des Modells halten kann, ergibt sich eine sehr enge Verzahnung des Modells mit der Realität, sowie eine hohe Aktualität des virtuellen Modells. Da jeder Rechnerknoten den Teil des virtuellen Modells hält, den der Rechner in der Realität steuert und überwacht, bleiben bei Reparatur oder Austausch einer Komponente mit Rechnersystemen das Teilmodell sowie die gesamte Historie eines Teilmodells (Werte, Status, Dokumente, Statistiken etc.) erhalten. Von jeder realen Teilvorrichtung kann somit ein laufzeitbegleitender Maschinenpaß angelegt werden.

Sehr benutzerfreundliche Handhabung durch ein einheitliches Bedienprinzips auf allen Ebenen und der Möglichkeit der Nutzung von leicht unterschiedlichen Bedienelementen für verschiedene Komponenten und Teilnetzwerke.

Die beliebige Schachtelung von grafischen Benutzerschnittstellen ermöglicht leistungsfähige Vergleiche von Knoteninhalten durch einfache Navigationsvorgänge ohne aufwendige Programmierungen und verbessert den Überblick über das Gesamtsystem.

Der Komplexitätsgrad in der Navigation wird reduziert durch Nutzung von nur wenigen grundlegenden grafischen Strukturelementen.

Vereinfachte Wartung des dezentralen Systems, da die Funktion von Einzelknoten auf einfache Art und Weise ohne Datenverlust ersetzt werden kann.

Die Arbeit auf virtuellen Datenbeständen im Zentralkernel eines MetaOS- Knotens erhöht die Sicherheit und reduziert das Risiko von Datenverlusten, da nicht direkt auf den Objektdiensten eines MetaOS- Objekts gearbeitet werden muß. Automatisch aufgebaute, gestaffelte dezentrale Index- und Cachingmechanismen im Primärnetz und Sekundärnetz (Anlegen eines Zugriffsindex) verbessern die Antwortzeiten des Netzwerks bei Suchvorgängen und Datenzugriffen deutlich.

Da Suchvorgänge auf dezentralen Datenbeständen stattfinden, die ständig aktualisiert werden liefern Suchvorgänge immer aktuelle Ergebnisse. Es kann somit auch nach schnell veränderlichen dynamischen Datensätzen in realen Vorrichtungen gesucht werden.

Es kann nach beliebigen Datensätzen, Prozessen, Anwendungen, Dokumenten (inclusive Multimediadokumenten) und deren Inhalten gesucht werden, die von Objektdiensten an beliebiger Stelle im Gesamtnetz bereitgestellt werden. Suchergebnisse können aufgrund der Metaobjektstrukturen sehr einfach strukturiert und übersichtlich angezeigt werden (Erzeugen von globalen Übersichten nach speziellen Zuständen und Inhalten). Es können über Infomationsverteilanfragen dezentrale Auswertungen angestoßen werden, Prozesse geortet werden, die gestartet oder gestoppt werden sollen und Parameter an gefundene Prozesse übergeben werden.

Einzelne Knoten.welche beispielsweise eine technische Anlage regeln können zur lokalen Regelung des Prozesses auf alle aktuelle Prozeßinformationen des gesamten Netzes zugreifen

Das Metaobjektprinzip ermöglicht durch die Suche nach speziellen Informationen die Bildung von aktuellen strukturierten Informationstopologien belieber Datensätze.

Der vernetzbare Kemelcluster erlaubt in Kombination mit den virtuellen

Informationsobjekten ein gemeinsames dezentrales- Prozeß- und Informationsmanagement beliebiger technischer Datenobjekte und Dokumente auf der realen Vorrichtung. Dies geschieht innerhalb einer einzigen, plattformunabhängigen Struktur.

Aufgrund des Multikemelansatzes in Form von Datendiensten und der Nutzung der vorhandener Systemdienste der Prozeßsteuerung sind MetaOS-Knoten flexibel, kompakt, schnell, robust und wirtschaftlich. Die erforderliche Entwicklungsleistung und die Rechnerbelastung durch MetaOS-Knoten ist sehr gering.

MetaOS-Knoten ermöglichen parallele Erfassung und Verteilung verschiedenster Datendienste in Form von Multifunktionsgateways. Die Funktionsweise als Gateway ermöglicht besonders Ressourcen- und Rechenleistung sparende Realisierung von komplexen Dienstobjekten, da überwiegend auf bestehende Datendienste zurückgegriffen werden kann. Dies führt zu einem sehr einfachen Gesamtsystem mit geringer Komplexität.

Durch die Implementierung und Abbildung nahezu beliebiger

Schnittstellen und bestehender Webapplikationen in allgemeine

Objektbäume können bestehende Softwareinvestitionen geschützt werden.

Eine gemeinsame Kommandosprache zur Kommunikation aller Objektdienste erlaubt beliebige Loka-I und Fernverknüpfung aller Objekte und kann direkt oder indirekt auf viele andere Protokolle abgebildet werden (z.B. HTTP, FTP, Telnet, Mail, TCP/IP direkt etc.). Die Kontrolle von realen Vorrichtungen kann somit über nahezu beliebige Kommunikationswege erfolgen.

Einzelkomponenten eines MetaOS-Knotens können einfach angepaßt und erweitert werden. Verteilte Dienste (z.B. Administrationsdienste) im Netzwerk können zu hierarchischen Gruppen zusammengefaßt werden und als Verzeichnisdienst fungieren.

Fehlende Objekteigenschaften eines Informationsobjekts auf einem MetaOS-Knoten werden automatisch in anderen gemounteten Objekten gesucht. Objekteigenschaften können so auf mehrere Objekte verteilt werden und bei Bedarf wie ein Puzzle zusammengefügt werden. Datenobjekte können auf diese Weise weitestgehend auf den Quellen belassen werden.

Bei Suchvorgängen in MetaOS-Knoten können nicht nur Adressen zurückgegeben werden, sondern komplette dezentral gelagerte Anwendungen und Datenbestände können als Antwort sofort synchronisiert und gestartet werden. Die Art der Darstellung von Datensätzen kann dezentral festgelegt werden.

Automatisierte Verteilung von beliebigen Datenbeständen. z.B. können Modelle und Werte zur Abbildung von realen Vorrichten und Organisationen zunächst zentral gebildet werden, und dann auf ein MetaOS-Netzwerk verteilt werden.

Die virtuelle Zusammenschaltung identischer und ähnlicher Strukturdaten mehrerer MetaOS-Knoten zu einem virtuellem Gesamtdatenbestand in Form von Symbiosen erhöht die Übersichtlichkeit im Netzwerk.

Dienste können auf mehrere Rechner verteilt werden.

Die Auslagerung der Zugangsberechtigung und Authentifizierungen auf Datendienste ermöglicht zugangsabhängige Benutzerverwaltung und Authentifizierung in MetaOS-Netzen. Beliebige Benutzterverwaltungs- und Authentifizierungsmodule können in unterschiedlichen Netzbereichen genutzt werden.

Knoten mit administrativen Funktionen können an gesicherten Orten betrieben werden, und dennoch vollständig in das MetaOS-Netzwerk integriert sein.

Die Bildung von Symbiosen erhöht die Leitungsfähigkeit von Knotengruppen hinsichtlich Rechenbelastung und Datentransfers durch Lastausgleich und die Robustheit von MetaOS-Teilnetzen, da jeder Knoten als Server für alle Datenobjekte der Symbiose fungieren kann.

Jeder Knoten in der Symbiose hält den gleichen Objektbaum, bestehend aus allen Datenobjekten der Symbiose.

Symbiosen ermöglichen für den Benutzter transparentes Verschieben von Datenobjekten auf den Knoten der Symbiose.

Die browserintegrierenden grafischen Benutzerschnittstellen von MetaOS- Knoten verknüpfen die Vorteile von reinen Java Clients, mit den Möglichkeiten von Browser-Plugins und ActiveX X Komponenten, frei definierbaren HTML- und XML-Masken, bestehenden Java und Webanwendungen und erlauben für jede Gruppe und Komponente der realen Vorrichtung eine optimale Darstellung.

Die Kontrolle der realen Vorrichtungen, die effiziente Navigation, und Wissensgewinnung mit Hilfe der verteilten gespeicherten Informationsbestände aus einer ansonsten unüberschaubaren Angebotsvielfalt wird gegenüber herkömmlichen Methoden deutlich verbessert.

Die Leistungsfähigkeit der Benutzerschnittstellen wächst automatisch mit der Leistungsfähigkeit der verwendeten Abbildungstechnologien in den Browserkomponenten.

Da der Visualisierungsdienst, der die grafischen Benutzerschnittstellen generiert, selbst Teil des MetaOS-Knotens ist und alle Arbeitswerkzeuge, d.h. der Visualisierungsdienst selbst und alle weiteren benötigte Komponenten direkt vom Objektbaum des MetaOS-Knotens aus dem Internet geholt werden, ergibt sich eine stark vereinfachte Anwendung und Administration des Gesamtsystems. Die Nutzung von speziellen, fest installierten Clients ist ebenfalls möglich.

Die Möglichkeit der Schachtelung der unter verschiedenen Aspekten darstellbaren Teilansichten (die Elemente des virtuellen Datenbestandes) ermöglichen aufgrund der Wiederverwendbarkeit der meisten GUI- Komponenten die Schaffung von ressourcenarmen Benutzeroberfläche, die auch auf schwachen Netzwerkverbindungen sehr leistungsfähig sind. Die Grundelemente der GUI sind z.B. auch auf Mobilfunknetzen, als Benutzeroberfläche für Thin-Clients in leistungsschwachen öffentlichen Netzen und für Anwendungen unter erschwerten Bedingungen, in denen Wärmeentwicklung der Rechnersysteme eine Rolle spielt sinnvoll einsetzbar.

Die Auslegung auf optimale Ausnutzung der Bildschirmoberfläche durch teilautomatisierte Optimierung von Fensteranordnungen und Größen, der Verwendung nur sehr weniger Bedienelemente und Verwendung eines automatisierten Fensterschichtenmodells zum kontrollierten automatischen Übereinanderschichten von grafischen Benutzerschnittstellen erlaubt die Verwendung auch sehr kleiner Displays (z.B. bei Low-Cost Lösungen) zur Darstellung alle wichtigen Informationen auf nur einer Bildschirmseite ohne Einschränkungen bei der Übersichtlichkeit.

Da jedes Informationsobjekt neben vielen anderen Darstellungs- und Editierfunktionen in Form eines eigenen Windowmanagers mit Desktop, Taskleiste und Fenstern dargestellt werden kann, aber auch als vollständiger eigenständiger Browser, verknüpft die GUI die Vorteile von klassischen Windowmanagern mit modernen Browsertechnologien.

Die verwendete dynamische Schachteltechnik, die Komponenten der Interaktionsobjekte in den verschiedenen Hierarchieebenen entlang den verschiedenen Richtungen des Darstellungsgebiets anordnet, verwaltet Bezüge und Hierarchien von Datenelementen der realen Vorrichtung und von externen Informationskomponenten untereinander wesentlich besser, als vollständig frei bewegliche Fenstertechniken. Darüber hinaus ist es den Benutzer einfacher den Gesamtüberblick über die realen und virtuellen Vorrichtungen zu behalten.

Datenobjekte in der virtuellen Vorrichtung und darin eingelagerte Datensätze können im Browser über frei definierbare grafische Bedienelemente selektiv bearbeitet werden.

Eine alternativ text- oder grafikbasierte Navigation in den hierarchischen Elementen der virtuellen Informationssysteme bildet dynamisch Ordnungsgruppen während der Navigation, bildet global und lokal zeitliche Navigationsfolgen für alle Elemente und erleichtert somit die Navigation im Vergleich zu anderen Techniken deutlich.

Durch Einbindung der browsergestützten Darstellung in plattformübergreifende Office-Pakete (z.B. Star-Office 5.x) besteht die Möglichkeit erweiterter Datentypvisualisierung und gleichzeitigen Weiterbearbeitung durch integrierte Office- und Groupwarekomponenten auf einer Vielzahl von Betriebssystemen. Technische Datenobjekte können auf diese Weise sehr einfach in betriebswirtschaftlich relevante Dokumente eingefügt werden. Diese Methode erspart überdies den Wechsel zwischen Applikationen und bringt einen erheblichen Zeitgewinn bei der Informationsbeschaffung und Bearbeitung.

Sekundärnetze beinhalteten als wesentliche Elemente nur Visualisierungsdienste inkl. Interaktionsobjekten und Zusätze für Suchen und Schreiben von Metadatenobjekten auf Webservern und FTP-Server. Durch den Visualisierungsdienst können Datenobjekte auf Web- und FTP Servern komfortabel abgefragt, editiert und gesucht und umstrukturiert werden. Das Sekundärnetz ist optimal geeignet für die Einbindung von technischen Kleinstmodulen in das Gesamtnetzwerk. Es erlaubt die clientseitige Vernetzung von hochorganisierten Kleinstanwendungen technischer, kommerzieller und dokumentarischer Natur mit anderen Sekundärnetzen(z.B. auf der Basis von FTP Diensten und Webservern.) sowie die optisch nahtlose clientseitige Einbindung in das Primärnetz in ein übergreifendes Organisationsprinzip bei minimalsten Ressourceneinsatz (Auf der Serverseite läuft nur der FTP bzw. der Webserver). Darüber hinaus können Teilstrukturen von Web. bzw. FTP- Servers durch internes mounten virtuell überlagert werden und auf diese Weise Datenobjekte mit unterschiedlichen Eigenschaften gebildet werden. Die FTP- bzw. WebServer dienen als ausgelagerte dezentrale Datenbanken (dessen Inhalte natürlich auch dynamisch Prozeßwerte enthalten können), dessen Metaobjektsätze zyklisch vom Primärnetz abgefragt werden können. Das sekundäre Netz ermöglicht die kontrollierte dynamische Erweiterung des Gesamtdatenbestandes mit einfachsten Mitteln in systematischer Form. Technische und wirtschaftliche Schwierigkeiten bei der Installation und Wartung klassischer Datenbanken entfallen.

Durch überwiegende Nutzung der Rechnerkapazitäten des Clients werden die Serversysteme kaum belastet.

Auf virtuelle Javamaschinen oder ähnliche aufwendige Prozesse kann bei Sekundärnetzen verzichtet werden. Diese sind die für Geräte, die nur Statusinformationen weitergeben oder relativ einfache Funktionen ausüben sollen ungeeignet.

Durch dynamische Generierung von Links aus Metaobjektkomponenten in den virtuelle InformationsObjekten kann eine virtuelle Umstrukturierung der Interaktionsobjekte erfolgen und auf diese Weise die Navigation auch in Sekundärnetzen erleichtern.

I. Hierbei stellen die Figuren einzeln folgendes dar:

Zeichnung 1 : Kommunikationsweqe Zentralkernel Datendienste

1 Zentralkernel mit Objektverzeichnis

2 Kommunikationsrichtungen

3 Datendienst Kernelstruktur

4 Datendienst externe Schnittstelle (z.B. nntp) 5 Datendienst externe Benutzerverwaltung

6 Kerberos Authentifizierungsdienst

7 Datendienst Bedienung und Beobachtung (zum Betrieb eines Bediengeräts)

8 Datendienst IEEE-488 (Meßvorrichtung mit eingebauter Analysevorrichtungen) 9 Datendienst Snmp

10 Datendienst OPC (mit angeschlossenem Regelungssystem)

11 Benachbarter Zentralkernel

Zeichnung 2: Beispiel Schema Datenstrukturintegration

12 Funktionsbereich Mensch (Bedienung und Beobachtung)

13 Funktionsbereich Analyse

14 Funktionsbereich Technik

15 PDA-GUI 16 Internetbrowseroberfläche

17 Echtzeitdatenbank

18 statistische Datenauswertung

19 Echtzeitdatenanalyse

20 Bedienung über Officesoftware 21 Windparkrouter

22 WKA-Prozeß (IEC-1131-3 )

23 Fehlerfrüherkennungssystem WKA

24 Anbindung Internetbrowser

25 Anbindung PDA-Oberfläche 26 XML Anbindung

27 Anbindung Systemmanagement SNMP

28 OPC Anbindung

29 Propieretäre Schnittstelle

30 Anbindung Echtzeitanalyse 31 Anbindung statistische Auswertung

32 Datenbankanbindung

33 gemeinsame Datenstruktur Visualisierung

34 gemeinsame Datenstruktur Datenanalyse

35 gemeinsames Datenmodell Echtzeitdaten 36 gemeinsame Datenstruktur für alle Dienste 37 gemeinsam genutze Datenstrukturen von Visualisierungs- und Analysediensten

38 propieretäre Datenstruktur Datendienst

Zeichnung 3: Logische Kommunikationsmöglichkeiten der Zentralkernel auf einem physikalischen Netzwerk:

39 Internet

40 Zentralkernel im Internet

41 Intranet 42 Zentralkernel im Intranet

43 Zentralkernel in einer Windkraftanlage 1 (Kommunikation erfolgt über das Stromnetz)

44 Netzwerkrouter

45 Zentralkernel in einer Windkraftanlage 2 (Kommunikation erfolgt über das Stromnetz)

46 Alle Zentralkernel können mit allen Zentralkerneln im Netz bidirektional kommunizieren wobei mehrer Verbindungen gleichzeitig gehalten werden.

47 Ein Zentralkernel mit einer ihm aktuell bekannten kommunizierbaren Umgebung

48 Ein Zentralkernel mit einer anderen ihm aktuell bekannten kommunizierbaren

Umgebung

Zeichnung 4: Schema Datenuberlgerung und zentralisierendes Wirkungsprinzip des MetaOS-Datenmodells

49 Zentralkernel 1 mit eingebundenen Datenbeständen benachbarter Knoten und

Analyseschnittstellen, technischen Schnittstellen sowie Bedien- und Beobachtungsschnittstellen 50 Zentralkernel 2 mit eingebundenen Datenbeständen benachbarter Knoten und

Analyseschnittstellen, technischen Schnittstellen sowie Bedien- und

Beobachtungsschnittstellen 51 Zentralkernel 3 mit eingebundenen Datenbeständen benachbarter Knoten und

Analyseschnittstellen, technischen Schnittstellen sowie Bedien- und

Beobachtungsschnittstellen

52 Zentralkernel 4 mit eingebundenen Datenbeständen benachbarter Knoten und

Analyseschnittstellen, technischen Schnittstellen sowie Bedien- und Beobachtungsschnittstellen

53 Zentralkernel 5 mit eingebundenen Datenbeständen benachbarter Knoten und Analyseschnittstellen, technischen Schnittstellen sowie Bedien- und

Beobachtungsschnittstellen

54 Zentralkernel 6 mit eingebundenen Datenbeständen benachbarter Knoten und

55 Zentralkernel 7 mit eingebundenen Datenbeständen benachbarter Knoten und

Analyseschnittstellen, technischen Schnittstellen sowie Bedien- und Beobachtungsschnittstellen 56 externe Funktionseinheit a

57 externe Funktionseinheit b

58 externe Funktionseinheit c

59 externe Funktionseinheit d

60 externe Funktionseinheit e 61 externe Funktionseinheit f 62 externe Funktionseinheit g

63 externe Funktionseinheit h

64 externe Funktionseinheit i

65 Physikalisches Modell verteilter überlappender Datenstrukturen 66 Schnittstellen bilden verschiedene Daten auf einheitlicher lokaler Datenstruktur ab

67 Virtuelles logisches Modell mit einheitlicher Datenstruktur (virtuelle Zentralisierung)

Zeichnung 5: Zuweisung räumlich oder thematisch zusammengehöriger Datendienste zu Zentralstrukturen technischer Geräte

68 Windparkspezifische Datendienste

69 Datendienst externe Benutzerverwaltung Windpark 70 Kerberos Authentifizierungsdienst Windpark

71 Datendienst Netzzustand Windpark

72 Datendienst Windparkleistung

73 Dienst Bedienung und Beobachtung WKA 1

74 Dienst Analyse Meßwete WKA 1 75 Datendienst Snmp WKA 1

76 Datendienst Regelung WKA 1

77 Datendienst Netzüberwachung WKA 1

78 Dienst Bedienung und Beobachtung WKA 2

79 Dienst Analyse Meßwete WKA 2 80 Datendienst Snmp WKA 2

81 Datendienst Regelung WKA 2

82 Datendienst Netzüberwachung WKA 2

83 WKA 2

84 WKA 1 85 Zentralkernel WKA 1 86 Räumlich und/oder logisch zusammengehörige Dienste für WKA 1

87 logisch zusammengehörige Dienste für WKA 2

Zeichnung 6: Funktionsbereiche Zentralkernel 88 Virtueller Objektbaum

89 Command Prozessor

90 Userverwaltung -Defaultuser -Gastuser

91 Kommunikation

92 OPC-Wert 93 NFS-Dateien

94 Nntp Elemetn

95 Analogwerte A/D Wandler

Zeichnung 7: Verteilter MetaOS Knoten logisch zusammengehöriger Daten

96 Linux/GNU-System

97 Zentralkernel

98 IEEE 488-Dienst

99 NFS-Dienst 100 QNX- EchtzeitOS

101 Proprietäre Schnittstelle Regelungssystem 1

102 Java Virtual Machine

103 Regelungsystem 2 mit OPC-Server 104 OPC-Dienst 105 Meßsystem mit IEEE 488 Schnittstelle 106 NFS-Server 107 Regelungssystem 1

Zeichnung 8: Verteilter MetaOS Knoten logisch zusammengehöriger Daten am Beispiel einer Windkraftanlage 108 Windkraftanlage

109 Java Virtual Machine 110 OPC-Dienst

111 Linux/GNU-System 112 Betriebssystem Laptop

113 Regelungssystem 1 mit OPC Sever

114 Regelungssystem 2 mit propietarer Schnittstelle 115 NFS-Server

116 Bedien- und Beobachtungsgerät 117 Dienst Regelungssystem 2 NFS-Dienst

118 NFS-Dienst

119 Schaltschrank

Zeichnung 9: Mischung von Hard/ und Softwarediensten 120 Zentralkernel 121 LDAP Dienst 122 LDAP-Server

123 Datendienst Analogwandler

124 AD/DA-Wand(er Karte

Zeichnung 10: Datendienst Abbildung Datenquelle auf

Objektbaumstruktur

(Kapselung in Datenobjekten)

125 Typkonvertierter Objektbaumbereich 126 Proprietärer Schnittstellenbereich

127 Prozeßwerte

128 Hierarchisch organisierte Logfiles

129 Transformierte Prozeßwerte

130 Transformierte Logfiles 131 Offsetpfadangabe Prozeßwerte 132 Offsetpfadangabe Prozeßwerte

133 Kommunikation Zentralkernel

Zeichnung 11 : Mountbeispiel von Datendiensten an Zentralkernel 134 Zentralkernel mit gemounteten synchronisierten Objektbäumen

135 Datendienst 1 mit typkonvertierten Daten

136 Datendienst 2 mit typkonvertierten Daten

137 Datendienst 3 mit typkonvertierten Daten

138 0PC-Client 139 NFS-Client

140 IRC-Client

141 Datendienst 4 kann Gesamtbaum des Zentralkernels synchronisieren

142 Bedieneinheit für alle Daten des Gesamtbaums

143 Weiterer Zentralkernel im Netzwerk mit gemounteten und synchronisiertem

Gesamtbaum.

Zeichnung 12: Struktur Element Obiektbaum

144 Gesamtelement mit eingelagerten Datenobjekten und Metadatenobjekten.

145 Datenobjekt

146 Metadatenobjekt 1

147 Metadatenobjekt 2

148 Metadatenobjekt 3 149 Header des Metadatenobjekts 1

150 Nutzdaten des Metadatenobjekts 1

151 Datenobjekt und Metadatenobjekt gruppiert zu Gruppe a

152 Metadatenobjekt 1 und Metadatenobjekt 2 gruppiert zu Gruppe b (Überlagerung mit Gruppe a) 153 Metadatenobjekt 1 und Metadatenobjekt 2 gruppiert zu Gruppe c (Überlagerung mit Gruppe b)

Zeichnung 13: Struktur eines Datenobjekts oder Metadatenobiekts

154 Baumstruktur der Headerdaten eines Objektheaders 155 Nutzdaen des Datenobjekts

Zeichnung 14: Schichtung von Informationen eines Datenelements auf dem Zentralkernel

156 Zusammengefügtes Datenelement aus mehreren Elementen verschiedener

Datendienste auf dem Zentralkernel in der Reihenfolge Datendienst 1 , Datendienst 2, Datendienst 3

157 Metaobjekte aus Datendienst 3 158 Objekte und Metaobjekte aus Datendienst 2

159 Objekt aus Datendienst 1

160 Projektionsergebnis aus Synchronisation in der Reihenfolge Objekte aus Datendienst

1 und dann Datendienst 2 (Reihenfolgenprojektion) 161 nicht synchronisiertes Objekt, da schon Objekt aus Schicht Datendienst 1 synchronisiert

162 Metaobjekt aus Datendienst 2 (synchronisiert)

163 Metaobjekt aus Datendienst 2 (synchronisiert) 164 nicht synchronisiertes Metaobjekt, da schon Metaobjekt aus Schicht Datendienst 2 synchronisiert

165 Metaobjekt aus Datendienst 3 (synchronisiert)

166 Im Zentralkernel projizierte Metaobjekte Zeichnung 15: Beispielnutzung Header

167 Datenobjekt

168 Header des Datenobjekts

169 Nutzdaten 170 Timinginformationen zur Synchronisation

171 Informationen zu Ressourcen des lokalen Standorts (CPU, Speicher, Netzwerkkapazitäten)

172 Log- und Fehlerinformationen

173 Informationen zur Administration, Sicherheits- und Transporteigenschaften

174 Popularitäts- und Prioritätseigenschaften

175 Informationen über Art und Zustand der Bedien- und Beobachtungsvorrichtungen

176 Beschreibungsinformationen zu den Objekten 177 Zusammengefaßte Informationen über hierarchisch tiefer und höher liegende

Objektstrukturen

178 Zustand des Datenobjekts

Zeichnung 16: relative Synchronisation

179 Zentralkernel mit Datenelementen in einer hierarchischen Anordnung

180 relative Synchronisation von Nutzdaten eines Datenobjekts über eine Hierarchieebene

181 relative Synchronisation von Nutzdaten eines Datenobjekts über zwei Hierarchieebenen

182 relative Synchronisation von Nutzdaten eines Datenobjekts über drei Hierarchieebenen

183 Vererbung von Headerdaten über mehrere Schichten, durch wiederholte relative Synchronisation 184 relative oder absolute Synchronisation von Nutzdaten aus verschiedenen

Metaobjekten verschiedener Hierarchieebenen und der oprativen Verknüpfung am Zielort.

Zeichnung 17: Nutzung der Synchronsiation zur Analyse (Fiitertung) von Daten.

185 Zentralkernel 186 OPC Datendienst mit angeschlossener technsicher Regelung

187 Datendienst mit angeschlossener technischer Analyseeinheit

188 Datendienst ausgeührt als Bedien- und Beobachtungseinheit

189 Element zu Datendienst enthält technische Prozeßwerte

190 Element zu Datendienst analysiert nach relativer Synchronisation der technischen

Prozeßwerte mit Hilfe des Datendienstes die technischen Daten

191 Element zu Datendienst bereitet nach relativer Synchronisation der Analysedaten die

Analyseergebnisse zur Präsentation auf.

Zeichnung 18: Autokonfiguration durch Synchronisation von Informationen aus hierarchisch höherern Zentralkerneln

192 Zentralkernel 1

193 hierarchisch untergeordneter Zentralkernel 2 194 Element mit Konfigurationsdaten eines Knotens wird von hierarchisch niederem

Zentralkernel synchronisiert.

Zeichnung 19:Schedulinq von Daten- und Metadatenobiekten (Synchronisation) im Zentralkernel 195 Element 1 mit Timiniginformationen

196 Element 2 mit Timiniginformationen

197 Element 3 mit Timiniginformationen

198 Scheduler der Synchronisation von Objekten anhand von Timinginformationen anstößt

199 Datenbank mit Timinginformationen (selbst als Datenobjekt ausgelegt)

Zeichnung 20:Synchronisationsbeispiel von Datendiensten mit prioritätsgesteuerter Überlagerung von Datenbeständen an einem grafischen Mengenschema.

200 Zentralkernel

201 Datendienst 1 mit Priorität 1 202 Datendienst 2 mit Priorität 2

203 Datendienst 3 mit Priorität 3

204 Datenbestände Datendienst 1

205 Teildatenbestand 1 Datendienst 1

206 Teildatenbestand 2 Datendienst 1 207 Datenbestände Datendienst 2

208 Teildatenbestand 1 Datendienst 2

209 Teildatenbestand 2 Datendienst 2

210 Datenbestände Datendienst 3

211 Teildatenbestand 1 Datendienst 3 212 Teildatenbestand 2 Datendienst 3

213 Synchronisierte Datenbestände von Datendienst 1

214 Synchronisierte Datenbestände von Datendienst 2

215 eingefügte Teildatenbestände aus Datendienst 1

216 eingefügte Teildatenbestände aus Datendienst 3 217 Überlagerung als identisch gekennzeichneter Datenbestände aus verschiedenen

Datenbetänden mit unterschiedlichen Prioritäen 218 Metadaten aus Datendienst 1 , welche in Datendienst 3 nicht vorhanden sind, werden durch den Projektionsmechanismus angezeigt, da sie nicht von den den Metadaten aus Datendiesnt 3 überlagert werden.

Zeichnung 21 : 219 Zentralkernel WKA

220 Datendienst Prozeßwerte

221 Datendienst Logfiles

222 Datendienst nntp

223 Schaltschrank 224 Synchronsationswege

Zeichnung 22: Eigenschaftsschichtung (Mounten) (Metaobjekten und Headerobiekten) im Zentralkernel

225 Wurzel des virtuellen Objektbaums des Zentralkernels 226 virtuelles Filesystem Datendienst

227 Element a

228 Element b

229 Element b'

230 Eigenschaften Element b (Objekte, Metaobjekte) 231 Eigenschaften Element b'

232 Element c

233 Element d

234 Element c'

235 Elememt d' 236 Eigenschaften x1 ,x2 237 Eigenschaften y1

238 Eigenschaften x3.x4

239 Eigenschaften y2

240 Wurzel des resultierenden virtuellen Objektbaums des Zentralkernels 241 Element a

242 Element b

243 Eigenschaften Element a

244 Element c

245 Element d 246 Eigenschaften x1 ,x2,x3,x3

247 Eigenschaften y1 ,y2

Zeichnung 23: Beispiel für die Verwendung von Operatoren während der Projektion Schichtung von syntaktisch ähnlichen Elementbäumen.

248 Wurzel des virtuellen Objektbaums des Zentralkernels

249 Virtuelles Filesystem Datendienst

250 Element a

251 Element Artist 252 Element Artisten

253 Element y mit Eigenschaft y1

254 Element b

255 Eigenschaften x3,x4

256 Element y' 257 Eigenschaften y2

258 Wurzel des virtuellen Objektbaums des Zentralkernels

259 Element a

260 Element Artist*

261 Element y 262 Eigenschaften y1 ,y2 263 Element b

264 Eigenschaften x3,x4

Zeichnung 24: Zugriff auf Objekte im MetaOS Knoten Zugriff auf Element Karl, Eigenschaft y2. Element wird im Zentralkernel gecached

265 Wurzel des virtuellen Objektbaums des Zentralkernels mit Anfrage ausgehend vom

Zentralkernel 266 virtuelles Filesystem Datendienst

267 Element a

268 Element b an wekches ein Datendiesnt gemountet ist

269 Element Karl

270 Eigenschaften y1 271 Element b'

272 Element c

273 Eigenschaften x3,x4

274 Element Karl'

275 Eigenschaften y2

Zeichnung 25:Spiegelung und Verteilung von Datenobjekten Schreiben der Eigenschaft x auf Elemente Artist in verschiedenen Datendiensten

276 Virtuelles Filesystem Datendienst 1 mit Priorität 1 277 Wurzel des virtuellen Objektbaums des Zentralkernels

278 Virtuelles Filesystem Datendienst 2 mit Priorität 2

279 Element Artist'

280 Eigenschaften Element Artist

281 Element a 282 Element Artist 283 Element Artist "

284 Eigenschaften Element Artist "

285 Mountstruktur Datendienst 1

286 Mountstruktur Datendienst 2

Zeichnung 26: Replizierung von Daten entlang des Transportweges von Elementen in den Zentralkerneln

287 Wurzel des virtuellen Objektbaums des Zentralkernel 1

288 Wurzel des virtuellen Objektbaums des Zentralkernel 2 289 Wurzel des virtuellen Objektbaums des Zentralkernel 3

290 Element a mit Eigenschaften

291 Element b mit Eigenschaften

292 Element b' mit Eigenschaften

293 Element b' mit Eigenschaften 294 Element c mit Eigenschften x3,x4

295 Kopie von Element c von Knoten 3 mit Eigenschften x3,x4

296 Element d mit Eigenschaften x1 ,x2

297 Kopie von Element c von Knoten 2 mit Eigenschften x3,x4

298 Kopie von Element d von Knoten 2 mit Eigenschften x1 ,x2 299 Kopierrichtung

300 Mountstruktur

Zeichnung 27: Getrennte Verwaltung von verschiedenen Metaobjekten in verschiedenen Datendiensten 301 Virtuelles Filesystem Datendiesnt OPC

302 Wurzel des virtuellen Objektbaums des Zentralkernel 1

303 Virtuelles Filesystem Datendiesnt SQL

304 Element a

305 Element b 306 Element c 307 Eigenschaft x1

308 Eigenschaft x2

309 Eigenschaft x3

310 Eigenschaft x4

Zeichnung 28: Bildung einer Symbiose (Additive Schichtung) Knoten 2 und Knoten 3 mounten Verzeichnisse entsprechend Knoten 1

311 Wurzel des virtuellen Objektbaums des Knoten 1 312 Wurzel des virtuellen Objektbaums des Knoten 2

313 Wurzel des virtuellen Objektbaums des Knoten 3

314 Selbstmount Objekte aus Objektbaum 1

315 Mount Objekte aus Objektbaum 2

316 Mount Objekte aus Objektbaum 3 317 Ordner für alle Verzeichnisse aus der Symbiose

Zeichnung 29:

318 Wurzel Zentralkernel WKA 1

319 Wurzel Zentralkernel WKA 2 320 Wurzel Zentralkernel WKA 3

321 Mount Datenbestände WKA 1

322 Mount Datenbestände WKA 2

323 Mount Datenbestände WKA 3

324 Startpunkt Gesamtdatenbstand 325 WKA 1

326 WKA 2

327 WKA 3

328 Schaltschrank WKA 1

329 Schaltschrank WKA 2 330 Schaltschrank WKA 3 Zeichnung 30: Beispielkopplung Primärnetz und Sekundärnetz in der Ben utzeroberf lache

331 OPC-Server der WKA Steuerung 332 Nntp-Server

333 Primärnetzknoten mit Datendiensten

334 Elektrisches Schaltgerät mit HTTP-Server

335 Schaltschrank Windkraftanlage

336 Windkraftanlage 337 Internet

338 Benutzeroberfläche des Sekundärnetzes

339 Benutzeroberfläche des Primärnetzes

Zeichnung 31 : Kontaktieren einer Symbiose 340 Knoten 1

341 Knoten 2

342 Knoten 3

343 Knoten 4

344 Virtueller mount Knoten 1 345 Virtueller mount Knoten 3

346 Direkter mount Knoten 2

Zeichnung 32:

347 OPC-Dienst 348 Nntp-Dienst

349 Primärnetzknoten

350 Virtueller Objektbaum

351 Benutzeroberfläche Primärnetz

352 Sekundärnetzknoten (z.B. Http oder FTP Server) 353 Benutzeroberfläche Sekundärnetz 354 Symiink Sekundärnetz (Startet Benuitzeroberfläche Sekundärnetz)

Zeichnung 33: Einkopplung Datenbestände Sekundärnetz in Primärnetzzentralkernel 355 OPC-Dienst

356 Nntp-Dienst

357 Primärnetzknoten

358 Virtueller Objektbaum

359 Sekundärnetzdienst 360 Sekundärnetzknoten (z.B. Web oder FTP Server)

Zeichnung 34: Visualisierung über einen Datendienst (z.B. als Javaclient)

361 Rechner 1 362 Zentralkernel

363 Telnet-Dienst

364 FTP-Dienst

365 IMAP-Dienst

366 Benutzerschnittstelle auf Rechner 2 367 Objektbaumstruktur Datendienst

368 Grafikausgabeteil Datendienst

Zeichnung 35: Visualisierung über eine getrennte Clientsoftware

369 Rechner 1 370 Zentralkernel

371 NFS-Dienst

372 OPC-Dienst

373 Corba-Dienst

374 Benutzerschnittstelle auf Rechner 2 375 Objektbaumstruktur Datendienst 376 Proprietärer Teil Datendienst

377 Grafikausgabeteil Datendienst

Zeichnung 36:Objektbaumexplorer 378 Basisbedienleiste Explorer

379 Strukturierungsordner

380 Objekte aus Datendienst 1

381 Objekte aus Datendienst 2

382 Objekte aus Datendiesnt 3 383 Objekte aus Datendienst 4

Zeichnung 37: Objektbaumexplorer mit Metadatenobjekten

384 Vordefinierte Anzeigemuster für Metadatengruppen (in den Headern der Metadaten verschlüsselt)

385 Basisbedienleiste Explorer

386 Objekt des virtuellen Objektbaumes

387 Metaobjekte der Baumobjekte

Zeichnung 38: vordefinierte Objektansicht (Symbolansicht)

388 Basisbedienleiste Explorer

389 Objekte

Zeichnung 39: vordefinierte Obiektansicht in Metadaten verschlüsselt (Ansicht Real)

390 Basisbedienleiste Explorer

391 HTML-Seite mit eingebetteten Metadaten oder Javaapplet

Zeichnung 40: Obiektansicht Obiektmanager 392 Basisbedienleiste Explorer 393 Objekt 1 (sichtbar)

394 Objektübersicht

395 Objektl in Taskleiste

396 Objekt2 in Taskleiste (aktiv, jedoch nur in Taskleiste sichtbar) 397 Objekt3 in Taskleiste (aktiv, jedoch nur in Taskleiste sichtbar)

398 Objekt4 in Taskleiste (aktiv, jedoch nur in Taskleiste sichtbar)

399 Objektδ in Taskleiste (aktiv, jedoch nur in Taskleiste sichtbar)

400 Objekt6 in Taskleiste (aktiv, jedoch nur in Taskleiste sichtbar)

Zeichnung 41 : Darstellung mehrerer Objekte

401 Basisbedienleiste Explorer (Informationen von WKA1 und WKA2 sind z.B. von externen Knoten synchronisiert worden)

402 Objekt Windkraftanlage 1 Ansicht Real 403 Objekt Windkraftanlage 2 Ansicht Real

404 Objektübersicht

405 Taskleistenrepräsentation WKA 1

406 Taskleistenrepräsentation WKA 2

407 Basisbedienleiste WKA 1 408 Basisbedienleiste WKA 2

Zeichnung 42: Einbindung von Fremdinformationen

409 Basisbedienleiste Explorer

410 Objekt 1 (sichtbar) (z.B Windkraftanlage 1 ) 411 Objekt 2 (sichtbar)

412 Objektübersicht

413 Desktop (z.B. mit Geoinformationssystem)

414 Basisbedienleiste innerer Explorer 1

415 Basisbedienleiste innerer Explorer 2 Zeichnung 43: Schachtelung von Windowmanagern

416 Basisbedienleiste Explorer

417 äußerer Desktop

418 Basisbedienleiste innerer Explorer 1 419 Basisbedienleiste innerer Explorer 2

420 Objektübersicht

421 Innerer Desktop 1

422 Innerer Desktop 2

Zeichnung 44: Schachtelung von Windowmanagern am Beispiel von Windkraftanlagen

423 Basisbedienleiste Explorer

424 Äußerer Desktop mit Visualisierung von Windkraftanlagen eines Windparks (z.B als statistische Übersicht)

425 Basisbedienleiste innerer Explorer 1

426 Basisbedienleiste innerer Explorer 2

427 Objektübersicht

428 Innerer Desktop 1 mit WKA 1 429 Innerer Desktop 2 mit WKA 2

430 Teildatenbestand 1 WKA 2

431 Teildatenbestand 2 WKA 2

432 Unterkomponente 1 Teildaten bestand 2 WKA 2

433 Unterkomponente 2 Teildatenbestand 2 WKA 2 434 Teildatenbestand 1 WKA 1

435 Teildatenbestand 2 WKA 2

436 Taskleistenrepräsentation WKA 1

437 Taskleistenrepräsentation WKA 2

Zeichnung 45: Auskopplunq einer Untermenge des virtuellen Dateibaums eines MetaOS-Knotens

438 Basisbedienleiste Explorer

439 Äusserer Desktop

440 Basisbedienleiste Objekt 1 441 Basisbedienleiste Objekt 2

442 Ansicht Objekt 1

443 Desktop Objekt 2

444 Objekt 2.1 Ansicht Real

445 Objekt 2.2 Ansicht Real 446 Objektübersicht

447 Objektübersicht von Pespektive des Objekts 1

448 Taskleistenrepräsentation Objekt 1

449 Taskleistenrepräsentation Objekt 2

Zeichnung 46: Grafische Trenung Zentralkernel in Teildatenbestände der Datendienste

450 Basisbedienleiste Zentralkernel

451 (Teil)datenbestand Zentralkernel

452 Basisbedienleiste Datendienst 1 453 (Teil)datenbestand Datendienst 1

454 Basisbedienleiste Datendienst 2

455 (Teil)datenbestand Datendienst 2

456 Basisbedienleiste Datendienst 3

457 (Teil)datenbestand Datendienst 3

Zeichnung 47: Mehrfachauskopplung von Untermengen

458 Basisbedienleiste Explorer

459 Äusserer Desktop

460 Basisbedienleiste innerer Explorer 461 Objektübersicht innerer Explorer. 462 Ansicht Objekt 1

463 Ausgekoppeltes Objekt 1

464 Ausgekoppeltes Objekt 2

465 Ausgekoppeltes Objekt 3

Zeichnung 48: Objektmanager im dreidimensionalen Raum

466 Objektmanager 1

467 Objektmanager 2

468 Objektmanager 3

Zeichnung 49: Obiektmanager in dreidimensionaler Darstellung

469 Objektmanager 1

470 Objektmanager 2

471 Objektmanager 3 472 Objektmanager 4

Zeichnung 50: Eine Anzahl abstrahierter Objektmanager in dreidimensionaler Darstellung

473 Objektmanager 1 474 Objektmanager 2

475 Objektmanager 3

476 Objektmanager 4

477 Objektmanager 4.1

478 Objektmanager 4.1.1 479 Objektmanager 4.1.2

480 Objektmanager 4.1.3

Zeichnung 51 : Obiektmanager dreidimensional mit Windkraftaniaqen

481 Darstellung Windpark 1 482 Darstellung Windpark 2 483 Darstellung Windpark 3

484 Darstellung Windpark 4 mit Unterobjekten

485 Darstellung Teilbereich Windpark 4

486 Darstellung Windpark 4 Anlage 1 487 Darstellung Windpark 4 Anlage 2

488 Darstellung Windpark 4 Anlage 3

Zeichnung 52: Logische Grundstruktur MetaOS Netz

489 Virtuelles Zentrum aus hierarchisch höchsten Knoten 490 proprietäre Schnittstellenstrukturen

491 Mountstruktur der Zentralkernel zur Bildung einer grundlegenden logischen Hierarchie.

492 externer Datendienst 1 Knoten A

493 externer Datendienst 2 Knoten A 494 externer Datendienst 3 Knoten A

495 externer Datendienst 4 Knoten A

496 externer Datendienst 5 Knoten A

497 externer Datendienst 6 Knoten A

498 externer Datendienst 1 Knoten B 499 externer Datendienst 1 Knoten B

500 externer Datendienst 1 Knoten B

501 externer Datendienst 1 Knoten B

502 externer Datendienst 1 Knoten B

503 externer Datendienst 1 Knoten B

Zeichnung 53: Mountschema für einen dezentralen global einheitlichen Objektbaums

504 Oberste Hierarchie (virtuelles Zentrum) bestehend aus einer Symbiose aus drei Knoten 505 Knoten mit statischen Daten 506 Hierarchieebene 1

507 Hierarchieebene 2

508 Hierarchieebene 3

509 Hierarchieebene 4 510 Datenbaum mit externen Schnittstellen (dynamische Daten)

511 externe Schnittstelle 1

512 externe Schnittstelle 2

513 externe Schnittstelle 3

514 externe Schnittstelle 4 515 externe Schnittstelle 5

516 externe Schnittstelle 6

517 Hierarchie 3 bestehend aus einer Symbiose zweier Knoten

518 Synchronisation des Globalbaums aus Hierarchie 2 für einheitlicher Zugriff auf das Globalnetz von jedem Knoten

519 Synchronisation der unteren Hierarchien an lokale Datenbestände zur Bildung eines

Regionalbaums

520 Synchronisation des Globalbaums aus oberster Hierarchie (oberste Hierarchien können nach Synchronisation von niederen Hierarchien simuliert werden und müssen nicht real vorhanden sein)

521 Bildung Regionalbaum an oberster Hierarchie 522 lokale Datenbestände werden global zur Verfügung gestellt

Zeichnung 54: Beispiel logische Verknüpfung mit Windkraftanlagen und Solarmodulen

523 Virtuelles Zentrum des Gesamtnetzes 524 Server mit groben Strukturdaten für das Gesamtnetz, welche an alle Knoten vererbt werden

525 Server mit ergänzenden Strukturdaten für das Windparknetz.

526 Server mit ergänzenden Strukturdaten für das Solarnetz, welche an alle Zellen vererbt werden

527 Knoten WKA 1

528 Datendienste im Turmkopf von WKA 1

529 Knoten WKA 2 530 Datendienste im Turmkopf von WKA 2

531 Solarzelle 1

532 Datendienste in Solarmodul 1

533 Knoten Solarmodul 1

534 Datendienst Steuerung Solarmodul 1 535 Datendienst Analyse Solarmodul 1

536 Solarzelle 2

537 Datendienste in Solarmodul 2

538 Knoten Solarmodul 2

539 Datendienst Steuerung Solarmodul 2 540 Datendienst Analyse Solarmodul 2

Zeichnung 55: Knotenkenntnisse Gesamtnetz und Kommunikation

541 Knoten 1

542 bekannte lokale Umgebung Knoten 1 543 Knoten 2

544 bekannte lokale Umgebung Knoten 2

545 externer Dienst a Knoten 1

546 externer Dienst b Knoten 1

547 externer Dienst c Knoten 1 548 externer Dienst d in gelernter Umgebung von Knoten 1 549 externer Dienst e in gelernter Umgebung von Knoten 1

550 externer Dienst f in gelernter Umgebung von Knoten 1

551 Direkte Kommunikation aller externen Dienste mit gelernter Umgebung über Zentralkernel Knoten 1

552 Überlappungsgebiet bekannter lokaler Umgebungen (Erhöhung der Robustheit der

Gesamtstruktur)

553 „logisches" Grundgerüst für globalen Datenbaum (gemountet und synchronisierte

Grundstrukturen)

554 bekannte globale Umgebung für alle Knoten incl. Knoten 1 und 2 (virtuelles Zentrum).

Zeichnung 56: Kommunikation mit bekannter Umgebung

555 Knoten 1

556 Mountstruktur der Knoten

557 bekannte Umgebung Knoten 2

558 gleichzeitige Kommunikationsmöglichkeit von Knoten 1 mit allen bekannten Knoten

Zeichnung 57: Indizes und Änderungsmeldungen

559 Änderungsmeldung Knoten 3 an Knoten 2

560 Knoten 1 561 Änderungsmeldung an übergeordnete Hierarchie

562 Änderungsmeldung über zwei Hierarchieebenen

563 bekannte Umgebung Knoten 1

564 bekannte Umgebung Knoten 2

565 Symbiose zweier Knoten 566 Indexstruktur Knoten als Objekt oder Metaobjekt 567 Knoten 2 fragt nach Änderungen über zwei Hierarchieebenen

568 Knoten 2 fragt nach Änderungen in übergeordneter Struktur

569 Knoten 2

570 Knoten 3

II. Ausführungsbeispiele

Eine Sammlung von räumlich oder thematisch zusammenhängender Diensten, genannt ein MetaOS-Knoten (Fig. 1) wird zusammengehalten durch einen kompakten Zentralkernel mit integriertem Command Prozessor, der die Kommunikation innerhalb eines Knotens definiert, die Dienste zentral strukturiert und organisiert, Objektdaten cached und eine rudimentäre Zugriffskontrolle bereitstellt (Fig. 6). Jegliche Kommunikation der Dienste erfolgt koordiniert über den Zentralkernel.

Alle Zentralkernel können mit allen Zentralkerneln im Netz bidirektional kommunizieren wobei mehrer Verbindungen gleichzeitig gehalten werden (Fig. 3).

Dienste des MetaOS-Knotens laufen auf unterschiedlichen, dezentralen unterlegten physikalischen oder logischen Maschinen, beispielsweise auf einem QNX-Echtzeitrechner, einem Linux Rechner und einer Java Virtual Maschine (Fig. 7).

Fig. 8 zeigt ein Beispiel eines verteilten MetaOS Knotens am Beispiel einer Windkraftanlage.

Dienste implementieren Filesysteme, Netzwerkdienste, Gerätetreiber etc.. oder stellen diese über ein Gateway bereit. Fig. 5 zeigt ein Zuordnungsbeispiel von Datendiensten zu Zentralkerneln in Windkraftanlagen

Im Gegensatz zu klassischen Mikrokernel basierten Kemelclustem von Betriebssystemen, die ausschließlich für die Bereitstellung von Ressourcen ihrer eigenen Hardware in Form von Schnittstellen zu sorgen haben, sorgt ein MetaOS-Knoten auch für die Bereitstellung höher organisierten logischen Ressourcen eigener und fremder Hardware und Betriebssystemen. Ein Dienst eines Meta-OS Objektes unterscheidet daher nicht zwischen Hardware und Softwareressourcen (Fig. 9).

Ausführungsbeispiele für Dienste:

- Prozeßgateways (z.B. OPC)

- Netzwerkfilesysteme (NFS, WebNFS, Samba etc..) - Verzeichnisprotokolle und Netzdienste (Jini, LDAP)

- Objektorientierte oder relationale Datenbanktreiber.

- Mail und Newsclients

- Internet Relay Chat (IRC)

- Jeder Dienst eines MetaOS-Knotens ist in zwei Teile aufgeteilt. Ein Teil des Dienstes greift als Client auf außerhalb von MetaOS-Knoten liegende Datenobjekte und Dienste zu (bzw. bildet einen Server für externe Clients,) der andere Teil bildet eine Serverstruktur für den Zentralkernel. Im einfachstem Fall ist dies ein einfacher Wert, im allgemeinsten Fall sich dynamisch ändernde Objektstrukturen (Fig. 10). - Die verschiedenen Datendienste eines Knotens werden an beliebigen Stellen an einer virtuellem hierarchischen Objektstruktur (Element/Cluster-Tree) des Zentralkernels angehängt (gemountet). Für den Zentralkernel sieht die Struktur der gemounteten Dienste genauso aus, wie der eigene virtuelle Objektbaum (Fig. 11). Verschiedenste Datenstrukturen werden so in eine gemeinsame Struktur auf dem Zentralkernel integriert (Fig. 2)

Fig.21 veranschaulicht das Anhängen von Datendiensten in den Zentralkernel einer Windkraftanlage. Mehrere Zentralkernel werden weiterhin in eine Gesamtstruktur aller

Zentralkernel integriert (Fig. 4).

- Mountvorgänge können an verschiedenen Stellen im virtuellen Objektbaum durchgeführt werden, aber auch so, daß mehrere Dienste mit zum Teil gleich strukturierten und benannten Dateibäumen beginnend bei einem Mountpunkt virtuell übereinandergelegt werden

(Fig. 22).

- Objektbäume können auch mittels „syntaktisch/semantischer Logik" oder anderer logischer Objektordnem gemountet werden, so daß syntaktisch/semantisch ähnliche Objektordner jeweils zu einem einzigen Objektordner verschmolzen werden (Fig. 23).

Objektbäume können auch durch relative Mountangaben über ein oder mehrere Hierarchien synchronistert werden (Fig.16). Fig. 17 veranschaulicht die Nutzungsmöglichkeiten bei der Analyse von Daten.

Durch relative Synchronisation können auch Konfigurationsdaten von einzelnen Zentralkerneln über mehrere Hierarchieebenen weitergegeben werden und so weitere Knoten konfiguriert werden. Sind in mehreren Knoten Konfigurationsdaten vorhanden werden diese durch den Projektionsmechanismus aggregiert.

Ausführungsbeispiele für übereinandergelegte Eigenschaften von gemounteten Diensten:

Die Grundstruktur eines Datenelements auf dem Zentralkernel zeigen Fig.

(2) und Fig. (3)

Lesezuqriff: Kann auf eine Objekteigenschaft im Objektbaum des Zentralkernels nicht zugegriffen werden, so versucht der Zentralkernel, Zugriff auf die Objekteigenschaft über andere für dieses Objekt zuständige Dienste zu erlangen. Zuständige Dienste können lokale Objektdienste gleicher oder höherer gelegener Position im Objektbaum sein, aber auch weitere, gemountete MetaOS-Knoten (Fig. 24). Die Reihenfolge der Suchzugriffe auf die verschiedenen Dienste wird über die Reihenfolge der Mountpunkte in den Mountlisten der Objekte festgelegt. (Fig. 14) zeigt ein Schema fü die Schichtung von Informationen aus mehreren Datendiensten. Für die Header der Datenobjekte (Fig. 15) gelten die gleichen

Eigenschaften für die Schichtung und Projektion von Informationen wie für die Nutzdaten.

Die Synchronisationsreihenfolgen der Elemtne und Datenobjekte im Zentralkernel werden über einen Scheduler im Zentralkernel festgelegt, der mit den Timinginformationen aus den Headern arbeitet. (Fig. 19)

Fig. 20 zeigt ein Synchronisationsbeispiel von Datendiensten mit prioritätsgesteuerter

Überlagerung von Daten beständen an einem grafischen Mengenschema. Jeder Datenmenge repräsentiert dabei einen (Teil)datenbaum der Datendienste

Spiegelung und Verteilung von Datenobiekten:

- Pro MetaOS-Knoten können eine oder mehrere Datenbanken eingehängt werden, die Datenobjekte anderer Objektdienste speichern oder Datenobjekte in Datendienste schreiben. Bei einem Schreibzugriff auf ein Element eines Zentralkernels, versucht der Zentralkernel auch in alle anderen gemounteten Elemente zu schreiben (Fig. 29).

- Angefragte Datenobjekte werden standardmäßig entlang des Transportweges repliziert (Fig. 26). Daten und Metadatenobjekten:

Getrennte Verwaltung von Datenobjekten und Metadatenobjekten in verschiedenen Datendiensten (Fig. 27).

Mountbeispiele für Zentralkernel:

- Symbiose:

Zusammenführung und Abgleich von virtuellen MetaOS- Informationsobjekten einer Gruppe von MetaOS-Knoten in einem Ordner »Gesamt«. Das komplette Informationsobjekt aller Cluster steht neben den lokalen Datenobjekten auf jedem Einzelrechner dieses Objekts bereit (Fig. 13).

Fig. 29 zeigt die Zusammenschaltung dreier Windkraftanlagen zu einem virtuellen

Gesamtprozeß.

- Mounten von Symbiosen durch weitere MetaOS-Knoten (Fig. 31). Knoten 4 empfängt zusätzlich Knotenadressen und weitere Informationen aus den Metadaten von Knoten 1 und Knoten 3 als losen vermountknoten zur Verbesserung der Strukturstabilität.

Vernetzung von Primärnetz und Sekundärnetz:

- Vernetzung von Primärnetz und Sekundärnetz über den Client (Fig. 32 und Fig. 30) Sekundärnetz wird in die Benutzeroberfläche des

Primärnetzes eingebunden .

- Vernetzung von Primärnetz und Sekundärnetz mit Hilfe eines MetaOS- Knoten (Fig. 33).

Benutzerschnittstellen: Die Kommunikation eines MetaOS-Knotens mit einem Benutzer erfolgt über Visualisierungsdienste. Visualisierungsdienste sind selbst Bestandteile von MetaOS-Knoten und kommunizieren mit Hilfe des Commandprozessors wie die anderen Knoten des Objekts auch. Ein MetaOS-Knoten kann mehrere Visualisierungsdienste auf verschiedenen Maschinen verwalten. Jeder Visualisierungsdienst kann mehrere Benutzerschnittstellen generieren.

Ausführungsbeispiel 1 :

Meta-OS Knoten mit verschiedenen Visualisierungsdiensten auf einer auf einem Knoten( Bedienung über Telnet, FTP oder IMAP Mailclient) (Fig. 34) (361-365).

Ausführungsbeispiel 2:

Meta-OS-Knoten mit einem Visualisierungsdienst und Webserver auf zwei Maschinen. Die Bedienung erfolgt über einen Webbrowser und pagereload. Die Rechenleistung des Clients wird nicht genutzt. Der Visualisierungsdienst erhält einen eigenen in der Leistungsfähigkeit skalierbaren Windowmanager, dessen Grafikressoucen vom Webbrowser bereitgestellt werden (Fig. 35).

Ausführungsbeispiel 3: Um die Geschwindigkeit der Benutzeroberfläche zu erhöhen kann ein Meta-OS Knoten mit einem modularen Visualisierungsdienst als JavaApplet/JavaBean/ActiveX Komponente z.B. in einem Webbrowser abgebildet werden. Der Benutzterschnittstelle wird vollständig clientseitig generiert und im Webbrowser durch HTML/XML Elemente realisiert (Fig. 34 366-368). a) Darstellung einiger grundlegender zweidimensionaler Darstellungsformen (Fig. 19).

Fig. 36 Objektübersicht Fig. 37 Objektübersicht detailliert Fig. 38 Symbol Fig. 39 Real Fig. 40 Objektmanager

Die Auswahl eines Objekts öffnet das jeweilige Objekt im Explorerfenster, oder nach Angaben, die in dem Header des Objekts selbst stehen. b) Vergleichsmodus mehrerer Windkraftanlagen (Fig. 40). c) Einbindung von Fremdinformationen (Geoinformationssystem, VRML, Robotervisualisierung) (Fig. 42). d) Schachtelung von Darstellungsformen eines Objektmanagers z.B. Objektmanager im Objektmanager (Fig. 43). Ein Beispiel mit

Windkraftanlagen zeigt Fig. 44 e) Auskoppeln von Untermengen d1 ) Auskoppeln von Untermengen unter Beibehaltung des Bezugspunktes (2*Objektmanager einer geschachtelt) (Fig. 45)

Grafische Trennung der Datenbestände Zentralkernel in Teildatenbestände der Datendienste (Fig. 46). Die Datenbestände auf dem Zentralkernel werden den Datendienstquellen zugeordnet angezeigt. d2) Mehrfachauskopplung von Untermengen (Fig. 47). Schließen der

Objekte Übersicht schließt auch alle ausgekoppelten, hierarchisch untergeordneten Fenster d) Interaktionsraum 3 dimensional d1) Objektmanager im Raum gestapelt (Fig. 48) d2) Windowmanager im 3d-Modus im Ring mit gewürfelten Unterelementen (Fig. 49) d5) 2^* Mehrfachauskopplung aus Windowmanager im Ring unter Beibehaltung der Bezüge (Fig. 50)

Wird eines der Basiselemente (Element 1 ) geschlossen, werden auch alle untergeordneten Elemente geschlossen

Ein Beispiel mit Windparks und Windkraftanlagen zeigt (Fig: 51)

Ansonsten stehen im 3d Raum die gleichen Elemente wie in der zweidimensionalen Fläche zur Verfügung.

Beispiel für vierdimensionale Abbildung:

Die Abbildung einer vierdimensionalen Struktur auf einen 3-dimensionalen Raum ergibt jeweils Gruppen von verschiedenen Gebilden. Betrachtet man z.B. die Navigation durch das virtuelle Informationsobjekt (Zeit) als vierte Dimension, so kann von jedem geöffneten Fenster aus ein Schritt zurück größere dreidimensionale Strukturdarstellungen verändern (z.B. das Schließen von ganzen Unterbäumen im dreidimensionalen Raum).

Der jeweils entsprechende Visualisierungsdienst wird automatisch mit den benötigten Ressourcen zum Client gesendet. Der Visualisierungsdienst enthält neben den Strukturdaten des virtuellen Informationsobjekt auch eine Strukturbeschreibung eines browsereigenen skalierbaren Windowmanagers und eines Browsers im Browser. Die Minimalanforderungen für den Visualisierungsdienst im Beispiel 3 sind für die Programmiersprache Java Javal .0/Live Connect/Javascript 1.0/HTML 3.2 mit Frameerweiterungen, (wichtig für Mobile Geräte). Da der Visualisierungsdienst nur minimale Grafikstrukturen übermittelt, ist er sehr kompakt und wird schnell über Leitungen transportiert. Knoten werden standardmäßig in einer logischen Baumform zu einer Grundstruktur verknüpft (Fig. 52)

Die detailierte Verknüpfungslogik zeigt das hierarchische Mountschema in Fig. 53 zur Konstruktion eines dezentralen global einheitlichen Objektbaums, wobei einzelne Knoten selbst Symbiosen darstellen können. Das Mountschema erzeugt einen einheitlichen globalen Datenbaum in jedem Knoten, sowie einen regionlen Datenbereich, beginnend mit den lokalen Datenbeständen in dem die lokalen Datenbestände mit den lokalen Datenbeständen der niederen Hierarchien synchronisiert werden. Höhere Hierarchieebenen können nach der Synchronisation durch niedere Hierarchieebenen simuliert werden und müssen nicht real vorhanden sein, d.h. Sie dürfen zeitweise ausfallen ohne die Struktur des Netzwerks zu gefährden.

Fig.54 zeigt eine Beispielspielanwendung des Netzwerkes mit dezentralen Energieanlagen, in welchem das virtuelle Zentrum die Strukturdaten für das Netzwerk verwaltet, die oberste Hierarchie die Grobstruktur des gesamten Netzwerks, und die tieferliegenden Hierarchien ergänzende Strukturdaten. Die unteren Hierarchien synchronisieren die Strukturdaten der höherliegenden Hierarchien und führen diese mit den lokalen Strukturdaten zusammen

Fig.55 veranschaulicht das Grundwissen jedes einzelnen Knoten über das Gesamtnetzwerk nach Eintritt in das Netzwerk und den Lernvorgang über das Netzwerk durch Navigation. Bei Eintritt in das Netzwerk lernt die Knoten zunächst die Struktur der lokalen Umgebung und die Struktur des virtuellen Zentrums durch Synchronisationsvorgänge. Durch die Überlappung der synchronisierten, bekannten Umgebungen dürfen einzelne Knoten ausfallen, ohne daß das Netzwerk in seiner Grundstruktur beeinträchtigt wird.

Fig.56 veranschaulicht die gleichzeitigen bidireltionalen Kommunikationsmöglichkeiten eines Knotens mit der bekannten Umgebung

Fig. 57 stellt die Verteilung von Indizes im Gesamtnetz dar und beschreibt, wie Änderungen im Netzwerk über das gesamte Netzwerk weitergereicht werden. Zu höheren Hierarchieebenen werden Änderungen in den Objektbäumen ereignisorientiert gemeldet, hierarchisch niedere Ebenen fragen selbständig nach Änderungen in höheren Hierarchieschichten indem Änderungsflags durch relative Synchronisation geholt werden.

Claims

Patentansprüche

1.

Vorrichtung zur Modellierung, integrierten Überwachung, Steuerung, Regelung, Analyse und Datenspeicherung von komplexen technischen Verfahrensabläufen basierend auf einzelnen Meß-, Analyse-, Regelungs-, Bedien-.Beobachtungs- und Speichervorichtungen dadurch gekennzeichnet, daß die Vorichtung wenigstens einen Zentralkernel mit jeweils einer integrierten Zugangskontrolle, separater Kontrolle für die Verwaltung von Tasks, Threads, Speicher, Netzwerkkapazitäten und jeweils eine hierarchisch strukturierte Objektbaumverwaltung mit integrierter Funktion zur programmgesteuerten oder manuellen Sammlung und Verteilung von Datenelementen, Verwaltung und Kommunikation von Diensten und weiteren Zentralkerneln samt zugehörigen Datenstrukturen aufweist.

2.

Vorrichtung nach Anspruch 1 , dadurch gekennzeichnet, daß die Vorrichtung räumlich und/oder thematisch zusammengehörige physikalische oder logische Geräte oder weitere Zentralkernel als Client oder Serverdienste des MetaOS Knotens aufweist, die mit der Objektbaumverwaltung des Zentralkernels bei Bedarf gleichzeitig kommunizieren und mindestens ein Dienst der Vorrichtung externe Schnittstellen für Bedienung und Beobachtung des verteilten Datenverarbeitungssystems aufweisen kann.

3.

Vorrichtung nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, daß ein lokaler Zentralkernel während des

Betriebs durch Mountvorgänge um beliebige Datendienste und weitere Zentralkernel bei Bedarf erweitert wird und beliebige Datendienste und weitere Zentralkernel bei Bedarf entfernt werden.

4.

Vorrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß weitere externe Zentralkernel und die

Dienste eines Zentralkernels den jeweiligen propretären

Einzelvorrichtungen zugeordnete und normierte, hierarchisch strukturierte

Objektbäume aufweisen.

5.

Vorrichtung nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Objektbäume der Dienste oder deren

Teile der Objektbaumverwaltung des Zentralkernels an beliebigen Stellen zugeordnet (gemountet) und über einen optional programmgesteuerten, auf Reihenfolgen, Prioritäten, Filtern und Operatoren basierenden

Projektionsverfahren zu einem resultierenden Objektbaum mit Elementen, welche aus Objekten mehrerer Dienste kombiniert werden, zusammengefügt (synchronisiert) und gespeichert werden.

6.

Vorrichtung nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß jedes Element der Objektbäume von

Diensten und Zentralkerneln aus einem beliebigen Datenobjekt und optional einer beliebigen Anzahl dem Datenobjekt zugeordneter Metadatenobjekte besteht und jedem Daten- und Metadatenobjekt ein hierarchisch strukturierter Baum von Headerdatenobjekten zugeordnet ist und alle Objektbaumelemente aller Datendienste, Zentralkernel und Headerdatenobjekte der verteilten Datenverarbeitungsanlage eine identische Grundstruktur aufweisen. Vorrichtung nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß Objekte, Metadatenobjekte und

Headerdatenobjekte eines Elements des Zentralkernels in beliebiger Kombination mit dem Projektionsverfahren nach Anspruch 5 aus den

Diensten des Zentralkemrels und aus weiteren Zentralkerneln in das

Element projiziert werden und die Headerdatenobjekte jedes Daten-, und

Metadatenobjekts eines Zentralkernels Timinginformationen zur

Synchronisation, Informationen zu Ressourcen des lokalen Standorts (CPU, Speicher, Netzwerkkapazitäten), Log- und Fehlerinformationen, Informationen zur Benutzerverwaltung und Authentisierung, Sicherheit, Transport-, Popularitäts- und Prioritätseigenschaften und Zustand des Datenobjekts, sowie vollständige Informationen über Art und aktuellen Zustand der Bedien- und Beobachtungsvorrichtungen sowie Beschreibungsinformationen zu den Objekten und zusammengefaßte Informationen über hierarchisch tiefer liegende Objektstrukturen enthalten, welche aus verschiedenen spezialisierten Datendiensten und weiteren Zentralkerneln in eine gemeinsame Headerobjektstruktur des Elements gemountet und projiziert werden.

8

Vorrichtung nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß die gleichen Informationstypen der

Headerdatenobjekte von beliebigen Zentralkerneln durch Mounten, und programmgesteuerte Synchronisation auf ein gemeinsames

Headerdatenobjekt projiziert werden.

Vorrichtung nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß Daten-, Metadaten- oder

Headerdatenobjekte von Objektbäumen, welche von unterschiedlichen Datendiensten und weiteren Zentralkerneln an die gleiche Stelle im Objektverzeichnis des Zentral kern eis gemountet werden, unter Anwendung von Projektionsprioritäten und syntaktischen, semantischen, logischen und numerischen programmgesteuerten Filtern und Operatoren mit dem Zentralkernel synchronisiert und gespeichert werden.

10.

Vorrichtung nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß beliebige Objekte, Elemente und Teilstrukturen eines Zentralkernels mit beliebigen Objekten, Elementen und Teilstrukturen weiterer lokaler Datendienste, Bedienschnittstellen oder Zentralkernel und mit beliebigen Objekten, Elementen und Strukturen des eigenen Zentralkernels mit Hilfe einer für alle Beschreibungs- und Kommunikationsvorgänge zwischen Objekten, Elementen und Strukturen einheitlichen Kommandsprache gemountet, gefiltert, mit Operatoren verknüpft und synchronisert werden und daß Daten-, Metadaten- und Headerdatenobjekte hierarchisch übergeordneter wie auch untergeordneter Baumelemente durch Angabe relativer Mountmarken gemountet und synchronisiert werden.

11.

Vorrichtung nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, daß in jedem Zentralkernel der

Datenverarbeitungsanlage ein Index von synchronisierten Objektverzeichnissen, Datenobjekten und Metadatenobjekten angelegt wird.

12.

Vorrichtung nach einem der Ansprüche 1 bis 11 , dadurch gekennzeichnet, daß eine Gruppe zwei-, oder dreidimensionaler, interaktiver in einem zwei- oder dreidimensionalen Gebiet liegender Komponenten einer grafischen Benutzerschnittstelle ai .. a_m, bestehend wiederum aus Mengen br..bm_' von an lokalen und dezentralen Orten generierten zwei- oder dreidimensionalen interaktiven grafischen Benutzerschnittstellen, in der jede Benutzerschnittstelle der Menge b eine für Sie selbst spezifische zugehörige Menge c1..cn grafischer Basiselemente sowie optional eine Menge an frei definierbaren grafischen Zusatzelementen enthält und die Gestaltung mindestens eines der Basiselemente jeder Mengen c derart ist, daß mindestens eine weitere grafische Benutzerschnittstelle vom Typ der Mengen a oder b oder mindestens eine Benutzerschnittstelle mindestens eines Elements der Menge an Benutzerschnittstellen b in einem Teilgebiet von c vollständig abgebildet werden kann, und die Elemente der Mengen a und b als externe Bedien- und Beobachtungsschnittstellen der Elemente eines oder mehrerer Datendienste im verteilten Daten Verarbeitungssystem nach Anspruch 1-11 dienen, indem Daten durch die Schnittstellen aus dem Datendienst synchronisert und präsentiert werden.

13.

Vorrichtung nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, daß mindestens eines der Basiselemente jeder Mengen c eine eigene Bedien- und Beobachtungsoberfläche mit Objektexplorer, einer Objektleiste ausgewählter Objekte und einer Visualisierungsoberfläche für Objekte darstellt.

14.

Verfahren zur integrierten Überwachung, Steuerung, Regelung, Analyse und Datenspeicherung von vorzugsweise mehrteiligen komplexen technischen Vorgängen durch beliebige Teilnehmer der verteilten Datenverarbeitungseinrichtung dadurch gekennzeichnet, daß Einzelinformationen, Informationslisten und hierarchisch organisierte Informationsstrukturen aus Daten-, Zustande-, und Funktionsschnittstellen der einzelnen Meß-, Analyse-, Speicher-, Regelungs-, Bedien- und Beobachtungsvorrichtungen und aus Zentralkerneln durch programmgesteuerte Informationsprojektion nach Bedarf in den jeweiligen Objektbäumen der zugeordneten Dienste gekapselt werden.

15.

Verfahren nach Anspruch 14 dadurch gekennzeichnet, daß jedes Datenobjekt und Metadatenobjekt eines Datendienstes oder Zentralkernels durch programmgesteuerte

Synchronisation zeitveränderliche Informationen aus den technischen

Vorrichtungen kapselt.

16.

Verfahren nach Anspruch 14 oder 15 dadurch gekennzeichnet, daß die programmgesteuerte Synchronisation von Objektstrukturen und Objekten durch Scheduler in den Datendiensten gesteuert wird, welche ihre Timinginformationen den Headerdatenobjekten der Ojektbäume entnehmen

17.

Verfahren nach Anspruch 14 bis 16 dadurch gekennzeichnet, daß ausgehend von einem anfänglich einzelnen Zentralkernel als virtuellem Zentrum mit weiteren Zentralkerneln ein logisch verknüpftes hierarchisches Netzwerk von Zentralkerneln aus verteilten Objektbeständen gemountet wird, so daß jeder Zentralkernel der Hierarchie jeweils Zugriff auf ein resultierendes, einheitlich netzwerkweit globales (virtuelle Zentralisierung) Verzeichnis, ein jeweils unterschiedlichen regionales Bereichsverzeichnis logisch zusammenhängender Elemente und ein lokales Verzeichnis gebildet aus den dezentrale liegenden Diensten und Elementen erhält, indem jeder Knoten ein Mountschema mit anderem Knoten bildet, so daß jeder Knoten lokale Datendienste in ein lokales privates sowie auf Wunsch in ein lokales öffentliches Bereichsverzeichnis logisch zusammenhängender Elemente synchronisiert, ein festgelegtes Globalverzeichnis eines hierarchisch höherliegenden Zentralkernels an das Wurzelelement seines eigenen Zentralkernels mountet und synchronisiert und öffentliche lokale Bereichsverzeichnisse an die öffentlichen Bereichsverzeichnisse des übergeordneten Knotens im lokalen Globalverzeichnis mountet und synchronisiert und öffentliche regionale Bereichsverzeichnisse von untergeordneten Knoten an das eigene regionale Objektverzeichnis mountet.

18. Verfahren nach Anspruch 14 bis 17 dadurch gekennzeichnet, daß jeder Zentralkernel Datenbestände des virtuellen Zentrums und Datenbestände weiterer Zentralkernel synchronisert und mit diesen synchronisierten Datenbständen zeitweise inaktive ausgefallene Zentralkernel für den Zeitraum des Ausfalls simulieren.

19.

Verfahren nach Anspruch 14 bis 18 dadurch gekennzeichnet, daß Suchvorgänge im Netzwerk durch Nutzung der Vorrichtung nach Anspruch 9 realisiert werden

20.

Verfahren nach Anspruch 14 bis 19 dadurch gekennzeichnet, daß beliebige den Zentralkernel mountende Dienste und weitere Zentralkernel über die in den Zentralkernel projizierten und gespeicherten Informationen aus allen dem Zentralkernel sowie dem Global- und Regionalverzeichnis zugeordneten Vorrichtungen, lesen, beobachten und analysieren und über den entgegengesetzen Vorgang mit Informationen beschreiben und auf diese Weise bedienen, beobachten und regeln kann.

21.

Verfahren nach Anspruch 14 bis 20 dadurch gekennzeichnet, daß jeder Zentralkernel aus einer nur logisch zusammenhängender Gruppe von Zentralkerneln alle Verzeichnisse aller anderen Zentralkernel der Gruppe in einem für die gesamte Gruppe festgelegten Bereichsverzeichnis mountet und synchronisiert und mit diesen eine so Symbiose bildet

22.

Verfahren nach Anspruch 14 bis 21 dadurch gekennzeichnet, daß eine Menge von FTP- und HTTP-Server über FTP und HTTP fähige Datendienste dem Netzwerk zugeordnet wird und Daten in dieses einspeist.

23.

Verfahren nach Anspruch 14 bis 22 dadurch gekennzeichnet, daß in den Headerobjekten von Diensten dezentral gelagerte Timinginformationen zur Synchronisation, Informationen zu Ressourcen des lokalen Standorts (CPU, Speicher, Netzwerkkapazitäten), Log- und Fehlerinformationen, Informationen zur Benutzerverwaltung und Authentisierung, Sicherheit, Transport-, Popularitäts- und Prioritätseigenschaften und Zustand der Datenobjekte, sowie Informationen über Art und Zustand der Bedien- und Beobachtungsvorrichtungen sowie Beschreibungsinformationen zu den Objekten und zusammengefaßte Informationen über hierarchisch tiefer liegende Objektstrukturen entsprechend dem Verfahren in Anspruch 17 in jeweils eigene private Verzeichnisse, regionale Bereichsverzeichnisse und für alle Zentralkernel immer einheitliche Globalverzeichnisse, synchronisiert werden.

24.

Verfahren nach Anspruch 14 bis 23 dadurch gekennzeichnet, daß Änderungen von Datenobjekten, Metadatenobjekten und Headerdatenobjekten in den Objektbäumen von Datendiensten und Zentralkerneln in den Headerdatenobjekten der jeweiligen Elemente vermerkt werden und der Änderungsvermerk sukzessive an hierarchisch übergeordnete Objekthierarchien übermittelt wird und hierarchisch untergeordnete Objekthierarchien regelmäßig nach Änderungsvermerken in hierarchisch höheren Elementen nachfragen, so daß Objekt- und Elementveränderungen in allen globalen, regionalen und privaten Objektbaumverzeichnissen bemerkt werden.

25.

Verwendung der Vorrichtung nach einem der Ansprüche 1-13 zur integrierten virtuell zentralisierten Modellierung, Überwachung, Steuerung, Regelung und Speicherung von komplexen Verfahrensabläufen

26.

Verwendung der Vorrichtung nach Anspruch 25 für in räumlicher Entfernung zueinander angeordnete Anlagen

27. Verwendung der Vorrichtung nach Anspruch 26 für in räumlicher Entfernung voneinander angeordnete Industrieanlagen, Windparks, Solarzellen, Blockheizkraftwerke, Biogasanlagen, Wasserkraftanlagen, Kohlekraftanlagen, Ölkraftanlagen, Gasturbinenanlagen,

Kernkraftanlagen, Brennstoffzellenanlagen und andere

Energieversorgungsanlagen, auch im gemischten Betrieb, für Mobilfunktstationen, Bedien- und Beobachtungsgeräte, Pipelinenetze, Stromnetze, Gebäudeautomatisierung in Stadteilen und Verwaltung technischer Infrastrukturen.