Abstraction
...
Figure1
Use cases
In A requirement of IVI systems is that they need to support transitions to multiple power states. Not just a simple power off/on state, but several other types of power states are required. In each power state, it is necessary to switch the function to be controlled and the power state of connected devices.
Due to the diversity of use cases in modern automotive, it is necessary for IVI systems to operate even in situations where there is no voltage supplied by the battery. A problem inherent to IVI is the limited power supplied by the battery. If you always start and maintain any hardware in the state, it will lead to battery failure. Therefore, when using IVI, it is necessary to define the various power states according to the use case of each user, and in each power state, activate the minimum amount of hardware necessary to realize the use case and realize the function.
The IVI receives power state transition requests from the vehicle (hardware) side, notifies these requests to the various services, and performs state transitions. In this 4.4 section, the use cases involving power state transitions, the functional requirements for realizing those use cases, and the functions of the Basesystem as a sample implementation are described.
The description of Hardware in 4.4 section indicates some kind of hardware (such as CAN signal) that notifies the IVI side of power state transition.
Figure1
Use cases
In the following table, use cases which need the Power State Management function are described. In each use case, a power state transition of the car is changed, and the IVI also needs to change states.
Table 2
...
# | Item | Description |
|---|---|---|
UC.PS.1 |
A user searches the destination on the navigation display after starting the car.
2
When a user wants to go to the destination quickly after starting the car, he or she can quickly search the destination because of quick startup of IVI.
3
A user shutdown IVI by the ACC off.
4
IVI(quick) startup | The driver opens the door and gets into the car. And the user presses the button for ACC-ON and the car and the IVI is turned on. | |
UC.PS.2 | IVI shutdown | The driver presses the button for ACC-OFF, gets out of the car and does not get into the car for a long time. |
UC.PS.3 | Startup unlinked with the ACC | The driver presses a button for IVI-ON and uses audio, video, and communication services without ACC-ON. |
UC.PS.4 | Delayed ending | After arrival at the destination, when the driver wants to continue a handsfree call after ACC |
-OFF, the user continues it although the display is off |
(There are other use cases, for example, When an user
. | ||
UC.PS.5 | Remote parking system | When the driver wants to get the car out |
of the parking lot, the driver uses the smartphone-linked function to control outside and |
gets into the car. |
UC.PS.6 |
5
While a user stops the car, a certain amount of time passes. The IVI system then changes to the transition of Ready (Suspend) state.
...
Demotion assistance | After the driver arrives at the destination, the driver presses the button for ACC-OFF and gets out of the car. When the driver gets out of the car, if there is danger behind the car, an alarm sounds and the driver is notified. | |
UC.PS.7 | Return to the car soon | The driver presses the button for ACC-OFF, gets out of the car and gets into the car soon. |
UC.PS.8 | Return to the car temporally | The driver opens the door and takes out the luggage. The driver closes the door and does not get into the car. |
UC.PS.9 | Automatic updates via OTA | IVI automatically updates software through OTA function while the driver is away from the car. |
UC.PS.10 | Data backup | IVI performs data backup while the driver is away from the car. |
In Production Readiness, the 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)
- The state which IVI is suspended(Suspend)
Although the five 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 five four states.
Table 3
# | IVI power state | Description of each state |
|---|---|---|
1 | Power-off |
This is the state in which the IVI system is turned off |
The
and the IVI display is turned off. | |
2 | Ready |
This is the state in which the IVI system is turned on |
The
and the IVI display is turned off. |
BT and Wifi services should be prepared at Ready state as standard
is turned on. |
, it takes a lot of time. |
Therefore, the |
“Ready” status is necessary. | |
3 | Partially running |
This is the state in which the IVI system is turned on. |
The IVI display is turned off.
The IVI system keeps selected services so that the services can be used for some time after the ACC off.
When transitioning to this state from any other state, the IVI system will be able to use the selected services for a while. (There is no specific mention of turning the IVI display off/on. It shall be dependent on implementation.) | |
4 | Running |
This is the state in which the IVI system is turned on |
Also
and the IVI display is turned on. |
All of the user functions are available.
5
Suspend
The IVI display is turned off.
The IVI system prepares selected services so that the IVI system can transition smoothly to the Ready state.
The ACC is on and all of the functions can be used. |
The following shows the IVI state transition diagram of the above table. The conditions for each transition are also described.
Figure3Figure 4 ) State transition diagram
...
When the power status of the vehicle changes, the power status of the IVI will transition.
The cause of the change in the vehicle power state depends on the vehicle signal, CAN signal, vehicle system, etc. Therefore, the required state/transition may be different depending on the product and hardware requirements of each OEM.
However, the above state transition diagram shows the state that realizes the use cases defined in this document. Each OEM should add or delete state/transition as necessary.
Table 5
Use case | State transition diagram | The condition of transition |
|---|
(1)IVI (quick) startup | (A), (B) | ( |
A)The transition request to change the selected services states to “Ready” is sent from the Hardware side. (B)The transition request to change the IVI state to “Running” is sent from the Hardware side. | ||
(2)IVI shutdown | (C), (E) | (C)The transition request to change the IVI state to “Power-off” is sent from the Hardware side. |
(E)When no transition request is received and a certain amount of time has passed, the state is changed. | |
(3)Startup unlinked with the ACC | (A), ( |
F) | ( |
A)The transition request to change the selected services states to “Ready” is sent from the Hardware side. ( |
F)The transition request to change the |
selected services states to “Partially Running” is sent from |
#3
pressing a button for IVI-ON. | ||
(4)Delayed ending | (C) | ( |
C) |
When the transition request to change the IVI state to “Power-off” is sent from the Hardware side |
#4
(5), (6)
, the state goes through “Partially running” once. If there is a request to execute the function, it is done in this state. | ||
(5)Remote parking system | (A), (F) | (A)The transition request to change the selected services states to “Ready” is sent from the Hardware side. (F)The transition request to change the selected services states to “Partially |
Running” is sent from the user’s smartphone. | ||
(6)Demotion assistance | (C) | (C)When the transition request to change the IVI state to “Power-off” is sent from the Hardware side |
, the state goes through “Partially running” once. If there is a request to execute the function, it is done in this state. | ||
(7)Return to the car soon | (C), (D) | (C)The transition request to change the IVI state to “Power-off” is sent from the Hardware side. (D)The transition request to change the IVI state to Running is sent from the Hardware side. |
(8)Return to the car temporally | (A), (G) | (A)The transition request to change the selected services states to “Ready” is sent from the Hardware side |
#5
(7), (8)
. | ||
(9)Automatic updates via OTA | (A), (F), (E) | (A)The transition request to change the selected services states to |
“Ready” is sent from the Hardware side. (F)The transition request to change the selected services states to “Partially Running” is sent from pressing a button for IVI-ON. (E)When no transition request is received and a certain amount of time has passed, the state is changed. | ||
(10)Data backup | (A), (F), (E) | ( |
A)The transition request to change the selected services states to “Ready” is sent from the Hardware side. (F)The transition request to change the selected services states to “Partially Running” is sent from pressing a button for IVI-ON. (E)When no transition request is received and a certain amount of time has passed, the state is changed. |
Functional Requirements
This table includes the functional requirements of Power State Management module. Figure2 will be used to explain this requirement.
Table 6
# | Item | Related use case | Description |
|---|---|---|---|
FR.PS.1 | Power state receiving | All of the use cases | Power State Management should receive state transition requests from the Hardware side. |
FR.PS.2 |
When Power State Management receives the state transition requests from Hardware side to change to each 5 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
Power State Management should notify the state transition completion information to the Hardware side.
6
Power State Management should not notify the Hardware side every time the state transition completion information is sent from a service, but rather notifies the Hardware side of a certain amount of information at once.
7
The incoming trigger of the power state depends on each OEM so the incoming trigger should be flexible enough to change. | ||
FR.PS.3 | Power state sending | Power State Management should notify the power state change request to each service. |
FR.PS.4 | Since the number(definition) of power states depends on each OEM, adding or removing power states should be flexible enough to change. | |
FR.PS.5 | Only services which require control by power state change requests should be notified of the necessary request. | |
FR.PS.6 | Device control | According to the power state transition, each application or middleware related to services should switch the function to activate or the control devices. |
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.
- Power Service
- System Manager
Figure4In the implementation of Basesystem, the function modules for Power Service Management are Power Service and System Manager. The software configuration diagram is defined in 2. The scope. Please refer to it.
Figure 7
Power Service
Power service provides functions such as notifying the system manager unit module 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.
Reference
...
code :
https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging/basesystem.git;a=tree;f=service/system/system_managerpower_service;h=fabcbf6aabbf0b7dd8a1df2fb35491029a2d1fdd;hb=refs/heads/master
System Manager
In order to control the system according to the power state transition request, System manager notifies the services of a power state transition received from Power service.
Reference code :
https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging/basesystem.git;a=tree;f=service/system/power_service;h=fabcbf6aabbf0b7dd8a1df2fb35491029a2d1fddsystem_manager;hb=refs/heads/master