DE102021209779A1

DE102021209779A1 - Prozess und Vorrichtung zum Simulieren eines Netzwerks von ECUs

Info

Publication number: DE102021209779A1
Application number: DE102021209779.0A
Authority: DE
Inventors: Damon Troy Martini
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-09-06
Filing date: 2021-09-06
Publication date: 2023-03-09

Abstract

Prozess (10) zum Simulieren eines Netzwerks (16) von ECUs (17, 18, 19, 20, 21), dadurch gekennzeichnet, dass- eine Benutzereingabe bezüglich einer Topologie des Netzwerks (16) empfangen wird,- auf der Basis der Benutzereingabe eine Erzeugung von Code durchgeführt wird,- mittels des Codes eine Basissimulation des Netzwerks (16) durchgeführt wird,- abhängig von der Basissimulation und der gewünschten Fehlerinjektion (22) die ECUs (17, 18, 19, 20, 21) angepasst werden und- unter Verwendung der angepassten ECUs (17, 18, 19, 20, 21) eine angepasste Simulation des Netzwerks (16) durchgeführt wird.

Description

Die vorliegende Erfindung betrifft einen Prozess zum Simulieren eines Netzwerks von ECUs. Die vorliegende Erfindung betrifft ferner eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speicherungsmedium.
Stand der Technik
Eine ECU (elektronische Steuereinheit) ist ein eingebettetes System in Kraftfahrzeugelektronik, das eines oder mehrere der elektrischen Systeme oder Subsysteme in einem Fahrzeug- oder Industriecomputer-Netzwerk steuert. CN111478800A offenbart einen Ansatz für den Entwurf und die Analyse von solchen zeitempfindlichen Netzwerken auf der Basis der kommerziellen Software „RTaW-Pegase“.
Offenbarung der Erfindung
Die vorliegende Erfindung stellt einen Prozess zum Simulieren eines Netzwerks von ECUs, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speicherungsmedium gemäß den unabhängigen Ansprüchen bereit.
Der vorgeschlagene Ansatz basiert auf der Erkenntnis, dass sich vorbekannte Kommunikations-Simulationswerkzeuge entweder auf Netzwerkkommunikationssimulation oder die genaue Modellierung des internen ECU-Verhaltens konzentrieren.
Eine Ausführungsform der Erfindung hat den Vorteil, dass sie die oben erwähnten Fähigkeiten in einer einzigen Werkzeugkette kombiniert, wodurch ein Verständnis der Gesamt-Netzwerkarchitektur gefördert wird. Dieses Verständnis erlaubt es Systemtechnikern, das Systemverhalten unter normalen und Fehlerfällen besser vorherzusagen und Anforderungen bezüglich der ECUs im Hinblick auf CPU-Leistungsfähigkeit und RAM-Kapazität zu untersuchen. Als Ergebnis verringert die Erfindung die Bemühungen beim Ableiten von kosteneffektiven Lösungen für Mikrocontroller, Ethern-Switches und Ethernet-Verbindungen.
Die abhängigen Ansprüche führen vorteilhafte Verfeinerungen und Verbesserungen des Grundprinzips von Anspruch 1 an. Zum Beispiel können ECUs für SWIFI (Software-implementierte Fehlerinjektion) angepasst werden, basierend auf gewünschten Rahmenübertragungsmustern wie Jitter, Babbling oder Rahmenverlust seitens der angepassten ECUs. Diese und andere Konfigurationsoptionen ermöglichen dem Systemarchitekt die Fähigkeit, mit verschiedenen Rahmen-Routingverzögerungen, Frequenzen, Pufferspeicherkonfigurationen und so weiter zu experimentieren, so dass er eine optimale Lösung finden kann, die Kundenansprüche im Hinblick auf Latenz von Ende zu Ende erfüllt, und die ECUs im Hinblick auf RAM und Rahmenverarbeitungsleistung weiter zu optimieren, um den am besten passenden Mikrocontroller zu finden und die gewählten Komponenten zu verifizieren, indem sichergestellt wird, dass alle Kundenansprüche selbst unter Fehlerbedingungen erfüllt werden.
Figurenliste
Ausführungsformen der Erfindung werden in den Zeichnungen dargestellt und in der folgenden Beschreibung ausführlicher erläutert. Es zeigen:

1 das Flussdiagramm eines Werkzeugkettenprozesses gemäß einer ersten Ausführungsform.
2 ein Netzwerk von ECUs.
3 mögliche Rahmenübertragungsmuster zur Fehlerinjektion.
4 ein angepasstes Mehrkern-Mikrocontroller-Gateway.
5 die Profilierung eines angepassten Einzelkern-Mikrocontroller-AUTOSAR-Gateways.
6 die schematische Darstellung einer Workstation gemäß einer zweiten Ausführungsform.

Ähnliche Bezugszeichen bezeichnen in den beigefügten Zeichnungen durchweg entsprechende Merkmale.
Ausführungsformen der Erfindung
Um leicht konfigurierbare Fehlerinjektion oder AUTOSAR-Verhalten in einem Architektursimulationsmodell zu implementieren, wird eine Werkzeugkette wie in 1 vorgeschlagen, die aus einem Basissimulations-Erzeuger (26) und einem angepassten Simulations-Erzeuger (27) mit speziellen Konfigurationswerkzeugen (33, 37) zusammengesetzt ist. Der Basissimulations-Erzeuger (26) empfängt Kundeneingaben (11) hinsichtlich der Topologie (23) des zu simulierenden Netzwerks, seiner Zentralgateway- bzw. CGW-Routingtabelle (24) und der Hintergrundverkehrstabelle (25). Auf der Basis solcher Eingaben (11) erzeugt (12) der Basissimulations-Erzeuger (26) Java-Code für eine Basissimulation (13) mittels RTaW-Pegase.
Abhängig von der Basissimulation (13) sowie dem zusätzlichen CGW (28) und der Fehlerinjektionskonfiguration (29) werden ausgewählte Mehrkern-ECUs dann unter Verwendung einer Architekturkonfigurations-GUI (37) des angepassten Simulations-Erzeugers (27) angepasst (14). Die AUTOSAR-ECU-Konfigurations-GUI (33) von letzterem, die weitere ECU-Eingaben (30) in Form von zusätzlichen Konfigurationsdateien (31) bereitstellt, kann verwendet werden, um ausgewählte ECUs auf einem AUTOSAR-Gateway zu modellieren.
2 zeigt das resultierende Netzwerk (16) ausgewählt angepasster ECUs (17, 18, 19, 20, 21) und ihrer Zusätze (32, 34). Im vorliegenden Beispiel umfassen die ECUs (17, 18, 19, 20,21) einen Fahrzeugcomputer (VC 17), Zonen-ECUs (18), eine Motor-ECU (19), eine CCU (Konnektivitätssteuereinheit) (20) und ein ADAS (Advanced Driver Assistance System) (21). Während der zentrale VC (17) und seine Zonen-ECUs (18) auf einem AUTOSAR-Gateway (32) modelliert werden, werden die CCU (20) und das ADAS (21) auf einer Mehrkern-CPU (34) modelliert.
Zur Implementierung der Fehlerinjektion (22 - 3) wird die ECU, die den betreffenden Rahmen sendet, als eine „Sprecher“-ECU angepasst, wobei die Vorgabe-Übertragungseigenschaften des Rahmens deaktiviert und dann durch die angepasste ECU-Software gesteuert werden. Es werden nur die Timing-Eigenschaften übersteuert; alles andere wird wie per Vorgabe (Rahmengröße, Rahmentyp usw.) gelassen. Unter Verwendung dieser Technik kann jedes Übertragungsmuster (39, 40, 41, 42) erzeugt werden, um Phänomene wie Babbling (40), Rahmenverlust (41) und Jitter (42) zu replizieren, um dem Systemarchitekten somit die Fähigkeit zu geben, die Architekturreaktion auf solche nachteiligen Effekte zu verstehen.
Das in 4 dargestellte Mehrkern-Mikrocontroller-Gateway (34) ist ein vereinfachtes Gateway-Modell, das es dem Benutzer erlaubt, eine beliebige Anzahl von Kernen (35, 36) zu konfigurieren, wodurch Parallel-Rahmenverarbeitung erlaubt wird. Ferner kann jede Kommunikationsschnittstelle mit jedem Kern (35, 36) verbunden werden, wobei das Rahmenverarbeitungsverfahren als Interrupt-gesteuert oder mit einer definierten Abfrageperiode abgefragt ausgewählt wird. Dadurch erhält die Systemarchitektur die Möglichkeit, mit verschiedenen Kommunikationsschnittstellen- oder Kernkonfigurationen zu experimentieren.
Das Einzelkern-Mikrocontroller-AUTOSAR-Gateway (32 - 2) ist ein fortschrittlicheres funktionales Gateway-Modell, das es dem Benutzer erlaubt, einen einzelnen Kern für sequenzielle Verarbeitung von CAN-, LIN- und Ethernetrahmen zu konfigurieren. Dieses Modell umfasst einen auf Priorität basierenden Task-Scheduler, der es dem Systemarchitekten erlaubt, eine beliebige Art von Task mit einer Priorität von 0 bis 7, konfigurierbaren Rahmenverarbeitungsverzögerungen auf der Basis von Messungen in realen Gateways, skalierbarer Taktfrequenz, konfigurierbaren Speicherpuffergrößen für alle Kommunikationsschnittstellen und Graphen, die die CPU-Last und erforderlichen Speicher im Verlauf der Simulation zeigen, zu definieren.
Der auf Priorität basierende Task-Scheduler kann verwendet werden, um Rahmen-Routingaufgaben sowie nicht kommunikationsbezogene Aufgaben, wie etwa Watchdog-Timer- und andere Betriebssystemaufgaben, einzuteilen. Während es einem herkömmlichen Scheduler schwerfallen kann, CAN- und Ethernetrahmen, die gleichzeitig ankommen, genau zu verarbeiten, stellt die Priorisierung sicher, dass, wenn irgendein Rahmen empfangen wird, eine Aufgabe zu dem Scheduler hinzugefügt wird und der Task-Scheduler Aufgaben sequenziell auf der Basis der Priorität ausführt.
Da jede sorgfältige Analyse der Leistungsfähigkeit eines Netzwerks ein Verständnis aller seiner ECUs, die es enthält, erfordert, werden in realen ECUs erhaltene Zeitmessungen als konfigurierbare Rahmenverarbeitungsverzögerungen in der angepassten Simulation (15) widergespiegelt.
Falls ein Hardwaretechniker gegebene EMC-Anforderungen nicht einhält und anfordert, dass die ECU-Taktfrequenz reduziert wird, erlaubt die skalierbare Taktfrequenz dem Systemarchitekten, schnell eine reduzierte Taktfrequenz zu emulieren und ihre Auswirkung auf die Architektur zu analysieren.
Unter Verwendung von in realen Mikrocontrollern gesammelten Messungen gestattet die Konfiguration von Puffergrößen dem Systemarchitekten, zu verifizieren, ob der Speicher zum Vermeiden von Rahmenverlust ausreicht.
Die in 5 abgebildeten Graphen (43, 44, 45, 46) zeigen die Auslastung von CPU-Last und Speicher für jede Kommunikationsschnittstelle als Funktion der Simulationszeit, wodurch der Systemarchitekt die Möglichkeit erhält, jede ECU (17, 18) modelliert als ein AUTOSAR-Gateway (32) zu profilieren und weiter bezüglich Rahmenverarbeitungsleistung (43) und Pufferspeicher (44, 45, 46) zu optimieren.
Dieser Prozess (10) kann zum Beispiel in Software oder Hardware oder einem Hybrid von Software und Hardware implementiert werden, wie etwa in der in der schematischen Darstellung von 6 dargestellten Workstation (50).
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

CN 111478800 A [0002]

Claims

Prozess (10) zum Simulieren eines Netzwerks (16) von ECUs (17, 18, 19, 20, 21) unter Fehlerinjektion (22), dadurch gekennzeichnet, dass - eine Benutzereingabe (11) bezüglich einer Topologie (23) des Netzwerks (16) empfangen wird, - auf der Basis der Benutzereingabe (11) eine Erzeugung (12) von Code durchgeführt wird, - mittels des Codes eine Basissimulation (13) des Netzwerks (16) durchgeführt wird, - abhängig von der Basissimulation (13) und der gewünschten Fehlerinjektion (22) die ECUs (17, 18, 19, 20, 21) angepasst (14) werden und - unter Verwendung der angepassten ECUs (17, 18, 19, 20, 21) eine angepasste Simulation (15) des Netzwerks (16) durchgeführt wird.
Prozess (10) nach Anspruch 1, dadurch gekennzeichnet, dass - die Kundeneingabe (11) eine Zentral-Gateway-Routingtabelle (24) umfasst oder - die Kundeneingabe (11) eine Hintergrundverkehrstabelle (25) umfasst.
Prozess (10) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass - die Benutzereingabe (11), Codeerzeugung (12) und Basissimulation (13) durch einen Basissimulations-Erzeuger (26) bewirkt werden und - das Anpassen (14) und die angepasste Simulation (15) durch einen angepassten Simulations-Erzeuger (27) bewirkt werden.
Prozess (10) nach Anspruch 3, dadurch gekennzeichnet, dass - das Anpassen (14) ferner von einer Nicht-AUTOSAR-Zentral-Gateway-Konfiguration (28) abhängt, - das Anpassen (14) ferner von einer Konfiguration (29) der Fehlerinjektion (22) bezüglich der erwünschten Fehlerinjektion (22) abhängt oder - das Anpassen (14) ferner von ECU-Eingaben (30) abhängt, so wie sie in anderen Konfigurationsdateien (31) des angepassten Simulations-Erzeugers (234) realisiert werden können.
Prozess (10) nach Anspruch 4, dadurch gekennzeichnet, dass - die ECUs (17, 18, 19, 20, 21) selektiv auf einem AUTOSAR-Gateway (32) modelliert werden und die ECU-Eingabe (30) mittels einer AUTOSAR-ECU-Konfigurations-GUI (33) bereitgestellt wird oder - die ECUs (17, 18, 19, 20, 21) selektiv auf einer CPU (34) mit mehreren µC-Kernen (35, 36) modelliert und mittels einer Architekturkonfigurations-GUI (37) des angepassten Simulations-Erzeugers (27) angepasst (14) werden.
Prozess (10) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass - die Fehlerinjektion (22) durch eine Software (38) auf der Basis erwünschter Rahmenübertragungsmuster (39, 40, 41, 42) der angepassten ECUs (17, 18, 19, 20, 21) gesteuert wird und - die Muster (39, 40, 41, 42) reguläre Übertragung (39), Jitter (40), Babbling (41) oder Rahmenverlust (42) umfassen.
Prozess (10) nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass - mittels der angepassten Simulation (15) die ECUs (17, 18, 19, 20, 21) im Hinblick auf CPU-Last (43), Ethernet-Pufferverwendung (44), Verwendung von Interrupt-gesteuertem CAN-Puffer (45) oder softwaregesteuerter CAN-Pufferverwendung (46), wie etwa in einem Abfrageintervall von 1 Millisekunde, profiliert werden.
Prozess (10) nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass - die ECUs (17, 18, 19, 20, 21) einen Fahrzeugcomputer (17), eine Zonen-ECU (18), eine Motor-ECU (19), eine Konnektivitätssteuereinheit (20) oder ein fortschrittliches Fahrerhilfssystem (21) umfassen.
Computerprogramm, das dafür ausgelegt ist, den Prozess (10) nach einem der Ansprüche 1 bis 8 auszuführen.
Maschinen-lesbares Speicherungsmedium, das das Computerprogramm nach Anspruch 9 speichert.
Vorrichtung (50), die dafür ausgelegt ist, den Prozess (10) nach einem der Ansprüche 1 bis 8 auszuführen.