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