Method of transmitting data

Abstract

Method of transmitting data in a distributed system of programmable controls, wherein data are transmitted between data sources and data sinks, both of which represent a respective node in the distributed system, and wherein the respective data sources and data sinks communicating with one another are determined by way of parameters.

Claims

1. A method of transmitting data in a distributed system of programmable controls, comprising the following steps: installing interconnected controls and sensors in a plurality of hardware to provide a plurality of units; each unit of the plurality of units forming a node of a plurality of nodes in the distributed system; determining by parameters data sources and data sinks to communicate with one another, wherein the data sources and the data sinks represent a respective node of the plurality of nodes in the distributed system, the respective node comprising a control program and standard functions, wherein communication functions are fixed program routines and fall back on a parameter file comprising the parameters; transmitting the data between the data sources and the data sinks; parameterizing the program routines for the communication functions; adapting the parameters independently of the control program while the control program is running; and exchanging a unit of the plurality of units during operation of the distributed system; wherein the control program is independent of the communication functions; and wherein the program routines are hardware independent and universally usable with different hardware.

2. The method according to claim 1, wherein the parameterization is carried out by way of an external configuration file.

3. The method according to claim 1, wherein start and destination addresses of the communication functions are parameterized.

4. The method according to claim 1, wherein protocols on which the communication functions are based are parameterized.

5. The method according to claim 1, wherein the program routines and hardware Application Program Interfaces (APIs) are virtualized.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The sole FIG. shows a flow chart of a preferred embodiment of the inventive method.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

(2) The invention is illustrated in the following by way of an embodiment.

(3) The invention is illustrated on the basis of control of a piste tracked vehicle, but is applicable to any control and regulating systems.

(4) Controls and sensors, which are interconnected by way of a bus system, are installed as units in the vehicle (see box 5 in the flow chart of the sole FIG.). In that case, each unit forms a network node.

(5) Nodes which detect and pass on data are thus data sources and those which receive and process data are data sinks.

(6) If, for example, motor rotational speed is now detected by a data source (see box 10 in the flow chart of the sole FIG.), then this is coded (see box 15 in the flow chart of the sole FIG.) and transmitted in a message (see box 20 in the flow chart of the sole FIG.). For that purpose, the program code gives the data source a command to transmit the data packet. Specific communication functions send the data packet to the data sink.

(7) The communication functions in that case fall back on a parameter file in which it is specified which data packet is to be transmitted by which protocol via which bus system to which data sink.

(8) This parameter file is in that case independent of the program code.

(9) The program code is executed, for example, in a runtime environment or a virtual machine and is thus independent of the hardware used. In that case, standardised runtime environments such as, for example, Java can be used. Abstraction between hardware-dependent routines and hardware-independent routines can also be undertaken so that the actual program code is hardware-independent and accesses hardware-dependent routines. This is particularly useful especially on embedded systems, since an operating system is usually not provided thereat.

(10) The communication functions provide a standardised interface for the program code, to which this can have access.

(11) The communication functions can be hardware-specific or, however, access the hardware and thus the physical interfaces by way of special hardware drivers.

(12) Equally, not only can the communication with other nodes be abstracted in such a way, but also it is conceivable for microcontrollerswhich evaluate sensors and thus serve as data sourcesto access sensors in the same mode and manner so that here, as well, hardware independence is achieved.

(13) The data sinks process the received data packets (see box 25 in the flow chart of the sole FIG.). In order to be able to receive these, the program code thereat similarly accesses communication functions, which receive the data packets and transfer to the program code.

(14) Here, too, the program code is hardware-independent, whereagainst the communication functions directly or indirectly access the hardware.

(15) Continuing with the example of a piste tracked vehicle: If the diesel engine is now exchanged for a hybrid unit then only the parameterisation of the control unit of the hybrid unit has to be appropriately parameterised so that rotational speed data can be represented on a display by an application running on a microcontroller.

(16) The microcontroller display in that case does not even notice that a different drive unit is installed, since its sole function is to display rotational speed data.

(17) Equally, it is conceivable for a Controller Area Network (CAN) bus system to be converted to Ethernet.

(18) For that purpose, the communication interfaces are exchanged and the parameterisation of the individual nodes appropriately adapted.

(19) The program code can be executed without change.

(20) Fresh evaluation and comprehensive tests are eliminated.

(21) In addition, the parameterisation can be changed in ongoing operation. This is not possible with conventional approaches in which the communication is filed directly in the program code.

(22) Rather, with everyeven smallchange the code had to be completely freshly compiled and tested.

(23) In addition, it is achieved with the approach according to the invention that the program code can be repeatedly used for the most diverse applications, in which case the reliability of apparatus and installations is increased due to longer and more extensive experience with the respective program code.