path: root/docs/agl-specs-v1.0/00-doorsNG-skimed.md

---
# 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)  <http://www.digital-cp.com/>
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  &lt;device&gt;”
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  &lt;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