Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
DATA STRUCTURE FOR AN EMBEDDED SYSTEM, CORRESPONDING SYSTEM AND VEHICLE
Document Type and Number:
WIPO Patent Application WO/2020/182607
Kind Code:
A1
Abstract:
The invention relates to a data structure (10) for an embedded system (20), characterized by the following features: a typified static memory pool (11) for storing a plurality of data objects (12), an allocator (13) having a first pointer (14) pointing to the memory pool (11), and a pointer object (15) having a second pointer (16) pointing to the allocator (13).

Inventors:
BAUMGAERTNER RAINER (DE)
KOPP MICHAEL (DE)
DIZIOL RAPHAEL (DE)
Application Number:
PCT/EP2020/055842
Publication Date:
September 17, 2020
Filing Date:
March 05, 2020
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
BOSCH GMBH ROBERT (DE)
International Classes:
G06F9/54
Domestic Patent References:
WO2017095367A12017-06-08
WO2018146000A12018-08-16
Foreign References:
US20050149903A12005-07-07
Download PDF:
Claims:
Ansprüche

1. Datenstruktur (10) für ein eingebettetes System (20),

gekennzeichnet durch folgende Merkmale:

- einen typisierten statischen Speicherpool (11) zum Speichern mehrerer Daten-Objekte (12),

- einen Allokator (13) mit einem auf den Speicherpool (11) weisenden ersten Zeiger (14) und

- ein Zeigerobjekt (15) mit einem auf den Allokator (13) weisenden

zweiten Zeiger (16).

2. Datenstruktur (10) nach Anspruch 1,

gekennzeichnet durch folgende Merkmale:

- das Zeigerobjekt (15) ist ein durch mehrere Prozesse des Systems (20) gemeinsam nutzbarer intelligenter Zeiger und

- das Zeigerobjekt (15) umfasst ferner einen auf Referenzzähler der Objekte (12) verweisenden dritten Zeiger (17).

3. Datenstruktur (10) nach Anspruch 1 oder 2,

gekennzeichnet durch folgendes Merkmal:

- der erste Zeiger (14), zweite Zeiger (16) und dritte Zeiger (17) sind verschieblich.

4. Datenstruktur (10) nach Anspruch 3,

gekennzeichnet durch folgendes Merkmal:

- die Prozesse sind Zwischenanwendungen. 5. Eingebettetes System (20) für ein Fahrzeug (30),

gekennzeichnet durch folgende Merkmale:

- das System (20) umfasst einen gemeinsam nutzbaren Speicherbereich zum Austauschen einer Nachricht (18) zwischen den

Zwischenanwendungen und

- der Speicherbereich weist eine Datenstruktur (10) nach Anspruch 4 auf.

6. System (20) nach Anspruch 5,

gekennzeichnet durch folgende Merkmale:

- das System (20) ist dazu eingerichtet, aufgrund einer

Streckenprognose (21) und Sensordatenfusion (22) ein Umfeld (23) des Fahrzeuges (30) zu modellieren und

- der Speicherbereich ist dazu eingerichtet, einen Zustand (24) des

Umfeldes (23) festzuhalten.

7. System (20) nach Anspruch 6,

gekennzeichnet durch folgendes Merkmal:

- das System (20) ist dazu eingerichtet, mittels der Datenstruktur (10) weitere Verkehrsteilnehmer im Umfeld (23) des Fahrzeuges (30) zu verwalten.

8. System (20) nach Anspruch 7,

gekennzeichnet durch folgendes Merkmal:

- das System (20) ist dazu eingerichtet, die Verkehrsteilnehmer verschiedenen Fahrspuren im Umfeld (23) des Fahrzeuges (30) zuzuordnen.

9. System (20) nach einem der Ansprüche 6 bis 8,

gekennzeichnet durch folgende Merkmale:

- das System (20) umfasst ein Gateway (25) mit einem

kraftfahrzeugtechnischen Betriebssystem (26) und

- das Gateway (26) ist dazu eingerichtet, den Zustand (24) in einem

externen Archiv (27) aufzuzeichnen.

10. Fahrzeug (30) mit einem System (20) nach Anspruch 9.

Description:
Beschreibung

Titel

Datenstruktur für ein eingebettetes System, entsprechendes System und

Fahrzeug

Die vorliegende Erfindung betrifft eine Datenstruktur für ein eingebettetes System. Die vorliegende Erfindung betrifft darüber hinaus ein entsprechendes Fahrzeug sowie ein entsprechendes System.

Stand der Technik

Der Begriff des hochautomatisierten Fahrens {highly automated driving, HAD) bezeichnet gemeinhin eine Entwicklungsstufe zwischen dem assistierten Fahren, bei welchem der Fahrer durch zahlreiche (oft getrennte) Fahrerassistenzsysteme bei der Fahraufgabe unterstützt wird, und dem autonomen Fahren, bei welchem das Fahrzeug gänzlich selbsttätig und ohne Einwirkung des Fahrers fährt. Beim hochautomatisierten Fahren verfügt das Fahrzeug gewissermaßen über eine eigene Intelligenz, die vorausplant und die Fahraufgabe zumindest in den meisten Situationen übernehmen könnte. Fahrer und Steuergeräte ( electronic control units, ECUs) führen zusammen das Fahrzeug, wobei der menschliche Fahrer jederzeit bestimmt, wie stark er in das Fahrverhalten des Fahrzeuges eingreift.

W02018146000A1 offenbart ein Steuergerät für ein Kraftfahrzeug, das eingerichtet ist, mehrere Anwendungen und

Zwischenanwendungen ( middleware ) zu betreiben und einen durch die

Anwendungen und Zwischenanwendungen gemeinsam nutzbaren Speicher umfasst. Die Zwischenanwendungen sind eingerichtet, eine

Interprozesskommunikation zwischen den Anwendungen über den Speicher abzuwickeln. Offenbarung der Erfindung

Die Erfindung stellt eine Datenstruktur für ein eingebettetes System, ein entsprechendes Fahrzeug sowie ein entsprechendes System gemäß den unabhängigen Ansprüchen bereit.

Der erfindungsgemäße Ansatz fußt hierbei auf der Erkenntnis, dass zahlreiche Fahrerassistenzsysteme für hochautomatisiertes Fahren aktuell in der

Entstehungsphase sind. Einschlägige Ansätze basieren auf Middleware- zentrischen Umsetzungen in Multi- ECU-, Multiprozessor- oder Multiprozess- Topologien. Dabei werden - wie im Falle des Steuergerätes gemäß

W02018146000A1 - Datenstrukturen über die Middleware versendet. Aus Effizienzgründen sollten diese Datenstrukturen innerhalb eines Prozessors zwischen einzelnen Prozessen mit unterschiedlichen logischen Adressräumen geteilt werden können, ohne eine tiefe Kopie ( deep copy ) anzufertigen. Zur Abbildung komplexer Datenstrukturen mit statischer Speicherallokation zwischen Prozessen können hierzu sogenannte relokatierbare, also verschiebliche Zeiger ( relocatable pointers) verwendet werden.

Die vorgeschlagene Lösung trägt ferner dem Umstand Rechnung, dass zusätzlich der interne Zustand von Prozessen (z. B. der Zustand eines Kalman- Filters) messbar sein sollte, um Fehler im Serienbetrieb exakt reproduzieren zu können. Hierzu kann der interne Zustand explizit modelliert werden. Interne Zustände basieren auf komplexen Datenstrukturen. Diese Anforderungen werden von Middleware-basierten Systemen nach dem Stand der Technik, insbesondere bei statischer Allokation, kaum unterstützt.

Da im Bereich des hochautomatisieren Fahrens die Realität möglichst exakt abgebildet werden sollte, stellt diese Anwendung im Vergleich zu klassischen Fahrerassistenzsystemen erhöhte Anforderungen an die verwendeten

Algorithmen und erhöht somit gleichermaßen Komplexität und Umfang der zu verwendenden Datenstrukturen. Moderne Programmierparadigmen wie z. B. „Ressourcenbelegung ist Initialisierung“ ( resource acquisition is initialization,

RAM) helfen dabei, Komplexität und somit Fehleranfälligkeit des Programmcodes deutlich zu reduzieren. Derartige Paradigmen verfolgen das Ziel, die fehleranfällige Speicherallokation und -Freigabe nicht dem Programmierer zu überlassen, sondern durch den impliziten Aufruf eines Destruktors der jeweiligen Klasse durchführen zu lassen. Im Gegensatz zu anderen Mechanismen wie automatischer Speicherbereinigung ( garbage collection) ist die Laufzeit des resultierenden Programmes deterministisch, was einen Vorteil für

sicherheitsrelevante Systeme darstellt.

Der nachfolgend beschriebene Ansatz erkennt ferner, dass solcherlei

Mechanismen, wie sie in den Standards C++11 und C++14 in Gestalt der Datentypen std::unique_ptr, std::shared_ptr und std::weak_ptr verankert sind, zur Komplexitätsreduktion im Quellcode zwar grundsätzlich in Betracht kommen. Allerdings sind derartige Umsetzungen aus unterschiedlichsten Gründen nicht für den sicherheitsrelevanten Einsatz geeignet: So beruhen sie zunächst auf dynamischer Speicherallokation auf dem Frei- oder Haldenspeicher ( heap ), was die in Echtzeitsystemen erforderliche Vorhersage des Laufzeitverhaltens erschwert; sie können zudem zwischen unterschiedlichen Prozessen nicht ohne zusätzlichen Aufwand für Serialisierung und Verwaltung ausgetauscht oder zur Verwaltung interner Systemzustände verwendet werden.

Ein Vorzug der erfindungsgemäßen Lösung besteht vor diesem Hintergrund darin, es durch die Einführung spezieller Umsetzungen der besagten intelligenten Zeiger {smart pointers) zu ermöglichen, moderne Programmierparadigmen auch in sicherheitsrelevantem Umfeld und speziell in eingebetteten ( embedded) Systemen effizient einzusetzen. Dies wiederum ermöglicht die Implementierung komplexer Algorithmen mittels vergleichsweise einfachem Quellcode, der - bei geeigneter Strukturierung - eine hohe Verständlichkeit und Wartbarkeit aufweisen kann.

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 kann eine gemeinsame Nutzung des erfindungsgemäßen Zeigerobjektes durch mehrere

Zwischenanwendungen vorgesehen sein. Diese Umsetzung der Erfindung ermöglicht deren effizienten Einsatz zur Middleware-zentrierten

Datenkommunikation und Messung interner Zustände. Stellvertretend für alle besagten Varianten intelligenter Zeiger sei dieser Ansatz nunmehr stellvertretend anhand eines gemeinsam nutzbaren Zeigers ( shared pointer) erläutert.

Kurze Beschreibung der Zeichnungen

Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:

Figur 1 die Veranschaulichung eines erfindungsgemäß gemeinsam genutzten Zeigers.

Figur 2 schematisch die Verwendung der Shared Pointer in internen Zuständen und zum Datenaustausch.

Ausführungsformen der Erfindung

Figur 1 illustriert einen typisierten statischen Speicherbereich (11) des exemplarischen Typs„TFixedMemoryPool“, in welchem Objekte (12) eines beliebigen Typs angelegt werden können. Zusätzlich ist ein Allokator (13) vorgesehen, der es einem gemeinsam genutzten, gleichsam intelligenten Zeigerobjekt (15) ermöglicht, Objekte (12) in diesem Speicherpool (11) anzulegen. Dieser Shared Pointer (15) verweist auf den Allokator (13), der seinerseits den besagten Speicherpool (11) referenziert. Zusätzlich wird in einem statischen Speicherplatz Speicher für Referenzzähler ( reference counters) vorgehalten. Vorzugsweise ist dieser Speicherplatz eng mit dem

Speicherpool (11) verbunden, da jedem Daten-Objekt (12) jeweils ein

Referenzzähler zugeordnet ist und die Anzahl der Referenzzähler des gemeinsam genutzten Zeigers (15) somit dem Umfang des Speicherpools (11) entspricht. Im Falle eines sogenannten schwachen Zeigers {weak pointer) ist vorzugsweise eine anwendungsabhängige Maximalanzahl vorzugeben. Wenn die Bezugnahme auf unterschiedliche Objekte vorteilhafterweise durch

Relocatable Pointer erfolgt, ist eine vom logischen Adressraum unabhängige Abbildung möglich. Ohne Relocatable Pointer ist die Realisierung in der statisch allokierten Datenstruktur (10) zwar denkbar, jedoch nicht ohne Weiteres deren Versand durch die Middleware über logische Adressräume hinweg.

Ein maßgeblicher Unterschied dieses Ansatzes beispielsweise zu dem von der C++-Standardbibliothek umfassten std::shared_ptr liegt in der Möglichkeit, die vom gemeinsam genutzten Zeiger (15) referenzierten Daten-Objekte (12) in statischen Speicherbereichen ablegen zu können. Vorzugsweise unter Nutzung verschieblicher Zeiger ist somit auch ein Versenden in unterschiedliche logische Adressräume möglich. Besonderes Augenmerk kommt dabei dem

Referenzcounter zu, da letzterer herkömmlicherweise auf dem Heap angelegt wird. Diese Vorgehensweise führt bei eingebetteten Systemen und insbesondere dem Versand über die Middleware zu zahlreichen Problemen. Diese Vorteile gegenüber dem besagten std::shared_ptr werden im nachfolgend beschriebenen Anwendungsfall deutlich.

Da ein erfindungsgemäßer Shared Pointer (15) seine Daten (12) und

Referenzcounter in einem zusammenhängenden Speicherbereich verwaltet

- z. B. innerhalb einer einzelnen Nachricht (18) in einem für Nachrichten zwischen Prozessen gemeinsam genutzten Speicher -, kann der interne Zustand einer Applikation vorteilhafterweise durch flache Kopie {shallow copy) in eine

- den betreffenden Shared Pointer (15) einschließende - Nachricht (18) an andere Teilnehmer im System (20) überführt werden.

Wenn diese Nachricht (18) von einem Sender an mehrere Empfänger übertragen wird, darf auf Sender- und Empfängerseite kein Shared Pointer (15) desselben Typs verwendet werden, da der Empfänger nur lesend auf den

Nachrichtenspeicher (18) zugreifen sollte. Andernfalls wäre zu befürchten, dass bei weiteren Referenzen auf Empfängerseite der Referenzcounter verändert und somit im schlimmsten Fall ein Objekt (12) aus dem ausschließlich zum Lesen vorgesehenen Speicherpool (11) entfernt werden würde. Um dies zu verhindern ist es vorteilhaft, den Shared Pointer (15) auf Empfängerseite in einen

Relocatable Pointer umzuwandeln. Die Freigabe der Objekte (12) erfolgt dann vorzugsweise erst durch Freigabe der kompletten empfangenen Nachricht (18) selbst. Durch einen erfindungsgemäßen Shared Pointer (15) ist es also möglich, moderne Programmierparadigmen auf den Bereich des hochautomatisierten Fahrens anzuwenden und komplexe Sachverhalte mittels einer vergleichsweise einfachen Datenstruktur (10) auszudrücken. Der Shared Pointer (15) erlaubt es zudem, komplexe Datenstrukturen statisch zu realisieren. Auf Basis des

Relocatable Pointers ermöglicht es der Shared Pointer (15), interne Zustände messbar und anderen Prozessen durch einen Nachrichtenaustausch effizient zugänglich zu machen.

Figur 2 zeigt beispielhaft eine Verwendung des Shared Pointers (15 - Figur 1), um erkannte Verkehrsteilnehmer und andere Objekte in ein Umfeld-Modell (23) einzutragen und weiterzugeben. Shared Pointer (15) verweisen dabei von einzelnen Kanten des Kartengraphen auf die erkannten Objekte. Bewegt sich das Ego- Fahrzeug (30) vorwärts, dann werden neue Kanten hinzugefügt und nicht länger benötigte Kanten entfernt. Bei diesem Entfernen hinfälliger

Kartenelemente werden automatisch die verknüpften Objekte freigegeben, sobald alle Shared Pointer (15), die auf das jeweilige Objekt zeigen, zerstört wurden. Eine Ausführungsform der Erfindung gestattet eine statische Allokierung derartiger Strukturen (10 - Figur 1) und somit die Weitergabe des Umfeld- Modells (23) ohne tiefe Kopie. Als Empfänger kommen vorzugsweise andere Middleware-Prozesse, aber auch messtechnische Einrichtungen in Betracht.