diff options
Diffstat (limited to 'agl-specs-v1.0/00-doorsNG-skimed.md')
| -rw-r--r-- | agl-specs-v1.0/00-doorsNG-skimed.md | 4203 |
1 files changed, 0 insertions, 4203 deletions
diff --git a/agl-specs-v1.0/00-doorsNG-skimed.md b/agl-specs-v1.0/00-doorsNG-skimed.md deleted file mode 100644 index c5ffbd5..0000000 --- a/agl-specs-v1.0/00-doorsNG-skimed.md +++ /dev/null @@ -1,4203 +0,0 @@ ---- -# Master Header for Jkyll ---- - -Version 1.0 -Automotive Grade Linux -Requirements Specification -May 28, 2015 -www.automotivelinux.org -www.linuxfoundation.org -Automotive Grade Linux Requirements Spec v1.0 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**1 Automotive Grade Linux** -1.1 Overview -Automotive Grade Linux (AGL) is a Linux Foundation Workgroup dedicated to creating open -source software solutions for automotive applications. Although the initial target for AGL is In- -Vehicle-Infotainment (IVI) systems, additional use cases such as instrument clusters and and -telematics systems will eventually be supported. AGL has participants from the Automotive, -Communications, and Semiconductor Industries and welcomes contributions from individual -developers. -By leveraging the over \$10B of investment made in the Linux kernel and other open source -software projects, the AGL Workgroup: -· -Enables rapid software innovation for automotive suppliers to keep up with the demand -from consumers for better IVI experiences -· -Utilizes the talents of thousands of open source software developers dedicated to -maintaining the core software in areas like the Linux kernel, networking, and -connectivity, used in systems across numerous industries -The goals of the Automotive Grade Linux Workgroup are to provide: -· -An automotive-focused core Linux operating system stack that meets common and -shared requirements of the automotive ecosystem with a broad community of -support that includes individual developers, academic organizations and companies. -· -A transparent, collaborative, and open environment for Automotive OEMs, Tier One -suppliers, and their semiconductor and software vendors to create amazing in-vehicle -software. -· -A collective voice for working with other open source projects and developing new open -source solutions. -· -An embedded Linux distribution that enables rapid prototyping for developers new to -Linux or teams with prior open source experience -This results in faster time to market by jump-starting product teams with reference applications -running on multiple hardware platforms. -Page 5 of 159 - - > **Term** > **Definition** - ------------ ------------------------------------------ - > A2DP > Advanced Audio Distribution Profile - > AGL > Automotive Grade Linux - > AVRCP > Audio Video Remote Control Profile - > FS > File System - > GPS > Global Positioning System - > GPU > Graphical Processing Unit - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -1.2 Document Scope -The scope of this document is to define the architecture of the Automotive Grade Linux software -platform. The requirements are broken up into an overview of the Architecture and a description -of each of the layers in the architecture followed by the requirements for each module in the -various layers. The Architecture Diagram and the layout of the specification take into -consideration all of the components that would be needed for an IVI system; however the are -missing requirements for individual modules. As the spec continues to evolve those sections will -continue to be filled in. -The main goal of this document is to define the core software platform from which applications -can be built. As such, this document does not define application requirements except in a single -case (Home Screen). Application requirements will be developed by various projects that use the -AGL platform. Those application requirements can be used to drive new or revised -requirements into the platform. -At this time there is no plan to use this specification to create a compliance or certification -program. The specification is used as blueprint to guide the overall work of AGL and to derive -work packages for companies and individuals to complete in order to attain the goals of the AGL -Workgroup. -1.3 Glossary of Terms - - > HFP > Hands Free Profile - -------- ------------------------------------- - > IBOC > In-Band On Channel - > LTSI > Long Term Support Initiative - > NTP > Network Time Protocol - > OEM > Original Equipment Manufacturer - > OS > Operating System - > OSS > Open Source Software - > SDL > Smart Device Link - > STT > Speech to Text - > TTS > Text to Speech - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**2 Architecture** -The Automotive Grade Linux Software Architecture diagram is below. The architecture consists -of five layers. The App/HMI layer contains applications with their associated business logic and -HMI. Generally applications are out of scope for this document since they are product specific -for the OEM that is developing a system based on AGL. -The Application Framework layer provides the APIs for creating both managing and running -applications on an AGL system. The Services layer contains user space services that all -applications can access. The Operating System (OS) layer provides the Linux kernel and device -drivers along with standard OS utilities. -Page 7 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**3 App/HMI Layer** -Applications may use a web based framework or a native framework. A system may include -applications that use different frameworks. Coordination of applications between frameworks is -performed by the AGL App Framework. The diagram represents possible applications that could -appear in a given system, but is not all inclusive. Reference applications may be provided by AGL -Page 8 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -to demonstrate the capabilities of the platform. -3.1 Home Screen -Home Screen provides the Home User Interface (Home UI) of the system which meets the -following requirements: -· Rich User Experience (Rich UX) -· Driver Distraction mitigation -· Variations support -Rich UX covers requirements such as usability and user satisfaction. Driver Distraction mitigation -covers requirements on display control and user operation behavior while vehicle is in motion to -minimize driver distraction. Variations support covers requirements to support customization of -design and behavior of the system to meet the different needs of vehicle type, destination and -grade. -**3.1.1 Layout** -The following use cases are considered for Layout. -· -Home Screen developer changes the Home UI by using a customizable layout definition. -Page 9 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**3.1.2 System UI Parts** -The use case assumed about System UI Parts is as follows. -· -An application or System uses status bar and on-screen in order to notify information to -a user. -· -User uses the system setting UI in order to change settings. -· User uses software keyboard in order to input characters. -**3.1.3 Application Management** -The use case assumed about Application Management is as follows. -· -A user downloads and installs or updates the delivery application from application store. -· A user uninstalls the delivery application. -· -A user launches the installed delivery application or the pre-installed application. -· Also a user terminates those applications. -**3.1.4 Application Switch** -The use case assumed about Application Switch is as follows. -· -User switches application via application history or application stack. -· -The system switches application according to Driving Mode status. -**3.1.5 Application History** -Application switching by application history is assumed as follows. -· -The system records the order of the applications in the order in which the application is -displayed. -· -The order of application that is recorded is updated each time the display of the -application is switched. -· -Screen of the application is displayed in the order in which they are recorded in the -history at the time of switching applications. -Page 10 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -‑ Specification of operation -- User runs a swipe from the edge of the application screen area. -‑ Specification of action -- The order of the screen is managed order management list (application history). -- List order update opportunity(Update has determined a display of the application) -- Application starts or stops. -- Allowed to stand between the screen N seconds after the swipe. -‑"N seconds"‑User defines the value of any. -- User to operate the screen after you swipe. -‑"operation"‑Screen tap. Menu display. Other. -Figure 5‑2 represents a sample Home Screen depicting the above mentioned use cases. -Page 11 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**3.1.6 Application Stack** -Application switching by application stack is assumed as follows. -· -The user specifies the type of any order. The system records the order of the application -to the rule as of the specified type. -· Examples of the types of any order -· Application start-up order -· -Screen of the application is displayed in the order in which they are recorded in the stack -Page 12 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -when switching applications. -‑ Specification of operation -· -User runs a swipe from the edge of the application screen area. -‑ Specification of action -· -The order of the screen is managed order management list (application stack). -· -List order update opportunity.(Application start-up order as an example) -· -Application that started at the end of the list when the application is started is added. -· -Application that has stopped from the list when the application is stopped will be -deleted. -Figure 5-3 represents the switching example depicting the application of the above switching. -Page 13 of 159 - - -------------------------------------------------------------------------------------- - > **No** > **Use Case** > **Role** > **Description** - ---------- ----------------- --------------- ----------------------------------------- - > 1-1 > Layout > GUI Layout > Function to define a customizable - > > - > definition > GUI Layout definition. - -------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**3.1.7 Role of Home Screen** -Table 5-1 describes the role of the Home Screen to satisfy the purpose and use cases -Page 14 of 159 - - ---------------------------------------------------------------------------------------------------- - > 1-2 > Change Layout > Function to apply the customized - > - > GUI layout definition. - ------- --------------------- ------------------------ --------------------------------------------- - > 2-1 > System UI Parts > Status Bar > Function to display the - > - > information from application or - > - > system. - > - > Function to quickly access and set - > - > certain system settings. - - > 2-2 > On-screen > Function to display a popup - > - > window such as alert messages. - - > 2-3 > System Setting > Function to display system - > - > settings menu regarding GUI, - > - > such as locale and network. - - > 2-4 > Software > Function to display software - > > - > Keyboard > keyboard. - - > 3-1 > Application > Application > Function to download - > > > - > Management > Management > applications from application - > - > store. Function to install, uninstall - > - > and update the downloaded - > - > applications. - - > 3-2 > Application > Function to launch/terminate - > > - > Launcher > applications. - - > 4-1 > Application > Application List > Function to switch applications by - > > - > Switch > installed application list. - - > 4-2 > Application History > Function which switches - > - > application in order by - > - > applications history. - - > 4-3 > Application Stack > Function to switch application in - > - > any order. - ---------------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**Table 5-2: Relevance of the Role and Purpose** -Page 15 of 159 - - ----------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Rich UX** > **Driver** > **Variations** - > > - > **Distraction** > **support** - > - > **mitigation** - ----------- --------------------------- ---------------- ------------------- ------------------ - > 1-1 > GUI Layout definition > ‑ > ‑ > ‑ - - > 1-2 > Change Layout > ‑ > ‑ > ‑ - - > 2-1 > Status Bar > ‑ > ‑ - - > 2-2 > On-screen > ‑ > ‑ - - > 2-3 > System Setting > ‑ > ‑ - - > 2-4 > Software Keyboard > ‑ > ‑ - - > 3-1 > Application Management > ‑ > ‑ - - > 3-2 > Application Launcher > ‑ > ‑ - - > 4-1 > Application List > ‑ > ‑ - - > 4-2 > Application History > ‑ > ‑ - - > 4-3 > Application Stack > ‑ > ‑ - ----------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**3.1.8 Requirements** -**3.1.8.1 Layout** -Home Screen must provide a mechanism for customizable GUI layout definition by each vehicle -type, each destination and each grade. -Home Screen must provide a mechanism for a customizable GUI layout definition for different -vehicle type, destination and grade. -GUI layout definitioncan be definedsuch as the following items: -(In addition, items that can be defined is not limited to the following.) -· screen resource (Display, Layer Type, Area) -Page 16 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· sound resource (Zone, Sound Type) -· input resource (Device, Event Type) -· UI Component to be used in the entire system -· transition effect (Animation effect) -· Background image -Home Screen must provide a mechanism to apply customized GUI layout definition. -**3.1.8.2 System UI Parts** -Home Screen must provide a mechanism to display two or more information simultaneously to -the status notification area. -Home Screen must provide a mechanism to displaying status to status notification area. -· Current Time: Displaying clock capability -· -Icons of Status: Displaying icons for notify information from applications -· -Status Message: Displaying text for notify information from applications -· -Communication Status: Status of mobile communication and wireless communications -(Wi-Fi, Bluetooth, etc.) -Home screen must provide an interface to retrieve information from application for notification. -Home Screen must provide a mechanism to show popup window into on-screen window. -Home Screen must provide GUI method to hide on-screen window by user operation. -Home Screen must provide a mechanism to hide on-screen window within a specified duration. -Home Screen must provide an interface for applications to request to show popups. -Home Screen must provide an interface for applications to cancel the previously requested -popup. -Page 17 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Home Screen must provide a mechanism to show text information, draw images and show -software switch like button in the on-screen window. -Home Screen must provide a mechanism to specify attributes such as position and size of On- -screen window. -Home Screen must support a mechanism to specify other window display effect when the On- -screen window is displayed. (e.g. tone down) -Home Screen must provide system setting menu regarding GUI, such as locale and network. -Home Screen must provide a mechanism to change current date and time setting. -Home Screen must provide a mechanism to change timezone setting. -· -The platform must set up the date, time and timezone according to a current position -automatically. -· -Home Screen must provide a mechanism to set up turning on and off of the automatic -date/time/timezone setup. -Home Screen must provide a mechanism to change language setting. -Home Screen must provide a mechanism to change wireless communications (Wi-Fi, Bluetooth, -etc.) setting. -· Enable/Disable -· Connect/Disconnect -· Search the devices -· Display the list of available and/or registered devices -Home Screen must provide a mechanism to change mobile communication setting. -· Enable/Disable -Page 18 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· A setup and change of various attributes -· Display the list of registered devices and select device -HomeScreen must support to change the appearance of a screen to a user's liking. -These are as follows. -· Tone of a screen. -· Appearance of a window frame. -· Animation effect when screen transition was occurred. -Home Screen must support a mechanism to set or change master audio volume. -Home Screen must support a mechanism to set or change display brightness. -Home Screen must provide a mechanism to show software keyboard. -Home Screen must provide a mechanism to apply default settings (e.g. theme, local, wallpaper) -to a new user, when a user is added by the User Manager. -**3.1.8.3 Application Management** -Home Screen must provide a mechanism to manage downloaded application package. -· Display downloaded application list from application store. -· Download the application -· Install the downloaded application -· Uninstall the downloaded application -· Update the downloaded application -Home Screen must provide a mechanism to launch the application. -Home Screen must provide a mechanism to terminate the application. -Page 19 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**3.1.8.4 Application Switch** -Home Screen must provide a mechanism to show the list of installed applications. -Examples of assumed application list -· list of application name -· list of application’s icon -· list of live thumbnail for all the running applications -Home Screen must provide a mechanism for switching display application in order by application -history. -Home Screen must provide a mechanism for the application stack in any order. For example, -such as launch order or display order. -Home Screen must provide a mechanism for the system to switch applications. -For example, when Driving Mode changes, system must be able to switch application based on -policy. -**4 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 -May 28, 2015 -**4.1.1 Application Manager** -Application Manager describes requirements for AGL application lifecycle function. Application -lifecycle contains application installation/removal and launch/hide/resume/kill. -**4.1.1.1 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. -**4.1.2 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 -**4.1.2.1 Use** **Case** -Please refer “screen resource control” of Policy Manger section. -**4.1.2.2 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 -**4.1.2.3 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. -**5 Services Layer** -The Services Layer contains user space services that all applications can access. Generally the -services provide either an IPC type interface or a subroutine/ function API. These interfaces -remain the same for a given implementation and it is up to the Application Framework Runtime -modules to provide access to these interfaces to the applications. Since we are trying to avoid -unnecessary interface shims, it is not necessary for AGL to define standard service layer -interfaces for a given module. Unless otherwise specified the API depends upon the interfaces -provided by the open source packages chosen for a module. Different implementations may -choose different packages for a given function and it is left to the Application Framework -runtime to adjust to any new interfaces, -Page 77 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1 Platform Services -Platform Services Layer. Conventional Linux platform services -**5.1.1 Bluetooth** -This document describes requirements regarding registration, (dis)connection and device -information management between Bluetooth device and infotainment system. Necessary -Bluetooth profiles in automotive use case are defined here. -**5.1.1.1 Requirements** -The Telephony system shall be designed to -support a minimum of BT3.0+EDR, but shall be possible to upgrade to Bluetooth 4.0+EDR -without hardware upgrade. -A Bluetooth hands-free system shall provide the following BT profiles: -· Core 2.0 + EDR inc. GAP (Generic Access Profile) -· HFP (Hands Free Profile) -· OBEX (Object Exchange) -· OPP (Object Push Profile) -· PBAP (Phonebook Access Profile) -· SPP (Serial Port Profile) -· SDAP (Service Discovery Access Profile) -If the BT system is designed to operate with BT Media Players (E.g. control and stream music -from), the system shall also support the following incremental BT profiles: -· A2DP (Advanced Audio Distribution Profile) -· AVRCP (Audio Visual Remote Control Profile) -The link key shall be minimum 128 bits. The encryption key is negotiated and shall be set at the -Page 78 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -highest supported value by the remote device. The Telephony system shall be capable of -generating up to 128-bit encryption key. The Telephony system will not be the limiting device in -encryption key length negotiation. -When implemented by the remote device Simple Secure Pairing 'Numeric comparison' method as -default pairing mechanism. However when remote device is limited a configurable priority -scheme will be adopted where the order of mechanisms will be determined at configuration -time. -The Telephony system shall provide Bluetooth Power Class 2. The operating range of Class 2 is -10 meters and maximum power is 2.5 mW (4 dBm). -The Telephony system shall have provision for 1, 3 and 5-slot packet transmission. It shall -allow using five-slot packet transmission for faster data rate. -The Telephony system shall use IrMC standards as directed by the BT specification. It is a -standard from IrDA, including IrOBEX for object exchange including vCards, vCalendars, etc. -vCard is the electronic business card. It is used for Personal Data Interchange (PDI). vCards are -often attached to e-mail messages, and can be exchanged on Instant Messaging. vCard contain -name and address information, phone numbers, and e-mail addresses. -vCard version 2.1 is widely adopted by e-mail clients. It contains FN, N, PHOTO, BDAY, ADR, -LABEL, TEL, EMAIL, MAILER, TZ, GEO, TITLE, ROLE, Logo, Agent, ORG, NOTE, REV, SOUND, -URL, UID, Version, and KEY properties. -vCard version 3.0 is IETF standards format. It is defined in following two parts: -MIME Content-Type for Directory Information -vCard MIME Directory Profile -It contains NICKNAME, CATEGORIES, PRODID, SORTSTRING and CLASS properties along with -the vCard version 2.1 properties. -The touch-screen or head unit HMI must have the ability to delete a Bluetooth device and any -associated data (E.g. phonebook, voicemail number) when required, even if the BT device list is -not full. -The Telephony system shall use SCO link for voice data if eSCO link is not supported else eSCO -Page 79 of 159 - - ------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **Support in HF** > **AGL** - ----------- ------------------------------------------------------------- ----------------------- ----------- - > 1 > Connection management > Mandatory > x - - > 2 > Phone status information > Mandatory > x - - > 3 > Audio Connection handling > Mandatory > x - - > 4 > Accept an incoming voice call > Mandatory > x - - > 5 > Reject an incoming voice call > Mandatory > x - - > 6 > Terminate a call > Mandatory > x - - > 7 > Audio Connection transfer during an ongoing call > Mandatory > x - - > 8 > Place a call with a phone number supplied by the > Option > x - > - > HF - - > 9 > Place a call using memory dialing > Option > - - - > 10 > Place a call to the last number dialed > Option > - - ------------------------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -shall be used. -5.1.1.1.1 Hands Free Profile -The Telephony system shall implement Hands-Free Profile (HFP) as per the hands-free Profile -specification version 1.6 or later. -The Telephony system shall enable a headset, or an embedded Hands-Free unit to connect, -wirelessly, to a cellular phone for the purposes of acting as the cellular phone's audio input and -output mechanism and allowing typical Telephony functions to be performed without access to -the actual phone. -It shall provide following roles: -Hands-Free unit (HF) - - > 11 > Call waiting notification > Option > x - ------- ------------------------------------------------------ ---------- ---------- - > 12 > Three way calling > Option > x(\*1) - > 13 > Calling Line Identification (CLI) > Option > x - > 14 > Echo canceling (EC) and noise reduction (NR) > Option > x - > 15 > Voice recognition activation > Option > x - > 16 > Attach a Phone number to a voice tag > Option > - - > 17 > Ability to transmit DTMF codes > Option > x - > 18 > Remote audio volume control > Option > - - > 19 > Respond and Hold > Option > x - > 20 > Subscriber Number Information > Option > x - > 21a > Enhanced Call Status > Option > x - > 21b > Enhanced Call Controls > Option > - - > 22 > Individual Indicator Activation > Option > - - > 23 > Wide Band Speech > Option > x - > 24 > Codec Negotiation > Option > x - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -\*1: Does not support Multi-party (conference) call -The Telephony system shall be able to use the AT+CGMM query/response to determine the -model of the phone over the HFP profile connection. Whatever is returned shall be stored as a -string in a phone model CGMM variable. -· Phone Model CGMM: -· Type: string -· Max length: 200 chars -Page 81 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· Persistence: No -A property shall exist for each device which is connected to the system. -The request shall be made each time a HFP Service Level Connection is established with the -device. -The Telephony system shall be able to use the AT+CGMI query/response to determine the -Manufacturer of the phone over the HFP profile connection. Whatever is returned shall be -stored as a string in a phone model CGMI variable. -· Phone Model CGMI: -· Type: string -· Max length: 200 chars -· Persistence: No -A property shall exist for each device which is connected to the system. -The request shall be made each time a HFP Service Level Connection is established with the -device. -The Telephony system shall be able to use the AT+CGMR query/response to determine the -revision of the phone over the HFP profile connection. Whatever is returned shall be stored as a -string in a phone model CGMR property. -· Phone Model CGMR: -· Type: string -· Max length: 200 chars -· Persistence: No -A property shall exist for each device which is connected to the system. -The request shall be made each time a HFP Service Level Connection is established with the -device. -5.1.1.1.2 Advanced Audio Distribution Profile (A2DP) -The Telephony system shall implement Advanced Audio Distribution Profile as per the A2DP -specification version 1.2 or later. -Page 82 of 159 - - > **No.** > **Codec** > **Support** > **AGL** - ----------- ------------------- --------------- ----------- - > 1 > SBC > Mandatory > x - > 2 > MPEG-1,2 Audio > Option > - - > 3 > MPEG-2,4 AAC > Option > - - > 4 > ATRAC family > Option > - - - > **No.** > **Feature** > **Support in SNK** > **AGL** - ----------- -------------------- ------------------------ ----------- - > 1 > Audio Streaming > Mandatory > x - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -The Telephony system shall use this profile for audio streaming. This profile shall be use to -realize distribution of audio content of high-quality in mono or stereo on ACL channels. -It shall provide following roles: -Sink (SNK) - A device is the SNK when it acts as a sink of a digital audio stream delivered from -the SRC on the same piconet. -Items marked with "x" in AGL column in Table 20 should be supported. -Decode functions of codec marked with "x" in AGL column in Table 21 should be supported. -Copyright protection technology SCMS-T should be supported. -5.1.1.1.3 Phone Book Access Profile -Page 83 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -The Telephony system shall implement Phonebook Access Profile as per the PBAP specification -version 1.1 or later. -The Telephony system shall use this profile to allow exchange of Phonebook Objects between -devices. -Phonebook is automatically downloaded into the system from mobile device for browsing. The -Telephony system shall store user's Phonebook and the Phonebook details of the connected -device shall be available to the user. The Telephony system shall manage the contacts by, listing -and copying contact information. -It shall provide following roles: -· Phonebook Client Equipment (PCE) -It shall provide following types of Phonebook objects: -· The main Phonebook object -· The Incoming Call History object -· The Outgoing Call History object -· The Missed Call History object -· The Combined Call History object -A Bluetooth hands-free system must download the phonebook from the connected BT device -automatically if the BT device has provision for the transfer of phonebook data. The Phonebook -download shall be performed by any one of the following methods listed in priority of usage: -· Using PBAP profile -All the BT device's phonebook entries must be transferred - those on any external memory (E.g. -SIM) and also any stored in the BT device's memory. -The number type data (if stored with the contact) shall also be transferred and stored in the -vehicle phonebook. The Phonebook shall be associated to only the BT device it was downloaded -from. -5.1.1.1.4 Dial Up Networking (DUN) Profile -Dial-Up Networking Profile (DUN) has to be supported as well as Profiles/Protocols for -necessary lower layers. -Page 84 of 159 - - > **No.** > **Service** > **Support in DT** > **AGL** - ----------- ------------------------------------------- ----------------------- ----------- - > 1 > Data call without audio feedback > Mandatory > x - > 2 > Data call with audio feedback > Option > - - > 3 > Fax services without audio feedback > N/A > - - > 4 > Fax services with audio feedback > N/A > - - > 5 > Voice call > N/A > - - > 6 > Incoming calls > Option > x - > 7 > Outgoing calls > Mandatory > x - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -It has to comply with the specification for “Data Terminal (DT)” -Items marked with "x" in AGL column in Table 23 should be supported. -5.1.1.1.5 Object Push Profile (OPP) -Object Push Profile (OPP) has to be supported as well as Profiles/Protocols for necessary lower -layers. -It has to comply with the specification for “Push Server”. -Items marked with "x" in AGL column in Table 24 should be supported. -**Table 24 : List of OPP Push Server Supporting Functions** -Page 85 of 159 - - > **No.** > **Feature** > **Support in CT** > **AGL** - ----------- -------------------------------------------- ----------------------- ----------- - > 1 > Connection establishment for control > Mandatory > x - > 2 > Release connection for control > Mandatory > x - > 3 > Connection establishment for browsing > C6 > x - - ------------------------------------------------------------------------------------- - > **No** > **Feature** > **Support in Push Server** > **AGL** - > - > **.** - ---------- ---------------------------- --------------------------------- ----------- - > 1 > Object Push > Mandatory > x - - > 2 > Business Card Pull > Option > - - - > 3 > Business Card Exchange > Option > - - ------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.1.1.6 Audio/Video Remote Control Profile (AVRCP) -The System shall implement Audio / Video Remote Control Profile version 1.6. -The system shall use this profile for audio streaming control for each connected media device -plus one remote control.. -The system must comply with the specification for Controller (CT) items marked with "x" in AGL -column in Table 25 should be supported. -C2: Mandatory if device supports Metadata Attributes for Current Media Item or optional -otherwise -C3: Mandatory to support at least one Category -C4: Mandatory if Category 2 supported, excluded otherwise -C6: Mandatory if Browsing (item 18) is supported, optional otherwise -EX: Excluded -Page 86 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -4 Release connection for browsing C6 x -5 AV/C Info commands Option x -6 Category 1: Player/Recorder C3 x -7 Category 2: Monitor/Amplifier C3 - -8 Category 3: Tuner C3 - -9 Category 4: Menu C3 - -10 Capabilities Option x -11 Player Application Settings Option x -12 Metadata Attributes for Current Media Item Option x -13 Notifications C2 x -14 Continuation C2 x -15 Basic Group Navigation Option x -16 Absolute Volume C4 - -17 Media Player Selection Option x -17.1 - Supports Multiple Players Option x -18 Browsing Option x -18.1 - Database Aware Players Option x -19 Search Option - -20 Now Playing C6 x -20.1 - Playable Folders Option x -21 Error Response EX - -22 PASSTHROUGH operation supporting press and Option x -Page 87 of 159 - - ------------------------------------------------------------------------------ - > **No** > **Feature** > **Support by the MCE** > **AGL** - > - > **.** - ---------- ------------------------- ----------------------------- ----------- - > 1 > Message Notification > C1 > x - - > 2 > Message Browsing > C1 > x - - > 3 > Message Uploading > Option > x - - > 4 > Message Delete > Option > - - - > 5 > Notification > C2 > x - > - > Registration - ------------------------------------------------------------------------------ - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -hold -The AVRCP profile realisation shall implement an Inform Battery Status of CT parameter and -pass this information up to so it can be passed to the User. -5.1.1.1.7 Message Access Profile -Message Access Profile (MAP) has to be supported as well as Profiles/Protocols for necessary -lower layers. -It has to comply with the specification for “Message Client Equipment (MCE)”. -Items marked with "x" in AGL column in Table 26 should be supported. -C1: The MCE to support at least one of the C1-labelled features -C2: The MCE shall support Message Notification Registration if it supports Message -Notification. Not applicable otherwise. -Page 88 of 159 - - > **No.** > **Feature** > **Support in PANU** > **AGL** - ----------- ------------------------------------------ ------------------------- ----------- - > 1 > Initialization of NAP/GN service > - > - - > 2 > Shutdown of NAP/GN service > - > - - > 3 > Establish NAP/GN service Connection > Mandatory > x - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.1.1.8 Serial Port Profile (SPP) -The Telephony system shall implement Serial Port Profile as per the SPP specification version -1.1 or later. -It shall provide following roles: -Initiator - This is the device that takes initiative to form a connection to another device. -Acceptor - This is the device that waits for another device to take initiative to connect. -Following features shall be provided by the Supplier: -Establish link and setup virtual serial connection -Accept link and establish virtual serial connection -Register Service record for application in local SDP database -5.1.1.1.9 Personal Area Network (PAN) Profile -Personal Area Network Profile (PAN) has to be supported as well as Profiles/Protocols for -necessary lower layers. -It has to comply with the specification for “PAN User (PANU)”. -Items marked with "x" in AGL column in Table 27 should be supported. -Page 89 of 159 - - > 4 > Lost NAP/GN Service Connection > Mandatory > x - ----- ------------------------------------------- ------------- ----- - > 5 > Disconnect NAP/GN Service Connection > Mandatory > x - > 6 > Management Information Base (MIB) > - > - - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.1.1.10 Service Discovery Profile (SDP) -The Telephony system shall implement Service Discovery Application Profile as per the SDAP -specification version 1.1. -The Telephony system shall use this profile to locate services that are available on or via devices -in the vicinity of a Bluetooth enabled device. -It shall provide following roles: -Local Device - A device that initiates the service discovery procedure. -Remote Devices(S) - A device that participates in the service discovery process by responding to -the service inquiries generated by Local Device. -The following features shall be provided by the Supplier: -Search for services by service class -Search for services by service attributes -Service browsing -5.1.1.1.11 Device Information Profile -Device Identification Profile (DIP) has to be supported as well as Profiles/Protocols for -necessary lower layers. -Items marked with "x" in AGL column in Table 28 should be supported. -**Table 28 : List of DIP Supporting Functions** -Page 90 of 159 - - > **No.** > **Feature** > **Support** > **AGL** - ----------- ----------------------- --------------- ----------- - > 1 > SpecificationID > Mandatory > x - > 2 > VendorID > Mandatory > x - > 3 > ProductID > Mandatory > x - > 4 > Version > Mandatory > x - > 5 > PrimaryRecord > Mandatory > x - > 6 > VendorIDSource > Mandatory > x - > 7 > ClientExecutableURL > - > - - > 8 > ServiceDescription > - > - - > 9 > DocumentationURL > - > - - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.1.1.12 Bluetooth Smart Ready -Bluetooth Smart Ready shall be supported. -It shall comply with Bluetooth Low Energy standard. -5.1.1.1.13 Generic Object Exchange Profile (GOEP) -The Telephony system shall implement Generic Object Exchange Profile as per the GOEX -specification version 2.0 or later. -The Telephony system shall use this profile to facilitate the exchange of binary objects between -devices. The usage model shall be Synchronization, File Transfer or Object Push model. -It shall provide following roles: -Server - This is the device that provides an object exchange server to and from which data -objects shall be pushed and pulled, respectively. -Page 91 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Client - This is the device that can push or/and pull data object(s) to and from the Server. -The following features shall be provided by the Supplier: -Establishing an object connection -Pushing a data object -Pulling a data object -Performing an action on data objects -Creating and managing a Reliable Object Exchange Connection -5.1.1.1.14 Generic Audio/Video Distribution Profile -The Telephony system shall implement Generic Audio/Video Distribution Profile as per the -GAVDP specification version 1.2 or later. -The Telephony system shall use this profile to specify signalling transaction procedures between -two devices to set up, terminate, and reconfigure streaming channels. -It shall provide following roles: -Initiator (INT) -Acceptor (ACP) -Following are the feature requirements for this profile: -Connection -Transfer Control -Signalling Control -Security Control -Note: This profile is currently being enhanced to version 1.3. Release date of this version is not -yet finalized. The Telephony system shall be able to upgrade to the newer version in the future. -5.1.1.1.15 Bluetooth Diagnostics -**5.1.2 Error Management** -The Error Management module provides platform error handling mechanisms. This includes -Page 92 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -detecting system errors that occur after start up to provide a recovery function by localized -restart. In addition, -in case of a broad ranged malfunction, Error Management provide quick detection and recovery -to issue in a short amount of time. -**5.1.2.1 Use Cases** -5.1.2.1.1 System Surveillance and Recovery -While using in-car information device, if the whole system or part of the function stops, an -immediate error detection and automatic recovery will be needed. For example, when updating -the screen while route guidance is on or voice recognition cannot be used, restart the function to -try and recover. When an error occurs in the core of a system such as an output communicating -middle ware, reboot the whole system to try and recover. -There are several supposed cases for system surveillance such as a case where the system that -adopted AGL and monitors by itself or monitored by the system that has not adopted AGL. The -AGL Error Management scope includes parts of the system that adopted AGL. -The way of recovery has to be assessed by the status of the system behavior. For example, even -if the way to recover the car navigation error might be reboot, the system reboot should not be -done when the car navigation is displaying back camera image. Because of these use cases, Error -Management should focus on the degree of importance for surveillance list process and the -degree should be adjusted by its behavior status. -5.1.2.1.2 Collecting Information -For when the system failure occurred after the launch, the most urgent item is a prompt -recovery but what is also a point that is worth noting is to collect the information to specify the -cause for its failure. Therefore, gathering information with the minimum recovery time is needed. -With Linux system, memory image dump (core dump) of generally abended process is used. On -the other hand, a scale of middleware which is an in- car application is increasing and has come -Page 93 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -to the point where the time to dump the entire memory image is impermissible. To avoid this, -the Error Management function will provide the system to leave the light log. -**5.1.2.2 Requirements** -Prevent the system failure shutoff and also in case of failure provided the function that judge its -status automatically and recover -The Error Management module should support both surveillance of the whole system and each -process. -The Error Management module should monitor the memory usage of whole system cyclically. -When memory usage exceeds set threshold value, a set action should be done. Cycle, threshold -value, action is changeable by AGL user. -Kernel function that requires Error Management surveillance, driver has to send a notification -to Error Management when an error occurs. The subjects that sends error notifications are -output communication or disk I/O. -Error Management should be able to execute the action after obtaining the error notification -by kernel function and the driver. Action should be changeable by AGL user. For example, an -error for CAN communication is critical so system restart could be done but USB communication -error can be ignored since it may be caused by a compatibility issue between devices. -Error Management should monitor processes for existence or non-existence, when abended it -should execute a set action. The set action should be changeable by the AGL user. Termination -of resident process is a defect but termination of a temporal behaving process is correct so -those two should be able to set separately. -Error Management should monitor the process with a set cycle and when it goes over threshold -value, should be able to execute the set action. Cycle, threshold value, action should be -changeable by AGL user. The subjects of surveillance are CPU usage and memory usage. -Should be able to vanish process forcibly including subsidiary process -Page 94 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Make the software that works by system have the concept of level importance. -Appropriate recovery depending on the level of importance. The level of importance should be -adjustable depending on the status of operation by coordinating with Policy. -The process that detecting an external communication error within the Error Management -module and recovering has to be set to complete before external monitoring detects. -The application that is monitored by the Error Management modulehas to be independent as -more than one process. -The application that is monitored by the Error Management moduleshould not combine multiple -applications to one process. Application’s runtime part does not have the structure where -multiple applications can be moved by the same process. -Service providing side has to be nondense to the application. For example, the Service providing -process such as a software keyboard should not go wrong with the state of App. Such as -process crash, exit, etc.. -An application has to be nondense to an application. When linking two application one ends -suddenly the other will not become abnormal state. -The process that communicates with the external system has to be independent from the other -process while recovering that does not include system restart so that it can notify alive towards -external side. -When the software that is under the surveillance of RAS can not recover with one restart -additional process can be done such as deleting the subject files that were registered -beforehand. -The system has to have a structure where overwrite the files that are stored in a pinned file -system without destroying them. -Page 95 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -When system down occurs (kernel panic), should be able to collect the information need for -analyzing. -When making the system down happen intentionally( BUG\_ON etc.),make sure to leave a -message that can specify the cause. -Both the log which is for debug and can take time to output and the log that leaves minimum log -in a short period of time have been equipped and able to select. -In any abnormal cases log output does not lock the system (stand by for spin lock etc.) or -system down does not occur (self-destruction on log output process). -Should be able to leave the aberrance occurred in kernel area on the log. -Should be able to select the level of log output. -Should be able to record the aberrance log with the time of occurrence. -Should be able to obtain the information linked to the system resources. -Should be able to leave the information corresponding to core dump in a short period of time. -Both the log which is for debug and can take time to output and the log that leaves minimum log -in a short period of time have been equipped and able to select. -As the smallest amount of information, the following information should be left. -· Register information -· Process logical memory map -· -Stack dump or back trace from the exceptional place of occurrence -· Time of occurrence -· -Information that can specify the occurred process thread (name of an executing -file‑name of the thread etc.) -Page 96 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· The signal that occurred -Lightweight core dump is a core dump that can set the restrictions below. -· -Select the memory mapping category of process executing memory image that targeted -for an output. -· -Specify the order of an output and output high-priority memory mapping first to prevent -dropping the information needed. -· -Output only the memory mapping that is linked to the abnormal process (text area). \[O\] -· -Compress the data for each memory mapping category and output up to the fixed -maximum size. -· -NOTE information of ELF header and program header will not change. -Selectable memory mappings are the following. -· anonymous private mappings -· anonymous shared mappings -· file-backed private mappings -· file-backed shared mappings -· private huge page -· shared huge page -Setting parameters of the output context are the following. -· -Memory mapping category which is for an output object can be set. -· The order of outputting memory mapping can be set. -Should be able to leave the log in increments of process. Possible to filter and have a look in -increments of process. -Should be able to leave a trace log in increments of process during process crash. Should be -able to leave a trace log in increments of process during system running, if necessary. -Should be able to obtain the information related to system resource of process. -Page 97 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -There should be a structure to be able to error trace among the whole process in a user space. -**5.1.3 Graphics** -Graphics subsystem; HMI input, wayland, windowing, etc. -**5.1.4 Location Services** -Location services includes support for GPS, location, and positioning services including dead -reckoning. Time of day support is also included in Location Services since time is a primary -output of the GPS receiver. -**5.1.4.1 Position** -**5.1.4.2 Time of Day** -With Linux, time adjusting is generally done by using date command or NTP but since in-car -device can obtain the accurate time from GPS, GPS time is often used as Abs Time. Because of -its advantage where this GPS demand can be done anywhere in the world, it would continue in -future. Therefore, we are going to need a structure for adjusting the Linux system time. -**Monotonic and Absolute Time Support** -As a weak point of GPS, when cold start, it takes a long time to obtain the accurate time. -Because of this, it will not set the right time for booting the system and will adjust it while it’s -moving. As for in-car device, the demand to make the system boot faster is rather strong and -Abs Time can vary while it’s working for one of the middle ware applications. -On the other hand, although POSIX API which is used as a standard for Linux, provides the time -that has not been effected by the adjusting in case of a simple latency, but for resource latency, -some of them can only set with Abs Time. Therefore, in-car Linux needs an API that supports -Monotonic Time. -**Kernel Time Precision** -Page 98 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -In-car device needs to support all kinds of communicating system such as CAN. Those -communicating system includes the device that needs ms order procedure. -In Linux Kernel space, jiffies are used as mere time. However 1jiffies time differs depending on -the CPU architecture and the architecture differs depending on SOC. Because of this, the lowest -value for unit of time that AGL environment has to support needs to be decided. -**5.1.4.3 Requirements** -Should be able to adjust the system time from GPS middle ware. -Adjust the system time after the time is determinate. -GPS middle ware has to have the system where it can implement GPS driver control parts using -the plugin (source plugin). Must tolerate proprietary GPS component. -GPS middle source plugin must tolerate proprietary. Source plugin has to be a license that is not -imposed a duty to open source. For example, header library’s license that is needed to make -Source plugin can not be GPL or LGPL. -When waiting, can use both absolute time and monotonic time -Resource obtaining time out such as mutex, semaphore can use both absolute time and -monotonic time. -Resource obtaining time out such as mutex, semaphore can use both absolute time and -monotonic time. -System time must be able to use consecutively at least until 2099. -Absolute time has to support leap year and leap seconds. -1 jiffies have to be smaller than 1ms. -Page 99 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Time waiting that involve context switch, must be done with the accuracy over 1ms. -From timer / ISR, can boot tasklet with the accuracy 1ms. -A system has to be able to handle time with at least the accuracy 1ms. -**5.1.5 Health Monitoring** -Platform monitoring services such as watchdog or active monitoring -**5.1.6 IPC** -Standard platform interprocess and interprocessor communication mechanism. -**5.1.7 Lifecycle Management** -Startup, shutdown, state change, etc. -**5.1.8 Network Services** -Includes standard networking protocols such as TCP/IP via any networking physical layer -including Wifi, Bluetooth, or ethernet. -**5.1.9 Persistent Storage** -Power safe persistent storage -**5.1.10 Power Management** -Amount of ECUs in the car and their complexity has grown dramatically over last decade. Needs -in processing power are constantly growing to catch up with demands of automotive industry. -*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* -Page 100 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -modern ECUs -In parallel, success of green, electric cars is pushing power budget limits down as never before, -in distant future we may see “battle for watts” in automotive electronics. Finding optimal -balance between performance and ECU operating modes, frequencies, voltages is also important -for overall durability characteristic. -Suspend/resume techniques and retention of the ECU in lower power states now becoming -more welcomed over traditional cold boot approaches. -Linux community has been working on power management architecture for many years, it has -become a state of art framework and set of components that addresses needs not only -consumer electronics industry, but also industrial automation, security, etc.) -**5.1.10.1 Requirements** -AGL kernel shall allow switching between active and suspend states. Exact definition of suspend -states is platform/architecture-specific (e.g. “suspend to memory”, “suspend to disk” -/“hibernate” correspond to S3 and S4 in ACPI terminology) -Kernel and peripheral device drivers shall not be affected by suspend/resume transitions. -AGL kernel shall provide sufficient APIs for application to control active/suspend state -transitions and receive appropriate events/notifications. Kernel should not initiate power state -transitions if no requests provided from applications. -Detailed definition of steps/actions required for suspend/resume sequence is out of the scope of -this specification (it is also platform-dependent). -AGL kernel for SMP configurations shall allow enabling/disabling of individual cores (or group of -cores) (NOTE: on some platforms/architectures enabling/disabling may be achieved by putting -core in one of its low power states) -AGL kernel shall only provide mechanism for applications to request enabling/disabling particular -cores from SMP group. -Page 101 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -AGL kernel shall support CPU frequency and voltage scaling. Exact definition of operating points -(table of frequencies/voltages allowed by hardware) is platform/architecture-specific (moreover, -some of operating points may be omitted/ignored in AGL kernel as their impact on power budget -insignificant) -Kernel and peripheral device drivers shall not be affected by CPU frequency and voltage scaling -Only application-defined policies shall be allowed for CPU frequency and voltage scaling. -Default in-kernel governors/policies (e.g. on-demand or performance) shall not be used and they -may have negative impact on overall system performance/predictability -AGL kernel shall allow switching between active and idle states. Exact definition of idle states is -platform/architecture-specific (e.g. C0..C4 in ACPI terminology or WFI+… for ARM) -Kernel and peripheral device drivers shall not be affected entering/leaving one of idle states -Only application-defined policies shall be allowed for CPU Idle -AGL kernel shall support run-time power management of I/O (peripheral) devices -AGL kernel shall support I/O (peripheral) device voltage and frequency scaling -**5.1.11 Resource Management** -Resource and device management. -Resource Management shall provide an interface to be used for informing status of a resource -request by the Resource Manager. -**5.1.12 Telephony Services** -**5.1.12.1 Requirements** -Page 102 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.12.1.1 Telephony variants -Purpose: To define the variants of Telephony -Requirement: -There will be 2 variants of phone system. -Variant 1: Front User only Telephony. -Variant 2: Rear and Front Telephony. -All variants will have Bluetooth capability. The feature will be configurable so that the feature -can be disabled via car configuration. -**5.1.13 Wi-Fi** -This Wi-Fi subsystem controls registration, connection management, and device information -management between a wireless LAN device and infotainment system. -Necessary Wi-Fi specification in automotive use case is defined here. -**5.1.13.1 Use Cases** -5.1.13.1.1 Construct WiFi Network -In-Vehicle Infotainment systems constructs 3 types of Wi-Fi networks. -a\. STA -In-Vehicle Infotainment system acts as a STA (Station) and connects to an external network via -an Access Point. -It also connects to Access Points which support Wi-Fi Hotspot. -b\. AP -In-Vehicle Infotainment system acts as an AP (Access Point) and connects multiple Wi-Fi devices -with an external network. -Page 103 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -It also connects Wi-Fi devices which support Wi-Fi Hotspot. -c\. P2P -In-Vehicle Infotainment system and Wi-Fi device makes P2P (Peer to Peer) connection using Wi- -Fi Direct. -5.1.13.1.2 Miracast -In-Vehicle Infotainment system and Wi-Fi device shares a display using Miracast.-(a) -They are also remotely operated to a Wi-Fi device from the infotainment system, or vice versa, -by using UIBC (User Interface Back Channel).-(b) -**Figure 8-29 : Overview of Miracast** -a\. Shared Displayed Content -Page 104 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Use case examples of shared displayed content are: -· -A passenger on the passenger seat views the multimedia content played on Wi-Fi Device -(e.g. Mobile) on In-Vehicle Infotainment system. -· -A rear seat passenger views the multimedia content played on In-Vehicle Infotainment -system on Wi-Fi Device(e.g. Rear seat monitor). -b\. Remote Operation -Use case examples of remote operation are: -· -A passenger on the passenger seat plays the multimedia content stored in Wi-Fi Device -(e.g. Mobile) by operating In-Vehicle Infotainment system. -· -A passenger on the rear seat controls air conditioner functionality in In-Vehicle -Infotainment system by operating a Wi-Fi Device (e.g. Mobile). -· -While the vehicle is in motion, a passenger on the rear seat controls the navigation -functionality in a passenger on the rear seat controls by operating a Wi-Fi Device(e.g. -Mobile). -5.1.13.1.3 DLNA -In-Vehicle Infotainment system connects with a DLNA device via Wi-Fi. -**5.1.13.2 Requirements** -5.1.13.2.1 Security -The WiFi module shall support security standard WEP. -It shall support 40 bit WEP encryption method. -It shall support 104 bit WEP encryption method. -It shall support security standard WPA Personal. -Page 105 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -It shall support TKIP encryption method. -It shall support CCMP encryption method. -It shall support security standard WPA2 Personal. -It shall support TKIP encryption method. -It shall support CCMP encryption method. -It shall support security standard WPA Enterprise. -It shall support TKIP encryption method. -It shall support CCMP encryption method. -It shall support security standard WPA2 Enterprise. -It shall support TKIP encryption method. -It shall support CCMP encryption method. -5.1.13.2.2 Simple Configuration -It shall comply with WPS (Wi-Fi Protected Setup) standard. -It shall be able to perform connection with PIN (Personal Identification Number) method. -It shall support Configuration Method for Display. -Page 106 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -It shall support Configuration Method for Keypad. -It shall be able to perform connection with PBC (Push button configuration) method. -It shall support Configuration Method for PushButton. -It shall be able to perform connection with NFC (Near Field Communication) method. -5.1.13.2.3 QoS -It shall comply with WMM (Wi-Fi Multimedia) standard. -It shall comply with WMM-PS (Wireless Multimedia Power Save) standard. -5.1.13.2.4 STA -The In-Vehicle system shall be able to function as a STA (Non-AP Station). -5.1.13.2.5 AP -The In-Vehicle system shall be able to function as an AP (Access Point). -5.1.13.2.6 WiFi Direct -It shall comply with Wi-Fi Direct standard. -It shall support the WiFi Direct functions as listed in Table 29. -Page 107 of 159 - - -------------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **(Reference)** - > - > **Support in Wi-** - > - > **Fi Direct** - ----------- ---------------------------------------------------- -------------------------- ------------------------ - > 1 > P2P Provision > ‑ > Mandatory - > - > Discovery - - > 2 > P2P Device Discovery > Scan Phase > Mandatory - - > 3 > ‑ > Find Phase > Mandatory - - > 4 > P2P GO Negotiation > ‑ > Mandatory - - > 5 > P2P Service Discovery > ‑ > Option - - > 6 > P2P Invitation > Temporary P2P Group > Option - - > 7 > ‑ > Persistent P2P Group > Option - - > 8 > Persistent P2P Group / Persistent Reconnect > Option - - > 9 > Intra-BSS Distribution > ‑ > Option - - > 10 > Concurrent Operation > ‑ > Option - - > 11 > P2P Service Discovery > UPnP > Option - - > 12 > ‑ > Bonjour > Option - - > 13 > ‑ > Wi-Fi Display > Option - - > 14 > ‑ > WS-Discovery > Option - - > 15 > ‑ > Vendor specific > Option - -------------------------------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.13.2.7 Miracast -Page 108 of 159 - - -------------------------------------------------------------------------------------------------------------- - > ‑**No.** > **Feature** > ‑ > **(Refere** - > - > **nce)** - > - > **Suppor** - > - > **t in** - > - > **Miracas** - > - > **t** - ------------ ----------------------------------------------------- ----------------------- ------------------- - > 1 > WFD Device type > WFD Source > Mandat - > - > ory - - > 2 > ‑ > Primary Sink > Mandat - > - > ory - - > 3 > ‑ > Dual-role possible > Option - - > 4 > WFD Service > ‑ > Option - > - > Discovery - - > 5 > WFD connection establishment with Wi-Fi P2P > Mandat - > - > ory - - > 6 > WFD connection establishment with Wi-Fi TDLS > Option - - > 7 > Persistent WFD > via Wi-Fi P2P > Option - > - > Group - - > 8 > ‑ > via TDLS > Option - - > 9 > WFD Capability Negotiation (RTSP) > Mandat - > - > ory - - > 10 > WFD Session Establishment (RTSP) > Mandat - > - > ory - -------------------------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -It shall comply with Miracast standard. -It shall support the Miracast functions identified in Table 30. -Page 109 of 159 - - --------------------------------------------------------------------------------- - > 11 > AV Streaming and Control (MPEG-TS/RTP/RTSP) > Mandat - > - > ory - ------ --------------------------------------------------- ----------- ---------- - > 12 > WFD Standby (RTP/RTSP) > Option - - > 13 > Video CODEC formats > Option - - > 14 > Audio CODEC formats > Option - - > 15 > UIBC > Generic - - > 16 > HIDC - --------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.1.13.2.8 WiFi Hotspot -It shall comply with Wi-Fi Hotspot standard. -In-Vehicle system which acts as an a STA(Non-AP Station)shall be able to connect with Hotspot -service. -In-Vehicle system which acts as an AP (Access Point) shall be able to provide Hotspot service. -5.1.13.2.9 DLNA via WiFi -The In-Vehicle system shall be able to connect with DLNA devices via Wi-Fi. -**5.1.14 Window System** -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. -Page 110 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.2 Automotive Services -Automotive Services Layer contains services that are not found in a typical Linux distribution but -contains services specialized for automotive applications. -**5.2.1 Audio Services** -BTBF, equilization, mult-zone audio control, etc. -**5.2.2 Camera Services** -Standard interface to vehicle mounted cameras; backup camera, side and front cameras, etc. -**5.2.3 Configuration Services** -Service for storing configuration parameters. -**5.2.4 Diagnostic Services** -Diagnostic services. -(This is automotive diagnostics such as storing and retrieving DTC. ) -**5.2.5 Multimedia Services** -CD, DVD, Blu-Ray, MP3, etc. -(Factor out metadata into separate component.) -**5.2.5.1 Media Player** -In-vehicle multimedia system shall provide rich and robust user-experience that includes not just -Page 111 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -support of multiple audio-video formats, but also variety of input and output audio/video -devices, both static and dynamically pluggable. In contrast to mobile or desktop applications, -there is normally more than one consumer of multimedia content in a car, with front- and rear- -seat passengers as well as driver all having independent requirements. -The following requirements are considered essential for in-vehicle multimedia system: -· -Supported multimedia formats shall correspond to major end-user expectations, i.e. the -ones encountered in mobile and desktop world. -· -Multiple audio / video sources and sinks, both static (i.e. always existing in the system) -and dynamic (i.e. appearing and disappearing when user connects a Bluetooth headset or -establishes a network connection.) -· -Multiple independent consumers of multimedia data and globally configurable routing of -audio / video processing chains. -Latency requirements of audio/video processing may also vary depending on a type of the data -processed; e.g. data from rear-view camera shall be decoded and visualized “instantly” in -comparison to a movie clip displayed on rear-passenger monitor, voice notification from -navigation software shall not be delayed significantly, speech data passed to and from -Bluetooth headset during phone conversation shall have reasonably bounded latencies and so -on. -It is considered that multimedia system may consist of multiple processing units, and therefore -processing load balancing mechanism shall be present. Mechanisms of audio/video processing -offloading to dedicated processing units (hardware acceleration) shall be provisioned, with -particular implementation freedom left for a silicon vendor. -The following requirements formalize these considerations. -**5.2.5.2 Requirements** -5.2.5.2.1 Media Containers -AGL shall provide an API that allows handling of various media data within the system. This -includes audio/video playback and recording as well as media streaming over the network. It -shall be possible to run multiple media streams in parallel for all IVI users, with configurable -input/output devices routing. Multimedia framework does not necessarily need to be isolated -from application (that is, it may run in the same address space as application), however it shall -be guaranteed that independent applications using the framework are isolated from each other. -Page 112 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -AGL shall provide support for extraction from media containers streams other than audio-visual, -for example subtitles. Application shall be able to retrieve timing information as well as stream -identification data from media container. -AGL shall provide support for major network streaming protocols such as: -· HTTP -· RTPS -· Digital Radio (DAB) -· DigitalTV (DVB-T) etc. -It shall be possible to extend the set of supported streaming protocols in accordance with -system requirements. -AGL shall provide a mechanism to utilize available hardware accelerators to offload -computationally extensive processing to specialized units in vendor-specific way. Such -extension, if available, shall be transparent to the applications. -Lip Synch must be implemented as plug-in software for Multimedia Framework. -AGL shall provide a mechanism to automatically detect type of media data contained in the -source file, and to instantiate all required components to organize data processing without -intervention of the application. It shall be, however, possible for application to control this -process if it is essential for its functionality. Example of such intervention would be selection of -particular audio track (in user-chosen language) or selection of particular video stream from -multiple choices. -AGL shall provide an API to control execution of audio/video processing chain, specifically shall -support the following functionality: -· -Selection of data source and destination (files, devices, network resources) -· Pausing/resuming of multimedia streams -· Rewinding in forward and reverse directions (for playback) -· Audio volume control on per-stream basis -· Retrieval of current stream position (timestamp) -Page 113 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· -Notifications on error conditions preventing multimedia stream processing -AGL shall provide a mechanism to specify routing of input and output devices that are involved -into multimedia data processing. In particular, for playback scenario it shall be possible to -specify where audio and video data is rendered, and for recording scenario it shall be possible to -specify capturing source. It shall be possible to organize broadcasting of decoded raw -audio/video streams to multiple renderers as well. -AGL shall include a dedicated sound server that simplifies routing, mixing, post-processing and -synchronization of raw PCM audio streams. Specifically, the following functionality is expected: -· -Support for multiple audio sources and audio sinks with arbitrary (configurable) routing. -· Per-stream volume and audio effects control. -· -Resampling and format conversion (e.g. channels downmixing, sample width conversion). -· -Sample-accurate streams synchronization (e.g. for echo-cancellation purpose). -· Mixing and broadcasting of the audio streams. -AGL shall provide a mechanism to control sound server configuration in run-time, that is, to -specify the rules and policies defining system response to external events like adding or -removing of new audio device (e.g. Bluetooth headset connection), receiving of the phone call, -emergency system alarm output and so on. -AGL shall provide support for major multimedia containers, such as: -· MPEG2-TS/PS (ISO/IEC 13818-1) -· MP4 (MPEG-4 Part 14, ISO/IEC 14496-14:2003) -It shall be possible to extend the set of supported multimedia formats in accordance with -system requirements. -It must be possible to extend AGL to support additional optional multimedia containers such as: -· OGG (RFC 3533) -· 3GPP (ISO/IEC 14496-12) -· etc -Page 114 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -5.2.5.2.2 Media Audio Codecs -AGL shall provide support for major audio codecs, such as: -· -MP3 (MPEG-1/2 Audio Layer-3, ISO/IEC 11172-3, ISO/IEC 13818-3) -· AAC (ISO/IEC 13818-7, ISO/IEC 14496-3) -It shall be possible to extend the set of supported audio codecs in accordance with system -requirements. -It must be possible to extend AGL to support additional audio codecs, such as: -· VORBIS (http://xiph.org/vorbis/) -· Windows Media Audio -· etc. -5.2.5.2.3 Media Video Codecs -AGL shall provide support for major video codecs, such as: -· MPEG-2 (ISO/IEC 13818-2) -· MPEG-4 Part 2 (ISO/IEC 14496-2) -· H.264 (MPEG-4 Part10, ISO/IEC 14496-10, ITU-T H.264) -It shall be possible to extend the set of supported video codecs in accordance with system -requirements. -It must be possible to extend AGL to support additional video codecs, such as: -· Theora (www.theora.org) -· Windows Media Video -· etc -5.2.5.2.4 Image File Formats -Page 115 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -The system shall be able to perform all required operations on viewing of Image in BMP, up to 32 bit true -colour. -Compression formats -· RLE 8 bits/pixel -· RLE 4 bits/pixel -· Bit field or Huffman 1D compression -· JPEG or RLE-24 -· PNG -The system shall be able to perform all required operations on Viewing of Image in JPEG/JPEG 2000 -The system shall be able to perform all required operations on viewing of Image in JPEG XR/HD, including -Exchangeable Image File Format (EXIF) format. -The system shall implement the ability to perform all required operations on Viewing of Image in PNG, -including transparency -The system shall be able to perform all required operations on viewing of Image in GIF 87a and enhanced -version 89a and also animation in GIFF images. -The system shall be able to perform all required operations on viewing images in TIFF format. -The system shall implement the ability to perform all required operations on viewing of Image in WBMP -format. -The system shall implement the ability to perform all required operations on viewing of Image in WBMP -format. -**5.2.6 Navigation Services** -Navigation engine -Page 116 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**5.2.7 PIM** -Personal Information Manager; calendar, appointments, reminders, etc. -**5.2.8 Smartphone Link** -This section describes regarding Smartphone link. Smartphone Link is the technology which -realizes that video and audio streaming play which data from smartphone. And touch operation -is possible to share between IVI and smartphone. MirrorLink, Miracast, SmartDeviceLink and -AirPlay are technologies that realize Smartphone Link. By this technology, it is possible to use -smartphone content (map, music, browser...) by IVI. -Figure 8-30 shows the system structure of the Smartphone Link. -**Figure: 8-30** -Page 117 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -AGL defines following requirements of Smartphone link. -1. The screen of smartphone shall be mirrored to IVI. -2. The sound of smartphone shall be linked to IVI. -3. The sound shall be synchronized with the screen. -4. IVI should operate smartphone. -5. The response time of operations from IVI should be less than 200ms. -6. If connection between smart phone and ivi was disconnected by external factor, then should -inform the "disconnection" to a user and return to the normal state. -This document describes “Miracast” and “SmartDeviceLink” from the reference of Smartphone -link. -**5.2.8.1 Miracast** -This section describes requirements regarding Smartphone link (Miracast). -Miracast is the display transfer technology using wireless connection which was defined by Wi- -Fi Alliance. Send screen data from source device to sink device and it realize display sharing -between source device and sink device. -Following figure (Figure: 8‑31) shows the system structure of Miracast. -**Figure: 8-31** -Page 118 of 159 - - ---------------------------------------------------------------------------------------------- - > **No** > **Requires** > **Description** - ------------ ----------------------------- --------------------------------------------------- - > SPL.1.1 > WFD Topology > Define role of Miracast - - > SPL.1.2 > Connection Topology > Define connection condition between - > - > a smartphone and an IVI - - > SPL.1.2. > P2P Topology > Define connection method of P2P (Wi-Fi - > > - > 1 > Direct). - - > SPL.1.2. > Wi-Fi Frequency > Define Wi-Fi frequency - > - > 2 - - > SPL.1.3 > Video Format > Define Video format - - > SPL.1.4 > Audio Format > Define Audio format - - > SPL.1.5 > Session Control > Define Miracast session state - - > SPL.1.6 > Link Content Protection > Define content protection function required - > - > for implementing Miracast - - > SPL.1.7 > Resource Management > Define resource management - ---------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Follow reference documents to support Miracast if there was no description of this section. -**References** -\[1\] Wi-Fi Display Technical Specification Version 1.0.0 -\[2\] W-Fi Peer-to-Peer (P2P) Technical Specification Version 1.2 -\[3\] High-bandwidth Digital Content Protection System Interface Independent Adaption Revision -2.2 -\[4\] DCP (Digital Content Protection) <http://www.digital-cp.com/> -AGL provide display sharing technology between Smartphone and IVI system using Miracast. -Page 119 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -SPL.1.8 Fail-safe Control Define Fail-safe control -**Table 8-14: Smartphone Link (Miracast) Requirements** -**Figure: 8-32 State Change Diagram** -The states of Smartphone link (Miracast) is defined in Table 8-32. -Page 120 of 159 - - ------------------------------------------------------------------------------------------------------- - > **No.** > **State** > **Description** - ----------- ------------------------- ----------------------------------------------------------------- - > 1 > Idle > Smartphone link (Miracast) function is not initialized. - - > 2 > Initialized > Smartphone link (Miracast) function is initialized and - > - > waiting for Wi-Fi P2P connection from source - > - > device. - - > 3 > Connected Wi-Fi P2P > Established Wi-Fi P2P connection with source - > - > device. - - > 4 > Initiated > Smartphone link (Miracast) session is established. - - > 5 > Play > Streaming the audio and video content from source - > - > device to sink device. - - > 6 > Pause > Paused the streaming of audio and video content - > - > from source divide to sink device. - ------------------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**5.2.8.2 Smart Device Link** -“Smart Device Link”, aka “SDL”, is template based approach of smartphone link capability. -Application itself is in a mobile phone, however, HMI is provided by IVI system. This approach -makes it possible to apply IVI adapted user experience, such as larger button to prevent driver’s -distraction and voice recognition. -That means, application requests to IVI system, then IVI system will respond by using remote -procedure calls. Application’s HMI will be rendered by IVI system by using IVI’s HMI framework -and/or policy, though all the application’s logic is contained in mobile phone. -SDL provides more suitable HMI for IVI rather than mirroring type approach, however, mobile -phone’s application must support SDL capability. In other words, only SDL supported -applications can be launched. -Page 121 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**Figure 8-33 : SDL overview** -**5.2.8.3 Requirements** -5.2.8.3.1 Miracast -System must provide a capability of Miracast as smartphone link function. -· -Support WFD Primary Sink and support MPEG2-TS(Video, Audio) streaming play which -from Source Device‑Smartphone‑. -· Supporting WFD Source is an option. -· -Support customize function using “Miracast setting file” which used for negotiation (\*1) -source device and sink device (\*1. Video format, audio format and other parameters). -· -Screen data which from Smartphone may not support Drivers Destruction, therefore take -measures to Drivers Destruction. (e.g. Disable Miracast during vehicle speed over -5Km/H) -· Support Wi-Fi P2P connection. -· -Follow reference \[1\] and reference \[2\] to support Wi-Fi P2P function, parameters in -Miracast connection and so on if there was no description of this section. -· Wi-Fi TDLS connection is an option. -· -AGL do not define confliction specification regarding Wi-Fi connection. (e.g. User select -Wi-Fi P2P connect ion during accessing Wi-Fi connection.) -· -AGL do not define confliction specification regarding Sink device operation when receive -Page 122 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -connection request from Source device. (e.g. Connect automatically, ask user for -confirmation) -· -Support P2P Group Owner and P2P client as the topology of Wi-Fi P2P connection. -· -Support DHCP server and DHCP client for TCP/IP seamless connection after P2P -connection established. -· -Support 2.4GHz band for the frequency of Wi-Fi P2P connection. -· -Supporting 5GHz band is an option, but support DFS (Dynamic Frequency Selection) -function if support 5GHz band. -· Follow reference \[1\] for Video Codec. -· Support follow format for Video Resolution and Frame rate. -o 640\*480‑VGA‑‑Progressive 60 fps -o 1280\*720‑HD‑Progressive 30 fps -Regarding Video resolution and Frame rate, other formats are an option. -· Support follow format for Audio. -o LPCM 48ksps 16bit 2ch -o AAC 48ksps 16bit 2ch -Regarding Audio Format, other formats are an option. -When the state changes "Pause", take measures to give notice of pause for user. (e.g. pop-up -notification) -Screen data which from Smartphone may be protected by content protection, therefore support -content protection function. -· -AGL recommend HDCP function which described reference \[2\], \[3\]. But AGL do not -define HDCP function. Each vendor should support content protection function as for -Page 123 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -vendor’s own reason. -· Support both encryption cases if support HDCP function. -o Case1 Videos data encryption -o Case2 Both video and audio encryption -Take notice that it is necessary to satisfy security requirements specified according to -DCP.(reference \[4\]) -· -Miracast must support interruption by other function. If some high priority event occurs, -then Miracast release screen and audio resources for the event. -· -It is selectable how to deal Miracast session. (Standby Miracast session or close Miracast -session.) -· -Support a notification to a user and returning to the normal state, if following events -happen. -o Failed to Wi-Fi connection -o Failed to establish Miracast session -o Wi-Fi link loss on Miracast -o Break Miracast connection from smartphone -5.2.8.3.2 Smart Device Link -System must provide a capability of Smart Device Link as smartphone link function. -System must provide a mechanism to render HMI of SDL according to template. -System must provide a mechanism to enable user interface regarding SDL by using touch panel -device of IVI device. -System must provide a mechanism to enable user interface regarding SDL by using voice -Page 124 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -recognition of IVI system. -System must provide a mechanism to link Android device regarding SDL capability. Connectivity -method must be supported Bluetooth and/or Wi-Fi. -System must provide a mechanism to link iPhone device regarding SDL capability. Connectivity -method must be supported Bluetooth and/or Wi-Fi. -**5.2.9 Speech Services** -The Speech Services module provides voice recognition and synthesis for AGL applications. -AGL system voice framework must be able to record and interpret voice commands -AGL system voice framework must be able to convert text to synthesized speech -**5.2.10 Tuner Services** -The Tuner Services module provides a mechanism that allows different tuner types to plug into -the same API regardless of the receiver type. Support for AM/FM, HD Radio, SDARS, DAB, DRM, -TV Tuners etc is provided. The Tuner Services module shall allow multiple tuners to be present -in the same system and allow its clients to address each tuner in the system independently. -**5.2.10.1 Receivers** -The Receivers module of Automotive Grade Linux may control different receiver types including -AM, FM, Hybrid Digital (HD) Radio, SDARS, and DAB tuners. The module may access any -number of different tuners. For all tuner types the module supports accessing station data from -the tuner, changing the receiver frequency or station and reading station metadata about current -content. -The Receivers module shall provide a mechanism that allows different tuner types to plug into -the same API regardless of the receiver type. -Page 125 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -The Receivers module shall allow multiple receivers to be present in the same system and allow -its clients to address each receiver in the system independently. -5.2.10.1.1 HD Radio -HD Radio is a proprietary In-Band on Channel (IBOC) system created and owned by Ibiquity. An -HD radio receives analog AM/FM signals and can also use digital information in a subband to -provide additional stations and/or enhance the audio quality of the main station. When the -receiver is decoding digital data for AM/FM playback it is commonly thought of as HD Radio. The -HD Radio system architecture shall conform to the broadcast system design proposed by the -iBiquity Digital Corporation detailed in RX\_SSFD\_5029. Both the HD hardware and functional -design shall meet all iBiquity Digital specifications, and satisfy the Type Approval specified by -iBiquity Digital. -The IBOC hardware is assumed to have three modes which will be used to describe the -requirements in this section. -1) AM - radio is decoding an over the air AM station. -2) FM - radio is decoding an over the air FM station. -3) HD - radio is decoding an AM or FM station using the subband for the over the air station. -Each requirement may refer to AM and/or FM and/or HD to specify the modes the requirement is -applicable to. -AM/FM/HD system shall be able to enable/disable the HD radio reception and present the status -to the system. -AM/FM/HD tuner shall be able to tune to a specified frequency and report the result of the -tuning process. The possible results are, Tuning successful and Tuning unsuccessful. If Tuning -successful event is notified by the tuner, it shall play the audio through the selected audio -output. If tuner notifies the Tuning unsuccessful event, the system shall inform that "No -Reception" is available in that specific channel. -AM system shall extract following parameters from a successfully tuned channel and present to -the system, which shall be added in the station database. -Page 126 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· Frequency -· Mono/Stereo -FM system shall extract following parameters from a successfully tuned channel and present to -the system, which shall be added in the station database. -· Frequency -· PI Code (RDS only) -· PTY (RDS only) -· Radio Text (RDS only) -· PS Name (RDS only) -· Category (RDS only) -· Mono/Stereo -HD system shall extract following parameters from a successfully tuned channel and present to -the system, which shall be added in the station database. -· Frequency -· PTY -· No of HD channels available -· Radio Text -· Channel Name -· Category -· Bit rate -· Station Logo -· Artist Experience -The System shall allow the tuned frequency to be incremented or decremented. -The System shall be able to tune to the next/previous valid station as determined by signal -strength. -AM/FM/HD system shall be able to abort Seek Up/Down operations. -Page 127 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -FM/HD system shall be able to set the stop sensitivity for seek over FM band and shall be -possible to adjust by software. -· Range: 15 – 40 dBµV -· Step: 1 dBµV -· Default: 20 dBµV -· -Other parameters like multipath shall be possible to use for determining Stop sensitivity -level. TBD, Supplier to suggest solution. -AM/HD system shall be able to set the stop sensitivity for seek over AM band and shall be -possible to adjust by software. -· Range: 20 – 40 dBµV -· Step: 1 dBµV -· Default: 34 dBµV -· -It shall be possible to have different setting depending on atmospheric conditions (e.g. -different for night and day). -The system shall be able to switch between AM and FM bands. -HD system shall be able to extract the Station Information Service (SIS) Short Name from the -SIS Protocol Data Unit (PDU) on the Primary IBOC Data Service (PIDS) logical channel and -present to the system. The implementation of SIS Short Name feature shall be in compliance -with iBiquity Digital specification "HD Radio™ Air Interface Design Description Station -Information Service Transport". -HD system shall be able to extract the Station Information Service (SIS) Long Name from the -SIS Protocol Data Unit (PDU) on the Primary IBOC Data Service (PIDS) logical channel and -present to the system. The implementation of SIS Long Name feature shall be in compliance -with iBiquity Digital specification "HD Radio™ Air Interface Design Description Station -Information Service Transport". -HD system shall indicate the HD channel number of current tuned channel. It shall be 1 to 8. -Page 128 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -HD system shall extract the following PAD data from audio stream and present to the system. -· Song -· Artist -· Album -· Genre -· Comments -· Commercial -· Reference Identifier -The system implementation shall be in compliance with iBiquity Digital HD radio specification -"HD Radio Air Interface Design Description - Program Service Data Rev. C" -FM/HD system shall be able to receive and extract the RDS/RBDS data and present to the -system. The system implementation shall be in compliance with "BS EN 62106:2009, -Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency -range from 87,5 MHz to 108,0 MHz". -FM/HD system shall be able to enable/disable RDS/RBDS. When RDS/RBDS is enabled/disabled -the system shall indicate this. -FM/HD system shall be able to enable/disable the radio text display. -FM/HD system shall present the Alternative Frequency (AF) setting status to the system. -FM/HD system shall be able to enable/disable alternative frequency switching. -FM/HD system shall be able to notify the system when an Emergency Alert Interrupt is received. -FM/HD system shall be able to skip the Emergency Alert when it is on-air. -FM/HD system shall be able to notify the system when Emergency Alert Interrupt is received -through RDS. -Page 129 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -FM/HD system shall be able to cancel the PTY31 interrupt notification. -FM/HD system shall be able to enable/disable the Traffic Announcement reception. -FM/HD system shall present the status of the FM traffic announcement to the system. -FM/HD system shall be able to skip the FM traffic announcement when it is on-air. -FM/HD system shall be able to enable/disable regionalisation. -FM/HD system shall be able to enable/disable the Traffic Message Channel (TMC) reception. -FM/HD system shall be able to enable/disable the Transport Protocol Expert Group (TPEG) -reception. -FM/HD system shall be able to receive the traffic updates from the Japanese traffic channels. -FM/HD system shall be able to enable/disable the News announcement reception. -FM/HD system shall be able to skip the News when being broadcast. -HD system shall decode PNG images which shall be in compliance with HD Design specification. -HD system shall be able to decode the channel icon PNG images and present to the system. -AM/FM/HD system shall be able to mute the audio output. -AM/FM/HD system shall be able to un-mute the audio output. -*HD system shall extract the album name, artist name, track number from the audio stream a*nd -Page 130 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -present to the system. -The feature will store the data of a tagged song in non-volatile memory within the IMC. The -feature will be able to store at least 50 tags. -*5.2.10.1.1.1 Configuration* -AM/FM/HD system shall be able to configure the frequency band through local configuration -file. -AM/FM/HD system shall be able to configure the step frequency through local configuration file. -AM/FM/HD system shall be able to configure the seek stop level threshold through local -configuration file. -5.2.10.1.2 Database Requirements -AM/FM/HD system shall require a database to store the channel list information which contains -the following attributes: -· Frequency -· PTY (FM & HD only) -· Channel name (FM & HD only) -· Channel icon (HD Only) -· Category (FM & HD only) -AM/FM/HD system shall be able to update the channel list database based on the following -conditions: -· New channel is found -· Existing channel disappears -· -Channel list update shall not create any inconsistency on the current channel list -database. -Page 131 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -AM/FM/HD system shall sort the channel list database based on the channel name, and present -to the system. -AM/FM/HD system shall sort the channel list database based on the ascending order of the -frequency, and present to the system. -FM/HD system shall sort the channel list database based on the PTY (Program Type) category, -and present to the system. -AM/FM/HD system shall create favourite station database which consists of the following -information: -· Station name (FM and HD only) -· Frequency -· Status of HD (HD, HD1, HD2) -· HD SIS (HD only) -AM/FM/HD system shall be able to update the database based on following conditions: -· Favourite station changed -· Favourite station is removed -· New favourite is added -**5.2.11 Vehicle Bus / Vehicle Info Control** -Vehicle Info Control (VIC) provides a capability to access to various vehicle properties from -applications and/or other middleware. Standardized interfaces are provided to vehicle CAN, and -LIN bus. Figure 7-27 describes overall architecture of Vehicle Info Control. The main purpose of -VIC is to provide API to application and/or middleware. Vehicle Info Control has four main -functions. -· Vehicle Data Processing -· Communication between ECUs -· Vehicle Data Upload -Page 132 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· Simulator -**Figure 7-27 : Overview of Vehicle Info Control** -**5.2.11.1 Vehicle Data Processing** -Vehicle data is the information about the vehicle itself, and the information in cars (for example, -personal information on a driver, etc.). VIC deals with all the information which application -and/or middleware need within vehicles. The following data is contained in these. -· -Vehicle information about the vehicles itself, such as speed, a shift position,‑temperature -· User Information, such as a name, taste, etc. of a driver -· The operation history of a driver -Page 133 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· -The operation state of the vehicles which middleware determined based on vehicle -conditions, such as speed and day and night -Vehicles data processing consists of the following functional elements further. -(1) Abstraction of Vehicles Data -In VIC, all vehicles data is treated as abstract data. it concerns and comes out of this to the kind -of car, or the country of the destination. For example, though speed is detected at the revolving -speed of the wheel, in VIC, vehicles data is abstracted and treated at speed and it provides for -application and/or middleware. Thereby, application and/or middleware can treat the vehicles -data of the same implications and the same unit. -(2) Maintenance of Vehicles Data -Each abstracted vehicles data is held. The vehicles data to hold is a current value and the past -value (history). -(3) Application / Middleware Interface (API) -The accessing function of the vehicles data from application and/or middleware is offered as API. -Acquisition of the current value of vehicles data or the past history, a setup of vehicles data, and -the change notice function of vehicles data are included in this. However, each vehicles data -restricts the application and/or middleware which can be accessed according to the importance -(access control). -(4) Vehicles Interface -It is a function for managing the various data of vehicles of in-vehicle networks, such as CAN -and FlexRay, etc. The component in which the exchange with actual vehicles performs the -exchange with vehicles by a vehicle type since it is various is not included in requirements. -However, the correspondence procedure of it and VIC is specified. It assumes that two or more -Vehicle Interface is prepared depending on a communication method with vehicles, etc. In -addition, the vehicles data which can be accessed for every Vehicles Interface is restricted. -**5.2.11.2 Communications between ECUs** -Page 134 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -When a system consists of two or more ECUs, the vehicles data managed by ECU other than -ECU in which application and/or middleware are working shall also be treated. For this reason, -vehicle information processing communicates with it of other ECUs. Thereby, application and/or -middleware can be treated, without caring about by which ECU required vehicles data is -acquired. In addition, the communication function between ECUs also restricts the vehicle data -which each ECU can access. -**5.2.11.3 Vehicle Data Upload** -When a system consists of two or more ECUs, the vehicles data managed by ECU other than -ECU in which application and/or middleware are working shall also be treated. For this reason, -vehicle information processing communicates with it of other ECUs. Thereby, application and/or -middleware can be treated, without caring about by which ECU required vehicles data is -acquired. In addition, the communication function between ECUs also restricts the vehicle data -which each ECU can access. -**5.2.11.4 Simulator** -In the development environment of application and/or middleware, since actual vehicles data is -unacquirable, it is preparing the simulator which imitated actual vehicles, and makes -development environment construction easy. By a simulator, it assumes using the steering wheel -controller for PC games. Since this function is an object for development environment, let it be -an option. -**5.2.11.5 Requirements** -The system must hold vehicle information and must offer the mechanism in which application -and/or middleware can access vehicle information. -The system must provide application and/or middleware with vehicle information as an abstract -property. For example, the speed of vehicles must be not the number of rotations of a wheel but -the speed of a car. -System must provide a mechanism to add or delete vehicle property easily. -Page 135 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -System must support typical vehicle property as “standard property”. -As for a standard property, it is desirable for the same attribute name to be the same meaning. -System must provide a mechanism to add or delete custom vehicle property easily. -A custom property is a property which a system donor can add uniquely in addition to a standard -property. -Let the unit of the value of Vehicle Info Data be an international unit(meter, gram, …etc) -The value of Vehicle Info Data should have sufficient accuracy which application and/or -middleware need. For example, when a unit is made into Km/h, an integral value is not enough -as the accuracy of Velocity. It is necessary to change Km/h into MPH in the country of a mile -display. Moreover, it is because the error of the speed display is defined by law. -A vehicle information control facility requires the mechanism in which vehicle information is -stored. A lot of events generate some information at high speed. About such information, the -load to a system has few directions processed collectively. Moreover, when data is taken and -spilt by an application, the structure which can carry out recovery is required. -It is not realistic to accumulate all the information that changes at high speed. For this reason, In -corresponding to neither of the following, it shall not store the change data. -· -The amount of change of a value. It is not accumulated when the difference from the -accumulated newest value is less than a threshold value. -· -Lapsed time from the last change It does not accumulate, if time has not passed since the -newest accumulation. -About each vehicle information, the threshold value and cumulative dosage of accumulation need -to be able to set up easily. -In addition, it also makes it possible not to accumulate specific vehicle information. -System must provide an interface to application and/or middleware regarding vehicle property -access. -System must provide an interface to retrieve vehicle property from application and/or -middleware. -Page 136 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Below attributes must include in this interface -· Zone(optional) -· Property name -· Value -· -Timestamp - Timestamp specifies last updated time of corresponded vehicle property. -System must provide an interface to set abstracted value to vehicle property from application -and/or middleware. -Below attributes must include in this interface. -· Zone(optional) -· Property name -· Value -System must provide an interface to subscribe status change of vehicle property from -application and/or middleware. -When status changed, system must invoke callback function with below attributes. -· Zone(optional) -· Property name -· Value -· Timestamp -· Sequence number -Timestamp specifies last updated time of corresponded vehicle property. -Sequence number is useful to check event order. -The acceptable value of change can be specified for vehicle information about the notice of -change of vehicle information. -In order to lower system-wide load, it will not notify, if it is change which is less than an -acceptable value even if vehicle information changes. -For example, although engine number of rotations changes every moment, in the case of the -application which displays it in 20 steps, it is not necessary to know less than several percent of -change. -Page 137 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -It shall not notify the change, in corresponding to neither of the following. -· -The amount of change of a value - It does not notify, if the amount of change of the -value from the last notice of change is less than specification. -· -Lapsed time from the last change - From the last notice of change, if it is less than a -definite period of time, it does not notify. -Depending on application, the notice with a fixed cycle is more convenient than the notice at the -time of change. -What is notified only the specified cycle even if it changes two or more times into the specified -notice interval is made possible. -The data stored is acquired collectively. -Below attributes must include in this interface. -· Zone(optional) -· Property name -· Values -· Timestamps -It is desirable that the time range to acquire can be specified. For example, data from 10 -seconds before to the present, data from 13:20 to 14:00, etc. -There is an attribute for which change/reference is simultaneously needed in relation to mutual -in vehicle information. For example, latitude, longitude, and an altitude are changed -simultaneously. If these pieces of vehicle information is changed and referred to individually, the -newest longitude may acquire the value in front of one, and a current position may be unable to -recognize latitude correctly. For this reason, it is necessary to summarize the vehicle information -relevant to mutual and to access it. -Access of ones of those vehicle information is deterred until renewal of all the vehicle -information included in Property Set at the time of a setup of vehicle information is completed, -and renewal of ones of those vehicle information is deterred until it completes acquisition of all -those vehicle information at the time of reference. -The definition of the vehicle information included in Property Set is being able to change easily. -Or the thing which can be changed from a program during operation. -Page 138 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -System must provide a mechanism of access control per each property. For example, property -"velocity" can be accessed from only application A and B, but property "turn signal" can be -accessed from all applications. -System must also provide a mechanism of access control per each method even if same -property. For example, about "seat setting", all applications can get this property, but only -application C can set this property. -Permission for each property and method must be configurable easily. Because, access control -policy may be different per car type, grade and destination. -System must provide a mechanism to enable routing any vehicle property both within same ECU -and across two or more ECU’s. -If a Property Change event is received from VIC, change can be notified to all the applications, -middleware and other VICs which are subscribing change of the vehicle information. In addition, -the notice of change must be able to be distributed also to the application and/or middleware -which exist in a different ECU. -VIC can be requested to set the value specified as Property. -It can set, even if it exists on ECU from which an application and VIC differ. -The newest value can be returned immediately, without asking VIC to the acquisition demand -from an application. For this reason, keep the newest value of each Property. -Even if it is in ECU from which VIC of the Property differs, the demand from an application -responds. -It can exchange with two or more VICs. Addition and deletion of Data Provider can be performed -easily. -The data exchange between ECUs should be permitted by VIC. -All data transmission and reception from other Software Component are refusing. -Page 139 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -The system should have a mechanism which communicates the stored vehicles. -The vehicle information to upload is being able to choose. -A selection condition is that the following specification is possible at least. -· Date-and-time range -· Object vehicles data -· The change threshold value of vehicles data -Enable change of selection of vehicle information easily. As for this, it is desirable for it to be -able to change dynamically from an external. -The simulator of vehicles data using the steering wheel controller for PC games, etc. as -substitution of actual vehicles in development environment is prepared. -Car Simulator is being able to notify the following vehicles data to vehicles data processing -activities through a vehicles interface function at least. -· Speed -· Shift position -· The direction of vehicles -· Latitude and longitude of a current position -· Turn signal -The steering wheel controller for PC games to be used is being able to obtain easily. Moreover, -it is desirable that two or more steering wheel controllers can be used. -VIC should fill the following performance specifications and performance. -It is a value on condition of H/W assumed that the following values will be used for in-vehicle -information machines and equipment in 2016. -Page 140 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· Maximum number of properties : 4,096 -· Maximum number of property sets: 1,024 -· Greatest data storage time : 12 hours -It is a value on condition of H/W assumed that the following values will be used for in-vehicle -information machines and equipment in 2016. -· Get/Set method(one property) - 0.2ms -· Get/Set method(property set include 30 properties) -1.3ms -· Subscribe callback - 2.5ms (after change of a value) -· -GetHistory method(for within 3 minutes after the present) - 0.2ms -· -GetHistory method (older than 3 minutes from the present) - 50ms -VIC is being able to change without having composition which has pliability and extendibility -about the vehicles data to manage, and reconstructing the whole VIC about the kind and -attribute of vehicles data. -Vehicle Interface treats various kinds of in-vehicle LAN and sensors, and they are mounted by -various H/W according to a maker or a vehicle type. For this reason, VIC needs to be able to add -and change Vehicle Interface without reconstruction of VIC. -Abstraction of vehicles data is the duty of Vehicle Interface in principle. This is because it is -necessary to change the concreteness data depending on H/W of in-vehicle LAN or sensors. -However, an abstract vehicles data value may be decided by combination of the concreteness -vehicles data from two or more Vehicle Interface. In this case, VIC needs to change two or more -concreteness vehicles data into one abstract vehicles data. -Since this conversion is dependent on H/W of in-vehicle LAN or sensors, so it cannot be -mounted in the VIC itself. -In order to solve this, suppose that the mechanism in which such a conversion module can be -added without reconstruction of VIC is prepared for VIC. -**5.2.12 Telematics Services** -V2V, V2I, RVI, Traffic information, etc. -Page 141 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -**5.2.13 Window System** -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. -AGL specifies that automotive grade Linux shall support multiple windows on a display. -AGL specifies that automotive grade Linux shall support multiple windows owned by multiple -processes to be rendered on a display. -AGL specifies that automotive grade Linux shall support rendering to off-screen buffer to -achieve flicker less rendering. -AGL specifies that automotive grade Linux shall support composition of windows with off- -screen buffers. -AGL specifies that automotive grade Linux shall support a translucent window, i.e. underlying -objects underneath the translucent window is visible depending on the alpha values of pixels. -AGL specifies that automotive grade Linux shall make OpenGL/ES 2.0 API compliant to Khronos -group available to clients for their rendering. -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 support window manager that is replaceable by -configuration. -AGL specifies that automotive grade Linux shall provide a window system that abstracts the -*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e a -Page 142 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -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. -AGL specifies that automotive grade Linux shall support multi-headed display where available. -AGL specifies that automotive grade Linux shall support mirroring of windows to multiple -displays. -AGL specifies that automotive grade Linux shall support hardware layers, such as DRM planes, -where available. -AGL specifies that automotive grade Linux shall compose windows using available hardware -acceleration capabilities. -AGL specifies that automotive grade Linux shall support management of windows and inputs -from users depending on statuses of a vehicle. The statuses of vehicle include a speed of a -vehicle, a motion of a vehicle, etc. For instance, the inputs may needs to be limited while the -vehicle reaches to the certain speed. -AGL specifies that automotive grade Linux shall abstract physical input devices such as buttons, -a touch panel, a control knob etc. -AGL specifies that automotive grade Linux shall support On-screen keyboard which takes input -from available physical input devices. -**6 Security Services** -Security framework -6.1 Access Control -Access Control describes requirements for AGL Access Control. -Page 143 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Access control is a mechanism to grant / deny access to APIs/files in the system. -**6.1.1 Requirements** -AGL system must support a system-wide access control mechanism. -**7 Operating System Layer** -7.1 Kernel -**7.1.1 Linux Kernel** -Automotive Grade Linux uses the Linux Kernel. The kernel is constantly evolving with a new -release about every sixty days. The automotive industry has design cycles of three to five years -for IVI systems. Somehow a balance must be struck between updating operating system and -kernel every few months and keeping up to date with modern features that the kernel and the -rest of the open source community provides, -**7.1.1.1 Requirements** -AGL kernel shall be based on Long Term Support Initiative (LTSI) kernel. -At the moment LTSI kernel is the only open source/public kernel that gets closer to automotive -industry needs – it has certain automotive industry demanded components integrated, it is fully -aligned with Linux LTS trees so it leverages security fixes and/or generic bugfixes adapted by -Linux community, LTSI kernel merge window is more flexible to industry demands and allow to -accumulate wider set of features, components and bugfixes relevant for industry (comparing to -regular Linux kernel merge/release cycle). LTSI kernel is thoroughly validated manually and with -the help of automated tools to track and discover anomalies and regressions. -AGL development process should utilize bug tracker with ability to mark bugs as open/fixed on -particular distribution branches. Open bugs should have direct impact on release decisions. -Page 144 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -7.2 Boot Loader -7.3 Hypervisor -TBD. Need to add very basic “background” regarding virtualization, explain about OS-level -virtualization/isolation, then about type1/type2 hypervisors (virtualization). In modern IVI -systems OS-level virtualization is widely used (applications isolation, combination of Android -and Linux apps together), future – maybe Linux/IVI + ADAS + Instrument Cluster = guests on -top type1 hypervisor. -**7.3.1 Requirements** -AGL shall provide OS-level mechanisms for running multiple isolated instances (containers) that -have its own directory structure, network devices, IP addresses and process table. The -processes running in other containers shall not be visible from inside a container. -AGL Linux should be configurable to work as Type-1 “bare-metal” hypervisor “guest”. Following -functionality shall be supported by AGL Linux “guest”: -· IPC (with hypervisor and other “guests”) -· -“paravirtualized” device drivers for peripherals shared with other “guests” (unless -virtualization abstraction is supported by hardware) -7.4 Operating System -**7.4.1 File Systems** -File system (FS) requirements for AGL concentrate on Reliability, Accessibility, and Serviceability -as their main characteristics. -· -*Reliability*means data integrity protection, automatic error detection and correction, -tolerance to power failures, robustness under stress I/O load in multi-process -environment, extended lifetime via use of wear leveling and bad block management -techniques. -Page 145 of 159 - - ------------------------------------------------------------------------------- - > **FS Requirements** > **R-FS References** - ------------------------------------------------------ ------------------------ - > 6. File Systems (P1) > 2. btrfs - > > - > 6.1. Robust File System for managed internal > 2.1. - > > - > storage (P1) > btr - > > - > 6.1.1. Power failure tolerance (P1) > fsc - > > - > 6.1.2. Quick recovery after power loss > k - > > - > (P1) > 3. ext2 - > > - > 6.1.3. Multi-threaded I/O (P1) > 3.1. - > > - > 6.1.4. On-demand integrity checker (P1) > e2 - > > - > 6.1.5. Read-only mode (P1) > def - > > - > 6.1.6. Non-blocking unmounting (P1) > rag - > > - > 6.1.7. Means for optimizing I/O > 4. ext3 - > > - > performance if it may degrade under > 5. ext4 - > > - > certain conditions. (P2) > 5.1. - > > - > 6.1.8. File space pre-allocation (P2) > e4 - > > - > 6.1.9. Meta-data error detection (P2) > def - > > - > 6.1.10. File data error detection (P2) > rag - > > - > 6.1.11. Online integrity checking (P2) > 5.2. - > > - > 6.1.12. Write timeout control (P2) > e2f - > > - > 6.1.13. Compression support (P2) > sck - > > - > 6.1.14. Quota support (P2) > 6. vfat - > > - > 6.1.15. I/O process priority (P2) > 7. UBIFS - > > - > 6.1.16. File system event notifications > 8. Generic - > - > tools and - > - > APIs - > - > 8.1. - > - > fan - ------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -· -*Accessibility*means ability to use external storage devices, as well as accessing -designated parts of internal file system over secure wired or wireless connections. -· -*Serviceability*means ability to upgrade AGL as a whole or by updating individual -packages, and availability of file system checking and optimization tools. -Automotive Grade Linux Requirements Spec v1.0 -(P2) -6.1.17. Logical block size control (P2) -6.1.18. Snapshots (P2) -6.2. File System for non-managed internal -storage (P1) - -May 28, 2015 - -otif - -y - -8.2. - -fst - -rim - -6.2.1. All P1 requirements from -FS.1.1.x list (P1) -6.2.2. Wear leveling (P1) -6.2.3. Error detection/correction (P1) -6.2.4. Tolerance to flipping bits (P1) -6.2.5. Read/write disturb awareness -(P1) -6.2.6. Bad block management (P1) -6.2.7. As many P2 requirements from -FS.1.1.x list as possible (P2) -6.2.8. Wear leveling statistics (P2) -6.3. File Systems for removable storage (P1) -6.3.1. Restricted functionality from -security point of view (P1) -6.3.2. Automount/autounmount (P1) -6.3.3. Automatic synchronous flushing -of modified data to physical media (P2) -**7.4.1.1 Requirements** -AGL shall provide a set of file systems to support the following types of storage devices: -internal managed (SSD, eMMC, etc.), internal non-managed (raw NOR and NAND FLASH -memory), removable managed (USB stick, SD card). -AGL shall provide robust file system suitable for use on managed internal storage devices, -Page 147 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -AGL shall provide robust file system suitable for use on non-managed internal storage devices, -AGL shall provide a set of file systems popular on removable media devices. -A system must be able to withstand power failures under heavy load of meta-data-intensive, -and data-intensive operations, including power-failures during OS startup, and shutdown. -A file system must be able to restore good data and meta-data state after unexpected power -interruption without performing the full time-consuming integrity check. Such recovery should -not add more than a second to the normal boot process after power failure on idle system. -Normally this is achieved via journal- or log-based (also known as transactional or copy-on- -write) operation. -A file system must be able to handle meta-data-intensive, and data-intensive I/O from multiple -threads and/or processes simultaneously. -A file system must have integrity checking tool with ability to execute it on-demand. -A file system must be able to switch between read-only, (when no data is committed to physical -storage device), and read/write modes in runtime. E.g. via “mount –o remount,ro <device>” -command. -AGL must support “lazy” (delayed) unmounting. -AGL should provide means for optimizing potentially degraded I/O performance after prolonged -file system and storage use. Often, this refers to offline or online file system defragmentation. -Another example is periodic fstrim execution on SSD storage. -A file system should be able to pre-allocate space for created/extended files on request. This -may be used to minimize fragmentation of frequently written files. -A file system should have an option of automatic error detection in its meta-data. -Page 148 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -A file system should be able to associate error detection codes with separate blocks of stored -data, and to verify the data against the codes in runtime upon each read from a physical device. -A file system should have a utility for meta-data integrity checking on mounted partition. -A file system should allow changing timeout after which it flushes modified data to physical -media. -A file system should support automatic data compression. -It should be possible to enable file system quotas for particular users and/or groups. -AGL should allow to set I/O scheduling class and priority for particular processes. -AGL should allow user space applications to subscribe for file and directory change notifications. -Making logical block size equal to a power of physical block size may improve physical I/O -performance, and decrease file fragmentation impact. -A file system should allow creation of snapshots. -A file system must perform wear leveling before writing data, so that the limited number of -erase/program cycles is evenly distributed across all device blocks. -A file system must support the following error detection/correction algorithm(s): BCH4, BCH8. -A file system should not just be able to detect/correct a number of flipped bits but should also -actively prevent the issue from happening in the first place, especially after unexpected power -interruption. Known techniques include forced reprogramming of blocks that were in use at the -time of power failure, and copying data to a fresh block after detected error correction. -A file system should not just be able to detect/correct errors caused by read/write disturb -Page 149 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -phenomenon but should also actively prevent the issue from happening in the first place. Known -techniques include limiting the number of read cycles between erases, and copying data to a -fresh block after detected error correction. -A file system must perform bad block detection and management transparently to file system -users. -Current FLASH wear-related statistics should be accessible via user-space utility. -A file system must support noexec, and nodev mount options. -A file system must be able to automatically mount plugged-in removable media, and -automatically unmount it when unplugged. -A file system must support sync mount option. -AGL shall provide a set of file systems to support the following types of storage devices: -internal managed (SSD, eMMC, etc.), internal non-managed (raw NOR and NAND FLASH -memory), removable managed (USB stick, SD card). -**7.4.2 Resource Control** -In IVI system, it depends time and occasion that which application and/or middleware should be -higher priority. Resource control provides basic functionality regarding proper resource -allocation for each process and/or process group. -(cgroups) -**7.4.2.1 Use Case and Role** -If end user specified a destination and started route guidance, map drawing following current -position and voice and/or visual guidance should be treated as higher priority than others. -On the other hand, if end user is watching a movie, movie player and decoder should be assigned -Page 150 of 159 - - ------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- -------------- ---------------------------------------------------------------- - > 1 > Priority > Allocate resource via its own priority. High priority - > - > process and/or process group should be assigned - > - > more resource. - - > 2 > Time slot > To share resource per time slot. - - > 3 > Release > Forced release of partially or whole allocated - > - > resource. - - > 4 > Grouping > Grouping two or more processes, and allocate - > - > resource per defined process group. - ------------------------------------------------------------------------------------------- - -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -to higher priority than others. -Important point is that it may assign two or more high priority application and/or middleware at -the same time. And, one function may be provided from two or more processes. -Table 9-33 describes the role of resource control to be satisfied above purpose and use cases. -AGL assumes four types of resources, CPU, memory, storage bandwidth and network -bandwidth. Table 9-34 describes associated roles per each resource type. -**Table 9-34 : Functions of System Resource Management** -**7.4.2.2 Requirements** -7.4.2.2.1 Priority -System provides a mechanism to set resource priority per each process. -Page 151 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -System provides an interface to set and refer resource priority of specific process. -This interface must be called from other process. -CPU resource must support “priority” based resource management. -Resource Manager should dynamically change the ratio of offering resources according to the -status of resources using by system. And its configuration must be changed easily. -Resource Manager should log the status of resources using by system. -Resource Manager should offer resources separately to threads of user land and threads of -kernel. And Resource Manager should treat the bottom half and software interrupts as high -priority tasks. -7.4.2.2.2 Time Slot -When two or more process request to same resource at the same time, system must provide a -mechanism to mediate to guarantee the time slot to obtain specific timeframe for each -processes. -System must provide an interface to set specific timeframe to obtain time slot per each process. -System must provide a mechanism of resource sharing by time slot regarding CPU, storage -bandwidth and network bandwidth. -Scheduler should detect the status of resources for each thread. -Scheduler must not run the specific thread for more than 10 micro second. -Scheduler should guarantee that threads can run periodically. -Scheduler should control the dispatches that occur extremely. -Page 152 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -7.4.2.2.3 Release -System must provide an interface to release all or partial resource which had obtained by -specific process. -System must provide a mechanism of resource releasing regarding memory resource. -7.4.2.2.4 Grouping -System must provide a mechanism to group two or more processes regarding resource -management such as priority, time slot and releasing. System must able to assign same -attributes to grouped processes altogether. -System must provide an interface to group two or more processes from other process. -System must provide a mechanism to group regarding CPU, memory, storage bandwidth and -network bandwidth. -**7.4.3 Startup/Shutdown Control** -Boot/Shutdown Control is a mechanism to control boot and shutdown of a program running in a -user space. The order of boot/shutdown in the target program can be easily swapped depending -on the product configuration. Boot/Shutdown Control supports both “static order” which -boots/shuts down the program according to the static dependency of each program, and -“dynamic order” which swaps the order dynamically in specific conditions. -**7.4.3.1 Use Cases** -(1) Static Modification of Boot/Shutdown Order -a. -Setting up of Boot/Shutdown Order Based on Product Configuration -To support various product configurations, the integrator configures/modifies orders of boot/shutdown -for all programs running on the target device. -Page 153 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -b. -Configuring the Order of Boot/Shutdown during a Program Development -In order to evaluate a developed program, the developer modifies only the order of the developed -program in target programs. -c\. Configuring the Order of Boot/Shutdown when Software Update -Maintainer modifies the order of boot/shut down for a program to be updated when software update. -(2) Dynamic Modification of Boot/Shutdown Order -a. -Prioritized Boot of the Features which the User was Previously Using -It dynamically modifies the boot order of the target program in order for last used features (e.g. audio) to -be operated by priority when ACC turns ON. -b\. Prioritized Boot of Update Functionalities -Update related programs are booted by priority when connected with maintenance kit and ACC turned -ON. -**7.4.3.2 Requirements** -Boot/Shutdown Control shall start components, which are configured to be started. -Boot/Shutdown Control shall ensure that dependent components are started in the order that -has been configured. -Boot/Shutdown Control shall start independent components in parallel. -Boot/Shutdown Control shall stop components, which are requested to be stopped. -Boot/Shutdown Control shall ensure that dependent components are stopped in the order that -has been configured. -Page 154 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Boot/Shutdown Control shall be configurable by run level to start corresponding modules. -**7.4.4 Database** -Due to the nature of AGL operating environment, it is very important for DB engine to guarantee -database instance integrity after power failures. Other important feature for generic system -database engine is rich set of bindings to various programming languages. -Below is short summary for better understanding of DBS Requirements and References -hierarchy. -1. Power failure tolerance (P1) -2. Quick recovery after power loss (P1) -3. Multi-threaded I/O (P1) -4. API bindings for C programming language -5. On-demand integrity checker (P2) -DB instance integrity must be ensured after power failures under heavy load of read and write -DB transactions. -DB engine must be able to quickly restore good data state after unexpected power interruption. -Such recovery should not add more than a second to the normal boot process after power -failure on idle system. -DB engine must allow read and write access to DB instance from multiple threads and/or -processes simultaneously. -DB engine API must be available for C-based applications. -DB engine should have DB instance integrity checking tool with ability to execute it on-demand. -DB engine must be able to quickly restore to a previously defined state after unexpected power -interruption during adding some data. -Page 155 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -DB engine should have availability to merge some data from internal and external databases, -such as vehicle information database and databases at data center. -And DB engine should have accessibility to allow read access to DB instance during merging. -Also, DB engine should have durability not to break its data after unexpected power interruption -during merging. -**7.4.5 System Update** -Maintenance of in-vehicle devices is also an important role for any automotive system. There are -numerous use cases for updating the device software such as software failure,security patching, -bug fixes, and new features. Because automotive devices are battery operated and subject to -power cuts any System Updates must be robust enough to withstand sudden power loss. -System Update module should have a Robust version up function. -System Update moduleshould have a system difference version up function. -There should be a data update structure for each file or package (same as WindowsUpdate or -apt of Linux distribution). -There should be a data update structure for each file or package (same as WindowsUpdate or -apt of Linux distribution). -Difference update should be enabled for kernel, middle ware and application. -If power discontinuity (forced restart) occurs during update for differences, the system should -be recovered after choosing the status (before or after update) for each update target. -If power discontinuity (forced restart) occurs during update for differences, the status (during -update) should be detected and the system should restart. -Time required for applying patch should be 5 minutes maximum for single 10MByte data. -Page 156 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -Memory usage for difference update should be maximum 1Mbyte. -Unit amount for difference data should be 10MByte maximum for difference update. -System Update moduleshould have full version up function for whole system. -Kernel, middle ware and application should be mass updated. System structure should allow -mass update. -There should be mass update structure for kernel, middle ware and application. -If power discontinuity (forced restart) occurs while mass update of kernel, middle ware and -application, the status (during update) should be detected and the system should restart. -If power discontinuity (forced restart) occurs while mass update of kernel, middle ware and -application, the status (during update) should be detected and the system should restart. -7.5 Device Drivers -Device drivers may be in kernel space or user space or a combination of both. -**7.5.1 Peripherals** -Typical IO device drivers such as SPI, USB, memory, I2C that are typically present on a SOC. -The flash process must be robust with an endurance of more than 10k write/erase cycles and -data retention over 15-years/10 ppm, assuming application specific worst-case conditions. For -optimised timing for downloading and restoring data the programming access time shall be less -than 50 s/byte average. -The EEPROM process must be robust with an endurance of more than 100k write/erase cycles -and data retention over 15 years/10ppm. Higher programming voltage than 5 V for Flash or -EEPROM is not allowed. -Page 157 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -In applications that need to save data at power down, the programming access time must be -fast. (target <1ms/byte) -N.B. EEPROM functionality can be emulated in flash memory passing the requirements above. -**7.5.2 Graphics Drivers** -Graphics drivers provide the interface to the graphical resources (e.g., GPU) within the system. -This may include on-board graphical resources or a separate GPU from the main SOC. -**7.5.3 Video Drivers** -Video codecs allow the system to decode and/or encode video for playback or recording. Video -codecs will nearly always be hardware based. -**7.5.3.1 Requirements** -The system shall provide device drivers to access any hardware implementation of video -functionality. -**7.5.4 Audio Codecs** -**7.5.4.1 Requirements** -Automotive Grade Linux BSPs shall provide devices drivers to access audio codecs that are -implemented in hardware. -Automotive Grade Linux BSPs should provide software implementations for those audio codecs -that are required for AGL-based products and not supported in hardware. -**7.5.5 Automotive Devices** -Device drivers for automotive related devices. This may includes buses such as CAN, MOST, or -*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* -Page 158 of 159 -Automotive Grade Linux Requirements Spec v1.0 -May 28, 2015 -required to directly interface to sensors that may not be on the bus such as gyros used for -navigation or an air bag sensor for a telematics system. -**8 Notices** -Linux is a registered trademark of Linus Torvalds. -The Linux Foundation and Yocto Project are registered trademarks of The Linux Foundation. -Bluetooth is a registered trademark of the Bluetooth SIG Inc. -Miracast is a registered trademark of the Wi-Fi Alliance. -MirrorLink is a certification mark of the Car Connectivity Consortium. -AirPlay is a trademark of Apple, Inc. -Page 159 of 159 |