-
Die vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen von Programmdaten aus einer auf einem Rechensystem bereitgestellten Datenbank sowie ein Rechensystem und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
Für Produkte in sicherheitsrelevanten Bereichen, z.B. bei Fahrzeugen oder Maschinen, existieren je nach Domäne oder Anwendung Normen zur funktionalen Sicherheit. Dies betrifft nicht nur die Hardware, sondern auch die Software oder allgemein Programmdaten, dort insbesondere sog. Software-Integritäts-Level (SIL). Diese Normen beschreiben z.B. Anforderungen an den Software-Entwicklungsprozess und an die Daten- bzw. Softwarebereitstellung. Solche Normen sind z.B. die DIN EN IS025519 für Landwirtschaft, die DIN EN ISO 13849 für Maschinen, oder die DIN EN ISO26262 für Automotive.
-
Während der Software-Entwicklung sind dabei je nach Norm unterschiedliche Qualitätsdaten zu erheben und nachzuweisen. Dies kann manuell oder auch automatisch erfolgen. Zu durchlaufende Qualitätsprüfungen (oder auch „Quality Gates“) während der Entwicklung und vor Auslieferung der Software sind in der Regel im Software-Entwicklungsprozess des Herstellers verankert und damit unabhängig von Anforderungen aus den Normen der funktionalen Sicherheit.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Bereitstellen von Programmdaten aus einer Datenbank sowie ein Rechensystem 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 beschäftigt sich mit dem Bereitstellen von Programmdaten aus einer auf einem Rechensystem bereitgestellten Datenbank, insbesondere in der sog. Cloud, also einem z.B. über Internet erreichbaren Server, zum Herunterladen durch z.B. einen Anwender. Die Programmdaten können dabei insbesondere Software wie eine Softwareanwendung oder eine Funktion hiervon umfassen, ebenso aber auch nur Daten, die z.B. im Rahmen von solchen Softwareanwendungen oder Funktionen verwendet werden, z.B. Karten oder Applikationskurven.
-
Ein Grund, weshalb Programmdaten, die z.B. für Steuergeräte in Fahrzeugen oder anderen Maschinen verwendet werden sollen, auf diese Weise bereitgestellt werden oder werden sollen, ist die Überlegung, dass eine Entwicklungs-Plattform geschaffen werden kann, die beteiligten Unternehmen (die die Programmdaten bereitstellen, also z.B. Software entwickeln) die Möglichkeit bietet, ihre Programmdaten (zentral) zu hosten und dann auf Anforderung an Kunden bzw. Anwender bereitzustellen bzw. herauszugeben. Hierfür muss aber herstellerübergreifend die Einhaltung von Sicherheitsnormen gewährleistet sein.
-
Die Hersteller bzw. Entwickler einer Softwareanwendung oder anderer Programmdaten kennen in der Regel die Sicherheitsanforderung des Endkunden an die Softwareanwendung bzw. Programmdaten nicht und haben daher meist auch kein direktes Interesse am Nachweis für eine oder mehrere domänen-spezifische Normen. Programmdaten wie Funktionen von und Daten für Softwareanwendungen unterliegen aber direkt oder indirekt gewissen Anforderungen der funktionalen Sicherheit. Ein direkter Bezug liegt vor, wenn die Programmdaten, wie eine Softwareanwendung oder eine von ihr bereitgestellte Funktion, selbst ein gewisses Gefährdungspotential aufweisen oder zur Abwendung eines Gefährdungspotentials dienen. Hierunter fallen z.B. Softwareanwendungen, die in einem Fahrzeug Lenkbewegungen verursachen oder auf die Bremsen zugreifen. Ein indirekter Bezug liegt vor, wenn Programmdaten wie eine Softwareanwendung oder eine von ihr bereitgestellte Funktion selbst zwar kein Gefährdungspotential aufweisen bzw. zur Abwendung eines solchen dienen, aber im Zusammenhang mit einer solchen Softwareanwendung bzw. Funktion verwendet werden. Ein Beispiel hierfür wäre die Messung oder Anzeige von Entfernungen, z.B. zum nächsten Hindernis vor einem Fahrzeug. Dies ist an sich zwar nicht sicherheitsrelevant, wir aber für sicherheitsrelevante Funktionen wie z.B. einem rechtzeitigen Bremsen benötigt.
-
Ein weiterer indirekter Bezug liegt vor, wenn die Programmdaten in einer Software-Hardware-Einheit (z.B. in einem Steuergerät oder einem abgekapselten Teil davon, aber auch auf jedem anderen beliebigen Speicher wie einer Datenbank) zusammen mit anderen Programmdaten wie einer Softwareanwendung oder einer von dieser bereitgestellten Funktion liegen, die ein Gefährdungspotential aufweist bzw. zur Abwendung eines solchen dient. Dieser Aspekt ist vom Gesichtspunkt der funktionalen Sicherheit und der daraus abgeleiteten Sicherheits- bzw. Integritätsanforderungen her gesehen ein besonders kritischer. Es wird nämlich unterstellt (oder muss unterstellt werden), dass beliebige Programmdaten, die ohne nachgewiesene Trennung in einer Software-Hardware-Einheit mit anderen Programmdaten, Softwareanwendungen oder Funktionen liegen, diese hinsichtlich der gewährleisteten Sicherheitsanforderungen „kontaminieren“.
-
Die Folge davon ist, dass alle Programmdaten dieser Hardware-Software-Einheit den Softwareintegritätslevel der Programmdaten mit der niedrigsten Integritätseinstufung einnehmen. In der Konsequenz muss eine solche Kontamination der in der Cloud bzw. der Datenbank liegenden Programmdaten verhindert werden, ebenso aber später beim Einsatz auf z.B. einem Steuergerät. Es müssen also, zusätzlich zu den funktionalen Anforderungen des Kunden Anforderungen nonfunktionaler Art und hier insbesondere die Einhaltung der Software-Integrität gewährleistet sein. Zusätzlich sollte die Fehlverwendung von Programmdaten von niedrigem Integritätslevel bzw. niedriger Sicherheitsanforderung in einem Produkt mit hohen bzw. höheren Sicherheitsanforderungen verhindert oder weitest möglich eingeschränkt werden. Dies beinhaltet zum einen, dass der Kunde seine Anforderungen an das Integritätslevel bzw. die Sicherheitsanforderungen im Rahmen der Bereitstellung explizit benennen soll, und zum anderen, dass der Zulieferer bzw. Hersteller bei Kenntnis von Fehlverwendung diese, falls möglich, unterbinden sollte.
-
Vor diesem Hintergrund wird das im Folgenden erläuterte Vorgehen für das Bereitstellen von Programmdaten wie z.B. einer Softwareanwendung aus einer auf einem Rechensystem bereitgestellten Datenbank für z.B. späteres Herunterladen vorgeschlagen, das automatisiert von dem Rechensystem (also sozusagen von der Cloud bzw. dem zugrundliegenden Server oder Serververbund) durchgeführt wird. Das Rechensystem ist hierzu entsprechend in ein Netzwerk einzubinden. Es versteht sich, dass die Programmdaten zuvor vom Rechensystem empfangen worden sei müssen, ebenso wie z.B. Referenzdaten mit Informationen über die Programmdaten sowie über Sicherheitsanforderungen an die Programmdaten.
-
Die Programmdaten werden, auf eine Anfrage zum Bereitstellen der Programmdaten hin, in einem von dem Rechensystem getrennt von der Datenbank (auf die Programmdaten zunächst gespeichert sind) bereitgestellten Eingangsbereich zwischengespeichert. Eine solche Anfrage kann z.B. von einem Kunden oder Anwender, der die Programmdaten herunterladen und in ein Steuergerät oder ein sonstiges System aufspielen oder integrieren will, stammen. Diese kann beispielsweise über einen PC und Internet, eine App oder dergleichen erfolgen.
-
Danach oder ggf. auch zumindest teilweise zusammen mit der Anfrage werden Anforderungen an die Programmdaten empfangen, also Anforderungen, die der Anwender bzw. dessen System, für das die Programmdaten vorgesehen sind, hat oder benötigt. Hierzu wird dann überprüft, ob die Anforderungen von den Programmdaten erfüllt werden. Dies erfolgt durch Abgleichen der Anforderungen mit Informationen aus einem auf dem Rechensystem vorhandenen Sicherheitsverzeichnis, die wiederum Informationen über die Programmdaten sowie über Sicherheitsanforderungen an die Programmdaten umfassen. Dieser Abgleich kann zudem aber auch andere, im Eingangsbereich verfügbare Daten und/oder Informationen umfassen, die z.B. manuelle eingestellt wurden oder auch sonst im Zusammenhang mit dem Einstellen der Programmdaten in den Eingangsbereich gelangt sind.
-
Dieses Sicherheitsverzeichnis ist dabei insbesondere mit den Programmdaten korreliert und z.B. beim Einstellen der Programmdaten auf die Datenbank erzeugt worden. Ein solches Sicherheitsverzeichnis kann insbesondere als Nachweis dafür dienen, dass die Programmdaten bestimmte Kriterien, insbesondere hinsichtlich Sicherheitsanforderungen, erfüllen.
-
Diese Informationen im Sicherheitsverzeichnis können dabei teils auch von dem Entwickler oder Hersteller, von dem die Programmdaten in die Datenbank eingestellt wurden, stammen. Die Informationen über die Programmdaten (sog. „Kontext-Katalog“) umfassen z.B. die verantwortlichen Hersteller der Programmdaten, verwendete Normen, die Version der Programmdaten, einen eindeutigen Identifier für die Version sowie mitgelieferte Kataloge („(Kontext-Katalog“, „Sicherheitsanforderungs-Katalog“, siehe auch nachfolgend) (für z.B. kryptographische Prüfsummen), Zeitpunkte, Gültigkeit, oder Selbsteinstufung des Software-Integritätslevels der Programmdaten. Hier kann allgemein auch von einem „Kontext-Katalog“ gesprochen werden. Die Informationen über die Sicherheitsanforderungen an die Programmdaten(sog. „Sicherheitsanforderungs-Katalog‟) umfassen z.B. eine Beschreibung der Konformität mit Sicherheitsanforderungen aus anzuwenden Normen, z.B. die eingangs schon genannte DIN EN IS025519 für Landwirtschaft, die DIN EN ISO 13849 für Maschinen oder die DIN EN ISO26262 für Automotive.
-
Diese Überprüfung bzw. dieser Abgleich kann ggf. auch in mehreren Stufen erfolgen, d.h. dass zunächst ein Aspekt der Anforderung abgefragt und geprüft wird und danach - aber ggf. auch nur, wenn dieser erste Aspekt erfüllt ist - ein weiterer Aspekt. Beispielhafte Themen bzw. Anforderungen, die hierbei geprüft bzw. adressiert werden, werden im Folgenden beschrieben.
-
Aus dem Bereich der funktionalen Sicherheit (Safety Domäne) kann vom Anwender z. B. die geplante Anwendung oder der Anwendungsfall abgefragt werden, die mit den gemäß Sicherheitsverzeichnis zugelassenen Bereichen (Domänen) der Programmdaten abgeglichen wird. Hinsichtlich eines Integritätslevels kann vom Anwender z.B. ein erforderliches Integritätslevel (das er z.B. für seine Anwendung benötigt) abgefragt werden, das mit dem gemäß Sicherheitsverzeichnis verfügbaren Integritätslevel der Programmdaten abgeglichen wird. Aus dem Bereich ‚Länderspezifika‘ kann vom Anwender z. B. die gemäß Sicherheitsverzeichnis erforderliche Regularien-Compliance (z.B. bestimmte Sicherheits- oder sonstige Anforderungen, die im gewünschten Einsatzland erforderlich ist) abgefragt werden, die dann mit der gemäß Sicherheitsverzeichnis dokumentierten Regularien-Compliance, erforderlichen Zusatzmaßnahmen, oder expliziten Ausschlusskriterien abgeglichen wird. Aus dem Bereich ‚Funktionsspezifika‘ können vom Anwender z.B. erforderliche Parameterwerte für die einzelnen Funktionen der Programmdaten abgefragt werden, die dann mit gemäß Sicherheitsverzeichnis dokumentierten Parameterwerten hierfür abgeglichen werden.
-
Wenn diese automatisierte Bewertung ergibt, dass die Anforderungen erfüllt sind, werden die Programmdaten zum Herunterladen (bzw. für eine weitere Verwendung) bereitgestellt. Ergänzend hierzu wird insbesondere ein Bereitstellungsverzeichnis erstellt, das Informationen über die Überprüfung umfasst und zusammen mit den Programmdaten zum Herunterladen bereitgestellt wird. Die Programmdaten können dann auch aus dem Eingangsbereich entfernt bzw. gelöscht werden, insbesondere aber erst, nachdem sie heruntergeladen bzw. vom Anwender bezogen worden sind.
-
Die Informationen, die das Bereitstellungsverzeichnis umfasst, können z.B. die folgenden sein: ein Identifier der überprüften Programmdaten bzw. Software, ein Identifier eines Bereitstellungs- bzw. Deployment Protokolls, Randbedingungen (z.B. Bereitstellungsziel, End-Anwender, Datum; der Anwender kann z.B. Randbedingungen insofern beeinflussen, als der die Programmdaten in bestimmten Ländern oder für einen bestimmte Dauer oder einen bestimmten Zweck verwenden will) der Überprüfung und/oder Bereitstellung, ein ausführliches Ergebnis der Überprüfung, insbesondere inklusive Klassifizierung der Sicherheitsanforderung bzw. des Safety-Integrity-Levels für die überprüften Normen, sowie zulässige Zielmärkte, und ein kodiertes, kurzes Ergebnis mit den Randbedingungen. Das vollständige Bereitstellungsverzeichnis (also eine Art „Deployment Katalog“) kann auch direkt an den Anwender bzw. End-Anwender überstellt werden. Das kurze Ergebnis kann bei entsprechender Konfiguration z.B. an das Bereitstellungsziel, d.h. das System bzw. die Recheneinheit, in die die Programmdaten integriert werden sollen, überstellt werden. Auf diese Weise können die Programmdaten bzw. die Software freigegeben werden; hierzu kann z.B. in einem Header der Programmdaten ein entsprechender Hinweis eingefügt werden. Die Programmdaten können danach (mit dem geänderten Header) an das Bereitstellungsziel überstellt bzw. übermittelt werden. Zudem kann das erwähnte Bereitstellungsprotokoll an den Eingangsbereich überstellt werden. Das Bereitstellungsprotokoll umfasst z.B. Informationen über die Überprüfung, zu den Referenzdaten und den Anforderungen. Die Programmdaten können, wie erwähnt, dann aus dem Eingangsbereich entfernt bzw. gelöscht werden.
-
Wenn die Anforderungen hingegen nicht erfüllt sind (also eine negative Bewertung vorliegt), so wird zweckmäßigerweise ein Fehlerverzeichnis oder ein Fehlerreport („Error Log“) erstellt und zum Herunterladen bereitgestellt. Insbesondere werden die Programmdaten dann ebenfalls aus dem Eingangsbereich entfernt bzw. gelöscht, aber eben ohne, dass sie heruntergeladen worden sind, und insbesondere auch ohne, dass sie heruntergeladen werden konnten. Die Informationen, die das Fehlerverzeichnis umfasst, können z.B. die folgenden sein: ein Identifier der überprüften Programmdaten bzw. Software, ein Identifier des Bereitstellungs- bzw. Deployment Protokolls, Randbedingungen (z.B. Bereitstellungsziel, End-Anwender, Datum) der Überprüfung und/oder Bereitstellung, und ein Ergebnis der Überprüfung, insbesondere inklusive Begründung der negativen Bewertung. Das Fehlerverzeichnis kann an den End-Anwender überstellt werden, das Bereitstellungsprotokoll kann an den Eingangsbereich überstellt werden, die Programmdaten können, wie erwähnt, aus dem Eingangsbereich entfernt bzw. gelöscht werden.
-
In beiden Fällen, also bei positiver und negativer Bewertung bzw. bei Erfüllen und Nicht-Erfüllen der Anforderungen kann also das Bereitstellungsprotokoll erstellt werden. Dieses umfasst, wie schon erwähnt, z.B. Informationen über die Überprüfung, zu den Referenzdaten und den Anforderungen. Dies kann z.B. auch eine Verlinkung zum Sicherheitsverzeichnis umfassen, das eine Risiko-Analyse der angeforderten Programmdaten enthält. Auch ein Protokoll des Abgleichs der Anforderungen kann umfasst sein. Das Bereitstellungsprotokoll kann dann ausgewertet und archiviert werden.
-
Bevorzugt wird nach dem Bereitstellen der Programmdaten ein Integrationsverzeichnis bereitgestellt, das Informationen über Tests und/oder Maßnahmen zur Integration der Programmdaten auf einer Recheneinheit bzw. einem System umfasst, und zusammen mit den Programmdaten zum Herunterladen bereitgestellt. Auf diese Weise kann auch die Integration beim Anwender bzw. auf dessen Recheneinheit oder System gesteuert werden.
-
In dem Eingangsbereich können hierfür neben dem Integrationsverzeichnis auch Testdaten und/oder Testvektoren bereitgestellt werden. Unter Testvektoren können hierbei strukturierte Datensammlungen verstanden werden, mit denen bestimmte Testablaufe definiert werden. Diese können z.B. umfassen, welcher Speicherplatz benötigt wird, welche Eingangsdaten nötig sind, und was das Resultat sein soll.
-
Die vom Integrationsverzeichnis umfassten und insbesondere auch für die Integration erforderlichen Tests und Maßnahmen können in drei Gruppen unterteilt werden: erstens, Tests bzw. Maßnahmen zur funktionalen Absicherung vor Abschluss der Integration, zweitens, Tests bzw. Maßnahmen zur Absicherung der Software-Integrität, und drittens, Tests bzw. Maßnahmen während der Laufzeit der Programmdaten auf dem betreffenden System.
-
Die Tests bzw. Maßnahmen vor einer abschließenden Integration sind zweckmäßigerweise vom Anwender durchzuführen, im beschriebenen Format zu protokollieren und an das Rechensystem zu übergeben. Sie werden dann insbesondere Bestandteil eines Integrationsprotokolls und können erforderlich sein, um eine Integrationsfreigabe zu erhalten. Vom Rechensystem werden damit dann also Informationen über eine gemäß Integrationsverzeichnis durchgeführte Integration empfangen. Diese Informationen können dann auf vorgegebene Anforderungen überprüft werden, und, wenn die Anforderungen erfüllt sind, kann die Integrationsfreigabe für die Programmdaten in Bezug auf die Recheneinheit bzw. das System erteilt bzw. bereitgestellt werden. Zweckmäßig ist es, wenn die Integrationsfreigabe nur dann erteilt wird, wenn die Programmdaten, wie zuvor erwähnt, für die Bereitstellung freigegeben wurden, also z.B. im Header der Programmdaten ein entsprechender Hinweis eingefügt wurde.
-
Bei negativen Tests bzw. Maßnahmen vor abschließender Integration, d.h. wenn die Anforderungen nicht erfüllt sind, kann wieder ein Fehlerverzeichnis oder Fehlerprotokoll erstellt werden. Im Header der Programmdaten bzw. Software kann zudem vermerkt werden, dass die Integration fehlgeschlagen ist. In beiden Fällen aber kann ein Integrationsprotokoll erstellt werden.
-
Bei positiven Tests bzw. Maßnahmen vor abschließender Integration können zusätzlich die erwähnten Tests bzw. Maßnahmen zur Absicherung der Software-Integrität und die Tests bzw. Maßnahmen während der Laufzeit durchgeführt werden. Die Tests bzw. Maßnahmen zur Absicherung der Software-Integrität können vom End-Anwender z.B. die Durchführung einer Kompositionsanalyse erfordern. Diese bestimmt, von welchen Funktionen die bereitgestellten Programmdaten bzw. Software verwendet werden. Handelt es sich bei den Verwendern um Funktionen, die im selben Vorgang bereitgestellt und überstellt wurden, verfügen diese Funktionen z.B. über eine funktionsbasierte Risikobewertung, die über das Bereitstellungsprotokoll und die hierin verlinkte Risiko-Analyse bezogen werden kann.
-
Auf Basis der Kompositionsanalyse und der Daten aus dem Bereitstellungsverzeichnis kann dann eine Kompositionsbewertung erstellt werden, die Systemfunktionen und den Integritätslevel mit den von ihnen verwendeten, ausgelieferten Funktionen und deren Integritätslevel listet. Diese Liste kann Bestandteil des Integrationsverzeichnisses sein.
-
Zusätzlich können vom End-Anwender z.B. Daten für eine System-Risiko-Analyse („Hazard and Risk Analysis“) angefragt werden. In diesem Fall kann das Rechensystem auf die Risiko-Analyse des Bereitstellungsverzeichnisses zugreifen und eine Kompositionsrisiko-Analyse erstellen. Diese besteht z.B. aus einer Darstellung der bereitgestellten Programmdaten inklusive Risikodaten, einer Ausweisung der verwendeten Funktionen aus den überstellten Programmdaten sowie einer Ausweisung der Komposition inklusive Bewertung. Diese kann im Integrationsverzeichnis hinterlegt und vom End-Anwender für die Erstellung einer System-Risiko-Analyse verwendet werden.
-
Zusätzlich können vom Anwender die Testdaten und Daten zur erwähnten Analyse während der Laufzeit angefragt und anlog zu den Testdaten für die funktionale Absicherung zur Verfügung gestellt werden. Sie beinhalten z.B. Testdaten oder Testvektoren zur Überprüfung der Funktionalität während der Laufzeit bzw. auf dem Bereitstellungsziel (Selbst-Test), und Grenzwerte zur Überprüfung und Beschränkung von Eingangsparametern während der Laufzeit. Bei einem solchen Test zur Laufzeit kann z.B. eine Prüfsumme über den vorhandenen Code gebildet und mit einem Referenzwert verglichen werden, oder es können auch (einfache) Test mit bestimmten Eingangsdaten und einem Vergleich der Ausgangsdaten mit Referenzdaten durchgeführt werden.
-
Abschließend kann wieder das Integrationsprotokoll erstellt werden, das z.B. sämtliche Informationen aus dem Integrationsverzeichnis und dem Fehlerverzeichnis enthält. Es kann außerdem eine Verlinkung zum Sicherheitsverzeichnis enthalten, das die Risiko-Analyse der angeforderten Programmdaten enthält, sowie ein Protokoll der Kommunikation zwischen End-Anwender bzw. Bereitstellungsziel und dem Eingangsbereich. Das Integrationsprotokoll kann dann z.B. für eine Analyse des Kundenverhaltens ausgewertet und dann archiviert werden.
-
Wenn bereits ein System des Anwenders geänderte Sicherheitsanforderungen an die Programmdaten benötigt, kann das beschriebene Vorgehen mit den entsprechend geänderten Anforderungen, die an das Rechensystem übermittelt werden, erneut durchlaufen werden.
-
Ein erfindungsgemäßes Rechensystem z.B. ein Server, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Rechensystem noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete 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.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
- 2 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer weiteren bevorzugten Ausführungsform.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform dargestellt, und zwar insbesondere anhand eines Rechensystems 120, das entsprechend dazu eingerichtet ist.
-
Beispielsweise will ein Hersteller oder Anbieter 100 (Entwickler) von z.B. einer bestimmten Softwareanwendung für ein Steuergerät eines Fahrzeugs oder einer bestimmten Funktion hierfür Programmdaten 110, z.B. eine Softwareanwendung oder Funktion oder auch bestimmte Daten hierfür, in z.B. einer aktuellen Version für Kunden zur Verfügung stellen. Dies soll auf dem Rechensystem 120 bzw. dort einer Datenbank 130 erfolgen, von wo die Programmdaten 110 dann z.B. heruntergeladen werden können.
-
Neben den Programmdaten 110 selbst stellt der Anbieter 100 auch noch Referenzdaten zur Verfügung, die einerseits Informationen 112 über die Programmdaten 110 sowie Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 umfassen. Die Informationen 112 über die Programmdaten 110 können z.B. die verantwortlichen Hersteller (dies kann einer sein, denkbar sind aber auch mehrere Hersteller) der Programmdaten, verwendete Normen, die Version der Programmdaten, einen eindeutigen Identifier für die Version sowie mitgelieferte Kataloge, Zeitpunkte, Gültigkeit, oder Selbsteinstufung des Software-Integritätslevels der Programmdaten umfassen. Die Informationen 112 stellen damit einen „Kontext-Katalog“ dar. Die Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 können z.B. eine Beschreibung der Konformität mit Sicherheitsanforderungen aus anzuwenden Normen umfassen. Für das Beispiel eines Fahrzeugs ist dies z.B. die DIN EN ISO26262 für Automotive.
-
Nach einer Prüfung werden die Programmdaten 110 dann auf der Datenbank 130 bzw. auf einem speziellen Teilbereich 124 für die entsprechenden Sicherheitsanforderungen (die Teilbereiche 126, 128 sind für andere Sicherheitsanforderungen vorgesehen) hinterlegt. Zudem wird vom Rechensystem 120 ein Sicherheitsverzeichnis 150 erstellt, das z.B. sämtliche Informationen 112 und 114 umfasst, sowie z.B. auch ein Datum und ein Ergebnis der Überprüfung, ggf. auch eine Klassifizierung der Sicherheitsanforderung für die überprüften Normen.
-
Das vorgeschlagene Verfahren betrifft nun insbesondere das Bereitstellen dieser Programmdaten 110 aus der Datenbank 130 für einen Kunden oder Anwender 165, der diese Programmdaten 110 auf ein System 160 (oder ein Steuergerät) herunterladen und dort integrieren will. Hierzu stellt der Anwender - oder ggf. auch automatisiert das System 160 - eine Anfrage 140 zum Bereitstellen der Programmdaten 110 an das Rechensystem 120. Diese Anfrage 140 wird vom Rechensystem 120 empfangen.
-
Die Programmdaten 110 aus der Datenbank 130 werden daraufhin auf einem von dem Rechensystem 120 getrennt von der Datenbank 130 bereitgestellten Eingangsbereich 122 (oder Austauschbereich) zwischengespeichert. Daraufhin werden vom Rechensystem 120 Anforderungen 152 an die Programmdaten empfangen und es wird überprüft, ob die Anforderungen 152 von den Programmdaten 110 erfüllt werden. Dies erfolgt durch Abgleichen der Anforderungen 152 mit Informationen aus einem Sicherheitsverzeichnis 150, die Informationen 112 über die Programmdaten 110 sowie Informationen 114 über Sicherheitsanforderungen an die Programmdaten 120 umfasst. Das Empfangen der Anforderungen 152 kann, wie schon erwähnt, auch mehrstufig bzw. in mehreren Schritten erfolgen. Wenn die Anforderungen 152 erfüllt sind, werden die Programmdaten 110 zum Herunterladen durch z.B. den Anwender 165 oder - ggf. automatisiert - auf das System 160 bereitgestellt.
-
Außerdem wird, wenn die Anforderungen 152 erfüllt sind, ein Bereitstellungsverzeichnis 142 erstellt, das Informationen über die Überprüfung umfasst, und zusammen mit den Programmdaten 110 zum Herunterladen bereitgestellt. Die Informationen, die das Bereitstellungsverzeichnis umfasst, können z.B. ein Identifier der überprüften Programmdaten 110, ein ausführliches Ergebnis der Überprüfung sowie ein kurzes Ergebnis mit den Randbedingungen sein (weitere Informationen wurden vorstehend schon genannt). Das vollständige Bereitstellungsverzeichnis kann auch direkt an den Anwender 165 überstellt werden. Das kurze Ergebnis kann bei entsprechender Konfiguration z.B. an das Bereitstellungsziel, d.h. hier das System 160 überstellt werden. Auf diese Weise können die Programmdaten 110 freigegeben werden; hierzu kann z.B. in einem Header der Programmdaten ein entsprechender Hinweis 111 eingefügt werden.
-
Wenn die Anforderungen 152 hingegen nicht erfüllt sein sollten (das kann auch dann schon der Fall sein, wenn bei einem mehrstufigen Empfang in der ersten Stufe die Anforderungen schon nicht erfüllt sind), wird ein Fehlerverzeichnis 143 erstellt und ebenfalls zum Herunterladen bereitgestellt bzw. direkt an den Anwender 165 überstellt. Die Programmdaten 110 werden dann aber aus dem Eingangsbereich 122 entfernt bzw. gelöscht.
-
Unabhängig vom Ausgang der Überprüfung wird weiterhin ein Bereitstellungsprotokoll 144 erstellt, das Informationen über die Überprüfung, zu den Referenzdaten und den Anforderungen umfasst.
-
Neben dem Bereitstellen der Programmdaten 120 kann im Rahmen des vorgeschlagenen Vorgehens dann auch noch eine Integration der Programmdaten in z.B. das System 160 erfolgen. Hierzu ist in 2 schematisch ein Ablauf eines erfindungsgemäßen Verfahrens in einer weiteren bevorzugten Ausführungsform dargestellt. Der Ablauf hierbei ist ähnlich dem vorstehenden beschriebenen, Abweichungen sollen nachfolgend erläutert werden (gleiche Komponenten sind mit gleichen Bezugszeichen wie in 1 bezeichnet).
-
Nach dem Bereitstellen der Programmdaten 100, die dann auch ggf. schon auf das System 160 heruntergeladen wurden, wird ein Integrationsverzeichnis 242 bereitgestellt, das Informationen über Tests und/oder Maßnahmen zur Integration der Programmdaten 100 auf dem System (es kann sich hierbei z.B. um eine Recheneinheit wie ein Steuergerät handeln) umfasst, und zusammen mit den Programmdaten 110 zum Herunterladen für den Anwender 165 bereitgestellt wird. Für die Erstellung des Integrationsverzeichnisses kann z.B. auf das Bereitstellungsverzeichnis 142 sowie ggf. ein allgemeines Verzeichnis 250 für eine Integration zurückgegriffen werden.
-
Die Integration kann dann automatisiert vom System 160 oder ggf. vom Anwender 165 durchgeführt werden. Dabei oder danach werden Informationen 240 über eine gemäß Integrationsverzeichnis 242 durchgeführte Integration an das Rechensystem 120 übermittelt und von diesem empfangen. Diese Informationen 240 werden auf vorgegebene Anforderungen überprüft, und, wenn die Anforderungen erfüllt sind, wird eine Integrationsfreigabe 246 für die Programmdaten 110 in Bezug auf das System 160 erteilt. Dabei können vor abschließender Integration zusätzlich die erwähnten Tests bzw. Maßnahmen zur Absicherung der Software-Integrität und die Tests bzw. Maßnahmen während der Laufzeit durchgeführt werden.
-
Bei negativen Tests bzw. Maßnahmen vor abschließender Integration, d.h. wenn die Anforderungen nicht erfüllt sind, kann ein Fehlerverzeichnis 243 erstellt werden. Im Header der Programmdaten 110 kann dann mit einem Hinweis 211 vermerkt werden, dass die Integration fehlgeschlagen ist. In beiden Fällen, d.h. bei Freigabe und bei fehlgeschlagener Integration kann ein Integrationsprotokoll 244 erstellt werden, das z.B. sämtliche Informationen aus dem Integrationsverzeichnis und ggf. dem Fehlerverzeichnis enthält.
