diff options
Diffstat (limited to 'agl-specs-v1.0/00-doorsNG-original.md')
| -rw-r--r-- | agl-specs-v1.0/00-doorsNG-original.md | 7753 |
1 files changed, 0 insertions, 7753 deletions
diff --git a/agl-specs-v1.0/00-doorsNG-original.md b/agl-specs-v1.0/00-doorsNG-original.md deleted file mode 100644 index d41635d..0000000 --- a/agl-specs-v1.0/00-doorsNG-original.md +++ /dev/null @@ -1,7753 +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 -> -> May 28, 2015 -> -> Table of Contents -> -> [***1***](#5)*** Automotive Grade Linux ...............................................................................................*** -> ***5*** -> -> [**1.1**](#5)** Overview ............................................................................................................................** -> **5** -> -> [**1.2**](#6)** Document Scope.................................................................................................................** -> **6** -> -> [**1.3**](#6)** Glossary of Terms ..............................................................................................................** -> **6** -> -> [***2***](#7)*** Architecture ..................................................................................................................*** -> ***7*** -> -> [***3***](#8)*** App/HMI Layer .............................................................................................................*** -> ***8*** -> -> [**3.1**](#9)** Home Screen ......................................................................................................................** -> **9** -> -> [3.1.1](#9) Layout......................................................................................................................................... -> 9 -> -> [3.1.2](#10) System UI Parts........................................................................................................................ -> 10 -> -> [3.1.3](#10) Application Management .......................................................................................................... -> 10 -> -> [3.1.4](#10) Application Switch.................................................................................................................... -> 10 -> -> [3.1.5](#10) Application History ................................................................................................................... -> 10 -> -> [3.1.6](#12) Application Stack ...................................................................................................................... -> 12 -> -> [3.1.7](#14) Role of Home Screen................................................................................................................ -> 14 -> -> [3.1.8](#16) Requirements ........................................................................................................................... -> 16 -> -> [***4***](#20)*** Application Framework Layer .....................................................................................*** -> ***20*** -> -> [**4.1**](#20)** AGL Application Framework .............................................................................................** -> **20** -> -> [4.1.1](#21) Application Manager................................................................................................................. -> 21 -> -> [4.1.2](#21) Window Manager ..................................................................................................................... -> 21 -> -> [4.1.3](#27) Policy Manager ......................................................................................................................... -> 27 -> -> [4.1.4](#59) Sound Manager ........................................................................................................................ -> 59 -> -> [4.1.5](#63) Input Manager .......................................................................................................................... -> 63 -> -> [4.1.6](#65) User Manager ........................................................................................................................... -> 65 -> -> [**4.2**](#71)** Web HMI ..........................................................................................................................** -> **71** -> -> [4.2.1](#71) Web API ................................................................................................................................... -> 71 -> -> [4.2.2](#75) Web Runtime............................................................................................................................ -> 75 -> -> [**4.3**](#76)** Native HMI .......................................................................................................................** -> **76** -> -> [4.3.1](#76) Native App Runtime.................................................................................................................. -> 76 -> -> [4.3.2](#77) Native Application Framework ................................................................................................. -> 77 -> -> [***5***](#77)*** Services Layer ............................................................................................................*** -> ***77*** -> -> [**5.1**](#78)** Platform Services .............................................................................................................** -> **78** -> -> [5.1.1](#78) Bluetooth ................................................................................................................................. -> 78 -> -> [5.1.2](#92) Error Management.................................................................................................................... -> 92 -> -> [5.1.3](#98) Graphics ................................................................................................................................... -> 98 -> -> [5.1.4](#98) Location Services...................................................................................................................... -> 98 -> -> Page 2 of 159 -> -> Automotive Grade Linux Requirements Spec v1.0 -> -> May 28, 2015 -> -> [5.1.5](#100) Health Monitoring .................................................................................................................. -> 100 -> -> [5.1.6](#100) IPC ......................................................................................................................................... -> 100 -> -> [5.1.7](#100) Lifecycle Management............................................................................................................ -> 100 -> -> [5.1.8](#100) Network Services................................................................................................................... -> 100 -> -> [5.1.9](#100) Persistent Storage ................................................................................................................. -> 100 -> -> [5.1.10](#100) Power Management ............................................................................................................. -> 100 -> -> [5.1.11](#102) Resource Management......................................................................................................... -> 102 -> -> [5.1.12](#102) Telephony Services .............................................................................................................. -> 102 -> -> [5.1.13](#103) Wi-Fi .................................................................................................................................... -> 103 -> -> [5.1.14](#110) Window System................................................................................................................... -> 110 -> -> [**5.2**](#111)** Automotive Services ......................................................................................................** -> **111** -> -> [5.2.1](#111) Audio Services........................................................................................................................ -> 111 -> -> [5.2.2](#111) Camera Services..................................................................................................................... -> 111 -> -> [5.2.3](#111) Configuration Services ........................................................................................................... -> 111 -> -> [5.2.4](#111) Diagnostic Services ................................................................................................................ -> 111 -> -> [5.2.5](#111) Multimedia Services ............................................................................................................... -> 111 -> -> [5.2.6](#116) Navigation Services................................................................................................................ -> 116 -> -> [5.2.7](#117) PIM......................................................................................................................................... -> 117 -> -> [5.2.8](#117) Smartphone Link .................................................................................................................... -> 117 -> -> [5.2.9](#125) Speech Services ..................................................................................................................... -> 125 -> -> [5.2.10](#125) Tuner Services ..................................................................................................................... -> 125 -> -> [5.2.11](#132) Vehicle Bus / Vehicle Info Control........................................................................................ -> 132 -> -> [5.2.12](#141) Telematics Services.............................................................................................................. -> 141 -> -> [5.2.13](#142) Window System................................................................................................................... -> 142 -> -> [***6***](#143)*** Security Services......................................................................................................*** -> ***143*** -> -> [**6.1**](#143)** Access Control ...............................................................................................................** -> **143** -> -> [6.1.1](#144) Requirements ......................................................................................................................... -> 144 -> -> [***7***](#144)*** Operating System Layer ..........................................................................................*** -> ***144*** -> -> [**7.1**](#144)** Kernel ............................................................................................................................** -> **144** -> -> [7.1.1](#144) Linux Kernel ........................................................................................................................... -> 144 -> -> [**7.2**](#145)** Boot Loader ...................................................................................................................** -> **145** -> -> [**7.3**](#145)** Hypervisor .....................................................................................................................** -> **145** -> -> [7.3.1](#145) Requirements ......................................................................................................................... -> 145 -> -> [**7.4**](#145)** Operating System ..........................................................................................................** -> **145** -> -> [7.4.1](#145) File Systems ........................................................................................................................... -> 145 -> -> [7.4.2](#150) Resource Control ................................................................................................................... -> 150 -> -> [7.4.3](#153) Startup/Shutdown Control .................................................................................................... -> 153 -> -> [7.4.4](#155) Database ................................................................................................................................ -> 155 -> -> [7.4.5](#156) System Update....................................................................................................................... -> 156 -> -> [**7.5**](#157)** Device Drivers ................................................................................................................** -> **157** -> -> Page 3 of 159 -> -> Automotive Grade Linux Requirements Spec v1.0 -> -> May 28, 2015 -> -> [7.5.1](#157) Peripherals ............................................................................................................................. -> 157 -> -> [7.5.2](#158) Graphics Drivers..................................................................................................................... -> 158 -> -> [7.5.3](#158) Video Drivers.......................................................................................................................... -> 158 -> -> [7.5.4](#158) Audio Codecs ......................................................................................................................... -> 158 -> -> [7.5.5](#158) Automotive Devices ............................................................................................................... -> 158 -> -> [***8***](#159)*** Notices.....................................................................................................................*** -> ***159*** -> -> Page 4 of 159 -> -> 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 |