DE102020102996A1

DE102020102996A1 - Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung

Info

Publication number: DE102020102996A1
Application number: DE102020102996.9A
Authority: DE
Inventors: Frieder Heckmann; Markus Hedderich; Markus Heimberger
Original assignee: Valeo Schalter und Sensoren GmbH
Current assignee: Valeo Schalter und Sensoren GmbH
Priority date: 2020-02-06
Filing date: 2020-02-06
Publication date: 2021-08-12

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Modellieren von Anforderungen für elektrische Fahrzeugkomponenten mit den Schritten:a) Festlegen (S1) von Funktionsblöcken (12, 13, 14, 15) für Basisunktionen eines Fahrerassistenzsystems,b) Zuordnen (S2) von zeitlichen Ressourcen zu den Funktionsblöcken (12, 13, 14, 15),gekennzeichnet durchc) Gruppieren (S3) der Funktionsblöcke (12, 13, 14, 15) zu Ausführungseinheiten (11),d) Erstellen (S4) einer Architektur (18) von Ausführungseinheiten (11), die eine Gesamtheit von Fahrerassistenzfunktionen eines Fahrerassistenzsystems darstellt, wobei festgelegt wird in welchem zeitlichen Zyklus die jeweilige Ausführungseinheiten (11) ausgeführt werden,e) Zuweisen (S5) von Abfolgen von Funktionsblöcken (12, 13, 14, 15) einer jeweiligen Ausführungseinheit (11) zu jeder Fahrerassistenzfunktion,f) Ausführen (S6) aller Abfolgen und Ermitteln einer dafür benötigten Zeit, undg) Vergleichen (S7) der benötigten Zeit mit einer vorgegebenen Echtzeitanforderung.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Modellieren von Anforderungen für elektrische Fahrzeugkomponenten und ein Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung.
Auch betrifft die vorliegende Erfindung eine Vorrichtung zur Durchführung von Schritten des Verfahrens.
Des Weiteren betrifft die vorliegende Erfindung ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Computerprogramms durch einen Computer diesen veranlassen, Schritte des Verfahrens auszuführen.
Des Weiteren betrifft die vorliegende Erfindung ein Datenträgersignal, das das Computerprogramm überträgt.
Des Weiteren betrifft die vorliegende Erfindung ein computerlesbares Medium, umfassend Befehle, die bei der Ausführung durch einen Computer diesen veranlassen, Schritte des Verfahrens auszuführen.
Prozesse in der industriellen Fertigung werden zunehmend komplexer und stellen dadurch immer höhere Anforderungen an die Automatisierungstechnik. Die Effizienz in der Entwicklungs- und Fertigungsphase von Maschinen und Anlagen ist hier ein entscheidender Faktor. Hierbei ist man aus Zeitgründen darauf angewiesen, möglichst viele Entwicklungsaufgaben zu vereinfachen und zu automatisieren.
Zur Optimierung bei der Entwicklung einer neuen Maschine oder Anlage nutzt man integrierte Entwicklungsprozesse. Ein Ansatz stellt dabei die modellbasierte Entwicklung dar, bei der das Steuerungsprogramm und das Maschinenmodell im Simulationswerkzeug modelliert werden.
Die modellbasierte Entwicklung bietet die Möglichkeit, konzeptionelle Fehler in kritischen Steuerungs- und Regelungsfunktionen frühzeitig zu erkennen und zu beseitigen, bevor Unternehmen physikalische Maschinen oder Anlagen bauen. Entwickler sparen damit Zeit und Aufwand für die Entwicklung und die Inbetriebnahme und können dadurch Kosten senken. Modular aufgebaute Modelle erhöhen die Wiederverwendbarkeit und ermöglichen nachträgliche Erweiterungen, ohne dass das gesamte System dafür neu programmiert werden muss.
Bei der modellbasierten Entwicklung entwerfen Entwickler das Steuerungsprogramm im Simulationsmodell und entwickeln es dort so lange weiter, bis das Simulationsergebnis zufriedenstellend ist. Anschließend wird es mittels automatischer Code-Generierung vollständig automatisiert und ohne manuellen Eingriff auf die Steuerung übertragen. Dieses Vorgehen verringert den Aufwand. Auch das Risiko, dass durch die manuelle Programmierung Fehler entstehen, ist eher gering. Zudem lässt sich so die Zeit für die Inbetriebnahme reduzieren, da das Programm bereits an einer virtuellen Maschine in der Simulation überprüft wurde und an der physikalischen Maschine nur noch das Feintuning stattfindet. Bisher hat man das Steuerungsprogramm manuell programmiert und - falls schon vorhanden - an der physikalischen Maschine getestet. Das kostet viel Zeit und Geld und kann sogar gefährlich sein; außerdem hängt die Code-Qualität jeweils vom einzelnen Programmierer ab.
Modellbasierte Entwicklung wird insbesondere verwendet zum Entwurf, zur Implementierung und zur Dokumentation komplexer Systeme. Alle relevanten Daten werden dabei in einem Modell gehalten, um Redundanz und damit den Zwang zur Synchronisation der gleichen Information an verschiedenen Stellen zu vermeiden. Nach Stand der Technik liegt der Fokus in diesen Modellen auf den statischen Aspekten wie der funktionalen Analyse, der Darstellung der Systemelemente und ihren Schnittstellen untereinander. Dynamische Aspekte werden vernachlässigt.
Ein immer wichtig werdender Teil der Systementwicklung ist der Entwurf, die Dokumentation und Verifikation der dynamischen Systemaspekte wie die Echtzeitanforderungen und die Echtzeit-Architektur. In komplexen Systemen mit mehreren Cores, CPUs oder Hardware- (abgekürzt: HW) Beschleunigern ist die Echtzeit-Architektur anfällig für Fehler, da es eine Vielzahl von parallelen Prozessen gibt, die teils synchron und teils asynchron zueinander arbeiten. Zusätzlich muss eine große Zahl an Echtzeitanforderungen erfüllt werden. Oft zeigen sich Echtzeit-Probleme erst im Fahrzeugtest und können damit erst spät behoben werden. Timing Probleme sind heute sogar gar nicht erkennbar, da relevante Information wie Zeitstempeln und Scheduler Status nicht zugänglich sind. Fehler, die spät erkannt werden, sind teuer im Beheben. Daher sollten sie so früh wie möglich gefunden werden.
Um die dynamischen Aspekte eines Systems zu entwerfen, wird nach heutigem Stand der Technik aus dem statischen Systemmodell manuell ein Simulationsmodell in einem speziellen Simulationstool erzeugt. Die Echtzeitanforderungen und Wirkketten werden im Simulationstool hinterlegt und im Zuge der Simulation getestet.
Außerdem ist eine Konsistenz zwischen Modellierungstool und Simulationstool nur gewährleistet, wenn Änderungen an beiden Modellen synchron durchgeführt werden. Eine Inkonsistenz zwischen den Modellen kann dazu führen, dass Fehler nicht frühzeitig erkannt werden können.
Ein weiterer Nachteil ist, dass bisher keine direkte Verbindung zwischen dem im Systemmodell hinterlegten Echtzeitanforderungen und dem System- bzw. Software-Test existiert. Dadurch ist nicht gewährleistet, dass der Test der Echtzeitanforderungen auf Basis der im Modell vorhandenen Informationen erfolgt.
Ausgehend von dem oben genannten Stand der Technik liegt der Erfindung somit die Aufgabe zugrunde, ein verbessertes Verfahren, eine verbesserte Vorrichtung, ein verbessertes Computerprogramm, ein verbessertes Datenträgersignal und ein verbessertes computerlesbares Medium anzugeben. Insbesondere soll die modellbasierte Entwicklung insbesondere verbesserte Echtzeit-Architekturen zur Verfügung stellen.
Die Lösung der Aufgabe erfolgt erfindungsgemäß durch die Merkmale der unabhängigen Ansprüche. Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
Es wird ein Verfahren zum Modellieren von Anforderungen für elektrische Fahrzeugkomponenten, insbesondere eine Prozessorvorrichtung eines Fahrzeugs (z.B. mit einer CPU und einem Arbeitsspeicher) vorgeschlagen. Das Verfahren umfasst die Schritte: a) Festlegen von Funktionsblöcken für Basisunktionen eines Fahrerassistenzsystems, b) Zuordnen von zeitlichen Ressourcen zu den Funktionsblöcken, c) Gruppieren der Funktionsblöcke zu Ausführungseinheiten, d) Erstellen einer Architektur von Ausführungseinheiten, die eine Gesamtheit von Fahrerassistenzfunktionen eines Fahrerassistenzsystems darstellt, wobei festgelegt wird in welchem zeitlichen Zyklus die jeweilige Ausführungseinheiten ausgeführt werden, e) Zuweisen von Abfolgen von Funktionsblöcken einer jeweiligen Ausführungseinheit zu jeder Fahrerassistenzfunktion, f) Ausführen aller Abfolgen und Ermitteln einer dafür benötigten Zeit, und g) Vergleichen der benötigten Zeit mit einer vorgegebenen Echtzeitanforderu ng.
Das Verfahren hat den Vorteil, dass die Integration der Fahrzeugkomponente in das Fahrzeug vereinfacht ist. Weiterhin besteht der Vorteil, dass mit Hilfe der ermittelten Zeiten die Integrationsbedingungen und/oder Integrationsanforderungen ermittelt und bereitgestellt werden. Vorzugsweise ist das Verfahren ein Verfahren zum Abgleichen eines Rechenaufwands für eine Vielzahl von Fahrfunktionen eines Fahrzeugs mit der Fahrzeugkomponente, insbesondere einer Hardware des Fahrzeugs, die den Rechenaufwand aufbringen muss.
Eine Fahrerassistenzfunktion ist z.B. ein Notbremsassistent, eine Parklückenerkennung und ein Rückfahrassistent usw. des Fahrzeugs. Moderne Fahrzeuge umfassen eine Vielzahl, insbesondere mehr oder weniger als 10, 20 oder 30, derartiger Fahrerassistenzfunktionen. Die zeitlichen Ressourcen sind z.B. Nettozeiten (d.h. wie lange die CPU tatsächlich beschäftigt ist) oder Bruttozeiten (d.h. die tatsächliche Ausführungszeit, d.h. Rechenzeit mit Unterbrechungen durch andere Prozesse). Beispielsweise wird in dem Verfahren eine einzige Architektur erstellt. Vorzugsweise bildet jede Abfolge aus Schritt e) eine Wirkkette aus. Vorzugsweise werden die Schritte f) und g) automatisiert durchgeführt. Der Schritt b) wird insbesondere in einer beliebigen Reihenfolge jedoch vor dem Schritt f) durchgeführt.
Gemäß einer Ausführungsform des Verfahrens, erfolgt die Abfolge von Funktionsblöcken in einer Ausführungseinheit sequenziell.
Gemäß einer weiteren Ausführungsform des Verfahrens, erfolgt die Abfolge von Funktionsblöcken in einer Ausführungseinheit parallel. Beispielsweise können ein Funktionsblock, der ein Abgreifen von Kameradaten repräsentiert, und ein Funktionsblock, der ein Abgreifen von Ultraschalldaten repräsentiert, parallel ausgeführt werden.
Gemäß einer weiteren Ausführungsform des Verfahrens, umfasst Schritt d) ein logisches Verschalten von Eingängen und Ausgängen der Ausführungseinheiten.
Gemäß einer weiteren Ausführungsform des Verfahrens, werden alle Verfahrensschritte in einem einzigen Modell ausgeführt.
Gemäß einer weiteren Ausführungsform des Verfahrens, werden alle Verfahrensschritte in einem einzigen Softwaretool ausgeführt.
Gemäß einer Ausführungsform des Verfahrens, wird nach Schritt g) der festgelegte zeitliche Zyklus zumindest einer Ausführungseinheit geändert und/oder wird die zeitliche Ressource zumindest eines Funktionsblocks und/oder wird die Architektur von Ausführungseinheiten geändert und/oder wird die Zuweisung der Abfolge der Funktionsblöcke geändert, insbesondere wenn in Schritt g) die benötigten Zeit größer als die vorgegebenen Echtzeitanforderung ist. Vorzugsweise werden die Schritte f) und g) wiederholt. Dies hat den Vorteil, dass iterativ alle Echtzeitbedingungen erfüllt werden können.
Weiterhin wird ein Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung vorgeschlagen. Hierbei weist die Echtzeit-Architektur auf: eine Laufzeitschicht mit einer logischen Architektur zur Aufteilung von auszuführenden Operationen auf logische Systemelemente einer Hardware-Schicht und auf logische Systemelemente zumindest einer Software-Schicht; eine Integrationsarchitektur zum Zuordnen von den logischen Systemelementen zu der Hardware-Schicht, zu der Laufzeitschicht und zu der zumindest einen Software-Schicht; und zumindest eine Wirkkette zum Auslösen einer Aktion in einem Fahrzeug basierend auf einer Sensormessung oder einer Eingabe durch einen Fahrer. Die zumindest eine Wirkkette ist ausgestaltet zur Erfüllung zumindest einer Echtzeitanforderung. Das Verfahren weist folgende Verfahrensschritte auf:

- Generieren eines Simulationsmodells aus der Echtzeit-Architektur und Überprüfen der zumindest einen Wirkkette und der zumindest einen Echtzeitanforderung;
- Zum Erzeugen von zumindest einer Wirkketten-Spur, Modellieren des Simulationsmodells unter Festlegung von einem Triggerpunkt zum Auslösen der zumindest einen Wirkkette; und
- Auswerten der zumindest einen Wirkketten-Spur basierend auf der zumindest einen Wirkkette mit der zumindest einen Echtzeitanforderung.

Erfindungsgemäß ist außerdem eine Vorrichtung mit Mitteln zur Durchführung der Schritte des Verfahrens angegeben.
Weiter ist erfindungsgemäß ein Computerprogramm angegeben, umfassend Befehle, die bei der Ausführung des Computerprogramms durch einen Computer diesen veranlassen, Schritte des Verfahrens auszuführen. Ein Computerprogramm ist eine Sammlung von Anweisungen zum Ausführen einer bestimmten Aufgabe, die dafür konzipiert ist, eine bestimmte Klasse von Problemen zu lösen. Die Anweisungen eines Programms sind dafür konzipiert, durch einen Computer ausgeführt zu werden, wobei es erforderlich ist, dass ein Computer Programme ausführen kann, damit es funktioniert.
Weiter ist erfindungsgemäß ein Datenträgersignal angegeben, das das Computerprogramm überträgt.
Weiter ist erfindungsgemäß ein computerlesbares Medium angegeben, umfassend Befehle, die bei der Ausführung durch einen Computer diesen veranlassen, Schritte des Verfahrens auszuführen.
Grundidee der vorliegenden Erfindung ist also eine Herleitung der Wirkkette oder Wirkketten und der Echtzeitanforderung(en) aus einer Anforderungsanalyse. Die zumindest eine Wirkkette ist insbesondere im System hinterlegt, bevor das beanspruchte Verfahren ausgeführt wird. Es erfolgt eine Generierung des Simulationsmodells aus der Echtzeit-Architektur und eine automatisierte Überprüfung der im darin Echtzeitanforderung(en) bzw. Wirkkette(n). Die Integrationsarchitektur wird mit der-/denselben Wirkkette(n) bzw. Echtzeitanforderung(en) getestet wie die logische Architektur, wobei für die Integrationsarchitektur weitere Anforderungen definiert werden können. Die Triggerpunkt(e) der Wirkkette(n) ist/sind insbesondere Teil der Systemmodellierung. Damit ist insbesondere auch eine Teststrategie der Echtzeit-Architektur Teil des Modells. Zuletzt erfolgt eine automatisierte Auswertung der eingefahrenen Spure(n), in anderen Worten auch Traces genannt, auf Basis der im Modell hinterlegten Wirkkette(n) bzw. Echtzeitanforderung(en).
In anderen Worten, die Erfindung umfasst eine Darstellung der Wirkketten in einem Tool zur modellbasierten System- bzw. Software-Entwicklung, eine Simulation der Architektur bereits auf logischer Ebene, und eine Integration der Echtzeitanalyse, Echtzeitarchitektur und der Testdefinition in einem Tool zur modellbasierten System- bzw. Software Entwicklung. Dafür wird zum Beispiel eine graphische Beschreibungssprache benutzt, aus der eine Simulation der Echtzeitarchitektur automatisch generiert werden kann. Weiterhin werden die im Tool definierten Wirkketten zur Auswertung der Testdaten, die bei Tests auf der realen Hardware generiert wurden, verwendet.
Der Vorteil dieser Lösung ist, dass der Entwurf und die Darstellung der dynamischen Aspekte Teil des Systemmodells sind. Alle Informationen sind nur einmal im Systemmodell hinterlegt, und es ist keine redundante Datenhaltung nötig. Die Verifikation findet bereits auf der Ebene der logischen Architektur statt. Damit können mögliche Designfehler bereits erkannt werden, bevor die konkrete Architektur ausgearbeitet wird. Da für die Definition der Wirkketten und der Echtzeitarchitektur eine formalisierte Darstellung verwendet wird, kann die Simulation automatisiert aus dem Systemmodell erzeugt werden und gegen die dort hinterlegten Wirkketten und Echtzeitanforderungen getestet werden. Des Weiteren arbeitet der System- bzw. Software-Test mit denselben Wirkketten und Echtzeitanforderungen. Damit ist gewährleistet, dass Design und Test dieselben Ziele abprüft. Wirkketten beschreiben die Kommunikation zwischen Funktionsblöcken und/oder Ausführungseinheiten und sind vergleichbar mit Signalpfaden. In anderen Worten, die Wirkketten beschreiben einen Informationsfluss über verschiedene logische Subsysteme. Die Wirkkette gibt an, welche Elemente an der Funktion beteiligt sind. Die Abarbeitung der Wirkkette muss innerhalb der zumindest einen Echtzeitanforderung erfolgen.
Eine Wirkketten-Spur entspricht dann einer Auswirkung einer Wirkkette auf die verschiedenen logischen Subsysteme. Sie entsteht bei der Umsetzung der Wirkkette in dem System. In anderen Worten, hierbei kann umfasst seine ein Aktion zumindest eines Teils des logischen Subsystems basierend zumindest einem Teilelement der Wirkkette, wie z. B. eine Abarbeitung in Form von Funktionsblöcken und/oder Ausführungseinheiten. Insofern könnte man eine solche Wirkketten-Spur als Visualisierung des letztlichen Ablaufs der Wirkkette verstehen. Insbesondere ein Zeitverhalten von logischen Subsystemen beim Abarbeiten von Funktionsblöcken und/oder Ausführungseinheiten könnte bei einer Wirkketten-Spur untersucht werden. Demnach kann durch Untersuchung einer Wirkkettenspur letztlich festgestellt werden, innerhalb welcher Zeit die Wirkkette im System durchlaufen wird.
Die logische Architektur umfasst die Systemkomponenten, die zur Realisierung der Funktion benötigt werden, z.B. die Algorithmen. Dabei wird noch keine konkrete Zielplatform betrachtet. Es wird z.B. festgelegt, welche logischen Blöcke sequentiell und welche parallel abgearbeitet werden können. Daraus lässt sich später ein Deployment ableiten.
Elemente wie das Betriebssystem oder Softwarekomponenten zur Realisierung der Kommunikation zwischen Prozessor (Central Processing Unit, bzw. abgekürzt: CPU) gehören nicht zur logischen Architektur. Sie werden lediglich dazu benötigt, die logische Architektur auf einen Zielplatform zu integrieren.
Die Integrationsarchitektur implementiert die logischen Komponenten auf einer konkreten Hardware. Hierzu gehört eine Zuweisung der logischen Systemelemente auf Hardware-Ausführungseinheiten, wie z. B. Cores, CPUs, integrierten Schaltkreisen, wie Field Programmable Gate Arrays (FPGAs), oder eine Realisierung der Kommunikationsflüsse zwischen den logischen Komponenten z.B. durch die Implementierung der Inter-Prozess-, Inter-Core-, oder Inter-CPU Kommunikation.
Beispiele für Echtzeit-Anforderungen sind, dass zwischen der Messung eines Signals und der Reaktion dürfen maximal 100ms vergehen, oder dass zwischen der Messung, z.B. bei einer Aufnahme eines Bildes mit einer Kamera, und der Ausgabe der darin enthaltenen Objekte, z. B. Fußgänger oder Autos, maximal 100ms vergehen dürfen.
Das Auswerten der zumindest einen Wirkketten-Spur basierend auf der zumindest einen Wirkkette mit der zumindest einen Echtzeitanforderung erfolgt beispielsweise anhand einer Bewertung, ob die Wirkketten innerhalb eines bestimmten Zeitraums durchgeführt werden, damit die Echtzeitanforderungen erfüllt sind. Für die Auswertung gibt es Tools. Aus dem Modell generiert man Projektdateien für diese Tools, die auswerten. Das Ergebnis ist ein Report, der angibt, ob die Echtzeitanforderungen eingehalten wurden.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass ein Festlegen, mittels einer Anforderungsanalyse, der zumindest einen Wirkkette der Echtzeit-Architektur, erfolgt. Insbesondere wird die Anforderungsanalyse manuell durchgeführt. Das Ergebnis ist eine Echtzeitanforderung für eine bestimmte Funktion. In anderen Worten, Randbedingungen können manuell festgelegt werden. Alternativ oder zusätzlich können Wirkketten aus Analysen mittels Cloud-Computing festgelegt werden.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass das Festlegen der zumindest einen Wirkkette mit der zumindest einen zu erfüllenden Echtzeitanforderung ein Modellieren eines Datenflusses über die logischen Systemelemente umfasst. Hierbei können an die Wirkkette gestellte Anforderungen getestet werden.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass das Überprüfen der zumindest einen Wirkkette und der zumindest einen Echtzeitanforderung ein Überprüfen der logischen Architektur anhand der zumindest einen Wirkkette umfasst. Dies bevorteilt eine Konsistenz zwischen Wirkketten und logischer Architektur.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass das Überprüfen der zumindest einen Wirkkette und der zumindest einen Echtzeitanforderung ein Überprüfen der Integrationsarchitektur anhand der zumindest einen Wirkkette umfasst. Dies bevorteilt eine Konsistenz zwischen den Wirkketten und der Integrationsarchitektur.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass das Modellieren des Simulationsmodells zumindest eine Teststrategie umfasst. Beispielsweise können hiermit verschiedene Situationen in dem Modell geprüft werden.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass die Wirkkette zumindest einen ketteninternen Triggerpunkt zum Auslösen eines Prozesses zumindest einer Teilkette der Wirkkette aufweist. Hiermit kann ein Zeitpunkt oder eine andere Bedingung zum Auslösen der Kette, auch unabhängig von anderen Wirkketten der logischen Architektur, festgelegt werden.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass der Triggerpunkt zum Auslösen der zumindest einen Wirkkette und/oder der ketteninterne Triggerpunkt derart ausgestaltet sind, dass ein durch zumindest einen Teil der Wirkkette definierter Prozess zyklisch ausgelöst wird, wobei der Triggerpunkt bevorzugt ein Zeitgeber ist, oder derart ausgestaltet sind, dass der durch zumindest einen Teil der Wirkkette definierte Prozess nach Ende eines vorangegangenen, durch eine andere Wirkkette definierten Prozesses, ausgelöst wird. Beispielsweise wird die Wirkkette mit Hilfe eines zyklischen Prozesses gestartet, wobei die Zykluszeit insbesondere einen gewissen Jitter umfasst, z.B. mit einer Normalverteilung. Als Jitter bezeichnet man eine zeitliche Schwankung oder einen zeitlichen Offset bezüglich einer festen Periode.
In anderen Worten, es können verschiedene Konnektoren benutzt werden. Ein Kontrollfluss-Konnektor aktiviert einen Prozess. Ein Datenfluss-Konnektor beschreibt, wie Daten über die logischen Systemelemente fließen.
Mit anderen Worten hat die erfindungsgemäße Lösung insbesondere folgende Ziele: Herleitung der Wirkketten und der Echtzeitanforderungen aus einer Anforderungsanalyse, Generierung des Simulationsmodells aus der Echtzeit-Architektur und automatisierte Überprüfung der Echtzeitanforderungen und/oder Wirkketten. Die Integrationsarchitektur wird insbesondere mit den selben Wirkketten und/oder Echtzeitanforderungen getestet wie die logische Architektur, wobei beispielsweise für die Integrationsarchitektur weitere Anforderungen definiert werden können. Die Triggerpunkte der Wirkketten können Teil der Systemmodellierung sein. Insbesondere ist auch ein Testverfahren, das die Teststrategie umfasst, der Echtzeit-Architektur Teil des Modells. Weiterhin wird vorzugsweise eine automatisierte Auswertung der eingefahrenen Traces auf Basis der im Modell hinterlegten Wirkketten und/oder Echtzeitanforderungen ausgeführt.
Der Vorteil dieser Lösung ist insbesondere, dass der Entwurf und die Darstellung der dynamischen Aspekte Teil des Systemmodells sind. Alle Informationen sind vorzugsweise nur einmal im Systemmodell hinterlegt, sodass keine redundante Datenhaltung nötig ist. Eine Verifikation kann bereits auf der Ebene der logischen Architektur stattfinden. Vorteilhafterweise können damit mögliche Designfehler bereits erkannt werden, bevor die konkrete Architektur ausgearbeitet wird. Da für die Definition der Wirkketten und der Echtzeitarchitektur eine formalisierte Darstellung verwendet werden kann, kann die Simulation automatisiert aus dem Systemmodell erzeugt werden und gegen die dort hinterlegten Wirkketten und Echtzeitanforderungen getestet werden. Des Weiteren kann der System/Software-Test mit den selben Wirkketten und Echtzeitanforderungen durgeführt werden. Damit ist gewährleistet, dass das Design und der Test dieselben Ziele abprüfen.
Die Herleitung oder Bestimmung der Wirkketten ist bevorzugt Teil des Systementwurfs. Dabei werden der Datenfluss über die logischen Systemelemente modelliert und die Echtzeitanforderung für den Datenfluss bestimmt (z.B. maximal erlaubte Verzögerung).
Insbesondere muss die Echtzeit-Architektur in der Lage sein, alle Wirkketten in der geforderten Zeit abzuarbeiten. Zentrale Komponenten sind z.B. die logischen Subsysteme, die auch für die Definition der Wirkketten verwendet werden. Die Prozesse können entweder zyklisch (z.B. durch einen Timer) oder von anderen Prozessen aktiviert werden. SysML/UML sind die gängigen Modellierungssprachen, die zur Systembeschreibung verwendet werden könne. Diese Sprachen bieten jedoch keine direkte Unterstützung zur Modellierung einer Echtzeit-Architektur und Wirkketten. Sie müssen durch ein geeignetes Profil weiterentwickelt werden.
Nachfolgend wird die Erfindung unter Bezugnahme auf die anliegende Zeichnung anhand bevorzugter Ausführungsformen näher erläutert. Die dargestellten Merkmale können sowohl jeweils einzeln als auch in Kombination einen Aspekt der Erfindung darstellen. Merkmale verschiedener Ausführungsbeispiele sind übertragbar von einem Ausführungsbeispiel auf ein anderes.
Es zeigt

1 schematisch eine Ausführungseinheit;
2 schematisch eine Architektur von Ausführungseinheiten;
3 ein Flussdiagramm einer ersten Ausführungsform eines erfindungsgemäßen Verfahrens;
4 ein Flussdiagramm einer zweiten Ausführungsform eines erfindungsgemäßen Verfahrens;
5 eine Wirkkette gemäß einem Ausführungsbeispiel und
6 eine Prozessarchitektur auf logischer Ebene gemäß einem Ausfü hru ngsbeispiel.

1 zeigt schematisch eine Ausführungseinheit 11. Die Ausführungseinheit 11 umfasst Funktionsblöcke 12, 13, 14, 15. Der Funktionsblock 12 repräsentiert z.B. das Abgreifen von Ultraschallsensordaten eines Fahrzeugs. Der Funktionsblock 13 repräsentiert z.B. eine digitale Karte, die von einem Fahrzeug generiert und wiederholend aktualisiert wird. Der Funktionsblock 14 repräsentiert z.B. ein Abgreifen von Odometriedaten des Fahrzeugs. Der Funktionsblock 15 repräsentiert z.B. eine Trajektorienplanung des Fahrzeugs. Die Funktionsblöcke 12, 13, 14, 15 umfassen Ausgänge 16 und Eingängen 17, die miteinander verbunden sind. Vorzugsweise sind die Funktionsblöcke 12, 13, 14, 15 sequentiell miteinander verbunden. Das Verbinden der Funktionsblöcke bedeutete, dass ein Funktionsblock von dem Ausgangssignal des anderen Funktionsblocks abhängig ist.
Jedem Funktionsblock wird eine zeitliche Ressource in Form einer Zeit zugeordnet. Beim Ausführen der Funktionsblöcke werden die Zeiten miteinander addiert, um den Rechenaufwand und die dafür benötigte Zeit abzuschätzen.
Die in 1 illustrierten Funktionsblöcke sind lediglich beispielhaft. Eine Ausführungseinheit 11 kann beliebige Funktionsblöcke 12, 13, 14, 15 umfassen.
2 zeigt eine Architektur 18 von Ausführungseinheiten 11, die die Gesamtheit von Fahrerassistenzfunktionen eines Fahrerassistenzsystems erfüllt bzw. abbildet. Die Ausführungseinheiten 11 umfassen Eingänge 20 und Ausgänge 19, wobei die Ausgänge 19 mit den Eingängen 20, wie in 2 gezeigt, verbunden sind. Weiterhin wird festgelegt in welchem zeitlichen Zyklus jeweilige Ausführungseinheiten 11 ausgeführt (aktiviert oder getriggert) werden. Dafür können z.B. Trigger T von der Architektur 18 umfasst sein. Insbesondere wird jede Ausführungseinheit getriggert. Beispielsweise wird zumindest eine Ausführungseinheit 11 mit Hilfe des Konnektors 21 getriggert. Weiterhin kann eine Ausführungseinheit 11 mit einem Trigger T und einem Konnektor 21 getriggert werden. Beispielsweise wird dem Konnektor 21 eine Verzögerungszeit zugeordnet, die für das Triggern benötigt wird.
Die 3 zeigt ein Flussdiagramm einer ersten Ausführungsform eines erfindungsgemäßen Verfahrens.
Es wird ein Verfahren zum Modellieren von Anforderungen für elektrische Fahrzeugkomponenten vorgeschlagen.
In einem ersten Schritte S1 werden die Funktionsblöcke 12, 13, 14, 15 für Basisunktionen eines Fahrerassistenzsystems festgelegt. In einem Schritt S2 werden zeitliche Ressourcen zu den Funktionsblöcken 12, 13, 14, 15 zugeordnet. In einem Schritt S3 werden die Funktionsblöcke 12, 13, 14, 15 zu den Ausführungseinheiten 11 gruppiert. In einem Schritt S4 wird eine Architektur 18 von den Ausführungseinheiten 11, die die Gesamtheit der Fahrerassistenzfunktionen des Fahrerassistenzsystems darstellt erstellt. Dabei wird festgelegt, in welchem zeitlichen Zyklus die jeweilige Ausführungseinheiten 11 ausgeführt werden. In einem Schritt S5 werden Abfolgen von Funktionsblöcken 12, 13, 14, 15 einer jeweiligen Ausführungseinheit 11 zu jeder Fahrerassistenzfunktion zugewiesen. In einem Schritt S6 werden alle Abfolgen ausgeführt und eine dafür benötigte Zeit, insbesondere automatisch, ermittelt.
In einem Schritt S7 wird die benötigten Zeit mit einer vorgegebenen Echtzeitanforderung verglichen. Die Echtzeitanforderungen werden aus Anforderungen an ein Fahrzeug ermittelt. Beispielsweise gibt es die Anforderung an einen Notbremsassistenten, dass bei gewissen Geschwindigkeiten des Fahrzeugs ein gewisser Bremsweg unterschritten werden muss. Daraus lässt sich ableiten, ob die Architektur 18 die Echtzeitanforderungen einhalten kann oder nicht.
Die in den 1 bis 3 beschriebenen Merkmale sind beispielsweise unabhängig von den in 3 bis 6 beschriebenen Merkmalen. Alternativ sind die Merkmale beispielsweise miteinander Verknüpft zu verstehen.
Die 4 zeigt ein Flussdiagramm eines erfindungsgemäßen Verfahrens.
Das Verfahren ist geeignet für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung.
Die Echtzeit-Architektur weist auf: eine Laufzeitschicht mit einer logischen Architektur zur Aufteilung von auszuführenden Operationen auf logische Systemelemente einer Hardware-Schicht und auf logische Systemelemente zumindest einer Software-Schicht; eine Integrationsarchitektur zum Zuordnen von den logischen Systemelementen zu der Hardware-Schicht, zu der Laufzeitschicht und zu der zumindest einen Software-Schicht; und zumindest eine Wirkkette 1 zum Auslösen einer Aktion in einem Fahrzeug basierend auf einer Sensormessung oder einer Eingabe eines Fahrers.
Die zumindest eine Wirkkette 1 ist zur Erfüllung zumindest einer Echtzeitanforderung ausgestaltet.
Das Verfahren weist folgende Verfahrensschritte auf:
Gemäß einem Schritt „100“ ist das Generieren eines Simulationsmodells aus der Echtzeit-Architektur vorgesehen. Gemäß einem Schritt „200“ ist das Überprüfen der zumindest einen Wirkkette 1 und der zumindest einen Echtzeitanforderung E vorgesehen.
Gemäß einem Schritt „300“ ist vorgesehen, dass zum Erzeugen von zumindest einer Wirkketten-Spur, ein Modellieren des Simulationsmodells unter Festlegung von einem Triggerpunkt zum Auslösen der zumindest einen Wirkkette 1 erfolgt.
Zuletzt erfolgt gemäß einem Schritt „400“ das Auswerten der zumindest einen Wirkketten-Spur basierend auf der zumindest einen Wirkkette 1 mit der zumindest einen Echtzeitanforderung E.
Die Herleitung der Wirkkette 1 ist Teil des Systementwurfs. Dabei wird der Datenfluss über die logischen Systemelemente modelliert und die Echtzeitanforderung E für den Datenfluss bestimmt. Eine solche Echtzeitanforderung E kann z.B. eine maximal erlaubte Verzögerung definieren. In 5 ist ein Ausführungsbeispiel für eine Wirkkette 1 gezeigt, bei der ein Sensor 2 ein Umwelt-Ereignis U erfasst. Die Messsignale des Sensors 2 werden dann innerhalb des systeminternen Wirkkettenteils 1a prozessiert. Hierbei kann beispielsweise eine Weiterleitung des Signals an eine Schnittstelle 3 erfolgen. Die Schnittstelle 3 leitet das Signal dann wiederum an logische Subsystemkomponenten 4a bis 4c weiter. Diese wiederum leiten das Signal dann an ein LAN-Übertragungsmedium 5 weiter. Das Prozessieren und das Weiterleiten des Signals innerhalb der Wirkkette 1 muss unter Erfüllung der zumindest einen Echtzeitanforderung E erfolgen.
In 6 ist eine Prozessarchitektur 10 auf logischer Ebene gemäß einem Ausführungsbeispiel gezeigt. Hierbei sind eine Vielzahl von Wirkketten vorgesehen, welche durch Trigger T innerhalb von Zeitspannen t1 bis t10 ausgelöst oder prozessiert werden können.
Die Echtzeitarchitektur 10 muss in der Lage sein, alle Wirkketten 1 in der geforderten Zeit abzuarbeiten. Zentrale Komponenten sind die logischen Subsysteme, die auch für die Definition der Wirkketten 1 verwendet werden. Die Prozesse können entweder zyklisch, z.B. durch einen Timer, oder von anderen Prozessen aktiviert werden. SysML bzw. UML sind mögliche, verwendbare Modellierungssprachen zur Systembeschreibung. Diese Sprachen bieten keine direkte Unterstützung zur Modellierung einer Echtzeit-Architektur und Wirkketten. Sie müssen durch ein geeignetes Profil erweitert werden.
Gemäß einem Ausführungsbeispiel muss das Profil die folgenden Anforderungen erfüllen: Definition von Trigger Elementen zur zyklischen Steuerung von Tasks bzw. Funktionsblöcken und/oder Ausführungseinheiten; Definition von Task Elementen mit und ohne Funktionsblöcken und/oder Ausführungseinheiten; Definition von Konnektoren zur Aktivierung von Prozessen bzw. Funktionsblöcken und/oder Ausführungseinheiten. Die Konnektoren können z.B. eine Verzögerung der Aktivierung des nächsten Tasks enthalten, wenn dieser z.B. auf einem anderen Prozessorkern (Core von einer CPU) läuft. So können Effekte wie die Intercore-Kommunikation berücksichtigt werden; Definition von Konnektoren zu Modellierung von Datenflüssen zwischen Prozessen. Datenflüsse können definieren, wie lange ein Datenfluss zwischen zwei Prozesse maximal dauern kann. Damit kann z.B. der Einfluss einer Intercore- bzw. Inter-CPU-Kommunikation modelliert werden.
Bezugszeichenliste

1: Wirkkette
1a: systeminterner Wirkkettenteil
2: Sensor
3: Schnittstelle
4a-4c: logische Subsystemkomponente
5: LAN-Übertragungsmedium
10: Prozessarchitektur
11: Ausführungseinheit
12: Funktionsblock
13: Funktionsblock
14: Funktionsblock
15: Funktionsblock
16: Ausgang
17: Eingang
18: Architektur
19: Ausgang
20: Eingang
21: Konnektor
100: Generieren eines Simulationsmodells aus der Echtzeit-Architektur
200: Überprüfen der zumindest einen Wirkkette und der zumindest einen Echtzeitanforderung
300: zum Erzeugen von zumindest einer Wirkketten-Spur, ein Modellieren des Simulationsmodells unter Festlegung von einem Triggerpunkt zum Auslösen der zumindest einen Wirkkette
400: Auswerten der zumindest einen Wirkketten-Spur basierend auf der zumindest einen Wirkkette mit der zumindest einen Echtzeitanforderung
E: Echtzeitanforderung
T: Trigger
U: Umwelt-Ereignis
t1-t10: Zeitspanne
S1: Schritt
S2: Schritt
S3: Schritt
S4: Schritt
S5: Schritt
S6: Schritt
S7: Schritt

Claims

Verfahren zum Modellieren von Anforderungen für elektrische Fahrzeugkomponenten mit den Schritten: a) Festlegen (S1) von Funktionsblöcken (12, 13, 14, 15) für Basisunktionen eines Fahrerassistenzsystems, b) Zuordnen (S2) von zeitlichen Ressourcen zu den Funktionsblöcken (12, 13, 14, 15), gekennzeichnet durch c) Gruppieren (S3) der Funktionsblöcke (12, 13, 14, 15) zu Ausführungseinheiten (11), d) Erstellen (S4) einer Architektur (18) von Ausführungseinheiten (11), die eine Gesamtheit von Fahrerassistenzfunktionen eines Fahrerassistenzsystems darstellt, wobei festgelegt wird in welchem zeitlichen Zyklus die jeweilige Ausführungseinheiten (11) ausgeführt werden, e) Zuweisen (S5) von Abfolgen von Funktionsblöcken (12, 13, 14, 15) einer jeweiligen Ausführungseinheit (11) zu jeder Fahrerassistenzfunktion, f) Ausführen (S6) aller Abfolgen und Ermitteln einer dafür benötigten Zeit, und g) Vergleichen (S7) der benötigten Zeit mit einer vorgegebenen Echtzeitanforderung.
Verfahren nach Anspruch 1, wobei die Abfolge von Funktionsblöcken (11, 12, 13, 14) in einer Ausführungseinheit (11) sequenziell erfolgt.
Verfahren nach Anspruch 1 oder 2, wobei Schritt d) ein logisches Verschalten von Eingängen (20) und Ausgängen (19) der Ausführungseinheiten (11) umfasst.
Verfahren nach einem der Ansprüche 1 bis 3, wobei der festgelegte zeitliche Zyklus zumindest einer Ausführungseinheit (11) aus Schritt d) und/oder die zeitliche Ressource zumindest eines Funktionsblocks (12, 13, 14, 15) und/oder die Architektur von Ausführungseinheiten (11) und/oder die Zuweisung der Abfolge der Funktionsblöcke (12, 13, 14, 15) geändert wird, insbesondere wenn in Schritt g) die benötigten Zeit größer als die vorgegebenen Echtzeitanforderung ist.
Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung, wobei die Echtzeit-Architektur aufweist: eine Laufzeitschicht mit einer logischen Architektur zur Aufteilung von auszuführenden Operationen auf logische Systemelemente einer Hardware-Schicht und auf logische Systemelemente zumindest einer Software-Schicht; eine Integrationsarchitektur zum Zuordnen von den logischen Systemelementen zu der Hardware-Schicht, zu der Laufzeitschicht und zu der zumindest einen Software-Schicht; und zumindest eine Wirkkette (1) zum Auslösen einer Aktion in einem Fahrzeug basierend auf einer Sensormessung oder einer Eingabe eines Fahrers, wobei die zumindest eine Wirkkette (1) zur Erfüllung zumindest einer Echtzeitanforderung ausgestaltet ist; das Verfahren aufweisend folgende Verfahrensschritte: • Generieren eines Simulationsmodells aus der Echtzeit-Architektur (100) und Überprüfen der zumindest einen Wirkkette (1) und der zumindest einen Echtzeitanforderung (E) (200); • Zum Erzeugen von zumindest einer Wirkketten-Spur, Modellieren des Simulationsmodells unter Festlegung von einem Triggerpunkt zum Auslösen der zumindest einen Wirkkette (1) (300); und • Auswerten der zumindest einen Wirkketten-Spur basierend auf der zumindest einen Wirkkette (1) mit der zumindest einen Echtzeitanforderung (E) (400).
Verfahren nach Anspruch 5, wobei zumindest eine Wirkkette (1) vor dem Generieren des Simulationsmodells festgelegt wird, wobei das Festlegen der zumindest einen Wirkkette (1) mit der zumindest einen zu erfüllenden Echtzeitanforderung (E) ein Modellieren eines Datenflusses über die logischen Systemelemente umfasst.
Verfahren nach Anspruch 5 oder 6, wobei das Überprüfen der zumindest einen Wirkkette (1) und der zumindest einen Echtzeitanforderung (E) (200) ein Überprüfen der logischen Architektur anhand der zumindest einen Wirkkette (1) umfasst.
Verfahren nach einem der Ansprüche 5 bis 6, wobei das Überprüfen der zumindest einen Wirkkette (1) und der zumindest einen Echtzeitanforderung (E) (200) ein Überprüfen der Integrationsarchitektur anhand der zumindest einen Wirkkette (1) umfasst.
Verfahren nach einem der Ansprüche 5 bis 8, wobei das Modellieren des Simulationsmodells (300) zumindest eine Teststrategie umfasst.
Verfahren nach einem der Ansprüche 5 bis 9, wobei die Wirkkette (1) zumindest einen ketteninternen Triggerpunkt zum Auslösen eines Prozesses zumindest einer Teilkette der Wirkkette (1) aufweist.
Verfahren nach einem der Ansprüche 5 bis 10, wobei der Triggerpunkt zum Auslösen der zumindest einen Wirkkette (1) und/oder der ketteninterne Triggerpunkt derart ausgestaltet sind, dass ein durch zumindest einen Teil der Wirkkette (1) definierter Prozess zyklisch ausgelöst wird, wobei der Triggerpunkt bevorzugt ein Zeitgeber ist, oder derart ausgestaltet sind, dass der durch zumindest einen Teil der Wirkkette (1) definierte Prozess nach Ende eines vorangegangenen, durch eine andere Wirkkette (1) definierten Prozesses, ausgelöst wird.
Vorrichtung zur Durchführung mindestens eines Schritts des Verfahrens nach mindestens einem der vorgenannten Ansprüche.
Computerprogramm, umfassend Befehle, die bei der Ausführung des Computerprogramms durch einen Computer diesen veranlassen, ein Verfahren nach mindestens einem der vorgenannten Ansprüche auszuführen.
Datenträgersignal, das das Computerprogramm nach dem vorgenannten Anspruch überträgt.
Computerlesbares Medium, umfassend Befehle, die bei der Ausführung durch einen Computer diesen veranlassen, ein Verfahren nach mindestens einem der vorgenannten Ansprüche auszuführen.