WO2021089296A1 - System zum austausch von nachrichten durch eine anwendungssoftware - Google Patents

System zum austausch von nachrichten durch eine anwendungssoftware Download PDF

Info

Publication number
WO2021089296A1
WO2021089296A1 PCT/EP2020/079077 EP2020079077W WO2021089296A1 WO 2021089296 A1 WO2021089296 A1 WO 2021089296A1 EP 2020079077 W EP2020079077 W EP 2020079077W WO 2021089296 A1 WO2021089296 A1 WO 2021089296A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface library
adapter
following features
interfaces
interface
Prior art date
Application number
PCT/EP2020/079077
Other languages
English (en)
French (fr)
Inventor
Udo Schulz
Mouham Tanimou
Joshua-Niclas OERGELE
Micha Muenzenmay
Christian Kahr
Tobias Krug
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 US17/769,887 priority Critical patent/US20220292047A1/en
Publication of WO2021089296A1 publication Critical patent/WO2021089296A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0423—Input/output
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/45—Nc applications
    • G05B2219/45017—Agriculture machine, tractor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0002—Serial port, e.g. RS232C
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN

Definitions

  • the present invention relates to a system for exchanging messages by application software.
  • SW software
  • OTA over-the-air
  • FOTA and SOTA are used, for example, to update the control units (electronic control units, ECUs) of networked motor vehicles and agricultural machinery.
  • a vehicle connection interface vehicle connectivity gateway, VCG
  • VCG vehicle connectivity gateway
  • vehicle-internal control units can be expanded in this way by features that use existing sensors and actuators for new applications.
  • Corresponding applications can be created by the manufacturer or original equipment manufacturer (OEM) of an agricultural machine - for example using a development kit - and offered on a digital sales platform in the cloud.
  • Conceivable extensions include, for example, advanced telemetry or special agricultural functions such as targeted weed control.
  • DE102015203766A1 discloses a subsystem for a vehicle with a device management client connected via an air interface to a device management server of the backend for exchanging device, vehicle and diagnostic and software update information, one connected via the air interface to a download server of the backend Download client for downloading a software update from the backend into the vehicle, software update clients connected to the download client for applying the software update and a vehicle update client connected to the download client and the software update clients for coordinating the software update.
  • the container or operating system virtualization which has been common in data center operations for a long time, has recently increasingly found its way into the practice of embedded systems.
  • This method makes it possible to operate several instances of an operating system as so-called guests in isolation from one another on a host system.
  • the host can provide a complete runtime environment to each application encapsulated within such a container, which may include, for example, dynamic libraries of the programming language used by the respective developer, such as Java, C or Python.
  • this "lightweight" form of virtualization imposes some restrictions on the guests, but has the advantage that all containers contain the core of the native operating system - typically Linux, BSD, Solaris or another Unix-like system. use together. The use of containers thus spares the scarce resources of embedded systems.
  • the invention provides a system for the exchange of messages by application software on a control device according to the independent claims.
  • a basic idea of the approach according to the invention is the creation of interfaces which enable an agnostic use of interfaces external to the control unit, actuators and sensors as well as internal control unit interfaces such as services.
  • Two complementary elements are used for this: a database with interfaces that can be dynamically changed at runtime (hereinafter: “interface library”) and a type of modifiable adapter (hereinafter: “abstraction layer”), the components of which enable a service-oriented and container-based system architecture.
  • interface library a database with interfaces that can be dynamically changed at runtime
  • abstraction layer hereinafter: "abstraction layer”
  • the abstraction layer enables communication across lower levels.
  • One advantage of this solution is the possibility of using the software communication infrastructure on which the system is based.
  • the implementation is not limited to a specific machine, but behaves dynamically, i.e. changes automatically with changing variants of the connected hardware (HW).
  • HW connected hardware
  • APIs Application programming interfaces
  • process parameters are taken into account by the platform and are therefore no longer relevant for the application software developer. This applies, for example, to units of target or actual values of internal signals and on bus systems.
  • the abstraction layer has a programming interface which connects the interface library described with a message broker.
  • the entire system architecture can be designed in a modular manner or changed statically and dynamically.
  • the implementation of the communication broker can be exchanged without changing the entire architecture.
  • a driver module from the interface library can also be reloaded during runtime, for example.
  • the use of the above APIs represents the central interface of the service-oriented software components with their respective advantages.
  • the interface library includes adapters for a wide variety of interfaces, which are supported by corresponding drivers of the system.
  • This has the advantage that with the same architecture almost all interfaces supported by control units can be abstracted from application software and used agnostically. The latter in turn enables the efficient and ECU-independent development of application software with a wide variety of performance features.
  • FIG. 1 shows the block diagram of a system according to an embodiment of the invention.
  • FIG. 2 schematically shows an interface library of the system according to FIG. 1.
  • Figure 3 shows the connection between the interface library and application software.
  • Figure 4 is a model of a seed drill.
  • An embodiment of the invention comprises several elements, which will now be explained in detail.
  • the different tasks, functions and advantages of the abstraction layer and the interface library are also described.
  • the service-oriented communication or architecture of the system is based on this layer model of the interfaces.
  • the abstraction layer and the interface library represent an extension and improvement of existing layer models for communication:
  • the abstraction layer with its APIs is based on the layers of the well-known OSI model. Its implementation and that of the interface library are independent of the target hardware.
  • the individual components can be exchanged here. Such an exchange merely requires that the respective intermediate layers are exchanged accordingly.
  • the message broker can be exchanged, while the rest of the architecture - with the exception of the corresponding API of the abstraction layer - does not have to be changed.
  • the interface library is responsible for validating this communication, as it requires the inclusion of hardware-related aspects, for example with regard to ISOBUS or input and output (I / O).
  • the abstraction layer (12) and the interface library (14) represent layers of the system (10), which in turn consist of layers (see FIG. 1).
  • the central element of the interface library (14) is a coordinator (15) who - beyond ISOBUS z. B. in machines with proprietary interfaces - concrete instances of generic machine models (see, for example, Fig. 4 for the seed drill model) via the adapter modules (16 and 27) with I / O modules and other peripheral devices.
  • the software machine model of a seed drill is shown as an example.
  • the block “sowing machine” describes the generic functions of a sowing machine (outlet, rows, tank, sowing machine).
  • the "Machine” block describes the administrative and operating data of the specific seed drill (machine, seeds, position).
  • the "Administrative data instance” block is the instance of the administrative or operational data and the generic functions. The instantiation takes place through the abstraction layer (12) and the interface library (14) uses this. The administrative and operating data are also stored in the "database” (e.g. in the cloud).
  • modules can, for example, differ in terms of the programming languages used or their syntactic depth.
  • the interface library (14) offers correspondences to different interfaces of the OSI model, which reflect its different levels (1-7) (see FIG. 2).
  • the components A to D shown in Figure 2 represent examples of different implementation depths according to the levels of the OSI model.
  • the interface library (14) supplements the "missing" layers down to the service level (level 7) and the abstraction layer (12) to be able to offer a generic interface. As shown, different levels of implementation are supported. This is necessary because peripheral devices from different manufacturers / types support different levels.
  • component A could correspond to the GPS driver in Figure 1
  • component B to the socket CAN
  • component C to the ISOBUS
  • component D to any I / O (e.g. temperature sensor).
  • All elements (21, 17, 23, 25) in the interface library ISOBUS adapter (16) are also adapters.
  • the interface library base parts adapter (17) contains all interfaces that are common to all available ISOBUS stacks (22, 24, 26).
  • the other adapters (21, 23, 25) are exemplary adapters for supplier-specific parts of the ISOBUS stack that the suppliers bring with them, for example. All adapters use a specifically created machine model to define the interface space of
  • the abstraction layer (12) is based on comparable considerations (see FIG. 3). This allows the language-agnostic exchange of information between application programs (11) without platform dependencies, for example independent of the implementation and performance of the message broker (13) used. It can also be configured dynamically and, in particular, allows expansion with new executable units or reconfiguration of an existing executable unit. Finally, it enables communication to be monitored and controlled, for example with regard to the bandwidth used.
  • the connection to the message broker (13) is made by means of a further programming interface (30) of the abstraction layer (12).
  • the interface library (14) is also connected to the message broker (13) via a corresponding programming interface (30).
  • Another property of the present embodiment is the dynamic scalability of its interfaces.
  • Their object-oriented modeling enables adaptation to different machine sizes. This means that the machine models, for example, are scalable: for a field sprayer, for example, with regard to the working width and number of nozzles, for a row seeder, with regard to the number of rows.
  • the software platform defines abstract classes from which specific machine types are derived through the implementation of the inherited access methods and the definition of variables.
  • the object-oriented modeling supports a corresponding granularity with regard to the scope of services of hardware and application software
  • the machine model provides classes for syringe, tank and section (section), whereby a syringe can comprise several tanks, which in turn may have several sections.
  • the “syringe” class defines methods for accessing its attributes of the “tank” class type; the latter in turn defines methods for accessing its attributes of the “Section” class type.
  • this class defines methods for opening and closing the nozzles.
  • the interface library (14) gives the system (10) according to the invention a high degree of compatibility with a wide variety of machines. If, for example, the application software (11) only supports the control of a section of a field sprayer, but the latter has four differently controllable sections, the interface library (14) allows all sections to be controlled. A dynamic adjustment at runtime is also conceivable.
  • the interface library (14) determines that there are new or more detailed machine interfaces on an attachment, a service advertising mechanism ensures that the availability of these machine interfaces are known to the message broker (13) and the relevant drivers (28) from the Can be downloaded from the cloud.
  • the application software (11) can discover and use the new interfaces via a discovery mechanism.
  • each application software (11) sets certain minimum requirements in a manifest file for the interfaces and resources of the machine controlled by it, which are stored in a central registry during the installation process of the relevant container. As long as there are no corresponding machines are connected or controlled at runtime, these interfaces remain abstract.
  • application software (11) and interface library (14) for each individual API are connected by an arbitration process. This combination ensures efficient management of the APIs.
  • the interface library (14) adapts to the application software (11) or specifies the interfaces in accordance with the relevant notes in the registry. According to this, a protocol which enables meta-communication, but not the exchange of user data, is coordinated between the application software (11) and the interface library (14). This meta-communication is used to exchange information that does not directly affect the control of actuators, drivers, etc., but rather their functionality and quality of service (QoS).
  • QoS quality of service
  • the testability of the application software (11) is also increased by the above communication architecture.
  • the interface library (14) can be replaced by a mockup for the purpose of component tests.
  • a virtual machine class simulates a physical machine for this purpose.
  • the entire application software (11) for a machine model can be developed and, in particular, tested without its developer having a copy or even detailed knowledge of this machine.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

System (10) zum Austausch von Nachrichten durch eine Anwendungssoftware (11), gekennzeichnet durch folgende Merkmale: - eine Abstraktionsschicht (12) zum Abstrahieren der Nachrichten und - eine über einen Nachrichtenbroker (13) mit der Abstraktionsschicht (12) verbundene Schnittstellenbibliothek (14).

Description

Beschreibung
Titel
System zum Austausch von Nachrichten durch eine Anwendungssoftware
Die vorliegende Erfindung betrifft ein System zum Austausch von Nachrichten durch eine Anwendungssoftware.
Stand der Technik
Hinlänglich bekannt sind Verfahren zum Verteilen oder Aktualisieren von Software (SW) über eine - mitunter als „Luftschnittstelle“ ( overthe air, OTA) bezeichnete - drahtlose Datenschnittstelle. Gattungsmäßige Verfahren finden Anwendung sowohl auf Anwendungssoftware (SOTA) als auch auf eingebettete Systemsoftware ( firmware , FOTA).
Nach dem Stand der Technik werden FOTA und SOTA beispielsweise zur Aktualisierung der Steuergeräte ( electronic control units, ECUs) vernetzter Kraftfahrzeuge und Landmaschinen eingesetzt. Zur telematischen Verbindung zwischen dem die Steuergeräte koppelnden Bussystem und dem Internet (der sinnbildlichen „Cloud“) dient hierbei typischerweise eine Fahrzeugverbindungsschnittstelle ( vehicle Connectivity gateway, VCG).
Jenseits der Wartung und Fehlerbereinigung bereits installierter Software lässt sich der Funktionsumfang fahrzeuginterner Steuergeräte auf diesem Wege um Leistungsmerkmale ( features ) erweitern, welche vorhandene Sensoren und Aktoren für neue Anwendungsfälle nutzen. Entsprechende Applikationen können durch Hersteller oder Erstausrüster {original equipment manufacturer, OEM) einer Landmaschine - etwa mittels eines Entwicklungskits {development kit) - erstellt und auf einer digitalen Vertriebsplattform in der Cloud angeboten werden. Als denkbare Erweiterungen kommen zum Beispiel fortgeschrittene Telemetrie- oder agrartechnische Spezialfunktionen wie die gezielte Unkrautbekämpfung in Betracht.
DE102015203766A1 offenbart ein Teilsystem für ein Fahrzeug mit einem über eine Luftschnittstelle mit einem Gerätemanagement-Server des Backends verbundenen Gerätemanagement-Client zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, einem über die Luftschnittstelle mit einem Download-Server des Backends verbundenen Download-Client zum Herunterladen eines Softwareupdates von dem Backend in das Fahrzeug, mit dem Download-Client verbundenen Softwareupdate-Clients zum Anwenden des Softwareupdates und einen mit dem Download-Client und den Softwareupdate-Clients verbundenen Fahrzeugupdate-Client zum Koordinieren des Softwareupdates.
Im Zuge einer unabhängigen Entwicklung findet die im Rechenzentrumsbetrieb bereits seit Längerem übliche Container- oder Betriebssystem-Virtualisierung in jüngerer Zeit vermehrt Eingang in die Praxis der eingebetteten Systeme {embedded Systems). Diese Methode erlaubt es, mehrere Instanzen eines Betriebssystems als sogenannte Gäste ( guests ) isoliert voneinander auf einem Wirtssystem ( host ) zu betreiben. Auf diese Weise kann der Wirt jeder innerhalb eines solchen Containers gekapselten Anwendung ( application , app) eine vollständige Laufzeitumgebung zur Verfügung stellen, die beispielsweise dynamische Bibliotheken der vom jeweiligen Entwickler genutzten Programmiersprache wie Java, C oder Python umfassen mag. Im Gegensatz zur Nutzung eines Hypervisors erlegt diese „leichtgewichtige“ Form der Virtualisierung den Gästen zwar einige Einschränkungen auf, birgt jedoch den Vorteil, dass alle Container den Kern des nativen Betriebssystems - typischerweise Linux, BSD, Solaris oder ein anderes Unix-ähnliches System - gemeinsam nutzen. Die Nutzung von Containern schont somit die knappen Betriebsmittel eingebetteter Systeme.
Offenbarung der Erfindung
Die Erfindung stellt ein System zum Nachrichtenaustausch durch eine Anwendungssoftware auf einem Steuergerät gemäß den unabhängigen Ansprüchen bereit.
Ein Grundgedanke des erfindungsgemäßen Ansatzes ist die Schaffung von Schnittstellen, die eine agnostische Verwendung von Steuergeräte-externen Schnittstellen, Aktorik und Sensorik als auch Steuergeräte-internen Schnittstellen wie Services ermöglichen. Hierzu dienen zwei komplementäre Elemente: eine zur Laufzeit dynamisch veränderbare Datenbank mit Schnittstellen (im Folgenden: „Schnittstellenbibliothek“) und eine Art modifizierbarer Adapter (im Folgenden: „Abstraktionsschicht“), dessen Bestandteile eine Service-orientierte und Container-basierte System architektur ermöglicht. Darüber hinaus ermöglicht die Abstraktionsschicht eine Kommunikation über tieferliegende Ebenen.
Ein Vorzug dieser Lösung liegt in der eröffneten Möglichkeit, die dem System zugrundeliegende SW- Kommunikationsinfrastruktur zu nutzen. Hierbei ist die Implementierung nicht auf eine spezifische Maschine beschränkt, sondern verhält sich dynamisch, verändert sich also automatisch mit wechselnden Varianten einer angeschlossenen Hardware (HW). Der Entwickler einer Anwendung wird bei der Verarbeitung dieser potenziellen Dynamik bzgl. verbundener Hardware - und damit verfügbarer
Anwendungsprogrammierschnittstellen ( application programming interfaces, APIs) - durch die Plattform unterstützt. Darüber hinaus werden bestimmte Varianten bzgl. Prozessparametern durch die Plattform berücksichtigt und sind damit für den Anwendungssoftwareentwickler nicht mehr relevant. Dies gilt zum Beispiel für Einheiten von Soll- oder Ist-Größen interner Signale und auf Bussystemen.
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 die Abstraktionsschicht eine Programmierschnittstelle aufweist, welche die beschriebene Schnittstellenbibliothek mit einem Nachrichtenbroker ( message broker) verbindet. Durch die Verwendung derartiger Schnittstellen und einer auf Schichten basierenden Kommunikationsarchitektur kann die gesamte Systemarchitektur modular gestaltet bzw. statisch und dynamisch verändert werden. Beispielsweise kann die Implementierung des Kommunikationsbrokers ohne Veränderung der gesamten Architektur ausgetauscht werden. Ebenso kann zum Beispiel zur Laufzeit ein Treibermodul der Schnittstellenbibliothek nachgeladen werden. Hierbei stellt die Verwendung der obigen APIs die zentrale Schnittstelle der Service-orientierten Softwarekomponenten mit ihren jeweiligen Vorteilen dar.
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die Schnittstellenbibliothek Adapter für unterschiedlichste Schnittstellen umfasst, welche durch entsprechende Treiber des Systems unterstützt werden. Dies birgt den Vorteil, dass mit derselben Architektur nahezu alle von Steuergeräten unterstützten Schnittstellen von Anwendungssoftware abstrahiert und agnostisch genutzt werden können. Letzteres wiederum ermöglicht die effiziente und Steuergeräte-unabhängige Entwicklung von Anwendungssoftware mit verschiedensten Leistungsmerkmalen.
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 das Blockdiagramm eines Systems gemäß einer Ausführungsform der Erfindung.
Figur 2 schematisch eine Schnittstellenbibliothek des Systems gemäß der Figur 1. Figur 3 die Verbindung zwischen Schnittstellenbibliothek und Anwendungssoftware.
Figur 4 ein Sämaschinenmodell.
Ausführungsformen der Erfindung
Eine Ausgestaltung der Erfindung umfasst mehrere Elemente, welche nunmehr im Einzelnen erläutert werden. In diesem Zusammenhang werden auch die unterschiedlichen Aufgaben, Funktionsweisen und Vorteile der Abstraktionsschicht sowie der Schnittstellenbibliothek beschrieben. Die serviceorientierte Kommunikation bzw. Architektur des Systems baut auf diesem Schichtenmodell der Schnittstellen auf.
Erfindungsgemäß stellen Abstraktionsschicht und Schnittstellenbibliothek eine Erweiterung und Verbesserung bestehender Schichtenmodelle zur Kommunikation dar: Die Abstraktionsschicht mit ihren APIs orientiert sich an den Schichten des wohlbekannten OSI-Modells. Ihre Umsetzung und jene der Schnittstellenbibliothek ist unabhängig von der Ziel-HW. Gemäß obigem Verständnis können hierbei die einzelnen Komponenten ausgetauscht werden. Ein derartiger Austausch bedingt lediglich, dass die jeweiligen Zwischenschichten entsprechend ausgetauscht werden. Beispielsweise kann der Nachrichtenbroker ausgetauscht werden, während die restliche Architektur - mit Ausnahme der entsprechenden API der Abstraktionsschicht - nicht verändert werden muss.
Im Gegensatz zum OSI-Schichtenmodell erfolgt die Kommunikation dabei gleichsam „vertragsbasiert“, indem für jede API die Erfüllung nichtfunktionaler Anforderungen - etwa die Einhaltung einer bestimmten Reaktionszeit - zugesichert werden. Eine Validierung dieser Kommunikation obliegt der Schnittstellenbibliothek, da sie die Einbeziehung hardwarenaher Gesichtspunkte zum Beispiel hinsichtlich ISOBUS oder Ein- und Ausgabe (input/output, I/O) erfordert. Abstraktionsschicht (12) und Schnittstellenbibliothek (14) stellen dabei Schichten des Systems (10) dar, welche ihrerseits aus Schichten bestehen (siehe Figur 1). Zentrales Element der Schnittstellenbibliothek (14) ist hierbei ein Koordinator (15), der - jenseits von ISOBUS z. B. bei Maschinen mit proprietären Schnittstellen - konkrete Instanzen von generischen Maschinenmodellen (siehe z.B. Fig. 4 zum Sämaschinenmodell) über die Adaptermodule (16 und 27) mit I/O-Modulen und anderen Peripheriegeräten verbindet.
In Figur 4 ist beispielhaft das Software Maschinenmodell einer Sämaschine dargestellt. Der Block „Sähmaschine“ beschreibt die generischen Funktionen einer Sämaschine (Auslass, Reihen, Tank, Sämaschine). Der Block „Maschine“ beschreibt die Verwaltungs- bzw. Betriebsdaten der konkreten Sämaschine (Maschine, Samen, Position). Der Block „Verwaltungsdateninstanz“ ist die Instanz der Verwaltungs- bzw. Betriebsdaten und der generischen Funktionen. Die Instanziierung erfolgt durch die Abstraktionsschicht (12) und die Schnittstellenbibliothek (14) nutzt diese. Die Verwaltungs- bzw. Betriebsdaten werden zudem in der „Datenbank“ (z.B. in der Cloud) gespeichert.
Diese Module können beispielsweise hinsichtlich der verwendeten Programmiersprachen oder ihrer syntaktischen Tiefe von unterschiedlicher Gestalt sein. Zu diesem Zweck bietet die Schnittstellenbibliothek (14) Entsprechungen zu verschieden Schnittstellen des OSI-Modells, die dessen unterschiedliche Ebenen (1-7) widerspiegeln (siehe Figur 2).
Die im Bild 2 dargestellten Komponenten A bis D stellen dabei beispielhaft verschiedene Implementierungstiefen entsprechend der Ebenen des OSI Modells dar. Die Schnittstellenbibliothek (14) ergänzt dabei die „fehlenden“ Layer bis auf Service Ebenen (Level 7), um der Abstraktionsschicht (12) eine generische Schnittstelle anbieten zu können. Wie dargestellt werden unterschiedliche Implementierungsstufen unterstützt. Dies ist notwendig, da Peripheriegeräte von unterschiedlichen Herstellern/Typ unterschiedliche Level unterstützen. Zum Beispiel Komponente A könnte dem GPS-Driver im Bild 1 entsprechen, Komponente B dem Socket CAN, Komponente C dem ISOBUS sowie Komponente D einem beliebigen I/O (z.B. Temperatursensor). Alle im Schnittstellenbibliothek-ISOBUS-Adapter (16) befindlichen Elemente (21, 17, 23, 25) sind ebenfalls Adapter. Der Schnittstellenbibliothek-Basisteile-Adapter (17) enthält alle Schnittstellen die für alle verfügbaren ISOBUS- Stacks (22, 24, 26) gemeinsam sind. Die anderen Adapter (21, 23, 25) sind beispielhafte Adapter für lieferantenspezifische Teile des ISOBUS-Stacks, die z.B. die Lieferanten mitbringen. Alle Adapter nutzen ein spezifisch erstelltes Maschinenmodell um den Schnittstellenraum dieser Adapter zu definieren.
Vergleichbare Überlegungen liegen der Abstraktionsschicht (12) zugrunde (siehe Figur 3). Diese gestattet den sprachagnostischen Austausch von Informationen zwischen Anwendungsprogrammen (11) ohne Plattformabhängigkeiten, also zum Beispiel unabhängig von der Umsetzung und Leistungsfähigkeit des verwendeten Nachrichtenbrokers (13). Sie ist zudem dynamisch konfigurierbar und erlaubt insbesondere die Erweiterung durch neue ausführbare Einheiten oder Rekonfiguration einer bestehenden ausführbaren Einheit. Schließlich ermöglicht sie die Überwachung und Steuerung von Kommunikation, zum Beispiel hinsichtlich der beanspruchten Bandbreite.
Dies wird seitens der Anwendungssoftware (11) durch eine API ermöglicht, die sämtliche genannten Implementierungsdetails vor dem Entwickler verbirgt. Die Verbindung zum Nachrichtenbroker (13) erfolgt mittels einer weiteren Programmierschnittstelle (30) der Abstraktionsschicht (12). Über eine entsprechende Programmierschnittstelle (30) ist auch die Schnittstellenbibliothek (14) mit dem Nachrichtenbroker (13) verbunden.
Eine weitere Eigenschaft der vorliegenden Ausführungsform ist die dynamische Skalierbarkeit ihrer Interfaces. Deren objektorientierte Modellierung ermöglicht hierbei die Anpassung an verschiedene Maschinengrößen. Dadurch sind beispielsweise die Maschinenmodelle skalierbar: bei einer Feldspritze etwa bezüglich Arbeitsbreite und Düsenanzahl, bei einer Reihensämaschine bezüglich der Anzahl der Reihen. Hierzu definiert die Softwareplattform abstrakte Klassen, aus welchen konkrete Maschinentypen durch die Implementierung der geerbten Zugriffsmethoden und Definition von Variablen abgeleitet werden. Dabei unterstützt die objektorientierte Modellierung eine entsprechende Granularität hinsichtlich des Leistungsumfanges von Hardware und Anwendungssoftware
(11).
Diese Detailgenauigkeit sei nunmehr anhand einer Feldspritze mit Abschnittssteuerung ( section controf) erläutert. Das Maschinenmodell sieht Klassen für Spritze, Tank und Abschnitt ( section ) vor, wobei eine Spritze mehrere Tanks umfassen kann, die ihrerseits mehrere Abschnitte aufweisen mögen. Die Klasse „Spritze“ definiert hierbei Methoden zum Zugriff auf ihre Attribute vom Klassentyp „Tank“; letzterer wiederum definiert Methoden zum Zugriff auf seine Attribute vom Klassentyp „Abschnitt“. Diese Klasse schließlich definiert Methoden zum Öffnen und Schließen der Düsen. Die beschriebene Objekthierarchie ermöglicht es, die modellierte Maschine auf unterschiedlichen Ebenen mit unterschiedlicher Granularität anzusprechen.
Die Schnittstellenbibliothek (14) verleiht dem erfindungsgemäßen System (10) auf diese Weise ein hohes Maß an Kompatibilität zu unterschiedlichsten Maschinen. Falls zum Beispiel die Anwendungssoftware (11) nur die Ansteuerung eines Abschnittes einer Feldspritze unterstützt, letztere jedoch vier unterschiedlich ansteuerbare Abschnitte besitzt, erlaubt die Schnittstellenbibliothek (14) die Ansteuerung sämtlicher Abschnitte. Auch eine dynamische Anpassung zur Laufzeit ist denkbar: Wenn z. B. die Schnittstellenbibliothek (14) feststellt, dass auf einem Anbaugerät neue oder detailliertere Maschinenschnittstellen vorhanden sind, sorgt ein Service- Advertising-Mechanismus dafür, dass die Verfügbarkeit dieser Maschinenschnittstellen dem Nachrichtenbroker (13) bekannt sind und die einschlägigen Treiber (28) aus der Cloud heruntergeladen werden. Über einen Discovery-Mechanismus kann die Anwendersoftware (11) die neuen Schnittstellen entdecken und verwenden.
Das Laufzeitverhalten eröffnet neuartige Einsatzmöglichkeiten für ein erfindungsgemäßes Steuergerät. Hierzu stellt jede Anwendungssoftware (11) in einer Manifest- Datei gewisse Mindestanforderungen an die Schnittstellen und Betriebsmittel der von ihr gesteuerten Maschine, die während des Installationsprozesses des betreffenden Containers in einer zentralen Registry abgelegt werden. Solange jedoch keine entsprechenden Maschinen angeschlossen sind bzw. zur Laufzeit angesteuert werden, bleiben diese Schnittstellen abstrakt.
Nach dem Installationsprozess werden durch einen Arbitrierungsvorgang Anwendungssoftware (11) und Schnittstellenbibliothek (14) für jede einzelne API verbunden. Diese Kombination gewährleistet ein effizientes Management der APIs. Ist der sinnbildliche „Handshake“ vollzogen, so stellt sich die Schnittstellenbibliothek (14) auf die Anwendungssoftware (11) ein bzw. konkretisiert die Schnittstellen gemäß betreffenden Vermerken in der Registry. Hiernach wird ein Protokoll, welches die Meta- Kommunikation, nicht jedoch den Austausch von Nutzdaten ermöglicht, zwischen Anwendungssoftware (11) und Schnittstellenbibliothek (14) abgestimmt. Diese Meta- Kommunikation dient dem Austausch von Informationen, welche nicht unmittelbar die Ansteuerung von Aktoren, Treibern etc., sondern deren Funktionsfähigkeit und Dienstgüte ( quality of Service, QoS) betreffen.
Nach dem Durchlaufen dieser Schritte sind Advertising, Discovery, Arbitrierung und Überwachung von APIs und dem Zugriff auf diese abgestimmt und ermöglichen der Anwendungssoftware (11) eine hinsichtlich Funktion, Vermeidung von Bitfehlern, Datenintegrität und -konsistenz sichere Kommunikation.
Auch die Testbarkeit der Anwendungssoftware (11) wird durch obige Kommunikationsarchitektur erhöht. So kann beispielsweise die Schnittstellenbibliothek (14) zum Zwecke von Komponententests durch eine Attrappe ( mockup ) ersetzt werden. Eine virtuelle Maschinenklasse simuliert hierzu eine physikalische Maschine. Im äußersten Fall kann die gesamte Anwendungssoftware (11) für ein Maschinenmodell entwickelt und insbesondere getestet werden, ohne dass ihr Entwickler über ein Exemplar oder auch nur detaillierte Kenntnis dieser Maschine verfügt.

Claims

Ansprüche
1. System (10) zum Austausch von Nachrichten durch eine Anwendungssoftware (11), gekennzeichnet durch folgende Merkmale:
- eine Abstraktionsschicht (12) zum Abstrahieren der Nachrichten und
- eine über einen Nachrichtenbroker (13) mit der Abstraktionsschicht (12) verbundene Schnittstellenbibliothek (14).
2. System (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale:
- die Abstraktionsschicht (12) weist eine Programmierschnittstelle (30) auf und
- die Schnittstellenbibliothek (14) ist über die Programmierschnittstelle (30) mit dem Nachrichtenbroker (13) verbunden.
3. System (10) nach Anspruch 1 oder 2, gekennzeichnet durch folgende Merkmale:
- das System (10) umfasst eine Treiberschicht (18) für eine physikalische Schicht (19) und
- die Schnittstellenbibliothek (14) umfasst einen Koordinator (15) zum Koordinieren von Hardwarekomponenten (A-D), einen ISOBUS-Adapter (16) mit einem Basisteil (17) und mindestens einen CAN-Protokollstapel (20, 22, 24, 26).
4. System (10) nach Anspruch 3, gekennzeichnet durch folgende Merkmale:
- der Koordinator (15) ist an einen Schnittstellenbibliothek-Basisteile- Adapter (17) des ISOBUS-Adapters (16) angepasst, - der Schnittstellenbibliothek-Basisteile-Adapter (17) enthält gemeinsame Schnittstellen für andere lieferantenspezifische Adapter (21, 23, 25) und
- die Schnittstellenbibliothek (14) umfasst Protokollstapel (22, 24, 26, 20) zum Zugreifen auf die physikalische Schicht (19) mittels der Treiberschicht (18).
5. System (10) nach Anspruch 3, gekennzeichnet durch folgende Merkmale:
- der Koordinator (15) ist an lieferantenspezifische Adapter (21, 23, 25) des ISOBUS-Adapters (16) angepasst,
- die lieferantenspezifischen Adapter (21, 23, 25) enthalten lieferantenspezifische Schnittstellen und
- die Schnittstellenbibliothek (14) umfasst Protokollstapel (22, 24, 26, 20) zum Zugreifen auf die physikalische Schicht (19) mittels der Treiberschicht (18).
6. System (10) nach einem der Ansprüche 3 bis 5, gekennzeichnet durch folgende Merkmale:
- der Koordinator (15) ist an einen Adapter (27) für weitere Schnittstellen angepasst,
- der Adapter (27) umfasst weitere serviceorientierte Adapter,
- die Schnittstellenbibliothek (14) umfasst herstellerunspezifische und serviceunspezifische Protokollstapel (37, 35, 36) und
- die Protokollstapel (37, 35, 36) kommunizieren mit der physikalischen Schicht (19) anhand von Treibern (29, 28).
7. System (10) nach einem der Ansprüche 3 bis 5, gekennzeichnet durch folgende Merkmale:
- der Koordinator (15) ist an einen Adapter (27) für weitere Schnittstellen angepasst,
- der Adapter (27) umfasst weitere serviceorientierte Adapter,
- die Schnittstellenbibliothek (14) umfasst herstellerspezifische und servicespezifische Protokollstapel (37, 35, 36) und
- die Protokollstapel (37, 35, 36) kommunizieren mit der physikalischen Schicht (19) anhand von Treibern (29, 28).
8. System (10) nach einem der Ansprüche 1 bis 7, gekennzeichnet durch folgende Merkmale:
- die Schnittstellenbibliothek (14) umfasst einen weiteren Adapter (27) für sonstige Schnittstellen (31-34) und - das System (10) umfasst weitere Treiber (28) für die
Schnittstellen (31-34).
9. System (10) nach Anspruch 8, dadurch gekennzeichnet, dass die Schnittstellen (31-34) mindestens eine der folgenden umfassen:
- einen LIN-Bus (31),
- einen FlexRay-Bus (32),
- ein Ethernet (33) oder
- weitere Ein- und Ausgänge (34).
10. System (10) nach einem der Ansprüche 1 bis 9, gekennzeichnet durch folgende Merkmale:
- die Schnittstellenbibliothek (14) umfasst einen GPS-Dienst (37) und
- das System (10) umfasst einen GPS-Treiber (29).
11. System (10) nach einem der Ansprüche 1 bis 10, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die Schnittstellenbibliothek (14) umfasst einen Sensor-Dienst (35) oder
- die Schnittstellenbibliothek (14) umfasst einen Aktor-Dienst (36).
PCT/EP2020/079077 2019-11-06 2020-10-15 System zum austausch von nachrichten durch eine anwendungssoftware WO2021089296A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/769,887 US20220292047A1 (en) 2019-11-06 2020-10-15 System for the exchange of messages through an application software

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019217046.3A DE102019217046A1 (de) 2019-11-06 2019-11-06 System zum Austausch von Nachrichten durch eine Anwendungssoftware
DE102019217046.3 2019-11-06

Publications (1)

Publication Number Publication Date
WO2021089296A1 true WO2021089296A1 (de) 2021-05-14

Family

ID=72944139

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/079077 WO2021089296A1 (de) 2019-11-06 2020-10-15 System zum austausch von nachrichten durch eine anwendungssoftware

Country Status (3)

Country Link
US (1) US20220292047A1 (de)
DE (1) DE102019217046A1 (de)
WO (1) WO2021089296A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022207594A1 (de) 2022-07-26 2024-02-01 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Bilden einer Kommunikationsschnittstelle zwischen einem Softwaremodul und einem Adressaten

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004016227A1 (de) * 2004-04-01 2005-10-20 Volkswagen Ag Steuergerät für ein Kraftfahrzeug
DE102004039633A1 (de) * 2004-08-11 2006-02-23 Volkswagen Ag Verfahren und Vorrichtung zum Austauschen fahrzeugoriginärer Informationen

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7870559B2 (en) * 2007-03-27 2011-01-11 International Business Machines Corporation Methods, systems, and computer program products for continuous availability of non-persistence messages in a distributed platform
US9392316B2 (en) * 2010-10-28 2016-07-12 At&T Intellectual Property I, L.P. Messaging abstraction in a mobile device server
US20140244746A1 (en) * 2013-02-26 2014-08-28 Red Hat, Inc. Systems and Methods for Message Routing Using Link State Information
CN109842585B (zh) * 2017-11-27 2021-04-13 中国科学院沈阳自动化研究所 面向工业嵌入式系统的网络信息安全防护单元和防护方法
DE102019217047A1 (de) * 2019-11-06 2021-05-06 Robert Bosch Gmbh Verfahren und Vorrichtung zum Verwalten von Zugriffen mehrerer Softwarekomponenten auf Softwareschnittstellen

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004016227A1 (de) * 2004-04-01 2005-10-20 Volkswagen Ag Steuergerät für ein Kraftfahrzeug
DE102004039633A1 (de) * 2004-08-11 2006-02-23 Volkswagen Ag Verfahren und Vorrichtung zum Austauschen fahrzeugoriginärer Informationen

Also Published As

Publication number Publication date
US20220292047A1 (en) 2022-09-15
DE102019217046A1 (de) 2021-06-17

Similar Documents

Publication Publication Date Title
WO2006066880A1 (de) System und verfahren zum automatischen aktualisieren von funktionalitäten in einem verteilten netzwerk
DE69829442T2 (de) System und Verfahren für transparenten, globalen Zugang zu physikalischen Geräten in einem Rechnersystem
DE102005014273B4 (de) Vergleich von Schnittstellen zwischen Softwarekomponenten
DE102016210672A1 (de) Verfahren für die drahtlose Remote-Aktualisierung von Fahrzeug-Software
DE102016210676A1 (de) Verfahren zum Aktualisieren von ECUs unter Verwendung von differenziellen Aktualisierungspaketen
DE102016210511A1 (de) Zentralisiertes System für die Software Aktualisierung von Fahrzeugkomponenten
DE202008016892U1 (de) Kraftfahrzeug-Steuervorrichtung
DE102011087826A1 (de) Vorrichtung zur Bedienung von mindestens einem Feldgerät der Automatisierungstechnik
DE102005013239A1 (de) Drahtlosmodulsimulator
WO2005076121A2 (de) Treiber-server für daten oder dateien von geräte-treibern, insbesondere druckertreibern, in einem rechnernetzwerk
WO2021089296A1 (de) System zum austausch von nachrichten durch eine anwendungssoftware
WO2019211122A1 (de) Feature-development-framework und feature-integration-framework zum implementieren physikalischer funktionsfeatures in einem zielgerät
EP3832517A1 (de) Computerimplementiertes verfahren zur einbindung mindestens eines signalwerts in einem virtuellen steuergerät
WO2021089310A1 (de) Verfahren und vorrichtung zum verwalten von zugriffen mehrerer softwarekomponenten auf softwareschnittstellen
DE112020002785T5 (de) Verfahren für ein virtualisierungssystem auf container-grundlage
EP1665031A2 (de) Verfahren zur installation einer programmkomponente
DE102022113922A1 (de) Ota-master, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE102012217328A1 (de) Verfahren zum Simulieren eines Steuergeräts
WO2021047970A1 (de) Software-komponenten für eine software-architektur
WO2021089308A1 (de) System zum steuern einer maschine
DE102020123506A1 (de) Verfahren zur Erzeugung von Quellcode mit servicebasierter Kommunikation
WO2021089297A1 (de) System zum steuern einer maschine
DE102021202017A1 (de) Verfahren zum Betreiben einer Recheneinheit
DE102004012315A1 (de) Verfahren zur automatischen Anpassung von Software
WO2021089295A1 (de) Verfahren und vorrichtung zum verwalten einer softwarekomponente für ein vorgegebenes system

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: 20793326

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: 20793326

Country of ref document: EP

Kind code of ref document: A1