SYSTEM FOR THE EXCHANGE OF MESSAGES THROUGH AN APPLICATION SOFTWARE

Abstract

A system for the exchange of messages through an application software. The system includes an abstraction layer for abstracting the messages and an interface library connected to the abstraction layer via a message broker.

Claims

1-11. (canceled)

12. A system for an exchange of messages through an application software, comprising: an abstraction layer configured to abstract the messages; and an interface library connected to the abstraction layer via a message broker.

13. The system as recited in claim 12, wherein: the abstraction layer has a programming interface; and the interface library is connected to the message broker via the programming interface.

14. The system as recited in claim 12, wherein: the system includes a driver layer for a physical layer; and the interface library includes a coordinator for coordination of hardware components, an ISOBUS adapter having a basic part, and at least one CAN protocol stack.

15. The system as recited in claim 14, wherein: the coordinator is adapted to an interface-library basic-parts adapter of the ISOBUS adapter; the interface-library basic-parts adapter contains mutual interfaces for other supplier-specific adapters; and the interface library includes protocol stacks for accessing the physical layer using the driver layer.

16. The system as recited in claim 14, wherein: the coordinator is adapted to supplier-specific adapters of the ISOBUS adapter; the supplier-specific adapters contain supplier-specific interfaces; and the interface library includes protocol stacks for accessing the physical layer using the driver layer.

17. The system as recited in claim 14, wherein: the coordinator is adapted to an adapter for further interfaces; the adapter includes further service-oriented adapters; the interface library includes manufacturer-nonspecific and service-nonspecific protocol stacks; and the protocol stacks communicate with the physical layer using drivers.

18. The system as recited in claim 14, wherein: the coordinator is adapted to an adapter for further interfaces; the adapter includes further service-oriented adapters; the interface library includes manufacturer-specific and service-specific protocol stacks; and the protocol stacks communicate with the physical layer using drivers.

19. The system as recited in claim 12, wherein: the interface library includes a further adapter for other interfaces; and the system includes further drivers for the interfaces.

20. The system as recited in claim 19, wherein the interfaces include at least one of the following: a LIN bus, or a FlexRay bus, or an Ethernet, or further inputs and outputs.

21. The system as recited in claim 12, wherein: the interface library includes a GPS service; and the system includes a GPS driver.

22. The system as recited in claim 12, wherein: the interface library includes a sensor service, or the interface library includes an actuator service.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Exemplary embodiments of the present invention are explained in greater detail in the following description and represented in the figures.

[0013] FIG. 1 shows the block diagram of a system according to one specific example embodiment of the present invention.

[0014] FIG. 2 shows schematically an interface library of the system according to FIG. 1.

[0015] FIG. 3 shows the connection between the interface library and the application software.

[0016] FIGS. 4A and 4B (together) show a model of a seeder.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0017] An embodiment of the present invention includes multiple elements, which shall now be explained in detail. In this context, the different tasks, modes of operation and advantages of the abstraction layer as well as of the interface library are also described. The service-oriented communication or architecture of the system builds on this layer model of the interfaces.

[0018] According to the present invention, the abstraction layer and the interface library represent an expansion and improvement of existing layer models for communication: The abstraction layer with its APIs is oriented towards the layers of the conventional OSI model. Its implementation and that of the interface library is independent of the target HW. According to the understanding above, in this case, the individual components are able to be exchanged. Such an exchange requires only that the respective intermediate layers be exchanged correspondingly. For example, the message broker may be exchanged, while the remaining architecture—with the exception of the corresponding API of the abstraction layer—does not have to be changed.

[0019] In contrast to the OSI layer model, the communication in this case takes place “based on agreement”, so to speak, in that for each API, the fulfillment of non-functional requirements—for instance, the observance of a certain reaction time—is assured. The interface library has the task of validating this communication, since it requires the inclusion of computer-oriented aspects, e.g., with respect to ISOBUS or input/output (I/O).

[0020] In this context, abstraction layer (12) and interface library (14) represent layers of system (10), which for their part are made up of layers (see FIG. 1). The central element of interface library (14) in this case is a coordinator (15), which—beyond ISOBUS, e.g., in the case of machines with proprietary interfaces—connects concrete instances of generic machine models (see, e.g., FIG. 4 for the seeder model) via adapter modules (16 and 27) to I/O modules and other peripheral devices.

[0021] FIGS. 4A and 4B (together) show by way of example the software machine model of a seeder. The block “sowing machine” describes the generic functions of a seeder (outlet, rows, tank, seeder). The block “machine” describes the management data or operating data of the specific seeder (machine, seed, position). The block “management-data instance” is the instance of the management data or operating data and the generic functions. The instantiation is carried out by abstraction layer (12), and interface library (14) uses it. In addition, the management data or operating data are stored in the “database” (e.g., in the Cloud).

[0022] For example, these modules may be different in terms of the programming languages used or their syntactic depth. For this reason, interface library (14) provides equivalents to various interfaces of the OSI model, which reflect its different levels (1-7) (see FIG. 2).

[0023] In this context, components A to D shown in FIG. 2 represent, by way of example, different implementation depths corresponding to the levels of the OSI model. In this case, interface library (14) supplements the “missing” layers up to the service levels (level 7), in order to be able to offer abstraction layer (12) a generic interface. As shown, different implementation levels are supported. This is necessary, since peripheral devices of different manufacturers/type support different levels. For example, component A could correspond to the GPS driver in FIG. 1, component B could correspond to the socketCAN, component C could correspond to the ISOBUS and component D could correspond to an arbitrary I/O (e.g., temperature sensor).

[0024] All elements (21, 17, 23, 25) located in interface-library ISOBUS adapter (16) are likewise adapters. Interface-library basic-parts adapter (17) contains all interfaces that are mutual for all available ISOBUS stacks (22, 24, 26). The other adapters (21, 23, 25) are exemplary adapters for supplier-specific parts of the ISOBUS stack, which the suppliers bring along with them, for example. All adapters utilize a specifically created machine model to define the interface space of these adapters.

[0025] Comparable considerations underlie abstraction layer (12) (see FIG. 3). It permits the language-agnostic exchange of information between application programs (11) without platform dependencies, thus, for example, regardless of the implementation and performance of message broker (13) utilized. In addition, it is dynamically configurable and, in particular, allows expansion by new executable units or reconfiguration of an existing executable unit. Finally, it permits the monitoring and control of communication, e.g., with respect to the bandwidth demanded.

[0026] This is made possible on the part of application software (11) by an API, which conceals all the indicated implementation details from the developer. The connection to message broker (13) is accomplished with the aid of a further programming interface (30) of abstraction layer (12). Interface library (14) is also connected to message broker (13) via a corresponding programming interface (30).

[0027] A further characteristic of the present specific embodiment is the dynamic scalability of its interfaces. In this connection, their object-oriented modeling permits the adaptation to various machine sizes. For example, the machine models are scalable in this way: In the case of an agricultural sprayer, for instance, with respect to the working width and number of nozzles, in the case of a seed drill, with respect to the number of rows. To that end, the software platform defines abstract classes, from which concrete machine types are derived by implementation of the inherited access methods and definition of variables. At the same time, the object-oriented modeling supports a corresponding granularity in terms of the scope of performance of hardware and application software (11).

[0028] This detailed accuracy shall now be explained on the basis of an agricultural sprayer with section control. The machine model provides classes for sprayer, tank and section, where a sprayer may include multiple tanks, which on their part, might have multiple sections. In this case, the class “sprayer” defines methods for access to its attributes by the class type “tank”; the latter in turn defines methods for access to its attributes by the class type “section”. Finally, this class defines methods for opening and closing the nozzles. The object hierarchy described enables the modeled machine to respond to different levels with different granularity.

[0029] In this way, interface library (14) lends to system (10) of the present invention, a high degree of compatibility with a wide variety of machines. For instance, if application software (11) supports only the control of one section of an agricultural sprayer, but the latter has four differently controllable sections, interface library (14) allows the control of all sections. A dynamic adaptation at runtime is also possible: For example, if interface library (14) determines that new or more detailed machine interfaces are available on an add-on unit, a service-advertising mechanism sees to it that message broker (13) knows of the availability of these machine interfaces and the relevant drivers (28) are downloaded from the Cloud. Application software (11) is able to find and utilize the new interfaces via a discovery mechanism.

[0030] The runtime behavior opens up new possible uses for an electronic control unit according to the present invention. To that end, in a manifest data file, each application software (11) places certain minimum demands on the interfaces and resources of the machine controlled by it, which are stored in a central registry during the installation process of the container in question. However, so long as no corresponding machines are connected or are controlled at runtime, these interfaces remain abstract.

[0031] After the installation process, application software (11) and interface library (14) are connected for each individual API through an arbitration process. This combination ensures efficient management of the APIs. When the figurative “handshake” is complete, interface library (14) then adapts itself to application software (11), that is, concretizes the interfaces in accordance with pertaining notes in the registry. After that, a protocol which permits the meta-communication, but not the exchange of useful data, between application software (11) and interface library (14) is agreed upon. This meta-communication is used for the exchange of information which does not pertain directly to the control of actuators, drivers, etc., but rather their functional performance and quality of service (QoS).

[0032] After running through these steps, advertising, discovery, arbitration and monitoring of APIs and access to them are agreed upon, and afford application software (11) a communication that is reliable in terms of function, avoidance of bit errors, data integrity and data consistency.

[0033] The testability of application software (11) is also increased by the communication architecture above. Thus, for example, for the purpose of component tests, interface library (14) may be replaced by a mockup. To that end, a virtual machine class simulates a physical machine. In the extreme case, the entire application software (11) for a machine model may be developed and especially tested, without its developer having at its disposal a sample or even detailed knowledge of this machine.