Method for operating a communications network in a power-saving mode

[0001] Conventional technology The present invention starts with a method of driving a communication network in a power saving mode. [0002] From the IEEE standard 1394 [1], the Sylalbus system is known. In this silal bus system, various different terminals are connected via a 4-6 core cable or an optical waveguide. At least one node here is configured so that it can take on additional management functions for the network (bus management). [0003] In addition to the above standards, there is also a bus-independent extension, which is specified as HAVi (Home Audio Video interoperability) [2]. This HAVi specification specifically describes remote control of equipment using a resource manager, which occupies resources (equipment) on demand and releases them again. [0004] The HAVi specification also describes a distributed model. In this distributed model, equipment is controlled via a control module, the so-called "device control module (DCM)". This DCM is executed as a software element on a device that exerts a control function on other devices. Here, each DCM is dedicated to a predetermined device or device class. [0005] Advantages of the invention The method according to claim 1 realizes effective network-wide coordination of the current saving state. This allows this method to be used in vehicles where low current consumption during hibernation is a critical requirement. [0006] The dependent claims describe an advantageous embodiment of this method. [0007] Drawing Examples of the present invention will be described with reference to the drawings. [0008] FIG. 1 is a schematic diagram showing a network configuration of a bus system. [0009] FIG. 2 is a schematic diagram showing a functional diagram for controlling the power saving mode. [0010] Description of Examples The present invention will be described based on a serial bus system according to the IEEE standard 1394 [1]. Here, the extension according to the HAVi specification [2] is also used as a reference. Prior to the original description of the present invention, a description will be given to understand the IEEE standard 1394 and the HAVi specification. Further, some concepts will be explained. [0011] Various terminals (nodes) are connected via a 4-6-core cable or an optical waveguide in Fig. 1. Here the nodes can be selectively configured as end pieces (leaves) 100 or relay nodes (branches) 200,300. The top node is called the root. By using various node types, it is possible to construct an appropriate topology of the network. Here, the leaf receives the information packet and processes it if the target address of the packet matches a unique one. The branch additionally has to send every packet it receives on one port to every other port. [0012] With IEEE1394, the network is automatically configured. That is, after switching on or resetting, all nodes send multiple selected pieces of information about themselves to the network. This information is received by all nodes. Here, one node is configured so that it can additionally take on the management function (bus management) for the network. For this purpose, this node collects all the information of other nodes, processes it, and stores it appropriately internally. If more than one node has bus management capabilities, there is a way to compete, from which one node becomes the winner and takes on bus management. [0013] In addition to the methods described in the IEEE1394 specification, there are also bus-independent extended HAVis. This extension is suitable for use with IEEE1394-networks. In particular, the HAVi specification states that the device can be remotely controlled from each other point in the network. A distributed model is described for this purpose, in which device control is performed via a control module, the so-called "device control module (DCM)". This DCM is executed as a software element on a device that intends to exert a control function on other devices. Here, the DCM is dedicated to a predetermined device or device class. Another group of software elements is the "functional component module", each of which can be hierarchically placed under the DCM to control some of the dedicated functions of the device. [0014] The HAVi-components used in connection with the present invention are described below: HAVi is based on the concept of modules for distributed systems. Here, the individual modules are network elements, especially software elements. All network elements in the system are uniformly addressed. In most cases, network elements can be centralized or distributed. That is, it may be executed by only one entity of a predetermined software element (for example, stream manager), or this kind of entity may be executed within each device. [0015] Here the following network elements are provided in the system: Stream Manager: The Stream Manager SM is used to form, disconnect and manage connections between software elements and / or equipment. This stream manager is configured as a distributed system like a registry. Here a special instruction is used to obtain the state of all SMs or the state of one given SM. [0016] Event Manager: The event manager carries notifications about state changes in the system to communication participants. [0017] Registry: The registry contains information about each software element and each available device available within each network. Here, information about individual software elements is stored in the attributes. It is possible to add additional attributes to the previously defined attributes. The registry configuration is a distributed system. That is, each device contains a part of the entire registry. But you can also keep this in the center. This is not visible for access to the registry. This is because different entities in the registry in the network exchange requested information automatically in some cases. [0018] Resource Manager: The resource manager performs the occupancy and release of resources (equipment, software elements) and the planned process (eg VCR shooting). ) and remembers ). [0019] DCM Manager: The DCM Manager is responsible for installing and uninstalling DCM under the appropriate equipment. [0020] Device Control Module: A device control module DCM is a software element that combines one or more FCMs into a single device drive. [0021] [0021] Functional control module: The functional control module FCM is a software element that drives and controls the functional units of a device (eg, a CD-track or UKW-tuner). Here, the DCM consists of the basic functions common to all DCMs and the FCM dedicated to the equipment. [0022] Each such module or each module required within the device constitutes a unified application interface. Such a unified interface provides interoperability between the application and the equipment of various manufacturers (interoperability API). [0023] The method according to the invention is used under a system based on the HaVi standard [3]. A power manager element (hereinafter referred to as local power saving mode control unit 3) is added to the network element described there. The local power saving mode control unit is responsible for the local management of the power (power saving) -mode. The power manager entity, which exists in the entire network, is defined as the central unit 2 when the system is initialized to the power master, thereby providing network-wide coordination of the power saving state of the network elements. Central unit 2 has different information (eg Busaktivitaet, battery status, ignition) Make decisions about changes in the power saving mode of one or more or all devices in the network based on (on / off). When the driver leaves his car, the ignition is switched off and the bus activity is almost zero. The central unit evaluates to change such criteria to power saving mode. To this end, central unit 2 sends the corresponding command to selected (single cast, multicast) or all (broadcast) equipment / network elements in the network. When the central unit 2 internally determines that all the devices will be transferred to the power saving state, the central unit first sends a notice regarding the standby state change in the network during normal drive. Upon receiving such a notice, the local power saving mode control unit 3 checks whether this switch can be performed or whether the activity (user or resource) still exists in the device. If the device agrees to the change of state, the power saving mode control unit 3 of this device positively acknowledges this notice (best aetigt). If the device does not agree to the change of state, the power saving mode control unit of this device negatively acknowledges and responds to this notice. After a positive acknowledgment, it is particularly advantageous that the device no longer allows a new start of activity and does not interfere with further progress. If the acknowledgment is negative, the device additionally conveys in the response which part of the device (software element) is still active. This makes it possible to detect a device that has failed or malfunctions. [0024] After a positive acknowledgment of all devices in the network, central unit 2 requests to switch to power saving mode. Such a call can still be rejected by the power saving mode control unit 3 in the device, thereby interrupting the state change. If not, the device changes state as instructed. [0025] In addition to such cooperative methods (kooperativen Verfahren), there are non-cooperative methods (unkooperatives Verfahren) for exceptions. In this non-cooperative method, central unit 2 sends a "Force" -command. This in particular means a forced change of state due to a special notice (Kennzeichung). When such a command is received, the device cannot reject it and the state change should be performed at least after a set amount of time. [0026] A specific embodiment will be described below with reference to FIG. One of the devices present in the system is selected as the central unit 2 (power master) when the system is initialized. [0027] The following function calls are used to perform the above method: Status Get PowerMode (OUT Power Mode) (12) Status Set PowerMode ( IN PowerMode new PowerMode, IN RequestMode mode, OUT sequence &lt;SEID&gt; seidList) Status Change PowerMode ( IN RequestMode mode, IN boolean application, OUT boolean confirmed, OUT wstring &lt;50&gt; info) The power master (central unit 2) is based on its own information (eg bus load, ignition key position, central lock position, interior space sensor) and one or more devices in the system (possibly). Determines that (and all equipment) is no longer needed and should be transitioned to power saving mode. For this purpose, the power master inquires in which mode the network element / device 1 exists by GetPowerState12 and 13 in the local power manager (power saving mode control unit 3) in the system. [0028] The power master 2 announces the imminent switching by SetPowerMode (mode = ANNOUNCE) 14 to the local power saving mode control unit 3 of the device that should switch its own power mode. Local power manager 3 uses its own stream manager 4 (GetLocalConnectionMap15) and registry (GetElement16, 17) to determine whether resources in its own device are occupied and which resources in its own device are occupied. Inspect whether or not. [0029] Software (network) element 1 that still occupies the resource is notified of the impending power mode switch by ChangePowerMode (mode = ANNOUNCE18). In its own response (19), this software element communicates whether this switch is possible from its own point of view. If the co-operation method is negative in response, at least one such software element rejects the Power Master 2 query through its own assigned Local Power Manager 3. In this case, this process is interrupted. [0030] If the power master 2 receives a positive response to the notice (20), the power master repeats the notification SetPowerMode with mode = SET21. The device that subsequently responds switches to power mode 23 selected by its power manager 3 via notification 22. [0031] The following is an example of non-cooperative switching to power saving state: Powermaster 2 receives information that the state of the source, especially the state of charge of the battery, is critical, and all devices in the system immediately switch to power saving mode. Judge that it should be changed. The power master 2 sets the parameter mode to FORCE in the notification SetPowerMode in order to avoid the delay of the process due to the refusal of the notice as in the above example. Local power manager 3 sets mode = FORCE in ChangePowerMode on its own side. This causes all software-elements to recognize that this system is currently attenuated. In FORCE-mode, the software element does not reject the notice and must decay immediately. [0032] If the confirmation response of the notice by the power master 2 is not returned, or if the specially indicated notice (FORCE) is received, the switch to the power saving mode is performed by the power master 2 or the local power manager 3 after a predetermined time. It can also be done automatically. [0033] It is particularly advantageous for the power master to also assume the functions of the Isochronous resource manager and cycle master over the IEEE1394-bus. [0034] Alternatively, Power Manager 3 can send a positive receipt for calls with "SET" and "FORCE". This allows the Power Master 2 to check all devices to see if this has been reached and, in some cases, repeat the appropriate command. [0035] [Outside 1]<img file="JP4732673B2_D0001.tif" />[Simple explanation of drawings] FIG. 1 is a schematic diagram showing a network configuration of a bus system. FIG. 2 is a schematic diagram showing a functional diagram for power saving mode control.