[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1046991B1 - Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls - Google Patents

Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls Download PDF

Info

Publication number
EP1046991B1
EP1046991B1 EP99107827A EP99107827A EP1046991B1 EP 1046991 B1 EP1046991 B1 EP 1046991B1 EP 99107827 A EP99107827 A EP 99107827A EP 99107827 A EP99107827 A EP 99107827A EP 1046991 B1 EP1046991 B1 EP 1046991B1
Authority
EP
European Patent Office
Prior art keywords
reference values
cooperate
ability
complied
software modules
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.)
Expired - Lifetime
Application number
EP99107827A
Other languages
English (en)
French (fr)
Other versions
EP1046991A1 (de
Inventor
Gerhard Dipl-Ing. Göser (FH)
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.)
Siemens AG
Continental Automotive France SAS
Original Assignee
Siemens AG
Siemens VDO Automotive SAS
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 Siemens AG, Siemens VDO Automotive SAS filed Critical Siemens AG
Priority to EP99107827A priority Critical patent/EP1046991B1/de
Priority to DE59903732T priority patent/DE59903732D1/de
Priority to US09/553,326 priority patent/US6751788B1/en
Publication of EP1046991A1 publication Critical patent/EP1046991A1/de
Application granted granted Critical
Publication of EP1046991B1 publication Critical patent/EP1046991B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs

Definitions

  • software modules Software and parts of software (hereinafter referred to as software modules are often called by different people written. It must be ensured that the actions of a software module to that of another software module do not contradict or even reverse it do. With open software, that means in the environment of a personal computer that becomes independence and Compatibility of the software modules with one another dynamic range monitoring software guaranteed.
  • the object of the invention is to provide such a method.
  • the advantage of the invention is that no additional effort (Direct access memory, read-only memory, runtime) in the Control unit itself is required.
  • the inventive method for formal review and for testing embedded software modules and the like embedded overall software provides that the properties of the individual software modules with regard to Differentiation from the other software modules, static and quasi-dynamic (that is: static worst case analysis of the dynamic behavior) are formally checked, and that this check before the dynamic operation of the device is carried out. This in turn has the consequence that advantageously no additional monitoring software in the active Operation is needed.
  • the formal review of the delimitation of the software modules affects at least (but not exclusively) the Check for prohibited write access to memory (e.g. on registers, random access memory areas, Pins, pointers etc.) and the check regarding the limitation of loop counters (i.e. that none Endless loops are present).
  • the functional test it can also be provided that that, based on the object code, it is checked whether program parts run directly from the random access memory area (ie can be changed dynamically); that the object code is used to check how long an interrupt is blocked; that the object code is used to check the maximum time required for a software module (task) to be processed; that the worst case timing of the entirety or a subset of the software modules is determined on the basis of the object code of an implementation language such as OSEK-OIL (in particular on the basis of the description of the task priorities, preemptions and so on) and the specification of the task activation frequency; and that the stack size is determined from the worst-case situation with regard to interrupts, preemptions etc. as well as their priority and frequency.
  • OSEK-OIL in particular on the basis of the description of the task priorities, preemptions and so on
  • FIG. 1 two within a control unit STG Functions using software tasks ST1 and ST2 (software modules) will be realized.
  • the two software tasks ST1 and ST2 run in one, not shown in the drawing Processor from within the two software tasks ST1 and ST2 to a base register BAR, to a random access memory RAM and ports POR access.
  • the ports are POR for example with a sensor SES and an actuator ACT under Interposition of adapter units AU1 and AU2 connected.
  • the sensor SES provides information to the processor that these are processed by means of the software tasks ST1 and ST2 accordingly controls the ACT actuator.
  • a first method step 1 what is to be tested Software module according to object code sequences (machine code sequences) which searches a write access to illegal would represent areas.
  • object code sequences machine code sequences
  • a second step 2 the loops and identifies their loop counters of the software modules to be tested. It is determined how these counters within the Loops are manipulated, and whether at the beginning of the loop this Meters have a static limit. This will be the maximum Number of loop passes determined.
  • the object code searched for object code sequences manipulate the interrupt enable / disable operations.
  • the interrupt disable times are in the form of the ones in between Object code cycles (machine code cycles) from the Object code determined.
  • the maximum Runtime of individual software modules e.g. OSEK tasks
  • object code cycles machine code cycles
  • a method step 5 the frequency of the interrupts, the Taskauf calls and the messages per defined Unit of time (for example per engine revolution in the case of a Motor control) and the priorities of the tasks and messages and the approved pre-emption available to the tool provided (for example by input).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Description

Software und Teile einer Software (im folgenden Software-Module genannt) werden heute häufig von verschiedenen Personen geschrieben. Dabei muß sichergestellt werden, daß die Aktionen eines Software-Modules zu denen eines anderen Software-Modules nicht im Widerspruch stehen oder sie gar rückgängig machen. Bei offener Software, das heißt in der Umgebung eines Personal-Computers, wird die Unabhängigkeit und Verträglichkeit der Software-Module untereinander von einer dynamischen Bereichsüberwachungssoftware garantiert.
Für in Geräte (mit zum Beispiel Mikrocontrollern, Mikroprozessoren oder Steuerungen) eingebettete Software wird heute diese Eigenschaft durch Regeln für die Zusammenarbeit einzelner Software-Module sichergestellt: Zuerst wird die Software in lesbarer Form als Source-Code mit der zugehörigen Dokumentation erstellt. Dann wird sie in die maschinenlesbare Form, dem Object-Code, compiliert. Firmeninterne Aufgabenteilung und Regeln (Design Rules) stellen die Verträglichkeit der einzelnen Software-Module untereinander sicher. In einem Integrationstest wird das Zusammenspiel der Software-Module in Funktion und Zeitverhalten überprüft.
Alle diese Arbeiten werden bei eingebetteter Software (Embedded Software) unter offener Zusammenarbeit aller Beteiligten, das heißt unter Vorlage der Source-Codes und deren Dokumentationen, durchgeführt.
Die Komplexität von eingebetteten Software-Modulen, die kooperative Funktionen zwischen zwei oder mehreren Geräten ausführen, ist so groß geworden, daß sie von einzelnen Firmen nicht mehr alleine beherrscht beziehungsweise erstellt werden können. Die Kooperation von Wettbewerbern bei der Erstellung der eingebetteten Software für ein oder mehrere Geräte ist notwendig geworden. Die Wettbewerbssituation zwischen den Firmen verbietet allerdings die Offenlegung des Source-Codes und zwingt zur Einbettung von bereits compiliertem Object-Code. Damit ist der Inhalt einer technischen Funktion dem Ersteller einer anderen Funktion nicht mehr im Detail bekannt. Er kann also darauf keine Rücksicht mehr nehmen.
Damit ein Software-Modul seine technische Funktionalität unabhängig von und verträglich mit einer anderen technischen Funktion erfüllen kann, müßte eine zusätzliche Bereichsüberwachungsfunktion installiert werden. Dies wäre aber relativ aufwendig und damit teuer.
Es existieren Software-Werkzeuge, die die Einhaltung formaler Regeln (Design Rules) im Source-Code oder im Object-Code überprüfen können. Es existieren auch Mechanismen zur Worstcase-Vorhersage des Zeitverhaltens unter Verwendung des Source-Codes beziehungsweise Object-Codes. Es existiert jedoch kein Verfahren, das die Unabhängigkeit und Verträglichkeit verschiedener mittels Software realisierter technischer Funktionen untereinander überprüft.
Aufgabe der Erfindung ist es, ein derartiges Verfahren bereitzustellen.
Die Aufgabe wird gelöst durch ein Verfahren gemäß dem unabhängigen Anspruch 1. Ausgestaltungen und Weiterbildungen des Erfindungsgedankens sind Gegenstand abhängiger Ansprüche.
Vorteil der Erfindung ist es, daß kein zusätzlicher Aufwand (Direktzugriffsspeicher, Nur-Lese-Speicher, Laufzeit) im Steuergerät selbst erforderlich ist.
Dies wird insbesondere durch die nachfolgend beschriebenen Maßnahmen erreicht, wobei nur die Aufteilung der technischen Funktionen auf die einzelnen Software-Module bekannt sein muß. Unter Aufteilung technischer Funktionen ist beispielsweise zu verstehen, welche Funktion welche Aktoren, Sensoren und so weiter über welche Ports bedient werden, welche Register (z.B. für Grundeinstellungen des Mikrocontrollers, des Mikroprozessors oder der Steuerung) von welcher Funktion bedient werden, wieviel Laufzeit für die jeweilige Funktionen zur Verfügung stehen soll, wie häufig Interrupts, Preemptionen und Taskaufrufe pro Zeiteinheit auftreten werden und welche Schnittstellen die Funktionen untereinander benutzen.
Das erfindungsgemäße Verfahren zur formalen Überprüfung und zum Test von einzubettenden Software-Modulen und entsprechender eingebetteter Gesamt-Software sieht vor, daß die Eigenschaften der einzelnen Software-Module im Hinblick auf die Abgrenzung zu den anderen Software-Modulen statisch und quasi-dynamisch (das heißt: statische Worst-Case-Betrachtung des dynamischen Verhaltens) formal überprüft werden, sowie daß diese Überprüfung bereits vor dem dynamischen Betrieb des Gerätes durchgeführt wird. Das wiederum hat zur Folge, daß vorteilhafterweise keine zusätzliche Überwachungssoftware im aktiven Betrieb benötigt wird.
Vorteilhaft ist auch, daß die Sicherstellung einer einwandfreien allgemeinen technischen Funktionalität bei Geräten mit eingebetteter Software vor allem in Anwendungen, bei denen Teile der Software nicht als Source-Code vorliegen.
Die formale Überprüfung der Abgrenzung der Software-Module betrifft dabei mindestens (aber nicht ausschließlich) die Überprüfung hinsichtlich verbotener Schreib-Zugriffe auf Speicher (beispielsweise auf Register, Direktzugriffsspeicher-Bereiche, Pins, Pointer etc.) und die Überprüfung hinsichtlich der Begrenzung von Schleifenzählern (d.h., daß keine Endlosschleifen vorhanden sind).
Desweiteren kann überprüft werden, ob verbotene Interrupt-Enable/Disable-Operationen durchgeführt werden.
Im Rahmen der Funktionsprüfung kann auch vorgesehen werden,
daß ausgehend von dem Objekt-Code überprüft wird, ob Programmteile direkt aus dem Direktzugriffsspeicher-Bereich ablaufen (also dynamisch änderbar sind);
daß anhand des Object-Codes überprüft wird, wie lange maximal ein Interrupt gesperrt wird;
daß anhand des Object-Codes überprüft wird, wieviel Zeit ein Software-Modul (Task) maximal zur Abarbeitung benötigt;
daß anhand des Object-Codes einer Implementierungsprache wie zum Beispiel OSEK-OIL (insbesondere anhand der Beschreibung der Taskprioritäten, Preemptionen und so weiter) sowie der Angabe der Taskaktivierungsfrequenz das Worstcase-Zeitverhalten der Gesamtheit oder einer Untermenge der Software-Module bestimmt wird; und
daß die Stackgröße aus der Worst-Case-Situation bezüglich Interrupts, Preemptionen etc. sowie deren Priorität und Frequenz ermittelt wird.
Die Erfindung wird nachfolgend anhand der in den Figuren der Zeichnung dargestellten Ausführungsbeispiele näher erläutert. Es zeigt:
Figur 1
die Umgebung für eine Anwendung eines erfindungsgemäßen Verfahrens und
Figur 2
das Ablaufdiagramm zu einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens.
Gemäß Figur 1 sollen innerhalb eines Steuergerätes STG zwei Funktionen mittels Software-Tasks ST1 und ST2 (Software-Module) realisiert werden. Die beiden Software-Tasks ST1 und ST2 laufen dabei in einem, in der Zeichnung nicht dargestellten Prozessor ab, der im Rahmen der beiden Software-Tasks ST1 und ST2 auf ein Basis-Register BAR, auf einen Direktzugriffsspeicher RAM und auf Ports POR zugreift. Die Ports POR sind beispielsweise mit einem Sensor SES und einen Aktor ACT unter Zwischenschaltung von Anpaßeinheiten AU1 und AU2 verbunden. Der Sensor SES gibt dabei Informationen an den Prozessor, der diese mittels der Software-Tasks ST1 und ST2 bearbeitet und dementsprechend den Aktor ACT steuert. Pro Zyklus (= beispielsweise der minimale zeitliche Abstand jeweils bestimmter externer Ereignisse wie etwa der obere Totpunkt bei einem Verbrennungsmotor) ist dabei die Laufzeit gemäß einer Laufzeitverteilung LZV auf bestimmte Funktionen verteilt, wobei allgemein gemäß einer bestimmten Resourcen-Verteilung MZL auf Basis-Register BAR, auf einen Direkt-Zugriffs-Speicher RAM und auf die Ports POR zugegriffen wird.
Bekannt ist dabei insbesondere die Aufteilung der technischen Funktionen auf die einzelnen Software-Tasks ST1 und ST2. Unter Aufteilung technischer Funktionen ist hierbei zu verstehen, welche Funktion der Aktor ACT und welche der Sensor SEN über welchen Port POR bedient. Weiterhin ist bekannt, welche Register (beispielsweise für Grundeinstellungen des Prozessors und damit des Steuergerätes STG) von welcher Funktion (Software-Tasks ST1 und ST2) bedient werden dürfen und wieviel Laufzeit (Laufzeitverteilung LZV) für die jeweilige Funktionen (Software-Tasks ST1 und ST2) zur Verfügung stehen soll. Schließlich ist bekannt, wie häufig Interrupts, Preemptionen und Taskaufrufe pro Zeiteinheit auftreten werden und welche Schnittstellen die Funktionen untereinander benutzen (zum Beispiel "Send-Message-Befehle" oder "Receive-Message-Befehle" bei der Maschinensprache OSEK OIL).
Gemäß Figur 2 stehen die einzelnen Funktionen zunächst als Software-Tasks ST1 und ST2 (Software-Module) zur Verfügung. Bevor nun die Funktionen in das Steuergerät STG integriert werden können, muß deren gegenseitige Verträglichkeit und Unabhängigkeit nachgewiesen werden. Dazu werden nun alle gegenseitigen Beeinflußungen bevorzugt wie folgt identifiziert:
In einem ersten Verfahrensschritt 1 wird das zu testende Software-Modul nach Object-Code-Sequenzen (Maschinen-Code-Sequenzen) durchsucht, die einen Schreib-Zugriff auf unzulässige Bereiche darstellen würden.
In einem zweiten Verfahrensschritt 2 werden die Schleifen und ihre Schleifenzähler der zu testenden Software-Module identifiziert. Es wird ermittelt, wie diese Zähler innerhalb der Schleifen manipuliert werden, und ob zum Schleifenanfang diese Zähler eine statische Grenze aufweisen. Damit wird die maximale Anzahl der Schleifendurchläufe ermittelt.
In einem weiteren Verfahrensschritt 3 wird der Object-Code nach Object-Code-Sequenzen (Maschinen-Code-Sequenzen) durchsucht, die Interrupt-Enable/Disable-Operationen manipulieren. Die Interrupt-Disable-Zeiten werden in Form der dazwischenliegenden Object-Code-Zyklen (Maschinen-Code-Zyklen) aus dem Object-Code ermittelt.
Außerdem wird in einem weiteren Verfahrensschritt 4 die maximale Laufzeit einzelner Software-Module (zum Beispiel OSEK-Tasks) in Form von Object-Code-Zyklen (Maschinen-Code-Zyklen)aus dem Object-Code ermittelt.
In einem Verfahrensschritt 5 wird die Häufigkeit der Interrupts, der Taskaufrufe und der Messages per definierter Zeiteinheit (zum Beispiel per Motorumdrehung im Falle einer Motorsteuerung) sowie die Prioritäten der Tasks und der Messages und der zugelassenen Preemptionen dem Werkzeug zur Verfügung gestellt (zum Beispiel per Eingabe). Damit lassen sich beispielsweise Verfahren zur Ermittlung der Software Runtime und Message Latency Time anwenden.
Parallel wird aus diesen Informationen die maximale Interrupt- und Preemptions-Tiefe ermittelt, um damit die Größe des benötigten Stacks zu ermitteln (Verfahrensschritt 6).
Nach Durchlauf dieses Verfahrens steht fest, ob in den nicht offengelegten Teilen der Software-Module eine Beeinflußung anderer Software-Module stattfindet und ob ausreichend Resourcen (RAM, ROM, Laufzeit) dem jeweiligen Software-Modul zur Verfügung stehen.
Damit ist automatisch sichergestellt, daß die mit dieser Software realisierten technischen Funktionen sich ausschließlich an den offengelegten Schnittstellen gegenseitig beeinflussen, daß sie also untereinander verträglich sind. Zusätzlicher Überwachungsaufwand wird nicht benötigt. Die Überprüfung erfolgt dabei bevorzugt durch eine weitere Prozessoranordnung unter ebenfalls Software-Steuerung.

Claims (13)

  1. Verfahren zum Testen der Kooperationsfähigkeit von jeweils bestimmte Funktionen in einem Gerät ausführenden Software-Modulen anhand von in den ausführenden Software-Modulen enthaltenen Maschinen-Code-Sequenzen mit den Verfahrensschritten:
    a) Durchsuchen der Software-Module nach Maschinen-Code-Sequenzen, die einen Schreib-Zugriff auf unerlaubte Bereiche beinhalten,
    b) Ermitteln jeweils der maximalen Anzahl von Schleifendurchläufen je Schleife und Feststellen, ob die maximale Anzahl von Schleifendurchläufen begrenzt ist, und
    wobei bei Einhaltung die Kooperationsfähigkeit gegeben und bei Nichteinhaltung der Referenzwerte die Kooperationsfähigkeit nicht gegeben ist.
  2. Verfahren nach Anspruch 1 mit dem zusätzlichen Verfahrensschritt:
    c) Durchsuchen der Software-Module nach Sequenzen, bei denen unerlaubte Interrupt-Enable/Disable-Operationen durchgeführt werden, wobei bei Einhaltung der Referenzwerte die Kooperationsfähigkeit gegeben und bei Nichteinhaltung der Referenzwerte die Kooperationsfähigkeit nicht gegeben ist.
  3. Verfahren nach einem der vorherigen Ansprüche mit dem zusätzlichen Verfahrensschritt:
    d) Ermitteln der Interrupt-Disable-Zeiten und Vergleich der Interrupt-Disable-Zeiten mit jeweils entsprechenden Referenzwerten, wobei bei Einhaltung der Referenzwerte die Kooperationsfähigkeit gegeben und bei Nichteinhaltung der Referenzwerte die Kooperationsfähigkeit nicht gegeben ist.
  4. Verfahren nach einem der vorherigen Ansprüche mit dem zusätzlichen Verfahrensschritt:
    e) Ermitteln der maximalen Laufzeit der einzelnen ausführenden Software-Module und Vergleich der maximalen Laufzeit der einzelnen ausführenden Software-Module mit jeweils entsprechenden Referenzwerten, wobei bei Einhaltung der Referenzwerte die Kooperationsfähigkeit gegeben und bei Nichteinhaltung der Referenzwerte die Kooperationsfähigkeit nicht gegeben ist.
  5. Verfahren nach einem der vorherigen Ansprüche mit dem zusätzlichen Verfahrensschritt:
    f) Ermitteln der Gesamtlaufzeit und der Nachrichten-Latenz-Zeit und Vergleich der Gesamtlaufzeit und der Nachrichten-Latenz-Zeit mit jeweils entsprechenden Referenzwerten, wobei bei Einhaltung der Referenzwerte die Kooperationsfähigkeit gegeben und bei Nichteinhaltung der Referenzwerte die Kooperationsfähigkeit nicht gegeben ist.
  6. Verfahren nach einem der vorherigen Ansprüche mit dem zusätzlichen Verfahrensschritt:
    g) Ermitteln der maximalen Interrupt- und Preemptionstiefe und Vergleich der maximalen Interrupt- und Preemptionstiefe mit jeweils entsprechenden Referenzwerten, wobei bei Einhaltung der Referenzwerte die Kooperationsfähigkeit gegeben und bei Nichteinhaltung der Referenzwerte die Kooperationsfähigkeit nicht gegeben ist.
  7. Verfahren nach Anspruch 2, bei dem die Anzahl der Schleifendurchläufe ermittelt wird durch:
    Identifizieren der Schleifen und ihrer zugehörigen Schleifenzähler, Feststellen, auf welche Weise die Zähler manipuliert werden und
    Feststellen, ob am Schleifenanfang die Zähler jeweils eine statische Grenze aufweisen.
  8. Verfahren nach Anspruch 3, bei dem die Interrupt-Disable-Zeiten ermittelt werden durch:
    Durchsuchen der Software-Module nach Interrupt-Enable/Disable-Code manipulierenden Maschinen-Code-Sequenzen und
    Bestimmen der zwischen jeweils diesen Maschinen-Code-Sequenzen liegenden Zeiten.
  9. Verfahren nach Anspruch 4, bei dem die maximale Laufzeit der einzelnen ausführenden Software-Module ermittelt wird anhand der Anzahl von Maschinen-Zyklen.
  10. Verfahren nach Anspruch 5, bei dem Gesamtlaufzeit und Nachrichten-Latenz-Zeit ermittelt werden durch:
    Bestimmen der Häufigkeit der Interrupts, der Taskaufrufe und der Nachrichten per definierter Zeiteinheit und
    Feststellen der Prioritäten der Tasks, der Messages und der zugelassenen Preemptionen.
  11. Verfahren nach Anspruch 6, bei dem die maximale Interrupt- und Preemptionstiefe ermittelt wird durch:
    Bestimmen der Häufigkeit der Interrupts, der Taskaufrufe und der Nachrichten per definierter Zeiteinheit und
    Feststellen der Prioritäten der Tasks, der Messages und der zugelassenen Preemptionen.
  12. Verfahren nach Anspruch 11, bei dem die Größe eines benötigten Stacks aus der maximalen Interrupt- und Preemptionstiefe ermittelt wird.
  13. Verfahren nach einem der vorherigen Ansprüche, bei dem die Software-Module dahingehend untersucht werden, ob Maschinen-Code-Sequenzen direkt aus einem Direkt-Zugriffs-Speicher heraus ablaufen.
EP99107827A 1999-04-20 1999-04-20 Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls Expired - Lifetime EP1046991B1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP99107827A EP1046991B1 (de) 1999-04-20 1999-04-20 Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls
DE59903732T DE59903732D1 (de) 1999-04-20 1999-04-20 Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls
US09/553,326 US6751788B1 (en) 1999-04-20 2000-04-20 Method of testing computer software

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP99107827A EP1046991B1 (de) 1999-04-20 1999-04-20 Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls

Publications (2)

Publication Number Publication Date
EP1046991A1 EP1046991A1 (de) 2000-10-25
EP1046991B1 true EP1046991B1 (de) 2002-12-11

Family

ID=8238004

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99107827A Expired - Lifetime EP1046991B1 (de) 1999-04-20 1999-04-20 Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls

Country Status (3)

Country Link
US (1) US6751788B1 (de)
EP (1) EP1046991B1 (de)
DE (1) DE59903732D1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003015906A (ja) * 2001-06-28 2003-01-17 Mitsubishi Electric Corp リモートデバッグ方法および装置
CN1679034A (zh) * 2002-04-08 2005-10-05 托普科德公司 用于对软件开发服务征求建议的系统以及方法
CN1813226A (zh) * 2003-06-24 2006-08-02 罗伯特.博世有限公司 电子控制单元和用于规定电子控制单元的软件结构的方法
GB0412104D0 (en) * 2004-05-29 2004-06-30 Ibm Apparatus method and program for recording diagnostic trace information
US8260602B1 (en) * 2006-11-02 2012-09-04 The Math Works, Inc. Timer analysis and identification
US8719801B2 (en) * 2008-06-25 2014-05-06 Microsoft Corporation Timing analysis of concurrent programs
US8589730B2 (en) * 2010-08-31 2013-11-19 Apple Inc. Handling errors during device bootup from a non-volatile memory
US8706955B2 (en) 2011-07-01 2014-04-22 Apple Inc. Booting a memory device from a host
US20130047261A1 (en) * 2011-08-19 2013-02-21 Graeme John Proudler Data Access Control
US9063884B2 (en) * 2012-10-23 2015-06-23 Hewlett-Packard Development Company, L.P. Analysis of health indicators of a system
CN116431107B (zh) * 2023-03-14 2023-12-29 芜湖市桀蒲网络科技有限公司 一种基于大数据的软件模块划分方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6247144B1 (en) * 1991-01-31 2001-06-12 Compaq Computer Corporation Method and apparatus for comparing real time operation of object code compatible processors
US5450575A (en) * 1991-03-07 1995-09-12 Digital Equipment Corporation Use of stack depth to identify machine code mistakes
US5872909A (en) * 1995-01-24 1999-02-16 Wind River Systems, Inc. Logic analyzer for software
US5761408A (en) * 1996-01-16 1998-06-02 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution
US6223144B1 (en) * 1998-03-24 2001-04-24 Advanced Technology Materials, Inc. Method and apparatus for evaluating software programs for semiconductor circuits
US6477683B1 (en) * 1999-02-05 2002-11-05 Tensilica, Inc. Automated processor generation system for designing a configurable processor and method for the same
US6484188B1 (en) * 1999-12-30 2002-11-19 Intel Corporation Optimization of garbage collection code in the context of raw native interface function calls in the java programming language

Also Published As

Publication number Publication date
EP1046991A1 (de) 2000-10-25
US6751788B1 (en) 2004-06-15
DE59903732D1 (de) 2003-01-23

Similar Documents

Publication Publication Date Title
EP1046991B1 (de) Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
DE102018003142A1 (de) Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
DE10215405A1 (de) Verfahren und Vorrichtung zur Funktionsprüfung eines Analog-Digital-Wandlers sowie Analog-Digital-Wandler
EP0104635A2 (de) Verfahren und Anordnung zum Prüfen eines digitalen Rechners
DE69815006T2 (de) Datenverarbeitungseinheit mit Fehlerbeseitungsmöglichkeiten
DE102006052757B4 (de) Verfahren zum Betrieb eines Automatisierungsgerätes mit einer Verarbeitungseinheit mit mehreren Verarbeitungskernen
EP3080668A1 (de) Verfahren zur beeinflussung eines steuerprogramms eines steuergeräts
DE102005037230A1 (de) Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersystems
EP2924522A1 (de) Verfahren zur Beeinflussung eines Steuerprogramms
EP2482148B1 (de) Verfahren für die Projektierung und/oder Programmierung einer multifunktionalen Komponente einer industriellen Automatisierungsanordnung
DE60309157T2 (de) Speichersystem mit Fehlererkennungsvorrichtung
EP2990941B1 (de) Computerimplementiertes verfahren zur erzeugung eines steuergeräteprogrammcodes und diesbezügliche meldungsverwaltungsumgebung
DE102009001048A1 (de) Vorrichtung und Verfahren zur Prüfung der Arbeitsweise eines Rechnersystems
EP2338111B1 (de) Verfahren und vorrichtung zum testen eines rechnerkerns in einer mindestens zwei rechnerkerne aufweisenden recheneinheit
DE60213786T2 (de) System und verfahren zur automatischen erfassung von aussagen in einer java-kompatibilitätsprüfumgebung
EP2329374A1 (de) Testmodul und verfahren zum testen einer o/r-abbildungs-middleware
DE102020130717A1 (de) Softwareprodukt zum Betreiben einer externen Systemgruppe in unterschiedlichen Konfigurationen
EP2634700A1 (de) Verfahren und Entwicklungsumgebung zur Überwachung eines ablaufenden Programms
DE10138533A1 (de) Bereitstellung von Projekt- und/oder Projektierungsdaten eines Automatisierungsprojekts in einem durch eine standardisierte Meta-Sprache, insbesondere XML, definiertem Format
EP2386952A1 (de) Verfahren und Entwicklungsumgebung zur Überwachung eines ablaufenden Programms
EP2267562A1 (de) Verfahren und Gerät zur Überprüfung von zwischen Komponenten auszutauschenden Daten in einem XML-Format
DE10125385B4 (de) Vorrichtung, Anordnung und Verfahren zum Parametrieren, Projektieren und Inbetriebnehmen von Steuerungssystemen sowie zur zeitlichen Steuerung eines Systems
DE102005020899A1 (de) Verfahren und Vorrichtung zur Messung der Testabdeckung bei Multithreading-Programmen
DE60211922T2 (de) Architektur einer elektronischen Vorrichtung zum Ermitteln der Betriebsphase einer Brennkraftmaschine

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: A1

Designated state(s): DE FR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17P Request for examination filed

Effective date: 20001120

AKX Designation fees paid

Free format text: DE FR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS VDO AUTOMOTIVE S.A.S.

Owner name: SIEMENS AKTIENGESELLSCHAFT

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

RTI1 Title (correction)

Free format text: METHOD FOR TESTING THE AUTONOMY AND COMPATIBILTY OF A SOFTWARE MODULE

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

17Q First examination report despatched

Effective date: 20020528

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR

REF Corresponds to:

Ref document number: 59903732

Country of ref document: DE

Date of ref document: 20030123

ET Fr: translation filed
PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20030912

REG Reference to a national code

Ref country code: FR

Ref legal event code: CD

REG Reference to a national code

Ref country code: FR

Ref legal event code: TQ

Owner name: CONTINENTAL AUTOMOTIVE GMBH, DE

Effective date: 20111104

Ref country code: FR

Ref legal event code: TQ

Owner name: SIEMENS VDO AUTOMOTIVE S.A.S.

Effective date: 20111104

Ref country code: FR

Ref legal event code: TQ

Owner name: CONTINENTAL AUTOMOTIVE FRANCE, FR

Effective date: 20111104

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20130430

Year of fee payment: 15

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 59903732

Country of ref document: DE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 59903732

Country of ref document: DE

Effective date: 20141101

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20141101

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 17

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20150421

Year of fee payment: 17

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20161230

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160502