EP2232366A2 - Verfahren, system und simulations- bzw. analysemodell zur datenverarbeitung - Google Patents

Verfahren, system und simulations- bzw. analysemodell zur datenverarbeitung

Info

Publication number
EP2232366A2
EP2232366A2 EP09796652A EP09796652A EP2232366A2 EP 2232366 A2 EP2232366 A2 EP 2232366A2 EP 09796652 A EP09796652 A EP 09796652A EP 09796652 A EP09796652 A EP 09796652A EP 2232366 A2 EP2232366 A2 EP 2232366A2
Authority
EP
European Patent Office
Prior art keywords
data
simulation
user
analysis model
data object
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09796652A
Other languages
English (en)
French (fr)
Inventor
Ralf MÜNZENBERGER
Matthias DÖRFEL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inchron GmbH
Original Assignee
Inchron GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inchron GmbH filed Critical Inchron GmbH
Publication of EP2232366A2 publication Critical patent/EP2232366A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

  • the present invention relates to a method, a system and a simulation or analysis model for data processing, in particular for pre-processing of data before the provision of the data to a user of the data for further processing of the data at the user of the data.
  • the invention relates to a computer-based method and simulation or analysis model for data processing.
  • the object of the present invention is to encapsulate and conceal the details necessary for the analysis or simulation of the overall system so that, apart from the intended results, no further information about the subsystem of the other party is disclosed. This object can be achieved by the subject matter in the independent claims.
  • the present invention solves the above object and provides a computerized method for preprocessing data prior to providing the data to a user
  • the method comprises the steps of: a) selecting, by the data provider, at least a portion of the data from the total data to be provided to the user for further processing in dependence on at least one predetermined criterion that the user fulfills; (b) to make the selected data non - visible in such a way that, despite the non - disclosure of the selected data, the selected
  • the data preferably represents one or more software components.
  • the data is preferably one or more software components of a complex embedded system.
  • the interfaces of the hidden software component can remain visible to the user.
  • the data user preferably checks the real-time capability of the one or more software components.
  • the data provider and the data user are thus able to provide only a part of the complex embedded system at a time, but to use the complete system through interaction of the individual parts.
  • the non-visualization of the selected data in step b) enables the data user to obtain results by performing the overall data without being able to view the data in its entirety.
  • the user criterion can be a license dongle.
  • the data preferably represent a simulation and / or analysis model.
  • the selected data may preferably represent one or more task models.
  • the selected data is preferably made invisible by encryption.
  • the steps a) and b) can also be carried out at the data user, the original data user preferably now being regarded as the data provider and the original data provider as the data user.
  • This iteration can be repeated several times.
  • the data are preferably in XML, UML, C, C ++, Matlab / Simulink script, Python, Pascal, Fortran or Basic format.
  • a computer system for performing the method of pre-processing data prior to providing the data to a user of the data for further processing the data with the user of the data.
  • the computer system has a selection device for selection by the data provider of at least part of the data from the entire data to be provided to the user for further processing as a function of at least one predetermined criterion that the user fulfills.
  • the computer system has a unit for not visualizing the selected data in such a way that, despite the non-visualization of the selected data, the selected data remain further executable after the user has made it available.
  • a computerized method for simulating and / or analyzing an overall system having at least two parts comprises the steps of: receiving data representing one or more of the parts of the overall system from one or more data providers, the data being preprocessed by at least one data provider in accordance with a method according to the method described above; Joining, by the data user, the received data to form the overall system; and analysis and / or simulation of the overall system by the data user.
  • the data user for forming the overall system in step b) preferably adds own data to the received data, which represent a further part of the overall system.
  • the data may represent one or more software components.
  • the data is preferably one or more software components of a complex embedded system.
  • the interfaces of the hidden software component preferably remain visible to the user.
  • the data preferably represent a simulation and / or analysis model.
  • the selected data preferably represent one or more task models.
  • a digital storage medium having a program for performing the method described above.
  • a simulation and / or analysis model includes a first data object that controls access to the further data objects, a second data object that forms the outer interface of the simulation and / or analysis model, a third data object, which contains the contents of the simulation and / or analysis model as further processable data, and a fourth data object, which contains the simulation and / or analysis model as a prepared executable simulation.
  • the first data object preferably controls the access of the user of the simulation and / or analysis model to the interface information of the second data object, to the further processable data of the third data object and to the prepared executable simulation of the fourth data object taking into account predetermined access authorization information.
  • the predetermined conditional access information in the first data object may be stored on a license dongle.
  • At least one of the access authorization information of the further processable data of the third data object and the executable data of the fourth data object is encrypted.
  • the first data object preferably denies the user's access to the further processable data of the third data object, but allows the user's access to the prepared executable simulation of the fourth data object, thereby rendering the simulation and / or analysis model non-visual and / or further processable for the user but is made executable.
  • At least part of the further-processable data of the third data object describes the dynamic time behavior of the simulation and / or analysis model.
  • the further-processable data of the third data object can have a source code and the prepared executable simulation of the fourth data object can be generated by generating a simulation model, as described, for example, in WO 2007/051634 A2.
  • the source code of the third data object is preferably in XML, UML, C, C ++, Matlab / Simulink script, Python, Pascal, Fortran or Basic format.
  • the executable data of the fourth data object may be in an intermediate representation or precompiled form.
  • the prepared executable simulation of the fourth data object can be integrated in a software environment of the user into an executable overall model.
  • the simulation and / or analysis model preferably forms a hierarchically ordered part of a superordinate simulation and / or analysis model.
  • the simulation and / or analysis model preferably forms a model or submodel of an embedded system.
  • At least part of the contents of the simulation and / or analysis model is assigned to at least one task of a control unit as further processable data of the third data object and of the executable data of the fourth data object.
  • the simulation and / or analysis model can be used for real-time analysis.
  • the method according to the present invention couples the user's own content with the encrypted content that is thereby encrypted unplanned environments and simulations are usable.
  • DRM Digital Rights Management
  • the AUTOSAR standard provides for the exchange of XML files that describe parts, modules and entire systems. However, the sender always reveals all information about his component and can not restrict the transfer or the purpose of use.
  • the export is a special process that generates a special description from a project at a party 1, which can be imported again at a party 2.
  • the parts of the project marked as hidden by party 1 are completely visible in party 1, but in party 2 only as black box.
  • party 2 may be an analysis or simulation of the But does not see any details within the parts of the project marked as hidden by party 1.
  • the import of a project takes place in a tool that creates a simulatable or analyzable project.
  • the sender marked as hidden parts are then visible as a black box and usable, but not visible.
  • a black box that has an interface definition that allows it to connect to the rest of the system. This includes a (hidden) simulation or analysis model that can be used. Inner details of the black box are not visible.
  • the user can select for which recipient an element marked as hidden should be usable. Only these users can use the imported project in a simulation or analysis. The recipient list of items that the user has already received (imported) as hidden can no longer be changed (especially not supplemented).
  • the recipient can be a single installation of a tool or a license dongle.
  • the single installation corresponds to a personalized receiver while the commitment to the license dongle corresponds in particular to a complete enterprise in the case of a network license.
  • the recipient To select a recipient for an export, the recipient must generate a corresponding cryptographic key and send it to the sender. The sender must include this key in his system accordingly.
  • the relationships between senders and recipients form a network of trust relationships, which can be compared to the Network of Trust of PGP / GnuPG.
  • encryption always implies the use of recognized cryptographic techniques. It can use asymmetric algorithms (DSA, RSA), symmetric algorithms (AES) and hash algorithms (SHA).
  • DSA asymmetric algorithms
  • AES symmetric algorithms
  • SHA hash algorithms
  • Step 1 At the contractor
  • the overall system is created by the contractor.
  • a project is defined that contains the required processors and their shading.
  • task models are defined for its part of the software components to be developed. Task models are also created for the software components of the client in accordance with the specification in the invitation to tender. The interaction of the software components and their real-time properties can be tested on the contractor's side by suitable scenarios.
  • the contractor marks the task models of his software components as hidden and exports the project.
  • the generated file contains all parts that are not marked as hidden and those that are marked as hidden in an encrypted form that only the intended recipient can process. This file is then preferably transmitted from the client to the contractor.
  • Step 2 At the client
  • the client imports the transmitted file into his tool.
  • the parts of the system that were not marked as hidden are just as visible and editable to him as if he had entered them himself in the project. Parts that have been marked as hidden and for which they have been designated as authorized recipients are visible as black boxes. These parts are reduced to their interface definitions.
  • the simulation or analysis is possible by a stored model, which is not further visible.
  • the client can now examine the system.
  • Each part, even the parts marked as hidden, can be replaced by own task models of any degree of abstraction. It makes sense to refine the system parts corresponding to its system components with more precise task models. He can then check the correct function of the project by simulation or analysis.
  • the refined parts are then marked as hidden.
  • An export of the project by the client is expediently carried out in a version that corresponds to the refinement of the parts he marked as hidden parts of the previously imported version.
  • the client sends the exported project back to the contractor.
  • Step 3 Back to the contractor The contractor first loads the project that was originally exported and imports the file returned by the client. By subtracting the versions, the tool recognizes which changes have been made by the client and transfers these parts to the project. Task models are replaced by black boxes, which have been marked as hidden. Other refinements that have not been marked as hidden will also be applied.
  • the contractor carries out a simulation or analysis of the modified project and can thus assess the real-time capability of the entire system.
  • step 1 The parts that the contractor marked as hidden in step 1 are now visible again to the original creator. Details are visible and can be reviewed and changed.
  • controlloop Shown is a model that consists of two submodels.
  • the submodel named "controlloop" is not visible after the described invention
  • the XML tag ⁇ connection> corresponds to the second data object, which is the outer interface of the sub-simulation model, the XML tag ⁇ receivers> to the first data object, the the
  • the XML tag ⁇ data> with the ID 3 corresponds to the third data object, which contains the contents of the sub-simulation model as processable data for authorized users, and the tag ⁇ data> with the ID 4 corresponds to the fourth
  • Unpacking the encrypted data stream results in XML structures that are parsed again.
  • the user can not change attributes of the received data. This keeps the encrypted model consistent with the rest of the system. If the user saves such a project, the model will continue to be stored in encrypted form.
  • the actual data to be protected is encrypted with a randomly generated key.
  • the ciphertext forms the data in the ⁇ data> tag described above.
  • the key itself is encoded with the public key of the recipient according to an asymmetric encryption method. This is done individually for each recipient.
  • the list of the key of the data to be protected so enciphered for each receiver forms the content of the above-mentioned ⁇ receiver> tag.
  • the encrypted model and the list of encrypted keys are embedded as a record in the surrounding data format.
  • Access by the user to the decrypted data must not be possible.
  • the tool must take the appropriate measures.
  • FIG. 1 there is an overall system consisting of five components: A (4), B (5), C (10), D (11) and E (30).
  • the communication between the two processors takes place via a CAN bus (7).
  • Component A consists of the CPU-I (1) and several operating system tasks and interrupt service routines (2) and is generated by the data provider as a simulation model.
  • Component B consists of several operating system tasks (3) and is generated by the data provider as a simulation model.
  • Component C consists of the CPU-2 (6) and several operating system tasks and interrupt service routines (8) and is generated by the data provider as a simulation model.
  • Component D consists of several operating system tasks (9) and is generated by the data provider as a simulation model.
  • Component E consists of a CAN bus (7) and is generated by the data provider as a simulation model.
  • Data container A (12) contains the first (16), second (17), third (18) and fourth data object (19) of component A (4).
  • Data container B (13) contains the first (20), second (21), third data object (22) of component B (5).
  • Data container C (14) contains the first (23), second (24), third (25) and fourth data object (26) of component C (10).
  • Data container D (15) contains the first (27), second (28), third data object (29) of the component D (11).
  • Data container E (34) contains the first (31), second (32), third data object (33) of the component E (30).
  • User 1 is Data Provider and User for Component A and Data User for Component B.
  • User 2 is Data Provider of Components B and E and Data User of Components A, B, CD, and E.
  • User 3 is Data Provider. Provider of component C and D.
  • User 1 wants to investigate the behavior of subsystem 1 consisting of components A and B in a simulation.
  • the component B required for this purpose is made available to it by data provider 2 as data container B.
  • the access to the third data object (22) is regulated by the first data object (20). It can be viewed and simulated by data users 1.
  • User 2 wants to perform a simulation of the entire system. In addition to its own components B and E, it requires the component A from the data provider 1 and the components C and D from the data provider 3. The two components A and C are not visible to him and are respectively hidden by the data provider exported and made available.
  • Data provider 1 provides the fourth data object (19) of its component A and data provider 3 the fourth data object (26) of its component C for the simulation.
  • the third data objects of these two components are not visible - the access is controlled by the first data object.
  • the interfaces of the components A and C can be used for data users 2 in the simulation, since these are provided as second data objects.
  • Component D is visible to Data User 2 because it needs to see internal dynamic behavior for its analysis. Data provider 3 therefore allows it to view the third data object (29) - the access is controlled by the first data object (27).
  • the list of authorized data users for the fourth data objects may be empty, so that a fourth data object for the components B, D and E is not needed.
  • User 3 performs a simulation of the subsystem 2 consisting of the two components C and D. For this he needs no further components.

Abstract

Das erfindungsgemäße Verfahren zur Vorverarbeitung von Daten vor Bereitstellung der Daten an einen Nutzer der Daten zur Weiterverarbeitung der Daten bei dem Nutzer der Daten 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.

Description

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.

Claims

PATENTANSPRÜCHE
1. Verfahren zur Vorverarbeitung von Daten vor Bereitstellung der Daten an einen Nutzer der Daten zur Weiterverarbeitung der Daten bei dem Nutzer der Daten, mit den Schritten: 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 ausfuhrbar bleiben.
2. Verfahren nach Anspruch 1, wobei die Daten eine oder mehrere Software-Komponenten darstellen.
3. Verfahren nach Anspruch 1 oder 2, wobei die Daten eine oder mehrere Software- Komponenten eines komplexen eingebetteten Systems sind.
4. Verfahren nach Anspruch 2 oder 3, wobei der Daten-Nutzer die Echtzeitfähigkeit der einen oder mehreren Software-Komponenten überprüft.
5. Verfahren nach Anspruch 2, 3 oder 4, wobei die Schnittstellen der versteckten Software- Komponente für den Nutzer sichtbar bleiben.
6. Verfahren nach einem der Ansprüche 1 bis 5, wobei der Daten-Bereitsteller und der Daten- Nutzer jeweils nur einen Teil des komplexen eingebetteten Systems bereitstellen aber durch Interaktion der einzelnen Teile das komplette System nutzen.
7. Verfahren nach einem der Ansprüche 1 bis 6, wobei durch das Nichtsichtbarmachen der ausgewählten Daten in Schritt b) dem Daten-Nutzer ermöglicht wird, durch Ausfuhren der
Gesamtdaten Ergebnisse zu erzielen, ohne die Daten in ihrer Gesamtheit einsehen zu können.
8. Verfahren nach einem der Ansprüche 1 bis 7, wobei als Nutzerkriterium ein Lizenzdongle verwendet wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, wobei die Daten ein Simulations- und/oder Analysemodell darstellen.
10. Verfahren nach Anspruch 9, wobei die ausgewählten Daten ein oder mehrere Taskmodelle darstellen.
11. Verfahren nach einem der Ansprüche 1 bis 10, wobei die ausgewählten Daten durch Verschlüsselung nichtsichtbar gemacht werden.
12. Verfahren nach einem der Ansprüche 1 bis 11, wobei Schritte a) und b) ebenfalls beim Daten-Nutzer durchgeführt werden, wobei der ursprüngliche Daten-Nutzer nun als Daten- Bereitsteller anzusehen ist und der ursprüngliche Daten-Bereitsteller als Daten-Nutzer.
13. Verfahren nach Anspruch 12, wobei diese Iteration mehrmals wiederholt wird.
14. Verfahren nach einem der Ansprüche 1 bis 13, wobei die Daten in XML, UML, C, C++, Matlab/Simulmk-Script, Python, Pascal, Fortran oder Basic Format vorliegen.
15. Computersystem zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 14 zur Vorverarbeitung von Daten vor Bereitstellung der Daten an einen Nutzer der Daten zur Weiterverarbeitung der Daten bei dem Nutzer der Daten, mit: einer Auswahleinrichtung 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; einer Einheit zum Nichtsichtbarmachen der ausgewählten Daten derart, dass die ausgewählten Daten trotz der NichtSichtbarmachung für den Nutzer nach deren
Bereitstellung ausführbar bleiben.
16. Computerprogramm zum Durchführen des Verfahrens nach einem der Ansprüche 1 bis 14.
17. Verfahren zur Simulation und/oder Analyse eines Gesamtsystems das aus mindestens zwei Teilen besteht, mit den Schritten: a) 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 einem der Ansprüche 1 bis 14 vorverarbeitet sind; b) Zusammenfügen, durch den Daten-Nutzer, der empfangenen Daten, um das Gesamtsystem zu bilden; und c) Analyse und/oder Simulation des Gesamtsystems durch den Daten-Nutzer.
18. Verfahren nach Anspruch 17, wobei der Daten-Nutzer zur Bildung des Gesamtsystems in Schritt b) den empfangenen Daten noch eigene Daten hinzufügt, die einen weiteren Teil des Gesamtsystems darstellen.
19. Verfahren nach Anspruch 17 oder 18, wobei die Daten eine oder mehrere Software- Komponenten darstellen.
20. Verfahren nach Anspruch 17 oder 18, wobei die Daten eine oder mehrere Software- Komponenten eines komplexen eingebetteten Systems sind.
21. Verfahren nach Anspruch 19 oder 20 wobei die Schnittstellen der versteckten Software- Komponente für den Nutzer sichtbar bleiben.
22. Verfahren nach einem der Ansprüche 1 bis 21, wobei die Daten ein Simulations- und/oder Analysemodell darstellen.
23. Verfahren nach einem der Ansprüche 1 bis 22, wobei die ausgewählten Daten ein oder mehrere Taskmodelle darstellen.
24. Chip mit einem Programm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 14 und 17 bis 23.
25. Digitales Speichermedium mit einem Programm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 14 und 17 bis 23.
26. Simulations- und/oder Analysemodell, 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 aufweist und einem vierten Datenobjekt, das das Simulations- und/oder Analysemodell des dritten Datenobjekts als vorbereitete ausführbare Simulation aufweist, wobei das erste Datenobjekt den Zugang des Benutzers des Simulations- und/oder Analysemodells zu den weiterverarbeitbaren Daten des dritten Datenobjekts und zu der vorbereiteten ausführbaren Simulation des vierten Datenobjekts steuert.
27. Simulations- und/oder Analysemodell nach Anspruch 26, wobei das erste Datenobjekt den Zugang des Benutzers unter Berücksichtigung vorgegebener
Zugangsberechtigungsinformationen steuert.
28. Simulations- und/oder Analysemodell nach Anspruch 27, wobei die vorgegebenen Zugangsberechtigungsinformationen in dem ersten Datenobjekt und/oder auf einem Lizenzdongle gespeichert sind.
29. Simulations- und/oder Analysemodell nach Anspruch 28, wobei mindestens eines der Zugangsberechtigungsinformationen der weiterverarbeitbaren Daten des dritten Datenobjekts und der vorbereiteten ausführbaren Simulation des vierten Datenobjekts verschlüsselt sind.
30. Simulations- und/oder Analysemodell nach einem der Ansprüche 26 bis 29, wobei das erste Datenobjekt den Zugang des Benutzers zu den weiterverarbeitbaren Daten des dritten Datenobjekts verweigert, aber den Zugang des Benutzers zu der ausführbaren Simulation des vierten Datenobjekts erlaubt, wodurch das Simulations- und/oder Analysemodell für den Benutzer nicht einseh- und/oder weiterverarbeitbar, aber ausführbar gemacht wird.
31. Simulations- und/oder Analysemodell nach einem der Ansprüche 26 bis 30, wobei zumindest ein Teil der weiterverarbeitbaren Daten des Simulations- und/oder Analysemodells des dritten Datenobjekts das Zeitverhalten des Simulations- und/oder Analysemodells beschreibt.
32. Simulations- und/oder Analysemodell nach einem der Ansprüche 26 bis 31, wobei die weiterverarbeitbaren Daten des dritten Datenobjekts einen Quellcode aufweisen und die vorbereitete ausführbare Simulation des vierten Datenobjekts durch Erzeugung eines Simulationsmodells aus dem Quellcode des dritten Datenobjekts generiert werden.
33. Simulations- und/oder Analysemodell nach Anspruch 32, wobei der Quellcode des dritten Datenobjekts in XML, UML, C, C++, Matlab/Simulink-script, Python, Pascal, Fortran oder Basic Format vorliegt.
34. Simulations- und/oder Analysemodell nach Anspruch 32 oder 33, wobei die ausfuhrbaren Daten des vierten Datenobjekts in einer Zwischendarstellung oder in vorkompilierter Form vorliegen.
35. Simulations- und/oder Analysemodell nach einem der Ansprüche 32 bis 35, wobei die vorbereitete ausfuhrbare Simulation des vierten Datenobjekts in einer Softwareumgebung des Benutzers in ein ausfuhrbares Gesamtmodell eingebunden wird.
36. Simulations- und/oder Analysemodell nach einem der Ansprüche 26 bis 35, das einen hierarchisch geordneten Teil eines übergeordneten Simulations- und/oder Analysemodells bildet.
37. Simulations- und/oder Analysemodell nach einem der Ansprüche 27 bis 36, das ein Modell oder Teilmodell eines eingebetteten Systems bildet.
38. Simulations- und/oder Analysemodell nach Anspruch 37, wobei zumindest ein Teil der weiterverarbeitbaren Daten des dritten Datenobjekts und der vorbereiteten ausfuhrbaren Simulation des vierten Datenobjekts zumindest einem Task eines Steuergerätes zugeordnet wird.
39. Simulations- und/oder Analysemodell nach einem der Ansprüche 26 bis 38, das zur Echtzeitanalyse eingesetzt wird.
EP09796652A 2008-11-28 2009-11-27 Verfahren, system und simulations- bzw. analysemodell zur datenverarbeitung Withdrawn EP2232366A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008059550 2008-11-28
PCT/EP2009/065972 WO2010060985A2 (de) 2008-11-28 2009-11-27 Verfahren, system und simulations- bzw. analysemodell zur datenverarbeitung

Publications (1)

Publication Number Publication Date
EP2232366A2 true EP2232366A2 (de) 2010-09-29

Family

ID=41694759

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09796652A Withdrawn EP2232366A2 (de) 2008-11-28 2009-11-27 Verfahren, system und simulations- bzw. analysemodell zur datenverarbeitung

Country Status (8)

Country Link
US (1) US8661419B2 (de)
EP (1) EP2232366A2 (de)
JP (1) JP2012510656A (de)
KR (1) KR101458579B1 (de)
CN (1) CN102227714A (de)
CA (1) CA2744891C (de)
IL (1) IL213142A (de)
WO (1) WO2010060985A2 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102339364A (zh) * 2010-07-26 2012-02-01 邹芬 一种使用非可见可变容量存储装置实现软件授权的方法
CN102467640B (zh) * 2010-11-05 2014-10-15 北大方正集团有限公司 功能定制方法和装置
US8931103B2 (en) * 2011-09-08 2015-01-06 International Business Machines Corporation Generating security permissions
CN103514331B (zh) * 2013-09-30 2016-08-31 西北工业大学 一种从Simulink模型转换至UML模型的方法
WO2016108963A1 (en) * 2014-12-30 2016-07-07 Battelle Memorial Institute Temporal anomaly detection on automotive networks
CN107408060B (zh) 2015-03-17 2020-10-16 华为技术有限公司 一种数据处理的方法及装置
KR101662137B1 (ko) * 2016-02-26 2016-10-05 주식회사 티맥스 소프트 다수의 데이터 객체들에 대한 트랜잭션을 설정하는 방법, 서버 및 컴퓨터 판독 가능한 기록 매체
CN106776326B (zh) * 2016-12-20 2020-07-28 中国农业银行股份有限公司 一种数据分析模型的建模方法及系统
CN106897585B (zh) * 2017-03-15 2019-12-13 北京深思数盾科技股份有限公司 软件许可管理方法、软件保护方法及装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6161051A (en) * 1998-05-08 2000-12-12 Rockwell Technologies, Llc System, method and article of manufacture for utilizing external models for enterprise wide control
AU2001241503A1 (en) * 2000-02-18 2001-08-27 Cedere Corporation Auto control of network monitoring and simulation
JP2002230359A (ja) * 2001-01-31 2002-08-16 Toyota Central Res & Dev Lab Inc シミュレーションモデル配信方法、シミュレーションモデル収集方法、プログラムおよび記録媒体
US20030004699A1 (en) * 2001-06-04 2003-01-02 Choi Charles Y. Method and apparatus for evaluating an integrated circuit model
US7152028B2 (en) * 2001-12-13 2006-12-19 Texas Instruments Incorporated Software development tool with embedded cache analysis
JP2003216502A (ja) * 2002-01-25 2003-07-31 Mazda Motor Corp シミュレーションシステムのセキュリティ装置、その方法、及びそのプログラム
US7334222B2 (en) * 2002-09-11 2008-02-19 International Business Machines Corporation Methods and apparatus for dependency-based impact simulation and vulnerability analysis
US7509246B1 (en) * 2003-06-09 2009-03-24 Altera Corporation System level simulation models for hardware modules
US7107567B1 (en) 2004-04-06 2006-09-12 Altera Corporation Electronic design protection circuit
US7409652B1 (en) * 2004-06-04 2008-08-05 Altera Corporation Debuggable opaque IP
CA2569714A1 (en) * 2004-06-08 2005-12-22 Dartdevices Corporation Architecture, apparatus and method for device team recruitment and content renditioning for universal device interoperability platform
US7487080B1 (en) * 2004-07-08 2009-02-03 The Mathworks, Inc. Partitioning a model in modeling environments
US7743361B2 (en) * 2004-09-20 2010-06-22 The Mathworks, Inc. Providing block state information for a model based development process
US8271964B2 (en) * 2005-05-16 2012-09-18 Microsoft Corporation Extensible software development services
US8234630B2 (en) * 2006-05-03 2012-07-31 The Mathworks, Inc. Calling an entity of a graphical model with a non-graphical entity and calling a non-graphical entity of a graphical model with a graphical entity
US8087007B2 (en) * 2006-05-08 2011-12-27 Assima Ltd. System and method for software prototype-development and validation and for automatic software simulation re-grabbing
DE102006031790A1 (de) * 2006-07-10 2008-01-17 Giesecke & Devrient Gmbh Abgesicherter Programmcode
US8079022B2 (en) * 2007-06-04 2011-12-13 Carbon Design Systems, Inc. Simulation of software
EP2223245B1 (de) * 2007-11-30 2011-07-20 Coventor, Inc. System und verfahren zur dreidimensionalen schematischen erfassung und darstellung von multiphysics-systemmodellen
JP5172585B2 (ja) * 2008-10-07 2013-03-27 インターナショナル・ビジネス・マシーンズ・コーポレーション オブジェクト・モデルに対するアクセスを制御するシステム、方法、およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
CA2744891A1 (en) 2010-06-03
US20110258709A1 (en) 2011-10-20
CA2744891C (en) 2015-10-27
WO2010060985A2 (de) 2010-06-03
JP2012510656A (ja) 2012-05-10
KR101458579B1 (ko) 2014-11-07
IL213142A (en) 2016-02-29
IL213142A0 (en) 2011-07-31
WO2010060985A3 (de) 2010-07-29
US8661419B2 (en) 2014-02-25
CN102227714A (zh) 2011-10-26
KR20110099120A (ko) 2011-09-06

Similar Documents

Publication Publication Date Title
WO2010060985A2 (de) Verfahren, system und simulations- bzw. analysemodell zur datenverarbeitung
EP3012761B1 (de) Schutz von softwaremodellen
DE60207812T2 (de) Verfahren und vorrichtung zum dynamischen zuweisen von benutzungsrechten zu digitalen werken
DE60307736T2 (de) Serverarchitektur für sichere Plug-ins in digitalen Rechteverwaltungsssystemen
DE69730321T2 (de) Verfahren und vorrichtung zum schützen von daten mit mehreren auf datenelementebene anwendbaren verschlüsselungsstufen
DE112017002050B4 (de) Konfiguration für Multifaktorautorisierung
EP1410128A1 (de) Datenverarbeitungsvorrichtung
DE112011103164T5 (de) Datenverteilungsvorrichtung, Datenverteilungssystem, Client-Vorrichtung, Datenverteilungsverfahren, Datenempfangsverfahren, Programm und Datenträger,
DE102009017221A1 (de) Information-Rights-Management
EP2502176B1 (de) Verfahren und vorrichtung zum zugreifen auf steuerungsdaten gemäss einer bereitgestellten rechteinformation
DE112012004247T5 (de) Passives Überwachen virtueller Systeme unter Verwendung einer erweiterbaren Indexierung
DE10304412A1 (de) Elektronisch signierte Dokumente mit Prüfsoftware
DE60221861T2 (de) Server mit dateiverifikation
EP1010052B1 (de) Verfahren zur steuerung der verteilung und nutzung von software-objekten bei vernetzten rechnern
WO2021069621A1 (de) Verfahren zum sicheren ausführen eines workflows in einem computersystem
DE102007008948B4 (de) Verfahren und System zur Verfügungstellung digitaler Inhalte
DE202012101671U1 (de) Sichere elektronische Unterzeichnung von Information
DE102016207145A1 (de) Steuersystem für eine Verarbeitung von Bilddaten
EP2187282B1 (de) Verfahren zum Betreiben einer Anlage unter Verwendung von gegen unberechtigte Verwendung gesicherten Daten
DE102012212452A1 (de) Verfahren und System zum Bearbeiten definierter Bereiche innerhalb eines elektronischen Dokuments
EP2184705A1 (de) Verfahren, System und Gerät zum Verarbeiten von Rechten
DE102005049510B4 (de) Verfahren zum Verwalten eines Sicherheitssystems
WO2010026151A1 (de) Verfahren zur einräumung einer zugriffsberechtigung auf ein rechnerbasiertes objekt in einem automatisierungssystem, computerprogramm und automatisierungssystem
EP3407237B1 (de) Klassenbasiertes verschlüsselungsverfahren
DE102006005178A1 (de) Verfahren zur Schutzkennzeichnung von Daten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100819

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INCHRON GMBH

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20140203

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170802