EP1428126A2 - Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem - Google Patents

Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem

Info

Publication number
EP1428126A2
EP1428126A2 EP02760105A EP02760105A EP1428126A2 EP 1428126 A2 EP1428126 A2 EP 1428126A2 EP 02760105 A EP02760105 A EP 02760105A EP 02760105 A EP02760105 A EP 02760105A EP 1428126 A2 EP1428126 A2 EP 1428126A2
Authority
EP
European Patent Office
Prior art keywords
control unit
software
software functions
functions
experimental
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.)
Ceased
Application number
EP02760105A
Other languages
English (en)
French (fr)
Inventor
Hans-Joerg Wolff
Thomas Zurawka
Joerg Schaeuffele
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch 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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP1428126A2 publication Critical patent/EP1428126A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0428—Safety, monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • 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/3684—Test management for test design, e.g. generating new test cases
    • 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/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23188—Software independent and dependent of hardware
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24006—Code coverage memory:contains data about addressed addresses during program run
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24034—Model checker, to verify and debug control software
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24038—Several test signals stored in memory and used as input signals
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24061—Simulator, generates input signals, shows output signals of logic

Definitions

  • the invention relates to a method and a system for verifying software functions for a control unit according to the independent claims. Furthermore, the invention relates to a computer program consisting of program code elements for executing a method for software verification according to claim 10.
  • the microcomputer In order to be able to determine the code coverage of a control or regulation program of the microcomputer even while the motor vehicle is traveling, it is proposed that the microcomputer contain a code coverage memory in addition to and parallel to the program memory and data memory, which is connected to the microprocessor via the address bus and the data bus , Information about which addresses of the program memory or the data memory are addressed by the microcomputer during the execution of a control program from the program memory during a drive of the motor vehicle as part of a write or read access can then be stored in the code cover memory.
  • the so-called code coverage method for determining the code coverage is carried out by a so-called system execution analyzer.
  • control unit software will also control and monitor safety-relevant driving functions in the near future, such as in X-By-Wire systems, the quality requirements for software development and verification in embedded control systems will continue to increase.
  • the aim of the invention is to use a precisely defined, continuous function development process to specify a method for verifying the software functions or the software code, with which the quality of the software can still be ensured in order to optimize the situation resulting from the prior art.
  • a system for verification and a corresponding computer program are the subject of the invention.
  • the invention relates to a method and a system and a corresponding computer program for verifying software functions for a control unit using a simulation model for mapping the software functions and the control unit, advantageously from the identical simulation model on the one hand for a first experimental control unit and on the other hand for one second series control unit, the software code for the software functions is generated automatically, with identical input variables for the software functions being used on both control units and the resulting output variables of both control units being recorded synchronously, that is, simultaneously, the software functions being verified by comparing the output variables of both control units.
  • a uniform simulation model for the experimental control unit, that is to say the experimental target, and for the series control unit, that is to say the ECU target, is thus taken as a basis.
  • a so-called target-identical prototyping takes place, as mentioned, in the simulation model, e.g. B. ASCET-SD, modeled functions on the experimental target and the stimulation of the functions by the control unit input variables.
  • the implementation for the software functions from the identical model for the series control unit, that is to say the ECU target also takes place automatically from the simulation model with the aid of a target code generation. The verification is then carried out by a parallel function test on the experimental target and ECU target.
  • the acquisition and comparison of the output variables and / or intermediate variables leading to the output variables from the series control unit, that is to say the ECU target, are advantageously carried out with those of the experimental target or the Experimental control unit automatically performed by the experimental control unit.
  • the software code for the software functions for each experimental control unit and series control unit is advantageously generated with different generating means, that is to say in particular translated with different compilers either for the same processor or for different processors.
  • the code coverage that is to say the continuous paths in the software code and / or in the software functions for determining the
  • the software functions serve to control operating sequences in a vehicle and are then verified accordingly with the method, the system and the corresponding computer program.
  • the entire verification of the software functions is carried out with a simulation means simulating a vehicle and / or vehicle components and / or vehicle functions, for example LabCar, without the use of a real vehicle.
  • the software code of the software functions is advantageously divided into hardware-dependent software code and hardware-independent software code.
  • the hardware-dependent part includes, for example, that Operating system and the so-called hardware abstraction layer for defining general standardized interfaces for connecting to this hardware-dependent software code part for various, selectable, hardware-independent software code parts, the hardware-independent software code part containing the software functions for controlling the operating processes in a vehicle.
  • this also creates a multi-stage function development process with which the software quality can be increased in every phase and the development risk can be minimized, which entails great potential for cost savings.
  • FIG. 1 shows a series control unit, that is to say an ECU target and an experimental target, with a representation of the respective software architecture.
  • FIG. 2 shows the flow of the method for software verification in a flow chart.
  • FIG. 3 shows the data and control flow, based on the method for software verification according to the invention.
  • FIG. 1 shows a series control unit 100, the so-called ECU target, and the experimental control unit 101, the so-called experimental target. Both control units 100 and 101 are connected via the communication link 103. Depending on the application, this communication connection can be unidirectional or bidirectional, serial or parallel, etc. Furthermore, a visualization and / or evaluation means 102 is connected to the experimental target 101, which is also referred to below as a GUI or Graffical User Interface. The connection itself, in parallel or serial as well as unidirectional or bidirectional, is designated 104 here. As already mentioned, this visualization means 102 can also include evaluation options, that is to say a computing unit and / or a storage unit, wherein this GUI can also be integrated in the experimental target.
  • evaluation options that is to say a computing unit and / or a storage unit, wherein this GUI can also be integrated in the experimental target.
  • Blocks 105 and 106 symbolically represent the ECU software architecture and the software architecture of the experimental target.
  • the architecture of the software or the software functions of the series control unit, that is to say the ECU software is of central importance, for example for the formation of components and variants, the reuse and portability and the support of interfaces of the series control unit for development tools.
  • the development process and the software architecture must therefore be considered together. There is one
  • Layer architecture is advantageous, in which the actual control unit functionality, that is to say the hardware-independent software functions such as application software, is separated from the hardware-dependent software layers of the platform software.
  • the platform software can be reused across projects, and secondly, the interfaces for the Unified access to the control units.
  • This makes it possible to use standardized methods or tools tailored to these standard interfaces during development, verification, but also in production and service. B. for rapid prototyping, debugging, measuring and calibration.
  • the functions of the application software or the software functions, in particular for controlling operating processes in a vehicle can be specified independently of the hardware and can thus be ported to different control unit platforms.
  • Block 105 contains, for example, a block of data 107 which comprises the entirety of the data, that is to say input and output variables, measurement data, internal intermediate variables, etc. These data of the functions are essentially the same in the context of the software functions in block 107 and block 109. In software block 105, however, further software code or further software functions are no longer directly accessible, so that block 108 shows black box behavior and essentially only measurement and calibration, based on data block 107, is possible on the ECU target.
  • Experimental target 101 is used, in which access to the behavior of the functions or the software functions in block 110 is also possible in addition to data block 109 within the framework of the hardware-independent software.
  • black box behavior is therefore only shown in block 111, that is to say with regard to the platform software.
  • the operating system for example OSEK-OS or ERCOS, as well as automotive services and the mentioned abstraction layer, hardware abstraction layer HAL, are embedded in it. Through this abstraction layer, the independence of the software layers above, in particular the application software that describes or contains the behavior and data of the software functions.
  • the software structure is essentially between the series control unit, that is to say the ECU target and the experimental target, that is to say the
  • Experimental control unit the same. It is also important, in order to describe it later, to represent the time synchronism as part of the verification, the operating system or the operating systems on which they are based having the same time behavior, advantageously using the same or comparable operating systems, in particular standard operating systems such as OSEK and other standards such as ASAM are taken into account and used.
  • Development tools such as ASCET-SD, support the graphic, physical and component-based modeling of functions of hardware-independent software, in particular the application software, simulation and rapid prototyping with an experimental target, i.e. target-identical prototyping and automatic target code generation for implementation on the Serial control unit, the target system.
  • the simulation model or the corresponding development tools generate a complete description file in a standard format, for example ASAM-MCD2, for all measurement and calibration variables of a control unit, which enables standardized measurement and calibration tool interfaces.
  • the process sequence is shown in FIG. 2 based on the creation of the simulation model in block 200.
  • the simulation model in particular ASCET-SD, is in particular for the hardware-independent software functions “single source”, that is, the basis for the series control unit, that is, the ECU target and the experimental control unit.
  • the target code is generated in block 201 with respect to the ECU target for the software functions from the simulation model for the series control unit formed in block 200.
  • Target-identical prototyping of the functions modeled in the simulation model is also carried out automatically on the experimental target.
  • Target-identical prototyping means that the entire arithmetic and timing behavior is specified and simulated (on the experimental control unit) and virtually matches the system behavior of the series control unit.
  • the software code is then generated in block 203, in particular by compiling it in C for the ECU target.
  • the software code can be in any programming language, the example C as well as C ++ or Java, etc. are not to be understood as restrictive with regard to the subject matter of the invention.
  • the conversion into the software code mentioned for the experimental control unit takes place.
  • the actual software verification now takes place in block 208 and block 209.
  • a temporally parallel function test is carried out in block 208 on series control unit 205 and experimental control unit 206, wherein, as indicated, a data exchange can take place via connection 207.
  • Experimental control unit identical. For example, e.g. Floating point arithmetic of the experimental target (e.g. also fixed point arithmetic possible) and, for example, fixed point arithmetic on the series control unit, a comparison between floating point arithmetic and fixed point arithmetic is possible. It is thus possible at an early stage to investigate the influence of quantization and overflow effects on the series control device, that is to say the ECU target, in order to make it possible to display deficiencies in the implementation and, in particular, to correct them automatically, if necessary.
  • the measurement and comparison of the output variables with regard to the software functions then takes place, preferably on the experimental control unit.
  • the measurement on the series control unit and experimental control unit or the acquisition of the values and their comparison takes place simultaneously and synchronized in time.
  • software verification with target-identical prototyping and target code generation is possible.
  • Identical code generator options for target identical prototyping and target code generation can be available, which means that fixed point arithmetic is then used on both targets and control units.
  • the same operating systems, in particular an OSEK operating system, such as ERCOS and identical ones advantageously come on the experimental target Service routines, as in the series control unit, are used.
  • a code coverage analysis is possible with block 210 either via connection 212 on the experimental target or optionally via connection 213 on the series control unit.
  • the software code in particular C code, which is generated automatically by the simulation model, is instrumented.
  • commercial coverage tools for code instrumentation or for coverage analysis can be integrated into the simulation model in order to achieve the goal of achieving a high coverage (path and / or branch coverage).
  • 100% branch coverage on the ECU target can be inferred from 100% branch coverage.
  • the code coverage analysis could also be carried out on the ECU target, as shown via connection 213, in which case it would be advantageous for the code coverage analysis to be carried out directly on the software code of the series control unit, and thus also hardware-dependent software part, the platform software, is covered.
  • the measurement and simulation environment is advantageously integrated into the experimental control unit and could also be used in the laboratory, on the test bench and in the vehicle.
  • the measured variable comparison that is to say the comparison of the output variables, is advantageously calculated on the experimental control unit. Due to the diversity of the platforms used, including compilers and code generator sets, the examination and review of code generator optimizations especially for the series control unit, the identification of code generator, compiler and processor problems or errors as well as the detection of timing problems of the series control unit are possible. This will now be explained in more detail using the data and control flow in FIG. 3.
  • FIG. 3 shows the experimental control unit with block 101 and the series control unit again with block 100.
  • the serial control unit 100 receives specific input variables via connection 303 and outputs output variables or measured variables via connection 302 in accordance with the software functions.
  • Block 300, the control route can, on the one hand, as already mentioned, be the vehicle; on the other hand a simulation environment such as B. the representation of various vehicle functions or the entire vehicle in the laboratory as a LabCar, which means that the entire test sequence together with such a LabCar can be relocated to the laboratory and automated.
  • the input variables of the real series control unit can be, for example, via the bidirectional connection 103 or alternatively with the connection 304
  • the line 301 or the symbolic signal flow represents, for example, a trigger from the ECU target to the experimental target.
  • the output variables of the series control unit can be transmitted via path 306 to a visualization and, under certain circumstances, evaluation system 102 GUI, which in particular is bidirectionally connected to the experimental control unit via connection 104 communicates.
  • the GUI can also be integrated into the experimental control unit.
  • the output variables of the experimental target or also the comparison results can optionally be transmitted via a path 305 to further evaluation means or display means. Especially in the
  • Program code elements are processed in order to achieve the method steps according to the invention.
  • the program code elements that run or are executed when executed on a computer, computer or the verification system then result in the described method steps of the system according to the invention.
  • the program code elements are stored on any data carrier (system-internal or external), ie RAM, ROM, EPROM, CD-ROM, floppy disk, etc., before or for execution.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Automation & Control Theory (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Verfahren und System zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulationsmodells zur Abbildung der Softwarefunktionen und der Steuereinheit, wobei aus dem identischen Simulationsmodell zum einen für eine erste Experimentalsteuereinheit und zum zweiten für eine zweite Seriensteuereinheit der Softwarecode für die Softwarefunktionen automatisch generiert wird, wobei identische Eingangsgrössen für die Softwarefunktionen auf beiden Steuergeräten zum Einsatz kommen und die sich daraus ergebenden Ausgangsgrössen beider Steuereinheiten zeitsynchron, also simultan erfasst werden, wobei durch Vergleich der Ausgangsgrössen beider Steuereinheiten die Softwarefunktionen verifiziert werden.

Description

Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
Stand der Technik
Die Erfindung betrifft ein Verfahren und ein System zur Verifikation von Softwarefunktionen für eine Steuereinheit gemäß den unabhängigen Ansprüchen. Des Weiteren betrifft die Erfindung ein Computerprogramm, bestehend aus Programm-Code- Elementen zur Ausführung eines Verfahrens zur Softwareverifikation gemäß Anspruch 10.
Die zunehmende Komplexität der Steuergerätefunktionen bzw. der einzelnen Automobilsteuergeräte oder Steuereinheiten (Electronic Control Units ECU) , aber auch die zunehmende Vernetzung und Interaktion der Steuereinheiten und Steuergerätefunktionen im Fahrzeugverbund sowie erhöhte Qualitäts- und Sicherheitsanforderungen machen die Verifikation der Softwarefunk ionen schwierig und sehr aufwendig. Dies gilt ebenso für die Vernetzung von Steuereinheiten und Modulen in anderen technischen Gebieten wie beispielsweise dem Werkzeugmaschinenbau, der Automatisierung usw. Heute erfolgt die Softwarefreigabe für die Einzelsysteme durch systematischen Test im Elektronikverbund. Gerade im Automobilbereich ist dies häufig nur im Fahrzeug möglich und dementsprechend kostspielig. Dabei werden unter definierten Umgebungsbedingungen festgelegte Fahrsituationskataloge abgefahren, um eine möglichst hohe Abdeckung beim Softwaretest zu erreichen. Da aus Kostengründen bei Seriensteuergeräten nur sehr begrenzte Speicher- und Laufzeit-Ressourcen zur Verfügung stehen, ist der Einsatz etablierter Testtechnologien, etwa zur Codeabdeckungs- (Code Coverage) Analyse bei der Softwarefreigabe häufig nicht möglich oder mit erhöhten Kosten verbunden.
Dies ist in der DE 199 59 247 AI insofern sichtbar, als dass ein zusätzlicher Codeabdeckungsspeicher zur Erfassung der Codeabdeckung notwendig ist. So zeigt die Erfindung in der genannten Offenlegungsschrift einen Mikrocomputer zum Einsatz in einem Steuerungs- bzw. Regelungsgerät zur Regelung eines Prozesses in einem Kraftfahrzeug. Um die Codeabdeckung eines Steuerungs- bzw. Regelungsprogramms des Mikrocomputers auch während der Fahrt des Kraftfahrzeugs bestimmen zu können, wird vorgeschlagen, dass der Mikrocomputer einen CodeabdeckungsSpeicher zusätzlich und parallel zum Programmspeicher und Datenspeicher enthält, der über den Adressbus und den Datenbus an den Mikroprozessor angeschlossen ist. Dabei sind dann in dem Codeabdeckungsspeieher Angaben darüber ablegbar, welche Adressen des Programmspeichers bzw. des Datenspeichers während der Ausführung eines Steuerungsprogramms aus dem Programmspeicher durch den Mikrocomputer während einer Fahrt des Kraftfahrzeugs im Rahmen eines Schreib- bzw. Lesezugriffs angesprochen werden. Dabei wird als ein mögliches Prüf- und Testverfahren für Programme aus dem Stand der Technik das zum Bestimmen der Codeabdeckung sogenannte Code-Coverage-Verfahren durchgeführt durch einen sogenannten System Execution Analyser. Dabei führen alle in einem externen Adressbus anliegenden Adressen des Mikroprozessors zu einem Kennzeichen in einer Memory- Übersicht. Die am Ende des Tests nicht gekennzeichneten Adressbereiche wurden somit im Rahmen der Durchführung des Programms nicht angesprochen und die entsprechenden Programmteile somit nicht durchlaufen. Durch solch eine Analyse der Testlücken lassen sich z. B. nicht getestete Funktionen sowie fehlerhafte Umsetzung von Funktionsanforderungen erkennen und beseitigen.
Wenn aber ein zusätzlicher Codeabdeckungsspeicher und die entsprechende Rechenzeit nicht zur Verfügung steht, was bei einer Seriensteuereinheit in der Regel gegeben ist, so ist das Verfahren gemäß der DE 199 59 247 AI nicht durchführbar. Dann ist außer dem Messen von steuergeräteinternen Größen kein Zugriff auf die Steuergerätesoftware bzw. die entsprechenden Softwarefunktionen möglich und die Sof warefunktionen können dann nur als als Black Box getestet werden. Diese Situation führt bei der gleichzeitig geforderten hohen Echtzeitfähigkeit und Zuverlässigkeit der Systeme zu einem Zielkonflikt.
Da in naher Zukunft Steuergerätesoftware auch sicherheitsrelevante Fahrfunktionen steuert und überwacht, wie beispielsweise bei X-By-Wire-Systemen, steigen die Qualitätsanforderungen für die Softwareentwicklung und Verifikation bei Embedded-Control-Systemen weiter.
Ziel der Erfindung ist es, anhand eines exakt definierten, durchgängigen Funktionsentwicklungsprozesses ein Verfahren zur Verifikation der Softwarefunktionen bzw. des Softwarecodes anzugeben, womit die Qualität der Software weiterhin gesichert werden kann, um die sich aus dem Stand der Technik ergebende Situation zu optimieren. Dazu ist neben dem Verfahren auch ein System zur Verifikation sowie ein entsprechendes Computerprogramm Gegenstand der Erfindung .
Vorteile der Erfindung Dazu betrifft die Erfindung ein Verfahren und ein System sowie ein entsprechendes Computerprogramm zur Verifikation von Softwarefunktionen für eine Steuereinheit mit Verwendung eines Simulationsmodells zur Abbildung der Softwarefunktionen und der Steuereinheit, wobei vorteilhafter Weise aus dem identischen Simulationsmodell zum Einen für eine erste Experimentalsteuereinheit und zum Zweiten für eine zweite Seriensteuereinheit der Softwarecode für die Softwarefunktionen automatisch generiert wird, wobei identische Eingangsgrößen für die Softwarefunktionen auf beiden Steuergeräten zum Einsatz kommen und die sich daraus ergebenden Ausgangsgrößen beider Steuereinheiten zeitsynchron, also simultan erfasst werden, wobei durch Vergleich der Ausgangsgrößen beider Steuereinheiten die Softwarefunktionen verifiziert werden.
Es wird somit ein einheitliches Simulationsmodell für die Experimentalsteuereinheit, also das Experimentaltarget sowie für die Seriensteuereinheit, also das ECU Target zu Grunde gelegt. Auf dieser Basis erfolgt dann, wie genannt, ein sogenanntes Target-Identical-Prototyping der in dem Simulationsmodell, z. B. ASCET-SD, modellierten Funktionen auf dem Experimentaltarget sowie die Stimulation der Funktionen durch die Steuergeräteeingangsgrößen. Zum Anderen erfolgt ebenfalls automatisch aus dem Simulationsmodell mit Hilfe einer Target-Code-Generierung die Umsetzung für die Softwarefunktionen aus dem identischen Modell für die Seriensteuereinheit, also das ECU-Target. Die Verifikation erfolgt dann durch parallelen Funktionstest auf Experimentaltarget und ECU-Target .
Dabei wird vorteilhafter Weise die Erfassung und der Vergleich der Ausgangsgrößen und/oder zu den Ausgangsgrößen führenden Zwischengrößen von Seriensteuereinheit, also ECU- Target mit denen des Experimentaltarget oder der Experimentalsteuereinheit automatisch durch die Experimentalsteuereinheit durchgeführt .
Dabei wird vorteilhafter Weise der Softwarecode für die Softwarefunktionen jeweils für Experimentalsteuereinheit und Seriensteuereinheit mit unterschiedlichen Erzeugungsmitteln generiert, also insbesondere mit unterschiedlichen Compilern entweder für den gleichen Prozessor oder für verschiedene Prozessoren übersetzt.
In einer vorteilhaften Ausführungsform wird zusätzlich bei der Verifikation der Softwarefunktionen die Codeabdeckung, also die durchlaufenden Pfade im Softwarecode und/oder in den Softwarefunktionen zur Bestimmung der
Sof warecodeabdeckung auf der Experimentalsteuereinheit, dem Experimentaltarget oder auf der Seriensteuereinheit erfasst, was beim ECU Target den Vorteil hat, dass sie hardwareabhängige oder Plattform Software eingeschlossen ist.
In einer bevorzugten Ausführungsform dienen dabei die Softwarefunktionen zur Steuerung von Betriebsabläufen bei einem Fahrzeug und werden dann entsprechend mit dem Verfahren, dem System sowie entsprechendem Computerprogramm verifiziert .
In einer besonders vorteilhaften und kostengünstigen Ausführungsform wird die gesamte Verifikation der Softwarefunktionen mit einem ein Fahrzeug und/oder Fahrzeugkomponenten und/oder Fahrzeugfunktionen simulierenden Simulationsmittel, beispielsweise LabCar ohne Einsatz eines realen Fahrzeugs durchgeführt.
Vorteilhafter Weise wird der Softwarecode der Softwarefunktionen in hardwareabhängigen Softwarecode und hardwareunabhängigen Softwarecode unterteilt. Dabei beinhaltet der hardwareabhängige Teil, beispielsweise das Betriebssystem und den sogenannten Hardware-Abstraction- Layer zur Definition allgemeiner standardisierter Schnittstellen zur Anbindung an diesen hardwareabhängigen Softwarecodeteil für verschiedene, wählbare, hardwareunabhängige Softwarecodeteile, wobei der hardwareunabhängige Softwarecodeteil die Softwarefunktionen zur Steuerung der Betriebsabläufe bei einem Fahrzeug enthält.
So entsteht im Weiteren neben der Softwareverifikation ein mehrstufiger Funktionsentwicklungsprozess, mit welchem in jeder Phase die Softwaregualität gesteigert und das Entwicklungsrisiko minimiert werden kann, was ein hohes Potential zur Kosteneinsparung mit sich bringt.
Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung sowie den Merkmalen der Ansprüche.
Zeichnungen
Die Erfindung wird im Weiteren anhand der in der Zeichnung dargestellten Figuren näher erläutert .
Dabei zeigt Figur 1 eine Seriensteuereinheit, also ein ECU- Target und ein Experimentaltarget mit Darstellung der j eweiligen Softwarearchitektur .
Figur 2 zeigt in einem Flussdiagramm den Ablauf des Verfahrens zur Softwareverifikation.
In Figur 3 ist noch einmal der Daten- und Kontrollf luss , bezogen auf das er findungs gemäße Verfahren zur Softwareverifikation, dargestellt .
Beschreibung der Ausführungsbeispiele Figur 1 zeigt dazu eine Seriensteuereinheit 100, das sogenannte ECU-Target sowie die Experimentalsteuereinheit 101, das sogenannte Experimentaltarget. Beide Steuereinheiten 100 und 101 stehen über die Kommunikationsverbindung 103 in Verbindung. Je nach Anwendungsfall kann diese Kommunikationsverbindung uni- oder bidirektional, seriell oder parallel usw. sein. Weiterhin ist mit dem Experimentaltarget 101 ein Visualisierungsund/oder Auswertungsmittel 102 verbunden, welches im Weiteren auch als GUI oder Graffical User Interface bezeichnet wird. Die Verbindung selbst, eben parallel oder seriell sowie unidirektional oder bidirektional ist hierbei mit 104 bezeichnet. Dieses Visualisierungsmittel 102 kann, wie schon erwähnt, auch Auswertemöglichkeit, also eine Recheneinheit und/oder eine Speichereinheit umfassen, wobei dieses GUI ebenfalls im Experimentaltarget integriert sein kann.
Mit den Blöcken 105 und 106 ist symbolisch die ECU- Softwarearchitektur sowie die Softwarearchitektur des Experimentaltarget dargestellt. Die Architektur der Software bzw. der Softwarefunktionen der Seriensteuereinheit, also die ECU-Software hat zentrale Bedeutung, etwa für die Komponenten- und Variantenbildung, die Wiederverwendung und Portierbarkeit sowie die Unterstützung von Schnittstellen der Seriensteuereinheit für Entwicklungswerkzeuge. Der Entwicklungsprozess und die Softwarearchitektur müssen daher gemeinsam betrachtet werden. Dabei ist eine
Schichtenarchitektur vorteilhaft, bei der eine Trennung der eigentlichen Steuergerätefunktionalität, also der hardwareunabhängigen Softwarefunktionen wie Applikationssoftware von den hardwareabhängigen Softwareschichten der Plattformsoftware durchgeführt ist. Dadurch kann einerseits die Plattformsoftware projektübergreifend wiederverwendet werden und zweitens werden vorteilhafter Weise die Schnittstellen für den Zugriff auf die Steuereinheiten vereinheitlicht. Damit ist der Einsatz standardisierter Methoden bzw. auf diese Standardschnittstellen abgestimmter Werkzeuge während der Entwicklung, der Verifikation, aber auch in der Fertigung und im Service möglich, z. B. für Rapid Prototyping, Debugging, Messen und Kalibrieren. Außerdem können die Funktionen der Applikationssoftware bzw. die Softwarefunktionen, insbesondere zur Steuerung von Betriebsabläufen bei einem Fahrzeug, hardwareunabhängig spezifiziert werden und sind damit auf unterschiedliche Steuergeräteplattformen portierbar .
Im Block 105 ist dabei beispielsweise ein Block Daten 107 enthalten, der die Gesamtheit der Daten, also Eingangs- und Ausgangsgrößen, Messdaten, interne Zwischengrößen usw. umfasst. Diese Daten der Funktionen sind im Rahmen der Softwarefunktionen im Block 107 und Block 109 im Wesentlichen gleich. Im Softwareblock 105 sind aber weiterer Softwarecode bzw. weitere Softwarefunktionen nicht mehr direkt zugreifbar, so dass Block 108 Black-Box-Verhalten zeigt und auf dem ECU-Target im Wesentlichen nur ein Messen und Kalibrieren, bezogen auf den Datenblock 107, möglich ist .
Daneben wird zur späteren Verifikation das
Experimentaltarget 101 eingesetzt, bei dem auch der Zugriff auf das Verhalten der Funktionen bzw. der Softwarefunktionen in Block 110 zusätzlich zum Datenblock 109 im Rahmen der hardwareunabhängigen Software möglich ist. Bei Experimentaltarget ist somit nur im Block 111, also bezüglich der Plattformsoftware, Black-Box-Verhalten gezeigt. Darin ist das Betriebssystem, beispielsweise OSEK- OS oder ERCOS sowie Automotive Services und der angesprochene Abstraktionslayer, Hardwareabstractionlayer HAL eingebettet. Durch diese Abstraktionsschicht wird die Unabhängigkeit der darüberliegenden Softwareschichten, insbesondere der Applikationssoftware, die Verhalten und Daten der Softwarefunktionen beschreiben bzw. enthalten, ermöglicht .
Um die Verifikation der Softwarefunktionen bzw. des Sof warecodes, wie auch in den weiteren Figuren 2 und 3 beschrieben, zu ermöglichen, ist im Wesentlichen die Softwarestruktur zwischen Seriensteuereinheit, also ECU- Target und Experimentaltarget, also der
Experimentalsteuereinheit gleich. Wichtig ist auch, um es später noch zu beschreiben, die Zeitsynchronität im Rahmen der Verifikation darzustellen, wobei das zu Grunde liegende Betriebssystem bzw. die jeweils zu Grunde liegenden Betriebssysteme gleiches Zeitverhalten aufweisen, wobei vorteilhaf er Weise gleiche oder vergleichbare Betriebssysteme, insbesondere Standardbetriebssysteme wie OSEK und andere Standards wie ASAM Berücksichtigung und Verwendung finden.
Durch die Zugriffsmöglichkeit auf die Daten und das Verhalten der Softwarefunktionen sind in den Blöcken 109 und 110 im Gegensatz zur Seriensteuereinheit diesbezüglich Rapid-Prototyping oder durch Verwendung des gleichen Simulationsmodells ASCET-SD Target-Identical-Prototyping der in ASCET-SD-modellierten Funktionen auf dem
Experimentaltarget und Stimulation der Funktionen durch die Eingangsgrößen der Seriensteuereinheit möglich.
Das Simulationsmodell bzw. das zugehörige
Entwicklungswerkzeug, beispielsweise ASCET-SD unterstützt dazu die grafische, physikalische und komponentenbasierte Modellierung von Funktionen der hardwareunabhängigen Software, insbesondere der Applikationssoftware, die Simulation und Rapid-Prototyping mit Experimentaltarget, also das Target-Identical-Prototyping sowie die automatische Targetcodegenerierung für die Implementierung auf der Seriensteuereinheit, dem Zielsystem. Zusätzlich wird durch das Simulationsmodell bzw. die entsprechenden Entwicklungswerkzeuge eine vollständige Beschreibungsdatei in einem Standardformat, beispielsweise ASAM-MCD2 , für alle Mess- und Verstellgrößen einer Steuereinheit generiert, wodurch standardisierte Mess- und Kalibrierwerkzeugschnittstellen möglich sind.
In Figur 2 ist ausgehend von der Erstellung des Simulationsmodells in Block 200 die Verf hrensabfolge dargestellt. Dabei ist das Simulationsmodell, insbesondere ASCET-SD, insbesondere für die hardwareunabhängigen Softwarefunktionen „Single Source", also Basis gleichermaßen für die Seriensteuereinheit, also das ECU-Target und die Experimentalsteuereinheit. Im Block 201 erfolgt die Targetcodegenerierung bezüglich des ECU-Targets für die Softwarefunktionen aus dem im Block 200 gebildeten Simulationsmodell für die Seriensteuereinheit.
In Block 202 erfolgt ebenfalls automatisch das Target- Identical-Prototyping der im Simulationsmodell modellierten Funktionen auf dem Experimentaltarget. Dabei bedeutet Target-Identical-Prototyping, dass das gesamte arithmetische sowie das Zeitverhalten spezifiziert und simuliert wird (auf der Experimentalsteuereinheit) und virtuell exakt übereinstimmt mit dem Systemverhalten der Seriensteuereinhei .
Im Block 203 erfolgt dann die Erzeugung des Softwarecodes, insbesondere durch Kompilierung in C für das ECU-Target. Dabei kann der Softwarecode in einer beliebigen Programmiersprache vorliegen, das Beispiel C wie auch C++ oder Java, etc. sind nicht einschränkend im Hinblick auf den erfindungsgemäßen Gegenstand zu verstehen. Gleichermaßen erfolgt in Block 204 die Umsetzung in genannten Softwarecode für die Experimentalsteuereinheit. In Block 208 und Block 209 erfolgt nun die eigentliche Softwareverifikation. Dazu erfolgt in Block 208 ein zeitlich paralleler Funktionstest auf Seriensteuereinheit 205 und Experimentalsteuereinheit 206 wobei angedeutet über Verbindung 207 ein Datenaustausch erfolgen kann. Dabei sind die Testfälle für Seriensteuereinheit und
Experimentalsteuereinheit identisch. So wird insbesondere bei z.B. Fließpunktarithmetik des Experimentaltarget (z.B. auch Festpunktarithmetik möglich) und beispielsweise Festpunktarithmetik auf der Seriensteuereinheit ein Vergleich zwischen Fließpunktarithmetik und Festpunktarithmetik möglich. Damit ist es frühzeitig möglich, den Einfluss von Quantisierungs- und Überlaufeffekten auf dem Seriensteuergerät, also dem ECU- Target zu untersuchen, um eine Anzeige von Unzulänglichkeiten bezüglich der Implementierung zu ermöglichen und gegebenenfalls insbesondere automatisch zu korrigieren.
Im Block 209 erfolgt dann das Messen und der Vergleich der Ausgangsgrößen bezüglich der Softwarefunktionen, vorzugsweise auf der Experimentalsteuereinheit. Die Messung auf Seriensteuereinheit und Experimentalsteuereinheit bzw. die Erfassung der Werte und deren Vergleich erfolgt dabei simultan und zeitsynchronisiert . Somit ist zusammenfassend eine Softwareverifikation mit Target-Identical-Prototyping und Target-Code-Generierung möglich. Es können identische Code-Generator-Optionen für das Target-Identical-Prototyping und die Target-Code-Generierung zur Verfügung stehen, wodurch dann auf beiden Targets bzw. Steuereinheiten Festpunktarithmetik zum Einsatz kommt. Wie vorher angedeutet, kommen vorteilhafter Weise auf dem Experimentaltarget gleiche Betriebssysteme, insbesondere ein OSEK-Betriebssystem, wie beispielsweise ERCOS und identische Dienste-Routinen, wie in der Seriensteuereinheit , zum Einsatz .
Optional und zusätzlich ist mit Block 210 eine Codeabdeckungsanalyse, die sogenannte Code-Coverage-Analyse entweder über Verbindung 212 auf dem Experimental Target oder auch optional über Verbindung 213 auf der Seriensteuereinheit möglich. Dazu wird der insbesondere vom Simulationsmodell automatisch generierte Softwarecode, insbesondere C-Code, instrumentiert. Dazu können kommerzielle Coverage-Werkzeuge zur Codeinstrumentierung bzw. zur Coverage-Analyse in das Simulationsmodell eingebunden werden, um das Ziel, eine hohe Abdeckung (Pfad- und/oder Zweigabdeckung) zu erreichen, zu erzielen.
So kann beispielsweise unter der Voraussetzung von 100% Target-Identical-Prototyping für die hardwareunabhängigen Softwaref nktionen kann aus 100% Zweigabdeckung, auf 100% Zweigabdeckung auf dem ECU-Target geschlossen werden.
Alternativ könnte die Code-Coverage-Analyse auch auf dem ECU-Target ausgeführt werden, wie über Verbindung 213 dargestellt, wobei in diesem Fall vorteilhaft wäre, dass die Code-Coverage-Analyse direkt auf dem Softwarecode der Seriensteuereinheit ausgeführt wird, und damit auch der hardwareabhängige Softwareanteil, die Plattformsoftware, abgedeckt ist.
Aus einem identischen Simulationsmodell, beispielsweise ASCED-SD wird für zwei Pfade zur späteren Verifikation, insbesondere C-Code, als Softwarecode generiert, für das ECU-Target mit Target-Code-Generierung und für das Experimentaltarget mit Target-Identical-Prototyping. Zu dem Vergleich zwischen Fließpunktarithmetik auf der Experimentalsteuereinheit mit Festpunktarithmetik, auf der Seriensteuereinheit werden gleiche Teststimuli, also insbesondere gleiche Eingangsgrößen, und eine simultane und synchronisierte Messwerterfassung, also eine Erfassung der Ausgangsgrößen auf beiden Steuereinheiten durchgeführt.
Vorteilhafter Weise ist dabei die Mess- und Simulationsumgebung in die Experimentalsteuereinheit integriert und könnte ebenso im Labor, am Prüfstand sowie im Fahrzeug eingesetzt werden. Vorteilhafter Weise wird der Messgrößenvergleich, also der Vergleich der Ausgangsgrößen, auf der Experimentalsteuereinheit gerechnet. Durch die Diversität der verwendeten Plattformen inklusive Compiler und Codegeneratorsets wird zudem die Untersuchung und Überprüfung von Codegeneratoroptimierungen speziell für die Seriensteuereinheit, das Identifizieren von Codegenerator-, Compiler- und Prozessorproblemen bzw. -fehlem sowie das Erkennen von Timingproblemen der Seriensteuereinheit möglich. Dies wird nun anhand des Daten- und Kontrollflusses in Figur 3 noch einmal näher erläutert .
In Figur 3 ist mit Block 101 die Experimentalsteuereinheit und mit Block 100 wieder die Seriensteuereinheit dargestellt. Die Seriensteuereinheit 100 erhält über Verbindung 303 spezifische Eingangsgrößen und gibt über Verbindung 302 entsprechend der Softwarefunktionen Ausgangsgrößen oder Messgrößen aus. Block 300, die Steuerstrecke, kann zum Einen, wie schon erwähnt, das Fahrzeug, sein; zum Anderen eine Simulationsumgebung wie z. B. die Darstellung verschiedener Fahrzeugfunktionen bzw. des gesamten Fahrzeugs im Labor als LabCar, wodurch der gesamte Prüfablauf zusammen mit einem solchen LabCar ins Labor verlagert und automatisiert werden kann. Die Eingangsgrößen der realen Seriensteuereinheit können dabei beispielsweise über die bidirektionale Verbindung 103 oder alternativ mit der Verbindung 304 der
Experimentalsteuereinheit übermittelt werden. Ebenso können die Messgrößen oder Ausgangsgrößen der Seriensteuereinheit zum Vergleich, sofern dieser auf der
Experimentalsteuereinheit durchgeführt wird, diesen via Verbindung 103 übermittelt werden.
Die Leitung 301 bzw. der symbolische Signalfluss stellt beispielsweise einen Trigger von dem ECU-Target zum Experimental Target dar. Ebenso können die Ausgangsgrößen der Seriensteuereinheit über Pfad 306 einem Visualisierungsund unter Umständen Auswertesystem 102 GUI übermittelt werden, welches über Verbindung 104 insbesondere bidirektional mit der Experimentalsteuereinheit in Verbindung steht. Auch hier ist prinzipiell eine Integration des GUI in die Experimentalsteuereinheit möglich.
Ebenso können optional die Ausgangsgrößen des Experimentaltargets oder auch die Vergleichsergebnisse über einen Pfad 305 an weitere Auswertemittel oder Anzeigemittel übermittelt werden. Insbesondere in der
Experimentalsteuereinheit, aber auch alternativ in einer Visual!sierungs- oder Auswerteeinheit, beispielsweise 102 oder verbunden mit Pfad 305 erfolgt ein Vergleich der Ausgangsgrößen der Softwarefunktionen von
Experimentalsteuereinheit und Seriensteuereinheit. Sind die Ausgangsgrößen gleich, so wurde Target-Identical-Prototyping bezogen auf die unabhängigen Sof warefunktionen erreicht. Unterscheiden sich die Ausgangsgrößen, liegen entweder Probleme mit dem Codegenerator, dem Compiler, dem Prozessor, den Dienstroutinen oder dem Timing der Seriensteuereinheit, dem ECU-Timing vor und können als Fehler angezeigt werden sowie mit entsprechenden Fehlerreaktionen belegt werden. Diese Fehleraufdeckung ist insofern gesichert, als getrennte Pfade verwendet werden; nicht nur dadurch, dass zwei Prozessoren - einer im Experimentaltarget und einer im ECU- Target verwendet werden, sondern auch, wenn diese optional nicht typgleich sind, ebenso wie unterschiedliche Compiler, um die Fehlerwiederholung in beiden Pfaden zu unterbinden und die Fehler bzw. Probleme zu entdecken. Das im bisherigen beschriebene Verfahren läuft automatisiert im Rahmen eines Computerprogramms mit Programmcodeelementen auf dem dargestellten Verfifikationssystem ab. Dabei werden einzelne Programmcodeelemente abgearbeitet um die erfindungsgemäßen Verfahrensschritte gemäß der Ansprüche zu erzielen. Die Programmcodeelemente, die bei Ausführung auf einem Computer, Rechner bzw. dem Verfifikationssystem ablaufen bzw. durchgeführt werden, haben dann die beschriebenen Verfahrensschritte des erfindungsgemäßen Systems zur Folge. Dabei sind die Programmcodeelemente auf einem beliebigen Datenträger (systemimanent oder extern) also RAM, ROM, EPROM, CD-ROM, Diskette, usw. vor oder zur Ausführung abgespeichert.

Claims

Patentansprüche
1. Verfahren zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulationsmodells zur Abbildung der Softwarefunktionen und der Steuereinheit, dadurch gekennzeichnet, dass aus dem identischen Simulationsmodell zum einen für eine erste Experimentalsteuereinheit und zum zweiten für eine zweite Seriensteuereinheit der Softwarecode für die Softwarefunktionen automatisch generiert wird, wobei identische Eingangsgrößen für die Softwarefunktionen auf beiden Steuergeräten zum Einsatz kommen und die sich daraus ergebenden Ausgangsgrößen beider Steuereinheiten zeitsynchron erfasst werden, wobei durch Vergleich der Ausgangsgrößen beider Steuereinheiten die Sof warefunktionen verifiziert werden .
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Erfassung und der Vergleich der Ausgangsgrößen und/oder zu den Ausgangsgrößen führender Zwischengrößen durch die erste Experimentalsteuereinheit automatisch durchgeführt werden.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Softwarecode für die Softwarefunktionen jeweils für Experimentalsteuereinheit oder Seriensteuereinheit mit unterschiedlichen Erzeugungsmitteln generiert wird.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zusätzlich bei der Verifikation die durchlaufenen Pfade im Softwarecode und/oder in den Softwarefunktionen zur Bestimmung der Softwarecodeabdeckung auf der Experimentalsteuereinheit erfasst werden.
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, das die Softwarefunktionen zur Steuerung von Betriebsabläufen bei einem Fahrzeug dienen.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die gesamte Verifikation der Softwarefunktionen mit einem ein Fahrzeug simulierenden Simulationsmittel ohne Einsatz eines realen Fahrzeugs durchgeführt wird.
7. Verfahren nach Anspruch 1 und 5, dadurch gekennzeichnet, dass der Softwarecode in hardwareabhängigen Softwarecode und hardwareunabhängigen Softwarecode unterteilt ist, wobei nur der hardwareunabhängige Softwarecode Softwarefunktionen zur Steuerung von Betriebsabläufen bei einem Fahrzeug dient.
8. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zusätzlich bei der Verifikation die durchlaufenen Pfade im Softwarecode und/oder in den Softwarefunktionen zur Bestimmung der Softwarecodeabdeckung auf der Seriensteuereinheit erfasst werde .
9. System zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulationsmodells zur Abbildung der Softwarefunktionen und der Steuereinheit, mit einer ersten Experimentalsteuereinheit und einer zweiten Seriensteuereinheit, die miteinander in
Kommunikationsverbindung stehen, dadurch gekennzeichnet, dass erste Mittel enthalten sind, welche aus dem identischen Simulationsmodell zum einen für die erste Experimentalsteuereinheit und zum zweiten für die zweite Seriensteuereinheit den Softwarecode für die Softwarefunktionen automatisch generieren, wobei identische Eingangsgrößen für die Softwarefunktionen auf beiden Steuergeräten zum Einsatz kommen und zweite Mittel enthalten sind, welche die sich daraus ergebenden Ausgangsgrößen beider Steuereinheiten zeitsynchron erfassen, wobei dritte Mittel, insbesondere auf der Experimentalsteuereinheit, enthalten sind, welche durch Vergleich der Ausgangsgrößen beider Steuereinheiten die Softwarefunktionen verifizieren.
10. Computerprogramm bestehend aus Programmcodeelementen, durch welches bei Ausführung der Programmcodeelemente auf einem Computer oder auf einem Computersystem, insbesondere auf einer Steuereinheit oder auf einem System gemäß Anspruch 9, ein Verfahren nach einem der Ansprüche 1 bis 8 automatisch durchgeführt wird.
EP02760105A 2001-09-07 2002-07-24 Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem Ceased EP1428126A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10144050 2001-09-07
DE10144050A DE10144050A1 (de) 2001-09-07 2001-09-07 Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
PCT/DE2002/002725 WO2003027850A2 (de) 2001-09-07 2002-07-24 Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem

Publications (1)

Publication Number Publication Date
EP1428126A2 true EP1428126A2 (de) 2004-06-16

Family

ID=7698161

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02760105A Ceased EP1428126A2 (de) 2001-09-07 2002-07-24 Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem

Country Status (6)

Country Link
US (1) US7275184B2 (de)
EP (1) EP1428126A2 (de)
JP (1) JP4236104B2 (de)
AU (1) AU2002325798A1 (de)
DE (1) DE10144050A1 (de)
WO (1) WO2003027850A2 (de)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7502728B1 (en) * 2002-04-30 2009-03-10 Unisys Corporation Code coverage testing in hardware emulation
GB0213688D0 (en) * 2002-06-14 2002-07-24 Ibm Automated test generation
US7596778B2 (en) * 2003-07-03 2009-09-29 Parasoft Corporation Method and system for automatic error prevention for computer software
US20050033457A1 (en) * 2003-07-25 2005-02-10 Hitoshi Yamane Simulation aid tools and ladder program verification systems
EP1530138A1 (de) * 2003-11-10 2005-05-11 Robert Bosch Gmbh Generische Mess- und Kalibrierschnittstelle zur Entwicklung von Steuerungsprogrammen
US7162389B2 (en) * 2003-12-01 2007-01-09 Fujitsu-Ten Limited Evaluation device for control unit, simulator, and evaluation system
US7793269B2 (en) * 2005-02-15 2010-09-07 Ebay Inc. Parallel software testing based on a normalized configuration
US7383460B2 (en) * 2005-03-25 2008-06-03 Microsoft Corporation Method and system for configuring a timer
SE529634C2 (sv) * 2006-03-02 2007-10-09 Abb Ab En metod för att jämföra variabelvärden erhållna från olika versioner av ett applikationsprogram samt ett automationssystem och en styrenhet
SE529676C2 (sv) * 2006-03-02 2007-10-23 Abb Ab En metod för att utvärdera en applikation, ett automationssystem och en styrenhet
US8087007B2 (en) * 2006-05-08 2011-12-27 Assima Ltd. System and method for software prototype-development and validation and for automatic software simulation re-grabbing
GB0614067D0 (en) * 2006-07-17 2006-08-23 Ineos Fluor Holdings Ltd Heat transfer compositions
US8161457B2 (en) * 2007-03-06 2012-04-17 International Business Machines Corporation Detection of errors caused by interactions of independent software vendor code with host code
US9442701B1 (en) * 2007-06-21 2016-09-13 The Mathworks, Inc. Verifying models for exceptional behavior
DE102007028721A1 (de) 2007-06-21 2008-12-24 Iav Gmbh Ingenieurgesellschaft Auto Und Verkehr Verfahren und Vorrichtung zur Verifizierung von Funktionsabläufen in einem Steuergerät
WO2009146979A1 (en) 2008-06-05 2009-12-10 International Business Machines Corporation Method system and computer program for identifying software problems
JP5494255B2 (ja) * 2010-06-07 2014-05-14 富士電機株式会社 安全制御システム
EP2503459B1 (de) * 2011-03-23 2021-01-20 Volvo Car Corporation Komplett und kompatibel-Funktion
US8694978B1 (en) * 2011-03-25 2014-04-08 Google Inc. Function side-effect modeling by prototyping
CN106874055B (zh) * 2017-03-07 2020-01-31 上海怿星电子科技有限公司 一种用于汽车ecu程序自动刷写测试的方法和装置
DE102018212560A1 (de) * 2017-08-08 2019-02-14 Robert Bosch Gmbh Rechnergestütztes System zum Testen einer servergestützten Fahrzeugfunktion
CN109409022B (zh) * 2018-12-21 2023-07-14 核动力运行研究所 一种用于核电堆芯物理仿真可视化建模调试测试方法
US11237802B1 (en) 2020-07-20 2022-02-01 Bank Of America Corporation Architecture diagram analysis tool for software development
DE102021201837A1 (de) * 2021-02-26 2022-09-01 Siemens Mobility GmbH Verfahren zur Konfiguration einer Steuerungssoftware bei einem Schienenfahrzeug

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS56500945A (de) 1979-07-27 1981-07-09
US5551050A (en) * 1989-12-20 1996-08-27 Texas Instruments Incorporated System and method using synchronized processors to perform real time internal monitoring of a data processing device
FR2685838B1 (fr) * 1991-12-27 1994-02-25 Sgs Thomson Microelectronics Sa Procede pour verifier la conformite a une norme d'une cellule representative d'un circuit dedie a la gestion d'un protocole de communication, et systeme pour sa mise en óoeuvre.
US5313618A (en) * 1992-09-03 1994-05-17 Metalink Corp. Shared bus in-circuit emulator system and method
US5946472A (en) * 1996-10-31 1999-08-31 International Business Machines Corporation Apparatus and method for performing behavioral modeling in hardware emulation and simulation environments
US5960188A (en) * 1997-03-13 1999-09-28 Delco Electronics Corporation Method for modeling electrical interconnections in a cycle based simulator
US6332201B1 (en) * 1999-03-23 2001-12-18 Hewlett-Packard Company Test results checking via predictive-reactive emulation
US6973417B1 (en) * 1999-11-05 2005-12-06 Metrowerks Corporation Method and system for simulating execution of a target program in a simulated target system
DE19959247A1 (de) 1999-12-08 2001-06-13 Bosch Gmbh Robert Mikrocomputer zum Einsatz in einem Steuerungs-/Regelungsgerät eines Kraftfahrzeugs und Verfahren zum Bestimmen der Codeabdeckung eines Steuerungs-/Regelungsprogramms des Mikrocomputers
US7035784B1 (en) * 2000-09-22 2006-04-25 Lucent Technologies Inc. Data-driven method simulator and simulation process
US20030088710A1 (en) * 2001-07-05 2003-05-08 Sukhwinder Sandhu Simulation environment software

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
DE10144050A1 (de) 2003-03-27
US7275184B2 (en) 2007-09-25
AU2002325798A1 (en) 2003-04-07
US20050022166A1 (en) 2005-01-27
JP4236104B2 (ja) 2009-03-11
WO2003027850A2 (de) 2003-04-03
JP2005504377A (ja) 2005-02-10
WO2003027850A3 (de) 2004-02-05

Similar Documents

Publication Publication Date Title
EP1428126A2 (de) Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP2770389B1 (de) Verfahren zur Durchführung einer Konfiguration eines Steuergeräte-Testsystems
DE69810795T2 (de) Automatisierte gültigkeitsbestätigung und richtigkeitsprüfung von rechnersoftware
EP2244141B1 (de) Verfahren und Vorrichtung zur Verifizierung eines Automatisierungssystems
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
EP2770434B1 (de) Verfahren zur Durchführung einer Inventarisierung der an ein Steuergeräte-Testsystem angeschlossenen Hardware-Komponenten
EP3306295B1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
WO2009095202A1 (de) Verfahren und vorrichtung zur ausführung von tests mittels funktional kaskadierten test- und experimentiervorrichtungen
DE202016008563U1 (de) Konfigurationssystem zum Konfigurieren eines für das Testen eines Steuergeräts eingerichteten Testgeräts
DE102009034242A1 (de) Verfahren und Vorrichtung zum Prüfen eines Steuergeräts eines Fahrzeugs
WO2015035438A1 (de) Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens
EP2653850B1 (de) Verfahren und IT-System zum Durchführen von Gesamtfahrzeugtests
DE102020102996A1 (de) Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung
WO2006081869A1 (de) Vorrichtung und verfahren zum testen von komponenten und systemen
EP1632855A1 (de) Funktionseinheit zur Ausführung von logischen Testfällen auf einem an eine zu prüfende Einheit angekoppelten Testsystem und entsprechendes Verfahren
WO2020099524A1 (de) Verfahren und systeme zur bereitstellung von leistungsdaten eines steuergerätes im fahrbetrieb
Ursu et al. Simulink® modeling for vehicle simulator design
DE102009054137A1 (de) Verfahren zum Testen einer Applikation hinsichtlich ihrer Performanz
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms
AT525591A1 (de) Verfahren und Vorrichtung zur automatischen Analyse eines Diagnosesystems eines Fahrzeugs
DE102022115636A1 (de) Verfahren zum Evaluieren eines Ergebnisses einer Simulation eines Steuergeräts
DE102010052177A1 (de) Verfahren zum Prüfen eines Steuergeräts
DE102020215387A1 (de) Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102020207921A1 (de) Verfahren zum Einrichten eines Fahrzeugsimulationsmodells

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

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17P Request for examination filed

Effective date: 20040805

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20110615