You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Describe the use cases of functions which are common in each OEM's products and functional requirements on implementation.

Abstraction

This chapter provides requirements for the function of the Power State Management.

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.

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.


#

Item

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

When a user wants to continue a handsfree call after ACC off, he or she can continue it although the display is off as partially running state.
(There are other use cases, for example, 

  • When an user wants to get the car out, he or she can use the smartphone-linked function to control outside and after that get into the car.
  • When no one is in the car, the multimedia system will be updated through OTA. )

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.


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.

  1. The state of IVI power off(Power-off)
  2. The state which is ready to boot IVI(Ready)
  3. The state which the part of IVI features can be used(Partially running)
  4. The state which IVI has started(Running)
  5. The state which IVI is suspended(Suspend)


Although the five 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 states.


#

IVI power state

Description of each state

1

Power-off

The IVI system is turned off.
The IVI display is turned off.

2

Ready

The IVI system is turned on.
The IVI display is turned off.
The IVI system prepares selected services so that the IVI system can provide user functions quickly when the IVI becomes on.
BT and Wifi services should be prepared at Ready state as standard..

※When starting a car with unprepared IVI, it takes a lot of time. So the state “Ready” is necessary.

3

Partially running

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.

4

Running

The IVI is turned on.
Also the IVI display is turned on.
All of the user functions are available.

5

Suspend

The IVI system is turned on.
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 following shows the IVI state transition diagram of the above table. The conditions for each transition are also described.

       


                      Figure3
                       

Use cases diagram

State transition diagram

The condition of transition

#1

(1)

(1)The transition request to change the IVI state to “Running” is sent from the Hardware side.

#2

(3), (4)

(3)The transition request to change the selected services states to “Ready” is sent from the Hardware side.

(4)The transition request to change the IVI state to “Running” is sent from the Hardware side.

#3

(2)

(2)The transition request to change the IVI state to “Power-off” is sent from the Hardware side.

#4

(5), (6)

(5)The transition request to change the selected services states to “Partially running” is sent from the Hardware side.

(6)The transition request to change the IVI state to “Power-off” is sent from the Hardware side and IVI system terminates.

#5

(7), (8)

(7)The transition request to change the selected services states to “Suspend” is sent from the Hardware side.

(8)The transition request to change the selected services states to “Ready” is sent from the Hardware side.

Functional Requirements

This table includes the functional requirements of Power State Management module.  Figure2 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

Power State Management notifies 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

BT, Wifi should be prepared at Ready state as standard. However they should be configurable.

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
  • (NS frameworkunified)

                                                                                                          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.

NS frameworkunified

NS frameworkunified provides mechanism for communicating with any process in Basesystem

Reference Code

System manager

https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging/basesystem.git;a=tree;f=service/system/system_manager;hb=refs/heads/master

Power service

https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging/basesystem.git;a=tree;f=service/system/power_service;h=fabcbf6aabbf0b7dd8a1df2fb35491029a2d1fdd;hb=refs/heads/master


  • No labels