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.　 Image RemovedA 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.

Image Added

　　　　　　　　　　　　　　　　　　　　　　　　　 Figure1
　　　　　　　　　　　　　　　　　

...

In the following table, use cases which need the Power State Management function are described. Each user is a driverIn each use case, a power state transition of the car is changed, and the IVI also needs to change states.

#	Item	Description	User
1

A

IVI(quick) startup

The user opens the

Door

door and

rides in

gets into the car. And the user presses the

start

button for ACC-ON

. Then

and the car and the IVI

turns

is turned on.	Driver
2	IVI shutdown	The user presses the button for ACC-OFF, gets out of the car and does not get into the car for a long time.	Driver
3	Startup unlinked with the ACC	The user presses a button for IVI-ON and uses audio, video, and communication services without ACC-ON.	Driver
4	Delayed ending	After arrival at the destination, when

a

the user wants to continue a handsfree call after ACC-OFF, the user

can continue

continues it although the display is off.

Driver

3

5

Remote parking system

When

a

the user wants to get the car out of the

garage

parking lot, the user

can use

uses the smartphone-linked function to control outside and

after that get

gets into the car.

(There are other use cases, for example, when no one is in the car, the multimedia system will be updated through OTA. )

Driver

4

A

	Driver
6	Demotion assistance	After the user arrives at the destination, the user presses the button for ACC-OFF and gets out of the car. When the user gets out of the car, if there is danger behind the car, an alarm sounds and the user is notified.	Driver
7	Return to the car soon	The 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


8	Return to the car temporally	The user opens the door and takes out the luggage. The user closes the door and does not get into the car

for a long time

.

Driver

　　　　　　　　　　　　　　　　　　　　　　　　　　 Table 2

Discussion Space for additional use cases(Freely write please) ~17:55

...

　　　　　　　　　　　　　　　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)

...

The following table is a description of the above four states.

#	IVI power state	Description of each state
1	Power-off

The

This is the state in which the IVI system is turned off

.
The

and the IVI display is turned off.
2	Ready

The

This is the state in which the IVI system is turned on

.
The

and 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

is turned on.
※When starting a car with IVI unprepared

IVI

, it takes a lot of time.

So

Therefore, the

state

“Ready” status is necessary.
3	Partially running

The

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

The IVI

This is the state in which the IVI system is turned on

.
Also

and the IVI display is turned on.

All

The ACC is on and all of the

user

functions

are available

can be used.

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

case	State transition diagram	The condition of transition

#1

(1)IVI(quick) startup

(

1

A), (

2

B)

(

1

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

(

23

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

#2

(

(2)IVI shutdown

(C), (E)

(

3

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

.

#3

(1

.

(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), (

6

F)

(

1

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

(

6

F)The transition request to change the selected services states to “Partially Running” is sent from 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

(3

, 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), (

4

F)

(

3

A)The transition request to change the

IVI state to “Power-off”

selected services states to “Ready” is sent from the Hardware side.

(

4

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

Running

“Power-off” is sent from the Hardware side

.

#5

(3

, 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), (

5

D)

(

3

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

(

5

D)

No

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. (G)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. Figure1 will be used to explain this requirement.

#

Item

Related use case

Description

1

Power state receiving

All of the use cases

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

The incoming trigger of the power state depends on each OEM so the incoming trigger should be flexible enough to change.
3	Power state sending	Power State Management should notify

each service of the transition request based on the configuration in the case of requirements(#2)

the power state change request to each service.

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

Since the number(definition) of power states depends on each OEM, adding or removing power states should be flexible enough to change.
5	Only services which require control by power state change requests should be notified of the necessary request.
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

...

Power Service
System Manager

Image RemovedImage Added

Figure4

...

Versions Compared

Old Version 43

New Version 44

Key

Abstraction

Discussion Space for additional use cases(Freely write please) ~17:55

Functional Requirements

Power State Management in Basesystem

Image RemovedImage Added

Page Comparison

Versions Compared

Old Version 43

New Version 44

Key

Abstraction

Discussion Space for additional use cases(Freely write please) ~17:55

Functional Requirements

Power State Management in Basesystem

Image RemovedImage Added