WO2015035438A1 - Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens - Google Patents

Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens Download PDF

Info

Publication number
WO2015035438A1
WO2015035438A1 PCT/AT2014/050197 AT2014050197W WO2015035438A1 WO 2015035438 A1 WO2015035438 A1 WO 2015035438A1 AT 2014050197 W AT2014050197 W AT 2014050197W WO 2015035438 A1 WO2015035438 A1 WO 2015035438A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
code
generated
verification device
system description
Prior art date
Application number
PCT/AT2014/050197
Other languages
English (en)
French (fr)
Inventor
Carsten Weich
Original Assignee
Fts Computertechnik 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 Fts Computertechnik Gmbh filed Critical Fts Computertechnik Gmbh
Priority to EP14781803.3A priority Critical patent/EP3044667A1/de
Priority to US15/021,275 priority patent/US20160224456A1/en
Publication of WO2015035438A1 publication Critical patent/WO2015035438A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3616—Software analysis for verifying properties of programs using software metrics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven

Definitions

  • the invention relates to a method for verifying generated software, in particular a computer program, which software is generated by means of a software generator, and / or generated code, which is generated by means of a code generator, wherein the software or the code of the Software generator or the code generator based on a system description is created.
  • ISO 26262 is an ISO standard for automotive safety-related electrical / electronic systems and has rapidly become established as an important guideline for the development of automotive ECUs since its introduction in 2011. ISO 26262 specifies the rules by which security-relevant hardware and software must be developed.
  • the RTE is used on a safety-related ECU ("Engine Control Unit") with an ASIL ("Automotive Safety Integrity Level”) rating.
  • the security objective (IS026262 Safety Goal) "secure data transfer" is understood to mean the following guarantees: RTE messages are written by a send component and can be read by predefined recipients, and the following applies:
  • RTE messages are transmitted consistently (i.e., all associated individual signals together).
  • predefined runnables can be activated as soon as an RTE message is written.
  • RTE messages are collections of single signals that belong together.
  • the RTE is usually a generated software whose accuracy is very difficult to prove. In principle, there are several possibilities for proof of correctness:
  • a verification device for verifying the software or the code according to the invention, wherein a) the system description is read into the verification device, b) the verification device using the system description or several software code patterns or code patterns are created, c) the source code of the generated software or the generated code is read into the verification device, and d) the verification device the source code or the code for presence of all software code Pattern or code pattern checked.
  • a static analysis is thus carried out, ie the software or computer program to be verified does not run during the verification.
  • the verifier based on the system description describing the software, determines what conditions and possibly items must be included in the generated code, and that "knowledge” is examined by the verifier directly in the generated code This is done by generating syntactic software code patterns that should or should be present in the software code, and then examining the code for the presence of all these software code patterns.
  • Items are elements / components, such as ports, tasks, components, etc., which are defined in the system description as parts of the system. If all software code patterns are available without errors, the generated software is also error-free.
  • the system description is given in the form of an abstract system model.
  • the software is an RTE, in particular an AUTOSAR RTE for a control unit of a motor vehicle
  • the system description may be a (AUTOSAR) ECU configuration, which ECU configuration corresponds to an AUTOSAR system description contains an AUTOSAR ECU Description.
  • system description comprises at least one set of properties and / or at least one set of items which describe the software to be generated.
  • the verification device for the creation of the at least one code pattern in step b) the verification device generates all conditions on the basis of the system description, which conditions describe the context for which the generated software was generated.
  • the context applies to the target system in which the generated software runs, not to the generation.
  • such conditions may e.g. among others: "memory protection is used”, “multiple instantiation is possible”, “all code is available as source code”.
  • the verification device selects, on the basis of the generated conditions, one or more code templates which are permissible in the presence of the generated conditions for a software generation, from a set of predefined code templates.
  • the set of predefined code templates are stored in a database associated with the verification device.
  • the selected code templates are instantiated by the verification device, ie that variables present in the selected code templates are replaced by values or information which the verification device determines from the system description become.
  • the code patterns thus created are now searched by the verification device in the source code of the generated software, and if all (correct) code patterns are found positively, the verification is positive, ie the generated software is error-free.
  • the verification device comprises at least one verification software or consists of a verification software.
  • the verification device is its own software, also referred to below as the verification tool.
  • the invention can be used if the generated software is a runtime environment.
  • the generated software is a software for execution on a device, for example on a control unit.
  • system description contains information regarding the device for which the generated software is intended.
  • a controller includes various ports.
  • the information regarding the (control) device included in the system description and to be considered in the generation of the software then includes e.g. the names, number and definition of the ports. These are taken into account when generating the software.
  • Services may be functions that are retrieved by a user of the RTE and are activated by the software (RTE), Preferably, information regarding these services is also included in the system description.
  • this information also enters into the generation of the software code patterns, and from the conditions and this information (name, number, definition of the ports) the software code patterns are created by the verification means.
  • the system description at least contains:
  • the system description is an ECU configuration, in particular an AUTOSAR ECU configuration, which ECU configuration contains a system description, in particular an AUTOSAR system description together with an ECU description, in particular an AUTOSAR ECU description ,
  • the verification device checks whether all software code patterns are present in the source text, and wherein the verification device generates an output report, wherein the output report contains the marked source text in which the generated software code patterns are marked.
  • a so-called colored source code can be generated, ie a listing of the generated code in which all found code patterns (patterns) are marked, for example color-coded, for example with a green coloration "Manually" by a user are simply checked to see whether all code parts are marked accordingly (in color). All code parts which correspond to known code patterns of the verification device are marked accordingly, i. dyed in this case.
  • the Autosar RTE user should only use a limited range of functions (the Autosar RTE-Verify Safety Manual describes which functions are supported). If further functions are used, they remain uncoloured in the colored source code and have to be checked manually - in the classic way through test and review.
  • the verification device checks whether all software code patterns are present in the source text, and wherein the verification device generates an error report listing all software code patterns which were not found by the verification device in the source text ,
  • the verifier generates a report listing those code patterns that were expected by the verifier and that were found. The verification succeeds if the tagged source code does not contain any unlabeled areas and if the error report is empty or if the expected and found code patterns match.
  • the verification device outputs a configuration feedback report which contains all information and / or conditions which were determined by the verification device from the system description, which are relevant for the generation of the software.
  • system description used to generate the software results from the so-called system design, from which by means of a corresponding design tool, e.g. the tool "DaVinci Developer", the system description is generated.
  • the configuration feedback report shows a subset of the system design used as input for generating the software. The user can therefore easily check on the basis of this configuration feedback report whether the system description used is the same (at least with regard to the information relevant to the generation) as that resulting from the configuration feedback report.
  • the invention relates to software, in particular computer program, e.g. Control software for a motor vehicle, the software being verified according to a method mentioned above.
  • the software is based on an AUTOSAR standard. It is advantageous if the software is realized in the form of a runtime environment.
  • the system description is an ECU configuration, in particular an AUTOSAR ECU configuration, which ECU configuration contains a system description, in particular an AUTOSAR system description together with an ECU description, in particular an AUTOSAR ECU description.
  • the invention also relates to a control device for a motor vehicle, on which runs at least one software described above or a computer program described above.
  • FIG. 3 shows a schematic representation of a code template which is used by a verification device for generating a software code pattern
  • FIG. 1 shows schematically the process of generating a software 1.
  • This software 1 can in principle be any software, in the example presented it is an AUTOSAR RTE, also referred to below as RTE.
  • RTE AUTOSAR RTE
  • the presented verification method is of particular advantage.
  • the software (RTE) 1 is generated with a software generator 2, wherein the software 1 is created by the software generator 2 based on a system description 3.
  • the system description 3 can be given in the form of an abstract system model, and / or the system description 3 comprises one or more sets of properties and / or one or more sets of commands which describe the software to be generated.
  • system description 3 is in the form of an (AUTOSAR) ECU configuration which contains an AUTOSAR system description 3b together with an AUTOSAR ECU Description 3a.
  • the system description includes 3 tasks, ports, and services in the controller for which the RTE is intended. For example, if two software components exchange messages via the RTE, then corresponding "ports" must be declared in the system description.This system description is read in by the RTE generator 2. For the message exchange to work safely, the RTE generator 2 must have code 1 create the buffer required for the message exchange correctly and the access functions to these buffers are defined correctly, the buffers must be large enough, the access functions must respect the buffer size and must not be interruptible, etc.
  • FIG. 1 further shows schematically the verification process according to the invention.
  • a verification device 4 in the form of verification software also referred to below as “verification tool”
  • the system description 3 is read into the verification device 4 on the basis of the read-in
  • the verification device 4 creates one or more software code patterns 5 (see FIG. 3)
  • the source code of the generated software 1 is read into the verification device 4, and the verification device 4 checks the source code 1 for the presence of all of it generated software code pattern 5.
  • FIG. 2 again shows the verification process in a more detailed representation.
  • all conditions 10 are initially established by the verification device 4 on the basis of the system description 3 in order to produce the at least one code pattern 5 which conditions 10 describe the context for which the generated software was generated.
  • the context applies to the target system in which the generated software runs, not to the generation.
  • the verification device 4 on the basis of the generated conditions 10 one or more code templates, which are allowed in the presence of the generated conditions 10 for software production, selected from a set of predetermined code templates.
  • the set of predefined code templates are stored in a database associated with the verification device 4.
  • the verification device 4 thus selects from the available code templates the relevant code templates, which are relevant for the generation of the software in the context described by the software description.
  • the selected code templates are instantiated by the verification device 4, ie that variables present in the selected code templates are replaced by values determined by the verification device 4 from the system description 3 become.
  • the code templates 5 are generated from the code templates. It can also happen that one and the same code template is used several times, with different assignment of the variables.
  • the verification engine creates a list of code parts (code patterns) that must exist in the code.
  • the database contains the templates (code templates) with variables for port names, component names, names of the data types to be exchanged, etc. These names are also read from the system description and replaced in the templates ("Templates are instantiated") the code parts in the form that they need to be in the actual generated RTE code, the presence of these parts in the generated code is checked, and if they are in exactly that form, the generated RTE is considered verified.
  • FIG. 3 An example of a code template from which a code pattern 5 (not shown in FIG. 3) is created is shown in FIG.
  • the conditions 10 C1, C2, C3, C4, C5 in the code template are to be fulfilled, which make the code template shown valid.
  • the variables ⁇ re> (runnable entity name), ⁇ oa> (OS application), ⁇ t> (data type), ⁇ c> (component type name) and ⁇ name> (inter-runnable variable name) with corresponding values.
  • the verification device 4 checks whether all such software code patterns 5 are present in the source code 1 of the software.
  • the verification device 4 creates an output report 6 (see FIGS. 1, 2), the output report 6 containing the marked source text in which the generated software code patterns 5 are marked.
  • a so-called colored source code can be generated, ie a listing of the generated code in which all found code patterns (patterns) are marked, for example color-coded, for example with a green coloration "Manually" by a user are simply checked to see whether all code parts are marked accordingly (in color). All code parts which correspond to the verification device known code patterns are marked accordingly, ie dyed in this case.
  • the Autosar RTE user should only use a limited range of functions (the Autosar RTE-Verify Safety Manual describes which functions are supported). If further functions are used, they remain uncoloured in the colored source code and have to be checked manually - in the classic way through test and review.
  • the verification device 4 checks whether all software code patterns 5 are present in the source text, and wherein the verification device 4 generates an error report 6 listing all the software code patterns that are to be used by the verification device 4 were not found in the source code.
  • the verifier 4 generates a report 6 listing those code patterns which were expected by the verifier 4 and which were found.
  • the verification succeeds if the tagged source code does not contain any unlabeled areas and if the error report is empty or if the expected and found code patterns match.
  • the verification device 4 outputs a configuration feedback report 6a which contains all information and / or conditions which were determined by the verification device 4 from the system description 3, which are relevant for the generation of the software.
  • the system description 3, which is used to generate the software 1 results from the so-called system design 100.
  • a suitable design tool 110 for example the tool "DaVinci Developer”
  • the system description 3 is removed from the system Design 100 generated.
  • the configuration feedback report 6a a subset of the system design 100 is shown, which is used as input for the generation of the software 1. The user can therefore easily check on the basis of this configuration feedback report 6a whether the system description used is the same (at least with regard to the information relevant to the generation) as that resulting from the configuration feedback report 6a ,
  • the configuration feedback 6a shows if the correct system description has been used.
  • an integrator checks the configuration feedback, it also receives confirmation for the RTE design tool and various other processing steps prior to verification.
  • the integrator gets an acknowledgment by the RTE verification tool 4 that the RTE generation process is based on the correct configuration data and that it has passed through without error. Compliance with the Safety Manual, which restricts the permissible RTE functionality for safety-relevant functions, is also confirmed.
  • the value of the RTE verification tool 4 is that of removing the code parts used by the RTE, attributing them to precisely defined preconditions and thus making them accessible for review in accordance with ISO 26262 rules can be made.
  • code patterns, patterns short code fragments
  • RTE-Verify 4 testing Only carefully checked patterns will be included in the scope of RTE-Verify 4 testing.
  • the test report from RTE-Verify thus provides confirmation that only pre-tested parts of the code were used in a specific project, so the RTE consists of - according to the rules of ISO 26262 - trusted code.
  • the proposed method according to the invention is extremely flexible. If, for example, AUTOSAR evolved, and certain functions are extended or changed, then only the affected patterns need to be adapted and re-examined.
  • the proposed method according to the invention is completely transparent to the user, verification of the verification itself is simple.
  • the method according to the invention drastically reduces the size of the code which has to be checked manually.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Verifizierung von generierter Software (1), insbesondere eines Computerprogrammes, welche Software (1) mittels eines Software-Generators (2) erzeugt wird, wobei die Software (1) von dem Software-Generator (2) basierend auf einer System-Beschreibung (3) erstellt wird. Weiters betrifft die Erfindung eine Verifizierungseinrichtung zum Durchführen eines solchen Verfahrens. Zur Verifizierung der Software (1) eine Verifizierungseinrichtung (4) vorgesehen ist, wobei a) die System-Beschreibung (3) in die Verifizierungseinrichtung (4) eingelesen wird, b) die Verifizierungseinrichtung (4) an Hand der System-Beschreibung (3) ein oder mehrere Software-Code-Muster (5) erstellt, c) der Quelltext der generierten Software (1) in die Verifizierungseinrichtung (4) eingelesen wird, und d) die Verifizierungseinrichtung (4) den Quelltext (1) auf Vorhandensein aller Software-Code- Musters (5) überprüft.

Description

VERFAHREN ZUR VERIFIZIERUNG GENERIERTER SOFTWARE SOWIE VERIFIZIERUNGSEINRICHTUNG ZUM DURCHFÜHREN EINES SOLCHEN VERFAHRENS
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.

Claims

PATENTANSPRÜCHE
1. Verfahren zur Verifizierung von generierter Software (1), insbesondere eines Computerprogramms, welche Software (1) mittels eines Software-Generators (2) erzeugt wird, und/o- der von generiertem Code, welcher mittels eines Code-Generators erzeugt wird, wobei die Software (1) bzw. der Code von dem Software-Generator (2) bzw. dem Code-Generator basierend auf einer System- Beschreibung (3) erstellt wird, dadurch gekennzeichnet, dass zur Verifizierung der Software (1) bzw. de Codes eine Verifizierungseinrichtung (4) vorgesehen ist, wobei a) die System-Beschreibung (3) in die Verifizierungseinrichtung (4) eingelesen wird, b) die Verifizierungseinrichtung (4) an Hand der System-Beschreibung (3) ein oder mehrere Software-Code-Muster (5) bzw. Code-Muster erstellt, c) der Quelltext der generierten Software (1) bzw. der generierte Code in die Verifizierungseinrichtung (4) eingelesen wird, und d) die Verifizierungseinrichtung (4) den Quelltext (1) bzw. den Code auf Vorhandensein aller Software-Code-Muster (5) bzw. Code-Muster überprüft.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die System-Beschreibung (3) in Form eines abstrakten Systemmodells gegeben ist.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die System-Beschreibung (3) zumindest einen Satz von Eigenschaften und/ oder zumindest einen Satz von Befehlen, welche die zu erzeugende Software beschreiben, umfasst.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass zur Erstellung des zumindest einen Code-Musters (5) in Schritt b) die 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.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, 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.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Menge an vorgegebenen Code-Vorlagen in einer der Verifizierungseinrichtung (4) zugeordneten Datenbank abgespeichert sind.
7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, 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 bzw. Informationen ersetzt werden, welche von der Verifizierungseinrichtung (4) aus der System-Beschreibung (3) ermittelt werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Verifizierungseinrichtung (4) zumindest eine Verifizierungssoftware umf asst bzw. aus einer Verifizierungssoftware besteht.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die generierte Software (1) eine Laufzeitumgebung ist.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die generierte Software (1) eine Software zur Ausführung auf einem Gerät, beispielsweise auf einem Steuergerät ist.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass das Steuergerät ein Steuergerät für ein Kraftfahrzeug ist.
12. Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass die System-Beschreibung (3) Informationen bezüglich des Gerätes, für das die generierte Software (1) vorgesehen ist, beinhaltet.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass bei einer Software (1) 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 (3) zumindest enthält: -) Namen, Anzahl und Definition von Ports, und/ oder -) Services im Steuergerät.
14. Verfahren nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, dass die System-Beschreibung (3) eine ECU Konfiguration, insbesondere eine AUTOSAR ECU Konfiguration ist, welche ECU Konfiguration eine System-Description, insbesondere eine AUTOSAR System- Description (3b) zusammen mit einer ECU Description, insbesondere einer AUTOSAR ECU Description (3a) enthält.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Verifizierungseinrichtung (4) überprüft, ob alle Software-Code- Muster (5) in dem Quelltext vorhanden sind, und wobei die Verifizierungseinrichtung (4) einen Ausgabereport (6) erstellt, wobei der Ausgabereport (6) den markierten Quelltext enthält, in welchem die erzeugten Software- Code-Muster (5) markiert sind.
16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass 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.
17. Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass die Verifizierungseinrichtung (4) 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.
18. Verifizierungseinrichtung, insbesondere Verifizierungssoftware zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 17.
19. Software, insbesondere Computerprogramm, z.B. Steuerungssoftware, für ein Kraftfahrzeug, wobei die Software mit einem Verfahren nach einem der Ansprüche 1 bis 17 verifiziert ist.
20. Software nach Anspruch 19, dadurch gekennzeichnet, dass sie auf einem AUTOSAR Standard basiert.
21. Software nach Anspruch 20, dadurch gekennzeichnet, dass sie in Form einer Laufzeit- umgebung realisiert ist.
22. Software nach Anspruch 21, dadurch gekennzeichnet, dass eine Systembeschreibung (3) der Laufzeitumgebung zumindest enthält:
-) Namen, Anzahl und Definition von Ports, und/ oder
-) Services im Steuergerät.
23. Software nach Anspruch 22, dadurch gekennzeichnet, dass die System-Beschreibung (3) eine ECU Konfiguration, insbesondere eine AUTOSAR ECU Konfiguration ist, welche ECU Konfiguration eine System-Description, insbesondere eine AUTOSAR System-Description (3b) zusammen mit einer ECU Description, insbesondere einer AUTOSAR ECU Description (3a) enthält.
24. Steuergerät für ein Kraftfahrzeug, auf welchem zumindest eine Software bzw. ein Computerprogramm nach einem der Ansprüche 19 bis 23 abläuft.
PCT/AT2014/050197 2013-09-13 2014-09-05 Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens WO2015035438A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP14781803.3A EP3044667A1 (de) 2013-09-13 2014-09-05 Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens
US15/021,275 US20160224456A1 (en) 2013-09-13 2014-09-05 Method for verifying generated software, and verifying device for carrying out such a method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA50580/2013 2013-09-13
ATA50580/2013A AT514731A2 (de) 2013-09-13 2013-09-13 Verfahren zur Verifizierung generierter Software sowie Verifizierungseinrichtung zum Durchführen eines solchen Verfahrens

Publications (1)

Publication Number Publication Date
WO2015035438A1 true WO2015035438A1 (de) 2015-03-19

Family

ID=51687759

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AT2014/050197 WO2015035438A1 (de) 2013-09-13 2014-09-05 Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens

Country Status (4)

Country Link
US (1) US20160224456A1 (de)
EP (1) EP3044667A1 (de)
AT (1) AT514731A2 (de)
WO (1) WO2015035438A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9588877B1 (en) 2015-09-25 2017-03-07 International Business Machines Corporation Unit-level formal verification for vehicular software systems

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3493051A1 (de) * 2017-11-30 2019-06-05 The MathWorks, Inc. System und verfahren zur beurteilung der einhaltung des implementierungscodes mit einer softwarearchitekturspezifikation
DE102018003142A1 (de) 2017-12-13 2019-06-13 The Mathworks, Inc. Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114841A1 (en) * 2003-11-21 2005-05-26 Moskowitz Milton E. Automatic computer code review tool
US8464204B1 (en) * 2008-10-06 2013-06-11 The Mathworks, Inc. Verification of computer-executable code generated from a model

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8448130B1 (en) * 2007-08-20 2013-05-21 The Mathworks, Inc. Auto-generated code validation
US8856726B2 (en) * 2009-09-14 2014-10-07 The Mathworks, Inc. Verification of computer-executable code generated from a slice of a model
JP5065344B2 (ja) * 2009-07-14 2012-10-31 インターナショナル・ビジネス・マシーンズ・コーポレーション シミュレーション方法、システム及びプログラム
US8606375B2 (en) * 2010-06-04 2013-12-10 The Mathworks, Inc. Interactive control of multiple input multiple output control structures
US9377998B2 (en) * 2011-11-08 2016-06-28 The Mathworks, Inc. Code generation for control design
US9251308B2 (en) * 2012-07-23 2016-02-02 International Business Machines Corporation Simulation method, system, and program

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114841A1 (en) * 2003-11-21 2005-05-26 Moskowitz Milton E. Automatic computer code review tool
US8464204B1 (en) * 2008-10-06 2013-06-11 The Mathworks, Inc. Verification of computer-executable code generated from a model

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9588877B1 (en) 2015-09-25 2017-03-07 International Business Machines Corporation Unit-level formal verification for vehicular software systems
US9870313B2 (en) 2015-09-25 2018-01-16 International Business Machines Corporation Unit-level formal verification for vehicular software systems
US9875175B2 (en) 2015-09-25 2018-01-23 International Business Machines Corporation Unit-level formal verification for vehicular software systems
US9898395B2 (en) 2015-09-25 2018-02-20 International Business Machines Corporation Unit-level formal verification for vehicular software systems

Also Published As

Publication number Publication date
EP3044667A1 (de) 2016-07-20
AT514731A2 (de) 2015-03-15
US20160224456A1 (en) 2016-08-04

Similar Documents

Publication Publication Date Title
DE102015207656B4 (de) Verfahren und System zum Testen von Steuersoftware eines gesteuerten Systems
DE60021066T2 (de) Prüfung eines Softwarepakets
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE102020205539A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
DE10144050A1 (de) Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
EP3306295B1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
WO2015035438A1 (de) Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens
EP3207386B1 (de) Überprüfen eines funktionsmoduls einer automatisierungsanlage
DE102009032333A1 (de) Verfahren zur Prüfung von Modellen
DE102020213809A1 (de) Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts
DE102020206327A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102010047954A1 (de) Formelle offline-Verifikation ausführbarer Modelle
DE102010044039A1 (de) Verfahren und Vorrichtung zur Qualitätsanalyse von Systemmodellen
DE102017212612A1 (de) Verfahren zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs
DE4426739C2 (de) Testverfahren sowie Einrichtung zum Erzeugen von Test-Fällen, Testeinrichtung und Programm-Modul dafür
DE102021004427B4 (de) Verfahren zur lmplementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
WO2012013203A1 (de) System und verfahren zur verbreitung und zum austausch von elementen zur planung und/oder zum betrieb automatisierungstechnischer betriebsmittel
DE102016123332A1 (de) Virtuelle Inbetriebnahme und Simulation eines Gebäudeautomatisierungssystems
DE102021200298A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020206323A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102019209541A1 (de) Verfahren und Vorrichtung zum Erfüllen einer Entwicklungsaufgabe
Friedberger Efficient software model checking with block-abstraction memoization
DE102021203278A1 (de) Verfahren zum Testen eines Steuergeräts
DE102021132302A1 (de) Compilervalidierung

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14781803

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15021275

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2014781803

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014781803

Country of ref document: EP