MXPA99003538A - Device interoperability - Google Patents

Abstract

A device having means for controlling operating modes of the device processes control and query data received from the second and third electronic devices for managing the communication relationships amongst these devices. The invention involves a system for communicating between multiple electronic devices, such as consumer electronic devices or the like, via interconnections such as digital data buses.

Description

DEVICE INTEROPERABILITY Field of the Invention The present invention relates to a system for communication between multiple electronic devices, such as consumer electronic devices or the like, via interconnections such as digital data buses. More particularly, this invention relates to a configuration for handling the interoperability of said devices. BACKGROUND OF THE INVENTION A data bus can be used to interconnect electronic devices such as television receivers, display devices, video cassette recorders (VCRs), direct transmission satellite receivers (DBS) and home control devices. (for example, a security system or a temperature control device). Communication using a data bus occurs in accordance with a bus protocol.

Examples of bus protocols include the Electronic Bus of Consumption or CEBus, and the High Performance Series Bus IEEE 1394.

Commonly, a bus protocol provides communication for data and control information. For example, the control information is communicated in a "control channel" that has a protocol defined in the IS-60 specification of the Industry Association Electronics (EIA). The control information for a particular application can be defined using a form of programming language known as CAL (Common Application Language).

Consumer electronic devices are becoming increasingly complex and provide an increasing number of functions. Although coupling these devices together via a data bus it may be necessary to provide a complete audio-video (A / V) system, doing so can create numerous problems. For example, certain functions of a device may require interaction with one or more devices coupled to the bus. A capacity of one device may be necessary to complete a particular operation on another device. Conflicts between the needs of various devices can occur. European Patent Application 0 604 166 discloses a communication system that allows the transmission of more data than that which is provided in the data field of the transmission signal without interruption. Currently, when more than one device competes for the use of a common resource, for example a third device connected to the network bus, the first one in time controls the device. The other device can not access the common resource until the first device releases the resource. This does not represent a problem in simple networks, for example a network comprising a television, a cable box, and a video cassette recorder. In such simple networks, the video cassette recorder is "controlled" by the cable box, ie the video cassette recorder will only record what the cable box is playing. However, in more complex networks two devices, for example a cable box and a digital transmission receiver, can compete for the control of a shared resource, that is, a video cassette recorder. Brief Description of the Invention In many control applications it is desirable to discriminate on general access to a device. This discrimination usually benefits only one device. In such a case, a special relationship called "coupling", for a short or long period of time, between two devices. The coupling relationship allows a device to control access to a second device (i.e. a "coupled device"). In general, there are two types of coupling approaches. In the first approach, the coupled device determines whether it can be coupled and / or decoupled to another device. A request to couple the device is made directly to the coupled device. If the coupled device regroups the device that has attached it (ie, the coupling device) to discern whether the existing coupling can be terminated or not and complete a new coupling. If the coupling device does not respond, for example, in the case of a fault, the coupled device terminates the coupling and establishes the new coupling. In the second approach, a device that wishes to dock another device transmits a request in the network that any device having a coupling in the desired device ends its coupling. Generally, according to the invention, a first electronic device comprises a means for coupling a data bus and a control means for controlling the communication via the data bus between the first electronic device and second and third electronic devices coupled to the bus of data. The control means processes query and control data received from the second and third devices to handle the communication relationships between these devices. In accordance with one aspect of the present invention, there is provided a device having a means for communicating with at least one second device interconnected by a network bus, thereby creating a relationship between said first device and said second device, said means of communication is able to receive query data from a third device. Additionally, the device has a first means for storing information pertaining to the persistence of said relationship and a second means for storing information pertaining to a condition for terminating said relationship, and a means for controlling operating modes of said device in response to control data. of said second device. The control means is capable of processing said relationship information and said query data and terminating said relationship in response to one of the termination condition and said query data. In accordance with another aspect of the present invention, the relationship information comprises one of a first state wherein said relationship is terminated in response to said query data and a second state wherein said relationship is maintained independently of said data. query.

In accordance with yet another aspect of the present invention, terminating said relationship in response to such query data comprises forming a new relationship between such consumer electronic device and said third device. In accordance with yet another aspect of the present invention, the control means is capable of regrouping said second device, in response to receiving such query data to obtain permission to terminate said relationship. In accordance with a further aspect of the present invention, a system having a plurality of devices interconnected by means of a network bus is provided. Each device has a means for communicating, first and second means for storing information and a means for controlling the operating modes of said device as described above. In accordance with an aspect of the method of the present invention a consumer electronic device connected to a network bus, the method comprises communicating with at least one second device interconnected by a network bus, controlling operating modes of such consumer electronic device, storing information about a persistence of such a relationship and a predetermined condition pertaining to a condition for terminating said relationship, receiving query data from a third device, processing said information pertaining to said meaning of said relationship and said query data, and ending said relationship in response to one of the aforementioned termination condition and the aforementioned query data. BRIEF DESCRIPTION OF THE DRAWINGS The invention can be better understood by referring to the accompanying drawings in which: Figure 1A shows in block diagram form, a system of electronic devices coupled together using a data bus; Figure 1 B shows, in block diagram form, greater detail of a portion of the system shown in Figure 1 A; and Figures 2 to 7 show flow charts illustrating the operation of the system shown in Figure 1. In the drawings, reference numbers that are identical in different figures indicate functions that are the same or similar. Detailed Description of the Drawings Figure 1 A shows a system including electronic devices A, B and C, identified by reference numbers 1 10, 100 and 120, respectively, which are coupled together via a data bus 130. Devices A, B and C can be various types of electronic devices including consumer electronic devices such as video and / or audio signal processing devices and control devices for the home. Specific examples of consumer electronic devices include television receiver (TV), display devices, cable boxes, video cassette recorder (VTR or VCR) direct transmission satellite receivers (such as a DSS satellite receiver) disc drives Compact (CD) digital video disc drives (DVD). Home control devices include safety devices (eg, cameras, locks), remotely controlled interruption devices, and environmental control devices (eg, heating, cooling). A system embodying the principles of the invention may include more than three devices shown in Figure 1 A. Also, each device may be a different type of device. For example, a system in accordance with the invention could include numerous devices in a home including a television receiver, video cassette recorder, cable box, satellite receiver, audio system, and home control devices. In the example shown in Figure 1A, the data bus 130 includes multiple signal paths to communicate control and data information between the devices. The bus structure can be in series or in parallel. The data communication on the bus can be in accordance with any of a variety of bus protocols such as I EEE 1394 protocols or Consumer Electronics Bus, above mentioned. The data communicated via bus 130 may include audio and video data. For example, a satellite receiver that receives a digital video signal could transfer digital data and video via bus 130 to a digital tape recorder (DTR) for recording. Device 1 00 includes bus interface unit 1 02 to connect device 1 00 to bus 1 30. Bus interface 1 02 includes suitable physical equipment to receive data from bus 1 30 and to transmit data on the bus 1 30. For example, the interface 1 02 may include registers or buffer memory to receive and temporarily store data from the bus 130 until the device 1 00 is ready to process the data, and to store data until it is ready for transmission in the bus 1 30. Interface 102 is controlled by the control microcomputer (μC) 1 04. The term "microcomputer" is intended to represent various devices including, but not limited to, devices such as microprocessors, microcomputers, controllers, and computers. control that are implemented using one or more integrated circuits and / or discrete components. The microcomputer 1 04 controls the passage of data between the interface 102 and other units in the device 100 such as signal processing units (not shown in Figure 1 A). For example, if the device 100 is a digital tape recorder and the bus interface unit 102 is receiving digital video data for recording, the microcomputer 104 ensures that the interface 102 passes audio and video data to the video processing circuits. signals on device 1 00 so that recording occurs as intended. Also, the microcomputer 104 controls the interface such that the interface 1 02 com unique data a and bus 1 30 in accordance with the appropriate bus protocol. The microcomputer 1 04 implements the desired bus protocol under the control of a control program and data stored in the memory 106. The memory 106 may include various types of memory including random access memory, read-only memory, EEPROM, and hard drive or other types of storage. The control program may include routines for controlling the functions of the bus interface 102 such as activating and deactivating communication, coordinating the bus operations with other operations on the device 100 and formatting data for bus communication. One aspect of controlling the bus interface 102 provided by the microcomputer 104 is to determine how to resolve conflicts of requests for the use of resources in the device 100. For example, the situation in which the device 1 10 is a cable box is considered. , the device 120 in a DSS satellite receiver and the unit 100 is a video tape recorder (VTR). A user can program the video tape recorder 100 to start recording a particular program via cable box 1 10 at a specific time. A conflicting command causes the DSS unit 120 to attempt to access the video tape recorder 100 while it is recording the program via cable box 1 10. Conventional systems resolve the described program by either ignoring the access attempt of the DSS 120 unit or by notifying the user that the video tape recorder 100 is not available. In accordance with one aspect of the invention, the system shown in Figure 1A implements a coupling manager to resolve resource conflicts in a manner described in detail below. In the exemplary embodiment shown in Figure 1A, the microcomputer 104 operates under the control of a "coupling manager" routine included in the bus control program to ensure that the device 100 resolves conflicts in a manner described in detail to continuation. A routine of "coupling mechanism" 1070 is also included in the bus control program; the operation of the coupling mechanism 1070 is described in the detailed description of Figure 2 below. The coupling manager provides the establishment of communication relations, or coupling conditions, between devices coupled to the bus 130 and determine under what conditions these relationships are modified. The docking manager operation includes parameters that are stored in a portion 107 of the memory 106 and will be described in more detail below. The parameters associated with a coupling relationship that are involved in resolving a conflict are stored in the region of the coupling manager 107 of the memory 106 in Figure 1 A. Three of these parameters are persistence, coupled address, and decoupling condition. Figure 1 B illustrates these three parameters stored as three different inputs 1071, 1072, and 1073 in the memory region 107. It should be noted that, although not shown in Figure 1 A, devices 1 10 and 120 each include functions that provide functionality similar to that described herein as provided by units 102, 104, 106 and 107 in unit 100. The structure in these units 1 10 and 120 may be similar to that shown in device 100, but a Similar functionality can be produced using other configurations as well. As an example of the operation of the coupling manager, the conflict example described above should be considered. Using the docking manager, recording a program from the cable box 110 using the video tape recorder 100 involves the bus control capability of the cable box 1 10 which transmits a request for coupling to the video tape recorder 100. The coupling request asks the video tape recorder 100 to establish a relationship, ie to establish a coupled condition, with the cable box 110. The microcomputer 104 receives the coupling request via the bus interface unit 102. and determines whether the video tape recorder 100 is already coupled to another device or not. If it is not, that is, the video tape recorder is available for coupling, the video tape recorder 100 sends a reply to the cable box 1 10 indicating that the coupling has been established in the coupling mechanism 1070. The recording of the desired program of the cable box 1 10 is carried out and the coupling relationship prevents the interruption of the recording except under certain conditions that are defined by parameters such as persistence and decoupling condition described above and in more detail to Then, they are associated with the coupling relationship. The value of these parameters is set by the coupling device, ie the unit that initiates the coupling condition (the cable box 1 10 in the present example) and are transferred and stored in the coupling device (the tape recorder). video in the present example) in respective portions of the region 107 of the memory 106. When the DSS unit 120 requires the use of the video tape recorder 100, the capability of the coupling manager in the DSS unit 120 sends a coupling request to the video tape recorder 100. As there is a previously existing relationship between the video tape recorder 100 and the cable box 1 10, the coupling manager in the video tape recorder 100 processes the request for coupling the video tape recorder 100. DSS unit 120 according to the parameters of the existing coupling condition and stored in the video tape recorder 100 and resolves the conflicting request of the below described. Figure 2 illustrates the operation of the coupling mechanism 1070, which cooperates with the coupling manager 107. The coupling manager 107 handles the relationships or couplings that a "master device" initiates. The coupling mechanism 1070 carries out the coupling of the two devices together. When a master device wishes to initiate a coupling, sends a command to the slave device. A device may be in one of several states that involve coupling control. Four states of this type, decoupled, coupled, pending decoupling request, and change coupling flag, are illustrated by ovals 210, 220, 230, and 240 in Figure 2. Transitions between states are illustrated by lines connecting the ovals As shown in the upper part of Figure 2, a coupling manager can receive requests including coupling and decoupling requests. As shown in the lower part of Figure 2, a coupling mechanism can produce responses such as "granting_coupling" or "coupling_in_use" in response to requests. Also, a coupling mechanism can produce a decoupling request and a restart / device error indication. As shown in Figure 2, the system changes from the decoupled state 210 to the coupled state 220 in response to a coupling request and issues a coupling-grant response. A return to the decoupled state 210 of the coupled state 220 occurs in response to a coupling that is being released. Coupling release occurs through transitions through states 230 and 240. In response to a decoupling request, the system moves from state 220 to pending decoupling request status 230. In state 230, the system processes such parameters as the persistence parameter and the decoupling condition to determine whether a coupling should be released. If the assembly will not be dissolved, a coupling_in_use message is sent and the system returns to the coupled state 220. If the coupling can be dissolved, a decoupling message is issued and the system changes to the state 240 in which the address coupled or pointing The coupling is changed to that of the device that is now requesting a coupling. Subsequently, the system changes to the coupled state 220 and issues a message grant_couplement. The operation of the coupling manager 107 and the coupling mechanism 1070 under various conditions, i.e. various types of transactions between devices, is illustrated in Figures 3 to 7. In Figure 3, a device B is not coupled and, in In response to a coupling request from device A, device B establishes a coupling with device A. In FIG. 4, device B is coupled to device C in response to a pre-coupling request and receives a request for conflicting coupling from device A. The persistence parameter is set to 0 meaning that device B does not need to request decoupling approval from device C before decoupling and reconnecting with device A. device B should only evaluate the condition parameter decoupling request to determine whether or not to dissolve the coupling with device C. In Figure 5, device B is ac opted to device C in response to a pre-coupling request from device C and the persistence parameter is set to 1. The device B sends a decoupling request, also called a "disinherit coupling" request, to the device C. The coupling manager in the device C determines whether to release the coupling or not. In Figure 4, device C decides to maintain the coupling and sends a "resource in use" message that is retransmitted to device A by device B. Figure 6 shows a transaction similar to that of Figure 4 (ie, persistence = 1) except that the device C responds to the request for coupling of the device A by dissolving the coupling of the device C with the device B. Thus, the device C sends a decoupling message to the device B and the device B subsequently grants a coupling with device A. Figure 7 shows a transaction in which device B is coupled to device C with persistence equal to 0 and device A calls all coupling managers indicating the desire of device A to couple with device B. Device C notifies device A that device C will release its coupling with device B. So, device A sends a request for coupling to device B and, because the persistence parameter is set to 0, device B is coupled to device A and can send a message to device C instructing device C to dissolve the device. Coupling with the device B. Additionably within the scope of the present invention, only the master or coupling devices require coupling managers 107 and the slave or dockable devices only employ coupling mechanisms 1070. The operation of a system of this it is similar to the system described here. Further details on the aspect of the coupling manager of the invention, including the functions of the coupling manager in addition to those already described, are described below. For convenience only, the following detailed description includes aspects based on the use of the CAL Programming Language.; however, it should be noted that any suitable alternative programming language can replace it. Examples of Applications that use Coupling The following describes an application in addition to those already described in which a coupling relationship is required. In a first example, a device ("device A") wishes to download several data packets in a remote device ("device B"). Device A does not want the data placed in device B to be overwritten until the download is complete. Normally, this function requires a Segmented Network Service on both devices. However, in accordance with this invention, device A establishes a coupling time relationship which ensures that it is the only device capable of writing to device B. After the data transfer, the device A terminates the coupling relationship and, "uncouples" the device B. In a second example, an external device, such as a cable box, executes a program timer event. The cable box "couples" the transport mechanism of the video cassette recorder. This keeps the video cassette recorder in recording mode until the session ends or an override condition occurs. The cable box sends a Stop command to the cassette recorder and undocks the cassette recorder at the end of the event. In a third example, a device wishes to display a display message for a period of time. The device couples the screen to itself and sends the relevant deployment information. This deployment device displays the information for a period of time. The coupled device is decoupled either by the coupling device itself or by a conditioning event, for example the passage of a lapse of time. A special form of coupling, "listening", is also implemented. Controlling and interoperating with various devices requires the ability to know their status. A device that contains listening capability discriminates between transmission reports sent by a particular group of devices, for example, devices placed in a home. For example, the status change information is automatically sent from one device to another. A video cassette recorder updates its motion mode status to a deployment device or a temperature sensor sends an update to an environmental administrator. There are two problems with this approach. The first problem is to determine if the report should go. The problem of the partner is that the receiving device determines what information is important for its function. This occurs where there are multiple instances of the same type of device, such as thermostats or safety sensors, informing several subsystems in the same house. It is necessary to discriminate between sources of information. The listening function performs this function. There are several listening applications. Some are more dynamic than others. Environmental control is an example of a stable (static) listening application. In such a system, the listening functions are relatively static after an initial set-up function. These systems require a reliable and inexpensive means of listening. Issues such as security and special access are important. The configuration of the system occurs in the installation and does not change very frequently. This is in great contrast to an audio - video system. An audio-video system is very dynamic. The devices are installed and removed relatively frequently. The video source and the request function make the configuration of the systems change quickly and regularly. Playback, Recording, Deployment menu, and Player Events require changes in listening and coupling the device. It is necessary to change the device from the listening source of the video cassette recorder to a direct transmission satellite device in an instant. There is also a lot of listening between devices. A television receiver can be listening to a device, an environmental system, for deployment while a cable box is listening to the status of a video cassette recorder. There are several levels of coupling and listening desired. In many cases, an application requires only a device-level coupling. However, there are cases in which it is desirable to dock at an object level. (That is, a device can be formed by more than one object, for example a device can have separate controllable functions in the device itself). A situation of this type is a video cassette recorder application where it may be desirable to couple the transport mechanism while allowing other devices to edit or add timer events. Also, while it is desirable to couple the deployment object to a television receiver to ensure proper deployment, it is not desirable to couple the ability of the devices to respond to other communications.

The coupling attribute has relational, conditioning and inherited characteristics. An example of a conditioning coupling feature is when an object is already coupled by a device. Decoupled objects can be attached; however, the device may not be dockable. In a situation of this type, the device is dockable only by the same device that coupled to one of its objects. The inherited coupling infers that all objects in a device inherit the object's docked state. The Coupling Manager All devices that want to attach other devices must have a "Coupling Manager" that keeps track of all active links initiated by the device and is responsible for coupling and uncoupling remote devices. A structure of a coupling manager of this type, implemented in CAL is provided below.

The parameters outlined above are described below. 1 . Definition of the Connection_Signifier Each record of the variable (IV) of the memory_block instance of the Data Memory is a signal to the attached device, which resides remotely in the network. The data of the coupling_mark includes three fields: (1) < Address_of_Red_of_Device >; (2) < Identification_of_Concocted_Context >; and (3) < Identification_of_Abject_Object > . Fields left blank are considered as null. The ___ Device_Red_Address field is the network address of the attached device. In a Consumer Electronics Bus application, the MAC address is used as the network address. The field of Identification_of_Contracted_Context contains two bytes. The first byte is a Context number or the "DE" context wildcard. The wild card DE implies that the coupling corresponds to all instances of the same context in the device. The second byte is the_dentification_of_Class_of_Context. The remaining bytes are null. The field of Identification_of_Object_Assorted is divided into two bytes. The first bytes is either the Number_of_Object or the wildcard of Object "00". When the object wildcard is used, the second byte is the Object_Class. When the wildcard is not used, the second byte is null. This allows the coupling of all objects in the same Object Class. 2. Definition of Decoupling Message The coupled device sends a decoupling message to the Coupling Manager. There are three decoupling messages defined: Decouple_Device; (2) Decouple_Context; and (3) Uncouple Object. The decoupling message is sent using a Macro, U4.

The macro U4 contains two argument fields. The first argument contains the Address_of_Red_of_Device. The second argument contains the context and object information. The macro prototype is "<context_identification> < object_identification> U4 < data sheet > < escape tab > < Di_De_Red_De_De_Depositivo > Fx Data Sheet > < data size > > escape tab > < Number_of_Context > < ldentification_of_Coase_of_Context > < Objectification_of_Object > < Calse_de_Objeto > "When a context is coupled, the Number_of_Context and the_dentification_of_Class_of_Context are placed in the second argument field, (the_dentification_of_Object and the Class_of_Object are not provided.) The object information is null.When an object is coupled, the Number_of_Context , the Identification_of_Class_of_Context, the Identification_of_Object and the Class_of_Object are also provided in the second element: a) Device Decoupling Message The Disconnect_Device message must contain the <Device_Red_Address> of the docked device The second argument is not contained in the message. "00 04 55 34 F5 F5 F4 34 F6 < Address_of_Red_of_Device > F5"Examples of Coupling Signaling Vectors in the Coupling Administrator Object Coupling Devices The ability to attach a device depends on the couplings previously made. The coupling of the device requires that all other couplings be canceled. The implementation of the coupling uses the variables (IV) in the following table. The variable Attachment_Address must be present in all implementations. The default persistence value is "0". The following subsections contain a detailed explanation of the variables. a) Persistence Variable The Persistence Variable influences the uncoupling behavior of the device. Currently there are three defined persistence levels: (0) Loose; (1) Adjusted; and (2) Listen. The persistence variable has a default value of Loose. When a device invests in a decoupled state, you must set the persistence to the default value. A loose coupling level occurs when the persistence level is "0". Loose coupling causes a device to discriminate between devices that try to control it. However, the coupling is loose. This means that the coupled device can grant the request for a new coupling with confidence that the previous coupling device must dissolve the previously existing coupling. When a coupling level is loose, the coupling device must automatically release the coupling on request. This produces a rapid dissolution of the previous couplings and the replacement of new couplings. When a loose coupled device receives a request to change the Attachment_Address, it returns a completion message and sends a notification to the pre-coupling device to dissolve the coupling. Loose coupling infers that any device can change the Attachment_Address Variable. The adjusted coupling occurs when the persistence field is set to "1"; this allows only the coupling device to change or grant permission to change the Attachment_Address Variable. This is useful when a third device wishes to create a coupling with the coupled device. In this case, the third device consults the coupled device. The coupled device sends a decoupling message to the Coupling Manager Object of the coupling device. The coupling device can either produce its coupling or not produce its coupling; that is, the coupling device returns a Completed Tab, FE, when it dissolves the previous coupling. Otherwise, the Coupling Manager returns an FD Tab with error-resource in the code (u) of use. Setting the Persistence Variable to "2" produces a form of coupling called listening (as described above). When listening, the "coupled" device joins another device. A device can implement several levels of persistence, depending on its application. b) Key_Input Variable The Key_Input Variable acts as a simple key on a coupled device. This Variable activates access to protected variables. This option can protect private functions, such as special diagnostics and establishment operations, from general access. It also allows a device to discriminate between sources in the Listen application. There are two uses of the Key_Input Variable. The first is when an adjusted coupling is established, (persistence = 1). The coupling device provides a Data_Key_Input value of data type that grants access to the private areas of the device. This value is defined, for explanation purposes, as the "coupling_key". The second use is in a listening application (persistence = 2). The Listening Function uses the Key_Input Variable as an additional discriminator. An explanation of this Key_Input function is presented later in this document.

In addition to the first level of privacy, a manufacturer can choose to make the Key_Input Variable a protected variable that requires authentication. This separates the matter from special access and authentication. The Key_Input Variable is inactive when a device is decoupled or the persistence is not set to "loose". The default value of the key_input value is "null". When a device is decoupled or the persistence level is changed, the Key_Input Variable is inverted to the default value. This means that only the coupling device is able to supply or read a value of Key_Input Variable. This allows only one device to access private functions or data. Depending on the application, the "coupling_key" can be a fixed key, placed in the ROM, or a key that can be written, such as a "confidence key". Normally, there is only one valid value of Key_Input; however, there may be multiple valid values of Key_Input Variable. A manufacturer can select to make the Variable of the coupling_key be writable. Protected devices e become private again by setting the Key_Input Variable as an invalid entry (for example, the logical length is 0) or a false value, by disarming the coupling, or by changing the coupling persistence < > 1 . c) Attachment_Address Variable The Attach_Address Variable is a data type variable and the network address that docked the device. In a Consumer Electronics Bus application, the MAC address is used as the network address. A coupling device initiates a coupling with a device when it writes its network address to the appropriate Variable of Address_of_Ackup. Once a coupling is in place by setting the Attach_Address Variable to an invalid address (that is, the logical length is 0) it disarms the coupling. A coupling request to a device that does not support collation produces an Error Return Variable - Invalid, d) Coupling Condition Variable A third variable is the Coupling Condition Variable that allows the user to specify a condition that automatically dissolves a coupling. The decoupling condition can use the Variables found in the device (this is similar to the Event Manager Object). The Variable of the Decoupling of Decoupling contains a Boolean expression that defines the condi- tion of decoupling for the device. The Boolean expression is a CA L expression, as defined in the CA L grammar. This pro- gram is waiting for a condi- tion in the device to occur, such as expiration of the timer or crossing of the minimum level. The device dissolves the coupling in the specified decoupling condition. It should be noted that the decoupling condition is in the coupled device. The level of persistence can be either loose or tight. A condition is loaded in the Disconnect_Condition using the method of establishing Matrix. In this case, the data that is being loaded is the actual program of CAL conditions. This program includes the condition of monitoring what will cause the decoupling action. As in the Event Manager Object, there are two slight differences in the CAL grammar so that the Decoupling_Condition Variable operates correctly. The first difference is to identify the instance variables that will be monitored. Instead of a simple Variable identifier, the con and location of the Variable object must be provided. For example, instead of testing (current_value> max_value), the_Connection_Condition would try (Audio Con, Volume Control, current_value> Audio Con, Volume Control, max_value). By requiring all bytes, the statement can be analyzed correctly. The Boolean expression contained in Condition of Disconnection allows to evaluate two relations at most. For example, the Clock Object could be decoupled when the time equals 12 or the month is equal to 6. The first Variable in the Boolean expression is the reported value. Together with the standard relations operators, an additional operator, the DELTA operator, is defined. Note that when the Decoupling_Condition Variable is written (using the Matrix Setting Method) the object must verify the validity of the condition that the Variable is having. If the condition is invalid, an Error-Bad Argument Type (12) is returned and the Disconnection_Condition does not occur. Implementation of Coupling A device is coupled by setting the Attachment_Address Variable to a valid destination address using the method of establishing Matrix. In the case of a Consumer Electronics Bus application, the network address is composed of the Unit address and the Start Code that appear in order of the most significant bit (MSB), least significant bit (LSB). An example of a coupling message using a Unit Code 0034, Start Code 001A, produces the following message: < context > < object > 46471 Ffd Ff434 Ff6003400 1A (< context > < object > set Matrix 'GA' < DEL < < DEL > < DATOS > 34 < ESCAPE > 0034001A) Setting a Variable of Address_of_Am object to an invalid address (that is, logical length is 0) decouples it. (< context > <object> set Matrix 'GA' <DEL> <DATA> 34 <ESCAPE> An Error Variable - Invalid is returned when this function does not it is supported. 1 . Implementation of the Object Coupling The coupling to the Object level is carried out by fixing the coupling mechanism in the individual Object. 2. Implementation of the Context Coupling The coupling of the object level can be extended to contexts. The coupling to the context level is done by setting the coupling mechanism in the Context Control Object. Setting the Variable of the AttachmentAddress to a valid value couples the context. The objects exemplified in the context inherit the same Connection_Address. (This only applies when persistence < > 2). If an object in the context is already coupled, the context can not be coupled unless the value of the Variable of the Attachment_Address is the same as the value of Context_Action_Address. The context coupling is initiated by typing the network address of the coupling device in the Context_About_Connect Variable placed in the Context Control Object. < context_identification > 01 01 46 47 54 F5 F5 F4 34 F6 < Connection_Address > The Variables of Persistence_of_Context, Input_of_Key_of_Context, and Condition_of_Connection_of_Context inherit its Persistence behavior from Object Variables, Key_Input, Attach_Address, and Decipher_Connect, respectively. 3. Implementing Device Coupling Coupling to the device level is carried out by fixing the coupling mechanism of the device on the Node Control Object. The Node Control Object may have its own individual Object coupling mechanism. The device level coupling variables are The Variables Persistence_of_Device, In Positive_Text_Trace, Device_Adaptation_Direction, and Device_Disclosure_Condition inherit its behavior from the Persistence Object Variables, Key_Input, Connection_Address, and Condition of Disengagement, respectively. The coupling of the device is started by writing the network address of the coupling device in the Address_Application_Adapter Variable. 00 01 46 54 F5 F5 F4 34 F6 <; Acceptance_Address > Coupling scenarios For demonstration purposes, the docking device is the device that you want to attach another device. The coupled device is the device to be coupled. The coupling request can be made either to the device to be coupled or to the coupling manager having the coupling. Under normal conditions, a coupling request is made by trying to write a new address in the Attachment_Address Variable. The request can be either direct or conditional, a) Direct Coupling Request An example of a coupling message using a Unit Code 0034, Start Code 001 A, produces the following message: < context > < object > 46 4741 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1 A (<context> <object> set Matrix 'G' <DEL>> DEL <DATA>> '4' <ESCAPE > 0034 001 A) The device must determine if it is dockable. If the device, object, context is not coupled, a completed FE file is returned. The coupling device places the coupling flag on the coupling manager object. b) Conditional Object Coupling Request An example of a coupling message using a Unit Code 0034, Start Code 001A, produces the following message: < context > < object > 56 47 F7 < context > < object > 46 4741 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1 A EB 44 47 F8 (< context > < object > l (SI "G" < START > < context > < object > set Matrix 'G * < DEL < DEL > DEL <DATA> >' 4 '< ESCAPE > 0034 001 A < YES NO > set Matrix "G" < FI N >) If the matrix "G" is not in use the device is docked, otherwise it will not dock the device.This method is used with resource coupling.If the device is in use, the requesting device can request "ask" the coupling device to yield the coupling by sending a transmission message c) Using the ACOPLAM macro I ENTO U2 The ACOPLAM I ENTO U2 macro is used to couple context and objects. The Macro message contains the identification of the Macro followed by the list of arguments. There are two necessary arguments: (1) Dírección_de_Acoplamiento; and (2) persistence. A list of arguments is considered null if it is not full. After establishing a coupling, the Key_Input_Value and the_Docking_Condition are updated. < context_identification > < object_dentification > "U 2" < data sheet > < data size > < escape tab > < coupling_address > F5 < persistence > F5 < Entry_of_Key > Example for the Macro CAL message to fit a context 1 1: "1 1 01 1 55U 322 F4 34 F6 OF 32 23 F5 01" The argument 0Ff32 2334 is the coupling direction, the persistence is set to 1. At this point, the coupling device can send Variable Data Input_Key and Data Variable of Disconnect_Condition. When the Attachment_Address is not provided it is assumed to be the source address of the Macro Message. "1 1 01 55 32 F5 F5 01" Request for Coupling Release to Coupling Master (1) using DES H ER EDAR (option 1) If the object is coupled, at either the object, context or device level, then it will request that the device that prevents the coupling leaves its coupling. The message is sent to Object of the Coupling Administrator: < Universal context > < Object of the Coupling Manager > • disinherit > coupling signal (6C) > F4 [number of bytes] F6 < device_address > < context_identification > < object > disinherit the link with < d ispositive > < context > < object > Context_identification includes the number_of_context if it is not AO. If it is AO, the context number can optionally be included. (2) Using the Macro DISACOPLAM I ENTO U41 (option 21) The DECOUPLING Macro U 14 is sent to the Object of the EVENT Administrator. The macro is compared to the desired coupling flag and requested to be removed. If there is a present match then the coupling manager either grants the request or denies the request. If the coupling device can not be found, the coupled device dissolves the coupling. The details are shown in section 2.1.2. Listening Implementation The listening function allows a device to discriminate between transmission messages that contain status information. The listening function is a special application of the coupling function. In listening mode, the object does not inherit the coupling state of the context or device. (This is necessary for the listening function to be performed correctly when a device or context is attached). In Listening, a device joins itself to another device. This means that a device can set its own Variable of AttachmentAddress. The Variable of Connection_Address is either read-only or read / write. The write option is actually a loose type of coupling. The persistence variable is set to "2". The Key Input Variable acts as a special access discriminant. The following table contains the list of the Listening Variable.

When the Attach_Address is a read-only variable, the device sets its own docking address. When the Coupling Direction is set externally, the coupling device does not place a coupling flag in its Coupling Manager. There are three different listening implementations. The first method uses the source network address to grant access to the listener object. The object discriminates in favor of the source device address that corresponds to the Variable of Address_of_Acoplam. In this case, the message is written to the appropriate Instantaneous Variable. The second and third implementations use the Key_Input device. This implementation requires a macro message. The macro message, L1, is used to deliver the data and the value of Key_Input simultaneously. The listening device verifies that the macro is from the correct source address and that the value Input_of_Text provided matches the desired value. 1 . Multiple Listening Implementations There are times when a listening object may wish to listen to all sources of transmission without discrimination. A situation of this kind occurs when a fire detector transmission is detecting a fire. It transmits the information to the network. A listening device wants to hear all possible sources that would report a fire. In a general application, the multi-source listening application is implemented allowing a device to receive the status of any device (sensor). This is indicated by setting the Attachment_Address Variable to a trassion address. In a Consumer Electronics Bus application, the listening discrimination is set either to all the Unit_Departments in a particular Home Code or to all addresses in the network. The zone or author source addresses of the weapon are included in the message; This can be extracted from the source_address field or in a status vector contained in the message. 2. Listening via Key_Input and Link_Address From this man, the value of key_of_coupling is converted into a selector value that allows a device to discriminate between individual context and objects. For example, in the context of time, the time type identifier may be provided in the Macro Message. This value is verified for the type of time desired. If a device has multiple instances of an informed context, the device may include the context number in the Key_Input field. The receiving node verifies the incoming context and verifies that it is the one of interest. < context_identification > < object_dentification > 53 331 F4 < data size > < escape tab > 5 < Connection_Address > F5 < data sheet > < escape tab > > Entry_of_Key > F5 < Message from List_of_Arguments > In Listening, a device joins itself to another device. In the case of listening, a device can set its own Variable of Address_of_Mallocation. The Variable of Connection_Address can be read-only or read / write. 3. Listening via Key_Entry Listening can also be achieved by setting the Attachment_Address to "00 00 00 00". In this case, the only discriminant is the value of Key_Input. This allows a discrim ine object based on an access key. This is done as follows: < context_identification > < Identification_of_Object > 63 31 F5 00 00 00 00 F5 < data sheet > < data size > < escape tab > < Entry_of_Key > F5 < List_of_Argument > When the Connection_Address is read-only, the device only sets its own address. When an Attachment_Address Variable is R / W, the coupling is loose. The coupling device does not place a coupling flag in its Coupling Manager. < context_identification > < Identification_of_Object > L1 < data sheet > < data size > < escape tab > < Connection_Address > F5 F5 < message > There are some cases where a single discriminant is desired between multiple contexts or objects in a single device. An example is a temperature sensing device that contains multiple sensors. It may be desirable to attach each sensor to a corresponding listening object. This is done using the keyboard_input approach where if the_key_input = null there is no discrimination. When a value is set for the Key_Input, the listener requires the appropriate value of Key_Input before updating the object. Example: The listener variable has a discriminant, such as the number of keyboard_input, which allows the user to set a discriminator. The data and the discriminant are sent to the Listening F5 DATA of the macro_dentification_tend input. If the Key_Input is not provided, the discriminator is the network address. Although the invention has been described in detail with respect to numerous modalities thereof, it will be evident from the reading and understanding of the above, that numerous modifications to the described modality will occur to those skilled in the art and it is intended that said modifications are within the scope of the appended claims.

Claims (12)

1. REVIVIENDS 1. A device (B) comprising: (a) communication means (102) with at least a second device (A) interconnected by a network bus (130) thus creating a relationship between said first device and such second device, said communication means is capable of receiving query data from a third device; (b) first means for storing (106) information pertaining to the persistence of said relationship; (c) second means for storing (106) information pertaining to a condition for terminating said relationship; (d) a means for controlling (104) operating modes of said device in response to control data of said second device, such control means being able to process said persistence information in response to said inquiry and completion data said relationship in response to one of the termination condition and persistence information processed. The device mentioned in claim 1, wherein said processed persistence information comprises one of a first state wherein said relationship is terminated in response to said query data and a second state wherein said relationship is maintained independently of such query data. 3. The device mentioned in claim 2, wherein terminating said relationship in response to said inquiry data comprises forming a new relationship between the device and said third device. The device mentioned in claim 3, wherein said control means is capable of regrouping said second device, in response to receiving such query data to obtain permission to terminate said relationship. The device mentioned in claim 4, wherein said control means is additionally capable of monitoring the state of said second device. The device mentioned in claim 5, wherein said control means is additionally capable of activating said second device for modifying information contained in said consumer electronic device. The device mentioned in claim 1, wherein said predetermined condition relates to one of said relationship between said consumer electronic device and said second device and an internal condition of said device. 8. A method for controlling an electronic device from a high connected network bus, the method comprises: (a) communicating with at least one second device interconnected by a network bus, thus creating a relationship between such a device consumer electronics and the said second device; (b) controlling operating modes of said consumer electronic device, at least one operating mode is controllable by said second device in such a network bus, thus creating a relationship between such electronic consumer device and said second device; (c) storing information about the persistence of said relationship and a predetermined condition pertaining to a condition for terminating such a relationship; (d) receiving query data from a third device; (e) processing said information pertaining to such meaning of said relationship and such inquiry data; and (f) terminate said relationship in response to one of said termination and processing condition. The method of claim 8, wherein the step of terminating further comprises creating a new relationship between said consumer electronic device and said third device. The method of claim 8, wherein the step of terminating said relationship is performed in response to the step of regrouping said second device to obtain permission to terminate said relationship. eleven . The method of claim 10, further comprising the step of monitoring the state of said second device. The method of claim 1, further comprising the step of activating said second device to modify information contained in such consumer electronic device.RESU MEN A device that has means to control operating modes of the process control of the device and query data received from the second and third electronic devices to manage the communication relationships between these devices. The invention includes a system for communication between multiple electronic devices, such as consumer electronic devices and the like, via interconnections such as digital data buses.