DE102016110939B3

DE102016110939B3 - Datenorganisationsverfahren und Entwicklungsumgebungssystem

Info

Publication number: DE102016110939B3
Application number: DE102016110939.8A
Authority: DE
Inventors: Torsten Nitschke; Benno Heines; Rolf Salzmann; Carsten Kolodziej; Robert von der Ahe
Original assignee: Phoenix Contact GmbH and Co KG
Current assignee: Phoenix Contact GmbH and Co KG
Priority date: 2016-06-15
Filing date: 2016-06-15
Publication date: 2017-10-05
Anticipated expiration: 2036-06-16
Also published as: US20170364355A1; US10331443B2; CN107526766A; CN107526766B

Abstract

Die Erfindung betrifft ein Datenorganisationsverfahren sowie ein Entwicklungsumgebungssystem, das zur Durchführung des Datenorganisationsverfahrens ausgebildet ist. Das erfindungsgemäße Datenorganisationsverfahren sieht vor, dass eine gespeicherte oder zu speichernde Datenmenge gemäß einer ersten Struktur organisiert wird, wobei die Datenmenge nach inhaltsbezogenen Aspekten und/oder nach zugriffsrechtlichen Aspekten in Datenteilmengen unterteilt wird, wobei neben der ersten Struktur zusätzlich eine weitere Struktur vorgesehen ist, gemäß der die Datenmenge organisiert wird, wobei die Datenmenge nach Zuständigkeitsbereichen unterteilt wird, wobei jeder Zuständigkeitsbereich wenigstens eine Datenteilmenge gemäß der ersten Struktur umfasst, wobei jede Datenteilmenge zumindest eine Dateneinheit umfasst, und wobei jedem Zuständigkeitsbereich jeweils eine zuständige Benutzermenge zugeordnet wird, wobei die Benutzermenge zumindest einen Benutzer umfasst.

Description

Die Erfindung betrifft ein Datenorganisationsverfahren sowie ein Entwicklungsumgebungssystem, das zur Durchführung des Datenorganisationsverfahrens ausgebildet ist.
Entwicklungsumgebungssysteme werden für das Bearbeiten von Entwicklungsprojekten verschiedener Art eingesetzt und können je nach Einsatzbereich verschieden ausgebildet sein. In der Regel stellen Entwicklungsumgebungssysteme dem Benutzer eine Entwicklungsumgebung mit einer Benutzerschnittstelle bzw. -oberfläche bereit und ermöglichen das Bearbeiten eines Entwicklungsprojekts sowie das Speichern der Entwicklungsprojektdaten. Aufgrund des Umfangs und der Komplexität vieler Entwicklungsprojekte ist es ferner zunehmend erforderlich und üblich geworden, dass viele Entwicklungsumgebungssysteme das Bearbeiten des Entwicklungsprojekts durch mehrere Benutzer ermöglichen. Beispiele für Entwicklungsumgebungssysteme sind Textverarbeitungssysteme, Bildbearbeitungssysteme, Desktop-Publishing-Systeme, Redaktionssysteme und Content-Management-Systeme sowie Softwareentwicklungssysteme. Somit kann es sich bei einem Entwicklungsprojekt um ein publizistisches Projekt wie ein Buch oder eine Website handeln oder auch um ein Softwareprojekt wie zum Beispiel eine Steuersoftware für eine Automatisierungsanlage. Die vorliegende Erfindung wird hauptsächlich am Beispiel eines Entwicklungsprojekts erläutert, bei dem es um das Erstellen bzw. Bearbeiten einer solchen Steuersoftware für eine Automatisierungsanlage geht. Jedoch ist die Erfindung grundsätzlich ebenso für andere Entwicklungsprojekte anwendbar.
Um z. B. eine unbeabsichtigte Aktualisierung und Referenzierung einer gemeinsamen Tabelle durch eine nicht autorisierte Person zu verhindern, wenn Software, die die Aktualisierung und Referenzierung der gemeinsamen Tabelle in Objektorientierter Sprache durchführt, von einer großen Anzahl von Entwicklern entwickelt wird, schlägt die JP H05-113877 A vor, eine Serverklasse, die den Wert der gemeinsamen Tabelle definiert, welche von mehreren Teilen der zu entwickelnden Software verwendet wird, getrennt von einer Clientklasse zu erzeugen, die sich auf den Wert bezieht. Das Zusammenstellen einer nicht autorisierten Server- oder Clientklasse in der Software, ohne dass ein vorgeschriebenes Zugriffsrechts auf die gemeinsame Tabelle besteht, wird durch die Begrenzung des Rechts des Auslesens eines Server-Headers, der die Serverklasse erzeugt, und eines Client-Headers, der die Clientklasse erzeugt, verhindert.
Die von einem Entwicklungsumgebungssystem bereitgestellte Entwicklungsumgebung für Softwareprojekte wird im Folgenden auch als Entwicklungswerkzeug oder Software-Werkzeug bezeichnet, wobei eine Entwicklungsumgebung auch mehr als ein solches Werkzeug umfassen kann. Ferner wird im Folgenden die Steuersoftware für eine Automatisierungsanlage auch als Automatisierungslösung bezeichnet. Eine Automatisierungsanlage, etwa zur Durchführung eines Fertigungsprozesses, umfasst typischer Weise wenigstens eine Steuerung, insbesondere eine Speicherprogrammierbare Steuerung (SPS), und mehrere zu steuernde Geräte, die jeweils mit Sensoren und/oder Aktoren ausgestattet sind, wobei die Steuerung und die Geräte über ein Netzwerk oder einen Bus mit einander in Kommunikationsverbindung stehen.
Innerhalb der Automatisierungstechnik wird eine SPS oder ein Gerät in der Regel mit einem Software-Werkzeug konfiguriert und/oder programmiert. Während früher verschiedene Software-Werkzeuge für verschiedene Aufgaben verwendet wurden, so können inzwischen komplette Automatisierungslösungen mit einem umfassenden Software-Werkzeug erstellt und bearbeitet werden. Zum Beispiel wurde früher die Visualisierung von Zuständen einer Steuerung an einem Anzeigepanel mit einem speziellen Software-Werkzeug für eine sogenannte Mensch-Maschinen-Schnittstelle (englisch: „human machine interface”, kurz HMI) erstellt, während die eigentliche Prozessregelung mit einem Software-Werkzeug für Programmiersprachen nach Teil 3 der Norm IEC 61131, d. h. in der zum für die vorliegende Anmeldung maßgeblichen Zeitrang gültigen Version, erzeugt und gewartet wurde. Heutiger Stand ist, dass dasselbe Software-Werkzeug für die Erstellung und Bearbeitung des HMI als auch der Prozessregelung verwendet wird und die gesamte Automatisierungslösung in einer Sammlung von Dateien oder gar einer einzigen Datei zusammengefasst abgelegt wird. Aus einer solchen Automatisierungslösung können dann mittels des Software-Werkzeugs idealer Weise gleich alle Geräte sowie die Steuerung einer Automatisierungsanlage mit Konfiguration und Programmierung versorgt werden. Hierzu wird das Software-Werkzeug vom Benutzer angewiesen, aus der projektierten Automatisierungslösung direkt von den Geräten und der Steuerung verwendbare Einstellungen und ausführbare Programmdateien zu erzeugen und an diese zu verteilen.
Beispielhaft ist ein solches Szenario, bei dem mittels eines Software-Werkzeugs eine Automatisierungslösung erstellt und bearbeitet sowie in Konfigurations- und ausführbare Daten übersetzt wird, die dann an die einzelnen Geräte verteilt werden, schematisch in der 1 dargestellt. Es versteht sich, dass anstelle eines der drei in 1 dargestellten Geräte A, B und C oder ergänzend dazu auch eine hier nicht dargestellte Steuerung vorgesehen sein könnte.
Es ist also üblich geworden, dass in einer Automatisierungslösung und mit demselben Software-Werkzeug mehrere Fachaufgaben bearbeitet und gewartet werden. Hierzu verwenden Benutzer aus unterschiedlichen Fachbereichen bzw. mit unterschiedlichen fachlichen Schwerpunkten dasselbe Software-Werkzeug und arbeiten an demselben Satz von Dateien oder derselben Datei, durch die eine Automatisierungslösung in Gänze beschrieben wird. Solche Arbeiten geschehen sequenziell oder zeitlich überlappend.
Traditionell werden Automatisierungslösungen von Software-Werkzeugen hierarchisch strukturiert gemäß dem von der Norm IEC 61131 Teil 3 definierten Architekturmodell dargestellt. An dieser Form der hierarchischen Anordnung orientieren sich auch andere Informationsmodelle, wie zum Beispiel dasjenige der OPC Foundation (Open Platform Communications) für die Repräsentation von Information aus Speicherprogrammierbaren Steuerungen gemäß der OPC Unified Architecture (OPC UA).
Die 2 zeigt ein Schema einer typischen Benutzeroberfläche einer Entwicklungsumgebung bzw. eines Software-Werkzeugs. Typischerweise stellen Software-Werkzeuge die Gegenstände der Automatisierungslösung in einem Auswahlbereich ihrer Benutzeroberfläche als auf- und zuklappbaren Baum nach der Hierarchie des Architekturmodells gemäß IEC 61131 Teil 3 dar. Eine Automatisierungslösung enthält oder referenziert Bibliotheken mit Funktionen und Funktionsbausteinen, welche in der Automatisierungslösung verwendet werden. Auf gleicher Hierarchieebene wie die Bibliotheken werden Datentypen definiert, wobei zum Zwecke der Strukturierung mehrere Datentypen auf einem Arbeitsblatt zusammengefasst sein können. Im Beispiel existieren die Arbeitsblätter „WeldingTypes” und „CoatingTypes” für die Definition von lösungsspezifischen Datentypen. Auf gleicher Ebene mit der Zusammenfassung der Datentypen werden ferner Programmorganisationseinheiten (POEs) zusammenfassend erklärt. Im Beispiel befinden sich unterhalb des Knotens „Logische POEs” die folgenden Einheiten: Funktionsblock „FBfuzzy”, Programm „ProgramShort”, Programm „ProgamLong” und Funktion „Fexact”. Jede POE ist weiter strukturiert zum Beispiel in Arbeitsblättern mit lokalen Variablen und Arbeitsblätter mit Quelltext zur Implementierung des Programms, der Funktion oder des Blocks. Auf der Ebene der Zusammenfassung aller Bibliotheken, Datentypen und logischen POEs befindet sich auch die Zusammenfassung der Hardware, welche in Konfigurationen unterteilt wird. Im Beispiel existieren unterhalb des Knotens „Hardware” die Konfigurationen „ControllerA” und „ControllerB”, die jeweils aus einer eigenen Ressource „Processor1”, globalen Variablen, und einem IO-Modul bestehen. Beispielhaft sind die Ressourcen namens „Processor1” jeweils noch einmal in Ausführungseinheiten (Tasks) namens „Fast und „Slow” unterteilt, denen jeweils eine Programminstanz namens „ProgShort” und „ProgLong” zugeordnet ist. Programminstanzen sind zum Beispiel Instanzen der unterhalb der logischen POEs erklärten Programme.
An dem Beispiel ist ersichtlich, dass diese Strukturierung einer Automatisierungslösung an dem Architekturmodell für die Programmierung gemäß IEC 61131 Teil 3 ausgerichtet ist. Durch übliche Software-Werkzeuge für Automatisierungslösungen wie zum Beispiel MULTIPROG Version 5.50, PC WorX Revision 6.10 oder CodeSys V3.5 werden einzelne Automatisierungslösungen in dieser Strukturierung abgespeichert, das heißt, auch die innere Struktur der erzeugten Datei oder die Organisation der Dateisammlung in Dateiordnern folgt diesem Architekturmodell der IEC 61131 Teil 3.
Die genannten Software-Werkzeuge ermöglichen in der Regel auch, an den Knoten des beispielhaft in 2 dargestellten Baumes der Automatisierungslösung Rechte für die Bearbeitung durch verschiedene Benutzer einzustellen. Wie viele verschiedene Benutzerarten eingestellt werden können, hängt von dem jeweiligen Software-Werkzeug ab. In der Regel wirken sich die Rechte auf die untergeordneten Knoten aus, das heißt, sie werden vererbt, wobei die Rangfolge im Baum dem Architekturmodell gemäß IEC 61131 Teil 3 folgt.
Ein Beispiel für die Unterscheidung von zwei verschiedenen Arten von Benutzergruppen gibt das Software-Werkzeug MULTIPROG in der Version 5.50: Eine Gruppe von Benutzern kennt ein initial für das Projekt vergebenes Passwort, eine andere Gruppe von Benutzern hingegen kennt es nicht. Gibt ein Benutzer das Passwort nach dem Öffnen der Automatisierungslösung korrekt ein, so kann die Lösung vollumfänglich bearbeitet werden, ansonsten kann sie nur nach den Rechten bearbeitet werden, welche unter Angabe des Passwortes ehemals an den Knoten eingestellt wurden. Bei solchen Implementierungen nach dem Stand der Technik wird der Bearbeitungsschutz durch das Software-Werkzeug durchgesetzt.
Ein Benutzer ohne Kenntnis des Passwortes könnte jedoch mit einem anderen Software-Werkzeug, zum Beispiel einem allgemein auf binären Daten arbeitenden Editor wie einem sogenannten Hex-Editor, über die eingestellten Grenzen hinweg an den abgespeicherten Dateien der Automatisierungslösung manipulieren. Dabei können eventuell vorhandene Prüfsummen so manipuliert werden, dass das eigentliche Software-Werkzeug nur dann in der Lage ist, eine unrechtmäßige Manipulation zu erkennen, wenn das Projektpasswort eingegeben wurde oder wenn eine neu errechnete Prüfsumme mit einer vormals anderswo außerhalb der Automatisierungslösung notierten Prüfsumme verglichen wird. Letzterer Vergleich ist beispielsweise für Automatisierungslösungen in Verwendung, welche nach den Richtlinien für die funktionale Sicherheit (Safety) zertifiziert worden sind.
Ein anderes Beispiel liefert das Software-Werkzeug CodeSys V3.5, bei dem in Form einer Rechtematrix je Knoten des Baumes der Automatisierungslösung festgelegt werden kann, welcher Benutzer welche Aktion im Engineering oder an den Objekten des jeweiligen Teilbaumes vornehmen kann.
Eine Besonderheit stellt zudem die sogenannte Adresstabelle oder Verknüpfungstabelle (im Folgenden auch kurz VKT genannt) innerhalb einer Automatisierungslösung dar. So erlauben es gängige Software-Werkzeuge zur Erstellung und Pflege von Automatisierungslösungen, Variablen mit Ein- und Ausgängen von POEs sowie Ein- und Ausgängen von (physikalischen) IO-Modulen zu verknüpfen und diese Verknüpfungen auch im Zuge der Entwicklung wieder zu verändern. Nun können diese Verknüpfungen nicht immer eindeutig einem Knoten des Baumes innerhalb der Automatisierungslösung zugeordnet werden. Vielmehr kommt es vor oder ist es erforderlich, eine Variable mit mehreren Eingängen oder Ausgängen gleichzeitig zu verknüpfen. Die Verwaltung solcher Verknüpfungen erfolgt daher über alle hierarchischen Ebenen der Automatisierungslösung hinweg. Üblicher Weise werden die Verknüpfungen in der erwähnten Adress- oder Verknüpfungstabelle einer Automatisierungslösung gepflegt, die zum Beispiel die Form einer Matrix hat und mangels Zuordnung bzw. Zuordenbarkeit lösungsübergreifend abgespeichert wird.
Oftmals ist es beim Bearbeiten einer Automatisierungslösung mit einem Software-Werkzeug gewünscht oder erforderlich, dass beim Speichern der aktuellen Fassung die vorherige Fassung, etwa zu Dokumentationszwecken, erhalten bleibt und nicht einfach überschrieben wird. Aus dem Zuständigkeitsbereich der herkömmlichen Informationstechnologie sind Versionierungswerkzeuge bzw. Versionsverwaltungswerkzeuge zur Dokumentation und zum Nachvollziehen von verschiedenen Revisionen desselben Programmquelltextes beziehungsweise einer strukturierten Sammlung von Quelltexten bekannt. Allgemein verwalten Versionsverwaltungswerkzeuge Revisionen von Dateien beliebigen Inhaltes, welche in einer Hierarchie von Dateiordnern organisiert sind. Als Beispiel seien die Versionsverwaltungswerkzeuge Subversion (SVN) und GIT genannt. Sie verwalten üblicherweise Programmquelltexte in Form von Textdateien und können auch mit beliebigen Dateiinhalten wie zum Beispiel binären Daten umgehen. Versionsverwaltungswerkzeuge können in der Regel mehrere Ablagen (englisch: repositories) von Sammlungen von Dateien verwalten.
Von dem Software-Werkzeug CodeSys V3.5 ist bekannt, dass es zum Beispiel mit dem Versionsverwaltungswerkzeug Subversion direkt interagieren kann und dort die Automatisierungslösung solchermaßen in Dateiordnern hinterlegt, wie es das Architekturmodell gemäß IEC 61131 Teil 3 nahelegt.
Das Versionskontrollsystem GIT implementiert ferner einen kryptographisch starken Integritätsschutz in Form eines kryptographischen Hashwertes jeweils für

a) jede Version eines einzelnen versionierten Objektes,
b) die Menge von Objekten samt ihren Metadaten wie Objekttyp und -name, die zu einem bestimmten Versionsstand gehören, und
c) je Versionsstand die zugehörige Änderungsnotiz (commit message), den Hashwert der Menge von Objekten, die zum Versionsstand gehören, den Hashwert zum vorherigen Versionsstand und weitere Information wie den Namen des Autors.

Durch die Einbeziehung des Hashwertes des vorherigen Versionsstandes bei der Hashwertberechnung zu einem neuen Versionsstand entsteht ein Integritätsschutz für die Versionshistorie. Weiter erlaubt das Versionskontrollsystem GIT auch die Erstellung von kryptographisch starken digitalen Signaturen zu Hashwerten von Versionsständen, wodurch ein Manipulationsschutz für die jeweilige Version samt ihrer Versionshistorie entsteht und welche Signaturen GIT verifizieren kann. Allerdings besteht hierbei der Nachteil, dass einer immer alles unterzeichnen muss.
So stehen bekanntermaßen kryptographische Mittel zum Schutz von digitalen Daten vor Manipulation in Form von Signaturen zur Verfügung. Digitale Daten werden demnach signiert, wobei ein Zeichnungsberechtigter zu beliebigen Daten eine Signatur erstellen und unter Verwendung bestimmter Mittel eine andere Partei zu einem späteren Zeitpunkt prüfen kann, ob die Daten noch so gestaltet sind, wie sie zum Zeitpunkt der Signaturerstellung waren. Letzteres wird Authentifizierung der Daten genannt. Wenn hohe Verarbeitungsgeschwindigkeit notwendig ist, dann ist in der Regel die Verwendung von symmetrischer Kryptographie von Vorteil, welche beim Signierenden und beim Authentifizierenden denselben Schlüssel, der auch geteiltes Geheimnis genannt wird, verwendet. Alle Teilnehmer an einem authentifizierbaren Datenaustausch müssen somit dasselbe Geheimnis kennen. Zwar ist die symmetrische Kryptographie mit geringem Rechenaufwand und deshalb mit hoher Verarbeitungsgeschwindigkeit durchführbar. Ein Problem existiert jedoch bei der Geheimhaltung des Geheimnisses. Je mehr Teilnehmern es bekannt sein muss, desto höher ist das Risiko, dass das Geheimnis Unbefugten bekannt wird. Das Verteilen eines initialen oder neuen Geheimnisses ist ein zusätzliches Problem. Es sind viele Lösungsmöglichkeiten bekannt. Sie sind hier im Rahmen der Erfindung nicht weiter relevant, außer ihrer gemeinsamen Eigenschaft, dass sie organisatorisch und/oder vom Rechenbedarf her aufwändig sind. Bei mehreren verschiedenen Benutzern sind Signaturen basierend auf asymmetrischer Kryptographie von Vorteil, die mit einem Schlüsselpaar erstellt und geprüft werden. Ein privater Schlüssel dient dem Erstellen einer Signatur und ein zugehöriger öffentlicher Schlüssel dient dem Prüfen einer Signatur. Zum Zwecke der Wahrung der Beweiskraft sollte von einem privaten Schlüssel Kopien lediglich in so geringer Anzahl wie möglich vorhanden sein, damit nur die jeweils ermächtigte Person gültige Signaturen erzeugen kann. Üblicherweise ist jeder zeichnungsberechtigten Person mindestens ein eigenes Schlüsselpaar zugeordnet und jede Person hält ihre privaten Schlüssel für sich, macht sie also keiner anderen Person zugänglich. Bei der Interaktion zwischen Personen haben sich asymmetrische Signaturen durchgesetzt und es existieren Lösungen, bei denen der jeweilige private Schlüssel in einem kleinen Gerät oder Elektronikbauteil sicher verwahrt wird, so dass er quasi nicht extrahierbar oder kopierbar, jedoch für die Erstellung von Signaturen anwendbar ist und damit in gewisser Sichtweise ähnlich zu Schlüsseln für Sicherheitstürschlösser funktioniert. Zur effizienten Verteilung und Prüfbarkeit von öffentlichen Schlüsseln sind sogenannte Schlüsselinfrastrukturen (zu Englisch „Public Key Infrastructures”, kurz PKIs) etabliert. Besondere Bedeutung haben die im Zusammenhang mit Schlüsselinfrastrukturen verwendeten Zertifikate. In ihnen können Identitäten von Personen bestätigt werden als auch Befugnisse und andere Eigenschaften der Personen benannt werden. Eine nützliche Variante der Erklärung solcher Befugnisse und Eigenschaften sind Attributzertifikate. Für die Langzeitprüfbarkeit von digitalen Signaturen kann z. B. ein Format definiert sein, das eine digitale Signatur mit einem Zeitstempel und optional anderen Nachweisen kombiniert, dass die Signatur zu einem bestimmten Zeitpunkt bereits existierte.
Auch für die effiziente Langzeitarchivierung von digitalen Signaturen können z. B. zu vielen Daten effizient Signaturen erstellt werden, indem ein Baum von kryptographisch starken Prüfsummen aufgebaut wird und nur die Wurzel signiert wird. Hierbei enthalten die Blattknoten des Baumes kryptographisch starke Prüfsummen einzelner Daten (oder Dateien) und bei allen anderen Knoten gilt, dass sie die kryptographisch starke Prüfsumme aller in definierter Form hintereinander codierten Prüfsummen der direkt untergeordneten Knoten sind. Eine einfache Form eines solchen Baumes hat einen Wurzelknoten und eine beliebige Anzahl von Blattknoten aber keine dazwischen gelagerten Knoten. Diese Form erlaubt die effiziente Signatur einer Menge von Daten (oder Dateien), jedoch ohne vorherige Gruppenbildung.
Wie eingangs erwähnt, ist es möglich, dass mehrere Personen bzw. Benutzer zusammen ein Entwicklungsprojekt wie etwa eine Automatisierungslösung bearbeiten. Diesbezüglich ist in der 3 schematisch dargestellt, wie zum Beispiel Software-Werkzeuge wie MULTIPROG Version 5.50 und CodeSys V3.5 innerhalb größerer Organisationen heutzutage dazu verwendet werden, dass verschiedene Personen jeweils eine eigene Arbeitskopie (Arbeitskopie 1, 2, bis m) derselben Automatisierungslösung lokal auf ihrem Arbeitsplatzrechner (System R.1, R.2 bis R.m) bearbeiten. Das jeweilige Ergebnis wird in der Regel in einer zentralen Ablage, zum Beispiel einem Server (System Z), hinterlegt, so dass alle Personen der Organisation aus der zentralen Ablage die jeweils aktuelle Fassung der Automatisierungslösung abholen und dort auch hinterlegen können. Zu diesem Zwecke sind die Systeme (System Z, R.1, R.2 bis R.m) zumindest zeitweise über ein bei 3 aus Übersichtlichkeitsgründen nicht weiter dargestelltes Netzwerk miteinander verbunden. Der Server (System Z) kann dabei einen zentralen Speicherort für Ordner und Dateien mit oder ohne Versionsverwaltung bereitstellen.
Manchmal erfolgt eine Kollaboration bei der Bearbeitung von Automatisierungslösungen auch ohne gemeinsame zentrale Ablage. Hierbei wird die jeweils aktuelle Version der Automatisierungslösung zwischen den Systemen der Personen direkt übertragen, wobei die beteiligten Personen sich zu dem Zweck idealerweise auf eine Bearbeitungsreihenfolge einigen.
Sowohl mit als auch ohne zentrale Ablage entstehen häufig zwei oder mehrere verschiedene neue Versionen einer Automatisierungslösung, die von derselben oder gar verschiedenen ursprünglichen Versionen abstammen. Wegen der herkömmlichen Speicherform der Automatisierungslösung, zum Beispiel in Form von Dateiordnern und Unterordnern nach dem Architekturmodell gemäß IEC 61131 Teil 3, entstehen damit häufig Konflikte, so dass vorgenommene Änderungen durch späteres Überschreiben ungewollt wieder rückgängig gemacht werden und damit Arbeit verloren geht oder zusätzlicher Arbeitsaufwand zum Vereinigen (englisch: merging) zweier konkurrierend erstellter neuer Versionen entsteht.
Ein Beispiel für ein ungewolltes Überschreiben einer vorherigen Änderung ist in 4 gezeigt, wo ein Schweißspezialist und ein Lackierspezialist konkurrierend das Programm „ProgramShort” der bereits mit 2 vorgestellten Automatisierungslösung modifizieren, wobei am Ende der letzte Kopiervorgang zum Zeitpunkt t7 die Änderung des Lackierspezialisten auf der zentralen Ablage (System Z) als Version 3 speichert, jedoch somit die mit dem Kopiervorgang zum Zeitpunkt t6 als Version 2 gespeicherte Änderung des Schweißspezialisten im Programm „ProgramShort” wieder rückgängig macht.
Die herkömmliche Lösung für den im Beispiel gezeigten Konflikt ist, dass der Lackierspezialist die Änderungen des Schweißspezialisten in seine bereits geänderte Version 3 von „ProgramShort” integriert. Allerdings würde dann die von dem Lackierspezialisten gespeicherte Version 3 auch Änderungen des Schweißspezialisten enthalten, für die der Lackierspezialist eventuell gar nicht kompetent war.
Besonders häufig entstehen derartige Konflikte im Zusammenhang mit der Verknüpfungstabelle (VKT), welche üblicherweise an zentraler Stelle der Automatisierungslösung verortet ist und welche insbesondere bei Programmänderungen häufig mit geändert werden muss.
Vor allem aufgrund solcher übergreifenden Anteile einer Automatisierungslösung lassen sich Zugriffsregeln in einer zentralen Ablage allenfalls schwer durchsetzen.
Besonders offensichtlich wird die Relevanz der Nichterkennbarkeit von Kompetenzüberschreitungen wie in dem beispielhaft diskutierten Fall, wenn ein Safety-Spezialist Änderungen vornimmt, die durch einen Nicht-Safety-Spezialisten nachträglich mit neuen Änderungen integriert werden müssen. Bisher sind deshalb Automatisierungslösungen mit Safety-Anteilen strikt von Nicht-Safety-Lösungen getrennt worden.
Ein weiteres Beispiel der Kollaboration bei der Bearbeitung von Automatisierungslösungen gibt die DE 11 2013 007 160 T6 . Das dort vorgestellte Entwicklungsumgebungssystem ist schematisch in der 5 dargestellt. Dabei ist das Software-Werkzeug in einen Client-Anteil und einen Server-Anteil aufgeteilt und wird verteilt auf den Systemen (System Z, System R.1 bis R.m) betrieben. Auf den Arbeitsplatzrechnern (System R.1 bis R.m) läuft nur der Client-Anteil, während je ein Server-Anteil pro Arbeitsplatzrechner auf dem zentralen System (System Z) instanziiert und betrieben wird, sobald das Software-Werkzeug auf einem Arbeitsplatzrechner aktiviert wird. Während der Client-Anteil von geringem Umfang ist und im Wesentlichen zwei Aufgaben wahrnimmt, wird die Programmlogik des Software-Werkzeuges auf dem zentralen System ausgeführt. Die zwei Aufgaben des Client-Anteils auf den Arbeitsplatzrechnern sind erstens die Interaktion mit dem Benutzer zum Beispiel in Form von Darstellungen und üblichen Bedienelementen von üblichen grafischen Benutzeroberflächen und zweitens die Vermittlung der Kommunikation zwischen einer oder mehreren Speicherprogrammierbaren Steuerungen (Gerät G.1 bis G.m), welche vom Arbeitsplatzrechner aus erreicht werden können, und dem Server-Anteil des Software-Werkzeuges. Bei dieser Art der Kollaboration ist besonders, dass Arbeitskopien der Automatisierungslösung nur auf dem zentralen System gehalten werden, nicht auf den Arbeitsplatzrechnern. Sogar die aus der Automatisierungslösung erzeugbaren Konfigurationen und ausführbaren Dateien werden auf dem zentralen System erzeugt und erst nach Erzeugung zum Client-Anteil übertragen, der sie zu den durch den Client-Anteil erreichbaren Steuerungen (Gerät G.1 bis G.m) weiterreicht. Die gesamte Verwaltung und Durchsetzung von Zugriffsrechten geschieht auf dem zentralen System. Diese Art von Entwicklungsumgebungssystem entspricht weitgehend einem Schema, das aus dem „Cloud Computing” als „Software as a Service” (SaaS) bekannt ist. Nachteilig daran ist neben der Komplexität vor allem, dass eine Automatisierungslösung am Arbeitsplatzrechner (System R.1 bis R.m) nur bei bestehender Verbindung zum zentralen System (System Z) bearbeitet werden kann.
Bei der bekannten Art der Strukturierung und Speicherung von Automatisierungslösungen in Form der Hierarchie nach dem Architekturmodell gemäß IEC 61131 Teil 3, unabhängig davon ob in einer Datei mit innerer Struktur oder in Form einer Sammlung von Dateien mit einer Dateiordnerstruktur, wie sie bei herkömmlichen Software-Werkzeugen für die Bearbeitung von Automatisierungslösungen erfolgt, besteht grundsätzlich das Problem, dass mehrere Benutzer, auch wenn sie aus verschiedenen Fachbereichen kommen, oftmals dieselben Teilbäume dieser Hierarchie bearbeiten müssen, obwohl sie eigentlich an getrennten Aufgaben arbeiten, die ansonsten wenig Berührungspunkte haben.
Dies bringt eine Reihe weiterer Probleme und Konflikte mit sich, von denen mehrere oben bereits erwähnt wurden.
Insbesondere ist es bei vielen Gegenständen der Automatisierungslösung, wie einzelnen POEs, POE-Instanzen oder der Verknüpfungstabelle, nicht möglich, einem Benutzer eine klare Eigentümerschaft und Verantwortung dafür zuzuordnen. Ohne solch eine Zuordenbarkeit fehlt jedoch auch die Möglichkeit, die Integrität (Daten dürfen nicht unbemerkt verändert werden, alle Änderungen müssen nachvollziehbar sein) und die Authentizität (Echtheit, Überprüfbarkeit und Vertrauenswürdigkeit) solcher Bestandteile der Automatisierungslösung und letztlich der Automatisierungslösung im Ganzen gewährleisten bzw. verifizieren zu können.
Die Aufgabe der vorliegenden Erfindung besteht somit darin, die Konfliktmöglichkeiten zu reduzieren, die bisher bei der Bearbeitung von Entwicklungsprojekten durch mehrere Personen mittels von Entwicklungsumgebungssystemen bereitgestellten Entwicklungsumgebungen auftreten.
Eine mit der Erfindung in zweckmäßiger Ausführung anzugehende Problematik kann hierbei darin gesehen werden, bei der Bearbeitung von Entwicklungsprojekten durch mehrere Personen mittels von Entwicklungsumgebungssystemen bereitgestellten Entwicklungsumgebungen Zuständigkeitsverletzungen zuverlässig erkennen zu können.
Eine mit der Erfindung in vorteilhafter Ausgestaltung anzugehende Problematik kann hierbei darin gesehen werden, bei der Bearbeitung von Entwicklungsprojekten, insbesondere durch mehrere Personen, mittels von Entwicklungsumgebungssystemen bereitgestellten Entwicklungsumgebungen unzulässige Manipulationen an den Entwicklungsprojektdaten zuverlässig erkennen und orten zu können, selbst wenn die Manipulationen an den Entwicklungsprojektdaten außerhalb des Entwicklungsumgebungssystems vorgenommen wurden.
Eine mit der Erfindung in vorteilhafter Ausgestaltung anzugehende Problematik kann hierbei darin gesehen werden, bei der Bearbeitung von Entwicklungsprojekten, insbesondere durch mehrere Personen, mittels von Entwicklungsumgebungssystemen bereitgestellten Entwicklungsumgebungen eine Möglichkeit zu schaffen, dass die Authentizität der Entwicklungsprojektdaten insgesamt und/oder die Authentizität einzelner Teile der Entwicklungsprojektdaten zuverlässig verifizierbar ist.
Eine mit der Erfindung in vorteilhafter Ausgestaltung anzugehende Problematik kann hierbei darin gesehen werden, dass das erwähnte Erkennen von Zuständigkeitsverletzungen und/oder von unzulässigen Manipulationen und/oder das Verifizieren der Authentizität ohne Kenntnis eines Geheimnisses möglich sein soll, damit Geheimnisse nicht geteilt werden müssen.
Zur Lösung der Aufgabe schlägt die Erfindung insbesondere ein Datenorganisationsverfahren mit den Merkmalen des unabhängigen Patentanspruchs 1 sowie ein Entwicklungsumgebungssystem mit den Merkmalen des unabhängigen Patentanspruchs 24 vor. Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Datenorganisationsverfahrens und Entwicklungsumgebungssystems sind in den jeweiligen abhängigen Patentansprüchen angegeben. Die zu dem Datenorganisationsverfahren angegebenen Merkmale und Vorteile gelten sinngemäß auch für das Entwicklungsumgebungssystem.
Vorgeschlagen wird demnach ein Datenorganisationsverfahren, bei dem eine gespeicherte oder zu speichernde Datenmenge gemäß einer ersten Struktur organisiert wird, wobei die Datenmenge nach inhaltsbezogenen Aspekten und/oder nach zugriffsrechtlichen Aspekten in Datenteilmengen unterteilt wird, wobei neben der ersten Struktur zusätzlich eine weitere Struktur vorgesehen ist, gemäß der die Datenmenge organisiert wird, wobei die Datenmenge nach Zuständigkeitsbereichen unterteilt wird. Dabei umfasst jeder Zuständigkeitsbereich wenigstens eine Datenteilmenge gemäß der ersten Struktur, und jede Datenteilmenge umfasst zumindest eine Dateneinheit. Ferner wird jedem Zuständigkeitsbereich jeweils eine zuständige Benutzermenge zugeordnet, wobei die Benutzermenge zumindest einen Benutzer umfasst.
Demnach ist der bzw. jeder zu der Benutzermenge gehörende Benutzer dem Zuständigkeitsbereich zugeordnet, dem auch die Benutzermenge zugeordnet ist. Die einem Zuständigkeitsbereich zugeordnete Benutzermenge wird bei der Beschreibung des Ausführungsbeispiels auch als Eigentümergruppe bezeichnet.
Eine weitere Ausbildung des Verfahrens sieht vor, dass die Datenmenge Entwicklungsprojektdaten, bevorzugt Daten eines Softwareentwicklungsprojekts und insbesondere Programmcode und/oder Konfigurationsdaten und/oder Parametrierungsdaten für eine Automatisierungsanlage, enthält.
Somit kann es sich bei der ersten Struktur insbesondere um die Hierarchie des Architekturmodells gemäß IEC 61131 Teil 3 handeln, nach welcher insbesondere die Entwicklungsprojektdaten unterteilt bzw. organisiert werden.
Vorzugsweise ist bei dem Verfahren vorgesehen, dass eine bestimmte Dateneinheit nur von einem bestimmten Zuständigkeitsbereich umfasst wird, und/oder dass wenigstens ein Benutzer von mehreren Benutzermengen umfasst wird. Demnach gibt es hinsichtlich solcher Dateneinheiten keine Überschneidung von Zuständigkeiten. Es kann jedoch Benutzer geben, die zu mehreren Benutzermengen gehören und somit mehreren Zuständigkeitsbereichen zugeordnet sind. Ein solcher Benutzer wird nachfolgend auch als Diplomat bezeichnet.
Ein solches Datenorganisationsverfahren und die dabei vorgesehene zusätzliche Unterteilung der gespeicherten oder zu speichernden Datenmenge nach Zuständigkeitsbereichen gemäß einer weiteren Struktur erlaubt bereits eine deutliche Reduzierung der Konfliktmöglichkeiten bei der Bearbeitung von Entwicklungsprojekten durch mehrere Personen.
Eine Weiterbildung des Verfahrens sieht vor, dass gemäß der weiteren Struktur zusätzlich ein Hauptzuständigkeitsbereich bereitgestellt und dieser jedem Zuständigkeitsbereich übergeordnet wird, so dass der Hauptzuständigkeitsbereich indirekt alle von den Zuständigkeitsbereichen umfassten Datenteilmengen umfasst. Dabei umfasst der Hauptzuständigkeitsbereich zusätzlich aber auch jede Datenteilmenge der Datenmenge direkt, die von keinem anderen Zuständigkeitsbereich umfasst wird. Jede Datenteilmenge umfasst dabei zumindest eine Dateneinheit, und dem Hauptzuständigkeitsbereich wird eine zuständige Hauptbenutzermenge zugeordnet, die zumindest einen Benutzer umfasst. Demnach ist jeder zur Hauptbenutzermenge gehörende Benutzer dem Hauptzuständigkeitsbereich zugeordnet und sozusagen ein Hauptbenutzer, wobei ein Hauptbenutzer somit direkt oder indirekt die Zuständigkeit für jede Datenteilmenge bzw. für die gesamte Datenmenge besitzt. Die dem Hauptzuständigkeitsbereich zugeordnete Hauptbenutzermenge wird bei der Beschreibung des Ausführungsbeispiels auch als Haupteigentümergruppe bezeichnet.
Eine andere Weiterbildung des Verfahrens sieht vor, dass dem Hauptzuständigkeitsbereich wenigstens eine erste Beschreibungsinformation zugeordnet wird, wobei die erste Beschreibungsinformation eine Identifikationsinformation des Hauptzuständigkeitsbereichs und/oder eine Identifikationsinformation der zuständigen Hauptbenutzermenge umfasst. Alternativ oder ergänzend ist vorgesehen, dass jedem Zuständigkeitsbereich jeweils wenigstens eine zweite Beschreibungsinformation zugeordnet wird, wobei die zweite Beschreibungsinformation eine Identifikationsinformation des Zuständigkeitsbereichs, eine Identifikationsinformation des Hauptzuständigkeitsbereichs und/oder eine Identifikationsinformation der zuständigen Benutzermenge umfasst.
Bei den genannten Identifikationsinformationen kann es sich zum Beispiel um eine eindeutige ID oder einen Namen für den Hauptzuständigkeitsbereich, die Hauptbenutzermenge, einen Zuständigkeitsbereich oder eine Benutzermenge handeln. Diese Informationen können beispielsweise in einer Beschreibungsdatei enthalten sein, die dem jeweiligen Bereich zugeordnet ist.
Eine andere Weiterbildung des Verfahrens sieht vor, dass wenigstens eine Verknüpfung zwischen Dateneinheiten bereitgestellt wird, wobei zu der Verknüpfung eine Verknüpfungsinformation erzeugt wird, die eine Identifikationsinformation der Verknüpfung, eine Identifikationsinformation des Hauptzuständigkeitsbereichs und/oder eine Identifikationsinformation jedes an der Verknüpfung beteiligten Zuständigkeitsbereichs sowie insbesondere eine Identifikationsinformation und/oder Zeigerinformation zu jeder an der Verknüpfung beteiligten Dateneinheit umfasst.
Dabei kann eine Zeigerinformation zum Beispiel ein Verweis bzw. eine Pfadangabe zum Speicherort der jeweiligen Dateneinheit sein. Im Falle einer Steuersoftware bzw. einer Automatisierungslösung, die im Rahmen eines Entwicklungsprojekts erstellt und/oder bearbeitet werden soll, können die zu verknüpfenden Dateneinheiten zum Beispiel Variablen sein, die mit Ein- und Ausgängen von POEs oder IO-Modulen zu verknüpfen verknüpft werden, wobei die Verknüpfungsinformation zum Beispiel in einer Verknüpfungstabelle vermerkt wird. In der Regel umfasst eine Automatisierungslösung eine Vielzahl solcher Verknüpfungen und entsprechend viele Verknüpfungsinformationen gilt es zu verwalten. Derartige Verknüpfungsinformationen können gemäß der Erfindung auf verschiedene Weise erzeugt und verteilt bzw. zusammengefasst werden, insbesondere in Abhängigkeit davon, ob eine Verknüpfung zwischen Dateneinheiten aus dem gleichen Zuständigkeitsbereich oder zwischen Dateneinheiten aus unterschiedlichen Zuständigkeitsbereichen besteht.
Diesbezüglich sieht eine Ausbildung des Verfahrens vor, dass die Verknüpfungsinformation gemäß einer ersten Variante erzeugt wird, wobei jede Verknüpfungsinformation dem Hauptzuständigkeitsbereich zugeordnet wird und nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist.
Ferner sieht eine weitere Ausbildung des Verfahrens vor, dass die Verknüpfungsinformation gemäß einer zweiten Variante erzeugt wird, wobei die Verknüpfungsinformation

a) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten nur von dem Hauptzuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
b) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von dem Hauptzuständigkeitsbereich und einem weiteren Zuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
c) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von unterschiedlichen Zuständigkeitsbereichen umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
d) einem Zuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten von diesem Zuständigkeitsbereich umfasst werden, wobei die diesem Zuständigkeitsbereich zugeordnete Benutzermenge für eine solche Verknüpfungsinformation zuständig ist.

Ferner sieht eine weitere Ausbildung des Verfahrens vor, dass die Verknüpfungsinformation gemäß einer dritten Variante erzeugt wird, wobei die Verknüpfungsinformation

a) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten nur von dem Hauptzuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
b) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von dem Hauptzuständigkeitsbereich und einem weiteren Zuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
c) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von unterschiedlichen Zuständigkeitsbereichen umfasst werden, wobei die Hauptbenutzermenge oder eine Benutzerschnittmenge aus den diesen Zuständigkeitsbereichen jeweils zugeordneten Benutzermengen für eine solche Verknüpfungsinformation zuständig ist, oder
d) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten von nur einem Zuständigkeitsbereich umfasst werden, wobei die Hauptbenutzermenge oder die diesem Zuständigkeitsbereich zugeordnete Benutzermenge für eine solche Verknüpfungsinformation zuständig ist.

Ferner sieht eine weitere Ausbildung des Verfahrens vor, dass die Verknüpfungsinformation gemäß einer vierten Variante erzeugt wird, wobei die Verknüpfungsinformation

a) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten nur von dem Hauptzuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
b) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von dem Hauptzuständigkeitsbereich und einem weiteren Zuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder
c) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von unterschiedlichen Zuständigkeitsbereichen umfasst werden, wobei die Hauptbenutzermenge oder eine Benutzerschnittmenge aus den diesen Zuständigkeitsbereichen jeweils zugeordneten Benutzermengen für eine solche Verknüpfungsinformation zuständig ist, oder
d) einem Zuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten von diesem Zuständigkeitsbereich umfasst werden, wobei die diesem Zuständigkeitsbereich zugeordnete Benutzermenge für eine solche Verknüpfungsinformation zuständig ist.

Eine andere Weiterbildung des Verfahrens sieht vor, dass jeweils eine Prüfinformation, insbesondere eine Prüfsumme wie beispielsweise ein sogenannter Hashwert, ermittelt wird

– für wenigstens eine dem Hauptzuständigkeitsbereich zugeordnete erste Beschreibungsinformation und/oder
– bezüglich jedes Zuständigkeitsbereichs für jeweils wenigstens eine dem jeweiligen Zuständigkeitsbereich zugeordnete zweite Beschreibungsinformation und/oder
– für im Wesentlichen jede von dem Hauptzuständigkeitsbereich direkt umfasste Dateneinheit und/oder
– für jede dem Hauptzuständigkeitsbereich zugeordnete Verknüpfungsinformation gemäß der ersten oder zweiten Variante,

– für im Wesentlichen jede von einem Zuständigkeitsbereich umfasste Dateneinheit und/oder
– für jede einem Zuständigkeitsbereich zugeordnete Verknüpfungsinformation der zweiten oder vierten Variante,

Diesbezüglich sieht eine andere Weiterbildung des Verfahrens vor, dass jeweils eine eindeutige Prüfinformation ermittelt wird

– für jedes einem jeweiligen Zuständigkeitsbereich zugeordnete Inventar, und/oder
– für das dem Hauptzuständigkeitsbereich zugeordnete Inventar, und/oder
– für jede dem Hauptzuständigkeitsbereich zugeordnete Verknüpfungsinformation gemäß der dritten oder vierten Variante,

Eine weitere Ausbildung des Verfahrens sieht vor, dass wenigstens eine dem Hauptzuständigkeitsbereich zugeordnete Beschreibungsinformation und/oder Verknüpfungsinformation und/oder das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar und/oder Metainventar jeweils eine weitere von dem Hauptzuständigkeitsbereich umfasste Dateneinheit darstellt, und/oder dass wenigstens eine einem Zuständigkeitsbereich zugeordnete Beschreibungsinformation und/oder Verknüpfungsinformation und/oder das dem Zuständigkeitsbereich zugeordnete Inventar jeweils eine weitere von diesem Zuständigkeitsbereich umfasste Dateneinheit darstellt.
Demnach kann zum Beispiel eine Beschreibungsinformation, eine Verknüpfungsinformation, ein Hauptinventar, ein Metainventar oder ein Inventar eines Zuständigkeitsbereichs jeweils in Form einer Datei vorliegen, die dann von dem Hauptzuständigkeitsbereich oder einem Zuständigkeitsbereich umfasst ist, wobei insbesondere für Dateien mit Beschreibungsinformationen oder Verknüpfungsinformationen vorgesehen sein kann, eine Prüfinformation zu ermitteln und diese Prüfinformation sowie eine Zeigerinformation auf die jeweilige Datei in ein Hauptinventar, Metainventar oder Inventar eines Zuständigkeitsbereiches aufzunehmen.
Vorzugsweise ist bei dem Verfahren vorgesehen, dass die Datenmenge vorrangig gemäß der weiteren Struktur gespeichert wird. Das heißt, dass die weitere Struktur Vorrang hat vor der ersten Struktur. So wird beim Speichern der Datenmenge z. B. zunächst für jeden Zuständigkeitsbereich gemäß der weiteren Struktur ein Ordner angelegt, und erst unterhalb bzw. innerhalb dieser Ordner werden die Datenteilmengen bzw. Dateneinheiten gemäß der ersten Struktur gespeichert. Oder wenn z. B. die gesamte Datenmenge in einer Datei gespeichert wird, wird auf der obersten Hierarchieebene zunächst für jeden Zuständigkeitsbereich gemäß der weiteren Struktur ein Knoten angelegt, und erst unterhalb bzw. innerhalb dieser Knoten werden auf der zweiten Hierarchieebene die Datenteilmengen bzw. Dateneinheiten gemäß der ersten Struktur gespeichert.
Eine andere Weiterbildung des Verfahrens sieht vor, dass jedem Benutzer, der von wenigstens einer Benutzermenge umfasst ist, die einem Zuständigkeitsbereich zugeordnet ist, und/oder der von der Hauptbenutzermenge umfasst ist, die dem Hauptzuständigkeitsbereich zugeordnet ist, eine eindeutige Signaturinformation sowie eine dazu passende eindeutige Verifikationsinformation zugeordnet wird. Bei der Signaturinformation kann es sich beispielsweise um einen digitalen privaten Signaturschlüssel und bei der Verifikationsinformation um einen digitalen öffentlichen Verifikationsschlüssel handeln, die zusammen ein Schlüsselpaar für asynchrone Kryptographie bilden.
Diesbezüglich sieht eine andere Weiterbildung des Verfahrens vor, dass bei einem Schreibzugriff auf eine Dateneinheit ein Signieren dieser Dateneinheit erfolgt, indem für diese zu speichernde Dateneinheit unter Einbeziehen der Signaturinformation, die dem den Schreibzugriff auslösenden Benutzer zugeordnet ist, eine Kontrollinformation ermittelt und dieser Dateneinheit zugeordnet wird. Bei dieser Kontrollinformation handelt es sich insbesondere um eine digitale Signatur. Bevorzugt wird für die zu speichernde Dateneinheit zunächst eine Prüfinformation, beispielsweise ein Hashwert, ermittelt und anschließend für diese Prüfinformation unter Einbeziehen der Signaturinformation, die dem den Schreibzugriff auslösenden Benutzer zugeordnet ist, eine Kontrollinformation ermittelt und dieser Dateneinheit zugeordnet und insbesondere hinzugefügt.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass bei einem Schreibzugriff auf eine Dateneinheit, für die eine Prüfsumme von einem Inventar, dem Hauptinventar oder dem Metainventar umfasst ist, ein Signieren der Dateneinheit derart erfolgt, dass

– für diese zu speichernde Dateneinheit eine neue Prüfinformation ermittelt wird,
– die von dem Inventar, dem Hauptinventar oder dem Metainventar für diese Dateneinheit umfasste Prüfinformation durch die neu ermittelte Prüfinformation ersetzt wird, und
– stellvertretend für diese Dateneinheit stattdessen für das Inventar, das Hauptinventar oder das Metainventar, das die für diese Dateneinheit neu ermittelte Prüfinformation umfasst, unter Einbeziehen der Signaturinformation, die dem den Schreibzugriff auslösenden Benutzer zugeordnet ist, eine Kontrollinformation ermittelt und diesem Inventar, Hauptinventar oder Metainventar zugeordnet wird. Somit sind vorteilhafter Weise mit nur einer Kontrollinformation, also zum Beispiel einer digitalen Signatur, gleich mehrere bzw. alle relevanten Dateneinheiten eines Zuständigkeitsbereiches signiert. Dies ist in der Regel schneller als das Ermitteln einer Kontrollinformation für jede einzelne Dateneinheit und zahlt sich vor allem dann aus, wenn nur eine Dateneinheit oder wenige Dateneinheiten geändert wurden.

Das digitale Signieren von Zuständigkeitsbereichen bzw. von wichtigen Dateneinheiten der Zuständigkeitsbereiche schafft die Voraussetzung, um Zuständigkeitsverletzungen und Manipulationen erkennen und die Integrität und Authentizität von Entwicklungsprojektdaten insgesamt oder in Teilen verifizieren zu können. Hier sieht die Erfindung in weiteren bevorzugten Ausbildungen Gültigkeitskontrollen vor.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass beim Signieren die Kontrollinformation unter zusätzlichem Einbeziehen einer Zeitinformation ermittelt wird. Dies ermöglicht eine noch sicherere Gültigkeitskontrolle.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass ausgelöst von einer Anforderung eines Benutzers oder von einem innerhalb einer vorbestimmbaren Zeitspanne stattfindenden ersten Lese- oder Schreibzugriff auf wenigstens eine Dateneinheit wenigstens eine Gültigkeitskontrolle durchgeführt wird, wobei das positive oder negative Ergebnis der Gültigkeitskontrolle angezeigt wird.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass, insbesondere in einem ersten Schritt, für das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar die Gültigkeit der dem Hauptinventar zugeordneten Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört,
und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar die Gültigkeit jeder von dem Hauptinventar umfassten Zeigerinformation kontrolliert wird, indem das Vorhandensein der durch die jeweilige Zeigerinformation angegebenen Dateneinheit kontrolliert wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die durch die Zeigerinformation angegebene Dateneinheit vorhanden ist,
und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar die Gültigkeit jeder von dem Hauptinventar umfassten Prüfinformation kontrolliert wird, indem für die durch die jeweilige Zeigerinformation angegebene Dateneinheit die Prüfinformation erneut berechnet wird und die erneut berechnete Prüfinformation mit der im Hauptinventar enthaltenen Prüfinformation verglichen wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die erneut berechnete Prüfinformation mit der im Hauptinventar enthaltenen Prüfinformation übereinstimmt.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass, insbesondere in einem zweiten Schritt, für das dem Hauptzuständigkeitsbereich zugeordnete Metainventar die Gültigkeit der dem Metainventar zugeordneten Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu einer Benutzermenge gehört, die einem der Zuständigkeitsbereiche zugeordnet ist,
und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Metainventar die Gültigkeit jeder von dem Metainventar umfassten Zeigerinformation kontrolliert wird, indem das Vorhandensein der durch die jeweilige Zeigerinformation angegebenen Dateneinheit kontrolliert wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die durch die Zeigerinformation angegebene Dateneinheit vorhanden ist,
und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Metainventar die Gültigkeit jeder von dem Metainventar umfassten Prüfinformation kontrolliert wird, indem für die durch die jeweilige Zeigerinformation angegebene Dateneinheit die Prüfinformation erneut berechnet wird und die erneut berechnete Prüfinformation mit der im Metainventar enthaltenen Prüfinformation verglichen wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die erneut berechnete Prüfinformation mit der im Metainventar enthaltenen Prüfinformation übereinstimmt.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass, insbesondere in einem dritten Schritt, für jedes einem Zuständigkeitsbereich zugeordnete Inventar die Gültigkeit der dem Inventar zugeordneten Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu der Benutzermenge gehört, die demselben Zuständigkeitsbereich zugeordnet ist, dem auch dieses Inventar zugeordnet ist,
und/oder dass für jedes einem Zuständigkeitsbereich zugeordnete Inventar die Gültigkeit jeder von dem Inventar umfassten Zeigerinformation kontrolliert wird, indem das Vorhandensein der durch die jeweilige Zeigerinformation angegebenen Dateneinheit kontrolliert wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die durch die Zeigerinformation angegebene Dateneinheit vorhanden ist,
und/oder dass für jedes einem Zuständigkeitsbereich zugeordnete Inventar die Gültigkeit jeder von dem Inventar umfassten Prüfinformation kontrolliert wird, indem für die durch die jeweilige Zeigerinformation angegebene Dateneinheit die Prüfinformation erneut berechnet wird und die erneut berechnete Prüfinformation mit der in dem Inventar enthaltenen Prüfinformation verglichen wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die erneut berechnete Prüfinformation mit der in dem Inventar enthaltenen Prüfinformation übereinstimmt.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass, insbesondere in einem vierten Schritt, für jede weitere von dem Hauptzuständigkeitsbereich umfasste Dateneinheit, welche eine zugeordnete Kontrollinformation besitzt, die Gültigkeit dieser Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu einer Benutzerschnittmenge gehört, die für diese Dateneinheit zuständig ist, sofern diese Dateneinheit eine Verknüpfungsinformation gemäß der dritten oder vierten Variante ist,
und/oder dass für jede weitere von einem jeweiligen Zuständigkeitsbereich umfasste Dateneinheit, welche eine zugeordnete Kontrollinformation besitzt, die Gültigkeit dieser Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu der Benutzermenge gehört, die demselben Zuständigkeitsbereich zugeordnet ist, der auch diese Dateneinheit umfasst.
Zweckmäßig wird ferner überprüft, ob mehr Dateneinheiten enthalten sind, als in irgendeinem Inventar vorhanden sind, denn ungeschützte, unverzeichnete Dateneinheiten dürfen, soweit sie relevant sind, nicht vorhanden sein.
Das digitale Signieren von Zuständigkeitsbereichen bzw. von wichtigen Dateneinheiten der Zuständigkeitsbereiche und das Kontrollieren der Gültigkeit der digitalen Signaturen gewährleisten ein zuverlässiges Erkennen von Zuständigkeitsverletzungen und Manipulationen sowie ein Verifizieren der Integrität und Authentizität von Entwicklungsprojektdaten insgesamt oder in Teilen.
Ferner sieht eine andere Weiterbildung des Verfahrens vor, dass, insbesondere bei jedem der vier zuvor beschriebenen Schritte, beim Kontrollieren der Gültigkeit einer Kontrollinformation, die unter zusätzlichem Einbeziehen einer Zeitinformation ermittelt wurde, ein positives Ergebnis der Gültigkeitskontrolle nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu dem in der Zeitinformation genannten Zeitpunkt

– zu der Hauptbenutzermenge gehörte, oder
– zu einer Benutzermenge gehörte, die einem der Zuständigkeitsbereiche zugeordnet ist, sofern diese Kontrollinformation dem Metainventar zugeordnet ist, oder
– der zu der Benutzermenge gehörte, die demselben Zuständigkeitsbereich zugeordnet ist, dem auch das Inventar zugeordnet ist, dem diese Kontrollinformation zugeordnet ist, oder
– der zu einer Benutzerschnittmenge gehörte, die für die Dateneinheit zuständig ist, der diese Kontrollinformation zugeordnet ist, sofern diese Dateneinheit eine Verknüpfungsinformation gemäß der dritten oder vierten Variante ist, oder
– der zu der Benutzermenge gehörte, die demselben Zuständigkeitsbereich zugeordnet ist, der auch die Dateneinheit umfasst, der diese Kontrollinformation zugeordnet ist.

Das Einbeziehen einer Zeitinformation in die digitale Signatur erhöht die Zuverlässigkeit nochmals, da somit bei einer späteren Gültigkeitskontrolle für eine Signatur nachvollziehbar ist, ob ein Benutzer zum Zeitpunkt des Signierens tatsächlich Mitglied der zuständigen Benutzermenge gewesen ist. Dies ist besonders vorteilhaft, wenn Entwicklungsprojekte über lange Zeiträume andauern, während derer eine gewisse Fluktuation der Benutzer und Zuständigkeiten durchaus auftreten kann.
Eine weitere Ausbildung des Verfahrens sieht vor, dass bei einem Schreibzugriff auf eine Datenteilmenge oder Dateneinheit, eine neue Version dieser Datenteilmenge oder Dateneinheit gespeichert wird.
Des Weiteren wird ein Entwicklungsumgebungssystem vorgeschlagen, das zur Durchführung des zuvor beschriebenen Datenorganisationsverfahren ausgebildet ist, umfassend

– eine Speichervorrichtung,
– eine Eingabe-/Ausgabevorrichtung, und
– eine Verarbeitungsvorrichtung,

In einem sehr einfachen Beispiel kann das Entwicklungsumgebungssystem also bereist durch einen entsprechend ausgebildeten Arbeitsplatzrechner oder Laptop repräsentiert sein.
Gemäß einer weiteren Ausbildung des Entwicklungsumgebungssystems ist vorgesehen, dass dieses mehrere Entwicklungsumgebungsgeräte umfasst, die jeweils eine Speichervorrichtung, eine Eingabe-/Ausgabevorrichtung und eine Verarbeitungsvorrichtung umfassen, und die jeweils eine Kommunikationsvorrichtung umfassen und mittels dieser zumindest zeitweise an ein Netzwerk angekoppelt sind und miteinander kommunizieren können. Dabei fungiert ein erstes der Entwicklungsumgebungsgeräte als Entwicklungsumgebungsserver, in dessen Speichervorrichtung die Entwicklungsprojektdaten zentral gespeichert sind, und wenigstens ein weiteres der Entwicklungsumgebungsgeräte fungiert als Entwicklungsumgebungsclient, dass auf die zentral gespeicherten Entwicklungsprojektdaten insbesondere lesend und/oder schreibend zugreifen kann.
Gemäß einer weiteren Ausbildung des Entwicklungsumgebungssystems ist vorgesehen, dass in der Speichervorrichtung des Entwicklungsumgebungsservers die Entwicklungsumgebung zentral gespeichert ist, wobei der Entwicklungsumgebungsclient auf die zentral gespeicherte Entwicklungsumgebung zugreifen kann. Dabei umfasst die Entwicklungsumgebung eine durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsservers ausführbare Entwicklungsumgebungsservereinheit und eine durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsclients ausführbare Entwicklungsumgebungsclienteinheit. Die Entwicklungsumgebungsservereinheit und die Entwicklungsumgebungsclienteinheit können insbesondere über das Netzwerk zusammenwirken. Dabei steuert die Entwicklungsumgebungsservereinheit bei Ausführung durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsservers wenigstens das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung des Entwicklungsumgebungsservers, während die Entwicklungsumgebungsclienteinheit bei Ausführung durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsclients wenigstens das Bereitstellen der Benutzerschnittstelle zum Bearbeiten des Entwicklungsprojekts an der Eingabe-/Ausgabevorrichtung des Entwicklungsumgebungsclients steuert.
Der Entwicklungsumgebungsserver kann dabei zum Beispiel auch durch Cloud-Computing bereitgestellt sein.
Alternativ hierzu kann das Entwicklungsumgebungssystem auch nur zwei oder mehr gleichrangige Entwicklungsumgebungsgeräte umfassen, wie zum Beispiel zwei entsprechend ausgebildete Arbeitsplatzrechner, die nicht als Client und Server zusammenwirken, jedoch über ein Netzwerk miteinander kommunizieren können, um zum Beispiel die Entwicklungsprojektdaten oder zumindest einen Teil davon in einem bestimmten Bearbeitungsstand von dem einem zu dem anderem Entwicklungsumgebungsgerät zu übertragen.
Beispielsweise kann das Entwicklungsumgebungssystem aber auch wenigstens ein Gerät einer Automatisierungsanlage umfassen, das mit wenigstens einem Entwicklungssystemgerät über ein Netzwerk kommunizieren kann, wobei die Entwicklungsprojektdaten Programmcode und/oder Konfigurationsdaten und/oder Parametrierungsdaten für wenigstens das eine Gerät der Automatisierungsanlage umfassen, und wobei Entwicklungsprojektdaten von dem Entwicklungsumgebungsgerät an das Gerät der Automatisierungsanlage übertragen werden, das durch die übertragenen Entwicklungsprojektdaten programmiert und/oder konfiguriert und/oder parametriert wird.
In einer weiteren Ausbildung des Entwicklungsumgebungssystems ist vorgesehen, dass die Entwicklungsumgebung das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung derart steuert, dass vor dem Einschreiben einer von den Entwicklungsprojektdaten umfassten Dateneinheit in die Speichervorrichtung wenigstens eine Gültigkeitskontrolle entsprechend dem Datenorganisationsverfahren erfolgt, wobei das Einschreiben der Dateneinheit in die Speichervorrichtung nur bei einem positiven Ergebnis der Gültigkeitskontrolle erfolgt.
Diese und weitere Merkmale sowie die vielen Vorteile der vorliegenden Erfindung ergeben sich auch aus dem Ausführungsbeispiel, welches nachfolgend unter Bezugnahme auf die beiliegenden Zeichnungen näher erläutert wird. Es zeigt dabei
1 eine schematische Darstellung eines beispielhaften Szenarios gemäß Stand der Technik, bei dem mittels eines Software-Werkzeugs eine Automatisierungslösung erstellt und bearbeitet sowie in Konfigurations- und ausführbare Daten übersetzt wird, die dann an die einzelnen Geräte verteilt werden;
2 eine schematische Darstellung einer typischen Benutzeroberfläche einer Entwicklungsumgebung bzw. eines Software-Werkzeugs für Entwicklungsprojekte gemäß Stand der Technik;
3 eine schematische Darstellung der Kollaboration bei der Bearbeitung einer Automatisierungslösung mit verteilten Systemen gemäß Stand der Technik;
4 eine schematische Darstellung eines Konfliktes bei der Kollaboration bei der Bearbeitung einer Automatisierungslösung gemäß Stand der Technik, bei dem ein ungewolltes Überschreiben einer Änderung erfolgt, anhand eines Ablaufdiagramms;
5 eine schematische Darstellung der Kollaboration bei der Bearbeitung einer Automatisierungslösung mit verteilten Systemen gemäß DE 11 2013 007 160 T6 (Stand der Technik);
6 eine schematische Darstellung der Aufteilung einer Automatisierungslösung in Zuständigkeitsbereiche;
7 eine schematische Darstellung der Zuordnung von Teams zu den Zuständigkeitsbereichen innerhalb einer Automatisierungslösung;
8 eine schematische Darstellung einer Konfliktvermeidung anhand eines Ablaufdiagramms;
9 eine schematische Darstellung möglicher Varianten der Aufteilung der Verknüpfungstabelle (VKT) sowie der Zuordnung der VKT-Teile zu bestimmten Zuständigkeitsbereichen innerhalb einer Automatisierungslösung;
10 eine schematische Darstellung der Beziehungen der Dateneinheiten zu den Inventaren beziehungsweise zum Hauptinventar innerhalb einer Automatisierungslösung;
11 eine schematische Darstellung des Aufbaus des Hauptinventars, des Metainventars und der Inventare der Zuständigkeitsbereiche innerhalb einer Automatisierungslösung; und
12 eine schematische Darstellung der Beziehungen des Metainventars sowohl zum Hauptinventar als auch zu den Inventaren der Zuständigkeitsbereiche und zu den bereichsübergreifenden VKT-Teilen innerhalb einer Automatisierungslösung.
Die 1 bis 5 wurden eingangs bereits im Zusammenhang mit dem Stand der Technik erläutert, so dass nachfolgend höchstens noch vereinzelt darauf Bezug genommen wird. Anhand der 6 bis 12 wird nunmehr vor allem die vorliegende Erfindung näher erläutert.
Die Erfindung wurde entwickelt aufgrund der eingangs dargelegten Probleme und Nachteile bestehender Entwicklungsumgebungen bzw. Software-Werkzeuge für das Erstellen und Bearbeiten von Automatisierungslösungen. Es wurde jedoch bald deutlich, dass das erfindungsgemäße Datenorganisationsverfahren für eine zu speichernde oder gespeicherte Datenmenge sowie das Entwicklungsumgebungssystem, welches dieses Datenorganisationsverfahren durchführen kann nicht nur für das Entwickeln von Steuersoftware für Automatisierungsanlagen sondern für das Erstellen und Bearbeiten von Softwareprojekten im Allgemeinen und darüber hinaus für sonstige Entwicklungsprojekte anwendbar und nützlich ist, insbesondere wenn es während des Entwicklungsprojektes auch um die Kollaboration mehrerer Personen bzw. Benutzer geht.
Zur weiteren Erläuterung des erfindungsgemäßen Datenorganisationsverfahrens und Entwicklungsumgebungssystems wird jedoch auch im Folgenden weiterhin an dem Anwendungsbeispiel der Entwicklung einer Automatisierungslösung bzw. einer Steuersoftware für Automatisierungsanlagen festgehalten.
Ein erfindungsgemäßes Entwicklungsumgebungssystem, das zur Durchführung des erfindungsgemäßen Datenorganisationsverfahrens ausgebildet ist, ist in den Figuren nicht explizit gezeigt. In einem sehr einfachen Beispiel kann es nur ein Entwicklungsumgebungsgerät, wie zum Beispiel einen Arbeitsplatzrechner, umfassen, das mit einer Speichervorrichtung, einer Eingabe-/Ausgabevorrichtung und einer Verarbeitungsvorrichtung ausgestattet ist. Dabei ist in der Speichervorrichtung zum einen eine Datenmenge, die Entwicklungsprojektdaten enthält, und zum anderen eine Entwicklungsumgebung bzw. ein Software-Werkzeug gespeichert, die bei Ausführung durch die Verarbeitungsvorrichtung das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung entsprechend dem erfindungsgemäßen Datenorganisationsverfahren und das Bereitstellen einer Benutzerschnittstelle zum Bearbeiten des Entwicklungsprojekts an der Eingabe-/Ausgabevorrichtung steuert.
In einem anderen Beispiel kann ein erfindungsgemäßes Entwicklungsumgebungssystem ähnlich gestaltet sein, wie das in 3 gezeigte System des Stands der Technik. Das heißt, der in 3 gezeigte Server (System Z) könnte einem Entwicklungsumgebungsserver und die in 3 gezeigten Arbeitsplatzrechner (System R.1, R.2 bis R.m) könnten Entwicklungsumgebungsclients des erfindungsgemäßen Entwicklungsumgebungssystems entsprechen, welche über das in 3 aus Übersichtlichkeitsgründen nicht weiter dargestellte Netzwerk miteinander kommunizieren können. Der Entwicklungsumgebungsserver speichert dabei in einer nicht dargestellten Speichervorrichtung eine die Entwicklungsprojektdaten umfassende Datenmenge sowie eine, eine Entwicklungsumgebungsservereinheit und eine Entwicklungsumgebungsclienteinheit umfassende Entwicklungsumgebung. Sowohl auf die Entwicklungsprojektdaten als auch auf die Entwicklungsumgebung können die Entwicklungsumgebungsclients zugreifen. Durch eine nicht dargestellte Verarbeitungsvorrichtung des Entwicklungsumgebungsservers ist die Entwicklungsumgebungsservereinheit ausführbar und durch eine nicht dargestellte Verarbeitungsvorrichtung eines des Entwicklungsumgebungsclients ist die Entwicklungsumgebungsclienteinheit ausführbar. Die Entwicklungsumgebungsservereinheit und die Entwicklungsumgebungsclienteinheit können dann über das Netzwerk zusammenwirken. Dabei steuert die Entwicklungsumgebungsservereinheit bei Ausführung durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsservers wenigstens das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung des Entwicklungsumgebungsservers, während die Entwicklungsumgebungsclienteinheit bei Ausführung durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsclients wenigstens das Bereitstellen der Benutzerschnittstelle zum Bearbeiten des Entwicklungsprojekts an der Eingabe-/Ausgabevorrichtung des Entwicklungsumgebungsclients steuert. Möglich ist auch, dass mehrere Entwicklungsumgebungsclients mit ihren Verarbeitungsvorrichtungen jeweils eine Entwicklungsumgebungsclienteinheit ausführen, so dass an der jeweiligen Eingabe-/Ausgabevorrichtung jedes der Entwicklungsumgebungsclients eine Benutzerschnittstelle zum Bearbeiten des Entwicklungsprojekts bereitsteht.
Ein wesentlicher Aspekt der Erfindung liegt in dem Reorganisieren der Struktur einer gespeicherten oder zu speichernden Datenmenge, wie beispielsweise den Entwicklungsprojektdaten einer Automatisierungslösung, und in dem Schaffen einer strikten Aufteilung der Datenmenge in Zuständigkeitsbereiche. Dabei stellen die Zuständigkeitsbereiche nicht überlappende Bereiche dar, so dass zu jedem Zuständigkeitsbereich eine eindeutige Menge von zuständigen Personen bzw. Benutzern zugeordnet werden kann. Dadurch können viele Konflikte, die beim kollaborativen Erstellen und Bearbeiten von Automatisierungslösungen bisher auftraten, nun nicht mehr entstehen.
Einen weiteren wesentlichen Aspekt der Erfindung stellt das Absichern jedes einzelnen Zuständigkeitsbereiches bzw. wenigstens einer von dem jeweiligen Zuständigkeitsbereich umfassten Datenteilmenge gegen unbefugte Manipulation durch asymmetrische digitale Signaturen dar, welche durch zuständige Personen bzw. Benutzer, das heißt solche, die zu der einem jeweiligen Zuständigkeitsbereich zugeordneten Benutzermenge gehören, angebracht und nach Bearbeitung erneuert werden. Dies ermöglicht das Erkennen von Zuständigkeitsverletzungen und Manipulationen und erlaubt die Verifizierung der Integrität und Authentizität von Datenteilmengen oder der gesamten Datenmenge, ohne dass die Benutzer hierfür ein Geheimnis, wie zum Beispiel ein Passwort, teilen müssten.
Anstelle der ausschließlichen Organisation der Speicherstruktur nach dem Architekturmodell der IEC 61131 Teil 3 tritt an übergeordneter Stelle eine Organisation nach explizit vom Benutzer zu definierenden Zuständigkeitsbereichen. Jeder Zuständigkeitsbereich kann beliebige Elemente des Architekturmodells nach IEC 61131 Teil 3 enthalten. Über eine logische Verknüpfung können die Elemente weiterhin auch nach dem bekannten Architekturmodell organisiert werden, die Organisation der Speicherstruktur erfolgt aber in erster Linie nach den Zuständigkeitsbereichen. Tatsächlich enthält also jeder Zuständigkeitsbereich nur einen Teil der Automatisierungslösung und damit gegebenenfalls sogar nur Teile jener durch das Architekturmodell definierten Baumstruktur einer vollständigen Automatisierungslösung.
Wenn eine Automatisierungslösung als Sammlung von Dateien mit deren Organisation in Dateiordnern erfolgt, dann ist es für die Anwendung der Aufteilung nach Zuständigkeitsbereichen beispielsweise sinnvoll, im Wurzelordner der gespeicherten Automatisierungslösung je Zuständigkeitsbereich einen Ordner anzulegen und erst darunter mit einer Dateiordnerstruktur nach der Hierarchie des Architekturmodells gemäß IEC 61131 Teil 3 fortzufahren. Dieses ist beispielhaft in der 6 dargestellt. Hier wird eine herkömmliche Automatisierungslösung in zwei Zuständigkeitsbereiche aufgeteilt. Der eine Zuständigkeitsbereich behandelt thematisch das Schweißen (englisch „welding”), der zweite Zuständigkeitsbereich enthält alle Elemente für das Lackieren (englisch „coating”). Es ist denkbar, dass ein weiterer Zuständigkeitsbereich eingerichtet wird, in welchem für das Schweißen und Lackieren gemeinsam benötigte Elemente untergebracht werden. Dieses ist zum Beispiel dann sinnvoll wenn solche Querschnittsfunktionalität tatsächlich vorhanden und isolierbar ist. Mit dem Beispiel sind nicht alle denkbaren Varianten dargestellt. Es ist insbesondere nicht notwendig, dass Zuständigkeitsbereiche wie im Beispiel „vertikal” nach Prozessschritten getrennt werden (erst schweißen, dann lackieren). Es wäre auch denkbar, dass eine Trennung nach Technologie „horizontal” erfolgt, zum Beispiel, wenn eine Arbeitsgruppe auf Visualisierung spezialisiert ist und sowohl für den Schweißvorgang als auch für den Lackiervorgang die Visualisierungspanele programmiert. Mischungen von „horizontaler” und „vertikaler” Trennung sind denkbar und sinnvoll, je nach der Verteilung von Expertise auf verschiedene Arbeitsgruppen. Zunehmend enthalten Automatisierungslösungen auch Bestandteile, die nicht vom Architekturmodell nach IEC 61131 Teil 3 erfasst sind. Auch für diese ist die Aufteilung nach Zuständigkeitsbereichen sinnvoll.
Weiter sieht die Erfindung vor, dass jedem Zuständigkeitsbereich eine Person bzw. ein Benutzer als Eigentümer zugeordnet wird. Für das Ermöglichen einer Zusammenarbeit ist die Zuordnung einer Eigentümergruppe anstatt eines einzelnen Eigentümers sinnvoll. Im Folgenden wird statt Eigentümergruppe auch von Team gesprochen. Ein Team kann eine beliebige Menge von Personen bzw. Benutzern umfassen, im Spezialfall also eine Person und damit genau einen Eigentümer. Weiter wird der Automatisierungslösung selbst eine Eigentümergruppe bzw. ein Team zugeordnet. Zur besseren Unterscheidbarkeit von den Eigentümergruppen anderer Zuständigkeitsbereiche wird die der Automatisierungslösung zugeordnete Eigentümergruppe im Folgenden auch als Haupteigentümergruppe und der ihr zugeordnete Zuständigkeitsbereich als Hauptzuständigkeitsbereich bezeichnet. Auch die Haupteigentümergruppe kann eine beliebige Menge von Personen bzw. Benutzern umfassen. Die Zuordnung kann beispielsweise jeweils im Dateiordner des Zuständigkeitsbereichs beziehungsweise für die Automatisierungslösung im Wurzelordner der Lösung hinterlegt werden.
Tatsächlich ist die Zuordnung einer Eigentümergruppe zu der Automatisierungslösung in Gänze ein sinnvoller erster Schritt beim Erstellen bzw. Anlegen einer Automatisierungslösung. Er muss spätestens beim Aufteilen einer Automatisierungslösung in Zuständigkeitsbereiche erfolgen. Denn so entsteht eine organisatorische Aufgabenteilung, welche verhindert, dass beliebige Benutzer bzw. Personen innerhalb einer Automatisierungslösung Zuständigkeitsbereiche und Zuständigkeiten verändern. Die zur Eigentümergruppe der ganzen Automatisierungslösung gehörenden Personen sollten bevorzugt auch solche sein, die innerhalb der Organisation (zum Beispiel des Unternehmens oder der Institution), welche die Automatisierungslösung erstellt, hinreichend unabhängig sind, zum Beispiel indem sie Weisungsbefugnis und Entscheidungsgewalt in der Sache der Automatisierungslösung haben.
In 7 ist ein Beispiel für die Zuordnung von Teams innerhalb einer Automatisierungslösung gezeigt. Der Automatisierungslösung namens „BeispielLösungNeu” ist das Team „Owner” zugeordnet. Dem Zuständigkeitsbereich „HMI” ist das Team „HMI Engineers”, dem Zuständigkeitsbereich „Welding” das Team „Welding Engineers” und dem Zuständigkeitsbereich „Coating” das Team „Coating Engineers” zugeordnet. In der 7 ist die Zuordnung eines Teams zu einem Zuständigkeitsbereich beispielhaft mittels Dateien dargestellt, das heißt, innerhalb des dem Hauptzuständigkeitsbereich entsprechenden Wurzelordners der Automatisierungslösung befindet sich eine Datei zwecks Zuordnung des Teams „Owner”, und jedem Zuständigkeitsbereich ist ein Unterordner zugeordnet, in welchem sich wiederum jeweils eine Datei befindet, die definiert, welches Team diesem Zuständigkeitsbereich zugeordnet ist. Die Zuordnung der Teams zum Hauptzuständigkeitsbereich und zu den Zuständigkeitsbereichen kann aber auch auf andere Weise erfolgen, beispielsweise zusammen mit anderen Werten innerhalb einer Beschreibungsdatei für den jeweiligen Bereich.
Es ist denkbar, dass die Datenmenge des gesamten in 7 dargestellten Ordnerbaumes samt Dateien innerhalb einer einzigen strukturierten Datei enthalten ist, zum Beispiel innerhalb einer komprimierten Datei nach dem ZIP-Dateiformat. Es ist auch denkbar, dass die Definition von Zuständigkeitsbereichen und Zuordnung von Teams in einer einzigen Datei geschieht, welche direkt im Wurzelordner der Automatisierungslösung angeordnet ist.
Die konkrete Form der Zuordnung von Teams kann vielgestaltig sein. Es ist zum Beispiel möglich, dass eine Datei, welche die Zuordnung definiert, alle Benutzer bzw. Personen nennt, die zum Team gehören. Alternativ ist es möglich, dass innerhalb der Speicherung einer Automatisierungslösung ein Team nur anhand eines Bezeichners referenziert wird und die eigentliche Liste von zugehörigen Personen außerhalb der Automatisierungslösung verfügbar ist, zum Beispiel in einem Verzeichnisdienst wie einem LDAP-Server. Sehr gut geeignet erscheint die Zuordnung von einzelnen Personen zu Teams mittels Attributzertifikat. Das heißt der Verzeichnisdienst speichert für jede Person bzw. jeden Benutzer ein Zertifikat, wobei in dem Zertifikat der Name wenigstens eines Teams der Automatisierungslösung eingetragen ist, dessen Mitglied die Person sein soll.
Vorteilhaft an der Speicherung von Automatisierungslösungen gemäß der Erfindung ist, dass unterschiedliche Teams an unterschiedlichen Bereichen der Automatisierungslösung arbeiten und damit an unterschiedlichen Bereichen weitgehend konfliktfrei Änderungen vornehmen können. Konflikte treten damit nur noch auf, wenn innerhalb des Teams an derselben Stelle eines Zuständigkeitsbereiches zeitlich überlappend Änderungen vorgenommen werden. In der Praxis ist das von geringer Bedeutung, weil üblicherweise innerhalb eines Teams während des normalen Arbeitsalltags regelmäßige Absprachen zur Arbeitsorganisation erfolgen und so Konflikte in vorbeugender Weise automatisch vermieden werden.
Wie eingangs bereits erklärt, ist die VKT ein zentraler Bestandteil einer Automatisierungslösung und kann in Gänze nicht einem konkreten Zuständigkeitsbereich zugeordnet werden, auch nicht mit der bereits mit der Erfindung erklärten reorganisierten Struktur einer Automatisierungslösung. Denn die Eigenschaft der Verknüpfungstabelle ist die einer Matrix, welche definiert, welche Variablen einer Automatisierungslösung welchen Ein- und Ausgängen verknüpft sind. Ein- und Ausgänge können jene von POEs sein oder zum Beispiel zu IO-Modulen, Feldgeräten oder Remote-IOs gehören. Weil nach der erfindungsgemäßen Struktur der Automatisierungslösung Ein- und Ausgänge sowie POEs und Ressourcen in beliebigen Zuständigkeitsbereichen angeordnet sein können, müssen Verknüpfungen laut VKT zwischen verschiedenen Zuständigkeitsbereichen möglich sein. Die 9 zeigt vier mögliche Varianten der Aufteilung der Verknüpfungstabelle (VKT) einer Automatisierungslösung, sowie die Zuordnung der VKT-Teile zu bestimmten Zuständigkeitsbereichen.
Eine erste Variante sieht vor, die VKT zentral, das heißt im Hauptzuständigkeitsbereich der Automatisierungslösung, anzuordnen, zum Beispiel als Datei innerhalb ihres Wurzelordners. Damit hier ohne Konflikte gearbeitet werden kann, macht es Sinn, das Pflegen dieser Verknüpfungen den Mitgliedern der Haupteigentümergruppe zu übertragen. Diese Variante entspricht weitgehend dem Stand der Technik. Neu ist die Zuteilung der Zuständigkeit zu einer Haupteigentümergruppe.
Eine zweite Variante sieht vor, dass die VKT auf einen zentralen VKT-Teil und in je einen weiteren VKT-Teil pro Zuständigkeitsbereich der Automatisierungslösung aufgeteilt wird. In dem zentralen VKT-Teil werden genau die Verknüpfungen erfasst, welche zwischen Variablen und Ein- sowie Ausgängen verschiedener Zuständigkeitsbereiche erstellt und gepflegt werden müssen. In dem VKT-Teil eines Zuständigkeitsbereiches werden genau die Verknüpfungen erfasst, welche zwischen Variablen und Ein- sowie Ausgängen innerhalb dieses Zuständigkeitsbereiches erstellt und gepflegt werden müssen. Bei dieser Variante ist die Anzahl der Konflikte beim Erstellen und Pflegen von Verknüpfungen reduziert, weil die Zuständigkeit für einen bestimmten Teil der VKT bei dem jeweiligen Team des zugehörigen Zuständigkeitsbereiches liegt. Eine Herausforderung bei der Pflege der Teile der VKT liegt hier in der komplexen Handhabung von Vorgängen, bei denen eine Verknüpfung durch Veränderung der beteiligten Ein- und Ausgänge und oder der beteiligten Variablen zwischen den Teilen migriert werden muss. Sie muss dann in einem ersten Schritt aus dem einen Teil der VKT entfernt und in einem zweiten Schritt in dem anderen Teil der VKT hinzugefügt werden. Gegebenenfalls müssen diese Schritte unterschiedliche Personen durchführen um das Prinzip der strikten Einteilung der Zuständigkeiten zu wahren.
Eine dritte Variante sieht vor, dass die VKT in viele Teile zerteilt wird, so dass je Kombination von durch die Verknüpfung betroffenen Zuständigkeitsbereichen ein Teil der VKT existiert. Dieses sind bei einer Anzahl von N Zuständigkeitsbereichen 2^N – 1 VKT-Teile. Die Zuständigkeit je VKT-Teil ist dann so definiert, dass jeder VKT-Teil durch einen Benutzer verändert werden darf, der entweder Mitglied der Haupteigentümergruppe ist oder Mitglied in allen Teams aller durch den VKT-Teil betroffenen Zuständigkeitsbereiche. Personen, die Mitglied in mehreren Teams sind, können in Analogie zu dem Prinzip der strikten Einteilung der Zuständigkeiten als Diplomaten bezeichnet werden. Bei dieser Variante wird die Anzahl der möglichen Konflikte stark reduziert, während allerdings die Komplexität der Handhabung steigt und somit der Aufwand für die Implementierung eines nutzerfreundlichen Software-Werkzeuges. Tatsächlich unterstützt diese Variante den natürlichen Arbeitsfluss in größeren Organisationen und erlaubt dort eine sehr gute Arbeitsteilung.
Eine vierte Variante verfeinert die dritte Variante in der Form, dass die Teile der Verknüpfungstabelle, welche zu einer Kombination von genau einem Zuständigkeitsbereich gehören, jeweils in diesem Zuständigkeitsbereich gespeichert werden. Auch diese Variante ist beispielhaft mit der 9 unten dargestellt.
Durch die Einteilung einer abgespeicherten Automatisierungslösung in Zuständigkeitsbereiche ohne Überlappung ist es leicht möglich, asymmetrische digitale Signaturen zur Erkennung von nicht autorisierten Manipulationen und damit zum Manipulationsschutz einzusetzen. Die Erfindung sieht dazu vor, dass je Zuständigkeitsbereich alle relevanten Daten des Zuständigkeitsbereiches von einer zeichnungsberechtigten Person bzw. einem zeichnungsberechtigten Benutzer digital signiert werden. Zeichnungsberechtigt für einen Zuständigkeitsbereich ist jede Person, die Mitglied des Teams ist, welches dem Zuständigkeitsbereich zugeordnet ist, sowie in der Regel auch jede Person, die Mitglied der Haupteigentümergruppe ist.
Zusätzlich sieht die Erfindung vor, dass die Aufteilung der Automatisierungslösung in Zuständigkeitsbereiche und die Zuordnung der Teams durch ein Mitglied der Haupteigentümergruppe asymmetrisch digital signiert werden muss, zuzüglich aller relevanten Daten, welche von zentraler Bedeutung für die Automatisierungslösung sind, also nicht eindeutig einem Zuständigkeitsbereich zugeordnet werden können. Welche Teams als Eigentümergruppen geeignet sind, ist sinnvollerweise außerhalb der Automatisierungslösung definiert, zum Beispiel mittels eines Attributes innerhalb des Zertifikates zum öffentlichen Schlüssel der jeweiligen Gruppenmitglieder. Alternativ kann diese Information zum Beispiel in der Konfiguration der Installation des Software-Werkzeuges zur Pflege der Automatisierungslösung hinterlegt sein.
Es ist vorgesehen, dass das Software-Werkzeug zur Erstellung und Pflege von Automatisierungslösungen diese authentifiziert, wenn sie mit dem Software-Werkzeug gelesen oder bearbeitet werden. Ferner soll das Software-Werkzeug den Benutzer in geeigneter Weise über den Erfolg oder Misserfolg der Authentifizierung informieren bzw. warnen. Insbesondere prüft das Software-Werkzeug dabei, dass die notwendige Zeichnungsbefugnis für die jeweiligen Signaturen vorliegt, indem es die Mitgliedschaft der jeweils unterzeichnenden Personen in den zugeordneten Teams überprüft.
Eine vorteilhafte Gestaltung der technischen Realisierung des Manipulationsschutzes ist schon in 7 gezeigt. Dort ist an zentraler Stelle für die Automatisierungslösung in Form einer Datei im Wurzelordner ein signiertes Inventar dargestellt. Weiter ist je Zuständigkeitsbereich der Automatisierungslösung ein signiertes Inventar dargestellt, welches analog als Datei innerhalb des Ordners des jeweiligen Zuständigkeitsbereiches verortet ist. Prinzipiell könnten die Inventare auch anders verortet sein, wichtig für die weitgehend konfliktfreie Zusammenarbeit und für die eindeutige Zuordnung der Zeichnungsbefugnis ist lediglich ihre Aufteilung. Mit einem signierten Inventar ist hier gemeint, dass eine Liste von kryptographisch starken Prüfsummen von relevanten Daten eines Zuständigkeitsbereiches insgesamt digital signiert wird, das heißt, zu der Liste von kryptographisch starken Prüfsummen von relevanten Daten wird mittels eines einem Teammitglied zugeordneten privaten Signaturschlüssels eine digitale Signatur ermittelt. Es ist damit ein effizientes Mittel, um nach einer kleinen Änderung von Daten innerhalb eines Zuständigkeitsbereiches oder an zentraler Stelle der Automatisierungslösung relativ schnell eine neue Signatur erzeugen zu können. Die Erfindung greift hier im Wesentlichen auf das Prinzip eines Prüfsummenbaums zurück. Zur besseren Unterscheidbarkeit von den Inventaren anderer Zuständigkeitsbereiche wird das der Automatisierungslösung zugeordnete Inventar im Folgenden auch als Hauptinventar bezeichnet.
Die 10 zeigt die Beziehungen der Dateneinheiten zu den Inventaren und die Beziehungen weiterer Dateneinheiten zum Hauptinventar. Dargestellt ist dieselbe Automatisierungslösung wie bei 7. Zusätzlich sind in 10 durch geschweifte Klammern Daten zusammengefasst und mit Pfeilen jeweils genau jenem Inventar zugeordnet, durch das sie gegen unbefugte Manipulation geschützt werden. Hierbei ist zu beachten, dass zentrale Eigenschaften der Automatisierungslösung wie zum Beispiel der Name und die Zuordnung der Haupteigentümergruppe eben durch das von einem Mitglied der Haupteigentümergruppe signierte zentrale Inventar, also das Hauptinventar, geschützt werden. Erkennbar umfasst das Hauptinventar somit nicht die Inventare der Zuständigkeitsbereiche. Ansonsten entstünde das Problem, dass durch eine Änderung in einem Bereich, welches eine Änderung im zugehörigen Inventar bewirkt, auch eine Änderung im Hauptinventar notwendig wird und dessen Signatur dann nicht mehr stimmen würde, so dass im Endeffekt nur ein Benutzer der Hauptbenutzergruppe überhaupt ändern könnte.
Nicht in 10 dargestellt aber für den vollständigen Schutz grundsätzlich notwendig ist, dass alle Inventare einmalige und eindeutige Eigenschaften der Automatisierungslösung mit in die digitale Signatur einbeziehen. Zum Beispiel kann die Automatisierungslösung als zentrales Attribut eine zufällig erzeugte und mit hoher Wahrscheinlichkeit global eindeutige Identität (ID) haben und diese kann in die digitale Signatur für das Inventar mit einbezogen werden. Dadurch wird es einer unbefugten Person nahezu unmöglich, durch Vertauschung von Inventaren oder ganzer Zuständigkeitsbereiche von gültigen aber verschiedenen Automatisierungslösungen neue aber von keiner befugten Person tatsächlich signierte bzw. freigegebene Kombinationen von Automatisierungslösungen zusammenzustellen. Solche Manipulation kann dann erkannt werden, weil die Bezüge auf die Identitäten nicht passen.
Prinzipiell kann ein Inventar von beliebiger Gestalt sein. Wichtig ist nur, dass der gesamte Zustand aller relevanten Daten eines Zuständigkeitsbereiches einer Automatisierungslösung mit Hilfe der digitalen Signatur, die für das Inventar ermittelt wird, erfasst wird. Analog gilt dies auch für die zentralen relevanten Daten des Hauptzuständigkeitsbereichs bzw. der Automatisierungslösung, deren Zustand mit Hilfe der digitalen Signatur eines Haupteigentümers, die für das Hauptinventar ermittelt wird, erfasst werden muss. Ansonsten wäre es einem Unbefugten möglich, Teile der Automatisierungslösung zum Beispiel durch einen gültig signierten alten Stand zu ersetzen.
Weitere Einzelheiten der Inventare werden später noch anhand der 11 erläutert.
Für die vier oben beschriebenen Varianten der Aufteilung der VKT wird der Manipulationsschutz wie folgt erfindungsgemäß umgesetzt.
Für die erste Variante wird die einzige zentral angeordnete und vollständige VKT mit in das Hauptinventar aufgenommen, welches von einem Mitglied der Haupteigentümergruppe signiert wird.
Für die zweite Variante wird der zentrale VKT-Teil, welcher Verknüpfungen zwischen Zuständigkeitsbereichen enthält, mit in das Hauptinventar aufgenommen, welches von einem Mitglied der Haupteigentümergruppe signiert wird. Alle anderen VKT-Teile werden jeweils in das Inventar mit aufgenommen, welches zu dem jeweiligen Zuständigkeitsbereich gehört.
Für die dritte Variante werden die einzelnen Teile der VKT jeweils direkt durch denjenigen Benutzer signiert, welcher den VKT-Teil zuletzt verändert hat. Zeichnungsberechtigt sind die bereits erklärten Diplomaten, also Personen bzw. Benutzer, die bei all jenen Zuständigkeitsbereichen gleichzeitig im zugehörigen Team Mitglied sind, die durch den VKT-Teil betroffen sind. Diese VKT-Teile werden jedoch nicht in eines der bisher erklärten Inventare mit aufgenommen, sondern in ein sogenanntes Metainventar, das später anhand der 12 näher erläutert wird.
Für die vierte Variante kann der Manipulationsschutz auf gleiche Weise wie für die dritte Variante implementiert werden. Alternativ existiert jedoch auch die Möglichkeit, dass wegen der speziellen Verortung von bestimmten Teilen der VKT in einem konkreten Zuständigkeitsbereich, jene Teile in das Inventar des jeweiligen Zuständigkeitsbereiches aufgenommen werden, so dass sie dann über die Signatur für das Inventar gesichert sind.
Bei dem bisher erklärten erfindungsgemäßen Manipulationsschutz für Automatisierungslösungen basierend auf asymmetrischen Signaturen besteht noch die Gefahr, dass getrennt signierte Teile derselben Automatisierungslösung durch andere gültig signierte Versionen dieser Teile auch durch unbefugte Personen ausgetauscht werden können, ohne dass ein Software-Werkzeug dieses erkennen könnte. Das liegt daran, dass keine kryptographisch starke Verbindung weder zwischen den einzelnen Zuständigkeitsbereichen untereinander noch zwischen den Zuständigkeitsbereichen und den zentralen Daten der Automatisierungslösung existiert. Ersichtlich ist dies beispielhaft an der 10. Die Inventare der einzelnen Zuständigkeitsbereiche sind in keiner Weise kryptographisch untereinander oder mit dem Hauptinventar der Automatisierungslösung verbunden. Für den Zeitraum der fortschreitenden Entwicklung an einer Automatisierungslösung wäre dieses auch gerade hinderlich, weil ja eine möglichst konfliktfreie Zusammenarbeit ermöglicht werden soll.
Die Erfindung sieht deshalb vor, dass zusätzlich zu den einzelnen Inventaren stets ein übergeordnetes Inventar gepflegt wird, mit welchem die anderen Inventare signiert werden. Das übergeordnete Inventar wird hier zur Unterscheidung Metainventar genannt. Es dient als kryptographische Klammer über den gesamten Stand der Automatisierungslösung und wird im Folgenden anhand der 11 und 12 erläutert.
Sinnvollerweise sieht das Software-Werkzeug vor, dass während normaler Entwicklungstätigkeit jede Person das Metainventar signieren darf, welche Mitglied der Haupteigentümergruppe oder eines Teams eines Zuständigkeitsbereiches, das heißt irgendeines Zuständigkeitsbereiches der Automatisierungslösung, ist. Zur Erstellung wichtiger Versionen, zum Beispiel vor Inbetriebnahme eines Ergebnisses der Entwicklungstätigkeit, eines sogenannten Releases, kann jedoch das Erfordernis gelten, dass das Metainventar durch ein Mitglied der Haupteigentümergruppe signiert werden muss. Dies kann besonders für solche Releases erforderlich bzw. von Vorteil sein, die nach Richtlinien der funktionalen Sicherheit zertifiziert werden sollen oder worden sind. Das Software-Werkzeug kann zum Beispiel in die Signatur für das Metainventar die Information aufnehmen, dass damit ein Release-Stand signiert wird.
In 11 ist beispielhaft der Aufbau des Hauptinventars, des Metainventars und der Inventare der Zuständigkeitsbereiche beschrieben. Eine Automatisierungslösung mit dem Namen „L” ist in einem Ordner mit dem Namen „L” abgelegt. Innerhalb des Ordners „L”, dessen Inhalt dem Hauptzuständigkeitsbereich gehört, ist eine Datei namens „Solution.xml” mit einer Beschreibung der Automatisierungslösung vorhanden, die einen Wert zur Identität (ID) „86cfd7fe..” und zum Namen „L” der Automatisierungslösung angibt sowie einen Wert zum Namen der zugehörigen Haupteigentümergruppe „TeamO” angibt.
Die Datei „Inventar.xml” im Ordner „L” enthält das zentrale Inventar der Automatisierungslösung, also das Hauptinventar. Im gleichen Ordner ist auch eine Datei „Metalnventar.xml” enthalten, welche das Metainventar im Sinne der Erfindung enthält.
Im Ordner „L” der Automatisierungslösung existiert ein Unterordner je Zuständigkeitsbereich und darin wiederum jeweils eine Beschreibungsdatei für den Zuständigkeitsbereich und eine Inventardatei. Die Beschreibungsdatei eines Zuständigkeitsbereichs wiederholt die Identität der Automatisierungslösung, zu welcher der Zuständigkeitsbereich gehört, und definiert eine eigene Identität (ID) für den Zuständigkeitsbereich sowie ein zuständiges Team.
Das Hauptinventar und das Metainventar nennen beide ebenfalls die Identität der Automatisierungslösung. Ein Inventar in einem Zuständigkeitsbereich enthält hingegen einen Wert für die Identität (ID) des Zuständigkeitsbereiches. Weiter ist in jedem Inventar eine Tabelle mit Dateinamen und den zu den Inhalten der Dateien ermittelten Hashwerten enthalten. Beispielhafte Beziehungen zwischen Dateien und ihren Hashwerten in den Inventaren sind bei 11 über die gestrichelten Pfeile symbolisiert. Dateinamen werden dabei relativ zur Position des Inventars benannt, also gegebenenfalls mit Namen der Unterordner. Zuletzt ist jedes Inventar mit seinem ganzen eigenen Inhalt signiert.
Welche Menge von Dateien und zugehörigen Hashwerten in einem Inventar aufgelistet bzw. enthalten ist, hängt von der Art des Inventars ab. Ein Inventar für einen Zuständigkeitsbereich listet alle wesentlichen Dateien innerhalb des Zuständigkeitsbereiches, ausgenommen der Beschreibungsdatei und des Inventars selbst. Das Hauptinventar der Automatisierungslösung listet alle wesentlichen Dateien, welche direkt im Ordner der Automatisierungslösung, hier „L”, enthalten sind, ausgenommen der Dateien des Hauptinventars, des Metainventars und der bereichsübergreifenden VKT-Teile. Das Metainventar listet alle anderen Inventardateien und die bereichsübergreifenden VKT-Teile sowie die für diese Dateien ermittelten Hashwerte auf.
Das Hauptinventar muss von einem Mitglied der Haupteigentümergruppe signiert sein, hier „TeamO”. Jedes Inventar eines Zuständigkeitsbereiches muss von einem Mitglied des zuständigen Teams signiert sein, hier „TeamH” bzw. „TeamW”.
Das Metainventar hingegen ist nach den oben erklärten Regeln während einer Entwicklungsphase von einem Mitglied irgendeines dieser Teams zu signieren, während es zu einem besonderen Anlass wie zum Beispiel einer Versionsfreigabe oder Saftety-Zertifizierung aus organisatorischen Zwängen von einem Mitglied der Haupteigentümergruppe zu signieren ist, hier „TeamO”. Letzteres ließe sich auch in Form einer zweiten Signatur unter dem Metainventar realisieren, die dann Siegelsignatur genannt werden kann, denn die Automatisierungslösung wird damit in einem bestimmten Stand besonders gesiegelt.
In den 10 und 11 sind keine VKT-Teile eingezeichnet. Zwar sind in 11 die Beziehungen zwischen Dateien und ihren Hashwerten in den Inventaren für das Hauptinventar und die Inventare in den Zuständigkeitsbereichen dargestellt, jedoch fehlt dort zur besseren Übersichtlichkeit eine solche Darstellung der Beziehung für das Metainventar.
Sowohl die Beziehung des Metainventars zu von ihm durch Hashwert referenzierten Dateiinhalten als auch die bereichsübergreifenden VKT-Teile sind nun in der 12 dargestellt und zwar so wie sie gemäß der vierten Variante zur Aufteilung der VKT vorgeschlagen sind. Somit befinden sich Dateien mit VKT-Teilen, die mehrere Zuständigkeitsbereiche betreffen, innerhalb des obersten Ordners „L” der Automatisierungslösung. Allerdings sind in 12 im Vergleich zu statt zwei Zuständigkeitsbereichen die drei Zuständigkeitsbereiche „H”, „W” und „C” in einer beispielhaften Automatisierungslösung vorhanden. Die VKT-Teile, welche zu genau einem Zuständigkeitsbereich gehören, sind weiterhin nicht dargestellt. Sie werden aber wie die Dateien eines Zuständigkeitsbereiches innerhalb des Zuständigkeitsbereiches gespeichert und durch das Inventar des jeweiligen Zuständigkeitsbereiches gelistet, welches von einem Mitglied des Teams des Zuständigkeitsbereichs zu signieren ist.
Weiter oben ist bereits erklärt, dass das Metainventar alle anderen Inventare listet und zusätzlich diejenigen VKT-Teile, welche mehreren Zuständigkeitsbereichen zugeordnet sind. Diese sind hier im Beispiel vier VKT-Teile, die jeweils bereits selbst direkt signiert sind und diese Signatur selbst enthalten. Dieses soll mit einem kleinen Siegelsymbol in der Abbildung dargestellt sein.
Die Zuständigkeitsbereiche und die ihnen zugeordneten Team bringen als weiteren Vorteil mit sich, dass sich darauf basierend in einer zentralen Ablage für die Automatisierungslösung leicht Zugriffsregeln einstellen lassen, so dass sich Zuständigkeitsverletzungen bzw. Kompetenzüberschreitungen nicht nur erkennen, sondern auch verhindern lassen. Wenn die zentrale Ablage beispielsweise ein Netzwerklaufwerk ist, dann kann dort für die Ordner der einzelnen Zuständigkeitsbereiche eingestellt werden, dass nur Mitglieder des zugeordneten Teams in dem jeweiligen Ordner Änderungen vornehmen dürfen und nur die Haupteigentümergruppe weitere solche Ordner einrichten und löschen darf. Wenn die zentrale Ablage beispielsweise ein Versionskontrollsystem wie GIT ist, dann lassen sich im GIT-Repository an entsprechender Stelle der Ordner ebensolche Zugriffsregeln im Dateisystem des zentralen Systems einstellen und/oder in sogenannten Commit-Triggern von GIT Zugriffsüberprüfungen durchführen.
Aus dem in der 8 gezeigten Beispiel ist leicht ersichtlich, dass in dem gezeigten Ablauf der Schweißspezialist an anderen Objekten der Automatisierungslösung arbeitet als der Lackierspezialist. In der zentralen Ablage (System Z) können daher Zugriffsregeln im Dateisystem oder im Versionskontrollsystem durchgesetzt werden, dass nur Schweißspezialisten Änderungen im Zuständigkeitsbereich „Welding” vornehmen dürfen und nur Lackierspezialisten Änderungen im Zuständigkeitsbereich „Coating”. Als weitere Zugriffsregel kann in der zentralen Ablage vorteilhaft eingestellt sein, dass nur Mitglieder der Haupteigentümergruppe an Objekten des Hauptzuständigkeitsbereichs, also an Objekten der Automatisierungslösung oberhalb der Zuständigkeitsbereiche, Änderungen vornehmen dürfen.
Bei zeitlich länger dauernden Arbeiten an einer Automatisierungslösung, insbesondere bei deren Pflege über mehrere Jahre und verschiedene Versionen hinweg, kommt es vor, dass die zu einzelnen Teams oder Eigentümergruppen gehörenden Personen Aufgaben wechseln, zum Beispiel ein Team verlassen oder zu neu hinzukommen. Um zuverlässig jede Version einer Automatisierungslösung gemäß der zu ihrem Erstellungszeitpunkt geltenden Teammitgliedschaften prüfen zu können, sieht die Erfindung vor, dass jede Signatur mit ihrem Zeitpunkt der Erstellung ausgestattet wird und dieses optional sogar durch einen zusätzlich zur Signatur abgespeicherten kryptographischer Zeitstempel für spätere Prüfungen nachgewiesen wird. Das Software-Werkzeug verwendet erfindungsgemäß bei der Prüfung den Zeitpunkt der Signaturerstellung um bei der Prüfung den zu dem Zeitpunkt geltenden Stand der Team- und Gruppenmitgliedschaften des Signierenden in Betracht zu ziehen.
Es sind viele Varianten denkbar, wie das Software-Werkzeug die Information der zu einem Zeitpunkt geltenden Teammitgliedschaften in Erfahrung bringen kann. Zum Beispiel können Teammitgliedschaften in Form von (auch alten bereits abgelaufenen) Attributzertifikaten in einem Verzeichnisdienst wie einem LDAP-Server zu der Person des Signierenden hinterlegt sein. In einer besonders vorteilhaften Variante der Erfindung nimmt das Software-Werkzeug solche prüfbaren Nachweise der Teammitgliedschaft direkt in eine erweiterte Signatur mit auf – in Anlehnung an langzeitprüfbare Signaturen. Dann ist es nicht notwendig, bei einer späteren Prüfung die ehemals gültigen Mitgliedschaften zu ermitteln.
Bei einer Änderung an der Automatisierungslösung, welche nach den oben beschriebenen Schutzmaßnahmen eine neue Signatur eines oder mehrerer Inventare erfordert (auch des Metainventares) kann gemäß einer Variante im Rahmen der Erfindung z. B. auch nur eine Beschreibung der Veränderungen des Inventares neu signiert werden, anstelle beispielsweise das gesamte Inventare neu zu signieren und wobei diese Veränderung dabei eine kryptographisch starke Prüfsumme der vorherigen Version des Inventares enthält. Eine solche Veränderungsbeschreibung kann das Software-Werkzeug in der Automatisierungslösung zweckmäßig zusätzlich zum eigentlichen Inventar abspeichern. Mehrere solcher Änderungsbeschreibungen können z. B. auch kaskadiert werden, insbesondere indem eine nachfolgende Änderungsbeschreibung statt des vorherigen Inventares eine kryptographisch starke Prüfsumme der vorhergehenden Änderungsbeschreibung enthält und das Software-Werkzeug solchermaßen eine Sequenz von Änderungsbeschreibungen zusätzlich zum Inventar abspeichert. Diese Variante der Abspeicherung bedingt zwar höheren Rechenaufwand bei der Authentifizierung von Automatisierungslösungen. Sie hat aber gleichzeitig den Vorteil, dass Information für unveränderte Daten erhalten bleibt, d. h. insbesondere auch, wer sie ehemals erstellt oder zuletzt geändert hat.
Um unbefugte Manipulationen mittels der verschiedenen Inventare und Signaturen zu erkennen, wird erfindungsgemäß insbesondere bei jedem Verwenden einer Arbeitskopie bzw. Instanz der Automatisierungslösung bzw. Entwicklungsprojektdaten die Korrektheit bzw. Gültigkeit der Signaturen an den Inventaren kontrolliert bzw. verifiziert, insbesondere dahingehend, ob jede dieser Signaturen von einem Mitglied des jeweils zugeordneten Teams stammt. Das Software-Werkzeug, also die von einer Verarbeitungsvorrichtung des Entwicklungsumgebungssystems ausgeführte Entwicklungsumgebung, nimmt idealerweise diese Prüfung vor, zum Beispiel bei jedem Öffnen einer Arbeitskopie oder auf Anforderung des Benutzers. Hierzu muss das Software-Werkzeug so eingerichtet sein, dass es Signaturen zu Personen und Personen zu Teams zuordnen kann und die Prüfung nach einem bestimmten Ablauf vornimmt. Insbesondere benötigt das Software-Werkzeug Zugriff auf die den Personen bzw. Benutzern zugeordneten öffentlichen Verifikationsschlüssel. Der Ablauf der Gültigkeitskontrolle erfolgt vorteilhaft in den folgenden Schritten und jeweiligen Teilschritten, wobei bei einem negativen Ergebnis für einen der Schritte bzw. Teilschritte bereits eine unbefugte Manipulation entdeckt ist und nur bei ausschließlich positiven Ergebnissen für alle Schritte die Integrität und Authentizität der Automatisierungslösung festgestellt ist:

1. Prüfen der durch einen Haupteigentümer in der Automatisierungslösung hinterlegten Informationen 1.1. durch das Verifizieren der Signatur zu dem Hauptinventar und Prüfen, dass die Signatur von einem Mitglied des Teams stammt, das der Automatisierungslösung als Haupteigentümer zugeordnet ist, 1.2. durch das Prüfen des Vorhandenseins eines jeden im Inventar verzeichneten Objektes der Automatisierungslösung und 1.3. durch das Neuberechnen eines Hashwertes zu jedem im Inventar verzeichneten Objektes und das Vergleichen dieses neuberechneten Hashwertes mit dem im Inventar hinterlegten Hashwert.
2. Prüfen eines jeden Zuständigkeitsbereiches in der Automatisierungslösung 2.1. durch das Verifizieren der Signatur zu dem Inventar des Zuständigkeitsbereiches und Prüfen, dass die Signatur von einem Mitglied des Teams stammt, das dem Zuständigkeitsbereich als Eigentümer zugeordnet ist, 2.2. durch das Prüfen des Vorhandenseins eines jeden im Inventar verzeichneten Objektes des Zuständigkeitsbereiches und 2.3. durch das Neuberechnen eines Hashwertes zu jedem im Inventar verzeichneten Objektes und das Vergleichen dieses neuberechneten Hashwertes mit dem im Inventar hinterlegten Hashwert.

3. prüfen, dass alle relevanten Objekte innerhalb der Automatisierungslösung in dem zugehörigen Inventar verzeichnet sind, und also kein überzähliges oder ungeschütztes Objekt vorhanden ist.

Die oben beschriebenen Schritte lassen sich ohne Einschränkung für die Gültigkeit des Ergebnisses aber auch in anderer Reihenfolge oder auch ganz oder teilweise gleichzeitig durchführen. Ist beispielsweise eine besonders schnelle Prüfung gewünscht, können alle Schritte gleichzeitig ausgeführt werden, besonders Vorteilhaft sogar die Neuberechnung der Hashwerte zu mehreren Objekten der Automatisierungslösung gleichzeitig. Auch das Auslassen einiger Gültigkeitskontrollen ist im Einzelfall denkbar.
Für die Wirksamkeit des Manipulationsschutzes für die VKT ist es bei den Varianten drei und vier notwendig, dass das Software-Werkzeug so eingerichtet sind, dass es zusätzlich zu den bereits beschriebenen Schritten zur Prüfung der Integrität und Authentizität der Automatisierungslösung auch die Signaturen der direkt signierten VKT-Teile prüft und ob diese Signaturen jeweils von einer entsprechend zuständigen Person bzw. einem zuständigen Benutzer stammen, die bzw. der also in den jeweiligen Team Mitglied ist.
Zur Wirksamkeit des Manipulationsschutzes für die gesamte Automatisierungslösung muss das Software-Werkzeug so eingerichtet sein, dass die korrekte Signatur des Metainventars als zusätzlicher Schritt bei der Prüfung der Integrität und Authentizität einer Automatisierungslösung durchgeführt wird. Dies kann im Wesentlichen analog zu den Teilschritten des Schrittes 1 oder 2 erfolgen.
An dem beispielhaften Ablaufdiagramm aus 8 kann erklärt werden, dass anhand der Daten einer jeden Arbeitskopie bzw. Instanz der Automatisierungslösung geprüft werden kann, ob die in der Automatisierungslösung bestimmten Kompetenzen bzw. Zuständigkeiten eingehalten wurden. Zunächst trägt am Ende zum Zeitpunkt t8 das Inventar im Zuständigkeitsbereich „Welding” die Signatur des Schweißspezialisten und das Inventar im Zuständigkeitsbereich „Coating” die Signatur des Lackierspezialisten, obwohl beide und sogar konkurrierend Änderungen an derselben Automatisierungslösung durchgeführt haben. Die Korrektheit der Signaturen und die Zuständigkeit der Signierenden lässt sich an einer beliebigen Arbeitskopie von Version 3 auf einem beliebigen System R prüfen. Würde beispielsweise abweichend zu dem Ablauf nach 8 das System R.1 kein Schweißspezialist, sondern ein Roboterspezialist bedienen, dann würde später bei einer Überprüfung der Versionen 2 oder 3 anhand einer Arbeitskopie auf einem beliebigen System R auffallen, dass die Signatur am Inventar im Zuständigkeitsbereich „Welding” nicht von einem Schweißspezialisten stammt.
Die Ausführung von Prüfungsschritten für den Manipulationsschutz, wie zuvor beschrieben, kann insbesondere auf Arbeitsplatzrechnern anhand von Arbeitskopien der Automatisierungslösung erfolgen. Alternativ oder ergänzend können die Prüfschritte in der zentralen Ablage durchgeführt werden, beispielsweise immer dann wenn eine neue Version abgelegt werden soll. Diese Variante erscheint besonders dann vorteilhaft, wenn die zentrale Ablage zum Beispiel ein Speicher in einer sogenannten Cloud ist. Bei fehlgeschlagener Prüfung verweigert die zentrale Ablage sinnvollerweise die Annahme der neuen Version, so dass garantiert ist, dass nur integre und authentische Versionen jemals abgespeichert werden.

Claims

Datenorganisationsverfahren, bei dem eine gespeicherte oder zu speichernde Datenmenge gemäß einer ersten Struktur organisiert wird, wobei die Datenmenge nach inhaltsbezogenen Aspekten und/oder nach zugriffsrechtlichen Aspekten in Datenteilmengen unterteilt wird, dadurch gekennzeichnet, dass neben der ersten Struktur zusätzlich eine weitere Struktur vorgesehen ist, gemäß der die Datenmenge organisiert wird, wobei die Datenmenge nach Zuständigkeitsbereichen unterteilt wird, wobei jeder Zuständigkeitsbereich wenigstens eine Datenteilmenge gemäß der ersten Struktur umfasst, wobei jede Datenteilmenge zumindest eine Dateneinheit umfasst, und wobei jedem Zuständigkeitsbereich jeweils eine zuständige Benutzermenge zugeordnet wird, wobei die Benutzermenge zumindest einen Benutzer umfasst, und wobei eine bestimmte Dateneinheit nur von einem bestimmten Zuständigkeitsbereich und/oder wenigstens ein Benutzer von mehreren Benutzermengen umfasst wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass gemäß der weiteren Struktur zusätzlich ein Hauptzuständigkeitsbereich bereitgestellt und dieser jedem Zuständigkeitsbereich übergeordnet wird, so dass der Hauptzuständigkeitsbereich indirekt alle von den Zuständigkeitsbereichen umfassten Datenteil mengen umfasst, wobei der Hauptzuständigkeitsbereich zusätzlich aber auch jede Datenteilmenge der Datenmenge direkt umfasst, die von keinem Zuständigkeitsbereich umfasst wird, wobei jede Datenteilmenge zumindest eine Dateneinheit umfasst, und wobei dem Hauptzuständigkeitsbereich eine zuständige Hauptbenutzermenge zugeordnet wird, wobei die Hauptbenutzermenge zumindest einen Benutzer umfasst.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass dem Hauptzuständigkeitsbereich wenigstens eine erste Beschreibungsinformation zugeordnet wird, wobei die erste Beschreibungsinformation eine Identifikationsinformation des Hauptzuständigkeitsbereichs und/oder eine Identifikationsinformation der zuständigen Hauptbenutzermenge umfasst, und/oder dass jedem Zuständigkeitsbereich jeweils wenigstens eine zweite Beschreibungsinformation zugeordnet wird, wobei die zweite Beschreibungsinformation eine Identifikationsinformation des Zuständigkeitsbereichs, eine Identifikationsinformation des Hauptzuständigkeitsbereich und/oder eine Identifikationsinformation der zuständigen Benutzermenge umfasst.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass wenigstens eine Verknüpfung zwischen Dateneinheiten bereitgestellt wird, wobei zu der Verknüpfung eine Verknüpfungsinformation erzeugt wird, die eine Identifikationsinformation der Verknüpfung, eine Identifikationsinformation des Hauptzuständigkeitsbereichs und/oder eine Identifikationsinformation jedes an der Verknüpfung beteiligten Zuständigkeitsbereichs umfasst.
Verfahren nach dem vorherigen Anspruch, dadurch gekennzeichnet, – dass i) die Verknüpfungsinformation gemäß einer ersten Variante erzeugt wird, wobei jede Verknüpfungsinformation dem Hauptzuständigkeitsbereich zugeordnet wird und nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, – oder, dass die Verknüpfungsinformation gemäß einer zweiten Variante erzeugt wird, wobei die Verknüpfungsinformation a) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten nur von dem Hauptzuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder b) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von dem Hauptzuständigkeitsbereich und einem weiteren Zuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder c) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von unterschiedlichen Zuständigkeitsbereichen umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder d) einem Zuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten von diesem Zuständigkeitsbereich umfasst werden, wobei die diesem Zuständigkeitsbereich zugeordnete Benutzermenge für eine solche Verknüpfungsinformation zuständig ist, – oder, dass ii) die Verknüpfungsinformation gemäß einer dritten Variante erzeugt wird, wobei die Verknüpfungsinformation a) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten nur von dem Hauptzuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder b) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von dem Hauptzuständigkeitsbereich und einem weiteren Zuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder c) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von unterschiedlichen Zuständigkeitsbereichen umfasst werden, wobei die Hauptbenutzermenge oder eine Benutzerschnittmenge aus den diesen Zuständigkeitsbereichen jeweils zugeordneten Benutzermengen für eine solche Verknüpfungsinformation zuständig ist, oder d) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten von nur einem Zuständigkeitsbereich umfasst werden, wobei die Hauptbenutzermenge oder die diesem Zuständigkeitsbereich zugeordnete Benutzermenge für eine solche Verknüpfungsinformation zuständig ist, – oder, dass iii) die Verknüpfungsinformation gemäß einer vierten Variante erzeugt wird, wobei die Verknüpfungsinformation a) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten nur von dem Hauptzuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder b) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von dem Hauptzuständigkeitsbereich und einem weiteren Zuständigkeitsbereich umfasst werden, wobei nur die Hauptbenutzermenge für eine solche Verknüpfungsinformation zuständig ist, oder c) dem Hauptzuständigkeitsbereich zugeordnet wird, wenn die an der Verknüpfung beteiligten Dateneinheiten von unterschiedlichen Zuständigkeitsbereichen umfasst werden, wobei die Hauptbenutzermenge oder eine Benutzerschnittmenge aus den diesen Zuständigkeitsbereichen jeweils zugeordneten Benutzermengen für eine solche Verknüpfungsinformation zuständig ist, oder d) einem Zuständigkeitsbereich zugeordnet wird, wenn alle an der Verknüpfung beteiligten Dateneinheiten von diesem Zuständigkeitsbereich umfasst werden, wobei die diesem Zuständigkeitsbereich zugeordnete Benutzermenge für eine solche Verknüpfungsinformation zuständig ist.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass jeweils eine Prüfinformation ermittelt wird – für wenigstens eine dem Hauptzuständigkeitsbereich zugeordnete erste Beschreibungsinformation und/oder – bezüglich jedes Zuständigkeitsbereichs für jeweils wenigstens eine dem jeweiligen Zuständigkeitsbereich zugeordnete zweite Beschreibungsinformation und/oder – für im Wesentlichen jede von dem Hauptzuständigkeitsbereich direkt umfasste Dateneinheit und/oder – für jede dem Hauptzuständigkeitsbereich zugeordnete Verknüpfungsinformation gemäß der ersten oder zweiten Variante, wobei dem Hauptzuständigkeitsbereich ein Hauptinventar zugeordnet wird, das jede derartige Prüfinformation sowie zu jeder Prüfinformation eine Zeigerinformation auf die der jeweiligen Prüfinformation zugrundeliegende Beschreibungsinformation oder Verknüpfungsinformation oder Dateneinheit umfasst, und/oder dass jeweils eine Prüfinformation ermittelt wird – für im Wesentlichen jede von einem Zuständigkeitsbereich umfasste Dateneinheit und/oder – für jede einem Zuständigkeitsbereich zugeordnete Verknüpfungsinformation der zweiten oder vierten Variante, wobei jedem Zuständigkeitsbereich ein Inventar zugeordnet wird, das jede derartige Prüfinformation sowie zu jeder Prüfinformation eine Zeigerinformation auf die der jeweiligen Prüfinformation zugrundeliegende Verknüpfungsinformation oder Dateneinheit umfasst.
Verfahren nach dem vorherigen Anspruch, dadurch gekennzeichnet, dass jeweils eine eindeutige Prüfinformation ermittelt wird – für jedes einem jeweiligen Zuständigkeitsbereich zugeordnete Inventar, und/oder – für das dem Hauptzuständigkeitsbereich zugeordnete Inventar, und/oder – für jede dem Hauptzuständigkeitsbereich zugeordnete Verknüpfungsinformation gemäß der dritten oder vierten Variante, wobei dem Hauptzuständigkeitsbereich ein Metainventar zugeordnet wird, das jede derartige Prüfinformation sowie zu jeder Prüfinformation eine Zeigerinformation auf die der jeweiligen Prüfinformation zugrundeliegende Verknüpfungsinformation oder auf das der jeweiligen Prüfinformation zugrundeliegende Inventar oder Hauptinventar umfasst.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass wenigstens eine dem Hauptzuständigkeitsbereich zugeordnete Beschreibungsinformation und/oder Verknüpfungsinformation und/oder das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar und/oder Metainventar jeweils eine weitere von dem Hauptzuständigkeitsbereich umfasste Dateneinheit darstellt, und/oder dass wenigstens eine einem Zuständigkeitsbereich zugeordnete Beschreibungsinformation und/oder Verknüpfungsinformation und/oder das dem Zuständigkeitsbereich zugeordnete Inventar jeweils eine weitere von diesem Zuständigkeitsbereich umfasste Dateneinheit darstellt.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Datenmenge vorrangig gemäß der weiteren Struktur gespeichert wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass jedem Benutzer, der von wenigstens einer Benutzermenge umfasst ist, die einem Zuständigkeitsbereich zugeordnet ist, und/oder der von der Hauptbenutzermenge umfasst ist, die dem Hauptzuständigkeitsbereich zugeordnet ist, eine eindeutige Signaturinformation sowie eine dazu passende eindeutige Verifikationsinformation zugeordnet wird.
Verfahren nach dem vorherigen Anspruch, dadurch gekennzeichnet, dass bei einem Schreibzugriff auf eine Dateneinheit ein Signieren dieser Dateneinheit erfolgt, indem für diese zu speichernde Dateneinheit unter Einbeziehen der Signaturinformation, die dem den Schreibzugriff auslösenden Benutzer zugeordnet ist, eine Kontrollinformation ermittelt und dieser Dateneinheit zugeordnet wird.
Verfahren nach einem der zwei vorherigen Ansprüche, dadurch gekennzeichnet, dass bei einem Schreibzugriff auf eine Dateneinheit, für die eine Prüfsumme von einem Inventar, dem Hauptinventar oder dem Metainventar umfasst ist, ein Signieren der Dateneinheit derart erfolgt, dass – für diese zu speichernde Dateneinheit eine neue Prüfinformation ermittelt wird, – die von dem Inventar, dem Hauptinventar oder dem Metainventar für diese Dateneinheit umfasste Prüfinformation durch die neu ermittelte Prüfinformation ersetzt wird, und – stellvertretend für diese Dateneinheit stattdessen für das Inventar, das Hauptinventar oder das Metainventar, das die für diese Dateneinheit neu ermittelte Prüfinformation umfasst, unter Einbeziehen der Signaturinformation, die dem den Schreibzugriff auslösenden Benutzer zugeordnet ist, eine Kontrollinformation ermittelt und diesem Inventar, Hauptinventar oder Metainventar zugeordnet wird.
Verfahren nach einem der zwei vorherigen Ansprüche, dadurch gekennzeichnet, dass beim Signieren die Kontrollinformation unter zusätzlichem Einbeziehen einer Zeitinformation ermittelt wird.
Verfahren nach einem der drei vorherigen Ansprüche, dadurch gekennzeichnet, dass ausgelöst von einer Anforderung eines Benutzers oder von einem innerhalb einer vorbestimmbaren Zeitspanne stattfindenden ersten Lese- oder Schreibzugriff auf wenigstens eine Dateneinheit wenigstens eine Gültigkeitskontrolle durgeführt wird, wobei das positive oder negative Ergebnis der Gültigkeitskontrolle angezeigt wird.
Verfahren nach dem vorherigen Anspruch, dadurch gekennzeichnet, dass für das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar die Gültigkeit der dem Hauptinventar zugeordneten Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört, und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar die Gültigkeit jeder von dem Hauptinventar umfassten Zeigerinformation kontrolliert wird, indem das Vorhandensein der durch die jeweilige Zeigerinformation angegebenen Dateneinheit kontrolliert wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die durch die Zeigerinformation angegebene Dateneinheit vorhanden ist, und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Hauptinventar die Gültigkeit jeder von dem Hauptinventar umfassten Prüfinformation kontrolliert wird, indem für die durch die jeweilige Zeigerinformation angegebene Dateneinheit die Prüfinformation erneut berechnet wird und die erneut berechnete Prüfinformation mit der im Hauptinventar enthaltenen Prüfinformation verglichen wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die erneut berechnete Prüfinformation mit der im Hauptinventar enthaltenen Prüfinformation übereinstimmt.
Verfahren nach einem der zwei vorherigen Ansprüche, dadurch gekennzeichnet, dass für das dem Hauptzuständigkeitsbereich zugeordnete Metainventar die Gültigkeit der dem Metainventar zugeordneten Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu einer Benutzermenge gehört, die einem der Zuständigkeitsbereiche zugeordnet ist, und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Metainventar die Gültigkeit jeder von dem Metainventar umfassten Zeigerinformation kontrolliert wird, indem das Vorhandensein der durch die jeweilige Zeigerinformation angegebenen Dateneinheit kontrolliert wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die durch die Zeigerinformation angegebene Dateneinheit vorhanden ist, und/oder dass für das dem Hauptzuständigkeitsbereich zugeordnete Metainventar die Gültigkeit jeder von dem Metainventar umfassten Prüfinformation kontrolliert wird, indem für die durch die jeweilige Zeigerinformation angegebene Dateneinheit die Prüfinformation erneut berechnet wird und die erneut berechnete Prüfinformation mit der im Metainventar enthaltenen Prüfinformation verglichen wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die erneut berechnete Prüfinformation mit der im Metainventar enthaltenen Prüfinformation übereinstimmt.
Verfahren nach einem der drei vorherigen Ansprüche, dadurch gekennzeichnet, dass für jedes einem Zuständigkeitsbereich zugeordnete Inventar die Gültigkeit der dem Inventar zugeordneten Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu der Benutzermenge gehört, die demselben Zuständigkeitsbereich zugeordnet ist, dem auch dieses Inventar zugeordnet ist, und/oder dass für jedes einem Zuständigkeitsbereich zugeordnete Inventar die Gültigkeit jeder von dem Inventar umfassten Zeigerinformation kontrolliert wird, indem das Vorhandensein der durch die jeweilige Zeigerinformation angegebenen Dateneinheit kontrolliert wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die durch die Zeigerinformation angegebene Dateneinheit vorhanden ist, und/oder dass für jedes einem Zuständigkeitsbereich zugeordnete Inventar die Gültigkeit jeder von dem Inventar umfassten Prüfinformation kontrolliert wird, indem für die durch die jeweilige Zeigerinformation angegebene Dateneinheit die Prüfinformation erneut berechnet wird und die erneut berechnete Prüfinformation mit der in dem Inventar enthaltenen Prüfinformation verglichen wird, wobei ein positives Ergebnis nur erzielbar ist, wenn die erneut berechnete Prüfinformation mit der in dem Inventar enthaltenen Prüfinformation übereinstimmt.
Verfahren nach einem der vier vorherigen Ansprüche, dadurch gekennzeichnet, dass für jede weitere von dem Hauptzuständigkeitsbereich umfasste Dateneinheit, welche eine zugeordnete Kontrollinformation besitzt, die Gültigkeit dieser Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu einer Benutzerschnittmenge gehört, die für diese Dateneinheit zuständig ist, sofern diese Dateneinheit eine Verknüpfungsinformation gemäß der dritten oder vierten Variante ist, und/oder dass für jede weitere von einem jeweiligen Zuständigkeitsbereich umfasste Dateneinheit, welche eine zugeordnete Kontrollinformation besitzt, die Gültigkeit dieser Kontrollinformation unter Einbeziehen wenigstens einer Verifikationsinformation kontrolliert wird, wobei ein positives Ergebnis nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu der Hauptbenutzermenge gehört oder der zu der Benutzermenge gehört, die demselben Zuständigkeitsbereich zugeordnet ist, der auch diese Dateneinheit umfasst.
Verfahren nach einem der fünf vorherigen Ansprüche, dadurch gekennzeichnet, dass beim Kontrollieren der Gültigkeit einer Kontrollinformation, die unter zusätzlichem Einbeziehen einer Zeitinformation ermittelt wurde, ein positives Ergebnis der Gültigkeitskontrolle nur mittels einer Verifikationsinformation erzielbar ist, die einem Benutzer zugeordnet ist, der zu dem in der Zeitinformation genannten Zeitpunkt – zu der Hauptbenutzermenge gehörte, oder – zu einer Benutzermenge gehörte, die einem der Zuständigkeitsbereiche zugeordnet ist, sofern diese Kontrollinformation dem Metainventar zugeordnet ist, oder – der zu der Benutzermenge gehörte, die demselben Zuständigkeitsbereich zugeordnet ist, dem auch das Inventar zugeordnet ist, dem diese Kontrollinformation zugeordnet ist, oder – der zu einer Benutzerschnittmenge gehörte, die für die Dateneinheit zuständig ist, der diese Kontrollinformation zugeordnet ist, sofern diese Dateneinheit eine Verknüpfungsinformation gemäß der dritten oder vierten Variante ist, oder – der zu der Benutzermenge gehörte, die demselben Zuständigkeitsbereich zugeordnet ist, der auch die Dateneinheit umfasst, der diese Kontrollinformation zugeordnet ist.
Verfahren nach einem der sechs vorherigen Ansprüche, dadurch gekennzeichnet, dass überprüft wird, ob mehr Dateneinheiten enthalten sind, als in irgendeinem Inventar vorhanden sind.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass bei einem Schreibzugriff auf eine Datenteilmenge oder Dateneinheit, eine neue Version dieser Datenteilmenge oder Dateneinheit gespeichert wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Datenmenge Entwicklungsprojektdaten, bevorzugt Daten eines Softwareentwicklungsprojekts und insbesondere Programmcode und/oder Konfigurationsdaten und/oder Parametrierungsdaten für eine Automatisierungsanlage, enthält.
Entwicklungsumgebungssystem, das zur Durchführung des Datenorganisationsverfahren gemäß einem der vorherigen Ansprüche ausgebildet ist, umfassend – eine Speichervorrichtung, – eine Eingabe-/Ausgabevorrichtung, – eine Verarbeitungsvorrichtung, wobei in der Speichervorrichtung eine Datenmenge gespeichert ist, die Entwicklungsprojektdaten enthält, und wobei in der Speichervorrichtung eine Entwicklungsumgebung gespeichert ist, wobei die Entwicklungsumgebung bei Ausführung durch die Verarbeitungsvorrichtung das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung entsprechend dem Datenorganisationsverfahren und das Bereitstellen einer Benutzerschnittstelle zum Bearbeiten des Entwicklungsprojekts an der Eingabe-/Ausgabevorrichtung steuert.
Entwicklungsumgebungssystem nach dem vorherigen Anspruch, welches mehrere Entwicklungsumgebungsgeräte umfasst, die jeweils eine Speichervorrichtung, eine Eingabe-/Ausgabevorrichtung und eine Verarbeitungsvorrichtung umfassen, und die jeweils eine Kommunikationsvorrichtung umfassen und mittels dieser zumindest zeitweise an ein Netzwerk angekoppelt sind und miteinander kommunizieren können, wobei ein erstes der Entwicklungsumgebungsgeräte als Entwicklungsumgebungsserver fungiert, in dessen Speichervorrichtung die Entwicklungsprojektdaten zentral gespeichert sind, und wobei wenigstens ein weiteres der Entwicklungsumgebungsgeräte als Entwicklungsumgebungsclient fungiert und auf die zentral gespeicherten Entwicklungsprojektdaten zugreifen kann.
Entwicklungsumgebungssystem nach dem vorherigen Anspruch, wobei in der Speichervorrichtung des Entwicklungsumgebungsservers die Entwicklungsumgebung zentral gespeichert ist, und wobei der Entwicklungsumgebungsclient auf die zentral gespeicherte Entwicklungsumgebung zugreifen kann, wobei die Entwicklungsumgebung eine durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsservers ausführbare Entwicklungsumgebungsservereinheit und eine durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsclients ausführbare Entwicklungsumgebungsclienteinheit umfasst, wobei die Entwicklungsumgebungsservereinheit und die Entwicklungsumgebungsclienteinheit zusammenwirken können, wobei die Entwicklungsumgebungsservereinheit bei Ausführung durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsservers wenigstens das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung des Entwicklungsumgebungsservers steuert, und wobei die Entwicklungsumgebungsclienteinheit bei Ausführung durch die Verarbeitungsvorrichtung des Entwicklungsumgebungsclients wenigstens das Bereitstellen der Benutzerschnittstelle zum Bearbeiten des Entwicklungsprojekts an der Eingabe-/Ausgabevorrichtung des Entwicklungsumgebungsclients steuert.
Entwicklungsumgebungssystem nach einem der vorherigen Ansprüche 23 bis 25, wobei die Entwicklungsumgebung das Speichern der Entwicklungsprojektdaten in der Speichervorrichtung derart steuert, dass vor dem Einschreiben einer von den Entwicklungsprojektdaten umfassten Dateneinheit in die Speichervorrichtung wenigstens eine Gültigkeitskontrolle entsprechend dem Datenorganisationsverfahren erfolgt; wobei das Einschreiben der Dateneinheit in die Speichervorrichtung nur bei einem positiven Ergebnis der Gültigkeitskontrolle erfolgt.