Abstraction
This chapter provides requirements for the function of the Power State Management.
As the power state of IVI, from the user's perspective, the system appears to be in ACC-ON/OFF state, but there are various power states inside the vehicle that need to be managed.
On vehicle power state transitions(like ACC On/Off) or other use cases, IVI should receive the power state transition requests. In such cases of state transition, it is necessary to have a mechanism to manage the services running on IVI and notify the transition request to each services from Power State Management module.
What is described here indicates some kind of notification from the Hardware side (e.g. Acc on, etc.).
This figure shows the data flow diagram with the Hardware side.
Figure1
Use cases
In the following table, use cases which need the Power State Management function are described. Each user is a driver.
# | Item | User |
|---|---|---|
1 | A user opens the Door and rides in the car. And the user presses the start button for ACC-ON. Then the car and the IVI turns on. | Driver |
2 | After arrival at the destination, when a user wants to continue a handsfree call after ACC-OFF, the user can continue it although the display is off. | Driver |
3 | When a user wants to get the car out of the garage, the user can use the smartphone-linked function to control outside and after that get into the car. | Driver |
4 | A user presses the button for ACC-OFF, gets out of the car and gets into the car soon. | Driver |
5 | A user presses the button for ACC off, gets out of the car and does not get into the car for a long time. | Driver |
Discussion Space for additional use cases(Freely write please) ~17:0
# | item |
|---|---|
define some example of partially running and Ready
| |
| Deep sleep (Garage mode) vs Partially running management |
This is a simplified use case diagram of the above use case.
Figure2
In Production Readiness, to realize the use cases, power state transition of IVI in general is defined as follows.
- The state of IVI power off(Power-off)
- The state which is ready to boot IVI(Ready)
- The state which the part of IVI features can be used(Partially running)
- The state which IVI has started(Running)
Although the four states are considered necessary for product use cases, the 2 and 3 states depend on the requirements of each OEM.
The following table is a description of the above four states.
# | IVI power state | Description of each state |
|---|---|---|
1 | Power-off | The IVI system is turned off. |
2 | Ready | The IVI system is turned on. |
3 | Partially running | The IVI system is turned on. |
4 | Running | The IVI is turned on. |
The following shows the IVI state transition diagram of the above table. The conditions for each transition are also described.
Figure3) State transition diagram
Use cases diagram | State transition diagram | The condition of transition |
|---|---|---|
#1 | (1), (2) | (1)The transition request to change the selected services states to “Ready” is sent from the Hardware side. (2)The transition request to change the IVI state to “Running” is sent from the Hardware side. |
#2 | (3) | (3)The transition request to change the IVI state to “Power-off” is sent from the Hardware side. |
#3 | (1), (6) | (1)The transition request to change the selected services states to “Ready” is sent from the Hardware side. (6)The transition request to change the selected services states to “Partially Running” is sent from the Hardware side. |
#4 | (3), (4) | (3)The transition request to change the IVI state to “Power-off” is sent from the Hardware side. (4)The transition request to change the IVI state to Running is sent from the Hardware side. |
#5 | (3), (5) | (3)The transition request to change the IVI state to “Power-off” is sent from the Hardware side. (5)No transition request to change the IVI state is sent. |
Functional Requirements
This table includes the functional requirements of Power State Management module. Figure1 will be used to explain this requirement.
# | Description |
|---|---|
1 | Power State Management should receive state transition requests from the Hardware side. |
2 | When Power State Management receives the state transition requests from Hardware side to change to each 4 power state, the target service notified from Power State Management module should be configurable. |
3 | Power State Management should notify each service of the transition request based on the configuration in the case of requirements(#2). |
4 | Power State Management should receive completion notification when the service that received the request notification completes the state transition.(Finally the information will be notified to the Hardware side.) |
5 | At Ready state, some services should be defined as connected(which can start up quickly). For example, Bluetooth or Wifi services are considered to be such targets. |
Power State Management in Basesystem
Reference implementation by Basesystem
To have Power State Management for the use cases above, we provided the following functions as part of the power management function. Refer to the software configuration diagram(2. The scope).
- Power Service
- System Manager
Figure4
Power Service
Power service provides functions such as notifying the system manager unit of power state transition requests by getting the notification from the Hardware side, or receiving requests and notifying the Hardware side of it.
System Manager
In order to control the system according to the power state transition request, System manager notifies the services on the service list of a power state transition received from Power service.