WO2002015483A1

WO2002015483A1 - Resource management method

Info

Publication number: WO2002015483A1
Application number: PCT/DE2001/002280
Authority: WO
Inventors: Vasco Vollmer; Matthias Hofmann
Original assignee: Robert Bosch Gmbh
Priority date: 2000-08-11
Filing date: 2001-06-20
Publication date: 2002-02-21
Also published as: DE10040012A1

Abstract

During resource management, priorities for the request and use of the resources (100) are assigned to the resource users (200, 300). The requested resources (100) are preferably allocated to resource users or services (300) with a high priority or resources already in use by resource users (200) or services with a low priority are enabled in order to allocate them to resource users or services with a higher priority (300). Frequent confirmations of uses of resources by a user can be eliminated. The method is particularly suited for a serial bus system according to IEEE Standard 1394 and the expansion HAVi (Home Audio Video interoperability) suited therefor. The inventive method can be advantageously used in a motor vehicle.

Description

PROCESS 2UM RESOURCE MANAGEMENT

Resource Management

State of the art

The invention is based on resource management for resources that can be operated in particular on a serial bus.

A serial bus system is known from the IEEE standard 1394 [1], in which various terminal devices (nodes) are connected either via a 4-6-core cable or an optical fiber. At least one node can be designed in such a way that it can take on additional management functions for the network (bus management).

Weaving the above standard there is a sun dependent

Extension specified under the name HAVi (Home Audio Video interoperability) [2]. This HAVi specification describes in particular the remote control of devices using a resource manager, which allocates a resource (device) on request and also releases it again. Advantages of the invention

With the resource management according to claim 1, it is possible to carry out an effective and simple resource management which avoids frequent confirmation, in particular of occupancies, by a user. This resource management is therefore particularly suitable where a user should not be distracted by frequent manual inputs, preferably in motor vehicles. In the invention, priorities are assigned to the requirements and assignments of resources. Resource users or: Services with a high priority are given priority to the requested resources, or resources already used by resource users or services with a lower priority are released in order to allocate them to the resource users or services with a higher priority.

The resource management according to the invention affects functions within an existing standard, e.g. the

HaVi standard, not and can therefore be easily integrated into such a standard.

drawings

Exemplary embodiments of the invention are explained in more detail with reference to the drawings. Show it

1 shows the network topology of a bus system, FIG. 2 ^' the allocation of a free resource,

3 the transfer of an occupied resource, FIG. 4 the rejection of an transfer. Description of exemplary embodiments

The invention is explained on the basis of the serial bus system according to the IEEE standard 1394 [1], whereby also the

Extension according to the HAVi specification [2]. Before the actual explanation of the invention, the IEEE standard 1394 and the HAVi specification are discussed for better understanding.

According to FIG. 1, the various end devices (nodes) are either connected via a 4-6-core cable or an optical waveguide 1. A node can optionally be designed as an end piece (leaf) 400 or as a relay node (branch) 200, 300. The top node is called root 100. A suitable topology of the network can be set up by using the different node types. A sheet receives information packets and processes them if the target

The address of the package matches your own. A branch must also send out all packets it receives on one port on all other ports.

IEEE 1394 stipulates that the network is self-configuring, ie after switching on or after a reset, all nodes send some selected information about themselves into the network. This information is received by all nodes. A node can be designed in such a way that it can take on additional management functions for the network (bus management). To do this, it collects all the information from the other node, processes it and saves them appropriately internally. If several nodes have bus management capabilities, there is a competitive process from which one node emerges as the winner, who then takes over the bus management.

In addition to the procedures as described in the IEEE 1394 specifications, there is the bus-independent HAVi extension, which is suitable for use in an IEEE 1394 network. In particular, the remote control of devices from any other point in the network is described in the HAVi specification. For this purpose, a distributed model is described in which the devices are controlled via: Control modules, so-called "Device Control Modules (DCM)". These DCMs run as software elements on the device that want to perform control functions on another device. A DCM is specific to a specific device or device class. Another group of software elements are the "Functional Component Modules", of which several can be arranged hierarchically below a DCM and which are responsible for the control of a specific functional part of a device.

An essential requirement for such a system is the continuous handling of colliding device accesses, i. H. the handling of two or more simultaneous bending requests on one device. A distinction can be made between devices that allow more than one access, e.g. B. DAB tuners and those that only allow access, z. B. speakers. The HAVi-

The standard provides one or more resource managers 400 that have a resource (device) 100, 200, 300 Document the request and release it again. In HAVi usage, there are so-called extenders, which are software elements that request access to one or more resources. There are also clients, correspondingly these are software elements that currently have access to a resource - after a successful request, a contender becomes a client.

HAVi differentiates between so-called user

Clients / Contenders, d. H. Software elements that i.a. if necessary, can obtain confirmation from a user and system clients / extenders that do not require any interaction from the user. Accordingly, the user client / contender has further rights, so a user contender can take over an already occupied resource at any time, since i.a. the user has made the appropriate decision. An example of this is the recording of a television program on a video recorder: If another program has already been programmed for recording for the same time, the user can decide which of the programs he would like to keep.

For the use in the motor vehicle, the distinction in only two stages (user / system) is often not sufficient and the frequent confirmation by the user (driver) does not make sense. The present invention describes resource management that is known as _. Extension to the HAVi standard can be inserted with additional levels.

The method according to the invention adds an additional possibility to the HAVi standard, requirements and Assign priorities to resource assignments. This extension does not impair the function of a standard HAVi device, but enables resources (devices) that use the inventive method to manage resources efficiently and easily.

The invention ensures a distinction between the importance of a particular resource requirement compared to the currently valid resource allocation. In the case of an existing occupancy with lower priority, the occupying software element should release the resource so that it can then be used by the higher-priority software element. The existing HAVi standard describes a programming interface (Application Programming Interface, API) with which access to the network and

System functions is realized. Some function calls and parameters to be transferred are defined for the resource manager. These are used by a software element to allocate a resource and to release it again. In particular are relevant for the method according to the invention

(cf. [2], chap. 5.7.1, chap. 5.10.1):

^β FCM:: Reserve β ResourceManager:: Reserve β ResourceManager:: Negotiate o <Client>:: PreemptionRequest

The structure of the function calls in HAVi is based on the Interface Description Language (IDL). The format is general: GOAL:: COMMAND. GOAL means this

Software element 'that KOMMANDDO should execute. The GOAL often gives a return value on the success or Failure from COMMAND (status). In addition, parameters can be defined as "in" or "out", depending on whether they are passed with the function call (in) or after the function call from ZIEL (out).

The HAVi function calls to which changes are made in the method according to the invention thus look as follows:

Resource-Manager :: Reserve (in boolean preemptive, in ClientRole role, in wstring <50> info, in sequence <ResourceRequestRecord> reguestRecords, out sequence <ResourceStatusRecord> sfcatus Records)

Status ResourceManager:: Negotiate (in boolean reguest, in ClientRole role, in long negotiateTimeout, in wstring <50> info, in sequence <SEID> resources, out sequence <ResourceNegotiateRecord> negotiateRecords)

Status <Client>: rPreemptionRequest (in boolean request, in sequence <SEID> resources, in SEID contender, in long preemptionTimeσut, in ClientRole role, in wstring <50> inInfo, out wstring <50> outlnfo)

Remote status:: Reserve (in SEID serves in ClientRole role, in wstring <50> info, in boolean primary, in boolean nonlntrύsive, in OperationCode preemptionRequestCode)

The Info ^• (also: inInfo, outInfo) parameter is relevant for the present invention. According to the HAVi standard, this parameter is used to provide the requester (client) or client with additional information about the current process.

The method according to the invention uses an entry in these info fields in order to inform the client of the priority with which the contender requests the resource. When a client receives a request for a resource that has a higher priority than its own _t , that client should release the resource.

It is particularly advantageous to mark the entry of the assigned priority with a unique token, so that devices which contain the method according to the invention can differentiate whether it is the entry of the priority according to the method according to the invention or a different type of entry. Subsequently, the format CIAN_PRIO: X; assumed, where X is a placeholder for the value of the priority. Another ASCII string is also conceivable. It is also conceivable to use more than one character for coding the priority. The semicolon in the string serves as

Separator for a possibly following entry. It is also possible to define another or no separator. In the network shown in FIG. 1, reference numerals 100, 200 and 300 denote network elements (devices). The network element 400 denotes a device that can additionally or exclusively operate as a resource manager.

The resource 100 only allows easy access, for example a digitally controllable loudspeaker. The device 200 can access the resource 100, e.g. B. a radio.

The second device 300 can also access the resource 10O, e.g. B. a navigation device. 2 shows the occupancy of a free resource (loudspeaker 100) by the radio 200.

The driver switches on the radio 200 while driving. , This reserves the required resource 100 using the resource manager 400. The contender (radio 20O) sends a reservation request 111 to the resource manager 400. The resource manager 400 sends a request 112 to the radio 200, which sends a positive message 113 back , Since there is no further allocation of resource 100, resource manager 400 grants radio 200 access 114 to resource 100. The radio now plays audio data on the loudspeaker. The radio 200 receives a positive confirmation 115 from the resource manager 400. After some time, the driver switches on his navigation device 300 and enters a destination. to

The navigation device uses voice guidance that is output via the same resource 100. Both Devices 200 and 300 contain a device according to the inventive method. The manufacturers of the two devices have each given an appropriate priority. It is advantageous to use 10 priority levels (0 ... 9). The highest level should be reserved for system functions and system maintenance. In this example, priority 0 is used, ie 0 corresponds to the highest order, 9 the lowest order. In this example, the radio 200 has a priority of 6, the navigation device has a priority of 4.

If the navigation device 300 wants to make a voice output (FIG. 3), it requests the resource loudspeaker 100 from the resource manager 400 with the function call ResourceManager :: Reserve (211) (FIG. 2). With this call, the navigation device transfers parameters that contain relevant information about this reservation request. In addition to the content defined in the HAVi standard, the "info" parameter contains the string "CIAN_PRIO: 4;". The resource manager 400 then requests the current flexion status 212 from the resource 100. Since the resource is currently occupied by the radio 200, the resource manager 400 gives the navigation device 300 a feedback 213 that the reservation has failed. The navigation system 300 should then inquire about the current reservation status 214 at the resource 100 in order to find out why the reservation of the resource failed. Using the information transmitted in this query, the navigation device 300 can recognize (215) that the current assignment of the resource by the radio 200 takes place and has a lower priority than that which is assigned to the navigation device. The navigation device will then instruct the resource manager 400 to negotiate the takeover of the resource. The ResourceManager:: Negotiate 216 function call used for this includes the

Priority of the navigation device 300 the entry that this negotiation should be "preemptive", i. H. lead to a takeover of the resource. The resource manager 400 then sends a takeover request to the radio 200. The function <Client>:: PreemptionRequest 217 used in turn contains, among other things, the priority of the requesting device (here: navigation device). The occupying device (here: radio 200) now checks whether the priority of the requesting device is higher (218) than its own and answers with an approval 219 to accept the

Resource if the foreign priority is higher than your own. Otherwise, it can still agree, but will generally reject a takeover.

After approval by the radio 200, the resource manager 400 sends a success message 220 to the requesting navigation device 300. This can then instruct the resource manager 221 to call up the resource and to allocate the resource by calling the "ResourceManager:: Reserve" function again

Assign navigation device 300. This is done by passing the "Preemptive" parameter. Due to this function call, the resource manager 400 the requested resource 200 to reserve (222) and at ^'reservation made 223 notify the navigation device 300 (224). FIG. 4 shows the corresponding sequence in the event of a rejection, ie checking priority 218 here shows that device 300 has a lower priority than device 200.

The priorities for individual devices or services do not have to be laid down in a standard, but can be assigned by the manufacturer of the device or service.

Since all the information required after the first query of the state of the resource

(FCM:: GetReservationStatus) are known in the resource manager, in particular the priority of the occupying and the 'requesting device, the command <Client>:: PreemptionRequest can also be sent instead of a rejection to take over the resource for the contender, provided that Contender has a higher priority. This can significantly shorten the process.

literature

[1] IEEE, "P1394a Draft for a High Performance Serial Bus

(Supplement) "

[2] HAVi Organization, "The HAVi Specification 1.0"

Claims

claims

1. Resource management for resources that can be operated in particular on a serial bus with the following features:

- the requirements and allocations of resources (100) are assigned priorities,

- Resource users or services (300) with a high priority are given priority to the requested resources (100) or resources of resource users (200) or services with low priority that have already been used are released in order to give them to the resource users or services with higher priority (300) allot.

2nd Resource management according to ^' Claim 1, characterized in that a resource manager (400) is provided, and software elements assigned to the resource users (200, 300) which, in interaction with the resource manager (400), allocate resources (10O ) Taxes.

3. Resource management according to one of claims 1 or 2, characterized in that function calls and parameters to be transferred to the software elements are defined for the resource manager (400).

4. Resource management according to one of claims 2 or 3, characterized in that selected software elements are set up to return values on the success or failure of occupancy requests.

5. Resource management according to claim 3 or 4, characterized in that the priorities within the function calls are clearly identified in info fields in order to distinguish them from other entries in the info fields.

6. Resource management according to one of claims 2 to 5, characterized in that a resource user (200, 300) is set up to communicate directly with the resource (100) after a failure of an assignment request in order to inquire about the reservation status of the resource, to then negotiate with the resource manager (400) about the takeover of the resource.

7. Resource management according to one of claims 1 to 6, characterized in that the allocation of priorities is carried out device-dependent and / or service-dependent, this allocation either being a fixed agreement or being performed by the device and / or service provider.

8. Resource management according to one of claims 1 to 7, characterized in that the resource management is integrated in a self-configuring bus network.