-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben einer Recheneinheit, insbesondere auch eines Systems mit mehreren Recheneinheiten, sowie eine Recheneinheit bzw. ein System und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
In Fahrzeugen können Steuergeräte verwendet werden, die verschiedene Programmfunktionen oder Funktionen oder Anwendungen bzw. Programme oder Programmteile bereitstellen, die für das von dem Steuergerät betriebene mechatronische System, z.B. ein Bremsregelsystem, verwendet werden. Solche Funktionen oder Anwendungen, insbesondere wenn sie sich auf das konkrete mechatronische System beziehen, werden herkömmlicherweise alle auf dem betreffenden, einzelnen Steuergerät bereitgestellt und sind auch nur dafür ausgelegt.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Betreiben einer Recheneinheit sowie eine Recheneinheit bzw. ein System und ein Computerprogramm zu dessen Durchführung 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 dem Betreiben einer oder mehrerer kommunikativ verbundener Recheneinheiten sowie dem Ausführen einer oder mehrerer Programmfunktionen (im Folgenden auch einfach als Funktionen bezeichnet) oder Anwendungen darauf, die z.B. für ein bestimmtes mechatronisches System in einem Fahrzeug vorgesehen sind (dies muss aber nicht notwendigerweise so sein). Zwischen solchen Funktionen wird eine Kommunikation ermöglicht, sodass die Funktionen z.B. untereinander Daten oder andere Informationen austauschen können oder allgemein eine Funktion auf eine andere Funktion zugreifen kann. Im Rahmen der Erfindung wird es ermöglicht, dass diese Funktionen nicht - wie bisher üblich - auf einer einzelnen Recheneinheit (wie z.B. einem Steuergerät eines Fahrzeugs) bereitgestellt bzw. ausgeführt werden müssen, sondern über verschiedene Recheneinheiten, die z.B. untereinander vernetzt bzw. kommunikativ verbunden sind, verteilt sein können, und das insbesondere plattform- und/oder betriebssystemunabhängig. Insofern kann z.B. eine Funktion auch z.B. in einem entfernt von einer anderen Recheneinheit angeordneten und drahtlos damit kommunikativ verbundenen Server oder ähnlichem („Cloud“) vorgesehen sein.
-
Dazu bedient sich die Erfindung verschiedener Schichten, die entsprechend bereitgestellt bzw. eingerichtet werden, ähnlich einem sog. OSl-Modell (auch als ISO/OSI-Referenzmodell bezeichnet), das allgemein ein Referenzmodell für Netzwerkprotokolle als Schichtenarchitektur ist. Zweck des OSl-Modells ist beispielsweise, Kommunikation über unterschiedlichste technische Systeme hinweg zu beschreiben und die Weiterentwicklung zu begünstigen. Dazu definiert dieses Modell sieben aufeinanderfolgende Schichten (engl.: „layers“) mit jeweils eng begrenzten Aufgaben. In der gleichen Schicht mit klaren Schnittstellen definierte Netzwerkprotokolle sind einfach untereinander austauschbar, selbst wenn sie wie das Internet Protocol eine zentrale Funktion haben. Die Schnittstellen zwischen den Schichten sind beim OSl-Modell abstrakt standardisiert. Im Idealfall ist eine Komponente, die entsprechend dem OSl-Modell implementiert wurde, austauschbar, ohne dass sich der Zweck und die Funktionsfähigkeit des Systems elementar verändern.
-
In üblichen, kommunikationsorientierten Systemen mit Client-Server-Architektur können z.B. drei Arten von Kommunikation unterschieden werden, die sich hinsichtlich Auslöser und Richtung von Daten- und Kontrollfluss unterscheiden:
- Erstens: Parameter (der Kontrollfluss geht vom Client aus, dieser greift lesend oder schreiben auf einen Parameter des Servers zu);
- Zweitens: Methode oder sog. „Remote-Procedure-Call“ (Kontrollfluss und ggf. Steuerdaten gehen vom Client an den Server, dieser antwortet ggfs. mit einem Rückgabewert); und
- Drittens: Ereignis (bei Interesse an einem bestimmten Ereignis und ggfs. zugehöriger Prozessdaten eröffnet der Client ein Abonnement für ein Ereignis beim Server. Dieser quittiert üblicherweise den Eingang der Anfrage. Der eigentliche Kontroll- und Datenfluss bei Eintritt eines Ereignisses findet zeitlich unabhängig vom Server zum Client statt).
-
Im Rahmen der Erfindung kommen nun insbesondere zwei bestimmte Arten von Schichten zum Einsatz, die auf jeder Recheneinheit, auf der eine Funktion ausgeführt wird, durch einen entsprechenden Bereitstellungsmechanismus bereitgestellt werden: eine Funktions-Kommunikations-Abstraktions-Schicht (engl.: „Feature Communikation Abstraction Layer“, FCAL) und eine Funktions-Integrations-Schicht (engl.: „Feature Integration Layer“, FIL, oder auch „Feature Integration Library“). Diese beiden Schichten (die selbst wiederum jeweils mehreren Schichten umfassen können) erfüllen zwei zentrale Aufgaben.
-
Auf der einen Seite ermöglichen sie es (insbesondere in Kombination) einem Entwickler von App-Like-Software (also eine Funktion oder Anwendung), die zugrundeliegende Software-Kommunikationsinfrastruktur zu nutzen. Zudem ist die Implementierung nicht auf eine spezifische Maschine oder ein spezifisches System beschränkt, sondern verhält sich dynamisch, also verändert sich automatisch mit wechselnden Varianten einer angeschlossenen Hardware. Es können also insbesondere (bei der FIL) Treiber und/oder bereitgestellte Schnittstellen zur Laufzeit bei Bedarf angepasst werden, insbesondere dynamisch. Der Entwickler einer Anwendung oder Funktion wird bei der Verarbeitung dieser potentiellen Dynamik bzgl. verbundener Hardware - und damit verfügbarer API (API steht für engl. „Application Programming Interface“ und bezeichnet eine Programmier- oder Anwenderschnittstelle) - durch die verwendete Plattform unterstützt. Darüber hinaus werden bestimmte Varianten bzgl. Prozessparametern durch die Plattform (in den Schichten bzw. deren Schnittstellen) berücksichtigt und sind damit für den Anwendungssoftwareentwickler nicht mehr relevant (z.B. Einheiten von Soll-/Istgrößen auf internen Signalen und auf Bussystemen). Insbesondere die FIL erlaubt z.B., dass verschiedene Gegenstücke zu verschiedenen Schnittstellen eines Schichten-Modells, insbesondere des OSl-Modells, gebildet werden, vorzugsweise mit unterschiedlichen Abstraktionsstufen oder Abstraktionslevel.
-
Durch die Verwendung einer auf Schichten basierenden Kommunikationsarchitektur (Schnittstellen) kann die gesamte Systemarchitektur modular gestaltet bzw. statisch und dynamisch verändert werden. Beispielsweise kann die Implementierung eines Kommunikationsbrokers (auch als FCB bezeichnet, engl.: „Feature Communication Broker“; dabei handelt es sich um eine weitere Schicht, die eine Schnittstelle mit z.B. Umwandlung von Protokollen ermöglicht) ohne Veränderung der gesamten Architektur ausgetauscht werden (statische Veränderung). Auf der anderen Seite kann z.B. zur Laufzeit ein Treibermodul (z.B. im Rahmen der FIL) nachgeladen werden (dynamische Veränderung).
-
Ergänzend kommt nun aber hinzu, dass insbesondere diese beiden Elemente oder Schichten - Funktions-Kommunikations-Abstraktions-Schicht und Funktions-Integrations-Schicht - es ermöglichen, dass bestehende Funktionen von mechatronischen Systemen, die derzeit geschlossen auf einer Recheneinheit vorliegen, in verteilten System verarbeitet werden können. Die einzelnen Funktionen (es kann sich dabei auch um Sub- bzw. Unterfunktionen von übergeordneten Funktionen handeln) können so in einem Netz von Recheneinheiten verteilt werden, wobei diese Recheneinheiten nicht in einem Steuergerät oder einer Maschine vorliegen müssen, sondern zudem auch über Maschinen hinweg verwendbar sein können, wie eingangs schon erwähnt. Denkbar ist hier z.B. eine kooperative Verarbeitung von Daten von zwei zueinander gehörenden Systemen - diese Zugehörigkeit kann z.B. örtlich, rechtlich, durch Eigentum oder einen Verkauf von Rechenleistung begründet sein.
-
Zudem kann eine Auslagerung und Aggregation von Funktionen verschiedener Recheneinheiten verschiedener Systeme in teilzentrale (vgl. Edge-Computing) und zentrale Recheneinheiten (vgl. Cloud-Computing) realisiert werden, was hinsichtlich Kosten, Zuverlässigkeit oder Funktionsumfang Vorteile bieten kann.
-
Mit den vorgeschlagenen Schichten wird bereits eine Menge von Schnittstellen definiert, die eine agnostische (d.h. unabhängige) Verwendung von Steuergeräte-externe Schnittstellen, Aktorik und Sensorik ermöglichen. Dies wird durch die zwei komplementären Elemente FCAL und FIL erreicht. Die FIL stellt insbesondere eine zur Laufzeit dynamisch veränderbare Datenbank mit Schnittstellen aus der Systemumgebung (z.B. aus Bussystemen) und Infrastrukturkomponenten im System dar. Diesem Vorteil steht die FCAL gegenüber. Diese kann als eine Art modifizierbarer Adapter verstanden werden, deren Bestandteile (dabei kann es sich z.B. um eine FCAL-API und eine FIL-API handeln) beispielsweise eine service-orientierte sowie eine container-basierte Systemarchitektur ermöglicht.
-
Zudem ermöglicht die FCAL auch die Kommunikation über tieferliegende Kommunikationsebenen. Die FCAL abstrahiert auch mögliche Schnittstellen zwischen Funktionen selbst und erlaubt so einen effizienten, verteilten Aufbau von Funktionen, wie vorstehend schon erläutert. Denkbar sind hier z.B. auch Hilfsfunktionen wie Bibliotheken, Datenverarbeitung und Datenspeicherung und ähnliche Funktionsblöcke, die von einer solchen zentralisierten, hochwertigen Umsetzung profitieren. Durch die generische, abstrahierte Umsetzung der Schnittstellen dieser Hilfsfunktionen sind zudem neuartige Zusammenarbeitsmodelle zur Entwicklung von komplexen Funktionen möglich.
-
Ein besonderer Vorteil hierbei ist, dass mit derselben Architektur nahezu alle von Steuergeräten (ECU) unterstützten Schnittstellen bzgl. deren Infrastruktur und über Bussysteme angebundene dritte Systeme von App-Like-Software (Anwendungen) abstrahiert und agnostisch genutzt werden können. In derselben Art und Weise können auch die Schnittstellen zwischen den Funktionen agnostisch genutzt werden. Dies ermöglicht eine steuergeräte-unabhängige Entwicklung von Nutz-und/oder Anwendungssoftware (Funktionen, App-Like-Software) wodurch Effizienzsteigerungen in der Entwicklung ermöglicht werden. Durch die Dekomposition von derzeit geschlossenen Funktionalitäten durch Nutzung dieser Systemstruktur bzw. Systemarchitektur ergeben sich noch weitere Räume für Effizienzsteigerungen sowie neue Möglichkeiten für Funktionszusammensetzungen und verteilte Entwicklung. Insbesondere stellt die Verwendung der erwähnten APIs eine zentrale Schnittstelle der service-orientierten Softwarekomponenten und deren jeweiligen Vorteile dar.
-
Eine erfindungsgemäße Recheneinheit, z.B. ein Steuergerät eines Kraftfahrzeugs bzw. ein System mit mehreren solchen Recheneinheiten ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
-
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 eine Anordnung von Recheneinheiten, bei der ein erfindungsgemäßes Verfahren durchführbar ist.
- 2 bis 5 zeigen schematisch verschiedene Schichten, wie sie bei erfindungsgemäßen Verfahren in verschiedenen bevorzugten Ausführungsformen zum Einsatz kommen können.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch ein Fahrzeug 100 gezeigt, in dem beispielhaft drei Recheneinheiten 110, 112, 114 (es kann sich dabei insbesondere um Steuergeräte handeln) vorgesehen sind, die mittels beispielhaft zweier verschiedener Kommunikationsmedien 120, 122 (z.B. CAN, Ethernet) in Kommunikationsverbindung stehen. Zudem ist über eine drahtlose Kommunikationsverbindung 130 eine Kommunikation mit einer außerhalb des Fahrzeugs 100 angeordneten Recheneinheit 140, z.B. einem Server einer Cloud, möglich. Es versteht sich, dass auch die anderen Recheneinheiten untereinander oder anderweitig Daten austauschen können.
-
Beispielhaft ist eine Software oder Programmfunktion 150 gezeigt, die vier verschiedene Funktionen oder Anwendungen oder Programmteile F1, F2, F3 und F4 (es können auch mehr oder weniger sein) umfasst, die zwar zusammen z.B. den Betrieb eines bestimmten mechatronischen Systems ermöglichen, aber auf den vier verschiedenen Recheneinheiten 110, 112, 114 und 140 verteilt ausgeführt werden können. Beispielsweise stellt ein adaptives Thermomanagement solch eine Funktion dar: In einem embedded (eingebetteten) Steuergerät (SG) (z.B. die Recheneinheit 114) des Fahrzeuges werden verschiedene Daten (wie z.B. Temperatur, Feuchtigkeit, ...) über Sensoren oder virtuelle Sensoren erfasst. Diese Daten werden z.B. in einer weiteren Recheneinheit (z.B. 112) aggregiert und über eine drahtlose Verbindung (z.B. 110) an eine weitere Recheneinheit (z.B. 140, z.B. in Cloud) übertragen, mit denen dann anhand komplexer Modelle Adaptionsparameter beispielsweise zur Korrektur von Einspritzparametern )wie z.B. ein Ansteuerbeginn und/oder eine Ansteuerdauer eines Einspritzventils) ermittelt werden, die dann zu einer weiteren Recheneinheit (z.B. 110) im Fahrzeug übertragen wird und diese (110) dann die Aktoren (z.B. Leistungsschalter zur Ansteuerung von Kraftstoffeinspritzventilen) direkt ansteuert. Analog können dann verschiedene andere verteilte Funktionen dargestellt werden.
-
Die im Rahmen der Erfindung vorgeschlagene Architektur umfasst mehrere Dimensionen, die im Folgenden separat erläutert werden sollen. Die unterschiedlichen Elemente beschreiben dabei die unterschiedlichen Aufgaben, Funktionsweisen und Vorteile der FCAL sowie der FIL. Die FCAL sowie die FIL stellen insbesondere eine Erweiterung und Verbesserung bestehender Schichtenmodelle zur Kommunikation (wie z.B. des erwähnten OSl-Modells) dar. Solche Schichten sind beispielhaft in 2 für eine Funktion 200 gezeigt.
-
Die FCAL 210 mit ihren Schnittstellen (APIs, insbesondere FIL-API und FCAL-API) orientiert sich insbesondere an den klassischen Schichten des OSI-Schichtenmodells. Die Umsetzung der FCAL sowie der FIL 230 ist targetunabhängig, d.h. unabhängig von der Ziel-Hardware. Gemäß obigem Verständnis können hierbei die einzelnen Komponenten ausgetauscht werden. Dies bedingt lediglich, dass die jeweiligen Zwischenschichten entsprechend ausgetauscht werden. Beispielsweise kann die Implementierung des FCB 220 getauscht werden, während die restliche Architektur (mit Ausnahme der FCAL-API) nicht verändert werden muss.
-
Im Gegensatz zum OSI-Modell findet die Kommunikation dabei insbesondere anhand einer „Contract Based Communication“ statt: Schnittstellen bzw. APIs sind nicht nur APIs, sondern besitzen zweckmäßigerweise auch ein Gütekriterium (z.B. Reaktionszeit - „Vertrag darüber, dass Antwort in x Sekunden erfolgt“) Eine Validierung dieser „Contract Based Communication“ ist dann z.B. nur durch die FIL möglich, da diese auch die physikalische Seite „sieht“ (z.B. ISOBUS oder I/O in der Schicht 270). FCAL und FIL stellen dabei einzelne Schichten dar, welche wiederum selbst aus Schichten bestehen oder zumindest bestehen können.
-
Die FIL 230 umfasst als ein zentrales Element einen sog. FIL-Koordinator 232, der konkrete Instanzen von generischen Maschinenmodellen (auch über den ISOBUS hinausgehend, für z.B. Maschinen mit proprietären Schnittstellen; bei ISOBUS handelt es sich um einen Datenbus bei landwirtschaftlich genutzten Geräten bzw. Fahrzeugen) mit I/O-Modulen verbindet. Diese Module können unterschiedlicher Gestalt (verschiedene Programmiersprachen, syntaktische Tiefe usw.) sein. Aus diesem Grund ist die FIL 230 in der Lage, unterschiedliche Gegenstücke zu verschieden Schnittstellen des OSl-Modells zu bilden, und zwar mit unterschiedlichen Abstraktionsstufen/-level, wie dies z.B. in 3 mit Level L1 bis L7 für verschiedene Komponenten 300, 302, 304, 306 dargestellt ist.
-
Diese Komponenten können einfache Treiber sein, z.B. für aktive und passive Sensoren oder Aktoren wobei nur eine elektrische Spannung gemessen bzw. ein PWM (Pulsweitenmoduliertes) Stellsignal vorgegeben wird. Der FIL übernimmt die weiteren Funktionen bis zum FCB. D.h. der FIL macht aus dem elektrischen Signal (Spannung bzw. PWM) ein physikalisches Signal bzw. umgekehrt und aus dem physikalischen Signal wird ein Service für den FCB generiert und umgekehrt. Die Erkennung, um welchen Level es sich handelt erkennt der FIL z.B. aus dem Manifest (einem Konfigurationsverzeichnis) der betroffenen Komponente.
-
Im genannten Aktuator-Beispiel könnte das das Sprayventil betreffen, im untersten Level gibt es dann ein PWM-Signal und eine Dauer, im Level darüber einen mittleren Strom und eine Dauer, darüber dann die Spritzrate und die Dauer, darüber im Level schließlich eine Spritzmenge bzw. einen Service „stelle Spritzmenge XY ein“.
-
Im genannten Sensor-Beispiel Temperatur könnte das eine Motortemperatur betreffen, im untersten Level gibt es dann eine Spannung, darüber eine Temperatur, darüber eine Plausibilisierung des Temperaturbereichs und - Temperaturverlaufs und Filterung, bzw. einen Service „erfasse die Motortemperatur“.
-
Daneben kann die FIL 230 noch einen FIL-ISOBUS-Adapter 234 mit FIL-VAR1 236, FIL-‚AdaptBase Part‘ 238, FIL-VAR2 240 und FIL-VAR3 242 umfassen. Ebenso einen gemischten FIL-Adapter 244. In einer weiteren Schicht kann die FIL 230 z.B. einen VAR1-Stack 246 (eine Bibliothek für ISOBUS), einen VAR2-Stack 248 (eine alternative Bibliothek für ISOBUS), einen VAR3-Stack 250 (eine weitere alternative Bibliothek für ISOBUS), weitere CANs 252, einen GNSS-Service 256, einen Sensor-Service 256 sowie einen Aktuator-Service 258 umfassen.
-
In einer weiteren Schicht 260, einer Software- oder Betriebssystemschicht, nach der FIL 230 können dann ein Socket-CAN 262, ein GNSSTreiber 264 (GNSS steht dabei für Global Navigation Satellite System) sowie weitere Treiber 266 folgen, schließlich eine Schicht 270, die auf Hardware-Ebene liegt und z.B. physikalische Kommunikationsschnittstellen wie CAN, LIN, FlexRay, Ethernet, I/O und dergleichen umfasst. Die einzelnen Begriffe sollen nachfolgend kurz erläutert werden:
- ISOBUS: konform zu der Norm ISO 11783. Diese Norm definiert erstens die physikalischen Eigenschaften, wie Stecker und Leitungen, zweitens die Art der Teilnehmer und drittens die Datenformate und Schnittstellen des Netzwerkes.
- FIL-VAR1, FIL-VAR2, FIL-VAR3: Adapter zu Varianten der ISOBUS-Implementierungen.
- VAR1-Stack, VAR2-Stack, VAR3-Stack: Varianten der ISOBUS-Implementierungen.
- CAN: CAN ist als ISO 11898 international standardisiert und definiert die Layer 1 (physische Schicht) und 2 (Datensicherungsschicht) im ISO/OSI-Referenzmodell.
- LIN (Local Interconnect Network): Der LIN-Bus ist ein kostengünstiges serielles Kommunikationsprotokoll, das Remote-Anwendungen innerhalb eines Fahrzeugnetzwerks effektiv unterstützt. Es soll das bestehende CAN-Netzwerk ergänzen, was zu hierarchischen Netzwerken innerhalb von Autos führt.
- FlexRay: serielles, deterministisches und fehlertolerantes Feldbussystem für den Einsatz im Automobil, vergleichbar mit TTP.
- Ethernet: eine Technik, die Software (Protokolle usw.) und Hardware (Kabel, Verteiler, Netzwerkkarten usw.) für kabelgebundene Datennetze spezifiziert, welche ursprünglich für lokale Datennetze (LANs) gedacht war und daher auch als LAN-Technik bezeichnet wird. Sie ermöglicht den Datenaustausch in Form von Datenframes zwischen den in einem lokalen Netz (LAN) angeschlossenen Geräten (Computer, Drucker und dergleichen).
- Socket: ein vom Betriebssystem bereitgestelltes Objekt, das als Kommunikationsendpunkt dient. Die Kommunikation über Sockets erfolgt in der Regel bidirektional, das heißt, über das Socket können Daten sowohl empfangen als auch gesendet werden.
- GNSS ist ein globales Navigationssatellitensystem (englisch Global Navigation Satellite System) zur Positionsbestimmung und Navigation auf der Erde und in der Luft durch den Empfang der Signale von Navigationssatelliten und Pseudoliten. GNSS ist ein Sammelbegriff für die Verwendung bestehender und künftiger globaler Satellitensysteme (z.B. NAVSTAR GPS, GLONASS, Galileo, ...)
- I/O (Input/Output): damit bezeichnet man die Kommunikation / Interaktion eines Informationssystems mit seiner ‚Außenwelt‘, z. B. externe Geräte. Die Geräte selbst sind direkt über Daten-, Steuer- und Adressbusse angeschlossen. Sie enthalten Puffer um Anfragen und Antworten zwischenzuspeichern.
-
Für die FCAL gelten vergleichbare Überlegungen, ein Schema hierzu ist in 4 dargestellt, indem über verschiedene Level (zwischen L1 und L7) eine Kommunikation einer Funktion 200 über eine FCAL-API 212, den FCB 220 sowie eine weitere FCAL-API 214 mit der FIL 230 gezeigt ist.
-
Eine grundlegende Aufgabe zur Implementierung der FCAL ist der Austausch von Informationen zwischen Funktionen; sie soll nämlich ohne Plattformabhängigkeiten (nicht limitiert durch Umsetzung der jeweiligen Plattform z.B. Performanz des jeweiligen FCB), dynamisch konfigurierbar (Erweiterung durch neue ausführbare Einheiten oder Rekonfiguration einer bestehenden ausführbaren Einheit) und sprachagnostisch sein sowie eine Steuerung von Kommunikation und Überwachung (Bandbreitensteuerung) ermöglichen.
-
In der Umsetzung kann hierfür dann auf der Funktions-Seite (Container-Seite) die Verbindung durch die FIL-API (nur diese „sieht“ der Entwickler) ermöglicht werden. Die Verbindung zum FCB wird durch die FCAL-API abgebildet (eine Schicht innerhalb der FCAL. Die FIL ist selbst wieder über eine FCAL-API mit dem FCB verbunden (vgl. 4).
-
Ein weiterer Aspekt ist die dynamische Skalierbarkeit der Interfaces bzw. Schnittstellen. Die objektorientierte Modellierung ermöglicht die Anpassung an verschiedene Maschinengrößen. Dadurch sind Maschinenmodelle skalierbar: Insbesondere z.B. hinsichtlich der Arbeitsbreite einer Feldspritze (1 bis n Düsen) oder einer Reihensähmaschine (Anzahl der Reihen).
-
Es gibt typischerweise eine Menge an Klassen, die abstrakt die unterstützen Maschinentypen der Softwareplattform realisieren (mit „Pflichtmethoden“ und „Variablen“). Dabei unterstützt die objektorientierte Modellierung eine entsprechende Granularität hinsichtlich dessen, was angeschlossen ist (welche Arbeitsmaschine etc.) und was die Funktion leisten kann.
-
Eine beispielhafte Erklärung anhand eines Sprayers (landwirtschaftliches Sprühgerät) mit Abschnittssteuerung (wie er z.B. in der Landwirtschaft verwendet wird) ist wie folgt: Auszuwählende Klassen sind „Sprayer“, „Tank“ und „Abschnitt“; ein Sprayer kann mehrere Tanks haben, ein Tank mehrere Abschnitte usw.; das Sprayerobjekt bietet z.B. Methoden an, um auf die Tankobjekte zuzugreifen; das Tankobjekt bietet z.B. Methoden an, um auf die Abschnittsobjekte zuzugreifen; ein Abschnittsobjekt bietet z.B. Methoden zum Öffnen und Schließen der Düsen an. Der erwähnte Aufbau ermöglicht es damit, innerhalb der Objekthierarchie unterschiedliche Ebenen mit unterschiedlicher Granularität anzusprechen.
-
Andere Beispiele wären z.B. eine landwirtschaftliche Sähmaschine oder eine Baumaschine. Bei letzterer kann es sich insbesondere einen Bagger mit einer Schaufel oder einem (hydraulischen) Hammer handeln insbesondere jeweils in variabler Größe von Schaufel bzw. Hammer, die am Baggerarm angebaut werden können.
-
Wie bereits erläutert, stellt die FIL die zentrale Schnittstelle zur physikalischen Maschine dar. Dies ermöglicht eine bessere Kompatibilität, z.B. falls eine Funktion nur die Ansteuerung eines Abschnitts unterstützt, die Maschine jedoch mehrere unterschiedlich ansteuerbare Abschnitte besitzt. In diesem Fall fasst die FIL die API-Bedarfe der Maschine zusammen. Ebenso wird eine dynamische Anpassung zur Laufzeit ermöglicht; z.B. kann es sein, dass die FIL entdeckt, dass auf dem Anbaugerät neue oder granularere Maschinenschnittstellen vorhanden sind. In diesem Fall sorgt ein Erkennungs-Mechanismus dafür, dass die Verfügbarkeit dieser Maschinenschnittstellen den Funktionen bekannt sind bzw. gemacht werden sowie die notwendigen Treiber (z.B. aus der Cloud) heruntergeladen werden. Bei einer Architektur nach OSI ist dies hingegen nicht möglich, insbesondere nicht zur Laufzeit.
-
Generell ist es damit möglich, dass z.B. eine (neue) Programmfunktion hinzugefügt wird, indem gemäß einem Funktionskonfigurationsverzeichnis der hinzuzufügenden Programmfunktion eine Funktions-Kommunikations-Abstraktions-Schicht der hinzuzufügenden Programmfunktion zugeordnet wird und indem diese Funktions-Kommunikations-Abstraktions-Schicht derart betrieben wird, dass sie eine Schnittstelle von der Programmfunktion zur mittelbaren oder unmittelbaren Kommunikation mit der Funktions-Integrations-Schicht bereitstellt. Eine solche neue Funktion kann dann auf einer Recheneinheit ausgeführt werden, auf der schon andere Funktionen laufen, aber auch auf einer anderen Recheneinheit, die bisher noch nicht beteiligt ist.
-
Wie diese Erklärung schon zeigt, sind ein dynamisches Verhalten zur Laufzeit und damit signifikant neuartige Möglichkeiten für den Einsatz des gesamten Steuergeräts möglich. Jede Funktion kennt ihren minimalen Schnittstellenanspruch/-Bedarf. Solange jedoch keine physikalischen Schnittstellen angeschlossen sind bzw. zur Laufzeit aufgerufen werden, liegen die Schnittstellen unkonkret und generisch vor. Dies endet, sobald physikalische Schnittstellen angeschlossen werden bzw. beim Starten angeschlossen sind.
-
Hierzu sei auf 5 verwiesen, in der die Architektur aus 2 im Grunde nochmals dargestellt ist, jedoch für beispielhaft drei Funktionen 200 (die FIL 230 ist zudem nur als ein Block gezeigt). Auch wenn die Funktionen hier gleich bezeichnet sind, so versteht sich, dass in der Praxis die Funktionen voneinander verschieden sind, aber auf die gleiche Weise eingebunden sind. Die Funktionen 200 sind jeweils als Teil eines Containers 206 dargestellt, in dem neben der Funktion 200 selbst ein Datenspeicher 202, eine Funktionskonfigurationsverzeichnis 204 sowie die der Funktion 200 zugewiesene FCAL 210 vorgesehen sind.
-
Ergänzend ist ein Funktions-GUI-Framework 510 (GUI steht für engl. „Graphical User Interface“, also eine graphische Benutzerschnittstelle) gezeigt, mittels welcher neue Funktionen hinzugefügt oder bestehende Funktionen entfernt werden können. In einem Funktionsintegrations-Framework 520 sind ein Funktionsintegrations-Framework-Dienstprogramm 522 (dieses dient z.B. zum Installieren, Konfigurieren, Updaten, Starten, Stoppen, Pausieren, Wiederaufnehmen und De-Installieren von Funktionen), ein Überwachungsmodul 524 (dient z.B. als Sicherheitsüberwachung oder für Fail-Safe-Mode) sowie ein Speicher 526 für Container mit Funktionen. Zudem ist eine Landungszone 530 (die Landungszone ist eine Zone im Speicher, die alleine für Kommunikation und Austausch zwischen Recheneinheit und ihre Außenwelt reserviert ist) vorgesehen, die eine Eingangszone 532 und eine Ausgangszone 534 umfasst. Zudem ist eine FEK 500 vorgesehen. FEK steht für FEATURE Enabling Kit - und stellt eine Recheneinheit dar, in der das genannte Framework installiert ist und läuft. Funktions-GUI-Framework 510, Funktionsintegrations-Framework 520 und Landungszone 530 befinden sich z.B. auf der Recheneinheit und laufen auch auf dieser Recheneinheit.
-
Das vorstehend erwähnte dynamische Verhalten wird ermöglicht durch folgende dynamischen Abläufe, insbesondere unter Verwendung von Funktions-GUI-Framework 510, Funktionsintegrations-Framework 520 und Landungszone 530 wie vorstehend erwähnt:
- Während des Installationsprozesses können z.B. in einem Verzeichnis (oder Manifest, vgl. Funktionskonfigurationsverzeichnis 204) der Funktionen die benötigten Schnittstellen (i.d.R. Konkretisierung der FIL-API) konkret benannt sein. Die erwarteten Schnittstellen werden in der Registry zentral abgelegt (z.B. auch der I/O-Bedarf). Nach dem Installationsprozess (z.B. im obigen Fall) können in einem Arbitrierungsvorgang FIL und Funktion für jede einzelne API verbunden werden (Kombination); dies ermöglicht ein effizientes Management der APIs). Danach stellt sich die FIL auf die Funktion ein bzw. realisiert die Schnittstellen gemäß der in der Registry vermerkten Schnittstellen. Zudem wird dann z.B. ein Kommunikationsprotokoll, womit die Meta-Kommunikation zwischen FIL und Funktion ermöglicht wird, abgestimmt (typischerweise nicht für Nutzdaten/Kommunikation). Diese Meta-Kommunikation ist für den Austausch von Informationen gedacht, welche sich nicht unmittelbar mit der Ansteuerung von Aktorik, Treibern etc. befassen, sondern die Funktionsfähigkeit und Quality-of-Service (Dienste-Qualität) unterstützen.
-
Nachdem diese Schritte durchlaufen sind, sind Erkennung, die Arbitrierung und das Monitoring (APIs, und Zugriff auf API) aufeinander abgestimmt und ermöglichen der Funktion eine sichere Kommunikation (hinsichtlich funktionaler Sicherheit, Vermeidung von Bitfehlern, Datensicherheit sowie Datenintegrität und Datenkonsistenz).
-
Zusammenfassend ist das Besondere an dem vorgeschlagenen Vorgehen, dass der FIL die Treiber und die Schnittstellen zur Laufzeit (dynamisch) anpassen kann. Wird z.B. ein neues Anbaugerät wie z.B. ein Sprayer (Systemerweiterung) an den Traktor (System) angeschlossen, so werden über den ISOBUS die Konfigurationsdaten des Anbaugerätes (Systemerweiterung) bekannt gegeben. Anhand dieser Informationen erkennt der FIL über seinen Discovery- (Erkennungs-) Mechanismus ob die die Daten und Routinen zur Steuerung dieses Anbaugerätes (Teilsystems) vorhanden sind. Dazu sucht der Discovery-Mechanismus seinen Interfacepool (lokale Datenbank) durch. Fehlende Treiber und Schnittstellen werden automatisch aus der Cloud (Datenbanken mit Konfigurationen) heruntergeladen, installiert und zur Nutzung / Steuerung des Anbaugerätes bereitgestellt. Diese hier beschriebene Dynamik (zur Laufzeit) ist mit der Standardarchitektur nach OSI nicht darstellbar.
-
Dabei betrifft die Anpassung sowohl eine Erweiterung als auch eine Reduzierung von Schnittstellen und Treibern. Wird z.B. ein vorhandenes Feature ersetzt durch ein neues Feature mit weniger Schnittstellen, dann werden die nicht notwendigen Schnittstellen und zugehörige Treiber automatisch durch den FIL entfernt.
-
Weiterführende Konzepte wären z.B. eine Testbarkeit der Funktion, die durch obige Kommunikationsarchitektur erhöht wird. Die FIL kann durch eine Test-FIL ersetzt (z.B. FIL-Mockup) werden. Eine virtuelle Maschinenklasse simuliert (dem Entwickler), dass eine physikalische Maschine existiert. Der Ansatz des Testens kann dahingehend weiterentwickelt werden, dass der Entwickler gegen diese virtuelle Maschinenklasse seinen Code und die Logik entwickelt bzw. testet, ohne Kenntnisse einer realen Maschine zu besitzen oder diese im Zugriff zu haben.
-
Ein besonderer Aspekt im Rahmen der Erfindung ist die schon erwähnte Dekomposition von Funktionen bzw. Funktionalitäten bei mechatronischen Systemen. Die systemabhängigen Schnittstellen der Maschine oder des Fahrzeuges werden durch die FIL in agnostische Schnittstellen umgewandelt und dort der Nutzfunktion (der Funktion bzw. der Anwendung) zur Verfügung gestellt. Diese Nutzfunktion kann Anforderungen an externe Komponenten über das abstrahierte System in die reale Welt übertragen und so die Systemgrenze ‚Steuergerät‘ überwinden.
-
Hierbei kann ebenfalls auf einem externen Bediensystem eine Ein-/Ausgabe erfolgen oder aber in einer weiteren Verkettung eine weitere Funktionalität mit angebunden werden. Dies kann ebenfalls über eine Telemetrieverbindung auf einem entfernten Bediensystem erfolgen oder über eine per Telemetrie angebundene Automatisierungslösung zur teil- oder vollautonomen Ansteuerung umgesetzt werden. Weiterhin können mehrere Funktionen innerhalb des einzelnen Systems z.B. durch Kommunikation miteinander in Verbindung gebracht werden und eine gemeinschaftliche Aufgabe erledigen. Dies kann ebenfalls über mehrere Recheneinheiten einer Maschine hinweg erfolgen, aber auch über die Realisierung in verteilten Recheneinheiten von per Telemetrie (drahtlose Kommunikationsverbindung) verbundenen Maschinen, sowie in mehreren teilzentralisiert (vgl. Edge Computing) oder zentralisiert (vgl. Cloud Computing) umgesetzten Recheneinheiten erreicht werden.
