From 0eba225fb27ec0b87bfa80361314fec5ab901caa Mon Sep 17 00:00:00 2001 From: Stephane Desneux Date: Tue, 16 Oct 2018 13:10:46 +0200 Subject: Import from docs-agl/docs Change-Id: Id524561d87410e5463cddd123b30eb63d75b62bd Signed-off-by: Stephane Desneux --- agl-specs-v1.0/00-doorsNG-original.md | 7753 --------------------------------- 1 file changed, 7753 deletions(-) delete mode 100644 agl-specs-v1.0/00-doorsNG-original.md (limited to 'agl-specs-v1.0/00-doorsNG-original.md') diff --git a/agl-specs-v1.0/00-doorsNG-original.md b/agl-specs-v1.0/00-doorsNG-original.md deleted file mode 100644 index d41635d..0000000 --- a/agl-specs-v1.0/00-doorsNG-original.md +++ /dev/null @@ -1,7753 +0,0 @@ ---- -# Master Header for Jkyll ---- - -> ![](media/picture8.jpeg)![](media/picture9.jpeg)Version   1.0 -> -> Automotive Grade Linux -> -> Requirements Specification -> -> May   28,   2015 -> -> www.automotivelinux.org -> -> www.linuxfoundation.org -> -> ![](media/picture10.jpeg)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 -> -> ![](media/picture46.jpeg)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 -> -> ![](media/picture87.jpeg)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 -> -> ![](media/picture94.jpeg)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 - -> ![](media/picture95.jpeg)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 - -> ![](media/picture96.jpeg)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 -> -> ![](media/picture97.jpeg)![](media/picture98.jpeg)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 -> -> ![](media/picture99.jpeg)![](media/picture100.jpeg)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 -> -> ![](media/picture101.jpeg)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 -> -> ![](media/picture102.jpeg)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 -> -> ![](media/picture103.jpeg)![](media/picture104.jpeg)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 -> -> ![](media/picture105.jpeg)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. - -------------------------------------------------------------------------------------- - -> ![](media/picture106.jpeg)![](media/picture107.jpeg)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. - ---------------------------------------------------------------------------------------------------- - -> ![](media/picture108.jpeg)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 > ‑ > ‑ - ----------------------------------------------------------------------------------------------- - -> ![](media/picture109.jpeg)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 -> -> ![](media/picture110.jpeg)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 -> -> ![](media/picture111.jpeg)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 -> -> ![](media/picture112.jpeg)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 -> -> ![](media/picture113.jpeg)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 -> -> ![](media/picture114.jpeg)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. - -------------------------------------------------------------------------------------------------------- - -> ![](media/picture115.jpeg)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. - ---------------------------------------------------------------------------------------------- - -> ![](media/picture116.jpeg)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 -> -> ![](media/picture117.jpeg)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 -> -> ![](media/picture118.jpeg)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 -> -> ![](media/picture119.jpeg)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 -> -> ![](media/picture120.jpeg)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 -> -> ![](media/picture121.jpeg)![](media/picture122.jpeg)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 -> -> ![](media/picture123.jpeg)![](media/picture124.jpeg)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 - ----------------------------------------------------------------------------------------------------------------------------------------------------- - -> ![](media/picture125.jpeg)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. - ----------------------------------------------------------------------------------------------------- - -> ![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Policy  Manager  has  the  below  role. -> -> Page  31  of  159 -> -> ![](media/picture128.jpeg)![](media/picture129.jpeg)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 -> -> ![](media/picture130.jpeg)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 -> -> ![](media/picture131.jpeg)![](media/picture132.jpeg)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 - ------------------------------------------------------------------------------------------------------ - -> ![](media/picture133.jpeg)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 -> -> ![](media/picture134.jpeg)![](media/picture135.jpeg)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 -> -> ![](media/picture136.jpeg)![](media/picture137.jpeg)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. - ------------------------------------------------------------------------------------------------- - -> ![](media/picture138.jpeg)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 -> -> ![](media/picture139.jpeg)![](media/picture140.jpeg)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 -> -> ![](media/picture141.jpeg)![](media/picture142.jpeg)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 -> -> ![](media/picture143.jpeg)![](media/picture144.jpeg)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. - ---------------------------------------------------------------------------------------------------- - -> ![](media/picture145.jpeg)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 -> -> ![](media/picture146.jpeg)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 -> -> ![](media/picture147.jpeg)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 -> -> ![](media/picture148.jpeg)![](media/picture149.jpeg)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 -> -> ![](media/picture150.jpeg)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 -> -> ![](media/picture151.jpeg)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 -> -> ![](media/picture152.jpeg)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 -> -> ![](media/picture153.jpeg)![](media/picture154.jpeg)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 -> -> ![](media/picture155.jpeg)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 -> -> ![](media/picture156.jpeg)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 -> -> ![](media/picture157.jpeg)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 -> -> ![](media/picture158.jpeg)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 -> -> ![](media/picture159.jpeg)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 -> -> ![](media/picture160.jpeg)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 -> -> ![](media/picture161.jpeg)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 -> -> ![](media/picture162.jpeg)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 -> -> ![](media/picture163.jpeg)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 -> -> ![](media/picture164.jpeg)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. - ---------------------------------------------------------------------------------------------------- - -> ![](media/picture165.jpeg)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 -> -> ![](media/picture166.jpeg)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 -> -> ![](media/picture167.jpeg)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. - ------------------------------------------------------------------------------------------------------------------------- - -> ![](media/picture168.jpeg)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. - --------------------------------------------------------------------------------------------------------- - -> ![](media/picture169.jpeg)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 -> -> ![](media/picture170.jpeg)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 -> -> ![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)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 -> -> ![](media/picture174.jpeg)![](media/picture175.jpeg)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 -> -> ![](media/picture176.jpeg)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 -> -> ![](media/picture177.jpeg)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 -> -> ![](media/picture178.jpeg)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 -> -> ![](media/picture179.jpeg)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 -> -> ![](media/picture180.jpeg)![](media/picture181.jpeg)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 -> -> ![](media/picture182.jpeg)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 -> -> ![](media/picture183.jpeg)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 -> -> ![](media/picture184.jpeg)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 -> -> ![](media/picture185.jpeg)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 -> -> ![](media/picture186.jpeg)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 -> -> ![](media/picture187.jpeg)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 -> -> ![](media/picture188.jpeg)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 > - - ------------------------------------------------------------------------------------------------------------- - -> ![](media/picture189.jpeg)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 - -> ![](media/picture190.jpeg)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 -> -> ![](media/picture191.jpeg)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 - -> ![](media/picture192.jpeg)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 -> -> ![](media/picture193.jpeg)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 - -> ![](media/picture194.jpeg)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 > - - ------------------------------------------------------------------------------------- - -> ![](media/picture195.jpeg)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 -> -> ![](media/picture196.jpeg)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 - ------------------------------------------------------------------------------ - -> ![](media/picture197.jpeg)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 - -> ![](media/picture198.jpeg)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) > - > - - -> ![](media/picture199.jpeg)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 > - > - - -> ![](media/picture200.jpeg)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 -> -> ![](media/picture201.jpeg)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 -> -> ![](media/picture202.jpeg)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 -> -> ![](media/picture203.jpeg)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 -> -> ![](media/picture204.jpeg)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 -> -> ![](media/picture205.jpeg)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 -> -> ![](media/picture206.jpeg)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 -> -> ![](media/picture207.jpeg)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 -> -> ![](media/picture208.jpeg)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 -> -> ![](media/picture209.jpeg)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 -> -> ![](media/picture210.jpeg)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 -> -> ![](media/picture211.jpeg)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 -> -> ![](media/picture212.jpeg)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 -> -> ![](media/picture213.jpeg)![](media/picture214.jpeg)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 -> -> ![](media/picture215.jpeg)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 -> -> ![](media/picture216.jpeg)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 -> -> ![](media/picture217.jpeg)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 - -------------------------------------------------------------------------------------------------------------------- - -> ![](media/picture218.jpeg)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 - -------------------------------------------------------------------------------------------------------------- - -> ![](media/picture219.jpeg)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 - --------------------------------------------------------------------------------- - -> ![](media/picture220.jpeg)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 -> -> ![](media/picture221.jpeg)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 -> -> ![](media/picture222.jpeg)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 -> -> ![](media/picture223.jpeg)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 -> -> ![](media/picture224.jpeg)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 -> -> ![](media/picture225.jpeg)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 -> -> ![](media/picture226.jpeg)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 -> -> ![](media/picture227.jpeg)![](media/picture228.jpeg)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 -> -> ![](media/picture229.jpeg)![](media/picture230.jpeg)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 - ---------------------------------------------------------------------------------------------- - -> ![](media/picture231.jpeg)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)   -> -> AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. -> -> Page  119  of  159 -> -> ![](media/picture233.jpeg)![](media/picture234.jpeg)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. - ------------------------------------------------------------------------------------------------------- - -> ![](media/picture235.jpeg)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 -> -> ![](media/picture236.jpeg)![](media/picture237.jpeg)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 -> -> ![](media/picture238.jpeg)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 -> -> ![](media/picture239.jpeg)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 -> -> ![](media/picture240.jpeg)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 -> -> ![](media/picture241.jpeg)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 -> -> ![](media/picture242.jpeg)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 -> -> ![](media/picture243.jpeg)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 -> -> ![](media/picture244.jpeg)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 -> -> ![](media/picture245.jpeg)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 -> -> ![](media/picture246.jpeg)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 -> -> ![](media/picture247.jpeg)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 -> -> ![](media/picture248.jpeg)![](media/picture249.jpeg)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 -> -> ![](media/picture250.jpeg)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 -> -> ![](media/picture251.jpeg)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 -> -> ![](media/picture252.jpeg)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 -> -> ![](media/picture253.jpeg)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 -> -> ![](media/picture254.jpeg)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 -> -> ![](media/picture255.jpeg)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 -> -> ![](media/picture256.jpeg)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 -> -> ![](media/picture257.jpeg)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 -> -> ![](media/picture258.jpeg)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 -> -> ![](media/picture259.jpeg)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 -> -> ![](media/picture260.jpeg)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 -> -> ![](media/picture261.jpeg)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 - ------------------------------------------------------------------------------- - -> ![](media/picture262.jpeg)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. -> -> ![](media/picture263.jpeg)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 -> -> ![](media/picture264.jpeg)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 -> -> ![](media/picture265.jpeg)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 -> -> ![](media/picture266.jpeg)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. - ------------------------------------------------------------------------------------------- - -> ![](media/picture267.jpeg)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 -> -> ![](media/picture268.jpeg)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 -> -> ![](media/picture269.jpeg)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 -> -> ![](media/picture270.jpeg)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 -> -> ![](media/picture271.jpeg)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 -> -> ![](media/picture272.jpeg)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 -> -> ![](media/picture273.jpeg)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 -> -> ![](media/picture274.jpeg)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 -> -> ![](media/picture275.jpeg)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 -- cgit