DE102020213809A1 - Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts - Google Patents

Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts Download PDF

Info

Publication number
DE102020213809A1
DE102020213809A1 DE102020213809.5A DE102020213809A DE102020213809A1 DE 102020213809 A1 DE102020213809 A1 DE 102020213809A1 DE 102020213809 A DE102020213809 A DE 102020213809A DE 102020213809 A1 DE102020213809 A1 DE 102020213809A1
Authority
DE
Germany
Prior art keywords
test
software
computer
control unit
binary file
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.)
Pending
Application number
DE102020213809.5A
Other languages
English (en)
Inventor
Antoni Lacasta I Sulla
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 DE102020213809.5A priority Critical patent/DE102020213809A1/de
Priority to US17/510,259 priority patent/US11899561B2/en
Priority to CN202111293266.6A priority patent/CN114443465A/zh
Publication of DE102020213809A1 publication Critical patent/DE102020213809A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2273Test methods
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3676Test management for coverage analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Steuergeräts (104) beim Testen einer Software (102) des Steuergeräts (104), wobei das Steuergerät (104) einen Prozessor (112) zum Ausführen der Software (102) und einen Speicher (106) zum Speichern der Software (102) umfasst. Das Verfahren umfasst folgende Schritte: Empfangen (510) von durch einen Testcomputer (116) generierten Testanfragen (128) in dem Steuergerät (104); Ausführen (520) eines Testprogramms (110) zum Testen der Software (102) basierend auf den Testanfragen (128) durch Ausführen einer in dem Speicher (106) gespeicherten ersten Binärdatei durch den Prozessor (112), wobei die erste Binärdatei eine Testversion der Software (102) codiert, die mindestens ein zum Ausführen des Testprogramms (110) erforderliches Testmodul umfasst, wobei Testergebnisse (130) generiert werden; Senden (530) der Testergebnisse (130) von dem Steuergerät (104) an den Testcomputer (116); und Empfangen (540) einer durch den Prozessor (112) ausführbaren zweiten Binärdatei (132) in dem Steuergerät (104) und Speichern (550) der zweiten Binärdatei (132) in dem Speicher (106), wenn der Testcomputer (116) anhand der Testergebnisse (130) bestimmt hat, dass die Software (102) betriebstauglich ist, wobei die zweite Binärdatei (132) aus der ersten Binärdatei durch den Testcomputer (116) erzeugt wurde und eine Endversion der Software (102) codiert, die das Ausführen des mindestens einen Testmoduls (108) verhindert.

Description

  • Gebiet der Erfindung
  • Die Erfindung betrifft ein computerimplementiertes Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und ein computerimplementiertes Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts. Weiter betrifft die Erfindung ein Steuergerät, einen Testcomputer, ein Testsystem, ein Computerprogramm sowie ein computerlesbares Medium zum Ausführen des entsprechenden Verfahrens bzw. der entsprechenden Verfahren. Das Steuergerät kann beispielsweise konfiguriert sein, um Funktionen in einem Kraftfahrzeug zu kontrollieren.
  • Stand der Technik
  • Um einen möglichst fehlerfreien Betrieb eines Steuergeräts, etwa eines Steuergeräts zur Steuerung von Komponenten eines Kraftfahrzeugs, zu gewährleisten, kann eine auf dem Steuergerät auszuführende Software, die beispielsweise ein Betriebssystem und verschiedene Anwendungen umfassen kann, verschiedenen Softwaretests unterzogen werden. Beispielsweise kann in solchen Softwaretests geprüft werden, ob einzelne Komponenten der Software korrekt implementiert wurden, ob voneinander abhängige Komponenten der Software korrekt zusammenarbeiten oder ob die Software die an sie gestellten Anforderungen erfüllt. Die Software kann hierzu beispielsweise in einen Testmodus versetzt werden, in dem Testdaten zum Nachweis bestimmter Softwarefehler von einem Tester in die Software injiziert werden können. Aus Sicherheitsgründen sollte ein solches Injizieren von Daten im Normalbetrieb des Steuergeräts jedoch nach Möglichkeit verhindert werden.
  • Offenbarung der Erfindung
  • Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz ein Verfahren zum Betreiben eines Steuergeräts, ein Verfahren zum Betreiben eines Testcomputers, ein Steuergerät, ein Testcomputer, ein Testsystem, ein Computerprogramm und ein computerlesbares Medium gemäß den unabhängigen Ansprüchen vorgestellt. Vorteilhafte Weiterbildungen und Verbesserungen des hier vorgestellten Ansatzes ergeben sich aus der Beschreibung und sind in den abhängigen Ansprüchen beschrieben.
  • Vorteile der Erfindung
  • Ausführungsformen der vorliegenden Erfindung ermöglichen es in vorteilhafter Weise, eine Software eines Steuergeräts mittels eines oder mehrerer Softwaremodule der Software zu testen und dieses Softwaremodul bzw. diese Softwaremodule nach dem Testen dauerhaft zu deaktivieren, ohne dass hierzu ein der Software zugrunde liegender Quellcode geändert und erneut kompiliert zu werden braucht.
  • Ein erster Aspekt der Erfindung betrifft ein computerimplementiertes Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts. Dabei umfasst das Steuergerät einen Prozessor zum Ausführen der Software und einen Speicher zum Speichern der Software. Das Verfahren umfasst zumindest die folgenden Schritte, die vorzugsweise in der angegebenen Reihenfolge ausgeführt werden können: Empfangen von durch einen Testcomputer generierten Testanfragen in dem Steuergerät; Ausführen eines Testprogramms zum Testen der Software basierend auf den Testanfragen durch Ausführen einer in dem Speicher gespeicherten ersten Binärdatei durch den Prozessor, wobei die erste Binärdatei eine Testversion der Software codiert, die mindestens ein zum Ausführen des Testprogramms erforderliches Testmodul umfasst, wobei Testergebnisse generiert werden; Senden der Testergebnisse von dem Steuergerät an den Testcomputer; Empfangen einer durch den Prozessor ausführbaren zweiten Binärdatei in dem Steuergerät und Speichern der zweiten Binärdatei in dem Speicher, wenn der Testcomputer anhand der Testergebnisse bestimmt hat, dass die Software betriebstauglich ist, wobei die zweite Binärdatei aus der ersten Binärdatei durch den Testcomputer erzeugt wurde und eine Endversion der Software codiert, die das Ausführen des mindestens einen Testmoduls verhindert.
  • Ein zweiter Aspekt der Erfindung betrifft ein computerimplementiertes Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts. Dabei umfasst das Steuergerät einen Prozessor zum Ausführen der Software und einen Speicher zum Speichern der Software. Das Verfahren umfasst zumindest die folgenden Schritte, die vorzugsweise in der angegebenen Reihenfolge ausgeführt werden können: Generieren von Testanfragen durch den Testcomputer; Senden der Testanfragen von dem Testcomputer an das Steuergerät, wobei die Testanfragen den Prozessor veranlassen, ein Testprogramm zum Testen der Software durch Ausführen einer in dem Speicher gespeicherten ersten Binärdatei auszuführen, wobei die erste Binärdatei eine Testversion der Software codiert, die mindestens ein zum Ausführen des Testprogramms erforderliches Testmodul umfasst, wobei Testergebnisse generiert werden; Empfangen der durch das Steuergerät generierten Testergebnisse in dem Testcomputer; Bestimmen anhand der Testergebnisse durch den Testcomputer, ob die Software betriebstauglich ist; Erzeugen einer zweiten Binärdatei aus der ersten Binärdatei durch den Testcomputer, wenn bestimmt wurde, dass die Software betriebstauglich ist, wobei die zweite Binärdatei eine Endversion der Software codiert, die das Ausführen des mindestens einen Testmoduls verhindert; und Senden der zweiten Binärdatei von dem Testcomputer an das Steuergerät.
  • Dies hat den technischen Effekt, dass ein erneutes Ausführen des Testprogramms verhindert werden kann, ohne dass hierzu ein Quellcode der Software geändert zu werden braucht. Anders ausgedrückt kann dadurch vermieden werden, dass der Quellcode ein weiteres Mal kompiliert werden muss, nachdem die Software erfolgreich getestet wurde. Dadurch, dass diejenige (kompilierte) Version der Software getestet wird, die später im Normalbetrieb des Steuergeräts tatsächlich ausgeführt wird, kann die Wahrscheinlichkeit von Fehlfunktionen des Steuergeräts im Normalbetrieb deutlich reduziert werden.
  • Das Verfahren zum Betreiben des Steuergeräts kann beispielsweise automatisch durch das Steuergerät ausgeführt werden. Ebenso kann beispielsweise das Verfahren zum Betreiben des Testcomputers automatisch durch den Testcomputer ausgeführt werden.
  • Das Steuergerät bzw. der Testcomputer kann Hardware- und/oder Softwaremodule umfassen.
  • Das Steuergerät kann beispielsweise ein Steuergerät eines Kraftfahrzeugs wie etwa eines Pkw, Lkw, Busses oder eines Motorrads sein.
  • Zusätzlich zum Prozessor und zum Speicher kann das Steuergerät Mittel zur Datenkommunikation mit dem Testcomputer oder sonstigen Peripheriegeräten umfassen.
  • Der Speicher des Steuergeräts kann beispielsweise ein nicht flüchtiges Speicherelement, etwa einen ROM, EPROM oder Flash-Speicher, und/oder ein flüchtiges Speicherelement, etwa einen RAM, umfassen. Die zu testende Software des Steuergeräts kann in dem nicht flüchtigen Speicherelement abgespeichert sein.
  • Es ist möglich, dass das Steuergerät einen Mikrocontroller umfasst, wobei der Prozessor, der Speicher und/oder die Kommunikationsschnittstelle Komponenten des Mikrocontrollers sein können.
  • Beispielsweise kann das Steuergerät, etwa dessen Mikrocontroller, eine JTAG-Schnittstelle (JTAG = Joint Test Action Group) zur Datenkommunikation mit dem Testcomputer umfassen. Eine solche JTAG-Schnittstelle ermöglicht das Testen und Debuggen integrierter Schaltungen. Beispielsweise ermöglicht es die JTAG-Schnittstelle, auf einen internen Speicher des Mikrocontrollers zuzugreifen, Rechnerkerne zu stoppen, Haltepunkte zu setzen o. Ä. Die Datenkommunikation zwischen dem Steuergerät und dem Testcomputer kann beispielsweise über einen Debugger mit einer JTAG-Schnittstelle zur Datenkommunikation mit der JTAG-Schnittstelle des Steuergeräts und einer weiteren Schnittstelle zur Datenkommunikation mit dem Testcomputer, etwa USB, Ethernet oder UART, erfolgen. Auf dem Testcomputer kann eine geeignete Debuggersoftware zum Testen der Software des Steuergeräts laufen. Die zweite Binärdatei kann beispielsweise über den Debugger oder ein Programmiergerät auf das Steuergerät übertragen werden.
  • Alternativ oder zusätzlich zur JTAG-Schnittstelle kann das Steuergerät eine Diagnoseschnittstelle zur Datenkommunikation mit einem externen Diagnosegerät umfassen, etwa über CAN-Bus, FlexRay und/oder Ethernet. Eine solche Diagnoseschnittstelle ermöglicht es beispielsweise, einen Fehlerspeicher des Steuergeräts auszulesen, Softwareaktualisierungen durchzuführen oder Konfigurationsparameter des Steuergeräts zu ändern. Ebenso wie die JTAG-Schnittstelle kann die Diagnoseschnittstelle als Kommunikationsschnittstelle zur Datenkommunikation mit dem Testcomputer fungieren.
  • Unter einem Testcomputer kann im Allgemeinen ein externer Computer verstanden werden, der zu Testzwecken temporär mit dem Steuergerät verbunden werden kann, etwa ein PC, Laptop oder Tablet, und auf dem eine geeignete Testsoftware, etwa zum Generieren der Testanfragen, Auswerten der Testergebnisse und Erzeugen und Senden der zweiten Binärdatei, ausgeführt werden kann, vorangehend auch Debuggersoftware genannt. Bei dem Testcomputer kann es sich jedoch auch um ein speziell programmiertes Testgerät zum automatisierten Testen der Software des Steuergeräts handeln.
  • Die erste Binärdatei kann beispielsweise durch Kompilieren und Linken auf einem Computer, etwa dem Testcomputer, erzeugt worden sein und beispielsweise im HEX-Format gespeichert sein. Die erste Binärdatei kann zum einen Funktionen, die durch das Steuergerät im Normalbetrieb ausgeführt werden sollen, und zum anderen eine Testfunktion, die das Testen dieser Funktionen ermöglicht, implementieren. Die Testfunktion kann in Form eines oder mehrerer Testmodule der Software implementiert sein.
  • Beispielsweise kann die erste Binärdatei unter Laborbedingungen und/oder in einer Testumgebung in das Steuergerät programmiert werden, um die Software des Steuergeräts zu testen. Beim Erzeugen der zweiten Binärdatei aus der ersten Binärdatei durch den Testcomputer kann das Testmodul bzw. können die Testmodule durch spezielle Inhalte ersetzt werden, die einen Abbruch der Operation beim Ausführen dieser Inhalte erzwingen, während die übrigen Funktionen der Software erhalten bleiben. Die zweite Binärdatei kann dann zur Fertigung des Steuergeräts verwendet werden.
  • Beispielsweise kann der Testcomputer konfiguriert sein, um Testanfragen zum Durchführen verschiedener Arten von Tests mit der Software des Steuergeräts zu generieren, insbesondere etwa eines Integrationstests.
  • Die zu testende Software des Steuergeräts kann beispielsweise ein Betriebssystem und/oder verschiedene Anwendungsprogramme umfassen.
  • Beispielsweise kann es sich bei der Software um eine Firmware des Steuergeräts handeln.
  • Unter einem Testmodul kann im Allgemeinen ein in die Software des Steuergeräts integriertes Softwaremodul verstanden werden, das zum Ausführen des Testprogramms erforderlich ist. Das Überschreiben des Testmoduls in der ersten Binärdatei bewirkt also, dass das Testprogramm nicht mehr ausführbar ist. Insbesondere kann das Testmodul ausschließlich zum Ausführen des Testprogramms konfiguriert sein. Dadurch kann erreicht werden, dass die für die Betriebstauglichkeit relevante Funktionalität der Software beim Überschreiben des Testmoduls nicht oder allenfalls in nicht signifikanter Weise beeinträchtigt wird.
  • Das Testmodul kann beispielsweise als Schnittstelle zwischen einer Umgebung des Steuergeräts und internen Schnittstellen von Komponenten der Software des Steuergeräts fungieren. Beispielsweise kann das Testmodul konfiguriert sein, um die Software zwischen einem Normalmodus und einem Testmodus umzuschalten, wobei im Testmodus ein Injizieren von (Test-)Daten in die zu testende Komponente der Software ermöglicht wird und im Normalmodus ein solches Injizieren verhindert wird. Anders ausgedrückt kann das Testmodul als Datenschalter zum Steuern eines Datenflusses zwischen der Kommunikationsschnittstelle des Steuergeräts und verschiedenen Schichten der Software des Steuergeräts fungieren. Ein solcher Datenschalter kann englisch auch als switch for data and control oder kurz SDC bezeichnet werden. Die Software des Steuergeräts kann auch mehrere solcher Datenschalter als Testmodule umfassen. Dabei kann jeder der Datenschalter beim Ausführen des Löschbefehls aus dem Speicher des Steuergeräts gelöscht werden.
  • Um die Software des Steuergeräts unter realitätsnahen Bedingungen testen zu können, kann das Steuergerät beispielsweise in eine geeignete Testumgebung eingebunden sein. Eine solche Testumgebung ermöglicht es beispielsweise, verschiedene Kombinationen von Eingangssignalen und Nachrichten für das Steuergerät bereitzustellen und entsprechende Ausgangsdaten des Steuergeräts aufzuzeichnen. Die Testumgebung kann beispielsweise konfiguriert sein, um das Verhalten von Fahrzeugkomponenten, die im Normalbetrieb mit dem Steuergerät verbunden sind, zu emulieren.
  • Um zu bestimmen, ob die Software betriebstauglich, d. h. für einen Normalbetrieb unter realen Bedingungen tauglich ist, können die Testergebnisse beispielsweise mit entsprechenden Soll-Testergebnissen verglichen werden, die etwa in einer Lookup-Tabelle hinterlegt sein können. Dabei kann je nach Vergleichsergebnis bestimmt werden, ob ein Testergebnis einen die Betriebstauglichkeit der Software beeinträchtigenden Fehler darstellt oder nicht.
  • Ein dritter Aspekt der Erfindung betrifft ein Steuergerät, das einen Prozessor zum Ausführen einer Software und einen Speicher, in dem die Software gespeichert ist, umfasst. Das Steuergerät ist konfiguriert, um das Verfahren gemäß einer Ausführungsform des ersten Aspekts der Erfindung auszuführen. Merkmale des Verfahrens gemäß einer Ausführungsform des ersten Aspekts der Erfindung können auch Merkmale des Steuergeräts sein und umgekehrt.
  • Ein vierter Aspekt der Erfindung betrifft einen Testcomputer, der konfiguriert ist, um das Verfahren gemäß einer Ausführungsform des zweiten Aspekts der Erfindung auszuführen. Merkmale des Verfahrens gemäß einer Ausführungsform des zweiten Aspekts der Erfindung können auch Merkmale des Testcomputers sein und umgekehrt.
  • Ein fünfter Aspekt der Erfindung betrifft ein Testsystem zum Testen einer Software eines Steuergeräts. Das Testsystem umfasst ein Steuergerät gemäß einer Ausführungsform des dritten Aspekts der Erfindung und einen Testcomputer gemäß einer Ausführungsform des vierten Aspekts der Erfindung.
  • Ein sechster Aspekt der Erfindung betrifft ein Computerprogramm. Das Computerprogramm umfasst Befehle, die ein Steuergerät gemäß einer Ausführungsform des dritten Aspekts der Erfindung bei Ausführung des Computerprogramms durch das Steuergerät veranlassen, das Verfahren gemäß einer Ausführungsform des ersten Aspekts der Erfindung auszuführen, und/oder Befehle, die einen Testcomputer gemäß einer Ausführungsform des vierten Aspekts der Erfindung bei Ausführung des Computerprogramms durch den Testcomputer veranlassen, das Verfahren gemäß einer Ausführungsform des zweiten Aspekts der Erfindung auszuführen.
  • Ein siebter Aspekt der Erfindung betrifft ein computerlesbares Medium, auf dem das Computerprogramm gemäß einer Ausführungsform des sechsten Aspekts der Erfindung gespeichert ist. Das computerlesbare Medium kann ein flüchtiger oder nicht flüchtiger Datenspeicher sein. Beispielsweise kann das computerlesbare Medium eine Festplatte, ein USB-Speichergerät, ein RAM, ROM, EPROM oder Flash-Speicher sein. Das computerlesbare Medium kann auch ein einen Download eines Programmcodes ermöglichendes Datenkommunikationsnetzwerk wie etwa das Internet oder eine Datenwolke (Cloud) sein.
  • Merkmale des Verfahrens gemäß einer Ausführungsform des ersten bzw. zweiten Aspekts der Erfindung können auch Merkmale des Computerprogramms und/oder des computerlesbaren Mediums sein und umgekehrt.
  • Ideen zu Ausführungsformen der vorliegenden Erfindung können unter anderem als auf den nachfolgend beschriebenen Gedanken und Erkenntnissen beruhend angesehen werden.
  • Gemäß einer Ausführungsform werden beim Ausführen des Testprogramms Testdaten zum Simulieren von Fehlersituationen in zu testende Komponenten der Software eingegeben. Mittels der Testdaten können beispielsweise folgende Fehlersituationen simuliert werden: Endlosschleifen, Nullwerte, Speicherzugriffsverletzungen, Störungen von Programmabläufen, Ausführung unzulässiger Befehle oder ungültiger Gleitkommaoperationen. Denkbar sind jedoch auch beliebige andere Fehlersituationen oder Testfälle. Die Testdaten können beispielsweise von dem Testcomputer in das Steuergerät injiziert werden. Das Injizieren der Testdaten kann mittels des Testmoduls bzw. der Testmodule der Software erfolgen. Beispielsweise kann jede der zu testenden Komponenten als Reaktion auf das Eingeben der Testdaten ein Testergebnis generieren. Alternativ oder zusätzlich ist es möglich, dass die Testdaten durch das Steuergerät selbst bereitgestellt werden. Diese Ausführungsform vereinfacht unter anderem die Durchführung eines Integrationstestes, bei dem das korrekte Zusammenspiel verschiedener, voneinander abhängiger Komponenten der Software getestet wird.
  • Gemäß einer Ausführungsform werden durch den Testcomputer generierte Fremddaten in dem Steuergerät empfangen und als die Testdaten verwendet. Wie bereits erwähnt, können die Testdaten über die Kommunikationsschnittstelle des Steuergeräts eingelesen werden. Durch diese Ausführungsform kann das Generieren von Testdaten durch das Steuergerät entfallen.
  • Gemäß einer Ausführungsform werden die Testdaten in eine Systemschicht der Software eingegeben. Die Systemschicht kann beispielsweise ein Betriebssystem des Steuergeräts umfassen. Unter anderem kann die Systemschicht beispielsweise Speicherdienste und/oder Kommunikationsdienste für auf dem Steuergerät laufende Anwendungsprogramme bereitstellen. Das Testmodul der Software kann beispielsweise in die Systemschicht, etwa in einen oberen, der Anwendungsschicht nahen Bereich der Systemschicht, integriert sein. Durch diese Ausführungsform können Softwarefehler in der Systemschicht nachgewiesen werden.
  • Gemäß einer Ausführungsform wird verhindert, dass zusätzlich zu den Testdaten Ausgangsdaten mindestens einer außerhalb der Systemschicht befindlichen Komponente der Software in die Systemschicht eingegeben werden. Bei der außerhalb der Systemschicht befindlichen Komponente kann es sich beispielsweise um eine Komponente einer Anwendungsschicht oder einer Zwischenschicht zwischen der Systemschicht und der Anwendungsschicht handeln (siehe unten). Durch diese Ausführungsform können die Testergebnisse potenziell verfälschende Wechselwirkungen zwischen den Testdaten und den Ausgangsdaten der außerhalb der Systemschicht befindlichen Komponente(n) vermieden werden.
  • Gemäß einer Ausführungsform werden die Testdaten in eine Anwendungsschicht der Software eingegeben. Die Anwendungsschicht kann verschiedene Anwendungsprogramme des Steuergeräts umfassen, wie beispielsweise ein Programm zur Steuerung eines Scheibenwischers, ein Programm zur Steuerung einer Zentralverriegelung o. Ä. Durch diese Ausführungsform können Softwarefehler in der Anwendungsschicht nachgewiesen werden.
  • Zusätzlich zur Systemschicht und Anwendungsschicht kann die Software des Steuergeräts eine Zwischenschicht zur Vermittlung zwischen der Systemschicht und der Anwendungsschicht umfassen, auch Middleware genannt. Eine solche Zwischenschicht ermöglicht unter anderem die getrennte Entwicklung von System- und Anwendungsschicht und das Testen einzelner Softwarekomponenten. Das Testmodul kann beispielsweise konfiguriert sein, um zwischen der Systemschicht und der Zwischenschicht zu interagieren.
  • Gemäß einer Ausführungsform wird verhindert, dass zusätzlich zu den Testdaten Ausgangsdaten mindestens einer außerhalb der Anwendungsschicht befindlichen Komponente der Software in die Anwendungsschicht eingegeben werden. Bei der außerhalb der Anwendungsschicht befindlichen Komponente kann es sich beispielsweise um eine Komponente der Systemschicht oder der Zwischenschicht handeln. Durch diese Ausführungsform können die Testergebnisse potenziell verfälschende Wechselwirkungen zwischen den Testdaten und den Ausgangsdaten der außerhalb der Anwendungsschicht befindlichen Komponente(n) vermieden werden.
  • Gemäß einer Ausführungsform ist das Testmodul konfiguriert, um einen Eingang mindestens einer zu testenden Komponente der Software wahlweise mit einer Kommunikationsschnittstelle zur Datenkommunikation mit dem Testcomputer oder mit einem Ausgang mindestens einer weiteren Komponente der Software zu verbinden. Dadurch kann die Software mit geringem Aufwand zwischen einem Normalmodus, in dem die zu testende Komponente mit dem Ausgang der weiteren Komponente(n) statt mit der Kommunikationsschnittstelle verbunden ist, und einem Testmodus, in dem die zu testende Komponente mit der Kommunikationsschnittstelle statt mit dem Ausgang der weiteren Komponente(n) verbunden ist, umgeschaltet werden. Anders ausgedrückt können durch diese Ausführungsform Testdaten gezielt in einzelne Komponenten der Software eingegeben werden, wobei ungewollte Wechselwirkungen mit weiteren Komponenten der Software vermieden werden können.
  • Gemäß einer Ausführungsform wird das Testprogramm auf einem ersten Steuergerät ausgeführt und die zweite Binärdatei in einem Speicher eines zweiten Steuergeräts gespeichert. Anders ausgedrückt kann zum Testen der Software ein anderes Steuergerät verwendet werden als zum Speichern der zweiten Binärdatei. Beispielsweise kann die Software auf einem Teststeuergerät unter Laborbedingungen und/oder in einer Testumgebung getestet werden, während die zweite Binärdatei dann im Rahmen eines Fertigungsprozesses in ein zu fertigendes Steuergerät programmiert werden kann.
  • Figurenliste
  • Nachfolgend werden Ausführungsformen der Erfindung unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, wobei weder die Zeichnungen noch die Beschreibung als die Erfindung einschränkend auszulegen sind.
    • 1 zeigt schematisch ein Testsystem gemäß einem Ausführungsbeispiel der Erfindung.
    • 2 zeigt schematisch einen Datenfluss zwischen Komponenten einer Software eines Steuergeräts aus 1 in einem Normalmodus.
    • 3 zeigt schematisch einen Datenfluss zwischen Komponenten einer Software eines Steuergeräts aus 1 in einem ersten Testmodus.
    • 4 zeigt schematisch einen Datenfluss zwischen Komponenten einer Software eines Steuergeräts aus 1 in einem zweiten Testmodus.
    • 5 zeigt ein Ablaufdiagramm zur Veranschaulichung eines Verfahrens zum Betreiben eines Steuergeräts gemäß einem Ausführungsbeispiel der Erfindung.
    • 6 zeigt ein Ablaufdiagramm zur Veranschaulichung eines Verfahrens zum Betreiben eines Testcomputers gemäß einem Ausführungsbeispiel der Erfindung.
  • Die Figuren sind lediglich schematisch und nicht maßstabsgetreu. Gleiche Bezugszeichen bezeichnen in den Figuren gleiche oder gleichwirkende Merkmale.
  • Ausführungsformen der Erfindung
  • 1 zeigt ein Testsystem 100 zum Testen einer Software 102 eines Steuergeräts 104. Die Software 102 ist in einem Speicher 106 des Steuergeräts 104 gespeichert, etwa einem Flash-Speicher oder EPROM.
  • Die Software 102 umfasst mindestens ein Testmodul 108 zum Ausführen eines Testprogramms 110, das konfiguriert ist, um Softwarefehler in der Software 102 nachzuweisen. Die Software 102 ist in Form einer ersten Binärdatei im Speicher 106 gespeichert.
  • Weiter umfasst das Steuergerät 104 einen Prozessor 112 zum Ausführen der Software 102 bzw. des Testprogramms 110 mittels des in die Software 102 integrierten Testmoduls 108 sowie eine Kommunikationsschnittstelle 114 zur Datenkommunikation mit einem Testcomputer 116 des Testsystems 100. Der Prozessor 112, der Speicher 106 und die Kommunikationsschnittstelle 114 können über ein Bussystem 118 miteinander verbunden sein. Der Prozessor 112 und/oder der Speicher 106 können beispielsweise Komponenten eines Mikrocontrollers sein.
  • Der Testcomputer 116 kann mit einem Testcomputerspeicher 120, einem Testcomputerprozessor 122, einer Testcomputerkommunikationsschnittstelle 124 zur Datenkommunikation mit dem Steuergerät 104 sowie einem Testcomputerbussystem 126 ausgestattet sein.
  • Ein Verfahren zum Testen der Software 102 mittels des Testsystems 100 kann folgende Schritte umfassen, die einerseits durch das Steuergerät 104, wie in 5 veranschaulicht, andererseits durch den Testcomputer 116, wie in 6 veranschaulicht, ausgeführt werden.
  • In Schritt 610 generiert der Testcomputer 116 Testanfragen 128.
  • In Schritt 620 sendet der Testcomputer 116 die Testanfragen 128 über die Testcomputerkommunikationsschnittstelle 124 an die Kommunikationsschnittstelle 114.
  • In Schritt 510 empfängt das Steuergerät 104 die Testanfragen 128 an der Kommunikationsschnittstelle 114.
  • In Schritt 520 führt der Prozessor 112 basierend auf den Testanfragen 128 das Testprogramm 110 aus. Dazu führt der Prozessor 112 eine durch die erste Binärdatei codierte und das Testmodul 108 enthaltende Testversion der Software 102 aus. Im Rahmen des Testprogramms 110 können beispielsweise mehrere Tests durchgeführt werden, wobei in jedem der Tests ein Testergebnis 130 generiert wird.
  • In Schritt 530 sendet das Steuergerät 104 die Testergebnisse 130, beispielsweise gesammelt oder einzeln, über die Kommunikationsschnittstelle 114 an die Testcomputerkommunikationsschnittstelle 124.
  • In Schritt 630 empfängt der Testcomputer 116 die Testergebnisse 130 an der Testcomputerkommunikationsschnittstelle 124.
  • In Schritt 640 wertet der Testcomputer 116 die Testergebnisse 130 aus. Hierzu kann beispielsweise ein entsprechendes Auswerteprogramm durch den Testcomputerprozessor 122 ausgeführt werden, bei dem die Testergebnisse 130 mit hinterlegten Soll-Testergebnissen verglichen werden und je nach Abweichung zwischen den Testergebnissen 130 und den jeweiligen Soll-Testergebnissen bestimmt wird, ob die Software 102 betriebstauglich ist oder nicht.
  • In Schritt 650 erzeugt der Testcomputer 116 aus der ersten Binärdatei, die in dem Testcomputerspeicher 120 gespeichert und beispielsweise durch Kompilieren und Linken durch den Testcomputer 116 erzeugt worden sein kann, eine zweite Binärdatei 132, sofern in Schritt 640 die Software 102 durch das Auswerteprogramm als betriebstauglich eingestuft wurde. Die zweite Binärdatei 132 codiert eine (produktionstaugliche) Endversion der Software 102, die das Ausführen des Testmoduls 108 verhindert. Hierzu kann der Testcomputer 116 das Testmodul 108 codierende Bereiche der ersten Binärdatei mit geeigneten Inhalten ersetzen.
  • In Schritt 660 sendet der Testcomputer 116 die zweite Binärdatei 132 über die Testcomputerkommunikationsschnittstelle 124 an die Kommunikationsschnittstelle 114.
  • In Schritt 540 empfängt das Steuergerät 104 die zweite Binärdatei 132 an der Kommunikationsschnittstelle 114 und speichert sie in Schritt 550 im Speicher 106 ab. Dabei kann beispielsweise die erste Binärdatei mit der zweiten Binärdatei 132 überschrieben werden.
  • Anschließend können beispielsweise weitere Tests mit der Software 102 durchgeführt werden. Dabei kann es sich um Tests handeln, die ohne Verwendung des Testmoduls 108 bzw. der Testmodule 108 durchgeführt werden können. Beispielsweise kann in einem solchen Test unter realitätsnahen Bedingungen geprüft werden, ob die Software sämtliche Softwareanforderungen erfüllt.
  • Es ist möglich, dass beim Ausführen des Testprogramms 110 in Schritt 520 spezielle Testdaten 134 zum Simulieren von Fehlersituationen in zu testende Komponenten der Software 102 eingegeben werden.
  • Die Testdaten 134 können beispielsweise durch den Testcomputer 116 generiert und über die Testcomputerkommunikationsschnittstelle 124 an die Kommunikationsschnittstelle 114 gesendet werden, wobei das Steuergerät 104 die Testdaten 134 an der Kommunikationsschnittstelle 114 empfangen kann.
  • Wie die Testdaten 134 in die Software 102 injiziert werden können, wird nachfolgend anhand der 2 bis 4 näher beschrieben.
  • 2 zeigt eine mögliche Architektur der Software 102. In diesem Beispiel umfasst die Software 102 eine Systemschicht 200 zum Ausführen von Basissoftware, etwa eines Betriebssystems, eine Anwendungsschicht 202 zum Ausführen von Anwendungssoftware und eine Zwischenschicht 204, die den Austausch von Daten zwischen der Systemschicht 200 und der Anwendungsschicht 202 ermöglicht.
  • Das Testmodul 108 ist hier beispielhaft in die Systemschicht 200 integriert und als Datenschalter konfiguriert. Zusätzlich umfasst die Systemschicht 200 in diesem Beispiel ein Kommunikationsmodul 206 zur Datenkommunikation mit der Kommunikationsschnittstelle 114 und ein Systemmodul 208 zum Bereitstellen von Systemdiensten, beispielsweise zur Datenkommunikation mit Peripheriegeräten oder zum Steuern von Zugriffen auf den nicht flüchtigen Speicher 106.
  • In dem in 2 gezeigten Normalmodus der Software 102 können Daten einerseits zwischen der Anwendungsschicht 202 und der Zwischenschicht 204, andererseits über das Testmodul 108 zwischen der Zwischenschicht 204 und dem Systemmodul 208 ausgetauscht werden. Das Testmodul 108 ist im Normalmodus so konfiguriert, dass der Austausch von Daten sowohl zwischen dem Testmodul 108 und der Zwischenschicht 204 als auch zwischen dem Testmodul 108 und dem Systemmodul 208 ermöglicht wird und der Austausch von Daten zwischen dem Testmodul 108 und dem Kommunikationsmodul 206 verhindert wird.
  • 3 zeigt einen Datenfluss in einem ersten Testmodus der Software 102. Das Testmodul 108 ist im ersten Testmodus so konfiguriert, dass der Austausch von Daten sowohl zwischen dem Testmodul 108 und dem Kommunikationsmodul 206 als auch zwischen dem Testmodul 108 und dem Systemmodul 208 ermöglicht wird und der Austausch von Daten zwischen dem Testmodul 108 und der Zwischenschicht 204 verhindert wird. Somit wird verhindert, dass zusätzlich zu den Testdaten 134, die am Kommunikationsmodul 206 empfangen und über das Testmodul 108 an das Systemmodul 208 gesendet werden, Ausgangsdaten der Zwischenschicht 204 im Systemmodul 208 verarbeitet werden.
  • Der erste Testmodus ermöglicht beispielsweise die Durchführung eines Integrationstests mit Komponenten der Systemschicht 200. Hierbei können beispielsweise simulierte Ausgangsdaten der Anwendungsschicht 202 oder sonstige zum Nachweis von Softwarefehlern in der Systemschicht 200 geeignete Daten als die Testdaten 134 verwendet werden.
  • 4 zeigt einen Datenfluss in einem zweiten Testmodus der Software 102. Das Testmodul 108 ist im zweiten Testmodus so konfiguriert, dass der Austausch von Daten sowohl zwischen dem Testmodul 108 und dem Kommunikationsmodul 206 als auch zwischen dem Testmodul 108 und der Zwischenschicht 204 ermöglicht wird und der Austausch von Daten zwischen dem Testmodul 108 und dem Systemmodul 208 verhindert wird. Somit wird verhindert, dass zusätzlich zu den Testdaten 134, die am Kommunikationsmodul 206 empfangen, über das Testmodul 108 an die Zwischenschicht 204 gesendet und über die Zwischenschicht 204 an die Anwendungsschicht 202 gesendet werden, Ausgangsdaten des Systemmoduls 208 in der Zwischenschicht 204 bzw. in der Anwendungsschicht 202 verarbeitet werden.
  • Der zweite Testmodus ermöglicht beispielsweise die Durchführung eines Integrationstests mit Komponenten der Anwendungsschicht 202. Hierbei können beispielsweise simulierte Ausgangsdaten der Systemschicht 200 oder sonstige zum Nachweis von Softwarefehlern in der Anwendungsschicht 202 geeignete Daten als die Testdaten 134 verwendet werden.
  • Zum Umschalten des Testmoduls 108 zwischen dem Normalmodus, dem ersten Testmodus und dem zweiten Testmodus kann der Testcomputer 116 beispielsweise entsprechende Schaltbefehle an das Steuergerät 104 senden. Die Schaltbefehle können beispielsweise in den Testanfragen 128 codiert sein.
  • Abschließend wird darauf hingewiesen, dass Begriffe wie „aufweisend“, „umfassend“ etc. keine anderen Elemente oder Schritte ausschließen und Begriffe wie „eine“ oder „ein“ keine Vielzahl ausschließen. Bezugszeichen in den Ansprüchen sind nicht als Einschränkung anzusehen.

Claims (15)

  1. Verfahren zum Betreiben eines Steuergeräts (104) beim Testen einer Software (102) des Steuergeräts (104), wobei das Steuergerät (104) einen Prozessor (112) zum Ausführen der Software (102) und einen Speicher (106) zum Speichern der Software (102) umfasst, wobei das Verfahren umfasst: Empfangen (510) von durch einen Testcomputer (116) generierten Testanfragen (128) in dem Steuergerät (104); Ausführen (520) eines Testprogramms (110) zum Testen der Software (102) basierend auf den Testanfragen (128) durch Ausführen einer in dem Speicher (106) gespeicherten ersten Binärdatei durch den Prozessor (112), wobei die erste Binärdatei eine Testversion der Software (102) codiert, die mindestens ein zum Ausführen des Testprogramms (110) erforderliches Testmodul (108) umfasst, wobei Testergebnisse (130) generiert werden; Senden (530) der Testergebnisse (130) von dem Steuergerät (104) an den Testcomputer (116); und Empfangen (540) einer durch den Prozessor (112) ausführbaren zweiten Binärdatei (132) in dem Steuergerät (104) und Speichern (550) der zweiten Binärdatei (132) in dem Speicher (106), wenn der Testcomputer (116) anhand der Testergebnisse (130) bestimmt hat, dass die Software (102) betriebstauglich ist, wobei die zweite Binärdatei (132) aus der ersten Binärdatei durch den Testcomputer (116) erzeugt wurde und eine Endversion der Software (102) codiert, die das Ausführen des mindestens einen Testmoduls (108) verhindert.
  2. Verfahren nach Anspruch 1, wobei beim Ausführen (520) des Testprogramms (110) Testdaten (134) zum Simulieren von Fehlersituationen in zu testende Komponenten (200, 202, 204, 208) der Software (102) eingegeben werden.
  3. Verfahren nach Anspruch 2, wobei durch den Testcomputer (116) generierte Fremddaten in dem Steuergerät (104) empfangen und als die Testdaten (134) verwendet werden.
  4. Verfahren nach Anspruch 2 oder 3, wobei die Testdaten (134) in eine Systemschicht (200) der Software (102) eingegeben werden.
  5. Verfahren nach Anspruch 4, wobei verhindert wird, dass zusätzlich zu den Testdaten (134) Ausgangsdaten mindestens einer außerhalb der Systemschicht (200) befindlichen Komponente (202, 204) der Software (102) in die Systemschicht (200) eingegeben werden.
  6. Verfahren nach einem der Ansprüche 2 bis 5, wobei die Testdaten (134) in eine Anwendungsschicht (202) der Software (102) eingegeben werden.
  7. Verfahren nach Anspruch 6, wobei verhindert wird, dass zusätzlich zu den Testdaten (134) Ausgangsdaten mindestens einer außerhalb der Anwendungsschicht (202) befindlichen Komponente (208) der Software (102) in die Anwendungsschicht (202) eingegeben werden.
  8. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Testmodul (108) konfiguriert ist, um einen Eingang mindestens einer zu testenden Komponente (202, 208) der Software (102) wahlweise mit einer Kommunikationsschnittstelle (114) zur Datenkommunikation mit dem Testcomputer (116) oder mit einem Ausgang mindestens einer weiteren Komponente (204, 208) der Software (102) zu verbinden.
  9. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Testprogramm (110) auf einem ersten Steuergerät ausgeführt wird und die zweite Binärdatei (132) in einem Speicher (106) eines zweiten Steuergeräts gespeichert wird.
  10. Steuergerät (104), umfassend einen Prozessor (112) zum Ausführen einer Software (102) und einen Speicher (106), in dem die Software (102) gespeichert ist; wobei das Steuergerät (104) konfiguriert ist, um das Verfahren nach einem der vorhergehenden Ansprüche auszuführen.
  11. Verfahren zum Betreiben eines Testcomputers (116) beim Testen einer Software (102) eines Steuergeräts (104), wobei das Steuergerät (104) einen Prozessor (112) zum Ausführen der Software (102) und einen Speicher (106) zum Speichern der Software (102) umfasst, wobei das Verfahren umfasst: Generieren (610) von Testanfragen (128) durch den Testcomputer (116); Senden (620) der Testanfragen (128) von dem Testcomputer (116) an das Steuergerät (104), wobei die Testanfragen (128) den Prozessor (112) veranlassen, ein Testprogramm (110) zum Testen der Software (102) durch Ausführen einer in dem Speicher (106) gespeicherten ersten Binärdatei auszuführen, wobei die erste Binärdatei eine Testversion der Software (102) codiert, die mindestens ein zum Ausführen des Testprogramms (110) erforderliches Testmodul (108) umfasst, wobei Testergebnisse (130) generiert werden; Empfangen (630) der durch das Steuergerät (104) generierten Testergebnisse (130) in dem Testcomputer (116); Bestimmen (640) anhand der Testergebnisse (130) durch den Testcomputer (116), ob die Software (102) betriebstauglich ist; Erzeugen (650) einer zweiten Binärdatei (132) aus der ersten Binärdatei durch den Testcomputer (116), wenn bestimmt wurde, dass die Software (102) betriebstauglich ist, wobei die zweite Binärdatei (132) eine Endversion der Software (102) codiert, die das Ausführen des mindestens einen Testmoduls (108) verhindert; und Senden (660) der zweiten Binärdatei (132) von dem Testcomputer (116) an das Steuergerät (104).
  12. Testcomputer (116), der konfiguriert ist, um das Verfahren nach Anspruch 11 auszuführen.
  13. Testsystem (100) zum Testen einer Software (102) eines Steuergeräts (104), wobei das Testsystem (100) umfasst: ein Steuergerät (104) nach Anspruch 10; und einen Testcomputer (116) nach Anspruch 12.
  14. Computerprogramm, umfassend: Befehle, die ein Steuergerät (104) nach Anspruch 10 bei Ausführung des Computerprogramms durch das Steuergerät (104) veranlassen, das Verfahren nach einem der Ansprüche 1 bis 9 auszuführen; und/oder Befehle, die einen Testcomputer (116) nach Anspruch 12 bei Ausführung des Computerprogramms durch den Testcomputer (116) veranlassen, das Verfahren nach Anspruch 11 auszuführen.
  15. Computerlesbares Medium, auf dem das Computerprogramm nach Anspruch 14 gespeichert ist.
DE102020213809.5A 2020-11-03 2020-11-03 Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts Pending DE102020213809A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102020213809.5A DE102020213809A1 (de) 2020-11-03 2020-11-03 Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts
US17/510,259 US11899561B2 (en) 2020-11-03 2021-10-25 Method for operating a control unit when testing software of the control unit, and method for operating a test computer when testing software of a control unit
CN202111293266.6A CN114443465A (zh) 2020-11-03 2021-11-03 在测试控制设备软件时运行控制设备的方法和在测试控制设备软件时运行测试计算机的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020213809.5A DE102020213809A1 (de) 2020-11-03 2020-11-03 Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts

Publications (1)

Publication Number Publication Date
DE102020213809A1 true DE102020213809A1 (de) 2022-05-05

Family

ID=81184035

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020213809.5A Pending DE102020213809A1 (de) 2020-11-03 2020-11-03 Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts

Country Status (3)

Country Link
US (1) US11899561B2 (de)
CN (1) CN114443465A (de)
DE (1) DE102020213809A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115529623B (zh) * 2022-11-24 2023-05-02 广州世炬网络科技有限公司 一种基带单元测试装置、方法、终端设备以及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787096A (en) * 1996-04-23 1998-07-28 Micron Technology, Inc. Circuit and method for testing an integrated circuit
US7882317B2 (en) * 2004-12-06 2011-02-01 Microsoft Corporation Process isolation using protection domains
US7594142B1 (en) * 2006-06-30 2009-09-22 Microsoft Corporation Architecture for automated detection and analysis of security issues
EP2248366A4 (de) * 2008-01-29 2014-04-09 Qualcomm Inc Sichere anwendungssignierung
US8788652B2 (en) * 2009-07-27 2014-07-22 Ixia Real world network testing combining lower layer network tests, application layer tests and interdependent interactions
EP2759956B1 (de) * 2013-01-25 2017-01-11 Synopsys, Inc. System zum Prüfen einer Computeranwendung
US10462262B2 (en) * 2016-01-06 2019-10-29 Northrop Grumman Systems Corporation Middleware abstraction layer (MAL)

Also Published As

Publication number Publication date
CN114443465A (zh) 2022-05-06
US11899561B2 (en) 2024-02-13
US20220138083A1 (en) 2022-05-05

Similar Documents

Publication Publication Date Title
DE102015207656B4 (de) Verfahren und System zum Testen von Steuersoftware eines gesteuerten Systems
DE102017211433B4 (de) Verfahren zum Durchführen eines Funktionstests eines Steuergeräts in einem Hardware-in-the-Loop-Test, HIL-Test, sowie HIL-Prüfstand und Steuergerät
DE10144050A1 (de) Verfahren zur Softwareverifikation für Steuereinheiten und Verifikationssystem
EP1906377A1 (de) System und Verfahren zur Integration eines Prozessleitsystems in einen Trainingssimulator
WO2019072840A1 (de) Vorrichtung zur absicherung von diagnosebefehlen an ein steuergerät und entsprechendes kraftfahrzeug
EP3285165A1 (de) Modifizieren und simulieren der betriebssoftware eines technischen systems
EP3306295B1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
DE102009014698A1 (de) System und Verfahren zur automatischen Prüfung eines Programms für sicherheitsgerichtete Automatisierungssysteme
DE102020213809A1 (de) Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts
WO2021209192A1 (de) Verfahren und vorrichtung zum prüfen der kompatibilität zwischen einer anwendungssoftware und einer mobilen arbeitsmaschine
WO2006035038A2 (de) Verfahren zum testen von steuergerätesoftware für ein steuergerät
WO2015035438A1 (de) Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens
DE102021207872A1 (de) Kompositionelle verifikation von eingebetteten softwaresystemen
DE102016115314A1 (de) Modifizieren und Simulieren der Betriebssoftware eines technischen Systems
DE102020214922A1 (de) Verfahren zum Testen einer Anwendung für Fahrzeuge
DE102010047954A1 (de) Formelle offline-Verifikation ausführbarer Modelle
EP3933593A1 (de) Verfahren und computerprogramm zum testen eines technischen systems
DE102021115181B3 (de) Verfahren zum Prüfen einer Softwareanwendung und softwareanwendungsbezogener Daten eines Fahrzeugs, computerlesbares Medium und System
DE102022207612A1 (de) Computer-implementiertes Verfahren zur Verifikation einer Softwarekomponente einer automatisierten Fahrfunktion
DE102011000958A1 (de) Verfahren und System zum Testen von Software und/oder Hardware eines oder mehrerer in ein Kraftfahrzeug zu integrierender Bauteile
DE102017212612A1 (de) Verfahren zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs
DE102022114286A1 (de) Verfahren zum Rekonstruieren eines Laufzeitfehlers eines Softwaremoduls eines Kraftfahrzeug- Steuergeräts sowie Speichermedium und Prozessorschaltung
DE102022206900A1 (de) Verfahren zum Testen eines Computerprogramms in mehreren Zusammensetzungen aus Computerprogramm-Modulen
DE102021203278A1 (de) Verfahren zum Testen eines Steuergeräts
DE102022112141A1 (de) Verfahren zur Erstellung eines vereinfachten virtuellen Steuergeräts