[go: up one dir, main page]

WO2018146000A1 - Steuergerät für ein kraftfahrzeug und entsprechendes kraftfahrzeug - Google Patents

Steuergerät für ein kraftfahrzeug und entsprechendes kraftfahrzeug Download PDF

Info

Publication number
WO2018146000A1
WO2018146000A1 PCT/EP2018/052568 EP2018052568W WO2018146000A1 WO 2018146000 A1 WO2018146000 A1 WO 2018146000A1 EP 2018052568 W EP2018052568 W EP 2018052568W WO 2018146000 A1 WO2018146000 A1 WO 2018146000A1
Authority
WO
WIPO (PCT)
Prior art keywords
applications
control device
motor vehicle
following features
application
Prior art date
Application number
PCT/EP2018/052568
Other languages
English (en)
French (fr)
Inventor
Rainer Baumgaertner
Michael Poehnl
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 CN201880010747.1A priority Critical patent/CN110291504B/zh
Publication of WO2018146000A1 publication Critical patent/WO2018146000A1/de

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; 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/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes

Definitions

  • the present invention relates to a control device for a motor vehicle.
  • the present invention also relates to a corresponding motor vehicle and a corresponding method.
  • HAD highly automated driving
  • vehicle has its own intelligence, so to speak, which could plan ahead and take over the driving task, at least in most situations.
  • ECUs electronice control units
  • US 2013/0145482 AI describes a vehicle that has one or more
  • Implemented processing modules are configured to connect to the various buses in the vehicle with the various buses connected to the various components of the vehicle to facilitate information transfer between the vehicles
  • Each processing module is further modularized with the ability to add and replace other functional modules now or in the future. These function modules can themselves as independent vehicle components act. Each processing module can handle processing to other modules depending on its health,
  • US 2007/076593 A1 discloses a vehicle control system having a plurality of nodes connected to a communication network for performing coordinated operations based on data sent over the communication network for controlling the vehicle, each of the nodes comprising: a node status Determination section that receives node status data from other nodes via the communication network and determines node status indicating one or more of a failure state and a non-failure state of the plurality of nodes, a node status evaluation result transmission / reception section for transmitting
  • the invention provides a control device for a motor vehicle and a
  • the approach according to the invention is based on the finding that numerous driver assistance systems for highly automated driving are currently in the development phase.
  • the realization requires the mastery of large systems. Especially the distribution of subtasks to different ones
  • Services layer eliminates unnecessary copying of data or blocking of applications and thus proves to be highly efficient.
  • CE Consumer electronics
  • Access to the shared memory are authorized. It is particularly advantageous that the solution contains a flexible method for separation. The efficiency of the realization is largely maintained.
  • control device further comprises a memory management unit (MMU) to perform the separation.
  • MMU memory management unit
  • the applications access the intermediate applications via an intermediate application interface, which in turn has standardized interfaces
  • Microcontroller abstraction layer Complex drivers or other services of the base software access.
  • the traffic is thus completely abstracted by the service layer. Even a distribution of applications to different ECUs is possible, provided that latency and quality of service can be guaranteed.
  • Operating system such as QNX be provided for the controller.
  • said separation between applications may be through adaptive partitioning (AP) of the application software.
  • AP adaptive partitioning
  • An appropriate scheduler allows the designer of the real-time system to specify that a certain amount of processing resources be reserved for a particular partition - that is, a group of activity threads or threads that make up a subsystem.
  • FIG. 1 shows an inter-application-oriented approach according to FIG. 1
  • FIG. 2 shows the data traffic between control units by means of a
  • FIG. 3 shows the control unit-internal data traffic by means of the service layer according to the invention.
  • FIG. 4 shows a solution strategy for using shared memory in the context of an efficient intermediate application approach
  • FIG. 5 Basics of the separation.
  • FIG. 6 shows the effect of the separation in connection with FIG.
  • Figure 7 shows a solution strategy for inter-process communication while maintaining the separation of areas with different security requirements.
  • FIG. 8 shows the inter-process communication via shared memory while maintaining the separation of areas with different ones
  • Figure 1 illustrates an inter-application approach according to the proposed solution strategy.
  • Applications (11) use the application programming interface (API) here special intermediate applications (12).
  • API application programming interface
  • Data traffic is handled exclusively via the intermediate applications (12), which enables portability, scalability and reusability, data encapsulation, etc.
  • Such an approach could be, for example, within the framework of a future definition
  • AUTOSAR adaptive and open automotive system architecture
  • FIG. 2 illustrates the data traffic between control devices by means of a service layer according to the invention.
  • Each control unit (10) operates the specific one in addition to the AU TOS AR basic software (15)
  • the basic software (15) includes
  • the intermediate applications (12) of the service layer while the application software (14) comprises the individual applications (11) in the strict sense.
  • the application software (14) comprises the individual applications (11) in the strict sense.
  • the intermediate application interface (13) accesses the intermediate applications (12), the latter in turn access the operating system (17), data connection (18), control device abstraction layer (19), microcontroller abstraction layer (20), complex drivers (21) or others via standardized interfaces (16) Services of the basic software (15) too.
  • FIG. 3 shows, in a corresponding representation, the data traffic by means of the service layer according to the invention within a single one
  • Interprocess communication (29) is controlled by selected elements
  • FIG. 4 illustrates a solution strategy for using shared memory (23) in the context of the approach discussed.
  • the control unit (10) comprises such by various applications (11) and
  • the latter are in this case subject to the same security requirements imposed by a common Automotive safety integrity level (ASIL) designated A, B, C, D or QM. (This given
  • Safety requirement level carries the following representative
  • control unit (10) comprises a memory management unit-not shown as such.
  • a corresponding operating system (17) such as QNX whose microkernel supports the runtime separation (25) by an adaptive partitioning of the application software (14).
  • Execution strands (24) within a process can not be easily separated in this way.
  • Intermediate application (31) operates on said security requirement level (X), some applications (11) access a second intermediate application of lesser security requirement level (Y). Those applications (11) which access both the first intermediate application (31) and the second intermediate application (32) serve at the same time as
  • Security level operated and correspondingly privileged application A also acts as a safety limiter (27) for cross-sector access to the memory (23) by means of the second intermediate application (32).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Steuergerät (10) für ein Kraftfahrzeug, gekennzeichnet durch folgende Merkmale: - das Steuergerät (10) ist eingerichtet, mehrere Anwendungen (11) und Zwischenanwendungen (12) zu betreiben, - das Steuergerät (10) umfasst einen durch die Anwendungen (11) und Zwischenanwendungen (12) gemeinsam nutzbaren Speicher (23) und - die Zwischenanwendungen (12) sind eingerichtet, eine Interprozesskommunikation (29) zwischen den Anwendungen (11) über den Speicher (23) abzuwickeln.

Description

Beschreibung Titel
Steuergerät für ein Kraftfahrzeug und entsprechendes Kraftfahrzeug
Die vorliegende Erfindung betrifft ein Steuergerät für ein Kraftfahrzeug. Die vorliegende Erfindung betrifft darüber hinaus ein entsprechendes Kraftfahrzeug und ein entsprechendes Verfahren.
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.
US 2013/0145482 AI beschreibt ein Fahrzeug, das ein oder mehrere
Verarbeitungsmodule implementiert. Diese Module sind konfiguriert, um eine Verbindung zu den verschiedenen Bussen im Fahrzeug herzustellen, wobei die verschiedenen Busse mit den verschiedenen Komponenten des Fahrzeugs verbunden sind, um eine Informationsübertragung zwischen den
Fahrzeugkomponenten zu erleichtern. Jedes Verarbeitungsmodul ist weiter modularisiert mit der Fähigkeit, andere Funktionsmodule jetzt oder zukünftig hinzuzufügen und zu ersetzen. Diese Funktionsmodule können selbst als eigenständige Fahrzeugkomponenten agieren. Jedes Verarbeitungsmodul kann die Verarbeitung an andere Module abhängig von seiner Gesundheit,
Verarbeitungslast oder durch Fremdsteuerung übergeben. Somit hilft die Vielzahl von Verarbeitungsmodulen, einen Middleware-Steuerpunkt für das Fahrzeug mit Redundanz in der Verarbeitung und dem Sicherheits- und
Sicherheitsbewusstsein in ihren Anwendungen zu implementieren.
US 2007/076593 AI offenbart ein Fahrzeugsteuerungssystem mit mehreren Knoten, die mit einem Kommunikationsnetz verbunden sind, um koordinierte Vorgänge auf der Grundlage von Daten, die über das Kommunikationsnetz gesendet werden, zum Steuern des Fahrzeugs durchzuführen, wobei jeder der Knoten Folgendes umfasst: einen Knotenstatus-Bestimmungsabschnitt, der Knotenstatusdaten von anderen Knoten über das Kommunikationsnetz empfängt und Knotenstatus bestimmt, die einen oder mehrere eines Ausfallzustands und eines Nichtausfallzustands der mehreren Knoten anzeigen, einen Knotenstatus- Auswertungsergebnis-Sende-/-Empfangsabschnitt zum Senden von
Knotenstatusdaten einschließlich Knotenstatus des eigenen Knotens und der anderen Knoten, die von dem Knotenstatus-Bestimmungsabschnitt bestimmt wurden, an die anderen Knoten und zum Empfangen von Knotenstatusdaten einschließlich Knotenstatus des eigenen Knotens und der anderen Knoten, die von anderen Knoten bestimmt und über das Kommunikationsnetz gesendet wurden und einen Ausfallknoten-Identifikationsabschnitt, der einen mit dem Kommunikationsnetz verbundenen ausgefallenen Knoten auf der Grundlage der Knotenstatusdaten identifiziert, die Knotenstatus des eigenen Knotens und der anderen Knoten einschließen, die von dem Knotenstatus-Bestimmungsabschnitt bestimmt und von den anderen Knoten gesendet wurden, wobei die Vorgänge in dem Knotenstatus-Bestimmungsabschnitt, dem Knotenstatus- Auswertungsergebnis-Sende-/-Empfangsabschnitt und dem Ausfallknoten- Identifikationsabschnitt synchron mit Kommunikationen zwischen dem eigenen Knoten und den anderen Knoten über das Kommunikationsnetz ausgeführt werden und der Ausfallknoten-Identifikationsabschnitt mit einer Middleware, die eine Anwendungsprogrammschnittstelle einschließt, umgesetzt wird, die das Ergebnis der Ausfallknoten- Identifikation einem
Steuerungsanwendungsprogramm bereitstellt, das auf dem eigenen Knoten läuft. Offenbarung der Erfindung
Die Erfindung stellt ein Steuergerät für ein Kraftfahrzeug sowie ein
entsprechendes Kraftfahrzeug und Verfahren gemäß den unabhängigen
Ansprüchen bereit. Dem erfindungsgemäßen Ansatz liegt hierbei die Erkenntnis zugrunde, dass zahlreiche Fahrerassistenzsysteme für hochautomatisiertes Fahren aktuell in der Entstehungsphase sind. Die Realisierung erfordert das Beherrschen von großen Systemen. Speziell die Verteilung der Teilaufgaben auf verschiedene
Steuergeräte stellt erhöhte Anforderungen bezüglich der Kommunikation zwischen den Teilaufgaben. Eine Dienste-Schicht von
Zwischenanwendungen (middleware) soll hier das flexible Verteilen von
Teilaufgaben ermöglichen.
Es wird daher ein effizienter Middleware-Ansatz vorgestellt. Basis dieses Ansatzes sind Interprozesskommunikation (inter-process communication, IPC) und gemeinsam genutzter Speicher (shared memory). Eine derart beschaffene
Dienste-Schicht verzichtet auf ein unnötiges Kopieren von Daten oder Blockieren von Anwendungen und erweist sich somit als in höchstem Maße rationell.
Der nachfolgend erörterte Ansatz mag etwa zur Gestaltung einer
Referenzplattform-Softwarearchitektur für HAD dienen und gestattet
insbesondere eine Echtzeitverarbeitung großer Datenmengen von mehreren
Sensoren sowie die Kommunikation des Fahrzeuges mit seiner
Umgebung (Car2X) bei höchster Betriebssicherheit, Zuverlässigkeit und
Absicherung gegen unbefugte Manipulation. Unterstützt werden auf diesem Wege auch moderne Mehrkern- und insbesondere Vielkern-Controller und - aufgrund deren erhöhten Leistungspotenziales - unterschiedlichste der
Unterhaltungselektronik (consumer electronics, CE) entliehene Komponenten. Insgesamt erfüllt die vorgeschlagene Lösung somit höchste Anforderungen hinsichtlich Effizienz, Skalier- und Wartbarkeit, Portabilität, Datenkapselung, Standardkonformität und Austauschbarkeit beispielsweise von Software und insbesondere Firmware über die Luftschnittstelle (Software over the air, SOTA; firmware over the air, FOTA). 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 vorgesehen sein, dass Steuergerät und Betriebssystem zwischen den Anwendungen eine Separation dergestalt vornehmen, dass bestimmte Anwendungen nicht zu einem
Zugriff auf den gemeinsam nutzbaren Speicher berechtigt sind. Besonders vorteilhaft ist dabei, dass die Lösung eine flexible Methode zur Separation enthält. Dabei wird die Effizienz der Realisierung weitgehend erhalten.
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass das Steuergerät ferner eine Speicherverwaltungseinheit (memory management unit, MMU) umfasst, um die Separation vorzunehmen. Eine Trennung unterschiedlicher Speicherbereiche lässt sich somit vorteilhaft in entsprechender Hardware abbilden.
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die Anwendungen über eine Zwischenanwendungsschnittstelle auf die Zwischenanwendungen zugreifen, die sich ihrerseits über standardisierte Schnittstellen auf
Betriebssystem, Datenverbindungen, Steuergerätabstraktionsschicht,
Mikrocontrollerabstraktionsschicht, komplexe Treiber oder sonstige Dienste der Basissoftware zugreifen. Der Datenverkehr wird auf diese Weise vollständig durch die Dienste-Schicht abstrahiert. Selbst eine Verteilung von Anwendungen auf unterschiedliche Steuergeräte wird so möglich, sofern Latenz und Dienstgüte gewährleistet werden können.
Gemäß einem weiteren Aspekt schließlich kann ein POSIX-konformes
Betriebssystem wie QNX für das Steuergerät vorgesehen sein. Im letzteren Fall mag die besagte Separation zwischen einzelnen Anwendungen durch adaptive Partitionierung (AP) der Anwendungssoftware erfolgen. Ein entsprechender Scheduler ermöglicht es dem Entwerfer des Echtzeitsystems festzulegen, dass ein gewisser Anteil von Verarbeitungsressourcen für eine bestimmte Partition - also Gruppe von Aktivitätsträgern bzw. Ausführungssträngen (threads) oder Prozessen, die ein Subsystem bilden - reserviert ist. 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 einen zwischenanwendungsorientierten Ansatz gemäß der
vorgeschlagenen Lösungsstrategie.
Figur 2 den Datenverkehr zwischen Steuergeräten mittels einer
erfindungsgemäßen Dienste-Schicht.
Figur 3 den steuergerätinternen Datenverkehr mittels der erfindungsgemäßen Dienste-Schicht.
Figur 4 eine Lösungsstrategie zur Verwendung gemeinsam genutzten Speichers im Rahmen eines effizienten Zwischenanwendungsansatzes zur
Interprozesskommunikation.
Figur 5 Grundlagen der Separation.
Figur 6 die Wirkung der Separation im Zusammenhang mit
Zwischenanwendungen.
Figur 7 eine Lösungsstrategie zur Interprozesskommunikation unter Beibehaltung der Trennung von Bereichen mit unterschiedlichen Sicherheitsanforderungen.
Figur 8 die Interprozesskommunikation über gemeinsam genutzten Speicher unter Beibehaltung der Trennung von Bereichen mit unterschiedlichen
Sicherheitsanforderungen.
Ausführungsformen der Erfindung
Figur 1 illustriert einen zwischenanwendungsorientierten Ansatz gemäß der vorgeschlagenen Lösungsstrategie. Anwendungen (11) bedienen sich hier der Anwendungsprogrammierschnittstelle (application programming Interface, API) besonderer Zwischenanwendungen (12). Datenverkehr wird dabei ausschließlich über die Zwischenanwendungen (12) abgewickelt, was Portabilität, Skalier- und Wiederverwendbarkeit, Datenkapselung usw. ermöglicht. Ein derartiger Ansatz ließe sich beispielsweise im Rahmen einer zukünftig zu definierenden
anpassungsfähigen und offenen Fahrzeugsystemarchitektur (automotive open System architecture, AUTOSAR) verfolgen.
Figur 2 veranschaulicht den Datenverkehr zwischen Steuergeräten mittels einer erfindungsgemäßen Dienste-Schicht. Jedes Steuergerät (10) betreibt hierbei neben der AU TOS AR- Basissoftware (15) die spezifische
HAD-Anwendungssoftware (14). Die Basissoftware (15) umfasst
erfindungsgemäß auch die Zwischenanwendungen (12) der Dienste-Schicht, während die Anwendungssoftware (14) die einzelnen Anwendungen (11) im engeren Sinne umfasst. Wie die Anwendungen (11) über eine
Zwischenanwendungsschnittstelle (13) auf die Zwischenanwendungen (12) zugreifen, so greifen letztere ihrerseits über standardisierte Schnittstellen (16) auf Betriebssystem (17), Datenverbindung (18), Steuergerätabstraktionsschicht (19), Mikrocontrollerabstraktionsschicht (20), komplexe Treiber (21) oder sonstige Dienste der Basissoftware (15) zu.
Figur 3 zeigt in entsprechender Darstellung den Datenverkehr mittels der erfindungsgemäßen Dienste-Schicht innerhalb eines einzelnen
Steuergerätes (10). Eine derart effiziente steuergerätinterne
Interprozesskommunikation (29) wird durch ausgewählte Elemente
beispielsweise im Rahmen von AUTOSAR in Kombination mit einer geeigneten API für gemeinsam genutzten Speicher (23) ermöglicht und stellt eine
Schlüsselfähigkeit eingebetteter HAD-Systeme dar.
Figur 4 beleuchtet eine Lösungsstrategie zur Verwendung gemeinsam genutzten Speichers (23) im Rahmen des diskutierten Ansatzes. Das Steuergerät (10) umfasst solch einen durch verschiedene Anwendungen (11) und
Zwischenanwendungen (12) gemeinsam nutzbaren Speicher (23), über welchen eine der Zwischenanwendungen (31) die Interprozesskommunikation (29) zwischen den Anwendungen A und B abwickelt. Letztere unterliegen in diesem Fall den gleichen Sicherheitsanforderungen, die durch eine gemeinsame Sicherheitsanforderungsstufe (automotive safety integrity level, ASIL) mit der Bezeichnung A, B, C, D oder QM festgelegt werden. (Diese gegebene
Sicherheitsanforderungsstufe trägt im Folgenden stellvertretend das
Bezugszeichen X.)
Die Grundlagen der Separation (25) seien nunmehr anhand der Figur 5 erläutert. POSIX-konforme Betriebssysteme wie QNX erlauben eine solche Trennung von Anwendungen (11) auf Prozessebene, die somit voraussichtlich auch im Rahmen einer künftigen, anpassungsfähigen AUTOSAR-Implementierung umgesetzt werden kann. (Dies gilt natürlich auch für nicht POSIX-konforme Systeme, die entsprechende Mechanismen enthalten.) Das Steuergerät (10) umfasst zu diesem Zweck eine - als solche nicht abgebildete - Speicherverwaltungseinheit. Bei Verwendung eines entsprechenden Betriebssystems (17) wie QNX unterstützt dessen Mikrokern zur Laufzeit die Separation (25) durch eine adaptive Partitionierung der Anwendungssoftware (14). Einzelne
Ausführungsstränge (24) innerhalb eines Prozesses lassen sich auf diesem Wege nicht ohne Weiteres trennen.
Es sei bemerkt, dass das exemplarisch angeführte QNX lediglich eines von zahlreichen denkbaren Ziel- Betriebssystemen darstellt. Die beschriebenen Mechanismen sind gleichwohl auch im Umfeld anderweitiger Betriebssysteme denkbar. Sogar ein Ansatz mit Hypervisor kann von einer erfindungsgemäßen Ausgestaltung profitieren.
Die Funktion der erfindungsgemäßen Zwischenanwendungen (12) in diesem Zusammenhang erschließt sich aus Figur 6. Betrachtet man den durch die gegebene Sicherheitsanforderungsstufe (X) definierten Bereich, so kann die Separation (25) innerhalb dieses Bereiches durch den Entwicklungsprozess der Software und insbesondere eine stringente Schichtenbildung erzwungen werden. Wo dies nicht möglich ist - etwa in der bereichsübergreifenden Kommunikation mit Anwendungen (11) auf geringerer Sicherheitsanforderungsstufe (Y) - sind ausdrückliche Mechanismen erforderlich. Figur 7 illustriert einen solchen Mechanismus zur
Interprozesskommunikation (29) unter Beibehaltung der Trennung von Bereichen mit unterschiedlichen Sicherheitsanforderungen. Während eine erste
Zwischenanwendung (31) auf der besagten Sicherheitsanforderungsstufe (X) operiert, greifen einige Anwendungen (11) auf eine zweite Zwischenanwendung geringerer Sicherheitsanforderungsstufe (Y) zu. Diejenigen Anwendungen (11), welche sowohl auf die erste Zwischenanwendung (31) als auch auf die zweite Zwischenanwendung (32) zugreifen, dienen dabei zugleich als
Sicherheitsbegrenzer (26) zwischen den Sicherheitsanforderungsstufen (X, Y).
Die Funktion des gemeinsam nutzbaren Speichers (23) in dieser Konstellation veranschaulicht Figur 8: Im Gegensatz zur privilegierten Anwendung A ist die nichtprivilegierte Anwendung C in diesem Szenario nicht zu einem Zugriff auf den gemeinsam nutzbaren Speicher (23) berechtigt (28). Die auf höchster
Sicherheitsstufe betriebene und entsprechend privilegierte Anwendung A fungiert zudem als Sicherheitsbegrenzer (27) beim bereichsübergreifenden Zugriff auf den Speicher (23) mittels der zweiten Zwischenanwendung (32).

Claims

Steuergerät (10) für ein Kraftfahrzeug,
gekennzeichnet durch folgende Merkmale:
- das Steuergerät (10) ist eingerichtet, mehrere Anwendungen (11) und Zwischenanwendungen (12) zu betreiben,
- das Steuergerät (10) umfasst einen durch die Anwendungen (11) und Zwischenanwendungen (12) gemeinsam nutzbaren Speicher (23) und
- die Zwischenanwendungen (12) sind eingerichtet, eine
Interprozesskommunikation (29) zwischen den Anwendungen (11) über den Speicher (23) abzuwickeln.
Steuergerät (10) nach Anspruch 1,
gekennzeichnet durch folgende Merkmale:
- das Steuergerät (10) ist eingerichtet, eine Anwendungssoftware (14) insbesondere für ein Fahrerassistenzsystem zum hochautomatisierten Fahren des Kraftfahrzeuges und eine Basissoftware (15) zu betreiben,
- die Basissoftware (15) umfasst die Zwischenanwendungen (12) und
- die Anwendungssoftware (14) umfasst die Anwendungen (11).
Steuergerät (10) nach Anspruch 2,
gekennzeichnet durch folgende Merkmale:
- die Anwendungen (11) sind eingerichtet, über eine
Zwischenanwendungsschnittstelle (13) auf die
Zwischenanwendungen (12) zuzugreifen und
- die Zwischenanwendungen (12) sind eingerichtet, über standardisierte Schnittstellen (16) auf ein Betriebssystem (17), eine
Datenverbindung (18), eine Steuergerätabstraktionsschicht (19), eine Mikrocontrollerabstraktionsschicht (20), komplexe Treiber (21) oder sonstige Dienste (22) der Basissoftware (15) zuzugreifen.
Steuergerät (10) nach Anspruch 3,
gekennzeichnet durch folgende Merkmale:
- die Anwendungen (11) umfassen privilegierte Anwendungen (A, B) und nichtprivilegierte Anwendungen (C), - die Anwendungen (11) weisen jeweils mindestens einen
Ausführungsstrang (24) auf und
- das Steuergerät (10) und Betriebssystem (17) sind eingerichtet,
zwischen den Anwendungen (11) eine Separation (25) dergestalt vorzunehmen, dass die nichtprivilegierten Anwendungen (C) nicht zu einem Zugriff auf den gemeinsam nutzbaren Speicher (23) berechtigt sind.
5. Steuergerät (10) nach Anspruch 4,
gekennzeichnet durch folgende Merkmale:
- das Steuergerät (10) umfasst ferner eine Speicherverwaltungseinheit und
- die Speicherverwaltungseinheit ist eingerichtet, die Separation (25) vorzunehmen.
6. Steuergerät (10) nach Anspruch 4 oder 5,
gekennzeichnet durch folgende Merkmale:
- für eine gegebene Sicherheitsanforderungsstufe (X) des
Kraftfahrzeuges umfassen die Zwischenanwendungen (12) eine erste Zwischenanwendung (31) auf der besagten
Sicherheitsanforderungsstufe (X) und mindestens eine zweite
Zwischenanwendung (32) auf geringerer
Sicherheitsanforderungsstufe (Y) und
- diejenigen Anwendungen (11), welche sowohl auf die erste Zwischenanwendung (31) als auch auf die zweite
Zwischenanwendung (32) zugreifen, sind als Sicherheitsbegrenzer (26) zwischen den Sicherheitsanforderungsstufen (X, Y) eingerichtet.
7. Steuergerät (10) nach einem der Ansprüche 4 bis 6,
gekennzeichnet durch folgendes Merkmal:
- das Betriebssystem (17) ist POSIX-konform.
8. Steuergerät (10) nach Anspruch 7,
gekennzeichnet durch folgendes Merkmal:
- das Betriebssystem (17) ist QNX. Steuergerät (10) nach Anspruch 8,
gekennzeichnet durch folgendes Merkmal:
- die Separation (25) erfolgt durch eine adaptive Partitionieru Anwendungssoftware (14).
10. Kraftfahrzeug mit einem Steuergerät (10) nach einem der Ansprüche 1 bis 9.
11. Verfahren zum Steuern eines Kraftfahrzeuges,
gekennzeichnet durch folgende Merkmale:
- mehrere Anwendungen (11) und Zwischenanwendungen (12) werden auf einem gemeinsamen Steuergerät (10) betrieben,
- ein Speicher (23) des Steuergerätes (10) wird durch die Anwendungen (11) und Zwischenanwendungen (12) gemeinsam genutzt und
- eine Interprozesskommunikation (29) zwischen den Anwendungen (11) wird durch die Zwischenanwendungen (12) über den Speicher (23) abgewickelt.
12. Verfahren nach Anspruch 11,
gekennzeichnet durch folgende Merkmale:
- durch das Steuergerät (10) werden eine Anwendungssoftware (14) insbesondere für ein Fahrerassistenzsystem zum hochautomatisierten Fahren des Kraftfahrzeuges und eine Basissoftware (15) betrieben,
- die Basissoftware (15) umfasst die Zwischenanwendungen (12) und
- die Anwendungssoftware (14) umfasst die Anwendungen (11).
13. Verfahren nach Anspruch 12,
gekennzeichnet durch folgende Merkmale:
- die Anwendungen (11) greifen über eine
Zwischenanwendungsschnittstelle (13) auf die
Zwischenanwendungen (12) zu und
die Zwischenanwendungen (12) greifen über standardisierte
Schnittstellen (16) auf ein Betriebssystem (17), eine
Datenverbindung (18), eine Steuergerätabstraktionsschicht (19), eine Mikrocontrollerabstraktionsschicht (20), komplexe Treiber
(21) oder sonstige Dienste (22) der Basissoftware (15) zu.
PCT/EP2018/052568 2017-02-08 2018-02-01 Steuergerät für ein kraftfahrzeug und entsprechendes kraftfahrzeug WO2018146000A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201880010747.1A CN110291504B (zh) 2017-02-08 2018-02-01 用于机动车的控制器和相应的机动车

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017201966.2A DE102017201966A1 (de) 2017-02-08 2017-02-08 Steuergerät für ein Kraftfahrzeug und entsprechendes Kraftfahrzeug
DE102017201966.2 2017-02-08

Publications (1)

Publication Number Publication Date
WO2018146000A1 true WO2018146000A1 (de) 2018-08-16

Family

ID=61192897

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/052568 WO2018146000A1 (de) 2017-02-08 2018-02-01 Steuergerät für ein kraftfahrzeug und entsprechendes kraftfahrzeug

Country Status (3)

Country Link
CN (1) CN110291504B (de)
DE (1) DE102017201966A1 (de)
WO (1) WO2018146000A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020182544A1 (de) 2019-03-12 2020-09-17 Robert Bosch Gmbh Datenstruktur für ein eingebettetes system, entsprechendes system und fahrzeug
WO2020182607A1 (de) 2019-03-12 2020-09-17 Robert Bosch Gmbh Datenstruktur für ein eingebettetes system, entsprechendes system und fahrzeug
US11494535B2 (en) 2019-09-17 2022-11-08 Robert Bosch Gmbh Method and device for simulating a control unit
US12005932B2 (en) 2019-09-17 2024-06-11 Robert Bosch Gmbh Method and device for automating a driving function

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022133985A1 (de) * 2022-12-20 2024-06-20 Valeo Schalter Und Sensoren Gmbh Steuergerät mit QM-Betriebssystem als Servicearchitektur für ASIL-Anwendungen

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070076593A1 (en) 2005-10-03 2007-04-05 Hitachi, Ltd. Vehicle control system
US7730261B1 (en) * 2005-12-20 2010-06-01 Marvell International Ltd. Multicore memory management system
US8286188B1 (en) * 2007-04-27 2012-10-09 Marvell Israel (M.I.S.L.) Ltd. Method and apparatus for advanced interprocess communication
US20130145482A1 (en) 2011-11-16 2013-06-06 Flextronics Ap, Llc Vehicle middleware

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103684963B (zh) * 2013-11-18 2017-05-24 重庆邮电大学 一种面向车联网应用的中间件架构系统及实现方法
CN104133728B (zh) * 2013-12-16 2015-07-22 腾讯科技(深圳)有限公司 一种进程间通讯的方法、及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070076593A1 (en) 2005-10-03 2007-04-05 Hitachi, Ltd. Vehicle control system
US7730261B1 (en) * 2005-12-20 2010-06-01 Marvell International Ltd. Multicore memory management system
US8286188B1 (en) * 2007-04-27 2012-10-09 Marvell Israel (M.I.S.L.) Ltd. Method and apparatus for advanced interprocess communication
US20130145482A1 (en) 2011-11-16 2013-06-06 Flextronics Ap, Llc Vehicle middleware

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020182544A1 (de) 2019-03-12 2020-09-17 Robert Bosch Gmbh Datenstruktur für ein eingebettetes system, entsprechendes system und fahrzeug
WO2020182607A1 (de) 2019-03-12 2020-09-17 Robert Bosch Gmbh Datenstruktur für ein eingebettetes system, entsprechendes system und fahrzeug
US11494535B2 (en) 2019-09-17 2022-11-08 Robert Bosch Gmbh Method and device for simulating a control unit
US12005932B2 (en) 2019-09-17 2024-06-11 Robert Bosch Gmbh Method and device for automating a driving function

Also Published As

Publication number Publication date
DE102017201966A1 (de) 2018-08-09
CN110291504A (zh) 2019-09-27
CN110291504B (zh) 2023-11-21

Similar Documents

Publication Publication Date Title
WO2018146000A1 (de) Steuergerät für ein kraftfahrzeug und entsprechendes kraftfahrzeug
EP2235628B1 (de) Kraftfahrzeug-steuervorrichtung
DE102011117116B4 (de) Steuereinrichtung zum wenigstens teilweise autonomen Betrieb eines Fahrzeugs und Fahrzeug mit solch einer Steuereinrichtung
WO2013171122A2 (de) Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts
EP3929740A1 (de) Verfahren zur orchestrierung einer container-basierten anwendung auf einem endgerät
DE102017100118A1 (de) Skalierbares Steuersystem für ein Kraftfahrzeug
DE10357118A1 (de) Laden von Software-Modulen
DE102007006614A1 (de) Anwendung einer verteilten Diagnosearchitektur in AUTOSAR
EP3900266A1 (de) Verfahren zum betreiben eines fahrzeuges beim auslagern von rechenleistung aus dem fahrzeug an mindestens einen edge-cloud-computer
DE102016008957B4 (de) Direkter Zugriff auf Bussignale in einem Kraftfahrzeug
DE102004002020A1 (de) Steuerungssoftwarearchitektur zur Realisierung einer dezentralisierten kooperativen Steuerung mehrerer elektronischer Steuerungsvorrichtungen, die über ein Netzwerk verbunden sind
DE102019217047A1 (de) Verfahren und Vorrichtung zum Verwalten von Zugriffen mehrerer Softwarekomponenten auf Softwareschnittstellen
DE102012212680A1 (de) Verfahren und System zur fehlertoleranten Steuerung von Stellgliedern für eine begrenzte Zeit auf der Grundlage von vorberechneten Werten
EP3560153B1 (de) Verfahren zum betreiben einer datenverarbeitungsanlage, datenverarbeitungsanlage
WO2008092412A1 (de) Steuerung des laufzeitverhaltens von prozessen
EP4381386B1 (de) Priorisieren eines zugriffs von einer containerinstanz auf eine datei in einer dateisystemressource
EP4144003B1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
DE102019208519A1 (de) Verfahren und Vorrichtung zum Anpassen einer Softwareanwendung
DE102021207473A1 (de) Mitigation einer manipulation von software eines fahrzeugs
DE102023208876A1 (de) Ein Verfahren zum Aktualisieren einer Anwendung einer elektronischen Kraftfahrzeug-Steuereinheit
DE102021204789A1 (de) Verfahren und system zur zusicherung garantierter dienstgüte in fahrzeugen
WO2023138721A1 (de) Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit
DE102023208140A1 (de) Verfahren zum Bereitstellen eines verteilten Informationssicherheits-Systems für ein Fahrzeug
WO2021089308A1 (de) System zum steuern einer maschine
DE102024000182A1 (de) Computerimplementiertes Verfahren zum Konfigurieren einer Firewall, Computerprogrammprodukt, computerlesbares Speichermedium und Fahrzeug

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18704482

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18704482

Country of ref document: EP

Kind code of ref document: A1