---
title : Application Framwork
author: imported from Doors-ng by Fulup(iot.bzh)
date : 2016-06-30
categories: architecture, automotive
tags: architecture, automotive, linux
layout: techdoc
---
## Application Framework Layer
The Application Framework layer provides the methods needed to create software applications
and their user interfaces. The platform can support multiple application frameworks any of
which may be built into an SDK or product build. The application framework contains any code
specifically written for that framework as well the bindings to the Services and Operating
Systems layers that the application framework provides for its applications.
4.1 AGL Application Framework
The AGL Application Framework provides basic services to all applications regardless of the
framework they are implemented in so that there is a standard method providing the services.
Page 20 of 159
Automotive Grade Linux Requirements Spec v1.0 
{: class="image"}
May 28, 2015
### Application Manager
Application Manager describes requirements for AGL application lifecycle function. Application
lifecycle contains application installation/removal and launch/hide/resume/kill.
### Requirements
AGL System must support application lifecycle (install/uninstall, launch/kill, suspend/resume) based on
appid/pid via launcher.
AGL System must support a database to store application metadata (appid, exec path etc.).
AGL System must provide an interface to get a list of installed applications.
AGL System must provide an interface to get the state of an application.
AGL System must provide application privilege control.
### Window Manager
A window system is a software component that facilitates an implementation of graphical user interface. A
window system is responsible for managing display devices, Graphics Processing Units (GPUs), input
devices, and graphics memory. A window system works with the software component named window
manager that is responsible for a layout management of windows, and a routing of user interactions.
A window manager is as software component that is responsible for a layout management of
windows.
Window manager of automotive middleware layer makes up for traditional window management
system to be satisfied IVI’s complex requirements, typically requested from Policy Manager.
Also, AGL aims to provide well-portability among various hardware platforms.
Page 21 of 159
**No.** | **Role** | **Description**
-----------| -----------------------------|--------------------------------------------------------------
1 | Window drawing | Provide capability to draw a window to any place
| |
| | and any size and any scale.
| |
| | Also provide capability to change visibility of the
| |
| | window.
2 | Overlay of multiple | Provide capability to overlay two or more windows
| |
| windows | with any z-order.
| |
| | Also provide capability to use hardware layer
| |
| | efficiently.
3 | Visual effect | Provide capability to adapt visual effect as below.
| |
| | · Animation effect to change visibility
| |
| | · Animation effect to transit between two or
| |
| | more windows
| |
| | · Visual effect for a window, such as gray-out
| |
| | and transparent.
4 | Frame rate control | Provide capability to control dynamic frame rate
| |
| | change. This is useful if system resource was
| |
| | shortage.
5 | Multiple hardware layer | Provide capability to use hardware layer efficiently
| |
| support | if hardware supports two or more hardware layers.
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
#### Use Case
Please refer “screen resource control” of Policy Manger section.
#### Role
Table 7-148 describes the role of window manager to be satisfied above purpose and use
cases.
Page 22 of 159
----------------------------------------------------------------------------------------------
| 6 | Reduced dependency of | Provide well-defined interface to reduce
| |
| hardware | dependency of hardware. Well-defined interface
|
| also makes it possible to increase the effect of
|
| portability and development cost.
----- --------------------------- ------------------------------------------------------------
| 7 | Multi window / multi | Support multi window management and multi
| |
| display | display.
| 8 | Compatibility | From the compatibility point of view, AGL should
|
| use public API, and shall not rely on hardware
|
| specific API.
----------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
#### Requirements
4.1.2.3.1 Window Drawing
System must provide a mechanism to manage surfaces, such as create, delete, make visible and
make invisible.
System must provide a mechanism to create and delete surface.
When surface is created or deleted, system must notify status change to GUI resource.
This notification mechanism makes possible to assign surface to proper area by GUI resource.
System must provide a mechanism to change visibility per each surface.
And, provide an interface to change visibility.
All the surfaces must be set to invisible for initial state.
Surface will be visible only if GUI resource issues to change visibility.
System must provide a mechanism to move surface’s area. If area size was different between
previous area and new one, then system must support to fit into new area by VIC.4.1.4.
*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt
Page 23 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
from size of surface.
If resize was happened, system must notify to surface’s owner application.
If size of surface and size of area was different, system must provide a mechanism to fit surface
into area by squeeze.
If size of surface and size of area was different, system must provide a mechanism to fit surface
into area by using combination of scaling and trimming function.
That means, system must provide a mechanism to fit surface into area keeping original aspect
ratio. This makes it possible to fit by “pan & scan”.
If size of surface and size of area was different, system must provide a mechanism to fit surface
into area by using combination of scaling and background color.
That means, system must provide a mechanism to fit surface into area keeping original aspect
ratio. System also provides a mechanism to fill background color into redundant pixels. This
mechanism makes it possible to do “letterbox” method.
4.1.2.3.2 Overlay of Multiple Windows
System must provide a mechanism to create and delete a layer.
Layer must have a concept of z-order. That means, display order for each layer is decided by
their z-order attribute.
Z-order attribute is fixed value. So, if application wants to change display order of surfaces,
then, attached layer must be changed.
System must provide a mechanism to create and delete “area” to display surface.
Area is a concept which defines where to display in specific layer.
System must provide a mechanism to attach surface to any layer.
Also, system must be able to change attached layer.
And, provide an interface to attach and change.
Page 24 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
System must provide a mechanism to assign surface to any area in a layer.
And, provide an interface to assign surface to any area.
System must provide a mechanism to change visibility per each layer.
That means all the surfaces belonging to same layer will be changed visible or invisible at the
same time.
And, provide an interface to change visibility per layer.
Initial state must be set to invisible.
System must provide a mechanism to enable superimposed display based on z-order of each
layer, and disposition of surfaces.
4.1.2.3.3 Visual Affect
System must provide a mechanism to apply animation effect when visibility change was
happened.
Per each animation, system must provide a mechanism to apply below attributes.
- Duration
Animation type
System must provide typical animation effects, such as slide-in, slide-out, zoom-in and zoom-
out.
Also, system must provide a mechanism to add, delete and change animation effect easily by
plug-in architecture.
System must provide a mechanism to apply animation effect when move surface was happened.
Per each animation, system must provide a mechanism to apply below attributes.
· Duration
Animation type
System must provide typical animation effects, such as slide-in, slide-out, zoom-in and zoom-
Page 25 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
out.
Also, system must provide a mechanism to add, delete and change animation effect easily by
plug-in architecture.
System must provide a mechanism to make effect to surface.
And, provide an interface to set effect type from application and other software components.
System must provide a mechanism to make specific surface to gray-out.
System must provide a mechanism to make specific surface to low brightness
System must provide a mechanism to add, delete and change effect for surface easily by plug-in
architecture.
4.1.2.3.4 Frame Rate Control
System must provide a mechanism to reduce frame rate independent from refresh interval of
application.
System also provides a mechanism to set frame rate as 0fps, independent from refresh interval
of application.
This function is useful to keep whole system quality even if high load status, such as live
thumbnail and moving surface.
4.1.2.3.5 Multiple Hardware Layer Support
If hardware supports two or more hardware layers, system must provide a mechanism to use
hardware layers efficiently.
·
Never use software overlay when superimposing two or more hardware layers
Assign hardware layer for graphical high load function, such as video playback
4.1.2.3.6 Reduced Dependency of Hardware
Page 26 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Window Manager must be able to retrieve system structure regarding displays and layers of
each display. And system must provide a mechanism to adapt any structure without re-build,
such as by using re-configuration.
4.1.2.3.7 Multi Window
AGL specifies that automotive grade Linux shall manage multiple windows owned by multiple
processes on a display.
AGL specifies that automotive grade Linux shall support multi-headed display.
4.1.2.3.8 Compatibility
AGL specifies that automotive grade Linux shall have a window manager that uses only public
APIs provided by Window System and OpenGL/ES 2.0 for rendering and user interaction.
AGL specifies that automotive grade Linux shall have a window manager that relies on a
standard rendering API such as OpenGL/ES 2.0 only. The window manager shall not rely on any
hardware specific API.
A window system and OpenGL/ES 2.0 API are responsible for a hardware abstraction.
**4.1.3 Policy Manager**
**4.1.3.1 Overview**
4.1.3.1.1 Purpose
Policy Manager collects information and makes decisions based on them. To do that, Policy
Manager collects lots of status, such as user operation and application status, then issue Vehicle
Info Control or Resource Control to provide information. Policy Manager controls two types of
resource, one is called “GUI resources” such as screen and sound, and other one is called
Page 27 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
“System resources” such as CPU and memory.
4.1.3.1.2 GUI Resources
(1) Definition
· About Control of GUI Resources
AGL is supposed the following devices in this feature. For example, display with touch panel,
speaker, and microphone. And AGL defines that “GUI resources” are resources that provide user
or is provided by user on those devices, such as windows, sound streams and input events.
**Figure 7-1: GUI resources**
Page 28 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Policy Manager controls GUI resources according to external conditions. For example, Policy
Manager limits the information of GUI resources while the vehicle is driving, because, the too
much information distracts the attention of driver from driving operations.
· Associated Software Architecture
The software architecture of Policy Manager and related components regarding GUI resources
control is as below.
**Figure 7-2: Associated Software Expected Use Case**
Page 29 of 159
-----------------------------------------------------------------------------------------------------------------------------------------------------
| **No** | **Component** | **Description**
|
| **.**
---------- ------------------------ --------------------------------------------------------- -------------------------------------------------------
| 1 | Homescreen | Request to control of GUI resources.
| 2 | Applications | Request to output or input of GUI resources.
| 3 | UI Component | Receive driving mode and day night mode. And
|
| then provide the corresponding feature to
|
| applications UI such as input limitation and
|
| changing the theme.
| 4 | Application Manager | Detect application installation. Then Notify the
|
| definition of GUI resources such as role by
|
| application configurations.
| 5- | Vehicle | Window Manager
| |
| 1 | Info
|
| Control
| 5- | Sound Manager
|
| 2
| 5- | Input Manager
|
| 3
| 5- | Vehicle Info Distributor
|
| 4
| 5- | User Manager
|
| 5
-----------------------------------------------------------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Policy Manager is related with the below components.
(2) Role
Page 30 of 159
-----------------------------------------------------------------------------------------------------
| **ID** | **Role** | **Description**
---------- ------------------------------ -----------------------------------------------------------
| 1 | External condition | (1) Receives the external conditions.
|
| collection
| 2 | Judgment of priority of | (1) Receives the input/output/control request of
| |
| GUI resource | GUI resources.
|
| (2) Judgment the GUI resource owner according to
|
| external conditions.
| 3 | GUI resource control | (1) Issue the GUI resource control according to
|
| judgment.
|
| (2) Notify the driving mode and day night mode
|
| that is calculated by external conditions.
-----------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Policy Manager has the below role.
Page 31 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
**Figure 7-3: Definition of Role**
GUI resource classifies screen resource, sound resource and input resource. Details of each
resource type are as follows:
a. Screen Resource
a-1. External Condition Collection
Policy Manager collects the below definition that is related with screen resource.
**Figure 7-4: Definition of screen resource**
• Concept of Display, Layer, Layout and Area
AGL supports not only one physical display but also two or more displays. Each display has one
or more layer. And each layer must be connected to one layout defined by Homescreen. Layout
Page 32 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
consists of one or more areas. “Area” is graphics composed area to display specific graphics
window.
The z-order of layers is flexible. Policy Manager decides the z-order of each layer depending on
objectives of them. For example, layer-1 was used as “phone call notification”, and layer-2 was
used as displaying “map”, then Policy Manager will decide that layer-1 should be upper than
layer-2.
Layer is created by application including Homescreen. When application creates layer,
application specifies layer type. Layer type is roughly categorized as “Basic” and “Interrupt”.
“Basic” layers are used to display application itself such as media playback, map drawing and
setting menu. “Interrupt” layers are used to display overlay windows such as information alert
and enlarged view.
When application creates layer with ”Basic” type, application must specify layout type for it. On
the other hand, the case layer with “Interrupt”, application must specify corresponding “Basic”
layer. The layout of “Interrupt” layer is followed by “Basic” layer’s layout.
From the capability of Policy Manager point of view, the main purpose of layer is to decide z-
order. In other words, if there is a scenario to change z-order of two or more windows triggered
by system status change and/or user operation, then such kind of window must assign to
individual layer.
• Concept of Layer Owner, Role and Surface
“Layer owner” is application which created that layer. “Layer owner” can request each area of
that layer. When “Layer owner” requests specific area, “Layer owner” also specify “Role” of
area. “Role” represents how to be used that area, and used to define z-order of layers by Policy
Manager.
“Layer owner” also can request to change “Role” for specific area, however, whether “Role”
change is acceptable or not is decided by Policy Manager by using policy rule.
One area should connect to one graphics window. AGL defines the term “Surface” as graphics
window to display into one area.
Page 33 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Surface is a canvas to draw graphical image by application. To show via physical display, surface
drawn by application must be assigned to specific area. Figure 7-16 describes simplest example
to assign one surface to full screen with one layer. If layer has two or more areas, then
corresponding surfaces are mapped to each area. According to example of Figure 7-16, surface
is fit to area size as “squeeze”, however AGL also provide a way to fit as “letterbox” and “pan &
scan”.
**Figure 7-5: Definition of Surface**
• Subdivision of “Interrupt” Layer
Basically, “Basic” layer corresponding to “Interrupt” layer is used to display application’s main
surface. However there are some exceptions. For example virtual keyboard is not needed main
surface. However, to follow this layer type rule, virtual keyboard must have corresponding
“Basic” layer. But this “Basic” layer never used to display. Also on-screen, such as alert message
is not needed main surface too. But it must have corresponding “Basic” layer from same reason.
According to above concept and some exceptions, AGL defines four layer types described
as Table 7-3.
Page 34 of 159
---------------------------------------------------------------------------------------------------------
| **No** | **Type** | **Summary** | **Example**
---------- ------------- -------------------------------------------------------- -----------------------
| 1 | Basic | This is application’s basic screen. Typically, | Map of navigation
|
| application requests this layer at first time.
| 2 | Interrupt | This is application’s popup screen. | Enlarged view of
|
| navigation
| 3 | On-screen | This is system popup screen. Typically, On- | Warning message
| |
| screen service (e.g. Homescreen) requests | popup
|
| this layer.
| 4 | Software | This is the software keyboard screen. | Software keyboard
| |
| keyboard | Typically, software keyboard service
|
| requests this layer.
---------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------
| **No** | **Contents** | **Summary** | **Example**
---------- ---------------- ------------------------------------------------------- ------------------
| 1 | Role | This is screen owner (such as application or | Navigation
|
| service) role.
| 2 | Sub role | This is specific screen role. | Enlarged view
------------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
a-2. Judgment of Priority of GUI Resource
Policy Manager receives the request with “Role” that is related with each screen resource. Role
is the category name of screen resource priority. Role is used to judgment of priority by Policy
Manager. Table 7-4 and Figure 7-6 describes the definition of role and sub role.
Role consists of role and sub role. Role is screen owner role such as “Navigation” and “Software
Page 35 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
keyboard”. Sub role defines when layer type of the screen resource is not “Basic”. Sub role is
popup screen role such as “Enlarged view” (of Navigation).
**Figure 7-6: Definition of Role and Sub role**
The screen resources are sorted of priority that is related to role by Policy Manager. If display
has two or more layers, then all layers will be superimposed by z-order.
In addition, Policy Manager decides the area of "Interrupt" layer using role. Area of "Interrupt"
layer must be same area of the related "Basic" layer. "related" means that "Role" (is not "Sub
role") of "Basic" and "Interrupt" is same. For examples, if "Interrupt" layer is set “Navigation”
role and “Lane guidance” sub role, this is set in same area of "Navigation" role.
a-3. GUI resource control
Policy Manager controls the screen resources using Vehicle Info Control. Policy Manager only
issues to control the screen resources but it is actually controlled by Vehicle Info Control
directly.
Page 36 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
There are three types of screen resource control:
One is allocation of each surface such as position, size and size-fitting method.
Second one is visibility control. Basically, visibility should be “ON” during area owner was
assigned. However, visibility may set to “OFF” during driving mode due to driving restriction.
Last one is order control of each layer. Policy Manager decides the order of each layer, and issue
z-order information for each layer.
b. Sound Resource
b-1. External Condition Collection
Policy Manager receives the below definition that is related with sound resource.
**Figure 7-7: Definition of Sound Resource**
• Zone
Zone is a place in the car, such as driver zone, passenger zone, rear seat zone. Each zone can
play at the same time.
Page 37 of 159
-------------------------------------------------------------------------------------------------
| **No** | **Type** | **Summary** | **Example**
---------- ------------- ---------------------------------------------- -------------------------
| 1 | Basic | This is application’s basic sound. | Music of media
|
| player
| 2 | Interrupt | This is application’s interrupt sound. | Guidance of
|
| Navigation
| 3 | Beep | This is beep. Typically, Homescreen | Display touch sound
|
| requests this type.
-------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
• Sound type
Sound type is the category of sound resource. Sound type must be set by each sound resource
owner such as application. If application wants to play sound, it must be assigned to proper
sound type of proper zone. Only one sound stream can occupy specific sound type of specific
zone. In other words, if two or more sound streams should be mixed in same zone, then each
sound stream must assign to individual sound type.
AGL supports the following sound type, however it’s just sample and should be configurable.
• Stream
Stream is connection of sound resource that is made in applications. Sound is transferred in
stream.
b-2. Judgment of Priority of GUI resource
Policy Manager receives the request with “Role” that is related with each sound resource. Role
is the category name of sound resource. Role is used to judgment of priority by Policy
Manager. Figure 7-8 describes the definition of role.
Page 38 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
**Figure 7-8: Sample Role**
The sound resources in the same zone and same sound type are switched along the priority that
is related to role by Policy Manager. In other words, the sound resources of different zones or
different sound type are not switched. They are mixed.
b-3. GUI Resource Control
Policy Manager controls the sound resources using Vehicle Info Control. Policy Manager only
issues to control the sound resources but it is actually controlled by Vehicle Info Control
directly.
There are two types of sound resource control:
One is playback control such as play, pause and stop. Policy Manger issues to play sound for
sound area owner, and if area owner was changed, then issue to stop previous playing sound
Page 39 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
stream and to start play latest area owner.
Other one is volume control. Two or more sound streams of same zone may playback
simultaneously if each sound streams are assigned to different sound type. In this case, Policy
Manager specifies volume parameter for each sound stream. For example, if route guidance and
music playback are mixed, assign higher volume to route guidance and volume down for music
playback.
c. Input Resource
c-1. External Condition Collection
Policy Manager receives the below definition that is related with input resource.
**Figure 7-9: Definition of Input Resource**
• Device Name
Device name is identity of input device such as steering SW and microphone.
• Event Type
Event type is logical group of input event from each input device such as volumes and
temperatures.
c-2. Judgment of Priority of GUI resource
Page 40 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
If application wants to be notified input event, it must request input event notice with device
name and event type. The request is judged whether to notify by Policy Manager using policy
DB. And Vehicle Info Control notifies input event to applications along the result of the
judgment as below.
**Figure 7-10: Definition of routing rule**
OEM special switch means product variant configuration in Figure 7-10.
c-3. GUI Resource Control
Policy Manager controls the input resources using Vehicle Info Control. Policy Manager only
issues to control the input resources but it is actually controlled by Vehicle Info Control directly.
Input resource control is to specify event target to Vehicle Info Control.
4.1.3.1.3 System Resources
(1) Definition
Policy Manager controls System resources according to external conditions. For example, Policy
Manager limits memory usage of background applications when memory shortage was occurred.
Page 41 of 159
----------------------------------------------------------------------------------------------------
| **ID** | **Role** | **Description**
---------- ----------------------------- -----------------------------------------------------------
| 1 | External condition | (1) Receives the external conditions.
|
| collection
| 3 | System resource control | 1. Issue the System resource control according
|
| to external condition change.
|
| 2. Kill process(s) forcibly according to external
|
| condition change.
----------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Policy Manager controls System resources by using “Resource Control” of kernel layer. So,
target resources are CPU, memory, storage bandwidth and network bandwidth.
**4.1.3.2 Requirements**
4.1.3.2.1 Screen Resource
(1) External Condition Collection
System must provide a mechanism to receive the definition that is used judgment of resource
owner.
System must provide a mechanism to receive the physical display information. Because system
uses physical display information with to control surface to other system. The receive
information must include as follows.
a. ID
b. Display resolution (Vertical and horizontal number of pixels)
c. DPI
d. Connected ECU
Page 42 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
System must provide a mechanism to receive the layout definition. Layout definition must be
able to identify the all areas of display. As a result, system recognizes the available area list
according to current layout of each display.
The receive definition must include the follows.
a. ID
b. Area list
System must provide a mechanism to receive the area definition. Area is set application surface
by system if the request is accepted by system. As a result, application surface displays on the
device.
The receive request must include the follows.
a. Layout ID
b. ID
c. Area position (Coordinate of the upper-left)
d. Area size (Length \* Width)
System must provide a mechanism to receive the layout type of each display. System can specify
the available areas if layout type is defined. The receive information must include the follows.
a. Display ID
b. Layout ID
System must provide a mechanism to receive the priority rule. Because system must judge the
providing resource using it when the request is collision.
The receive information must include the follows.
a. Role
b. Priority
System must provide a mechanism to receive the vehicle status. Because system must judge
driving mode.
The receive information must include the follows.
a. Velocity
Page 43 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
b. Brake status
System should provide a mechanism to receive the vehicle status. Because system should judge
day night mode.
The receive information should include the follows.
a. The brightness of the interior
System should provide a mechanism to receive the user status. Because system should judge the
providing resource using it.
System should provide a mechanism to receive the infrastructure status. Because system should
judge the providing resource using it.
(2) Judgment of Priority of GUI Resource
System must provide a mechanism to assign resource owner to the requested resource
according to external condition. This means that system judges the providing resource.
System must provide a mechanism to receive the layer request. System allocates the physical
resource. Application must request the area on this layer if application needs to display the
resource.
The receive request must include as follows.
a. Role
b. Layer type
The receive request should include as follows.
c. Display ID
System must provide a mechanism to receive the area request. System sorts layers in order by
priority that is related with the specified role. Then system displays the application surface on
the specified area on the specified layer.
The receive request must include as follows.
a. Role
Page 44 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
b. Layer ID
The receive request must include as follows when layer type of the specified layer is “Basic”.
Because there is a specification that the area on layer except basic type must be located on the
related basic type area.
c. Area ID
**Figure 7-11: Sequence to display**
System should provide an interface to request both screen and sound resource simultaneously.
In this request, requester should choose below options.
a.
Requester needs both screen and sound. For example, if screen resource was available,
but sound resource was occupied by other owner of higher priority, then, request should
be refused.
b.
Requester wants screen and sound resource as much as possible. For example, if screen
resource was available, but sound resource was occupied by other owner of higher
priority, then, only screen resource should be assigned to requester.
Page 45 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
System should provide a mechanism to receive the request of forcibly acquire and forcibly
release. System should be able to forcibly acquire and forcibly release request during system
running. System should raise the requested surface to the top of the display.
The receive request should include the follows in addition to the information of the normal
request.
a. Effective period (Can set unlimited)
System should not raise the other surface above its during effective period.
System should provide a mechanism to receive the request that is specified the following effect.
a. The effect at the transition
b. The effect of display surface
System must provide a mechanism to judge priority of resources. The screen resources are
sorted of priority that is related to role by system. If display has two or more layers, then all
layers will be superimposed by z-order.
System must provide a mechanism to judge visible surfaces according to vehicle running state.
System must hide the surface that has too much information.
(3) GUI Resource Control
System must provide a mechanism to issue the resource control according to judgment.
System must provide a mechanism to issue the following resource control.
a. Visible / Invisible
b. Change position
c. Raise
The receive request must include as follows.
i. Surface ID \*Only case of visible.
ii. Display ID \*Only case of visible.
iii. Layer ID \*Only case of visible.
Page 46 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
iv. Position (Coordinate of the upper-left) \*Only case of visible and change position.
v. Size (Length \* Width) \*Only case of visible.
System should provide a mechanism to set the following effect of the surface to other system.
a. The effect at the transition
b. The effect of display surface
4.1.3.2.2 Sound Resource
(1) External Condition Collection
System must provide a mechanism to receive the definition that is used judgment of resource
owner.
System must provide a mechanism to receive the zone definition. Because system uses zone
information with to control stream to other system. The receive information must include as
follows.
a. ID
b. Sound device ID
System must provide a mechanism to receive the sound type definition. Because system uses
sound type information with to control stream to other system. The receive information must
include as follows.
a. ID
(2) Judgment of Priority of GUI resource
System must provide a mechanism to assign resource owner to the requested resource
according to external condition. This means that system judges the providing resource.
System must provide a mechanism to receive the owner request. System must be able to receive
request during system running.
Page 47 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
The receive request must include as follows.
a. Role
b. Zone ID
c. Sound type ID
System should provide a mechanism to receive the request of forcibly acquire and forcibly
release. System should be able to forcibly acquire and forcibly release receive request during
system running.
The receive request should include as follows in addition to the information of the normal
request.
a. Effective period (Can set unlimited)
System must assign resource owner as requested. And system must not assign resource owner
by other request on same area during effective period.
System should provide a mechanism to receive the request that is specified the following effect.
a. The effect at the transition
b. The effect of output sound
System must provide a mechanism to judge priority of resources when there are two or more
resources on same sound type on same zone. System judges the providing resource by priority
of resources that is related to role.
\* Boundary of the role between Policy Manager and application.
Page 48 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Figure 7-12: Boundary of role (Case of reverse)
System should provide a mechanism to manage order of the owner request. Because system
should provide a mechanism to hold the request until the request is approved.
For example, if current playing interrupt sound completed, select the next play interrupt sound
from request history based on the priority.
(3) GUI Resource Control
System must provide a mechanism to issue the resource control according to judgment.
System must provide a mechanism to issue the following resource control.
a. Mute / Unmute
b. Change zone
The receive request must include as follows.
i. Stream ID
ii. Device
In the case of multi-channel speaker, the receive request should include as follows.
iii. Channel ID
Page 49 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
System should provide a mechanism to set the below effect of the sound to other system.
a. The effect at the transition
b. The effect of output sound
4.1.3.2.3 Input Resource
(1) External Condition Collection
System must provide a mechanism to receive the definition that is used judgment of resource
owner.
System must provide a mechanism to receive the input device information. Because system uses
input device information with to control input event to other system. The receive information
must include as follows.
a. ID
System must provide a mechanism to receive the event type definition. Because system uses
input device definition with to control input event to other system. The receive definition must
include as follows.
a. ID
b. Related event IDs
(2) Judgment of Priority of GUI resource
System must provide a mechanism to assign resource owner to the requested resource
according to external condition. This means that system judges the providing resource.
System must provide a mechanism to receive the owner request. System must be able to receive
request during system running.
The receive request must include as follows.
a. Input device ID
Page 50 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
b. Event type ID
System should provide a mechanism to judge whether to accept request according to the
limitation routing rule of policy DB.
(3) GUI Resource Control
System must provide a mechanism to issue the resource control according to judgment.
System must provide a mechanism to issue the following resource control.
a. Set the routing rule
The receive request must include as follows.
i. Input device ID
ii. Event type ID
The receive request must include either as follows.
iii. The allowed application
iv. The denied application
System should provide a mechanism to set the following information.
a. Application that has active surface
System should notify the touch event from touch panel to user operating application. This
feature is needed because there may be case that privilege application such as Homescreen
changes the active surface.
4.1.3.2.4 System Resources
(1) External Condition Collection
System must provide a mechanism to collect external conditions to be used by Policy Manager
to decide proper system resource.
Page 51 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Policy Manager must detect creation and deletion of process.
To detect creation of process, Policy Manager can assign proper system resource to created
process.
Also, to detect deletion of process, Policy Manager can assign resources of deleted process to
other active processes.
To assign proper system resource to specific process, system must provide a mechanism to
identify process’s role. In other words, Policy Manager must recognize the purpose of each
active process.
Policy Manager must detect current memory consumption periodically.
To detect current memory consumption, Policy Manager can control maximum memory to each
process to prevent memory shortage. Also, Policy Manager may kill processes which were
thought as not so important process.
Policy Manager must detect current CPU consumption periodically.
To detect current CPU consumption, Policy Manager can control priority to each process to keep
system performance. Also, Policy Manager may kill processes which seem to be in unexpected
busy state.
System must provide a mechanism to notify application status change to Policy Manager.
Application status includes as below.
· GUI resource status, such as foreground or background.
·
Resuming last status or not. When system starts up or log-in user changes, system must
resume last status. In this case, Policy Manager should assign much resource to last
application to resume quickly as much as possible.
(2) System Resource Control
System must provide a mechanism to change assigned system resource per process or process
group according to external conditions.
According to policy based decision, Policy Manager must assign proper system resource to
target process or process group by using “Resource Control” of kernel layer. (typically cgroups
Page 52 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
will be used)
System must provide a mechanism to kill process or process group forcibly.
4.1.3.2.5 Resource Management
Resource Management shall consist of three functional components - Resource Manager, Policy
Manager, Connection Manager.
Resource Management shall provide CORBA interfaces to rest of the components in the system.
Each resource request shall be in form a:
AppID,
SourceID,
RequestorZoneID,
NeedAll Flag (to specify if all the resources need to be allocated ),
Required Resource List.
Resource Management shall be able to handle resource requests for Audio Sinks (eg: Cabin
Speakers, HeadPhones)
Resource Management shall be able to handle resource requests for Video Sinks (eg: Display)
Resource Management shall be able to handle Source arbitration (Mic, WavPlayer instances,
Tuners etc.)
Resource Management shall be able to validate all the input parameters for a resource request
from resource requestors.
Resource Management shall be able to keep track of all the available resources.
Use CCF data to identify all the resources that are possible in the system. (static identification)
Page 53 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Use dynamic registration by the resource owners to identify what resources out of the above list
are available at a point of time in the system. (dynamic identification)
Resource Management shall inform about resource availability and unavailability in the system
through status update.
Resource Management shall support stacking/queuing of resource requests.
> Receive the requests from the resource requestors.
> Handle each request in chronological order and check for policy validation through Policy
Manager.
> Add the validated requests into a priority queue.
> Process each request from the top of the queue for establishing the connection.
> If a request is still in the pending queue and the requestor requests to withdraw the request, it
shall be removed from the queue.
Each request for resource shall be handled as an independent request irrespective of any earlier
request by the same requestor. In case of multiple resources requested in a single request, it
shall be treated as a single request and will be processed based on the request parameters.
If the NeedAll flag is set by the requestor, it shall either grant all the requested resources to the
requestor or none of them shall be granted. There shall be no partial allocation of resources.
If the NeedAll flag is not set, it shall be able to do partial allocation of resources i.e. grant
some/all of the resources requested by the requestor.
Resource Management shall provide an interface to a request owner to remove/withdraw an
existing resource request.
Resource Management shall check for every requested resource against a pre-defined set of
policies if the request can be served at this point of time or not. Below is a list of possible inputs
for the policy decision:
> Currently Free or InUse Sink status
> Who is the resource owner of the currently used sink resource (if it is in use)
Page 54 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
> Priority of the new requestor compared to the currently using requestor.
Resource Management shall use the system state as an additional input to make a decision if a
request can currently be serviced or not. Below system states can be taken as input to the
policy decision:
> Based on the speed restriction setting for a specific region, a request can be granted/kept
pending.
> Low Power Mode, Eco Mode, System errors shall also be used to make policy decisions.
At any point of time it shall maintain the following information for each ZONE for use by
resource requestor:
> Zone ID
> Allocated Source Instance
> Allocated Sink Instance
> Mute status
Resource Management shall not consider requirements to achieve a specific feature functionality
(e.g. : Lowering audio volume of rest of the sinks when a phone call is in progress) as an input to
the resource management policy.
Resource Management shall not provide support for requirements to achieve a specific feature
functionality (e.g.: Pausing a pausable source when phone call is in progress).
Resource Management shall maintain priorities for all non-entertainment sources (eg:
AMFM\_TA, PHONE\_NORMAL, NAV\_VG, etc. shall all have priorities). In case two sources have
same priority, the first requestor shall be granted a resource. In case of difference in priorities,
the highest priority resource request shall be the one that is granted the resource.
Resource Management shall maintain same priority for all entertainment sources (eg: MP, DVD,
AMFM\_NORMAL, etc. shall all have the same priority). The last received Entertainment resource
request will be the one that is granted the resource.
A valid (parameter and policy validated) resource request shall never be denied to the requestor.
It shall either be granted or kept as a pending request in the priority queue.
Page 55 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Resource Management shall be responsible for reporting a broken resource status.
It shall be the responsibility of the resource requestor to remove the request from Resource
Manager if the resource is no longer needed.
Resource Management shall assign a sink instance (the specific instance allocated out of all
available instances of the requested sink type for a particular zone) to a resource request, once
the request is granted against the set policy.
Resource Management shall maintain connection state of an already granted connection.
Possible connection states are Active or Passive.
> When a source has the primary (master) control over a sink, the connection state will be
active.
Ex: In normal mode, a driver requesting for AMFM source to Driver HeadPhone Sink connection.
> When a source has the secondary (slave) control over a sink, the connection state will be
passive.
Ex: Driver using the AMFM source, at the same time the rear passenger requesting for same
AMFM source on Rear headphone sink.
Resource Management shall be responsible for connecting/building a new source-sink
connection using the underlying platform support.
Resource Management shall be responsible for removing/releasing an existing source-sink
connection using the underlying platform support.
Resource Management shall request to mute the audio sink before an existing connection is
removed/released.
Resource Management shall provide an interface to unmute the audio sink when a connection is
re-established and the active source is ready to use the sink for audio routing.
Resource Management shall provide an interface to unmute an audio sink.
Page 56 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Resource Management shall inform the resource requestor when the sink is connected and ready
to be used for audio routing.
Resource requestor needs to inform the Resource Manager when they are ready to start audio
routing. This information shall be used to unmute the allocated sink.
Resource Management shall maintain the system connection table at any point of time.
Connection table contains information regarding which sink is currently allocated to which
source instance.
Resource Management shall support handling of change in behaviour based on Limo setting:
> Share the source between the Rear Seat headphone (Limo mode owner) and Cabin Speakers.
System shall support 4 ForegroundBeep sinks and 2 ForegroundSpeech sinks. 2 additional sinks
are reserved for Engine noise synthesis which is outside the scope of this document. Additionally
1 FG speech sink and 1 FG beep sink is reserved for future use by ISC.
The number of sinks supported by the system shall be configurable through LCF parameter.
Headphones shall not be required to support any foreground sinks.
In case of Foreground sources and Tuner interrupt sources, any sink that is taken away from a
source because of a high-priority interruption, need to be returned back to the previous source
(if the request from the previous source is still valid and it's the next highest priority request).
As part of requirement to improve connection handling efficiency, it shall have exceptions to not
disconnect the active connection while switching between any Tuner Source-Sink Background
connection to another Tuner Interrupt Source with same sink connection.
It shall inform Resource Manager about a errors/failure in any of the existing sinks.
It shall inform Resource Manager about a errors/failure in any of the existing sources.
Page 57 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
It shall provide the error state information about all resources to the Platform Error State
Manager.
It shall inform the resource requestors in case the request is for an erroneous or faulty sink.
It shall wait for the application manager to notify it to prepare for shutdown.
It shall interact with the data storage manager to access (read and write) persistence data.
It shall interact with the data storage manager to access CCF data.
It shall support rules/exceptions (Blacklist) that define resource allocation strategy based on
current system scenario.
E.g.: If there is a blacklist rule that says a Speech session shall not be allowed while phone call
is in progress, then even if a FG sink is available, Speech shall be denied resources and kept as a
pending request.
It shall provide an interface to receive Limo mode setting status.
It shall provide an interface to receive status when a rear-user selects to take Cabin control.
It shall use interfaces of early app to receive information if it's already using Audio/Video
resources and update its internal status accordingly.
On any change in input to the Policy Manager (system state) it shall reevaluate all active
connections and reconnect or disconnect if required.
E.g. An Amp gets disconnected, then all active connects have to be disconnected.
Once the Amp gets reconnected, the connection info shall be reevaluated and final set of
connections shall be rebuilt with Amp.
It shall provide CORBA interfaces to the Resource Manager.
Page 58 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
It shall be responsible for connecting/building a new source-sink connection using the underlying
platform support.
It shall be responsible for removing/releasing an existing source-sink connection using the
underlying platform support.
It shall request to mute the audio sink before an existing connection is removed/released.
It shall provide an interface to unmute an audio sink.
System shall support 4 ForegroundBeep sinks and 2 ForegroundSpeech sinks. 2 additional sinks
are reserved for Engine noise synthesis which is outside the scope of this document. Additionally
1 FG speech sink and 1 FG beep sink is reserved for future use by ISC.
The no. of sinks supported by the system shall be configurable through LCF parameter.
It shall inform Resource Manager about a errors/failure in any of the existing sinks.
Headphones shall not be required to support any foreground sinks.
It shall wait for the application manager to notify it to prepare for shutdown.
It shall interact with the data storage manager to access (read and write) persistence data.
It shall interact with the data storage manager to access CCF data.
**4.1.4 Sound Manager**
A sound manager is a mechanism in which a sound output demand in two or more zones from
two or more applications is arbitrated, an audio server manages control of a sound output and a
policy manager manages a mediation rule.
Page 59 of 159
----------------------------------------------------------------------------------------------------
| **No.** | **Role** | **Description**
----------- --------------------------- ------------------------------------------------------------
| 1 | Routing sound streams | To route each sound stream to proper zone(s).
| 2 | Mixing level control | Mixing two or more sound streams after volume
|
| control of each sound streams.
| 3 | Sound effect | Provide a capability of sound effect as follows,
|
| · When changing sound stream. E.g. fade-in,
|
| fade-out and cross-fade.
| 4 | Reduced dependency of | Provide well-defined interface to reduce
| |
| hardware | dependency of hardware. Well-defined interface
|
| also makes it possible to increase the effect of
|
| portability and development cost.
----------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
A zone is a place in the car divided by the purpose of output power of sound like a driver zone, a
passenger zone, and a rear seat zone. Each zone can play at the same time. Refer to "Sound
resource" of "7.1.1.2 (2) Role" of "7.1 Policy Manager" for the details of a zone.
Applications that play and capture audio via the audio server, applications that control things like
volume and routing via the audio server, and a policy manager that works with the audio server
to implement automatic audio policies.
**4.1.4.1 Use Case**
Please refer “sound resource control” of Policy Manger section.
Table 7-14 describes the role of sound manager to be satisfied above purpose and use cases.
**4.1.4.2 Requirements**
Page 60 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
4.1.4.2.1 Routing Sound Streams
System must provide a mechanism to manage sound “zone”.
Refer to "(2) Sound resource" of "7.3.1.2.2 Role" of "7.3 Policy Manager" for the details of a
zone and how to manage zone.
System must provide a mechanism to manage one or more connected sound devices, and each
channels of each sound device.
One or more sound devices are usually connected to a system, and each sound device consists
of one or more channels. And each channel outputs the sound of a monophonic recording.
For example, as for a stereo sound, a speaker is connected to each of two channels, and it is
arranged at the driver side of a car, and the passenger seat side. If a telephone call is got when
outputting stereo music from both of speakers, only the channel of a driver side needs to lower
musical volume, and needs to mix and output the sound of a telephone (to louder sound than
music). For this reason, the system needs to recognize and control each channel of each sound
device.
The system must determine the route which outputs two or more sound streams to two or more
zones.
Although the output place zone of a sound stream may change dynamically according to the
present state of vehicles and a policy manager makes the decision, sound manager requires the
mechanism in which a route is smoothly changed based on the determination of policy manager.
System must provide a mechanism to manage two or more sound zone as grouped zone.
System must provide a mechanism to do volume control for specific zone.
All the sound outputted to a certain zone is adjusted by the volume of the zone.
System must provide a mechanism to control sound stream.
Control of a sound stream is as follows.
·
Mute/unmute: System must provide a mechanism to do mute or unmute to any sound
stream.
·
Suspend/resume: System must provide a mechanism to suspend or resume to any sound
Page 61 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
stream.
Volume control: System must provide a mechanism to change volume to any sound stream.
4.1.4.2.2 Mixing Level Control
The system must offer the mechanism for arbitrating two or more sound streams outputted to
the same zone according to a policy manager's arbitration.
System must provide a mechanism to do mixing after volume control of each sound streams.
System must provide a mechanism to attenuate sound volume when other sound stream
requested to play into same sound zone.
In this case, system must also provide a mechanism to return to the volume before attenuating
the volume of a sound stream when interrupted sound stream was ended.
System must provide a mechanism to mute sound volume when other sound stream requested
to play into same sound zone.
In this case, system must also provide a mechanism to unmute sound volume when interrupted
sound stream was ended.
System must provide a mechanism to suspend sound stream playback when other sound stream
requested to play into same sound zone.
In this case, system must also provide a mechanism to resume playback when interrupted sound
stream was ended.
4.1.4.2.3 Sound Effect
When sound stream was changed, system must provide a mechanism to do sound effect.
System must provide typical sound effect such as fade in and fade out.
System must provide a mechanism to add, replace and delete sound effect easily by using plugin
architecture.
Page 62 of 159
-------------------------------------------------------------------------------------------------------------------------
| **No.** | **Input type** | **Associated device** | **Description**
----------- ------------------- -------------------------- --------------------------------------------------------------
| 1 | Key | Steering switch | Simple key event.
|
| Deliver to application.
| 2 | Keyboard | Virtual keyboard | Keyboard event.
|
| Deliver to application, then use input
|
| method backend if needed.
| 3 | Touch | Touch panel | Touch event, such as start, stop and move.
|
| Also supports double click and multi-touch
|
| capability.
|
| Deliver to application.
| 4 | Sound | Microphone | Sound input.
-------------------------------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
4.1.4.2.4 Reduced Dependency of Hardware
Sound Manager must be able to retrieve system structure regarding sound device and channels
of each device. And the system must enable addition/deletion of a sound device by the means
which does not need rebuild of systems, such as a configuration.
**4.1.5 Input Manager**
The Input Manager provides a capability to deliver input events to the proper application
depending on request from Policy Manager. Policy Manager will decide event target per each
input area. Also, the IVI system may use various car-oriented input devices such as steering
switch. Input manager provides a capability to abstract such kind of input event.
**4.1.5.1 Use Case**
Please refer “input resource control” of Policy Manger section.
---------------------------------------------------------------------------------------------------------
| **No.** | **Role** | **Description**
----------- --------------------------- -----------------------------------------------------------------
| 1 | Abstract device event | Provide capability to abstract from device event to
|
| application readable event name, such as “volume
|
| up” and “right arrow”.
| 2 | Event delivery | Provide capability to deliver input event to specified
|
| application.
---------------------------------------------------------------------------------------------------------
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Deliver to application or voice recognition
engine.
Table 7-14 describes the role of input manager to be satisfied above purpose and use cases.
**4.1.5.2 Requirements**
**4.1.5.3 Abstract Device Event**
System must provide a mechanism to re-configuration regarding input devices without re-build.
Because, connected input devices may different by car grade, car type, destination and optional
equipment.
**4.1.5.4 Event Delivery**
System must provide a mechanism to deliver any input event to any application.
System must provide an interface to apply event delivery rule by using attribute pair “device id”
and “destination application id”.
Device id specifies a logical device name. Logical device name will link to physical device by
UIM.2.1.2.
Page 64 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Also, system must provide a mechanism to change event delivery rule dynamically.
System must provide a mechanism to link between logical device name and physical device.
System must provide a mechanism to deliver any input event to any application depending on
delivery rule defined in UIM.2.1.1.
System must provide a mechanism to inhibit any event delivery.
This function makes it possible to restrict input event during driving mode.
**4.1.6 User Manager**
**4.1.6.1 Use Case**
**4.1.6.2 Personal Identification**
User manager provides multi-user environment. A car may be used by two or more people, and a
person may use two or more cars, by using rent-a-car, for example.
**4.1.6.3 User Preference**
Multi-user environment provides same user experience for each user.
Also, multi-user aims seamless personal data sharing not only between cars but also including
other devices such as smartphones and smart TVs. Furthermore, it will include seamless data
sharing from your home and your office.
Identify the person, and log-in to the IVI system as a specified user. Personal identify may be
provided by traditional user name and password pair, smart key or biometrics.
Once a user has logged-in to IVI system, IVI system should provide personalized user
experience. For example, Bob uses English, but Alice uses French. Also, Bob likes rock-music,
*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob is
Page 65 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
logged-in, and Japanese and classic-music should be selected when Alice is logged-in.
**Figure 7-24 : Provide Logged-in User’s UE (User Experience)**
**4.1.6.4 Rent-a-car and/or Replacing a Car**
When Bob uses a rent-a-car, same preference should be adapted as if he rode his own car. If
Bob’s preference was stored in a cloud, then this can be supported. However, security is
important in this scenario. For example, Bob must not be able to access to other user’s
preference.
**Figure 7-25 : User data sharing between cars**
Page 66 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
**4.1.6.5 Seamless Data Sharing**
Cloud-based user data syncing will enable seamless data sharing between IVI systems and
smart-phones, home networks and accessing from your offices.
**Figure 7-26 : User data sharing over the cars**
**4.1.6.6 Role**
**Error! Reference source not found.** describes the role of the User Manager to satisfy the above
purpose and use cases.
**Table 7-17 : Role of User Manager**
**No.** **Role** **Description**
Page 67 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
1 User identification
Provide a mechanism to identify user, such as user
name and password pair, smart key and biometrics.
Provide a mechanism to log-in to the IVI system as
a specified user.
When a different user logs in, proper user
preference for the user must be applied, and
resume last state of corresponding user.
Also, each application can store application’s data
per user. In such cases, proper user data must be
applied when a different user logs in.
2 User preference
Provide a mechanism to apply user preference of
logged-in user.
User preference includes the following data.
· User interface, such as locale and wall-
paper.
· Resume last application’s status of specified
user.
· Application specific data.
3 User data management
Provide a mechanism to manage cloud based user
data.
The following capabilities are required.
· Download user data of the logged-in user
from the cloud.
· Update cloud data if the user data was
updated by user operation or otherwise.
· Periodically sync-up w/ cloud because user
data may be updated by other devices.
In addition to the above basic capabilities, user data
cache is essential for a car, since a car may not
always have a reliable network connection.
4 Security Because cloud based sharing user data may be
accessed from any place, user data must be
protected from unexpected data access.
Page 68 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
So, IVI system must provide security mechanism
regarding accessing to cloud based user data.
**4.1.6.7 Requirements**
4.1.6.7.1 User Identification
System must provide a mechanism to identify logged-in user.
System must provide a mechanism to enter user name and password, and verify password to
identify logged-in user.
System should provide a mechanism to read smart key attribute to identify logged-in user. For
example, using NFC.
System should provide a mechanism to identify logged-in user by using biometrics.
4.1.6.7.2 User Preference
When a logged-in user is identified, system must apply user preference depending on the
currently logged-in user.
System must provide a mechanism to apply personalized user experience as follows.
- Locale settings
- UX theme
Wall paper
System must provide an easy mechanism to add plugin function and/or attribute of personalized
user experience.
Page 69 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
System must provide a mechanism to switch application data per user, and apply logged-in
user’s application data automatically.
When user is identified and logged-in, the system must apply last status of logged-in user. Last
status refers to the status of the system as the current logged-in user has last logged-out of the
system. Specifically, last status includes the following.
- Foreground applications. That means displayed applications.
Background applications.
When user logs in for the first time, the system must apply user preference for new log-in user.
System must provide a mechanism to apply default preference attributes for new log-in user.
System must provide default preference attributes and HMI to apply for first time log-in user.
4.1.6.7.3 User Data Management
System must provide a mechanism to manage user data.
AGL defines “user data” as a general term which includes all the data necessary to realize user
preference.
User data shall be stored in the cloud. The cloud provides user data not only to IVI systems but
also other systems and/or devices such as smartphones, Home-PCs, business-PCs, HEMS and
home electronics.
System must provide a mechanism to apply user preference and to supply user data to
application by using cloud based user data.
System must provide a mechanism to download cloud based user data and apply it as user data
of the IVI system.
When user data is updated in the IVI system, then the system must upload updated user data to
the cloud.
Also, since other device or system may update shared user data elsewhere, system must provide
Page 70 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
a mechanism to sync with the cloud periodically to keep user data in the IVI system up-to-date.
Because the IVI system is not necessarily connected to a network, the system must provide a
mechanism to cache downloaded user data.
If the IVI system re-connected to a network, system must sync with the cloud as soon as
possible.
4.1.6.7.4 Security
Because user data may include personal information, system must provide a mechanism to
protect user data from risks including but not limited to leakage, tampering and theft.
System must provide a mechanism to protect user data when accessing to the cloud.
-
System must authenticate communication entity. In other words, IVI system must
authenticate cloud server, and cloud server must authenticate client such as IVI system,
smartphone or PC.
-
System must provide a mechanism to encrypt transported data via a network.
-
System must provide a mechanism to transport data via a network with protection
against falsification of data from unauthorized access or illegal access.
-
Cloud server must provide a mechanism to authenticate individual user, and provide
user data only to the authorized user.
Because, two or more user’s user data may be stored in IVI system as a cache, system must
provide a mechanism to protect cache data from other users. The protection of cached data to
include not only the current multi-user environment risk, but also the risk of attacks against
cached data. In other words, only logged-in user’s cache data can be accessed.
4.2 Web HMI
Web based HMI. Contains applications, web runtime environment, and web-based home screen.
**4.2.1 Web API**
Page 71 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
It is discussed that HMI parts of IVI system will be developed using HTML5. APIs to use service
function in IVI system from web applications is needed. Audio Visual API provides APIs for audio
visual equipment control to web applications. (e.g. Media files on storage, CD, DVD, BT-Audio,
Photo, etc.)
Web applications use Audio Visual API to play audio visual contents on IVI system. Use case of
Audio Visual API is shown in Figure 6-1.
**Figure 6-1: Use case of Audio Visual API**
**4.2.1.1 Requirements**
Audio Visual API must provide API to select Audio Visual contents.
· Select content using URL
·
Select content using contents list provided by multimedia subsystem
Page 72 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
Audio Visual API must provide API to playback Audio Visual contents. (Media file on storage, CD,
DVD, BT-Audio, Photo, etc.)
· Play
· Pause
· Fast-forward
· Rewind
· Track up
· Track down
· Select playmode (Repeat/Random)
Audio Visual API must provide API to control a volume.
· Volume up
· Volume down
· Mute
Audio Visual API must provide API for metadata access about Audio Visual contents.
Audio Visual API must provide API for notifications.
· The case that playback state is changed
· The case that Audio Visual contents is add / removed
Audio Visual API must provide API to play AM/FM radio.
· Change the frequency.
· Change the broadcasting stations.
· Receive the list of broadcasting stations.
· Select the preset channel.
· Get the information of the broadcasting station.
Audio Visual API must provide API to play digital radio.
· Store the broadcast program information.
Page 73 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
· Get the broadcast program information.
· Get the play time.
· Play the radio broadcast cached.
AGL System must support a web API to access Vehicle information.
AGL System must support web API to control STT/TTS daemon.
AGL System must support web API to control navi engine.
AGL System needs to provide a Web API to allow peer to peer communication between two web
apps.
AGL System needs to provide an API to allow peer to peer communication between a web app
and a native app.
AGL System must support access control over app to app communications. Service provider
should be able to restrict subscriber.
AGL System must support W3C/HTML5 DOM, Forms and Styles.
AGL System must support W3C/HTML5 Device APIs: Touch Events, Device Orientation,
Network Information
AGL System must support W3C/HTML5 Graphics APIs: canvas, canvas 2D context, and SVG
AGL System must support W3C/HTML5 Media: audio and video tags, user media and web audio
AGL System must support W3C/HTML5 Communication APIs: websocket, web messaging,
server sent events, session history of browsing context
*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL
Page 74 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
AGL System must support W3C/HTML5 Security APIs: Cross-Origin Resource Sharing, HTML5
The iframe element, Content Security Policy 1.0.
AGL System must support W3C/HTML5 UI APIs: Clipboard, DnD, Web Notifications
AGL System must support W3C/HTML5 Performance APIs: Web workers, Page Visibility, Timing
control, Navigation timing
AGL System must support W3C/HTML5 Location API: Geolocation
AGL System must support W3C/HTML5 Widget: Widget Packaging and XML Configuration,
Widget Interface, XML Digital Signatures for Widgets, Widget Access Request Policy
AGL System must support Khronos WebGL API.
**4.2.2 Web Runtime**
The Web Runtime module contains the bindings for the Web Application Framework to access
the AGL Application Framework and Services.
**4.2.2.1 Requirements**
AGL system Web Runtime shall provide full web application lifecycle management (e.g.,
installation/removal).
AGL System Web Runtime shall provide full execution environment for web apps (i.e., launch,
view generation, rendering, etc.)
AGL system Web Runtime shall provide a mechanism to implement plugins/extensions to add
better device/platform integration.
Page 75 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
AGL system Web Runtime shall provide a mechanism to manage apps' access control and also to
categorize apps with different privileges.
System must provide high level GUI components for Web application.
At least, below components are required.
· Text labels
· Button
· Radio button
· Check box
· Tab panel
· Animation (e.g. MNG, GIF animation)
· Slider
· Accordion list
· Anchor
· Text input form
· Dropdown list box
· Date picker
4.3 Native HMI
The Native HMI provides an application framework for those applications that are not written
using Javascript or other web technologies.
**4.3.1 Native App Runtime**
The Native Runtime module contains the bindings for the Native Application Framework to
access the AGL Application Framework and Services.
**4.3.1.1 Requirements**
System must provide high level GUI components for native application.
Page 76 of 159
Automotive Grade Linux Requirements Spec v1.0
May 28, 2015
At least, below components are required.
· Text labels
· Button
· Radio button
· Check box
· Tab panel
· Animation (e.g. MNG, GIF animation)
· Slider
· Accordion list
· Anchor
· Text input form
· Dropdown list box
· Date picker
**4.3.2 Native Application Framework**
The platform can support multiple application frameworks any of which may be built into an
SDK or product build. The application framework contains any code specifically written for that
framework as well the bindings to the Services and Operating Systems layers that the
application framework provides for its applications.