DATA TRANSFER PROCEDURES
Patent Information
- Application Number
- DE502016016821
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2015-10-21
- Filing Date
- 2016-10-20
- Publication Date
- 2024-12-19
- Estimated Expiration
- 2036-10-20
AI Technical Summary
Existing data transmission methods in distributed systems of programmable controllers require extensive code evaluations and tests for even minor changes, leading to increased costs and complexity, especially when replacing units or control units, as addressing must be manually adjusted within the program code.
Programmable controllers are designed as embedded systems without an operating system, with virtualized program routines and communication functions, allowing hardware-independent implementation and parameterization of communication protocols and addresses via external configuration files, enabling flexible and adaptable data transmission.
This approach eliminates the need for extensive code evaluations and testing, allowing for seamless hardware changes and increased flexibility, as program code remains unchanged with adaptable communication functions, enhancing reliability and reducing operational costs.
Description
[0001] The invention relates to a method for transmitting data in a distributed system of programmable controllers, wherein data is transferred between data sources and data sinks, each of which represents a node in the distributed system, and wherein the respective communicating data sources and data sinks are determined by parameters.
[0002] Such control systems communicate with each other via a network, fieldbus, or similar.
[0003] The program routines define which data should be sent from one control unit to another or received from another.
[0004] The addressing of the other control unit is also stored in the program routines.
[0005] This is highly problematic, however, because even minor changes, such as replacing a component or control unit, require this adjustment to be made in the program code each time. At best, the addressing can be determined via parameters.
[0006] This means that the entire program code must be subjected to evaluation and various tests each time to ensure that malfunctions are at least largely excluded.
[0007] For example, US2015 / 0100774 A1 describes such a system, which can be parameterized via configuration files.
[0008] From DE 11 2012 005 116 T2, another system is known which enables automatic management of configuration information.
[0009] From DE 10 2006 006 250 A1, an information processing system with virtual machines and a method for centralized software management is known.
[0010] The object of the invention is to propose a method which makes it possible to do without these costly evaluations and tests, which also cause considerable expenses.
[0011] This problem is solved according to the invention by implementing programmable controllers as embedded systems that do not have an operating system, and by virtualizing the program routines, communication functions, and hardware APIs, and by implementing the program routines, communication functions, and protocols in a hardware-independent manner.
[0012] This achieves a high degree of hardware independence. The program routines become universally applicable and can run on various hardware. For example, a connected vehicle can be equipped with a hybrid drive instead of a diesel engine. Each drive system has a specific control unit that exchanges standardized data with other control units.
[0013] This allows the network of data sources and data sinks to be defined via parameters, independent of the underlying program routines.
[0014] It has proven to be very advantageous if each node is equipped with a control program and standard functions.
[0015] This allows the control program to be decoupled from standard functions that the control program can access.
[0016] In this context, it is also extremely advantageous if the communication functions are stored as fixed program routines.
[0017] This allows the control program access to communication functions.
[0018] According to a further embodiment of the invention, it is very advantageous if the program routines for the communication functions are parameterizable.
[0019] This allows access to the communication functions to be adjusted via parameters.
[0020] It is also extremely advantageous if the parameterization is done via an external configuration file.
[0021] This allows the parameters to be adjusted independently of the tax program. It is even conceivable to adjust them while the tax program is running.
[0022] According to a further embodiment of the invention, it is extremely advantageous if the start and destination addresses of the communication functions are configurable.
[0023] This ensures a very high degree of flexibility. Components can easily be replaced, if necessary, even during operation.
[0024] Furthermore, it is very advantageous if the protocols underlying the communication functions are configurable.
[0025] This means that the individual modules, or at least program routines, can be used for a wide variety of applications and can be based on, for example, fieldbus, Ethernet or the like.
[0026] The invention is illustrated below using an exemplary embodiment.
[0027] The invention is illustrated using the control system of a snow groomer, but is transferable to any control and regulation systems.
[0028] In the vehicle, the control units and sensors are built as individual units that are interconnected via a bus system. Each unit forms a network node.
[0029] Nodes that collect and transmit data are data sources, while those that receive and process data are data sinks.
[0030] If, for example, the engine speed is recorded by a data source, this information is encoded in a message and sent. The program code of the data source gives the command to send the data packet. Special communication functions then send the data packet to the data sink.
[0031] The communication functions access a parameter file that specifies which data packet should be sent to which data sink via which bus system using which protocol.
[0032] This parameter file is independent of the program code.
[0033] The program code is executed, for example, in a runtime environment or a virtual machine, and is therefore independent of the hardware used. Standardized runtime environments such as Java can be used. An abstraction between hardware-dependent and hardware-independent routines can also be implemented, so that the actual program code is hardware-independent and accesses hardware-dependent routines. This is particularly useful on embedded systems, as an operating system is generally not provided there.
[0034] The communication functions provide a standardized interface for the program code, which it can access.
[0035] The communication functions can be hardware-specific, or they can access the hardware and thus the physical interfaces via special hardware drivers.
[0036] Similarly, not only can communication with other nodes be abstracted in this way, but it is also conceivable that microcontrollers, which evaluate sensors and thus serve as data sources, access the sensors in the same way, so that hardware independence is also achieved here.
[0037] The data sinks process the received data packets. In order to receive these, the program code there also accesses communication functions that receive the data packets and pass them on to the program code.
[0038] Here too, the program code is hardware-independent, whereas the communication functions access the hardware directly or indirectly.
[0039] To stick with the example of the snow groomer: If the diesel engine is replaced with a hybrid unit, only the parameterization of the hybrid unit's control unit needs to be adjusted accordingly so that speed information can be sent to a display, which can be shown by an app running on a microcontroller.
[0040] The display microcontroller doesn't even "notice" that a different drive unit is installed, as its sole purpose is to display the speed information.
[0041] It is also conceivable that a CAN bus system could be converted to Ethernet.
[0042] For this purpose, the communication interfaces are exchanged and the parameterization of the individual nodes is adjusted accordingly.
[0043] The program code can be adopted unchanged.
[0044] A re-evaluation and extensive testing are not required.
[0045] The parameters can also be changed during operation. This is not possible with conventional approaches where the communication is directly embedded in the program code.
[0046] Instead, every single change, no matter how small, requires the entire code to be recompiled and tested.
[0047] The inventive approach also achieves the fact that program code can often be used for a wide variety of applications, thereby increasing the reliability of devices and systems due to long and extensive experience with the respective program code.
Claims
1. Method for transmitting data in a distributed system of programmable controllers, whereby data is transmitted between data sources and data sinks, each of which represents a node in the distributed system, whereby the data sources and data sinks communicating with each other are determined via parameters, characterized in that programmable controllers are designed as embedded systems that do not have an operating system and that the program routines, communication functions, hardware APIs are virtualized and that the program routines, communication functions and protocols are designed to be hardware-independent, whereby an abstraction is made between hardware-dependent and hardware-independent routines.
2. Method according to claim 1, characterized in that the nodes are each equipped with a control program and standard functions.
3. Method according to claim 1 or 2, characterized in that the communication functions are stored as fixed program routines.
4. Method according to claim 3, characterized in that the program routines for the communication functions can be parameterized.
5. Method according to claim 4, characterized in that the parameterization takes place via an external configuration file.
6. Method according to one of the preceding claims, characterized in that the start and destination addresses of the communication functions can be parameterized.
7. Method according to one of the preceding claims, characterized in that the protocols underlying the communication functions can be parameterized.
