From b613306283561ee1f35f70b268a9a63efc8e1bef Mon Sep 17 00:00:00 2001 From: Stephane Desneux Date: Fri, 11 Nov 2016 17:18:46 +0100 Subject: docs: add agl-specs-v1.0 in markdown format (wip) Change-Id: I5071c98d21154eefe13d5e2e97ccea6130668b06 Signed-off-by: Stephane Desneux --- agl-specs-v1.0/00-doorsNG-skimed.md | 4203 +++++++++++++++++++++++++++++++++++ 1 file changed, 4203 insertions(+) create mode 100644 agl-specs-v1.0/00-doorsNG-skimed.md (limited to 'agl-specs-v1.0/00-doorsNG-skimed.md') diff --git a/agl-specs-v1.0/00-doorsNG-skimed.md b/agl-specs-v1.0/00-doorsNG-skimed.md new file mode 100644 index 0000000..c5ffbd5 --- /dev/null +++ b/agl-specs-v1.0/00-doorsNG-skimed.md @@ -0,0 +1,4203 @@ +--- +# 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 +![](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 1.2.3-korg