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