diff options
Diffstat (limited to 'agl-specs-v1.0/04-app-fw.md')
| -rw-r--r-- | agl-specs-v1.0/04-app-fw.md | 1499 |
1 files changed, 0 insertions, 1499 deletions
diff --git a/agl-specs-v1.0/04-app-fw.md b/agl-specs-v1.0/04-app-fw.md deleted file mode 100644 index c88cb04..0000000 --- a/agl-specs-v1.0/04-app-fw.md +++ /dev/null @@ -1,1499 +0,0 @@ ---- - -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. |