WO2009106681A1

WO2009106681A1 - Administration of distributed data systems

Info

Publication number: WO2009106681A1
Application number: PCT/FI2009/050117
Authority: WO
Inventors: Pasi PÖRI; Sami Hartikainen; Harri Jokela
Original assignee: Teleste Oyj
Priority date: 2008-02-29
Filing date: 2009-02-13
Publication date: 2009-09-03
Also published as: EP2250788A1; FI20085188A0; EP2250788A4; FI20085188L

Abstract

A method for administering variables of a distributed data system and a headed system of a cable television network, which system comprises several data processors connected to each other via a communication bus, which data processors comprises applications arranged to communicate with each other. In the method, the variables of the applications are defined as data elements, which data element is a key/value pair, where the key defines the location of the data element in the data system and the value defines the current value of the data element; a specific keyscope is registered for each application, which keyscope defines the initial part of the key, and a channel address for the application, which defines the location of the application in the communication bus so that the channel address can be established on the basis of said keyscope; at least one data element in a second application is called from the first application at least on the basis of the key of the data element, and the call is directed in the communication bus to the second application on the basis of the key of the data element and the channel address of the application.

Description

ADMINISTRATION OF DISTRIBUTED DATA SYSTEMS

Field of the invention

The invention relates to administration of distributed data systems, specifically headend systems of a cable television network. Background of the invention

Cable television networks may be implemented by various techniques and network topologies, currently mostly as so-called HFC networks (Hybrid Fiber Coax), i.e. as combinations of a fibre network and a coaxial cable network, but when considering future network solutions the cable television operators must also take into account the rapid development of IP-based (Internet Protocol) networks and services, for example the so-called IP television. However, irrespective of the implementation method of the distribution network, the implementation of a cable television network requires the implementation of a headend system.

The function of the headend is to receive program services from different sources, if necessary to convert them into a format suitable for the distribution network, and to adapt them to be transmitted typically in multiplexed channel bundles. The headend of a digital cable television networks must advantageously be able to receive program services in a digital satellite (DVB-S), terrestrial (DVB-T), cable (DVB-C) and asynchronic (DVB-ASI) format. Further, it must be able to receive analog program services, which must be converted into digital form by means of a suitable encoder. Further, one or more Video-On-Demand servers (VOD) may operate as a program source. All these program sources must therefore be able to be adapted in the headend system to a format suitable for the distribution network, typically either the DVB-C or DVB-ASI format.

As becomes obvious from what is disclosed above, the headend systems are typically complex, large systems composed of several separate devices, and their administration and usage is laborious and requires versatile skills from those performing those tasks. Often there are separate devices or units for each input/output interface, which may be provided by different manufactures and each one typically has their own user interface. In addition, the operating system software of some devices is updated often, while devices with older technology may not necessarily be updated at all any longer.

All this makes the centralized administration of headend systems very complex. Previously the aim has been to solve this problem by cable- television-operator-specifically customized software assemblies, which provide middleware that facilitates usage. The purpose of middleware is to hide the different user interfaces and usages of the devices behind a common administration interface and to aim to provide the user with a view of the entire system level. Middleware are expensive investments because of large amounts of development work and costs for continuous maintenance.

Especially compatibility problems due to generation/software updates of products cause big problems. The function interfaces and message structures are application-specifically individual, in which case even a small change may cause a loss of compatibility, which is avoided by tying the communication applications and their versions tightly together. In addition, each application must know exactly what services are provided in a specific application. Thus, each application should know substantially all data types, their interfaces and/or type-specific extensions of other applications, which is in practice impossible.

In addition, communication between applications in a distributed system, where the applications are located, for example, in different devices connected by a data communication network, requires specific planning and a great deal of error-prone control of settings. According to prior art, the system in practice becomes so static, that it does not allow the removal or addition of an individual device, or even changing (network) settings, such as IP addresses.

Brief summary of the invention Now, an improved arrangement has been developed to reduce the above-mentioned problems. As different aspects of the invention, we present a method and a headend system, which are characterized in what will be presented in the independent claims.

The dependent claims disclose advantageous embodiments of the invention.

The invention is based on the idea that in a distributed data system, such as a headend system of a cable television network, which comprises several data processors connected to each other via a communication bus, which data processors comprise at least one application, which applications are arranged to communication with each other, the variables of said applications are defined as data elements, which data element is a key/value -pair, where the key defines the location of the data element in the communication system and the value defines the current value of the data element; a specific keyscope is registered for each said application, which defines the initial part of said key, and a channel address of the application, which defines the location of the application in the communication bus so that the channel address can be resolved on the basis of said keyscope; at least one data element in a second application is called from a first application on the basis of at least one key of the data element; and the call is directed in the communication bus to said second application on the basis of the key of the data element and the channel address of the application.

In other words, the invention describes a uniform communication method between applications, where changes in the communication interface or message structure of an individual application do not cause a change in the communication mechanism itself and therefore do not automatically require changing and updating client applications. In the method the applications communicate by sending and receiving data elements (key/value-pairs), which are relayed between the communicating applications without the applications in question knowing each other in depth.

According to an embodiment, in said application an address of an application is received as a response to the application initializing a communication channel in a communication bus; and a specific keyscope and application channel address in a keyscope register are registered for said application.

According to an embodiment, a get operation is determined for said calls, with which the application making the call requests the receiving application to send as a response the current value of at least one data element defined in the call; and a set operation, with which the application making the call notifies the receiving application a new value for the at least one data element defined in the call.

According to an embodiment ,in the key/value-pair of the data element the key is a character string of an unlimited length, and the value is one of the following allowed data types: signed/unsigned 32/64-bit integral number, floating point number, ASCIIZ character string, or a byte string without a data type.

According to an embodiment the services offered by said data processors is notified to a distributed administration server by means of service notification messages; the device keyscope and a corresponding channel address notified in the service notification message is stored in a device keyscope register covering the system; and the services provided by a specific data processor are notified by means of service notification messages to the other data processors of the system from the distributed administration server.

According to an embodiment, the device keyscope and the corresponding channel address notified in the service notification message are stored for a predetermined time in the device keyscope register covering the system; and as a response the not receiving a new service notification message within said predetermined time, said device keyscope is removed from said device keyscope register.

According to an embodiment, as a response to the call made by said first application on the basis of the data element key of the second application, the call is directed to a device-specific relay mechanism; a search in a data specific table of the keyscope register is performed on the basis of said key of the data element; as a response to not finding said data element key from the device-specific table of the keyscope register, a search is performed in the device keyscope register covering the system on the basis of said data element key; as a response to finding said data element key in the device keyscope register covering the system, a device keyscope corresponding to said second application and the channel address of the device are sent to the device-specific relay mechanism; and the call is directed from the device-specific relay mechanism in the communication bus to said device comprising the second application on the basis of said device keyscope and the channel address of the device.

By means of the method according to the invention and its various embodiments it is possible to attain significant advantages. By means of them it is possible to implement a distributed application environment, where data on the services provided by the device is communicated to the other devices of the network, and data on the services provided by the other devices of the network is received. In addition, the received service data is offered to the communication mechanism, which, if necessary, directs traffic over the network without the communicating applications having to separately prepare for the situation. By defining the variables of the applications as key/value- pair-type data elements, the applications do not need to be aware of the location of the data elements; it is enough that they know the key of the data element in question. This uniform administration of data positions enables the direct access of an application to the original data position of a data element of another application, which enables fast data relaying and the multiformity of the data types does not limit the data transfer at all.

This is especially advantageous in the headend systems of the cable television network, which typically comprise several separate devices, which are even supplied by different manufacturers and each of which may comprise their own user interface and even an operating system.

As a second aspect of the invention is therefore disclosed a headend system of a cable television network, where the method according to the invention can be applied. The other aspects, embodiments and advantages will be presented later in the detailed description of the invention.

Brief description of the drawings The invention will now be described in more detail in connection with preferred embodiments with reference to the appended drawings, in which:

Fig. 1 shows in a reduced block chart an example of an integrated headed device, where the communication procedure according to the invention can be applied;

Fig. 2 shows in a reduced view the basic functionality of the communication mechanism according to the invention;

Fig. 3 shows in a reduced view the registration according to an embodiment of a keyscope of the application in a key register;

Fig. 4 shows in a reduced view the establishment according to an embodiment of a value of a data element published by the application on the basis of a key;

Fig. 5 shows in a reduced view a distributed system according to an embodiment, which system is composed of several devices connected to each other via a data communication network;

Fig. 6 shows in a reduced view a procedure according to an embodiment for notifying the services provided by a device to other device of the system; and

Fig. 7 shows in a reduced view a procedure according to an embodiment for communication between applications, when the applications are located in different devices. Detailed description of the invention

Figure 1 shows by a reduced block chart an example of an integrated headend apparatus, where the communication procedure according to the invention may advantageously be applied. The purpose of figure 1 is to illustrate the operation of a headend apparatus on a general level by using some most typical modules as examples, and therefore figure 1 does not show all the functional blocks that are adaptable to a headend apparatus.

In figure 1 the headend apparatus according to an aspect of the invention is shown physically integrated to the same apparatus assembly, for example a case. Even though this kind of physical integration is an advantageous embodiment, which facilitates the concrete administration and maintenance of the apparatus, it is not essential to the functionality of the invention. In other words, the invention can similarly be implemented by using one or more modules outside the apparatus case, which modules are, however, functionally connected in a manner required by the invention. Thus, the headend apparatus according to figure 1 can on a general level be understood as a distributed system, whose separate modules are managed through a common communication mechanism.

The integrated headend apparatus 100 according to figure 1 comprises a main module 102 and at least one, but advantageously several, for example 4 to 8, interface modules 104. Each of such modules can be interpreted to correspond to a separate device according to prior art, as a part of the headend system. In addition, the headend apparatus 100 according to figure 1 comprises a power source module 106 and at least one, typically several fan modules 108.

The main module 102 is responsible for the administration and synchronization of the headend apparatus and all the modules connected to it. The main module 102 comprises a central processing unit (CPU), memory (MEM) and interfaces to other modules and the user interface (Ul) 110 of the apparatus. The main module administrates all the data transfer taking place in the headend apparatus, comprising both the administration of incoming/outgoing program service streams of interface modules 104 and the processing of the internal control data of the apparatus. The main module also controls the power input from the power source module 106 to other modules. In addition, the main module advantageously comprises an internal Ethernet switch 112, which enables the processing of program service streams on IP level and sending and receiving program service streams as IP-based, either as Single Program Transport Stream (SPTS) or as Multi Program Transport Stream (MPTS) in an Ethernet network, in which an Ethernet interface module 114 is used for sending and receiving program service streams.

The operating system controlling the main module and the operation of the entire apparatus is stored in the memory (MEM). The memory (MEM) comprises a read memory portion, which can be for example a ROM memory and a random access memory which can be composed of a RAM memory and/or a FLASH memory. The information obtained from the different modules of the apparatus is relayed via the memory to the central processing unit (CPU), which comprises one or more processors and which processes the obtained information in a manner controlled by the operating system.

The interface modules 104 are connected to the main module 102 for the part of their program service stream on the IP interface of the link layer plane of the Ethernet, which IP interface has its own IP address and a network mask configured via the user interface. The IP packets can be relayed as such to other interface modules.

A substantial part of the above-described cooperation between modules is a solution, where the basic functionality of each module is implemented in the same generic manner. The basic functionality comprises advantageously at least an operating system, common program functions for all modules, a uniform administration of data positions and a universal communication mechanism.

According to figure 2 the basic functionality is implemented as an integrated core program (CORE), which can be taken into use in products connected to the system. The core program is delivered in a separate software packet in binary form, which packet can be adapted to operate in different HW environments. Figure 2 shows, as an example, several applications (APPLICATION (1), (2), ..., (n); 202, 204, 206), which can be used in one or more separate devices or modules belonging to a headend apparatus. For each application has been adapted a separate core software unit (CORE (1), (2) (n);

208, 210, 212), via which each application has access to any data element (DATA (1 ), (2), ..., (n); 214, 216, 218) in different applications of the headend apparatus.

The core software packet CORE offers to the application software of the product several services of general use, which are characteristic to all the products of the system. The communication mechanism of general use, which can also be called DXI (Data Exchange Interface) in short, is designed to avoid the drawbacks of conventional IPC- techniques (InterProcess Communication).

The generally known IPC techniques can be divided into two basic types: 1) communication between two points (P2P, point-to-point) by using application-specific function interfaces that are determined separately for each functionality; and 2) bus-type message relay mechanism with application-specific message structures. Conventionally the weakness of these techniques is the application- specific individuality of the function interfaces and message structures, as well as the loss of compatibility caused by even a small change, which leads to the mutual captivity and version dependence of communicating applications. In addition to this, each application must know specifically from which application each service can be obtained.

By using the communication method (DXI) according to an embodiment, a uniform communication between applications is provided, where changes in the communication interface or message structure of an individual application do not cause a change in the communication mechanism itself and therefore do not automatically require changing and updating client applications. In the DXI method the applications communicate by sending and receiving data elements (key/value-pairs), which are relayed between the communicating applications without the applications in question knowing each other in depth. This is described more in detail by examples later.

The generic transfer of information in a distributed system requires support for all possible data types. In a conventional data transfer between applications, either a separate interface or its type-specific extension is created for each data type, which in turn causes problems, typically due to limited support for data types, the inflexibility of fixed interfaces and the difficulty of controlling changes and versions.

By using a uniform data position control according to an embodiment, the direct access of the application (APPLICATION) to the original data position of the data element (DATA) is enabled. This method enables a fast data transmission and the multiformity of the data type does not limit data transfer at all. This is also described more in detail by examples later.

Communication between applications in a distributed system, where the applications are located, for example, in different devices connected by a data communication network, requires specific planning and a great deal of error-prone control of settings. According to prior art, the system in practice becomes so static, that it does not allow the removal or addition of an individual device, or even changing (network) settings, such as IP addresses.

By using the communication method (DXI) according to an embodiment as described above, it is possible to implement a distributed application environment, where information on the services provided by the device is communicated to the other devices of the network, and information on the services provided by the other devices of the networks is received. In addition, the received service information is provided to the communication mechanism (DXI), which, if necessary, directs traffic over the network without the communicating applications having to separately prepare for the situation. From object-oriented software architectures are known, inter alia, get and set operations, by means of which objects and their values are set to a variable. According to an embodiment the communication mechanism (DXI) defines the get and set operations so that the application sending with the get operation (making the call) requests the receiver to send as a response the current values of the data elements defined as parameters. With the set operation the sending application (the one making the call), in turn, notifies the receiver of the new values for the defined data elements as parameters of the call. The receiving application performs the procedures needed for changing the values of the data elements in question.

According to an embodiment, in the above-described communication mechanism an unlimited number of data elements can be as parameters of both the get and set operations. A data element is a key/value pair, where the key is a character string of an unlimited length, and the value is one of the allowed data types: signed/unsigned 32/64-bit integral number, floating point number, ASCIIZ character string, or an unlimited byte string (without a data type) divided into dimensioned bytes. As a part of the value of the data element it is also possible to relay the status data of the application, in which case the receiving application can possibly be prepared, for example, for the application processing the data element in question being loaded and not necessarily reacting to calls as fast as when unloaded. The identifier of the operation, as well as its parameters are advantageously encoded into such form that may be transferred by using a DXIJransport transfer mechanism.

The applications do not need to be aware of the location of the data elements; it is sufficient that they know the key of the data element in question. In order for the DXI relay mechanism to find the data element on the basis of the key only, the initial part of the key indicates the keyscope. Each application has an individual keyscope, which they register to a keyscope registry. This embodiment is illustrated in the example according to figure 3. In figure 3 the application 300, whose keyscope is "sensors", publishes two data elements, whose keys are "temp.mbi" and "fan.rpm.1". At first the application initializes (init(); 302) the DXI_transport communication channel 304, so that other applications will be able to communicate with it. As a result of the initialization (init_result(); 306), the application 300 receives information on its key address (transport_addr), which it notifies (register_keyscope(); 308) to a keyscope register 310. At the same time the application registers its keyscope "sensors". When the application has registered as described above, the data element of the application can advantageously be manipulated from another application, if the other application only knows the key of the data element.

According to an embodiment the registration of data elements utilizes advantageously also other data on the "behaviour" of the data element. For example, the previous example describes two sensors ("sensors"), the first of which measures temperature ("temp.mbi") and the second the fan rotation speed ("fan.rpm.1"), which values therefore describe the values of corresponding data elements. Now the first sensor is registered in the key register expressly as a temperature sensor (temp) and the second sensor as the sensor for the speed of rotation of the fan (fan.rpm). The behaviour of this kind of values, such as temperature or the speed of rotation of a fan, in a known environment is very much predictable by a person skilled in the art, in which case it is possible to make strong assumptions on the current values of the data elements. Thus, for example in a situation, where it is sufficient that the values of the above-described data elements are only within obvious limiting values, it is possible to make such an assumption purely on the basis of the "behaviour data" of a data element and the actual value of the data element does not need to be fetched from another application each time.

The system most advantageously comprises the keyscope register 310 covering the entire system, which register is composed of several tables, to which at least the keyscopes, channel addresses and status data of the applications are stored. The tables of the keyscope register can advantageously be grouped device-specifically, in which case the data elements of the applications of one device are stored in the same table. Thus, when searching for the value of a specific data element of some application, if the application is known to be in a specific device, the search can be focused directly to the correct table. Correspondingly, if searching for an application, which is by default located in a different device than the application performing the search, the search can be skipped in the table of the device in question. A person skilled in the art will appreciate that the keyscope register can also be implemented as several separate keyscope registers.

Figure 4 illustrates an example of how another application can determine the value of a data element published by a first application on the basis of the key. In figure 4 the communication application (clientApp; 400) between two applications is interested in the value of that data element, whose key is "sensors. temp. mb1". The communication application 400 does not know the application it needs to communicate with in order to receive the desired reply, and therefore it makes a call (get("sensors.temp.mb1"); 402) to the DXI relay mechanism 404 (DXI_broker). In order to establish the correct keyscope the DXI_broker 404 performs a search on the basis of the key (find_provider("sensors.temp.mb1"; 406) in the keyscope register 408, from where a keyscope "sensors" registered in the above- described manner is found. The keyscope register 408 returns as a reply to the query the correct keyscope and the channel address of the application (find_result("sensors", transport_addr; 410).

By means of the channel address received from the keyscope register the DXI_broker 404 may now perform the actual communication via the DXMransport channel to the application providing the data value in question. In other words, the DXI_broker 404 sends an operation call (op(get, transport_addr, "sensors.temp.mb1"); 412) to the DXMransport channel 414, which directs the call (getfsensors.temp.mbr); 416) on the basis of the channel address to the correct application 418, which also comprises the data element "temp.mbr. According to an embodiment the DXI_broker 404 relays the correct keyscope ("sensors") received from the keyscope register 408 and the channel address (transport_addr) of the application to the application (clientApp; 400) that made the call, which stores the location of the data element for example as a static variable, which after this always points directly to the data element in question. Thus, the next time the communication application searches the value of the data element "sensors.temp.mb1", the keyscope and the channel address are not needed to be searched again, but the addressing takes place directly to the data element itself, which naturally optimizes the speed of the search.

The above-described communication mechanism and its different embodiments are especially suitable for administering and controlling distributed systems. One such distributed system may be a headend apparatus according to figure 1. Figure 5 shows an example of such a distributed system, which is composed of several devices connected to each other via a data communication network.

The system of the example according to figure 5 is the administration application of some other system, where each device is responsible for a certain part of the operations of the system. The system comprises a monitoring device (monitor; 500), which monitors the state of the administrated system, a control device (control; 502), which controls the administrated system, a database (db; 504), to which the state history of the managed system is stored, and user interface devices (monitor_gui; 506; control_gui; 508), which offer user interfaces for monitoring and controlling the administrated system. The devices of the system are connected to each other by means of a communication channel (ethernet; 510). In this kind of a system it is possible to advantageously apply the above-described communication mechanism (DXI) so that the parts of the system find each other in a self-educating manner. This is illustrated in a simplified manner by means of figure 6.

The services provided by the device are notified to the other devices of the system by means of so-called service notification messages. In figure 6 the device keyscope of the device is "monitor_gui", which a distributed DXI server (Distributed DXI_server; 600) notifies to the network (announce("monitor_gui"); 602) for the information of other devices of the system. At the same time the DDXI_server 600 listens to the service notification messages of other devices, and when noticing one (listen("monitor"); 604) stores the service notification messages together with the channel address (register_global_keyscope("monitor", transport_addr; 606) required for DXI communication to the device keyscope register 608 covering the system. According to an embodiment the procedure also comprises the expiry of the device keyscope, i.e. each service notification message is valid for only a specific time, and if no new service notification message is received within this time, the device keyscope in question is removed from the register.

Figure 7 illustrates an example of how the communication between the applications takes place when the applications are located in different devices. Figure 7 shows two device assemblies, a user interface device (monitor_gui; 700) and a monitoring device (monitor; 702), as well as a communication channel (DXMransport; 704) as an interface between these. The application ("Ul_app"; 706) located in the user interface device 700 wants to know the value of the data element "monitor.sensors.temp.1", and therefore it makes a call (get("monitor.sensors.temp.1"); 708) to the DXI__broker mechanism 710. In order to determine the correct keyscope the DXI_broker 710 first performs a search on the basis of the key (find_provider("sensors.temp.mb1"; 712) to the device-specific table 714 of the keyscope register. Since no correspondence is found in the device-specific table 714 of the keyscope register, next a search (result(NO_MATCH); 716) in the device keyscope register 718 covering the entire system is made, where a device keyscope "monitor" registered in the above-described manner can be found. As a response to the query, the device keyscope register 718 returns the correct keyscope of the device and at least the channel address of the device (resultfmonitor", transport_addr; 720).

On the basis of the channel address received from the device keyscope register 718, the DXI_broker 710 sends an operation call (op(get, transport_addr, "sensors.temp.1"); 722) to the DXI transport channel 704, which directs the call (get("sensors.temp.mb1"); 724) on the basis of the channel address of the device first to the correct device ("monitor"; 702). The monitoring device 702 directs the call further to the application 726, whose keyscope is "sensors", which also comprises the data element "temp.1".

A requirement for the operation of the above-described mechanism is advantageously only that the service notification message sent by the monitoring device 702 must be registered in the device keyscope register of the user interface device 700. Therefore, the communicating applications do not advantageously need to be prepared for communication between devices in any way. Communication between applications is therefore performed in the same way irrespective of whether they are in the same device or in different devices.

Thus, the entire system can be implemented by focusing expressly on the characteristics of the variables, because there is no need to pay attention to the data type itself, as the communication mechanism is designed to operate with any data type. This way it can further be ensured that the variable acts in the manner that is characteristic to it.

The communication mechanism DXI itself can be implemented on the basis of IPC techniques known as such. In other words, the transfer of data elements can be implemented either as communication between two points (P2P) with its function call mechanisms or by using message relaying in bus-form. Thus, the encoding/decoding of data elements is performed most advantageously in a manner characteristic to the selected IPC technique. Especially in connection with headend apparatuses, most of the communication takes place between two applications, in which case P2P communication is a more natural selection for IPC technique. Some applicable communication mechanisms include CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) and Sun RPC (Remote Procedure Call), of which especially SunRPC is well suited to be used in Unix/Linux-based embedded systems. It will be obvious for a person skilled in the art that with technological developments, the basic idea of the invention can be implemented in a variety of ways. Thus, the invention and its embodiments are not limited to the above-described examples but they may vary within the scope of the claims.

Claims

Claims:

1. A method for administration of variables in a distributed data system, which data system comprises several data processors connected to each other via a communication bus, which data processors comprise at least one application, which applications are arranged to communicate with each other; characterized by the method comprising defining variables of said applications as data elements, which data element is a key/value pair, where the key defines the location of the data element in the data system and the value defines the current value of the data element; registering a specific keyscope for each said application, which keyscope defines the initial part of said key, and a channel address of the application, which defines the location of the application in the communication bus so that the channel address can be established on the basis of said keyscope; calling from the first application at least one data element in the second application on the basis of at least a data element key; and directing the call in the communication bus to said second application on the basis of the data element key and the application channel address.

2. The method according to claim 1 , characterized by receiving (306) in said application a channel address of an application in response to the application initializing (302) a communication channel (304) in the communication bus; and registered (308) a specific keyscope for said application and an application channel address to the keyscope register (310).

3. The method according to claim 1 or 2, characterized by determined for said calls a get operation, with which the application making the call requests the receiving application to send as a response the current value of at least one data element defined in the call; and a set operation, with which the application making the call notifies the receiving application a new value for the at least one data element defined in the call.

4. The method according to claim 3, characterized in that in said get and set operations the parameters can be an unlimited number of data elements

5. The method according to any of the preceding claims, characterized in that in the key/value-pair of the data element the key is a character string of an unlimited length, and the value is one of the following allowed data types: signed/unsigned 32/64-bit integral number, floating point number, ASCIIZ character string, or a byte string without a data type.

6. The method according to any of the preceding claims, characterized by notifying (604) the services provided by said data processors by means of service notification messages to the distributed administration server (600); storing the device keyscope notified in the service notification message and the corresponding channel address in a device keyscope register (608) covering the system; and notifying (602) the services provided by a specific data processor by means of service notification messages to other data processors of the system from the distributed administration server (600).

7. The method according to claim 6, characterized by storing the device keyscope notified in the service notification message and the corresponding channel address in a device keyscope register (608) covering the system for a set time; and in response to not receiving any new corresponding service notification messages within the set time, said device keyscope is removed from said device keyscope register (608).

8. The method according to any of the preceding claims, characterized by in response to the call made by said first application on the basis of the key of the data element of the second application, directing the call (402; 708) to a device-specific relay mechanism (404; 710); performing a search (406; 712) on the basis of said data element key in the device-specific table of the keyscope register (408 714); in response to not finding said data element key in the device-specific table (408; 714) of the keyscope register, performing a search (716) on the basis of said data element key in the device keyscope register (718) covering the system; in response to finding said data element key in the device keyscope register (718) covering the system, sending (720) a device keyscope corresponding to said second application and the channel address of the device to the device-specific relay mechanism (710); and directing (722) a call from the device-specific relay mechanism (710) in the communication bus to said device comprising the second application on the basis of said device keyscope and the channel address of the device.

9. The method according to any of the preceding claims, characterized by encoding the identifiers of the operations used in the calls and the parameters of the operations so that they can be transferred by using the selected communication mechanism.

10. The method according to claim 9, characterized in that the communication mechanism is one of the following:

CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) or SunRPC (Remote Procedure Call).

11. A headend system of a cable television network, comprising several processors for television transmissions connected to each other via a communication bus, which processors comprise at least one application, which applications are arranged to communicate with each other; characterized in that in the headend system variables of said applications are arranged to be defined as data elements, which data element is a key/value pair, where the key defines the location of the data element in the data system and the value defines the current value of the data element; said processors and the applications comprised by them are functionally connected to their own core software unit, which provides an interface and a communication mechanism to the data elements of the other processors of the headend system and their applications; said headend system comprises a keyscope register (408; 714), to which is arranged to be registered a specific keyscope for each said application, which keyscope defines the initial part of said key, and a channel address of the application, which defines the locations of the application in the communication bus so that the channel address can be established on the basis of said keyscope; said processors and the applications comprised by them are arranged to communicate with each other by calling from the first application at least one data element in the second application at least on the basis of a key of the data element; and by directing the call in the communication bus to said second application on the basis of the key of the data element and the channel address of the application.

12. The headend system according to claim 11 , characterized in that said applications are arranged to initialize (302) their communication channel (304) in the communication bus, as a response to which they receive (306) the channel address of the application; and a keyscope register (310) comprises several device-specific tables, to which the specific keyscope of said applications and the channel address of the application are arranged to be registered (308) device-specifically.

13. The headend system according to claim 11 or 12, characterized in that in the key/value pair of the data element the key is a character string of an unlimited length, and the value is one of the following allowed data types: signed/unsigned 32/64-bit integral number, floating point number, ASCIIZ character string, or a byte string without a data type.

14. The headend system according to any of the claims 11 to 13, characterized in that at least one core software unit comprises a distributed administration server (600), to which the services provided by said data processors are arranged to be notified (604) by means of service notification messages; a device keyscope register (608) covering the system, in which register the keyscope notified in the service notification message and the corresponding channel address are arranged to be stored; and said distributed administration server (600) is arranged to notify (602) the services provided by a specific data processor by means of service notification messages to the other data processors of the system.

15. The headend system according to any of the claims 11 to 14, characterized in that at least one core software unit comprises a device-specific relay mechanism (4040; 710), which is arranged to receive the call made by said first application on the basis of the key of the data element of the second application; which device-specific relay mechanism (404; 710) is arranged to perform a search (406; 712) on the basis of said data element key in at least one device-specific table (408; 714) of the keyscope register and, if necessary, further in a device keyscope register (718) covering the entire system; receive in response to said search a device keyscope corresponding to said second application and the device channel address; and direct (722) a call in the communication bus to said device comprising the second application on the basis of said device keyscope and the channel address of the device.

16. The headend system according to any of the claims 11 or 15, characterized in that the identifiers of the operations used in the calls and the parameters of the operations are arranged to be encoded so that they can be transferred by using the selected communication mechanism.

17. The headend system according to claim 16, characterized in that the communication mechanism is one of the following: CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) or SunRPC (Remote Procedure Call).

18. The headend system according to any of the claims 11 or 17, characterized in that said processors are implemented as separate modules, in which case the headend system comprises a main module (102), which is responsible for administering the headend system and all the modules connected to it; and at least one, advantageously several interface modules for receiving and sending program streams of the cable television system.