-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Bordnetzes, ein Bordnetz, ein Rechensystem sowie ein Verfahren zum Einrichten eines Bordnetzes in einem Fahrzeug.
-
Hintergrund der Erfindung
-
In einem modernen Fahrzeug gibt es verschiedenste Funktionen, die durch einzelne Steuergeräte und daran angeschlossene Sensoren und Aktoren umgesetzt werden. Steuergeräte wiederum können miteinander datenübertragend bzw. kommunikativ verbunden sein, um Daten bzw. Informationen auszutauschen. Die Gesamtheit der Steuergeräte, Sensoren und Aktoren sowie ggf. weiteren Komponenten wie insbesondere Kommunikationsverbindungen wird auch als Bordnetz bzw. Borddatennetz bezeichnet, deren Aufbau bzw. Anordnung auch als E/E-Architektur.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Betreiben eines Bordnetzes, ein Bordnetz, ein Rechensystem sowie ein Verfahren zum Einrichten eines Bordnetzes in einem Fahrzeug mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Die Erfindung beschäftigt sich mit einem Bordnetz bzw. der E/E-Architektur in einem Fahrzeug und insbesondere der Kommunikation zwischen verschiedenen Einheiten in diesem Bordnetz. Getrieben durch Kostenoptimierung, steigende Komplexität der Elektronik im Fahrzeug und neue Möglichkeiten aufgrund des technischen Forstschritts ist insbesondere von Seiten der Fahrzeughersteller eine Optimierung der E/E-Architektur angestrebt. Um einerseits durch eine Vereinfachung des Kabelbaums Kosten zu sparen und andererseits die Flexibilität und Skalierbarkeit durch die Konzentration bzw. Zentralisierung von Software auf sogenannten Fahrzeugzentralrechnern (auch als „Vehicle Computer“ bezeichnet) zu erhöhen, kommt der Einsatz einer sog. zonalen E/E-Architektur oder Zonenarchitektur in Betracht. In der zonalen E/E-Architektur könne z.B. Sensoren, Aktoren, „intelligente“ Mechatroniken bzw. Mechatronikeinheiten (sog. Smart Components, hierunter versteht man mechanische Einheiten mit eigener Rechenlogik bzw. eigenem Controller wie z.B. eine Kühlermechatronik bestehend aus Lüftermotor, Lüfterendstufe und Lüftermikrocontroller, oder z.B. die Mechatronik eines Getriebes, die Schaltvorgänge regelt) und (Smart-) „Electronic Control Units“ (ECU), also Steuergeräte im herkömmlichen Sinne, und sonstige mechatronische Einheiten entsprechend ihrer geometrischen Position im Fahrzeug über sog. Zonensteuergeräte an einen oder mehrere Fahrzeugzentralrechner angebunden werden. Die Zonensteuergeräte fungieren dabei insbesondere als Energie- und Datenverteiler, die eigentliche Logik bzw. Funktion wird, zumindest soweit möglich, auf dem Fahrzeugzentralrechner ausgeführt oder gerechnet.
-
Die Zentralisierung der Software (mit Logik und Funktion) geht typischerweise mit dem Einsatz von leistungsstärkeren Recheneinheiten auf dem Fahrzeugzentralrechner einher - die heute gängigen auf Mikrocontrollern (µC) basierende Systeme werden in dieser Geräteklasse mit Mikroprozessoren (µP) erweitert. Die darauf laufenden Betriebssysteme (z.B. POSIX-basierte Betriebssysteme) ermöglichen eine sog. Service-orientierte-Architektur (SOA), die eine effiziente und schnelle Entwicklung von Funktionen erlaubt.
-
Das Einbringen neuer Funktionen in einem verteilten System wie einem Bordnetz erfordert bisher in der Regel eine Anpassung der Software auf allen beteiligten Steuergeräten. Die Ziele einer schnelleren Markteinführungszeit von Fahrzeugfunktionen und Erweiterung bzw. Ergänzung von Fahrzeugfunktionen im Feld lassen sich nur effizient realisieren, wenn dem Teilnehmer, der die Logik der Funktion implementiert - dies ist in der erwähnten Zonenarchitektur ein Fahrzeugzentralrechner - der volle Zugriff auf die Peripherie bzw. Sensorik und Aktuatorik im Fahrzeug zur Verfügung steht.
-
Eine hohe Wiederverwendung (bzw. eine möglichst universelle Verwendung) der Software-Funktionen auf den Fahrzeugzentralrechnern erfordert, dass die entsprechenden Applikationen oder Anwendungen (die die Software-Funktionen bereitstellen) von der eingesetzten Fahrzeug-Hardware entkoppelt werden. Eine Entkopplung über einen auf Service-orientierter-Architektur (SOA) basierenden (oder service-basierten) Ansatz in den Fahrzeugzentralrechnern erfordert eine Wandlung der signal-basierten Informationen der Peripherie bzw. Sensorik und Aktuatorik auf service-basierte Schnittstellen. Eine solche Wandlung sollte möglich sein, ohne dass dabei Programmcode der Zonensteuergeräte und darunterliegender Komponenten (der Ausführungseinheiten) notwendig ist, um die erwähnte Entkopplung zu erreichen.
-
Wünschenswert ist es insofern, neue Fahrzeugfunktionen allein durch ein Update von Software-Funktionen auf den Fahrzeugrechnern zu ermöglichen, ohne dass dabei ein Update der Software der Zonensteuergeräte oder nachgelagerten Komponenten (Ausführungseinheiten) notwendig ist.
-
Wie erwähnt, liegt dem Bordnetz bzw. der E/E-Architektur eines Fahrzeugs, wie es im Rahmen der vorliegenden Erfindung verwendet wird, eine Zonenarchitektur zu Grunde. Diese Zonenarchitektur weist drei Ebenen (oder „Layer“) auf, eine Rechenebene (oder „Computational Layer“), eine Zonenebene (oder „Zonal Layer“) und eine Ausführungs- oder Embedded-Ebene (oder „Embedded Layer“). In der Rechenebene ist dabei der Fahrzeugzentralrechner vorgesehen. Denkbar ist auch die Verwendung mehrerer solcher Fahrzeugzentralrechner, die dann entsprechend alle der Rechenebene zugeordnet sind. Typisch und auch bevorzugt ist die Anbindung des Fahrzeugzentralrechners (insbesondere drahtlos) an eine fahrzeugexterne bzw. fahrzeugfremde Recheneinheit wie ein entferntes Rechensystem oder einen Server („Cloud“), über die verschiedene Funktionen oder Dienste oder auch Software-Updates bereitgestellt werden können. Bei mehreren Fahrzeugzentralrechnern kann die Anbindung eines davon an die fahrzeugfremde Recheneinheit ausreichend sein. Diese fahrzeugfremde Recheneinheit kann dann ebenfalls der Rechenebene zugeordnet werden.
-
In der Zonenebene sind (im generischen Sinne) Zonensteuergeräte vorgesehen, wobei typischerweise mehrere Zonensteuergeräte vorhanden sind, auch wenn die Zonenarchitektur grundsätzlich auch bei nur einem Zonensteuergerät anwendbar ist. In der Ausführungsebene sind (im generischen Sinne) Ausführungseinheiten vorgesehen, wobei typischerweise mehrere Ausführungseinheiten je Zonensteuergerät vorhanden sind, auch wenn die Zonenarchitektur grundsätzlich auch bei nur insgesamt einer Ausführungseinheit oder einer Ausführungseinheit je Zonensteuergerät anwendbar ist.
-
Die Zonensteuergeräte - es kann sich hier, wie nachfolgend auch noch näher erläutert, um relativ einfache Rechensysteme oder Recheneinheiten handeln - dienen dabei insbesondere der geometrischen bzw. räumlichen Aufteilung im Fahrzeug. Beispielsweise können vier Zonensteuergeräte vorgesehen sein, jeweils eines für vorne, hinten, links und rechts im Fahrzeug (vgl. hierzu auch noch Figuren mit Figurenbeschreibung). Unter Ausführungseinheiten sind insbesondere Sensoren, Aktoren, sog. Smart Components (intelligente Mechatroniken) bzw. (Smart) „Electronic Control Units“ (ECU), also Steuergeräte im herkömmlichen Sinne, und sonstige mechatronische Einheiten zu verstehen, die auf unterster Ebene stehen und für die (unmittelbare) Ausführung von Aktionen oder Messungen zuständig sind. Aufgrund der Zuordnung der Ausführungseinheiten zu jeweils einem Zonensteuergerät können die einzelnen Ausführungseinheiten entsprechend auch einer Zone wie „vorne“ oder „hinten“ zugeordnet werden. Beispielsweise können alle im Motorraum angeordneten Steuergeräte der Zone „vorne“ zugeordnet sein.
-
Die Zonensteuergeräte sind dabei jeweils mittels eines ersten Kommunikationssystems mit dem Fahrzeugzentralrechner (bzw. der Rechenebene) kommunikativ verbunden. Als erstes Kommunikationssystem kommt hier z.B. Ethernet oder ein anderes breitbandiges Kommunikationssystem in Betracht. Im Falle mehrerer Fahrzeugzentralrechner kann jedes Zonensteuergerät mit (nur) einem dieser Fahrzeugzentralrechner verbunden sein. Die Ausführungseinheiten sind jeweils mittelbar oder unmittelbar über ein zweites Kommunikationssystem wie z.B. einen Kommunikationsbus mit dem ihnen zugeordneten Zonensteuergerät kommunikativ verbunden. Als zweites Kommunikationssystem bzw. Kommunikationsbus kommt hier z.B. ein CAN- oder LIN-Bus in Betracht. Dabei können verschiedene Ausführungseinheiten an dasselbe Zonensteuergerät ggf. auch über verschiedene Kommunikationsbusse angebunden sein. Einzelne Ausführungseinheiten können dabei direkt bzw. unmittelbar an das zugeordnete Zonensteuergerät angebunden sein, dies gilt insbesondere für Steuergeräte oder smarte bzw. intelligente Sensoren und Aktoren. Ebenso kann eine Ausführungseinheit aber indirekt bzw. mittelbar an das Zonensteuergerät angebunden sein, dann z.B. über ein solches Steuergerät. Dies gilt dann insbesondere für einfache Sensoren und Aktoren. Unter kommunikativer Anbindung ist dabei für sämtliche Kommunikationssysteme insbesondere zu verstehen, dass Daten bzw. Informationen ausgetauscht werden können, insbesondere digital (bei einfachen Sensoren, Schaltern oder Aktoren aber ggf. auch analog), ebenso aber z.B. auch einfache Spannungs- und/Stromwerte (die z.B. durch Änderung des Widerstands eines Temperatursensors erhalten werden).
-
Neben dieser Zonenarchitektur und den erwähnten Kommunikationsverbindungen wird zudem eine spezielle Konfiguration von Zonensteuergeräten und Fahrzeugzentralrechnern vorgeschlagen, die beim Betrieb eines solchen Bordnetzes zum Einsatz kommen bzw. womit ein solches Bordnetz mit seinen Einheiten konfiguriert ist. Im Sinne der Erfindung umfasst ein Bordnetz dabei zumindest die im Rahmen der Zonenarchitektur erwähnten Fahrzeugzentralrechner, Zentralsteuergeräte, Ausführungseinheiten (insbesondere also jeweils wenigstens eines davon) sowie die jeweiligen Kommunikationssysteme, insbesondere soweit sie z.B. in einem Fahrzeug vorhanden sind.
-
Wie aus den nachfolgenden Erläuterungen noch ersichtlich, funktioniert die Erfindung nicht nur bei einer solchen Zonenarchitektur; ausreichend ist auch eine Architektur mit den erwähnten drei Ebenen. Eine (geometrische) Aufteilung nach Zonen ist zwar von Vorteil, aber nicht zwingend erforderlich. In diesem Sinne soll nachfolgend anstelle von Zonensteuergeräten auch von Zwischensteuergeräten (die dann einer Zwischenebene zugeordnet sind) gesprochen werden. Ebenso muss es sich bei der verwendeten Architektur demnach nicht notwendigerweise um eine Zonenarchitektur handeln.
-
Für jedes Zwischen- bzw. Zonensteuergerät wird hierbei eine Beschreibungsdateivorgesehen, in der Schnittstellen für alle Ausführungseinheiten, die mittelbar oder unmittelbar über das zweite Kommunikationssystem mit dem betreffenden Zwischensteuergerät kommunikativ verbunden sind, beschrieben sind. Bei einer solchen Beschreibungsdatei handelt es sich insbesondere um eine maschinenlesbare Beschreibung dieser Schnittstellen. Für jeden Fahrzeugzentralrechner werden - z.B. im Rahmen einer Konfiguration - dann Datensätze von zumindest den an den betreffenden Fahrzeugzentralrechner angebundenen Zwischensteuergeräten erstellt. Mit anderen Worten wird der Fahrzeugzentralrechner anhand der Beschreibungsdateien konfiguriert, sodass anschließend die relevanten Informationen über die Schnittstellen in dem Fahrzeugzentralrechner vorhanden sind - eben in den Datensätzen. Dazu können, z.B. diese Beschreibungsdateien auf den betreffenden Zwischensteuergeräten hinterlegt sein und es wird Zugriff darauf gewährt, denkbar ist auch, dass die Beschreibungsdateien auf den betreffenden Fahrzeugzentralrechner geladen und dort dann vorgehalten werden. Ebenso können die Beschreibungsdateien über die erwähnte fahrzeugfremde Recheneinheit bereitgestellt und bei Bedarf vom Fahrzeugzentralrechner abgerufen werden, was eine einfache Anpassung der Datensätze erlaubt. Die Beschreibungsdateien können auch lediglich zur Konfiguration bzw. zur Erstellung des Programms (inkl. der Datensätze) des Fahrzeugzentralrechners verwendet werden.
-
Diese Beschreibungsdateien können z.B. von den Herstellern der betreffenden Zwischensteuergeräte erstellt und bereitgestellt werden. Die Verwaltung und Bereitstellung der Beschreibungsdateien muss aber nicht zwingend durch den Hersteller oder Lieferanten des Zwischensteuergeräts erfolgen. Ein bereitgestelltes Ökosystem aus betreffenden Tools und SW-Produkten könnte es einem Fahrzeughersteller z.B. auch erlauben, Erweiterungen der Beschreibungsdateien von Zwischensteuergeräten selbst durchzuführen.
-
Eine Beschreibungsdatei eines Zwischensteuergeräts umfasst unter anderem z.B. die Beschreibung der Schnittstelle von direkt an das Zwischensteuergerät angeschlossenen Ein- und Ausgängen und der Kommunikationsschnittstelle von Komponenten, die mittels z.B. Sub-Bussystemen angeschlossenen sind, also die Ausführungseinheiten, die mittelbar oder unmittelbar über das zweite Kommunikationssystem mit dem betreffenden Zwischensteuergerät kommunikativ verbunden sind. Dabei können für die Beschreibungsdateien bestehende Beschreibungsformate der an das Zwischensteuergerät angeschlossenen Peripherie, z.B. gängige Beschreibungsformate wie das für Werkstattdiagnose gängige ODX-Format wiederverwendet und durch Zusatzinformationen, wie z.B. Ablaufsteuerung der Werkstattdiagnose im OTX-Format, ergänzt werden. Weitere Metainformationen über die angeschlossene Peripherie, z.B. Informationen über den Arbeitsbereich eines Ausgangs, können ebenfalls Bestandteil der Beschreibungsdatei sein. Damit liegen sämtliche Informationen vor, die nötig sind, um jede an das Zonensteuergerät angeschlossene Ausführungseinheit auslesen und/oder ansteuern zu können.
-
Weiterhin wird in jedem Fahrzeugzentralrechner eine Zwischenanwendung - eine sog. „Middleware“, die insbesondere konfigurierbar ist - ausgeführt, über die mittels eines betreffenden Datensatzes (also die relevanten Informationen über die vorhandenen Schnittstellen) ein Zugriff von auf dem betreffenden Fahrzeugzentralrechner ausgeführten Anwendungen (Software) über das betreffende Zwischensteuergerät auf daran angebundene Ausführungseinheiten eingerichtet wird bzw. ermöglicht wird. Dies ermöglicht die Anbindung der Anwendungen an die vorhandene Hardware des Fahrzeugs.
-
Vorzugsweise werden durch die Zwischenanwendung auf dem betreffenden Fahrzeugzentralrechner sowohl eine signal-basierte Schnittstelle als auch eine service-basierte Schnittstelle bereitgestellt, die dann z.B. je nach Bedarf verwendet werden können. Während über eine signal-basierte Schnittstelle Daten bzw. Informationen dann zur Verfügung gestellt werden, wenn sie vorliegen, wie es z.B. für harte Echtzeitanforderungen nötig ist, werden über eine service-basierte Schnittstelle (bzw. in einer „Service-Orientierten-Architektur“) die Daten bzw. Informationen als Dienste (Services) bereitgestellt, d.h. jede Recheneinheit (hier jedes Zonensteuergerät oder jede Ausführungseinheit, ebenso aber auch der Fahrzeugzentralrechner bzw. dort der Mikroprozessor oder ein darauf laufendes Programm) kann die benötigten Dienste abonnieren und erhält daraufhin die Daten zugesandt.
-
Bevorzugt wird auch zwischen einem Fahrzeugzentralrechner und einem Zwischensteuergerät eine Kommunikationsschnittstelle bereitgestellt, über die Informationen über wenigstens ein Kommunikationsparadigma ausgetauscht werden können. Das wenigstens eine Kommunikationsparadigma umfasst z.B. ein Gateway-Paradigma (oder Tunneling-Paradigma), bei dem Daten basierend auf dem zweiten Kommunikationssystem (die also von einer Ausführungseinheit an das Zwischensteuergerät gesendet werden) in entsprechende Daten basierend auf dem ersten Kommunikationssystem (die also von dem Zwischensteuergerät an einen Fahrzeugzentralrechner gesendet werden) gewandelt werden oder umgekehrt. Eine (inhaltliche) Änderung der Daten finden hier also nicht statt, lediglich eine (formale) Anpassung an das andere Kommunikationssystem. Unter Kommunikationsparadigmen sind hier insbesondere verschiedene Verarbeitungsmethoden und/oder Protokolle der Kommunikation über das gleiche Medium (hier insbesondere) Ethernet) zu verstehen, z.B. Gateway/Tunneling wie erwähnt, oder aber z.B. auch zyklischer Blocktransfer von Sensor/Aktuator-Informationen, Routing anhand von bestehenden Diagnosetransportprotokollen, oder Weiterleitung von Ethernet (kann rein in Hardware Switch- oder Bridge-basiert auf dem Zonensteuergerät erfolgen).
-
Die auf den Fahrzeugzentralrechnern ausgeführten Anwendungen greifen dann insbesondere auf die Kommunikationsschnittstelle zu. Die Anwendungen können Fahrzeugfunktionen umfassen oder bereitstellen, die auf oberster Ebene (nämlich auf dem Fahrzeugzentralrechner) als sog. „Software Component“ (SWC) oder Applikationen (App) dargestellt sind. Diese greifen dann auf die Kommunikationsschnittstelle zu. Die Entkopplung erfolgt mittels der erwähnten Zwischenanwendung bzw. Middleware, umfassend z.B. die signal-basierte Schnittstelle (Signal-Dispatcher) und die service-basierte Schnittstelle, welche mittels der Beschreibungsdateien bzw. Datensätze der Zwischensteuergeräte parametriert sind.
-
Ein wesentlicher Unterschied und auch Vorteil des vorgeschlagenen Konzepts gegenüber bisheriger Konfiguration liegt darin, dem Fahrzeugzentralrechner und den darauf laufenden Applikationen bzw. Anwendungen Zugriff auf jegliche im Fahrzeug verbaute Peripherie bzw. Sensorik und Aktuatorik (die Ausführungseinheiten) zu bieten. Dabei muss sich eine Applikation nicht darum kümmern, über welches Zwischensteuergerät der Zugriff erfolgt und wie dieser in der speziellen Umsetzung aussieht. Das Zusammenspiel aus konfigurierbarer Zwischenanwendung (Middleware) und der Datensätze (Beschreibungsdateien) der Zwischensteuergeräte ermöglicht diese Abstraktion.
-
Zusätzlich bietet das vorgeschlagene Konzept die Möglichkeit, Komponenten unterhalb der Zwischensteuergeräte, also Ausführungseinheiten, hinzuzufügen oder auszutauschen bzw. deren Parameter zu ändern und den Zugriff darauf über das betreffende Zonensteuergerät von den Fahrzeugzentralrechnern aus zu ermöglichen, ohne dass dabei eine Anpassung des Programmcodes des Zwischensteuergeräts notwendig ist. Eine Anpassung oder Parametrisierung ist lediglich in den Datensätzen der Zwischensteuergeräte notwendig, die aber - wie erwähnt - ohne weiteres anpassbar sind. Entsprechende Beschreibungsdateien sind ohne weiteres zugänglich und können auch bereitgestellt werden, z.B. über die fahrzeugfremde Recheneinheit. Damit können die Datensätze, d.h. die Konfiguration der Fahrzeugzentralrechner, dann angepasst werden.
-
Die Erfindung betrifft neben einem Verfahren zum Betreiben eines solchen Bordnetzes in einem Fahrzeug auch ein solches Bordnetz, ein Rechensystem zur Verwendung als Fahrzeugzentralrechner in einem solchen Bordnetz sowie ein Verfahren zum Einrichten eines solchen Bordnetzes in einem Fahrzeug. Vorzugsweise wird beim Einrichten, wenn eine Ausführungseinheit ausgetauscht oder hinzugefügt wird, der Datensatz des betreffenden Zwischensteuergeräts, an dem die Ausführungseinheit anzuschließen ist, angepasst. Bevorzugt wird beim Einrichten auch, wenn eine Anwendung, die auf einem Fahrzeugzentralrechner auszuführen ist, ausgetauscht oder hinzugefügt wird, die Zwischenanwendung des betreffenden Fahrzeugzentralrechners angepasst.
-
Für weitere Ausgestaltungen und Vorteile von Bordnetz, Rechensystem und Verfahren zum Einrichten sei zur Vermeidung von Wiederholungen auf obige Ausführungen verwiesen, die hier entsprechend gelten.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt schematisch ein erfindungsgemäßes Bordnetz in einer bevorzugten Ausgestaltung in einem Fahrzeug.
- 2 zeigt schematisch eine Zonenarchitektur eines Bordnetzes zur Erläuterung der Erfindung.
- 3 zeigt schematisch einen Teil eines Bordnetzes zur Erläuterung der Erfindung.
- 4 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch ein erfindungsgemäßes Bordnetz 100 in einer bevorzugten Ausgestaltung in einem Fahrzeug 102 dargestellt, anhand dessen die E/E-Architektur bzw. die Verteilung der einzelnen Einheiten bzw. Komponenten des Bordnetzes erläutert werden sollen. Das Bordnetz 100 umfasst beispielhaft einen Fahrzeugzentralrechner 110, vier als Zonensteuergeräte ausgebildete (bzw. verwendete) Zwischensteuergeräte 120A, 120B, 120C, 120D sowie mehrere Ausführungseinheiten, die hier Steuergeräte 120, intelligente Mechatronikeinheiten 132] sowie Aktoren und Sensoren 134 (hier soll nicht nach Aktoren und Sensoren unterschieden werden) umfassen.
-
Die Zonensteuergeräte 120A, 120B, 120C, 120D sind beispielhaft jeweils einer Zone „vorne“, „hinten“, „links“ und „rechts“ zugeordnet und sind jeweils über ein erstes Kommunikationssystem 112, z.B. Ethernet, kommunikativ an den Fahrzeugzentralrechner 110 angebunden, was eine Kommunikation jedes der Zonensteuergeräte jeweils mit dem Fahrzeugzentralrechner 110 erlaubt. Außerdem weist der Fahrzeugzentralrechner 110 beispielhaft eine drahtlose Kommunikationsverbindung 114 (bzw. ein entsprechendes Kommunikationsmodul) auf, um z.B. mit einer fahrzeugfremden Recheneinheit („Cloud“) kommunizieren zu können, wie später noch näher erläutert wird. Der Fahrzeugzentralrechner 110 könnte aber z.B. auch nur an ein solches Kommunikationsmodul angebunden sein.
-
Die Ausführungseinheiten 130, 132, 134 sind jeweils einem der Zonensteuergeräte zugeordnet und sind über eine zweite Kommunikationsverbindung 122 wie z.B. einen CAN- oder LIN-Bus mittelbar oder unmittelbar an das betreffende Zonensteuergerät kommunikativ angebunden. Beispielsweise ist das dem Zonensteuergerät 120A zugeordnete Steuergerät 130 unmittelbar an das Zonensteuergerät angebunden, einer der Sensoren/Aktoren 134 hingegen mittelbar, nämlich über das Steuergerät 130; dieser Sensor/Aktor 134 ist insbesondere unmittelbar an das Steuergerät 130 angebunden. Andere Sensoren/Aktoren 134 sind z.B. auch unmittelbar an das Zonensteuergerät angebunden, gleiches gilt für intelligente Mechatronikeinheiten 132.
-
Die zweiten Kommunikationssysteme 122 für die Anbindung der Ausführungseinheiten an die Zonensteuergeräte bzw. ggf. untereinander müssen nicht notwendigerweise alle identisch sein, denkbar ist eine Unterscheidung je nach Art der Ausführungseinheit. So sind einfachere Sensoren z.B. nur über LIN angebunden, etwas komplexere Steuergeräte z.B. über CAN. Die Zonensteuergeräte weisen aber entsprechende Schnittstellen auf.
-
Auf die konkrete Art oder Funktionalität der Ausführungseinheiten 130, 132, 134 kommt es für die vorliegende Erfindung nicht an; beispielsweise können die Ausführungseinheiten 130, 132, 134, die dem Zonensteuergerät 120A und damit der Zone „vorne“ zugeordnet sind, z.B. Leuchten oder Aktoren für Scheibenwischer oder ähnliches umfassen. Ähnliches gilt für das Zonensteuergerät 120B bzw. die Zone „hinten“. Die den Zonensteuergeräten 120C, 120D bzw. den Zonen „links“ und „rechts“ zugeordneten Ausführungseinheiten kann es sich z.B. um Taster und Aktoren für Fensterheber handeln. An dieser Stelle sei nochmals erwähnt, dass dieses Bordnetz nur rein bespielhaft ist und der Erläuterung der Erfindung dienen soll.
-
Das gezeigte Bordnetz 100 macht allerdings deutlich, dass durch die Zonensteuergeräte eine gezielte Zuordnung bzw. Aufteilung der einzelnen Ausführungseinheiten nach geometrischen Zonen bei nur einem Fahrzeugzentralrechner (oder ggf. wenigen Fahrzeugzentralrechnern) möglich ist, wodurch die gesamte (kumulierte) Länge an Kabeln für das Bordnetz gegenüber herkömmlicher E/E-Architektur mitunter deutlich reduziert werden kann.
-
An dieser Stelle sei erwähnt, dass dies insbesondere die Kommunikationssysteme bzw. Kommunikationsmedien betrifft. Es versteht sich, dass für die einzelnen Einheiten auch eine Energie- bzw. Stromversorgung nötig ist, die hier nicht weiter behandelt werden soll.
-
In 2 ist schematisch eine Zonenarchitektur eines Bordnetzes zur Erläuterung der Erfindung dargestellt. Das hier gezeigte Bordnetz ist vergleichbar dem Bordnetz 100 aus 1, allerdings mit etwas veränderter Anzahl an einzelnen Einheiten; die Bezeichnungen entsprechen aber denjenigen aus 1. So sind z.B. nur die drei Zonensteuergeräte 120A, 120B, 120C gezeigt, denen jeweils Ausführungseinheiten zugeordnet sind, deren Anzahl ggf. von der aus 1 abweicht. Dies hat auf die Funktionsweise der Erfindung allerdings keinen Einfluss.
-
Wie schon erwähnt, wird im Rahmen der Erfindung eine Zonenarchitektur verwendet, die drei Ebenen aufweist, denen die einzelnen Einheiten zugeordnet sind. Der Fahrzeugzentralrechner 110, hier beispielhaft mit Mikrocontroller 116 und Mikroprozessor 118 gezeigt, ist der Rechenebene R zugeordnet. Ebenso ist eine fahrzeugfremde Recheneinheit 140 (es handelt sich dabei z.B. um einen zentralen, entfernt vom Fahrzeug angeordneten Server oder Hochleistungsrechner, der Speicher und Rechenleistung zur Verfügung stellt) gezeigt, an die der Fahrzeugzentralrechner über die drahtlose Kommunikationsverbindung 114 angebunden ist. Die fahrzeugfremde Recheneinheit 140 ist ebenfalls der Rechenebene R zugeordnet.
-
Die Zonensteuergeräte 120A, 120B, 120C sind der Zonenebene Z zugeordnet und die Ausführungseinheiten 130, 132, 134 sind der Ausführungs- oder Embedded-Ebene E zugeordnet. Innerhalb der Ausführungsebene E sind die Steuergeräte 130 und intelligenten Mechatronikeinheiten 132 in einer Zwischenstufe über den Sensoren/Aktoren 134 angeordnet, was für die Funktionsweise der Erfindung allerdings keinen Einfluss hat.
-
Mit den schon in Bezug auf 1 erläuterten Kommunikationssystemen und der kommunikativen Anbindung ergibt sich als Kommunikationskonzept, dass eine Kommunikation zwischen einer Ausführungseinheit (in der Ausführungsebene E) und dem Fahrzeugzentralrechner (in der Rechenebene R) immer bzw. nur über ein Zonensteuergerät (in der Zonenebene Z) erfolgt. Eine Kommunikation zwischen zwei Zonensteuergeräten wiederum erfolgt immer bzw. nur über die Rechenebene R. Die Zonensteuergeräte selbst dienen damit nur als eine Art Gateway oder Tunnel. Jedes Zonensteuergerät gibt eingehende Daten inhaltlich unverändert wieder aus, allenfalls eine formale Anpassung an das andere Kommunikationssystem, z.B. von LIN auf Ethernet oder Ethernet auf CAN, oder Kapselung wird vorgenommen.
-
In 3 ist schematisch ein Teil eines Bordnetzes zur Erläuterung der Erfindung detaillierter dargestellt. Insbesondere sind hier der Fahrzeugzentralrechner 110 sowie die Zonensteuergeräte 120A, 120B, 120C aus 2 detaillierter gezeigt, anhand dessen das im Rahmen der Erfindung vorgeschlagene Konzept der Konfiguration von Zonensteuergeräten und deren Einbindung in die Fahrzeugzentralrechner erläutert werden soll. Die den Zonensteuergeräten zugeordneten Ausführungseinheiten weichen in ihrer Anzahl ggf. von den in 1 und 2 gezeigten Situationen ab. Dies hat auf die Funktionsweise der Erfindung allerdings keinen Einfluss.
-
Auf dem Mikrocontroller 116 des Fahrzeugzentralrechners sollen hier beispielhaft drei Anwendungen in Form von „Software Components“ (SWCs) 200 laufen, zudem sind eine signal-basierte Schnittstelle 202 (bzw. „Signal Dispatcher“) und eine service-basierte Schnittstelle 204 („Service Interface“) vorgesehen. Auf dem Mikroprozessor 118 des Fahrzeugzentralrechners sollen hier beispielhaft drei Anwendungen in Form von „Applikationen“ (Apps) 212 laufen, zudem sind eine service-basierte Schnittstelle 214 („Service Interface“) und eine „Update Dispatcher“ 216 (eine Einheit, die für Software-Updates bzw. deren Verteilung vorgesehen ist) vorgesehen. Die service-basierten Schnittstellen 204 und 214 stehen zusammen eine „Service-orientiere-Architektur“ 206 bereit. Entscheidend ist hier eine Signal-nach-Service-Wandlung; dies kann bevorzugt auf Seiten des Mikrocontrollers (dann Schnittstelle 204) oder auf Seiten des Mikroprozessors (dann Schnittstelle 214) erfolgen. Dann wird auf dem jeweils anderen insbesondere nur noch ein Link (Verbindung) zum Signal bzw. zur Applikation bereitgestellt.
-
Weiterhin sind hier beispielhaft auf dem Mikrocontroller 216 die Datensätze 210A, 210B und 210C vorgesehen, die zu den drei gezeigten Zonensteuergeräten 120A, 120B und 120C gehören, die basierend auf entsprechenden Beschreibungsdateien erzeugt wurden (die Datensätze entstehen also durch die Konfiguration) und auf die eine hier beispielhaft mit 208 bezeichnete Zwischenanwendung bzw. „Middleware“ Zugriff hat. Ebenso könnten die Datensätze (zusätzlich) auf dem Mikroprozessor 118 vorgehhalten werden bzw. für die Erstellung der entsprechenden Konfiguration herangezogen werden. Es können z.B. Teile beschrieben sein, die direkt vom Mikroprozessor 118 als Update kommuniziert werden. Wie erwähnt, sind in den Datensätzen die Schnittstellen der Zonensteuergeräte zu den daran angebundenen bzw. anbindbaren Ausführungseinheiten beschrieben. Damit kann der Fahrzeugzentralrechner über die Zonensteuergeräte auf die Ausführungseinheiten zugreifen.
-
Weiterhin ist eine Kommunikationsschnittstelle zwischen dem Fahrzeugzentralrechner 110 und den Zonensteuergeräten vorgesehen, die auf Seiten des Fahrzeugzentralrechners 110 in zwei Teilen bereitgestellt wird. Ein Teil 230.1 wird auf dem Mikrocontroller 216 ausgeführt und deckt dabei ein- und ausgehende Daten 232 (Input/Output) sowie ein Gateway 234 für das zweite Kommunikationssystem, also z.B. CAN, LIN, ab. Ein Teil 230.2 hingegen wird auf dem Mikroprozessor 218 ausgeführt und deckt eine Switch-Funktion 236 für das erste Kommunikationssystem, z.B. Ethernet, ab und dient für Updates 238.
-
Auf jedem der Zonensteuergeräte 120A, 120B, 120C ist ein Gegenstück 230.3 der Kommunikationsschnittstelle vorgesehen, die jeweils sämtliche Funktionen abdeckt. Auf diese Weise hat der Fahrzeugzentralrechner Zugriff auf die an die Zonensteuergeräte angebundenen Ausführungseinheiten und kann z.B. Daten von dort empfangen, Daten dorthin übermitteln oder kann Software-Updates für diese (über das Zonensteuergerät als Puffer) bereitstellen.
-
In 4 ist schematisch ein Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform dargestellt, der das Einrichten eines Bordnetzes in einem Fahrzeug umfasst.
-
In einem Schritt 300 kann ein Hersteller eines Zonensteuergeräts dieses zunächst designen, und zwar entsprechend der später im Fahrzeug anzuschließenden bzw. angeschlossenen Peripherie (die Ausführungseinheiten), und das notwendige Programm erstellen, um mit der Peripherie interagieren zu können.
-
Basierend auf den Informationen des Programms (diese können z.B. maschinell während der Generierung des Programms erfasst werden) und weiteren Beschreibungsdateien, die die angeschlossene Peripherie mitliefert (z.B. Kommunikationsinterface der angeschlossenen Peripherie im Autosar ARXML oder Vector DBC Standard), erzeugt bzw. erstellt z.B. der Hersteller des Zonensteuergeräts in Schritt 310 eine für das Zonensteuergerät gültige Beschreibungsdatei, die er dem Fahrzeughersteller bereitstellt.
-
Der Fahrzeughersteller konfiguriert in Schritt 320 dann die Zwischenanwendung („Middleware“) auf dem Fahrzeugzentralrechner (oder auch auf mehreren Fahrzeugzentralrechnern, sofern anwendbar) unter Verwendung der Beschreibungsdatei. Es werden also die Datensätze erstellt (die Zwischenanwendung verfügt - über die Datensätze - also über die Informationen über die Schnittstellen auf den Zonensteuergeräten). Die darauf laufenden Anwendungen (SWCs und Apps) werden mit den relevanten Informationen der Zone (der ein Zonensteuergerät zugeordnet ist) verbunden. Die Anbindung kann sowohl signal-basiert als auch service-basiert erfolgen, hier sind, wie erwähnt, die entsprechenden Schnittstellen vorhanden. Informationen wie Datentyp, Umrechnung, etc. sind für eine Anbindung typischerweise relevant. Ggf. sind auch weitere Parameter der beschriebenen Schnittstelle zu definieren (z.B. Frequenz eines PWM-Signals), sofern diese angeboten werden. Im Fall einer service-basierten Anbindung beschreibt die Konfiguration z.B. zusätzlich die Wandlung von Signal nach Service. Die Konfiguration kann z.B. mit Tools erfolgen, die ebenfalls durch den Hersteller des Zonensteuergeräts bereitgestellt werden. Die Konfiguration unterstützt z.B. sowohl sog. Pre-Compile-Konfigurationen als auch Post-Build-Konfigurationen.
-
Nachdem in Schritt 330 die Konfiguration (also die Zwischenanwendung bzw. „Middleware“) auf dem Fahrzeugzentralrechner eingebracht und aktiviert wurde, erfolgt in Schritt 340 die Signal-Umrechnung und Service-Wandlung der signal-basierten Information der Zonensteuergeräte zur Laufzeit (also während des Betriebs) auf dem Fahrzeugzentralrechner entsprechend der Konfiguration in der „Middleware“. Die Kommunikation erfolgt zwischen Zonensteuergerät und Fahrzeugzentralrechner über die beschriebene Kommunikationsschnittstelle.
-
Weiterhin sind beispielhaft zwei Szenarien eines nachträglichen Updates dargestellt. In Schritt 350 ist ein Update einer an das Zonensteuergerät angeschlossenen Peripherie (Ausführungseinheit) gezeigt, z.B. das Ersetzen eines angeschlossenen „Smart Actuators“ durch ein Produkt eines anderen Herstellers oder auch eine einfache Erweiterung einer angeschlossenen Peripherie. Änderungen müssen sich nicht auf den Programmcode des Zonensteuergeräts auswirken, da dieses die Rolle eines transparenten Datenverteilers einnimmt, wie ausführlich erläutert. Die Änderung kann daher allein über ein Update der Beschreibungsdatei und dann - über entsprechende Konfiguration - des Datensatzes erfolgen und den entsprechenden Anpassungen auf Seiten des Fahrzeugzentralrechners.
-
In Schritt 360 ist ein Update gezeigt, bei dem eine neue oder geänderte Fahrzeugfunktion als SWC oder App auf dem Fahrzeugzentralrechner eingebracht wird (und die dort dann später auszuführen ist). Da die Beschreibung der angeschlossenen Sensorik und Aktuatorik des Fahrzeugs bereits auf dem Fahrzeugzentralrechner in der Form des Datensatzes verfügbar ist, ist auch lediglich eine Anpassung der Konfiguration der „Middleware“ auf dem Fahrzeugzentralrechner notwendig.
