DE10148194A1 - Computersystem - Google Patents

Abstract

Die Sicherheit und die Benutzerberechtigung in einem Computersystem, wie zum Beispiel einem Steuersystem, basieren auf dynamischen Beziehungen zwischen Software-Objekten in mehrfachen Strukturen. Auf diese Weise wird die Benutzerberechtigung angepaßt an den aktuellen Stand des Steuer- und Fabrikations-Ausführungssystems, wie zum Beispiel die Anpassung an ein Produkt, welches durch einen Prozeß wandert. Ein Software-Objekt ist in Strukturen positioniert, wie zum Beispiel einer funktionalen Struktur, einer Ortsstruktur oder einer Auftragsstruktur, wobei jede Struktur aus einer Hierarchie von Software-Objekten besteht. In jeder Struktur übernimmt das Software-Objekt Sicherheiten von anderen Software-Objekten in der Hierarchie. Da das Software-Objekt in mehrfachen hierarchischen Strukturen eingefügt ist, wird die Sicherheit des Software-Objekts von Sicherheitsobjekten in mehrfachen hierarchischen Strukturen übernommen (geerbt). Die Benutzerberechtigung, mit einem Software-Objekt in Dialog zu treten, ist, zusätzlich zu der Identität des angemeldeten Benutzers, abhängig von der übernommenen Sicherheit des Software-Objekts. Wenn ein Software-Objekt in eine hierarchische Struktur eingefügt wird, dort gelöscht oder verschoben wird, so ändert sich die Sicherheit des Software-Objekts. Die Erfindung bezieht sich auch auf ein Verfahren in einem Computersystem zur Konfiguration von Sicherheit und Benutzerberechtigung. Ferner bezieht sich die Erfindung auf ein Computerprogramm-Produkt ...

Description

Technisches Gebiet

Die vorliegende Erfindung bezieht sich auf ein Computersy­ stem, wie zum Beispiel ein Steuersystem. Die Erfindung be­ zieht sich auch auf andere Computersysteme, wie zum Beispiel ein Fabrikations-Ausführungssystem. Insbesondere bezieht sich die vorliegende Erfindung auf ein Sicherheitssystem in solchen Systemen. Die Erfindung sieht eine Zugangsberechti­ gung zu Software-Objekten vor, die Objekte der realen Welt repräsentieren. Die Erfindung bezieht sich auch auf ein Ver­ fahren zur Konfiguration von Sicherheit in einem Computersy­ stem. Ferner bezieht sich die Erfindung auf ein Computerpro­ gramm-Produkt zur Einrichtung von Sicherheit.

Stand der Technik

Sicherheit in einem computer-gestützten System umfaßt die Prüfung, ob ein Benutzer die relevante Berechtigung hat, be­ vor der Benutzer Handlungen ausführen kann, wie zum Beispiel das Aufrufen eines Programms, das Öffnen einer Datei oder die Vornahme bestimmter Operationen an bestimmten Entitäten.

Bei einem computer-gestützten Steuer- und Fabrikations-Aus­ führungssystem werden individuelle Benutzer als Mitglieder einer Gruppe definiert, wie zum Beispiel Bedienperson, Inge­ nieur, Planer oder Leiter. Dieses Vorgehen ist üblich in der Industrie, wie zum Beispiel in der Chemie, der Pharmazeutik, der Lebensmittelindustrie, der Metallindustrie, des Berg­ baus, der Zellstoff- und der Papierindustrie. Andere Indu­ strien und öffentliche Versorgungsbetriebe, in denen die gleiche Maßnahme angewendet wird, sind die Kraftfahrzeugin­ dustrie, das Gebiet der Verbraucherprodukte, der Stromerzeu­ gung, der Stromverteilung, der Abwasserentsorgung, Ölraffi­ nerien, Gasrohrleitungen und Off-shore-Platformen. Traditio­ nelle Verfahren zur Herstellung von Sicherheit in Steuer- und Fabrikationssystemen basieren auf Zulassungen; ein be­ stimmter Benutzer hat bestimmte Operationen an bestimmten Entitäten vorzunehmen. Als Beispiel in einem Steuer- und Fa­ brikationssystem erlaubt das Sicherheitsschema für eine tra­ ditionelle Schnittstelle zwischen Mensch und Maschine be­ stimmten Benutzern den Zugang zu bestimmten Entitäten über bestimmte Displays. Eine Bedienperson, die verantwortlich ist für die Beaufsichtigung und Steuerung eines Trockners in einer Zellstofffabrik, ist berechtigt, auf graphische Schau­ bilder und Steuer-Bildschirmvorlagen für die Trocknungsab­ teilung der Zellstofffabrik zuzugreifen. Ein Leiter in der­ selben Zellstofffabrik kann berechtigt sein, auf dieselben graphischen Schaubilder zuzugreifen und diese für Informati­ onszwecke einzusehen, jedoch hat der Leiter keinen Zugang zu den entsprechenden Bildschirmvorlagen für die Steuerung.

Eine Beschreibung eines Sicherheits- und Berechtigungssy­ stems in einem herkömmlichen Steuersystem ist bekannt aus der US 4 886 590. Eine Hierarchie aus Berechtigungsschlüs­ seln begrenzt den Zugang zu dem Gerät in Abhängigkeit der Berechtigungsstufe der Person, die den Zugang sucht. Unter­ schiedliche Grade der Berechtigung können vorgesehen sein für eine Bedienperson des Gerätes, eine Überwachungsperson und das Wartungspersonal. Auf der niedrigsten Berechtigungs­ stufe kann eine Bedienperson das Gerät bedienen. Auf der nächsthöheren Berechtigungsstufe können Betriebsparameter, wie zum Beispiel Zielpunkte und Chargencharakteristika, ge­ ändert werden. Auf der höchsten Berechtigungsstufe können Änderungen an der Systemsoftware vorgenommen werden. Die Be­ rechtigung ist statisch, wenn ein Benutzer beim System ange­ meldet ist.

Ein Problem bei einem herkömmlichen Steuer- und Fabrikati­ ons-Ausführungssystemen besteht darin, daß das Sicherheits­ system sich nicht an Änderungen in den Beziehungen zwischen verschiedenen Entitäten anpaßt. Solche Änderungen können beispielsweise verursacht werden durch das Durchlaufen einer bestimmten Charge durch verschiedenen Sektionen einer Pro­ duktionsausrüstung oder durch das Durchlaufen eines Produk­ tionsauftrages oder einer Kundenrechnung durch verschiedene Vorbereitungsstufen. Wenn beispielsweise eine Entität der realen Welt, wie zum Beispiel eine pharmazeutische Charge, sich in der Produktionsplanungsphase befindet, ist es ange­ bracht, Zugang zu einer Softwarefunktion für die Zuweisung von Rohmaterial zu haben. Wenn die Charge hergestellt worden ist und in das Produktlagerhaus geht, ist es nicht länger angebracht, Rohmaterial für die Charge zuzuweisen. Stattdes­ sen ist die Sicherheit in einem herkömmlichen Steuer- und Fabrikations-Ausführungssystem jedoch darauf begrenzt, daß bestimmte Benutzer nur Zugang haben zu bestimmten vordefi­ nierten Ansichten, Displays und Werkzeugen in dem System.

Ein anderes Problem bei einem herkömmlichen Steuer- und Fa­ brikations-Ausführungssystem besteht darin, in effizienter Weise Software-Objekte anzuordnen und einem Benutzer in ei­ ner sicheren Weise Zugang zu verschiedenen Perspektiven von Software-Objekten zu gewähren. Die große Anzahl von Entitä­ ten der realen Welt, die in einem System dargestellt werden, ist in sich selbst eine Herausforderung, da ihre Zahl in die Tausende bis mehrere Millionen gehen kann. Ferner wird jede Entität der realen Welt in mehreren Software-Anwendungen dargestellt. Die Anzahl verschiedener Software-Anwendungen in einem Steuer- und Fabrikations-Ausführungssystem beträgt typischerweise 10 bis 100.

Ein Steuersystem kann für sich als eine Software-Anwendung betrachtet werden. Beispiele für Funktionen in einem Steuer­ system sind ein graphisches Schaubild einer Prozeßausrü­ stung, eine Liste von aktiven Alarmen, eine Trendkurvendar­ stellung und eine Konfiguration eines Steuerprogrammes. Ein anderes Beispiel einer Software-Anwendung ist eine Wartungs­ software, zu der Funktionen gehören für Fehlerberichte, War­ tungsgeschichte, einen Wartungsplan, eine Liste zugehöriger Ersatzteile, eine Abschaltanalyse und so weiter. Ein anderes Beispiel einer Software-Anwendung ist ein Simulationspaket, welches Funktionen enthält, wie zum Beispiel eine Was-Geschieht-Wenn-Analayse, bevor Änderungen eines Einstellpunk­ tes an einem Polymerreaktor eingeführt werden.

Eine Aufgabe eines Steuer- und Fabrikationssystems besteht darin, eine geeignete Darstellung verschiedener Beziehungen zwischen Entitäten der realen Welt zu finden. Beispielsweise gehört eine Entität der realen Welt, wie zum Beispiel ein Gefäß, zu einer Produktionsanlage und ist einem bestimmten Stockwerk eines bestimmten Gebäudes installiert. Das gleiche Gefäß ist Teil einer flüssigen Prozeßlinie und ist ein Glied einer Einheit, deren Funktion in der Mischung von Zutaten besteht. Zu einem bestimmten Zeitpunkt ist das Gefäß der Produktion einer bestimmten Charge zugeordnet. Dem Gefäß ist eine Anzahl von Einheiten zugeordnet, welche die aktuelle Steuerung des Prozesses bewerkstelligen. Beispiele von Ein­ heiten, die einer Entität der realen Welt, wie zum Beispiel einem Gefäß, zugeordnet sind, sind Regler, programmierbare logische Regler (PLCs) und intelligente und nichtintelli­ gente Feldgeräte. Die Regler, PLCs und Feldgeräte können ih­ rerseits, zusätzlich zu dem Gefäß, anderen Entitäten der re­ alen Welt zugeordnet sein.

Eine andere Aufgabe eines Computersystems besteht darin, einen Benutzerzugang vorzusehen und verschiedene Arten von Informationen über Entitäten in einer industriellen Anlage zu verwalten. Dies wird durch die Tatsache kompliziert, daß Informationen und Funktionalität, die sich auf diese Entitä­ ten beziehen, über viele verschiedene Software-Anwendungen verbreitet sind. In einem Steuer- und Fabrikations-Ausfüh­ rungssystem ist gewöhnlich eine gewisse gemeinsame Grundlage zwischen Software-Anwendungen vorhanden, was die Standards anbetrifft. Mit der Fortentwicklung von De-Facto-Standards, wie zum Beispiel Transmission Control Protocol/Internet Pro­ tocol (TCP/IP), Hyper Text Meta Language (HTML) und Extensible Markup Language (XML) wird ein Fernzugang von einer in­ dustriellen Anlage zu einer anderen zunehmend unter Benut­ zung der Internet-Technologie ausgeführt. Ein anderer wich­ tiger Standard wurde von Microsoft (geschütztes Markenzei­ chen) publiziert und wird Component Object Model (COM) ge­ nannt. COM beschreibt einen Standard für eine gegenseitige Betriebsmöglichkeit zwischen Teilen einer oder mehrerer Software-Anwendungen. Die Spezifikation ist verfügbar in der Microsoft Developer Network (MSDN) online Web-Seite. Aber bei einem herkömmlichen Steuer- und Fabrikations-Ausfüh­ rungssystem ist diese allgemeine Grundlagentechnologie sel­ ten in einen beachtlichen Grad von Integration umgeformt worden, bei dem der Benutzer, beispielsweise die Bedienper­ son eines Steuersystems, Zugang zu Funktionen aus verschie­ denen Software-Anwendungen bei einer Produktionsanlage hat und diese in effizienter Weise benutzen kann. Ein Grund da­ für, warum Bedienpersonen und andere Benutzer eines Steuer­ systems die Vorteile eines integrierten Systems gewöhnlich verweigert werden, besteht darin, daß Informationen und der Zugang zu Funktionen, die sich auf ein bestimmte Entität der realen Welt beziehen, sich auf eine Anzahl verschiedener Software-Anwendungen verteilen.

In einem herkömmlichen Steuer- und Fabrikations-Ausführungs­ system ist die Benutzerberechtigung an eine bestimmte Soft­ ware-Anwendung gebunden. Eine natürliche Person kann sehr wohl mehreren Benutzern zugeordnet sein. Jeder Benutzer hat eine Berechtigungskonfiguration, die normalerweise auf der Zugehörigkeit zu einer Gruppe von Benutzern beruht, wobei sich die Berechtigung auf ein bestimmtes Software-System be­ zieht. Ein Beispiel für eine solche Berechtigung und ein solches Softwaresystem ist die Einblicknahme als Ingenieur für die Konfiguration von Bildschirmvorlagen für die Steue­ rung in einem Steuersystem. Ein anderes Beispiel für eine Benutzerberechtigung und ein zugehöriges Softwaresystem ist ein Ferndiskettenzugriff in den aktuellen Bereich eines Be­ triebssystems. Noch ein weiteres Beispiel ist die Berechti­ gung, neue Befehle in Befehlsmodulen eines Enterprise Re­ source Planning-Systems zu schaffen. Mit kommerziellen Soft­ wareprodukten, wie zum Beispiel Microsofts Windows 2000 (geschütztes Markenzeichen) ist es leichter geworden, einen Arbeitsplatz oder eine Arbeitsstation für mehrere Zwecke zu verwenden. Die Spezifikationen für das Sicherheitsmodell von Windows 2000 und Windows NT (geschütztes Markenzeichen) sind auf der Microsoft MSDN-Online-Web-Seite verfügbar. Die Spe­ zifikation des NT Dateiensystem NTFS (geschütztes Markenzei­ chen) ist auch verfügbar auf der Web-Seite von Microsoft. Die Sicherheit in NTFS ist fokussiert auf die Handhabungssi­ cherheit von Dateien auf einer und mehreren Disketten in ei­ nem Computernetzwerk.

Ein gewisser Fortschritt wurde auf dem Gebiet der Betriebs­ systeme gemacht, um eine verbesserte Sicherheit für Pro­ gramme zu erreichen, die in einem Computersystem verfügbar sind, welches verschiedene Sicherheitsprotokolle hat. US 5 604 490 beschreibt eine Verbesserung der Sicherheit eines Betriebssystems. Das Betriebssystem bietet ein Sicherheits­ system für einen Computer oder ein Netzwerk, welches mehrere Sicherheits-Untersysteme hat. Das Betriebssystem vereinigt Sicherheitsprotokolle für jeden Benutzer auf der Grundlage einzigartiger Benutzereigenschaften. Benutzereigenschaften sind einem sogenannten Benutzer-Handle zugeordnet, der bezüg­ lich der einzigartigen Benutzereigenschaften orientiert (mapped) ist für jede Programmprozedur. Sobald eine Anforde­ rung an ein Objekt, zugegangen über den Server, erfolgt, ge­ währt das System Zugang zu dem Objekt auf der Grundlage der neuen Benutzereigenschaften, die dem Handle zugeordnet sind.

Es gibt bestimmte Probleme, die in einem Steuer- und Fabri­ kations-Ausführungssystem der Zuwendung bedürfen. Ein spe­ zielles Thema bei der Steuerung und Fertigung besteht darin, daß, wie gut auch immer die Produktion geplant sein mag, es notwendig sein kann, den Plan zu ändern. Es gibt viele Gründe, warum ein Produktionsplan nicht ausführbar sein könnte. Wenn beispielsweise das vorgesehene Rohmaterial sich als von zu schlechter Qualität oder von falscher Art er­ weist, kann der geplante Posten nicht produziert werden. Wenn man in dieser Lage den Produktionsplan nicht einhalten kann, würde es vorteilhaft sein, wenn die Bedienperson Zu­ gang zu den letzten Informationen über den Vorrat an Aufträ­ gen hätte. Der Vorteil besteht darin, daß sich die Gelegen­ heit ergibt, das nächstbeste Produkt für die Produktion aus­ zuwählen. Ein Problem besteht darin, daß in einem herkömmli­ chen Steuer- und Fabrikations-Ausführungssystem die Bedien­ person in dieser Lage entweder auf Informationen von einem Kollegen warten muß oder die Gefahr in Kauf nehmen muß, ein Produkt einer bestimmten Art zu produzieren, das als Lager­ bestand enden könnte. Noch schlimmer, es könnte nicht mög­ lich sein, den Prozeß anzuhalten, und die Bedienperson könn­ ten gezwungen sein, den Prozeß rückgängig zu machen oder das Rohmaterial als Abfall zu behandeln. Beispielsweise soll eine Bedienperson eine bestimmte Aluminiummenge des Typs A produzieren. Die Bedienperson stellt fest, daß das verfüg­ bare Rohmaterial nicht der für die Produktion des Typs A er­ forderten Spezifikation entspricht. Jedoch würde das Rohma­ terial der Bedienperson gestatten, das Produkt B zu produ­ zieren. In dieser Lage wäre es von Vorteil, den Produktions­ plan einzusehen und nach dem Produkt B zu suchen. Wenn das Produkt B für die Produktion nicht geplant ist, könnte eine Suche in der Liste der neuen Aufträge ein passendes Produkt ergeben, so daß die Produktion entgegen einem Befehl vorge­ nommen werden kann. Jedoch auch dann, wenn dies die einzige Art einer Suche und eines Zugriffs ist, die die Bedienperson in der Produktionsplanung und dem Auftragssystem vornehmen muß, kann deren Durchführung eine lange und kostspielige Prozedur sein. Im schlimmsten Falle bedeutet dies nicht nur, daß eine Bedienperson mehrere Anmeldeprozeduren beherrschen muß, sondern auch mehrere verschiedene Benutzerumgebungen für die betroffenen Software-Anwendung. Für die Praxis läuft dies darauf hinaus, daß in einem herkömmlichen Steuer- und Fabrikations-Ausführungssystem nur bestimmte Personen vor­ handen sind, die bestimmte Software-Anwendung benutzen. Den­ noch wäre es für eine Bedienperson von Vorteil, eine Aktua­ lisierung des gegenwärtigen Auftragsstatus zu bekommen, in­ dem er diese Informationen dem Auftragssystem entnimmt, was gewöhnlich als nicht sicher und praktikabel betrachtet wird.

Im Lichte der oben genannten Probleme haben die Erfinder er­ kannt, daß ein System benötigt wird, bei welchem die Benut­ zerberechtigung nicht allein von dem angemeldeten Benutzer abhängt, sondern auch von Beziehungen zwischen Entitäten, mit denen der Benutzer arbeitet. Das System sollte sich an Änderungen in dem Steuer- und Fabrikations-Ausführungssystem während der Zeit, in der ein Benutzer angemeldet ist, anpas­ sen.

Zusammenfassung der Erfindung

Ein Ziel der Erfindung besteht darin, ein Computersystem für die Sicherheit zu entwickeln, welches in einem Steuersystem integriert ist. Ein anderes Ziel besteht darin, ein Com­ putersystem für die Sicherheit zu schaffen, welches in ein System von Software-Anwendungen integriert ist, wie zum Bei­ spiel ein Fabrikations-Ausführungssystem.

Ein anderes Ziel der Erfindung besteht darin, ein Computer­ system zu entwickeln, bei welchem die Benutzerberechtigung nicht nur von einer Benutzeranmeldung bei einer Arbeitssta­ tion und einer betriebenen Entität abhängt, sondern welches die Benutzerberechtigung auch anpaßt an dynamische Änderun­ gen in den Beziehungen zwischen Softwaredarstellungen von Entitäten der realen Welt in einer Mehrzahl von hierarchi­ schen Strukturen.

Ein weiteres Ziel der Erfindung besteht darin, ein Computer­ system zu schaffen, bei dem die Sicherheit eines Software-Objekts, welches eine Entität der realen Welt repräsentiert, von einer Sicherheit abhängt, die von anderen Software-Ob­ jekten übernommen (ererbt) wird, welche andere Entitäten der realen Welt auf höheren Positionen in mindestens zwei hier­ archischen Strukturen repräsentieren.

Für das Verstehen der Ziele und Vorteile der Erfindung dürfte es von Hilfe sein, die folgende kurze Beschreibung von Metaobjekten und Aspekten zu studieren. Ein Software-Ob­ jekt, welches eine Entität der realen Welt repräsentiert, kann durch ein Metaobjekt implementiert werden. Ein Metaob­ jekt kann auch ein Software-Objekt implementieren, das eine abstraktere Entität repräsentiert. Ein Metaobjekt kann in mehrere hierarchische Strukturen von Metaobjekten eingesetzt werden. Jede Perspektive eines Metaobjekts definiert ein Pa­ ket von Informationen und einen Satz von Funktionen für die Schaffung, den Zugriff auf und die Manipulation dieser/diese Informationen. Eine bestimmte Art von Aspekt ist ein Sicher­ heitsaspekt. Ein Aspekt kann in der Weise übernommen (ererbt) werden, daß Metaobjekte auf einer niedrigeren Posi­ tion Aspekte von einem oder mehreren Objekten auf einer hö­ heren Position in einer hierarchischen Struktur übernehmen. Die Übernahme unterscheidet sich von herkömmlichen Formen einer Übernahme in objektorientierten Systemen insofern, als sie nicht definiert ist in Form einer Objektklassen-Hierarchie, sondern in Form von mehrfachen strukturellen Be­ ziehungen zwischen verschiedenen Objekten von im übrigen nicht in Beziehung stehenden Klassen. Dies steht im Gegen­ satz zu einem Objekt, welches eine Spezialisierung einer ge­ nerellen Objektklasse in einer herkömmlichen Objektklassen-Hierarchie ist.

Ein weiteres Ziel der Erfindung besteht darin, ein Computer­ system zu entwickeln, bei welchem die Sicherheit eines Meta­ objekts auf mindestens zwei Sicherheitsaspekten beruht, die über mindestens zwei hierarchische Strukturen übernommen werden. Die Übernahme eines oder mehrerer Sicherheitsaspekte erfolgt von oder über ein Mutter-Metaobjekt in jeder hierar­ chischen Struktur, in welcher das Metaobjekt eingefügt ist.

Noch ein anderes Ziel der Erfindung besteht darin, ein Com­ putersystem zu entwickeln, bei welchem die Benutzerberechti­ gung für den Zugang zu einem Aspekt eines Metaobjekts auf mindestens zwei von mindestens zwei hierarchischen Struktu­ ren übernommenen Sicherheitsaspekten in Kombination mit der Benutzeridentität beruht.

Ein grundsätzlicher Vorteil der Erfindung besteht in der Möglichkeit, Sicherheit und Benutzerberechtigung an Änderun­ gen in den Beziehungen zwischen Metaobjekten in einer Mehr­ zahl von hierarchischen Strukturen anzupassen. In einem Com­ putersystem, in welchem Metaobjekte Entitäten der realen Welt repräsentieren, können solche Änderungen beispielsweise die Folge davon sein, daß ein Produkt in seinem Herstel­ lungsprozeß fortschreitet.

Ein anderer grundsätzlicher Vorteil der Erfindung besteht darin, daß sie die Interaktionsfähigkeiten zwischen Benut­ zern und verschiedenen Softwaresystemen in sicherer und dy­ namischer Weise verstärkt. Die Erfindung beschreibt ein Sy­ stem, das verschiedene Software-Anwendungen in die Lage ver­ setzt, zusammenzuarbeiten, um in sicherer Weise eine inte­ grierte Funktionalität eines Metaobjekts zu ermöglichen.

Es ist ein weiteres Ziel, ein Computersystem zu schaffen, bei welchem ein übernommener Sicherheitsaspekt eines Metaob­ jektes beseitigt wird, wenn das Softwareobjekt in einer hierarchischen Struktur gelöscht wird, in der Sicherheitsa­ spekt übernommen war. Dies hat zur Folge, daß die Benutzer­ berechtigung für den Zugang zu einem Aspekt des Metaobjekts dynamisiert ist in der Zeit zwischen der Anmeldung und der Abmeldung.

Ein weiteres Ziel besteht darin, Mittel zu schaffen für eine Änderung einer Benutzerberechtigung von einem Benutzer zu einem anderen Benutzer, wenn ein Metaobjekt die Position än­ dert. Die Benutzerberechtigung definiert das Recht des Zu­ gangs zu einem bestimmten Aspekt eines Metaobjekts. Änderun­ gen in der Position eines Metaobjekts können anzeigen, daß Produkte sich zwischen verschiedenen Prozeßausrüstungen wei­ terbewegen.

Ein anderes Ziel der Erfindung besteht darin, ein Computer­ system zu schaffen, welches Mittel enthält zum Auflisten von Aspekten, die zu einer aktuellen Benutzerberechtigung pas­ sen. Dies hat den Vorteil, daß die vorliegende Erfindung Mittel bereitstellt, die Anzahl der Aspekte eines Metaobjek­ tes, die für einen Benutzer auf einem Schirm dargestellt werden, in Abhängigkeit der Position eines Metaobjekts in mehrfachen hierarchischen Strukturen zu reduzieren.

Ein weiteres Ziel besteht darin, ein Computersystem zu ent­ wickeln, bei welchem die aktuelle Sicherheit unabhängig da­ von ist, von welcher hierarchischen Struktur ein Benutzer ein Metaobjekt auswählt.

Die oben genannten Ziele werden durch die Erfindung gemäß dem erreicht, was in den beigefügten Patentansprüchen 1 bis 27 definiert ist. Insbesondere wird ein Computersystem für die Sicherheit in einem computerisierten Steuersystem defi­ niert durch den unabhängigen Anspruch 1, und ein Verfahren zur Errichtung von Sicherheit in einem Computersystem, wel­ ches ein Steuersystem enthält, wird durch den unabhängigen Anspruch 10 definiert und ein Computerprogrammprodukt durch den Anspruch 20.

Das generelle erfinderische Konzept der Erfindung besteht darin, daß die aktuelle Benutzerberechtigung nicht nur auf der Identität des bei dem System angemeldeten Benutzer und der bearbeiteten Entität beruht, sondern auch auf Beziehun­ gen zwischen der bearbeiteten Entität und anderen Entitäten in einer Mehrzahl von hierarchischen Strukturen.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt ein vereinfachtes Diagramm der Komponenten ei­ nes Computersystems, welches für Sicherheit in einem Steuer- und Fabrikations-Ausführungssystem sorgt.

Fig. 2 zeigt schematisch ein Ausführungsbeispiel der Erfin­ dung mit der Übernahme von Sicherheitsaspekten von Mutter-Metaobjekten in mehreren hierarchischen Strukturen auf ein Kind-Metaobjekt. Die Figur zeigt, daß Beziehungen zwischen Entitäten in mehreren hier­ archischen Strukturen die aktuelle Sicherheit eines Metaobjektes bestimmen.

Fig. 3 zeigt schematisch ein Metaobjekt, welches eine Enti­ tät der realen Welt darstellt. In diesem Falle ist die Entität der realen Welt ein Gegenstand einer Prozeßausrüstung. Genauer gesagt, repräsentiert das Metaobjekt eine Mischereinheit. Die Figur zeigt Bei­ spiele von Softwarefunktionen, die als Aspekte ver­ fügbar sind. Dem Metaobjekt ist auch ein Sicher­ heitsaspekt zugeordnet.

Fig. 4 zeigt ein anderes Metaobjekt, welches eine Entität der realen Welt darstellt. In diesem Falle ist die Entität der realen Welt ein Produkt. Genauer gesagt, das Metaobjekt repräsentiert eine bestimmte Charge eines Milchproduktes. Mit dem Fortschreiten des Pro­ duktes durch den Fertigungsprozeß paßt sich die Be­ nutzerberechtigung für den Zugang zu Aspekten des entsprechenden Metaobjektes der Position der Pro­ duktbeziehungen zu anderen Metaobjekten in hierar­ chischen Strukturen an.

Fig. 5 zeigt ein Diagramm, welches zeigt, daß die für den Benutzer zugänglichen Aspekte abhängig sind von ei­ nem Satz übernommener Sicherheitsaspekte. Der Benut­ zer listet die verfügbaren Aspekte auf einem Bild­ schirm auf.

Fig. 6 zeigt ein Beispiel eines Satzes von Sicherheitsa­ spekten, die von einem Metaobjekt übernommen sind. Es ist die Kombination von übernommenen Sicher­ heitsaspekten aus mehrfachen Strukturen, welche die aktuelle Sicherheit eines Metaobjektes definiert.

Fig. 7 zeigt einen Programmablaufplan eines Verfahrens zur Errichtung von Sicherheit in einem Computersystem.

Fig. 8 zeigt eine Zugangsprüffunktion, welche die Berechti­ gung eines Benutzers auf Zugriff auf einen Aspekt eines Metaobjekts überprüft. Das Ergebnis der Zu­ gangsprüfung ist abhängig von übernommenen Sicher­ heitsaspekten aus mehrfachen Strukturen.

Beschreibung von bevorzugten Ausführungsbeispielen

Um die Erfindung leichter zu verstehen, ist es notwendig, einige Einzelheiten betreffend ein Steuersystem, ein Fabri­ kations-Ausführungssystem, Metaobjekte, Aspekte und hierar­ chische Strukturen zu erklären.

Steuersystem

Fig. 1 zeigt ein Steuersystem in einem Computersystem. Das Steuersystem 1 enthält eine Mehrzahl von Arbeitsstationen 4, tragbaren Geräten 8, Reglern 5, PLCs 6 und Feldgeräte 7. Die Kommunikation 13 in einem Kontrollsystem findet über Kabel oder Lichtleiter statt. Alternativ kann die Kommunikation auch drahtlos erfolgen, beispielsweise zwischen tragbaren Geräten 8 und Arbeitsstationen 4. Beispiele tragbarer Geräte sind Mobiltelefone, Taschen-PCs und drahtlose Programmierge­ räte. Es gibt typischerweise mehrere Arten von Kommunikati­ onsprotokollen und -standards, welche das Steuersystem ver­ wendet. TCP/IP und Ethernet werden zwischen Arbeitsstatio­ nen, PLCs und Reglern bevorzugt. Die Verwendung von TCP/IP bedeutet, daß auf dem Internet 12 basierende Protokolle und Standards für den Fernzugriff des Steuersystems verwendet werden. Felddatenwege (field busses) werden in erster Linie verwendet, um Feldgeräte miteinander zu verbinden. Feldda­ tenwege werden auch für die Kommunikation zwischen Feldgerä­ ten, PLCs, Reglern und Arbeitsstationen verwendet. Auch Ein­ gangs/Ausgangs-Systeme (I/O-Systeme) 9 kommunizieren in er­ ster Linie über Felddatenwege.

Ein Softwaresystem zur Steuerung und/oder Überwachung ist verteilt auf Arbeitsstationen, tragbare Geräten, Regler, PLCs und Feldgeräte. Beispielsweise kann ein Steuerprogramm, welches bestimmt, ob ein Ventil zu öffnen oder zu schließen ist, in einer CPU bei dem Ventil selbst 7, in einem PLC 6, in einem Regler 5 oder in einer Arbeitsstation abgearbeitet werden. Wo das Steuerprogramm abgearbeitet wird, hängt von der Anwendung und der Komplexität des Steuerproblems ab. Die Überwachung von Entitäten der realen Welt erfolgt typischer­ weise von Arbeitsstationen aus oder durch Verwendung eines tragbaren Gerätes. Andere Beispiele von Software in einem Steuersystem sind Prozeßgraphiken und SCADA-Funktionen (SCADA = Supervision, Control and Data Acquisition).

Fabrikations-Ausführungssystem

In Fig. 1 ist ein Fabrikations-Ausführungssystem 2 ein software-gestütztes System, welches aus mehreren Software- Anwendung besteht. Solche Anwendungen sind Wartung, Quali­ tätssicherung, Lagerbestands- und Laborsysteme. Beispiele anderer solcher Anwendungen sind Versorgungsmanagement, Pro­ duktionsplanung, Umwelt- und Energieleitsysteme. Beispiele von Kommunikationsstandard zur Verbindung von Computern 13 und Arbeitsstationen, die Fabrikations-Ausführungssysteme bewirten, sind TCP/IP und Ethernet. Das Fabrikations-Ausfüh­ rungssystem 2 ist typischerweise über ein Steuersystem 1 mit Entitäten der realen Welt 10, 11 verbunden.

Die Anwendung eines Fabrikationssystems erfolgt typischer­ weise bei der Produktion oder dem Zusammenbau von Entitäten der realen Welt, wie zum Beispiel Lastkraftwagen, Personen­ kraftwagen, industrielle Güter, Lebensmittel, Chemikalien, Pharmazeutika, Papier, Metall, Mineralien, Öl und Gas. Ein Fabrikations-Ausführungssystem oder Anwendungen eines sol­ chen Systems kommen auch zum Zuge in Industriestandorten und in Unternehmen, die Steuersystem für andere Zwecke als zur Fabrikation verwenden. Solche Standorte und Unternehmen sind Kraftwerke, Kraftverteilungsnetze und Abwasseranlagen. Sol­ che Anlagen verwenden einige derselben Module wie ein Fabri­ kations-Ausführungssystem, wie zum Beispiel Wartungs-, Um­ welt- und Laborsysteme.

Metaobjekte

In einem Steuer- und Fabrikations-Ausführungssystem besteht eine grundlegende Notwendigkeit, Informationen über alle verschiedenen Entitäten der realen Welt einer industriellen Anlage zusammen zu halten, zu verwalten und für den Zugang zu diesen Informationen zu sorgen. Die Fig. 1 zeigt, daß Steuersysteme und Fabrikations-Ausführungssysteme Software- Darstellungen von Entitäten 10, 11 der realen Welt enthalten. Diese Entitäten der realen Welt bestehen aus vielen ver­ schiedenen Arten.

Beispiele einer Art einer Entitäten der realen Welt sind ein Ventil, ein Übertrager, ein Stellglied oder ein Sensor. Ein anderes Wort für diese Art von Entitäten der realen Welt in dieser Beschreibung ist das Wort "Feldgerät". Fig. 2 zeigt Beispiele mehrerer Entitäten der realen Welt, wie zum Bei­ spiel ein Ventil 31, die als Metaobjekte dargestellt sind. Beispiele komplizierterer Entitäten der realen Welt sind eine Mischereinheit 23, ein Kompressor, ein Reaktor, ein Kessel, ein Förderer oder ein Industrieroboter. Ein anderes Wort für diese Art von Entitäten der realen Welt in dieser Beschreibung ist das Wort "Prozeßausrüstung". Fig. 3 zeigt ein Beispiel einer solchen komplexen Entitäten der realen Welt 40. Andere Beispiele eines Prozeßausrüstungs-Gegenstan­ des sind ein Schaltgerät, eine Luftbehandlungseinheit oder ein Lagergestell.

Andere Arten von Entitäten der realen Welt bei einer indu­ striellen Anlagen sind Prozeß-Entitäten. Beispiele für Pro­ zeß-Entitäten sind Produkte, Material, Chargen, Kunden und so weiter. Prozeß-Entitäten können Entitäten der realen Welt sein, die sich durch eine Produktionsstraße bewegen, wie pharmazeutische Zutaten für die Produktion einer bestimmten Charge. Fig. 4 zeigt ein Beispiel einer Softwaredarstellung einer solchen Entität der realen Welt 50. Prozeß-Entitäten können auch Gegenstände sein, die nicht körperlich in der Anlage existieren, sondern durch Softwareobjekte in dem Steuer- und Fabrikations-Ausführungssystem repräsentiert werden. Beispiele solcher Prozeß-Entitäten sind Kunden und Aufträge.

Feldgeräte, Prozeßausrüstungen und Prozeß-Entitäten werden durch Metaobjekte repräsentiert. Ein Metaobjekte ist nicht ein Objekt im herkömmlichen Sinne objekt-orientierter Sy­ steme, sondern vielmehr ein Behälter von Hinweisen für die Implementierung ihrer Aspekte. Bei einem bevorzugten Ausfüh­ rungsform der Erfindung werden Metaobjekte und Aspekte im­ plementiert mit einer gewissen Form von objekt-orientierter Technologie, wie zum Beispiel COM. Es wird ein Satz von Schnittstellen definiert, welche es erlauben, daß Aspekte unter Benutzung üblicher Dienste kooperieren.

Metaobjekte haben Beziehungen zu anderen Metaobjekten. Ein erstes Metaobjekt 31, welches auf einer niedrigeren Position in einer hierarchischen Struktur eingeordnet ist als ein zweites Metaobjekt 24, wird als Kind (Abkömmling) des zwei­ ten Metaobjekts bezeichnet. Das zweite Metaobjekt 24 wird als Mutter des ersten Metaobjekts 31 bezeichnet.

Ein bestimmtes Metaobjekt kann zu jedem Zeitpunkt in jeder Zahl von Strukturen und in jeder Anzahl von Positionen in jeder einzelnen Struktur vorkommen. Somit kann zu jedem Zeitpunkt das Metaobjekt eine beliebige Anzahl von Mutter- Metaobjekten haben. Dies ist in Fig. 2 gezeigt, wo das Me­ taobjekt 31 gleichzeitig in einer funktionalen Struktur 20, in einer Ortsstruktur 21 und in einer Chargenstruktur 22 vorhanden ist. In jeder dieser genannten Strukturen hat das Metaobjekt 31 eine Mutter.

Zusätzlich zu ihrer Funktion, Feldgeräte, Prozeß-Entitäten und andere Identitäten zu repräsentieren, können Metaobjekte andere Funktionen haben. Beispielsweise werden Metaobjekt auch verwendet, um Gruppen von Objekten zu repräsentieren und zu definieren, wie solche Gruppen von Objekten in hier­ archischen Strukturen einzuordnen sind und auch, wie diese Objekte miteinander in Beziehung stehen.

Aspekte

Ein Metaobjekt kann unter verschiedenen Gesichtspunkten be­ schrieben werden. Diese verschiedenen Gesichtspunkte werden dargestellt als die einem Metaobjekt zugeordneten Aspekte. Jeder dieser Aspekte definiert einen Informationsteil und einen Satz von Funktionen zur Schaffung, zum Zugang und zur Manipulation dieser Information. Fig. 3 zeigt ein Metaob­ jekt, welches eine Mischereinheit darstellt. Ein Aspekt kann einen Entwurfsplan 41 der Mischereinheit repräsentieren, ein anderer Aspekt kann ein Steuerprogramm 43 der Mischereinheit repräsentieren und wieder ein anderer Aspekt kann Bediener­ graphiken 44 repräsentieren.

Wie Fig. 1 zeigt, gibt es an einem Produktionsstandort an­ dere Software-Anwendungen neben dem Steuersystem 1 und dem Fabrikations-Ausführungssystem 2. Diese Software-Anwendungen werden beispielsweise verwendet für die Resourcenplanung 3 eines Unternehmens, wie zum Beispiel für die Buchhaltung, Auftragsverwaltung und menschlichen Resourcen. Auch Soft­ ware-Anwendungen für Büro- und Back-Office-Zwecke können an einem Standort vorhanden sein. Diese Anwendungen laufen in einer heterogenen Umgebung, das heißt, an einem Produktions- oder Herstellungsort sind mehrere Software-Anwendungen vor­ handen, die zum Teil kompatibel sind. Zusammen unterstützen diese Anwendungen das gesamte Szenario des Steuer- und Fa­ brikations-Ausführungssystem. Diese Software-Anwendungen be­ finden sich in vielen Fällen nicht vor Ort an einem Produk­ tionsstandort, sondern sind vielmehr verteilt mittels bei­ spielsweise der Internet-Technologie.

In einem System, wo die Sicherheit auf einer Erfindung be­ ruht, ist eine Funktion oder ein Verfahren einer solchen Software-Anwendung als ein Teil eines Aspekts eingebettet. Eingebettet sein als Teil eines Aspekts bedeutet, daß die Hauptfunktionalität des Aspektes vollständig auf einer Soft­ ware-Anwendung basieren kann. Unter Bezug auf Fig. 4 kann ein als "aktuelle Aufträge" benannter Aspekt 52 einen Aufruf an das Auftragsverwaltungssystem einschließen. Der Aufruf des Auftragsverwaltungssystems bewirkt, daß als Antwort eine Liste von Aufträgen an den Aspekt gegeben wird. Bei der Im­ plementierung des Aspektes kann es zusätzliche Funktionen geben, die nicht Teil des Auftragssystems sind. Beispiels­ weise kann ein Aufruf des Aspekts "aktuelle Aufträge" in verschiedenen Arten der Formatierung und Darstellung der ak­ tuellen Aufträge auf einem Bildschirm resultieren, abhängig davon, ob das Ergebnis in einer Arbeitsstation, einem trag­ baren Gerät oder einem Mobiltelefon dargestellt werden soll. Bei einer Ausführungsform der Erfindung wird die Benutzerbe­ rechtigung, auf eine Funktion einer Software-Anwendung zuzu­ greifen, die in einem Aspekt eingebettet ist, beherrscht von der aktuellen Sicherung des Metaobjekts. Die Erfindung er­ möglicht es, die Softwarefunktionen als Aspekte zu implemen­ tieren, die in einer sicheren Weise zusammenarbeiten.

Sicherheitsaspekt

Ein Aspekttyp ist ein Sicherheitsaspekt. Fig. 3 zeigt ein Metaobjekt 40, welches eine Prozeßausrüstung darstellt, wie zum Beispiel eine Mischereinheit, die einen Sicherheitsa­ spekt 48 hat. Fig. 4 zeigt ein Metaobjekt 50, welches eine Prozeß-Entität darstellt, die einen Sicherheitsaspekt 58 hat.

Erlaubnisse in einem Sicherheitsaspekt eines Metaobjekts de­ finieren, welche Art von Benutzerzugang erlaubt wird. Bei­ spiele für Erlaubnisse sind "ansehen", "bedienen", "steuern" "verwalten" "einstellen" "zuweisen" "befehlen" und so weiter.

Fig. 6 zeigt eine Vielzahl von Sicherheitsaspekten, die von einem Metaobjekt übernommen (ererbt) sind. Ein Sicherheitsa­ spekt enthält eine Vielzahl von Erlaubnissen. In dem Sicher­ heitsaspekt ist jede Erlaubnis (73, 76) einer Liste von Be­ nutzern (75, 78) zugeordnet. Als Eintrag in eine Liste kommt ein einzelner Benutzer oder eine Gruppe von Benutzern in Be­ tracht. Jede Liste von Benutzern ist einer bestimmten Er­ laubnis zugeordnet. Beispielsweise kann eine Erlaubnis "ansehen" einer Liste von Benutzern zugeordnet sein, welche sowohl individuelle Benutzer als auch eine Gruppe von Benut­ zern enthält. Beispielsweise kann "ansehen" zulässig sein für einen bestimmten Benutzer, der Bill heißt, für einen be­ stimmten Benutzer, der Jim heißt, für eine Gruppe von Benut­ zern, die sich mit der Produktionsplanung befaßt, und für eine Gruppe von Bedienpersonen für den Prozeß. Eine solche Liste könnte wie folgt aussehen: ("Bill", "Jim", Produkti­ onsplaner, Tagesschicht-Bedienperson).

Die Definition einer Liste von Benutzern, wobei die Liste einer bestimmten Erlaubnis zugeordnet ist, ist dem Fachmann bestens bekannt und gehört als solche zum Stand der Technik.

Bei einer bevorzugten Ausführungsform definieren mindestens zwei Sicherheitsaspekte eines Metaobjekts das Recht eines Benutzers, auf Zugang zu dem Metaobjekt, und insbesondere, das Recht des Benutzers, auf Aspekte, die dem genannten Me­ taobjekt zugeordnet sind, einzuwirken. Sobald ein Benutzer eine Anmeldung bei dem System vorgenommen hat, wird die ak­ tuelle Benutzerberechtigung auf Zugang zu einem Aspekt eines Metaobjekts bestimmt von einem aktuellen Satz von Sicher­ heitsaspekten und der Konfiguration dieser Sicherheitsa­ spekte.

Die Gültigkeit einer bestimmten Erlaubnis hängt von jedem Aspekt ab, auf den sich die Erlaubnis bezieht. Die gültige Erlaubnis, auf einen Aspekt zuzugreifen, wird in dem Aspekt selbst definiert. Ein bestimmte Erlaubnis kann für mehrere Aspekte gelten. Beispielsweise kann die Erlaubnis "bedienen" gültig sein für einen Aspekt, wie zum Beispiel die Funktion zum Starten des Transportes von Gütern, eines Metaobjekts, welches ein Fördersystem repräsentiert. Innerhalb desselben Metaobjekts kann die Erlaubnis "betätigen" auch gültig sein für einen Aspekt, welcher ein Schaubild einer Prozeßgraphik aufruft, die eine Änderung der Geschwindigkeit und der Last des Förderers zuläßt. Die Einrichtung der Gültigkeit einer Erlaubnis für einen bestimmten Aspekt ist durch einen Sy­ stemverwalter konfigurierbar. Um auf bestimmte Aspekte zu­ greifen zu können, ist eine Kombination von Erlaubnissen notwendig.

Hierarchische Strukturen

Um mit allen Informationen in einem Steuer- und Fabrikati­ ons-Ausführungssystem umgehen zu können, müssen diese in ei­ ner bestimmten Weise organisiert sein. Eine effiziente Me­ thode, die Informationen eines Steuer- und Fabrikations-Aus­ führungssystems zu organisieren, besteht in der Verwendung eines Konzeptes, welches "Strukturen" genannt wird.

Fig. 2 zeigt drei Strukturen: Eine funktionale Struktur 20, eine Ortsstruktur 21 und eine Chargenstruktur 22, in denen Metaobjekte eingefügt sind. Jede der in Fig. 2 gezeigten Strukturen hat einen hierarchischen Aufbau.

Ein Metaobjekt, welches eine Entität repräsentiert, ist ty­ pischerweise in mehreren hierarchischen Strukturen gleich­ zeitig vorhanden. Beispielsweise hat ein bestimmter Gegen­ stand einer Prozeßausrüstung eine bestimmte Position in ei­ ner funktionalen Struktur, die von der funktionalen Aufglie­ derung der Anlage abhängt. Der Gegenstand hat auch eine räumliche Position, und somit hat er auch einen Platz in ei­ ner Ortsstruktur. Derselbe Ausrüstungsgegenstand kann zur Zeit einem bestimmten Produktionsauftrag zugeordnet sein, so daß er in eine Auftragsstruktur gehört. Da der Gegenstand zur Herstellung eines bestimmten Produktes dient, paßt er in eine Produktstruktur.

Als ein Beispiel ist in Fig. 2 das Ventil 31 FIC201 einge­ fügt in eine funktionale Struktur, eine Ortstruktur und eine Chargenstruktur. Obgleich nicht dargestellt, sollte auch be­ achtet werden, daß ein Metaobjekt auch in mehreren Positio­ nen innerhalb ein- und derselben hierarchischen Struktur vorkommen kann.

Bei der vorliegenden Erfindung beherrschen die Beziehungen zwischen der Entität, mit der gearbeitet wird, und anderen Entitäten die Sicherheit des Computersystems. Die Beziehun­ gen werden in Form von hierarchischen Strukturen beschrie­ ben, wie zum Beispiel einer funktionalen Struktur und einer Ortsstruktur. Andere hierarchische Strukturen können Auf­ tragsstrukturen, Steuerstrukturen oder Chargenstrukturen sein. Dies bedeutet, daß bei der vorliegenden Erfindung die aktuelle Berechtigung nicht nur durch den angemeldeten Be­ nutzer und die Entität, mit der gearbeitet wird, bestimmt wird, sondern auch von Beziehungen zwischen Entitäten.

Übernahme von Sicherheiten von Mutter-Metaobjekten in einer hierarchischen Struktur

Fig. 2 zeigt die Übernahme von Sicherheit in einer hierar­ chischen Struktur, wie zum Beispiel einer funktionalen Struktur 20.

Ein Sicherheitsaspekt eines Metaobjekts wird von einem Mut­ terobjekt in einer hierarchischen Struktur übernommen. Ein Kind kann seinerseits ein Mutterobjekt sein, welches seiner­ seits andere Kinder hat. Es kann also ein Sicherheitsaspekt aus die Hierarchie einer Struktur übernommen werden. Das Mutter-Metaobjekt 23 ist einer Anzahl von Aspekten zugeord­ net. Der/die Sicherheitsaspekt oder -aspekte eines Mutter-Metaobjekts enthält einen Anzeiger (flag) TBI = "Zu Überneh­ men" 26. Als Beispiel kann in der funktionalen Struktur ein Metaobjekt 23 eine Mischereinheit repräsentieren. Seine Kin­ der in der hierarchischen Struktur würden den mit "Zu Über­ nehmen" markierten Sicherheitsaspekt 26 übernehmen. Das Me­ taobjekt Milchzufluß 33, welches ein Kind der Mischereinheit 23 ist, würde diesen Sicherheitsaspekt übernehmen. Metaob­ jekte, die unter dem Milchzufluß eingeordnet sind, würden ihrerseits denselben Sicherheitsaspekt übernehmen. Ein Meta­ objekt, welches unter dem Milchzufluß 33 eingeordnet ist, kann eine funktionale Einheit FIC201 sein, die aus einem Steuerprogramm 35, einem Flußübertrager 34 und einem Ventil 31 besteht. Der Zeitpunkt, in dem die Kinder der Mischerein­ heit die Sicherheitsaspekte der Mischereinheit übernehmen, ist der Zeitpunkt der Einfügung in die funktionale Struktur.

Wie bei dem Ausführungsbeispiel oben beschrieben, wird der Sicherheitsaspekt eines Mutter-Metaobjekts in einer hierar­ chischen Struktur von oben nach unten übernommen. Eine Über­ nahme erfolgt unter der Voraussetzung, daß ein Sicherheitsa­ spekt auf "Zu Übernehmen" eingestellt ist. Eine Übernahme ist nicht begrenzt auf die direkten Kinder eines Mutter-Me­ taobjekts, sondern eine Übernahme erfolgt für alle Nachkom­ men des Mutter-Metaobjekts in einer bestimmten hierarchi­ schen Struktur.

In Fig. 2 ist jedes Metaobjekt 23 bis 25 mit einem Sicher­ heitsaspekt konfiguriert. Die Metaobjekte sind Mutter-Meta­ objekte in Bezug auf ihre Kinder. Für jeden Sicherheitsa­ spekt 28 bis 30, der mit "Zu Übernehmen" 26 markiert ist, wird jede Erlaubnis und die zugeordnete Liste von Benutzern von jedem Mutter-Metaobjekt 23 bis 25 gehalten.

Übernahme erfolgt für den Fall, daß ein Metaobjekt in eine hierarchische Struktur eingefügt wild. Bei einem bevorzugten Ausführungsbeispiel der Erfindung ist die Übernahme eines Sicherheitsaspektes über eine Struktur unabhängig davon, ob das Ereignis von einem Mutter-Metaobjekt verursacht wird, welches auf einer höheren Position (23) eingeordnet wird, oder von einem Kinder-Metaobjekt, welches auf einer niedri­ geren Position (31) eingeordnet wird. Die Übernahme eines Sicherheitsaspektes trifft zu, solange ein Metaobjekt (23) mit einem Sicherheitsaspekt, der auf "Zu Übernehmen" einge­ stellt ist, auf einer höheren Stufe plaziert ist.

Wie oben kurz beschrieben wurde, implementieren Metaobjekte, zusätzlich zu der Darstellung von Feldgeräten und Prozeß- Entitäten als Software-Objekte, andere abstraktere Objekte. Auch bei solchen Repräsentationen übernehmen die Metaobjekt Sicherheitsaspekte.

Übernahme von Sicherheiten von Metaobjekten in mehrfachen hierarchischen Strukturen

Bei einer Ausführungsform der Erfindung übernimmt ein Meta­ objekt, welches eine Entität der realen Welt repräsentiert, Sicherheitsaspekte von mehreren hierarchischen Strukturen.

Fig. 2 zeigt ein Beispiel, bei welchem ein Metaobjekt ein in eine funktionale Struktur 20 eingeordnetes Ventil 31 re­ präsentiert, auch in eine Ortsstruktur 21 und in eine Char­ genstruktur 22 eingeordnet sein kann. In jeder hierarchi­ schen Struktur kann das Metaobjekt, welches ein Ventil re­ präsentiert, einen Sicherheitsaspekt 28 bis 30 übernehmen. Die Kombination dieser Sicherheitsaspekte bildet die Grund­ lage für die augenblickliche Berechtigung.

Beispielsweise kann ein Ventil 31 in einem speziellen Raum untergebracht sein, der zu einem Prozeßbereich 24 gehört, wodurch es zu einem Kind des Prozeßbereiches in der Orts­ struktur 21 wird. Das Ventil hat eine bestimmte Prozeß-Funktionalität, die es zu einem Kind eines Metaobjekts macht, welches den Milchzufluß 33 zu einer Produktionszelle, wie zum Beispiel einer Mischereinheit, in der funktionalen Struktur 20 repräsentiert. Das Ventil und andere Prozeßaus­ rüstungen sind gegenwärtig einer bestimmten Bananenmilch-Charge 25 zugeordnet, wodurch das Ventil zu einem Kind der Chargenstruktur 22 wird.

Da das Metaobjekt in mehreren Strukturen gleichzeitig einge­ ordnet sein kann, übernimmt es die Sicherheitseinstellungen von mehreren Metaobjekten aus mehreren Strukturen.

Fig. 7 zeigt den Programmablaufplan eines Verfahrens zur Sicherheitskonfiguration eines Metaobjektes durch Einfügung des Metaobjektes in mehrere Strukturen.

Fig. 2 zeigt ein Beispiel, bei welchem ein Metaobjekt 31 drei Sicherheitsaspekte 28 bis 30 übernommen hat, deren drei entsprechenden Referenzen von dem Metaobjekt 31 gehalten werden. Zugang zu einem bestimmten übernommenen Sicher­ heitsaspekt 28 des Metaobjekts 31 erfolgt durch Referenz des Sicherheitsaspekts. Dieser Sicherheitsaspekt ist markiert mit "Zu Übernehmen" 26 in einem Mutter-Metaobjekt und wird von dem Mutter-Metaobjekt auf einer höheren Position in der Hierarchie gehalten.

Dynamische Sicherheit und dynamische Benutzerberechtigung von Metaobjekten in mehrfachen hierarchischen Strukturen

Ferner verliert bei einer bevorzugten Ausführungsform das Metaobjekt, wenn es an seiner Position in einer bestimmten hierarchischen Struktur gelöscht wird, die Zuordnung zu den Sicherheitsaspekten, die es vorher übernommen hatte von oder über seine Mutter in der hierarchischen Struktur. Die Si­ cherheit ist dynamisch. Da die Benutzerberechtigung auf der Sicherheit basiert, ist die Benutzerberechtigung, auf minde­ stens ein Aspekt eines Metaobjekt zugreifen zu können, dyna­ misch während der Zeit zwischen Anmeldung und Abmeldung.

Wenn das Metaobjekt in eine andere Position in derselben hierarchischen Struktur oder in eine andere hierarchische Struktur eingefügt wird, übernimmt es neue Sicherheitsa­ spekte von seinem neuen Mutter-Metaobjekt.

Bei einem bevorzugten Ausführungsform kann ein Metaobjekt zwischen verschiedenen Positionen in einer oder mehreren Strukturen verschoben werden, wobei es beispielsweise Pro­ dukte repräsentiert, die durch eine Fertigungsstraße laufen, oder Produktionsaufträge, die verschiedenen Prozeßausrüstun­ gen zugeordnet sind. Das Verschieben eines Metaobjekts in einer hierarchischen Struktur ist vom Standpunkt der Über­ nahme eines Sicherheitsaspekts gleichbedeutend damit, daß das Metaobjekt zuerst in seiner Position in einer hierarchi­ schen Struktur gelöscht wird und das Metaobjekt dann in ei­ ner neuen Position in einer hierarchischen Struktur einge­ fügt wird.

Benutzer

Ein Benutzer gehört zu einer Gruppe von Benutzern, die eine bestimmte Verantwortung tragen. Solche Gruppen von Benutzern sind Bedienungspersonen, Steuerungsingenieure, Auftragsver­ walter, Verkaufspersonen, Produktionsplaner oder Wartungs­ leiter. Zusätzlich zu seiner Zugehörigkeit zu einer Gruppe hat jeder Benutzer eine Benutzeridentität.

Der Benutzer ist typischerweise eine Person. Aber als Benut­ zer wird jeder Ausübende eines Prozesses betrachtet, der bei dem Sicherheitssystem angemeldet ist. Beispielsweise kann der Benutzer auch ein Prozeß sein, geschaffen durch ein Skript oder Programm, welches auf einem Computer oder einem Prozessor läuft, wobei der Prozeß Handlungen ausführt, wie zum Beispiel das Wiederauffinden von Informationen für einen Produktionsbericht.

Benutzeranmeldung

Ein Benutzer wird durch eine Anmeldeprozedur identifiziert. Zu der Anmeldeprozedur können Schritte gehören, wie zum Bei­ spiel die Eingabe eines Benutzernamens oder eines Kennwortes auf dem Bildschirm mittels einer Tastatur, die Benutzung ei­ nes körperlichen Gegenstandes, wie zum Beispiel eines Schlüssels zur Freigabe einer Bedienertastatur oder die Be­ nutzung einer Chipkarte zur Identifikation. Die Anmeldepro­ zedur kann auch über ein tragbares Gerät erfolgen oder durch Verwendung der Identität eines Benutzers, der bereits bei einem Betriebssystem, wie zum Beispiel einer Arbeitsstation, angemeldet ist. Die Software, welche die Anmeldeprozedur für das System handhabt, läuft auf einer oder mehreren Arbeits­ stationen.

Nach der Anmeldung wird der Benutzer erkannt und identifi­ ziert mit Hilfe einer einmaligen Benutzeridentität. Zusätz­ lich zu dem Besitz einer einmaligen Identität kann der Be­ nutzer als zugehörig zu einer oder mehreren Gruppen von Be­ nutzern erkannt werden.

Die vorliegende Erfindung beschreibt ein Verfahren, bei wel­ chem die Berechtigung während der Zeit zwischen der Anmel­ dung und der Abmeldung dynamisch ist. Sicherheitsaspekte des Metaobjekts, mit welchem der Benutzer in Dialog tritt, be­ stimmen die Berechtigung. Wie oben beschrieben, werden diese Sicherheitsaspekte dynamisch übernommen von anderen Metaob­ jekten durch Übernahme in einer Vielzahl von hierarchischen Strukturen. Da die Sicherheit eines Metaobjekts dynamisch ist, ist die Benutzerberechtigung dynamisch. Folglich hängt die Berechtigung in dynamischer Weise davon ab, auf welches Metaobjekt der Benutzer zugreift und von den Beziehungen dieses Metaobjekts zu anderen Metaobjekten in einer Mehrzahl von hierarchischen Strukturen.

Bewertung der aktuellen Benutzerberechtigung

Die Fig. 3 und 4 zeigen, daß ein Metaobjekt 40, 50 einer aktuellen Sicherheit 48, 58 zugeordnet ist. Bei einer Aus­ führungsform der Erfindung erfolgt die Bewertung der aktuel­ len Benutzerberechtigung für den Zugriff auf einen Aspekt 41 bis 47, 51 bis 57 des Metaobjekts 40, 50 mittels einer Zu­ gangsprüffunktion.

Die Zugangsprüffunktion 100 verwendet Hinweise auf die aktu­ elle Benutzerberechtigung 101, die Identität des Metaobjekts 102 und die Identität des Aspekts 103 als Eingangsgrößen für die Durchführung der Bewertung.

Fig. 8 zeigt eine Zugangsprüffunktion 100. Die Überprüfung erfolgt durch Erfassen Abbildung (mapping) der aktuellen Si­ cherheitsaspekte des Metaobjekts mit der Benutzeridentität und der gültigen Erlaubnis des Benutzers auf Zugriff auf einen bestimmten Aspekt.

Die Funktion holt Informationen über gültige Erlaubnisse 105 von den Aspekten 41 bis 47, 51 bis 57 heran, auf welche der Benutzer zuzugreifen versucht. Für einen Aspekt ist eine be­ stimmte Erlaubnis oder eine Kombination von Erlaubnissen gültig.

Die Funktion prüft alle aktuellen Sicherheitsaspekte 106 des Metaobjekts. Die Funktion prüft, ob eine Übereinstimmung be­ steht zwischen der zuvor herangeholten gültigen Erlaubnis, zum Beispiel "zuweisen", und einer Erlaubnis in irgendeinem der Sicherheitsaspekte. Siehe Fig. 6, die Sicherheitsa­ spekte 70 bis 72 für Einzelheiten von Erlaubnissen zeigt.

Angenommen, eine Übereinstimmung von Erlaubnissen ist vor­ handen, so prüft die Funktion, ob die Benutzeridentität 101 eine Übereinstimmung mit den Benutzerlisten 75-76, 78-79, welche den Erlaubnissen 73-74, 76-77 entsprechen, der Si­ cherheitsaspekte zeigt. Je nach Ergebnis der Zugangsprüfung wird dem Benutzer der Zugang gewährt oder verwehrt.

Priorität hierarchischer Strukturen

Bei der vorliegenden Erfindung definieren Sicherheitsa­ spekte, die aus verschiedenen hierarchischen Strukturen von einem bestimmten Metaobjekt übernommen werden, gewöhnlich verschiedene Erlaubnisse. Jedoch kann ein Sicherheitsaspekt eine Erlaubnis definieren, die Zugang zu einem bestimmten Aspekt gestattet, während ein anderer Sicherheitsaspekt, der aus einer anderen hierarchischen Struktur übernommen wird, den Zugang verwehren kann. Aus diesem Grund enthält das Sy­ stem eine Definition bezüglich der Priorität der hierarchi­ schen Strukturen.

Als Beispiel wird in Fig. 2 eine funktionale Struktur 20 so definiert, daß sie Priorität vor einer Ortsstruktur 21 hat. Ein Metaobjekt, welches ein Ventil FIC201 31 repräsentiert, übernimmt Sicherheitsaspekte von einer funktionalen Struktur und einer Ortsstruktur. Fig. 6 zeigt die übernommenen Si­ cherheitsaspekte des Ventils für dieses Beispiel. Durch den übernommenen Sicherheitsaspekt 70 wird einer Gruppe von Be­ nutzern, die sich beispielsweise mit der Produktionsplanung befassen, die Erlaubnis "Ansicht" 76, 78 gewährt. Das Ventil FIC201 übernimmt auch einen Sicherheitsaspekt von der Orts­ struktur 71. Durch diesen übernommenen Sicherheitsaspekt 71 wird der Produktionsplanungsgruppe die Erlaubnis "Ansicht" 77 verweigert, da die Gruppe nicht in der entsprechenden Li­ ste von Benutzern auftaucht. Da aber die funktionale Struk­ tur als die mit der höheren Priorität definiert ist, bei welcher der Produktionsplanungsgruppe Zugang gewährt wird, kann ein zu der Produktionsplanungsgruppe gehörender Benut­ zer auf jeden Aspekt des Metaobjekts zugreifen, welcher die Erlaubnis "Ansicht" definiert hat.

Anmeldung bei einer Mehrzahl von Software-Anwendungen

Unter nochmaligem Bezug auf Fig. 3 braucht sich ein Benut­ zer nur einmal anzumelden, selbst wenn dabei mehrere Soft­ ware-Anwendungen betroffen sind. Bei einer Ausführungsform der Erfindung führt eine Anmeldung bei einer solchen Soft­ ware-Anwendung über einen Aspekt nicht dazu, daß eine andere Benutzerumgebung gestartet wird. Vielmehr wird das Ergebnis eines Funktionsaufrufes angezeigt. Beispielsweise kann eine Liste von Artikelnummern von Ersatzteilen für eine Pumpe, die ein Kind eines Prozeßausrüstungs-Objektes 40 ist, von einem Wartungssystem 45 angezeigt werden, ohne daß der Be­ nutzer eine weitere Anmeldung vorzunehmen braucht. Um Arti­ kelnummer für Ersatzteile aufzulisten, kann der Aspekt eine Mehrzahl von Softwarefunktionen des Wartungssystems haben. Die Benutzerberechtigung für den Zugriff auf eine Mehrzahl dieser Software-Anwendungen hängt ab von den Beziehungen zwischen dem bearbeiteten Metaobjekt und den Beziehungen zwischen dem Metaobjekt und anderen Metaobjekten in einer Mehrzahl von hierarchischen Strukturen. Die Erfindung be­ schreibt ein System, welches die Zusammenarbeit verschiede­ ner Softwarefunktionen einer Mehrzahl von Software-Anwendun­ gen ermöglicht, um in einer sicheren Weise eine integrierte Funktionalität des Metaobjekts bereitzustellen.

Wechsel einer Benutzerberechtigung von einem Benutzer zu einen anderen

Bei einer bevorzugten Ausführungsform wechselt die Benutzer­ berechtigung für den Zugriff auf einen bestimmten Aspekt ei­ nes Metaobjekts von einem Benutzer zu einen anderen, wenn das Metaobjekt seine Position in einer hierarchischen Struk­ tur verändert. Beispielsweise kann das Recht des Zugangs zur Zuweisung von Rohmaterial von einem Produktionsplaner auf eine Bedienperson übergehen, wenn das Produkt aus der Pla­ nungsphase in die Prozeßphase bewegt wird.

Ein solches Beispiel ist eine Anlage, die gemäß Fig. 2 Milchprodukte produziert. In der Anlage wird eine Software- Anwendung für die Produktionsplanung verwendet, und eine an­ dere Software-Anwendung wird für die Handhabung der Zuwei­ sung von Zusätzen verwendet. Während der Produktionspla­ nungsphase befaßt sich ein individueller Benutzer der Benut­ zergruppe, die Produktionsplaner heißt, mit der Vorbereitung eines neuen Produktionspostens. Der Produktionsplaner wird bei dem System, wie von der Erfindung definiert, angemeldet.

Selbst wenn der Produktionsposten noch keine körperliche Ge­ stalt angenommen hat, welche einer Entität der realen Welt entspricht, wird auf dieser Stufe ein Metaobjekt angelegt. Der Benutzer ruft über das Metaobjekt, welches den Posten repräsentiert, die Funktionen der Produktionsplanungs-Soft­ ware auf. In Fig. 2 wird das Metaobjekt auf dieser Stufe zu der funktionalen Struktur 20 gehören und, genauer, ein Kind der Produktionsplanung 37 sein. Der Sicherheitsaspekt des Metaobjekts wird von einem Mutter-Metaobjekt übernommen, in diesem Falle dem Produktionsplanungsobjekt.

Der übernommene Sicherheitsaspekt des Kinder-Metaobjekts de­ finiert eine Berechtigung auch für Systeme, die aus der Sicht einer bestimmten Gruppe von Benutzern oder eines indi­ viduellen Benutzers als zweitrangig betrachtet werden kön­ nen. Während der Posten sich in der Planungsphase befindet, ist der Produktionsplaner berechtigt, Zusätze in einem La­ gerbestandssystem 57 zuzuweisen oder Zuweisungen zu beseiti­ gen, siehe Fig. 4. Das Lagerbestandssystem ist aus der Sicht des Produktionsplaners zweitrangig. Die Zuordnung von Zusätzen erfolgt durch einen Aspekt des Metaobjekts, welches den Posten repräsentiert. Der Aufruf einer solchen Funktion erfolgt aus einer anderen Software-Anwendung, die für den Benutzer verborgen ist. Die Zuweisung von Zusätzen kann bei­ spielsweise auf der Grundlage eines Hauptrezeptes erfolgen, welches eine Liste von Zutaten und eine gewünschte Menge enthält, welches für den Posten auftragsspezifisch ist. Wenn der Benutzer der Produktionsplanergruppe alle notwendi­ gen Planungsschritte abgeschlossen hat, einschließlich der Zuweisung von Zusätzen, wird der Posten als für die Produk­ tion bereit betrachtet. Sobald der Posten für die Produktion geplant ist, wird das Metaobjekt in eine andere Position der funktionalen Struktur verschoben.

Bei der Verschiebung des Metaobjekts verliert dieses den von dem Mutter-Metaobjekt der Produktionsplanung übernommenen Sicherheitsaspekt. An seiner Stelle übernimmt das Metaobjekt den Sicherheitsaspekt des Mutter-Metaobjektes an der aktuel­ len Position in der funktionalen Struktur. In dieser Posi­ tion wird das Posten als im Prozeß befindlich betrachtet. Wenn der Posten sich im Prozeß befindet, erhält eine be­ stimmte Bedienperson, die die Verantwortung für eine be­ stimmte Produktionslinie trägt, wie zum Beispiel die flüs­ sige Verarbeitungslinie 38 in Fig. 2, die Berechtigung, Zu­ sätze zuzuweisen oder Zuweisungen aufzuheben. Die Bedienper­ son verwendet ein System für die Prozeßsteuerung als das erstrangige System. Das Lagerbestandssystem für die Zuwei­ sung von Zusätzen wird für die Bedienperson als zweitrangi­ ges System betrachtet. Die Metaobjekte, welche Zutaten in dem Rohmaterialsystem repräsentieren und die vorher dem Po­ sten zugeordnet waren, sind nun unter Kontrolle der Bedien­ person. Der Sicherheitsaspekt des Metaobjekts, welches den Posten repräsentiert, gestattet es dem Produktionsplaner nicht mehr, die Menge des zugewiesenen Materials zu ändern.

Liste und Zugang zu Aspekten

Fig. 5 zeigt, wie die Anzahl der Aspekte reduziert wird, die dem Benutzer in jedem bestimmten Zeitpunkt angeboten werden. Zusätzlich zu den oben erwähnten Verfahren und Funk­ tionen verbessert die vorliegende Erfindung die Interaktion des Benutzers durch Reduzierung der Aspekte, die in einer Liste auf der Grundlage der aktuellen Sicherheit eines Meta­ objekts dargeboten werden. Ein Benutzer 60 kann Aspekte, auf die ihm der Zugriff erlaubt ist, auf dem Bildschirm einer Arbeitsstation oder eines tragbaren Gerätes auflisten. Die Liste 62 wird vorzugsweise in einem Einblendmenü angezeigt. Nur diejenigen Aspekte eines bestimmten Metaobjekts, auf die zuzugreifen der Benutzer zur Zeit berechtigt ist, werden in dem Einblendmenü angezeigt. Abhängig von der Konfiguration des Systems werden diejenigen Aspekte, für die der Benutzer zur Zeit keine Zugangsberechtigung hat, entweder überhaupt nicht angezeigt, oder sie sind in der Liste abgeblendet.

Dies bedeutet, daß eine als ein Aspekt implementierte Soft­ warefunktion auf einem Bildschirm nur über ein Metaobjekt an einer bestimmten Positionen in einer Mehrzahl von hierarchi­ schen Strukturen aufgelistet werden kann. Als ein Beispiel hat ein Metaobjekt 61 übernommene Sicherheitsaspekte 63 von verschiedenen hierarchischen Strukturen. Dem Benutzer 60 wird eine Liste 62 von Aspekten angezeigt, die auf dem aktu­ ellen Satz von Sicherheitsaspekten basiert.

Beispielsweise repräsentiert ein Metaobjekt einen Produkti­ onsposten, wie zum Beispiel Bananeneiscreme. Der Posten ist herzustellen und abzupacken. Während der Herstellung waren mehrere Prozeßgraphikanzeigen für die Bedienperson zugäng­ lich. Während der Herstellung waren diese Prozeßgraphikan­ zeigen, wenn die Bedienperson die Aspekte des Postens aufli­ stete, in der Liste sichtbar. Nach der Herstellung und dem Abpacken wird der Posten in die Ortsstruktur zu dem Gefrier­ lagerhaus verschoben. Aber wenn der Posten zu dem Gefrierla­ gerhaus verschoben wird, ist die Prozeßgraphikanzeige für die Steuerung nicht zugänglich. Bei der vorliegenden Erfin­ dung bewirken die Sicherheitsaspekte des hergestellten Po­ stens, daß die Prozeßgraphikanzeige zugänglich ist, solange sich der Posten im Herstellungsprozeß befindet, aber nicht zugänglich ist, wenn der Posten sich im Gefrierlagerhaus be­ findet. Wenn der Posten sich im Gefrierlagerhaus befindet und ein Benutzer Aspekte auflistet, werden Interaktionen mit der Prozeßgraphikanzeige nicht länger in der Liste der Aspekte angezeigt.

Bei einer Ausführungsform der Erfindung ist die aktuelle Si­ cherheit eines Metaobjekts unabhängig davon, von welcher hierarchischen Struktur ein Benutzer ein Anordnung auswählt. Das bedeutet, daß die aktuelle Benutzerberechtigung unabhän­ gig davon ist, von welcher hierarchischen Struktur ein Be­ nutzer ein Metaobjekt auswählt. Wie beispielsweise Fig. 2 zeigt, ist ein Ventil 31 in einer Ortsstruktur 21 und einer funktionalen Struktur 20 eingeordnet. Die Benutzerberechti­ gung für den Zugriff auf eine Prozeßgraphikanzeige 36 des Ventils ist die gleiche, egal, ob der Benutzer das Ventil aus der Ortsstruktur 21 oder der funktionalen Struktur 20 auswählt.

Es ist zu beachten, daß die Anwendung der vorliegenden Er­ findung nicht begrenzt ist auf Funktionen herkömmlicher Steuersysteme oder Fabrikations-Ausführungssysteme für die Verwendung in industriellen Anwendungen, sondern sich auch auf andere Gebiete erstreckt. Hierzu gehören geschäftliche und kommerzielle Aktivitäten, wie zum Beispiel Produktions­ management-, Verkaufs-, Design-, Geschäfts- und Finanzsy­ steme. Zu den Anwendungsgebieten der Erfindung gehört auch die Steuerung von Ausrüstungen an Orten wie zum Beispiel in einem Bürohaus, einem Wohnhaus, einem Schiff oder einer Woh­ nung. Die Anwendbarkeit der Erfindung erstreckt sich auch auf computer-gestützte Infrastrukturen, wie zum Beispiel die Verteilung elektrischer Energie, Telefon- und Nachrichten­ netzwerke sowie auch Unterstützungssysteme für Straßen und Eisenbahnen. Daher ist zu beachten, daß, obwohl die vorlie­ gende Erfindung an Beispielen im Zusammenhang mit Systemen beschrieben wurde, zu denen Ventile, Prozeßgefäße, Mischer­ einheiten und Chargen gehören, Ausführungsformen der vorlie­ genden Erfindung auf jeden anderen geeigneten Typ von Enti­ täten anwendbar ist.

Es wird auch darauf hingewiesen, daß, während beispielhafte Ausführungsformen der Erfindung beschrieben wurden, es ver­ schiedene Variationen und Modifikationen gibt, die an der beschriebenen Lösung vorgenommen werden können, ohne den Be­ reich der vorliegenden Erfindung, wie er in den beigefügten Ansprüche definiert ist, zu verlassen.

Claims (27)

1. Computersystem mit einer Sicherheitseinrichtung in einem computer-gestützten Steuersystem (1), zu welchen Computersy­ stem gehören:
eine Arbeitsstation (4),
ein Softwaresystem, welches eine Entität der realen Welt (10, 11) als ein erstes Software-Objekt (31) repräsen­ tiert,
ein System zur Steuerung und/oder Überwachung der Entität der realen Welt,
Mittel zur Einfügung eines Software-Objekts in eine hier­ archische Struktur,
Mittel zur Identifizierung eines individuellen Benutzers im Augenblick der Anmeldung für das genannte Computersy­ stem,
Mittel zur Identifizierung des individuellen Benutzers während der Zeit zwischen Anmeldung und Abmeldung anhand einer Benutzeridentität, dadurch gekennzeichnet, daß
das erste Software-Objekt (31) in mindestens zwei hierar­ chische Strukturen (20, 21, 22) aus Software-Objekten ein­ gefügt ist und das erste Software-Objekt mindestens einen Sicherheitsaspekt (28) von einem zweiten Software-Objekt (23) übernimmt, wobei das zweite Software-Objekt (23) auf einer höheren Position als das erste Software-Objekt in einer der genannten hierarchischen Strukturen eingeordnet ist, und das erste Software-Objekt mindestens einen Si­ cherheitsaspekt (29) von einem dritten Software-Objekt (24) übernimmt, wobei das dritte Software-Objekt auf ei­ ner höheren Position als das erste Software-Objekt in ei­ ner der genannten hierarchischen Strukturen eingeordnet ist,
eine aktuelle Sicherheit des ersten Software-Objekts (31) auf mindestens zwei Sicherheitsaspekten (28, 29) basiert, welche dem ersten Software-Objekt zugeordnet sind, über­ nommen über mindestens zwei hierarchische Strukturen,
eine aktuelle Benutzerberechtigung, auf mindestens einen Aspekt des ersten Software-Objektes zuzugreifen, auf min­ destens zwei Sicherheitsaspekten (28, 29) basiert, über­ nommen über mindestens zwei hierarchische Strukturen in Kombination mit der Benutzeridentität in dem genannten Computersystem.

2. Computersystem nach Anspruch 1, wobei der Sicherheitsa­ spekt (28, 29), der zuvor über eine hierarchische Struktur (20, 21) übernommen wurde, seine Zuordnung zu dem genannten ersten Software-Objekt (31) verliert durch Löschung des ge­ nannten ersten Software-Objekts (31) in der hierarchischen Struktur (20, 21), wodurch die Benutzerberechtigung auf Zu­ griff auf mindestens einen Aspekt des ersten Software-Ob­ jekts während der Zeitspanne zwischen Anmeldung und Abmel­ dung dynamisch ist.

3. Computersystem nach Anspruch 1, zu welchem ferner ein Fa­ brikations-Ausführungssystem gehört, dadurch ge­ kennzeichnet, daß eine Softwarefunktion des Fa­ brikations-Ausführungssystem (2) als ein Aspekt des genann­ ten ersten Software-Objekts verfügbar ist.

4. Computersystem nach einem der vorhergehenden Ansprüche, wobei jedes der genannten Software-Objekte als ein Metaob­ jekt (40, 50) implementiert ist.

5. Computersystem nach Anspruch 4, wobei eine Benutzer­ schnittstelle Mittel vorsieht für:
die Auswahl eines Metaobjekts (61) durch Zeigen mittels einer Maus auf ein Metaobjekt und durch ein rechtsseiti­ ges Anklicken des Objektes oder durch ähnlichen Mitteln zur Auswahl eines Metaobjekts, und die Anzeige einer Li­ ste von Aspekten mittels eines Einblendmenüs (62) oder eines ähnlichen Mittels,
die Auswahl eines Aspektes aus der Liste von Aspekten durch ein Anklicken mit der linken Maustaste oder durch ähnliche Mittel, dadurch gekennzeichnet, daß
das Metaobjekt in zwei oder mehr hierarchische Strukturen (20, 21, 22) eingeordnet wurde,
die in der Liste (62) angezeigten Aspekte diejenigen sind, welche zu der aktuellen Benutzerberechtigung pas­ sen, und daß die Benutzerberechtigung auf der Grundlage von zwei oder mehr Sicherheitsaspekten (63, 28, 29, 30) er­ mittelt wird.

6. Computersystem nach Anspruch 5, dadurch ge­ kennzeichnet, daß die aktuelle Benutzerberechti­ gung auf Zugriff auf ein Metaobjekt unabhängig davon ist, aus welcher hierarchischen Struktur ein Benutzer ein Metaob­ jekt auswählt.

7. Computersystem nach Anspruch 6, wobei die aktuelle Benut­ zerberechtigung auf Zugriff auf einen Aspekt (41-47) durch eine Zugangsprüffunktion (100) ermittelt wird, da­ durch gekennzeichnet, daß diese Funktion Einrichtungen enthält für:
die Behandlung von Referenzen bezüglich einer Benutzeri­ dentität (101), einer Metaobjektidentität (102) und einer Aspektidentität (103), die als Eingangsgrößen bei einem Aufruf der Funktion definiert sind,
die Behandlung einer Referenz bezüglich eines Software- Objektes (104), welche nach einem Ergebnis fragt, welches als Ausgangsgröße bei dem Aufruf der Zugangsprüfung defi­ niert ist,
das Zugreifen auf Erlaubnisse in dem Aspekt unter Bezug­ nahme auf die Aspektidentität (103) und das Auffinden von Informationen über eine gültige Erlaubnis (105) auf Zu­ gang zu dem Aspekt,
das Zugreifen auf alle Sicherheitsaspekte (106, 70-72) durch Bezugnahme auf die Metaobjektidentität,
die Prüfung, ob es eine Übereinstimmung gibt zwischen der zuvor in dem Aspekt aufgefundenen gültigen Erlaubnis und den Erlaubnissen in allen Sicherheitsaspekten (70-72), und, vorausgesetzt, daß mindestens eine Übereinstimmung (74) vorhanden ist, die weitere Prüfung anhand der Benut­ zeridentität, ob es eine Übereinstimmung gibt zwischen dem Benutzer und einem Eintrag in der Benutzerliste (76), welche der zuvor übereinstimmenden Erlaubnis (74) ent­ spricht,
die Ausgabe des Ergebnisses "Gewährung" oder "Verweigerung" (107) in Abhängigkeit des Ergebnisses der Prüfung an das aufrufende Software-Objekt durch die Refe­ renz des Software-Objektes.

8. Computersystem nach Anspruch 7, dadurch ge­ kennzeichnet, daß es eine Einrichtung enthält für die Definition einer Priorität zwischen hierarchischen Strukturen (20-22) und daß die genannte Priorität für die Bestimmung verwendet wird, welcher Sicherheitsaspekt Priori­ tät vor einem anderen Sicherheitsaspekt haben soll, wenn die genannten Sicherheitsaspekten an ein Metaobjekt über minde­ stens zwei hierarchische Strukturen übergeben (vererbt) wur­ den, und die genannten Sicherheitsaspekte die gleiche Er­ laubnis (76, 77) definieren, die ein bestimmter Benutzer benötigt, um auf einen Aspekt des Metaobjekts zugreifen zu können.

9. Computersystem nach Anspruch 4, dadurch ge­ kennzeichnet, daß es Einrichtungen enthält zur Änderung einer Benutzerberechtigung, wenn ein Metaobjekt seine Position in einer hierarchischen Struktur verändert, von einem Benutzer zu einem anderen Benutzer, wobei die Be­ nutzerberechtigung das Recht auf Zugang zu einem bestimmten Aspekt des Metaobjekts definiert.

10. Verfahren zur Einrichtung einer Sicherheit in einem Com­ putersystem, welches ein computergestütztes Steuersystem (1) enthält, wobei zu dem Verfahren folgende Schritte gehö­ ren:

• - Definition (80) eines ersten Software-Objekts (31) zur Darstellung einer Entität der realen Welt,
• - Definition (81) eines zweiten Software-Objekts (23), wel­ ches mindestens einen Sicherheitsaspekt (28) hat,
• - Konfiguration (82) des zweiten Software-Objekts (23) in der Weise, daß es als Mutter-Software-Objekt wirkt,
• - Einstellung (83) von mindestens einem Sicherheitsaspekt (28) des zweiten Software-Objektes (23) als übernommen,
• - Einfügung (84) des zweiten Software-Objekts in eine erste hierarchische Struktur (20), so daß alle Software-Objekte unter dem zweiten Software-Objekt in der ersten hierar­ chischen Struktur (20) mindestens einen Sicherheitsaspekt (28) von dem zweiten Software-Objekt übernehmen,
• - Einfügung (85) des ersten Software-Objekts (31) in die erste hierarchische Struktur (20) und damit Zuordnung des ersten Software-Objekts (31) als Kind des zweiten Soft­ ware-Objekts (23), oder Zuordnung des ersten Software-Ob­ jekts als ein Kind eines Software-Objekt in einer niedri­ geren Position in der ersten hierarchischen Struktur als derjenigen des zweiten Software-Objekts (23), wobei das erste Software-Objekt mindestens einen Sicherheitsaspekt (28) des zweiten Software-Objekts übernimmt,

gekennzeichnet durch folgende weitere Schritte:

• - Definition (86) eines dritten Software-Objekts (24), wel­ ches mindestens einen Sicherheitsaspekt (29) hat,
• - Konfiguration (87) des dritten Software-Objekts (24) in der Weise, daß es als Mutter-Software-Objekt wirkt,
• - Einstellung (88) von mindestens einem Sicherheitsaspekt (29) des dritten Software-Objektes (24) als übernommen,
• - Einfügung (89) des dritten Software-Objekts (24) in eine zweite hierarchische Struktur (21), so daß alle Software- Objekte unter der zweiten hierarchischen Struktur minde­ stens einen Sicherheitsaspekt (29) von dem dritten Software-Objekt übernehmen,
• - Einfügung (90) des ersten Software-Objekts (31) in die zweite hierarchische Struktur (21) und damit Zuordnung des ersten Software-Objekts als Kind des dritten Soft­ ware-Objekts (24), oder Zuordnung des ersten Software-Ob­ jekts als ein Kind eines Software-Objekts in einer nied­ rigeren Position in der zweiten hierarchischen Struktur als derjenigen des dritten Software-Objekts, so daß (91) die aktuelle Sicherheit des ersten Software-Objekts (31) eine Kombination der übernommenen Sicherheitsaspekte (28, 29) des zweiten (23) und des dritten (24) Software- Objekts darstellt.

11. Verfahren nach Anspruch 10, wobei der Sicherheitsaspekt (28, 29), der zuvor in eine hierarchische Struktur (20, 21, 22) übernommen wurde, seine Zuordnung zu dem genannten ersten Software-Objekt (31) verliert durch Löschung des genannten ersten Software-Objekts (31) in der hierarchischen Struktur (20, 21, 22), wodurch die Benutzerberechtigung auf Zugriff auf mindestens einen Aspekt des ersten Software-Objekts während der Zeitspanne zwischen Anmeldung und Abmeldung dynamisch ist.

12. Verfahren nach Anspruch 11, wobei das genannte Computer­ system ferner ein Fabrikations-Ausführungssystem enthält, dadurch gekennzeichnet, daß eine Soft­ warefunktion des Fabrikations-Ausführungssystem (2) als ein Aspekt des genannten ersten Software-Objekts verfügbar ist.

13. Verfahren nach einem der Ansprüche 10, 11 oder 12, wobei jedes der genannten Software-Objekte als ein Metaobjekt im­ plementiert ist.

14. Verfahren nach Anspruch 13 mit folgenden zusätzlichen Schritten:

• - Auswahl eines Metaobjekts (31, 61), mittels einer Benut­ zerschnittstelle, durch Zeigen mittels einer Maus auf ein Metaobjekt und durch ein rechtsseitiges Anklicken des Ob­ jektes oder durch ähnlichen Mitteln zur Auswahl eines Me­ taobjekts, und Anzeige einer Liste von Aspekten mittels eines Einblendmenüs (62) oder eines ähnlichen Mittels,
• - Auswahl eines Aspektes aus der Liste von Aspekten durch ein Anklicken mit der linken Maustaste oder durch ähnli­ che Mittel,

dadurch gekennzeichnet, daß

• - das Metaobjekt in eine oder mehr hierarchische Strukturen (20, 21, 22) eingeordnet wurde,
• - die in der Liste (62) angezeigten Aspekte diejenigen sind, welche zu der aktuellen Benutzerberechtigung pas­ sen, und daß die genannte Benutzerberechtigung auf der Grundlage von zwei oder mehr Sicherheitsaspekten (63, 28, 29, 30) ermittelt wird.

15. Verfahren nach Anspruch 14, dadurch ge­ kennzeichnet, daß die aktuelle Benutzerberechti­ gung auf Zugriff auf ein Metaobjekt unabhängig davon ist, aus welcher hierarchischen Struktur ein Benutzer ein Metaob­ jekt auswählt.

16. Verfahren nach Anspruch 15, wobei die aktuelle Benutzer­ berechtigung auf Zugriff auf einen Aspekt (41-47) durch eine Zugangsprüffunktion (100) ermittelt wird, gekenn­ zeichnet durch folgende Schritte:

• - Behandlung von Referenzen bezüglich einer Benutzeridenti­ tät (101), einer Metaobjektidentität (102) und einer Aspektidentität (103), die als Eingangsgrößen bei einem Aufruf der Funktion definiert sind,
• - Behandlung einer Referenz bezüglich eines Software-Objek­ tes (104), welche nach einem Ergebnis fragt, welches als Ausgangsgröße bei dem Aufruf der Zugangsprüfung definiert ist,
• - Zugreifen auf Erlaubnisse in dem Aspekt unter Bezugnahme auf die Aspektidentität (103) und das Auffinden von In­ formationen über eine gültige Erlaubnis (105) auf Zugang zu dem Aspekt,
• - Zugreifen auf alle Sicherheitsaspekte (106, 70-72) durch Bezugnahme auf die Metaobjektidentität,
• - Prüfung, ob es eine Übereinstimmung gibt zwischen der zu­ vor in dem Aspekt aufgefundenen gültigen Erlaubnis und den Erlaubnissen in allen Sicherheitsaspekten (70-72), und, vorausgesetzt, daß eine Übereinstimmung (74) vorhan­ den ist, weitere Prüfung anhand der Benutzeridentität, ob es eine Übereinstimmung gibt zwischen dem Benutzer und einem Eintrag in der Benutzerliste (75, 76), welche der zuvor übereinstimmenden Erlaubnis (73, 74) entspricht,
• - Ausgabe des Ergebnisses "Gewährung" oder "Verweigerung" (107) in Abhängigkeit des Ergebnisses der Prüfung an das aufrufende Software-Objekt durch Verwendung der Objektre­ ferenz.

17. Verfahren nach Anspruch 16, wobei die aktuelle Sicher­ heit definiert wird durch den zusätzlichen Schritt der Defi­ nition einer Priorität zwischen hierarchischen Strukturen und Bestimmung anhand der Priorität, welcher Sicherheitsa­ spekt Priorität vor einem anderen Sicherheitsaspekt haben soll, wenn die genannten Sicherheitsaspekten an ein Metaob­ jekt über mindestens zwei hierarchische Strukturen übergeben (vererbt) wurden, und die genannten Sicherheitsaspekte die gleiche Erlaubnis definieren, die ein bestimmter Benutzer benötigt, um auf einen Aspekt des Metaobjekts zugreifen zu können.

18. Verfahren nach Anspruch 15, wobei als zusätzlicher Schritt eine Änderung einer Benutzerberechtigung vorgesehen ist, wenn ein Metaobjekt seine Position in einer hierarchi­ schen Struktur verändert, von einem Benutzer zu einem ande­ ren Benutzer, wobei die Benutzerberechtigung das Recht auf Zugang zu einem bestimmten Aspekt des Metaobjekts definiert.

19. Verfahren nach Anspruch 10, wobei als weiteren Schritt vorgesehen ist eine Verschiebung des genannten ersten Soft­ ware-Objekts aus einer Position in einer ersten hierarchi­ schen Struktur in eine neue Position in irgendeiner Struk­ tur, so daß die Zuordnung eines Sicherheitsaspekts, der zu­ vor über die erste hierarchischen Struktur übernommen wurde, zu dem ersten Software-Objekt aufgehoben wird, und das erste Software-Objekt mit einem Sicherheitsaspekt verbunden wird, welcher über irgendeine Struktur übernommen wird, wobei die Benutzerberechtigung, auf mindestens einen Aspekt des ersten Software-Objekts zuzugreifen, während der Zeitspanne zwi­ schen Anmeldung und Abmeldung dynamisch ist.

20. Computerprogramm-Produkt zur Verwendung in einem Com­ putersystem, welches einen Software-Code hat, der in den in­ neren Speicher des Computers in einem computer-gestützten System ladbar ist, wobei das Computerprogramm-Produkt Ein­ richtungen hat, welche den Computer veranlassen, ein erstes Software-Objekt (31), welches eine Entität der realen Welt repräsentiert, zur Verfügung zu stellen, welches erste Soft­ ware-Objekt (31) in zwei oder mehr hierarchische Strukturen (20, 21, 22) von Software-Objekten eingefügt ist, welches er­ ste Software-Objekt mindestens einen Sicherheitsaspekt (28) von einem zweiten Software-Objekt (23) und einem dritten Software-Objekt (24) übernimmt, wobei das zweite Software- Objekt (23) und das dritte Software-Objekt (24) eine höhere Position als das erste Software-Objekt (31) in einer Hierar­ chie einnehmen, und vorsehen, daß das erste Software-Objekt dem übernommenen Sicherheitsaspekt (28) zugeordnet ist, und eine aktuelle Berechtigung für einen Benutzer vorsehen, auf einen Aspekt des ersten Software-Objekt zuzugreifen, auf der Grundlage von mindestens zwei Sicherheitsaspekte, die über mindestens zwei hierarchische Strukturen übernommen werden, in Kombination mit der Benutzeridentität in dem genannten computerisierten System.

21. Computerprogramm-Produkt nach Anspruch 20, wobei der Si­ cherheitsaspekt (28, 29), der zuvor über eine hierarchische Struktur (20, 21, 22) übernommen wurde, seine Zuordnung zu dem genannten ersten Software-Objekt (31) verliert durch Löschung des genannten ersten Software-Objekts (31) in der hierarchischen Struktur (20, 21, 22), wodurch die Benutzerbe­ rechtigung auf Zugriff auf mindestens einen Aspekt des er­ sten Software-Objekts während der Zeitspanne zwischen Anmel­ dung und Abmeldung dynamisch ist.

22. Computerprogramm-Produkt nach Anspruch 20 oder 21, wobei jedes der genannten Software-Objekte als ein Metaobjekt im­ plementiert ist.

23. Computerprogramm-Produkt nach Anspruch 22, wobei eine Benutzerschnittstelle Mittel vorsieht für:
die Auswahl eines Metaobjekts (31, 61) durch Zeigen mit­ tels einer Maus auf ein Metaobjekt und durch ein rechts­ seitiges Anklicken des Objektes oder durch ähnlichen Mit­ teln zur Auswahl eines Metaobjekts, und die Anzeige einer Liste von Aspekten mittels eines Einblendmenüs oder eines ähnlichen Mittels,
die Auswahl eines Aspektes aus der Liste von Aspekten durch ein Anklicken mit der linken Maustaste oder durch ähnliche Mittel, dadurch gekennzeichnet, daß
das Metaobjekt in zwei oder mehr hierarchische Strukturen (20, 21, 22) eingeordnet wurde,
die in der Liste (62) angezeigten Aspekte diejenigen sind, welche zu der aktuellen Benutzerberechtigung pas­ sen, und daß die Benutzerberechtigung auf der Grundlage von zwei oder mehr Sicherheitsaspekten (63, 28, 29, 30) er­ mittelt wird.

24. Computerprogramm-Produkt nach Anspruch 23, da­ durch gekennzeichnet, daß die aktuelle Benutzerberechtigung auf Zugriff auf ein Metaobjekt unabhän­ gig davon ist, aus welcher hierarchischen Struktur ein Be­ nutzer ein Metaobjekt auswählt.

25. Computerprogramm-Produkt nach Anspruch 24, wobei die ak­ tuelle Benutzerberechtigung auf Zugriff auf einen Aspekt (41-47, 51-57) durch eine Zugangsprüffunktion ermittelt wird, dadurch gekennzeichnet, daß diese Funktion Einrichtungen enthält für:
die Behandlung von Referenzen bezüglich einer Benutzeri­ dentität (101), einer Metaobjektidentität (102) und einer Aspektidentität (103), die als Eingangsgrößen bei einem Aufruf der Funktion definiert sind,
die Behandlung einer Referenz bezüglich eines Software- Objektes (104), welche nach einem Ergebnis fragt, welches als Ausgangsgröße bei dem Aufruf der Zugangsprüfung defi­ niert ist,
das Zugreifen auf Erlaubnisse in dem Aspekt unter Bezug­ nahme auf die Aspektidentität (103) und das Auffinden von Informationen über eine gültige Erlaubnis (105) auf Zu­ gang zu dem Aspekt,
das Zugreifen auf alle Sicherheitsaspekte (106, 70-72) durch Bezugnahme auf die Metaobjektidentität,
die Prüfung, ob es eine Übereinstimmung gibt zwischen der zuvor in dem Aspekt aufgefundenen gültigen Erlaubnis und den Erlaubnissen in allen Sicherheitsaspekten (70-72), und, vorausgesetzt, daß mindestens eine Übereinstimmung (73, 74) vorhanden ist, die weitere Prüfung anhand der Be­ nutzeridentität, ob es eine Übereinstimmung gibt zwischen dem Benutzer und einem Eintrag in der Benutzerliste (75, 76), welche der zuvor übereinstimmenden Erlaubnis (73, 74) entspricht,
die Ausgabe des Ergebnisses "Gewährung" oder "Verweigerung" (107) in Abhängigkeit des Ergebnisses der Prüfung an das aufrufende Software-Objekt durch die Ver­ wendung der Objektreferenz.

26. Computerprogramm-Produkt nach Anspruch 25, da­ durch gekennzeichnet, daß es Software enthält zur Definition einer Priorität zwischen hierarchi­ schen Strukturen und zur Bestimmung anhand der Priorität, welcher Sicherheitsaspekt Priorität vor einem anderen Si­ cherheitsaspekt haben soll, wenn die genannten Sicherheitsa­ spekten an ein Metaobjekt über mindestens zwei hierarchische Strukturen übergeben (vererbt) wurden, und die genannten Si­ cherheitsaspekte die gleiche Erlaubnis definieren, die ein bestimmter Benutzer benötigt, um auf einen Aspekt des Meta­ objekts zugreifen zu können.

27. Computerprogramm-Produkt nach Anspruch 26 verkörpert in einem von einem Computer lesbaren Medium.