DE102018207172A1 - Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems - Google Patents

Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems Download PDF

Info

Publication number
DE102018207172A1
DE102018207172A1 DE102018207172.1A DE102018207172A DE102018207172A1 DE 102018207172 A1 DE102018207172 A1 DE 102018207172A1 DE 102018207172 A DE102018207172 A DE 102018207172A DE 102018207172 A1 DE102018207172 A1 DE 102018207172A1
Authority
DE
Germany
Prior art keywords
software components
stored
state
following features
states
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
DE102018207172.1A
Other languages
English (en)
Inventor
Rainer Baumgaertner
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 DE102018207172.1A priority Critical patent/DE102018207172A1/de
Publication of DE102018207172A1 publication Critical patent/DE102018207172A1/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/30Monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40Data acquisition and logging

Abstract

Verfahren (20) zum Simulieren eines cyber-physischen Systems in einer realen Betriebssituation,gekennzeichnet durch folgende Merkmale:- Messdaten und interne Zustände von Softwarekomponenten (cl, c2) des Systems werden in der Betriebssituation abgespeichert (21) und- ein Simulator wird mit den Messdaten und Zuständen parametriert (22).

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Simulieren eines cyber-physischen Systems in einer realen Betriebssituation. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
  • Stand der Technik
  • In der Informatik wird als cyber-physisches System (cyber-physical system, CPS) jedweder Verbund informatischer, softwaretechnischer Komponenten mit mechanischen oder elektronischen Teilen bezeichnet, die über eine Dateninfrastruktur wie einen Feldbus oder ein anderweitiges Rechnernetz kommunizieren. Die Ausbildung von cyber-physischen Systemen entsteht aus der Vernetzung eingebetteter Systeme durch drahtgebundene oder drahtlose Kommunikationsnetze. Cyber-physische Systeme nach dem Stand der Technik sind durch einen hohen Grad an Komplexität gekennzeichnet.
  • Typische Einsatzbereiche von CPS umfassen höchst zuverlässige medizinische Geräte und Systeme, altersgerechte Assistenzsysteme, IT-Verkehrssteuerungs- und Verkehrslogistiksysteme, vernetzte Sicherheits- sowie Fahrerassistenzsysteme für Kraftfahrzeuge, industrielle Prozesssteuerungs- und Automationssysteme, nachhaltige Umweltbeeinflussungs- und Beobachtungssysteme, Energieversorgungsmanagementsysteme, militärische Systemvernetzungssysteme sowie Infrastruktursysteme für Kommunikation und Kultur.
  • Beispielsweise offenbart WO2016023767A1 ein Fahrerassistenzsystem für ein Fahrzeug, das ausgebildet ist, die Fahrzeugführung durch Teilautomatisierung und Kooperation mit dem Fahrer zu übernehmen. Das Fahrerassistenzsystem umfasst dabei mindestens ein Bedienelement, das beim Auftreten bestimmter Fahrsituationen vom Fahrer betätigt werden muss, wodurch die Vigilanz und die Aufmerksamkeit des Fahrers während der Durchführung einer teilautomatisiert durchgeführten Fahrt sichergestellt ist. Abhängig von der Betätigung des Bedienelements wird das aktuell durchgeführte teilautomatisierte Fahrmanöver bzw. die teilautomatisierte Fahrt und ein bei oder nach der Betätigung des Bedienelements durchgeführtes teilautomatisiertes Fahrmanöver fortgeführt, in der Ausführung angepasst oder beendet.
  • Offenbarung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Simulieren eines cyber-physischen Systems in einer realen Betriebssituation, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
  • Der vorgeschlagene Ansatz fußt hierbei auf der Erkenntnis, dass Fahrerassistenzsysteme für hochautomatisiertes Fahren aktuell in der Entstehungsphase sind. Die Komplexität derartiger Software liegt mitunter um Größenordnungen über derjenigen heutiger kraftfahrzeugtechnischer (automotive) Systeme.
  • Dem nachfolgend vorgestellten Verfahren liegt ferner die Einsicht zugrunde, dass Systeme für hochautomatisiertes Fahren technisch aufwändig sind. Gleiches gilt für zukünftige Robotik-Systeme. Sie benötigen eine hohe Rechenleistung und einen großen Speicher und haben hohe Sicherheitsanforderungen zu erfüllen. Das Berücksichtigen der funktionalen Sicherheitsanforderungen erhöht zusätzlich die Systemkomplexität.
  • Heutige Systeme im automobilen Umfeld sind oft als direkt kommunizierende Applikationen oder Komponenten ausgelegt. Daten werden mit dem Zeitpunkt der Verfügbarkeit sofort anderen Applikationen zur Verfügung gestellt. Der exakte zeitliche Zusammenhang der einzelnen Applikationen kann dabei aus technischen Gründen nicht exakt vorgegeben werden, z. B. da viel weniger unabhängige Rechenkerne zur Verfügung stehen, als Applikationen, die darauf ausgeführt werden sollen. Daher ist schwer vorherzusagen, wann Daten exakt gesendet werden. Aus Sicht der empfangenden Applikationen führt dies zu einem unvorhersehbaren, von der tatsächlichen Ausführungszeit abhängigen Datenalter.
  • Ein Vorschlag zur Lösung dieses Problems sieht vor, dass die Ausgaben aller Applikationen oder Komponenten einer Zeitscheibe oder Aufgabe (task) erst zu Beginn der nächsten Zeitscheibe sichtbar gemacht und die Eingaben aller Applikationen bzw. Komponenten innerhalb einer Zeitscheibe bzw. Task am Anfang der Task quasi eingefroren werden.
  • Der damit erreichbare Determinismus erleichtert entscheidend die Entwicklung, da nun bei gegebenen Eingangsdaten die Ausgabedaten und deren Empfänger - selbst im Rahmen eines komplexen Zeitscheibensystems - eindeutig feststehen.
  • Neben der vereinfachten Entwicklung ist hiermit ist auch eine endlich eindeutige Nachsimulation möglich.
  • Herkömmliche Nachsimulationen sind leider in der Regel nicht eindeutig, da der beschriebene Determinismus nicht gewährleistet ist und somit mehr oder weniger abweichende Ergebnisse entstehen. Dies erschwert das exakte Nachstellen der des zu untersuchenden Sachverhalts und erschwert jegliche Fehlersuche. Speziell in komplexen System führt dies wiederum zu nur schwer handhabbaren Situationen.
  • Ein Vorzug dieser Lösung liegt in der eröffneten Möglichkeit einer Nachsimulation, die auch bei Vorliegen lediglich partieller Messungen - also solcher Messdaten, die nicht die vollständige Betriebsdauer des Systems seit dessen Start abdecken - sowie bei Komponenten, die interne Zustände haben und Systemen mit Rückkopplungen funktioniert. Dazu wird der interne Zustand aller an der Nachsimulation, beteiligten Applikationen oder Komponenten zusätzlich in der Messung abgespeichert. Wird nun dieser interne Zustand zu Beginn der Nachsimulation aus der Messung in die Komponenten übertragen, dann ist eine eindeutige Nachsimulation möglich.
  • Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So ist die Reduktion des Datenaufkommens im beschriebenen Verfahren in erheblichem Umfang möglich. Da oft der interne Zustand von Komponenten ein Vielfaches des normalen Datenaufkommens darstellen würde, ist es vorteilhaft, dieses Datenvolumen zu reduzieren.
  • Figurenliste
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 das Flussdiagramm eines Verfahrens gemäß einer Ausführungsform der Erfindung.
    • 2 ein System, welches aus Applikationen oder Komponenten besteht, die innerhalb von Zeitscheiben in Tasks organisiert sind.
  • Ausführungsformen der Erfindung
  • 1 illustriert die grundlegenden Schritte des vorgeschlagenen Verfahrens (20). Erfindungsgemäß werden dabei zusätzlich zu den Messdaten des zu simulierenden cyber-physischen Systems in dessen Betrieb auch die internen Zustände der Softwarekomponenten abgespeichert (Prozess 21), die später zur Parametrierung (Prozess 22) eines geeigneten Simulators dienen können.
  • Die erste Phase dieses Vorgehens (Prozess 21) sei nunmehr im Einzelnen anhand von 2 erläutert. Wie diese Abbildung erkennen lässt, geben die Applikationen bzw. Komponenten (cl, c2) Daten aus und können diese empfangen. Die Datenausgabe ist auf der rechten Seite der jeweiligen Komponente (cl, c2) dargestellt, der Dateneingang auf der linken Seite. Die Zeit schreitet abbildungsgemäß von links nach rechts voran.
  • Weiterhin wird gezeigt, dass jede Komponente (cl, c2) zusätzlich ihren internen Zustand (16) ausgibt. Vorteilhaft ist, wenn Sie diesen im nächsten Zyklus wieder einliest. Es wäre aber auch möglich, den internen Zustand (16) nur zur Messung auszugeben und ihn z. B. auf Kommando wieder einzulesen. Ebenso wäre es denkbar, den internen Zustand (16) auf Befehl auszugeben.
  • Der interne Zustand (16) kann vorteilhaft vor der nächsten Taskaktivierung in einer Messeinrichtung abgespeichert werden. Die mit den Bezugszeichen 6 bis 11 versehenen Pfeile stellen die Messzeitpunkte im Zeitscheibensystem dar. In der Darstellung ist zu sehen, dass für Komponenten in Tasks mit einer kürzeren Zykluszeit auch deutlich öfter der interne Zustand (16) zur Messeinrichtung übertragen werden muss (so wird z. B. c2 in den Zeitpunkten 6, 7, 8 und 9 gemessen) als für Tasks mit einer größeren Zykluszeit (z. B. cl wird in 10 und 11 gemessen).
  • Kreuzförmige Markierungen am unteren Rand der Abbildung deuten an, welche Messungen entfallen könnten. Beispielsweise könnte in einer Ausgestaltung der Erfindung zu den Zeitpunkten 14 und 15 nicht, wohl aber zu den Zeitpunkten 12 und 13 gemessen werden. Eine auf diesen Messungen aufsetzende Nachsimulation könnte damit lediglich zu den Zeitpunkten 12 und 13 starten. Dies würde aber keine substanzielle Einschränkung darstellen, da dank der erfindungsgemäßen Möglichkeit zur genauen Nachsimulation die Zustände zu den Folgezeitpunkten dennoch berechnet werden können.
  • Eine entsprechende Ausführungsform der Erfindung erschließt ein enormes Potential zur Reduzierung des für die Zustandsmessung benötigten Messdatenumfangs. Auf diese Weise wird ein Messen der internen Komponentenzustände in hohem Maße praktikabel.
  • Vorteilhaft ist weiterhin der folgende Umstand: Da der Zustand (16) der Komponenten (cl, c2) zu solchen Zeitpunkten, die zwischen zwei Zustandsmessungen liegen, nachsimuliert werden kann, können die Messzeitpunkte nahezu beliebig gewählt werden. Es ist zum Beispiel denkbar, nur im Abstand von jeweils 1.000 Zyklen den Zustand (16) zu messen. Damit würde es z. B. ausreichen, die Daten von 1.000 Zyklen vor dem Nachsimulationspunkt in der Messung abzuspeichern, ohne auf eine genaue Nachsimulation verzichten zu müssen. Die Reduzierung des Datenaufkommens kann dabei fast proportional zum gewählten „Abstand“ sein. Im genannten Beispiel wären also nur 0,1 % der Zustandsmessdaten einer vollständigen Messung zu verwalten.
  • Vorteilhaft kann auch sein, den Zeitpunkt für die Zustandsmessung adaptiv zu wählen. Falls z. B. eine Komprimierung der Messdaten verwendet wird, dann könnte die Zustandsmessung nach dem erfolgreichen Wegschreiben des letzten Zustands (16) erfolgen. Dies würde dann eine variierende Zustandsmessung gestatten. Solange genügend Messdaten in der Messung vorliegen, wäre auch in dieser Ausführungsform eine eindeutige Nachsimulation möglich.
  • Besonders vorteilhaft ist es dabei, den Messzeitpunkt für den Zustand (16) auf den gemeinsamen Zyklusanfang aller Tasks (T1, T2) zu legen. In 2 sind diese mit den Bezugszeichen 12 und 13 versehen. Damit wird ein konsistenter Zustand aller Tasks (T1,T2) und ihrer Komponenten (cl, c2) erreicht, was das Nachsimulieren erleichtert. Dies schränkt nicht den möglichen Abstand zwischen den Messungen ein, sondern legt nur einen günstigen Zyklusanfang für die Messung fest.
  • Vorteilhaft ist es ferner, die Tasksystemzyklen fortlaufend zu nummerieren und die jeweilige Zyklusnummer gemeinsam mit den gemessenen Zuständen (16) der Komponenten (cl, c2) abzuspeichern. Damit ist der genaue Zyklus zum „Wiederaufspielen“ der Messung für die Nachsimulation bekannt.
  • Dieses Verfahren (20) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät implementiert sein.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • WO 2016023767 A1 [0004]

Claims (10)

  1. Verfahren (20) zum Simulieren eines cyber-physischen Systems in einer realen Betriebssituation, gekennzeichnet durch folgende Merkmale: - Messdaten und interne Zustände von Softwarekomponenten (cl, c2) des Systems werden in der Betriebssituation abgespeichert (21) und - ein Simulator wird mit den Messdaten und Zuständen parametriert (22).
  2. Verfahren (20) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - das Abspeichern (21) erfolgt periodisch in mehreren Zeitscheiben und - der in einer der Zeitscheiben abgespeicherte Zustand (16) einer der Softwarekomponenten (cl, c2) wird in einer späteren Zeitscheibe von der Softwarekomponente (cl, c2) wieder eingelesen.
  3. Verfahren (20) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - das Abspeichern (21) erfolgt bedarfsweise und - der in einer der Zeitscheiben abgespeicherte Zustand (16) einer der Softwarekomponenten (cl, c2) wird auf Kommando wieder eingelesen.
  4. Verfahren (20) nach einem der Ansprüche 1 bis 3, gekennzeichnet durch folgendes Merkmal: - der Zustand (16) einer der Softwarekomponenten (cl, c2) wird auf Befehl ausgegeben.
  5. Verfahren (20) nach einem der Ansprüche 1 bis 4, gekennzeichnet durch folgendes Merkmal: - der Zustand (16) einer der Softwarekomponenten (cl, c2) wird vor einer erneuten Aktivierung der Softwarekomponente (cl, c2) in einer Messeinrichtung abgelegt.
  6. Verfahren (20) nach einem der Ansprüche 1 bis 5, gekennzeichnet durch folgende Merkmale: - jede der Softwarekomponenten (cl, c2) wird periodisch in einem für die Softwarekomponente (cl, c2) spezifischen Zeitintervall ausgeführt und - das Abspeichern (21) erfolgt periodisch in einem den Softwarekomponenten (cl, c2) gemeinsamen Zeitintervall, welches einem gemeinsamen Vielfachen der spezifischen Zeitintervalle entspricht.
  7. Verfahren (20) nach einem der Ansprüche 1 bis 5, gekennzeichnet durch folgende Merkmale: - das Abspeichern (21) umfasst eine Komprimierung zumindest der Messdaten und - das Abspeichern (21) wird erst wiederholt, wenn die komprimierten Messdaten und Zustände vollständig geschrieben wurden.
  8. Computerprogramm (cl, c2), welches eingerichtet ist, das Verfahren (20) nach einem der Ansprüche 1 bis 7 auszuführen.
  9. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
  10. Vorrichtung (30), die eingerichtet ist, das Verfahren (20) nach einem der Ansprüche 1 bis 7 auszuführen.
DE102018207172.1A 2018-05-08 2018-05-08 Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems Pending DE102018207172A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102018207172.1A DE102018207172A1 (de) 2018-05-08 2018-05-08 Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018207172.1A DE102018207172A1 (de) 2018-05-08 2018-05-08 Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems

Publications (1)

Publication Number Publication Date
DE102018207172A1 true DE102018207172A1 (de) 2018-06-21

Family

ID=62251252

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018207172.1A Pending DE102018207172A1 (de) 2018-05-08 2018-05-08 Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems

Country Status (1)

Country Link
DE (1) DE102018207172A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11494535B2 (en) 2019-09-17 2022-11-08 Robert Bosch Gmbh Method and device for simulating a control unit

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016023767A1 (de) 2014-08-15 2016-02-18 Robert Bosch Gmbh Fahrerassistenzsystem

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016023767A1 (de) 2014-08-15 2016-02-18 Robert Bosch Gmbh Fahrerassistenzsystem

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11494535B2 (en) 2019-09-17 2022-11-08 Robert Bosch Gmbh Method and device for simulating a control unit

Similar Documents

Publication Publication Date Title
EP2801872B1 (de) Testeinrichtung zum Test eines virtuellen Steuergeräts
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
DE102014110096A1 (de) Testeinrichtung zum Echtzeittest eines virtuellen Steuergeräts
DE102017120016A1 (de) Verfahren zur Konfiguration eines zum Testen eines elektronischen Steuergeräts eingerichteten Testgeräts sowie Konfigurationssystem
DE102018110020A1 (de) Verfahren zum Erzeugen eines auf einem Testgerät ausführbaren Modells eines technischen Systems und Testgerät
EP1947568A1 (de) Verfahren zur Beobachtung eines Steuergeräts
EP2520991A1 (de) Verfahren zum steuernden Eingriff in das Verhalten eines Submoduls
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
DE102018207172A1 (de) Verfahren und Vorrichtung zum Simulieren eines cyber-physischen Systems
DE102014016180A1 (de) Verfahren und Einrichtung zur Verwaltung und Konfiguration von Feldgeräten einer Automatisierungsanlage
EP3916493A1 (de) Prognose eines systemzustands eines technischen systems
EP3699704B1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
EP2985663A1 (de) Verfahren zur Simulation einer automatisierten industriellen Anlage
EP3603010B1 (de) Verfahren und korrespondierendes system zur datenübertragung von einem gerät an ein datenverwaltungsmittel
EP2193409B1 (de) System und verfahren zur modellierung von signalflüssen in automatisierungstechnischen anlagen
DE102018130649A1 (de) Verfahren zum Analysieren des Messverhaltens eines Feldgeräts der Automatisierungstechnik in Abhängigkeit der Parametrierung des Feldgeräts
DE102017130842A1 (de) Konfigurationssystem zur Konfiguration eines zum Testen eines elektronischen Steuergeräts geeigneten Testsystems
DE102016123599A1 (de) Robotersteuerung mit Funktion zur Kommunikation mit einer speicherprogrammierbaren Steuerung und Kommunikationssystem
EP1958101B1 (de) System und verfahren zur automatischen prüfung von planungsergebnissen
DE102015100736A1 (de) Computerimplementiertes Verfahren zur automatischen Generierung wenigstens eines eine Treiberfunktion repräsentierenden Blocks für eine blockbasierte Modellierungsumgebung
DE102013010783A1 (de) Verfahren und Steuergerät zum Testen einer Automatisierungslösung basierend auf einer PLC-Steuerung
DE102018207175A1 (de) Verfahren und Vorrichtung zum Aktivieren von Tasks in einem Betriebssystem
WO2014146686A1 (de) Werkzeug und verfahren zur simulation einer technischen anlage
DE102016107797A1 (de) Verfahren zur Konfiguration eines zum Testen eines elektronischen Steuergeräts eingerichteten Testgeräts
DE102022115217A1 (de) Verfahren und System zur Bestimmung von Parametrierungswerten für ein physikalisches Modell einer Fahrzeugkomponente

Legal Events

Date Code Title Description
R230 Request for early publication
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0019000000

Ipc: G16Z0099000000