Verfahren, System und Simulations- bzw. Analysemodell zur
Datenverarbeitung
Technisches Gebiet
Die vorliegende Erfindung betrifft ein Verfahren, ein System und ein Simulations- bzw. Analysemodell zur Datenverarbeitung, insbesondere zur Vorverarbeitung von Daten vor der Bereitstellung der Daten an einen Nutzer der Daten zur Weiterverarbeitung der Daten bei dem Nutzer der Daten. Insbesondere betrifft die Erfindung ein computer-basiertes Verfahren und Simulations- bzw. Analysemodell zur Datenverarbeitung.
Hintergrund der Technik
Im Bereich der Informationstechnologie kommt oft vor, dass ein Auftraggeber und ein Auftragnehmer gemeinsam an einem komplexen eingebetteten System arbeiten. Dieses System kann mehrere Prozessoren aufweisen, für die sowohl der Auftraggeber als auch der Auftragnehmer Softwarekomponenten entwickeln. Die Verteilung der Software kann dabei entlang der Prozessorgrenzen definiert sein. Das Gesamtsystem erbringt nur gemeinsam die geforderte Funktionalität, wobei es wesentlich ist, dass die Interaktion der Softwarekomponenten von Auftraggeber und Auftragnehmer Echtzeitanforderungen einhält.
Zusammenfassung der Erfindung
Zum Nachweis der geforderten Echtzeitfähigkeit soll nun sowohl Simulation als auch Analyse eingesetzt werden. Weder der Auftraggeber noch der Auftragnehmer haben dabei ein Interesse daran, mehr als unbedingt notwendig über ihr Teilsystem preis zu geben. Vorzugsweise ist die Aufgabe der vorliegende Erfindung, die für die Analyse bzw. Simulation des Gesamtsystems notwendigen Details zu kapseln und zu verbergen, so dass außer den beabsichtigten Ergebnissen keine weiteren Informationen über das Teilsystem der jeweils anderen Partei preisgegeben werden.
Diese Aufgabe kann durch den Gegenstand in den unabhängigen Ansprüchen gelöst werden.
Die vorliegende Erfindung löst die oben genannte Aufgabe und stellt ein computergestütztes Verfahren zur Vorverarbeitung von Daten vor Bereitstellung der Daten an einen Nutzer der
Daten zur Weiterverarbeitung der Daten bei dem Nutzer der Daten bereit. Das Verfahren weist die Schritte auf: a) Auswählen, durch den Daten-Bereitsteller, mindestens eines Teils der Daten aus den gesamten dem Nutzer zur Weiterverarbeitung bereitzustellenden Daten abhängig von mindestens einem vorgegebenen Kriterium, das der Nutzer erfüllt; b) Nichtsichtbarmachen der ausgewählten Daten derart, dass die ausgewählten Daten trotz der NichtSichtbarmachung für den
Nutzer nach deren Bereitstellung weiterverarbeitbar und/oder ausführbar bleiben.
Die Daten stellen vorzugsweise eine oder mehrere Software-Komponenten dar. Die Daten sind vorzugsweise eine oder mehrere Software-Komponenten eines komplexen eingebetteten Systems. Die Schnittstellen der versteckten Software-Komponente kann für den Nutzer sichtbar bleiben.
Der Daten-Nutzer überprüft vorzugsweise die Echtzeitfähigkeit der einen oder mehreren Software-Komponenten.
Der Daten-Bereitsteller und der Daten-Nutzer sind somit in der Lage, jeweils nur einen Teil des komplexen eingebetteten Systems bereitstellen, aber durch Interaktion der einzelnen Teile das komplette System zu nutzen.
Durch das Nichtsichtbarmachen der ausgewählten Daten in Schritt b) wird dem Daten-Nutzer ermöglicht, durch Ausführen der Gesamtdaten Ergebnisse zu erzielen, ohne die Daten in ihrer Gesamtheit einsehen zu können.
Als Nutzerkriterium kann ein Lizenzdongle verwendet werden.
Die Daten stellen vorzugsweise ein Simulations- und/oder Analysemodell dar. Die ausgewählten Daten können vorzugsweise ein oder mehrere Taskmodelle darstellen.
Die ausgewählten Daten werden vorzugsweise durch Verschlüsselung nichtsichtbar gemacht.
Die Schritte a) und b) können ebenfalls beim Daten-Nutzer durchgeführt werden, wobei der ursprüngliche Daten-Nutzer vorzugsweise nun als Daten-Bereitsteller anzusehen ist und der ursprüngliche Daten-Bereitsteller als Daten-Nutzer.
Diese Iteration kann mehrmals wiederholt werden.
Die Daten liegen vorzugsweise in XML, UML, C, C++, Matlab/Simulink-Script, Python, Pascal, Fortran oder Basic Format vor.
Nach einem weiteren Aspekt der vorliegenden Erfindung wird ein Computersystem zur Durchführung des Verfahrens zur Vorverarbeitung von Daten vor Bereitstellung der Daten an einen Nutzer der Daten zur Weiterverarbeitung der Daten bei dem Nutzer der Daten bereitgestellt. Das Computersystem weist eine Auswahleinrichtung auf zum Auswählen durch den Daten-Bereitsteller mindestens eines Teils der Daten aus den gesamten dem Nutzer zur Weiterverarbeitung bereitzustellenden Daten abhängig von mindestens einem vorgegebenen Kriterium, das der Nutzer erfüllt. Ferner weist das Computersystem eine Einheit auf zum Nichtsichtbarmachen der ausgewählten Daten derart, dass die ausgewählten Daten trotz der NichtSichtbarmachung für den Nutzer nach deren Bereitstellung weiterverarbeitbar bzw. ausführbar bleiben.
Nach einem weiteren Aspekt der vorliegenden Erfindung wird ein Computerprogramm zum Durchführen des oben beschriebenen Verfahrens bereitgestellt.
Nach einem weiteren Aspekt der vorliegenden Erfindung wird ein computergestütztes Verfahren zur Simulation und/oder Analyse eines Gesamtsystems, das mindestens zwei Teile aufweist, bereitgestellt. Das Verfahren weist die Schritte auf: Empfangen von Daten, die einen oder mehrere der Teile des Gesamtsystems darstellen, von einem oder mehreren Daten-Bereitstellern, wobei die Daten von mindestens einem Daten-Bereitsteller gemäß einem Verfahren nach dem oben beschriebenem Verfahren vorverarbeitet sind; Zusammenfügen, durch den Daten-Nutzer, der empfangenen Daten, um das Gesamtsystem zu bilden; und Analyse und/oder Simulation des Gesamtsystems durch den Daten-Nutzer.
Der Daten-Nutzer zur Bildung des Gesamtsystems in Schritt b) fügt vorzugsweise den empfangenen Daten noch eigene Daten hinzu, die einen weiteren Teil des Gesamtsystems darstellen.
Die Daten können eine oder mehrere Software-Komponenten darstellen. Die Daten sind vorzugsweise eine oder mehrere Software-Komponenten eines komplexen eingebetteten Systems. Die Schnittstellen der versteckten Software-Komponente bleiben vorzugsweise für den Nutzer sichtbar.
Die Daten stellen vorzugsweise ein Simulations- und/oder Analysemodell dar. Die ausgewählten Daten stellen vorzugsweise ein oder mehrere Taskmodelle dar.
Nach einem weiteren Aspekt der vorliegenden Erfindung wird ein Chip mit einem Programm zur Durchführung des oben beschriebenen Verfahrens bereitgestellt.
Nach einem noch weiteren Aspekt der vorliegenden Erfindung wird ein digitales Speichermedium mit einem Programm zur Durchführung des oben beschriebenen Verfahrens bereitgestellt.
Nach einem noch weiteren Aspekt der vorliegenden Erfindung wird ein Simulations- und/oder Analysemodell bereitgestellt, das mit einem ersten Datenobjekt, das den Zugang zu den weiteren Datenobjekten steuert, einem zweiten Datenobjekt, das die äußere Schnittstelle des Simulations- und/oder Analysemodells bildet, einem dritten Datenobjekt, das die Inhalte des Simulations- und/oder Analysemodells als weiterverarbeitbare Daten enthält, und einem vierten Datenobjekt versehen ist, das das Simulations- und/oder Analysemodell als vorbereitete ausführbare Simulation enthält.
Das erste Datenobjekt steuert vorzugsweise den Zugang des Benutzers des Simulations- und/oder Analysemodells zu den Schnittstelleninformationen des zweiten Datenobjekts, zu den weiterverarbeitbaren Daten des dritten Datenobjekt und zu der vorbereiteten ausführbaren Simulation des vierten Datenobjekts unter Berücksichtigung vorgegebener Zugangsberechtigungsinformationen.
Die vorgegebenen Zugangsberechtigungsinformationen in dem ersten Datenobjekt können auf einem Lizenzdongle gespeichert werden.
Vorzugsweise ist mindestens eine der Zugangsberechtigungsinformationen der weiterverarbeitbaren bzw. ausfuhrbaren Daten des dritten Datenobjekts und der ausführbaren Daten des vierten Datenobjekts verschlüsselt.
Das erste Datenobjekt verweigert vorzugsweise den Zugang des Benutzers zu den weiterverarbeitbaren Daten des dritten Datenobjekts, aber erlaubt den Zugang des Benutzers zu der vorbereiteten ausführbaren Simulation des vierten Datenobjekts, wodurch das Simulations- und/oder Analysemodell für den Benutzer nicht einseh- und/oder weiterverarbeitbar aber ausführbar gemacht wird.
Vorzugsweise beschreibt zumindest ein Teil der weiterverarbeitbaren Daten des dritten Datenobjekts das dynamische Zeitverhalten des Simulations- und/oder Analysemodells.
Die weiterverarbeitbaren Daten des dritten Datenobjekts können einen Quellcode aufweisen und die vorbereitete ausführbare Simulation des vierten Datenobjekts kann durch die Erzeugung eines Simulationsmodells generiert werden, wie beispielsweise in WO 2007/051634 A2 beschrieben.
Der Quellcode des dritten Datenobjekts liegt vorzugsweise in XML, UML, C, C++, Matlab/Simulink-Script, Python, Pascal, Fortran oder Basic Format vor.
Die ausfuhrbaren Daten des vierten Datenobjekts können zum Beispiel in einer Zwischendarstellung oder in vorkompilierter Form vorliegen.
Die vorbereitete ausführbare Simulation des vierten Datenobjekts kann in einer Softwareumgebung des Benutzers in ein ausführbares Gesamtmodell eingebunden werden.
Das Simulations- und/oder Analysemodell bildet vorzugsweise einen hierarchisch geordneten Teil eines übergeordneten Simulations- und/oder Analysemodells. Das Simulations- und/oder Analysemodell bildet vorzugsweise ein Modell oder Teilmodell eines eingebetteten Systems.
Vorzugsweise wird zumindest ein Teil der Inhalte des Simulations- und/oder Analysemodells als weiterverarbeitbare Daten des dritten Datenobjekts und der ausführbaren Daten des vierten Datenobjekts zumindest einem Task eines Steuergerätes zugeordnet.
Das Simulations- und/oder Analysemodell kann zur Echtzeitanalyse eingesetzt wird.
Gegenüber Digital Rights Management (DRM), das auch die Verschlüsselung für einen bestimmten Personenkreis (Eigentümer lizenzierter Abspielgeräte) als auch die maschinelle Weiterverarbeitung vorsieht, koppelt das Verfahren nach der vorliegenden Erfindung eigene Inhalte des Benutzers mit den verschlüsselten Inhalten, die dadurch für bei der Verschlüsselung nicht angedachte Umgebungen und Simulationen verwendbar sind.
Der Standard AUTOSAR sieht den Austausch von XML-Dateien vor, die Teile, Module und ganze Systeme beschreiben. Dabei gibt der Absender aber immer alle Informationen über seine Komponente preis und kann die Weitergabe oder den Verwendungszweck auch nicht einschränken.
Detaillierte Beschreibung
Nachfolgend wird die Erfindung mit bevorzugten Ausfuhrungsformen in Detail beschrieben.
Einige Begriffe zur Beschreibung der Erfindung werden hier wie folgt erläutet:
• Ein Projekt exportieren
Der Export ist ein besonderer Vorgang, der aus einem Projekt bei einer Partei 1 eine spezielle Beschreibung erzeugt, die bei einer Partei 2 wiederum importiert werden kann. Die von Partei 1 als hidden markierten Teile des Projektes sind bei Partei 1 vollständig sichtbar, bei Partei 2 dagegen nur als Black Box. Partei 2 kann zwar eine Analyse oder Simulation des
Gesamtprojektes durchfuhren, sieht aber keine Details innerhalb der von Partei 1 als hidden markierten Teile des Projekts.
• Ein Projekt importieren
Der Import eines Projektes erfolgt in einem Werkzeug, das daraus ein simulierbares oder analysierbares Projekt erzeugt. Die vom Absender als hidden markierten Teile sind als Black Box dann zwar sichtbar und verwendbar, aber nicht einsehbar.
• hidden
Dies bedeutet, dass eine Komponente als Black Box sichtbar ist und in einer Simulation oder Analyse auch verwendet werden kann. Ein Hineinsehen, also ein Erkennen von Details des Innenlebens ist aber weder in der Projektansicht noch in den Simulations- oder Analyseergebnissen möglich.
• Black Box
Ein schwarzer Kasten, der eine Schnittstellendefinition besitzt, mit der er mit dem restlichen System verbunden werden kann. Dazu gehört auch ein (verstecktes) Simulations- oder Analysemodell, das verwendet werden kann. Innere Details der Black Box sind nicht sichtbar.
• beabsichtigter Empfanger
Beim Exportieren eines Projektes kann der Anwender auswählen, für welche Empfänger ein als hidden markiertes Element verwendbar sein soll. Nur diese Anwender können das importierte Projekt in einer Simulation oder Analyse verwenden. Die Empfangerliste von Elementen, die der Anwender bereits als hidden empfangen (importiert) hat, kann nicht mehr geändert (insbesondere nicht ergänzt) werden.
Als Empfanger kann eine einzelne Installation eines Werkzeugs oder ein Lizenzdongle angegeben werden. Die einzelne Installation entspricht einem personalisierten Empfänger
während die Bindung an den Lizenzdongle insbesondere im Falle einer Netzwerklizenz einem kompletten Unternehmen entspricht.
Um einen Empfänger für einen Exportvorgang auswählen zu können, muss der Empfänger einen entsprechenden kryptographischen Schlüssel erzeugen und an den Absender senden. Der Absender muss diesen Schlüssel entsprechend in sein System aufnehmen. Die Beziehungen zwischen Absendern und Empfängern bilden ein Netz von Vertrauensbeziehungen, das mit dem Network of Trust von PGP/GnuPG verglichen werden kann.
• PGP/GnuPG
Ein Quasi- Standard zur asymmetrischen Verschlüsselung von E-Mail und anderen Dokumenten, die nur von beabsichtigten Empfängern wieder entschlüsselt werden können.
• Verschlüsselung
Im Kontext dieses Dokuments bedeutet Verschlüsselung immer den Einsatz anerkannter kryptographischer Verfahren. Dabei können asymmetrische Algorithmen (DSA, RSA), symmetrische Algorithmen (AES) und Hash-Algorithmen (SHA) zum Einsatz kommen. Die Nennung konkreter Verfahren erfolgt stets vorbehaltlich einer lizenztechnischen Prüfung.
Das Verfahren nach der vorliegenden Erfindung wird anhand beispielhafter Ausführungsform beschrieben.
Schritt 1 : Beim Auftragnehmer
Das Gesamtsystem wird durch den Auftragnehmer erstellt. Es wird hierzu ein Projekt definiert, das die geforderten Prozessoren und ihre Verschattung enthält. Zusätzlich werden Taskmodelle für seinen Teil der zu entwickelnden Softwarekomponenten definiert. Auch für die Softwarekomponenten des Auftraggebers werden Taskmodelle entsprechend der Spezifikation in der Ausschreibung erstellt. Das Zusammenspiel der Softwarekomponenten und deren Echtzeiteigenschaften kann auf der Seite der Auftragnehmer durch geeignete Szenarien getestet werden.
Im nächsten Schritt markiert der Auftragnehmer die Taskmodelle seiner Softwarekomponenten als hidden und exportiert das Projekt. Die dabei erzeugte Datei enthält alle nicht als hidden markierten Teile offen sichtbar und die als hidden markierten Teile in einer verschlüsselten Form, die nur der beabsichtigte Empfanger verarbeiten kann. Diese Datei wird dann vorzugsweise von dem Auftraggeber an den Auftragnehmer übertragen.
Schritt 2: Beim Auftraggeber
Der Auftraggeber importiert die übersandte Datei in sein Werkzeug. Die Teile des Systems, die nicht als hidden markiert wurden, sind für ihn genauso sichtbar und editierbar, als wenn er sie selbst im Projekt eingegeben hätte. Teile, die als hidden markiert wurden und für die er als berechtigter Empfänger angegeben wurde, sind als Black Box sichtbar. Dabei sind diese Teile auf ihre Schnittstellendefinitionen reduziert. Die Simulation oder Analyse ist durch ein hinterlegtes Modell möglich, das aber nicht weiter einsehbar ist.
Importiert jemand die übersandte Datei, der nicht als berechtigter Empfänger angegeben wurde, so sind die vom Auftragnehmer als hidden markierten Teile fiir ihn weder sichtbar noch in einer Simulation oder Analyse verwendbar.
Der Auftraggeber kann nun das System untersuchen. Jeden Teil, auch die als hidden markierte Teile, kann er durch eigene Taskmodelle beliebigen Abstraktionsgrades ersetzen. Sinnvollerweise verfeinert er die seinen Systemkomponenten entsprechenden Systemteile durch genauere Taskmodelle. Die korrekte Funktion des Projektes kann er anschließend durch Simulation oder Analyse überprüfen.
Die so verfeinerten Teile werden anschließend als hidden markiert. Ein Export des Projektes durch den Auftraggeber erfolgt sinnvollerweise in einer Version, die bis auf die Verfeinerung der von ihm als hidden markierten Teile der zuvor importierten Version entspricht. Das exportierte Projekt sendet der Auftraggeber an den Auftragnehmer zurück.
Schritt 3: Zurück beim Auftragnehmer
Der Auftragnehmer lädt erst das Projekt, das ursprünglich exportiert wurde, und importiert hier die vom Auftraggeber zurückgesandte Datei. Durch Differenzbildung der Versionen erkennt das Werkzeug, welche Änderungen vom Auftraggeber vorgenommen wurden und übernimmt diese Teile in das Projekt. Dabei werden Taskmodelle durch Black Boxes ersetzt, die als hidden markiert wurden. Auch andere Verfeinerungen, die nicht als hidden markiert wurden, werden übernommen.
Der Auftragnehmer fuhrt eine Simulation oder Analyse des modifizierten Projektes durch und kann so die Echtzeitfähigkeit des Gesamtsystems beurteilen.
Die Teile, die der Auftragnehmer in Schritt 1 als hidden markiert hat, sind für den ursprünglichen Urheber nun wieder sichtbar. Details sind sichtbar und können bewertet und geändert werden.
Schritt 4: Eine erneute Iteration
Der Ablauf der Schritte 1-3 kann nun erneut beginnen. Jeder Teilnehmer verfeinert seine Taskmodelle, markiert die vertraulichen Komponenten als hidden und exportiert das Projekt für den Partner. Dieser kann die Änderungen dann wiederum im Kontext seiner Komponenten bewerten.
Beispiele
Einbettung der Daten
Nachfolgend wird die vorliegende Erfindung anhand eines beispielhaften Projektes beschrieben. Aktuell sind solche Projekte in XML kodiert. Eine Erweiterung um Anteile, die als hidden markiert sind, könnte wie folgt aussehen:
<model> <submodel name="controlloop"> <interface>
<connection> ... </connection> </interface> όmplementation mode="hidden"> <receivers> ... CDATA ... </receivers>
<data id="3"> ... CDATA ... </data> <data id="4"> ... CDATA ... </data> </implementation> </submodel> <submodel name="basepart">
<interface>
<connection> ... </connection> </interface>
<implementation mode="visible" type="c"> <file>src/a.c</file>
<task name="Processlrf>
<entry>src/a . c/mainFunction</entry> </task>
</implementation> </submodel>
<model>
Gezeigt ist ein Modell, das aus zwei Teilmodellen besteht. Das Teilmodell mit dem Namen „controlloop" ist nach der beschriebenen Erfindung nicht-sichtbar. Das Teilmodell mit dem
Namen „basepart" ist für alle Datennutzer sichtbar. Im nicht-sichtbar gemachten Teilmodell entsprechen das XML-Tag <connection> dem zweiten Datenobjekt, das die äußere Schnittstelle des Teil-Simulationsmodells bildet, das XML-Tag <receivers> dem ersten Datenobjekt, das den
Zugang zu den weiteren Datenobjekten steuert. Das XML-Tag <data> mit der ID 3 entspricht dem dritten Datenobjekt, das für berechtigte Benutzer die Inhalte des Teil-Simulationsmodells als weiterverarbeitbare Daten enthält, und das Tag <data> mit der ID 4 entspricht dem vierten
Datenobjekt, das für berechtigte Nutzer das Teil-Simulationsmodell als vorbereitete ausführbare
Simulation enthält. Auf diese Weise kann der Entwickler des Teilmodells „controlloop" das fertige Teilmodell dem Entwickler des Teilmodells „basepart" zum Testen des Gesamtsystems in einer Simulations- und Analyseumgebung bereitstellen, ohne geheimes Fachwissen (zum
Beispiel Regelalgorithmen für einen charakeristischen Motorenklang) preiszugeben.
Das Verstecken kann theoretisch auf jeder Hierarchieebene erfolgen. Beim Entpacken des verschlüsselten Datenstroms ergeben sich wieder XML- Strukturen, die erneut geparst werden.
Auswertung der Daten
Beim Import des Objektes wird ein als hidden markiertes Element nur anhand seines Typs, seines Namens und seiner Interfacebeschreibung dargestellt. Erst für die Analyse oder Simulation wird auf die verschlüsselten Daten zugegriffen.
Der Anwender kann keine Attribute der erhalten Daten ändern. So bleibt das verschlüsselte Modell konsistent mit dem Rest des Systems. Speichert der Anwender so ein Projekt ab, so wird das Modell weiterhin verschlüsselt abgelegt.
Verschlüsselung der Daten
Für die Verschlüsselung werden Standardverfahren eingesetzt. Typischerweise werden die eigentlich zu schützenden Daten mit einen zufallig erzeugten Schlüssel verschlüsselt. Das Chiffrat bildet die Daten im oben beschriebenen Tag <data>. Der Schlüssel selbst wird mit dem öffentlichen Schlüssel des Empfangers gemäß einem asymmetrischen Verschlüsselungsverfahren kodiert. Dies erfolgt für jeden Empfänger einzeln. Die Liste des so für jeden Empfanger chiffrierten Schlüssels der zu schützenden Daten bildet den Inhalt des oben genannten Tags <receivers>.
Das verschlüsselte Modell und die Liste der chiffrierten Schlüssel werden als Datensatz in das umgebende Datenformat eingebettet.
Ein Zugriff durch den Anwender auf die entschlüsselten Daten darf nicht möglich sein. Das Werkzeug muss die entsprechenden Maßnahmen treffen.
Die Beschreibung des Systems im exportierten Zustand muss einen Sinn ergeben. Dies bedeutet im Wesentlichen eine maschinelle Verarbeitbarkeit, die sich von der Interpretation durch den sichtbaren Teil unterscheidet.
Konkret heißt das: Die Beschreibung der Schnittstellen einer Komponente ist für den Anwender sichtbar. Die zugehörige verschlüsselte Simulationsbeschreibung ist dagegen nur für das Werkzeug sinnvoll interpretierbar.
Eine Textdatei ohne Semantik ist ein Gegenbeispiel: Die Ausblendung eines Absatzes oder Kapitels vor dem Benutzer macht die Gesamtheit sinnlos, da das Dokument ohne weitere Information nicht maschinell interpretiert werden kann.
Anwendungsbeispiel Sichtbarkeit von Komponenten eines Simulationsmodells
Im folgenden Anwendungsbeispiel, wie in Figur 1 dargestellt, gibt es ein Gesamtsystem bestehend aus fünf Komponenten: A (4), B (5), C (10), D (11) und E (30). Die Kommunikation zwischen den beiden Prozessoren erfolgt über einen CAN-Bus (7). Komponente A besteht aus der CPU-I (1) und mehreren Betriebssystem-Tasks und Interrupt-Service-Routinen (2) und wird vom Daten-Bereitsteller als Simulationsmodell erzeugt. Komponente B besteht aus mehreren Betriebssystem-Tasks (3) und wird vom Daten-Bereitsteller als Simulationsmodell erzeugt. Komponente C besteht aus der CPU-2 (6) und mehreren Betriebssystem-Tasks und Interrupt- Service-Routinen (8) und wird vom Daten-Bereitsteller als Simulationsmodell erzeugt. Komponente D besteht aus mehreren Betriebssystem-Tasks (9) und wird vom Daten-Bereitsteller als Simulationsmodell erzeugt. Komponente E besteht aus einem CAN-Bus (7) und wird vom Daten-Bereitsteller als Simulationsmodell erzeugt. Datencontainer A (12) enthält das erste (16), zweite (17), dritte (18) und vierte Datenobjekt (19) der Komponente A (4). Datencontainer B (13) enthält das erste (20), zweite (21), dritte Datenobjekt (22) der Komponente B (5). Datencontainer C (14) enthält das erste (23), zweite (24), dritte (25) und vierte Datenobjekt (26) der Komponente C (10). Datencontainer D (15) enthält das erste (27), zweite (28), dritte Datenobjekt (29) der Komponente D (11). Datencontainer E (34) enthält das erste (31), zweite (32), dritte Datenobjekt (33) der Komponente E (30).
Benutzer 1 ist Daten-Bereitsteller und -Nutzer für Komponente A und Daten-Nutzer von Komponente B. Benutzer 2 ist Daten-Bereitsteller der Komponenten B und E und Daten-Nutzer der Komponenten A, B, C D und E. Benutzer 3 ist Daten-Bereitsteller der Komponente C und D.
Benutzer 1 möchte in einer Simulation das Verhalten des Teilsystems 1 bestehend aus den Komponenten A und B untersuchen. Die hierfür benötigte Komponente B wird ihm von Daten- Bereitsteller 2 als Datencontainer B zur Verfügung gestellt. Der Zugriff auf das dritte Datenobjekt (22) ist durch das erste Datenobjekt (20) geregelt. Es ist für Daten-Nutzer 1 einsehbar und simulierbar. Benutzer 2 möchte eine Simulation des Gesamtsystems durchführen.
Er benötigt hierfür neben seinen eigenen Komponenten B und E die Komponente A vom Daten- Bereitsteller 1 und die Komponenten C und D vom Daten-Bereitsteller 3. Die beiden Komponenten A und C sind für ihn nicht einsehbar und werden jeweils vom Daten-Bereitsteller als hidden exportiert und zur Verfügung gestellt. Daten-Bereitsteller 1 stellt für die Simulation das vierte Datenobjekt (19) seiner Komponente A und Daten-Bereitsteller 3 das vierte Datenobjekt (26) seiner Komponente C zur Verfügung. Die dritten Datenobjekte dieser beiden Komponenten sind nicht einsehbar - der Zugang wird jeweils durch das erste Datenobjekt gesteuert. Die Schnittstellen der Komponenten A und C sind für Daten-Nutzer 2 in der Simulation verwendbar, da diese als zweite Datenobjekte zur Verfügung gestellt werden. Komponente D ist für Daten-Nutzer 2 einsehbar, da er für seine Analysen das interne dynamische Verhalten sehen muss. Daten-Bereitsteller 3 erlaubt ihm deshalb Einsicht in das dritte Datenobjekt (29) - der Zugang wird durch das erste Datenobjekt (27) gesteuert. Die Liste der berechtigten Daten-Nutzer für die vierten Datenobjekte kann leer sein, so dass ein viertes Datenobjekt für die Komponenten B, D und E nicht benötigt wird. Benutzer 3 führt eine Simulation des Teilsystems 2 bestehend aus den beiden Komponenten C und D durch. Hierfür benötigt er keine weiteren Komponenten.