-
Die vorliegende Erfindung betrifft ein Verfahren zum kompatiblen Einsatz von Softwaremodulen, sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
Im Automotive-Bereich werden Steuerungsfunktionen von Fahrzeugkomponenten durch in Steuergeräten ausgeführte Computerprogramme, d.h. durch Software, implementiert. Die Software wird hierbei als sogenannte eingebettete bzw. embedded Software typischerweise speziell für die Hardware (Steuergerät, z.B. ein oder mehrere Mikrocontroller) geschrieben, auf der sie eingesetzt werden soll. Die Software und Hardware muss bestimmte Anforderung erfüllen, um die korrekte Funktion des Fahrzeugs zu gewährleisten. Dies betrifft insbesondere sicherheitsrelevante Steuerungsfunktionen bzw. Fahrzeugkomponenten, für die beispielsweise sogenannte „Automotive Safety Integrity Level“ (ASIL) anzuwenden sind.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum kompatiblen Einsatz von Softwaremodulen sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Die Erfindung bedient sich der Maßnahme, eine Prüfung der Kompatibilität (bzw. Kompatibilitätsprüfung) von Softwaremodulen mittels Metadaten, die in Protokollen (sogenannten ‚Smart-Contract-Einheiten‘) in einer Transaktionsdatenbank gespeichert sind, durchzuführen. Jedem Softwaremodul ist jeweils eines der Protokolle zugeordnet (vorzugsweise in einer eins-zu-eins-Beziehung). Wenn die Kompatibilitätsprüfung erfolgreich ist, gelten die Softwaremodule als (gemeinsam) kompatibel einsetzbar. Anderenfalls wird insbesondere davon ausgegangen, dass die Softwaremodule nicht kompatibel einsetzbar sind. Es wird dadurch der Einsatz modular aufgebauter Software bei gleichzeitiger Einhaltung von Kompatibilitätsanforderungen ermöglicht. Da die Metadaten in Protokollen in einer Transaktionsdatenbank gespeichert werden, sind diese vor Manipulationen sicher bzw. jede Änderung kann anhand entsprechender protokollierter Transaktionen in der Transaktionsdatenbank manipulationssicher nachgewiesen werden. Die Kompatibilitätsprüfung ist also manipulationssicher.
-
Der Begriff ‚Softwaremodul‘ soll wie üblich ein Computerprogramm-Modul einer Software (bestehend aus einem oder mehreren Computerprogrammen) bezeichnen. Ein Softwaremodul implementiert (indem es entsprechend programmiert ist) typischerweise eine oder mehrere Funktionalitäten, z.B. Steuerungsfunktionalitäten von Steuergeräten. Die Gesamtsteuerungsfunktion, die durch Steuergeräte eines Fahrzeugs oder einer Maschine mittels darin ausgeführter Softwaremodule implementiert wird, ergibt sich aus dem Zusammenwirken von mehreren Softwaremodulen, die miteinander Daten austauschen. Beispielsweise könnte ein Softwaremodul Messdaten erfassen und vorverarbeiten und die vorverarbeiteten Messdaten an ein anderes Softwaremodul (das in derselben oder in einem anderen Steuergerät ausgeführt wird) übermitteln, welches die vorverarbeiteten Messdaten dann zur Steuerung einer Komponente, z.B. eines Motors, verwendet.
-
Es können zur Steuerung verschiedener Fahrzeugkomponenten jeweils eigene Softwaremodule eingesetzt werden, wobei Fahrzeugkomponenten und/oder Softwaremodule von unterschiedlichen Herstellern sein können und ein bestimmtes Softwaremodul auf unterschiedlichen Recheneinheiten ausgeführt werden kann, d.h. die im Mikrocontrollerbereich übliche Bindung der Software an die Hardware ist nicht unbedingt gegeben. Durch die Modularisierung der Steuerungssoftware können die Anpassung der Steuerung einzelner Fahrzeugkomponenten und der Einsatz einer bestimmten Fahrzeugkomponente in verschiedenen Fahrzeugen vereinfacht werden.
-
Wie vorstehend erläutert, wird die Gesamtfunktion einer modularisiert aufgebauten Software durch das Zusammenwirken der Softwaremodule verwirklicht. Damit dies fehlerfrei und so möglich ist, dass die Gesamtfunktion wie gewünscht erreicht wird, insbesondere so, dass vorgegebene Anforderungen an die Software bzw. deren Gesamtfunktion erfüllt werden, müssen die Softwaremodule miteinander ‚kompatibel einsetzbar‘ sein. D.h. wenn die Softwaremodule miteinander kompatibel einsetzbar sind, wird davon ausgegangen, dass die modulare Software die Gesamtfunktion fehlerfrei und wie gewünscht verwirklicht.
-
In dieser Anmeldung wird der Begriff ‚Protokoll‘ für ‚Smart-Contract‘ bzw. ‚intelligenter Vertrag‘ verwendet. Ein Protokoll ist also als ein Computerprotokoll bzw. Computerprogramm implementiert, das automatisiert ausgeführt wird. Ein Protokoll umfasst im Allgemeinen Programmcode und/oder Daten, die in der Transaktionsdatenbank gespeichert sind. Zur Interaktion können Protokolle Funktionenumfassen, etwa um im Protokoll umfasste bzw. gespeicherte Daten abzufragen. Protokolle werden automatisiert ausgeführt, müssen also nicht eigens aufgerufen werden, d.h. die im Programmcode in Form von Funktionen kodifizierten Abläufe werden automatisch durchgeführt, etwa in Reaktion auf das Vorliegen bestimmter Bedingungen oder in Reaktion auf einen Aufruf der jeweiligen Funktion. Bei der Ausführung eines Protokolls bzw. Programmcodes können Daten anfallen oder können Daten geändert werden, dies wird durch die Transaktionsdatenbank in Form von Transaktion gespeichert (etwa in Blöcken einer Blockkette („block chain“)). Ein Protokoll ist also als automatisiert auf der Transaktionsdatenbank ausgeführtes Computerprotokoll implementiert. Die Transaktionsdatenbank kann als Blockkette implementiert sein.
-
Protokolle bzw. Smart-Contract-Einheiten können im Prinzip als Computerprotokolle bzw. Computerprogramme angesehen werden, die einen Vertrag abbilden und insbesondere die Abwicklung und Einhaltung eines Vertrags in automatischer Form ermöglichen. Solche Computerprotokolle (‚Smart-Contract‘, ‚intelligenter Vertrag‘ können durch eine Programmiersprache in einer dezentralen Datenbank, etwa einer Blockkette verwirklicht werden. Hierfür kann z.B. die Programmiersprache Solidity verwendet werden, die eigens zur Implementierung dieser Computerprotokolle entwickelt wurde und z.B. in Ethereum bzw. in der „Ethereum Virtual Machine“ genutzt wird. Neben bekannten, im Prinzip allgemein verfügbaren Transaktionsdatenbanken (Blockketten) wie Ethereum kann auch eine proprietäre Transaktionsdatenbank verwendet werden. Beispielsweise könnte ein Fahrzeughersteller oder Maschinenhersteller eine eigene Transaktionsdatenbank implementieren, in der Protokolle im Sinne der vorliegenden Erfindung, d.h. Protokolle, die Metadaten speichern, automatisiert ausgeführt werden, um den kompatiblen Einsatz von Softwaremodulen in Recheneinheiten bzw. Steuergeräten, die der Steuerung von Komponenten von Fahrzeugen/Maschinen des jeweiligen Herstellers dienen, zu gewährleisten.
-
Bevorzugt erfolgt die Prüfung der Kompatibilität durch wenigstens eine in einem der Protokolle implementierte Prüffunktion. Dies ist vorteilhaft, da so anhand der in der Transaktionsdatenbank gespeicherten Transaktion, die sich auf die Prüfung beziehen, der Ablauf der Prüfung manipulationssicher nachvollzogen werden kann.
-
Bevorzugt beschreiben für jedes der Softwaremodule die Metadaten (unabhängig voneinander) wenigstens eine Eigenschaft des jeweiligen Softwaremoduls und/oder wenigstens eine Anforderung des jeweiligen Softwaremoduls. Beispiele für Eigenschaften sind ein erreichtes Sicherheitslevel, vorzugsweise ein erreichtes ASIL („Automotive Safety Integrity Level“ entsprechend Standard ISO 26262) oder auch ein erreichtes Sicherheitslevel nach IEC 61508 oder ISO 13849, Berechnungszyklen und daraus z.B. Zykluszeiten für zu sendende Daten. Beispiele für Anforderungen sind ein gefordertes Sicherheitslevel, vorzugsweise ein gefordertes ASIL oder auch ein gefordertes Sicherheitslevel nach IEC 61508 oder ISO 13849, Zykluszeiten eines Eingangssignals bzw. zu empfangender Daten, Speicherplatzbedarf.
-
Bevorzugt beschreiben für ein erstes der Softwaremodule die Metadaten wenigstens eine Eigenschaft und für ein zweites der Softwaremodule die Metadaten wenigstens eine Anforderung. Die Prüfung der Kompatibilität schließt ein Prüfen ein, ob die wenigstens eine Eigenschaft des ersten Softwaremoduls der wenigstens einen Anforderung des zweiten Softwaremoduls entspricht. Soweit eine Prüffunktion vorgesehen ist, ist diese Prüffunktion in dem Protokoll, das dem zweiten Softwaremodul zugeordnet ist, implementiert.
-
Weiter bevorzugt werden, wenn die Prüfung erfolgreich ist, Daten, die vom ersten an das zweite Softwaremodul übermittelt werden, durch das zweite Softwaremodul verwendet bzw. verarbeitet.
-
Ebenso weiter bevorzugt werden, wenn die Prüfung nicht erfolgreich ist, Daten, die vom ersten an das zweite Softwaremodul übermittelt werden, vom zweiten Softwaremodul nicht verwendet bzw. verarbeitet.
-
Entsprechend werden je nachdem, ob die Prüfung erfolgreich ist oder nicht, die Daten des ersten Softwaremoduls vom zweiten Softwaremodul verwendet oder nicht. Im Fall einer erfolgreichen Prüfung ist also ein kompatibler Einsatz des ersten und des zweiten Softwaremoduls möglich, wobei der Einsatz hier die Verwendung der Daten einschließt. Im Fall einer nicht erfolgreichen Prüfung (etwa zu geringes ASIL der Daten bzw. des ersten Softwaremoduls), können Fehlfunktionen oder Ähnliches, die sich aus fehlhaften Daten ergeben, im zweiten Softwaremodul verhindert werden (im Sinne der geprüften Anforderungen/Eigenschaften, hier etwa ASIL).
-
Bevorzugt wird wenn die Prüfung der Kompatibilität für ein Softwaremodul erfolgreich ist, das Softwaremodul auf einer Recheneinheit, auf der es zur Installation vorgesehen ist, installiert. Andernfalls, d.h. bei nicht erfolgreicher Prüfung, wird die Installation vorzugsweise unterbunden. Dadurch kann sichergestellt werden, dass nur kompatibel einsetzbare Softwaremodule installiert werden. Die Ausführung nicht kompatibler Softwaremodule wird also von vornherein unterbunden.
-
Bevorzugt werden die Metadaten unveränderlich durch die Protokolle gespeichert. Z.B. ist in den Protokollen keine Schreib- bzw. Änderungsfunktion für die Metadaten implementiert, sondern lediglich eine Lese- bzw. Abfragefunktion. Eine Manipulation ist dadurch ausgeschlossen, bzw. anhand von in der Transaktionsdatenbank protokollierten Transaktionen zumindest nachweisbar.
-
Eine erfindungsgemäße Recheneinheit (z.B. ein Steuergerät eines Kraftfahrzeugs oder einer Maschine), ist, insbesondere programmtechnisch, dazu eingerichtet, die Prüfung der Kompatibilität gemäß einem erfindungsgemäßen Verfahren zu veranlassen oder (selbst) durchzuführen, wenn wenigstens eines der Softwaremodule auf der Recheneinheit ausgeführt wird oder zur Installation auf der Recheneinheit vorgesehen ist. Um die Prüfung der Kompatibilität zu veranlassen, ist die Recheneinheit vorzugsweise eingerichtet, die Prüffunktion in einem Softwaremodul aufzurufen.
-
Bevorzugt ist die Recheneinheit weiter dazu eingerichtet, die Verarbeitung von Daten, die von einem Softwaremodul übermittelt werden, für das die Kompatibilität erfolgreich geprüft ist, durch ein auf der Recheneinheit ausgeführtes Softwaremodul zu veranlassen, und/oder die Installation eines Softwaremoduls, für das die Kompatibilität erfolgreich geprüft ist, zu veranlassen.
-
Ebenso bevorzugt ist die Recheneinheit weiter dazu eingerichtet, die Verarbeitung von Daten, die von einem Softwaremodul übermittelt werden, für das die Kompatibilität nicht erfolgreich geprüft ist, durch ein auf der Recheneinheit ausgeführtes Softwaremodul zu unterbinden, und/oder die Installation eines Softwaremoduls, für das die Kompatibilität nicht erfolgreich geprüft ist, zu unterbinden.
-
Durch diese Ausgestaltungen wird sichergestellt, dass nur kompatibel einsetzbare Softwaremodule gemeinsam verwendet bzw. ausgeführt werden.
-
Zweckmäßigerweise werden diese Funktionalitäten durch ein auf der Recheneinheit ausgeführtes Computerprogramm (Software-Verwaltungsprogramm) implementiert.
-
Schließlich ist ein maschinenlesbares Speichermedium vorgesehen mit einem darauf gespeicherten Computerprogramm wie vorstehend beschrieben. Geeignete Speichermedien bzw. Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich. Ein solcher Download kann dabei drahtgebunden bzw. kabelgebunden oder drahtlos (z.B. über ein WLAN-Netz, eine 3G-, 4G-, 5G- oder 6G-Verbindung, etc.) erfolgen.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt ein Beispiel für eine Kompatibilitätsprüfung zwischen Softwaremodulen in zwei Komponenten bzw. Recheneinheiten gemäß einer bevorzugten Ausführungsform.
- 2 zeigt ein Ablaufdiagramm gemäß einer bevorzugten Ausführungsform.
-
Ausführungsform(en) der Erfindung
-
1 zeigt ein Beispiel für eine Kompatibilitätsprüfung zwischen Softwaremodulen 10, 12 in zwei Komponenten bzw. Recheneinheiten 14, 16 gemäß einer bevorzugten Ausführungsform. Die Recheneinheiten weisen wie üblich einen oder mehrere Prozessoren, Speicher, Schnittstellen usw. auf.
-
Die zwei Recheneinheiten können z.B. zur Steuerung von Fahrzeugkomponenten oder Maschinenkomponenten unter Verwendung der Softwaremodule dienen. Dabei sind eine erste Recheneinheit 14, in der ein erstes Softwaremodul 10 ausgeführt wird, und eine zweite Recheneinheit 16, in der ein zweites Softwaremodul 12 ausgeführt wird, gezeigt. Durch das erste Softwaremodul 10 werden Daten 18 (z.B. Messwerte, Steueranweisungen, o.Ä.) an das zweite Softwaremodul 12 übermittelt, das die Daten 18 verwenden soll, z.B. um einen Aktor anzusteuern. Das Übermitteln von Daten und Verwenden der Daten kann als gemeinsamer Einsatz der Softwaremodule angesehen werden, wobei durch die Prüfung der Kompatibilität sichergestellt werden soll, dass ein kompatibler Einsatz im Sinne von in Metadaten hinterlegten Informationen (Anforderungen/Eigenschaften) möglich ist. Anders als dargestellt ist es auch denkbar, dass das erste und das zweite Softwaremodul in derselben Recheneinheit ausgeführt werden.
-
Um sicherzustellen, dass das erste Softwaremodul 10 und damit die von diesem übermittelten Daten 18 bestimmte vorgegebene Anforderungen erfüllen, wird eine Kompatibilitätsprüfung durchgeführt. Die Anforderungen können sicherheitsrelevante Anforderungen (z.B. bestimmtes ASIL), technische Anforderungen (z.B., dass die Daten, etwa Messergebnisse, regelmäßig mit bestimmten zeitlichen Maximalabständen übermittelt werden), Anforderungen an das Datenformat, o.Ä. sein.
-
Entsprechend umfassen bzw. beschreiben erste Metadaten 22 des ersten Softwaremoduls 10 Eigenschaften des ersten Softwaremoduls (d.h. Eigenschaften, die vom ersten Softwaremodul erfüllt werden) und zweite Metadaten 24 des zweiten Softwaremoduls 12 umfassen bzw. beschreiben Anforderung des zweiten Softwaremoduls. Selbstverständlich können zusätzlich die ersten Metadaten auch Anforderungen des ersten Softwaremoduls und/oder die zweiten Metadaten auch Eigenschaften beschreiben.
-
Die ersten und die zweiten Metadaten werden jeweils durch (bzw. als) ein erstes Protokoll 26 bzw. zweites Protokoll 28 in einer Transaktionsdatenbank 20 gespeichert. Das erste Protokoll 26 umfasst insbesondere eine (Programm-) Funktion bzw. Abfragefunktion (nicht dargestellt), die eingerichtet ist, d.h. entsprechend programmiert ist, die ersten Metadaten (alle oder eine Teilmenge davon) an ein anderes Protokoll zu übermitteln, wenn dieses andere Protokoll diese Abfragefunktion aufruft bzw. die ersten Metadaten abfragt. Im dargestellten Fall fragt das zweite Protokoll 28 die ersten Metadaten ab, die an das zweite Protokoll 28 übermittelt werden (Pfeil 30). Es kann auch vorgesehen sein, dass nur eine in der Abfrage spezifizierte Teilmenge der ersten Metadaten übermittelt wird.
-
Das zweite Protokoll 28 umfasst insbesondere eine (Programm-)Funktion bzw. Prüffunktion 32, die eingerichtet ist, d.h. entsprechend programmiert ist, anhand von einem anderen Protokoll übermittelter Metadaten zu prüfen, ob die in den zweiten Metadaten 24 beschriebenen Anforderungen des zweiten Softwaremoduls 12 erfüllt sind. Im dargestellten Fall wird durch die Prüffunktion 32 anhand der übermittelten (Pfeil 30) ersten Metadaten 22 bzw. anhand der darin beschriebenen Eigenschaften des ersten Softwaremoduls 10 geprüft, ob das erste Softwaremodul 10 die Anforderungen, die in den zweiten Metadaten 24 beschrieben sind, erfüllt. Die Metadaten weisen insbesondere ein vorbestimmtes Datenformat auf, so dass entsprechende Vergleiche möglich sind. Datenformate können u.a. sein: textbasierte, vereinfachte Auszeichnungssprachen wie XML, JSON, YAML; anwendungsspezifische, binäre Formate; oder Bytecode, in dem Daten und Anwendungsalgorithmus als JIT-Code (just-in-time Code) verbunden sind. Letzteres erlaubt, den konkreten Prüfalgorithmus (bzw. die konkrete Prüffunktion) manipulationssicher in der Transaktionsdatenbank abzulegen. Das ermöglicht, auch mit der Anwendung wachsende Funktionsumfänge zu implementieren, ohne den grundlegenden Manipulationsschutz des ursprünglichen Programms zu gefährden.
-
Wie erwähnt sind das erste und das zweite Protokoll 26, 28 in einer Transaktionsdatenbank 20 realisiert, insbesondere in einer Blockkette, etwa in Ethereum, wobei beispielsweise Solidity als Programmiersprache verwendet wird. In den Protokollen ist ein automatisierter Ablaufplan, der Transaktionen innerhalb der Transaktionsdatenbank ausführen kann, implementiert, d.h. die Protokolle sind als automatisiert auf der Transaktionsdatenbank ausgeführte Computerprotokolle (d.h. im Wesentlichen als Computerprogramme) implementiert. Die Protokolle können als sogenannte „Smart Contracts“ angesehen werden.
-
Wenn die Prüfung erfolgreich ist, wenn also die Anforderungen erfüllt sind, wird das erste Softwaremodul 10 als kompatibel angesehen; ein kompatibler gemeinsamer Einsatz des ersten und des zweiten Softwaremoduls ist also möglich. Entsprechend verwendet das zweite Softwaremodul 12 Daten 18, die vom ersten Softwaremodul 10 übermittelt werden. Wenn die Prüfung nicht erfolgreich ist (mangelnde Kompatibilität, kompatibler Einsatz nicht möglich), wenn also die Anforderungen nicht erfüllt sind, werden vom ersten Softwaremodul 10 übermittelte Daten 18 vorzugsweise nicht durch das zweite Softwaremodul 12 verwendet. Die Prüfung der Kompatibilität erfolgt typischerweise nicht jedes Mal, wenn Daten 18 übermittelt werden, sondern an gewissen Zeitpunkten, etwa wenn das System, das die erste Komponente bzw. das erste Softwaremodul 10 und die zweite Komponente bzw. das zweite Softwaremodul 12 umfasst, konfiguriert wird, oder wenn eine Änderung des ersten und/oder des zweiten Softwaremoduls festgestellt wird. Auch eine Prüfung an vorgegebenen Zeitpunkten, z.B. regelmäßigen Zeitpunkten, oder zufälligen Zeitpunkten ist denkbar.
-
Die Metadaten können jeweils auch kryptographische Daten, z.B. öffentliche Schlüssel umfassen (nicht dargestellt), die es mittels eines kryptographischen Verfahrens ermöglichen, festzustellen, ob ein ausgeführtes Softwaremodul auch tatsächlich dasjenige Softwaremodul ist, auf das sich die Metadaten beziehen. Eine solche Feststellung könnte beispielsweise in der Kompatibilitätsprüfung (z.B. Prüffunktion 32) umfasst sein.
-
2 zeigt ein Ablaufdiagramm gemäß einer bevorzugten Ausführungsform, die die Prüfung der Kompatibilität und den Einsatz eines ersten und eines zweiten Softwaremoduls beschreibt und die im Wesentlichen der in 1 gezeigten Struktur entspricht.
-
In einem optionalen Schritt 100 erfolgt ein Bestimmen von Metadaten und/oder Speichern der Metadaten für eines oder mehrere der Softwaremodule. Die Metadaten werden dabei mittels Protokollen, die den Softwaremodulen zugeordnet sind, gespeichert.
-
In einem bevorzugten Schritt 110 werden erste Metadaten des ersten Softwaremoduls durch das zweite Softwaremodul angefordert und an das zweite Softwaremodul übermittelt. Dazu kann, wie im Zusammenhang mit 1 erläutert, in einem ersten Protokoll, das dem ersten Softwaremodul zugeordnet ist, eine Abfragefunktion aufgerufen werden, die die angeforderten ersten Metadaten des ersten Softwaremoduls an das zweite Softwaremodul zurückgibt.
-
In Schritt 120 erfolgt ein Prüfen der Kompatibilität mittels der ersten Metadaten und zweiten Metadaten des zweiten Softwaremoduls. Letztere werden durch ein zweites Protokoll, das dem zweiten Softwaremodul zugeordnet ist, gespeichert. Diese Prüfung der Kompatibilität kann insbesondere durch eine Prüffunktion, die im zweiten Protokoll implementiert ist, erfolgen. Das Anfordern der ersten Metadaten, d.h. das Aufrufen der Abfragefunktion des ersten Protokolls, kann ebenfalls durch diese Prüffunktion erfolgen. Insofern kann Schritt 110 als Teil von Schritt 120 angesehen werden.
-
Wenn die Prüfung der Kompatibilität in Schritt 120 erfolgreich ist, können das erste und das zweite Softwaremodul gemeinsam eingesetzt (verwendet oder ausgeführt) werden. Beispielsweise können in Schritt 130 Daten, die vom ersten Softwaremodul an das zweite Softwaremodul übermittelt werden, durch das zweite Softwaremodul verarbeitet (verwendet) werden bzw. deren Verarbeitung (Verwendung) durch das zweite Softwaremodul zugelassen werden.
-
Wenn die Prüfung der Kompatibilität in Schritt 120 nicht erfolgreich ist, gelten die beiden Softwaremodule als nicht kompatibel und diese werden insbesondere nicht gemeinsam eingesetzt; z.B. werden die vom ersten Softwaremodul übermittelten Daten nicht vom zweiten Softwaremodul verwendet. In diesem Fall kann vorzugsweise in Schritt 140 eine Fehlermeldung oder Ähnliches erzeugt werden.
-
Die Schritte 110 und 120 werden bevorzugt innerhalb der Transaktionsdatenbank ausgeführt, d.h. wie erläutert durch entsprechende in den Protokollen implementierte Funktionen. Das ist vorteilhaft, da dadurch der Ablauf der Prüfung der Kompatibilität in der Transaktionsdatenbank in Form von Transaktionen gespeichert bzw. protokolliert wird und somit nachvollziehbar ist. Lediglich das Veranlassen der Prüfung erfolgt von außerhalb, z.B. durch Recheneinheit, in der das zweite Softwaremodul ausgeführt wird, bzw. durch eine darin implementierte Funktionalität. Alternativ könnten lediglich die Metadaten durch die Protokolle gespeichert sein und die Prüfung außerhalb der Transaktionsdatenbank erfolgen, im genannten Beispiel etwa durch eine entsprechende Funktionalität in der Recheneinheit, in der das zweite Softwaremodul ausgeführt wird. Die Metadaten sind dann vor Manipulationen geschützt, da die Metadaten in den Protokollen unveränderlich gespeichert sind oder zumindest jede Änderung in der Transaktionsdatenbank nachvollziehbar ist.
-
Die Schritte 130 und 140 werden insbesondere durch wenigstens eine Recheneinheit veranlasst, auf der eines der Softwaremodule ausgeführt wird bzw. installiert ist. Die wenigstens eine Recheneinheit führt hierfür z.B. entsprechende Computerprogramme aus. Solche Computerprogramme können auch die Prüfung veranlassen (Schritte 110, 120).
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- ISO 26262 [0011]
- IEC 61508 [0011]
- ISO 13849 [0011]
