EP3044667A1 - Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé - Google Patents

Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé

Info

Publication number
EP3044667A1
EP3044667A1 EP14781803.3A EP14781803A EP3044667A1 EP 3044667 A1 EP3044667 A1 EP 3044667A1 EP 14781803 A EP14781803 A EP 14781803A EP 3044667 A1 EP3044667 A1 EP 3044667A1
Authority
EP
European Patent Office
Prior art keywords
software
code
generated
verification device
system description
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP14781803.3A
Other languages
German (de)
English (en)
Inventor
Carsten Weich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FTS Computertechnik GmbH
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
Publication of EP3044667A1 publication Critical patent/EP3044667A1/fr
Withdrawn legal-status Critical Current

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.

Abstract

L'invention concerne un procédé pour vérifier des logiciels générés (1), en particulier un programme informatique, le logiciel (1) étant obtenu au moyen d'un générateur de logiciels (2), le logiciel (1) étant créé par le générateur de logiciels (2) sur base d'une description de système (3). De plus, l'invention concerne un dispositif de vérification pour la réalisation d'un tel procédé. L'invention concerne un dispositif de vérification (4) pour la vérification du logiciel (1), a) la description du système (3) étant lue dans le dispositif de vérification (4), b) le dispositif de vérification (4) créant, à l'aide de la description du système (3), un ou plusieurs modèles de code logiciel (5), c) le texte source du logiciel généré (1) étant lu dans le dispositif de vérification (4) et d) le dispositif de vérification (4) testant le texte source (1) sur la présence de tous les modèles de code logiciel (5).
EP14781803.3A 2013-09-13 2014-09-05 Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé Withdrawn EP3044667A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA50580/2013A AT514731A2 (de) 2013-09-13 2013-09-13 Verfahren zur Verifizierung generierter Software sowie Verifizierungseinrichtung zum Durchführen eines solchen Verfahrens
PCT/AT2014/050197 WO2015035438A1 (fr) 2013-09-13 2014-09-05 Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé

Publications (1)

Publication Number Publication Date
EP3044667A1 true EP3044667A1 (fr) 2016-07-20

Family

ID=51687759

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14781803.3A Withdrawn EP3044667A1 (fr) 2013-09-13 2014-09-05 Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé

Country Status (4)

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

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9875175B2 (en) 2015-09-25 2018-01-23 International Business Machines Corporation Unit-level formal verification for vehicular software systems
EP3493051A1 (fr) 2017-11-30 2019-06-05 The MathWorks, Inc. Système et procédés permettant d'évaluer la conformité du code de mise en uvre avec une spécification d'architecture logicielle
DE102018003142A1 (de) 2017-12-13 2019-06-13 The Mathworks, Inc. Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem

Family Cites Families (8)

* 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
US8448130B1 (en) * 2007-08-20 2013-05-21 The Mathworks, Inc. Auto-generated code validation
US8713528B1 (en) * 2008-10-06 2014-04-29 The Mathworks, Inc. Verification of computer-executable code generated from a model
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2015035438A1 *

Also Published As

Publication number Publication date
AT514731A2 (de) 2015-03-15
US20160224456A1 (en) 2016-08-04
WO2015035438A1 (fr) 2015-03-19

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 (fr) Procédé de génération d'un modèle d'un système technique exécutable sur un appareil d'essai et appareil d'essai
DE10144050A1 (de) Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
EP3306295B1 (fr) Procédé et dispositif d'essai de commandes électroniques, en particulier d'essai de commandes automobiles
WO2015035438A1 (fr) Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé
EP3207386B1 (fr) Contrôle d'un module fonctionnel d'un système d'automatisation
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
WO2012013203A1 (fr) Système et procédé de diffusion et d'échange d'éléments pour la planification et/ou pour l'exploitation de moyens opérationnels en technique d'automatisme
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
DE102022112141A1 (de) Verfahren zur Erstellung eines vereinfachten virtuellen Steuergeräts
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
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160329

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

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

18D Application deemed to be withdrawn

Effective date: 20161101