WO2022184781A1 - Verfahren zum betreiben einer recheneinheit - Google Patents

Verfahren zum betreiben einer recheneinheit Download PDF

Info

Publication number
WO2022184781A1
WO2022184781A1 PCT/EP2022/055304 EP2022055304W WO2022184781A1 WO 2022184781 A1 WO2022184781 A1 WO 2022184781A1 EP 2022055304 W EP2022055304 W EP 2022055304W WO 2022184781 A1 WO2022184781 A1 WO 2022184781A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
program
communication
functions
layer
Prior art date
Application number
PCT/EP2022/055304
Other languages
English (en)
French (fr)
Inventor
Udo Schulz
Micha Muenzenmay
Mouham Tanimou
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
Publication of WO2022184781A1 publication Critical patent/WO2022184781A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space

Definitions

  • the present invention relates to a method for operating a computing unit, in particular also a system with a plurality of computing units, and a computing unit or a system and a computer program for its implementation.
  • control devices can be used that provide various program functions or functions or applications or programs or program parts that are used for the mechatronic system operated by the control device, e.g. a brake control system.
  • Such functions or applications particularly when they relate to the specific mechatronic system, are conventionally all provided on the relevant individual control unit and are only designed for this.
  • the invention deals with the operation of one or more communicatively connected computing units and the execution of one or more Program functions (also referred to simply as functions below) or applications thereon which are provided, for example, for a specific mechatronic system in a vehicle (but this does not necessarily have to be the case). Communication is made possible between such functions, so that the functions can, for example, exchange data or other information with one another or, in general, one function can access another function.
  • Program functions also referred to simply as functions below
  • applications thereon which are provided, for example, for a specific mechatronic system in a vehicle (but this does not necessarily have to be the case).
  • Communication is made possible between such functions, so that the functions can, for example, exchange data or other information with one another or, in general, one function can access another function.
  • the invention makes it possible that these functions do not have to be provided or executed on a single computing unit (e.g. a control unit of a vehicle) - as was previously the case - but rather via different computing units that are networked or communicatively connected to one another, for example are, can be distributed, and in particular independent of platform and/or operating system.
  • a function can also be provided, for example, in a server or the like ("cloud") that is located remotely from another computing unit and is wirelessly connected to it for communication.
  • the invention makes use of various layers, which are made available or set up accordingly, similar to what is known as an OSI model (also referred to as an ISO/OSI reference model), which is generally a reference model for network protocols as a layered architecture.
  • OSI model also referred to as an ISO/OSI reference model
  • the purpose of the OSI model is, for example, to describe communication across a wide variety of technical systems and to promote further development.
  • this model defines seven consecutive layers, each with narrowly defined tasks.
  • Network protocols defined in the same layer with clear interfaces are easily interchangeable, even if they have a central function like the Internet Protocol.
  • the interfaces between the layers are abstractly standardized in the OSI model.
  • a component implemented according to the OSI model is interchangeable without fundamentally changing the purpose and functionality of the system.
  • Event when interested in a specific event and possibly associated process data, the client opens a subscription for an event with the server. This usually acknowledges the receipt of the request. The actual control and data flow when an event occurs is independent of time from the server to the client).
  • a function-communication-abstraction layer engaging a ture Communication Abstraction Layer
  • FCAL ture Communication Abstraction Layer
  • FIL Function Integration Layer
  • FIL Function Integration Library
  • the implementation is not limited to a specific machine or a specific system, but behaves dynamically, i.e. it changes automatically with changing variants of a connected hardware.
  • driver and/or interfaces provided can therefore be adapted at runtime as required, in particular dynamically.
  • the developer of an application or function is supported by the platform used when processing this potential dynamic with regard to connected hardware - and the API available with it (API stands for "Application Programming Interface” and designates a programming or user interface).
  • the FIL in particular allows, for example, different counterparts to different interfaces of a layer model, in particular the OSI model, to be formed, preferably with different levels of abstraction.
  • the entire system architecture can be designed in a modular manner or changed statically and dynamically.
  • a communication broker also known as FCB, "Feature Communication Broker”; this is another layer that enables an interface with e.g. conversion of protocols
  • FCB Feature Communication Broker
  • a driver module e.g. as part of the FIL
  • runtime dynamic change
  • outsourcing and aggregation of functions of different computing units of different systems in sub-central (cf. edge computing) and central processing units (cf. cloud computing) can be implemented, which can offer advantages in terms of costs, reliability or range of functions.
  • the proposed layers already define a number of interfaces that enable agnostic (i.e. independent) use of external control unit interfaces, actuators and sensors.
  • the FIL represents a database that can be dynamically changed at runtime with interfaces from the system environment (e.g. from bus systems) and infrastructure components in the system.
  • This advantage is offset by the FCAL.
  • This can be understood as a type of modifiable adapter whose components (this can be an FCAL API and a FIL API, for example) enable a service-oriented and container-based system architecture, for example.
  • the FCAL also enables communication via lower-lying communication levels.
  • the FCAL also abstracts possible interfaces between functions themselves and thus allows an efficient, distributed structure of functions, as already explained above.
  • Auxiliary functions such as libraries, data processing and data storage and similar function blocks that benefit from such a centralized, high-quality implementation are also conceivable here. Thanks to the generic, abstract implementation of the interfaces for these auxiliary functions, new types of cooperation models for the development of complex functions are also possible.
  • a particular advantage here is that with the same architecture, almost all interfaces supported by control units (ECU) with regard to their infrastructure and third-party systems connected via bus systems can be abstracted from app-like software (applications) and used agnostically. In the same way, the interfaces between the functions can also be used agnostically.
  • This enables a control unit-independent development of useful and/or application software (functions, app-like software), which enables increases in efficiency in development.
  • the decomposition of currently closed functionalities through the use of this system structure or system architecture results in further areas for efficiency. Increases in ciency as well as new possibilities for functional composition and distributed development.
  • the use of the APIs mentioned represents a central interface of the service-oriented software components and their respective advantages.
  • a processing unit e.g. a control unit of a motor vehicle or a system with several such processing units is set up, in particular in terms of programming, to carry out a method according to the invention.
  • Suitable data carriers for providing the computer program are, in particular, magnetic, optical and electrical storage devices such as hard drives, flash memories, EEPROMs, DVDs, etc. It is also possible to download a program via computer networks (Internet, intranet, etc.).
  • FIG. 1 schematically shows an arrangement of computing units in which a method according to the invention can be carried out.
  • FIGS. 2 to 5 show diagrammatically various layers as can be used in various preferred embodiments in methods according to the invention.
  • a vehicle 100 is shown schematically in FIG. 1, in which, by way of example, three computing units 110, 112, 114 (this can in particular be control units) are provided, which communicate by means of, for example, two different communication media 120, 122 (e.g. CAN, Ethernet). be in communication.
  • a wireless communication link 130 can be used to communicate with a computing unit 140, e.g. It goes without saying that the other computing units can also exchange data with one another or in some other way.
  • a software or program function 150 is shown as an example, which includes four different functions or applications or program parts F1, F2, F3 and F4 (there may be more or fewer), which together, for example, enable the operation of a specific mechatronic system, but on distributed over the four different computing units 110, 112, 114 and 140.
  • an adaptive thermal management represents such a function: In an embedded (embedded) control unit (SG) (eg the computing unit 114) of the vehicle, various data (such as temperature, humidity, ...) are recorded via sensors or virtual sensors This data are aggregated, for example, in a further processing unit (e.g. 112) and transmitted via a wireless connection (e.g. 110) to a further processing unit (e.g. 140, e.g.
  • adaptation parameters for example for correcting injection parameters, such as a start of activation, are then calculated using complex models and/or a control duration of an injection valve
  • a further processing unit e.g. 110
  • this (110) controls the actuators (e.g. power switches for activating fuel injection valves) directly.
  • Various other distributed functions can then be represented analogously.
  • the architecture proposed within the scope of the invention comprises several dimensions, which are to be explained separately below.
  • the different elements describe the different tasks, functions and advantages of the FCAL and the FIL.
  • the FCAL and the FIL represent an extension and improvement of existing layer models for communication (such as the OSI model mentioned). Such layers are shown in FIG. 2 for a function 200 by way of example.
  • the FCAL 210 with its interfaces is based in particular on the classic layers of the OSI layer model.
  • the implementation of the FCAL and the FIL 230 is target-independent, i.e. independent of the target hardware. According to the above understanding, the individual components can be exchanged here. This only requires that the respective intermediate layers are exchanged accordingly.
  • the implementation of the FCB 220 can be exchanged, while the rest of the architecture (with the exception of the FCAL API) does not have to be changed.
  • Interfaces or APIs are not just APIs, but also have a quality criterion (e.g. reaction time - "contract that the answer will be given in x seconds ")
  • a validation of this "Contract Based Communication” is then e.g. only possible by the FIL, since this also "sees” the physical side (e.g. ISOBUS or I/O in layer 270).
  • FCAL and FIL represent individual layers, which in turn consist or at least can consist of layers.
  • the FIL 230 comprises a so-called FIL coordinator 232 as a central element, which contains specific instances of generic machine models (also going beyond the ISOBUS, for example for machines with proprietary interfaces; ISOBUS is a data bus for agricultural implements or . Vehicles) connects to I/O modules. These modules can take different forms (different programming languages, syntactic depth etc.) be. For this reason, the FIL 230 is able to form different counterparts to different interfaces of the OSI model, with different levels of abstraction, as is the case, for example, in Figure 3 with levels L1 to L7 for different components 300, 302 , 304, 306 is shown.
  • These components can be simple drivers, e.g. for active and passive sensors or actuators, where only an electrical voltage is measured or a PWM (pulse width modulated) control signal is specified.
  • the FIL takes on the other functions up to the FCB. This means that the FIL turns the electrical signal (voltage or PWM) into a physical signal and vice versa, and a service for the FCB is generated from the physical signal and vice versa.
  • the FIL recognizes which level is involved, e.g. from the manifest (a configuration directory) of the affected component.
  • the FIL 230 can also include a FIL ISOBUS adapter 234 with FIL-VAR1 236, FIL 'AdaptBase Part' 238, FIL-VAR2240 and FIL-VAR3242.
  • a mixed FIL adapter 244 In a further layer, the FIL 230 can, for example, have a VAR1 stack 246 (a library for ISOBUS), a VAR2 stack 248 (an alternative library for ISOBUS), a VAR3 stack 250 (another alternative Library for ISOBUS), further CANs 252, a GNSS service 256, a sensor service 256 and an actuator service 258 include.
  • a software or operating system layer after the FIL 230, a socket CAN 262, a GNSS driver 264 (GNSS stands for Global Navigation Satellite System) and further drivers 266 can follow, finally a layer 270 that Hardware level and includes, for example, physical communication interfaces such as CAN, LIN, FlexRay, Ethernet, I/O and the like.
  • GNSS Global Navigation Satellite System
  • ISOBUS Conforms to the ISO 11783 standard. This standard firstly defines the physical properties, such as plugs and cables, secondly the type of participants and thirdly the data formats and interfaces of the network.
  • FIL-VAR1, FIL-VAR2, FIL-VAR3 Adapter for variants of the ISOBUS implementations.
  • VAR1 stack, VAR2 stack, VAR3 stack Variants of the ISOBUS implementations.
  • CAN is internationally standardized as ISO 11898 and defines layers 1 (physical layer) and 2 (data security layer) in the ISO/OSI reference model.
  • the LIN bus is a low-cost serial communication protocol that effectively supports remote applications within a vehicle network. It is intended to complement the existing CAN network, resulting in hierarchical networks within cars.
  • FlexRay serial, deterministic and fault-tolerant field bus system for use in automobiles, comparable to TTP.
  • Ethernet a technology that specifies software (protocols, etc.) and hardware (cables, distributors, network cards, etc.) for wired data networks, which was originally intended for local data networks (LANs) and is therefore also referred to as LAN technology. It enables the exchange of data in the form of data frames between the devices (computers, printers and the like) connected in a local area network (LAN).
  • LAN local area network
  • Socket an operating system-provided object that serves as a communication endpoint. Communication via sockets is usually bidirectional, which means that data can be both received and sent via the socket.
  • GNSS is a global navigation satellite system for position determination and navigation on earth and in the air by receiving signals from navigation satellites and pseudolites.
  • GNSS is a collective term for the use of existing and future global satellite systems (e.g. NAVSTAR GPS, GLONASS, Galileo, ...)
  • I/O Input/Output: this describes the communication / interaction of an information system with its 'outside world', e.g. B. external devices.
  • the devices themselves are connected directly via data, control and address buses. They contain buffers to temporarily store requests and responses.
  • a fundamental task of implementing the FCAL is the exchange of information between functions; it should be without platform dependencies (not limited by implementation of the respective platform, e.g. performance of the respective FCB), dynamically configurable (extension with new executable units or reconfiguration of an existing executable unit) and language-agnostic as well as control of communication and monitoring (bandwidth control). ) enable.
  • connection can then be made possible on the function side (container side) through the FIL API (the developer only "sees” this).
  • the connection to the FCB is mapped by the FCAL-API (a layer within the FCAL.
  • the FIL is itself connected to the FCB via an FCAL-API (see FIG. 4).
  • Another aspect is the dynamic scalability of the interfaces.
  • Object-oriented modeling enables adaptation to different machine sizes. This makes machine models scalable: In particular, e.g. with regard to the working width of a field sprayer (1 to n nozzles) or a row seed drill (number of rows).
  • An exemplary explanation using a sprayer (agricultural sprayer) with section control is as follows: Classes to select are Sprayer, Tank and Section; a sprayer can have multiple tanks, a tank multiple sections, etc.; For example, the sprayer object provides methods to access the tank objects; For example, the tank object provides methods to access the section objects; for example, a section object provides methods for opening and closing the nozzles.
  • Classes to select are Sprayer, Tank and Section; a sprayer can have multiple tanks, a tank multiple sections, etc.;
  • the sprayer object provides methods to access the tank objects;
  • the tank object provides methods to access the section objects; for example, a section object provides methods for opening and closing the nozzles.
  • the structure mentioned makes it possible to address different levels with different levels of granularity within the object hierarchy.
  • an agricultural seed drill or a construction machine can in particular be an excavator with a shovel or a (hydraulic) hammer, in particular each with a variable size of shovel or hammer, which can be attached to the excavator arm.
  • the FIL represents the central interface to the physical machine. This enables better compatibility, e.g. if a function on only supports the control of one section, but the machine has several sections that can be controlled in different ways.
  • the FIL summarizes the API needs of the machine. Dynamic adjustment at runtime is also possible; eg, the FIL may discover that new or more granular machine interfaces are present on the implement. In this case, a detection mechanism ensures that the availability of these machine interfaces is made known to the functions and that the necessary drivers (e.g. from the cloud) are downloaded. With an architecture based on OSI, however, this is not possible, especially not at runtime.
  • FIG. 5 in which the architecture from FIG. 2 is basically shown again, but for three functions 200 by way of example (the FIL 230 is also only shown as a block). Even if the functions are referred to here in the same way, it is understood that in practice the functions differ from one another are different but linked in the same way.
  • the functions 200 are each shown as part of a container 206 in which, in addition to the function 200 itself, a data store 202, a function configuration directory 204 and the FCAL 210 assigned to the function 200 are provided.
  • GUI framework 510 GUI stands for “Graphical User Interface”, ie a graphical user interface
  • function integration framework 520 are a function integration framework utility 522 (serving e.g. for installing, configuring, updating, starting, stopping, pausing, resuming and uninstalling functions), a monitoring module 524 (serving e.g. for securing safety monitoring or for fail-safe mode) and a memory 526 for containers with functions.
  • function integration framework utility 522 serving e.g. for installing, configuring, updating, starting, stopping, pausing, resuming and uninstalling functions
  • monitoring module 524 serving e.g. for securing safety monitoring or for fail-safe mode
  • memory 526 for containers with functions.
  • a landing zone 530 (the landing zone is a zone in memory that is reserved solely for communication and exchange between the processing unit and its outside world) is provided, which includes an entry zone 532 and an exit zone 534 .
  • An FEK 500 is also planned.
  • FEK stands for FEATURE Enabling Kit - and represents a computing unit in which the framework is installed and running. For example, function GUI framework 510, function integration framework 520, and landing zone 530 reside and run on the computational unit.
  • the required interfaces (usually specification of the FIL-API) can be specifically named in a directory (or manifest, cf. function configuration directory 204) of the functions.
  • the expected interfaces are stored centrally in the registry (e.g. also the I/O requirements).
  • FIL and function for each individual API can be connected (combination) in an arbitration process; this enables efficient management of the APIs).
  • the FIL adapts to the function or implements the interfaces according to the interfaces noted in the registry.
  • a communication protocol for example, which enables meta-communication between FIL and the function, is then coordinated (typically not for user data/communication). This meta-communication is intended for the exchange of information that is not directly concerned with the control of actuators, drivers, etc., but that supports functionality and quality of service (service quality).
  • detection, arbitration and monitoring are coordinated and enable the function to communicate securely (in terms of functional safety, avoidance of bit errors, data security as well as data integrity and data consistency).
  • the FIL can (dynamically) adapt the drivers and the interfaces at runtime.
  • a new attachment such as a sprayer (system extension) is connected to the tractor (system)
  • the configuration data of the attachment is made known via the ISOBUS.
  • the FIL uses its discovery (recognition) mechanism to recognize whether the data and routines for controlling this attachment (subsystem) are available.
  • the discovery mechanism searches through its interface pool (local database). Missing drivers and interfaces are automatically downloaded from the cloud (databases with configurations), installed and made available for use/control of the attachment.
  • the dynamics described here cannot be represented with the standard OSI architecture.
  • the adaptation concerns both an extension and a reduction of interfaces and drivers. If, for example, an existing feature is replaced by a new feature with fewer interfaces, then the unnecessary interfaces and associated drivers are automatically removed by the FIL. Further concepts would be, for example, the ability to test the function, which is increased by the above communication architecture.
  • the FIL can be replaced by a test FIL (e.g. FIL mockup).
  • a virtual machine class simulates (to the developer) that a physical machine exists.
  • the testing approach can be further developed in such a way that the developer develops and tests his code and logic against this virtual machine class without having knowledge of a real machine or having access to it.
  • a particular aspect of the invention is the already mentioned decomposition of functions or functionalities in mechatronic systems.
  • the system-dependent interfaces of the machine or vehicle are converted into agnostic interfaces by the FIL and made available there for the useful function (the function or the application).
  • This useful function can transfer requirements to external components via the abstracted system into the real world and thus overcome the system limit 'control unit'.
  • an input/output can also be carried out on an external operating system or another functionality can be linked in a further chain.
  • This can also be done via a telemetry connection on a remote operating system or implemented via an automation solution connected via telemetry for partially or fully autonomous control.
  • several functions within the individual system can be linked to one another, e.g. through communication, and carry out a joint task. This can also take place across several computing units of a machine, but also via the realization in distributed computing units of machines connected by telemetry (wireless communication link), as well as in several partially centralized (cf. edge computing) or centralized (cf. cloud computing) converted computing units can be achieved.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben einer Recheneinheit, auf der eine Programmfunktion (200) ausgeführt wird, wobei für die Programmfunktion (200) durch einen Bereitstellungsmechanismus eine Kommunikation mit wenigstens einer anderen Programmfunktion (200) unter Verwendung einer Funktions-Kommunikations-Abstraktions-Schicht (210) und einer Funktions-Integrations-Schicht (230) bereitgestellt wird, wobei der Bereitstellungsmechanismus folgendes umfasst: Zuordnen der Funktions-Kommunikations-Abstraktions-Schicht (210) zu der Programmfunktion (200) und Betreiben der Funktions-Kommunikations-Abstraktions-Schicht (210) derart, dass sie eine Schnittstelle von der Programmfunktion zur mittelbaren oder unmittelbaren Kommunikation mit der Funktions-Integrations-Schicht (230) bereitstellt, Betreiben der Funktions-Integrations-Schicht (230) derart, dass sie eine Schnittstelle zur mittelbaren oder unmittelbaren Kommunikation mit der Funktions-Kommunikations-Abstraktions-Schicht (210) der Programmfunktion bereitstellt, und Betreiben der Funktions-Integrations-Schicht (230) derart, dass sie einen mittelbaren oder unmittelbaren Kommunikationszugriff auf ein auf der Recheneinheit ausgeführtes Betriebssystem und/oder eine Kommunikationsschnittstelle bereitstellt.

Description

Beschreibung
Titel
Verfahren zum Betreiben einer Recheneinheit
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben einer Rechenein heit, 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 Pro grammfunktionen oder Funktionen oder Anwendungen bzw. Programme oder Programmteile bereitstellen, die für das von dem Steuergerät betriebene mecha- tronische System, z.B. ein Bremsregelsystem, verwendet werden. Solche Funkti onen oder Anwendungen, insbesondere wenn sie sich auf das konkrete mecha- tronische System beziehen, werden herkömmlicherweise alle auf dem betreffen den, einzelnen Steuergerät bereitgestellt und sind auch nur dafür ausgelegt.
Offenbarung der Erfindung
Erfindungsgemäß werden ein Verfahren zum Betreiben einer Recheneinheit so wie eine Recheneinheit bzw. ein System und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorge schlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
Die Erfindung beschäftigt sich mit dem Betreiben einer oder mehrerer kommuni kativ 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. kommunika tiv 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 be reitgestellt bzw. eingerichtet werden, ähnlich einem sog. OSI-Modell (auch als ISO/OSI-Referenzmodell bezeichnet), das allgemein ein Referenzmodell für Netzwerkprotokolle als Schichtenarchitektur ist. Zweck des OSI-Modells ist bei spielsweise, 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 OSI-Modell abstrakt standardisiert. Im Idealfall ist eine Komponente, die entsprechend dem OSI-Modell implementiert wurde, aus tauschbar, 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 hin sichtlich 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 Ser ver. Dieser quittiert üblicherweise den Eingang der Anfrage. Der eigentliche Kon- troll- 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 aus geführt wird, durch einen entsprechenden Bereitstellungsmechanismus bereitge stelltwerden: eine Funktions-Kommunikations-Abstraktions-Schicht (engl.: "Fea ture 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 Schich ten 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 zu grundeliegende Software-Kommunikationsinfrastruktur zu nutzen. Zudem ist die Implementierung nicht auf eine spezifische Maschine oder ein spezifisches Sys tem 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 Sol stgrößen auf internen Signalen und auf Bussystemen). Insbesondere die FIL erlaubt z.B., dass verschiedene Gegenstücke zu verschiedenen Schnitt stellen eines Schichten-Modells, insbesondere des OSI-Modells, gebildet wer den, vorzugsweise mit unterschiedlichen Abstraktionsstufen oder Abstraktionsle- vel.
Durch die Verwendung einer auf Schichten basierenden Kommunikationsarchi tektur (Schnittstellen) kann die gesamte Systemarchitektur modular gestaltet bzw. statisch und dynamisch verändert werden. Beispielsweise kann die Imple mentierung 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ände rung). 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 Funkti- ons-lntegrations-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 Funkti onen (es kann sich dabei auch um Sub- bzw. Unterfunktionen von übergeordne ten Funktionen handeln) können so in einem Netz von Recheneinheiten verteilt werden, wobei diese Recheneinheiten nicht in einem Steuergerät oder einer Ma schine vorliegen müssen, sondern zudem auch über Maschinen hinweg ver wendbar 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 hin sichtlich 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 insbeson dere 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 ser- vice-orientierte sowie eine container-basierte Systemarchitektur ermöglicht.
Zudem ermöglicht die FCAL auch die Kommunikation über tieferliegende Kom munikationsebenen. Die FCAL abstrahiert auch mögliche Schnittstellen zwischen Funktionen selbst und erlaubt so einen effizienten, verteilten Aufbau von Funkti onen, wie vorstehend schon erläutert. Denkbar sind hier z.B. auch Hilfsfunktio nen wie Bibliotheken, Datenverarbeitung und Datenspeicherung und ähnliche Funktionsblöcke, die von einer solchen zentralisierten, hochwertigen Umsetzung profitieren. Durch die generische, abstrahierte Umsetzung der Schnittstellen die ser Hilfsfunktionen sind zudem neuartige Zusammenarbeitsmodelle zur Entwick lung 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 (Anwen dungen) abstrahiert und agnostisch genutzt werden können. In derselben Art und Weise können auch die Schnittstellen zwischen den Funktionen agnostisch ge nutzt 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 Dekom position von derzeit geschlossenen Funktionalitäten durch Nutzung dieser Sys temstruktur bzw. Systemarchitektur ergeben sich noch weitere Räume für Effi- zienzsteigerungen 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 Kraftfahr zeugs bzw. ein System mit mehreren solchen Recheneinheiten ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durch zufü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 Da tenträger zur Bereitstellung des Computerprogramms sind insbesondere magne tische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computer netze (Internet, Intranet usw.) ist möglich.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Be schreibung und der beiliegenden Zeichnung.
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schema tisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
Kurze Beschreibung der Zeichnungen
Figur 1 zeigt schematisch eine Anordnung von Recheneinheiten, bei der ein er findungsgemäßes Verfahren durchführbar ist. Figuren 2 bis 5 zeigen schematisch verschiedene Schichten, wie sie bei erfin dungsgemäßen Verfahren in verschiedenen bevorzugten Ausführungs formen zum Einsatz kommen können.
Ausführungsform(en) der Erfindung
In Figur 1 ist schematisch ein Fahrzeug 100 gezeigt, in dem beispielhaft drei Re cheneinheiten 110, 112, 114 (es kann sich dabei insbesondere um Steuergeräte handeln) vorgesehen sind, die mittels beispielhaft zweier verschiedener Kommu nikationsmedien 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 Rechen einheit 140, z.B. einem Server einer Cloud, möglich. Es versteht sich, dass auch die anderen Recheneinheiten untereinander oder anderweitig Daten austau- schen können.
Beispielhaft ist eine Software oder Programmfunktion 150 gezeigt, die vier ver schiedene 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 ausge fü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 einerweiteren 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) er mittelt werden, die dann zu einerweiteren 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 Di mensionen, die im Folgenden separat erläutert werden sollen. Die unterschiedli chen Elemente beschreiben dabei die unterschiedlichen Aufgaben, Funktions weisen und Vorteile der FCAL sowie der FIL. Die FCAL sowie die FIL stellen ins besondere eine Erweiterung und Verbesserung bestehender Schichtenmodelle zur Kommunikation (wie z.B. des erwähnten OSI-Modells) dar. Solche Schichten sind beispielhaft in Figur 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 targetunab hä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 wer den, 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ütekriteri um (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, wel che 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 Ge räten bzw. Fahrzeugen) mit I/O-Modulen verbindet. Diese Module können unter schiedlicher Gestalt (verschiedene Programmiersprachen, syntaktische Tiefe usw.) sein. Aus diesem Grund ist die FIL 230 in der Lage, unterschiedliche Ge genstücke zu verschieden Schnittstellen des OSI-Modells zu bilden, und zwar mit unterschiedlichen Abstraktionsstufen/-level, wie dies z.B. in Figur 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 umge kehrt. 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 unters ten 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 Spritzmen ge XY ein“.
Im genannten Sensor-Beispiel Temperatur könnte das eine Motortemperatur be treffen, im untersten Level gibt es dann eine Spannung, darüber eine Tempera tur, darüber eine Plausibilisierung des Temperaturbereichs und - Temperaturver laufs 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-VAR2240 und FIL-VAR3242 umfassen. Ebenso einen gemischten FIL-Adapter 244. In einerweiteren 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 umfas- sen. In einerweiteren 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 fol gen, schließlich eine Schicht 270, die auf Hardware-Ebene liegt und z.B. physika lische 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 phy sikalischen Eigenschaften, wie Stecker und Leitungen, zweitens die Art der Teil nehmer 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 Fahrzeug netzwerks 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, Ver teiler, 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 Daten- frames zwischen den in einem lokalen Netz (LAN) angeschlossenen Geräten (Computer, Drucker und dergleichen).
Socket: ein vom Betriebssystem bereitgestelltes Objekt, das als Kommunikati onsendpunkt dient. Die Kommunikation über Sockets erfolgt in der Regel bidirek tional, das heißt, über das Socket können Daten sowohl empfangen als auch ge sendet 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 Pseudoli- ten. 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 ent halten Puffer um Anfragen und Antworten zwischenzuspeichern.
Für die FCAL gelten vergleichbare Überlegungen, ein Schema hierzu ist in Figur 4 dargestellt, indem über verschiedene Level (zwischen L1 und L7) eine Kom munikation 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än gigkeiten (nicht limitiert durch Umsetzung der jeweiligen Plattform z.B. Perfor- manz 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. Figur 4).
Ein weiterer Aspekt ist die dynamische Skalierbarkeit der Interfaces bzw. Schnitt stellen. Die objektorientierte Modellierung ermöglicht die Anpassung an ver schiedene Maschinengrößen. Dadurch sind Maschinenmodelle skalierbar: Insbe sondere 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 Ma schinentypen der Softwareplattform realisieren (mit „Pflichtmethoden“ und „Vari ablen“). 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üh gerä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 un terschiedliche 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 wer den 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 Funkti- on nur die Ansteuerung eines Abschnitts unterstützt, die Maschine jedoch mehre re unterschiedlich ansteuerbare Abschnitte besitzt. In diesem Fall fasst die FIL die API-Bedarfe der Maschine zusammen. Ebenso wird eine dynamische Anpas sung zur Laufzeit ermöglicht; z.B. kann es sein, dass die FIL entdeckt, dass auf dem Anbaugerät neue oder granulärere Maschinenschnittstellen vorhanden sind. In diesem Fall sorgt ein Erkennungs-Mechanismus dafür, dass die Verfügbarkeit dieser Maschinenschnittstellen den Funktionen bekannt sind bzw. gemacht wer den sowie die notwendigen Treiber (z.B. aus der Cloud) heruntergeladen wer den. Bei einer Architektur nach OSI ist dies hingegen nicht möglich, insbesonde re nicht zur Laufzeit.
Generell ist es damit möglich, dass z.B. eine (neue) Programmfunktion hinzuge fügt wird, indem gemäß einem Funktionskonfigurationsverzeichnis der hinzuzu fügenden Programmfunktion eine Funktions-Kommunikations-Abstraktions- Schicht der hinzuzufügenden Programmfunktion zugeordnet wird und indem die se Funktions-Kommunikations-Abstraktions-Schicht derart betrieben wird, dass sie eine Schnittstelle von der Programmfunktion zur mittelbaren oder unmittelba ren Kommunikation mit der Funktions-Integrations-Schicht bereitstellt. Eine sol che neue Funktion kann dann auf einer Recheneinheit ausgeführt werden, auf der schon andere Funktionen laufen, aber auch auf einer anderen Rechenein heit, 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 Schnittstellenan- spruch/-Bedarf. Solange jedoch keine physikalischen Schnittstellen angeschlos sen sind bzw. zur Laufzeit aufgerufen werden, liegen die Schnittstellen unkonkret und generisch vor. Dies endet, sobald physikalische Schnittstellen angeschlos sen werden bzw. beim Starten angeschlossen sind.
Hierzu sei auf Figur 5 verwiesen, in der die Architektur aus Figur 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 be zeichnet 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 Funktionskonfigurationsver zeichnis 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 wel cher neue Funktionen hinzugefügt oder bestehende Funktionen entfernt werden können. In einem Funktionsintegrations-Framework 520 sind ein Funktionsinteg- rations-Framework-Dienstprogramm 522 (dieses dient z.B. zum Installieren, Kon figurieren, Updaten, Starten, Stoppen, Pausieren, Wiederaufnehmen und De installieren von Funktionen), ein Überwachungsmodul 524 (dient z.B. als Sicher heitsü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 Re cheneinheit und ihre Außenwelt reserviert ist) vorgesehen, die eine Eingangszo ne 532 und eine Ausgangszone 534 umfasst. Zudem ist eine FEK 500 vorgese hen. 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 Ma nifest, vgl. Funktionskonfigurationsverzeichnis 204) der Funktionen die benötig ten 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 Kommunika tionsprotokoll, womit die Meta-Kommunikation zwischen FIL und Funktion ermög licht wird, abgestimmt (typischerweise nicht für Nutzdaten/Kommunikation). Die se Meta-Kommunikation ist für den Austausch von Informationen gedacht, wel che sich nicht unmittelbar mit der Ansteuerung von Aktorik, Treibern etc. befas sen, sondern die Funktionsfähigkeit und Quality-of-Service (Dienste-Qualität) un terstützen.
Nachdem diese Schritte durchlaufen sind, sind Erkennung, die Arbitrierung und das Monitoring (APIs, und Zugriff auf API) aufeinander abgestimmt und ermögli chen der Funktion eine sichere Kommunikation (hinsichtlich funktionaler Sicher heit, Vermeidung von Bitfehlern, Datensicherheit sowie Datenintegrität und Da tenkonsistenz).
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 Konfi gurationsdaten des Anbaugerätes (Systemerweiterung) bekannt gegeben. An hand 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 sei nen Interfacepool (lokale Datenbank) durch. Fehlende Treiber und Schnittstellen werden automatisch aus der Cloud (Datenbanken mit Konfigurationen) herunter geladen, 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 vir tuelle 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 Dekom position 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 Nutzfunkti on (der Funktion bzw. der Anwendung) zur Verfügung gestellt. Diese Nutzfunkti on 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 er folgen oder aber in einerweiteren Verkettung eine weitere Funktionalität mit an gebunden werden. Dies kann ebenfalls über eine Telemetrieverbindung auf ei nem entfernten Bediensystem erfolgen oder über eine per Telemetrie angebun dene Automatisierungslösung zur teil- oder vollautonomen Ansteuerung umge setzt 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 mehre re Recheneinheiten einer Maschine hinweg erfolgen, aber auch über die Reali sierung in verteilten Recheneinheiten von per Telemetrie (drahtlose Kommunika tionsverbindung) verbundenen Maschinen, sowie in mehreren teilzentralisiert (vgl. Edge Computing) oder zentralisiert (vgl. Cloud Computing) umgesetzten Recheneinheiten erreicht werden.

Claims

Ansprüche
1. Verfahren zum Betreiben einer Recheneinheit (110, 112, 114, 140), auf der eine Programmfunktion (150, 200, F1, F2, F3, F4) als Teil eines Programms ausgeführt wird, wobei für die Programmfunktion (200) durch einen Bereit stellungsmechanismus eine Kommunikation mit wenigstens einer anderen Programmfunktion (200), die Teil des Programms ist, unter Verwendung ei ner Funktions-Kommunikations-Abstraktions-Schicht (210) und einer Funkti- ons-lntegrations-Schicht (230) eingerichtet wird, wobei der Bereitstellungs mechanismus folgendes umfasst:
Zuordnen der Funktions-Kommunikations-Abstraktions-Schicht (210) zu der Programmfunktion (150, 200, F1, F2, F3, F4) und Betreiben der Funkti- ons-Kommunikations-Abstraktions-Schicht (210) derart, dass sie eine Schnittstelle (212, 214) von der Programmfunktion zur mittelbaren oder un mittelbaren Kommunikation mit der Funktions-Integrations-Schicht (230) be reitstellt,
Betreiben der Funktions-Integrations-Schicht (230) derart, dass sie eine Schnittstelle zur mittelbaren oder unmittelbaren Kommunikation mit der Funktions-Kommunikations-Abstraktions-Schicht (210) der Programmfunkti on bereitstellt, und
Betreiben der Funktions-Integrations-Schicht (230) derart, dass sie ei nen mittelbaren oder unmittelbaren Kommunikationszugriff auf ein auf der Recheneinheit (110, 112, 114, 140) ausgeführtes Betriebssystem und/oder eine Kommunikationsschnittstelle bereitstellt.
2. Verfahren nach Anspruch 1, wobei die Funktions-Integrations-Schicht (230) derart betrieben wird, dass diese verschiedene Gegenstücke zu verschiede nen Schnittstellen eines Schichten-Modells, insbesondere eines OSI- Modells, bildet, vorzugsweise mit unterschiedlichen Abstraktionsstufen.
3. Verfahren nach Anspruch 1 oder 2, wobei die Funktions-Integrations-Schicht (230) derart betrieben wird, dass Treiber und/oder bereitgestellte Schnittstel len zur Laufzeit bei Bedarf angepasst werden, insbesondere dynamisch.
4. Verfahren nach einem der vorstehenden Ansprüche, wobei der Bereitstel lungsmechanismus weiterhin umfasst:
Bereitstellen einer Kommunikations-Broker-Schicht (220) und Betreiben der Kommunikations-Broker-Schicht (220) derart, dass sie eine Schnittstelle zur Funktions-Integrations-Schicht (230) und eine Schnittstelle zur Funkti- ons-Kommunikations-Abstraktions-Schicht (210) bereitstellt.
5. Verfahren nach einem der vorstehenden Ansprüche, wobei auf der Rechen einheit (110, 112, 114, 140) mehrere Programmfunktionen (200, F1, F2, F3, F4) ausgeführt werden, die Teil des Programms sind, für die untereinander eine Kommunikation bereitgestellt wird, indem jede der mehreren Pro grammfunktionen (200, F1, F2, F3, F4) durch den Bereitstellungsmechanis mus bereitgestellt wird.
6. Verfahren zum Betreiben eines Systems umfassend mehrere Recheneinhei ten (110, 112, 114, 140), die mittels wenigstens einer Kommunikationsver bindung verbunden sind, wobei jede der mehreren Recheneinheiten (110,
112, 114, 140) jeweils gemäß einem der vorstehenden Ansprüche betrieben wird, sodass darauf jeweils eine oder mehreren Programmfunktionen (200, F1, F2, F3, F4) ausgeführt werden, die insgesamt Teil des Programms sind, und sodass für zwei Programmfunktionen (220), die auf verschiedenen Re cheneinheiten (110, 112, 114, 140) ausgeführt werden, untereinander eine Kommunikation bereitgestellt wird.
7. Verfahren nach Anspruch 6, wobei wenigstens zwei der mehreren Rechen einheiten (110, 112, 114, 140) für zwei verschiedene, insbesondere mechat- ronische, Systeme in einem Fahrzeug (100) verwendet werden.
8. Verfahren nach Anspruch 6, wobei wenigstens eine der mehreren Rechen einheiten (110, 112, 114) für ein, insbesondere mechatronisches, System in einem Fahrzeug (100) verwendet wird, und wobei wenigstens eine der meh reren Recheneinheiten (140) außerhalb des Fahrzeugs (100) angeordnet ist und verwendet wird.
9. Verfahren nach einem der vorstehenden Ansprüche, wobei eine Programm funktion (200, F1, F2, F3, F4), die Teil des Programms ist, auf eine Rechen einheit (110, 112, 114, 140), auf der bereits wenigstens eine Programmfunk tion (200, F1, F2, F3, F4) ausgeführt wird, oder auf eine Recheneinheit, auf der noch keine Programmfunktion ausgeführt, hinzugefügt wird, indem ge mäß einem Funktionskonfigurationsverzeichnis (204) 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 unmit telbaren Kommunikation mit der Funktions-Integrations-Schicht (230) bereit stellt.
10. Verfahren nach einem der vorstehenden Ansprüche, wobei die Programm funktionen (200, F1, F2, F3, F4) ausgewählt sind aus: Betriebsfunktionen für ein mechatronisches System, Hilfsfunktionen, Bibliotheksfunktionen, Daten verarbeitungsfunktionen und Datenspeicherungsfunktionen.
11. Verfahren nach einem der vorstehenden Ansprüche, wobei wenigstens eine Programmfunktion (200, F1, F2, F3, F4) eine Betriebsfunktionen für ein me chatronisches System umfasst, wobei das mechatronisches System ausge wählt ist aus: einem landwirtschaftlichen Sprühgerät, einer landwirtschaftli chen Sämaschine, und einer Baumaschine wie beispielsweise einem Bag ger mit einer Schaufel oder in einem hydraulischen Hammer.
12. Recheneinheit (110, 112, 114, 140) oder System mit mehreren Rechenein heiten (110, 112, 114, 140), die bzw. das dazu eingerichtet ist, alle Verfah rensschritte eines Verfahrens nach einem der vorstehenden Ansprüche durchzuführen.
13. Computerprogramm, das eine Recheneinheit (110, 112, 114, 140) oder ein System mit mehreren Recheneinheiten (110, 112, 114, 140) dazu veran lasst, alle Verfahrensschritte eines Verfahrens nach einem der Ansprüche 1 bis 11 durchzuführen, wenn es auf der Recheneinheit bzw. auf dem System ausgeführt wird.
14. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Com puterprogramm nach Anspruch 13.
PCT/EP2022/055304 2021-03-03 2022-03-02 Verfahren zum betreiben einer recheneinheit WO2022184781A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021202017.8A DE102021202017A1 (de) 2021-03-03 2021-03-03 Verfahren zum Betreiben einer Recheneinheit
DE102021202017.8 2021-03-03

Publications (1)

Publication Number Publication Date
WO2022184781A1 true WO2022184781A1 (de) 2022-09-09

Family

ID=80953301

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/055304 WO2022184781A1 (de) 2021-03-03 2022-03-02 Verfahren zum betreiben einer recheneinheit

Country Status (2)

Country Link
DE (1) DE102021202017A1 (de)
WO (1) WO2022184781A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7523237B2 (en) * 2004-04-01 2009-04-21 Delphi Tecnhologies, Inc. Method and protocol for diagnostics or arbitrarily complex networks of devices

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7523237B2 (en) * 2004-04-01 2009-04-21 Delphi Tecnhologies, Inc. Method and protocol for diagnostics or arbitrarily complex networks of devices

Also Published As

Publication number Publication date
DE102021202017A1 (de) 2022-09-08

Similar Documents

Publication Publication Date Title
EP1738236B1 (de) Automatisierungsnetzwerk mit zustandsmeldenden netzwerkkomponenten
DE10343963A1 (de) Bereitstellung von Diagnoseinformationen
EP3535626B1 (de) Bereitstellung von informationen zu zusatzfunktionalitäten von feldbuskomponenten
DE102010026494A1 (de) Verfahren zur Konfigurierung einer Steuerungseinrichtung
EP2770389A2 (de) Verfahren zur Durchführung einer Konfiguration eines Steuergeräte-Testsystems
DE102007058609A1 (de) Verfahren zur Installation von Objekten für ein komponentenbasiertes Managementsystem für Feldgeräte der Automatisierungstechnik
EP3552062B1 (de) Verfahren zum bereitstellen von sensorbasierten fahrzeugfunktionen in einem kraftfahrzeug sowie kraftfahrzeug-recheneinrichtung und kraftfahrzeug
EP3832517A1 (de) Computerimplementiertes verfahren zur einbindung mindestens eines signalwerts in einem virtuellen steuergerät
DE112009001820T5 (de) Steuervorrichtung, Steuerverfahren und Computerprogramm
WO2020069816A1 (de) Verfahren zum etablieren einer netzwerkkommunikation mittels opc ua
WO2022184781A1 (de) Verfahren zum betreiben einer recheneinheit
EP3821306B1 (de) Verfahren zum parametrieren eines sensorsystems
DE102020204714A1 (de) Verfahren und Vorrichtung zum Prüfen der Kompatibilität zwischen einer Anwendungssoftware und einer mobilen Arbeitsmaschine
DE102020118563A1 (de) Middleware-system und -verfahren
DE102022123358A1 (de) Frequenzbasierte merkmalsbeschränkung für ein neuronales netz
DE102019217046A1 (de) System zum Austausch von Nachrichten durch eine Anwendungssoftware
WO2021047970A1 (de) Software-komponenten für eine software-architektur
DE10394242T5 (de) Verfahren und Instrument zur Zuweisung von Rechenressourcen in einem verteilten Steuersystem
DE102012007321A1 (de) Verfahren zum Betreiben eines Diagnosesystems und Diagnosesystem
DE102020006643A1 (de) Übermittlung von Protokolldaten eines Fahrzeugs für einen Entwicklungsprozess mittels einer Cloud
DE102004008869A1 (de) Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
DE112009001818T5 (de) Steuervorrichtung, Steuerverfahren und Computerprogramm
EP4144003B1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
DE112009001842T5 (de) Steuervorrichtung, Steuerverfahren und Computerprogramm
DE102021124714A1 (de) Verfahren und system bewegen einer logik eines service zwischen ecosystemen

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

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

Country of ref document: EP

Kind code of ref document: A1