Die Erfindung betrifft ein Verfahren zur Verifizierung von generierter Software, insbesondere eines Computerprogramms, welche Software mittels eines Software-Generators erzeugt wird, und/ oder von generiertem Code, welcher mittels eines Code-Generators erzeugt wird, wobei die Software bzw. der Code von dem Software-Generator bzw. dem Code-Generator basierend auf einer System- Beschreibung erstellt wird.

Die ISO 26262 ist eine ISO-Norm für sicherheitsrelevante elektrische/ elektronische Systeme in Kraftfahrzeugen und hat sich seit ihrer Einführung im Jahr 2011 rasch als wichtiger Leitfaden für die Entwicklung von Steuergeräten für Kraftfahrzeuge etabliert. Die ISO 26262 legt jene Regeln fest, nach denen sicherheitsrelevante Hardware und Software entwickelt werden muss.

Neue Softwareentwicklungen insbesondere für Steuergerät für Kraftfahrzeuge erfolgen zumeist nach dem AUTOSAR ("Automotive Open System Architecture) Standard. Um die Standardisierungsanforderungen von AUTOSAR und die Sicherheitsanforderungen der ISO 26262 zu erfüllen, kann auf Basis-Software zurückgegriffen werden, die nach ISO 26262 entwickelt wurde. Eine Herausforderung blieb bisher allerdings das AUTOSAR Runtime Environment (RTE). Die AUTOSAR RTE wird in einem AUTOS AR-basierten Fahrzeugsteuergerät zum Austausch von Informationen zwischen Softwarekomponenten verwendet. Wenn das Steuergerät sicherheitsrelevante Aufgaben übernimmt, dann muss sichergestellt werden, dass die RTE dabei keine Fehler verursachen kann.

Sicherheitsziel (Safety Goal) für die RTE

Zur Beantwortung der Frage, was es bedeutet, dass eine RTE„korrekt bzw. sicher funktioniert", wird von folgenden Annahmen ausgegangen:

• Die RTE wird auf einer sicherheitsrelevanten ECU („Engine Control Unit", Motor Steuergerät) mit einer ASIL-Einstufung („Automotive Safety Integrity Level") verwendet.

• Informationen, die über die RTE zwischen den Softwarekomponenten dieser ECU intern ausgetauscht werden, sind sicherheitsrelevant. Die RTE„erbt" also den ASIL der Funktionen, die darauf zugreifen.

Als Sicherheitsziel (IS026262 Safety Goal)„sichere Datenübertragung" werden hier folgende Garantien verstanden: RTE-Nachrichten werden von einer Sende-Komponente geschrieben und können von vorher festgelegten Empfängern gelesen werden, und es gilt:

• Die Empfänger lesen dabei die Daten, wie sie vorher geschrieben wurden.

• RTE-Nachrichten werden konsistent (d.h. alle zugehörigen Einzelsignale zusammen) übertragen.

• RTE-Nachrichten sind nur für die vorher festgelegten Empfänger sichtbar.

• Optional können vorher festgelegte Runnables aktiviert werden, sobald eine RTE-Nach- richt geschrieben wird.

• Sonst hat die Datenübertragung keine weiteren Effekte.

RTE-Nachrichten sind Sammlungen von Einzelsignalen, die zusammengehören.

Die RTE ist für gewöhnlich eine generierte Software, deren Fehlerfreiheit sehr schwer nachzuweisen ist. Zum Nachweis der Fehlerfreiheit existieren prinzipiell mehrere Möglichkeiten:

• Verwendung eines qualifizierten Generators für die Software, im Falle einer RTE eines RTE-Generators, der eine„fehlerfreie Software" bzw. eine„fehlerfreie RTE" erzeugt

• Prüfung/ Review des generierten Codes, insbesondere RTE-Codes

• Tests

Fehlerfreie Generatoren, insbesondere RTE-Generatoren zu entwickeln erscheint unrealistisch: Aufgrund der hohen Komplexität solcher Tools würde eine Entwicklung nach ISO 26262 sehr teuer werden. Selbst wenn man die Kosten nur einmal trägt, besteht noch das Problem, dass ein„zertifizierter Generator" so lange für seine Entwicklung benötigt, dass er bei seiner Fertigstellung kaum mehr der aktuellen AUTOSAR- Version entspricht. Dieser Ansatz ist also teuer und auch sehr unflexibel. Tests und manuelle Reviews des generierten RTE-Codes sind aktuell die einzigen Möglichkeiten. Sie sind schwer durchzuführen und entsprechend aufwendig. Um die notwendige Testabdeckung zu erreichen, muss ein RTE-Integrationstester im generierten Code die automatisch angelegten Puffer-Variablen, die generierten Datentypen und Zugriffs-Makros zuerst analysieren und dann entsprechende Tests erstellen.

Es ist eine Aufgabe, eine verbesserte Möglichkeit zur Verifizierung von generierter Software, d.h. der Überprüfung der Software auf Fehlerfreiheit zur Verfügung zu stellen.

Weiters ist es eine Aufgabe der Erfindung, eine verbesserte Möglichkeit zur Verifizierung von generierter Software für Steuergeräte für Kraftfahrzeuge zur Verfügung zu stellen.

Diese Aufgaben werden mit einem eingangs erwähnten Verfahren dadurch gelöst, dass erfindungsgemäß zur Verifizierung der Software bzw. des Codes eine Verifizierungseinrichtung vorgesehen ist, wobei a) die System-Beschreibung in die Verifizierungseinrichtung eingelesen wird, b) die Verifizierungseinrichtung an Hand der System-Beschreibung ein oder mehrere Software-Code-Muster bzw. Code-Muster erstellt, c) der Quelltext der generierten Software bzw. der generierte Code in die Verifizierungseinrichtung eingelesen wird, und d) die Verifizierungseinrichtung den Quelltext bzw. den Code auf Vorhandensein aller Software-Code-Muster bzw. Code-Muster überprüft.

Erfindungsgemäß wird somit eine statische Analyse durchgeführt, d.h., die zu verifizierende Software bzw. Computerprogramm läuft während der Verifikation nicht. Bei dieser Analyse wird von der Verifizierungseinrichtung, ausgehend von der System-Beschreibung, welche die Software beschreibt, ermittelt, welche Bedingungen und gegebenenfalls Items in dem generierten Code enthalten sein müssen, und dieses„Wissen" wird von der Verifizierungseinrichtung direkt in dem generierten Code untersucht. Dazu werden syntaktische Software-Code- Muster erzeugt, die im Software-Code vorhanden sein sollten bzw. sein müssen, und der Code wird dann auf das Vorhandensein aller dieser Software-Code-Muster untersucht.„Items" sind dabei Elemente/ Bestandteile, wie etwa Ports, Tasks, Components, etc. welche in der System- Beschreibung als Teile des Systems definiert werden. Sind alle Software-Code-Muster fehlerfrei vorhanden, so ist auch die generierte Software fehlerfrei.

Bei einer Ausführungsform der Erfindung ist vorgesehen, dass die System-Beschreibung in Form eines abstrakten Systemmodells gegeben ist. Beispielsweise kann die System-Beschreibung im Falle, dass es sich bei der Software um eine RTE, insbesondere eine AUTOSAR RTE für ein Steuergerät eines Kraftfahrzeuges handelt, eine (AUTOSAR) ECU Konfiguration sein, welche ECU Konfiguration eine/ die AUTOSAR System-Description zusammen mit einer/ der AUTOSAR ECU Description enthält.

Es kann vorgesehen sein, dass die System-Beschreibung zumindest einen Satz von Eigenschaften und/ oder zumindest einen Satz von Items, welche die zu erzeugende Software beschreiben, umfasst.

Bei einer konkreten Ausführungsform der Erfindung ist dabei vorgesehen, dass zur Erstellung des zumindest einen Code-Musters in Schritt b) die Verifizierungseinrichtung an Hand der System-Beschreibung alle Bedingungen erzeugt, welche Bedingungen den Kontext beschreiben, für den die generierte Software erzeugt wurde. Der Kontext gilt für das Zielsystem, in dem die generierte Software läuft, nicht für die Generierung. Im Zusammenhang mit einer AUTOSAR RTE können solche Bedingungen z.B. unter anderem sein:„memory protection is used" ,„multiple instantiation is possible" ,„all code is available as source code" .

Weiters ist dann vorgesehen, dass die Verifizierungseinrichtung an Hand der erzeugten Bedingungen ein oder mehrere Code-Vorlagen, welche bei Vorliegen der erzeugten Bedingungen für eine Software-Erzeugung zulässig sind, aus einer Menge an vorgegebenen Code-Vorlagen auswählt.

Typischerweise ist vorgesehen, dass die Menge an vorgegebenen Code-Vorlagen in einer der Verifizierungseinrichtung zugeordneten Datenbank abgespeichert sind.

In einem nächsten Schritt ist dann noch vorgesehen, dass die ausgewählten Code-Vorlagen von der Verifizierungseinrichtung instantiiert werden, d.h., dass in den ausgewählten Code- Vorlagen vorhandene Variablen durch Werte bzw. Informationen ersetzt werden, welche von der Verifizierungseinrichtung aus der System-Beschreibung ermittelt werden. Die derart erstellten Code-Muster werden nun von der Verifizierungseinrichtung in dem Quelltext der generierten Software gesucht, und bei positivem Auffinden aller (korrekten) Code- Muster ist die Verifizierung positiv, d.h. die generierte Software ist fehlerfrei.

Weiters ist vorgesehen, dass die Verifizierungseinrichtung zumindest eine Verifizierungssoftware umfasst bzw. aus einer Verifizierungssoftware besteht. Üblicherweise ist die Verifizierungseinrichtung eine eigene Software, im Folgenden auch Verifizierungs-Tool genannt.

Zweckmäßig kann die Erfindung eingesetzt werden, wenn die generierte Software eine Laufzeitumgebung ist.

Von besonderem Vorteil ist die Erfindung, wenn die generierte Software eine Software zur Ausführung auf einem Gerät, beispielsweise auf einem Steuergerät ist.

Weiters ist es noch günstig, wenn die System-Beschreibung Informationen bezüglich des Gerätes, für das die generierte Software vorgesehen ist, beinhaltet.

Beispielsweise enthält ein Steuergerät verschiedene Ports. Die Information bezüglich des (Steuer-)Gerätes, welcher in der System-Beschreibung mit enthalten und bei der Generierung der Software zu berücksichtigen ist, enthält dann z.B. die Namen, Anzahl und Definition der Ports. Diese werden bei der Generierung der Software berücksichtigt. Weiters kann vorgesehen sein, dass das Steuergerät Services anbietet.„Services" sind dabei Funktionen, die von einem Nutzer der RTE abgerufen werden und durch die Software (RTE) aktiviert werden. Vorzugsweise sind Informationen bezüglich dieser Services ebenfalls in der System- Beschreibung enthalten.

Andererseits geht diese Information auch bei der Erzeugung der Software-Code-Muster ein, und aus den Bedingungen und diesen Informationen (Name, Anzahl, Definition der Ports) werden die Software-Code-Muster von den Verifizierungsmitteln erstellt.

Weiters ist mit Vorteil vorgesehen, dass bei einer Software in Form einer Laufzeitumgebung, insbesondere einer Laufzeitumgebung für ein Steuergerät, welches Steuergerät vorzugsweise für ein Kraftfahrzeug vorgesehen ist, die System-Beschreibung zumindest enthält:

-) Namen, Anzahl und Definition von Ports, und/ oder

-) Services im Steuergerät. Bei einer konkreten Ausführungsform ist dabei vorgesehen, dass die System-Beschreibung eine ECU Konfiguration, insbesondere eine AUTOSAR ECU Konfiguration ist, welche ECU Konfiguration eine System-Description, insbesondere eine AUTOSAR System-Description zusammen mit einer ECU Description, insbesondere einer AUTOSAR ECU Description enthält.

Vorzugsweise ist vorgesehen, dass die Verifizierungseinrichtung überprüft, ob alle Software- Code-Muster in dem Quelltext vorhanden sind, und wobei die Verifizierungseinrichtung einen Ausgabereport erstellt, wobei der Ausgabereport den markierten Quelltext enthält, in welchem die erzeugten Software-Code-Muster markiert sind.

Es kann in diesem Zusammenhang ein sogenannter„Colored Source Code" erzeugt werden, d.h. ein Listing des generierten Codes, in dem alle gefundenen Code-Muster (Patterns) markiert, beispielsweise farblich markiert sind, etwa mit einer grünen Einfärbung. Dieser markierte Code kann dann„manuell" von einem Benutzer einfach dahingehend überprüft werden, ob alle Code-Teile entsprechend (farblich) markiert sind. Alle Code-Teile, welche der Verifizierungseinrichtung bekannten Code-Mustern entsprechen, sind entsprechend markiert, d.h. in diesem Fall eingefärbt.

Bleiben Codeteile übrig, die nicht markiert sind, dann hat entweder der Software-Generator einen Fehler gemacht, oder der Benutzer hat ein nicht unterstütztes Software-Feature, insbesondere ein nicht unterstütztes Autosar RTE-Feature verwendet. Insbesondere in sicherheitsrelevanten Softwarekomponenten sollte der Autosar RTE-Anwender nur einen eingeschränkten Funktionsumfang verwenden (das Autosar RTE-Verify Safety Manual beschreibt, welche Funktionen unterstützt sind). Werden darüber hinaus weitere Funktionen verwendet, dann bleiben diese im Colored-Source-Code ungefärbt und müssen manuell - auf die klassische Art und Weise durch Test und Review - geprüft werden.

Weiters ist es von Vorteil, wenn die Verifizierungseinrichtung überprüft, ob alle Software- Code-Muster in dem Quelltext vorhanden sind, und wobei die Verifizierungseinrichtung einen Fehlerreport erzeugt, welcher alle Software-Code-Muster auflistet, welche von der Verifizierungseinrichtung im Quelltext nicht gefunden wurden.

Alternativ erzeugt die Verifizierungseinrichtung einen Report, in welchem jene Code-Muster aufgelistet sind, welche von der Verifizierungseinrichtung erwartet wurden und welche gefunden wurden. Die Verifizierung ist erfolgreich, wenn der markierte Quellcode keine nicht-markierten Bereiche enthält, und wenn der Fehlerbericht leer ist bzw. wenn die erwarteten und aufgefundenen Code-Muster übereinstimmen.

Insbesondere ist es schließlich auch noch von Vorteil, wenn die Verifizierungseinrichtung einen Konfigurations-Feedback-Report ausgibt, welcher alle Informationen und/ oder Bedingungen enthält, welche von der Verifizierungseinrichtung aus der System-Beschreibung ermittelt wurden, welche für die Generierung der Software relevant sind.

Die System-Beschreibung, welche zur Generierung der Software verwendet wird, ergibt sich aus dem sogenannten System-Design, aus welchem mittels eines entsprechenden Design- Tools, z.B. dem Tool„DaVinci Developer", die System-Beschreibung erzeugt wird.

In dem Konfigurations-Feedback-Report wird ein Subset des System-Designs dargestellt, welches als Input für die Generierung der Software benutzt wird. Der Benutzer kann an Hand dieses Konfigurations-Feedback-Reports daher einfach überprüfen, ob die verwendete System-Beschreibung dieselbe (zumindest in Bezug auf die für die Generierung relevanten Informationen) ist wie jene, die sich aus dem Konfigurations-Feedback-Report ergibt.

Bei einer End-to-End-Überprüfung durch den Benutzer können somit Fehler in der Generie- rungskette der Software ausgeschlossen werden, nämlich insbesondere, ob

-) der Generator und die Verifizierungseinrichtung mit falschem Input gearbeitet haben;

-) der Input leer war, was zu einem trivialen "Empty"-Fehler führen würde.

Weiters werden die eingangs genannten Aufgaben noch mit einer Verifizierungseinrichtung, insbesondere einer Verifizierungssoftware zum Durchführen eines oben beschriebenen Verfahrens gelöst.

Weiters betrifft die Erfindung eine Software, insbesondere Computerprogramm, z.B. Steuerungssoftware, für ein Kraftfahrzeug, wobei die Software nach einem oben genannten Verfahren verifiziert ist.

Von Vorteil ist es, wenn die Software auf einem AUTOSAR Standard basiert. Von Vorteil ist es, wenn die Software in Form einer Laufzeitumgebung realisiert ist.

Von Vorteil ist es, wenn eine Systembeschreibung der Laufzeitumgebung zumindest enthält:

-) Namen, Anzahl und Definition von Ports, und/ oder

-) Services im Steuergerät.

Von Vorteil ist es, wenn die System-Beschreibung eine ECU Konfiguration, insbesondere eine AUTOSAR ECU Konfiguration ist, welche ECU Konfiguration eine System-Description, insbesondere eine AUTOSAR System-Description zusammen mit einer ECU Description, insbesondere einer AUTOSAR ECU Description enthält.

Schließlich betrifft die Erfindung noch ein Steuergerät für ein Kraftfahrzeug, auf welchem zumindest eine oben beschriebene Software bzw. ein oben beschriebenes Computerprogramm abläuft.

Im Folgenden ist die Erfindung an Hand eines nicht einschränkenden Beispiels näher erläutert, welches in der Zeichnung dargestellt ist. In dieser zeigt

Fig. 1 schematisch die Generierung einer RTE,

Fig. 2 schematisch den Ablauf eines erfindungsgemäßen Verifizierungsprozesses,

Fig. 3 eine schematische Darstellung einer Code-Vorlage, welche von einer Verifizierungseinrichtung zur Erzeugung eines Software-Code- Musters verwendet wird, und

Fig. 4 eine End-to-End Absicherung des Software-Generierungsprozesses.

Figur 1 zeigt schematisch den Prozess der Generierung einer Software 1. Bei dieser Software 1 kann es sich prinzipiell um beliebige Software handeln, im vorgestellten Beispiel handelt es sich um eine AUTOSAR RTE, im Folgenden auch RTE genannt. Für eine solche RTE ist das vorgestellte Verifizierungsverfahren von besonderem Vorteil.

Die Software (RTE) 1 wird, wie in Figur 1 gezeigt, mit einem Software-Generator 2 erzeugt, wobei die Software 1 von dem Software-Generator 2 basierend auf einer System-Beschreibung 3 erstellt wird. Die System-Beschreibung 3 kann dabei in Form eines abstrakten Systemmodells gegeben sein, und/ oder die System- Beschreibung 3 umfasst einen oder mehrere Sätze von Eigenschaften und/ oder einen oder mehrere Sätze von Befehlen, welche die zu erzeugende Software beschreiben.

Im Falle einer AUTOSAR RTE für ein Steuergerät eines Kraftfahrzeuges liegt die System-Beschreibung 3 in Form einer (AUTOSAR) ECU Konfiguration vor, welche eine AUTOSAR System- Description 3b zusammen mit einer AUTOSAR ECU Description 3a enthält.

Beispielsweise enthält die System-Beschreibung 3 Tasks, Ports und Services in dem Steuergerät, für welches die RTE vorgesehen ist. Tauschen zwei Softwarekomponenten beispielsweise Nachrichten über die RTE aus, dann müssen entsprechende„Ports" in der System-Beschreibung deklariert sein. Diese System-Beschreibung wird vom RTE-Generator 2 eingelesen. Damit der Nachrichtenaustausch sicher funktioniert, muss der RTE-Generator 2 Code 1 erzeugen, in dem die für den Nachrichtenaustausch benötigten Puffer korrekt angelegt und die Zugriffsfunktionen auf diese Puffer korrekt definiert sind. Die Puffer müssen groß genug sein, die Zugriffsfunktionen müssen die Puffergröße beachten und dürfen nicht unterbrechbar sein, etc.

Figur 1 zeigt weiters schematisch den erfindungsgemäßen Verifizierungsprozess. Wie Figur zu entnehmen ist, ist zur Verifizierung der Software 1 eine Verifizierungseinrichtung 4 in Form einer Verifizierungssoftware (im Folgenden auch als„Verifizierungs-Tool" bezeichnet) vorgesehen ist. Die System-Beschreibung 3 wird in die Verifizierungseinrichtung 4 eingelesen, an Hand der eingelesenen der System-Beschreibung 3 erstellt die Verifizierungseinrichtung 4 ein oder mehrere Software-Code-Muster 5 (siehe Figur 3), der Quelltext der generierten Software 1 wird in die Verifizierungseinrichtung 4 eingelesen, und die Verifizierungseinrichtung 4 überprüft den Quelltext 1 auf Vorhandensein aller von ihr erzeugten Software-Code-Muster 5.

Abschließend werden ein oder mehrere Reports 6 ausgegeben, auf welche weiter unten noch näher eingegangen wird.

Figur 2 zeigt noch einmal den Verifizierungsprozess in einer detaillierteren Darstellung. Wie Figur 2 zu entnehmen ist, werden zur Erstellung des zumindest einen Code-Musters 5 vorerst von der Verifizierungseinrichtung 4 an Hand der System-Beschreibung 3 alle Bedingungen 10 erzeugt, welche Bedingungen 10 den Kontext beschreiben, für den die generierte Software erzeugt wurde. Der Kontext gilt für das Zielsystem, in dem die generierte Software läuft, nicht für die Generierung.

Weiters ist dann vorgesehen, dass die Verifizierungseinrichtung 4 an Hand der erzeugten Bedingungen 10 ein oder mehrere Code-Vorlagen, welche bei Vorliegen der erzeugten Bedingungen 10 für eine Software-Erzeugung zulässig sind, aus einer Menge an vorgegebenen Code-Vorlagen auswählt. Typischerweise ist vorgesehen, dass die Menge an vorgegebenen Code-Vorlagen in einer der Verifizierungseinrichtung 4 zugeordneten Datenbank abgespeichert sind.

Insbesondere bei sicherheitskritischen Anwendungen (Safety) steht eine Anzahl an Code-Vorlagen zur Verfügung, welche sorgfältig getestet/ geprüft/ verifiziert sind und für eine Verwendung zur Erzeugung einer sicherheitsrelevanten Software qualifiziert sind. Solche Code-Vorlagen stehen der Verifizierungseinrichtung zur Verfügung.

Die Verifizierungseinrichtung 4 wählt also aus den zur Verfügung stehenden Code-Vorlagen die relevanten Code-Vorlagen aus, welche in dem Kontext, der durch die Software-Beschreibung beschrieben ist, für die Erzeugung der Software relevant sind.

In einem nächsten Schritt ist dann noch vorgesehen, dass die ausgewählten Code-Vorlagen von der Verifizierungseinrichtung 4 instantiiert werden, d.h., dass in den ausgewählten Code- Vorlagen vorhandene Variablen durch Werte ersetzt werden, welche von der Verifizierungseinrichtung 4 aus der System-Beschreibung 3 ermittelt werden.

Auf diese Weise werden aus den Code-Vorlagen die Code-Muster 5 erzeugt. Dabei kann es auch vorkommen, dass ein und dieselbe Code-Vorlage mehrmals, mit unterschiedlicher Belegung der Variablen, verwendet wird.

Um die Situation noch einmal an einem konkreten Beispiel einer AUTOSAR RTE zu erläutert: beispielsweise werden in der System-Beschreibung zwei Komponenten mit je einem Port beschrieben. Der eine Port der einen Komponenten dient als Ausgangsport, der Port der anderen Komponente als Eingangsport. Diese Ports werden in der Systembeschreibung verbunden. Die Verifizierungseinrichtung liest diese Systembeschreibung und„weiß" daher, dass es die beiden Komponenten und verbundenen Ports gibt. Für jede Komponente und für jeden Port muss es daher in der generierten RTE Code-Teile geben: • Code, um den Port anzulegen;

• Code um Ausgangsdaten abzusenden;

• Code um Eingangsdaten zu lesen, etc.

Die Verifizierungseinrichtung erstellt eine Liste von Code-Teilen (Code-Mustern), die es im Code geben muss. Aus der Datenbank kommen die Templates (Code-Vorlagen) mit Variablen für Portnamen, Komponentennamen, Namen der auszutauschenden Datentypen, etc. Diese Namen werden ebenfalls aus der Systembeschreibung gelesen und in den Templates ersetzt („Templates werden instanziiert"). Somit verfügt das Verifizierungstool über die Code-Teile in der Form, wie sie im tatsächlichen generierten RTE-Code vorliegen müssen. Das Vorhandensein dieser Teile im generierten Code wird geprüft. Liegen sie in genau dieser Form vor, gilt die generierte RTE als verifiziert.

Gibt es beispielsweise einen Steuergeräte-interne Kommunikationspfad, so gilt: Wenn es einen Port gibt, dann muss er sowohl sender- als auch empfängerseitig definiert sein, es muss Puffervariablen geben, um die Informationen zu übertragen, und schließlich muss es Makros geben, mit denen beim Senden und Empfangen diese Puffer beschrieben bzw. gelesen werden. All diese Bedingungen werden in C-Sprachpatterns übersetzt und diese Patterns dann im generierten Code aufgespürt.

Ein Beispiel einer Code-Vorlage, aus welcher ein Code-Muster 5 (in Figur 3 nicht gezeigt) erstellt wird, ist in Figur 3 dargestellt. Entsprechend der System-Beschreibung bzw. ECU-Konfiguration sind die Bedingungen 10 (Cl, C2, C3, C4, C5) in der Code-Vorlage zu erfüllen, welchen die gezeigte Code-Vorlage gültig machen. Entsprechend der System-Beschreibung werden die Variablen <re> (runnable entity name), <oa> (OS application), <t> (data type), <c> (component type name) und <name> (inter-runnable variable name) mit entsprechenden Werten ersetzt.

Wie schon erläutert überprüft die Verifizierungseinrichtung 4, ob alle solchen Software-Code- Muster 5 in dem Quelltext 1 der Software vorhanden sind. Die Verifizierungseinrichtung 4 erstellt einen Ausgabereport 6 (siehe Figur 1, 2), wobei der Ausgabereport 6 den markierten Quelltext enthält, in welchem die erzeugten Software-Code-Muster 5 markiert sind. Es kann in diesem Zusammenhang ein sogenannter„Colored Source Code" erzeugt werden, d.h. ein Listing des generierten Codes, in dem alle gefundenen Code-Muster (Patterns) markiert, beispielsweise farblich markiert sind, etwa mit einer grünen Einfärbung. Dieser markierte Code kann dann„manuell" von einem Benutzer einfach dahingehend überprüft werden, ob alle Code-Teile entsprechend (farblich) markiert sind. Alle Code-Teile, welche der Verifizierungseinrichtung bekannten Code-Mustern entsprechen, sind entsprechend markiert, d.h. in diesem Fall eingefärbt.

Bleiben Codeteile übrig, die nicht markiert sind, dann hat entweder der Software-Generator einen Fehler gemacht, oder der Benutzer hat ein nicht unterstütztes Software-Feature, insbesondere ein nicht unterstütztes Autosar RTE-Feature verwendet. Insbesondere in sicherheitsrelevanten Softwarekomponenten sollte der Autosar RTE-Anwender nur einen eingeschränkten Funktionsumfang verwenden (das Autosar RTE-Verify Safety Manual beschreibt, welche Funktionen unterstützt sind). Werden darüber hinaus weitere Funktionen verwendet, dann bleiben diese im Colored-Source-Code ungefärbt und müssen manuell - auf die klassische Art und Weise durch Test und Review - geprüft werden.

Weiters ist es von Vorteil, wenn die Verifizierungseinrichtung 4 überprüft, ob alle Software- Code-Muster 5 in dem Quelltext vorhanden sind, und wobei die Verifizierungseinrichtung 4 einen Fehlerreport 6 erzeugt, welcher alle Software-Code-Muster auflistet, welche von der Verifizierungseinrichtung 4 im Quelltext nicht gefunden wurden.

Alternativ erzeugt die Verifizierungseinrichtung 4 einen Report 6, in welchem jene Code-Muster aufgelistet sind, welche von der Verifizierungseinrichtung 4 erwartet wurden und welche gefunden wurden.

Die Verifizierung ist erfolgreich, wenn der markierte Quellcode keine nicht-markierten Bereiche enthält, und wenn der Fehlerbericht leer ist bzw. wenn die erwarteten und aufgefundenen Code-Muster übereinstimmen.

Insbesondere ist es schließlich auch noch von Vorteil, wenn die Verifizierungseinrichtung 4 wie in Figur 4 gezeigt einen Konfigurations-Feedback-Report 6a ausgibt, welcher alle Informationen und/ oder Bedingungen enthält, welche von der Verifizierungseinrichtung 4 aus der System-Beschreibung 3 ermittelt wurden, welche für die Generierung der Software relevant sind. Die System-Beschreibung 3, welche zur Generierung der Software 1 verwendet wird, ergibt sich aus dem sogenannten System-Design 100. Mittels eines geeigneten Design-Tools 110, z.B. dem Tool„DaVinci Developer", wird die System-Beschreibung 3 aus dem System-Design 100 erzeugt.

In dem Konfigurations-Feedback-Report 6a wird ein Subset des System-Designs 100 dargestellt, welches als Input für die Generierung der Software 1 benutzt wird. Der Benutzer kann an Hand dieses Konfigurations-Feedback-Reports 6a daher einfach überprüfen, ob die verwendete System-Beschreibung dieselbe (zumindest in Bezug auf die für die Generierung relevanten Informationen) ist wie jene, die sich aus dem Konfigurations-Feedback-Report 6a ergibt.

Bei einer End-to-End-Überprüfung durch den Benutzer können somit Fehler in der Generie- rungskette der Software 1 ausgeschlossen werden, nämlich insbesondere, ob

-) der Generator und die Verifizierungserinrichtung mit falschem Input gearbeitet haben;

-) der Input leer war, was zu einem trivialen "Empty"-Fehler führen würde.

In einem ISO 26262-basierten Projekt müssen auch die Entwicklungstools qualifiziert werden. Das Konfigurations-Feedback 6a zeigt, ob die richtige Systembeschreibung verwendet wurde. Dadurch, dass das RTE-Verifizierungstool 4 (RTE-Verify) nochmals die ECU-Konfiguration 3 anzeigt, die für die Verifikation verwendet wurde, wird die ganze Kette der RTE-Konfigura- tionstools abgesichert (Figur 4). Wenn ein Integrator das Konfigurations-Feedback prüft, dann bekommt er auch eine Bestätigung für das RTE-Design-Tool und verschiedene weitere Verarbeitungsschritte im Vorfeld der Verifikation.

Der Integrator bekommt durch das RTE-Verifizierungstool 4 eine Bestätigung, dass der RTE- Generierungsprozess auf den korrekten Konfigurationsdaten basiert, und dass er fehlerfrei durchgelaufen ist. Auch die Einhaltung des Safety Manuals, in dem die zulässige RTE-Funk- tionalität für sicherheitsrelevante Funktionen eingeschränkt wurde, wird damit rückbestätigt.

Aus Sicht eines Safety-Auditors besteht der Wert des erfindungsgemäßen RTE-Verifizie- rungstools 4 darin, die von der RTE verwendeten Codeteile herausgelöst, auf genau definierte Vorbedingungen zurückgeführt und damit einem Review nach ISO 26262 Regeln zugänglich gemacht werden können. Anstatt einen komplexen Code-Generator prüfen zu müssen, der auf einer Vielzahl von Libraries aufbaut und mit weiteren komplexen Tools verbunden ist, müssen nur kurze Code-Fragmente (Code-Muster, Patterns) in Hinblick auf die gesteckten Sicherheitsziele geprüft werden. Für einen realistischen Funktionsumfang sind dabei typischerweise einige hundert Patterns notwendig. Dies ist mit einem vertretbaren Aufwand und glaubhaft darstellbar, dass alle diese Patterns sorgfältig nach Checklisten geprüft werden.

Nur sorgfältig geprüfte Patterns werden in den Prüfumfang von RTE-Verify 4 übernommen. Der Prüfbericht von RTE-Verify liefert somit die Bestätigung, dass in einem konkreten Projekt nur vorab geprüfte Codeteile verwendet wurden, die RTE besteht also aus - nach den Regeln der ISO 26262 - vertrauenswürdigem Code.

Das vorgestellte erfindungsgemäße Verfahren ist äußerst flexibel. Wenn sich z.B. AUTOSAR weiterentwickelt, und bestimmte Funktionen erweitert oder geändert werden, dann müssen nur die betroffenen Patterns adaptiert und neu geprüft werden.

Das vorgestellte erfindungsgemäße Verfahren ist völlig transparent für den Anwender, das Prüfen der Verifikation selbst ist einfach. Das erfindungsgemäße Verfahren reduziert die Größe des Codes, der manuell geprüft werden muss, drastisch.

Andere Beispiele, wo das erfindungsgemäße Verfahren angewendet werden können, betreffend generell die Verifizierung von generiertem Code, wie z.B. Konfigurationstabellen sowie generierten Code für Prüfsummenberechnungen.