...
| Tip |
|---|
This page is created based on https://confluencelf-automotivelinux.automotivelinuxatlassian.orgnet/wiki/display/RS/Policy+Manager |
...
Table of Contents
| Table of Contents | ||
|---|---|---|
|
...
Summary
Policy Manager provides functions to control resources called GUI resources such as screens and sounds according to user operations, applications, vehicles, and driver statuses.
In a system in a car, there are input / output devices such as touch panels, speakers and microphones. The resources provided by users on those devices, and the resources that provide users with windows, sound streams, input events, etc. for input / output of those devices are collectively defined as GUI resources.
Policy Manager controls the use of GUI resources according to external conditions.
For example, during operation, if there is too much information to the driver, the driver will distract attention from the driving operation, thus controlling the use of GUI resources.
...
Fig. GUI resources
Glossary
Abbreviation | Description |
|---|---|
Use Cases
| Use Case | ||
|---|---|---|
| External condition collection | External condition collection is to receive the external conditions. | |
| Judgment of priority of GUI resource | judgment of priority of GUI resource is to receive the input/output/control request of GUI resources. | |
| Judgment of priority of GUI resource is to judge the GUI resource owner according to external conditions. | ||
| GUI resource control | GUI resource control is to issue the GUI resource control according to judgment. | |
| Policy Manager controls the screen resources | |
| One is allocation of each surface such as position, size and size-fitting method. | ||
Second one is visibility control. ・Basically, visibility should be "ON" during area owner was assigned. ・However, visibility may set to "OFF" during driving mode due to driving mode due to driving restriction. | ||
Last one is order control of each layer. ・Policy Manager decides the order of each layer, and issue z-order information for each layer. | ||
| Policy Manager controls the sound resources | |
One is playback control such as play, pause and stop. ・Policy Manager issues to play sound for sound area owner, and if area owner was changed, then issue to stop previous playing sound stream and to start play latest area owner. | ||
| These are sound manager responsibility | |
| These are Input manager responsibility. | |
| ||
|
Requirements
Functional Requirements
| Screen Resource | Requirement | |
|---|---|---|
| Configuration | Policy manager must provide a mechanism to configure physical display information. | * |
| Policy manager must provide a mechanism to configure the layout. | * | |
| Policy manager must provide a mechanism to configure the area definition. | * | |
Policy manager must provide a mechanism to configure (or define) the priority rule. | * | |
| Judgment of Priority of GUI Resource |
Policy manager must provide a mechanism to assign resource owner to the requested resource according to external condition. | ||
System must provide a mechanism to receive the layer request. | should be modified | |
System must provide a mechanism to receive the area request. | should be modified | |
| ||
System should provide a mechanism to receive the request of forcibly acquire and forcibly release. | ||
| ||
System must provide a mechanism to judge priority of resources. | ||
System must provide a mechanism to judge visible surfaces according to vehicle running state which comes for other component. | ||
| ||
| GUI Resource Control | System must provide a mechanism to issue the resource control according to judgment. |
System must provide a mechanism to issue the following resource control. ・Visible/Invisible ・Change position ・Raise * 4 Need to change because the scope of requirements varies depending on the reader | ||
| ||
| To add |
| Sound Resource | Requirement | |
|---|---|---|
| External Condition Collection | System must provide a mechanism to receive/configure the zone definition.* 4 Need to change because the scope of requirements varies depending on the reader | |
System must provide a mechanism to receive/configure the sound type definition.* 4 Need to change because the scope of requirements varies depending on the reader | ||
| Judgment of Priority of GUI Resource | System must provide a mechanism to receive/configure the owner request.* 4 Need to change because the scope of requirements varies depending on the reader | |
System should provide a mechanism to receive the request of forcibly acquire and forcibly release.* 4 Need to change because the scope of requirements varies depending on the reader | ||
System must assign resource owner as requested. * 4 Need to change because the scope of requirements varies depending on the reader | ||
| ||
System must provide a mechanism to judge priority of resources when there are two or more resources on same sound type on same zone. | ||
System should provide a mechanism to manage order of the owner request.* 4 Need to change because the scope of requirements varies depending on the reader | FIFO is enough? | |
| GUI Resource Control |
| |
| ||
| To add |
...
| Resource Management | Requirement | |
|---|---|---|
| All requirements are not for RBA | ||
Resource Management shall be able to handle resource requests for Audio Sinks(e.g. Cabin Speakers, Headphones)* 4 Need to change because the scope of requirements varies depending on the reader | ||
| Resource Management shall be able to handle resource requests for Video Sinks(e.g. Display) | ||
Resource Management shall be able to handle Source arbitration(Mix, WavPlayer instances, Tuners etc.)* 4 Need to change because the scope of requirements varies depending on the reader | ||
| Resource Management shall be able to handle validate all the input parameters for a resource request from resource requestors. | ||
Resource Management shall be able to keep track of all the available resources.* 4 Need to change because the scope of requirements varies depending on the reader | ||
| This is not for RBA | |
| Resource Management shall provide an interface to a request owner to remove/withdraw an existing resource request. | ||
Resource Management shall check for every requested resource against a pre-defined set of policies. * 4 Need to change because the scope of requirements varies depending on the reader | ||
Resource Management shall use the system state as an additional input to make a decision. * 4 Need to change because the scope of requirements varies depending on the reader | ||
| Resource Management shall not consider requirements to achieve a specific feature functionality. | ||
| Resource Management shall not provide support for requirements to achieve a specific feature functionality. | ||
| Deleted because details are not clear | |
| Deleted because details are not clear | |
| Deleted because details are not clear | |
| Resource Management shall assign a sink instance to a resource request, once the request is granted against the set policy. | ||
| Resource Management shall maintain connection state of an already granted connection. | ||
Resource Management shall be responsible for connecting/building a new source-sink connection using the underlying platform support. * 4 Need to change because the scope of requirements varies depending on the reader | ||
| Resource Management shall be responsible for removing/releasing an existing source-sink connection using the underlying platform support. | ||
Resource Management shall be request to mute the audio sink before an existing connection is removed/released. * 4 Need to change because the scope of requirements varies depending on the reader | ||
Resource Management shall provide an interface to unmute the audio sink when a connection is re-established and the active source is ready to use the sink for audio routing. * 4 Need to change because the scope of requirements varies depending on the reader | ||
Resource Management shall provide an interface to unmute an audio sink. * 4 Need to change because the scope of requirements varies depending on the reader | ||
Resource Management shall inform the resource requestor when the sink is connected and ready to be used for audio routing. * 4 Need to change because the scope of requirements varies depending on the reader | ||
Resource Management needs to inform the Resource Manager when they are ready to start audio routing. * 4 Need to change because the scope of requirements varies depending on the reader | ||
| ||
The number of sinks supported by the system shall be configurable through LCF parameter. * 4 Need to change because the scope of requirements varies depending on the reader | ||
| To add |
Non-Functional Requirements
| Category | Requirement |
|---|---|