DE10144050A1 - Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem - Google Patents

Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem

Info

Publication number
DE10144050A1
DE10144050A1 DE10144050A DE10144050A DE10144050A1 DE 10144050 A1 DE10144050 A1 DE 10144050A1 DE 10144050 A DE10144050 A DE 10144050A DE 10144050 A DE10144050 A DE 10144050A DE 10144050 A1 DE10144050 A1 DE 10144050A1
Authority
DE
Germany
Prior art keywords
control unit
software
software functions
experimental
functions
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
DE10144050A
Other languages
English (en)
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
Priority to DE10144050A priority Critical patent/DE10144050A1/de
Priority to US10/489,070 priority patent/US7275184B2/en
Priority to AU2002325798A priority patent/AU2002325798A1/en
Priority to EP02760105A priority patent/EP1428126A2/de
Priority to JP2003531322A priority patent/JP4236104B2/ja
Priority to PCT/DE2002/002725 priority patent/WO2003027850A2/de
Publication of DE10144050A1 publication Critical patent/DE10144050A1/de
Withdrawn 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

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öß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.

Description

    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 Softwarefunktionen 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 A1 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 Codeabdeckungsspeicher 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 A1 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 Softwarefunktionen 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 det 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 Softwarecodeabdeckung 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 Softwarequalitä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 Fig. 1 eine Seriensteuereinheit, also ein ECU- Target und ein Experimentaltarget mit Darstellung der jeweiligen Softwarearchitektur.
  • Fig. 2 zeigt in einem Flussdiagramm den Ablauf des Verfahrens zur Softwareverifikation.
  • In Fig. 3 ist noch einmal der Daten- und Kontrollfluss, bezogen auf das erfindungsgemäße Verfahren zur Softwareverifikation, dargestellt.
    • Beschreibung der Ausführungsbeispiele
  • Fig. 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 Visualisierungs- und/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 Softwarecodes, wie auch in den weiteren Fig. 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 vorteilhafter 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 Fig. 2 ist ausgehend von der Erstellung des Simulationsmodells in Block 200 die Verfahrensabfolge 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 Seriensteuereinheit.
  • 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 Softwarefunktionen 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. -fehlern sowie das Erkennen von Timingproblemen der Seriensteuereinheit möglich. Dies wird nun anhand des Daten- und Kontrollflusses in Fig. 3 noch einmal näher erläutert.
  • In Fig. 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 Visualisierungs- und 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 Visualisierungs- 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 Softwarefunktionen 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 Verifikationssystem 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 Verifikationssystem 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 (10)

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 Softwarefunktionen 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 werden.
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.
DE10144050A 2001-09-07 2001-09-07 Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem Withdrawn DE10144050A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE10144050A DE10144050A1 (de) 2001-09-07 2001-09-07 Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
US10/489,070 US7275184B2 (en) 2001-09-07 2002-07-24 Software verification method for control units and verification system
AU2002325798A AU2002325798A1 (en) 2001-09-07 2002-07-24 Software verification method for control units and verification system
EP02760105A EP1428126A2 (de) 2001-09-07 2002-07-24 Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem
JP2003531322A JP4236104B2 (ja) 2001-09-07 2002-07-24 制御ユニットのためのソフトウェア検証方法及び検証システム
PCT/DE2002/002725 WO2003027850A2 (de) 2001-09-07 2002-07-24 Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10144050A DE10144050A1 (de) 2001-09-07 2001-09-07 Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem

Publications (1)

Publication Number Publication Date
DE10144050A1 true DE10144050A1 (de) 2003-03-27

Family

ID=7698161

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10144050A Withdrawn DE10144050A1 (de) 2001-09-07 2001-09-07 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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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

Families Citing this family (23)

* 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
SE529676C2 (sv) * 2006-03-02 2007-10-23 Abb Ab En metod för att utvärdera en applikation, ett automationssystem och en styrenhet
SE0600449L (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
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
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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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

Also Published As

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

Similar Documents

Publication Publication Date Title
DE10144050A1 (de) Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
EP2770389B1 (de) Verfahren zur Durchführung einer Konfiguration eines Steuergeräte-Testsystems
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP2244141A1 (de) Verfahren und Vorrichtung zur Verifizierung eines Automatisierungssystems
DE102007010978A1 (de) Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
EP3709166B1 (de) Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten
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
DE102008043374A1 (de) Vorrichtung und Verfahren zur Generierung redundanter, aber unterschiedlicher Maschinencodes aus einem Quellcode zur Verifizierung für ein sicherheitskritisches System
EP3044667A1 (de) Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens
DE102009034242A1 (de) Verfahren und Vorrichtung zum Prüfen eines Steuergeräts eines Fahrzeugs
DE102007015140A1 (de) Diagnosevorrichtung und Diagnoseverfahren zum Ausführen einer Diagnose eines mechatronischen Systems
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
WO2020099524A1 (de) Verfahren und systeme zur bereitstellung von leistungsdaten eines steuergerätes im fahrbetrieb
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms
DE102022115636A1 (de) Verfahren zum Evaluieren eines Ergebnisses einer Simulation eines Steuergeräts
DE102020215387A1 (de) Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102010052177A1 (de) Verfahren zum Prüfen eines Steuergeräts
DE102020207921A1 (de) Verfahren zum Einrichten eines Fahrzeugsimulationsmodells
DE102019209472A1 (de) Verfahren und Vorrichtung zum Bewerten der Robustheit eines auf einem Simulationsmodell basierenden Testverfahrens
DE102021109133A1 (de) Verfahren und Vorrichtung zum Erstellen von Testfällen für ein Testsystem
EP4167041A1 (de) Verfahren und vorrichtung zur automatischen analyse eines diagnosesystems eines fahrzeugs

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R002 Refusal decision in examination/registration proceedings
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20130403