FI115863B - System and method for handling data flow between application and communication bus in a computer controlled control system - Google Patents

Description

115863

System and method for processing data stream between application and communication bus in a computer controlled bypass system

BACKGROUND OF THE INVENTION 5

The invention relates to a method for processing a data stream between an application and a communication bus according to the preamble of claim 1 in a computer controlled control system.

The invention relates to a computer controlled control system according to the preamble of claim 10.

Industrial hardware and peripherals connected to computers, as well as remote control and control software that is closely related to them, make up an important part of the telecommunications market. A very common solution for controlling embedded systems is to provide separate PC-based software that communicates with the devices using a customer-selected data path.

20 The protocol used for communication may vary depending on the application area. The computer-controlled system offers significant advantages and: · “Cost savings through a slightly more complex user interface • # ♦ \. much easier and cheaper to do on a PC than on a * * controlled device itself. In addition, the controlled device can thus be physically located very far from the control center and several devices can be controlled; if desired, use the same software.

• «·

Whenever a brand new device is developed, the most common way is that the control -: '· *. * Software development process starts all over again. In addition, many companies want to use their own protocol to control their devices, the details of which are not disclosed to competitors. The message structures and the contents of the protocol packages can vary greatly, even between different products of the same vendor. This usually results in very little or no pre-existing code being used in new systems: * 35.

115863 2

Figure 1 shows a simplified model of how current control software works. In the figure, three different devices 1, 2 and 3 are connected to the control system 63, each using a different communication connection 4, 5 and 6. Communication and maintenance of data connection between the devices 1-5 3 and the application 7 takes place through the operating system and its communication services 8. The function of the operating system 8 is to convert the data to be transmitted into a physical data path 9-11.

It is noteworthy that for each different communication connection 4-6, an application program 7 has to have its own block 12-14, which can communicate with the operating system services 8. This solution is usually chosen because the interface provided by the operating system services 8 (communication protocols 15-17) may be very different when comparing different communication connections.

15

The interface is usually the so-called. API (Application Programming Interface). For example, using a serial port is completely different from a programmer's point of view than using a TCP / IP connection, not to mention that the hardware manufacturer wants to use a more exotic way of controlling the operating system, such as SMS (Short Message Service). If differences have not been sufficiently addressed already in the application design phase 7, the solution is * »·. it is also widely used to create a completely new application program for new communications.

25: Additional challenges in telecommunication applications also include the potential for retransmission of data packets, fluctuations in response times, error handling and data buffering. Thus, the product development cycle can be significantly shortened by using the system of the invention which solves these problems and further provides an interface that is independent of the communication connection or protocol used, remains constant for communication over the communication connection and thus minimizes the need for modification of the application.

35 Brief Description of the Invention

The method according to the invention is set forth in claim 1.

115863 3

The computer controlled control system according to the invention is set forth in claim 10.

5 The system component-based solution accelerates the development of industrial communication systems as hardware and computers communicate through a standard interface. The system is designed specifically for Windows® and provides an easy-to-use programming interface for telecommunications application developers.

10

A particular advantage of the invention is achieved in the system on the data receiving side. The client application can be provided with a fixed interface regardless of the data structure or the protocol used. This facilitates the programming of the communication part of the client application and its access, in particular, to the header and data fields contained in the data packet.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be explained in more detail using, by way of example, a preferred embodiment of the invention, with reference to the accompanying drawings, in which: "* * · * * f * Figure 1 is a block diagram of a prior art

t I I

control system and operation of control software, Figure 2 is a block diagram showing a control system and operation of control software according to a preferred embodiment of the invention,

* I

Fig. 3 is a signal diagram illustrating the opening of a communication connection. in the system shown in Figure 2,

t I

Fig. 4 shows as a signal diagram the transmission of data in the system according to Fig. 2, and Fig. 5 shows as a signal diagram the reception of data in the system according to Fig. 2.

35 4 115863

DETAILED DESCRIPTION OF THE INVENTION

The system of the invention consists of program components implemented in the following example using COM technology developed by Microsoft Corporation. The COM (Component Object Model) technology and its advantages have been described e.g. EP-A-0 778 688 A2, as well as in the literature. The invention can also be implemented using COMBA-10 components (Common Object Request Broker Architecture) or object-oriented programming instead of COM technology. Implementation of the system using these other methods will be apparent to one skilled in the art from this disclosure. The advantage is that COM technology is more commonly used than CORBA technology and, compared to object-oriented methods, COM technology provides easier code reuse and support for more programming languages. Nor is the system dependent on the operating system.

The different components of the system are shown in Figure 2. The system is called * 20 called GXCom. The data received and transmitted by the application program 18 is packaged in components 19-21, each called a GXPacket component. Adding or reading data. The GXPacket component 19-21 can be easily accessed using the methods found at component interface 22. GXPacket Component 19-21 • ·: ”25 ensures that the protocol used by application program 18 does not: .v affect the implementation of any other GXCom system. Thus, the GXCom system does not know the protocol used by the client (i.e. application 18), but processes all the data as GXPacket components 19-21. This also allows the application program interface 18 to 37 systems to remain unchanged even if the protocol changes. The GXCom system generates one or more GXPacket components during a 19-21 run. application program 18 requests.

The so-called GXCIient component 23 provides the application program 18 with an interface 35 to 37 systems. Creating, sending and receiving packages 19-21: f; as well as the system settings are all done by this com! ·! : via component 23. Each client application 18 can thus create its own »» 115863 5 instance lightweight GXCIient component. As an example, another GXCIient component 24 and an application 25 have been used. Of the GXServer component 26, there is only one instance in the computer memory to which the system 31 with the program components 5 is implemented. This is important eg. because the GXServer component 26 is able to provide a centralized efficient allocation of resources e.g. 18, 25 between different applications. For example, the implementation allows two client applications to communicate with the same communication media at the same time.

10

For example, in some known operating systems, operation is limited so that only one application at a time can be reserved for the serial port. With GXCom, the serial port can be centrally reserved by the system for use by all application programs, and not done by each of the 15 application programs. The client 18, 25 may also, if it so desires, by means of the system settings, separately specify that the serial port may not be used as the application alone, if it is desired to ensure sufficient communication capacity.

20 The core of the system is the GXServer component 26. Its main function is to receive the GXPacket components 19-21 transmitted by the GXCIient component 23, and retrieve the client inside them. input data and forward the data as a byte string to the media components 27-30, which take care of transmitting the data to the operating system- * ·; "25 with the assistance of 8 services to the physical communication bus (4-6 and physical communication 9-11, respectively).

At reception, the GXServer component 26 is able to convert data from slides 27 - 30 of me - "*** · to GXPacket components 19 r '": - 21 due to the parameters set to it. At reception, packets 19-21 are forwarded to GXCIient component 23, which forwards them to the client application 18.

The function of the media components 27-30 in the transmission case is to transmit the data stream provided by the v: GXServer component 26 to the physical bearer, whereby it utilizes the operating system services 8, and in the receiving case: f to convert the data from the operating system services 8 into a data stream. . For conversion, each media component 27 to 30 contains 115863 6 so-called. Properties method, which allows communication-specific parameters to be modified directly from the client 18. The GXServer component 26 forwards the connection directly to the client-5 application 18 when establishing a connection between the media component 27-30 of the connection mode. For example, when establishing a serial port the baud rate used in the traffic and the number of data bits. The data stream consists of bit-like information that can be divided into bytes for processing the information they contain 10

Figure 3 illustrates in more detail how the client application 18 opens a communication connection. The communication medium is set to serial port connection 28 in this example, but other connections are established in the same way only when the communication parameters vary.

15

Initially, the client application 18 calls the GXCIient component 23 so-called. SelectMedia method 32, for which the desired connection type is given as a parameter. The connection type used in the example case is COM1 (Select-Media (COMI)), which means that you want to use serial port 20 number one. A number of different connection types are defined in the system, each of which is represented by a particular media component 27 to 30. The so-called serial port connection types correspond to each other. The GXSerial media component 28, while there is a so-called TCP / IP connection. GXTCPIP Media Component 29. Media components and new connection types can be easily added «25 • into the system later, according to customer requirements.

v: This is made possible by having identical interfaces 33 - 36 on all media components. This minimizes the need for changes to other system components caused by the addition of a new me - "*: slide component. Client applications 18, 25 may ask for connection types supported by the current version of The GXCIient component 23, 24 uses the methods found in interface 37, 38. The system's ··· architecture not only offers extensibility, but also allows different client '·' groups to be provided with different installation packages containing the 27 - 30 formats support for different connection types.

C, -35; After calling the SelectMedia method 32, the GXCIient Communicator component 23 forwards a media component creation request 39 to component 26 (GetMedia (COMI)) of GXServers 115863 7. The function of the GXServer component 26 is to create (step 40) the actual media component, in this case the GXSerial component 28, and return the pointer (step 41) to its interface 34 to the GXCIient component 23, which in turn forwards (step 5 42) to the client application 18. via the interface pointer of the media component 23, the client application 18 is able to set (step 43) the required settings for the connection type using the Properties method found in each of the media components 27 to 30. The method is implemented without giving any parameters; allows you to set and save connection type settings to the media component. This solution has been chosen because each media component has a different, sometimes large, set of settings. The solution also allows the media component interfaces to be kept identical in terms of parameters, so as to minimize the number of client application changes needed when a new connection type is added to the system later.

When the desired settings for the connection type are set, the client application 18 calls the so-called. AssignMedia method 44, which allows GXServer component 20 component 26 to create a copy of the media component 28 (AssignMedia (GXSerial) itself) (steps 45 and 46) for connection and data transfer. The implementation is arranged so that after the method is called, edit without first closing all connections through the media # 28 · component 28. This ensures that “• 25 only one application can access the communication settings and no other application can modify it while the connection is running, when multiple clients are running one at a time. : * ·: The connection is finally closed using the so-called Close method of GXCIient 23.

i · · * · I · t · 30 When data is transmitted over a communication connection, the system converts the data packets to the format required by the communication connection and takes care of the data, ···, buffering, retransmissions, and error reporting. The client application 18 can manage all of these tasks with the settings of the GXCIient component i i * 1 23.

035: X Figure 4 outlines the transmission of one data packet '•' I through the system. Initially, application program 18 sets the settings required for transmission t <1 »t 115863 8 to the GXCIient component 47. The number of retransmissions and the waiting time for a response before retransmission are the basic settings for controlling the retransmission mechanism. If there is no reply to the packet at speed 5, the transmission will be automatically resumed if one or more retransmissions are set. If no response is received and all retransmissions have been used, the GXCIient component 23 informs the client of the error by sending a so-called. Event-message.

10 The GXCom system itself cannot identify which of the received packets is the answer to any sent packet or is incorrect because this functionality would require knowledge of the protocol used by the client 18. The issue is resolved in GXCom by transmitting all response packets to the client application with 18 Event messages. The client application 18 can determine in the event message return parameters whether it is a response packet or an error message and the system utilizes this information to determine whether a retransmission is to be performed.

20 Other settings that the client application 18 can use include: automatic checksum calculation for outgoing packets, use:.; j 'byte order and maximum size of send and receive buffers! * · .., and possible beginning and end of packet. The start and end characters are appended to the beginning and end of each packet transmitted ....: 25 while being converted to outgoing byte streams for the media component 28. The start and end characters are used in some protocols to identify packet -... boundaries in reception situations. For settings that are not set from the client 18, default values are used.

\ ': 30 The GXCIient-23 and GXPacket components 19 also have some of the same settings. The idea is that the GXCIient component has 23 settings; · | ·; is used for sending all packages, but the client application 18 ···. may choose to send a single packet with different transmission settings. Thus, the configuration of the package overrides the configuration of the GXCIient 23. : ··: 35 This allows the application program 18 to easily send multiple packets which, for example, are retransmitted five times in the event of an error, but also, for example, one packet which is not re-retransmitted even if a transmission error occurs. If settings are not set for the GXCIient component 23, then the client application 18 will have to set them individually for each GXPacket component 19 if the default settings are not comfortable. GXCIient 23 copies (step 5 48) all the settings it receives directly to the GXServer component 26, which actually takes care of retransmission and packet buffering.

When the GXCIient component 23 is configured correctly, the client 10 application 18 generates (step 49) the GXPacket component 19 while providing a pointer to the interface of that packet. Through the interface, the client application 18 can set the packet-specific settings already described in the previous paragraph. In addition, packet component 19 is filled with data contained in the header and data fields (step 50). Both fields 15 (packet header field and data field) have their own methods by which the transmitted byte string can be transmitted to the packet component 19.

Once the information required by the GXPacket component 19 is completed, the client application 18 can send the packet pointer to the GXCIient component 23 20s. 51 of the Send method (Send ()). The GXCIient component 23 copies the transmission settings to the packet and forwards (step 52) the packet to the GXServer component 26. The function of the GXServer component 26 is to store the packet component in buffer 53 to wait for transmission (step 54). The function of the GXServer component in the transmission is to collect ....: 25 the header and data to be transmitted from the packet component 19 and to transmit it to the media component 28 in byte stream. The GXServer component 26 also ... takes care of any retransmission, and monitors the stage at which the packet transmission is abandoned in the event of an error.

The media component 28 takes the incoming byte stream from the GXServer component 26 and forwards it to the operating system service controlling the data connection in question (service 8 according to Figure 2), which takes care of it. transmission of data to a physical transmission path (transmission path 9, / ”* 10 or 11 according to Figure 1).

: 35

Next, consider the system from the data receiving side. Figure 5 illustrates the reception of a single packet.

115863 10

In the reception situation, it is desired to transmit the same GXPacket components 19-21 to the client 18 instead of the byte stream as it does when sending. Because the interface 22 of the GXPacket component 19-21 is fixedly defined, the client application 18 can be provided with a fixed interface regardless of the byte stream structure or the protocol used. This facilitates the programming of the 18 communication sections of the client application. The packet component 19-21 forms a logical entity and allows easy access to the header and data fields contained in the packet.

10

In order to form packet components 19-21 from the incoming data stream, the client application 18 must describe the protocol it uses for the GXServer component 26, since its function is to assemble the GXPacket components 19-21 from the incoming data stream. The GXServer com-15 component 26 has at least four parameters for this purpose: BOP (Beginning of packet), EOP (End of packet), HeaderLength (header field field length) and DataLength (data field length). These parameters can be set (step 55 in Figure 5), either all or just a suitable portion. Below are 20 listed protocol protocols A to I that the system can recognize and the settings it requires. It is noteworthy that in the examples. greatly simplifies the structure of the packet components to be formed. In practice, however, the server component 26 always generates a GXPacket COM component, such as component 19, whose header information can be called by the so-called packet component interface. ExtractHeader method and data information in the so-called. ExtractData-method.

'* ··' Protocol Variation A1: The packets are identified by the BOP only. For example, suppose the GXServer component - ': ": 30 tells 26 that the start character is a byte FF and the GXServer receives a data string FF E1 02 FF AA C3 C5 FF 00. With the start character, GXServer detects that it has received three packets: E1 02 , AA C3 C5 ··· and 00. If the length of the header field is not defined,

»I

'·' Matches bytes in the data field of the packet.

= /: 35

Protocol Variation A2: The packets are identified by a data packet start character (BOP), and a header field length (HeaderLength) is also specified.

115863 11 This also allows the data to be divided into header and data fields. If in the example of the previous paragraph A1 the header field length was one byte, the received packets would look like E1 / 02, AA / C3 C5, and 00 /, with 5 characters being used here to separate the header and data fields of each packet.

Protocol Variation A3: In addition to the start character (BOP), a packet end character (EOP) is specified. The variation is practically no different from the example in A1. If, for example, the byte CC was used as the end character 10 in the incoming data for Example A1, it would look like this: FF E1 02 CC FF AA C3 C5 CC FF 00 CC.

Protocol Variation A4: EOP only is defined. Practically like Example A1, but the packets are identified by the ending character instead of the initial 15.

Protocol Variation A5: End character (EOP) and header field length (HeaderLength) are defined. In practice, this variation E is like Example A2.

20

Protocol Variation B1: Only the DataLength is specified. In this case, all incoming data is assumed to belong to its data field. For example, if the data field length is set to three bytes and; y: the following data is received: 01 02 03 04 05 06 07 08 09, then GXServer 26 is able to compile three packets (01 02 03, 04 05 06 and 07 08 09).

Protocol Variation B2: additionally defined header field length (HeaderLength). In this case, it is desired to place some of the data in the header field. If: 30 is retrieved from Example B1 and is defined as a header field length of one byte and a data field length of two bytes, then - ;: ·. these packages would look like 01/02/03, 04/05/06 and 07/08/08,. · ·. where the header and data parts are separated by /.

• ·: ·:: 35 Protocol Variation B3: HeaderLength is:. ·· specified. Like Example B1, but all incoming data is placed in the header field of the packet being generated.

12 1 1 5863

Protocol Variation C1: Only the Header-Length is defined, plus the location where the data field length is calculated from the beginning of the header field and how long the field indicating length 5 is. For example, data 00 00 01 AA EF 00 02 AA BB is received. The header field is set to three bytes in length, and it is further specified that the length of the data field is found in the second byte from the beginning, and the length field measures two bytes. Now GXServer will extract data from scratch. The first three syllables, 00 00 01 cat-10, are warfare as a header field. The length of the data field is represented by the second and third bytes, i.e. the length of the data field is 00 01 bytes, i.e. one byte. Byte AA is provided in the data field. By the same logic, the server component decodes the next packet into the form EF 00 02 / AA BB.

Thus, with these rules, the GXServer component 26 is able to create (step 57) from the incoming byte stream 56 COM (GXPacket components) components having standard interfaces. The components created by the server 26 are passed (step 58) to the GXCIient component 23, which asks for a so-called. The Is-ReplyPacket-event method 59 (IsReplyPacketO) client applications 18 determines whether the received packet component is a response packet to any previously transmitted packet. If so, the client application 18:>; j · tells which packet the received packet component is the response to, and the GXCIient 23 sends to the GXServer component 26 the message that the transmission was successful, so that the packet to which the response came does not need to be sent. - ....: 25 again, but can be removed from the server's 26 send buffers ..... In this case, GXCIient 23 next asks IsReplyOK- * · ... event method what is the status of the response packet (step 60). If a pre-*** · 'character is sent as a command that should write something to the receiving device's memory, the response packet may contain information that reads: "; 30 whether the write was successful or failed despite the command being received. If a negative response is given to the IsReplyOK method, the server may still try retransmission or issue. ···. the cash register can handle the error handling itself. If the received packet was not a response to any previously transmitted packet (negative: ·: -; 35 responses to the IsReplyPacket method), as illustrated in Figure 5, the server 26 forwards the packet to the client application 18. Received-event method (ReceivedQ, steps 61 and 62).

115863 13

The invention is not limited to the above embodiment, but can be modified within the scope of the appended claims. The Execution Environment may be various computer devices with an Operating System intended to run applications and software systems, in particular a personal computer (PC) or a workstation operating therein, comprising a suitable operating system. The hardware and operating system have 10 necessary applications and protocol tools to communicate with other devices. The operating system is preferably a ready-made system according to the prior art, which provides ready-made services for the transmission of data stream data.

15

Claims (14)

14 1 1 5863 A method for processing a data stream between an application (18, 25) and a communication bus (4, 5, 6, 9, 10, 11) in a computer-controlled control system (31), characterized in that the method: compresses in the control system (31) reception and transmission the data stream to be transmitted in one connection to one or more packet components (19, 20, 21) which is standardized for different applications (18, 25) and independent of the selected telecommunication connection (4, 5, 6, 9, 10, 11), the packet component (19, 20, 21) comprising the necessary standardized programming interface (22) through which the data stream is read from or written to the packet component (19, 20, 21 21) by said application (18) is controlled by a standard programming interface operating system (8) comprising telecommunication services 20 for implementing one or more data streams eto traffic connection (4, 5, 6, 9, 10, 11) for the · ·. : * for communication between the control system of the sensing system (31) and one or more of the * *: '·· two controllable devices (1, 2, 3), ν': whereby said communication links (4, 5, 6, 9, 10, 11) *: **: The communication protocols used by 25 may also differ; converting, during transmission, a data stream read from said packet component (19, 20, 21) to a form available for the selected telecommunication connection ;; den (4, 5, 6, 9, 10, 11) according to the communication protocol and; while being dependent on said telecommunication connection (4, 5, 6, 9, 10,: 11), and supplying it to telecommunication services (8), v and '; ϊ 35, upon receiving, converting a data stream received from telecommunication services (8) and 115863 15 depend on the communication protocol (4, 5, 6, 9, 10, 11) selected for use, and write it to said packet component (19, 20, 21) via said standardized programming interface (22) and transmit it to the application (22). 18, 25), which interprets the information of the data stream. A method according to claim 1, characterized in that said packet components (19, 20, 21) 10 are formed from the data stream based on predetermined and stored unique values of said application (18) for parameters defining rules for dividing a continuous data stream into discrete packet components (19, 20, 21). , 21) and preferably also the internal structure of the packet component (19, 20, 21), in particular the header field and / or the data field. 15 The method of claim 2, characterized by determining, by means of said unique parameters, at least: an initial character in the data stream for the packet component; or the length of the packet component header field in bytes; or an end sign for a packet component found in the data stream; or the length of the data field of the packet component in bytes; information about where the header field is multiplied by the length of the data field; .i * or any combination of the above. : V: A method according to claim 1, characterized in that *: *: 25 sets the connection parameters of the selected telecommunication connection (4, 5, 6, 9, 10, 11) by one or more media commands (18, 25). via a component (27, 28, 29) comprising standardized programming interfaces (33, 34, 35) and selecting an application (18). , a unique media component (27, 30 28, 29) according to the connection type selected, which in turn calls the telecommunication services (8) to transmit the data stream * ·; · '. • I t Method according to claim 4, characterized in that Λ sets and stores the connection type parameters relating to the communication connection (4, 5, 6, 9, 10, 11) to the selected media component (27, 28, 29) of the application (18, 25). and a configuration dialog between the selected media component (27, 28, 29). 16 115863 Method according to one of Claims 1 to 5, characterized in that packet components (19, 20, 21) are created for transmission of the data stream of the application (18, 25) to each application (18, 25) via an individual client component (23, 24). , which client component comprises a standard programming interface (37, 38) through which the General settings for the packet components (19, 20, 21) of each application (18, 25) can be set and stored in an individual client component (23, 24), and If necessary, the 10 settings can be set for each packet component (19, 20, 21). Method according to claim 6, characterized in that packet components (19, 20, 21) are transmitted from each client component (23, 24) to a server component (26), which centrally takes care of converting the packet components (19, 20, 21) to be transmitted and converting each data link (4, 5, 6, 9, 10, 11) to a data transmission protocol and converting the data stream to a packet component (19, 20, 21) for application (18, 25). 20 A method according to claim 6 or 7, characterized in that the client component (23, 24) is called from the application (18, 25) in connection with the transmission and the communication link (4, 5, 6, 9, 10, : V: 11) to open, whereby the desired connection type is defined in the call para ·: ··: 25 meters and return to the application (18) the pointer information for the ·: ··· programming interface (34, 35, 36) through which . · ·. meters are adjustable. :. Method according to one of Claims 1 to 9, characterized in that the resources of the communication links (4, 5, 6, 9, 10, 11) are distributed centrally between different applications (18, 25) via a server component (26) which is also centrally takes care of converting the packet components (19, 20, 21) into a data stream and vice versa. A computer-controlled control system comprising: 115863 17 - an operating environment for driving one or more control applications, - control means for handling a data stream between the application (18, 25) and the communication bus (4, 5, 5, 6, 9, 10, 11), characterized in that the control means comprise: - means for compressing the data stream 10 received and transmitted in one or more packet components (19, 20, 21) which is standardized for different applications (18, 25) and independent of the selected telecommunication connection (4, 5, 6, 9, 10, 11), wherein said packet component (19, 20, 21) comprises the required 15 standardized programming interface (22) through which the data stream can be read from or written to the packet component (19, 20, 21). 20, 21) by said application (18), wherein the control system further comprises: - operating system means (8) for establishing a communication bus (4, 5, 6, 9, 10, 11) between a control computer: a control system (31) and one or more controllable devices (1, 2, 3); and for transmitting a data stream, wherein the communication protocols used by said telecommunication connections (4, 5, 6, 9, 10, 11) may also differ and which operating system means are controlled by a standard programming interface; in addition: - means for controlling communication services via a standard programming interface and for transmitting data stream at reception and transmission, 115863 18 - means for reading the data stream from said packet component (19, 20, 21) to a format available for transmission. selected connection (4, 5, 6, 9, 10, 11) according to communication protocol 5 and dependent on said telecommunication connection (4, 5, 6, 9, 10, 11), and for supplying to telecommunication services (8), means for converting data stream 10 received from telecommunication services (8) upon reception, wherein the format of the data stream is dependent on the communication protocol of the selected communication link (4, 5, 6, 9, 10, 11) for writing the data stream to said packet component (19, 20, 21) via said standardized programming interface (22) 15 and for transmitting ( 18, 25) arranged to interpret the information in the data stream. A computer-controlled control system according to claim 10, characterized in that the control means are arranged to form said packet components (19, 20, 21) from the data stream of the earth based on predefined and stored by said application (18): which defines rules for dividing the image stream into separate packet components (19, 20, 25 21) and preferably also the internal boundary of the packet component (19, 20, 21): · | field, especially the header field and / or data field. The computer controlled control system of claim 11; method, characterized in that said unique parameters comprise at least the following information: an initial character in the data stream for a packet component; or the length of the packet component header field in bytes; or 0 ·: the end sign of the packet component found in the data stream; or the length of the data field of the packet component in bytes; information on where the header field is multiplied by the length of the data field; or a combination of the above. 1 1 5863 19 A computer program comprising program code means, characterized in that it is arranged to perform the steps of any one of claims 1 to 9 when said computer program is executed on a control computer. 5 A computer program product comprising program code means stored on computer readable media, characterized in that it is arranged to perform the steps of any one of claims 1 to 9 when said computer program is run on a control computer. 115863 20