Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#

item

1

define some example of partially running and Ready

  • boot status
  • ready : bt, wifi, without display
  • partially running : hands free(bt, voice agent?)
  • Services should be configurable
2

Deep sleep (Garage mode) vs Partially running management


This is a simplified use case diagram of the above use case.
   Image Removed                   Figure2
In Production Readiness, the power state transition of IVI in general is defined as follows.

...

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

#

IVI power state

Description of each state

1

Power-off

This is the state in which the IVI system is turned off and the IVI display is turned off.

2

Ready

This is the state in which the IVI system is turned on 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 is turned on.
※When starting a car with IVI unprepared, 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. 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 and the IVI display is turned on. The ACC is on and all of the functions can be used.

                                   Table 3

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
                       

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 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, 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.
(G)When no transition request is received and a certain amount of time has passed, the state is changed.

                                   Table 5

Functional Requirements

This table includes the functional requirements of Power State Management module.  Figure1 will be used to explain this requirement.

#

Item

Related use caseDescription

1

Power state receiving



All of the use cases

Power State Management should receive state transition requests from the Hardware side.

2

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 the power state change request to each service.

4

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.

                                   Table 6

Power State Management in Basesystem

...

  • Power Service
  • System Manager

Image RemovedImage Added

                                                                                                          Figure4Figure 7


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.

...