MXPA00010360A - Method for managing objects in a communication network and implementing device - Google Patents

Abstract

The invention concerns a method for distributive management of a catalogue of objects in a communication network comprising machines, said method comprising a step for recording the local objects present in a machine in a local register managed at said machine level. The method is characterised in that it consists in:preparing, by a local object, a request for a list of objects, said request being transmitted to the single local register of the machine housing the object;propagating said request by the local register to remote registers;collecting replies to said request by remote registers and the local register reply;transmitting the collected replies to the local object which has made the initial request. The invention also concerns machines capable of being connected to a network wherein said method is implemented. The invention is particularly applicable in the context of home automation communication networks.

Description

PROCESS TO MANAGE OBJECTS IN A COMMUNICATION NETWORK AND DEVICE FOR IMP EMENTATION OF THE SAME The invention relates to a process for handling objects, in particular computer program modules, in a communication network that can be of the automation type at home. It also refers to devices capable of being linked to this network and comprising a means to implement the process. The invention applies in particular in a home network adapted to the interconnection of audio and video devices. In a network of mass market electronic devices such as televisions, satellite cable decoders or video recorders, it is necessary to provide a means of communication between the devices, while taking into account the complexity and price limitations inherent in the devices. devices produced in mass. Depending on the type of network contemplated, it may be necessary for a device (also referred to as a node in the following) of the network Determine the path or address of another device. This is also the case if the concept of the device is replaced with the concept of object, or program module, it being possible for a device to contain a large number of objects. This can be related to downloaded or resident applications, particular user interfaces or lower level modules. Each object or module of a device can seek to communicate with another object or module of the same device or of another device in the network. Each object is considered as a resource available to the other objects. In this case, the problem arises from obtaining a dynamic list of resources available on the network. In this context, the object of the invention is a process for the distributed handling of a catalog of objects in a communication network comprising devices, the process comprising the step of registering local objects present in a device in a local register handled at level of this device, the process that is characterized in that it additionally comprises the steps of: - formulating, by a local object, a request for a list of objects, the request that is transmitted to the local, individual registry of the device that hosts the local object; propagate the request through the local registry to the distant registers; - collect the responses to the request by the remote registers and the response of the local registry; - transmit the collected responses to the local object that has made the initial request.

Each node (or device) stores only the local information to this node or device; the information is not duplicated in other nodes, an object that registers itself only in the local registry. In this way, the memory requirements on each device are restricted. The object search (program modules) is distributed among the various devices, each database that is interrogated locally. In this way, the requirements of resources for the processing of information at the local level are also restricted by themselves. In addition, only the relevant information, that is, the one that meets the search criteria, travels over the network; therefore it is used Widely pass band. The consistency of the data is maintained in a simple manner; it is not necessary to update, by virtue of complex processing, distant databases when a change is made in a local database. And if a node disappears, only the information related to this node is lost. Also, requests are propagated in the network only to the other registers. There is no transmission to all the elements in the network, only to a well identified subset, specifically the registers. This also limits the band of steps required. According to a particular embodiment, a local register comprises for each object registered therein an identifier of this object in the network, this identifier that is unique to the network, as well as the attributes of the object. According to a particular embodiment, the identifier (SEID) comprises a device identifier in which the object is present, this device identifier that is unique in the network, as well as a unique local identifier in this object at the level of device.

According to a particular embodiment, a type of request formulated by an object is a request comprising at least one selection criterion corresponding to an attribute of the object. According to a particular embodiment, the function of an object is an attribute stored by a local register with respect to the object. According to a particular embodiment, the step of propagating a request comprises the step of determining the devices connected to the network that comprise a register by themselves. An object in this way can initiate a request to obtain a list of the other objects without relating itself with the knowledge of whether or not these objects are located in the same node. According to a particular modality, the step of determining the devices comprises the determination of the types (FAV, IAV, BAV, LAV) of the devices present in the network, the type of a device that indicates whether a record is hosted or not. he hosts it. In the HAVi type network, the type devices FAV and IAV are obliged to understand a registry, while devices type BAV and LAV do not possess According to a variant mode, a request is propagated only to a specified group of remote registers. When it is known, for example, in advance that program modules comprising certain attributes are present only in a given type of device, then it is possible to limit the propagation of requests to this type of device to limit the number of messages that flow around the device. network. According to a variant embodiment, one of the types of requests that can be formulated by an object is a request comprising selection criteria for at least two object lists, as well as at least one operator to process the lists. The subject of the invention is also a device in a communication network comprising a means for storing local objects, a means for storing a local object for containing a catalog of objects local to the device, a means for connecting the network device, the device characterized in that it additionally comprises: a means to propagate a request for a list of objects formulated by a local object to the local registers in the other devices; a means to collect the response from the records of the other devices and the response of the local registry and to transmit the responses to the object that has made the request.

According to a particular embodiment, the device further comprises a means for determining the addresses of the devices of the network comprising the so-called differential registers. Other features and advantages of the invention will become apparent through the description of a particular non-limiting modality illustrated by the appended figures, among which: The Figure schematically represents a home network comprising four devices of different types. Figure Ib is a block diagram of one of the devices of Figure 1; Figure 2 is a schematic representation illustrating the program organization of the device of Figure 1; Figure 3 represents the states of a registration module of a device of the network; Figure 4 represents the sequencing of messages in a request requesting propagation to a remote registration module. According to the present example embodiment, the home network comprises four types of devices. Audio and video devices that have complete functionalities (FAV), audio and video devices with an intermediate function (IAV), audio and video base (BAV) devices and audio and video inheritance devices (LAV). The common communication bar is of the IEEE1394 type, but may be of some other type. The network supports a common control language, referred to as HAVI language. FAV type devices have the most complete functionalities of all the devices in the network; a communication manager, a registration module, an administrator of device control modules and device control modules (referred to as "DCM" in the following), it being possible for the latter to be downloaded. According to a variant, the device also comprises a User interface administrator, FAV devices can take control of less sophisticated devices, such as BAV and LAV devices by means of device control modules. An FAV device can access other FAV or IAV-type devices in order to access the resources it lacks (for example, a user interface manager). IAV devices have the same functionality as an FAV except for the possibility of downloading device control modules. BAV type devices have a specific private control language for them, and that is not necessarily the one used by the rest of the devices. This type of device is controlled by a FAV device by means of a control module (DCM) discharged from the same type BAV device and adapted for the control thereof, for example the BAV type device can be a printer, whose printer administrator is Download LAV devices are devices connected to the common bar or to devices of type IAV or FAV through specific connections. LAV devices are controlled by specific control modules (DCM) that do not originate from the device itself and have their own private language. The Figure represents an example network in the form of four FAV, IAV, BAV and LAV devices. The FAV, IAV and BAV devices are connected to the same common bar while the LAV device is connected directly to the FAV device and controlled by a control module present in the latter. The BAV device is controlled, for example by means of the IAV device. Figure Ib schematically represents the FAV 1 device, comprises a microprocessor 2 linked to a random access memory 3 and a read only memory 4, at least partially programmable, as well as a common bar interface of the IEEE 1394 type (reference 5) which consists of a link circuit and a physical circuit ("PHY" according to the IEEE 1394 terminology). The device 1 also comprises a specific interface 6 for connecting to the LAV video recorder. In particular, four types of modules of program may be present in the memory of the devices of the present network. These are DCM device control modules, applications, service module ^ and a message transmission manager. The DCM device control modules allow control of a device or a subset of this device. The control module can be located in the device to be controlled by itself (if it is a device type IAV or FAV) or in a device different from the device to be controlled (if the device to be controlled is of type LAV or BAV, the control administrator will be located in a device type IAV or FAV, the latter that serves as a platform of execution). A control administrator is either present from the outside, or can be downloaded. In the latter case, the download is carried out for example at the time of initialization of the device, or when requested by an application. The function control modules (referred to as FCM) are program modules that allow the control of a function of a device and are included in the control modules of DCM devices. In this case, a device may have several functions: recording, tuner, camera, display, mass memory, etc. Service modules often offer system services or functions. They can be accessed either by local program modules, or through the system to transmit messages to the modules of other devices. These services or system functions include, in particular, the graphic administration of the user interfaces, the administration or operation (for example, downloading) of the DCM modules, the procedures for connecting a device to the network, the initialization of the network (list of network resources), as well as the registration modules, which will be seen in greater detail later in the present. Each program module (DCM or application or system service modules) must register itself in the local registration module (that is, the registration module in which it resides or in which it has been loaded), if desired grant access through the message layer to other program modules of the network. The FCM function modules related to a DCM control module are also registered by themselves in the local registration module. The message transmission administrators are responsible for communication messages from one program module to another, despite the devices in which these modules are located. When a program module needs to send a message to another module, it does not know the physical device that hosts the destination module. Figure 2 illustrates an example of a program organization of a FAV type device. This device comprises a downloaded application 21 (for example, a game), two DCM control modules A and B 22 and 23, a private application 24 (for example, an electronic program guide), a common communication bar manager 25. IEEE 1883/1394 type, a registration module 26, a high level user interface 27, a DCM administrator 28 and a message transmission system 29. The modules communicate with each other by means of the message transmission system accessible through an interface. 30 of application programming (referred to as the "API" in what follows). The device also comprises an interface 31 with the common bar 1394. In its installation in the network, the FAV device will seek to load the DCM control modules of the BAV devices in order to make them available to the applications. With this in mind, the BAV devices place the code of the corresponding DCM module in a known area of their memory and in a self-descriptive data structure referred to as the SDD (SDD stands for "Self-description Device"). The FAV type device in this way can read this memory space and load the DCM module of the BAV type of the device. An example is where the BAV device is a printer. The DCM control modules loaded in this way are registered in the FAV device registration module and are thus accessible by the rest of the network. The data structure type SDD is mandatory in the devices type FAV, IAV or BAV and is located in a fixed address in each device. In the initialization of the same, in this way it becomes possible that a device type FAV explore the network to load the DCM modules of all BAV type devices. It is the administrator of the DCM modules of the FAV device that executes this task. An SDD data structure also comprises the type of device (FAV, IAV, BAV, LAV). The message transmission system of a device comprises: - the registration module 26 (declaration and search for program modules), a message layer, comprising the message dispatcher 29 (sending and receiving messages), the message interface Application programming (API) 30 to allow access to the transmission system and an adaptation sub-layer of the IEEE 1394 common bar. The common bar adaptation sub-layer IEEE 1394 has in particular the role of adapting the data transmission to the IEEE 1394 protocol, by encapsulating the messages to be transmitted in packets adapted to the IEEE 1394 standard. A message comprises three components: the address of the destination program module , the address of the source program module and the useful data.

An address of a program module is composed of an identifier of the node in which it is executed, this identifier that is unique to the network, followed by a unique program module identifier to the node in which it is executed. The identifiers of the program modules are assigned by the local message transmission system to a node. The addresses are used by the message dispatcher to transmit messages to the appropriate program module. According to the present example embodiment, a program module address or identifier referred to as "SEID" in what follows), is a binary word of 880 bits. This comprises: • A 64-bit device identifier stored in the ROM of the device on which the program module is executed. In the case of a downloaded module, it is the identifier of the host that is used. The device identifier is assigned at the time of manufacture and corresponds to the EUI64 field defined in the IEEE 1394-1995 standard. A part of this device identifier is administered by the IEEE organization that it is specific to each manufacturer, the other is chosen by the manufacturer of the device itself, in such a way that each manufactured device is provided with a different identifier. • A local identifier consisting of a serial number assigned directly by the message transmission system of a node, this number is coded in 16 bits and concatenated with the device identifier to form the SEID identifier. The message transmission system maintains an accountant in this regard. Few serial numbers are reserved (for example from 0x0000 to 0x0005) and are used to define the particular service modules. For example, the serial number 0x0001 corresponds routinely to the module of the registration of a device. In this way, each program module of the network comprises a different and unique SEID identifier. However, it is possible to define unique identifiers by means of the others indicated above.

The registry module maintains a database comprising a directory of locally available computer program modules at the device level. It makes available a programming interface that provides access to the functions of the registry of program modules and the search of modules according to a list of criteria. There is a registration module in each device type FAV or IAV. Within this device, all program modules are registered by the local registry module. If a program module wishes to be able to be concatenated, it must register itself in the registration module. For each program module registered therein, the registry module maintains its address in the network and the attributes of this module. According to a variant mode, the registration module does not include the program module address, but its serial number. The attributes of a program module allows it to be characterized. For each program module, these attributes are stored in a table, which includes for each attribute the reference of the latter in 32 bits, su. size in bytes as well as its value. Table 1 gives a list of the default attributes.

TABLE 1 The type of program module represents the main function of the module. If the program module is a system service module, then the attribute type designates the system service itself. The registration module is a service module. If the program module is an FCM, function control manager, the type defines the function: recorder, display, tuner, etc. If the program module is a DCM device control manager, the type is "DCM", if the program module has an application programming interface ("API") that is incompatible with the rest of the network, the type it is private" . The identifier "HUID" is a device identifier with which a DCM administrator or function is associated with which an FCM administrator is associated. The type of device associated with the program module is FAV, VAT, BAV or LAV, as already explained. A DCM administrator can be associated with a graphical user interface. The attribute "graphical interface" indicates that this is the case, and that it was appropriate in the degree of compatibility of the DCM administrator interface with the various interface levels provided in the network. The attribute "formed of support" indicates the type of data storage support that is supported by a device. These are for example DVD, DAT, DVHS, DVC media. The "formed data" attribute indicates the data format that can be manipulated by a device. These are for example MPEG2, JPEG, MIDI, ASCII formats. The attributes "device manufacturer" and "program module manufacturer" indicate a reference respectively of the device manufacturer or the program module while the attribute "program module pressure" indicates the version number of a module. Finally, the attribute "audio / video command language" indicates the type of language specific to the program module, in addition to the common HAVI command language already mentioned. The value of the attribute is a 32-bit field, the value of each bit indicating compatibility with a specific order language, for example CAL or AV / C. The database of a registration module it can also understand, according to a variant modality, specific or "private" attributes. It should be noted that the modules of the registers of several devices are different. There is no centralized registry, in which all the program modules will be cataloged. Program modules register only at the level of an individual record; your local registry. Therefore, there are no double records in several registers.

According to the present example embodiment, the application programming interface of a register module comprises five orders, which will be detailed below: (a) Program Module Register This command is used to add a program module to the local registry database or to modify the attributes of a program module that you have registered. This is in particular by a program module to register itself when the device comprising this element is connected. The program module transmits its SEID identifier and the attributes to the module 3 registry. If this Mentifier is already present, the new attributes replace the old ones. Otherwise, a new entry is created in the local database (^ * local record). The registration module transmits a status message to the program module, depending on the result of the recording: recording confirmation or message from (b) Extraction of the Program Module This command is used to read the attributes of a program module, knowing its SEID identifier. An indicator to an area of the device's random access memory, to which the data must be copied, is transmitted with the extraction request. If the program module is not present in the local database, then the indicator is set to zero and it is returned through the registry module. The registration module also returns a status message, which confirms the copying of the attributes, or indicates that the searched identifier is not present. (c) Deleting a Registry Program Module This command is used to remove a program module from the local database. Its SEID identifier is supplied as an order parameter. The registration module returns a status message confirming the deletion or indicating that the corresponding program module has not been found. (d) Request for the List of Program Modules ("Simple Request") This order makes it possible to determine the identifiers of the program modules registered in the set of local registrars and that meet certain criteria. According to the present example embodiment, these criteria are the reference of an attribute and the value of an attribute. A parameter of the order is also an operator that indicates the way in which the comparison between the value of the attribute specified in the order and the values of the base will be elaborated (equal, greater, greater or equal, smaller, smaller or same, different, logical "Y" in the form of bits, logical "0" in the form of bits, etc.). _________________ É _____________ aa__ The register module returns, as appropriate, the list of SEID identifiers of the corresponding program modules. It also returns a message from. state that indicates the success of the operation (whether the identifiers have been found or not) or its failure. (e) Realization of a Boolean Operation between two lists of Program Modules ("Multiple Request") This order is used to perform a Boolean operation on two lists of identifiers. The order includes as a parameter the requests corresponding to each list. A request may consist of the criteria already mentioned in paragraph (d) (simple petition), or of other multiple requests. A parameter of this order may also be the relevant Boolean operator ("Y" or "0" within the context of the present example embodiment). The registration module returns as appropriate the list of identifiers SEID as well as a status message that reports the success of the operation or its failure, for any reason, such as for example a shortage of resources.

To have access to other program modules, a program module must know the SEID identifier of its corresponding modules. With regard to the program modules registered in the same module of the registry, this is not a problem, the set of previous requests that allow each program module to extract the lists of identifiers from the local database. A program module has access to the local registry module through the local message transmission system. You can also access a remote registration module, in this way send back identifiers of modules registered in other registration modules. To do this, each registration module propagates a request that has been transmitted locally to the modules of the registers of the other devices. According to the present exemplary embodiment, a remote registration module from which no response is received in a given time interval is ignored.

Each registration module that receives the request from the initial registration module performs its own search in its local database and returns the list separately as appropriate. of identifiers that correspond to the criteria of the request to the initial registration module. The latter then transmits the concatenated list of all received identifiers to the program module that initiates the request. The program module when the request starts can then communicate with the program modules of other devices and use resources that correspond to them.

Figure 3 is a state diagram of a module of the register of a device. This diagram comprises two states, A and B. The state A is a state waiting for a request from a program module. State B is the state waiting for a response to an elaborate request from the remote record modules by the local registration module. Table 2 gives the events that activate the actions undertaken by the local registry module and the corresponding start and end states. The reference of the events are the same as in Figure 4.

TABLE 4 The requests are propagated by the registration module. It should be noted that the identifier of a registration module is composed of a manufacturer identifier (set by IEEE), a device identifier (set by the manufacturer) and a registration module identifier, the latter being identical for all registration modules. To be able to propagate a request, the registration module of a device enrolls all the devices in the network, whose identifiers it obtains. Then determine those among these devices who comprise a record. In the present example embodiment, these are only FAV or IAV type devices. Knowing the identifiers of the devices that can be accessed by the network, the registration module reads the type of each device in the SDD data structure mentioned above. In this way it eliminates the BAV devices. The concatenation of each device identifier with the local identifier (serial number) fixed common to all the registration modules to obtain the list of the complete SEID addresses of all the registration modules. A registration module has the list of identifiers and device by means of the management module of the local common bar (the so-called "CMM"), which monitors the connection and disconnection of the network devices. This module reads the list of all the nodes connected to the network from a record referred to as "T0P0L0GY_MAP" defined by document IEEE 1394-1995, paragraph 8.3.2.4.1. This record is placed in a common bar manager device (referred to as the "common bar manager" in the IEEE document cited above) that updates the record in relation to the topology of the network. The address of this device is known by the other devices by the means also described in the IEEE document. Figure 4 is a diagram indicating the sequencing of the messages when a request issued by a program module A and a first device is to be propagated to the registration module of a second device, a program module B which is registered in the record of this second device. In accordance with the modality presented hereinabove, a petition issued a program module with a view to determine the set of non-local program modules is propagated to all remote registration modules. According to a variant embodiment, this type of request can also be limited to a group of remote registration modules, for example, those of a particular type of device.

Claims (10)

1. CLAIMS 1. A process for the administration or distributed management of a catalog of objects in a communication network, comprising devices, the process that comprises the step of registering local objects present in a device in a local register managed or administered at the level of this device. The process that is characterized in that it additionally comprises the steps of: - formulating, by a local object, a request for a list of objects, the request that is transmitted to the local registry, individual of the device that hosts the local object; propagate the request through the local registry to distant registers; - collect the responses to the request by distant registers and the response of the local registry; - transmit the collected responses to the local object that made the initial request.
2. 2. The process according to claim 1, characterized in that a local registry comprises for each object to register therein an identifier of this object in the network, this identifier being unique to the network, as well as the attributes of the object.
3. 3. The process according to claim 2, characterized in that the identifier (SEID) comprises a device identifier in which the object is present, this identifier device that is unique in the network, as well as a unique local identifier to this object at device level. The process according to claim 2 or 3, characterized in that a type of request formulated by an object is a request comprising at least one selection criterion corresponding to an object attribute. The process according to claim 4, characterized in that the function of an object is an attribute stored by a local register with respect to the object. The process according to one of the preceding claims, characterized in that the step of propagating a request comprises the step of determining the devices connected to the network that themselves comprise a register. The process according to claim 6, characterized in that the step of determining a device comprises the determination of the device (FAV, IAV, BAV, LAV, of the devices present in the network, the type of a device that hosts a register or if it does not host it.) • The process according to one of the preceding claims, characterized in that a type of request formulated by an object is a request comprising selection criteria for at least two lists of objects, as well as at least one operator to process the lists 9. The device in a communication network comprising means for storing local objects, means for storing a local register for containing a catalog of local objects to the devices, means for connecting the device to the network, the device which is characterized in that it additionally comprises: means for propagating a request for a list of objects formulated by a local object to the local registries of other devices; - means to collect the responses from the registers of the other devices and the response of the registry cal and to transmit the answers to the object that has made the request. 10. The device according to the claim 9, characterized in that it additionally comprises a means for determining the addresses of the devices of the network comprising the so-called remote registers.