From 0eba225fb27ec0b87bfa80361314fec5ab901caa Mon Sep 17 00:00:00 2001 From: Stephane Desneux Date: Tue, 16 Oct 2018 13:10:46 +0200 Subject: Import from docs-agl/docs Change-Id: Id524561d87410e5463cddd123b30eb63d75b62bd Signed-off-by: Stephane Desneux --- LICENSE | 201 + agl-specs-v1.0/00-doorsNG-original.md | 7753 ---- agl-specs-v1.0/00-doorsNG-skimed.md | 4203 --- agl-specs-v1.0/01-overview.md | 94 - agl-specs-v1.0/02-architecture.md | 13 - agl-specs-v1.0/03-homescreen.md | 8246 ---- agl-specs-v1.0/04-app-fw.md | 1499 - .../d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css | 37230 ------------------- .../d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm | 1 - ...cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp | Bin 172956 -> 0 bytes ...8b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp | Bin 48584 -> 0 bytes ...e2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp | Bin 52132 -> 0 bytes ...79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp | Bin 61162 -> 0 bytes ...33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp | Bin 106770 -> 0 bytes ...28_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp | Bin 137296 -> 0 bytes ...59_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp | Bin 86538 -> 0 bytes ...2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp | Bin 243156 -> 0 bytes ...27_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp | Bin 71924 -> 0 bytes ...ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp | Bin 163530 -> 0 bytes ...73_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp | Bin 130785 -> 0 bytes ...07_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp | Bin 17023 -> 0 bytes ...8a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp | Bin 25953 -> 0 bytes ...c7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp | Bin 106319 -> 0 bytes ...e9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp | Bin 20104 -> 0 bytes ...3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp | Bin 145549 -> 0 bytes ...99_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp | Bin 158334 -> 0 bytes ...4b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp | Bin 34545 -> 0 bytes ...ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp | Bin 165898 -> 0 bytes ...5e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp | Bin 165111 -> 0 bytes ...78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp | Bin 427432 -> 0 bytes ...79_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp | Bin 136272 -> 0 bytes ...76_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp | Bin 146056 -> 0 bytes ...a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp | Bin 61377 -> 0 bytes ...0d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp | Bin 30117 -> 0 bytes ...28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp | Bin 34032 -> 0 bytes ...rl_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css | 491 - ...L module_decomposition_diagram v1.0-rc1.pdf.png | Bin 172956 -> 0 bytes agl-specs-v1.0/media/Image 10.png | Bin 146056 -> 0 bytes agl-specs-v1.0/media/Image 14.png | Bin 20104 -> 0 bytes agl-specs-v1.0/media/Image 15.png | Bin 243156 -> 0 bytes agl-specs-v1.0/media/Image 16.png | Bin 61377 -> 0 bytes agl-specs-v1.0/media/Image 17.png | Bin 61162 -> 0 bytes agl-specs-v1.0/media/Image 21.png | Bin 165111 -> 0 bytes agl-specs-v1.0/media/Image 22.png | Bin 86538 -> 0 bytes agl-specs-v1.0/media/Image 23.png | Bin 25953 -> 0 bytes agl-specs-v1.0/media/Image 24.png | Bin 30117 -> 0 bytes agl-specs-v1.0/media/Image 25.png | Bin 106770 -> 0 bytes agl-specs-v1.0/media/Image 26.png | Bin 34545 -> 0 bytes agl-specs-v1.0/media/Image 27.png | Bin 137296 -> 0 bytes agl-specs-v1.0/media/Image 28.png | Bin 130785 -> 0 bytes agl-specs-v1.0/media/Image 29.png | Bin 427432 -> 0 bytes agl-specs-v1.0/media/Image 30.png | Bin 106319 -> 0 bytes agl-specs-v1.0/media/Image 39.png | Bin 34032 -> 0 bytes agl-specs-v1.0/media/Image 40.png | Bin 165898 -> 0 bytes agl-specs-v1.0/media/Image 41.png | Bin 158334 -> 0 bytes agl-specs-v1.0/media/Image 60.png | Bin 136272 -> 0 bytes agl-specs-v1.0/media/Image 8.png | Bin 52132 -> 0 bytes agl-specs-v1.0/media/Image 9.png | Bin 145549 -> 0 bytes agl-specs-v1.0/media/Smartlink State Diagram.png | Bin 163530 -> 0 bytes agl-specs-v1.0/media/picture95.png | Bin 180930 -> 0 bytes app-framework/index.md | 86 - audio/4a-framework.md | 6 - audio/bluez-alsa.md | 113 - docs/agl-specs-v1.0/00-doorsNG-original.md | 7753 ++++ docs/agl-specs-v1.0/00-doorsNG-skimed.md | 4203 +++ docs/agl-specs-v1.0/01-overview.md | 94 + docs/agl-specs-v1.0/02-architecture.md | 13 + docs/agl-specs-v1.0/03-homescreen.md | 8246 ++++ docs/agl-specs-v1.0/04-app-fw.md | 1499 + .../d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css | 37230 +++++++++++++++++++ .../d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm | 1 + ...cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp | Bin 0 -> 172956 bytes ...8b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp | Bin 0 -> 48584 bytes ...e2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp | Bin 0 -> 52132 bytes ...79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp | Bin 0 -> 61162 bytes ...33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp | Bin 0 -> 106770 bytes ...28_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp | Bin 0 -> 137296 bytes ...59_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp | Bin 0 -> 86538 bytes ...2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp | Bin 0 -> 243156 bytes ...27_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp | Bin 0 -> 71924 bytes ...ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp | Bin 0 -> 163530 bytes ...73_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp | Bin 0 -> 130785 bytes ...07_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp | Bin 0 -> 17023 bytes ...8a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp | Bin 0 -> 25953 bytes ...c7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp | Bin 0 -> 106319 bytes ...e9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp | Bin 0 -> 20104 bytes ...3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp | Bin 0 -> 145549 bytes ...99_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp | Bin 0 -> 158334 bytes ...4b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp | Bin 0 -> 34545 bytes ...ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp | Bin 0 -> 165898 bytes ...5e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp | Bin 0 -> 165111 bytes ...78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp | Bin 0 -> 427432 bytes ...79_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp | Bin 0 -> 136272 bytes ...76_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp | Bin 0 -> 146056 bytes ...a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp | Bin 0 -> 61377 bytes ...0d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp | Bin 0 -> 30117 bytes ...28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp | Bin 0 -> 34032 bytes ...rl_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css | 491 + ...L module_decomposition_diagram v1.0-rc1.pdf.png | Bin 0 -> 172956 bytes docs/agl-specs-v1.0/media/Image 10.png | Bin 0 -> 146056 bytes docs/agl-specs-v1.0/media/Image 14.png | Bin 0 -> 20104 bytes docs/agl-specs-v1.0/media/Image 15.png | Bin 0 -> 243156 bytes docs/agl-specs-v1.0/media/Image 16.png | Bin 0 -> 61377 bytes docs/agl-specs-v1.0/media/Image 17.png | Bin 0 -> 61162 bytes docs/agl-specs-v1.0/media/Image 21.png | Bin 0 -> 165111 bytes docs/agl-specs-v1.0/media/Image 22.png | Bin 0 -> 86538 bytes docs/agl-specs-v1.0/media/Image 23.png | Bin 0 -> 25953 bytes docs/agl-specs-v1.0/media/Image 24.png | Bin 0 -> 30117 bytes docs/agl-specs-v1.0/media/Image 25.png | Bin 0 -> 106770 bytes docs/agl-specs-v1.0/media/Image 26.png | Bin 0 -> 34545 bytes docs/agl-specs-v1.0/media/Image 27.png | Bin 0 -> 137296 bytes docs/agl-specs-v1.0/media/Image 28.png | Bin 0 -> 130785 bytes docs/agl-specs-v1.0/media/Image 29.png | Bin 0 -> 427432 bytes docs/agl-specs-v1.0/media/Image 30.png | Bin 0 -> 106319 bytes docs/agl-specs-v1.0/media/Image 39.png | Bin 0 -> 34032 bytes docs/agl-specs-v1.0/media/Image 40.png | Bin 0 -> 165898 bytes docs/agl-specs-v1.0/media/Image 41.png | Bin 0 -> 158334 bytes docs/agl-specs-v1.0/media/Image 60.png | Bin 0 -> 136272 bytes docs/agl-specs-v1.0/media/Image 8.png | Bin 0 -> 52132 bytes docs/agl-specs-v1.0/media/Image 9.png | Bin 0 -> 145549 bytes .../media/Smartlink State Diagram.png | Bin 0 -> 163530 bytes docs/agl-specs-v1.0/media/picture95.png | Bin 0 -> 180930 bytes docs/app-framework/index.md | 86 + docs/audio/4a-framework.md | 6 + docs/audio/bluez-alsa.md | 113 + docs/getting-started/customize_bitbake_conf.md | 53 + docs/getting-started/footers/intel-footer.md | 90 + docs/getting-started/footers/porter-footer.md | 23 + docs/getting-started/footers/raspberrypi-footer.md | 56 + .../RaspberryPi2-ModelB-debug-serial-cable.jpg | Bin 0 -> 96123 bytes .../machines/R-Car-Starter-Kit-gen3.md | 633 + docs/getting-started/machines/intel.md | 186 + docs/getting-started/machines/qemu.md | 119 + docs/getting-started/machines/raspberrypi.md | 39 + docs/getting-started/setup-sdk-environment.md | 124 + docs/getting-started/source-code.md | 201 + docs/getting-started/troubleshooting.md | 210 + docs/platform/working-on-the-chinook-branch.md | 122 + docs/platform/working-on-the-master-branch.md | 122 + docs/security-blueprint/README.md | 158 + docs/security-blueprint/WhiteBoxArchi.png | Bin 0 -> 348110 bytes docs/security-blueprint/annexes/0_Abstract.md | 7 + docs/security-blueprint/annexes/ConfigNotes.md | 485 + docs/security-blueprint/annexes/todoNotes.md | 80 + docs/security-blueprint/index.md | 22 + docs/security-blueprint/part-1/0_Abstract.md | 77 + docs/security-blueprint/part-2/0_Abstract.md | 64 + docs/security-blueprint/part-2/1-Image.md | 52 + .../part-2/2-Communication-modes.md | 89 + docs/security-blueprint/part-2/3-Consoles.md | 107 + docs/security-blueprint/part-3/0_Abstract.md | 18 + docs/security-blueprint/part-4/0_Abstract.md | 60 + docs/security-blueprint/part-4/1-General.md | 278 + docs/security-blueprint/part-4/2-Memory.md | 156 + docs/security-blueprint/part-4/3-Consoles.md | 78 + docs/security-blueprint/part-4/4-Debug.md | 208 + docs/security-blueprint/part-4/5-FileSystems.md | 60 + docs/security-blueprint/part-5/0_Abstract.md | 103 + docs/security-blueprint/part-5/1-MAC.md | 165 + docs/security-blueprint/part-5/2-SystemD.md | 60 + docs/security-blueprint/part-5/3-SystemBus.md | 24 + docs/security-blueprint/part-5/4-Services.md | 37 + docs/security-blueprint/part-5/5-AppFw.md | 315 + docs/security-blueprint/part-5/6-Utilities.md | 78 + docs/security-blueprint/part-5/7-Users.md | 77 + docs/security-blueprint/part-5/App-flow.png | Bin 0 -> 73545 bytes docs/security-blueprint/part-6/0_Abstract.md | 80 + docs/security-blueprint/part-6/1-Installation.md | 29 + .../part-6/2-PrivilegeManagement.md | 7 + docs/security-blueprint/part-6/3-Signature.md | 9 + docs/security-blueprint/part-6/4-Services.md | 10 + .../security-blueprint/part-6/App_signing_flow.png | Bin 0 -> 154923 bytes docs/security-blueprint/part-7/0_Abstract.md | 52 + .../part-7/1-BusAndConnectors.md | 68 + docs/security-blueprint/part-7/2-Wireless.md | 244 + docs/security-blueprint/part-7/3-Cloud.md | 107 + docs/security-blueprint/part-8/0_Abstract.md | 76 + docs/security-blueprint/part-8/1-FOTA.md | 41 + docs/security-blueprint/part-8/2-SOTA.md | 20 + docs/security-blueprint/part-9/0_Abstract.md | 62 + docs/signaling/architecture.md | 467 + docs/signaling/images/OpenXC_to_AGL.png | Bin 0 -> 84031 bytes docs/signaling/images/agent-arch.svg | 352 + docs/signaling/images/agent-sample.svg | 426 + docs/signaling/images/can-generator.svg | 244 + docs/signaling/images/cloud-arch.svg | 837 + docs/signaling/images/distributed-arch.png | Bin 0 -> 73736 bytes docs/signaling/images/distributed-arch.svg | 717 + docs/signaling/images/iotbzh_logo_small.png | Bin 0 -> 6989 bytes docs/signaling/images/logo_iot_bzh.svg | 142 + docs/signaling/images/signal-service-arch.svg | 296 + docs/signaling/index.md | 50 + getting-started/customize_bitbake_conf.md | 53 - getting-started/footers/intel-footer.md | 90 - getting-started/footers/porter-footer.md | 23 - getting-started/footers/raspberrypi-footer.md | 56 - .../RaspberryPi2-ModelB-debug-serial-cable.jpg | Bin 96123 -> 0 bytes getting-started/machines/R-Car-Starter-Kit-gen3.md | 633 - getting-started/machines/intel.md | 186 - getting-started/machines/qemu.md | 119 - getting-started/machines/raspberrypi.md | 39 - getting-started/setup-sdk-environment.md | 124 - getting-started/source-code.md | 201 - getting-started/troubleshooting.md | 210 - platform/working-on-the-chinook-branch.md | 122 - platform/working-on-the-master-branch.md | 122 - security-blueprint/README.md | 158 - security-blueprint/WhiteBoxArchi.png | Bin 348110 -> 0 bytes security-blueprint/annexes/0_Abstract.md | 7 - security-blueprint/annexes/ConfigNotes.md | 485 - security-blueprint/annexes/todoNotes.md | 80 - security-blueprint/index.md | 22 - security-blueprint/part-1/0_Abstract.md | 77 - security-blueprint/part-2/0_Abstract.md | 64 - security-blueprint/part-2/1-Image.md | 52 - security-blueprint/part-2/2-Communication-modes.md | 89 - security-blueprint/part-2/3-Consoles.md | 107 - security-blueprint/part-3/0_Abstract.md | 18 - security-blueprint/part-4/0_Abstract.md | 60 - security-blueprint/part-4/1-General.md | 278 - security-blueprint/part-4/2-Memory.md | 156 - security-blueprint/part-4/3-Consoles.md | 78 - security-blueprint/part-4/4-Debug.md | 208 - security-blueprint/part-4/5-FileSystems.md | 60 - security-blueprint/part-5/0_Abstract.md | 103 - security-blueprint/part-5/1-MAC.md | 165 - security-blueprint/part-5/2-SystemD.md | 60 - security-blueprint/part-5/3-SystemBus.md | 24 - security-blueprint/part-5/4-Services.md | 37 - security-blueprint/part-5/5-AppFw.md | 315 - security-blueprint/part-5/6-Utilities.md | 78 - security-blueprint/part-5/7-Users.md | 77 - security-blueprint/part-5/App-flow.png | Bin 73545 -> 0 bytes security-blueprint/part-6/0_Abstract.md | 80 - security-blueprint/part-6/1-Installation.md | 29 - security-blueprint/part-6/2-PrivilegeManagement.md | 7 - security-blueprint/part-6/3-Signature.md | 9 - security-blueprint/part-6/4-Services.md | 10 - security-blueprint/part-6/App_signing_flow.png | Bin 154923 -> 0 bytes security-blueprint/part-7/0_Abstract.md | 52 - security-blueprint/part-7/1-BusAndConnectors.md | 68 - security-blueprint/part-7/2-Wireless.md | 244 - security-blueprint/part-7/3-Cloud.md | 107 - security-blueprint/part-8/0_Abstract.md | 76 - security-blueprint/part-8/1-FOTA.md | 41 - security-blueprint/part-8/2-SOTA.md | 20 - security-blueprint/part-9/0_Abstract.md | 62 - signaling/architecture.md | 467 - signaling/images/OpenXC_to_AGL.png | Bin 84031 -> 0 bytes signaling/images/agent-arch.svg | 352 - signaling/images/agent-sample.svg | 426 - signaling/images/can-generator.svg | 244 - signaling/images/cloud-arch.svg | 837 - signaling/images/distributed-arch.png | Bin 73736 -> 0 bytes signaling/images/distributed-arch.svg | 717 - signaling/images/iotbzh_logo_small.png | Bin 6989 -> 0 bytes signaling/images/logo_iot_bzh.svg | 142 - signaling/images/signal-service-arch.svg | 296 - signaling/index.md | 50 - 259 files changed, 69108 insertions(+), 68907 deletions(-) create mode 100644 LICENSE delete mode 100644 agl-specs-v1.0/00-doorsNG-original.md delete mode 100644 agl-specs-v1.0/00-doorsNG-skimed.md delete mode 100644 agl-specs-v1.0/01-overview.md delete mode 100644 agl-specs-v1.0/02-architecture.md delete mode 100644 agl-specs-v1.0/03-homescreen.md delete mode 100644 agl-specs-v1.0/04-app-fw.md delete mode 100755 agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css delete mode 100755 agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm delete mode 100755 agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp delete mode 100755 agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp delete mode 100755 agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css delete mode 100644 agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png delete mode 100644 agl-specs-v1.0/media/Image 10.png delete mode 100644 agl-specs-v1.0/media/Image 14.png delete mode 100644 agl-specs-v1.0/media/Image 15.png delete mode 100644 agl-specs-v1.0/media/Image 16.png delete mode 100644 agl-specs-v1.0/media/Image 17.png delete mode 100644 agl-specs-v1.0/media/Image 21.png delete mode 100644 agl-specs-v1.0/media/Image 22.png delete mode 100644 agl-specs-v1.0/media/Image 23.png delete mode 100644 agl-specs-v1.0/media/Image 24.png delete mode 100644 agl-specs-v1.0/media/Image 25.png delete mode 100644 agl-specs-v1.0/media/Image 26.png delete mode 100644 agl-specs-v1.0/media/Image 27.png delete mode 100644 agl-specs-v1.0/media/Image 28.png delete mode 100644 agl-specs-v1.0/media/Image 29.png delete mode 100644 agl-specs-v1.0/media/Image 30.png delete mode 100644 agl-specs-v1.0/media/Image 39.png delete mode 100644 agl-specs-v1.0/media/Image 40.png delete mode 100644 agl-specs-v1.0/media/Image 41.png delete mode 100644 agl-specs-v1.0/media/Image 60.png delete mode 100644 agl-specs-v1.0/media/Image 8.png delete mode 100644 agl-specs-v1.0/media/Image 9.png delete mode 100644 agl-specs-v1.0/media/Smartlink State Diagram.png delete mode 100644 agl-specs-v1.0/media/picture95.png delete mode 100644 app-framework/index.md delete mode 100644 audio/4a-framework.md delete mode 100644 audio/bluez-alsa.md create mode 100644 docs/agl-specs-v1.0/00-doorsNG-original.md create mode 100644 docs/agl-specs-v1.0/00-doorsNG-skimed.md create mode 100644 docs/agl-specs-v1.0/01-overview.md create mode 100644 docs/agl-specs-v1.0/02-architecture.md create mode 100644 docs/agl-specs-v1.0/03-homescreen.md create mode 100644 docs/agl-specs-v1.0/04-app-fw.md create mode 100755 docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css create mode 100755 docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm create mode 100755 docs/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp create mode 100755 docs/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css create mode 100644 docs/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png create mode 100644 docs/agl-specs-v1.0/media/Image 10.png create mode 100644 docs/agl-specs-v1.0/media/Image 14.png create mode 100644 docs/agl-specs-v1.0/media/Image 15.png create mode 100644 docs/agl-specs-v1.0/media/Image 16.png create mode 100644 docs/agl-specs-v1.0/media/Image 17.png create mode 100644 docs/agl-specs-v1.0/media/Image 21.png create mode 100644 docs/agl-specs-v1.0/media/Image 22.png create mode 100644 docs/agl-specs-v1.0/media/Image 23.png create mode 100644 docs/agl-specs-v1.0/media/Image 24.png create mode 100644 docs/agl-specs-v1.0/media/Image 25.png create mode 100644 docs/agl-specs-v1.0/media/Image 26.png create mode 100644 docs/agl-specs-v1.0/media/Image 27.png create mode 100644 docs/agl-specs-v1.0/media/Image 28.png create mode 100644 docs/agl-specs-v1.0/media/Image 29.png create mode 100644 docs/agl-specs-v1.0/media/Image 30.png create mode 100644 docs/agl-specs-v1.0/media/Image 39.png create mode 100644 docs/agl-specs-v1.0/media/Image 40.png create mode 100644 docs/agl-specs-v1.0/media/Image 41.png create mode 100644 docs/agl-specs-v1.0/media/Image 60.png create mode 100644 docs/agl-specs-v1.0/media/Image 8.png create mode 100644 docs/agl-specs-v1.0/media/Image 9.png create mode 100644 docs/agl-specs-v1.0/media/Smartlink State Diagram.png create mode 100644 docs/agl-specs-v1.0/media/picture95.png create mode 100644 docs/app-framework/index.md create mode 100644 docs/audio/4a-framework.md create mode 100644 docs/audio/bluez-alsa.md create mode 100644 docs/getting-started/customize_bitbake_conf.md create mode 100644 docs/getting-started/footers/intel-footer.md create mode 100644 docs/getting-started/footers/porter-footer.md create mode 100644 docs/getting-started/footers/raspberrypi-footer.md create mode 100644 docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg create mode 100644 docs/getting-started/machines/R-Car-Starter-Kit-gen3.md create mode 100644 docs/getting-started/machines/intel.md create mode 100644 docs/getting-started/machines/qemu.md create mode 100644 docs/getting-started/machines/raspberrypi.md create mode 100644 docs/getting-started/setup-sdk-environment.md create mode 100644 docs/getting-started/source-code.md create mode 100644 docs/getting-started/troubleshooting.md create mode 100644 docs/platform/working-on-the-chinook-branch.md create mode 100644 docs/platform/working-on-the-master-branch.md create mode 100644 docs/security-blueprint/README.md create mode 100644 docs/security-blueprint/WhiteBoxArchi.png create mode 100644 docs/security-blueprint/annexes/0_Abstract.md create mode 100644 docs/security-blueprint/annexes/ConfigNotes.md create mode 100644 docs/security-blueprint/annexes/todoNotes.md create mode 100644 docs/security-blueprint/index.md create mode 100644 docs/security-blueprint/part-1/0_Abstract.md create mode 100644 docs/security-blueprint/part-2/0_Abstract.md create mode 100644 docs/security-blueprint/part-2/1-Image.md create mode 100644 docs/security-blueprint/part-2/2-Communication-modes.md create mode 100644 docs/security-blueprint/part-2/3-Consoles.md create mode 100644 docs/security-blueprint/part-3/0_Abstract.md create mode 100644 docs/security-blueprint/part-4/0_Abstract.md create mode 100644 docs/security-blueprint/part-4/1-General.md create mode 100644 docs/security-blueprint/part-4/2-Memory.md create mode 100644 docs/security-blueprint/part-4/3-Consoles.md create mode 100644 docs/security-blueprint/part-4/4-Debug.md create mode 100644 docs/security-blueprint/part-4/5-FileSystems.md create mode 100644 docs/security-blueprint/part-5/0_Abstract.md create mode 100644 docs/security-blueprint/part-5/1-MAC.md create mode 100644 docs/security-blueprint/part-5/2-SystemD.md create mode 100644 docs/security-blueprint/part-5/3-SystemBus.md create mode 100644 docs/security-blueprint/part-5/4-Services.md create mode 100644 docs/security-blueprint/part-5/5-AppFw.md create mode 100644 docs/security-blueprint/part-5/6-Utilities.md create mode 100644 docs/security-blueprint/part-5/7-Users.md create mode 100644 docs/security-blueprint/part-5/App-flow.png create mode 100644 docs/security-blueprint/part-6/0_Abstract.md create mode 100644 docs/security-blueprint/part-6/1-Installation.md create mode 100644 docs/security-blueprint/part-6/2-PrivilegeManagement.md create mode 100644 docs/security-blueprint/part-6/3-Signature.md create mode 100644 docs/security-blueprint/part-6/4-Services.md create mode 100644 docs/security-blueprint/part-6/App_signing_flow.png create mode 100644 docs/security-blueprint/part-7/0_Abstract.md create mode 100644 docs/security-blueprint/part-7/1-BusAndConnectors.md create mode 100644 docs/security-blueprint/part-7/2-Wireless.md create mode 100644 docs/security-blueprint/part-7/3-Cloud.md create mode 100644 docs/security-blueprint/part-8/0_Abstract.md create mode 100644 docs/security-blueprint/part-8/1-FOTA.md create mode 100644 docs/security-blueprint/part-8/2-SOTA.md create mode 100644 docs/security-blueprint/part-9/0_Abstract.md create mode 100644 docs/signaling/architecture.md create mode 100644 docs/signaling/images/OpenXC_to_AGL.png create mode 100644 docs/signaling/images/agent-arch.svg create mode 100644 docs/signaling/images/agent-sample.svg create mode 100644 docs/signaling/images/can-generator.svg create mode 100644 docs/signaling/images/cloud-arch.svg create mode 100644 docs/signaling/images/distributed-arch.png create mode 100644 docs/signaling/images/distributed-arch.svg create mode 100644 docs/signaling/images/iotbzh_logo_small.png create mode 100644 docs/signaling/images/logo_iot_bzh.svg create mode 100644 docs/signaling/images/signal-service-arch.svg create mode 100644 docs/signaling/index.md delete mode 100644 getting-started/customize_bitbake_conf.md delete mode 100644 getting-started/footers/intel-footer.md delete mode 100644 getting-started/footers/porter-footer.md delete mode 100644 getting-started/footers/raspberrypi-footer.md delete mode 100644 getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg delete mode 100644 getting-started/machines/R-Car-Starter-Kit-gen3.md delete mode 100644 getting-started/machines/intel.md delete mode 100644 getting-started/machines/qemu.md delete mode 100644 getting-started/machines/raspberrypi.md delete mode 100644 getting-started/setup-sdk-environment.md delete mode 100644 getting-started/source-code.md delete mode 100644 getting-started/troubleshooting.md delete mode 100644 platform/working-on-the-chinook-branch.md delete mode 100644 platform/working-on-the-master-branch.md delete mode 100644 security-blueprint/README.md delete mode 100644 security-blueprint/WhiteBoxArchi.png delete mode 100644 security-blueprint/annexes/0_Abstract.md delete mode 100644 security-blueprint/annexes/ConfigNotes.md delete mode 100644 security-blueprint/annexes/todoNotes.md delete mode 100644 security-blueprint/index.md delete mode 100644 security-blueprint/part-1/0_Abstract.md delete mode 100644 security-blueprint/part-2/0_Abstract.md delete mode 100644 security-blueprint/part-2/1-Image.md delete mode 100644 security-blueprint/part-2/2-Communication-modes.md delete mode 100644 security-blueprint/part-2/3-Consoles.md delete mode 100644 security-blueprint/part-3/0_Abstract.md delete mode 100644 security-blueprint/part-4/0_Abstract.md delete mode 100644 security-blueprint/part-4/1-General.md delete mode 100644 security-blueprint/part-4/2-Memory.md delete mode 100644 security-blueprint/part-4/3-Consoles.md delete mode 100644 security-blueprint/part-4/4-Debug.md delete mode 100644 security-blueprint/part-4/5-FileSystems.md delete mode 100644 security-blueprint/part-5/0_Abstract.md delete mode 100644 security-blueprint/part-5/1-MAC.md delete mode 100644 security-blueprint/part-5/2-SystemD.md delete mode 100644 security-blueprint/part-5/3-SystemBus.md delete mode 100644 security-blueprint/part-5/4-Services.md delete mode 100644 security-blueprint/part-5/5-AppFw.md delete mode 100644 security-blueprint/part-5/6-Utilities.md delete mode 100644 security-blueprint/part-5/7-Users.md delete mode 100644 security-blueprint/part-5/App-flow.png delete mode 100644 security-blueprint/part-6/0_Abstract.md delete mode 100644 security-blueprint/part-6/1-Installation.md delete mode 100644 security-blueprint/part-6/2-PrivilegeManagement.md delete mode 100644 security-blueprint/part-6/3-Signature.md delete mode 100644 security-blueprint/part-6/4-Services.md delete mode 100644 security-blueprint/part-6/App_signing_flow.png delete mode 100644 security-blueprint/part-7/0_Abstract.md delete mode 100644 security-blueprint/part-7/1-BusAndConnectors.md delete mode 100644 security-blueprint/part-7/2-Wireless.md delete mode 100644 security-blueprint/part-7/3-Cloud.md delete mode 100644 security-blueprint/part-8/0_Abstract.md delete mode 100644 security-blueprint/part-8/1-FOTA.md delete mode 100644 security-blueprint/part-8/2-SOTA.md delete mode 100644 security-blueprint/part-9/0_Abstract.md delete mode 100644 signaling/architecture.md delete mode 100644 signaling/images/OpenXC_to_AGL.png delete mode 100644 signaling/images/agent-arch.svg delete mode 100644 signaling/images/agent-sample.svg delete mode 100644 signaling/images/can-generator.svg delete mode 100644 signaling/images/cloud-arch.svg delete mode 100644 signaling/images/distributed-arch.png delete mode 100644 signaling/images/distributed-arch.svg delete mode 100644 signaling/images/iotbzh_logo_small.png delete mode 100644 signaling/images/logo_iot_bzh.svg delete mode 100644 signaling/images/signal-service-arch.svg delete mode 100644 signaling/index.md diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..8dada3e --- /dev/null +++ b/LICENSE @@ -0,0 +1,201 @@ + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + + 4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + + 5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + + 6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + + 7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + + 8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + + 9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + + END OF TERMS AND CONDITIONS + + APPENDIX: How to apply the Apache License to your work. + + To apply the Apache License to your work, attach the following + boilerplate notice, with the fields enclosed by brackets "{}" + replaced with your own identifying information. (Don't include + the brackets!) The text should be enclosed in the appropriate + comment syntax for the file format. We also recommend that a + file or class name and description of purpose be included on the + same "printed page" as the copyright notice for easier + identification within third-party archives. + + Copyright {yyyy} {name of copyright owner} + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. diff --git a/agl-specs-v1.0/00-doorsNG-original.md b/agl-specs-v1.0/00-doorsNG-original.md deleted file mode 100644 index d41635d..0000000 --- a/agl-specs-v1.0/00-doorsNG-original.md +++ /dev/null @@ -1,7753 +0,0 @@ ---- -# Master Header for Jkyll ---- - -> ![](media/picture8.jpeg)![](media/picture9.jpeg)Version   1.0 -> -> Automotive Grade Linux -> -> Requirements Specification -> -> May   28,   2015 -> -> www.automotivelinux.org -> -> www.linuxfoundation.org -> -> ![](media/picture10.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Table of Contents -> -> [***1***](#5)***  Automotive  Grade  Linux ...............................................................................................*** -> ***5*** -> -> [**1.1**](#5)**  Overview  ............................................................................................................................** -> **5** -> -> [**1.2**](#6)**  Document  Scope.................................................................................................................** -> **6** -> -> [**1.3**](#6)**  Glossary  of  Terms  ..............................................................................................................** -> **6** -> -> [***2***](#7)***  Architecture ..................................................................................................................*** -> ***7*** -> -> [***3***](#8)***  App/HMI  Layer  .............................................................................................................*** -> ***8*** -> -> [**3.1**](#9)**  Home  Screen  ......................................................................................................................** -> **9** -> -> [3.1.1](#9)  Layout......................................................................................................................................... -> 9 -> -> [3.1.2](#10)  System  UI  Parts........................................................................................................................ -> 10 -> -> [3.1.3](#10)  Application  Management .......................................................................................................... -> 10 -> -> [3.1.4](#10)  Application  Switch.................................................................................................................... -> 10 -> -> [3.1.5](#10)  Application  History ................................................................................................................... -> 10 -> -> [3.1.6](#12)  Application  Stack ...................................................................................................................... -> 12 -> -> [3.1.7](#14)  Role  of  Home  Screen................................................................................................................ -> 14 -> -> [3.1.8](#16)  Requirements  ........................................................................................................................... -> 16 -> -> [***4***](#20)***  Application  Framework  Layer .....................................................................................*** -> ***20*** -> -> [**4.1**](#20)**  AGL  Application  Framework .............................................................................................** -> **20** -> -> [4.1.1](#21)  Application  Manager................................................................................................................. -> 21 -> -> [4.1.2](#21)  Window  Manager ..................................................................................................................... -> 21 -> -> [4.1.3](#27)  Policy  Manager ......................................................................................................................... -> 27 -> -> [4.1.4](#59)  Sound  Manager  ........................................................................................................................ -> 59 -> -> [4.1.5](#63)  Input  Manager .......................................................................................................................... -> 63 -> -> [4.1.6](#65)  User  Manager ........................................................................................................................... -> 65 -> -> [**4.2**](#71)**  Web  HMI ..........................................................................................................................** -> **71** -> -> [4.2.1](#71)  Web  API  ................................................................................................................................... -> 71 -> -> [4.2.2](#75)  Web  Runtime............................................................................................................................ -> 75 -> -> [**4.3**](#76)**  Native  HMI .......................................................................................................................** -> **76** -> -> [4.3.1](#76)  Native  App  Runtime.................................................................................................................. -> 76 -> -> [4.3.2](#77)  Native  Application  Framework  ................................................................................................. -> 77 -> -> [***5***](#77)***  Services  Layer  ............................................................................................................*** -> ***77*** -> -> [**5.1**](#78)**  Platform  Services  .............................................................................................................** -> **78** -> -> [5.1.1](#78)  Bluetooth  ................................................................................................................................. -> 78 -> -> [5.1.2](#92)  Error  Management.................................................................................................................... -> 92 -> -> [5.1.3](#98)  Graphics  ................................................................................................................................... -> 98 -> -> [5.1.4](#98)  Location  Services...................................................................................................................... -> 98 -> -> Page  2  of  159 -> -> ![](media/picture46.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> [5.1.5](#100)  Health  Monitoring .................................................................................................................. -> 100 -> -> [5.1.6](#100)  IPC  ......................................................................................................................................... -> 100 -> -> [5.1.7](#100)  Lifecycle  Management............................................................................................................ -> 100 -> -> [5.1.8](#100)  Network  Services................................................................................................................... -> 100 -> -> [5.1.9](#100)  Persistent  Storage  ................................................................................................................. -> 100 -> -> [5.1.10](#100)  Power  Management ............................................................................................................. -> 100 -> -> [5.1.11](#102)  Resource  Management......................................................................................................... -> 102 -> -> [5.1.12](#102)  Telephony  Services .............................................................................................................. -> 102 -> -> [5.1.13](#103)  Wi-Fi .................................................................................................................................... -> 103 -> -> [5.1.14](#110)  Window  System................................................................................................................... -> 110 -> -> [**5.2**](#111)**  Automotive  Services  ......................................................................................................** -> **111** -> -> [5.2.1](#111)  Audio  Services........................................................................................................................ -> 111 -> -> [5.2.2](#111)  Camera  Services..................................................................................................................... -> 111 -> -> [5.2.3](#111)  Configuration  Services ........................................................................................................... -> 111 -> -> [5.2.4](#111)  Diagnostic  Services ................................................................................................................ -> 111 -> -> [5.2.5](#111)  Multimedia  Services  ............................................................................................................... -> 111 -> -> [5.2.6](#116)  Navigation  Services................................................................................................................ -> 116 -> -> [5.2.7](#117)  PIM......................................................................................................................................... -> 117 -> -> [5.2.8](#117)  Smartphone  Link  .................................................................................................................... -> 117 -> -> [5.2.9](#125)  Speech  Services  ..................................................................................................................... -> 125 -> -> [5.2.10](#125)  Tuner  Services  ..................................................................................................................... -> 125 -> -> [5.2.11](#132)  Vehicle  Bus  /  Vehicle  Info  Control........................................................................................ -> 132 -> -> [5.2.12](#141)  Telematics  Services.............................................................................................................. -> 141 -> -> [5.2.13](#142)  Window  System................................................................................................................... -> 142 -> -> [***6***](#143)***  Security  Services......................................................................................................*** -> ***143*** -> -> [**6.1**](#143)**  Access  Control ...............................................................................................................** -> **143** -> -> [6.1.1](#144)  Requirements ......................................................................................................................... -> 144 -> -> [***7***](#144)***  Operating  System  Layer  ..........................................................................................*** -> ***144*** -> -> [**7.1**](#144)**  Kernel  ............................................................................................................................** -> **144** -> -> [7.1.1](#144)  Linux  Kernel  ........................................................................................................................... -> 144 -> -> [**7.2**](#145)**  Boot  Loader  ...................................................................................................................** -> **145** -> -> [**7.3**](#145)**  Hypervisor  .....................................................................................................................** -> **145** -> -> [7.3.1](#145)  Requirements ......................................................................................................................... -> 145 -> -> [**7.4**](#145)**  Operating  System  ..........................................................................................................** -> **145** -> -> [7.4.1](#145)  File  Systems ........................................................................................................................... -> 145 -> -> [7.4.2](#150)  Resource  Control  ................................................................................................................... -> 150 -> -> [7.4.3](#153)  Startup/Shutdown  Control  .................................................................................................... -> 153 -> -> [7.4.4](#155)  Database ................................................................................................................................ -> 155 -> -> [7.4.5](#156)  System  Update....................................................................................................................... -> 156 -> -> [**7.5**](#157)**  Device  Drivers ................................................................................................................** -> **157** -> -> Page  3  of  159 -> -> ![](media/picture87.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> [7.5.1](#157)  Peripherals ............................................................................................................................. -> 157 -> -> [7.5.2](#158)  Graphics  Drivers..................................................................................................................... -> 158 -> -> [7.5.3](#158)  Video  Drivers.......................................................................................................................... -> 158 -> -> [7.5.4](#158)  Audio  Codecs  ......................................................................................................................... -> 158 -> -> [7.5.5](#158)  Automotive  Devices  ............................................................................................................... -> 158 -> -> [***8***](#159)***  Notices.....................................................................................................................*** -> ***159*** -> -> Page  4  of  159 -> -> ![](media/picture94.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **1   Automotive   Grade   Linux** -> -> 1.1  Overview -> -> Automotive  Grade  Linux  (AGL)  is  a  Linux  Foundation  Workgroup  dedicated  to  creating  open -> -> source  software  solutions  for  automotive  applications.  Although  the  initial  target  for  AGL  is  In- -> -> Vehicle-Infotainment  (IVI)  systems,  additional  use  cases  such  as  instrument  clusters  and  and -> -> telematics  systems  will  eventually  be  supported.  AGL  has  participants  from  the  Automotive, -> -> Communications,  and  Semiconductor  Industries  and  welcomes  contributions  from  individual -> -> developers. -> -> By  leveraging  the  over  \$10B  of  investment  made  in  the  Linux  kernel  and  other  open  source -> -> software  projects,  the  AGL  Workgroup: -> -> · -> Enables  rapid  software  innovation  for  automotive  suppliers  to  keep  up  with  the  demand -> -> from  consumers  for  better  IVI  experiences -> -> · -> Utilizes  the  talents  of  thousands  of  open  source  software  developers  dedicated  to -> -> maintaining  the  core  software  in  areas  like  the  Linux  kernel,  networking,  and -> -> connectivity,  used  in  systems  across  numerous  industries -> -> The  goals  of  the  Automotive  Grade  Linux  Workgroup  are  to  provide: -> -> · -> An  automotive-focused  core  Linux  operating  system  stack  that  meets  common  and -> -> shared  requirements  of  the  automotive  ecosystem  with  a  broad  community  of -> -> support  that  includes  individual  developers,  academic  organizations  and  companies. -> -> · -> A  transparent,  collaborative,  and  open  environment  for  Automotive  OEMs,  Tier  One -> -> suppliers,  and  their  semiconductor  and  software  vendors  to  create  amazing  in-vehicle -> -> software. -> -> · -> A  collective  voice  for  working  with  other  open  source  projects  and  developing  new  open -> -> source  solutions. -> -> · -> An  embedded  Linux  distribution  that  enables  rapid  prototyping  for  developers  new  to -> -> Linux  or  teams  with  prior  open  source  experience -> -> This  results  in  faster  time  to  market  by  jump-starting  product  teams  with  reference  applications -> -> running  on  multiple  hardware  platforms. -> -> Page  5  of  159 - - > **Term** > **Definition** - ------------ ------------------------------------------ - > A2DP > Advanced  Audio  Distribution  Profile - > AGL > Automotive  Grade  Linux - > AVRCP > Audio  Video  Remote  Control  Profile - > FS > File  System - > GPS > Global  Positioning  System - > GPU > Graphical  Processing  Unit - -> ![](media/picture95.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 1.2  Document  Scope -> -> The  scope  of  this  document  is  to  define  the  architecture  of  the  Automotive  Grade  Linux  software -> -> platform.  The  requirements  are  broken  up  into  an  overview  of  the  Architecture  and  a  description -> -> of  each  of  the  layers  in  the  architecture  followed  by  the  requirements  for  each  module  in  the -> -> various  layers.  The  Architecture  Diagram  and  the  layout  of  the  specification  take  into -> -> consideration  all  of  the  components  that  would  be  needed  for  an  IVI  system;  however  the  are -> -> missing  requirements  for  individual  modules.  As  the  spec  continues  to  evolve  those  sections  will -> -> continue  to  be  filled  in. -> -> The  main  goal  of  this  document  is  to  define  the  core  software  platform  from  which  applications -> -> can  be  built.  As  such,  this  document  does  not  define  application  requirements  except  in  a  single -> -> case  (Home  Screen).  Application  requirements  will  be  developed  by  various  projects  that  use  the -> -> AGL  platform.  Those  application  requirements  can  be  used  to  drive  new  or  revised -> -> requirements  into  the  platform. -> -> At  this  time  there  is  no  plan  to  use  this  specification  to  create  a  compliance  or  certification -> -> program.  The  specification  is  used  as  blueprint  to  guide  the  overall  work  of  AGL  and  to  derive -> -> work  packages  for  companies  and  individuals  to  complete  in  order  to  attain  the  goals  of  the  AGL -> -> Workgroup. -> -> 1.3  Glossary  of  Terms - - > HFP > Hands  Free  Profile - -------- ------------------------------------- - > IBOC > In-Band  On  Channel - > LTSI > Long  Term  Support  Initiative - > NTP > Network  Time  Protocol - > OEM > Original  Equipment  Manufacturer - > OS > Operating  System - > OSS > Open  Source  Software - > SDL > Smart  Device  Link - > STT > Speech  to  Text - > TTS > Text  to  Speech - -> ![](media/picture96.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **2   Architecture** -> -> The  Automotive  Grade  Linux  Software  Architecture  diagram  is  below.  The  architecture  consists -> -> of  five  layers.  The  App/HMI  layer  contains  applications  with  their  associated  business  logic  and -> -> HMI.  Generally  applications  are  out  of  scope  for  this  document  since  they  are  product  specific -> -> for  the  OEM  that  is  developing  a  system  based  on  AGL. -> -> The  Application  Framework  layer  provides  the  APIs  for  creating  both  managing  and  running -> -> applications  on  an  AGL  system.  The  Services  layer  contains  user  space  services  that  all -> -> applications  can  access.  The  Operating  System  (OS)  layer  provides  the  Linux  kernel  and  device -> -> drivers  along  with  standard  OS  utilities. -> -> Page  7  of  159 -> -> ![](media/picture97.jpeg)![](media/picture98.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **3   App/HMI   Layer** -> -> Applications  may  use  a  web  based  framework  or  a  native  framework.  A  system  may  include -> -> applications  that  use  different  frameworks.  Coordination  of  applications  between  frameworks  is -> -> performed  by  the  AGL  App  Framework.  The  diagram  represents  possible  applications  that  could -> -> appear  in  a  given  system,  but  is  not  all  inclusive.  Reference  applications  may  be  provided  by  AGL -> -> Page  8  of  159 -> -> ![](media/picture99.jpeg)![](media/picture100.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> to  demonstrate  the  capabilities  of  the  platform. -> -> 3.1  Home  Screen -> -> Home  Screen  provides  the  Home  User  Interface  (Home  UI)  of  the  system  which  meets  the -> -> following  requirements: -> -> · Rich  User  Experience  (Rich  UX) -> -> · Driver  Distraction  mitigation -> -> · Variations  support -> -> Rich  UX  covers  requirements  such  as  usability  and  user  satisfaction.  Driver  Distraction  mitigation -> -> covers  requirements  on  display  control  and  user  operation  behavior  while  vehicle  is  in  motion  to -> -> minimize  driver  distraction.  Variations  support  covers  requirements  to  support  customization  of -> -> design  and  behavior  of  the  system  to  meet  the  different  needs  of  vehicle  type,  destination  and -> -> grade. -> -> **3.1.1  Layout** -> -> The  following  use  cases  are  considered  for  Layout. -> -> · -> Home  Screen  developer  changes  the  Home  UI  by  using  a  customizable  layout  definition. -> -> Page  9  of  159 -> -> ![](media/picture101.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **3.1.2  System  UI  Parts** -> -> The  use  case  assumed  about  System  UI  Parts  is  as  follows. -> -> · -> An  application  or  System  uses  status  bar  and  on-screen  in  order  to  notify  information  to -> -> a  user. -> -> · -> User  uses  the  system  setting  UI  in  order  to  change  settings. -> -> · User  uses  software  keyboard  in  order  to  input  characters. -> -> **3.1.3  Application  Management** -> -> The  use  case  assumed  about  Application  Management  is  as  follows. -> -> · -> A  user  downloads  and  installs  or  updates  the  delivery  application  from  application  store. -> -> · A  user  uninstalls  the  delivery  application. -> -> · -> A  user  launches  the  installed  delivery  application  or  the  pre-installed  application. -> -> · Also  a  user  terminates  those  applications. -> -> **3.1.4  Application  Switch** -> -> The  use  case  assumed  about  Application  Switch  is  as  follows. -> -> · -> User  switches  application  via  application  history  or  application  stack. -> -> · -> The  system  switches  application  according  to  Driving  Mode  status. -> -> **3.1.5  Application  History** -> -> Application  switching  by  application  history  is  assumed  as  follows. -> -> · -> The  system  records  the  order  of  the  applications  in  the  order  in  which  the  application  is -> -> displayed. -> -> · -> The  order  of  application  that  is  recorded  is  updated  each  time  the  display  of  the -> -> application  is  switched. -> -> · -> Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the -> -> history  at  the  time  of  switching  applications. -> -> Page  10  of  159 -> -> ![](media/picture102.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> ‑  Specification  of  operation -> -> -  User  runs  a  swipe  from  the  edge  of  the  application  screen  area. -> -> ‑  Specification  of  action -> -> -  The  order  of  the  screen  is  managed  order  management  list  (application  history). -> -> -  List  order  update  opportunity(Update  has  determined  a  display  of  the  application) -> -> -  Application  starts  or  stops. -> -> -  Allowed  to  stand  between  the  screen  N  seconds  after  the  swipe. -> -> ‑"N  seconds"‑User  defines  the  value  of  any. -> -> -  User  to  operate  the  screen  after  you  swipe. -> -> ‑"operation"‑Screen  tap.  Menu  display.  Other. -> -> Figure  5‑2  represents  a  sample  Home  Screen  depicting  the  above  mentioned  use  cases. -> -> Page  11  of  159 -> -> ![](media/picture103.jpeg)![](media/picture104.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **3.1.6  Application  Stack** -> -> Application  switching  by  application  stack  is  assumed  as  follows. -> -> · -> The  user  specifies  the  type  of  any  order.  The  system  records  the  order  of  the  application -> -> to  the  rule  as  of  the  specified  type. -> -> · Examples  of  the  types  of  any  order -> -> · Application  start-up  order -> -> · -> Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the  stack -> -> Page  12  of  159 -> -> ![](media/picture105.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> when  switching  applications. -> -> ‑  Specification  of  operation -> -> · -> User  runs  a  swipe  from  the  edge  of  the  application  screen  area. -> -> ‑  Specification  of  action -> -> · -> The  order  of  the  screen  is  managed  order  management  list  (application  stack). -> -> · -> List  order  update  opportunity.(Application  start-up  order  as  an  example) -> -> · -> Application  that  started  at  the  end  of  the  list  when  the  application  is  started  is  added. -> -> · -> Application  that  has  stopped  from  the  list  when  the  application  is  stopped  will  be -> -> deleted. -> -> Figure  5-3  represents  the  switching  example  depicting  the  application  of  the  above  switching. -> -> Page  13  of  159 - - -------------------------------------------------------------------------------------- - > **No** > **Use  Case** > **Role** > **Description** - ---------- ----------------- --------------- ----------------------------------------- - > 1-1 > Layout > GUI  Layout > Function  to  define  a  customizable - > > - > definition > GUI  Layout  definition. - -------------------------------------------------------------------------------------- - -> ![](media/picture106.jpeg)![](media/picture107.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **3.1.7  Role  of  Home  Screen** -> -> Table  5-1  describes  the  role  of  the  Home  Screen  to  satisfy  the  purpose  and  use  cases -> -> Page  14  of  159 - - ---------------------------------------------------------------------------------------------------- - > 1-2 > Change  Layout > Function  to  apply  the  customized - > - > GUI  layout  definition. - ------- --------------------- ------------------------ --------------------------------------------- - > 2-1 > System  UI  Parts > Status  Bar > Function  to  display  the - > - > information  from  application  or - > - > system. - > - > Function  to  quickly  access  and  set - > - > certain  system  settings. - - > 2-2 > On-screen > Function  to  display  a  popup - > - > window  such  as  alert  messages. - - > 2-3 > System  Setting > Function  to  display  system - > - > settings  menu  regarding  GUI, - > - > such  as  locale  and  network. - - > 2-4 > Software > Function  to  display  software - > > - > Keyboard > keyboard. - - > 3-1 > Application > Application > Function  to  download - > > > - > Management > Management > applications  from  application - > - > store.  Function  to  install,  uninstall - > - > and  update  the  downloaded - > - > applications. - - > 3-2 > Application > Function  to  launch/terminate - > > - > Launcher > applications. - - > 4-1 > Application > Application  List > Function  to  switch  applications  by - > > - > Switch > installed  application  list. - - > 4-2 > Application  History > Function  which  switches - > - > application  in  order  by - > - > applications  history. - - > 4-3 > Application  Stack > Function  to  switch  application  in - > - > any  order. - ---------------------------------------------------------------------------------------------------- - -> ![](media/picture108.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **Table  5-2:  Relevance  of  the  Role  and  Purpose** -> -> Page  15  of  159 - - ----------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Rich  UX** > **Driver** > **Variations** - > > - > **Distraction** > **support** - > - > **mitigation** - ----------- --------------------------- ---------------- ------------------- ------------------ - > 1-1 > GUI  Layout  definition > ‑ > ‑ > ‑ - - > 1-2 > Change  Layout > ‑ > ‑ > ‑ - - > 2-1 > Status  Bar > ‑ > ‑ - - > 2-2 > On-screen > ‑ > ‑ - - > 2-3 > System  Setting > ‑ > ‑ - - > 2-4 > Software  Keyboard > ‑ > ‑ - - > 3-1 > Application  Management > ‑ > ‑ - - > 3-2 > Application  Launcher > ‑ > ‑ - - > 4-1 > Application  List > ‑ > ‑ - - > 4-2 > Application  History > ‑ > ‑ - - > 4-3 > Application  Stack > ‑ > ‑ - ----------------------------------------------------------------------------------------------- - -> ![](media/picture109.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **3.1.8  Requirements** -> -> **3.1.8.1  Layout** -> -> Home  Screen  must  provide  a  mechanism  for  customizable  GUI  layout  definition  by  each  vehicle -> -> type,  each  destination  and  each  grade. -> -> Home  Screen  must  provide  a  mechanism  for  a  customizable  GUI  layout  definition  for  different -> -> vehicle  type,  destination  and  grade. -> -> GUI  layout  definitioncan  be  definedsuch  as  the  following  items: -> -> (In  addition,  items  that  can  be  defined  is  not  limited  to  the  following.) -> -> · screen  resource  (Display,  Layer  Type,  Area) -> -> Page  16  of  159 -> -> ![](media/picture110.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · sound  resource  (Zone,  Sound  Type) -> -> · input  resource  (Device,  Event  Type) -> -> · UI  Component  to  be  used  in  the  entire  system -> -> · transition  effect  (Animation  effect) -> -> · Background  image -> -> Home  Screen  must  provide  a  mechanism  to  apply  customized  GUI  layout  definition. -> -> **3.1.8.2  System  UI  Parts** -> -> Home  Screen  must  provide  a  mechanism  to  display  two  or  more  information  simultaneously  to -> -> the  status  notification  area. -> -> Home  Screen  must  provide  a  mechanism  to  displaying  status  to  status  notification  area. -> -> · Current  Time:  Displaying  clock  capability -> -> · -> Icons  of  Status:  Displaying  icons  for  notify  information  from  applications -> -> · -> Status  Message:  Displaying  text  for  notify  information  from  applications -> -> · -> Communication  Status:  Status  of  mobile  communication  and  wireless  communications -> -> (Wi-Fi,  Bluetooth,  etc.) -> -> Home  screen  must  provide  an  interface  to  retrieve  information  from  application  for  notification. -> -> Home  Screen  must  provide  a  mechanism  to  show  popup  window  into  on-screen  window. -> -> Home  Screen  must  provide  GUI  method  to  hide  on-screen  window  by  user  operation. -> -> Home  Screen  must  provide  a  mechanism  to  hide  on-screen  window  within  a  specified  duration. -> -> Home  Screen  must  provide  an  interface  for  applications  to  request  to  show  popups. -> -> Home  Screen  must  provide  an  interface  for  applications  to  cancel  the  previously  requested -> -> popup. -> -> Page  17  of  159 -> -> ![](media/picture111.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Home  Screen  must  provide  a  mechanism  to  show  text  information,  draw  images  and  show -> -> software  switch  like  button  in  the  on-screen  window. -> -> Home  Screen  must  provide  a  mechanism  to  specify  attributes  such  as  position  and  size  of  On- -> -> screen  window. -> -> Home  Screen  must  support  a  mechanism  to  specify  other  window  display  effect  when  the  On- -> -> screen  window  is  displayed.  (e.g.  tone  down) -> -> Home  Screen  must  provide  system  setting  menu  regarding  GUI,  such  as  locale  and  network. -> -> Home  Screen  must  provide  a  mechanism  to  change  current  date  and  time  setting. -> -> Home  Screen  must  provide  a  mechanism  to  change  timezone  setting. -> -> · -> The  platform  must  set  up  the  date,  time  and  timezone  according  to  a  current  position -> -> automatically. -> -> · -> Home  Screen  must  provide  a  mechanism  to  set  up  turning  on  and  off  of  the  automatic -> -> date/time/timezone  setup. -> -> Home  Screen  must  provide  a  mechanism  to  change  language  setting. -> -> Home  Screen  must  provide  a  mechanism  to  change  wireless  communications  (Wi-Fi,  Bluetooth, -> -> etc.)  setting. -> -> · Enable/Disable -> -> · Connect/Disconnect -> -> · Search  the  devices -> -> · Display  the  list  of  available  and/or  registered  devices -> -> Home  Screen  must  provide  a  mechanism  to  change  mobile  communication  setting. -> -> · Enable/Disable -> -> Page  18  of  159 -> -> ![](media/picture112.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · A  setup  and  change  of  various  attributes -> -> · Display  the  list  of  registered  devices  and  select  device -> -> HomeScreen  must  support  to  change  the  appearance  of  a  screen  to  a  user's  liking. -> -> These  are  as  follows. -> -> · Tone  of  a  screen. -> -> · Appearance  of  a  window  frame. -> -> · Animation  effect  when  screen  transition  was  occurred. -> -> Home  Screen  must  support  a  mechanism  to  set  or  change  master  audio  volume. -> -> Home  Screen  must  support  a  mechanism  to  set  or  change  display  brightness. -> -> Home  Screen  must  provide  a  mechanism  to  show  software  keyboard. -> -> Home  Screen  must  provide  a  mechanism  to  apply  default  settings  (e.g.  theme,  local,  wallpaper) -> -> to  a  new  user,  when  a  user  is  added  by  the  User  Manager. -> -> **3.1.8.3  Application  Management** -> -> Home  Screen  must  provide  a  mechanism  to  manage  downloaded  application  package. -> -> · Display  downloaded  application  list  from  application  store. -> -> · Download  the  application -> -> · Install  the  downloaded  application -> -> · Uninstall  the  downloaded  application -> -> · Update  the  downloaded  application -> -> Home  Screen  must  provide  a  mechanism  to  launch  the  application. -> -> Home  Screen  must  provide  a  mechanism  to  terminate  the  application. -> -> Page  19  of  159 -> -> ![](media/picture113.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **3.1.8.4  Application  Switch** -> -> Home  Screen  must  provide  a  mechanism  to  show  the  list  of  installed  applications. -> -> Examples  of  assumed  application  list -> -> · list  of  application  name -> -> · list  of  application’s  icon -> -> · list  of  live  thumbnail  for  all  the  running  applications -> -> Home  Screen  must  provide  a  mechanism  for  switching  display  application  in  order  by  application -> -> history. -> -> Home  Screen  must  provide  a  mechanism  for  the  application  stack  in  any  order.  For  example, -> -> such  as  launch  order  or  display  order. -> -> Home  Screen  must  provide  a  mechanism  for  the  system  to  switch  applications. -> -> For  example,  when  Driving  Mode  changes,  system  must  be  able  to  switch  application  based  on -> -> policy. -> -> **4   Application   Framework   Layer** -> -> The  Application  Framework  layer  provides  the  methods  needed  to  create  software  applications -> -> and  their  user  interfaces.  The  platform  can  support  multiple  application  frameworks  any  of -> -> which  may  be  built  into  an  SDK  or  product  build.  The  application  framework  contains  any  code -> -> specifically  written  for  that  framework  as  well  the  bindings  to  the  Services  and  Operating -> -> Systems  layers  that  the  application  framework  provides  for  its  applications. -> -> 4.1  AGL  Application  Framework -> -> The  AGL  Application  Framework  provides  basic  services  to  all  applications  regardless  of  the -> -> framework  they  are  implemented  in  so  that  there  is  a  standard  method  providing  the  services. -> -> Page  20  of  159 -> -> ![](media/picture114.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **4.1.1  Application  Manager** -> -> Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application -> -> lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. -> -> **4.1.1.1  Requirements** -> -> AGL  System  must  support  application  lifecycle  (install/uninstall,  launch/kill,  suspend/resume)  based  on -> -> appid/pid  via  launcher. -> -> AGL  System  must  support  a  database  to  store  application  metadata  (appid,  exec  path  etc.). -> -> AGL  System  must  provide  an  interface  to  get  a  list  of  installed  applications. -> -> AGL  System  must  provide  an  interface  to  get  the  state  of  an  application. -> -> AGL  System  must  provide  application  privilege  control. -> -> **4.1.2  Window  Manager** -> -> A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user  interface.  A -> -> window  system  is  responsible  for  managing  display  devices,  Graphics  Processing  Units  (GPUs),  input -> -> devices,  and  graphics  memory.  A  window  system  works  with  the  software  component  named  window -> -> manager  that  is  responsible  for  a  layout  management  of  windows,  and  a  routing  of  user  interactions. -> -> A  window  manager  is  as  software  component  that  is  responsible  for  a  layout  management  of -> -> windows. -> -> Window  manager  of  automotive  middleware  layer  makes  up  for  traditional  window  management -> -> system  to  be  satisfied  IVI’s  complex  requirements,  typically  requested  from  Policy  Manager. -> -> Also,  AGL  aims  to  provide  well-portability  among  various  hardware  platforms. -> -> Page  21  of  159 - - -------------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- ----------------------------- -------------------------------------------------------------- - > 1 > Window  drawing > Provide  capability  to  draw  a  window  to  any  place - > - > and  any  size  and  any  scale. - > - > Also  provide  capability  to  change  visibility  of  the - > - > window. - - > 2 > Overlay  of  multiple > Provide  capability  to  overlay  two  or  more  windows - > > - > windows > with  any  z-order. - > - > Also  provide  capability  to  use  hardware  layer - > - > efficiently. - - > 3 > Visual  effect > Provide  capability  to  adapt  visual  effect  as  below. - > - > ·     Animation  effect  to  change  visibility - > - > ·     Animation  effect  to  transit  between  two  or - > - > more  windows - > - > ·     Visual  effect  for  a  window,  such  as  gray-out - > - > and  transparent. - - > 4 > Frame  rate  control > Provide  capability  to  control  dynamic  frame  rate - > - > change.  This  is  useful  if  system  resource  was - > - > shortage. - - > 5 > Multiple  hardware  layer > Provide  capability  to  use  hardware  layer  efficiently - > > - > support > if  hardware  supports  two  or  more  hardware  layers. - -------------------------------------------------------------------------------------------------------- - -> ![](media/picture115.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **4.1.2.1  Use** **Case** -> -> Please  refer  “screen  resource  control”  of  Policy  Manger  section. -> -> **4.1.2.2  Role** -> -> Table  7-148  describes  the  role  of  window  manager  to  be  satisfied  above  purpose  and  use -> -> cases. -> -> Page  22  of  159 - - ---------------------------------------------------------------------------------------------- - > 6 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce - > > - > hardware > dependency  of  hardware.  Well-defined  interface - > - > also  makes  it  possible  to  increase  the  effect  of - > - > portability  and  development  cost. - ----- --------------------------- ------------------------------------------------------------ - > 7 > Multi  window  /  multi > Support  multi  window  management  and  multi - > > - > display > display. - - > 8 > Compatibility > From  the  compatibility  point  of  view,  AGL  should - > - > use  public  API,  and  shall  not  rely  on  hardware - > - > specific  API. - ---------------------------------------------------------------------------------------------- - -> ![](media/picture116.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **4.1.2.3  Requirements** -> -> 4.1.2.3.1  Window  Drawing -> -> System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and -> -> make  invisible. -> -> System  must  provide  a  mechanism  to  create  and  delete  surface. -> -> When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. -> -> This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. -> -> System  must  provide  a  mechanism  to  change  visibility  per  each  surface. -> -> And,  provide  an  interface  to  change  visibility. -> -> All  the  surfaces  must  be  set  to  invisible  for  initial  state. -> -> Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. -> -> System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between -> -> previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. -> -> *System must provide a mechanism to fit surface into area. Because, size of area may differe*nt -> -> Page  23  of  159 -> -> ![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> from  size  of  surface. -> -> If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. -> -> If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -> -> into  area  by  squeeze. -> -> If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -> -> into  area  by  using  combination  of  scaling  and  trimming  function. -> -> That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -> -> ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. -> -> If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -> -> into  area  by  using  combination  of  scaling  and  background  color. -> -> That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -> -> ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This -> -> mechanism  makes  it  possible  to  do  “letterbox”  method. -> -> 4.1.2.3.2  Overlay  of  Multiple  Windows -> -> System  must  provide  a  mechanism  to  create  and  delete  a  layer. -> -> Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by -> -> their  z-order  attribute. -> -> Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, -> -> then,  attached  layer  must  be  changed. -> -> System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. -> -> Area  is  a  concept  which  defines  where  to  display  in  specific  layer. -> -> System  must  provide  a  mechanism  to  attach  surface  to  any  layer. -> -> Also,  system  must  be  able  to  change  attached  layer. -> -> And,  provide  an  interface  to  attach  and  change. -> -> Page  24  of  159 -> -> ![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. -> -> And,  provide  an  interface  to  assign  surface  to  any  area. -> -> System  must  provide  a  mechanism  to  change  visibility  per  each  layer. -> -> That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the -> -> same  time. -> -> And,  provide  an  interface  to  change  visibility  per  layer. -> -> Initial  state  must  be  set  to  invisible. -> -> System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each -> -> layer,  and  disposition  of  surfaces. -> -> 4.1.2.3.3  Visual  Affect -> -> System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was -> -> happened. -> -> Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -> -> - Duration -> -> Animation  type -> -> System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -> -> out. -> -> Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -> -> plug-in  architecture. -> -> System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. -> -> Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -> -> · Duration -> -> Animation  type -> -> System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -> -> Page  25  of  159 -> -> ![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> out. -> -> Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -> -> plug-in  architecture. -> -> System  must  provide  a  mechanism  to  make  effect  to  surface. -> -> And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. -> -> System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. -> -> System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness -> -> System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in -> -> architecture. -> -> 4.1.2.3.4  Frame  Rate  Control -> -> System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of -> -> application. -> -> System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval -> -> of  application. -> -> This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live -> -> thumbnail  and  moving  surface. -> -> 4.1.2.3.5  Multiple  Hardware  Layer  Support -> -> If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use -> -> hardware  layers  efficiently. -> -> · -> Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers -> -> Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback -> -> 4.1.2.3.6  Reduced  Dependency  of  Hardware -> -> Page  26  of  159 -> -> ![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of -> -> each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, -> -> such  as  by  using  re-configuration. -> -> 4.1.2.3.7  Multi  Window -> -> AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple -> -> processes  on  a  display. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. -> -> 4.1.2.3.8  Compatibility -> -> AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -> -> APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -> -> AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a -> -> standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any -> -> hardware  specific  API. -> -> A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. -> -> **4.1.3  Policy  Manager** -> -> **4.1.3.1  Overview** -> -> 4.1.3.1.1  Purpose -> -> Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy -> -> Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle -> -> Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of -> -> resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called -> -> Page  27  of  159 -> -> ![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> “System  resources”  such  as  CPU  and  memory. -> -> 4.1.3.1.2  GUI  Resources -> -> (1)  Definition -> -> ·  About  Control  of  GUI  Resources -> -> AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, -> -> speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user -> -> or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. -> -> **Figure  7-1:  GUI  resources** -> -> Page  28  of  159 -> -> ![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy -> -> Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too -> -> much  information  distracts  the  attention  of  driver  from  driving  operations. -> -> ·  Associated  Software  Architecture -> -> The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources -> -> control  is  as  below. -> -> **Figure  7-2:  Associated  Software  Expected  Use  Case** -> -> Page  29  of  159 - - ----------------------------------------------------------------------------------------------------------------------------------------------------- - > **No** > **Component** > **Description** - > - > **.** - ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- - > 1 > Homescreen > Request  to  control  of  GUI  resources. - - > 2 > Applications > Request  to  output  or  input  of  GUI  resources. - - > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And - > - > then  provide  the  corresponding  feature  to - > - > applications  UI  such  as  input  limitation  and - > - > changing  the  theme. - - > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the - > - > definition  of  GUI  resources  such  as  role  by - > - > application  configurations. - - > 5- > Vehicle > Window  Manager - > > - > 1 > Info - > - > Control - - > 5- > Sound  Manager - > - > 2 - - > 5- > Input  Manager - > - > 3 - - > 5- > Vehicle  Info  Distributor - > - > 4 - - > 5- > User  Manager - > - > 5 - ----------------------------------------------------------------------------------------------------------------------------------------------------- - -> ![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Policy  Manager  is  related  with  the  below  components. -> -> (2)  Role -> -> Page  30  of  159 - - ----------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ------------------------------ ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of - > > - > GUI  resource > GUI  resources. - > - > (2)  Judgment  the  GUI  resource  owner  according  to - > - > external  conditions. - - > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to - > - > judgment. - > - > (2)  Notify  the  driving  mode  and  day  night  mode - > - > that  is  calculated  by  external  conditions. - ----------------------------------------------------------------------------------------------------- - -> ![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Policy  Manager  has  the  below  role. -> -> Page  31  of  159 -> -> ![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **Figure  7-3:  Definition  of  Role** -> -> GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each -> -> resource  type  are  as  follows: -> -> a.  Screen  Resource -> -> a-1.  External  Condition  Collection -> -> Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. -> -> **Figure  7-4:  Definition  of  screen  resource** -> -> •  Concept  of  Display,  Layer,  Layout  and  Area -> -> AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one -> -> or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout -> -> Page  32  of  159 -> -> ![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics -> -> window. -> -> The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on -> -> objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was -> -> used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than -> -> layer-2. -> -> Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, -> -> application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. -> -> “Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and -> -> setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert -> -> and  enlarged  view. -> -> When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On -> -> the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” -> -> layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. -> -> From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- -> -> order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered -> -> by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to -> -> individual  layer. -> -> •  Concept  of  Layer  Owner,  Role  and  Surface -> -> “Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of -> -> that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of -> -> area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy -> -> Manager. -> -> “Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” -> -> change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. -> -> One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics -> -> window  to  display  into  one  area. -> -> Page  33  of  159 -> -> ![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface -> -> drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example -> -> to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then -> -> corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface -> -> is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & -> -> scan”. -> -> **Figure  7-5:  Definition  of  Surface** -> -> •  Subdivision  of  “Interrupt”  Layer -> -> Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main -> -> surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main -> -> surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding -> -> “Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message -> -> is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. -> -> According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described -> -> as  Table  7-3. -> -> Page  34  of  159 - - --------------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- -------------------------------------------------------- ----------------------- - > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation - > - > application  requests  this  layer  at  first  time. - - > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of - > - > navigation - - > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message - > > - > screen  service  (e.g.  Homescreen)  requests > popup - > - > this  layer. - - > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard - > > - > keyboard > Typically,  software  keyboard  service - > - > requests  this  layer. - --------------------------------------------------------------------------------------------------------- - - ------------------------------------------------------------------------------------------------------ - > **No** > **Contents** > **Summary** > **Example** - ---------- ---------------- ------------------------------------------------------- ------------------ - > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation - > - > service)  role. - - > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view - ------------------------------------------------------------------------------------------------------ - -> ![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> a-2.  Judgment  of  Priority  of  GUI  Resource -> -> Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role -> -> is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy -> -> Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. -> -> Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software -> -> Page  35  of  159 -> -> ![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is -> -> popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). -> -> **Figure  7-6:  Definition  of  Role  and  Sub  role** -> -> The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display -> -> has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. -> -> In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" -> -> layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub -> -> role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” -> -> role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. -> -> a-3.  GUI  resource  control -> -> Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only -> -> issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -> -> directly. -> -> Page  36  of  159 -> -> ![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> There  are  three  types  of  screen  resource  control: -> -> One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. -> -> Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was -> -> assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. -> -> Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue -> -> z-order  information  for  each  layer. -> -> b.  Sound  Resource -> -> b-1.  External  Condition  Collection -> -> Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. -> -> **Figure  7-7:  Definition  of  Sound  Resource** -> -> •  Zone -> -> Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can -> -> play  at  the  same  time. -> -> Page  37  of  159 - - ------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- ---------------------------------------------- ------------------------- - > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media - > - > player - - > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of - > - > Navigation - - > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound - > - > requests  this  type. - ------------------------------------------------------------------------------------------------- - -> ![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> •  Sound  type -> -> Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource -> -> owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper -> -> sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific -> -> zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each -> -> sound  stream  must  assign  to  individual  sound  type. -> -> AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. -> -> •  Stream -> -> Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in -> -> stream. -> -> b-2.  Judgment  of  Priority  of  GUI  resource -> -> Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role -> -> is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy -> -> Manager.  Figure  7-8  describes  the  definition  of  role. -> -> Page  38  of  159 -> -> ![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **Figure  7-8:  Sample  Role** -> -> The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that -> -> is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or -> -> different  sound  type  are  not  switched.  They  are  mixed. -> -> b-3.  GUI  Resource  Control -> -> Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only -> -> issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -> -> directly. -> -> There  are  two  types  of  sound  resource  control: -> -> One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for -> -> sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound -> -> Page  39  of  159 -> -> ![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> stream  and  to  start  play  latest  area  owner. -> -> Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback -> -> simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy -> -> Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and -> -> music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music -> -> playback. -> -> c.  Input  Resource -> -> c-1.  External  Condition  Collection -> -> Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. -> -> **Figure  7-9:  Definition  of  Input  Resource** -> -> •  Device  Name -> -> Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. -> -> •  Event  Type -> -> Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and -> -> temperatures. -> -> c-2.  Judgment  of  Priority  of  GUI  resource -> -> Page  40  of  159 -> -> ![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device -> -> name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy -> -> DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the -> -> judgment  as  below. -> -> **Figure  7-10:  Definition  of  routing  rule** -> -> OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. -> -> c-3.  GUI  Resource  Control -> -> Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only -> -> issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. -> -> Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. -> -> 4.1.3.1.3  System  Resources -> -> (1)  Definition -> -> Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy -> -> Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. -> -> Page  41  of  159 - - ---------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ----------------------------- ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according - > - > to  external  condition  change. - > - > 2.  Kill  process(s)  forcibly  according  to  external - > - > condition  change. - ---------------------------------------------------------------------------------------------------- - -> ![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, -> -> target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. -> -> **4.1.3.2  Requirements** -> -> 4.1.3.2.1  Screen  Resource -> -> (1)  External  Condition  Collection -> -> System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -> -> owner. -> -> System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system -> -> uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive -> -> information  must  include  as  follows. -> -> a.  ID -> -> b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) -> -> c.  DPI -> -> d.  Connected  ECU -> -> Page  42  of  159 -> -> ![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be -> -> able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list -> -> according  to  current  layout  of  each  display. -> -> The  receive  definition  must  include  the  follows. -> -> a.  ID -> -> b.  Area  list -> -> System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface -> -> by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the -> -> device. -> -> The  receive  request  must  include  the  follows. -> -> a.  Layout  ID -> -> b.  ID -> -> c.  Area  position  (Coordinate  of  the  upper-left) -> -> d.  Area  size  (Length  \*  Width) -> -> System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify -> -> the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. -> -> a.  Display  ID -> -> b.  Layout  ID -> -> System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the -> -> providing  resource  using  it  when  the  request  is  collision. -> -> The  receive  information  must  include  the  follows. -> -> a.  Role -> -> b.  Priority -> -> System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge -> -> driving  mode. -> -> The  receive  information  must  include  the  follows. -> -> a.  Velocity -> -> Page  43  of  159 -> -> ![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> b.  Brake  status -> -> System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge -> -> day  night  mode. -> -> The  receive  information  should  include  the  follows. -> -> a.  The  brightness  of  the  interior -> -> System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the -> -> providing  resource  using  it. -> -> System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should -> -> judge  the  providing  resource  using  it. -> -> (2)  Judgment  of  Priority  of  GUI  Resource -> -> System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -> -> according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -> -> System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical -> -> resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the -> -> resource. -> -> The  receive  request  must  include  as  follows. -> -> a.  Role -> -> b.  Layer  type -> -> The  receive  request  should  include  as  follows. -> -> c.  Display  ID -> -> System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by -> -> priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on -> -> the  specified  area  on  the  specified  layer. -> -> The  receive  request  must  include  as  follows. -> -> a.  Role -> -> Page  44  of  159 -> -> ![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> b.  Layer  ID -> -> The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. -> -> Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the -> -> related  basic  type  area. -> -> c.  Area  ID -> -> **Figure  7-11:  Sequence  to  display** -> -> System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. -> -> In  this  request,  requester  should  choose  below  options. -> -> a. -> Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, -> -> but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should -> -> be  refused. -> -> b. -> Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen -> -> resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher -> -> priority,  then,  only  screen  resource  should  be  assigned  to  requester. -> -> Page  45  of  159 -> -> ![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -> -> release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system -> -> running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. -> -> The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal -> -> request. -> -> a.  Effective  period  (Can  set  unlimited) -> -> System  should  not  raise  the  other  surface  above  its  during  effective  period. -> -> System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -> -> a.  The  effect  at  the  transition -> -> b.  The  effect  of  display  surface -> -> System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are -> -> sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all -> -> layers  will  be  superimposed  by  z-order. -> -> System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. -> -> System  must  hide  the  surface  that  has  too  much  information. -> -> (3)  GUI  Resource  Control -> -> System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -> -> System  must  provide  a  mechanism  to  issue  the  following  resource  control. -> -> a.  Visible  /  Invisible -> -> b.  Change  position -> -> c.  Raise -> -> The  receive  request  must  include  as  follows. -> -> i.  Surface  ID  \*Only  case  of  visible. -> -> ii.  Display  ID  \*Only  case  of  visible. -> -> iii.  Layer  ID  \*Only  case  of  visible. -> -> Page  46  of  159 -> -> ![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. -> -> v.  Size  (Length  \*  Width)  \*Only  case  of  visible. -> -> System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. -> -> a.  The  effect  at  the  transition -> -> b.  The  effect  of  display  surface -> -> 4.1.3.2.2  Sound  Resource -> -> (1)  External  Condition  Collection -> -> System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -> -> owner. -> -> System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone -> -> information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as -> -> follows. -> -> a.  ID -> -> b.  Sound  device  ID -> -> System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses -> -> sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must -> -> include  as  follows. -> -> a.  ID -> -> (2)  Judgment  of  Priority  of  GUI  resource -> -> System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -> -> according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -> -> System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -> -> request  during  system  running. -> -> Page  47  of  159 -> -> ![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> The  receive  request  must  include  as  follows. -> -> a.  Role -> -> b.  Zone  ID -> -> c.  Sound  type  ID -> -> System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -> -> release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during -> -> system  running. -> -> The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal -> -> request. -> -> a.  Effective  period  (Can  set  unlimited) -> -> System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner -> -> by  other  request  on  same  area  during  effective  period. -> -> System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -> -> a.  The  effect  at  the  transition -> -> b.  The  effect  of  output  sound -> -> System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more -> -> resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority -> -> of  resources  that  is  related  to  role. -> -> \*  Boundary  of  the  role  between  Policy  Manager  and  application. -> -> Page  48  of  159 -> -> ![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Figure  7-12:  Boundary  of  role  (Case  of  reverse) -> -> System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system -> -> should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. -> -> For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound -> -> from  request  history  based  on  the  priority. -> -> (3)  GUI  Resource  Control -> -> System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -> -> System  must  provide  a  mechanism  to  issue  the  following  resource  control. -> -> a.  Mute  /  Unmute -> -> b.  Change  zone -> -> The  receive  request  must  include  as  follows. -> -> i.  Stream  ID -> -> ii.  Device -> -> In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. -> -> iii.  Channel  ID -> -> Page  49  of  159 -> -> ![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. -> -> a.  The  effect  at  the  transition -> -> b.  The  effect  of  output  sound -> -> 4.1.3.2.3  Input  Resource -> -> (1)  External  Condition  Collection -> -> System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -> -> owner. -> -> System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses -> -> input  device  information  with  to  control  input  event  to  other  system.  The  receive  information -> -> must  include  as  follows. -> -> a.  ID -> -> System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses -> -> input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must -> -> include  as  follows. -> -> a.  ID -> -> b.  Related  event  IDs -> -> (2)  Judgment  of  Priority  of  GUI  resource -> -> System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -> -> according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -> -> System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -> -> request  during  system  running. -> -> The  receive  request  must  include  as  follows. -> -> a.  Input  device  ID -> -> Page  50  of  159 -> -> ![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> b.  Event  type  ID -> -> System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the -> -> limitation  routing  rule  of  policy  DB. -> -> (3)  GUI  Resource  Control -> -> System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -> -> System  must  provide  a  mechanism  to  issue  the  following  resource  control. -> -> a.  Set  the  routing  rule -> -> The  receive  request  must  include  as  follows. -> -> i.  Input  device  ID -> -> ii.  Event  type  ID -> -> The  receive  request  must  include  either  as  follows. -> -> iii.  The  allowed  application -> -> iv.  The  denied  application -> -> System  should  provide  a  mechanism  to  set  the  following  information. -> -> a.  Application  that  has  active  surface -> -> System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This -> -> feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen -> -> changes  the  active  surface. -> -> 4.1.3.2.4  System  Resources -> -> (1)  External  Condition  Collection -> -> System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager -> -> to  decide  proper  system  resource. -> -> Page  51  of  159 -> -> ![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Policy  Manager  must  detect  creation  and  deletion  of  process. -> -> To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created -> -> process. -> -> Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to -> -> other  active  processes. -> -> To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to -> -> identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each -> -> active  process. -> -> Policy  Manager  must  detect  current  memory  consumption  periodically. -> -> To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each -> -> process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were -> -> thought  as  not  so  important  process. -> -> Policy  Manager  must  detect  current  CPU  consumption  periodically. -> -> To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep -> -> system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected -> -> busy  state. -> -> System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. -> -> Application  status  includes  as  below. -> -> · GUI  resource  status,  such  as  foreground  or  background. -> -> · -> Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must -> -> resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last -> -> application  to  resume  quickly  as  much  as  possible. -> -> (2)  System  Resource  Control -> -> System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process -> -> group  according  to  external  conditions. -> -> According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to -> -> target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups -> -> Page  52  of  159 -> -> ![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> will  be  used) -> -> System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. -> -> 4.1.3.2.5  Resource  Management -> -> Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy -> -> Manager,  Connection  Manager. -> -> Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. -> -> Each  resource  request  shall  be  in  form  a: -> -> AppID, -> -> SourceID, -> -> RequestorZoneID, -> -> NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), -> -> Required  Resource  List. -> -> Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin -> -> Speakers,  HeadPhones) -> -> Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) -> -> Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, -> -> Tuners  etc.) -> -> Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request -> -> from  resource  requestors. -> -> Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. -> -> Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) -> -> Page  53  of  159 -> -> ![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list -> -> are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) -> -> Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system -> -> through  status  update. -> -> Resource  Management  shall  support  stacking/queuing  of  resource  requests. -> -> >  Receive  the  requests  from  the  resource  requestors. -> -> >  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy -> -> Manager. -> -> >  Add  the  validated  requests  into  a  priority  queue. -> -> >  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. -> -> >  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it -> -> shall  be  removed  from  the  queue. -> -> Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier -> -> request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it -> -> shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. -> -> If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the -> -> requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. -> -> If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant -> -> some/all  of  the  resources  requested  by  the  requestor. -> -> Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an -> -> existing  resource  request. -> -> Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of -> -> policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs -> -> for  the  policy  decision: -> -> >  Currently  Free  or  InUse  Sink  status -> -> >  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) -> -> Page  54  of  159 -> -> ![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> >  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. -> -> Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a -> -> request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the -> -> policy  decision: -> -> >  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept -> -> pending. -> -> >  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. -> -> At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by -> -> resource  requestor: -> -> >  Zone  ID -> -> >  Allocated  Source  Instance -> -> >  Allocated  Sink  Instance -> -> >  Mute  status -> -> Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality -> -> (e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to -> -> the  resource  management  policy. -> -> Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature -> -> functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). -> -> Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: -> -> AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have -> -> same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, -> -> the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. -> -> Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, -> -> AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource -> -> request  will  be  the  one  that  is  granted  the  resource. -> -> A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. -> -> It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. -> -> Page  55  of  159 -> -> ![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. -> -> It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource -> -> Manager  if  the  resource  is  no  longer  needed. -> -> Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all -> -> available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once -> -> the  request  is  granted  against  the  set  policy. -> -> Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. -> -> Possible  connection  states  are  Active  or  Passive. -> -> >  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be -> -> active. -> -> Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. -> -> >  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be -> -> passive. -> -> Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same -> -> AMFM  source  on  Rear  headphone  sink. -> -> Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink -> -> connection  using  the  underlying  platform  support. -> -> Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink -> -> connection  using  the  underlying  platform  support. -> -> Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is -> -> removed/released. -> -> Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is -> -> re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. -> -> Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. -> -> Page  56  of  159 -> -> ![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready -> -> to  be  used  for  audio  routing. -> -> Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio -> -> routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. -> -> Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. -> -> Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which -> -> source  instance. -> -> Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: -> -> >  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. -> -> System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -> -> are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -> -> 1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -> -> The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -> -> Headphones  shall  not  be  required  to  support  any  foreground  sinks. -> -> In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a -> -> source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source -> -> (if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). -> -> As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not -> -> disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background -> -> connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. -> -> It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -> -> It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. -> -> Page  57  of  159 -> -> ![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State -> -> Manager. -> -> It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. -> -> It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -> -> It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -> -> It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -> -> It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on -> -> current  system  scenario. -> -> E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call -> -> is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a -> -> pending  request. -> -> It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. -> -> It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. -> -> It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video -> -> resources  and  update  its  internal  status  accordingly. -> -> On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active -> -> connections  and  reconnect  or  disconnect  if  required. -> -> E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. -> -> Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of -> -> connections  shall  be  rebuilt  with  Amp. -> -> It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. -> -> Page  58  of  159 -> -> ![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying -> -> platform  support. -> -> It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the -> -> underlying  platform  support. -> -> It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. -> -> It  shall  provide  an  interface  to  unmute  an  audio  sink. -> -> System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -> -> are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -> -> 1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -> -> The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -> -> It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -> -> Headphones  shall  not  be  required  to  support  any  foreground  sinks. -> -> It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -> -> It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -> -> It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -> -> **4.1.4  Sound  Manager** -> -> A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from -> -> two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a -> -> policy  manager  manages  a  mediation  rule. -> -> Page  59  of  159 - - ---------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ------------------------------------------------------------ - > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). - - > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume - > - > control  of  each  sound  streams. - - > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, - > - > ·     When  changing  sound  stream.  E.g.  fade-in, - > - > fade-out  and  cross-fade. - - > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce - > > - > hardware > dependency  of  hardware.  Well-defined  interface - > - > also  makes  it  possible  to  increase  the  effect  of - > - > portability  and  development  cost. - ---------------------------------------------------------------------------------------------------- - -> ![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a -> -> passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound -> -> resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. -> -> Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like -> -> volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server -> -> to  implement  automatic  audio  policies. -> -> **4.1.4.1  Use  Case** -> -> Please  refer  “sound  resource  control”  of  Policy  Manger  section. -> -> Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. -> -> **4.1.4.2  Requirements** -> -> Page  60  of  159 -> -> ![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 4.1.4.2.1  Routing  Sound  Streams -> -> System  must  provide  a  mechanism  to  manage  sound  “zone”. -> -> Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a -> -> zone  and  how  to  manage  zone. -> -> System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each -> -> channels  of  each  sound  device. -> -> One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists -> -> of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. -> -> For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is -> -> arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when -> -> outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower -> -> musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than -> -> music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound -> -> device. -> -> The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more -> -> zones. -> -> Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the -> -> present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the -> -> mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. -> -> System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. -> -> System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. -> -> All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. -> -> System  must  provide  a  mechanism  to  control  sound  stream. -> -> Control  of  a  sound  stream  is  as  follows. -> -> · -> Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound -> -> stream. -> -> · -> Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound -> -> Page  61  of  159 -> -> ![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> stream. -> -> Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. -> -> 4.1.4.2.2  Mixing  Level  Control -> -> The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to -> -> the  same  zone  according  to  a  policy  manager's  arbitration. -> -> System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. -> -> System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream -> -> requested  to  play  into  same  sound  zone. -> -> In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating -> -> the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. -> -> System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested -> -> to  play  into  same  sound  zone. -> -> In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted -> -> sound  stream  was  ended. -> -> System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream -> -> requested  to  play  into  same  sound  zone. -> -> In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound -> -> stream  was  ended. -> -> 4.1.4.2.3  Sound  Effect -> -> When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. -> -> System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. -> -> System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin -> -> architecture. -> -> Page  62  of  159 - - ------------------------------------------------------------------------------------------------------------------------- - > **No.** > **Input  type** > **Associated  device** > **Description** - ----------- ------------------- -------------------------- -------------------------------------------------------------- - > 1 > Key > Steering  switch > Simple  key  event. - > - > Deliver  to  application. - - > 2 > Keyboard > Virtual  keyboard > Keyboard  event. - > - > Deliver     to     application,     then     use     input - > - > method  backend  if  needed. - - > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. - > - > Also  supports  double  click  and  multi-touch - > - > capability. - > - > Deliver  to  application. - - > 4 > Sound > Microphone > Sound  input. - ------------------------------------------------------------------------------------------------------------------------- - -> ![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 4.1.4.2.4  Reduced  Dependency  of  Hardware -> -> Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels -> -> of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means -> -> which  does  not  need  rebuild  of  systems,  such  as  a  configuration. -> -> **4.1.5  Input  Manager** -> -> The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application -> -> depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each -> -> input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering -> -> switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. -> -> **4.1.5.1  Use  Case** -> -> Please  refer  “input  resource  control”  of  Policy  Manger  section. - - --------------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ----------------------------------------------------------------- - > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to - > - > application  readable  event  name,  such  as  “volume - > - > up”  and  “right  arrow”. - - > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified - > - > application. - --------------------------------------------------------------------------------------------------------- - -> ![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Deliver  to  application  or  voice  recognition -> -> engine. -> -> Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. -> -> **4.1.5.2  Requirements** -> -> **4.1.5.3  Abstract  Device  Event** -> -> System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. -> -> Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional -> -> equipment. -> -> **4.1.5.4  Event  Delivery** -> -> System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. -> -> System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” -> -> and  “destination  application  id”. -> -> Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by -> -> UIM.2.1.2. -> -> Page  64  of  159 -> -> ![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. -> -> System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. -> -> System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on -> -> delivery  rule  defined  in  UIM.2.1.1. -> -> System  must  provide  a  mechanism  to  inhibit  any  event  delivery. -> -> This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. -> -> **4.1.6  User  Manager** -> -> **4.1.6.1  Use  Case** -> -> **4.1.6.2  Personal  Identification** -> -> User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a -> -> person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. -> -> **4.1.6.3  User  Preference** -> -> Multi-user  environment  provides  same  user  experience  for  each  user. -> -> Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including -> -> other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data -> -> sharing  from  your  home  and  your  office. -> -> Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be -> -> provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. -> -> Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user -> -> experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, -> -> *but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is -> -> Page  65  of  159 -> -> ![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. -> -> **Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** -> -> **4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** -> -> When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If -> -> Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is -> -> important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s -> -> preference. -> -> **Figure  7-25  :  User  data  sharing  between  cars** -> -> Page  66  of  159 -> -> ![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **4.1.6.5  Seamless  Data  Sharing** -> -> Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and -> -> smart-phones,  home  networks  and  accessing  from  your  offices. -> -> **Figure  7-26  :  User  data  sharing  over  the  cars** -> -> **4.1.6.6  Role** -> -> **Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above -> -> purpose  and  use  cases. -> -> **Table  7-17  :  Role  of  User  Manager** -> -> **No.** **Role** **Description** -> -> Page  67  of  159 -> -> ![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 1 User  identification -> Provide  a  mechanism  to  identify  user,  such  as  user -> -> name  and  password  pair,  smart  key  and  biometrics. -> -> Provide  a  mechanism  to  log-in  to  the  IVI  system  as -> -> a  specified  user. -> -> When a different user logs in, proper user -> -> preference  for  the  user  must  be  applied,  and -> -> resume  last  state  of  corresponding  user. -> -> Also,  each  application  can  store  application’s  data -> -> per  user.  In  such  cases,  proper  user  data  must  be -> -> applied  when  a  different  user  logs  in. -> -> 2 User  preference -> Provide  a  mechanism  to  apply  user  preference  of -> -> logged-in  user. -> -> User  preference  includes  the  following  data. -> -> · User  interface,  such  as  locale  and  wall- -> -> paper. -> -> · Resume  last  application’s  status  of  specified -> -> user. -> -> · Application  specific  data. -> -> 3 User  data  management -> Provide  a  mechanism  to  manage  cloud  based  user -> -> data. -> -> The  following  capabilities  are  required. -> -> · Download  user  data  of  the  logged-in  user -> -> from  the  cloud. -> -> · Update  cloud  data  if  the  user  data  was -> -> updated  by  user  operation  or  otherwise. -> -> · Periodically  sync-up  w/  cloud  because  user -> -> data  may  be  updated  by  other  devices. -> -> In  addition  to  the  above  basic  capabilities,  user  data -> -> cache  is  essential  for  a  car,  since  a  car  may  not -> -> always  have  a  reliable  network  connection. -> -> 4 Security Because  cloud  based  sharing  user  data  may  be -> -> accessed  from  any  place,  user  data  must  be -> -> protected  from  unexpected  data  access. -> -> Page  68  of  159 -> -> ![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> So,  IVI  system  must  provide  security  mechanism -> -> regarding  accessing  to  cloud  based  user  data. -> -> **4.1.6.7  Requirements** -> -> 4.1.6.7.1  User  Identification -> -> System  must  provide  a  mechanism  to  identify  logged-in  user. -> -> System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to -> -> identify  logged-in  user. -> -> System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For -> -> example,  using  NFC. -> -> System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. -> -> 4.1.6.7.2  User  Preference -> -> When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the -> -> currently  logged-in  user. -> -> System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. -> -> - Locale  settings -> -> - UX  theme -> -> Wall  paper -> -> System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized -> -> user  experience. -> -> Page  69  of  159 -> -> ![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in -> -> user’s  application  data  automatically. -> -> When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last -> -> status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the -> -> system.  Specifically,  last  status  includes  the  following. -> -> - Foreground  applications.  That  means  displayed  applications. -> -> Background  applications. -> -> When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. -> -> System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. -> -> System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. -> -> 4.1.6.7.3  User  Data  Management -> -> System  must  provide  a  mechanism  to  manage  user  data. -> -> AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user -> -> preference. -> -> User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but -> -> also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and -> -> home  electronics. -> -> System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to -> -> application  by  using  cloud  based  user  data. -> -> System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data -> -> of  the  IVI  system. -> -> When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to -> -> the  cloud. -> -> Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide -> -> Page  70  of  159 -> -> ![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. -> -> Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a -> -> mechanism  to  cache  downloaded  user  data. -> -> If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as -> -> possible. -> -> 4.1.6.7.4  Security -> -> Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to -> -> protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. -> -> System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. -> -> - -> System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must -> -> authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, -> -> smartphone  or  PC. -> -> - -> System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. -> -> - -> System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection -> -> against  falsification  of  data  from  unauthorized  access  or  illegal  access. -> -> - -> Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide -> -> user  data  only  to  the  authorized  user. -> -> Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must -> -> provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to -> -> include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against -> -> cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. -> -> 4.2  Web  HMI -> -> Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. -> -> **4.2.1  Web  API** -> -> Page  71  of  159 -> -> ![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service -> -> function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio -> -> visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, -> -> Photo,  etc.) -> -> Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of -> -> Audio  Visual  API  is  shown  in  Figure  6-1. -> -> **Figure  6-1:  Use  case  of  Audio  Visual  API** -> -> **4.2.1.1  Requirements** -> -> Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. -> -> · Select  content  using  URL -> -> · -> Select  content  using  contents  list  provided  by  multimedia  subsystem -> -> Page  72  of  159 -> -> ![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, -> -> DVD,  BT-Audio,  Photo,  etc.) -> -> · Play -> -> · Pause -> -> · Fast-forward -> -> · Rewind -> -> · Track  up -> -> · Track  down -> -> · Select  playmode  (Repeat/Random) -> -> Audio  Visual  API  must  provide  API  to  control  a  volume. -> -> · Volume  up -> -> · Volume  down -> -> · Mute -> -> Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. -> -> Audio  Visual  API  must  provide  API  for  notifications. -> -> · The  case  that  playback  state  is  changed -> -> · The  case  that  Audio  Visual  contents  is  add  /  removed -> -> Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. -> -> · Change  the  frequency. -> -> · Change  the  broadcasting  stations. -> -> · Receive  the  list  of  broadcasting  stations. -> -> · Select  the  preset  channel. -> -> · Get  the  information  of  the  broadcasting  station. -> -> Audio  Visual  API  must  provide  API  to  play  digital  radio. -> -> · Store  the  broadcast  program  information. -> -> Page  73  of  159 -> -> ![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · Get  the  broadcast  program  information. -> -> · Get  the  play  time. -> -> · Play  the  radio  broadcast  cached. -> -> AGL  System  must  support  a  web  API  to  access  Vehicle  information. -> -> AGL  System  must  support  web  API  to  control  STT/TTS  daemon. -> -> AGL  System  must  support  web  API  to  control  navi  engine. -> -> AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web -> -> apps. -> -> AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app -> -> and  a  native  app. -> -> AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider -> -> should  be  able  to  restrict  subscriber. -> -> AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. -> -> AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, -> -> Network  Information -> -> AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG -> -> AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio -> -> AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, -> -> server  sent  events,  session  history  of  browsing  context -> -> *AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL -> -> Page  74  of  159 -> -> ![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 -> -> The  iframe  element,  Content  Security  Policy  1.0. -> -> AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications -> -> AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing -> -> control,  Navigation  timing -> -> AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation -> -> AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, -> -> Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy -> -> AGL  System  must  support  Khronos  WebGL  API. -> -> **4.2.2  Web  Runtime** -> -> The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access -> -> the  AGL  Application  Framework  and  Services. -> -> **4.2.2.1  Requirements** -> -> AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., -> -> installation/removal). -> -> AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, -> -> view  generation,  rendering,  etc.) -> -> AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add -> -> better  device/platform  integration. -> -> Page  75  of  159 -> -> ![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to -> -> categorize  apps  with  different  privileges. -> -> System  must  provide  high  level  GUI  components  for  Web  application. -> -> At  least,  below  components  are  required. -> -> · Text  labels -> -> · Button -> -> · Radio  button -> -> · Check  box -> -> · Tab  panel -> -> · Animation  (e.g.  MNG,  GIF  animation) -> -> · Slider -> -> · Accordion  list -> -> · Anchor -> -> · Text  input  form -> -> · Dropdown  list  box -> -> · Date  picker -> -> 4.3  Native  HMI -> -> The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written -> -> using  Javascript  or  other  web  technologies. -> -> **4.3.1  Native  App  Runtime** -> -> The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to -> -> access  the  AGL  Application  Framework  and  Services. -> -> **4.3.1.1  Requirements** -> -> System  must  provide  high  level  GUI  components  for  native  application. -> -> Page  76  of  159 -> -> ![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> At  least,  below  components  are  required. -> -> · Text  labels -> -> · Button -> -> · Radio  button -> -> · Check  box -> -> · Tab  panel -> -> · Animation  (e.g.  MNG,  GIF  animation) -> -> · Slider -> -> · Accordion  list -> -> · Anchor -> -> · Text  input  form -> -> · Dropdown  list  box -> -> · Date  picker -> -> **4.3.2  Native  Application  Framework** -> -> The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an -> -> SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that -> -> framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the -> -> application  framework  provides  for  its  applications. -> -> **5   Services   Layer** -> -> The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the -> -> services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces -> -> remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime -> -> modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid -> -> unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer -> -> interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces -> -> provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may -> -> choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework -> -> runtime  to  adjust  to  any  new  interfaces, -> -> Page  77  of  159 -> -> ![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1  Platform  Services -> -> Platform  Services  Layer.  Conventional  Linux  platform  services -> -> **5.1.1  Bluetooth** -> -> This  document  describes  requirements  regarding  registration,  (dis)connection  and  device -> -> information  management  between  Bluetooth  device  and  infotainment  system.  Necessary -> -> Bluetooth  profiles  in  automotive  use  case  are  defined  here. -> -> **5.1.1.1  Requirements** -> -> The  Telephony  system  shall  be  designed  to -> -> support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR -> -> without  hardware  upgrade. -> -> A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: -> -> · Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) -> -> · HFP  (Hands  Free  Profile) -> -> · OBEX  (Object  Exchange) -> -> · OPP  (Object  Push  Profile) -> -> · PBAP  (Phonebook  Access  Profile) -> -> · SPP  (Serial  Port  Profile) -> -> · SDAP  (Service  Discovery  Access  Profile) -> -> If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music -> -> from),  the  system  shall  also  support  the  following  incremental  BT  profiles: -> -> · A2DP  (Advanced  Audio  Distribution  Profile) -> -> · AVRCP  (Audio  Visual  Remote  Control  Profile) -> -> The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the -> -> Page  78  of  159 -> -> ![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of -> -> generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in -> -> encryption  key  length  negotiation. -> -> When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as -> -> default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority -> -> scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration -> -> time. -> -> The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is -> -> 10  meters  and  maximum  power  is  2.5  mW  (4  dBm). -> -> The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall -> -> allow  using  five-slot  packet  transmission  for  faster  data  rate. -> -> The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a -> -> standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. -> -> vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are -> -> often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain -> -> name  and  address  information,  phone  numbers,  and  e-mail  addresses. -> -> vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, -> -> LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, -> -> URL,  UID,  Version,  and  KEY  properties. -> -> vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: -> -> MIME  Content-Type  for  Directory  Information -> -> vCard  MIME  Directory  Profile -> -> It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with -> -> the  vCard  version  2.1  properties. -> -> The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any -> -> associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is -> -> not  full. -> -> The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO -> -> Page  79  of  159 - - ------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **Support  in  HF** > **AGL** - ----------- ------------------------------------------------------------- ----------------------- ----------- - > 1 > Connection  management > Mandatory > x - - > 2 > Phone  status  information > Mandatory > x - - > 3 > Audio  Connection  handling > Mandatory > x - - > 4 > Accept  an  incoming  voice  call > Mandatory > x - - > 5 > Reject  an  incoming  voice  call > Mandatory > x - - > 6 > Terminate  a  call > Mandatory > x - - > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x - - > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x - > - > HF - - > 9 > Place  a  call  using  memory  dialing > Option > - - - > 10 > Place  a  call  to  the  last  number  dialed > Option > - - ------------------------------------------------------------------------------------------------------------- - -> ![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> shall  be  used. -> -> 5.1.1.1.1  Hands  Free  Profile -> -> The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile -> -> specification  version  1.6  or  later. -> -> The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, -> -> wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and -> -> output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to -> -> the  actual  phone. -> -> It  shall  provide  following  roles: -> -> Hands-Free  unit  (HF) - - > 11 > Call  waiting  notification > Option > x - ------- ------------------------------------------------------ ---------- ---------- - > 12 > Three  way  calling > Option > x(\*1) - > 13 > Calling  Line  Identification  (CLI) > Option > x - > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x - > 15 > Voice  recognition  activation > Option > x - > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - - > 17 > Ability  to  transmit  DTMF  codes > Option > x - > 18 > Remote  audio  volume  control > Option > - - > 19 > Respond  and  Hold > Option > x - > 20 > Subscriber  Number  Information > Option > x - > 21a > Enhanced  Call  Status > Option > x - > 21b > Enhanced  Call  Controls > Option > - - > 22 > Individual  Indicator  Activation > Option > - - > 23 > Wide  Band  Speech > Option > x - > 24 > Codec  Negotiation > Option > x - -> ![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> \*1:  Does  not  support  Multi-party  (conference)  call -> -> The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the -> -> model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -> -> string  in  a  phone  model  CGMM  variable. -> -> · Phone  Model  CGMM: -> -> · Type:  string -> -> · Max  length:  200  chars -> -> Page  81  of  159 -> -> ![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · Persistence:  No -> -> A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -> -> The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -> -> device. -> -> The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the -> -> Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be -> -> stored  as  a  string  in  a  phone  model  CGMI  variable. -> -> · Phone  Model  CGMI: -> -> · Type:  string -> -> · Max  length:  200  chars -> -> · Persistence:  No -> -> A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -> -> The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -> -> device. -> -> The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the -> -> revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -> -> string  in  a  phone  model  CGMR  property. -> -> · Phone  Model  CGMR: -> -> · Type:  string -> -> · Max  length:  200  chars -> -> · Persistence:  No -> -> A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -> -> The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -> -> device. -> -> 5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) -> -> The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP -> -> specification  version  1.2  or  later. -> -> Page  82  of  159 - - > **No.** > **Codec** > **Support** > **AGL** - ----------- ------------------- --------------- ----------- - > 1 > SBC > Mandatory > x - > 2 > MPEG-1,2  Audio > Option > - - > 3 > MPEG-2,4  AAC > Option > - - > 4 > ATRAC  family > Option > - - - > **No.** > **Feature** > **Support  in  SNK** > **AGL** - ----------- -------------------- ------------------------ ----------- - > 1 > Audio  Streaming > Mandatory > x - -> ![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to -> -> realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. -> -> It  shall  provide  following  roles: -> -> Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from -> -> the  SRC  on  the  same  piconet. -> -> Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. -> -> Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. -> -> Copyright  protection  technology  SCMS-T  should  be  supported. -> -> 5.1.1.1.3  Phone  Book  Access  Profile -> -> Page  83  of  159 -> -> ![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification -> -> version  1.1  or  later. -> -> The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between -> -> devices. -> -> Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The -> -> Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected -> -> device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing -> -> and  copying  contact  information. -> -> It  shall  provide  following  roles: -> -> · Phonebook  Client  Equipment  (PCE) -> -> It  shall  provide  following  types  of  Phonebook  objects: -> -> · The  main  Phonebook  object -> -> · The  Incoming  Call  History  object -> -> · The  Outgoing  Call  History  object -> -> · The  Missed  Call  History  object -> -> · The  Combined  Call  History  object -> -> A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device -> -> automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook -> -> download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: -> -> · Using  PBAP  profile -> -> All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. -> -> SIM)  and  also  any  stored  in  the  BT  device's  memory. -> -> The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the -> -> vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded -> -> from. -> -> 5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile -> -> Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -> -> necessary  lower  layers. -> -> Page  84  of  159 - - > **No.** > **Service** > **Support  in  DT** > **AGL** - ----------- ------------------------------------------- ----------------------- ----------- - > 1 > Data  call  without  audio  feedback > Mandatory > x - > 2 > Data  call  with  audio  feedback > Option > - - > 3 > Fax  services  without  audio  feedback > N/A > - - > 4 > Fax  services  with  audio  feedback > N/A > - - > 5 > Voice  call > N/A > - - > 6 > Incoming  calls > Option > x - > 7 > Outgoing  calls > Mandatory > x - -> ![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” -> -> Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. -> -> 5.1.1.1.5  Object  Push  Profile  (OPP) -> -> Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower -> -> layers. -> -> It  has  to  comply  with  the  specification  for  “Push  Server”. -> -> Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. -> -> **Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** -> -> Page  85  of  159 - - > **No.** > **Feature** > **Support  in  CT** > **AGL** - ----------- -------------------------------------------- ----------------------- ----------- - > 1 > Connection  establishment  for  control > Mandatory > x - > 2 > Release  connection  for  control > Mandatory > x - > 3 > Connection  establishment  for  browsing > C6 > x - - ------------------------------------------------------------------------------------- - > **No** > **Feature** > **Support  in  Push  Server** > **AGL** - > - > **.** - ---------- ---------------------------- --------------------------------- ----------- - > 1 > Object  Push > Mandatory > x - - > 2 > Business  Card  Pull > Option > - - - > 3 > Business  Card  Exchange > Option > - - ------------------------------------------------------------------------------------- - -> ![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) -> -> The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. -> -> The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device -> -> plus  one  remote  control.. -> -> The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL -> -> column  in  Table  25  should  be  supported. -> -> C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional -> -> otherwise -> -> C3:  Mandatory  to  support  at  least  one  Category -> -> C4:  Mandatory  if  Category  2  supported,  excluded  otherwise -> -> C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise -> -> EX:  Excluded -> -> Page  86  of  159 -> -> ![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 4 Release  connection  for  browsing C6 x -> -> 5 AV/C  Info  commands Option x -> -> 6 Category  1:  Player/Recorder C3 x -> -> 7 Category  2:  Monitor/Amplifier C3 - -> -> 8 Category  3:  Tuner C3 - -> -> 9 Category  4:  Menu C3 - -> -> 10 Capabilities Option x -> -> 11 Player  Application  Settings Option x -> -> 12 Metadata  Attributes  for  Current  Media  Item Option x -> -> 13 Notifications C2 x -> -> 14 Continuation C2 x -> -> 15 Basic  Group  Navigation Option x -> -> 16 Absolute  Volume C4 - -> -> 17 Media  Player  Selection Option x -> -> 17.1 -  Supports  Multiple  Players Option x -> -> 18 Browsing Option x -> -> 18.1 -  Database  Aware  Players Option x -> -> 19 Search Option - -> -> 20 Now  Playing C6 x -> -> 20.1 -  Playable  Folders Option x -> -> 21 Error  Response EX - -> -> 22 PASSTHROUGH  operation  supporting  press  and Option x -> -> Page  87  of  159 - - ------------------------------------------------------------------------------ - > **No** > **Feature** > **Support  by  the  MCE** > **AGL** - > - > **.** - ---------- ------------------------- ----------------------------- ----------- - > 1 > Message  Notification > C1 > x - - > 2 > Message  Browsing > C1 > x - - > 3 > Message  Uploading > Option > x - - > 4 > Message  Delete > Option > - - - > 5 > Notification > C2 > x - > - > Registration - ------------------------------------------------------------------------------ - -> ![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> hold -> -> The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and -> -> pass  this  information  up  to  so  it  can  be  passed  to  the  User. -> -> 5.1.1.1.7  Message  Access  Profile -> -> Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary -> -> lower  layers. -> -> It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. -> -> Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. -> -> C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features -> -> C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message -> -> Notification.  Not  applicable  otherwise. -> -> Page  88  of  159 - - > **No.** > **Feature** > **Support  in  PANU** > **AGL** - ----------- ------------------------------------------ ------------------------- ----------- - > 1 > Initialization  of  NAP/GN  service > - > - - > 2 > Shutdown  of  NAP/GN  service > - > - - > 3 > Establish  NAP/GN  service  Connection > Mandatory > x - -> ![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.1.1.8  Serial  Port  Profile  (SPP) -> -> The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version -> -> 1.1  or  later. -> -> It  shall  provide  following  roles: -> -> Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. -> -> Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. -> -> Following  features  shall  be  provided  by  the  Supplier: -> -> Establish  link  and  setup  virtual  serial  connection -> -> Accept  link  and  establish  virtual  serial  connection -> -> Register  Service  record  for  application  in  local  SDP  database -> -> 5.1.1.1.9  Personal  Area  Network  (PAN)  Profile -> -> Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -> -> necessary  lower  layers. -> -> It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. -> -> Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. -> -> Page  89  of  159 - - > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x - ----- ------------------------------------------- ------------- ----- - > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x - > 6 > Management  Information  Base  (MIB) > - > - - -> ![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.1.1.10  Service  Discovery  Profile  (SDP) -> -> The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP -> -> specification  version  1.1. -> -> The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices -> -> in  the  vicinity  of  a  Bluetooth  enabled  device. -> -> It  shall  provide  following  roles: -> -> Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. -> -> Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to -> -> the  service  inquiries  generated  by  Local  Device. -> -> The  following  features  shall  be  provided  by  the  Supplier: -> -> Search  for  services  by  service  class -> -> Search  for  services  by  service  attributes -> -> Service  browsing -> -> 5.1.1.1.11  Device  Information  Profile -> -> Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for -> -> necessary  lower  layers. -> -> Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. -> -> **Table  28  :  List  of  DIP  Supporting  Functions** -> -> Page  90  of  159 - - > **No.** > **Feature** > **Support** > **AGL** - ----------- ----------------------- --------------- ----------- - > 1 > SpecificationID > Mandatory > x - > 2 > VendorID > Mandatory > x - > 3 > ProductID > Mandatory > x - > 4 > Version > Mandatory > x - > 5 > PrimaryRecord > Mandatory > x - > 6 > VendorIDSource > Mandatory > x - > 7 > ClientExecutableURL > - > - - > 8 > ServiceDescription > - > - - > 9 > DocumentationURL > - > - - -> ![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.1.1.12  Bluetooth  Smart  Ready -> -> Bluetooth  Smart  Ready  shall  be  supported. -> -> It  shall  comply  with  Bluetooth  Low  Energy  standard. -> -> 5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) -> -> The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX -> -> specification  version  2.0  or  later. -> -> The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between -> -> devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. -> -> It  shall  provide  following  roles: -> -> Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data -> -> objects  shall  be  pushed  and  pulled,  respectively. -> -> Page  91  of  159 -> -> ![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. -> -> The  following  features  shall  be  provided  by  the  Supplier: -> -> Establishing  an  object  connection -> -> Pushing  a  data  object -> -> Pulling  a  data  object -> -> Performing  an  action  on  data  objects -> -> Creating  and  managing  a  Reliable  Object  Exchange  Connection -> -> 5.1.1.1.14  Generic  Audio/Video  Distribution  Profile -> -> The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the -> -> GAVDP  specification  version  1.2  or  later. -> -> The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between -> -> two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. -> -> It  shall  provide  following  roles: -> -> Initiator  (INT) -> -> Acceptor  (ACP) -> -> Following  are  the  feature  requirements  for  this  profile: -> -> Connection -> -> Transfer  Control -> -> Signalling  Control -> -> Security  Control -> -> Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not -> -> yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. -> -> 5.1.1.1.15  Bluetooth  Diagnostics -> -> **5.1.2  Error  Management** -> -> The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes -> -> Page  92  of  159 -> -> ![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized -> -> restart.  In  addition, -> -> in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery -> -> to  issue  in  a  short  amount  of  time. -> -> **5.1.2.1  Use  Cases** -> -> 5.1.2.1.1  System  Surveillance  and  Recovery -> -> While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an -> -> immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating -> -> the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to -> -> try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating -> -> middle  ware,  reboot  the  whole  system  to  try  and  recover. -> -> There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that -> -> adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The -> -> AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. -> -> The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even -> -> if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be -> -> done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error -> -> Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the -> -> degree  should  be  adjusted  by  its  behavior  status. -> -> 5.1.2.1.2  Collecting  Information -> -> For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt -> -> recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the -> -> cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. -> -> With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On -> -> the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come -> -> Page  93  of  159 -> -> ![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, -> -> the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. -> -> **5.1.2.2  Requirements** -> -> Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its -> -> status  automatically  and  recover -> -> The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each -> -> process. -> -> The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. -> -> When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold -> -> value,  action  is  changeable  by  AGL  user. -> -> Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification -> -> to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are -> -> output  communication  or  disk  I/O. -> -> Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification -> -> by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an -> -> error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication -> -> error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. -> -> Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it -> -> should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination -> -> of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so -> -> those  two  should  be  able  to  set  separately. -> -> Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold -> -> value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be -> -> changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. -> -> Should  be  able  to  vanish  process  forcibly  including  subsidiary  process -> -> Page  94  of  159 -> -> ![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Make  the  software  that  works  by  system  have  the  concept  of  level  importance. -> -> Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be -> -> adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. -> -> The  process  that  detecting  an  external  communication  error  within  the  Error  Management -> -> module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. -> -> The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as -> -> more  than  one  process. -> -> The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple -> -> applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where -> -> multiple  applications  can  be  moved  by  the  same  process. -> -> Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing -> -> process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as -> -> process  crash,  exit,  etc.. -> -> An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends -> -> suddenly  the  other  will  not  become  abnormal  state. -> -> The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other -> -> process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards -> -> external  side. -> -> When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart -> -> additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered -> -> beforehand. -> -> The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file -> -> system  without  destroying  them. -> -> Page  95  of  159 -> -> ![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for -> -> analyzing. -> -> When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a -> -> message  that  can  specify  the  cause. -> -> Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -> -> in  a  short  period  of  time  have  been  equipped  and  able  to  select. -> -> In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or -> -> system  down  does  not  occur  (self-destruction  on  log  output  process). -> -> Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. -> -> Should  be  able  to  select  the  level  of  log  output. -> -> Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. -> -> Should  be  able  to  obtain  the  information  linked  to  the  system  resources. -> -> Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. -> -> Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -> -> in  a  short  period  of  time  have  been  equipped  and  able  to  select. -> -> As  the  smallest  amount  of  information,  the  following  information  should  be  left. -> -> · Register  information -> -> · Process  logical  memory  map -> -> · -> Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence -> -> · Time  of  occurrence -> -> · -> Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing -> -> file‑name  of  the  thread  etc.) -> -> Page  96  of  159 -> -> ![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · The  signal  that  occurred -> -> Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. -> -> · -> Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted -> -> for  an  output. -> -> · -> Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent -> -> dropping  the  information  needed. -> -> · -> Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] -> -> · -> Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed -> -> maximum  size. -> -> · -> NOTE  information  of  ELF  header  and  program  header  will  not  change. -> -> Selectable  memory  mappings  are  the  following. -> -> · anonymous  private  mappings -> -> · anonymous  shared  mappings -> -> · file-backed  private  mappings -> -> · file-backed  shared  mappings -> -> · private  huge  page -> -> · shared  huge  page -> -> Setting  parameters  of  the  output  context  are  the  following. -> -> · -> Memory  mapping  category  which  is  for  an  output  object  can  be  set. -> -> · The  order  of  outputting  memory  mapping  can  be  set. -> -> Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in -> -> increments  of  process. -> -> Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be -> -> able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. -> -> Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. -> -> Page  97  of  159 -> -> ![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. -> -> **5.1.3  Graphics** -> -> Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. -> -> **5.1.4  Location  Services** -> -> Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead -> -> reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary -> -> output  of  the  GPS  receiver. -> -> **5.1.4.1  Position** -> -> **5.1.4.2  Time  of  Day** -> -> With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car -> -> device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of -> -> its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in -> -> future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. -> -> **Monotonic  and  Absolute  Time  Support** -> -> As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. -> -> Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s -> -> moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and -> -> Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. -> -> On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time -> -> that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, -> -> some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports -> -> Monotonic  Time. -> -> **Kernel  Time  Precision** -> -> Page  98  of  159 -> -> ![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those -> -> communicating  system  includes  the  device  that  needs  ms  order  procedure. -> -> In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on -> -> the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest -> -> value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. -> -> **5.1.4.3  Requirements** -> -> Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. -> -> Adjust  the  system  time  after  the  time  is  determinate. -> -> GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using -> -> the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. -> -> GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not -> -> imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make -> -> Source  plugin  can  not  be  GPL  or  LGPL. -> -> When  waiting,  can  use  both  absolute  time  and  monotonic  time -> -> Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -> -> monotonic  time. -> -> Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -> -> monotonic  time. -> -> System  time  must  be  able  to  use  consecutively  at  least  until  2099. -> -> Absolute  time  has  to  support  leap  year  and  leap  seconds. -> -> 1  jiffies  have  to  be  smaller  than  1ms. -> -> Page  99  of  159 -> -> ![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. -> -> From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. -> -> A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. -> -> **5.1.5  Health  Monitoring** -> -> Platform  monitoring  services  such  as  watchdog  or  active  monitoring -> -> **5.1.6  IPC** -> -> Standard  platform  interprocess  and  interprocessor  communication  mechanism. -> -> **5.1.7  Lifecycle  Management** -> -> Startup,  shutdown,  state  change,  etc. -> -> **5.1.8  Network  Services** -> -> Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer -> -> including  Wifi,  Bluetooth,  or  ethernet. -> -> **5.1.9  Persistent  Storage** -> -> Power  safe  persistent  storage -> -> **5.1.10  Power  Management** -> -> Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs -> -> in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. -> -> *This, in turn has impact on power budget and temperature/heat dissipation characteristic of* -> -> Page  100  of  159 -> -> ![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> modern  ECUs -> -> In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, -> -> in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal -> -> balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important -> -> for  overall  durability  characteristic. -> -> Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming -> -> more  welcomed  over  traditional  cold  boot  approaches. -> -> Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has -> -> become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only -> -> consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) -> -> **5.1.10.1  Requirements** -> -> AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend -> -> states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” -> -> /“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) -> -> Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. -> -> AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state -> -> transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state -> -> transitions  if  no  requests  provided  from  applications. -> -> Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of -> -> this  specification  (it  is  also  platform-dependent). -> -> AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of -> -> cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting -> -> core  in  one  of  its  low  power  states) -> -> AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular -> -> cores  from  SMP  group. -> -> Page  101  of  159 -> -> ![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points -> -> (table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, -> -> some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget -> -> insignificant) -> -> Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling -> -> Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. -> -> Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they -> -> may  have  negative  impact  on  overall  system  performance/predictability -> -> AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is -> -> platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) -> -> Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states -> -> Only  application-defined  policies  shall  be  allowed  for  CPU  Idle -> -> AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices -> -> AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling -> -> **5.1.11  Resource  Management** -> -> Resource  and  device  management. -> -> Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource -> -> request  by  the  Resource  Manager. -> -> **5.1.12  Telephony  Services** -> -> **5.1.12.1  Requirements** -> -> Page  102  of  159 -> -> ![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.12.1.1  Telephony  variants -> -> Purpose:  To  define  the  variants  of  Telephony -> -> Requirement: -> -> There  will  be  2  variants  of  phone  system. -> -> Variant  1:  Front  User  only  Telephony. -> -> Variant  2:  Rear  and  Front  Telephony. -> -> All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature -> -> can  be  disabled  via  car  configuration. -> -> **5.1.13  Wi-Fi** -> -> This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information -> -> management  between  a  wireless  LAN  device  and  infotainment  system. -> -> Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. -> -> **5.1.13.1  Use  Cases** -> -> 5.1.13.1.1  Construct  WiFi  Network -> -> In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. -> -> a\. STA -> -> In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via -> -> an  Access  Point. -> -> It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. -> -> b\. AP -> -> In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices -> -> with  an  external  network. -> -> Page  103  of  159 -> -> ![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. -> -> c\. P2P -> -> In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- -> -> Fi  Direct. -> -> 5.1.13.1.2  Miracast -> -> In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) -> -> They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, -> -> by  using  UIBC  (User  Interface  Back  Channel).-(b) -> -> **Figure  8-29  :  Overview  of  Miracast** -> -> a\. Shared  Displayed  Content -> -> Page  104  of  159 -> -> ![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Use  case  examples  of  shared  displayed  content  are: -> -> · -> A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device -> -> (e.g.  Mobile)  on  In-Vehicle  Infotainment  system. -> -> · -> A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment -> -> system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). -> -> b\. Remote  Operation -> -> Use  case  examples  of  remote  operation  are: -> -> · -> A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device -> -> (e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. -> -> · -> A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle -> -> Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). -> -> · -> While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation -> -> functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. -> -> Mobile). -> -> 5.1.13.1.3  DLNA -> -> In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. -> -> **5.1.13.2  Requirements** -> -> 5.1.13.2.1  Security -> -> The  WiFi  module  shall  support  security  standard  WEP. -> -> It  shall  support  40  bit  WEP  encryption  method. -> -> It  shall  support  104  bit  WEP  encryption  method. -> -> It  shall  support  security  standard  WPA  Personal. -> -> Page  105  of  159 -> -> ![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  shall  support  TKIP  encryption  method. -> -> It  shall  support  CCMP  encryption  method. -> -> It  shall  support  security  standard  WPA2  Personal. -> -> It  shall  support  TKIP  encryption  method. -> -> It  shall  support  CCMP  encryption  method. -> -> It  shall  support  security  standard  WPA  Enterprise. -> -> It  shall  support  TKIP  encryption  method. -> -> It  shall  support  CCMP  encryption  method. -> -> It  shall  support  security  standard  WPA2  Enterprise. -> -> It  shall  support  TKIP  encryption  method. -> -> It  shall  support  CCMP  encryption  method. -> -> 5.1.13.2.2  Simple  Configuration -> -> It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. -> -> It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. -> -> It  shall  support  Configuration  Method  for  Display. -> -> Page  106  of  159 -> -> ![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  shall  support  Configuration  Method  for  Keypad. -> -> It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. -> -> It  shall  support  Configuration  Method  for  PushButton. -> -> It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. -> -> 5.1.13.2.3  QoS -> -> It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. -> -> It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. -> -> 5.1.13.2.4  STA -> -> The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). -> -> 5.1.13.2.5  AP -> -> The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). -> -> 5.1.13.2.6  WiFi  Direct -> -> It  shall  comply  with  Wi-Fi  Direct  standard. -> -> It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. -> -> Page  107  of  159 - - -------------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **(Reference)** - > - > **Support  in  Wi-** - > - > **Fi  Direct** - ----------- ---------------------------------------------------- -------------------------- ------------------------ - > 1 > P2P  Provision > ‑ > Mandatory - > - > Discovery - - > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory - - > 3 > ‑ > Find  Phase > Mandatory - - > 4 > P2P  GO  Negotiation > ‑ > Mandatory - - > 5 > P2P  Service  Discovery > ‑ > Option - - > 6 > P2P  Invitation > Temporary  P2P  Group > Option - - > 7 > ‑ > Persistent  P2P  Group > Option - - > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option - - > 9 > Intra-BSS  Distribution > ‑ > Option - - > 10 > Concurrent  Operation > ‑ > Option - - > 11 > P2P  Service  Discovery > UPnP > Option - - > 12 > ‑ > Bonjour > Option - - > 13 > ‑ > Wi-Fi  Display > Option - - > 14 > ‑ > WS-Discovery > Option - - > 15 > ‑ > Vendor  specific > Option - -------------------------------------------------------------------------------------------------------------------- - -> ![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.13.2.7  Miracast -> -> Page  108  of  159 - - -------------------------------------------------------------------------------------------------------------- - > ‑**No.** > **Feature** > ‑ > **(Refere** - > - > **nce)** - > - > **Suppor** - > - > **t        in** - > - > **Miracas** - > - > **t** - ------------ ----------------------------------------------------- ----------------------- ------------------- - > 1 > WFD  Device  type > WFD  Source > Mandat - > - > ory - - > 2 > ‑ > Primary  Sink > Mandat - > - > ory - - > 3 > ‑ > Dual-role  possible > Option - - > 4 > WFD  Service > ‑ > Option - > - > Discovery - - > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat - > - > ory - - > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option - - > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option - > - > Group - - > 8 > ‑ > via  TDLS > Option - - > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat - > - > ory - - > 10 > WFD  Session  Establishment  (RTSP) > Mandat - > - > ory - -------------------------------------------------------------------------------------------------------------- - -> ![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  shall  comply  with  Miracast  standard. -> -> It  shall  support  the  Miracast  functions  identified  in  Table  30. -> -> Page  109  of  159 - - --------------------------------------------------------------------------------- - > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat - > - > ory - ------ --------------------------------------------------- ----------- ---------- - > 12 > WFD  Standby  (RTP/RTSP) > Option - - > 13 > Video  CODEC  formats > Option - - > 14 > Audio  CODEC  formats > Option - - > 15 > UIBC > Generic - - > 16 > HIDC - --------------------------------------------------------------------------------- - -> ![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.1.13.2.8  WiFi  Hotspot -> -> It  shall  comply  with  Wi-Fi  Hotspot  standard. -> -> In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot -> -> service. -> -> In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. -> -> 5.1.13.2.9  DLNA  via  WiFi -> -> The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. -> -> **5.1.14  Window  System** -> -> A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -> -> interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -> -> Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -> -> component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -> -> and  a  routing  of  user  interactions. -> -> Page  110  of  159 -> -> ![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.2  Automotive  Services -> -> Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but -> -> contains  services  specialized  for  automotive  applications. -> -> **5.2.1  Audio  Services** -> -> BTBF,  equilization,  mult-zone  audio  control,  etc. -> -> **5.2.2  Camera  Services** -> -> Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. -> -> **5.2.3  Configuration  Services** -> -> Service  for  storing  configuration  parameters. -> -> **5.2.4  Diagnostic  Services** -> -> Diagnostic  services. -> -> (This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) -> -> **5.2.5  Multimedia  Services** -> -> CD,  DVD,  Blu-Ray,  MP3,  etc. -> -> (Factor  out  metadata  into  separate  component.) -> -> **5.2.5.1  Media  Player** -> -> In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just -> -> Page  111  of  159 -> -> ![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video -> -> devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, -> -> there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- -> -> seat  passengers  as  well  as  driver  all  having  independent  requirements. -> -> The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: -> -> · -> Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the -> -> ones  encountered  in  mobile  and  desktop  world. -> -> · -> Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) -> -> and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or -> -> establishes  a  network  connection.) -> -> · -> Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of -> -> audio  /  video  processing  chains. -> -> Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data -> -> processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in -> -> comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from -> -> navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from -> -> Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so -> -> on. -> -> It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore -> -> processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing -> -> offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with -> -> particular  implementation  freedom  left  for  a  silicon  vendor. -> -> The  following  requirements  formalize  these  considerations. -> -> **5.2.5.2  Requirements** -> -> 5.2.5.2.1  Media  Containers -> -> AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This -> -> includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It -> -> shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable -> -> input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated -> -> from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall -> -> be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. -> -> Page  112  of  159 -> -> ![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, -> -> for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream -> -> identification  data  from  media  container. -> -> AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: -> -> · HTTP -> -> · RTPS -> -> · Digital  Radio  (DAB) -> -> · DigitalTV  (DVB-T)  etc. -> -> It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with -> -> system  requirements. -> -> AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload -> -> computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such -> -> extension,  if  available,  shall  be  transparent  to  the  applications. -> -> Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. -> -> AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the -> -> source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without -> -> intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this -> -> process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of -> -> particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from -> -> multiple  choices. -> -> AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall -> -> support  the  following  functionality: -> -> · -> Selection  of  data  source  and  destination  (files,  devices,  network  resources) -> -> · Pausing/resuming  of  multimedia  streams -> -> · Rewinding  in  forward  and  reverse  directions  (for  playback) -> -> · Audio  volume  control  on  per-stream  basis -> -> · Retrieval  of  current  stream  position  (timestamp) -> -> Page  113  of  159 -> -> ![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · -> Notifications  on  error  conditions  preventing  multimedia  stream  processing -> -> AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved -> -> into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to -> -> specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to -> -> specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw -> -> audio/video  streams  to  multiple  renderers  as  well. -> -> AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and -> -> synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: -> -> · -> Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. -> -> · Per-stream  volume  and  audio  effects  control. -> -> · -> Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). -> -> · -> Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). -> -> · Mixing  and  broadcasting  of  the  audio  streams. -> -> AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to -> -> specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or -> -> removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, -> -> emergency  system  alarm  output  and  so  on. -> -> AGL  shall  provide  support  for  major  multimedia  containers,  such  as: -> -> · MPEG2-TS/PS  (ISO/IEC  13818-1) -> -> · MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) -> -> It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with -> -> system  requirements. -> -> It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: -> -> · OGG  (RFC  3533) -> -> · 3GPP  (ISO/IEC  14496-12) -> -> · etc -> -> Page  114  of  159 -> -> ![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 5.2.5.2.2  Media  Audio  Codecs -> -> AGL  shall  provide  support  for  major  audio  codecs,  such  as: -> -> · -> MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) -> -> · AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) -> -> It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system -> -> requirements. -> -> It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: -> -> · VORBIS  (http://xiph.org/vorbis/) -> -> · Windows  Media  Audio -> -> · etc. -> -> 5.2.5.2.3  Media  Video  Codecs -> -> AGL  shall  provide  support  for  major  video  codecs,  such  as: -> -> · MPEG-2  (ISO/IEC  13818-2) -> -> · MPEG-4  Part  2  (ISO/IEC  14496-2) -> -> · H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) -> -> It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system -> -> requirements. -> -> It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: -> -> · Theora  (www.theora.org) -> -> · Windows  Media  Video -> -> · etc -> -> 5.2.5.2.4  Image  File  Formats -> -> Page  115  of  159 -> -> ![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true -> -> colour. -> -> Compression  formats -> -> · RLE  8  bits/pixel -> -> · RLE  4  bits/pixel -> -> · Bit  field  or  Huffman  1D  compression -> -> · JPEG  or  RLE-24 -> -> · PNG -> -> The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 -> -> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including -> -> Exchangeable  Image  File  Format  (EXIF)  format. -> -> The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, -> -> including  transparency -> -> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced -> -> version  89a  and  also  animation  in  GIFF  images. -> -> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. -> -> The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -> -> format. -> -> The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -> -> format. -> -> **5.2.6  Navigation  Services** -> -> Navigation  engine -> -> Page  116  of  159 -> -> ![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **5.2.7  PIM** -> -> Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. -> -> **5.2.8  Smartphone  Link** -> -> This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which -> -> realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation -> -> is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and -> -> AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use -> -> smartphone  content  (map,  music,  browser...)  by  IVI. -> -> Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. -> -> **Figure:  8-30** -> -> Page  117  of  159 -> -> ![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AGL  defines  following  requirements  of  Smartphone  link. -> -> 1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. -> -> 2.  The  sound  of  smartphone  shall  be  linked  to  IVI. -> -> 3.  The  sound  shall  be  synchronized  with  the  screen. -> -> 4.  IVI  should  operate  smartphone. -> -> 5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. -> -> 6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should -> -> inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. -> -> This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone -> -> link. -> -> **5.2.8.1  Miracast** -> -> This  section  describes  requirements  regarding  Smartphone  link  (Miracast). -> -> Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- -> -> Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing -> -> between  source  device  and  sink  device. -> -> Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. -> -> **Figure:  8-31** -> -> Page  118  of  159 - - ---------------------------------------------------------------------------------------------- - > **No** > **Requires** > **Description** - ------------ ----------------------------- --------------------------------------------------- - > SPL.1.1 > WFD  Topology > Define  role  of  Miracast - - > SPL.1.2 > Connection  Topology > Define  connection  condition  between - > - > a  smartphone  and  an  IVI - - > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi - > > - > 1 > Direct). - - > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency - > - > 2 - - > SPL.1.3 > Video  Format > Define  Video  format - - > SPL.1.4 > Audio  Format > Define  Audio  format - - > SPL.1.5 > Session  Control > Define  Miracast  session  state - - > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required - > - > for  implementing  Miracast - - > SPL.1.7 > Resource  Management > Define  resource  management - ---------------------------------------------------------------------------------------------- - -> ![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. -> -> **References** -> -> \[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 -> -> \[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 -> -> \[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision -> -> 2.2 -> -> \[4\]  DCP  (Digital  Content  Protection)   -> -> AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. -> -> Page  119  of  159 -> -> ![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> SPL.1.8 Fail-safe  Control Define  Fail-safe  control -> -> **Table  8-14:  Smartphone  Link  (Miracast)  Requirements** -> -> **Figure:  8-32  State  Change  Diagram** -> -> The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. -> -> Page  120  of  159 - - ------------------------------------------------------------------------------------------------------- - > **No.** > **State** > **Description** - ----------- ------------------------- ----------------------------------------------------------------- - > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. - - > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and - > - > waiting  for  Wi-Fi  P2P  connection  from  source - > - > device. - - > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source - > - > device. - - > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. - - > 5 > Play > Streaming  the  audio  and  video  content  from  source - > - > device  to  sink  device. - - > 6 > Pause > Paused  the  streaming  of  audio  and  video  content - > - > from  source  divide  to  sink  device. - ------------------------------------------------------------------------------------------------------- - -> ![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **5.2.8.2  Smart  Device  Link** -> -> “Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. -> -> Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach -> -> makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s -> -> distraction  and  voice  recognition. -> -> That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote -> -> procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework -> -> and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. -> -> SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile -> -> phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported -> -> applications  can  be  launched. -> -> Page  121  of  159 -> -> ![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **Figure  8-33  :  SDL  overview** -> -> **5.2.8.3  Requirements** -> -> 5.2.8.3.1  Miracast -> -> System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. -> -> · -> Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which -> -> from  Source  Device‑Smartphone‑. -> -> · Supporting  WFD  Source  is  an  option. -> -> · -> Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) -> -> source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). -> -> · -> Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take -> -> measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over -> -> 5Km/H) -> -> · Support  Wi-Fi  P2P  connection. -> -> · -> Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in -> -> Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. -> -> · Wi-Fi  TDLS  connection  is  an  option. -> -> · -> AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select -> -> Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) -> -> · -> AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive -> -> Page  122  of  159 -> -> ![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for -> -> confirmation) -> -> · -> Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. -> -> · -> Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P -> -> connection  established. -> -> · -> Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. -> -> · -> Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) -> -> function  if  support  5GHz  band. -> -> · Follow  reference  \[1\]  for  Video  Codec. -> -> · Support  follow  format  for  Video  Resolution  and  Frame  rate. -> -> o 640\*480‑VGA‑‑Progressive  60  fps -> -> o 1280\*720‑HD‑Progressive  30  fps -> -> Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. -> -> · Support  follow  format  for  Audio. -> -> o LPCM  48ksps  16bit  2ch -> -> o AAC  48ksps  16bit  2ch -> -> Regarding  Audio  Format,  other  formats  are  an  option. -> -> When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up -> -> notification) -> -> Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support -> -> content  protection  function. -> -> · -> AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not -> -> define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for -> -> Page  123  of  159 -> -> ![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> vendor’s  own  reason. -> -> · Support  both  encryption  cases  if  support  HDCP  function. -> -> o Case1  Videos  data  encryption -> -> o Case2  Both  video  and  audio  encryption -> -> Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to -> -> DCP.(reference  \[4\]) -> -> · -> Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, -> -> then  Miracast  release  screen  and  audio  resources  for  the  event. -> -> · -> It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast -> -> session.) -> -> · -> Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events -> -> happen. -> -> o Failed  to  Wi-Fi  connection -> -> o Failed  to  establish  Miracast  session -> -> o Wi-Fi  link  loss  on  Miracast -> -> o Break  Miracast  connection  from  smartphone -> -> 5.2.8.3.2  Smart  Device  Link -> -> System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. -> -> System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. -> -> System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel -> -> device  of  IVI  device. -> -> System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice -> -> Page  124  of  159 -> -> ![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> recognition  of  IVI  system. -> -> System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity -> -> method  must  be  supported  Bluetooth  and/or  Wi-Fi. -> -> System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity -> -> method  must  be  supported  Bluetooth  and/or  Wi-Fi. -> -> **5.2.9  Speech  Services** -> -> The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. -> -> AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands -> -> AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech -> -> **5.2.10  Tuner  Services** -> -> The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into -> -> the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, -> -> TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present -> -> in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. -> -> **5.2.10.1  Receivers** -> -> The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including -> -> AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any -> -> number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from -> -> the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current -> -> content. -> -> The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into -> -> the  same  API  regardless  of  the  receiver  type. -> -> Page  125  of  159 -> -> ![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow -> -> its  clients  to  address  each  receiver  in  the  system  independently. -> -> 5.2.10.1.1  HD  Radio -> -> HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An -> -> HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to -> -> provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the -> -> receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The -> -> HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the -> -> iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional -> -> design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by -> -> iBiquity  Digital. -> -> The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the -> -> requirements  in  this  section. -> -> 1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. -> -> 2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. -> -> 3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. -> -> Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is -> -> applicable  to. -> -> AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status -> -> to  the  system. -> -> AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the -> -> tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning -> -> successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio -> -> output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No -> -> Reception"  is  available  in  that  specific  channel. -> -> AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -> -> the  system,  which  shall  be  added  in  the  station  database. -> -> Page  126  of  159 -> -> ![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · Frequency -> -> · Mono/Stereo -> -> FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -> -> the  system,  which  shall  be  added  in  the  station  database. -> -> · Frequency -> -> · PI  Code  (RDS  only) -> -> · PTY  (RDS  only) -> -> · Radio  Text  (RDS  only) -> -> · PS  Name  (RDS  only) -> -> · Category  (RDS  only) -> -> · Mono/Stereo -> -> HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -> -> the  system,  which  shall  be  added  in  the  station  database. -> -> · Frequency -> -> · PTY -> -> · No  of  HD  channels  available -> -> · Radio  Text -> -> · Channel  Name -> -> · Category -> -> · Bit  rate -> -> · Station  Logo -> -> · Artist  Experience -> -> The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. -> -> The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal -> -> strength. -> -> AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. -> -> Page  127  of  159 -> -> ![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be -> -> possible  to  adjust  by  software. -> -> · Range:  15  –  40  dBµV -> -> · Step:  1  dBµV -> -> · Default:  20  dBµV -> -> · -> Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity -> -> level.  TBD,  Supplier  to  suggest  solution. -> -> AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be -> -> possible  to  adjust  by  software. -> -> · Range:  20  –  40  dBµV -> -> · Step:  1  dBµV -> -> · Default:  34  dBµV -> -> · -> It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. -> -> different  for  night  and  day). -> -> The  system  shall  be  able  to  switch  between  AM  and  FM  bands. -> -> HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the -> -> SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -> -> present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance -> -> with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -> -> Information  Service  Transport". -> -> HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the -> -> SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -> -> present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance -> -> with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -> -> Information  Service  Transport". -> -> HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. -> -> Page  128  of  159 -> -> ![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. -> -> · Song -> -> · Artist -> -> · Album -> -> · Genre -> -> · Comments -> -> · Commercial -> -> · Reference  Identifier -> -> The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification -> -> "HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" -> -> FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the -> -> system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, -> -> Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency -> -> range  from  87,5  MHz  to  108,0  MHz". -> -> FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled -> -> the  system  shall  indicate  this. -> -> FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. -> -> FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. -> -> FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. -> -> FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. -> -> FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. -> -> FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received -> -> through  RDS. -> -> Page  129  of  159 -> -> ![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. -> -> FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. -> -> FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. -> -> FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. -> -> FM/HD  system  shall  be  able  to  enable/disable  regionalisation. -> -> FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. -> -> FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) -> -> reception. -> -> FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. -> -> FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. -> -> FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. -> -> HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. -> -> HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. -> -> AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. -> -> AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. -> -> *HD system shall extract the album name, artist name, track number from the audio stream a*nd -> -> Page  130  of  159 -> -> ![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> present  to  the  system. -> -> The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The -> -> feature  will  be  able  to  store  at  least  50  tags. -> -> *5.2.10.1.1.1  Configuration* -> -> AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration -> -> file. -> -> AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. -> -> AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local -> -> configuration  file. -> -> 5.2.10.1.2  Database  Requirements -> -> AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains -> -> the  following  attributes: -> -> · Frequency -> -> · PTY  (FM  &  HD  only) -> -> · Channel  name  (FM  &  HD  only) -> -> · Channel  icon  (HD  Only) -> -> · Category  (FM  &  HD  only) -> -> AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following -> -> conditions: -> -> · New  channel  is  found -> -> · Existing  channel  disappears -> -> · -> Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list -> -> database. -> -> Page  131  of  159 -> -> ![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present -> -> to  the  system. -> -> AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the -> -> frequency,  and  present  to  the  system. -> -> FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, -> -> and  present  to  the  system. -> -> AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following -> -> information: -> -> · Station  name  (FM  and  HD  only) -> -> · Frequency -> -> · Status  of  HD  (HD,  HD1,  HD2) -> -> · HD  SIS  (HD  only) -> -> AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: -> -> · Favourite  station  changed -> -> · Favourite  station  is  removed -> -> · New  favourite  is  added -> -> **5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** -> -> Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from -> -> applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and -> -> LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of -> -> VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main -> -> functions. -> -> · Vehicle  Data  Processing -> -> · Communication  between  ECUs -> -> · Vehicle  Data  Upload -> -> Page  132  of  159 -> -> ![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · Simulator -> -> **Figure  7-27  :  Overview  of  Vehicle  Info  Control** -> -> **5.2.11.1  Vehicle  Data  Processing** -> -> Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, -> -> personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application -> -> and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. -> -> · -> Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature -> -> · User  Information,  such  as  a  name,  taste,  etc.  of  a  driver -> -> · The  operation  history  of  a  driver -> -> Page  133  of  159 -> -> ![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · -> The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle -> -> conditions,  such  as  speed  and  day  and  night -> -> Vehicles  data  processing  consists  of  the  following  functional  elements  further. -> -> (1)  Abstraction  of  Vehicles  Data -> -> In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind -> -> of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving -> -> speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for -> -> application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles -> -> data  of  the  same  implications  and  the  same  unit. -> -> (2)  Maintenance  of  Vehicles  Data -> -> Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past -> -> value  (history). -> -> (3)  Application  /  Middleware  Interface  (API) -> -> The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. -> -> Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and -> -> the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data -> -> restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance -> -> (access  control). -> -> (4)  Vehicles  Interface -> -> It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN -> -> and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the -> -> exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. -> -> However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more -> -> Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In -> -> addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. -> -> **5.2.11.2  Communications  between  ECUs** -> -> Page  134  of  159 -> -> ![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -> -> ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -> -> vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -> -> middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -> -> acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -> -> which  each  ECU  can  access. -> -> **5.2.11.3  Vehicle  Data  Upload** -> -> When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -> -> ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -> -> vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -> -> middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -> -> acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -> -> which  each  ECU  can  access. -> -> **5.2.11.4  Simulator** -> -> In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is -> -> unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes -> -> development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel -> -> controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be -> -> an  option. -> -> **5.2.11.5  Requirements** -> -> The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application -> -> and/or  middleware  can  access  vehicle  information. -> -> The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract -> -> property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but -> -> the  speed  of  a  car. -> -> System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. -> -> Page  135  of  159 -> -> ![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  must  support  typical  vehicle  property  as  “standard  property”. -> -> As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. -> -> System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. -> -> A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard -> -> property. -> -> Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) -> -> The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or -> -> middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough -> -> as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile -> -> display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. -> -> A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is -> -> stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the -> -> load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and -> -> spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. -> -> It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In -> -> corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. -> -> · -> The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the -> -> accumulated  newest  value  is  less  than  a  threshold  value. -> -> · -> Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the -> -> newest  accumulation. -> -> About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need -> -> to  be  able  to  set  up  easily. -> -> In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. -> -> System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property -> -> access. -> -> System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or -> -> middleware. -> -> Page  136  of  159 -> -> ![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Below  attributes  must  include  in  this  interface -> -> · Zone(optional) -> -> · Property  name -> -> · Value -> -> · -> Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -> -> System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application -> -> and/or  middleware. -> -> Below  attributes  must  include  in  this  interface. -> -> · Zone(optional) -> -> · Property  name -> -> · Value -> -> System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from -> -> application  and/or  middleware. -> -> When  status  changed,  system  must  invoke  callback  function  with  below  attributes. -> -> · Zone(optional) -> -> · Property  name -> -> · Value -> -> · Timestamp -> -> · Sequence  number -> -> Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -> -> Sequence  number  is  useful  to  check  event  order. -> -> The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of -> -> change  of  vehicle  information. -> -> In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an -> -> acceptable  value  even  if  vehicle  information  changes. -> -> For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the -> -> application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of -> -> change. -> -> Page  137  of  159 -> -> ![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. -> -> · -> The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the -> -> value  from  the  last  notice  of  change  is  less  than  specification. -> -> · -> Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a -> -> definite  period  of  time,  it  does  not  notify. -> -> Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the -> -> time  of  change. -> -> What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified -> -> notice  interval  is  made  possible. -> -> The  data  stored  is  acquired  collectively. -> -> Below  attributes  must  include  in  this  interface. -> -> · Zone(optional) -> -> · Property  name -> -> · Values -> -> · Timestamps -> -> It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 -> -> seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. -> -> There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual -> -> in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed -> -> simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the -> -> newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to -> -> recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information -> -> relevant  to  mutual  and  to  access  it. -> -> Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle -> -> information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, -> -> and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all -> -> those  vehicle  information  at  the  time  of  reference. -> -> The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. -> -> Or  the  thing  which  can  be  changed  from  a  program  during  operation. -> -> Page  138  of  159 -> -> ![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property -> -> "velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be -> -> accessed  from  all  applications. -> -> System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same -> -> property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only -> -> application  C  can  set  this  property. -> -> Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control -> -> policy  may  be  different  per  car  type,  grade  and  destination. -> -> System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU -> -> and  across  two  or  more  ECU’s. -> -> If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, -> -> middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, -> -> the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware -> -> which  exist  in  a  different  ECU. -> -> VIC  can  be  requested  to  set  the  value  specified  as  Property. -> -> It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. -> -> The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand -> -> from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. -> -> Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application -> -> responds. -> -> It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed -> -> easily. -> -> The  data  exchange  between  ECUs  should  be  permitted  by  VIC. -> -> All  data  transmission  and  reception  from  other  Software  Component  are  refusing. -> -> Page  139  of  159 -> -> ![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. -> -> The  vehicle  information  to  upload  is  being  able  to  choose. -> -> A  selection  condition  is  that  the  following  specification  is  possible  at  least. -> -> · Date-and-time  range -> -> · Object  vehicles  data -> -> · The  change  threshold  value  of  vehicles  data -> -> Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be -> -> able  to  change  dynamically  from  an  external. -> -> The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as -> -> substitution  of  actual  vehicles  in  development  environment  is  prepared. -> -> Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing -> -> activities  through  a  vehicles  interface  function  at  least. -> -> · Speed -> -> · Shift  position -> -> · The  direction  of  vehicles -> -> · Latitude  and  longitude  of  a  current  position -> -> · Turn  signal -> -> The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, -> -> it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. -> -> VIC  should  fill  the  following  performance  specifications  and  performance. -> -> It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -> -> information  machines  and  equipment  in  2016. -> -> Page  140  of  159 -> -> ![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · Maximum  number  of  properties  :  4,096 -> -> · Maximum  number  of  property  sets:  1,024 -> -> · Greatest  data  storage  time :  12  hours -> -> It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -> -> information  machines  and  equipment  in  2016. -> -> · Get/Set  method(one  property)  -  0.2ms -> -> · Get/Set  method(property  set  include  30  properties)  -1.3ms -> -> · Subscribe  callback  -  2.5ms  (after  change  of  a  value) -> -> · -> GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms -> -> · -> GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms -> -> VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility -> -> about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and -> -> attribute  of  vehicles  data. -> -> Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by -> -> various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add -> -> and  change  Vehicle  Interface  without  reconstruction  of  VIC. -> -> Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is -> -> necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. -> -> However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness -> -> vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more -> -> concreteness  vehicles  data  into  one  abstract  vehicles  data. -> -> Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be -> -> mounted  in  the  VIC  itself. -> -> In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be -> -> added  without  reconstruction  of  VIC  is  prepared  for  VIC. -> -> **5.2.12  Telematics  Services** -> -> V2V,  V2I,  RVI,  Traffic  information,  etc. -> -> Page  141  of  159 -> -> ![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> **5.2.13  Window  System** -> -> A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -> -> interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -> -> Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -> -> component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -> -> and  a  routing  of  user  interactions. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple -> -> processes  to  be  rendered  on  a  display. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to -> -> achieve  flicker  less  rendering. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- -> -> screen  buffers. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying -> -> objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. -> -> AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos -> -> group  available  to  clients  for  their  rendering. -> -> AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -> -> APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by -> -> configuration. -> -> AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the -> -> *underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a -> -> Page  142  of  159 -> -> ![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The -> -> window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES -> -> 2.0  API  are  responsible  for  a  hardware  abstraction. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple -> -> displays. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, -> -> where  available. -> -> AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware -> -> acceleration  capabilities. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs -> -> from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a -> -> vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the -> -> vehicle  reaches  to  the  certain  speed. -> -> AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, -> -> a  touch  panel,  a  control  knob  etc. -> -> AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input -> -> from  available  physical  input  devices. -> -> **6   Security   Services** -> -> Security  framework -> -> 6.1  Access  Control -> -> Access  Control  describes  requirements  for  AGL  Access  Control. -> -> Page  143  of  159 -> -> ![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. -> -> **6.1.1  Requirements** -> -> AGL  system  must  support  a  system-wide  access  control  mechanism. -> -> **7   Operating   System   Layer** -> -> 7.1  Kernel -> -> **7.1.1  Linux  Kernel** -> -> Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new -> -> release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years -> -> for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and -> -> kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the -> -> rest  of  the  open  source  community  provides, -> -> **7.1.1.1  Requirements** -> -> AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. -> -> At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive -> -> industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully -> -> aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by -> -> Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to -> -> accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to -> -> regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with -> -> the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. -> -> AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on -> -> particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. -> -> Page  144  of  159 -> -> ![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 7.2  Boot  Loader -> -> 7.3  Hypervisor -> -> TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level -> -> virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI -> -> systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android -> -> and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on -> -> top  type1  hypervisor. -> -> **7.3.1  Requirements** -> -> AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that -> -> have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The -> -> processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. -> -> AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following -> -> functionality  shall  be  supported  by  AGL  Linux  “guest”: -> -> · IPC  (with  hypervisor  and  other  “guests”) -> -> · -> “paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless -> -> virtualization  abstraction  is  supported  by  hardware) -> -> 7.4  Operating  System -> -> **7.4.1  File  Systems** -> -> File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability -> -> as  their  main  characteristics. -> -> · -> *Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, -> -> tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process -> -> environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management -> -> techniques. -> -> Page  145  of  159 - - ------------------------------------------------------------------------------- - > **FS  Requirements** > **R-FS  References** - ------------------------------------------------------ ------------------------ - > 6.  File  Systems  (P1) > 2.  btrfs - > > - > 6.1.  Robust  File  System  for  managed  internal > 2.1. - > > - > storage  (P1) > btr - > > - > 6.1.1.  Power  failure  tolerance  (P1) > fsc - > > - > 6.1.2.  Quick  recovery  after  power  loss > k - > > - > (P1) > 3.  ext2 - > > - > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. - > > - > 6.1.4.  On-demand  integrity  checker  (P1) > e2 - > > - > 6.1.5.  Read-only  mode  (P1) > def - > > - > 6.1.6.  Non-blocking  unmounting  (P1) > rag - > > - > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 - > > - > performance  if  it  may  degrade  under > 5.  ext4 - > > - > certain  conditions.  (P2) > 5.1. - > > - > 6.1.8.  File  space  pre-allocation  (P2) > e4 - > > - > 6.1.9.  Meta-data  error  detection  (P2) > def - > > - > 6.1.10.  File  data  error  detection  (P2) > rag - > > - > 6.1.11.  Online  integrity  checking  (P2) > 5.2. - > > - > 6.1.12.  Write  timeout  control  (P2) > e2f - > > - > 6.1.13.  Compression  support  (P2) > sck - > > - > 6.1.14.  Quota  support  (P2) > 6.  vfat - > > - > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS - > > - > 6.1.16.  File  system  event  notifications > 8.  Generic - > - > tools  and - > - > APIs - > - > 8.1. - > - > fan - ------------------------------------------------------------------------------- - -> ![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> · -> *Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing -> -> designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. -> -> · -> *Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual -> -> packages,  and  availability  of  file  system  checking  and  optimization  tools. -> -> ![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> (P2) -> -> 6.1.17.  Logical  block  size  control  (P2) -> -> 6.1.18.  Snapshots  (P2) -> -> 6.2.  File  System  for  non-managed  internal -> -> storage  (P1) - -May  28,  2015 - -otif - -y - -8.2. - -fst - -rim - -> 6.2.1.  All  P1  requirements  from -> -> FS.1.1.x  list  (P1) -> -> 6.2.2.  Wear  leveling  (P1) -> -> 6.2.3.  Error  detection/correction  (P1) -> -> 6.2.4.  Tolerance  to  flipping  bits  (P1) -> -> 6.2.5.  Read/write  disturb  awareness -> -> (P1) -> -> 6.2.6.  Bad  block  management  (P1) -> -> 6.2.7.  As  many  P2  requirements  from -> -> FS.1.1.x  list  as  possible  (P2) -> -> 6.2.8.  Wear  leveling  statistics  (P2) -> -> 6.3.  File  Systems  for  removable  storage  (P1) -> -> 6.3.1.  Restricted  functionality  from -> -> security  point  of  view  (P1) -> -> 6.3.2.  Automount/autounmount  (P1) -> -> 6.3.3.  Automatic  synchronous  flushing -> -> of  modified  data  to  physical  media  (P2) -> -> **7.4.1.1  Requirements** -> -> AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -> -> internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -> -> memory),  removable  managed  (USB  stick,  SD  card). -> -> AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, -> -> Page  147  of  159 -> -> ![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, -> -> AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. -> -> A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, -> -> and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. -> -> A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power -> -> interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should -> -> not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. -> -> Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- -> -> write)  operation. -> -> A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple -> -> threads  and/or  processes  simultaneously. -> -> A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. -> -> A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical -> -> storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” -> -> command. -> -> AGL  must  support  “lazy”  (delayed)  unmounting. -> -> AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged -> -> file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. -> -> Another  example  is  periodic  fstrim  execution  on  SSD  storage. -> -> A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This -> -> may  be  used  to  minimize  fragmentation  of  frequently  written  files. -> -> A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. -> -> Page  148  of  159 -> -> ![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored -> -> data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. -> -> A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. -> -> A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical -> -> media. -> -> A  file  system  should  support  automatic  data  compression. -> -> It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. -> -> AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. -> -> AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. -> -> Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O -> -> performance,  and  decrease  file  fragmentation  impact. -> -> A  file  system  should  allow  creation  of  snapshots. -> -> A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of -> -> erase/program  cycles  is  evenly  distributed  across  all  device  blocks. -> -> A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. -> -> A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also -> -> actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power -> -> interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the -> -> time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. -> -> A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb -> -> Page  149  of  159 -> -> ![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known -> -> techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a -> -> fresh  block  after  detected  error  correction. -> -> A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system -> -> users. -> -> Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. -> -> A  file  system  must  support  noexec,  and  nodev  mount  options. -> -> A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and -> -> automatically  unmount  it  when  unplugged. -> -> A  file  system  must  support  sync  mount  option. -> -> AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -> -> internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -> -> memory),  removable  managed  (USB  stick,  SD  card). -> -> **7.4.2  Resource  Control** -> -> In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be -> -> higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource -> -> allocation  for  each  process  and/or  process  group. -> -> (cgroups) -> -> **7.4.2.1  Use  Case  and  Role** -> -> If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current -> -> position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. -> -> On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned -> -> Page  150  of  159 - - ------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- -------------- ---------------------------------------------------------------- - > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority - > - > process  and/or  process  group  should  be  assigned - > - > more  resource. - - > 2 > Time  slot > To  share  resource  per  time  slot. - - > 3 > Release > Forced  release  of  partially  or  whole  allocated - > - > resource. - - > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate - > - > resource  per  defined  process  group. - ------------------------------------------------------------------------------------------- - -> ![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> to  higher  priority  than  others. -> -> Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at -> -> the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. -> -> Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. -> -> AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network -> -> bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. -> -> **Table  9-34  :  Functions  of  System  Resource  Management** -> -> **7.4.2.2  Requirements** -> -> 7.4.2.2.1  Priority -> -> System  provides  a  mechanism  to  set  resource  priority  per  each  process. -> -> Page  151  of  159 -> -> ![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. -> -> This  interface  must  be  called  from  other  process. -> -> CPU  resource  must  support  “priority”  based  resource  management. -> -> Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the -> -> status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. -> -> Resource  Manager  should  log  the  status  of  resources  using  by  system. -> -> Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of -> -> kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high -> -> priority  tasks. -> -> 7.4.2.2.2  Time  Slot -> -> When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a -> -> mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each -> -> processes. -> -> System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. -> -> System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage -> -> bandwidth  and  network  bandwidth. -> -> Scheduler  should  detect  the  status  of  resources  for  each  thread. -> -> Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. -> -> Scheduler  should  guarantee  that  threads  can  run  periodically. -> -> Scheduler  should  control  the  dispatches  that  occur  extremely. -> -> Page  152  of  159 -> -> ![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> 7.4.2.2.3  Release -> -> System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by -> -> specific  process. -> -> System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. -> -> 7.4.2.2.4  Grouping -> -> System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource -> -> management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same -> -> attributes  to  grouped  processes  altogether. -> -> System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. -> -> System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and -> -> network  bandwidth. -> -> **7.4.3  Startup/Shutdown  Control** -> -> Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a -> -> user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending -> -> on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which -> -> boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and -> -> “dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. -> -> **7.4.3.1  Use  Cases** -> -> (1)  Static  Modification  of  Boot/Shutdown  Order -> -> a. -> Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration -> -> To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown -> -> for  all  programs  running  on  the  target  device. -> -> Page  153  of  159 -> -> ![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> b. -> Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development -> -> In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed -> -> program  in  target  programs. -> -> c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update -> -> Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. -> -> (2)  Dynamic  Modification  of  Boot/Shutdown  Order -> -> a. -> Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using -> -> It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to -> -> be  operated  by  priority  when  ACC  turns  ON. -> -> b\. Prioritized  Boot  of  Update  Functionalities -> -> Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned -> -> ON. -> -> **7.4.3.2  Requirements** -> -> Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. -> -> Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that -> -> has  been  configured. -> -> Boot/Shutdown  Control  shall  start  independent  components  in  parallel. -> -> Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. -> -> Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that -> -> has  been  configured. -> -> Page  154  of  159 -> -> ![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. -> -> **7.4.4  Database** -> -> Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee -> -> database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system -> -> database  engine  is  rich  set  of  bindings  to  various  programming  languages. -> -> Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References -> -> hierarchy. -> -> 1.  Power  failure  tolerance  (P1) -> -> 2.  Quick  recovery  after  power  loss  (P1) -> -> 3.  Multi-threaded  I/O  (P1) -> -> 4.  API  bindings  for  C  programming  language -> -> 5.  On-demand  integrity  checker  (P2) -> -> DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write -> -> DB  transactions. -> -> DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. -> -> Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power -> -> failure  on  idle  system. -> -> DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or -> -> processes  simultaneously. -> -> DB  engine  API  must  be  available  for  C-based  applications. -> -> DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. -> -> DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power -> -> interruption  during  adding  some  data. -> -> Page  155  of  159 -> -> ![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, -> -> such  as  vehicle  information  database  and  databases  at  data  center. -> -> And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. -> -> Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption -> -> during  merging. -> -> **7.4.5  System  Update** -> -> Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are -> -> numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, -> -> bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to -> -> power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. -> -> System  Update  module  should  have  a  Robust  version  up  function. -> -> System  Update  moduleshould  have  a  system  difference  version  up  function. -> -> There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -> -> apt  of  Linux  distribution). -> -> There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -> -> apt  of  Linux  distribution). -> -> Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. -> -> If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should -> -> be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. -> -> If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during -> -> update)  should  be  detected  and  the  system  should  restart. -> -> Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. -> -> Page  156  of  159 -> -> ![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> Memory  usage  for  difference  update  should  be  maximum  1Mbyte. -> -> Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. -> -> System  Update  moduleshould  have  full  version  up  function  for  whole  system. -> -> Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow -> -> mass  update. -> -> There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. -> -> If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -> -> application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -> -> If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -> -> application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -> -> 7.5  Device  Drivers -> -> Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. -> -> **7.5.1  Peripherals** -> -> Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. -> -> The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and -> -> data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For -> -> optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less -> -> than  50  s/byte  average. -> -> The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles -> -> and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or -> -> EEPROM  is  not  allowed. -> -> Page  157  of  159 -> -> ![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be -> -> fast.  (target  <1ms/byte) -> -> N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. -> -> **7.5.2  Graphics  Drivers** -> -> Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. -> -> This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. -> -> **7.5.3  Video  Drivers** -> -> Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video -> -> codecs  will  nearly  always  be  hardware  based. -> -> **7.5.3.1  Requirements** -> -> The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video -> -> functionality. -> -> **7.5.4  Audio  Codecs** -> -> **7.5.4.1  Requirements** -> -> Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are -> -> implemented  in  hardware. -> -> Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs -> -> that  are  required  for  AGL-based  products  and  not  supported  in  hardware. -> -> **7.5.5  Automotive  Devices** -> -> Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or -> -> *LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* -> -> Page  158  of  159 -> -> ![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 -> -> May  28,  2015 -> -> required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for -> -> navigation  or  an  air  bag  sensor  for  a  telematics  system. -> -> **8   Notices** -> -> Linux  is  a  registered  trademark  of  Linus  Torvalds. -> -> The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. -> -> Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. -> -> Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. -> -> MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. -> -> AirPlay  is  a  trademark  of  Apple,  Inc. -> -> Page  159  of  159 diff --git a/agl-specs-v1.0/00-doorsNG-skimed.md b/agl-specs-v1.0/00-doorsNG-skimed.md deleted file mode 100644 index c5ffbd5..0000000 --- a/agl-specs-v1.0/00-doorsNG-skimed.md +++ /dev/null @@ -1,4203 +0,0 @@ ---- -# Master Header for Jkyll ---- - -![](media/picture8.jpeg)![](media/picture9.jpeg)Version   1.0 -Automotive Grade Linux -Requirements Specification -May   28,   2015 -www.automotivelinux.org -www.linuxfoundation.org -![](media/picture10.jpeg)Automotive Grade Linux Requirements Spec v1.0 -![](media/picture94.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**1   Automotive   Grade   Linux** -1.1  Overview -Automotive  Grade  Linux  (AGL)  is  a  Linux  Foundation  Workgroup  dedicated  to  creating  open -source  software  solutions  for  automotive  applications.  Although  the  initial  target  for  AGL  is  In- -Vehicle-Infotainment  (IVI)  systems,  additional  use  cases  such  as  instrument  clusters  and  and -telematics  systems  will  eventually  be  supported.  AGL  has  participants  from  the  Automotive, -Communications,  and  Semiconductor  Industries  and  welcomes  contributions  from  individual -developers. -By  leveraging  the  over  \$10B  of  investment  made  in  the  Linux  kernel  and  other  open  source -software  projects,  the  AGL  Workgroup: -· -Enables  rapid  software  innovation  for  automotive  suppliers  to  keep  up  with  the  demand -from  consumers  for  better  IVI  experiences -· -Utilizes  the  talents  of  thousands  of  open  source  software  developers  dedicated  to -maintaining  the  core  software  in  areas  like  the  Linux  kernel,  networking,  and -connectivity,  used  in  systems  across  numerous  industries -The  goals  of  the  Automotive  Grade  Linux  Workgroup  are  to  provide: -· -An  automotive-focused  core  Linux  operating  system  stack  that  meets  common  and -shared  requirements  of  the  automotive  ecosystem  with  a  broad  community  of -support  that  includes  individual  developers,  academic  organizations  and  companies. -· -A  transparent,  collaborative,  and  open  environment  for  Automotive  OEMs,  Tier  One -suppliers,  and  their  semiconductor  and  software  vendors  to  create  amazing  in-vehicle -software. -· -A  collective  voice  for  working  with  other  open  source  projects  and  developing  new  open -source  solutions. -· -An  embedded  Linux  distribution  that  enables  rapid  prototyping  for  developers  new  to -Linux  or  teams  with  prior  open  source  experience -This  results  in  faster  time  to  market  by  jump-starting  product  teams  with  reference  applications -running  on  multiple  hardware  platforms. -Page  5  of  159 - - > **Term** > **Definition** - ------------ ------------------------------------------ - > A2DP > Advanced  Audio  Distribution  Profile - > AGL > Automotive  Grade  Linux - > AVRCP > Audio  Video  Remote  Control  Profile - > FS > File  System - > GPS > Global  Positioning  System - > GPU > Graphical  Processing  Unit - -![](media/picture95.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -1.2  Document  Scope -The  scope  of  this  document  is  to  define  the  architecture  of  the  Automotive  Grade  Linux  software -platform.  The  requirements  are  broken  up  into  an  overview  of  the  Architecture  and  a  description -of  each  of  the  layers  in  the  architecture  followed  by  the  requirements  for  each  module  in  the -various  layers.  The  Architecture  Diagram  and  the  layout  of  the  specification  take  into -consideration  all  of  the  components  that  would  be  needed  for  an  IVI  system;  however  the  are -missing  requirements  for  individual  modules.  As  the  spec  continues  to  evolve  those  sections  will -continue  to  be  filled  in. -The  main  goal  of  this  document  is  to  define  the  core  software  platform  from  which  applications -can  be  built.  As  such,  this  document  does  not  define  application  requirements  except  in  a  single -case  (Home  Screen).  Application  requirements  will  be  developed  by  various  projects  that  use  the -AGL  platform.  Those  application  requirements  can  be  used  to  drive  new  or  revised -requirements  into  the  platform. -At  this  time  there  is  no  plan  to  use  this  specification  to  create  a  compliance  or  certification -program.  The  specification  is  used  as  blueprint  to  guide  the  overall  work  of  AGL  and  to  derive -work  packages  for  companies  and  individuals  to  complete  in  order  to  attain  the  goals  of  the  AGL -Workgroup. -1.3  Glossary  of  Terms - - > HFP > Hands  Free  Profile - -------- ------------------------------------- - > IBOC > In-Band  On  Channel - > LTSI > Long  Term  Support  Initiative - > NTP > Network  Time  Protocol - > OEM > Original  Equipment  Manufacturer - > OS > Operating  System - > OSS > Open  Source  Software - > SDL > Smart  Device  Link - > STT > Speech  to  Text - > TTS > Text  to  Speech - -![](media/picture96.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**2   Architecture** -The  Automotive  Grade  Linux  Software  Architecture  diagram  is  below.  The  architecture  consists -of  five  layers.  The  App/HMI  layer  contains  applications  with  their  associated  business  logic  and -HMI.  Generally  applications  are  out  of  scope  for  this  document  since  they  are  product  specific -for  the  OEM  that  is  developing  a  system  based  on  AGL. -The  Application  Framework  layer  provides  the  APIs  for  creating  both  managing  and  running -applications  on  an  AGL  system.  The  Services  layer  contains  user  space  services  that  all -applications  can  access.  The  Operating  System  (OS)  layer  provides  the  Linux  kernel  and  device -drivers  along  with  standard  OS  utilities. -Page  7  of  159 -![](media/picture97.jpeg)![](media/picture98.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**3   App/HMI   Layer** -Applications  may  use  a  web  based  framework  or  a  native  framework.  A  system  may  include -applications  that  use  different  frameworks.  Coordination  of  applications  between  frameworks  is -performed  by  the  AGL  App  Framework.  The  diagram  represents  possible  applications  that  could -appear  in  a  given  system,  but  is  not  all  inclusive.  Reference  applications  may  be  provided  by  AGL -Page  8  of  159 -![](media/picture99.jpeg)![](media/picture100.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  demonstrate  the  capabilities  of  the  platform. -3.1  Home  Screen -Home  Screen  provides  the  Home  User  Interface  (Home  UI)  of  the  system  which  meets  the -following  requirements: -· Rich  User  Experience  (Rich  UX) -· Driver  Distraction  mitigation -· Variations  support -Rich  UX  covers  requirements  such  as  usability  and  user  satisfaction.  Driver  Distraction  mitigation -covers  requirements  on  display  control  and  user  operation  behavior  while  vehicle  is  in  motion  to -minimize  driver  distraction.  Variations  support  covers  requirements  to  support  customization  of -design  and  behavior  of  the  system  to  meet  the  different  needs  of  vehicle  type,  destination  and -grade. -**3.1.1  Layout** -The  following  use  cases  are  considered  for  Layout. -· -Home  Screen  developer  changes  the  Home  UI  by  using  a  customizable  layout  definition. -Page  9  of  159 -![](media/picture101.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**3.1.2  System  UI  Parts** -The  use  case  assumed  about  System  UI  Parts  is  as  follows. -· -An  application  or  System  uses  status  bar  and  on-screen  in  order  to  notify  information  to -a  user. -· -User  uses  the  system  setting  UI  in  order  to  change  settings. -· User  uses  software  keyboard  in  order  to  input  characters. -**3.1.3  Application  Management** -The  use  case  assumed  about  Application  Management  is  as  follows. -· -A  user  downloads  and  installs  or  updates  the  delivery  application  from  application  store. -· A  user  uninstalls  the  delivery  application. -· -A  user  launches  the  installed  delivery  application  or  the  pre-installed  application. -· Also  a  user  terminates  those  applications. -**3.1.4  Application  Switch** -The  use  case  assumed  about  Application  Switch  is  as  follows. -· -User  switches  application  via  application  history  or  application  stack. -· -The  system  switches  application  according  to  Driving  Mode  status. -**3.1.5  Application  History** -Application  switching  by  application  history  is  assumed  as  follows. -· -The  system  records  the  order  of  the  applications  in  the  order  in  which  the  application  is -displayed. -· -The  order  of  application  that  is  recorded  is  updated  each  time  the  display  of  the -application  is  switched. -· -Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the -history  at  the  time  of  switching  applications. -Page  10  of  159 -![](media/picture102.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -‑  Specification  of  operation --  User  runs  a  swipe  from  the  edge  of  the  application  screen  area. -‑  Specification  of  action --  The  order  of  the  screen  is  managed  order  management  list  (application  history). --  List  order  update  opportunity(Update  has  determined  a  display  of  the  application) --  Application  starts  or  stops. --  Allowed  to  stand  between  the  screen  N  seconds  after  the  swipe. -‑"N  seconds"‑User  defines  the  value  of  any. --  User  to  operate  the  screen  after  you  swipe. -‑"operation"‑Screen  tap.  Menu  display.  Other. -Figure  5‑2  represents  a  sample  Home  Screen  depicting  the  above  mentioned  use  cases. -Page  11  of  159 -![](media/picture103.jpeg)![](media/picture104.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**3.1.6  Application  Stack** -Application  switching  by  application  stack  is  assumed  as  follows. -· -The  user  specifies  the  type  of  any  order.  The  system  records  the  order  of  the  application -to  the  rule  as  of  the  specified  type. -· Examples  of  the  types  of  any  order -· Application  start-up  order -· -Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the  stack -Page  12  of  159 -![](media/picture105.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -when  switching  applications. -‑  Specification  of  operation -· -User  runs  a  swipe  from  the  edge  of  the  application  screen  area. -‑  Specification  of  action -· -The  order  of  the  screen  is  managed  order  management  list  (application  stack). -· -List  order  update  opportunity.(Application  start-up  order  as  an  example) -· -Application  that  started  at  the  end  of  the  list  when  the  application  is  started  is  added. -· -Application  that  has  stopped  from  the  list  when  the  application  is  stopped  will  be -deleted. -Figure  5-3  represents  the  switching  example  depicting  the  application  of  the  above  switching. -Page  13  of  159 - - -------------------------------------------------------------------------------------- - > **No** > **Use  Case** > **Role** > **Description** - ---------- ----------------- --------------- ----------------------------------------- - > 1-1 > Layout > GUI  Layout > Function  to  define  a  customizable - > > - > definition > GUI  Layout  definition. - -------------------------------------------------------------------------------------- - -![](media/picture106.jpeg)![](media/picture107.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**3.1.7  Role  of  Home  Screen** -Table  5-1  describes  the  role  of  the  Home  Screen  to  satisfy  the  purpose  and  use  cases -Page  14  of  159 - - ---------------------------------------------------------------------------------------------------- - > 1-2 > Change  Layout > Function  to  apply  the  customized - > - > GUI  layout  definition. - ------- --------------------- ------------------------ --------------------------------------------- - > 2-1 > System  UI  Parts > Status  Bar > Function  to  display  the - > - > information  from  application  or - > - > system. - > - > Function  to  quickly  access  and  set - > - > certain  system  settings. - - > 2-2 > On-screen > Function  to  display  a  popup - > - > window  such  as  alert  messages. - - > 2-3 > System  Setting > Function  to  display  system - > - > settings  menu  regarding  GUI, - > - > such  as  locale  and  network. - - > 2-4 > Software > Function  to  display  software - > > - > Keyboard > keyboard. - - > 3-1 > Application > Application > Function  to  download - > > > - > Management > Management > applications  from  application - > - > store.  Function  to  install,  uninstall - > - > and  update  the  downloaded - > - > applications. - - > 3-2 > Application > Function  to  launch/terminate - > > - > Launcher > applications. - - > 4-1 > Application > Application  List > Function  to  switch  applications  by - > > - > Switch > installed  application  list. - - > 4-2 > Application  History > Function  which  switches - > - > application  in  order  by - > - > applications  history. - - > 4-3 > Application  Stack > Function  to  switch  application  in - > - > any  order. - ---------------------------------------------------------------------------------------------------- - -![](media/picture108.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Table  5-2:  Relevance  of  the  Role  and  Purpose** -Page  15  of  159 - - ----------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Rich  UX** > **Driver** > **Variations** - > > - > **Distraction** > **support** - > - > **mitigation** - ----------- --------------------------- ---------------- ------------------- ------------------ - > 1-1 > GUI  Layout  definition > ‑ > ‑ > ‑ - - > 1-2 > Change  Layout > ‑ > ‑ > ‑ - - > 2-1 > Status  Bar > ‑ > ‑ - - > 2-2 > On-screen > ‑ > ‑ - - > 2-3 > System  Setting > ‑ > ‑ - - > 2-4 > Software  Keyboard > ‑ > ‑ - - > 3-1 > Application  Management > ‑ > ‑ - - > 3-2 > Application  Launcher > ‑ > ‑ - - > 4-1 > Application  List > ‑ > ‑ - - > 4-2 > Application  History > ‑ > ‑ - - > 4-3 > Application  Stack > ‑ > ‑ - ----------------------------------------------------------------------------------------------- - -![](media/picture109.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**3.1.8  Requirements** -**3.1.8.1  Layout** -Home  Screen  must  provide  a  mechanism  for  customizable  GUI  layout  definition  by  each  vehicle -type,  each  destination  and  each  grade. -Home  Screen  must  provide  a  mechanism  for  a  customizable  GUI  layout  definition  for  different -vehicle  type,  destination  and  grade. -GUI  layout  definitioncan  be  definedsuch  as  the  following  items: -(In  addition,  items  that  can  be  defined  is  not  limited  to  the  following.) -· screen  resource  (Display,  Layer  Type,  Area) -Page  16  of  159 -![](media/picture110.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· sound  resource  (Zone,  Sound  Type) -· input  resource  (Device,  Event  Type) -· UI  Component  to  be  used  in  the  entire  system -· transition  effect  (Animation  effect) -· Background  image -Home  Screen  must  provide  a  mechanism  to  apply  customized  GUI  layout  definition. -**3.1.8.2  System  UI  Parts** -Home  Screen  must  provide  a  mechanism  to  display  two  or  more  information  simultaneously  to -the  status  notification  area. -Home  Screen  must  provide  a  mechanism  to  displaying  status  to  status  notification  area. -· Current  Time:  Displaying  clock  capability -· -Icons  of  Status:  Displaying  icons  for  notify  information  from  applications -· -Status  Message:  Displaying  text  for  notify  information  from  applications -· -Communication  Status:  Status  of  mobile  communication  and  wireless  communications -(Wi-Fi,  Bluetooth,  etc.) -Home  screen  must  provide  an  interface  to  retrieve  information  from  application  for  notification. -Home  Screen  must  provide  a  mechanism  to  show  popup  window  into  on-screen  window. -Home  Screen  must  provide  GUI  method  to  hide  on-screen  window  by  user  operation. -Home  Screen  must  provide  a  mechanism  to  hide  on-screen  window  within  a  specified  duration. -Home  Screen  must  provide  an  interface  for  applications  to  request  to  show  popups. -Home  Screen  must  provide  an  interface  for  applications  to  cancel  the  previously  requested -popup. -Page  17  of  159 -![](media/picture111.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Home  Screen  must  provide  a  mechanism  to  show  text  information,  draw  images  and  show -software  switch  like  button  in  the  on-screen  window. -Home  Screen  must  provide  a  mechanism  to  specify  attributes  such  as  position  and  size  of  On- -screen  window. -Home  Screen  must  support  a  mechanism  to  specify  other  window  display  effect  when  the  On- -screen  window  is  displayed.  (e.g.  tone  down) -Home  Screen  must  provide  system  setting  menu  regarding  GUI,  such  as  locale  and  network. -Home  Screen  must  provide  a  mechanism  to  change  current  date  and  time  setting. -Home  Screen  must  provide  a  mechanism  to  change  timezone  setting. -· -The  platform  must  set  up  the  date,  time  and  timezone  according  to  a  current  position -automatically. -· -Home  Screen  must  provide  a  mechanism  to  set  up  turning  on  and  off  of  the  automatic -date/time/timezone  setup. -Home  Screen  must  provide  a  mechanism  to  change  language  setting. -Home  Screen  must  provide  a  mechanism  to  change  wireless  communications  (Wi-Fi,  Bluetooth, -etc.)  setting. -· Enable/Disable -· Connect/Disconnect -· Search  the  devices -· Display  the  list  of  available  and/or  registered  devices -Home  Screen  must  provide  a  mechanism  to  change  mobile  communication  setting. -· Enable/Disable -Page  18  of  159 -![](media/picture112.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· A  setup  and  change  of  various  attributes -· Display  the  list  of  registered  devices  and  select  device -HomeScreen  must  support  to  change  the  appearance  of  a  screen  to  a  user's  liking. -These  are  as  follows. -· Tone  of  a  screen. -· Appearance  of  a  window  frame. -· Animation  effect  when  screen  transition  was  occurred. -Home  Screen  must  support  a  mechanism  to  set  or  change  master  audio  volume. -Home  Screen  must  support  a  mechanism  to  set  or  change  display  brightness. -Home  Screen  must  provide  a  mechanism  to  show  software  keyboard. -Home  Screen  must  provide  a  mechanism  to  apply  default  settings  (e.g.  theme,  local,  wallpaper) -to  a  new  user,  when  a  user  is  added  by  the  User  Manager. -**3.1.8.3  Application  Management** -Home  Screen  must  provide  a  mechanism  to  manage  downloaded  application  package. -· Display  downloaded  application  list  from  application  store. -· Download  the  application -· Install  the  downloaded  application -· Uninstall  the  downloaded  application -· Update  the  downloaded  application -Home  Screen  must  provide  a  mechanism  to  launch  the  application. -Home  Screen  must  provide  a  mechanism  to  terminate  the  application. -Page  19  of  159 -![](media/picture113.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**3.1.8.4  Application  Switch** -Home  Screen  must  provide  a  mechanism  to  show  the  list  of  installed  applications. -Examples  of  assumed  application  list -· list  of  application  name -· list  of  application’s  icon -· list  of  live  thumbnail  for  all  the  running  applications -Home  Screen  must  provide  a  mechanism  for  switching  display  application  in  order  by  application -history. -Home  Screen  must  provide  a  mechanism  for  the  application  stack  in  any  order.  For  example, -such  as  launch  order  or  display  order. -Home  Screen  must  provide  a  mechanism  for  the  system  to  switch  applications. -For  example,  when  Driving  Mode  changes,  system  must  be  able  to  switch  application  based  on -policy. -**4   Application   Framework   Layer** -The  Application  Framework  layer  provides  the  methods  needed  to  create  software  applications -and  their  user  interfaces.  The  platform  can  support  multiple  application  frameworks  any  of -which  may  be  built  into  an  SDK  or  product  build.  The  application  framework  contains  any  code -specifically  written  for  that  framework  as  well  the  bindings  to  the  Services  and  Operating -Systems  layers  that  the  application  framework  provides  for  its  applications. -4.1  AGL  Application  Framework -The  AGL  Application  Framework  provides  basic  services  to  all  applications  regardless  of  the -framework  they  are  implemented  in  so  that  there  is  a  standard  method  providing  the  services. -Page  20  of  159 -![](media/picture114.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**4.1.1  Application  Manager** -Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application -lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. -**4.1.1.1  Requirements** -AGL  System  must  support  application  lifecycle  (install/uninstall,  launch/kill,  suspend/resume)  based  on -appid/pid  via  launcher. -AGL  System  must  support  a  database  to  store  application  metadata  (appid,  exec  path  etc.). -AGL  System  must  provide  an  interface  to  get  a  list  of  installed  applications. -AGL  System  must  provide  an  interface  to  get  the  state  of  an  application. -AGL  System  must  provide  application  privilege  control. -**4.1.2  Window  Manager** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user  interface.  A -window  system  is  responsible  for  managing  display  devices,  Graphics  Processing  Units  (GPUs),  input -devices,  and  graphics  memory.  A  window  system  works  with  the  software  component  named  window -manager  that  is  responsible  for  a  layout  management  of  windows,  and  a  routing  of  user  interactions. -A  window  manager  is  as  software  component  that  is  responsible  for  a  layout  management  of -windows. -Window  manager  of  automotive  middleware  layer  makes  up  for  traditional  window  management -system  to  be  satisfied  IVI’s  complex  requirements,  typically  requested  from  Policy  Manager. -Also,  AGL  aims  to  provide  well-portability  among  various  hardware  platforms. -Page  21  of  159 - - -------------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- ----------------------------- -------------------------------------------------------------- - > 1 > Window  drawing > Provide  capability  to  draw  a  window  to  any  place - > - > and  any  size  and  any  scale. - > - > Also  provide  capability  to  change  visibility  of  the - > - > window. - - > 2 > Overlay  of  multiple > Provide  capability  to  overlay  two  or  more  windows - > > - > windows > with  any  z-order. - > - > Also  provide  capability  to  use  hardware  layer - > - > efficiently. - - > 3 > Visual  effect > Provide  capability  to  adapt  visual  effect  as  below. - > - > ·     Animation  effect  to  change  visibility - > - > ·     Animation  effect  to  transit  between  two  or - > - > more  windows - > - > ·     Visual  effect  for  a  window,  such  as  gray-out - > - > and  transparent. - - > 4 > Frame  rate  control > Provide  capability  to  control  dynamic  frame  rate - > - > change.  This  is  useful  if  system  resource  was - > - > shortage. - - > 5 > Multiple  hardware  layer > Provide  capability  to  use  hardware  layer  efficiently - > > - > support > if  hardware  supports  two  or  more  hardware  layers. - -------------------------------------------------------------------------------------------------------- - -![](media/picture115.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**4.1.2.1  Use** **Case** -Please  refer  “screen  resource  control”  of  Policy  Manger  section. -**4.1.2.2  Role** -Table  7-148  describes  the  role  of  window  manager  to  be  satisfied  above  purpose  and  use -cases. -Page  22  of  159 - - ---------------------------------------------------------------------------------------------- - > 6 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce - > > - > hardware > dependency  of  hardware.  Well-defined  interface - > - > also  makes  it  possible  to  increase  the  effect  of - > - > portability  and  development  cost. - ----- --------------------------- ------------------------------------------------------------ - > 7 > Multi  window  /  multi > Support  multi  window  management  and  multi - > > - > display > display. - - > 8 > Compatibility > From  the  compatibility  point  of  view,  AGL  should - > - > use  public  API,  and  shall  not  rely  on  hardware - > - > specific  API. - ---------------------------------------------------------------------------------------------- - -![](media/picture116.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**4.1.2.3  Requirements** -4.1.2.3.1  Window  Drawing -System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and -make  invisible. -System  must  provide  a  mechanism  to  create  and  delete  surface. -When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. -This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. -System  must  provide  a  mechanism  to  change  visibility  per  each  surface. -And,  provide  an  interface  to  change  visibility. -All  the  surfaces  must  be  set  to  invisible  for  initial  state. -Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. -System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between -previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. -*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt -Page  23  of  159 -![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -from  size  of  surface. -If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  squeeze. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  using  combination  of  scaling  and  trimming  function. -That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  using  combination  of  scaling  and  background  color. -That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This -mechanism  makes  it  possible  to  do  “letterbox”  method. -4.1.2.3.2  Overlay  of  Multiple  Windows -System  must  provide  a  mechanism  to  create  and  delete  a  layer. -Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by -their  z-order  attribute. -Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, -then,  attached  layer  must  be  changed. -System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. -Area  is  a  concept  which  defines  where  to  display  in  specific  layer. -System  must  provide  a  mechanism  to  attach  surface  to  any  layer. -Also,  system  must  be  able  to  change  attached  layer. -And,  provide  an  interface  to  attach  and  change. -Page  24  of  159 -![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. -And,  provide  an  interface  to  assign  surface  to  any  area. -System  must  provide  a  mechanism  to  change  visibility  per  each  layer. -That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the -same  time. -And,  provide  an  interface  to  change  visibility  per  layer. -Initial  state  must  be  set  to  invisible. -System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each -layer,  and  disposition  of  surfaces. -4.1.2.3.3  Visual  Affect -System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was -happened. -Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -- Duration -Animation  type -System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -out. -Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -plug-in  architecture. -System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. -Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -· Duration -Animation  type -System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -Page  25  of  159 -![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -out. -Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -plug-in  architecture. -System  must  provide  a  mechanism  to  make  effect  to  surface. -And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. -System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. -System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness -System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in -architecture. -4.1.2.3.4  Frame  Rate  Control -System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of -application. -System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval -of  application. -This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live -thumbnail  and  moving  surface. -4.1.2.3.5  Multiple  Hardware  Layer  Support -If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use -hardware  layers  efficiently. -· -Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers -Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback -4.1.2.3.6  Reduced  Dependency  of  Hardware -Page  26  of  159 -![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of -each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, -such  as  by  using  re-configuration. -4.1.2.3.7  Multi  Window -AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple -processes  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. -4.1.2.3.8  Compatibility -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a -standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any -hardware  specific  API. -A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. -**4.1.3  Policy  Manager** -**4.1.3.1  Overview** -4.1.3.1.1  Purpose -Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy -Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle -Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of -resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called -Page  27  of  159 -![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -“System  resources”  such  as  CPU  and  memory. -4.1.3.1.2  GUI  Resources -(1)  Definition -·  About  Control  of  GUI  Resources -AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, -speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user -or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. -**Figure  7-1:  GUI  resources** -Page  28  of  159 -![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy -Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too -much  information  distracts  the  attention  of  driver  from  driving  operations. -·  Associated  Software  Architecture -The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources -control  is  as  below. -**Figure  7-2:  Associated  Software  Expected  Use  Case** -Page  29  of  159 - - ----------------------------------------------------------------------------------------------------------------------------------------------------- - > **No** > **Component** > **Description** - > - > **.** - ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- - > 1 > Homescreen > Request  to  control  of  GUI  resources. - - > 2 > Applications > Request  to  output  or  input  of  GUI  resources. - - > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And - > - > then  provide  the  corresponding  feature  to - > - > applications  UI  such  as  input  limitation  and - > - > changing  the  theme. - - > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the - > - > definition  of  GUI  resources  such  as  role  by - > - > application  configurations. - - > 5- > Vehicle > Window  Manager - > > - > 1 > Info - > - > Control - - > 5- > Sound  Manager - > - > 2 - - > 5- > Input  Manager - > - > 3 - - > 5- > Vehicle  Info  Distributor - > - > 4 - - > 5- > User  Manager - > - > 5 - ----------------------------------------------------------------------------------------------------------------------------------------------------- - -![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  is  related  with  the  below  components. -(2)  Role -Page  30  of  159 - - ----------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ------------------------------ ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of - > > - > GUI  resource > GUI  resources. - > - > (2)  Judgment  the  GUI  resource  owner  according  to - > - > external  conditions. - - > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to - > - > judgment. - > - > (2)  Notify  the  driving  mode  and  day  night  mode - > - > that  is  calculated  by  external  conditions. - ----------------------------------------------------------------------------------------------------- - -![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  has  the  below  role. -Page  31  of  159 -![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  7-3:  Definition  of  Role** -GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each -resource  type  are  as  follows: -a.  Screen  Resource -a-1.  External  Condition  Collection -Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. -**Figure  7-4:  Definition  of  screen  resource** -•  Concept  of  Display,  Layer,  Layout  and  Area -AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one -or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout -Page  32  of  159 -![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics -window. -The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on -objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was -used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than -layer-2. -Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, -application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. -“Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and -setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert -and  enlarged  view. -When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On -the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” -layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. -From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- -order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered -by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to -individual  layer. -•  Concept  of  Layer  Owner,  Role  and  Surface -“Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of -that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of -area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy -Manager. -“Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” -change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. -One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics -window  to  display  into  one  area. -Page  33  of  159 -![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface -drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example -to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then -corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface -is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & -scan”. -**Figure  7-5:  Definition  of  Surface** -•  Subdivision  of  “Interrupt”  Layer -Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main -surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main -surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding -“Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message -is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. -According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described -as  Table  7-3. -Page  34  of  159 - - --------------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- -------------------------------------------------------- ----------------------- - > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation - > - > application  requests  this  layer  at  first  time. - - > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of - > - > navigation - - > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message - > > - > screen  service  (e.g.  Homescreen)  requests > popup - > - > this  layer. - - > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard - > > - > keyboard > Typically,  software  keyboard  service - > - > requests  this  layer. - --------------------------------------------------------------------------------------------------------- - - ------------------------------------------------------------------------------------------------------ - > **No** > **Contents** > **Summary** > **Example** - ---------- ---------------- ------------------------------------------------------- ------------------ - > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation - > - > service)  role. - - > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view - ------------------------------------------------------------------------------------------------------ - -![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -a-2.  Judgment  of  Priority  of  GUI  Resource -Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role -is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy -Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. -Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software -Page  35  of  159 -![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is -popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). -**Figure  7-6:  Definition  of  Role  and  Sub  role** -The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display -has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. -In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" -layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub -role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” -role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. -a-3.  GUI  resource  control -Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -directly. -Page  36  of  159 -![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -There  are  three  types  of  screen  resource  control: -One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. -Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was -assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. -Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue -z-order  information  for  each  layer. -b.  Sound  Resource -b-1.  External  Condition  Collection -Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. -**Figure  7-7:  Definition  of  Sound  Resource** -•  Zone -Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can -play  at  the  same  time. -Page  37  of  159 - - ------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- ---------------------------------------------- ------------------------- - > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media - > - > player - - > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of - > - > Navigation - - > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound - > - > requests  this  type. - ------------------------------------------------------------------------------------------------- - -![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -•  Sound  type -Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource -owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper -sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific -zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each -sound  stream  must  assign  to  individual  sound  type. -AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. -•  Stream -Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in -stream. -b-2.  Judgment  of  Priority  of  GUI  resource -Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role -is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy -Manager.  Figure  7-8  describes  the  definition  of  role. -Page  38  of  159 -![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  7-8:  Sample  Role** -The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that -is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or -different  sound  type  are  not  switched.  They  are  mixed. -b-3.  GUI  Resource  Control -Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -directly. -There  are  two  types  of  sound  resource  control: -One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for -sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound -Page  39  of  159 -![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -stream  and  to  start  play  latest  area  owner. -Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback -simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy -Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and -music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music -playback. -c.  Input  Resource -c-1.  External  Condition  Collection -Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. -**Figure  7-9:  Definition  of  Input  Resource** -•  Device  Name -Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. -•  Event  Type -Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and -temperatures. -c-2.  Judgment  of  Priority  of  GUI  resource -Page  40  of  159 -![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device -name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy -DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the -judgment  as  below. -**Figure  7-10:  Definition  of  routing  rule** -OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. -c-3.  GUI  Resource  Control -Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. -Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. -4.1.3.1.3  System  Resources -(1)  Definition -Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy -Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. -Page  41  of  159 - - ---------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ----------------------------- ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according - > - > to  external  condition  change. - > - > 2.  Kill  process(s)  forcibly  according  to  external - > - > condition  change. - ---------------------------------------------------------------------------------------------------- - -![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, -target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. -**4.1.3.2  Requirements** -4.1.3.2.1  Screen  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system -uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive -information  must  include  as  follows. -a.  ID -b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) -c.  DPI -d.  Connected  ECU -Page  42  of  159 -![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be -able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list -according  to  current  layout  of  each  display. -The  receive  definition  must  include  the  follows. -a.  ID -b.  Area  list -System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface -by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the -device. -The  receive  request  must  include  the  follows. -a.  Layout  ID -b.  ID -c.  Area  position  (Coordinate  of  the  upper-left) -d.  Area  size  (Length  \*  Width) -System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify -the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. -a.  Display  ID -b.  Layout  ID -System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the -providing  resource  using  it  when  the  request  is  collision. -The  receive  information  must  include  the  follows. -a.  Role -b.  Priority -System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge -driving  mode. -The  receive  information  must  include  the  follows. -a.  Velocity -Page  43  of  159 -![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Brake  status -System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge -day  night  mode. -The  receive  information  should  include  the  follows. -a.  The  brightness  of  the  interior -System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the -providing  resource  using  it. -System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should -judge  the  providing  resource  using  it. -(2)  Judgment  of  Priority  of  GUI  Resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical -resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the -resource. -The  receive  request  must  include  as  follows. -a.  Role -b.  Layer  type -The  receive  request  should  include  as  follows. -c.  Display  ID -System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by -priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on -the  specified  area  on  the  specified  layer. -The  receive  request  must  include  as  follows. -a.  Role -Page  44  of  159 -![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Layer  ID -The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. -Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the -related  basic  type  area. -c.  Area  ID -**Figure  7-11:  Sequence  to  display** -System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. -In  this  request,  requester  should  choose  below  options. -a. -Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, -but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should -be  refused. -b. -Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen -resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher -priority,  then,  only  screen  resource  should  be  assigned  to  requester. -Page  45  of  159 -![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system -running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. -The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal -request. -a.  Effective  period  (Can  set  unlimited) -System  should  not  raise  the  other  surface  above  its  during  effective  period. -System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -a.  The  effect  at  the  transition -b.  The  effect  of  display  surface -System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are -sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all -layers  will  be  superimposed  by  z-order. -System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. -System  must  hide  the  surface  that  has  too  much  information. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Visible  /  Invisible -b.  Change  position -c.  Raise -The  receive  request  must  include  as  follows. -i.  Surface  ID  \*Only  case  of  visible. -ii.  Display  ID  \*Only  case  of  visible. -iii.  Layer  ID  \*Only  case  of  visible. -Page  46  of  159 -![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. -v.  Size  (Length  \*  Width)  \*Only  case  of  visible. -System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. -a.  The  effect  at  the  transition -b.  The  effect  of  display  surface -4.1.3.2.2  Sound  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone -information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as -follows. -a.  ID -b.  Sound  device  ID -System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses -sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must -include  as  follows. -a.  ID -(2)  Judgment  of  Priority  of  GUI  resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -request  during  system  running. -Page  47  of  159 -![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  receive  request  must  include  as  follows. -a.  Role -b.  Zone  ID -c.  Sound  type  ID -System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during -system  running. -The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal -request. -a.  Effective  period  (Can  set  unlimited) -System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner -by  other  request  on  same  area  during  effective  period. -System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -a.  The  effect  at  the  transition -b.  The  effect  of  output  sound -System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more -resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority -of  resources  that  is  related  to  role. -\*  Boundary  of  the  role  between  Policy  Manager  and  application. -Page  48  of  159 -![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Figure  7-12:  Boundary  of  role  (Case  of  reverse) -System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system -should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. -For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound -from  request  history  based  on  the  priority. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Mute  /  Unmute -b.  Change  zone -The  receive  request  must  include  as  follows. -i.  Stream  ID -ii.  Device -In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. -iii.  Channel  ID -Page  49  of  159 -![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. -a.  The  effect  at  the  transition -b.  The  effect  of  output  sound -4.1.3.2.3  Input  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses -input  device  information  with  to  control  input  event  to  other  system.  The  receive  information -must  include  as  follows. -a.  ID -System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses -input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must -include  as  follows. -a.  ID -b.  Related  event  IDs -(2)  Judgment  of  Priority  of  GUI  resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -request  during  system  running. -The  receive  request  must  include  as  follows. -a.  Input  device  ID -Page  50  of  159 -![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Event  type  ID -System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the -limitation  routing  rule  of  policy  DB. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Set  the  routing  rule -The  receive  request  must  include  as  follows. -i.  Input  device  ID -ii.  Event  type  ID -The  receive  request  must  include  either  as  follows. -iii.  The  allowed  application -iv.  The  denied  application -System  should  provide  a  mechanism  to  set  the  following  information. -a.  Application  that  has  active  surface -System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This -feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen -changes  the  active  surface. -4.1.3.2.4  System  Resources -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager -to  decide  proper  system  resource. -Page  51  of  159 -![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  must  detect  creation  and  deletion  of  process. -To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created -process. -Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to -other  active  processes. -To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to -identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each -active  process. -Policy  Manager  must  detect  current  memory  consumption  periodically. -To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each -process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were -thought  as  not  so  important  process. -Policy  Manager  must  detect  current  CPU  consumption  periodically. -To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep -system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected -busy  state. -System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. -Application  status  includes  as  below. -· GUI  resource  status,  such  as  foreground  or  background. -· -Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must -resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last -application  to  resume  quickly  as  much  as  possible. -(2)  System  Resource  Control -System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process -group  according  to  external  conditions. -According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to -target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups -Page  52  of  159 -![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -will  be  used) -System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. -4.1.3.2.5  Resource  Management -Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy -Manager,  Connection  Manager. -Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. -Each  resource  request  shall  be  in  form  a: -AppID, -SourceID, -RequestorZoneID, -NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), -Required  Resource  List. -Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin -Speakers,  HeadPhones) -Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) -Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, -Tuners  etc.) -Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request -from  resource  requestors. -Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. -Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) -Page  53  of  159 -![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list -are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) -Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system -through  status  update. -Resource  Management  shall  support  stacking/queuing  of  resource  requests. ->  Receive  the  requests  from  the  resource  requestors. ->  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy -Manager. ->  Add  the  validated  requests  into  a  priority  queue. ->  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. ->  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it -shall  be  removed  from  the  queue. -Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier -request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it -shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. -If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the -requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. -If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant -some/all  of  the  resources  requested  by  the  requestor. -Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an -existing  resource  request. -Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of -policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs -for  the  policy  decision: ->  Currently  Free  or  InUse  Sink  status ->  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) -Page  54  of  159 -![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 ->  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. -Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a -request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the -policy  decision: ->  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept -pending. ->  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. -At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by -resource  requestor: ->  Zone  ID ->  Allocated  Source  Instance ->  Allocated  Sink  Instance ->  Mute  status -Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality -(e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to -the  resource  management  policy. -Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature -functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). -Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: -AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have -same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, -the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. -Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, -AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource -request  will  be  the  one  that  is  granted  the  resource. -A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. -It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. -Page  55  of  159 -![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. -It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource -Manager  if  the  resource  is  no  longer  needed. -Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all -available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once -the  request  is  granted  against  the  set  policy. -Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. -Possible  connection  states  are  Active  or  Passive. ->  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be -active. -Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. ->  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be -passive. -Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same -AMFM  source  on  Rear  headphone  sink. -Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink -connection  using  the  underlying  platform  support. -Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink -connection  using  the  underlying  platform  support. -Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is -removed/released. -Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is -re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. -Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. -Page  56  of  159 -![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready -to  be  used  for  audio  routing. -Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio -routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. -Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. -Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which -source  instance. -Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: ->  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. -System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -Headphones  shall  not  be  required  to  support  any  foreground  sinks. -In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a -source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source -(if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). -As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not -disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background -connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. -Page  57  of  159 -![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State -Manager. -It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. -It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on -current  system  scenario. -E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call -is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a -pending  request. -It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. -It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. -It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video -resources  and  update  its  internal  status  accordingly. -On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active -connections  and  reconnect  or  disconnect  if  required. -E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. -Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of -connections  shall  be  rebuilt  with  Amp. -It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. -Page  58  of  159 -![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying -platform  support. -It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the -underlying  platform  support. -It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. -It  shall  provide  an  interface  to  unmute  an  audio  sink. -System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -Headphones  shall  not  be  required  to  support  any  foreground  sinks. -It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -**4.1.4  Sound  Manager** -A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from -two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a -policy  manager  manages  a  mediation  rule. -Page  59  of  159 - - ---------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ------------------------------------------------------------ - > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). - - > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume - > - > control  of  each  sound  streams. - - > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, - > - > ·     When  changing  sound  stream.  E.g.  fade-in, - > - > fade-out  and  cross-fade. - - > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce - > > - > hardware > dependency  of  hardware.  Well-defined  interface - > - > also  makes  it  possible  to  increase  the  effect  of - > - > portability  and  development  cost. - ---------------------------------------------------------------------------------------------------- - -![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a -passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound -resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. -Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like -volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server -to  implement  automatic  audio  policies. -**4.1.4.1  Use  Case** -Please  refer  “sound  resource  control”  of  Policy  Manger  section. -Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. -**4.1.4.2  Requirements** -Page  60  of  159 -![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4.1.4.2.1  Routing  Sound  Streams -System  must  provide  a  mechanism  to  manage  sound  “zone”. -Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a -zone  and  how  to  manage  zone. -System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each -channels  of  each  sound  device. -One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists -of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. -For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is -arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when -outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower -musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than -music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound -device. -The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more -zones. -Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the -present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the -mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. -System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. -System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. -All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. -System  must  provide  a  mechanism  to  control  sound  stream. -Control  of  a  sound  stream  is  as  follows. -· -Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound -stream. -· -Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound -Page  61  of  159 -![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -stream. -Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. -4.1.4.2.2  Mixing  Level  Control -The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to -the  same  zone  according  to  a  policy  manager's  arbitration. -System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. -System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream -requested  to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating -the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. -System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested -to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted -sound  stream  was  ended. -System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream -requested  to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound -stream  was  ended. -4.1.4.2.3  Sound  Effect -When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. -System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. -System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin -architecture. -Page  62  of  159 - - ------------------------------------------------------------------------------------------------------------------------- - > **No.** > **Input  type** > **Associated  device** > **Description** - ----------- ------------------- -------------------------- -------------------------------------------------------------- - > 1 > Key > Steering  switch > Simple  key  event. - > - > Deliver  to  application. - - > 2 > Keyboard > Virtual  keyboard > Keyboard  event. - > - > Deliver     to     application,     then     use     input - > - > method  backend  if  needed. - - > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. - > - > Also  supports  double  click  and  multi-touch - > - > capability. - > - > Deliver  to  application. - - > 4 > Sound > Microphone > Sound  input. - ------------------------------------------------------------------------------------------------------------------------- - -![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4.1.4.2.4  Reduced  Dependency  of  Hardware -Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels -of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means -which  does  not  need  rebuild  of  systems,  such  as  a  configuration. -**4.1.5  Input  Manager** -The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application -depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each -input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering -switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. -**4.1.5.1  Use  Case** -Please  refer  “input  resource  control”  of  Policy  Manger  section. - - --------------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ----------------------------------------------------------------- - > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to - > - > application  readable  event  name,  such  as  “volume - > - > up”  and  “right  arrow”. - - > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified - > - > application. - --------------------------------------------------------------------------------------------------------- - -![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Deliver  to  application  or  voice  recognition -engine. -Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. -**4.1.5.2  Requirements** -**4.1.5.3  Abstract  Device  Event** -System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. -Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional -equipment. -**4.1.5.4  Event  Delivery** -System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. -System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” -and  “destination  application  id”. -Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by -UIM.2.1.2. -Page  64  of  159 -![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. -System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. -System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on -delivery  rule  defined  in  UIM.2.1.1. -System  must  provide  a  mechanism  to  inhibit  any  event  delivery. -This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. -**4.1.6  User  Manager** -**4.1.6.1  Use  Case** -**4.1.6.2  Personal  Identification** -User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a -person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. -**4.1.6.3  User  Preference** -Multi-user  environment  provides  same  user  experience  for  each  user. -Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including -other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data -sharing  from  your  home  and  your  office. -Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be -provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. -Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user -experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, -*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is -Page  65  of  159 -![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. -**Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** -**4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** -When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If -Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is -important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s -preference. -**Figure  7-25  :  User  data  sharing  between  cars** -Page  66  of  159 -![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**4.1.6.5  Seamless  Data  Sharing** -Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and -smart-phones,  home  networks  and  accessing  from  your  offices. -**Figure  7-26  :  User  data  sharing  over  the  cars** -**4.1.6.6  Role** -**Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above -purpose  and  use  cases. -**Table  7-17  :  Role  of  User  Manager** -**No.** **Role** **Description** -Page  67  of  159 -![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -1 User  identification -Provide  a  mechanism  to  identify  user,  such  as  user -name  and  password  pair,  smart  key  and  biometrics. -Provide  a  mechanism  to  log-in  to  the  IVI  system  as -a  specified  user. -When a different user logs in, proper user -preference  for  the  user  must  be  applied,  and -resume  last  state  of  corresponding  user. -Also,  each  application  can  store  application’s  data -per  user.  In  such  cases,  proper  user  data  must  be -applied  when  a  different  user  logs  in. -2 User  preference -Provide  a  mechanism  to  apply  user  preference  of -logged-in  user. -User  preference  includes  the  following  data. -· User  interface,  such  as  locale  and  wall- -paper. -· Resume  last  application’s  status  of  specified -user. -· Application  specific  data. -3 User  data  management -Provide  a  mechanism  to  manage  cloud  based  user -data. -The  following  capabilities  are  required. -· Download  user  data  of  the  logged-in  user -from  the  cloud. -· Update  cloud  data  if  the  user  data  was -updated  by  user  operation  or  otherwise. -· Periodically  sync-up  w/  cloud  because  user -data  may  be  updated  by  other  devices. -In  addition  to  the  above  basic  capabilities,  user  data -cache  is  essential  for  a  car,  since  a  car  may  not -always  have  a  reliable  network  connection. -4 Security Because  cloud  based  sharing  user  data  may  be -accessed  from  any  place,  user  data  must  be -protected  from  unexpected  data  access. -Page  68  of  159 -![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -So,  IVI  system  must  provide  security  mechanism -regarding  accessing  to  cloud  based  user  data. -**4.1.6.7  Requirements** -4.1.6.7.1  User  Identification -System  must  provide  a  mechanism  to  identify  logged-in  user. -System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to -identify  logged-in  user. -System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For -example,  using  NFC. -System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. -4.1.6.7.2  User  Preference -When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the -currently  logged-in  user. -System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. -- Locale  settings -- UX  theme -Wall  paper -System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized -user  experience. -Page  69  of  159 -![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in -user’s  application  data  automatically. -When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last -status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the -system.  Specifically,  last  status  includes  the  following. -- Foreground  applications.  That  means  displayed  applications. -Background  applications. -When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. -System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. -System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. -4.1.6.7.3  User  Data  Management -System  must  provide  a  mechanism  to  manage  user  data. -AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user -preference. -User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but -also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and -home  electronics. -System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to -application  by  using  cloud  based  user  data. -System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data -of  the  IVI  system. -When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to -the  cloud. -Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide -Page  70  of  159 -![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. -Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a -mechanism  to  cache  downloaded  user  data. -If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as -possible. -4.1.6.7.4  Security -Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to -protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. -System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. -- -System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must -authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, -smartphone  or  PC. -- -System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. -- -System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection -against  falsification  of  data  from  unauthorized  access  or  illegal  access. -- -Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide -user  data  only  to  the  authorized  user. -Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must -provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to -include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against -cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. -4.2  Web  HMI -Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. -**4.2.1  Web  API** -Page  71  of  159 -![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service -function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio -visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, -Photo,  etc.) -Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of -Audio  Visual  API  is  shown  in  Figure  6-1. -**Figure  6-1:  Use  case  of  Audio  Visual  API** -**4.2.1.1  Requirements** -Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. -· Select  content  using  URL -· -Select  content  using  contents  list  provided  by  multimedia  subsystem -Page  72  of  159 -![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, -DVD,  BT-Audio,  Photo,  etc.) -· Play -· Pause -· Fast-forward -· Rewind -· Track  up -· Track  down -· Select  playmode  (Repeat/Random) -Audio  Visual  API  must  provide  API  to  control  a  volume. -· Volume  up -· Volume  down -· Mute -Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. -Audio  Visual  API  must  provide  API  for  notifications. -· The  case  that  playback  state  is  changed -· The  case  that  Audio  Visual  contents  is  add  /  removed -Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. -· Change  the  frequency. -· Change  the  broadcasting  stations. -· Receive  the  list  of  broadcasting  stations. -· Select  the  preset  channel. -· Get  the  information  of  the  broadcasting  station. -Audio  Visual  API  must  provide  API  to  play  digital  radio. -· Store  the  broadcast  program  information. -Page  73  of  159 -![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Get  the  broadcast  program  information. -· Get  the  play  time. -· Play  the  radio  broadcast  cached. -AGL  System  must  support  a  web  API  to  access  Vehicle  information. -AGL  System  must  support  web  API  to  control  STT/TTS  daemon. -AGL  System  must  support  web  API  to  control  navi  engine. -AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web -apps. -AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app -and  a  native  app. -AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider -should  be  able  to  restrict  subscriber. -AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. -AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, -Network  Information -AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG -AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio -AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, -server  sent  events,  session  history  of  browsing  context -*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL -Page  74  of  159 -![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 -The  iframe  element,  Content  Security  Policy  1.0. -AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications -AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing -control,  Navigation  timing -AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation -AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, -Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy -AGL  System  must  support  Khronos  WebGL  API. -**4.2.2  Web  Runtime** -The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access -the  AGL  Application  Framework  and  Services. -**4.2.2.1  Requirements** -AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., -installation/removal). -AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, -view  generation,  rendering,  etc.) -AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add -better  device/platform  integration. -Page  75  of  159 -![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to -categorize  apps  with  different  privileges. -System  must  provide  high  level  GUI  components  for  Web  application. -At  least,  below  components  are  required. -· Text  labels -· Button -· Radio  button -· Check  box -· Tab  panel -· Animation  (e.g.  MNG,  GIF  animation) -· Slider -· Accordion  list -· Anchor -· Text  input  form -· Dropdown  list  box -· Date  picker -4.3  Native  HMI -The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written -using  Javascript  or  other  web  technologies. -**4.3.1  Native  App  Runtime** -The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to -access  the  AGL  Application  Framework  and  Services. -**4.3.1.1  Requirements** -System  must  provide  high  level  GUI  components  for  native  application. -Page  76  of  159 -![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -At  least,  below  components  are  required. -· Text  labels -· Button -· Radio  button -· Check  box -· Tab  panel -· Animation  (e.g.  MNG,  GIF  animation) -· Slider -· Accordion  list -· Anchor -· Text  input  form -· Dropdown  list  box -· Date  picker -**4.3.2  Native  Application  Framework** -The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an -SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that -framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the -application  framework  provides  for  its  applications. -**5   Services   Layer** -The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the -services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces -remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime -modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid -unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer -interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces -provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may -choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework -runtime  to  adjust  to  any  new  interfaces, -Page  77  of  159 -![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1  Platform  Services -Platform  Services  Layer.  Conventional  Linux  platform  services -**5.1.1  Bluetooth** -This  document  describes  requirements  regarding  registration,  (dis)connection  and  device -information  management  between  Bluetooth  device  and  infotainment  system.  Necessary -Bluetooth  profiles  in  automotive  use  case  are  defined  here. -**5.1.1.1  Requirements** -The  Telephony  system  shall  be  designed  to -support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR -without  hardware  upgrade. -A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: -· Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) -· HFP  (Hands  Free  Profile) -· OBEX  (Object  Exchange) -· OPP  (Object  Push  Profile) -· PBAP  (Phonebook  Access  Profile) -· SPP  (Serial  Port  Profile) -· SDAP  (Service  Discovery  Access  Profile) -If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music -from),  the  system  shall  also  support  the  following  incremental  BT  profiles: -· A2DP  (Advanced  Audio  Distribution  Profile) -· AVRCP  (Audio  Visual  Remote  Control  Profile) -The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the -Page  78  of  159 -![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of -generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in -encryption  key  length  negotiation. -When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as -default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority -scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration -time. -The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is -10  meters  and  maximum  power  is  2.5  mW  (4  dBm). -The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall -allow  using  five-slot  packet  transmission  for  faster  data  rate. -The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a -standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. -vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are -often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain -name  and  address  information,  phone  numbers,  and  e-mail  addresses. -vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, -LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, -URL,  UID,  Version,  and  KEY  properties. -vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: -MIME  Content-Type  for  Directory  Information -vCard  MIME  Directory  Profile -It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with -the  vCard  version  2.1  properties. -The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any -associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is -not  full. -The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO -Page  79  of  159 - - ------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **Support  in  HF** > **AGL** - ----------- ------------------------------------------------------------- ----------------------- ----------- - > 1 > Connection  management > Mandatory > x - - > 2 > Phone  status  information > Mandatory > x - - > 3 > Audio  Connection  handling > Mandatory > x - - > 4 > Accept  an  incoming  voice  call > Mandatory > x - - > 5 > Reject  an  incoming  voice  call > Mandatory > x - - > 6 > Terminate  a  call > Mandatory > x - - > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x - - > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x - > - > HF - - > 9 > Place  a  call  using  memory  dialing > Option > - - - > 10 > Place  a  call  to  the  last  number  dialed > Option > - - ------------------------------------------------------------------------------------------------------------- - -![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -shall  be  used. -5.1.1.1.1  Hands  Free  Profile -The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile -specification  version  1.6  or  later. -The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, -wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and -output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to -the  actual  phone. -It  shall  provide  following  roles: -Hands-Free  unit  (HF) - - > 11 > Call  waiting  notification > Option > x - ------- ------------------------------------------------------ ---------- ---------- - > 12 > Three  way  calling > Option > x(\*1) - > 13 > Calling  Line  Identification  (CLI) > Option > x - > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x - > 15 > Voice  recognition  activation > Option > x - > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - - > 17 > Ability  to  transmit  DTMF  codes > Option > x - > 18 > Remote  audio  volume  control > Option > - - > 19 > Respond  and  Hold > Option > x - > 20 > Subscriber  Number  Information > Option > x - > 21a > Enhanced  Call  Status > Option > x - > 21b > Enhanced  Call  Controls > Option > - - > 22 > Individual  Indicator  Activation > Option > - - > 23 > Wide  Band  Speech > Option > x - > 24 > Codec  Negotiation > Option > x - -![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -\*1:  Does  not  support  Multi-party  (conference)  call -The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the -model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -string  in  a  phone  model  CGMM  variable. -· Phone  Model  CGMM: -· Type:  string -· Max  length:  200  chars -Page  81  of  159 -![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the -Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be -stored  as  a  string  in  a  phone  model  CGMI  variable. -· Phone  Model  CGMI: -· Type:  string -· Max  length:  200  chars -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the -revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -string  in  a  phone  model  CGMR  property. -· Phone  Model  CGMR: -· Type:  string -· Max  length:  200  chars -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) -The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP -specification  version  1.2  or  later. -Page  82  of  159 - - > **No.** > **Codec** > **Support** > **AGL** - ----------- ------------------- --------------- ----------- - > 1 > SBC > Mandatory > x - > 2 > MPEG-1,2  Audio > Option > - - > 3 > MPEG-2,4  AAC > Option > - - > 4 > ATRAC  family > Option > - - - > **No.** > **Feature** > **Support  in  SNK** > **AGL** - ----------- -------------------- ------------------------ ----------- - > 1 > Audio  Streaming > Mandatory > x - -![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to -realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. -It  shall  provide  following  roles: -Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from -the  SRC  on  the  same  piconet. -Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. -Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. -Copyright  protection  technology  SCMS-T  should  be  supported. -5.1.1.1.3  Phone  Book  Access  Profile -Page  83  of  159 -![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification -version  1.1  or  later. -The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between -devices. -Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The -Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected -device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing -and  copying  contact  information. -It  shall  provide  following  roles: -· Phonebook  Client  Equipment  (PCE) -It  shall  provide  following  types  of  Phonebook  objects: -· The  main  Phonebook  object -· The  Incoming  Call  History  object -· The  Outgoing  Call  History  object -· The  Missed  Call  History  object -· The  Combined  Call  History  object -A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device -automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook -download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: -· Using  PBAP  profile -All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. -SIM)  and  also  any  stored  in  the  BT  device's  memory. -The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the -vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded -from. -5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile -Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -Page  84  of  159 - - > **No.** > **Service** > **Support  in  DT** > **AGL** - ----------- ------------------------------------------- ----------------------- ----------- - > 1 > Data  call  without  audio  feedback > Mandatory > x - > 2 > Data  call  with  audio  feedback > Option > - - > 3 > Fax  services  without  audio  feedback > N/A > - - > 4 > Fax  services  with  audio  feedback > N/A > - - > 5 > Voice  call > N/A > - - > 6 > Incoming  calls > Option > x - > 7 > Outgoing  calls > Mandatory > x - -![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” -Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. -5.1.1.1.5  Object  Push  Profile  (OPP) -Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower -layers. -It  has  to  comply  with  the  specification  for  “Push  Server”. -Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. -**Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** -Page  85  of  159 - - > **No.** > **Feature** > **Support  in  CT** > **AGL** - ----------- -------------------------------------------- ----------------------- ----------- - > 1 > Connection  establishment  for  control > Mandatory > x - > 2 > Release  connection  for  control > Mandatory > x - > 3 > Connection  establishment  for  browsing > C6 > x - - ------------------------------------------------------------------------------------- - > **No** > **Feature** > **Support  in  Push  Server** > **AGL** - > - > **.** - ---------- ---------------------------- --------------------------------- ----------- - > 1 > Object  Push > Mandatory > x - - > 2 > Business  Card  Pull > Option > - - - > 3 > Business  Card  Exchange > Option > - - ------------------------------------------------------------------------------------- - -![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) -The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. -The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device -plus  one  remote  control.. -The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL -column  in  Table  25  should  be  supported. -C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional -otherwise -C3:  Mandatory  to  support  at  least  one  Category -C4:  Mandatory  if  Category  2  supported,  excluded  otherwise -C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise -EX:  Excluded -Page  86  of  159 -![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4 Release  connection  for  browsing C6 x -5 AV/C  Info  commands Option x -6 Category  1:  Player/Recorder C3 x -7 Category  2:  Monitor/Amplifier C3 - -8 Category  3:  Tuner C3 - -9 Category  4:  Menu C3 - -10 Capabilities Option x -11 Player  Application  Settings Option x -12 Metadata  Attributes  for  Current  Media  Item Option x -13 Notifications C2 x -14 Continuation C2 x -15 Basic  Group  Navigation Option x -16 Absolute  Volume C4 - -17 Media  Player  Selection Option x -17.1 -  Supports  Multiple  Players Option x -18 Browsing Option x -18.1 -  Database  Aware  Players Option x -19 Search Option - -20 Now  Playing C6 x -20.1 -  Playable  Folders Option x -21 Error  Response EX - -22 PASSTHROUGH  operation  supporting  press  and Option x -Page  87  of  159 - - ------------------------------------------------------------------------------ - > **No** > **Feature** > **Support  by  the  MCE** > **AGL** - > - > **.** - ---------- ------------------------- ----------------------------- ----------- - > 1 > Message  Notification > C1 > x - - > 2 > Message  Browsing > C1 > x - - > 3 > Message  Uploading > Option > x - - > 4 > Message  Delete > Option > - - - > 5 > Notification > C2 > x - > - > Registration - ------------------------------------------------------------------------------ - -![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -hold -The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and -pass  this  information  up  to  so  it  can  be  passed  to  the  User. -5.1.1.1.7  Message  Access  Profile -Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary -lower  layers. -It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. -Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. -C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features -C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message -Notification.  Not  applicable  otherwise. -Page  88  of  159 - - > **No.** > **Feature** > **Support  in  PANU** > **AGL** - ----------- ------------------------------------------ ------------------------- ----------- - > 1 > Initialization  of  NAP/GN  service > - > - - > 2 > Shutdown  of  NAP/GN  service > - > - - > 3 > Establish  NAP/GN  service  Connection > Mandatory > x - -![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.8  Serial  Port  Profile  (SPP) -The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version -1.1  or  later. -It  shall  provide  following  roles: -Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. -Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. -Following  features  shall  be  provided  by  the  Supplier: -Establish  link  and  setup  virtual  serial  connection -Accept  link  and  establish  virtual  serial  connection -Register  Service  record  for  application  in  local  SDP  database -5.1.1.1.9  Personal  Area  Network  (PAN)  Profile -Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. -Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. -Page  89  of  159 - - > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x - ----- ------------------------------------------- ------------- ----- - > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x - > 6 > Management  Information  Base  (MIB) > - > - - -![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.10  Service  Discovery  Profile  (SDP) -The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP -specification  version  1.1. -The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices -in  the  vicinity  of  a  Bluetooth  enabled  device. -It  shall  provide  following  roles: -Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. -Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to -the  service  inquiries  generated  by  Local  Device. -The  following  features  shall  be  provided  by  the  Supplier: -Search  for  services  by  service  class -Search  for  services  by  service  attributes -Service  browsing -5.1.1.1.11  Device  Information  Profile -Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. -**Table  28  :  List  of  DIP  Supporting  Functions** -Page  90  of  159 - - > **No.** > **Feature** > **Support** > **AGL** - ----------- ----------------------- --------------- ----------- - > 1 > SpecificationID > Mandatory > x - > 2 > VendorID > Mandatory > x - > 3 > ProductID > Mandatory > x - > 4 > Version > Mandatory > x - > 5 > PrimaryRecord > Mandatory > x - > 6 > VendorIDSource > Mandatory > x - > 7 > ClientExecutableURL > - > - - > 8 > ServiceDescription > - > - - > 9 > DocumentationURL > - > - - -![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.12  Bluetooth  Smart  Ready -Bluetooth  Smart  Ready  shall  be  supported. -It  shall  comply  with  Bluetooth  Low  Energy  standard. -5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) -The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX -specification  version  2.0  or  later. -The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between -devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. -It  shall  provide  following  roles: -Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data -objects  shall  be  pushed  and  pulled,  respectively. -Page  91  of  159 -![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. -The  following  features  shall  be  provided  by  the  Supplier: -Establishing  an  object  connection -Pushing  a  data  object -Pulling  a  data  object -Performing  an  action  on  data  objects -Creating  and  managing  a  Reliable  Object  Exchange  Connection -5.1.1.1.14  Generic  Audio/Video  Distribution  Profile -The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the -GAVDP  specification  version  1.2  or  later. -The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between -two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. -It  shall  provide  following  roles: -Initiator  (INT) -Acceptor  (ACP) -Following  are  the  feature  requirements  for  this  profile: -Connection -Transfer  Control -Signalling  Control -Security  Control -Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not -yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. -5.1.1.1.15  Bluetooth  Diagnostics -**5.1.2  Error  Management** -The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes -Page  92  of  159 -![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized -restart.  In  addition, -in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery -to  issue  in  a  short  amount  of  time. -**5.1.2.1  Use  Cases** -5.1.2.1.1  System  Surveillance  and  Recovery -While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an -immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating -the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to -try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating -middle  ware,  reboot  the  whole  system  to  try  and  recover. -There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that -adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The -AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. -The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even -if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be -done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error -Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the -degree  should  be  adjusted  by  its  behavior  status. -5.1.2.1.2  Collecting  Information -For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt -recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the -cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. -With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On -the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come -Page  93  of  159 -![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, -the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. -**5.1.2.2  Requirements** -Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its -status  automatically  and  recover -The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each -process. -The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. -When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold -value,  action  is  changeable  by  AGL  user. -Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification -to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are -output  communication  or  disk  I/O. -Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification -by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an -error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication -error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. -Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it -should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination -of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so -those  two  should  be  able  to  set  separately. -Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold -value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be -changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. -Should  be  able  to  vanish  process  forcibly  including  subsidiary  process -Page  94  of  159 -![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Make  the  software  that  works  by  system  have  the  concept  of  level  importance. -Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be -adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. -The  process  that  detecting  an  external  communication  error  within  the  Error  Management -module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. -The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as -more  than  one  process. -The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple -applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where -multiple  applications  can  be  moved  by  the  same  process. -Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing -process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as -process  crash,  exit,  etc.. -An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends -suddenly  the  other  will  not  become  abnormal  state. -The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other -process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards -external  side. -When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart -additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered -beforehand. -The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file -system  without  destroying  them. -Page  95  of  159 -![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for -analyzing. -When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a -message  that  can  specify  the  cause. -Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -in  a  short  period  of  time  have  been  equipped  and  able  to  select. -In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or -system  down  does  not  occur  (self-destruction  on  log  output  process). -Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. -Should  be  able  to  select  the  level  of  log  output. -Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. -Should  be  able  to  obtain  the  information  linked  to  the  system  resources. -Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. -Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -in  a  short  period  of  time  have  been  equipped  and  able  to  select. -As  the  smallest  amount  of  information,  the  following  information  should  be  left. -· Register  information -· Process  logical  memory  map -· -Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence -· Time  of  occurrence -· -Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing -file‑name  of  the  thread  etc.) -Page  96  of  159 -![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· The  signal  that  occurred -Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. -· -Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted -for  an  output. -· -Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent -dropping  the  information  needed. -· -Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] -· -Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed -maximum  size. -· -NOTE  information  of  ELF  header  and  program  header  will  not  change. -Selectable  memory  mappings  are  the  following. -· anonymous  private  mappings -· anonymous  shared  mappings -· file-backed  private  mappings -· file-backed  shared  mappings -· private  huge  page -· shared  huge  page -Setting  parameters  of  the  output  context  are  the  following. -· -Memory  mapping  category  which  is  for  an  output  object  can  be  set. -· The  order  of  outputting  memory  mapping  can  be  set. -Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in -increments  of  process. -Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be -able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. -Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. -Page  97  of  159 -![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. -**5.1.3  Graphics** -Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. -**5.1.4  Location  Services** -Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead -reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary -output  of  the  GPS  receiver. -**5.1.4.1  Position** -**5.1.4.2  Time  of  Day** -With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car -device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of -its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in -future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. -**Monotonic  and  Absolute  Time  Support** -As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. -Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s -moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and -Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. -On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time -that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, -some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports -Monotonic  Time. -**Kernel  Time  Precision** -Page  98  of  159 -![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those -communicating  system  includes  the  device  that  needs  ms  order  procedure. -In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on -the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest -value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. -**5.1.4.3  Requirements** -Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. -Adjust  the  system  time  after  the  time  is  determinate. -GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using -the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. -GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not -imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make -Source  plugin  can  not  be  GPL  or  LGPL. -When  waiting,  can  use  both  absolute  time  and  monotonic  time -Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -monotonic  time. -Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -monotonic  time. -System  time  must  be  able  to  use  consecutively  at  least  until  2099. -Absolute  time  has  to  support  leap  year  and  leap  seconds. -1  jiffies  have  to  be  smaller  than  1ms. -Page  99  of  159 -![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. -From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. -A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. -**5.1.5  Health  Monitoring** -Platform  monitoring  services  such  as  watchdog  or  active  monitoring -**5.1.6  IPC** -Standard  platform  interprocess  and  interprocessor  communication  mechanism. -**5.1.7  Lifecycle  Management** -Startup,  shutdown,  state  change,  etc. -**5.1.8  Network  Services** -Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer -including  Wifi,  Bluetooth,  or  ethernet. -**5.1.9  Persistent  Storage** -Power  safe  persistent  storage -**5.1.10  Power  Management** -Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs -in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. -*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* -Page  100  of  159 -![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -modern  ECUs -In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, -in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal -balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important -for  overall  durability  characteristic. -Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming -more  welcomed  over  traditional  cold  boot  approaches. -Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has -become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only -consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) -**5.1.10.1  Requirements** -AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend -states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” -/“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. -AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state -transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state -transitions  if  no  requests  provided  from  applications. -Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of -this  specification  (it  is  also  platform-dependent). -AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of -cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting -core  in  one  of  its  low  power  states) -AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular -cores  from  SMP  group. -Page  101  of  159 -![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points -(table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, -some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget -insignificant) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling -Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. -Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they -may  have  negative  impact  on  overall  system  performance/predictability -AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is -platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states -Only  application-defined  policies  shall  be  allowed  for  CPU  Idle -AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices -AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling -**5.1.11  Resource  Management** -Resource  and  device  management. -Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource -request  by  the  Resource  Manager. -**5.1.12  Telephony  Services** -**5.1.12.1  Requirements** -Page  102  of  159 -![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.12.1.1  Telephony  variants -Purpose:  To  define  the  variants  of  Telephony -Requirement: -There  will  be  2  variants  of  phone  system. -Variant  1:  Front  User  only  Telephony. -Variant  2:  Rear  and  Front  Telephony. -All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature -can  be  disabled  via  car  configuration. -**5.1.13  Wi-Fi** -This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information -management  between  a  wireless  LAN  device  and  infotainment  system. -Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. -**5.1.13.1  Use  Cases** -5.1.13.1.1  Construct  WiFi  Network -In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. -a\. STA -In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via -an  Access  Point. -It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. -b\. AP -In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices -with  an  external  network. -Page  103  of  159 -![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. -c\. P2P -In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- -Fi  Direct. -5.1.13.1.2  Miracast -In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) -They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, -by  using  UIBC  (User  Interface  Back  Channel).-(b) -**Figure  8-29  :  Overview  of  Miracast** -a\. Shared  Displayed  Content -Page  104  of  159 -![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Use  case  examples  of  shared  displayed  content  are: -· -A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device -(e.g.  Mobile)  on  In-Vehicle  Infotainment  system. -· -A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment -system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). -b\. Remote  Operation -Use  case  examples  of  remote  operation  are: -· -A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device -(e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. -· -A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle -Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). -· -While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation -functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. -Mobile). -5.1.13.1.3  DLNA -In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. -**5.1.13.2  Requirements** -5.1.13.2.1  Security -The  WiFi  module  shall  support  security  standard  WEP. -It  shall  support  40  bit  WEP  encryption  method. -It  shall  support  104  bit  WEP  encryption  method. -It  shall  support  security  standard  WPA  Personal. -Page  105  of  159 -![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA2  Personal. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA  Enterprise. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA2  Enterprise. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -5.1.13.2.2  Simple  Configuration -It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. -It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. -It  shall  support  Configuration  Method  for  Display. -Page  106  of  159 -![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  support  Configuration  Method  for  Keypad. -It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. -It  shall  support  Configuration  Method  for  PushButton. -It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. -5.1.13.2.3  QoS -It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. -It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. -5.1.13.2.4  STA -The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). -5.1.13.2.5  AP -The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). -5.1.13.2.6  WiFi  Direct -It  shall  comply  with  Wi-Fi  Direct  standard. -It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. -Page  107  of  159 - - -------------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **(Reference)** - > - > **Support  in  Wi-** - > - > **Fi  Direct** - ----------- ---------------------------------------------------- -------------------------- ------------------------ - > 1 > P2P  Provision > ‑ > Mandatory - > - > Discovery - - > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory - - > 3 > ‑ > Find  Phase > Mandatory - - > 4 > P2P  GO  Negotiation > ‑ > Mandatory - - > 5 > P2P  Service  Discovery > ‑ > Option - - > 6 > P2P  Invitation > Temporary  P2P  Group > Option - - > 7 > ‑ > Persistent  P2P  Group > Option - - > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option - - > 9 > Intra-BSS  Distribution > ‑ > Option - - > 10 > Concurrent  Operation > ‑ > Option - - > 11 > P2P  Service  Discovery > UPnP > Option - - > 12 > ‑ > Bonjour > Option - - > 13 > ‑ > Wi-Fi  Display > Option - - > 14 > ‑ > WS-Discovery > Option - - > 15 > ‑ > Vendor  specific > Option - -------------------------------------------------------------------------------------------------------------------- - -![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.13.2.7  Miracast -Page  108  of  159 - - -------------------------------------------------------------------------------------------------------------- - > ‑**No.** > **Feature** > ‑ > **(Refere** - > - > **nce)** - > - > **Suppor** - > - > **t        in** - > - > **Miracas** - > - > **t** - ------------ ----------------------------------------------------- ----------------------- ------------------- - > 1 > WFD  Device  type > WFD  Source > Mandat - > - > ory - - > 2 > ‑ > Primary  Sink > Mandat - > - > ory - - > 3 > ‑ > Dual-role  possible > Option - - > 4 > WFD  Service > ‑ > Option - > - > Discovery - - > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat - > - > ory - - > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option - - > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option - > - > Group - - > 8 > ‑ > via  TDLS > Option - - > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat - > - > ory - - > 10 > WFD  Session  Establishment  (RTSP) > Mandat - > - > ory - -------------------------------------------------------------------------------------------------------------- - -![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  comply  with  Miracast  standard. -It  shall  support  the  Miracast  functions  identified  in  Table  30. -Page  109  of  159 - - --------------------------------------------------------------------------------- - > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat - > - > ory - ------ --------------------------------------------------- ----------- ---------- - > 12 > WFD  Standby  (RTP/RTSP) > Option - - > 13 > Video  CODEC  formats > Option - - > 14 > Audio  CODEC  formats > Option - - > 15 > UIBC > Generic - - > 16 > HIDC - --------------------------------------------------------------------------------- - -![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.13.2.8  WiFi  Hotspot -It  shall  comply  with  Wi-Fi  Hotspot  standard. -In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot -service. -In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. -5.1.13.2.9  DLNA  via  WiFi -The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. -**5.1.14  Window  System** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -and  a  routing  of  user  interactions. -Page  110  of  159 -![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.2  Automotive  Services -Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but -contains  services  specialized  for  automotive  applications. -**5.2.1  Audio  Services** -BTBF,  equilization,  mult-zone  audio  control,  etc. -**5.2.2  Camera  Services** -Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. -**5.2.3  Configuration  Services** -Service  for  storing  configuration  parameters. -**5.2.4  Diagnostic  Services** -Diagnostic  services. -(This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) -**5.2.5  Multimedia  Services** -CD,  DVD,  Blu-Ray,  MP3,  etc. -(Factor  out  metadata  into  separate  component.) -**5.2.5.1  Media  Player** -In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just -Page  111  of  159 -![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video -devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, -there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- -seat  passengers  as  well  as  driver  all  having  independent  requirements. -The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: -· -Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the -ones  encountered  in  mobile  and  desktop  world. -· -Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) -and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or -establishes  a  network  connection.) -· -Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of -audio  /  video  processing  chains. -Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data -processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in -comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from -navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from -Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so -on. -It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore -processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing -offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with -particular  implementation  freedom  left  for  a  silicon  vendor. -The  following  requirements  formalize  these  considerations. -**5.2.5.2  Requirements** -5.2.5.2.1  Media  Containers -AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This -includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It -shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable -input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated -from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall -be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. -Page  112  of  159 -![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, -for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream -identification  data  from  media  container. -AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: -· HTTP -· RTPS -· Digital  Radio  (DAB) -· DigitalTV  (DVB-T)  etc. -It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with -system  requirements. -AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload -computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such -extension,  if  available,  shall  be  transparent  to  the  applications. -Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. -AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the -source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without -intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this -process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of -particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from -multiple  choices. -AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall -support  the  following  functionality: -· -Selection  of  data  source  and  destination  (files,  devices,  network  resources) -· Pausing/resuming  of  multimedia  streams -· Rewinding  in  forward  and  reverse  directions  (for  playback) -· Audio  volume  control  on  per-stream  basis -· Retrieval  of  current  stream  position  (timestamp) -Page  113  of  159 -![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -Notifications  on  error  conditions  preventing  multimedia  stream  processing -AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved -into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to -specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to -specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw -audio/video  streams  to  multiple  renderers  as  well. -AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and -synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: -· -Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. -· Per-stream  volume  and  audio  effects  control. -· -Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). -· -Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). -· Mixing  and  broadcasting  of  the  audio  streams. -AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to -specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or -removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, -emergency  system  alarm  output  and  so  on. -AGL  shall  provide  support  for  major  multimedia  containers,  such  as: -· MPEG2-TS/PS  (ISO/IEC  13818-1) -· MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) -It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with -system  requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: -· OGG  (RFC  3533) -· 3GPP  (ISO/IEC  14496-12) -· etc -Page  114  of  159 -![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.2.5.2.2  Media  Audio  Codecs -AGL  shall  provide  support  for  major  audio  codecs,  such  as: -· -MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) -· AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) -It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system -requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: -· VORBIS  (http://xiph.org/vorbis/) -· Windows  Media  Audio -· etc. -5.2.5.2.3  Media  Video  Codecs -AGL  shall  provide  support  for  major  video  codecs,  such  as: -· MPEG-2  (ISO/IEC  13818-2) -· MPEG-4  Part  2  (ISO/IEC  14496-2) -· H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) -It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system -requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: -· Theora  (www.theora.org) -· Windows  Media  Video -· etc -5.2.5.2.4  Image  File  Formats -Page  115  of  159 -![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true -colour. -Compression  formats -· RLE  8  bits/pixel -· RLE  4  bits/pixel -· Bit  field  or  Huffman  1D  compression -· JPEG  or  RLE-24 -· PNG -The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including -Exchangeable  Image  File  Format  (EXIF)  format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, -including  transparency -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced -version  89a  and  also  animation  in  GIFF  images. -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -format. -**5.2.6  Navigation  Services** -Navigation  engine -Page  116  of  159 -![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.7  PIM** -Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. -**5.2.8  Smartphone  Link** -This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which -realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation -is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and -AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use -smartphone  content  (map,  music,  browser...)  by  IVI. -Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. -**Figure:  8-30** -Page  117  of  159 -![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  defines  following  requirements  of  Smartphone  link. -1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. -2.  The  sound  of  smartphone  shall  be  linked  to  IVI. -3.  The  sound  shall  be  synchronized  with  the  screen. -4.  IVI  should  operate  smartphone. -5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. -6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should -inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. -This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone -link. -**5.2.8.1  Miracast** -This  section  describes  requirements  regarding  Smartphone  link  (Miracast). -Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- -Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing -between  source  device  and  sink  device. -Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. -**Figure:  8-31** -Page  118  of  159 - - ---------------------------------------------------------------------------------------------- - > **No** > **Requires** > **Description** - ------------ ----------------------------- --------------------------------------------------- - > SPL.1.1 > WFD  Topology > Define  role  of  Miracast - - > SPL.1.2 > Connection  Topology > Define  connection  condition  between - > - > a  smartphone  and  an  IVI - - > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi - > > - > 1 > Direct). - - > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency - > - > 2 - - > SPL.1.3 > Video  Format > Define  Video  format - - > SPL.1.4 > Audio  Format > Define  Audio  format - - > SPL.1.5 > Session  Control > Define  Miracast  session  state - - > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required - > - > for  implementing  Miracast - - > SPL.1.7 > Resource  Management > Define  resource  management - ---------------------------------------------------------------------------------------------- - -![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. -**References** -\[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 -\[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 -\[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision -2.2 -\[4\]  DCP  (Digital  Content  Protection)   -AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. -Page  119  of  159 -![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -SPL.1.8 Fail-safe  Control Define  Fail-safe  control -**Table  8-14:  Smartphone  Link  (Miracast)  Requirements** -**Figure:  8-32  State  Change  Diagram** -The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. -Page  120  of  159 - - ------------------------------------------------------------------------------------------------------- - > **No.** > **State** > **Description** - ----------- ------------------------- ----------------------------------------------------------------- - > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. - - > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and - > - > waiting  for  Wi-Fi  P2P  connection  from  source - > - > device. - - > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source - > - > device. - - > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. - - > 5 > Play > Streaming  the  audio  and  video  content  from  source - > - > device  to  sink  device. - - > 6 > Pause > Paused  the  streaming  of  audio  and  video  content - > - > from  source  divide  to  sink  device. - ------------------------------------------------------------------------------------------------------- - -![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.8.2  Smart  Device  Link** -“Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. -Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach -makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s -distraction  and  voice  recognition. -That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote -procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework -and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. -SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile -phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported -applications  can  be  launched. -Page  121  of  159 -![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  8-33  :  SDL  overview** -**5.2.8.3  Requirements** -5.2.8.3.1  Miracast -System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. -· -Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which -from  Source  Device‑Smartphone‑. -· Supporting  WFD  Source  is  an  option. -· -Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) -source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). -· -Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take -measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over -5Km/H) -· Support  Wi-Fi  P2P  connection. -· -Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in -Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. -· Wi-Fi  TDLS  connection  is  an  option. -· -AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select -Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) -· -AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive -Page  122  of  159 -![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for -confirmation) -· -Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. -· -Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P -connection  established. -· -Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. -· -Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) -function  if  support  5GHz  band. -· Follow  reference  \[1\]  for  Video  Codec. -· Support  follow  format  for  Video  Resolution  and  Frame  rate. -o 640\*480‑VGA‑‑Progressive  60  fps -o 1280\*720‑HD‑Progressive  30  fps -Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. -· Support  follow  format  for  Audio. -o LPCM  48ksps  16bit  2ch -o AAC  48ksps  16bit  2ch -Regarding  Audio  Format,  other  formats  are  an  option. -When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up -notification) -Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support -content  protection  function. -· -AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not -define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for -Page  123  of  159 -![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -vendor’s  own  reason. -· Support  both  encryption  cases  if  support  HDCP  function. -o Case1  Videos  data  encryption -o Case2  Both  video  and  audio  encryption -Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to -DCP.(reference  \[4\]) -· -Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, -then  Miracast  release  screen  and  audio  resources  for  the  event. -· -It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast -session.) -· -Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events -happen. -o Failed  to  Wi-Fi  connection -o Failed  to  establish  Miracast  session -o Wi-Fi  link  loss  on  Miracast -o Break  Miracast  connection  from  smartphone -5.2.8.3.2  Smart  Device  Link -System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. -System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. -System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel -device  of  IVI  device. -System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice -Page  124  of  159 -![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -recognition  of  IVI  system. -System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity -method  must  be  supported  Bluetooth  and/or  Wi-Fi. -System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity -method  must  be  supported  Bluetooth  and/or  Wi-Fi. -**5.2.9  Speech  Services** -The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. -AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands -AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech -**5.2.10  Tuner  Services** -The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into -the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, -TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present -in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. -**5.2.10.1  Receivers** -The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including -AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any -number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from -the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current -content. -The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into -the  same  API  regardless  of  the  receiver  type. -Page  125  of  159 -![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow -its  clients  to  address  each  receiver  in  the  system  independently. -5.2.10.1.1  HD  Radio -HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An -HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to -provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the -receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The -HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the -iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional -design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by -iBiquity  Digital. -The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the -requirements  in  this  section. -1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. -2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. -3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. -Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is -applicable  to. -AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status -to  the  system. -AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the -tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning -successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio -output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No -Reception"  is  available  in  that  specific  channel. -AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -Page  126  of  159 -![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Frequency -· Mono/Stereo -FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -· Frequency -· PI  Code  (RDS  only) -· PTY  (RDS  only) -· Radio  Text  (RDS  only) -· PS  Name  (RDS  only) -· Category  (RDS  only) -· Mono/Stereo -HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -· Frequency -· PTY -· No  of  HD  channels  available -· Radio  Text -· Channel  Name -· Category -· Bit  rate -· Station  Logo -· Artist  Experience -The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. -The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal -strength. -AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. -Page  127  of  159 -![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be -possible  to  adjust  by  software. -· Range:  15  –  40  dBµV -· Step:  1  dBµV -· Default:  20  dBµV -· -Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity -level.  TBD,  Supplier  to  suggest  solution. -AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be -possible  to  adjust  by  software. -· Range:  20  –  40  dBµV -· Step:  1  dBµV -· Default:  34  dBµV -· -It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. -different  for  night  and  day). -The  system  shall  be  able  to  switch  between  AM  and  FM  bands. -HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the -SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance -with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -Information  Service  Transport". -HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the -SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance -with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -Information  Service  Transport". -HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. -Page  128  of  159 -![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. -· Song -· Artist -· Album -· Genre -· Comments -· Commercial -· Reference  Identifier -The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification -"HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" -FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the -system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, -Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency -range  from  87,5  MHz  to  108,0  MHz". -FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled -the  system  shall  indicate  this. -FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. -FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. -FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. -FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. -FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. -FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received -through  RDS. -Page  129  of  159 -![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. -FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. -FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. -FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. -FM/HD  system  shall  be  able  to  enable/disable  regionalisation. -FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. -FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) -reception. -FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. -FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. -FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. -HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. -HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. -AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. -AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. -*HD system shall extract the album name, artist name, track number from the audio stream a*nd -Page  130  of  159 -![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -present  to  the  system. -The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The -feature  will  be  able  to  store  at  least  50  tags. -*5.2.10.1.1.1  Configuration* -AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration -file. -AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. -AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local -configuration  file. -5.2.10.1.2  Database  Requirements -AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains -the  following  attributes: -· Frequency -· PTY  (FM  &  HD  only) -· Channel  name  (FM  &  HD  only) -· Channel  icon  (HD  Only) -· Category  (FM  &  HD  only) -AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following -conditions: -· New  channel  is  found -· Existing  channel  disappears -· -Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list -database. -Page  131  of  159 -![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present -to  the  system. -AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the -frequency,  and  present  to  the  system. -FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, -and  present  to  the  system. -AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following -information: -· Station  name  (FM  and  HD  only) -· Frequency -· Status  of  HD  (HD,  HD1,  HD2) -· HD  SIS  (HD  only) -AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: -· Favourite  station  changed -· Favourite  station  is  removed -· New  favourite  is  added -**5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** -Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from -applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and -LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of -VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main -functions. -· Vehicle  Data  Processing -· Communication  between  ECUs -· Vehicle  Data  Upload -Page  132  of  159 -![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Simulator -**Figure  7-27  :  Overview  of  Vehicle  Info  Control** -**5.2.11.1  Vehicle  Data  Processing** -Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, -personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application -and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. -· -Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature -· User  Information,  such  as  a  name,  taste,  etc.  of  a  driver -· The  operation  history  of  a  driver -Page  133  of  159 -![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle -conditions,  such  as  speed  and  day  and  night -Vehicles  data  processing  consists  of  the  following  functional  elements  further. -(1)  Abstraction  of  Vehicles  Data -In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind -of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving -speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for -application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles -data  of  the  same  implications  and  the  same  unit. -(2)  Maintenance  of  Vehicles  Data -Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past -value  (history). -(3)  Application  /  Middleware  Interface  (API) -The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. -Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and -the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data -restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance -(access  control). -(4)  Vehicles  Interface -It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN -and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the -exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. -However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more -Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In -addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. -**5.2.11.2  Communications  between  ECUs** -Page  134  of  159 -![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -which  each  ECU  can  access. -**5.2.11.3  Vehicle  Data  Upload** -When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -which  each  ECU  can  access. -**5.2.11.4  Simulator** -In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is -unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes -development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel -controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be -an  option. -**5.2.11.5  Requirements** -The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application -and/or  middleware  can  access  vehicle  information. -The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract -property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but -the  speed  of  a  car. -System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. -Page  135  of  159 -![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  support  typical  vehicle  property  as  “standard  property”. -As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. -System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. -A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard -property. -Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) -The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or -middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough -as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile -display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. -A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is -stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the -load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and -spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. -It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In -corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. -· -The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the -accumulated  newest  value  is  less  than  a  threshold  value. -· -Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the -newest  accumulation. -About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need -to  be  able  to  set  up  easily. -In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. -System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property -access. -System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or -middleware. -Page  136  of  159 -![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Below  attributes  must  include  in  this  interface -· Zone(optional) -· Property  name -· Value -· -Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application -and/or  middleware. -Below  attributes  must  include  in  this  interface. -· Zone(optional) -· Property  name -· Value -System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from -application  and/or  middleware. -When  status  changed,  system  must  invoke  callback  function  with  below  attributes. -· Zone(optional) -· Property  name -· Value -· Timestamp -· Sequence  number -Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -Sequence  number  is  useful  to  check  event  order. -The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of -change  of  vehicle  information. -In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an -acceptable  value  even  if  vehicle  information  changes. -For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the -application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of -change. -Page  137  of  159 -![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. -· -The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the -value  from  the  last  notice  of  change  is  less  than  specification. -· -Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a -definite  period  of  time,  it  does  not  notify. -Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the -time  of  change. -What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified -notice  interval  is  made  possible. -The  data  stored  is  acquired  collectively. -Below  attributes  must  include  in  this  interface. -· Zone(optional) -· Property  name -· Values -· Timestamps -It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 -seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. -There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual -in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed -simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the -newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to -recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information -relevant  to  mutual  and  to  access  it. -Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle -information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, -and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all -those  vehicle  information  at  the  time  of  reference. -The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. -Or  the  thing  which  can  be  changed  from  a  program  during  operation. -Page  138  of  159 -![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property -"velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be -accessed  from  all  applications. -System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same -property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only -application  C  can  set  this  property. -Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control -policy  may  be  different  per  car  type,  grade  and  destination. -System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU -and  across  two  or  more  ECU’s. -If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, -middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, -the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware -which  exist  in  a  different  ECU. -VIC  can  be  requested  to  set  the  value  specified  as  Property. -It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. -The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand -from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. -Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application -responds. -It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed -easily. -The  data  exchange  between  ECUs  should  be  permitted  by  VIC. -All  data  transmission  and  reception  from  other  Software  Component  are  refusing. -Page  139  of  159 -![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. -The  vehicle  information  to  upload  is  being  able  to  choose. -A  selection  condition  is  that  the  following  specification  is  possible  at  least. -· Date-and-time  range -· Object  vehicles  data -· The  change  threshold  value  of  vehicles  data -Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be -able  to  change  dynamically  from  an  external. -The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as -substitution  of  actual  vehicles  in  development  environment  is  prepared. -Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing -activities  through  a  vehicles  interface  function  at  least. -· Speed -· Shift  position -· The  direction  of  vehicles -· Latitude  and  longitude  of  a  current  position -· Turn  signal -The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, -it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. -VIC  should  fill  the  following  performance  specifications  and  performance. -It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -information  machines  and  equipment  in  2016. -Page  140  of  159 -![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Maximum  number  of  properties  :  4,096 -· Maximum  number  of  property  sets:  1,024 -· Greatest  data  storage  time :  12  hours -It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -information  machines  and  equipment  in  2016. -· Get/Set  method(one  property)  -  0.2ms -· Get/Set  method(property  set  include  30  properties)  -1.3ms -· Subscribe  callback  -  2.5ms  (after  change  of  a  value) -· -GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms -· -GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms -VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility -about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and -attribute  of  vehicles  data. -Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by -various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add -and  change  Vehicle  Interface  without  reconstruction  of  VIC. -Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is -necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. -However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness -vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more -concreteness  vehicles  data  into  one  abstract  vehicles  data. -Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be -mounted  in  the  VIC  itself. -In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be -added  without  reconstruction  of  VIC  is  prepared  for  VIC. -**5.2.12  Telematics  Services** -V2V,  V2I,  RVI,  Traffic  information,  etc. -Page  141  of  159 -![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.13  Window  System** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -and  a  routing  of  user  interactions. -AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple -processes  to  be  rendered  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to -achieve  flicker  less  rendering. -AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- -screen  buffers. -AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying -objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. -AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos -group  available  to  clients  for  their  rendering. -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by -configuration. -AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the -*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a -Page  142  of  159 -![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The -window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES -2.0  API  are  responsible  for  a  hardware  abstraction. -AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. -AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple -displays. -AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, -where  available. -AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware -acceleration  capabilities. -AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs -from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a -vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the -vehicle  reaches  to  the  certain  speed. -AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, -a  touch  panel,  a  control  knob  etc. -AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input -from  available  physical  input  devices. -**6   Security   Services** -Security  framework -6.1  Access  Control -Access  Control  describes  requirements  for  AGL  Access  Control. -Page  143  of  159 -![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. -**6.1.1  Requirements** -AGL  system  must  support  a  system-wide  access  control  mechanism. -**7   Operating   System   Layer** -7.1  Kernel -**7.1.1  Linux  Kernel** -Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new -release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years -for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and -kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the -rest  of  the  open  source  community  provides, -**7.1.1.1  Requirements** -AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. -At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive -industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully -aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by -Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to -accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to -regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with -the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. -AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on -particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. -Page  144  of  159 -![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -7.2  Boot  Loader -7.3  Hypervisor -TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level -virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI -systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android -and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on -top  type1  hypervisor. -**7.3.1  Requirements** -AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that -have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The -processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. -AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following -functionality  shall  be  supported  by  AGL  Linux  “guest”: -· IPC  (with  hypervisor  and  other  “guests”) -· -“paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless -virtualization  abstraction  is  supported  by  hardware) -7.4  Operating  System -**7.4.1  File  Systems** -File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability -as  their  main  characteristics. -· -*Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, -tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process -environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management -techniques. -Page  145  of  159 - - ------------------------------------------------------------------------------- - > **FS  Requirements** > **R-FS  References** - ------------------------------------------------------ ------------------------ - > 6.  File  Systems  (P1) > 2.  btrfs - > > - > 6.1.  Robust  File  System  for  managed  internal > 2.1. - > > - > storage  (P1) > btr - > > - > 6.1.1.  Power  failure  tolerance  (P1) > fsc - > > - > 6.1.2.  Quick  recovery  after  power  loss > k - > > - > (P1) > 3.  ext2 - > > - > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. - > > - > 6.1.4.  On-demand  integrity  checker  (P1) > e2 - > > - > 6.1.5.  Read-only  mode  (P1) > def - > > - > 6.1.6.  Non-blocking  unmounting  (P1) > rag - > > - > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 - > > - > performance  if  it  may  degrade  under > 5.  ext4 - > > - > certain  conditions.  (P2) > 5.1. - > > - > 6.1.8.  File  space  pre-allocation  (P2) > e4 - > > - > 6.1.9.  Meta-data  error  detection  (P2) > def - > > - > 6.1.10.  File  data  error  detection  (P2) > rag - > > - > 6.1.11.  Online  integrity  checking  (P2) > 5.2. - > > - > 6.1.12.  Write  timeout  control  (P2) > e2f - > > - > 6.1.13.  Compression  support  (P2) > sck - > > - > 6.1.14.  Quota  support  (P2) > 6.  vfat - > > - > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS - > > - > 6.1.16.  File  system  event  notifications > 8.  Generic - > - > tools  and - > - > APIs - > - > 8.1. - > - > fan - ------------------------------------------------------------------------------- - -![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -*Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing -designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. -· -*Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual -packages,  and  availability  of  file  system  checking  and  optimization  tools. -![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 -(P2) -6.1.17.  Logical  block  size  control  (P2) -6.1.18.  Snapshots  (P2) -6.2.  File  System  for  non-managed  internal -storage  (P1) - -May  28,  2015 - -otif - -y - -8.2. - -fst - -rim - -6.2.1.  All  P1  requirements  from -FS.1.1.x  list  (P1) -6.2.2.  Wear  leveling  (P1) -6.2.3.  Error  detection/correction  (P1) -6.2.4.  Tolerance  to  flipping  bits  (P1) -6.2.5.  Read/write  disturb  awareness -(P1) -6.2.6.  Bad  block  management  (P1) -6.2.7.  As  many  P2  requirements  from -FS.1.1.x  list  as  possible  (P2) -6.2.8.  Wear  leveling  statistics  (P2) -6.3.  File  Systems  for  removable  storage  (P1) -6.3.1.  Restricted  functionality  from -security  point  of  view  (P1) -6.3.2.  Automount/autounmount  (P1) -6.3.3.  Automatic  synchronous  flushing -of  modified  data  to  physical  media  (P2) -**7.4.1.1  Requirements** -AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -memory),  removable  managed  (USB  stick,  SD  card). -AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, -Page  147  of  159 -![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, -AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. -A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, -and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. -A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power -interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should -not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. -Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- -write)  operation. -A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple -threads  and/or  processes  simultaneously. -A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. -A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical -storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” -command. -AGL  must  support  “lazy”  (delayed)  unmounting. -AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged -file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. -Another  example  is  periodic  fstrim  execution  on  SSD  storage. -A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This -may  be  used  to  minimize  fragmentation  of  frequently  written  files. -A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. -Page  148  of  159 -![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored -data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. -A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. -A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical -media. -A  file  system  should  support  automatic  data  compression. -It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. -AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. -AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. -Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O -performance,  and  decrease  file  fragmentation  impact. -A  file  system  should  allow  creation  of  snapshots. -A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of -erase/program  cycles  is  evenly  distributed  across  all  device  blocks. -A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. -A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also -actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power -interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the -time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. -A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb -Page  149  of  159 -![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known -techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a -fresh  block  after  detected  error  correction. -A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system -users. -Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. -A  file  system  must  support  noexec,  and  nodev  mount  options. -A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and -automatically  unmount  it  when  unplugged. -A  file  system  must  support  sync  mount  option. -AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -memory),  removable  managed  (USB  stick,  SD  card). -**7.4.2  Resource  Control** -In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be -higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource -allocation  for  each  process  and/or  process  group. -(cgroups) -**7.4.2.1  Use  Case  and  Role** -If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current -position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. -On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned -Page  150  of  159 - - ------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- -------------- ---------------------------------------------------------------- - > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority - > - > process  and/or  process  group  should  be  assigned - > - > more  resource. - - > 2 > Time  slot > To  share  resource  per  time  slot. - - > 3 > Release > Forced  release  of  partially  or  whole  allocated - > - > resource. - - > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate - > - > resource  per  defined  process  group. - ------------------------------------------------------------------------------------------- - -![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  higher  priority  than  others. -Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at -the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. -Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. -AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network -bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. -**Table  9-34  :  Functions  of  System  Resource  Management** -**7.4.2.2  Requirements** -7.4.2.2.1  Priority -System  provides  a  mechanism  to  set  resource  priority  per  each  process. -Page  151  of  159 -![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. -This  interface  must  be  called  from  other  process. -CPU  resource  must  support  “priority”  based  resource  management. -Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the -status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. -Resource  Manager  should  log  the  status  of  resources  using  by  system. -Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of -kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high -priority  tasks. -7.4.2.2.2  Time  Slot -When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a -mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each -processes. -System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. -System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage -bandwidth  and  network  bandwidth. -Scheduler  should  detect  the  status  of  resources  for  each  thread. -Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. -Scheduler  should  guarantee  that  threads  can  run  periodically. -Scheduler  should  control  the  dispatches  that  occur  extremely. -Page  152  of  159 -![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -7.4.2.2.3  Release -System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by -specific  process. -System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. -7.4.2.2.4  Grouping -System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource -management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same -attributes  to  grouped  processes  altogether. -System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. -System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and -network  bandwidth. -**7.4.3  Startup/Shutdown  Control** -Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a -user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending -on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which -boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and -“dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. -**7.4.3.1  Use  Cases** -(1)  Static  Modification  of  Boot/Shutdown  Order -a. -Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration -To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown -for  all  programs  running  on  the  target  device. -Page  153  of  159 -![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b. -Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development -In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed -program  in  target  programs. -c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update -Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. -(2)  Dynamic  Modification  of  Boot/Shutdown  Order -a. -Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using -It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to -be  operated  by  priority  when  ACC  turns  ON. -b\. Prioritized  Boot  of  Update  Functionalities -Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned -ON. -**7.4.3.2  Requirements** -Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. -Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that -has  been  configured. -Boot/Shutdown  Control  shall  start  independent  components  in  parallel. -Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. -Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that -has  been  configured. -Page  154  of  159 -![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. -**7.4.4  Database** -Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee -database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system -database  engine  is  rich  set  of  bindings  to  various  programming  languages. -Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References -hierarchy. -1.  Power  failure  tolerance  (P1) -2.  Quick  recovery  after  power  loss  (P1) -3.  Multi-threaded  I/O  (P1) -4.  API  bindings  for  C  programming  language -5.  On-demand  integrity  checker  (P2) -DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write -DB  transactions. -DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. -Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power -failure  on  idle  system. -DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or -processes  simultaneously. -DB  engine  API  must  be  available  for  C-based  applications. -DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. -DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power -interruption  during  adding  some  data. -Page  155  of  159 -![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, -such  as  vehicle  information  database  and  databases  at  data  center. -And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. -Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption -during  merging. -**7.4.5  System  Update** -Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are -numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, -bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to -power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. -System  Update  module  should  have  a  Robust  version  up  function. -System  Update  moduleshould  have  a  system  difference  version  up  function. -There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -apt  of  Linux  distribution). -There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -apt  of  Linux  distribution). -Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. -If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should -be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. -If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during -update)  should  be  detected  and  the  system  should  restart. -Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. -Page  156  of  159 -![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Memory  usage  for  difference  update  should  be  maximum  1Mbyte. -Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. -System  Update  moduleshould  have  full  version  up  function  for  whole  system. -Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow -mass  update. -There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. -If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -7.5  Device  Drivers -Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. -**7.5.1  Peripherals** -Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. -The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and -data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For -optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less -than  50  s/byte  average. -The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles -and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or -EEPROM  is  not  allowed. -Page  157  of  159 -![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be -fast.  (target  <1ms/byte) -N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. -**7.5.2  Graphics  Drivers** -Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. -This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. -**7.5.3  Video  Drivers** -Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video -codecs  will  nearly  always  be  hardware  based. -**7.5.3.1  Requirements** -The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video -functionality. -**7.5.4  Audio  Codecs** -**7.5.4.1  Requirements** -Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are -implemented  in  hardware. -Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs -that  are  required  for  AGL-based  products  and  not  supported  in  hardware. -**7.5.5  Automotive  Devices** -Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or -*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* -Page  158  of  159 -![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for -navigation  or  an  air  bag  sensor  for  a  telematics  system. -**8   Notices** -Linux  is  a  registered  trademark  of  Linus  Torvalds. -The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. -Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. -Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. -MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. -AirPlay  is  a  trademark  of  Apple,  Inc. -Page  159  of  159 diff --git a/agl-specs-v1.0/01-overview.md b/agl-specs-v1.0/01-overview.md deleted file mode 100644 index 75a6410..0000000 --- a/agl-specs-v1.0/01-overview.md +++ /dev/null @@ -1,94 +0,0 @@ ---- - -title : AGL Specification Overview -author: imported from Doors-ng by Fulup(iot.bzh) -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -## 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 InVehicle Infotainment(IVI)  systems,  additional  use  cases  such  as  instrument  clusters  and  and -telematics  systems  will  eventually  be  supported.  AGL  has  participants  from  the  Automotive, -Communications,  and  Semiconductor  Industries  and  welcomes  contributions  from  individual -developers. - -By  leveraging  the  over  \$10B  of  investment  made  in  the  Linux  kernel  and  other  open  source -software  projects,  the  AGL  Workgroup: - -Enables  rapid  software  innovation  for  automotive  suppliers  to  keep  up  with  the  demand -from  consumers  for  better  IVI  experiences· - -Utilizes  the  talents  of  thousands  of  open  source  software  developers  dedicated  to -maintaining  the  core  software  in  areas  like  the  Linux  kernel,  networking,  and -connectivity,  used  in  systems  across  numerous  industries -The  goals  of  the  Automotive  Grade  Linux  Workgroup  are  to  provide: - -An  automotive-focused  core  Linux  operating  system  stack  that  meets  common  and -shared  requirements  of  the  automotive  ecosystem  with  a  broad  community  of -support  that  includes  individual  developers,  academic  organizations  and  companies. - -A  transparent,  collaborative,  and  open  environment  for  Automotive  OEMs,  Tier  One -suppliers,  and  their  semiconductor  and  software  vendors  to  create  amazing  in-vehicle -software. - -A  collective  voice  for  working  with  other  open  source  projects  and  developing  new  open -source  solutions. - -An  embedded  Linux  distribution  that  enables  rapid  prototyping  for  developers  new  to -Linux  or  teams  with  prior  open  source  experience -This  results  in  faster  time  to  market  by  jump-starting  product  teams  with  reference  applications -running  on  multiple  hardware  platforms. -Page  5  of  159 - - **Term** | **Definition** - ----------| ------------------------------------------ - A2DP | Advanced  Audio  Distribution  Profile - AGL | Automotive  Grade  Linux - AVRCP | Audio  Video  Remote  Control  Profile - FS | File  System - GPS | Global  Positioning  System - GPU | Graphical  Processing  Unit - -Automotive Grade Linux Requirements Spec v1.0![](media/picture95.png) -{: class="image"} - - -## Document  Scope - -[comment]: May  28,  2015 -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. - -## 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 diff --git a/agl-specs-v1.0/02-architecture.md b/agl-specs-v1.0/02-architecture.md deleted file mode 100644 index 7bad304..0000000 --- a/agl-specs-v1.0/02-architecture.md +++ /dev/null @@ -1,13 +0,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 diff --git a/agl-specs-v1.0/03-homescreen.md b/agl-specs-v1.0/03-homescreen.md deleted file mode 100644 index 22a56c3..0000000 --- a/agl-specs-v1.0/03-homescreen.md +++ /dev/null @@ -1,8246 +0,0 @@ ---- - -title : App/HMI HomeScreen -author: imported from Doors-ng by Fulup(iot.bzh) -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -## Overview -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. - -** 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 - -## 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. - -## 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. - -## 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. - -## 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 - -##  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 - - -## 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 -##  Requirements - -### 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. - -###  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. - -###  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 -### 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. - -##   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 - -### Application  Manager -Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application -lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. - -###  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. - -###  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 -####  Use Case -Please  refer  “screen  resource  control”  of  Policy  Manger  section. - -####  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 -#### Requirements -4.1.2.3.1  Window  Drawing -System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and -make  invisible. -System  must  provide  a  mechanism  to  create  and  delete  surface. -When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. -This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. -System  must  provide  a  mechanism  to  change  visibility  per  each  surface. -And,  provide  an  interface  to  change  visibility. -All  the  surfaces  must  be  set  to  invisible  for  initial  state. -Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. -System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between -previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. -*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt -Page  23  of  159 -![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -from  size  of  surface. -If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  squeeze. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  using  combination  of  scaling  and  trimming  function. -That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  using  combination  of  scaling  and  background  color. -That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This -mechanism  makes  it  possible  to  do  “letterbox”  method. -4.1.2.3.2  Overlay  of  Multiple  Windows -System  must  provide  a  mechanism  to  create  and  delete  a  layer. -Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by -their  z-order  attribute. -Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, -then,  attached  layer  must  be  changed. -System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. -Area  is  a  concept  which  defines  where  to  display  in  specific  layer. -System  must  provide  a  mechanism  to  attach  surface  to  any  layer. -Also,  system  must  be  able  to  change  attached  layer. -And,  provide  an  interface  to  attach  and  change. -Page  24  of  159 -![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. -And,  provide  an  interface  to  assign  surface  to  any  area. -System  must  provide  a  mechanism  to  change  visibility  per  each  layer. -That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the -same  time. -And,  provide  an  interface  to  change  visibility  per  layer. -Initial  state  must  be  set  to  invisible. -System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each -layer,  and  disposition  of  surfaces. -4.1.2.3.3  Visual  Affect -System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was -happened. -Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -- Duration -Animation  type -System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -out. -Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -plug-in  architecture. -System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. -Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -· Duration -Animation  type -System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -Page  25  of  159 -![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -out. -Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -plug-in  architecture. -System  must  provide  a  mechanism  to  make  effect  to  surface. -And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. -System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. -System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness -System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in -architecture. -4.1.2.3.4  Frame  Rate  Control -System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of -application. -System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval -of  application. -This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live -thumbnail  and  moving  surface. -4.1.2.3.5  Multiple  Hardware  Layer  Support -If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use -hardware  layers  efficiently. -· -Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers -Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback -4.1.2.3.6  Reduced  Dependency  of  Hardware -Page  26  of  159 -![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of -each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, -such  as  by  using  re-configuration. -4.1.2.3.7  Multi  Window -AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple -processes  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. -4.1.2.3.8  Compatibility -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a -standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any -hardware  specific  API. -A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. -**4.1.3  Policy  Manager** -**4.1.3.1  Overview** -4.1.3.1.1  Purpose -Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy -Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle -Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of -resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called -Page  27  of  159 -![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -“System  resources”  such  as  CPU  and  memory. -4.1.3.1.2  GUI  Resources -(1)  Definition -·  About  Control  of  GUI  Resources -AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, -speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user -or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. -**Figure  7-1:  GUI  resources** -Page  28  of  159 -![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy -Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too -much  information  distracts  the  attention  of  driver  from  driving  operations. -·  Associated  Software  Architecture -The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources -control  is  as  below. -**Figure  7-2:  Associated  Software  Expected  Use  Case** -Page  29  of  159 - - ----------------------------------------------------------------------------------------------------------------------------------------------------- - > **No** > **Component** > **Description** - > - > **.** - ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- - > 1 > Homescreen > Request  to  control  of  GUI  resources. - - > 2 > Applications > Request  to  output  or  input  of  GUI  resources. - - > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And - > - > then  provide  the  corresponding  feature  to - > - > applications  UI  such  as  input  limitation  and - > - > changing  the  theme. - - > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the - > - > definition  of  GUI  resources  such  as  role  by - > - > application  configurations. - - > 5- > Vehicle > Window  Manager - > > - > 1 > Info - > - > Control - - > 5- > Sound  Manager - > - > 2 - - > 5- > Input  Manager - > - > 3 - - > 5- > Vehicle  Info  Distributor - > - > 4 - - > 5- > User  Manager - > - > 5 - ----------------------------------------------------------------------------------------------------------------------------------------------------- - -![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  is  related  with  the  below  components. -(2)  Role -Page  30  of  159 - - ----------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ------------------------------ ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of - > > - > GUI  resource > GUI  resources. - > - > (2)  Judgment  the  GUI  resource  owner  according  to - > - > external  conditions. - - > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to - > - > judgment. - > - > (2)  Notify  the  driving  mode  and  day  night  mode - > - > that  is  calculated  by  external  conditions. - ----------------------------------------------------------------------------------------------------- - -![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  has  the  below  role. -Page  31  of  159 -![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  7-3:  Definition  of  Role** -GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each -resource  type  are  as  follows: -a.  Screen  Resource -a-1.  External  Condition  Collection -Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. -**Figure  7-4:  Definition  of  screen  resource** -•  Concept  of  Display,  Layer,  Layout  and  Area -AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one -or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout -Page  32  of  159 -![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics -window. -The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on -objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was -used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than -layer-2. -Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, -application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. -“Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and -setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert -and  enlarged  view. -When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On -the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” -layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. -From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- -order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered -by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to -individual  layer. -•  Concept  of  Layer  Owner,  Role  and  Surface -“Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of -that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of -area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy -Manager. -“Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” -change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. -One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics -window  to  display  into  one  area. -Page  33  of  159 -![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface -drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example -to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then -corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface -is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & -scan”. -**Figure  7-5:  Definition  of  Surface** -•  Subdivision  of  “Interrupt”  Layer -Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main -surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main -surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding -“Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message -is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. -According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described -as  Table  7-3. -Page  34  of  159 - - --------------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- -------------------------------------------------------- ----------------------- - > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation - > - > application  requests  this  layer  at  first  time. - - > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of - > - > navigation - - > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message - > > - > screen  service  (e.g.  Homescreen)  requests > popup - > - > this  layer. - - > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard - > > - > keyboard > Typically,  software  keyboard  service - > - > requests  this  layer. - --------------------------------------------------------------------------------------------------------- - - ------------------------------------------------------------------------------------------------------ - > **No** > **Contents** > **Summary** > **Example** - ---------- ---------------- ------------------------------------------------------- ------------------ - > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation - > - > service)  role. - - > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view - ------------------------------------------------------------------------------------------------------ - -![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -a-2.  Judgment  of  Priority  of  GUI  Resource -Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role -is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy -Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. -Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software -Page  35  of  159 -![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is -popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). -**Figure  7-6:  Definition  of  Role  and  Sub  role** -The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display -has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. -In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" -layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub -role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” -role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. -a-3.  GUI  resource  control -Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -directly. -Page  36  of  159 -![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -There  are  three  types  of  screen  resource  control: -One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. -Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was -assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. -Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue -z-order  information  for  each  layer. -b.  Sound  Resource -b-1.  External  Condition  Collection -Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. -**Figure  7-7:  Definition  of  Sound  Resource** -•  Zone -Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can -play  at  the  same  time. -Page  37  of  159 - - ------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- ---------------------------------------------- ------------------------- - > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media - > - > player - - > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of - > - > Navigation - - > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound - > - > requests  this  type. - ------------------------------------------------------------------------------------------------- - -![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -•  Sound  type -Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource -owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper -sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific -zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each -sound  stream  must  assign  to  individual  sound  type. -AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. -•  Stream -Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in -stream. -b-2.  Judgment  of  Priority  of  GUI  resource -Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role -is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy -Manager.  Figure  7-8  describes  the  definition  of  role. -Page  38  of  159 -![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  7-8:  Sample  Role** -The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that -is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or -different  sound  type  are  not  switched.  They  are  mixed. -b-3.  GUI  Resource  Control -Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -directly. -There  are  two  types  of  sound  resource  control: -One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for -sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound -Page  39  of  159 -![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -stream  and  to  start  play  latest  area  owner. -Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback -simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy -Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and -music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music -playback. -c.  Input  Resource -c-1.  External  Condition  Collection -Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. -**Figure  7-9:  Definition  of  Input  Resource** -•  Device  Name -Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. -•  Event  Type -Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and -temperatures. -c-2.  Judgment  of  Priority  of  GUI  resource -Page  40  of  159 -![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device -name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy -DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the -judgment  as  below. -**Figure  7-10:  Definition  of  routing  rule** -OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. -c-3.  GUI  Resource  Control -Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. -Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. -4.1.3.1.3  System  Resources -(1)  Definition -Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy -Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. -Page  41  of  159 - - ---------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ----------------------------- ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according - > - > to  external  condition  change. - > - > 2.  Kill  process(s)  forcibly  according  to  external - > - > condition  change. - ---------------------------------------------------------------------------------------------------- - -![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, -target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. -**4.1.3.2  Requirements** -4.1.3.2.1  Screen  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system -uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive -information  must  include  as  follows. -a.  ID -b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) -c.  DPI -d.  Connected  ECU -Page  42  of  159 -![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be -able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list -according  to  current  layout  of  each  display. -The  receive  definition  must  include  the  follows. -a.  ID -b.  Area  list -System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface -by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the -device. -The  receive  request  must  include  the  follows. -a.  Layout  ID -b.  ID -c.  Area  position  (Coordinate  of  the  upper-left) -d.  Area  size  (Length  \*  Width) -System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify -the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. -a.  Display  ID -b.  Layout  ID -System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the -providing  resource  using  it  when  the  request  is  collision. -The  receive  information  must  include  the  follows. -a.  Role -b.  Priority -System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge -driving  mode. -The  receive  information  must  include  the  follows. -a.  Velocity -Page  43  of  159 -![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Brake  status -System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge -day  night  mode. -The  receive  information  should  include  the  follows. -a.  The  brightness  of  the  interior -System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the -providing  resource  using  it. -System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should -judge  the  providing  resource  using  it. -(2)  Judgment  of  Priority  of  GUI  Resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical -resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the -resource. -The  receive  request  must  include  as  follows. -a.  Role -b.  Layer  type -The  receive  request  should  include  as  follows. -c.  Display  ID -System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by -priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on -the  specified  area  on  the  specified  layer. -The  receive  request  must  include  as  follows. -a.  Role -Page  44  of  159 -![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Layer  ID -The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. -Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the -related  basic  type  area. -c.  Area  ID -**Figure  7-11:  Sequence  to  display** -System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. -In  this  request,  requester  should  choose  below  options. -a. -Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, -but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should -be  refused. -b. -Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen -resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher -priority,  then,  only  screen  resource  should  be  assigned  to  requester. -Page  45  of  159 -![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system -running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. -The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal -request. -a.  Effective  period  (Can  set  unlimited) -System  should  not  raise  the  other  surface  above  its  during  effective  period. -System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -a.  The  effect  at  the  transition -b.  The  effect  of  display  surface -System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are -sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all -layers  will  be  superimposed  by  z-order. -System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. -System  must  hide  the  surface  that  has  too  much  information. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Visible  /  Invisible -b.  Change  position -c.  Raise -The  receive  request  must  include  as  follows. -i.  Surface  ID  \*Only  case  of  visible. -ii.  Display  ID  \*Only  case  of  visible. -iii.  Layer  ID  \*Only  case  of  visible. -Page  46  of  159 -![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. -v.  Size  (Length  \*  Width)  \*Only  case  of  visible. -System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. -a.  The  effect  at  the  transition -b.  The  effect  of  display  surface -4.1.3.2.2  Sound  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone -information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as -follows. -a.  ID -b.  Sound  device  ID -System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses -sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must -include  as  follows. -a.  ID -(2)  Judgment  of  Priority  of  GUI  resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -request  during  system  running. -Page  47  of  159 -![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  receive  request  must  include  as  follows. -a.  Role -b.  Zone  ID -c.  Sound  type  ID -System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during -system  running. -The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal -request. -a.  Effective  period  (Can  set  unlimited) -System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner -by  other  request  on  same  area  during  effective  period. -System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -a.  The  effect  at  the  transition -b.  The  effect  of  output  sound -System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more -resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority -of  resources  that  is  related  to  role. -\*  Boundary  of  the  role  between  Policy  Manager  and  application. -Page  48  of  159 -![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Figure  7-12:  Boundary  of  role  (Case  of  reverse) -System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system -should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. -For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound -from  request  history  based  on  the  priority. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Mute  /  Unmute -b.  Change  zone -The  receive  request  must  include  as  follows. -i.  Stream  ID -ii.  Device -In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. -iii.  Channel  ID -Page  49  of  159 -![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. -a.  The  effect  at  the  transition -b.  The  effect  of  output  sound -4.1.3.2.3  Input  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses -input  device  information  with  to  control  input  event  to  other  system.  The  receive  information -must  include  as  follows. -a.  ID -System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses -input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must -include  as  follows. -a.  ID -b.  Related  event  IDs -(2)  Judgment  of  Priority  of  GUI  resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -request  during  system  running. -The  receive  request  must  include  as  follows. -a.  Input  device  ID -Page  50  of  159 -![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Event  type  ID -System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the -limitation  routing  rule  of  policy  DB. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Set  the  routing  rule -The  receive  request  must  include  as  follows. -i.  Input  device  ID -ii.  Event  type  ID -The  receive  request  must  include  either  as  follows. -iii.  The  allowed  application -iv.  The  denied  application -System  should  provide  a  mechanism  to  set  the  following  information. -a.  Application  that  has  active  surface -System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This -feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen -changes  the  active  surface. -4.1.3.2.4  System  Resources -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager -to  decide  proper  system  resource. -Page  51  of  159 -![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  must  detect  creation  and  deletion  of  process. -To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created -process. -Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to -other  active  processes. -To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to -identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each -active  process. -Policy  Manager  must  detect  current  memory  consumption  periodically. -To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each -process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were -thought  as  not  so  important  process. -Policy  Manager  must  detect  current  CPU  consumption  periodically. -To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep -system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected -busy  state. -System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. -Application  status  includes  as  below. -· GUI  resource  status,  such  as  foreground  or  background. -· -Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must -resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last -application  to  resume  quickly  as  much  as  possible. -(2)  System  Resource  Control -System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process -group  according  to  external  conditions. -According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to -target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups -Page  52  of  159 -![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -will  be  used) -System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. -4.1.3.2.5  Resource  Management -Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy -Manager,  Connection  Manager. -Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. -Each  resource  request  shall  be  in  form  a: -AppID, -SourceID, -RequestorZoneID, -NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), -Required  Resource  List. -Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin -Speakers,  HeadPhones) -Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) -Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, -Tuners  etc.) -Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request -from  resource  requestors. -Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. -Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) -Page  53  of  159 -![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list -are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) -Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system -through  status  update. -Resource  Management  shall  support  stacking/queuing  of  resource  requests. ->  Receive  the  requests  from  the  resource  requestors. ->  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy -Manager. ->  Add  the  validated  requests  into  a  priority  queue. ->  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. ->  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it -shall  be  removed  from  the  queue. -Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier -request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it -shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. -If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the -requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. -If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant -some/all  of  the  resources  requested  by  the  requestor. -Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an -existing  resource  request. -Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of -policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs -for  the  policy  decision: ->  Currently  Free  or  InUse  Sink  status ->  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) -Page  54  of  159 -![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 ->  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. -Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a -request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the -policy  decision: ->  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept -pending. ->  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. -At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by -resource  requestor: ->  Zone  ID ->  Allocated  Source  Instance ->  Allocated  Sink  Instance ->  Mute  status -Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality -(e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to -the  resource  management  policy. -Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature -functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). -Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: -AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have -same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, -the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. -Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, -AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource -request  will  be  the  one  that  is  granted  the  resource. -A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. -It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. -Page  55  of  159 -![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. -It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource -Manager  if  the  resource  is  no  longer  needed. -Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all -available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once -the  request  is  granted  against  the  set  policy. -Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. -Possible  connection  states  are  Active  or  Passive. ->  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be -active. -Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. ->  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be -passive. -Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same -AMFM  source  on  Rear  headphone  sink. -Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink -connection  using  the  underlying  platform  support. -Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink -connection  using  the  underlying  platform  support. -Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is -removed/released. -Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is -re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. -Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. -Page  56  of  159 -![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready -to  be  used  for  audio  routing. -Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio -routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. -Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. -Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which -source  instance. -Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: ->  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. -System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -Headphones  shall  not  be  required  to  support  any  foreground  sinks. -In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a -source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source -(if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). -As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not -disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background -connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. -Page  57  of  159 -![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State -Manager. -It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. -It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on -current  system  scenario. -E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call -is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a -pending  request. -It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. -It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. -It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video -resources  and  update  its  internal  status  accordingly. -On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active -connections  and  reconnect  or  disconnect  if  required. -E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. -Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of -connections  shall  be  rebuilt  with  Amp. -It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. -Page  58  of  159 -![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying -platform  support. -It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the -underlying  platform  support. -It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. -It  shall  provide  an  interface  to  unmute  an  audio  sink. -System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -Headphones  shall  not  be  required  to  support  any  foreground  sinks. -It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -**4.1.4  Sound  Manager** -A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from -two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a -policy  manager  manages  a  mediation  rule. -Page  59  of  159 - - ---------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ------------------------------------------------------------ - > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). - - > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume - > - > control  of  each  sound  streams. - - > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, - > - > ·     When  changing  sound  stream.  E.g.  fade-in, - > - > fade-out  and  cross-fade. - - > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce - > > - > hardware > dependency  of  hardware.  Well-defined  interface - > - > also  makes  it  possible  to  increase  the  effect  of - > - > portability  and  development  cost. - ---------------------------------------------------------------------------------------------------- - -![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a -passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound -resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. -Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like -volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server -to  implement  automatic  audio  policies. -**4.1.4.1  Use  Case** -Please  refer  “sound  resource  control”  of  Policy  Manger  section. -Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. -**4.1.4.2  Requirements** -Page  60  of  159 -![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4.1.4.2.1  Routing  Sound  Streams -System  must  provide  a  mechanism  to  manage  sound  “zone”. -Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a -zone  and  how  to  manage  zone. -System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each -channels  of  each  sound  device. -One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists -of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. -For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is -arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when -outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower -musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than -music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound -device. -The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more -zones. -Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the -present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the -mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. -System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. -System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. -All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. -System  must  provide  a  mechanism  to  control  sound  stream. -Control  of  a  sound  stream  is  as  follows. -· -Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound -stream. -· -Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound -Page  61  of  159 -![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -stream. -Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. -4.1.4.2.2  Mixing  Level  Control -The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to -the  same  zone  according  to  a  policy  manager's  arbitration. -System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. -System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream -requested  to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating -the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. -System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested -to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted -sound  stream  was  ended. -System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream -requested  to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound -stream  was  ended. -4.1.4.2.3  Sound  Effect -When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. -System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. -System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin -architecture. -Page  62  of  159 - - ------------------------------------------------------------------------------------------------------------------------- - > **No.** > **Input  type** > **Associated  device** > **Description** - ----------- ------------------- -------------------------- -------------------------------------------------------------- - > 1 > Key > Steering  switch > Simple  key  event. - > - > Deliver  to  application. - - > 2 > Keyboard > Virtual  keyboard > Keyboard  event. - > - > Deliver     to     application,     then     use     input - > - > method  backend  if  needed. - - > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. - > - > Also  supports  double  click  and  multi-touch - > - > capability. - > - > Deliver  to  application. - - > 4 > Sound > Microphone > Sound  input. - ------------------------------------------------------------------------------------------------------------------------- - -![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4.1.4.2.4  Reduced  Dependency  of  Hardware -Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels -of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means -which  does  not  need  rebuild  of  systems,  such  as  a  configuration. -**4.1.5  Input  Manager** -The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application -depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each -input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering -switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. -**4.1.5.1  Use  Case** -Please  refer  “input  resource  control”  of  Policy  Manger  section. - - --------------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ----------------------------------------------------------------- - > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to - > - > application  readable  event  name,  such  as  “volume - > - > up”  and  “right  arrow”. - - > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified - > - > application. - --------------------------------------------------------------------------------------------------------- - -![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Deliver  to  application  or  voice  recognition -engine. -Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. -**4.1.5.2  Requirements** -**4.1.5.3  Abstract  Device  Event** -System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. -Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional -equipment. -**4.1.5.4  Event  Delivery** -System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. -System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” -and  “destination  application  id”. -Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by -UIM.2.1.2. -Page  64  of  159 -![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. -System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. -System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on -delivery  rule  defined  in  UIM.2.1.1. -System  must  provide  a  mechanism  to  inhibit  any  event  delivery. -This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. -**4.1.6  User  Manager** -**4.1.6.1  Use  Case** -**4.1.6.2  Personal  Identification** -User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a -person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. -**4.1.6.3  User  Preference** -Multi-user  environment  provides  same  user  experience  for  each  user. -Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including -other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data -sharing  from  your  home  and  your  office. -Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be -provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. -Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user -experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, -*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is -Page  65  of  159 -![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. -**Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** -**4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** -When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If -Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is -important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s -preference. -**Figure  7-25  :  User  data  sharing  between  cars** -Page  66  of  159 -![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**4.1.6.5  Seamless  Data  Sharing** -Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and -smart-phones,  home  networks  and  accessing  from  your  offices. -**Figure  7-26  :  User  data  sharing  over  the  cars** -**4.1.6.6  Role** -**Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above -purpose  and  use  cases. -**Table  7-17  :  Role  of  User  Manager** -**No.** **Role** **Description** -Page  67  of  159 -![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -1 User  identification -Provide  a  mechanism  to  identify  user,  such  as  user -name  and  password  pair,  smart  key  and  biometrics. -Provide  a  mechanism  to  log-in  to  the  IVI  system  as -a  specified  user. -When a different user logs in, proper user -preference  for  the  user  must  be  applied,  and -resume  last  state  of  corresponding  user. -Also,  each  application  can  store  application’s  data -per  user.  In  such  cases,  proper  user  data  must  be -applied  when  a  different  user  logs  in. -2 User  preference -Provide  a  mechanism  to  apply  user  preference  of -logged-in  user. -User  preference  includes  the  following  data. -· User  interface,  such  as  locale  and  wall- -paper. -· Resume  last  application’s  status  of  specified -user. -· Application  specific  data. -3 User  data  management -Provide  a  mechanism  to  manage  cloud  based  user -data. -The  following  capabilities  are  required. -· Download  user  data  of  the  logged-in  user -from  the  cloud. -· Update  cloud  data  if  the  user  data  was -updated  by  user  operation  or  otherwise. -· Periodically  sync-up  w/  cloud  because  user -data  may  be  updated  by  other  devices. -In  addition  to  the  above  basic  capabilities,  user  data -cache  is  essential  for  a  car,  since  a  car  may  not -always  have  a  reliable  network  connection. -4 Security Because  cloud  based  sharing  user  data  may  be -accessed  from  any  place,  user  data  must  be -protected  from  unexpected  data  access. -Page  68  of  159 -![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -So,  IVI  system  must  provide  security  mechanism -regarding  accessing  to  cloud  based  user  data. -**4.1.6.7  Requirements** -4.1.6.7.1  User  Identification -System  must  provide  a  mechanism  to  identify  logged-in  user. -System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to -identify  logged-in  user. -System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For -example,  using  NFC. -System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. -4.1.6.7.2  User  Preference -When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the -currently  logged-in  user. -System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. -- Locale  settings -- UX  theme -Wall  paper -System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized -user  experience. -Page  69  of  159 -![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in -user’s  application  data  automatically. -When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last -status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the -system.  Specifically,  last  status  includes  the  following. -- Foreground  applications.  That  means  displayed  applications. -Background  applications. -When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. -System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. -System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. -4.1.6.7.3  User  Data  Management -System  must  provide  a  mechanism  to  manage  user  data. -AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user -preference. -User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but -also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and -home  electronics. -System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to -application  by  using  cloud  based  user  data. -System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data -of  the  IVI  system. -When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to -the  cloud. -Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide -Page  70  of  159 -![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. -Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a -mechanism  to  cache  downloaded  user  data. -If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as -possible. -4.1.6.7.4  Security -Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to -protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. -System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. -- -System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must -authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, -smartphone  or  PC. -- -System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. -- -System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection -against  falsification  of  data  from  unauthorized  access  or  illegal  access. -- -Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide -user  data  only  to  the  authorized  user. -Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must -provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to -include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against -cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. -4.2  Web  HMI -Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. -**4.2.1  Web  API** -Page  71  of  159 -![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service -function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio -visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, -Photo,  etc.) -Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of -Audio  Visual  API  is  shown  in  Figure  6-1. -**Figure  6-1:  Use  case  of  Audio  Visual  API** -**4.2.1.1  Requirements** -Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. -· Select  content  using  URL -· -Select  content  using  contents  list  provided  by  multimedia  subsystem -Page  72  of  159 -![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, -DVD,  BT-Audio,  Photo,  etc.) -· Play -· Pause -· Fast-forward -· Rewind -· Track  up -· Track  down -· Select  playmode  (Repeat/Random) -Audio  Visual  API  must  provide  API  to  control  a  volume. -· Volume  up -· Volume  down -· Mute -Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. -Audio  Visual  API  must  provide  API  for  notifications. -· The  case  that  playback  state  is  changed -· The  case  that  Audio  Visual  contents  is  add  /  removed -Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. -· Change  the  frequency. -· Change  the  broadcasting  stations. -· Receive  the  list  of  broadcasting  stations. -· Select  the  preset  channel. -· Get  the  information  of  the  broadcasting  station. -Audio  Visual  API  must  provide  API  to  play  digital  radio. -· Store  the  broadcast  program  information. -Page  73  of  159 -![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Get  the  broadcast  program  information. -· Get  the  play  time. -· Play  the  radio  broadcast  cached. -AGL  System  must  support  a  web  API  to  access  Vehicle  information. -AGL  System  must  support  web  API  to  control  STT/TTS  daemon. -AGL  System  must  support  web  API  to  control  navi  engine. -AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web -apps. -AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app -and  a  native  app. -AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider -should  be  able  to  restrict  subscriber. -AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. -AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, -Network  Information -AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG -AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio -AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, -server  sent  events,  session  history  of  browsing  context -*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL -Page  74  of  159 -![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 -The  iframe  element,  Content  Security  Policy  1.0. -AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications -AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing -control,  Navigation  timing -AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation -AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, -Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy -AGL  System  must  support  Khronos  WebGL  API. -**4.2.2  Web  Runtime** -The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access -the  AGL  Application  Framework  and  Services. -**4.2.2.1  Requirements** -AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., -installation/removal). -AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, -view  generation,  rendering,  etc.) -AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add -better  device/platform  integration. -Page  75  of  159 -![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to -categorize  apps  with  different  privileges. -System  must  provide  high  level  GUI  components  for  Web  application. -At  least,  below  components  are  required. -· Text  labels -· Button -· Radio  button -· Check  box -· Tab  panel -· Animation  (e.g.  MNG,  GIF  animation) -· Slider -· Accordion  list -· Anchor -· Text  input  form -· Dropdown  list  box -· Date  picker -4.3  Native  HMI -The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written -using  Javascript  or  other  web  technologies. -**4.3.1  Native  App  Runtime** -The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to -access  the  AGL  Application  Framework  and  Services. -**4.3.1.1  Requirements** -System  must  provide  high  level  GUI  components  for  native  application. -Page  76  of  159 -![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -At  least,  below  components  are  required. -· Text  labels -· Button -· Radio  button -· Check  box -· Tab  panel -· Animation  (e.g.  MNG,  GIF  animation) -· Slider -· Accordion  list -· Anchor -· Text  input  form -· Dropdown  list  box -· Date  picker -**4.3.2  Native  Application  Framework** -The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an -SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that -framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the -application  framework  provides  for  its  applications. -**5   Services   Layer** -The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the -services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces -remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime -modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid -unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer -interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces -provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may -choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework -runtime  to  adjust  to  any  new  interfaces, -Page  77  of  159 -![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1  Platform  Services -Platform  Services  Layer.  Conventional  Linux  platform  services -**5.1.1  Bluetooth** -This  document  describes  requirements  regarding  registration,  (dis)connection  and  device -information  management  between  Bluetooth  device  and  infotainment  system.  Necessary -Bluetooth  profiles  in  automotive  use  case  are  defined  here. -**5.1.1.1  Requirements** -The  Telephony  system  shall  be  designed  to -support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR -without  hardware  upgrade. -A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: -· Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) -· HFP  (Hands  Free  Profile) -· OBEX  (Object  Exchange) -· OPP  (Object  Push  Profile) -· PBAP  (Phonebook  Access  Profile) -· SPP  (Serial  Port  Profile) -· SDAP  (Service  Discovery  Access  Profile) -If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music -from),  the  system  shall  also  support  the  following  incremental  BT  profiles: -· A2DP  (Advanced  Audio  Distribution  Profile) -· AVRCP  (Audio  Visual  Remote  Control  Profile) -The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the -Page  78  of  159 -![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of -generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in -encryption  key  length  negotiation. -When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as -default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority -scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration -time. -The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is -10  meters  and  maximum  power  is  2.5  mW  (4  dBm). -The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall -allow  using  five-slot  packet  transmission  for  faster  data  rate. -The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a -standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. -vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are -often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain -name  and  address  information,  phone  numbers,  and  e-mail  addresses. -vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, -LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, -URL,  UID,  Version,  and  KEY  properties. -vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: -MIME  Content-Type  for  Directory  Information -vCard  MIME  Directory  Profile -It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with -the  vCard  version  2.1  properties. -The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any -associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is -not  full. -The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO -Page  79  of  159 - - ------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **Support  in  HF** > **AGL** - ----------- ------------------------------------------------------------- ----------------------- ----------- - > 1 > Connection  management > Mandatory > x - - > 2 > Phone  status  information > Mandatory > x - - > 3 > Audio  Connection  handling > Mandatory > x - - > 4 > Accept  an  incoming  voice  call > Mandatory > x - - > 5 > Reject  an  incoming  voice  call > Mandatory > x - - > 6 > Terminate  a  call > Mandatory > x - - > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x - - > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x - > - > HF - - > 9 > Place  a  call  using  memory  dialing > Option > - - - > 10 > Place  a  call  to  the  last  number  dialed > Option > - - ------------------------------------------------------------------------------------------------------------- - -![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -shall  be  used. -5.1.1.1.1  Hands  Free  Profile -The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile -specification  version  1.6  or  later. -The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, -wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and -output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to -the  actual  phone. -It  shall  provide  following  roles: -Hands-Free  unit  (HF) - - > 11 > Call  waiting  notification > Option > x - ------- ------------------------------------------------------ ---------- ---------- - > 12 > Three  way  calling > Option > x(\*1) - > 13 > Calling  Line  Identification  (CLI) > Option > x - > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x - > 15 > Voice  recognition  activation > Option > x - > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - - > 17 > Ability  to  transmit  DTMF  codes > Option > x - > 18 > Remote  audio  volume  control > Option > - - > 19 > Respond  and  Hold > Option > x - > 20 > Subscriber  Number  Information > Option > x - > 21a > Enhanced  Call  Status > Option > x - > 21b > Enhanced  Call  Controls > Option > - - > 22 > Individual  Indicator  Activation > Option > - - > 23 > Wide  Band  Speech > Option > x - > 24 > Codec  Negotiation > Option > x - -![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -\*1:  Does  not  support  Multi-party  (conference)  call -The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the -model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -string  in  a  phone  model  CGMM  variable. -· Phone  Model  CGMM: -· Type:  string -· Max  length:  200  chars -Page  81  of  159 -![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the -Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be -stored  as  a  string  in  a  phone  model  CGMI  variable. -· Phone  Model  CGMI: -· Type:  string -· Max  length:  200  chars -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the -revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -string  in  a  phone  model  CGMR  property. -· Phone  Model  CGMR: -· Type:  string -· Max  length:  200  chars -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) -The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP -specification  version  1.2  or  later. -Page  82  of  159 - - > **No.** > **Codec** > **Support** > **AGL** - ----------- ------------------- --------------- ----------- - > 1 > SBC > Mandatory > x - > 2 > MPEG-1,2  Audio > Option > - - > 3 > MPEG-2,4  AAC > Option > - - > 4 > ATRAC  family > Option > - - - > **No.** > **Feature** > **Support  in  SNK** > **AGL** - ----------- -------------------- ------------------------ ----------- - > 1 > Audio  Streaming > Mandatory > x - -![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to -realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. -It  shall  provide  following  roles: -Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from -the  SRC  on  the  same  piconet. -Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. -Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. -Copyright  protection  technology  SCMS-T  should  be  supported. -5.1.1.1.3  Phone  Book  Access  Profile -Page  83  of  159 -![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification -version  1.1  or  later. -The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between -devices. -Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The -Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected -device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing -and  copying  contact  information. -It  shall  provide  following  roles: -· Phonebook  Client  Equipment  (PCE) -It  shall  provide  following  types  of  Phonebook  objects: -· The  main  Phonebook  object -· The  Incoming  Call  History  object -· The  Outgoing  Call  History  object -· The  Missed  Call  History  object -· The  Combined  Call  History  object -A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device -automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook -download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: -· Using  PBAP  profile -All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. -SIM)  and  also  any  stored  in  the  BT  device's  memory. -The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the -vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded -from. -5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile -Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -Page  84  of  159 - - > **No.** > **Service** > **Support  in  DT** > **AGL** - ----------- ------------------------------------------- ----------------------- ----------- - > 1 > Data  call  without  audio  feedback > Mandatory > x - > 2 > Data  call  with  audio  feedback > Option > - - > 3 > Fax  services  without  audio  feedback > N/A > - - > 4 > Fax  services  with  audio  feedback > N/A > - - > 5 > Voice  call > N/A > - - > 6 > Incoming  calls > Option > x - > 7 > Outgoing  calls > Mandatory > x - -![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” -Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. -5.1.1.1.5  Object  Push  Profile  (OPP) -Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower -layers. -It  has  to  comply  with  the  specification  for  “Push  Server”. -Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. -**Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** -Page  85  of  159 - - > **No.** > **Feature** > **Support  in  CT** > **AGL** - ----------- -------------------------------------------- ----------------------- ----------- - > 1 > Connection  establishment  for  control > Mandatory > x - > 2 > Release  connection  for  control > Mandatory > x - > 3 > Connection  establishment  for  browsing > C6 > x - - ------------------------------------------------------------------------------------- - > **No** > **Feature** > **Support  in  Push  Server** > **AGL** - > - > **.** - ---------- ---------------------------- --------------------------------- ----------- - > 1 > Object  Push > Mandatory > x - - > 2 > Business  Card  Pull > Option > - - - > 3 > Business  Card  Exchange > Option > - - ------------------------------------------------------------------------------------- - -![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) -The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. -The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device -plus  one  remote  control.. -The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL -column  in  Table  25  should  be  supported. -C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional -otherwise -C3:  Mandatory  to  support  at  least  one  Category -C4:  Mandatory  if  Category  2  supported,  excluded  otherwise -C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise -EX:  Excluded -Page  86  of  159 -![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4 Release  connection  for  browsing C6 x -5 AV/C  Info  commands Option x -6 Category  1:  Player/Recorder C3 x -7 Category  2:  Monitor/Amplifier C3 - -8 Category  3:  Tuner C3 - -9 Category  4:  Menu C3 - -10 Capabilities Option x -11 Player  Application  Settings Option x -12 Metadata  Attributes  for  Current  Media  Item Option x -13 Notifications C2 x -14 Continuation C2 x -15 Basic  Group  Navigation Option x -16 Absolute  Volume C4 - -17 Media  Player  Selection Option x -17.1 -  Supports  Multiple  Players Option x -18 Browsing Option x -18.1 -  Database  Aware  Players Option x -19 Search Option - -20 Now  Playing C6 x -20.1 -  Playable  Folders Option x -21 Error  Response EX - -22 PASSTHROUGH  operation  supporting  press  and Option x -Page  87  of  159 - - ------------------------------------------------------------------------------ - > **No** > **Feature** > **Support  by  the  MCE** > **AGL** - > - > **.** - ---------- ------------------------- ----------------------------- ----------- - > 1 > Message  Notification > C1 > x - - > 2 > Message  Browsing > C1 > x - - > 3 > Message  Uploading > Option > x - - > 4 > Message  Delete > Option > - - - > 5 > Notification > C2 > x - > - > Registration - ------------------------------------------------------------------------------ - -![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -hold -The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and -pass  this  information  up  to  so  it  can  be  passed  to  the  User. -5.1.1.1.7  Message  Access  Profile -Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary -lower  layers. -It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. -Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. -C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features -C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message -Notification.  Not  applicable  otherwise. -Page  88  of  159 - - > **No.** > **Feature** > **Support  in  PANU** > **AGL** - ----------- ------------------------------------------ ------------------------- ----------- - > 1 > Initialization  of  NAP/GN  service > - > - - > 2 > Shutdown  of  NAP/GN  service > - > - - > 3 > Establish  NAP/GN  service  Connection > Mandatory > x - -![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.8  Serial  Port  Profile  (SPP) -The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version -1.1  or  later. -It  shall  provide  following  roles: -Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. -Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. -Following  features  shall  be  provided  by  the  Supplier: -Establish  link  and  setup  virtual  serial  connection -Accept  link  and  establish  virtual  serial  connection -Register  Service  record  for  application  in  local  SDP  database -5.1.1.1.9  Personal  Area  Network  (PAN)  Profile -Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. -Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. -Page  89  of  159 - - > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x - ----- ------------------------------------------- ------------- ----- - > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x - > 6 > Management  Information  Base  (MIB) > - > - - -![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.10  Service  Discovery  Profile  (SDP) -The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP -specification  version  1.1. -The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices -in  the  vicinity  of  a  Bluetooth  enabled  device. -It  shall  provide  following  roles: -Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. -Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to -the  service  inquiries  generated  by  Local  Device. -The  following  features  shall  be  provided  by  the  Supplier: -Search  for  services  by  service  class -Search  for  services  by  service  attributes -Service  browsing -5.1.1.1.11  Device  Information  Profile -Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. -**Table  28  :  List  of  DIP  Supporting  Functions** -Page  90  of  159 - - > **No.** > **Feature** > **Support** > **AGL** - ----------- ----------------------- --------------- ----------- - > 1 > SpecificationID > Mandatory > x - > 2 > VendorID > Mandatory > x - > 3 > ProductID > Mandatory > x - > 4 > Version > Mandatory > x - > 5 > PrimaryRecord > Mandatory > x - > 6 > VendorIDSource > Mandatory > x - > 7 > ClientExecutableURL > - > - - > 8 > ServiceDescription > - > - - > 9 > DocumentationURL > - > - - -![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.12  Bluetooth  Smart  Ready -Bluetooth  Smart  Ready  shall  be  supported. -It  shall  comply  with  Bluetooth  Low  Energy  standard. -5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) -The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX -specification  version  2.0  or  later. -The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between -devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. -It  shall  provide  following  roles: -Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data -objects  shall  be  pushed  and  pulled,  respectively. -Page  91  of  159 -![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. -The  following  features  shall  be  provided  by  the  Supplier: -Establishing  an  object  connection -Pushing  a  data  object -Pulling  a  data  object -Performing  an  action  on  data  objects -Creating  and  managing  a  Reliable  Object  Exchange  Connection -5.1.1.1.14  Generic  Audio/Video  Distribution  Profile -The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the -GAVDP  specification  version  1.2  or  later. -The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between -two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. -It  shall  provide  following  roles: -Initiator  (INT) -Acceptor  (ACP) -Following  are  the  feature  requirements  for  this  profile: -Connection -Transfer  Control -Signalling  Control -Security  Control -Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not -yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. -5.1.1.1.15  Bluetooth  Diagnostics -**5.1.2  Error  Management** -The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes -Page  92  of  159 -![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized -restart.  In  addition, -in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery -to  issue  in  a  short  amount  of  time. -**5.1.2.1  Use  Cases** -5.1.2.1.1  System  Surveillance  and  Recovery -While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an -immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating -the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to -try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating -middle  ware,  reboot  the  whole  system  to  try  and  recover. -There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that -adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The -AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. -The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even -if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be -done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error -Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the -degree  should  be  adjusted  by  its  behavior  status. -5.1.2.1.2  Collecting  Information -For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt -recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the -cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. -With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On -the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come -Page  93  of  159 -![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, -the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. -**5.1.2.2  Requirements** -Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its -status  automatically  and  recover -The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each -process. -The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. -When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold -value,  action  is  changeable  by  AGL  user. -Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification -to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are -output  communication  or  disk  I/O. -Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification -by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an -error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication -error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. -Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it -should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination -of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so -those  two  should  be  able  to  set  separately. -Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold -value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be -changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. -Should  be  able  to  vanish  process  forcibly  including  subsidiary  process -Page  94  of  159 -![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Make  the  software  that  works  by  system  have  the  concept  of  level  importance. -Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be -adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. -The  process  that  detecting  an  external  communication  error  within  the  Error  Management -module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. -The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as -more  than  one  process. -The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple -applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where -multiple  applications  can  be  moved  by  the  same  process. -Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing -process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as -process  crash,  exit,  etc.. -An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends -suddenly  the  other  will  not  become  abnormal  state. -The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other -process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards -external  side. -When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart -additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered -beforehand. -The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file -system  without  destroying  them. -Page  95  of  159 -![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for -analyzing. -When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a -message  that  can  specify  the  cause. -Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -in  a  short  period  of  time  have  been  equipped  and  able  to  select. -In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or -system  down  does  not  occur  (self-destruction  on  log  output  process). -Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. -Should  be  able  to  select  the  level  of  log  output. -Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. -Should  be  able  to  obtain  the  information  linked  to  the  system  resources. -Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. -Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -in  a  short  period  of  time  have  been  equipped  and  able  to  select. -As  the  smallest  amount  of  information,  the  following  information  should  be  left. -· Register  information -· Process  logical  memory  map -· -Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence -· Time  of  occurrence -· -Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing -file‑name  of  the  thread  etc.) -Page  96  of  159 -![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· The  signal  that  occurred -Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. -· -Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted -for  an  output. -· -Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent -dropping  the  information  needed. -· -Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] -· -Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed -maximum  size. -· -NOTE  information  of  ELF  header  and  program  header  will  not  change. -Selectable  memory  mappings  are  the  following. -· anonymous  private  mappings -· anonymous  shared  mappings -· file-backed  private  mappings -· file-backed  shared  mappings -· private  huge  page -· shared  huge  page -Setting  parameters  of  the  output  context  are  the  following. -· -Memory  mapping  category  which  is  for  an  output  object  can  be  set. -· The  order  of  outputting  memory  mapping  can  be  set. -Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in -increments  of  process. -Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be -able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. -Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. -Page  97  of  159 -![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. -**5.1.3  Graphics** -Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. -**5.1.4  Location  Services** -Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead -reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary -output  of  the  GPS  receiver. -**5.1.4.1  Position** -**5.1.4.2  Time  of  Day** -With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car -device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of -its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in -future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. -**Monotonic  and  Absolute  Time  Support** -As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. -Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s -moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and -Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. -On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time -that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, -some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports -Monotonic  Time. -**Kernel  Time  Precision** -Page  98  of  159 -![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those -communicating  system  includes  the  device  that  needs  ms  order  procedure. -In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on -the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest -value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. -**5.1.4.3  Requirements** -Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. -Adjust  the  system  time  after  the  time  is  determinate. -GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using -the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. -GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not -imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make -Source  plugin  can  not  be  GPL  or  LGPL. -When  waiting,  can  use  both  absolute  time  and  monotonic  time -Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -monotonic  time. -Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -monotonic  time. -System  time  must  be  able  to  use  consecutively  at  least  until  2099. -Absolute  time  has  to  support  leap  year  and  leap  seconds. -1  jiffies  have  to  be  smaller  than  1ms. -Page  99  of  159 -![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. -From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. -A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. -**5.1.5  Health  Monitoring** -Platform  monitoring  services  such  as  watchdog  or  active  monitoring -**5.1.6  IPC** -Standard  platform  interprocess  and  interprocessor  communication  mechanism. -**5.1.7  Lifecycle  Management** -Startup,  shutdown,  state  change,  etc. -**5.1.8  Network  Services** -Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer -including  Wifi,  Bluetooth,  or  ethernet. -**5.1.9  Persistent  Storage** -Power  safe  persistent  storage -**5.1.10  Power  Management** -Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs -in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. -*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* -Page  100  of  159 -![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -modern  ECUs -In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, -in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal -balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important -for  overall  durability  characteristic. -Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming -more  welcomed  over  traditional  cold  boot  approaches. -Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has -become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only -consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) -**5.1.10.1  Requirements** -AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend -states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” -/“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. -AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state -transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state -transitions  if  no  requests  provided  from  applications. -Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of -this  specification  (it  is  also  platform-dependent). -AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of -cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting -core  in  one  of  its  low  power  states) -AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular -cores  from  SMP  group. -Page  101  of  159 -![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points -(table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, -some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget -insignificant) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling -Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. -Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they -may  have  negative  impact  on  overall  system  performance/predictability -AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is -platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states -Only  application-defined  policies  shall  be  allowed  for  CPU  Idle -AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices -AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling -**5.1.11  Resource  Management** -Resource  and  device  management. -Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource -request  by  the  Resource  Manager. -**5.1.12  Telephony  Services** -**5.1.12.1  Requirements** -Page  102  of  159 -![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.12.1.1  Telephony  variants -Purpose:  To  define  the  variants  of  Telephony -Requirement: -There  will  be  2  variants  of  phone  system. -Variant  1:  Front  User  only  Telephony. -Variant  2:  Rear  and  Front  Telephony. -All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature -can  be  disabled  via  car  configuration. -**5.1.13  Wi-Fi** -This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information -management  between  a  wireless  LAN  device  and  infotainment  system. -Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. -**5.1.13.1  Use  Cases** -5.1.13.1.1  Construct  WiFi  Network -In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. -a\. STA -In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via -an  Access  Point. -It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. -b\. AP -In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices -with  an  external  network. -Page  103  of  159 -![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. -c\. P2P -In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- -Fi  Direct. -5.1.13.1.2  Miracast -In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) -They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, -by  using  UIBC  (User  Interface  Back  Channel).-(b) -**Figure  8-29  :  Overview  of  Miracast** -a\. Shared  Displayed  Content -Page  104  of  159 -![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Use  case  examples  of  shared  displayed  content  are: -· -A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device -(e.g.  Mobile)  on  In-Vehicle  Infotainment  system. -· -A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment -system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). -b\. Remote  Operation -Use  case  examples  of  remote  operation  are: -· -A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device -(e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. -· -A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle -Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). -· -While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation -functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. -Mobile). -5.1.13.1.3  DLNA -In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. -**5.1.13.2  Requirements** -5.1.13.2.1  Security -The  WiFi  module  shall  support  security  standard  WEP. -It  shall  support  40  bit  WEP  encryption  method. -It  shall  support  104  bit  WEP  encryption  method. -It  shall  support  security  standard  WPA  Personal. -Page  105  of  159 -![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA2  Personal. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA  Enterprise. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA2  Enterprise. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -5.1.13.2.2  Simple  Configuration -It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. -It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. -It  shall  support  Configuration  Method  for  Display. -Page  106  of  159 -![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  support  Configuration  Method  for  Keypad. -It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. -It  shall  support  Configuration  Method  for  PushButton. -It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. -5.1.13.2.3  QoS -It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. -It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. -5.1.13.2.4  STA -The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). -5.1.13.2.5  AP -The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). -5.1.13.2.6  WiFi  Direct -It  shall  comply  with  Wi-Fi  Direct  standard. -It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. -Page  107  of  159 - - -------------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **(Reference)** - > - > **Support  in  Wi-** - > - > **Fi  Direct** - ----------- ---------------------------------------------------- -------------------------- ------------------------ - > 1 > P2P  Provision > ‑ > Mandatory - > - > Discovery - - > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory - - > 3 > ‑ > Find  Phase > Mandatory - - > 4 > P2P  GO  Negotiation > ‑ > Mandatory - - > 5 > P2P  Service  Discovery > ‑ > Option - - > 6 > P2P  Invitation > Temporary  P2P  Group > Option - - > 7 > ‑ > Persistent  P2P  Group > Option - - > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option - - > 9 > Intra-BSS  Distribution > ‑ > Option - - > 10 > Concurrent  Operation > ‑ > Option - - > 11 > P2P  Service  Discovery > UPnP > Option - - > 12 > ‑ > Bonjour > Option - - > 13 > ‑ > Wi-Fi  Display > Option - - > 14 > ‑ > WS-Discovery > Option - - > 15 > ‑ > Vendor  specific > Option - -------------------------------------------------------------------------------------------------------------------- - -![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.13.2.7  Miracast -Page  108  of  159 - - -------------------------------------------------------------------------------------------------------------- - > ‑**No.** > **Feature** > ‑ > **(Refere** - > - > **nce)** - > - > **Suppor** - > - > **t        in** - > - > **Miracas** - > - > **t** - ------------ ----------------------------------------------------- ----------------------- ------------------- - > 1 > WFD  Device  type > WFD  Source > Mandat - > - > ory - - > 2 > ‑ > Primary  Sink > Mandat - > - > ory - - > 3 > ‑ > Dual-role  possible > Option - - > 4 > WFD  Service > ‑ > Option - > - > Discovery - - > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat - > - > ory - - > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option - - > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option - > - > Group - - > 8 > ‑ > via  TDLS > Option - - > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat - > - > ory - - > 10 > WFD  Session  Establishment  (RTSP) > Mandat - > - > ory - -------------------------------------------------------------------------------------------------------------- - -![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  comply  with  Miracast  standard. -It  shall  support  the  Miracast  functions  identified  in  Table  30. -Page  109  of  159 - - --------------------------------------------------------------------------------- - > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat - > - > ory - ------ --------------------------------------------------- ----------- ---------- - > 12 > WFD  Standby  (RTP/RTSP) > Option - - > 13 > Video  CODEC  formats > Option - - > 14 > Audio  CODEC  formats > Option - - > 15 > UIBC > Generic - - > 16 > HIDC - --------------------------------------------------------------------------------- - -![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.13.2.8  WiFi  Hotspot -It  shall  comply  with  Wi-Fi  Hotspot  standard. -In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot -service. -In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. -5.1.13.2.9  DLNA  via  WiFi -The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. -**5.1.14  Window  System** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -and  a  routing  of  user  interactions. -Page  110  of  159 -![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.2  Automotive  Services -Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but -contains  services  specialized  for  automotive  applications. -**5.2.1  Audio  Services** -BTBF,  equilization,  mult-zone  audio  control,  etc. -**5.2.2  Camera  Services** -Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. -**5.2.3  Configuration  Services** -Service  for  storing  configuration  parameters. -**5.2.4  Diagnostic  Services** -Diagnostic  services. -(This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) -**5.2.5  Multimedia  Services** -CD,  DVD,  Blu-Ray,  MP3,  etc. -(Factor  out  metadata  into  separate  component.) -**5.2.5.1  Media  Player** -In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just -Page  111  of  159 -![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video -devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, -there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- -seat  passengers  as  well  as  driver  all  having  independent  requirements. -The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: -· -Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the -ones  encountered  in  mobile  and  desktop  world. -· -Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) -and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or -establishes  a  network  connection.) -· -Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of -audio  /  video  processing  chains. -Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data -processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in -comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from -navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from -Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so -on. -It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore -processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing -offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with -particular  implementation  freedom  left  for  a  silicon  vendor. -The  following  requirements  formalize  these  considerations. -**5.2.5.2  Requirements** -5.2.5.2.1  Media  Containers -AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This -includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It -shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable -input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated -from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall -be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. -Page  112  of  159 -![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, -for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream -identification  data  from  media  container. -AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: -· HTTP -· RTPS -· Digital  Radio  (DAB) -· DigitalTV  (DVB-T)  etc. -It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with -system  requirements. -AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload -computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such -extension,  if  available,  shall  be  transparent  to  the  applications. -Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. -AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the -source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without -intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this -process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of -particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from -multiple  choices. -AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall -support  the  following  functionality: -· -Selection  of  data  source  and  destination  (files,  devices,  network  resources) -· Pausing/resuming  of  multimedia  streams -· Rewinding  in  forward  and  reverse  directions  (for  playback) -· Audio  volume  control  on  per-stream  basis -· Retrieval  of  current  stream  position  (timestamp) -Page  113  of  159 -![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -Notifications  on  error  conditions  preventing  multimedia  stream  processing -AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved -into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to -specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to -specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw -audio/video  streams  to  multiple  renderers  as  well. -AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and -synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: -· -Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. -· Per-stream  volume  and  audio  effects  control. -· -Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). -· -Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). -· Mixing  and  broadcasting  of  the  audio  streams. -AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to -specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or -removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, -emergency  system  alarm  output  and  so  on. -AGL  shall  provide  support  for  major  multimedia  containers,  such  as: -· MPEG2-TS/PS  (ISO/IEC  13818-1) -· MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) -It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with -system  requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: -· OGG  (RFC  3533) -· 3GPP  (ISO/IEC  14496-12) -· etc -Page  114  of  159 -![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.2.5.2.2  Media  Audio  Codecs -AGL  shall  provide  support  for  major  audio  codecs,  such  as: -· -MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) -· AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) -It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system -requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: -· VORBIS  (http://xiph.org/vorbis/) -· Windows  Media  Audio -· etc. -5.2.5.2.3  Media  Video  Codecs -AGL  shall  provide  support  for  major  video  codecs,  such  as: -· MPEG-2  (ISO/IEC  13818-2) -· MPEG-4  Part  2  (ISO/IEC  14496-2) -· H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) -It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system -requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: -· Theora  (www.theora.org) -· Windows  Media  Video -· etc -5.2.5.2.4  Image  File  Formats -Page  115  of  159 -![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true -colour. -Compression  formats -· RLE  8  bits/pixel -· RLE  4  bits/pixel -· Bit  field  or  Huffman  1D  compression -· JPEG  or  RLE-24 -· PNG -The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including -Exchangeable  Image  File  Format  (EXIF)  format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, -including  transparency -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced -version  89a  and  also  animation  in  GIFF  images. -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -format. -**5.2.6  Navigation  Services** -Navigation  engine -Page  116  of  159 -![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.7  PIM** -Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. -**5.2.8  Smartphone  Link** -This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which -realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation -is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and -AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use -smartphone  content  (map,  music,  browser...)  by  IVI. -Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. -**Figure:  8-30** -Page  117  of  159 -![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  defines  following  requirements  of  Smartphone  link. -1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. -2.  The  sound  of  smartphone  shall  be  linked  to  IVI. -3.  The  sound  shall  be  synchronized  with  the  screen. -4.  IVI  should  operate  smartphone. -5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. -6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should -inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. -This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone -link. -**5.2.8.1  Miracast** -This  section  describes  requirements  regarding  Smartphone  link  (Miracast). -Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- -Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing -between  source  device  and  sink  device. -Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. -**Figure:  8-31** -Page  118  of  159 - - ---------------------------------------------------------------------------------------------- - > **No** > **Requires** > **Description** - ------------ ----------------------------- --------------------------------------------------- - > SPL.1.1 > WFD  Topology > Define  role  of  Miracast - - > SPL.1.2 > Connection  Topology > Define  connection  condition  between - > - > a  smartphone  and  an  IVI - - > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi - > > - > 1 > Direct). - - > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency - > - > 2 - - > SPL.1.3 > Video  Format > Define  Video  format - - > SPL.1.4 > Audio  Format > Define  Audio  format - - > SPL.1.5 > Session  Control > Define  Miracast  session  state - - > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required - > - > for  implementing  Miracast - - > SPL.1.7 > Resource  Management > Define  resource  management - ---------------------------------------------------------------------------------------------- - -![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. -**References** -\[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 -\[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 -\[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision -2.2 -\[4\]  DCP  (Digital  Content  Protection)   -AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. -Page  119  of  159 -![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -SPL.1.8 Fail-safe  Control Define  Fail-safe  control -**Table  8-14:  Smartphone  Link  (Miracast)  Requirements** -**Figure:  8-32  State  Change  Diagram** -The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. -Page  120  of  159 - - ------------------------------------------------------------------------------------------------------- - > **No.** > **State** > **Description** - ----------- ------------------------- ----------------------------------------------------------------- - > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. - - > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and - > - > waiting  for  Wi-Fi  P2P  connection  from  source - > - > device. - - > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source - > - > device. - - > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. - - > 5 > Play > Streaming  the  audio  and  video  content  from  source - > - > device  to  sink  device. - - > 6 > Pause > Paused  the  streaming  of  audio  and  video  content - > - > from  source  divide  to  sink  device. - ------------------------------------------------------------------------------------------------------- - -![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.8.2  Smart  Device  Link** -“Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. -Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach -makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s -distraction  and  voice  recognition. -That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote -procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework -and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. -SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile -phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported -applications  can  be  launched. -Page  121  of  159 -![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  8-33  :  SDL  overview** -**5.2.8.3  Requirements** -5.2.8.3.1  Miracast -System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. -· -Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which -from  Source  Device‑Smartphone‑. -· Supporting  WFD  Source  is  an  option. -· -Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) -source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). -· -Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take -measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over -5Km/H) -· Support  Wi-Fi  P2P  connection. -· -Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in -Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. -· Wi-Fi  TDLS  connection  is  an  option. -· -AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select -Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) -· -AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive -Page  122  of  159 -![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for -confirmation) -· -Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. -· -Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P -connection  established. -· -Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. -· -Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) -function  if  support  5GHz  band. -· Follow  reference  \[1\]  for  Video  Codec. -· Support  follow  format  for  Video  Resolution  and  Frame  rate. -o 640\*480‑VGA‑‑Progressive  60  fps -o 1280\*720‑HD‑Progressive  30  fps -Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. -· Support  follow  format  for  Audio. -o LPCM  48ksps  16bit  2ch -o AAC  48ksps  16bit  2ch -Regarding  Audio  Format,  other  formats  are  an  option. -When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up -notification) -Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support -content  protection  function. -· -AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not -define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for -Page  123  of  159 -![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -vendor’s  own  reason. -· Support  both  encryption  cases  if  support  HDCP  function. -o Case1  Videos  data  encryption -o Case2  Both  video  and  audio  encryption -Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to -DCP.(reference  \[4\]) -· -Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, -then  Miracast  release  screen  and  audio  resources  for  the  event. -· -It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast -session.) -· -Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events -happen. -o Failed  to  Wi-Fi  connection -o Failed  to  establish  Miracast  session -o Wi-Fi  link  loss  on  Miracast -o Break  Miracast  connection  from  smartphone -5.2.8.3.2  Smart  Device  Link -System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. -System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. -System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel -device  of  IVI  device. -System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice -Page  124  of  159 -![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -recognition  of  IVI  system. -System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity -method  must  be  supported  Bluetooth  and/or  Wi-Fi. -System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity -method  must  be  supported  Bluetooth  and/or  Wi-Fi. -**5.2.9  Speech  Services** -The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. -AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands -AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech -**5.2.10  Tuner  Services** -The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into -the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, -TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present -in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. -**5.2.10.1  Receivers** -The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including -AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any -number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from -the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current -content. -The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into -the  same  API  regardless  of  the  receiver  type. -Page  125  of  159 -![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow -its  clients  to  address  each  receiver  in  the  system  independently. -5.2.10.1.1  HD  Radio -HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An -HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to -provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the -receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The -HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the -iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional -design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by -iBiquity  Digital. -The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the -requirements  in  this  section. -1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. -2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. -3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. -Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is -applicable  to. -AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status -to  the  system. -AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the -tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning -successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio -output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No -Reception"  is  available  in  that  specific  channel. -AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -Page  126  of  159 -![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Frequency -· Mono/Stereo -FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -· Frequency -· PI  Code  (RDS  only) -· PTY  (RDS  only) -· Radio  Text  (RDS  only) -· PS  Name  (RDS  only) -· Category  (RDS  only) -· Mono/Stereo -HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -· Frequency -· PTY -· No  of  HD  channels  available -· Radio  Text -· Channel  Name -· Category -· Bit  rate -· Station  Logo -· Artist  Experience -The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. -The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal -strength. -AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. -Page  127  of  159 -![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be -possible  to  adjust  by  software. -· Range:  15  –  40  dBµV -· Step:  1  dBµV -· Default:  20  dBµV -· -Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity -level.  TBD,  Supplier  to  suggest  solution. -AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be -possible  to  adjust  by  software. -· Range:  20  –  40  dBµV -· Step:  1  dBµV -· Default:  34  dBµV -· -It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. -different  for  night  and  day). -The  system  shall  be  able  to  switch  between  AM  and  FM  bands. -HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the -SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance -with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -Information  Service  Transport". -HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the -SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance -with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -Information  Service  Transport". -HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. -Page  128  of  159 -![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. -· Song -· Artist -· Album -· Genre -· Comments -· Commercial -· Reference  Identifier -The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification -"HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" -FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the -system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, -Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency -range  from  87,5  MHz  to  108,0  MHz". -FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled -the  system  shall  indicate  this. -FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. -FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. -FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. -FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. -FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. -FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received -through  RDS. -Page  129  of  159 -![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. -FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. -FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. -FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. -FM/HD  system  shall  be  able  to  enable/disable  regionalisation. -FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. -FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) -reception. -FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. -FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. -FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. -HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. -HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. -AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. -AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. -*HD system shall extract the album name, artist name, track number from the audio stream a*nd -Page  130  of  159 -![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -present  to  the  system. -The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The -feature  will  be  able  to  store  at  least  50  tags. -*5.2.10.1.1.1  Configuration* -AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration -file. -AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. -AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local -configuration  file. -5.2.10.1.2  Database  Requirements -AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains -the  following  attributes: -· Frequency -· PTY  (FM  &  HD  only) -· Channel  name  (FM  &  HD  only) -· Channel  icon  (HD  Only) -· Category  (FM  &  HD  only) -AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following -conditions: -· New  channel  is  found -· Existing  channel  disappears -· -Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list -database. -Page  131  of  159 -![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present -to  the  system. -AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the -frequency,  and  present  to  the  system. -FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, -and  present  to  the  system. -AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following -information: -· Station  name  (FM  and  HD  only) -· Frequency -· Status  of  HD  (HD,  HD1,  HD2) -· HD  SIS  (HD  only) -AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: -· Favourite  station  changed -· Favourite  station  is  removed -· New  favourite  is  added -**5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** -Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from -applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and -LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of -VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main -functions. -· Vehicle  Data  Processing -· Communication  between  ECUs -· Vehicle  Data  Upload -Page  132  of  159 -![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Simulator -**Figure  7-27  :  Overview  of  Vehicle  Info  Control** -**5.2.11.1  Vehicle  Data  Processing** -Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, -personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application -and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. -· -Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature -· User  Information,  such  as  a  name,  taste,  etc.  of  a  driver -· The  operation  history  of  a  driver -Page  133  of  159 -![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle -conditions,  such  as  speed  and  day  and  night -Vehicles  data  processing  consists  of  the  following  functional  elements  further. -(1)  Abstraction  of  Vehicles  Data -In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind -of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving -speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for -application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles -data  of  the  same  implications  and  the  same  unit. -(2)  Maintenance  of  Vehicles  Data -Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past -value  (history). -(3)  Application  /  Middleware  Interface  (API) -The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. -Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and -the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data -restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance -(access  control). -(4)  Vehicles  Interface -It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN -and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the -exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. -However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more -Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In -addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. -**5.2.11.2  Communications  between  ECUs** -Page  134  of  159 -![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -which  each  ECU  can  access. -**5.2.11.3  Vehicle  Data  Upload** -When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -which  each  ECU  can  access. -**5.2.11.4  Simulator** -In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is -unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes -development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel -controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be -an  option. -**5.2.11.5  Requirements** -The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application -and/or  middleware  can  access  vehicle  information. -The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract -property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but -the  speed  of  a  car. -System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. -Page  135  of  159 -![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  support  typical  vehicle  property  as  “standard  property”. -As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. -System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. -A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard -property. -Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) -The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or -middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough -as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile -display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. -A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is -stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the -load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and -spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. -It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In -corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. -· -The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the -accumulated  newest  value  is  less  than  a  threshold  value. -· -Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the -newest  accumulation. -About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need -to  be  able  to  set  up  easily. -In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. -System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property -access. -System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or -middleware. -Page  136  of  159 -![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Below  attributes  must  include  in  this  interface -· Zone(optional) -· Property  name -· Value -· -Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application -and/or  middleware. -Below  attributes  must  include  in  this  interface. -· Zone(optional) -· Property  name -· Value -System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from -application  and/or  middleware. -When  status  changed,  system  must  invoke  callback  function  with  below  attributes. -· Zone(optional) -· Property  name -· Value -· Timestamp -· Sequence  number -Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -Sequence  number  is  useful  to  check  event  order. -The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of -change  of  vehicle  information. -In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an -acceptable  value  even  if  vehicle  information  changes. -For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the -application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of -change. -Page  137  of  159 -![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. -· -The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the -value  from  the  last  notice  of  change  is  less  than  specification. -· -Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a -definite  period  of  time,  it  does  not  notify. -Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the -time  of  change. -What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified -notice  interval  is  made  possible. -The  data  stored  is  acquired  collectively. -Below  attributes  must  include  in  this  interface. -· Zone(optional) -· Property  name -· Values -· Timestamps -It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 -seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. -There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual -in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed -simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the -newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to -recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information -relevant  to  mutual  and  to  access  it. -Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle -information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, -and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all -those  vehicle  information  at  the  time  of  reference. -The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. -Or  the  thing  which  can  be  changed  from  a  program  during  operation. -Page  138  of  159 -![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property -"velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be -accessed  from  all  applications. -System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same -property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only -application  C  can  set  this  property. -Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control -policy  may  be  different  per  car  type,  grade  and  destination. -System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU -and  across  two  or  more  ECU’s. -If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, -middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, -the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware -which  exist  in  a  different  ECU. -VIC  can  be  requested  to  set  the  value  specified  as  Property. -It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. -The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand -from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. -Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application -responds. -It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed -easily. -The  data  exchange  between  ECUs  should  be  permitted  by  VIC. -All  data  transmission  and  reception  from  other  Software  Component  are  refusing. -Page  139  of  159 -![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. -The  vehicle  information  to  upload  is  being  able  to  choose. -A  selection  condition  is  that  the  following  specification  is  possible  at  least. -· Date-and-time  range -· Object  vehicles  data -· The  change  threshold  value  of  vehicles  data -Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be -able  to  change  dynamically  from  an  external. -The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as -substitution  of  actual  vehicles  in  development  environment  is  prepared. -Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing -activities  through  a  vehicles  interface  function  at  least. -· Speed -· Shift  position -· The  direction  of  vehicles -· Latitude  and  longitude  of  a  current  position -· Turn  signal -The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, -it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. -VIC  should  fill  the  following  performance  specifications  and  performance. -It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -information  machines  and  equipment  in  2016. -Page  140  of  159 -![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Maximum  number  of  properties  :  4,096 -· Maximum  number  of  property  sets:  1,024 -· Greatest  data  storage  time :  12  hours -It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -information  machines  and  equipment  in  2016. -· Get/Set  method(one  property)  -  0.2ms -· Get/Set  method(property  set  include  30  properties)  -1.3ms -· Subscribe  callback  -  2.5ms  (after  change  of  a  value) -· -GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms -· -GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms -VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility -about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and -attribute  of  vehicles  data. -Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by -various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add -and  change  Vehicle  Interface  without  reconstruction  of  VIC. -Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is -necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. -However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness -vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more -concreteness  vehicles  data  into  one  abstract  vehicles  data. -Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be -mounted  in  the  VIC  itself. -In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be -added  without  reconstruction  of  VIC  is  prepared  for  VIC. -**5.2.12  Telematics  Services** -V2V,  V2I,  RVI,  Traffic  information,  etc. -Page  141  of  159 -![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.13  Window  System** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -and  a  routing  of  user  interactions. -AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple -processes  to  be  rendered  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to -achieve  flicker  less  rendering. -AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- -screen  buffers. -AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying -objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. -AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos -group  available  to  clients  for  their  rendering. -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by -configuration. -AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the -*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a -Page  142  of  159 -![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The -window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES -2.0  API  are  responsible  for  a  hardware  abstraction. -AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. -AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple -displays. -AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, -where  available. -AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware -acceleration  capabilities. -AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs -from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a -vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the -vehicle  reaches  to  the  certain  speed. -AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, -a  touch  panel,  a  control  knob  etc. -AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input -from  available  physical  input  devices. -**6   Security   Services** -Security  framework -6.1  Access  Control -Access  Control  describes  requirements  for  AGL  Access  Control. -Page  143  of  159 -![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. -**6.1.1  Requirements** -AGL  system  must  support  a  system-wide  access  control  mechanism. -**7   Operating   System   Layer** -7.1  Kernel -**7.1.1  Linux  Kernel** -Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new -release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years -for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and -kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the -rest  of  the  open  source  community  provides, -**7.1.1.1  Requirements** -AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. -At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive -industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully -aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by -Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to -accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to -regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with -the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. -AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on -particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. -Page  144  of  159 -![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -7.2  Boot  Loader -7.3  Hypervisor -TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level -virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI -systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android -and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on -top  type1  hypervisor. -**7.3.1  Requirements** -AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that -have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The -processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. -AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following -functionality  shall  be  supported  by  AGL  Linux  “guest”: -· IPC  (with  hypervisor  and  other  “guests”) -· -“paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless -virtualization  abstraction  is  supported  by  hardware) -7.4  Operating  System -**7.4.1  File  Systems** -File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability -as  their  main  characteristics. -· -*Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, -tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process -environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management -techniques. -Page  145  of  159 - - ------------------------------------------------------------------------------- - > **FS  Requirements** > **R-FS  References** - ------------------------------------------------------ ------------------------ - > 6.  File  Systems  (P1) > 2.  btrfs - > > - > 6.1.  Robust  File  System  for  managed  internal > 2.1. - > > - > storage  (P1) > btr - > > - > 6.1.1.  Power  failure  tolerance  (P1) > fsc - > > - > 6.1.2.  Quick  recovery  after  power  loss > k - > > - > (P1) > 3.  ext2 - > > - > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. - > > - > 6.1.4.  On-demand  integrity  checker  (P1) > e2 - > > - > 6.1.5.  Read-only  mode  (P1) > def - > > - > 6.1.6.  Non-blocking  unmounting  (P1) > rag - > > - > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 - > > - > performance  if  it  may  degrade  under > 5.  ext4 - > > - > certain  conditions.  (P2) > 5.1. - > > - > 6.1.8.  File  space  pre-allocation  (P2) > e4 - > > - > 6.1.9.  Meta-data  error  detection  (P2) > def - > > - > 6.1.10.  File  data  error  detection  (P2) > rag - > > - > 6.1.11.  Online  integrity  checking  (P2) > 5.2. - > > - > 6.1.12.  Write  timeout  control  (P2) > e2f - > > - > 6.1.13.  Compression  support  (P2) > sck - > > - > 6.1.14.  Quota  support  (P2) > 6.  vfat - > > - > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS - > > - > 6.1.16.  File  system  event  notifications > 8.  Generic - > - > tools  and - > - > APIs - > - > 8.1. - > - > fan - ------------------------------------------------------------------------------- - -![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -*Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing -designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. -· -*Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual -packages,  and  availability  of  file  system  checking  and  optimization  tools. -![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 -(P2) -6.1.17.  Logical  block  size  control  (P2) -6.1.18.  Snapshots  (P2) -6.2.  File  System  for  non-managed  internal -storage  (P1) - -May  28,  2015 - -otif - -y - -8.2. - -fst - -rim - -6.2.1.  All  P1  requirements  from -FS.1.1.x  list  (P1) -6.2.2.  Wear  leveling  (P1) -6.2.3.  Error  detection/correction  (P1) -6.2.4.  Tolerance  to  flipping  bits  (P1) -6.2.5.  Read/write  disturb  awareness -(P1) -6.2.6.  Bad  block  management  (P1) -6.2.7.  As  many  P2  requirements  from -FS.1.1.x  list  as  possible  (P2) -6.2.8.  Wear  leveling  statistics  (P2) -6.3.  File  Systems  for  removable  storage  (P1) -6.3.1.  Restricted  functionality  from -security  point  of  view  (P1) -6.3.2.  Automount/autounmount  (P1) -6.3.3.  Automatic  synchronous  flushing -of  modified  data  to  physical  media  (P2) -**7.4.1.1  Requirements** -AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -memory),  removable  managed  (USB  stick,  SD  card). -AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, -Page  147  of  159 -![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, -AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. -A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, -and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. -A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power -interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should -not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. -Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- -write)  operation. -A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple -threads  and/or  processes  simultaneously. -A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. -A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical -storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” -command. -AGL  must  support  “lazy”  (delayed)  unmounting. -AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged -file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. -Another  example  is  periodic  fstrim  execution  on  SSD  storage. -A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This -may  be  used  to  minimize  fragmentation  of  frequently  written  files. -A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. -Page  148  of  159 -![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored -data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. -A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. -A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical -media. -A  file  system  should  support  automatic  data  compression. -It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. -AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. -AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. -Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O -performance,  and  decrease  file  fragmentation  impact. -A  file  system  should  allow  creation  of  snapshots. -A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of -erase/program  cycles  is  evenly  distributed  across  all  device  blocks. -A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. -A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also -actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power -interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the -time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. -A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb -Page  149  of  159 -![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known -techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a -fresh  block  after  detected  error  correction. -A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system -users. -Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. -A  file  system  must  support  noexec,  and  nodev  mount  options. -A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and -automatically  unmount  it  when  unplugged. -A  file  system  must  support  sync  mount  option. -AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -memory),  removable  managed  (USB  stick,  SD  card). -**7.4.2  Resource  Control** -In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be -higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource -allocation  for  each  process  and/or  process  group. -(cgroups) -**7.4.2.1  Use  Case  and  Role** -If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current -position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. -On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned -Page  150  of  159 - - ------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- -------------- ---------------------------------------------------------------- - > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority - > - > process  and/or  process  group  should  be  assigned - > - > more  resource. - - > 2 > Time  slot > To  share  resource  per  time  slot. - - > 3 > Release > Forced  release  of  partially  or  whole  allocated - > - > resource. - - > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate - > - > resource  per  defined  process  group. - ------------------------------------------------------------------------------------------- - -![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  higher  priority  than  others. -Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at -the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. -Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. -AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network -bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. -**Table  9-34  :  Functions  of  System  Resource  Management** -**7.4.2.2  Requirements** -7.4.2.2.1  Priority -System  provides  a  mechanism  to  set  resource  priority  per  each  process. -Page  151  of  159 -![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. -This  interface  must  be  called  from  other  process. -CPU  resource  must  support  “priority”  based  resource  management. -Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the -status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. -Resource  Manager  should  log  the  status  of  resources  using  by  system. -Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of -kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high -priority  tasks. -7.4.2.2.2  Time  Slot -When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a -mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each -processes. -System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. -System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage -bandwidth  and  network  bandwidth. -Scheduler  should  detect  the  status  of  resources  for  each  thread. -Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. -Scheduler  should  guarantee  that  threads  can  run  periodically. -Scheduler  should  control  the  dispatches  that  occur  extremely. -Page  152  of  159 -![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -7.4.2.2.3  Release -System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by -specific  process. -System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. -7.4.2.2.4  Grouping -System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource -management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same -attributes  to  grouped  processes  altogether. -System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. -System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and -network  bandwidth. -**7.4.3  Startup/Shutdown  Control** -Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a -user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending -on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which -boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and -“dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. -**7.4.3.1  Use  Cases** -(1)  Static  Modification  of  Boot/Shutdown  Order -a. -Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration -To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown -for  all  programs  running  on  the  target  device. -Page  153  of  159 -![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b. -Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development -In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed -program  in  target  programs. -c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update -Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. -(2)  Dynamic  Modification  of  Boot/Shutdown  Order -a. -Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using -It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to -be  operated  by  priority  when  ACC  turns  ON. -b\. Prioritized  Boot  of  Update  Functionalities -Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned -ON. -**7.4.3.2  Requirements** -Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. -Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that -has  been  configured. -Boot/Shutdown  Control  shall  start  independent  components  in  parallel. -Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. -Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that -has  been  configured. -Page  154  of  159 -![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. -**7.4.4  Database** -Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee -database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system -database  engine  is  rich  set  of  bindings  to  various  programming  languages. -Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References -hierarchy. -1.  Power  failure  tolerance  (P1) -2.  Quick  recovery  after  power  loss  (P1) -3.  Multi-threaded  I/O  (P1) -4.  API  bindings  for  C  programming  language -5.  On-demand  integrity  checker  (P2) -DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write -DB  transactions. -DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. -Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power -failure  on  idle  system. -DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or -processes  simultaneously. -DB  engine  API  must  be  available  for  C-based  applications. -DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. -DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power -interruption  during  adding  some  data. -Page  155  of  159 -![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, -such  as  vehicle  information  database  and  databases  at  data  center. -And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. -Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption -during  merging. -**7.4.5  System  Update** -Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are -numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, -bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to -power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. -System  Update  module  should  have  a  Robust  version  up  function. -System  Update  moduleshould  have  a  system  difference  version  up  function. -There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -apt  of  Linux  distribution). -There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -apt  of  Linux  distribution). -Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. -If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should -be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. -If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during -update)  should  be  detected  and  the  system  should  restart. -Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. -Page  156  of  159 -![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Memory  usage  for  difference  update  should  be  maximum  1Mbyte. -Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. -System  Update  moduleshould  have  full  version  up  function  for  whole  system. -Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow -mass  update. -There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. -If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -7.5  Device  Drivers -Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. -**7.5.1  Peripherals** -Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. -The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and -data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For -optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less -than  50  s/byte  average. -The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles -and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or -EEPROM  is  not  allowed. -Page  157  of  159 -![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be -fast.  (target  <1ms/byte) -N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. -**7.5.2  Graphics  Drivers** -Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. -This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. -**7.5.3  Video  Drivers** -Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video -codecs  will  nearly  always  be  hardware  based. -**7.5.3.1  Requirements** -The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video -functionality. -**7.5.4  Audio  Codecs** -**7.5.4.1  Requirements** -Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are -implemented  in  hardware. -Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs -that  are  required  for  AGL-based  products  and  not  supported  in  hardware. -**7.5.5  Automotive  Devices** -Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or -*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* -Page  158  of  159 -![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for -navigation  or  an  air  bag  sensor  for  a  telematics  system. -**8   Notices** -Linux  is  a  registered  trademark  of  Linus  Torvalds. -The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. -Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. -Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. -MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. -AirPlay  is  a  trademark  of  Apple,  Inc. -Page  159  of  159 ---- - -title : App/HMI   Layer -author: imported from Doors-ng by Fulup(iot.bzh) -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - - - -** 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 - -## 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. - -## 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. - -## 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. - -## 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 - -##  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 - - -## 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 -##  Requirements - -### 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. - -###  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. - -###  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 -### 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. - -##   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 - -### Application  Manager -Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application -lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. - -###  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. - -###  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 -####  Use Case -Please  refer  “screen  resource  control”  of  Policy  Manger  section. - -####  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 -#### Requirements -4.1.2.3.1  Window  Drawing -System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and -make  invisible. -System  must  provide  a  mechanism  to  create  and  delete  surface. -When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. -This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. -System  must  provide  a  mechanism  to  change  visibility  per  each  surface. -And,  provide  an  interface  to  change  visibility. -All  the  surfaces  must  be  set  to  invisible  for  initial  state. -Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. -System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between -previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. -*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt -Page  23  of  159 -![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -from  size  of  surface. -If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  squeeze. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  using  combination  of  scaling  and  trimming  function. -That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. -If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface -into  area  by  using  combination  of  scaling  and  background  color. -That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect -ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This -mechanism  makes  it  possible  to  do  “letterbox”  method. -4.1.2.3.2  Overlay  of  Multiple  Windows -System  must  provide  a  mechanism  to  create  and  delete  a  layer. -Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by -their  z-order  attribute. -Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, -then,  attached  layer  must  be  changed. -System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. -Area  is  a  concept  which  defines  where  to  display  in  specific  layer. -System  must  provide  a  mechanism  to  attach  surface  to  any  layer. -Also,  system  must  be  able  to  change  attached  layer. -And,  provide  an  interface  to  attach  and  change. -Page  24  of  159 -![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. -And,  provide  an  interface  to  assign  surface  to  any  area. -System  must  provide  a  mechanism  to  change  visibility  per  each  layer. -That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the -same  time. -And,  provide  an  interface  to  change  visibility  per  layer. -Initial  state  must  be  set  to  invisible. -System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each -layer,  and  disposition  of  surfaces. -4.1.2.3.3  Visual  Affect -System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was -happened. -Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -- Duration -Animation  type -System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -out. -Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -plug-in  architecture. -System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. -Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. -· Duration -Animation  type -System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- -Page  25  of  159 -![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -out. -Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by -plug-in  architecture. -System  must  provide  a  mechanism  to  make  effect  to  surface. -And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. -System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. -System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness -System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in -architecture. -4.1.2.3.4  Frame  Rate  Control -System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of -application. -System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval -of  application. -This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live -thumbnail  and  moving  surface. -4.1.2.3.5  Multiple  Hardware  Layer  Support -If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use -hardware  layers  efficiently. -· -Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers -Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback -4.1.2.3.6  Reduced  Dependency  of  Hardware -Page  26  of  159 -![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of -each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, -such  as  by  using  re-configuration. -4.1.2.3.7  Multi  Window -AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple -processes  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. -4.1.2.3.8  Compatibility -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a -standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any -hardware  specific  API. -A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. -**4.1.3  Policy  Manager** -**4.1.3.1  Overview** -4.1.3.1.1  Purpose -Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy -Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle -Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of -resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called -Page  27  of  159 -![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -“System  resources”  such  as  CPU  and  memory. -4.1.3.1.2  GUI  Resources -(1)  Definition -·  About  Control  of  GUI  Resources -AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, -speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user -or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. -**Figure  7-1:  GUI  resources** -Page  28  of  159 -![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy -Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too -much  information  distracts  the  attention  of  driver  from  driving  operations. -·  Associated  Software  Architecture -The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources -control  is  as  below. -**Figure  7-2:  Associated  Software  Expected  Use  Case** -Page  29  of  159 - - ----------------------------------------------------------------------------------------------------------------------------------------------------- - > **No** > **Component** > **Description** - > - > **.** - ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- - > 1 > Homescreen > Request  to  control  of  GUI  resources. - - > 2 > Applications > Request  to  output  or  input  of  GUI  resources. - - > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And - > - > then  provide  the  corresponding  feature  to - > - > applications  UI  such  as  input  limitation  and - > - > changing  the  theme. - - > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the - > - > definition  of  GUI  resources  such  as  role  by - > - > application  configurations. - - > 5- > Vehicle > Window  Manager - > > - > 1 > Info - > - > Control - - > 5- > Sound  Manager - > - > 2 - - > 5- > Input  Manager - > - > 3 - - > 5- > Vehicle  Info  Distributor - > - > 4 - - > 5- > User  Manager - > - > 5 - ----------------------------------------------------------------------------------------------------------------------------------------------------- - -![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  is  related  with  the  below  components. -(2)  Role -Page  30  of  159 - - ----------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ------------------------------ ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of - > > - > GUI  resource > GUI  resources. - > - > (2)  Judgment  the  GUI  resource  owner  according  to - > - > external  conditions. - - > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to - > - > judgment. - > - > (2)  Notify  the  driving  mode  and  day  night  mode - > - > that  is  calculated  by  external  conditions. - ----------------------------------------------------------------------------------------------------- - -![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  has  the  below  role. -Page  31  of  159 -![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  7-3:  Definition  of  Role** -GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each -resource  type  are  as  follows: -a.  Screen  Resource -a-1.  External  Condition  Collection -Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. -**Figure  7-4:  Definition  of  screen  resource** -•  Concept  of  Display,  Layer,  Layout  and  Area -AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one -or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout -Page  32  of  159 -![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics -window. -The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on -objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was -used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than -layer-2. -Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, -application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. -“Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and -setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert -and  enlarged  view. -When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On -the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” -layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. -From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- -order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered -by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to -individual  layer. -•  Concept  of  Layer  Owner,  Role  and  Surface -“Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of -that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of -area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy -Manager. -“Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” -change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. -One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics -window  to  display  into  one  area. -Page  33  of  159 -![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface -drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example -to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then -corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface -is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & -scan”. -**Figure  7-5:  Definition  of  Surface** -•  Subdivision  of  “Interrupt”  Layer -Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main -surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main -surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding -“Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message -is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. -According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described -as  Table  7-3. -Page  34  of  159 - - --------------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- -------------------------------------------------------- ----------------------- - > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation - > - > application  requests  this  layer  at  first  time. - - > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of - > - > navigation - - > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message - > > - > screen  service  (e.g.  Homescreen)  requests > popup - > - > this  layer. - - > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard - > > - > keyboard > Typically,  software  keyboard  service - > - > requests  this  layer. - --------------------------------------------------------------------------------------------------------- - - ------------------------------------------------------------------------------------------------------ - > **No** > **Contents** > **Summary** > **Example** - ---------- ---------------- ------------------------------------------------------- ------------------ - > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation - > - > service)  role. - - > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view - ------------------------------------------------------------------------------------------------------ - -![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -a-2.  Judgment  of  Priority  of  GUI  Resource -Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role -is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy -Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. -Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software -Page  35  of  159 -![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is -popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). -**Figure  7-6:  Definition  of  Role  and  Sub  role** -The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display -has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. -In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" -layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub -role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” -role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. -a-3.  GUI  resource  control -Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -directly. -Page  36  of  159 -![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -There  are  three  types  of  screen  resource  control: -One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. -Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was -assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. -Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue -z-order  information  for  each  layer. -b.  Sound  Resource -b-1.  External  Condition  Collection -Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. -**Figure  7-7:  Definition  of  Sound  Resource** -•  Zone -Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can -play  at  the  same  time. -Page  37  of  159 - - ------------------------------------------------------------------------------------------------- - > **No** > **Type** > **Summary** > **Example** - ---------- ------------- ---------------------------------------------- ------------------------- - > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media - > - > player - - > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of - > - > Navigation - - > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound - > - > requests  this  type. - ------------------------------------------------------------------------------------------------- - -![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -•  Sound  type -Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource -owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper -sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific -zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each -sound  stream  must  assign  to  individual  sound  type. -AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. -•  Stream -Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in -stream. -b-2.  Judgment  of  Priority  of  GUI  resource -Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role -is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy -Manager.  Figure  7-8  describes  the  definition  of  role. -Page  38  of  159 -![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  7-8:  Sample  Role** -The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that -is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or -different  sound  type  are  not  switched.  They  are  mixed. -b-3.  GUI  Resource  Control -Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control -directly. -There  are  two  types  of  sound  resource  control: -One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for -sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound -Page  39  of  159 -![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -stream  and  to  start  play  latest  area  owner. -Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback -simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy -Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and -music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music -playback. -c.  Input  Resource -c-1.  External  Condition  Collection -Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. -**Figure  7-9:  Definition  of  Input  Resource** -•  Device  Name -Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. -•  Event  Type -Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and -temperatures. -c-2.  Judgment  of  Priority  of  GUI  resource -Page  40  of  159 -![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device -name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy -DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the -judgment  as  below. -**Figure  7-10:  Definition  of  routing  rule** -OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. -c-3.  GUI  Resource  Control -Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only -issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. -Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. -4.1.3.1.3  System  Resources -(1)  Definition -Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy -Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. -Page  41  of  159 - - ---------------------------------------------------------------------------------------------------- - > **ID** > **Role** > **Description** - ---------- ----------------------------- ----------------------------------------------------------- - > 1 > External  condition > (1)  Receives  the  external  conditions. - > - > collection - - > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according - > - > to  external  condition  change. - > - > 2.  Kill  process(s)  forcibly  according  to  external - > - > condition  change. - ---------------------------------------------------------------------------------------------------- - -![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, -target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. -**4.1.3.2  Requirements** -4.1.3.2.1  Screen  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system -uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive -information  must  include  as  follows. -a.  ID -b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) -c.  DPI -d.  Connected  ECU -Page  42  of  159 -![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be -able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list -according  to  current  layout  of  each  display. -The  receive  definition  must  include  the  follows. -a.  ID -b.  Area  list -System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface -by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the -device. -The  receive  request  must  include  the  follows. -a.  Layout  ID -b.  ID -c.  Area  position  (Coordinate  of  the  upper-left) -d.  Area  size  (Length  \*  Width) -System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify -the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. -a.  Display  ID -b.  Layout  ID -System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the -providing  resource  using  it  when  the  request  is  collision. -The  receive  information  must  include  the  follows. -a.  Role -b.  Priority -System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge -driving  mode. -The  receive  information  must  include  the  follows. -a.  Velocity -Page  43  of  159 -![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Brake  status -System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge -day  night  mode. -The  receive  information  should  include  the  follows. -a.  The  brightness  of  the  interior -System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the -providing  resource  using  it. -System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should -judge  the  providing  resource  using  it. -(2)  Judgment  of  Priority  of  GUI  Resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical -resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the -resource. -The  receive  request  must  include  as  follows. -a.  Role -b.  Layer  type -The  receive  request  should  include  as  follows. -c.  Display  ID -System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by -priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on -the  specified  area  on  the  specified  layer. -The  receive  request  must  include  as  follows. -a.  Role -Page  44  of  159 -![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Layer  ID -The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. -Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the -related  basic  type  area. -c.  Area  ID -**Figure  7-11:  Sequence  to  display** -System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. -In  this  request,  requester  should  choose  below  options. -a. -Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, -but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should -be  refused. -b. -Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen -resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher -priority,  then,  only  screen  resource  should  be  assigned  to  requester. -Page  45  of  159 -![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system -running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. -The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal -request. -a.  Effective  period  (Can  set  unlimited) -System  should  not  raise  the  other  surface  above  its  during  effective  period. -System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -a.  The  effect  at  the  transition -b.  The  effect  of  display  surface -System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are -sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all -layers  will  be  superimposed  by  z-order. -System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. -System  must  hide  the  surface  that  has  too  much  information. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Visible  /  Invisible -b.  Change  position -c.  Raise -The  receive  request  must  include  as  follows. -i.  Surface  ID  \*Only  case  of  visible. -ii.  Display  ID  \*Only  case  of  visible. -iii.  Layer  ID  \*Only  case  of  visible. -Page  46  of  159 -![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. -v.  Size  (Length  \*  Width)  \*Only  case  of  visible. -System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. -a.  The  effect  at  the  transition -b.  The  effect  of  display  surface -4.1.3.2.2  Sound  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone -information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as -follows. -a.  ID -b.  Sound  device  ID -System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses -sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must -include  as  follows. -a.  ID -(2)  Judgment  of  Priority  of  GUI  resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -request  during  system  running. -Page  47  of  159 -![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  receive  request  must  include  as  follows. -a.  Role -b.  Zone  ID -c.  Sound  type  ID -System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly -release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during -system  running. -The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal -request. -a.  Effective  period  (Can  set  unlimited) -System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner -by  other  request  on  same  area  during  effective  period. -System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. -a.  The  effect  at  the  transition -b.  The  effect  of  output  sound -System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more -resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority -of  resources  that  is  related  to  role. -\*  Boundary  of  the  role  between  Policy  Manager  and  application. -Page  48  of  159 -![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Figure  7-12:  Boundary  of  role  (Case  of  reverse) -System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system -should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. -For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound -from  request  history  based  on  the  priority. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Mute  /  Unmute -b.  Change  zone -The  receive  request  must  include  as  follows. -i.  Stream  ID -ii.  Device -In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. -iii.  Channel  ID -Page  49  of  159 -![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. -a.  The  effect  at  the  transition -b.  The  effect  of  output  sound -4.1.3.2.3  Input  Resource -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource -owner. -System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses -input  device  information  with  to  control  input  event  to  other  system.  The  receive  information -must  include  as  follows. -a.  ID -System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses -input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must -include  as  follows. -a.  ID -b.  Related  event  IDs -(2)  Judgment  of  Priority  of  GUI  resource -System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource -according  to  external  condition.  This  means  that  system  judges  the  providing  resource. -System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive -request  during  system  running. -The  receive  request  must  include  as  follows. -a.  Input  device  ID -Page  50  of  159 -![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b.  Event  type  ID -System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the -limitation  routing  rule  of  policy  DB. -(3)  GUI  Resource  Control -System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. -System  must  provide  a  mechanism  to  issue  the  following  resource  control. -a.  Set  the  routing  rule -The  receive  request  must  include  as  follows. -i.  Input  device  ID -ii.  Event  type  ID -The  receive  request  must  include  either  as  follows. -iii.  The  allowed  application -iv.  The  denied  application -System  should  provide  a  mechanism  to  set  the  following  information. -a.  Application  that  has  active  surface -System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This -feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen -changes  the  active  surface. -4.1.3.2.4  System  Resources -(1)  External  Condition  Collection -System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager -to  decide  proper  system  resource. -Page  51  of  159 -![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Policy  Manager  must  detect  creation  and  deletion  of  process. -To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created -process. -Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to -other  active  processes. -To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to -identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each -active  process. -Policy  Manager  must  detect  current  memory  consumption  periodically. -To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each -process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were -thought  as  not  so  important  process. -Policy  Manager  must  detect  current  CPU  consumption  periodically. -To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep -system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected -busy  state. -System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. -Application  status  includes  as  below. -· GUI  resource  status,  such  as  foreground  or  background. -· -Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must -resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last -application  to  resume  quickly  as  much  as  possible. -(2)  System  Resource  Control -System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process -group  according  to  external  conditions. -According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to -target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups -Page  52  of  159 -![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -will  be  used) -System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. -4.1.3.2.5  Resource  Management -Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy -Manager,  Connection  Manager. -Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. -Each  resource  request  shall  be  in  form  a: -AppID, -SourceID, -RequestorZoneID, -NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), -Required  Resource  List. -Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin -Speakers,  HeadPhones) -Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) -Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, -Tuners  etc.) -Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request -from  resource  requestors. -Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. -Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) -Page  53  of  159 -![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list -are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) -Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system -through  status  update. -Resource  Management  shall  support  stacking/queuing  of  resource  requests. ->  Receive  the  requests  from  the  resource  requestors. ->  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy -Manager. ->  Add  the  validated  requests  into  a  priority  queue. ->  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. ->  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it -shall  be  removed  from  the  queue. -Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier -request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it -shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. -If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the -requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. -If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant -some/all  of  the  resources  requested  by  the  requestor. -Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an -existing  resource  request. -Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of -policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs -for  the  policy  decision: ->  Currently  Free  or  InUse  Sink  status ->  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) -Page  54  of  159 -![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 ->  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. -Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a -request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the -policy  decision: ->  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept -pending. ->  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. -At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by -resource  requestor: ->  Zone  ID ->  Allocated  Source  Instance ->  Allocated  Sink  Instance ->  Mute  status -Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality -(e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to -the  resource  management  policy. -Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature -functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). -Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: -AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have -same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, -the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. -Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, -AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource -request  will  be  the  one  that  is  granted  the  resource. -A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. -It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. -Page  55  of  159 -![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. -It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource -Manager  if  the  resource  is  no  longer  needed. -Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all -available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once -the  request  is  granted  against  the  set  policy. -Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. -Possible  connection  states  are  Active  or  Passive. ->  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be -active. -Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. ->  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be -passive. -Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same -AMFM  source  on  Rear  headphone  sink. -Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink -connection  using  the  underlying  platform  support. -Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink -connection  using  the  underlying  platform  support. -Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is -removed/released. -Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is -re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. -Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. -Page  56  of  159 -![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready -to  be  used  for  audio  routing. -Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio -routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. -Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. -Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which -source  instance. -Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: ->  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. -System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -Headphones  shall  not  be  required  to  support  any  foreground  sinks. -In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a -source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source -(if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). -As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not -disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background -connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. -Page  57  of  159 -![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State -Manager. -It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. -It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on -current  system  scenario. -E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call -is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a -pending  request. -It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. -It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. -It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video -resources  and  update  its  internal  status  accordingly. -On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active -connections  and  reconnect  or  disconnect  if  required. -E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. -Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of -connections  shall  be  rebuilt  with  Amp. -It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. -Page  58  of  159 -![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying -platform  support. -It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the -underlying  platform  support. -It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. -It  shall  provide  an  interface  to  unmute  an  audio  sink. -System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks -are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally -1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. -The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. -It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. -Headphones  shall  not  be  required  to  support  any  foreground  sinks. -It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. -It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. -It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. -**4.1.4  Sound  Manager** -A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from -two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a -policy  manager  manages  a  mediation  rule. -Page  59  of  159 - - ---------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ------------------------------------------------------------ - > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). - - > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume - > - > control  of  each  sound  streams. - - > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, - > - > ·     When  changing  sound  stream.  E.g.  fade-in, - > - > fade-out  and  cross-fade. - - > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce - > > - > hardware > dependency  of  hardware.  Well-defined  interface - > - > also  makes  it  possible  to  increase  the  effect  of - > - > portability  and  development  cost. - ---------------------------------------------------------------------------------------------------- - -![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a -passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound -resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. -Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like -volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server -to  implement  automatic  audio  policies. -**4.1.4.1  Use  Case** -Please  refer  “sound  resource  control”  of  Policy  Manger  section. -Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. -**4.1.4.2  Requirements** -Page  60  of  159 -![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4.1.4.2.1  Routing  Sound  Streams -System  must  provide  a  mechanism  to  manage  sound  “zone”. -Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a -zone  and  how  to  manage  zone. -System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each -channels  of  each  sound  device. -One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists -of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. -For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is -arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when -outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower -musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than -music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound -device. -The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more -zones. -Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the -present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the -mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. -System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. -System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. -All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. -System  must  provide  a  mechanism  to  control  sound  stream. -Control  of  a  sound  stream  is  as  follows. -· -Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound -stream. -· -Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound -Page  61  of  159 -![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -stream. -Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. -4.1.4.2.2  Mixing  Level  Control -The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to -the  same  zone  according  to  a  policy  manager's  arbitration. -System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. -System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream -requested  to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating -the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. -System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested -to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted -sound  stream  was  ended. -System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream -requested  to  play  into  same  sound  zone. -In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound -stream  was  ended. -4.1.4.2.3  Sound  Effect -When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. -System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. -System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin -architecture. -Page  62  of  159 - - ------------------------------------------------------------------------------------------------------------------------- - > **No.** > **Input  type** > **Associated  device** > **Description** - ----------- ------------------- -------------------------- -------------------------------------------------------------- - > 1 > Key > Steering  switch > Simple  key  event. - > - > Deliver  to  application. - - > 2 > Keyboard > Virtual  keyboard > Keyboard  event. - > - > Deliver     to     application,     then     use     input - > - > method  backend  if  needed. - - > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. - > - > Also  supports  double  click  and  multi-touch - > - > capability. - > - > Deliver  to  application. - - > 4 > Sound > Microphone > Sound  input. - ------------------------------------------------------------------------------------------------------------------------- - -![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4.1.4.2.4  Reduced  Dependency  of  Hardware -Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels -of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means -which  does  not  need  rebuild  of  systems,  such  as  a  configuration. -**4.1.5  Input  Manager** -The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application -depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each -input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering -switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. -**4.1.5.1  Use  Case** -Please  refer  “input  resource  control”  of  Policy  Manger  section. - - --------------------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- --------------------------- ----------------------------------------------------------------- - > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to - > - > application  readable  event  name,  such  as  “volume - > - > up”  and  “right  arrow”. - - > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified - > - > application. - --------------------------------------------------------------------------------------------------------- - -![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Deliver  to  application  or  voice  recognition -engine. -Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. -**4.1.5.2  Requirements** -**4.1.5.3  Abstract  Device  Event** -System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. -Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional -equipment. -**4.1.5.4  Event  Delivery** -System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. -System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” -and  “destination  application  id”. -Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by -UIM.2.1.2. -Page  64  of  159 -![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. -System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. -System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on -delivery  rule  defined  in  UIM.2.1.1. -System  must  provide  a  mechanism  to  inhibit  any  event  delivery. -This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. -**4.1.6  User  Manager** -**4.1.6.1  Use  Case** -**4.1.6.2  Personal  Identification** -User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a -person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. -**4.1.6.3  User  Preference** -Multi-user  environment  provides  same  user  experience  for  each  user. -Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including -other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data -sharing  from  your  home  and  your  office. -Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be -provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. -Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user -experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, -*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is -Page  65  of  159 -![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. -**Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** -**4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** -When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If -Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is -important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s -preference. -**Figure  7-25  :  User  data  sharing  between  cars** -Page  66  of  159 -![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**4.1.6.5  Seamless  Data  Sharing** -Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and -smart-phones,  home  networks  and  accessing  from  your  offices. -**Figure  7-26  :  User  data  sharing  over  the  cars** -**4.1.6.6  Role** -**Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above -purpose  and  use  cases. -**Table  7-17  :  Role  of  User  Manager** -**No.** **Role** **Description** -Page  67  of  159 -![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -1 User  identification -Provide  a  mechanism  to  identify  user,  such  as  user -name  and  password  pair,  smart  key  and  biometrics. -Provide  a  mechanism  to  log-in  to  the  IVI  system  as -a  specified  user. -When a different user logs in, proper user -preference  for  the  user  must  be  applied,  and -resume  last  state  of  corresponding  user. -Also,  each  application  can  store  application’s  data -per  user.  In  such  cases,  proper  user  data  must  be -applied  when  a  different  user  logs  in. -2 User  preference -Provide  a  mechanism  to  apply  user  preference  of -logged-in  user. -User  preference  includes  the  following  data. -· User  interface,  such  as  locale  and  wall- -paper. -· Resume  last  application’s  status  of  specified -user. -· Application  specific  data. -3 User  data  management -Provide  a  mechanism  to  manage  cloud  based  user -data. -The  following  capabilities  are  required. -· Download  user  data  of  the  logged-in  user -from  the  cloud. -· Update  cloud  data  if  the  user  data  was -updated  by  user  operation  or  otherwise. -· Periodically  sync-up  w/  cloud  because  user -data  may  be  updated  by  other  devices. -In  addition  to  the  above  basic  capabilities,  user  data -cache  is  essential  for  a  car,  since  a  car  may  not -always  have  a  reliable  network  connection. -4 Security Because  cloud  based  sharing  user  data  may  be -accessed  from  any  place,  user  data  must  be -protected  from  unexpected  data  access. -Page  68  of  159 -![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -So,  IVI  system  must  provide  security  mechanism -regarding  accessing  to  cloud  based  user  data. -**4.1.6.7  Requirements** -4.1.6.7.1  User  Identification -System  must  provide  a  mechanism  to  identify  logged-in  user. -System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to -identify  logged-in  user. -System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For -example,  using  NFC. -System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. -4.1.6.7.2  User  Preference -When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the -currently  logged-in  user. -System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. -- Locale  settings -- UX  theme -Wall  paper -System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized -user  experience. -Page  69  of  159 -![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in -user’s  application  data  automatically. -When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last -status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the -system.  Specifically,  last  status  includes  the  following. -- Foreground  applications.  That  means  displayed  applications. -Background  applications. -When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. -System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. -System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. -4.1.6.7.3  User  Data  Management -System  must  provide  a  mechanism  to  manage  user  data. -AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user -preference. -User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but -also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and -home  electronics. -System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to -application  by  using  cloud  based  user  data. -System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data -of  the  IVI  system. -When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to -the  cloud. -Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide -Page  70  of  159 -![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. -Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a -mechanism  to  cache  downloaded  user  data. -If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as -possible. -4.1.6.7.4  Security -Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to -protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. -System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. -- -System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must -authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, -smartphone  or  PC. -- -System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. -- -System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection -against  falsification  of  data  from  unauthorized  access  or  illegal  access. -- -Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide -user  data  only  to  the  authorized  user. -Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must -provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to -include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against -cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. -4.2  Web  HMI -Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. -**4.2.1  Web  API** -Page  71  of  159 -![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service -function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio -visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, -Photo,  etc.) -Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of -Audio  Visual  API  is  shown  in  Figure  6-1. -**Figure  6-1:  Use  case  of  Audio  Visual  API** -**4.2.1.1  Requirements** -Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. -· Select  content  using  URL -· -Select  content  using  contents  list  provided  by  multimedia  subsystem -Page  72  of  159 -![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, -DVD,  BT-Audio,  Photo,  etc.) -· Play -· Pause -· Fast-forward -· Rewind -· Track  up -· Track  down -· Select  playmode  (Repeat/Random) -Audio  Visual  API  must  provide  API  to  control  a  volume. -· Volume  up -· Volume  down -· Mute -Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. -Audio  Visual  API  must  provide  API  for  notifications. -· The  case  that  playback  state  is  changed -· The  case  that  Audio  Visual  contents  is  add  /  removed -Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. -· Change  the  frequency. -· Change  the  broadcasting  stations. -· Receive  the  list  of  broadcasting  stations. -· Select  the  preset  channel. -· Get  the  information  of  the  broadcasting  station. -Audio  Visual  API  must  provide  API  to  play  digital  radio. -· Store  the  broadcast  program  information. -Page  73  of  159 -![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Get  the  broadcast  program  information. -· Get  the  play  time. -· Play  the  radio  broadcast  cached. -AGL  System  must  support  a  web  API  to  access  Vehicle  information. -AGL  System  must  support  web  API  to  control  STT/TTS  daemon. -AGL  System  must  support  web  API  to  control  navi  engine. -AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web -apps. -AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app -and  a  native  app. -AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider -should  be  able  to  restrict  subscriber. -AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. -AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, -Network  Information -AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG -AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio -AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, -server  sent  events,  session  history  of  browsing  context -*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL -Page  74  of  159 -![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 -The  iframe  element,  Content  Security  Policy  1.0. -AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications -AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing -control,  Navigation  timing -AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation -AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, -Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy -AGL  System  must  support  Khronos  WebGL  API. -**4.2.2  Web  Runtime** -The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access -the  AGL  Application  Framework  and  Services. -**4.2.2.1  Requirements** -AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., -installation/removal). -AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, -view  generation,  rendering,  etc.) -AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add -better  device/platform  integration. -Page  75  of  159 -![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to -categorize  apps  with  different  privileges. -System  must  provide  high  level  GUI  components  for  Web  application. -At  least,  below  components  are  required. -· Text  labels -· Button -· Radio  button -· Check  box -· Tab  panel -· Animation  (e.g.  MNG,  GIF  animation) -· Slider -· Accordion  list -· Anchor -· Text  input  form -· Dropdown  list  box -· Date  picker -4.3  Native  HMI -The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written -using  Javascript  or  other  web  technologies. -**4.3.1  Native  App  Runtime** -The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to -access  the  AGL  Application  Framework  and  Services. -**4.3.1.1  Requirements** -System  must  provide  high  level  GUI  components  for  native  application. -Page  76  of  159 -![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -At  least,  below  components  are  required. -· Text  labels -· Button -· Radio  button -· Check  box -· Tab  panel -· Animation  (e.g.  MNG,  GIF  animation) -· Slider -· Accordion  list -· Anchor -· Text  input  form -· Dropdown  list  box -· Date  picker -**4.3.2  Native  Application  Framework** -The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an -SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that -framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the -application  framework  provides  for  its  applications. -**5   Services   Layer** -The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the -services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces -remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime -modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid -unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer -interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces -provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may -choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework -runtime  to  adjust  to  any  new  interfaces, -Page  77  of  159 -![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1  Platform  Services -Platform  Services  Layer.  Conventional  Linux  platform  services -**5.1.1  Bluetooth** -This  document  describes  requirements  regarding  registration,  (dis)connection  and  device -information  management  between  Bluetooth  device  and  infotainment  system.  Necessary -Bluetooth  profiles  in  automotive  use  case  are  defined  here. -**5.1.1.1  Requirements** -The  Telephony  system  shall  be  designed  to -support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR -without  hardware  upgrade. -A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: -· Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) -· HFP  (Hands  Free  Profile) -· OBEX  (Object  Exchange) -· OPP  (Object  Push  Profile) -· PBAP  (Phonebook  Access  Profile) -· SPP  (Serial  Port  Profile) -· SDAP  (Service  Discovery  Access  Profile) -If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music -from),  the  system  shall  also  support  the  following  incremental  BT  profiles: -· A2DP  (Advanced  Audio  Distribution  Profile) -· AVRCP  (Audio  Visual  Remote  Control  Profile) -The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the -Page  78  of  159 -![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of -generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in -encryption  key  length  negotiation. -When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as -default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority -scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration -time. -The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is -10  meters  and  maximum  power  is  2.5  mW  (4  dBm). -The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall -allow  using  five-slot  packet  transmission  for  faster  data  rate. -The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a -standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. -vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are -often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain -name  and  address  information,  phone  numbers,  and  e-mail  addresses. -vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, -LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, -URL,  UID,  Version,  and  KEY  properties. -vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: -MIME  Content-Type  for  Directory  Information -vCard  MIME  Directory  Profile -It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with -the  vCard  version  2.1  properties. -The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any -associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is -not  full. -The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO -Page  79  of  159 - - ------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **Support  in  HF** > **AGL** - ----------- ------------------------------------------------------------- ----------------------- ----------- - > 1 > Connection  management > Mandatory > x - - > 2 > Phone  status  information > Mandatory > x - - > 3 > Audio  Connection  handling > Mandatory > x - - > 4 > Accept  an  incoming  voice  call > Mandatory > x - - > 5 > Reject  an  incoming  voice  call > Mandatory > x - - > 6 > Terminate  a  call > Mandatory > x - - > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x - - > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x - > - > HF - - > 9 > Place  a  call  using  memory  dialing > Option > - - - > 10 > Place  a  call  to  the  last  number  dialed > Option > - - ------------------------------------------------------------------------------------------------------------- - -![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -shall  be  used. -5.1.1.1.1  Hands  Free  Profile -The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile -specification  version  1.6  or  later. -The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, -wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and -output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to -the  actual  phone. -It  shall  provide  following  roles: -Hands-Free  unit  (HF) - - > 11 > Call  waiting  notification > Option > x - ------- ------------------------------------------------------ ---------- ---------- - > 12 > Three  way  calling > Option > x(\*1) - > 13 > Calling  Line  Identification  (CLI) > Option > x - > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x - > 15 > Voice  recognition  activation > Option > x - > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - - > 17 > Ability  to  transmit  DTMF  codes > Option > x - > 18 > Remote  audio  volume  control > Option > - - > 19 > Respond  and  Hold > Option > x - > 20 > Subscriber  Number  Information > Option > x - > 21a > Enhanced  Call  Status > Option > x - > 21b > Enhanced  Call  Controls > Option > - - > 22 > Individual  Indicator  Activation > Option > - - > 23 > Wide  Band  Speech > Option > x - > 24 > Codec  Negotiation > Option > x - -![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -\*1:  Does  not  support  Multi-party  (conference)  call -The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the -model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -string  in  a  phone  model  CGMM  variable. -· Phone  Model  CGMM: -· Type:  string -· Max  length:  200  chars -Page  81  of  159 -![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the -Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be -stored  as  a  string  in  a  phone  model  CGMI  variable. -· Phone  Model  CGMI: -· Type:  string -· Max  length:  200  chars -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the -revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a -string  in  a  phone  model  CGMR  property. -· Phone  Model  CGMR: -· Type:  string -· Max  length:  200  chars -· Persistence:  No -A  property  shall  exist  for  each  device  which  is  connected  to  the  system. -The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the -device. -5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) -The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP -specification  version  1.2  or  later. -Page  82  of  159 - - > **No.** > **Codec** > **Support** > **AGL** - ----------- ------------------- --------------- ----------- - > 1 > SBC > Mandatory > x - > 2 > MPEG-1,2  Audio > Option > - - > 3 > MPEG-2,4  AAC > Option > - - > 4 > ATRAC  family > Option > - - - > **No.** > **Feature** > **Support  in  SNK** > **AGL** - ----------- -------------------- ------------------------ ----------- - > 1 > Audio  Streaming > Mandatory > x - -![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to -realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. -It  shall  provide  following  roles: -Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from -the  SRC  on  the  same  piconet. -Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. -Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. -Copyright  protection  technology  SCMS-T  should  be  supported. -5.1.1.1.3  Phone  Book  Access  Profile -Page  83  of  159 -![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification -version  1.1  or  later. -The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between -devices. -Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The -Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected -device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing -and  copying  contact  information. -It  shall  provide  following  roles: -· Phonebook  Client  Equipment  (PCE) -It  shall  provide  following  types  of  Phonebook  objects: -· The  main  Phonebook  object -· The  Incoming  Call  History  object -· The  Outgoing  Call  History  object -· The  Missed  Call  History  object -· The  Combined  Call  History  object -A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device -automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook -download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: -· Using  PBAP  profile -All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. -SIM)  and  also  any  stored  in  the  BT  device's  memory. -The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the -vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded -from. -5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile -Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -Page  84  of  159 - - > **No.** > **Service** > **Support  in  DT** > **AGL** - ----------- ------------------------------------------- ----------------------- ----------- - > 1 > Data  call  without  audio  feedback > Mandatory > x - > 2 > Data  call  with  audio  feedback > Option > - - > 3 > Fax  services  without  audio  feedback > N/A > - - > 4 > Fax  services  with  audio  feedback > N/A > - - > 5 > Voice  call > N/A > - - > 6 > Incoming  calls > Option > x - > 7 > Outgoing  calls > Mandatory > x - -![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” -Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. -5.1.1.1.5  Object  Push  Profile  (OPP) -Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower -layers. -It  has  to  comply  with  the  specification  for  “Push  Server”. -Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. -**Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** -Page  85  of  159 - - > **No.** > **Feature** > **Support  in  CT** > **AGL** - ----------- -------------------------------------------- ----------------------- ----------- - > 1 > Connection  establishment  for  control > Mandatory > x - > 2 > Release  connection  for  control > Mandatory > x - > 3 > Connection  establishment  for  browsing > C6 > x - - ------------------------------------------------------------------------------------- - > **No** > **Feature** > **Support  in  Push  Server** > **AGL** - > - > **.** - ---------- ---------------------------- --------------------------------- ----------- - > 1 > Object  Push > Mandatory > x - - > 2 > Business  Card  Pull > Option > - - - > 3 > Business  Card  Exchange > Option > - - ------------------------------------------------------------------------------------- - -![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) -The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. -The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device -plus  one  remote  control.. -The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL -column  in  Table  25  should  be  supported. -C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional -otherwise -C3:  Mandatory  to  support  at  least  one  Category -C4:  Mandatory  if  Category  2  supported,  excluded  otherwise -C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise -EX:  Excluded -Page  86  of  159 -![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -4 Release  connection  for  browsing C6 x -5 AV/C  Info  commands Option x -6 Category  1:  Player/Recorder C3 x -7 Category  2:  Monitor/Amplifier C3 - -8 Category  3:  Tuner C3 - -9 Category  4:  Menu C3 - -10 Capabilities Option x -11 Player  Application  Settings Option x -12 Metadata  Attributes  for  Current  Media  Item Option x -13 Notifications C2 x -14 Continuation C2 x -15 Basic  Group  Navigation Option x -16 Absolute  Volume C4 - -17 Media  Player  Selection Option x -17.1 -  Supports  Multiple  Players Option x -18 Browsing Option x -18.1 -  Database  Aware  Players Option x -19 Search Option - -20 Now  Playing C6 x -20.1 -  Playable  Folders Option x -21 Error  Response EX - -22 PASSTHROUGH  operation  supporting  press  and Option x -Page  87  of  159 - - ------------------------------------------------------------------------------ - > **No** > **Feature** > **Support  by  the  MCE** > **AGL** - > - > **.** - ---------- ------------------------- ----------------------------- ----------- - > 1 > Message  Notification > C1 > x - - > 2 > Message  Browsing > C1 > x - - > 3 > Message  Uploading > Option > x - - > 4 > Message  Delete > Option > - - - > 5 > Notification > C2 > x - > - > Registration - ------------------------------------------------------------------------------ - -![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -hold -The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and -pass  this  information  up  to  so  it  can  be  passed  to  the  User. -5.1.1.1.7  Message  Access  Profile -Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary -lower  layers. -It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. -Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. -C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features -C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message -Notification.  Not  applicable  otherwise. -Page  88  of  159 - - > **No.** > **Feature** > **Support  in  PANU** > **AGL** - ----------- ------------------------------------------ ------------------------- ----------- - > 1 > Initialization  of  NAP/GN  service > - > - - > 2 > Shutdown  of  NAP/GN  service > - > - - > 3 > Establish  NAP/GN  service  Connection > Mandatory > x - -![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.8  Serial  Port  Profile  (SPP) -The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version -1.1  or  later. -It  shall  provide  following  roles: -Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. -Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. -Following  features  shall  be  provided  by  the  Supplier: -Establish  link  and  setup  virtual  serial  connection -Accept  link  and  establish  virtual  serial  connection -Register  Service  record  for  application  in  local  SDP  database -5.1.1.1.9  Personal  Area  Network  (PAN)  Profile -Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. -Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. -Page  89  of  159 - - > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x - ----- ------------------------------------------- ------------- ----- - > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x - > 6 > Management  Information  Base  (MIB) > - > - - -![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.10  Service  Discovery  Profile  (SDP) -The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP -specification  version  1.1. -The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices -in  the  vicinity  of  a  Bluetooth  enabled  device. -It  shall  provide  following  roles: -Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. -Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to -the  service  inquiries  generated  by  Local  Device. -The  following  features  shall  be  provided  by  the  Supplier: -Search  for  services  by  service  class -Search  for  services  by  service  attributes -Service  browsing -5.1.1.1.11  Device  Information  Profile -Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for -necessary  lower  layers. -Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. -**Table  28  :  List  of  DIP  Supporting  Functions** -Page  90  of  159 - - > **No.** > **Feature** > **Support** > **AGL** - ----------- ----------------------- --------------- ----------- - > 1 > SpecificationID > Mandatory > x - > 2 > VendorID > Mandatory > x - > 3 > ProductID > Mandatory > x - > 4 > Version > Mandatory > x - > 5 > PrimaryRecord > Mandatory > x - > 6 > VendorIDSource > Mandatory > x - > 7 > ClientExecutableURL > - > - - > 8 > ServiceDescription > - > - - > 9 > DocumentationURL > - > - - -![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.1.1.12  Bluetooth  Smart  Ready -Bluetooth  Smart  Ready  shall  be  supported. -It  shall  comply  with  Bluetooth  Low  Energy  standard. -5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) -The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX -specification  version  2.0  or  later. -The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between -devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. -It  shall  provide  following  roles: -Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data -objects  shall  be  pushed  and  pulled,  respectively. -Page  91  of  159 -![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. -The  following  features  shall  be  provided  by  the  Supplier: -Establishing  an  object  connection -Pushing  a  data  object -Pulling  a  data  object -Performing  an  action  on  data  objects -Creating  and  managing  a  Reliable  Object  Exchange  Connection -5.1.1.1.14  Generic  Audio/Video  Distribution  Profile -The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the -GAVDP  specification  version  1.2  or  later. -The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between -two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. -It  shall  provide  following  roles: -Initiator  (INT) -Acceptor  (ACP) -Following  are  the  feature  requirements  for  this  profile: -Connection -Transfer  Control -Signalling  Control -Security  Control -Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not -yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. -5.1.1.1.15  Bluetooth  Diagnostics -**5.1.2  Error  Management** -The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes -Page  92  of  159 -![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized -restart.  In  addition, -in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery -to  issue  in  a  short  amount  of  time. -**5.1.2.1  Use  Cases** -5.1.2.1.1  System  Surveillance  and  Recovery -While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an -immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating -the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to -try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating -middle  ware,  reboot  the  whole  system  to  try  and  recover. -There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that -adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The -AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. -The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even -if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be -done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error -Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the -degree  should  be  adjusted  by  its  behavior  status. -5.1.2.1.2  Collecting  Information -For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt -recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the -cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. -With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On -the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come -Page  93  of  159 -![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, -the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. -**5.1.2.2  Requirements** -Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its -status  automatically  and  recover -The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each -process. -The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. -When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold -value,  action  is  changeable  by  AGL  user. -Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification -to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are -output  communication  or  disk  I/O. -Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification -by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an -error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication -error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. -Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it -should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination -of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so -those  two  should  be  able  to  set  separately. -Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold -value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be -changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. -Should  be  able  to  vanish  process  forcibly  including  subsidiary  process -Page  94  of  159 -![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Make  the  software  that  works  by  system  have  the  concept  of  level  importance. -Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be -adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. -The  process  that  detecting  an  external  communication  error  within  the  Error  Management -module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. -The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as -more  than  one  process. -The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple -applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where -multiple  applications  can  be  moved  by  the  same  process. -Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing -process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as -process  crash,  exit,  etc.. -An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends -suddenly  the  other  will  not  become  abnormal  state. -The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other -process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards -external  side. -When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart -additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered -beforehand. -The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file -system  without  destroying  them. -Page  95  of  159 -![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for -analyzing. -When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a -message  that  can  specify  the  cause. -Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -in  a  short  period  of  time  have  been  equipped  and  able  to  select. -In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or -system  down  does  not  occur  (self-destruction  on  log  output  process). -Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. -Should  be  able  to  select  the  level  of  log  output. -Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. -Should  be  able  to  obtain  the  information  linked  to  the  system  resources. -Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. -Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log -in  a  short  period  of  time  have  been  equipped  and  able  to  select. -As  the  smallest  amount  of  information,  the  following  information  should  be  left. -· Register  information -· Process  logical  memory  map -· -Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence -· Time  of  occurrence -· -Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing -file‑name  of  the  thread  etc.) -Page  96  of  159 -![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· The  signal  that  occurred -Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. -· -Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted -for  an  output. -· -Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent -dropping  the  information  needed. -· -Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] -· -Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed -maximum  size. -· -NOTE  information  of  ELF  header  and  program  header  will  not  change. -Selectable  memory  mappings  are  the  following. -· anonymous  private  mappings -· anonymous  shared  mappings -· file-backed  private  mappings -· file-backed  shared  mappings -· private  huge  page -· shared  huge  page -Setting  parameters  of  the  output  context  are  the  following. -· -Memory  mapping  category  which  is  for  an  output  object  can  be  set. -· The  order  of  outputting  memory  mapping  can  be  set. -Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in -increments  of  process. -Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be -able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. -Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. -Page  97  of  159 -![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. -**5.1.3  Graphics** -Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. -**5.1.4  Location  Services** -Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead -reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary -output  of  the  GPS  receiver. -**5.1.4.1  Position** -**5.1.4.2  Time  of  Day** -With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car -device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of -its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in -future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. -**Monotonic  and  Absolute  Time  Support** -As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. -Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s -moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and -Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. -On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time -that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, -some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports -Monotonic  Time. -**Kernel  Time  Precision** -Page  98  of  159 -![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those -communicating  system  includes  the  device  that  needs  ms  order  procedure. -In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on -the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest -value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. -**5.1.4.3  Requirements** -Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. -Adjust  the  system  time  after  the  time  is  determinate. -GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using -the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. -GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not -imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make -Source  plugin  can  not  be  GPL  or  LGPL. -When  waiting,  can  use  both  absolute  time  and  monotonic  time -Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -monotonic  time. -Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and -monotonic  time. -System  time  must  be  able  to  use  consecutively  at  least  until  2099. -Absolute  time  has  to  support  leap  year  and  leap  seconds. -1  jiffies  have  to  be  smaller  than  1ms. -Page  99  of  159 -![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. -From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. -A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. -**5.1.5  Health  Monitoring** -Platform  monitoring  services  such  as  watchdog  or  active  monitoring -**5.1.6  IPC** -Standard  platform  interprocess  and  interprocessor  communication  mechanism. -**5.1.7  Lifecycle  Management** -Startup,  shutdown,  state  change,  etc. -**5.1.8  Network  Services** -Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer -including  Wifi,  Bluetooth,  or  ethernet. -**5.1.9  Persistent  Storage** -Power  safe  persistent  storage -**5.1.10  Power  Management** -Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs -in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. -*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* -Page  100  of  159 -![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -modern  ECUs -In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, -in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal -balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important -for  overall  durability  characteristic. -Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming -more  welcomed  over  traditional  cold  boot  approaches. -Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has -become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only -consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) -**5.1.10.1  Requirements** -AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend -states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” -/“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. -AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state -transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state -transitions  if  no  requests  provided  from  applications. -Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of -this  specification  (it  is  also  platform-dependent). -AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of -cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting -core  in  one  of  its  low  power  states) -AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular -cores  from  SMP  group. -Page  101  of  159 -![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points -(table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, -some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget -insignificant) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling -Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. -Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they -may  have  negative  impact  on  overall  system  performance/predictability -AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is -platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) -Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states -Only  application-defined  policies  shall  be  allowed  for  CPU  Idle -AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices -AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling -**5.1.11  Resource  Management** -Resource  and  device  management. -Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource -request  by  the  Resource  Manager. -**5.1.12  Telephony  Services** -**5.1.12.1  Requirements** -Page  102  of  159 -![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.12.1.1  Telephony  variants -Purpose:  To  define  the  variants  of  Telephony -Requirement: -There  will  be  2  variants  of  phone  system. -Variant  1:  Front  User  only  Telephony. -Variant  2:  Rear  and  Front  Telephony. -All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature -can  be  disabled  via  car  configuration. -**5.1.13  Wi-Fi** -This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information -management  between  a  wireless  LAN  device  and  infotainment  system. -Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. -**5.1.13.1  Use  Cases** -5.1.13.1.1  Construct  WiFi  Network -In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. -a\. STA -In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via -an  Access  Point. -It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. -b\. AP -In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices -with  an  external  network. -Page  103  of  159 -![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. -c\. P2P -In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- -Fi  Direct. -5.1.13.1.2  Miracast -In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) -They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, -by  using  UIBC  (User  Interface  Back  Channel).-(b) -**Figure  8-29  :  Overview  of  Miracast** -a\. Shared  Displayed  Content -Page  104  of  159 -![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Use  case  examples  of  shared  displayed  content  are: -· -A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device -(e.g.  Mobile)  on  In-Vehicle  Infotainment  system. -· -A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment -system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). -b\. Remote  Operation -Use  case  examples  of  remote  operation  are: -· -A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device -(e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. -· -A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle -Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). -· -While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation -functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. -Mobile). -5.1.13.1.3  DLNA -In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. -**5.1.13.2  Requirements** -5.1.13.2.1  Security -The  WiFi  module  shall  support  security  standard  WEP. -It  shall  support  40  bit  WEP  encryption  method. -It  shall  support  104  bit  WEP  encryption  method. -It  shall  support  security  standard  WPA  Personal. -Page  105  of  159 -![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA2  Personal. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA  Enterprise. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -It  shall  support  security  standard  WPA2  Enterprise. -It  shall  support  TKIP  encryption  method. -It  shall  support  CCMP  encryption  method. -5.1.13.2.2  Simple  Configuration -It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. -It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. -It  shall  support  Configuration  Method  for  Display. -Page  106  of  159 -![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  support  Configuration  Method  for  Keypad. -It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. -It  shall  support  Configuration  Method  for  PushButton. -It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. -5.1.13.2.3  QoS -It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. -It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. -5.1.13.2.4  STA -The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). -5.1.13.2.5  AP -The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). -5.1.13.2.6  WiFi  Direct -It  shall  comply  with  Wi-Fi  Direct  standard. -It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. -Page  107  of  159 - - -------------------------------------------------------------------------------------------------------------------- - > **No.** > **Feature** > **(Reference)** - > - > **Support  in  Wi-** - > - > **Fi  Direct** - ----------- ---------------------------------------------------- -------------------------- ------------------------ - > 1 > P2P  Provision > ‑ > Mandatory - > - > Discovery - - > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory - - > 3 > ‑ > Find  Phase > Mandatory - - > 4 > P2P  GO  Negotiation > ‑ > Mandatory - - > 5 > P2P  Service  Discovery > ‑ > Option - - > 6 > P2P  Invitation > Temporary  P2P  Group > Option - - > 7 > ‑ > Persistent  P2P  Group > Option - - > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option - - > 9 > Intra-BSS  Distribution > ‑ > Option - - > 10 > Concurrent  Operation > ‑ > Option - - > 11 > P2P  Service  Discovery > UPnP > Option - - > 12 > ‑ > Bonjour > Option - - > 13 > ‑ > Wi-Fi  Display > Option - - > 14 > ‑ > WS-Discovery > Option - - > 15 > ‑ > Vendor  specific > Option - -------------------------------------------------------------------------------------------------------------------- - -![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.13.2.7  Miracast -Page  108  of  159 - - -------------------------------------------------------------------------------------------------------------- - > ‑**No.** > **Feature** > ‑ > **(Refere** - > - > **nce)** - > - > **Suppor** - > - > **t        in** - > - > **Miracas** - > - > **t** - ------------ ----------------------------------------------------- ----------------------- ------------------- - > 1 > WFD  Device  type > WFD  Source > Mandat - > - > ory - - > 2 > ‑ > Primary  Sink > Mandat - > - > ory - - > 3 > ‑ > Dual-role  possible > Option - - > 4 > WFD  Service > ‑ > Option - > - > Discovery - - > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat - > - > ory - - > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option - - > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option - > - > Group - - > 8 > ‑ > via  TDLS > Option - - > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat - > - > ory - - > 10 > WFD  Session  Establishment  (RTSP) > Mandat - > - > ory - -------------------------------------------------------------------------------------------------------------- - -![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  comply  with  Miracast  standard. -It  shall  support  the  Miracast  functions  identified  in  Table  30. -Page  109  of  159 - - --------------------------------------------------------------------------------- - > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat - > - > ory - ------ --------------------------------------------------- ----------- ---------- - > 12 > WFD  Standby  (RTP/RTSP) > Option - - > 13 > Video  CODEC  formats > Option - - > 14 > Audio  CODEC  formats > Option - - > 15 > UIBC > Generic - - > 16 > HIDC - --------------------------------------------------------------------------------- - -![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.1.13.2.8  WiFi  Hotspot -It  shall  comply  with  Wi-Fi  Hotspot  standard. -In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot -service. -In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. -5.1.13.2.9  DLNA  via  WiFi -The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. -**5.1.14  Window  System** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -and  a  routing  of  user  interactions. -Page  110  of  159 -![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.2  Automotive  Services -Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but -contains  services  specialized  for  automotive  applications. -**5.2.1  Audio  Services** -BTBF,  equilization,  mult-zone  audio  control,  etc. -**5.2.2  Camera  Services** -Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. -**5.2.3  Configuration  Services** -Service  for  storing  configuration  parameters. -**5.2.4  Diagnostic  Services** -Diagnostic  services. -(This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) -**5.2.5  Multimedia  Services** -CD,  DVD,  Blu-Ray,  MP3,  etc. -(Factor  out  metadata  into  separate  component.) -**5.2.5.1  Media  Player** -In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just -Page  111  of  159 -![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video -devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, -there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- -seat  passengers  as  well  as  driver  all  having  independent  requirements. -The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: -· -Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the -ones  encountered  in  mobile  and  desktop  world. -· -Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) -and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or -establishes  a  network  connection.) -· -Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of -audio  /  video  processing  chains. -Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data -processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in -comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from -navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from -Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so -on. -It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore -processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing -offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with -particular  implementation  freedom  left  for  a  silicon  vendor. -The  following  requirements  formalize  these  considerations. -**5.2.5.2  Requirements** -5.2.5.2.1  Media  Containers -AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This -includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It -shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable -input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated -from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall -be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. -Page  112  of  159 -![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, -for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream -identification  data  from  media  container. -AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: -· HTTP -· RTPS -· Digital  Radio  (DAB) -· DigitalTV  (DVB-T)  etc. -It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with -system  requirements. -AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload -computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such -extension,  if  available,  shall  be  transparent  to  the  applications. -Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. -AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the -source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without -intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this -process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of -particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from -multiple  choices. -AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall -support  the  following  functionality: -· -Selection  of  data  source  and  destination  (files,  devices,  network  resources) -· Pausing/resuming  of  multimedia  streams -· Rewinding  in  forward  and  reverse  directions  (for  playback) -· Audio  volume  control  on  per-stream  basis -· Retrieval  of  current  stream  position  (timestamp) -Page  113  of  159 -![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -Notifications  on  error  conditions  preventing  multimedia  stream  processing -AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved -into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to -specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to -specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw -audio/video  streams  to  multiple  renderers  as  well. -AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and -synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: -· -Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. -· Per-stream  volume  and  audio  effects  control. -· -Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). -· -Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). -· Mixing  and  broadcasting  of  the  audio  streams. -AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to -specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or -removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, -emergency  system  alarm  output  and  so  on. -AGL  shall  provide  support  for  major  multimedia  containers,  such  as: -· MPEG2-TS/PS  (ISO/IEC  13818-1) -· MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) -It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with -system  requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: -· OGG  (RFC  3533) -· 3GPP  (ISO/IEC  14496-12) -· etc -Page  114  of  159 -![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -5.2.5.2.2  Media  Audio  Codecs -AGL  shall  provide  support  for  major  audio  codecs,  such  as: -· -MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) -· AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) -It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system -requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: -· VORBIS  (http://xiph.org/vorbis/) -· Windows  Media  Audio -· etc. -5.2.5.2.3  Media  Video  Codecs -AGL  shall  provide  support  for  major  video  codecs,  such  as: -· MPEG-2  (ISO/IEC  13818-2) -· MPEG-4  Part  2  (ISO/IEC  14496-2) -· H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) -It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system -requirements. -It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: -· Theora  (www.theora.org) -· Windows  Media  Video -· etc -5.2.5.2.4  Image  File  Formats -Page  115  of  159 -![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true -colour. -Compression  formats -· RLE  8  bits/pixel -· RLE  4  bits/pixel -· Bit  field  or  Huffman  1D  compression -· JPEG  or  RLE-24 -· PNG -The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including -Exchangeable  Image  File  Format  (EXIF)  format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, -including  transparency -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced -version  89a  and  also  animation  in  GIFF  images. -The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -format. -The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP -format. -**5.2.6  Navigation  Services** -Navigation  engine -Page  116  of  159 -![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.7  PIM** -Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. -**5.2.8  Smartphone  Link** -This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which -realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation -is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and -AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use -smartphone  content  (map,  music,  browser...)  by  IVI. -Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. -**Figure:  8-30** -Page  117  of  159 -![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  defines  following  requirements  of  Smartphone  link. -1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. -2.  The  sound  of  smartphone  shall  be  linked  to  IVI. -3.  The  sound  shall  be  synchronized  with  the  screen. -4.  IVI  should  operate  smartphone. -5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. -6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should -inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. -This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone -link. -**5.2.8.1  Miracast** -This  section  describes  requirements  regarding  Smartphone  link  (Miracast). -Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- -Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing -between  source  device  and  sink  device. -Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. -**Figure:  8-31** -Page  118  of  159 - - ---------------------------------------------------------------------------------------------- - > **No** > **Requires** > **Description** - ------------ ----------------------------- --------------------------------------------------- - > SPL.1.1 > WFD  Topology > Define  role  of  Miracast - - > SPL.1.2 > Connection  Topology > Define  connection  condition  between - > - > a  smartphone  and  an  IVI - - > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi - > > - > 1 > Direct). - - > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency - > - > 2 - - > SPL.1.3 > Video  Format > Define  Video  format - - > SPL.1.4 > Audio  Format > Define  Audio  format - - > SPL.1.5 > Session  Control > Define  Miracast  session  state - - > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required - > - > for  implementing  Miracast - - > SPL.1.7 > Resource  Management > Define  resource  management - ---------------------------------------------------------------------------------------------- - -![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. -**References** -\[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 -\[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 -\[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision -2.2 -\[4\]  DCP  (Digital  Content  Protection)   -AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. -Page  119  of  159 -![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -SPL.1.8 Fail-safe  Control Define  Fail-safe  control -**Table  8-14:  Smartphone  Link  (Miracast)  Requirements** -**Figure:  8-32  State  Change  Diagram** -The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. -Page  120  of  159 - - ------------------------------------------------------------------------------------------------------- - > **No.** > **State** > **Description** - ----------- ------------------------- ----------------------------------------------------------------- - > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. - - > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and - > - > waiting  for  Wi-Fi  P2P  connection  from  source - > - > device. - - > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source - > - > device. - - > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. - - > 5 > Play > Streaming  the  audio  and  video  content  from  source - > - > device  to  sink  device. - - > 6 > Pause > Paused  the  streaming  of  audio  and  video  content - > - > from  source  divide  to  sink  device. - ------------------------------------------------------------------------------------------------------- - -![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.8.2  Smart  Device  Link** -“Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. -Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach -makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s -distraction  and  voice  recognition. -That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote -procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework -and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. -SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile -phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported -applications  can  be  launched. -Page  121  of  159 -![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**Figure  8-33  :  SDL  overview** -**5.2.8.3  Requirements** -5.2.8.3.1  Miracast -System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. -· -Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which -from  Source  Device‑Smartphone‑. -· Supporting  WFD  Source  is  an  option. -· -Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) -source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). -· -Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take -measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over -5Km/H) -· Support  Wi-Fi  P2P  connection. -· -Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in -Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. -· Wi-Fi  TDLS  connection  is  an  option. -· -AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select -Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) -· -AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive -Page  122  of  159 -![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for -confirmation) -· -Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. -· -Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P -connection  established. -· -Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. -· -Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) -function  if  support  5GHz  band. -· Follow  reference  \[1\]  for  Video  Codec. -· Support  follow  format  for  Video  Resolution  and  Frame  rate. -o 640\*480‑VGA‑‑Progressive  60  fps -o 1280\*720‑HD‑Progressive  30  fps -Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. -· Support  follow  format  for  Audio. -o LPCM  48ksps  16bit  2ch -o AAC  48ksps  16bit  2ch -Regarding  Audio  Format,  other  formats  are  an  option. -When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up -notification) -Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support -content  protection  function. -· -AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not -define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for -Page  123  of  159 -![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -vendor’s  own  reason. -· Support  both  encryption  cases  if  support  HDCP  function. -o Case1  Videos  data  encryption -o Case2  Both  video  and  audio  encryption -Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to -DCP.(reference  \[4\]) -· -Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, -then  Miracast  release  screen  and  audio  resources  for  the  event. -· -It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast -session.) -· -Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events -happen. -o Failed  to  Wi-Fi  connection -o Failed  to  establish  Miracast  session -o Wi-Fi  link  loss  on  Miracast -o Break  Miracast  connection  from  smartphone -5.2.8.3.2  Smart  Device  Link -System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. -System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. -System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel -device  of  IVI  device. -System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice -Page  124  of  159 -![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -recognition  of  IVI  system. -System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity -method  must  be  supported  Bluetooth  and/or  Wi-Fi. -System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity -method  must  be  supported  Bluetooth  and/or  Wi-Fi. -**5.2.9  Speech  Services** -The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. -AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands -AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech -**5.2.10  Tuner  Services** -The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into -the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, -TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present -in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. -**5.2.10.1  Receivers** -The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including -AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any -number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from -the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current -content. -The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into -the  same  API  regardless  of  the  receiver  type. -Page  125  of  159 -![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow -its  clients  to  address  each  receiver  in  the  system  independently. -5.2.10.1.1  HD  Radio -HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An -HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to -provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the -receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The -HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the -iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional -design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by -iBiquity  Digital. -The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the -requirements  in  this  section. -1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. -2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. -3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. -Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is -applicable  to. -AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status -to  the  system. -AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the -tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning -successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio -output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No -Reception"  is  available  in  that  specific  channel. -AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -Page  126  of  159 -![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Frequency -· Mono/Stereo -FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -· Frequency -· PI  Code  (RDS  only) -· PTY  (RDS  only) -· Radio  Text  (RDS  only) -· PS  Name  (RDS  only) -· Category  (RDS  only) -· Mono/Stereo -HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to -the  system,  which  shall  be  added  in  the  station  database. -· Frequency -· PTY -· No  of  HD  channels  available -· Radio  Text -· Channel  Name -· Category -· Bit  rate -· Station  Logo -· Artist  Experience -The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. -The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal -strength. -AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. -Page  127  of  159 -![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be -possible  to  adjust  by  software. -· Range:  15  –  40  dBµV -· Step:  1  dBµV -· Default:  20  dBµV -· -Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity -level.  TBD,  Supplier  to  suggest  solution. -AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be -possible  to  adjust  by  software. -· Range:  20  –  40  dBµV -· Step:  1  dBµV -· Default:  34  dBµV -· -It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. -different  for  night  and  day). -The  system  shall  be  able  to  switch  between  AM  and  FM  bands. -HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the -SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance -with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -Information  Service  Transport". -HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the -SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and -present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance -with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station -Information  Service  Transport". -HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. -Page  128  of  159 -![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. -· Song -· Artist -· Album -· Genre -· Comments -· Commercial -· Reference  Identifier -The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification -"HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" -FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the -system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, -Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency -range  from  87,5  MHz  to  108,0  MHz". -FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled -the  system  shall  indicate  this. -FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. -FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. -FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. -FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. -FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. -FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received -through  RDS. -Page  129  of  159 -![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. -FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. -FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. -FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. -FM/HD  system  shall  be  able  to  enable/disable  regionalisation. -FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. -FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) -reception. -FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. -FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. -FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. -HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. -HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. -AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. -AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. -*HD system shall extract the album name, artist name, track number from the audio stream a*nd -Page  130  of  159 -![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -present  to  the  system. -The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The -feature  will  be  able  to  store  at  least  50  tags. -*5.2.10.1.1.1  Configuration* -AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration -file. -AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. -AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local -configuration  file. -5.2.10.1.2  Database  Requirements -AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains -the  following  attributes: -· Frequency -· PTY  (FM  &  HD  only) -· Channel  name  (FM  &  HD  only) -· Channel  icon  (HD  Only) -· Category  (FM  &  HD  only) -AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following -conditions: -· New  channel  is  found -· Existing  channel  disappears -· -Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list -database. -Page  131  of  159 -![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present -to  the  system. -AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the -frequency,  and  present  to  the  system. -FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, -and  present  to  the  system. -AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following -information: -· Station  name  (FM  and  HD  only) -· Frequency -· Status  of  HD  (HD,  HD1,  HD2) -· HD  SIS  (HD  only) -AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: -· Favourite  station  changed -· Favourite  station  is  removed -· New  favourite  is  added -**5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** -Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from -applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and -LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of -VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main -functions. -· Vehicle  Data  Processing -· Communication  between  ECUs -· Vehicle  Data  Upload -Page  132  of  159 -![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Simulator -**Figure  7-27  :  Overview  of  Vehicle  Info  Control** -**5.2.11.1  Vehicle  Data  Processing** -Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, -personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application -and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. -· -Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature -· User  Information,  such  as  a  name,  taste,  etc.  of  a  driver -· The  operation  history  of  a  driver -Page  133  of  159 -![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle -conditions,  such  as  speed  and  day  and  night -Vehicles  data  processing  consists  of  the  following  functional  elements  further. -(1)  Abstraction  of  Vehicles  Data -In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind -of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving -speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for -application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles -data  of  the  same  implications  and  the  same  unit. -(2)  Maintenance  of  Vehicles  Data -Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past -value  (history). -(3)  Application  /  Middleware  Interface  (API) -The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. -Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and -the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data -restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance -(access  control). -(4)  Vehicles  Interface -It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN -and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the -exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. -However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more -Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In -addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. -**5.2.11.2  Communications  between  ECUs** -Page  134  of  159 -![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -which  each  ECU  can  access. -**5.2.11.3  Vehicle  Data  Upload** -When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than -ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, -vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or -middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is -acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data -which  each  ECU  can  access. -**5.2.11.4  Simulator** -In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is -unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes -development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel -controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be -an  option. -**5.2.11.5  Requirements** -The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application -and/or  middleware  can  access  vehicle  information. -The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract -property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but -the  speed  of  a  car. -System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. -Page  135  of  159 -![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  support  typical  vehicle  property  as  “standard  property”. -As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. -System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. -A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard -property. -Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) -The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or -middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough -as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile -display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. -A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is -stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the -load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and -spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. -It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In -corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. -· -The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the -accumulated  newest  value  is  less  than  a  threshold  value. -· -Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the -newest  accumulation. -About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need -to  be  able  to  set  up  easily. -In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. -System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property -access. -System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or -middleware. -Page  136  of  159 -![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Below  attributes  must  include  in  this  interface -· Zone(optional) -· Property  name -· Value -· -Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application -and/or  middleware. -Below  attributes  must  include  in  this  interface. -· Zone(optional) -· Property  name -· Value -System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from -application  and/or  middleware. -When  status  changed,  system  must  invoke  callback  function  with  below  attributes. -· Zone(optional) -· Property  name -· Value -· Timestamp -· Sequence  number -Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. -Sequence  number  is  useful  to  check  event  order. -The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of -change  of  vehicle  information. -In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an -acceptable  value  even  if  vehicle  information  changes. -For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the -application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of -change. -Page  137  of  159 -![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. -· -The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the -value  from  the  last  notice  of  change  is  less  than  specification. -· -Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a -definite  period  of  time,  it  does  not  notify. -Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the -time  of  change. -What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified -notice  interval  is  made  possible. -The  data  stored  is  acquired  collectively. -Below  attributes  must  include  in  this  interface. -· Zone(optional) -· Property  name -· Values -· Timestamps -It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 -seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. -There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual -in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed -simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the -newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to -recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information -relevant  to  mutual  and  to  access  it. -Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle -information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, -and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all -those  vehicle  information  at  the  time  of  reference. -The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. -Or  the  thing  which  can  be  changed  from  a  program  during  operation. -Page  138  of  159 -![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property -"velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be -accessed  from  all  applications. -System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same -property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only -application  C  can  set  this  property. -Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control -policy  may  be  different  per  car  type,  grade  and  destination. -System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU -and  across  two  or  more  ECU’s. -If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, -middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, -the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware -which  exist  in  a  different  ECU. -VIC  can  be  requested  to  set  the  value  specified  as  Property. -It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. -The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand -from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. -Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application -responds. -It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed -easily. -The  data  exchange  between  ECUs  should  be  permitted  by  VIC. -All  data  transmission  and  reception  from  other  Software  Component  are  refusing. -Page  139  of  159 -![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. -The  vehicle  information  to  upload  is  being  able  to  choose. -A  selection  condition  is  that  the  following  specification  is  possible  at  least. -· Date-and-time  range -· Object  vehicles  data -· The  change  threshold  value  of  vehicles  data -Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be -able  to  change  dynamically  from  an  external. -The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as -substitution  of  actual  vehicles  in  development  environment  is  prepared. -Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing -activities  through  a  vehicles  interface  function  at  least. -· Speed -· Shift  position -· The  direction  of  vehicles -· Latitude  and  longitude  of  a  current  position -· Turn  signal -The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, -it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. -VIC  should  fill  the  following  performance  specifications  and  performance. -It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -information  machines  and  equipment  in  2016. -Page  140  of  159 -![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· Maximum  number  of  properties  :  4,096 -· Maximum  number  of  property  sets:  1,024 -· Greatest  data  storage  time :  12  hours -It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle -information  machines  and  equipment  in  2016. -· Get/Set  method(one  property)  -  0.2ms -· Get/Set  method(property  set  include  30  properties)  -1.3ms -· Subscribe  callback  -  2.5ms  (after  change  of  a  value) -· -GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms -· -GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms -VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility -about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and -attribute  of  vehicles  data. -Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by -various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add -and  change  Vehicle  Interface  without  reconstruction  of  VIC. -Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is -necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. -However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness -vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more -concreteness  vehicles  data  into  one  abstract  vehicles  data. -Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be -mounted  in  the  VIC  itself. -In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be -added  without  reconstruction  of  VIC  is  prepared  for  VIC. -**5.2.12  Telematics  Services** -V2V,  V2I,  RVI,  Traffic  information,  etc. -Page  141  of  159 -![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -**5.2.13  Window  System** -A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user -interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing -Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software -component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, -and  a  routing  of  user  interactions. -AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple -processes  to  be  rendered  on  a  display. -AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to -achieve  flicker  less  rendering. -AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- -screen  buffers. -AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying -objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. -AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos -group  available  to  clients  for  their  rendering. -AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public -APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. -AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by -configuration. -AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the -*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a -Page  142  of  159 -![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The -window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES -2.0  API  are  responsible  for  a  hardware  abstraction. -AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. -AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple -displays. -AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, -where  available. -AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware -acceleration  capabilities. -AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs -from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a -vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the -vehicle  reaches  to  the  certain  speed. -AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, -a  touch  panel,  a  control  knob  etc. -AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input -from  available  physical  input  devices. -**6   Security   Services** -Security  framework -6.1  Access  Control -Access  Control  describes  requirements  for  AGL  Access  Control. -Page  143  of  159 -![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. -**6.1.1  Requirements** -AGL  system  must  support  a  system-wide  access  control  mechanism. -**7   Operating   System   Layer** -7.1  Kernel -**7.1.1  Linux  Kernel** -Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new -release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years -for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and -kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the -rest  of  the  open  source  community  provides, -**7.1.1.1  Requirements** -AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. -At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive -industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully -aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by -Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to -accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to -regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with -the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. -AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on -particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. -Page  144  of  159 -![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -7.2  Boot  Loader -7.3  Hypervisor -TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level -virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI -systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android -and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on -top  type1  hypervisor. -**7.3.1  Requirements** -AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that -have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The -processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. -AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following -functionality  shall  be  supported  by  AGL  Linux  “guest”: -· IPC  (with  hypervisor  and  other  “guests”) -· -“paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless -virtualization  abstraction  is  supported  by  hardware) -7.4  Operating  System -**7.4.1  File  Systems** -File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability -as  their  main  characteristics. -· -*Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, -tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process -environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management -techniques. -Page  145  of  159 - - ------------------------------------------------------------------------------- - > **FS  Requirements** > **R-FS  References** - ------------------------------------------------------ ------------------------ - > 6.  File  Systems  (P1) > 2.  btrfs - > > - > 6.1.  Robust  File  System  for  managed  internal > 2.1. - > > - > storage  (P1) > btr - > > - > 6.1.1.  Power  failure  tolerance  (P1) > fsc - > > - > 6.1.2.  Quick  recovery  after  power  loss > k - > > - > (P1) > 3.  ext2 - > > - > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. - > > - > 6.1.4.  On-demand  integrity  checker  (P1) > e2 - > > - > 6.1.5.  Read-only  mode  (P1) > def - > > - > 6.1.6.  Non-blocking  unmounting  (P1) > rag - > > - > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 - > > - > performance  if  it  may  degrade  under > 5.  ext4 - > > - > certain  conditions.  (P2) > 5.1. - > > - > 6.1.8.  File  space  pre-allocation  (P2) > e4 - > > - > 6.1.9.  Meta-data  error  detection  (P2) > def - > > - > 6.1.10.  File  data  error  detection  (P2) > rag - > > - > 6.1.11.  Online  integrity  checking  (P2) > 5.2. - > > - > 6.1.12.  Write  timeout  control  (P2) > e2f - > > - > 6.1.13.  Compression  support  (P2) > sck - > > - > 6.1.14.  Quota  support  (P2) > 6.  vfat - > > - > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS - > > - > 6.1.16.  File  system  event  notifications > 8.  Generic - > - > tools  and - > - > APIs - > - > 8.1. - > - > fan - ------------------------------------------------------------------------------- - -![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -· -*Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing -designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. -· -*Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual -packages,  and  availability  of  file  system  checking  and  optimization  tools. -![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 -(P2) -6.1.17.  Logical  block  size  control  (P2) -6.1.18.  Snapshots  (P2) -6.2.  File  System  for  non-managed  internal -storage  (P1) - -May  28,  2015 - -otif - -y - -8.2. - -fst - -rim - -6.2.1.  All  P1  requirements  from -FS.1.1.x  list  (P1) -6.2.2.  Wear  leveling  (P1) -6.2.3.  Error  detection/correction  (P1) -6.2.4.  Tolerance  to  flipping  bits  (P1) -6.2.5.  Read/write  disturb  awareness -(P1) -6.2.6.  Bad  block  management  (P1) -6.2.7.  As  many  P2  requirements  from -FS.1.1.x  list  as  possible  (P2) -6.2.8.  Wear  leveling  statistics  (P2) -6.3.  File  Systems  for  removable  storage  (P1) -6.3.1.  Restricted  functionality  from -security  point  of  view  (P1) -6.3.2.  Automount/autounmount  (P1) -6.3.3.  Automatic  synchronous  flushing -of  modified  data  to  physical  media  (P2) -**7.4.1.1  Requirements** -AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -memory),  removable  managed  (USB  stick,  SD  card). -AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, -Page  147  of  159 -![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, -AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. -A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, -and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. -A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power -interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should -not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. -Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- -write)  operation. -A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple -threads  and/or  processes  simultaneously. -A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. -A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical -storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” -command. -AGL  must  support  “lazy”  (delayed)  unmounting. -AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged -file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. -Another  example  is  periodic  fstrim  execution  on  SSD  storage. -A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This -may  be  used  to  minimize  fragmentation  of  frequently  written  files. -A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. -Page  148  of  159 -![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored -data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. -A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. -A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical -media. -A  file  system  should  support  automatic  data  compression. -It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. -AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. -AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. -Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O -performance,  and  decrease  file  fragmentation  impact. -A  file  system  should  allow  creation  of  snapshots. -A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of -erase/program  cycles  is  evenly  distributed  across  all  device  blocks. -A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. -A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also -actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power -interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the -time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. -A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb -Page  149  of  159 -![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known -techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a -fresh  block  after  detected  error  correction. -A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system -users. -Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. -A  file  system  must  support  noexec,  and  nodev  mount  options. -A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and -automatically  unmount  it  when  unplugged. -A  file  system  must  support  sync  mount  option. -AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: -internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH -memory),  removable  managed  (USB  stick,  SD  card). -**7.4.2  Resource  Control** -In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be -higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource -allocation  for  each  process  and/or  process  group. -(cgroups) -**7.4.2.1  Use  Case  and  Role** -If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current -position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. -On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned -Page  150  of  159 - - ------------------------------------------------------------------------------------------- - > **No.** > **Role** > **Description** - ----------- -------------- ---------------------------------------------------------------- - > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority - > - > process  and/or  process  group  should  be  assigned - > - > more  resource. - - > 2 > Time  slot > To  share  resource  per  time  slot. - - > 3 > Release > Forced  release  of  partially  or  whole  allocated - > - > resource. - - > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate - > - > resource  per  defined  process  group. - ------------------------------------------------------------------------------------------- - -![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -to  higher  priority  than  others. -Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at -the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. -Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. -AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network -bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. -**Table  9-34  :  Functions  of  System  Resource  Management** -**7.4.2.2  Requirements** -7.4.2.2.1  Priority -System  provides  a  mechanism  to  set  resource  priority  per  each  process. -Page  151  of  159 -![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. -This  interface  must  be  called  from  other  process. -CPU  resource  must  support  “priority”  based  resource  management. -Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the -status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. -Resource  Manager  should  log  the  status  of  resources  using  by  system. -Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of -kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high -priority  tasks. -7.4.2.2.2  Time  Slot -When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a -mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each -processes. -System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. -System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage -bandwidth  and  network  bandwidth. -Scheduler  should  detect  the  status  of  resources  for  each  thread. -Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. -Scheduler  should  guarantee  that  threads  can  run  periodically. -Scheduler  should  control  the  dispatches  that  occur  extremely. -Page  152  of  159 -![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -7.4.2.2.3  Release -System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by -specific  process. -System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. -7.4.2.2.4  Grouping -System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource -management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same -attributes  to  grouped  processes  altogether. -System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. -System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and -network  bandwidth. -**7.4.3  Startup/Shutdown  Control** -Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a -user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending -on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which -boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and -“dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. -**7.4.3.1  Use  Cases** -(1)  Static  Modification  of  Boot/Shutdown  Order -a. -Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration -To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown -for  all  programs  running  on  the  target  device. -Page  153  of  159 -![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -b. -Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development -In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed -program  in  target  programs. -c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update -Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. -(2)  Dynamic  Modification  of  Boot/Shutdown  Order -a. -Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using -It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to -be  operated  by  priority  when  ACC  turns  ON. -b\. Prioritized  Boot  of  Update  Functionalities -Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned -ON. -**7.4.3.2  Requirements** -Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. -Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that -has  been  configured. -Boot/Shutdown  Control  shall  start  independent  components  in  parallel. -Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. -Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that -has  been  configured. -Page  154  of  159 -![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. -**7.4.4  Database** -Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee -database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system -database  engine  is  rich  set  of  bindings  to  various  programming  languages. -Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References -hierarchy. -1.  Power  failure  tolerance  (P1) -2.  Quick  recovery  after  power  loss  (P1) -3.  Multi-threaded  I/O  (P1) -4.  API  bindings  for  C  programming  language -5.  On-demand  integrity  checker  (P2) -DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write -DB  transactions. -DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. -Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power -failure  on  idle  system. -DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or -processes  simultaneously. -DB  engine  API  must  be  available  for  C-based  applications. -DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. -DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power -interruption  during  adding  some  data. -Page  155  of  159 -![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, -such  as  vehicle  information  database  and  databases  at  data  center. -And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. -Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption -during  merging. -**7.4.5  System  Update** -Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are -numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, -bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to -power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. -System  Update  module  should  have  a  Robust  version  up  function. -System  Update  moduleshould  have  a  system  difference  version  up  function. -There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -apt  of  Linux  distribution). -There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or -apt  of  Linux  distribution). -Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. -If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should -be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. -If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during -update)  should  be  detected  and  the  system  should  restart. -Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. -Page  156  of  159 -![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -Memory  usage  for  difference  update  should  be  maximum  1Mbyte. -Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. -System  Update  moduleshould  have  full  version  up  function  for  whole  system. -Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow -mass  update. -There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. -If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and -application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. -7.5  Device  Drivers -Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. -**7.5.1  Peripherals** -Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. -The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and -data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For -optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less -than  50  s/byte  average. -The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles -and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or -EEPROM  is  not  allowed. -Page  157  of  159 -![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be -fast.  (target  <1ms/byte) -N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. -**7.5.2  Graphics  Drivers** -Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. -This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. -**7.5.3  Video  Drivers** -Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video -codecs  will  nearly  always  be  hardware  based. -**7.5.3.1  Requirements** -The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video -functionality. -**7.5.4  Audio  Codecs** -**7.5.4.1  Requirements** -Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are -implemented  in  hardware. -Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs -that  are  required  for  AGL-based  products  and  not  supported  in  hardware. -**7.5.5  Automotive  Devices** -Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or -*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* -Page  158  of  159 -![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 -May  28,  2015 -required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for -navigation  or  an  air  bag  sensor  for  a  telematics  system. -**8   Notices** -Linux  is  a  registered  trademark  of  Linus  Torvalds. -The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. -Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. -Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. -MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. -AirPlay  is  a  trademark  of  Apple,  Inc. -Page  159  of  159 diff --git a/agl-specs-v1.0/04-app-fw.md b/agl-specs-v1.0/04-app-fw.md deleted file mode 100644 index c88cb04..0000000 --- a/agl-specs-v1.0/04-app-fw.md +++ /dev/null @@ -1,1499 +0,0 @@ ---- - -title : Application Framwork -author: imported from Doors-ng by Fulup(iot.bzh) -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -## Application   Framework   Layer -The  Application  Framework  layer  provides  the  methods  needed  to  create  software  applications -and  their  user  interfaces.  The  platform  can  support  multiple  application  frameworks  any  of -which  may  be  built  into  an  SDK  or  product  build.  The  application  framework  contains  any  code -specifically  written  for  that  framework  as  well  the  bindings  to  the  Services  and  Operating -Systems  layers  that  the  application  framework  provides  for  its  applications. -4.1  AGL  Application  Framework -The  AGL  Application  Framework  provides  basic  services  to  all  applications  regardless  of  the -framework  they  are  implemented  in  so  that  there  is  a  standard  method  providing  the  services. -Page  20  of  159 - -Automotive Grade Linux Requirements Spec v1.0 ![](../media/picture114.jpeg) -{: class="image"} - -May  28,  2015 - -### Application  Manager -Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application -lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. - -### 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. - -### 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 - -#### Use Case -Please  refer  “screen  resource  control”  of  Policy  Manger  section. - -#### 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 -#### 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. diff --git a/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css b/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css deleted file mode 100755 index 65ae26b..0000000 --- a/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css +++ /dev/null @@ -1,37230 +0,0 @@ - - -.table_class1DeffCell -{ -border-bottom-color: #FFFFFF; -border-top-color: #FFFFFF; -border-right-color: #FFFFFF; -border-left-color: #FFFFFF; -border-top-style: solid; -border-left-style: solid; -border-right-style: solid; -border-bottom-style: solid; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -border-bottom-width: 1px; -} -.table_class77DeffCell -{ -border-bottom-color: #000000; -border-top-color: #000000; -border-right-color: #000000; -border-left-color: #000000; -border-top-style: solid; -border-left-style: solid; -border-right-style: solid; -border-bottom-style: solid; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -border-bottom-width: 1px; -} -.table_class266DeffCell -{ -border-bottom-color: #000000; -border-top-color: #000000; -border-right-color: #000000; -border-left-color: #000000; -border-top-style: solid; -border-left-style: solid; -border-right-style: solid; -border-bottom-style: solid; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -border-bottom-width: 1px; -} - -.Body -{ -font-weight: normal; -color: #000000; -font-family: Trebuchet MS; -font-size: 11px; -} - -.Prefix -{ -color: #000000; -font-family: Trebuchet MS; -font-size: 9px; -} - -.LabelItalic -{ -font-style: italic; -text-decoration: underline; -} - -.LabelStrong -{ -font-weight: bold; -text-decoration: underline; -} - -.HeaderCell -{ -border-bottom-color: #999999; -border-left-color: #FFFFFF; -border-right-color: #FFFFFF; -border-top-color: #FFFFFF; -border-left-style: none; -border-right-style: none; -border-top-style: none; -color: #666666; -font-family: Arial; -font-size: 9px; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -} - -.BodyCell -{ -border-bottom-color: #e5e5e5; -border-left-color: #FFFFFF; -border-right-color: #FFFFFF; -border-top-color: #FFFFFF; -border-left-style: none; -border-right-style: none; -border-top-style: none; -color: #222222; -font-family: Arial; -font-size: 9px; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -} - -.SubTotalCell -{ -border-bottom-color: #e5e5e5; -border-left-color: #FFFFFF; -border-right-color: #FFFFFF; -border-top-color: #FFFFFF; -border-left-style: none; -border-right-style: none; -border-top-style: none; -font-weight: bold; -color: #666666; -font-family: Arial; -font-size: 9px; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -} - -.TotalCell -{ -border-bottom-color: #e5e5e5; -border-left-color: #FFFFFF; -border-right-color: #FFFFFF; -border-top-color: #FFFFFF; -border-left-style: none; -border-right-style: none; -border-top-style: none; -font-weight: bold; -color: #222222; -font-family: Arial; -font-size: 9px; -border-top-width: 1px; -border-left-width: 1px; -border-right-width: 1px; -} - -.Hyperlink -{ -color: #3087B3; -} - -.Normal -{ -color: #222222; -font-family: Arial; -font-size: 10px; -} - -.Header -{ -color: #222222; -font-family: Arial; -font-size: 10px; -} - -.Title -{ -text-align: right; -font-weight: bold; -font-size: 18px; -} - -.SubTitle -{ -text-align: right; -color: #222222; -font-family: Arial; -font-size: 16px; -} - -.TableOfContents -{ -color: #222222; -font-family: Arial; -font-size: 14px; -color: #008A52; -font-family: Arial; -font-size: 18px; -} - -.InternalHyperlink -{ -color: #3087B3; -color: #3087B3; -} - -.Figure -{ -color: #222222; -font-family: Arial; -font-size: 9px; -text-align: center; -color: #222222; -font-family: Arial; -font-size: 11px; -} - -.Footer -{ -color: #222222; -font-family: Arial; -font-size: 10px; -color: #222222; -font-family: Arial; -font-size: 10px; -color: #222222; -font-family: Arial; -font-size: 10px; -} - -.LogoImage -{ -align: right; -} - -.table_of_contents2c9377fb-ce44-48bb-ab81-2b2ad4709e9f -{ -} - -.table_class1 -{ -border-collapse: collapse; -width: 100%; -} - -.row_class2 -{ -} - -.cell_class3 -{ -text-align: left; -vertical-align: center; -width: 250px; -} - -.text_class5 -{ -} - -.cell_class6 -{ -text-align: right; -vertical-align: center; -width: 250px; -} - -.text_class8 -{ -} - -.cell_class4 -{ -width: 250px; -} - -.cell_class7 -{ -width: 250px; -} - -.cell_class9 -{ -text-align: left; -vertical-align: center; -width: 150px; -} - -.cell_class11 -{ -text-align: center; -vertical-align: center; -width: 150px; -} - -.text_class13 -{ -} - -.text_class14 -{ -} - -.text_class15 -{ -} - -.text_class16 -{ -} - -.text_class17 -{ -} - -.cell_class18 -{ -text-align: right; -vertical-align: center; -width: 150px; -} - -.text_class20 -{ -} - -.cell_class10 -{ -width: 150px; -} - -.cell_class12 -{ -width: 150px; -} - -.cell_class19 -{ -width: 150px; -} - -.paragraph_class21 -{ -} - -.text_class22 -{ -} - -.paragraph_class23 -{ -} - -.text_class24 -{ -} - -.text_class25 -{ -} - -.text_class26 -{ -} - -.text_class27 -{ -} - -.text_class28 -{ -} - -.text_class29 -{ -} - -.text_class30 -{ -} - -.text_class31 -{ -} - -.text_class32 -{ -} - -.text_class33 -{ -} - -.paragraph_class34 -{ -} - -.text_class35 -{ -} - -.text_class36 -{ -} - -.paragraph_class37 -{ -} - -.text_class38 -{ -} - -.paragraph_class39 -{ -} - -.text_class40 -{ -font-size: 11px; -} - -.text_class41 -{ -} - -.hyperlink_class42 -{ -} - -.hyperlink_class43 -{ -} - -.paragraph_class44 -{ -} - -.paragraph_class45 -{ -} - -.text_class46 -{ -font-size: 11px; -} - -.hyperlink_class47 -{ -} - -.list_class48 -{ -list-style-type: disc; -} - -.list_detail_class49 -{ -} - -.text_class50 -{ -font-size: 11px; -} - -.text_class51 -{ -font-size: 11px; -} - -.paragraph_class52 -{ -} - -.paragraph_class53 -{ -} - -.text_class54 -{ -font-size: 11px; -} - -.text_class55 -{ -font-size: 11px; -} - -.text_class56 -{ -font-size: 11px; -} - -.text_class57 -{ -font-size: 11px; -} - -.text_class58 -{ -font-size: 11px; -} - -.paragraph_class59 -{ -} - -.text_class60 -{ -font-size: 11px; -} - -.text_class61 -{ -} - -.text_class62 -{ -} - -.paragraph_class63 -{ -} - -.text_class64 -{ -font-size: 11px; -} - -.text_class65 -{ -font-size: 11px; -} - -.text_class66 -{ -font-size: 11px; -} - -.paragraph_class67 -{ -} - -.paragraph_class68 -{ -} - -.text_class69 -{ -font-size: 11px; -} - -.paragraph_class70 -{ -} - -.paragraph_class71 -{ -} - -.text_class72 -{ -font-size: 11px; -} - -.text_class73 -{ -font-size: 11px; -} - -.text_class74 -{ -} - -.text_class75 -{ -} - -.paragraph_class76 -{ -} - -.table_class77 -{ -border-collapse: collapse; -} - -.row_class78 -{ -} - -.cell_class79 -{ -width: 115px; -background-color: #999999; -} - -.text_class81 -{ -} - -.text_class82 -{ -font-size: 11px; -} - -.text_class83 -{ -font-weight: bold; -} - -.cell_class84 -{ -width: 448px; -background-color: #999999; -} - -.text_class86 -{ -font-size: 11px; -} - -.text_class87 -{ -font-weight: bold; -} - -.cell_class88 -{ -width: 115px; -} - -.paragraph_class89 -{ -} - -.text_class90 -{ -font-size: 11px; -} - -.cell_class91 -{ -width: 448px; -} - -.paragraph_class92 -{ -} - -.text_class93 -{ -font-size: 11px; -} - -.paragraph_class94 -{ -} - -.text_class95 -{ -font-size: 11px; -} - -.paragraph_class96 -{ -} - -.text_class97 -{ -font-size: 11px; -} - -.paragraph_class98 -{ -} - -.text_class99 -{ -font-size: 11px; -} - -.paragraph_class100 -{ -} - -.text_class101 -{ -font-size: 11px; -} - -.paragraph_class102 -{ -} - -.text_class103 -{ -font-size: 11px; -} - -.paragraph_class104 -{ -} - -.text_class105 -{ -font-size: 11px; -} - -.paragraph_class106 -{ -} - -.text_class107 -{ -font-size: 11px; -} - -.paragraph_class108 -{ -} - -.text_class109 -{ -font-size: 11px; -} - -.paragraph_class110 -{ -} - -.text_class111 -{ -font-size: 11px; -} - -.paragraph_class112 -{ -} - -.text_class113 -{ -font-size: 11px; -} - -.paragraph_class114 -{ -} - -.text_class115 -{ -font-size: 11px; -} - -.paragraph_class116 -{ -} - -.text_class117 -{ -font-size: 11px; -} - -.paragraph_class118 -{ -} - -.text_class119 -{ -font-size: 11px; -} - -.paragraph_class120 -{ -} - -.text_class121 -{ -font-size: 11px; -} - -.paragraph_class122 -{ -} - -.text_class123 -{ -font-size: 11px; -} - -.paragraph_class124 -{ -} - -.text_class125 -{ -font-size: 11px; -} - -.paragraph_class126 -{ -} - -.text_class127 -{ -font-size: 11px; -} - -.paragraph_class128 -{ -} - -.text_class129 -{ -font-size: 11px; -} - -.paragraph_class130 -{ -} - -.text_class131 -{ -font-size: 11px; -} - -.paragraph_class132 -{ -} - -.text_class133 -{ -font-size: 11px; -} - -.paragraph_class134 -{ -} - -.text_class135 -{ -font-size: 11px; -} - -.paragraph_class136 -{ -} - -.text_class137 -{ -font-size: 11px; -} - -.paragraph_class138 -{ -} - -.text_class139 -{ -font-size: 11px; -} - -.paragraph_class140 -{ -} - -.text_class141 -{ -font-size: 11px; -} - -.paragraph_class142 -{ -} - -.text_class143 -{ -font-size: 11px; -} - -.paragraph_class144 -{ -} - -.text_class145 -{ -font-size: 11px; -} - -.paragraph_class146 -{ -} - -.text_class147 -{ -font-size: 11px; -} - -.paragraph_class148 -{ -} - -.text_class149 -{ -font-size: 11px; -} - -.paragraph_class150 -{ -} - -.text_class151 -{ -font-size: 11px; -} - -.paragraph_class152 -{ -} - -.text_class153 -{ -font-size: 11px; -} - -.text_class154 -{ -} - -.text_class155 -{ -} - -.paragraph_class156 -{ -} - -.text_class157 -{ -font-size: 11px; -} - -.paragraph_class158 -{ -} - -.text_class159 -{ -font-size: 11px; -} - -.paragraph_class160 -{ -} - -.text_class161 -{ -} - -.image_class162 -{ -} - -.text_class163 -{ -} - -.text_class164 -{ -} - -.paragraph_class165 -{ -} - -.text_class166 -{ -font-size: 11px; -} - -.text_class167 -{ -} - -.text_class168 -{ -} - -.paragraph_class169 -{ -} - -.text_class170 -{ -font-size: 11px; -} - -.text_class171 -{ -font-size: 11px; -} - -.text_class172 -{ -font-size: 11px; -} - -.text_class173 -{ -font-size: 11px; -} - -.paragraph_class174 -{ -} - -.paragraph_class175 -{ -} - -.text_class176 -{ -font-size: 11px; -} - -.text_class177 -{ -} - -.paragraph_class178 -{ -} - -.text_class179 -{ -} - -.paragraph_class180 -{ -} - -.text_class181 -{ -font-size: 11px; -} - -.text_class182 -{ -font-size: 11px; -} - -.paragraph_class183 -{ -} - -.paragraph_class184 -{ -} - -.paragraph_class185 -{ -} - -.text_class186 -{ -} - -.text_class187 -{ -} - -.paragraph_class188 -{ -} - -.text_class189 -{ -font-size: 11px; -} - -.text_class190 -{ -font-size: 11px; -} - -.text_class191 -{ -font-size: 11px; -} - -.text_class192 -{ -font-size: 11px; -} - -.text_class193 -{ -} - -.text_class194 -{ -} - -.paragraph_class195 -{ -} - -.text_class196 -{ -font-size: 11px; -} - -.text_class197 -{ -font-size: 11px; -} - -.text_class198 -{ -font-size: 11px; -} - -.text_class199 -{ -font-size: 11px; -} - -.text_class200 -{ -font-size: 11px; -} - -.text_class201 -{ -} - -.text_class202 -{ -} - -.paragraph_class203 -{ -} - -.text_class204 -{ -font-size: 11px; -} - -.text_class205 -{ -font-size: 11px; -} - -.text_class206 -{ -font-size: 11px; -} - -.text_class207 -{ -} - -.text_class208 -{ -} - -.paragraph_class209 -{ -} - -.text_class210 -{ -font-size: 11px; -} - -.text_class211 -{ -font-size: 11px; -} - -.text_class212 -{ -font-size: 11px; -} - -.text_class213 -{ -font-size: 11px; -} - -.paragraph_class214 -{ -} - -.paragraph_class215 -{ -} - -.text_class216 -{ -font-size: 11px; -} - -.paragraph_class217 -{ -} - -.text_class218 -{ -font-size: 11px; -} - -.paragraph_class219 -{ -} - -.text_class220 -{ -font-size: 11px; -} - -.paragraph_class221 -{ -} - -.text_class222 -{ -font-size: 11px; -} - -.paragraph_class223 -{ -} - -.text_class224 -{ -font-size: 11px; -} - -.paragraph_class225 -{ -} - -.text_class226 -{ -font-size: 11px; -} - -.paragraph_class227 -{ -} - -.text_class228 -{ -font-size: 11px; -} - -.paragraph_class229 -{ -} - -.text_class230 -{ -font-size: 11px; -} - -.paragraph_class231 -{ -} - -.text_class232 -{ -font-size: 11px; -} - -.paragraph_class233 -{ -} - -.text_class234 -{ -font-size: 11px; -} - -.paragraph_class235 -{ -} - -.paragraph_class236 -{ -} - -.text_class237 -{ -font-size: 11px; -} - -.text_class238 -{ -} - -.text_class239 -{ -} - -.text_class240 -{ -} - -.paragraph_class241 -{ -} - -.text_class242 -{ -font-size: 11px; -} - -.text_class243 -{ -font-size: 11px; -} - -.text_class244 -{ -font-size: 11px; -} - -.text_class245 -{ -font-size: 11px; -} - -.text_class246 -{ -font-size: 11px; -} - -.paragraph_class247 -{ -} - -.paragraph_class248 -{ -} - -.text_class249 -{ -font-size: 11px; -} - -.text_class250 -{ -font-size: 11px; -} - -.paragraph_class251 -{ -} - -.text_class252 -{ -font-size: 11px; -} - -.text_class253 -{ -font-size: 11px; -} - -.text_class254 -{ -font-size: 11px; -} - -.text_class255 -{ -font-size: 11px; -} - -.text_class256 -{ -font-size: 11px; -} - -.paragraph_class257 -{ -} - -.paragraph_class258 -{ -} - -.text_class259 -{ -font-size: 11px; -} - -.text_class260 -{ -} - -.text_class261 -{ -} - -.text_class262 -{ -} - -.paragraph_class263 -{ -} - -.text_class264 -{ -font-size: 11px; -} - -.text_class265 -{ -} - -.table_class266 -{ -border-collapse: collapse; -} - -.cell_class267 -{ -text-align: center; -vertical-align: center; -width: 47px; -background-color: #bfbfbf; -} - -.paragraph_class269 -{ -margin-left: 0px; -} - -.text_class270 -{ -font-size: 11px; -font-family: arial; -} - -.text_class271 -{ -font-weight: bold; -} - -.cell_class272 -{ -text-align: center; -vertical-align: center; -width: 154px; -background-color: #bfbfbf; -} - -.paragraph_class274 -{ -margin-left: 0px; -} - -.text_class275 -{ -font-size: 11px; -font-family: arial; -} - -.text_class276 -{ -font-weight: bold; -} - -.cell_class277 -{ -text-align: center; -vertical-align: center; -width: 138px; -background-color: #bfbfbf; -} - -.paragraph_class279 -{ -margin-left: 0px; -} - -.text_class280 -{ -font-size: 11px; -font-family: arial; -} - -.text_class281 -{ -font-weight: bold; -} - -.cell_class282 -{ -text-align: center; -vertical-align: center; -width: 236px; -background-color: #bfbfbf; -} - -.paragraph_class284 -{ -margin-left: 0px; -} - -.text_class285 -{ -font-size: 11px; -font-family: arial; -} - -.text_class286 -{ -font-weight: bold; -} - -.cell_class287 -{ -width: 47px; -} - -.paragraph_class288 -{ -margin-left: 0px; -} - -.text_class289 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class290 -{ -width: 154px; -} - -.paragraph_class291 -{ -margin-left: 0px; -} - -.text_class292 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class293 -{ -margin-left: 0px; -} - -.cell_class294 -{ -width: 138px; -} - -.paragraph_class295 -{ -margin-left: 0px; -} - -.text_class296 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class297 -{ -margin-left: 0px; -} - -.text_class298 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class299 -{ -width: 236px; -} - -.paragraph_class300 -{ -margin-left: 0px; -} - -.text_class301 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class302 -{ -margin-left: 0px; -} - -.text_class303 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class304 -{ -margin-left: 0px; -} - -.text_class305 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class306 -{ -margin-left: 0px; -} - -.text_class307 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class308 -{ -margin-left: 0px; -} - -.text_class309 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class310 -{ -width: 154px; -} - -.paragraph_class311 -{ -margin-left: 0px; -} - -.text_class312 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class313 -{ -margin-left: 0px; -} - -.paragraph_class314 -{ -margin-left: 0px; -} - -.text_class315 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class316 -{ -margin-left: 0px; -} - -.text_class317 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class318 -{ -margin-left: 0px; -} - -.text_class319 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class320 -{ -margin-left: 0px; -} - -.text_class321 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class322 -{ -margin-left: 0px; -} - -.text_class323 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class324 -{ -margin-left: 0px; -} - -.text_class325 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class326 -{ -margin-left: 0px; -} - -.text_class327 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class328 -{ -margin-left: 0px; -} - -.text_class329 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class330 -{ -margin-left: 0px; -} - -.text_class331 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class332 -{ -margin-left: 0px; -} - -.text_class333 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class334 -{ -margin-left: 0px; -} - -.text_class335 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class336 -{ -margin-left: 0px; -} - -.text_class337 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class338 -{ -margin-left: 0px; -} - -.text_class339 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class340 -{ -margin-left: 0px; -} - -.text_class341 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class342 -{ -margin-left: 0px; -} - -.text_class343 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class344 -{ -margin-left: 0px; -} - -.paragraph_class345 -{ -margin-left: 0px; -} - -.text_class346 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class347 -{ -margin-left: 0px; -} - -.text_class348 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class349 -{ -margin-left: 0px; -} - -.text_class350 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class351 -{ -margin-left: 0px; -} - -.text_class352 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class353 -{ -margin-left: 0px; -} - -.text_class354 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class355 -{ -margin-left: 0px; -} - -.text_class356 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class357 -{ -margin-left: 0px; -} - -.text_class358 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class359 -{ -width: 154px; -} - -.paragraph_class360 -{ -margin-left: 0px; -} - -.text_class361 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class362 -{ -margin-left: 0px; -} - -.text_class363 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class364 -{ -margin-left: 0px; -} - -.paragraph_class365 -{ -margin-left: 0px; -} - -.text_class366 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class367 -{ -margin-left: 0px; -} - -.text_class368 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class369 -{ -margin-left: 0px; -} - -.text_class370 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class371 -{ -margin-left: 0px; -} - -.text_class372 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class373 -{ -margin-left: 0px; -} - -.text_class374 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class375 -{ -margin-left: 0px; -} - -.text_class376 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class377 -{ -margin-left: 0px; -} - -.text_class378 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class379 -{ -margin-left: 0px; -} - -.text_class380 -{ -font-size: 11px; -font-family: arial; -} - -.text_class381 -{ -} - -.paragraph_class382 -{ -text-align: center; -margin-left: 0px; -} - -.text_class383 -{ -font-size: 11px; -font-family: arial; -} - -.text_class384 -{ -font-weight: bold; -} - -.text_class385 -{ -} - -.cell_class386 -{ -text-align: center; -vertical-align: center; -width: 46px; -background-color: #bfbfbf; -} - -.paragraph_class388 -{ -margin-left: 0px; -} - -.text_class389 -{ -font-size: 11px; -font-family: arial; -} - -.text_class390 -{ -font-weight: bold; -} - -.cell_class391 -{ -text-align: center; -vertical-align: center; -width: 196px; -background-color: #bfbfbf; -} - -.paragraph_class393 -{ -margin-left: 0px; -} - -.text_class394 -{ -font-size: 11px; -font-family: arial; -} - -.text_class395 -{ -font-weight: bold; -} - -.cell_class396 -{ -text-align: center; -vertical-align: center; -width: 110px; -background-color: #bfbfbf; -} - -.paragraph_class398 -{ -margin-left: 0px; -} - -.text_class399 -{ -font-size: 11px; -font-family: arial; -} - -.text_class400 -{ -font-weight: bold; -} - -.paragraph_class402 -{ -margin-left: 0px; -} - -.text_class403 -{ -font-size: 11px; -font-family: arial; -} - -.text_class404 -{ -font-weight: bold; -} - -.paragraph_class406 -{ -margin-left: 0px; -} - -.text_class407 -{ -font-size: 11px; -font-family: arial; -} - -.text_class408 -{ -font-weight: bold; -} - -.cell_class409 -{ -width: 46px; -} - -.paragraph_class410 -{ -margin-left: 0px; -} - -.text_class411 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class412 -{ -width: 196px; -} - -.paragraph_class413 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class414 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class415 -{ -width: 110px; -} - -.paragraph_class416 -{ -text-align: center; -margin-left: 0px; -} - -.text_class417 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class418 -{ -text-align: center; -margin-left: 0px; -} - -.text_class419 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class420 -{ -text-align: center; -margin-left: 0px; -} - -.text_class421 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class422 -{ -margin-left: 0px; -} - -.text_class423 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class424 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class425 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class426 -{ -text-align: center; -margin-left: 0px; -} - -.text_class427 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class428 -{ -text-align: center; -margin-left: 0px; -} - -.text_class429 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class430 -{ -text-align: center; -margin-left: 0px; -} - -.text_class431 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class432 -{ -margin-left: 0px; -} - -.text_class433 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class434 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class435 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class436 -{ -text-align: center; -margin-left: 0px; -} - -.text_class437 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class438 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class439 -{ -text-align: center; -margin-left: 0px; -} - -.text_class440 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class441 -{ -margin-left: 0px; -} - -.text_class442 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class443 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class444 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class445 -{ -text-align: center; -margin-left: 0px; -} - -.text_class446 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class447 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class448 -{ -text-align: center; -margin-left: 0px; -} - -.text_class449 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class450 -{ -margin-left: 0px; -} - -.text_class451 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class452 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class453 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class454 -{ -text-align: center; -margin-left: 0px; -} - -.text_class455 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class456 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class457 -{ -text-align: center; -margin-left: 0px; -} - -.text_class458 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class459 -{ -margin-left: 0px; -} - -.text_class460 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class461 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class462 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class463 -{ -text-align: center; -margin-left: 0px; -} - -.text_class464 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class465 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class466 -{ -text-align: center; -margin-left: 0px; -} - -.text_class467 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class468 -{ -margin-left: 0px; -} - -.text_class469 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class470 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class471 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class472 -{ -text-align: center; -margin-left: 0px; -} - -.text_class473 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class474 -{ -text-align: center; -margin-left: 0px; -} - -.text_class475 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class476 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class477 -{ -margin-left: 0px; -} - -.text_class478 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class479 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class480 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class481 -{ -text-align: center; -margin-left: 0px; -} - -.text_class482 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class483 -{ -text-align: center; -margin-left: 0px; -} - -.text_class484 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class485 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class486 -{ -margin-left: 0px; -} - -.text_class487 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class488 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class489 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class490 -{ -text-align: center; -margin-left: 0px; -} - -.text_class491 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class492 -{ -text-align: center; -margin-left: 0px; -} - -.text_class493 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class494 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class495 -{ -margin-left: 0px; -} - -.text_class496 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class497 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class498 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class499 -{ -text-align: center; -margin-left: 0px; -} - -.text_class500 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class501 -{ -text-align: center; -margin-left: 0px; -} - -.text_class502 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class503 -{ -text-align: center; -margin-left: 0px; -} - -.paragraph_class504 -{ -margin-left: 0px; -} - -.text_class505 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class506 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class507 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class508 -{ -text-align: center; -margin-left: 0px; -} - -.text_class509 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class510 -{ -text-align: center; -margin-left: 0px; -} - -.text_class511 -{ -font-size: 11px; -font-family: courier new; -} - -.paragraph_class512 -{ -text-align: center; -margin-left: 0px; -} - -.text_class513 -{ -} - -.text_class514 -{ -} - -.paragraph_class515 -{ -} - -.text_class516 -{ -} - -.paragraph_class517 -{ -} - -.text_class518 -{ -font-family: arial; -} - -.text_class519 -{ -font-size: 11px; -} - -.paragraph_class520 -{ -} - -.text_class521 -{ -font-family: arial; -} - -.text_class522 -{ -font-size: 11px; -} - -.paragraph_class523 -{ -} - -.text_class524 -{ -font-family: arial; -} - -.text_class525 -{ -font-size: 11px; -} - -.text_class526 -{ -font-family: arial; -} - -.text_class527 -{ -font-size: 11px; -} - -.text_class528 -{ -font-family: arial; -} - -.text_class529 -{ -font-size: 11px; -} - -.text_class530 -{ -font-family: arial; -} - -.text_class531 -{ -font-size: 11px; -} - -.text_class532 -{ -font-family: arial; -} - -.text_class533 -{ -font-size: 11px; -} - -.text_class534 -{ -font-family: arial; -} - -.text_class535 -{ -font-size: 11px; -} - -.paragraph_class536 -{ -} - -.text_class537 -{ -font-family: arial; -} - -.text_class538 -{ -font-size: 11px; -} - -.text_class539 -{ -font-family: arial; -} - -.text_class540 -{ -font-size: 11px; -} - -.text_class541 -{ -font-family: arial; -} - -.text_class542 -{ -font-size: 11px; -} - -.text_class543 -{ -font-family: arial; -} - -.text_class544 -{ -font-size: 11px; -} - -.text_class545 -{ -font-family: arial; -} - -.text_class546 -{ -font-size: 11px; -} - -.text_class547 -{ -font-family: arial; -} - -.text_class548 -{ -font-size: 11px; -} - -.text_class549 -{ -font-family: arial; -} - -.text_class550 -{ -font-size: 11px; -} - -.text_class551 -{ -font-family: arial; -} - -.text_class552 -{ -font-size: 11px; -} - -.text_class553 -{ -} - -.paragraph_class554 -{ -} - -.text_class555 -{ -font-family: arial; -} - -.text_class556 -{ -font-size: 11px; -} - -.text_class557 -{ -} - -.text_class558 -{ -} - -.paragraph_class559 -{ -} - -.text_class560 -{ -font-family: arial; -} - -.text_class561 -{ -font-size: 11px; -} - -.text_class562 -{ -} - -.paragraph_class563 -{ -margin-left: 0px; -} - -.text_class564 -{ -font-family: arial; -} - -.text_class565 -{ -font-size: 11px; -} - -.text_class566 -{ -font-family: arial; -} - -.text_class567 -{ -font-size: 11px; -} - -.text_class568 -{ -font-family: arial; -} - -.text_class569 -{ -font-size: 11px; -} - -.text_class570 -{ -font-family: arial; -} - -.text_class571 -{ -font-size: 11px; -} - -.text_class572 -{ -font-family: arial; -} - -.text_class573 -{ -font-size: 11px; -} - -.text_class574 -{ -font-family: arial; -} - -.text_class575 -{ -font-size: 11px; -} - -.text_class576 -{ -} - -.paragraph_class577 -{ -} - -.text_class578 -{ -font-family: arial; -} - -.text_class579 -{ -font-size: 11px; -} - -.text_class580 -{ -} - -.paragraph_class581 -{ -} - -.text_class582 -{ -font-family: arial; -} - -.text_class583 -{ -font-size: 11px; -} - -.text_class584 -{ -} - -.paragraph_class585 -{ -margin-left: 0px; -} - -.text_class586 -{ -font-family: arial; -} - -.text_class587 -{ -font-size: 11px; -} - -.paragraph_class588 -{ -} - -.text_class589 -{ -font-family: arial; -} - -.text_class590 -{ -font-size: 11px; -} - -.text_class591 -{ -} - -.paragraph_class592 -{ -} - -.text_class593 -{ -font-family: arial; -} - -.text_class594 -{ -font-size: 11px; -} - -.text_class595 -{ -} - -.paragraph_class596 -{ -} - -.text_class597 -{ -font-family: arial; -} - -.text_class598 -{ -font-size: 11px; -} - -.text_class599 -{ -} - -.paragraph_class600 -{ -} - -.text_class601 -{ -font-family: arial; -} - -.text_class602 -{ -font-size: 11px; -} - -.text_class603 -{ -} - -.paragraph_class604 -{ -} - -.text_class605 -{ -font-family: arial; -} - -.text_class606 -{ -font-size: 11px; -} - -.text_class607 -{ -} - -.paragraph_class608 -{ -} - -.text_class609 -{ -font-family: arial; -} - -.text_class610 -{ -font-size: 11px; -} - -.text_class611 -{ -} - -.paragraph_class612 -{ -} - -.text_class613 -{ -font-family: arial; -} - -.text_class614 -{ -font-size: 11px; -} - -.text_class615 -{ -} - -.paragraph_class616 -{ -} - -.text_class617 -{ -font-family: arial; -} - -.text_class618 -{ -font-size: 11px; -} - -.text_class619 -{ -} - -.paragraph_class620 -{ -} - -.text_class621 -{ -font-family: arial; -} - -.text_class622 -{ -font-size: 11px; -} - -.text_class623 -{ -} - -.text_class624 -{ -font-family: arial; -} - -.text_class625 -{ -font-size: 11px; -} - -.text_class626 -{ -font-family: arial; -} - -.text_class627 -{ -font-size: 11px; -} - -.text_class628 -{ -font-family: arial; -} - -.text_class629 -{ -font-size: 11px; -} - -.text_class630 -{ -} - -.paragraph_class631 -{ -} - -.text_class632 -{ -font-family: arial; -} - -.text_class633 -{ -font-size: 11px; -} - -.text_class634 -{ -} - -.paragraph_class635 -{ -} - -.text_class636 -{ -font-family: arial; -} - -.text_class637 -{ -font-size: 11px; -} - -.text_class638 -{ -font-family: arial; -} - -.text_class639 -{ -font-size: 11px; -} - -.text_class640 -{ -font-family: arial; -} - -.text_class641 -{ -font-size: 11px; -} - -.text_class642 -{ -font-family: arial; -} - -.text_class643 -{ -font-size: 11px; -} - -.text_class644 -{ -font-family: arial; -} - -.text_class645 -{ -font-size: 11px; -} - -.text_class646 -{ -font-family: arial; -} - -.text_class647 -{ -font-size: 11px; -} - -.text_class648 -{ -} - -.paragraph_class649 -{ -} - -.text_class650 -{ -font-family: arial; -} - -.text_class651 -{ -font-size: 11px; -} - -.text_class652 -{ -font-family: arial; -} - -.text_class653 -{ -font-size: 11px; -} - -.text_class654 -{ -font-family: arial; -} - -.text_class655 -{ -font-size: 11px; -} - -.text_class656 -{ -font-family: arial; -} - -.text_class657 -{ -font-size: 11px; -} - -.text_class658 -{ -font-family: arial; -} - -.text_class659 -{ -font-size: 11px; -} - -.text_class660 -{ -} - -.paragraph_class661 -{ -margin-left: 0px; -} - -.text_class662 -{ -font-family: arial; -} - -.text_class663 -{ -font-size: 11px; -} - -.paragraph_class664 -{ -margin-left: 0px; -} - -.text_class665 -{ -font-family: arial; -} - -.text_class666 -{ -font-size: 11px; -} - -.text_class667 -{ -font-family: arial; -} - -.text_class668 -{ -font-size: 11px; -} - -.text_class669 -{ -font-family: arial; -} - -.text_class670 -{ -font-size: 11px; -} - -.text_class671 -{ -font-family: arial; -} - -.text_class672 -{ -font-size: 11px; -} - -.text_class673 -{ -font-family: arial; -} - -.text_class674 -{ -font-size: 11px; -} - -.text_class675 -{ -} - -.paragraph_class676 -{ -} - -.text_class677 -{ -font-family: arial; -} - -.text_class678 -{ -font-size: 11px; -} - -.text_class679 -{ -} - -.paragraph_class680 -{ -} - -.text_class681 -{ -font-family: arial; -} - -.text_class682 -{ -font-size: 11px; -} - -.text_class683 -{ -} - -.paragraph_class684 -{ -} - -.text_class685 -{ -font-family: arial; -} - -.text_class686 -{ -font-size: 11px; -} - -.text_class687 -{ -} - -.paragraph_class688 -{ -} - -.text_class689 -{ -font-family: arial; -} - -.text_class690 -{ -font-size: 11px; -} - -.text_class691 -{ -} - -.text_class692 -{ -} - -.paragraph_class693 -{ -margin-left: 0px; -} - -.text_class694 -{ -font-family: arial; -} - -.text_class695 -{ -font-size: 11px; -} - -.text_class696 -{ -font-family: arial; -} - -.text_class697 -{ -font-size: 11px; -} - -.text_class698 -{ -font-family: arial; -} - -.text_class699 -{ -font-size: 11px; -} - -.text_class700 -{ -font-family: arial; -} - -.text_class701 -{ -font-size: 11px; -} - -.text_class702 -{ -font-family: arial; -} - -.text_class703 -{ -font-size: 11px; -} - -.text_class704 -{ -font-family: arial; -} - -.text_class705 -{ -font-size: 11px; -} - -.text_class706 -{ -font-family: arial; -} - -.text_class707 -{ -font-size: 11px; -} - -.text_class708 -{ -} - -.paragraph_class709 -{ -margin-left: 0px; -} - -.text_class710 -{ -font-family: arial; -} - -.text_class711 -{ -font-size: 11px; -} - -.paragraph_class712 -{ -} - -.text_class713 -{ -font-family: arial; -} - -.text_class714 -{ -font-size: 11px; -} - -.text_class715 -{ -} - -.text_class716 -{ -} - -.paragraph_class717 -{ -margin-left: 0px; -} - -.text_class718 -{ -font-family: arial; -} - -.text_class719 -{ -font-size: 11px; -} - -.paragraph_class720 -{ -margin-left: 0px; -} - -.text_class721 -{ -font-family: arial; -} - -.text_class722 -{ -font-size: 11px; -} - -.text_class723 -{ -font-family: arial; -} - -.text_class724 -{ -font-size: 11px; -} - -.text_class725 -{ -font-family: arial; -} - -.text_class726 -{ -font-size: 11px; -} - -.text_class727 -{ -font-family: arial; -} - -.text_class728 -{ -font-size: 11px; -} - -.text_class729 -{ -font-family: arial; -} - -.text_class730 -{ -font-size: 11px; -} - -.text_class731 -{ -} - -.paragraph_class732 -{ -} - -.text_class733 -{ -font-family: arial; -} - -.text_class734 -{ -font-size: 11px; -} - -.text_class735 -{ -} - -.paragraph_class736 -{ -} - -.text_class737 -{ -font-family: arial; -} - -.text_class738 -{ -font-size: 11px; -} - -.text_class739 -{ -} - -.paragraph_class740 -{ -} - -.text_class741 -{ -font-family: arial; -} - -.text_class742 -{ -font-size: 11px; -} - -.paragraph_class743 -{ -} - -.text_class744 -{ -font-family: arial; -} - -.text_class745 -{ -font-size: 11px; -} - -.text_class746 -{ -} - -.text_class747 -{ -} - -.paragraph_class748 -{ -} - -.text_class749 -{ -font-size: 11px; -} - -.paragraph_class750 -{ -} - -.text_class751 -{ -} - -.text_class752 -{ -} - -.paragraph_class753 -{ -} - -.text_class754 -{ -font-size: 11px; -} - -.text_class755 -{ -} - -.text_class756 -{ -} - -.paragraph_class757 -{ -} - -.text_class758 -{ -font-size: 11px; -} - -.text_class759 -{ -} - -.text_class760 -{ -} - -.paragraph_class761 -{ -} - -.text_class762 -{ -font-family: arial; -} - -.text_class763 -{ -font-size: 10px; -} - -.text_class764 -{ -} - -.paragraph_class765 -{ -} - -.text_class766 -{ -font-family: arial; -} - -.text_class767 -{ -} - -.paragraph_class768 -{ -} - -.text_class769 -{ -font-size: 10px; -font-family: arial; -} - -.text_class770 -{ -} - -.paragraph_class771 -{ -} - -.text_class772 -{ -} - -.paragraph_class773 -{ -} - -.text_class774 -{ -} - -.text_class775 -{ -} - -.paragraph_class776 -{ -} - -.text_class777 -{ -} - -.paragraph_class778 -{ -margin-left: 0px; -} - -.text_class779 -{ -font-size: 11px; -font-family: arial; -} - -.text_class780 -{ -} - -.paragraph_class781 -{ -margin-left: 0px; -} - -.text_class782 -{ -font-size: 11px; -font-family: arial; -} - -.text_class783 -{ -} - -.text_class784 -{ -font-size: 11px; -} - -.text_class785 -{ -} - -.paragraph_class786 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class787 -{ -font-size: 11px; -font-family: arial; -} - -.text_class788 -{ -} - -.text_class789 -{ -font-size: 11px; -} - -.text_class790 -{ -} - -.paragraph_class791 -{ -margin-left: 0px; -} - -.text_class792 -{ -font-size: 11px; -font-family: arial; -} - -.text_class793 -{ -} - -.paragraph_class794 -{ -text-align: center; -margin-left: 0px; -} - -.text_class795 -{ -font-size: 11px; -font-family: arial; -} - -.text_class796 -{ -font-weight: bold; -} - -.text_class797 -{ -} - -.cell_class798 -{ -width: 49px; -} - -.paragraph_class800 -{ -margin-left: 0px; -} - -.text_class801 -{ -font-size: 11px; -font-family: arial; -} - -.text_class802 -{ -font-weight: bold; -} - -.cell_class803 -{ -width: 185px; -} - -.paragraph_class805 -{ -margin-left: 0px; -} - -.text_class806 -{ -font-size: 11px; -font-family: arial; -} - -.text_class807 -{ -font-weight: bold; -} - -.cell_class808 -{ -width: 350px; -} - -.paragraph_class810 -{ -margin-left: 0px; -} - -.text_class811 -{ -font-size: 11px; -font-family: arial; -} - -.text_class812 -{ -font-weight: bold; -} - -.paragraph_class813 -{ -margin-left: 0px; -} - -.text_class814 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class815 -{ -margin-left: 0px; -} - -.text_class816 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class817 -{ -margin-left: 0px; -} - -.text_class818 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class819 -{ -margin-left: 0px; -} - -.text_class820 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class821 -{ -margin-left: 0px; -} - -.text_class822 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class823 -{ -margin-left: 0px; -} - -.text_class824 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class825 -{ -margin-left: 0px; -} - -.text_class826 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class827 -{ -margin-left: 0px; -} - -.text_class828 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class829 -{ -margin-left: 0px; -} - -.text_class830 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class831 -{ -margin-left: 0px; -} - -.text_class832 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class833 -{ -margin-left: 0px; -} - -.text_class834 -{ -font-size: 11px; -font-family: arial; -} - -.text_class835 -{ -font-size: 11px; -font-family: arial; -} - -.text_class836 -{ -font-size: 11px; -font-family: arial; -} - -.text_class837 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class838 -{ -margin-left: 0px; -} - -.text_class839 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class840 -{ -margin-left: 0px; -} - -.text_class841 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class842 -{ -margin-left: 0px; -} - -.text_class843 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class844 -{ -margin-left: 0px; -} - -.text_class845 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class846 -{ -margin-left: 0px; -} - -.text_class847 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class848 -{ -margin-left: 0px; -} - -.text_class849 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class850 -{ -margin-left: 0px; -} - -.text_class851 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class852 -{ -margin-left: 0px; -} - -.text_class853 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class854 -{ -margin-left: 0px; -} - -.text_class855 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class856 -{ -margin-left: 0px; -} - -.text_class857 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class858 -{ -margin-left: 0px; -} - -.text_class859 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class860 -{ -margin-left: 0px; -} - -.text_class861 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class862 -{ -margin-left: 0px; -} - -.text_class863 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class864 -{ -margin-left: 0px; -} - -.text_class865 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class866 -{ -margin-left: 0px; -} - -.text_class867 -{ -font-size: 11px; -font-family: arial; -} - -.text_class868 -{ -} - -.text_class869 -{ -} - -.paragraph_class870 -{ -} - -.text_class871 -{ -} - -.paragraph_class872 -{ -} - -.text_class873 -{ -font-size: 11px; -} - -.text_class874 -{ -} - -.paragraph_class875 -{ -} - -.text_class876 -{ -font-size: 11px; -} - -.text_class877 -{ -font-family: arial; -} - -.paragraph_class878 -{ -} - -.text_class879 -{ -font-size: 11px; -} - -.text_class880 -{ -font-family: arial; -} - -.paragraph_class881 -{ -} - -.text_class882 -{ -font-size: 11px; -} - -.text_class883 -{ -font-family: arial; -} - -.text_class884 -{ -} - -.paragraph_class885 -{ -} - -.text_class886 -{ -font-size: 11px; -} - -.text_class887 -{ -font-family: arial; -} - -.paragraph_class888 -{ -} - -.text_class889 -{ -font-size: 11px; -} - -.text_class890 -{ -font-family: arial; -} - -.paragraph_class891 -{ -} - -.text_class892 -{ -font-size: 11px; -} - -.text_class893 -{ -font-family: arial; -} - -.paragraph_class894 -{ -} - -.text_class895 -{ -font-size: 11px; -} - -.text_class896 -{ -font-family: arial; -} - -.text_class897 -{ -} - -.paragraph_class898 -{ -} - -.text_class899 -{ -font-family: arial; -} - -.text_class900 -{ -font-size: 11px; -} - -.text_class901 -{ -} - -.paragraph_class902 -{ -} - -.text_class903 -{ -font-size: 11px; -} - -.text_class904 -{ -font-family: arial; -} - -.paragraph_class905 -{ -} - -.text_class906 -{ -font-size: 11px; -} - -.text_class907 -{ -font-family: arial; -} - -.text_class908 -{ -} - -.paragraph_class909 -{ -} - -.text_class910 -{ -font-size: 11px; -} - -.text_class911 -{ -font-family: arial; -} - -.text_class912 -{ -} - -.paragraph_class913 -{ -} - -.text_class914 -{ -font-family: arial; -} - -.text_class915 -{ -font-size: 11px; -} - -.paragraph_class916 -{ -} - -.text_class917 -{ -font-family: arial; -} - -.text_class918 -{ -font-size: 11px; -} - -.text_class919 -{ -} - -.paragraph_class920 -{ -} - -.text_class921 -{ -font-family: arial; -} - -.text_class922 -{ -font-size: 11px; -} - -.paragraph_class923 -{ -} - -.text_class924 -{ -font-family: arial; -} - -.text_class925 -{ -font-size: 11px; -} - -.text_class926 -{ -} - -.text_class927 -{ -} - -.paragraph_class928 -{ -} - -.text_class929 -{ -font-family: arial; -} - -.text_class930 -{ -font-size: 11px; -} - -.paragraph_class931 -{ -} - -.text_class932 -{ -font-family: arial; -} - -.text_class933 -{ -font-size: 11px; -} - -.paragraph_class934 -{ -} - -.text_class935 -{ -font-family: arial; -} - -.text_class936 -{ -font-size: 11px; -} - -.text_class937 -{ -} - -.paragraph_class938 -{ -} - -.text_class939 -{ -font-family: arial; -} - -.text_class940 -{ -font-size: 11px; -} - -.paragraph_class941 -{ -} - -.text_class942 -{ -font-family: arial; -} - -.text_class943 -{ -font-size: 11px; -} - -.text_class944 -{ -} - -.paragraph_class945 -{ -} - -.text_class946 -{ -font-family: arial; -} - -.text_class947 -{ -font-size: 11px; -} - -.paragraph_class948 -{ -} - -.text_class949 -{ -font-family: arial; -} - -.text_class950 -{ -font-size: 11px; -} - -.paragraph_class951 -{ -} - -.text_class952 -{ -font-family: arial; -} - -.text_class953 -{ -font-size: 11px; -} - -.text_class954 -{ -} - -.paragraph_class955 -{ -} - -.text_class956 -{ -font-family: arial; -} - -.text_class957 -{ -font-size: 11px; -} - -.paragraph_class958 -{ -} - -.text_class959 -{ -font-family: arial; -} - -.text_class960 -{ -font-size: 11px; -} - -.text_class961 -{ -} - -.paragraph_class962 -{ -} - -.text_class963 -{ -font-family: arial; -} - -.text_class964 -{ -font-size: 11px; -} - -.paragraph_class965 -{ -} - -.text_class966 -{ -font-family: arial; -} - -.text_class967 -{ -font-size: 11px; -} - -.paragraph_class968 -{ -} - -.text_class969 -{ -font-family: arial; -} - -.text_class970 -{ -font-size: 11px; -} - -.paragraph_class971 -{ -} - -.text_class972 -{ -font-family: arial; -} - -.text_class973 -{ -font-size: 11px; -} - -.text_class974 -{ -} - -.paragraph_class975 -{ -} - -.text_class976 -{ -font-family: arial; -} - -.text_class977 -{ -font-size: 11px; -} - -.text_class978 -{ -} - -.text_class979 -{ -} - -.paragraph_class980 -{ -} - -.text_class981 -{ -font-family: arial; -} - -.text_class982 -{ -font-size: 11px; -} - -.paragraph_class983 -{ -} - -.text_class984 -{ -font-family: arial; -} - -.text_class985 -{ -font-size: 11px; -} - -.paragraph_class986 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class987 -{ -font-size: 11px; -} - -.text_class988 -{ -font-family: arial; -} - -.text_class989 -{ -font-size: 11px; -} - -.paragraph_class990 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class991 -{ -font-size: 11px; -font-family: arial; -} - -.text_class992 -{ -} - -.paragraph_class993 -{ -} - -.text_class994 -{ -font-family: arial; -} - -.text_class995 -{ -font-size: 11px; -} - -.paragraph_class996 -{ -} - -.text_class997 -{ -font-family: arial; -} - -.text_class998 -{ -font-size: 11px; -} - -.text_class999 -{ -} - -.paragraph_class1000 -{ -} - -.text_class1001 -{ -font-family: arial; -} - -.text_class1002 -{ -font-size: 11px; -} - -.paragraph_class1003 -{ -} - -.text_class1004 -{ -font-family: arial; -} - -.text_class1005 -{ -font-size: 11px; -} - -.text_class1006 -{ -font-family: arial; -} - -.text_class1007 -{ -font-size: 11px; -} - -.paragraph_class1008 -{ -} - -.text_class1009 -{ -font-family: arial; -} - -.text_class1010 -{ -font-size: 11px; -} - -.text_class1011 -{ -} - -.paragraph_class1012 -{ -} - -.text_class1013 -{ -font-family: arial; -} - -.text_class1014 -{ -font-size: 11px; -} - -.paragraph_class1015 -{ -} - -.text_class1016 -{ -font-family: arial; -} - -.text_class1017 -{ -font-size: 11px; -} - -.text_class1018 -{ -} - -.paragraph_class1019 -{ -} - -.text_class1020 -{ -font-family: arial; -} - -.text_class1021 -{ -font-size: 11px; -} - -.paragraph_class1022 -{ -} - -.text_class1023 -{ -font-family: arial; -} - -.text_class1024 -{ -font-size: 11px; -} - -.text_class1025 -{ -} - -.paragraph_class1026 -{ -} - -.text_class1027 -{ -font-family: arial; -} - -.text_class1028 -{ -font-size: 11px; -} - -.text_class1029 -{ -} - -.paragraph_class1030 -{ -} - -.text_class1031 -{ -font-family: arial; -} - -.text_class1032 -{ -font-size: 11px; -} - -.text_class1033 -{ -} - -.paragraph_class1034 -{ -} - -.text_class1035 -{ -font-family: arial; -} - -.text_class1036 -{ -font-size: 11px; -} - -.text_class1037 -{ -} - -.text_class1038 -{ -} - -.paragraph_class1039 -{ -} - -.text_class1040 -{ -font-family: arial; -} - -.text_class1041 -{ -font-size: 11px; -} - -.paragraph_class1042 -{ -} - -.text_class1043 -{ -font-family: arial; -} - -.text_class1044 -{ -font-size: 11px; -} - -.paragraph_class1045 -{ -} - -.text_class1046 -{ -font-family: arial; -} - -.text_class1047 -{ -font-size: 11px; -} - -.text_class1048 -{ -} - -.text_class1049 -{ -} - -.paragraph_class1050 -{ -} - -.text_class1051 -{ -font-family: arial; -} - -.text_class1052 -{ -font-size: 11px; -} - -.text_class1053 -{ -font-family: arial; -} - -.text_class1054 -{ -font-size: 11px; -} - -.paragraph_class1055 -{ -} - -.text_class1056 -{ -font-family: arial; -} - -.text_class1057 -{ -font-size: 11px; -} - -.text_class1058 -{ -} - -.text_class1059 -{ -} - -.paragraph_class1060 -{ -} - -.text_class1061 -{ -font-family: arial; -} - -.text_class1062 -{ -font-size: 11px; -} - -.text_class1063 -{ -} - -.text_class1064 -{ -} - -.paragraph_class1065 -{ -} - -.text_class1066 -{ -font-family: arial; -} - -.text_class1067 -{ -font-size: 11px; -} - -.text_class1068 -{ -} - -.paragraph_class1069 -{ -} - -.text_class1070 -{ -font-family: arial; -} - -.text_class1071 -{ -font-size: 11px; -} - -.text_class1072 -{ -} - -.text_class1073 -{ -} - -.paragraph_class1074 -{ -} - -.text_class1075 -{ -font-family: arial; -} - -.text_class1076 -{ -font-size: 11px; -} - -.text_class1077 -{ -} - -.paragraph_class1078 -{ -} - -.text_class1079 -{ -font-family: arial; -} - -.text_class1080 -{ -font-size: 11px; -} - -.paragraph_class1081 -{ -} - -.text_class1082 -{ -font-family: arial; -} - -.text_class1083 -{ -font-size: 11px; -} - -.text_class1084 -{ -} - -.text_class1085 -{ -} - -.text_class1086 -{ -} - -.text_class1087 -{ -} - -.paragraph_class1088 -{ -margin-left: 0px; -} - -.text_class1089 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1090 -{ -} - -.text_class1091 -{ -} - -.paragraph_class1092 -{ -} - -.text_class1093 -{ -font-size: 11px; -} - -.text_class1094 -{ -} - -.paragraph_class1095 -{ -} - -.text_class1096 -{ -font-size: 11px; -} - -.text_class1097 -{ -} - -.text_class1098 -{ -} - -.paragraph_class1099 -{ -margin-left: 0px; -} - -.text_class1100 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1101 -{ -} - -.text_class1102 -{ -} - -.paragraph_class1103 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1104 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1105 -{ -font-weight: bold; -} - -.text_class1106 -{ -} - -.paragraph_class1107 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1108 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1109 -{ -} - -.paragraph_class1110 -{ -} - -.text_class1111 -{ -font-size: 11px; -} - -.text_class1112 -{ -} - -.text_class1113 -{ -} - -.paragraph_class1114 -{ -margin-left: 0px; -} - -.text_class1115 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1116 -{ -} - -.text_class1117 -{ -} - -.paragraph_class1118 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1119 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1120 -{ -font-weight: bold; -} - -.text_class1121 -{ -} - -.paragraph_class1122 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1123 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1124 -{ -} - -.paragraph_class1125 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1126 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1127 -{ -font-weight: bold; -} - -.text_class1128 -{ -} - -.cell_class1129 -{ -width: 37px; -} - -.paragraph_class1131 -{ -margin-left: 0px; -} - -.text_class1132 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1133 -{ -font-weight: bold; -} - -.cell_class1134 -{ -width: 197px; -} - -.paragraph_class1136 -{ -margin-left: 0px; -} - -.text_class1137 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1138 -{ -font-weight: bold; -} - -.cell_class1139 -{ -width: 340px; -} - -.paragraph_class1141 -{ -margin-left: 0px; -} - -.text_class1142 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1143 -{ -font-weight: bold; -} - -.paragraph_class1144 -{ -margin-left: 0px; -} - -.text_class1145 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1146 -{ -margin-left: 0px; -} - -.text_class1147 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1148 -{ -margin-left: 0px; -} - -.text_class1149 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1150 -{ -margin-left: 0px; -} - -.text_class1151 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1152 -{ -margin-left: 0px; -} - -.text_class1153 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1154 -{ -margin-left: 0px; -} - -.text_class1155 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1156 -{ -margin-left: 0px; -} - -.text_class1157 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1158 -{ -margin-left: 0px; -} - -.text_class1159 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1160 -{ -margin-left: 0px; -} - -.text_class1161 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1162 -{ -margin-left: 0px; -} - -.text_class1163 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1164 -{ -margin-left: 0px; -} - -.text_class1165 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1166 -{ -margin-left: 0px; -} - -.text_class1167 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1168 -{ -margin-left: 0px; -} - -.text_class1169 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class1170 -{ -width: 93px; -} - -.paragraph_class1171 -{ -margin-left: 0px; -} - -.text_class1172 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class1173 -{ -width: 104px; -} - -.paragraph_class1174 -{ -margin-left: 0px; -} - -.text_class1175 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1177 -{ -margin-left: 0px; -} - -.text_class1178 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1179 -{ -margin-left: 0px; -} - -.text_class1180 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1181 -{ -margin-left: 0px; -} - -.text_class1182 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1183 -{ -margin-left: 0px; -} - -.text_class1184 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1185 -{ -margin-left: 0px; -} - -.text_class1186 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1187 -{ -margin-left: 0px; -} - -.text_class1188 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1189 -{ -margin-left: 0px; -} - -.text_class1190 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1191 -{ -margin-left: 0px; -} - -.text_class1192 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1193 -{ -margin-left: 0px; -} - -.text_class1194 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1195 -{ -margin-left: 0px; -} - -.text_class1196 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1197 -{ -margin-left: 0px; -} - -.text_class1198 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1199 -{ -margin-left: 0px; -} - -.text_class1200 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1201 -{ -margin-left: 0px; -} - -.text_class1202 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1203 -{ -} - -.paragraph_class1204 -{ -} - -.text_class1205 -{ -font-size: 11px; -} - -.text_class1206 -{ -} - -.paragraph_class1207 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1208 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1209 -{ -} - -.paragraph_class1210 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1211 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1212 -{ -font-weight: bold; -} - -.text_class1213 -{ -} - -.paragraph_class1215 -{ -margin-left: 0px; -} - -.text_class1216 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1217 -{ -font-weight: bold; -} - -.paragraph_class1219 -{ -margin-left: 0px; -} - -.text_class1220 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1221 -{ -font-weight: bold; -} - -.paragraph_class1223 -{ -margin-left: 0px; -} - -.text_class1224 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1225 -{ -font-weight: bold; -} - -.paragraph_class1226 -{ -margin-left: 0px; -} - -.text_class1227 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1228 -{ -margin-left: 0px; -} - -.text_class1229 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1230 -{ -margin-left: 0px; -} - -.text_class1231 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1232 -{ -margin-left: 0px; -} - -.text_class1233 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1234 -{ -margin-left: 0px; -} - -.text_class1235 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1236 -{ -margin-left: 0px; -} - -.text_class1237 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1238 -{ -margin-left: 0px; -} - -.text_class1239 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1240 -{ -margin-left: 0px; -} - -.text_class1241 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1242 -{ -margin-left: 0px; -} - -.text_class1243 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1244 -{ -margin-left: 0px; -} - -.text_class1245 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1246 -{ -margin-left: 0px; -} - -.text_class1247 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1248 -{ -margin-left: 0px; -} - -.text_class1249 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1250 -{ -margin-left: 0px; -} - -.text_class1251 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1252 -{ -margin-left: 0px; -} - -.text_class1253 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1254 -{ -margin-left: 0px; -} - -.text_class1255 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1256 -{ -margin-left: 0px; -} - -.text_class1257 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1258 -{ -} - -.text_class1259 -{ -} - -.paragraph_class1260 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1261 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1262 -{ -font-weight: bold; -} - -.text_class1263 -{ -} - -.paragraph_class1264 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1265 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1266 -{ -} - -.paragraph_class1267 -{ -} - -.text_class1268 -{ -font-size: 11px; -} - -.text_class1269 -{ -} - -.paragraph_class1270 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1271 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1272 -{ -} - -.paragraph_class1273 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1274 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1275 -{ -} - -.text_class1276 -{ -} - -.paragraph_class1277 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1278 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1279 -{ -font-weight: bold; -} - -.text_class1280 -{ -} - -.paragraph_class1281 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1282 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1283 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1284 -{ -} - -.paragraph_class1285 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1286 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1287 -{ -} - -.paragraph_class1288 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1289 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1290 -{ -} - -.paragraph_class1291 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1292 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1293 -{ -} - -.paragraph_class1294 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1295 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1296 -{ -} - -.paragraph_class1297 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1298 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1299 -{ -} - -.paragraph_class1300 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1301 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1302 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1303 -{ -} - -.paragraph_class1304 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1305 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1306 -{ -} - -.paragraph_class1307 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1308 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1309 -{ -} - -.paragraph_class1310 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1311 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1312 -{ -} - -.paragraph_class1313 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1314 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1315 -{ -} - -.text_class1316 -{ -} - -.paragraph_class1317 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1318 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1319 -{ -font-weight: bold; -} - -.text_class1320 -{ -} - -.paragraph_class1321 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1322 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1323 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1324 -{ -} - -.paragraph_class1325 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1326 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1327 -{ -} - -.paragraph_class1328 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1329 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1330 -{ -} - -.paragraph_class1331 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1332 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1333 -{ -font-weight: bold; -} - -.text_class1334 -{ -} - -.cell_class1335 -{ -width: 34px; -background-color: #bfbfbf; -} - -.paragraph_class1337 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1338 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1339 -{ -font-weight: bold; -} - -.cell_class1340 -{ -width: 96px; -background-color: #bfbfbf; -} - -.paragraph_class1342 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1343 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1344 -{ -font-weight: bold; -} - -.cell_class1345 -{ -width: 302px; -background-color: #bfbfbf; -} - -.paragraph_class1347 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1348 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1349 -{ -font-weight: bold; -} - -.cell_class1350 -{ -width: 149px; -background-color: #bfbfbf; -} - -.paragraph_class1352 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1353 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1354 -{ -font-weight: bold; -} - -.cell_class1355 -{ -width: 34px; -} - -.paragraph_class1356 -{ -margin-left: 0px; -} - -.text_class1357 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class1358 -{ -width: 96px; -} - -.paragraph_class1359 -{ -margin-left: 0px; -} - -.text_class1360 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class1361 -{ -width: 302px; -} - -.paragraph_class1362 -{ -margin-left: 0px; -} - -.text_class1363 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class1364 -{ -width: 149px; -} - -.paragraph_class1365 -{ -margin-left: 0px; -} - -.text_class1366 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1367 -{ -margin-left: 0px; -} - -.text_class1368 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1369 -{ -margin-left: 0px; -} - -.text_class1370 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1371 -{ -margin-left: 0px; -} - -.text_class1372 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1373 -{ -margin-left: 0px; -} - -.text_class1374 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1375 -{ -margin-left: 0px; -} - -.text_class1376 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1377 -{ -margin-left: 0px; -} - -.text_class1378 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1379 -{ -margin-left: 0px; -} - -.text_class1380 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1381 -{ -margin-left: 0px; -} - -.text_class1382 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1383 -{ -margin-left: 0px; -} - -.text_class1384 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1385 -{ -margin-left: 0px; -} - -.text_class1386 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1387 -{ -margin-left: 0px; -} - -.text_class1388 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1389 -{ -margin-left: 0px; -} - -.text_class1390 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1391 -{ -} - -.paragraph_class1392 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1393 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1394 -{ -} - -.paragraph_class1395 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1396 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1397 -{ -} - -.paragraph_class1398 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1399 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1400 -{ -font-weight: bold; -} - -.text_class1401 -{ -} - -.paragraph_class1403 -{ -margin-left: 0px; -} - -.text_class1404 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1405 -{ -font-weight: bold; -} - -.paragraph_class1407 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1408 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1409 -{ -font-weight: bold; -} - -.paragraph_class1411 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1412 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1413 -{ -font-weight: bold; -} - -.paragraph_class1415 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1416 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1417 -{ -font-weight: bold; -} - -.paragraph_class1418 -{ -margin-left: 0px; -} - -.text_class1419 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1420 -{ -margin-left: 0px; -} - -.text_class1421 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1422 -{ -margin-left: 0px; -} - -.text_class1423 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1424 -{ -margin-left: 0px; -} - -.text_class1425 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1426 -{ -margin-left: 0px; -} - -.text_class1427 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1428 -{ -margin-left: 0px; -} - -.text_class1429 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1430 -{ -margin-left: 0px; -} - -.text_class1431 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class1432 -{ -margin-left: 0px; -} - -.text_class1433 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class1434 -{ -} - -.paragraph_class1435 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1436 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1437 -{ -} - -.text_class1438 -{ -} - -.paragraph_class1439 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1440 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1441 -{ -font-weight: bold; -} - -.text_class1442 -{ -} - -.paragraph_class1443 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1444 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1445 -{ -} - -.paragraph_class1446 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1447 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1448 -{ -} - -.paragraph_class1449 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1450 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1451 -{ -} - -.paragraph_class1452 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1453 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1454 -{ -} - -.paragraph_class1455 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1456 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1457 -{ -} - -.paragraph_class1458 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1459 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1460 -{ -} - -.paragraph_class1461 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1462 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1463 -{ -} - -.paragraph_class1464 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1465 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1466 -{ -} - -.paragraph_class1467 -{ -} - -.text_class1468 -{ -font-size: 11px; -} - -.text_class1469 -{ -} - -.paragraph_class1470 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1471 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1472 -{ -} - -.paragraph_class1473 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1474 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1475 -{ -} - -.text_class1476 -{ -} - -.paragraph_class1477 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1478 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1479 -{ -font-weight: bold; -} - -.text_class1480 -{ -} - -.paragraph_class1481 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1482 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1483 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1484 -{ -} - -.paragraph_class1485 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1486 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1487 -{ -} - -.paragraph_class1488 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1489 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1490 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1491 -{ -} - -.paragraph_class1492 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1493 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1494 -{ -} - -.paragraph_class1495 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1496 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1497 -{ -} - -.paragraph_class1498 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1499 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1500 -{ -font-weight: bold; -} - -.text_class1501 -{ -} - -.paragraph_class1503 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1504 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1505 -{ -font-weight: bold; -} - -.paragraph_class1507 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1508 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1509 -{ -font-weight: bold; -} - -.paragraph_class1511 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1512 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1513 -{ -font-weight: bold; -} - -.paragraph_class1515 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1516 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1517 -{ -font-weight: bold; -} - -.paragraph_class1518 -{ -margin-left: 0px; -} - -.text_class1519 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1520 -{ -margin-left: 0px; -} - -.text_class1521 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1522 -{ -margin-left: 0px; -} - -.text_class1523 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1524 -{ -margin-left: 0px; -} - -.text_class1525 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1526 -{ -margin-left: 0px; -} - -.text_class1527 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1528 -{ -margin-left: 0px; -} - -.text_class1529 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1530 -{ -margin-left: 0px; -} - -.text_class1531 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1532 -{ -margin-left: 0px; -} - -.text_class1533 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1534 -{ -margin-left: 0px; -} - -.text_class1535 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1536 -{ -margin-left: 0px; -} - -.text_class1537 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1538 -{ -margin-left: 0px; -} - -.text_class1539 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1540 -{ -margin-left: 0px; -} - -.text_class1541 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1542 -{ -} - -.paragraph_class1543 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1544 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1545 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1546 -{ -} - -.paragraph_class1547 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1548 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1549 -{ -} - -.paragraph_class1550 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1551 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1552 -{ -} - -.paragraph_class1553 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1554 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1555 -{ -} - -.text_class1556 -{ -} - -.paragraph_class1557 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1558 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1559 -{ -font-weight: bold; -} - -.text_class1560 -{ -} - -.paragraph_class1561 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1562 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1563 -{ -} - -.paragraph_class1564 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1565 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1566 -{ -} - -.paragraph_class1567 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1568 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1569 -{ -} - -.paragraph_class1570 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1571 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1572 -{ -} - -.paragraph_class1573 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1574 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1575 -{ -} - -.paragraph_class1576 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1577 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1578 -{ -} - -.paragraph_class1579 -{ -} - -.text_class1580 -{ -font-size: 11px; -} - -.text_class1581 -{ -} - -.paragraph_class1582 -{ -} - -.text_class1583 -{ -font-size: 11px; -} - -.text_class1584 -{ -} - -.paragraph_class1585 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1586 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1587 -{ -} - -.text_class1588 -{ -} - -.paragraph_class1589 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1590 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1591 -{ -font-weight: bold; -} - -.text_class1592 -{ -} - -.paragraph_class1593 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1594 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1595 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1596 -{ -} - -.paragraph_class1597 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1598 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1599 -{ -} - -.paragraph_class1600 -{ -text-align: justify; -margin-left: 40px; -} - -.text_class1601 -{ -font-size: 10px; -font-family: Times New Roman; -} - -.text_class1602 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1603 -{ -} - -.paragraph_class1604 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1605 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1606 -{ -} - -.paragraph_class1607 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1608 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1609 -{ -} - -.paragraph_class1610 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1611 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1612 -{ -} - -.text_class1613 -{ -} - -.paragraph_class1614 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1615 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1616 -{ -font-weight: bold; -} - -.text_class1617 -{ -} - -.paragraph_class1618 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1619 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1620 -{ -} - -.paragraph_class1621 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class1622 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1623 -{ -} - -.paragraph_class1624 -{ -margin-left: 0px; -} - -.text_class1625 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1626 -{ -} - -.paragraph_class1627 -{ -margin-left: 0px; -} - -.text_class1628 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1629 -{ -} - -.text_class1630 -{ -} - -.paragraph_class1631 -{ -} - -.text_class1632 -{ -font-size: 11px; -} - -.text_class1633 -{ -} - -.paragraph_class1634 -{ -margin-left: 0px; -} - -.text_class1635 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1636 -{ -} - -.paragraph_class1637 -{ -margin-left: 0px; -} - -.text_class1638 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1639 -{ -} - -.paragraph_class1640 -{ -} - -.text_class1641 -{ -font-size: 11px; -} - -.text_class1642 -{ -} - -.paragraph_class1644 -{ -margin-left: 0px; -} - -.text_class1645 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1646 -{ -font-weight: bold; -} - -.paragraph_class1648 -{ -margin-left: 0px; -} - -.text_class1649 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1650 -{ -font-weight: bold; -} - -.paragraph_class1652 -{ -margin-left: 0px; -} - -.text_class1653 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1654 -{ -font-weight: bold; -} - -.paragraph_class1655 -{ -margin-left: 0px; -} - -.text_class1656 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1657 -{ -margin-left: 0px; -} - -.text_class1658 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1659 -{ -margin-left: 0px; -} - -.text_class1660 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1661 -{ -margin-left: 0px; -} - -.text_class1662 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1663 -{ -margin-left: 0px; -} - -.text_class1664 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1665 -{ -margin-left: 0px; -} - -.text_class1666 -{ -font-size: 11px; -font-family: arial; -} - -.list_class1667 -{ -list-style-type: decimal; -} - -.text_class1668 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1669 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1670 -{ -} - -.text_class1671 -{ -} - -.text_class1672 -{ -} - -.paragraph_class1673 -{ -} - -.text_class1674 -{ -font-size: 11px; -} - -.text_class1675 -{ -} - -.paragraph_class1676 -{ -} - -.text_class1677 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1678 -{ -} - -.paragraph_class1679 -{ -} - -.text_class1680 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1681 -{ -} - -.text_class1682 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1683 -{ -} - -.text_class1684 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1685 -{ -color: #222222; -font-size: 11px; -font-family: arial; -} - -.text_class1686 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1687 -{ -} - -.text_class1688 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1689 -{ -} - -.text_class1690 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1691 -{ -} - -.paragraph_class1692 -{ -} - -.text_class1693 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1694 -{ -} - -.text_class1695 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1696 -{ -} - -.text_class1697 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1698 -{ -} - -.text_class1699 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1700 -{ -} - -.paragraph_class1701 -{ -margin-left: 0px; -} - -.text_class1702 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1703 -{ -margin-left: 0px; -} - -.text_class1704 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1705 -{ -margin-left: 0px; -} - -.text_class1706 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1707 -{ -margin-left: 0px; -} - -.text_class1708 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1709 -{ -margin-left: 0px; -} - -.text_class1710 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1711 -{ -margin-left: 0px; -} - -.text_class1712 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1713 -{ -} - -.paragraph_class1714 -{ -margin-left: 0px; -} - -.text_class1715 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1716 -{ -margin-left: 0px; -} - -.text_class1717 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1718 -{ -margin-left: 0px; -} - -.text_class1719 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1720 -{ -} - -.paragraph_class1721 -{ -margin-left: 0px; -} - -.text_class1722 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1723 -{ -margin-left: 0px; -} - -.text_class1724 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1725 -{ -margin-left: 0px; -} - -.text_class1726 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1727 -{ -margin-left: 0px; -} - -.text_class1728 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1729 -{ -} - -.paragraph_class1730 -{ -margin-left: 0px; -} - -.text_class1731 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1732 -{ -margin-left: 0px; -} - -.text_class1733 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1734 -{ -margin-left: 0px; -} - -.text_class1735 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1736 -{ -margin-left: 0px; -} - -.text_class1737 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1738 -{ -} - -.paragraph_class1739 -{ -margin-left: 0px; -} - -.text_class1740 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1741 -{ -margin-left: 0px; -} - -.text_class1742 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1743 -{ -margin-left: 0px; -} - -.text_class1744 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1745 -{ -} - -.paragraph_class1746 -{ -} - -.text_class1747 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1748 -{ -} - -.paragraph_class1749 -{ -} - -.text_class1750 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1751 -{ -} - -.paragraph_class1752 -{ -} - -.text_class1753 -{ -font-size: 11px; -} - -.text_class1754 -{ -} - -.paragraph_class1755 -{ -} - -.text_class1756 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1757 -{ -} - -.paragraph_class1758 -{ -margin-left: 0px; -} - -.text_class1759 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1760 -{ -margin-left: 0px; -} - -.text_class1761 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1762 -{ -margin-left: 0px; -} - -.text_class1763 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1764 -{ -margin-left: 0px; -} - -.text_class1765 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1766 -{ -margin-left: 0px; -} - -.text_class1767 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1768 -{ -margin-left: 0px; -} - -.text_class1769 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1770 -{ -} - -.paragraph_class1771 -{ -margin-left: 0px; -} - -.text_class1772 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1773 -{ -margin-left: 0px; -} - -.text_class1774 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1775 -{ -margin-left: 0px; -} - -.text_class1776 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1777 -{ -margin-left: 0px; -} - -.text_class1778 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1779 -{ -margin-left: 0px; -} - -.text_class1780 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1781 -{ -margin-left: 0px; -} - -.text_class1782 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1783 -{ -} - -.text_class1784 -{ -} - -.paragraph_class1785 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1786 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1787 -{ -font-weight: bold; -} - -.text_class1788 -{ -} - -.paragraph_class1789 -{ -margin-left: 0px; -} - -.text_class1790 -{ -font-size: 11px; -font-family: arial; -} - -.list_class1791 -{ -list-style-type: lower-alpha; -} - -.text_class1792 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1793 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1794 -{ -} - -.paragraph_class1795 -{ -margin-left: 0px; -} - -.text_class1796 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1797 -{ -margin-left: 0px; -} - -.text_class1798 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1799 -{ -margin-left: 0px; -} - -.text_class1800 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1801 -{ -margin-left: 0px; -} - -.text_class1802 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1803 -{ -} - -.paragraph_class1804 -{ -margin-left: 0px; -} - -.text_class1805 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1806 -{ -margin-left: 0px; -} - -.text_class1807 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1808 -{ -margin-left: 0px; -} - -.text_class1809 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1810 -{ -} - -.paragraph_class1811 -{ -} - -.text_class1812 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1813 -{ -} - -.paragraph_class1814 -{ -} - -.text_class1815 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1816 -{ -} - -.paragraph_class1817 -{ -} - -.text_class1818 -{ -font-size: 11px; -} - -.text_class1819 -{ -} - -.paragraph_class1820 -{ -} - -.text_class1821 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1822 -{ -} - -.paragraph_class1823 -{ -margin-left: 0px; -} - -.text_class1824 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1825 -{ -margin-left: 0px; -} - -.text_class1826 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1827 -{ -margin-left: 0px; -} - -.text_class1828 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1829 -{ -margin-left: 0px; -} - -.text_class1830 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1831 -{ -margin-left: 0px; -} - -.text_class1832 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1833 -{ -margin-left: 0px; -} - -.text_class1834 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1835 -{ -margin-left: 0px; -} - -.text_class1836 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1837 -{ -margin-left: 0px; -} - -.text_class1838 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1839 -{ -margin-left: 0px; -} - -.text_class1840 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1841 -{ -margin-left: 0px; -} - -.text_class1842 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1843 -{ -} - -.paragraph_class1844 -{ -margin-left: 0px; -} - -.text_class1845 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1846 -{ -margin-left: 0px; -} - -.text_class1847 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1848 -{ -margin-left: 0px; -} - -.text_class1849 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1850 -{ -} - -.text_class1851 -{ -} - -.paragraph_class1852 -{ -} - -.text_class1853 -{ -font-size: 11px; -} - -.text_class1854 -{ -} - -.paragraph_class1855 -{ -} - -.text_class1856 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1857 -{ -} - -.paragraph_class1858 -{ -margin-left: 0px; -} - -.text_class1859 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1860 -{ -margin-left: 0px; -} - -.text_class1861 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1862 -{ -margin-left: 0px; -} - -.text_class1863 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1864 -{ -} - -.paragraph_class1865 -{ -margin-left: 0px; -} - -.text_class1866 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1867 -{ -margin-left: 0px; -} - -.text_class1868 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1869 -{ -} - -.paragraph_class1870 -{ -} - -.text_class1871 -{ -font-size: 11px; -} - -.text_class1872 -{ -} - -.paragraph_class1873 -{ -} - -.text_class1874 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1875 -{ -} - -.paragraph_class1876 -{ -margin-left: 0px; -} - -.text_class1877 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1878 -{ -margin-left: 0px; -} - -.text_class1879 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1880 -{ -margin-left: 0px; -} - -.text_class1881 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1882 -{ -margin-left: 0px; -} - -.text_class1883 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1884 -{ -margin-left: 0px; -} - -.text_class1885 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1886 -{ -} - -.paragraph_class1887 -{ -margin-left: 0px; -} - -.text_class1888 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1889 -{ -margin-left: 0px; -} - -.text_class1890 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1891 -{ -margin-left: 0px; -} - -.text_class1892 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1893 -{ -margin-left: 0px; -} - -.text_class1894 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1895 -{ -} - -.paragraph_class1896 -{ -margin-left: 0px; -} - -.text_class1897 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1898 -{ -margin-left: 0px; -} - -.text_class1899 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1900 -{ -margin-left: 0px; -} - -.text_class1901 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1902 -{ -} - -.paragraph_class1903 -{ -} - -.text_class1904 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1905 -{ -} - -.paragraph_class1906 -{ -margin-left: 0px; -} - -.text_class1907 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1908 -{ -} - -.text_class1909 -{ -} - -.paragraph_class1910 -{ -text-align: center; -margin-left: 0px; -} - -.text_class1911 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1912 -{ -} - -.paragraph_class1913 -{ -margin-left: 0px; -} - -.text_class1914 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1915 -{ -margin-left: 0px; -} - -.text_class1916 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1917 -{ -} - -.paragraph_class1918 -{ -} - -.text_class1919 -{ -font-size: 11px; -} - -.text_class1920 -{ -} - -.paragraph_class1921 -{ -} - -.text_class1922 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1923 -{ -} - -.paragraph_class1924 -{ -margin-left: 0px; -} - -.text_class1925 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1926 -{ -margin-left: 0px; -} - -.text_class1927 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1928 -{ -margin-left: 0px; -} - -.text_class1929 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1930 -{ -margin-left: 0px; -} - -.text_class1931 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1932 -{ -margin-left: 0px; -} - -.text_class1933 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1934 -{ -margin-left: 0px; -} - -.text_class1935 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1936 -{ -margin-left: 0px; -} - -.text_class1937 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1938 -{ -margin-left: 0px; -} - -.text_class1939 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1940 -{ -} - -.paragraph_class1941 -{ -margin-left: 0px; -} - -.text_class1942 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1943 -{ -margin-left: 0px; -} - -.text_class1944 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1945 -{ -margin-left: 0px; -} - -.text_class1946 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1947 -{ -} - -.text_class1948 -{ -} - -.paragraph_class1949 -{ -} - -.text_class1950 -{ -font-size: 11px; -} - -.text_class1951 -{ -} - -.paragraph_class1952 -{ -} - -.text_class1953 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1954 -{ -} - -.paragraph_class1955 -{ -margin-left: 0px; -} - -.text_class1956 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1957 -{ -margin-left: 0px; -} - -.text_class1958 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1959 -{ -} - -.paragraph_class1960 -{ -margin-left: 0px; -} - -.text_class1961 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1962 -{ -margin-left: 0px; -} - -.text_class1963 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1964 -{ -margin-left: 0px; -} - -.text_class1965 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1966 -{ -} - -.paragraph_class1967 -{ -} - -.text_class1968 -{ -font-size: 11px; -} - -.text_class1969 -{ -} - -.paragraph_class1970 -{ -} - -.text_class1971 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1972 -{ -} - -.paragraph_class1973 -{ -margin-left: 0px; -} - -.text_class1974 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1975 -{ -margin-left: 0px; -} - -.text_class1976 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1977 -{ -margin-left: 0px; -} - -.text_class1978 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1979 -{ -margin-left: 0px; -} - -.text_class1980 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1981 -{ -} - -.paragraph_class1982 -{ -} - -.text_class1983 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1984 -{ -} - -.paragraph_class1985 -{ -} - -.text_class1986 -{ -font-size: 11px; -} - -.text_class1987 -{ -} - -.paragraph_class1988 -{ -} - -.text_class1989 -{ -font-size: 11px; -font-family: arial; -} - -.text_class1990 -{ -} - -.paragraph_class1991 -{ -margin-left: 0px; -} - -.text_class1992 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1993 -{ -margin-left: 0px; -} - -.text_class1994 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1995 -{ -margin-left: 0px; -} - -.text_class1996 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1997 -{ -margin-left: 0px; -} - -.text_class1998 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class1999 -{ -margin-left: 0px; -} - -.text_class2000 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2001 -{ -margin-left: 0px; -} - -.text_class2002 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2003 -{ -margin-left: 0px; -} - -.text_class2004 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2005 -{ -margin-left: 0px; -} - -.text_class2006 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2007 -{ -} - -.paragraph_class2008 -{ -margin-left: 0px; -} - -.text_class2009 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2010 -{ -margin-left: 0px; -} - -.text_class2011 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2012 -{ -margin-left: 0px; -} - -.text_class2013 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2014 -{ -} - -.text_class2015 -{ -} - -.paragraph_class2016 -{ -} - -.text_class2017 -{ -font-size: 11px; -} - -.text_class2018 -{ -} - -.paragraph_class2019 -{ -} - -.text_class2020 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2021 -{ -} - -.paragraph_class2022 -{ -margin-left: 0px; -} - -.text_class2023 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2024 -{ -margin-left: 0px; -} - -.text_class2025 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2026 -{ -margin-left: 0px; -} - -.text_class2027 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2028 -{ -} - -.paragraph_class2029 -{ -} - -.text_class2030 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2031 -{ -} - -.paragraph_class2032 -{ -margin-left: 0px; -} - -.text_class2033 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2034 -{ -margin-left: 0px; -} - -.text_class2035 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2036 -{ -} - -.paragraph_class2037 -{ -margin-left: 0px; -} - -.text_class2038 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2039 -{ -margin-left: 0px; -} - -.text_class2040 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2041 -{ -} - -.paragraph_class2042 -{ -margin-left: 0px; -} - -.text_class2043 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2044 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2045 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2046 -{ -} - -.paragraph_class2047 -{ -} - -.text_class2048 -{ -font-size: 11px; -} - -.text_class2049 -{ -} - -.paragraph_class2050 -{ -} - -.text_class2051 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2052 -{ -} - -.paragraph_class2053 -{ -} - -.text_class2054 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2055 -{ -} - -.paragraph_class2056 -{ -} - -.text_class2057 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2058 -{ -} - -.text_class2059 -{ -} - -.paragraph_class2060 -{ -} - -.text_class2061 -{ -font-size: 11px; -} - -.text_class2062 -{ -} - -.paragraph_class2063 -{ -} - -.text_class2064 -{ -font-size: 11px; -} - -.text_class2065 -{ -} - -.paragraph_class2066 -{ -} - -.text_class2067 -{ -font-size: 11px; -} - -.paragraph_class2068 -{ -} - -.text_class2069 -{ -font-size: 11px; -} - -.paragraph_class2070 -{ -} - -.text_class2071 -{ -font-size: 11px; -} - -.paragraph_class2072 -{ -} - -.text_class2073 -{ -font-size: 11px; -} - -.paragraph_class2074 -{ -} - -.text_class2075 -{ -font-size: 11px; -} - -.paragraph_class2076 -{ -} - -.text_class2077 -{ -font-size: 11px; -} - -.text_class2078 -{ -} - -.paragraph_class2079 -{ -} - -.text_class2080 -{ -font-size: 11px; -} - -.text_class2081 -{ -} - -.paragraph_class2082 -{ -} - -.text_class2083 -{ -font-size: 11px; -} - -.text_class2084 -{ -} - -.paragraph_class2085 -{ -} - -.text_class2086 -{ -font-size: 11px; -} - -.text_class2087 -{ -} - -.paragraph_class2088 -{ -} - -.text_class2089 -{ -font-size: 11px; -} - -.text_class2090 -{ -} - -.paragraph_class2091 -{ -} - -.text_class2092 -{ -font-size: 11px; -} - -.paragraph_class2093 -{ -} - -.text_class2094 -{ -font-size: 11px; -} - -.paragraph_class2095 -{ -} - -.text_class2096 -{ -font-size: 11px; -} - -.text_class2097 -{ -} - -.paragraph_class2098 -{ -} - -.text_class2099 -{ -font-size: 11px; -} - -.text_class2100 -{ -} - -.paragraph_class2101 -{ -} - -.text_class2102 -{ -font-size: 11px; -} - -.paragraph_class2103 -{ -} - -.text_class2104 -{ -font-size: 11px; -} - -.paragraph_class2105 -{ -} - -.text_class2106 -{ -font-size: 11px; -} - -.paragraph_class2107 -{ -} - -.text_class2108 -{ -font-size: 11px; -} - -.paragraph_class2109 -{ -} - -.text_class2110 -{ -font-size: 11px; -} - -.paragraph_class2111 -{ -} - -.text_class2112 -{ -font-size: 11px; -} - -.text_class2113 -{ -} - -.paragraph_class2114 -{ -} - -.text_class2115 -{ -font-size: 11px; -} - -.text_class2116 -{ -} - -.paragraph_class2117 -{ -} - -.text_class2118 -{ -font-size: 11px; -} - -.text_class2119 -{ -} - -.paragraph_class2120 -{ -} - -.text_class2121 -{ -font-size: 11px; -} - -.text_class2122 -{ -} - -.paragraph_class2123 -{ -} - -.text_class2124 -{ -font-size: 11px; -} - -.text_class2125 -{ -} - -.paragraph_class2126 -{ -} - -.text_class2127 -{ -font-size: 11px; -} - -.paragraph_class2128 -{ -} - -.text_class2129 -{ -font-size: 11px; -} - -.paragraph_class2130 -{ -} - -.text_class2131 -{ -font-size: 11px; -} - -.paragraph_class2132 -{ -} - -.text_class2133 -{ -font-size: 11px; -} - -.text_class2134 -{ -} - -.paragraph_class2135 -{ -} - -.text_class2136 -{ -font-size: 11px; -} - -.paragraph_class2137 -{ -} - -.text_class2138 -{ -font-size: 11px; -} - -.paragraph_class2139 -{ -} - -.text_class2140 -{ -font-size: 11px; -} - -.text_class2141 -{ -} - -.paragraph_class2142 -{ -} - -.text_class2143 -{ -font-size: 11px; -} - -.paragraph_class2144 -{ -} - -.text_class2145 -{ -font-size: 11px; -} - -.paragraph_class2146 -{ -} - -.text_class2147 -{ -font-size: 11px; -} - -.paragraph_class2148 -{ -} - -.text_class2149 -{ -font-size: 11px; -} - -.paragraph_class2150 -{ -} - -.text_class2151 -{ -font-size: 11px; -} - -.text_class2152 -{ -} - -.paragraph_class2153 -{ -} - -.text_class2154 -{ -font-size: 11px; -} - -.text_class2155 -{ -} - -.paragraph_class2156 -{ -} - -.text_class2157 -{ -font-size: 11px; -} - -.text_class2158 -{ -} - -.paragraph_class2159 -{ -} - -.text_class2160 -{ -font-size: 11px; -} - -.text_class2161 -{ -} - -.paragraph_class2162 -{ -} - -.text_class2163 -{ -font-size: 11px; -} - -.text_class2164 -{ -} - -.paragraph_class2165 -{ -} - -.text_class2166 -{ -font-size: 11px; -} - -.text_class2167 -{ -} - -.paragraph_class2168 -{ -} - -.text_class2169 -{ -font-size: 11px; -} - -.text_class2170 -{ -} - -.paragraph_class2171 -{ -} - -.text_class2172 -{ -font-size: 11px; -} - -.text_class2173 -{ -} - -.paragraph_class2174 -{ -} - -.text_class2175 -{ -font-size: 11px; -} - -.text_class2176 -{ -} - -.paragraph_class2177 -{ -} - -.text_class2178 -{ -font-size: 11px; -} - -.paragraph_class2179 -{ -} - -.text_class2180 -{ -font-size: 11px; -} - -.paragraph_class2181 -{ -} - -.text_class2182 -{ -font-size: 11px; -} - -.paragraph_class2183 -{ -} - -.text_class2184 -{ -font-size: 11px; -} - -.paragraph_class2185 -{ -} - -.text_class2186 -{ -font-size: 11px; -} - -.text_class2187 -{ -} - -.paragraph_class2188 -{ -} - -.text_class2189 -{ -font-size: 11px; -} - -.text_class2190 -{ -} - -.paragraph_class2191 -{ -} - -.text_class2192 -{ -font-size: 11px; -} - -.text_class2193 -{ -} - -.paragraph_class2194 -{ -} - -.text_class2195 -{ -font-size: 11px; -} - -.text_class2196 -{ -} - -.paragraph_class2197 -{ -} - -.text_class2198 -{ -font-size: 11px; -} - -.text_class2199 -{ -} - -.paragraph_class2200 -{ -} - -.text_class2201 -{ -font-size: 11px; -} - -.text_class2202 -{ -} - -.paragraph_class2203 -{ -} - -.text_class2204 -{ -font-size: 11px; -} - -.text_class2205 -{ -} - -.paragraph_class2206 -{ -} - -.text_class2207 -{ -font-size: 11px; -} - -.text_class2208 -{ -} - -.paragraph_class2209 -{ -} - -.text_class2210 -{ -font-size: 11px; -} - -.text_class2211 -{ -} - -.paragraph_class2212 -{ -} - -.text_class2213 -{ -font-size: 11px; -} - -.paragraph_class2214 -{ -} - -.text_class2215 -{ -font-size: 11px; -} - -.text_class2216 -{ -} - -.paragraph_class2217 -{ -} - -.text_class2218 -{ -font-size: 11px; -} - -.text_class2219 -{ -} - -.paragraph_class2220 -{ -} - -.text_class2221 -{ -font-size: 11px; -} - -.text_class2222 -{ -} - -.paragraph_class2223 -{ -} - -.text_class2224 -{ -font-size: 11px; -} - -.text_class2225 -{ -} - -.paragraph_class2226 -{ -} - -.text_class2227 -{ -font-size: 11px; -} - -.text_class2228 -{ -} - -.paragraph_class2229 -{ -} - -.text_class2230 -{ -font-size: 11px; -} - -.text_class2231 -{ -} - -.paragraph_class2232 -{ -} - -.text_class2233 -{ -font-size: 11px; -} - -.text_class2234 -{ -} - -.paragraph_class2235 -{ -} - -.text_class2236 -{ -font-size: 11px; -} - -.text_class2237 -{ -} - -.paragraph_class2238 -{ -} - -.text_class2239 -{ -font-size: 11px; -} - -.text_class2240 -{ -} - -.paragraph_class2241 -{ -} - -.text_class2242 -{ -font-size: 11px; -} - -.text_class2243 -{ -} - -.paragraph_class2244 -{ -} - -.text_class2245 -{ -font-size: 11px; -} - -.text_class2246 -{ -} - -.paragraph_class2247 -{ -} - -.text_class2248 -{ -font-size: 11px; -} - -.text_class2249 -{ -} - -.paragraph_class2250 -{ -} - -.text_class2251 -{ -font-size: 11px; -} - -.text_class2252 -{ -} - -.paragraph_class2253 -{ -} - -.text_class2254 -{ -font-size: 11px; -} - -.paragraph_class2255 -{ -} - -.text_class2256 -{ -font-size: 11px; -} - -.text_class2257 -{ -} - -.paragraph_class2258 -{ -} - -.text_class2259 -{ -font-size: 11px; -} - -.text_class2260 -{ -} - -.paragraph_class2261 -{ -} - -.text_class2262 -{ -font-size: 11px; -} - -.text_class2263 -{ -} - -.paragraph_class2264 -{ -} - -.text_class2265 -{ -font-size: 11px; -} - -.text_class2266 -{ -} - -.paragraph_class2267 -{ -} - -.text_class2268 -{ -font-size: 11px; -} - -.paragraph_class2269 -{ -} - -.text_class2270 -{ -font-size: 11px; -} - -.paragraph_class2271 -{ -} - -.text_class2272 -{ -font-size: 11px; -} - -.text_class2273 -{ -} - -.paragraph_class2274 -{ -} - -.text_class2275 -{ -font-size: 11px; -} - -.text_class2276 -{ -} - -.paragraph_class2277 -{ -} - -.text_class2278 -{ -font-size: 11px; -} - -.text_class2279 -{ -} - -.paragraph_class2280 -{ -} - -.text_class2281 -{ -font-size: 11px; -} - -.text_class2282 -{ -} - -.paragraph_class2283 -{ -} - -.text_class2284 -{ -font-size: 11px; -} - -.text_class2285 -{ -} - -.paragraph_class2286 -{ -} - -.text_class2287 -{ -font-size: 11px; -} - -.text_class2288 -{ -} - -.paragraph_class2289 -{ -} - -.text_class2290 -{ -font-size: 11px; -} - -.text_class2291 -{ -} - -.paragraph_class2292 -{ -} - -.text_class2293 -{ -font-size: 11px; -} - -.text_class2294 -{ -} - -.paragraph_class2295 -{ -} - -.text_class2296 -{ -font-size: 11px; -} - -.text_class2297 -{ -} - -.paragraph_class2298 -{ -} - -.text_class2299 -{ -font-size: 11px; -} - -.text_class2300 -{ -} - -.paragraph_class2301 -{ -} - -.text_class2302 -{ -font-size: 11px; -} - -.text_class2303 -{ -} - -.paragraph_class2304 -{ -} - -.text_class2305 -{ -font-size: 11px; -} - -.text_class2306 -{ -} - -.paragraph_class2307 -{ -} - -.text_class2308 -{ -font-size: 11px; -} - -.text_class2309 -{ -} - -.text_class2310 -{ -} - -.paragraph_class2311 -{ -} - -.text_class2312 -{ -font-size: 11px; -} - -.paragraph_class2313 -{ -} - -.paragraph_class2314 -{ -} - -.text_class2315 -{ -font-size: 11px; -} - -.text_class2316 -{ -font-family: arial; -} - -.paragraph_class2317 -{ -} - -.text_class2318 -{ -font-size: 11px; -} - -.text_class2319 -{ -font-family: arial; -} - -.text_class2320 -{ -} - -.text_class2321 -{ -} - -.paragraph_class2322 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2323 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2324 -{ -} - -.paragraph_class2325 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2326 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2327 -{ -} - -.paragraph_class2328 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2329 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2330 -{ -} - -.paragraph_class2332 -{ -margin-left: 0px; -} - -.text_class2333 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2334 -{ -font-weight: bold; -} - -.paragraph_class2336 -{ -margin-left: 0px; -} - -.text_class2337 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2338 -{ -font-weight: bold; -} - -.paragraph_class2340 -{ -margin-left: 0px; -} - -.text_class2341 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2342 -{ -font-weight: bold; -} - -.paragraph_class2343 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2344 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2345 -{ -margin-left: 0px; -} - -.text_class2346 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2347 -{ -margin-left: 0px; -} - -.text_class2348 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2349 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2350 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2351 -{ -margin-left: 0px; -} - -.text_class2352 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2353 -{ -margin-left: 0px; -} - -.text_class2354 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2355 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2356 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2357 -{ -margin-left: 0px; -} - -.text_class2358 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2359 -{ -margin-left: 0px; -} - -.text_class2360 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2361 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2362 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2363 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2364 -{ -margin-left: 0px; -} - -.text_class2365 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2366 -{ -margin-left: 0px; -} - -.text_class2367 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2368 -{ -} - -.text_class2369 -{ -font-size: 11px; -} - -.text_class2370 -{ -} - -.text_class2371 -{ -font-size: 11px; -} - -.text_class2372 -{ -} - -.paragraph_class2373 -{ -} - -.text_class2374 -{ -font-family: arial; -} - -.text_class2375 -{ -font-size: 11px; -} - -.paragraph_class2376 -{ -} - -.text_class2377 -{ -font-family: arial; -} - -.text_class2378 -{ -font-size: 11px; -} - -.text_class2379 -{ -} - -.paragraph_class2380 -{ -} - -.text_class2381 -{ -font-family: arial; -} - -.text_class2382 -{ -font-size: 11px; -} - -.paragraph_class2383 -{ -} - -.text_class2384 -{ -font-family: arial; -} - -.text_class2385 -{ -font-size: 11px; -} - -.paragraph_class2386 -{ -} - -.text_class2387 -{ -font-family: arial; -} - -.text_class2388 -{ -font-size: 11px; -} - -.text_class2389 -{ -} - -.paragraph_class2390 -{ -} - -.text_class2391 -{ -font-family: arial; -} - -.text_class2392 -{ -font-size: 11px; -} - -.paragraph_class2393 -{ -} - -.text_class2394 -{ -font-family: arial; -} - -.text_class2395 -{ -font-size: 11px; -} - -.text_class2396 -{ -} - -.paragraph_class2397 -{ -} - -.text_class2398 -{ -font-family: arial; -} - -.text_class2399 -{ -font-size: 11px; -} - -.text_class2400 -{ -} - -.paragraph_class2401 -{ -} - -.text_class2402 -{ -font-family: arial; -} - -.text_class2403 -{ -font-size: 11px; -} - -.paragraph_class2404 -{ -} - -.text_class2405 -{ -font-family: arial; -} - -.text_class2406 -{ -font-size: 11px; -} - -.text_class2407 -{ -} - -.paragraph_class2408 -{ -} - -.text_class2409 -{ -font-family: arial; -} - -.text_class2410 -{ -font-size: 11px; -} - -.paragraph_class2411 -{ -} - -.text_class2412 -{ -font-family: arial; -} - -.text_class2413 -{ -font-size: 11px; -} - -.text_class2414 -{ -font-family: arial; -} - -.text_class2415 -{ -font-size: 11px; -} - -.text_class2416 -{ -font-family: arial; -} - -.text_class2417 -{ -font-size: 11px; -} - -.paragraph_class2418 -{ -} - -.text_class2419 -{ -font-family: arial; -} - -.text_class2420 -{ -font-size: 11px; -} - -.text_class2421 -{ -} - -.text_class2422 -{ -} - -.paragraph_class2423 -{ -} - -.text_class2424 -{ -font-family: arial; -} - -.text_class2425 -{ -font-size: 11px; -} - -.text_class2426 -{ -} - -.paragraph_class2427 -{ -} - -.text_class2428 -{ -font-family: arial; -} - -.text_class2429 -{ -font-size: 11px; -} - -.text_class2430 -{ -} - -.paragraph_class2431 -{ -} - -.text_class2432 -{ -font-family: arial; -} - -.text_class2433 -{ -font-size: 11px; -} - -.paragraph_class2434 -{ -} - -.text_class2435 -{ -font-family: arial; -} - -.text_class2436 -{ -font-size: 11px; -} - -.text_class2437 -{ -} - -.paragraph_class2438 -{ -} - -.text_class2439 -{ -font-family: arial; -} - -.text_class2440 -{ -font-size: 11px; -} - -.paragraph_class2441 -{ -} - -.text_class2442 -{ -font-family: arial; -} - -.text_class2443 -{ -font-size: 11px; -} - -.text_class2444 -{ -} - -.paragraph_class2445 -{ -} - -.text_class2446 -{ -font-family: arial; -} - -.text_class2447 -{ -font-size: 11px; -} - -.paragraph_class2448 -{ -} - -.text_class2449 -{ -font-family: arial; -} - -.text_class2450 -{ -font-size: 11px; -} - -.text_class2451 -{ -} - -.text_class2452 -{ -} - -.paragraph_class2453 -{ -} - -.text_class2454 -{ -font-family: arial; -} - -.text_class2455 -{ -font-size: 11px; -} - -.paragraph_class2456 -{ -} - -.text_class2457 -{ -font-family: arial; -} - -.text_class2458 -{ -font-size: 11px; -} - -.text_class2459 -{ -} - -.paragraph_class2460 -{ -} - -.text_class2461 -{ -font-family: arial; -} - -.text_class2462 -{ -font-size: 11px; -} - -.text_class2463 -{ -} - -.text_class2464 -{ -} - -.paragraph_class2465 -{ -} - -.text_class2466 -{ -font-family: arial; -} - -.text_class2467 -{ -font-size: 11px; -} - -.text_class2468 -{ -} - -.text_class2469 -{ -} - -.paragraph_class2470 -{ -} - -.text_class2471 -{ -font-size: 11px; -} - -.text_class2472 -{ -} - -.text_class2473 -{ -} - -.paragraph_class2474 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2475 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2476 -{ -} - -.paragraph_class2477 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2478 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2479 -{ -} - -.paragraph_class2481 -{ -margin-left: 0px; -} - -.text_class2482 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2483 -{ -font-weight: bold; -} - -.cell_class2484 -{ -width: 95px; -} - -.paragraph_class2486 -{ -margin-left: 0px; -} - -.text_class2487 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2488 -{ -font-weight: bold; -} - -.cell_class2489 -{ -width: 140px; -} - -.paragraph_class2491 -{ -margin-left: 0px; -} - -.text_class2492 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2493 -{ -font-weight: bold; -} - -.cell_class2494 -{ -width: 301px; -} - -.paragraph_class2496 -{ -margin-left: 0px; -} - -.text_class2497 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2498 -{ -font-weight: bold; -} - -.paragraph_class2499 -{ -margin-left: 0px; -} - -.text_class2500 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2501 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2502 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2503 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2504 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2505 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2506 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2507 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2508 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2509 -{ -margin-left: 0px; -} - -.text_class2510 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2511 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2512 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2513 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2514 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2515 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2516 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2517 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2518 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2519 -{ -margin-left: 0px; -} - -.text_class2520 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2521 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2522 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2523 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2524 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2525 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2526 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2527 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2528 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2529 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2530 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2531 -{ -margin-left: 0px; -} - -.text_class2532 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2533 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2534 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2535 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2536 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2537 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2538 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2539 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2540 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2541 -{ -} - -.paragraph_class2542 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2543 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2544 -{ -} - -.paragraph_class2545 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2546 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2547 -{ -font-weight: bold; -} - -.text_class2548 -{ -} - -.paragraph_class2550 -{ -margin-left: 0px; -} - -.text_class2551 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2552 -{ -font-weight: bold; -} - -.paragraph_class2554 -{ -margin-left: 0px; -} - -.text_class2555 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2556 -{ -font-weight: bold; -} - -.paragraph_class2558 -{ -margin-left: 0px; -} - -.text_class2559 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2560 -{ -font-weight: bold; -} - -.paragraph_class2561 -{ -margin-left: 0px; -} - -.text_class2562 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2563 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2564 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2565 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2566 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2567 -{ -margin-left: 0px; -} - -.text_class2568 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2569 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2570 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2571 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2572 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2573 -{ -} - -.text_class2574 -{ -} - -.text_class2575 -{ -} - -.paragraph_class2576 -{ -} - -.text_class2577 -{ -font-family: arial; -} - -.text_class2578 -{ -font-size: 11px; -} - -.paragraph_class2579 -{ -} - -.text_class2580 -{ -font-family: arial; -} - -.text_class2581 -{ -font-size: 11px; -} - -.text_class2582 -{ -} - -.text_class2583 -{ -} - -.paragraph_class2584 -{ -} - -.text_class2585 -{ -font-family: arial; -} - -.text_class2586 -{ -font-size: 11px; -} - -.text_class2587 -{ -} - -.paragraph_class2588 -{ -} - -.text_class2589 -{ -font-family: arial; -} - -.text_class2590 -{ -font-size: 11px; -} - -.paragraph_class2591 -{ -} - -.text_class2592 -{ -font-family: arial; -} - -.text_class2593 -{ -font-size: 11px; -} - -.paragraph_class2594 -{ -} - -.text_class2595 -{ -font-family: arial; -} - -.text_class2596 -{ -font-size: 11px; -} - -.text_class2597 -{ -} - -.paragraph_class2598 -{ -} - -.text_class2599 -{ -font-family: arial; -} - -.text_class2600 -{ -font-size: 11px; -} - -.text_class2601 -{ -} - -.paragraph_class2602 -{ -} - -.text_class2603 -{ -font-family: arial; -} - -.text_class2604 -{ -font-size: 11px; -} - -.text_class2605 -{ -} - -.paragraph_class2606 -{ -} - -.text_class2607 -{ -font-family: arial; -} - -.text_class2608 -{ -font-size: 11px; -} - -.paragraph_class2609 -{ -} - -.text_class2610 -{ -font-family: arial; -} - -.text_class2611 -{ -font-size: 11px; -} - -.text_class2612 -{ -} - -.text_class2613 -{ -} - -.text_class2614 -{ -} - -.text_class2615 -{ -} - -.paragraph_class2616 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2617 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2618 -{ -} - -.text_class2619 -{ -} - -.paragraph_class2620 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2621 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2622 -{ -} - -.paragraph_class2623 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2624 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2625 -{ -} - -.paragraph_class2626 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2627 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2628 -{ -} - -.paragraph_class2629 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2630 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2631 -{ -} - -.text_class2632 -{ -} - -.paragraph_class2633 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2634 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2635 -{ -font-weight: bold; -} - -.text_class2636 -{ -} - -.text_class2637 -{ -} - -.paragraph_class2638 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2639 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2640 -{ -} - -.text_class2641 -{ -} - -.paragraph_class2642 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2643 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2644 -{ -font-weight: bold; -} - -.text_class2645 -{ -} - -.text_class2646 -{ -} - -.paragraph_class2647 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2648 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2649 -{ -} - -.text_class2650 -{ -} - -.paragraph_class2651 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2652 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2653 -{ -font-weight: bold; -} - -.text_class2654 -{ -} - -.text_class2655 -{ -} - -.paragraph_class2656 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2657 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2658 -{ -font-weight: bold; -} - -.text_class2659 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2660 -{ -} - -.paragraph_class2661 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2662 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2663 -{ -font-weight: bold; -} - -.text_class2664 -{ -} - -.paragraph_class2666 -{ -margin-left: 0px; -} - -.text_class2667 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2668 -{ -font-weight: bold; -} - -.paragraph_class2670 -{ -margin-left: 0px; -} - -.text_class2671 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2672 -{ -font-weight: bold; -} - -.paragraph_class2674 -{ -margin-left: 0px; -} - -.text_class2675 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2676 -{ -font-weight: bold; -} - -.paragraph_class2677 -{ -margin-left: 0px; -} - -.text_class2678 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2679 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2680 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2681 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2682 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2683 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2684 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2685 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2686 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2687 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2688 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2689 -{ -margin-left: 0px; -} - -.text_class2690 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2691 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2692 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2693 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2694 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2695 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2696 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2697 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2698 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2699 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2700 -{ -margin-left: 0px; -} - -.text_class2701 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2702 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2703 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2704 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2705 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2706 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2707 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2708 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2709 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2710 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2711 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2712 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2713 -{ -margin-left: 0px; -} - -.text_class2714 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2715 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2716 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2717 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2718 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class2719 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class2720 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2721 -{ -} - -.text_class2722 -{ -} - -.text_class2723 -{ -font-size: 11px; -} - -.text_class2724 -{ -} - -.paragraph_class2725 -{ -} - -.text_class2726 -{ -font-family: arial; -} - -.text_class2727 -{ -font-size: 11px; -} - -.text_class2728 -{ -} - -.paragraph_class2729 -{ -} - -.text_class2730 -{ -font-family: arial; -} - -.text_class2731 -{ -font-size: 11px; -} - -.text_class2732 -{ -} - -.paragraph_class2733 -{ -} - -.text_class2734 -{ -font-family: arial; -} - -.text_class2735 -{ -font-size: 11px; -} - -.text_class2736 -{ -} - -.paragraph_class2737 -{ -} - -.text_class2738 -{ -font-family: arial; -} - -.text_class2739 -{ -font-size: 11px; -} - -.text_class2740 -{ -} - -.text_class2741 -{ -font-size: 11px; -} - -.text_class2742 -{ -} - -.paragraph_class2743 -{ -} - -.text_class2744 -{ -font-family: arial; -} - -.text_class2745 -{ -font-size: 11px; -} - -.text_class2746 -{ -} - -.paragraph_class2747 -{ -} - -.text_class2748 -{ -font-family: arial; -} - -.text_class2749 -{ -font-size: 11px; -} - -.paragraph_class2750 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2751 -{ -font-size: 11px; -} - -.text_class2752 -{ -font-family: arial; -} - -.text_class2753 -{ -font-size: 11px; -} - -.paragraph_class2754 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2755 -{ -font-size: 11px; -} - -.text_class2756 -{ -font-family: arial; -} - -.text_class2757 -{ -font-size: 11px; -} - -.paragraph_class2758 -{ -} - -.text_class2759 -{ -font-family: arial; -} - -.text_class2760 -{ -font-size: 11px; -} - -.text_class2761 -{ -} - -.paragraph_class2762 -{ -} - -.text_class2763 -{ -font-family: arial; -} - -.text_class2764 -{ -font-size: 11px; -} - -.text_class2765 -{ -} - -.paragraph_class2766 -{ -} - -.text_class2767 -{ -font-family: arial; -} - -.text_class2768 -{ -font-size: 11px; -} - -.text_class2769 -{ -} - -.paragraph_class2770 -{ -} - -.text_class2771 -{ -font-family: arial; -} - -.text_class2772 -{ -font-size: 11px; -} - -.paragraph_class2773 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2774 -{ -font-size: 11px; -} - -.text_class2775 -{ -font-family: arial; -} - -.text_class2776 -{ -font-size: 11px; -} - -.paragraph_class2777 -{ -} - -.text_class2778 -{ -font-family: arial; -} - -.text_class2779 -{ -font-size: 11px; -} - -.text_class2780 -{ -} - -.paragraph_class2781 -{ -} - -.text_class2782 -{ -font-family: arial; -} - -.text_class2783 -{ -font-size: 11px; -} - -.text_class2784 -{ -} - -.paragraph_class2785 -{ -} - -.text_class2786 -{ -font-family: arial; -} - -.text_class2787 -{ -font-size: 11px; -} - -.text_class2788 -{ -} - -.paragraph_class2789 -{ -} - -.text_class2790 -{ -font-family: arial; -} - -.text_class2791 -{ -font-size: 11px; -} - -.text_class2792 -{ -} - -.text_class2793 -{ -font-size: 11px; -} - -.text_class2794 -{ -} - -.paragraph_class2795 -{ -} - -.text_class2796 -{ -font-family: arial; -} - -.text_class2797 -{ -font-size: 11px; -} - -.paragraph_class2798 -{ -} - -.text_class2799 -{ -font-family: arial; -} - -.text_class2800 -{ -font-size: 11px; -} - -.text_class2801 -{ -} - -.paragraph_class2802 -{ -} - -.text_class2803 -{ -font-family: arial; -} - -.text_class2804 -{ -font-size: 11px; -} - -.paragraph_class2805 -{ -} - -.text_class2806 -{ -font-family: arial; -} - -.text_class2807 -{ -font-size: 11px; -} - -.text_class2808 -{ -} - -.paragraph_class2809 -{ -} - -.text_class2810 -{ -font-family: arial; -} - -.text_class2811 -{ -font-size: 11px; -} - -.paragraph_class2812 -{ -} - -.text_class2813 -{ -font-family: arial; -} - -.text_class2814 -{ -font-size: 11px; -} - -.paragraph_class2815 -{ -} - -.text_class2816 -{ -font-family: arial; -} - -.text_class2817 -{ -font-size: 11px; -} - -.text_class2818 -{ -} - -.paragraph_class2819 -{ -} - -.text_class2820 -{ -font-family: arial; -} - -.text_class2821 -{ -font-size: 11px; -} - -.paragraph_class2822 -{ -} - -.text_class2823 -{ -font-family: arial; -} - -.text_class2824 -{ -font-size: 11px; -} - -.text_class2825 -{ -} - -.text_class2826 -{ -font-size: 11px; -} - -.text_class2827 -{ -} - -.paragraph_class2828 -{ -} - -.text_class2829 -{ -font-family: arial; -} - -.text_class2830 -{ -font-size: 11px; -} - -.text_class2831 -{ -} - -.paragraph_class2832 -{ -} - -.text_class2833 -{ -font-family: arial; -} - -.text_class2834 -{ -font-size: 11px; -} - -.paragraph_class2835 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2836 -{ -font-size: 11px; -} - -.text_class2837 -{ -font-family: arial; -} - -.text_class2838 -{ -font-size: 11px; -} - -.paragraph_class2839 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2840 -{ -font-size: 11px; -} - -.text_class2841 -{ -font-family: arial; -} - -.text_class2842 -{ -font-size: 11px; -} - -.paragraph_class2843 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2844 -{ -font-size: 11px; -} - -.text_class2845 -{ -font-family: arial; -} - -.text_class2846 -{ -font-size: 11px; -} - -.paragraph_class2847 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class2848 -{ -font-size: 11px; -} - -.text_class2849 -{ -font-family: arial; -} - -.text_class2850 -{ -font-size: 11px; -} - -.text_class2851 -{ -} - -.paragraph_class2852 -{ -} - -.text_class2853 -{ -font-family: arial; -} - -.text_class2854 -{ -font-size: 11px; -} - -.text_class2855 -{ -} - -.text_class2856 -{ -} - -.paragraph_class2857 -{ -} - -.text_class2858 -{ -font-size: 11px; -} - -.text_class2859 -{ -font-family: arial; -} - -.text_class2860 -{ -} - -.text_class2861 -{ -} - -.paragraph_class2862 -{ -} - -.text_class2863 -{ -font-size: 11px; -} - -.text_class2864 -{ -font-family: arial; -} - -.text_class2865 -{ -font-family: arial; -} - -.text_class2866 -{ -font-family: arial; -} - -.paragraph_class2867 -{ -} - -.paragraph_class2868 -{ -} - -.text_class2869 -{ -font-size: 11px; -} - -.text_class2870 -{ -font-family: arial; -} - -.text_class2871 -{ -} - -.text_class2872 -{ -} - -.paragraph_class2873 -{ -text-align: center; -margin-left: 0px; -} - -.text_class2874 -{ -font-size: 11px; -font-family: arial; -} - -.text_class2875 -{ -font-weight: bold; -} - -.text_class2876 -{ -} - -.text_class2877 -{ -} - -.paragraph_class2878 -{ -} - -.text_class2879 -{ -font-size: 11px; -} - -.text_class2880 -{ -font-family: arial; -} - -.text_class2881 -{ -font-size: 11px; -} - -.text_class2882 -{ -font-family: arial; -} - -.text_class2883 -{ -font-size: 11px; -} - -.text_class2884 -{ -font-family: arial; -} - -.text_class2885 -{ -font-family: arial; -} - -.text_class2886 -{ -} - -.paragraph_class2887 -{ -} - -.text_class2888 -{ -font-family: arial; -} - -.text_class2889 -{ -font-size: 11px; -} - -.text_class2890 -{ -font-family: arial; -} - -.text_class2891 -{ -font-size: 11px; -} - -.text_class2892 -{ -font-family: arial; -} - -.text_class2893 -{ -font-size: 11px; -} - -.text_class2894 -{ -font-family: arial; -} - -.text_class2895 -{ -font-size: 11px; -} - -.text_class2896 -{ -font-family: arial; -} - -.text_class2897 -{ -font-size: 11px; -} - -.text_class2898 -{ -font-family: arial; -} - -.text_class2899 -{ -font-size: 11px; -} - -.text_class2900 -{ -font-family: arial; -} - -.text_class2901 -{ -font-size: 11px; -} - -.text_class2902 -{ -font-family: arial; -} - -.text_class2903 -{ -font-size: 11px; -} - -.text_class2904 -{ -font-family: arial; -} - -.text_class2905 -{ -font-size: 11px; -} - -.text_class2906 -{ -} - -.paragraph_class2907 -{ -} - -.text_class2908 -{ -font-family: arial; -} - -.text_class2909 -{ -font-size: 11px; -} - -.text_class2910 -{ -font-family: arial; -} - -.text_class2911 -{ -font-size: 11px; -} - -.text_class2912 -{ -font-family: arial; -} - -.text_class2913 -{ -font-size: 11px; -} - -.text_class2914 -{ -font-family: arial; -} - -.text_class2915 -{ -font-size: 11px; -} - -.text_class2916 -{ -font-family: arial; -} - -.text_class2917 -{ -font-size: 11px; -} - -.text_class2918 -{ -} - -.paragraph_class2919 -{ -} - -.text_class2920 -{ -font-family: arial; -} - -.text_class2921 -{ -font-size: 11px; -} - -.text_class2922 -{ -} - -.paragraph_class2923 -{ -} - -.text_class2924 -{ -font-family: arial; -} - -.text_class2925 -{ -font-size: 11px; -} - -.text_class2926 -{ -font-family: arial; -} - -.text_class2927 -{ -font-size: 11px; -} - -.text_class2928 -{ -font-family: arial; -} - -.text_class2929 -{ -font-size: 11px; -} - -.text_class2930 -{ -font-family: arial; -} - -.text_class2931 -{ -font-size: 11px; -} - -.text_class2932 -{ -} - -.paragraph_class2933 -{ -} - -.text_class2934 -{ -font-family: arial; -} - -.text_class2935 -{ -font-size: 11px; -} - -.text_class2936 -{ -font-family: arial; -} - -.text_class2937 -{ -font-size: 11px; -} - -.text_class2938 -{ -font-family: arial; -} - -.text_class2939 -{ -font-size: 11px; -} - -.text_class2940 -{ -font-family: arial; -} - -.text_class2941 -{ -font-size: 11px; -} - -.text_class2942 -{ -font-family: arial; -} - -.text_class2943 -{ -font-size: 11px; -} - -.text_class2944 -{ -font-family: arial; -} - -.text_class2945 -{ -font-size: 11px; -} - -.paragraph_class2946 -{ -} - -.paragraph_class2947 -{ -} - -.text_class2948 -{ -font-family: arial; -} - -.text_class2949 -{ -font-size: 11px; -} - -.text_class2950 -{ -font-family: arial; -} - -.text_class2951 -{ -font-size: 11px; -} - -.text_class2952 -{ -font-family: arial; -} - -.text_class2953 -{ -font-size: 11px; -} - -.text_class2954 -{ -font-family: arial; -} - -.text_class2955 -{ -font-size: 11px; -} - -.text_class2956 -{ -font-family: arial; -} - -.text_class2957 -{ -font-size: 11px; -} - -.text_class2958 -{ -font-family: arial; -} - -.text_class2959 -{ -font-size: 11px; -} - -.text_class2960 -{ -} - -.paragraph_class2961 -{ -} - -.text_class2962 -{ -font-family: arial; -} - -.text_class2963 -{ -font-size: 11px; -} - -.text_class2964 -{ -} - -.paragraph_class2965 -{ -} - -.text_class2966 -{ -font-family: arial; -} - -.text_class2967 -{ -font-size: 11px; -} - -.text_class2968 -{ -} - -.paragraph_class2969 -{ -} - -.text_class2970 -{ -font-family: arial; -} - -.text_class2971 -{ -font-size: 11px; -} - -.text_class2972 -{ -} - -.paragraph_class2973 -{ -} - -.text_class2974 -{ -font-family: arial; -} - -.text_class2975 -{ -font-size: 11px; -} - -.text_class2976 -{ -} - -.paragraph_class2977 -{ -} - -.text_class2978 -{ -font-family: arial; -} - -.text_class2979 -{ -font-size: 11px; -} - -.text_class2980 -{ -} - -.paragraph_class2981 -{ -} - -.text_class2982 -{ -font-family: arial; -} - -.text_class2983 -{ -font-size: 11px; -} - -.text_class2984 -{ -} - -.paragraph_class2985 -{ -} - -.text_class2986 -{ -font-family: arial; -} - -.text_class2987 -{ -font-size: 11px; -} - -.text_class2988 -{ -} - -.paragraph_class2989 -{ -} - -.text_class2990 -{ -font-family: arial; -} - -.text_class2991 -{ -font-size: 11px; -} - -.text_class2992 -{ -} - -.paragraph_class2993 -{ -} - -.text_class2994 -{ -font-family: arial; -} - -.text_class2995 -{ -font-size: 11px; -} - -.text_class2996 -{ -} - -.paragraph_class2997 -{ -} - -.text_class2998 -{ -font-family: arial; -} - -.text_class2999 -{ -font-size: 11px; -} - -.text_class3000 -{ -} - -.paragraph_class3001 -{ -} - -.text_class3002 -{ -font-family: arial; -} - -.text_class3003 -{ -font-size: 11px; -} - -.text_class3004 -{ -} - -.paragraph_class3005 -{ -} - -.text_class3006 -{ -font-family: arial; -} - -.text_class3007 -{ -font-size: 11px; -} - -.text_class3008 -{ -} - -.paragraph_class3009 -{ -} - -.text_class3010 -{ -font-family: arial; -} - -.text_class3011 -{ -font-size: 11px; -} - -.text_class3012 -{ -} - -.paragraph_class3013 -{ -} - -.text_class3014 -{ -font-family: arial; -} - -.text_class3015 -{ -font-size: 11px; -} - -.text_class3016 -{ -} - -.paragraph_class3017 -{ -} - -.text_class3018 -{ -font-family: arial; -} - -.text_class3019 -{ -font-size: 11px; -} - -.text_class3020 -{ -} - -.paragraph_class3021 -{ -} - -.text_class3022 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3023 -{ -} - -.paragraph_class3024 -{ -} - -.text_class3025 -{ -font-family: arial; -} - -.text_class3026 -{ -font-size: 11px; -} - -.text_class3027 -{ -} - -.paragraph_class3028 -{ -} - -.text_class3029 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3030 -{ -} - -.text_class3031 -{ -} - -.paragraph_class3032 -{ -} - -.text_class3033 -{ -font-size: 11px; -} - -.text_class3034 -{ -} - -.text_class3035 -{ -} - -.paragraph_class3036 -{ -} - -.text_class3037 -{ -font-size: 11px; -} - -.text_class3038 -{ -} - -.paragraph_class3039 -{ -} - -.text_class3040 -{ -font-size: 11px; -} - -.text_class3041 -{ -} - -.paragraph_class3042 -{ -} - -.text_class3043 -{ -font-size: 11px; -} - -.text_class3044 -{ -font-family: arial; -} - -.text_class3045 -{ -} - -.paragraph_class3046 -{ -} - -.text_class3047 -{ -font-size: 11px; -} - -.text_class3048 -{ -font-family: arial; -} - -.text_class3049 -{ -} - -.paragraph_class3050 -{ -} - -.text_class3051 -{ -font-family: arial; -} - -.text_class3052 -{ -font-size: 11px; -} - -.paragraph_class3053 -{ -} - -.text_class3054 -{ -font-family: arial; -} - -.text_class3055 -{ -font-size: 11px; -} - -.text_class3056 -{ -font-family: arial; -} - -.text_class3057 -{ -font-size: 11px; -} - -.text_class3058 -{ -font-family: arial; -} - -.text_class3059 -{ -font-size: 11px; -} - -.text_class3060 -{ -font-family: arial; -} - -.text_class3061 -{ -font-size: 11px; -} - -.text_class3062 -{ -font-family: arial; -} - -.text_class3063 -{ -font-size: 11px; -} - -.text_class3064 -{ -font-family: arial; -} - -.text_class3065 -{ -font-size: 11px; -} - -.text_class3066 -{ -font-family: arial; -} - -.text_class3067 -{ -font-size: 11px; -} - -.text_class3068 -{ -font-family: arial; -} - -.text_class3069 -{ -font-size: 11px; -} - -.text_class3070 -{ -font-family: arial; -} - -.text_class3071 -{ -font-size: 11px; -} - -.text_class3072 -{ -font-family: arial; -} - -.text_class3073 -{ -font-size: 11px; -} - -.text_class3074 -{ -font-family: arial; -} - -.text_class3075 -{ -font-size: 11px; -} - -.text_class3076 -{ -font-family: arial; -} - -.text_class3077 -{ -font-size: 11px; -} - -.text_class3078 -{ -font-family: arial; -} - -.text_class3079 -{ -font-size: 11px; -} - -.text_class3080 -{ -font-family: arial; -} - -.text_class3081 -{ -font-size: 11px; -} - -.text_class3082 -{ -} - -.text_class3083 -{ -} - -.paragraph_class3084 -{ -} - -.text_class3085 -{ -font-size: 11px; -} - -.text_class3086 -{ -} - -.text_class3087 -{ -} - -.paragraph_class3088 -{ -} - -.text_class3089 -{ -font-size: 11px; -} - -.text_class3090 -{ -} - -.text_class3091 -{ -} - -.paragraph_class3092 -{ -} - -.text_class3093 -{ -font-family: arial; -} - -.text_class3094 -{ -font-size: 11px; -} - -.paragraph_class3095 -{ -} - -.text_class3096 -{ -font-family: arial; -} - -.text_class3097 -{ -font-size: 11px; -} - -.text_class3098 -{ -font-family: arial; -} - -.text_class3099 -{ -font-size: 11px; -} - -.text_class3100 -{ -font-family: arial; -} - -.text_class3101 -{ -font-size: 11px; -} - -.text_class3102 -{ -font-family: arial; -} - -.text_class3103 -{ -font-size: 11px; -} - -.text_class3104 -{ -font-family: arial; -} - -.text_class3105 -{ -font-size: 11px; -} - -.text_class3106 -{ -font-family: arial; -} - -.text_class3107 -{ -font-size: 11px; -} - -.text_class3108 -{ -font-family: arial; -} - -.text_class3109 -{ -font-size: 11px; -} - -.text_class3110 -{ -font-family: arial; -} - -.text_class3111 -{ -font-size: 11px; -} - -.text_class3112 -{ -font-family: arial; -} - -.text_class3113 -{ -font-size: 11px; -} - -.text_class3114 -{ -font-family: arial; -} - -.text_class3115 -{ -font-size: 11px; -} - -.text_class3116 -{ -font-family: arial; -} - -.text_class3117 -{ -font-size: 11px; -} - -.text_class3118 -{ -font-family: arial; -} - -.text_class3119 -{ -font-size: 11px; -} - -.text_class3120 -{ -font-family: arial; -} - -.text_class3121 -{ -font-size: 11px; -} - -.text_class3122 -{ -font-family: arial; -} - -.text_class3123 -{ -font-size: 11px; -} - -.text_class3124 -{ -} - -.text_class3125 -{ -} - -.paragraph_class3126 -{ -} - -.text_class3127 -{ -font-size: 11px; -} - -.text_class3128 -{ -} - -.text_class3129 -{ -} - -.paragraph_class3130 -{ -} - -.text_class3131 -{ -font-size: 11px; -} - -.text_class3132 -{ -} - -.text_class3133 -{ -} - -.paragraph_class3134 -{ -} - -.text_class3135 -{ -font-size: 11px; -} - -.text_class3136 -{ -} - -.text_class3137 -{ -} - -.paragraph_class3138 -{ -} - -.text_class3139 -{ -font-size: 11px; -} - -.text_class3140 -{ -} - -.text_class3141 -{ -} - -.paragraph_class3142 -{ -} - -.text_class3143 -{ -font-size: 11px; -} - -.paragraph_class3144 -{ -} - -.text_class3145 -{ -font-size: 11px; -} - -.paragraph_class3146 -{ -} - -.text_class3147 -{ -} - -.paragraph_class3148 -{ -} - -.text_class3149 -{ -font-size: 11px; -} - -.text_class3150 -{ -font-size: 11px; -} - -.text_class3151 -{ -font-size: 11px; -} - -.text_class3152 -{ -font-size: 11px; -} - -.text_class3153 -{ -font-size: 11px; -} - -.text_class3154 -{ -font-size: 11px; -} - -.text_class3155 -{ -font-size: 11px; -} - -.text_class3156 -{ -font-size: 11px; -} - -.paragraph_class3157 -{ -} - -.text_class3158 -{ -font-size: 11px; -} - -.text_class3159 -{ -font-size: 11px; -} - -.text_class3160 -{ -font-size: 11px; -} - -.text_class3161 -{ -} - -.paragraph_class3162 -{ -} - -.text_class3163 -{ -font-size: 11px; -} - -.text_class3164 -{ -} - -.paragraph_class3165 -{ -} - -.text_class3166 -{ -font-size: 11px; -} - -.text_class3167 -{ -} - -.paragraph_class3168 -{ -} - -.text_class3169 -{ -font-size: 11px; -} - -.text_class3170 -{ -} - -.paragraph_class3171 -{ -} - -.text_class3172 -{ -font-size: 11px; -} - -.text_class3173 -{ -} - -.paragraph_class3174 -{ -} - -.text_class3175 -{ -font-size: 11px; -} - -.paragraph_class3176 -{ -} - -.text_class3177 -{ -font-size: 11px; -} - -.paragraph_class3178 -{ -} - -.text_class3179 -{ -font-size: 11px; -} - -.paragraph_class3180 -{ -} - -.text_class3181 -{ -font-size: 11px; -} - -.paragraph_class3182 -{ -} - -.text_class3183 -{ -font-size: 11px; -} - -.paragraph_class3184 -{ -} - -.text_class3185 -{ -font-size: 11px; -} - -.paragraph_class3186 -{ -} - -.text_class3187 -{ -font-size: 11px; -} - -.text_class3188 -{ -} - -.paragraph_class3189 -{ -} - -.text_class3190 -{ -font-size: 11px; -} - -.text_class3191 -{ -} - -.paragraph_class3192 -{ -} - -.text_class3193 -{ -font-size: 11px; -} - -.text_class3194 -{ -} - -.text_class3195 -{ -} - -.paragraph_class3196 -{ -} - -.text_class3197 -{ -font-size: 11px; -} - -.paragraph_class3198 -{ -} - -.text_class3199 -{ -font-size: 11px; -} - -.paragraph_class3200 -{ -} - -.text_class3201 -{ -font-size: 11px; -} - -.paragraph_class3202 -{ -} - -.text_class3203 -{ -font-size: 11px; -} - -.text_class3204 -{ -} - -.paragraph_class3205 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3206 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3207 -{ -font-weight: bold; -} - -.text_class3208 -{ -} - -.cell_class3209 -{ -width: 53px; -background-color: #c0c0c0; -} - -.paragraph_class3211 -{ -margin-left: 0px; -} - -.paragraph_class3212 -{ -margin-left: 0px; -} - -.text_class3213 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3214 -{ -font-weight: bold; -} - -.cell_class3215 -{ -width: 340px; -background-color: #c0c0c0; -} - -.paragraph_class3217 -{ -margin-left: 0px; -} - -.text_class3218 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3219 -{ -font-weight: bold; -} - -.cell_class3220 -{ -width: 111px; -background-color: #c0c0c0; -} - -.paragraph_class3222 -{ -margin-left: 0px; -} - -.text_class3223 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3224 -{ -font-weight: bold; -} - -.cell_class3225 -{ -width: 54px; -background-color: #c0c0c0; -} - -.paragraph_class3227 -{ -margin-left: 0px; -} - -.text_class3228 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3229 -{ -font-weight: bold; -} - -.cell_class3230 -{ -width: 53px; -} - -.paragraph_class3231 -{ -margin-left: 0px; -} - -.text_class3232 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3233 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3234 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3235 -{ -width: 111px; -} - -.paragraph_class3236 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3237 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3238 -{ -width: 54px; -} - -.paragraph_class3239 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3240 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3241 -{ -margin-left: 0px; -} - -.text_class3242 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3243 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3244 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3245 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3246 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3247 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3248 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3249 -{ -margin-left: 0px; -} - -.text_class3250 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3251 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3252 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3253 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3254 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3255 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3256 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3257 -{ -margin-left: 0px; -} - -.text_class3258 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3259 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3260 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3261 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3262 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3263 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3264 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3265 -{ -margin-left: 0px; -} - -.text_class3266 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3267 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3268 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3269 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3270 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3271 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3272 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3273 -{ -margin-left: 0px; -} - -.text_class3274 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3275 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3276 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3277 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3278 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3279 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3280 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3281 -{ -margin-left: 0px; -} - -.text_class3282 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3283 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3284 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3285 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3286 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3287 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3288 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3289 -{ -margin-left: 0px; -} - -.text_class3290 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3291 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3292 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3293 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3294 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3295 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3296 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3297 -{ -margin-left: 0px; -} - -.text_class3298 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3299 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3300 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3301 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3302 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3303 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3304 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3305 -{ -margin-left: 0px; -} - -.text_class3306 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3307 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3308 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3309 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3310 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3311 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3312 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3313 -{ -margin-left: 0px; -} - -.text_class3314 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3315 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3316 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3317 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3318 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3319 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3320 -{ -font-size: 11px; -} - -.paragraph_class3321 -{ -margin-left: 0px; -} - -.text_class3322 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3323 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3324 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3325 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3326 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3327 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3328 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3329 -{ -margin-left: 0px; -} - -.text_class3330 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3331 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3332 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3333 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3334 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3335 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3336 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3337 -{ -margin-left: 0px; -} - -.text_class3338 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3339 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3340 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3341 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3342 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3343 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3344 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3345 -{ -margin-left: 0px; -} - -.text_class3346 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3347 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3348 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3349 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3350 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3351 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3352 -{ -font-size: 11px; -} - -.paragraph_class3353 -{ -margin-left: 0px; -} - -.text_class3354 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3355 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3356 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3357 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3358 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3359 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3360 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3361 -{ -margin-left: 0px; -} - -.text_class3362 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3363 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3364 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3365 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3366 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3367 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3368 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3369 -{ -margin-left: 0px; -} - -.text_class3370 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3371 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3372 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3373 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3374 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3375 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3376 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3377 -{ -margin-left: 0px; -} - -.text_class3378 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3379 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3380 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3381 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3382 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3383 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3384 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3385 -{ -margin-left: 0px; -} - -.text_class3386 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3387 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3388 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3389 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3390 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3391 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3392 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3393 -{ -margin-left: 0px; -} - -.text_class3394 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3395 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3396 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3397 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3398 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3399 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3400 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3401 -{ -margin-left: 0px; -} - -.text_class3402 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3403 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3404 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3405 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3406 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3407 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3408 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3409 -{ -margin-left: 0px; -} - -.text_class3410 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3411 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3412 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3413 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3414 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3415 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3416 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3417 -{ -margin-left: 0px; -} - -.text_class3418 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3419 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3420 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3421 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3422 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3423 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3424 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3425 -{ -margin-left: 0px; -} - -.text_class3426 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3427 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3428 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3429 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3430 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3431 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3432 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3433 -{ -} - -.paragraph_class3434 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3435 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3436 -{ -} - -.paragraph_class3437 -{ -} - -.text_class3438 -{ -font-size: 11px; -} - -.text_class3439 -{ -font-size: 11px; -} - -.text_class3440 -{ -font-size: 11px; -} - -.text_class3441 -{ -font-size: 11px; -} - -.text_class3442 -{ -font-size: 11px; -} - -.paragraph_class3443 -{ -} - -.text_class3444 -{ -font-size: 11px; -} - -.paragraph_class3445 -{ -} - -.text_class3446 -{ -font-size: 11px; -} - -.text_class3447 -{ -} - -.paragraph_class3448 -{ -} - -.text_class3449 -{ -font-size: 11px; -} - -.text_class3450 -{ -font-size: 11px; -} - -.text_class3451 -{ -font-size: 11px; -} - -.text_class3452 -{ -font-size: 11px; -} - -.text_class3453 -{ -font-size: 11px; -} - -.paragraph_class3454 -{ -} - -.text_class3455 -{ -font-size: 11px; -} - -.paragraph_class3456 -{ -} - -.text_class3457 -{ -font-size: 11px; -} - -.text_class3458 -{ -} - -.paragraph_class3459 -{ -} - -.text_class3460 -{ -font-size: 11px; -} - -.text_class3461 -{ -font-size: 11px; -} - -.text_class3462 -{ -font-size: 11px; -} - -.text_class3463 -{ -font-size: 11px; -} - -.text_class3464 -{ -font-size: 11px; -} - -.paragraph_class3465 -{ -} - -.text_class3466 -{ -font-size: 11px; -} - -.paragraph_class3467 -{ -} - -.text_class3468 -{ -font-size: 11px; -} - -.paragraph_class3469 -{ -} - -.text_class3470 -{ -} - -.text_class3471 -{ -} - -.paragraph_class3472 -{ -} - -.text_class3473 -{ -font-size: 11px; -} - -.paragraph_class3474 -{ -} - -.text_class3475 -{ -font-size: 11px; -} - -.paragraph_class3476 -{ -} - -.text_class3477 -{ -font-size: 11px; -} - -.paragraph_class3478 -{ -} - -.paragraph_class3479 -{ -} - -.text_class3480 -{ -font-size: 11px; -} - -.paragraph_class3481 -{ -} - -.paragraph_class3482 -{ -} - -.text_class3483 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3484 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3485 -{ -} - -.paragraph_class3486 -{ -} - -.text_class3487 -{ -font-size: 11px; -} - -.text_class3488 -{ -font-family: arial; -} - -.text_class3489 -{ -font-family: arial; -} - -.text_class3490 -{ -font-family: arial; -} - -.paragraph_class3491 -{ -} - -.paragraph_class3492 -{ -} - -.text_class3493 -{ -font-size: 11px; -} - -.text_class3494 -{ -font-family: arial; -} - -.text_class3495 -{ -} - -.paragraph_class3496 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3497 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3498 -{ -font-weight: bold; -} - -.text_class3499 -{ -} - -.cell_class3500 -{ -width: 43px; -background-color: #c0c0c0; -} - -.paragraph_class3502 -{ -margin-left: 0px; -} - -.text_class3503 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3504 -{ -font-weight: bold; -} - -.cell_class3505 -{ -width: 122px; -background-color: #c0c0c0; -} - -.paragraph_class3507 -{ -margin-left: 0px; -} - -.text_class3508 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3509 -{ -font-weight: bold; -} - -.cell_class3510 -{ -width: 124px; -background-color: #c0c0c0; -} - -.paragraph_class3512 -{ -margin-left: 0px; -} - -.text_class3513 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3514 -{ -font-weight: bold; -} - -.paragraph_class3516 -{ -margin-left: 0px; -} - -.text_class3517 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3518 -{ -font-weight: bold; -} - -.cell_class3519 -{ -width: 43px; -} - -.paragraph_class3520 -{ -margin-left: 0px; -} - -.text_class3521 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3522 -{ -width: 122px; -} - -.paragraph_class3523 -{ -margin-left: 0px; -} - -.text_class3524 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3525 -{ -width: 124px; -} - -.paragraph_class3526 -{ -margin-left: 0px; -} - -.text_class3527 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3528 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3529 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3530 -{ -} - -.paragraph_class3531 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3532 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3533 -{ -font-weight: bold; -} - -.text_class3534 -{ -} - -.cell_class3535 -{ -width: 39px; -background-color: #c0c0c0; -} - -.paragraph_class3537 -{ -margin-left: 0px; -} - -.text_class3538 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class3539 -{ -font-weight: bold; -} - -.cell_class3540 -{ -width: 126px; -background-color: #c0c0c0; -} - -.paragraph_class3542 -{ -margin-left: 0px; -} - -.text_class3543 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class3544 -{ -font-weight: bold; -} - -.paragraph_class3546 -{ -margin-left: 0px; -} - -.text_class3547 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class3548 -{ -font-weight: bold; -} - -.paragraph_class3550 -{ -margin-left: 0px; -} - -.text_class3551 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class3552 -{ -font-weight: bold; -} - -.cell_class3553 -{ -width: 39px; -} - -.paragraph_class3554 -{ -margin-left: 0px; -} - -.text_class3555 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class3556 -{ -width: 126px; -} - -.paragraph_class3557 -{ -margin-left: 0px; -} - -.text_class3558 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3559 -{ -margin-left: 0px; -} - -.text_class3560 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3561 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3562 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3563 -{ -margin-left: 0px; -} - -.text_class3564 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3565 -{ -margin-left: 0px; -} - -.text_class3566 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3567 -{ -margin-left: 0px; -} - -.text_class3568 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3569 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3570 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3571 -{ -margin-left: 0px; -} - -.text_class3572 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3573 -{ -margin-left: 0px; -} - -.text_class3574 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3575 -{ -margin-left: 0px; -} - -.text_class3576 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3577 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3578 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3579 -{ -margin-left: 0px; -} - -.text_class3580 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3581 -{ -margin-left: 0px; -} - -.text_class3582 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3583 -{ -margin-left: 0px; -} - -.text_class3584 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class3585 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3586 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class3587 -{ -} - -.text_class3588 -{ -} - -.paragraph_class3589 -{ -} - -.text_class3590 -{ -font-size: 11px; -} - -.paragraph_class3591 -{ -} - -.text_class3592 -{ -font-size: 11px; -} - -.paragraph_class3593 -{ -} - -.text_class3594 -{ -font-size: 11px; -} - -.paragraph_class3595 -{ -} - -.text_class3596 -{ -font-size: 11px; -} - -.text_class3597 -{ -font-size: 11px; -} - -.paragraph_class3598 -{ -} - -.text_class3599 -{ -font-size: 11px; -} - -.text_class3600 -{ -font-size: 11px; -} - -.text_class3601 -{ -font-size: 11px; -} - -.text_class3602 -{ -font-size: 11px; -} - -.text_class3603 -{ -font-size: 11px; -} - -.text_class3604 -{ -font-size: 11px; -} - -.text_class3605 -{ -} - -.paragraph_class3606 -{ -} - -.text_class3607 -{ -font-size: 11px; -} - -.text_class3608 -{ -font-size: 11px; -} - -.paragraph_class3609 -{ -} - -.paragraph_class3610 -{ -} - -.text_class3611 -{ -font-size: 11px; -} - -.paragraph_class3612 -{ -} - -.text_class3613 -{ -font-size: 11px; -} - -.text_class3614 -{ -} - -.text_class3615 -{ -} - -.paragraph_class3616 -{ -} - -.text_class3617 -{ -font-family: arial; -} - -.text_class3618 -{ -font-size: 11px; -} - -.paragraph_class3619 -{ -} - -.paragraph_class3620 -{ -} - -.text_class3621 -{ -font-family: arial; -} - -.text_class3622 -{ -font-size: 11px; -} - -.paragraph_class3623 -{ -} - -.paragraph_class3624 -{ -} - -.text_class3625 -{ -font-family: arial; -} - -.text_class3626 -{ -font-size: 11px; -} - -.text_class3627 -{ -font-family: arial; -} - -.text_class3628 -{ -font-size: 11px; -} - -.text_class3629 -{ -} - -.paragraph_class3630 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3631 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3632 -{ -font-weight: bold; -} - -.text_class3633 -{ -} - -.cell_class3634 -{ -width: 72px; -background-color: #c0c0c0; -} - -.paragraph_class3636 -{ -margin-left: 0px; -} - -.text_class3637 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3638 -{ -font-weight: bold; -} - -.cell_class3639 -{ -width: 260px; -background-color: #c0c0c0; -} - -.paragraph_class3641 -{ -margin-left: 0px; -} - -.text_class3642 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3643 -{ -font-weight: bold; -} - -.cell_class3644 -{ -width: 108px; -background-color: #c0c0c0; -} - -.paragraph_class3646 -{ -margin-left: 0px; -} - -.text_class3647 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3648 -{ -font-weight: bold; -} - -.paragraph_class3650 -{ -margin-left: 0px; -} - -.text_class3651 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3652 -{ -font-weight: bold; -} - -.cell_class3653 -{ -width: 72px; -} - -.paragraph_class3654 -{ -margin-left: 0px; -} - -.text_class3655 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3656 -{ -width: 260px; -} - -.paragraph_class3657 -{ -margin-left: 0px; -} - -.text_class3658 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3659 -{ -width: 108px; -} - -.paragraph_class3660 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3661 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3662 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3663 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3664 -{ -margin-left: 0px; -} - -.text_class3665 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3666 -{ -margin-left: 0px; -} - -.text_class3667 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3668 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3669 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3670 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3671 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3672 -{ -margin-left: 0px; -} - -.text_class3673 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3674 -{ -margin-left: 0px; -} - -.text_class3675 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3676 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3677 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3678 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3679 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3680 -{ -margin-left: 0px; -} - -.text_class3681 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3682 -{ -margin-left: 0px; -} - -.text_class3683 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3684 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3685 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3686 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3687 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3688 -{ -margin-left: 0px; -} - -.text_class3689 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3690 -{ -margin-left: 0px; -} - -.text_class3691 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3692 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3693 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3694 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3695 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3696 -{ -margin-left: 0px; -} - -.text_class3697 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3698 -{ -margin-left: 0px; -} - -.text_class3699 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3700 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3701 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3702 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3703 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3704 -{ -margin-left: 0px; -} - -.text_class3705 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3706 -{ -margin-left: 0px; -} - -.text_class3707 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3708 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3709 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3710 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3711 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3712 -{ -} - -.text_class3713 -{ -} - -.paragraph_class3714 -{ -} - -.text_class3715 -{ -font-size: 11px; -} - -.text_class3716 -{ -font-family: arial; -} - -.paragraph_class3717 -{ -} - -.paragraph_class3718 -{ -} - -.text_class3719 -{ -font-size: 11px; -} - -.text_class3720 -{ -font-family: arial; -} - -.paragraph_class3721 -{ -} - -.paragraph_class3722 -{ -} - -.text_class3723 -{ -font-size: 11px; -} - -.text_class3724 -{ -font-family: arial; -} - -.text_class3725 -{ -font-family: arial; -} - -.text_class3726 -{ -font-family: arial; -} - -.text_class3727 -{ -} - -.paragraph_class3728 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3729 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3730 -{ -font-weight: bold; -} - -.text_class3731 -{ -} - -.cell_class3732 -{ -width: 36px; -background-color: #c0c0c0; -} - -.paragraph_class3734 -{ -margin-left: 0px; -} - -.text_class3735 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3736 -{ -font-weight: bold; -} - -.cell_class3737 -{ -width: 176px; -background-color: #c0c0c0; -} - -.paragraph_class3739 -{ -margin-left: 0px; -} - -.text_class3740 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3741 -{ -font-weight: bold; -} - -.cell_class3742 -{ -width: 178px; -background-color: #c0c0c0; -} - -.paragraph_class3744 -{ -margin-left: 0px; -} - -.text_class3745 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3746 -{ -font-weight: bold; -} - -.cell_class3747 -{ -width: 49px; -background-color: #c0c0c0; -} - -.paragraph_class3749 -{ -margin-left: 0px; -} - -.text_class3750 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3751 -{ -font-weight: bold; -} - -.cell_class3752 -{ -width: 36px; -} - -.paragraph_class3753 -{ -margin-left: 0px; -} - -.text_class3754 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3755 -{ -width: 176px; -} - -.paragraph_class3756 -{ -margin-left: 0px; -} - -.text_class3757 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3758 -{ -width: 178px; -} - -.paragraph_class3759 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3760 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3761 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3762 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3763 -{ -margin-left: 0px; -} - -.text_class3764 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3765 -{ -margin-left: 0px; -} - -.text_class3766 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3767 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3768 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3769 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3770 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3771 -{ -margin-left: 0px; -} - -.text_class3772 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3773 -{ -margin-left: 0px; -} - -.text_class3774 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3775 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3776 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3777 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3778 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3779 -{ -} - -.text_class3780 -{ -} - -.paragraph_class3781 -{ -} - -.text_class3782 -{ -font-family: arial; -} - -.text_class3783 -{ -font-size: 11px; -} - -.paragraph_class3784 -{ -} - -.text_class3785 -{ -font-family: arial; -} - -.text_class3786 -{ -font-size: 11px; -} - -.paragraph_class3787 -{ -} - -.text_class3788 -{ -font-size: 11px; -} - -.text_class3789 -{ -font-family: arial; -} - -.paragraph_class3790 -{ -} - -.paragraph_class3791 -{ -} - -.text_class3792 -{ -font-size: 11px; -} - -.text_class3793 -{ -font-family: arial; -} - -.paragraph_class3794 -{ -} - -.text_class3795 -{ -font-size: 11px; -} - -.text_class3796 -{ -font-family: arial; -} - -.paragraph_class3797 -{ -} - -.text_class3798 -{ -font-size: 11px; -} - -.text_class3799 -{ -font-family: arial; -} - -.paragraph_class3800 -{ -} - -.text_class3801 -{ -font-size: 11px; -} - -.text_class3802 -{ -font-family: arial; -} - -.paragraph_class3803 -{ -} - -.text_class3804 -{ -font-size: 11px; -} - -.text_class3805 -{ -font-family: arial; -} - -.text_class3806 -{ -} - -.paragraph_class3807 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3808 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3809 -{ -font-weight: bold; -} - -.text_class3810 -{ -} - -.cell_class3811 -{ -width: 51px; -background-color: #c0c0c0; -} - -.paragraph_class3813 -{ -margin-left: 0px; -} - -.text_class3814 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3815 -{ -font-weight: bold; -} - -.cell_class3816 -{ -width: 348px; -background-color: #c0c0c0; -} - -.paragraph_class3818 -{ -margin-left: 0px; -} - -.text_class3819 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3820 -{ -font-weight: bold; -} - -.cell_class3821 -{ -width: 113px; -background-color: #c0c0c0; -} - -.paragraph_class3823 -{ -margin-left: 0px; -} - -.text_class3824 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3825 -{ -font-weight: bold; -} - -.paragraph_class3827 -{ -margin-left: 0px; -} - -.text_class3828 -{ -font-size: 11px; -font-family: arial; -} - -.text_class3829 -{ -font-weight: bold; -} - -.cell_class3830 -{ -width: 51px; -} - -.paragraph_class3831 -{ -margin-left: 0px; -} - -.text_class3832 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3833 -{ -width: 348px; -} - -.paragraph_class3834 -{ -margin-left: 0px; -} - -.text_class3835 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class3836 -{ -width: 113px; -} - -.paragraph_class3837 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3838 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3839 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3840 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3841 -{ -margin-left: 0px; -} - -.text_class3842 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3843 -{ -margin-left: 0px; -} - -.text_class3844 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3845 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3846 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3847 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3848 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3849 -{ -margin-left: 0px; -} - -.text_class3850 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3851 -{ -margin-left: 0px; -} - -.text_class3852 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3853 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3854 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3855 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3856 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3857 -{ -margin-left: 0px; -} - -.text_class3858 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3859 -{ -margin-left: 0px; -} - -.text_class3860 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3861 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3862 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3863 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3864 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3865 -{ -margin-left: 0px; -} - -.text_class3866 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3867 -{ -margin-left: 0px; -} - -.text_class3868 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3869 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3870 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3871 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3872 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3873 -{ -margin-left: 0px; -} - -.text_class3874 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3875 -{ -margin-left: 0px; -} - -.text_class3876 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3877 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3878 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3879 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3880 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3881 -{ -margin-left: 0px; -} - -.text_class3882 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3883 -{ -margin-left: 0px; -} - -.text_class3884 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3885 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3886 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3887 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3888 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3889 -{ -margin-left: 0px; -} - -.text_class3890 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3891 -{ -margin-left: 0px; -} - -.text_class3892 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3893 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3894 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3895 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3896 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3897 -{ -margin-left: 0px; -} - -.text_class3898 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3899 -{ -margin-left: 0px; -} - -.text_class3900 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3901 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3902 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3903 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3904 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3905 -{ -margin-left: 0px; -} - -.text_class3906 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3907 -{ -margin-left: 0px; -} - -.text_class3908 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3909 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3910 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3911 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3912 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3913 -{ -margin-left: 0px; -} - -.text_class3914 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3915 -{ -margin-left: 0px; -} - -.text_class3916 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3917 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3918 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3919 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3920 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3921 -{ -margin-left: 0px; -} - -.text_class3922 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3923 -{ -margin-left: 0px; -} - -.text_class3924 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3925 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3926 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3927 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3928 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3929 -{ -margin-left: 0px; -} - -.text_class3930 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3931 -{ -margin-left: 0px; -} - -.text_class3932 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3933 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3934 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3935 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3936 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3937 -{ -margin-left: 0px; -} - -.text_class3938 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3939 -{ -margin-left: 0px; -} - -.text_class3940 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3941 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3942 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3943 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3944 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3945 -{ -margin-left: 0px; -} - -.text_class3946 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3947 -{ -margin-left: 0px; -} - -.text_class3948 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3949 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3950 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3951 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3952 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3953 -{ -margin-left: 0px; -} - -.text_class3954 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3955 -{ -margin-left: 0px; -} - -.text_class3956 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3957 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3958 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3959 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3960 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3961 -{ -margin-left: 0px; -} - -.text_class3962 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3963 -{ -margin-left: 0px; -} - -.text_class3964 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3965 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3966 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3967 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3968 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3969 -{ -margin-left: 0px; -} - -.text_class3970 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3971 -{ -margin-left: 0px; -} - -.text_class3972 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3973 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3974 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3975 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3976 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3977 -{ -margin-left: 0px; -} - -.text_class3978 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3979 -{ -margin-left: 0px; -} - -.text_class3980 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3981 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3982 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3983 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3984 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3985 -{ -margin-left: 0px; -} - -.text_class3986 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3987 -{ -margin-left: 0px; -} - -.text_class3988 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3989 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3990 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3991 -{ -text-align: center; -margin-left: 0px; -} - -.text_class3992 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3993 -{ -margin-left: 0px; -} - -.text_class3994 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3995 -{ -margin-left: 0px; -} - -.text_class3996 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3997 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class3998 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class3999 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4000 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4001 -{ -margin-left: 0px; -} - -.text_class4002 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4003 -{ -margin-left: 0px; -} - -.text_class4004 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4005 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4006 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4007 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4008 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4009 -{ -margin-left: 0px; -} - -.text_class4010 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4011 -{ -margin-left: 0px; -} - -.text_class4012 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4013 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4014 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4015 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4016 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4017 -{ -margin-left: 0px; -} - -.text_class4018 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4019 -{ -margin-left: 0px; -} - -.text_class4020 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4021 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4022 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4023 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4024 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4025 -{ -margin-left: 0px; -} - -.text_class4026 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4027 -{ -margin-left: 0px; -} - -.text_class4028 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4029 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4030 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4031 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4032 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4033 -{ -} - -.paragraph_class4034 -{ -} - -.text_class4035 -{ -font-size: 11px; -} - -.paragraph_class4036 -{ -} - -.text_class4037 -{ -} - -.text_class4038 -{ -} - -.paragraph_class4039 -{ -} - -.text_class4040 -{ -font-family: arial; -} - -.text_class4041 -{ -font-size: 11px; -} - -.paragraph_class4042 -{ -} - -.paragraph_class4043 -{ -} - -.text_class4044 -{ -font-family: arial; -} - -.text_class4045 -{ -font-size: 11px; -} - -.text_class4046 -{ -font-family: ｍｓ 明朝; -} - -.text_class4047 -{ -font-size: 11px; -} - -.text_class4048 -{ -font-family: arial; -} - -.text_class4049 -{ -font-size: 11px; -} - -.paragraph_class4050 -{ -} - -.text_class4051 -{ -font-family: arial; -} - -.text_class4052 -{ -font-size: 11px; -} - -.text_class4053 -{ -font-family: arial; -} - -.text_class4054 -{ -font-size: 11px; -} - -.text_class4055 -{ -font-family: arial; -} - -.text_class4056 -{ -font-size: 11px; -} - -.paragraph_class4057 -{ -} - -.paragraph_class4058 -{ -} - -.text_class4059 -{ -font-family: arial; -} - -.text_class4060 -{ -font-size: 11px; -} - -.paragraph_class4061 -{ -} - -.text_class4062 -{ -font-family: arial; -} - -.text_class4063 -{ -font-size: 11px; -} - -.text_class4064 -{ -} - -.paragraph_class4065 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4066 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4067 -{ -font-weight: bold; -} - -.text_class4068 -{ -} - -.paragraph_class4070 -{ -margin-left: 0px; -} - -.text_class4071 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4072 -{ -font-weight: bold; -} - -.cell_class4073 -{ -width: 165px; -background-color: #c0c0c0; -} - -.paragraph_class4075 -{ -margin-left: 0px; -} - -.text_class4076 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4077 -{ -font-weight: bold; -} - -.cell_class4078 -{ -width: 173px; -background-color: #c0c0c0; -} - -.paragraph_class4080 -{ -margin-left: 0px; -} - -.text_class4081 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4082 -{ -font-weight: bold; -} - -.cell_class4083 -{ -width: 52px; -background-color: #c0c0c0; -} - -.paragraph_class4085 -{ -margin-left: 0px; -} - -.text_class4086 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4087 -{ -font-weight: bold; -} - -.paragraph_class4088 -{ -margin-left: 0px; -} - -.text_class4089 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class4090 -{ -width: 165px; -} - -.paragraph_class4091 -{ -margin-left: 0px; -} - -.text_class4092 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class4093 -{ -width: 173px; -} - -.paragraph_class4094 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4095 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class4096 -{ -width: 52px; -} - -.paragraph_class4097 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4098 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4099 -{ -margin-left: 0px; -} - -.text_class4100 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4101 -{ -margin-left: 0px; -} - -.text_class4102 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4103 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4104 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4105 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4106 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4107 -{ -margin-left: 0px; -} - -.text_class4108 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4109 -{ -margin-left: 0px; -} - -.text_class4110 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4111 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4112 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4113 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4114 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4115 -{ -margin-left: 0px; -} - -.text_class4116 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4117 -{ -margin-left: 0px; -} - -.text_class4118 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4119 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4120 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4121 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4122 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4123 -{ -margin-left: 0px; -} - -.text_class4124 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4125 -{ -margin-left: 0px; -} - -.text_class4126 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4127 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4128 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4129 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4130 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4131 -{ -} - -.text_class4132 -{ -} - -.paragraph_class4133 -{ -} - -.text_class4134 -{ -font-size: 11px; -} - -.paragraph_class4135 -{ -} - -.text_class4136 -{ -font-size: 11px; -} - -.paragraph_class4137 -{ -} - -.text_class4138 -{ -font-size: 11px; -} - -.paragraph_class4139 -{ -} - -.text_class4140 -{ -font-size: 11px; -} - -.paragraph_class4141 -{ -} - -.text_class4142 -{ -font-size: 11px; -} - -.paragraph_class4143 -{ -} - -.text_class4144 -{ -font-size: 11px; -} - -.paragraph_class4145 -{ -} - -.text_class4146 -{ -font-size: 11px; -} - -.paragraph_class4147 -{ -} - -.text_class4148 -{ -font-size: 11px; -} - -.text_class4149 -{ -} - -.text_class4150 -{ -} - -.paragraph_class4151 -{ -} - -.text_class4152 -{ -font-family: arial; -} - -.text_class4153 -{ -font-size: 11px; -} - -.paragraph_class4154 -{ -} - -.paragraph_class4155 -{ -} - -.text_class4156 -{ -font-family: arial; -} - -.text_class4157 -{ -font-size: 11px; -} - -.text_class4158 -{ -font-family: ｍｓ 明朝; -} - -.text_class4159 -{ -font-size: 11px; -} - -.text_class4160 -{ -font-family: arial; -} - -.text_class4161 -{ -font-size: 11px; -} - -.paragraph_class4162 -{ -} - -.paragraph_class4163 -{ -} - -.text_class4164 -{ -font-family: arial; -} - -.text_class4165 -{ -font-size: 11px; -} - -.text_class4166 -{ -font-family: arial; -} - -.text_class4167 -{ -font-size: 11px; -} - -.text_class4168 -{ -font-family: arial; -} - -.text_class4169 -{ -font-size: 11px; -} - -.text_class4170 -{ -font-family: arial; -} - -.text_class4171 -{ -font-size: 11px; -} - -.text_class4172 -{ -} - -.paragraph_class4173 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4174 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4175 -{ -font-weight: bold; -} - -.text_class4176 -{ -} - -.cell_class4177 -{ -width: 42px; -background-color: #c0c0c0; -} - -.paragraph_class4179 -{ -margin-left: 0px; -} - -.text_class4180 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4181 -{ -font-weight: bold; -} - -.cell_class4182 -{ -width: 278px; -background-color: #c0c0c0; -} - -.paragraph_class4184 -{ -margin-left: 0px; -} - -.text_class4185 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4186 -{ -font-weight: bold; -} - -.cell_class4187 -{ -width: 146px; -background-color: #c0c0c0; -} - -.paragraph_class4189 -{ -margin-left: 0px; -} - -.text_class4190 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4191 -{ -font-weight: bold; -} - -.paragraph_class4193 -{ -margin-left: 0px; -} - -.text_class4194 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4195 -{ -font-weight: bold; -} - -.cell_class4196 -{ -width: 42px; -} - -.paragraph_class4197 -{ -margin-left: 0px; -} - -.text_class4198 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class4199 -{ -width: 278px; -} - -.paragraph_class4200 -{ -margin-left: 0px; -} - -.text_class4201 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class4202 -{ -width: 146px; -} - -.paragraph_class4203 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4204 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4205 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4206 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4207 -{ -margin-left: 0px; -} - -.text_class4208 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4209 -{ -margin-left: 0px; -} - -.text_class4210 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4211 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4212 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4213 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4214 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4215 -{ -margin-left: 0px; -} - -.text_class4216 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4217 -{ -margin-left: 0px; -} - -.text_class4218 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4219 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4220 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4221 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4222 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4223 -{ -margin-left: 0px; -} - -.text_class4224 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4225 -{ -margin-left: 0px; -} - -.text_class4226 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4227 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4228 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4229 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4230 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4231 -{ -margin-left: 0px; -} - -.text_class4232 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4233 -{ -margin-left: 0px; -} - -.text_class4234 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4235 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4236 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4237 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4238 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4239 -{ -margin-left: 0px; -} - -.text_class4240 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4241 -{ -margin-left: 0px; -} - -.text_class4242 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4243 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4244 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class4245 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4246 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class4247 -{ -} - -.text_class4248 -{ -} - -.paragraph_class4249 -{ -} - -.text_class4250 -{ -font-size: 11px; -} - -.paragraph_class4251 -{ -} - -.text_class4252 -{ -font-size: 11px; -} - -.paragraph_class4253 -{ -} - -.text_class4254 -{ -font-size: 11px; -} - -.paragraph_class4255 -{ -} - -.text_class4256 -{ -font-size: 11px; -} - -.paragraph_class4257 -{ -} - -.text_class4258 -{ -font-size: 11px; -} - -.paragraph_class4259 -{ -} - -.text_class4260 -{ -font-size: 11px; -} - -.paragraph_class4261 -{ -} - -.text_class4262 -{ -font-size: 11px; -} - -.paragraph_class4263 -{ -} - -.text_class4264 -{ -font-size: 11px; -} - -.paragraph_class4265 -{ -} - -.text_class4266 -{ -font-size: 11px; -} - -.text_class4267 -{ -} - -.text_class4268 -{ -} - -.paragraph_class4269 -{ -} - -.text_class4270 -{ -font-size: 11px; -} - -.text_class4271 -{ -font-family: arial; -} - -.paragraph_class4272 -{ -} - -.paragraph_class4273 -{ -} - -.text_class4274 -{ -font-size: 11px; -} - -.text_class4275 -{ -font-family: arial; -} - -.text_class4276 -{ -font-family: arial; -} - -.text_class4277 -{ -font-family: arial; -} - -.text_class4278 -{ -} - -.paragraph_class4279 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4280 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4281 -{ -font-weight: bold; -} - -.text_class4282 -{ -} - -.cell_class4283 -{ -width: 60px; -background-color: #c0c0c0; -} - -.paragraph_class4285 -{ -margin-left: 0px; -} - -.text_class4286 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4287 -{ -font-weight: bold; -} - -.cell_class4288 -{ -width: 167px; -background-color: #c0c0c0; -} - -.paragraph_class4290 -{ -margin-left: 0px; -} - -.text_class4291 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4292 -{ -font-weight: bold; -} - -.cell_class4293 -{ -width: 95px; -background-color: #c0c0c0; -} - -.paragraph_class4295 -{ -margin-left: 0px; -} - -.text_class4296 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4297 -{ -font-weight: bold; -} - -.cell_class4298 -{ -width: 64px; -background-color: #c0c0c0; -} - -.paragraph_class4300 -{ -margin-left: 0px; -} - -.text_class4301 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4302 -{ -font-weight: bold; -} - -.cell_class4303 -{ -width: 60px; -} - -.paragraph_class4304 -{ -margin-left: 0px; -} - -.text_class4305 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class4306 -{ -width: 167px; -} - -.paragraph_class4307 -{ -margin-left: 0px; -} - -.text_class4308 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4309 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4310 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class4311 -{ -width: 64px; -} - -.paragraph_class4312 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4313 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4314 -{ -margin-left: 0px; -} - -.text_class4315 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4316 -{ -margin-left: 0px; -} - -.text_class4317 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4318 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4319 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4320 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4321 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4322 -{ -margin-left: 0px; -} - -.text_class4323 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4324 -{ -margin-left: 0px; -} - -.text_class4325 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4326 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4327 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4328 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4329 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4330 -{ -margin-left: 0px; -} - -.text_class4331 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4332 -{ -margin-left: 0px; -} - -.text_class4333 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4334 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4335 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4336 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4337 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4338 -{ -margin-left: 0px; -} - -.text_class4339 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4340 -{ -margin-left: 0px; -} - -.text_class4341 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4342 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4343 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4344 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4345 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4346 -{ -margin-left: 0px; -} - -.text_class4347 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4348 -{ -margin-left: 0px; -} - -.text_class4349 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4350 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class4351 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4352 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4353 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4354 -{ -margin-left: 0px; -} - -.text_class4355 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4356 -{ -margin-left: 0px; -} - -.text_class4357 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4358 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4359 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4360 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4361 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4362 -{ -margin-left: 0px; -} - -.text_class4363 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4364 -{ -margin-left: 0px; -} - -.text_class4365 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4366 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4367 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4368 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4369 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4370 -{ -margin-left: 0px; -} - -.text_class4371 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4372 -{ -margin-left: 0px; -} - -.text_class4373 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4374 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4375 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4376 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4377 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4378 -{ -} - -.text_class4379 -{ -} - -.paragraph_class4380 -{ -} - -.text_class4381 -{ -font-family: arial; -} - -.text_class4382 -{ -font-size: 11px; -} - -.paragraph_class4383 -{ -} - -.text_class4384 -{ -font-family: arial; -} - -.text_class4385 -{ -font-size: 11px; -} - -.text_class4386 -{ -} - -.text_class4387 -{ -} - -.paragraph_class4388 -{ -} - -.text_class4389 -{ -font-size: 11px; -} - -.paragraph_class4390 -{ -} - -.text_class4391 -{ -font-size: 11px; -} - -.paragraph_class4392 -{ -} - -.text_class4393 -{ -font-size: 11px; -} - -.paragraph_class4394 -{ -} - -.text_class4395 -{ -font-size: 11px; -} - -.paragraph_class4396 -{ -} - -.text_class4397 -{ -font-size: 11px; -} - -.paragraph_class4398 -{ -} - -.text_class4399 -{ -font-size: 11px; -} - -.paragraph_class4400 -{ -} - -.text_class4401 -{ -font-size: 11px; -} - -.paragraph_class4402 -{ -} - -.text_class4403 -{ -font-size: 11px; -} - -.paragraph_class4404 -{ -} - -.text_class4405 -{ -font-size: 11px; -} - -.paragraph_class4406 -{ -} - -.text_class4407 -{ -font-size: 11px; -} - -.paragraph_class4408 -{ -} - -.text_class4409 -{ -font-size: 11px; -} - -.text_class4410 -{ -} - -.text_class4411 -{ -} - -.paragraph_class4412 -{ -} - -.text_class4413 -{ -font-size: 11px; -} - -.paragraph_class4414 -{ -} - -.text_class4415 -{ -font-size: 11px; -} - -.paragraph_class4416 -{ -} - -.text_class4417 -{ -font-size: 11px; -} - -.paragraph_class4418 -{ -} - -.text_class4419 -{ -font-size: 11px; -} - -.paragraph_class4420 -{ -} - -.text_class4421 -{ -font-size: 11px; -} - -.paragraph_class4422 -{ -} - -.text_class4423 -{ -font-size: 11px; -} - -.paragraph_class4424 -{ -} - -.text_class4425 -{ -font-size: 11px; -} - -.paragraph_class4426 -{ -} - -.text_class4427 -{ -font-size: 11px; -} - -.paragraph_class4428 -{ -} - -.text_class4429 -{ -font-size: 11px; -} - -.paragraph_class4430 -{ -} - -.text_class4431 -{ -font-size: 11px; -} - -.paragraph_class4432 -{ -} - -.text_class4433 -{ -font-size: 11px; -} - -.text_class4434 -{ -} - -.text_class4435 -{ -} - -.text_class4436 -{ -} - -.paragraph_class4437 -{ -} - -.text_class4438 -{ -font-size: 11px; -} - -.text_class4439 -{ -font-family: arial; -} - -.text_class4440 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4441 -{ -} - -.text_class4442 -{ -font-size: 11px; -} - -.text_class4443 -{ -font-size: 11px; -} - -.paragraph_class4444 -{ -} - -.text_class4445 -{ -} - -.text_class4446 -{ -} - -.paragraph_class4447 -{ -text-indent: -18.0px; -margin-left: 18px; -} - -.text_class4448 -{ -font-size: 10px; -} - -.text_class4449 -{ -} - -.paragraph_class4450 -{ -} - -.text_class4451 -{ -font-family: arial; -} - -.text_class4452 -{ -font-size: 11px; -} - -.text_class4453 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4454 -{ -} - -.paragraph_class4455 -{ -} - -.text_class4456 -{ -font-family: arial; -} - -.text_class4457 -{ -font-size: 11px; -} - -.paragraph_class4458 -{ -} - -.paragraph_class4459 -{ -} - -.text_class4460 -{ -font-family: arial; -} - -.text_class4461 -{ -font-size: 11px; -} - -.text_class4462 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4463 -{ -} - -.text_class4464 -{ -font-size: 10px; -} - -.text_class4465 -{ -} - -.paragraph_class4466 -{ -} - -.text_class4467 -{ -font-family: arial; -} - -.text_class4468 -{ -font-size: 11px; -} - -.paragraph_class4469 -{ -} - -.paragraph_class4470 -{ -} - -.text_class4471 -{ -font-family: arial; -} - -.text_class4472 -{ -font-size: 11px; -} - -.text_class4473 -{ -} - -.text_class4474 -{ -} - -.paragraph_class4475 -{ -} - -.text_class4476 -{ -font-family: arial; -} - -.text_class4477 -{ -font-size: 11px; -} - -.text_class4478 -{ -} - -.paragraph_class4479 -{ -} - -.text_class4480 -{ -font-family: arial; -} - -.text_class4481 -{ -font-size: 11px; -} - -.text_class4482 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4483 -{ -font-family: arial; -} - -.text_class4484 -{ -font-size: 11px; -} - -.text_class4485 -{ -} - -.paragraph_class4486 -{ -} - -.text_class4487 -{ -font-size: 11px; -} - -.text_class4488 -{ -} - -.paragraph_class4489 -{ -} - -.text_class4490 -{ -font-family: arial; -} - -.text_class4491 -{ -font-size: 11px; -} - -.text_class4492 -{ -font-family: arial; -} - -.text_class4493 -{ -font-size: 11px; -} - -.text_class4494 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4495 -{ -} - -.paragraph_class4496 -{ -} - -.text_class4497 -{ -font-family: arial; -} - -.text_class4498 -{ -font-size: 11px; -} - -.text_class4499 -{ -font-family: arial; -} - -.text_class4500 -{ -font-size: 11px; -} - -.text_class4501 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4502 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4503 -{ -} - -.paragraph_class4504 -{ -} - -.text_class4505 -{ -font-size: 11px; -} - -.text_class4506 -{ -font-size: 11px; -} - -.text_class4507 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4508 -{ -} - -.paragraph_class4509 -{ -} - -.text_class4510 -{ -font-family: arial; -} - -.text_class4511 -{ -font-size: 11px; -} - -.text_class4512 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4513 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4514 -{ -} - -.paragraph_class4515 -{ -} - -.text_class4516 -{ -font-family: arial; -} - -.text_class4517 -{ -font-size: 11px; -} - -.text_class4518 -{ -} - -.paragraph_class4519 -{ -} - -.text_class4520 -{ -font-family: arial; -} - -.text_class4521 -{ -font-size: 11px; -} - -.text_class4522 -{ -} - -.paragraph_class4523 -{ -} - -.text_class4524 -{ -font-family: arial; -} - -.text_class4525 -{ -font-size: 11px; -} - -.text_class4526 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4527 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4528 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4529 -{ -} - -.paragraph_class4530 -{ -} - -.text_class4531 -{ -font-family: arial; -} - -.text_class4532 -{ -font-size: 11px; -} - -.text_class4533 -{ -} - -.paragraph_class4534 -{ -} - -.text_class4535 -{ -font-family: arial; -} - -.text_class4536 -{ -font-size: 11px; -} - -.text_class4537 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4538 -{ -font-family: arial; -} - -.text_class4539 -{ -font-size: 11px; -} - -.text_class4540 -{ -} - -.paragraph_class4541 -{ -} - -.text_class4542 -{ -font-family: arial; -} - -.text_class4543 -{ -font-size: 11px; -} - -.text_class4544 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4545 -{ -font-family: arial; -} - -.text_class4546 -{ -font-size: 11px; -} - -.text_class4547 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4548 -{ -} - -.paragraph_class4549 -{ -} - -.text_class4550 -{ -font-family: arial; -} - -.text_class4551 -{ -font-size: 11px; -} - -.text_class4552 -{ -} - -.paragraph_class4553 -{ -} - -.text_class4554 -{ -font-family: arial; -} - -.text_class4555 -{ -font-size: 11px; -} - -.text_class4556 -{ -} - -.paragraph_class4557 -{ -} - -.text_class4558 -{ -font-family: arial; -} - -.text_class4559 -{ -font-size: 11px; -} - -.text_class4560 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4561 -{ -} - -.paragraph_class4562 -{ -} - -.text_class4563 -{ -font-family: arial; -} - -.text_class4564 -{ -font-size: 11px; -} - -.text_class4565 -{ -} - -.paragraph_class4566 -{ -} - -.text_class4567 -{ -font-family: arial; -} - -.text_class4568 -{ -font-size: 11px; -} - -.text_class4569 -{ -} - -.paragraph_class4570 -{ -} - -.text_class4571 -{ -font-family: arial; -} - -.text_class4572 -{ -font-size: 11px; -} - -.text_class4573 -{ -} - -.paragraph_class4574 -{ -} - -.text_class4575 -{ -font-family: arial; -} - -.text_class4576 -{ -font-size: 11px; -} - -.text_class4577 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4578 -{ -} - -.paragraph_class4579 -{ -} - -.text_class4580 -{ -font-size: 11px; -} - -.text_class4581 -{ -} - -.paragraph_class4582 -{ -} - -.text_class4583 -{ -font-family: arial; -} - -.text_class4584 -{ -font-size: 11px; -} - -.text_class4585 -{ -} - -.paragraph_class4586 -{ -} - -.text_class4587 -{ -font-family: arial; -} - -.text_class4588 -{ -font-size: 11px; -} - -.text_class4589 -{ -} - -.paragraph_class4590 -{ -} - -.text_class4591 -{ -font-family: arial; -} - -.text_class4592 -{ -font-size: 11px; -} - -.text_class4593 -{ -} - -.paragraph_class4594 -{ -} - -.text_class4595 -{ -font-family: arial; -} - -.text_class4596 -{ -font-size: 11px; -} - -.text_class4597 -{ -} - -.paragraph_class4598 -{ -} - -.text_class4599 -{ -font-family: arial; -} - -.text_class4600 -{ -font-size: 11px; -} - -.text_class4601 -{ -} - -.paragraph_class4602 -{ -} - -.text_class4603 -{ -font-family: arial; -} - -.text_class4604 -{ -font-size: 11px; -} - -.text_class4605 -{ -} - -.paragraph_class4606 -{ -} - -.text_class4607 -{ -font-family: arial; -} - -.text_class4608 -{ -font-size: 11px; -} - -.text_class4609 -{ -} - -.paragraph_class4610 -{ -} - -.text_class4611 -{ -font-family: arial; -} - -.text_class4612 -{ -font-size: 11px; -} - -.text_class4613 -{ -font-family: arial; -} - -.text_class4614 -{ -font-size: 11px; -} - -.text_class4615 -{ -font-family: arial; -} - -.text_class4616 -{ -font-size: 11px; -} - -.text_class4617 -{ -font-family: arial; -} - -.text_class4618 -{ -font-size: 11px; -} - -.text_class4619 -{ -font-family: arial; -} - -.text_class4620 -{ -font-size: 11px; -} - -.text_class4621 -{ -font-family: arial; -} - -.text_class4622 -{ -font-size: 11px; -} - -.text_class4623 -{ -font-family: meiryo ui; -} - -.text_class4624 -{ -font-size: 11px; -} - -.text_class4625 -{ -font-family: arial; -} - -.text_class4626 -{ -font-size: 11px; -} - -.text_class4627 -{ -font-family: arial; -} - -.text_class4628 -{ -font-size: 11px; -} - -.text_class4629 -{ -font-family: arial; -} - -.text_class4630 -{ -font-size: 11px; -} - -.text_class4631 -{ -} - -.paragraph_class4632 -{ -} - -.text_class4633 -{ -font-family: arial; -} - -.text_class4634 -{ -font-size: 11px; -} - -.text_class4635 -{ -font-family: arial; -} - -.text_class4636 -{ -font-size: 11px; -} - -.text_class4637 -{ -font-family: arial; -} - -.text_class4638 -{ -font-size: 11px; -} - -.text_class4639 -{ -font-family: arial; -} - -.text_class4640 -{ -font-size: 11px; -} - -.text_class4641 -{ -font-family: arial; -} - -.text_class4642 -{ -font-size: 11px; -} - -.text_class4643 -{ -font-family: arial; -} - -.text_class4644 -{ -font-size: 11px; -} - -.paragraph_class4645 -{ -} - -.paragraph_class4646 -{ -} - -.text_class4647 -{ -font-family: arial; -} - -.text_class4648 -{ -font-size: 11px; -} - -.text_class4649 -{ -font-family: arial; -} - -.text_class4650 -{ -font-size: 11px; -} - -.text_class4651 -{ -font-family: arial; -} - -.text_class4652 -{ -font-size: 11px; -} - -.text_class4653 -{ -font-family: arial; -} - -.text_class4654 -{ -font-size: 11px; -} - -.text_class4655 -{ -font-family: arial; -} - -.text_class4656 -{ -font-size: 11px; -} - -.text_class4657 -{ -font-family: arial; -} - -.text_class4658 -{ -font-size: 11px; -} - -.text_class4659 -{ -font-family: arial; -} - -.text_class4660 -{ -font-size: 11px; -} - -.paragraph_class4661 -{ -} - -.paragraph_class4662 -{ -} - -.text_class4663 -{ -font-family: arial; -} - -.text_class4664 -{ -font-size: 11px; -} - -.text_class4665 -{ -font-family: arial; -} - -.text_class4666 -{ -font-size: 11px; -} - -.text_class4667 -{ -font-family: arial; -} - -.text_class4668 -{ -font-size: 11px; -} - -.text_class4669 -{ -font-family: arial; -} - -.text_class4670 -{ -font-size: 11px; -} - -.text_class4671 -{ -} - -.paragraph_class4672 -{ -} - -.text_class4673 -{ -font-family: arial; -} - -.text_class4674 -{ -font-size: 11px; -} - -.text_class4675 -{ -} - -.paragraph_class4676 -{ -} - -.text_class4677 -{ -font-family: arial; -} - -.text_class4678 -{ -font-size: 11px; -} - -.text_class4679 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4680 -{ -} - -.paragraph_class4681 -{ -} - -.text_class4682 -{ -font-family: arial; -} - -.text_class4683 -{ -font-size: 11px; -} - -.text_class4684 -{ -} - -.paragraph_class4685 -{ -} - -.text_class4686 -{ -font-size: 11px; -} - -.text_class4687 -{ -} - -.text_class4688 -{ -} - -.paragraph_class4689 -{ -} - -.text_class4690 -{ -font-size: 11px; -} - -.text_class4691 -{ -} - -.text_class4692 -{ -} - -.paragraph_class4693 -{ -} - -.text_class4694 -{ -font-size: 11px; -} - -.text_class4695 -{ -} - -.text_class4696 -{ -} - -.text_class4697 -{ -} - -.paragraph_class4698 -{ -} - -.text_class4699 -{ -font-family: arial; -} - -.text_class4700 -{ -font-size: 11px; -} - -.paragraph_class4701 -{ -} - -.paragraph_class4702 -{ -font-weight: bold; -text-indent: -42.55px; -margin-left: 42px; -} - -.text_class4703 -{ -font-size: 11px; -} - -.paragraph_class4704 -{ -} - -.text_class4705 -{ -font-family: arial; -} - -.text_class4706 -{ -font-size: 11px; -} - -.paragraph_class4707 -{ -} - -.text_class4708 -{ -font-family: arial; -} - -.text_class4709 -{ -font-size: 11px; -} - -.paragraph_class4710 -{ -} - -.text_class4711 -{ -font-family: arial; -} - -.text_class4712 -{ -font-size: 11px; -} - -.paragraph_class4713 -{ -} - -.paragraph_class4714 -{ -font-weight: bold; -text-indent: -42.55px; -margin-left: 42px; -} - -.text_class4715 -{ -font-size: 11px; -} - -.paragraph_class4716 -{ -} - -.text_class4717 -{ -font-family: arial; -} - -.text_class4718 -{ -font-size: 11px; -} - -.paragraph_class4719 -{ -} - -.text_class4720 -{ -font-family: arial; -} - -.text_class4721 -{ -font-size: 11px; -} - -.text_class4722 -{ -} - -.text_class4723 -{ -} - -.paragraph_class4724 -{ -} - -.text_class4725 -{ -font-family: arial; -} - -.text_class4726 -{ -font-size: 11px; -} - -.text_class4727 -{ -} - -.paragraph_class4728 -{ -} - -.text_class4729 -{ -font-family: arial; -} - -.text_class4730 -{ -font-size: 11px; -} - -.text_class4731 -{ -} - -.paragraph_class4732 -{ -} - -.text_class4733 -{ -font-family: arial; -} - -.text_class4734 -{ -font-size: 11px; -} - -.text_class4735 -{ -font-family: arial; -} - -.text_class4736 -{ -font-size: 11px; -} - -.text_class4737 -{ -} - -.paragraph_class4738 -{ -} - -.text_class4739 -{ -font-family: arial; -} - -.text_class4740 -{ -font-size: 11px; -} - -.text_class4741 -{ -} - -.paragraph_class4742 -{ -} - -.text_class4743 -{ -font-family: arial; -} - -.text_class4744 -{ -font-size: 11px; -} - -.text_class4745 -{ -} - -.paragraph_class4746 -{ -} - -.text_class4747 -{ -font-family: arial; -} - -.text_class4748 -{ -font-size: 11px; -} - -.text_class4749 -{ -} - -.paragraph_class4750 -{ -} - -.text_class4751 -{ -font-family: arial; -} - -.text_class4752 -{ -font-size: 11px; -} - -.text_class4753 -{ -} - -.paragraph_class4754 -{ -} - -.text_class4755 -{ -font-family: arial; -} - -.text_class4756 -{ -font-size: 11px; -} - -.text_class4757 -{ -} - -.paragraph_class4758 -{ -} - -.text_class4759 -{ -font-family: arial; -} - -.text_class4760 -{ -font-size: 11px; -} - -.text_class4761 -{ -} - -.paragraph_class4762 -{ -} - -.text_class4763 -{ -font-family: arial; -} - -.text_class4764 -{ -font-size: 11px; -} - -.text_class4765 -{ -} - -.paragraph_class4766 -{ -} - -.text_class4767 -{ -font-family: arial; -} - -.text_class4768 -{ -font-size: 11px; -} - -.text_class4769 -{ -} - -.paragraph_class4770 -{ -} - -.text_class4771 -{ -font-family: arial; -} - -.text_class4772 -{ -font-size: 11px; -} - -.text_class4773 -{ -} - -.paragraph_class4774 -{ -} - -.text_class4775 -{ -font-family: arial; -} - -.text_class4776 -{ -font-size: 11px; -} - -.text_class4777 -{ -} - -.text_class4778 -{ -} - -.paragraph_class4779 -{ -} - -.text_class4780 -{ -font-size: 11px; -} - -.text_class4781 -{ -} - -.text_class4782 -{ -} - -.paragraph_class4783 -{ -} - -.text_class4784 -{ -font-size: 11px; -} - -.text_class4785 -{ -} - -.text_class4786 -{ -} - -.paragraph_class4787 -{ -} - -.text_class4788 -{ -font-size: 11px; -} - -.text_class4789 -{ -} - -.text_class4790 -{ -} - -.paragraph_class4791 -{ -} - -.text_class4792 -{ -font-size: 11px; -} - -.text_class4793 -{ -} - -.text_class4794 -{ -} - -.paragraph_class4795 -{ -} - -.text_class4796 -{ -font-size: 11px; -} - -.text_class4797 -{ -} - -.text_class4798 -{ -} - -.paragraph_class4799 -{ -} - -.text_class4800 -{ -font-family: arial; -} - -.text_class4801 -{ -font-size: 11px; -} - -.paragraph_class4802 -{ -} - -.paragraph_class4803 -{ -} - -.text_class4804 -{ -font-family: arial; -} - -.text_class4805 -{ -font-size: 11px; -} - -.paragraph_class4806 -{ -} - -.paragraph_class4807 -{ -} - -.text_class4808 -{ -font-family: arial; -} - -.text_class4809 -{ -font-size: 11px; -} - -.paragraph_class4810 -{ -} - -.paragraph_class4811 -{ -} - -.text_class4812 -{ -font-family: arial; -} - -.text_class4813 -{ -font-size: 11px; -} - -.text_class4814 -{ -} - -.text_class4815 -{ -} - -.paragraph_class4816 -{ -} - -.text_class4817 -{ -font-family: arial; -} - -.text_class4818 -{ -font-size: 11px; -} - -.paragraph_class4819 -{ -} - -.paragraph_class4820 -{ -} - -.text_class4821 -{ -font-family: arial; -} - -.text_class4822 -{ -font-size: 11px; -} - -.paragraph_class4823 -{ -} - -.paragraph_class4824 -{ -} - -.text_class4825 -{ -font-family: arial; -} - -.text_class4826 -{ -font-size: 11px; -} - -.paragraph_class4827 -{ -} - -.paragraph_class4828 -{ -} - -.text_class4829 -{ -font-family: arial; -} - -.text_class4830 -{ -font-size: 11px; -} - -.text_class4831 -{ -} - -.paragraph_class4832 -{ -} - -.text_class4833 -{ -font-family: arial; -} - -.text_class4834 -{ -font-size: 11px; -} - -.paragraph_class4835 -{ -} - -.text_class4836 -{ -font-family: arial; -} - -.text_class4837 -{ -font-size: 11px; -} - -.text_class4838 -{ -} - -.paragraph_class4839 -{ -} - -.text_class4840 -{ -font-family: arial; -} - -.text_class4841 -{ -font-size: 11px; -} - -.paragraph_class4842 -{ -} - -.paragraph_class4843 -{ -} - -.text_class4844 -{ -font-family: arial; -} - -.text_class4845 -{ -font-size: 11px; -} - -.paragraph_class4846 -{ -} - -.paragraph_class4847 -{ -} - -.text_class4848 -{ -font-family: arial; -} - -.text_class4849 -{ -font-size: 11px; -} - -.text_class4850 -{ -} - -.paragraph_class4851 -{ -} - -.text_class4852 -{ -font-family: arial; -} - -.text_class4853 -{ -font-size: 11px; -} - -.paragraph_class4854 -{ -} - -.text_class4855 -{ -font-family: arial; -} - -.text_class4856 -{ -font-size: 11px; -} - -.paragraph_class4857 -{ -} - -.text_class4858 -{ -font-family: arial; -} - -.text_class4859 -{ -font-size: 11px; -} - -.text_class4860 -{ -} - -.paragraph_class4861 -{ -} - -.text_class4862 -{ -font-family: arial; -} - -.text_class4863 -{ -font-size: 11px; -} - -.text_class4864 -{ -} - -.paragraph_class4865 -{ -} - -.text_class4866 -{ -font-family: arial; -} - -.text_class4867 -{ -font-size: 11px; -} - -.text_class4868 -{ -} - -.text_class4869 -{ -} - -.paragraph_class4870 -{ -} - -.text_class4871 -{ -font-size: 11px; -} - -.text_class4872 -{ -} - -.paragraph_class4873 -{ -} - -.text_class4874 -{ -font-size: 11px; -} - -.text_class4875 -{ -} - -.text_class4876 -{ -} - -.text_class4877 -{ -} - -.text_class4878 -{ -} - -.paragraph_class4879 -{ -} - -.text_class4880 -{ -font-size: 11px; -} - -.paragraph_class4881 -{ -} - -.text_class4882 -{ -font-size: 11px; -} - -.paragraph_class4883 -{ -} - -.text_class4884 -{ -font-size: 11px; -} - -.paragraph_class4885 -{ -} - -.text_class4886 -{ -font-size: 11px; -} - -.paragraph_class4887 -{ -} - -.text_class4888 -{ -font-size: 11px; -} - -.paragraph_class4889 -{ -} - -.text_class4890 -{ -font-size: 11px; -} - -.paragraph_class4891 -{ -} - -.text_class4892 -{ -} - -.text_class4893 -{ -} - -.paragraph_class4894 -{ -} - -.text_class4895 -{ -font-size: 11px; -} - -.text_class4896 -{ -} - -.text_class4897 -{ -} - -.text_class4898 -{ -} - -.paragraph_class4899 -{ -} - -.text_class4900 -{ -font-family: arial; -} - -.text_class4901 -{ -font-size: 11px; -} - -.paragraph_class4902 -{ -} - -.paragraph_class4903 -{ -text-indent: -18.0px; -margin-left: 23px; -} - -.text_class4904 -{ -font-size: 11px; -} - -.text_class4905 -{ -font-size: 11px; -} - -.paragraph_class4906 -{ -} - -.text_class4907 -{ -font-family: arial; -} - -.text_class4908 -{ -font-size: 11px; -} - -.paragraph_class4909 -{ -} - -.text_class4910 -{ -font-family: arial; -} - -.text_class4911 -{ -font-size: 11px; -} - -.paragraph_class4912 -{ -} - -.text_class4913 -{ -font-size: 11px; -} - -.text_class4914 -{ -font-size: 11px; -} - -.paragraph_class4915 -{ -} - -.text_class4916 -{ -font-family: arial; -} - -.text_class4917 -{ -font-size: 11px; -} - -.paragraph_class4918 -{ -} - -.text_class4919 -{ -font-family: arial; -} - -.text_class4920 -{ -font-size: 11px; -} - -.paragraph_class4921 -{ -} - -.text_class4922 -{ -font-size: 11px; -} - -.text_class4923 -{ -font-size: 11px; -} - -.paragraph_class4924 -{ -} - -.text_class4925 -{ -font-family: arial; -} - -.text_class4926 -{ -font-size: 11px; -} - -.text_class4927 -{ -} - -.text_class4928 -{ -} - -.paragraph_class4929 -{ -} - -.text_class4930 -{ -font-family: arial; -} - -.text_class4931 -{ -font-size: 11px; -} - -.paragraph_class4932 -{ -} - -.text_class4933 -{ -font-family: arial; -} - -.text_class4934 -{ -font-size: 11px; -} - -.text_class4935 -{ -} - -.text_class4936 -{ -} - -.paragraph_class4937 -{ -text-align: center; -margin-left: 0px; -} - -.text_class4938 -{ -font-size: 11px; -font-family: arial; -} - -.text_class4939 -{ -font-weight: bold; -} - -.text_class4940 -{ -} - -.text_class4941 -{ -font-size: 11px; -} - -.text_class4942 -{ -font-size: 11px; -} - -.paragraph_class4943 -{ -} - -.text_class4944 -{ -font-family: arial; -} - -.text_class4945 -{ -font-size: 11px; -} - -.text_class4946 -{ -font-family: arial; -} - -.text_class4947 -{ -font-size: 11px; -} - -.text_class4948 -{ -font-family: arial; -} - -.text_class4949 -{ -font-size: 11px; -} - -.text_class4950 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class4951 -{ -} - -.text_class4952 -{ -font-size: 11px; -} - -.text_class4953 -{ -font-size: 11px; -} - -.paragraph_class4954 -{ -} - -.text_class4955 -{ -font-family: arial; -} - -.text_class4956 -{ -font-size: 11px; -} - -.text_class4957 -{ -font-family: arial; -} - -.text_class4958 -{ -font-size: 11px; -} - -.text_class4959 -{ -font-family: arial; -} - -.text_class4960 -{ -font-size: 11px; -} - -.text_class4961 -{ -font-family: arial; -} - -.text_class4962 -{ -font-size: 11px; -} - -.text_class4963 -{ -font-family: arial; -} - -.text_class4964 -{ -font-size: 11px; -} - -.text_class4965 -{ -font-family: arial; -} - -.text_class4966 -{ -font-size: 11px; -} - -.text_class4967 -{ -font-family: arial; -} - -.text_class4968 -{ -font-size: 11px; -} - -.text_class4969 -{ -} - -.text_class4970 -{ -} - -.paragraph_class4971 -{ -} - -.text_class4972 -{ -font-family: arial; -} - -.text_class4973 -{ -font-size: 11px; -} - -.text_class4974 -{ -} - -.text_class4975 -{ -} - -.text_class4976 -{ -} - -.paragraph_class4977 -{ -} - -.text_class4978 -{ -font-family: arial; -} - -.text_class4979 -{ -font-size: 11px; -} - -.text_class4980 -{ -} - -.paragraph_class4981 -{ -} - -.text_class4982 -{ -font-family: arial; -} - -.text_class4983 -{ -font-size: 11px; -} - -.text_class4984 -{ -} - -.paragraph_class4985 -{ -} - -.text_class4986 -{ -font-family: arial; -} - -.text_class4987 -{ -font-size: 11px; -} - -.text_class4988 -{ -} - -.paragraph_class4989 -{ -} - -.text_class4990 -{ -font-family: arial; -} - -.text_class4991 -{ -font-size: 11px; -} - -.text_class4992 -{ -} - -.paragraph_class4993 -{ -} - -.text_class4994 -{ -font-family: arial; -} - -.text_class4995 -{ -font-size: 11px; -} - -.text_class4996 -{ -} - -.paragraph_class4997 -{ -} - -.text_class4998 -{ -font-family: arial; -} - -.text_class4999 -{ -font-size: 11px; -} - -.text_class5000 -{ -} - -.paragraph_class5001 -{ -} - -.text_class5002 -{ -font-family: arial; -} - -.text_class5003 -{ -font-size: 11px; -} - -.text_class5004 -{ -} - -.paragraph_class5005 -{ -} - -.text_class5006 -{ -font-family: arial; -} - -.text_class5007 -{ -font-size: 11px; -} - -.text_class5008 -{ -} - -.paragraph_class5009 -{ -} - -.text_class5010 -{ -font-family: arial; -} - -.text_class5011 -{ -font-size: 11px; -} - -.text_class5012 -{ -} - -.paragraph_class5013 -{ -} - -.text_class5014 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5015 -{ -} - -.paragraph_class5016 -{ -} - -.text_class5017 -{ -font-family: arial; -} - -.text_class5018 -{ -font-size: 11px; -} - -.text_class5019 -{ -} - -.paragraph_class5020 -{ -} - -.text_class5021 -{ -font-family: arial; -} - -.text_class5022 -{ -font-size: 11px; -} - -.text_class5023 -{ -} - -.paragraph_class5024 -{ -} - -.text_class5025 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5026 -{ -} - -.paragraph_class5027 -{ -} - -.text_class5028 -{ -font-family: arial; -} - -.text_class5029 -{ -font-size: 11px; -} - -.text_class5030 -{ -} - -.paragraph_class5031 -{ -} - -.text_class5032 -{ -font-family: arial; -} - -.text_class5033 -{ -font-size: 11px; -} - -.text_class5034 -{ -} - -.text_class5035 -{ -} - -.paragraph_class5036 -{ -} - -.text_class5037 -{ -font-family: arial; -} - -.text_class5038 -{ -font-size: 11px; -} - -.text_class5039 -{ -} - -.paragraph_class5040 -{ -} - -.text_class5041 -{ -font-family: arial; -} - -.text_class5042 -{ -font-size: 11px; -} - -.text_class5043 -{ -} - -.paragraph_class5044 -{ -} - -.text_class5045 -{ -font-family: arial; -} - -.text_class5046 -{ -font-size: 11px; -} - -.text_class5047 -{ -} - -.paragraph_class5048 -{ -} - -.text_class5049 -{ -font-family: arial; -} - -.text_class5050 -{ -font-size: 11px; -} - -.text_class5051 -{ -} - -.paragraph_class5052 -{ -} - -.text_class5053 -{ -font-family: arial; -} - -.text_class5054 -{ -font-size: 11px; -} - -.text_class5055 -{ -} - -.paragraph_class5056 -{ -} - -.text_class5057 -{ -font-family: arial; -} - -.text_class5058 -{ -font-size: 11px; -} - -.text_class5059 -{ -} - -.paragraph_class5060 -{ -} - -.text_class5061 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5062 -{ -} - -.text_class5063 -{ -} - -.paragraph_class5064 -{ -} - -.text_class5065 -{ -font-family: arial; -} - -.text_class5066 -{ -font-size: 11px; -} - -.text_class5067 -{ -} - -.paragraph_class5068 -{ -} - -.text_class5069 -{ -font-family: arial; -} - -.text_class5070 -{ -font-size: 11px; -} - -.text_class5071 -{ -} - -.text_class5072 -{ -} - -.paragraph_class5073 -{ -} - -.text_class5074 -{ -font-family: arial; -} - -.text_class5075 -{ -font-size: 11px; -} - -.text_class5076 -{ -} - -.text_class5077 -{ -} - -.paragraph_class5078 -{ -} - -.text_class5079 -{ -font-family: arial; -} - -.text_class5080 -{ -font-size: 11px; -} - -.text_class5081 -{ -} - -.text_class5082 -{ -} - -.paragraph_class5083 -{ -} - -.text_class5084 -{ -font-family: arial; -} - -.text_class5085 -{ -font-size: 11px; -} - -.text_class5086 -{ -} - -.paragraph_class5087 -{ -} - -.text_class5088 -{ -font-family: arial; -} - -.text_class5089 -{ -font-size: 11px; -} - -.text_class5090 -{ -} - -.paragraph_class5091 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5092 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5093 -{ -font-weight: bold; -} - -.text_class5094 -{ -} - -.cell_class5095 -{ -width: 47px; -background-color: #bfbfbf; -} - -.paragraph_class5097 -{ -margin-left: 0px; -} - -.text_class5098 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5099 -{ -font-weight: bold; -} - -.cell_class5100 -{ -width: 184px; -background-color: #bfbfbf; -} - -.paragraph_class5102 -{ -margin-left: 0px; -} - -.text_class5103 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5104 -{ -font-weight: bold; -} - -.cell_class5105 -{ -width: 168px; -background-color: #bfbfbf; -} - -.paragraph_class5107 -{ -margin-left: 0px; -} - -.cell_class5108 -{ -width: 129px; -background-color: #bfbfbf; -} - -.paragraph_class5110 -{ -margin-left: 0px; -} - -.text_class5111 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5112 -{ -font-weight: bold; -} - -.paragraph_class5113 -{ -margin-left: 0px; -} - -.text_class5114 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5115 -{ -font-weight: bold; -} - -.cell_class5116 -{ -width: 47px; -background-color: #ffffff; -} - -.paragraph_class5117 -{ -margin-left: 0px; -} - -.text_class5118 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5119 -{ -width: 184px; -background-color: #ffffff; -} - -.paragraph_class5120 -{ -margin-left: 0px; -} - -.text_class5121 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5122 -{ -width: 168px; -background-color: #ffffff; -} - -.paragraph_class5123 -{ -margin-left: 0px; -} - -.text_class5124 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5125 -{ -width: 129px; -background-color: #ffffff; -} - -.paragraph_class5126 -{ -margin-left: 0px; -} - -.text_class5127 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5128 -{ -margin-left: 0px; -} - -.text_class5129 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5130 -{ -margin-left: 0px; -} - -.text_class5131 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5132 -{ -margin-left: 0px; -} - -.text_class5133 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5134 -{ -margin-left: 0px; -} - -.text_class5135 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5136 -{ -margin-left: 0px; -} - -.text_class5137 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5138 -{ -margin-left: 0px; -} - -.text_class5139 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5140 -{ -margin-left: 0px; -} - -.text_class5141 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5142 -{ -margin-left: 0px; -} - -.text_class5143 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5144 -{ -margin-left: 0px; -} - -.text_class5145 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5146 -{ -margin-left: 0px; -} - -.text_class5147 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5148 -{ -margin-left: 0px; -} - -.text_class5149 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5150 -{ -margin-left: 0px; -} - -.text_class5151 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5152 -{ -margin-left: 0px; -} - -.text_class5153 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5154 -{ -margin-left: 0px; -} - -.text_class5155 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5156 -{ -margin-left: 0px; -} - -.text_class5157 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5158 -{ -margin-left: 0px; -} - -.text_class5159 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5160 -{ -margin-left: 0px; -} - -.text_class5161 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5162 -{ -margin-left: 0px; -} - -.text_class5163 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5164 -{ -margin-left: 0px; -} - -.text_class5165 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5166 -{ -margin-left: 0px; -} - -.text_class5167 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5168 -{ -margin-left: 0px; -} - -.text_class5169 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5170 -{ -margin-left: 0px; -} - -.text_class5171 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5172 -{ -margin-left: 0px; -} - -.text_class5173 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5174 -{ -margin-left: 0px; -} - -.text_class5175 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5176 -{ -margin-left: 0px; -} - -.text_class5177 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5178 -{ -width: 352px; -background-color: #ffffff; -} - -.paragraph_class5179 -{ -margin-left: 0px; -} - -.text_class5180 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5181 -{ -margin-left: 0px; -} - -.text_class5182 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5183 -{ -margin-left: 0px; -} - -.text_class5184 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5185 -{ -margin-left: 0px; -} - -.text_class5186 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5187 -{ -margin-left: 0px; -} - -.text_class5188 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5189 -{ -margin-left: 0px; -} - -.text_class5190 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5191 -{ -margin-left: 0px; -} - -.text_class5192 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5193 -{ -margin-left: 0px; -} - -.text_class5194 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5195 -{ -margin-left: 0px; -} - -.text_class5196 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5197 -{ -margin-left: 0px; -} - -.text_class5198 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5199 -{ -margin-left: 0px; -} - -.text_class5200 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5201 -{ -margin-left: 0px; -} - -.text_class5202 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5203 -{ -margin-left: 0px; -} - -.text_class5204 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5205 -{ -margin-left: 0px; -} - -.text_class5206 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5207 -{ -margin-left: 0px; -} - -.text_class5208 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5209 -{ -margin-left: 0px; -} - -.text_class5210 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5211 -{ -margin-left: 0px; -} - -.text_class5212 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5213 -{ -margin-left: 0px; -} - -.text_class5214 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5215 -{ -margin-left: 0px; -} - -.text_class5216 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5217 -{ -margin-left: 0px; -} - -.text_class5218 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5219 -{ -margin-left: 0px; -} - -.text_class5220 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5221 -{ -margin-left: 0px; -} - -.text_class5222 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5223 -{ -margin-left: 0px; -} - -.text_class5224 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5225 -{ -margin-left: 0px; -} - -.text_class5226 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5227 -{ -margin-left: 0px; -} - -.text_class5228 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5229 -{ -margin-left: 0px; -} - -.text_class5230 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5231 -{ -margin-left: 0px; -} - -.text_class5232 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5233 -{ -margin-left: 0px; -} - -.text_class5234 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5235 -{ -margin-left: 0px; -} - -.text_class5236 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5237 -{ -margin-left: 0px; -} - -.text_class5238 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5239 -{ -} - -.text_class5240 -{ -} - -.paragraph_class5241 -{ -} - -.text_class5242 -{ -font-family: arial; -} - -.text_class5243 -{ -font-size: 11px; -} - -.text_class5244 -{ -} - -.paragraph_class5245 -{ -} - -.text_class5246 -{ -font-size: 11px; -} - -.text_class5247 -{ -} - -.paragraph_class5248 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5249 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5250 -{ -font-weight: bold; -} - -.text_class5251 -{ -} - -.cell_class5252 -{ -width: 72px; -background-color: #bfbfbf; -} - -.paragraph_class5254 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5255 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5256 -{ -font-weight: bold; -} - -.cell_class5257 -{ -width: 195px; -background-color: #bfbfbf; -} - -.paragraph_class5259 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5260 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5261 -{ -font-weight: bold; -} - -.cell_class5262 -{ -width: 132px; -background-color: #bfbfbf; -} - -.paragraph_class5264 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5265 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5266 -{ -font-weight: bold; -} - -.cell_class5267 -{ -width: 90px; -background-color: #bfbfbf; -} - -.paragraph_class5269 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5270 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5271 -{ -font-weight: bold; -} - -.paragraph_class5272 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5273 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5274 -{ -font-weight: bold; -} - -.cell_class5275 -{ -width: 72px; -background-color: #ffffff; -} - -.paragraph_class5276 -{ -margin-left: 0px; -} - -.text_class5277 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5278 -{ -width: 195px; -background-color: #ffffff; -} - -.paragraph_class5279 -{ -margin-left: 0px; -} - -.text_class5280 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5281 -{ -width: 132px; -background-color: #ffffff; -} - -.paragraph_class5282 -{ -margin-left: 0px; -} - -.text_class5283 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5284 -{ -width: 90px; -background-color: #ffffff; -} - -.paragraph_class5285 -{ -margin-left: 0px; -} - -.text_class5286 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5287 -{ -margin-left: 0px; -} - -.text_class5288 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5289 -{ -margin-left: 0px; -} - -.text_class5290 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5291 -{ -margin-left: 0px; -} - -.text_class5292 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5293 -{ -margin-left: 0px; -} - -.text_class5294 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5295 -{ -margin-left: 0px; -} - -.text_class5296 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5297 -{ -margin-left: 0px; -} - -.text_class5298 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5299 -{ -margin-left: 0px; -} - -.text_class5300 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5301 -{ -margin-left: 0px; -} - -.text_class5302 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5303 -{ -margin-left: 0px; -} - -.text_class5304 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5305 -{ -margin-left: 0px; -} - -.text_class5306 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5307 -{ -margin-left: 0px; -} - -.text_class5308 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5309 -{ -margin-left: 0px; -} - -.text_class5310 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5311 -{ -margin-left: 0px; -} - -.text_class5312 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5313 -{ -width: 327px; -background-color: #ffffff; -} - -.paragraph_class5314 -{ -margin-left: 0px; -} - -.text_class5315 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5316 -{ -margin-left: 0px; -} - -.text_class5317 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5318 -{ -margin-left: 0px; -} - -.text_class5319 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5320 -{ -margin-left: 0px; -} - -.text_class5321 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5322 -{ -margin-left: 0px; -} - -.text_class5323 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5324 -{ -margin-left: 0px; -} - -.text_class5325 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5326 -{ -margin-left: 0px; -} - -.text_class5327 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5328 -{ -margin-left: 0px; -} - -.text_class5329 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5330 -{ -margin-left: 0px; -} - -.text_class5331 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5332 -{ -margin-left: 0px; -} - -.text_class5333 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5334 -{ -margin-left: 0px; -} - -.text_class5335 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5336 -{ -margin-left: 0px; -} - -.text_class5337 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5338 -{ -margin-left: 0px; -} - -.text_class5339 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5340 -{ -margin-left: 0px; -} - -.text_class5341 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5342 -{ -margin-left: 0px; -} - -.text_class5343 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5344 -{ -margin-left: 0px; -} - -.text_class5345 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5346 -{ -margin-left: 0px; -} - -.text_class5347 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5348 -{ -margin-left: 0px; -} - -.text_class5349 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5350 -{ -margin-left: 0px; -} - -.text_class5351 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5352 -{ -margin-left: 0px; -} - -.text_class5353 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5354 -{ -margin-left: 0px; -} - -.text_class5355 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5356 -{ -margin-left: 0px; -} - -.text_class5357 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5358 -{ -margin-left: 0px; -} - -.text_class5359 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5360 -{ -margin-left: 0px; -} - -.text_class5361 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5362 -{ -margin-left: 0px; -} - -.text_class5363 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5364 -{ -margin-left: 0px; -} - -.text_class5365 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5366 -{ -margin-left: 0px; -} - -.text_class5367 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5368 -{ -margin-left: 0px; -} - -.text_class5369 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5370 -{ -margin-left: 0px; -} - -.text_class5371 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5372 -{ -margin-left: 0px; -} - -.text_class5373 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5374 -{ -margin-left: 0px; -} - -.text_class5375 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5376 -{ -margin-left: 0px; -} - -.text_class5377 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5378 -{ -width: 195px; -background-color: #ffffff; -} - -.paragraph_class5379 -{ -margin-left: 0px; -} - -.text_class5380 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class5381 -{ -width: 132px; -background-color: #ffffff; -} - -.paragraph_class5382 -{ -margin-left: 0px; -} - -.text_class5383 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5384 -{ -margin-left: 0px; -} - -.text_class5385 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5386 -{ -margin-left: 0px; -} - -.text_class5387 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5388 -{ -margin-left: 0px; -} - -.paragraph_class5389 -{ -margin-left: 0px; -} - -.text_class5390 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5391 -{ -margin-left: 0px; -} - -.text_class5392 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5393 -{ -} - -.text_class5394 -{ -} - -.paragraph_class5395 -{ -} - -.text_class5396 -{ -font-family: arial; -} - -.text_class5397 -{ -font-size: 11px; -} - -.text_class5398 -{ -} - -.paragraph_class5399 -{ -} - -.text_class5400 -{ -font-family: arial; -} - -.text_class5401 -{ -font-size: 11px; -} - -.text_class5402 -{ -} - -.paragraph_class5403 -{ -} - -.text_class5404 -{ -font-family: arial; -} - -.text_class5405 -{ -font-size: 11px; -} - -.text_class5406 -{ -} - -.text_class5407 -{ -} - -.paragraph_class5408 -{ -} - -.text_class5409 -{ -font-family: arial; -} - -.text_class5410 -{ -font-size: 11px; -} - -.text_class5411 -{ -} - -.text_class5412 -{ -} - -.paragraph_class5413 -{ -} - -.text_class5414 -{ -font-size: 11px; -} - -.text_class5415 -{ -} - -.text_class5416 -{ -} - -.paragraph_class5417 -{ -} - -.text_class5418 -{ -font-size: 11px; -} - -.text_class5419 -{ -} - -.text_class5420 -{ -} - -.paragraph_class5421 -{ -} - -.text_class5422 -{ -font-size: 11px; -} - -.text_class5423 -{ -} - -.text_class5424 -{ -} - -.paragraph_class5425 -{ -} - -.text_class5426 -{ -font-size: 11px; -} - -.text_class5427 -{ -} - -.text_class5428 -{ -} - -.paragraph_class5429 -{ -} - -.text_class5430 -{ -font-size: 11px; -} - -.text_class5431 -{ -} - -.text_class5432 -{ -} - -.paragraph_class5433 -{ -} - -.text_class5434 -{ -font-size: 11px; -} - -.paragraph_class5435 -{ -} - -.text_class5436 -{ -font-size: 11px; -} - -.text_class5437 -{ -} - -.text_class5438 -{ -} - -.paragraph_class5439 -{ -} - -.text_class5440 -{ -font-size: 11px; -} - -.paragraph_class5441 -{ -} - -.text_class5442 -{ -font-size: 11px; -} - -.text_class5443 -{ -} - -.text_class5444 -{ -} - -.paragraph_class5445 -{ -} - -.text_class5446 -{ -font-family: arial; -} - -.text_class5447 -{ -font-size: 11px; -} - -.paragraph_class5448 -{ -} - -.text_class5449 -{ -font-family: arial; -} - -.text_class5450 -{ -font-size: 11px; -} - -.paragraph_class5451 -{ -} - -.text_class5452 -{ -font-family: arial; -} - -.text_class5453 -{ -font-size: 11px; -} - -.text_class5454 -{ -font-family: arial; -} - -.text_class5455 -{ -font-size: 11px; -} - -.text_class5456 -{ -font-family: arial; -} - -.text_class5457 -{ -font-size: 11px; -} - -.paragraph_class5458 -{ -} - -.text_class5459 -{ -font-family: arial; -} - -.text_class5460 -{ -font-size: 11px; -} - -.paragraph_class5461 -{ -} - -.text_class5462 -{ -font-family: arial; -} - -.text_class5463 -{ -font-size: 11px; -} - -.paragraph_class5464 -{ -} - -.text_class5465 -{ -font-family: arial; -} - -.text_class5466 -{ -font-size: 11px; -} - -.text_class5467 -{ -} - -.text_class5468 -{ -} - -.text_class5469 -{ -} - -.paragraph_class5470 -{ -} - -.text_class5471 -{ -font-family: arial; -} - -.text_class5472 -{ -font-size: 11px; -} - -.text_class5473 -{ -} - -.paragraph_class5474 -{ -} - -.text_class5475 -{ -font-family: arial; -} - -.text_class5476 -{ -font-size: 11px; -} - -.text_class5477 -{ -} - -.paragraph_class5478 -{ -} - -.text_class5479 -{ -font-family: arial; -} - -.text_class5480 -{ -font-size: 11px; -} - -.text_class5481 -{ -font-family: arial; -} - -.text_class5482 -{ -font-size: 11px; -} - -.text_class5483 -{ -font-family: arial; -} - -.text_class5484 -{ -font-size: 11px; -} - -.text_class5485 -{ -font-family: arial; -} - -.text_class5486 -{ -font-size: 11px; -} - -.text_class5487 -{ -font-family: arial; -} - -.text_class5488 -{ -font-size: 11px; -} - -.paragraph_class5489 -{ -} - -.text_class5490 -{ -font-family: arial; -} - -.text_class5491 -{ -font-size: 11px; -} - -.text_class5492 -{ -} - -.paragraph_class5493 -{ -} - -.text_class5494 -{ -font-family: arial; -} - -.text_class5495 -{ -font-size: 11px; -} - -.text_class5496 -{ -} - -.paragraph_class5497 -{ -} - -.text_class5498 -{ -font-family: arial; -} - -.text_class5499 -{ -font-size: 11px; -} - -.text_class5500 -{ -} - -.paragraph_class5501 -{ -} - -.text_class5502 -{ -font-family: arial; -} - -.text_class5503 -{ -font-size: 11px; -} - -.text_class5504 -{ -} - -.paragraph_class5505 -{ -} - -.text_class5506 -{ -font-family: arial; -} - -.text_class5507 -{ -font-size: 11px; -} - -.text_class5508 -{ -font-family: arial; -} - -.text_class5509 -{ -font-size: 11px; -} - -.text_class5510 -{ -font-family: arial; -} - -.text_class5511 -{ -font-size: 11px; -} - -.text_class5512 -{ -font-family: arial; -} - -.text_class5513 -{ -font-size: 11px; -} - -.text_class5514 -{ -font-family: arial; -} - -.text_class5515 -{ -font-size: 11px; -} - -.text_class5516 -{ -font-family: arial; -} - -.text_class5517 -{ -font-size: 11px; -} - -.text_class5518 -{ -font-family: arial; -} - -.text_class5519 -{ -font-size: 11px; -} - -.text_class5520 -{ -font-family: arial; -} - -.text_class5521 -{ -font-size: 11px; -} - -.text_class5522 -{ -} - -.paragraph_class5523 -{ -} - -.text_class5524 -{ -font-family: arial; -} - -.text_class5525 -{ -font-size: 11px; -} - -.text_class5526 -{ -} - -.paragraph_class5527 -{ -} - -.text_class5528 -{ -font-family: arial; -} - -.text_class5529 -{ -font-size: 11px; -} - -.text_class5530 -{ -font-family: arial; -} - -.text_class5531 -{ -font-size: 11px; -} - -.text_class5532 -{ -font-family: arial; -} - -.text_class5533 -{ -font-size: 11px; -} - -.text_class5534 -{ -font-family: arial; -} - -.text_class5535 -{ -font-size: 11px; -} - -.text_class5536 -{ -font-family: arial; -} - -.text_class5537 -{ -font-size: 11px; -} - -.text_class5538 -{ -font-family: arial; -} - -.text_class5539 -{ -font-size: 11px; -} - -.text_class5540 -{ -} - -.paragraph_class5541 -{ -} - -.text_class5542 -{ -font-family: arial; -} - -.text_class5543 -{ -font-size: 11px; -} - -.text_class5544 -{ -} - -.paragraph_class5545 -{ -} - -.text_class5546 -{ -font-family: arial; -} - -.text_class5547 -{ -font-size: 11px; -} - -.list_detail_class5548 -{ -} - -.paragraph_class5549 -{ -} - -.text_class5550 -{ -font-family: arial; -} - -.text_class5551 -{ -font-size: 11px; -} - -.text_class5552 -{ -font-size: 11px; -} - -.paragraph_class5553 -{ -} - -.text_class5554 -{ -font-family: arial; -} - -.text_class5555 -{ -font-size: 11px; -} - -.text_class5556 -{ -font-size: 11px; -} - -.paragraph_class5557 -{ -} - -.text_class5558 -{ -font-family: arial; -} - -.text_class5559 -{ -font-size: 11px; -} - -.paragraph_class5560 -{ -} - -.text_class5561 -{ -} - -.paragraph_class5562 -{ -} - -.text_class5563 -{ -font-size: 11px; -} - -.text_class5564 -{ -font-size: 11px; -} - -.text_class5565 -{ -font-size: 11px; -} - -.text_class5566 -{ -font-size: 11px; -} - -.text_class5567 -{ -font-size: 11px; -} - -.text_class5568 -{ -font-size: 11px; -} - -.text_class5569 -{ -} - -.text_class5570 -{ -} - -.paragraph_class5571 -{ -} - -.text_class5572 -{ -font-family: arial; -} - -.text_class5573 -{ -font-size: 11px; -} - -.text_class5574 -{ -font-family: arial; -} - -.text_class5575 -{ -font-size: 11px; -} - -.text_class5576 -{ -font-size: 11px; -} - -.text_class5577 -{ -font-size: 11px; -} - -.paragraph_class5578 -{ -} - -.text_class5579 -{ -font-family: arial; -} - -.text_class5580 -{ -font-size: 11px; -} - -.text_class5581 -{ -} - -.paragraph_class5582 -{ -} - -.text_class5583 -{ -font-family: arial; -} - -.text_class5584 -{ -font-size: 11px; -} - -.paragraph_class5585 -{ -} - -.text_class5586 -{ -font-family: arial; -} - -.text_class5587 -{ -font-size: 11px; -} - -.text_class5588 -{ -font-size: 11px; -} - -.hyperlink_class5589 -{ -} - -.text_class5590 -{ -font-family: arial; -} - -.text_class5591 -{ -font-size: 11px; -} - -.text_class5592 -{ -font-family: arial; -} - -.text_class5593 -{ -font-size: 11px; -} - -.text_class5594 -{ -} - -.text_class5595 -{ -} - -.paragraph_class5596 -{ -} - -.text_class5597 -{ -font-family: arial; -} - -.text_class5598 -{ -font-size: 11px; -} - -.text_class5599 -{ -font-family: arial; -} - -.text_class5600 -{ -font-size: 11px; -} - -.text_class5601 -{ -font-family: arial; -} - -.text_class5602 -{ -font-size: 11px; -} - -.paragraph_class5603 -{ -} - -.text_class5604 -{ -font-family: arial; -} - -.text_class5605 -{ -font-size: 11px; -} - -.text_class5606 -{ -font-size: 11px; -} - -.paragraph_class5607 -{ -} - -.text_class5608 -{ -font-family: arial; -} - -.text_class5609 -{ -font-size: 11px; -} - -.text_class5610 -{ -} - -.paragraph_class5611 -{ -} - -.text_class5612 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5613 -{ -font-family: arial; -} - -.text_class5614 -{ -font-size: 11px; -} - -.text_class5615 -{ -font-family: arial; -} - -.text_class5616 -{ -font-size: 11px; -} - -.text_class5617 -{ -font-family: arial; -} - -.text_class5618 -{ -font-size: 11px; -} - -.text_class5619 -{ -font-family: arial; -} - -.text_class5620 -{ -font-size: 11px; -} - -.text_class5621 -{ -} - -.text_class5622 -{ -} - -.paragraph_class5623 -{ -} - -.paragraph_class5624 -{ -} - -.text_class5625 -{ -} - -.paragraph_class5626 -{ -} - -.text_class5627 -{ -} - -.paragraph_class5628 -{ -} - -.text_class5629 -{ -} - -.paragraph_class5630 -{ -} - -.text_class5631 -{ -} - -.paragraph_class5632 -{ -} - -.text_class5633 -{ -} - -.paragraph_class5634 -{ -} - -.text_class5635 -{ -} - -.paragraph_class5636 -{ -} - -.text_class5637 -{ -} - -.paragraph_class5638 -{ -} - -.text_class5639 -{ -} - -.text_class5640 -{ -} - -.paragraph_class5641 -{ -} - -.text_class5642 -{ -font-size: 11px; -} - -.text_class5643 -{ -} - -.text_class5644 -{ -} - -.paragraph_class5645 -{ -} - -.text_class5646 -{ -font-size: 11px; -} - -.text_class5647 -{ -} - -.text_class5648 -{ -} - -.paragraph_class5649 -{ -} - -.text_class5650 -{ -font-size: 11px; -} - -.paragraph_class5651 -{ -} - -.paragraph_class5652 -{ -} - -.text_class5653 -{ -font-size: 15px; -} - -.text_class5654 -{ -} - -.text_class5655 -{ -} - -.paragraph_class5656 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5657 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5658 -{ -font-weight: bold; -} - -.text_class5659 -{ -} - -.paragraph_class5660 -{ -} - -.text_class5661 -{ -font-family: arial; -} - -.text_class5662 -{ -font-size: 11px; -} - -.paragraph_class5663 -{ -} - -.text_class5664 -{ -font-family: arial; -} - -.text_class5665 -{ -font-size: 11px; -} - -.paragraph_class5666 -{ -} - -.text_class5667 -{ -font-family: arial; -} - -.text_class5668 -{ -font-size: 11px; -} - -.paragraph_class5669 -{ -} - -.text_class5670 -{ -font-family: arial; -} - -.text_class5671 -{ -font-size: 11px; -} - -.paragraph_class5672 -{ -} - -.text_class5673 -{ -font-family: arial; -} - -.text_class5674 -{ -font-size: 11px; -} - -.paragraph_class5675 -{ -} - -.text_class5676 -{ -font-family: arial; -} - -.text_class5677 -{ -font-size: 11px; -} - -.paragraph_class5678 -{ -} - -.text_class5679 -{ -font-family: arial; -} - -.text_class5680 -{ -font-size: 11px; -} - -.paragraph_class5681 -{ -} - -.paragraph_class5682 -{ -} - -.text_class5683 -{ -font-family: arial; -} - -.text_class5684 -{ -font-size: 11px; -} - -.text_class5685 -{ -} - -.text_class5686 -{ -} - -.paragraph_class5687 -{ -} - -.text_class5688 -{ -font-family: arial; -} - -.text_class5689 -{ -font-size: 11px; -} - -.text_class5690 -{ -font-family: arial; -} - -.text_class5691 -{ -font-size: 11px; -} - -.paragraph_class5692 -{ -} - -.text_class5693 -{ -font-family: arial; -} - -.text_class5694 -{ -font-size: 11px; -} - -.paragraph_class5695 -{ -} - -.text_class5696 -{ -font-family: arial; -} - -.text_class5697 -{ -font-size: 11px; -} - -.text_class5698 -{ -font-family: arial; -} - -.text_class5699 -{ -font-size: 11px; -} - -.text_class5700 -{ -font-family: arial; -} - -.text_class5701 -{ -font-size: 11px; -} - -.text_class5702 -{ -} - -.text_class5703 -{ -} - -.paragraph_class5704 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5705 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5706 -{ -font-weight: bold; -} - -.text_class5707 -{ -} - -.paragraph_class5708 -{ -} - -.text_class5709 -{ -font-family: arial; -} - -.text_class5710 -{ -font-size: 11px; -} - -.paragraph_class5711 -{ -} - -.paragraph_class5712 -{ -font-weight: bold; -} - -.text_class5713 -{ -font-family: arial; -} - -.text_class5714 -{ -font-size: 11px; -} - -.paragraph_class5715 -{ -} - -.text_class5716 -{ -font-family: arial; -} - -.text_class5717 -{ -font-size: 11px; -} - -.paragraph_class5718 -{ -} - -.text_class5719 -{ -font-family: arial; -} - -.text_class5720 -{ -font-size: 11px; -} - -.paragraph_class5721 -{ -} - -.text_class5722 -{ -font-family: arial; -} - -.text_class5723 -{ -font-size: 11px; -} - -.paragraph_class5724 -{ -} - -.text_class5725 -{ -font-family: arial; -} - -.text_class5726 -{ -font-size: 11px; -} - -.hyperlink_class5727 -{ -} - -.text_class5728 -{ -} - -.paragraph_class5729 -{ -} - -.text_class5730 -{ -font-family: arial; -} - -.text_class5731 -{ -font-size: 11px; -} - -.paragraph_class5732 -{ -} - -.text_class5733 -{ -font-family: arial; -} - -.text_class5734 -{ -font-size: 11px; -} - -.text_class5735 -{ -font-family: arial; -} - -.text_class5736 -{ -font-size: 11px; -} - -.text_class5737 -{ -font-family: arial; -} - -.text_class5738 -{ -font-size: 11px; -} - -.text_class5739 -{ -} - -.cell_class5740 -{ -width: 76px; -background-color: #bfbfbf; -} - -.paragraph_class5742 -{ -margin-left: 0px; -} - -.text_class5743 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5744 -{ -font-weight: bold; -} - -.cell_class5745 -{ -width: 182px; -background-color: #bfbfbf; -} - -.paragraph_class5747 -{ -margin-left: 0px; -} - -.text_class5748 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5749 -{ -font-weight: bold; -} - -.cell_class5750 -{ -width: 317px; -background-color: #bfbfbf; -} - -.paragraph_class5752 -{ -margin-left: 0px; -} - -.text_class5753 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5754 -{ -font-weight: bold; -} - -.cell_class5755 -{ -width: 76px; -} - -.paragraph_class5756 -{ -margin-left: 0px; -} - -.text_class5757 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5758 -{ -width: 182px; -} - -.paragraph_class5759 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5760 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5761 -{ -width: 317px; -} - -.paragraph_class5762 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5763 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5764 -{ -margin-left: 0px; -} - -.text_class5765 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5766 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5767 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5768 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5769 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5770 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5771 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5772 -{ -margin-left: 0px; -} - -.text_class5773 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5774 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5775 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5776 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5777 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5778 -{ -margin-left: 0px; -} - -.text_class5779 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5780 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5781 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5782 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5783 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5784 -{ -margin-left: 0px; -} - -.text_class5785 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5786 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5787 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5788 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5789 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5790 -{ -margin-left: 0px; -} - -.text_class5791 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5792 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5793 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5794 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5795 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5796 -{ -margin-left: 0px; -} - -.text_class5797 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5798 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5799 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5800 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5801 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5802 -{ -margin-left: 0px; -} - -.text_class5803 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5804 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5805 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5806 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5807 -{ -font-size: 10px; -font-family: arial; -} - -.paragraph_class5808 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5809 -{ -font-size: 10px; -font-family: arial; -} - -.paragraph_class5810 -{ -margin-left: 0px; -} - -.text_class5811 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5812 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5813 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5814 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5815 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5816 -{ -margin-left: 0px; -} - -.text_class5817 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5818 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5819 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5820 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5821 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5822 -{ -} - -.paragraph_class5823 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5824 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5825 -{ -font-weight: bold; -} - -.text_class5826 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5827 -{ -font-weight: bold; -} - -.text_class5828 -{ -} - -.paragraph_class5829 -{ -} - -.paragraph_class5830 -{ -} - -.text_class5831 -{ -} - -.paragraph_class5832 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5833 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5834 -{ -font-weight: bold; -} - -.text_class5835 -{ -} - -.paragraph_class5836 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5837 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5838 -{ -} - -.paragraph_class5839 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5840 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5841 -{ -font-weight: bold; -} - -.text_class5842 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5843 -{ -font-weight: bold; -} - -.text_class5844 -{ -} - -.cell_class5845 -{ -width: 49px; -background-color: #bfbfbf; -} - -.paragraph_class5847 -{ -margin-left: 0px; -} - -.text_class5848 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5849 -{ -font-weight: bold; -} - -.paragraph_class5851 -{ -margin-left: 0px; -} - -.text_class5852 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5853 -{ -font-weight: bold; -} - -.cell_class5854 -{ -width: 357px; -background-color: #bfbfbf; -} - -.paragraph_class5856 -{ -margin-left: 0px; -} - -.text_class5857 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.text_class5858 -{ -font-weight: bold; -} - -.paragraph_class5859 -{ -margin-left: 0px; -} - -.text_class5860 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5861 -{ -width: 168px; -} - -.paragraph_class5862 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5863 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.cell_class5864 -{ -width: 357px; -} - -.paragraph_class5865 -{ -margin-left: 0px; -} - -.text_class5866 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5867 -{ -margin-left: 0px; -} - -.text_class5868 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5869 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5870 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5871 -{ -margin-left: 0px; -} - -.text_class5872 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5873 -{ -margin-left: 0px; -} - -.text_class5874 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5875 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5876 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5877 -{ -margin-left: 0px; -} - -.text_class5878 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5879 -{ -margin-left: 0px; -} - -.text_class5880 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5881 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5882 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5883 -{ -margin-left: 0px; -} - -.text_class5884 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5885 -{ -margin-left: 0px; -} - -.text_class5886 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5887 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5888 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5889 -{ -margin-left: 0px; -} - -.text_class5890 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5891 -{ -margin-left: 0px; -} - -.text_class5892 -{ -color: #000000; -font-size: 11px; -font-family: arial; -} - -.paragraph_class5893 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class5894 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class5895 -{ -margin-left: 0px; -} - -.text_class5896 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5897 -{ -} - -.text_class5898 -{ -} - -.paragraph_class5899 -{ -} - -.text_class5900 -{ -font-family: arial; -} - -.text_class5901 -{ -font-size: 11px; -} - -.paragraph_class5902 -{ -} - -.text_class5903 -{ -font-family: arial; -} - -.text_class5904 -{ -font-size: 11px; -} - -.paragraph_class5905 -{ -} - -.text_class5906 -{ -font-family: arial; -} - -.text_class5907 -{ -font-size: 11px; -} - -.text_class5908 -{ -} - -.text_class5909 -{ -} - -.paragraph_class5910 -{ -text-align: center; -margin-left: 0px; -} - -.text_class5911 -{ -font-size: 11px; -font-family: arial; -} - -.text_class5912 -{ -font-weight: bold; -} - -.text_class5913 -{ -} - -.text_class5914 -{ -} - -.text_class5915 -{ -} - -.paragraph_class5916 -{ -} - -.text_class5917 -{ -font-family: arial; -} - -.text_class5918 -{ -font-size: 11px; -} - -.text_class5919 -{ -} - -.text_class5920 -{ -font-family: arial; -} - -.text_class5921 -{ -font-size: 11px; -} - -.text_class5922 -{ -font-family: ｍｓ ｐ明朝; -} - -.text_class5923 -{ -font-size: 11px; -} - -.text_class5924 -{ -font-family: arial; -} - -.text_class5925 -{ -font-size: 11px; -} - -.text_class5926 -{ -font-family: ｍｓ ｐ明朝; -} - -.text_class5927 -{ -font-size: 11px; -} - -.text_class5928 -{ -font-family: arial; -} - -.text_class5929 -{ -font-size: 11px; -} - -.text_class5930 -{ -font-family: arial; -} - -.text_class5931 -{ -font-size: 11px; -} - -.text_class5932 -{ -font-family: arial; -} - -.text_class5933 -{ -font-size: 11px; -} - -.text_class5934 -{ -font-family: arial; -} - -.text_class5935 -{ -font-size: 11px; -} - -.text_class5936 -{ -font-family: arial; -} - -.text_class5937 -{ -font-size: 11px; -} - -.text_class5938 -{ -font-family: arial; -} - -.text_class5939 -{ -font-size: 11px; -} - -.text_class5940 -{ -font-family: arial; -} - -.text_class5941 -{ -font-size: 11px; -} - -.text_class5942 -{ -} - -.text_class5943 -{ -font-family: arial; -} - -.text_class5944 -{ -font-size: 11px; -} - -.text_class5945 -{ -font-family: arial; -} - -.text_class5946 -{ -font-size: 11px; -} - -.text_class5947 -{ -font-family: arial; -} - -.text_class5948 -{ -font-size: 11px; -} - -.text_class5949 -{ -font-family: arial; -} - -.text_class5950 -{ -font-size: 11px; -} - -.text_class5951 -{ -font-family: arial; -} - -.text_class5952 -{ -font-size: 11px; -} - -.text_class5953 -{ -font-family: arial; -} - -.text_class5954 -{ -font-size: 11px; -} - -.text_class5955 -{ -font-family: arial; -} - -.text_class5956 -{ -font-size: 11px; -} - -.text_class5957 -{ -font-family: arial; -} - -.text_class5958 -{ -font-size: 11px; -} - -.text_class5959 -{ -font-family: arial; -} - -.text_class5960 -{ -font-size: 11px; -} - -.text_class5961 -{ -font-family: arial; -} - -.text_class5962 -{ -font-size: 11px; -} - -.text_class5963 -{ -font-family: arial; -} - -.text_class5964 -{ -font-size: 11px; -} - -.text_class5965 -{ -} - -.text_class5966 -{ -font-family: arial; -} - -.text_class5967 -{ -font-size: 11px; -} - -.text_class5968 -{ -font-family: arial; -} - -.text_class5969 -{ -font-size: 11px; -} - -.text_class5970 -{ -font-family: arial; -} - -.text_class5971 -{ -font-size: 11px; -} - -.text_class5972 -{ -} - -.text_class5973 -{ -font-family: arial; -} - -.text_class5974 -{ -font-size: 11px; -} - -.text_class5975 -{ -font-family: arial; -} - -.text_class5976 -{ -font-size: 11px; -} - -.text_class5977 -{ -font-family: arial; -} - -.text_class5978 -{ -font-size: 11px; -} - -.text_class5979 -{ -} - -.text_class5980 -{ -font-family: arial; -} - -.text_class5981 -{ -font-size: 11px; -} - -.text_class5982 -{ -font-family: arial; -} - -.text_class5983 -{ -font-size: 11px; -} - -.text_class5984 -{ -font-family: arial; -} - -.text_class5985 -{ -font-size: 11px; -} - -.text_class5986 -{ -font-family: ｍｓ ｐ明朝; -} - -.text_class5987 -{ -font-size: 11px; -} - -.text_class5988 -{ -font-family: arial; -} - -.text_class5989 -{ -font-size: 11px; -} - -.text_class5990 -{ -font-family: ｍｓ ｐ明朝; -} - -.text_class5991 -{ -font-size: 11px; -} - -.text_class5992 -{ -font-family: arial; -} - -.text_class5993 -{ -font-size: 11px; -} - -.text_class5994 -{ -font-family: arial; -} - -.text_class5995 -{ -font-size: 11px; -} - -.text_class5996 -{ -font-family: ｍｓ ｐ明朝; -} - -.text_class5997 -{ -font-size: 11px; -} - -.text_class5998 -{ -font-family: arial; -} - -.text_class5999 -{ -font-size: 11px; -} - -.text_class6000 -{ -font-family: ｍｓ ｐ明朝; -} - -.text_class6001 -{ -font-size: 11px; -} - -.text_class6002 -{ -font-family: arial; -} - -.text_class6003 -{ -font-size: 11px; -} - -.paragraph_class6004 -{ -} - -.text_class6005 -{ -font-family: arial; -} - -.text_class6006 -{ -font-size: 11px; -} - -.text_class6007 -{ -} - -.text_class6008 -{ -font-family: arial; -} - -.text_class6009 -{ -font-size: 11px; -} - -.text_class6010 -{ -font-family: arial; -} - -.text_class6011 -{ -font-size: 11px; -} - -.text_class6012 -{ -font-family: arial; -} - -.text_class6013 -{ -font-size: 11px; -} - -.paragraph_class6014 -{ -} - -.text_class6015 -{ -font-family: arial; -} - -.text_class6016 -{ -font-size: 11px; -} - -.text_class6017 -{ -} - -.paragraph_class6018 -{ -} - -.text_class6019 -{ -font-family: arial; -} - -.text_class6020 -{ -font-size: 11px; -} - -.text_class6021 -{ -font-family: arial; -} - -.text_class6022 -{ -font-size: 11px; -} - -.text_class6023 -{ -} - -.paragraph_class6024 -{ -} - -.text_class6025 -{ -font-family: arial; -} - -.text_class6026 -{ -font-size: 11px; -} - -.text_class6027 -{ -font-family: arial; -} - -.text_class6028 -{ -font-size: 11px; -} - -.paragraph_class6029 -{ -} - -.text_class6030 -{ -font-family: arial; -} - -.text_class6031 -{ -font-size: 11px; -} - -.text_class6032 -{ -font-family: arial; -} - -.text_class6033 -{ -font-size: 11px; -} - -.text_class6034 -{ -font-family: arial; -} - -.text_class6035 -{ -font-size: 11px; -} - -.text_class6036 -{ -font-family: arial; -} - -.text_class6037 -{ -font-size: 11px; -} - -.text_class6038 -{ -font-family: arial; -} - -.text_class6039 -{ -font-size: 11px; -} - -.text_class6040 -{ -font-family: arial; -} - -.text_class6041 -{ -font-size: 11px; -} - -.text_class6042 -{ -font-family: arial; -} - -.text_class6043 -{ -font-size: 11px; -} - -.text_class6044 -{ -font-family: arial; -} - -.text_class6045 -{ -font-size: 11px; -} - -.paragraph_class6046 -{ -} - -.text_class6047 -{ -font-family: arial; -} - -.text_class6048 -{ -font-size: 11px; -} - -.text_class6049 -{ -} - -.text_class6050 -{ -font-family: arial; -} - -.text_class6051 -{ -font-size: 11px; -} - -.text_class6052 -{ -font-family: arial; -} - -.text_class6053 -{ -font-size: 11px; -} - -.text_class6054 -{ -font-family: arial; -} - -.text_class6055 -{ -font-size: 11px; -} - -.text_class6056 -{ -} - -.text_class6057 -{ -font-family: arial; -} - -.text_class6058 -{ -font-size: 11px; -} - -.text_class6059 -{ -font-family: arial; -} - -.text_class6060 -{ -font-size: 11px; -} - -.text_class6061 -{ -font-family: arial; -} - -.text_class6062 -{ -font-size: 11px; -} - -.text_class6063 -{ -font-family: arial; -} - -.text_class6064 -{ -font-size: 11px; -} - -.text_class6065 -{ -font-family: arial; -} - -.text_class6066 -{ -font-size: 11px; -} - -.text_class6067 -{ -font-family: arial; -} - -.text_class6068 -{ -font-size: 11px; -} - -.text_class6069 -{ -} - -.text_class6070 -{ -} - -.paragraph_class6071 -{ -} - -.text_class6072 -{ -font-family: arial; -} - -.text_class6073 -{ -font-size: 11px; -} - -.text_class6074 -{ -} - -.paragraph_class6075 -{ -} - -.text_class6076 -{ -font-family: arial; -} - -.text_class6077 -{ -font-size: 11px; -} - -.text_class6078 -{ -} - -.paragraph_class6079 -{ -} - -.text_class6080 -{ -font-family: arial; -} - -.text_class6081 -{ -font-size: 11px; -} - -.text_class6082 -{ -} - -.paragraph_class6083 -{ -} - -.text_class6084 -{ -font-family: arial; -} - -.text_class6085 -{ -font-size: 11px; -} - -.text_class6086 -{ -} - -.paragraph_class6087 -{ -} - -.text_class6088 -{ -font-family: arial; -} - -.text_class6089 -{ -font-size: 11px; -} - -.text_class6090 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6091 -{ -} - -.paragraph_class6092 -{ -} - -.text_class6093 -{ -font-family: arial; -} - -.text_class6094 -{ -font-size: 11px; -} - -.text_class6095 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6096 -{ -} - -.text_class6097 -{ -} - -.paragraph_class6098 -{ -} - -.text_class6099 -{ -font-size: 11px; -} - -.text_class6100 -{ -} - -.paragraph_class6101 -{ -} - -.text_class6102 -{ -font-family: arial; -} - -.text_class6103 -{ -font-size: 10px; -} - -.text_class6104 -{ -} - -.paragraph_class6105 -{ -} - -.text_class6106 -{ -font-family: arial; -} - -.text_class6107 -{ -font-size: 10px; -} - -.text_class6108 -{ -} - -.text_class6109 -{ -} - -.paragraph_class6110 -{ -} - -.text_class6111 -{ -font-size: 11px; -} - -.text_class6112 -{ -} - -.text_class6113 -{ -} - -.paragraph_class6114 -{ -} - -.text_class6115 -{ -font-size: 11px; -} - -.text_class6116 -{ -} - -.paragraph_class6117 -{ -} - -.text_class6118 -{ -font-size: 11px; -} - -.text_class6119 -{ -} - -.paragraph_class6120 -{ -} - -.text_class6121 -{ -font-size: 11px; -} - -.text_class6122 -{ -} - -.text_class6123 -{ -} - -.paragraph_class6124 -{ -} - -.text_class6125 -{ -font-size: 11px; -} - -.text_class6126 -{ -font-size: 11px; -} - -.text_class6127 -{ -} - -.paragraph_class6128 -{ -} - -.text_class6129 -{ -font-size: 11px; -} - -.paragraph_class6130 -{ -} - -.text_class6131 -{ -font-size: 11px; -} - -.paragraph_class6132 -{ -} - -.text_class6133 -{ -font-size: 11px; -} - -.paragraph_class6134 -{ -} - -.text_class6135 -{ -font-size: 11px; -} - -.text_class6136 -{ -} - -.paragraph_class6137 -{ -} - -.text_class6138 -{ -font-size: 11px; -} - -.text_class6139 -{ -} - -.paragraph_class6140 -{ -} - -.text_class6141 -{ -font-size: 11px; -} - -.text_class6142 -{ -} - -.paragraph_class6143 -{ -} - -.text_class6144 -{ -font-size: 11px; -} - -.text_class6145 -{ -font-size: 11px; -} - -.text_class6146 -{ -font-size: 11px; -} - -.text_class6147 -{ -} - -.paragraph_class6148 -{ -} - -.text_class6149 -{ -font-size: 11px; -} - -.text_class6150 -{ -font-size: 11px; -} - -.text_class6151 -{ -font-size: 11px; -} - -.text_class6152 -{ -font-size: 11px; -} - -.text_class6153 -{ -font-size: 11px; -} - -.text_class6154 -{ -font-size: 11px; -} - -.text_class6155 -{ -font-size: 11px; -} - -.text_class6156 -{ -font-size: 11px; -} - -.text_class6157 -{ -} - -.paragraph_class6158 -{ -} - -.text_class6159 -{ -font-size: 11px; -} - -.text_class6160 -{ -font-size: 11px; -} - -.text_class6161 -{ -font-size: 11px; -} - -.text_class6162 -{ -font-size: 11px; -} - -.text_class6163 -{ -font-size: 11px; -} - -.text_class6164 -{ -font-size: 11px; -} - -.text_class6165 -{ -font-size: 11px; -} - -.text_class6166 -{ -font-size: 11px; -} - -.text_class6167 -{ -font-size: 11px; -} - -.text_class6168 -{ -font-size: 11px; -} - -.text_class6169 -{ -} - -.paragraph_class6170 -{ -} - -.text_class6171 -{ -font-size: 11px; -} - -.text_class6172 -{ -} - -.paragraph_class6173 -{ -} - -.text_class6174 -{ -font-size: 11px; -} - -.text_class6175 -{ -} - -.paragraph_class6176 -{ -} - -.text_class6177 -{ -font-size: 11px; -} - -.text_class6178 -{ -} - -.paragraph_class6179 -{ -} - -.text_class6180 -{ -font-size: 11px; -} - -.text_class6181 -{ -font-size: 11px; -} - -.text_class6182 -{ -font-size: 11px; -} - -.text_class6183 -{ -font-size: 11px; -} - -.text_class6184 -{ -font-size: 11px; -} - -.text_class6185 -{ -} - -.paragraph_class6186 -{ -} - -.text_class6187 -{ -font-size: 11px; -} - -.text_class6188 -{ -font-size: 11px; -} - -.text_class6189 -{ -font-size: 11px; -} - -.text_class6190 -{ -font-size: 11px; -} - -.text_class6191 -{ -font-size: 11px; -} - -.text_class6192 -{ -} - -.paragraph_class6193 -{ -} - -.text_class6194 -{ -font-size: 11px; -} - -.paragraph_class6195 -{ -} - -.text_class6196 -{ -} - -.paragraph_class6197 -{ -} - -.text_class6198 -{ -font-size: 11px; -} - -.text_class6199 -{ -} - -.paragraph_class6200 -{ -} - -.text_class6201 -{ -font-size: 11px; -} - -.text_class6202 -{ -} - -.paragraph_class6203 -{ -} - -.text_class6204 -{ -font-size: 11px; -} - -.text_class6205 -{ -} - -.paragraph_class6206 -{ -} - -.text_class6207 -{ -font-size: 11px; -} - -.text_class6208 -{ -font-size: 11px; -} - -.text_class6209 -{ -font-size: 11px; -} - -.text_class6210 -{ -font-size: 11px; -} - -.text_class6211 -{ -font-size: 11px; -} - -.text_class6212 -{ -font-size: 11px; -} - -.text_class6213 -{ -font-size: 11px; -} - -.text_class6214 -{ -font-size: 11px; -} - -.paragraph_class6215 -{ -} - -.text_class6216 -{ -font-size: 11px; -} - -.text_class6217 -{ -} - -.paragraph_class6218 -{ -} - -.text_class6219 -{ -font-size: 11px; -} - -.text_class6220 -{ -} - -.paragraph_class6221 -{ -} - -.text_class6222 -{ -font-size: 11px; -} - -.text_class6223 -{ -} - -.paragraph_class6224 -{ -} - -.text_class6225 -{ -font-size: 11px; -} - -.text_class6226 -{ -} - -.paragraph_class6227 -{ -} - -.text_class6228 -{ -font-size: 11px; -} - -.text_class6229 -{ -} - -.paragraph_class6230 -{ -} - -.text_class6231 -{ -font-size: 11px; -} - -.text_class6232 -{ -} - -.paragraph_class6233 -{ -} - -.text_class6234 -{ -font-size: 11px; -} - -.text_class6235 -{ -} - -.paragraph_class6236 -{ -} - -.text_class6237 -{ -font-size: 11px; -} - -.text_class6238 -{ -} - -.paragraph_class6239 -{ -} - -.text_class6240 -{ -font-size: 11px; -} - -.text_class6241 -{ -} - -.paragraph_class6242 -{ -} - -.text_class6243 -{ -font-size: 11px; -} - -.text_class6244 -{ -} - -.paragraph_class6245 -{ -} - -.text_class6246 -{ -font-size: 11px; -} - -.text_class6247 -{ -} - -.paragraph_class6248 -{ -} - -.text_class6249 -{ -font-size: 11px; -} - -.text_class6250 -{ -} - -.paragraph_class6251 -{ -} - -.text_class6252 -{ -font-size: 11px; -} - -.text_class6253 -{ -} - -.paragraph_class6254 -{ -} - -.text_class6255 -{ -font-size: 11px; -} - -.text_class6256 -{ -} - -.paragraph_class6257 -{ -} - -.text_class6258 -{ -font-size: 11px; -} - -.text_class6259 -{ -} - -.paragraph_class6260 -{ -} - -.text_class6261 -{ -font-size: 11px; -} - -.text_class6262 -{ -} - -.paragraph_class6263 -{ -} - -.text_class6264 -{ -font-size: 11px; -} - -.text_class6265 -{ -} - -.paragraph_class6266 -{ -} - -.text_class6267 -{ -font-size: 11px; -} - -.text_class6268 -{ -} - -.paragraph_class6269 -{ -} - -.text_class6270 -{ -font-size: 11px; -} - -.text_class6271 -{ -} - -.paragraph_class6272 -{ -} - -.text_class6273 -{ -font-size: 11px; -} - -.text_class6274 -{ -} - -.paragraph_class6275 -{ -} - -.text_class6276 -{ -font-size: 11px; -} - -.text_class6277 -{ -} - -.paragraph_class6278 -{ -} - -.text_class6279 -{ -font-size: 11px; -} - -.text_class6280 -{ -} - -.paragraph_class6281 -{ -} - -.text_class6282 -{ -font-size: 11px; -} - -.text_class6283 -{ -} - -.paragraph_class6284 -{ -} - -.text_class6285 -{ -font-size: 11px; -} - -.text_class6286 -{ -} - -.paragraph_class6287 -{ -} - -.text_class6288 -{ -font-size: 11px; -} - -.text_class6289 -{ -} - -.paragraph_class6290 -{ -} - -.text_class6291 -{ -} - -.paragraph_class6292 -{ -} - -.text_class6293 -{ -font-size: 11px; -} - -.text_class6294 -{ -} - -.paragraph_class6295 -{ -} - -.text_class6296 -{ -font-size: 11px; -} - -.text_class6297 -{ -} - -.paragraph_class6298 -{ -} - -.text_class6299 -{ -font-size: 11px; -} - -.text_class6300 -{ -} - -.text_class6301 -{ -} - -.paragraph_class6302 -{ -} - -.text_class6303 -{ -font-size: 11px; -} - -.text_class6304 -{ -font-size: 11px; -} - -.text_class6305 -{ -font-size: 11px; -} - -.text_class6306 -{ -font-size: 11px; -} - -.text_class6307 -{ -font-size: 11px; -} - -.text_class6308 -{ -font-size: 11px; -} - -.text_class6309 -{ -} - -.paragraph_class6310 -{ -} - -.text_class6311 -{ -font-size: 11px; -} - -.text_class6312 -{ -font-size: 11px; -} - -.text_class6313 -{ -font-size: 11px; -} - -.text_class6314 -{ -font-size: 11px; -} - -.text_class6315 -{ -} - -.paragraph_class6316 -{ -} - -.text_class6317 -{ -font-size: 11px; -} - -.text_class6318 -{ -} - -.paragraph_class6319 -{ -} - -.text_class6320 -{ -font-size: 11px; -} - -.text_class6321 -{ -} - -.paragraph_class6322 -{ -} - -.text_class6323 -{ -font-size: 11px; -} - -.text_class6324 -{ -} - -.paragraph_class6325 -{ -} - -.text_class6326 -{ -font-size: 11px; -} - -.text_class6327 -{ -font-size: 11px; -} - -.text_class6328 -{ -font-size: 11px; -} - -.text_class6329 -{ -font-size: 11px; -} - -.text_class6330 -{ -font-size: 11px; -} - -.text_class6331 -{ -} - -.paragraph_class6332 -{ -} - -.text_class6333 -{ -font-size: 11px; -} - -.text_class6334 -{ -font-size: 11px; -} - -.text_class6335 -{ -font-size: 11px; -} - -.text_class6336 -{ -font-size: 11px; -} - -.text_class6337 -{ -} - -.text_class6338 -{ -} - -.paragraph_class6339 -{ -} - -.text_class6340 -{ -font-family: arial; -} - -.text_class6341 -{ -font-size: 11px; -} - -.text_class6342 -{ -font-size: 11px; -} - -.text_class6343 -{ -} - -.text_class6344 -{ -font-family: arial; -} - -.text_class6345 -{ -font-size: 11px; -} - -.paragraph_class6346 -{ -} - -.text_class6347 -{ -font-size: 11px; -} - -.text_class6348 -{ -font-family: arial; -} - -.paragraph_class6349 -{ -} - -.text_class6350 -{ -font-size: 11px; -} - -.text_class6351 -{ -font-family: arial; -} - -.paragraph_class6352 -{ -} - -.text_class6353 -{ -font-size: 11px; -} - -.paragraph_class6354 -{ -} - -.text_class6355 -{ -font-size: 11px; -} - -.text_class6356 -{ -} - -.text_class6357 -{ -} - -.paragraph_class6358 -{ -text-align: center; -margin-left: 0px; -} - -.text_class6359 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6360 -{ -font-weight: bold; -} - -.text_class6361 -{ -} - -.text_class6362 -{ -} - -.paragraph_class6363 -{ -} - -.text_class6364 -{ -font-family: arial; -} - -.text_class6365 -{ -font-size: 11px; -} - -.text_class6366 -{ -font-family: arial; -} - -.text_class6367 -{ -font-size: 11px; -} - -.text_class6368 -{ -} - -.text_class6369 -{ -font-family: arial; -} - -.text_class6370 -{ -font-size: 11px; -} - -.text_class6371 -{ -font-family: arial; -} - -.text_class6372 -{ -font-size: 11px; -} - -.text_class6373 -{ -font-family: arial; -} - -.text_class6374 -{ -font-size: 11px; -} - -.text_class6375 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6376 -{ -margin-left: 26px; -} - -.paragraph_class6377 -{ -} - -.text_class6378 -{ -font-family: arial; -} - -.text_class6379 -{ -font-size: 11px; -} - -.paragraph_class6380 -{ -} - -.text_class6381 -{ -font-size: 11px; -} - -.text_class6382 -{ -font-size: 11px; -} - -.paragraph_class6383 -{ -} - -.text_class6384 -{ -font-family: arial; -} - -.text_class6385 -{ -font-size: 11px; -} - -.paragraph_class6386 -{ -} - -.text_class6387 -{ -font-size: 11px; -} - -.text_class6388 -{ -font-size: 11px; -} - -.paragraph_class6389 -{ -} - -.text_class6390 -{ -font-family: arial; -} - -.text_class6391 -{ -font-size: 11px; -} - -.paragraph_class6392 -{ -} - -.text_class6393 -{ -font-size: 11px; -} - -.text_class6394 -{ -font-size: 11px; -} - -.paragraph_class6395 -{ -} - -.text_class6396 -{ -font-family: arial; -} - -.text_class6397 -{ -font-size: 11px; -} - -.paragraph_class6398 -{ -} - -.text_class6399 -{ -font-size: 11px; -} - -.text_class6400 -{ -font-size: 11px; -} - -.paragraph_class6401 -{ -} - -.text_class6402 -{ -font-family: arial; -} - -.text_class6403 -{ -font-size: 11px; -} - -.text_class6404 -{ -} - -.text_class6405 -{ -} - -.paragraph_class6406 -{ -} - -.text_class6407 -{ -font-family: arial; -} - -.text_class6408 -{ -font-size: 11px; -} - -.text_class6409 -{ -} - -.text_class6410 -{ -} - -.paragraph_class6411 -{ -} - -.text_class6412 -{ -font-family: arial; -} - -.text_class6413 -{ -font-size: 11px; -} - -.text_class6414 -{ -} - -.text_class6415 -{ -} - -.paragraph_class6416 -{ -} - -.text_class6417 -{ -font-family: arial; -} - -.text_class6418 -{ -font-size: 11px; -} - -.text_class6419 -{ -} - -.text_class6420 -{ -} - -.paragraph_class6421 -{ -} - -.text_class6422 -{ -font-family: arial; -} - -.text_class6423 -{ -font-size: 11px; -} - -.text_class6424 -{ -} - -.paragraph_class6425 -{ -} - -.text_class6426 -{ -font-family: arial; -} - -.text_class6427 -{ -font-size: 11px; -} - -.text_class6428 -{ -} - -.paragraph_class6429 -{ -} - -.text_class6430 -{ -font-family: arial; -} - -.text_class6431 -{ -font-size: 11px; -} - -.text_class6432 -{ -} - -.paragraph_class6433 -{ -} - -.text_class6434 -{ -font-family: arial; -} - -.text_class6435 -{ -font-size: 11px; -} - -.paragraph_class6436 -{ -} - -.text_class6437 -{ -font-family: arial; -} - -.text_class6438 -{ -font-size: 11px; -} - -.text_class6439 -{ -} - -.paragraph_class6440 -{ -} - -.text_class6441 -{ -font-family: arial; -} - -.text_class6442 -{ -font-size: 11px; -} - -.paragraph_class6443 -{ -} - -.text_class6444 -{ -font-family: arial; -} - -.text_class6445 -{ -font-size: 11px; -} - -.text_class6446 -{ -} - -.paragraph_class6447 -{ -} - -.text_class6448 -{ -font-family: arial; -} - -.text_class6449 -{ -font-size: 11px; -} - -.text_class6450 -{ -font-family: ｍｓ 明朝; -} - -.text_class6451 -{ -font-size: 11px; -} - -.text_class6452 -{ -font-family: arial; -} - -.text_class6453 -{ -font-size: 11px; -} - -.text_class6454 -{ -} - -.paragraph_class6455 -{ -} - -.text_class6456 -{ -font-family: arial; -} - -.text_class6457 -{ -font-size: 11px; -} - -.text_class6458 -{ -} - -.paragraph_class6459 -{ -} - -.text_class6460 -{ -font-family: arial; -} - -.text_class6461 -{ -font-size: 11px; -} - -.text_class6462 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6463 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6464 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6465 -{ -} - -.text_class6466 -{ -font-family: arial; -} - -.text_class6467 -{ -font-size: 11px; -} - -.text_class6468 -{ -font-family: arial; -} - -.text_class6469 -{ -font-size: 11px; -} - -.text_class6470 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6471 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6472 -{ -font-family: arial; -} - -.text_class6473 -{ -font-size: 11px; -} - -.text_class6474 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6475 -{ -} - -.paragraph_class6476 -{ -} - -.text_class6477 -{ -font-family: arial; -} - -.text_class6478 -{ -font-size: 11px; -} - -.paragraph_class6479 -{ -} - -.text_class6480 -{ -font-family: arial; -} - -.text_class6481 -{ -font-size: 11px; -} - -.text_class6482 -{ -} - -.paragraph_class6483 -{ -} - -.text_class6484 -{ -font-family: arial; -} - -.text_class6485 -{ -font-size: 11px; -} - -.text_class6486 -{ -} - -.paragraph_class6487 -{ -} - -.text_class6488 -{ -font-family: arial; -} - -.text_class6489 -{ -font-size: 11px; -} - -.paragraph_class6490 -{ -} - -.text_class6491 -{ -font-family: arial; -} - -.text_class6492 -{ -font-size: 11px; -} - -.text_class6493 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6494 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6495 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6496 -{ -font-family: arial; -} - -.text_class6497 -{ -font-size: 11px; -} - -.text_class6498 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6499 -{ -} - -.paragraph_class6500 -{ -} - -.text_class6501 -{ -font-family: arial; -} - -.text_class6502 -{ -font-size: 11px; -} - -.paragraph_class6503 -{ -} - -.text_class6504 -{ -font-family: arial; -} - -.text_class6505 -{ -font-size: 11px; -} - -.text_class6506 -{ -font-family: arial; -} - -.text_class6507 -{ -font-size: 11px; -} - -.text_class6508 -{ -font-family: arial; -} - -.text_class6509 -{ -font-size: 11px; -} - -.text_class6510 -{ -font-family: arial; -} - -.text_class6511 -{ -font-size: 11px; -} - -.text_class6512 -{ -font-family: arial; -} - -.text_class6513 -{ -font-size: 11px; -} - -.text_class6514 -{ -} - -.paragraph_class6515 -{ -} - -.text_class6516 -{ -font-family: arial; -} - -.text_class6517 -{ -font-size: 11px; -} - -.paragraph_class6518 -{ -} - -.text_class6519 -{ -font-family: arial; -} - -.text_class6520 -{ -font-size: 11px; -} - -.text_class6521 -{ -font-family: arial; -} - -.text_class6522 -{ -font-size: 11px; -} - -.text_class6523 -{ -font-family: arial; -} - -.text_class6524 -{ -font-size: 11px; -} - -.text_class6525 -{ -font-family: arial; -} - -.text_class6526 -{ -font-size: 11px; -} - -.text_class6527 -{ -font-family: arial; -} - -.text_class6528 -{ -font-size: 11px; -} - -.text_class6529 -{ -font-family: arial; -} - -.text_class6530 -{ -font-size: 11px; -} - -.paragraph_class6531 -{ -} - -.text_class6532 -{ -font-family: arial; -} - -.text_class6533 -{ -font-size: 11px; -} - -.paragraph_class6534 -{ -} - -.text_class6535 -{ -font-family: arial; -} - -.text_class6536 -{ -font-size: 11px; -} - -.text_class6537 -{ -} - -.paragraph_class6538 -{ -} - -.text_class6539 -{ -font-family: arial; -} - -.text_class6540 -{ -font-size: 11px; -} - -.paragraph_class6541 -{ -} - -.text_class6542 -{ -font-family: arial; -} - -.text_class6543 -{ -font-size: 11px; -} - -.paragraph_class6544 -{ -} - -.text_class6545 -{ -font-family: arial; -} - -.text_class6546 -{ -font-size: 11px; -} - -.paragraph_class6547 -{ -} - -.text_class6548 -{ -font-family: arial; -} - -.text_class6549 -{ -font-size: 11px; -} - -.text_class6550 -{ -font-family: arial; -} - -.text_class6551 -{ -font-size: 11px; -} - -.text_class6552 -{ -font-family: arial; -} - -.text_class6553 -{ -font-size: 11px; -} - -.text_class6554 -{ -font-family: arial; -} - -.text_class6555 -{ -font-size: 11px; -} - -.text_class6556 -{ -font-family: arial; -} - -.text_class6557 -{ -font-size: 11px; -} - -.text_class6558 -{ -} - -.paragraph_class6559 -{ -} - -.text_class6560 -{ -font-family: arial; -} - -.text_class6561 -{ -font-size: 11px; -} - -.paragraph_class6562 -{ -} - -.text_class6563 -{ -font-family: arial; -} - -.text_class6564 -{ -font-size: 11px; -} - -.text_class6565 -{ -} - -.paragraph_class6566 -{ -} - -.text_class6567 -{ -font-family: arial; -} - -.text_class6568 -{ -font-size: 11px; -} - -.paragraph_class6569 -{ -} - -.text_class6570 -{ -font-family: arial; -} - -.text_class6571 -{ -font-size: 11px; -} - -.text_class6572 -{ -font-family: arial; -} - -.text_class6573 -{ -font-size: 11px; -} - -.text_class6574 -{ -font-family: arial; -} - -.text_class6575 -{ -font-size: 11px; -} - -.text_class6576 -{ -font-family: arial; -} - -.text_class6577 -{ -font-size: 11px; -} - -.text_class6578 -{ -font-family: arial; -} - -.text_class6579 -{ -font-size: 11px; -} - -.paragraph_class6580 -{ -} - -.text_class6581 -{ -font-family: arial; -} - -.text_class6582 -{ -font-size: 11px; -} - -.text_class6583 -{ -} - -.paragraph_class6584 -{ -} - -.text_class6585 -{ -font-family: arial; -} - -.text_class6586 -{ -font-size: 11px; -} - -.text_class6587 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6588 -{ -} - -.paragraph_class6589 -{ -} - -.text_class6590 -{ -font-family: arial; -} - -.text_class6591 -{ -font-size: 11px; -} - -.text_class6592 -{ -} - -.paragraph_class6593 -{ -} - -.text_class6594 -{ -font-family: arial; -} - -.text_class6595 -{ -font-size: 11px; -} - -.text_class6596 -{ -} - -.paragraph_class6597 -{ -} - -.text_class6598 -{ -font-family: arial; -} - -.text_class6599 -{ -font-size: 11px; -} - -.paragraph_class6600 -{ -} - -.paragraph_class6601 -{ -} - -.text_class6602 -{ -font-family: arial; -} - -.text_class6603 -{ -font-size: 11px; -} - -.text_class6604 -{ -} - -.paragraph_class6605 -{ -} - -.text_class6606 -{ -font-family: arial; -} - -.text_class6607 -{ -font-size: 11px; -} - -.text_class6608 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6609 -{ -} - -.paragraph_class6610 -{ -} - -.text_class6611 -{ -font-family: arial; -} - -.text_class6612 -{ -font-size: 11px; -} - -.text_class6613 -{ -} - -.paragraph_class6614 -{ -} - -.text_class6615 -{ -font-family: arial; -} - -.text_class6616 -{ -font-size: 11px; -} - -.text_class6617 -{ -} - -.paragraph_class6618 -{ -} - -.text_class6619 -{ -font-family: arial; -} - -.text_class6620 -{ -font-size: 11px; -} - -.paragraph_class6621 -{ -} - -.text_class6622 -{ -font-family: arial; -} - -.text_class6623 -{ -font-size: 11px; -} - -.text_class6624 -{ -} - -.paragraph_class6625 -{ -} - -.text_class6626 -{ -font-family: arial; -} - -.text_class6627 -{ -font-size: 11px; -} - -.paragraph_class6628 -{ -} - -.text_class6629 -{ -font-family: arial; -} - -.text_class6630 -{ -font-size: 11px; -} - -.text_class6631 -{ -} - -.paragraph_class6632 -{ -} - -.text_class6633 -{ -font-family: arial; -} - -.text_class6634 -{ -font-size: 11px; -} - -.text_class6635 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6636 -{ -} - -.paragraph_class6637 -{ -} - -.text_class6638 -{ -font-family: arial; -} - -.text_class6639 -{ -font-size: 11px; -} - -.paragraph_class6640 -{ -} - -.text_class6641 -{ -font-family: arial; -} - -.text_class6642 -{ -font-size: 11px; -} - -.text_class6643 -{ -} - -.paragraph_class6644 -{ -} - -.text_class6645 -{ -font-family: arial; -} - -.text_class6646 -{ -font-size: 11px; -} - -.text_class6647 -{ -} - -.paragraph_class6648 -{ -} - -.text_class6649 -{ -font-family: arial; -} - -.text_class6650 -{ -font-size: 11px; -} - -.paragraph_class6651 -{ -} - -.text_class6652 -{ -font-family: arial; -} - -.text_class6653 -{ -font-size: 11px; -} - -.text_class6654 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6655 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6656 -{ -font-family: arial; -} - -.text_class6657 -{ -font-size: 11px; -} - -.text_class6658 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6659 -{ -font-family: arial; -} - -.text_class6660 -{ -font-size: 11px; -} - -.text_class6661 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6662 -{ -} - -.paragraph_class6663 -{ -} - -.text_class6664 -{ -font-family: arial; -} - -.text_class6665 -{ -font-size: 11px; -} - -.text_class6666 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6667 -{ -} - -.text_class6668 -{ -} - -.paragraph_class6669 -{ -} - -.text_class6670 -{ -font-family: arial; -} - -.text_class6671 -{ -font-size: 11px; -} - -.text_class6672 -{ -} - -.paragraph_class6673 -{ -} - -.text_class6674 -{ -font-family: arial; -} - -.text_class6675 -{ -font-size: 11px; -} - -.text_class6676 -{ -font-family: arial; -} - -.text_class6677 -{ -font-size: 11px; -} - -.text_class6678 -{ -font-family: arial; -} - -.text_class6679 -{ -font-size: 11px; -} - -.text_class6680 -{ -font-family: arial; -} - -.text_class6681 -{ -font-size: 11px; -} - -.text_class6682 -{ -font-family: arial; -} - -.text_class6683 -{ -font-size: 11px; -} - -.text_class6684 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6685 -{ -} - -.paragraph_class6686 -{ -} - -.text_class6687 -{ -font-family: arial; -} - -.text_class6688 -{ -font-size: 11px; -} - -.text_class6689 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6690 -{ -} - -.paragraph_class6691 -{ -} - -.text_class6692 -{ -font-family: arial; -} - -.text_class6693 -{ -font-size: 11px; -} - -.text_class6694 -{ -} - -.paragraph_class6695 -{ -} - -.text_class6696 -{ -font-family: arial; -} - -.text_class6697 -{ -font-size: 11px; -} - -.text_class6698 -{ -font-family: arial; -} - -.text_class6699 -{ -font-size: 11px; -} - -.text_class6700 -{ -font-family: arial; -} - -.text_class6701 -{ -font-size: 11px; -} - -.text_class6702 -{ -font-family: arial; -} - -.text_class6703 -{ -font-size: 11px; -} - -.text_class6704 -{ -} - -.paragraph_class6705 -{ -} - -.text_class6706 -{ -font-family: arial; -} - -.text_class6707 -{ -font-size: 11px; -} - -.text_class6708 -{ -font-family: arial; -} - -.text_class6709 -{ -font-size: 11px; -} - -.text_class6710 -{ -font-family: arial; -} - -.text_class6711 -{ -font-size: 11px; -} - -.text_class6712 -{ -font-family: arial; -} - -.text_class6713 -{ -font-size: 11px; -} - -.text_class6714 -{ -font-family: arial; -} - -.text_class6715 -{ -font-size: 11px; -} - -.text_class6716 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6717 -{ -} - -.paragraph_class6718 -{ -} - -.text_class6719 -{ -font-family: arial; -} - -.text_class6720 -{ -font-size: 11px; -} - -.text_class6721 -{ -} - -.paragraph_class6722 -{ -} - -.text_class6723 -{ -font-family: arial; -} - -.text_class6724 -{ -font-size: 11px; -} - -.text_class6725 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6726 -{ -} - -.paragraph_class6727 -{ -} - -.text_class6728 -{ -font-family: arial; -} - -.text_class6729 -{ -font-size: 11px; -} - -.paragraph_class6730 -{ -} - -.text_class6731 -{ -font-family: arial; -} - -.text_class6732 -{ -font-size: 11px; -} - -.paragraph_class6733 -{ -} - -.text_class6734 -{ -font-family: arial; -} - -.text_class6735 -{ -font-size: 11px; -} - -.paragraph_class6736 -{ -} - -.text_class6737 -{ -font-family: arial; -} - -.text_class6738 -{ -font-size: 11px; -} - -.text_class6739 -{ -} - -.text_class6740 -{ -} - -.paragraph_class6741 -{ -} - -.text_class6742 -{ -font-size: 11px; -} - -.text_class6743 -{ -} - -.text_class6744 -{ -} - -.paragraph_class6745 -{ -} - -.text_class6746 -{ -font-family: arial; -} - -.text_class6747 -{ -font-size: 11px; -} - -.text_class6748 -{ -} - -.paragraph_class6749 -{ -} - -.text_class6750 -{ -font-family: arial; -} - -.text_class6751 -{ -font-size: 11px; -} - -.text_class6752 -{ -} - -.paragraph_class6753 -{ -} - -.text_class6754 -{ -font-family: arial; -} - -.text_class6755 -{ -font-size: 11px; -} - -.text_class6756 -{ -} - -.paragraph_class6757 -{ -} - -.text_class6758 -{ -font-family: arial; -} - -.text_class6759 -{ -font-size: 11px; -} - -.text_class6760 -{ -} - -.paragraph_class6761 -{ -} - -.text_class6762 -{ -font-family: arial; -} - -.text_class6763 -{ -font-size: 11px; -} - -.text_class6764 -{ -} - -.paragraph_class6765 -{ -} - -.text_class6766 -{ -font-family: arial; -} - -.text_class6767 -{ -font-size: 11px; -} - -.text_class6768 -{ -} - -.paragraph_class6769 -{ -} - -.text_class6770 -{ -font-family: arial; -} - -.text_class6771 -{ -font-size: 11px; -} - -.text_class6772 -{ -} - -.paragraph_class6773 -{ -} - -.text_class6774 -{ -font-family: arial; -} - -.text_class6775 -{ -font-size: 11px; -} - -.text_class6776 -{ -} - -.paragraph_class6777 -{ -} - -.text_class6778 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6779 -{ -} - -.paragraph_class6780 -{ -} - -.text_class6781 -{ -font-family: arial; -} - -.text_class6782 -{ -font-size: 11px; -} - -.text_class6783 -{ -} - -.paragraph_class6784 -{ -} - -.text_class6785 -{ -font-family: arial; -} - -.text_class6786 -{ -font-size: 11px; -} - -.text_class6787 -{ -} - -.paragraph_class6788 -{ -} - -.text_class6789 -{ -font-family: arial; -} - -.text_class6790 -{ -font-size: 11px; -} - -.text_class6791 -{ -} - -.paragraph_class6792 -{ -} - -.text_class6793 -{ -font-family: arial; -} - -.text_class6794 -{ -font-size: 11px; -} - -.text_class6795 -{ -} - -.paragraph_class6796 -{ -} - -.text_class6797 -{ -font-family: arial; -} - -.text_class6798 -{ -font-size: 11px; -} - -.text_class6799 -{ -} - -.paragraph_class6800 -{ -} - -.text_class6801 -{ -font-family: arial; -} - -.text_class6802 -{ -font-size: 11px; -} - -.text_class6803 -{ -} - -.paragraph_class6804 -{ -} - -.text_class6805 -{ -font-family: arial; -} - -.text_class6806 -{ -font-size: 11px; -} - -.text_class6807 -{ -} - -.paragraph_class6808 -{ -} - -.text_class6809 -{ -font-family: arial; -} - -.text_class6810 -{ -font-size: 11px; -} - -.text_class6811 -{ -} - -.text_class6812 -{ -} - -.paragraph_class6813 -{ -} - -.text_class6814 -{ -font-size: 11px; -} - -.text_class6815 -{ -} - -.text_class6816 -{ -} - -.paragraph_class6817 -{ -} - -.text_class6818 -{ -font-size: 11px; -} - -.text_class6819 -{ -font-family: arial; -} - -.paragraph_class6820 -{ -} - -.text_class6821 -{ -font-size: 11px; -} - -.text_class6822 -{ -font-family: arial; -} - -.text_class6823 -{ -} - -.text_class6824 -{ -font-size: 11px; -} - -.text_class6825 -{ -} - -.paragraph_class6826 -{ -} - -.text_class6827 -{ -font-size: 11px; -} - -.text_class6828 -{ -font-family: arial; -} - -.text_class6829 -{ -} - -.text_class6830 -{ -} - -.text_class6831 -{ -} - -.text_class6832 -{ -} - -.paragraph_class6833 -{ -} - -.text_class6834 -{ -font-size: 11px; -} - -.text_class6835 -{ -} - -.text_class6836 -{ -} - -.paragraph_class6837 -{ -} - -.text_class6838 -{ -font-family: arial; -} - -.text_class6839 -{ -font-size: 11px; -} - -.paragraph_class6840 -{ -} - -.paragraph_class6841 -{ -} - -.text_class6842 -{ -font-family: arial; -} - -.text_class6843 -{ -font-size: 11px; -} - -.text_class6844 -{ -} - -.paragraph_class6845 -{ -} - -.text_class6846 -{ -font-family: arial; -} - -.text_class6847 -{ -font-size: 11px; -} - -.text_class6848 -{ -} - -.text_class6849 -{ -} - -.text_class6850 -{ -} - -.paragraph_class6851 -{ -} - -.text_class6852 -{ -font-size: 11px; -} - -.text_class6853 -{ -font-family: arial; -} - -.text_class6854 -{ -} - -.text_class6855 -{ -} - -.paragraph_class6856 -{ -} - -.text_class6857 -{ -font-family: arial; -} - -.text_class6858 -{ -font-size: 11px; -} - -.text_class6859 -{ -} - -.paragraph_class6860 -{ -} - -.text_class6861 -{ -font-family: arial; -} - -.text_class6862 -{ -font-size: 11px; -} - -.text_class6863 -{ -font-family: arial; -} - -.text_class6864 -{ -font-size: 11px; -} - -.text_class6865 -{ -font-family: arial; -} - -.text_class6866 -{ -font-size: 11px; -} - -.text_class6867 -{ -font-family: arial; -} - -.text_class6868 -{ -font-size: 11px; -} - -.text_class6869 -{ -} - -.text_class6870 -{ -} - -.text_class6871 -{ -} - -.paragraph_class6872 -{ -} - -.text_class6873 -{ -font-family: arial; -} - -.text_class6874 -{ -font-size: 11px; -} - -.paragraph_class6875 -{ -} - -.text_class6876 -{ -font-style: italic; -} - -.text_class6877 -{ -font-family: arial; -} - -.text_class6878 -{ -font-size: 11px; -} - -.text_class6879 -{ -font-family: arial; -} - -.text_class6880 -{ -font-size: 11px; -} - -.text_class6881 -{ -font-style: italic; -} - -.text_class6882 -{ -font-family: arial; -} - -.text_class6883 -{ -font-size: 11px; -} - -.text_class6884 -{ -font-family: arial; -} - -.text_class6885 -{ -font-size: 11px; -} - -.text_class6886 -{ -font-style: italic; -} - -.text_class6887 -{ -font-family: arial; -} - -.text_class6888 -{ -font-size: 11px; -} - -.text_class6889 -{ -font-family: arial; -} - -.text_class6890 -{ -font-size: 11px; -} - -.paragraph_class6891 -{ -} - -.paragraph_class6892 -{ -} - -.text_class6893 -{ -font-family: arial; -} - -.text_class6894 -{ -font-size: 11px; -} - -.text_class6895 -{ -} - -.cell_class6896 -{ -width: 435px; -background-color: #bfbfbf; -} - -.paragraph_class6898 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class6899 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6900 -{ -font-weight: bold; -} - -.cell_class6901 -{ -width: 147px; -background-color: #bfbfbf; -} - -.paragraph_class6903 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class6904 -{ -font-size: 11px; -font-family: arial; -} - -.text_class6905 -{ -font-weight: bold; -} - -.cell_class6906 -{ -width: 435px; -} - -.list_class6907 -{ -list-style-type: decimal; -} - -.text_class6908 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6909 -{ -margin-left: 80px; -} - -.text_class6910 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6911 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6912 -{ -margin-left: 120px; -} - -.text_class6913 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6914 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6915 -{ -margin-left: 120px; -} - -.text_class6916 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6917 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6918 -{ -margin-left: 120px; -} - -.text_class6919 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6920 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6921 -{ -margin-left: 120px; -} - -.text_class6922 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6923 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6924 -{ -margin-left: 120px; -} - -.text_class6925 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6926 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6927 -{ -margin-left: 120px; -} - -.text_class6928 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6929 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6930 -{ -margin-left: 120px; -} - -.text_class6931 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6932 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6933 -{ -margin-left: 120px; -} - -.text_class6934 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6935 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6936 -{ -margin-left: 120px; -} - -.text_class6937 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6938 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6939 -{ -margin-left: 120px; -} - -.text_class6940 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6941 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6942 -{ -margin-left: 120px; -} - -.text_class6943 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6944 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6945 -{ -margin-left: 120px; -} - -.text_class6946 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6947 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6948 -{ -margin-left: 120px; -} - -.text_class6949 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6950 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6951 -{ -margin-left: 120px; -} - -.text_class6952 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6953 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6954 -{ -margin-left: 120px; -} - -.text_class6955 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6956 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6957 -{ -margin-left: 120px; -} - -.text_class6958 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6959 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6960 -{ -margin-left: 120px; -} - -.text_class6961 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6962 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6963 -{ -margin-left: 120px; -} - -.text_class6964 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6965 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6966 -{ -margin-left: 80px; -} - -.text_class6967 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6968 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6969 -{ -margin-left: 120px; -} - -.text_class6970 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6971 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6972 -{ -margin-left: 120px; -} - -.text_class6973 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6974 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6975 -{ -margin-left: 120px; -} - -.text_class6976 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6977 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6978 -{ -margin-left: 120px; -} - -.text_class6979 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6980 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6981 -{ -margin-left: 120px; -} - -.text_class6982 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6983 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6984 -{ -margin-left: 120px; -} - -.text_class6985 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6986 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6987 -{ -margin-left: 120px; -} - -.text_class6988 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6989 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6990 -{ -margin-left: 120px; -} - -.text_class6991 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6992 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6993 -{ -margin-left: 80px; -} - -.text_class6994 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6995 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6996 -{ -margin-left: 120px; -} - -.text_class6997 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class6998 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class6999 -{ -margin-left: 120px; -} - -.text_class7000 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7001 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7002 -{ -margin-left: 120px; -} - -.text_class7003 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7004 -{ -font-size: 11px; -font-family: arial; -} - -.cell_class7005 -{ -width: 147px; -} - -.list_class7006 -{ -list-style-type: decimal; -} - -.text_class7007 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7008 -{ -margin-left: 80px; -} - -.text_class7009 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7010 -{ -font-size: 11px; -font-family: arial; -} - -.list_class7011 -{ -list-style-type: decimal; -} - -.text_class7012 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7013 -{ -margin-left: 80px; -} - -.text_class7014 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7015 -{ -font-size: 11px; -font-family: arial; -} - -.list_class7016 -{ -list-style-type: decimal; -} - -.text_class7017 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7018 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7019 -{ -margin-left: 80px; -} - -.text_class7020 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7021 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7022 -{ -margin-left: 80px; -} - -.text_class7023 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7024 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7025 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7026 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7027 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7028 -{ -margin-left: 80px; -} - -.text_class7029 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7030 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7031 -{ -margin-left: 80px; -} - -.text_class7032 -{ -font-size: 10px; -font-family: times new roman; -} - -.text_class7033 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7034 -{ -} - -.text_class7035 -{ -} - -.paragraph_class7036 -{ -} - -.text_class7037 -{ -font-family: arial; -} - -.text_class7038 -{ -font-size: 11px; -} - -.text_class7039 -{ -} - -.paragraph_class7040 -{ -} - -.text_class7041 -{ -font-family: arial; -} - -.text_class7042 -{ -font-size: 11px; -} - -.text_class7043 -{ -} - -.paragraph_class7044 -{ -} - -.text_class7045 -{ -font-family: arial; -} - -.text_class7046 -{ -font-size: 11px; -} - -.text_class7047 -{ -} - -.paragraph_class7048 -{ -} - -.text_class7049 -{ -font-family: arial; -} - -.text_class7050 -{ -font-size: 11px; -} - -.text_class7051 -{ -} - -.paragraph_class7052 -{ -} - -.text_class7053 -{ -font-family: arial; -} - -.text_class7054 -{ -font-size: 11px; -} - -.text_class7055 -{ -} - -.paragraph_class7056 -{ -} - -.text_class7057 -{ -font-family: arial; -} - -.text_class7058 -{ -font-size: 11px; -} - -.text_class7059 -{ -} - -.paragraph_class7060 -{ -} - -.text_class7061 -{ -font-family: arial; -} - -.text_class7062 -{ -font-size: 11px; -} - -.text_class7063 -{ -} - -.paragraph_class7064 -{ -} - -.text_class7065 -{ -font-family: arial; -} - -.text_class7066 -{ -font-size: 11px; -} - -.text_class7067 -{ -} - -.paragraph_class7068 -{ -} - -.text_class7069 -{ -font-family: arial; -} - -.text_class7070 -{ -font-size: 11px; -} - -.text_class7071 -{ -} - -.paragraph_class7072 -{ -} - -.text_class7073 -{ -font-family: arial; -} - -.text_class7074 -{ -font-size: 11px; -} - -.text_class7075 -{ -} - -.paragraph_class7076 -{ -} - -.text_class7077 -{ -font-family: arial; -} - -.text_class7078 -{ -font-size: 11px; -} - -.text_class7079 -{ -} - -.paragraph_class7080 -{ -} - -.text_class7081 -{ -font-family: arial; -} - -.text_class7082 -{ -font-size: 11px; -} - -.text_class7083 -{ -} - -.paragraph_class7084 -{ -} - -.text_class7085 -{ -font-family: arial; -} - -.text_class7086 -{ -font-size: 11px; -} - -.text_class7087 -{ -} - -.paragraph_class7088 -{ -} - -.text_class7089 -{ -font-family: arial; -} - -.text_class7090 -{ -font-size: 11px; -} - -.text_class7091 -{ -} - -.paragraph_class7092 -{ -} - -.text_class7093 -{ -font-family: arial; -} - -.text_class7094 -{ -font-size: 11px; -} - -.text_class7095 -{ -} - -.paragraph_class7096 -{ -} - -.text_class7097 -{ -font-family: arial; -} - -.text_class7098 -{ -font-size: 11px; -} - -.text_class7099 -{ -} - -.paragraph_class7100 -{ -} - -.text_class7101 -{ -font-family: arial; -} - -.text_class7102 -{ -font-size: 11px; -} - -.text_class7103 -{ -} - -.paragraph_class7104 -{ -} - -.text_class7105 -{ -font-family: arial; -} - -.text_class7106 -{ -font-size: 11px; -} - -.text_class7107 -{ -} - -.paragraph_class7108 -{ -} - -.text_class7109 -{ -font-family: arial; -} - -.text_class7110 -{ -font-size: 11px; -} - -.text_class7111 -{ -} - -.paragraph_class7112 -{ -} - -.text_class7113 -{ -font-family: arial; -} - -.text_class7114 -{ -font-size: 11px; -} - -.text_class7115 -{ -} - -.paragraph_class7116 -{ -} - -.text_class7117 -{ -font-family: arial; -} - -.text_class7118 -{ -font-size: 11px; -} - -.text_class7119 -{ -} - -.paragraph_class7120 -{ -} - -.text_class7121 -{ -font-family: arial; -} - -.text_class7122 -{ -font-size: 11px; -} - -.text_class7123 -{ -} - -.paragraph_class7124 -{ -} - -.text_class7125 -{ -font-family: arial; -} - -.text_class7126 -{ -font-size: 11px; -} - -.text_class7127 -{ -} - -.paragraph_class7128 -{ -} - -.text_class7129 -{ -font-family: arial; -} - -.text_class7130 -{ -font-size: 11px; -} - -.text_class7131 -{ -} - -.paragraph_class7132 -{ -} - -.text_class7133 -{ -font-family: arial; -} - -.text_class7134 -{ -font-size: 11px; -} - -.text_class7135 -{ -} - -.paragraph_class7136 -{ -} - -.text_class7137 -{ -font-family: arial; -} - -.text_class7138 -{ -font-size: 11px; -} - -.text_class7139 -{ -} - -.paragraph_class7140 -{ -} - -.text_class7141 -{ -font-family: arial; -} - -.text_class7142 -{ -font-size: 11px; -} - -.text_class7143 -{ -} - -.paragraph_class7144 -{ -} - -.text_class7145 -{ -font-family: arial; -} - -.text_class7146 -{ -font-size: 11px; -} - -.text_class7147 -{ -} - -.paragraph_class7148 -{ -} - -.text_class7149 -{ -font-family: arial; -} - -.text_class7150 -{ -font-size: 11px; -} - -.text_class7151 -{ -} - -.paragraph_class7152 -{ -} - -.text_class7153 -{ -font-family: arial; -} - -.text_class7154 -{ -font-size: 11px; -} - -.text_class7155 -{ -} - -.paragraph_class7156 -{ -} - -.text_class7157 -{ -font-family: arial; -} - -.text_class7158 -{ -font-size: 11px; -} - -.text_class7159 -{ -} - -.paragraph_class7160 -{ -} - -.text_class7161 -{ -font-family: arial; -} - -.text_class7162 -{ -font-size: 11px; -} - -.text_class7163 -{ -} - -.text_class7164 -{ -} - -.paragraph_class7165 -{ -} - -.text_class7166 -{ -font-size: 11px; -} - -.paragraph_class7167 -{ -} - -.text_class7168 -{ -font-size: 11px; -} - -.text_class7169 -{ -} - -.text_class7170 -{ -} - -.paragraph_class7171 -{ -} - -.text_class7172 -{ -font-family: arial; -} - -.text_class7173 -{ -font-size: 11px; -} - -.paragraph_class7174 -{ -} - -.paragraph_class7175 -{ -} - -.text_class7176 -{ -font-family: arial; -} - -.text_class7177 -{ -font-size: 11px; -} - -.paragraph_class7178 -{ -} - -.paragraph_class7179 -{ -} - -.text_class7180 -{ -font-family: arial; -} - -.text_class7181 -{ -font-size: 11px; -} - -.paragraph_class7182 -{ -} - -.paragraph_class7183 -{ -} - -.text_class7184 -{ -font-family: arial; -} - -.text_class7185 -{ -font-size: 11px; -} - -.text_class7186 -{ -font-family: arial; -} - -.text_class7187 -{ -font-size: 11px; -} - -.text_class7188 -{ -} - -.paragraph_class7189 -{ -text-align: center; -margin-left: 0px; -} - -.text_class7190 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7191 -{ -font-weight: bold; -} - -.text_class7192 -{ -} - -.paragraph_class7194 -{ -margin-left: 0px; -} - -.text_class7195 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7196 -{ -font-weight: bold; -} - -.paragraph_class7198 -{ -margin-left: 0px; -} - -.text_class7199 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7200 -{ -font-weight: bold; -} - -.paragraph_class7202 -{ -margin-left: 0px; -} - -.text_class7203 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7204 -{ -font-weight: bold; -} - -.paragraph_class7205 -{ -margin-left: 0px; -} - -.text_class7206 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7207 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class7208 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7209 -{ -margin-left: 0px; -} - -.text_class7210 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7211 -{ -margin-left: 0px; -} - -.text_class7212 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7213 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class7214 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7215 -{ -margin-left: 0px; -} - -.text_class7216 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7217 -{ -margin-left: 0px; -} - -.text_class7218 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7219 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class7220 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7221 -{ -margin-left: 0px; -} - -.text_class7222 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7223 -{ -margin-left: 0px; -} - -.text_class7224 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7225 -{ -text-align: justify; -margin-left: 0px; -} - -.text_class7226 -{ -font-size: 11px; -font-family: arial; -} - -.paragraph_class7227 -{ -margin-left: 0px; -} - -.text_class7228 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7229 -{ -} - -.paragraph_class7230 -{ -} - -.text_class7231 -{ -font-family: arial; -} - -.text_class7232 -{ -font-size: 11px; -} - -.text_class7233 -{ -font-family: arial; -} - -.text_class7234 -{ -font-size: 11px; -} - -.text_class7235 -{ -font-family: arial; -} - -.text_class7236 -{ -font-size: 11px; -} - -.text_class7237 -{ -} - -.paragraph_class7238 -{ -text-align: center; -margin-left: 0px; -} - -.text_class7239 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7240 -{ -font-weight: bold; -} - -.text_class7241 -{ -} - -.text_class7242 -{ -} - -.text_class7243 -{ -} - -.paragraph_class7244 -{ -} - -.text_class7245 -{ -font-family: arial; -} - -.text_class7246 -{ -font-size: 11px; -} - -.text_class7247 -{ -} - -.paragraph_class7248 -{ -} - -.text_class7249 -{ -font-family: arial; -} - -.text_class7250 -{ -font-size: 11px; -} - -.paragraph_class7251 -{ -} - -.text_class7252 -{ -font-family: arial; -} - -.text_class7253 -{ -font-size: 11px; -} - -.text_class7254 -{ -} - -.paragraph_class7255 -{ -} - -.text_class7256 -{ -font-family: arial; -} - -.text_class7257 -{ -font-size: 11px; -} - -.text_class7258 -{ -font-family: ｍｓ 明朝; -} - -.text_class7259 -{ -font-size: 11px; -} - -.text_class7260 -{ -font-family: arial; -} - -.text_class7261 -{ -font-size: 11px; -} - -.text_class7262 -{ -} - -.paragraph_class7263 -{ -} - -.text_class7264 -{ -font-family: arial; -} - -.text_class7265 -{ -font-size: 11px; -} - -.text_class7266 -{ -} - -.paragraph_class7267 -{ -} - -.text_class7268 -{ -font-family: arial; -} - -.text_class7269 -{ -font-size: 11px; -} - -.text_class7270 -{ -} - -.paragraph_class7271 -{ -} - -.text_class7272 -{ -font-family: arial; -} - -.text_class7273 -{ -font-size: 11px; -} - -.text_class7274 -{ -} - -.text_class7275 -{ -} - -.paragraph_class7276 -{ -} - -.text_class7277 -{ -font-family: arial; -} - -.text_class7278 -{ -font-size: 11px; -} - -.text_class7279 -{ -} - -.paragraph_class7280 -{ -} - -.text_class7281 -{ -font-family: arial; -} - -.text_class7282 -{ -font-size: 11px; -} - -.text_class7283 -{ -} - -.paragraph_class7284 -{ -} - -.text_class7285 -{ -font-family: arial; -} - -.text_class7286 -{ -font-size: 11px; -} - -.text_class7287 -{ -} - -.paragraph_class7288 -{ -} - -.text_class7289 -{ -font-family: arial; -} - -.text_class7290 -{ -font-size: 11px; -} - -.text_class7291 -{ -} - -.paragraph_class7292 -{ -} - -.text_class7293 -{ -font-family: arial; -} - -.text_class7294 -{ -font-size: 11px; -} - -.paragraph_class7295 -{ -} - -.text_class7296 -{ -font-family: arial; -} - -.text_class7297 -{ -font-size: 11px; -} - -.paragraph_class7298 -{ -} - -.text_class7299 -{ -font-family: arial; -} - -.text_class7300 -{ -font-size: 11px; -} - -.text_class7301 -{ -} - -.text_class7302 -{ -} - -.paragraph_class7303 -{ -} - -.text_class7304 -{ -font-family: arial; -} - -.text_class7305 -{ -font-size: 11px; -} - -.text_class7306 -{ -} - -.paragraph_class7307 -{ -} - -.text_class7308 -{ -font-family: arial; -} - -.text_class7309 -{ -font-size: 11px; -} - -.text_class7310 -{ -} - -.text_class7311 -{ -} - -.paragraph_class7312 -{ -} - -.text_class7313 -{ -font-family: arial; -} - -.text_class7314 -{ -font-size: 11px; -} - -.text_class7315 -{ -} - -.paragraph_class7316 -{ -} - -.text_class7317 -{ -font-family: arial; -} - -.text_class7318 -{ -font-size: 11px; -} - -.text_class7319 -{ -} - -.paragraph_class7320 -{ -} - -.text_class7321 -{ -font-family: arial; -} - -.text_class7322 -{ -font-size: 11px; -} - -.text_class7323 -{ -} - -.text_class7324 -{ -} - -.paragraph_class7325 -{ -} - -.text_class7326 -{ -font-size: 11px; -} - -.text_class7327 -{ -} - -.text_class7328 -{ -} - -.paragraph_class7329 -{ -} - -.text_class7330 -{ -font-family: arial; -} - -.paragraph_class7331 -{ -text-indent: -5.25px; -margin-left: 5px; -} - -.paragraph_class7332 -{ -} - -.text_class7333 -{ -font-family: arial; -} - -.paragraph_class7334 -{ -} - -.paragraph_class7335 -{ -} - -.text_class7336 -{ -font-family: arial; -} - -.paragraph_class7337 -{ -} - -.paragraph_class7338 -{ -} - -.text_class7339 -{ -font-family: arial; -} - -.paragraph_class7340 -{ -} - -.paragraph_class7341 -{ -} - -.text_class7342 -{ -font-family: arial; -} - -.text_class7343 -{ -} - -.text_class7344 -{ -} - -.paragraph_class7345 -{ -} - -.text_class7346 -{ -font-family: arial; -} - -.text_class7347 -{ -font-size: 11px; -} - -.text_class7348 -{ -} - -.paragraph_class7349 -{ -} - -.text_class7350 -{ -font-family: arial; -} - -.text_class7351 -{ -font-size: 11px; -} - -.text_class7352 -{ -} - -.paragraph_class7353 -{ -} - -.text_class7354 -{ -font-family: arial; -} - -.text_class7355 -{ -font-size: 11px; -} - -.text_class7356 -{ -} - -.paragraph_class7357 -{ -} - -.text_class7358 -{ -font-family: arial; -} - -.text_class7359 -{ -font-size: 11px; -} - -.text_class7360 -{ -} - -.paragraph_class7361 -{ -} - -.text_class7362 -{ -font-family: arial; -} - -.text_class7363 -{ -font-size: 11px; -} - -.text_class7364 -{ -} - -.paragraph_class7365 -{ -} - -.text_class7366 -{ -font-family: arial; -} - -.text_class7367 -{ -font-size: 11px; -} - -.text_class7368 -{ -} - -.text_class7369 -{ -} - -.paragraph_class7370 -{ -} - -.text_class7371 -{ -font-size: 11px; -} - -.text_class7372 -{ -font-family: arial; -} - -.paragraph_class7373 -{ -} - -.text_class7374 -{ -font-size: 11px; -} - -.text_class7375 -{ -font-family: arial; -} - -.text_class7376 -{ -font-size: 11px; -} - -.text_class7377 -{ -font-family: arial; -} - -.text_class7378 -{ -font-size: 11px; -} - -.text_class7379 -{ -font-family: arial; -} - -.text_class7380 -{ -font-size: 11px; -} - -.text_class7381 -{ -font-family: arial; -} - -.text_class7382 -{ -font-size: 11px; -} - -.text_class7383 -{ -font-family: arial; -} - -.text_class7384 -{ -font-family: arial; -} - -.text_class7385 -{ -font-size: 11px; -} - -.text_class7386 -{ -font-family: arial; -} - -.text_class7387 -{ -} - -.paragraph_class7388 -{ -} - -.text_class7389 -{ -font-family: arial; -} - -.text_class7390 -{ -font-size: 11px; -} - -.text_class7391 -{ -} - -.paragraph_class7392 -{ -} - -.text_class7393 -{ -font-family: arial; -} - -.text_class7394 -{ -font-size: 11px; -} - -.text_class7395 -{ -} - -.paragraph_class7396 -{ -} - -.text_class7397 -{ -font-family: arial; -} - -.text_class7398 -{ -font-size: 11px; -} - -.text_class7399 -{ -} - -.paragraph_class7400 -{ -} - -.text_class7401 -{ -font-family: arial; -} - -.text_class7402 -{ -font-size: 11px; -} - -.text_class7403 -{ -} - -.paragraph_class7404 -{ -} - -.text_class7405 -{ -font-family: arial; -} - -.text_class7406 -{ -font-size: 11px; -} - -.text_class7407 -{ -} - -.paragraph_class7408 -{ -} - -.text_class7409 -{ -font-family: arial; -} - -.text_class7410 -{ -font-size: 11px; -} - -.text_class7411 -{ -} - -.paragraph_class7412 -{ -} - -.text_class7413 -{ -font-family: arial; -} - -.text_class7414 -{ -font-size: 11px; -} - -.paragraph_class7415 -{ -} - -.text_class7416 -{ -font-family: arial; -} - -.text_class7417 -{ -font-size: 11px; -} - -.text_class7418 -{ -} - -.text_class7419 -{ -} - -.paragraph_class7420 -{ -} - -.text_class7421 -{ -font-family: arial; -} - -.text_class7422 -{ -font-size: 11px; -} - -.text_class7423 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7424 -{ -} - -.paragraph_class7425 -{ -} - -.text_class7426 -{ -font-family: arial; -} - -.text_class7427 -{ -font-size: 11px; -} - -.text_class7428 -{ -} - -.paragraph_class7429 -{ -} - -.text_class7430 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7431 -{ -font-family: arial; -} - -.text_class7432 -{ -font-size: 11px; -} - -.text_class7433 -{ -} - -.paragraph_class7434 -{ -} - -.text_class7435 -{ -font-family: arial; -} - -.text_class7436 -{ -font-size: 11px; -} - -.text_class7437 -{ -} - -.paragraph_class7438 -{ -} - -.text_class7439 -{ -font-family: arial; -} - -.text_class7440 -{ -font-size: 11px; -} - -.text_class7441 -{ -} - -.paragraph_class7442 -{ -} - -.text_class7443 -{ -font-family: arial; -} - -.text_class7444 -{ -font-size: 11px; -} - -.text_class7445 -{ -} - -.paragraph_class7446 -{ -} - -.text_class7447 -{ -font-family: arial; -} - -.text_class7448 -{ -font-size: 11px; -} - -.text_class7449 -{ -} - -.paragraph_class7450 -{ -} - -.text_class7451 -{ -font-family: arial; -} - -.text_class7452 -{ -font-size: 11px; -} - -.text_class7453 -{ -} - -.paragraph_class7454 -{ -} - -.text_class7455 -{ -font-family: arial; -} - -.text_class7456 -{ -font-size: 11px; -} - -.text_class7457 -{ -} - -.paragraph_class7458 -{ -} - -.text_class7459 -{ -font-family: arial; -} - -.text_class7460 -{ -font-size: 11px; -} - -.text_class7461 -{ -} - -.paragraph_class7462 -{ -} - -.text_class7463 -{ -font-family: arial; -} - -.text_class7464 -{ -font-size: 11px; -} - -.text_class7465 -{ -} - -.paragraph_class7466 -{ -} - -.text_class7467 -{ -font-size: 11px; -font-family: arial; -} - -.text_class7468 -{ -font-family: arial; -} - -.text_class7469 -{ -font-size: 11px; -} - -.text_class7470 -{ -} - -.paragraph_class7471 -{ -} - -.text_class7472 -{ -font-family: arial; -} - -.text_class7473 -{ -font-size: 11px; -} - -.text_class7474 -{ -} - -.paragraph_class7475 -{ -} - -.text_class7476 -{ -font-family: arial; -} - -.text_class7477 -{ -font-size: 11px; -} - -.text_class7478 -{ -} - -.paragraph_class7479 -{ -} - -.text_class7480 -{ -font-family: arial; -} - -.text_class7481 -{ -font-size: 11px; -} - -.text_class7482 -{ -} - -.paragraph_class7483 -{ -} - -.text_class7484 -{ -font-family: arial; -} - -.text_class7485 -{ -font-size: 11px; -} - -.text_class7486 -{ -} - -.text_class7487 -{ -} - -.paragraph_class7488 -{ -} - -.text_class7489 -{ -font-size: 11px; -} - -.text_class7490 -{ -} - -.text_class7491 -{ -} - -.paragraph_class7492 -{ -} - -.text_class7493 -{ -font-size: 11px; -} - -.text_class7494 -{ -} - -.paragraph_class7495 -{ -} - -.text_class7496 -{ -font-size: 11px; -} - -.paragraph_class7497 -{ -} - -.text_class7498 -{ -font-size: 11px; -} - -.paragraph_class7499 -{ -} - -.text_class7500 -{ -font-size: 11px; -} - -.paragraph_class7501 -{ -} - -.text_class7502 -{ -font-size: 11px; -} - -.text_class7503 -{ -} - -.text_class7504 -{ -} - -.paragraph_class7505 -{ -} - -.text_class7506 -{ -font-size: 11px; -} - -.text_class7507 -{ -} - -.text_class7508 -{ -} - -.paragraph_class7509 -{ -} - -.text_class7510 -{ -font-size: 11px; -} - -.text_class7511 -{ -} - -.text_class7512 -{ -} - -.paragraph_class7513 -{ -} - -.text_class7514 -{ -font-size: 11px; -} - -.text_class7515 -{ -} - -.text_class7516 -{ -} - -.text_class7517 -{ -} - -.paragraph_class7518 -{ -} - -.text_class7519 -{ -font-size: 11px; -} - -.text_class7520 -{ -} - -.paragraph_class7521 -{ -} - -.text_class7522 -{ -font-size: 11px; -} - -.text_class7523 -{ -} - -.text_class7524 -{ -} - -.paragraph_class7525 -{ -} - -.text_class7526 -{ -font-size: 11px; -} - -.text_class7527 -{ -} - -.text_class7528 -{ -} - -.paragraph_class7529 -{ -} - -.text_class7530 -{ -font-size: 11px; -} - -.paragraph_class7531 -{ -} - -.text_class7532 -{ -font-size: 11px; -} - -.paragraph_class7533 -{ -} - -.text_class7534 -{ -font-size: 11px; -} - -.paragraph_class7535 -{ -} - -.text_class7536 -{ -font-size: 11px; -} - -.paragraph_class7537 -{ -} - -.text_class7538 -{ -font-size: 11px; -} - -.paragraph_class7539 -{ -} - -.text_class7540 -{ -font-size: 11px; -} - -.paragraph_class7541 -{ -} - -.text_class7542 -{ -} \ No newline at end of file diff --git a/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm b/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm deleted file mode 100755 index 70dfae8..0000000 --- a/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm +++ /dev/null @@ -1 +0,0 @@ -

AGL Requirements Spec

Project AGL Project

Printed by

July 7, 2016, 10:18:17 AM EDT

.......................................................................................................................

Table of Contents

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.


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


 

 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

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


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.

 




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 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.

 

 


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.

 

・ 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.




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 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.




3.1.7 Role of Home Screen


Table 5-1 describes the role of the Home Screen to satisfy the purpose and use cases mentioned above.


No

Use Case

Role

Description

1-1

Layout

 

GUI Layout 

definition

Function to define a customizable GUI Layout definition.

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 Keyboard

Function to display software keyboard.

3-1

Application

Management

 

Application

Management

Function to download applications from application store. Function to install, uninstall and update the downloaded applications.

3-2

Application Launcher

Function to launch/terminate applications.

4-1

Application

Switch

 

Application List

Function to switch applications by 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.


Table 5-2:  Relevance of the Role and Purpose


No.

Role

Rich UX

Driver Distraction mitigation

Variations support

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

✓

✓

 


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)
  • 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.


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
  • 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.


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.


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. 


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.


Table 7-16 : Role of Resource Control


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 windows

Provide capability to overlay two or more 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 support

Provide capability to use hardware layer efficiently if hardware supports two or more hardware layers.

6

Reduced dependency of hardware

Provide well-defined interface to reduce dependency of hardware. Well-defined interface also makes it possible to increase the effect of portability and development cost.

7

Multi window / multi display

Support multi window management and multi display.

8

Compatibility

From the compatibility point of view, AGL should use public API, and shall not rely on hardware specific API.


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 different 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.


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-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

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 “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


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


Policy Manager is related with the below components.


Table 7-1: Related Components


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-1

Vehicle Info Control

Window Manager

Control screen resource such as show/hide windows.

5-2

Sound Manager

Control sound resource such as mute/unmute sound streams.

5-3

Input Manager

Control input resource such as notify/not notify touch event on touch panel display to applications.

5-4

Vehicle Info Distributor

Provide the vehicle information from vehicle network such as CAN.

5-5

User Manager

Detect user switching. Then Notify the definition of user information such as application list of login user.


(2)  Role


Policy Manager has the below role.


Table 7-2:  Role of Policy Manager


ID

Role

Description

1

External condition

collection

(1) Receives the external conditions.

2

Judgment of priority of GUI resource

(1) Receives the input/output/control request of

 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.




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 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.


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.


Table 7-3:  Definition of Layer Type


No

Type

Summary

Example

1

Basic

This is application’s basic screen. Typically, application requests this layer at first time.

Map of navigation

2

Interrupt

This is application’s popup screen.

Enlarged view of navigation

3

On-screen

This is system popup screen. Typically, On-screen service (e.g. Homescreen) requests this layer.

Warning message popup

4

Software keyboard

This is the software keyboard screen. Typically, software keyboard service requests this layer.

Software keyboard


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.


Table 7-4: Definition of Role


No

Contents

Summary

Example

1

Role

This is screen owner (such as application or service) role.

Navigation

2

Sub role

This is specific screen role.

Enlarged view


Role consists of role and sub role. Role is screen owner role such as “Navigation” and “Software 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.


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.


• 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.


Table 7-5:  Definition of sound type


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 requests this type.

Display touch sound


• 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.




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 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


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.


Policy Manager controls System resources by using “Resource Control” of kernel layer. So, target resources are CPU, memory, storage bandwidth and network bandwidth.


a.  Role


ID

Role

Description

1

External condition

collection

(1) Receives the external conditions.

3

System resource control

  • Issue the System resource control according to external condition change.
  • Kill process(s) forcibly according to external condition change.

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


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

 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

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.

  • 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.
  • 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.

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.

 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.

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.




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


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

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.


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 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)

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)

> 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.


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.


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.


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.


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.

 

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.


Table 7-15 : Role of Resource Control


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 hardware

Provide well-defined interface to reduce dependency of hardware. Well-defined interface also makes it possible to increase the effect of portability and development cost.


4.1.4.2 Requirements


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 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.


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.


By the way, associated input devices are listed below.


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.

Deliver to application or voice recognition engine.


Table 7-14 describes the role of input manager to be satisfied above purpose and use cases.


Table 7-14 : Role of Resource Control


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.


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.

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 Bob is 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


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

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.

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.


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 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


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

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.
  • 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 SQL


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.


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.

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,


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 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 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)


Table 19 : List of HFP supporting functions


 

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 HF

Option

x

9

Place a call using memory dialing

Option

-

10

Place a call to the last number dialed

Option

-

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


*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
  • 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.

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.


Table 20 : List of A2DP Supporting Functions


No.

Feature

Support in SNK

AGL

1

Audio Streaming

Mandatory

x


Table 21 : Supporting Codec


No.

Codec

Support

AGL

1

SBC

Mandatory

x

2

MPEG-1,2 Audio

Option

-

3

MPEG-2,4 AAC

Option

-

4

ATRAC family

Option

-


5.1.1.1.3 Phone Book Access Profile

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.

 

It has to comply with the specification for “Data Terminal (DT)”

 

Items marked with "x" in AGL column in Table 23 should be supported.


Table 23 : List of DUN Supporting Functions


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


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


No.

Feature

Support in Push Server

AGL

1

Object Push

Mandatory

x

2

Business Card Pull

Option

-

3

Business Card Exchange

Option

-


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


Table 25 : List of AVRCP Supporting Functions


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

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 hold

Option

x


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.


Table 26 : List of MAP Supporting Functions


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 Registration

C2

x


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.


Table 27 : List of PAN Supporting Functions


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

4

Lost NAP/GN Service Connection

Mandatory

x

5

Disconnect NAP/GN Service Connection

Mandatory

x

6

Management Information Base (MIB)

-

-


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


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

-

-


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.

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 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 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


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.


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.)
  • 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.


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

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.


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 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.


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


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.

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

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.


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.


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.


Table 29 : List of Wi-Fi Direct Supporting Functions


No.

Feature

 

(Reference)

Support in Wi-Fi Direct

1

P2P Provision Discovery

　

Mandatory

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


5.1.13.2.7 Miracast

It shall comply with Miracast standard.


It shall support the Miracast functions identified in Table 30. 


Table 30 : List of Miracast Supporting Functions


　No.

Feature

　

(Reference)

Support in Miracast

1

WFD Device type

WFD Source

Mandatory

2

　

Primary Sink

Mandatory

3

　

Dual-role possible

Option

4

WFD Service Discovery

　

Option

5

WFD connection establishment with Wi-Fi P2P

Mandatory

6

WFD connection establishment with Wi-Fi TDLS

Option

7

Persistent WFD Group

via Wi-Fi P2P

Option

8

　

via TDLS

Option

9

WFD Capability Negotiation (RTSP)

Mandatory

10

WFD Session Establishment (RTSP)

Mandatory

11

AV Streaming and Control (MPEG-TS/RTP/RTSP)

Mandatory

12

WFD Standby (RTP/RTSP)

Option

13

Video CODEC formats

Option

14

Audio CODEC formats

Option

15

UIBC

Generic

Option

16

 

HIDC

Option


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.


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 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.


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)
  • 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

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:


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

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


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


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


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.

AGL defines following Smartphone link (Miracast) specification as Table 8‑14.


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.1

P2P Topology

Define connection method of P2P (Wi-Fi Direct).

SPL.1.2.2

Wi-Fi Frequency

Define Wi-Fi frequency

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

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.


Table 8-32: State Definition


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.


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.




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 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.
    • 640*480（VGA）　Progressive 60 fps
    • 1280*720（HD）Progressive 30 fps

Regarding Video resolution and Frame rate, other formats are an option.


  • Support follow format for Audio.
    • LPCM 48ksps 16bit 2ch
    • 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 vendor’s own reason.
  • Support both encryption cases if support HDCP function.
    • Case1 Videos data encryption
    • 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.
    • Failed to Wi-Fi connection
    • Failed to establish Miracast session
    • Wi-Fi link loss on Miracast
    • 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 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.


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.

  • 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.


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.


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.


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 and 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.

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

  • 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
  • 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


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.


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.

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.

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.


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.


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.

  • 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.


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 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.


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.

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.


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. 

 

  • Reliabilitymeans 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.
  • Accessibilitymeans ability to use external storage devices, as well as accessing designated parts of internal file system over secure wired or wireless connections.
  • Serviceabilitymeans ability to upgrade AGL as a whole or by updating individual packages, and availability of file system checking and optimization tools.

 

Below is short summary for better understanding of FS Requirements hierarchy.


FS Requirements

R-FS References

  1. File Systems (P1)

6.1. Robust File System for managed internal storage (P1)

6.1.1. Power failure tolerance (P1)

6.1.2. Quick recovery after power loss (P1)

6.1.3. Multi-threaded I/O (P1)

6.1.4. On-demand integrity checker (P1)

6.1.5. Read-only mode (P1)

6.1.6. Non-blocking unmounting (P1)

6.1.7. Means for optimizing I/O performance if it may degrade under certain conditions. (P2)

6.1.8. File space pre-allocation (P2)

6.1.9. Meta-data error detection (P2)

6.1.10. File data error detection (P2)

6.1.11. Online integrity checking (P2)

6.1.12. Write timeout control (P2)

6.1.13. Compression support (P2)

6.1.14. Quota support (P2)

6.1.15. I/O process priority (P2)

6.1.16. File system event notifications (P2)

6.1.17. Logical block size control (P2)

6.1.18. Snapshots (P2)

6.2. File System for non-managed internal storage (P1)

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)

  1. btrfs

2.1. btrfsck

  1. ext2

3.1. e2defrag

  1. ext3
  2. ext4

5.1. e4defrag

5.2. e2fsck

  1. vfat
  2. UBIFS
  3. Generic tools and APIs

8.1. fanotify

8.2. fstrim


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, 


AGL shall provide robust file system suitable for use on non-managed internal storage devices, 


AGL shall provide a set of file systems popular on removable media devices.


A system must be able to withstand power failures under heavy load of meta-data-intensive, and data-intensive operations, including power-failures during OS startup, and shutdown.


A file system must be able to restore good data and meta-data state after unexpected power interruption without performing the full time-consuming integrity check. Such recovery should not add more than a second to the normal boot process after power failure on idle system. Normally this is achieved via journal- or log-based (also known as transactional or copy-on-write) operation.


A file system must be able to handle meta-data-intensive, and data-intensive I/O from multiple threads and/or processes simultaneously.


A file system must have integrity checking tool with ability to execute it on-demand.


A file system must be able to switch between read-only, (when no data is committed to physical storage device), and read/write modes in runtime. E.g. via “mount –o remount,ro <device>” command.


AGL must support “lazy” (delayed) unmounting.


AGL should provide means for optimizing potentially degraded I/O performance after prolonged file system and storage use. Often, this refers to offline or online file system defragmentation. Another example is periodic fstrim execution on SSD storage.


A file system should be able to pre-allocate space for created/extended files on request. This may be used to minimize fragmentation of frequently written files.


A file system should have an option of automatic error detection in its meta-data.


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 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 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.


Table 9-33 : Role of Resource Control


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.


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.


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.


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.

 

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.


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. 

  • Power failure tolerance (P1)
  • Quick recovery after power loss (P1)
  • Multi-threaded I/O (P1)
  • API bindings for C programming language
  • 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.


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.


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.

In applications that need to save data at power down, the programming access time must be fast. (target <1ms/byte)

N.B. EEPROM functionality can be emulated in flash memory passing the requirements above.


7.5.2 Graphics Drivers


Graphics drivers provide the interface to the graphical resources (e.g., GPU) within the system. This may include on-board graphical resources or a separate GPU from the main SOC.


7.5.3 Video Drivers


Video codecs allow the system to decode and/or encode video for playback or recording. Video codecs will nearly always be hardware based.


7.5.3.1 Requirements


The system shall provide device drivers to access any hardware implementation of video functionality. 


7.5.4 Audio Codecs


7.5.4.1 Requirements


Automotive Grade Linux BSPs shall provide devices drivers to access audio codecs that are implemented in hardware. 


Automotive Grade Linux BSPs should provide software implementations for those audio codecs that are required for AGL-based products and not supported in hardware.


7.5.5 Automotive Devices


Device drivers for automotive related devices. This may includes buses such as CAN, MOST,  or LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be 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.

AirPlay is a registered trademark of Apple, Inc.

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.

 


 \ No newline at end of file diff --git a/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp b/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp deleted file mode 100755 index 3c643f8..0000000 Binary files a/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp b/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp deleted file mode 100755 index 78023d1..0000000 Binary files a/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp b/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp deleted file mode 100755 index 5567500..0000000 Binary files a/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp b/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp deleted file mode 100755 index c2468f8..0000000 Binary files a/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp b/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp deleted file mode 100755 index 1fdd82a..0000000 Binary files a/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp b/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp deleted file mode 100755 index 48246db..0000000 Binary files a/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp b/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp deleted file mode 100755 index 1efdd2a..0000000 Binary files a/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp b/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp deleted file mode 100755 index 0aabf03..0000000 Binary files a/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp b/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp deleted file mode 100755 index 15830d1..0000000 Binary files a/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp b/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp deleted file mode 100755 index fe5496b..0000000 Binary files a/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp b/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp deleted file mode 100755 index 14eb699..0000000 Binary files a/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp b/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp deleted file mode 100755 index 7cefc5b..0000000 Binary files a/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp b/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp deleted file mode 100755 index 3109ca5..0000000 Binary files a/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp b/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp deleted file mode 100755 index b3cb683..0000000 Binary files a/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp b/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp deleted file mode 100755 index c87088e..0000000 Binary files a/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp b/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp deleted file mode 100755 index 3d60252..0000000 Binary files a/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp b/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp deleted file mode 100755 index b2c68a9..0000000 Binary files a/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp b/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp deleted file mode 100755 index abbd56a..0000000 Binary files a/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp b/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp deleted file mode 100755 index 0beff83..0000000 Binary files a/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp b/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp deleted file mode 100755 index 162ef6e..0000000 Binary files a/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp b/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp deleted file mode 100755 index 204a8ef..0000000 Binary files a/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp b/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp deleted file mode 100755 index e3a1bf3..0000000 Binary files a/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp b/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp deleted file mode 100755 index ca23958..0000000 Binary files a/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp b/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp deleted file mode 100755 index 3fd719f..0000000 Binary files a/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp b/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp deleted file mode 100755 index 8903a66..0000000 Binary files a/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp b/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp deleted file mode 100755 index 1912c99..0000000 Binary files a/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp and /dev/null differ diff --git a/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css b/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css deleted file mode 100755 index 48203f1..0000000 --- a/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css +++ /dev/null @@ -1,491 +0,0 @@ -body { - font-family:"Arial Unicode MS","sans-serif"; -} - -p.MsoNormal, li.MsoNormal, div.MsoNormal { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin: 0in; - margin-bottom: .0001pt; -} - -h1 { - color: #008A52; - font-size: 14.0pt; - font-weight: bold; - margin-bottom: 12.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 6.0pt; - page-break-after: avoid; -} - -h2 { - color: #222222; - font-size: 12.0pt; - font-weight: normal; - line-height: 12.0pt; - margin-bottom: 12.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 6.0pt; - page-break-after: avoid; -} - -h3 { - color: #222222; - font-size: 10.0pt; - font-weight: bold; - line-height: 12.0pt; - margin: 0in; - margin-bottom: .0001pt; - page-break-after: avoid; -} - -h4 { - color: #666666; - font-size: 9.0pt; - font-weight: bold; - line-height: 12.0pt; - margin-bottom: 12.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 6.0pt; - page-break-after: avoid; -} - -h5 { - color: #222222; - font-size: 11.0pt; - font-weight: normal; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 12.0pt; -} - -h6 { - color: #222222; - font-size: 11.0pt; - font-style: italic; - font-weight: normal; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 12.0pt; -} - -p.MsoHeading7, li.MsoHeading7, div.MsoHeading7 { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 12.0pt; -} - -p.MsoHeading8, li.MsoHeading8, div.MsoHeading8 { - color: #222222; - font-size: 10.0pt; - font-style: italic; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 12.0pt; -} - -p.MsoHeading9, li.MsoHeading9, div.MsoHeading9 { - color: #222222; - font-size: 9.0pt; - font-style: italic; - font-weight: bold; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 12.0pt; -} - -p.MsoToc1, li.MsoToc1, div.MsoToc1 { - color: #007670; - font-size: 14.0pt; - font-weight: bold; - margin-bottom: 6.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 6.0pt; -} - -p.MsoToc2, li.MsoToc2, div.MsoToc2 { - color: #222222; - font-size: 11.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 6.0pt; -} - -p.MsoToc3, li.MsoToc3, div.MsoToc3 { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: .1in; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoToc4, li.MsoToc4, div.MsoToc4 { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: .4in; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoToc5, li.MsoToc5, div.MsoToc5 { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 40.0pt; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoToc6, li.MsoToc6, div.MsoToc6 { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 50.0pt; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoToc7, li.MsoToc7, div.MsoToc7 { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 60.0pt; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoToc8, li.MsoToc8, div.MsoToc8 { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 70.0pt; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoToc9, li.MsoToc9, div.MsoToc9 { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 80.0pt; - margin-right: 0in; - margin-top: 0in; -} - -p.MsoCommentText, li.MsoCommentText, div.MsoCommentText { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin: 0in; - margin-bottom: .0001pt; - mso-style-link: "Comment Text Char"; -} - -p.MsoHeader, li.MsoHeader, div.MsoHeader { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin: 0in; - margin-bottom: .0001pt; -} - -p.MsoFooter, li.MsoFooter, div.MsoFooter { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin: 0in; - margin-bottom: .0001pt; -} - -p.MsoTof, li.MsoTof, div.MsoTof { - color: #008A52; - font-size: 18.0pt; - margin-bottom: .0001pt; - margin-left: 20.0pt; - margin-right: 0in; - margin-top: 0in; - mso-style-link: "Table of Figures Char"; - text-indent: -20.0pt; -} - -p.MsoTitle, li.MsoTitle, div.MsoTitle { - color: #007670; - font-size: 36.0pt; - font-weight: bold; - margin: 0in; - margin-bottom: .0001pt; - text-align: right; -} - -p.MsoBodyText, li.MsoBodyText, div.MsoBodyText { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: .5in; - margin-right: 0in; - margin-top: 0in; - mso-style-link: "Body Text Char"; -} - -p.MsoBodyTextIndent2, li.MsoBodyTextIndent2, div.MsoBodyTextIndent2 { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: .5in; - margin-right: 0in; - margin-top: 0in; -} - -a:link, span.MsoHyperlink { - color: #3087B3; - text-decoration: none; -} - -a:visited, span.MsoHyperlinkFollowed { - color: #3087B3; - text-decoration: none; -} - -p { - color: #222222; - font-size: 12.0pt; - margin-left: 0in; - margin-right: 0in; -} - -p.MsoCommentSubject, li.MsoCommentSubject, div.MsoCommentSubject { - color: #222222; - font-size: 10.0pt; - font-weight: bold; - line-height: 12.0pt; - margin: 0in; - margin-bottom: .0001pt; - mso-style-link: "Comment Subject Char"; -} - -p.MsoAcetate, li.MsoAcetate, div.MsoAcetate { - color: #222222; - font-size: 8.0pt; - margin: 0in; - margin-bottom: .0001pt; - mso-style-link: "Balloon Text Char"; -} - -p.MsoRMPane, li.MsoRMPane, div.MsoRMPane { - color: windowtext; - font-size: 10.0pt; - margin: 0in; - margin-bottom: .0001pt; -} - -p.MsoTocHeading, li.MsoTocHeading, div.MsoTocHeading { - color: #008A52; - font-size: 18.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 12.0pt; - page-break-after: avoid; -} - -p.Tabletext, li.Tabletext, div.Tabletext { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 0in; - mso-style-name: Tabletext; -} - -p.InfoBlue, li.InfoBlue, div.InfoBlue { - color: blue; - font-size: 10.0pt; - font-style: italic; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: .5in; - margin-right: 0in; - margin-top: 0in; - mso-style-name: InfoBlue; -} - -p.Figure, li.Figure, div.Figure { - color: #008A52; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: .0001pt; - margin-left: 28.35pt; - margin-right: 0in; - margin-top: 0in; - mso-style-link: "Figure Char"; - mso-style-name: Figure; - text-indent: -28.35pt; -} - -span.TableofFiguresChar { - color: #008A52; - mso-style-link: "Table of Figures"; - mso-style-name: "Table of Figures Char"; -} - -span.FigureChar { - color: #008A52; - mso-style-link: Figure; - mso-style-name: "Figure Char"; -} - -span.CommentTextChar { - color: #222222; - mso-style-link: "Comment Text"; - mso-style-name: "Comment Text Char"; -} - -span.CommentSubjectChar { - color: #222222; - font-weight: bold; - mso-style-link: "Comment Subject"; - mso-style-name: "Comment Subject Char"; -} - -p.Body2, li.Body2, div.Body2 { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: 78.0pt; - margin-right: 0in; - margin-top: 0in; - mso-style-link: "Body2 Char"; - mso-style-name: Body2; -} - -span.textclass4 { - mso-style-name: text_class4; -} - -span.BodyTextChar { - color: #222222; - mso-style-link: "Body Text"; - mso-style-name: "Body Text Char"; -} - -span.Body2Char { - color: #222222; - mso-style-link: Body2; - mso-style-name: "Body2 Char"; -} - -p.BodyTextBold, li.BodyTextBold, div.BodyTextBold { - color: #222222; - font-size: 10.0pt; - font-weight: bold; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: .5in; - margin-right: 0in; - margin-top: 0in; - mso-style-name: "Body Text Bold"; -} - -p.BodyTextUnderlined, li.BodyTextUnderlined, div.BodyTextUnderlined { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: .5in; - margin-right: 0in; - margin-top: 0in; - mso-style-name: "Body Text Underlined"; - text-decoration: underline; -} - -p.colbody, li.colbody, div.colbody { - color: #222222; - font-size: 9.0pt; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 3.0pt; - mso-style-name: colbody; -} - -p.colheading, li.colheading, div.colheading { - color: #666666; - font-size: 9.0pt; - font-weight: bold; - line-height: 12.0pt; - margin-bottom: 3.0pt; - margin-left: 0in; - margin-right: 0in; - margin-top: 3.0pt; - mso-style-name: colheading; -} - -p.detail, li.detail, div.detail { - color: #222222; - font-size: 10.0pt; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: 70.3pt; - margin-right: 0in; - margin-top: 0in; - mso-style-name: detail; - text-indent: -70.3pt; -} - -p.prompt, li.prompt, div.prompt { - color: #222222; - font-size: 10.0pt; - font-style: italic; - font-weight: bold; - line-height: 12.0pt; - margin-bottom: 6.0pt; - margin-left: 70.3pt; - margin-right: 0in; - margin-top: 0in; - mso-style-name: prompt; - text-indent: -70.3pt; -} - -p.TitleExtras, li.TitleExtras, div.TitleExtras { - color: #222222; - font-size: 16.0pt; - margin: 0in; - margin-bottom: .0001pt; - mso-style-name: "Title Extras"; - text-align: right; -} \ No newline at end of file diff --git a/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png b/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png deleted file mode 100644 index 3c643f8..0000000 Binary files a/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 10.png b/agl-specs-v1.0/media/Image 10.png deleted file mode 100644 index ca23958..0000000 Binary files a/agl-specs-v1.0/media/Image 10.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 14.png b/agl-specs-v1.0/media/Image 14.png deleted file mode 100644 index c87088e..0000000 Binary files a/agl-specs-v1.0/media/Image 14.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 15.png b/agl-specs-v1.0/media/Image 15.png deleted file mode 100644 index 0aabf03..0000000 Binary files a/agl-specs-v1.0/media/Image 15.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 16.png b/agl-specs-v1.0/media/Image 16.png deleted file mode 100644 index 3fd719f..0000000 Binary files a/agl-specs-v1.0/media/Image 16.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 17.png b/agl-specs-v1.0/media/Image 17.png deleted file mode 100644 index c2468f8..0000000 Binary files a/agl-specs-v1.0/media/Image 17.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 21.png b/agl-specs-v1.0/media/Image 21.png deleted file mode 100644 index 162ef6e..0000000 Binary files a/agl-specs-v1.0/media/Image 21.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 22.png b/agl-specs-v1.0/media/Image 22.png deleted file mode 100644 index 1efdd2a..0000000 Binary files a/agl-specs-v1.0/media/Image 22.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 23.png b/agl-specs-v1.0/media/Image 23.png deleted file mode 100644 index 3109ca5..0000000 Binary files a/agl-specs-v1.0/media/Image 23.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 24.png b/agl-specs-v1.0/media/Image 24.png deleted file mode 100644 index 8903a66..0000000 Binary files a/agl-specs-v1.0/media/Image 24.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 25.png b/agl-specs-v1.0/media/Image 25.png deleted file mode 100644 index 1fdd82a..0000000 Binary files a/agl-specs-v1.0/media/Image 25.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 26.png b/agl-specs-v1.0/media/Image 26.png deleted file mode 100644 index abbd56a..0000000 Binary files a/agl-specs-v1.0/media/Image 26.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 27.png b/agl-specs-v1.0/media/Image 27.png deleted file mode 100644 index 48246db..0000000 Binary files a/agl-specs-v1.0/media/Image 27.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 28.png b/agl-specs-v1.0/media/Image 28.png deleted file mode 100644 index 14eb699..0000000 Binary files a/agl-specs-v1.0/media/Image 28.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 29.png b/agl-specs-v1.0/media/Image 29.png deleted file mode 100644 index 204a8ef..0000000 Binary files a/agl-specs-v1.0/media/Image 29.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 30.png b/agl-specs-v1.0/media/Image 30.png deleted file mode 100644 index b3cb683..0000000 Binary files a/agl-specs-v1.0/media/Image 30.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 39.png b/agl-specs-v1.0/media/Image 39.png deleted file mode 100644 index 1912c99..0000000 Binary files a/agl-specs-v1.0/media/Image 39.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 40.png b/agl-specs-v1.0/media/Image 40.png deleted file mode 100644 index 0beff83..0000000 Binary files a/agl-specs-v1.0/media/Image 40.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 41.png b/agl-specs-v1.0/media/Image 41.png deleted file mode 100644 index b2c68a9..0000000 Binary files a/agl-specs-v1.0/media/Image 41.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 60.png b/agl-specs-v1.0/media/Image 60.png deleted file mode 100644 index e3a1bf3..0000000 Binary files a/agl-specs-v1.0/media/Image 60.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 8.png b/agl-specs-v1.0/media/Image 8.png deleted file mode 100644 index 5567500..0000000 Binary files a/agl-specs-v1.0/media/Image 8.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Image 9.png b/agl-specs-v1.0/media/Image 9.png deleted file mode 100644 index 3d60252..0000000 Binary files a/agl-specs-v1.0/media/Image 9.png and /dev/null differ diff --git a/agl-specs-v1.0/media/Smartlink State Diagram.png b/agl-specs-v1.0/media/Smartlink State Diagram.png deleted file mode 100644 index fe5496b..0000000 Binary files a/agl-specs-v1.0/media/Smartlink State Diagram.png and /dev/null differ diff --git a/agl-specs-v1.0/media/picture95.png b/agl-specs-v1.0/media/picture95.png deleted file mode 100644 index 5caaae0..0000000 Binary files a/agl-specs-v1.0/media/picture95.png and /dev/null differ diff --git a/app-framework/index.md b/app-framework/index.md deleted file mode 100644 index 5690fda..0000000 --- a/app-framework/index.md +++ /dev/null @@ -1,86 +0,0 @@ -# AGL Application Framework - -This page summarizes all materials related to AGL Application Framework - -## Source Code - -The current code of AGL App-Framework is stored on AGL Code Repository. It's divided in the following projects: - -* [src/app-framework-main](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src%2Fapp-framework-main.git;a=summary) Main services -* [src/app-framework-binder](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src%2Fapp-framework-binder.git;a=summary): Binder Daemon -* [src/app-framework-demo](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src%2Fapp-framework-demo.git;a=summary) Demos - -## Building AGL with Application Framework support - -The Application Framework can be added easily to an AGL build using the feature 'agl-appfw-smack'. - -Typically, the following command can be called to initialize AGL build: - - # meta-agl/scripts/aglsetup.sh -m porter agl-appfw-smack agl-demo agl-devel - ... - # bitbake agl-demo-platform - -## Documentation - -Technical documentation is maintained in the source code and should be browsable with the [upcoming AGL documentation system](https://github.com/automotive-grade-linux/docs-agl) - -Temporarily, a static documentation has been made in PDF format: - -* [Introduction to Application Framework](http://iot.bzh/download/public/2016/appfw/01_Introduction-to-AppFW-for-AGL-1.0.pdf) -* [AppFW Core Documentation](http://iot.bzh/download/public/2016/appfw/02_Documentation-AppFW-Core-2.0.pdf) -* [Privileges Management](http://iot.bzh/download/public/2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) - -Some extra guides are also available in PDF format: - -* [Build your 1st AGL Application](http://iot.bzh/download/public/2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf) -* Applications Templates are available on [github:iotbzh/app-framework-templates](https://github.com/iotbzh/app-framework-templates) - -### Bindings Examples - -Some bindings are available to quickstart new projects: - -* GPS - see [github:iotbzh/af-gps-binding](https://github.com/iotbzh/af-gps-binding/blob/master/src/af-gps-binding.c) -* OpenXC Reader - see [github:iotbzh/txc-demo](https://github.com/iotbzh/txc-demo/blob/master/binding/txc-binding.c) -* CPU/Memory stats - see [github:iotbzh/txc-demo](https://github.com/iotbzh/txc-demo/blob/master/binding/stat-binding.c) -* Radio - see [gerrit:src/app-framework-binder](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-binder.git;a=tree;f=bindings/radio;hb=master) -* Audio - see [gerrit:src/app-framework-binder](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-binder.git;a=tree;f=bindings/audio;hb=master) - -The list is not exhaustive. ***Please add other bindings here !*** - -### Demos - -* Simple HTML5 Demos apps (ported from Tizen) on [github:iotbzh/afm-widget-examples](https://github.com/iotbzh/afm-widget-examples) -* Installable package with [TXC Demo Application](http://iot.bzh/download/public/2016/afb-demos/txc-demo_0.1.wgt) -* Applications available in [gerrit:app-framework-demo](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-demo.git;a=summary) - -## Presentations - -* Oct 16 - [Application Security Model - Status Update](http://iot.bzh/download/public/2016/genivi/CyberSecurity-Genivi-Q42016-Fulup-IoTbzh.pdf) -* Sept 16 - [Building Applications with AGL Framework](http://iot.bzh/download/public/2016/genivi/CyberSecurity-Genivi-Q42016-Fulup-IoTbzh.pdf) - Also visible in [PDF version](http://iot.bzh/download/public/2016/publications/build-agl-application-AMM-Munich-2016.pdf) -* Feb 16 - [HTML5 Apps for Automotive Systems](http://iot.bzh/download/public/2016/publications/HTML5_Applications_for_Automotive_Systems.pdf) -* Feb 16 - [Application & Security Framework Proposal AGL 2.0](http://iot.bzh/download/public/2016/security/Security-Proposal-AGL20-Fulup.pdf) -* Jan 16 - [Security Architecture Proposal](http://iot.bzh/download/public/2016/security/Security-Architecture-AGL20.pdf) - -## History - -### Motivation for rewriting the App. Framework - -To get the background and motivation on why Application Framework has been rewritten: - -* [Tizen Security: lessons learnt](http://iot.bzh/download/public/2015/tizen-security-lessons-learnt-initial.pdf) -* [this discussion](https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-October/002749.html) -* [Linux Automotive Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf) - -### Comparison/Relationship with Tizen - - Tizen AGL - ---------------------------------- - App/OS isolation yes yes - Container option no possible - Native App partial* yes - HTML5 App yes yes - Cloud App No yes - Unified API (HTLM/Native) No yes - service as App** No yes - Adding API *** core core or App - Devel model bespoke Standard Web diff --git a/audio/4a-framework.md b/audio/4a-framework.md deleted file mode 100644 index d54f12b..0000000 --- a/audio/4a-framework.md +++ /dev/null @@ -1,6 +0,0 @@ -# AGL Audio High Level Binding (4A) - -The Audio High Level Binding is the upper layer in the Audio 4A architecture. - -Presentation is available: -[4a-presentation-by-audiokinetics](https://schd.ws/hosted_files/aglammeu17/aa/HighLevelAudio_DresdenAMM_Final_0.pdf) diff --git a/audio/bluez-alsa.md b/audio/bluez-alsa.md deleted file mode 100644 index bbdef77..0000000 --- a/audio/bluez-alsa.md +++ /dev/null @@ -1,113 +0,0 @@ -# bluez-alsa - -## Introduction - -Bluetooth Audio ALSA Backend allow bluetooth audio without PulseAudio. - -This project is a rebirth of a direct integration between Bluez and ALSA. Since Bluez >= 5, the build-in integration has been removed in favor of 3rd party audio applications. From now on, Bluez acts as a middleware between an audio application, which implements Bluetooth audio profile, and a Bluetooth audio device. - -github source : [bluez-alsa](https://github.com/Arkq/bluez-alsa) - -## Add bluez-alsa to an AGL image - -You can add bluez-alsa to your image - -```yocto -IMAGE_INSTALL_append = "bluez-alsa" -``` - -## Check bluez-alsa status - -You can check the bluez-alsa status by running: - -```bash -systemctl status bluez-alsa.service -``` - -## Stop pulseaudio - -You must disable pulseaudio if you want to use bluez-alsa - -```bash -systemctl --user stop pulseaudio -``` - -or disable pulseaudio bluetooth support - -```bash -vi /etc/pulse/default.pa -#.ifexists module-bluetooth-policy.so -#load-module module-bluetooth-policy -#.endif - -#.ifexists module-bluetooth-discover.so -#load-module module-bluetooth-discover -#.endif -``` - -## Connect your Bluetooth device - -You need to connect a bluetooth device - -```bash -$ bluetoothctl -[bluetooth]# pair ${BT_ADDR} -[bluetooth]# connect ${BT_ADDR} -[bluetooth]# info ${BT_ADDR} -``` - -Here somes documentation links: - -* [Bluetooth headset from archlinux](https://wiki.archlinux.org/index.php/Bluetooth_headset) -* [Bluetooth Headset from gentoo](https://wiki.gentoo.org/wiki/Bluetooth_Headset) -* [Bluez A2DP AudioSink for ALSA](http://www.lightofdawn.org/blog/?viewDetailed=00032) -* [Bluez A2DP](http://www.lightofdawn.org/wiki/wiki.cgi/BluezA2DP) - -## Test bluez-alsa speacker - -```bash -wget http://www.kozco.com/tech/piano2.wav - -aplay -D bluealsa:HCI=hci0,DEV=${BT_ADDR},PROFILE=a2dp ./piano2.wav -``` - -## Add bluez-alsa pcm config to alsa - -```bash -vi /etc/asound.conf -# Bluetooth headset -pcm.btheadset { - type plug - slave.pcm { - type bluealsa - device "${BT_ADDR}" - profile "a2dp" - } - hint { - show on - description "Bluetooth Audio ALSA Backend" - } -} -``` - -Doc [asoundrc](https://alsa.opensrc.org/Asoundrc) - -Test bluez-alsa pcm - -```bash -aplay -D btheadset ./piano2.wav -``` - -## Test gstreamer player - -```bash -gst-launch-1.0 uridecodebin uri=file:///mnt/Holy-Mountain.mp3 ! alsasink device=btheadset -``` - -## Test bluez-alsa phone - -After connected your phone with bluez: - -```bash -bluealsa-aplay ${BT_ADDR} -``` diff --git a/docs/agl-specs-v1.0/00-doorsNG-original.md b/docs/agl-specs-v1.0/00-doorsNG-original.md new file mode 100644 index 0000000..d41635d --- /dev/null +++ b/docs/agl-specs-v1.0/00-doorsNG-original.md @@ -0,0 +1,7753 @@ +--- +# Master Header for Jkyll +--- + +> ![](media/picture8.jpeg)![](media/picture9.jpeg)Version   1.0 +> +> Automotive Grade Linux +> +> Requirements Specification +> +> May   28,   2015 +> +> www.automotivelinux.org +> +> www.linuxfoundation.org +> +> ![](media/picture10.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Table of Contents +> +> [***1***](#5)***  Automotive  Grade  Linux ...............................................................................................*** +> ***5*** +> +> [**1.1**](#5)**  Overview  ............................................................................................................................** +> **5** +> +> [**1.2**](#6)**  Document  Scope.................................................................................................................** +> **6** +> +> [**1.3**](#6)**  Glossary  of  Terms  ..............................................................................................................** +> **6** +> +> [***2***](#7)***  Architecture ..................................................................................................................*** +> ***7*** +> +> [***3***](#8)***  App/HMI  Layer  .............................................................................................................*** +> ***8*** +> +> [**3.1**](#9)**  Home  Screen  ......................................................................................................................** +> **9** +> +> [3.1.1](#9)  Layout......................................................................................................................................... +> 9 +> +> [3.1.2](#10)  System  UI  Parts........................................................................................................................ +> 10 +> +> [3.1.3](#10)  Application  Management .......................................................................................................... +> 10 +> +> [3.1.4](#10)  Application  Switch.................................................................................................................... +> 10 +> +> [3.1.5](#10)  Application  History ................................................................................................................... +> 10 +> +> [3.1.6](#12)  Application  Stack ...................................................................................................................... +> 12 +> +> [3.1.7](#14)  Role  of  Home  Screen................................................................................................................ +> 14 +> +> [3.1.8](#16)  Requirements  ........................................................................................................................... +> 16 +> +> [***4***](#20)***  Application  Framework  Layer .....................................................................................*** +> ***20*** +> +> [**4.1**](#20)**  AGL  Application  Framework .............................................................................................** +> **20** +> +> [4.1.1](#21)  Application  Manager................................................................................................................. +> 21 +> +> [4.1.2](#21)  Window  Manager ..................................................................................................................... +> 21 +> +> [4.1.3](#27)  Policy  Manager ......................................................................................................................... +> 27 +> +> [4.1.4](#59)  Sound  Manager  ........................................................................................................................ +> 59 +> +> [4.1.5](#63)  Input  Manager .......................................................................................................................... +> 63 +> +> [4.1.6](#65)  User  Manager ........................................................................................................................... +> 65 +> +> [**4.2**](#71)**  Web  HMI ..........................................................................................................................** +> **71** +> +> [4.2.1](#71)  Web  API  ................................................................................................................................... +> 71 +> +> [4.2.2](#75)  Web  Runtime............................................................................................................................ +> 75 +> +> [**4.3**](#76)**  Native  HMI .......................................................................................................................** +> **76** +> +> [4.3.1](#76)  Native  App  Runtime.................................................................................................................. +> 76 +> +> [4.3.2](#77)  Native  Application  Framework  ................................................................................................. +> 77 +> +> [***5***](#77)***  Services  Layer  ............................................................................................................*** +> ***77*** +> +> [**5.1**](#78)**  Platform  Services  .............................................................................................................** +> **78** +> +> [5.1.1](#78)  Bluetooth  ................................................................................................................................. +> 78 +> +> [5.1.2](#92)  Error  Management.................................................................................................................... +> 92 +> +> [5.1.3](#98)  Graphics  ................................................................................................................................... +> 98 +> +> [5.1.4](#98)  Location  Services...................................................................................................................... +> 98 +> +> Page  2  of  159 +> +> ![](media/picture46.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> [5.1.5](#100)  Health  Monitoring .................................................................................................................. +> 100 +> +> [5.1.6](#100)  IPC  ......................................................................................................................................... +> 100 +> +> [5.1.7](#100)  Lifecycle  Management............................................................................................................ +> 100 +> +> [5.1.8](#100)  Network  Services................................................................................................................... +> 100 +> +> [5.1.9](#100)  Persistent  Storage  ................................................................................................................. +> 100 +> +> [5.1.10](#100)  Power  Management ............................................................................................................. +> 100 +> +> [5.1.11](#102)  Resource  Management......................................................................................................... +> 102 +> +> [5.1.12](#102)  Telephony  Services .............................................................................................................. +> 102 +> +> [5.1.13](#103)  Wi-Fi .................................................................................................................................... +> 103 +> +> [5.1.14](#110)  Window  System................................................................................................................... +> 110 +> +> [**5.2**](#111)**  Automotive  Services  ......................................................................................................** +> **111** +> +> [5.2.1](#111)  Audio  Services........................................................................................................................ +> 111 +> +> [5.2.2](#111)  Camera  Services..................................................................................................................... +> 111 +> +> [5.2.3](#111)  Configuration  Services ........................................................................................................... +> 111 +> +> [5.2.4](#111)  Diagnostic  Services ................................................................................................................ +> 111 +> +> [5.2.5](#111)  Multimedia  Services  ............................................................................................................... +> 111 +> +> [5.2.6](#116)  Navigation  Services................................................................................................................ +> 116 +> +> [5.2.7](#117)  PIM......................................................................................................................................... +> 117 +> +> [5.2.8](#117)  Smartphone  Link  .................................................................................................................... +> 117 +> +> [5.2.9](#125)  Speech  Services  ..................................................................................................................... +> 125 +> +> [5.2.10](#125)  Tuner  Services  ..................................................................................................................... +> 125 +> +> [5.2.11](#132)  Vehicle  Bus  /  Vehicle  Info  Control........................................................................................ +> 132 +> +> [5.2.12](#141)  Telematics  Services.............................................................................................................. +> 141 +> +> [5.2.13](#142)  Window  System................................................................................................................... +> 142 +> +> [***6***](#143)***  Security  Services......................................................................................................*** +> ***143*** +> +> [**6.1**](#143)**  Access  Control ...............................................................................................................** +> **143** +> +> [6.1.1](#144)  Requirements ......................................................................................................................... +> 144 +> +> [***7***](#144)***  Operating  System  Layer  ..........................................................................................*** +> ***144*** +> +> [**7.1**](#144)**  Kernel  ............................................................................................................................** +> **144** +> +> [7.1.1](#144)  Linux  Kernel  ........................................................................................................................... +> 144 +> +> [**7.2**](#145)**  Boot  Loader  ...................................................................................................................** +> **145** +> +> [**7.3**](#145)**  Hypervisor  .....................................................................................................................** +> **145** +> +> [7.3.1](#145)  Requirements ......................................................................................................................... +> 145 +> +> [**7.4**](#145)**  Operating  System  ..........................................................................................................** +> **145** +> +> [7.4.1](#145)  File  Systems ........................................................................................................................... +> 145 +> +> [7.4.2](#150)  Resource  Control  ................................................................................................................... +> 150 +> +> [7.4.3](#153)  Startup/Shutdown  Control  .................................................................................................... +> 153 +> +> [7.4.4](#155)  Database ................................................................................................................................ +> 155 +> +> [7.4.5](#156)  System  Update....................................................................................................................... +> 156 +> +> [**7.5**](#157)**  Device  Drivers ................................................................................................................** +> **157** +> +> Page  3  of  159 +> +> ![](media/picture87.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> [7.5.1](#157)  Peripherals ............................................................................................................................. +> 157 +> +> [7.5.2](#158)  Graphics  Drivers..................................................................................................................... +> 158 +> +> [7.5.3](#158)  Video  Drivers.......................................................................................................................... +> 158 +> +> [7.5.4](#158)  Audio  Codecs  ......................................................................................................................... +> 158 +> +> [7.5.5](#158)  Automotive  Devices  ............................................................................................................... +> 158 +> +> [***8***](#159)***  Notices.....................................................................................................................*** +> ***159*** +> +> Page  4  of  159 +> +> ![](media/picture94.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **1   Automotive   Grade   Linux** +> +> 1.1  Overview +> +> Automotive  Grade  Linux  (AGL)  is  a  Linux  Foundation  Workgroup  dedicated  to  creating  open +> +> source  software  solutions  for  automotive  applications.  Although  the  initial  target  for  AGL  is  In- +> +> Vehicle-Infotainment  (IVI)  systems,  additional  use  cases  such  as  instrument  clusters  and  and +> +> telematics  systems  will  eventually  be  supported.  AGL  has  participants  from  the  Automotive, +> +> Communications,  and  Semiconductor  Industries  and  welcomes  contributions  from  individual +> +> developers. +> +> By  leveraging  the  over  \$10B  of  investment  made  in  the  Linux  kernel  and  other  open  source +> +> software  projects,  the  AGL  Workgroup: +> +> · +> Enables  rapid  software  innovation  for  automotive  suppliers  to  keep  up  with  the  demand +> +> from  consumers  for  better  IVI  experiences +> +> · +> Utilizes  the  talents  of  thousands  of  open  source  software  developers  dedicated  to +> +> maintaining  the  core  software  in  areas  like  the  Linux  kernel,  networking,  and +> +> connectivity,  used  in  systems  across  numerous  industries +> +> The  goals  of  the  Automotive  Grade  Linux  Workgroup  are  to  provide: +> +> · +> An  automotive-focused  core  Linux  operating  system  stack  that  meets  common  and +> +> shared  requirements  of  the  automotive  ecosystem  with  a  broad  community  of +> +> support  that  includes  individual  developers,  academic  organizations  and  companies. +> +> · +> A  transparent,  collaborative,  and  open  environment  for  Automotive  OEMs,  Tier  One +> +> suppliers,  and  their  semiconductor  and  software  vendors  to  create  amazing  in-vehicle +> +> software. +> +> · +> A  collective  voice  for  working  with  other  open  source  projects  and  developing  new  open +> +> source  solutions. +> +> · +> An  embedded  Linux  distribution  that  enables  rapid  prototyping  for  developers  new  to +> +> Linux  or  teams  with  prior  open  source  experience +> +> This  results  in  faster  time  to  market  by  jump-starting  product  teams  with  reference  applications +> +> running  on  multiple  hardware  platforms. +> +> Page  5  of  159 + + > **Term** > **Definition** + ------------ ------------------------------------------ + > A2DP > Advanced  Audio  Distribution  Profile + > AGL > Automotive  Grade  Linux + > AVRCP > Audio  Video  Remote  Control  Profile + > FS > File  System + > GPS > Global  Positioning  System + > GPU > Graphical  Processing  Unit + +> ![](media/picture95.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 1.2  Document  Scope +> +> The  scope  of  this  document  is  to  define  the  architecture  of  the  Automotive  Grade  Linux  software +> +> platform.  The  requirements  are  broken  up  into  an  overview  of  the  Architecture  and  a  description +> +> of  each  of  the  layers  in  the  architecture  followed  by  the  requirements  for  each  module  in  the +> +> various  layers.  The  Architecture  Diagram  and  the  layout  of  the  specification  take  into +> +> consideration  all  of  the  components  that  would  be  needed  for  an  IVI  system;  however  the  are +> +> missing  requirements  for  individual  modules.  As  the  spec  continues  to  evolve  those  sections  will +> +> continue  to  be  filled  in. +> +> The  main  goal  of  this  document  is  to  define  the  core  software  platform  from  which  applications +> +> can  be  built.  As  such,  this  document  does  not  define  application  requirements  except  in  a  single +> +> case  (Home  Screen).  Application  requirements  will  be  developed  by  various  projects  that  use  the +> +> AGL  platform.  Those  application  requirements  can  be  used  to  drive  new  or  revised +> +> requirements  into  the  platform. +> +> At  this  time  there  is  no  plan  to  use  this  specification  to  create  a  compliance  or  certification +> +> program.  The  specification  is  used  as  blueprint  to  guide  the  overall  work  of  AGL  and  to  derive +> +> work  packages  for  companies  and  individuals  to  complete  in  order  to  attain  the  goals  of  the  AGL +> +> Workgroup. +> +> 1.3  Glossary  of  Terms + + > HFP > Hands  Free  Profile + -------- ------------------------------------- + > IBOC > In-Band  On  Channel + > LTSI > Long  Term  Support  Initiative + > NTP > Network  Time  Protocol + > OEM > Original  Equipment  Manufacturer + > OS > Operating  System + > OSS > Open  Source  Software + > SDL > Smart  Device  Link + > STT > Speech  to  Text + > TTS > Text  to  Speech + +> ![](media/picture96.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **2   Architecture** +> +> The  Automotive  Grade  Linux  Software  Architecture  diagram  is  below.  The  architecture  consists +> +> of  five  layers.  The  App/HMI  layer  contains  applications  with  their  associated  business  logic  and +> +> HMI.  Generally  applications  are  out  of  scope  for  this  document  since  they  are  product  specific +> +> for  the  OEM  that  is  developing  a  system  based  on  AGL. +> +> The  Application  Framework  layer  provides  the  APIs  for  creating  both  managing  and  running +> +> applications  on  an  AGL  system.  The  Services  layer  contains  user  space  services  that  all +> +> applications  can  access.  The  Operating  System  (OS)  layer  provides  the  Linux  kernel  and  device +> +> drivers  along  with  standard  OS  utilities. +> +> Page  7  of  159 +> +> ![](media/picture97.jpeg)![](media/picture98.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **3   App/HMI   Layer** +> +> Applications  may  use  a  web  based  framework  or  a  native  framework.  A  system  may  include +> +> applications  that  use  different  frameworks.  Coordination  of  applications  between  frameworks  is +> +> performed  by  the  AGL  App  Framework.  The  diagram  represents  possible  applications  that  could +> +> appear  in  a  given  system,  but  is  not  all  inclusive.  Reference  applications  may  be  provided  by  AGL +> +> Page  8  of  159 +> +> ![](media/picture99.jpeg)![](media/picture100.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> to  demonstrate  the  capabilities  of  the  platform. +> +> 3.1  Home  Screen +> +> Home  Screen  provides  the  Home  User  Interface  (Home  UI)  of  the  system  which  meets  the +> +> following  requirements: +> +> · Rich  User  Experience  (Rich  UX) +> +> · Driver  Distraction  mitigation +> +> · Variations  support +> +> Rich  UX  covers  requirements  such  as  usability  and  user  satisfaction.  Driver  Distraction  mitigation +> +> covers  requirements  on  display  control  and  user  operation  behavior  while  vehicle  is  in  motion  to +> +> minimize  driver  distraction.  Variations  support  covers  requirements  to  support  customization  of +> +> design  and  behavior  of  the  system  to  meet  the  different  needs  of  vehicle  type,  destination  and +> +> grade. +> +> **3.1.1  Layout** +> +> The  following  use  cases  are  considered  for  Layout. +> +> · +> Home  Screen  developer  changes  the  Home  UI  by  using  a  customizable  layout  definition. +> +> Page  9  of  159 +> +> ![](media/picture101.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **3.1.2  System  UI  Parts** +> +> The  use  case  assumed  about  System  UI  Parts  is  as  follows. +> +> · +> An  application  or  System  uses  status  bar  and  on-screen  in  order  to  notify  information  to +> +> a  user. +> +> · +> User  uses  the  system  setting  UI  in  order  to  change  settings. +> +> · User  uses  software  keyboard  in  order  to  input  characters. +> +> **3.1.3  Application  Management** +> +> The  use  case  assumed  about  Application  Management  is  as  follows. +> +> · +> A  user  downloads  and  installs  or  updates  the  delivery  application  from  application  store. +> +> · A  user  uninstalls  the  delivery  application. +> +> · +> A  user  launches  the  installed  delivery  application  or  the  pre-installed  application. +> +> · Also  a  user  terminates  those  applications. +> +> **3.1.4  Application  Switch** +> +> The  use  case  assumed  about  Application  Switch  is  as  follows. +> +> · +> User  switches  application  via  application  history  or  application  stack. +> +> · +> The  system  switches  application  according  to  Driving  Mode  status. +> +> **3.1.5  Application  History** +> +> Application  switching  by  application  history  is  assumed  as  follows. +> +> · +> The  system  records  the  order  of  the  applications  in  the  order  in  which  the  application  is +> +> displayed. +> +> · +> The  order  of  application  that  is  recorded  is  updated  each  time  the  display  of  the +> +> application  is  switched. +> +> · +> Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the +> +> history  at  the  time  of  switching  applications. +> +> Page  10  of  159 +> +> ![](media/picture102.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> ‑  Specification  of  operation +> +> -  User  runs  a  swipe  from  the  edge  of  the  application  screen  area. +> +> ‑  Specification  of  action +> +> -  The  order  of  the  screen  is  managed  order  management  list  (application  history). +> +> -  List  order  update  opportunity(Update  has  determined  a  display  of  the  application) +> +> -  Application  starts  or  stops. +> +> -  Allowed  to  stand  between  the  screen  N  seconds  after  the  swipe. +> +> ‑"N  seconds"‑User  defines  the  value  of  any. +> +> -  User  to  operate  the  screen  after  you  swipe. +> +> ‑"operation"‑Screen  tap.  Menu  display.  Other. +> +> Figure  5‑2  represents  a  sample  Home  Screen  depicting  the  above  mentioned  use  cases. +> +> Page  11  of  159 +> +> ![](media/picture103.jpeg)![](media/picture104.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **3.1.6  Application  Stack** +> +> Application  switching  by  application  stack  is  assumed  as  follows. +> +> · +> The  user  specifies  the  type  of  any  order.  The  system  records  the  order  of  the  application +> +> to  the  rule  as  of  the  specified  type. +> +> · Examples  of  the  types  of  any  order +> +> · Application  start-up  order +> +> · +> Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the  stack +> +> Page  12  of  159 +> +> ![](media/picture105.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> when  switching  applications. +> +> ‑  Specification  of  operation +> +> · +> User  runs  a  swipe  from  the  edge  of  the  application  screen  area. +> +> ‑  Specification  of  action +> +> · +> The  order  of  the  screen  is  managed  order  management  list  (application  stack). +> +> · +> List  order  update  opportunity.(Application  start-up  order  as  an  example) +> +> · +> Application  that  started  at  the  end  of  the  list  when  the  application  is  started  is  added. +> +> · +> Application  that  has  stopped  from  the  list  when  the  application  is  stopped  will  be +> +> deleted. +> +> Figure  5-3  represents  the  switching  example  depicting  the  application  of  the  above  switching. +> +> Page  13  of  159 + + -------------------------------------------------------------------------------------- + > **No** > **Use  Case** > **Role** > **Description** + ---------- ----------------- --------------- ----------------------------------------- + > 1-1 > Layout > GUI  Layout > Function  to  define  a  customizable + > > + > definition > GUI  Layout  definition. + -------------------------------------------------------------------------------------- + +> ![](media/picture106.jpeg)![](media/picture107.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **3.1.7  Role  of  Home  Screen** +> +> Table  5-1  describes  the  role  of  the  Home  Screen  to  satisfy  the  purpose  and  use  cases +> +> Page  14  of  159 + + ---------------------------------------------------------------------------------------------------- + > 1-2 > Change  Layout > Function  to  apply  the  customized + > + > GUI  layout  definition. + ------- --------------------- ------------------------ --------------------------------------------- + > 2-1 > System  UI  Parts > Status  Bar > Function  to  display  the + > + > information  from  application  or + > + > system. + > + > Function  to  quickly  access  and  set + > + > certain  system  settings. + + > 2-2 > On-screen > Function  to  display  a  popup + > + > window  such  as  alert  messages. + + > 2-3 > System  Setting > Function  to  display  system + > + > settings  menu  regarding  GUI, + > + > such  as  locale  and  network. + + > 2-4 > Software > Function  to  display  software + > > + > Keyboard > keyboard. + + > 3-1 > Application > Application > Function  to  download + > > > + > Management > Management > applications  from  application + > + > store.  Function  to  install,  uninstall + > + > and  update  the  downloaded + > + > applications. + + > 3-2 > Application > Function  to  launch/terminate + > > + > Launcher > applications. + + > 4-1 > Application > Application  List > Function  to  switch  applications  by + > > + > Switch > installed  application  list. + + > 4-2 > Application  History > Function  which  switches + > + > application  in  order  by + > + > applications  history. + + > 4-3 > Application  Stack > Function  to  switch  application  in + > + > any  order. + ---------------------------------------------------------------------------------------------------- + +> ![](media/picture108.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **Table  5-2:  Relevance  of  the  Role  and  Purpose** +> +> Page  15  of  159 + + ----------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Rich  UX** > **Driver** > **Variations** + > > + > **Distraction** > **support** + > + > **mitigation** + ----------- --------------------------- ---------------- ------------------- ------------------ + > 1-1 > GUI  Layout  definition > ‑ > ‑ > ‑ + + > 1-2 > Change  Layout > ‑ > ‑ > ‑ + + > 2-1 > Status  Bar > ‑ > ‑ + + > 2-2 > On-screen > ‑ > ‑ + + > 2-3 > System  Setting > ‑ > ‑ + + > 2-4 > Software  Keyboard > ‑ > ‑ + + > 3-1 > Application  Management > ‑ > ‑ + + > 3-2 > Application  Launcher > ‑ > ‑ + + > 4-1 > Application  List > ‑ > ‑ + + > 4-2 > Application  History > ‑ > ‑ + + > 4-3 > Application  Stack > ‑ > ‑ + ----------------------------------------------------------------------------------------------- + +> ![](media/picture109.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **3.1.8  Requirements** +> +> **3.1.8.1  Layout** +> +> Home  Screen  must  provide  a  mechanism  for  customizable  GUI  layout  definition  by  each  vehicle +> +> type,  each  destination  and  each  grade. +> +> Home  Screen  must  provide  a  mechanism  for  a  customizable  GUI  layout  definition  for  different +> +> vehicle  type,  destination  and  grade. +> +> GUI  layout  definitioncan  be  definedsuch  as  the  following  items: +> +> (In  addition,  items  that  can  be  defined  is  not  limited  to  the  following.) +> +> · screen  resource  (Display,  Layer  Type,  Area) +> +> Page  16  of  159 +> +> ![](media/picture110.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · sound  resource  (Zone,  Sound  Type) +> +> · input  resource  (Device,  Event  Type) +> +> · UI  Component  to  be  used  in  the  entire  system +> +> · transition  effect  (Animation  effect) +> +> · Background  image +> +> Home  Screen  must  provide  a  mechanism  to  apply  customized  GUI  layout  definition. +> +> **3.1.8.2  System  UI  Parts** +> +> Home  Screen  must  provide  a  mechanism  to  display  two  or  more  information  simultaneously  to +> +> the  status  notification  area. +> +> Home  Screen  must  provide  a  mechanism  to  displaying  status  to  status  notification  area. +> +> · Current  Time:  Displaying  clock  capability +> +> · +> Icons  of  Status:  Displaying  icons  for  notify  information  from  applications +> +> · +> Status  Message:  Displaying  text  for  notify  information  from  applications +> +> · +> Communication  Status:  Status  of  mobile  communication  and  wireless  communications +> +> (Wi-Fi,  Bluetooth,  etc.) +> +> Home  screen  must  provide  an  interface  to  retrieve  information  from  application  for  notification. +> +> Home  Screen  must  provide  a  mechanism  to  show  popup  window  into  on-screen  window. +> +> Home  Screen  must  provide  GUI  method  to  hide  on-screen  window  by  user  operation. +> +> Home  Screen  must  provide  a  mechanism  to  hide  on-screen  window  within  a  specified  duration. +> +> Home  Screen  must  provide  an  interface  for  applications  to  request  to  show  popups. +> +> Home  Screen  must  provide  an  interface  for  applications  to  cancel  the  previously  requested +> +> popup. +> +> Page  17  of  159 +> +> ![](media/picture111.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Home  Screen  must  provide  a  mechanism  to  show  text  information,  draw  images  and  show +> +> software  switch  like  button  in  the  on-screen  window. +> +> Home  Screen  must  provide  a  mechanism  to  specify  attributes  such  as  position  and  size  of  On- +> +> screen  window. +> +> Home  Screen  must  support  a  mechanism  to  specify  other  window  display  effect  when  the  On- +> +> screen  window  is  displayed.  (e.g.  tone  down) +> +> Home  Screen  must  provide  system  setting  menu  regarding  GUI,  such  as  locale  and  network. +> +> Home  Screen  must  provide  a  mechanism  to  change  current  date  and  time  setting. +> +> Home  Screen  must  provide  a  mechanism  to  change  timezone  setting. +> +> · +> The  platform  must  set  up  the  date,  time  and  timezone  according  to  a  current  position +> +> automatically. +> +> · +> Home  Screen  must  provide  a  mechanism  to  set  up  turning  on  and  off  of  the  automatic +> +> date/time/timezone  setup. +> +> Home  Screen  must  provide  a  mechanism  to  change  language  setting. +> +> Home  Screen  must  provide  a  mechanism  to  change  wireless  communications  (Wi-Fi,  Bluetooth, +> +> etc.)  setting. +> +> · Enable/Disable +> +> · Connect/Disconnect +> +> · Search  the  devices +> +> · Display  the  list  of  available  and/or  registered  devices +> +> Home  Screen  must  provide  a  mechanism  to  change  mobile  communication  setting. +> +> · Enable/Disable +> +> Page  18  of  159 +> +> ![](media/picture112.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · A  setup  and  change  of  various  attributes +> +> · Display  the  list  of  registered  devices  and  select  device +> +> HomeScreen  must  support  to  change  the  appearance  of  a  screen  to  a  user's  liking. +> +> These  are  as  follows. +> +> · Tone  of  a  screen. +> +> · Appearance  of  a  window  frame. +> +> · Animation  effect  when  screen  transition  was  occurred. +> +> Home  Screen  must  support  a  mechanism  to  set  or  change  master  audio  volume. +> +> Home  Screen  must  support  a  mechanism  to  set  or  change  display  brightness. +> +> Home  Screen  must  provide  a  mechanism  to  show  software  keyboard. +> +> Home  Screen  must  provide  a  mechanism  to  apply  default  settings  (e.g.  theme,  local,  wallpaper) +> +> to  a  new  user,  when  a  user  is  added  by  the  User  Manager. +> +> **3.1.8.3  Application  Management** +> +> Home  Screen  must  provide  a  mechanism  to  manage  downloaded  application  package. +> +> · Display  downloaded  application  list  from  application  store. +> +> · Download  the  application +> +> · Install  the  downloaded  application +> +> · Uninstall  the  downloaded  application +> +> · Update  the  downloaded  application +> +> Home  Screen  must  provide  a  mechanism  to  launch  the  application. +> +> Home  Screen  must  provide  a  mechanism  to  terminate  the  application. +> +> Page  19  of  159 +> +> ![](media/picture113.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **3.1.8.4  Application  Switch** +> +> Home  Screen  must  provide  a  mechanism  to  show  the  list  of  installed  applications. +> +> Examples  of  assumed  application  list +> +> · list  of  application  name +> +> · list  of  application’s  icon +> +> · list  of  live  thumbnail  for  all  the  running  applications +> +> Home  Screen  must  provide  a  mechanism  for  switching  display  application  in  order  by  application +> +> history. +> +> Home  Screen  must  provide  a  mechanism  for  the  application  stack  in  any  order.  For  example, +> +> such  as  launch  order  or  display  order. +> +> Home  Screen  must  provide  a  mechanism  for  the  system  to  switch  applications. +> +> For  example,  when  Driving  Mode  changes,  system  must  be  able  to  switch  application  based  on +> +> policy. +> +> **4   Application   Framework   Layer** +> +> The  Application  Framework  layer  provides  the  methods  needed  to  create  software  applications +> +> and  their  user  interfaces.  The  platform  can  support  multiple  application  frameworks  any  of +> +> which  may  be  built  into  an  SDK  or  product  build.  The  application  framework  contains  any  code +> +> specifically  written  for  that  framework  as  well  the  bindings  to  the  Services  and  Operating +> +> Systems  layers  that  the  application  framework  provides  for  its  applications. +> +> 4.1  AGL  Application  Framework +> +> The  AGL  Application  Framework  provides  basic  services  to  all  applications  regardless  of  the +> +> framework  they  are  implemented  in  so  that  there  is  a  standard  method  providing  the  services. +> +> Page  20  of  159 +> +> ![](media/picture114.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **4.1.1  Application  Manager** +> +> Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application +> +> lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. +> +> **4.1.1.1  Requirements** +> +> AGL  System  must  support  application  lifecycle  (install/uninstall,  launch/kill,  suspend/resume)  based  on +> +> appid/pid  via  launcher. +> +> AGL  System  must  support  a  database  to  store  application  metadata  (appid,  exec  path  etc.). +> +> AGL  System  must  provide  an  interface  to  get  a  list  of  installed  applications. +> +> AGL  System  must  provide  an  interface  to  get  the  state  of  an  application. +> +> AGL  System  must  provide  application  privilege  control. +> +> **4.1.2  Window  Manager** +> +> A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user  interface.  A +> +> window  system  is  responsible  for  managing  display  devices,  Graphics  Processing  Units  (GPUs),  input +> +> devices,  and  graphics  memory.  A  window  system  works  with  the  software  component  named  window +> +> manager  that  is  responsible  for  a  layout  management  of  windows,  and  a  routing  of  user  interactions. +> +> A  window  manager  is  as  software  component  that  is  responsible  for  a  layout  management  of +> +> windows. +> +> Window  manager  of  automotive  middleware  layer  makes  up  for  traditional  window  management +> +> system  to  be  satisfied  IVI’s  complex  requirements,  typically  requested  from  Policy  Manager. +> +> Also,  AGL  aims  to  provide  well-portability  among  various  hardware  platforms. +> +> Page  21  of  159 + + -------------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- ----------------------------- -------------------------------------------------------------- + > 1 > Window  drawing > Provide  capability  to  draw  a  window  to  any  place + > + > and  any  size  and  any  scale. + > + > Also  provide  capability  to  change  visibility  of  the + > + > window. + + > 2 > Overlay  of  multiple > Provide  capability  to  overlay  two  or  more  windows + > > + > windows > with  any  z-order. + > + > Also  provide  capability  to  use  hardware  layer + > + > efficiently. + + > 3 > Visual  effect > Provide  capability  to  adapt  visual  effect  as  below. + > + > ·     Animation  effect  to  change  visibility + > + > ·     Animation  effect  to  transit  between  two  or + > + > more  windows + > + > ·     Visual  effect  for  a  window,  such  as  gray-out + > + > and  transparent. + + > 4 > Frame  rate  control > Provide  capability  to  control  dynamic  frame  rate + > + > change.  This  is  useful  if  system  resource  was + > + > shortage. + + > 5 > Multiple  hardware  layer > Provide  capability  to  use  hardware  layer  efficiently + > > + > support > if  hardware  supports  two  or  more  hardware  layers. + -------------------------------------------------------------------------------------------------------- + +> ![](media/picture115.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **4.1.2.1  Use** **Case** +> +> Please  refer  “screen  resource  control”  of  Policy  Manger  section. +> +> **4.1.2.2  Role** +> +> Table  7-148  describes  the  role  of  window  manager  to  be  satisfied  above  purpose  and  use +> +> cases. +> +> Page  22  of  159 + + ---------------------------------------------------------------------------------------------- + > 6 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce + > > + > hardware > dependency  of  hardware.  Well-defined  interface + > + > also  makes  it  possible  to  increase  the  effect  of + > + > portability  and  development  cost. + ----- --------------------------- ------------------------------------------------------------ + > 7 > Multi  window  /  multi > Support  multi  window  management  and  multi + > > + > display > display. + + > 8 > Compatibility > From  the  compatibility  point  of  view,  AGL  should + > + > use  public  API,  and  shall  not  rely  on  hardware + > + > specific  API. + ---------------------------------------------------------------------------------------------- + +> ![](media/picture116.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **4.1.2.3  Requirements** +> +> 4.1.2.3.1  Window  Drawing +> +> System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and +> +> make  invisible. +> +> System  must  provide  a  mechanism  to  create  and  delete  surface. +> +> When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. +> +> This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. +> +> System  must  provide  a  mechanism  to  change  visibility  per  each  surface. +> +> And,  provide  an  interface  to  change  visibility. +> +> All  the  surfaces  must  be  set  to  invisible  for  initial  state. +> +> Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. +> +> System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between +> +> previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. +> +> *System must provide a mechanism to fit surface into area. Because, size of area may differe*nt +> +> Page  23  of  159 +> +> ![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> from  size  of  surface. +> +> If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. +> +> If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +> +> into  area  by  squeeze. +> +> If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +> +> into  area  by  using  combination  of  scaling  and  trimming  function. +> +> That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +> +> ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. +> +> If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +> +> into  area  by  using  combination  of  scaling  and  background  color. +> +> That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +> +> ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This +> +> mechanism  makes  it  possible  to  do  “letterbox”  method. +> +> 4.1.2.3.2  Overlay  of  Multiple  Windows +> +> System  must  provide  a  mechanism  to  create  and  delete  a  layer. +> +> Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by +> +> their  z-order  attribute. +> +> Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, +> +> then,  attached  layer  must  be  changed. +> +> System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. +> +> Area  is  a  concept  which  defines  where  to  display  in  specific  layer. +> +> System  must  provide  a  mechanism  to  attach  surface  to  any  layer. +> +> Also,  system  must  be  able  to  change  attached  layer. +> +> And,  provide  an  interface  to  attach  and  change. +> +> Page  24  of  159 +> +> ![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. +> +> And,  provide  an  interface  to  assign  surface  to  any  area. +> +> System  must  provide  a  mechanism  to  change  visibility  per  each  layer. +> +> That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the +> +> same  time. +> +> And,  provide  an  interface  to  change  visibility  per  layer. +> +> Initial  state  must  be  set  to  invisible. +> +> System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each +> +> layer,  and  disposition  of  surfaces. +> +> 4.1.2.3.3  Visual  Affect +> +> System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was +> +> happened. +> +> Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +> +> - Duration +> +> Animation  type +> +> System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +> +> out. +> +> Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +> +> plug-in  architecture. +> +> System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. +> +> Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +> +> · Duration +> +> Animation  type +> +> System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +> +> Page  25  of  159 +> +> ![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> out. +> +> Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +> +> plug-in  architecture. +> +> System  must  provide  a  mechanism  to  make  effect  to  surface. +> +> And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. +> +> System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. +> +> System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness +> +> System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in +> +> architecture. +> +> 4.1.2.3.4  Frame  Rate  Control +> +> System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of +> +> application. +> +> System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval +> +> of  application. +> +> This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live +> +> thumbnail  and  moving  surface. +> +> 4.1.2.3.5  Multiple  Hardware  Layer  Support +> +> If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use +> +> hardware  layers  efficiently. +> +> · +> Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers +> +> Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback +> +> 4.1.2.3.6  Reduced  Dependency  of  Hardware +> +> Page  26  of  159 +> +> ![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of +> +> each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, +> +> such  as  by  using  re-configuration. +> +> 4.1.2.3.7  Multi  Window +> +> AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple +> +> processes  on  a  display. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. +> +> 4.1.2.3.8  Compatibility +> +> AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +> +> APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +> +> AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a +> +> standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any +> +> hardware  specific  API. +> +> A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. +> +> **4.1.3  Policy  Manager** +> +> **4.1.3.1  Overview** +> +> 4.1.3.1.1  Purpose +> +> Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy +> +> Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle +> +> Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of +> +> resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called +> +> Page  27  of  159 +> +> ![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> “System  resources”  such  as  CPU  and  memory. +> +> 4.1.3.1.2  GUI  Resources +> +> (1)  Definition +> +> ·  About  Control  of  GUI  Resources +> +> AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, +> +> speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user +> +> or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. +> +> **Figure  7-1:  GUI  resources** +> +> Page  28  of  159 +> +> ![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy +> +> Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too +> +> much  information  distracts  the  attention  of  driver  from  driving  operations. +> +> ·  Associated  Software  Architecture +> +> The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources +> +> control  is  as  below. +> +> **Figure  7-2:  Associated  Software  Expected  Use  Case** +> +> Page  29  of  159 + + ----------------------------------------------------------------------------------------------------------------------------------------------------- + > **No** > **Component** > **Description** + > + > **.** + ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- + > 1 > Homescreen > Request  to  control  of  GUI  resources. + + > 2 > Applications > Request  to  output  or  input  of  GUI  resources. + + > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And + > + > then  provide  the  corresponding  feature  to + > + > applications  UI  such  as  input  limitation  and + > + > changing  the  theme. + + > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the + > + > definition  of  GUI  resources  such  as  role  by + > + > application  configurations. + + > 5- > Vehicle > Window  Manager + > > + > 1 > Info + > + > Control + + > 5- > Sound  Manager + > + > 2 + + > 5- > Input  Manager + > + > 3 + + > 5- > Vehicle  Info  Distributor + > + > 4 + + > 5- > User  Manager + > + > 5 + ----------------------------------------------------------------------------------------------------------------------------------------------------- + +> ![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Policy  Manager  is  related  with  the  below  components. +> +> (2)  Role +> +> Page  30  of  159 + + ----------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ------------------------------ ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of + > > + > GUI  resource > GUI  resources. + > + > (2)  Judgment  the  GUI  resource  owner  according  to + > + > external  conditions. + + > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to + > + > judgment. + > + > (2)  Notify  the  driving  mode  and  day  night  mode + > + > that  is  calculated  by  external  conditions. + ----------------------------------------------------------------------------------------------------- + +> ![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Policy  Manager  has  the  below  role. +> +> Page  31  of  159 +> +> ![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **Figure  7-3:  Definition  of  Role** +> +> GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each +> +> resource  type  are  as  follows: +> +> a.  Screen  Resource +> +> a-1.  External  Condition  Collection +> +> Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. +> +> **Figure  7-4:  Definition  of  screen  resource** +> +> •  Concept  of  Display,  Layer,  Layout  and  Area +> +> AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one +> +> or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout +> +> Page  32  of  159 +> +> ![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics +> +> window. +> +> The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on +> +> objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was +> +> used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than +> +> layer-2. +> +> Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, +> +> application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. +> +> “Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and +> +> setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert +> +> and  enlarged  view. +> +> When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On +> +> the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” +> +> layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. +> +> From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- +> +> order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered +> +> by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to +> +> individual  layer. +> +> •  Concept  of  Layer  Owner,  Role  and  Surface +> +> “Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of +> +> that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of +> +> area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy +> +> Manager. +> +> “Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” +> +> change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. +> +> One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics +> +> window  to  display  into  one  area. +> +> Page  33  of  159 +> +> ![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface +> +> drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example +> +> to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then +> +> corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface +> +> is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & +> +> scan”. +> +> **Figure  7-5:  Definition  of  Surface** +> +> •  Subdivision  of  “Interrupt”  Layer +> +> Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main +> +> surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main +> +> surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding +> +> “Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message +> +> is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. +> +> According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described +> +> as  Table  7-3. +> +> Page  34  of  159 + + --------------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- -------------------------------------------------------- ----------------------- + > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation + > + > application  requests  this  layer  at  first  time. + + > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of + > + > navigation + + > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message + > > + > screen  service  (e.g.  Homescreen)  requests > popup + > + > this  layer. + + > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard + > > + > keyboard > Typically,  software  keyboard  service + > + > requests  this  layer. + --------------------------------------------------------------------------------------------------------- + + ------------------------------------------------------------------------------------------------------ + > **No** > **Contents** > **Summary** > **Example** + ---------- ---------------- ------------------------------------------------------- ------------------ + > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation + > + > service)  role. + + > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view + ------------------------------------------------------------------------------------------------------ + +> ![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> a-2.  Judgment  of  Priority  of  GUI  Resource +> +> Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role +> +> is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy +> +> Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. +> +> Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software +> +> Page  35  of  159 +> +> ![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is +> +> popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). +> +> **Figure  7-6:  Definition  of  Role  and  Sub  role** +> +> The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display +> +> has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. +> +> In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" +> +> layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub +> +> role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” +> +> role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. +> +> a-3.  GUI  resource  control +> +> Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only +> +> issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +> +> directly. +> +> Page  36  of  159 +> +> ![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> There  are  three  types  of  screen  resource  control: +> +> One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. +> +> Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was +> +> assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. +> +> Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue +> +> z-order  information  for  each  layer. +> +> b.  Sound  Resource +> +> b-1.  External  Condition  Collection +> +> Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. +> +> **Figure  7-7:  Definition  of  Sound  Resource** +> +> •  Zone +> +> Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can +> +> play  at  the  same  time. +> +> Page  37  of  159 + + ------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- ---------------------------------------------- ------------------------- + > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media + > + > player + + > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of + > + > Navigation + + > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound + > + > requests  this  type. + ------------------------------------------------------------------------------------------------- + +> ![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> •  Sound  type +> +> Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource +> +> owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper +> +> sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific +> +> zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each +> +> sound  stream  must  assign  to  individual  sound  type. +> +> AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. +> +> •  Stream +> +> Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in +> +> stream. +> +> b-2.  Judgment  of  Priority  of  GUI  resource +> +> Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role +> +> is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy +> +> Manager.  Figure  7-8  describes  the  definition  of  role. +> +> Page  38  of  159 +> +> ![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **Figure  7-8:  Sample  Role** +> +> The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that +> +> is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or +> +> different  sound  type  are  not  switched.  They  are  mixed. +> +> b-3.  GUI  Resource  Control +> +> Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only +> +> issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +> +> directly. +> +> There  are  two  types  of  sound  resource  control: +> +> One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for +> +> sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound +> +> Page  39  of  159 +> +> ![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> stream  and  to  start  play  latest  area  owner. +> +> Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback +> +> simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy +> +> Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and +> +> music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music +> +> playback. +> +> c.  Input  Resource +> +> c-1.  External  Condition  Collection +> +> Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. +> +> **Figure  7-9:  Definition  of  Input  Resource** +> +> •  Device  Name +> +> Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. +> +> •  Event  Type +> +> Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and +> +> temperatures. +> +> c-2.  Judgment  of  Priority  of  GUI  resource +> +> Page  40  of  159 +> +> ![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device +> +> name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy +> +> DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the +> +> judgment  as  below. +> +> **Figure  7-10:  Definition  of  routing  rule** +> +> OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. +> +> c-3.  GUI  Resource  Control +> +> Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only +> +> issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. +> +> Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. +> +> 4.1.3.1.3  System  Resources +> +> (1)  Definition +> +> Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy +> +> Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. +> +> Page  41  of  159 + + ---------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ----------------------------- ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according + > + > to  external  condition  change. + > + > 2.  Kill  process(s)  forcibly  according  to  external + > + > condition  change. + ---------------------------------------------------------------------------------------------------- + +> ![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, +> +> target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. +> +> **4.1.3.2  Requirements** +> +> 4.1.3.2.1  Screen  Resource +> +> (1)  External  Condition  Collection +> +> System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +> +> owner. +> +> System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system +> +> uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive +> +> information  must  include  as  follows. +> +> a.  ID +> +> b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) +> +> c.  DPI +> +> d.  Connected  ECU +> +> Page  42  of  159 +> +> ![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be +> +> able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list +> +> according  to  current  layout  of  each  display. +> +> The  receive  definition  must  include  the  follows. +> +> a.  ID +> +> b.  Area  list +> +> System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface +> +> by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the +> +> device. +> +> The  receive  request  must  include  the  follows. +> +> a.  Layout  ID +> +> b.  ID +> +> c.  Area  position  (Coordinate  of  the  upper-left) +> +> d.  Area  size  (Length  \*  Width) +> +> System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify +> +> the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. +> +> a.  Display  ID +> +> b.  Layout  ID +> +> System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the +> +> providing  resource  using  it  when  the  request  is  collision. +> +> The  receive  information  must  include  the  follows. +> +> a.  Role +> +> b.  Priority +> +> System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge +> +> driving  mode. +> +> The  receive  information  must  include  the  follows. +> +> a.  Velocity +> +> Page  43  of  159 +> +> ![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> b.  Brake  status +> +> System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge +> +> day  night  mode. +> +> The  receive  information  should  include  the  follows. +> +> a.  The  brightness  of  the  interior +> +> System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the +> +> providing  resource  using  it. +> +> System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should +> +> judge  the  providing  resource  using  it. +> +> (2)  Judgment  of  Priority  of  GUI  Resource +> +> System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +> +> according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +> +> System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical +> +> resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the +> +> resource. +> +> The  receive  request  must  include  as  follows. +> +> a.  Role +> +> b.  Layer  type +> +> The  receive  request  should  include  as  follows. +> +> c.  Display  ID +> +> System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by +> +> priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on +> +> the  specified  area  on  the  specified  layer. +> +> The  receive  request  must  include  as  follows. +> +> a.  Role +> +> Page  44  of  159 +> +> ![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> b.  Layer  ID +> +> The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. +> +> Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the +> +> related  basic  type  area. +> +> c.  Area  ID +> +> **Figure  7-11:  Sequence  to  display** +> +> System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. +> +> In  this  request,  requester  should  choose  below  options. +> +> a. +> Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, +> +> but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should +> +> be  refused. +> +> b. +> Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen +> +> resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher +> +> priority,  then,  only  screen  resource  should  be  assigned  to  requester. +> +> Page  45  of  159 +> +> ![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +> +> release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system +> +> running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. +> +> The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal +> +> request. +> +> a.  Effective  period  (Can  set  unlimited) +> +> System  should  not  raise  the  other  surface  above  its  during  effective  period. +> +> System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +> +> a.  The  effect  at  the  transition +> +> b.  The  effect  of  display  surface +> +> System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are +> +> sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all +> +> layers  will  be  superimposed  by  z-order. +> +> System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. +> +> System  must  hide  the  surface  that  has  too  much  information. +> +> (3)  GUI  Resource  Control +> +> System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +> +> System  must  provide  a  mechanism  to  issue  the  following  resource  control. +> +> a.  Visible  /  Invisible +> +> b.  Change  position +> +> c.  Raise +> +> The  receive  request  must  include  as  follows. +> +> i.  Surface  ID  \*Only  case  of  visible. +> +> ii.  Display  ID  \*Only  case  of  visible. +> +> iii.  Layer  ID  \*Only  case  of  visible. +> +> Page  46  of  159 +> +> ![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. +> +> v.  Size  (Length  \*  Width)  \*Only  case  of  visible. +> +> System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. +> +> a.  The  effect  at  the  transition +> +> b.  The  effect  of  display  surface +> +> 4.1.3.2.2  Sound  Resource +> +> (1)  External  Condition  Collection +> +> System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +> +> owner. +> +> System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone +> +> information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as +> +> follows. +> +> a.  ID +> +> b.  Sound  device  ID +> +> System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses +> +> sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must +> +> include  as  follows. +> +> a.  ID +> +> (2)  Judgment  of  Priority  of  GUI  resource +> +> System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +> +> according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +> +> System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +> +> request  during  system  running. +> +> Page  47  of  159 +> +> ![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> The  receive  request  must  include  as  follows. +> +> a.  Role +> +> b.  Zone  ID +> +> c.  Sound  type  ID +> +> System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +> +> release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during +> +> system  running. +> +> The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal +> +> request. +> +> a.  Effective  period  (Can  set  unlimited) +> +> System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner +> +> by  other  request  on  same  area  during  effective  period. +> +> System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +> +> a.  The  effect  at  the  transition +> +> b.  The  effect  of  output  sound +> +> System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more +> +> resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority +> +> of  resources  that  is  related  to  role. +> +> \*  Boundary  of  the  role  between  Policy  Manager  and  application. +> +> Page  48  of  159 +> +> ![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Figure  7-12:  Boundary  of  role  (Case  of  reverse) +> +> System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system +> +> should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. +> +> For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound +> +> from  request  history  based  on  the  priority. +> +> (3)  GUI  Resource  Control +> +> System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +> +> System  must  provide  a  mechanism  to  issue  the  following  resource  control. +> +> a.  Mute  /  Unmute +> +> b.  Change  zone +> +> The  receive  request  must  include  as  follows. +> +> i.  Stream  ID +> +> ii.  Device +> +> In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. +> +> iii.  Channel  ID +> +> Page  49  of  159 +> +> ![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. +> +> a.  The  effect  at  the  transition +> +> b.  The  effect  of  output  sound +> +> 4.1.3.2.3  Input  Resource +> +> (1)  External  Condition  Collection +> +> System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +> +> owner. +> +> System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses +> +> input  device  information  with  to  control  input  event  to  other  system.  The  receive  information +> +> must  include  as  follows. +> +> a.  ID +> +> System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses +> +> input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must +> +> include  as  follows. +> +> a.  ID +> +> b.  Related  event  IDs +> +> (2)  Judgment  of  Priority  of  GUI  resource +> +> System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +> +> according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +> +> System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +> +> request  during  system  running. +> +> The  receive  request  must  include  as  follows. +> +> a.  Input  device  ID +> +> Page  50  of  159 +> +> ![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> b.  Event  type  ID +> +> System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the +> +> limitation  routing  rule  of  policy  DB. +> +> (3)  GUI  Resource  Control +> +> System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +> +> System  must  provide  a  mechanism  to  issue  the  following  resource  control. +> +> a.  Set  the  routing  rule +> +> The  receive  request  must  include  as  follows. +> +> i.  Input  device  ID +> +> ii.  Event  type  ID +> +> The  receive  request  must  include  either  as  follows. +> +> iii.  The  allowed  application +> +> iv.  The  denied  application +> +> System  should  provide  a  mechanism  to  set  the  following  information. +> +> a.  Application  that  has  active  surface +> +> System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This +> +> feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen +> +> changes  the  active  surface. +> +> 4.1.3.2.4  System  Resources +> +> (1)  External  Condition  Collection +> +> System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager +> +> to  decide  proper  system  resource. +> +> Page  51  of  159 +> +> ![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Policy  Manager  must  detect  creation  and  deletion  of  process. +> +> To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created +> +> process. +> +> Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to +> +> other  active  processes. +> +> To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to +> +> identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each +> +> active  process. +> +> Policy  Manager  must  detect  current  memory  consumption  periodically. +> +> To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each +> +> process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were +> +> thought  as  not  so  important  process. +> +> Policy  Manager  must  detect  current  CPU  consumption  periodically. +> +> To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep +> +> system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected +> +> busy  state. +> +> System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. +> +> Application  status  includes  as  below. +> +> · GUI  resource  status,  such  as  foreground  or  background. +> +> · +> Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must +> +> resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last +> +> application  to  resume  quickly  as  much  as  possible. +> +> (2)  System  Resource  Control +> +> System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process +> +> group  according  to  external  conditions. +> +> According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to +> +> target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups +> +> Page  52  of  159 +> +> ![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> will  be  used) +> +> System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. +> +> 4.1.3.2.5  Resource  Management +> +> Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy +> +> Manager,  Connection  Manager. +> +> Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. +> +> Each  resource  request  shall  be  in  form  a: +> +> AppID, +> +> SourceID, +> +> RequestorZoneID, +> +> NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), +> +> Required  Resource  List. +> +> Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin +> +> Speakers,  HeadPhones) +> +> Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) +> +> Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, +> +> Tuners  etc.) +> +> Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request +> +> from  resource  requestors. +> +> Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. +> +> Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) +> +> Page  53  of  159 +> +> ![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list +> +> are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) +> +> Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system +> +> through  status  update. +> +> Resource  Management  shall  support  stacking/queuing  of  resource  requests. +> +> >  Receive  the  requests  from  the  resource  requestors. +> +> >  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy +> +> Manager. +> +> >  Add  the  validated  requests  into  a  priority  queue. +> +> >  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. +> +> >  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it +> +> shall  be  removed  from  the  queue. +> +> Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier +> +> request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it +> +> shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. +> +> If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the +> +> requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. +> +> If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant +> +> some/all  of  the  resources  requested  by  the  requestor. +> +> Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an +> +> existing  resource  request. +> +> Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of +> +> policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs +> +> for  the  policy  decision: +> +> >  Currently  Free  or  InUse  Sink  status +> +> >  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) +> +> Page  54  of  159 +> +> ![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> >  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. +> +> Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a +> +> request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the +> +> policy  decision: +> +> >  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept +> +> pending. +> +> >  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. +> +> At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by +> +> resource  requestor: +> +> >  Zone  ID +> +> >  Allocated  Source  Instance +> +> >  Allocated  Sink  Instance +> +> >  Mute  status +> +> Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality +> +> (e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to +> +> the  resource  management  policy. +> +> Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature +> +> functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). +> +> Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: +> +> AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have +> +> same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, +> +> the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. +> +> Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, +> +> AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource +> +> request  will  be  the  one  that  is  granted  the  resource. +> +> A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. +> +> It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. +> +> Page  55  of  159 +> +> ![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. +> +> It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource +> +> Manager  if  the  resource  is  no  longer  needed. +> +> Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all +> +> available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once +> +> the  request  is  granted  against  the  set  policy. +> +> Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. +> +> Possible  connection  states  are  Active  or  Passive. +> +> >  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be +> +> active. +> +> Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. +> +> >  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be +> +> passive. +> +> Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same +> +> AMFM  source  on  Rear  headphone  sink. +> +> Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink +> +> connection  using  the  underlying  platform  support. +> +> Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink +> +> connection  using  the  underlying  platform  support. +> +> Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is +> +> removed/released. +> +> Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is +> +> re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. +> +> Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. +> +> Page  56  of  159 +> +> ![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready +> +> to  be  used  for  audio  routing. +> +> Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio +> +> routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. +> +> Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. +> +> Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which +> +> source  instance. +> +> Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: +> +> >  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. +> +> System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +> +> are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +> +> 1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +> +> The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +> +> Headphones  shall  not  be  required  to  support  any  foreground  sinks. +> +> In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a +> +> source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source +> +> (if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). +> +> As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not +> +> disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background +> +> connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. +> +> It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +> +> It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. +> +> Page  57  of  159 +> +> ![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State +> +> Manager. +> +> It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. +> +> It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +> +> It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +> +> It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +> +> It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on +> +> current  system  scenario. +> +> E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call +> +> is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a +> +> pending  request. +> +> It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. +> +> It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. +> +> It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video +> +> resources  and  update  its  internal  status  accordingly. +> +> On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active +> +> connections  and  reconnect  or  disconnect  if  required. +> +> E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. +> +> Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of +> +> connections  shall  be  rebuilt  with  Amp. +> +> It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. +> +> Page  58  of  159 +> +> ![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying +> +> platform  support. +> +> It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the +> +> underlying  platform  support. +> +> It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. +> +> It  shall  provide  an  interface  to  unmute  an  audio  sink. +> +> System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +> +> are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +> +> 1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +> +> The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +> +> It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +> +> Headphones  shall  not  be  required  to  support  any  foreground  sinks. +> +> It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +> +> It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +> +> It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +> +> **4.1.4  Sound  Manager** +> +> A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from +> +> two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a +> +> policy  manager  manages  a  mediation  rule. +> +> Page  59  of  159 + + ---------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ------------------------------------------------------------ + > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). + + > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume + > + > control  of  each  sound  streams. + + > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, + > + > ·     When  changing  sound  stream.  E.g.  fade-in, + > + > fade-out  and  cross-fade. + + > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce + > > + > hardware > dependency  of  hardware.  Well-defined  interface + > + > also  makes  it  possible  to  increase  the  effect  of + > + > portability  and  development  cost. + ---------------------------------------------------------------------------------------------------- + +> ![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a +> +> passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound +> +> resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. +> +> Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like +> +> volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server +> +> to  implement  automatic  audio  policies. +> +> **4.1.4.1  Use  Case** +> +> Please  refer  “sound  resource  control”  of  Policy  Manger  section. +> +> Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. +> +> **4.1.4.2  Requirements** +> +> Page  60  of  159 +> +> ![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 4.1.4.2.1  Routing  Sound  Streams +> +> System  must  provide  a  mechanism  to  manage  sound  “zone”. +> +> Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a +> +> zone  and  how  to  manage  zone. +> +> System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each +> +> channels  of  each  sound  device. +> +> One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists +> +> of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. +> +> For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is +> +> arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when +> +> outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower +> +> musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than +> +> music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound +> +> device. +> +> The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more +> +> zones. +> +> Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the +> +> present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the +> +> mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. +> +> System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. +> +> System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. +> +> All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. +> +> System  must  provide  a  mechanism  to  control  sound  stream. +> +> Control  of  a  sound  stream  is  as  follows. +> +> · +> Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound +> +> stream. +> +> · +> Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound +> +> Page  61  of  159 +> +> ![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> stream. +> +> Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. +> +> 4.1.4.2.2  Mixing  Level  Control +> +> The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to +> +> the  same  zone  according  to  a  policy  manager's  arbitration. +> +> System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. +> +> System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream +> +> requested  to  play  into  same  sound  zone. +> +> In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating +> +> the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. +> +> System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested +> +> to  play  into  same  sound  zone. +> +> In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted +> +> sound  stream  was  ended. +> +> System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream +> +> requested  to  play  into  same  sound  zone. +> +> In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound +> +> stream  was  ended. +> +> 4.1.4.2.3  Sound  Effect +> +> When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. +> +> System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. +> +> System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin +> +> architecture. +> +> Page  62  of  159 + + ------------------------------------------------------------------------------------------------------------------------- + > **No.** > **Input  type** > **Associated  device** > **Description** + ----------- ------------------- -------------------------- -------------------------------------------------------------- + > 1 > Key > Steering  switch > Simple  key  event. + > + > Deliver  to  application. + + > 2 > Keyboard > Virtual  keyboard > Keyboard  event. + > + > Deliver     to     application,     then     use     input + > + > method  backend  if  needed. + + > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. + > + > Also  supports  double  click  and  multi-touch + > + > capability. + > + > Deliver  to  application. + + > 4 > Sound > Microphone > Sound  input. + ------------------------------------------------------------------------------------------------------------------------- + +> ![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 4.1.4.2.4  Reduced  Dependency  of  Hardware +> +> Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels +> +> of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means +> +> which  does  not  need  rebuild  of  systems,  such  as  a  configuration. +> +> **4.1.5  Input  Manager** +> +> The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application +> +> depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each +> +> input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering +> +> switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. +> +> **4.1.5.1  Use  Case** +> +> Please  refer  “input  resource  control”  of  Policy  Manger  section. + + --------------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ----------------------------------------------------------------- + > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to + > + > application  readable  event  name,  such  as  “volume + > + > up”  and  “right  arrow”. + + > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified + > + > application. + --------------------------------------------------------------------------------------------------------- + +> ![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Deliver  to  application  or  voice  recognition +> +> engine. +> +> Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. +> +> **4.1.5.2  Requirements** +> +> **4.1.5.3  Abstract  Device  Event** +> +> System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. +> +> Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional +> +> equipment. +> +> **4.1.5.4  Event  Delivery** +> +> System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. +> +> System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” +> +> and  “destination  application  id”. +> +> Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by +> +> UIM.2.1.2. +> +> Page  64  of  159 +> +> ![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. +> +> System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. +> +> System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on +> +> delivery  rule  defined  in  UIM.2.1.1. +> +> System  must  provide  a  mechanism  to  inhibit  any  event  delivery. +> +> This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. +> +> **4.1.6  User  Manager** +> +> **4.1.6.1  Use  Case** +> +> **4.1.6.2  Personal  Identification** +> +> User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a +> +> person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. +> +> **4.1.6.3  User  Preference** +> +> Multi-user  environment  provides  same  user  experience  for  each  user. +> +> Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including +> +> other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data +> +> sharing  from  your  home  and  your  office. +> +> Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be +> +> provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. +> +> Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user +> +> experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, +> +> *but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is +> +> Page  65  of  159 +> +> ![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. +> +> **Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** +> +> **4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** +> +> When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If +> +> Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is +> +> important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s +> +> preference. +> +> **Figure  7-25  :  User  data  sharing  between  cars** +> +> Page  66  of  159 +> +> ![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **4.1.6.5  Seamless  Data  Sharing** +> +> Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and +> +> smart-phones,  home  networks  and  accessing  from  your  offices. +> +> **Figure  7-26  :  User  data  sharing  over  the  cars** +> +> **4.1.6.6  Role** +> +> **Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above +> +> purpose  and  use  cases. +> +> **Table  7-17  :  Role  of  User  Manager** +> +> **No.** **Role** **Description** +> +> Page  67  of  159 +> +> ![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 1 User  identification +> Provide  a  mechanism  to  identify  user,  such  as  user +> +> name  and  password  pair,  smart  key  and  biometrics. +> +> Provide  a  mechanism  to  log-in  to  the  IVI  system  as +> +> a  specified  user. +> +> When a different user logs in, proper user +> +> preference  for  the  user  must  be  applied,  and +> +> resume  last  state  of  corresponding  user. +> +> Also,  each  application  can  store  application’s  data +> +> per  user.  In  such  cases,  proper  user  data  must  be +> +> applied  when  a  different  user  logs  in. +> +> 2 User  preference +> Provide  a  mechanism  to  apply  user  preference  of +> +> logged-in  user. +> +> User  preference  includes  the  following  data. +> +> · User  interface,  such  as  locale  and  wall- +> +> paper. +> +> · Resume  last  application’s  status  of  specified +> +> user. +> +> · Application  specific  data. +> +> 3 User  data  management +> Provide  a  mechanism  to  manage  cloud  based  user +> +> data. +> +> The  following  capabilities  are  required. +> +> · Download  user  data  of  the  logged-in  user +> +> from  the  cloud. +> +> · Update  cloud  data  if  the  user  data  was +> +> updated  by  user  operation  or  otherwise. +> +> · Periodically  sync-up  w/  cloud  because  user +> +> data  may  be  updated  by  other  devices. +> +> In  addition  to  the  above  basic  capabilities,  user  data +> +> cache  is  essential  for  a  car,  since  a  car  may  not +> +> always  have  a  reliable  network  connection. +> +> 4 Security Because  cloud  based  sharing  user  data  may  be +> +> accessed  from  any  place,  user  data  must  be +> +> protected  from  unexpected  data  access. +> +> Page  68  of  159 +> +> ![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> So,  IVI  system  must  provide  security  mechanism +> +> regarding  accessing  to  cloud  based  user  data. +> +> **4.1.6.7  Requirements** +> +> 4.1.6.7.1  User  Identification +> +> System  must  provide  a  mechanism  to  identify  logged-in  user. +> +> System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to +> +> identify  logged-in  user. +> +> System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For +> +> example,  using  NFC. +> +> System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. +> +> 4.1.6.7.2  User  Preference +> +> When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the +> +> currently  logged-in  user. +> +> System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. +> +> - Locale  settings +> +> - UX  theme +> +> Wall  paper +> +> System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized +> +> user  experience. +> +> Page  69  of  159 +> +> ![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in +> +> user’s  application  data  automatically. +> +> When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last +> +> status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the +> +> system.  Specifically,  last  status  includes  the  following. +> +> - Foreground  applications.  That  means  displayed  applications. +> +> Background  applications. +> +> When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. +> +> System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. +> +> System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. +> +> 4.1.6.7.3  User  Data  Management +> +> System  must  provide  a  mechanism  to  manage  user  data. +> +> AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user +> +> preference. +> +> User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but +> +> also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and +> +> home  electronics. +> +> System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to +> +> application  by  using  cloud  based  user  data. +> +> System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data +> +> of  the  IVI  system. +> +> When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to +> +> the  cloud. +> +> Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide +> +> Page  70  of  159 +> +> ![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. +> +> Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a +> +> mechanism  to  cache  downloaded  user  data. +> +> If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as +> +> possible. +> +> 4.1.6.7.4  Security +> +> Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to +> +> protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. +> +> System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. +> +> - +> System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must +> +> authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, +> +> smartphone  or  PC. +> +> - +> System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. +> +> - +> System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection +> +> against  falsification  of  data  from  unauthorized  access  or  illegal  access. +> +> - +> Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide +> +> user  data  only  to  the  authorized  user. +> +> Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must +> +> provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to +> +> include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against +> +> cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. +> +> 4.2  Web  HMI +> +> Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. +> +> **4.2.1  Web  API** +> +> Page  71  of  159 +> +> ![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service +> +> function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio +> +> visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, +> +> Photo,  etc.) +> +> Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of +> +> Audio  Visual  API  is  shown  in  Figure  6-1. +> +> **Figure  6-1:  Use  case  of  Audio  Visual  API** +> +> **4.2.1.1  Requirements** +> +> Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. +> +> · Select  content  using  URL +> +> · +> Select  content  using  contents  list  provided  by  multimedia  subsystem +> +> Page  72  of  159 +> +> ![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, +> +> DVD,  BT-Audio,  Photo,  etc.) +> +> · Play +> +> · Pause +> +> · Fast-forward +> +> · Rewind +> +> · Track  up +> +> · Track  down +> +> · Select  playmode  (Repeat/Random) +> +> Audio  Visual  API  must  provide  API  to  control  a  volume. +> +> · Volume  up +> +> · Volume  down +> +> · Mute +> +> Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. +> +> Audio  Visual  API  must  provide  API  for  notifications. +> +> · The  case  that  playback  state  is  changed +> +> · The  case  that  Audio  Visual  contents  is  add  /  removed +> +> Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. +> +> · Change  the  frequency. +> +> · Change  the  broadcasting  stations. +> +> · Receive  the  list  of  broadcasting  stations. +> +> · Select  the  preset  channel. +> +> · Get  the  information  of  the  broadcasting  station. +> +> Audio  Visual  API  must  provide  API  to  play  digital  radio. +> +> · Store  the  broadcast  program  information. +> +> Page  73  of  159 +> +> ![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · Get  the  broadcast  program  information. +> +> · Get  the  play  time. +> +> · Play  the  radio  broadcast  cached. +> +> AGL  System  must  support  a  web  API  to  access  Vehicle  information. +> +> AGL  System  must  support  web  API  to  control  STT/TTS  daemon. +> +> AGL  System  must  support  web  API  to  control  navi  engine. +> +> AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web +> +> apps. +> +> AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app +> +> and  a  native  app. +> +> AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider +> +> should  be  able  to  restrict  subscriber. +> +> AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. +> +> AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, +> +> Network  Information +> +> AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG +> +> AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio +> +> AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, +> +> server  sent  events,  session  history  of  browsing  context +> +> *AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL +> +> Page  74  of  159 +> +> ![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 +> +> The  iframe  element,  Content  Security  Policy  1.0. +> +> AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications +> +> AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing +> +> control,  Navigation  timing +> +> AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation +> +> AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, +> +> Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy +> +> AGL  System  must  support  Khronos  WebGL  API. +> +> **4.2.2  Web  Runtime** +> +> The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access +> +> the  AGL  Application  Framework  and  Services. +> +> **4.2.2.1  Requirements** +> +> AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., +> +> installation/removal). +> +> AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, +> +> view  generation,  rendering,  etc.) +> +> AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add +> +> better  device/platform  integration. +> +> Page  75  of  159 +> +> ![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to +> +> categorize  apps  with  different  privileges. +> +> System  must  provide  high  level  GUI  components  for  Web  application. +> +> At  least,  below  components  are  required. +> +> · Text  labels +> +> · Button +> +> · Radio  button +> +> · Check  box +> +> · Tab  panel +> +> · Animation  (e.g.  MNG,  GIF  animation) +> +> · Slider +> +> · Accordion  list +> +> · Anchor +> +> · Text  input  form +> +> · Dropdown  list  box +> +> · Date  picker +> +> 4.3  Native  HMI +> +> The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written +> +> using  Javascript  or  other  web  technologies. +> +> **4.3.1  Native  App  Runtime** +> +> The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to +> +> access  the  AGL  Application  Framework  and  Services. +> +> **4.3.1.1  Requirements** +> +> System  must  provide  high  level  GUI  components  for  native  application. +> +> Page  76  of  159 +> +> ![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> At  least,  below  components  are  required. +> +> · Text  labels +> +> · Button +> +> · Radio  button +> +> · Check  box +> +> · Tab  panel +> +> · Animation  (e.g.  MNG,  GIF  animation) +> +> · Slider +> +> · Accordion  list +> +> · Anchor +> +> · Text  input  form +> +> · Dropdown  list  box +> +> · Date  picker +> +> **4.3.2  Native  Application  Framework** +> +> The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an +> +> SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that +> +> framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the +> +> application  framework  provides  for  its  applications. +> +> **5   Services   Layer** +> +> The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the +> +> services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces +> +> remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime +> +> modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid +> +> unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer +> +> interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces +> +> provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may +> +> choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework +> +> runtime  to  adjust  to  any  new  interfaces, +> +> Page  77  of  159 +> +> ![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1  Platform  Services +> +> Platform  Services  Layer.  Conventional  Linux  platform  services +> +> **5.1.1  Bluetooth** +> +> This  document  describes  requirements  regarding  registration,  (dis)connection  and  device +> +> information  management  between  Bluetooth  device  and  infotainment  system.  Necessary +> +> Bluetooth  profiles  in  automotive  use  case  are  defined  here. +> +> **5.1.1.1  Requirements** +> +> The  Telephony  system  shall  be  designed  to +> +> support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR +> +> without  hardware  upgrade. +> +> A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: +> +> · Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) +> +> · HFP  (Hands  Free  Profile) +> +> · OBEX  (Object  Exchange) +> +> · OPP  (Object  Push  Profile) +> +> · PBAP  (Phonebook  Access  Profile) +> +> · SPP  (Serial  Port  Profile) +> +> · SDAP  (Service  Discovery  Access  Profile) +> +> If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music +> +> from),  the  system  shall  also  support  the  following  incremental  BT  profiles: +> +> · A2DP  (Advanced  Audio  Distribution  Profile) +> +> · AVRCP  (Audio  Visual  Remote  Control  Profile) +> +> The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the +> +> Page  78  of  159 +> +> ![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of +> +> generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in +> +> encryption  key  length  negotiation. +> +> When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as +> +> default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority +> +> scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration +> +> time. +> +> The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is +> +> 10  meters  and  maximum  power  is  2.5  mW  (4  dBm). +> +> The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall +> +> allow  using  five-slot  packet  transmission  for  faster  data  rate. +> +> The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a +> +> standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. +> +> vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are +> +> often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain +> +> name  and  address  information,  phone  numbers,  and  e-mail  addresses. +> +> vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, +> +> LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, +> +> URL,  UID,  Version,  and  KEY  properties. +> +> vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: +> +> MIME  Content-Type  for  Directory  Information +> +> vCard  MIME  Directory  Profile +> +> It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with +> +> the  vCard  version  2.1  properties. +> +> The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any +> +> associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is +> +> not  full. +> +> The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO +> +> Page  79  of  159 + + ------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **Support  in  HF** > **AGL** + ----------- ------------------------------------------------------------- ----------------------- ----------- + > 1 > Connection  management > Mandatory > x + + > 2 > Phone  status  information > Mandatory > x + + > 3 > Audio  Connection  handling > Mandatory > x + + > 4 > Accept  an  incoming  voice  call > Mandatory > x + + > 5 > Reject  an  incoming  voice  call > Mandatory > x + + > 6 > Terminate  a  call > Mandatory > x + + > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x + + > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x + > + > HF + + > 9 > Place  a  call  using  memory  dialing > Option > - + + > 10 > Place  a  call  to  the  last  number  dialed > Option > - + ------------------------------------------------------------------------------------------------------------- + +> ![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> shall  be  used. +> +> 5.1.1.1.1  Hands  Free  Profile +> +> The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile +> +> specification  version  1.6  or  later. +> +> The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, +> +> wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and +> +> output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to +> +> the  actual  phone. +> +> It  shall  provide  following  roles: +> +> Hands-Free  unit  (HF) + + > 11 > Call  waiting  notification > Option > x + ------- ------------------------------------------------------ ---------- ---------- + > 12 > Three  way  calling > Option > x(\*1) + > 13 > Calling  Line  Identification  (CLI) > Option > x + > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x + > 15 > Voice  recognition  activation > Option > x + > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - + > 17 > Ability  to  transmit  DTMF  codes > Option > x + > 18 > Remote  audio  volume  control > Option > - + > 19 > Respond  and  Hold > Option > x + > 20 > Subscriber  Number  Information > Option > x + > 21a > Enhanced  Call  Status > Option > x + > 21b > Enhanced  Call  Controls > Option > - + > 22 > Individual  Indicator  Activation > Option > - + > 23 > Wide  Band  Speech > Option > x + > 24 > Codec  Negotiation > Option > x + +> ![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> \*1:  Does  not  support  Multi-party  (conference)  call +> +> The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the +> +> model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +> +> string  in  a  phone  model  CGMM  variable. +> +> · Phone  Model  CGMM: +> +> · Type:  string +> +> · Max  length:  200  chars +> +> Page  81  of  159 +> +> ![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · Persistence:  No +> +> A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +> +> The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +> +> device. +> +> The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the +> +> Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be +> +> stored  as  a  string  in  a  phone  model  CGMI  variable. +> +> · Phone  Model  CGMI: +> +> · Type:  string +> +> · Max  length:  200  chars +> +> · Persistence:  No +> +> A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +> +> The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +> +> device. +> +> The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the +> +> revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +> +> string  in  a  phone  model  CGMR  property. +> +> · Phone  Model  CGMR: +> +> · Type:  string +> +> · Max  length:  200  chars +> +> · Persistence:  No +> +> A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +> +> The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +> +> device. +> +> 5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) +> +> The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP +> +> specification  version  1.2  or  later. +> +> Page  82  of  159 + + > **No.** > **Codec** > **Support** > **AGL** + ----------- ------------------- --------------- ----------- + > 1 > SBC > Mandatory > x + > 2 > MPEG-1,2  Audio > Option > - + > 3 > MPEG-2,4  AAC > Option > - + > 4 > ATRAC  family > Option > - + + > **No.** > **Feature** > **Support  in  SNK** > **AGL** + ----------- -------------------- ------------------------ ----------- + > 1 > Audio  Streaming > Mandatory > x + +> ![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to +> +> realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. +> +> It  shall  provide  following  roles: +> +> Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from +> +> the  SRC  on  the  same  piconet. +> +> Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. +> +> Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. +> +> Copyright  protection  technology  SCMS-T  should  be  supported. +> +> 5.1.1.1.3  Phone  Book  Access  Profile +> +> Page  83  of  159 +> +> ![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification +> +> version  1.1  or  later. +> +> The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between +> +> devices. +> +> Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The +> +> Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected +> +> device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing +> +> and  copying  contact  information. +> +> It  shall  provide  following  roles: +> +> · Phonebook  Client  Equipment  (PCE) +> +> It  shall  provide  following  types  of  Phonebook  objects: +> +> · The  main  Phonebook  object +> +> · The  Incoming  Call  History  object +> +> · The  Outgoing  Call  History  object +> +> · The  Missed  Call  History  object +> +> · The  Combined  Call  History  object +> +> A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device +> +> automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook +> +> download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: +> +> · Using  PBAP  profile +> +> All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. +> +> SIM)  and  also  any  stored  in  the  BT  device's  memory. +> +> The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the +> +> vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded +> +> from. +> +> 5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile +> +> Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +> +> necessary  lower  layers. +> +> Page  84  of  159 + + > **No.** > **Service** > **Support  in  DT** > **AGL** + ----------- ------------------------------------------- ----------------------- ----------- + > 1 > Data  call  without  audio  feedback > Mandatory > x + > 2 > Data  call  with  audio  feedback > Option > - + > 3 > Fax  services  without  audio  feedback > N/A > - + > 4 > Fax  services  with  audio  feedback > N/A > - + > 5 > Voice  call > N/A > - + > 6 > Incoming  calls > Option > x + > 7 > Outgoing  calls > Mandatory > x + +> ![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” +> +> Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. +> +> 5.1.1.1.5  Object  Push  Profile  (OPP) +> +> Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower +> +> layers. +> +> It  has  to  comply  with  the  specification  for  “Push  Server”. +> +> Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. +> +> **Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** +> +> Page  85  of  159 + + > **No.** > **Feature** > **Support  in  CT** > **AGL** + ----------- -------------------------------------------- ----------------------- ----------- + > 1 > Connection  establishment  for  control > Mandatory > x + > 2 > Release  connection  for  control > Mandatory > x + > 3 > Connection  establishment  for  browsing > C6 > x + + ------------------------------------------------------------------------------------- + > **No** > **Feature** > **Support  in  Push  Server** > **AGL** + > + > **.** + ---------- ---------------------------- --------------------------------- ----------- + > 1 > Object  Push > Mandatory > x + + > 2 > Business  Card  Pull > Option > - + + > 3 > Business  Card  Exchange > Option > - + ------------------------------------------------------------------------------------- + +> ![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) +> +> The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. +> +> The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device +> +> plus  one  remote  control.. +> +> The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL +> +> column  in  Table  25  should  be  supported. +> +> C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional +> +> otherwise +> +> C3:  Mandatory  to  support  at  least  one  Category +> +> C4:  Mandatory  if  Category  2  supported,  excluded  otherwise +> +> C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise +> +> EX:  Excluded +> +> Page  86  of  159 +> +> ![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 4 Release  connection  for  browsing C6 x +> +> 5 AV/C  Info  commands Option x +> +> 6 Category  1:  Player/Recorder C3 x +> +> 7 Category  2:  Monitor/Amplifier C3 - +> +> 8 Category  3:  Tuner C3 - +> +> 9 Category  4:  Menu C3 - +> +> 10 Capabilities Option x +> +> 11 Player  Application  Settings Option x +> +> 12 Metadata  Attributes  for  Current  Media  Item Option x +> +> 13 Notifications C2 x +> +> 14 Continuation C2 x +> +> 15 Basic  Group  Navigation Option x +> +> 16 Absolute  Volume C4 - +> +> 17 Media  Player  Selection Option x +> +> 17.1 -  Supports  Multiple  Players Option x +> +> 18 Browsing Option x +> +> 18.1 -  Database  Aware  Players Option x +> +> 19 Search Option - +> +> 20 Now  Playing C6 x +> +> 20.1 -  Playable  Folders Option x +> +> 21 Error  Response EX - +> +> 22 PASSTHROUGH  operation  supporting  press  and Option x +> +> Page  87  of  159 + + ------------------------------------------------------------------------------ + > **No** > **Feature** > **Support  by  the  MCE** > **AGL** + > + > **.** + ---------- ------------------------- ----------------------------- ----------- + > 1 > Message  Notification > C1 > x + + > 2 > Message  Browsing > C1 > x + + > 3 > Message  Uploading > Option > x + + > 4 > Message  Delete > Option > - + + > 5 > Notification > C2 > x + > + > Registration + ------------------------------------------------------------------------------ + +> ![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> hold +> +> The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and +> +> pass  this  information  up  to  so  it  can  be  passed  to  the  User. +> +> 5.1.1.1.7  Message  Access  Profile +> +> Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary +> +> lower  layers. +> +> It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. +> +> Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. +> +> C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features +> +> C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message +> +> Notification.  Not  applicable  otherwise. +> +> Page  88  of  159 + + > **No.** > **Feature** > **Support  in  PANU** > **AGL** + ----------- ------------------------------------------ ------------------------- ----------- + > 1 > Initialization  of  NAP/GN  service > - > - + > 2 > Shutdown  of  NAP/GN  service > - > - + > 3 > Establish  NAP/GN  service  Connection > Mandatory > x + +> ![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.1.1.8  Serial  Port  Profile  (SPP) +> +> The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version +> +> 1.1  or  later. +> +> It  shall  provide  following  roles: +> +> Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. +> +> Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. +> +> Following  features  shall  be  provided  by  the  Supplier: +> +> Establish  link  and  setup  virtual  serial  connection +> +> Accept  link  and  establish  virtual  serial  connection +> +> Register  Service  record  for  application  in  local  SDP  database +> +> 5.1.1.1.9  Personal  Area  Network  (PAN)  Profile +> +> Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +> +> necessary  lower  layers. +> +> It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. +> +> Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. +> +> Page  89  of  159 + + > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x + ----- ------------------------------------------- ------------- ----- + > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x + > 6 > Management  Information  Base  (MIB) > - > - + +> ![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.1.1.10  Service  Discovery  Profile  (SDP) +> +> The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP +> +> specification  version  1.1. +> +> The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices +> +> in  the  vicinity  of  a  Bluetooth  enabled  device. +> +> It  shall  provide  following  roles: +> +> Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. +> +> Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to +> +> the  service  inquiries  generated  by  Local  Device. +> +> The  following  features  shall  be  provided  by  the  Supplier: +> +> Search  for  services  by  service  class +> +> Search  for  services  by  service  attributes +> +> Service  browsing +> +> 5.1.1.1.11  Device  Information  Profile +> +> Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for +> +> necessary  lower  layers. +> +> Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. +> +> **Table  28  :  List  of  DIP  Supporting  Functions** +> +> Page  90  of  159 + + > **No.** > **Feature** > **Support** > **AGL** + ----------- ----------------------- --------------- ----------- + > 1 > SpecificationID > Mandatory > x + > 2 > VendorID > Mandatory > x + > 3 > ProductID > Mandatory > x + > 4 > Version > Mandatory > x + > 5 > PrimaryRecord > Mandatory > x + > 6 > VendorIDSource > Mandatory > x + > 7 > ClientExecutableURL > - > - + > 8 > ServiceDescription > - > - + > 9 > DocumentationURL > - > - + +> ![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.1.1.12  Bluetooth  Smart  Ready +> +> Bluetooth  Smart  Ready  shall  be  supported. +> +> It  shall  comply  with  Bluetooth  Low  Energy  standard. +> +> 5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) +> +> The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX +> +> specification  version  2.0  or  later. +> +> The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between +> +> devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. +> +> It  shall  provide  following  roles: +> +> Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data +> +> objects  shall  be  pushed  and  pulled,  respectively. +> +> Page  91  of  159 +> +> ![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. +> +> The  following  features  shall  be  provided  by  the  Supplier: +> +> Establishing  an  object  connection +> +> Pushing  a  data  object +> +> Pulling  a  data  object +> +> Performing  an  action  on  data  objects +> +> Creating  and  managing  a  Reliable  Object  Exchange  Connection +> +> 5.1.1.1.14  Generic  Audio/Video  Distribution  Profile +> +> The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the +> +> GAVDP  specification  version  1.2  or  later. +> +> The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between +> +> two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. +> +> It  shall  provide  following  roles: +> +> Initiator  (INT) +> +> Acceptor  (ACP) +> +> Following  are  the  feature  requirements  for  this  profile: +> +> Connection +> +> Transfer  Control +> +> Signalling  Control +> +> Security  Control +> +> Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not +> +> yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. +> +> 5.1.1.1.15  Bluetooth  Diagnostics +> +> **5.1.2  Error  Management** +> +> The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes +> +> Page  92  of  159 +> +> ![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized +> +> restart.  In  addition, +> +> in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery +> +> to  issue  in  a  short  amount  of  time. +> +> **5.1.2.1  Use  Cases** +> +> 5.1.2.1.1  System  Surveillance  and  Recovery +> +> While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an +> +> immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating +> +> the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to +> +> try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating +> +> middle  ware,  reboot  the  whole  system  to  try  and  recover. +> +> There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that +> +> adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The +> +> AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. +> +> The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even +> +> if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be +> +> done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error +> +> Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the +> +> degree  should  be  adjusted  by  its  behavior  status. +> +> 5.1.2.1.2  Collecting  Information +> +> For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt +> +> recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the +> +> cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. +> +> With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On +> +> the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come +> +> Page  93  of  159 +> +> ![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, +> +> the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. +> +> **5.1.2.2  Requirements** +> +> Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its +> +> status  automatically  and  recover +> +> The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each +> +> process. +> +> The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. +> +> When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold +> +> value,  action  is  changeable  by  AGL  user. +> +> Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification +> +> to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are +> +> output  communication  or  disk  I/O. +> +> Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification +> +> by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an +> +> error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication +> +> error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. +> +> Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it +> +> should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination +> +> of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so +> +> those  two  should  be  able  to  set  separately. +> +> Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold +> +> value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be +> +> changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. +> +> Should  be  able  to  vanish  process  forcibly  including  subsidiary  process +> +> Page  94  of  159 +> +> ![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Make  the  software  that  works  by  system  have  the  concept  of  level  importance. +> +> Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be +> +> adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. +> +> The  process  that  detecting  an  external  communication  error  within  the  Error  Management +> +> module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. +> +> The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as +> +> more  than  one  process. +> +> The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple +> +> applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where +> +> multiple  applications  can  be  moved  by  the  same  process. +> +> Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing +> +> process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as +> +> process  crash,  exit,  etc.. +> +> An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends +> +> suddenly  the  other  will  not  become  abnormal  state. +> +> The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other +> +> process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards +> +> external  side. +> +> When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart +> +> additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered +> +> beforehand. +> +> The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file +> +> system  without  destroying  them. +> +> Page  95  of  159 +> +> ![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for +> +> analyzing. +> +> When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a +> +> message  that  can  specify  the  cause. +> +> Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +> +> in  a  short  period  of  time  have  been  equipped  and  able  to  select. +> +> In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or +> +> system  down  does  not  occur  (self-destruction  on  log  output  process). +> +> Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. +> +> Should  be  able  to  select  the  level  of  log  output. +> +> Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. +> +> Should  be  able  to  obtain  the  information  linked  to  the  system  resources. +> +> Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. +> +> Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +> +> in  a  short  period  of  time  have  been  equipped  and  able  to  select. +> +> As  the  smallest  amount  of  information,  the  following  information  should  be  left. +> +> · Register  information +> +> · Process  logical  memory  map +> +> · +> Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence +> +> · Time  of  occurrence +> +> · +> Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing +> +> file‑name  of  the  thread  etc.) +> +> Page  96  of  159 +> +> ![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · The  signal  that  occurred +> +> Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. +> +> · +> Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted +> +> for  an  output. +> +> · +> Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent +> +> dropping  the  information  needed. +> +> · +> Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] +> +> · +> Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed +> +> maximum  size. +> +> · +> NOTE  information  of  ELF  header  and  program  header  will  not  change. +> +> Selectable  memory  mappings  are  the  following. +> +> · anonymous  private  mappings +> +> · anonymous  shared  mappings +> +> · file-backed  private  mappings +> +> · file-backed  shared  mappings +> +> · private  huge  page +> +> · shared  huge  page +> +> Setting  parameters  of  the  output  context  are  the  following. +> +> · +> Memory  mapping  category  which  is  for  an  output  object  can  be  set. +> +> · The  order  of  outputting  memory  mapping  can  be  set. +> +> Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in +> +> increments  of  process. +> +> Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be +> +> able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. +> +> Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. +> +> Page  97  of  159 +> +> ![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. +> +> **5.1.3  Graphics** +> +> Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. +> +> **5.1.4  Location  Services** +> +> Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead +> +> reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary +> +> output  of  the  GPS  receiver. +> +> **5.1.4.1  Position** +> +> **5.1.4.2  Time  of  Day** +> +> With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car +> +> device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of +> +> its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in +> +> future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. +> +> **Monotonic  and  Absolute  Time  Support** +> +> As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. +> +> Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s +> +> moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and +> +> Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. +> +> On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time +> +> that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, +> +> some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports +> +> Monotonic  Time. +> +> **Kernel  Time  Precision** +> +> Page  98  of  159 +> +> ![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those +> +> communicating  system  includes  the  device  that  needs  ms  order  procedure. +> +> In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on +> +> the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest +> +> value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. +> +> **5.1.4.3  Requirements** +> +> Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. +> +> Adjust  the  system  time  after  the  time  is  determinate. +> +> GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using +> +> the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. +> +> GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not +> +> imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make +> +> Source  plugin  can  not  be  GPL  or  LGPL. +> +> When  waiting,  can  use  both  absolute  time  and  monotonic  time +> +> Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +> +> monotonic  time. +> +> Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +> +> monotonic  time. +> +> System  time  must  be  able  to  use  consecutively  at  least  until  2099. +> +> Absolute  time  has  to  support  leap  year  and  leap  seconds. +> +> 1  jiffies  have  to  be  smaller  than  1ms. +> +> Page  99  of  159 +> +> ![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. +> +> From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. +> +> A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. +> +> **5.1.5  Health  Monitoring** +> +> Platform  monitoring  services  such  as  watchdog  or  active  monitoring +> +> **5.1.6  IPC** +> +> Standard  platform  interprocess  and  interprocessor  communication  mechanism. +> +> **5.1.7  Lifecycle  Management** +> +> Startup,  shutdown,  state  change,  etc. +> +> **5.1.8  Network  Services** +> +> Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer +> +> including  Wifi,  Bluetooth,  or  ethernet. +> +> **5.1.9  Persistent  Storage** +> +> Power  safe  persistent  storage +> +> **5.1.10  Power  Management** +> +> Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs +> +> in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. +> +> *This, in turn has impact on power budget and temperature/heat dissipation characteristic of* +> +> Page  100  of  159 +> +> ![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> modern  ECUs +> +> In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, +> +> in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal +> +> balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important +> +> for  overall  durability  characteristic. +> +> Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming +> +> more  welcomed  over  traditional  cold  boot  approaches. +> +> Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has +> +> become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only +> +> consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) +> +> **5.1.10.1  Requirements** +> +> AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend +> +> states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” +> +> /“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) +> +> Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. +> +> AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state +> +> transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state +> +> transitions  if  no  requests  provided  from  applications. +> +> Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of +> +> this  specification  (it  is  also  platform-dependent). +> +> AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of +> +> cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting +> +> core  in  one  of  its  low  power  states) +> +> AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular +> +> cores  from  SMP  group. +> +> Page  101  of  159 +> +> ![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points +> +> (table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, +> +> some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget +> +> insignificant) +> +> Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling +> +> Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. +> +> Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they +> +> may  have  negative  impact  on  overall  system  performance/predictability +> +> AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is +> +> platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) +> +> Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states +> +> Only  application-defined  policies  shall  be  allowed  for  CPU  Idle +> +> AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices +> +> AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling +> +> **5.1.11  Resource  Management** +> +> Resource  and  device  management. +> +> Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource +> +> request  by  the  Resource  Manager. +> +> **5.1.12  Telephony  Services** +> +> **5.1.12.1  Requirements** +> +> Page  102  of  159 +> +> ![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.12.1.1  Telephony  variants +> +> Purpose:  To  define  the  variants  of  Telephony +> +> Requirement: +> +> There  will  be  2  variants  of  phone  system. +> +> Variant  1:  Front  User  only  Telephony. +> +> Variant  2:  Rear  and  Front  Telephony. +> +> All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature +> +> can  be  disabled  via  car  configuration. +> +> **5.1.13  Wi-Fi** +> +> This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information +> +> management  between  a  wireless  LAN  device  and  infotainment  system. +> +> Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. +> +> **5.1.13.1  Use  Cases** +> +> 5.1.13.1.1  Construct  WiFi  Network +> +> In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. +> +> a\. STA +> +> In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via +> +> an  Access  Point. +> +> It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. +> +> b\. AP +> +> In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices +> +> with  an  external  network. +> +> Page  103  of  159 +> +> ![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. +> +> c\. P2P +> +> In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- +> +> Fi  Direct. +> +> 5.1.13.1.2  Miracast +> +> In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) +> +> They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, +> +> by  using  UIBC  (User  Interface  Back  Channel).-(b) +> +> **Figure  8-29  :  Overview  of  Miracast** +> +> a\. Shared  Displayed  Content +> +> Page  104  of  159 +> +> ![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Use  case  examples  of  shared  displayed  content  are: +> +> · +> A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device +> +> (e.g.  Mobile)  on  In-Vehicle  Infotainment  system. +> +> · +> A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment +> +> system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). +> +> b\. Remote  Operation +> +> Use  case  examples  of  remote  operation  are: +> +> · +> A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device +> +> (e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. +> +> · +> A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle +> +> Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). +> +> · +> While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation +> +> functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. +> +> Mobile). +> +> 5.1.13.1.3  DLNA +> +> In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. +> +> **5.1.13.2  Requirements** +> +> 5.1.13.2.1  Security +> +> The  WiFi  module  shall  support  security  standard  WEP. +> +> It  shall  support  40  bit  WEP  encryption  method. +> +> It  shall  support  104  bit  WEP  encryption  method. +> +> It  shall  support  security  standard  WPA  Personal. +> +> Page  105  of  159 +> +> ![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  shall  support  TKIP  encryption  method. +> +> It  shall  support  CCMP  encryption  method. +> +> It  shall  support  security  standard  WPA2  Personal. +> +> It  shall  support  TKIP  encryption  method. +> +> It  shall  support  CCMP  encryption  method. +> +> It  shall  support  security  standard  WPA  Enterprise. +> +> It  shall  support  TKIP  encryption  method. +> +> It  shall  support  CCMP  encryption  method. +> +> It  shall  support  security  standard  WPA2  Enterprise. +> +> It  shall  support  TKIP  encryption  method. +> +> It  shall  support  CCMP  encryption  method. +> +> 5.1.13.2.2  Simple  Configuration +> +> It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. +> +> It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. +> +> It  shall  support  Configuration  Method  for  Display. +> +> Page  106  of  159 +> +> ![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  shall  support  Configuration  Method  for  Keypad. +> +> It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. +> +> It  shall  support  Configuration  Method  for  PushButton. +> +> It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. +> +> 5.1.13.2.3  QoS +> +> It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. +> +> It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. +> +> 5.1.13.2.4  STA +> +> The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). +> +> 5.1.13.2.5  AP +> +> The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). +> +> 5.1.13.2.6  WiFi  Direct +> +> It  shall  comply  with  Wi-Fi  Direct  standard. +> +> It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. +> +> Page  107  of  159 + + -------------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **(Reference)** + > + > **Support  in  Wi-** + > + > **Fi  Direct** + ----------- ---------------------------------------------------- -------------------------- ------------------------ + > 1 > P2P  Provision > ‑ > Mandatory + > + > Discovery + + > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory + + > 3 > ‑ > Find  Phase > Mandatory + + > 4 > P2P  GO  Negotiation > ‑ > Mandatory + + > 5 > P2P  Service  Discovery > ‑ > Option + + > 6 > P2P  Invitation > Temporary  P2P  Group > Option + + > 7 > ‑ > Persistent  P2P  Group > Option + + > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option + + > 9 > Intra-BSS  Distribution > ‑ > Option + + > 10 > Concurrent  Operation > ‑ > Option + + > 11 > P2P  Service  Discovery > UPnP > Option + + > 12 > ‑ > Bonjour > Option + + > 13 > ‑ > Wi-Fi  Display > Option + + > 14 > ‑ > WS-Discovery > Option + + > 15 > ‑ > Vendor  specific > Option + -------------------------------------------------------------------------------------------------------------------- + +> ![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.13.2.7  Miracast +> +> Page  108  of  159 + + -------------------------------------------------------------------------------------------------------------- + > ‑**No.** > **Feature** > ‑ > **(Refere** + > + > **nce)** + > + > **Suppor** + > + > **t        in** + > + > **Miracas** + > + > **t** + ------------ ----------------------------------------------------- ----------------------- ------------------- + > 1 > WFD  Device  type > WFD  Source > Mandat + > + > ory + + > 2 > ‑ > Primary  Sink > Mandat + > + > ory + + > 3 > ‑ > Dual-role  possible > Option + + > 4 > WFD  Service > ‑ > Option + > + > Discovery + + > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat + > + > ory + + > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option + + > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option + > + > Group + + > 8 > ‑ > via  TDLS > Option + + > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat + > + > ory + + > 10 > WFD  Session  Establishment  (RTSP) > Mandat + > + > ory + -------------------------------------------------------------------------------------------------------------- + +> ![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  shall  comply  with  Miracast  standard. +> +> It  shall  support  the  Miracast  functions  identified  in  Table  30. +> +> Page  109  of  159 + + --------------------------------------------------------------------------------- + > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat + > + > ory + ------ --------------------------------------------------- ----------- ---------- + > 12 > WFD  Standby  (RTP/RTSP) > Option + + > 13 > Video  CODEC  formats > Option + + > 14 > Audio  CODEC  formats > Option + + > 15 > UIBC > Generic + + > 16 > HIDC + --------------------------------------------------------------------------------- + +> ![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.1.13.2.8  WiFi  Hotspot +> +> It  shall  comply  with  Wi-Fi  Hotspot  standard. +> +> In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot +> +> service. +> +> In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. +> +> 5.1.13.2.9  DLNA  via  WiFi +> +> The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. +> +> **5.1.14  Window  System** +> +> A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +> +> interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +> +> Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +> +> component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +> +> and  a  routing  of  user  interactions. +> +> Page  110  of  159 +> +> ![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.2  Automotive  Services +> +> Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but +> +> contains  services  specialized  for  automotive  applications. +> +> **5.2.1  Audio  Services** +> +> BTBF,  equilization,  mult-zone  audio  control,  etc. +> +> **5.2.2  Camera  Services** +> +> Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. +> +> **5.2.3  Configuration  Services** +> +> Service  for  storing  configuration  parameters. +> +> **5.2.4  Diagnostic  Services** +> +> Diagnostic  services. +> +> (This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) +> +> **5.2.5  Multimedia  Services** +> +> CD,  DVD,  Blu-Ray,  MP3,  etc. +> +> (Factor  out  metadata  into  separate  component.) +> +> **5.2.5.1  Media  Player** +> +> In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just +> +> Page  111  of  159 +> +> ![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video +> +> devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, +> +> there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- +> +> seat  passengers  as  well  as  driver  all  having  independent  requirements. +> +> The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: +> +> · +> Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the +> +> ones  encountered  in  mobile  and  desktop  world. +> +> · +> Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) +> +> and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or +> +> establishes  a  network  connection.) +> +> · +> Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of +> +> audio  /  video  processing  chains. +> +> Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data +> +> processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in +> +> comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from +> +> navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from +> +> Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so +> +> on. +> +> It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore +> +> processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing +> +> offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with +> +> particular  implementation  freedom  left  for  a  silicon  vendor. +> +> The  following  requirements  formalize  these  considerations. +> +> **5.2.5.2  Requirements** +> +> 5.2.5.2.1  Media  Containers +> +> AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This +> +> includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It +> +> shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable +> +> input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated +> +> from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall +> +> be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. +> +> Page  112  of  159 +> +> ![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, +> +> for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream +> +> identification  data  from  media  container. +> +> AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: +> +> · HTTP +> +> · RTPS +> +> · Digital  Radio  (DAB) +> +> · DigitalTV  (DVB-T)  etc. +> +> It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with +> +> system  requirements. +> +> AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload +> +> computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such +> +> extension,  if  available,  shall  be  transparent  to  the  applications. +> +> Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. +> +> AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the +> +> source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without +> +> intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this +> +> process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of +> +> particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from +> +> multiple  choices. +> +> AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall +> +> support  the  following  functionality: +> +> · +> Selection  of  data  source  and  destination  (files,  devices,  network  resources) +> +> · Pausing/resuming  of  multimedia  streams +> +> · Rewinding  in  forward  and  reverse  directions  (for  playback) +> +> · Audio  volume  control  on  per-stream  basis +> +> · Retrieval  of  current  stream  position  (timestamp) +> +> Page  113  of  159 +> +> ![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · +> Notifications  on  error  conditions  preventing  multimedia  stream  processing +> +> AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved +> +> into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to +> +> specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to +> +> specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw +> +> audio/video  streams  to  multiple  renderers  as  well. +> +> AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and +> +> synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: +> +> · +> Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. +> +> · Per-stream  volume  and  audio  effects  control. +> +> · +> Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). +> +> · +> Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). +> +> · Mixing  and  broadcasting  of  the  audio  streams. +> +> AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to +> +> specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or +> +> removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, +> +> emergency  system  alarm  output  and  so  on. +> +> AGL  shall  provide  support  for  major  multimedia  containers,  such  as: +> +> · MPEG2-TS/PS  (ISO/IEC  13818-1) +> +> · MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) +> +> It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with +> +> system  requirements. +> +> It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: +> +> · OGG  (RFC  3533) +> +> · 3GPP  (ISO/IEC  14496-12) +> +> · etc +> +> Page  114  of  159 +> +> ![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 5.2.5.2.2  Media  Audio  Codecs +> +> AGL  shall  provide  support  for  major  audio  codecs,  such  as: +> +> · +> MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) +> +> · AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) +> +> It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system +> +> requirements. +> +> It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: +> +> · VORBIS  (http://xiph.org/vorbis/) +> +> · Windows  Media  Audio +> +> · etc. +> +> 5.2.5.2.3  Media  Video  Codecs +> +> AGL  shall  provide  support  for  major  video  codecs,  such  as: +> +> · MPEG-2  (ISO/IEC  13818-2) +> +> · MPEG-4  Part  2  (ISO/IEC  14496-2) +> +> · H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) +> +> It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system +> +> requirements. +> +> It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: +> +> · Theora  (www.theora.org) +> +> · Windows  Media  Video +> +> · etc +> +> 5.2.5.2.4  Image  File  Formats +> +> Page  115  of  159 +> +> ![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true +> +> colour. +> +> Compression  formats +> +> · RLE  8  bits/pixel +> +> · RLE  4  bits/pixel +> +> · Bit  field  or  Huffman  1D  compression +> +> · JPEG  or  RLE-24 +> +> · PNG +> +> The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 +> +> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including +> +> Exchangeable  Image  File  Format  (EXIF)  format. +> +> The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, +> +> including  transparency +> +> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced +> +> version  89a  and  also  animation  in  GIFF  images. +> +> The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. +> +> The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +> +> format. +> +> The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +> +> format. +> +> **5.2.6  Navigation  Services** +> +> Navigation  engine +> +> Page  116  of  159 +> +> ![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **5.2.7  PIM** +> +> Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. +> +> **5.2.8  Smartphone  Link** +> +> This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which +> +> realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation +> +> is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and +> +> AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use +> +> smartphone  content  (map,  music,  browser...)  by  IVI. +> +> Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. +> +> **Figure:  8-30** +> +> Page  117  of  159 +> +> ![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AGL  defines  following  requirements  of  Smartphone  link. +> +> 1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. +> +> 2.  The  sound  of  smartphone  shall  be  linked  to  IVI. +> +> 3.  The  sound  shall  be  synchronized  with  the  screen. +> +> 4.  IVI  should  operate  smartphone. +> +> 5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. +> +> 6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should +> +> inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. +> +> This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone +> +> link. +> +> **5.2.8.1  Miracast** +> +> This  section  describes  requirements  regarding  Smartphone  link  (Miracast). +> +> Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- +> +> Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing +> +> between  source  device  and  sink  device. +> +> Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. +> +> **Figure:  8-31** +> +> Page  118  of  159 + + ---------------------------------------------------------------------------------------------- + > **No** > **Requires** > **Description** + ------------ ----------------------------- --------------------------------------------------- + > SPL.1.1 > WFD  Topology > Define  role  of  Miracast + + > SPL.1.2 > Connection  Topology > Define  connection  condition  between + > + > a  smartphone  and  an  IVI + + > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi + > > + > 1 > Direct). + + > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency + > + > 2 + + > SPL.1.3 > Video  Format > Define  Video  format + + > SPL.1.4 > Audio  Format > Define  Audio  format + + > SPL.1.5 > Session  Control > Define  Miracast  session  state + + > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required + > + > for  implementing  Miracast + + > SPL.1.7 > Resource  Management > Define  resource  management + ---------------------------------------------------------------------------------------------- + +> ![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. +> +> **References** +> +> \[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 +> +> \[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 +> +> \[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision +> +> 2.2 +> +> \[4\]  DCP  (Digital  Content  Protection)   +> +> AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. +> +> Page  119  of  159 +> +> ![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> SPL.1.8 Fail-safe  Control Define  Fail-safe  control +> +> **Table  8-14:  Smartphone  Link  (Miracast)  Requirements** +> +> **Figure:  8-32  State  Change  Diagram** +> +> The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. +> +> Page  120  of  159 + + ------------------------------------------------------------------------------------------------------- + > **No.** > **State** > **Description** + ----------- ------------------------- ----------------------------------------------------------------- + > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. + + > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and + > + > waiting  for  Wi-Fi  P2P  connection  from  source + > + > device. + + > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source + > + > device. + + > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. + + > 5 > Play > Streaming  the  audio  and  video  content  from  source + > + > device  to  sink  device. + + > 6 > Pause > Paused  the  streaming  of  audio  and  video  content + > + > from  source  divide  to  sink  device. + ------------------------------------------------------------------------------------------------------- + +> ![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **5.2.8.2  Smart  Device  Link** +> +> “Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. +> +> Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach +> +> makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s +> +> distraction  and  voice  recognition. +> +> That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote +> +> procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework +> +> and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. +> +> SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile +> +> phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported +> +> applications  can  be  launched. +> +> Page  121  of  159 +> +> ![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **Figure  8-33  :  SDL  overview** +> +> **5.2.8.3  Requirements** +> +> 5.2.8.3.1  Miracast +> +> System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. +> +> · +> Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which +> +> from  Source  Device‑Smartphone‑. +> +> · Supporting  WFD  Source  is  an  option. +> +> · +> Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) +> +> source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). +> +> · +> Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take +> +> measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over +> +> 5Km/H) +> +> · Support  Wi-Fi  P2P  connection. +> +> · +> Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in +> +> Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. +> +> · Wi-Fi  TDLS  connection  is  an  option. +> +> · +> AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select +> +> Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) +> +> · +> AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive +> +> Page  122  of  159 +> +> ![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for +> +> confirmation) +> +> · +> Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. +> +> · +> Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P +> +> connection  established. +> +> · +> Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. +> +> · +> Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) +> +> function  if  support  5GHz  band. +> +> · Follow  reference  \[1\]  for  Video  Codec. +> +> · Support  follow  format  for  Video  Resolution  and  Frame  rate. +> +> o 640\*480‑VGA‑‑Progressive  60  fps +> +> o 1280\*720‑HD‑Progressive  30  fps +> +> Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. +> +> · Support  follow  format  for  Audio. +> +> o LPCM  48ksps  16bit  2ch +> +> o AAC  48ksps  16bit  2ch +> +> Regarding  Audio  Format,  other  formats  are  an  option. +> +> When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up +> +> notification) +> +> Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support +> +> content  protection  function. +> +> · +> AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not +> +> define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for +> +> Page  123  of  159 +> +> ![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> vendor’s  own  reason. +> +> · Support  both  encryption  cases  if  support  HDCP  function. +> +> o Case1  Videos  data  encryption +> +> o Case2  Both  video  and  audio  encryption +> +> Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to +> +> DCP.(reference  \[4\]) +> +> · +> Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, +> +> then  Miracast  release  screen  and  audio  resources  for  the  event. +> +> · +> It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast +> +> session.) +> +> · +> Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events +> +> happen. +> +> o Failed  to  Wi-Fi  connection +> +> o Failed  to  establish  Miracast  session +> +> o Wi-Fi  link  loss  on  Miracast +> +> o Break  Miracast  connection  from  smartphone +> +> 5.2.8.3.2  Smart  Device  Link +> +> System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. +> +> System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. +> +> System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel +> +> device  of  IVI  device. +> +> System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice +> +> Page  124  of  159 +> +> ![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> recognition  of  IVI  system. +> +> System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity +> +> method  must  be  supported  Bluetooth  and/or  Wi-Fi. +> +> System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity +> +> method  must  be  supported  Bluetooth  and/or  Wi-Fi. +> +> **5.2.9  Speech  Services** +> +> The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. +> +> AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands +> +> AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech +> +> **5.2.10  Tuner  Services** +> +> The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into +> +> the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, +> +> TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present +> +> in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. +> +> **5.2.10.1  Receivers** +> +> The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including +> +> AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any +> +> number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from +> +> the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current +> +> content. +> +> The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into +> +> the  same  API  regardless  of  the  receiver  type. +> +> Page  125  of  159 +> +> ![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow +> +> its  clients  to  address  each  receiver  in  the  system  independently. +> +> 5.2.10.1.1  HD  Radio +> +> HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An +> +> HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to +> +> provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the +> +> receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The +> +> HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the +> +> iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional +> +> design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by +> +> iBiquity  Digital. +> +> The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the +> +> requirements  in  this  section. +> +> 1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. +> +> 2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. +> +> 3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. +> +> Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is +> +> applicable  to. +> +> AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status +> +> to  the  system. +> +> AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the +> +> tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning +> +> successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio +> +> output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No +> +> Reception"  is  available  in  that  specific  channel. +> +> AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +> +> the  system,  which  shall  be  added  in  the  station  database. +> +> Page  126  of  159 +> +> ![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · Frequency +> +> · Mono/Stereo +> +> FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +> +> the  system,  which  shall  be  added  in  the  station  database. +> +> · Frequency +> +> · PI  Code  (RDS  only) +> +> · PTY  (RDS  only) +> +> · Radio  Text  (RDS  only) +> +> · PS  Name  (RDS  only) +> +> · Category  (RDS  only) +> +> · Mono/Stereo +> +> HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +> +> the  system,  which  shall  be  added  in  the  station  database. +> +> · Frequency +> +> · PTY +> +> · No  of  HD  channels  available +> +> · Radio  Text +> +> · Channel  Name +> +> · Category +> +> · Bit  rate +> +> · Station  Logo +> +> · Artist  Experience +> +> The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. +> +> The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal +> +> strength. +> +> AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. +> +> Page  127  of  159 +> +> ![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be +> +> possible  to  adjust  by  software. +> +> · Range:  15  –  40  dBµV +> +> · Step:  1  dBµV +> +> · Default:  20  dBµV +> +> · +> Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity +> +> level.  TBD,  Supplier  to  suggest  solution. +> +> AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be +> +> possible  to  adjust  by  software. +> +> · Range:  20  –  40  dBµV +> +> · Step:  1  dBµV +> +> · Default:  34  dBµV +> +> · +> It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. +> +> different  for  night  and  day). +> +> The  system  shall  be  able  to  switch  between  AM  and  FM  bands. +> +> HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the +> +> SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +> +> present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance +> +> with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +> +> Information  Service  Transport". +> +> HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the +> +> SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +> +> present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance +> +> with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +> +> Information  Service  Transport". +> +> HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. +> +> Page  128  of  159 +> +> ![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. +> +> · Song +> +> · Artist +> +> · Album +> +> · Genre +> +> · Comments +> +> · Commercial +> +> · Reference  Identifier +> +> The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification +> +> "HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" +> +> FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the +> +> system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, +> +> Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency +> +> range  from  87,5  MHz  to  108,0  MHz". +> +> FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled +> +> the  system  shall  indicate  this. +> +> FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. +> +> FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. +> +> FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. +> +> FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. +> +> FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. +> +> FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received +> +> through  RDS. +> +> Page  129  of  159 +> +> ![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. +> +> FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. +> +> FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. +> +> FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. +> +> FM/HD  system  shall  be  able  to  enable/disable  regionalisation. +> +> FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. +> +> FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) +> +> reception. +> +> FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. +> +> FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. +> +> FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. +> +> HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. +> +> HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. +> +> AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. +> +> AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. +> +> *HD system shall extract the album name, artist name, track number from the audio stream a*nd +> +> Page  130  of  159 +> +> ![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> present  to  the  system. +> +> The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The +> +> feature  will  be  able  to  store  at  least  50  tags. +> +> *5.2.10.1.1.1  Configuration* +> +> AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration +> +> file. +> +> AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. +> +> AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local +> +> configuration  file. +> +> 5.2.10.1.2  Database  Requirements +> +> AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains +> +> the  following  attributes: +> +> · Frequency +> +> · PTY  (FM  &  HD  only) +> +> · Channel  name  (FM  &  HD  only) +> +> · Channel  icon  (HD  Only) +> +> · Category  (FM  &  HD  only) +> +> AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following +> +> conditions: +> +> · New  channel  is  found +> +> · Existing  channel  disappears +> +> · +> Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list +> +> database. +> +> Page  131  of  159 +> +> ![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present +> +> to  the  system. +> +> AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the +> +> frequency,  and  present  to  the  system. +> +> FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, +> +> and  present  to  the  system. +> +> AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following +> +> information: +> +> · Station  name  (FM  and  HD  only) +> +> · Frequency +> +> · Status  of  HD  (HD,  HD1,  HD2) +> +> · HD  SIS  (HD  only) +> +> AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: +> +> · Favourite  station  changed +> +> · Favourite  station  is  removed +> +> · New  favourite  is  added +> +> **5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** +> +> Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from +> +> applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and +> +> LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of +> +> VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main +> +> functions. +> +> · Vehicle  Data  Processing +> +> · Communication  between  ECUs +> +> · Vehicle  Data  Upload +> +> Page  132  of  159 +> +> ![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · Simulator +> +> **Figure  7-27  :  Overview  of  Vehicle  Info  Control** +> +> **5.2.11.1  Vehicle  Data  Processing** +> +> Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, +> +> personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application +> +> and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. +> +> · +> Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature +> +> · User  Information,  such  as  a  name,  taste,  etc.  of  a  driver +> +> · The  operation  history  of  a  driver +> +> Page  133  of  159 +> +> ![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · +> The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle +> +> conditions,  such  as  speed  and  day  and  night +> +> Vehicles  data  processing  consists  of  the  following  functional  elements  further. +> +> (1)  Abstraction  of  Vehicles  Data +> +> In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind +> +> of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving +> +> speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for +> +> application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles +> +> data  of  the  same  implications  and  the  same  unit. +> +> (2)  Maintenance  of  Vehicles  Data +> +> Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past +> +> value  (history). +> +> (3)  Application  /  Middleware  Interface  (API) +> +> The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. +> +> Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and +> +> the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data +> +> restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance +> +> (access  control). +> +> (4)  Vehicles  Interface +> +> It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN +> +> and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the +> +> exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. +> +> However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more +> +> Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In +> +> addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. +> +> **5.2.11.2  Communications  between  ECUs** +> +> Page  134  of  159 +> +> ![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +> +> ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +> +> vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +> +> middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +> +> acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +> +> which  each  ECU  can  access. +> +> **5.2.11.3  Vehicle  Data  Upload** +> +> When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +> +> ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +> +> vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +> +> middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +> +> acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +> +> which  each  ECU  can  access. +> +> **5.2.11.4  Simulator** +> +> In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is +> +> unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes +> +> development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel +> +> controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be +> +> an  option. +> +> **5.2.11.5  Requirements** +> +> The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application +> +> and/or  middleware  can  access  vehicle  information. +> +> The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract +> +> property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but +> +> the  speed  of  a  car. +> +> System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. +> +> Page  135  of  159 +> +> ![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  must  support  typical  vehicle  property  as  “standard  property”. +> +> As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. +> +> System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. +> +> A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard +> +> property. +> +> Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) +> +> The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or +> +> middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough +> +> as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile +> +> display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. +> +> A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is +> +> stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the +> +> load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and +> +> spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. +> +> It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In +> +> corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. +> +> · +> The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the +> +> accumulated  newest  value  is  less  than  a  threshold  value. +> +> · +> Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the +> +> newest  accumulation. +> +> About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need +> +> to  be  able  to  set  up  easily. +> +> In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. +> +> System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property +> +> access. +> +> System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or +> +> middleware. +> +> Page  136  of  159 +> +> ![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Below  attributes  must  include  in  this  interface +> +> · Zone(optional) +> +> · Property  name +> +> · Value +> +> · +> Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +> +> System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application +> +> and/or  middleware. +> +> Below  attributes  must  include  in  this  interface. +> +> · Zone(optional) +> +> · Property  name +> +> · Value +> +> System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from +> +> application  and/or  middleware. +> +> When  status  changed,  system  must  invoke  callback  function  with  below  attributes. +> +> · Zone(optional) +> +> · Property  name +> +> · Value +> +> · Timestamp +> +> · Sequence  number +> +> Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +> +> Sequence  number  is  useful  to  check  event  order. +> +> The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of +> +> change  of  vehicle  information. +> +> In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an +> +> acceptable  value  even  if  vehicle  information  changes. +> +> For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the +> +> application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of +> +> change. +> +> Page  137  of  159 +> +> ![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. +> +> · +> The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the +> +> value  from  the  last  notice  of  change  is  less  than  specification. +> +> · +> Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a +> +> definite  period  of  time,  it  does  not  notify. +> +> Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the +> +> time  of  change. +> +> What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified +> +> notice  interval  is  made  possible. +> +> The  data  stored  is  acquired  collectively. +> +> Below  attributes  must  include  in  this  interface. +> +> · Zone(optional) +> +> · Property  name +> +> · Values +> +> · Timestamps +> +> It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 +> +> seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. +> +> There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual +> +> in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed +> +> simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the +> +> newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to +> +> recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information +> +> relevant  to  mutual  and  to  access  it. +> +> Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle +> +> information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, +> +> and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all +> +> those  vehicle  information  at  the  time  of  reference. +> +> The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. +> +> Or  the  thing  which  can  be  changed  from  a  program  during  operation. +> +> Page  138  of  159 +> +> ![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property +> +> "velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be +> +> accessed  from  all  applications. +> +> System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same +> +> property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only +> +> application  C  can  set  this  property. +> +> Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control +> +> policy  may  be  different  per  car  type,  grade  and  destination. +> +> System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU +> +> and  across  two  or  more  ECU’s. +> +> If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, +> +> middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, +> +> the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware +> +> which  exist  in  a  different  ECU. +> +> VIC  can  be  requested  to  set  the  value  specified  as  Property. +> +> It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. +> +> The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand +> +> from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. +> +> Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application +> +> responds. +> +> It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed +> +> easily. +> +> The  data  exchange  between  ECUs  should  be  permitted  by  VIC. +> +> All  data  transmission  and  reception  from  other  Software  Component  are  refusing. +> +> Page  139  of  159 +> +> ![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. +> +> The  vehicle  information  to  upload  is  being  able  to  choose. +> +> A  selection  condition  is  that  the  following  specification  is  possible  at  least. +> +> · Date-and-time  range +> +> · Object  vehicles  data +> +> · The  change  threshold  value  of  vehicles  data +> +> Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be +> +> able  to  change  dynamically  from  an  external. +> +> The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as +> +> substitution  of  actual  vehicles  in  development  environment  is  prepared. +> +> Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing +> +> activities  through  a  vehicles  interface  function  at  least. +> +> · Speed +> +> · Shift  position +> +> · The  direction  of  vehicles +> +> · Latitude  and  longitude  of  a  current  position +> +> · Turn  signal +> +> The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, +> +> it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. +> +> VIC  should  fill  the  following  performance  specifications  and  performance. +> +> It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +> +> information  machines  and  equipment  in  2016. +> +> Page  140  of  159 +> +> ![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · Maximum  number  of  properties  :  4,096 +> +> · Maximum  number  of  property  sets:  1,024 +> +> · Greatest  data  storage  time :  12  hours +> +> It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +> +> information  machines  and  equipment  in  2016. +> +> · Get/Set  method(one  property)  -  0.2ms +> +> · Get/Set  method(property  set  include  30  properties)  -1.3ms +> +> · Subscribe  callback  -  2.5ms  (after  change  of  a  value) +> +> · +> GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms +> +> · +> GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms +> +> VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility +> +> about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and +> +> attribute  of  vehicles  data. +> +> Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by +> +> various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add +> +> and  change  Vehicle  Interface  without  reconstruction  of  VIC. +> +> Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is +> +> necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. +> +> However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness +> +> vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more +> +> concreteness  vehicles  data  into  one  abstract  vehicles  data. +> +> Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be +> +> mounted  in  the  VIC  itself. +> +> In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be +> +> added  without  reconstruction  of  VIC  is  prepared  for  VIC. +> +> **5.2.12  Telematics  Services** +> +> V2V,  V2I,  RVI,  Traffic  information,  etc. +> +> Page  141  of  159 +> +> ![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> **5.2.13  Window  System** +> +> A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +> +> interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +> +> Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +> +> component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +> +> and  a  routing  of  user  interactions. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple +> +> processes  to  be  rendered  on  a  display. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to +> +> achieve  flicker  less  rendering. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- +> +> screen  buffers. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying +> +> objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. +> +> AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos +> +> group  available  to  clients  for  their  rendering. +> +> AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +> +> APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by +> +> configuration. +> +> AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the +> +> *underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a +> +> Page  142  of  159 +> +> ![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The +> +> window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES +> +> 2.0  API  are  responsible  for  a  hardware  abstraction. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple +> +> displays. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, +> +> where  available. +> +> AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware +> +> acceleration  capabilities. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs +> +> from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a +> +> vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the +> +> vehicle  reaches  to  the  certain  speed. +> +> AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, +> +> a  touch  panel,  a  control  knob  etc. +> +> AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input +> +> from  available  physical  input  devices. +> +> **6   Security   Services** +> +> Security  framework +> +> 6.1  Access  Control +> +> Access  Control  describes  requirements  for  AGL  Access  Control. +> +> Page  143  of  159 +> +> ![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. +> +> **6.1.1  Requirements** +> +> AGL  system  must  support  a  system-wide  access  control  mechanism. +> +> **7   Operating   System   Layer** +> +> 7.1  Kernel +> +> **7.1.1  Linux  Kernel** +> +> Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new +> +> release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years +> +> for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and +> +> kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the +> +> rest  of  the  open  source  community  provides, +> +> **7.1.1.1  Requirements** +> +> AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. +> +> At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive +> +> industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully +> +> aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by +> +> Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to +> +> accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to +> +> regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with +> +> the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. +> +> AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on +> +> particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. +> +> Page  144  of  159 +> +> ![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 7.2  Boot  Loader +> +> 7.3  Hypervisor +> +> TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level +> +> virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI +> +> systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android +> +> and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on +> +> top  type1  hypervisor. +> +> **7.3.1  Requirements** +> +> AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that +> +> have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The +> +> processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. +> +> AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following +> +> functionality  shall  be  supported  by  AGL  Linux  “guest”: +> +> · IPC  (with  hypervisor  and  other  “guests”) +> +> · +> “paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless +> +> virtualization  abstraction  is  supported  by  hardware) +> +> 7.4  Operating  System +> +> **7.4.1  File  Systems** +> +> File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability +> +> as  their  main  characteristics. +> +> · +> *Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, +> +> tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process +> +> environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management +> +> techniques. +> +> Page  145  of  159 + + ------------------------------------------------------------------------------- + > **FS  Requirements** > **R-FS  References** + ------------------------------------------------------ ------------------------ + > 6.  File  Systems  (P1) > 2.  btrfs + > > + > 6.1.  Robust  File  System  for  managed  internal > 2.1. + > > + > storage  (P1) > btr + > > + > 6.1.1.  Power  failure  tolerance  (P1) > fsc + > > + > 6.1.2.  Quick  recovery  after  power  loss > k + > > + > (P1) > 3.  ext2 + > > + > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. + > > + > 6.1.4.  On-demand  integrity  checker  (P1) > e2 + > > + > 6.1.5.  Read-only  mode  (P1) > def + > > + > 6.1.6.  Non-blocking  unmounting  (P1) > rag + > > + > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 + > > + > performance  if  it  may  degrade  under > 5.  ext4 + > > + > certain  conditions.  (P2) > 5.1. + > > + > 6.1.8.  File  space  pre-allocation  (P2) > e4 + > > + > 6.1.9.  Meta-data  error  detection  (P2) > def + > > + > 6.1.10.  File  data  error  detection  (P2) > rag + > > + > 6.1.11.  Online  integrity  checking  (P2) > 5.2. + > > + > 6.1.12.  Write  timeout  control  (P2) > e2f + > > + > 6.1.13.  Compression  support  (P2) > sck + > > + > 6.1.14.  Quota  support  (P2) > 6.  vfat + > > + > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS + > > + > 6.1.16.  File  system  event  notifications > 8.  Generic + > + > tools  and + > + > APIs + > + > 8.1. + > + > fan + ------------------------------------------------------------------------------- + +> ![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> · +> *Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing +> +> designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. +> +> · +> *Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual +> +> packages,  and  availability  of  file  system  checking  and  optimization  tools. +> +> ![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> (P2) +> +> 6.1.17.  Logical  block  size  control  (P2) +> +> 6.1.18.  Snapshots  (P2) +> +> 6.2.  File  System  for  non-managed  internal +> +> storage  (P1) + +May  28,  2015 + +otif + +y + +8.2. + +fst + +rim + +> 6.2.1.  All  P1  requirements  from +> +> FS.1.1.x  list  (P1) +> +> 6.2.2.  Wear  leveling  (P1) +> +> 6.2.3.  Error  detection/correction  (P1) +> +> 6.2.4.  Tolerance  to  flipping  bits  (P1) +> +> 6.2.5.  Read/write  disturb  awareness +> +> (P1) +> +> 6.2.6.  Bad  block  management  (P1) +> +> 6.2.7.  As  many  P2  requirements  from +> +> FS.1.1.x  list  as  possible  (P2) +> +> 6.2.8.  Wear  leveling  statistics  (P2) +> +> 6.3.  File  Systems  for  removable  storage  (P1) +> +> 6.3.1.  Restricted  functionality  from +> +> security  point  of  view  (P1) +> +> 6.3.2.  Automount/autounmount  (P1) +> +> 6.3.3.  Automatic  synchronous  flushing +> +> of  modified  data  to  physical  media  (P2) +> +> **7.4.1.1  Requirements** +> +> AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +> +> internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +> +> memory),  removable  managed  (USB  stick,  SD  card). +> +> AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, +> +> Page  147  of  159 +> +> ![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, +> +> AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. +> +> A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, +> +> and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. +> +> A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power +> +> interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should +> +> not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. +> +> Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- +> +> write)  operation. +> +> A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple +> +> threads  and/or  processes  simultaneously. +> +> A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. +> +> A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical +> +> storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” +> +> command. +> +> AGL  must  support  “lazy”  (delayed)  unmounting. +> +> AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged +> +> file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. +> +> Another  example  is  periodic  fstrim  execution  on  SSD  storage. +> +> A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This +> +> may  be  used  to  minimize  fragmentation  of  frequently  written  files. +> +> A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. +> +> Page  148  of  159 +> +> ![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored +> +> data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. +> +> A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. +> +> A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical +> +> media. +> +> A  file  system  should  support  automatic  data  compression. +> +> It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. +> +> AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. +> +> AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. +> +> Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O +> +> performance,  and  decrease  file  fragmentation  impact. +> +> A  file  system  should  allow  creation  of  snapshots. +> +> A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of +> +> erase/program  cycles  is  evenly  distributed  across  all  device  blocks. +> +> A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. +> +> A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also +> +> actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power +> +> interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the +> +> time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. +> +> A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb +> +> Page  149  of  159 +> +> ![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known +> +> techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a +> +> fresh  block  after  detected  error  correction. +> +> A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system +> +> users. +> +> Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. +> +> A  file  system  must  support  noexec,  and  nodev  mount  options. +> +> A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and +> +> automatically  unmount  it  when  unplugged. +> +> A  file  system  must  support  sync  mount  option. +> +> AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +> +> internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +> +> memory),  removable  managed  (USB  stick,  SD  card). +> +> **7.4.2  Resource  Control** +> +> In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be +> +> higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource +> +> allocation  for  each  process  and/or  process  group. +> +> (cgroups) +> +> **7.4.2.1  Use  Case  and  Role** +> +> If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current +> +> position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. +> +> On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned +> +> Page  150  of  159 + + ------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- -------------- ---------------------------------------------------------------- + > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority + > + > process  and/or  process  group  should  be  assigned + > + > more  resource. + + > 2 > Time  slot > To  share  resource  per  time  slot. + + > 3 > Release > Forced  release  of  partially  or  whole  allocated + > + > resource. + + > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate + > + > resource  per  defined  process  group. + ------------------------------------------------------------------------------------------- + +> ![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> to  higher  priority  than  others. +> +> Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at +> +> the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. +> +> Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. +> +> AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network +> +> bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. +> +> **Table  9-34  :  Functions  of  System  Resource  Management** +> +> **7.4.2.2  Requirements** +> +> 7.4.2.2.1  Priority +> +> System  provides  a  mechanism  to  set  resource  priority  per  each  process. +> +> Page  151  of  159 +> +> ![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. +> +> This  interface  must  be  called  from  other  process. +> +> CPU  resource  must  support  “priority”  based  resource  management. +> +> Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the +> +> status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. +> +> Resource  Manager  should  log  the  status  of  resources  using  by  system. +> +> Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of +> +> kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high +> +> priority  tasks. +> +> 7.4.2.2.2  Time  Slot +> +> When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a +> +> mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each +> +> processes. +> +> System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. +> +> System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage +> +> bandwidth  and  network  bandwidth. +> +> Scheduler  should  detect  the  status  of  resources  for  each  thread. +> +> Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. +> +> Scheduler  should  guarantee  that  threads  can  run  periodically. +> +> Scheduler  should  control  the  dispatches  that  occur  extremely. +> +> Page  152  of  159 +> +> ![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> 7.4.2.2.3  Release +> +> System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by +> +> specific  process. +> +> System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. +> +> 7.4.2.2.4  Grouping +> +> System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource +> +> management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same +> +> attributes  to  grouped  processes  altogether. +> +> System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. +> +> System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and +> +> network  bandwidth. +> +> **7.4.3  Startup/Shutdown  Control** +> +> Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a +> +> user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending +> +> on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which +> +> boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and +> +> “dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. +> +> **7.4.3.1  Use  Cases** +> +> (1)  Static  Modification  of  Boot/Shutdown  Order +> +> a. +> Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration +> +> To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown +> +> for  all  programs  running  on  the  target  device. +> +> Page  153  of  159 +> +> ![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> b. +> Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development +> +> In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed +> +> program  in  target  programs. +> +> c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update +> +> Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. +> +> (2)  Dynamic  Modification  of  Boot/Shutdown  Order +> +> a. +> Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using +> +> It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to +> +> be  operated  by  priority  when  ACC  turns  ON. +> +> b\. Prioritized  Boot  of  Update  Functionalities +> +> Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned +> +> ON. +> +> **7.4.3.2  Requirements** +> +> Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. +> +> Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that +> +> has  been  configured. +> +> Boot/Shutdown  Control  shall  start  independent  components  in  parallel. +> +> Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. +> +> Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that +> +> has  been  configured. +> +> Page  154  of  159 +> +> ![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. +> +> **7.4.4  Database** +> +> Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee +> +> database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system +> +> database  engine  is  rich  set  of  bindings  to  various  programming  languages. +> +> Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References +> +> hierarchy. +> +> 1.  Power  failure  tolerance  (P1) +> +> 2.  Quick  recovery  after  power  loss  (P1) +> +> 3.  Multi-threaded  I/O  (P1) +> +> 4.  API  bindings  for  C  programming  language +> +> 5.  On-demand  integrity  checker  (P2) +> +> DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write +> +> DB  transactions. +> +> DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. +> +> Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power +> +> failure  on  idle  system. +> +> DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or +> +> processes  simultaneously. +> +> DB  engine  API  must  be  available  for  C-based  applications. +> +> DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. +> +> DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power +> +> interruption  during  adding  some  data. +> +> Page  155  of  159 +> +> ![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, +> +> such  as  vehicle  information  database  and  databases  at  data  center. +> +> And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. +> +> Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption +> +> during  merging. +> +> **7.4.5  System  Update** +> +> Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are +> +> numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, +> +> bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to +> +> power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. +> +> System  Update  module  should  have  a  Robust  version  up  function. +> +> System  Update  moduleshould  have  a  system  difference  version  up  function. +> +> There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +> +> apt  of  Linux  distribution). +> +> There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +> +> apt  of  Linux  distribution). +> +> Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. +> +> If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should +> +> be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. +> +> If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during +> +> update)  should  be  detected  and  the  system  should  restart. +> +> Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. +> +> Page  156  of  159 +> +> ![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> Memory  usage  for  difference  update  should  be  maximum  1Mbyte. +> +> Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. +> +> System  Update  moduleshould  have  full  version  up  function  for  whole  system. +> +> Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow +> +> mass  update. +> +> There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. +> +> If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +> +> application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +> +> If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +> +> application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +> +> 7.5  Device  Drivers +> +> Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. +> +> **7.5.1  Peripherals** +> +> Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. +> +> The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and +> +> data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For +> +> optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less +> +> than  50  s/byte  average. +> +> The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles +> +> and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or +> +> EEPROM  is  not  allowed. +> +> Page  157  of  159 +> +> ![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be +> +> fast.  (target  <1ms/byte) +> +> N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. +> +> **7.5.2  Graphics  Drivers** +> +> Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. +> +> This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. +> +> **7.5.3  Video  Drivers** +> +> Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video +> +> codecs  will  nearly  always  be  hardware  based. +> +> **7.5.3.1  Requirements** +> +> The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video +> +> functionality. +> +> **7.5.4  Audio  Codecs** +> +> **7.5.4.1  Requirements** +> +> Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are +> +> implemented  in  hardware. +> +> Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs +> +> that  are  required  for  AGL-based  products  and  not  supported  in  hardware. +> +> **7.5.5  Automotive  Devices** +> +> Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or +> +> *LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* +> +> Page  158  of  159 +> +> ![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 +> +> May  28,  2015 +> +> required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for +> +> navigation  or  an  air  bag  sensor  for  a  telematics  system. +> +> **8   Notices** +> +> Linux  is  a  registered  trademark  of  Linus  Torvalds. +> +> The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. +> +> Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. +> +> Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. +> +> MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. +> +> AirPlay  is  a  trademark  of  Apple,  Inc. +> +> Page  159  of  159 diff --git a/docs/agl-specs-v1.0/00-doorsNG-skimed.md b/docs/agl-specs-v1.0/00-doorsNG-skimed.md new file mode 100644 index 0000000..c5ffbd5 --- /dev/null +++ b/docs/agl-specs-v1.0/00-doorsNG-skimed.md @@ -0,0 +1,4203 @@ +--- +# Master Header for Jkyll +--- + +![](media/picture8.jpeg)![](media/picture9.jpeg)Version   1.0 +Automotive Grade Linux +Requirements Specification +May   28,   2015 +www.automotivelinux.org +www.linuxfoundation.org +![](media/picture10.jpeg)Automotive Grade Linux Requirements Spec v1.0 +![](media/picture94.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**1   Automotive   Grade   Linux** +1.1  Overview +Automotive  Grade  Linux  (AGL)  is  a  Linux  Foundation  Workgroup  dedicated  to  creating  open +source  software  solutions  for  automotive  applications.  Although  the  initial  target  for  AGL  is  In- +Vehicle-Infotainment  (IVI)  systems,  additional  use  cases  such  as  instrument  clusters  and  and +telematics  systems  will  eventually  be  supported.  AGL  has  participants  from  the  Automotive, +Communications,  and  Semiconductor  Industries  and  welcomes  contributions  from  individual +developers. +By  leveraging  the  over  \$10B  of  investment  made  in  the  Linux  kernel  and  other  open  source +software  projects,  the  AGL  Workgroup: +· +Enables  rapid  software  innovation  for  automotive  suppliers  to  keep  up  with  the  demand +from  consumers  for  better  IVI  experiences +· +Utilizes  the  talents  of  thousands  of  open  source  software  developers  dedicated  to +maintaining  the  core  software  in  areas  like  the  Linux  kernel,  networking,  and +connectivity,  used  in  systems  across  numerous  industries +The  goals  of  the  Automotive  Grade  Linux  Workgroup  are  to  provide: +· +An  automotive-focused  core  Linux  operating  system  stack  that  meets  common  and +shared  requirements  of  the  automotive  ecosystem  with  a  broad  community  of +support  that  includes  individual  developers,  academic  organizations  and  companies. +· +A  transparent,  collaborative,  and  open  environment  for  Automotive  OEMs,  Tier  One +suppliers,  and  their  semiconductor  and  software  vendors  to  create  amazing  in-vehicle +software. +· +A  collective  voice  for  working  with  other  open  source  projects  and  developing  new  open +source  solutions. +· +An  embedded  Linux  distribution  that  enables  rapid  prototyping  for  developers  new  to +Linux  or  teams  with  prior  open  source  experience +This  results  in  faster  time  to  market  by  jump-starting  product  teams  with  reference  applications +running  on  multiple  hardware  platforms. +Page  5  of  159 + + > **Term** > **Definition** + ------------ ------------------------------------------ + > A2DP > Advanced  Audio  Distribution  Profile + > AGL > Automotive  Grade  Linux + > AVRCP > Audio  Video  Remote  Control  Profile + > FS > File  System + > GPS > Global  Positioning  System + > GPU > Graphical  Processing  Unit + +![](media/picture95.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +1.2  Document  Scope +The  scope  of  this  document  is  to  define  the  architecture  of  the  Automotive  Grade  Linux  software +platform.  The  requirements  are  broken  up  into  an  overview  of  the  Architecture  and  a  description +of  each  of  the  layers  in  the  architecture  followed  by  the  requirements  for  each  module  in  the +various  layers.  The  Architecture  Diagram  and  the  layout  of  the  specification  take  into +consideration  all  of  the  components  that  would  be  needed  for  an  IVI  system;  however  the  are +missing  requirements  for  individual  modules.  As  the  spec  continues  to  evolve  those  sections  will +continue  to  be  filled  in. +The  main  goal  of  this  document  is  to  define  the  core  software  platform  from  which  applications +can  be  built.  As  such,  this  document  does  not  define  application  requirements  except  in  a  single +case  (Home  Screen).  Application  requirements  will  be  developed  by  various  projects  that  use  the +AGL  platform.  Those  application  requirements  can  be  used  to  drive  new  or  revised +requirements  into  the  platform. +At  this  time  there  is  no  plan  to  use  this  specification  to  create  a  compliance  or  certification +program.  The  specification  is  used  as  blueprint  to  guide  the  overall  work  of  AGL  and  to  derive +work  packages  for  companies  and  individuals  to  complete  in  order  to  attain  the  goals  of  the  AGL +Workgroup. +1.3  Glossary  of  Terms + + > HFP > Hands  Free  Profile + -------- ------------------------------------- + > IBOC > In-Band  On  Channel + > LTSI > Long  Term  Support  Initiative + > NTP > Network  Time  Protocol + > OEM > Original  Equipment  Manufacturer + > OS > Operating  System + > OSS > Open  Source  Software + > SDL > Smart  Device  Link + > STT > Speech  to  Text + > TTS > Text  to  Speech + +![](media/picture96.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**2   Architecture** +The  Automotive  Grade  Linux  Software  Architecture  diagram  is  below.  The  architecture  consists +of  five  layers.  The  App/HMI  layer  contains  applications  with  their  associated  business  logic  and +HMI.  Generally  applications  are  out  of  scope  for  this  document  since  they  are  product  specific +for  the  OEM  that  is  developing  a  system  based  on  AGL. +The  Application  Framework  layer  provides  the  APIs  for  creating  both  managing  and  running +applications  on  an  AGL  system.  The  Services  layer  contains  user  space  services  that  all +applications  can  access.  The  Operating  System  (OS)  layer  provides  the  Linux  kernel  and  device +drivers  along  with  standard  OS  utilities. +Page  7  of  159 +![](media/picture97.jpeg)![](media/picture98.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**3   App/HMI   Layer** +Applications  may  use  a  web  based  framework  or  a  native  framework.  A  system  may  include +applications  that  use  different  frameworks.  Coordination  of  applications  between  frameworks  is +performed  by  the  AGL  App  Framework.  The  diagram  represents  possible  applications  that  could +appear  in  a  given  system,  but  is  not  all  inclusive.  Reference  applications  may  be  provided  by  AGL +Page  8  of  159 +![](media/picture99.jpeg)![](media/picture100.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  demonstrate  the  capabilities  of  the  platform. +3.1  Home  Screen +Home  Screen  provides  the  Home  User  Interface  (Home  UI)  of  the  system  which  meets  the +following  requirements: +· Rich  User  Experience  (Rich  UX) +· Driver  Distraction  mitigation +· Variations  support +Rich  UX  covers  requirements  such  as  usability  and  user  satisfaction.  Driver  Distraction  mitigation +covers  requirements  on  display  control  and  user  operation  behavior  while  vehicle  is  in  motion  to +minimize  driver  distraction.  Variations  support  covers  requirements  to  support  customization  of +design  and  behavior  of  the  system  to  meet  the  different  needs  of  vehicle  type,  destination  and +grade. +**3.1.1  Layout** +The  following  use  cases  are  considered  for  Layout. +· +Home  Screen  developer  changes  the  Home  UI  by  using  a  customizable  layout  definition. +Page  9  of  159 +![](media/picture101.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**3.1.2  System  UI  Parts** +The  use  case  assumed  about  System  UI  Parts  is  as  follows. +· +An  application  or  System  uses  status  bar  and  on-screen  in  order  to  notify  information  to +a  user. +· +User  uses  the  system  setting  UI  in  order  to  change  settings. +· User  uses  software  keyboard  in  order  to  input  characters. +**3.1.3  Application  Management** +The  use  case  assumed  about  Application  Management  is  as  follows. +· +A  user  downloads  and  installs  or  updates  the  delivery  application  from  application  store. +· A  user  uninstalls  the  delivery  application. +· +A  user  launches  the  installed  delivery  application  or  the  pre-installed  application. +· Also  a  user  terminates  those  applications. +**3.1.4  Application  Switch** +The  use  case  assumed  about  Application  Switch  is  as  follows. +· +User  switches  application  via  application  history  or  application  stack. +· +The  system  switches  application  according  to  Driving  Mode  status. +**3.1.5  Application  History** +Application  switching  by  application  history  is  assumed  as  follows. +· +The  system  records  the  order  of  the  applications  in  the  order  in  which  the  application  is +displayed. +· +The  order  of  application  that  is  recorded  is  updated  each  time  the  display  of  the +application  is  switched. +· +Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the +history  at  the  time  of  switching  applications. +Page  10  of  159 +![](media/picture102.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +‑  Specification  of  operation +-  User  runs  a  swipe  from  the  edge  of  the  application  screen  area. +‑  Specification  of  action +-  The  order  of  the  screen  is  managed  order  management  list  (application  history). +-  List  order  update  opportunity(Update  has  determined  a  display  of  the  application) +-  Application  starts  or  stops. +-  Allowed  to  stand  between  the  screen  N  seconds  after  the  swipe. +‑"N  seconds"‑User  defines  the  value  of  any. +-  User  to  operate  the  screen  after  you  swipe. +‑"operation"‑Screen  tap.  Menu  display.  Other. +Figure  5‑2  represents  a  sample  Home  Screen  depicting  the  above  mentioned  use  cases. +Page  11  of  159 +![](media/picture103.jpeg)![](media/picture104.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**3.1.6  Application  Stack** +Application  switching  by  application  stack  is  assumed  as  follows. +· +The  user  specifies  the  type  of  any  order.  The  system  records  the  order  of  the  application +to  the  rule  as  of  the  specified  type. +· Examples  of  the  types  of  any  order +· Application  start-up  order +· +Screen  of  the  application  is  displayed  in  the  order  in  which  they  are  recorded  in  the  stack +Page  12  of  159 +![](media/picture105.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +when  switching  applications. +‑  Specification  of  operation +· +User  runs  a  swipe  from  the  edge  of  the  application  screen  area. +‑  Specification  of  action +· +The  order  of  the  screen  is  managed  order  management  list  (application  stack). +· +List  order  update  opportunity.(Application  start-up  order  as  an  example) +· +Application  that  started  at  the  end  of  the  list  when  the  application  is  started  is  added. +· +Application  that  has  stopped  from  the  list  when  the  application  is  stopped  will  be +deleted. +Figure  5-3  represents  the  switching  example  depicting  the  application  of  the  above  switching. +Page  13  of  159 + + -------------------------------------------------------------------------------------- + > **No** > **Use  Case** > **Role** > **Description** + ---------- ----------------- --------------- ----------------------------------------- + > 1-1 > Layout > GUI  Layout > Function  to  define  a  customizable + > > + > definition > GUI  Layout  definition. + -------------------------------------------------------------------------------------- + +![](media/picture106.jpeg)![](media/picture107.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**3.1.7  Role  of  Home  Screen** +Table  5-1  describes  the  role  of  the  Home  Screen  to  satisfy  the  purpose  and  use  cases +Page  14  of  159 + + ---------------------------------------------------------------------------------------------------- + > 1-2 > Change  Layout > Function  to  apply  the  customized + > + > GUI  layout  definition. + ------- --------------------- ------------------------ --------------------------------------------- + > 2-1 > System  UI  Parts > Status  Bar > Function  to  display  the + > + > information  from  application  or + > + > system. + > + > Function  to  quickly  access  and  set + > + > certain  system  settings. + + > 2-2 > On-screen > Function  to  display  a  popup + > + > window  such  as  alert  messages. + + > 2-3 > System  Setting > Function  to  display  system + > + > settings  menu  regarding  GUI, + > + > such  as  locale  and  network. + + > 2-4 > Software > Function  to  display  software + > > + > Keyboard > keyboard. + + > 3-1 > Application > Application > Function  to  download + > > > + > Management > Management > applications  from  application + > + > store.  Function  to  install,  uninstall + > + > and  update  the  downloaded + > + > applications. + + > 3-2 > Application > Function  to  launch/terminate + > > + > Launcher > applications. + + > 4-1 > Application > Application  List > Function  to  switch  applications  by + > > + > Switch > installed  application  list. + + > 4-2 > Application  History > Function  which  switches + > + > application  in  order  by + > + > applications  history. + + > 4-3 > Application  Stack > Function  to  switch  application  in + > + > any  order. + ---------------------------------------------------------------------------------------------------- + +![](media/picture108.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Table  5-2:  Relevance  of  the  Role  and  Purpose** +Page  15  of  159 + + ----------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Rich  UX** > **Driver** > **Variations** + > > + > **Distraction** > **support** + > + > **mitigation** + ----------- --------------------------- ---------------- ------------------- ------------------ + > 1-1 > GUI  Layout  definition > ‑ > ‑ > ‑ + + > 1-2 > Change  Layout > ‑ > ‑ > ‑ + + > 2-1 > Status  Bar > ‑ > ‑ + + > 2-2 > On-screen > ‑ > ‑ + + > 2-3 > System  Setting > ‑ > ‑ + + > 2-4 > Software  Keyboard > ‑ > ‑ + + > 3-1 > Application  Management > ‑ > ‑ + + > 3-2 > Application  Launcher > ‑ > ‑ + + > 4-1 > Application  List > ‑ > ‑ + + > 4-2 > Application  History > ‑ > ‑ + + > 4-3 > Application  Stack > ‑ > ‑ + ----------------------------------------------------------------------------------------------- + +![](media/picture109.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**3.1.8  Requirements** +**3.1.8.1  Layout** +Home  Screen  must  provide  a  mechanism  for  customizable  GUI  layout  definition  by  each  vehicle +type,  each  destination  and  each  grade. +Home  Screen  must  provide  a  mechanism  for  a  customizable  GUI  layout  definition  for  different +vehicle  type,  destination  and  grade. +GUI  layout  definitioncan  be  definedsuch  as  the  following  items: +(In  addition,  items  that  can  be  defined  is  not  limited  to  the  following.) +· screen  resource  (Display,  Layer  Type,  Area) +Page  16  of  159 +![](media/picture110.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· sound  resource  (Zone,  Sound  Type) +· input  resource  (Device,  Event  Type) +· UI  Component  to  be  used  in  the  entire  system +· transition  effect  (Animation  effect) +· Background  image +Home  Screen  must  provide  a  mechanism  to  apply  customized  GUI  layout  definition. +**3.1.8.2  System  UI  Parts** +Home  Screen  must  provide  a  mechanism  to  display  two  or  more  information  simultaneously  to +the  status  notification  area. +Home  Screen  must  provide  a  mechanism  to  displaying  status  to  status  notification  area. +· Current  Time:  Displaying  clock  capability +· +Icons  of  Status:  Displaying  icons  for  notify  information  from  applications +· +Status  Message:  Displaying  text  for  notify  information  from  applications +· +Communication  Status:  Status  of  mobile  communication  and  wireless  communications +(Wi-Fi,  Bluetooth,  etc.) +Home  screen  must  provide  an  interface  to  retrieve  information  from  application  for  notification. +Home  Screen  must  provide  a  mechanism  to  show  popup  window  into  on-screen  window. +Home  Screen  must  provide  GUI  method  to  hide  on-screen  window  by  user  operation. +Home  Screen  must  provide  a  mechanism  to  hide  on-screen  window  within  a  specified  duration. +Home  Screen  must  provide  an  interface  for  applications  to  request  to  show  popups. +Home  Screen  must  provide  an  interface  for  applications  to  cancel  the  previously  requested +popup. +Page  17  of  159 +![](media/picture111.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Home  Screen  must  provide  a  mechanism  to  show  text  information,  draw  images  and  show +software  switch  like  button  in  the  on-screen  window. +Home  Screen  must  provide  a  mechanism  to  specify  attributes  such  as  position  and  size  of  On- +screen  window. +Home  Screen  must  support  a  mechanism  to  specify  other  window  display  effect  when  the  On- +screen  window  is  displayed.  (e.g.  tone  down) +Home  Screen  must  provide  system  setting  menu  regarding  GUI,  such  as  locale  and  network. +Home  Screen  must  provide  a  mechanism  to  change  current  date  and  time  setting. +Home  Screen  must  provide  a  mechanism  to  change  timezone  setting. +· +The  platform  must  set  up  the  date,  time  and  timezone  according  to  a  current  position +automatically. +· +Home  Screen  must  provide  a  mechanism  to  set  up  turning  on  and  off  of  the  automatic +date/time/timezone  setup. +Home  Screen  must  provide  a  mechanism  to  change  language  setting. +Home  Screen  must  provide  a  mechanism  to  change  wireless  communications  (Wi-Fi,  Bluetooth, +etc.)  setting. +· Enable/Disable +· Connect/Disconnect +· Search  the  devices +· Display  the  list  of  available  and/or  registered  devices +Home  Screen  must  provide  a  mechanism  to  change  mobile  communication  setting. +· Enable/Disable +Page  18  of  159 +![](media/picture112.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· A  setup  and  change  of  various  attributes +· Display  the  list  of  registered  devices  and  select  device +HomeScreen  must  support  to  change  the  appearance  of  a  screen  to  a  user's  liking. +These  are  as  follows. +· Tone  of  a  screen. +· Appearance  of  a  window  frame. +· Animation  effect  when  screen  transition  was  occurred. +Home  Screen  must  support  a  mechanism  to  set  or  change  master  audio  volume. +Home  Screen  must  support  a  mechanism  to  set  or  change  display  brightness. +Home  Screen  must  provide  a  mechanism  to  show  software  keyboard. +Home  Screen  must  provide  a  mechanism  to  apply  default  settings  (e.g.  theme,  local,  wallpaper) +to  a  new  user,  when  a  user  is  added  by  the  User  Manager. +**3.1.8.3  Application  Management** +Home  Screen  must  provide  a  mechanism  to  manage  downloaded  application  package. +· Display  downloaded  application  list  from  application  store. +· Download  the  application +· Install  the  downloaded  application +· Uninstall  the  downloaded  application +· Update  the  downloaded  application +Home  Screen  must  provide  a  mechanism  to  launch  the  application. +Home  Screen  must  provide  a  mechanism  to  terminate  the  application. +Page  19  of  159 +![](media/picture113.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**3.1.8.4  Application  Switch** +Home  Screen  must  provide  a  mechanism  to  show  the  list  of  installed  applications. +Examples  of  assumed  application  list +· list  of  application  name +· list  of  application’s  icon +· list  of  live  thumbnail  for  all  the  running  applications +Home  Screen  must  provide  a  mechanism  for  switching  display  application  in  order  by  application +history. +Home  Screen  must  provide  a  mechanism  for  the  application  stack  in  any  order.  For  example, +such  as  launch  order  or  display  order. +Home  Screen  must  provide  a  mechanism  for  the  system  to  switch  applications. +For  example,  when  Driving  Mode  changes,  system  must  be  able  to  switch  application  based  on +policy. +**4   Application   Framework   Layer** +The  Application  Framework  layer  provides  the  methods  needed  to  create  software  applications +and  their  user  interfaces.  The  platform  can  support  multiple  application  frameworks  any  of +which  may  be  built  into  an  SDK  or  product  build.  The  application  framework  contains  any  code +specifically  written  for  that  framework  as  well  the  bindings  to  the  Services  and  Operating +Systems  layers  that  the  application  framework  provides  for  its  applications. +4.1  AGL  Application  Framework +The  AGL  Application  Framework  provides  basic  services  to  all  applications  regardless  of  the +framework  they  are  implemented  in  so  that  there  is  a  standard  method  providing  the  services. +Page  20  of  159 +![](media/picture114.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**4.1.1  Application  Manager** +Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application +lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. +**4.1.1.1  Requirements** +AGL  System  must  support  application  lifecycle  (install/uninstall,  launch/kill,  suspend/resume)  based  on +appid/pid  via  launcher. +AGL  System  must  support  a  database  to  store  application  metadata  (appid,  exec  path  etc.). +AGL  System  must  provide  an  interface  to  get  a  list  of  installed  applications. +AGL  System  must  provide  an  interface  to  get  the  state  of  an  application. +AGL  System  must  provide  application  privilege  control. +**4.1.2  Window  Manager** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user  interface.  A +window  system  is  responsible  for  managing  display  devices,  Graphics  Processing  Units  (GPUs),  input +devices,  and  graphics  memory.  A  window  system  works  with  the  software  component  named  window +manager  that  is  responsible  for  a  layout  management  of  windows,  and  a  routing  of  user  interactions. +A  window  manager  is  as  software  component  that  is  responsible  for  a  layout  management  of +windows. +Window  manager  of  automotive  middleware  layer  makes  up  for  traditional  window  management +system  to  be  satisfied  IVI’s  complex  requirements,  typically  requested  from  Policy  Manager. +Also,  AGL  aims  to  provide  well-portability  among  various  hardware  platforms. +Page  21  of  159 + + -------------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- ----------------------------- -------------------------------------------------------------- + > 1 > Window  drawing > Provide  capability  to  draw  a  window  to  any  place + > + > and  any  size  and  any  scale. + > + > Also  provide  capability  to  change  visibility  of  the + > + > window. + + > 2 > Overlay  of  multiple > Provide  capability  to  overlay  two  or  more  windows + > > + > windows > with  any  z-order. + > + > Also  provide  capability  to  use  hardware  layer + > + > efficiently. + + > 3 > Visual  effect > Provide  capability  to  adapt  visual  effect  as  below. + > + > ·     Animation  effect  to  change  visibility + > + > ·     Animation  effect  to  transit  between  two  or + > + > more  windows + > + > ·     Visual  effect  for  a  window,  such  as  gray-out + > + > and  transparent. + + > 4 > Frame  rate  control > Provide  capability  to  control  dynamic  frame  rate + > + > change.  This  is  useful  if  system  resource  was + > + > shortage. + + > 5 > Multiple  hardware  layer > Provide  capability  to  use  hardware  layer  efficiently + > > + > support > if  hardware  supports  two  or  more  hardware  layers. + -------------------------------------------------------------------------------------------------------- + +![](media/picture115.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**4.1.2.1  Use** **Case** +Please  refer  “screen  resource  control”  of  Policy  Manger  section. +**4.1.2.2  Role** +Table  7-148  describes  the  role  of  window  manager  to  be  satisfied  above  purpose  and  use +cases. +Page  22  of  159 + + ---------------------------------------------------------------------------------------------- + > 6 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce + > > + > hardware > dependency  of  hardware.  Well-defined  interface + > + > also  makes  it  possible  to  increase  the  effect  of + > + > portability  and  development  cost. + ----- --------------------------- ------------------------------------------------------------ + > 7 > Multi  window  /  multi > Support  multi  window  management  and  multi + > > + > display > display. + + > 8 > Compatibility > From  the  compatibility  point  of  view,  AGL  should + > + > use  public  API,  and  shall  not  rely  on  hardware + > + > specific  API. + ---------------------------------------------------------------------------------------------- + +![](media/picture116.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**4.1.2.3  Requirements** +4.1.2.3.1  Window  Drawing +System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and +make  invisible. +System  must  provide  a  mechanism  to  create  and  delete  surface. +When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. +This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. +System  must  provide  a  mechanism  to  change  visibility  per  each  surface. +And,  provide  an  interface  to  change  visibility. +All  the  surfaces  must  be  set  to  invisible  for  initial  state. +Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. +System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between +previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. +*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt +Page  23  of  159 +![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +from  size  of  surface. +If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  squeeze. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  using  combination  of  scaling  and  trimming  function. +That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  using  combination  of  scaling  and  background  color. +That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This +mechanism  makes  it  possible  to  do  “letterbox”  method. +4.1.2.3.2  Overlay  of  Multiple  Windows +System  must  provide  a  mechanism  to  create  and  delete  a  layer. +Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by +their  z-order  attribute. +Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, +then,  attached  layer  must  be  changed. +System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. +Area  is  a  concept  which  defines  where  to  display  in  specific  layer. +System  must  provide  a  mechanism  to  attach  surface  to  any  layer. +Also,  system  must  be  able  to  change  attached  layer. +And,  provide  an  interface  to  attach  and  change. +Page  24  of  159 +![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. +And,  provide  an  interface  to  assign  surface  to  any  area. +System  must  provide  a  mechanism  to  change  visibility  per  each  layer. +That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the +same  time. +And,  provide  an  interface  to  change  visibility  per  layer. +Initial  state  must  be  set  to  invisible. +System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each +layer,  and  disposition  of  surfaces. +4.1.2.3.3  Visual  Affect +System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was +happened. +Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +- Duration +Animation  type +System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +out. +Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +plug-in  architecture. +System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. +Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +· Duration +Animation  type +System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +Page  25  of  159 +![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +out. +Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +plug-in  architecture. +System  must  provide  a  mechanism  to  make  effect  to  surface. +And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. +System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. +System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness +System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in +architecture. +4.1.2.3.4  Frame  Rate  Control +System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of +application. +System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval +of  application. +This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live +thumbnail  and  moving  surface. +4.1.2.3.5  Multiple  Hardware  Layer  Support +If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use +hardware  layers  efficiently. +· +Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers +Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback +4.1.2.3.6  Reduced  Dependency  of  Hardware +Page  26  of  159 +![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of +each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, +such  as  by  using  re-configuration. +4.1.2.3.7  Multi  Window +AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple +processes  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. +4.1.2.3.8  Compatibility +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a +standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any +hardware  specific  API. +A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. +**4.1.3  Policy  Manager** +**4.1.3.1  Overview** +4.1.3.1.1  Purpose +Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy +Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle +Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of +resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called +Page  27  of  159 +![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +“System  resources”  such  as  CPU  and  memory. +4.1.3.1.2  GUI  Resources +(1)  Definition +·  About  Control  of  GUI  Resources +AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, +speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user +or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. +**Figure  7-1:  GUI  resources** +Page  28  of  159 +![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy +Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too +much  information  distracts  the  attention  of  driver  from  driving  operations. +·  Associated  Software  Architecture +The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources +control  is  as  below. +**Figure  7-2:  Associated  Software  Expected  Use  Case** +Page  29  of  159 + + ----------------------------------------------------------------------------------------------------------------------------------------------------- + > **No** > **Component** > **Description** + > + > **.** + ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- + > 1 > Homescreen > Request  to  control  of  GUI  resources. + + > 2 > Applications > Request  to  output  or  input  of  GUI  resources. + + > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And + > + > then  provide  the  corresponding  feature  to + > + > applications  UI  such  as  input  limitation  and + > + > changing  the  theme. + + > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the + > + > definition  of  GUI  resources  such  as  role  by + > + > application  configurations. + + > 5- > Vehicle > Window  Manager + > > + > 1 > Info + > + > Control + + > 5- > Sound  Manager + > + > 2 + + > 5- > Input  Manager + > + > 3 + + > 5- > Vehicle  Info  Distributor + > + > 4 + + > 5- > User  Manager + > + > 5 + ----------------------------------------------------------------------------------------------------------------------------------------------------- + +![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  is  related  with  the  below  components. +(2)  Role +Page  30  of  159 + + ----------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ------------------------------ ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of + > > + > GUI  resource > GUI  resources. + > + > (2)  Judgment  the  GUI  resource  owner  according  to + > + > external  conditions. + + > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to + > + > judgment. + > + > (2)  Notify  the  driving  mode  and  day  night  mode + > + > that  is  calculated  by  external  conditions. + ----------------------------------------------------------------------------------------------------- + +![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  has  the  below  role. +Page  31  of  159 +![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  7-3:  Definition  of  Role** +GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each +resource  type  are  as  follows: +a.  Screen  Resource +a-1.  External  Condition  Collection +Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. +**Figure  7-4:  Definition  of  screen  resource** +•  Concept  of  Display,  Layer,  Layout  and  Area +AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one +or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout +Page  32  of  159 +![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics +window. +The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on +objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was +used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than +layer-2. +Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, +application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. +“Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and +setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert +and  enlarged  view. +When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On +the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” +layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. +From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- +order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered +by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to +individual  layer. +•  Concept  of  Layer  Owner,  Role  and  Surface +“Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of +that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of +area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy +Manager. +“Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” +change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. +One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics +window  to  display  into  one  area. +Page  33  of  159 +![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface +drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example +to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then +corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface +is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & +scan”. +**Figure  7-5:  Definition  of  Surface** +•  Subdivision  of  “Interrupt”  Layer +Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main +surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main +surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding +“Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message +is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. +According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described +as  Table  7-3. +Page  34  of  159 + + --------------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- -------------------------------------------------------- ----------------------- + > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation + > + > application  requests  this  layer  at  first  time. + + > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of + > + > navigation + + > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message + > > + > screen  service  (e.g.  Homescreen)  requests > popup + > + > this  layer. + + > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard + > > + > keyboard > Typically,  software  keyboard  service + > + > requests  this  layer. + --------------------------------------------------------------------------------------------------------- + + ------------------------------------------------------------------------------------------------------ + > **No** > **Contents** > **Summary** > **Example** + ---------- ---------------- ------------------------------------------------------- ------------------ + > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation + > + > service)  role. + + > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view + ------------------------------------------------------------------------------------------------------ + +![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +a-2.  Judgment  of  Priority  of  GUI  Resource +Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role +is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy +Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. +Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software +Page  35  of  159 +![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is +popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). +**Figure  7-6:  Definition  of  Role  and  Sub  role** +The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display +has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. +In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" +layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub +role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” +role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. +a-3.  GUI  resource  control +Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +directly. +Page  36  of  159 +![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +There  are  three  types  of  screen  resource  control: +One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. +Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was +assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. +Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue +z-order  information  for  each  layer. +b.  Sound  Resource +b-1.  External  Condition  Collection +Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. +**Figure  7-7:  Definition  of  Sound  Resource** +•  Zone +Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can +play  at  the  same  time. +Page  37  of  159 + + ------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- ---------------------------------------------- ------------------------- + > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media + > + > player + + > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of + > + > Navigation + + > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound + > + > requests  this  type. + ------------------------------------------------------------------------------------------------- + +![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +•  Sound  type +Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource +owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper +sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific +zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each +sound  stream  must  assign  to  individual  sound  type. +AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. +•  Stream +Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in +stream. +b-2.  Judgment  of  Priority  of  GUI  resource +Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role +is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy +Manager.  Figure  7-8  describes  the  definition  of  role. +Page  38  of  159 +![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  7-8:  Sample  Role** +The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that +is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or +different  sound  type  are  not  switched.  They  are  mixed. +b-3.  GUI  Resource  Control +Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +directly. +There  are  two  types  of  sound  resource  control: +One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for +sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound +Page  39  of  159 +![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +stream  and  to  start  play  latest  area  owner. +Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback +simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy +Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and +music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music +playback. +c.  Input  Resource +c-1.  External  Condition  Collection +Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. +**Figure  7-9:  Definition  of  Input  Resource** +•  Device  Name +Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. +•  Event  Type +Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and +temperatures. +c-2.  Judgment  of  Priority  of  GUI  resource +Page  40  of  159 +![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device +name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy +DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the +judgment  as  below. +**Figure  7-10:  Definition  of  routing  rule** +OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. +c-3.  GUI  Resource  Control +Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. +Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. +4.1.3.1.3  System  Resources +(1)  Definition +Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy +Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. +Page  41  of  159 + + ---------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ----------------------------- ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according + > + > to  external  condition  change. + > + > 2.  Kill  process(s)  forcibly  according  to  external + > + > condition  change. + ---------------------------------------------------------------------------------------------------- + +![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, +target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. +**4.1.3.2  Requirements** +4.1.3.2.1  Screen  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system +uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive +information  must  include  as  follows. +a.  ID +b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) +c.  DPI +d.  Connected  ECU +Page  42  of  159 +![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be +able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list +according  to  current  layout  of  each  display. +The  receive  definition  must  include  the  follows. +a.  ID +b.  Area  list +System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface +by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the +device. +The  receive  request  must  include  the  follows. +a.  Layout  ID +b.  ID +c.  Area  position  (Coordinate  of  the  upper-left) +d.  Area  size  (Length  \*  Width) +System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify +the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. +a.  Display  ID +b.  Layout  ID +System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the +providing  resource  using  it  when  the  request  is  collision. +The  receive  information  must  include  the  follows. +a.  Role +b.  Priority +System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge +driving  mode. +The  receive  information  must  include  the  follows. +a.  Velocity +Page  43  of  159 +![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Brake  status +System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge +day  night  mode. +The  receive  information  should  include  the  follows. +a.  The  brightness  of  the  interior +System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the +providing  resource  using  it. +System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should +judge  the  providing  resource  using  it. +(2)  Judgment  of  Priority  of  GUI  Resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical +resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the +resource. +The  receive  request  must  include  as  follows. +a.  Role +b.  Layer  type +The  receive  request  should  include  as  follows. +c.  Display  ID +System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by +priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on +the  specified  area  on  the  specified  layer. +The  receive  request  must  include  as  follows. +a.  Role +Page  44  of  159 +![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Layer  ID +The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. +Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the +related  basic  type  area. +c.  Area  ID +**Figure  7-11:  Sequence  to  display** +System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. +In  this  request,  requester  should  choose  below  options. +a. +Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, +but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should +be  refused. +b. +Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen +resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher +priority,  then,  only  screen  resource  should  be  assigned  to  requester. +Page  45  of  159 +![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system +running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. +The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal +request. +a.  Effective  period  (Can  set  unlimited) +System  should  not  raise  the  other  surface  above  its  during  effective  period. +System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +a.  The  effect  at  the  transition +b.  The  effect  of  display  surface +System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are +sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all +layers  will  be  superimposed  by  z-order. +System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. +System  must  hide  the  surface  that  has  too  much  information. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Visible  /  Invisible +b.  Change  position +c.  Raise +The  receive  request  must  include  as  follows. +i.  Surface  ID  \*Only  case  of  visible. +ii.  Display  ID  \*Only  case  of  visible. +iii.  Layer  ID  \*Only  case  of  visible. +Page  46  of  159 +![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. +v.  Size  (Length  \*  Width)  \*Only  case  of  visible. +System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. +a.  The  effect  at  the  transition +b.  The  effect  of  display  surface +4.1.3.2.2  Sound  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone +information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as +follows. +a.  ID +b.  Sound  device  ID +System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses +sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must +include  as  follows. +a.  ID +(2)  Judgment  of  Priority  of  GUI  resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +request  during  system  running. +Page  47  of  159 +![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  receive  request  must  include  as  follows. +a.  Role +b.  Zone  ID +c.  Sound  type  ID +System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during +system  running. +The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal +request. +a.  Effective  period  (Can  set  unlimited) +System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner +by  other  request  on  same  area  during  effective  period. +System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +a.  The  effect  at  the  transition +b.  The  effect  of  output  sound +System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more +resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority +of  resources  that  is  related  to  role. +\*  Boundary  of  the  role  between  Policy  Manager  and  application. +Page  48  of  159 +![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Figure  7-12:  Boundary  of  role  (Case  of  reverse) +System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system +should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. +For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound +from  request  history  based  on  the  priority. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Mute  /  Unmute +b.  Change  zone +The  receive  request  must  include  as  follows. +i.  Stream  ID +ii.  Device +In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. +iii.  Channel  ID +Page  49  of  159 +![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. +a.  The  effect  at  the  transition +b.  The  effect  of  output  sound +4.1.3.2.3  Input  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses +input  device  information  with  to  control  input  event  to  other  system.  The  receive  information +must  include  as  follows. +a.  ID +System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses +input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must +include  as  follows. +a.  ID +b.  Related  event  IDs +(2)  Judgment  of  Priority  of  GUI  resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +request  during  system  running. +The  receive  request  must  include  as  follows. +a.  Input  device  ID +Page  50  of  159 +![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Event  type  ID +System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the +limitation  routing  rule  of  policy  DB. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Set  the  routing  rule +The  receive  request  must  include  as  follows. +i.  Input  device  ID +ii.  Event  type  ID +The  receive  request  must  include  either  as  follows. +iii.  The  allowed  application +iv.  The  denied  application +System  should  provide  a  mechanism  to  set  the  following  information. +a.  Application  that  has  active  surface +System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This +feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen +changes  the  active  surface. +4.1.3.2.4  System  Resources +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager +to  decide  proper  system  resource. +Page  51  of  159 +![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  must  detect  creation  and  deletion  of  process. +To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created +process. +Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to +other  active  processes. +To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to +identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each +active  process. +Policy  Manager  must  detect  current  memory  consumption  periodically. +To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each +process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were +thought  as  not  so  important  process. +Policy  Manager  must  detect  current  CPU  consumption  periodically. +To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep +system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected +busy  state. +System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. +Application  status  includes  as  below. +· GUI  resource  status,  such  as  foreground  or  background. +· +Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must +resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last +application  to  resume  quickly  as  much  as  possible. +(2)  System  Resource  Control +System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process +group  according  to  external  conditions. +According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to +target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups +Page  52  of  159 +![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +will  be  used) +System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. +4.1.3.2.5  Resource  Management +Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy +Manager,  Connection  Manager. +Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. +Each  resource  request  shall  be  in  form  a: +AppID, +SourceID, +RequestorZoneID, +NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), +Required  Resource  List. +Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin +Speakers,  HeadPhones) +Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) +Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, +Tuners  etc.) +Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request +from  resource  requestors. +Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. +Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) +Page  53  of  159 +![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list +are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) +Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system +through  status  update. +Resource  Management  shall  support  stacking/queuing  of  resource  requests. +>  Receive  the  requests  from  the  resource  requestors. +>  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy +Manager. +>  Add  the  validated  requests  into  a  priority  queue. +>  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. +>  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it +shall  be  removed  from  the  queue. +Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier +request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it +shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. +If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the +requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. +If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant +some/all  of  the  resources  requested  by  the  requestor. +Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an +existing  resource  request. +Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of +policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs +for  the  policy  decision: +>  Currently  Free  or  InUse  Sink  status +>  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) +Page  54  of  159 +![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +>  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. +Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a +request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the +policy  decision: +>  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept +pending. +>  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. +At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by +resource  requestor: +>  Zone  ID +>  Allocated  Source  Instance +>  Allocated  Sink  Instance +>  Mute  status +Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality +(e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to +the  resource  management  policy. +Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature +functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). +Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: +AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have +same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, +the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. +Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, +AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource +request  will  be  the  one  that  is  granted  the  resource. +A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. +It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. +Page  55  of  159 +![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. +It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource +Manager  if  the  resource  is  no  longer  needed. +Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all +available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once +the  request  is  granted  against  the  set  policy. +Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. +Possible  connection  states  are  Active  or  Passive. +>  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be +active. +Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. +>  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be +passive. +Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same +AMFM  source  on  Rear  headphone  sink. +Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink +connection  using  the  underlying  platform  support. +Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink +connection  using  the  underlying  platform  support. +Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is +removed/released. +Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is +re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. +Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. +Page  56  of  159 +![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready +to  be  used  for  audio  routing. +Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio +routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. +Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. +Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which +source  instance. +Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: +>  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. +System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +Headphones  shall  not  be  required  to  support  any  foreground  sinks. +In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a +source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source +(if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). +As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not +disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background +connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. +Page  57  of  159 +![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State +Manager. +It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. +It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on +current  system  scenario. +E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call +is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a +pending  request. +It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. +It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. +It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video +resources  and  update  its  internal  status  accordingly. +On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active +connections  and  reconnect  or  disconnect  if  required. +E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. +Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of +connections  shall  be  rebuilt  with  Amp. +It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. +Page  58  of  159 +![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying +platform  support. +It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the +underlying  platform  support. +It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. +It  shall  provide  an  interface  to  unmute  an  audio  sink. +System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +Headphones  shall  not  be  required  to  support  any  foreground  sinks. +It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +**4.1.4  Sound  Manager** +A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from +two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a +policy  manager  manages  a  mediation  rule. +Page  59  of  159 + + ---------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ------------------------------------------------------------ + > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). + + > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume + > + > control  of  each  sound  streams. + + > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, + > + > ·     When  changing  sound  stream.  E.g.  fade-in, + > + > fade-out  and  cross-fade. + + > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce + > > + > hardware > dependency  of  hardware.  Well-defined  interface + > + > also  makes  it  possible  to  increase  the  effect  of + > + > portability  and  development  cost. + ---------------------------------------------------------------------------------------------------- + +![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a +passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound +resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. +Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like +volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server +to  implement  automatic  audio  policies. +**4.1.4.1  Use  Case** +Please  refer  “sound  resource  control”  of  Policy  Manger  section. +Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. +**4.1.4.2  Requirements** +Page  60  of  159 +![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4.1.4.2.1  Routing  Sound  Streams +System  must  provide  a  mechanism  to  manage  sound  “zone”. +Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a +zone  and  how  to  manage  zone. +System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each +channels  of  each  sound  device. +One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists +of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. +For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is +arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when +outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower +musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than +music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound +device. +The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more +zones. +Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the +present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the +mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. +System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. +System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. +All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. +System  must  provide  a  mechanism  to  control  sound  stream. +Control  of  a  sound  stream  is  as  follows. +· +Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound +stream. +· +Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound +Page  61  of  159 +![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +stream. +Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. +4.1.4.2.2  Mixing  Level  Control +The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to +the  same  zone  according  to  a  policy  manager's  arbitration. +System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. +System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream +requested  to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating +the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. +System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested +to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted +sound  stream  was  ended. +System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream +requested  to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound +stream  was  ended. +4.1.4.2.3  Sound  Effect +When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. +System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. +System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin +architecture. +Page  62  of  159 + + ------------------------------------------------------------------------------------------------------------------------- + > **No.** > **Input  type** > **Associated  device** > **Description** + ----------- ------------------- -------------------------- -------------------------------------------------------------- + > 1 > Key > Steering  switch > Simple  key  event. + > + > Deliver  to  application. + + > 2 > Keyboard > Virtual  keyboard > Keyboard  event. + > + > Deliver     to     application,     then     use     input + > + > method  backend  if  needed. + + > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. + > + > Also  supports  double  click  and  multi-touch + > + > capability. + > + > Deliver  to  application. + + > 4 > Sound > Microphone > Sound  input. + ------------------------------------------------------------------------------------------------------------------------- + +![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4.1.4.2.4  Reduced  Dependency  of  Hardware +Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels +of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means +which  does  not  need  rebuild  of  systems,  such  as  a  configuration. +**4.1.5  Input  Manager** +The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application +depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each +input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering +switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. +**4.1.5.1  Use  Case** +Please  refer  “input  resource  control”  of  Policy  Manger  section. + + --------------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ----------------------------------------------------------------- + > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to + > + > application  readable  event  name,  such  as  “volume + > + > up”  and  “right  arrow”. + + > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified + > + > application. + --------------------------------------------------------------------------------------------------------- + +![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Deliver  to  application  or  voice  recognition +engine. +Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. +**4.1.5.2  Requirements** +**4.1.5.3  Abstract  Device  Event** +System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. +Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional +equipment. +**4.1.5.4  Event  Delivery** +System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. +System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” +and  “destination  application  id”. +Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by +UIM.2.1.2. +Page  64  of  159 +![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. +System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. +System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on +delivery  rule  defined  in  UIM.2.1.1. +System  must  provide  a  mechanism  to  inhibit  any  event  delivery. +This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. +**4.1.6  User  Manager** +**4.1.6.1  Use  Case** +**4.1.6.2  Personal  Identification** +User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a +person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. +**4.1.6.3  User  Preference** +Multi-user  environment  provides  same  user  experience  for  each  user. +Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including +other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data +sharing  from  your  home  and  your  office. +Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be +provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. +Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user +experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, +*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is +Page  65  of  159 +![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. +**Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** +**4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** +When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If +Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is +important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s +preference. +**Figure  7-25  :  User  data  sharing  between  cars** +Page  66  of  159 +![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**4.1.6.5  Seamless  Data  Sharing** +Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and +smart-phones,  home  networks  and  accessing  from  your  offices. +**Figure  7-26  :  User  data  sharing  over  the  cars** +**4.1.6.6  Role** +**Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above +purpose  and  use  cases. +**Table  7-17  :  Role  of  User  Manager** +**No.** **Role** **Description** +Page  67  of  159 +![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +1 User  identification +Provide  a  mechanism  to  identify  user,  such  as  user +name  and  password  pair,  smart  key  and  biometrics. +Provide  a  mechanism  to  log-in  to  the  IVI  system  as +a  specified  user. +When a different user logs in, proper user +preference  for  the  user  must  be  applied,  and +resume  last  state  of  corresponding  user. +Also,  each  application  can  store  application’s  data +per  user.  In  such  cases,  proper  user  data  must  be +applied  when  a  different  user  logs  in. +2 User  preference +Provide  a  mechanism  to  apply  user  preference  of +logged-in  user. +User  preference  includes  the  following  data. +· User  interface,  such  as  locale  and  wall- +paper. +· Resume  last  application’s  status  of  specified +user. +· Application  specific  data. +3 User  data  management +Provide  a  mechanism  to  manage  cloud  based  user +data. +The  following  capabilities  are  required. +· Download  user  data  of  the  logged-in  user +from  the  cloud. +· Update  cloud  data  if  the  user  data  was +updated  by  user  operation  or  otherwise. +· Periodically  sync-up  w/  cloud  because  user +data  may  be  updated  by  other  devices. +In  addition  to  the  above  basic  capabilities,  user  data +cache  is  essential  for  a  car,  since  a  car  may  not +always  have  a  reliable  network  connection. +4 Security Because  cloud  based  sharing  user  data  may  be +accessed  from  any  place,  user  data  must  be +protected  from  unexpected  data  access. +Page  68  of  159 +![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +So,  IVI  system  must  provide  security  mechanism +regarding  accessing  to  cloud  based  user  data. +**4.1.6.7  Requirements** +4.1.6.7.1  User  Identification +System  must  provide  a  mechanism  to  identify  logged-in  user. +System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to +identify  logged-in  user. +System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For +example,  using  NFC. +System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. +4.1.6.7.2  User  Preference +When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the +currently  logged-in  user. +System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. +- Locale  settings +- UX  theme +Wall  paper +System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized +user  experience. +Page  69  of  159 +![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in +user’s  application  data  automatically. +When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last +status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the +system.  Specifically,  last  status  includes  the  following. +- Foreground  applications.  That  means  displayed  applications. +Background  applications. +When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. +System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. +System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. +4.1.6.7.3  User  Data  Management +System  must  provide  a  mechanism  to  manage  user  data. +AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user +preference. +User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but +also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and +home  electronics. +System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to +application  by  using  cloud  based  user  data. +System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data +of  the  IVI  system. +When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to +the  cloud. +Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide +Page  70  of  159 +![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. +Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a +mechanism  to  cache  downloaded  user  data. +If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as +possible. +4.1.6.7.4  Security +Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to +protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. +System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. +- +System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must +authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, +smartphone  or  PC. +- +System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. +- +System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection +against  falsification  of  data  from  unauthorized  access  or  illegal  access. +- +Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide +user  data  only  to  the  authorized  user. +Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must +provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to +include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against +cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. +4.2  Web  HMI +Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. +**4.2.1  Web  API** +Page  71  of  159 +![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service +function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio +visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, +Photo,  etc.) +Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of +Audio  Visual  API  is  shown  in  Figure  6-1. +**Figure  6-1:  Use  case  of  Audio  Visual  API** +**4.2.1.1  Requirements** +Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. +· Select  content  using  URL +· +Select  content  using  contents  list  provided  by  multimedia  subsystem +Page  72  of  159 +![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, +DVD,  BT-Audio,  Photo,  etc.) +· Play +· Pause +· Fast-forward +· Rewind +· Track  up +· Track  down +· Select  playmode  (Repeat/Random) +Audio  Visual  API  must  provide  API  to  control  a  volume. +· Volume  up +· Volume  down +· Mute +Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. +Audio  Visual  API  must  provide  API  for  notifications. +· The  case  that  playback  state  is  changed +· The  case  that  Audio  Visual  contents  is  add  /  removed +Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. +· Change  the  frequency. +· Change  the  broadcasting  stations. +· Receive  the  list  of  broadcasting  stations. +· Select  the  preset  channel. +· Get  the  information  of  the  broadcasting  station. +Audio  Visual  API  must  provide  API  to  play  digital  radio. +· Store  the  broadcast  program  information. +Page  73  of  159 +![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Get  the  broadcast  program  information. +· Get  the  play  time. +· Play  the  radio  broadcast  cached. +AGL  System  must  support  a  web  API  to  access  Vehicle  information. +AGL  System  must  support  web  API  to  control  STT/TTS  daemon. +AGL  System  must  support  web  API  to  control  navi  engine. +AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web +apps. +AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app +and  a  native  app. +AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider +should  be  able  to  restrict  subscriber. +AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. +AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, +Network  Information +AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG +AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio +AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, +server  sent  events,  session  history  of  browsing  context +*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL +Page  74  of  159 +![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 +The  iframe  element,  Content  Security  Policy  1.0. +AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications +AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing +control,  Navigation  timing +AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation +AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, +Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy +AGL  System  must  support  Khronos  WebGL  API. +**4.2.2  Web  Runtime** +The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access +the  AGL  Application  Framework  and  Services. +**4.2.2.1  Requirements** +AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., +installation/removal). +AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, +view  generation,  rendering,  etc.) +AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add +better  device/platform  integration. +Page  75  of  159 +![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to +categorize  apps  with  different  privileges. +System  must  provide  high  level  GUI  components  for  Web  application. +At  least,  below  components  are  required. +· Text  labels +· Button +· Radio  button +· Check  box +· Tab  panel +· Animation  (e.g.  MNG,  GIF  animation) +· Slider +· Accordion  list +· Anchor +· Text  input  form +· Dropdown  list  box +· Date  picker +4.3  Native  HMI +The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written +using  Javascript  or  other  web  technologies. +**4.3.1  Native  App  Runtime** +The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to +access  the  AGL  Application  Framework  and  Services. +**4.3.1.1  Requirements** +System  must  provide  high  level  GUI  components  for  native  application. +Page  76  of  159 +![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +At  least,  below  components  are  required. +· Text  labels +· Button +· Radio  button +· Check  box +· Tab  panel +· Animation  (e.g.  MNG,  GIF  animation) +· Slider +· Accordion  list +· Anchor +· Text  input  form +· Dropdown  list  box +· Date  picker +**4.3.2  Native  Application  Framework** +The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an +SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that +framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the +application  framework  provides  for  its  applications. +**5   Services   Layer** +The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the +services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces +remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime +modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid +unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer +interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces +provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may +choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework +runtime  to  adjust  to  any  new  interfaces, +Page  77  of  159 +![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1  Platform  Services +Platform  Services  Layer.  Conventional  Linux  platform  services +**5.1.1  Bluetooth** +This  document  describes  requirements  regarding  registration,  (dis)connection  and  device +information  management  between  Bluetooth  device  and  infotainment  system.  Necessary +Bluetooth  profiles  in  automotive  use  case  are  defined  here. +**5.1.1.1  Requirements** +The  Telephony  system  shall  be  designed  to +support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR +without  hardware  upgrade. +A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: +· Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) +· HFP  (Hands  Free  Profile) +· OBEX  (Object  Exchange) +· OPP  (Object  Push  Profile) +· PBAP  (Phonebook  Access  Profile) +· SPP  (Serial  Port  Profile) +· SDAP  (Service  Discovery  Access  Profile) +If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music +from),  the  system  shall  also  support  the  following  incremental  BT  profiles: +· A2DP  (Advanced  Audio  Distribution  Profile) +· AVRCP  (Audio  Visual  Remote  Control  Profile) +The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the +Page  78  of  159 +![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of +generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in +encryption  key  length  negotiation. +When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as +default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority +scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration +time. +The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is +10  meters  and  maximum  power  is  2.5  mW  (4  dBm). +The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall +allow  using  five-slot  packet  transmission  for  faster  data  rate. +The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a +standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. +vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are +often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain +name  and  address  information,  phone  numbers,  and  e-mail  addresses. +vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, +LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, +URL,  UID,  Version,  and  KEY  properties. +vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: +MIME  Content-Type  for  Directory  Information +vCard  MIME  Directory  Profile +It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with +the  vCard  version  2.1  properties. +The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any +associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is +not  full. +The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO +Page  79  of  159 + + ------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **Support  in  HF** > **AGL** + ----------- ------------------------------------------------------------- ----------------------- ----------- + > 1 > Connection  management > Mandatory > x + + > 2 > Phone  status  information > Mandatory > x + + > 3 > Audio  Connection  handling > Mandatory > x + + > 4 > Accept  an  incoming  voice  call > Mandatory > x + + > 5 > Reject  an  incoming  voice  call > Mandatory > x + + > 6 > Terminate  a  call > Mandatory > x + + > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x + + > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x + > + > HF + + > 9 > Place  a  call  using  memory  dialing > Option > - + + > 10 > Place  a  call  to  the  last  number  dialed > Option > - + ------------------------------------------------------------------------------------------------------------- + +![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +shall  be  used. +5.1.1.1.1  Hands  Free  Profile +The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile +specification  version  1.6  or  later. +The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, +wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and +output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to +the  actual  phone. +It  shall  provide  following  roles: +Hands-Free  unit  (HF) + + > 11 > Call  waiting  notification > Option > x + ------- ------------------------------------------------------ ---------- ---------- + > 12 > Three  way  calling > Option > x(\*1) + > 13 > Calling  Line  Identification  (CLI) > Option > x + > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x + > 15 > Voice  recognition  activation > Option > x + > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - + > 17 > Ability  to  transmit  DTMF  codes > Option > x + > 18 > Remote  audio  volume  control > Option > - + > 19 > Respond  and  Hold > Option > x + > 20 > Subscriber  Number  Information > Option > x + > 21a > Enhanced  Call  Status > Option > x + > 21b > Enhanced  Call  Controls > Option > - + > 22 > Individual  Indicator  Activation > Option > - + > 23 > Wide  Band  Speech > Option > x + > 24 > Codec  Negotiation > Option > x + +![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +\*1:  Does  not  support  Multi-party  (conference)  call +The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the +model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +string  in  a  phone  model  CGMM  variable. +· Phone  Model  CGMM: +· Type:  string +· Max  length:  200  chars +Page  81  of  159 +![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the +Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be +stored  as  a  string  in  a  phone  model  CGMI  variable. +· Phone  Model  CGMI: +· Type:  string +· Max  length:  200  chars +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the +revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +string  in  a  phone  model  CGMR  property. +· Phone  Model  CGMR: +· Type:  string +· Max  length:  200  chars +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) +The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP +specification  version  1.2  or  later. +Page  82  of  159 + + > **No.** > **Codec** > **Support** > **AGL** + ----------- ------------------- --------------- ----------- + > 1 > SBC > Mandatory > x + > 2 > MPEG-1,2  Audio > Option > - + > 3 > MPEG-2,4  AAC > Option > - + > 4 > ATRAC  family > Option > - + + > **No.** > **Feature** > **Support  in  SNK** > **AGL** + ----------- -------------------- ------------------------ ----------- + > 1 > Audio  Streaming > Mandatory > x + +![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to +realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. +It  shall  provide  following  roles: +Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from +the  SRC  on  the  same  piconet. +Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. +Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. +Copyright  protection  technology  SCMS-T  should  be  supported. +5.1.1.1.3  Phone  Book  Access  Profile +Page  83  of  159 +![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification +version  1.1  or  later. +The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between +devices. +Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The +Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected +device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing +and  copying  contact  information. +It  shall  provide  following  roles: +· Phonebook  Client  Equipment  (PCE) +It  shall  provide  following  types  of  Phonebook  objects: +· The  main  Phonebook  object +· The  Incoming  Call  History  object +· The  Outgoing  Call  History  object +· The  Missed  Call  History  object +· The  Combined  Call  History  object +A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device +automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook +download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: +· Using  PBAP  profile +All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. +SIM)  and  also  any  stored  in  the  BT  device's  memory. +The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the +vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded +from. +5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile +Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +Page  84  of  159 + + > **No.** > **Service** > **Support  in  DT** > **AGL** + ----------- ------------------------------------------- ----------------------- ----------- + > 1 > Data  call  without  audio  feedback > Mandatory > x + > 2 > Data  call  with  audio  feedback > Option > - + > 3 > Fax  services  without  audio  feedback > N/A > - + > 4 > Fax  services  with  audio  feedback > N/A > - + > 5 > Voice  call > N/A > - + > 6 > Incoming  calls > Option > x + > 7 > Outgoing  calls > Mandatory > x + +![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” +Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. +5.1.1.1.5  Object  Push  Profile  (OPP) +Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower +layers. +It  has  to  comply  with  the  specification  for  “Push  Server”. +Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. +**Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** +Page  85  of  159 + + > **No.** > **Feature** > **Support  in  CT** > **AGL** + ----------- -------------------------------------------- ----------------------- ----------- + > 1 > Connection  establishment  for  control > Mandatory > x + > 2 > Release  connection  for  control > Mandatory > x + > 3 > Connection  establishment  for  browsing > C6 > x + + ------------------------------------------------------------------------------------- + > **No** > **Feature** > **Support  in  Push  Server** > **AGL** + > + > **.** + ---------- ---------------------------- --------------------------------- ----------- + > 1 > Object  Push > Mandatory > x + + > 2 > Business  Card  Pull > Option > - + + > 3 > Business  Card  Exchange > Option > - + ------------------------------------------------------------------------------------- + +![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) +The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. +The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device +plus  one  remote  control.. +The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL +column  in  Table  25  should  be  supported. +C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional +otherwise +C3:  Mandatory  to  support  at  least  one  Category +C4:  Mandatory  if  Category  2  supported,  excluded  otherwise +C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise +EX:  Excluded +Page  86  of  159 +![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4 Release  connection  for  browsing C6 x +5 AV/C  Info  commands Option x +6 Category  1:  Player/Recorder C3 x +7 Category  2:  Monitor/Amplifier C3 - +8 Category  3:  Tuner C3 - +9 Category  4:  Menu C3 - +10 Capabilities Option x +11 Player  Application  Settings Option x +12 Metadata  Attributes  for  Current  Media  Item Option x +13 Notifications C2 x +14 Continuation C2 x +15 Basic  Group  Navigation Option x +16 Absolute  Volume C4 - +17 Media  Player  Selection Option x +17.1 -  Supports  Multiple  Players Option x +18 Browsing Option x +18.1 -  Database  Aware  Players Option x +19 Search Option - +20 Now  Playing C6 x +20.1 -  Playable  Folders Option x +21 Error  Response EX - +22 PASSTHROUGH  operation  supporting  press  and Option x +Page  87  of  159 + + ------------------------------------------------------------------------------ + > **No** > **Feature** > **Support  by  the  MCE** > **AGL** + > + > **.** + ---------- ------------------------- ----------------------------- ----------- + > 1 > Message  Notification > C1 > x + + > 2 > Message  Browsing > C1 > x + + > 3 > Message  Uploading > Option > x + + > 4 > Message  Delete > Option > - + + > 5 > Notification > C2 > x + > + > Registration + ------------------------------------------------------------------------------ + +![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +hold +The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and +pass  this  information  up  to  so  it  can  be  passed  to  the  User. +5.1.1.1.7  Message  Access  Profile +Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary +lower  layers. +It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. +Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. +C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features +C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message +Notification.  Not  applicable  otherwise. +Page  88  of  159 + + > **No.** > **Feature** > **Support  in  PANU** > **AGL** + ----------- ------------------------------------------ ------------------------- ----------- + > 1 > Initialization  of  NAP/GN  service > - > - + > 2 > Shutdown  of  NAP/GN  service > - > - + > 3 > Establish  NAP/GN  service  Connection > Mandatory > x + +![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.8  Serial  Port  Profile  (SPP) +The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version +1.1  or  later. +It  shall  provide  following  roles: +Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. +Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. +Following  features  shall  be  provided  by  the  Supplier: +Establish  link  and  setup  virtual  serial  connection +Accept  link  and  establish  virtual  serial  connection +Register  Service  record  for  application  in  local  SDP  database +5.1.1.1.9  Personal  Area  Network  (PAN)  Profile +Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. +Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. +Page  89  of  159 + + > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x + ----- ------------------------------------------- ------------- ----- + > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x + > 6 > Management  Information  Base  (MIB) > - > - + +![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.10  Service  Discovery  Profile  (SDP) +The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP +specification  version  1.1. +The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices +in  the  vicinity  of  a  Bluetooth  enabled  device. +It  shall  provide  following  roles: +Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. +Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to +the  service  inquiries  generated  by  Local  Device. +The  following  features  shall  be  provided  by  the  Supplier: +Search  for  services  by  service  class +Search  for  services  by  service  attributes +Service  browsing +5.1.1.1.11  Device  Information  Profile +Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. +**Table  28  :  List  of  DIP  Supporting  Functions** +Page  90  of  159 + + > **No.** > **Feature** > **Support** > **AGL** + ----------- ----------------------- --------------- ----------- + > 1 > SpecificationID > Mandatory > x + > 2 > VendorID > Mandatory > x + > 3 > ProductID > Mandatory > x + > 4 > Version > Mandatory > x + > 5 > PrimaryRecord > Mandatory > x + > 6 > VendorIDSource > Mandatory > x + > 7 > ClientExecutableURL > - > - + > 8 > ServiceDescription > - > - + > 9 > DocumentationURL > - > - + +![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.12  Bluetooth  Smart  Ready +Bluetooth  Smart  Ready  shall  be  supported. +It  shall  comply  with  Bluetooth  Low  Energy  standard. +5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) +The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX +specification  version  2.0  or  later. +The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between +devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. +It  shall  provide  following  roles: +Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data +objects  shall  be  pushed  and  pulled,  respectively. +Page  91  of  159 +![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. +The  following  features  shall  be  provided  by  the  Supplier: +Establishing  an  object  connection +Pushing  a  data  object +Pulling  a  data  object +Performing  an  action  on  data  objects +Creating  and  managing  a  Reliable  Object  Exchange  Connection +5.1.1.1.14  Generic  Audio/Video  Distribution  Profile +The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the +GAVDP  specification  version  1.2  or  later. +The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between +two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. +It  shall  provide  following  roles: +Initiator  (INT) +Acceptor  (ACP) +Following  are  the  feature  requirements  for  this  profile: +Connection +Transfer  Control +Signalling  Control +Security  Control +Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not +yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. +5.1.1.1.15  Bluetooth  Diagnostics +**5.1.2  Error  Management** +The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes +Page  92  of  159 +![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized +restart.  In  addition, +in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery +to  issue  in  a  short  amount  of  time. +**5.1.2.1  Use  Cases** +5.1.2.1.1  System  Surveillance  and  Recovery +While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an +immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating +the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to +try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating +middle  ware,  reboot  the  whole  system  to  try  and  recover. +There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that +adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The +AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. +The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even +if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be +done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error +Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the +degree  should  be  adjusted  by  its  behavior  status. +5.1.2.1.2  Collecting  Information +For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt +recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the +cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. +With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On +the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come +Page  93  of  159 +![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, +the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. +**5.1.2.2  Requirements** +Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its +status  automatically  and  recover +The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each +process. +The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. +When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold +value,  action  is  changeable  by  AGL  user. +Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification +to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are +output  communication  or  disk  I/O. +Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification +by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an +error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication +error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. +Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it +should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination +of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so +those  two  should  be  able  to  set  separately. +Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold +value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be +changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. +Should  be  able  to  vanish  process  forcibly  including  subsidiary  process +Page  94  of  159 +![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Make  the  software  that  works  by  system  have  the  concept  of  level  importance. +Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be +adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. +The  process  that  detecting  an  external  communication  error  within  the  Error  Management +module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. +The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as +more  than  one  process. +The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple +applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where +multiple  applications  can  be  moved  by  the  same  process. +Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing +process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as +process  crash,  exit,  etc.. +An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends +suddenly  the  other  will  not  become  abnormal  state. +The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other +process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards +external  side. +When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart +additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered +beforehand. +The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file +system  without  destroying  them. +Page  95  of  159 +![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for +analyzing. +When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a +message  that  can  specify  the  cause. +Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +in  a  short  period  of  time  have  been  equipped  and  able  to  select. +In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or +system  down  does  not  occur  (self-destruction  on  log  output  process). +Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. +Should  be  able  to  select  the  level  of  log  output. +Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. +Should  be  able  to  obtain  the  information  linked  to  the  system  resources. +Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. +Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +in  a  short  period  of  time  have  been  equipped  and  able  to  select. +As  the  smallest  amount  of  information,  the  following  information  should  be  left. +· Register  information +· Process  logical  memory  map +· +Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence +· Time  of  occurrence +· +Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing +file‑name  of  the  thread  etc.) +Page  96  of  159 +![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· The  signal  that  occurred +Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. +· +Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted +for  an  output. +· +Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent +dropping  the  information  needed. +· +Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] +· +Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed +maximum  size. +· +NOTE  information  of  ELF  header  and  program  header  will  not  change. +Selectable  memory  mappings  are  the  following. +· anonymous  private  mappings +· anonymous  shared  mappings +· file-backed  private  mappings +· file-backed  shared  mappings +· private  huge  page +· shared  huge  page +Setting  parameters  of  the  output  context  are  the  following. +· +Memory  mapping  category  which  is  for  an  output  object  can  be  set. +· The  order  of  outputting  memory  mapping  can  be  set. +Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in +increments  of  process. +Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be +able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. +Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. +Page  97  of  159 +![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. +**5.1.3  Graphics** +Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. +**5.1.4  Location  Services** +Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead +reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary +output  of  the  GPS  receiver. +**5.1.4.1  Position** +**5.1.4.2  Time  of  Day** +With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car +device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of +its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in +future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. +**Monotonic  and  Absolute  Time  Support** +As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. +Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s +moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and +Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. +On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time +that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, +some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports +Monotonic  Time. +**Kernel  Time  Precision** +Page  98  of  159 +![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those +communicating  system  includes  the  device  that  needs  ms  order  procedure. +In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on +the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest +value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. +**5.1.4.3  Requirements** +Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. +Adjust  the  system  time  after  the  time  is  determinate. +GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using +the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. +GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not +imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make +Source  plugin  can  not  be  GPL  or  LGPL. +When  waiting,  can  use  both  absolute  time  and  monotonic  time +Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +monotonic  time. +Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +monotonic  time. +System  time  must  be  able  to  use  consecutively  at  least  until  2099. +Absolute  time  has  to  support  leap  year  and  leap  seconds. +1  jiffies  have  to  be  smaller  than  1ms. +Page  99  of  159 +![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. +From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. +A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. +**5.1.5  Health  Monitoring** +Platform  monitoring  services  such  as  watchdog  or  active  monitoring +**5.1.6  IPC** +Standard  platform  interprocess  and  interprocessor  communication  mechanism. +**5.1.7  Lifecycle  Management** +Startup,  shutdown,  state  change,  etc. +**5.1.8  Network  Services** +Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer +including  Wifi,  Bluetooth,  or  ethernet. +**5.1.9  Persistent  Storage** +Power  safe  persistent  storage +**5.1.10  Power  Management** +Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs +in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. +*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* +Page  100  of  159 +![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +modern  ECUs +In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, +in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal +balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important +for  overall  durability  characteristic. +Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming +more  welcomed  over  traditional  cold  boot  approaches. +Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has +become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only +consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) +**5.1.10.1  Requirements** +AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend +states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” +/“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. +AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state +transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state +transitions  if  no  requests  provided  from  applications. +Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of +this  specification  (it  is  also  platform-dependent). +AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of +cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting +core  in  one  of  its  low  power  states) +AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular +cores  from  SMP  group. +Page  101  of  159 +![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points +(table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, +some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget +insignificant) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling +Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. +Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they +may  have  negative  impact  on  overall  system  performance/predictability +AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is +platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states +Only  application-defined  policies  shall  be  allowed  for  CPU  Idle +AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices +AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling +**5.1.11  Resource  Management** +Resource  and  device  management. +Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource +request  by  the  Resource  Manager. +**5.1.12  Telephony  Services** +**5.1.12.1  Requirements** +Page  102  of  159 +![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.12.1.1  Telephony  variants +Purpose:  To  define  the  variants  of  Telephony +Requirement: +There  will  be  2  variants  of  phone  system. +Variant  1:  Front  User  only  Telephony. +Variant  2:  Rear  and  Front  Telephony. +All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature +can  be  disabled  via  car  configuration. +**5.1.13  Wi-Fi** +This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information +management  between  a  wireless  LAN  device  and  infotainment  system. +Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. +**5.1.13.1  Use  Cases** +5.1.13.1.1  Construct  WiFi  Network +In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. +a\. STA +In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via +an  Access  Point. +It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. +b\. AP +In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices +with  an  external  network. +Page  103  of  159 +![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. +c\. P2P +In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- +Fi  Direct. +5.1.13.1.2  Miracast +In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) +They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, +by  using  UIBC  (User  Interface  Back  Channel).-(b) +**Figure  8-29  :  Overview  of  Miracast** +a\. Shared  Displayed  Content +Page  104  of  159 +![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Use  case  examples  of  shared  displayed  content  are: +· +A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device +(e.g.  Mobile)  on  In-Vehicle  Infotainment  system. +· +A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment +system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). +b\. Remote  Operation +Use  case  examples  of  remote  operation  are: +· +A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device +(e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. +· +A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle +Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). +· +While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation +functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. +Mobile). +5.1.13.1.3  DLNA +In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. +**5.1.13.2  Requirements** +5.1.13.2.1  Security +The  WiFi  module  shall  support  security  standard  WEP. +It  shall  support  40  bit  WEP  encryption  method. +It  shall  support  104  bit  WEP  encryption  method. +It  shall  support  security  standard  WPA  Personal. +Page  105  of  159 +![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA2  Personal. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA  Enterprise. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA2  Enterprise. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +5.1.13.2.2  Simple  Configuration +It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. +It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. +It  shall  support  Configuration  Method  for  Display. +Page  106  of  159 +![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  support  Configuration  Method  for  Keypad. +It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. +It  shall  support  Configuration  Method  for  PushButton. +It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. +5.1.13.2.3  QoS +It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. +It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. +5.1.13.2.4  STA +The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). +5.1.13.2.5  AP +The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). +5.1.13.2.6  WiFi  Direct +It  shall  comply  with  Wi-Fi  Direct  standard. +It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. +Page  107  of  159 + + -------------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **(Reference)** + > + > **Support  in  Wi-** + > + > **Fi  Direct** + ----------- ---------------------------------------------------- -------------------------- ------------------------ + > 1 > P2P  Provision > ‑ > Mandatory + > + > Discovery + + > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory + + > 3 > ‑ > Find  Phase > Mandatory + + > 4 > P2P  GO  Negotiation > ‑ > Mandatory + + > 5 > P2P  Service  Discovery > ‑ > Option + + > 6 > P2P  Invitation > Temporary  P2P  Group > Option + + > 7 > ‑ > Persistent  P2P  Group > Option + + > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option + + > 9 > Intra-BSS  Distribution > ‑ > Option + + > 10 > Concurrent  Operation > ‑ > Option + + > 11 > P2P  Service  Discovery > UPnP > Option + + > 12 > ‑ > Bonjour > Option + + > 13 > ‑ > Wi-Fi  Display > Option + + > 14 > ‑ > WS-Discovery > Option + + > 15 > ‑ > Vendor  specific > Option + -------------------------------------------------------------------------------------------------------------------- + +![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.13.2.7  Miracast +Page  108  of  159 + + -------------------------------------------------------------------------------------------------------------- + > ‑**No.** > **Feature** > ‑ > **(Refere** + > + > **nce)** + > + > **Suppor** + > + > **t        in** + > + > **Miracas** + > + > **t** + ------------ ----------------------------------------------------- ----------------------- ------------------- + > 1 > WFD  Device  type > WFD  Source > Mandat + > + > ory + + > 2 > ‑ > Primary  Sink > Mandat + > + > ory + + > 3 > ‑ > Dual-role  possible > Option + + > 4 > WFD  Service > ‑ > Option + > + > Discovery + + > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat + > + > ory + + > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option + + > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option + > + > Group + + > 8 > ‑ > via  TDLS > Option + + > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat + > + > ory + + > 10 > WFD  Session  Establishment  (RTSP) > Mandat + > + > ory + -------------------------------------------------------------------------------------------------------------- + +![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  comply  with  Miracast  standard. +It  shall  support  the  Miracast  functions  identified  in  Table  30. +Page  109  of  159 + + --------------------------------------------------------------------------------- + > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat + > + > ory + ------ --------------------------------------------------- ----------- ---------- + > 12 > WFD  Standby  (RTP/RTSP) > Option + + > 13 > Video  CODEC  formats > Option + + > 14 > Audio  CODEC  formats > Option + + > 15 > UIBC > Generic + + > 16 > HIDC + --------------------------------------------------------------------------------- + +![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.13.2.8  WiFi  Hotspot +It  shall  comply  with  Wi-Fi  Hotspot  standard. +In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot +service. +In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. +5.1.13.2.9  DLNA  via  WiFi +The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. +**5.1.14  Window  System** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +and  a  routing  of  user  interactions. +Page  110  of  159 +![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.2  Automotive  Services +Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but +contains  services  specialized  for  automotive  applications. +**5.2.1  Audio  Services** +BTBF,  equilization,  mult-zone  audio  control,  etc. +**5.2.2  Camera  Services** +Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. +**5.2.3  Configuration  Services** +Service  for  storing  configuration  parameters. +**5.2.4  Diagnostic  Services** +Diagnostic  services. +(This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) +**5.2.5  Multimedia  Services** +CD,  DVD,  Blu-Ray,  MP3,  etc. +(Factor  out  metadata  into  separate  component.) +**5.2.5.1  Media  Player** +In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just +Page  111  of  159 +![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video +devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, +there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- +seat  passengers  as  well  as  driver  all  having  independent  requirements. +The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: +· +Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the +ones  encountered  in  mobile  and  desktop  world. +· +Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) +and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or +establishes  a  network  connection.) +· +Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of +audio  /  video  processing  chains. +Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data +processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in +comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from +navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from +Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so +on. +It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore +processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing +offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with +particular  implementation  freedom  left  for  a  silicon  vendor. +The  following  requirements  formalize  these  considerations. +**5.2.5.2  Requirements** +5.2.5.2.1  Media  Containers +AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This +includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It +shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable +input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated +from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall +be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. +Page  112  of  159 +![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, +for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream +identification  data  from  media  container. +AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: +· HTTP +· RTPS +· Digital  Radio  (DAB) +· DigitalTV  (DVB-T)  etc. +It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with +system  requirements. +AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload +computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such +extension,  if  available,  shall  be  transparent  to  the  applications. +Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. +AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the +source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without +intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this +process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of +particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from +multiple  choices. +AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall +support  the  following  functionality: +· +Selection  of  data  source  and  destination  (files,  devices,  network  resources) +· Pausing/resuming  of  multimedia  streams +· Rewinding  in  forward  and  reverse  directions  (for  playback) +· Audio  volume  control  on  per-stream  basis +· Retrieval  of  current  stream  position  (timestamp) +Page  113  of  159 +![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +Notifications  on  error  conditions  preventing  multimedia  stream  processing +AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved +into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to +specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to +specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw +audio/video  streams  to  multiple  renderers  as  well. +AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and +synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: +· +Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. +· Per-stream  volume  and  audio  effects  control. +· +Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). +· +Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). +· Mixing  and  broadcasting  of  the  audio  streams. +AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to +specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or +removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, +emergency  system  alarm  output  and  so  on. +AGL  shall  provide  support  for  major  multimedia  containers,  such  as: +· MPEG2-TS/PS  (ISO/IEC  13818-1) +· MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) +It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with +system  requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: +· OGG  (RFC  3533) +· 3GPP  (ISO/IEC  14496-12) +· etc +Page  114  of  159 +![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.2.5.2.2  Media  Audio  Codecs +AGL  shall  provide  support  for  major  audio  codecs,  such  as: +· +MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) +· AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) +It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system +requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: +· VORBIS  (http://xiph.org/vorbis/) +· Windows  Media  Audio +· etc. +5.2.5.2.3  Media  Video  Codecs +AGL  shall  provide  support  for  major  video  codecs,  such  as: +· MPEG-2  (ISO/IEC  13818-2) +· MPEG-4  Part  2  (ISO/IEC  14496-2) +· H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) +It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system +requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: +· Theora  (www.theora.org) +· Windows  Media  Video +· etc +5.2.5.2.4  Image  File  Formats +Page  115  of  159 +![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true +colour. +Compression  formats +· RLE  8  bits/pixel +· RLE  4  bits/pixel +· Bit  field  or  Huffman  1D  compression +· JPEG  or  RLE-24 +· PNG +The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including +Exchangeable  Image  File  Format  (EXIF)  format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, +including  transparency +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced +version  89a  and  also  animation  in  GIFF  images. +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +format. +**5.2.6  Navigation  Services** +Navigation  engine +Page  116  of  159 +![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.7  PIM** +Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. +**5.2.8  Smartphone  Link** +This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which +realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation +is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and +AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use +smartphone  content  (map,  music,  browser...)  by  IVI. +Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. +**Figure:  8-30** +Page  117  of  159 +![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  defines  following  requirements  of  Smartphone  link. +1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. +2.  The  sound  of  smartphone  shall  be  linked  to  IVI. +3.  The  sound  shall  be  synchronized  with  the  screen. +4.  IVI  should  operate  smartphone. +5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. +6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should +inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. +This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone +link. +**5.2.8.1  Miracast** +This  section  describes  requirements  regarding  Smartphone  link  (Miracast). +Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- +Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing +between  source  device  and  sink  device. +Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. +**Figure:  8-31** +Page  118  of  159 + + ---------------------------------------------------------------------------------------------- + > **No** > **Requires** > **Description** + ------------ ----------------------------- --------------------------------------------------- + > SPL.1.1 > WFD  Topology > Define  role  of  Miracast + + > SPL.1.2 > Connection  Topology > Define  connection  condition  between + > + > a  smartphone  and  an  IVI + + > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi + > > + > 1 > Direct). + + > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency + > + > 2 + + > SPL.1.3 > Video  Format > Define  Video  format + + > SPL.1.4 > Audio  Format > Define  Audio  format + + > SPL.1.5 > Session  Control > Define  Miracast  session  state + + > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required + > + > for  implementing  Miracast + + > SPL.1.7 > Resource  Management > Define  resource  management + ---------------------------------------------------------------------------------------------- + +![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. +**References** +\[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 +\[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 +\[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision +2.2 +\[4\]  DCP  (Digital  Content  Protection)   +AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. +Page  119  of  159 +![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +SPL.1.8 Fail-safe  Control Define  Fail-safe  control +**Table  8-14:  Smartphone  Link  (Miracast)  Requirements** +**Figure:  8-32  State  Change  Diagram** +The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. +Page  120  of  159 + + ------------------------------------------------------------------------------------------------------- + > **No.** > **State** > **Description** + ----------- ------------------------- ----------------------------------------------------------------- + > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. + + > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and + > + > waiting  for  Wi-Fi  P2P  connection  from  source + > + > device. + + > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source + > + > device. + + > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. + + > 5 > Play > Streaming  the  audio  and  video  content  from  source + > + > device  to  sink  device. + + > 6 > Pause > Paused  the  streaming  of  audio  and  video  content + > + > from  source  divide  to  sink  device. + ------------------------------------------------------------------------------------------------------- + +![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.8.2  Smart  Device  Link** +“Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. +Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach +makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s +distraction  and  voice  recognition. +That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote +procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework +and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. +SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile +phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported +applications  can  be  launched. +Page  121  of  159 +![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  8-33  :  SDL  overview** +**5.2.8.3  Requirements** +5.2.8.3.1  Miracast +System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. +· +Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which +from  Source  Device‑Smartphone‑. +· Supporting  WFD  Source  is  an  option. +· +Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) +source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). +· +Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take +measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over +5Km/H) +· Support  Wi-Fi  P2P  connection. +· +Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in +Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. +· Wi-Fi  TDLS  connection  is  an  option. +· +AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select +Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) +· +AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive +Page  122  of  159 +![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for +confirmation) +· +Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. +· +Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P +connection  established. +· +Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. +· +Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) +function  if  support  5GHz  band. +· Follow  reference  \[1\]  for  Video  Codec. +· Support  follow  format  for  Video  Resolution  and  Frame  rate. +o 640\*480‑VGA‑‑Progressive  60  fps +o 1280\*720‑HD‑Progressive  30  fps +Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. +· Support  follow  format  for  Audio. +o LPCM  48ksps  16bit  2ch +o AAC  48ksps  16bit  2ch +Regarding  Audio  Format,  other  formats  are  an  option. +When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up +notification) +Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support +content  protection  function. +· +AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not +define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for +Page  123  of  159 +![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +vendor’s  own  reason. +· Support  both  encryption  cases  if  support  HDCP  function. +o Case1  Videos  data  encryption +o Case2  Both  video  and  audio  encryption +Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to +DCP.(reference  \[4\]) +· +Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, +then  Miracast  release  screen  and  audio  resources  for  the  event. +· +It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast +session.) +· +Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events +happen. +o Failed  to  Wi-Fi  connection +o Failed  to  establish  Miracast  session +o Wi-Fi  link  loss  on  Miracast +o Break  Miracast  connection  from  smartphone +5.2.8.3.2  Smart  Device  Link +System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. +System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. +System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel +device  of  IVI  device. +System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice +Page  124  of  159 +![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +recognition  of  IVI  system. +System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity +method  must  be  supported  Bluetooth  and/or  Wi-Fi. +System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity +method  must  be  supported  Bluetooth  and/or  Wi-Fi. +**5.2.9  Speech  Services** +The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. +AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands +AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech +**5.2.10  Tuner  Services** +The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into +the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, +TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present +in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. +**5.2.10.1  Receivers** +The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including +AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any +number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from +the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current +content. +The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into +the  same  API  regardless  of  the  receiver  type. +Page  125  of  159 +![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow +its  clients  to  address  each  receiver  in  the  system  independently. +5.2.10.1.1  HD  Radio +HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An +HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to +provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the +receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The +HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the +iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional +design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by +iBiquity  Digital. +The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the +requirements  in  this  section. +1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. +2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. +3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. +Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is +applicable  to. +AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status +to  the  system. +AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the +tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning +successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio +output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No +Reception"  is  available  in  that  specific  channel. +AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +Page  126  of  159 +![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Frequency +· Mono/Stereo +FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +· Frequency +· PI  Code  (RDS  only) +· PTY  (RDS  only) +· Radio  Text  (RDS  only) +· PS  Name  (RDS  only) +· Category  (RDS  only) +· Mono/Stereo +HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +· Frequency +· PTY +· No  of  HD  channels  available +· Radio  Text +· Channel  Name +· Category +· Bit  rate +· Station  Logo +· Artist  Experience +The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. +The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal +strength. +AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. +Page  127  of  159 +![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be +possible  to  adjust  by  software. +· Range:  15  –  40  dBµV +· Step:  1  dBµV +· Default:  20  dBµV +· +Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity +level.  TBD,  Supplier  to  suggest  solution. +AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be +possible  to  adjust  by  software. +· Range:  20  –  40  dBµV +· Step:  1  dBµV +· Default:  34  dBµV +· +It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. +different  for  night  and  day). +The  system  shall  be  able  to  switch  between  AM  and  FM  bands. +HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the +SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance +with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +Information  Service  Transport". +HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the +SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance +with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +Information  Service  Transport". +HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. +Page  128  of  159 +![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. +· Song +· Artist +· Album +· Genre +· Comments +· Commercial +· Reference  Identifier +The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification +"HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" +FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the +system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, +Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency +range  from  87,5  MHz  to  108,0  MHz". +FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled +the  system  shall  indicate  this. +FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. +FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. +FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. +FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. +FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. +FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received +through  RDS. +Page  129  of  159 +![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. +FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. +FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. +FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. +FM/HD  system  shall  be  able  to  enable/disable  regionalisation. +FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. +FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) +reception. +FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. +FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. +FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. +HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. +HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. +AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. +AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. +*HD system shall extract the album name, artist name, track number from the audio stream a*nd +Page  130  of  159 +![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +present  to  the  system. +The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The +feature  will  be  able  to  store  at  least  50  tags. +*5.2.10.1.1.1  Configuration* +AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration +file. +AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. +AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local +configuration  file. +5.2.10.1.2  Database  Requirements +AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains +the  following  attributes: +· Frequency +· PTY  (FM  &  HD  only) +· Channel  name  (FM  &  HD  only) +· Channel  icon  (HD  Only) +· Category  (FM  &  HD  only) +AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following +conditions: +· New  channel  is  found +· Existing  channel  disappears +· +Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list +database. +Page  131  of  159 +![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present +to  the  system. +AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the +frequency,  and  present  to  the  system. +FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, +and  present  to  the  system. +AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following +information: +· Station  name  (FM  and  HD  only) +· Frequency +· Status  of  HD  (HD,  HD1,  HD2) +· HD  SIS  (HD  only) +AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: +· Favourite  station  changed +· Favourite  station  is  removed +· New  favourite  is  added +**5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** +Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from +applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and +LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of +VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main +functions. +· Vehicle  Data  Processing +· Communication  between  ECUs +· Vehicle  Data  Upload +Page  132  of  159 +![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Simulator +**Figure  7-27  :  Overview  of  Vehicle  Info  Control** +**5.2.11.1  Vehicle  Data  Processing** +Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, +personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application +and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. +· +Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature +· User  Information,  such  as  a  name,  taste,  etc.  of  a  driver +· The  operation  history  of  a  driver +Page  133  of  159 +![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle +conditions,  such  as  speed  and  day  and  night +Vehicles  data  processing  consists  of  the  following  functional  elements  further. +(1)  Abstraction  of  Vehicles  Data +In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind +of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving +speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for +application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles +data  of  the  same  implications  and  the  same  unit. +(2)  Maintenance  of  Vehicles  Data +Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past +value  (history). +(3)  Application  /  Middleware  Interface  (API) +The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. +Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and +the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data +restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance +(access  control). +(4)  Vehicles  Interface +It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN +and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the +exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. +However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more +Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In +addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. +**5.2.11.2  Communications  between  ECUs** +Page  134  of  159 +![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +which  each  ECU  can  access. +**5.2.11.3  Vehicle  Data  Upload** +When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +which  each  ECU  can  access. +**5.2.11.4  Simulator** +In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is +unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes +development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel +controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be +an  option. +**5.2.11.5  Requirements** +The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application +and/or  middleware  can  access  vehicle  information. +The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract +property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but +the  speed  of  a  car. +System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. +Page  135  of  159 +![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  support  typical  vehicle  property  as  “standard  property”. +As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. +System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. +A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard +property. +Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) +The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or +middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough +as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile +display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. +A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is +stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the +load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and +spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. +It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In +corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. +· +The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the +accumulated  newest  value  is  less  than  a  threshold  value. +· +Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the +newest  accumulation. +About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need +to  be  able  to  set  up  easily. +In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. +System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property +access. +System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or +middleware. +Page  136  of  159 +![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Below  attributes  must  include  in  this  interface +· Zone(optional) +· Property  name +· Value +· +Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application +and/or  middleware. +Below  attributes  must  include  in  this  interface. +· Zone(optional) +· Property  name +· Value +System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from +application  and/or  middleware. +When  status  changed,  system  must  invoke  callback  function  with  below  attributes. +· Zone(optional) +· Property  name +· Value +· Timestamp +· Sequence  number +Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +Sequence  number  is  useful  to  check  event  order. +The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of +change  of  vehicle  information. +In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an +acceptable  value  even  if  vehicle  information  changes. +For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the +application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of +change. +Page  137  of  159 +![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. +· +The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the +value  from  the  last  notice  of  change  is  less  than  specification. +· +Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a +definite  period  of  time,  it  does  not  notify. +Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the +time  of  change. +What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified +notice  interval  is  made  possible. +The  data  stored  is  acquired  collectively. +Below  attributes  must  include  in  this  interface. +· Zone(optional) +· Property  name +· Values +· Timestamps +It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 +seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. +There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual +in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed +simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the +newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to +recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information +relevant  to  mutual  and  to  access  it. +Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle +information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, +and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all +those  vehicle  information  at  the  time  of  reference. +The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. +Or  the  thing  which  can  be  changed  from  a  program  during  operation. +Page  138  of  159 +![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property +"velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be +accessed  from  all  applications. +System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same +property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only +application  C  can  set  this  property. +Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control +policy  may  be  different  per  car  type,  grade  and  destination. +System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU +and  across  two  or  more  ECU’s. +If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, +middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, +the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware +which  exist  in  a  different  ECU. +VIC  can  be  requested  to  set  the  value  specified  as  Property. +It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. +The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand +from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. +Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application +responds. +It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed +easily. +The  data  exchange  between  ECUs  should  be  permitted  by  VIC. +All  data  transmission  and  reception  from  other  Software  Component  are  refusing. +Page  139  of  159 +![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. +The  vehicle  information  to  upload  is  being  able  to  choose. +A  selection  condition  is  that  the  following  specification  is  possible  at  least. +· Date-and-time  range +· Object  vehicles  data +· The  change  threshold  value  of  vehicles  data +Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be +able  to  change  dynamically  from  an  external. +The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as +substitution  of  actual  vehicles  in  development  environment  is  prepared. +Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing +activities  through  a  vehicles  interface  function  at  least. +· Speed +· Shift  position +· The  direction  of  vehicles +· Latitude  and  longitude  of  a  current  position +· Turn  signal +The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, +it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. +VIC  should  fill  the  following  performance  specifications  and  performance. +It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +information  machines  and  equipment  in  2016. +Page  140  of  159 +![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Maximum  number  of  properties  :  4,096 +· Maximum  number  of  property  sets:  1,024 +· Greatest  data  storage  time :  12  hours +It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +information  machines  and  equipment  in  2016. +· Get/Set  method(one  property)  -  0.2ms +· Get/Set  method(property  set  include  30  properties)  -1.3ms +· Subscribe  callback  -  2.5ms  (after  change  of  a  value) +· +GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms +· +GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms +VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility +about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and +attribute  of  vehicles  data. +Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by +various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add +and  change  Vehicle  Interface  without  reconstruction  of  VIC. +Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is +necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. +However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness +vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more +concreteness  vehicles  data  into  one  abstract  vehicles  data. +Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be +mounted  in  the  VIC  itself. +In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be +added  without  reconstruction  of  VIC  is  prepared  for  VIC. +**5.2.12  Telematics  Services** +V2V,  V2I,  RVI,  Traffic  information,  etc. +Page  141  of  159 +![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.13  Window  System** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +and  a  routing  of  user  interactions. +AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple +processes  to  be  rendered  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to +achieve  flicker  less  rendering. +AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- +screen  buffers. +AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying +objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. +AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos +group  available  to  clients  for  their  rendering. +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by +configuration. +AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the +*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a +Page  142  of  159 +![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The +window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES +2.0  API  are  responsible  for  a  hardware  abstraction. +AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. +AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple +displays. +AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, +where  available. +AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware +acceleration  capabilities. +AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs +from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a +vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the +vehicle  reaches  to  the  certain  speed. +AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, +a  touch  panel,  a  control  knob  etc. +AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input +from  available  physical  input  devices. +**6   Security   Services** +Security  framework +6.1  Access  Control +Access  Control  describes  requirements  for  AGL  Access  Control. +Page  143  of  159 +![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. +**6.1.1  Requirements** +AGL  system  must  support  a  system-wide  access  control  mechanism. +**7   Operating   System   Layer** +7.1  Kernel +**7.1.1  Linux  Kernel** +Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new +release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years +for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and +kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the +rest  of  the  open  source  community  provides, +**7.1.1.1  Requirements** +AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. +At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive +industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully +aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by +Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to +accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to +regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with +the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. +AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on +particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. +Page  144  of  159 +![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +7.2  Boot  Loader +7.3  Hypervisor +TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level +virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI +systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android +and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on +top  type1  hypervisor. +**7.3.1  Requirements** +AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that +have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The +processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. +AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following +functionality  shall  be  supported  by  AGL  Linux  “guest”: +· IPC  (with  hypervisor  and  other  “guests”) +· +“paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless +virtualization  abstraction  is  supported  by  hardware) +7.4  Operating  System +**7.4.1  File  Systems** +File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability +as  their  main  characteristics. +· +*Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, +tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process +environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management +techniques. +Page  145  of  159 + + ------------------------------------------------------------------------------- + > **FS  Requirements** > **R-FS  References** + ------------------------------------------------------ ------------------------ + > 6.  File  Systems  (P1) > 2.  btrfs + > > + > 6.1.  Robust  File  System  for  managed  internal > 2.1. + > > + > storage  (P1) > btr + > > + > 6.1.1.  Power  failure  tolerance  (P1) > fsc + > > + > 6.1.2.  Quick  recovery  after  power  loss > k + > > + > (P1) > 3.  ext2 + > > + > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. + > > + > 6.1.4.  On-demand  integrity  checker  (P1) > e2 + > > + > 6.1.5.  Read-only  mode  (P1) > def + > > + > 6.1.6.  Non-blocking  unmounting  (P1) > rag + > > + > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 + > > + > performance  if  it  may  degrade  under > 5.  ext4 + > > + > certain  conditions.  (P2) > 5.1. + > > + > 6.1.8.  File  space  pre-allocation  (P2) > e4 + > > + > 6.1.9.  Meta-data  error  detection  (P2) > def + > > + > 6.1.10.  File  data  error  detection  (P2) > rag + > > + > 6.1.11.  Online  integrity  checking  (P2) > 5.2. + > > + > 6.1.12.  Write  timeout  control  (P2) > e2f + > > + > 6.1.13.  Compression  support  (P2) > sck + > > + > 6.1.14.  Quota  support  (P2) > 6.  vfat + > > + > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS + > > + > 6.1.16.  File  system  event  notifications > 8.  Generic + > + > tools  and + > + > APIs + > + > 8.1. + > + > fan + ------------------------------------------------------------------------------- + +![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +*Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing +designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. +· +*Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual +packages,  and  availability  of  file  system  checking  and  optimization  tools. +![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 +(P2) +6.1.17.  Logical  block  size  control  (P2) +6.1.18.  Snapshots  (P2) +6.2.  File  System  for  non-managed  internal +storage  (P1) + +May  28,  2015 + +otif + +y + +8.2. + +fst + +rim + +6.2.1.  All  P1  requirements  from +FS.1.1.x  list  (P1) +6.2.2.  Wear  leveling  (P1) +6.2.3.  Error  detection/correction  (P1) +6.2.4.  Tolerance  to  flipping  bits  (P1) +6.2.5.  Read/write  disturb  awareness +(P1) +6.2.6.  Bad  block  management  (P1) +6.2.7.  As  many  P2  requirements  from +FS.1.1.x  list  as  possible  (P2) +6.2.8.  Wear  leveling  statistics  (P2) +6.3.  File  Systems  for  removable  storage  (P1) +6.3.1.  Restricted  functionality  from +security  point  of  view  (P1) +6.3.2.  Automount/autounmount  (P1) +6.3.3.  Automatic  synchronous  flushing +of  modified  data  to  physical  media  (P2) +**7.4.1.1  Requirements** +AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +memory),  removable  managed  (USB  stick,  SD  card). +AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, +Page  147  of  159 +![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, +AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. +A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, +and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. +A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power +interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should +not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. +Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- +write)  operation. +A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple +threads  and/or  processes  simultaneously. +A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. +A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical +storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” +command. +AGL  must  support  “lazy”  (delayed)  unmounting. +AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged +file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. +Another  example  is  periodic  fstrim  execution  on  SSD  storage. +A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This +may  be  used  to  minimize  fragmentation  of  frequently  written  files. +A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. +Page  148  of  159 +![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored +data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. +A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. +A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical +media. +A  file  system  should  support  automatic  data  compression. +It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. +AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. +AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. +Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O +performance,  and  decrease  file  fragmentation  impact. +A  file  system  should  allow  creation  of  snapshots. +A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of +erase/program  cycles  is  evenly  distributed  across  all  device  blocks. +A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. +A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also +actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power +interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the +time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. +A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb +Page  149  of  159 +![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known +techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a +fresh  block  after  detected  error  correction. +A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system +users. +Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. +A  file  system  must  support  noexec,  and  nodev  mount  options. +A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and +automatically  unmount  it  when  unplugged. +A  file  system  must  support  sync  mount  option. +AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +memory),  removable  managed  (USB  stick,  SD  card). +**7.4.2  Resource  Control** +In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be +higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource +allocation  for  each  process  and/or  process  group. +(cgroups) +**7.4.2.1  Use  Case  and  Role** +If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current +position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. +On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned +Page  150  of  159 + + ------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- -------------- ---------------------------------------------------------------- + > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority + > + > process  and/or  process  group  should  be  assigned + > + > more  resource. + + > 2 > Time  slot > To  share  resource  per  time  slot. + + > 3 > Release > Forced  release  of  partially  or  whole  allocated + > + > resource. + + > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate + > + > resource  per  defined  process  group. + ------------------------------------------------------------------------------------------- + +![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  higher  priority  than  others. +Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at +the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. +Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. +AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network +bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. +**Table  9-34  :  Functions  of  System  Resource  Management** +**7.4.2.2  Requirements** +7.4.2.2.1  Priority +System  provides  a  mechanism  to  set  resource  priority  per  each  process. +Page  151  of  159 +![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. +This  interface  must  be  called  from  other  process. +CPU  resource  must  support  “priority”  based  resource  management. +Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the +status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. +Resource  Manager  should  log  the  status  of  resources  using  by  system. +Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of +kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high +priority  tasks. +7.4.2.2.2  Time  Slot +When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a +mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each +processes. +System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. +System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage +bandwidth  and  network  bandwidth. +Scheduler  should  detect  the  status  of  resources  for  each  thread. +Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. +Scheduler  should  guarantee  that  threads  can  run  periodically. +Scheduler  should  control  the  dispatches  that  occur  extremely. +Page  152  of  159 +![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +7.4.2.2.3  Release +System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by +specific  process. +System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. +7.4.2.2.4  Grouping +System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource +management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same +attributes  to  grouped  processes  altogether. +System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. +System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and +network  bandwidth. +**7.4.3  Startup/Shutdown  Control** +Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a +user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending +on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which +boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and +“dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. +**7.4.3.1  Use  Cases** +(1)  Static  Modification  of  Boot/Shutdown  Order +a. +Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration +To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown +for  all  programs  running  on  the  target  device. +Page  153  of  159 +![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b. +Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development +In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed +program  in  target  programs. +c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update +Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. +(2)  Dynamic  Modification  of  Boot/Shutdown  Order +a. +Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using +It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to +be  operated  by  priority  when  ACC  turns  ON. +b\. Prioritized  Boot  of  Update  Functionalities +Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned +ON. +**7.4.3.2  Requirements** +Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. +Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that +has  been  configured. +Boot/Shutdown  Control  shall  start  independent  components  in  parallel. +Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. +Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that +has  been  configured. +Page  154  of  159 +![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. +**7.4.4  Database** +Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee +database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system +database  engine  is  rich  set  of  bindings  to  various  programming  languages. +Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References +hierarchy. +1.  Power  failure  tolerance  (P1) +2.  Quick  recovery  after  power  loss  (P1) +3.  Multi-threaded  I/O  (P1) +4.  API  bindings  for  C  programming  language +5.  On-demand  integrity  checker  (P2) +DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write +DB  transactions. +DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. +Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power +failure  on  idle  system. +DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or +processes  simultaneously. +DB  engine  API  must  be  available  for  C-based  applications. +DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. +DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power +interruption  during  adding  some  data. +Page  155  of  159 +![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, +such  as  vehicle  information  database  and  databases  at  data  center. +And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. +Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption +during  merging. +**7.4.5  System  Update** +Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are +numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, +bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to +power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. +System  Update  module  should  have  a  Robust  version  up  function. +System  Update  moduleshould  have  a  system  difference  version  up  function. +There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +apt  of  Linux  distribution). +There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +apt  of  Linux  distribution). +Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. +If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should +be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. +If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during +update)  should  be  detected  and  the  system  should  restart. +Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. +Page  156  of  159 +![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Memory  usage  for  difference  update  should  be  maximum  1Mbyte. +Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. +System  Update  moduleshould  have  full  version  up  function  for  whole  system. +Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow +mass  update. +There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. +If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +7.5  Device  Drivers +Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. +**7.5.1  Peripherals** +Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. +The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and +data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For +optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less +than  50  s/byte  average. +The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles +and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or +EEPROM  is  not  allowed. +Page  157  of  159 +![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be +fast.  (target  <1ms/byte) +N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. +**7.5.2  Graphics  Drivers** +Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. +This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. +**7.5.3  Video  Drivers** +Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video +codecs  will  nearly  always  be  hardware  based. +**7.5.3.1  Requirements** +The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video +functionality. +**7.5.4  Audio  Codecs** +**7.5.4.1  Requirements** +Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are +implemented  in  hardware. +Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs +that  are  required  for  AGL-based  products  and  not  supported  in  hardware. +**7.5.5  Automotive  Devices** +Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or +*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* +Page  158  of  159 +![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for +navigation  or  an  air  bag  sensor  for  a  telematics  system. +**8   Notices** +Linux  is  a  registered  trademark  of  Linus  Torvalds. +The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. +Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. +Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. +MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. +AirPlay  is  a  trademark  of  Apple,  Inc. +Page  159  of  159 diff --git a/docs/agl-specs-v1.0/01-overview.md b/docs/agl-specs-v1.0/01-overview.md new file mode 100644 index 0000000..75a6410 --- /dev/null +++ b/docs/agl-specs-v1.0/01-overview.md @@ -0,0 +1,94 @@ +--- + +title : AGL Specification Overview +author: imported from Doors-ng by Fulup(iot.bzh) +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +## 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 InVehicle Infotainment(IVI)  systems,  additional  use  cases  such  as  instrument  clusters  and  and +telematics  systems  will  eventually  be  supported.  AGL  has  participants  from  the  Automotive, +Communications,  and  Semiconductor  Industries  and  welcomes  contributions  from  individual +developers. + +By  leveraging  the  over  \$10B  of  investment  made  in  the  Linux  kernel  and  other  open  source +software  projects,  the  AGL  Workgroup: + +Enables  rapid  software  innovation  for  automotive  suppliers  to  keep  up  with  the  demand +from  consumers  for  better  IVI  experiences· + +Utilizes  the  talents  of  thousands  of  open  source  software  developers  dedicated  to +maintaining  the  core  software  in  areas  like  the  Linux  kernel,  networking,  and +connectivity,  used  in  systems  across  numerous  industries +The  goals  of  the  Automotive  Grade  Linux  Workgroup  are  to  provide: + +An  automotive-focused  core  Linux  operating  system  stack  that  meets  common  and +shared  requirements  of  the  automotive  ecosystem  with  a  broad  community  of +support  that  includes  individual  developers,  academic  organizations  and  companies. + +A  transparent,  collaborative,  and  open  environment  for  Automotive  OEMs,  Tier  One +suppliers,  and  their  semiconductor  and  software  vendors  to  create  amazing  in-vehicle +software. + +A  collective  voice  for  working  with  other  open  source  projects  and  developing  new  open +source  solutions. + +An  embedded  Linux  distribution  that  enables  rapid  prototyping  for  developers  new  to +Linux  or  teams  with  prior  open  source  experience +This  results  in  faster  time  to  market  by  jump-starting  product  teams  with  reference  applications +running  on  multiple  hardware  platforms. +Page  5  of  159 + + **Term** | **Definition** + ----------| ------------------------------------------ + A2DP | Advanced  Audio  Distribution  Profile + AGL | Automotive  Grade  Linux + AVRCP | Audio  Video  Remote  Control  Profile + FS | File  System + GPS | Global  Positioning  System + GPU | Graphical  Processing  Unit + +Automotive Grade Linux Requirements Spec v1.0![](media/picture95.png) +{: class="image"} + + +## Document  Scope + +[comment]: May  28,  2015 +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. + +## 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 diff --git a/docs/agl-specs-v1.0/02-architecture.md b/docs/agl-specs-v1.0/02-architecture.md new file mode 100644 index 0000000..7bad304 --- /dev/null +++ b/docs/agl-specs-v1.0/02-architecture.md @@ -0,0 +1,13 @@ + +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 diff --git a/docs/agl-specs-v1.0/03-homescreen.md b/docs/agl-specs-v1.0/03-homescreen.md new file mode 100644 index 0000000..22a56c3 --- /dev/null +++ b/docs/agl-specs-v1.0/03-homescreen.md @@ -0,0 +1,8246 @@ +--- + +title : App/HMI HomeScreen +author: imported from Doors-ng by Fulup(iot.bzh) +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +## Overview +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. + +** 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 + +## 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. + +## 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. + +## 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. + +## 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 + +##  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 + + +## 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 +##  Requirements + +### 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. + +###  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. + +###  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 +### 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. + +##   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 + +### Application  Manager +Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application +lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. + +###  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. + +###  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 +####  Use Case +Please  refer  “screen  resource  control”  of  Policy  Manger  section. + +####  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 +#### Requirements +4.1.2.3.1  Window  Drawing +System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and +make  invisible. +System  must  provide  a  mechanism  to  create  and  delete  surface. +When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. +This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. +System  must  provide  a  mechanism  to  change  visibility  per  each  surface. +And,  provide  an  interface  to  change  visibility. +All  the  surfaces  must  be  set  to  invisible  for  initial  state. +Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. +System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between +previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. +*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt +Page  23  of  159 +![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +from  size  of  surface. +If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  squeeze. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  using  combination  of  scaling  and  trimming  function. +That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  using  combination  of  scaling  and  background  color. +That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This +mechanism  makes  it  possible  to  do  “letterbox”  method. +4.1.2.3.2  Overlay  of  Multiple  Windows +System  must  provide  a  mechanism  to  create  and  delete  a  layer. +Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by +their  z-order  attribute. +Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, +then,  attached  layer  must  be  changed. +System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. +Area  is  a  concept  which  defines  where  to  display  in  specific  layer. +System  must  provide  a  mechanism  to  attach  surface  to  any  layer. +Also,  system  must  be  able  to  change  attached  layer. +And,  provide  an  interface  to  attach  and  change. +Page  24  of  159 +![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. +And,  provide  an  interface  to  assign  surface  to  any  area. +System  must  provide  a  mechanism  to  change  visibility  per  each  layer. +That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the +same  time. +And,  provide  an  interface  to  change  visibility  per  layer. +Initial  state  must  be  set  to  invisible. +System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each +layer,  and  disposition  of  surfaces. +4.1.2.3.3  Visual  Affect +System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was +happened. +Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +- Duration +Animation  type +System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +out. +Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +plug-in  architecture. +System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. +Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +· Duration +Animation  type +System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +Page  25  of  159 +![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +out. +Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +plug-in  architecture. +System  must  provide  a  mechanism  to  make  effect  to  surface. +And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. +System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. +System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness +System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in +architecture. +4.1.2.3.4  Frame  Rate  Control +System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of +application. +System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval +of  application. +This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live +thumbnail  and  moving  surface. +4.1.2.3.5  Multiple  Hardware  Layer  Support +If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use +hardware  layers  efficiently. +· +Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers +Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback +4.1.2.3.6  Reduced  Dependency  of  Hardware +Page  26  of  159 +![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of +each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, +such  as  by  using  re-configuration. +4.1.2.3.7  Multi  Window +AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple +processes  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. +4.1.2.3.8  Compatibility +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a +standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any +hardware  specific  API. +A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. +**4.1.3  Policy  Manager** +**4.1.3.1  Overview** +4.1.3.1.1  Purpose +Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy +Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle +Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of +resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called +Page  27  of  159 +![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +“System  resources”  such  as  CPU  and  memory. +4.1.3.1.2  GUI  Resources +(1)  Definition +·  About  Control  of  GUI  Resources +AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, +speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user +or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. +**Figure  7-1:  GUI  resources** +Page  28  of  159 +![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy +Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too +much  information  distracts  the  attention  of  driver  from  driving  operations. +·  Associated  Software  Architecture +The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources +control  is  as  below. +**Figure  7-2:  Associated  Software  Expected  Use  Case** +Page  29  of  159 + + ----------------------------------------------------------------------------------------------------------------------------------------------------- + > **No** > **Component** > **Description** + > + > **.** + ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- + > 1 > Homescreen > Request  to  control  of  GUI  resources. + + > 2 > Applications > Request  to  output  or  input  of  GUI  resources. + + > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And + > + > then  provide  the  corresponding  feature  to + > + > applications  UI  such  as  input  limitation  and + > + > changing  the  theme. + + > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the + > + > definition  of  GUI  resources  such  as  role  by + > + > application  configurations. + + > 5- > Vehicle > Window  Manager + > > + > 1 > Info + > + > Control + + > 5- > Sound  Manager + > + > 2 + + > 5- > Input  Manager + > + > 3 + + > 5- > Vehicle  Info  Distributor + > + > 4 + + > 5- > User  Manager + > + > 5 + ----------------------------------------------------------------------------------------------------------------------------------------------------- + +![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  is  related  with  the  below  components. +(2)  Role +Page  30  of  159 + + ----------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ------------------------------ ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of + > > + > GUI  resource > GUI  resources. + > + > (2)  Judgment  the  GUI  resource  owner  according  to + > + > external  conditions. + + > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to + > + > judgment. + > + > (2)  Notify  the  driving  mode  and  day  night  mode + > + > that  is  calculated  by  external  conditions. + ----------------------------------------------------------------------------------------------------- + +![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  has  the  below  role. +Page  31  of  159 +![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  7-3:  Definition  of  Role** +GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each +resource  type  are  as  follows: +a.  Screen  Resource +a-1.  External  Condition  Collection +Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. +**Figure  7-4:  Definition  of  screen  resource** +•  Concept  of  Display,  Layer,  Layout  and  Area +AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one +or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout +Page  32  of  159 +![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics +window. +The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on +objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was +used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than +layer-2. +Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, +application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. +“Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and +setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert +and  enlarged  view. +When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On +the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” +layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. +From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- +order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered +by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to +individual  layer. +•  Concept  of  Layer  Owner,  Role  and  Surface +“Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of +that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of +area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy +Manager. +“Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” +change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. +One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics +window  to  display  into  one  area. +Page  33  of  159 +![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface +drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example +to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then +corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface +is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & +scan”. +**Figure  7-5:  Definition  of  Surface** +•  Subdivision  of  “Interrupt”  Layer +Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main +surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main +surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding +“Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message +is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. +According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described +as  Table  7-3. +Page  34  of  159 + + --------------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- -------------------------------------------------------- ----------------------- + > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation + > + > application  requests  this  layer  at  first  time. + + > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of + > + > navigation + + > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message + > > + > screen  service  (e.g.  Homescreen)  requests > popup + > + > this  layer. + + > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard + > > + > keyboard > Typically,  software  keyboard  service + > + > requests  this  layer. + --------------------------------------------------------------------------------------------------------- + + ------------------------------------------------------------------------------------------------------ + > **No** > **Contents** > **Summary** > **Example** + ---------- ---------------- ------------------------------------------------------- ------------------ + > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation + > + > service)  role. + + > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view + ------------------------------------------------------------------------------------------------------ + +![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +a-2.  Judgment  of  Priority  of  GUI  Resource +Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role +is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy +Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. +Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software +Page  35  of  159 +![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is +popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). +**Figure  7-6:  Definition  of  Role  and  Sub  role** +The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display +has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. +In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" +layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub +role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” +role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. +a-3.  GUI  resource  control +Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +directly. +Page  36  of  159 +![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +There  are  three  types  of  screen  resource  control: +One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. +Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was +assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. +Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue +z-order  information  for  each  layer. +b.  Sound  Resource +b-1.  External  Condition  Collection +Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. +**Figure  7-7:  Definition  of  Sound  Resource** +•  Zone +Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can +play  at  the  same  time. +Page  37  of  159 + + ------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- ---------------------------------------------- ------------------------- + > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media + > + > player + + > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of + > + > Navigation + + > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound + > + > requests  this  type. + ------------------------------------------------------------------------------------------------- + +![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +•  Sound  type +Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource +owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper +sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific +zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each +sound  stream  must  assign  to  individual  sound  type. +AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. +•  Stream +Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in +stream. +b-2.  Judgment  of  Priority  of  GUI  resource +Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role +is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy +Manager.  Figure  7-8  describes  the  definition  of  role. +Page  38  of  159 +![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  7-8:  Sample  Role** +The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that +is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or +different  sound  type  are  not  switched.  They  are  mixed. +b-3.  GUI  Resource  Control +Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +directly. +There  are  two  types  of  sound  resource  control: +One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for +sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound +Page  39  of  159 +![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +stream  and  to  start  play  latest  area  owner. +Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback +simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy +Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and +music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music +playback. +c.  Input  Resource +c-1.  External  Condition  Collection +Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. +**Figure  7-9:  Definition  of  Input  Resource** +•  Device  Name +Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. +•  Event  Type +Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and +temperatures. +c-2.  Judgment  of  Priority  of  GUI  resource +Page  40  of  159 +![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device +name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy +DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the +judgment  as  below. +**Figure  7-10:  Definition  of  routing  rule** +OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. +c-3.  GUI  Resource  Control +Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. +Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. +4.1.3.1.3  System  Resources +(1)  Definition +Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy +Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. +Page  41  of  159 + + ---------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ----------------------------- ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according + > + > to  external  condition  change. + > + > 2.  Kill  process(s)  forcibly  according  to  external + > + > condition  change. + ---------------------------------------------------------------------------------------------------- + +![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, +target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. +**4.1.3.2  Requirements** +4.1.3.2.1  Screen  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system +uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive +information  must  include  as  follows. +a.  ID +b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) +c.  DPI +d.  Connected  ECU +Page  42  of  159 +![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be +able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list +according  to  current  layout  of  each  display. +The  receive  definition  must  include  the  follows. +a.  ID +b.  Area  list +System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface +by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the +device. +The  receive  request  must  include  the  follows. +a.  Layout  ID +b.  ID +c.  Area  position  (Coordinate  of  the  upper-left) +d.  Area  size  (Length  \*  Width) +System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify +the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. +a.  Display  ID +b.  Layout  ID +System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the +providing  resource  using  it  when  the  request  is  collision. +The  receive  information  must  include  the  follows. +a.  Role +b.  Priority +System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge +driving  mode. +The  receive  information  must  include  the  follows. +a.  Velocity +Page  43  of  159 +![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Brake  status +System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge +day  night  mode. +The  receive  information  should  include  the  follows. +a.  The  brightness  of  the  interior +System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the +providing  resource  using  it. +System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should +judge  the  providing  resource  using  it. +(2)  Judgment  of  Priority  of  GUI  Resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical +resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the +resource. +The  receive  request  must  include  as  follows. +a.  Role +b.  Layer  type +The  receive  request  should  include  as  follows. +c.  Display  ID +System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by +priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on +the  specified  area  on  the  specified  layer. +The  receive  request  must  include  as  follows. +a.  Role +Page  44  of  159 +![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Layer  ID +The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. +Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the +related  basic  type  area. +c.  Area  ID +**Figure  7-11:  Sequence  to  display** +System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. +In  this  request,  requester  should  choose  below  options. +a. +Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, +but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should +be  refused. +b. +Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen +resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher +priority,  then,  only  screen  resource  should  be  assigned  to  requester. +Page  45  of  159 +![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system +running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. +The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal +request. +a.  Effective  period  (Can  set  unlimited) +System  should  not  raise  the  other  surface  above  its  during  effective  period. +System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +a.  The  effect  at  the  transition +b.  The  effect  of  display  surface +System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are +sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all +layers  will  be  superimposed  by  z-order. +System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. +System  must  hide  the  surface  that  has  too  much  information. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Visible  /  Invisible +b.  Change  position +c.  Raise +The  receive  request  must  include  as  follows. +i.  Surface  ID  \*Only  case  of  visible. +ii.  Display  ID  \*Only  case  of  visible. +iii.  Layer  ID  \*Only  case  of  visible. +Page  46  of  159 +![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. +v.  Size  (Length  \*  Width)  \*Only  case  of  visible. +System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. +a.  The  effect  at  the  transition +b.  The  effect  of  display  surface +4.1.3.2.2  Sound  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone +information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as +follows. +a.  ID +b.  Sound  device  ID +System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses +sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must +include  as  follows. +a.  ID +(2)  Judgment  of  Priority  of  GUI  resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +request  during  system  running. +Page  47  of  159 +![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  receive  request  must  include  as  follows. +a.  Role +b.  Zone  ID +c.  Sound  type  ID +System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during +system  running. +The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal +request. +a.  Effective  period  (Can  set  unlimited) +System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner +by  other  request  on  same  area  during  effective  period. +System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +a.  The  effect  at  the  transition +b.  The  effect  of  output  sound +System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more +resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority +of  resources  that  is  related  to  role. +\*  Boundary  of  the  role  between  Policy  Manager  and  application. +Page  48  of  159 +![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Figure  7-12:  Boundary  of  role  (Case  of  reverse) +System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system +should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. +For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound +from  request  history  based  on  the  priority. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Mute  /  Unmute +b.  Change  zone +The  receive  request  must  include  as  follows. +i.  Stream  ID +ii.  Device +In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. +iii.  Channel  ID +Page  49  of  159 +![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. +a.  The  effect  at  the  transition +b.  The  effect  of  output  sound +4.1.3.2.3  Input  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses +input  device  information  with  to  control  input  event  to  other  system.  The  receive  information +must  include  as  follows. +a.  ID +System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses +input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must +include  as  follows. +a.  ID +b.  Related  event  IDs +(2)  Judgment  of  Priority  of  GUI  resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +request  during  system  running. +The  receive  request  must  include  as  follows. +a.  Input  device  ID +Page  50  of  159 +![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Event  type  ID +System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the +limitation  routing  rule  of  policy  DB. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Set  the  routing  rule +The  receive  request  must  include  as  follows. +i.  Input  device  ID +ii.  Event  type  ID +The  receive  request  must  include  either  as  follows. +iii.  The  allowed  application +iv.  The  denied  application +System  should  provide  a  mechanism  to  set  the  following  information. +a.  Application  that  has  active  surface +System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This +feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen +changes  the  active  surface. +4.1.3.2.4  System  Resources +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager +to  decide  proper  system  resource. +Page  51  of  159 +![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  must  detect  creation  and  deletion  of  process. +To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created +process. +Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to +other  active  processes. +To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to +identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each +active  process. +Policy  Manager  must  detect  current  memory  consumption  periodically. +To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each +process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were +thought  as  not  so  important  process. +Policy  Manager  must  detect  current  CPU  consumption  periodically. +To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep +system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected +busy  state. +System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. +Application  status  includes  as  below. +· GUI  resource  status,  such  as  foreground  or  background. +· +Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must +resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last +application  to  resume  quickly  as  much  as  possible. +(2)  System  Resource  Control +System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process +group  according  to  external  conditions. +According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to +target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups +Page  52  of  159 +![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +will  be  used) +System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. +4.1.3.2.5  Resource  Management +Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy +Manager,  Connection  Manager. +Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. +Each  resource  request  shall  be  in  form  a: +AppID, +SourceID, +RequestorZoneID, +NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), +Required  Resource  List. +Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin +Speakers,  HeadPhones) +Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) +Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, +Tuners  etc.) +Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request +from  resource  requestors. +Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. +Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) +Page  53  of  159 +![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list +are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) +Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system +through  status  update. +Resource  Management  shall  support  stacking/queuing  of  resource  requests. +>  Receive  the  requests  from  the  resource  requestors. +>  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy +Manager. +>  Add  the  validated  requests  into  a  priority  queue. +>  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. +>  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it +shall  be  removed  from  the  queue. +Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier +request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it +shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. +If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the +requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. +If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant +some/all  of  the  resources  requested  by  the  requestor. +Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an +existing  resource  request. +Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of +policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs +for  the  policy  decision: +>  Currently  Free  or  InUse  Sink  status +>  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) +Page  54  of  159 +![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +>  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. +Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a +request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the +policy  decision: +>  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept +pending. +>  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. +At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by +resource  requestor: +>  Zone  ID +>  Allocated  Source  Instance +>  Allocated  Sink  Instance +>  Mute  status +Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality +(e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to +the  resource  management  policy. +Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature +functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). +Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: +AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have +same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, +the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. +Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, +AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource +request  will  be  the  one  that  is  granted  the  resource. +A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. +It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. +Page  55  of  159 +![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. +It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource +Manager  if  the  resource  is  no  longer  needed. +Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all +available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once +the  request  is  granted  against  the  set  policy. +Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. +Possible  connection  states  are  Active  or  Passive. +>  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be +active. +Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. +>  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be +passive. +Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same +AMFM  source  on  Rear  headphone  sink. +Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink +connection  using  the  underlying  platform  support. +Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink +connection  using  the  underlying  platform  support. +Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is +removed/released. +Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is +re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. +Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. +Page  56  of  159 +![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready +to  be  used  for  audio  routing. +Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio +routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. +Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. +Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which +source  instance. +Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: +>  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. +System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +Headphones  shall  not  be  required  to  support  any  foreground  sinks. +In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a +source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source +(if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). +As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not +disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background +connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. +Page  57  of  159 +![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State +Manager. +It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. +It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on +current  system  scenario. +E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call +is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a +pending  request. +It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. +It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. +It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video +resources  and  update  its  internal  status  accordingly. +On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active +connections  and  reconnect  or  disconnect  if  required. +E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. +Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of +connections  shall  be  rebuilt  with  Amp. +It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. +Page  58  of  159 +![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying +platform  support. +It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the +underlying  platform  support. +It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. +It  shall  provide  an  interface  to  unmute  an  audio  sink. +System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +Headphones  shall  not  be  required  to  support  any  foreground  sinks. +It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +**4.1.4  Sound  Manager** +A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from +two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a +policy  manager  manages  a  mediation  rule. +Page  59  of  159 + + ---------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ------------------------------------------------------------ + > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). + + > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume + > + > control  of  each  sound  streams. + + > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, + > + > ·     When  changing  sound  stream.  E.g.  fade-in, + > + > fade-out  and  cross-fade. + + > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce + > > + > hardware > dependency  of  hardware.  Well-defined  interface + > + > also  makes  it  possible  to  increase  the  effect  of + > + > portability  and  development  cost. + ---------------------------------------------------------------------------------------------------- + +![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a +passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound +resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. +Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like +volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server +to  implement  automatic  audio  policies. +**4.1.4.1  Use  Case** +Please  refer  “sound  resource  control”  of  Policy  Manger  section. +Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. +**4.1.4.2  Requirements** +Page  60  of  159 +![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4.1.4.2.1  Routing  Sound  Streams +System  must  provide  a  mechanism  to  manage  sound  “zone”. +Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a +zone  and  how  to  manage  zone. +System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each +channels  of  each  sound  device. +One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists +of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. +For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is +arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when +outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower +musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than +music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound +device. +The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more +zones. +Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the +present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the +mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. +System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. +System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. +All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. +System  must  provide  a  mechanism  to  control  sound  stream. +Control  of  a  sound  stream  is  as  follows. +· +Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound +stream. +· +Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound +Page  61  of  159 +![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +stream. +Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. +4.1.4.2.2  Mixing  Level  Control +The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to +the  same  zone  according  to  a  policy  manager's  arbitration. +System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. +System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream +requested  to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating +the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. +System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested +to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted +sound  stream  was  ended. +System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream +requested  to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound +stream  was  ended. +4.1.4.2.3  Sound  Effect +When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. +System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. +System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin +architecture. +Page  62  of  159 + + ------------------------------------------------------------------------------------------------------------------------- + > **No.** > **Input  type** > **Associated  device** > **Description** + ----------- ------------------- -------------------------- -------------------------------------------------------------- + > 1 > Key > Steering  switch > Simple  key  event. + > + > Deliver  to  application. + + > 2 > Keyboard > Virtual  keyboard > Keyboard  event. + > + > Deliver     to     application,     then     use     input + > + > method  backend  if  needed. + + > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. + > + > Also  supports  double  click  and  multi-touch + > + > capability. + > + > Deliver  to  application. + + > 4 > Sound > Microphone > Sound  input. + ------------------------------------------------------------------------------------------------------------------------- + +![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4.1.4.2.4  Reduced  Dependency  of  Hardware +Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels +of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means +which  does  not  need  rebuild  of  systems,  such  as  a  configuration. +**4.1.5  Input  Manager** +The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application +depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each +input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering +switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. +**4.1.5.1  Use  Case** +Please  refer  “input  resource  control”  of  Policy  Manger  section. + + --------------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ----------------------------------------------------------------- + > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to + > + > application  readable  event  name,  such  as  “volume + > + > up”  and  “right  arrow”. + + > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified + > + > application. + --------------------------------------------------------------------------------------------------------- + +![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Deliver  to  application  or  voice  recognition +engine. +Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. +**4.1.5.2  Requirements** +**4.1.5.3  Abstract  Device  Event** +System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. +Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional +equipment. +**4.1.5.4  Event  Delivery** +System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. +System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” +and  “destination  application  id”. +Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by +UIM.2.1.2. +Page  64  of  159 +![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. +System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. +System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on +delivery  rule  defined  in  UIM.2.1.1. +System  must  provide  a  mechanism  to  inhibit  any  event  delivery. +This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. +**4.1.6  User  Manager** +**4.1.6.1  Use  Case** +**4.1.6.2  Personal  Identification** +User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a +person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. +**4.1.6.3  User  Preference** +Multi-user  environment  provides  same  user  experience  for  each  user. +Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including +other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data +sharing  from  your  home  and  your  office. +Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be +provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. +Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user +experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, +*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is +Page  65  of  159 +![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. +**Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** +**4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** +When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If +Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is +important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s +preference. +**Figure  7-25  :  User  data  sharing  between  cars** +Page  66  of  159 +![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**4.1.6.5  Seamless  Data  Sharing** +Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and +smart-phones,  home  networks  and  accessing  from  your  offices. +**Figure  7-26  :  User  data  sharing  over  the  cars** +**4.1.6.6  Role** +**Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above +purpose  and  use  cases. +**Table  7-17  :  Role  of  User  Manager** +**No.** **Role** **Description** +Page  67  of  159 +![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +1 User  identification +Provide  a  mechanism  to  identify  user,  such  as  user +name  and  password  pair,  smart  key  and  biometrics. +Provide  a  mechanism  to  log-in  to  the  IVI  system  as +a  specified  user. +When a different user logs in, proper user +preference  for  the  user  must  be  applied,  and +resume  last  state  of  corresponding  user. +Also,  each  application  can  store  application’s  data +per  user.  In  such  cases,  proper  user  data  must  be +applied  when  a  different  user  logs  in. +2 User  preference +Provide  a  mechanism  to  apply  user  preference  of +logged-in  user. +User  preference  includes  the  following  data. +· User  interface,  such  as  locale  and  wall- +paper. +· Resume  last  application’s  status  of  specified +user. +· Application  specific  data. +3 User  data  management +Provide  a  mechanism  to  manage  cloud  based  user +data. +The  following  capabilities  are  required. +· Download  user  data  of  the  logged-in  user +from  the  cloud. +· Update  cloud  data  if  the  user  data  was +updated  by  user  operation  or  otherwise. +· Periodically  sync-up  w/  cloud  because  user +data  may  be  updated  by  other  devices. +In  addition  to  the  above  basic  capabilities,  user  data +cache  is  essential  for  a  car,  since  a  car  may  not +always  have  a  reliable  network  connection. +4 Security Because  cloud  based  sharing  user  data  may  be +accessed  from  any  place,  user  data  must  be +protected  from  unexpected  data  access. +Page  68  of  159 +![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +So,  IVI  system  must  provide  security  mechanism +regarding  accessing  to  cloud  based  user  data. +**4.1.6.7  Requirements** +4.1.6.7.1  User  Identification +System  must  provide  a  mechanism  to  identify  logged-in  user. +System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to +identify  logged-in  user. +System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For +example,  using  NFC. +System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. +4.1.6.7.2  User  Preference +When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the +currently  logged-in  user. +System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. +- Locale  settings +- UX  theme +Wall  paper +System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized +user  experience. +Page  69  of  159 +![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in +user’s  application  data  automatically. +When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last +status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the +system.  Specifically,  last  status  includes  the  following. +- Foreground  applications.  That  means  displayed  applications. +Background  applications. +When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. +System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. +System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. +4.1.6.7.3  User  Data  Management +System  must  provide  a  mechanism  to  manage  user  data. +AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user +preference. +User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but +also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and +home  electronics. +System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to +application  by  using  cloud  based  user  data. +System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data +of  the  IVI  system. +When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to +the  cloud. +Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide +Page  70  of  159 +![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. +Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a +mechanism  to  cache  downloaded  user  data. +If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as +possible. +4.1.6.7.4  Security +Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to +protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. +System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. +- +System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must +authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, +smartphone  or  PC. +- +System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. +- +System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection +against  falsification  of  data  from  unauthorized  access  or  illegal  access. +- +Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide +user  data  only  to  the  authorized  user. +Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must +provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to +include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against +cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. +4.2  Web  HMI +Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. +**4.2.1  Web  API** +Page  71  of  159 +![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service +function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio +visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, +Photo,  etc.) +Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of +Audio  Visual  API  is  shown  in  Figure  6-1. +**Figure  6-1:  Use  case  of  Audio  Visual  API** +**4.2.1.1  Requirements** +Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. +· Select  content  using  URL +· +Select  content  using  contents  list  provided  by  multimedia  subsystem +Page  72  of  159 +![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, +DVD,  BT-Audio,  Photo,  etc.) +· Play +· Pause +· Fast-forward +· Rewind +· Track  up +· Track  down +· Select  playmode  (Repeat/Random) +Audio  Visual  API  must  provide  API  to  control  a  volume. +· Volume  up +· Volume  down +· Mute +Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. +Audio  Visual  API  must  provide  API  for  notifications. +· The  case  that  playback  state  is  changed +· The  case  that  Audio  Visual  contents  is  add  /  removed +Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. +· Change  the  frequency. +· Change  the  broadcasting  stations. +· Receive  the  list  of  broadcasting  stations. +· Select  the  preset  channel. +· Get  the  information  of  the  broadcasting  station. +Audio  Visual  API  must  provide  API  to  play  digital  radio. +· Store  the  broadcast  program  information. +Page  73  of  159 +![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Get  the  broadcast  program  information. +· Get  the  play  time. +· Play  the  radio  broadcast  cached. +AGL  System  must  support  a  web  API  to  access  Vehicle  information. +AGL  System  must  support  web  API  to  control  STT/TTS  daemon. +AGL  System  must  support  web  API  to  control  navi  engine. +AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web +apps. +AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app +and  a  native  app. +AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider +should  be  able  to  restrict  subscriber. +AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. +AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, +Network  Information +AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG +AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio +AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, +server  sent  events,  session  history  of  browsing  context +*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL +Page  74  of  159 +![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 +The  iframe  element,  Content  Security  Policy  1.0. +AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications +AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing +control,  Navigation  timing +AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation +AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, +Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy +AGL  System  must  support  Khronos  WebGL  API. +**4.2.2  Web  Runtime** +The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access +the  AGL  Application  Framework  and  Services. +**4.2.2.1  Requirements** +AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., +installation/removal). +AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, +view  generation,  rendering,  etc.) +AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add +better  device/platform  integration. +Page  75  of  159 +![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to +categorize  apps  with  different  privileges. +System  must  provide  high  level  GUI  components  for  Web  application. +At  least,  below  components  are  required. +· Text  labels +· Button +· Radio  button +· Check  box +· Tab  panel +· Animation  (e.g.  MNG,  GIF  animation) +· Slider +· Accordion  list +· Anchor +· Text  input  form +· Dropdown  list  box +· Date  picker +4.3  Native  HMI +The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written +using  Javascript  or  other  web  technologies. +**4.3.1  Native  App  Runtime** +The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to +access  the  AGL  Application  Framework  and  Services. +**4.3.1.1  Requirements** +System  must  provide  high  level  GUI  components  for  native  application. +Page  76  of  159 +![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +At  least,  below  components  are  required. +· Text  labels +· Button +· Radio  button +· Check  box +· Tab  panel +· Animation  (e.g.  MNG,  GIF  animation) +· Slider +· Accordion  list +· Anchor +· Text  input  form +· Dropdown  list  box +· Date  picker +**4.3.2  Native  Application  Framework** +The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an +SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that +framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the +application  framework  provides  for  its  applications. +**5   Services   Layer** +The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the +services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces +remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime +modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid +unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer +interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces +provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may +choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework +runtime  to  adjust  to  any  new  interfaces, +Page  77  of  159 +![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1  Platform  Services +Platform  Services  Layer.  Conventional  Linux  platform  services +**5.1.1  Bluetooth** +This  document  describes  requirements  regarding  registration,  (dis)connection  and  device +information  management  between  Bluetooth  device  and  infotainment  system.  Necessary +Bluetooth  profiles  in  automotive  use  case  are  defined  here. +**5.1.1.1  Requirements** +The  Telephony  system  shall  be  designed  to +support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR +without  hardware  upgrade. +A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: +· Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) +· HFP  (Hands  Free  Profile) +· OBEX  (Object  Exchange) +· OPP  (Object  Push  Profile) +· PBAP  (Phonebook  Access  Profile) +· SPP  (Serial  Port  Profile) +· SDAP  (Service  Discovery  Access  Profile) +If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music +from),  the  system  shall  also  support  the  following  incremental  BT  profiles: +· A2DP  (Advanced  Audio  Distribution  Profile) +· AVRCP  (Audio  Visual  Remote  Control  Profile) +The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the +Page  78  of  159 +![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of +generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in +encryption  key  length  negotiation. +When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as +default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority +scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration +time. +The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is +10  meters  and  maximum  power  is  2.5  mW  (4  dBm). +The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall +allow  using  five-slot  packet  transmission  for  faster  data  rate. +The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a +standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. +vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are +often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain +name  and  address  information,  phone  numbers,  and  e-mail  addresses. +vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, +LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, +URL,  UID,  Version,  and  KEY  properties. +vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: +MIME  Content-Type  for  Directory  Information +vCard  MIME  Directory  Profile +It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with +the  vCard  version  2.1  properties. +The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any +associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is +not  full. +The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO +Page  79  of  159 + + ------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **Support  in  HF** > **AGL** + ----------- ------------------------------------------------------------- ----------------------- ----------- + > 1 > Connection  management > Mandatory > x + + > 2 > Phone  status  information > Mandatory > x + + > 3 > Audio  Connection  handling > Mandatory > x + + > 4 > Accept  an  incoming  voice  call > Mandatory > x + + > 5 > Reject  an  incoming  voice  call > Mandatory > x + + > 6 > Terminate  a  call > Mandatory > x + + > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x + + > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x + > + > HF + + > 9 > Place  a  call  using  memory  dialing > Option > - + + > 10 > Place  a  call  to  the  last  number  dialed > Option > - + ------------------------------------------------------------------------------------------------------------- + +![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +shall  be  used. +5.1.1.1.1  Hands  Free  Profile +The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile +specification  version  1.6  or  later. +The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, +wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and +output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to +the  actual  phone. +It  shall  provide  following  roles: +Hands-Free  unit  (HF) + + > 11 > Call  waiting  notification > Option > x + ------- ------------------------------------------------------ ---------- ---------- + > 12 > Three  way  calling > Option > x(\*1) + > 13 > Calling  Line  Identification  (CLI) > Option > x + > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x + > 15 > Voice  recognition  activation > Option > x + > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - + > 17 > Ability  to  transmit  DTMF  codes > Option > x + > 18 > Remote  audio  volume  control > Option > - + > 19 > Respond  and  Hold > Option > x + > 20 > Subscriber  Number  Information > Option > x + > 21a > Enhanced  Call  Status > Option > x + > 21b > Enhanced  Call  Controls > Option > - + > 22 > Individual  Indicator  Activation > Option > - + > 23 > Wide  Band  Speech > Option > x + > 24 > Codec  Negotiation > Option > x + +![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +\*1:  Does  not  support  Multi-party  (conference)  call +The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the +model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +string  in  a  phone  model  CGMM  variable. +· Phone  Model  CGMM: +· Type:  string +· Max  length:  200  chars +Page  81  of  159 +![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the +Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be +stored  as  a  string  in  a  phone  model  CGMI  variable. +· Phone  Model  CGMI: +· Type:  string +· Max  length:  200  chars +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the +revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +string  in  a  phone  model  CGMR  property. +· Phone  Model  CGMR: +· Type:  string +· Max  length:  200  chars +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) +The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP +specification  version  1.2  or  later. +Page  82  of  159 + + > **No.** > **Codec** > **Support** > **AGL** + ----------- ------------------- --------------- ----------- + > 1 > SBC > Mandatory > x + > 2 > MPEG-1,2  Audio > Option > - + > 3 > MPEG-2,4  AAC > Option > - + > 4 > ATRAC  family > Option > - + + > **No.** > **Feature** > **Support  in  SNK** > **AGL** + ----------- -------------------- ------------------------ ----------- + > 1 > Audio  Streaming > Mandatory > x + +![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to +realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. +It  shall  provide  following  roles: +Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from +the  SRC  on  the  same  piconet. +Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. +Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. +Copyright  protection  technology  SCMS-T  should  be  supported. +5.1.1.1.3  Phone  Book  Access  Profile +Page  83  of  159 +![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification +version  1.1  or  later. +The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between +devices. +Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The +Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected +device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing +and  copying  contact  information. +It  shall  provide  following  roles: +· Phonebook  Client  Equipment  (PCE) +It  shall  provide  following  types  of  Phonebook  objects: +· The  main  Phonebook  object +· The  Incoming  Call  History  object +· The  Outgoing  Call  History  object +· The  Missed  Call  History  object +· The  Combined  Call  History  object +A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device +automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook +download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: +· Using  PBAP  profile +All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. +SIM)  and  also  any  stored  in  the  BT  device's  memory. +The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the +vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded +from. +5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile +Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +Page  84  of  159 + + > **No.** > **Service** > **Support  in  DT** > **AGL** + ----------- ------------------------------------------- ----------------------- ----------- + > 1 > Data  call  without  audio  feedback > Mandatory > x + > 2 > Data  call  with  audio  feedback > Option > - + > 3 > Fax  services  without  audio  feedback > N/A > - + > 4 > Fax  services  with  audio  feedback > N/A > - + > 5 > Voice  call > N/A > - + > 6 > Incoming  calls > Option > x + > 7 > Outgoing  calls > Mandatory > x + +![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” +Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. +5.1.1.1.5  Object  Push  Profile  (OPP) +Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower +layers. +It  has  to  comply  with  the  specification  for  “Push  Server”. +Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. +**Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** +Page  85  of  159 + + > **No.** > **Feature** > **Support  in  CT** > **AGL** + ----------- -------------------------------------------- ----------------------- ----------- + > 1 > Connection  establishment  for  control > Mandatory > x + > 2 > Release  connection  for  control > Mandatory > x + > 3 > Connection  establishment  for  browsing > C6 > x + + ------------------------------------------------------------------------------------- + > **No** > **Feature** > **Support  in  Push  Server** > **AGL** + > + > **.** + ---------- ---------------------------- --------------------------------- ----------- + > 1 > Object  Push > Mandatory > x + + > 2 > Business  Card  Pull > Option > - + + > 3 > Business  Card  Exchange > Option > - + ------------------------------------------------------------------------------------- + +![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) +The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. +The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device +plus  one  remote  control.. +The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL +column  in  Table  25  should  be  supported. +C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional +otherwise +C3:  Mandatory  to  support  at  least  one  Category +C4:  Mandatory  if  Category  2  supported,  excluded  otherwise +C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise +EX:  Excluded +Page  86  of  159 +![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4 Release  connection  for  browsing C6 x +5 AV/C  Info  commands Option x +6 Category  1:  Player/Recorder C3 x +7 Category  2:  Monitor/Amplifier C3 - +8 Category  3:  Tuner C3 - +9 Category  4:  Menu C3 - +10 Capabilities Option x +11 Player  Application  Settings Option x +12 Metadata  Attributes  for  Current  Media  Item Option x +13 Notifications C2 x +14 Continuation C2 x +15 Basic  Group  Navigation Option x +16 Absolute  Volume C4 - +17 Media  Player  Selection Option x +17.1 -  Supports  Multiple  Players Option x +18 Browsing Option x +18.1 -  Database  Aware  Players Option x +19 Search Option - +20 Now  Playing C6 x +20.1 -  Playable  Folders Option x +21 Error  Response EX - +22 PASSTHROUGH  operation  supporting  press  and Option x +Page  87  of  159 + + ------------------------------------------------------------------------------ + > **No** > **Feature** > **Support  by  the  MCE** > **AGL** + > + > **.** + ---------- ------------------------- ----------------------------- ----------- + > 1 > Message  Notification > C1 > x + + > 2 > Message  Browsing > C1 > x + + > 3 > Message  Uploading > Option > x + + > 4 > Message  Delete > Option > - + + > 5 > Notification > C2 > x + > + > Registration + ------------------------------------------------------------------------------ + +![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +hold +The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and +pass  this  information  up  to  so  it  can  be  passed  to  the  User. +5.1.1.1.7  Message  Access  Profile +Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary +lower  layers. +It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. +Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. +C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features +C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message +Notification.  Not  applicable  otherwise. +Page  88  of  159 + + > **No.** > **Feature** > **Support  in  PANU** > **AGL** + ----------- ------------------------------------------ ------------------------- ----------- + > 1 > Initialization  of  NAP/GN  service > - > - + > 2 > Shutdown  of  NAP/GN  service > - > - + > 3 > Establish  NAP/GN  service  Connection > Mandatory > x + +![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.8  Serial  Port  Profile  (SPP) +The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version +1.1  or  later. +It  shall  provide  following  roles: +Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. +Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. +Following  features  shall  be  provided  by  the  Supplier: +Establish  link  and  setup  virtual  serial  connection +Accept  link  and  establish  virtual  serial  connection +Register  Service  record  for  application  in  local  SDP  database +5.1.1.1.9  Personal  Area  Network  (PAN)  Profile +Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. +Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. +Page  89  of  159 + + > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x + ----- ------------------------------------------- ------------- ----- + > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x + > 6 > Management  Information  Base  (MIB) > - > - + +![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.10  Service  Discovery  Profile  (SDP) +The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP +specification  version  1.1. +The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices +in  the  vicinity  of  a  Bluetooth  enabled  device. +It  shall  provide  following  roles: +Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. +Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to +the  service  inquiries  generated  by  Local  Device. +The  following  features  shall  be  provided  by  the  Supplier: +Search  for  services  by  service  class +Search  for  services  by  service  attributes +Service  browsing +5.1.1.1.11  Device  Information  Profile +Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. +**Table  28  :  List  of  DIP  Supporting  Functions** +Page  90  of  159 + + > **No.** > **Feature** > **Support** > **AGL** + ----------- ----------------------- --------------- ----------- + > 1 > SpecificationID > Mandatory > x + > 2 > VendorID > Mandatory > x + > 3 > ProductID > Mandatory > x + > 4 > Version > Mandatory > x + > 5 > PrimaryRecord > Mandatory > x + > 6 > VendorIDSource > Mandatory > x + > 7 > ClientExecutableURL > - > - + > 8 > ServiceDescription > - > - + > 9 > DocumentationURL > - > - + +![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.12  Bluetooth  Smart  Ready +Bluetooth  Smart  Ready  shall  be  supported. +It  shall  comply  with  Bluetooth  Low  Energy  standard. +5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) +The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX +specification  version  2.0  or  later. +The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between +devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. +It  shall  provide  following  roles: +Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data +objects  shall  be  pushed  and  pulled,  respectively. +Page  91  of  159 +![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. +The  following  features  shall  be  provided  by  the  Supplier: +Establishing  an  object  connection +Pushing  a  data  object +Pulling  a  data  object +Performing  an  action  on  data  objects +Creating  and  managing  a  Reliable  Object  Exchange  Connection +5.1.1.1.14  Generic  Audio/Video  Distribution  Profile +The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the +GAVDP  specification  version  1.2  or  later. +The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between +two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. +It  shall  provide  following  roles: +Initiator  (INT) +Acceptor  (ACP) +Following  are  the  feature  requirements  for  this  profile: +Connection +Transfer  Control +Signalling  Control +Security  Control +Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not +yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. +5.1.1.1.15  Bluetooth  Diagnostics +**5.1.2  Error  Management** +The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes +Page  92  of  159 +![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized +restart.  In  addition, +in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery +to  issue  in  a  short  amount  of  time. +**5.1.2.1  Use  Cases** +5.1.2.1.1  System  Surveillance  and  Recovery +While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an +immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating +the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to +try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating +middle  ware,  reboot  the  whole  system  to  try  and  recover. +There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that +adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The +AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. +The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even +if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be +done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error +Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the +degree  should  be  adjusted  by  its  behavior  status. +5.1.2.1.2  Collecting  Information +For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt +recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the +cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. +With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On +the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come +Page  93  of  159 +![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, +the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. +**5.1.2.2  Requirements** +Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its +status  automatically  and  recover +The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each +process. +The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. +When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold +value,  action  is  changeable  by  AGL  user. +Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification +to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are +output  communication  or  disk  I/O. +Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification +by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an +error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication +error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. +Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it +should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination +of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so +those  two  should  be  able  to  set  separately. +Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold +value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be +changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. +Should  be  able  to  vanish  process  forcibly  including  subsidiary  process +Page  94  of  159 +![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Make  the  software  that  works  by  system  have  the  concept  of  level  importance. +Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be +adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. +The  process  that  detecting  an  external  communication  error  within  the  Error  Management +module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. +The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as +more  than  one  process. +The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple +applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where +multiple  applications  can  be  moved  by  the  same  process. +Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing +process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as +process  crash,  exit,  etc.. +An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends +suddenly  the  other  will  not  become  abnormal  state. +The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other +process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards +external  side. +When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart +additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered +beforehand. +The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file +system  without  destroying  them. +Page  95  of  159 +![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for +analyzing. +When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a +message  that  can  specify  the  cause. +Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +in  a  short  period  of  time  have  been  equipped  and  able  to  select. +In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or +system  down  does  not  occur  (self-destruction  on  log  output  process). +Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. +Should  be  able  to  select  the  level  of  log  output. +Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. +Should  be  able  to  obtain  the  information  linked  to  the  system  resources. +Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. +Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +in  a  short  period  of  time  have  been  equipped  and  able  to  select. +As  the  smallest  amount  of  information,  the  following  information  should  be  left. +· Register  information +· Process  logical  memory  map +· +Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence +· Time  of  occurrence +· +Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing +file‑name  of  the  thread  etc.) +Page  96  of  159 +![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· The  signal  that  occurred +Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. +· +Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted +for  an  output. +· +Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent +dropping  the  information  needed. +· +Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] +· +Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed +maximum  size. +· +NOTE  information  of  ELF  header  and  program  header  will  not  change. +Selectable  memory  mappings  are  the  following. +· anonymous  private  mappings +· anonymous  shared  mappings +· file-backed  private  mappings +· file-backed  shared  mappings +· private  huge  page +· shared  huge  page +Setting  parameters  of  the  output  context  are  the  following. +· +Memory  mapping  category  which  is  for  an  output  object  can  be  set. +· The  order  of  outputting  memory  mapping  can  be  set. +Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in +increments  of  process. +Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be +able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. +Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. +Page  97  of  159 +![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. +**5.1.3  Graphics** +Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. +**5.1.4  Location  Services** +Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead +reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary +output  of  the  GPS  receiver. +**5.1.4.1  Position** +**5.1.4.2  Time  of  Day** +With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car +device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of +its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in +future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. +**Monotonic  and  Absolute  Time  Support** +As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. +Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s +moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and +Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. +On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time +that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, +some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports +Monotonic  Time. +**Kernel  Time  Precision** +Page  98  of  159 +![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those +communicating  system  includes  the  device  that  needs  ms  order  procedure. +In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on +the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest +value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. +**5.1.4.3  Requirements** +Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. +Adjust  the  system  time  after  the  time  is  determinate. +GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using +the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. +GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not +imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make +Source  plugin  can  not  be  GPL  or  LGPL. +When  waiting,  can  use  both  absolute  time  and  monotonic  time +Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +monotonic  time. +Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +monotonic  time. +System  time  must  be  able  to  use  consecutively  at  least  until  2099. +Absolute  time  has  to  support  leap  year  and  leap  seconds. +1  jiffies  have  to  be  smaller  than  1ms. +Page  99  of  159 +![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. +From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. +A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. +**5.1.5  Health  Monitoring** +Platform  monitoring  services  such  as  watchdog  or  active  monitoring +**5.1.6  IPC** +Standard  platform  interprocess  and  interprocessor  communication  mechanism. +**5.1.7  Lifecycle  Management** +Startup,  shutdown,  state  change,  etc. +**5.1.8  Network  Services** +Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer +including  Wifi,  Bluetooth,  or  ethernet. +**5.1.9  Persistent  Storage** +Power  safe  persistent  storage +**5.1.10  Power  Management** +Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs +in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. +*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* +Page  100  of  159 +![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +modern  ECUs +In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, +in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal +balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important +for  overall  durability  characteristic. +Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming +more  welcomed  over  traditional  cold  boot  approaches. +Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has +become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only +consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) +**5.1.10.1  Requirements** +AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend +states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” +/“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. +AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state +transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state +transitions  if  no  requests  provided  from  applications. +Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of +this  specification  (it  is  also  platform-dependent). +AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of +cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting +core  in  one  of  its  low  power  states) +AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular +cores  from  SMP  group. +Page  101  of  159 +![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points +(table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, +some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget +insignificant) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling +Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. +Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they +may  have  negative  impact  on  overall  system  performance/predictability +AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is +platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states +Only  application-defined  policies  shall  be  allowed  for  CPU  Idle +AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices +AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling +**5.1.11  Resource  Management** +Resource  and  device  management. +Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource +request  by  the  Resource  Manager. +**5.1.12  Telephony  Services** +**5.1.12.1  Requirements** +Page  102  of  159 +![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.12.1.1  Telephony  variants +Purpose:  To  define  the  variants  of  Telephony +Requirement: +There  will  be  2  variants  of  phone  system. +Variant  1:  Front  User  only  Telephony. +Variant  2:  Rear  and  Front  Telephony. +All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature +can  be  disabled  via  car  configuration. +**5.1.13  Wi-Fi** +This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information +management  between  a  wireless  LAN  device  and  infotainment  system. +Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. +**5.1.13.1  Use  Cases** +5.1.13.1.1  Construct  WiFi  Network +In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. +a\. STA +In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via +an  Access  Point. +It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. +b\. AP +In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices +with  an  external  network. +Page  103  of  159 +![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. +c\. P2P +In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- +Fi  Direct. +5.1.13.1.2  Miracast +In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) +They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, +by  using  UIBC  (User  Interface  Back  Channel).-(b) +**Figure  8-29  :  Overview  of  Miracast** +a\. Shared  Displayed  Content +Page  104  of  159 +![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Use  case  examples  of  shared  displayed  content  are: +· +A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device +(e.g.  Mobile)  on  In-Vehicle  Infotainment  system. +· +A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment +system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). +b\. Remote  Operation +Use  case  examples  of  remote  operation  are: +· +A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device +(e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. +· +A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle +Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). +· +While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation +functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. +Mobile). +5.1.13.1.3  DLNA +In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. +**5.1.13.2  Requirements** +5.1.13.2.1  Security +The  WiFi  module  shall  support  security  standard  WEP. +It  shall  support  40  bit  WEP  encryption  method. +It  shall  support  104  bit  WEP  encryption  method. +It  shall  support  security  standard  WPA  Personal. +Page  105  of  159 +![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA2  Personal. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA  Enterprise. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA2  Enterprise. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +5.1.13.2.2  Simple  Configuration +It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. +It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. +It  shall  support  Configuration  Method  for  Display. +Page  106  of  159 +![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  support  Configuration  Method  for  Keypad. +It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. +It  shall  support  Configuration  Method  for  PushButton. +It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. +5.1.13.2.3  QoS +It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. +It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. +5.1.13.2.4  STA +The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). +5.1.13.2.5  AP +The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). +5.1.13.2.6  WiFi  Direct +It  shall  comply  with  Wi-Fi  Direct  standard. +It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. +Page  107  of  159 + + -------------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **(Reference)** + > + > **Support  in  Wi-** + > + > **Fi  Direct** + ----------- ---------------------------------------------------- -------------------------- ------------------------ + > 1 > P2P  Provision > ‑ > Mandatory + > + > Discovery + + > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory + + > 3 > ‑ > Find  Phase > Mandatory + + > 4 > P2P  GO  Negotiation > ‑ > Mandatory + + > 5 > P2P  Service  Discovery > ‑ > Option + + > 6 > P2P  Invitation > Temporary  P2P  Group > Option + + > 7 > ‑ > Persistent  P2P  Group > Option + + > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option + + > 9 > Intra-BSS  Distribution > ‑ > Option + + > 10 > Concurrent  Operation > ‑ > Option + + > 11 > P2P  Service  Discovery > UPnP > Option + + > 12 > ‑ > Bonjour > Option + + > 13 > ‑ > Wi-Fi  Display > Option + + > 14 > ‑ > WS-Discovery > Option + + > 15 > ‑ > Vendor  specific > Option + -------------------------------------------------------------------------------------------------------------------- + +![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.13.2.7  Miracast +Page  108  of  159 + + -------------------------------------------------------------------------------------------------------------- + > ‑**No.** > **Feature** > ‑ > **(Refere** + > + > **nce)** + > + > **Suppor** + > + > **t        in** + > + > **Miracas** + > + > **t** + ------------ ----------------------------------------------------- ----------------------- ------------------- + > 1 > WFD  Device  type > WFD  Source > Mandat + > + > ory + + > 2 > ‑ > Primary  Sink > Mandat + > + > ory + + > 3 > ‑ > Dual-role  possible > Option + + > 4 > WFD  Service > ‑ > Option + > + > Discovery + + > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat + > + > ory + + > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option + + > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option + > + > Group + + > 8 > ‑ > via  TDLS > Option + + > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat + > + > ory + + > 10 > WFD  Session  Establishment  (RTSP) > Mandat + > + > ory + -------------------------------------------------------------------------------------------------------------- + +![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  comply  with  Miracast  standard. +It  shall  support  the  Miracast  functions  identified  in  Table  30. +Page  109  of  159 + + --------------------------------------------------------------------------------- + > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat + > + > ory + ------ --------------------------------------------------- ----------- ---------- + > 12 > WFD  Standby  (RTP/RTSP) > Option + + > 13 > Video  CODEC  formats > Option + + > 14 > Audio  CODEC  formats > Option + + > 15 > UIBC > Generic + + > 16 > HIDC + --------------------------------------------------------------------------------- + +![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.13.2.8  WiFi  Hotspot +It  shall  comply  with  Wi-Fi  Hotspot  standard. +In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot +service. +In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. +5.1.13.2.9  DLNA  via  WiFi +The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. +**5.1.14  Window  System** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +and  a  routing  of  user  interactions. +Page  110  of  159 +![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.2  Automotive  Services +Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but +contains  services  specialized  for  automotive  applications. +**5.2.1  Audio  Services** +BTBF,  equilization,  mult-zone  audio  control,  etc. +**5.2.2  Camera  Services** +Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. +**5.2.3  Configuration  Services** +Service  for  storing  configuration  parameters. +**5.2.4  Diagnostic  Services** +Diagnostic  services. +(This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) +**5.2.5  Multimedia  Services** +CD,  DVD,  Blu-Ray,  MP3,  etc. +(Factor  out  metadata  into  separate  component.) +**5.2.5.1  Media  Player** +In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just +Page  111  of  159 +![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video +devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, +there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- +seat  passengers  as  well  as  driver  all  having  independent  requirements. +The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: +· +Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the +ones  encountered  in  mobile  and  desktop  world. +· +Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) +and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or +establishes  a  network  connection.) +· +Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of +audio  /  video  processing  chains. +Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data +processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in +comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from +navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from +Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so +on. +It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore +processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing +offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with +particular  implementation  freedom  left  for  a  silicon  vendor. +The  following  requirements  formalize  these  considerations. +**5.2.5.2  Requirements** +5.2.5.2.1  Media  Containers +AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This +includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It +shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable +input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated +from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall +be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. +Page  112  of  159 +![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, +for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream +identification  data  from  media  container. +AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: +· HTTP +· RTPS +· Digital  Radio  (DAB) +· DigitalTV  (DVB-T)  etc. +It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with +system  requirements. +AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload +computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such +extension,  if  available,  shall  be  transparent  to  the  applications. +Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. +AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the +source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without +intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this +process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of +particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from +multiple  choices. +AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall +support  the  following  functionality: +· +Selection  of  data  source  and  destination  (files,  devices,  network  resources) +· Pausing/resuming  of  multimedia  streams +· Rewinding  in  forward  and  reverse  directions  (for  playback) +· Audio  volume  control  on  per-stream  basis +· Retrieval  of  current  stream  position  (timestamp) +Page  113  of  159 +![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +Notifications  on  error  conditions  preventing  multimedia  stream  processing +AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved +into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to +specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to +specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw +audio/video  streams  to  multiple  renderers  as  well. +AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and +synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: +· +Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. +· Per-stream  volume  and  audio  effects  control. +· +Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). +· +Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). +· Mixing  and  broadcasting  of  the  audio  streams. +AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to +specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or +removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, +emergency  system  alarm  output  and  so  on. +AGL  shall  provide  support  for  major  multimedia  containers,  such  as: +· MPEG2-TS/PS  (ISO/IEC  13818-1) +· MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) +It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with +system  requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: +· OGG  (RFC  3533) +· 3GPP  (ISO/IEC  14496-12) +· etc +Page  114  of  159 +![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.2.5.2.2  Media  Audio  Codecs +AGL  shall  provide  support  for  major  audio  codecs,  such  as: +· +MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) +· AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) +It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system +requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: +· VORBIS  (http://xiph.org/vorbis/) +· Windows  Media  Audio +· etc. +5.2.5.2.3  Media  Video  Codecs +AGL  shall  provide  support  for  major  video  codecs,  such  as: +· MPEG-2  (ISO/IEC  13818-2) +· MPEG-4  Part  2  (ISO/IEC  14496-2) +· H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) +It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system +requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: +· Theora  (www.theora.org) +· Windows  Media  Video +· etc +5.2.5.2.4  Image  File  Formats +Page  115  of  159 +![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true +colour. +Compression  formats +· RLE  8  bits/pixel +· RLE  4  bits/pixel +· Bit  field  or  Huffman  1D  compression +· JPEG  or  RLE-24 +· PNG +The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including +Exchangeable  Image  File  Format  (EXIF)  format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, +including  transparency +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced +version  89a  and  also  animation  in  GIFF  images. +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +format. +**5.2.6  Navigation  Services** +Navigation  engine +Page  116  of  159 +![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.7  PIM** +Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. +**5.2.8  Smartphone  Link** +This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which +realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation +is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and +AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use +smartphone  content  (map,  music,  browser...)  by  IVI. +Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. +**Figure:  8-30** +Page  117  of  159 +![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  defines  following  requirements  of  Smartphone  link. +1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. +2.  The  sound  of  smartphone  shall  be  linked  to  IVI. +3.  The  sound  shall  be  synchronized  with  the  screen. +4.  IVI  should  operate  smartphone. +5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. +6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should +inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. +This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone +link. +**5.2.8.1  Miracast** +This  section  describes  requirements  regarding  Smartphone  link  (Miracast). +Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- +Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing +between  source  device  and  sink  device. +Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. +**Figure:  8-31** +Page  118  of  159 + + ---------------------------------------------------------------------------------------------- + > **No** > **Requires** > **Description** + ------------ ----------------------------- --------------------------------------------------- + > SPL.1.1 > WFD  Topology > Define  role  of  Miracast + + > SPL.1.2 > Connection  Topology > Define  connection  condition  between + > + > a  smartphone  and  an  IVI + + > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi + > > + > 1 > Direct). + + > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency + > + > 2 + + > SPL.1.3 > Video  Format > Define  Video  format + + > SPL.1.4 > Audio  Format > Define  Audio  format + + > SPL.1.5 > Session  Control > Define  Miracast  session  state + + > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required + > + > for  implementing  Miracast + + > SPL.1.7 > Resource  Management > Define  resource  management + ---------------------------------------------------------------------------------------------- + +![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. +**References** +\[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 +\[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 +\[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision +2.2 +\[4\]  DCP  (Digital  Content  Protection)   +AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. +Page  119  of  159 +![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +SPL.1.8 Fail-safe  Control Define  Fail-safe  control +**Table  8-14:  Smartphone  Link  (Miracast)  Requirements** +**Figure:  8-32  State  Change  Diagram** +The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. +Page  120  of  159 + + ------------------------------------------------------------------------------------------------------- + > **No.** > **State** > **Description** + ----------- ------------------------- ----------------------------------------------------------------- + > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. + + > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and + > + > waiting  for  Wi-Fi  P2P  connection  from  source + > + > device. + + > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source + > + > device. + + > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. + + > 5 > Play > Streaming  the  audio  and  video  content  from  source + > + > device  to  sink  device. + + > 6 > Pause > Paused  the  streaming  of  audio  and  video  content + > + > from  source  divide  to  sink  device. + ------------------------------------------------------------------------------------------------------- + +![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.8.2  Smart  Device  Link** +“Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. +Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach +makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s +distraction  and  voice  recognition. +That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote +procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework +and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. +SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile +phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported +applications  can  be  launched. +Page  121  of  159 +![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  8-33  :  SDL  overview** +**5.2.8.3  Requirements** +5.2.8.3.1  Miracast +System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. +· +Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which +from  Source  Device‑Smartphone‑. +· Supporting  WFD  Source  is  an  option. +· +Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) +source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). +· +Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take +measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over +5Km/H) +· Support  Wi-Fi  P2P  connection. +· +Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in +Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. +· Wi-Fi  TDLS  connection  is  an  option. +· +AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select +Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) +· +AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive +Page  122  of  159 +![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for +confirmation) +· +Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. +· +Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P +connection  established. +· +Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. +· +Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) +function  if  support  5GHz  band. +· Follow  reference  \[1\]  for  Video  Codec. +· Support  follow  format  for  Video  Resolution  and  Frame  rate. +o 640\*480‑VGA‑‑Progressive  60  fps +o 1280\*720‑HD‑Progressive  30  fps +Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. +· Support  follow  format  for  Audio. +o LPCM  48ksps  16bit  2ch +o AAC  48ksps  16bit  2ch +Regarding  Audio  Format,  other  formats  are  an  option. +When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up +notification) +Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support +content  protection  function. +· +AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not +define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for +Page  123  of  159 +![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +vendor’s  own  reason. +· Support  both  encryption  cases  if  support  HDCP  function. +o Case1  Videos  data  encryption +o Case2  Both  video  and  audio  encryption +Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to +DCP.(reference  \[4\]) +· +Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, +then  Miracast  release  screen  and  audio  resources  for  the  event. +· +It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast +session.) +· +Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events +happen. +o Failed  to  Wi-Fi  connection +o Failed  to  establish  Miracast  session +o Wi-Fi  link  loss  on  Miracast +o Break  Miracast  connection  from  smartphone +5.2.8.3.2  Smart  Device  Link +System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. +System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. +System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel +device  of  IVI  device. +System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice +Page  124  of  159 +![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +recognition  of  IVI  system. +System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity +method  must  be  supported  Bluetooth  and/or  Wi-Fi. +System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity +method  must  be  supported  Bluetooth  and/or  Wi-Fi. +**5.2.9  Speech  Services** +The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. +AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands +AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech +**5.2.10  Tuner  Services** +The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into +the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, +TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present +in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. +**5.2.10.1  Receivers** +The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including +AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any +number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from +the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current +content. +The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into +the  same  API  regardless  of  the  receiver  type. +Page  125  of  159 +![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow +its  clients  to  address  each  receiver  in  the  system  independently. +5.2.10.1.1  HD  Radio +HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An +HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to +provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the +receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The +HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the +iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional +design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by +iBiquity  Digital. +The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the +requirements  in  this  section. +1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. +2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. +3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. +Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is +applicable  to. +AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status +to  the  system. +AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the +tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning +successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio +output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No +Reception"  is  available  in  that  specific  channel. +AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +Page  126  of  159 +![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Frequency +· Mono/Stereo +FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +· Frequency +· PI  Code  (RDS  only) +· PTY  (RDS  only) +· Radio  Text  (RDS  only) +· PS  Name  (RDS  only) +· Category  (RDS  only) +· Mono/Stereo +HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +· Frequency +· PTY +· No  of  HD  channels  available +· Radio  Text +· Channel  Name +· Category +· Bit  rate +· Station  Logo +· Artist  Experience +The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. +The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal +strength. +AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. +Page  127  of  159 +![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be +possible  to  adjust  by  software. +· Range:  15  –  40  dBµV +· Step:  1  dBµV +· Default:  20  dBµV +· +Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity +level.  TBD,  Supplier  to  suggest  solution. +AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be +possible  to  adjust  by  software. +· Range:  20  –  40  dBµV +· Step:  1  dBµV +· Default:  34  dBµV +· +It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. +different  for  night  and  day). +The  system  shall  be  able  to  switch  between  AM  and  FM  bands. +HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the +SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance +with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +Information  Service  Transport". +HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the +SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance +with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +Information  Service  Transport". +HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. +Page  128  of  159 +![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. +· Song +· Artist +· Album +· Genre +· Comments +· Commercial +· Reference  Identifier +The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification +"HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" +FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the +system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, +Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency +range  from  87,5  MHz  to  108,0  MHz". +FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled +the  system  shall  indicate  this. +FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. +FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. +FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. +FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. +FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. +FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received +through  RDS. +Page  129  of  159 +![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. +FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. +FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. +FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. +FM/HD  system  shall  be  able  to  enable/disable  regionalisation. +FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. +FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) +reception. +FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. +FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. +FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. +HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. +HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. +AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. +AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. +*HD system shall extract the album name, artist name, track number from the audio stream a*nd +Page  130  of  159 +![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +present  to  the  system. +The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The +feature  will  be  able  to  store  at  least  50  tags. +*5.2.10.1.1.1  Configuration* +AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration +file. +AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. +AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local +configuration  file. +5.2.10.1.2  Database  Requirements +AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains +the  following  attributes: +· Frequency +· PTY  (FM  &  HD  only) +· Channel  name  (FM  &  HD  only) +· Channel  icon  (HD  Only) +· Category  (FM  &  HD  only) +AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following +conditions: +· New  channel  is  found +· Existing  channel  disappears +· +Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list +database. +Page  131  of  159 +![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present +to  the  system. +AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the +frequency,  and  present  to  the  system. +FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, +and  present  to  the  system. +AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following +information: +· Station  name  (FM  and  HD  only) +· Frequency +· Status  of  HD  (HD,  HD1,  HD2) +· HD  SIS  (HD  only) +AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: +· Favourite  station  changed +· Favourite  station  is  removed +· New  favourite  is  added +**5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** +Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from +applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and +LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of +VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main +functions. +· Vehicle  Data  Processing +· Communication  between  ECUs +· Vehicle  Data  Upload +Page  132  of  159 +![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Simulator +**Figure  7-27  :  Overview  of  Vehicle  Info  Control** +**5.2.11.1  Vehicle  Data  Processing** +Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, +personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application +and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. +· +Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature +· User  Information,  such  as  a  name,  taste,  etc.  of  a  driver +· The  operation  history  of  a  driver +Page  133  of  159 +![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle +conditions,  such  as  speed  and  day  and  night +Vehicles  data  processing  consists  of  the  following  functional  elements  further. +(1)  Abstraction  of  Vehicles  Data +In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind +of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving +speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for +application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles +data  of  the  same  implications  and  the  same  unit. +(2)  Maintenance  of  Vehicles  Data +Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past +value  (history). +(3)  Application  /  Middleware  Interface  (API) +The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. +Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and +the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data +restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance +(access  control). +(4)  Vehicles  Interface +It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN +and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the +exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. +However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more +Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In +addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. +**5.2.11.2  Communications  between  ECUs** +Page  134  of  159 +![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +which  each  ECU  can  access. +**5.2.11.3  Vehicle  Data  Upload** +When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +which  each  ECU  can  access. +**5.2.11.4  Simulator** +In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is +unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes +development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel +controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be +an  option. +**5.2.11.5  Requirements** +The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application +and/or  middleware  can  access  vehicle  information. +The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract +property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but +the  speed  of  a  car. +System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. +Page  135  of  159 +![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  support  typical  vehicle  property  as  “standard  property”. +As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. +System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. +A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard +property. +Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) +The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or +middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough +as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile +display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. +A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is +stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the +load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and +spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. +It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In +corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. +· +The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the +accumulated  newest  value  is  less  than  a  threshold  value. +· +Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the +newest  accumulation. +About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need +to  be  able  to  set  up  easily. +In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. +System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property +access. +System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or +middleware. +Page  136  of  159 +![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Below  attributes  must  include  in  this  interface +· Zone(optional) +· Property  name +· Value +· +Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application +and/or  middleware. +Below  attributes  must  include  in  this  interface. +· Zone(optional) +· Property  name +· Value +System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from +application  and/or  middleware. +When  status  changed,  system  must  invoke  callback  function  with  below  attributes. +· Zone(optional) +· Property  name +· Value +· Timestamp +· Sequence  number +Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +Sequence  number  is  useful  to  check  event  order. +The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of +change  of  vehicle  information. +In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an +acceptable  value  even  if  vehicle  information  changes. +For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the +application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of +change. +Page  137  of  159 +![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. +· +The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the +value  from  the  last  notice  of  change  is  less  than  specification. +· +Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a +definite  period  of  time,  it  does  not  notify. +Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the +time  of  change. +What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified +notice  interval  is  made  possible. +The  data  stored  is  acquired  collectively. +Below  attributes  must  include  in  this  interface. +· Zone(optional) +· Property  name +· Values +· Timestamps +It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 +seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. +There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual +in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed +simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the +newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to +recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information +relevant  to  mutual  and  to  access  it. +Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle +information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, +and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all +those  vehicle  information  at  the  time  of  reference. +The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. +Or  the  thing  which  can  be  changed  from  a  program  during  operation. +Page  138  of  159 +![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property +"velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be +accessed  from  all  applications. +System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same +property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only +application  C  can  set  this  property. +Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control +policy  may  be  different  per  car  type,  grade  and  destination. +System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU +and  across  two  or  more  ECU’s. +If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, +middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, +the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware +which  exist  in  a  different  ECU. +VIC  can  be  requested  to  set  the  value  specified  as  Property. +It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. +The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand +from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. +Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application +responds. +It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed +easily. +The  data  exchange  between  ECUs  should  be  permitted  by  VIC. +All  data  transmission  and  reception  from  other  Software  Component  are  refusing. +Page  139  of  159 +![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. +The  vehicle  information  to  upload  is  being  able  to  choose. +A  selection  condition  is  that  the  following  specification  is  possible  at  least. +· Date-and-time  range +· Object  vehicles  data +· The  change  threshold  value  of  vehicles  data +Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be +able  to  change  dynamically  from  an  external. +The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as +substitution  of  actual  vehicles  in  development  environment  is  prepared. +Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing +activities  through  a  vehicles  interface  function  at  least. +· Speed +· Shift  position +· The  direction  of  vehicles +· Latitude  and  longitude  of  a  current  position +· Turn  signal +The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, +it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. +VIC  should  fill  the  following  performance  specifications  and  performance. +It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +information  machines  and  equipment  in  2016. +Page  140  of  159 +![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Maximum  number  of  properties  :  4,096 +· Maximum  number  of  property  sets:  1,024 +· Greatest  data  storage  time :  12  hours +It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +information  machines  and  equipment  in  2016. +· Get/Set  method(one  property)  -  0.2ms +· Get/Set  method(property  set  include  30  properties)  -1.3ms +· Subscribe  callback  -  2.5ms  (after  change  of  a  value) +· +GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms +· +GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms +VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility +about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and +attribute  of  vehicles  data. +Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by +various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add +and  change  Vehicle  Interface  without  reconstruction  of  VIC. +Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is +necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. +However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness +vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more +concreteness  vehicles  data  into  one  abstract  vehicles  data. +Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be +mounted  in  the  VIC  itself. +In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be +added  without  reconstruction  of  VIC  is  prepared  for  VIC. +**5.2.12  Telematics  Services** +V2V,  V2I,  RVI,  Traffic  information,  etc. +Page  141  of  159 +![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.13  Window  System** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +and  a  routing  of  user  interactions. +AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple +processes  to  be  rendered  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to +achieve  flicker  less  rendering. +AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- +screen  buffers. +AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying +objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. +AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos +group  available  to  clients  for  their  rendering. +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by +configuration. +AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the +*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a +Page  142  of  159 +![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The +window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES +2.0  API  are  responsible  for  a  hardware  abstraction. +AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. +AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple +displays. +AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, +where  available. +AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware +acceleration  capabilities. +AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs +from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a +vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the +vehicle  reaches  to  the  certain  speed. +AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, +a  touch  panel,  a  control  knob  etc. +AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input +from  available  physical  input  devices. +**6   Security   Services** +Security  framework +6.1  Access  Control +Access  Control  describes  requirements  for  AGL  Access  Control. +Page  143  of  159 +![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. +**6.1.1  Requirements** +AGL  system  must  support  a  system-wide  access  control  mechanism. +**7   Operating   System   Layer** +7.1  Kernel +**7.1.1  Linux  Kernel** +Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new +release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years +for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and +kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the +rest  of  the  open  source  community  provides, +**7.1.1.1  Requirements** +AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. +At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive +industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully +aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by +Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to +accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to +regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with +the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. +AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on +particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. +Page  144  of  159 +![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +7.2  Boot  Loader +7.3  Hypervisor +TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level +virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI +systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android +and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on +top  type1  hypervisor. +**7.3.1  Requirements** +AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that +have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The +processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. +AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following +functionality  shall  be  supported  by  AGL  Linux  “guest”: +· IPC  (with  hypervisor  and  other  “guests”) +· +“paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless +virtualization  abstraction  is  supported  by  hardware) +7.4  Operating  System +**7.4.1  File  Systems** +File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability +as  their  main  characteristics. +· +*Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, +tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process +environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management +techniques. +Page  145  of  159 + + ------------------------------------------------------------------------------- + > **FS  Requirements** > **R-FS  References** + ------------------------------------------------------ ------------------------ + > 6.  File  Systems  (P1) > 2.  btrfs + > > + > 6.1.  Robust  File  System  for  managed  internal > 2.1. + > > + > storage  (P1) > btr + > > + > 6.1.1.  Power  failure  tolerance  (P1) > fsc + > > + > 6.1.2.  Quick  recovery  after  power  loss > k + > > + > (P1) > 3.  ext2 + > > + > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. + > > + > 6.1.4.  On-demand  integrity  checker  (P1) > e2 + > > + > 6.1.5.  Read-only  mode  (P1) > def + > > + > 6.1.6.  Non-blocking  unmounting  (P1) > rag + > > + > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 + > > + > performance  if  it  may  degrade  under > 5.  ext4 + > > + > certain  conditions.  (P2) > 5.1. + > > + > 6.1.8.  File  space  pre-allocation  (P2) > e4 + > > + > 6.1.9.  Meta-data  error  detection  (P2) > def + > > + > 6.1.10.  File  data  error  detection  (P2) > rag + > > + > 6.1.11.  Online  integrity  checking  (P2) > 5.2. + > > + > 6.1.12.  Write  timeout  control  (P2) > e2f + > > + > 6.1.13.  Compression  support  (P2) > sck + > > + > 6.1.14.  Quota  support  (P2) > 6.  vfat + > > + > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS + > > + > 6.1.16.  File  system  event  notifications > 8.  Generic + > + > tools  and + > + > APIs + > + > 8.1. + > + > fan + ------------------------------------------------------------------------------- + +![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +*Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing +designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. +· +*Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual +packages,  and  availability  of  file  system  checking  and  optimization  tools. +![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 +(P2) +6.1.17.  Logical  block  size  control  (P2) +6.1.18.  Snapshots  (P2) +6.2.  File  System  for  non-managed  internal +storage  (P1) + +May  28,  2015 + +otif + +y + +8.2. + +fst + +rim + +6.2.1.  All  P1  requirements  from +FS.1.1.x  list  (P1) +6.2.2.  Wear  leveling  (P1) +6.2.3.  Error  detection/correction  (P1) +6.2.4.  Tolerance  to  flipping  bits  (P1) +6.2.5.  Read/write  disturb  awareness +(P1) +6.2.6.  Bad  block  management  (P1) +6.2.7.  As  many  P2  requirements  from +FS.1.1.x  list  as  possible  (P2) +6.2.8.  Wear  leveling  statistics  (P2) +6.3.  File  Systems  for  removable  storage  (P1) +6.3.1.  Restricted  functionality  from +security  point  of  view  (P1) +6.3.2.  Automount/autounmount  (P1) +6.3.3.  Automatic  synchronous  flushing +of  modified  data  to  physical  media  (P2) +**7.4.1.1  Requirements** +AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +memory),  removable  managed  (USB  stick,  SD  card). +AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, +Page  147  of  159 +![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, +AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. +A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, +and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. +A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power +interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should +not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. +Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- +write)  operation. +A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple +threads  and/or  processes  simultaneously. +A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. +A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical +storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” +command. +AGL  must  support  “lazy”  (delayed)  unmounting. +AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged +file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. +Another  example  is  periodic  fstrim  execution  on  SSD  storage. +A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This +may  be  used  to  minimize  fragmentation  of  frequently  written  files. +A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. +Page  148  of  159 +![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored +data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. +A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. +A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical +media. +A  file  system  should  support  automatic  data  compression. +It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. +AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. +AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. +Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O +performance,  and  decrease  file  fragmentation  impact. +A  file  system  should  allow  creation  of  snapshots. +A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of +erase/program  cycles  is  evenly  distributed  across  all  device  blocks. +A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. +A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also +actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power +interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the +time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. +A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb +Page  149  of  159 +![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known +techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a +fresh  block  after  detected  error  correction. +A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system +users. +Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. +A  file  system  must  support  noexec,  and  nodev  mount  options. +A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and +automatically  unmount  it  when  unplugged. +A  file  system  must  support  sync  mount  option. +AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +memory),  removable  managed  (USB  stick,  SD  card). +**7.4.2  Resource  Control** +In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be +higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource +allocation  for  each  process  and/or  process  group. +(cgroups) +**7.4.2.1  Use  Case  and  Role** +If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current +position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. +On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned +Page  150  of  159 + + ------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- -------------- ---------------------------------------------------------------- + > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority + > + > process  and/or  process  group  should  be  assigned + > + > more  resource. + + > 2 > Time  slot > To  share  resource  per  time  slot. + + > 3 > Release > Forced  release  of  partially  or  whole  allocated + > + > resource. + + > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate + > + > resource  per  defined  process  group. + ------------------------------------------------------------------------------------------- + +![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  higher  priority  than  others. +Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at +the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. +Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. +AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network +bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. +**Table  9-34  :  Functions  of  System  Resource  Management** +**7.4.2.2  Requirements** +7.4.2.2.1  Priority +System  provides  a  mechanism  to  set  resource  priority  per  each  process. +Page  151  of  159 +![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. +This  interface  must  be  called  from  other  process. +CPU  resource  must  support  “priority”  based  resource  management. +Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the +status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. +Resource  Manager  should  log  the  status  of  resources  using  by  system. +Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of +kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high +priority  tasks. +7.4.2.2.2  Time  Slot +When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a +mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each +processes. +System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. +System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage +bandwidth  and  network  bandwidth. +Scheduler  should  detect  the  status  of  resources  for  each  thread. +Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. +Scheduler  should  guarantee  that  threads  can  run  periodically. +Scheduler  should  control  the  dispatches  that  occur  extremely. +Page  152  of  159 +![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +7.4.2.2.3  Release +System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by +specific  process. +System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. +7.4.2.2.4  Grouping +System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource +management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same +attributes  to  grouped  processes  altogether. +System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. +System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and +network  bandwidth. +**7.4.3  Startup/Shutdown  Control** +Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a +user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending +on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which +boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and +“dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. +**7.4.3.1  Use  Cases** +(1)  Static  Modification  of  Boot/Shutdown  Order +a. +Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration +To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown +for  all  programs  running  on  the  target  device. +Page  153  of  159 +![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b. +Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development +In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed +program  in  target  programs. +c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update +Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. +(2)  Dynamic  Modification  of  Boot/Shutdown  Order +a. +Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using +It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to +be  operated  by  priority  when  ACC  turns  ON. +b\. Prioritized  Boot  of  Update  Functionalities +Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned +ON. +**7.4.3.2  Requirements** +Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. +Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that +has  been  configured. +Boot/Shutdown  Control  shall  start  independent  components  in  parallel. +Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. +Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that +has  been  configured. +Page  154  of  159 +![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. +**7.4.4  Database** +Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee +database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system +database  engine  is  rich  set  of  bindings  to  various  programming  languages. +Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References +hierarchy. +1.  Power  failure  tolerance  (P1) +2.  Quick  recovery  after  power  loss  (P1) +3.  Multi-threaded  I/O  (P1) +4.  API  bindings  for  C  programming  language +5.  On-demand  integrity  checker  (P2) +DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write +DB  transactions. +DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. +Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power +failure  on  idle  system. +DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or +processes  simultaneously. +DB  engine  API  must  be  available  for  C-based  applications. +DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. +DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power +interruption  during  adding  some  data. +Page  155  of  159 +![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, +such  as  vehicle  information  database  and  databases  at  data  center. +And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. +Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption +during  merging. +**7.4.5  System  Update** +Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are +numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, +bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to +power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. +System  Update  module  should  have  a  Robust  version  up  function. +System  Update  moduleshould  have  a  system  difference  version  up  function. +There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +apt  of  Linux  distribution). +There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +apt  of  Linux  distribution). +Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. +If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should +be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. +If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during +update)  should  be  detected  and  the  system  should  restart. +Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. +Page  156  of  159 +![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Memory  usage  for  difference  update  should  be  maximum  1Mbyte. +Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. +System  Update  moduleshould  have  full  version  up  function  for  whole  system. +Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow +mass  update. +There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. +If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +7.5  Device  Drivers +Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. +**7.5.1  Peripherals** +Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. +The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and +data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For +optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less +than  50  s/byte  average. +The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles +and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or +EEPROM  is  not  allowed. +Page  157  of  159 +![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be +fast.  (target  <1ms/byte) +N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. +**7.5.2  Graphics  Drivers** +Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. +This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. +**7.5.3  Video  Drivers** +Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video +codecs  will  nearly  always  be  hardware  based. +**7.5.3.1  Requirements** +The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video +functionality. +**7.5.4  Audio  Codecs** +**7.5.4.1  Requirements** +Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are +implemented  in  hardware. +Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs +that  are  required  for  AGL-based  products  and  not  supported  in  hardware. +**7.5.5  Automotive  Devices** +Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or +*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* +Page  158  of  159 +![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for +navigation  or  an  air  bag  sensor  for  a  telematics  system. +**8   Notices** +Linux  is  a  registered  trademark  of  Linus  Torvalds. +The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. +Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. +Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. +MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. +AirPlay  is  a  trademark  of  Apple,  Inc. +Page  159  of  159 +--- + +title : App/HMI   Layer +author: imported from Doors-ng by Fulup(iot.bzh) +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + + + +** 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 + +## 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. + +## 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. + +## 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. + +## 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 + +##  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 + + +## 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 +##  Requirements + +### 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. + +###  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. + +###  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 +### 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. + +##   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 + +### Application  Manager +Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application +lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. + +###  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. + +###  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 +####  Use Case +Please  refer  “screen  resource  control”  of  Policy  Manger  section. + +####  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 +#### Requirements +4.1.2.3.1  Window  Drawing +System  must  provide  a  mechanism  to  manage  surfaces,  such  as  create,  delete,  make  visible  and +make  invisible. +System  must  provide  a  mechanism  to  create  and  delete  surface. +When  surface  is  created  or  deleted,  system  must  notify  status  change  to  GUI  resource. +This  notification  mechanism  makes  possible  to  assign  surface  to  proper  area  by  GUI  resource. +System  must  provide  a  mechanism  to  change  visibility  per  each  surface. +And,  provide  an  interface  to  change  visibility. +All  the  surfaces  must  be  set  to  invisible  for  initial  state. +Surface  will  be  visible  only  if  GUI  resource  issues  to  change  visibility. +System  must  provide  a  mechanism  to  move  surface’s  area.  If  area  size  was  different  between +previous  area  and  new  one,  then  system  must  support  to  fit  into  new  area  by  VIC.4.1.4. +*System must provide a mechanism to fit surface into area. Because, size of area may differe*nt +Page  23  of  159 +![](media/picture117.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +from  size  of  surface. +If  resize  was  happened,  system  must  notify  to  surface’s  owner  application. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  squeeze. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  using  combination  of  scaling  and  trimming  function. +That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +ratio.  This  makes  it  possible  to  fit  by  “pan  &  scan”. +If  size  of  surface  and  size  of  area  was  different,  system  must  provide  a  mechanism  to  fit  surface +into  area  by  using  combination  of  scaling  and  background  color. +That  means,  system  must  provide  a  mechanism  to  fit  surface  into  area  keeping  original  aspect +ratio.  System  also  provides  a  mechanism  to  fill  background  color  into  redundant  pixels.  This +mechanism  makes  it  possible  to  do  “letterbox”  method. +4.1.2.3.2  Overlay  of  Multiple  Windows +System  must  provide  a  mechanism  to  create  and  delete  a  layer. +Layer  must  have  a  concept  of  z-order.  That  means,  display  order  for  each  layer  is  decided  by +their  z-order  attribute. +Z-order  attribute  is  fixed  value.  So,  if  application  wants  to  change  display  order  of  surfaces, +then,  attached  layer  must  be  changed. +System  must  provide  a  mechanism  to  create  and  delete  “area”  to  display  surface. +Area  is  a  concept  which  defines  where  to  display  in  specific  layer. +System  must  provide  a  mechanism  to  attach  surface  to  any  layer. +Also,  system  must  be  able  to  change  attached  layer. +And,  provide  an  interface  to  attach  and  change. +Page  24  of  159 +![](media/picture118.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  assign  surface  to  any  area  in  a  layer. +And,  provide  an  interface  to  assign  surface  to  any  area. +System  must  provide  a  mechanism  to  change  visibility  per  each  layer. +That  means  all  the  surfaces  belonging  to  same  layer  will  be  changed  visible  or  invisible  at  the +same  time. +And,  provide  an  interface  to  change  visibility  per  layer. +Initial  state  must  be  set  to  invisible. +System  must  provide  a  mechanism  to  enable  superimposed  display  based  on  z-order  of  each +layer,  and  disposition  of  surfaces. +4.1.2.3.3  Visual  Affect +System  must  provide  a  mechanism  to  apply  animation  effect  when  visibility  change  was +happened. +Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +- Duration +Animation  type +System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +out. +Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +plug-in  architecture. +System  must  provide  a  mechanism  to  apply  animation  effect  when  move  surface  was  happened. +Per  each  animation,  system  must  provide  a  mechanism  to  apply  below  attributes. +· Duration +Animation  type +System  must  provide  typical  animation  effects,  such  as  slide-in,  slide-out,  zoom-in  and  zoom- +Page  25  of  159 +![](media/picture119.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +out. +Also,  system  must  provide  a  mechanism  to  add,  delete  and  change  animation  effect  easily  by +plug-in  architecture. +System  must  provide  a  mechanism  to  make  effect  to  surface. +And,  provide  an  interface  to  set  effect  type  from  application  and  other  software  components. +System  must  provide  a  mechanism  to  make  specific  surface  to  gray-out. +System  must  provide  a  mechanism  to  make  specific  surface  to  low  brightness +System  must  provide  a  mechanism  to  add,  delete  and  change  effect  for  surface  easily  by  plug-in +architecture. +4.1.2.3.4  Frame  Rate  Control +System  must  provide  a  mechanism  to  reduce  frame  rate  independent  from  refresh  interval  of +application. +System  also  provides  a  mechanism  to  set  frame  rate  as  0fps,  independent  from  refresh  interval +of  application. +This  function  is  useful  to  keep  whole  system  quality  even  if  high  load  status,  such  as  live +thumbnail  and  moving  surface. +4.1.2.3.5  Multiple  Hardware  Layer  Support +If  hardware  supports  two  or  more  hardware  layers,  system  must  provide  a  mechanism  to  use +hardware  layers  efficiently. +· +Never  use  software  overlay  when  superimposing  two  or  more  hardware  layers +Assign  hardware  layer  for  graphical  high  load  function,  such  as  video  playback +4.1.2.3.6  Reduced  Dependency  of  Hardware +Page  26  of  159 +![](media/picture120.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Window  Manager  must  be  able  to  retrieve  system  structure  regarding  displays  and  layers  of +each  display.  And  system  must  provide  a  mechanism  to  adapt  any  structure  without  re-build, +such  as  by  using  re-configuration. +4.1.2.3.7  Multi  Window +AGL  specifies  that  automotive  grade  Linux  shall  manage  multiple  windows  owned  by  multiple +processes  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display. +4.1.2.3.8  Compatibility +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  relies  on  a +standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The  window  manager  shall  not  rely  on  any +hardware  specific  API. +A  window  system  and  OpenGL/ES  2.0  API  are  responsible  for  a  hardware  abstraction. +**4.1.3  Policy  Manager** +**4.1.3.1  Overview** +4.1.3.1.1  Purpose +Policy  Manager  collects  information  and  makes  decisions  based  on  them.  To  do  that,  Policy +Manager  collects  lots  of  status,  such  as  user  operation  and  application  status,  then  issue  Vehicle +Info  Control  or  Resource  Control  to  provide  information.  Policy  Manager  controls  two  types  of +resource,  one  is  called  “GUI  resources”  such  as  screen  and  sound,  and  other  one  is  called +Page  27  of  159 +![](media/picture121.jpeg)![](media/picture122.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +“System  resources”  such  as  CPU  and  memory. +4.1.3.1.2  GUI  Resources +(1)  Definition +·  About  Control  of  GUI  Resources +AGL  is  supposed  the  following  devices  in  this  feature.  For  example,  display  with  touch  panel, +speaker,  and  microphone.  And  AGL  defines  that  “GUI  resources”  are  resources  that  provide  user +or  is  provided  by  user  on  those  devices,  such  as  windows,  sound  streams  and  input  events. +**Figure  7-1:  GUI  resources** +Page  28  of  159 +![](media/picture123.jpeg)![](media/picture124.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  controls  GUI  resources  according  to  external  conditions.  For  example,  Policy +Manager  limits  the  information  of  GUI  resources  while  the  vehicle  is  driving,  because,  the  too +much  information  distracts  the  attention  of  driver  from  driving  operations. +·  Associated  Software  Architecture +The  software  architecture  of  Policy  Manager  and  related  components  regarding  GUI  resources +control  is  as  below. +**Figure  7-2:  Associated  Software  Expected  Use  Case** +Page  29  of  159 + + ----------------------------------------------------------------------------------------------------------------------------------------------------- + > **No** > **Component** > **Description** + > + > **.** + ---------- ------------------------ --------------------------------------------------------- ------------------------------------------------------- + > 1 > Homescreen > Request  to  control  of  GUI  resources. + + > 2 > Applications > Request  to  output  or  input  of  GUI  resources. + + > 3 > UI  Component > Receive  driving  mode  and  day  night  mode.  And + > + > then  provide  the  corresponding  feature  to + > + > applications  UI  such  as  input  limitation  and + > + > changing  the  theme. + + > 4 > Application  Manager > Detect  application  installation.  Then  Notify  the + > + > definition  of  GUI  resources  such  as  role  by + > + > application  configurations. + + > 5- > Vehicle > Window  Manager + > > + > 1 > Info + > + > Control + + > 5- > Sound  Manager + > + > 2 + + > 5- > Input  Manager + > + > 3 + + > 5- > Vehicle  Info  Distributor + > + > 4 + + > 5- > User  Manager + > + > 5 + ----------------------------------------------------------------------------------------------------------------------------------------------------- + +![](media/picture125.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  is  related  with  the  below  components. +(2)  Role +Page  30  of  159 + + ----------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ------------------------------ ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 2 > Judgment  of  priority  of > (1)  Receives  the  input/output/control  request  of + > > + > GUI  resource > GUI  resources. + > + > (2)  Judgment  the  GUI  resource  owner  according  to + > + > external  conditions. + + > 3 > GUI  resource  control > (1)  Issue  the  GUI  resource  control  according  to + > + > judgment. + > + > (2)  Notify  the  driving  mode  and  day  night  mode + > + > that  is  calculated  by  external  conditions. + ----------------------------------------------------------------------------------------------------- + +![](media/picture126.jpeg)![](media/picture127.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  has  the  below  role. +Page  31  of  159 +![](media/picture128.jpeg)![](media/picture129.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  7-3:  Definition  of  Role** +GUI  resource  classifies  screen  resource,  sound  resource  and  input  resource.  Details  of  each +resource  type  are  as  follows: +a.  Screen  Resource +a-1.  External  Condition  Collection +Policy  Manager  collects  the  below  definition  that  is  related  with  screen  resource. +**Figure  7-4:  Definition  of  screen  resource** +•  Concept  of  Display,  Layer,  Layout  and  Area +AGL  supports  not  only  one  physical  display  but  also  two  or  more  displays.  Each  display  has  one +or  more  layer.  And  each  layer  must  be  connected  to  one  layout  defined  by  Homescreen.  Layout +Page  32  of  159 +![](media/picture130.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +consists  of  one  or  more  areas.  “Area”  is  graphics  composed  area  to  display  specific  graphics +window. +The  z-order  of  layers  is  flexible.  Policy  Manager  decides  the  z-order  of  each  layer  depending  on +objectives  of  them.  For  example,  layer-1  was  used  as  “phone  call  notification”,  and  layer-2  was +used  as  displaying  “map”,  then  Policy  Manager  will  decide  that  layer-1  should  be  upper  than +layer-2. +Layer  is  created  by  application  including  Homescreen.  When  application  creates  layer, +application  specifies  layer  type.  Layer  type  is  roughly  categorized  as  “Basic”  and  “Interrupt”. +“Basic”  layers  are  used  to  display  application  itself  such  as  media  playback,  map  drawing  and +setting  menu.  “Interrupt”  layers  are  used  to  display  overlay  windows  such  as  information  alert +and  enlarged  view. +When  application  creates  layer  with  ”Basic”  type,  application  must  specify  layout  type  for  it.  On +the  other  hand,  the  case  layer  with  “Interrupt”,  application  must  specify  corresponding  “Basic” +layer.  The  layout  of  “Interrupt”  layer  is  followed  by  “Basic”  layer’s  layout. +From  the  capability  of  Policy  Manager  point  of  view,  the  main  purpose  of  layer  is  to  decide  z- +order.  In  other  words,  if  there  is  a  scenario  to  change  z-order  of  two  or  more  windows  triggered +by  system  status  change  and/or  user  operation,  then  such  kind  of  window  must  assign  to +individual  layer. +•  Concept  of  Layer  Owner,  Role  and  Surface +“Layer  owner”  is  application  which  created  that  layer.  “Layer  owner”  can  request  each  area  of +that  layer.  When  “Layer  owner”  requests  specific  area,  “Layer  owner”  also  specify  “Role”  of +area.  “Role”  represents  how  to  be  used  that  area,  and  used  to  define  z-order  of  layers  by  Policy +Manager. +“Layer  owner”  also  can  request  to  change  “Role”  for  specific  area,  however,  whether  “Role” +change  is  acceptable  or  not  is  decided  by  Policy  Manager  by  using  policy  rule. +One  area  should  connect  to  one  graphics  window.  AGL  defines  the  term  “Surface”  as  graphics +window  to  display  into  one  area. +Page  33  of  159 +![](media/picture131.jpeg)![](media/picture132.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Surface  is  a  canvas  to  draw  graphical  image  by  application.  To  show  via  physical  display,  surface +drawn  by  application  must  be  assigned  to  specific  area.  Figure  7-16  describes  simplest  example +to  assign  one  surface  to  full  screen  with  one  layer.  If  layer  has  two  or  more  areas,  then +corresponding  surfaces  are  mapped  to  each  area.  According  to  example  of  Figure  7-16,  surface +is  fit  to  area  size  as  “squeeze”,  however  AGL  also  provide  a  way  to  fit  as  “letterbox”  and  “pan  & +scan”. +**Figure  7-5:  Definition  of  Surface** +•  Subdivision  of  “Interrupt”  Layer +Basically,  “Basic”  layer  corresponding  to  “Interrupt”  layer  is  used  to  display  application’s  main +surface.  However  there  are  some  exceptions.  For  example  virtual  keyboard  is  not  needed  main +surface.  However,  to  follow  this  layer  type  rule,  virtual  keyboard  must  have  corresponding +“Basic”  layer.  But  this  “Basic”  layer  never  used  to  display.  Also  on-screen,  such  as  alert  message +is  not  needed  main  surface  too.  But  it  must  have  corresponding  “Basic”  layer  from  same  reason. +According  to  above  concept  and  some  exceptions,  AGL  defines  four  layer  types  described +as  Table  7-3. +Page  34  of  159 + + --------------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- -------------------------------------------------------- ----------------------- + > 1 > Basic > This  is  application’s  basic  screen.  Typically, > Map  of  navigation + > + > application  requests  this  layer  at  first  time. + + > 2 > Interrupt > This  is  application’s  popup  screen. > Enlarged  view  of + > + > navigation + + > 3 > On-screen > This  is  system  popup  screen.  Typically,  On- > Warning  message + > > + > screen  service  (e.g.  Homescreen)  requests > popup + > + > this  layer. + + > 4 > Software > This  is  the  software  keyboard  screen. > Software  keyboard + > > + > keyboard > Typically,  software  keyboard  service + > + > requests  this  layer. + --------------------------------------------------------------------------------------------------------- + + ------------------------------------------------------------------------------------------------------ + > **No** > **Contents** > **Summary** > **Example** + ---------- ---------------- ------------------------------------------------------- ------------------ + > 1 > Role > This  is  screen  owner  (such  as  application  or > Navigation + > + > service)  role. + + > 2 > Sub  role > This  is  specific  screen  role. > Enlarged  view + ------------------------------------------------------------------------------------------------------ + +![](media/picture133.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +a-2.  Judgment  of  Priority  of  GUI  Resource +Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  screen  resource.  Role +is  the  category  name  of  screen  resource  priority.  Role  is  used  to  judgment  of  priority  by  Policy +Manager.  Table  7-4  and  Figure  7-6  describes  the  definition  of  role  and  sub  role. +Role  consists  of  role  and  sub  role.  Role  is  screen  owner  role  such  as  “Navigation”  and  “Software +Page  35  of  159 +![](media/picture134.jpeg)![](media/picture135.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +keyboard”.  Sub  role  defines  when  layer  type  of  the  screen  resource  is  not  “Basic”.  Sub  role  is +popup  screen  role  such  as  “Enlarged  view”  (of  Navigation). +**Figure  7-6:  Definition  of  Role  and  Sub  role** +The  screen  resources  are  sorted  of  priority  that  is  related  to  role  by  Policy  Manager.  If  display +has  two  or  more  layers,  then  all  layers  will  be  superimposed  by  z-order. +In  addition,  Policy  Manager  decides  the  area  of  "Interrupt"  layer  using  role.  Area  of  "Interrupt" +layer  must  be  same  area  of  the  related  "Basic"  layer.  "related"  means  that  "Role"  (is  not  "Sub +role")  of  "Basic"  and  "Interrupt"  is  same.  For  examples,  if  "Interrupt"  layer  is  set  “Navigation” +role  and  “Lane  guidance”  sub  role,  this  is  set  in  same  area  of  "Navigation"  role. +a-3.  GUI  resource  control +Policy  Manager  controls  the  screen  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  screen  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +directly. +Page  36  of  159 +![](media/picture136.jpeg)![](media/picture137.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +There  are  three  types  of  screen  resource  control: +One  is  allocation  of  each  surface  such  as  position,  size  and  size-fitting  method. +Second  one  is  visibility  control.  Basically,  visibility  should  be  “ON”  during  area  owner  was +assigned.  However,  visibility  may  set  to  “OFF”  during  driving  mode  due  to  driving  restriction. +Last  one  is  order  control  of  each  layer.  Policy  Manager  decides  the  order  of  each  layer,  and  issue +z-order  information  for  each  layer. +b.  Sound  Resource +b-1.  External  Condition  Collection +Policy  Manager  receives  the  below  definition  that  is  related  with  sound  resource. +**Figure  7-7:  Definition  of  Sound  Resource** +•  Zone +Zone  is  a  place  in  the  car,  such  as  driver  zone,  passenger  zone,  rear  seat  zone.  Each  zone  can +play  at  the  same  time. +Page  37  of  159 + + ------------------------------------------------------------------------------------------------- + > **No** > **Type** > **Summary** > **Example** + ---------- ------------- ---------------------------------------------- ------------------------- + > 1 > Basic > This  is  application’s  basic  sound. > Music  of  media + > + > player + + > 2 > Interrupt > This  is  application’s  interrupt  sound. > Guidance  of + > + > Navigation + + > 3 > Beep > This  is  beep.  Typically,  Homescreen > Display  touch  sound + > + > requests  this  type. + ------------------------------------------------------------------------------------------------- + +![](media/picture138.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +•  Sound  type +Sound  type  is  the  category  of  sound  resource.  Sound  type  must  be  set  by  each  sound  resource +owner  such  as  application.  If  application  wants  to  play  sound,  it  must  be  assigned  to  proper +sound  type  of  proper  zone.  Only  one  sound  stream  can  occupy  specific  sound  type  of  specific +zone.  In  other  words,  if  two  or  more  sound  streams  should  be  mixed  in  same  zone,  then  each +sound  stream  must  assign  to  individual  sound  type. +AGL  supports  the  following  sound  type,  however  it’s  just  sample  and  should  be  configurable. +•  Stream +Stream  is  connection  of  sound  resource  that  is  made  in  applications.  Sound  is  transferred  in +stream. +b-2.  Judgment  of  Priority  of  GUI  resource +Policy  Manager  receives  the  request  with  “Role”  that  is  related  with  each  sound  resource.  Role +is  the  category  name  of  sound  resource.  Role  is  used  to  judgment  of  priority  by  Policy +Manager.  Figure  7-8  describes  the  definition  of  role. +Page  38  of  159 +![](media/picture139.jpeg)![](media/picture140.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  7-8:  Sample  Role** +The  sound  resources  in  the  same  zone  and  same  sound  type  are  switched  along  the  priority  that +is  related  to  role  by  Policy  Manager.  In  other  words,  the  sound  resources  of  different  zones  or +different  sound  type  are  not  switched.  They  are  mixed. +b-3.  GUI  Resource  Control +Policy  Manager  controls  the  sound  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  sound  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control +directly. +There  are  two  types  of  sound  resource  control: +One  is  playback  control  such  as  play,  pause  and  stop.  Policy  Manger  issues  to  play  sound  for +sound  area  owner,  and  if  area  owner  was  changed,  then  issue  to  stop  previous  playing  sound +Page  39  of  159 +![](media/picture141.jpeg)![](media/picture142.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +stream  and  to  start  play  latest  area  owner. +Other  one  is  volume  control.  Two  or  more  sound  streams  of  same  zone  may  playback +simultaneously  if  each  sound  streams  are  assigned  to  different  sound  type.  In  this  case,  Policy +Manager  specifies  volume  parameter  for  each  sound  stream.  For  example,  if  route  guidance  and +music  playback  are  mixed,  assign  higher  volume  to  route  guidance  and  volume  down  for  music +playback. +c.  Input  Resource +c-1.  External  Condition  Collection +Policy  Manager  receives  the  below  definition  that  is  related  with  input  resource. +**Figure  7-9:  Definition  of  Input  Resource** +•  Device  Name +Device  name  is  identity  of  input  device  such  as  steering  SW  and  microphone. +•  Event  Type +Event  type  is  logical  group  of  input  event  from  each  input  device  such  as  volumes  and +temperatures. +c-2.  Judgment  of  Priority  of  GUI  resource +Page  40  of  159 +![](media/picture143.jpeg)![](media/picture144.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +If  application  wants  to  be  notified  input  event,  it  must  request  input  event  notice  with  device +name  and  event  type.  The  request  is  judged  whether  to  notify  by  Policy  Manager  using  policy +DB.  And  Vehicle  Info  Control  notifies  input  event  to  applications  along  the  result  of  the +judgment  as  below. +**Figure  7-10:  Definition  of  routing  rule** +OEM  special  switch  means  product  variant  configuration  in  Figure  7-10. +c-3.  GUI  Resource  Control +Policy  Manager  controls  the  input  resources  using  Vehicle  Info  Control.  Policy  Manager  only +issues  to  control  the  input  resources  but  it  is  actually  controlled  by  Vehicle  Info  Control  directly. +Input  resource  control  is  to  specify  event  target  to  Vehicle  Info  Control. +4.1.3.1.3  System  Resources +(1)  Definition +Policy  Manager  controls  System  resources  according  to  external  conditions.  For  example,  Policy +Manager  limits  memory  usage  of  background  applications  when  memory  shortage  was  occurred. +Page  41  of  159 + + ---------------------------------------------------------------------------------------------------- + > **ID** > **Role** > **Description** + ---------- ----------------------------- ----------------------------------------------------------- + > 1 > External  condition > (1)  Receives  the  external  conditions. + > + > collection + + > 3 > System  resource  control > 1.  Issue  the  System  resource  control  according + > + > to  external  condition  change. + > + > 2.  Kill  process(s)  forcibly  according  to  external + > + > condition  change. + ---------------------------------------------------------------------------------------------------- + +![](media/picture145.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  controls  System  resources  by  using  “Resource  Control”  of  kernel  layer.  So, +target  resources  are  CPU,  memory,  storage  bandwidth  and  network  bandwidth. +**4.1.3.2  Requirements** +4.1.3.2.1  Screen  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  physical  display  information.  Because  system +uses  physical  display  information  with  to  control  surface  to  other  system.  The  receive +information  must  include  as  follows. +a.  ID +b.  Display  resolution  (Vertical  and  horizontal  number  of  pixels) +c.  DPI +d.  Connected  ECU +Page  42  of  159 +![](media/picture146.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  receive  the  layout  definition.  Layout  definition  must  be +able  to  identify  the  all  areas  of  display.  As  a  result,  system  recognizes  the  available  area  list +according  to  current  layout  of  each  display. +The  receive  definition  must  include  the  follows. +a.  ID +b.  Area  list +System  must  provide  a  mechanism  to  receive  the  area  definition.  Area  is  set  application  surface +by  system  if  the  request  is  accepted  by  system.  As  a  result,  application  surface  displays  on  the +device. +The  receive  request  must  include  the  follows. +a.  Layout  ID +b.  ID +c.  Area  position  (Coordinate  of  the  upper-left) +d.  Area  size  (Length  \*  Width) +System  must  provide  a  mechanism  to  receive  the  layout  type  of  each  display.  System  can  specify +the  available  areas  if  layout  type  is  defined.  The  receive  information  must  include  the  follows. +a.  Display  ID +b.  Layout  ID +System  must  provide  a  mechanism  to  receive  the  priority  rule.  Because  system  must  judge  the +providing  resource  using  it  when  the  request  is  collision. +The  receive  information  must  include  the  follows. +a.  Role +b.  Priority +System  must  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  must  judge +driving  mode. +The  receive  information  must  include  the  follows. +a.  Velocity +Page  43  of  159 +![](media/picture147.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Brake  status +System  should  provide  a  mechanism  to  receive  the  vehicle  status.  Because  system  should  judge +day  night  mode. +The  receive  information  should  include  the  follows. +a.  The  brightness  of  the  interior +System  should  provide  a  mechanism  to  receive  the  user  status.  Because  system  should  judge  the +providing  resource  using  it. +System  should  provide  a  mechanism  to  receive  the  infrastructure  status.  Because  system  should +judge  the  providing  resource  using  it. +(2)  Judgment  of  Priority  of  GUI  Resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  layer  request.  System  allocates  the  physical +resource.  Application  must  request  the  area  on  this  layer  if  application  needs  to  display  the +resource. +The  receive  request  must  include  as  follows. +a.  Role +b.  Layer  type +The  receive  request  should  include  as  follows. +c.  Display  ID +System  must  provide  a  mechanism  to  receive  the  area  request.  System  sorts  layers  in  order  by +priority  that  is  related  with  the  specified  role.  Then  system  displays  the  application  surface  on +the  specified  area  on  the  specified  layer. +The  receive  request  must  include  as  follows. +a.  Role +Page  44  of  159 +![](media/picture148.jpeg)![](media/picture149.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Layer  ID +The  receive  request  must  include  as  follows  when  layer  type  of  the  specified  layer  is  “Basic”. +Because  there  is  a  specification  that  the  area  on  layer  except  basic  type  must  be  located  on  the +related  basic  type  area. +c.  Area  ID +**Figure  7-11:  Sequence  to  display** +System  should  provide  an  interface  to  request  both  screen  and  sound  resource  simultaneously. +In  this  request,  requester  should  choose  below  options. +a. +Requester  needs  both  screen  and  sound.  For  example,  if  screen  resource  was  available, +but  sound  resource  was  occupied  by  other  owner  of  higher  priority,  then,  request  should +be  refused. +b. +Requester  wants  screen  and  sound  resource  as  much  as  possible.  For  example,  if  screen +resource  was  available,  but  sound  resource  was  occupied  by  other  owner  of  higher +priority,  then,  only  screen  resource  should  be  assigned  to  requester. +Page  45  of  159 +![](media/picture150.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  request  during  system +running.  System  should  raise  the  requested  surface  to  the  top  of  the  display. +The  receive  request  should  include  the  follows  in  addition  to  the  information  of  the  normal +request. +a.  Effective  period  (Can  set  unlimited) +System  should  not  raise  the  other  surface  above  its  during  effective  period. +System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +a.  The  effect  at  the  transition +b.  The  effect  of  display  surface +System  must  provide  a  mechanism  to  judge  priority  of  resources.  The  screen  resources  are +sorted  of  priority  that  is  related  to  role  by  system.  If  display  has  two  or  more  layers,  then  all +layers  will  be  superimposed  by  z-order. +System  must  provide  a  mechanism  to  judge  visible  surfaces  according  to  vehicle  running  state. +System  must  hide  the  surface  that  has  too  much  information. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Visible  /  Invisible +b.  Change  position +c.  Raise +The  receive  request  must  include  as  follows. +i.  Surface  ID  \*Only  case  of  visible. +ii.  Display  ID  \*Only  case  of  visible. +iii.  Layer  ID  \*Only  case  of  visible. +Page  46  of  159 +![](media/picture151.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +iv.  Position  (Coordinate  of  the  upper-left)  \*Only  case  of  visible  and  change  position. +v.  Size  (Length  \*  Width)  \*Only  case  of  visible. +System  should  provide  a  mechanism  to  set  the  following  effect  of  the  surface  to  other  system. +a.  The  effect  at  the  transition +b.  The  effect  of  display  surface +4.1.3.2.2  Sound  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  zone  definition.  Because  system  uses  zone +information  with  to  control  stream  to  other  system.  The  receive  information  must  include  as +follows. +a.  ID +b.  Sound  device  ID +System  must  provide  a  mechanism  to  receive  the  sound  type  definition.  Because  system  uses +sound  type  information  with  to  control  stream  to  other  system.  The  receive  information  must +include  as  follows. +a.  ID +(2)  Judgment  of  Priority  of  GUI  resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +request  during  system  running. +Page  47  of  159 +![](media/picture152.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  receive  request  must  include  as  follows. +a.  Role +b.  Zone  ID +c.  Sound  type  ID +System  should  provide  a  mechanism  to  receive  the  request  of  forcibly  acquire  and  forcibly +release.  System  should  be  able  to  forcibly  acquire  and  forcibly  release  receive  request  during +system  running. +The  receive  request  should  include  as  follows  in  addition  to  the  information  of  the  normal +request. +a.  Effective  period  (Can  set  unlimited) +System  must  assign  resource  owner  as  requested.  And  system  must  not  assign  resource  owner +by  other  request  on  same  area  during  effective  period. +System  should  provide  a  mechanism  to  receive  the  request  that  is  specified  the  following  effect. +a.  The  effect  at  the  transition +b.  The  effect  of  output  sound +System  must  provide  a  mechanism  to  judge  priority  of  resources  when  there  are  two  or  more +resources  on  same  sound  type  on  same  zone.  System  judges  the  providing  resource  by  priority +of  resources  that  is  related  to  role. +\*  Boundary  of  the  role  between  Policy  Manager  and  application. +Page  48  of  159 +![](media/picture153.jpeg)![](media/picture154.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Figure  7-12:  Boundary  of  role  (Case  of  reverse) +System  should  provide  a  mechanism  to  manage  order  of  the  owner  request.  Because  system +should  provide  a  mechanism  to  hold  the  request  until  the  request  is  approved. +For  example,  if  current  playing  interrupt  sound  completed,  select  the  next  play  interrupt  sound +from  request  history  based  on  the  priority. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Mute  /  Unmute +b.  Change  zone +The  receive  request  must  include  as  follows. +i.  Stream  ID +ii.  Device +In  the  case  of  multi-channel  speaker,  the  receive  request  should  include  as  follows. +iii.  Channel  ID +Page  49  of  159 +![](media/picture155.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  should  provide  a  mechanism  to  set  the  below  effect  of  the  sound  to  other  system. +a.  The  effect  at  the  transition +b.  The  effect  of  output  sound +4.1.3.2.3  Input  Resource +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  receive  the  definition  that  is  used  judgment  of  resource +owner. +System  must  provide  a  mechanism  to  receive  the  input  device  information.  Because  system  uses +input  device  information  with  to  control  input  event  to  other  system.  The  receive  information +must  include  as  follows. +a.  ID +System  must  provide  a  mechanism  to  receive  the  event  type  definition.  Because  system  uses +input  device  definition  with  to  control  input  event  to  other  system.  The  receive  definition  must +include  as  follows. +a.  ID +b.  Related  event  IDs +(2)  Judgment  of  Priority  of  GUI  resource +System  must  provide  a  mechanism  to  assign  resource  owner  to  the  requested  resource +according  to  external  condition.  This  means  that  system  judges  the  providing  resource. +System  must  provide  a  mechanism  to  receive  the  owner  request.  System  must  be  able  to  receive +request  during  system  running. +The  receive  request  must  include  as  follows. +a.  Input  device  ID +Page  50  of  159 +![](media/picture156.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b.  Event  type  ID +System  should  provide  a  mechanism  to  judge  whether  to  accept  request  according  to  the +limitation  routing  rule  of  policy  DB. +(3)  GUI  Resource  Control +System  must  provide  a  mechanism  to  issue  the  resource  control  according  to  judgment. +System  must  provide  a  mechanism  to  issue  the  following  resource  control. +a.  Set  the  routing  rule +The  receive  request  must  include  as  follows. +i.  Input  device  ID +ii.  Event  type  ID +The  receive  request  must  include  either  as  follows. +iii.  The  allowed  application +iv.  The  denied  application +System  should  provide  a  mechanism  to  set  the  following  information. +a.  Application  that  has  active  surface +System  should  notify  the  touch  event  from  touch  panel  to  user  operating  application.  This +feature  is  needed  because  there  may  be  case  that  privilege  application  such  as  Homescreen +changes  the  active  surface. +4.1.3.2.4  System  Resources +(1)  External  Condition  Collection +System  must  provide  a  mechanism  to  collect  external  conditions  to  be  used  by  Policy  Manager +to  decide  proper  system  resource. +Page  51  of  159 +![](media/picture157.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Policy  Manager  must  detect  creation  and  deletion  of  process. +To  detect  creation  of  process,  Policy  Manager  can  assign  proper  system  resource  to  created +process. +Also,  to  detect  deletion  of  process,  Policy  Manager  can  assign  resources  of  deleted  process  to +other  active  processes. +To  assign  proper  system  resource  to  specific  process,  system  must  provide  a  mechanism  to +identify  process’s  role.  In  other  words,  Policy  Manager  must  recognize  the  purpose  of  each +active  process. +Policy  Manager  must  detect  current  memory  consumption  periodically. +To  detect  current  memory  consumption,  Policy  Manager  can  control  maximum  memory  to  each +process  to  prevent  memory  shortage.  Also,  Policy  Manager  may  kill  processes  which  were +thought  as  not  so  important  process. +Policy  Manager  must  detect  current  CPU  consumption  periodically. +To  detect  current  CPU  consumption,  Policy  Manager  can  control  priority  to  each  process  to  keep +system  performance.  Also,  Policy  Manager  may  kill  processes  which  seem  to  be  in  unexpected +busy  state. +System  must  provide  a  mechanism  to  notify  application  status  change  to  Policy  Manager. +Application  status  includes  as  below. +· GUI  resource  status,  such  as  foreground  or  background. +· +Resuming  last  status  or  not.  When  system  starts  up  or  log-in  user  changes,  system  must +resume  last  status.  In  this  case,  Policy  Manager  should  assign  much  resource  to  last +application  to  resume  quickly  as  much  as  possible. +(2)  System  Resource  Control +System  must  provide  a  mechanism  to  change  assigned  system  resource  per  process  or  process +group  according  to  external  conditions. +According  to  policy  based  decision,  Policy  Manager  must  assign  proper  system  resource  to +target  process  or  process  group  by  using  “Resource  Control”  of  kernel  layer.  (typically  cgroups +Page  52  of  159 +![](media/picture158.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +will  be  used) +System  must  provide  a  mechanism  to  kill  process  or  process  group  forcibly. +4.1.3.2.5  Resource  Management +Resource  Management  shall  consist  of  three  functional  components  -  Resource  Manager,  Policy +Manager,  Connection  Manager. +Resource  Management  shall  provide  CORBA  interfaces  to  rest  of  the  components  in  the  system. +Each  resource  request  shall  be  in  form  a: +AppID, +SourceID, +RequestorZoneID, +NeedAll  Flag  (to  specify  if  all  the  resources  need  to  be  allocated  ), +Required  Resource  List. +Resource  Management  shall  be  able  to  handle  resource  requests  for  Audio  Sinks  (eg:  Cabin +Speakers,  HeadPhones) +Resource  Management  shall  be  able  to  handle  resource  requests  for  Video  Sinks  (eg:  Display) +Resource  Management  shall  be  able  to  handle  Source  arbitration  (Mic,  WavPlayer  instances, +Tuners  etc.) +Resource  Management  shall  be  able  to  validate  all  the  input  parameters  for  a  resource  request +from  resource  requestors. +Resource  Management  shall  be  able  to  keep  track  of  all  the  available  resources. +Use  CCF  data  to  identify  all  the  resources  that  are  possible  in  the  system.  (static  identification) +Page  53  of  159 +![](media/picture159.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Use  dynamic  registration  by  the  resource  owners  to  identify  what  resources  out  of  the  above  list +are  available  at  a  point  of  time  in  the  system.  (dynamic  identification) +Resource  Management  shall  inform  about  resource  availability  and  unavailability  in  the  system +through  status  update. +Resource  Management  shall  support  stacking/queuing  of  resource  requests. +>  Receive  the  requests  from  the  resource  requestors. +>  Handle  each  request  in  chronological  order  and  check  for  policy  validation  through  Policy +Manager. +>  Add  the  validated  requests  into  a  priority  queue. +>  Process  each  request  from  the  top  of  the  queue  for  establishing  the  connection. +>  If  a  request  is  still  in  the  pending  queue  and  the  requestor  requests  to  withdraw  the  request,  it +shall  be  removed  from  the  queue. +Each  request  for  resource  shall  be  handled  as  an  independent  request  irrespective  of  any  earlier +request  by  the  same  requestor.  In  case  of  multiple  resources  requested  in  a  single  request,  it +shall  be  treated  as  a  single  request  and  will  be  processed  based  on  the  request  parameters. +If  the  NeedAll  flag  is  set  by  the  requestor,  it  shall  either  grant  all  the  requested  resources  to  the +requestor  or  none  of  them  shall  be  granted.  There  shall  be  no  partial  allocation  of  resources. +If  the  NeedAll  flag  is  not  set,  it  shall  be  able  to  do  partial  allocation  of  resources  i.e.  grant +some/all  of  the  resources  requested  by  the  requestor. +Resource  Management  shall  provide  an  interface  to  a  request  owner  to  remove/withdraw  an +existing  resource  request. +Resource  Management  shall  check  for  every  requested  resource  against  a  pre-defined  set  of +policies  if  the  request  can  be  served  at  this  point  of  time  or  not.  Below  is  a  list  of  possible  inputs +for  the  policy  decision: +>  Currently  Free  or  InUse  Sink  status +>  Who  is  the  resource  owner  of  the  currently  used  sink  resource  (if  it  is  in  use) +Page  54  of  159 +![](media/picture160.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +>  Priority  of  the  new  requestor  compared  to  the  currently  using  requestor. +Resource  Management  shall  use  the  system  state  as  an  additional  input  to  make  a  decision  if  a +request  can  currently  be  serviced  or  not.  Below  system  states  can  be  taken  as  input  to  the +policy  decision: +>  Based  on  the  speed  restriction  setting  for  a  specific  region,  a  request  can  be  granted/kept +pending. +>  Low  Power  Mode,  Eco  Mode,  System  errors  shall  also  be  used  to  make  policy  decisions. +At  any  point  of  time  it  shall  maintain  the  following  information  for  each  ZONE  for  use  by +resource  requestor: +>  Zone  ID +>  Allocated  Source  Instance +>  Allocated  Sink  Instance +>  Mute  status +Resource  Management  shall  not  consider  requirements  to  achieve  a  specific  feature  functionality +(e.g.  :  Lowering  audio  volume  of  rest  of  the  sinks  when  a  phone  call  is  in  progress)  as  an  input  to +the  resource  management  policy. +Resource  Management  shall  not  provide  support  for  requirements  to  achieve  a  specific  feature +functionality  (e.g.:  Pausing  a  pausable  source  when  phone  call  is  in  progress). +Resource  Management  shall  maintain  priorities  for  all  non-entertainment  sources  (eg: +AMFM\_TA,  PHONE\_NORMAL,  NAV\_VG,  etc.  shall  all  have  priorities).  In  case  two  sources  have +same  priority,  the  first  requestor  shall  be  granted  a  resource.  In  case  of  difference  in  priorities, +the  highest  priority  resource  request  shall  be  the  one  that  is  granted  the  resource. +Resource  Management  shall  maintain  same  priority  for  all  entertainment  sources  (eg:  MP,  DVD, +AMFM\_NORMAL,  etc.  shall  all  have  the  same  priority).  The  last  received  Entertainment  resource +request  will  be  the  one  that  is  granted  the  resource. +A  valid  (parameter  and  policy  validated)  resource  request  shall  never  be  denied  to  the  requestor. +It  shall  either  be  granted  or  kept  as  a  pending  request  in  the  priority  queue. +Page  55  of  159 +![](media/picture161.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Resource  Management  shall  be  responsible  for  reporting  a  broken  resource  status. +It  shall  be  the  responsibility  of  the  resource  requestor  to  remove  the  request  from  Resource +Manager  if  the  resource  is  no  longer  needed. +Resource  Management  shall  assign  a  sink  instance  (the  specific  instance  allocated  out  of  all +available  instances  of  the  requested  sink  type  for  a  particular  zone)  to  a  resource  request,  once +the  request  is  granted  against  the  set  policy. +Resource  Management  shall  maintain  connection  state  of  an  already  granted  connection. +Possible  connection  states  are  Active  or  Passive. +>  When  a  source  has  the  primary  (master)  control  over  a  sink,  the  connection  state  will  be +active. +Ex:  In  normal  mode,  a  driver  requesting  for  AMFM  source  to  Driver  HeadPhone  Sink  connection. +>  When  a  source  has  the  secondary  (slave)  control  over  a  sink,  the  connection  state  will  be +passive. +Ex:  Driver  using  the  AMFM  source,  at  the  same  time  the  rear  passenger  requesting  for  same +AMFM  source  on  Rear  headphone  sink. +Resource  Management  shall  be  responsible  for  connecting/building  a  new  source-sink +connection  using  the  underlying  platform  support. +Resource  Management  shall  be  responsible  for  removing/releasing  an  existing  source-sink +connection  using  the  underlying  platform  support. +Resource  Management  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is +removed/released. +Resource  Management  shall  provide  an  interface  to  unmute  the  audio  sink  when  a  connection  is +re-established  and  the  active  source  is  ready  to  use  the  sink  for  audio  routing. +Resource  Management  shall  provide  an  interface  to  unmute  an  audio  sink. +Page  56  of  159 +![](media/picture162.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Resource  Management  shall  inform  the  resource  requestor  when  the  sink  is  connected  and  ready +to  be  used  for  audio  routing. +Resource  requestor  needs  to  inform  the  Resource  Manager  when  they  are  ready  to  start  audio +routing.  This  information  shall  be  used  to  unmute  the  allocated  sink. +Resource  Management  shall  maintain  the  system  connection  table  at  any  point  of  time. +Connection  table  contains  information  regarding  which  sink  is  currently  allocated  to  which +source  instance. +Resource  Management  shall  support  handling  of  change  in  behaviour  based  on  Limo  setting: +>  Share  the  source  between  the  Rear  Seat  headphone  (Limo  mode  owner)  and  Cabin  Speakers. +System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +The  number  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +Headphones  shall  not  be  required  to  support  any  foreground  sinks. +In  case  of  Foreground  sources  and  Tuner  interrupt  sources,  any  sink  that  is  taken  away  from  a +source  because  of  a  high-priority  interruption,  need  to  be  returned  back  to  the  previous  source +(if  the  request  from  the  previous  source  is  still  valid  and  it's  the  next  highest  priority  request). +As  part  of  requirement  to  improve  connection  handling  efficiency,  it  shall  have  exceptions  to  not +disconnect  the  active  connection  while  switching  between  any  Tuner  Source-Sink  Background +connection  to  another  Tuner  Interrupt  Source  with  same  sink  connection. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sources. +Page  57  of  159 +![](media/picture163.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  provide  the  error  state  information  about  all  resources  to  the  Platform  Error  State +Manager. +It  shall  inform  the  resource  requestors  in  case  the  request  is  for  an  erroneous  or  faulty  sink. +It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +It  shall  support  rules/exceptions  (Blacklist)  that  define  resource  allocation  strategy  based  on +current  system  scenario. +E.g.:  If  there  is  a  blacklist  rule  that  says  a  Speech  session  shall  not  be  allowed  while  phone  call +is  in  progress,  then  even  if  a  FG  sink  is  available,  Speech  shall  be  denied  resources  and  kept  as  a +pending  request. +It  shall  provide  an  interface  to  receive  Limo  mode  setting  status. +It  shall  provide  an  interface  to  receive  status  when  a  rear-user  selects  to  take  Cabin  control. +It  shall  use  interfaces  of  early  app  to  receive  information  if  it's  already  using  Audio/Video +resources  and  update  its  internal  status  accordingly. +On  any  change  in  input  to  the  Policy  Manager  (system  state)  it  shall  reevaluate  all  active +connections  and  reconnect  or  disconnect  if  required. +E.g.  An  Amp  gets  disconnected,  then  all  active  connects  have  to  be  disconnected. +Once  the  Amp  gets  reconnected,  the  connection  info  shall  be  reevaluated  and  final  set  of +connections  shall  be  rebuilt  with  Amp. +It  shall  provide  CORBA  interfaces  to  the  Resource  Manager. +Page  58  of  159 +![](media/picture164.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  be  responsible  for  connecting/building  a  new  source-sink  connection  using  the  underlying +platform  support. +It  shall  be  responsible  for  removing/releasing  an  existing  source-sink  connection  using  the +underlying  platform  support. +It  shall  request  to  mute  the  audio  sink  before  an  existing  connection  is  removed/released. +It  shall  provide  an  interface  to  unmute  an  audio  sink. +System  shall  support  4  ForegroundBeep  sinks  and  2  ForegroundSpeech  sinks.  2  additional  sinks +are  reserved  for  Engine  noise  synthesis  which  is  outside  the  scope  of  this  document.  Additionally +1  FG  speech  sink  and  1  FG  beep  sink  is  reserved  for  future  use  by  ISC. +The  no.  of  sinks  supported  by  the  system  shall  be  configurable  through  LCF  parameter. +It  shall  inform  Resource  Manager  about  a  errors/failure  in  any  of  the  existing  sinks. +Headphones  shall  not  be  required  to  support  any  foreground  sinks. +It  shall  wait  for  the  application  manager  to  notify  it  to  prepare  for  shutdown. +It  shall  interact  with  the  data  storage  manager  to  access  (read  and  write)  persistence  data. +It  shall  interact  with  the  data  storage  manager  to  access  CCF  data. +**4.1.4  Sound  Manager** +A  sound  manager  is  a  mechanism  in  which  a  sound  output  demand  in  two  or  more  zones  from +two  or  more  applications  is  arbitrated,  an  audio  server  manages  control  of  a  sound  output  and  a +policy  manager  manages  a  mediation  rule. +Page  59  of  159 + + ---------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ------------------------------------------------------------ + > 1 > Routing  sound  streams > To  route  each  sound  stream  to  proper  zone(s). + + > 2 > Mixing  level  control > Mixing  two  or  more  sound  streams  after  volume + > + > control  of  each  sound  streams. + + > 3 > Sound  effect > Provide  a  capability  of  sound  effect  as  follows, + > + > ·     When  changing  sound  stream.  E.g.  fade-in, + > + > fade-out  and  cross-fade. + + > 4 > Reduced  dependency  of > Provide  well-defined  interface  to  reduce + > > + > hardware > dependency  of  hardware.  Well-defined  interface + > + > also  makes  it  possible  to  increase  the  effect  of + > + > portability  and  development  cost. + ---------------------------------------------------------------------------------------------------- + +![](media/picture165.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +A  zone  is  a  place  in  the  car  divided  by  the  purpose  of  output  power  of  sound  like  a  driver  zone,  a +passenger  zone,  and  a  rear  seat  zone.  Each  zone  can  play  at  the  same  time.  Refer  to  "Sound +resource"  of  "7.1.1.2  (2)  Role"  of  "7.1  Policy  Manager"  for  the  details  of  a  zone. +Applications  that  play  and  capture  audio  via  the  audio  server,  applications  that  control  things  like +volume  and  routing  via  the  audio  server,  and  a  policy  manager  that  works  with  the  audio  server +to  implement  automatic  audio  policies. +**4.1.4.1  Use  Case** +Please  refer  “sound  resource  control”  of  Policy  Manger  section. +Table  7-14  describes  the  role  of  sound  manager  to  be  satisfied  above  purpose  and  use  cases. +**4.1.4.2  Requirements** +Page  60  of  159 +![](media/picture166.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4.1.4.2.1  Routing  Sound  Streams +System  must  provide  a  mechanism  to  manage  sound  “zone”. +Refer  to  "(2)  Sound  resource"  of  "7.3.1.2.2  Role"  of  "7.3  Policy  Manager"  for  the  details  of  a +zone  and  how  to  manage  zone. +System  must  provide  a  mechanism  to  manage  one  or  more  connected  sound  devices,  and  each +channels  of  each  sound  device. +One  or  more  sound  devices  are  usually  connected  to  a  system,  and  each  sound  device  consists +of  one  or  more  channels.  And  each  channel  outputs  the  sound  of  a  monophonic  recording. +For  example,  as  for  a  stereo  sound,  a  speaker  is  connected  to  each  of  two  channels,  and  it  is +arranged  at  the  driver  side  of  a  car,  and  the  passenger  seat  side.  If  a  telephone  call  is  got  when +outputting  stereo  music  from  both  of  speakers,  only  the  channel  of  a  driver  side  needs  to  lower +musical  volume,  and  needs  to  mix  and  output  the  sound  of  a  telephone  (to  louder  sound  than +music).  For  this  reason,  the  system  needs  to  recognize  and  control  each  channel  of  each  sound +device. +The  system  must  determine  the  route  which  outputs  two  or  more  sound  streams  to  two  or  more +zones. +Although  the  output  place  zone  of  a  sound  stream  may  change  dynamically  according  to  the +present  state  of  vehicles  and  a  policy  manager  makes  the  decision,  sound  manager  requires  the +mechanism  in  which  a  route  is  smoothly  changed  based  on  the  determination  of  policy  manager. +System  must  provide  a  mechanism  to  manage  two  or  more  sound  zone  as  grouped  zone. +System  must  provide  a  mechanism  to  do  volume  control  for  specific  zone. +All  the  sound  outputted  to  a  certain  zone  is  adjusted  by  the  volume  of  the  zone. +System  must  provide  a  mechanism  to  control  sound  stream. +Control  of  a  sound  stream  is  as  follows. +· +Mute/unmute:  System  must  provide  a  mechanism  to  do  mute  or  unmute  to  any  sound +stream. +· +Suspend/resume:  System  must  provide  a  mechanism  to  suspend  or  resume  to  any  sound +Page  61  of  159 +![](media/picture167.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +stream. +Volume  control:  System  must  provide  a  mechanism  to  change  volume  to  any  sound  stream. +4.1.4.2.2  Mixing  Level  Control +The  system  must  offer  the  mechanism  for  arbitrating  two  or  more  sound  streams  outputted  to +the  same  zone  according  to  a  policy  manager's  arbitration. +System  must  provide  a  mechanism  to  do  mixing  after  volume  control  of  each  sound  streams. +System  must  provide  a  mechanism  to  attenuate  sound  volume  when  other  sound  stream +requested  to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  return  to  the  volume  before  attenuating +the  volume  of  a  sound  stream  when  interrupted  sound  stream  was  ended. +System  must  provide  a  mechanism  to  mute  sound  volume  when  other  sound  stream  requested +to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  unmute  sound  volume  when  interrupted +sound  stream  was  ended. +System  must  provide  a  mechanism  to  suspend  sound  stream  playback  when  other  sound  stream +requested  to  play  into  same  sound  zone. +In  this  case,  system  must  also  provide  a  mechanism  to  resume  playback  when  interrupted  sound +stream  was  ended. +4.1.4.2.3  Sound  Effect +When  sound  stream  was  changed,  system  must  provide  a  mechanism  to  do  sound  effect. +System  must  provide  typical  sound  effect  such  as  fade  in  and  fade  out. +System  must  provide  a  mechanism  to  add,  replace  and  delete  sound  effect  easily  by  using  plugin +architecture. +Page  62  of  159 + + ------------------------------------------------------------------------------------------------------------------------- + > **No.** > **Input  type** > **Associated  device** > **Description** + ----------- ------------------- -------------------------- -------------------------------------------------------------- + > 1 > Key > Steering  switch > Simple  key  event. + > + > Deliver  to  application. + + > 2 > Keyboard > Virtual  keyboard > Keyboard  event. + > + > Deliver     to     application,     then     use     input + > + > method  backend  if  needed. + + > 3 > Touch > Touch  panel > Touch  event,  such  as  start,  stop  and  move. + > + > Also  supports  double  click  and  multi-touch + > + > capability. + > + > Deliver  to  application. + + > 4 > Sound > Microphone > Sound  input. + ------------------------------------------------------------------------------------------------------------------------- + +![](media/picture168.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4.1.4.2.4  Reduced  Dependency  of  Hardware +Sound  Manager  must  be  able  to  retrieve  system  structure  regarding  sound  device  and  channels +of  each  device.  And  the  system  must  enable  addition/deletion  of  a  sound  device  by  the  means +which  does  not  need  rebuild  of  systems,  such  as  a  configuration. +**4.1.5  Input  Manager** +The  Input  Manager  provides  a  capability  to  deliver  input  events  to  the  proper  application +depending  on  request  from  Policy  Manager.  Policy  Manager  will  decide  event  target  per  each +input  area.  Also,  the  IVI  system  may  use  various  car-oriented  input  devices  such  as  steering +switch.  Input  manager  provides  a  capability  to  abstract  such  kind  of  input  event. +**4.1.5.1  Use  Case** +Please  refer  “input  resource  control”  of  Policy  Manger  section. + + --------------------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- --------------------------- ----------------------------------------------------------------- + > 1 > Abstract  device  event > Provide  capability  to  abstract  from  device  event  to + > + > application  readable  event  name,  such  as  “volume + > + > up”  and  “right  arrow”. + + > 2 > Event  delivery > Provide  capability  to  deliver  input  event  to  specified + > + > application. + --------------------------------------------------------------------------------------------------------- + +![](media/picture169.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Deliver  to  application  or  voice  recognition +engine. +Table  7-14  describes  the  role  of  input  manager  to  be  satisfied  above  purpose  and  use  cases. +**4.1.5.2  Requirements** +**4.1.5.3  Abstract  Device  Event** +System  must  provide  a  mechanism  to  re-configuration  regarding  input  devices  without  re-build. +Because,  connected  input  devices  may  different  by  car  grade,  car  type,  destination  and  optional +equipment. +**4.1.5.4  Event  Delivery** +System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application. +System  must  provide  an  interface  to  apply  event  delivery  rule  by  using  attribute  pair  “device  id” +and  “destination  application  id”. +Device  id  specifies  a  logical  device  name.  Logical  device  name  will  link  to  physical  device  by +UIM.2.1.2. +Page  64  of  159 +![](media/picture170.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Also,  system  must  provide  a  mechanism  to  change  event  delivery  rule  dynamically. +System  must  provide  a  mechanism  to  link  between  logical  device  name  and  physical  device. +System  must  provide  a  mechanism  to  deliver  any  input  event  to  any  application  depending  on +delivery  rule  defined  in  UIM.2.1.1. +System  must  provide  a  mechanism  to  inhibit  any  event  delivery. +This  function  makes  it  possible  to  restrict  input  event  during  driving  mode. +**4.1.6  User  Manager** +**4.1.6.1  Use  Case** +**4.1.6.2  Personal  Identification** +User  manager  provides  multi-user  environment.  A  car  may  be  used  by  two  or  more  people,  and  a +person  may  use  two  or  more  cars,  by  using  rent-a-car,  for  example. +**4.1.6.3  User  Preference** +Multi-user  environment  provides  same  user  experience  for  each  user. +Also,  multi-user  aims  seamless  personal  data  sharing  not  only  between  cars  but  also  including +other  devices  such  as  smartphones  and  smart  TVs.  Furthermore,  it  will  include  seamless  data +sharing  from  your  home  and  your  office. +Identify  the  person,  and  log-in  to  the  IVI  system  as  a  specified  user.  Personal  identify  may  be +provided  by  traditional  user  name  and  password  pair,  smart  key  or  biometrics. +Once  a  user  has  logged-in  to  IVI  system,  IVI  system  should  provide  personalized  user +experience.  For  example,  Bob  uses  English,  but  Alice  uses  French.  Also,  Bob  likes  rock-music, +*but Alice likes classic-music. In this case, English and rock-music should be selected when B*ob  is +Page  65  of  159 +![](media/picture171.jpeg)![](media/picture172.jpeg)![](media/picture173.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +logged-in,  and  Japanese  and  classic-music  should  be  selected  when  Alice  is  logged-in. +**Figure  7-24  :  Provide  Logged-in  User’s  UE  (User  Experience)** +**4.1.6.4  Rent-a-car  and/or  Replacing  a  Car** +When  Bob  uses  a  rent-a-car,  same  preference  should  be  adapted  as  if  he  rode  his  own  car.  If +Bob’s  preference  was  stored  in  a  cloud,  then  this  can  be  supported.  However,  security  is +important  in  this  scenario.  For  example,  Bob  must  not  be  able  to  access  to  other  user’s +preference. +**Figure  7-25  :  User  data  sharing  between  cars** +Page  66  of  159 +![](media/picture174.jpeg)![](media/picture175.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**4.1.6.5  Seamless  Data  Sharing** +Cloud-based  user  data  syncing  will  enable  seamless  data  sharing  between  IVI  systems  and +smart-phones,  home  networks  and  accessing  from  your  offices. +**Figure  7-26  :  User  data  sharing  over  the  cars** +**4.1.6.6  Role** +**Error!  Reference  source  not  found.**  describes  the  role  of  the  User  Manager  to  satisfy  the  above +purpose  and  use  cases. +**Table  7-17  :  Role  of  User  Manager** +**No.** **Role** **Description** +Page  67  of  159 +![](media/picture176.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +1 User  identification +Provide  a  mechanism  to  identify  user,  such  as  user +name  and  password  pair,  smart  key  and  biometrics. +Provide  a  mechanism  to  log-in  to  the  IVI  system  as +a  specified  user. +When a different user logs in, proper user +preference  for  the  user  must  be  applied,  and +resume  last  state  of  corresponding  user. +Also,  each  application  can  store  application’s  data +per  user.  In  such  cases,  proper  user  data  must  be +applied  when  a  different  user  logs  in. +2 User  preference +Provide  a  mechanism  to  apply  user  preference  of +logged-in  user. +User  preference  includes  the  following  data. +· User  interface,  such  as  locale  and  wall- +paper. +· Resume  last  application’s  status  of  specified +user. +· Application  specific  data. +3 User  data  management +Provide  a  mechanism  to  manage  cloud  based  user +data. +The  following  capabilities  are  required. +· Download  user  data  of  the  logged-in  user +from  the  cloud. +· Update  cloud  data  if  the  user  data  was +updated  by  user  operation  or  otherwise. +· Periodically  sync-up  w/  cloud  because  user +data  may  be  updated  by  other  devices. +In  addition  to  the  above  basic  capabilities,  user  data +cache  is  essential  for  a  car,  since  a  car  may  not +always  have  a  reliable  network  connection. +4 Security Because  cloud  based  sharing  user  data  may  be +accessed  from  any  place,  user  data  must  be +protected  from  unexpected  data  access. +Page  68  of  159 +![](media/picture177.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +So,  IVI  system  must  provide  security  mechanism +regarding  accessing  to  cloud  based  user  data. +**4.1.6.7  Requirements** +4.1.6.7.1  User  Identification +System  must  provide  a  mechanism  to  identify  logged-in  user. +System  must  provide  a  mechanism  to  enter  user  name  and  password,  and  verify  password  to +identify  logged-in  user. +System  should  provide  a  mechanism  to  read  smart  key  attribute  to  identify  logged-in  user.  For +example,  using  NFC. +System  should  provide  a  mechanism  to  identify  logged-in  user  by  using  biometrics. +4.1.6.7.2  User  Preference +When  a  logged-in  user  is  identified,  system  must  apply  user  preference  depending  on  the +currently  logged-in  user. +System  must  provide  a  mechanism  to  apply  personalized  user  experience  as  follows. +- Locale  settings +- UX  theme +Wall  paper +System  must  provide  an  easy  mechanism  to  add  plugin  function  and/or  attribute  of  personalized +user  experience. +Page  69  of  159 +![](media/picture178.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  to  switch  application  data  per  user,  and  apply  logged-in +user’s  application  data  automatically. +When  user  is  identified  and  logged-in,  the  system  must  apply  last  status  of  logged-in  user.  Last +status  refers  to  the  status  of  the  system  as  the  current  logged-in  user  has  last  logged-out  of  the +system.  Specifically,  last  status  includes  the  following. +- Foreground  applications.  That  means  displayed  applications. +Background  applications. +When  user  logs  in  for  the  first  time,  the  system  must  apply  user  preference  for  new  log-in  user. +System  must  provide  a  mechanism  to  apply  default  preference  attributes  for  new  log-in  user. +System  must  provide  default  preference  attributes  and  HMI  to  apply  for  first  time  log-in  user. +4.1.6.7.3  User  Data  Management +System  must  provide  a  mechanism  to  manage  user  data. +AGL  defines  “user  data”  as  a  general  term  which  includes  all  the  data  necessary  to  realize  user +preference. +User  data  shall  be  stored  in  the  cloud.  The  cloud  provides  user  data  not  only  to  IVI  systems  but +also  other  systems  and/or  devices  such  as  smartphones,  Home-PCs,  business-PCs,  HEMS  and +home  electronics. +System  must  provide  a  mechanism  to  apply  user  preference  and  to  supply  user  data  to +application  by  using  cloud  based  user  data. +System  must  provide  a  mechanism  to  download  cloud  based  user  data  and  apply  it  as  user  data +of  the  IVI  system. +When  user  data  is  updated  in  the  IVI  system,  then  the  system  must  upload  updated  user  data  to +the  cloud. +Also,  since  other  device  or  system  may  update  shared  user  data  elsewhere,  system  must  provide +Page  70  of  159 +![](media/picture179.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +a  mechanism  to  sync  with  the  cloud  periodically  to  keep  user  data  in  the  IVI  system  up-to-date. +Because  the  IVI  system  is  not  necessarily  connected  to  a  network,  the  system  must  provide  a +mechanism  to  cache  downloaded  user  data. +If  the  IVI  system  re-connected  to  a  network,  system  must  sync  with  the  cloud  as  soon  as +possible. +4.1.6.7.4  Security +Because  user  data  may  include  personal  information,  system  must  provide  a  mechanism  to +protect  user  data  from  risks  including  but  not  limited  to  leakage,  tampering  and  theft. +System  must  provide  a  mechanism  to  protect  user  data  when  accessing  to  the  cloud. +- +System  must  authenticate  communication  entity.  In  other  words,  IVI  system  must +authenticate  cloud  server,  and  cloud  server  must  authenticate  client  such  as  IVI  system, +smartphone  or  PC. +- +System  must  provide  a  mechanism  to  encrypt  transported  data  via  a  network. +- +System  must  provide  a  mechanism  to  transport  data  via  a  network  with  protection +against  falsification  of  data  from  unauthorized  access  or  illegal  access. +- +Cloud  server  must  provide  a  mechanism  to  authenticate  individual  user,  and  provide +user  data  only  to  the  authorized  user. +Because,  two  or  more  user’s  user  data  may  be  stored  in  IVI  system  as  a  cache,  system  must +provide  a  mechanism  to  protect  cache  data  from  other  users.  The  protection  of  cached  data  to +include  not  only  the  current  multi-user  environment  risk,  but  also  the  risk  of  attacks  against +cached  data.  In  other  words,  only  logged-in  user’s  cache  data  can  be  accessed. +4.2  Web  HMI +Web  based  HMI.  Contains  applications,  web  runtime  environment,  and  web-based  home  screen. +**4.2.1  Web  API** +Page  71  of  159 +![](media/picture180.jpeg)![](media/picture181.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  is  discussed  that  HMI  parts  of  IVI  system  will  be  developed  using  HTML5.  APIs  to  use  service +function  in  IVI  system  from  web  applications  is  needed.  Audio  Visual  API  provides  APIs  for  audio +visual  equipment  control  to  web  applications.  (e.g.  Media  files  on  storage,  CD,  DVD,  BT-Audio, +Photo,  etc.) +Web  applications  use  Audio  Visual  API  to  play  audio  visual  contents  on  IVI  system.  Use  case  of +Audio  Visual  API  is  shown  in  Figure  6-1. +**Figure  6-1:  Use  case  of  Audio  Visual  API** +**4.2.1.1  Requirements** +Audio  Visual  API  must  provide  API  to  select  Audio  Visual  contents. +· Select  content  using  URL +· +Select  content  using  contents  list  provided  by  multimedia  subsystem +Page  72  of  159 +![](media/picture182.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Audio  Visual  API  must  provide  API  to  playback  Audio  Visual  contents.  (Media  file  on  storage,  CD, +DVD,  BT-Audio,  Photo,  etc.) +· Play +· Pause +· Fast-forward +· Rewind +· Track  up +· Track  down +· Select  playmode  (Repeat/Random) +Audio  Visual  API  must  provide  API  to  control  a  volume. +· Volume  up +· Volume  down +· Mute +Audio  Visual  API  must  provide  API  for  metadata  access  about  Audio  Visual  contents. +Audio  Visual  API  must  provide  API  for  notifications. +· The  case  that  playback  state  is  changed +· The  case  that  Audio  Visual  contents  is  add  /  removed +Audio  Visual  API  must  provide  API  to  play  AM/FM  radio. +· Change  the  frequency. +· Change  the  broadcasting  stations. +· Receive  the  list  of  broadcasting  stations. +· Select  the  preset  channel. +· Get  the  information  of  the  broadcasting  station. +Audio  Visual  API  must  provide  API  to  play  digital  radio. +· Store  the  broadcast  program  information. +Page  73  of  159 +![](media/picture183.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Get  the  broadcast  program  information. +· Get  the  play  time. +· Play  the  radio  broadcast  cached. +AGL  System  must  support  a  web  API  to  access  Vehicle  information. +AGL  System  must  support  web  API  to  control  STT/TTS  daemon. +AGL  System  must  support  web  API  to  control  navi  engine. +AGL  System  needs  to  provide  a  Web  API  to  allow  peer  to  peer  communication  between  two  web +apps. +AGL  System  needs  to  provide  an  API  to  allow  peer  to  peer  communication  between  a  web  app +and  a  native  app. +AGL  System  must  support  access  control  over  app  to  app  communications.  Service  provider +should  be  able  to  restrict  subscriber. +AGL  System  must  support  W3C/HTML5  DOM,  Forms  and  Styles. +AGL  System  must  support  W3C/HTML5  Device  APIs:  Touch  Events,  Device  Orientation, +Network  Information +AGL  System  must  support  W3C/HTML5  Graphics  APIs:  canvas,  canvas  2D  context,  and  SVG +AGL  System  must  support  W3C/HTML5  Media:  audio  and  video  tags,  user  media  and  web  audio +AGL  System  must  support  W3C/HTML5  Communication  APIs:  websocket,  web  messaging, +server  sent  events,  session  history  of  browsing  context +*AGL System must support W3C/HTML5 Storage APIs: Web storage, File, Database, Web S*QL +Page  74  of  159 +![](media/picture184.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  System  must  support  W3C/HTML5  Security  APIs:  Cross-Origin  Resource  Sharing,  HTML5 +The  iframe  element,  Content  Security  Policy  1.0. +AGL  System  must  support  W3C/HTML5  UI  APIs:  Clipboard,  DnD,  Web  Notifications +AGL  System  must  support  W3C/HTML5  Performance  APIs:  Web  workers,  Page  Visibility,  Timing +control,  Navigation  timing +AGL  System  must  support  W3C/HTML5  Location  API:  Geolocation +AGL  System  must  support  W3C/HTML5  Widget:  Widget  Packaging  and  XML  Configuration, +Widget  Interface,  XML  Digital  Signatures  for  Widgets,  Widget  Access  Request  Policy +AGL  System  must  support  Khronos  WebGL  API. +**4.2.2  Web  Runtime** +The  Web  Runtime  module  contains  the  bindings  for  the  Web  Application  Framework  to  access +the  AGL  Application  Framework  and  Services. +**4.2.2.1  Requirements** +AGL  system  Web  Runtime  shall  provide  full  web  application  lifecycle  management  (e.g., +installation/removal). +AGL  System  Web  Runtime  shall  provide  full  execution  environment  for  web  apps  (i.e.,  launch, +view  generation,  rendering,  etc.) +AGL  system  Web  Runtime  shall  provide  a  mechanism  to  implement  plugins/extensions  to  add +better  device/platform  integration. +Page  75  of  159 +![](media/picture185.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  system  Web  Runtime  shall  provide  a  mechanism  to  manage  apps'  access  control  and  also  to +categorize  apps  with  different  privileges. +System  must  provide  high  level  GUI  components  for  Web  application. +At  least,  below  components  are  required. +· Text  labels +· Button +· Radio  button +· Check  box +· Tab  panel +· Animation  (e.g.  MNG,  GIF  animation) +· Slider +· Accordion  list +· Anchor +· Text  input  form +· Dropdown  list  box +· Date  picker +4.3  Native  HMI +The  Native  HMI  provides  an  application  framework  for  those  applications  that  are  not  written +using  Javascript  or  other  web  technologies. +**4.3.1  Native  App  Runtime** +The  Native  Runtime  module  contains  the  bindings  for  the  Native  Application  Framework  to +access  the  AGL  Application  Framework  and  Services. +**4.3.1.1  Requirements** +System  must  provide  high  level  GUI  components  for  native  application. +Page  76  of  159 +![](media/picture186.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +At  least,  below  components  are  required. +· Text  labels +· Button +· Radio  button +· Check  box +· Tab  panel +· Animation  (e.g.  MNG,  GIF  animation) +· Slider +· Accordion  list +· Anchor +· Text  input  form +· Dropdown  list  box +· Date  picker +**4.3.2  Native  Application  Framework** +The  platform  can  support  multiple  application  frameworks  any  of  which  may  be  built  into  an +SDK  or  product  build.  The  application  framework  contains  any  code  specifically  written  for  that +framework  as  well  the  bindings  to  the  Services  and  Operating  Systems  layers  that  the +application  framework  provides  for  its  applications. +**5   Services   Layer** +The  Services  Layer  contains  user  space  services  that  all  applications  can  access.  Generally  the +services  provide  either  an  IPC  type  interface  or  a  subroutine/  function  API.  These  interfaces +remain  the  same  for  a  given  implementation  and  it  is  up  to  the  Application  Framework  Runtime +modules  to  provide  access  to  these  interfaces  to  the  applications.  Since  we  are  trying  to  avoid +unnecessary  interface  shims,  it  is  not  necessary  for  AGL  to  define  standard  service  layer +interfaces  for  a  given  module.  Unless  otherwise  specified  the  API  depends  upon  the  interfaces +provided  by  the  open  source  packages  chosen  for  a  module.  Different  implementations  may +choose  different  packages  for  a  given  function  and  it  is  left  to  the  Application  Framework +runtime  to  adjust  to  any  new  interfaces, +Page  77  of  159 +![](media/picture187.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1  Platform  Services +Platform  Services  Layer.  Conventional  Linux  platform  services +**5.1.1  Bluetooth** +This  document  describes  requirements  regarding  registration,  (dis)connection  and  device +information  management  between  Bluetooth  device  and  infotainment  system.  Necessary +Bluetooth  profiles  in  automotive  use  case  are  defined  here. +**5.1.1.1  Requirements** +The  Telephony  system  shall  be  designed  to +support  a  minimum  of  BT3.0+EDR,  but  shall  be  possible  to  upgrade  to  Bluetooth  4.0+EDR +without  hardware  upgrade. +A  Bluetooth  hands-free  system  shall  provide  the  following  BT  profiles: +· Core  2.0  +  EDR  inc.  GAP  (Generic  Access  Profile) +· HFP  (Hands  Free  Profile) +· OBEX  (Object  Exchange) +· OPP  (Object  Push  Profile) +· PBAP  (Phonebook  Access  Profile) +· SPP  (Serial  Port  Profile) +· SDAP  (Service  Discovery  Access  Profile) +If  the  BT  system  is  designed  to  operate  with  BT  Media  Players  (E.g.  control  and  stream  music +from),  the  system  shall  also  support  the  following  incremental  BT  profiles: +· A2DP  (Advanced  Audio  Distribution  Profile) +· AVRCP  (Audio  Visual  Remote  Control  Profile) +The  link  key  shall  be  minimum  128  bits.  The  encryption  key  is  negotiated  and  shall  be  set  at  the +Page  78  of  159 +![](media/picture188.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +highest  supported  value  by  the  remote  device.  The  Telephony  system  shall  be  capable  of +generating  up  to  128-bit  encryption  key.  The  Telephony  system  will  not  be  the  limiting  device  in +encryption  key  length  negotiation. +When  implemented  by  the  remote  device  Simple  Secure  Pairing  'Numeric  comparison'  method  as +default  pairing  mechanism.  However  when  remote  device  is  limited  a  configurable  priority +scheme  will  be  adopted  where  the  order  of  mechanisms  will  be  determined  at  configuration +time. +The  Telephony  system  shall  provide  Bluetooth  Power  Class  2.  The  operating  range  of  Class  2  is +10  meters  and  maximum  power  is  2.5  mW  (4  dBm). +The  Telephony  system  shall  have  provision  for  1,  3  and  5-slot  packet  transmission.  It  shall +allow  using  five-slot  packet  transmission  for  faster  data  rate. +The  Telephony  system  shall  use  IrMC  standards  as  directed  by  the  BT  specification.  It  is  a +standard  from  IrDA,  including  IrOBEX  for  object  exchange  including  vCards,  vCalendars,  etc. +vCard  is  the  electronic  business  card.  It  is  used  for  Personal  Data  Interchange  (PDI).  vCards  are +often  attached  to  e-mail  messages,  and  can  be  exchanged  on  Instant  Messaging.  vCard  contain +name  and  address  information,  phone  numbers,  and  e-mail  addresses. +vCard  version  2.1  is  widely  adopted  by  e-mail  clients.  It  contains  FN,  N,  PHOTO,  BDAY,  ADR, +LABEL,  TEL,  EMAIL,  MAILER,  TZ,  GEO,  TITLE,  ROLE,  Logo,  Agent,  ORG,  NOTE,  REV,  SOUND, +URL,  UID,  Version,  and  KEY  properties. +vCard  version  3.0  is  IETF  standards  format.  It  is  defined  in  following  two  parts: +MIME  Content-Type  for  Directory  Information +vCard  MIME  Directory  Profile +It  contains  NICKNAME,  CATEGORIES,  PRODID,  SORTSTRING  and  CLASS  properties  along  with +the  vCard  version  2.1  properties. +The  touch-screen  or  head  unit  HMI  must  have  the  ability  to  delete  a  Bluetooth  device  and  any +associated  data  (E.g.  phonebook,  voicemail  number)  when  required,  even  if  the  BT  device  list  is +not  full. +The  Telephony  system  shall  use  SCO  link  for  voice  data  if  eSCO  link  is  not  supported  else  eSCO +Page  79  of  159 + + ------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **Support  in  HF** > **AGL** + ----------- ------------------------------------------------------------- ----------------------- ----------- + > 1 > Connection  management > Mandatory > x + + > 2 > Phone  status  information > Mandatory > x + + > 3 > Audio  Connection  handling > Mandatory > x + + > 4 > Accept  an  incoming  voice  call > Mandatory > x + + > 5 > Reject  an  incoming  voice  call > Mandatory > x + + > 6 > Terminate  a  call > Mandatory > x + + > 7 > Audio  Connection  transfer  during  an  ongoing  call > Mandatory > x + + > 8 > Place  a  call  with  a  phone  number  supplied  by  the > Option > x + > + > HF + + > 9 > Place  a  call  using  memory  dialing > Option > - + + > 10 > Place  a  call  to  the  last  number  dialed > Option > - + ------------------------------------------------------------------------------------------------------------- + +![](media/picture189.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +shall  be  used. +5.1.1.1.1  Hands  Free  Profile +The  Telephony  system  shall  implement  Hands-Free  Profile  (HFP)  as  per  the  hands-free  Profile +specification  version  1.6  or  later. +The  Telephony  system  shall  enable  a  headset,  or  an  embedded  Hands-Free  unit  to  connect, +wirelessly,  to  a  cellular  phone  for  the  purposes  of  acting  as  the  cellular  phone's  audio  input  and +output  mechanism  and  allowing  typical  Telephony  functions  to  be  performed  without  access  to +the  actual  phone. +It  shall  provide  following  roles: +Hands-Free  unit  (HF) + + > 11 > Call  waiting  notification > Option > x + ------- ------------------------------------------------------ ---------- ---------- + > 12 > Three  way  calling > Option > x(\*1) + > 13 > Calling  Line  Identification  (CLI) > Option > x + > 14 > Echo  canceling  (EC)  and  noise  reduction  (NR) > Option > x + > 15 > Voice  recognition  activation > Option > x + > 16 > Attach  a  Phone  number  to  a  voice  tag > Option > - + > 17 > Ability  to  transmit  DTMF  codes > Option > x + > 18 > Remote  audio  volume  control > Option > - + > 19 > Respond  and  Hold > Option > x + > 20 > Subscriber  Number  Information > Option > x + > 21a > Enhanced  Call  Status > Option > x + > 21b > Enhanced  Call  Controls > Option > - + > 22 > Individual  Indicator  Activation > Option > - + > 23 > Wide  Band  Speech > Option > x + > 24 > Codec  Negotiation > Option > x + +![](media/picture190.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +\*1:  Does  not  support  Multi-party  (conference)  call +The  Telephony  system  shall  be  able  to  use  the  AT+CGMM  query/response  to  determine  the +model  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +string  in  a  phone  model  CGMM  variable. +· Phone  Model  CGMM: +· Type:  string +· Max  length:  200  chars +Page  81  of  159 +![](media/picture191.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +The  Telephony  system  shall  be  able  to  use  the  AT+CGMI  query/response  to  determine  the +Manufacturer  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be +stored  as  a  string  in  a  phone  model  CGMI  variable. +· Phone  Model  CGMI: +· Type:  string +· Max  length:  200  chars +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +The  Telephony  system  shall  be  able  to  use  the  AT+CGMR  query/response  to  determine  the +revision  of  the  phone  over  the  HFP  profile  connection.  Whatever  is  returned  shall  be  stored  as  a +string  in  a  phone  model  CGMR  property. +· Phone  Model  CGMR: +· Type:  string +· Max  length:  200  chars +· Persistence:  No +A  property  shall  exist  for  each  device  which  is  connected  to  the  system. +The  request  shall  be  made  each  time  a  HFP  Service  Level  Connection  is  established  with  the +device. +5.1.1.1.2  Advanced  Audio  Distribution  Profile  (A2DP) +The  Telephony  system  shall  implement  Advanced  Audio  Distribution  Profile  as  per  the  A2DP +specification  version  1.2  or  later. +Page  82  of  159 + + > **No.** > **Codec** > **Support** > **AGL** + ----------- ------------------- --------------- ----------- + > 1 > SBC > Mandatory > x + > 2 > MPEG-1,2  Audio > Option > - + > 3 > MPEG-2,4  AAC > Option > - + > 4 > ATRAC  family > Option > - + + > **No.** > **Feature** > **Support  in  SNK** > **AGL** + ----------- -------------------- ------------------------ ----------- + > 1 > Audio  Streaming > Mandatory > x + +![](media/picture192.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Telephony  system  shall  use  this  profile  for  audio  streaming.  This  profile  shall  be  use  to +realize  distribution  of  audio  content  of  high-quality  in  mono  or  stereo  on  ACL  channels. +It  shall  provide  following  roles: +Sink  (SNK)  -  A  device  is  the  SNK  when  it  acts  as  a  sink  of  a  digital  audio  stream  delivered  from +the  SRC  on  the  same  piconet. +Items  marked  with  "x"  in  AGL  column  in  Table  20  should  be  supported. +Decode  functions  of  codec  marked  with  "x"  in  AGL  column  in  Table  21  should  be  supported. +Copyright  protection  technology  SCMS-T  should  be  supported. +5.1.1.1.3  Phone  Book  Access  Profile +Page  83  of  159 +![](media/picture193.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Telephony  system  shall  implement  Phonebook  Access  Profile  as  per  the  PBAP  specification +version  1.1  or  later. +The  Telephony  system  shall  use  this  profile  to  allow  exchange  of  Phonebook  Objects  between +devices. +Phonebook  is  automatically  downloaded  into  the  system  from  mobile  device  for  browsing.  The +Telephony  system  shall  store  user's  Phonebook  and  the  Phonebook  details  of  the  connected +device  shall  be  available  to  the  user.  The  Telephony  system  shall  manage  the  contacts  by,  listing +and  copying  contact  information. +It  shall  provide  following  roles: +· Phonebook  Client  Equipment  (PCE) +It  shall  provide  following  types  of  Phonebook  objects: +· The  main  Phonebook  object +· The  Incoming  Call  History  object +· The  Outgoing  Call  History  object +· The  Missed  Call  History  object +· The  Combined  Call  History  object +A  Bluetooth  hands-free  system  must  download  the  phonebook  from  the  connected  BT  device +automatically  if  the  BT  device  has  provision  for  the  transfer  of  phonebook  data.  The  Phonebook +download  shall  be  performed  by  any  one  of  the  following  methods  listed  in  priority  of  usage: +· Using  PBAP  profile +All  the  BT  device's  phonebook  entries  must  be  transferred  -  those  on  any  external  memory  (E.g. +SIM)  and  also  any  stored  in  the  BT  device's  memory. +The  number  type  data  (if  stored  with  the  contact)  shall  also  be  transferred  and  stored  in  the +vehicle  phonebook.  The  Phonebook  shall  be  associated  to  only  the  BT  device  it  was  downloaded +from. +5.1.1.1.4  Dial  Up  Networking  (DUN)  Profile +Dial-Up  Networking  Profile  (DUN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +Page  84  of  159 + + > **No.** > **Service** > **Support  in  DT** > **AGL** + ----------- ------------------------------------------- ----------------------- ----------- + > 1 > Data  call  without  audio  feedback > Mandatory > x + > 2 > Data  call  with  audio  feedback > Option > - + > 3 > Fax  services  without  audio  feedback > N/A > - + > 4 > Fax  services  with  audio  feedback > N/A > - + > 5 > Voice  call > N/A > - + > 6 > Incoming  calls > Option > x + > 7 > Outgoing  calls > Mandatory > x + +![](media/picture194.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  has  to  comply  with  the  specification  for  “Data  Terminal  (DT)” +Items  marked  with  "x"  in  AGL  column  in  Table  23  should  be  supported. +5.1.1.1.5  Object  Push  Profile  (OPP) +Object  Push  Profile  (OPP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary  lower +layers. +It  has  to  comply  with  the  specification  for  “Push  Server”. +Items  marked  with  "x"  in  AGL  column  in  Table  24  should  be  supported. +**Table  24  :  List  of  OPP  Push  Server  Supporting  Functions** +Page  85  of  159 + + > **No.** > **Feature** > **Support  in  CT** > **AGL** + ----------- -------------------------------------------- ----------------------- ----------- + > 1 > Connection  establishment  for  control > Mandatory > x + > 2 > Release  connection  for  control > Mandatory > x + > 3 > Connection  establishment  for  browsing > C6 > x + + ------------------------------------------------------------------------------------- + > **No** > **Feature** > **Support  in  Push  Server** > **AGL** + > + > **.** + ---------- ---------------------------- --------------------------------- ----------- + > 1 > Object  Push > Mandatory > x + + > 2 > Business  Card  Pull > Option > - + + > 3 > Business  Card  Exchange > Option > - + ------------------------------------------------------------------------------------- + +![](media/picture195.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.6  Audio/Video  Remote  Control  Profile  (AVRCP) +The  System  shall  implement  Audio  /  Video  Remote  Control  Profile  version  1.6. +The  system  shall  use  this  profile  for  audio  streaming  control  for  each  connected  media  device +plus  one  remote  control.. +The  system  must  comply  with  the  specification  for  Controller  (CT)  items  marked  with  "x"  in  AGL +column  in  Table  25  should  be  supported. +C2:  Mandatory  if  device  supports  Metadata  Attributes  for  Current  Media  Item  or  optional +otherwise +C3:  Mandatory  to  support  at  least  one  Category +C4:  Mandatory  if  Category  2  supported,  excluded  otherwise +C6:  Mandatory  if  Browsing  (item  18)  is  supported,  optional  otherwise +EX:  Excluded +Page  86  of  159 +![](media/picture196.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +4 Release  connection  for  browsing C6 x +5 AV/C  Info  commands Option x +6 Category  1:  Player/Recorder C3 x +7 Category  2:  Monitor/Amplifier C3 - +8 Category  3:  Tuner C3 - +9 Category  4:  Menu C3 - +10 Capabilities Option x +11 Player  Application  Settings Option x +12 Metadata  Attributes  for  Current  Media  Item Option x +13 Notifications C2 x +14 Continuation C2 x +15 Basic  Group  Navigation Option x +16 Absolute  Volume C4 - +17 Media  Player  Selection Option x +17.1 -  Supports  Multiple  Players Option x +18 Browsing Option x +18.1 -  Database  Aware  Players Option x +19 Search Option - +20 Now  Playing C6 x +20.1 -  Playable  Folders Option x +21 Error  Response EX - +22 PASSTHROUGH  operation  supporting  press  and Option x +Page  87  of  159 + + ------------------------------------------------------------------------------ + > **No** > **Feature** > **Support  by  the  MCE** > **AGL** + > + > **.** + ---------- ------------------------- ----------------------------- ----------- + > 1 > Message  Notification > C1 > x + + > 2 > Message  Browsing > C1 > x + + > 3 > Message  Uploading > Option > x + + > 4 > Message  Delete > Option > - + + > 5 > Notification > C2 > x + > + > Registration + ------------------------------------------------------------------------------ + +![](media/picture197.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +hold +The  AVRCP  profile  realisation  shall  implement  an  Inform  Battery  Status  of  CT  parameter  and +pass  this  information  up  to  so  it  can  be  passed  to  the  User. +5.1.1.1.7  Message  Access  Profile +Message  Access  Profile  (MAP)  has  to  be  supported  as  well  as  Profiles/Protocols  for  necessary +lower  layers. +It  has  to  comply  with  the  specification  for  “Message  Client  Equipment  (MCE)”. +Items  marked  with  "x"  in  AGL  column  in  Table  26  should  be  supported. +C1:  The  MCE  to  support  at  least  one  of  the  C1-labelled  features +C2:  The  MCE  shall  support  Message  Notification  Registration  if  it  supports  Message +Notification.  Not  applicable  otherwise. +Page  88  of  159 + + > **No.** > **Feature** > **Support  in  PANU** > **AGL** + ----------- ------------------------------------------ ------------------------- ----------- + > 1 > Initialization  of  NAP/GN  service > - > - + > 2 > Shutdown  of  NAP/GN  service > - > - + > 3 > Establish  NAP/GN  service  Connection > Mandatory > x + +![](media/picture198.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.8  Serial  Port  Profile  (SPP) +The  Telephony  system  shall  implement  Serial  Port  Profile  as  per  the  SPP  specification  version +1.1  or  later. +It  shall  provide  following  roles: +Initiator  -  This  is  the  device  that  takes  initiative  to  form  a  connection  to  another  device. +Acceptor  -  This  is  the  device  that  waits  for  another  device  to  take  initiative  to  connect. +Following  features  shall  be  provided  by  the  Supplier: +Establish  link  and  setup  virtual  serial  connection +Accept  link  and  establish  virtual  serial  connection +Register  Service  record  for  application  in  local  SDP  database +5.1.1.1.9  Personal  Area  Network  (PAN)  Profile +Personal  Area  Network  Profile  (PAN)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +It  has  to  comply  with  the  specification  for  “PAN  User  (PANU)”. +Items  marked  with  "x"  in  AGL  column  in  Table  27  should  be  supported. +Page  89  of  159 + + > 4 > Lost  NAP/GN  Service  Connection > Mandatory > x + ----- ------------------------------------------- ------------- ----- + > 5 > Disconnect  NAP/GN  Service  Connection > Mandatory > x + > 6 > Management  Information  Base  (MIB) > - > - + +![](media/picture199.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.10  Service  Discovery  Profile  (SDP) +The  Telephony  system  shall  implement  Service  Discovery  Application  Profile  as  per  the  SDAP +specification  version  1.1. +The  Telephony  system  shall  use  this  profile  to  locate  services  that  are  available  on  or  via  devices +in  the  vicinity  of  a  Bluetooth  enabled  device. +It  shall  provide  following  roles: +Local  Device  -  A  device  that  initiates  the  service  discovery  procedure. +Remote  Devices(S)  -  A  device  that  participates  in  the  service  discovery  process  by  responding  to +the  service  inquiries  generated  by  Local  Device. +The  following  features  shall  be  provided  by  the  Supplier: +Search  for  services  by  service  class +Search  for  services  by  service  attributes +Service  browsing +5.1.1.1.11  Device  Information  Profile +Device  Identification  Profile  (DIP)  has  to  be  supported  as  well  as  Profiles/Protocols  for +necessary  lower  layers. +Items  marked  with  "x"  in  AGL  column  in  Table  28  should  be  supported. +**Table  28  :  List  of  DIP  Supporting  Functions** +Page  90  of  159 + + > **No.** > **Feature** > **Support** > **AGL** + ----------- ----------------------- --------------- ----------- + > 1 > SpecificationID > Mandatory > x + > 2 > VendorID > Mandatory > x + > 3 > ProductID > Mandatory > x + > 4 > Version > Mandatory > x + > 5 > PrimaryRecord > Mandatory > x + > 6 > VendorIDSource > Mandatory > x + > 7 > ClientExecutableURL > - > - + > 8 > ServiceDescription > - > - + > 9 > DocumentationURL > - > - + +![](media/picture200.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.1.1.12  Bluetooth  Smart  Ready +Bluetooth  Smart  Ready  shall  be  supported. +It  shall  comply  with  Bluetooth  Low  Energy  standard. +5.1.1.1.13  Generic  Object  Exchange  Profile  (GOEP) +The  Telephony  system  shall  implement  Generic  Object  Exchange  Profile  as  per  the  GOEX +specification  version  2.0  or  later. +The  Telephony  system  shall  use  this  profile  to  facilitate  the  exchange  of  binary  objects  between +devices.  The  usage  model  shall  be  Synchronization,  File  Transfer  or  Object  Push  model. +It  shall  provide  following  roles: +Server  -  This  is  the  device  that  provides  an  object  exchange  server  to  and  from  which  data +objects  shall  be  pushed  and  pulled,  respectively. +Page  91  of  159 +![](media/picture201.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Client  -  This  is  the  device  that  can  push  or/and  pull  data  object(s)  to  and  from  the  Server. +The  following  features  shall  be  provided  by  the  Supplier: +Establishing  an  object  connection +Pushing  a  data  object +Pulling  a  data  object +Performing  an  action  on  data  objects +Creating  and  managing  a  Reliable  Object  Exchange  Connection +5.1.1.1.14  Generic  Audio/Video  Distribution  Profile +The  Telephony  system  shall  implement  Generic  Audio/Video  Distribution  Profile  as  per  the +GAVDP  specification  version  1.2  or  later. +The  Telephony  system  shall  use  this  profile  to  specify  signalling  transaction  procedures  between +two  devices  to  set  up,  terminate,  and  reconfigure  streaming  channels. +It  shall  provide  following  roles: +Initiator  (INT) +Acceptor  (ACP) +Following  are  the  feature  requirements  for  this  profile: +Connection +Transfer  Control +Signalling  Control +Security  Control +Note:  This  profile  is  currently  being  enhanced  to  version  1.3.  Release  date  of  this  version  is  not +yet  finalized.  The  Telephony  system  shall  be  able  to  upgrade  to  the  newer  version  in  the  future. +5.1.1.1.15  Bluetooth  Diagnostics +**5.1.2  Error  Management** +The  Error  Management  module  provides  platform  error  handling  mechanisms.  This  includes +Page  92  of  159 +![](media/picture202.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +detecting  system  errors  that  occur  after  start  up  to  provide  a  recovery  function  by  localized +restart.  In  addition, +in  case  of  a  broad  ranged  malfunction,  Error  Management  provide  quick  detection  and  recovery +to  issue  in  a  short  amount  of  time. +**5.1.2.1  Use  Cases** +5.1.2.1.1  System  Surveillance  and  Recovery +While  using  in-car  information  device,  if  the  whole  system  or  part  of  the  function  stops,  an +immediate  error  detection  and  automatic  recovery  will  be  needed.  For  example,  when  updating +the  screen  while  route  guidance  is  on  or  voice  recognition  cannot  be  used,  restart  the  function  to +try  and  recover.  When  an  error  occurs  in  the  core  of  a  system  such  as  an  output  communicating +middle  ware,  reboot  the  whole  system  to  try  and  recover. +There  are  several  supposed  cases  for  system  surveillance  such  as  a  case  where  the  system  that +adopted  AGL  and  monitors  by  itself  or  monitored  by  the  system  that  has  not  adopted  AGL.  The +AGL  Error  Management  scope  includes  parts  of  the  system  that  adopted  AGL. +The  way  of  recovery  has  to  be  assessed  by  the  status  of  the  system  behavior.  For  example,  even +if  the  way  to  recover  the  car  navigation  error  might  be  reboot,  the  system  reboot  should  not  be +done  when  the  car  navigation  is  displaying  back  camera  image.  Because  of  these  use  cases,  Error +Management  should  focus  on  the  degree  of  importance  for  surveillance  list  process  and  the +degree  should  be  adjusted  by  its  behavior  status. +5.1.2.1.2  Collecting  Information +For  when  the  system  failure  occurred  after  the  launch,  the  most  urgent  item  is  a  prompt +recovery  but  what  is  also  a  point  that  is  worth  noting  is  to  collect  the  information  to  specify  the +cause  for  its  failure.  Therefore,  gathering  information  with  the  minimum  recovery  time  is  needed. +With  Linux  system,  memory  image  dump  (core  dump)  of  generally  abended  process  is  used.  On +the  other  hand,  a  scale  of  middleware  which  is  an  in-  car  application  is  increasing  and  has  come +Page  93  of  159 +![](media/picture203.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  the  point  where  the  time  to  dump  the  entire  memory  image  is  impermissible.  To  avoid  this, +the  Error  Management  function  will  provide  the  system  to  leave  the  light  log. +**5.1.2.2  Requirements** +Prevent  the  system  failure  shutoff  and  also  in  case  of  failure  provided  the  function  that  judge  its +status  automatically  and  recover +The  Error  Management  module  should  support  both  surveillance  of  the  whole  system  and  each +process. +The  Error  Management  module  should  monitor  the  memory  usage  of  whole  system  cyclically. +When  memory  usage  exceeds  set  threshold  value,  a  set  action  should  be  done.  Cycle,  threshold +value,  action  is  changeable  by  AGL  user. +Kernel  function  that  requires  Error  Management  surveillance,  driver  has  to  send  a  notification +to  Error  Management  when  an  error  occurs.  The  subjects  that  sends  error  notifications  are +output  communication  or  disk  I/O. +Error  Management  should  be  able  to  execute  the  action  after  obtaining  the  error  notification +by  kernel  function  and  the  driver.  Action  should  be  changeable  by  AGL  user.  For  example,  an +error  for  CAN  communication  is  critical  so  system  restart  could  be  done  but  USB  communication +error  can  be  ignored  since  it  may  be  caused  by  a  compatibility  issue  between  devices. +Error  Management  should  monitor  processes  for  existence  or  non-existence,  when  abended  it +should  execute  a  set  action.  The  set  action  should  be  changeable  by  the  AGL  user.  Termination +of  resident  process  is  a  defect  but  termination  of  a  temporal  behaving  process  is  correct  so +those  two  should  be  able  to  set  separately. +Error  Management  should  monitor  the  process  with  a  set  cycle  and  when  it  goes  over  threshold +value,  should  be  able  to  execute  the  set  action.  Cycle,  threshold  value,  action  should  be +changeable  by  AGL  user.  The  subjects  of  surveillance  are  CPU  usage  and  memory  usage. +Should  be  able  to  vanish  process  forcibly  including  subsidiary  process +Page  94  of  159 +![](media/picture204.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Make  the  software  that  works  by  system  have  the  concept  of  level  importance. +Appropriate  recovery  depending  on  the  level  of  importance.  The  level  of  importance  should  be +adjustable  depending  on  the  status  of  operation  by  coordinating  with  Policy. +The  process  that  detecting  an  external  communication  error  within  the  Error  Management +module  and  recovering  has  to  be  set  to  complete  before  external  monitoring  detects. +The  application  that  is  monitored  by  the  Error  Management  modulehas  to  be  independent  as +more  than  one  process. +The  application  that  is  monitored  by  the  Error  Management  moduleshould  not  combine  multiple +applications  to  one  process.  Application’s  runtime  part  does  not  have  the  structure  where +multiple  applications  can  be  moved  by  the  same  process. +Service  providing  side  has  to  be  nondense  to  the  application.  For  example,  the  Service  providing +process  such  as  a  software  keyboard  should  not  go  wrong  with  the  state  of  App.  Such  as +process  crash,  exit,  etc.. +An  application  has  to  be  nondense  to  an  application.  When  linking  two  application  one  ends +suddenly  the  other  will  not  become  abnormal  state. +The  process  that  communicates  with  the  external  system  has  to  be  independent  from  the  other +process  while  recovering  that  does  not  include  system  restart  so  that  it  can  notify  alive  towards +external  side. +When  the  software  that  is  under  the  surveillance  of  RAS  can  not  recover  with  one  restart +additional  process  can  be  done  such  as  deleting  the  subject  files  that  were  registered +beforehand. +The  system  has  to  have  a  structure  where  overwrite  the  files  that  are  stored  in  a  pinned  file +system  without  destroying  them. +Page  95  of  159 +![](media/picture205.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +When  system  down  occurs  (kernel  panic),  should  be  able  to  collect  the  information  need  for +analyzing. +When  making  the  system  down  happen  intentionally(  BUG\_ON  etc.),make  sure  to  leave  a +message  that  can  specify  the  cause. +Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +in  a  short  period  of  time  have  been  equipped  and  able  to  select. +In  any  abnormal  cases  log  output  does  not  lock  the  system  (stand  by  for  spin  lock  etc.)  or +system  down  does  not  occur  (self-destruction  on  log  output  process). +Should  be  able  to  leave  the  aberrance  occurred  in  kernel  area  on  the  log. +Should  be  able  to  select  the  level  of  log  output. +Should  be  able  to  record  the  aberrance  log  with  the  time  of  occurrence. +Should  be  able  to  obtain  the  information  linked  to  the  system  resources. +Should  be  able  to  leave  the  information  corresponding  to  core  dump  in  a  short  period  of  time. +Both  the  log  which  is  for  debug  and  can  take  time  to  output  and  the  log  that  leaves  minimum  log +in  a  short  period  of  time  have  been  equipped  and  able  to  select. +As  the  smallest  amount  of  information,  the  following  information  should  be  left. +· Register  information +· Process  logical  memory  map +· +Stack  dump  or  back  trace  from  the  exceptional  place  of  occurrence +· Time  of  occurrence +· +Information  that  can  specify  the  occurred  process  thread  (name  of  an  executing +file‑name  of  the  thread  etc.) +Page  96  of  159 +![](media/picture206.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· The  signal  that  occurred +Lightweight  core  dump  is  a  core  dump  that  can  set  the  restrictions  below. +· +Select  the  memory  mapping  category  of  process  executing  memory  image  that  targeted +for  an  output. +· +Specify  the  order  of  an  output  and  output  high-priority  memory  mapping  first  to  prevent +dropping  the  information  needed. +· +Output  only  the  memory  mapping  that  is  linked  to  the  abnormal  process  (text  area).  \[O\] +· +Compress  the  data  for  each  memory  mapping  category  and  output  up  to  the  fixed +maximum  size. +· +NOTE  information  of  ELF  header  and  program  header  will  not  change. +Selectable  memory  mappings  are  the  following. +· anonymous  private  mappings +· anonymous  shared  mappings +· file-backed  private  mappings +· file-backed  shared  mappings +· private  huge  page +· shared  huge  page +Setting  parameters  of  the  output  context  are  the  following. +· +Memory  mapping  category  which  is  for  an  output  object  can  be  set. +· The  order  of  outputting  memory  mapping  can  be  set. +Should  be  able  to  leave  the  log  in  increments  of  process.  Possible  to  filter  and  have  a  look  in +increments  of  process. +Should  be  able  to  leave  a  trace  log  in  increments  of  process  during  process  crash.  Should  be +able  to  leave  a  trace  log  in  increments  of  process  during  system  running,  if  necessary. +Should  be  able  to  obtain  the  information  related  to  system  resource  of  process. +Page  97  of  159 +![](media/picture207.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +There  should  be  a  structure  to  be  able  to  error  trace  among  the  whole  process  in  a  user  space. +**5.1.3  Graphics** +Graphics  subsystem;  HMI  input,  wayland,  windowing,  etc. +**5.1.4  Location  Services** +Location  services  includes  support  for  GPS,  location,  and  positioning  services  including  dead +reckoning.  Time  of  day  support  is  also  included  in  Location  Services  since  time  is  a  primary +output  of  the  GPS  receiver. +**5.1.4.1  Position** +**5.1.4.2  Time  of  Day** +With  Linux,  time  adjusting  is  generally  done  by  using  date  command  or  NTP  but  since  in-car +device  can  obtain  the  accurate  time  from  GPS,  GPS  time  is  often  used  as  Abs  Time.  Because  of +its  advantage  where  this  GPS  demand  can  be  done  anywhere  in  the  world,  it  would  continue  in +future.  Therefore,  we  are  going  to  need  a  structure  for  adjusting  the  Linux  system  time. +**Monotonic  and  Absolute  Time  Support** +As  a  weak  point  of  GPS,  when  cold  start,  it  takes  a  long  time  to  obtain  the  accurate  time. +Because  of  this,  it  will  not  set  the  right  time  for  booting  the  system  and  will  adjust  it  while  it’s +moving.  As  for  in-car  device,  the  demand  to  make  the  system  boot  faster  is  rather  strong  and +Abs  Time  can  vary  while  it’s  working  for  one  of  the  middle  ware  applications. +On  the  other  hand,  although  POSIX  API  which  is  used  as  a  standard  for  Linux,  provides  the  time +that  has  not  been  effected  by  the  adjusting  in  case  of  a  simple  latency,  but  for  resource  latency, +some  of  them  can  only  set  with  Abs  Time.  Therefore,  in-car  Linux  needs  an  API  that  supports +Monotonic  Time. +**Kernel  Time  Precision** +Page  98  of  159 +![](media/picture208.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +In-car  device  needs  to  support  all  kinds  of  communicating  system  such  as  CAN.  Those +communicating  system  includes  the  device  that  needs  ms  order  procedure. +In  Linux  Kernel  space,  jiffies  are  used  as  mere  time.  However  1jiffies  time  differs  depending  on +the  CPU  architecture  and  the  architecture  differs  depending  on  SOC.  Because  of  this,  the  lowest +value  for  unit  of  time  that  AGL  environment  has  to  support  needs  to  be  decided. +**5.1.4.3  Requirements** +Should  be  able  to  adjust  the  system  time  from  GPS  middle  ware. +Adjust  the  system  time  after  the  time  is  determinate. +GPS  middle  ware  has  to  have  the  system  where  it  can  implement  GPS  driver  control  parts  using +the  plugin  (source  plugin).  Must  tolerate  proprietary  GPS  component. +GPS  middle  source  plugin  must  tolerate  proprietary.  Source  plugin  has  to  be  a  license  that  is  not +imposed  a  duty  to  open  source.  For  example,  header  library’s  license  that  is  needed  to  make +Source  plugin  can  not  be  GPL  or  LGPL. +When  waiting,  can  use  both  absolute  time  and  monotonic  time +Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +monotonic  time. +Resource  obtaining  time  out  such  as  mutex,  semaphore  can  use  both  absolute  time  and +monotonic  time. +System  time  must  be  able  to  use  consecutively  at  least  until  2099. +Absolute  time  has  to  support  leap  year  and  leap  seconds. +1  jiffies  have  to  be  smaller  than  1ms. +Page  99  of  159 +![](media/picture209.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Time  waiting  that  involve  context  switch,  must  be  done  with  the  accuracy  over  1ms. +From  timer  /  ISR,  can  boot  tasklet  with  the  accuracy  1ms. +A  system  has  to  be  able  to  handle  time  with  at  least  the  accuracy  1ms. +**5.1.5  Health  Monitoring** +Platform  monitoring  services  such  as  watchdog  or  active  monitoring +**5.1.6  IPC** +Standard  platform  interprocess  and  interprocessor  communication  mechanism. +**5.1.7  Lifecycle  Management** +Startup,  shutdown,  state  change,  etc. +**5.1.8  Network  Services** +Includes  standard  networking  protocols  such  as  TCP/IP  via  any  networking  physical  layer +including  Wifi,  Bluetooth,  or  ethernet. +**5.1.9  Persistent  Storage** +Power  safe  persistent  storage +**5.1.10  Power  Management** +Amount  of  ECUs  in  the  car  and  their  complexity  has  grown  dramatically  over  last  decade.  Needs +in  processing  power  are  constantly  growing  to  catch  up  with  demands  of  automotive  industry. +*This, in turn has impact on power budget and temperature/heat dissipation characteristic of* +Page  100  of  159 +![](media/picture210.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +modern  ECUs +In  parallel,  success  of  green,  electric  cars  is  pushing  power  budget  limits  down  as  never  before, +in  distant  future  we  may  see  “battle  for  watts”  in  automotive  electronics.  Finding  optimal +balance  between  performance  and  ECU  operating  modes,  frequencies,  voltages  is  also  important +for  overall  durability  characteristic. +Suspend/resume  techniques  and  retention  of  the  ECU  in  lower  power  states  now  becoming +more  welcomed  over  traditional  cold  boot  approaches. +Linux  community  has  been  working  on  power  management  architecture  for  many  years,  it  has +become  a  state  of  art  framework  and  set  of  components  that  addresses  needs  not  only +consumer  electronics  industry,  but  also  industrial  automation,  security,  etc.) +**5.1.10.1  Requirements** +AGL  kernel  shall  allow  switching  between  active  and  suspend  states.  Exact  definition  of  suspend +states  is  platform/architecture-specific  (e.g.  “suspend  to  memory”,  “suspend  to  disk” +/“hibernate”  correspond  to  S3  and  S4  in  ACPI  terminology) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  suspend/resume  transitions. +AGL  kernel  shall  provide  sufficient  APIs  for  application  to  control  active/suspend  state +transitions  and  receive  appropriate  events/notifications.  Kernel  should  not  initiate  power  state +transitions  if  no  requests  provided  from  applications. +Detailed  definition  of  steps/actions  required  for  suspend/resume  sequence  is  out  of  the  scope  of +this  specification  (it  is  also  platform-dependent). +AGL  kernel  for  SMP  configurations  shall  allow  enabling/disabling  of  individual  cores  (or  group  of +cores)  (NOTE:  on  some  platforms/architectures  enabling/disabling  may  be  achieved  by  putting +core  in  one  of  its  low  power  states) +AGL  kernel  shall  only  provide  mechanism  for  applications  to  request  enabling/disabling  particular +cores  from  SMP  group. +Page  101  of  159 +![](media/picture211.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  kernel  shall  support  CPU  frequency  and  voltage  scaling.  Exact  definition  of  operating  points +(table  of  frequencies/voltages  allowed  by  hardware)  is  platform/architecture-specific  (moreover, +some  of  operating  points  may  be  omitted/ignored  in  AGL  kernel  as  their  impact  on  power  budget +insignificant) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  by  CPU  frequency  and  voltage  scaling +Only  application-defined  policies  shall  be  allowed  for  CPU  frequency  and  voltage  scaling. +Default  in-kernel  governors/policies  (e.g.  on-demand  or  performance)  shall  not  be  used  and  they +may  have  negative  impact  on  overall  system  performance/predictability +AGL  kernel  shall  allow  switching  between  active  and  idle  states.  Exact  definition  of  idle  states  is +platform/architecture-specific  (e.g.  C0..C4  in  ACPI  terminology  or  WFI+…  for  ARM) +Kernel  and  peripheral  device  drivers  shall  not  be  affected  entering/leaving  one  of  idle  states +Only  application-defined  policies  shall  be  allowed  for  CPU  Idle +AGL  kernel  shall  support  run-time  power  management  of  I/O  (peripheral)  devices +AGL  kernel  shall  support  I/O  (peripheral)  device  voltage  and  frequency  scaling +**5.1.11  Resource  Management** +Resource  and  device  management. +Resource  Management  shall  provide  an  interface  to  be  used  for  informing  status  of  a  resource +request  by  the  Resource  Manager. +**5.1.12  Telephony  Services** +**5.1.12.1  Requirements** +Page  102  of  159 +![](media/picture212.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.12.1.1  Telephony  variants +Purpose:  To  define  the  variants  of  Telephony +Requirement: +There  will  be  2  variants  of  phone  system. +Variant  1:  Front  User  only  Telephony. +Variant  2:  Rear  and  Front  Telephony. +All  variants  will  have  Bluetooth  capability.  The  feature  will  be  configurable  so  that  the  feature +can  be  disabled  via  car  configuration. +**5.1.13  Wi-Fi** +This  Wi-Fi  subsystem  controls  registration,  connection  management,  and  device  information +management  between  a  wireless  LAN  device  and  infotainment  system. +Necessary  Wi-Fi  specification  in  automotive  use  case  is  defined  here. +**5.1.13.1  Use  Cases** +5.1.13.1.1  Construct  WiFi  Network +In-Vehicle  Infotainment  systems  constructs  3  types  of  Wi-Fi  networks. +a\. STA +In-Vehicle  Infotainment  system  acts  as  a  STA  (Station)  and  connects  to  an  external  network  via +an  Access  Point. +It  also  connects  to  Access  Points  which  support  Wi-Fi  Hotspot. +b\. AP +In-Vehicle  Infotainment  system  acts  as  an  AP  (Access  Point)  and  connects  multiple  Wi-Fi  devices +with  an  external  network. +Page  103  of  159 +![](media/picture213.jpeg)![](media/picture214.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  also  connects  Wi-Fi  devices  which  support  Wi-Fi  Hotspot. +c\. P2P +In-Vehicle  Infotainment  system  and  Wi-Fi  device  makes  P2P  (Peer  to  Peer)  connection  using  Wi- +Fi  Direct. +5.1.13.1.2  Miracast +In-Vehicle  Infotainment  system  and  Wi-Fi  device  shares  a  display  using  Miracast.-(a) +They  are  also  remotely  operated  to  a  Wi-Fi  device  from  the  infotainment  system,  or  vice  versa, +by  using  UIBC  (User  Interface  Back  Channel).-(b) +**Figure  8-29  :  Overview  of  Miracast** +a\. Shared  Displayed  Content +Page  104  of  159 +![](media/picture215.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Use  case  examples  of  shared  displayed  content  are: +· +A  passenger  on  the  passenger  seat  views  the  multimedia  content  played  on  Wi-Fi  Device +(e.g.  Mobile)  on  In-Vehicle  Infotainment  system. +· +A  rear  seat  passenger  views  the  multimedia  content  played  on  In-Vehicle  Infotainment +system  on  Wi-Fi  Device(e.g.  Rear  seat  monitor). +b\. Remote  Operation +Use  case  examples  of  remote  operation  are: +· +A  passenger  on  the  passenger  seat  plays  the  multimedia  content  stored  in  Wi-Fi  Device +(e.g.  Mobile)  by  operating  In-Vehicle  Infotainment  system. +· +A  passenger  on  the  rear  seat  controls  air  conditioner  functionality  in  In-Vehicle +Infotainment  system  by  operating  a  Wi-Fi  Device  (e.g.  Mobile). +· +While  the  vehicle  is  in  motion,  a  passenger  on  the  rear  seat  controls  the  navigation +functionality  in  a  passenger  on  the  rear  seat  controls  by  operating  a  Wi-Fi  Device(e.g. +Mobile). +5.1.13.1.3  DLNA +In-Vehicle  Infotainment  system  connects  with  a  DLNA  device  via  Wi-Fi. +**5.1.13.2  Requirements** +5.1.13.2.1  Security +The  WiFi  module  shall  support  security  standard  WEP. +It  shall  support  40  bit  WEP  encryption  method. +It  shall  support  104  bit  WEP  encryption  method. +It  shall  support  security  standard  WPA  Personal. +Page  105  of  159 +![](media/picture216.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA2  Personal. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA  Enterprise. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +It  shall  support  security  standard  WPA2  Enterprise. +It  shall  support  TKIP  encryption  method. +It  shall  support  CCMP  encryption  method. +5.1.13.2.2  Simple  Configuration +It  shall  comply  with  WPS  (Wi-Fi  Protected  Setup)  standard. +It  shall  be  able  to  perform  connection  with  PIN  (Personal  Identification  Number)  method. +It  shall  support  Configuration  Method  for  Display. +Page  106  of  159 +![](media/picture217.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  support  Configuration  Method  for  Keypad. +It  shall  be  able  to  perform  connection  with  PBC  (Push  button  configuration)  method. +It  shall  support  Configuration  Method  for  PushButton. +It  shall  be  able  to  perform  connection  with  NFC  (Near  Field  Communication)  method. +5.1.13.2.3  QoS +It  shall  comply  with  WMM  (Wi-Fi  Multimedia)  standard. +It  shall  comply  with  WMM-PS  (Wireless  Multimedia  Power  Save)  standard. +5.1.13.2.4  STA +The  In-Vehicle  system  shall  be  able  to  function  as  a  STA  (Non-AP  Station). +5.1.13.2.5  AP +The  In-Vehicle  system  shall  be  able  to  function  as  an  AP  (Access  Point). +5.1.13.2.6  WiFi  Direct +It  shall  comply  with  Wi-Fi  Direct  standard. +It  shall  support  the  WiFi  Direct  functions  as  listed  in  Table  29. +Page  107  of  159 + + -------------------------------------------------------------------------------------------------------------------- + > **No.** > **Feature** > **(Reference)** + > + > **Support  in  Wi-** + > + > **Fi  Direct** + ----------- ---------------------------------------------------- -------------------------- ------------------------ + > 1 > P2P  Provision > ‑ > Mandatory + > + > Discovery + + > 2 > P2P  Device  Discovery > Scan  Phase > Mandatory + + > 3 > ‑ > Find  Phase > Mandatory + + > 4 > P2P  GO  Negotiation > ‑ > Mandatory + + > 5 > P2P  Service  Discovery > ‑ > Option + + > 6 > P2P  Invitation > Temporary  P2P  Group > Option + + > 7 > ‑ > Persistent  P2P  Group > Option + + > 8 > Persistent  P2P  Group  /  Persistent  Reconnect > Option + + > 9 > Intra-BSS  Distribution > ‑ > Option + + > 10 > Concurrent  Operation > ‑ > Option + + > 11 > P2P  Service  Discovery > UPnP > Option + + > 12 > ‑ > Bonjour > Option + + > 13 > ‑ > Wi-Fi  Display > Option + + > 14 > ‑ > WS-Discovery > Option + + > 15 > ‑ > Vendor  specific > Option + -------------------------------------------------------------------------------------------------------------------- + +![](media/picture218.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.13.2.7  Miracast +Page  108  of  159 + + -------------------------------------------------------------------------------------------------------------- + > ‑**No.** > **Feature** > ‑ > **(Refere** + > + > **nce)** + > + > **Suppor** + > + > **t        in** + > + > **Miracas** + > + > **t** + ------------ ----------------------------------------------------- ----------------------- ------------------- + > 1 > WFD  Device  type > WFD  Source > Mandat + > + > ory + + > 2 > ‑ > Primary  Sink > Mandat + > + > ory + + > 3 > ‑ > Dual-role  possible > Option + + > 4 > WFD  Service > ‑ > Option + > + > Discovery + + > 5 > WFD  connection  establishment  with  Wi-Fi  P2P > Mandat + > + > ory + + > 6 > WFD  connection  establishment  with  Wi-Fi  TDLS > Option + + > 7 > Persistent  WFD > via  Wi-Fi  P2P > Option + > + > Group + + > 8 > ‑ > via  TDLS > Option + + > 9 > WFD  Capability  Negotiation  (RTSP) > Mandat + > + > ory + + > 10 > WFD  Session  Establishment  (RTSP) > Mandat + > + > ory + -------------------------------------------------------------------------------------------------------------- + +![](media/picture219.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  comply  with  Miracast  standard. +It  shall  support  the  Miracast  functions  identified  in  Table  30. +Page  109  of  159 + + --------------------------------------------------------------------------------- + > 11 > AV  Streaming  and  Control  (MPEG-TS/RTP/RTSP) > Mandat + > + > ory + ------ --------------------------------------------------- ----------- ---------- + > 12 > WFD  Standby  (RTP/RTSP) > Option + + > 13 > Video  CODEC  formats > Option + + > 14 > Audio  CODEC  formats > Option + + > 15 > UIBC > Generic + + > 16 > HIDC + --------------------------------------------------------------------------------- + +![](media/picture220.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.1.13.2.8  WiFi  Hotspot +It  shall  comply  with  Wi-Fi  Hotspot  standard. +In-Vehicle  system  which  acts  as  an  a  STA(Non-AP  Station)shall  be  able  to  connect  with  Hotspot +service. +In-Vehicle  system  which  acts  as  an  AP  (Access  Point)  shall  be  able  to  provide  Hotspot  service. +5.1.13.2.9  DLNA  via  WiFi +The  In-Vehicle  system  shall  be  able  to  connect  with  DLNA  devices  via  Wi-Fi. +**5.1.14  Window  System** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +and  a  routing  of  user  interactions. +Page  110  of  159 +![](media/picture221.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.2  Automotive  Services +Automotive  Services  Layer  contains  services  that  are  not  found  in  a  typical  Linux  distribution  but +contains  services  specialized  for  automotive  applications. +**5.2.1  Audio  Services** +BTBF,  equilization,  mult-zone  audio  control,  etc. +**5.2.2  Camera  Services** +Standard  interface  to  vehicle  mounted  cameras;  backup  camera,  side  and  front  cameras,  etc. +**5.2.3  Configuration  Services** +Service  for  storing  configuration  parameters. +**5.2.4  Diagnostic  Services** +Diagnostic  services. +(This  is  automotive  diagnostics  such  as  storing  and  retrieving  DTC.  ) +**5.2.5  Multimedia  Services** +CD,  DVD,  Blu-Ray,  MP3,  etc. +(Factor  out  metadata  into  separate  component.) +**5.2.5.1  Media  Player** +In-vehicle  multimedia  system  shall  provide  rich  and  robust  user-experience  that  includes  not  just +Page  111  of  159 +![](media/picture222.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +support  of  multiple  audio-video  formats,  but  also  variety  of  input  and  output  audio/video +devices,  both  static  and  dynamically  pluggable.  In  contrast  to  mobile  or  desktop  applications, +there  is  normally  more  than  one  consumer  of  multimedia  content  in  a  car,  with  front-  and  rear- +seat  passengers  as  well  as  driver  all  having  independent  requirements. +The  following  requirements  are  considered  essential  for  in-vehicle  multimedia  system: +· +Supported  multimedia  formats  shall  correspond  to  major  end-user  expectations,  i.e.  the +ones  encountered  in  mobile  and  desktop  world. +· +Multiple  audio  /  video  sources  and  sinks,  both  static  (i.e.  always  existing  in  the  system) +and  dynamic  (i.e.  appearing  and  disappearing  when  user  connects  a  Bluetooth  headset  or +establishes  a  network  connection.) +· +Multiple  independent  consumers  of  multimedia  data  and  globally  configurable  routing  of +audio  /  video  processing  chains. +Latency  requirements  of  audio/video  processing  may  also  vary  depending  on  a  type  of  the  data +processed;  e.g.  data  from  rear-view  camera  shall  be  decoded  and  visualized  “instantly”  in +comparison  to  a  movie  clip  displayed  on  rear-passenger  monitor,  voice  notification  from +navigation  software  shall  not  be  delayed  significantly,  speech  data  passed  to  and  from +Bluetooth  headset  during  phone  conversation  shall  have  reasonably  bounded  latencies  and  so +on. +It  is  considered  that  multimedia  system  may  consist  of  multiple  processing  units,  and  therefore +processing  load  balancing  mechanism  shall  be  present.  Mechanisms  of  audio/video  processing +offloading  to  dedicated  processing  units  (hardware  acceleration)  shall  be  provisioned,  with +particular  implementation  freedom  left  for  a  silicon  vendor. +The  following  requirements  formalize  these  considerations. +**5.2.5.2  Requirements** +5.2.5.2.1  Media  Containers +AGL  shall  provide  an  API  that  allows  handling  of  various  media  data  within  the  system.  This +includes  audio/video  playback  and  recording  as  well  as  media  streaming  over  the  network.  It +shall  be  possible  to  run  multiple  media  streams  in  parallel  for  all  IVI  users,  with  configurable +input/output  devices  routing.  Multimedia  framework  does  not  necessarily  need  to  be  isolated +from  application  (that  is,  it  may  run  in  the  same  address  space  as  application),  however  it  shall +be  guaranteed  that  independent  applications  using  the  framework  are  isolated  from  each  other. +Page  112  of  159 +![](media/picture223.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  shall  provide  support  for  extraction  from  media  containers  streams  other  than  audio-visual, +for  example  subtitles.  Application  shall  be  able  to  retrieve  timing  information  as  well  as  stream +identification  data  from  media  container. +AGL  shall  provide  support  for  major  network  streaming  protocols  such  as: +· HTTP +· RTPS +· Digital  Radio  (DAB) +· DigitalTV  (DVB-T)  etc. +It  shall  be  possible  to  extend  the  set  of  supported  streaming  protocols  in  accordance  with +system  requirements. +AGL  shall  provide  a  mechanism  to  utilize  available  hardware  accelerators  to  offload +computationally  extensive  processing  to  specialized  units  in  vendor-specific  way.  Such +extension,  if  available,  shall  be  transparent  to  the  applications. +Lip  Synch  must  be  implemented  as  plug-in  software  for  Multimedia  Framework. +AGL  shall  provide  a  mechanism  to  automatically  detect  type  of  media  data  contained  in  the +source  file,  and  to  instantiate  all  required  components  to  organize  data  processing  without +intervention  of  the  application.  It  shall  be,  however,  possible  for  application  to  control  this +process  if  it  is  essential  for  its  functionality.  Example  of  such  intervention  would  be  selection  of +particular  audio  track  (in  user-chosen  language)  or  selection  of  particular  video  stream  from +multiple  choices. +AGL  shall  provide  an  API  to  control  execution  of  audio/video  processing  chain,  specifically  shall +support  the  following  functionality: +· +Selection  of  data  source  and  destination  (files,  devices,  network  resources) +· Pausing/resuming  of  multimedia  streams +· Rewinding  in  forward  and  reverse  directions  (for  playback) +· Audio  volume  control  on  per-stream  basis +· Retrieval  of  current  stream  position  (timestamp) +Page  113  of  159 +![](media/picture224.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +Notifications  on  error  conditions  preventing  multimedia  stream  processing +AGL  shall  provide  a  mechanism  to  specify  routing  of  input  and  output  devices  that  are  involved +into  multimedia  data  processing.  In  particular,  for  playback  scenario  it  shall  be  possible  to +specify  where  audio  and  video  data  is  rendered,  and  for  recording  scenario  it  shall  be  possible  to +specify  capturing  source.  It  shall  be  possible  to  organize  broadcasting  of  decoded  raw +audio/video  streams  to  multiple  renderers  as  well. +AGL  shall  include  a  dedicated  sound  server  that  simplifies  routing,  mixing,  post-processing  and +synchronization  of  raw  PCM  audio  streams.  Specifically,  the  following  functionality  is  expected: +· +Support  for  multiple  audio  sources  and  audio  sinks  with  arbitrary  (configurable)  routing. +· Per-stream  volume  and  audio  effects  control. +· +Resampling  and  format  conversion  (e.g.  channels  downmixing,  sample  width  conversion). +· +Sample-accurate  streams  synchronization  (e.g.  for  echo-cancellation  purpose). +· Mixing  and  broadcasting  of  the  audio  streams. +AGL  shall  provide  a  mechanism  to  control  sound  server  configuration  in  run-time,  that  is,  to +specify  the  rules  and  policies  defining  system  response  to  external  events  like  adding  or +removing  of  new  audio  device  (e.g.  Bluetooth  headset  connection),  receiving  of  the  phone  call, +emergency  system  alarm  output  and  so  on. +AGL  shall  provide  support  for  major  multimedia  containers,  such  as: +· MPEG2-TS/PS  (ISO/IEC  13818-1) +· MP4  (MPEG-4  Part  14,  ISO/IEC  14496-14:2003) +It  shall  be  possible  to  extend  the  set  of  supported  multimedia  formats  in  accordance  with +system  requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  optional  multimedia  containers  such  as: +· OGG  (RFC  3533) +· 3GPP  (ISO/IEC  14496-12) +· etc +Page  114  of  159 +![](media/picture225.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +5.2.5.2.2  Media  Audio  Codecs +AGL  shall  provide  support  for  major  audio  codecs,  such  as: +· +MP3  (MPEG-1/2  Audio  Layer-3,  ISO/IEC  11172-3,  ISO/IEC  13818-3) +· AAC  (ISO/IEC  13818-7,  ISO/IEC  14496-3) +It  shall  be  possible  to  extend  the  set  of  supported  audio  codecs  in  accordance  with  system +requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  audio  codecs,  such  as: +· VORBIS  (http://xiph.org/vorbis/) +· Windows  Media  Audio +· etc. +5.2.5.2.3  Media  Video  Codecs +AGL  shall  provide  support  for  major  video  codecs,  such  as: +· MPEG-2  (ISO/IEC  13818-2) +· MPEG-4  Part  2  (ISO/IEC  14496-2) +· H.264  (MPEG-4  Part10,  ISO/IEC  14496-10,  ITU-T  H.264) +It  shall  be  possible  to  extend  the  set  of  supported  video  codecs  in  accordance  with  system +requirements. +It  must  be  possible  to  extend  AGL  to  support  additional  video  codecs,  such  as: +· Theora  (www.theora.org) +· Windows  Media  Video +· etc +5.2.5.2.4  Image  File  Formats +Page  115  of  159 +![](media/picture226.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  BMP,  up  to  32  bit  true +colour. +Compression  formats +· RLE  8  bits/pixel +· RLE  4  bits/pixel +· Bit  field  or  Huffman  1D  compression +· JPEG  or  RLE-24 +· PNG +The  system  shall  be  able  to  perform  all  required  operations  on  Viewing  of  Image  in  JPEG/JPEG  2000 +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  JPEG  XR/HD,  including +Exchangeable  Image  File  Format  (EXIF)  format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  Viewing  of  Image  in  PNG, +including  transparency +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  of  Image  in  GIF  87a  and  enhanced +version  89a  and  also  animation  in  GIFF  images. +The  system  shall  be  able  to  perform  all  required  operations  on  viewing  images  in  TIFF  format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +format. +The  system  shall  implement  the  ability  to  perform  all  required  operations  on  viewing  of  Image  in  WBMP +format. +**5.2.6  Navigation  Services** +Navigation  engine +Page  116  of  159 +![](media/picture227.jpeg)![](media/picture228.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.7  PIM** +Personal  Information  Manager;  calendar,  appointments,  reminders,  etc. +**5.2.8  Smartphone  Link** +This  section  describes  regarding  Smartphone  link.  Smartphone  Link  is  the  technology  which +realizes  that  video  and  audio  streaming  play  which  data  from  smartphone.  And  touch  operation +is  possible  to  share  between  IVI  and  smartphone.  MirrorLink,  Miracast,  SmartDeviceLink  and +AirPlay  are  technologies  that  realize  Smartphone  Link.  By  this  technology,  it  is  possible  to  use +smartphone  content  (map,  music,  browser...)  by  IVI. +Figure   8-30   shows   the   system   structure   of   the   Smartphone   Link. +**Figure:  8-30** +Page  117  of  159 +![](media/picture229.jpeg)![](media/picture230.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  defines  following  requirements  of  Smartphone  link. +1.  The  screen  of  smartphone  shall  be  mirrored  to  IVI. +2.  The  sound  of  smartphone  shall  be  linked  to  IVI. +3.  The  sound  shall  be  synchronized  with  the  screen. +4.  IVI  should  operate  smartphone. +5.  The  response  time  of  operations  from  IVI  should  be  less  than  200ms. +6.  If  connection  between  smart  phone  and  ivi  was  disconnected  by  external  factor,  then  should +inform  the  "disconnection"  to  a  user  and  return  to  the  normal  state. +This  document  describes  “Miracast”  and  “SmartDeviceLink”  from  the  reference  of  Smartphone +link. +**5.2.8.1  Miracast** +This  section  describes  requirements  regarding  Smartphone  link  (Miracast). +Miracast  is  the  display  transfer  technology  using  wireless  connection  which  was  defined  by  Wi- +Fi  Alliance.  Send  screen  data  from  source  device  to  sink  device  and  it  realize  display  sharing +between  source  device  and  sink  device. +Following  figure  (Figure:  8‑31)  shows  the  system  structure  of  Miracast. +**Figure:  8-31** +Page  118  of  159 + + ---------------------------------------------------------------------------------------------- + > **No** > **Requires** > **Description** + ------------ ----------------------------- --------------------------------------------------- + > SPL.1.1 > WFD  Topology > Define  role  of  Miracast + + > SPL.1.2 > Connection  Topology > Define  connection  condition  between + > + > a  smartphone  and  an  IVI + + > SPL.1.2. > P2P  Topology > Define  connection  method  of  P2P  (Wi-Fi + > > + > 1 > Direct). + + > SPL.1.2. > Wi-Fi  Frequency > Define  Wi-Fi  frequency + > + > 2 + + > SPL.1.3 > Video  Format > Define  Video  format + + > SPL.1.4 > Audio  Format > Define  Audio  format + + > SPL.1.5 > Session  Control > Define  Miracast  session  state + + > SPL.1.6 > Link  Content  Protection > Define  content  protection  function  required + > + > for  implementing  Miracast + + > SPL.1.7 > Resource  Management > Define  resource  management + ---------------------------------------------------------------------------------------------- + +![](media/picture231.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Follow  reference  documents  to  support  Miracast  if  there  was  no  description  of  this  section. +**References** +\[1\]  Wi-Fi  Display  Technical  Specification  Version  1.0.0 +\[2\]  W-Fi  Peer-to-Peer  (P2P)  Technical  Specification  Version  1.2 +\[3\]  High-bandwidth  Digital  Content  Protection  System  Interface  Independent  Adaption  Revision +2.2 +\[4\]  DCP  (Digital  Content  Protection)   +AGL  provide  display  sharing  technology  between  Smartphone  and  IVI  system  using  Miracast. +Page  119  of  159 +![](media/picture233.jpeg)![](media/picture234.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +SPL.1.8 Fail-safe  Control Define  Fail-safe  control +**Table  8-14:  Smartphone  Link  (Miracast)  Requirements** +**Figure:  8-32  State  Change  Diagram** +The  states  of  Smartphone  link  (Miracast)  is  defined  in  Table  8-32. +Page  120  of  159 + + ------------------------------------------------------------------------------------------------------- + > **No.** > **State** > **Description** + ----------- ------------------------- ----------------------------------------------------------------- + > 1 > Idle > Smartphone  link  (Miracast)  function  is  not  initialized. + + > 2 > Initialized > Smartphone  link  (Miracast)  function  is  initialized  and + > + > waiting  for  Wi-Fi  P2P  connection  from  source + > + > device. + + > 3 > Connected  Wi-Fi  P2P > Established  Wi-Fi  P2P  connection  with  source + > + > device. + + > 4 > Initiated > Smartphone  link  (Miracast)  session  is  established. + + > 5 > Play > Streaming  the  audio  and  video  content  from  source + > + > device  to  sink  device. + + > 6 > Pause > Paused  the  streaming  of  audio  and  video  content + > + > from  source  divide  to  sink  device. + ------------------------------------------------------------------------------------------------------- + +![](media/picture235.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.8.2  Smart  Device  Link** +“Smart  Device  Link”,  aka  “SDL”,  is  template  based  approach  of  smartphone  link  capability. +Application  itself  is  in  a  mobile  phone,  however,  HMI  is  provided  by  IVI  system.  This  approach +makes  it  possible  to  apply  IVI  adapted  user  experience,  such  as  larger  button  to  prevent  driver’s +distraction  and  voice  recognition. +That  means,  application  requests  to  IVI  system,  then  IVI  system  will  respond  by  using  remote +procedure  calls.  Application’s  HMI  will  be  rendered  by  IVI  system  by  using  IVI’s  HMI  framework +and/or  policy,  though  all  the  application’s  logic  is  contained  in  mobile  phone. +SDL  provides  more  suitable  HMI  for  IVI  rather  than  mirroring  type  approach,  however,  mobile +phone’s  application  must  support  SDL  capability.  In  other  words,  only  SDL  supported +applications  can  be  launched. +Page  121  of  159 +![](media/picture236.jpeg)![](media/picture237.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**Figure  8-33  :  SDL  overview** +**5.2.8.3  Requirements** +5.2.8.3.1  Miracast +System  must  provide  a  capability  of  Miracast  as  smartphone  link  function. +· +Support  WFD  Primary  Sink  and  support  MPEG2-TS(Video,  Audio)  streaming  play  which +from  Source  Device‑Smartphone‑. +· Supporting  WFD  Source  is  an  option. +· +Support  customize  function  using  “Miracast  setting  file”  which  used  for  negotiation  (\*1) +source  device  and  sink  device  (\*1.  Video  format,  audio  format  and  other  parameters). +· +Screen  data  which  from  Smartphone  may  not  support  Drivers  Destruction,  therefore  take +measures  to  Drivers  Destruction.  (e.g.  Disable  Miracast  during  vehicle  speed  over +5Km/H) +· Support  Wi-Fi  P2P  connection. +· +Follow  reference  \[1\]  and  reference  \[2\]  to  support  Wi-Fi  P2P  function,  parameters  in +Miracast  connection  and  so  on  if  there  was  no  description  of  this  section. +· Wi-Fi  TDLS  connection  is  an  option. +· +AGL  do  not  define  confliction  specification  regarding  Wi-Fi  connection.  (e.g.  User  select +Wi-Fi  P2P  connect  ion  during  accessing  Wi-Fi  connection.) +· +AGL  do  not  define  confliction  specification  regarding  Sink  device  operation  when  receive +Page  122  of  159 +![](media/picture238.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +connection  request  from  Source  device.  (e.g.  Connect  automatically,  ask  user  for +confirmation) +· +Support  P2P  Group  Owner  and  P2P  client  as  the  topology  of  Wi-Fi  P2P  connection. +· +Support  DHCP  server  and  DHCP  client  for  TCP/IP  seamless  connection  after  P2P +connection  established. +· +Support  2.4GHz  band  for  the  frequency  of  Wi-Fi  P2P  connection. +· +Supporting  5GHz  band  is  an  option,  but  support  DFS  (Dynamic  Frequency  Selection) +function  if  support  5GHz  band. +· Follow  reference  \[1\]  for  Video  Codec. +· Support  follow  format  for  Video  Resolution  and  Frame  rate. +o 640\*480‑VGA‑‑Progressive  60  fps +o 1280\*720‑HD‑Progressive  30  fps +Regarding  Video  resolution  and  Frame  rate,  other  formats  are  an  option. +· Support  follow  format  for  Audio. +o LPCM  48ksps  16bit  2ch +o AAC  48ksps  16bit  2ch +Regarding  Audio  Format,  other  formats  are  an  option. +When  the  state  changes  "Pause",  take  measures  to  give  notice  of  pause  for  user.  (e.g.  pop-up +notification) +Screen  data  which  from  Smartphone  may  be  protected  by  content  protection,  therefore  support +content  protection  function. +· +AGL  recommend  HDCP  function  which  described  reference  \[2\],  \[3\].  But  AGL  do  not +define  HDCP  function.  Each  vendor  should  support  content  protection  function  as  for +Page  123  of  159 +![](media/picture239.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +vendor’s  own  reason. +· Support  both  encryption  cases  if  support  HDCP  function. +o Case1  Videos  data  encryption +o Case2  Both  video  and  audio  encryption +Take  notice  that  it  is  necessary  to  satisfy  security  requirements  specified  according  to +DCP.(reference  \[4\]) +· +Miracast  must  support  interruption  by  other  function.  If  some  high  priority  event  occurs, +then  Miracast  release  screen  and  audio  resources  for  the  event. +· +It  is  selectable  how  to  deal  Miracast  session.  (Standby  Miracast  session  or  close  Miracast +session.) +· +Support  a  notification  to  a  user  and  returning  to  the  normal  state,  if  following  events +happen. +o Failed  to  Wi-Fi  connection +o Failed  to  establish  Miracast  session +o Wi-Fi  link  loss  on  Miracast +o Break  Miracast  connection  from  smartphone +5.2.8.3.2  Smart  Device  Link +System  must  provide  a  capability  of  Smart  Device  Link  as  smartphone  link  function. +System  must  provide  a  mechanism  to  render  HMI  of  SDL  according  to  template. +System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  touch  panel +device  of  IVI  device. +System  must  provide  a  mechanism  to  enable  user  interface  regarding  SDL  by  using  voice +Page  124  of  159 +![](media/picture240.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +recognition  of  IVI  system. +System  must  provide  a  mechanism  to  link  Android  device  regarding  SDL  capability.  Connectivity +method  must  be  supported  Bluetooth  and/or  Wi-Fi. +System  must  provide  a  mechanism  to  link  iPhone  device  regarding  SDL  capability.  Connectivity +method  must  be  supported  Bluetooth  and/or  Wi-Fi. +**5.2.9  Speech  Services** +The  Speech  Services  module  provides  voice  recognition  and  synthesis  for  AGL  applications. +AGL  system  voice  framework  must  be  able  to  record  and  interpret  voice  commands +AGL  system  voice  framework  must  be  able  to  convert  text  to  synthesized  speech +**5.2.10  Tuner  Services** +The  Tuner  Services  module  provides  a  mechanism  that  allows  different  tuner  types  to  plug  into +the  same  API  regardless  of  the  receiver  type.  Support  for  AM/FM,  HD  Radio,  SDARS,  DAB,  DRM, +TV  Tuners  etc  is  provided.  The  Tuner  Services  module  shall  allow  multiple  tuners  to  be  present +in  the  same  system  and  allow  its  clients  to  address  each  tuner  in  the  system  independently. +**5.2.10.1  Receivers** +The  Receivers  module  of  Automotive  Grade  Linux  may  control  different  receiver  types  including +AM,  FM,  Hybrid  Digital  (HD)  Radio,  SDARS,  and  DAB  tuners.  The  module  may  access  any +number  of  different  tuners.  For  all  tuner  types  the  module  supports  accessing  station  data  from +the  tuner,  changing  the  receiver  frequency  or  station  and  reading  station  metadata  about  current +content. +The  Receivers  module  shall  provide  a  mechanism  that  allows  different  tuner  types  to  plug  into +the  same  API  regardless  of  the  receiver  type. +Page  125  of  159 +![](media/picture241.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  Receivers  module  shall  allow  multiple  receivers  to  be  present  in  the  same  system  and  allow +its  clients  to  address  each  receiver  in  the  system  independently. +5.2.10.1.1  HD  Radio +HD  Radio  is  a  proprietary  In-Band  on  Channel  (IBOC)  system  created  and  owned  by  Ibiquity.  An +HD  radio  receives  analog  AM/FM  signals  and  can  also  use  digital  information  in  a  subband  to +provide  additional  stations  and/or  enhance  the  audio  quality  of  the  main  station.  When  the +receiver  is  decoding  digital  data  for  AM/FM  playback  it  is  commonly  thought  of  as  HD  Radio.  The +HD  Radio  system  architecture  shall  conform  to  the  broadcast  system  design  proposed  by  the +iBiquity  Digital  Corporation  detailed  in  RX\_SSFD\_5029.  Both  the  HD  hardware  and  functional +design  shall  meet  all  iBiquity  Digital  specifications,  and  satisfy  the  Type  Approval  specified  by +iBiquity  Digital. +The  IBOC  hardware  is  assumed  to  have  three  modes  which  will  be  used  to  describe  the +requirements  in  this  section. +1)  AM  -  radio  is  decoding  an  over  the  air  AM  station. +2)  FM  -  radio  is  decoding  an  over  the  air  FM  station. +3)  HD  -  radio  is  decoding  an  AM  or  FM  station  using  the  subband  for  the  over  the  air  station. +Each  requirement  may  refer  to  AM  and/or  FM  and/or  HD  to  specify  the  modes  the  requirement  is +applicable  to. +AM/FM/HD  system  shall  be  able  to  enable/disable  the  HD  radio  reception  and  present  the  status +to  the  system. +AM/FM/HD  tuner  shall  be  able  to  tune  to  a  specified  frequency  and  report  the  result  of  the +tuning  process.  The  possible  results  are,  Tuning  successful  and  Tuning  unsuccessful.  If  Tuning +successful  event  is  notified  by  the  tuner,  it  shall  play  the  audio  through  the  selected  audio +output.  If  tuner  notifies  the  Tuning  unsuccessful  event,  the  system  shall  inform  that  "No +Reception"  is  available  in  that  specific  channel. +AM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +Page  126  of  159 +![](media/picture242.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Frequency +· Mono/Stereo +FM  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +· Frequency +· PI  Code  (RDS  only) +· PTY  (RDS  only) +· Radio  Text  (RDS  only) +· PS  Name  (RDS  only) +· Category  (RDS  only) +· Mono/Stereo +HD  system  shall  extract  following  parameters  from  a  successfully  tuned  channel  and  present  to +the  system,  which  shall  be  added  in  the  station  database. +· Frequency +· PTY +· No  of  HD  channels  available +· Radio  Text +· Channel  Name +· Category +· Bit  rate +· Station  Logo +· Artist  Experience +The  System  shall  allow  the  tuned  frequency  to  be  incremented  or  decremented. +The  System  shall  be  able  to  tune  to  the  next/previous  valid  station  as  determined  by  signal +strength. +AM/FM/HD  system  shall  be  able  to  abort  Seek  Up/Down  operations. +Page  127  of  159 +![](media/picture243.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +FM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  FM  band  and  shall  be +possible  to  adjust  by  software. +· Range:  15  –  40  dBµV +· Step:  1  dBµV +· Default:  20  dBµV +· +Other  parameters  like  multipath  shall  be  possible  to  use  for  determining  Stop  sensitivity +level.  TBD,  Supplier  to  suggest  solution. +AM/HD  system  shall  be  able  to  set  the  stop  sensitivity  for  seek  over  AM  band  and  shall  be +possible  to  adjust  by  software. +· Range:  20  –  40  dBµV +· Step:  1  dBµV +· Default:  34  dBµV +· +It  shall  be  possible  to  have  different  setting  depending  on  atmospheric  conditions  (e.g. +different  for  night  and  day). +The  system  shall  be  able  to  switch  between  AM  and  FM  bands. +HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Short  Name  from  the +SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +present  to  the  system.  The  implementation  of  SIS  Short  Name  feature  shall  be  in  compliance +with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +Information  Service  Transport". +HD  system  shall  be  able  to  extract  the  Station  Information  Service  (SIS)  Long  Name  from  the +SIS  Protocol  Data  Unit  (PDU)  on  the  Primary  IBOC  Data  Service  (PIDS)  logical  channel  and +present  to  the  system.  The  implementation  of  SIS  Long  Name  feature  shall  be  in  compliance +with  iBiquity  Digital  specification  "HD  Radio™  Air  Interface  Design  Description  Station +Information  Service  Transport". +HD  system  shall  indicate  the  HD  channel  number  of  current  tuned  channel.  It  shall  be  1  to  8. +Page  128  of  159 +![](media/picture244.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +HD  system  shall  extract  the  following  PAD  data  from  audio  stream  and  present  to  the  system. +· Song +· Artist +· Album +· Genre +· Comments +· Commercial +· Reference  Identifier +The  system  implementation  shall  be  in  compliance  with  iBiquity  Digital  HD  radio  specification +"HD  Radio  Air  Interface  Design  Description  -  Program  Service  Data  Rev.  C" +FM/HD  system  shall  be  able  to  receive  and  extract  the  RDS/RBDS  data  and  present  to  the +system.  The  system  implementation  shall  be  in  compliance  with  "BS  EN  62106:2009, +Specification  of  the  radio  data  system  (RDS)  for  VHF/FM  sound  broadcasting  in  the  frequency +range  from  87,5  MHz  to  108,0  MHz". +FM/HD  system  shall  be  able  to  enable/disable  RDS/RBDS.  When  RDS/RBDS  is  enabled/disabled +the  system  shall  indicate  this. +FM/HD  system  shall  be  able  to  enable/disable  the  radio  text  display. +FM/HD  system  shall  present  the  Alternative  Frequency  (AF)  setting  status  to  the  system. +FM/HD  system  shall  be  able  to  enable/disable  alternative  frequency  switching. +FM/HD  system  shall  be  able  to  notify  the  system  when  an  Emergency  Alert  Interrupt  is  received. +FM/HD  system  shall  be  able  to  skip  the  Emergency  Alert  when  it  is  on-air. +FM/HD  system  shall  be  able  to  notify  the  system  when  Emergency  Alert  Interrupt  is  received +through  RDS. +Page  129  of  159 +![](media/picture245.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +FM/HD  system  shall  be  able  to  cancel  the  PTY31  interrupt  notification. +FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Announcement  reception. +FM/HD  system  shall  present  the  status  of  the  FM  traffic  announcement  to  the  system. +FM/HD  system  shall  be  able  to  skip  the  FM  traffic  announcement  when  it  is  on-air. +FM/HD  system  shall  be  able  to  enable/disable  regionalisation. +FM/HD  system  shall  be  able  to  enable/disable  the  Traffic  Message  Channel  (TMC)  reception. +FM/HD  system  shall  be  able  to  enable/disable  the  Transport  Protocol  Expert  Group  (TPEG) +reception. +FM/HD  system  shall  be  able  to  receive  the  traffic  updates  from  the  Japanese  traffic  channels. +FM/HD  system  shall  be  able  to  enable/disable  the  News  announcement  reception. +FM/HD  system  shall  be  able  to  skip  the  News  when  being  broadcast. +HD  system  shall  decode  PNG  images  which  shall  be  in  compliance  with  HD  Design  specification. +HD  system  shall  be  able  to  decode  the  channel  icon  PNG  images  and  present  to  the  system. +AM/FM/HD  system  shall  be  able  to  mute  the  audio  output. +AM/FM/HD  system  shall  be  able  to  un-mute  the  audio  output. +*HD system shall extract the album name, artist name, track number from the audio stream a*nd +Page  130  of  159 +![](media/picture246.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +present  to  the  system. +The  feature  will  store  the  data  of  a  tagged  song  in  non-volatile  memory  within  the  IMC.  The +feature  will  be  able  to  store  at  least  50  tags. +*5.2.10.1.1.1  Configuration* +AM/FM/HD  system  shall  be  able  to  configure  the  frequency  band  through  local  configuration +file. +AM/FM/HD  system  shall  be  able  to  configure  the  step  frequency  through  local  configuration  file. +AM/FM/HD  system  shall  be  able  to  configure  the  seek  stop  level  threshold  through  local +configuration  file. +5.2.10.1.2  Database  Requirements +AM/FM/HD  system  shall  require  a  database  to  store  the  channel  list  information  which  contains +the  following  attributes: +· Frequency +· PTY  (FM  &  HD  only) +· Channel  name  (FM  &  HD  only) +· Channel  icon  (HD  Only) +· Category  (FM  &  HD  only) +AM/FM/HD  system  shall  be  able  to  update  the  channel  list  database  based  on  the  following +conditions: +· New  channel  is  found +· Existing  channel  disappears +· +Channel  list  update  shall  not  create  any  inconsistency  on  the  current  channel  list +database. +Page  131  of  159 +![](media/picture247.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  channel  name,  and  present +to  the  system. +AM/FM/HD  system  shall  sort  the  channel  list  database  based  on  the  ascending  order  of  the +frequency,  and  present  to  the  system. +FM/HD  system  shall  sort  the  channel  list  database  based  on  the  PTY  (Program  Type)  category, +and  present  to  the  system. +AM/FM/HD  system  shall  create  favourite  station  database  which  consists  of  the  following +information: +· Station  name  (FM  and  HD  only) +· Frequency +· Status  of  HD  (HD,  HD1,  HD2) +· HD  SIS  (HD  only) +AM/FM/HD  system  shall  be  able  to  update  the  database  based  on  following  conditions: +· Favourite  station  changed +· Favourite  station  is  removed +· New  favourite  is  added +**5.2.11  Vehicle  Bus  /  Vehicle  Info  Control** +Vehicle  Info  Control  (VIC)  provides  a  capability  to  access  to  various  vehicle  properties  from +applications  and/or  other  middleware.  Standardized  interfaces  are  provided  to  vehicle  CAN,  and +LIN  bus.  Figure  7-27  describes  overall  architecture  of  Vehicle  Info  Control.  The  main  purpose  of +VIC  is  to  provide  API  to  application  and/or  middleware.  Vehicle  Info  Control  has  four  main +functions. +· Vehicle  Data  Processing +· Communication  between  ECUs +· Vehicle  Data  Upload +Page  132  of  159 +![](media/picture248.jpeg)![](media/picture249.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Simulator +**Figure  7-27  :  Overview  of  Vehicle  Info  Control** +**5.2.11.1  Vehicle  Data  Processing** +Vehicle  data  is  the  information  about  the  vehicle  itself,  and  the  information  in  cars  (for  example, +personal  information  on  a  driver,  etc.).  VIC  deals  with  all  the  information  which  application +and/or  middleware  need  within  vehicles.  The  following  data  is  contained  in  these. +· +Vehicle  information  about  the  vehicles  itself,  such  as  speed,  a  shift  position,‑temperature +· User  Information,  such  as  a  name,  taste,  etc.  of  a  driver +· The  operation  history  of  a  driver +Page  133  of  159 +![](media/picture250.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +The  operation  state  of  the  vehicles  which  middleware  determined  based  on  vehicle +conditions,  such  as  speed  and  day  and  night +Vehicles  data  processing  consists  of  the  following  functional  elements  further. +(1)  Abstraction  of  Vehicles  Data +In  VIC,  all  vehicles  data  is  treated  as  abstract  data.  it  concerns  and  comes  out  of  this  to  the  kind +of  car,  or  the  country  of  the  destination.  For  example,  though  speed  is  detected  at  the  revolving +speed  of  the  wheel,  in  VIC,  vehicles  data  is  abstracted  and  treated  at  speed  and  it  provides  for +application  and/or  middleware.  Thereby,  application  and/or  middleware  can  treat  the  vehicles +data  of  the  same  implications  and  the  same  unit. +(2)  Maintenance  of  Vehicles  Data +Each  abstracted  vehicles  data  is  held.  The  vehicles  data  to  hold  is  a  current  value  and  the  past +value  (history). +(3)  Application  /  Middleware  Interface  (API) +The  accessing  function  of  the  vehicles  data  from  application  and/or  middleware  is  offered  as  API. +Acquisition  of  the  current  value  of  vehicles  data  or  the  past  history,  a  setup  of  vehicles  data,  and +the  change  notice  function  of  vehicles  data  are  included  in  this.  However,  each  vehicles  data +restricts  the  application  and/or  middleware  which  can  be  accessed  according  to  the  importance +(access  control). +(4)  Vehicles  Interface +It  is  a  function  for  managing  the  various  data  of  vehicles  of  in-vehicle  networks,  such  as  CAN +and  FlexRay,  etc.  The  component  in  which  the  exchange  with  actual  vehicles  performs  the +exchange  with  vehicles  by  a  vehicle  type  since  it  is  various  is  not  included  in  requirements. +However,  the  correspondence  procedure  of  it  and  VIC  is  specified.  It  assumes  that  two  or  more +Vehicle  Interface  is  prepared  depending  on  a  communication  method  with  vehicles,  etc.  In +addition,  the  vehicles  data  which  can  be  accessed  for  every  Vehicles  Interface  is  restricted. +**5.2.11.2  Communications  between  ECUs** +Page  134  of  159 +![](media/picture251.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +which  each  ECU  can  access. +**5.2.11.3  Vehicle  Data  Upload** +When  a  system  consists  of  two  or  more  ECUs,  the  vehicles  data  managed  by  ECU  other  than +ECU  in  which  application  and/or  middleware  are  working  shall  also  be  treated.  For  this  reason, +vehicle  information  processing  communicates  with  it  of  other  ECUs.  Thereby,  application  and/or +middleware  can  be  treated,  without  caring  about  by  which  ECU  required  vehicles  data  is +acquired.  In  addition,  the  communication  function  between  ECUs  also  restricts  the  vehicle  data +which  each  ECU  can  access. +**5.2.11.4  Simulator** +In  the  development  environment  of  application  and/or  middleware,  since  actual  vehicles  data  is +unacquirable,  it  is  preparing  the  simulator  which  imitated  actual  vehicles,  and  makes +development  environment  construction  easy.  By  a  simulator,  it  assumes  using  the  steering  wheel +controller  for  PC  games.  Since  this  function  is  an  object  for  development  environment,  let  it  be +an  option. +**5.2.11.5  Requirements** +The  system  must  hold  vehicle  information  and  must  offer  the  mechanism  in  which  application +and/or  middleware  can  access  vehicle  information. +The  system  must  provide  application  and/or  middleware  with  vehicle  information  as  an  abstract +property.  For  example,  the  speed  of  vehicles  must  be  not  the  number  of  rotations  of  a  wheel  but +the  speed  of  a  car. +System  must  provide  a  mechanism  to  add  or  delete  vehicle  property  easily. +Page  135  of  159 +![](media/picture252.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  support  typical  vehicle  property  as  “standard  property”. +As  for  a  standard  property,  it  is  desirable  for  the  same  attribute  name  to  be  the  same  meaning. +System  must  provide  a  mechanism  to  add  or  delete  custom  vehicle  property  easily. +A  custom  property  is  a  property  which  a  system  donor  can  add  uniquely  in  addition  to  a  standard +property. +Let  the  unit  of  the  value  of  Vehicle  Info  Data  be  an  international  unit(meter,  gram,  …etc) +The  value  of  Vehicle  Info  Data  should  have  sufficient  accuracy  which  application  and/or +middleware  need.  For  example,  when  a  unit  is  made  into  Km/h,  an  integral  value  is  not  enough +as  the  accuracy  of  Velocity.  It  is  necessary  to  change  Km/h  into  MPH  in  the  country  of  a  mile +display.  Moreover,  it  is  because  the  error  of  the  speed  display  is  defined  by  law. +A  vehicle  information  control  facility  requires  the  mechanism  in  which  vehicle  information  is +stored.  A  lot  of  events  generate  some  information  at  high  speed.  About  such  information,  the +load  to  a  system  has  few  directions  processed  collectively.  Moreover,  when  data  is  taken  and +spilt  by  an  application,  the  structure  which  can  carry  out  recovery  is  required. +It  is  not  realistic  to  accumulate  all  the  information  that  changes  at  high  speed.  For  this  reason,  In +corresponding  to  neither  of  the  following,  it  shall  not  store  the  change  data. +· +The  amount  of  change  of  a  value.  It  is  not  accumulated  when  the  difference  from  the +accumulated  newest  value  is  less  than  a  threshold  value. +· +Lapsed  time  from  the  last  change  It  does  not  accumulate,  if  time  has  not  passed  since  the +newest  accumulation. +About  each  vehicle  information,  the  threshold  value  and  cumulative  dosage  of  accumulation  need +to  be  able  to  set  up  easily. +In  addition,  it  also  makes  it  possible  not  to  accumulate  specific  vehicle  information. +System  must  provide  an  interface  to  application  and/or  middleware  regarding  vehicle  property +access. +System  must  provide  an  interface  to  retrieve  vehicle  property  from  application  and/or +middleware. +Page  136  of  159 +![](media/picture253.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Below  attributes  must  include  in  this  interface +· Zone(optional) +· Property  name +· Value +· +Timestamp  -  Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +System  must  provide  an  interface  to  set  abstracted  value  to  vehicle  property  from  application +and/or  middleware. +Below  attributes  must  include  in  this  interface. +· Zone(optional) +· Property  name +· Value +System  must  provide  an  interface  to  subscribe  status  change  of  vehicle  property  from +application  and/or  middleware. +When  status  changed,  system  must  invoke  callback  function  with  below  attributes. +· Zone(optional) +· Property  name +· Value +· Timestamp +· Sequence  number +Timestamp  specifies  last  updated  time  of  corresponded  vehicle  property. +Sequence  number  is  useful  to  check  event  order. +The  acceptable  value  of  change  can  be  specified  for  vehicle  information  about  the  notice  of +change  of  vehicle  information. +In  order  to  lower  system-wide  load,  it  will  not  notify,  if  it  is  change  which  is  less  than  an +acceptable  value  even  if  vehicle  information  changes. +For  example,  although  engine  number  of  rotations  changes  every  moment,  in  the  case  of  the +application  which  displays  it  in  20  steps,  it  is  not  necessary  to  know  less  than  several  percent  of +change. +Page  137  of  159 +![](media/picture254.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +It  shall  not  notify  the  change,  in  corresponding  to  neither  of  the  following. +· +The  amount  of  change  of  a  value  -  It  does  not  notify,  if  the  amount  of  change  of  the +value  from  the  last  notice  of  change  is  less  than  specification. +· +Lapsed  time  from  the  last  change  -  From  the  last  notice  of  change,  if  it  is  less  than  a +definite  period  of  time,  it  does  not  notify. +Depending  on  application,  the  notice  with  a  fixed  cycle  is  more  convenient  than  the  notice  at  the +time  of  change. +What  is  notified  only  the  specified  cycle  even  if  it  changes  two  or  more  times  into  the  specified +notice  interval  is  made  possible. +The  data  stored  is  acquired  collectively. +Below  attributes  must  include  in  this  interface. +· Zone(optional) +· Property  name +· Values +· Timestamps +It  is  desirable  that  the  time  range  to  acquire  can  be  specified.  For  example,  data  from  10 +seconds  before  to  the  present,  data  from  13:20  to  14:00,  etc. +There  is  an  attribute  for  which  change/reference  is  simultaneously  needed  in  relation  to  mutual +in  vehicle  information.  For  example,  latitude,  longitude,  and  an  altitude  are  changed +simultaneously.  If  these  pieces  of  vehicle  information  is  changed  and  referred  to  individually,  the +newest  longitude  may  acquire  the  value  in  front  of  one,  and  a  current  position  may  be  unable  to +recognize  latitude  correctly.  For  this  reason,  it  is  necessary  to  summarize  the  vehicle  information +relevant  to  mutual  and  to  access  it. +Access  of  ones  of  those  vehicle  information  is  deterred  until  renewal  of  all  the  vehicle +information  included  in  Property  Set  at  the  time  of  a  setup  of  vehicle  information  is  completed, +and  renewal  of  ones  of  those  vehicle  information  is  deterred  until  it  completes  acquisition  of  all +those  vehicle  information  at  the  time  of  reference. +The  definition  of  the  vehicle  information  included  in  Property  Set  is  being  able  to  change  easily. +Or  the  thing  which  can  be  changed  from  a  program  during  operation. +Page  138  of  159 +![](media/picture255.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  must  provide  a  mechanism  of  access  control  per  each  property.  For  example,  property +"velocity"  can  be  accessed  from  only  application  A  and  B,  but  property  "turn  signal"  can  be +accessed  from  all  applications. +System  must  also  provide  a  mechanism  of  access  control  per  each  method  even  if  same +property.  For  example,  about  "seat  setting",  all  applications  can  get  this  property,  but  only +application  C  can  set  this  property. +Permission  for  each  property  and  method  must  be  configurable  easily.  Because,  access  control +policy  may  be  different  per  car  type,  grade  and  destination. +System  must  provide  a  mechanism  to  enable  routing  any  vehicle  property  both  within  same  ECU +and  across  two  or  more  ECU’s. +If  a  Property  Change  event  is  received  from  VIC,  change  can  be  notified  to  all  the  applications, +middleware  and  other  VICs  which  are  subscribing  change  of  the  vehicle  information.  In  addition, +the  notice  of  change  must  be  able  to  be  distributed  also  to  the  application  and/or  middleware +which  exist  in  a  different  ECU. +VIC  can  be  requested  to  set  the  value  specified  as  Property. +It  can  set,  even  if  it  exists  on  ECU  from  which  an  application  and  VIC  differ. +The  newest  value  can  be  returned  immediately,  without  asking  VIC  to  the  acquisition  demand +from  an  application.  For  this  reason,  keep  the  newest  value  of  each  Property. +Even  if  it  is  in  ECU  from  which  VIC  of  the  Property  differs,  the  demand  from  an  application +responds. +It  can  exchange  with  two  or  more  VICs.  Addition  and  deletion  of  Data  Provider  can  be  performed +easily. +The  data  exchange  between  ECUs  should  be  permitted  by  VIC. +All  data  transmission  and  reception  from  other  Software  Component  are  refusing. +Page  139  of  159 +![](media/picture256.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +The  system  should  have  a  mechanism  which  communicates  the  stored  vehicles. +The  vehicle  information  to  upload  is  being  able  to  choose. +A  selection  condition  is  that  the  following  specification  is  possible  at  least. +· Date-and-time  range +· Object  vehicles  data +· The  change  threshold  value  of  vehicles  data +Enable  change  of  selection  of  vehicle  information  easily.  As  for  this,  it  is  desirable  for  it  to  be +able  to  change  dynamically  from  an  external. +The  simulator  of  vehicles  data  using  the  steering  wheel  controller  for  PC  games,  etc.  as +substitution  of  actual  vehicles  in  development  environment  is  prepared. +Car  Simulator  is  being  able  to  notify  the  following  vehicles  data  to  vehicles  data  processing +activities  through  a  vehicles  interface  function  at  least. +· Speed +· Shift  position +· The  direction  of  vehicles +· Latitude  and  longitude  of  a  current  position +· Turn  signal +The  steering  wheel  controller  for  PC  games  to  be  used  is  being  able  to  obtain  easily.  Moreover, +it  is  desirable  that  two  or  more  steering  wheel  controllers  can  be  used. +VIC  should  fill  the  following  performance  specifications  and  performance. +It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +information  machines  and  equipment  in  2016. +Page  140  of  159 +![](media/picture257.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· Maximum  number  of  properties  :  4,096 +· Maximum  number  of  property  sets:  1,024 +· Greatest  data  storage  time :  12  hours +It  is  a  value  on  condition  of  H/W  assumed  that  the  following  values  will  be  used  for  in-vehicle +information  machines  and  equipment  in  2016. +· Get/Set  method(one  property)  -  0.2ms +· Get/Set  method(property  set  include  30  properties)  -1.3ms +· Subscribe  callback  -  2.5ms  (after  change  of  a  value) +· +GetHistory  method(for  within  3  minutes  after  the  present)  -  0.2ms +· +GetHistory  method  (older  than  3  minutes  from  the  present)  -  50ms +VIC  is  being  able  to  change  without  having  composition  which  has  pliability  and  extendibility +about  the  vehicles  data  to  manage,  and  reconstructing  the  whole  VIC  about  the  kind  and +attribute  of  vehicles  data. +Vehicle  Interface  treats  various  kinds  of  in-vehicle  LAN  and  sensors,  and  they  are  mounted  by +various  H/W  according  to  a  maker  or  a  vehicle  type.  For  this  reason,  VIC  needs  to  be  able  to  add +and  change  Vehicle  Interface  without  reconstruction  of  VIC. +Abstraction  of  vehicles  data  is  the  duty  of  Vehicle  Interface  in  principle.  This  is  because  it  is +necessary  to  change  the  concreteness  data  depending  on  H/W  of  in-vehicle  LAN  or  sensors. +However,  an  abstract  vehicles  data  value  may  be  decided  by  combination  of  the  concreteness +vehicles  data  from  two  or  more  Vehicle  Interface.  In  this  case,  VIC  needs  to  change  two  or  more +concreteness  vehicles  data  into  one  abstract  vehicles  data. +Since  this  conversion  is  dependent  on  H/W  of  in-vehicle  LAN  or  sensors,  so  it  cannot  be +mounted  in  the  VIC  itself. +In  order  to  solve  this,  suppose  that  the  mechanism  in  which  such  a  conversion  module  can  be +added  without  reconstruction  of  VIC  is  prepared  for  VIC. +**5.2.12  Telematics  Services** +V2V,  V2I,  RVI,  Traffic  information,  etc. +Page  141  of  159 +![](media/picture258.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +**5.2.13  Window  System** +A  window  system  is  a  software  component  that  facilitates  an  implementation  of  graphical  user +interface.  A  window  system  is  responsible  for  managing  display  devices,  Graphics  Processing +Units  (GPUs),  input  devices,  and  graphics  memory.  A  window  system  works  with  the  software +component  named  window  manager  that  is  responsible  for  a  layout  management  of  windows, +and  a  routing  of  user  interactions. +AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  multiple  windows  owned  by  multiple +processes  to  be  rendered  on  a  display. +AGL  specifies  that  automotive  grade  Linux  shall  support  rendering  to  off-screen  buffer  to +achieve  flicker  less  rendering. +AGL  specifies  that  automotive  grade  Linux  shall  support  composition  of  windows  with  off- +screen  buffers. +AGL  specifies  that  automotive  grade  Linux  shall  support  a  translucent  window,  i.e.  underlying +objects  underneath  the  translucent  window  is  visible  depending  on  the  alpha  values  of  pixels. +AGL  specifies  that  automotive  grade  Linux  shall  make  OpenGL/ES  2.0  API  compliant  to  Khronos +group  available  to  clients  for  their  rendering. +AGL  specifies  that  automotive  grade  Linux  shall  have  a  window  manager  that  uses  only  public +APIs  provided  by  Window  System  and  OpenGL/ES  2.0  for  rendering  and  user  interaction. +AGL  specifies  that  automotive  grade  Linux  shall  support  window  manager  that  is  replaceable  by +configuration. +AGL  specifies  that  automotive  grade  Linux  shall  provide  a  window  system  that  abstracts  the +*underlying display subsystem and GPU. AGL specifies that automotive grade Linux shall hav*e  a +Page  142  of  159 +![](media/picture259.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +window  manager  that  relies  on  a  standard  rendering  API  such  as  OpenGL/ES  2.0  only.  The +window  manager  shall  not  rely  on  any  hardware  specific  API.  A  window  system  and  OpenGL/ES +2.0  API  are  responsible  for  a  hardware  abstraction. +AGL  specifies  that  automotive  grade  Linux  shall  support  multi-headed  display  where  available. +AGL  specifies  that  automotive  grade  Linux  shall  support  mirroring  of  windows  to  multiple +displays. +AGL  specifies  that  automotive  grade  Linux  shall  support  hardware  layers,  such  as  DRM  planes, +where  available. +AGL  specifies  that  automotive  grade  Linux  shall  compose  windows  using  available  hardware +acceleration  capabilities. +AGL  specifies  that  automotive  grade  Linux  shall  support  management  of  windows  and  inputs +from  users  depending  on  statuses  of  a  vehicle.  The  statuses  of  vehicle  include  a  speed  of  a +vehicle,  a  motion  of  a  vehicle,  etc.  For  instance,  the  inputs  may  needs  to  be  limited  while  the +vehicle  reaches  to  the  certain  speed. +AGL  specifies  that  automotive  grade  Linux  shall  abstract  physical  input  devices  such  as  buttons, +a  touch  panel,  a  control  knob  etc. +AGL  specifies  that  automotive  grade  Linux  shall  support  On-screen  keyboard  which  takes  input +from  available  physical  input  devices. +**6   Security   Services** +Security  framework +6.1  Access  Control +Access  Control  describes  requirements  for  AGL  Access  Control. +Page  143  of  159 +![](media/picture260.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Access  control  is  a  mechanism  to  grant  /  deny  access  to  APIs/files  in  the  system. +**6.1.1  Requirements** +AGL  system  must  support  a  system-wide  access  control  mechanism. +**7   Operating   System   Layer** +7.1  Kernel +**7.1.1  Linux  Kernel** +Automotive  Grade  Linux  uses  the  Linux  Kernel.  The  kernel  is  constantly  evolving  with  a  new +release  about  every  sixty  days.  The  automotive  industry  has  design  cycles  of  three  to  five  years +for  IVI  systems.  Somehow  a  balance  must  be  struck  between  updating  operating  system  and +kernel  every  few  months  and  keeping  up  to  date  with  modern  features  that  the  kernel  and  the +rest  of  the  open  source  community  provides, +**7.1.1.1  Requirements** +AGL  kernel  shall  be  based  on  Long  Term  Support  Initiative  (LTSI)  kernel. +At  the  moment  LTSI  kernel  is  the  only  open  source/public  kernel  that  gets  closer  to  automotive +industry  needs  –  it  has  certain  automotive  industry  demanded  components  integrated,  it  is  fully +aligned  with  Linux  LTS  trees  so  it  leverages  security  fixes  and/or  generic  bugfixes  adapted  by +Linux  community,  LTSI  kernel  merge  window  is  more  flexible  to  industry  demands  and  allow  to +accumulate  wider  set  of  features,  components  and  bugfixes  relevant  for  industry  (comparing  to +regular  Linux  kernel  merge/release  cycle).  LTSI  kernel  is  thoroughly  validated  manually  and  with +the  help  of  automated  tools  to  track  and  discover  anomalies  and  regressions. +AGL  development  process  should  utilize  bug  tracker  with  ability  to  mark  bugs  as  open/fixed  on +particular  distribution  branches.  Open  bugs  should  have  direct  impact  on  release  decisions. +Page  144  of  159 +![](media/picture261.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +7.2  Boot  Loader +7.3  Hypervisor +TBD.  Need  to  add  very  basic  “background”  regarding  virtualization,  explain  about  OS-level +virtualization/isolation,  then  about  type1/type2  hypervisors  (virtualization).  In  modern  IVI +systems  OS-level  virtualization  is  widely  used  (applications  isolation,  combination  of  Android +and  Linux  apps  together),  future  –  maybe  Linux/IVI  +  ADAS  +  Instrument  Cluster  =  guests  on +top  type1  hypervisor. +**7.3.1  Requirements** +AGL  shall  provide  OS-level  mechanisms  for  running  multiple  isolated  instances  (containers)  that +have  its  own  directory  structure,  network  devices,  IP  addresses  and  process  table.  The +processes  running  in  other  containers  shall  not  be  visible  from  inside  a  container. +AGL  Linux  should  be  configurable  to  work  as  Type-1  “bare-metal”  hypervisor  “guest”.  Following +functionality  shall  be  supported  by  AGL  Linux  “guest”: +· IPC  (with  hypervisor  and  other  “guests”) +· +“paravirtualized”  device  drivers  for  peripherals  shared  with  other  “guests”  (unless +virtualization  abstraction  is  supported  by  hardware) +7.4  Operating  System +**7.4.1  File  Systems** +File  system  (FS)  requirements  for  AGL  concentrate  on  Reliability,  Accessibility,  and  Serviceability +as  their  main  characteristics. +· +*Reliability*means  data  integrity  protection,  automatic  error  detection  and  correction, +tolerance  to  power  failures,  robustness  under  stress  I/O  load  in  multi-process +environment,  extended  lifetime  via  use  of  wear  leveling  and  bad  block  management +techniques. +Page  145  of  159 + + ------------------------------------------------------------------------------- + > **FS  Requirements** > **R-FS  References** + ------------------------------------------------------ ------------------------ + > 6.  File  Systems  (P1) > 2.  btrfs + > > + > 6.1.  Robust  File  System  for  managed  internal > 2.1. + > > + > storage  (P1) > btr + > > + > 6.1.1.  Power  failure  tolerance  (P1) > fsc + > > + > 6.1.2.  Quick  recovery  after  power  loss > k + > > + > (P1) > 3.  ext2 + > > + > 6.1.3.  Multi-threaded  I/O  (P1) > 3.1. + > > + > 6.1.4.  On-demand  integrity  checker  (P1) > e2 + > > + > 6.1.5.  Read-only  mode  (P1) > def + > > + > 6.1.6.  Non-blocking  unmounting  (P1) > rag + > > + > 6.1.7.  Means  for  optimizing  I/O > 4.  ext3 + > > + > performance  if  it  may  degrade  under > 5.  ext4 + > > + > certain  conditions.  (P2) > 5.1. + > > + > 6.1.8.  File  space  pre-allocation  (P2) > e4 + > > + > 6.1.9.  Meta-data  error  detection  (P2) > def + > > + > 6.1.10.  File  data  error  detection  (P2) > rag + > > + > 6.1.11.  Online  integrity  checking  (P2) > 5.2. + > > + > 6.1.12.  Write  timeout  control  (P2) > e2f + > > + > 6.1.13.  Compression  support  (P2) > sck + > > + > 6.1.14.  Quota  support  (P2) > 6.  vfat + > > + > 6.1.15.  I/O  process  priority  (P2) > 7.  UBIFS + > > + > 6.1.16.  File  system  event  notifications > 8.  Generic + > + > tools  and + > + > APIs + > + > 8.1. + > + > fan + ------------------------------------------------------------------------------- + +![](media/picture262.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +· +*Accessibility*means  ability  to  use  external  storage  devices,  as  well  as  accessing +designated  parts  of  internal  file  system  over  secure  wired  or  wireless  connections. +· +*Serviceability*means  ability  to  upgrade  AGL  as  a  whole  or  by  updating  individual +packages,  and  availability  of  file  system  checking  and  optimization  tools. +![](media/picture263.jpeg)Automotive Grade Linux Requirements Spec v1.0 +(P2) +6.1.17.  Logical  block  size  control  (P2) +6.1.18.  Snapshots  (P2) +6.2.  File  System  for  non-managed  internal +storage  (P1) + +May  28,  2015 + +otif + +y + +8.2. + +fst + +rim + +6.2.1.  All  P1  requirements  from +FS.1.1.x  list  (P1) +6.2.2.  Wear  leveling  (P1) +6.2.3.  Error  detection/correction  (P1) +6.2.4.  Tolerance  to  flipping  bits  (P1) +6.2.5.  Read/write  disturb  awareness +(P1) +6.2.6.  Bad  block  management  (P1) +6.2.7.  As  many  P2  requirements  from +FS.1.1.x  list  as  possible  (P2) +6.2.8.  Wear  leveling  statistics  (P2) +6.3.  File  Systems  for  removable  storage  (P1) +6.3.1.  Restricted  functionality  from +security  point  of  view  (P1) +6.3.2.  Automount/autounmount  (P1) +6.3.3.  Automatic  synchronous  flushing +of  modified  data  to  physical  media  (P2) +**7.4.1.1  Requirements** +AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +memory),  removable  managed  (USB  stick,  SD  card). +AGL  shall  provide  robust  file  system  suitable  for  use  on  managed  internal  storage  devices, +Page  147  of  159 +![](media/picture264.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +AGL  shall  provide  robust  file  system  suitable  for  use  on  non-managed  internal  storage  devices, +AGL  shall  provide  a  set  of  file  systems  popular  on  removable  media  devices. +A  system  must  be  able  to  withstand  power  failures  under  heavy  load  of  meta-data-intensive, +and  data-intensive  operations,  including  power-failures  during  OS  startup,  and  shutdown. +A  file  system  must  be  able  to  restore  good  data  and  meta-data  state  after  unexpected  power +interruption  without  performing  the  full  time-consuming  integrity  check.  Such  recovery  should +not  add  more  than  a  second  to  the  normal  boot  process  after  power  failure  on  idle  system. +Normally  this  is  achieved  via  journal-  or  log-based  (also  known  as  transactional  or  copy-on- +write)  operation. +A  file  system  must  be  able  to  handle  meta-data-intensive,  and  data-intensive  I/O  from  multiple +threads  and/or  processes  simultaneously. +A  file  system  must  have  integrity  checking  tool  with  ability  to  execute  it  on-demand. +A  file  system  must  be  able  to  switch  between  read-only,  (when  no  data  is  committed  to  physical +storage  device),  and  read/write  modes  in  runtime.  E.g.  via  “mount  –o  remount,ro  <device>” +command. +AGL  must  support  “lazy”  (delayed)  unmounting. +AGL  should  provide  means  for  optimizing  potentially  degraded  I/O  performance  after  prolonged +file  system  and  storage  use.  Often,  this  refers  to  offline  or  online  file  system  defragmentation. +Another  example  is  periodic  fstrim  execution  on  SSD  storage. +A  file  system  should  be  able  to  pre-allocate  space  for  created/extended  files  on  request.  This +may  be  used  to  minimize  fragmentation  of  frequently  written  files. +A  file  system  should  have  an  option  of  automatic  error  detection  in  its  meta-data. +Page  148  of  159 +![](media/picture265.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +A  file  system  should  be  able  to  associate  error  detection  codes  with  separate  blocks  of  stored +data,  and  to  verify  the  data  against  the  codes  in  runtime  upon  each  read  from  a  physical  device. +A  file  system  should  have  a  utility  for  meta-data  integrity  checking  on  mounted  partition. +A  file  system  should  allow  changing  timeout  after  which  it  flushes  modified  data  to  physical +media. +A  file  system  should  support  automatic  data  compression. +It  should  be  possible  to  enable  file  system  quotas  for  particular  users  and/or  groups. +AGL  should  allow  to  set  I/O  scheduling  class  and  priority  for  particular  processes. +AGL  should  allow  user  space  applications  to  subscribe  for  file  and  directory  change  notifications. +Making  logical  block  size  equal  to  a  power  of  physical  block  size  may  improve  physical  I/O +performance,  and  decrease  file  fragmentation  impact. +A  file  system  should  allow  creation  of  snapshots. +A  file  system  must  perform  wear  leveling  before  writing  data,  so  that  the  limited  number  of +erase/program  cycles  is  evenly  distributed  across  all  device  blocks. +A  file  system  must  support  the  following  error  detection/correction  algorithm(s):  BCH4,  BCH8. +A  file  system  should  not  just  be  able  to  detect/correct  a  number  of  flipped  bits  but  should  also +actively  prevent  the  issue  from  happening  in  the  first  place,  especially  after  unexpected  power +interruption.  Known  techniques  include  forced  reprogramming  of  blocks  that  were  in  use  at  the +time  of  power  failure,  and  copying  data  to  a  fresh  block  after  detected  error  correction. +A  file  system  should  not  just  be  able  to  detect/correct  errors  caused  by  read/write  disturb +Page  149  of  159 +![](media/picture266.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +phenomenon  but  should  also  actively  prevent  the  issue  from  happening  in  the  first  place.  Known +techniques  include  limiting  the  number  of  read  cycles  between  erases,  and  copying  data  to  a +fresh  block  after  detected  error  correction. +A  file  system  must  perform  bad  block  detection  and  management  transparently  to  file  system +users. +Current  FLASH  wear-related  statistics  should  be  accessible  via  user-space  utility. +A  file  system  must  support  noexec,  and  nodev  mount  options. +A  file  system  must  be  able  to  automatically  mount  plugged-in  removable  media,  and +automatically  unmount  it  when  unplugged. +A  file  system  must  support  sync  mount  option. +AGL  shall  provide  a  set  of  file  systems  to  support  the  following  types  of  storage  devices: +internal  managed  (SSD,  eMMC,  etc.),  internal  non-managed  (raw  NOR  and  NAND  FLASH +memory),  removable  managed  (USB  stick,  SD  card). +**7.4.2  Resource  Control** +In  IVI  system,  it  depends  time  and  occasion  that  which  application  and/or  middleware  should  be +higher  priority.  Resource  control  provides  basic  functionality  regarding  proper  resource +allocation  for  each  process  and/or  process  group. +(cgroups) +**7.4.2.1  Use  Case  and  Role** +If  end  user  specified  a  destination  and  started  route  guidance,  map  drawing  following  current +position  and  voice  and/or  visual  guidance  should  be  treated  as  higher  priority  than  others. +On  the  other  hand,  if  end  user  is  watching  a  movie,  movie  player  and  decoder  should  be  assigned +Page  150  of  159 + + ------------------------------------------------------------------------------------------- + > **No.** > **Role** > **Description** + ----------- -------------- ---------------------------------------------------------------- + > 1 > Priority > Allocate  resource  via  its  own  priority.  High  priority + > + > process  and/or  process  group  should  be  assigned + > + > more  resource. + + > 2 > Time  slot > To  share  resource  per  time  slot. + + > 3 > Release > Forced  release  of  partially  or  whole  allocated + > + > resource. + + > 4 > Grouping > Grouping  two  or  more  processes,  and  allocate + > + > resource  per  defined  process  group. + ------------------------------------------------------------------------------------------- + +![](media/picture267.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +to  higher  priority  than  others. +Important  point  is  that  it  may  assign  two  or  more  high  priority  application  and/or  middleware  at +the  same  time.  And,  one  function  may  be  provided  from  two  or  more  processes. +Table  9-33  describes  the  role  of  resource  control  to  be  satisfied  above  purpose  and  use  cases. +AGL  assumes  four  types  of  resources,  CPU,  memory,  storage  bandwidth  and  network +bandwidth.  Table  9-34  describes  associated  roles  per  each  resource  type. +**Table  9-34  :  Functions  of  System  Resource  Management** +**7.4.2.2  Requirements** +7.4.2.2.1  Priority +System  provides  a  mechanism  to  set  resource  priority  per  each  process. +Page  151  of  159 +![](media/picture268.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +System  provides  an  interface  to  set  and  refer  resource  priority  of  specific  process. +This  interface  must  be  called  from  other  process. +CPU  resource  must  support  “priority”  based  resource  management. +Resource  Manager  should  dynamically  change  the  ratio  of  offering  resources  according  to  the +status  of  resources  using  by  system.  And  its  configuration  must  be  changed  easily. +Resource  Manager  should  log  the  status  of  resources  using  by  system. +Resource  Manager  should  offer  resources  separately  to  threads  of  user  land  and  threads  of +kernel.  And  Resource  Manager  should  treat  the  bottom  half  and  software  interrupts  as  high +priority  tasks. +7.4.2.2.2  Time  Slot +When  two  or  more  process  request  to  same  resource  at  the  same  time,  system  must  provide  a +mechanism  to  mediate  to  guarantee  the  time  slot  to  obtain  specific  timeframe  for  each +processes. +System  must  provide  an  interface  to  set  specific  timeframe  to  obtain  time  slot  per  each  process. +System  must  provide  a  mechanism  of  resource  sharing  by  time  slot  regarding  CPU,  storage +bandwidth  and  network  bandwidth. +Scheduler  should  detect  the  status  of  resources  for  each  thread. +Scheduler  must  not  run  the  specific  thread  for  more  than  10  micro  second. +Scheduler  should  guarantee  that  threads  can  run  periodically. +Scheduler  should  control  the  dispatches  that  occur  extremely. +Page  152  of  159 +![](media/picture269.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +7.4.2.2.3  Release +System  must  provide  an  interface  to  release  all  or  partial  resource  which  had  obtained  by +specific  process. +System  must  provide  a  mechanism  of  resource  releasing  regarding  memory  resource. +7.4.2.2.4  Grouping +System  must  provide  a  mechanism  to  group  two  or  more  processes  regarding  resource +management  such  as  priority,  time  slot  and  releasing.  System  must  able  to  assign  same +attributes  to  grouped  processes  altogether. +System  must  provide  an  interface  to  group  two  or  more  processes  from  other  process. +System  must  provide  a  mechanism  to  group  regarding  CPU,  memory,  storage  bandwidth  and +network  bandwidth. +**7.4.3  Startup/Shutdown  Control** +Boot/Shutdown  Control  is  a  mechanism  to  control  boot  and  shutdown  of  a  program  running  in  a +user  space.  The  order  of  boot/shutdown  in  the  target  program  can  be  easily  swapped  depending +on  the  product  configuration.  Boot/Shutdown  Control  supports  both  “static  order”  which +boots/shuts  down  the  program  according  to  the  static  dependency  of  each  program,  and +“dynamic  order”  which  swaps  the  order  dynamically  in  specific  conditions. +**7.4.3.1  Use  Cases** +(1)  Static  Modification  of  Boot/Shutdown  Order +a. +Setting  up  of  Boot/Shutdown  Order  Based  on  Product  Configuration +To  support  various  product  configurations,  the  integrator  configures/modifies  orders  of  boot/shutdown +for  all  programs  running  on  the  target  device. +Page  153  of  159 +![](media/picture270.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +b. +Configuring  the  Order  of  Boot/Shutdown  during  a  Program  Development +In  order  to  evaluate  a  developed  program,  the  developer  modifies  only  the  order  of  the  developed +program  in  target  programs. +c\. Configuring  the  Order  of  Boot/Shutdown  when  Software  Update +Maintainer  modifies  the  order  of  boot/shut  down  for  a  program  to  be  updated  when  software  update. +(2)  Dynamic  Modification  of  Boot/Shutdown  Order +a. +Prioritized  Boot  of  the  Features  which  the  User  was  Previously  Using +It  dynamically  modifies  the  boot  order  of  the  target  program  in  order  for  last  used  features  (e.g.  audio)  to +be  operated  by  priority  when  ACC  turns  ON. +b\. Prioritized  Boot  of  Update  Functionalities +Update  related  programs  are  booted  by  priority  when  connected  with  maintenance  kit  and  ACC  turned +ON. +**7.4.3.2  Requirements** +Boot/Shutdown  Control  shall  start  components,  which  are  configured  to  be  started. +Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  started  in  the  order  that +has  been  configured. +Boot/Shutdown  Control  shall  start  independent  components  in  parallel. +Boot/Shutdown  Control  shall  stop  components,  which  are  requested  to  be  stopped. +Boot/Shutdown  Control  shall  ensure  that  dependent  components  are  stopped  in  the  order  that +has  been  configured. +Page  154  of  159 +![](media/picture271.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Boot/Shutdown  Control  shall  be  configurable  by  run  level  to  start  corresponding  modules. +**7.4.4  Database** +Due  to  the  nature  of  AGL  operating  environment,  it  is  very  important  for  DB  engine  to  guarantee +database  instance  integrity  after  power  failures.  Other  important  feature  for  generic  system +database  engine  is  rich  set  of  bindings  to  various  programming  languages. +Below  is  short  summary  for  better  understanding  of  DBS  Requirements  and  References +hierarchy. +1.  Power  failure  tolerance  (P1) +2.  Quick  recovery  after  power  loss  (P1) +3.  Multi-threaded  I/O  (P1) +4.  API  bindings  for  C  programming  language +5.  On-demand  integrity  checker  (P2) +DB  instance  integrity  must  be  ensured  after  power  failures  under  heavy  load  of  read  and  write +DB  transactions. +DB  engine  must  be  able  to  quickly  restore  good  data  state  after  unexpected  power  interruption. +Such  recovery  should  not  add  more  than  a  second  to  the  normal  boot  process  after  power +failure  on  idle  system. +DB  engine  must  allow  read  and  write  access  to  DB  instance  from  multiple  threads  and/or +processes  simultaneously. +DB  engine  API  must  be  available  for  C-based  applications. +DB  engine  should  have  DB  instance  integrity  checking  tool  with  ability  to  execute  it  on-demand. +DB  engine  must  be  able  to  quickly  restore  to  a  previously  defined  state  after  unexpected  power +interruption  during  adding  some  data. +Page  155  of  159 +![](media/picture272.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +DB  engine  should  have  availability  to  merge  some  data  from  internal  and  external  databases, +such  as  vehicle  information  database  and  databases  at  data  center. +And  DB  engine  should  have  accessibility  to  allow  read  access  to  DB  instance  during  merging. +Also,  DB  engine  should  have  durability  not  to  break  its  data  after  unexpected  power  interruption +during  merging. +**7.4.5  System  Update** +Maintenance  of  in-vehicle  devices  is  also  an  important  role  for  any  automotive  system.  There  are +numerous  use  cases  for  updating  the  device  software  such  as  software  failure,security  patching, +bug  fixes,  and  new  features.  Because  automotive  devices  are  battery  operated  and  subject  to +power  cuts  any  System  Updates  must  be  robust  enough  to  withstand  sudden  power  loss. +System  Update  module  should  have  a  Robust  version  up  function. +System  Update  moduleshould  have  a  system  difference  version  up  function. +There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +apt  of  Linux  distribution). +There  should  be  a  data  update  structure  for  each  file  or  package  (same  as  WindowsUpdate  or +apt  of  Linux  distribution). +Difference  update  should  be  enabled  for  kernel,  middle  ware  and  application. +If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  system  should +be  recovered  after  choosing  the  status  (before  or  after  update)  for  each  update  target. +If  power  discontinuity  (forced  restart)  occurs  during  update  for  differences,  the  status  (during +update)  should  be  detected  and  the  system  should  restart. +Time  required  for  applying  patch  should  be  5  minutes  maximum  for  single  10MByte  data. +Page  156  of  159 +![](media/picture273.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +Memory  usage  for  difference  update  should  be  maximum  1Mbyte. +Unit  amount  for  difference  data  should  be  10MByte  maximum  for  difference  update. +System  Update  moduleshould  have  full  version  up  function  for  whole  system. +Kernel,  middle  ware  and  application  should  be  mass  updated.  System  structure  should  allow +mass  update. +There  should  be  mass  update  structure  for  kernel,  middle  ware  and  application. +If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +If  power  discontinuity  (forced  restart)  occurs  while  mass  update  of  kernel,  middle  ware  and +application,  the  status  (during  update)  should  be  detected  and  the  system  should  restart. +7.5  Device  Drivers +Device  drivers  may  be  in  kernel  space  or  user  space  or  a  combination  of  both. +**7.5.1  Peripherals** +Typical  IO  device  drivers  such  as  SPI,  USB,  memory,  I2C  that  are  typically  present  on  a  SOC. +The  flash  process  must  be  robust  with  an  endurance  of  more  than  10k  write/erase  cycles  and +data  retention  over  15-years/10  ppm,  assuming  application  specific  worst-case  conditions.  For +optimised  timing  for  downloading  and  restoring  data  the  programming  access  time  shall  be  less +than  50  s/byte  average. +The  EEPROM  process  must  be  robust  with  an  endurance  of  more  than  100k  write/erase  cycles +and  data  retention  over  15  years/10ppm.  Higher  programming  voltage  than  5  V  for  Flash  or +EEPROM  is  not  allowed. +Page  157  of  159 +![](media/picture274.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +In  applications  that  need  to  save  data  at  power  down,  the  programming  access  time  must  be +fast.  (target  <1ms/byte) +N.B.  EEPROM  functionality  can  be  emulated  in  flash  memory  passing  the  requirements  above. +**7.5.2  Graphics  Drivers** +Graphics  drivers  provide  the  interface  to  the  graphical  resources  (e.g.,  GPU)  within  the  system. +This  may  include  on-board  graphical  resources  or  a  separate  GPU  from  the  main  SOC. +**7.5.3  Video  Drivers** +Video  codecs  allow  the  system  to  decode  and/or  encode  video  for  playback  or  recording.  Video +codecs  will  nearly  always  be  hardware  based. +**7.5.3.1  Requirements** +The  system  shall  provide  device  drivers  to  access  any  hardware  implementation  of  video +functionality. +**7.5.4  Audio  Codecs** +**7.5.4.1  Requirements** +Automotive  Grade  Linux  BSPs  shall  provide  devices  drivers  to  access  audio  codecs  that  are +implemented  in  hardware. +Automotive  Grade  Linux  BSPs  should  provide  software  implementations  for  those  audio  codecs +that  are  required  for  AGL-based  products  and  not  supported  in  hardware. +**7.5.5  Automotive  Devices** +Device  drivers  for  automotive  related  devices.  This  may  includes  buses  such  as  CAN,  MOST,  or +*LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be* +Page  158  of  159 +![](media/picture275.jpeg)Automotive Grade Linux Requirements Spec v1.0 +May  28,  2015 +required  to  directly  interface  to  sensors  that  may  not  be  on  the  bus  such  as  gyros  used  for +navigation  or  an  air  bag  sensor  for  a  telematics  system. +**8   Notices** +Linux  is  a  registered  trademark  of  Linus  Torvalds. +The  Linux  Foundation  and  Yocto  Project  are  registered  trademarks  of  The  Linux  Foundation. +Bluetooth  is  a  registered  trademark  of  the  Bluetooth  SIG  Inc. +Miracast  is  a  registered  trademark  of  the  Wi-Fi  Alliance. +MirrorLink  is  a  certification  mark  of  the  Car  Connectivity  Consortium. +AirPlay  is  a  trademark  of  Apple,  Inc. +Page  159  of  159 diff --git a/docs/agl-specs-v1.0/04-app-fw.md b/docs/agl-specs-v1.0/04-app-fw.md new file mode 100644 index 0000000..c88cb04 --- /dev/null +++ b/docs/agl-specs-v1.0/04-app-fw.md @@ -0,0 +1,1499 @@ +--- + +title : Application Framwork +author: imported from Doors-ng by Fulup(iot.bzh) +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +## Application   Framework   Layer +The  Application  Framework  layer  provides  the  methods  needed  to  create  software  applications +and  their  user  interfaces.  The  platform  can  support  multiple  application  frameworks  any  of +which  may  be  built  into  an  SDK  or  product  build.  The  application  framework  contains  any  code +specifically  written  for  that  framework  as  well  the  bindings  to  the  Services  and  Operating +Systems  layers  that  the  application  framework  provides  for  its  applications. +4.1  AGL  Application  Framework +The  AGL  Application  Framework  provides  basic  services  to  all  applications  regardless  of  the +framework  they  are  implemented  in  so  that  there  is  a  standard  method  providing  the  services. +Page  20  of  159 + +Automotive Grade Linux Requirements Spec v1.0 ![](../media/picture114.jpeg) +{: class="image"} + +May  28,  2015 + +### Application  Manager +Application  Manager  describes  requirements  for  AGL  application  lifecycle  function.  Application +lifecycle  contains  application  installation/removal  and  launch/hide/resume/kill. + +### 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. + +### 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 + +#### Use Case +Please  refer  “screen  resource  control”  of  Policy  Manger  section. + +#### 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 +#### 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. diff --git a/docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css b/docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css new file mode 100755 index 0000000..65ae26b --- /dev/null +++ b/docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.css @@ -0,0 +1,37230 @@ + + +.table_class1DeffCell +{ +border-bottom-color: #FFFFFF; +border-top-color: #FFFFFF; +border-right-color: #FFFFFF; +border-left-color: #FFFFFF; +border-top-style: solid; +border-left-style: solid; +border-right-style: solid; +border-bottom-style: solid; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +border-bottom-width: 1px; +} +.table_class77DeffCell +{ +border-bottom-color: #000000; +border-top-color: #000000; +border-right-color: #000000; +border-left-color: #000000; +border-top-style: solid; +border-left-style: solid; +border-right-style: solid; +border-bottom-style: solid; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +border-bottom-width: 1px; +} +.table_class266DeffCell +{ +border-bottom-color: #000000; +border-top-color: #000000; +border-right-color: #000000; +border-left-color: #000000; +border-top-style: solid; +border-left-style: solid; +border-right-style: solid; +border-bottom-style: solid; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +border-bottom-width: 1px; +} + +.Body +{ +font-weight: normal; +color: #000000; +font-family: Trebuchet MS; +font-size: 11px; +} + +.Prefix +{ +color: #000000; +font-family: Trebuchet MS; +font-size: 9px; +} + +.LabelItalic +{ +font-style: italic; +text-decoration: underline; +} + +.LabelStrong +{ +font-weight: bold; +text-decoration: underline; +} + +.HeaderCell +{ +border-bottom-color: #999999; +border-left-color: #FFFFFF; +border-right-color: #FFFFFF; +border-top-color: #FFFFFF; +border-left-style: none; +border-right-style: none; +border-top-style: none; +color: #666666; +font-family: Arial; +font-size: 9px; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +} + +.BodyCell +{ +border-bottom-color: #e5e5e5; +border-left-color: #FFFFFF; +border-right-color: #FFFFFF; +border-top-color: #FFFFFF; +border-left-style: none; +border-right-style: none; +border-top-style: none; +color: #222222; +font-family: Arial; +font-size: 9px; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +} + +.SubTotalCell +{ +border-bottom-color: #e5e5e5; +border-left-color: #FFFFFF; +border-right-color: #FFFFFF; +border-top-color: #FFFFFF; +border-left-style: none; +border-right-style: none; +border-top-style: none; +font-weight: bold; +color: #666666; +font-family: Arial; +font-size: 9px; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +} + +.TotalCell +{ +border-bottom-color: #e5e5e5; +border-left-color: #FFFFFF; +border-right-color: #FFFFFF; +border-top-color: #FFFFFF; +border-left-style: none; +border-right-style: none; +border-top-style: none; +font-weight: bold; +color: #222222; +font-family: Arial; +font-size: 9px; +border-top-width: 1px; +border-left-width: 1px; +border-right-width: 1px; +} + +.Hyperlink +{ +color: #3087B3; +} + +.Normal +{ +color: #222222; +font-family: Arial; +font-size: 10px; +} + +.Header +{ +color: #222222; +font-family: Arial; +font-size: 10px; +} + +.Title +{ +text-align: right; +font-weight: bold; +font-size: 18px; +} + +.SubTitle +{ +text-align: right; +color: #222222; +font-family: Arial; +font-size: 16px; +} + +.TableOfContents +{ +color: #222222; +font-family: Arial; +font-size: 14px; +color: #008A52; +font-family: Arial; +font-size: 18px; +} + +.InternalHyperlink +{ +color: #3087B3; +color: #3087B3; +} + +.Figure +{ +color: #222222; +font-family: Arial; +font-size: 9px; +text-align: center; +color: #222222; +font-family: Arial; +font-size: 11px; +} + +.Footer +{ +color: #222222; +font-family: Arial; +font-size: 10px; +color: #222222; +font-family: Arial; +font-size: 10px; +color: #222222; +font-family: Arial; +font-size: 10px; +} + +.LogoImage +{ +align: right; +} + +.table_of_contents2c9377fb-ce44-48bb-ab81-2b2ad4709e9f +{ +} + +.table_class1 +{ +border-collapse: collapse; +width: 100%; +} + +.row_class2 +{ +} + +.cell_class3 +{ +text-align: left; +vertical-align: center; +width: 250px; +} + +.text_class5 +{ +} + +.cell_class6 +{ +text-align: right; +vertical-align: center; +width: 250px; +} + +.text_class8 +{ +} + +.cell_class4 +{ +width: 250px; +} + +.cell_class7 +{ +width: 250px; +} + +.cell_class9 +{ +text-align: left; +vertical-align: center; +width: 150px; +} + +.cell_class11 +{ +text-align: center; +vertical-align: center; +width: 150px; +} + +.text_class13 +{ +} + +.text_class14 +{ +} + +.text_class15 +{ +} + +.text_class16 +{ +} + +.text_class17 +{ +} + +.cell_class18 +{ +text-align: right; +vertical-align: center; +width: 150px; +} + +.text_class20 +{ +} + +.cell_class10 +{ +width: 150px; +} + +.cell_class12 +{ +width: 150px; +} + +.cell_class19 +{ +width: 150px; +} + +.paragraph_class21 +{ +} + +.text_class22 +{ +} + +.paragraph_class23 +{ +} + +.text_class24 +{ +} + +.text_class25 +{ +} + +.text_class26 +{ +} + +.text_class27 +{ +} + +.text_class28 +{ +} + +.text_class29 +{ +} + +.text_class30 +{ +} + +.text_class31 +{ +} + +.text_class32 +{ +} + +.text_class33 +{ +} + +.paragraph_class34 +{ +} + +.text_class35 +{ +} + +.text_class36 +{ +} + +.paragraph_class37 +{ +} + +.text_class38 +{ +} + +.paragraph_class39 +{ +} + +.text_class40 +{ +font-size: 11px; +} + +.text_class41 +{ +} + +.hyperlink_class42 +{ +} + +.hyperlink_class43 +{ +} + +.paragraph_class44 +{ +} + +.paragraph_class45 +{ +} + +.text_class46 +{ +font-size: 11px; +} + +.hyperlink_class47 +{ +} + +.list_class48 +{ +list-style-type: disc; +} + +.list_detail_class49 +{ +} + +.text_class50 +{ +font-size: 11px; +} + +.text_class51 +{ +font-size: 11px; +} + +.paragraph_class52 +{ +} + +.paragraph_class53 +{ +} + +.text_class54 +{ +font-size: 11px; +} + +.text_class55 +{ +font-size: 11px; +} + +.text_class56 +{ +font-size: 11px; +} + +.text_class57 +{ +font-size: 11px; +} + +.text_class58 +{ +font-size: 11px; +} + +.paragraph_class59 +{ +} + +.text_class60 +{ +font-size: 11px; +} + +.text_class61 +{ +} + +.text_class62 +{ +} + +.paragraph_class63 +{ +} + +.text_class64 +{ +font-size: 11px; +} + +.text_class65 +{ +font-size: 11px; +} + +.text_class66 +{ +font-size: 11px; +} + +.paragraph_class67 +{ +} + +.paragraph_class68 +{ +} + +.text_class69 +{ +font-size: 11px; +} + +.paragraph_class70 +{ +} + +.paragraph_class71 +{ +} + +.text_class72 +{ +font-size: 11px; +} + +.text_class73 +{ +font-size: 11px; +} + +.text_class74 +{ +} + +.text_class75 +{ +} + +.paragraph_class76 +{ +} + +.table_class77 +{ +border-collapse: collapse; +} + +.row_class78 +{ +} + +.cell_class79 +{ +width: 115px; +background-color: #999999; +} + +.text_class81 +{ +} + +.text_class82 +{ +font-size: 11px; +} + +.text_class83 +{ +font-weight: bold; +} + +.cell_class84 +{ +width: 448px; +background-color: #999999; +} + +.text_class86 +{ +font-size: 11px; +} + +.text_class87 +{ +font-weight: bold; +} + +.cell_class88 +{ +width: 115px; +} + +.paragraph_class89 +{ +} + +.text_class90 +{ +font-size: 11px; +} + +.cell_class91 +{ +width: 448px; +} + +.paragraph_class92 +{ +} + +.text_class93 +{ +font-size: 11px; +} + +.paragraph_class94 +{ +} + +.text_class95 +{ +font-size: 11px; +} + +.paragraph_class96 +{ +} + +.text_class97 +{ +font-size: 11px; +} + +.paragraph_class98 +{ +} + +.text_class99 +{ +font-size: 11px; +} + +.paragraph_class100 +{ +} + +.text_class101 +{ +font-size: 11px; +} + +.paragraph_class102 +{ +} + +.text_class103 +{ +font-size: 11px; +} + +.paragraph_class104 +{ +} + +.text_class105 +{ +font-size: 11px; +} + +.paragraph_class106 +{ +} + +.text_class107 +{ +font-size: 11px; +} + +.paragraph_class108 +{ +} + +.text_class109 +{ +font-size: 11px; +} + +.paragraph_class110 +{ +} + +.text_class111 +{ +font-size: 11px; +} + +.paragraph_class112 +{ +} + +.text_class113 +{ +font-size: 11px; +} + +.paragraph_class114 +{ +} + +.text_class115 +{ +font-size: 11px; +} + +.paragraph_class116 +{ +} + +.text_class117 +{ +font-size: 11px; +} + +.paragraph_class118 +{ +} + +.text_class119 +{ +font-size: 11px; +} + +.paragraph_class120 +{ +} + +.text_class121 +{ +font-size: 11px; +} + +.paragraph_class122 +{ +} + +.text_class123 +{ +font-size: 11px; +} + +.paragraph_class124 +{ +} + +.text_class125 +{ +font-size: 11px; +} + +.paragraph_class126 +{ +} + +.text_class127 +{ +font-size: 11px; +} + +.paragraph_class128 +{ +} + +.text_class129 +{ +font-size: 11px; +} + +.paragraph_class130 +{ +} + +.text_class131 +{ +font-size: 11px; +} + +.paragraph_class132 +{ +} + +.text_class133 +{ +font-size: 11px; +} + +.paragraph_class134 +{ +} + +.text_class135 +{ +font-size: 11px; +} + +.paragraph_class136 +{ +} + +.text_class137 +{ +font-size: 11px; +} + +.paragraph_class138 +{ +} + +.text_class139 +{ +font-size: 11px; +} + +.paragraph_class140 +{ +} + +.text_class141 +{ +font-size: 11px; +} + +.paragraph_class142 +{ +} + +.text_class143 +{ +font-size: 11px; +} + +.paragraph_class144 +{ +} + +.text_class145 +{ +font-size: 11px; +} + +.paragraph_class146 +{ +} + +.text_class147 +{ +font-size: 11px; +} + +.paragraph_class148 +{ +} + +.text_class149 +{ +font-size: 11px; +} + +.paragraph_class150 +{ +} + +.text_class151 +{ +font-size: 11px; +} + +.paragraph_class152 +{ +} + +.text_class153 +{ +font-size: 11px; +} + +.text_class154 +{ +} + +.text_class155 +{ +} + +.paragraph_class156 +{ +} + +.text_class157 +{ +font-size: 11px; +} + +.paragraph_class158 +{ +} + +.text_class159 +{ +font-size: 11px; +} + +.paragraph_class160 +{ +} + +.text_class161 +{ +} + +.image_class162 +{ +} + +.text_class163 +{ +} + +.text_class164 +{ +} + +.paragraph_class165 +{ +} + +.text_class166 +{ +font-size: 11px; +} + +.text_class167 +{ +} + +.text_class168 +{ +} + +.paragraph_class169 +{ +} + +.text_class170 +{ +font-size: 11px; +} + +.text_class171 +{ +font-size: 11px; +} + +.text_class172 +{ +font-size: 11px; +} + +.text_class173 +{ +font-size: 11px; +} + +.paragraph_class174 +{ +} + +.paragraph_class175 +{ +} + +.text_class176 +{ +font-size: 11px; +} + +.text_class177 +{ +} + +.paragraph_class178 +{ +} + +.text_class179 +{ +} + +.paragraph_class180 +{ +} + +.text_class181 +{ +font-size: 11px; +} + +.text_class182 +{ +font-size: 11px; +} + +.paragraph_class183 +{ +} + +.paragraph_class184 +{ +} + +.paragraph_class185 +{ +} + +.text_class186 +{ +} + +.text_class187 +{ +} + +.paragraph_class188 +{ +} + +.text_class189 +{ +font-size: 11px; +} + +.text_class190 +{ +font-size: 11px; +} + +.text_class191 +{ +font-size: 11px; +} + +.text_class192 +{ +font-size: 11px; +} + +.text_class193 +{ +} + +.text_class194 +{ +} + +.paragraph_class195 +{ +} + +.text_class196 +{ +font-size: 11px; +} + +.text_class197 +{ +font-size: 11px; +} + +.text_class198 +{ +font-size: 11px; +} + +.text_class199 +{ +font-size: 11px; +} + +.text_class200 +{ +font-size: 11px; +} + +.text_class201 +{ +} + +.text_class202 +{ +} + +.paragraph_class203 +{ +} + +.text_class204 +{ +font-size: 11px; +} + +.text_class205 +{ +font-size: 11px; +} + +.text_class206 +{ +font-size: 11px; +} + +.text_class207 +{ +} + +.text_class208 +{ +} + +.paragraph_class209 +{ +} + +.text_class210 +{ +font-size: 11px; +} + +.text_class211 +{ +font-size: 11px; +} + +.text_class212 +{ +font-size: 11px; +} + +.text_class213 +{ +font-size: 11px; +} + +.paragraph_class214 +{ +} + +.paragraph_class215 +{ +} + +.text_class216 +{ +font-size: 11px; +} + +.paragraph_class217 +{ +} + +.text_class218 +{ +font-size: 11px; +} + +.paragraph_class219 +{ +} + +.text_class220 +{ +font-size: 11px; +} + +.paragraph_class221 +{ +} + +.text_class222 +{ +font-size: 11px; +} + +.paragraph_class223 +{ +} + +.text_class224 +{ +font-size: 11px; +} + +.paragraph_class225 +{ +} + +.text_class226 +{ +font-size: 11px; +} + +.paragraph_class227 +{ +} + +.text_class228 +{ +font-size: 11px; +} + +.paragraph_class229 +{ +} + +.text_class230 +{ +font-size: 11px; +} + +.paragraph_class231 +{ +} + +.text_class232 +{ +font-size: 11px; +} + +.paragraph_class233 +{ +} + +.text_class234 +{ +font-size: 11px; +} + +.paragraph_class235 +{ +} + +.paragraph_class236 +{ +} + +.text_class237 +{ +font-size: 11px; +} + +.text_class238 +{ +} + +.text_class239 +{ +} + +.text_class240 +{ +} + +.paragraph_class241 +{ +} + +.text_class242 +{ +font-size: 11px; +} + +.text_class243 +{ +font-size: 11px; +} + +.text_class244 +{ +font-size: 11px; +} + +.text_class245 +{ +font-size: 11px; +} + +.text_class246 +{ +font-size: 11px; +} + +.paragraph_class247 +{ +} + +.paragraph_class248 +{ +} + +.text_class249 +{ +font-size: 11px; +} + +.text_class250 +{ +font-size: 11px; +} + +.paragraph_class251 +{ +} + +.text_class252 +{ +font-size: 11px; +} + +.text_class253 +{ +font-size: 11px; +} + +.text_class254 +{ +font-size: 11px; +} + +.text_class255 +{ +font-size: 11px; +} + +.text_class256 +{ +font-size: 11px; +} + +.paragraph_class257 +{ +} + +.paragraph_class258 +{ +} + +.text_class259 +{ +font-size: 11px; +} + +.text_class260 +{ +} + +.text_class261 +{ +} + +.text_class262 +{ +} + +.paragraph_class263 +{ +} + +.text_class264 +{ +font-size: 11px; +} + +.text_class265 +{ +} + +.table_class266 +{ +border-collapse: collapse; +} + +.cell_class267 +{ +text-align: center; +vertical-align: center; +width: 47px; +background-color: #bfbfbf; +} + +.paragraph_class269 +{ +margin-left: 0px; +} + +.text_class270 +{ +font-size: 11px; +font-family: arial; +} + +.text_class271 +{ +font-weight: bold; +} + +.cell_class272 +{ +text-align: center; +vertical-align: center; +width: 154px; +background-color: #bfbfbf; +} + +.paragraph_class274 +{ +margin-left: 0px; +} + +.text_class275 +{ +font-size: 11px; +font-family: arial; +} + +.text_class276 +{ +font-weight: bold; +} + +.cell_class277 +{ +text-align: center; +vertical-align: center; +width: 138px; +background-color: #bfbfbf; +} + +.paragraph_class279 +{ +margin-left: 0px; +} + +.text_class280 +{ +font-size: 11px; +font-family: arial; +} + +.text_class281 +{ +font-weight: bold; +} + +.cell_class282 +{ +text-align: center; +vertical-align: center; +width: 236px; +background-color: #bfbfbf; +} + +.paragraph_class284 +{ +margin-left: 0px; +} + +.text_class285 +{ +font-size: 11px; +font-family: arial; +} + +.text_class286 +{ +font-weight: bold; +} + +.cell_class287 +{ +width: 47px; +} + +.paragraph_class288 +{ +margin-left: 0px; +} + +.text_class289 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class290 +{ +width: 154px; +} + +.paragraph_class291 +{ +margin-left: 0px; +} + +.text_class292 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class293 +{ +margin-left: 0px; +} + +.cell_class294 +{ +width: 138px; +} + +.paragraph_class295 +{ +margin-left: 0px; +} + +.text_class296 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class297 +{ +margin-left: 0px; +} + +.text_class298 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class299 +{ +width: 236px; +} + +.paragraph_class300 +{ +margin-left: 0px; +} + +.text_class301 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class302 +{ +margin-left: 0px; +} + +.text_class303 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class304 +{ +margin-left: 0px; +} + +.text_class305 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class306 +{ +margin-left: 0px; +} + +.text_class307 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class308 +{ +margin-left: 0px; +} + +.text_class309 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class310 +{ +width: 154px; +} + +.paragraph_class311 +{ +margin-left: 0px; +} + +.text_class312 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class313 +{ +margin-left: 0px; +} + +.paragraph_class314 +{ +margin-left: 0px; +} + +.text_class315 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class316 +{ +margin-left: 0px; +} + +.text_class317 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class318 +{ +margin-left: 0px; +} + +.text_class319 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class320 +{ +margin-left: 0px; +} + +.text_class321 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class322 +{ +margin-left: 0px; +} + +.text_class323 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class324 +{ +margin-left: 0px; +} + +.text_class325 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class326 +{ +margin-left: 0px; +} + +.text_class327 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class328 +{ +margin-left: 0px; +} + +.text_class329 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class330 +{ +margin-left: 0px; +} + +.text_class331 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class332 +{ +margin-left: 0px; +} + +.text_class333 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class334 +{ +margin-left: 0px; +} + +.text_class335 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class336 +{ +margin-left: 0px; +} + +.text_class337 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class338 +{ +margin-left: 0px; +} + +.text_class339 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class340 +{ +margin-left: 0px; +} + +.text_class341 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class342 +{ +margin-left: 0px; +} + +.text_class343 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class344 +{ +margin-left: 0px; +} + +.paragraph_class345 +{ +margin-left: 0px; +} + +.text_class346 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class347 +{ +margin-left: 0px; +} + +.text_class348 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class349 +{ +margin-left: 0px; +} + +.text_class350 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class351 +{ +margin-left: 0px; +} + +.text_class352 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class353 +{ +margin-left: 0px; +} + +.text_class354 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class355 +{ +margin-left: 0px; +} + +.text_class356 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class357 +{ +margin-left: 0px; +} + +.text_class358 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class359 +{ +width: 154px; +} + +.paragraph_class360 +{ +margin-left: 0px; +} + +.text_class361 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class362 +{ +margin-left: 0px; +} + +.text_class363 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class364 +{ +margin-left: 0px; +} + +.paragraph_class365 +{ +margin-left: 0px; +} + +.text_class366 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class367 +{ +margin-left: 0px; +} + +.text_class368 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class369 +{ +margin-left: 0px; +} + +.text_class370 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class371 +{ +margin-left: 0px; +} + +.text_class372 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class373 +{ +margin-left: 0px; +} + +.text_class374 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class375 +{ +margin-left: 0px; +} + +.text_class376 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class377 +{ +margin-left: 0px; +} + +.text_class378 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class379 +{ +margin-left: 0px; +} + +.text_class380 +{ +font-size: 11px; +font-family: arial; +} + +.text_class381 +{ +} + +.paragraph_class382 +{ +text-align: center; +margin-left: 0px; +} + +.text_class383 +{ +font-size: 11px; +font-family: arial; +} + +.text_class384 +{ +font-weight: bold; +} + +.text_class385 +{ +} + +.cell_class386 +{ +text-align: center; +vertical-align: center; +width: 46px; +background-color: #bfbfbf; +} + +.paragraph_class388 +{ +margin-left: 0px; +} + +.text_class389 +{ +font-size: 11px; +font-family: arial; +} + +.text_class390 +{ +font-weight: bold; +} + +.cell_class391 +{ +text-align: center; +vertical-align: center; +width: 196px; +background-color: #bfbfbf; +} + +.paragraph_class393 +{ +margin-left: 0px; +} + +.text_class394 +{ +font-size: 11px; +font-family: arial; +} + +.text_class395 +{ +font-weight: bold; +} + +.cell_class396 +{ +text-align: center; +vertical-align: center; +width: 110px; +background-color: #bfbfbf; +} + +.paragraph_class398 +{ +margin-left: 0px; +} + +.text_class399 +{ +font-size: 11px; +font-family: arial; +} + +.text_class400 +{ +font-weight: bold; +} + +.paragraph_class402 +{ +margin-left: 0px; +} + +.text_class403 +{ +font-size: 11px; +font-family: arial; +} + +.text_class404 +{ +font-weight: bold; +} + +.paragraph_class406 +{ +margin-left: 0px; +} + +.text_class407 +{ +font-size: 11px; +font-family: arial; +} + +.text_class408 +{ +font-weight: bold; +} + +.cell_class409 +{ +width: 46px; +} + +.paragraph_class410 +{ +margin-left: 0px; +} + +.text_class411 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class412 +{ +width: 196px; +} + +.paragraph_class413 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class414 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class415 +{ +width: 110px; +} + +.paragraph_class416 +{ +text-align: center; +margin-left: 0px; +} + +.text_class417 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class418 +{ +text-align: center; +margin-left: 0px; +} + +.text_class419 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class420 +{ +text-align: center; +margin-left: 0px; +} + +.text_class421 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class422 +{ +margin-left: 0px; +} + +.text_class423 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class424 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class425 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class426 +{ +text-align: center; +margin-left: 0px; +} + +.text_class427 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class428 +{ +text-align: center; +margin-left: 0px; +} + +.text_class429 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class430 +{ +text-align: center; +margin-left: 0px; +} + +.text_class431 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class432 +{ +margin-left: 0px; +} + +.text_class433 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class434 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class435 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class436 +{ +text-align: center; +margin-left: 0px; +} + +.text_class437 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class438 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class439 +{ +text-align: center; +margin-left: 0px; +} + +.text_class440 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class441 +{ +margin-left: 0px; +} + +.text_class442 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class443 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class444 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class445 +{ +text-align: center; +margin-left: 0px; +} + +.text_class446 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class447 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class448 +{ +text-align: center; +margin-left: 0px; +} + +.text_class449 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class450 +{ +margin-left: 0px; +} + +.text_class451 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class452 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class453 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class454 +{ +text-align: center; +margin-left: 0px; +} + +.text_class455 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class456 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class457 +{ +text-align: center; +margin-left: 0px; +} + +.text_class458 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class459 +{ +margin-left: 0px; +} + +.text_class460 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class461 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class462 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class463 +{ +text-align: center; +margin-left: 0px; +} + +.text_class464 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class465 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class466 +{ +text-align: center; +margin-left: 0px; +} + +.text_class467 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class468 +{ +margin-left: 0px; +} + +.text_class469 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class470 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class471 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class472 +{ +text-align: center; +margin-left: 0px; +} + +.text_class473 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class474 +{ +text-align: center; +margin-left: 0px; +} + +.text_class475 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class476 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class477 +{ +margin-left: 0px; +} + +.text_class478 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class479 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class480 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class481 +{ +text-align: center; +margin-left: 0px; +} + +.text_class482 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class483 +{ +text-align: center; +margin-left: 0px; +} + +.text_class484 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class485 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class486 +{ +margin-left: 0px; +} + +.text_class487 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class488 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class489 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class490 +{ +text-align: center; +margin-left: 0px; +} + +.text_class491 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class492 +{ +text-align: center; +margin-left: 0px; +} + +.text_class493 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class494 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class495 +{ +margin-left: 0px; +} + +.text_class496 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class497 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class498 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class499 +{ +text-align: center; +margin-left: 0px; +} + +.text_class500 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class501 +{ +text-align: center; +margin-left: 0px; +} + +.text_class502 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class503 +{ +text-align: center; +margin-left: 0px; +} + +.paragraph_class504 +{ +margin-left: 0px; +} + +.text_class505 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class506 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class507 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class508 +{ +text-align: center; +margin-left: 0px; +} + +.text_class509 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class510 +{ +text-align: center; +margin-left: 0px; +} + +.text_class511 +{ +font-size: 11px; +font-family: courier new; +} + +.paragraph_class512 +{ +text-align: center; +margin-left: 0px; +} + +.text_class513 +{ +} + +.text_class514 +{ +} + +.paragraph_class515 +{ +} + +.text_class516 +{ +} + +.paragraph_class517 +{ +} + +.text_class518 +{ +font-family: arial; +} + +.text_class519 +{ +font-size: 11px; +} + +.paragraph_class520 +{ +} + +.text_class521 +{ +font-family: arial; +} + +.text_class522 +{ +font-size: 11px; +} + +.paragraph_class523 +{ +} + +.text_class524 +{ +font-family: arial; +} + +.text_class525 +{ +font-size: 11px; +} + +.text_class526 +{ +font-family: arial; +} + +.text_class527 +{ +font-size: 11px; +} + +.text_class528 +{ +font-family: arial; +} + +.text_class529 +{ +font-size: 11px; +} + +.text_class530 +{ +font-family: arial; +} + +.text_class531 +{ +font-size: 11px; +} + +.text_class532 +{ +font-family: arial; +} + +.text_class533 +{ +font-size: 11px; +} + +.text_class534 +{ +font-family: arial; +} + +.text_class535 +{ +font-size: 11px; +} + +.paragraph_class536 +{ +} + +.text_class537 +{ +font-family: arial; +} + +.text_class538 +{ +font-size: 11px; +} + +.text_class539 +{ +font-family: arial; +} + +.text_class540 +{ +font-size: 11px; +} + +.text_class541 +{ +font-family: arial; +} + +.text_class542 +{ +font-size: 11px; +} + +.text_class543 +{ +font-family: arial; +} + +.text_class544 +{ +font-size: 11px; +} + +.text_class545 +{ +font-family: arial; +} + +.text_class546 +{ +font-size: 11px; +} + +.text_class547 +{ +font-family: arial; +} + +.text_class548 +{ +font-size: 11px; +} + +.text_class549 +{ +font-family: arial; +} + +.text_class550 +{ +font-size: 11px; +} + +.text_class551 +{ +font-family: arial; +} + +.text_class552 +{ +font-size: 11px; +} + +.text_class553 +{ +} + +.paragraph_class554 +{ +} + +.text_class555 +{ +font-family: arial; +} + +.text_class556 +{ +font-size: 11px; +} + +.text_class557 +{ +} + +.text_class558 +{ +} + +.paragraph_class559 +{ +} + +.text_class560 +{ +font-family: arial; +} + +.text_class561 +{ +font-size: 11px; +} + +.text_class562 +{ +} + +.paragraph_class563 +{ +margin-left: 0px; +} + +.text_class564 +{ +font-family: arial; +} + +.text_class565 +{ +font-size: 11px; +} + +.text_class566 +{ +font-family: arial; +} + +.text_class567 +{ +font-size: 11px; +} + +.text_class568 +{ +font-family: arial; +} + +.text_class569 +{ +font-size: 11px; +} + +.text_class570 +{ +font-family: arial; +} + +.text_class571 +{ +font-size: 11px; +} + +.text_class572 +{ +font-family: arial; +} + +.text_class573 +{ +font-size: 11px; +} + +.text_class574 +{ +font-family: arial; +} + +.text_class575 +{ +font-size: 11px; +} + +.text_class576 +{ +} + +.paragraph_class577 +{ +} + +.text_class578 +{ +font-family: arial; +} + +.text_class579 +{ +font-size: 11px; +} + +.text_class580 +{ +} + +.paragraph_class581 +{ +} + +.text_class582 +{ +font-family: arial; +} + +.text_class583 +{ +font-size: 11px; +} + +.text_class584 +{ +} + +.paragraph_class585 +{ +margin-left: 0px; +} + +.text_class586 +{ +font-family: arial; +} + +.text_class587 +{ +font-size: 11px; +} + +.paragraph_class588 +{ +} + +.text_class589 +{ +font-family: arial; +} + +.text_class590 +{ +font-size: 11px; +} + +.text_class591 +{ +} + +.paragraph_class592 +{ +} + +.text_class593 +{ +font-family: arial; +} + +.text_class594 +{ +font-size: 11px; +} + +.text_class595 +{ +} + +.paragraph_class596 +{ +} + +.text_class597 +{ +font-family: arial; +} + +.text_class598 +{ +font-size: 11px; +} + +.text_class599 +{ +} + +.paragraph_class600 +{ +} + +.text_class601 +{ +font-family: arial; +} + +.text_class602 +{ +font-size: 11px; +} + +.text_class603 +{ +} + +.paragraph_class604 +{ +} + +.text_class605 +{ +font-family: arial; +} + +.text_class606 +{ +font-size: 11px; +} + +.text_class607 +{ +} + +.paragraph_class608 +{ +} + +.text_class609 +{ +font-family: arial; +} + +.text_class610 +{ +font-size: 11px; +} + +.text_class611 +{ +} + +.paragraph_class612 +{ +} + +.text_class613 +{ +font-family: arial; +} + +.text_class614 +{ +font-size: 11px; +} + +.text_class615 +{ +} + +.paragraph_class616 +{ +} + +.text_class617 +{ +font-family: arial; +} + +.text_class618 +{ +font-size: 11px; +} + +.text_class619 +{ +} + +.paragraph_class620 +{ +} + +.text_class621 +{ +font-family: arial; +} + +.text_class622 +{ +font-size: 11px; +} + +.text_class623 +{ +} + +.text_class624 +{ +font-family: arial; +} + +.text_class625 +{ +font-size: 11px; +} + +.text_class626 +{ +font-family: arial; +} + +.text_class627 +{ +font-size: 11px; +} + +.text_class628 +{ +font-family: arial; +} + +.text_class629 +{ +font-size: 11px; +} + +.text_class630 +{ +} + +.paragraph_class631 +{ +} + +.text_class632 +{ +font-family: arial; +} + +.text_class633 +{ +font-size: 11px; +} + +.text_class634 +{ +} + +.paragraph_class635 +{ +} + +.text_class636 +{ +font-family: arial; +} + +.text_class637 +{ +font-size: 11px; +} + +.text_class638 +{ +font-family: arial; +} + +.text_class639 +{ +font-size: 11px; +} + +.text_class640 +{ +font-family: arial; +} + +.text_class641 +{ +font-size: 11px; +} + +.text_class642 +{ +font-family: arial; +} + +.text_class643 +{ +font-size: 11px; +} + +.text_class644 +{ +font-family: arial; +} + +.text_class645 +{ +font-size: 11px; +} + +.text_class646 +{ +font-family: arial; +} + +.text_class647 +{ +font-size: 11px; +} + +.text_class648 +{ +} + +.paragraph_class649 +{ +} + +.text_class650 +{ +font-family: arial; +} + +.text_class651 +{ +font-size: 11px; +} + +.text_class652 +{ +font-family: arial; +} + +.text_class653 +{ +font-size: 11px; +} + +.text_class654 +{ +font-family: arial; +} + +.text_class655 +{ +font-size: 11px; +} + +.text_class656 +{ +font-family: arial; +} + +.text_class657 +{ +font-size: 11px; +} + +.text_class658 +{ +font-family: arial; +} + +.text_class659 +{ +font-size: 11px; +} + +.text_class660 +{ +} + +.paragraph_class661 +{ +margin-left: 0px; +} + +.text_class662 +{ +font-family: arial; +} + +.text_class663 +{ +font-size: 11px; +} + +.paragraph_class664 +{ +margin-left: 0px; +} + +.text_class665 +{ +font-family: arial; +} + +.text_class666 +{ +font-size: 11px; +} + +.text_class667 +{ +font-family: arial; +} + +.text_class668 +{ +font-size: 11px; +} + +.text_class669 +{ +font-family: arial; +} + +.text_class670 +{ +font-size: 11px; +} + +.text_class671 +{ +font-family: arial; +} + +.text_class672 +{ +font-size: 11px; +} + +.text_class673 +{ +font-family: arial; +} + +.text_class674 +{ +font-size: 11px; +} + +.text_class675 +{ +} + +.paragraph_class676 +{ +} + +.text_class677 +{ +font-family: arial; +} + +.text_class678 +{ +font-size: 11px; +} + +.text_class679 +{ +} + +.paragraph_class680 +{ +} + +.text_class681 +{ +font-family: arial; +} + +.text_class682 +{ +font-size: 11px; +} + +.text_class683 +{ +} + +.paragraph_class684 +{ +} + +.text_class685 +{ +font-family: arial; +} + +.text_class686 +{ +font-size: 11px; +} + +.text_class687 +{ +} + +.paragraph_class688 +{ +} + +.text_class689 +{ +font-family: arial; +} + +.text_class690 +{ +font-size: 11px; +} + +.text_class691 +{ +} + +.text_class692 +{ +} + +.paragraph_class693 +{ +margin-left: 0px; +} + +.text_class694 +{ +font-family: arial; +} + +.text_class695 +{ +font-size: 11px; +} + +.text_class696 +{ +font-family: arial; +} + +.text_class697 +{ +font-size: 11px; +} + +.text_class698 +{ +font-family: arial; +} + +.text_class699 +{ +font-size: 11px; +} + +.text_class700 +{ +font-family: arial; +} + +.text_class701 +{ +font-size: 11px; +} + +.text_class702 +{ +font-family: arial; +} + +.text_class703 +{ +font-size: 11px; +} + +.text_class704 +{ +font-family: arial; +} + +.text_class705 +{ +font-size: 11px; +} + +.text_class706 +{ +font-family: arial; +} + +.text_class707 +{ +font-size: 11px; +} + +.text_class708 +{ +} + +.paragraph_class709 +{ +margin-left: 0px; +} + +.text_class710 +{ +font-family: arial; +} + +.text_class711 +{ +font-size: 11px; +} + +.paragraph_class712 +{ +} + +.text_class713 +{ +font-family: arial; +} + +.text_class714 +{ +font-size: 11px; +} + +.text_class715 +{ +} + +.text_class716 +{ +} + +.paragraph_class717 +{ +margin-left: 0px; +} + +.text_class718 +{ +font-family: arial; +} + +.text_class719 +{ +font-size: 11px; +} + +.paragraph_class720 +{ +margin-left: 0px; +} + +.text_class721 +{ +font-family: arial; +} + +.text_class722 +{ +font-size: 11px; +} + +.text_class723 +{ +font-family: arial; +} + +.text_class724 +{ +font-size: 11px; +} + +.text_class725 +{ +font-family: arial; +} + +.text_class726 +{ +font-size: 11px; +} + +.text_class727 +{ +font-family: arial; +} + +.text_class728 +{ +font-size: 11px; +} + +.text_class729 +{ +font-family: arial; +} + +.text_class730 +{ +font-size: 11px; +} + +.text_class731 +{ +} + +.paragraph_class732 +{ +} + +.text_class733 +{ +font-family: arial; +} + +.text_class734 +{ +font-size: 11px; +} + +.text_class735 +{ +} + +.paragraph_class736 +{ +} + +.text_class737 +{ +font-family: arial; +} + +.text_class738 +{ +font-size: 11px; +} + +.text_class739 +{ +} + +.paragraph_class740 +{ +} + +.text_class741 +{ +font-family: arial; +} + +.text_class742 +{ +font-size: 11px; +} + +.paragraph_class743 +{ +} + +.text_class744 +{ +font-family: arial; +} + +.text_class745 +{ +font-size: 11px; +} + +.text_class746 +{ +} + +.text_class747 +{ +} + +.paragraph_class748 +{ +} + +.text_class749 +{ +font-size: 11px; +} + +.paragraph_class750 +{ +} + +.text_class751 +{ +} + +.text_class752 +{ +} + +.paragraph_class753 +{ +} + +.text_class754 +{ +font-size: 11px; +} + +.text_class755 +{ +} + +.text_class756 +{ +} + +.paragraph_class757 +{ +} + +.text_class758 +{ +font-size: 11px; +} + +.text_class759 +{ +} + +.text_class760 +{ +} + +.paragraph_class761 +{ +} + +.text_class762 +{ +font-family: arial; +} + +.text_class763 +{ +font-size: 10px; +} + +.text_class764 +{ +} + +.paragraph_class765 +{ +} + +.text_class766 +{ +font-family: arial; +} + +.text_class767 +{ +} + +.paragraph_class768 +{ +} + +.text_class769 +{ +font-size: 10px; +font-family: arial; +} + +.text_class770 +{ +} + +.paragraph_class771 +{ +} + +.text_class772 +{ +} + +.paragraph_class773 +{ +} + +.text_class774 +{ +} + +.text_class775 +{ +} + +.paragraph_class776 +{ +} + +.text_class777 +{ +} + +.paragraph_class778 +{ +margin-left: 0px; +} + +.text_class779 +{ +font-size: 11px; +font-family: arial; +} + +.text_class780 +{ +} + +.paragraph_class781 +{ +margin-left: 0px; +} + +.text_class782 +{ +font-size: 11px; +font-family: arial; +} + +.text_class783 +{ +} + +.text_class784 +{ +font-size: 11px; +} + +.text_class785 +{ +} + +.paragraph_class786 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class787 +{ +font-size: 11px; +font-family: arial; +} + +.text_class788 +{ +} + +.text_class789 +{ +font-size: 11px; +} + +.text_class790 +{ +} + +.paragraph_class791 +{ +margin-left: 0px; +} + +.text_class792 +{ +font-size: 11px; +font-family: arial; +} + +.text_class793 +{ +} + +.paragraph_class794 +{ +text-align: center; +margin-left: 0px; +} + +.text_class795 +{ +font-size: 11px; +font-family: arial; +} + +.text_class796 +{ +font-weight: bold; +} + +.text_class797 +{ +} + +.cell_class798 +{ +width: 49px; +} + +.paragraph_class800 +{ +margin-left: 0px; +} + +.text_class801 +{ +font-size: 11px; +font-family: arial; +} + +.text_class802 +{ +font-weight: bold; +} + +.cell_class803 +{ +width: 185px; +} + +.paragraph_class805 +{ +margin-left: 0px; +} + +.text_class806 +{ +font-size: 11px; +font-family: arial; +} + +.text_class807 +{ +font-weight: bold; +} + +.cell_class808 +{ +width: 350px; +} + +.paragraph_class810 +{ +margin-left: 0px; +} + +.text_class811 +{ +font-size: 11px; +font-family: arial; +} + +.text_class812 +{ +font-weight: bold; +} + +.paragraph_class813 +{ +margin-left: 0px; +} + +.text_class814 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class815 +{ +margin-left: 0px; +} + +.text_class816 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class817 +{ +margin-left: 0px; +} + +.text_class818 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class819 +{ +margin-left: 0px; +} + +.text_class820 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class821 +{ +margin-left: 0px; +} + +.text_class822 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class823 +{ +margin-left: 0px; +} + +.text_class824 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class825 +{ +margin-left: 0px; +} + +.text_class826 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class827 +{ +margin-left: 0px; +} + +.text_class828 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class829 +{ +margin-left: 0px; +} + +.text_class830 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class831 +{ +margin-left: 0px; +} + +.text_class832 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class833 +{ +margin-left: 0px; +} + +.text_class834 +{ +font-size: 11px; +font-family: arial; +} + +.text_class835 +{ +font-size: 11px; +font-family: arial; +} + +.text_class836 +{ +font-size: 11px; +font-family: arial; +} + +.text_class837 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class838 +{ +margin-left: 0px; +} + +.text_class839 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class840 +{ +margin-left: 0px; +} + +.text_class841 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class842 +{ +margin-left: 0px; +} + +.text_class843 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class844 +{ +margin-left: 0px; +} + +.text_class845 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class846 +{ +margin-left: 0px; +} + +.text_class847 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class848 +{ +margin-left: 0px; +} + +.text_class849 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class850 +{ +margin-left: 0px; +} + +.text_class851 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class852 +{ +margin-left: 0px; +} + +.text_class853 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class854 +{ +margin-left: 0px; +} + +.text_class855 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class856 +{ +margin-left: 0px; +} + +.text_class857 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class858 +{ +margin-left: 0px; +} + +.text_class859 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class860 +{ +margin-left: 0px; +} + +.text_class861 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class862 +{ +margin-left: 0px; +} + +.text_class863 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class864 +{ +margin-left: 0px; +} + +.text_class865 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class866 +{ +margin-left: 0px; +} + +.text_class867 +{ +font-size: 11px; +font-family: arial; +} + +.text_class868 +{ +} + +.text_class869 +{ +} + +.paragraph_class870 +{ +} + +.text_class871 +{ +} + +.paragraph_class872 +{ +} + +.text_class873 +{ +font-size: 11px; +} + +.text_class874 +{ +} + +.paragraph_class875 +{ +} + +.text_class876 +{ +font-size: 11px; +} + +.text_class877 +{ +font-family: arial; +} + +.paragraph_class878 +{ +} + +.text_class879 +{ +font-size: 11px; +} + +.text_class880 +{ +font-family: arial; +} + +.paragraph_class881 +{ +} + +.text_class882 +{ +font-size: 11px; +} + +.text_class883 +{ +font-family: arial; +} + +.text_class884 +{ +} + +.paragraph_class885 +{ +} + +.text_class886 +{ +font-size: 11px; +} + +.text_class887 +{ +font-family: arial; +} + +.paragraph_class888 +{ +} + +.text_class889 +{ +font-size: 11px; +} + +.text_class890 +{ +font-family: arial; +} + +.paragraph_class891 +{ +} + +.text_class892 +{ +font-size: 11px; +} + +.text_class893 +{ +font-family: arial; +} + +.paragraph_class894 +{ +} + +.text_class895 +{ +font-size: 11px; +} + +.text_class896 +{ +font-family: arial; +} + +.text_class897 +{ +} + +.paragraph_class898 +{ +} + +.text_class899 +{ +font-family: arial; +} + +.text_class900 +{ +font-size: 11px; +} + +.text_class901 +{ +} + +.paragraph_class902 +{ +} + +.text_class903 +{ +font-size: 11px; +} + +.text_class904 +{ +font-family: arial; +} + +.paragraph_class905 +{ +} + +.text_class906 +{ +font-size: 11px; +} + +.text_class907 +{ +font-family: arial; +} + +.text_class908 +{ +} + +.paragraph_class909 +{ +} + +.text_class910 +{ +font-size: 11px; +} + +.text_class911 +{ +font-family: arial; +} + +.text_class912 +{ +} + +.paragraph_class913 +{ +} + +.text_class914 +{ +font-family: arial; +} + +.text_class915 +{ +font-size: 11px; +} + +.paragraph_class916 +{ +} + +.text_class917 +{ +font-family: arial; +} + +.text_class918 +{ +font-size: 11px; +} + +.text_class919 +{ +} + +.paragraph_class920 +{ +} + +.text_class921 +{ +font-family: arial; +} + +.text_class922 +{ +font-size: 11px; +} + +.paragraph_class923 +{ +} + +.text_class924 +{ +font-family: arial; +} + +.text_class925 +{ +font-size: 11px; +} + +.text_class926 +{ +} + +.text_class927 +{ +} + +.paragraph_class928 +{ +} + +.text_class929 +{ +font-family: arial; +} + +.text_class930 +{ +font-size: 11px; +} + +.paragraph_class931 +{ +} + +.text_class932 +{ +font-family: arial; +} + +.text_class933 +{ +font-size: 11px; +} + +.paragraph_class934 +{ +} + +.text_class935 +{ +font-family: arial; +} + +.text_class936 +{ +font-size: 11px; +} + +.text_class937 +{ +} + +.paragraph_class938 +{ +} + +.text_class939 +{ +font-family: arial; +} + +.text_class940 +{ +font-size: 11px; +} + +.paragraph_class941 +{ +} + +.text_class942 +{ +font-family: arial; +} + +.text_class943 +{ +font-size: 11px; +} + +.text_class944 +{ +} + +.paragraph_class945 +{ +} + +.text_class946 +{ +font-family: arial; +} + +.text_class947 +{ +font-size: 11px; +} + +.paragraph_class948 +{ +} + +.text_class949 +{ +font-family: arial; +} + +.text_class950 +{ +font-size: 11px; +} + +.paragraph_class951 +{ +} + +.text_class952 +{ +font-family: arial; +} + +.text_class953 +{ +font-size: 11px; +} + +.text_class954 +{ +} + +.paragraph_class955 +{ +} + +.text_class956 +{ +font-family: arial; +} + +.text_class957 +{ +font-size: 11px; +} + +.paragraph_class958 +{ +} + +.text_class959 +{ +font-family: arial; +} + +.text_class960 +{ +font-size: 11px; +} + +.text_class961 +{ +} + +.paragraph_class962 +{ +} + +.text_class963 +{ +font-family: arial; +} + +.text_class964 +{ +font-size: 11px; +} + +.paragraph_class965 +{ +} + +.text_class966 +{ +font-family: arial; +} + +.text_class967 +{ +font-size: 11px; +} + +.paragraph_class968 +{ +} + +.text_class969 +{ +font-family: arial; +} + +.text_class970 +{ +font-size: 11px; +} + +.paragraph_class971 +{ +} + +.text_class972 +{ +font-family: arial; +} + +.text_class973 +{ +font-size: 11px; +} + +.text_class974 +{ +} + +.paragraph_class975 +{ +} + +.text_class976 +{ +font-family: arial; +} + +.text_class977 +{ +font-size: 11px; +} + +.text_class978 +{ +} + +.text_class979 +{ +} + +.paragraph_class980 +{ +} + +.text_class981 +{ +font-family: arial; +} + +.text_class982 +{ +font-size: 11px; +} + +.paragraph_class983 +{ +} + +.text_class984 +{ +font-family: arial; +} + +.text_class985 +{ +font-size: 11px; +} + +.paragraph_class986 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class987 +{ +font-size: 11px; +} + +.text_class988 +{ +font-family: arial; +} + +.text_class989 +{ +font-size: 11px; +} + +.paragraph_class990 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class991 +{ +font-size: 11px; +font-family: arial; +} + +.text_class992 +{ +} + +.paragraph_class993 +{ +} + +.text_class994 +{ +font-family: arial; +} + +.text_class995 +{ +font-size: 11px; +} + +.paragraph_class996 +{ +} + +.text_class997 +{ +font-family: arial; +} + +.text_class998 +{ +font-size: 11px; +} + +.text_class999 +{ +} + +.paragraph_class1000 +{ +} + +.text_class1001 +{ +font-family: arial; +} + +.text_class1002 +{ +font-size: 11px; +} + +.paragraph_class1003 +{ +} + +.text_class1004 +{ +font-family: arial; +} + +.text_class1005 +{ +font-size: 11px; +} + +.text_class1006 +{ +font-family: arial; +} + +.text_class1007 +{ +font-size: 11px; +} + +.paragraph_class1008 +{ +} + +.text_class1009 +{ +font-family: arial; +} + +.text_class1010 +{ +font-size: 11px; +} + +.text_class1011 +{ +} + +.paragraph_class1012 +{ +} + +.text_class1013 +{ +font-family: arial; +} + +.text_class1014 +{ +font-size: 11px; +} + +.paragraph_class1015 +{ +} + +.text_class1016 +{ +font-family: arial; +} + +.text_class1017 +{ +font-size: 11px; +} + +.text_class1018 +{ +} + +.paragraph_class1019 +{ +} + +.text_class1020 +{ +font-family: arial; +} + +.text_class1021 +{ +font-size: 11px; +} + +.paragraph_class1022 +{ +} + +.text_class1023 +{ +font-family: arial; +} + +.text_class1024 +{ +font-size: 11px; +} + +.text_class1025 +{ +} + +.paragraph_class1026 +{ +} + +.text_class1027 +{ +font-family: arial; +} + +.text_class1028 +{ +font-size: 11px; +} + +.text_class1029 +{ +} + +.paragraph_class1030 +{ +} + +.text_class1031 +{ +font-family: arial; +} + +.text_class1032 +{ +font-size: 11px; +} + +.text_class1033 +{ +} + +.paragraph_class1034 +{ +} + +.text_class1035 +{ +font-family: arial; +} + +.text_class1036 +{ +font-size: 11px; +} + +.text_class1037 +{ +} + +.text_class1038 +{ +} + +.paragraph_class1039 +{ +} + +.text_class1040 +{ +font-family: arial; +} + +.text_class1041 +{ +font-size: 11px; +} + +.paragraph_class1042 +{ +} + +.text_class1043 +{ +font-family: arial; +} + +.text_class1044 +{ +font-size: 11px; +} + +.paragraph_class1045 +{ +} + +.text_class1046 +{ +font-family: arial; +} + +.text_class1047 +{ +font-size: 11px; +} + +.text_class1048 +{ +} + +.text_class1049 +{ +} + +.paragraph_class1050 +{ +} + +.text_class1051 +{ +font-family: arial; +} + +.text_class1052 +{ +font-size: 11px; +} + +.text_class1053 +{ +font-family: arial; +} + +.text_class1054 +{ +font-size: 11px; +} + +.paragraph_class1055 +{ +} + +.text_class1056 +{ +font-family: arial; +} + +.text_class1057 +{ +font-size: 11px; +} + +.text_class1058 +{ +} + +.text_class1059 +{ +} + +.paragraph_class1060 +{ +} + +.text_class1061 +{ +font-family: arial; +} + +.text_class1062 +{ +font-size: 11px; +} + +.text_class1063 +{ +} + +.text_class1064 +{ +} + +.paragraph_class1065 +{ +} + +.text_class1066 +{ +font-family: arial; +} + +.text_class1067 +{ +font-size: 11px; +} + +.text_class1068 +{ +} + +.paragraph_class1069 +{ +} + +.text_class1070 +{ +font-family: arial; +} + +.text_class1071 +{ +font-size: 11px; +} + +.text_class1072 +{ +} + +.text_class1073 +{ +} + +.paragraph_class1074 +{ +} + +.text_class1075 +{ +font-family: arial; +} + +.text_class1076 +{ +font-size: 11px; +} + +.text_class1077 +{ +} + +.paragraph_class1078 +{ +} + +.text_class1079 +{ +font-family: arial; +} + +.text_class1080 +{ +font-size: 11px; +} + +.paragraph_class1081 +{ +} + +.text_class1082 +{ +font-family: arial; +} + +.text_class1083 +{ +font-size: 11px; +} + +.text_class1084 +{ +} + +.text_class1085 +{ +} + +.text_class1086 +{ +} + +.text_class1087 +{ +} + +.paragraph_class1088 +{ +margin-left: 0px; +} + +.text_class1089 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1090 +{ +} + +.text_class1091 +{ +} + +.paragraph_class1092 +{ +} + +.text_class1093 +{ +font-size: 11px; +} + +.text_class1094 +{ +} + +.paragraph_class1095 +{ +} + +.text_class1096 +{ +font-size: 11px; +} + +.text_class1097 +{ +} + +.text_class1098 +{ +} + +.paragraph_class1099 +{ +margin-left: 0px; +} + +.text_class1100 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1101 +{ +} + +.text_class1102 +{ +} + +.paragraph_class1103 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1104 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1105 +{ +font-weight: bold; +} + +.text_class1106 +{ +} + +.paragraph_class1107 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1108 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1109 +{ +} + +.paragraph_class1110 +{ +} + +.text_class1111 +{ +font-size: 11px; +} + +.text_class1112 +{ +} + +.text_class1113 +{ +} + +.paragraph_class1114 +{ +margin-left: 0px; +} + +.text_class1115 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1116 +{ +} + +.text_class1117 +{ +} + +.paragraph_class1118 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1119 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1120 +{ +font-weight: bold; +} + +.text_class1121 +{ +} + +.paragraph_class1122 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1123 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1124 +{ +} + +.paragraph_class1125 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1126 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1127 +{ +font-weight: bold; +} + +.text_class1128 +{ +} + +.cell_class1129 +{ +width: 37px; +} + +.paragraph_class1131 +{ +margin-left: 0px; +} + +.text_class1132 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1133 +{ +font-weight: bold; +} + +.cell_class1134 +{ +width: 197px; +} + +.paragraph_class1136 +{ +margin-left: 0px; +} + +.text_class1137 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1138 +{ +font-weight: bold; +} + +.cell_class1139 +{ +width: 340px; +} + +.paragraph_class1141 +{ +margin-left: 0px; +} + +.text_class1142 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1143 +{ +font-weight: bold; +} + +.paragraph_class1144 +{ +margin-left: 0px; +} + +.text_class1145 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1146 +{ +margin-left: 0px; +} + +.text_class1147 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1148 +{ +margin-left: 0px; +} + +.text_class1149 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1150 +{ +margin-left: 0px; +} + +.text_class1151 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1152 +{ +margin-left: 0px; +} + +.text_class1153 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1154 +{ +margin-left: 0px; +} + +.text_class1155 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1156 +{ +margin-left: 0px; +} + +.text_class1157 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1158 +{ +margin-left: 0px; +} + +.text_class1159 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1160 +{ +margin-left: 0px; +} + +.text_class1161 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1162 +{ +margin-left: 0px; +} + +.text_class1163 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1164 +{ +margin-left: 0px; +} + +.text_class1165 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1166 +{ +margin-left: 0px; +} + +.text_class1167 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1168 +{ +margin-left: 0px; +} + +.text_class1169 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class1170 +{ +width: 93px; +} + +.paragraph_class1171 +{ +margin-left: 0px; +} + +.text_class1172 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class1173 +{ +width: 104px; +} + +.paragraph_class1174 +{ +margin-left: 0px; +} + +.text_class1175 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1177 +{ +margin-left: 0px; +} + +.text_class1178 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1179 +{ +margin-left: 0px; +} + +.text_class1180 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1181 +{ +margin-left: 0px; +} + +.text_class1182 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1183 +{ +margin-left: 0px; +} + +.text_class1184 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1185 +{ +margin-left: 0px; +} + +.text_class1186 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1187 +{ +margin-left: 0px; +} + +.text_class1188 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1189 +{ +margin-left: 0px; +} + +.text_class1190 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1191 +{ +margin-left: 0px; +} + +.text_class1192 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1193 +{ +margin-left: 0px; +} + +.text_class1194 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1195 +{ +margin-left: 0px; +} + +.text_class1196 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1197 +{ +margin-left: 0px; +} + +.text_class1198 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1199 +{ +margin-left: 0px; +} + +.text_class1200 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1201 +{ +margin-left: 0px; +} + +.text_class1202 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1203 +{ +} + +.paragraph_class1204 +{ +} + +.text_class1205 +{ +font-size: 11px; +} + +.text_class1206 +{ +} + +.paragraph_class1207 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1208 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1209 +{ +} + +.paragraph_class1210 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1211 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1212 +{ +font-weight: bold; +} + +.text_class1213 +{ +} + +.paragraph_class1215 +{ +margin-left: 0px; +} + +.text_class1216 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1217 +{ +font-weight: bold; +} + +.paragraph_class1219 +{ +margin-left: 0px; +} + +.text_class1220 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1221 +{ +font-weight: bold; +} + +.paragraph_class1223 +{ +margin-left: 0px; +} + +.text_class1224 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1225 +{ +font-weight: bold; +} + +.paragraph_class1226 +{ +margin-left: 0px; +} + +.text_class1227 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1228 +{ +margin-left: 0px; +} + +.text_class1229 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1230 +{ +margin-left: 0px; +} + +.text_class1231 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1232 +{ +margin-left: 0px; +} + +.text_class1233 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1234 +{ +margin-left: 0px; +} + +.text_class1235 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1236 +{ +margin-left: 0px; +} + +.text_class1237 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1238 +{ +margin-left: 0px; +} + +.text_class1239 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1240 +{ +margin-left: 0px; +} + +.text_class1241 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1242 +{ +margin-left: 0px; +} + +.text_class1243 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1244 +{ +margin-left: 0px; +} + +.text_class1245 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1246 +{ +margin-left: 0px; +} + +.text_class1247 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1248 +{ +margin-left: 0px; +} + +.text_class1249 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1250 +{ +margin-left: 0px; +} + +.text_class1251 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1252 +{ +margin-left: 0px; +} + +.text_class1253 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1254 +{ +margin-left: 0px; +} + +.text_class1255 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1256 +{ +margin-left: 0px; +} + +.text_class1257 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1258 +{ +} + +.text_class1259 +{ +} + +.paragraph_class1260 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1261 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1262 +{ +font-weight: bold; +} + +.text_class1263 +{ +} + +.paragraph_class1264 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1265 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1266 +{ +} + +.paragraph_class1267 +{ +} + +.text_class1268 +{ +font-size: 11px; +} + +.text_class1269 +{ +} + +.paragraph_class1270 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1271 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1272 +{ +} + +.paragraph_class1273 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1274 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1275 +{ +} + +.text_class1276 +{ +} + +.paragraph_class1277 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1278 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1279 +{ +font-weight: bold; +} + +.text_class1280 +{ +} + +.paragraph_class1281 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1282 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1283 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1284 +{ +} + +.paragraph_class1285 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1286 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1287 +{ +} + +.paragraph_class1288 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1289 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1290 +{ +} + +.paragraph_class1291 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1292 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1293 +{ +} + +.paragraph_class1294 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1295 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1296 +{ +} + +.paragraph_class1297 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1298 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1299 +{ +} + +.paragraph_class1300 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1301 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1302 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1303 +{ +} + +.paragraph_class1304 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1305 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1306 +{ +} + +.paragraph_class1307 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1308 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1309 +{ +} + +.paragraph_class1310 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1311 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1312 +{ +} + +.paragraph_class1313 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1314 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1315 +{ +} + +.text_class1316 +{ +} + +.paragraph_class1317 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1318 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1319 +{ +font-weight: bold; +} + +.text_class1320 +{ +} + +.paragraph_class1321 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1322 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1323 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1324 +{ +} + +.paragraph_class1325 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1326 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1327 +{ +} + +.paragraph_class1328 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1329 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1330 +{ +} + +.paragraph_class1331 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1332 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1333 +{ +font-weight: bold; +} + +.text_class1334 +{ +} + +.cell_class1335 +{ +width: 34px; +background-color: #bfbfbf; +} + +.paragraph_class1337 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1338 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1339 +{ +font-weight: bold; +} + +.cell_class1340 +{ +width: 96px; +background-color: #bfbfbf; +} + +.paragraph_class1342 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1343 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1344 +{ +font-weight: bold; +} + +.cell_class1345 +{ +width: 302px; +background-color: #bfbfbf; +} + +.paragraph_class1347 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1348 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1349 +{ +font-weight: bold; +} + +.cell_class1350 +{ +width: 149px; +background-color: #bfbfbf; +} + +.paragraph_class1352 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1353 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1354 +{ +font-weight: bold; +} + +.cell_class1355 +{ +width: 34px; +} + +.paragraph_class1356 +{ +margin-left: 0px; +} + +.text_class1357 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class1358 +{ +width: 96px; +} + +.paragraph_class1359 +{ +margin-left: 0px; +} + +.text_class1360 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class1361 +{ +width: 302px; +} + +.paragraph_class1362 +{ +margin-left: 0px; +} + +.text_class1363 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class1364 +{ +width: 149px; +} + +.paragraph_class1365 +{ +margin-left: 0px; +} + +.text_class1366 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1367 +{ +margin-left: 0px; +} + +.text_class1368 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1369 +{ +margin-left: 0px; +} + +.text_class1370 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1371 +{ +margin-left: 0px; +} + +.text_class1372 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1373 +{ +margin-left: 0px; +} + +.text_class1374 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1375 +{ +margin-left: 0px; +} + +.text_class1376 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1377 +{ +margin-left: 0px; +} + +.text_class1378 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1379 +{ +margin-left: 0px; +} + +.text_class1380 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1381 +{ +margin-left: 0px; +} + +.text_class1382 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1383 +{ +margin-left: 0px; +} + +.text_class1384 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1385 +{ +margin-left: 0px; +} + +.text_class1386 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1387 +{ +margin-left: 0px; +} + +.text_class1388 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1389 +{ +margin-left: 0px; +} + +.text_class1390 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1391 +{ +} + +.paragraph_class1392 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1393 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1394 +{ +} + +.paragraph_class1395 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1396 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1397 +{ +} + +.paragraph_class1398 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1399 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1400 +{ +font-weight: bold; +} + +.text_class1401 +{ +} + +.paragraph_class1403 +{ +margin-left: 0px; +} + +.text_class1404 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1405 +{ +font-weight: bold; +} + +.paragraph_class1407 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1408 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1409 +{ +font-weight: bold; +} + +.paragraph_class1411 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1412 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1413 +{ +font-weight: bold; +} + +.paragraph_class1415 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1416 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1417 +{ +font-weight: bold; +} + +.paragraph_class1418 +{ +margin-left: 0px; +} + +.text_class1419 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1420 +{ +margin-left: 0px; +} + +.text_class1421 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1422 +{ +margin-left: 0px; +} + +.text_class1423 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1424 +{ +margin-left: 0px; +} + +.text_class1425 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1426 +{ +margin-left: 0px; +} + +.text_class1427 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1428 +{ +margin-left: 0px; +} + +.text_class1429 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1430 +{ +margin-left: 0px; +} + +.text_class1431 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class1432 +{ +margin-left: 0px; +} + +.text_class1433 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class1434 +{ +} + +.paragraph_class1435 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1436 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1437 +{ +} + +.text_class1438 +{ +} + +.paragraph_class1439 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1440 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1441 +{ +font-weight: bold; +} + +.text_class1442 +{ +} + +.paragraph_class1443 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1444 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1445 +{ +} + +.paragraph_class1446 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1447 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1448 +{ +} + +.paragraph_class1449 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1450 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1451 +{ +} + +.paragraph_class1452 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1453 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1454 +{ +} + +.paragraph_class1455 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1456 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1457 +{ +} + +.paragraph_class1458 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1459 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1460 +{ +} + +.paragraph_class1461 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1462 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1463 +{ +} + +.paragraph_class1464 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1465 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1466 +{ +} + +.paragraph_class1467 +{ +} + +.text_class1468 +{ +font-size: 11px; +} + +.text_class1469 +{ +} + +.paragraph_class1470 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1471 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1472 +{ +} + +.paragraph_class1473 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1474 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1475 +{ +} + +.text_class1476 +{ +} + +.paragraph_class1477 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1478 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1479 +{ +font-weight: bold; +} + +.text_class1480 +{ +} + +.paragraph_class1481 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1482 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1483 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1484 +{ +} + +.paragraph_class1485 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1486 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1487 +{ +} + +.paragraph_class1488 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1489 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1490 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1491 +{ +} + +.paragraph_class1492 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1493 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1494 +{ +} + +.paragraph_class1495 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1496 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1497 +{ +} + +.paragraph_class1498 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1499 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1500 +{ +font-weight: bold; +} + +.text_class1501 +{ +} + +.paragraph_class1503 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1504 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1505 +{ +font-weight: bold; +} + +.paragraph_class1507 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1508 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1509 +{ +font-weight: bold; +} + +.paragraph_class1511 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1512 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1513 +{ +font-weight: bold; +} + +.paragraph_class1515 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1516 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1517 +{ +font-weight: bold; +} + +.paragraph_class1518 +{ +margin-left: 0px; +} + +.text_class1519 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1520 +{ +margin-left: 0px; +} + +.text_class1521 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1522 +{ +margin-left: 0px; +} + +.text_class1523 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1524 +{ +margin-left: 0px; +} + +.text_class1525 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1526 +{ +margin-left: 0px; +} + +.text_class1527 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1528 +{ +margin-left: 0px; +} + +.text_class1529 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1530 +{ +margin-left: 0px; +} + +.text_class1531 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1532 +{ +margin-left: 0px; +} + +.text_class1533 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1534 +{ +margin-left: 0px; +} + +.text_class1535 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1536 +{ +margin-left: 0px; +} + +.text_class1537 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1538 +{ +margin-left: 0px; +} + +.text_class1539 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1540 +{ +margin-left: 0px; +} + +.text_class1541 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1542 +{ +} + +.paragraph_class1543 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1544 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1545 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1546 +{ +} + +.paragraph_class1547 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1548 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1549 +{ +} + +.paragraph_class1550 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1551 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1552 +{ +} + +.paragraph_class1553 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1554 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1555 +{ +} + +.text_class1556 +{ +} + +.paragraph_class1557 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1558 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1559 +{ +font-weight: bold; +} + +.text_class1560 +{ +} + +.paragraph_class1561 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1562 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1563 +{ +} + +.paragraph_class1564 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1565 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1566 +{ +} + +.paragraph_class1567 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1568 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1569 +{ +} + +.paragraph_class1570 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1571 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1572 +{ +} + +.paragraph_class1573 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1574 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1575 +{ +} + +.paragraph_class1576 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1577 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1578 +{ +} + +.paragraph_class1579 +{ +} + +.text_class1580 +{ +font-size: 11px; +} + +.text_class1581 +{ +} + +.paragraph_class1582 +{ +} + +.text_class1583 +{ +font-size: 11px; +} + +.text_class1584 +{ +} + +.paragraph_class1585 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1586 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1587 +{ +} + +.text_class1588 +{ +} + +.paragraph_class1589 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1590 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1591 +{ +font-weight: bold; +} + +.text_class1592 +{ +} + +.paragraph_class1593 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1594 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1595 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1596 +{ +} + +.paragraph_class1597 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1598 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1599 +{ +} + +.paragraph_class1600 +{ +text-align: justify; +margin-left: 40px; +} + +.text_class1601 +{ +font-size: 10px; +font-family: Times New Roman; +} + +.text_class1602 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1603 +{ +} + +.paragraph_class1604 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1605 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1606 +{ +} + +.paragraph_class1607 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1608 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1609 +{ +} + +.paragraph_class1610 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1611 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1612 +{ +} + +.text_class1613 +{ +} + +.paragraph_class1614 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1615 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1616 +{ +font-weight: bold; +} + +.text_class1617 +{ +} + +.paragraph_class1618 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1619 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1620 +{ +} + +.paragraph_class1621 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class1622 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1623 +{ +} + +.paragraph_class1624 +{ +margin-left: 0px; +} + +.text_class1625 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1626 +{ +} + +.paragraph_class1627 +{ +margin-left: 0px; +} + +.text_class1628 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1629 +{ +} + +.text_class1630 +{ +} + +.paragraph_class1631 +{ +} + +.text_class1632 +{ +font-size: 11px; +} + +.text_class1633 +{ +} + +.paragraph_class1634 +{ +margin-left: 0px; +} + +.text_class1635 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1636 +{ +} + +.paragraph_class1637 +{ +margin-left: 0px; +} + +.text_class1638 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1639 +{ +} + +.paragraph_class1640 +{ +} + +.text_class1641 +{ +font-size: 11px; +} + +.text_class1642 +{ +} + +.paragraph_class1644 +{ +margin-left: 0px; +} + +.text_class1645 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1646 +{ +font-weight: bold; +} + +.paragraph_class1648 +{ +margin-left: 0px; +} + +.text_class1649 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1650 +{ +font-weight: bold; +} + +.paragraph_class1652 +{ +margin-left: 0px; +} + +.text_class1653 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1654 +{ +font-weight: bold; +} + +.paragraph_class1655 +{ +margin-left: 0px; +} + +.text_class1656 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1657 +{ +margin-left: 0px; +} + +.text_class1658 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1659 +{ +margin-left: 0px; +} + +.text_class1660 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1661 +{ +margin-left: 0px; +} + +.text_class1662 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1663 +{ +margin-left: 0px; +} + +.text_class1664 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1665 +{ +margin-left: 0px; +} + +.text_class1666 +{ +font-size: 11px; +font-family: arial; +} + +.list_class1667 +{ +list-style-type: decimal; +} + +.text_class1668 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1669 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1670 +{ +} + +.text_class1671 +{ +} + +.text_class1672 +{ +} + +.paragraph_class1673 +{ +} + +.text_class1674 +{ +font-size: 11px; +} + +.text_class1675 +{ +} + +.paragraph_class1676 +{ +} + +.text_class1677 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1678 +{ +} + +.paragraph_class1679 +{ +} + +.text_class1680 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1681 +{ +} + +.text_class1682 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1683 +{ +} + +.text_class1684 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1685 +{ +color: #222222; +font-size: 11px; +font-family: arial; +} + +.text_class1686 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1687 +{ +} + +.text_class1688 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1689 +{ +} + +.text_class1690 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1691 +{ +} + +.paragraph_class1692 +{ +} + +.text_class1693 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1694 +{ +} + +.text_class1695 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1696 +{ +} + +.text_class1697 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1698 +{ +} + +.text_class1699 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1700 +{ +} + +.paragraph_class1701 +{ +margin-left: 0px; +} + +.text_class1702 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1703 +{ +margin-left: 0px; +} + +.text_class1704 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1705 +{ +margin-left: 0px; +} + +.text_class1706 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1707 +{ +margin-left: 0px; +} + +.text_class1708 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1709 +{ +margin-left: 0px; +} + +.text_class1710 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1711 +{ +margin-left: 0px; +} + +.text_class1712 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1713 +{ +} + +.paragraph_class1714 +{ +margin-left: 0px; +} + +.text_class1715 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1716 +{ +margin-left: 0px; +} + +.text_class1717 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1718 +{ +margin-left: 0px; +} + +.text_class1719 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1720 +{ +} + +.paragraph_class1721 +{ +margin-left: 0px; +} + +.text_class1722 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1723 +{ +margin-left: 0px; +} + +.text_class1724 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1725 +{ +margin-left: 0px; +} + +.text_class1726 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1727 +{ +margin-left: 0px; +} + +.text_class1728 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1729 +{ +} + +.paragraph_class1730 +{ +margin-left: 0px; +} + +.text_class1731 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1732 +{ +margin-left: 0px; +} + +.text_class1733 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1734 +{ +margin-left: 0px; +} + +.text_class1735 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1736 +{ +margin-left: 0px; +} + +.text_class1737 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1738 +{ +} + +.paragraph_class1739 +{ +margin-left: 0px; +} + +.text_class1740 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1741 +{ +margin-left: 0px; +} + +.text_class1742 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1743 +{ +margin-left: 0px; +} + +.text_class1744 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1745 +{ +} + +.paragraph_class1746 +{ +} + +.text_class1747 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1748 +{ +} + +.paragraph_class1749 +{ +} + +.text_class1750 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1751 +{ +} + +.paragraph_class1752 +{ +} + +.text_class1753 +{ +font-size: 11px; +} + +.text_class1754 +{ +} + +.paragraph_class1755 +{ +} + +.text_class1756 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1757 +{ +} + +.paragraph_class1758 +{ +margin-left: 0px; +} + +.text_class1759 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1760 +{ +margin-left: 0px; +} + +.text_class1761 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1762 +{ +margin-left: 0px; +} + +.text_class1763 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1764 +{ +margin-left: 0px; +} + +.text_class1765 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1766 +{ +margin-left: 0px; +} + +.text_class1767 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1768 +{ +margin-left: 0px; +} + +.text_class1769 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1770 +{ +} + +.paragraph_class1771 +{ +margin-left: 0px; +} + +.text_class1772 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1773 +{ +margin-left: 0px; +} + +.text_class1774 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1775 +{ +margin-left: 0px; +} + +.text_class1776 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1777 +{ +margin-left: 0px; +} + +.text_class1778 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1779 +{ +margin-left: 0px; +} + +.text_class1780 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1781 +{ +margin-left: 0px; +} + +.text_class1782 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1783 +{ +} + +.text_class1784 +{ +} + +.paragraph_class1785 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1786 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1787 +{ +font-weight: bold; +} + +.text_class1788 +{ +} + +.paragraph_class1789 +{ +margin-left: 0px; +} + +.text_class1790 +{ +font-size: 11px; +font-family: arial; +} + +.list_class1791 +{ +list-style-type: lower-alpha; +} + +.text_class1792 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1793 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1794 +{ +} + +.paragraph_class1795 +{ +margin-left: 0px; +} + +.text_class1796 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1797 +{ +margin-left: 0px; +} + +.text_class1798 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1799 +{ +margin-left: 0px; +} + +.text_class1800 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1801 +{ +margin-left: 0px; +} + +.text_class1802 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1803 +{ +} + +.paragraph_class1804 +{ +margin-left: 0px; +} + +.text_class1805 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1806 +{ +margin-left: 0px; +} + +.text_class1807 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1808 +{ +margin-left: 0px; +} + +.text_class1809 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1810 +{ +} + +.paragraph_class1811 +{ +} + +.text_class1812 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1813 +{ +} + +.paragraph_class1814 +{ +} + +.text_class1815 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1816 +{ +} + +.paragraph_class1817 +{ +} + +.text_class1818 +{ +font-size: 11px; +} + +.text_class1819 +{ +} + +.paragraph_class1820 +{ +} + +.text_class1821 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1822 +{ +} + +.paragraph_class1823 +{ +margin-left: 0px; +} + +.text_class1824 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1825 +{ +margin-left: 0px; +} + +.text_class1826 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1827 +{ +margin-left: 0px; +} + +.text_class1828 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1829 +{ +margin-left: 0px; +} + +.text_class1830 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1831 +{ +margin-left: 0px; +} + +.text_class1832 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1833 +{ +margin-left: 0px; +} + +.text_class1834 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1835 +{ +margin-left: 0px; +} + +.text_class1836 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1837 +{ +margin-left: 0px; +} + +.text_class1838 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1839 +{ +margin-left: 0px; +} + +.text_class1840 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1841 +{ +margin-left: 0px; +} + +.text_class1842 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1843 +{ +} + +.paragraph_class1844 +{ +margin-left: 0px; +} + +.text_class1845 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1846 +{ +margin-left: 0px; +} + +.text_class1847 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1848 +{ +margin-left: 0px; +} + +.text_class1849 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1850 +{ +} + +.text_class1851 +{ +} + +.paragraph_class1852 +{ +} + +.text_class1853 +{ +font-size: 11px; +} + +.text_class1854 +{ +} + +.paragraph_class1855 +{ +} + +.text_class1856 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1857 +{ +} + +.paragraph_class1858 +{ +margin-left: 0px; +} + +.text_class1859 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1860 +{ +margin-left: 0px; +} + +.text_class1861 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1862 +{ +margin-left: 0px; +} + +.text_class1863 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1864 +{ +} + +.paragraph_class1865 +{ +margin-left: 0px; +} + +.text_class1866 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1867 +{ +margin-left: 0px; +} + +.text_class1868 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1869 +{ +} + +.paragraph_class1870 +{ +} + +.text_class1871 +{ +font-size: 11px; +} + +.text_class1872 +{ +} + +.paragraph_class1873 +{ +} + +.text_class1874 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1875 +{ +} + +.paragraph_class1876 +{ +margin-left: 0px; +} + +.text_class1877 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1878 +{ +margin-left: 0px; +} + +.text_class1879 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1880 +{ +margin-left: 0px; +} + +.text_class1881 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1882 +{ +margin-left: 0px; +} + +.text_class1883 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1884 +{ +margin-left: 0px; +} + +.text_class1885 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1886 +{ +} + +.paragraph_class1887 +{ +margin-left: 0px; +} + +.text_class1888 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1889 +{ +margin-left: 0px; +} + +.text_class1890 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1891 +{ +margin-left: 0px; +} + +.text_class1892 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1893 +{ +margin-left: 0px; +} + +.text_class1894 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1895 +{ +} + +.paragraph_class1896 +{ +margin-left: 0px; +} + +.text_class1897 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1898 +{ +margin-left: 0px; +} + +.text_class1899 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1900 +{ +margin-left: 0px; +} + +.text_class1901 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1902 +{ +} + +.paragraph_class1903 +{ +} + +.text_class1904 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1905 +{ +} + +.paragraph_class1906 +{ +margin-left: 0px; +} + +.text_class1907 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1908 +{ +} + +.text_class1909 +{ +} + +.paragraph_class1910 +{ +text-align: center; +margin-left: 0px; +} + +.text_class1911 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1912 +{ +} + +.paragraph_class1913 +{ +margin-left: 0px; +} + +.text_class1914 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1915 +{ +margin-left: 0px; +} + +.text_class1916 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1917 +{ +} + +.paragraph_class1918 +{ +} + +.text_class1919 +{ +font-size: 11px; +} + +.text_class1920 +{ +} + +.paragraph_class1921 +{ +} + +.text_class1922 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1923 +{ +} + +.paragraph_class1924 +{ +margin-left: 0px; +} + +.text_class1925 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1926 +{ +margin-left: 0px; +} + +.text_class1927 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1928 +{ +margin-left: 0px; +} + +.text_class1929 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1930 +{ +margin-left: 0px; +} + +.text_class1931 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1932 +{ +margin-left: 0px; +} + +.text_class1933 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1934 +{ +margin-left: 0px; +} + +.text_class1935 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1936 +{ +margin-left: 0px; +} + +.text_class1937 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1938 +{ +margin-left: 0px; +} + +.text_class1939 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1940 +{ +} + +.paragraph_class1941 +{ +margin-left: 0px; +} + +.text_class1942 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1943 +{ +margin-left: 0px; +} + +.text_class1944 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1945 +{ +margin-left: 0px; +} + +.text_class1946 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1947 +{ +} + +.text_class1948 +{ +} + +.paragraph_class1949 +{ +} + +.text_class1950 +{ +font-size: 11px; +} + +.text_class1951 +{ +} + +.paragraph_class1952 +{ +} + +.text_class1953 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1954 +{ +} + +.paragraph_class1955 +{ +margin-left: 0px; +} + +.text_class1956 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1957 +{ +margin-left: 0px; +} + +.text_class1958 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1959 +{ +} + +.paragraph_class1960 +{ +margin-left: 0px; +} + +.text_class1961 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1962 +{ +margin-left: 0px; +} + +.text_class1963 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1964 +{ +margin-left: 0px; +} + +.text_class1965 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1966 +{ +} + +.paragraph_class1967 +{ +} + +.text_class1968 +{ +font-size: 11px; +} + +.text_class1969 +{ +} + +.paragraph_class1970 +{ +} + +.text_class1971 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1972 +{ +} + +.paragraph_class1973 +{ +margin-left: 0px; +} + +.text_class1974 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1975 +{ +margin-left: 0px; +} + +.text_class1976 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1977 +{ +margin-left: 0px; +} + +.text_class1978 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1979 +{ +margin-left: 0px; +} + +.text_class1980 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1981 +{ +} + +.paragraph_class1982 +{ +} + +.text_class1983 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1984 +{ +} + +.paragraph_class1985 +{ +} + +.text_class1986 +{ +font-size: 11px; +} + +.text_class1987 +{ +} + +.paragraph_class1988 +{ +} + +.text_class1989 +{ +font-size: 11px; +font-family: arial; +} + +.text_class1990 +{ +} + +.paragraph_class1991 +{ +margin-left: 0px; +} + +.text_class1992 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1993 +{ +margin-left: 0px; +} + +.text_class1994 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1995 +{ +margin-left: 0px; +} + +.text_class1996 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1997 +{ +margin-left: 0px; +} + +.text_class1998 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class1999 +{ +margin-left: 0px; +} + +.text_class2000 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2001 +{ +margin-left: 0px; +} + +.text_class2002 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2003 +{ +margin-left: 0px; +} + +.text_class2004 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2005 +{ +margin-left: 0px; +} + +.text_class2006 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2007 +{ +} + +.paragraph_class2008 +{ +margin-left: 0px; +} + +.text_class2009 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2010 +{ +margin-left: 0px; +} + +.text_class2011 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2012 +{ +margin-left: 0px; +} + +.text_class2013 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2014 +{ +} + +.text_class2015 +{ +} + +.paragraph_class2016 +{ +} + +.text_class2017 +{ +font-size: 11px; +} + +.text_class2018 +{ +} + +.paragraph_class2019 +{ +} + +.text_class2020 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2021 +{ +} + +.paragraph_class2022 +{ +margin-left: 0px; +} + +.text_class2023 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2024 +{ +margin-left: 0px; +} + +.text_class2025 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2026 +{ +margin-left: 0px; +} + +.text_class2027 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2028 +{ +} + +.paragraph_class2029 +{ +} + +.text_class2030 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2031 +{ +} + +.paragraph_class2032 +{ +margin-left: 0px; +} + +.text_class2033 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2034 +{ +margin-left: 0px; +} + +.text_class2035 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2036 +{ +} + +.paragraph_class2037 +{ +margin-left: 0px; +} + +.text_class2038 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2039 +{ +margin-left: 0px; +} + +.text_class2040 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2041 +{ +} + +.paragraph_class2042 +{ +margin-left: 0px; +} + +.text_class2043 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2044 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2045 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2046 +{ +} + +.paragraph_class2047 +{ +} + +.text_class2048 +{ +font-size: 11px; +} + +.text_class2049 +{ +} + +.paragraph_class2050 +{ +} + +.text_class2051 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2052 +{ +} + +.paragraph_class2053 +{ +} + +.text_class2054 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2055 +{ +} + +.paragraph_class2056 +{ +} + +.text_class2057 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2058 +{ +} + +.text_class2059 +{ +} + +.paragraph_class2060 +{ +} + +.text_class2061 +{ +font-size: 11px; +} + +.text_class2062 +{ +} + +.paragraph_class2063 +{ +} + +.text_class2064 +{ +font-size: 11px; +} + +.text_class2065 +{ +} + +.paragraph_class2066 +{ +} + +.text_class2067 +{ +font-size: 11px; +} + +.paragraph_class2068 +{ +} + +.text_class2069 +{ +font-size: 11px; +} + +.paragraph_class2070 +{ +} + +.text_class2071 +{ +font-size: 11px; +} + +.paragraph_class2072 +{ +} + +.text_class2073 +{ +font-size: 11px; +} + +.paragraph_class2074 +{ +} + +.text_class2075 +{ +font-size: 11px; +} + +.paragraph_class2076 +{ +} + +.text_class2077 +{ +font-size: 11px; +} + +.text_class2078 +{ +} + +.paragraph_class2079 +{ +} + +.text_class2080 +{ +font-size: 11px; +} + +.text_class2081 +{ +} + +.paragraph_class2082 +{ +} + +.text_class2083 +{ +font-size: 11px; +} + +.text_class2084 +{ +} + +.paragraph_class2085 +{ +} + +.text_class2086 +{ +font-size: 11px; +} + +.text_class2087 +{ +} + +.paragraph_class2088 +{ +} + +.text_class2089 +{ +font-size: 11px; +} + +.text_class2090 +{ +} + +.paragraph_class2091 +{ +} + +.text_class2092 +{ +font-size: 11px; +} + +.paragraph_class2093 +{ +} + +.text_class2094 +{ +font-size: 11px; +} + +.paragraph_class2095 +{ +} + +.text_class2096 +{ +font-size: 11px; +} + +.text_class2097 +{ +} + +.paragraph_class2098 +{ +} + +.text_class2099 +{ +font-size: 11px; +} + +.text_class2100 +{ +} + +.paragraph_class2101 +{ +} + +.text_class2102 +{ +font-size: 11px; +} + +.paragraph_class2103 +{ +} + +.text_class2104 +{ +font-size: 11px; +} + +.paragraph_class2105 +{ +} + +.text_class2106 +{ +font-size: 11px; +} + +.paragraph_class2107 +{ +} + +.text_class2108 +{ +font-size: 11px; +} + +.paragraph_class2109 +{ +} + +.text_class2110 +{ +font-size: 11px; +} + +.paragraph_class2111 +{ +} + +.text_class2112 +{ +font-size: 11px; +} + +.text_class2113 +{ +} + +.paragraph_class2114 +{ +} + +.text_class2115 +{ +font-size: 11px; +} + +.text_class2116 +{ +} + +.paragraph_class2117 +{ +} + +.text_class2118 +{ +font-size: 11px; +} + +.text_class2119 +{ +} + +.paragraph_class2120 +{ +} + +.text_class2121 +{ +font-size: 11px; +} + +.text_class2122 +{ +} + +.paragraph_class2123 +{ +} + +.text_class2124 +{ +font-size: 11px; +} + +.text_class2125 +{ +} + +.paragraph_class2126 +{ +} + +.text_class2127 +{ +font-size: 11px; +} + +.paragraph_class2128 +{ +} + +.text_class2129 +{ +font-size: 11px; +} + +.paragraph_class2130 +{ +} + +.text_class2131 +{ +font-size: 11px; +} + +.paragraph_class2132 +{ +} + +.text_class2133 +{ +font-size: 11px; +} + +.text_class2134 +{ +} + +.paragraph_class2135 +{ +} + +.text_class2136 +{ +font-size: 11px; +} + +.paragraph_class2137 +{ +} + +.text_class2138 +{ +font-size: 11px; +} + +.paragraph_class2139 +{ +} + +.text_class2140 +{ +font-size: 11px; +} + +.text_class2141 +{ +} + +.paragraph_class2142 +{ +} + +.text_class2143 +{ +font-size: 11px; +} + +.paragraph_class2144 +{ +} + +.text_class2145 +{ +font-size: 11px; +} + +.paragraph_class2146 +{ +} + +.text_class2147 +{ +font-size: 11px; +} + +.paragraph_class2148 +{ +} + +.text_class2149 +{ +font-size: 11px; +} + +.paragraph_class2150 +{ +} + +.text_class2151 +{ +font-size: 11px; +} + +.text_class2152 +{ +} + +.paragraph_class2153 +{ +} + +.text_class2154 +{ +font-size: 11px; +} + +.text_class2155 +{ +} + +.paragraph_class2156 +{ +} + +.text_class2157 +{ +font-size: 11px; +} + +.text_class2158 +{ +} + +.paragraph_class2159 +{ +} + +.text_class2160 +{ +font-size: 11px; +} + +.text_class2161 +{ +} + +.paragraph_class2162 +{ +} + +.text_class2163 +{ +font-size: 11px; +} + +.text_class2164 +{ +} + +.paragraph_class2165 +{ +} + +.text_class2166 +{ +font-size: 11px; +} + +.text_class2167 +{ +} + +.paragraph_class2168 +{ +} + +.text_class2169 +{ +font-size: 11px; +} + +.text_class2170 +{ +} + +.paragraph_class2171 +{ +} + +.text_class2172 +{ +font-size: 11px; +} + +.text_class2173 +{ +} + +.paragraph_class2174 +{ +} + +.text_class2175 +{ +font-size: 11px; +} + +.text_class2176 +{ +} + +.paragraph_class2177 +{ +} + +.text_class2178 +{ +font-size: 11px; +} + +.paragraph_class2179 +{ +} + +.text_class2180 +{ +font-size: 11px; +} + +.paragraph_class2181 +{ +} + +.text_class2182 +{ +font-size: 11px; +} + +.paragraph_class2183 +{ +} + +.text_class2184 +{ +font-size: 11px; +} + +.paragraph_class2185 +{ +} + +.text_class2186 +{ +font-size: 11px; +} + +.text_class2187 +{ +} + +.paragraph_class2188 +{ +} + +.text_class2189 +{ +font-size: 11px; +} + +.text_class2190 +{ +} + +.paragraph_class2191 +{ +} + +.text_class2192 +{ +font-size: 11px; +} + +.text_class2193 +{ +} + +.paragraph_class2194 +{ +} + +.text_class2195 +{ +font-size: 11px; +} + +.text_class2196 +{ +} + +.paragraph_class2197 +{ +} + +.text_class2198 +{ +font-size: 11px; +} + +.text_class2199 +{ +} + +.paragraph_class2200 +{ +} + +.text_class2201 +{ +font-size: 11px; +} + +.text_class2202 +{ +} + +.paragraph_class2203 +{ +} + +.text_class2204 +{ +font-size: 11px; +} + +.text_class2205 +{ +} + +.paragraph_class2206 +{ +} + +.text_class2207 +{ +font-size: 11px; +} + +.text_class2208 +{ +} + +.paragraph_class2209 +{ +} + +.text_class2210 +{ +font-size: 11px; +} + +.text_class2211 +{ +} + +.paragraph_class2212 +{ +} + +.text_class2213 +{ +font-size: 11px; +} + +.paragraph_class2214 +{ +} + +.text_class2215 +{ +font-size: 11px; +} + +.text_class2216 +{ +} + +.paragraph_class2217 +{ +} + +.text_class2218 +{ +font-size: 11px; +} + +.text_class2219 +{ +} + +.paragraph_class2220 +{ +} + +.text_class2221 +{ +font-size: 11px; +} + +.text_class2222 +{ +} + +.paragraph_class2223 +{ +} + +.text_class2224 +{ +font-size: 11px; +} + +.text_class2225 +{ +} + +.paragraph_class2226 +{ +} + +.text_class2227 +{ +font-size: 11px; +} + +.text_class2228 +{ +} + +.paragraph_class2229 +{ +} + +.text_class2230 +{ +font-size: 11px; +} + +.text_class2231 +{ +} + +.paragraph_class2232 +{ +} + +.text_class2233 +{ +font-size: 11px; +} + +.text_class2234 +{ +} + +.paragraph_class2235 +{ +} + +.text_class2236 +{ +font-size: 11px; +} + +.text_class2237 +{ +} + +.paragraph_class2238 +{ +} + +.text_class2239 +{ +font-size: 11px; +} + +.text_class2240 +{ +} + +.paragraph_class2241 +{ +} + +.text_class2242 +{ +font-size: 11px; +} + +.text_class2243 +{ +} + +.paragraph_class2244 +{ +} + +.text_class2245 +{ +font-size: 11px; +} + +.text_class2246 +{ +} + +.paragraph_class2247 +{ +} + +.text_class2248 +{ +font-size: 11px; +} + +.text_class2249 +{ +} + +.paragraph_class2250 +{ +} + +.text_class2251 +{ +font-size: 11px; +} + +.text_class2252 +{ +} + +.paragraph_class2253 +{ +} + +.text_class2254 +{ +font-size: 11px; +} + +.paragraph_class2255 +{ +} + +.text_class2256 +{ +font-size: 11px; +} + +.text_class2257 +{ +} + +.paragraph_class2258 +{ +} + +.text_class2259 +{ +font-size: 11px; +} + +.text_class2260 +{ +} + +.paragraph_class2261 +{ +} + +.text_class2262 +{ +font-size: 11px; +} + +.text_class2263 +{ +} + +.paragraph_class2264 +{ +} + +.text_class2265 +{ +font-size: 11px; +} + +.text_class2266 +{ +} + +.paragraph_class2267 +{ +} + +.text_class2268 +{ +font-size: 11px; +} + +.paragraph_class2269 +{ +} + +.text_class2270 +{ +font-size: 11px; +} + +.paragraph_class2271 +{ +} + +.text_class2272 +{ +font-size: 11px; +} + +.text_class2273 +{ +} + +.paragraph_class2274 +{ +} + +.text_class2275 +{ +font-size: 11px; +} + +.text_class2276 +{ +} + +.paragraph_class2277 +{ +} + +.text_class2278 +{ +font-size: 11px; +} + +.text_class2279 +{ +} + +.paragraph_class2280 +{ +} + +.text_class2281 +{ +font-size: 11px; +} + +.text_class2282 +{ +} + +.paragraph_class2283 +{ +} + +.text_class2284 +{ +font-size: 11px; +} + +.text_class2285 +{ +} + +.paragraph_class2286 +{ +} + +.text_class2287 +{ +font-size: 11px; +} + +.text_class2288 +{ +} + +.paragraph_class2289 +{ +} + +.text_class2290 +{ +font-size: 11px; +} + +.text_class2291 +{ +} + +.paragraph_class2292 +{ +} + +.text_class2293 +{ +font-size: 11px; +} + +.text_class2294 +{ +} + +.paragraph_class2295 +{ +} + +.text_class2296 +{ +font-size: 11px; +} + +.text_class2297 +{ +} + +.paragraph_class2298 +{ +} + +.text_class2299 +{ +font-size: 11px; +} + +.text_class2300 +{ +} + +.paragraph_class2301 +{ +} + +.text_class2302 +{ +font-size: 11px; +} + +.text_class2303 +{ +} + +.paragraph_class2304 +{ +} + +.text_class2305 +{ +font-size: 11px; +} + +.text_class2306 +{ +} + +.paragraph_class2307 +{ +} + +.text_class2308 +{ +font-size: 11px; +} + +.text_class2309 +{ +} + +.text_class2310 +{ +} + +.paragraph_class2311 +{ +} + +.text_class2312 +{ +font-size: 11px; +} + +.paragraph_class2313 +{ +} + +.paragraph_class2314 +{ +} + +.text_class2315 +{ +font-size: 11px; +} + +.text_class2316 +{ +font-family: arial; +} + +.paragraph_class2317 +{ +} + +.text_class2318 +{ +font-size: 11px; +} + +.text_class2319 +{ +font-family: arial; +} + +.text_class2320 +{ +} + +.text_class2321 +{ +} + +.paragraph_class2322 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2323 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2324 +{ +} + +.paragraph_class2325 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2326 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2327 +{ +} + +.paragraph_class2328 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2329 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2330 +{ +} + +.paragraph_class2332 +{ +margin-left: 0px; +} + +.text_class2333 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2334 +{ +font-weight: bold; +} + +.paragraph_class2336 +{ +margin-left: 0px; +} + +.text_class2337 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2338 +{ +font-weight: bold; +} + +.paragraph_class2340 +{ +margin-left: 0px; +} + +.text_class2341 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2342 +{ +font-weight: bold; +} + +.paragraph_class2343 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2344 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2345 +{ +margin-left: 0px; +} + +.text_class2346 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2347 +{ +margin-left: 0px; +} + +.text_class2348 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2349 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2350 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2351 +{ +margin-left: 0px; +} + +.text_class2352 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2353 +{ +margin-left: 0px; +} + +.text_class2354 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2355 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2356 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2357 +{ +margin-left: 0px; +} + +.text_class2358 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2359 +{ +margin-left: 0px; +} + +.text_class2360 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2361 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2362 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2363 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2364 +{ +margin-left: 0px; +} + +.text_class2365 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2366 +{ +margin-left: 0px; +} + +.text_class2367 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2368 +{ +} + +.text_class2369 +{ +font-size: 11px; +} + +.text_class2370 +{ +} + +.text_class2371 +{ +font-size: 11px; +} + +.text_class2372 +{ +} + +.paragraph_class2373 +{ +} + +.text_class2374 +{ +font-family: arial; +} + +.text_class2375 +{ +font-size: 11px; +} + +.paragraph_class2376 +{ +} + +.text_class2377 +{ +font-family: arial; +} + +.text_class2378 +{ +font-size: 11px; +} + +.text_class2379 +{ +} + +.paragraph_class2380 +{ +} + +.text_class2381 +{ +font-family: arial; +} + +.text_class2382 +{ +font-size: 11px; +} + +.paragraph_class2383 +{ +} + +.text_class2384 +{ +font-family: arial; +} + +.text_class2385 +{ +font-size: 11px; +} + +.paragraph_class2386 +{ +} + +.text_class2387 +{ +font-family: arial; +} + +.text_class2388 +{ +font-size: 11px; +} + +.text_class2389 +{ +} + +.paragraph_class2390 +{ +} + +.text_class2391 +{ +font-family: arial; +} + +.text_class2392 +{ +font-size: 11px; +} + +.paragraph_class2393 +{ +} + +.text_class2394 +{ +font-family: arial; +} + +.text_class2395 +{ +font-size: 11px; +} + +.text_class2396 +{ +} + +.paragraph_class2397 +{ +} + +.text_class2398 +{ +font-family: arial; +} + +.text_class2399 +{ +font-size: 11px; +} + +.text_class2400 +{ +} + +.paragraph_class2401 +{ +} + +.text_class2402 +{ +font-family: arial; +} + +.text_class2403 +{ +font-size: 11px; +} + +.paragraph_class2404 +{ +} + +.text_class2405 +{ +font-family: arial; +} + +.text_class2406 +{ +font-size: 11px; +} + +.text_class2407 +{ +} + +.paragraph_class2408 +{ +} + +.text_class2409 +{ +font-family: arial; +} + +.text_class2410 +{ +font-size: 11px; +} + +.paragraph_class2411 +{ +} + +.text_class2412 +{ +font-family: arial; +} + +.text_class2413 +{ +font-size: 11px; +} + +.text_class2414 +{ +font-family: arial; +} + +.text_class2415 +{ +font-size: 11px; +} + +.text_class2416 +{ +font-family: arial; +} + +.text_class2417 +{ +font-size: 11px; +} + +.paragraph_class2418 +{ +} + +.text_class2419 +{ +font-family: arial; +} + +.text_class2420 +{ +font-size: 11px; +} + +.text_class2421 +{ +} + +.text_class2422 +{ +} + +.paragraph_class2423 +{ +} + +.text_class2424 +{ +font-family: arial; +} + +.text_class2425 +{ +font-size: 11px; +} + +.text_class2426 +{ +} + +.paragraph_class2427 +{ +} + +.text_class2428 +{ +font-family: arial; +} + +.text_class2429 +{ +font-size: 11px; +} + +.text_class2430 +{ +} + +.paragraph_class2431 +{ +} + +.text_class2432 +{ +font-family: arial; +} + +.text_class2433 +{ +font-size: 11px; +} + +.paragraph_class2434 +{ +} + +.text_class2435 +{ +font-family: arial; +} + +.text_class2436 +{ +font-size: 11px; +} + +.text_class2437 +{ +} + +.paragraph_class2438 +{ +} + +.text_class2439 +{ +font-family: arial; +} + +.text_class2440 +{ +font-size: 11px; +} + +.paragraph_class2441 +{ +} + +.text_class2442 +{ +font-family: arial; +} + +.text_class2443 +{ +font-size: 11px; +} + +.text_class2444 +{ +} + +.paragraph_class2445 +{ +} + +.text_class2446 +{ +font-family: arial; +} + +.text_class2447 +{ +font-size: 11px; +} + +.paragraph_class2448 +{ +} + +.text_class2449 +{ +font-family: arial; +} + +.text_class2450 +{ +font-size: 11px; +} + +.text_class2451 +{ +} + +.text_class2452 +{ +} + +.paragraph_class2453 +{ +} + +.text_class2454 +{ +font-family: arial; +} + +.text_class2455 +{ +font-size: 11px; +} + +.paragraph_class2456 +{ +} + +.text_class2457 +{ +font-family: arial; +} + +.text_class2458 +{ +font-size: 11px; +} + +.text_class2459 +{ +} + +.paragraph_class2460 +{ +} + +.text_class2461 +{ +font-family: arial; +} + +.text_class2462 +{ +font-size: 11px; +} + +.text_class2463 +{ +} + +.text_class2464 +{ +} + +.paragraph_class2465 +{ +} + +.text_class2466 +{ +font-family: arial; +} + +.text_class2467 +{ +font-size: 11px; +} + +.text_class2468 +{ +} + +.text_class2469 +{ +} + +.paragraph_class2470 +{ +} + +.text_class2471 +{ +font-size: 11px; +} + +.text_class2472 +{ +} + +.text_class2473 +{ +} + +.paragraph_class2474 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2475 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2476 +{ +} + +.paragraph_class2477 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2478 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2479 +{ +} + +.paragraph_class2481 +{ +margin-left: 0px; +} + +.text_class2482 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2483 +{ +font-weight: bold; +} + +.cell_class2484 +{ +width: 95px; +} + +.paragraph_class2486 +{ +margin-left: 0px; +} + +.text_class2487 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2488 +{ +font-weight: bold; +} + +.cell_class2489 +{ +width: 140px; +} + +.paragraph_class2491 +{ +margin-left: 0px; +} + +.text_class2492 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2493 +{ +font-weight: bold; +} + +.cell_class2494 +{ +width: 301px; +} + +.paragraph_class2496 +{ +margin-left: 0px; +} + +.text_class2497 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2498 +{ +font-weight: bold; +} + +.paragraph_class2499 +{ +margin-left: 0px; +} + +.text_class2500 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2501 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2502 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2503 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2504 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2505 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2506 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2507 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2508 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2509 +{ +margin-left: 0px; +} + +.text_class2510 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2511 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2512 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2513 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2514 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2515 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2516 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2517 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2518 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2519 +{ +margin-left: 0px; +} + +.text_class2520 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2521 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2522 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2523 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2524 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2525 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2526 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2527 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2528 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2529 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2530 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2531 +{ +margin-left: 0px; +} + +.text_class2532 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2533 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2534 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2535 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2536 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2537 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2538 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2539 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2540 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2541 +{ +} + +.paragraph_class2542 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2543 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2544 +{ +} + +.paragraph_class2545 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2546 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2547 +{ +font-weight: bold; +} + +.text_class2548 +{ +} + +.paragraph_class2550 +{ +margin-left: 0px; +} + +.text_class2551 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2552 +{ +font-weight: bold; +} + +.paragraph_class2554 +{ +margin-left: 0px; +} + +.text_class2555 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2556 +{ +font-weight: bold; +} + +.paragraph_class2558 +{ +margin-left: 0px; +} + +.text_class2559 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2560 +{ +font-weight: bold; +} + +.paragraph_class2561 +{ +margin-left: 0px; +} + +.text_class2562 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2563 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2564 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2565 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2566 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2567 +{ +margin-left: 0px; +} + +.text_class2568 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2569 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2570 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2571 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2572 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2573 +{ +} + +.text_class2574 +{ +} + +.text_class2575 +{ +} + +.paragraph_class2576 +{ +} + +.text_class2577 +{ +font-family: arial; +} + +.text_class2578 +{ +font-size: 11px; +} + +.paragraph_class2579 +{ +} + +.text_class2580 +{ +font-family: arial; +} + +.text_class2581 +{ +font-size: 11px; +} + +.text_class2582 +{ +} + +.text_class2583 +{ +} + +.paragraph_class2584 +{ +} + +.text_class2585 +{ +font-family: arial; +} + +.text_class2586 +{ +font-size: 11px; +} + +.text_class2587 +{ +} + +.paragraph_class2588 +{ +} + +.text_class2589 +{ +font-family: arial; +} + +.text_class2590 +{ +font-size: 11px; +} + +.paragraph_class2591 +{ +} + +.text_class2592 +{ +font-family: arial; +} + +.text_class2593 +{ +font-size: 11px; +} + +.paragraph_class2594 +{ +} + +.text_class2595 +{ +font-family: arial; +} + +.text_class2596 +{ +font-size: 11px; +} + +.text_class2597 +{ +} + +.paragraph_class2598 +{ +} + +.text_class2599 +{ +font-family: arial; +} + +.text_class2600 +{ +font-size: 11px; +} + +.text_class2601 +{ +} + +.paragraph_class2602 +{ +} + +.text_class2603 +{ +font-family: arial; +} + +.text_class2604 +{ +font-size: 11px; +} + +.text_class2605 +{ +} + +.paragraph_class2606 +{ +} + +.text_class2607 +{ +font-family: arial; +} + +.text_class2608 +{ +font-size: 11px; +} + +.paragraph_class2609 +{ +} + +.text_class2610 +{ +font-family: arial; +} + +.text_class2611 +{ +font-size: 11px; +} + +.text_class2612 +{ +} + +.text_class2613 +{ +} + +.text_class2614 +{ +} + +.text_class2615 +{ +} + +.paragraph_class2616 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2617 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2618 +{ +} + +.text_class2619 +{ +} + +.paragraph_class2620 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2621 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2622 +{ +} + +.paragraph_class2623 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2624 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2625 +{ +} + +.paragraph_class2626 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2627 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2628 +{ +} + +.paragraph_class2629 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2630 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2631 +{ +} + +.text_class2632 +{ +} + +.paragraph_class2633 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2634 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2635 +{ +font-weight: bold; +} + +.text_class2636 +{ +} + +.text_class2637 +{ +} + +.paragraph_class2638 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2639 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2640 +{ +} + +.text_class2641 +{ +} + +.paragraph_class2642 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2643 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2644 +{ +font-weight: bold; +} + +.text_class2645 +{ +} + +.text_class2646 +{ +} + +.paragraph_class2647 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2648 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2649 +{ +} + +.text_class2650 +{ +} + +.paragraph_class2651 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2652 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2653 +{ +font-weight: bold; +} + +.text_class2654 +{ +} + +.text_class2655 +{ +} + +.paragraph_class2656 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2657 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2658 +{ +font-weight: bold; +} + +.text_class2659 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2660 +{ +} + +.paragraph_class2661 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2662 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2663 +{ +font-weight: bold; +} + +.text_class2664 +{ +} + +.paragraph_class2666 +{ +margin-left: 0px; +} + +.text_class2667 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2668 +{ +font-weight: bold; +} + +.paragraph_class2670 +{ +margin-left: 0px; +} + +.text_class2671 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2672 +{ +font-weight: bold; +} + +.paragraph_class2674 +{ +margin-left: 0px; +} + +.text_class2675 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2676 +{ +font-weight: bold; +} + +.paragraph_class2677 +{ +margin-left: 0px; +} + +.text_class2678 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2679 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2680 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2681 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2682 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2683 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2684 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2685 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2686 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2687 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2688 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2689 +{ +margin-left: 0px; +} + +.text_class2690 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2691 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2692 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2693 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2694 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2695 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2696 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2697 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2698 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2699 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2700 +{ +margin-left: 0px; +} + +.text_class2701 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2702 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2703 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2704 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2705 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2706 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2707 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2708 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2709 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2710 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2711 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2712 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2713 +{ +margin-left: 0px; +} + +.text_class2714 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2715 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2716 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2717 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2718 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class2719 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class2720 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2721 +{ +} + +.text_class2722 +{ +} + +.text_class2723 +{ +font-size: 11px; +} + +.text_class2724 +{ +} + +.paragraph_class2725 +{ +} + +.text_class2726 +{ +font-family: arial; +} + +.text_class2727 +{ +font-size: 11px; +} + +.text_class2728 +{ +} + +.paragraph_class2729 +{ +} + +.text_class2730 +{ +font-family: arial; +} + +.text_class2731 +{ +font-size: 11px; +} + +.text_class2732 +{ +} + +.paragraph_class2733 +{ +} + +.text_class2734 +{ +font-family: arial; +} + +.text_class2735 +{ +font-size: 11px; +} + +.text_class2736 +{ +} + +.paragraph_class2737 +{ +} + +.text_class2738 +{ +font-family: arial; +} + +.text_class2739 +{ +font-size: 11px; +} + +.text_class2740 +{ +} + +.text_class2741 +{ +font-size: 11px; +} + +.text_class2742 +{ +} + +.paragraph_class2743 +{ +} + +.text_class2744 +{ +font-family: arial; +} + +.text_class2745 +{ +font-size: 11px; +} + +.text_class2746 +{ +} + +.paragraph_class2747 +{ +} + +.text_class2748 +{ +font-family: arial; +} + +.text_class2749 +{ +font-size: 11px; +} + +.paragraph_class2750 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2751 +{ +font-size: 11px; +} + +.text_class2752 +{ +font-family: arial; +} + +.text_class2753 +{ +font-size: 11px; +} + +.paragraph_class2754 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2755 +{ +font-size: 11px; +} + +.text_class2756 +{ +font-family: arial; +} + +.text_class2757 +{ +font-size: 11px; +} + +.paragraph_class2758 +{ +} + +.text_class2759 +{ +font-family: arial; +} + +.text_class2760 +{ +font-size: 11px; +} + +.text_class2761 +{ +} + +.paragraph_class2762 +{ +} + +.text_class2763 +{ +font-family: arial; +} + +.text_class2764 +{ +font-size: 11px; +} + +.text_class2765 +{ +} + +.paragraph_class2766 +{ +} + +.text_class2767 +{ +font-family: arial; +} + +.text_class2768 +{ +font-size: 11px; +} + +.text_class2769 +{ +} + +.paragraph_class2770 +{ +} + +.text_class2771 +{ +font-family: arial; +} + +.text_class2772 +{ +font-size: 11px; +} + +.paragraph_class2773 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2774 +{ +font-size: 11px; +} + +.text_class2775 +{ +font-family: arial; +} + +.text_class2776 +{ +font-size: 11px; +} + +.paragraph_class2777 +{ +} + +.text_class2778 +{ +font-family: arial; +} + +.text_class2779 +{ +font-size: 11px; +} + +.text_class2780 +{ +} + +.paragraph_class2781 +{ +} + +.text_class2782 +{ +font-family: arial; +} + +.text_class2783 +{ +font-size: 11px; +} + +.text_class2784 +{ +} + +.paragraph_class2785 +{ +} + +.text_class2786 +{ +font-family: arial; +} + +.text_class2787 +{ +font-size: 11px; +} + +.text_class2788 +{ +} + +.paragraph_class2789 +{ +} + +.text_class2790 +{ +font-family: arial; +} + +.text_class2791 +{ +font-size: 11px; +} + +.text_class2792 +{ +} + +.text_class2793 +{ +font-size: 11px; +} + +.text_class2794 +{ +} + +.paragraph_class2795 +{ +} + +.text_class2796 +{ +font-family: arial; +} + +.text_class2797 +{ +font-size: 11px; +} + +.paragraph_class2798 +{ +} + +.text_class2799 +{ +font-family: arial; +} + +.text_class2800 +{ +font-size: 11px; +} + +.text_class2801 +{ +} + +.paragraph_class2802 +{ +} + +.text_class2803 +{ +font-family: arial; +} + +.text_class2804 +{ +font-size: 11px; +} + +.paragraph_class2805 +{ +} + +.text_class2806 +{ +font-family: arial; +} + +.text_class2807 +{ +font-size: 11px; +} + +.text_class2808 +{ +} + +.paragraph_class2809 +{ +} + +.text_class2810 +{ +font-family: arial; +} + +.text_class2811 +{ +font-size: 11px; +} + +.paragraph_class2812 +{ +} + +.text_class2813 +{ +font-family: arial; +} + +.text_class2814 +{ +font-size: 11px; +} + +.paragraph_class2815 +{ +} + +.text_class2816 +{ +font-family: arial; +} + +.text_class2817 +{ +font-size: 11px; +} + +.text_class2818 +{ +} + +.paragraph_class2819 +{ +} + +.text_class2820 +{ +font-family: arial; +} + +.text_class2821 +{ +font-size: 11px; +} + +.paragraph_class2822 +{ +} + +.text_class2823 +{ +font-family: arial; +} + +.text_class2824 +{ +font-size: 11px; +} + +.text_class2825 +{ +} + +.text_class2826 +{ +font-size: 11px; +} + +.text_class2827 +{ +} + +.paragraph_class2828 +{ +} + +.text_class2829 +{ +font-family: arial; +} + +.text_class2830 +{ +font-size: 11px; +} + +.text_class2831 +{ +} + +.paragraph_class2832 +{ +} + +.text_class2833 +{ +font-family: arial; +} + +.text_class2834 +{ +font-size: 11px; +} + +.paragraph_class2835 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2836 +{ +font-size: 11px; +} + +.text_class2837 +{ +font-family: arial; +} + +.text_class2838 +{ +font-size: 11px; +} + +.paragraph_class2839 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2840 +{ +font-size: 11px; +} + +.text_class2841 +{ +font-family: arial; +} + +.text_class2842 +{ +font-size: 11px; +} + +.paragraph_class2843 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2844 +{ +font-size: 11px; +} + +.text_class2845 +{ +font-family: arial; +} + +.text_class2846 +{ +font-size: 11px; +} + +.paragraph_class2847 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class2848 +{ +font-size: 11px; +} + +.text_class2849 +{ +font-family: arial; +} + +.text_class2850 +{ +font-size: 11px; +} + +.text_class2851 +{ +} + +.paragraph_class2852 +{ +} + +.text_class2853 +{ +font-family: arial; +} + +.text_class2854 +{ +font-size: 11px; +} + +.text_class2855 +{ +} + +.text_class2856 +{ +} + +.paragraph_class2857 +{ +} + +.text_class2858 +{ +font-size: 11px; +} + +.text_class2859 +{ +font-family: arial; +} + +.text_class2860 +{ +} + +.text_class2861 +{ +} + +.paragraph_class2862 +{ +} + +.text_class2863 +{ +font-size: 11px; +} + +.text_class2864 +{ +font-family: arial; +} + +.text_class2865 +{ +font-family: arial; +} + +.text_class2866 +{ +font-family: arial; +} + +.paragraph_class2867 +{ +} + +.paragraph_class2868 +{ +} + +.text_class2869 +{ +font-size: 11px; +} + +.text_class2870 +{ +font-family: arial; +} + +.text_class2871 +{ +} + +.text_class2872 +{ +} + +.paragraph_class2873 +{ +text-align: center; +margin-left: 0px; +} + +.text_class2874 +{ +font-size: 11px; +font-family: arial; +} + +.text_class2875 +{ +font-weight: bold; +} + +.text_class2876 +{ +} + +.text_class2877 +{ +} + +.paragraph_class2878 +{ +} + +.text_class2879 +{ +font-size: 11px; +} + +.text_class2880 +{ +font-family: arial; +} + +.text_class2881 +{ +font-size: 11px; +} + +.text_class2882 +{ +font-family: arial; +} + +.text_class2883 +{ +font-size: 11px; +} + +.text_class2884 +{ +font-family: arial; +} + +.text_class2885 +{ +font-family: arial; +} + +.text_class2886 +{ +} + +.paragraph_class2887 +{ +} + +.text_class2888 +{ +font-family: arial; +} + +.text_class2889 +{ +font-size: 11px; +} + +.text_class2890 +{ +font-family: arial; +} + +.text_class2891 +{ +font-size: 11px; +} + +.text_class2892 +{ +font-family: arial; +} + +.text_class2893 +{ +font-size: 11px; +} + +.text_class2894 +{ +font-family: arial; +} + +.text_class2895 +{ +font-size: 11px; +} + +.text_class2896 +{ +font-family: arial; +} + +.text_class2897 +{ +font-size: 11px; +} + +.text_class2898 +{ +font-family: arial; +} + +.text_class2899 +{ +font-size: 11px; +} + +.text_class2900 +{ +font-family: arial; +} + +.text_class2901 +{ +font-size: 11px; +} + +.text_class2902 +{ +font-family: arial; +} + +.text_class2903 +{ +font-size: 11px; +} + +.text_class2904 +{ +font-family: arial; +} + +.text_class2905 +{ +font-size: 11px; +} + +.text_class2906 +{ +} + +.paragraph_class2907 +{ +} + +.text_class2908 +{ +font-family: arial; +} + +.text_class2909 +{ +font-size: 11px; +} + +.text_class2910 +{ +font-family: arial; +} + +.text_class2911 +{ +font-size: 11px; +} + +.text_class2912 +{ +font-family: arial; +} + +.text_class2913 +{ +font-size: 11px; +} + +.text_class2914 +{ +font-family: arial; +} + +.text_class2915 +{ +font-size: 11px; +} + +.text_class2916 +{ +font-family: arial; +} + +.text_class2917 +{ +font-size: 11px; +} + +.text_class2918 +{ +} + +.paragraph_class2919 +{ +} + +.text_class2920 +{ +font-family: arial; +} + +.text_class2921 +{ +font-size: 11px; +} + +.text_class2922 +{ +} + +.paragraph_class2923 +{ +} + +.text_class2924 +{ +font-family: arial; +} + +.text_class2925 +{ +font-size: 11px; +} + +.text_class2926 +{ +font-family: arial; +} + +.text_class2927 +{ +font-size: 11px; +} + +.text_class2928 +{ +font-family: arial; +} + +.text_class2929 +{ +font-size: 11px; +} + +.text_class2930 +{ +font-family: arial; +} + +.text_class2931 +{ +font-size: 11px; +} + +.text_class2932 +{ +} + +.paragraph_class2933 +{ +} + +.text_class2934 +{ +font-family: arial; +} + +.text_class2935 +{ +font-size: 11px; +} + +.text_class2936 +{ +font-family: arial; +} + +.text_class2937 +{ +font-size: 11px; +} + +.text_class2938 +{ +font-family: arial; +} + +.text_class2939 +{ +font-size: 11px; +} + +.text_class2940 +{ +font-family: arial; +} + +.text_class2941 +{ +font-size: 11px; +} + +.text_class2942 +{ +font-family: arial; +} + +.text_class2943 +{ +font-size: 11px; +} + +.text_class2944 +{ +font-family: arial; +} + +.text_class2945 +{ +font-size: 11px; +} + +.paragraph_class2946 +{ +} + +.paragraph_class2947 +{ +} + +.text_class2948 +{ +font-family: arial; +} + +.text_class2949 +{ +font-size: 11px; +} + +.text_class2950 +{ +font-family: arial; +} + +.text_class2951 +{ +font-size: 11px; +} + +.text_class2952 +{ +font-family: arial; +} + +.text_class2953 +{ +font-size: 11px; +} + +.text_class2954 +{ +font-family: arial; +} + +.text_class2955 +{ +font-size: 11px; +} + +.text_class2956 +{ +font-family: arial; +} + +.text_class2957 +{ +font-size: 11px; +} + +.text_class2958 +{ +font-family: arial; +} + +.text_class2959 +{ +font-size: 11px; +} + +.text_class2960 +{ +} + +.paragraph_class2961 +{ +} + +.text_class2962 +{ +font-family: arial; +} + +.text_class2963 +{ +font-size: 11px; +} + +.text_class2964 +{ +} + +.paragraph_class2965 +{ +} + +.text_class2966 +{ +font-family: arial; +} + +.text_class2967 +{ +font-size: 11px; +} + +.text_class2968 +{ +} + +.paragraph_class2969 +{ +} + +.text_class2970 +{ +font-family: arial; +} + +.text_class2971 +{ +font-size: 11px; +} + +.text_class2972 +{ +} + +.paragraph_class2973 +{ +} + +.text_class2974 +{ +font-family: arial; +} + +.text_class2975 +{ +font-size: 11px; +} + +.text_class2976 +{ +} + +.paragraph_class2977 +{ +} + +.text_class2978 +{ +font-family: arial; +} + +.text_class2979 +{ +font-size: 11px; +} + +.text_class2980 +{ +} + +.paragraph_class2981 +{ +} + +.text_class2982 +{ +font-family: arial; +} + +.text_class2983 +{ +font-size: 11px; +} + +.text_class2984 +{ +} + +.paragraph_class2985 +{ +} + +.text_class2986 +{ +font-family: arial; +} + +.text_class2987 +{ +font-size: 11px; +} + +.text_class2988 +{ +} + +.paragraph_class2989 +{ +} + +.text_class2990 +{ +font-family: arial; +} + +.text_class2991 +{ +font-size: 11px; +} + +.text_class2992 +{ +} + +.paragraph_class2993 +{ +} + +.text_class2994 +{ +font-family: arial; +} + +.text_class2995 +{ +font-size: 11px; +} + +.text_class2996 +{ +} + +.paragraph_class2997 +{ +} + +.text_class2998 +{ +font-family: arial; +} + +.text_class2999 +{ +font-size: 11px; +} + +.text_class3000 +{ +} + +.paragraph_class3001 +{ +} + +.text_class3002 +{ +font-family: arial; +} + +.text_class3003 +{ +font-size: 11px; +} + +.text_class3004 +{ +} + +.paragraph_class3005 +{ +} + +.text_class3006 +{ +font-family: arial; +} + +.text_class3007 +{ +font-size: 11px; +} + +.text_class3008 +{ +} + +.paragraph_class3009 +{ +} + +.text_class3010 +{ +font-family: arial; +} + +.text_class3011 +{ +font-size: 11px; +} + +.text_class3012 +{ +} + +.paragraph_class3013 +{ +} + +.text_class3014 +{ +font-family: arial; +} + +.text_class3015 +{ +font-size: 11px; +} + +.text_class3016 +{ +} + +.paragraph_class3017 +{ +} + +.text_class3018 +{ +font-family: arial; +} + +.text_class3019 +{ +font-size: 11px; +} + +.text_class3020 +{ +} + +.paragraph_class3021 +{ +} + +.text_class3022 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3023 +{ +} + +.paragraph_class3024 +{ +} + +.text_class3025 +{ +font-family: arial; +} + +.text_class3026 +{ +font-size: 11px; +} + +.text_class3027 +{ +} + +.paragraph_class3028 +{ +} + +.text_class3029 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3030 +{ +} + +.text_class3031 +{ +} + +.paragraph_class3032 +{ +} + +.text_class3033 +{ +font-size: 11px; +} + +.text_class3034 +{ +} + +.text_class3035 +{ +} + +.paragraph_class3036 +{ +} + +.text_class3037 +{ +font-size: 11px; +} + +.text_class3038 +{ +} + +.paragraph_class3039 +{ +} + +.text_class3040 +{ +font-size: 11px; +} + +.text_class3041 +{ +} + +.paragraph_class3042 +{ +} + +.text_class3043 +{ +font-size: 11px; +} + +.text_class3044 +{ +font-family: arial; +} + +.text_class3045 +{ +} + +.paragraph_class3046 +{ +} + +.text_class3047 +{ +font-size: 11px; +} + +.text_class3048 +{ +font-family: arial; +} + +.text_class3049 +{ +} + +.paragraph_class3050 +{ +} + +.text_class3051 +{ +font-family: arial; +} + +.text_class3052 +{ +font-size: 11px; +} + +.paragraph_class3053 +{ +} + +.text_class3054 +{ +font-family: arial; +} + +.text_class3055 +{ +font-size: 11px; +} + +.text_class3056 +{ +font-family: arial; +} + +.text_class3057 +{ +font-size: 11px; +} + +.text_class3058 +{ +font-family: arial; +} + +.text_class3059 +{ +font-size: 11px; +} + +.text_class3060 +{ +font-family: arial; +} + +.text_class3061 +{ +font-size: 11px; +} + +.text_class3062 +{ +font-family: arial; +} + +.text_class3063 +{ +font-size: 11px; +} + +.text_class3064 +{ +font-family: arial; +} + +.text_class3065 +{ +font-size: 11px; +} + +.text_class3066 +{ +font-family: arial; +} + +.text_class3067 +{ +font-size: 11px; +} + +.text_class3068 +{ +font-family: arial; +} + +.text_class3069 +{ +font-size: 11px; +} + +.text_class3070 +{ +font-family: arial; +} + +.text_class3071 +{ +font-size: 11px; +} + +.text_class3072 +{ +font-family: arial; +} + +.text_class3073 +{ +font-size: 11px; +} + +.text_class3074 +{ +font-family: arial; +} + +.text_class3075 +{ +font-size: 11px; +} + +.text_class3076 +{ +font-family: arial; +} + +.text_class3077 +{ +font-size: 11px; +} + +.text_class3078 +{ +font-family: arial; +} + +.text_class3079 +{ +font-size: 11px; +} + +.text_class3080 +{ +font-family: arial; +} + +.text_class3081 +{ +font-size: 11px; +} + +.text_class3082 +{ +} + +.text_class3083 +{ +} + +.paragraph_class3084 +{ +} + +.text_class3085 +{ +font-size: 11px; +} + +.text_class3086 +{ +} + +.text_class3087 +{ +} + +.paragraph_class3088 +{ +} + +.text_class3089 +{ +font-size: 11px; +} + +.text_class3090 +{ +} + +.text_class3091 +{ +} + +.paragraph_class3092 +{ +} + +.text_class3093 +{ +font-family: arial; +} + +.text_class3094 +{ +font-size: 11px; +} + +.paragraph_class3095 +{ +} + +.text_class3096 +{ +font-family: arial; +} + +.text_class3097 +{ +font-size: 11px; +} + +.text_class3098 +{ +font-family: arial; +} + +.text_class3099 +{ +font-size: 11px; +} + +.text_class3100 +{ +font-family: arial; +} + +.text_class3101 +{ +font-size: 11px; +} + +.text_class3102 +{ +font-family: arial; +} + +.text_class3103 +{ +font-size: 11px; +} + +.text_class3104 +{ +font-family: arial; +} + +.text_class3105 +{ +font-size: 11px; +} + +.text_class3106 +{ +font-family: arial; +} + +.text_class3107 +{ +font-size: 11px; +} + +.text_class3108 +{ +font-family: arial; +} + +.text_class3109 +{ +font-size: 11px; +} + +.text_class3110 +{ +font-family: arial; +} + +.text_class3111 +{ +font-size: 11px; +} + +.text_class3112 +{ +font-family: arial; +} + +.text_class3113 +{ +font-size: 11px; +} + +.text_class3114 +{ +font-family: arial; +} + +.text_class3115 +{ +font-size: 11px; +} + +.text_class3116 +{ +font-family: arial; +} + +.text_class3117 +{ +font-size: 11px; +} + +.text_class3118 +{ +font-family: arial; +} + +.text_class3119 +{ +font-size: 11px; +} + +.text_class3120 +{ +font-family: arial; +} + +.text_class3121 +{ +font-size: 11px; +} + +.text_class3122 +{ +font-family: arial; +} + +.text_class3123 +{ +font-size: 11px; +} + +.text_class3124 +{ +} + +.text_class3125 +{ +} + +.paragraph_class3126 +{ +} + +.text_class3127 +{ +font-size: 11px; +} + +.text_class3128 +{ +} + +.text_class3129 +{ +} + +.paragraph_class3130 +{ +} + +.text_class3131 +{ +font-size: 11px; +} + +.text_class3132 +{ +} + +.text_class3133 +{ +} + +.paragraph_class3134 +{ +} + +.text_class3135 +{ +font-size: 11px; +} + +.text_class3136 +{ +} + +.text_class3137 +{ +} + +.paragraph_class3138 +{ +} + +.text_class3139 +{ +font-size: 11px; +} + +.text_class3140 +{ +} + +.text_class3141 +{ +} + +.paragraph_class3142 +{ +} + +.text_class3143 +{ +font-size: 11px; +} + +.paragraph_class3144 +{ +} + +.text_class3145 +{ +font-size: 11px; +} + +.paragraph_class3146 +{ +} + +.text_class3147 +{ +} + +.paragraph_class3148 +{ +} + +.text_class3149 +{ +font-size: 11px; +} + +.text_class3150 +{ +font-size: 11px; +} + +.text_class3151 +{ +font-size: 11px; +} + +.text_class3152 +{ +font-size: 11px; +} + +.text_class3153 +{ +font-size: 11px; +} + +.text_class3154 +{ +font-size: 11px; +} + +.text_class3155 +{ +font-size: 11px; +} + +.text_class3156 +{ +font-size: 11px; +} + +.paragraph_class3157 +{ +} + +.text_class3158 +{ +font-size: 11px; +} + +.text_class3159 +{ +font-size: 11px; +} + +.text_class3160 +{ +font-size: 11px; +} + +.text_class3161 +{ +} + +.paragraph_class3162 +{ +} + +.text_class3163 +{ +font-size: 11px; +} + +.text_class3164 +{ +} + +.paragraph_class3165 +{ +} + +.text_class3166 +{ +font-size: 11px; +} + +.text_class3167 +{ +} + +.paragraph_class3168 +{ +} + +.text_class3169 +{ +font-size: 11px; +} + +.text_class3170 +{ +} + +.paragraph_class3171 +{ +} + +.text_class3172 +{ +font-size: 11px; +} + +.text_class3173 +{ +} + +.paragraph_class3174 +{ +} + +.text_class3175 +{ +font-size: 11px; +} + +.paragraph_class3176 +{ +} + +.text_class3177 +{ +font-size: 11px; +} + +.paragraph_class3178 +{ +} + +.text_class3179 +{ +font-size: 11px; +} + +.paragraph_class3180 +{ +} + +.text_class3181 +{ +font-size: 11px; +} + +.paragraph_class3182 +{ +} + +.text_class3183 +{ +font-size: 11px; +} + +.paragraph_class3184 +{ +} + +.text_class3185 +{ +font-size: 11px; +} + +.paragraph_class3186 +{ +} + +.text_class3187 +{ +font-size: 11px; +} + +.text_class3188 +{ +} + +.paragraph_class3189 +{ +} + +.text_class3190 +{ +font-size: 11px; +} + +.text_class3191 +{ +} + +.paragraph_class3192 +{ +} + +.text_class3193 +{ +font-size: 11px; +} + +.text_class3194 +{ +} + +.text_class3195 +{ +} + +.paragraph_class3196 +{ +} + +.text_class3197 +{ +font-size: 11px; +} + +.paragraph_class3198 +{ +} + +.text_class3199 +{ +font-size: 11px; +} + +.paragraph_class3200 +{ +} + +.text_class3201 +{ +font-size: 11px; +} + +.paragraph_class3202 +{ +} + +.text_class3203 +{ +font-size: 11px; +} + +.text_class3204 +{ +} + +.paragraph_class3205 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3206 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3207 +{ +font-weight: bold; +} + +.text_class3208 +{ +} + +.cell_class3209 +{ +width: 53px; +background-color: #c0c0c0; +} + +.paragraph_class3211 +{ +margin-left: 0px; +} + +.paragraph_class3212 +{ +margin-left: 0px; +} + +.text_class3213 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3214 +{ +font-weight: bold; +} + +.cell_class3215 +{ +width: 340px; +background-color: #c0c0c0; +} + +.paragraph_class3217 +{ +margin-left: 0px; +} + +.text_class3218 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3219 +{ +font-weight: bold; +} + +.cell_class3220 +{ +width: 111px; +background-color: #c0c0c0; +} + +.paragraph_class3222 +{ +margin-left: 0px; +} + +.text_class3223 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3224 +{ +font-weight: bold; +} + +.cell_class3225 +{ +width: 54px; +background-color: #c0c0c0; +} + +.paragraph_class3227 +{ +margin-left: 0px; +} + +.text_class3228 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3229 +{ +font-weight: bold; +} + +.cell_class3230 +{ +width: 53px; +} + +.paragraph_class3231 +{ +margin-left: 0px; +} + +.text_class3232 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3233 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3234 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3235 +{ +width: 111px; +} + +.paragraph_class3236 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3237 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3238 +{ +width: 54px; +} + +.paragraph_class3239 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3240 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3241 +{ +margin-left: 0px; +} + +.text_class3242 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3243 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3244 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3245 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3246 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3247 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3248 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3249 +{ +margin-left: 0px; +} + +.text_class3250 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3251 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3252 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3253 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3254 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3255 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3256 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3257 +{ +margin-left: 0px; +} + +.text_class3258 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3259 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3260 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3261 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3262 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3263 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3264 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3265 +{ +margin-left: 0px; +} + +.text_class3266 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3267 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3268 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3269 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3270 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3271 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3272 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3273 +{ +margin-left: 0px; +} + +.text_class3274 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3275 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3276 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3277 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3278 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3279 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3280 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3281 +{ +margin-left: 0px; +} + +.text_class3282 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3283 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3284 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3285 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3286 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3287 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3288 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3289 +{ +margin-left: 0px; +} + +.text_class3290 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3291 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3292 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3293 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3294 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3295 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3296 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3297 +{ +margin-left: 0px; +} + +.text_class3298 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3299 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3300 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3301 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3302 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3303 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3304 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3305 +{ +margin-left: 0px; +} + +.text_class3306 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3307 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3308 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3309 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3310 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3311 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3312 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3313 +{ +margin-left: 0px; +} + +.text_class3314 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3315 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3316 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3317 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3318 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3319 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3320 +{ +font-size: 11px; +} + +.paragraph_class3321 +{ +margin-left: 0px; +} + +.text_class3322 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3323 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3324 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3325 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3326 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3327 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3328 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3329 +{ +margin-left: 0px; +} + +.text_class3330 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3331 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3332 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3333 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3334 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3335 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3336 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3337 +{ +margin-left: 0px; +} + +.text_class3338 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3339 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3340 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3341 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3342 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3343 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3344 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3345 +{ +margin-left: 0px; +} + +.text_class3346 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3347 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3348 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3349 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3350 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3351 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3352 +{ +font-size: 11px; +} + +.paragraph_class3353 +{ +margin-left: 0px; +} + +.text_class3354 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3355 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3356 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3357 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3358 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3359 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3360 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3361 +{ +margin-left: 0px; +} + +.text_class3362 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3363 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3364 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3365 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3366 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3367 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3368 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3369 +{ +margin-left: 0px; +} + +.text_class3370 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3371 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3372 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3373 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3374 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3375 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3376 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3377 +{ +margin-left: 0px; +} + +.text_class3378 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3379 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3380 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3381 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3382 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3383 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3384 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3385 +{ +margin-left: 0px; +} + +.text_class3386 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3387 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3388 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3389 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3390 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3391 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3392 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3393 +{ +margin-left: 0px; +} + +.text_class3394 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3395 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3396 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3397 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3398 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3399 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3400 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3401 +{ +margin-left: 0px; +} + +.text_class3402 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3403 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3404 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3405 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3406 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3407 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3408 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3409 +{ +margin-left: 0px; +} + +.text_class3410 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3411 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3412 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3413 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3414 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3415 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3416 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3417 +{ +margin-left: 0px; +} + +.text_class3418 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3419 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3420 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3421 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3422 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3423 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3424 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3425 +{ +margin-left: 0px; +} + +.text_class3426 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3427 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3428 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3429 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3430 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3431 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3432 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3433 +{ +} + +.paragraph_class3434 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3435 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3436 +{ +} + +.paragraph_class3437 +{ +} + +.text_class3438 +{ +font-size: 11px; +} + +.text_class3439 +{ +font-size: 11px; +} + +.text_class3440 +{ +font-size: 11px; +} + +.text_class3441 +{ +font-size: 11px; +} + +.text_class3442 +{ +font-size: 11px; +} + +.paragraph_class3443 +{ +} + +.text_class3444 +{ +font-size: 11px; +} + +.paragraph_class3445 +{ +} + +.text_class3446 +{ +font-size: 11px; +} + +.text_class3447 +{ +} + +.paragraph_class3448 +{ +} + +.text_class3449 +{ +font-size: 11px; +} + +.text_class3450 +{ +font-size: 11px; +} + +.text_class3451 +{ +font-size: 11px; +} + +.text_class3452 +{ +font-size: 11px; +} + +.text_class3453 +{ +font-size: 11px; +} + +.paragraph_class3454 +{ +} + +.text_class3455 +{ +font-size: 11px; +} + +.paragraph_class3456 +{ +} + +.text_class3457 +{ +font-size: 11px; +} + +.text_class3458 +{ +} + +.paragraph_class3459 +{ +} + +.text_class3460 +{ +font-size: 11px; +} + +.text_class3461 +{ +font-size: 11px; +} + +.text_class3462 +{ +font-size: 11px; +} + +.text_class3463 +{ +font-size: 11px; +} + +.text_class3464 +{ +font-size: 11px; +} + +.paragraph_class3465 +{ +} + +.text_class3466 +{ +font-size: 11px; +} + +.paragraph_class3467 +{ +} + +.text_class3468 +{ +font-size: 11px; +} + +.paragraph_class3469 +{ +} + +.text_class3470 +{ +} + +.text_class3471 +{ +} + +.paragraph_class3472 +{ +} + +.text_class3473 +{ +font-size: 11px; +} + +.paragraph_class3474 +{ +} + +.text_class3475 +{ +font-size: 11px; +} + +.paragraph_class3476 +{ +} + +.text_class3477 +{ +font-size: 11px; +} + +.paragraph_class3478 +{ +} + +.paragraph_class3479 +{ +} + +.text_class3480 +{ +font-size: 11px; +} + +.paragraph_class3481 +{ +} + +.paragraph_class3482 +{ +} + +.text_class3483 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3484 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3485 +{ +} + +.paragraph_class3486 +{ +} + +.text_class3487 +{ +font-size: 11px; +} + +.text_class3488 +{ +font-family: arial; +} + +.text_class3489 +{ +font-family: arial; +} + +.text_class3490 +{ +font-family: arial; +} + +.paragraph_class3491 +{ +} + +.paragraph_class3492 +{ +} + +.text_class3493 +{ +font-size: 11px; +} + +.text_class3494 +{ +font-family: arial; +} + +.text_class3495 +{ +} + +.paragraph_class3496 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3497 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3498 +{ +font-weight: bold; +} + +.text_class3499 +{ +} + +.cell_class3500 +{ +width: 43px; +background-color: #c0c0c0; +} + +.paragraph_class3502 +{ +margin-left: 0px; +} + +.text_class3503 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3504 +{ +font-weight: bold; +} + +.cell_class3505 +{ +width: 122px; +background-color: #c0c0c0; +} + +.paragraph_class3507 +{ +margin-left: 0px; +} + +.text_class3508 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3509 +{ +font-weight: bold; +} + +.cell_class3510 +{ +width: 124px; +background-color: #c0c0c0; +} + +.paragraph_class3512 +{ +margin-left: 0px; +} + +.text_class3513 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3514 +{ +font-weight: bold; +} + +.paragraph_class3516 +{ +margin-left: 0px; +} + +.text_class3517 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3518 +{ +font-weight: bold; +} + +.cell_class3519 +{ +width: 43px; +} + +.paragraph_class3520 +{ +margin-left: 0px; +} + +.text_class3521 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3522 +{ +width: 122px; +} + +.paragraph_class3523 +{ +margin-left: 0px; +} + +.text_class3524 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3525 +{ +width: 124px; +} + +.paragraph_class3526 +{ +margin-left: 0px; +} + +.text_class3527 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3528 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3529 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3530 +{ +} + +.paragraph_class3531 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3532 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3533 +{ +font-weight: bold; +} + +.text_class3534 +{ +} + +.cell_class3535 +{ +width: 39px; +background-color: #c0c0c0; +} + +.paragraph_class3537 +{ +margin-left: 0px; +} + +.text_class3538 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class3539 +{ +font-weight: bold; +} + +.cell_class3540 +{ +width: 126px; +background-color: #c0c0c0; +} + +.paragraph_class3542 +{ +margin-left: 0px; +} + +.text_class3543 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class3544 +{ +font-weight: bold; +} + +.paragraph_class3546 +{ +margin-left: 0px; +} + +.text_class3547 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class3548 +{ +font-weight: bold; +} + +.paragraph_class3550 +{ +margin-left: 0px; +} + +.text_class3551 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class3552 +{ +font-weight: bold; +} + +.cell_class3553 +{ +width: 39px; +} + +.paragraph_class3554 +{ +margin-left: 0px; +} + +.text_class3555 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class3556 +{ +width: 126px; +} + +.paragraph_class3557 +{ +margin-left: 0px; +} + +.text_class3558 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3559 +{ +margin-left: 0px; +} + +.text_class3560 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3561 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3562 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3563 +{ +margin-left: 0px; +} + +.text_class3564 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3565 +{ +margin-left: 0px; +} + +.text_class3566 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3567 +{ +margin-left: 0px; +} + +.text_class3568 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3569 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3570 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3571 +{ +margin-left: 0px; +} + +.text_class3572 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3573 +{ +margin-left: 0px; +} + +.text_class3574 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3575 +{ +margin-left: 0px; +} + +.text_class3576 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3577 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3578 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3579 +{ +margin-left: 0px; +} + +.text_class3580 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3581 +{ +margin-left: 0px; +} + +.text_class3582 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3583 +{ +margin-left: 0px; +} + +.text_class3584 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class3585 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3586 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class3587 +{ +} + +.text_class3588 +{ +} + +.paragraph_class3589 +{ +} + +.text_class3590 +{ +font-size: 11px; +} + +.paragraph_class3591 +{ +} + +.text_class3592 +{ +font-size: 11px; +} + +.paragraph_class3593 +{ +} + +.text_class3594 +{ +font-size: 11px; +} + +.paragraph_class3595 +{ +} + +.text_class3596 +{ +font-size: 11px; +} + +.text_class3597 +{ +font-size: 11px; +} + +.paragraph_class3598 +{ +} + +.text_class3599 +{ +font-size: 11px; +} + +.text_class3600 +{ +font-size: 11px; +} + +.text_class3601 +{ +font-size: 11px; +} + +.text_class3602 +{ +font-size: 11px; +} + +.text_class3603 +{ +font-size: 11px; +} + +.text_class3604 +{ +font-size: 11px; +} + +.text_class3605 +{ +} + +.paragraph_class3606 +{ +} + +.text_class3607 +{ +font-size: 11px; +} + +.text_class3608 +{ +font-size: 11px; +} + +.paragraph_class3609 +{ +} + +.paragraph_class3610 +{ +} + +.text_class3611 +{ +font-size: 11px; +} + +.paragraph_class3612 +{ +} + +.text_class3613 +{ +font-size: 11px; +} + +.text_class3614 +{ +} + +.text_class3615 +{ +} + +.paragraph_class3616 +{ +} + +.text_class3617 +{ +font-family: arial; +} + +.text_class3618 +{ +font-size: 11px; +} + +.paragraph_class3619 +{ +} + +.paragraph_class3620 +{ +} + +.text_class3621 +{ +font-family: arial; +} + +.text_class3622 +{ +font-size: 11px; +} + +.paragraph_class3623 +{ +} + +.paragraph_class3624 +{ +} + +.text_class3625 +{ +font-family: arial; +} + +.text_class3626 +{ +font-size: 11px; +} + +.text_class3627 +{ +font-family: arial; +} + +.text_class3628 +{ +font-size: 11px; +} + +.text_class3629 +{ +} + +.paragraph_class3630 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3631 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3632 +{ +font-weight: bold; +} + +.text_class3633 +{ +} + +.cell_class3634 +{ +width: 72px; +background-color: #c0c0c0; +} + +.paragraph_class3636 +{ +margin-left: 0px; +} + +.text_class3637 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3638 +{ +font-weight: bold; +} + +.cell_class3639 +{ +width: 260px; +background-color: #c0c0c0; +} + +.paragraph_class3641 +{ +margin-left: 0px; +} + +.text_class3642 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3643 +{ +font-weight: bold; +} + +.cell_class3644 +{ +width: 108px; +background-color: #c0c0c0; +} + +.paragraph_class3646 +{ +margin-left: 0px; +} + +.text_class3647 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3648 +{ +font-weight: bold; +} + +.paragraph_class3650 +{ +margin-left: 0px; +} + +.text_class3651 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3652 +{ +font-weight: bold; +} + +.cell_class3653 +{ +width: 72px; +} + +.paragraph_class3654 +{ +margin-left: 0px; +} + +.text_class3655 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3656 +{ +width: 260px; +} + +.paragraph_class3657 +{ +margin-left: 0px; +} + +.text_class3658 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3659 +{ +width: 108px; +} + +.paragraph_class3660 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3661 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3662 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3663 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3664 +{ +margin-left: 0px; +} + +.text_class3665 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3666 +{ +margin-left: 0px; +} + +.text_class3667 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3668 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3669 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3670 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3671 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3672 +{ +margin-left: 0px; +} + +.text_class3673 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3674 +{ +margin-left: 0px; +} + +.text_class3675 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3676 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3677 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3678 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3679 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3680 +{ +margin-left: 0px; +} + +.text_class3681 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3682 +{ +margin-left: 0px; +} + +.text_class3683 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3684 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3685 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3686 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3687 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3688 +{ +margin-left: 0px; +} + +.text_class3689 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3690 +{ +margin-left: 0px; +} + +.text_class3691 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3692 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3693 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3694 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3695 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3696 +{ +margin-left: 0px; +} + +.text_class3697 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3698 +{ +margin-left: 0px; +} + +.text_class3699 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3700 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3701 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3702 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3703 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3704 +{ +margin-left: 0px; +} + +.text_class3705 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3706 +{ +margin-left: 0px; +} + +.text_class3707 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3708 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3709 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3710 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3711 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3712 +{ +} + +.text_class3713 +{ +} + +.paragraph_class3714 +{ +} + +.text_class3715 +{ +font-size: 11px; +} + +.text_class3716 +{ +font-family: arial; +} + +.paragraph_class3717 +{ +} + +.paragraph_class3718 +{ +} + +.text_class3719 +{ +font-size: 11px; +} + +.text_class3720 +{ +font-family: arial; +} + +.paragraph_class3721 +{ +} + +.paragraph_class3722 +{ +} + +.text_class3723 +{ +font-size: 11px; +} + +.text_class3724 +{ +font-family: arial; +} + +.text_class3725 +{ +font-family: arial; +} + +.text_class3726 +{ +font-family: arial; +} + +.text_class3727 +{ +} + +.paragraph_class3728 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3729 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3730 +{ +font-weight: bold; +} + +.text_class3731 +{ +} + +.cell_class3732 +{ +width: 36px; +background-color: #c0c0c0; +} + +.paragraph_class3734 +{ +margin-left: 0px; +} + +.text_class3735 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3736 +{ +font-weight: bold; +} + +.cell_class3737 +{ +width: 176px; +background-color: #c0c0c0; +} + +.paragraph_class3739 +{ +margin-left: 0px; +} + +.text_class3740 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3741 +{ +font-weight: bold; +} + +.cell_class3742 +{ +width: 178px; +background-color: #c0c0c0; +} + +.paragraph_class3744 +{ +margin-left: 0px; +} + +.text_class3745 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3746 +{ +font-weight: bold; +} + +.cell_class3747 +{ +width: 49px; +background-color: #c0c0c0; +} + +.paragraph_class3749 +{ +margin-left: 0px; +} + +.text_class3750 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3751 +{ +font-weight: bold; +} + +.cell_class3752 +{ +width: 36px; +} + +.paragraph_class3753 +{ +margin-left: 0px; +} + +.text_class3754 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3755 +{ +width: 176px; +} + +.paragraph_class3756 +{ +margin-left: 0px; +} + +.text_class3757 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3758 +{ +width: 178px; +} + +.paragraph_class3759 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3760 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3761 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3762 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3763 +{ +margin-left: 0px; +} + +.text_class3764 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3765 +{ +margin-left: 0px; +} + +.text_class3766 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3767 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3768 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3769 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3770 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3771 +{ +margin-left: 0px; +} + +.text_class3772 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3773 +{ +margin-left: 0px; +} + +.text_class3774 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3775 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3776 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3777 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3778 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3779 +{ +} + +.text_class3780 +{ +} + +.paragraph_class3781 +{ +} + +.text_class3782 +{ +font-family: arial; +} + +.text_class3783 +{ +font-size: 11px; +} + +.paragraph_class3784 +{ +} + +.text_class3785 +{ +font-family: arial; +} + +.text_class3786 +{ +font-size: 11px; +} + +.paragraph_class3787 +{ +} + +.text_class3788 +{ +font-size: 11px; +} + +.text_class3789 +{ +font-family: arial; +} + +.paragraph_class3790 +{ +} + +.paragraph_class3791 +{ +} + +.text_class3792 +{ +font-size: 11px; +} + +.text_class3793 +{ +font-family: arial; +} + +.paragraph_class3794 +{ +} + +.text_class3795 +{ +font-size: 11px; +} + +.text_class3796 +{ +font-family: arial; +} + +.paragraph_class3797 +{ +} + +.text_class3798 +{ +font-size: 11px; +} + +.text_class3799 +{ +font-family: arial; +} + +.paragraph_class3800 +{ +} + +.text_class3801 +{ +font-size: 11px; +} + +.text_class3802 +{ +font-family: arial; +} + +.paragraph_class3803 +{ +} + +.text_class3804 +{ +font-size: 11px; +} + +.text_class3805 +{ +font-family: arial; +} + +.text_class3806 +{ +} + +.paragraph_class3807 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3808 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3809 +{ +font-weight: bold; +} + +.text_class3810 +{ +} + +.cell_class3811 +{ +width: 51px; +background-color: #c0c0c0; +} + +.paragraph_class3813 +{ +margin-left: 0px; +} + +.text_class3814 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3815 +{ +font-weight: bold; +} + +.cell_class3816 +{ +width: 348px; +background-color: #c0c0c0; +} + +.paragraph_class3818 +{ +margin-left: 0px; +} + +.text_class3819 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3820 +{ +font-weight: bold; +} + +.cell_class3821 +{ +width: 113px; +background-color: #c0c0c0; +} + +.paragraph_class3823 +{ +margin-left: 0px; +} + +.text_class3824 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3825 +{ +font-weight: bold; +} + +.paragraph_class3827 +{ +margin-left: 0px; +} + +.text_class3828 +{ +font-size: 11px; +font-family: arial; +} + +.text_class3829 +{ +font-weight: bold; +} + +.cell_class3830 +{ +width: 51px; +} + +.paragraph_class3831 +{ +margin-left: 0px; +} + +.text_class3832 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3833 +{ +width: 348px; +} + +.paragraph_class3834 +{ +margin-left: 0px; +} + +.text_class3835 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class3836 +{ +width: 113px; +} + +.paragraph_class3837 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3838 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3839 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3840 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3841 +{ +margin-left: 0px; +} + +.text_class3842 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3843 +{ +margin-left: 0px; +} + +.text_class3844 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3845 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3846 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3847 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3848 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3849 +{ +margin-left: 0px; +} + +.text_class3850 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3851 +{ +margin-left: 0px; +} + +.text_class3852 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3853 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3854 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3855 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3856 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3857 +{ +margin-left: 0px; +} + +.text_class3858 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3859 +{ +margin-left: 0px; +} + +.text_class3860 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3861 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3862 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3863 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3864 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3865 +{ +margin-left: 0px; +} + +.text_class3866 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3867 +{ +margin-left: 0px; +} + +.text_class3868 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3869 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3870 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3871 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3872 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3873 +{ +margin-left: 0px; +} + +.text_class3874 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3875 +{ +margin-left: 0px; +} + +.text_class3876 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3877 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3878 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3879 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3880 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3881 +{ +margin-left: 0px; +} + +.text_class3882 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3883 +{ +margin-left: 0px; +} + +.text_class3884 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3885 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3886 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3887 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3888 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3889 +{ +margin-left: 0px; +} + +.text_class3890 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3891 +{ +margin-left: 0px; +} + +.text_class3892 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3893 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3894 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3895 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3896 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3897 +{ +margin-left: 0px; +} + +.text_class3898 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3899 +{ +margin-left: 0px; +} + +.text_class3900 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3901 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3902 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3903 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3904 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3905 +{ +margin-left: 0px; +} + +.text_class3906 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3907 +{ +margin-left: 0px; +} + +.text_class3908 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3909 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3910 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3911 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3912 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3913 +{ +margin-left: 0px; +} + +.text_class3914 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3915 +{ +margin-left: 0px; +} + +.text_class3916 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3917 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3918 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3919 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3920 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3921 +{ +margin-left: 0px; +} + +.text_class3922 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3923 +{ +margin-left: 0px; +} + +.text_class3924 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3925 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3926 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3927 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3928 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3929 +{ +margin-left: 0px; +} + +.text_class3930 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3931 +{ +margin-left: 0px; +} + +.text_class3932 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3933 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3934 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3935 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3936 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3937 +{ +margin-left: 0px; +} + +.text_class3938 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3939 +{ +margin-left: 0px; +} + +.text_class3940 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3941 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3942 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3943 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3944 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3945 +{ +margin-left: 0px; +} + +.text_class3946 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3947 +{ +margin-left: 0px; +} + +.text_class3948 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3949 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3950 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3951 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3952 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3953 +{ +margin-left: 0px; +} + +.text_class3954 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3955 +{ +margin-left: 0px; +} + +.text_class3956 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3957 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3958 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3959 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3960 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3961 +{ +margin-left: 0px; +} + +.text_class3962 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3963 +{ +margin-left: 0px; +} + +.text_class3964 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3965 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3966 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3967 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3968 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3969 +{ +margin-left: 0px; +} + +.text_class3970 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3971 +{ +margin-left: 0px; +} + +.text_class3972 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3973 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3974 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3975 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3976 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3977 +{ +margin-left: 0px; +} + +.text_class3978 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3979 +{ +margin-left: 0px; +} + +.text_class3980 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3981 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3982 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3983 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3984 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3985 +{ +margin-left: 0px; +} + +.text_class3986 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3987 +{ +margin-left: 0px; +} + +.text_class3988 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3989 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3990 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3991 +{ +text-align: center; +margin-left: 0px; +} + +.text_class3992 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3993 +{ +margin-left: 0px; +} + +.text_class3994 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3995 +{ +margin-left: 0px; +} + +.text_class3996 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3997 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class3998 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class3999 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4000 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4001 +{ +margin-left: 0px; +} + +.text_class4002 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4003 +{ +margin-left: 0px; +} + +.text_class4004 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4005 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4006 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4007 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4008 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4009 +{ +margin-left: 0px; +} + +.text_class4010 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4011 +{ +margin-left: 0px; +} + +.text_class4012 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4013 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4014 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4015 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4016 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4017 +{ +margin-left: 0px; +} + +.text_class4018 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4019 +{ +margin-left: 0px; +} + +.text_class4020 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4021 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4022 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4023 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4024 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4025 +{ +margin-left: 0px; +} + +.text_class4026 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4027 +{ +margin-left: 0px; +} + +.text_class4028 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4029 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4030 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4031 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4032 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4033 +{ +} + +.paragraph_class4034 +{ +} + +.text_class4035 +{ +font-size: 11px; +} + +.paragraph_class4036 +{ +} + +.text_class4037 +{ +} + +.text_class4038 +{ +} + +.paragraph_class4039 +{ +} + +.text_class4040 +{ +font-family: arial; +} + +.text_class4041 +{ +font-size: 11px; +} + +.paragraph_class4042 +{ +} + +.paragraph_class4043 +{ +} + +.text_class4044 +{ +font-family: arial; +} + +.text_class4045 +{ +font-size: 11px; +} + +.text_class4046 +{ +font-family: ｍｓ 明朝; +} + +.text_class4047 +{ +font-size: 11px; +} + +.text_class4048 +{ +font-family: arial; +} + +.text_class4049 +{ +font-size: 11px; +} + +.paragraph_class4050 +{ +} + +.text_class4051 +{ +font-family: arial; +} + +.text_class4052 +{ +font-size: 11px; +} + +.text_class4053 +{ +font-family: arial; +} + +.text_class4054 +{ +font-size: 11px; +} + +.text_class4055 +{ +font-family: arial; +} + +.text_class4056 +{ +font-size: 11px; +} + +.paragraph_class4057 +{ +} + +.paragraph_class4058 +{ +} + +.text_class4059 +{ +font-family: arial; +} + +.text_class4060 +{ +font-size: 11px; +} + +.paragraph_class4061 +{ +} + +.text_class4062 +{ +font-family: arial; +} + +.text_class4063 +{ +font-size: 11px; +} + +.text_class4064 +{ +} + +.paragraph_class4065 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4066 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4067 +{ +font-weight: bold; +} + +.text_class4068 +{ +} + +.paragraph_class4070 +{ +margin-left: 0px; +} + +.text_class4071 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4072 +{ +font-weight: bold; +} + +.cell_class4073 +{ +width: 165px; +background-color: #c0c0c0; +} + +.paragraph_class4075 +{ +margin-left: 0px; +} + +.text_class4076 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4077 +{ +font-weight: bold; +} + +.cell_class4078 +{ +width: 173px; +background-color: #c0c0c0; +} + +.paragraph_class4080 +{ +margin-left: 0px; +} + +.text_class4081 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4082 +{ +font-weight: bold; +} + +.cell_class4083 +{ +width: 52px; +background-color: #c0c0c0; +} + +.paragraph_class4085 +{ +margin-left: 0px; +} + +.text_class4086 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4087 +{ +font-weight: bold; +} + +.paragraph_class4088 +{ +margin-left: 0px; +} + +.text_class4089 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class4090 +{ +width: 165px; +} + +.paragraph_class4091 +{ +margin-left: 0px; +} + +.text_class4092 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class4093 +{ +width: 173px; +} + +.paragraph_class4094 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4095 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class4096 +{ +width: 52px; +} + +.paragraph_class4097 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4098 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4099 +{ +margin-left: 0px; +} + +.text_class4100 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4101 +{ +margin-left: 0px; +} + +.text_class4102 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4103 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4104 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4105 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4106 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4107 +{ +margin-left: 0px; +} + +.text_class4108 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4109 +{ +margin-left: 0px; +} + +.text_class4110 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4111 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4112 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4113 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4114 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4115 +{ +margin-left: 0px; +} + +.text_class4116 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4117 +{ +margin-left: 0px; +} + +.text_class4118 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4119 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4120 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4121 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4122 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4123 +{ +margin-left: 0px; +} + +.text_class4124 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4125 +{ +margin-left: 0px; +} + +.text_class4126 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4127 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4128 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4129 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4130 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4131 +{ +} + +.text_class4132 +{ +} + +.paragraph_class4133 +{ +} + +.text_class4134 +{ +font-size: 11px; +} + +.paragraph_class4135 +{ +} + +.text_class4136 +{ +font-size: 11px; +} + +.paragraph_class4137 +{ +} + +.text_class4138 +{ +font-size: 11px; +} + +.paragraph_class4139 +{ +} + +.text_class4140 +{ +font-size: 11px; +} + +.paragraph_class4141 +{ +} + +.text_class4142 +{ +font-size: 11px; +} + +.paragraph_class4143 +{ +} + +.text_class4144 +{ +font-size: 11px; +} + +.paragraph_class4145 +{ +} + +.text_class4146 +{ +font-size: 11px; +} + +.paragraph_class4147 +{ +} + +.text_class4148 +{ +font-size: 11px; +} + +.text_class4149 +{ +} + +.text_class4150 +{ +} + +.paragraph_class4151 +{ +} + +.text_class4152 +{ +font-family: arial; +} + +.text_class4153 +{ +font-size: 11px; +} + +.paragraph_class4154 +{ +} + +.paragraph_class4155 +{ +} + +.text_class4156 +{ +font-family: arial; +} + +.text_class4157 +{ +font-size: 11px; +} + +.text_class4158 +{ +font-family: ｍｓ 明朝; +} + +.text_class4159 +{ +font-size: 11px; +} + +.text_class4160 +{ +font-family: arial; +} + +.text_class4161 +{ +font-size: 11px; +} + +.paragraph_class4162 +{ +} + +.paragraph_class4163 +{ +} + +.text_class4164 +{ +font-family: arial; +} + +.text_class4165 +{ +font-size: 11px; +} + +.text_class4166 +{ +font-family: arial; +} + +.text_class4167 +{ +font-size: 11px; +} + +.text_class4168 +{ +font-family: arial; +} + +.text_class4169 +{ +font-size: 11px; +} + +.text_class4170 +{ +font-family: arial; +} + +.text_class4171 +{ +font-size: 11px; +} + +.text_class4172 +{ +} + +.paragraph_class4173 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4174 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4175 +{ +font-weight: bold; +} + +.text_class4176 +{ +} + +.cell_class4177 +{ +width: 42px; +background-color: #c0c0c0; +} + +.paragraph_class4179 +{ +margin-left: 0px; +} + +.text_class4180 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4181 +{ +font-weight: bold; +} + +.cell_class4182 +{ +width: 278px; +background-color: #c0c0c0; +} + +.paragraph_class4184 +{ +margin-left: 0px; +} + +.text_class4185 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4186 +{ +font-weight: bold; +} + +.cell_class4187 +{ +width: 146px; +background-color: #c0c0c0; +} + +.paragraph_class4189 +{ +margin-left: 0px; +} + +.text_class4190 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4191 +{ +font-weight: bold; +} + +.paragraph_class4193 +{ +margin-left: 0px; +} + +.text_class4194 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4195 +{ +font-weight: bold; +} + +.cell_class4196 +{ +width: 42px; +} + +.paragraph_class4197 +{ +margin-left: 0px; +} + +.text_class4198 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class4199 +{ +width: 278px; +} + +.paragraph_class4200 +{ +margin-left: 0px; +} + +.text_class4201 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class4202 +{ +width: 146px; +} + +.paragraph_class4203 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4204 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4205 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4206 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4207 +{ +margin-left: 0px; +} + +.text_class4208 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4209 +{ +margin-left: 0px; +} + +.text_class4210 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4211 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4212 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4213 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4214 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4215 +{ +margin-left: 0px; +} + +.text_class4216 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4217 +{ +margin-left: 0px; +} + +.text_class4218 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4219 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4220 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4221 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4222 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4223 +{ +margin-left: 0px; +} + +.text_class4224 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4225 +{ +margin-left: 0px; +} + +.text_class4226 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4227 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4228 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4229 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4230 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4231 +{ +margin-left: 0px; +} + +.text_class4232 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4233 +{ +margin-left: 0px; +} + +.text_class4234 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4235 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4236 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4237 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4238 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4239 +{ +margin-left: 0px; +} + +.text_class4240 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4241 +{ +margin-left: 0px; +} + +.text_class4242 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4243 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4244 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class4245 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4246 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class4247 +{ +} + +.text_class4248 +{ +} + +.paragraph_class4249 +{ +} + +.text_class4250 +{ +font-size: 11px; +} + +.paragraph_class4251 +{ +} + +.text_class4252 +{ +font-size: 11px; +} + +.paragraph_class4253 +{ +} + +.text_class4254 +{ +font-size: 11px; +} + +.paragraph_class4255 +{ +} + +.text_class4256 +{ +font-size: 11px; +} + +.paragraph_class4257 +{ +} + +.text_class4258 +{ +font-size: 11px; +} + +.paragraph_class4259 +{ +} + +.text_class4260 +{ +font-size: 11px; +} + +.paragraph_class4261 +{ +} + +.text_class4262 +{ +font-size: 11px; +} + +.paragraph_class4263 +{ +} + +.text_class4264 +{ +font-size: 11px; +} + +.paragraph_class4265 +{ +} + +.text_class4266 +{ +font-size: 11px; +} + +.text_class4267 +{ +} + +.text_class4268 +{ +} + +.paragraph_class4269 +{ +} + +.text_class4270 +{ +font-size: 11px; +} + +.text_class4271 +{ +font-family: arial; +} + +.paragraph_class4272 +{ +} + +.paragraph_class4273 +{ +} + +.text_class4274 +{ +font-size: 11px; +} + +.text_class4275 +{ +font-family: arial; +} + +.text_class4276 +{ +font-family: arial; +} + +.text_class4277 +{ +font-family: arial; +} + +.text_class4278 +{ +} + +.paragraph_class4279 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4280 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4281 +{ +font-weight: bold; +} + +.text_class4282 +{ +} + +.cell_class4283 +{ +width: 60px; +background-color: #c0c0c0; +} + +.paragraph_class4285 +{ +margin-left: 0px; +} + +.text_class4286 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4287 +{ +font-weight: bold; +} + +.cell_class4288 +{ +width: 167px; +background-color: #c0c0c0; +} + +.paragraph_class4290 +{ +margin-left: 0px; +} + +.text_class4291 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4292 +{ +font-weight: bold; +} + +.cell_class4293 +{ +width: 95px; +background-color: #c0c0c0; +} + +.paragraph_class4295 +{ +margin-left: 0px; +} + +.text_class4296 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4297 +{ +font-weight: bold; +} + +.cell_class4298 +{ +width: 64px; +background-color: #c0c0c0; +} + +.paragraph_class4300 +{ +margin-left: 0px; +} + +.text_class4301 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4302 +{ +font-weight: bold; +} + +.cell_class4303 +{ +width: 60px; +} + +.paragraph_class4304 +{ +margin-left: 0px; +} + +.text_class4305 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class4306 +{ +width: 167px; +} + +.paragraph_class4307 +{ +margin-left: 0px; +} + +.text_class4308 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4309 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4310 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class4311 +{ +width: 64px; +} + +.paragraph_class4312 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4313 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4314 +{ +margin-left: 0px; +} + +.text_class4315 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4316 +{ +margin-left: 0px; +} + +.text_class4317 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4318 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4319 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4320 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4321 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4322 +{ +margin-left: 0px; +} + +.text_class4323 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4324 +{ +margin-left: 0px; +} + +.text_class4325 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4326 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4327 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4328 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4329 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4330 +{ +margin-left: 0px; +} + +.text_class4331 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4332 +{ +margin-left: 0px; +} + +.text_class4333 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4334 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4335 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4336 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4337 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4338 +{ +margin-left: 0px; +} + +.text_class4339 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4340 +{ +margin-left: 0px; +} + +.text_class4341 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4342 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4343 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4344 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4345 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4346 +{ +margin-left: 0px; +} + +.text_class4347 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4348 +{ +margin-left: 0px; +} + +.text_class4349 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4350 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class4351 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4352 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4353 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4354 +{ +margin-left: 0px; +} + +.text_class4355 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4356 +{ +margin-left: 0px; +} + +.text_class4357 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4358 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4359 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4360 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4361 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4362 +{ +margin-left: 0px; +} + +.text_class4363 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4364 +{ +margin-left: 0px; +} + +.text_class4365 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4366 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4367 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4368 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4369 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4370 +{ +margin-left: 0px; +} + +.text_class4371 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4372 +{ +margin-left: 0px; +} + +.text_class4373 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4374 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4375 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4376 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4377 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4378 +{ +} + +.text_class4379 +{ +} + +.paragraph_class4380 +{ +} + +.text_class4381 +{ +font-family: arial; +} + +.text_class4382 +{ +font-size: 11px; +} + +.paragraph_class4383 +{ +} + +.text_class4384 +{ +font-family: arial; +} + +.text_class4385 +{ +font-size: 11px; +} + +.text_class4386 +{ +} + +.text_class4387 +{ +} + +.paragraph_class4388 +{ +} + +.text_class4389 +{ +font-size: 11px; +} + +.paragraph_class4390 +{ +} + +.text_class4391 +{ +font-size: 11px; +} + +.paragraph_class4392 +{ +} + +.text_class4393 +{ +font-size: 11px; +} + +.paragraph_class4394 +{ +} + +.text_class4395 +{ +font-size: 11px; +} + +.paragraph_class4396 +{ +} + +.text_class4397 +{ +font-size: 11px; +} + +.paragraph_class4398 +{ +} + +.text_class4399 +{ +font-size: 11px; +} + +.paragraph_class4400 +{ +} + +.text_class4401 +{ +font-size: 11px; +} + +.paragraph_class4402 +{ +} + +.text_class4403 +{ +font-size: 11px; +} + +.paragraph_class4404 +{ +} + +.text_class4405 +{ +font-size: 11px; +} + +.paragraph_class4406 +{ +} + +.text_class4407 +{ +font-size: 11px; +} + +.paragraph_class4408 +{ +} + +.text_class4409 +{ +font-size: 11px; +} + +.text_class4410 +{ +} + +.text_class4411 +{ +} + +.paragraph_class4412 +{ +} + +.text_class4413 +{ +font-size: 11px; +} + +.paragraph_class4414 +{ +} + +.text_class4415 +{ +font-size: 11px; +} + +.paragraph_class4416 +{ +} + +.text_class4417 +{ +font-size: 11px; +} + +.paragraph_class4418 +{ +} + +.text_class4419 +{ +font-size: 11px; +} + +.paragraph_class4420 +{ +} + +.text_class4421 +{ +font-size: 11px; +} + +.paragraph_class4422 +{ +} + +.text_class4423 +{ +font-size: 11px; +} + +.paragraph_class4424 +{ +} + +.text_class4425 +{ +font-size: 11px; +} + +.paragraph_class4426 +{ +} + +.text_class4427 +{ +font-size: 11px; +} + +.paragraph_class4428 +{ +} + +.text_class4429 +{ +font-size: 11px; +} + +.paragraph_class4430 +{ +} + +.text_class4431 +{ +font-size: 11px; +} + +.paragraph_class4432 +{ +} + +.text_class4433 +{ +font-size: 11px; +} + +.text_class4434 +{ +} + +.text_class4435 +{ +} + +.text_class4436 +{ +} + +.paragraph_class4437 +{ +} + +.text_class4438 +{ +font-size: 11px; +} + +.text_class4439 +{ +font-family: arial; +} + +.text_class4440 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4441 +{ +} + +.text_class4442 +{ +font-size: 11px; +} + +.text_class4443 +{ +font-size: 11px; +} + +.paragraph_class4444 +{ +} + +.text_class4445 +{ +} + +.text_class4446 +{ +} + +.paragraph_class4447 +{ +text-indent: -18.0px; +margin-left: 18px; +} + +.text_class4448 +{ +font-size: 10px; +} + +.text_class4449 +{ +} + +.paragraph_class4450 +{ +} + +.text_class4451 +{ +font-family: arial; +} + +.text_class4452 +{ +font-size: 11px; +} + +.text_class4453 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4454 +{ +} + +.paragraph_class4455 +{ +} + +.text_class4456 +{ +font-family: arial; +} + +.text_class4457 +{ +font-size: 11px; +} + +.paragraph_class4458 +{ +} + +.paragraph_class4459 +{ +} + +.text_class4460 +{ +font-family: arial; +} + +.text_class4461 +{ +font-size: 11px; +} + +.text_class4462 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4463 +{ +} + +.text_class4464 +{ +font-size: 10px; +} + +.text_class4465 +{ +} + +.paragraph_class4466 +{ +} + +.text_class4467 +{ +font-family: arial; +} + +.text_class4468 +{ +font-size: 11px; +} + +.paragraph_class4469 +{ +} + +.paragraph_class4470 +{ +} + +.text_class4471 +{ +font-family: arial; +} + +.text_class4472 +{ +font-size: 11px; +} + +.text_class4473 +{ +} + +.text_class4474 +{ +} + +.paragraph_class4475 +{ +} + +.text_class4476 +{ +font-family: arial; +} + +.text_class4477 +{ +font-size: 11px; +} + +.text_class4478 +{ +} + +.paragraph_class4479 +{ +} + +.text_class4480 +{ +font-family: arial; +} + +.text_class4481 +{ +font-size: 11px; +} + +.text_class4482 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4483 +{ +font-family: arial; +} + +.text_class4484 +{ +font-size: 11px; +} + +.text_class4485 +{ +} + +.paragraph_class4486 +{ +} + +.text_class4487 +{ +font-size: 11px; +} + +.text_class4488 +{ +} + +.paragraph_class4489 +{ +} + +.text_class4490 +{ +font-family: arial; +} + +.text_class4491 +{ +font-size: 11px; +} + +.text_class4492 +{ +font-family: arial; +} + +.text_class4493 +{ +font-size: 11px; +} + +.text_class4494 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4495 +{ +} + +.paragraph_class4496 +{ +} + +.text_class4497 +{ +font-family: arial; +} + +.text_class4498 +{ +font-size: 11px; +} + +.text_class4499 +{ +font-family: arial; +} + +.text_class4500 +{ +font-size: 11px; +} + +.text_class4501 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4502 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4503 +{ +} + +.paragraph_class4504 +{ +} + +.text_class4505 +{ +font-size: 11px; +} + +.text_class4506 +{ +font-size: 11px; +} + +.text_class4507 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4508 +{ +} + +.paragraph_class4509 +{ +} + +.text_class4510 +{ +font-family: arial; +} + +.text_class4511 +{ +font-size: 11px; +} + +.text_class4512 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4513 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4514 +{ +} + +.paragraph_class4515 +{ +} + +.text_class4516 +{ +font-family: arial; +} + +.text_class4517 +{ +font-size: 11px; +} + +.text_class4518 +{ +} + +.paragraph_class4519 +{ +} + +.text_class4520 +{ +font-family: arial; +} + +.text_class4521 +{ +font-size: 11px; +} + +.text_class4522 +{ +} + +.paragraph_class4523 +{ +} + +.text_class4524 +{ +font-family: arial; +} + +.text_class4525 +{ +font-size: 11px; +} + +.text_class4526 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4527 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4528 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4529 +{ +} + +.paragraph_class4530 +{ +} + +.text_class4531 +{ +font-family: arial; +} + +.text_class4532 +{ +font-size: 11px; +} + +.text_class4533 +{ +} + +.paragraph_class4534 +{ +} + +.text_class4535 +{ +font-family: arial; +} + +.text_class4536 +{ +font-size: 11px; +} + +.text_class4537 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4538 +{ +font-family: arial; +} + +.text_class4539 +{ +font-size: 11px; +} + +.text_class4540 +{ +} + +.paragraph_class4541 +{ +} + +.text_class4542 +{ +font-family: arial; +} + +.text_class4543 +{ +font-size: 11px; +} + +.text_class4544 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4545 +{ +font-family: arial; +} + +.text_class4546 +{ +font-size: 11px; +} + +.text_class4547 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4548 +{ +} + +.paragraph_class4549 +{ +} + +.text_class4550 +{ +font-family: arial; +} + +.text_class4551 +{ +font-size: 11px; +} + +.text_class4552 +{ +} + +.paragraph_class4553 +{ +} + +.text_class4554 +{ +font-family: arial; +} + +.text_class4555 +{ +font-size: 11px; +} + +.text_class4556 +{ +} + +.paragraph_class4557 +{ +} + +.text_class4558 +{ +font-family: arial; +} + +.text_class4559 +{ +font-size: 11px; +} + +.text_class4560 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4561 +{ +} + +.paragraph_class4562 +{ +} + +.text_class4563 +{ +font-family: arial; +} + +.text_class4564 +{ +font-size: 11px; +} + +.text_class4565 +{ +} + +.paragraph_class4566 +{ +} + +.text_class4567 +{ +font-family: arial; +} + +.text_class4568 +{ +font-size: 11px; +} + +.text_class4569 +{ +} + +.paragraph_class4570 +{ +} + +.text_class4571 +{ +font-family: arial; +} + +.text_class4572 +{ +font-size: 11px; +} + +.text_class4573 +{ +} + +.paragraph_class4574 +{ +} + +.text_class4575 +{ +font-family: arial; +} + +.text_class4576 +{ +font-size: 11px; +} + +.text_class4577 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4578 +{ +} + +.paragraph_class4579 +{ +} + +.text_class4580 +{ +font-size: 11px; +} + +.text_class4581 +{ +} + +.paragraph_class4582 +{ +} + +.text_class4583 +{ +font-family: arial; +} + +.text_class4584 +{ +font-size: 11px; +} + +.text_class4585 +{ +} + +.paragraph_class4586 +{ +} + +.text_class4587 +{ +font-family: arial; +} + +.text_class4588 +{ +font-size: 11px; +} + +.text_class4589 +{ +} + +.paragraph_class4590 +{ +} + +.text_class4591 +{ +font-family: arial; +} + +.text_class4592 +{ +font-size: 11px; +} + +.text_class4593 +{ +} + +.paragraph_class4594 +{ +} + +.text_class4595 +{ +font-family: arial; +} + +.text_class4596 +{ +font-size: 11px; +} + +.text_class4597 +{ +} + +.paragraph_class4598 +{ +} + +.text_class4599 +{ +font-family: arial; +} + +.text_class4600 +{ +font-size: 11px; +} + +.text_class4601 +{ +} + +.paragraph_class4602 +{ +} + +.text_class4603 +{ +font-family: arial; +} + +.text_class4604 +{ +font-size: 11px; +} + +.text_class4605 +{ +} + +.paragraph_class4606 +{ +} + +.text_class4607 +{ +font-family: arial; +} + +.text_class4608 +{ +font-size: 11px; +} + +.text_class4609 +{ +} + +.paragraph_class4610 +{ +} + +.text_class4611 +{ +font-family: arial; +} + +.text_class4612 +{ +font-size: 11px; +} + +.text_class4613 +{ +font-family: arial; +} + +.text_class4614 +{ +font-size: 11px; +} + +.text_class4615 +{ +font-family: arial; +} + +.text_class4616 +{ +font-size: 11px; +} + +.text_class4617 +{ +font-family: arial; +} + +.text_class4618 +{ +font-size: 11px; +} + +.text_class4619 +{ +font-family: arial; +} + +.text_class4620 +{ +font-size: 11px; +} + +.text_class4621 +{ +font-family: arial; +} + +.text_class4622 +{ +font-size: 11px; +} + +.text_class4623 +{ +font-family: meiryo ui; +} + +.text_class4624 +{ +font-size: 11px; +} + +.text_class4625 +{ +font-family: arial; +} + +.text_class4626 +{ +font-size: 11px; +} + +.text_class4627 +{ +font-family: arial; +} + +.text_class4628 +{ +font-size: 11px; +} + +.text_class4629 +{ +font-family: arial; +} + +.text_class4630 +{ +font-size: 11px; +} + +.text_class4631 +{ +} + +.paragraph_class4632 +{ +} + +.text_class4633 +{ +font-family: arial; +} + +.text_class4634 +{ +font-size: 11px; +} + +.text_class4635 +{ +font-family: arial; +} + +.text_class4636 +{ +font-size: 11px; +} + +.text_class4637 +{ +font-family: arial; +} + +.text_class4638 +{ +font-size: 11px; +} + +.text_class4639 +{ +font-family: arial; +} + +.text_class4640 +{ +font-size: 11px; +} + +.text_class4641 +{ +font-family: arial; +} + +.text_class4642 +{ +font-size: 11px; +} + +.text_class4643 +{ +font-family: arial; +} + +.text_class4644 +{ +font-size: 11px; +} + +.paragraph_class4645 +{ +} + +.paragraph_class4646 +{ +} + +.text_class4647 +{ +font-family: arial; +} + +.text_class4648 +{ +font-size: 11px; +} + +.text_class4649 +{ +font-family: arial; +} + +.text_class4650 +{ +font-size: 11px; +} + +.text_class4651 +{ +font-family: arial; +} + +.text_class4652 +{ +font-size: 11px; +} + +.text_class4653 +{ +font-family: arial; +} + +.text_class4654 +{ +font-size: 11px; +} + +.text_class4655 +{ +font-family: arial; +} + +.text_class4656 +{ +font-size: 11px; +} + +.text_class4657 +{ +font-family: arial; +} + +.text_class4658 +{ +font-size: 11px; +} + +.text_class4659 +{ +font-family: arial; +} + +.text_class4660 +{ +font-size: 11px; +} + +.paragraph_class4661 +{ +} + +.paragraph_class4662 +{ +} + +.text_class4663 +{ +font-family: arial; +} + +.text_class4664 +{ +font-size: 11px; +} + +.text_class4665 +{ +font-family: arial; +} + +.text_class4666 +{ +font-size: 11px; +} + +.text_class4667 +{ +font-family: arial; +} + +.text_class4668 +{ +font-size: 11px; +} + +.text_class4669 +{ +font-family: arial; +} + +.text_class4670 +{ +font-size: 11px; +} + +.text_class4671 +{ +} + +.paragraph_class4672 +{ +} + +.text_class4673 +{ +font-family: arial; +} + +.text_class4674 +{ +font-size: 11px; +} + +.text_class4675 +{ +} + +.paragraph_class4676 +{ +} + +.text_class4677 +{ +font-family: arial; +} + +.text_class4678 +{ +font-size: 11px; +} + +.text_class4679 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4680 +{ +} + +.paragraph_class4681 +{ +} + +.text_class4682 +{ +font-family: arial; +} + +.text_class4683 +{ +font-size: 11px; +} + +.text_class4684 +{ +} + +.paragraph_class4685 +{ +} + +.text_class4686 +{ +font-size: 11px; +} + +.text_class4687 +{ +} + +.text_class4688 +{ +} + +.paragraph_class4689 +{ +} + +.text_class4690 +{ +font-size: 11px; +} + +.text_class4691 +{ +} + +.text_class4692 +{ +} + +.paragraph_class4693 +{ +} + +.text_class4694 +{ +font-size: 11px; +} + +.text_class4695 +{ +} + +.text_class4696 +{ +} + +.text_class4697 +{ +} + +.paragraph_class4698 +{ +} + +.text_class4699 +{ +font-family: arial; +} + +.text_class4700 +{ +font-size: 11px; +} + +.paragraph_class4701 +{ +} + +.paragraph_class4702 +{ +font-weight: bold; +text-indent: -42.55px; +margin-left: 42px; +} + +.text_class4703 +{ +font-size: 11px; +} + +.paragraph_class4704 +{ +} + +.text_class4705 +{ +font-family: arial; +} + +.text_class4706 +{ +font-size: 11px; +} + +.paragraph_class4707 +{ +} + +.text_class4708 +{ +font-family: arial; +} + +.text_class4709 +{ +font-size: 11px; +} + +.paragraph_class4710 +{ +} + +.text_class4711 +{ +font-family: arial; +} + +.text_class4712 +{ +font-size: 11px; +} + +.paragraph_class4713 +{ +} + +.paragraph_class4714 +{ +font-weight: bold; +text-indent: -42.55px; +margin-left: 42px; +} + +.text_class4715 +{ +font-size: 11px; +} + +.paragraph_class4716 +{ +} + +.text_class4717 +{ +font-family: arial; +} + +.text_class4718 +{ +font-size: 11px; +} + +.paragraph_class4719 +{ +} + +.text_class4720 +{ +font-family: arial; +} + +.text_class4721 +{ +font-size: 11px; +} + +.text_class4722 +{ +} + +.text_class4723 +{ +} + +.paragraph_class4724 +{ +} + +.text_class4725 +{ +font-family: arial; +} + +.text_class4726 +{ +font-size: 11px; +} + +.text_class4727 +{ +} + +.paragraph_class4728 +{ +} + +.text_class4729 +{ +font-family: arial; +} + +.text_class4730 +{ +font-size: 11px; +} + +.text_class4731 +{ +} + +.paragraph_class4732 +{ +} + +.text_class4733 +{ +font-family: arial; +} + +.text_class4734 +{ +font-size: 11px; +} + +.text_class4735 +{ +font-family: arial; +} + +.text_class4736 +{ +font-size: 11px; +} + +.text_class4737 +{ +} + +.paragraph_class4738 +{ +} + +.text_class4739 +{ +font-family: arial; +} + +.text_class4740 +{ +font-size: 11px; +} + +.text_class4741 +{ +} + +.paragraph_class4742 +{ +} + +.text_class4743 +{ +font-family: arial; +} + +.text_class4744 +{ +font-size: 11px; +} + +.text_class4745 +{ +} + +.paragraph_class4746 +{ +} + +.text_class4747 +{ +font-family: arial; +} + +.text_class4748 +{ +font-size: 11px; +} + +.text_class4749 +{ +} + +.paragraph_class4750 +{ +} + +.text_class4751 +{ +font-family: arial; +} + +.text_class4752 +{ +font-size: 11px; +} + +.text_class4753 +{ +} + +.paragraph_class4754 +{ +} + +.text_class4755 +{ +font-family: arial; +} + +.text_class4756 +{ +font-size: 11px; +} + +.text_class4757 +{ +} + +.paragraph_class4758 +{ +} + +.text_class4759 +{ +font-family: arial; +} + +.text_class4760 +{ +font-size: 11px; +} + +.text_class4761 +{ +} + +.paragraph_class4762 +{ +} + +.text_class4763 +{ +font-family: arial; +} + +.text_class4764 +{ +font-size: 11px; +} + +.text_class4765 +{ +} + +.paragraph_class4766 +{ +} + +.text_class4767 +{ +font-family: arial; +} + +.text_class4768 +{ +font-size: 11px; +} + +.text_class4769 +{ +} + +.paragraph_class4770 +{ +} + +.text_class4771 +{ +font-family: arial; +} + +.text_class4772 +{ +font-size: 11px; +} + +.text_class4773 +{ +} + +.paragraph_class4774 +{ +} + +.text_class4775 +{ +font-family: arial; +} + +.text_class4776 +{ +font-size: 11px; +} + +.text_class4777 +{ +} + +.text_class4778 +{ +} + +.paragraph_class4779 +{ +} + +.text_class4780 +{ +font-size: 11px; +} + +.text_class4781 +{ +} + +.text_class4782 +{ +} + +.paragraph_class4783 +{ +} + +.text_class4784 +{ +font-size: 11px; +} + +.text_class4785 +{ +} + +.text_class4786 +{ +} + +.paragraph_class4787 +{ +} + +.text_class4788 +{ +font-size: 11px; +} + +.text_class4789 +{ +} + +.text_class4790 +{ +} + +.paragraph_class4791 +{ +} + +.text_class4792 +{ +font-size: 11px; +} + +.text_class4793 +{ +} + +.text_class4794 +{ +} + +.paragraph_class4795 +{ +} + +.text_class4796 +{ +font-size: 11px; +} + +.text_class4797 +{ +} + +.text_class4798 +{ +} + +.paragraph_class4799 +{ +} + +.text_class4800 +{ +font-family: arial; +} + +.text_class4801 +{ +font-size: 11px; +} + +.paragraph_class4802 +{ +} + +.paragraph_class4803 +{ +} + +.text_class4804 +{ +font-family: arial; +} + +.text_class4805 +{ +font-size: 11px; +} + +.paragraph_class4806 +{ +} + +.paragraph_class4807 +{ +} + +.text_class4808 +{ +font-family: arial; +} + +.text_class4809 +{ +font-size: 11px; +} + +.paragraph_class4810 +{ +} + +.paragraph_class4811 +{ +} + +.text_class4812 +{ +font-family: arial; +} + +.text_class4813 +{ +font-size: 11px; +} + +.text_class4814 +{ +} + +.text_class4815 +{ +} + +.paragraph_class4816 +{ +} + +.text_class4817 +{ +font-family: arial; +} + +.text_class4818 +{ +font-size: 11px; +} + +.paragraph_class4819 +{ +} + +.paragraph_class4820 +{ +} + +.text_class4821 +{ +font-family: arial; +} + +.text_class4822 +{ +font-size: 11px; +} + +.paragraph_class4823 +{ +} + +.paragraph_class4824 +{ +} + +.text_class4825 +{ +font-family: arial; +} + +.text_class4826 +{ +font-size: 11px; +} + +.paragraph_class4827 +{ +} + +.paragraph_class4828 +{ +} + +.text_class4829 +{ +font-family: arial; +} + +.text_class4830 +{ +font-size: 11px; +} + +.text_class4831 +{ +} + +.paragraph_class4832 +{ +} + +.text_class4833 +{ +font-family: arial; +} + +.text_class4834 +{ +font-size: 11px; +} + +.paragraph_class4835 +{ +} + +.text_class4836 +{ +font-family: arial; +} + +.text_class4837 +{ +font-size: 11px; +} + +.text_class4838 +{ +} + +.paragraph_class4839 +{ +} + +.text_class4840 +{ +font-family: arial; +} + +.text_class4841 +{ +font-size: 11px; +} + +.paragraph_class4842 +{ +} + +.paragraph_class4843 +{ +} + +.text_class4844 +{ +font-family: arial; +} + +.text_class4845 +{ +font-size: 11px; +} + +.paragraph_class4846 +{ +} + +.paragraph_class4847 +{ +} + +.text_class4848 +{ +font-family: arial; +} + +.text_class4849 +{ +font-size: 11px; +} + +.text_class4850 +{ +} + +.paragraph_class4851 +{ +} + +.text_class4852 +{ +font-family: arial; +} + +.text_class4853 +{ +font-size: 11px; +} + +.paragraph_class4854 +{ +} + +.text_class4855 +{ +font-family: arial; +} + +.text_class4856 +{ +font-size: 11px; +} + +.paragraph_class4857 +{ +} + +.text_class4858 +{ +font-family: arial; +} + +.text_class4859 +{ +font-size: 11px; +} + +.text_class4860 +{ +} + +.paragraph_class4861 +{ +} + +.text_class4862 +{ +font-family: arial; +} + +.text_class4863 +{ +font-size: 11px; +} + +.text_class4864 +{ +} + +.paragraph_class4865 +{ +} + +.text_class4866 +{ +font-family: arial; +} + +.text_class4867 +{ +font-size: 11px; +} + +.text_class4868 +{ +} + +.text_class4869 +{ +} + +.paragraph_class4870 +{ +} + +.text_class4871 +{ +font-size: 11px; +} + +.text_class4872 +{ +} + +.paragraph_class4873 +{ +} + +.text_class4874 +{ +font-size: 11px; +} + +.text_class4875 +{ +} + +.text_class4876 +{ +} + +.text_class4877 +{ +} + +.text_class4878 +{ +} + +.paragraph_class4879 +{ +} + +.text_class4880 +{ +font-size: 11px; +} + +.paragraph_class4881 +{ +} + +.text_class4882 +{ +font-size: 11px; +} + +.paragraph_class4883 +{ +} + +.text_class4884 +{ +font-size: 11px; +} + +.paragraph_class4885 +{ +} + +.text_class4886 +{ +font-size: 11px; +} + +.paragraph_class4887 +{ +} + +.text_class4888 +{ +font-size: 11px; +} + +.paragraph_class4889 +{ +} + +.text_class4890 +{ +font-size: 11px; +} + +.paragraph_class4891 +{ +} + +.text_class4892 +{ +} + +.text_class4893 +{ +} + +.paragraph_class4894 +{ +} + +.text_class4895 +{ +font-size: 11px; +} + +.text_class4896 +{ +} + +.text_class4897 +{ +} + +.text_class4898 +{ +} + +.paragraph_class4899 +{ +} + +.text_class4900 +{ +font-family: arial; +} + +.text_class4901 +{ +font-size: 11px; +} + +.paragraph_class4902 +{ +} + +.paragraph_class4903 +{ +text-indent: -18.0px; +margin-left: 23px; +} + +.text_class4904 +{ +font-size: 11px; +} + +.text_class4905 +{ +font-size: 11px; +} + +.paragraph_class4906 +{ +} + +.text_class4907 +{ +font-family: arial; +} + +.text_class4908 +{ +font-size: 11px; +} + +.paragraph_class4909 +{ +} + +.text_class4910 +{ +font-family: arial; +} + +.text_class4911 +{ +font-size: 11px; +} + +.paragraph_class4912 +{ +} + +.text_class4913 +{ +font-size: 11px; +} + +.text_class4914 +{ +font-size: 11px; +} + +.paragraph_class4915 +{ +} + +.text_class4916 +{ +font-family: arial; +} + +.text_class4917 +{ +font-size: 11px; +} + +.paragraph_class4918 +{ +} + +.text_class4919 +{ +font-family: arial; +} + +.text_class4920 +{ +font-size: 11px; +} + +.paragraph_class4921 +{ +} + +.text_class4922 +{ +font-size: 11px; +} + +.text_class4923 +{ +font-size: 11px; +} + +.paragraph_class4924 +{ +} + +.text_class4925 +{ +font-family: arial; +} + +.text_class4926 +{ +font-size: 11px; +} + +.text_class4927 +{ +} + +.text_class4928 +{ +} + +.paragraph_class4929 +{ +} + +.text_class4930 +{ +font-family: arial; +} + +.text_class4931 +{ +font-size: 11px; +} + +.paragraph_class4932 +{ +} + +.text_class4933 +{ +font-family: arial; +} + +.text_class4934 +{ +font-size: 11px; +} + +.text_class4935 +{ +} + +.text_class4936 +{ +} + +.paragraph_class4937 +{ +text-align: center; +margin-left: 0px; +} + +.text_class4938 +{ +font-size: 11px; +font-family: arial; +} + +.text_class4939 +{ +font-weight: bold; +} + +.text_class4940 +{ +} + +.text_class4941 +{ +font-size: 11px; +} + +.text_class4942 +{ +font-size: 11px; +} + +.paragraph_class4943 +{ +} + +.text_class4944 +{ +font-family: arial; +} + +.text_class4945 +{ +font-size: 11px; +} + +.text_class4946 +{ +font-family: arial; +} + +.text_class4947 +{ +font-size: 11px; +} + +.text_class4948 +{ +font-family: arial; +} + +.text_class4949 +{ +font-size: 11px; +} + +.text_class4950 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class4951 +{ +} + +.text_class4952 +{ +font-size: 11px; +} + +.text_class4953 +{ +font-size: 11px; +} + +.paragraph_class4954 +{ +} + +.text_class4955 +{ +font-family: arial; +} + +.text_class4956 +{ +font-size: 11px; +} + +.text_class4957 +{ +font-family: arial; +} + +.text_class4958 +{ +font-size: 11px; +} + +.text_class4959 +{ +font-family: arial; +} + +.text_class4960 +{ +font-size: 11px; +} + +.text_class4961 +{ +font-family: arial; +} + +.text_class4962 +{ +font-size: 11px; +} + +.text_class4963 +{ +font-family: arial; +} + +.text_class4964 +{ +font-size: 11px; +} + +.text_class4965 +{ +font-family: arial; +} + +.text_class4966 +{ +font-size: 11px; +} + +.text_class4967 +{ +font-family: arial; +} + +.text_class4968 +{ +font-size: 11px; +} + +.text_class4969 +{ +} + +.text_class4970 +{ +} + +.paragraph_class4971 +{ +} + +.text_class4972 +{ +font-family: arial; +} + +.text_class4973 +{ +font-size: 11px; +} + +.text_class4974 +{ +} + +.text_class4975 +{ +} + +.text_class4976 +{ +} + +.paragraph_class4977 +{ +} + +.text_class4978 +{ +font-family: arial; +} + +.text_class4979 +{ +font-size: 11px; +} + +.text_class4980 +{ +} + +.paragraph_class4981 +{ +} + +.text_class4982 +{ +font-family: arial; +} + +.text_class4983 +{ +font-size: 11px; +} + +.text_class4984 +{ +} + +.paragraph_class4985 +{ +} + +.text_class4986 +{ +font-family: arial; +} + +.text_class4987 +{ +font-size: 11px; +} + +.text_class4988 +{ +} + +.paragraph_class4989 +{ +} + +.text_class4990 +{ +font-family: arial; +} + +.text_class4991 +{ +font-size: 11px; +} + +.text_class4992 +{ +} + +.paragraph_class4993 +{ +} + +.text_class4994 +{ +font-family: arial; +} + +.text_class4995 +{ +font-size: 11px; +} + +.text_class4996 +{ +} + +.paragraph_class4997 +{ +} + +.text_class4998 +{ +font-family: arial; +} + +.text_class4999 +{ +font-size: 11px; +} + +.text_class5000 +{ +} + +.paragraph_class5001 +{ +} + +.text_class5002 +{ +font-family: arial; +} + +.text_class5003 +{ +font-size: 11px; +} + +.text_class5004 +{ +} + +.paragraph_class5005 +{ +} + +.text_class5006 +{ +font-family: arial; +} + +.text_class5007 +{ +font-size: 11px; +} + +.text_class5008 +{ +} + +.paragraph_class5009 +{ +} + +.text_class5010 +{ +font-family: arial; +} + +.text_class5011 +{ +font-size: 11px; +} + +.text_class5012 +{ +} + +.paragraph_class5013 +{ +} + +.text_class5014 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5015 +{ +} + +.paragraph_class5016 +{ +} + +.text_class5017 +{ +font-family: arial; +} + +.text_class5018 +{ +font-size: 11px; +} + +.text_class5019 +{ +} + +.paragraph_class5020 +{ +} + +.text_class5021 +{ +font-family: arial; +} + +.text_class5022 +{ +font-size: 11px; +} + +.text_class5023 +{ +} + +.paragraph_class5024 +{ +} + +.text_class5025 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5026 +{ +} + +.paragraph_class5027 +{ +} + +.text_class5028 +{ +font-family: arial; +} + +.text_class5029 +{ +font-size: 11px; +} + +.text_class5030 +{ +} + +.paragraph_class5031 +{ +} + +.text_class5032 +{ +font-family: arial; +} + +.text_class5033 +{ +font-size: 11px; +} + +.text_class5034 +{ +} + +.text_class5035 +{ +} + +.paragraph_class5036 +{ +} + +.text_class5037 +{ +font-family: arial; +} + +.text_class5038 +{ +font-size: 11px; +} + +.text_class5039 +{ +} + +.paragraph_class5040 +{ +} + +.text_class5041 +{ +font-family: arial; +} + +.text_class5042 +{ +font-size: 11px; +} + +.text_class5043 +{ +} + +.paragraph_class5044 +{ +} + +.text_class5045 +{ +font-family: arial; +} + +.text_class5046 +{ +font-size: 11px; +} + +.text_class5047 +{ +} + +.paragraph_class5048 +{ +} + +.text_class5049 +{ +font-family: arial; +} + +.text_class5050 +{ +font-size: 11px; +} + +.text_class5051 +{ +} + +.paragraph_class5052 +{ +} + +.text_class5053 +{ +font-family: arial; +} + +.text_class5054 +{ +font-size: 11px; +} + +.text_class5055 +{ +} + +.paragraph_class5056 +{ +} + +.text_class5057 +{ +font-family: arial; +} + +.text_class5058 +{ +font-size: 11px; +} + +.text_class5059 +{ +} + +.paragraph_class5060 +{ +} + +.text_class5061 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5062 +{ +} + +.text_class5063 +{ +} + +.paragraph_class5064 +{ +} + +.text_class5065 +{ +font-family: arial; +} + +.text_class5066 +{ +font-size: 11px; +} + +.text_class5067 +{ +} + +.paragraph_class5068 +{ +} + +.text_class5069 +{ +font-family: arial; +} + +.text_class5070 +{ +font-size: 11px; +} + +.text_class5071 +{ +} + +.text_class5072 +{ +} + +.paragraph_class5073 +{ +} + +.text_class5074 +{ +font-family: arial; +} + +.text_class5075 +{ +font-size: 11px; +} + +.text_class5076 +{ +} + +.text_class5077 +{ +} + +.paragraph_class5078 +{ +} + +.text_class5079 +{ +font-family: arial; +} + +.text_class5080 +{ +font-size: 11px; +} + +.text_class5081 +{ +} + +.text_class5082 +{ +} + +.paragraph_class5083 +{ +} + +.text_class5084 +{ +font-family: arial; +} + +.text_class5085 +{ +font-size: 11px; +} + +.text_class5086 +{ +} + +.paragraph_class5087 +{ +} + +.text_class5088 +{ +font-family: arial; +} + +.text_class5089 +{ +font-size: 11px; +} + +.text_class5090 +{ +} + +.paragraph_class5091 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5092 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5093 +{ +font-weight: bold; +} + +.text_class5094 +{ +} + +.cell_class5095 +{ +width: 47px; +background-color: #bfbfbf; +} + +.paragraph_class5097 +{ +margin-left: 0px; +} + +.text_class5098 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5099 +{ +font-weight: bold; +} + +.cell_class5100 +{ +width: 184px; +background-color: #bfbfbf; +} + +.paragraph_class5102 +{ +margin-left: 0px; +} + +.text_class5103 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5104 +{ +font-weight: bold; +} + +.cell_class5105 +{ +width: 168px; +background-color: #bfbfbf; +} + +.paragraph_class5107 +{ +margin-left: 0px; +} + +.cell_class5108 +{ +width: 129px; +background-color: #bfbfbf; +} + +.paragraph_class5110 +{ +margin-left: 0px; +} + +.text_class5111 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5112 +{ +font-weight: bold; +} + +.paragraph_class5113 +{ +margin-left: 0px; +} + +.text_class5114 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5115 +{ +font-weight: bold; +} + +.cell_class5116 +{ +width: 47px; +background-color: #ffffff; +} + +.paragraph_class5117 +{ +margin-left: 0px; +} + +.text_class5118 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5119 +{ +width: 184px; +background-color: #ffffff; +} + +.paragraph_class5120 +{ +margin-left: 0px; +} + +.text_class5121 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5122 +{ +width: 168px; +background-color: #ffffff; +} + +.paragraph_class5123 +{ +margin-left: 0px; +} + +.text_class5124 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5125 +{ +width: 129px; +background-color: #ffffff; +} + +.paragraph_class5126 +{ +margin-left: 0px; +} + +.text_class5127 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5128 +{ +margin-left: 0px; +} + +.text_class5129 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5130 +{ +margin-left: 0px; +} + +.text_class5131 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5132 +{ +margin-left: 0px; +} + +.text_class5133 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5134 +{ +margin-left: 0px; +} + +.text_class5135 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5136 +{ +margin-left: 0px; +} + +.text_class5137 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5138 +{ +margin-left: 0px; +} + +.text_class5139 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5140 +{ +margin-left: 0px; +} + +.text_class5141 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5142 +{ +margin-left: 0px; +} + +.text_class5143 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5144 +{ +margin-left: 0px; +} + +.text_class5145 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5146 +{ +margin-left: 0px; +} + +.text_class5147 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5148 +{ +margin-left: 0px; +} + +.text_class5149 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5150 +{ +margin-left: 0px; +} + +.text_class5151 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5152 +{ +margin-left: 0px; +} + +.text_class5153 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5154 +{ +margin-left: 0px; +} + +.text_class5155 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5156 +{ +margin-left: 0px; +} + +.text_class5157 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5158 +{ +margin-left: 0px; +} + +.text_class5159 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5160 +{ +margin-left: 0px; +} + +.text_class5161 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5162 +{ +margin-left: 0px; +} + +.text_class5163 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5164 +{ +margin-left: 0px; +} + +.text_class5165 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5166 +{ +margin-left: 0px; +} + +.text_class5167 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5168 +{ +margin-left: 0px; +} + +.text_class5169 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5170 +{ +margin-left: 0px; +} + +.text_class5171 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5172 +{ +margin-left: 0px; +} + +.text_class5173 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5174 +{ +margin-left: 0px; +} + +.text_class5175 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5176 +{ +margin-left: 0px; +} + +.text_class5177 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5178 +{ +width: 352px; +background-color: #ffffff; +} + +.paragraph_class5179 +{ +margin-left: 0px; +} + +.text_class5180 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5181 +{ +margin-left: 0px; +} + +.text_class5182 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5183 +{ +margin-left: 0px; +} + +.text_class5184 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5185 +{ +margin-left: 0px; +} + +.text_class5186 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5187 +{ +margin-left: 0px; +} + +.text_class5188 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5189 +{ +margin-left: 0px; +} + +.text_class5190 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5191 +{ +margin-left: 0px; +} + +.text_class5192 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5193 +{ +margin-left: 0px; +} + +.text_class5194 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5195 +{ +margin-left: 0px; +} + +.text_class5196 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5197 +{ +margin-left: 0px; +} + +.text_class5198 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5199 +{ +margin-left: 0px; +} + +.text_class5200 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5201 +{ +margin-left: 0px; +} + +.text_class5202 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5203 +{ +margin-left: 0px; +} + +.text_class5204 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5205 +{ +margin-left: 0px; +} + +.text_class5206 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5207 +{ +margin-left: 0px; +} + +.text_class5208 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5209 +{ +margin-left: 0px; +} + +.text_class5210 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5211 +{ +margin-left: 0px; +} + +.text_class5212 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5213 +{ +margin-left: 0px; +} + +.text_class5214 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5215 +{ +margin-left: 0px; +} + +.text_class5216 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5217 +{ +margin-left: 0px; +} + +.text_class5218 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5219 +{ +margin-left: 0px; +} + +.text_class5220 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5221 +{ +margin-left: 0px; +} + +.text_class5222 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5223 +{ +margin-left: 0px; +} + +.text_class5224 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5225 +{ +margin-left: 0px; +} + +.text_class5226 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5227 +{ +margin-left: 0px; +} + +.text_class5228 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5229 +{ +margin-left: 0px; +} + +.text_class5230 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5231 +{ +margin-left: 0px; +} + +.text_class5232 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5233 +{ +margin-left: 0px; +} + +.text_class5234 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5235 +{ +margin-left: 0px; +} + +.text_class5236 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5237 +{ +margin-left: 0px; +} + +.text_class5238 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5239 +{ +} + +.text_class5240 +{ +} + +.paragraph_class5241 +{ +} + +.text_class5242 +{ +font-family: arial; +} + +.text_class5243 +{ +font-size: 11px; +} + +.text_class5244 +{ +} + +.paragraph_class5245 +{ +} + +.text_class5246 +{ +font-size: 11px; +} + +.text_class5247 +{ +} + +.paragraph_class5248 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5249 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5250 +{ +font-weight: bold; +} + +.text_class5251 +{ +} + +.cell_class5252 +{ +width: 72px; +background-color: #bfbfbf; +} + +.paragraph_class5254 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5255 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5256 +{ +font-weight: bold; +} + +.cell_class5257 +{ +width: 195px; +background-color: #bfbfbf; +} + +.paragraph_class5259 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5260 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5261 +{ +font-weight: bold; +} + +.cell_class5262 +{ +width: 132px; +background-color: #bfbfbf; +} + +.paragraph_class5264 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5265 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5266 +{ +font-weight: bold; +} + +.cell_class5267 +{ +width: 90px; +background-color: #bfbfbf; +} + +.paragraph_class5269 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5270 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5271 +{ +font-weight: bold; +} + +.paragraph_class5272 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5273 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5274 +{ +font-weight: bold; +} + +.cell_class5275 +{ +width: 72px; +background-color: #ffffff; +} + +.paragraph_class5276 +{ +margin-left: 0px; +} + +.text_class5277 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5278 +{ +width: 195px; +background-color: #ffffff; +} + +.paragraph_class5279 +{ +margin-left: 0px; +} + +.text_class5280 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5281 +{ +width: 132px; +background-color: #ffffff; +} + +.paragraph_class5282 +{ +margin-left: 0px; +} + +.text_class5283 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5284 +{ +width: 90px; +background-color: #ffffff; +} + +.paragraph_class5285 +{ +margin-left: 0px; +} + +.text_class5286 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5287 +{ +margin-left: 0px; +} + +.text_class5288 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5289 +{ +margin-left: 0px; +} + +.text_class5290 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5291 +{ +margin-left: 0px; +} + +.text_class5292 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5293 +{ +margin-left: 0px; +} + +.text_class5294 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5295 +{ +margin-left: 0px; +} + +.text_class5296 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5297 +{ +margin-left: 0px; +} + +.text_class5298 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5299 +{ +margin-left: 0px; +} + +.text_class5300 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5301 +{ +margin-left: 0px; +} + +.text_class5302 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5303 +{ +margin-left: 0px; +} + +.text_class5304 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5305 +{ +margin-left: 0px; +} + +.text_class5306 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5307 +{ +margin-left: 0px; +} + +.text_class5308 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5309 +{ +margin-left: 0px; +} + +.text_class5310 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5311 +{ +margin-left: 0px; +} + +.text_class5312 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5313 +{ +width: 327px; +background-color: #ffffff; +} + +.paragraph_class5314 +{ +margin-left: 0px; +} + +.text_class5315 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5316 +{ +margin-left: 0px; +} + +.text_class5317 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5318 +{ +margin-left: 0px; +} + +.text_class5319 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5320 +{ +margin-left: 0px; +} + +.text_class5321 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5322 +{ +margin-left: 0px; +} + +.text_class5323 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5324 +{ +margin-left: 0px; +} + +.text_class5325 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5326 +{ +margin-left: 0px; +} + +.text_class5327 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5328 +{ +margin-left: 0px; +} + +.text_class5329 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5330 +{ +margin-left: 0px; +} + +.text_class5331 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5332 +{ +margin-left: 0px; +} + +.text_class5333 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5334 +{ +margin-left: 0px; +} + +.text_class5335 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5336 +{ +margin-left: 0px; +} + +.text_class5337 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5338 +{ +margin-left: 0px; +} + +.text_class5339 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5340 +{ +margin-left: 0px; +} + +.text_class5341 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5342 +{ +margin-left: 0px; +} + +.text_class5343 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5344 +{ +margin-left: 0px; +} + +.text_class5345 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5346 +{ +margin-left: 0px; +} + +.text_class5347 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5348 +{ +margin-left: 0px; +} + +.text_class5349 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5350 +{ +margin-left: 0px; +} + +.text_class5351 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5352 +{ +margin-left: 0px; +} + +.text_class5353 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5354 +{ +margin-left: 0px; +} + +.text_class5355 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5356 +{ +margin-left: 0px; +} + +.text_class5357 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5358 +{ +margin-left: 0px; +} + +.text_class5359 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5360 +{ +margin-left: 0px; +} + +.text_class5361 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5362 +{ +margin-left: 0px; +} + +.text_class5363 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5364 +{ +margin-left: 0px; +} + +.text_class5365 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5366 +{ +margin-left: 0px; +} + +.text_class5367 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5368 +{ +margin-left: 0px; +} + +.text_class5369 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5370 +{ +margin-left: 0px; +} + +.text_class5371 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5372 +{ +margin-left: 0px; +} + +.text_class5373 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5374 +{ +margin-left: 0px; +} + +.text_class5375 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5376 +{ +margin-left: 0px; +} + +.text_class5377 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5378 +{ +width: 195px; +background-color: #ffffff; +} + +.paragraph_class5379 +{ +margin-left: 0px; +} + +.text_class5380 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class5381 +{ +width: 132px; +background-color: #ffffff; +} + +.paragraph_class5382 +{ +margin-left: 0px; +} + +.text_class5383 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5384 +{ +margin-left: 0px; +} + +.text_class5385 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5386 +{ +margin-left: 0px; +} + +.text_class5387 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5388 +{ +margin-left: 0px; +} + +.paragraph_class5389 +{ +margin-left: 0px; +} + +.text_class5390 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5391 +{ +margin-left: 0px; +} + +.text_class5392 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5393 +{ +} + +.text_class5394 +{ +} + +.paragraph_class5395 +{ +} + +.text_class5396 +{ +font-family: arial; +} + +.text_class5397 +{ +font-size: 11px; +} + +.text_class5398 +{ +} + +.paragraph_class5399 +{ +} + +.text_class5400 +{ +font-family: arial; +} + +.text_class5401 +{ +font-size: 11px; +} + +.text_class5402 +{ +} + +.paragraph_class5403 +{ +} + +.text_class5404 +{ +font-family: arial; +} + +.text_class5405 +{ +font-size: 11px; +} + +.text_class5406 +{ +} + +.text_class5407 +{ +} + +.paragraph_class5408 +{ +} + +.text_class5409 +{ +font-family: arial; +} + +.text_class5410 +{ +font-size: 11px; +} + +.text_class5411 +{ +} + +.text_class5412 +{ +} + +.paragraph_class5413 +{ +} + +.text_class5414 +{ +font-size: 11px; +} + +.text_class5415 +{ +} + +.text_class5416 +{ +} + +.paragraph_class5417 +{ +} + +.text_class5418 +{ +font-size: 11px; +} + +.text_class5419 +{ +} + +.text_class5420 +{ +} + +.paragraph_class5421 +{ +} + +.text_class5422 +{ +font-size: 11px; +} + +.text_class5423 +{ +} + +.text_class5424 +{ +} + +.paragraph_class5425 +{ +} + +.text_class5426 +{ +font-size: 11px; +} + +.text_class5427 +{ +} + +.text_class5428 +{ +} + +.paragraph_class5429 +{ +} + +.text_class5430 +{ +font-size: 11px; +} + +.text_class5431 +{ +} + +.text_class5432 +{ +} + +.paragraph_class5433 +{ +} + +.text_class5434 +{ +font-size: 11px; +} + +.paragraph_class5435 +{ +} + +.text_class5436 +{ +font-size: 11px; +} + +.text_class5437 +{ +} + +.text_class5438 +{ +} + +.paragraph_class5439 +{ +} + +.text_class5440 +{ +font-size: 11px; +} + +.paragraph_class5441 +{ +} + +.text_class5442 +{ +font-size: 11px; +} + +.text_class5443 +{ +} + +.text_class5444 +{ +} + +.paragraph_class5445 +{ +} + +.text_class5446 +{ +font-family: arial; +} + +.text_class5447 +{ +font-size: 11px; +} + +.paragraph_class5448 +{ +} + +.text_class5449 +{ +font-family: arial; +} + +.text_class5450 +{ +font-size: 11px; +} + +.paragraph_class5451 +{ +} + +.text_class5452 +{ +font-family: arial; +} + +.text_class5453 +{ +font-size: 11px; +} + +.text_class5454 +{ +font-family: arial; +} + +.text_class5455 +{ +font-size: 11px; +} + +.text_class5456 +{ +font-family: arial; +} + +.text_class5457 +{ +font-size: 11px; +} + +.paragraph_class5458 +{ +} + +.text_class5459 +{ +font-family: arial; +} + +.text_class5460 +{ +font-size: 11px; +} + +.paragraph_class5461 +{ +} + +.text_class5462 +{ +font-family: arial; +} + +.text_class5463 +{ +font-size: 11px; +} + +.paragraph_class5464 +{ +} + +.text_class5465 +{ +font-family: arial; +} + +.text_class5466 +{ +font-size: 11px; +} + +.text_class5467 +{ +} + +.text_class5468 +{ +} + +.text_class5469 +{ +} + +.paragraph_class5470 +{ +} + +.text_class5471 +{ +font-family: arial; +} + +.text_class5472 +{ +font-size: 11px; +} + +.text_class5473 +{ +} + +.paragraph_class5474 +{ +} + +.text_class5475 +{ +font-family: arial; +} + +.text_class5476 +{ +font-size: 11px; +} + +.text_class5477 +{ +} + +.paragraph_class5478 +{ +} + +.text_class5479 +{ +font-family: arial; +} + +.text_class5480 +{ +font-size: 11px; +} + +.text_class5481 +{ +font-family: arial; +} + +.text_class5482 +{ +font-size: 11px; +} + +.text_class5483 +{ +font-family: arial; +} + +.text_class5484 +{ +font-size: 11px; +} + +.text_class5485 +{ +font-family: arial; +} + +.text_class5486 +{ +font-size: 11px; +} + +.text_class5487 +{ +font-family: arial; +} + +.text_class5488 +{ +font-size: 11px; +} + +.paragraph_class5489 +{ +} + +.text_class5490 +{ +font-family: arial; +} + +.text_class5491 +{ +font-size: 11px; +} + +.text_class5492 +{ +} + +.paragraph_class5493 +{ +} + +.text_class5494 +{ +font-family: arial; +} + +.text_class5495 +{ +font-size: 11px; +} + +.text_class5496 +{ +} + +.paragraph_class5497 +{ +} + +.text_class5498 +{ +font-family: arial; +} + +.text_class5499 +{ +font-size: 11px; +} + +.text_class5500 +{ +} + +.paragraph_class5501 +{ +} + +.text_class5502 +{ +font-family: arial; +} + +.text_class5503 +{ +font-size: 11px; +} + +.text_class5504 +{ +} + +.paragraph_class5505 +{ +} + +.text_class5506 +{ +font-family: arial; +} + +.text_class5507 +{ +font-size: 11px; +} + +.text_class5508 +{ +font-family: arial; +} + +.text_class5509 +{ +font-size: 11px; +} + +.text_class5510 +{ +font-family: arial; +} + +.text_class5511 +{ +font-size: 11px; +} + +.text_class5512 +{ +font-family: arial; +} + +.text_class5513 +{ +font-size: 11px; +} + +.text_class5514 +{ +font-family: arial; +} + +.text_class5515 +{ +font-size: 11px; +} + +.text_class5516 +{ +font-family: arial; +} + +.text_class5517 +{ +font-size: 11px; +} + +.text_class5518 +{ +font-family: arial; +} + +.text_class5519 +{ +font-size: 11px; +} + +.text_class5520 +{ +font-family: arial; +} + +.text_class5521 +{ +font-size: 11px; +} + +.text_class5522 +{ +} + +.paragraph_class5523 +{ +} + +.text_class5524 +{ +font-family: arial; +} + +.text_class5525 +{ +font-size: 11px; +} + +.text_class5526 +{ +} + +.paragraph_class5527 +{ +} + +.text_class5528 +{ +font-family: arial; +} + +.text_class5529 +{ +font-size: 11px; +} + +.text_class5530 +{ +font-family: arial; +} + +.text_class5531 +{ +font-size: 11px; +} + +.text_class5532 +{ +font-family: arial; +} + +.text_class5533 +{ +font-size: 11px; +} + +.text_class5534 +{ +font-family: arial; +} + +.text_class5535 +{ +font-size: 11px; +} + +.text_class5536 +{ +font-family: arial; +} + +.text_class5537 +{ +font-size: 11px; +} + +.text_class5538 +{ +font-family: arial; +} + +.text_class5539 +{ +font-size: 11px; +} + +.text_class5540 +{ +} + +.paragraph_class5541 +{ +} + +.text_class5542 +{ +font-family: arial; +} + +.text_class5543 +{ +font-size: 11px; +} + +.text_class5544 +{ +} + +.paragraph_class5545 +{ +} + +.text_class5546 +{ +font-family: arial; +} + +.text_class5547 +{ +font-size: 11px; +} + +.list_detail_class5548 +{ +} + +.paragraph_class5549 +{ +} + +.text_class5550 +{ +font-family: arial; +} + +.text_class5551 +{ +font-size: 11px; +} + +.text_class5552 +{ +font-size: 11px; +} + +.paragraph_class5553 +{ +} + +.text_class5554 +{ +font-family: arial; +} + +.text_class5555 +{ +font-size: 11px; +} + +.text_class5556 +{ +font-size: 11px; +} + +.paragraph_class5557 +{ +} + +.text_class5558 +{ +font-family: arial; +} + +.text_class5559 +{ +font-size: 11px; +} + +.paragraph_class5560 +{ +} + +.text_class5561 +{ +} + +.paragraph_class5562 +{ +} + +.text_class5563 +{ +font-size: 11px; +} + +.text_class5564 +{ +font-size: 11px; +} + +.text_class5565 +{ +font-size: 11px; +} + +.text_class5566 +{ +font-size: 11px; +} + +.text_class5567 +{ +font-size: 11px; +} + +.text_class5568 +{ +font-size: 11px; +} + +.text_class5569 +{ +} + +.text_class5570 +{ +} + +.paragraph_class5571 +{ +} + +.text_class5572 +{ +font-family: arial; +} + +.text_class5573 +{ +font-size: 11px; +} + +.text_class5574 +{ +font-family: arial; +} + +.text_class5575 +{ +font-size: 11px; +} + +.text_class5576 +{ +font-size: 11px; +} + +.text_class5577 +{ +font-size: 11px; +} + +.paragraph_class5578 +{ +} + +.text_class5579 +{ +font-family: arial; +} + +.text_class5580 +{ +font-size: 11px; +} + +.text_class5581 +{ +} + +.paragraph_class5582 +{ +} + +.text_class5583 +{ +font-family: arial; +} + +.text_class5584 +{ +font-size: 11px; +} + +.paragraph_class5585 +{ +} + +.text_class5586 +{ +font-family: arial; +} + +.text_class5587 +{ +font-size: 11px; +} + +.text_class5588 +{ +font-size: 11px; +} + +.hyperlink_class5589 +{ +} + +.text_class5590 +{ +font-family: arial; +} + +.text_class5591 +{ +font-size: 11px; +} + +.text_class5592 +{ +font-family: arial; +} + +.text_class5593 +{ +font-size: 11px; +} + +.text_class5594 +{ +} + +.text_class5595 +{ +} + +.paragraph_class5596 +{ +} + +.text_class5597 +{ +font-family: arial; +} + +.text_class5598 +{ +font-size: 11px; +} + +.text_class5599 +{ +font-family: arial; +} + +.text_class5600 +{ +font-size: 11px; +} + +.text_class5601 +{ +font-family: arial; +} + +.text_class5602 +{ +font-size: 11px; +} + +.paragraph_class5603 +{ +} + +.text_class5604 +{ +font-family: arial; +} + +.text_class5605 +{ +font-size: 11px; +} + +.text_class5606 +{ +font-size: 11px; +} + +.paragraph_class5607 +{ +} + +.text_class5608 +{ +font-family: arial; +} + +.text_class5609 +{ +font-size: 11px; +} + +.text_class5610 +{ +} + +.paragraph_class5611 +{ +} + +.text_class5612 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5613 +{ +font-family: arial; +} + +.text_class5614 +{ +font-size: 11px; +} + +.text_class5615 +{ +font-family: arial; +} + +.text_class5616 +{ +font-size: 11px; +} + +.text_class5617 +{ +font-family: arial; +} + +.text_class5618 +{ +font-size: 11px; +} + +.text_class5619 +{ +font-family: arial; +} + +.text_class5620 +{ +font-size: 11px; +} + +.text_class5621 +{ +} + +.text_class5622 +{ +} + +.paragraph_class5623 +{ +} + +.paragraph_class5624 +{ +} + +.text_class5625 +{ +} + +.paragraph_class5626 +{ +} + +.text_class5627 +{ +} + +.paragraph_class5628 +{ +} + +.text_class5629 +{ +} + +.paragraph_class5630 +{ +} + +.text_class5631 +{ +} + +.paragraph_class5632 +{ +} + +.text_class5633 +{ +} + +.paragraph_class5634 +{ +} + +.text_class5635 +{ +} + +.paragraph_class5636 +{ +} + +.text_class5637 +{ +} + +.paragraph_class5638 +{ +} + +.text_class5639 +{ +} + +.text_class5640 +{ +} + +.paragraph_class5641 +{ +} + +.text_class5642 +{ +font-size: 11px; +} + +.text_class5643 +{ +} + +.text_class5644 +{ +} + +.paragraph_class5645 +{ +} + +.text_class5646 +{ +font-size: 11px; +} + +.text_class5647 +{ +} + +.text_class5648 +{ +} + +.paragraph_class5649 +{ +} + +.text_class5650 +{ +font-size: 11px; +} + +.paragraph_class5651 +{ +} + +.paragraph_class5652 +{ +} + +.text_class5653 +{ +font-size: 15px; +} + +.text_class5654 +{ +} + +.text_class5655 +{ +} + +.paragraph_class5656 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5657 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5658 +{ +font-weight: bold; +} + +.text_class5659 +{ +} + +.paragraph_class5660 +{ +} + +.text_class5661 +{ +font-family: arial; +} + +.text_class5662 +{ +font-size: 11px; +} + +.paragraph_class5663 +{ +} + +.text_class5664 +{ +font-family: arial; +} + +.text_class5665 +{ +font-size: 11px; +} + +.paragraph_class5666 +{ +} + +.text_class5667 +{ +font-family: arial; +} + +.text_class5668 +{ +font-size: 11px; +} + +.paragraph_class5669 +{ +} + +.text_class5670 +{ +font-family: arial; +} + +.text_class5671 +{ +font-size: 11px; +} + +.paragraph_class5672 +{ +} + +.text_class5673 +{ +font-family: arial; +} + +.text_class5674 +{ +font-size: 11px; +} + +.paragraph_class5675 +{ +} + +.text_class5676 +{ +font-family: arial; +} + +.text_class5677 +{ +font-size: 11px; +} + +.paragraph_class5678 +{ +} + +.text_class5679 +{ +font-family: arial; +} + +.text_class5680 +{ +font-size: 11px; +} + +.paragraph_class5681 +{ +} + +.paragraph_class5682 +{ +} + +.text_class5683 +{ +font-family: arial; +} + +.text_class5684 +{ +font-size: 11px; +} + +.text_class5685 +{ +} + +.text_class5686 +{ +} + +.paragraph_class5687 +{ +} + +.text_class5688 +{ +font-family: arial; +} + +.text_class5689 +{ +font-size: 11px; +} + +.text_class5690 +{ +font-family: arial; +} + +.text_class5691 +{ +font-size: 11px; +} + +.paragraph_class5692 +{ +} + +.text_class5693 +{ +font-family: arial; +} + +.text_class5694 +{ +font-size: 11px; +} + +.paragraph_class5695 +{ +} + +.text_class5696 +{ +font-family: arial; +} + +.text_class5697 +{ +font-size: 11px; +} + +.text_class5698 +{ +font-family: arial; +} + +.text_class5699 +{ +font-size: 11px; +} + +.text_class5700 +{ +font-family: arial; +} + +.text_class5701 +{ +font-size: 11px; +} + +.text_class5702 +{ +} + +.text_class5703 +{ +} + +.paragraph_class5704 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5705 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5706 +{ +font-weight: bold; +} + +.text_class5707 +{ +} + +.paragraph_class5708 +{ +} + +.text_class5709 +{ +font-family: arial; +} + +.text_class5710 +{ +font-size: 11px; +} + +.paragraph_class5711 +{ +} + +.paragraph_class5712 +{ +font-weight: bold; +} + +.text_class5713 +{ +font-family: arial; +} + +.text_class5714 +{ +font-size: 11px; +} + +.paragraph_class5715 +{ +} + +.text_class5716 +{ +font-family: arial; +} + +.text_class5717 +{ +font-size: 11px; +} + +.paragraph_class5718 +{ +} + +.text_class5719 +{ +font-family: arial; +} + +.text_class5720 +{ +font-size: 11px; +} + +.paragraph_class5721 +{ +} + +.text_class5722 +{ +font-family: arial; +} + +.text_class5723 +{ +font-size: 11px; +} + +.paragraph_class5724 +{ +} + +.text_class5725 +{ +font-family: arial; +} + +.text_class5726 +{ +font-size: 11px; +} + +.hyperlink_class5727 +{ +} + +.text_class5728 +{ +} + +.paragraph_class5729 +{ +} + +.text_class5730 +{ +font-family: arial; +} + +.text_class5731 +{ +font-size: 11px; +} + +.paragraph_class5732 +{ +} + +.text_class5733 +{ +font-family: arial; +} + +.text_class5734 +{ +font-size: 11px; +} + +.text_class5735 +{ +font-family: arial; +} + +.text_class5736 +{ +font-size: 11px; +} + +.text_class5737 +{ +font-family: arial; +} + +.text_class5738 +{ +font-size: 11px; +} + +.text_class5739 +{ +} + +.cell_class5740 +{ +width: 76px; +background-color: #bfbfbf; +} + +.paragraph_class5742 +{ +margin-left: 0px; +} + +.text_class5743 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5744 +{ +font-weight: bold; +} + +.cell_class5745 +{ +width: 182px; +background-color: #bfbfbf; +} + +.paragraph_class5747 +{ +margin-left: 0px; +} + +.text_class5748 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5749 +{ +font-weight: bold; +} + +.cell_class5750 +{ +width: 317px; +background-color: #bfbfbf; +} + +.paragraph_class5752 +{ +margin-left: 0px; +} + +.text_class5753 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5754 +{ +font-weight: bold; +} + +.cell_class5755 +{ +width: 76px; +} + +.paragraph_class5756 +{ +margin-left: 0px; +} + +.text_class5757 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5758 +{ +width: 182px; +} + +.paragraph_class5759 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5760 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5761 +{ +width: 317px; +} + +.paragraph_class5762 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5763 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5764 +{ +margin-left: 0px; +} + +.text_class5765 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5766 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5767 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5768 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5769 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5770 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5771 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5772 +{ +margin-left: 0px; +} + +.text_class5773 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5774 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5775 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5776 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5777 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5778 +{ +margin-left: 0px; +} + +.text_class5779 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5780 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5781 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5782 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5783 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5784 +{ +margin-left: 0px; +} + +.text_class5785 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5786 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5787 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5788 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5789 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5790 +{ +margin-left: 0px; +} + +.text_class5791 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5792 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5793 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5794 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5795 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5796 +{ +margin-left: 0px; +} + +.text_class5797 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5798 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5799 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5800 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5801 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5802 +{ +margin-left: 0px; +} + +.text_class5803 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5804 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5805 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5806 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5807 +{ +font-size: 10px; +font-family: arial; +} + +.paragraph_class5808 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5809 +{ +font-size: 10px; +font-family: arial; +} + +.paragraph_class5810 +{ +margin-left: 0px; +} + +.text_class5811 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5812 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5813 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5814 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5815 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5816 +{ +margin-left: 0px; +} + +.text_class5817 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5818 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5819 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5820 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5821 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5822 +{ +} + +.paragraph_class5823 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5824 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5825 +{ +font-weight: bold; +} + +.text_class5826 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5827 +{ +font-weight: bold; +} + +.text_class5828 +{ +} + +.paragraph_class5829 +{ +} + +.paragraph_class5830 +{ +} + +.text_class5831 +{ +} + +.paragraph_class5832 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5833 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5834 +{ +font-weight: bold; +} + +.text_class5835 +{ +} + +.paragraph_class5836 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5837 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5838 +{ +} + +.paragraph_class5839 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5840 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5841 +{ +font-weight: bold; +} + +.text_class5842 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5843 +{ +font-weight: bold; +} + +.text_class5844 +{ +} + +.cell_class5845 +{ +width: 49px; +background-color: #bfbfbf; +} + +.paragraph_class5847 +{ +margin-left: 0px; +} + +.text_class5848 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5849 +{ +font-weight: bold; +} + +.paragraph_class5851 +{ +margin-left: 0px; +} + +.text_class5852 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5853 +{ +font-weight: bold; +} + +.cell_class5854 +{ +width: 357px; +background-color: #bfbfbf; +} + +.paragraph_class5856 +{ +margin-left: 0px; +} + +.text_class5857 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.text_class5858 +{ +font-weight: bold; +} + +.paragraph_class5859 +{ +margin-left: 0px; +} + +.text_class5860 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5861 +{ +width: 168px; +} + +.paragraph_class5862 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5863 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.cell_class5864 +{ +width: 357px; +} + +.paragraph_class5865 +{ +margin-left: 0px; +} + +.text_class5866 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5867 +{ +margin-left: 0px; +} + +.text_class5868 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5869 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5870 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5871 +{ +margin-left: 0px; +} + +.text_class5872 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5873 +{ +margin-left: 0px; +} + +.text_class5874 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5875 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5876 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5877 +{ +margin-left: 0px; +} + +.text_class5878 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5879 +{ +margin-left: 0px; +} + +.text_class5880 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5881 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5882 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5883 +{ +margin-left: 0px; +} + +.text_class5884 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5885 +{ +margin-left: 0px; +} + +.text_class5886 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5887 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5888 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5889 +{ +margin-left: 0px; +} + +.text_class5890 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5891 +{ +margin-left: 0px; +} + +.text_class5892 +{ +color: #000000; +font-size: 11px; +font-family: arial; +} + +.paragraph_class5893 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class5894 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class5895 +{ +margin-left: 0px; +} + +.text_class5896 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5897 +{ +} + +.text_class5898 +{ +} + +.paragraph_class5899 +{ +} + +.text_class5900 +{ +font-family: arial; +} + +.text_class5901 +{ +font-size: 11px; +} + +.paragraph_class5902 +{ +} + +.text_class5903 +{ +font-family: arial; +} + +.text_class5904 +{ +font-size: 11px; +} + +.paragraph_class5905 +{ +} + +.text_class5906 +{ +font-family: arial; +} + +.text_class5907 +{ +font-size: 11px; +} + +.text_class5908 +{ +} + +.text_class5909 +{ +} + +.paragraph_class5910 +{ +text-align: center; +margin-left: 0px; +} + +.text_class5911 +{ +font-size: 11px; +font-family: arial; +} + +.text_class5912 +{ +font-weight: bold; +} + +.text_class5913 +{ +} + +.text_class5914 +{ +} + +.text_class5915 +{ +} + +.paragraph_class5916 +{ +} + +.text_class5917 +{ +font-family: arial; +} + +.text_class5918 +{ +font-size: 11px; +} + +.text_class5919 +{ +} + +.text_class5920 +{ +font-family: arial; +} + +.text_class5921 +{ +font-size: 11px; +} + +.text_class5922 +{ +font-family: ｍｓ ｐ明朝; +} + +.text_class5923 +{ +font-size: 11px; +} + +.text_class5924 +{ +font-family: arial; +} + +.text_class5925 +{ +font-size: 11px; +} + +.text_class5926 +{ +font-family: ｍｓ ｐ明朝; +} + +.text_class5927 +{ +font-size: 11px; +} + +.text_class5928 +{ +font-family: arial; +} + +.text_class5929 +{ +font-size: 11px; +} + +.text_class5930 +{ +font-family: arial; +} + +.text_class5931 +{ +font-size: 11px; +} + +.text_class5932 +{ +font-family: arial; +} + +.text_class5933 +{ +font-size: 11px; +} + +.text_class5934 +{ +font-family: arial; +} + +.text_class5935 +{ +font-size: 11px; +} + +.text_class5936 +{ +font-family: arial; +} + +.text_class5937 +{ +font-size: 11px; +} + +.text_class5938 +{ +font-family: arial; +} + +.text_class5939 +{ +font-size: 11px; +} + +.text_class5940 +{ +font-family: arial; +} + +.text_class5941 +{ +font-size: 11px; +} + +.text_class5942 +{ +} + +.text_class5943 +{ +font-family: arial; +} + +.text_class5944 +{ +font-size: 11px; +} + +.text_class5945 +{ +font-family: arial; +} + +.text_class5946 +{ +font-size: 11px; +} + +.text_class5947 +{ +font-family: arial; +} + +.text_class5948 +{ +font-size: 11px; +} + +.text_class5949 +{ +font-family: arial; +} + +.text_class5950 +{ +font-size: 11px; +} + +.text_class5951 +{ +font-family: arial; +} + +.text_class5952 +{ +font-size: 11px; +} + +.text_class5953 +{ +font-family: arial; +} + +.text_class5954 +{ +font-size: 11px; +} + +.text_class5955 +{ +font-family: arial; +} + +.text_class5956 +{ +font-size: 11px; +} + +.text_class5957 +{ +font-family: arial; +} + +.text_class5958 +{ +font-size: 11px; +} + +.text_class5959 +{ +font-family: arial; +} + +.text_class5960 +{ +font-size: 11px; +} + +.text_class5961 +{ +font-family: arial; +} + +.text_class5962 +{ +font-size: 11px; +} + +.text_class5963 +{ +font-family: arial; +} + +.text_class5964 +{ +font-size: 11px; +} + +.text_class5965 +{ +} + +.text_class5966 +{ +font-family: arial; +} + +.text_class5967 +{ +font-size: 11px; +} + +.text_class5968 +{ +font-family: arial; +} + +.text_class5969 +{ +font-size: 11px; +} + +.text_class5970 +{ +font-family: arial; +} + +.text_class5971 +{ +font-size: 11px; +} + +.text_class5972 +{ +} + +.text_class5973 +{ +font-family: arial; +} + +.text_class5974 +{ +font-size: 11px; +} + +.text_class5975 +{ +font-family: arial; +} + +.text_class5976 +{ +font-size: 11px; +} + +.text_class5977 +{ +font-family: arial; +} + +.text_class5978 +{ +font-size: 11px; +} + +.text_class5979 +{ +} + +.text_class5980 +{ +font-family: arial; +} + +.text_class5981 +{ +font-size: 11px; +} + +.text_class5982 +{ +font-family: arial; +} + +.text_class5983 +{ +font-size: 11px; +} + +.text_class5984 +{ +font-family: arial; +} + +.text_class5985 +{ +font-size: 11px; +} + +.text_class5986 +{ +font-family: ｍｓ ｐ明朝; +} + +.text_class5987 +{ +font-size: 11px; +} + +.text_class5988 +{ +font-family: arial; +} + +.text_class5989 +{ +font-size: 11px; +} + +.text_class5990 +{ +font-family: ｍｓ ｐ明朝; +} + +.text_class5991 +{ +font-size: 11px; +} + +.text_class5992 +{ +font-family: arial; +} + +.text_class5993 +{ +font-size: 11px; +} + +.text_class5994 +{ +font-family: arial; +} + +.text_class5995 +{ +font-size: 11px; +} + +.text_class5996 +{ +font-family: ｍｓ ｐ明朝; +} + +.text_class5997 +{ +font-size: 11px; +} + +.text_class5998 +{ +font-family: arial; +} + +.text_class5999 +{ +font-size: 11px; +} + +.text_class6000 +{ +font-family: ｍｓ ｐ明朝; +} + +.text_class6001 +{ +font-size: 11px; +} + +.text_class6002 +{ +font-family: arial; +} + +.text_class6003 +{ +font-size: 11px; +} + +.paragraph_class6004 +{ +} + +.text_class6005 +{ +font-family: arial; +} + +.text_class6006 +{ +font-size: 11px; +} + +.text_class6007 +{ +} + +.text_class6008 +{ +font-family: arial; +} + +.text_class6009 +{ +font-size: 11px; +} + +.text_class6010 +{ +font-family: arial; +} + +.text_class6011 +{ +font-size: 11px; +} + +.text_class6012 +{ +font-family: arial; +} + +.text_class6013 +{ +font-size: 11px; +} + +.paragraph_class6014 +{ +} + +.text_class6015 +{ +font-family: arial; +} + +.text_class6016 +{ +font-size: 11px; +} + +.text_class6017 +{ +} + +.paragraph_class6018 +{ +} + +.text_class6019 +{ +font-family: arial; +} + +.text_class6020 +{ +font-size: 11px; +} + +.text_class6021 +{ +font-family: arial; +} + +.text_class6022 +{ +font-size: 11px; +} + +.text_class6023 +{ +} + +.paragraph_class6024 +{ +} + +.text_class6025 +{ +font-family: arial; +} + +.text_class6026 +{ +font-size: 11px; +} + +.text_class6027 +{ +font-family: arial; +} + +.text_class6028 +{ +font-size: 11px; +} + +.paragraph_class6029 +{ +} + +.text_class6030 +{ +font-family: arial; +} + +.text_class6031 +{ +font-size: 11px; +} + +.text_class6032 +{ +font-family: arial; +} + +.text_class6033 +{ +font-size: 11px; +} + +.text_class6034 +{ +font-family: arial; +} + +.text_class6035 +{ +font-size: 11px; +} + +.text_class6036 +{ +font-family: arial; +} + +.text_class6037 +{ +font-size: 11px; +} + +.text_class6038 +{ +font-family: arial; +} + +.text_class6039 +{ +font-size: 11px; +} + +.text_class6040 +{ +font-family: arial; +} + +.text_class6041 +{ +font-size: 11px; +} + +.text_class6042 +{ +font-family: arial; +} + +.text_class6043 +{ +font-size: 11px; +} + +.text_class6044 +{ +font-family: arial; +} + +.text_class6045 +{ +font-size: 11px; +} + +.paragraph_class6046 +{ +} + +.text_class6047 +{ +font-family: arial; +} + +.text_class6048 +{ +font-size: 11px; +} + +.text_class6049 +{ +} + +.text_class6050 +{ +font-family: arial; +} + +.text_class6051 +{ +font-size: 11px; +} + +.text_class6052 +{ +font-family: arial; +} + +.text_class6053 +{ +font-size: 11px; +} + +.text_class6054 +{ +font-family: arial; +} + +.text_class6055 +{ +font-size: 11px; +} + +.text_class6056 +{ +} + +.text_class6057 +{ +font-family: arial; +} + +.text_class6058 +{ +font-size: 11px; +} + +.text_class6059 +{ +font-family: arial; +} + +.text_class6060 +{ +font-size: 11px; +} + +.text_class6061 +{ +font-family: arial; +} + +.text_class6062 +{ +font-size: 11px; +} + +.text_class6063 +{ +font-family: arial; +} + +.text_class6064 +{ +font-size: 11px; +} + +.text_class6065 +{ +font-family: arial; +} + +.text_class6066 +{ +font-size: 11px; +} + +.text_class6067 +{ +font-family: arial; +} + +.text_class6068 +{ +font-size: 11px; +} + +.text_class6069 +{ +} + +.text_class6070 +{ +} + +.paragraph_class6071 +{ +} + +.text_class6072 +{ +font-family: arial; +} + +.text_class6073 +{ +font-size: 11px; +} + +.text_class6074 +{ +} + +.paragraph_class6075 +{ +} + +.text_class6076 +{ +font-family: arial; +} + +.text_class6077 +{ +font-size: 11px; +} + +.text_class6078 +{ +} + +.paragraph_class6079 +{ +} + +.text_class6080 +{ +font-family: arial; +} + +.text_class6081 +{ +font-size: 11px; +} + +.text_class6082 +{ +} + +.paragraph_class6083 +{ +} + +.text_class6084 +{ +font-family: arial; +} + +.text_class6085 +{ +font-size: 11px; +} + +.text_class6086 +{ +} + +.paragraph_class6087 +{ +} + +.text_class6088 +{ +font-family: arial; +} + +.text_class6089 +{ +font-size: 11px; +} + +.text_class6090 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6091 +{ +} + +.paragraph_class6092 +{ +} + +.text_class6093 +{ +font-family: arial; +} + +.text_class6094 +{ +font-size: 11px; +} + +.text_class6095 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6096 +{ +} + +.text_class6097 +{ +} + +.paragraph_class6098 +{ +} + +.text_class6099 +{ +font-size: 11px; +} + +.text_class6100 +{ +} + +.paragraph_class6101 +{ +} + +.text_class6102 +{ +font-family: arial; +} + +.text_class6103 +{ +font-size: 10px; +} + +.text_class6104 +{ +} + +.paragraph_class6105 +{ +} + +.text_class6106 +{ +font-family: arial; +} + +.text_class6107 +{ +font-size: 10px; +} + +.text_class6108 +{ +} + +.text_class6109 +{ +} + +.paragraph_class6110 +{ +} + +.text_class6111 +{ +font-size: 11px; +} + +.text_class6112 +{ +} + +.text_class6113 +{ +} + +.paragraph_class6114 +{ +} + +.text_class6115 +{ +font-size: 11px; +} + +.text_class6116 +{ +} + +.paragraph_class6117 +{ +} + +.text_class6118 +{ +font-size: 11px; +} + +.text_class6119 +{ +} + +.paragraph_class6120 +{ +} + +.text_class6121 +{ +font-size: 11px; +} + +.text_class6122 +{ +} + +.text_class6123 +{ +} + +.paragraph_class6124 +{ +} + +.text_class6125 +{ +font-size: 11px; +} + +.text_class6126 +{ +font-size: 11px; +} + +.text_class6127 +{ +} + +.paragraph_class6128 +{ +} + +.text_class6129 +{ +font-size: 11px; +} + +.paragraph_class6130 +{ +} + +.text_class6131 +{ +font-size: 11px; +} + +.paragraph_class6132 +{ +} + +.text_class6133 +{ +font-size: 11px; +} + +.paragraph_class6134 +{ +} + +.text_class6135 +{ +font-size: 11px; +} + +.text_class6136 +{ +} + +.paragraph_class6137 +{ +} + +.text_class6138 +{ +font-size: 11px; +} + +.text_class6139 +{ +} + +.paragraph_class6140 +{ +} + +.text_class6141 +{ +font-size: 11px; +} + +.text_class6142 +{ +} + +.paragraph_class6143 +{ +} + +.text_class6144 +{ +font-size: 11px; +} + +.text_class6145 +{ +font-size: 11px; +} + +.text_class6146 +{ +font-size: 11px; +} + +.text_class6147 +{ +} + +.paragraph_class6148 +{ +} + +.text_class6149 +{ +font-size: 11px; +} + +.text_class6150 +{ +font-size: 11px; +} + +.text_class6151 +{ +font-size: 11px; +} + +.text_class6152 +{ +font-size: 11px; +} + +.text_class6153 +{ +font-size: 11px; +} + +.text_class6154 +{ +font-size: 11px; +} + +.text_class6155 +{ +font-size: 11px; +} + +.text_class6156 +{ +font-size: 11px; +} + +.text_class6157 +{ +} + +.paragraph_class6158 +{ +} + +.text_class6159 +{ +font-size: 11px; +} + +.text_class6160 +{ +font-size: 11px; +} + +.text_class6161 +{ +font-size: 11px; +} + +.text_class6162 +{ +font-size: 11px; +} + +.text_class6163 +{ +font-size: 11px; +} + +.text_class6164 +{ +font-size: 11px; +} + +.text_class6165 +{ +font-size: 11px; +} + +.text_class6166 +{ +font-size: 11px; +} + +.text_class6167 +{ +font-size: 11px; +} + +.text_class6168 +{ +font-size: 11px; +} + +.text_class6169 +{ +} + +.paragraph_class6170 +{ +} + +.text_class6171 +{ +font-size: 11px; +} + +.text_class6172 +{ +} + +.paragraph_class6173 +{ +} + +.text_class6174 +{ +font-size: 11px; +} + +.text_class6175 +{ +} + +.paragraph_class6176 +{ +} + +.text_class6177 +{ +font-size: 11px; +} + +.text_class6178 +{ +} + +.paragraph_class6179 +{ +} + +.text_class6180 +{ +font-size: 11px; +} + +.text_class6181 +{ +font-size: 11px; +} + +.text_class6182 +{ +font-size: 11px; +} + +.text_class6183 +{ +font-size: 11px; +} + +.text_class6184 +{ +font-size: 11px; +} + +.text_class6185 +{ +} + +.paragraph_class6186 +{ +} + +.text_class6187 +{ +font-size: 11px; +} + +.text_class6188 +{ +font-size: 11px; +} + +.text_class6189 +{ +font-size: 11px; +} + +.text_class6190 +{ +font-size: 11px; +} + +.text_class6191 +{ +font-size: 11px; +} + +.text_class6192 +{ +} + +.paragraph_class6193 +{ +} + +.text_class6194 +{ +font-size: 11px; +} + +.paragraph_class6195 +{ +} + +.text_class6196 +{ +} + +.paragraph_class6197 +{ +} + +.text_class6198 +{ +font-size: 11px; +} + +.text_class6199 +{ +} + +.paragraph_class6200 +{ +} + +.text_class6201 +{ +font-size: 11px; +} + +.text_class6202 +{ +} + +.paragraph_class6203 +{ +} + +.text_class6204 +{ +font-size: 11px; +} + +.text_class6205 +{ +} + +.paragraph_class6206 +{ +} + +.text_class6207 +{ +font-size: 11px; +} + +.text_class6208 +{ +font-size: 11px; +} + +.text_class6209 +{ +font-size: 11px; +} + +.text_class6210 +{ +font-size: 11px; +} + +.text_class6211 +{ +font-size: 11px; +} + +.text_class6212 +{ +font-size: 11px; +} + +.text_class6213 +{ +font-size: 11px; +} + +.text_class6214 +{ +font-size: 11px; +} + +.paragraph_class6215 +{ +} + +.text_class6216 +{ +font-size: 11px; +} + +.text_class6217 +{ +} + +.paragraph_class6218 +{ +} + +.text_class6219 +{ +font-size: 11px; +} + +.text_class6220 +{ +} + +.paragraph_class6221 +{ +} + +.text_class6222 +{ +font-size: 11px; +} + +.text_class6223 +{ +} + +.paragraph_class6224 +{ +} + +.text_class6225 +{ +font-size: 11px; +} + +.text_class6226 +{ +} + +.paragraph_class6227 +{ +} + +.text_class6228 +{ +font-size: 11px; +} + +.text_class6229 +{ +} + +.paragraph_class6230 +{ +} + +.text_class6231 +{ +font-size: 11px; +} + +.text_class6232 +{ +} + +.paragraph_class6233 +{ +} + +.text_class6234 +{ +font-size: 11px; +} + +.text_class6235 +{ +} + +.paragraph_class6236 +{ +} + +.text_class6237 +{ +font-size: 11px; +} + +.text_class6238 +{ +} + +.paragraph_class6239 +{ +} + +.text_class6240 +{ +font-size: 11px; +} + +.text_class6241 +{ +} + +.paragraph_class6242 +{ +} + +.text_class6243 +{ +font-size: 11px; +} + +.text_class6244 +{ +} + +.paragraph_class6245 +{ +} + +.text_class6246 +{ +font-size: 11px; +} + +.text_class6247 +{ +} + +.paragraph_class6248 +{ +} + +.text_class6249 +{ +font-size: 11px; +} + +.text_class6250 +{ +} + +.paragraph_class6251 +{ +} + +.text_class6252 +{ +font-size: 11px; +} + +.text_class6253 +{ +} + +.paragraph_class6254 +{ +} + +.text_class6255 +{ +font-size: 11px; +} + +.text_class6256 +{ +} + +.paragraph_class6257 +{ +} + +.text_class6258 +{ +font-size: 11px; +} + +.text_class6259 +{ +} + +.paragraph_class6260 +{ +} + +.text_class6261 +{ +font-size: 11px; +} + +.text_class6262 +{ +} + +.paragraph_class6263 +{ +} + +.text_class6264 +{ +font-size: 11px; +} + +.text_class6265 +{ +} + +.paragraph_class6266 +{ +} + +.text_class6267 +{ +font-size: 11px; +} + +.text_class6268 +{ +} + +.paragraph_class6269 +{ +} + +.text_class6270 +{ +font-size: 11px; +} + +.text_class6271 +{ +} + +.paragraph_class6272 +{ +} + +.text_class6273 +{ +font-size: 11px; +} + +.text_class6274 +{ +} + +.paragraph_class6275 +{ +} + +.text_class6276 +{ +font-size: 11px; +} + +.text_class6277 +{ +} + +.paragraph_class6278 +{ +} + +.text_class6279 +{ +font-size: 11px; +} + +.text_class6280 +{ +} + +.paragraph_class6281 +{ +} + +.text_class6282 +{ +font-size: 11px; +} + +.text_class6283 +{ +} + +.paragraph_class6284 +{ +} + +.text_class6285 +{ +font-size: 11px; +} + +.text_class6286 +{ +} + +.paragraph_class6287 +{ +} + +.text_class6288 +{ +font-size: 11px; +} + +.text_class6289 +{ +} + +.paragraph_class6290 +{ +} + +.text_class6291 +{ +} + +.paragraph_class6292 +{ +} + +.text_class6293 +{ +font-size: 11px; +} + +.text_class6294 +{ +} + +.paragraph_class6295 +{ +} + +.text_class6296 +{ +font-size: 11px; +} + +.text_class6297 +{ +} + +.paragraph_class6298 +{ +} + +.text_class6299 +{ +font-size: 11px; +} + +.text_class6300 +{ +} + +.text_class6301 +{ +} + +.paragraph_class6302 +{ +} + +.text_class6303 +{ +font-size: 11px; +} + +.text_class6304 +{ +font-size: 11px; +} + +.text_class6305 +{ +font-size: 11px; +} + +.text_class6306 +{ +font-size: 11px; +} + +.text_class6307 +{ +font-size: 11px; +} + +.text_class6308 +{ +font-size: 11px; +} + +.text_class6309 +{ +} + +.paragraph_class6310 +{ +} + +.text_class6311 +{ +font-size: 11px; +} + +.text_class6312 +{ +font-size: 11px; +} + +.text_class6313 +{ +font-size: 11px; +} + +.text_class6314 +{ +font-size: 11px; +} + +.text_class6315 +{ +} + +.paragraph_class6316 +{ +} + +.text_class6317 +{ +font-size: 11px; +} + +.text_class6318 +{ +} + +.paragraph_class6319 +{ +} + +.text_class6320 +{ +font-size: 11px; +} + +.text_class6321 +{ +} + +.paragraph_class6322 +{ +} + +.text_class6323 +{ +font-size: 11px; +} + +.text_class6324 +{ +} + +.paragraph_class6325 +{ +} + +.text_class6326 +{ +font-size: 11px; +} + +.text_class6327 +{ +font-size: 11px; +} + +.text_class6328 +{ +font-size: 11px; +} + +.text_class6329 +{ +font-size: 11px; +} + +.text_class6330 +{ +font-size: 11px; +} + +.text_class6331 +{ +} + +.paragraph_class6332 +{ +} + +.text_class6333 +{ +font-size: 11px; +} + +.text_class6334 +{ +font-size: 11px; +} + +.text_class6335 +{ +font-size: 11px; +} + +.text_class6336 +{ +font-size: 11px; +} + +.text_class6337 +{ +} + +.text_class6338 +{ +} + +.paragraph_class6339 +{ +} + +.text_class6340 +{ +font-family: arial; +} + +.text_class6341 +{ +font-size: 11px; +} + +.text_class6342 +{ +font-size: 11px; +} + +.text_class6343 +{ +} + +.text_class6344 +{ +font-family: arial; +} + +.text_class6345 +{ +font-size: 11px; +} + +.paragraph_class6346 +{ +} + +.text_class6347 +{ +font-size: 11px; +} + +.text_class6348 +{ +font-family: arial; +} + +.paragraph_class6349 +{ +} + +.text_class6350 +{ +font-size: 11px; +} + +.text_class6351 +{ +font-family: arial; +} + +.paragraph_class6352 +{ +} + +.text_class6353 +{ +font-size: 11px; +} + +.paragraph_class6354 +{ +} + +.text_class6355 +{ +font-size: 11px; +} + +.text_class6356 +{ +} + +.text_class6357 +{ +} + +.paragraph_class6358 +{ +text-align: center; +margin-left: 0px; +} + +.text_class6359 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6360 +{ +font-weight: bold; +} + +.text_class6361 +{ +} + +.text_class6362 +{ +} + +.paragraph_class6363 +{ +} + +.text_class6364 +{ +font-family: arial; +} + +.text_class6365 +{ +font-size: 11px; +} + +.text_class6366 +{ +font-family: arial; +} + +.text_class6367 +{ +font-size: 11px; +} + +.text_class6368 +{ +} + +.text_class6369 +{ +font-family: arial; +} + +.text_class6370 +{ +font-size: 11px; +} + +.text_class6371 +{ +font-family: arial; +} + +.text_class6372 +{ +font-size: 11px; +} + +.text_class6373 +{ +font-family: arial; +} + +.text_class6374 +{ +font-size: 11px; +} + +.text_class6375 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6376 +{ +margin-left: 26px; +} + +.paragraph_class6377 +{ +} + +.text_class6378 +{ +font-family: arial; +} + +.text_class6379 +{ +font-size: 11px; +} + +.paragraph_class6380 +{ +} + +.text_class6381 +{ +font-size: 11px; +} + +.text_class6382 +{ +font-size: 11px; +} + +.paragraph_class6383 +{ +} + +.text_class6384 +{ +font-family: arial; +} + +.text_class6385 +{ +font-size: 11px; +} + +.paragraph_class6386 +{ +} + +.text_class6387 +{ +font-size: 11px; +} + +.text_class6388 +{ +font-size: 11px; +} + +.paragraph_class6389 +{ +} + +.text_class6390 +{ +font-family: arial; +} + +.text_class6391 +{ +font-size: 11px; +} + +.paragraph_class6392 +{ +} + +.text_class6393 +{ +font-size: 11px; +} + +.text_class6394 +{ +font-size: 11px; +} + +.paragraph_class6395 +{ +} + +.text_class6396 +{ +font-family: arial; +} + +.text_class6397 +{ +font-size: 11px; +} + +.paragraph_class6398 +{ +} + +.text_class6399 +{ +font-size: 11px; +} + +.text_class6400 +{ +font-size: 11px; +} + +.paragraph_class6401 +{ +} + +.text_class6402 +{ +font-family: arial; +} + +.text_class6403 +{ +font-size: 11px; +} + +.text_class6404 +{ +} + +.text_class6405 +{ +} + +.paragraph_class6406 +{ +} + +.text_class6407 +{ +font-family: arial; +} + +.text_class6408 +{ +font-size: 11px; +} + +.text_class6409 +{ +} + +.text_class6410 +{ +} + +.paragraph_class6411 +{ +} + +.text_class6412 +{ +font-family: arial; +} + +.text_class6413 +{ +font-size: 11px; +} + +.text_class6414 +{ +} + +.text_class6415 +{ +} + +.paragraph_class6416 +{ +} + +.text_class6417 +{ +font-family: arial; +} + +.text_class6418 +{ +font-size: 11px; +} + +.text_class6419 +{ +} + +.text_class6420 +{ +} + +.paragraph_class6421 +{ +} + +.text_class6422 +{ +font-family: arial; +} + +.text_class6423 +{ +font-size: 11px; +} + +.text_class6424 +{ +} + +.paragraph_class6425 +{ +} + +.text_class6426 +{ +font-family: arial; +} + +.text_class6427 +{ +font-size: 11px; +} + +.text_class6428 +{ +} + +.paragraph_class6429 +{ +} + +.text_class6430 +{ +font-family: arial; +} + +.text_class6431 +{ +font-size: 11px; +} + +.text_class6432 +{ +} + +.paragraph_class6433 +{ +} + +.text_class6434 +{ +font-family: arial; +} + +.text_class6435 +{ +font-size: 11px; +} + +.paragraph_class6436 +{ +} + +.text_class6437 +{ +font-family: arial; +} + +.text_class6438 +{ +font-size: 11px; +} + +.text_class6439 +{ +} + +.paragraph_class6440 +{ +} + +.text_class6441 +{ +font-family: arial; +} + +.text_class6442 +{ +font-size: 11px; +} + +.paragraph_class6443 +{ +} + +.text_class6444 +{ +font-family: arial; +} + +.text_class6445 +{ +font-size: 11px; +} + +.text_class6446 +{ +} + +.paragraph_class6447 +{ +} + +.text_class6448 +{ +font-family: arial; +} + +.text_class6449 +{ +font-size: 11px; +} + +.text_class6450 +{ +font-family: ｍｓ 明朝; +} + +.text_class6451 +{ +font-size: 11px; +} + +.text_class6452 +{ +font-family: arial; +} + +.text_class6453 +{ +font-size: 11px; +} + +.text_class6454 +{ +} + +.paragraph_class6455 +{ +} + +.text_class6456 +{ +font-family: arial; +} + +.text_class6457 +{ +font-size: 11px; +} + +.text_class6458 +{ +} + +.paragraph_class6459 +{ +} + +.text_class6460 +{ +font-family: arial; +} + +.text_class6461 +{ +font-size: 11px; +} + +.text_class6462 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6463 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6464 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6465 +{ +} + +.text_class6466 +{ +font-family: arial; +} + +.text_class6467 +{ +font-size: 11px; +} + +.text_class6468 +{ +font-family: arial; +} + +.text_class6469 +{ +font-size: 11px; +} + +.text_class6470 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6471 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6472 +{ +font-family: arial; +} + +.text_class6473 +{ +font-size: 11px; +} + +.text_class6474 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6475 +{ +} + +.paragraph_class6476 +{ +} + +.text_class6477 +{ +font-family: arial; +} + +.text_class6478 +{ +font-size: 11px; +} + +.paragraph_class6479 +{ +} + +.text_class6480 +{ +font-family: arial; +} + +.text_class6481 +{ +font-size: 11px; +} + +.text_class6482 +{ +} + +.paragraph_class6483 +{ +} + +.text_class6484 +{ +font-family: arial; +} + +.text_class6485 +{ +font-size: 11px; +} + +.text_class6486 +{ +} + +.paragraph_class6487 +{ +} + +.text_class6488 +{ +font-family: arial; +} + +.text_class6489 +{ +font-size: 11px; +} + +.paragraph_class6490 +{ +} + +.text_class6491 +{ +font-family: arial; +} + +.text_class6492 +{ +font-size: 11px; +} + +.text_class6493 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6494 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6495 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6496 +{ +font-family: arial; +} + +.text_class6497 +{ +font-size: 11px; +} + +.text_class6498 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6499 +{ +} + +.paragraph_class6500 +{ +} + +.text_class6501 +{ +font-family: arial; +} + +.text_class6502 +{ +font-size: 11px; +} + +.paragraph_class6503 +{ +} + +.text_class6504 +{ +font-family: arial; +} + +.text_class6505 +{ +font-size: 11px; +} + +.text_class6506 +{ +font-family: arial; +} + +.text_class6507 +{ +font-size: 11px; +} + +.text_class6508 +{ +font-family: arial; +} + +.text_class6509 +{ +font-size: 11px; +} + +.text_class6510 +{ +font-family: arial; +} + +.text_class6511 +{ +font-size: 11px; +} + +.text_class6512 +{ +font-family: arial; +} + +.text_class6513 +{ +font-size: 11px; +} + +.text_class6514 +{ +} + +.paragraph_class6515 +{ +} + +.text_class6516 +{ +font-family: arial; +} + +.text_class6517 +{ +font-size: 11px; +} + +.paragraph_class6518 +{ +} + +.text_class6519 +{ +font-family: arial; +} + +.text_class6520 +{ +font-size: 11px; +} + +.text_class6521 +{ +font-family: arial; +} + +.text_class6522 +{ +font-size: 11px; +} + +.text_class6523 +{ +font-family: arial; +} + +.text_class6524 +{ +font-size: 11px; +} + +.text_class6525 +{ +font-family: arial; +} + +.text_class6526 +{ +font-size: 11px; +} + +.text_class6527 +{ +font-family: arial; +} + +.text_class6528 +{ +font-size: 11px; +} + +.text_class6529 +{ +font-family: arial; +} + +.text_class6530 +{ +font-size: 11px; +} + +.paragraph_class6531 +{ +} + +.text_class6532 +{ +font-family: arial; +} + +.text_class6533 +{ +font-size: 11px; +} + +.paragraph_class6534 +{ +} + +.text_class6535 +{ +font-family: arial; +} + +.text_class6536 +{ +font-size: 11px; +} + +.text_class6537 +{ +} + +.paragraph_class6538 +{ +} + +.text_class6539 +{ +font-family: arial; +} + +.text_class6540 +{ +font-size: 11px; +} + +.paragraph_class6541 +{ +} + +.text_class6542 +{ +font-family: arial; +} + +.text_class6543 +{ +font-size: 11px; +} + +.paragraph_class6544 +{ +} + +.text_class6545 +{ +font-family: arial; +} + +.text_class6546 +{ +font-size: 11px; +} + +.paragraph_class6547 +{ +} + +.text_class6548 +{ +font-family: arial; +} + +.text_class6549 +{ +font-size: 11px; +} + +.text_class6550 +{ +font-family: arial; +} + +.text_class6551 +{ +font-size: 11px; +} + +.text_class6552 +{ +font-family: arial; +} + +.text_class6553 +{ +font-size: 11px; +} + +.text_class6554 +{ +font-family: arial; +} + +.text_class6555 +{ +font-size: 11px; +} + +.text_class6556 +{ +font-family: arial; +} + +.text_class6557 +{ +font-size: 11px; +} + +.text_class6558 +{ +} + +.paragraph_class6559 +{ +} + +.text_class6560 +{ +font-family: arial; +} + +.text_class6561 +{ +font-size: 11px; +} + +.paragraph_class6562 +{ +} + +.text_class6563 +{ +font-family: arial; +} + +.text_class6564 +{ +font-size: 11px; +} + +.text_class6565 +{ +} + +.paragraph_class6566 +{ +} + +.text_class6567 +{ +font-family: arial; +} + +.text_class6568 +{ +font-size: 11px; +} + +.paragraph_class6569 +{ +} + +.text_class6570 +{ +font-family: arial; +} + +.text_class6571 +{ +font-size: 11px; +} + +.text_class6572 +{ +font-family: arial; +} + +.text_class6573 +{ +font-size: 11px; +} + +.text_class6574 +{ +font-family: arial; +} + +.text_class6575 +{ +font-size: 11px; +} + +.text_class6576 +{ +font-family: arial; +} + +.text_class6577 +{ +font-size: 11px; +} + +.text_class6578 +{ +font-family: arial; +} + +.text_class6579 +{ +font-size: 11px; +} + +.paragraph_class6580 +{ +} + +.text_class6581 +{ +font-family: arial; +} + +.text_class6582 +{ +font-size: 11px; +} + +.text_class6583 +{ +} + +.paragraph_class6584 +{ +} + +.text_class6585 +{ +font-family: arial; +} + +.text_class6586 +{ +font-size: 11px; +} + +.text_class6587 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6588 +{ +} + +.paragraph_class6589 +{ +} + +.text_class6590 +{ +font-family: arial; +} + +.text_class6591 +{ +font-size: 11px; +} + +.text_class6592 +{ +} + +.paragraph_class6593 +{ +} + +.text_class6594 +{ +font-family: arial; +} + +.text_class6595 +{ +font-size: 11px; +} + +.text_class6596 +{ +} + +.paragraph_class6597 +{ +} + +.text_class6598 +{ +font-family: arial; +} + +.text_class6599 +{ +font-size: 11px; +} + +.paragraph_class6600 +{ +} + +.paragraph_class6601 +{ +} + +.text_class6602 +{ +font-family: arial; +} + +.text_class6603 +{ +font-size: 11px; +} + +.text_class6604 +{ +} + +.paragraph_class6605 +{ +} + +.text_class6606 +{ +font-family: arial; +} + +.text_class6607 +{ +font-size: 11px; +} + +.text_class6608 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6609 +{ +} + +.paragraph_class6610 +{ +} + +.text_class6611 +{ +font-family: arial; +} + +.text_class6612 +{ +font-size: 11px; +} + +.text_class6613 +{ +} + +.paragraph_class6614 +{ +} + +.text_class6615 +{ +font-family: arial; +} + +.text_class6616 +{ +font-size: 11px; +} + +.text_class6617 +{ +} + +.paragraph_class6618 +{ +} + +.text_class6619 +{ +font-family: arial; +} + +.text_class6620 +{ +font-size: 11px; +} + +.paragraph_class6621 +{ +} + +.text_class6622 +{ +font-family: arial; +} + +.text_class6623 +{ +font-size: 11px; +} + +.text_class6624 +{ +} + +.paragraph_class6625 +{ +} + +.text_class6626 +{ +font-family: arial; +} + +.text_class6627 +{ +font-size: 11px; +} + +.paragraph_class6628 +{ +} + +.text_class6629 +{ +font-family: arial; +} + +.text_class6630 +{ +font-size: 11px; +} + +.text_class6631 +{ +} + +.paragraph_class6632 +{ +} + +.text_class6633 +{ +font-family: arial; +} + +.text_class6634 +{ +font-size: 11px; +} + +.text_class6635 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6636 +{ +} + +.paragraph_class6637 +{ +} + +.text_class6638 +{ +font-family: arial; +} + +.text_class6639 +{ +font-size: 11px; +} + +.paragraph_class6640 +{ +} + +.text_class6641 +{ +font-family: arial; +} + +.text_class6642 +{ +font-size: 11px; +} + +.text_class6643 +{ +} + +.paragraph_class6644 +{ +} + +.text_class6645 +{ +font-family: arial; +} + +.text_class6646 +{ +font-size: 11px; +} + +.text_class6647 +{ +} + +.paragraph_class6648 +{ +} + +.text_class6649 +{ +font-family: arial; +} + +.text_class6650 +{ +font-size: 11px; +} + +.paragraph_class6651 +{ +} + +.text_class6652 +{ +font-family: arial; +} + +.text_class6653 +{ +font-size: 11px; +} + +.text_class6654 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6655 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6656 +{ +font-family: arial; +} + +.text_class6657 +{ +font-size: 11px; +} + +.text_class6658 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6659 +{ +font-family: arial; +} + +.text_class6660 +{ +font-size: 11px; +} + +.text_class6661 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6662 +{ +} + +.paragraph_class6663 +{ +} + +.text_class6664 +{ +font-family: arial; +} + +.text_class6665 +{ +font-size: 11px; +} + +.text_class6666 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6667 +{ +} + +.text_class6668 +{ +} + +.paragraph_class6669 +{ +} + +.text_class6670 +{ +font-family: arial; +} + +.text_class6671 +{ +font-size: 11px; +} + +.text_class6672 +{ +} + +.paragraph_class6673 +{ +} + +.text_class6674 +{ +font-family: arial; +} + +.text_class6675 +{ +font-size: 11px; +} + +.text_class6676 +{ +font-family: arial; +} + +.text_class6677 +{ +font-size: 11px; +} + +.text_class6678 +{ +font-family: arial; +} + +.text_class6679 +{ +font-size: 11px; +} + +.text_class6680 +{ +font-family: arial; +} + +.text_class6681 +{ +font-size: 11px; +} + +.text_class6682 +{ +font-family: arial; +} + +.text_class6683 +{ +font-size: 11px; +} + +.text_class6684 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6685 +{ +} + +.paragraph_class6686 +{ +} + +.text_class6687 +{ +font-family: arial; +} + +.text_class6688 +{ +font-size: 11px; +} + +.text_class6689 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6690 +{ +} + +.paragraph_class6691 +{ +} + +.text_class6692 +{ +font-family: arial; +} + +.text_class6693 +{ +font-size: 11px; +} + +.text_class6694 +{ +} + +.paragraph_class6695 +{ +} + +.text_class6696 +{ +font-family: arial; +} + +.text_class6697 +{ +font-size: 11px; +} + +.text_class6698 +{ +font-family: arial; +} + +.text_class6699 +{ +font-size: 11px; +} + +.text_class6700 +{ +font-family: arial; +} + +.text_class6701 +{ +font-size: 11px; +} + +.text_class6702 +{ +font-family: arial; +} + +.text_class6703 +{ +font-size: 11px; +} + +.text_class6704 +{ +} + +.paragraph_class6705 +{ +} + +.text_class6706 +{ +font-family: arial; +} + +.text_class6707 +{ +font-size: 11px; +} + +.text_class6708 +{ +font-family: arial; +} + +.text_class6709 +{ +font-size: 11px; +} + +.text_class6710 +{ +font-family: arial; +} + +.text_class6711 +{ +font-size: 11px; +} + +.text_class6712 +{ +font-family: arial; +} + +.text_class6713 +{ +font-size: 11px; +} + +.text_class6714 +{ +font-family: arial; +} + +.text_class6715 +{ +font-size: 11px; +} + +.text_class6716 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6717 +{ +} + +.paragraph_class6718 +{ +} + +.text_class6719 +{ +font-family: arial; +} + +.text_class6720 +{ +font-size: 11px; +} + +.text_class6721 +{ +} + +.paragraph_class6722 +{ +} + +.text_class6723 +{ +font-family: arial; +} + +.text_class6724 +{ +font-size: 11px; +} + +.text_class6725 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6726 +{ +} + +.paragraph_class6727 +{ +} + +.text_class6728 +{ +font-family: arial; +} + +.text_class6729 +{ +font-size: 11px; +} + +.paragraph_class6730 +{ +} + +.text_class6731 +{ +font-family: arial; +} + +.text_class6732 +{ +font-size: 11px; +} + +.paragraph_class6733 +{ +} + +.text_class6734 +{ +font-family: arial; +} + +.text_class6735 +{ +font-size: 11px; +} + +.paragraph_class6736 +{ +} + +.text_class6737 +{ +font-family: arial; +} + +.text_class6738 +{ +font-size: 11px; +} + +.text_class6739 +{ +} + +.text_class6740 +{ +} + +.paragraph_class6741 +{ +} + +.text_class6742 +{ +font-size: 11px; +} + +.text_class6743 +{ +} + +.text_class6744 +{ +} + +.paragraph_class6745 +{ +} + +.text_class6746 +{ +font-family: arial; +} + +.text_class6747 +{ +font-size: 11px; +} + +.text_class6748 +{ +} + +.paragraph_class6749 +{ +} + +.text_class6750 +{ +font-family: arial; +} + +.text_class6751 +{ +font-size: 11px; +} + +.text_class6752 +{ +} + +.paragraph_class6753 +{ +} + +.text_class6754 +{ +font-family: arial; +} + +.text_class6755 +{ +font-size: 11px; +} + +.text_class6756 +{ +} + +.paragraph_class6757 +{ +} + +.text_class6758 +{ +font-family: arial; +} + +.text_class6759 +{ +font-size: 11px; +} + +.text_class6760 +{ +} + +.paragraph_class6761 +{ +} + +.text_class6762 +{ +font-family: arial; +} + +.text_class6763 +{ +font-size: 11px; +} + +.text_class6764 +{ +} + +.paragraph_class6765 +{ +} + +.text_class6766 +{ +font-family: arial; +} + +.text_class6767 +{ +font-size: 11px; +} + +.text_class6768 +{ +} + +.paragraph_class6769 +{ +} + +.text_class6770 +{ +font-family: arial; +} + +.text_class6771 +{ +font-size: 11px; +} + +.text_class6772 +{ +} + +.paragraph_class6773 +{ +} + +.text_class6774 +{ +font-family: arial; +} + +.text_class6775 +{ +font-size: 11px; +} + +.text_class6776 +{ +} + +.paragraph_class6777 +{ +} + +.text_class6778 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6779 +{ +} + +.paragraph_class6780 +{ +} + +.text_class6781 +{ +font-family: arial; +} + +.text_class6782 +{ +font-size: 11px; +} + +.text_class6783 +{ +} + +.paragraph_class6784 +{ +} + +.text_class6785 +{ +font-family: arial; +} + +.text_class6786 +{ +font-size: 11px; +} + +.text_class6787 +{ +} + +.paragraph_class6788 +{ +} + +.text_class6789 +{ +font-family: arial; +} + +.text_class6790 +{ +font-size: 11px; +} + +.text_class6791 +{ +} + +.paragraph_class6792 +{ +} + +.text_class6793 +{ +font-family: arial; +} + +.text_class6794 +{ +font-size: 11px; +} + +.text_class6795 +{ +} + +.paragraph_class6796 +{ +} + +.text_class6797 +{ +font-family: arial; +} + +.text_class6798 +{ +font-size: 11px; +} + +.text_class6799 +{ +} + +.paragraph_class6800 +{ +} + +.text_class6801 +{ +font-family: arial; +} + +.text_class6802 +{ +font-size: 11px; +} + +.text_class6803 +{ +} + +.paragraph_class6804 +{ +} + +.text_class6805 +{ +font-family: arial; +} + +.text_class6806 +{ +font-size: 11px; +} + +.text_class6807 +{ +} + +.paragraph_class6808 +{ +} + +.text_class6809 +{ +font-family: arial; +} + +.text_class6810 +{ +font-size: 11px; +} + +.text_class6811 +{ +} + +.text_class6812 +{ +} + +.paragraph_class6813 +{ +} + +.text_class6814 +{ +font-size: 11px; +} + +.text_class6815 +{ +} + +.text_class6816 +{ +} + +.paragraph_class6817 +{ +} + +.text_class6818 +{ +font-size: 11px; +} + +.text_class6819 +{ +font-family: arial; +} + +.paragraph_class6820 +{ +} + +.text_class6821 +{ +font-size: 11px; +} + +.text_class6822 +{ +font-family: arial; +} + +.text_class6823 +{ +} + +.text_class6824 +{ +font-size: 11px; +} + +.text_class6825 +{ +} + +.paragraph_class6826 +{ +} + +.text_class6827 +{ +font-size: 11px; +} + +.text_class6828 +{ +font-family: arial; +} + +.text_class6829 +{ +} + +.text_class6830 +{ +} + +.text_class6831 +{ +} + +.text_class6832 +{ +} + +.paragraph_class6833 +{ +} + +.text_class6834 +{ +font-size: 11px; +} + +.text_class6835 +{ +} + +.text_class6836 +{ +} + +.paragraph_class6837 +{ +} + +.text_class6838 +{ +font-family: arial; +} + +.text_class6839 +{ +font-size: 11px; +} + +.paragraph_class6840 +{ +} + +.paragraph_class6841 +{ +} + +.text_class6842 +{ +font-family: arial; +} + +.text_class6843 +{ +font-size: 11px; +} + +.text_class6844 +{ +} + +.paragraph_class6845 +{ +} + +.text_class6846 +{ +font-family: arial; +} + +.text_class6847 +{ +font-size: 11px; +} + +.text_class6848 +{ +} + +.text_class6849 +{ +} + +.text_class6850 +{ +} + +.paragraph_class6851 +{ +} + +.text_class6852 +{ +font-size: 11px; +} + +.text_class6853 +{ +font-family: arial; +} + +.text_class6854 +{ +} + +.text_class6855 +{ +} + +.paragraph_class6856 +{ +} + +.text_class6857 +{ +font-family: arial; +} + +.text_class6858 +{ +font-size: 11px; +} + +.text_class6859 +{ +} + +.paragraph_class6860 +{ +} + +.text_class6861 +{ +font-family: arial; +} + +.text_class6862 +{ +font-size: 11px; +} + +.text_class6863 +{ +font-family: arial; +} + +.text_class6864 +{ +font-size: 11px; +} + +.text_class6865 +{ +font-family: arial; +} + +.text_class6866 +{ +font-size: 11px; +} + +.text_class6867 +{ +font-family: arial; +} + +.text_class6868 +{ +font-size: 11px; +} + +.text_class6869 +{ +} + +.text_class6870 +{ +} + +.text_class6871 +{ +} + +.paragraph_class6872 +{ +} + +.text_class6873 +{ +font-family: arial; +} + +.text_class6874 +{ +font-size: 11px; +} + +.paragraph_class6875 +{ +} + +.text_class6876 +{ +font-style: italic; +} + +.text_class6877 +{ +font-family: arial; +} + +.text_class6878 +{ +font-size: 11px; +} + +.text_class6879 +{ +font-family: arial; +} + +.text_class6880 +{ +font-size: 11px; +} + +.text_class6881 +{ +font-style: italic; +} + +.text_class6882 +{ +font-family: arial; +} + +.text_class6883 +{ +font-size: 11px; +} + +.text_class6884 +{ +font-family: arial; +} + +.text_class6885 +{ +font-size: 11px; +} + +.text_class6886 +{ +font-style: italic; +} + +.text_class6887 +{ +font-family: arial; +} + +.text_class6888 +{ +font-size: 11px; +} + +.text_class6889 +{ +font-family: arial; +} + +.text_class6890 +{ +font-size: 11px; +} + +.paragraph_class6891 +{ +} + +.paragraph_class6892 +{ +} + +.text_class6893 +{ +font-family: arial; +} + +.text_class6894 +{ +font-size: 11px; +} + +.text_class6895 +{ +} + +.cell_class6896 +{ +width: 435px; +background-color: #bfbfbf; +} + +.paragraph_class6898 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class6899 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6900 +{ +font-weight: bold; +} + +.cell_class6901 +{ +width: 147px; +background-color: #bfbfbf; +} + +.paragraph_class6903 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class6904 +{ +font-size: 11px; +font-family: arial; +} + +.text_class6905 +{ +font-weight: bold; +} + +.cell_class6906 +{ +width: 435px; +} + +.list_class6907 +{ +list-style-type: decimal; +} + +.text_class6908 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6909 +{ +margin-left: 80px; +} + +.text_class6910 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6911 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6912 +{ +margin-left: 120px; +} + +.text_class6913 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6914 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6915 +{ +margin-left: 120px; +} + +.text_class6916 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6917 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6918 +{ +margin-left: 120px; +} + +.text_class6919 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6920 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6921 +{ +margin-left: 120px; +} + +.text_class6922 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6923 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6924 +{ +margin-left: 120px; +} + +.text_class6925 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6926 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6927 +{ +margin-left: 120px; +} + +.text_class6928 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6929 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6930 +{ +margin-left: 120px; +} + +.text_class6931 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6932 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6933 +{ +margin-left: 120px; +} + +.text_class6934 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6935 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6936 +{ +margin-left: 120px; +} + +.text_class6937 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6938 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6939 +{ +margin-left: 120px; +} + +.text_class6940 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6941 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6942 +{ +margin-left: 120px; +} + +.text_class6943 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6944 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6945 +{ +margin-left: 120px; +} + +.text_class6946 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6947 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6948 +{ +margin-left: 120px; +} + +.text_class6949 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6950 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6951 +{ +margin-left: 120px; +} + +.text_class6952 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6953 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6954 +{ +margin-left: 120px; +} + +.text_class6955 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6956 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6957 +{ +margin-left: 120px; +} + +.text_class6958 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6959 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6960 +{ +margin-left: 120px; +} + +.text_class6961 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6962 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6963 +{ +margin-left: 120px; +} + +.text_class6964 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6965 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6966 +{ +margin-left: 80px; +} + +.text_class6967 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6968 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6969 +{ +margin-left: 120px; +} + +.text_class6970 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6971 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6972 +{ +margin-left: 120px; +} + +.text_class6973 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6974 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6975 +{ +margin-left: 120px; +} + +.text_class6976 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6977 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6978 +{ +margin-left: 120px; +} + +.text_class6979 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6980 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6981 +{ +margin-left: 120px; +} + +.text_class6982 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6983 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6984 +{ +margin-left: 120px; +} + +.text_class6985 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6986 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6987 +{ +margin-left: 120px; +} + +.text_class6988 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6989 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6990 +{ +margin-left: 120px; +} + +.text_class6991 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6992 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6993 +{ +margin-left: 80px; +} + +.text_class6994 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6995 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6996 +{ +margin-left: 120px; +} + +.text_class6997 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class6998 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class6999 +{ +margin-left: 120px; +} + +.text_class7000 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7001 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7002 +{ +margin-left: 120px; +} + +.text_class7003 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7004 +{ +font-size: 11px; +font-family: arial; +} + +.cell_class7005 +{ +width: 147px; +} + +.list_class7006 +{ +list-style-type: decimal; +} + +.text_class7007 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7008 +{ +margin-left: 80px; +} + +.text_class7009 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7010 +{ +font-size: 11px; +font-family: arial; +} + +.list_class7011 +{ +list-style-type: decimal; +} + +.text_class7012 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7013 +{ +margin-left: 80px; +} + +.text_class7014 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7015 +{ +font-size: 11px; +font-family: arial; +} + +.list_class7016 +{ +list-style-type: decimal; +} + +.text_class7017 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7018 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7019 +{ +margin-left: 80px; +} + +.text_class7020 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7021 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7022 +{ +margin-left: 80px; +} + +.text_class7023 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7024 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7025 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7026 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7027 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7028 +{ +margin-left: 80px; +} + +.text_class7029 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7030 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7031 +{ +margin-left: 80px; +} + +.text_class7032 +{ +font-size: 10px; +font-family: times new roman; +} + +.text_class7033 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7034 +{ +} + +.text_class7035 +{ +} + +.paragraph_class7036 +{ +} + +.text_class7037 +{ +font-family: arial; +} + +.text_class7038 +{ +font-size: 11px; +} + +.text_class7039 +{ +} + +.paragraph_class7040 +{ +} + +.text_class7041 +{ +font-family: arial; +} + +.text_class7042 +{ +font-size: 11px; +} + +.text_class7043 +{ +} + +.paragraph_class7044 +{ +} + +.text_class7045 +{ +font-family: arial; +} + +.text_class7046 +{ +font-size: 11px; +} + +.text_class7047 +{ +} + +.paragraph_class7048 +{ +} + +.text_class7049 +{ +font-family: arial; +} + +.text_class7050 +{ +font-size: 11px; +} + +.text_class7051 +{ +} + +.paragraph_class7052 +{ +} + +.text_class7053 +{ +font-family: arial; +} + +.text_class7054 +{ +font-size: 11px; +} + +.text_class7055 +{ +} + +.paragraph_class7056 +{ +} + +.text_class7057 +{ +font-family: arial; +} + +.text_class7058 +{ +font-size: 11px; +} + +.text_class7059 +{ +} + +.paragraph_class7060 +{ +} + +.text_class7061 +{ +font-family: arial; +} + +.text_class7062 +{ +font-size: 11px; +} + +.text_class7063 +{ +} + +.paragraph_class7064 +{ +} + +.text_class7065 +{ +font-family: arial; +} + +.text_class7066 +{ +font-size: 11px; +} + +.text_class7067 +{ +} + +.paragraph_class7068 +{ +} + +.text_class7069 +{ +font-family: arial; +} + +.text_class7070 +{ +font-size: 11px; +} + +.text_class7071 +{ +} + +.paragraph_class7072 +{ +} + +.text_class7073 +{ +font-family: arial; +} + +.text_class7074 +{ +font-size: 11px; +} + +.text_class7075 +{ +} + +.paragraph_class7076 +{ +} + +.text_class7077 +{ +font-family: arial; +} + +.text_class7078 +{ +font-size: 11px; +} + +.text_class7079 +{ +} + +.paragraph_class7080 +{ +} + +.text_class7081 +{ +font-family: arial; +} + +.text_class7082 +{ +font-size: 11px; +} + +.text_class7083 +{ +} + +.paragraph_class7084 +{ +} + +.text_class7085 +{ +font-family: arial; +} + +.text_class7086 +{ +font-size: 11px; +} + +.text_class7087 +{ +} + +.paragraph_class7088 +{ +} + +.text_class7089 +{ +font-family: arial; +} + +.text_class7090 +{ +font-size: 11px; +} + +.text_class7091 +{ +} + +.paragraph_class7092 +{ +} + +.text_class7093 +{ +font-family: arial; +} + +.text_class7094 +{ +font-size: 11px; +} + +.text_class7095 +{ +} + +.paragraph_class7096 +{ +} + +.text_class7097 +{ +font-family: arial; +} + +.text_class7098 +{ +font-size: 11px; +} + +.text_class7099 +{ +} + +.paragraph_class7100 +{ +} + +.text_class7101 +{ +font-family: arial; +} + +.text_class7102 +{ +font-size: 11px; +} + +.text_class7103 +{ +} + +.paragraph_class7104 +{ +} + +.text_class7105 +{ +font-family: arial; +} + +.text_class7106 +{ +font-size: 11px; +} + +.text_class7107 +{ +} + +.paragraph_class7108 +{ +} + +.text_class7109 +{ +font-family: arial; +} + +.text_class7110 +{ +font-size: 11px; +} + +.text_class7111 +{ +} + +.paragraph_class7112 +{ +} + +.text_class7113 +{ +font-family: arial; +} + +.text_class7114 +{ +font-size: 11px; +} + +.text_class7115 +{ +} + +.paragraph_class7116 +{ +} + +.text_class7117 +{ +font-family: arial; +} + +.text_class7118 +{ +font-size: 11px; +} + +.text_class7119 +{ +} + +.paragraph_class7120 +{ +} + +.text_class7121 +{ +font-family: arial; +} + +.text_class7122 +{ +font-size: 11px; +} + +.text_class7123 +{ +} + +.paragraph_class7124 +{ +} + +.text_class7125 +{ +font-family: arial; +} + +.text_class7126 +{ +font-size: 11px; +} + +.text_class7127 +{ +} + +.paragraph_class7128 +{ +} + +.text_class7129 +{ +font-family: arial; +} + +.text_class7130 +{ +font-size: 11px; +} + +.text_class7131 +{ +} + +.paragraph_class7132 +{ +} + +.text_class7133 +{ +font-family: arial; +} + +.text_class7134 +{ +font-size: 11px; +} + +.text_class7135 +{ +} + +.paragraph_class7136 +{ +} + +.text_class7137 +{ +font-family: arial; +} + +.text_class7138 +{ +font-size: 11px; +} + +.text_class7139 +{ +} + +.paragraph_class7140 +{ +} + +.text_class7141 +{ +font-family: arial; +} + +.text_class7142 +{ +font-size: 11px; +} + +.text_class7143 +{ +} + +.paragraph_class7144 +{ +} + +.text_class7145 +{ +font-family: arial; +} + +.text_class7146 +{ +font-size: 11px; +} + +.text_class7147 +{ +} + +.paragraph_class7148 +{ +} + +.text_class7149 +{ +font-family: arial; +} + +.text_class7150 +{ +font-size: 11px; +} + +.text_class7151 +{ +} + +.paragraph_class7152 +{ +} + +.text_class7153 +{ +font-family: arial; +} + +.text_class7154 +{ +font-size: 11px; +} + +.text_class7155 +{ +} + +.paragraph_class7156 +{ +} + +.text_class7157 +{ +font-family: arial; +} + +.text_class7158 +{ +font-size: 11px; +} + +.text_class7159 +{ +} + +.paragraph_class7160 +{ +} + +.text_class7161 +{ +font-family: arial; +} + +.text_class7162 +{ +font-size: 11px; +} + +.text_class7163 +{ +} + +.text_class7164 +{ +} + +.paragraph_class7165 +{ +} + +.text_class7166 +{ +font-size: 11px; +} + +.paragraph_class7167 +{ +} + +.text_class7168 +{ +font-size: 11px; +} + +.text_class7169 +{ +} + +.text_class7170 +{ +} + +.paragraph_class7171 +{ +} + +.text_class7172 +{ +font-family: arial; +} + +.text_class7173 +{ +font-size: 11px; +} + +.paragraph_class7174 +{ +} + +.paragraph_class7175 +{ +} + +.text_class7176 +{ +font-family: arial; +} + +.text_class7177 +{ +font-size: 11px; +} + +.paragraph_class7178 +{ +} + +.paragraph_class7179 +{ +} + +.text_class7180 +{ +font-family: arial; +} + +.text_class7181 +{ +font-size: 11px; +} + +.paragraph_class7182 +{ +} + +.paragraph_class7183 +{ +} + +.text_class7184 +{ +font-family: arial; +} + +.text_class7185 +{ +font-size: 11px; +} + +.text_class7186 +{ +font-family: arial; +} + +.text_class7187 +{ +font-size: 11px; +} + +.text_class7188 +{ +} + +.paragraph_class7189 +{ +text-align: center; +margin-left: 0px; +} + +.text_class7190 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7191 +{ +font-weight: bold; +} + +.text_class7192 +{ +} + +.paragraph_class7194 +{ +margin-left: 0px; +} + +.text_class7195 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7196 +{ +font-weight: bold; +} + +.paragraph_class7198 +{ +margin-left: 0px; +} + +.text_class7199 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7200 +{ +font-weight: bold; +} + +.paragraph_class7202 +{ +margin-left: 0px; +} + +.text_class7203 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7204 +{ +font-weight: bold; +} + +.paragraph_class7205 +{ +margin-left: 0px; +} + +.text_class7206 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7207 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class7208 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7209 +{ +margin-left: 0px; +} + +.text_class7210 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7211 +{ +margin-left: 0px; +} + +.text_class7212 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7213 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class7214 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7215 +{ +margin-left: 0px; +} + +.text_class7216 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7217 +{ +margin-left: 0px; +} + +.text_class7218 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7219 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class7220 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7221 +{ +margin-left: 0px; +} + +.text_class7222 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7223 +{ +margin-left: 0px; +} + +.text_class7224 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7225 +{ +text-align: justify; +margin-left: 0px; +} + +.text_class7226 +{ +font-size: 11px; +font-family: arial; +} + +.paragraph_class7227 +{ +margin-left: 0px; +} + +.text_class7228 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7229 +{ +} + +.paragraph_class7230 +{ +} + +.text_class7231 +{ +font-family: arial; +} + +.text_class7232 +{ +font-size: 11px; +} + +.text_class7233 +{ +font-family: arial; +} + +.text_class7234 +{ +font-size: 11px; +} + +.text_class7235 +{ +font-family: arial; +} + +.text_class7236 +{ +font-size: 11px; +} + +.text_class7237 +{ +} + +.paragraph_class7238 +{ +text-align: center; +margin-left: 0px; +} + +.text_class7239 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7240 +{ +font-weight: bold; +} + +.text_class7241 +{ +} + +.text_class7242 +{ +} + +.text_class7243 +{ +} + +.paragraph_class7244 +{ +} + +.text_class7245 +{ +font-family: arial; +} + +.text_class7246 +{ +font-size: 11px; +} + +.text_class7247 +{ +} + +.paragraph_class7248 +{ +} + +.text_class7249 +{ +font-family: arial; +} + +.text_class7250 +{ +font-size: 11px; +} + +.paragraph_class7251 +{ +} + +.text_class7252 +{ +font-family: arial; +} + +.text_class7253 +{ +font-size: 11px; +} + +.text_class7254 +{ +} + +.paragraph_class7255 +{ +} + +.text_class7256 +{ +font-family: arial; +} + +.text_class7257 +{ +font-size: 11px; +} + +.text_class7258 +{ +font-family: ｍｓ 明朝; +} + +.text_class7259 +{ +font-size: 11px; +} + +.text_class7260 +{ +font-family: arial; +} + +.text_class7261 +{ +font-size: 11px; +} + +.text_class7262 +{ +} + +.paragraph_class7263 +{ +} + +.text_class7264 +{ +font-family: arial; +} + +.text_class7265 +{ +font-size: 11px; +} + +.text_class7266 +{ +} + +.paragraph_class7267 +{ +} + +.text_class7268 +{ +font-family: arial; +} + +.text_class7269 +{ +font-size: 11px; +} + +.text_class7270 +{ +} + +.paragraph_class7271 +{ +} + +.text_class7272 +{ +font-family: arial; +} + +.text_class7273 +{ +font-size: 11px; +} + +.text_class7274 +{ +} + +.text_class7275 +{ +} + +.paragraph_class7276 +{ +} + +.text_class7277 +{ +font-family: arial; +} + +.text_class7278 +{ +font-size: 11px; +} + +.text_class7279 +{ +} + +.paragraph_class7280 +{ +} + +.text_class7281 +{ +font-family: arial; +} + +.text_class7282 +{ +font-size: 11px; +} + +.text_class7283 +{ +} + +.paragraph_class7284 +{ +} + +.text_class7285 +{ +font-family: arial; +} + +.text_class7286 +{ +font-size: 11px; +} + +.text_class7287 +{ +} + +.paragraph_class7288 +{ +} + +.text_class7289 +{ +font-family: arial; +} + +.text_class7290 +{ +font-size: 11px; +} + +.text_class7291 +{ +} + +.paragraph_class7292 +{ +} + +.text_class7293 +{ +font-family: arial; +} + +.text_class7294 +{ +font-size: 11px; +} + +.paragraph_class7295 +{ +} + +.text_class7296 +{ +font-family: arial; +} + +.text_class7297 +{ +font-size: 11px; +} + +.paragraph_class7298 +{ +} + +.text_class7299 +{ +font-family: arial; +} + +.text_class7300 +{ +font-size: 11px; +} + +.text_class7301 +{ +} + +.text_class7302 +{ +} + +.paragraph_class7303 +{ +} + +.text_class7304 +{ +font-family: arial; +} + +.text_class7305 +{ +font-size: 11px; +} + +.text_class7306 +{ +} + +.paragraph_class7307 +{ +} + +.text_class7308 +{ +font-family: arial; +} + +.text_class7309 +{ +font-size: 11px; +} + +.text_class7310 +{ +} + +.text_class7311 +{ +} + +.paragraph_class7312 +{ +} + +.text_class7313 +{ +font-family: arial; +} + +.text_class7314 +{ +font-size: 11px; +} + +.text_class7315 +{ +} + +.paragraph_class7316 +{ +} + +.text_class7317 +{ +font-family: arial; +} + +.text_class7318 +{ +font-size: 11px; +} + +.text_class7319 +{ +} + +.paragraph_class7320 +{ +} + +.text_class7321 +{ +font-family: arial; +} + +.text_class7322 +{ +font-size: 11px; +} + +.text_class7323 +{ +} + +.text_class7324 +{ +} + +.paragraph_class7325 +{ +} + +.text_class7326 +{ +font-size: 11px; +} + +.text_class7327 +{ +} + +.text_class7328 +{ +} + +.paragraph_class7329 +{ +} + +.text_class7330 +{ +font-family: arial; +} + +.paragraph_class7331 +{ +text-indent: -5.25px; +margin-left: 5px; +} + +.paragraph_class7332 +{ +} + +.text_class7333 +{ +font-family: arial; +} + +.paragraph_class7334 +{ +} + +.paragraph_class7335 +{ +} + +.text_class7336 +{ +font-family: arial; +} + +.paragraph_class7337 +{ +} + +.paragraph_class7338 +{ +} + +.text_class7339 +{ +font-family: arial; +} + +.paragraph_class7340 +{ +} + +.paragraph_class7341 +{ +} + +.text_class7342 +{ +font-family: arial; +} + +.text_class7343 +{ +} + +.text_class7344 +{ +} + +.paragraph_class7345 +{ +} + +.text_class7346 +{ +font-family: arial; +} + +.text_class7347 +{ +font-size: 11px; +} + +.text_class7348 +{ +} + +.paragraph_class7349 +{ +} + +.text_class7350 +{ +font-family: arial; +} + +.text_class7351 +{ +font-size: 11px; +} + +.text_class7352 +{ +} + +.paragraph_class7353 +{ +} + +.text_class7354 +{ +font-family: arial; +} + +.text_class7355 +{ +font-size: 11px; +} + +.text_class7356 +{ +} + +.paragraph_class7357 +{ +} + +.text_class7358 +{ +font-family: arial; +} + +.text_class7359 +{ +font-size: 11px; +} + +.text_class7360 +{ +} + +.paragraph_class7361 +{ +} + +.text_class7362 +{ +font-family: arial; +} + +.text_class7363 +{ +font-size: 11px; +} + +.text_class7364 +{ +} + +.paragraph_class7365 +{ +} + +.text_class7366 +{ +font-family: arial; +} + +.text_class7367 +{ +font-size: 11px; +} + +.text_class7368 +{ +} + +.text_class7369 +{ +} + +.paragraph_class7370 +{ +} + +.text_class7371 +{ +font-size: 11px; +} + +.text_class7372 +{ +font-family: arial; +} + +.paragraph_class7373 +{ +} + +.text_class7374 +{ +font-size: 11px; +} + +.text_class7375 +{ +font-family: arial; +} + +.text_class7376 +{ +font-size: 11px; +} + +.text_class7377 +{ +font-family: arial; +} + +.text_class7378 +{ +font-size: 11px; +} + +.text_class7379 +{ +font-family: arial; +} + +.text_class7380 +{ +font-size: 11px; +} + +.text_class7381 +{ +font-family: arial; +} + +.text_class7382 +{ +font-size: 11px; +} + +.text_class7383 +{ +font-family: arial; +} + +.text_class7384 +{ +font-family: arial; +} + +.text_class7385 +{ +font-size: 11px; +} + +.text_class7386 +{ +font-family: arial; +} + +.text_class7387 +{ +} + +.paragraph_class7388 +{ +} + +.text_class7389 +{ +font-family: arial; +} + +.text_class7390 +{ +font-size: 11px; +} + +.text_class7391 +{ +} + +.paragraph_class7392 +{ +} + +.text_class7393 +{ +font-family: arial; +} + +.text_class7394 +{ +font-size: 11px; +} + +.text_class7395 +{ +} + +.paragraph_class7396 +{ +} + +.text_class7397 +{ +font-family: arial; +} + +.text_class7398 +{ +font-size: 11px; +} + +.text_class7399 +{ +} + +.paragraph_class7400 +{ +} + +.text_class7401 +{ +font-family: arial; +} + +.text_class7402 +{ +font-size: 11px; +} + +.text_class7403 +{ +} + +.paragraph_class7404 +{ +} + +.text_class7405 +{ +font-family: arial; +} + +.text_class7406 +{ +font-size: 11px; +} + +.text_class7407 +{ +} + +.paragraph_class7408 +{ +} + +.text_class7409 +{ +font-family: arial; +} + +.text_class7410 +{ +font-size: 11px; +} + +.text_class7411 +{ +} + +.paragraph_class7412 +{ +} + +.text_class7413 +{ +font-family: arial; +} + +.text_class7414 +{ +font-size: 11px; +} + +.paragraph_class7415 +{ +} + +.text_class7416 +{ +font-family: arial; +} + +.text_class7417 +{ +font-size: 11px; +} + +.text_class7418 +{ +} + +.text_class7419 +{ +} + +.paragraph_class7420 +{ +} + +.text_class7421 +{ +font-family: arial; +} + +.text_class7422 +{ +font-size: 11px; +} + +.text_class7423 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7424 +{ +} + +.paragraph_class7425 +{ +} + +.text_class7426 +{ +font-family: arial; +} + +.text_class7427 +{ +font-size: 11px; +} + +.text_class7428 +{ +} + +.paragraph_class7429 +{ +} + +.text_class7430 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7431 +{ +font-family: arial; +} + +.text_class7432 +{ +font-size: 11px; +} + +.text_class7433 +{ +} + +.paragraph_class7434 +{ +} + +.text_class7435 +{ +font-family: arial; +} + +.text_class7436 +{ +font-size: 11px; +} + +.text_class7437 +{ +} + +.paragraph_class7438 +{ +} + +.text_class7439 +{ +font-family: arial; +} + +.text_class7440 +{ +font-size: 11px; +} + +.text_class7441 +{ +} + +.paragraph_class7442 +{ +} + +.text_class7443 +{ +font-family: arial; +} + +.text_class7444 +{ +font-size: 11px; +} + +.text_class7445 +{ +} + +.paragraph_class7446 +{ +} + +.text_class7447 +{ +font-family: arial; +} + +.text_class7448 +{ +font-size: 11px; +} + +.text_class7449 +{ +} + +.paragraph_class7450 +{ +} + +.text_class7451 +{ +font-family: arial; +} + +.text_class7452 +{ +font-size: 11px; +} + +.text_class7453 +{ +} + +.paragraph_class7454 +{ +} + +.text_class7455 +{ +font-family: arial; +} + +.text_class7456 +{ +font-size: 11px; +} + +.text_class7457 +{ +} + +.paragraph_class7458 +{ +} + +.text_class7459 +{ +font-family: arial; +} + +.text_class7460 +{ +font-size: 11px; +} + +.text_class7461 +{ +} + +.paragraph_class7462 +{ +} + +.text_class7463 +{ +font-family: arial; +} + +.text_class7464 +{ +font-size: 11px; +} + +.text_class7465 +{ +} + +.paragraph_class7466 +{ +} + +.text_class7467 +{ +font-size: 11px; +font-family: arial; +} + +.text_class7468 +{ +font-family: arial; +} + +.text_class7469 +{ +font-size: 11px; +} + +.text_class7470 +{ +} + +.paragraph_class7471 +{ +} + +.text_class7472 +{ +font-family: arial; +} + +.text_class7473 +{ +font-size: 11px; +} + +.text_class7474 +{ +} + +.paragraph_class7475 +{ +} + +.text_class7476 +{ +font-family: arial; +} + +.text_class7477 +{ +font-size: 11px; +} + +.text_class7478 +{ +} + +.paragraph_class7479 +{ +} + +.text_class7480 +{ +font-family: arial; +} + +.text_class7481 +{ +font-size: 11px; +} + +.text_class7482 +{ +} + +.paragraph_class7483 +{ +} + +.text_class7484 +{ +font-family: arial; +} + +.text_class7485 +{ +font-size: 11px; +} + +.text_class7486 +{ +} + +.text_class7487 +{ +} + +.paragraph_class7488 +{ +} + +.text_class7489 +{ +font-size: 11px; +} + +.text_class7490 +{ +} + +.text_class7491 +{ +} + +.paragraph_class7492 +{ +} + +.text_class7493 +{ +font-size: 11px; +} + +.text_class7494 +{ +} + +.paragraph_class7495 +{ +} + +.text_class7496 +{ +font-size: 11px; +} + +.paragraph_class7497 +{ +} + +.text_class7498 +{ +font-size: 11px; +} + +.paragraph_class7499 +{ +} + +.text_class7500 +{ +font-size: 11px; +} + +.paragraph_class7501 +{ +} + +.text_class7502 +{ +font-size: 11px; +} + +.text_class7503 +{ +} + +.text_class7504 +{ +} + +.paragraph_class7505 +{ +} + +.text_class7506 +{ +font-size: 11px; +} + +.text_class7507 +{ +} + +.text_class7508 +{ +} + +.paragraph_class7509 +{ +} + +.text_class7510 +{ +font-size: 11px; +} + +.text_class7511 +{ +} + +.text_class7512 +{ +} + +.paragraph_class7513 +{ +} + +.text_class7514 +{ +font-size: 11px; +} + +.text_class7515 +{ +} + +.text_class7516 +{ +} + +.text_class7517 +{ +} + +.paragraph_class7518 +{ +} + +.text_class7519 +{ +font-size: 11px; +} + +.text_class7520 +{ +} + +.paragraph_class7521 +{ +} + +.text_class7522 +{ +font-size: 11px; +} + +.text_class7523 +{ +} + +.text_class7524 +{ +} + +.paragraph_class7525 +{ +} + +.text_class7526 +{ +font-size: 11px; +} + +.text_class7527 +{ +} + +.text_class7528 +{ +} + +.paragraph_class7529 +{ +} + +.text_class7530 +{ +font-size: 11px; +} + +.paragraph_class7531 +{ +} + +.text_class7532 +{ +font-size: 11px; +} + +.paragraph_class7533 +{ +} + +.text_class7534 +{ +font-size: 11px; +} + +.paragraph_class7535 +{ +} + +.text_class7536 +{ +font-size: 11px; +} + +.paragraph_class7537 +{ +} + +.text_class7538 +{ +font-size: 11px; +} + +.paragraph_class7539 +{ +} + +.text_class7540 +{ +font-size: 11px; +} + +.paragraph_class7541 +{ +} + +.text_class7542 +{ +} \ No newline at end of file diff --git a/docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm b/docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm new file mode 100755 index 0000000..70dfae8 --- /dev/null +++ b/docs/agl-specs-v1.0/doors-export/d89e7c5f-5b27-4b36-92bd-fab525f5d0ca.htm @@ -0,0 +1 @@ +

AGL Requirements Spec

Project AGL Project

Printed by

July 7, 2016, 10:18:17 AM EDT

.......................................................................................................................

Table of Contents

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.


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


 

 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

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


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.

 




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 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.

 

 


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.

 

・ 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.




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 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.




3.1.7 Role of Home Screen


Table 5-1 describes the role of the Home Screen to satisfy the purpose and use cases mentioned above.


No

Use Case

Role

Description

1-1

Layout

 

GUI Layout 

definition

Function to define a customizable GUI Layout definition.

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 Keyboard

Function to display software keyboard.

3-1

Application

Management

 

Application

Management

Function to download applications from application store. Function to install, uninstall and update the downloaded applications.

3-2

Application Launcher

Function to launch/terminate applications.

4-1

Application

Switch

 

Application List

Function to switch applications by 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.


Table 5-2:  Relevance of the Role and Purpose


No.

Role

Rich UX

Driver Distraction mitigation

Variations support

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

✓

✓

 


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)
  • 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.


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
  • 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.


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.


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. 


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.


Table 7-16 : Role of Resource Control


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 windows

Provide capability to overlay two or more 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 support

Provide capability to use hardware layer efficiently if hardware supports two or more hardware layers.

6

Reduced dependency of hardware

Provide well-defined interface to reduce dependency of hardware. Well-defined interface also makes it possible to increase the effect of portability and development cost.

7

Multi window / multi display

Support multi window management and multi display.

8

Compatibility

From the compatibility point of view, AGL should use public API, and shall not rely on hardware specific API.


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 different 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.


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-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

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 “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


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


Policy Manager is related with the below components.


Table 7-1: Related Components


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-1

Vehicle Info Control

Window Manager

Control screen resource such as show/hide windows.

5-2

Sound Manager

Control sound resource such as mute/unmute sound streams.

5-3

Input Manager

Control input resource such as notify/not notify touch event on touch panel display to applications.

5-4

Vehicle Info Distributor

Provide the vehicle information from vehicle network such as CAN.

5-5

User Manager

Detect user switching. Then Notify the definition of user information such as application list of login user.


(2)  Role


Policy Manager has the below role.


Table 7-2:  Role of Policy Manager


ID

Role

Description

1

External condition

collection

(1) Receives the external conditions.

2

Judgment of priority of GUI resource

(1) Receives the input/output/control request of

 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.




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 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.


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.


Table 7-3:  Definition of Layer Type


No

Type

Summary

Example

1

Basic

This is application’s basic screen. Typically, application requests this layer at first time.

Map of navigation

2

Interrupt

This is application’s popup screen.

Enlarged view of navigation

3

On-screen

This is system popup screen. Typically, On-screen service (e.g. Homescreen) requests this layer.

Warning message popup

4

Software keyboard

This is the software keyboard screen. Typically, software keyboard service requests this layer.

Software keyboard


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.


Table 7-4: Definition of Role


No

Contents

Summary

Example

1

Role

This is screen owner (such as application or service) role.

Navigation

2

Sub role

This is specific screen role.

Enlarged view


Role consists of role and sub role. Role is screen owner role such as “Navigation” and “Software 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.


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.


• 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.


Table 7-5:  Definition of sound type


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 requests this type.

Display touch sound


• 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.




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 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


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.


Policy Manager controls System resources by using “Resource Control” of kernel layer. So, target resources are CPU, memory, storage bandwidth and network bandwidth.


a.  Role


ID

Role

Description

1

External condition

collection

(1) Receives the external conditions.

3

System resource control

  • Issue the System resource control according to external condition change.
  • Kill process(s) forcibly according to external condition change.

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


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

 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

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.

  • 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.
  • 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.

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.

 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.

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.




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


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

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.


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 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)

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)

> 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.


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.


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.


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.


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.

 

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.


Table 7-15 : Role of Resource Control


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 hardware

Provide well-defined interface to reduce dependency of hardware. Well-defined interface also makes it possible to increase the effect of portability and development cost.


4.1.4.2 Requirements


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 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.


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.


By the way, associated input devices are listed below.


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.

Deliver to application or voice recognition engine.


Table 7-14 describes the role of input manager to be satisfied above purpose and use cases.


Table 7-14 : Role of Resource Control


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.


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.

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 Bob is 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


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

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.

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.


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 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


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

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.
  • 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 SQL


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.


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.

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,


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 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 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)


Table 19 : List of HFP supporting functions


 

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 HF

Option

x

9

Place a call using memory dialing

Option

-

10

Place a call to the last number dialed

Option

-

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


*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
  • 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.

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.


Table 20 : List of A2DP Supporting Functions


No.

Feature

Support in SNK

AGL

1

Audio Streaming

Mandatory

x


Table 21 : Supporting Codec


No.

Codec

Support

AGL

1

SBC

Mandatory

x

2

MPEG-1,2 Audio

Option

-

3

MPEG-2,4 AAC

Option

-

4

ATRAC family

Option

-


5.1.1.1.3 Phone Book Access Profile

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.

 

It has to comply with the specification for “Data Terminal (DT)”

 

Items marked with "x" in AGL column in Table 23 should be supported.


Table 23 : List of DUN Supporting Functions


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


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


No.

Feature

Support in Push Server

AGL

1

Object Push

Mandatory

x

2

Business Card Pull

Option

-

3

Business Card Exchange

Option

-


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


Table 25 : List of AVRCP Supporting Functions


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

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 hold

Option

x


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.


Table 26 : List of MAP Supporting Functions


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 Registration

C2

x


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.


Table 27 : List of PAN Supporting Functions


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

4

Lost NAP/GN Service Connection

Mandatory

x

5

Disconnect NAP/GN Service Connection

Mandatory

x

6

Management Information Base (MIB)

-

-


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


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

-

-


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.

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 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 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


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.


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.)
  • 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.


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

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.


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 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.


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


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.

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

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.


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.


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.


Table 29 : List of Wi-Fi Direct Supporting Functions


No.

Feature

 

(Reference)

Support in Wi-Fi Direct

1

P2P Provision Discovery

　

Mandatory

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


5.1.13.2.7 Miracast

It shall comply with Miracast standard.


It shall support the Miracast functions identified in Table 30. 


Table 30 : List of Miracast Supporting Functions


　No.

Feature

　

(Reference)

Support in Miracast

1

WFD Device type

WFD Source

Mandatory

2

　

Primary Sink

Mandatory

3

　

Dual-role possible

Option

4

WFD Service Discovery

　

Option

5

WFD connection establishment with Wi-Fi P2P

Mandatory

6

WFD connection establishment with Wi-Fi TDLS

Option

7

Persistent WFD Group

via Wi-Fi P2P

Option

8

　

via TDLS

Option

9

WFD Capability Negotiation (RTSP)

Mandatory

10

WFD Session Establishment (RTSP)

Mandatory

11

AV Streaming and Control (MPEG-TS/RTP/RTSP)

Mandatory

12

WFD Standby (RTP/RTSP)

Option

13

Video CODEC formats

Option

14

Audio CODEC formats

Option

15

UIBC

Generic

Option

16

 

HIDC

Option


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.


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 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.


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)
  • 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

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:


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

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


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


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


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.

AGL defines following Smartphone link (Miracast) specification as Table 8‑14.


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.1

P2P Topology

Define connection method of P2P (Wi-Fi Direct).

SPL.1.2.2

Wi-Fi Frequency

Define Wi-Fi frequency

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

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.


Table 8-32: State Definition


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.


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.




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 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.
    • 640*480（VGA）　Progressive 60 fps
    • 1280*720（HD）Progressive 30 fps

Regarding Video resolution and Frame rate, other formats are an option.


  • Support follow format for Audio.
    • LPCM 48ksps 16bit 2ch
    • 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 vendor’s own reason.
  • Support both encryption cases if support HDCP function.
    • Case1 Videos data encryption
    • 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.
    • Failed to Wi-Fi connection
    • Failed to establish Miracast session
    • Wi-Fi link loss on Miracast
    • 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 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.


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.

  • 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.


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.


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.


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 and 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.

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

  • 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
  • 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


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.


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.

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.

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.


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.


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.

  • 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.


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 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.


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.

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.


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. 

 

  • Reliabilitymeans 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.
  • Accessibilitymeans ability to use external storage devices, as well as accessing designated parts of internal file system over secure wired or wireless connections.
  • Serviceabilitymeans ability to upgrade AGL as a whole or by updating individual packages, and availability of file system checking and optimization tools.

 

Below is short summary for better understanding of FS Requirements hierarchy.


FS Requirements

R-FS References

  1. File Systems (P1)

6.1. Robust File System for managed internal storage (P1)

6.1.1. Power failure tolerance (P1)

6.1.2. Quick recovery after power loss (P1)

6.1.3. Multi-threaded I/O (P1)

6.1.4. On-demand integrity checker (P1)

6.1.5. Read-only mode (P1)

6.1.6. Non-blocking unmounting (P1)

6.1.7. Means for optimizing I/O performance if it may degrade under certain conditions. (P2)

6.1.8. File space pre-allocation (P2)

6.1.9. Meta-data error detection (P2)

6.1.10. File data error detection (P2)

6.1.11. Online integrity checking (P2)

6.1.12. Write timeout control (P2)

6.1.13. Compression support (P2)

6.1.14. Quota support (P2)

6.1.15. I/O process priority (P2)

6.1.16. File system event notifications (P2)

6.1.17. Logical block size control (P2)

6.1.18. Snapshots (P2)

6.2. File System for non-managed internal storage (P1)

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)

  1. btrfs

2.1. btrfsck

  1. ext2

3.1. e2defrag

  1. ext3
  2. ext4

5.1. e4defrag

5.2. e2fsck

  1. vfat
  2. UBIFS
  3. Generic tools and APIs

8.1. fanotify

8.2. fstrim


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, 


AGL shall provide robust file system suitable for use on non-managed internal storage devices, 


AGL shall provide a set of file systems popular on removable media devices.


A system must be able to withstand power failures under heavy load of meta-data-intensive, and data-intensive operations, including power-failures during OS startup, and shutdown.


A file system must be able to restore good data and meta-data state after unexpected power interruption without performing the full time-consuming integrity check. Such recovery should not add more than a second to the normal boot process after power failure on idle system. Normally this is achieved via journal- or log-based (also known as transactional or copy-on-write) operation.


A file system must be able to handle meta-data-intensive, and data-intensive I/O from multiple threads and/or processes simultaneously.


A file system must have integrity checking tool with ability to execute it on-demand.


A file system must be able to switch between read-only, (when no data is committed to physical storage device), and read/write modes in runtime. E.g. via “mount –o remount,ro <device>” command.


AGL must support “lazy” (delayed) unmounting.


AGL should provide means for optimizing potentially degraded I/O performance after prolonged file system and storage use. Often, this refers to offline or online file system defragmentation. Another example is periodic fstrim execution on SSD storage.


A file system should be able to pre-allocate space for created/extended files on request. This may be used to minimize fragmentation of frequently written files.


A file system should have an option of automatic error detection in its meta-data.


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 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 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.


Table 9-33 : Role of Resource Control


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.


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.


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.


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.

 

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.


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. 

  • Power failure tolerance (P1)
  • Quick recovery after power loss (P1)
  • Multi-threaded I/O (P1)
  • API bindings for C programming language
  • 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.


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.


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.

In applications that need to save data at power down, the programming access time must be fast. (target <1ms/byte)

N.B. EEPROM functionality can be emulated in flash memory passing the requirements above.


7.5.2 Graphics Drivers


Graphics drivers provide the interface to the graphical resources (e.g., GPU) within the system. This may include on-board graphical resources or a separate GPU from the main SOC.


7.5.3 Video Drivers


Video codecs allow the system to decode and/or encode video for playback or recording. Video codecs will nearly always be hardware based.


7.5.3.1 Requirements


The system shall provide device drivers to access any hardware implementation of video functionality. 


7.5.4 Audio Codecs


7.5.4.1 Requirements


Automotive Grade Linux BSPs shall provide devices drivers to access audio codecs that are implemented in hardware. 


Automotive Grade Linux BSPs should provide software implementations for those audio codecs that are required for AGL-based products and not supported in hardware.


7.5.5 Automotive Devices


Device drivers for automotive related devices. This may includes buses such as CAN, MOST,  or LIN. Device drivers may be required for receivers (AM, FM, SDARS, etc). Drivers may also be 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.

AirPlay is a registered trademark of Apple, Inc.

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.

 


 \ No newline at end of file diff --git a/docs/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp b/docs/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp new file mode 100755 index 0000000..3c643f8 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/037f2fd7-4b46-4052-ab2c-bdbf0ec453cc_url_58ac1014-4881-4473-a501-7c65f72b887f.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp b/docs/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp new file mode 100755 index 0000000..78023d1 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/0e8db295-edc3-478a-96b7-a5744b57218b_url_18ac6450-15a9-4f2c-af35-b0a448c4c055.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp b/docs/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp new file mode 100755 index 0000000..5567500 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/10ab2b86-3b44-43b0-bd57-465df06c3be2_url_3366d14a-d26c-41ce-9756-24096b8a067c.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp b/docs/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp new file mode 100755 index 0000000..c2468f8 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/1c8fb581-185f-4b2e-b64f-73d161881e79_url_7c033ecb-0615-4641-97c7-a5815d11aa2d.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp b/docs/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp new file mode 100755 index 0000000..1fdd82a Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/250e200d-0da1-4c7b-ba99-7a8d8573cd33_url_556c24cc-4e53-409c-8093-bd9edf123c20.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp b/docs/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp new file mode 100755 index 0000000..48246db Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/2b64aebc-edd6-4ebd-917c-a21fcf10c028_url_460845f7-d2c9-4008-a57f-06453b5f987a.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp b/docs/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp new file mode 100755 index 0000000..1efdd2a Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/2d7ad221-b09d-4788-af30-d31200fac959_url_037700e6-3f20-4ce2-a692-19521c19c0c1.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp b/docs/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp new file mode 100755 index 0000000..0aabf03 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/3dd010e4-e984-42bb-b387-a1f37dda9c2e_url_5c0e72c4-6c44-4655-b63a-8dc5bf321ba2.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp b/docs/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp new file mode 100755 index 0000000..15830d1 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/3e259145-4707-4648-be0a-0879badb5927_url_b7453432-a03f-44c5-815c-e3f852554ffd.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp b/docs/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp new file mode 100755 index 0000000..fe5496b Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/477b0857-f2b7-4d49-967a-6e48261700ea_url_31d2e990-b099-4e5a-9a6c-14de3816eef7.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp b/docs/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp new file mode 100755 index 0000000..14eb699 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/497627e6-2fb5-4fbc-87aa-33ac3c339473_url_1b432ab1-c604-4f53-963c-713852d7e2d9.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp b/docs/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp new file mode 100755 index 0000000..7cefc5b Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/4e376388-5ef9-4f8d-99dc-7821b1489007_url_1a0bdd0b-75d3-4c36-bd6d-7f0ed32fc986.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp b/docs/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp new file mode 100755 index 0000000..3109ca5 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/59153556-3530-4ad3-bad6-2111bc7b598a_url_27a05136-e643-4190-9920-e2fdd7d87cdd.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp b/docs/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp new file mode 100755 index 0000000..b3cb683 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/6ff21cad-b4e3-4704-9dc9-11b4e34a6bc7_url_ac9557f9-74bd-413d-98c0-d42dd5f05493.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp b/docs/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp new file mode 100755 index 0000000..c87088e Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/74492594-79ed-471f-837f-462aa2c84ee9_url_3d199c49-5ada-4517-9681-83e02544fc68.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp b/docs/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp new file mode 100755 index 0000000..3d60252 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/78679f0a-370c-4808-a87a-34352eb95c3a_url_a0771926-8335-462c-9389-cd7a03275ae3.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp b/docs/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp new file mode 100755 index 0000000..b2c68a9 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/9c8bf58c-d03a-4ec3-a644-79ab711fb199_url_6131e9fd-f412-42ea-ab3b-8b388a06ae85.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp b/docs/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp new file mode 100755 index 0000000..abbd56a Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/a2b5a215-c7c4-4f00-b9b1-6fc1e295824b_url_f6dda64a-3216-4c55-9c8e-49f981e26715.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp b/docs/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp new file mode 100755 index 0000000..0beff83 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/a5155801-56b4-45d1-8efb-51457973a6ba_url_8728e553-96ee-4bdb-9629-ecafc900bcf0.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp b/docs/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp new file mode 100755 index 0000000..162ef6e Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/ce2463c2-25b4-42b7-ae3b-a08b2d82955e_url_5e2be80f-398e-48b2-be80-03d39e4f444f.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp b/docs/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp new file mode 100755 index 0000000..204a8ef Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/d055a169-d7d1-430d-8391-db0cfbb16c78_url_4896313a-e731-4411-a0a8-db3edf10082a.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp b/docs/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp new file mode 100755 index 0000000..e3a1bf3 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/d0656fc8-77ac-4b40-9601-c5857e46a879_url_31eb90ab-c8eb-41af-b5e8-369e049a96dc.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp b/docs/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp new file mode 100755 index 0000000..ca23958 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/d1efc9d4-b3d6-4afe-bea8-8c373cd05776_url_8c9527fd-8165-4b4f-9599-722b52abd35b.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp b/docs/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp new file mode 100755 index 0000000..3fd719f Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/e5243e9c-e39b-45d6-807e-aed3d60fa2a4_url_e34cd7fe-de2d-475d-b9f6-c457fb665666.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp b/docs/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp new file mode 100755 index 0000000..8903a66 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/f4424a8d-6bf8-47d1-b2d6-0b3b0eb9590d_url_d573c6e1-0b7a-41bc-b368-8a1d91e637dc.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp b/docs/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp new file mode 100755 index 0000000..1912c99 Binary files /dev/null and b/docs/agl-specs-v1.0/doors-export/img/f457d71b-dc09-4368-a524-6b0055176f28_url_d2e569d2-0324-403f-85d5-4127dbb47a92.tmp differ diff --git a/docs/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css b/docs/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css new file mode 100755 index 0000000..48203f1 --- /dev/null +++ b/docs/agl-specs-v1.0/doors-export/url_1e0228b9-c588-4778-b1fa-e4310852f526.tmp.css @@ -0,0 +1,491 @@ +body { + font-family:"Arial Unicode MS","sans-serif"; +} + +p.MsoNormal, li.MsoNormal, div.MsoNormal { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin: 0in; + margin-bottom: .0001pt; +} + +h1 { + color: #008A52; + font-size: 14.0pt; + font-weight: bold; + margin-bottom: 12.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 6.0pt; + page-break-after: avoid; +} + +h2 { + color: #222222; + font-size: 12.0pt; + font-weight: normal; + line-height: 12.0pt; + margin-bottom: 12.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 6.0pt; + page-break-after: avoid; +} + +h3 { + color: #222222; + font-size: 10.0pt; + font-weight: bold; + line-height: 12.0pt; + margin: 0in; + margin-bottom: .0001pt; + page-break-after: avoid; +} + +h4 { + color: #666666; + font-size: 9.0pt; + font-weight: bold; + line-height: 12.0pt; + margin-bottom: 12.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 6.0pt; + page-break-after: avoid; +} + +h5 { + color: #222222; + font-size: 11.0pt; + font-weight: normal; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 12.0pt; +} + +h6 { + color: #222222; + font-size: 11.0pt; + font-style: italic; + font-weight: normal; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 12.0pt; +} + +p.MsoHeading7, li.MsoHeading7, div.MsoHeading7 { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 12.0pt; +} + +p.MsoHeading8, li.MsoHeading8, div.MsoHeading8 { + color: #222222; + font-size: 10.0pt; + font-style: italic; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 12.0pt; +} + +p.MsoHeading9, li.MsoHeading9, div.MsoHeading9 { + color: #222222; + font-size: 9.0pt; + font-style: italic; + font-weight: bold; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 12.0pt; +} + +p.MsoToc1, li.MsoToc1, div.MsoToc1 { + color: #007670; + font-size: 14.0pt; + font-weight: bold; + margin-bottom: 6.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 6.0pt; +} + +p.MsoToc2, li.MsoToc2, div.MsoToc2 { + color: #222222; + font-size: 11.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 6.0pt; +} + +p.MsoToc3, li.MsoToc3, div.MsoToc3 { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: .1in; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoToc4, li.MsoToc4, div.MsoToc4 { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: .4in; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoToc5, li.MsoToc5, div.MsoToc5 { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 40.0pt; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoToc6, li.MsoToc6, div.MsoToc6 { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 50.0pt; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoToc7, li.MsoToc7, div.MsoToc7 { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 60.0pt; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoToc8, li.MsoToc8, div.MsoToc8 { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 70.0pt; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoToc9, li.MsoToc9, div.MsoToc9 { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 80.0pt; + margin-right: 0in; + margin-top: 0in; +} + +p.MsoCommentText, li.MsoCommentText, div.MsoCommentText { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin: 0in; + margin-bottom: .0001pt; + mso-style-link: "Comment Text Char"; +} + +p.MsoHeader, li.MsoHeader, div.MsoHeader { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin: 0in; + margin-bottom: .0001pt; +} + +p.MsoFooter, li.MsoFooter, div.MsoFooter { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin: 0in; + margin-bottom: .0001pt; +} + +p.MsoTof, li.MsoTof, div.MsoTof { + color: #008A52; + font-size: 18.0pt; + margin-bottom: .0001pt; + margin-left: 20.0pt; + margin-right: 0in; + margin-top: 0in; + mso-style-link: "Table of Figures Char"; + text-indent: -20.0pt; +} + +p.MsoTitle, li.MsoTitle, div.MsoTitle { + color: #007670; + font-size: 36.0pt; + font-weight: bold; + margin: 0in; + margin-bottom: .0001pt; + text-align: right; +} + +p.MsoBodyText, li.MsoBodyText, div.MsoBodyText { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: .5in; + margin-right: 0in; + margin-top: 0in; + mso-style-link: "Body Text Char"; +} + +p.MsoBodyTextIndent2, li.MsoBodyTextIndent2, div.MsoBodyTextIndent2 { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: .5in; + margin-right: 0in; + margin-top: 0in; +} + +a:link, span.MsoHyperlink { + color: #3087B3; + text-decoration: none; +} + +a:visited, span.MsoHyperlinkFollowed { + color: #3087B3; + text-decoration: none; +} + +p { + color: #222222; + font-size: 12.0pt; + margin-left: 0in; + margin-right: 0in; +} + +p.MsoCommentSubject, li.MsoCommentSubject, div.MsoCommentSubject { + color: #222222; + font-size: 10.0pt; + font-weight: bold; + line-height: 12.0pt; + margin: 0in; + margin-bottom: .0001pt; + mso-style-link: "Comment Subject Char"; +} + +p.MsoAcetate, li.MsoAcetate, div.MsoAcetate { + color: #222222; + font-size: 8.0pt; + margin: 0in; + margin-bottom: .0001pt; + mso-style-link: "Balloon Text Char"; +} + +p.MsoRMPane, li.MsoRMPane, div.MsoRMPane { + color: windowtext; + font-size: 10.0pt; + margin: 0in; + margin-bottom: .0001pt; +} + +p.MsoTocHeading, li.MsoTocHeading, div.MsoTocHeading { + color: #008A52; + font-size: 18.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 12.0pt; + page-break-after: avoid; +} + +p.Tabletext, li.Tabletext, div.Tabletext { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 0in; + mso-style-name: Tabletext; +} + +p.InfoBlue, li.InfoBlue, div.InfoBlue { + color: blue; + font-size: 10.0pt; + font-style: italic; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: .5in; + margin-right: 0in; + margin-top: 0in; + mso-style-name: InfoBlue; +} + +p.Figure, li.Figure, div.Figure { + color: #008A52; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: .0001pt; + margin-left: 28.35pt; + margin-right: 0in; + margin-top: 0in; + mso-style-link: "Figure Char"; + mso-style-name: Figure; + text-indent: -28.35pt; +} + +span.TableofFiguresChar { + color: #008A52; + mso-style-link: "Table of Figures"; + mso-style-name: "Table of Figures Char"; +} + +span.FigureChar { + color: #008A52; + mso-style-link: Figure; + mso-style-name: "Figure Char"; +} + +span.CommentTextChar { + color: #222222; + mso-style-link: "Comment Text"; + mso-style-name: "Comment Text Char"; +} + +span.CommentSubjectChar { + color: #222222; + font-weight: bold; + mso-style-link: "Comment Subject"; + mso-style-name: "Comment Subject Char"; +} + +p.Body2, li.Body2, div.Body2 { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: 78.0pt; + margin-right: 0in; + margin-top: 0in; + mso-style-link: "Body2 Char"; + mso-style-name: Body2; +} + +span.textclass4 { + mso-style-name: text_class4; +} + +span.BodyTextChar { + color: #222222; + mso-style-link: "Body Text"; + mso-style-name: "Body Text Char"; +} + +span.Body2Char { + color: #222222; + mso-style-link: Body2; + mso-style-name: "Body2 Char"; +} + +p.BodyTextBold, li.BodyTextBold, div.BodyTextBold { + color: #222222; + font-size: 10.0pt; + font-weight: bold; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: .5in; + margin-right: 0in; + margin-top: 0in; + mso-style-name: "Body Text Bold"; +} + +p.BodyTextUnderlined, li.BodyTextUnderlined, div.BodyTextUnderlined { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: .5in; + margin-right: 0in; + margin-top: 0in; + mso-style-name: "Body Text Underlined"; + text-decoration: underline; +} + +p.colbody, li.colbody, div.colbody { + color: #222222; + font-size: 9.0pt; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 3.0pt; + mso-style-name: colbody; +} + +p.colheading, li.colheading, div.colheading { + color: #666666; + font-size: 9.0pt; + font-weight: bold; + line-height: 12.0pt; + margin-bottom: 3.0pt; + margin-left: 0in; + margin-right: 0in; + margin-top: 3.0pt; + mso-style-name: colheading; +} + +p.detail, li.detail, div.detail { + color: #222222; + font-size: 10.0pt; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: 70.3pt; + margin-right: 0in; + margin-top: 0in; + mso-style-name: detail; + text-indent: -70.3pt; +} + +p.prompt, li.prompt, div.prompt { + color: #222222; + font-size: 10.0pt; + font-style: italic; + font-weight: bold; + line-height: 12.0pt; + margin-bottom: 6.0pt; + margin-left: 70.3pt; + margin-right: 0in; + margin-top: 0in; + mso-style-name: prompt; + text-indent: -70.3pt; +} + +p.TitleExtras, li.TitleExtras, div.TitleExtras { + color: #222222; + font-size: 16.0pt; + margin: 0in; + margin-bottom: .0001pt; + mso-style-name: "Title Extras"; + text-align: right; +} \ No newline at end of file diff --git a/docs/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png b/docs/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png new file mode 100644 index 0000000..3c643f8 Binary files /dev/null and b/docs/agl-specs-v1.0/media/AGL module_decomposition_diagram v1.0-rc1.pdf.png differ diff --git a/docs/agl-specs-v1.0/media/Image 10.png b/docs/agl-specs-v1.0/media/Image 10.png new file mode 100644 index 0000000..ca23958 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 10.png differ diff --git a/docs/agl-specs-v1.0/media/Image 14.png b/docs/agl-specs-v1.0/media/Image 14.png new file mode 100644 index 0000000..c87088e Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 14.png differ diff --git a/docs/agl-specs-v1.0/media/Image 15.png b/docs/agl-specs-v1.0/media/Image 15.png new file mode 100644 index 0000000..0aabf03 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 15.png differ diff --git a/docs/agl-specs-v1.0/media/Image 16.png b/docs/agl-specs-v1.0/media/Image 16.png new file mode 100644 index 0000000..3fd719f Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 16.png differ diff --git a/docs/agl-specs-v1.0/media/Image 17.png b/docs/agl-specs-v1.0/media/Image 17.png new file mode 100644 index 0000000..c2468f8 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 17.png differ diff --git a/docs/agl-specs-v1.0/media/Image 21.png b/docs/agl-specs-v1.0/media/Image 21.png new file mode 100644 index 0000000..162ef6e Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 21.png differ diff --git a/docs/agl-specs-v1.0/media/Image 22.png b/docs/agl-specs-v1.0/media/Image 22.png new file mode 100644 index 0000000..1efdd2a Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 22.png differ diff --git a/docs/agl-specs-v1.0/media/Image 23.png b/docs/agl-specs-v1.0/media/Image 23.png new file mode 100644 index 0000000..3109ca5 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 23.png differ diff --git a/docs/agl-specs-v1.0/media/Image 24.png b/docs/agl-specs-v1.0/media/Image 24.png new file mode 100644 index 0000000..8903a66 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 24.png differ diff --git a/docs/agl-specs-v1.0/media/Image 25.png b/docs/agl-specs-v1.0/media/Image 25.png new file mode 100644 index 0000000..1fdd82a Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 25.png differ diff --git a/docs/agl-specs-v1.0/media/Image 26.png b/docs/agl-specs-v1.0/media/Image 26.png new file mode 100644 index 0000000..abbd56a Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 26.png differ diff --git a/docs/agl-specs-v1.0/media/Image 27.png b/docs/agl-specs-v1.0/media/Image 27.png new file mode 100644 index 0000000..48246db Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 27.png differ diff --git a/docs/agl-specs-v1.0/media/Image 28.png b/docs/agl-specs-v1.0/media/Image 28.png new file mode 100644 index 0000000..14eb699 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 28.png differ diff --git a/docs/agl-specs-v1.0/media/Image 29.png b/docs/agl-specs-v1.0/media/Image 29.png new file mode 100644 index 0000000..204a8ef Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 29.png differ diff --git a/docs/agl-specs-v1.0/media/Image 30.png b/docs/agl-specs-v1.0/media/Image 30.png new file mode 100644 index 0000000..b3cb683 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 30.png differ diff --git a/docs/agl-specs-v1.0/media/Image 39.png b/docs/agl-specs-v1.0/media/Image 39.png new file mode 100644 index 0000000..1912c99 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 39.png differ diff --git a/docs/agl-specs-v1.0/media/Image 40.png b/docs/agl-specs-v1.0/media/Image 40.png new file mode 100644 index 0000000..0beff83 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 40.png differ diff --git a/docs/agl-specs-v1.0/media/Image 41.png b/docs/agl-specs-v1.0/media/Image 41.png new file mode 100644 index 0000000..b2c68a9 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 41.png differ diff --git a/docs/agl-specs-v1.0/media/Image 60.png b/docs/agl-specs-v1.0/media/Image 60.png new file mode 100644 index 0000000..e3a1bf3 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 60.png differ diff --git a/docs/agl-specs-v1.0/media/Image 8.png b/docs/agl-specs-v1.0/media/Image 8.png new file mode 100644 index 0000000..5567500 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 8.png differ diff --git a/docs/agl-specs-v1.0/media/Image 9.png b/docs/agl-specs-v1.0/media/Image 9.png new file mode 100644 index 0000000..3d60252 Binary files /dev/null and b/docs/agl-specs-v1.0/media/Image 9.png differ diff --git a/docs/agl-specs-v1.0/media/Smartlink State Diagram.png b/docs/agl-specs-v1.0/media/Smartlink State Diagram.png new file mode 100644 index 0000000..fe5496b Binary files /dev/null and b/docs/agl-specs-v1.0/media/Smartlink State Diagram.png differ diff --git a/docs/agl-specs-v1.0/media/picture95.png b/docs/agl-specs-v1.0/media/picture95.png new file mode 100644 index 0000000..5caaae0 Binary files /dev/null and b/docs/agl-specs-v1.0/media/picture95.png differ diff --git a/docs/app-framework/index.md b/docs/app-framework/index.md new file mode 100644 index 0000000..5690fda --- /dev/null +++ b/docs/app-framework/index.md @@ -0,0 +1,86 @@ +# AGL Application Framework + +This page summarizes all materials related to AGL Application Framework + +## Source Code + +The current code of AGL App-Framework is stored on AGL Code Repository. It's divided in the following projects: + +* [src/app-framework-main](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src%2Fapp-framework-main.git;a=summary) Main services +* [src/app-framework-binder](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src%2Fapp-framework-binder.git;a=summary): Binder Daemon +* [src/app-framework-demo](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src%2Fapp-framework-demo.git;a=summary) Demos + +## Building AGL with Application Framework support + +The Application Framework can be added easily to an AGL build using the feature 'agl-appfw-smack'. + +Typically, the following command can be called to initialize AGL build: + + # meta-agl/scripts/aglsetup.sh -m porter agl-appfw-smack agl-demo agl-devel + ... + # bitbake agl-demo-platform + +## Documentation + +Technical documentation is maintained in the source code and should be browsable with the [upcoming AGL documentation system](https://github.com/automotive-grade-linux/docs-agl) + +Temporarily, a static documentation has been made in PDF format: + +* [Introduction to Application Framework](http://iot.bzh/download/public/2016/appfw/01_Introduction-to-AppFW-for-AGL-1.0.pdf) +* [AppFW Core Documentation](http://iot.bzh/download/public/2016/appfw/02_Documentation-AppFW-Core-2.0.pdf) +* [Privileges Management](http://iot.bzh/download/public/2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) + +Some extra guides are also available in PDF format: + +* [Build your 1st AGL Application](http://iot.bzh/download/public/2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf) +* Applications Templates are available on [github:iotbzh/app-framework-templates](https://github.com/iotbzh/app-framework-templates) + +### Bindings Examples + +Some bindings are available to quickstart new projects: + +* GPS - see [github:iotbzh/af-gps-binding](https://github.com/iotbzh/af-gps-binding/blob/master/src/af-gps-binding.c) +* OpenXC Reader - see [github:iotbzh/txc-demo](https://github.com/iotbzh/txc-demo/blob/master/binding/txc-binding.c) +* CPU/Memory stats - see [github:iotbzh/txc-demo](https://github.com/iotbzh/txc-demo/blob/master/binding/stat-binding.c) +* Radio - see [gerrit:src/app-framework-binder](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-binder.git;a=tree;f=bindings/radio;hb=master) +* Audio - see [gerrit:src/app-framework-binder](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-binder.git;a=tree;f=bindings/audio;hb=master) + +The list is not exhaustive. ***Please add other bindings here !*** + +### Demos + +* Simple HTML5 Demos apps (ported from Tizen) on [github:iotbzh/afm-widget-examples](https://github.com/iotbzh/afm-widget-examples) +* Installable package with [TXC Demo Application](http://iot.bzh/download/public/2016/afb-demos/txc-demo_0.1.wgt) +* Applications available in [gerrit:app-framework-demo](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-demo.git;a=summary) + +## Presentations + +* Oct 16 - [Application Security Model - Status Update](http://iot.bzh/download/public/2016/genivi/CyberSecurity-Genivi-Q42016-Fulup-IoTbzh.pdf) +* Sept 16 - [Building Applications with AGL Framework](http://iot.bzh/download/public/2016/genivi/CyberSecurity-Genivi-Q42016-Fulup-IoTbzh.pdf) - Also visible in [PDF version](http://iot.bzh/download/public/2016/publications/build-agl-application-AMM-Munich-2016.pdf) +* Feb 16 - [HTML5 Apps for Automotive Systems](http://iot.bzh/download/public/2016/publications/HTML5_Applications_for_Automotive_Systems.pdf) +* Feb 16 - [Application & Security Framework Proposal AGL 2.0](http://iot.bzh/download/public/2016/security/Security-Proposal-AGL20-Fulup.pdf) +* Jan 16 - [Security Architecture Proposal](http://iot.bzh/download/public/2016/security/Security-Architecture-AGL20.pdf) + +## History + +### Motivation for rewriting the App. Framework + +To get the background and motivation on why Application Framework has been rewritten: + +* [Tizen Security: lessons learnt](http://iot.bzh/download/public/2015/tizen-security-lessons-learnt-initial.pdf) +* [this discussion](https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-October/002749.html) +* [Linux Automotive Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf) + +### Comparison/Relationship with Tizen + + Tizen AGL + ---------------------------------- + App/OS isolation yes yes + Container option no possible + Native App partial* yes + HTML5 App yes yes + Cloud App No yes + Unified API (HTLM/Native) No yes + service as App** No yes + Adding API *** core core or App + Devel model bespoke Standard Web diff --git a/docs/audio/4a-framework.md b/docs/audio/4a-framework.md new file mode 100644 index 0000000..d54f12b --- /dev/null +++ b/docs/audio/4a-framework.md @@ -0,0 +1,6 @@ +# AGL Audio High Level Binding (4A) + +The Audio High Level Binding is the upper layer in the Audio 4A architecture. + +Presentation is available: +[4a-presentation-by-audiokinetics](https://schd.ws/hosted_files/aglammeu17/aa/HighLevelAudio_DresdenAMM_Final_0.pdf) diff --git a/docs/audio/bluez-alsa.md b/docs/audio/bluez-alsa.md new file mode 100644 index 0000000..bbdef77 --- /dev/null +++ b/docs/audio/bluez-alsa.md @@ -0,0 +1,113 @@ +# bluez-alsa + +## Introduction + +Bluetooth Audio ALSA Backend allow bluetooth audio without PulseAudio. + +This project is a rebirth of a direct integration between Bluez and ALSA. Since Bluez >= 5, the build-in integration has been removed in favor of 3rd party audio applications. From now on, Bluez acts as a middleware between an audio application, which implements Bluetooth audio profile, and a Bluetooth audio device. + +github source : [bluez-alsa](https://github.com/Arkq/bluez-alsa) + +## Add bluez-alsa to an AGL image + +You can add bluez-alsa to your image + +```yocto +IMAGE_INSTALL_append = "bluez-alsa" +``` + +## Check bluez-alsa status + +You can check the bluez-alsa status by running: + +```bash +systemctl status bluez-alsa.service +``` + +## Stop pulseaudio + +You must disable pulseaudio if you want to use bluez-alsa + +```bash +systemctl --user stop pulseaudio +``` + +or disable pulseaudio bluetooth support + +```bash +vi /etc/pulse/default.pa +#.ifexists module-bluetooth-policy.so +#load-module module-bluetooth-policy +#.endif + +#.ifexists module-bluetooth-discover.so +#load-module module-bluetooth-discover +#.endif +``` + +## Connect your Bluetooth device + +You need to connect a bluetooth device + +```bash +$ bluetoothctl +[bluetooth]# pair ${BT_ADDR} +[bluetooth]# connect ${BT_ADDR} +[bluetooth]# info ${BT_ADDR} +``` + +Here somes documentation links: + +* [Bluetooth headset from archlinux](https://wiki.archlinux.org/index.php/Bluetooth_headset) +* [Bluetooth Headset from gentoo](https://wiki.gentoo.org/wiki/Bluetooth_Headset) +* [Bluez A2DP AudioSink for ALSA](http://www.lightofdawn.org/blog/?viewDetailed=00032) +* [Bluez A2DP](http://www.lightofdawn.org/wiki/wiki.cgi/BluezA2DP) + +## Test bluez-alsa speacker + +```bash +wget http://www.kozco.com/tech/piano2.wav + +aplay -D bluealsa:HCI=hci0,DEV=${BT_ADDR},PROFILE=a2dp ./piano2.wav +``` + +## Add bluez-alsa pcm config to alsa + +```bash +vi /etc/asound.conf +# Bluetooth headset +pcm.btheadset { + type plug + slave.pcm { + type bluealsa + device "${BT_ADDR}" + profile "a2dp" + } + hint { + show on + description "Bluetooth Audio ALSA Backend" + } +} +``` + +Doc [asoundrc](https://alsa.opensrc.org/Asoundrc) + +Test bluez-alsa pcm + +```bash +aplay -D btheadset ./piano2.wav +``` + +## Test gstreamer player + +```bash +gst-launch-1.0 uridecodebin uri=file:///mnt/Holy-Mountain.mp3 ! alsasink device=btheadset +``` + +## Test bluez-alsa phone + +After connected your phone with bluez: + +```bash +bluealsa-aplay ${BT_ADDR} +``` diff --git a/docs/getting-started/customize_bitbake_conf.md b/docs/getting-started/customize_bitbake_conf.md new file mode 100644 index 0000000..fa466ca --- /dev/null +++ b/docs/getting-started/customize_bitbake_conf.md @@ -0,0 +1,53 @@ +# Customize AGL build + +To customize the AGL build, you edit local.conf file, located in the build/conf directory. + +```bash +edit $AGL_TOP/build/conf/local.conf +``` + +## Buildhistory + +The OpenEmbedded build system creates this directory when you enable the build history feature. + +```bash +INHERIT += "buildhistory" +BUILDHISTORY_COMMIT = "1" +``` + +For more information please check [Here][buildhistory] + +## Deletion of temporary workspace + +Removes work files after the OpenEmbedded build system has finished with them. + +```bash +INHERIT += "rm_work" +``` + +For more information please check [Here][rm_work] + +## Share sstate cache + +The directory for the shared state cache. + +```bash +SSTATE_DIR = "${HOME}/workspace_agl/sstate-cache" +``` + +For more information please check [Here][share_sstatecache] + +## Share Download directory + +The central download directory used by the build process to store downloads. + +```bash +DL_DIR = "${HOME}/workspace_agl/downloads" +``` + +For more information please check [Here][share_download] + +[buildhistory]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-build-output-quality +[rm_work]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-tasks-rm_work +[share_sstatecache]: https://wiki.yoctoproject.org/wiki/Enable_sstate_cache +[share_download]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DL_DIR diff --git a/docs/getting-started/footers/intel-footer.md b/docs/getting-started/footers/intel-footer.md new file mode 100644 index 0000000..967feb4 --- /dev/null +++ b/docs/getting-started/footers/intel-footer.md @@ -0,0 +1,90 @@ +## BIOS update + +Both Joule and MinnowBoard-Max (not needed on Turbo) require a BIOS upgrade before running AGL on them. + +**Do not loose any time trying without upgrading your BIOS first.** + +For instructions on how to update the BIOS on those platforms, please refer to these documents: +* [MinnowBoard](https://firmware.intel.com/projects/minnowboard-max) +* [Intel Joule](https://software.intel.com/en-us/flashing-the-bios-on-joule) +* Intel MRB contact your technical support representative to get the non signed ABL firmware
+**Note** MRB users need to replace the mkefi-agl.sh script by mkabl-agl.sh + +## Creating a bootable image + +Multiple options are avaiable but `dd` and `tar` can very easily let you down due to the requirement to pass SMACK labels, create a proper UEFI configuration and a few other tricks. +The script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) has been done to help you. +The option -h will print the help and the option -v will detail the operation and ease any debug. + +## Installing your image on the internal eMMC + +It can be interesting to install the AGL image directly on the internal eMMC rather than to boot from and SD or a USB removable device. +The easiest to do so, is to add the required tools in your removable boot device, boot AGL from the removable device and +then use the mkefi-agl.sh script to install the image image on the internal eMMC. + * Add the tools to the AGL image. + ** Add a file site.conf in your build/conf directory with the following content: + ``` + INHERIT += "rm_work" + IMAGE_INSTALL_append = " linux-firmware-iwlwifi-7265d" + IMAGE_INSTALL_append = " parted e2fsprogs dosfstools" + IMAGE_INSTALL_append = " linux-firmware-i915 linux-firmware-ibt linux-firmware-iwlwifi-8000c" + add the iwlifi for your own device as needed + ``` + * rebuild your image and install it on your removable device with mkefi-agl.sh. + * add the AGL image file on your removable device in the home directory (for later installation) + ``` + the AGL image file created by yocto (.wic.xz) + located in build/tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic.xz + ``` + * boot AGL from your removable device + * connect to the AGL running image either via serial link or ssh + * locate the eMMC device name + * install image with mkefi-agl.sh + ``` + cat /proc/partitions + ``` + * install the AGL image on the eMMC with mkefi-agl.sh script + * remove the USB or SD boot device + * reboot + +## Selecting the SD or USB to boot + +When booting a MinnowBoard or a Joule you can change the default boot device by hitting F2 during initial UEFI boot. +It's easier to achieve it in the right time with a USB keyboard than via serial link. +During boot USB hubs are not supported, you need to connect the keyboard directly in the USB socket. +It's also preferable to use F9 and to change the boot order once for all. +Please note: You can only change the boot order when a valid device is inserted in the corresponding port (USB or SD). + +The MinnowBoard, Joule, many laptops and NUCs will not accept to boot with some USB3 sticks. If you have some trouble to get your USB3 stick detected during boot, swap it for a USB2. In any case working with SD card is faster to flash and to boot. SD should be preferred. +The Joule seems to refuse to boot with my SD-HC-I type cards while I had no problem with the MinnowBoard. If you work with a Joule, use regular SD-HC (mode 4 and 10 work fine). + +## Serial debug Port + +Serial debug port ID varies with the HW platform. By default AGL build Intel target as a MinnowBoard where serial is `/dev/ttyS0`, on Joule and MRB the serial debug is `/dev/ttyS2`. +On Up boards the /dev/ttyS0 serial port is not easy to access and using /dev/ttyS4 which is routed on the Arduino connector.
[See pinout]( http://www.up-board.org/wp-content/uploads/2017/11/UP-Square-DatasheetV0.5.pdf) + +You may have to change the configuration in your bootloader which is located in the EFI partition. + +## Serial debug cable + +On the MinnowBoard the serial cable is an FTDI serial cable. The wiring can be found [here](http://wiki.minnowboard.org/MinnowBoard_MAX_HW_Setup).
+Up Boards use the same FDDI 3.3V adaptor than the Minnow but the pin out is not adjacent and requires to split the pins. +On the Joule the serial connection is done via the micro USB cable which is not provided in the Developer kit. Details can be found [here](https://software.intel.com/en-us/node/667851). +Interface speed is 115200 bps, 8 bits, no parity, no flow control + +## Which port name is used to define the connected display(s) + +Port naming may change with HW platforms and connected display. The simplest is to check following the first boot, in the systemd journal, which display names are listed. + +```bash +journalctl |grep Output +``` + +**Note:** The Output information is only listed if a real Display is connected to the connector on the board. +The file holding that configuration is `/etc/xdg/weston/weston.ini`. + +Common Display names for Intel are: + +* `HDMI-A-1` +* `HDMI-A-2` +* `LVDS-1` diff --git a/docs/getting-started/footers/porter-footer.md b/docs/getting-started/footers/porter-footer.md new file mode 100644 index 0000000..7d1417d --- /dev/null +++ b/docs/getting-started/footers/porter-footer.md @@ -0,0 +1,23 @@ +## Weston + +If Weston fails to start double check : +``/etc/xdg/weston/weston.ini`` +and verify that the output name and screen resolution matches the configured U-Boot environment. +For example on Renesas Porter board rev 1.0 with screen resolution 1024x768: + +```bash +[core] +shell=desktop-shell.so +backend=drm-backend.so + +[shell] +locking=true +# Uncomment below to hide panel +#panel-location=none + +[output] +name=HDMI-A-1 +mode=1024x768 +#mode=1920x1080 +#mode=173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync +``` diff --git a/docs/getting-started/footers/raspberrypi-footer.md b/docs/getting-started/footers/raspberrypi-footer.md new file mode 100644 index 0000000..f5ff16f --- /dev/null +++ b/docs/getting-started/footers/raspberrypi-footer.md @@ -0,0 +1,56 @@ +# Commercial Licensed Packages + +Append to following lines to **conf/local.conf** to include libomxil under a commercial license to your build: + +```bash +# For libomxil +LICENSE_FLAGS_WHITELIST = "commercial" + +IMAGE_INSTALL_append = " libomxil" +``` + +# Raspberry Pi Touchscreen with Rotation + +If you have Raspberry Pi official 7" touchscreen connected, you can rotate it with these lines in /etc/xdg/weston/weston.ini + +```bash +root@raspberrypi3:/etc/xdg/weston# cat weston.ini +[core] +backend=drm-backend.so +shell=desktop-shell.so + +[shell] +locking=true +# Uncomment below to hide panel +#panel-location=none + +[launcher] +icon=/usr/share/weston/terminal.png +path=/usr/bin/weston-terminal + +[launcher] +icon=/usr/share/weston/icon_flower.png +path=/usr/bin/weston-flower + +[output] +name=DSI-1 +transform=270 +``` + +# Debugging + +It is possible to debug AGL images on Raspberry Pi using 3.3V USB to serial cable, such as [Olimex USB-Serial-Cable-F](https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/), connected to the UART of the board. Follow the instructions below to connect a cable to the board (do it on your own risk, no warranty is provided): + +* Connect the BLUE wire if you are using Olimex USB-Serial-Cable-F to pin 6 of Raspberry Pi, +* Connect the RX line of the cable (GREEN wire if you are using Olimex USB-Serial-Cable-F) to pin 8 (TX line) of Raspberry Pi, +* Connect the TX line of the cable (RED wire if you are using Olimex USB-Serial-Cable-F) to pin 10 (RX line) of Raspberry Pi. + +![Olimex USB-Serial-Cable-F attached to Raspberry PI 2 for debugging through the serial console](images/RaspberryPi2-ModelB-debug-serial-cable.jpg) + +* Plug the USB connector of the cable to your computer and use your favorite tool for serial communication, for example on Ubuntu and other Linux distributions you may use screen: + +```bash +sudo screen /dev/ttyUSB0 115200 +``` + +Pay attention that the colors of the cable may vary depending on the vendor. If you have USB console cable from Adafruit please have a look [here](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead). diff --git a/docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg b/docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg new file mode 100644 index 0000000..e8026d6 Binary files /dev/null and b/docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg differ diff --git a/docs/getting-started/machines/R-Car-Starter-Kit-gen3.md b/docs/getting-started/machines/R-Car-Starter-Kit-gen3.md new file mode 100644 index 0000000..68a3798 --- /dev/null +++ b/docs/getting-started/machines/R-Car-Starter-Kit-gen3.md @@ -0,0 +1,633 @@ +# AGL Kickstart on Renesas R-Car Starter Kit Gen3 (h3ulcb, m3ulcb, salvator-x(optional)) + +## Prerequisites + +* At this step, you are assumed to have downloaded the [AGL source code](/docs/getting_started/en/dev/reference/source-code.html). + +See the related paragraph if not done yet. + +* For creating the microSD card, you will need **bmaptool** + +There are pre-built packages (.deb or .rpm) for the supported host OSes, available at [this location]( +https://build.opensuse.org/package/show/isv:LinuxAutomotive:AGL_Master/bmap-tools) + +## Hardware + +Here is a non exhaustive list of hardware parts that could be used to setup the R-Car Starter Kit Gen3 board development environment: + +* Starter Kit Gen3 board with its 5V power supply +* micro USB-A cable for serial console (optional if using ethernet and ssh connection) +* USB 2.0 Hub (optional) +* Ethernet cable (optional if using serial console) +* HDMI type D (Micro connector) cable and associated display +* micro-SD Card (at least 4GB) and recommend to use class 10 type. +* USB touch screen device like the GeChic 1502i/1503i (optional) + +For more information and latest news, please check : + +* [elinux page for h3ulcb][R-car h3ulcb] +* [elinux page for m3ulcb][R-car m3ulcb] +* [elinux page for salvator-x][R-car salvator-x] + +Infotainment Carrier Board : + +* [elinux page for Kingfisher][R-car Kingfisher] + +**Note**:That the Salvator-X has NDA restrictions, so less documentation is available both here and elsewhere. + +The following documents may also be helpful: + +* [Yocto-Gen3 on elinux][R-car yocto] + +## BSP Version of R-Car Starter Kit Gen3 + +| AGL Version| Renesas version | +|:-:|:-:| +| AGL master | 3.9.0 | +| AGL 6.0.0 | 3.7.0 | +| AGL 5.0.x, 5.1.0| 2.23.1 | +| AGL 4.0.x |2.19.0 | + +## Building the AGL Demo Platform for R-Car Starter Kit Gen3 + +Before setting up the build environment, you need to download the proprietary drivers. + +* The version of the drivers you need can be displayed this way: + +```bash +grep -rn ZIP_.= $AGL_TOP/meta-agl/meta-agl-bsp/meta-rcar-gen3/scripts/setup_mm_packages.sh +``` + +* Download Renesas graphics drivers with a "click through" license from [Renesas website][rcar Linux Drivers 2] + * Under the Target hardware: **R-Car H3/M3** section. + +**Note**: + +* You have to register with a free account on MyRenesas and accept the license conditions before downloading the drivers. + The operation is fast and simple nevertheless mandatory to access evaluation of non open-source drivers for free. + Once you registered, you can download two zip files. +* It is recommended to store these drivers into your download directory (usually $HOME/Downloads, pointed by $XDG_DOWNLOAD_DIR in some OS). + * To avoid any errors, check that $XDG_DOWNLOAD_DIR is set to the directory where the drivers are stored, if not, set it using 'export' command +* Be sure to have the need rights for these files using : + +```bash +chmod a+r $XDG_DOWNLOAD_DIR/*.zip +``` + +* Check that the needed drivers files are found using : + +```bash +ls -1 $XDG_DOWNLOAD_DIR +[master] +-rw-r--r--. 1 1664 agl-sdk 5.0M Jun 28 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180627.zip +-rw-r--r--. 1 1664 agl-sdk 3,1M Jun 28 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180627.zip + +[Flounder] +-rw-r--r--. 1 1664 agl-sdk 4.9M Apr 24 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip +-rw-r--r--. 1 1664 agl-sdk 3,0M Apr 24 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip + +[Eel] +-rw-r--r--. 1 1664 agl-sdk 4.5M Dec 8 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip +-rw-r--r--. 1 1664 agl-sdk 3,0M Dec 8 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip +``` + +### Setting up the build environment + +Define the type of R-Car Starter Kit board as a variable: + +* for machine **h3ulcb** (Starter Kit Premier/H3) : + +```bash +export MACHINE=h3ulcb +``` + +* for machine **m3ulcb** (Starter Kit Pro/M3): + +```bash +export MACHINE=m3ulcb +``` + +* for machine **h3-salvator-x**: + +```bash +export MACHINE=h3-salvator-x +``` + +Now, init your build environment: + +```bash +cd $AGL_TOP +source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo agl-netboot agl-appfw-smack agl-localdev +``` + +**IMPORTANT NOTE**: Read the log to be sure you had no error during your setup. + +In case of missing graphics drivers, you could notice an error message as follow: + +```bash +[snip] +--- fragment /home/working/workspace_agl_master/meta-agl/templates/machine/h3ulcb/50_setup.sh +/home/working/workspace_agl_master /home/working/workspace_agl_master/build_gen3 +The graphics and multimedia acceleration packages for +the R-Car Gen3 board can be downloaded from: + https://www.renesas.com/en-us/solutions/automotive/rcar-demoboard-2.html + +These 2 files from there should be store in your'/home/devel/Downloads' directory. + R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip + R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip +/home/working/workspace_agl_master/build_gen3 +--- fragment /home/working/workspace_agl_master/meta-agl/templates/base/99_setup_EULAconf.sh +--- end of setup script +OK +Generating setup file: /home/working/workspace_agl_master/build_gen3/agl-init-build-env ... OK +------------ aglsetup.sh: Done +[snip] +``` + +If you encounter this issue, or any other unwanted behavior, you can fix the error mentioned and then clean up by removing the “$AGL_TOP/build” directory then re-launch the procedure again. + +In any case, you can find out more information for the reason of the error in this file: + +```bash +[snip] + +~/workspace_agl/build/conf $ cat setup.log +--- beginning of setup script +--- fragment /home/thierry/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh +--- fragment /home/thierry/workspace_agl/meta-agl/templates/machine/m3ulcb/50_setup.sh +~/workspace_agl ~/workspace_agl/build +ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip+" NOT EXTRACTING CORRECTLY +ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip+" NOT EXTRACTING CORRECTLY +The graphics and multimedia acceleration packages for +the R-Car Gen3 board BSP can be downloaded from: + + +These 2 files from there should be stored in your +'/home/thierry/Downloads' directory. + R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip + R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip +ERROR: Script /home/thierry/workspace_agl/build/conf/setup.sh failed +[snip] +``` + +After this command, the working directory is changed to $AGL_TOP/build. + +If you do not want do this, another option is to add the '**-f**' option to agl_setup.sh. + +Users may want to check that the board is correctly selected in the environment: + +```bash +grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf + MACHINE = "h3ulcb" +or + MACHINE = "m3ulcb" +or + MACHINE = "h3-salvator-x" +``` + +Configure for Release or Development: + +* development images contain extra tools for developer convenience, in particular: + * a debugger (gdb) + * some tweaks, including a disabled root password + * a SFTP server + * the TCF Agent for easier application deployment and remote debugging + * some extra system tools (usb, bluetooth ...) + * ... + +We explicitely activate these debug facilities by specifying the “agl-devel agl-netboot” feature. + +### Build your image + +The process to build an image is simple: + +```bash +bitbake agl-demo-platform +``` + +You may need to install rpcgen to run this command. + +When finished (it may take few hours), you should get the final result: + +```bash +ls -l $AGL_TOP/build/tmp/deploy/images/$MACHINE +``` + +**Note**: + +In case of failure of the build it is safe to first check that the Linux distribution chosen for your host has been validated for the current version of Yocto used by AGL. + +## Booting AGL Image on R-Car Starter Kit Gen3 boards using a microSD card + +To boot the board using a micro-SD card, there are two operations that must be done prior to first initial boot: + +* Update all firmware on the device. +* Set up the board to boot on the SD-card. + +For each subsequent build you only need to rewrite the SD-card with the new image. + +### Firmware Update + +This proceedure is done in two steps. The 'Sample Loader and MiniMonitor update' step only needs to be done once per device. The 'Firmware stack update' step is mandatory only if you use AGl Eel (version 5.0) or later. + +#### Sample Loader and MiniMonitor update + +Follow the documentation on the [eLinux.org wiki][R-car loader update] to update to at least version 3.02. This is mandatory to run AGL. + +#### Firmware stack update + +As an AArch64 platform, both **h3ulcb** and **m3ulcb** have a firmware stack divided in : **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. + +If you use AGl Eel (version 5.0) or later, you must update the firmware using the following links to eLinux.org wiki: **[h3ulcb][R-car h3ulcb firmware update]** or **[m3ulcb][R-car m3ulcb firmware update]**. + +The files listed in the eLinux.org wiki table will be found in the directory: + +```bash +*\$AGL_TOP/build/tmp/deploy/images/$MACHINE* +``` + +The Salvator-X firmware update process is not documented on eLinux. + +### Prepare the SD-card on the host + +Plug the microSD card and get its associated device by either running *`dmesg | tail -15`* or *`lsblk`*, for example: + +```bash +dmesg | tail -15 + + [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 + [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found + [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through + [ 1971.463870] sdc: sdc1 sdc2 +``` + +Here, the SD-card is attached to the device /dev/sdc. + +```bash +lsblk + + NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT + sda 8:0 0 167,7G 0 disk + ├─sda1 8:1 0 512M 0 part /boot/efi + ├─sda2 8:2 0 159,3G 0 part / + └─sda3 8:3 0 7,9G 0 part [SWAP] + sdb 8:16 0 931,5G 0 disk + └─sdb1 8:17 0 931,5G 0 part /media/storage + sdc 8:32 1 14,9G 0 disk + ├─sdc1 8:33 1 40M 0 part + └─sdc2 8:34 1 788M 0 part +``` + +**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time: +so you should repeat this operation each time you insert the microSD card to confirm the device name. + +In the example above, we see: + +* the first SATA drive as 'sda'. +* 'sdc' corresponds to the microSD card, and is also marked as removable device by *lsblk* which is a good confirmation. +* Your desktop system probably offers a choice to mount the SD-card automatically in some directory. +* In the next sample code, we'll suppose that the SD-card mount directory is stored in the variable $SDCARD. +* For example, if the microSD card is associated with device *sdc*: + +Go to your build directory: + +```bash +cd $AGL_TOP/build/tmp/deploy/images/$MACHINE +``` + +You can use bmaptool to copy the **.wic.xz** file to the storage device, discovered in the previous step: + +```bash +bmaptool copy ./agl-demo-platform-$MACHINE.wic.xz $SDCARD +``` + +Or you can be uncompressed and written to the device: + +```bash + sudo umount /dev/sdc + xzcat ./agl-demo-platform-$MACHINE.wic.xz | sudo dd of=$SDCARD bs=4M + sync +``` + +### Booting the board + +* Turn the board off using the power switch. +* Insert the microSD-card. +* Verify that you have plugged in, at least : + * An external monitor on HDMI port + * An input device (keyboard, mouse, touchscreen...) on USB port. + +* Turn the board on using the power switch. + After a few seconds, you'll see the AGL splash screen on the display and you'll be able to log in on the console terminal or in the graphic screen. + +## Serial Console Setup + +### Install a serial client on your computer + +This can be “screen”, “picocom”, “minicom”. +The lighter of the 3 is “picocom” (it has less dependencies). + +### Plug a USB cable from your computer to the serial CP2102 USB port (micro USB-A) + +With “dmesg” you can check the device created for the serial link. +Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host. +To get it, you must switch the board on. +For example: + +```bash +dmesg | tail +[2097783.287091] usb 2-1.5.3: new full-speed USB device number 24 using ehci-pci +[2097783.385857] usb 2-1.5.3: New USB device found, idVendor=0403, idProduct=6001 +[2097783.385862] usb 2-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[2097783.385864] usb 2-1.5.3: Product: FT232R USB UART +[2097783.385866] usb 2-1.5.3: Manufacturer: FTDI +[2097783.385867] usb 2-1.5.3: SerialNumber: AK04WWCE +[2097783.388288] ftdi_sio 2-1.5.3:1.0: FTDI USB Serial Device converter detected +[2097783.388330] usb 2-1.5.3: Detected FT232RL +[2097783.388658] usb 2-1.5.3: FTDI USB Serial Device converter now attached to ttyUSB0 +``` + +The link is attached to the device /dev/ttyUSB0. +It is time to launch your serial client. +Example: + +```bash +picocom -b 115200 /dev/ttyUSB0 +``` + +or + +```bash +minicom -b 115200 -D /dev/ttyUSB0 +``` + +or + +```bash +screen /dev/ttyUSB0 115200 +``` + +### Power on the board to see a shell on the console + +* For machine h3ulcb: + +```bash +NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 +NOTICE: BL2: PRR is R-Car H3 ES1.1 +NOTICE: BL2: LCM state is CM +NOTICE: BL2: DDR1600(rev.0.15) +NOTICE: BL2: DRAM Split is 4ch +NOTICE: BL2: QoS is Gfx Oriented(rev.0.30) +NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 +NOTICE: BL2: Lossy Decomp areas +NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 +NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 +NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 +NOTICE: BL2: v1.1(release):41099f4 +NOTICE: BL2: Built : 19:20:52, Jun 9 2016 +NOTICE: BL2: Normal boot +NOTICE: BL2: dst=0xe63150c8 src=0x8180000 len=36(0x24) +NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=3072(0xc00) +NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) +NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) +NOTICE: BL2: dst=0x49000000 src=0x8640000 len=1048576(0x100000) + + +U-Boot 2015.04 (Jun 09 2016 - 19:21:52) + +CPU: Renesas Electronics R8A7795 rev 1.1 +Board: H3ULCB +I2C: ready +DRAM: 3.9 GiB +MMC: sh-sdhi: 0, sh-sdhi: 1 +In: serial +Out: serial +Err: serial +Net: Board Net Initialization Failed +No ethernet found. +Hit any key to stop autoboot: 0 +=> +``` + +* For machine m3ulcb: + +``` +NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 +NOTICE: BL2: PRR is R-Car M3 Ver1.0 +NOTICE: BL2: Board is Starter Kit Rev1.0 +NOTICE: BL2: Boot device is HyperFlash(80MHz) +NOTICE: BL2: LCM state is CM +NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 +NOTICE: BL2: DDR1600(rev.0.22)NOTICE: [COLD_BOOT]NOTICE: ..0 +NOTICE: BL2: DRAM Split is 2ch +NOTICE: BL2: QoS is default setting(rev.0.17) +NOTICE: BL2: Lossy Decomp areas +NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 +NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 +NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 +NOTICE: BL2: v1.3(release):4eef9a2 +NOTICE: BL2: Built : 00:25:19, Aug 25 2017 +NOTICE: BL2: Normal boot +NOTICE: BL2: dst=0xe631e188 src=0x8180000 len=512(0x200) +NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) +NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) +NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) +NOTICE: BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000) + + +U-Boot 2015.04-dirty (Aug 25 2017 - 10:55:49) + +CPU: Renesas Electronics R8A7796 rev 1.0 +Board: M3ULCB +I2C: ready +DRAM: 1.9 GiB +MMC: sh-sdhi: 0, sh-sdhi: 1 +In: serial +Out: serial +Err: serial +Net: ravb +Hit any key to stop autoboot: 0 +=> +``` + +### Configure U-boot parameters + +Follow the steps below to configure the boot from microSD card and to set screen resolution: + +* Turn the board on using the power switch. +* Hit any key to stop autoboot (warning you have only few seconds). +* Type **printenv** to check if you have correct parameters for booting your board: + * Example for a h3ulcb: + + ``` + => printenv + baudrate=115200 + bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 + bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 + bootdelay=3 + fdt_high=0xffffffffffffffff + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb + load_ker=ext4load mmc 0:1 0x48080000 /boot/Image + stderr=serial + stdin=serial + stdout=serial + ver=U-Boot 2015.04 (Jun 09 2016 - 19:21:52) + + Environment size: 648/131068 bytes + ``` + + * Example for a m3ulcb: + + ``` + => printenv + baudrate=115200 + bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 + bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 + bootdelay=3 + fdt_high=0xffffffffffffffff + filesize=cdeb + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb + load_ker=ext4load mmc 0:1 0x48080000 /boot/Image + stderr=serial + stdin=serial + stdout=serial + ver=U-Boot 2015.04 (Nov 30 2016 - 18:25:18) + + Environment size: 557/131068 bytes + ``` + + * To boot on a sd card, it is recommended to set your environment using these commands : + + ``` + setenv bootargs console=ttySC0,115200 ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2 + setenv bootcmd run load_ker\; run load_dtb\; booti 0x48080000 - 0x48000000 + setenv load_ker ext4load mmc 0:1 0x48080000 /boot/Image + ``` + + * For machine h3ulcb (BSP >= 2.19): + + ``` + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb.dtb + ``` + + * For machine h3ulcb (BSP < 2.19): + + ``` + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb + ``` + + * For machine m3ulcb: + + ```bash + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb + ``` + + * For machine m3ulcb with a kingfisher board: + + ```bash + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb-kf.dtb + ``` + + * For machine h3ulcb with a kingfisher board: + + ```bash + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb-kf.dtb + ``` + + * Finally save boot environment: + + ```bash + saveenv + ``` + +* Now you can boot: + +``` +run bootcmd +``` + +### Console boot + +After booting, you should see the wayland display on the external monitor and a login prompt on the console, such as: + +* For machine h3ulcb: + +```bash +Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 + +h3ulcb login: root +``` + +* For machine m3ulcb: + +```bash +Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0 + +m3ulcb login: root +``` + +Logging in on the console is easy: + +* login is 'root' +* password is empty (not asked) + +### Network access + +If the board is connected to a local network using ethernet and if a DHCP server is able to distribute IP addresses, +you can then determine the Gen3 board IP address and log in using ssh: + +```bash +m3ulcb login: root +Last login: Tue Dec 6 09:55:15 UTC 2016 on tty2 +root@m3ulcb:~# ip -4 a +1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever +3: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 + inet 10.0.0.27/24 brd 10.0.0.255 scope global eth0 + valid_lft forever preferred_lft forever +root@m3ulcb:~# +``` + +Here, IP address is 10.0.0.27. Logging in using SSH is easy: + +```bash +$ ssh root@10.0.0.27 +Last login: Tue Dec 6 10:01:11 2016 from 10.0.0.13 +root@m3ulcb:~# cat /etc/os-release +ID="poky-agl" +NAME="Automotive Grade Linux" +VERSION="3.0.0+snapshot-20161202 (chinook)" +VERSION_ID="3.0.0-snapshot-20161202" +PRETTY_NAME="Automotive Grade Linux 3.0.0+snapshot-20161202 (chinook)" +``` + +## More Documentation + +Detailed guides on how to build AGL for Renesas boards and using AGL SDK inside a ready-to-use Docker container: + +* [AGL-Devkit-Build-your-1st-AGL-Application.pdf][Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application] + Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. +* [AGL-Devkit-HowTo_bake_a_service.pdf][Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service] + Generic guide on how to add a new service in the BSP. +* [AGL-Kickstart-on-Renesas-Porter-Board.pdf][Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board] +* [AGL-Devkit-Image-and-SDK-for-Porter.pdf][Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter] +* [AGL Developer Website](http://docs.automotivelinux.org) + +[R-car m3ulcb]: http://elinux.org/R-Car/Boards/M3SK +[R-car m3ulcb firmware update]: https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware +[R-car h3ulcb]: http://elinux.org/R-Car/Boards/H3SK +[R-car h3ulcb firmware update]: https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware +[R-car salvator-x]: https://elinux.org/R-Car/Boards/Salvator-X +[R-car loader update]: http://elinux.org/R-Car/Boards/Kingfisher#How_to_update_of_Sample_Loader_and_MiniMonitor +[R-car Kingfisher]: https://elinux.org/R-Car/Boards/Kingfisher +[R-car yocto]: http://elinux.org/R-Car/Boards/Yocto-Gen3 +[rcar Linux Drivers]: https://www.renesas.com/solutions/automotive/rcar-download/rcar-demoboard.html +[rcar Linux Drivers 2]: https://www.renesas.com/en-us/solutions/automotive/rcar-download/rcar-demoboard-2.html +[Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf +[Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf +[Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf +[Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf + diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md new file mode 100644 index 0000000..34957a8 --- /dev/null +++ b/docs/getting-started/machines/intel.md @@ -0,0 +1,186 @@ +# Running AGL on Intel MinnowBoard (and most Intel 64 bits HW) + +## Scope + +This documentation is aiming at people who want to run Automotive Grade +Linux (AGL) on Intel Hardware (HW). +While the reference HW used by AGL project is the Open Source MinnowBoard, this documentation [MinnowBoard wiki](https://minnowboard.org/) can be used to enable most of 64-bit Intel Architecture (IA) platforms using UEFI as boot loader. +In addition to the MinnowBoard, support for the [upCore & UpSquared boards](http://www.up-board.org/upsquared/) has been added. +You need to run the 64-bit version of the UEFI bootloader. +MinnowBoard Max and Turbot as well as Joule are both 64-bit capable. + +**Note**: This page is more focused on those who want to create bespoke AGL images and BSPs. + +If you are interested in creating ***applications*** to run on AGL, please visit the [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) documentation. + +UEFI has evolved a lot recently and you likely want to check that your HW firmware is up-to-date, this is mandatory for both the MinnowBoard-Max and the Joule. Not required on Minnowboard-Turbo and Up boards. + +[`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max) +[`https://software.intel.com/en-us/flashing-the-bios-on-joule`](https://software.intel.com/en-us/flashing-the-bios-on-joule) + +## Where to find an AGL bootable image + +### Download a ready made image + +AGL provides ready made images for developers. +You will find them on [AGL Download web site](https://download.automotivelinux.org/AGL/release) +image are located in YourPreferedRelease/intel-corei7-64/deploy/images/intel-corei7-64/ +Create a bootable SD card with the script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) +check the available options with the -v option. mkefi-agl.sh -v + +### Building an AGL image from scratch using Yocto + +**Note**: an alternative method for building an image is to use the AGL SDK delivered in a Docker container. + +There is currently no SDK dedicated to IA but the SDK provided for the Porter Board can build an IA image without changes (just `aglsetup.sh` needs to call for Intel). + +See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf "wikilink"). + +#### Download AGL source code + +Downloading the AGL sources from the various Git repositories is automated with the `repo` tool. Basic steps to download the AGL source code is described below and for more advanced topics involving the `repo` tool, please refer to the [`repo` documentation](https://source.android.com/source/using-repo.html "wikilink"). + +To install the `repo` tool: + +```bash + mkdir -p ~/bin; + export PATH=~/bin:$PATH; + curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo; + chmod a+x ~/bin/repo; +``` + +#### Configuring for the current *(older)* stable (Electric Eel 5.0.x) + +```bash + cd AGL-5.0.x; + repo init -b eel -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo +``` + +#### Configuring for master (DD) + +```bash + cd AGL-master; + repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo; +``` + +Once that you repo is initialised either with the stable or WIP, you need to sync the repo to fetch the various git trees. + +#### Downloading the configured AGL source code + +```bash + repo sync; +``` + +#### Building the AGL distro + +You are now ready to initialise your Yocto build. +When running the command: + +```bash + source meta-agl/scripts/aglsetup.sh -h +``` + +You will notice the Intel entries + +```bash + intel-corei7-64 + joule +``` + +Simply select that entry to replace porter in the -m option. +**Note:** agl-netboot option is required to create the right initramfs even if you do not boot from a network + +```bash + source meta-agl/scripts/aglsetup.sh \ + -m intel-corei7-64 \ + -b build \ + agl-devel agl-demo agl-appfw-smack agl-netboot agl-audio-4a-framework +``` + +**Note:** use the option "-m joule" when building for a Joule developer Kit target. + +Start the build **This can take several hours depending of your CPU and +internet connection and will required several GB on /tmp as well as on your build directory** + +```bash + bitbake agl-demo-platform +``` + +**Your newly baked disk image (.wic.xz) will be located at**: + `tmp/deploy/images/intel-corei7-64/` + +##### Alternative: Download a *ready made* image from AGL web site + +The Continuous Integration (CI) process from AGL creates and publish daily and stable builds. +Pointers to both can be found in [AGL supported HW](https://wiki.automotivelinux.org/agl-distro) (see Reference BSP/Intel). + +Once you have validated your process you can start to play/work with the snapshot pointer. + +Note that snapshot build may not work. + +Follow the directory: + +`intel-corei7-64/deploy/images/intel-corei7-64/` + +and download the file: + +`agl-demo-platform-intel-corei7-64.hddimg` + +## Create a bootable media + +Depending your target HW you will use an USB stick, an SD card or a HDD/SDD. +The creation process remains the same independently of the selected support. +It does require to have access to a Linux machine with `sudo` or root password. + +### Insert you removable media in the corresponding interface + +### Check the device name where the media can be accessed with the command + +```bash + lsblk + # Note that you want the name of the raw device not of a partition on the media + #(eg. /dev/sdc or /dev/mmcblk0) +``` + +### Download the script `mkefi-agl.sh` + +This script is present in the directory meta-agl/scripts from blowfish 2.0.4 : [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) + +Alternatively you can download it from the following Git repo: + +[https://github.com/dominig/mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh) + +### check the available options + +```bash + sh mkefi-agl.sh -v; +``` + +### create your media with the command adjusted to your configuration + +```bash + sudo sh mkefi-agl.sh MyAglImage.hdd /dev/sdX + #/dev/sdX is common for USB stick, /dev/mmcblk0 for laptop integrated SD card reader +``` + +## Boot the image on the target device + +1. Insert the created media with the AGL image in the target device + +1. Power on the device + +1. Select Change one off boot option (generally F12 key during power up) + +1. Select your removable device + +1. Let AGL boot + +**Note:**: depending on the speed of the removable media, the first boot may not complete, in that case simply reboot the device. + +This is quite common with USB2 sticks. + +By default the serial console is configured and activated at the rate of 115200 bps. + +## How to create your 1st AGL application + +[Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) diff --git a/docs/getting-started/machines/qemu.md b/docs/getting-started/machines/qemu.md new file mode 100644 index 0000000..7bd14c0 --- /dev/null +++ b/docs/getting-started/machines/qemu.md @@ -0,0 +1,119 @@ +# Building the AGL Demo Platform for QEMU + +To build the QEMU version of the AGL demo platform use machine **qemux86-64** along with features **agl-demo** and **agl-devel**: + +```bash +source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 agl-demo agl-devel +bitbake agl-demo-platform +``` + +By default, the build will produce a compressed *vmdk* image in **tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz** + +## Deploying the AGL Demo Platform for QEMU + +### Prepare an image for boot + +Decompress the **agl-demo-platform-qemux86-64.vmdk.xz** image to prepare it for boot. + +#### Linux + +```bash +cd tmp/deploy/images/qemux86-64 +xz -d agl-demo-platform-qemux86-64.vmdk.xz +``` + +#### Windows + +Download [7-Zip](http://www.7-zip.org/) and select **agl-demo-platform-qemux86-64.vmdk.xz** to be decompressed. + +## Boot an image + +### QEMU + +#### Install QEMU + +**Note**: if an AGL crosssdk has been created, it will contain a qemu binary for the host system. This SDK qemu binary has no graphics support and cannot currently be used to boot an AGL image. + +*Arch*: + +```bash +sudo pacman -S qemu +``` + +*Debian/Ubuntu*: + +```bash +sudo apt-get install qemu-system-x86 +``` + +*Fedora*: + +```bash +sudo yum install qemu-kvm +``` + +#### Boot QEMU + +Boot the **agl-demo-platform-qemux86-64.vmdk** image in qemu with kvm support: + +```bash +qemu-system-x86_64 -enable-kvm -m 2048 \ + -hda agl-demo-platform-qemux86-64.vmdk \ + -cpu kvm64 -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt \ + -vga virtio -show-cursor \ + -device virtio-rng-pci \ + -serial mon:stdio -serial null \ + -soundhw hda \ + -net nic,vlan=0 \ + -net user,hostfwd=tcp::2222-:22 +``` + +### VirtualBox + +#### Install VirtualBox + +Download and install [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 5.2.0 or later. + +#### Boot VirtualBox + +Boot the **agl-demo-platform-qemux86-64.vmdk** image in VirtualBox: + +* Start VirtualBox +* Click **New** to create a new machine + * Enter **AGL QEMU** as the *Name* + * Select **Linux** as the *Type* + * Select **Other Linux (64-bit)** as the *Version* + * Set *Memory size* to **2 GB** + * Click **Use an existing virtual hard disk file** under *Hard disk* + * Navigate to and select the **agl-demo-platform-qemux86-64.vmdk** image +* Ensure that the newly created **AGL QEMU** machine is highlighted and click **Start** + +### VMWare Player + +#### Install VMWare Player + +Download and install [VMWare Player](https://www.vmware.com/products/player/playerpro-evaluation.html) + +#### Boot VMWare Player + +Boot the **agl-demo-platform-qemux86-64.vmdk** image in VMWare Player: + +* Start VMWare Player +* Select **File** and **Create a New Virtual Machine** + * Select **I will install the operating system later** and click **Next** + * Select **Linux** as the *Guest Operating System*, **Other Linux 3.x kernel 64-bit** as the *Version*, and click **Next** + * Enter **AGL QEMU** as the *Name* and click **Next** + * Leave *disk capacity settings* unchanged and click **Next** + * Click **Finish** +* Select/highlight **AGL QEMU** and click **Edit virtual machine settings** + * Select/highlight **Memory** and click **2 GB** + * Select/highlight **Hard Disk (SCSI)** and click **Remove** + * Click **Add** + * Select **Hard Disk** and click **Next** + * Select **SCSI (Recommended)** and click **Next** + * Select **Use an existing virtual disk** and click **Next** + * Browse and select the **agl-demo-platform-qemux86-64.vmdk** image + * Click **Finish** + * Click **Keep Existing Format** + * Click **Save** +* Ensure that the newly created **AGL QEMU** machine is highlighted and click **Power On** diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md new file mode 100644 index 0000000..e016584 --- /dev/null +++ b/docs/getting-started/machines/raspberrypi.md @@ -0,0 +1,39 @@ +# Building the AGL Demo Platform for Raspberry Pi + +## Raspberry Pi 3 + +To build AGL demo platform for Raspberry Pi 3 use machine **raspberrypi3** and feature **agl-demo**: + +```bash +source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-appfw-smack +bitbake agl-demo-platform +``` + +## Raspberry Pi 2 + +To build AGL demo platform for Raspberry Pi 2 use machine **raspberrypi2** and feature **agl-demo**: + +```bash +source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-appfw-smack +bitbake agl-demo-platform +``` + +## Booting AGL Demo Platform on Raspberry Pi + +Follow the steps below to copy the image to microSD card and to boot it on Raspberry Pi 2 or 3: + +* Connect your sdcard in your linux machine. +* Copy output image from build machine to linux machine that is connected your sdcard. (Often, those are same machines) +* Output Image location in build machine for Raspberry Pi 2: *tmp/deploy/images/raspberrypi2/agl-demo-platform-raspberrypi2.wic.xz* +* Output Image location in build machine for Raspberry Pi 3: *tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic.xz* +* Unmount the microSD card and after that flash output image to it card with root user: + +*Note: the sdimage files can also be named rpi-sdimg-ota in case you have the **"agl-sota"** feature enabled* + +```bash +sudo umount [sdcard device] +xzcat [output image] | sudo dd of=[sdcard device] bs=4M +sync +``` + +* Plug your microSD card into Raspberry Pi 2 or 3 and boot the board diff --git a/docs/getting-started/setup-sdk-environment.md b/docs/getting-started/setup-sdk-environment.md new file mode 100644 index 0000000..691702c --- /dev/null +++ b/docs/getting-started/setup-sdk-environment.md @@ -0,0 +1,124 @@ +# AGL SDK Quick Setup + +This tutorial explains how to quickly setup an environment suitable to building and packaging AGL Applications using the SDK and a Docker container. + +The current tutorial has been tested on Linux, but may work with a few adjustments for Windows or MacOS. + +## Step 1: install Docker + +First install docker on your host, if not already done. +General instructions for Linux are available on the [Docker Site](https://docs.docker.com/engine/installation/linux/). + +Add yourself to the docker group. + +## Step 2: setup persistent workspace + +Docker images are pre-configured to use a particular uid:gid to enable the use +of OpenEmbedded build system. They provide a dedicated user account *devel* +which belong to uid=1664(devel) gid=1664(devel). (Note: password is *devel*) + +The script 'create_container' presented below instantiates a new container +and shares some volumes with the host: + +* /xdt (the build directory inside the container) is stored in ~/ssd/xdt_$ID (specific to instance ID) +* /home/devel/mirror is stored in ~/ssd/localmirror_$ID (specific to instance ID) +* /home/devel/share => points to ~/devel/docker/share (shared by all containers) + +Those shared volumes with the host needs the proper permissions to be accessible +from the contained environment. + +```bash +mkdir ~/ssd ~/devel +chmod a+w ~/ssd ~/devel +``` + +**Note**: + +* To gain access from your host on files created within the container, your + host account requires to be added to group id 1664. + +## Step 3: install the "Generic AGL Worker" Docker Image + +### Get docker image + +#### Pre-built image + +A pre-built image is available on automotivelinux download public site and can be used directly. + +First, download and load the image in your local Docker instance: + +```bash +wget -O - https://download.automotivelinux.org/AGL/snapshots/sdk/docker/docker_agl_worker-latest.tar.xz | docker load; +docker images; + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.automotivelinux.org/agl/worker-generic 5.99-95 6fcc19b4e0d7 2 weeks ago 1.56GB + jenkins latest 55720d63e328 5 weeks ago 711.9 MB + hello-world latest c54a2cc56cbb 5 months ago 1.848 kB +``` + +Identify the IMAGE_ID you just loaded. In the example above, this is 6fcc19b4e0d7 + +```bash +export IMAGE_ID=6fcc19b4e0d7 +``` + +#### Rebuilt image + +The Docker image for AGL Worker can be rebuilt using the scripts published here [docker-worker-generator](https://git.automotivelinux.org/AGL/docker-worker-generator/). + +### Start image + +Then, use the 'create_container' script to start a new, fresh container based on the AGL Worker image: + +**Note**: + +* The password for the id 'devel' inside the docker image is 'devel'. + +```bash +git clone https://git.automotivelinux.org/AGL/docker-worker-generator; +cd docker-worker-generator; +./contrib/create_container 0 $IMAGE_ID; +docker ps; + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + 4fb7c550ad75 6fcc19b4e0d7 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx +``` + +## Step 4: install the AGL SDK for your target + +Here, we assume that we just built an image 'agl-demo-platform-crosssdk' using the Yocto build procedure documented in the [Getting Started](../) section of the documentation. + +So we can copy such file to the shared volume. + +For example, we could have built the SDK from another worker container listening with SSH on port 2223: + +```bash +create_container 1; +ssh -p 2223 devel@mybuilder.local; +... [ prepare build environment ] ... +bitbake agl-demo-platform-crosssdk; +... [ build happens in /xdt/build ] ... +cp /xdt/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh ~/share; +``` + +then login to the first "SDK Container" and install the SDK: + +```bash +ssh -p 2222 devel@mysdk.local; +install_sdk ~/share/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh; +``` + +## Step 5: build your application + +First, you must source the SDK environment you wish to use (you MUST repeat this step each time you open a new shell): + +```bash +source /xdt/sdk/environment-setup- +``` + +You're then ready to go: get the sources, run the builds ... + +```bash +git clone ; +cd ; +cmake; make; make package; +``` diff --git a/docs/getting-started/source-code.md b/docs/getting-started/source-code.md new file mode 100644 index 0000000..3c5d6f4 --- /dev/null +++ b/docs/getting-started/source-code.md @@ -0,0 +1,201 @@ +# Introduction: Building target AGL image with Yocto project + +The standard Yocto process is made of the following steps: + +* Setting up your operating system. +* Setting up the build environment for R-Car BSP. +* Downloading the proprietary drivers and installing them in the build environment (if needed). +* Build the image. +* Boot using SD-CARD. + * Create an SD-CARD. + * Configure to boot on SD-CARD. + * Copy the image to the SD-CARD. + * Boot the board on it. + +For convenience, the resulting development images are made available [Here][AGL snapshots master latest] + +If you want to bypass the build phase and quick boot the board, you can download the image tarball and the kernel then follow the installation procedure. + +## Setting up your operating system + +The very first step is to ensure that your system can run the build system of the Yocto Project. + +**Important**: it only runs on Linux + +* if your system is Windows© or iOS© you should use a virtualization solution (Virtualbox, VMWare ...) to run a Linux VM on your system. + +For AGL 6.0, Yocto Project 2.4, known as rocko, has been selected for the BSP and build system. + +Reference data for configuring your system can be found in the Yocto documentation [Here][yocto ref Manual] + +Here after an extract of this documentation for most common Linux distributions: + +* The build system should be able to run on any modern distributions that has the following versions for: + * Python + * Git 1.7.8 or greater + * tar 1.24 or greater + * GCC, … + +**Note**: + +* Python 2.7.3 or greater excluding Python 3.x, which is not supported. + +### Ubuntu and Debian + +The essential and graphical support packages you need for a supported Ubuntu or Debian distribution are shown in the following command: + +```bash +sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ + build-essential chrpath socat libsdl1.2-dev xterm cpio curl +``` + +**Note**: + +* Also note that for this tutorial, the utility 'curl' has been added to the list of packages to install. + +### Fedora + +The essential and graphical packages you need for a supported Fedora distribution are shown in the following command: + +```bash +sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ + diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ + ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \ + SDL-devel xterm curl +``` + +### OpenSUSE + +The essential and graphical packages you need for a supported OpenSUSE distribution are shown in the following command: + +```bash +sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \ + diffstat texinfo python-curses patch socat libSDL-devel xterm curl \ + python3 python3-curses glibc-locale +``` + +### CentOS + +The essential and graphical packages you need for a supported CentOS distribution are shown in the following command: + +```bash +sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ + diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ + socat SDL-devel xterm curl +``` + +## Download AGL Source Code + +The AGL source code and Yocto layers are maintained on the AGL Gerrit server. +For information on how to create accounts for gerrit see [Getting Started with AGL][Getting Started with AGL]. + +### Setting up the build environment + +In the following, your top level directory is noted as “AGL_TOP”. +For example, we will set AGL_TOP to point to a directory “$HOME/workspace_agl”: + +```bash +export AGL_TOP=$HOME/workspace_agl +mkdir -p $AGL_TOP +``` + +### Prepare Repo Tool + +AGL Uses the 'repo' tool for managing repositories. +You need to setup layers of AGL. +You can use the commands below to prepare Repo: + +```bash +mkdir -p ~/bin +export PATH=~/bin:$PATH +curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo +chmod a+x ~/bin/repo +``` + +**Note**: + +* More information about the tool 'repo' [Here][repo info] + +### Download source + +You can choose your source release + +### Download Latest Stable Release + +To download all layers for the for the latest stable release, eel 5.0.3: + +```bash +cd $AGL_TOP +repo init -b eel -m eel_5.1.0.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo +repo sync +``` + +### Download Master Branch + +To download all code from master: + +```bash +cd $AGL_TOP +repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo +repo sync +``` + +## Set up Build Environment Info + +AGL has created a set up script for defining the target build and desired optional features. + +To get a complete list of the options available run. + +```bash +cd $AGL_TOP +source meta-agl/scripts/aglsetup.sh -h +``` + +Once you run aglsetup.sh with your desired parameters, you can build any target desired. + +## Features supported by aglsetup + +Here is the list of features for AGL 2.1 that can be specified in the aglsetup.sh command line: + +* in **meta-agl** + * agl-all-features + * agl-appfw-smack: enables IoT.bzh Application Framework + SMACK + Cynara + * agl-archiver + * agl-ci + * agl-ci-change-features + * agl-ci-change-features-nogfx + * agl-ci-snapshot-features + * agl-ci-snapshot-features-nogfx + * agl-devel: activate development options (empty root password, debugger, strace, valgrind …) + * agl-gplv2 + * agl-isafw + * agl-netboot: enable network boot support through TFTP and NBD (see meta-netboot layer) + * agl-profile-graphical + * agl-profile-graphical-html5 + * agl-profile-graphical-qt5 + * agl-profile-hud + * agl-profile-telematics + * agl-ptest + * agl-sota: enable SOTA components and dependencies (meta-sota, meta-filesystems, meta-ruby, meta-rust are added) +* in **meta-agl-demo** + * agl-demo: enable layer meta-agl-demo and meta-qt5 - required to build * agl-demo-platform + * agl-iotivity + * agl-sdl +* in **meta-agl-devel** + * agl-audio-4a-framework + * agl-audio-soundmanager-framework + * agl-egvirt + * agl-hmi-framework + * agl-oem-extra-libs + * agl-renesas-kernel + * agl-telemetry +* in **meta-agl-extra** + * agl-localdev: add a local layer named “meta-localdev” in meta directory and a local.dev.inc conf file if present + * blsched + +For newer features or to get more details on a given feature, take a look at the configuration files stored for each feature and/or each machine in meta-agl/templates and meta-agl-extra/templates. + +[AGL snapshots master latest]: https://download.automotivelinux.org/AGL/snapshots/master/latest/ +[yocto ref Manual]: http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#detailed-supported-distros +[Getting Started with AGL]: https://wiki.automotivelinux.org/start/getting-started +[repo info]: https://source.android.com/source/using-repo.html diff --git a/docs/getting-started/troubleshooting.md b/docs/getting-started/troubleshooting.md new file mode 100644 index 0000000..d3ad889 --- /dev/null +++ b/docs/getting-started/troubleshooting.md @@ -0,0 +1,210 @@ +# Troubleshooting + +## Extended attributes MUST be copied + +**IMPORTANT, The extended attribute set during image construction MUST be copied to the SD card.** + +When using tar to create the SDcard, it is a common error to not copy the extended attributes. Find below instruction for using tar. + +Verify that **tar** version is 1.28 or newer: + +```bash +tar --version +tar (GNU tar) 1.28 +[snip] +``` + +If it is not the case, a native up-to-date version of tar is also generated while building AGL distribution: + +```bash +tmp/sysroots/x86_64-linux/usr/bin/tar-native/tar --version +tar (GNU tar) 1.28 +[snip] +``` + +To copy Automotive Grade Linux (AGL) files AND EXTENDED ATRIBUTES onto the SDcard using tar the command is: + +```bash +tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --totals \ + --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz +``` + +## meta-rust + +Due to a known bug in the upstream of meta-rust the Yocto/OE recipe for rust-cross may fail while building RVI SOTA Client or another application written in the Rust programming language. +Until the complete resolution of the issue the workaround is to disable all use of the CXX11 ABI by applying the following lines to **conf/local.conf**: + +```bash +LD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0" +TARGET_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0" +CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0" + +BUILD_CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" +TARGET_CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" +``` + +## Screen orientation for Splash and in Weston + +Depending of your scren mounting the default orientation of the UI an/or splash screen might be incorrect. +To change the orientation of the splash screen patch + +```bash +File: /etc/systemd/system/sysinit.target.wants/psplash-start.service +Line: ExecStart=/usr/bin/psplash -n -a 90 +``` + +To change the orientation of the UI in Weston patch + +```bash +File: /etc/xdg/weston/weston.ini +Line: transform=90 +``` + +## Disabling Homescreen in AGL 4.0.x DD release + +**Problem**: new installed applications are not available on Homescreen and even if started manually through afm-util, the application starts but no surface appears. + +**Answer**: this is due to IVI-Shell integration with Qt and Homescreen. + +To disable IVI-Shell and revert to the "plain old" weston desktop, you can follow the 4 steps below: + +* Modify */etc/xdg/weston/weston.ini* and comment the line mentioning IVI-shell. For example on Porter board: + +```bash + [core] + backend=drm-backend.so + #shell=ivi-shell.so + ... +``` + +* modify */etc/afm/unit.env.d/qt-for-ivi-shell* and comment the line specifying QT Wayland backend: + +```bash + ... + #Environment=QT_WAYLAND_SHELL_INTEGRATION=ivi-shell + ... +``` + +(If you use vi, remove backup files by `rm /etc/afm/unit.env.d/*~`) + +* disable Homescreen services: + +```bash + # systemctl --user mask HomeScreen.service +``` + +* Reboot your target and you should then be able to start apps on the standard weston screen using afm-util + +## Adding media files to play with MediaPlayer + +AGL include the default MediaPlayer sample app which can be used to play music. The `lightmediascanner.service` by default will search for media under the `/media` folder. So if you plug in any USB stick containing music, they would be recognized and showed in the playlist of the MediaPlayer app menu. + +The current supported format is OGG. Please convert your files to ogg to play with MediaPlayer. + +In case you want to store music in another place, modify the `/usr/lib/systemd/user/lightmediascanner.service` file and change the `--directory` parameter to the path of that folder. + +If you don’t want to touch the ligthmediascanner service, you can also add a folder named "Music" under `/home/root` and put your music files there. + +## Configuring the Audio hardware + +AGL uses alsa as Audio configuration master. If the correct HW is not setup, the Audio system will fail to start what will also fails the demo Home Screen launch. +You need to configure Audio in 2 places + +* alsa +* 4A HAL + +### alsa + + The file /etc/asound.conf (at the beginning) tells which hardware will be used. + For example on an Intel Minnow or UP board your need to enter the following configuration. + +```bash + pcm.Speakers { + type dmix + slave {pcm "hw:PCH,3"} + ipc_key 1001 # ipc_key should be unique to each dmix + } +``` + +The correct value (here hw:PCH,3) can be obtained with the command: + +```bash + aplay -l + **** List of PLAYBACK Hardware Devices **** + card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] + Subdevices: 1/1 + Subdevice #0: subdevice #0 + card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] + Subdevices: 1/1 + Subdevice #0: subdevice #0 +``` + +Using hw:PCH rather than hw:0 will avoid you many trouble.\ +NOTE that the device number is not always 0. If you give no device number, alsa will assume device 0 (and the not the first available device), what can fail your configuration.\ +As the default is hw:0 (card 0 device 0), it will always fail on a Minnow or UP board. + +For info HW device for common configuration are: + +* for USB Audio -> hw:AUDIO,0 +* for Intel Analog output -> hw:PCH,0 (not available on Minnow, Joule, Up boards, ...) +* for Intel via -> HDMI hw:PCH,3 +* for MOST Unicens -> hw:ep016ch,0 + +### 4A HAL configuration + +AGL 4A needs to know which HAL shall be used. This is configured in the file: + +```bash +/usr/agl-service-audio-4a/ahl-agl-service-audio-4a-config.json +``` + +At the beginning of that file you will find the slected HAL (note the there is no correct default value). + +```bash +{ + "version": "0.2.0", + "policy_module": "AudioPolicy_v1", + "description": "High-level binding configuration file", + "note": "Devices and routings are always listed in order of priority (for device selection rules)", + "hal_list": ["intel-minnow"], + "audio_roles": [ +``` + +Here you see "intel-minnow" but common values are: + +* Intel laptop -> intel-pc +* Intel via HDMI -> intel-minnow +* Renesas -> Rcar-M3 +* USB Audio Speaker -> usb-audio +* MOSTS Unicens -> hal-most-unicens + +More HAL can be found on Gerrit (search projects named as 4a-hal*) + +## Installing the Map for the Navigation Application + +While the Navigation App is installed with all other demo Apps at first boot, the Maps required to be installed manually. + +### a) Method 1 on target download + + 1. Install the new image on the target + 2. boot a first time to install the demo Apps + 3. via ssh or serial connection, execute the script + * /usr/AGL/apps/download_mapdata_uk.sh\ + or + * /usr/AGL/apps/download_mapdata_jp.sh + +### b) At image creation + +Download on your build machine the desired maps and uncompress them on your target image before 1st boot. +This method is quicker and does not require to have the network enabled on the target device. +Map can be found here. + +* +* + +Once that you have built your image on the SD card, uncompress the desired map in on the SD card at the position /YourMountPoint/var/mapdata\ +(YourMountPoint will vary with your build system). + +You can also use the script from the image to install the Mapdata on your SD card but there is little adavange in using that method. e.g. + +* download_mapdata_jp.sh /YourMountPoint diff --git a/docs/platform/working-on-the-chinook-branch.md b/docs/platform/working-on-the-chinook-branch.md new file mode 100644 index 0000000..c211650 --- /dev/null +++ b/docs/platform/working-on-the-chinook-branch.md @@ -0,0 +1,122 @@ +# Working on the chinook branch + +## Intro + +This is a quick howto for working on the 'Charming Chinook' branch. Working on the branch +is easy as we maintain all changes through gerrit.automotivelinux.org. +If you are unfamiliar with gerrit, please read these fine how-to pages were put together from the +Mediawiki community here: . This covers the basics very well. Of course we'll work with gerrit.automotivelinux.org instead so apply likewise. + +## Installation of tools + +Install `git` with your distributions package manager. +A very useful tool is "git-review" (cmdline is then `git review`). +Install it from your distro or with `sudo pip install git-review`. + +## Prerequisites + +It is important to setup git and gerrit properly (see the Tutorial page mentioned above): + +* prereq #1) make sure git is properly setup with name/email +* prereq #2) make sure your ssh key is in gerrit.automotivelinux.org + +## Cloning, editing and submitting for review + +Follow these steps to submit a change to the 'Charming Chinook' branch: + +1. cloning the (tip of the) branch + + ```bash + repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + repo sync + ``` + +1. Change the recipe in question (one change at a time - small is better) + + ```bash + vi recipe-foo/bar/baz.bb + ``` + +1. Do a a few builds and tests (try 2 architectures if possible) + + ```bash + source meta-agl/scripts/aglsetup.sh .... agl-all-features + bitbake agl-demo-platform + ``` + +1. once satisfied do commit your change as usual in git + Make sure to do a proper commit message: + + + ```bash + git commit -s + + ``` + +1. All repos have .gitreview files already, so now it is just + + ```bash + git review + ``` + +1. (optional, but highly recommended!) Reset to gerrit/chinook + + ```bash + git checkout chinook` + git reset --hard gerrit/chinook + ``` + + It helps during the review process as gerrit would otherwise enforce + the whole series of patches to be reviewed/merged together (2nd depends on 1st patch). + +1. Rinse (=6) and repeat (=2-5) + +## Using git review to review/test-build a specific change in gerrit + +'git review' is also useful if you want to review a change. +Example for meta-agl: + +```bash + repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + repo sync + cd meta-agl/ + git review -d 8105 +``` + +This will pull-down change 8105. Now we can build with it applied: + +```bash + cd .. + source ... + bitbake ... +``` + +## Using gerrit to amend a changeset while in review + +The same workflow applies if you want to _amend_ a changeset while it is in review (not merged, yet): + +```bash +cd meta-agl/ +git review -d 8105 +``` + +This will pull-down change 8105. You can now edit a file: + +```bash +vi recipes-foo/bar/baz.bb +git commit -s --amend +``` + + Don't forget a test build + +```bash +cd .. +source meta-agl/scripts/aglsetup.sh ..... agl-all-features +bitbake ... # e.g. agl-demo-platform +``` + + Finally call git review to upload the change + +```bash +git review +``` \ No newline at end of file diff --git a/docs/platform/working-on-the-master-branch.md b/docs/platform/working-on-the-master-branch.md new file mode 100644 index 0000000..31f0c04 --- /dev/null +++ b/docs/platform/working-on-the-master-branch.md @@ -0,0 +1,122 @@ +# Working on the master branch + +## Intro + +This is a quick howto for working on the 'master' branch. Working on the branch +is easy as we maintain all changes through gerrit.automotivelinux.org. +If you are unfamiliar with gerrit, please read these fine how-to pages were put together from the +Mediawiki community here: . This covers the basics very well. Of course we'll work with gerrit.automotivelinux.org instead so apply likewise. + +## Installation of tools + +Install `git` with your distributions package manager. +A very useful tool is "git-review" (cmdline is then `git review`). +Install it from your distro or with `sudo pip install git-review`. + +## Prerequisites + +It is important to setup git and gerrit properly (see the Tutorial page mentioned above): + +* prereq #1) make sure git is properly setup with name/email +* prereq #2) make sure your ssh key is in gerrit.automotivelinux.org + +## Cloning, editing and submitting for review + +Follow these steps to submit a change to the 'master' branch: + +1. cloning the (tip of the) branch + + ```bash + repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + repo sync + ``` + +1. Change the recipe in question (one change at a time - small is better) + + ```bash + vi meta-xyz/recipe-foo/bar/baz.bb + ``` + +1. Do a a few builds and tests (try 2 architectures if possible) + + ```bash + source meta-agl/scripts/aglsetup.sh .... agl-all-features + bitbake agl-demo-platform + ``` + +1. once satisfied do commit your change as usual in git + Make sure to do a proper commit message: + + + ```bash + git commit -s + + ``` + +1. All repos have .gitreview files already, so now it is just + + ```bash + git review + ``` + +1. (optional, but highly recommended!) Reset to gerrit/master + + ```bash + git checkout master + git reset --hard gerrit/master + ``` + + It helps during the review process as gerrit would otherwise enforce + the whole series of patches to be reviewed/merged together (2nd depends on 1st patch). + +1. Rinse (=6) and repeat (=2-5) + +## Using git review to review/test-build a specific change in gerrit + +'git review' is also useful if you want to review a change. +Example for meta-agl: + +```bash + repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + repo sync + cd meta-agl/ + git review -d 8233 +``` + +This will pull-down change 8233. Now we can build with it applied: + +```bash + cd .. + source ... + bitbake ... +``` + +## Using gerrit to amend a changeset while in review + +The same workflow applies if you want to _amend_ a changeset while it is in review (not merged, yet): + +```bash +cd meta-agl/ +git review -d 8233 +``` + +This will pull-down change 8233. You can now edit a file: + +```bash +vi meta-xyz/recipes-foo/bar/baz.bb +git commit -s --amend +``` + + Don't forget a test build + +```bash +cd .. +source meta-agl/scripts/aglsetup.sh ..... agl-all-features +bitbake ... # e.g. agl-demo-platform +``` + + Finally call git review to upload the change + +```bash +git review +``` \ No newline at end of file diff --git a/docs/security-blueprint/README.md b/docs/security-blueprint/README.md new file mode 100644 index 0000000..a3cf24c --- /dev/null +++ b/docs/security-blueprint/README.md @@ -0,0 +1,158 @@ +# Introduction + +Modern cars have become a lot more technologically sophisticated and different than those of the past. We are seeing a wider range of new features and functionality, with a lot more complex software. It is fair to say that the cars being introduced to the market today have much more in common with computing devices like cell phones, than their predecessors did. Modern car manufacturers are also integrating support for a broad range of communication technologies for these “connected” cars. With the advent of such vehicles, Linux has become a natural choice for the software platform, with Automotive Grade Linux as a promising example. + +From a security point of view, the remote capabilities of a connected car results in a much larger attack surface. This opens a whole new world of security vulnerabilities that need to be considered during the architectural design. History shows that physical access to a device is sufficient for a hacker to gain root privileges. This makes the car a hostile environment. + +The Security Blueprint documents the security features that are included as part of Automotive Grade Linux (AGL) and identifies areas that need to be addressed from a security perspective as part of AGL. It also gives guidance around existing technologies and solutions. + +Security domains will allow us to create a set of tests verifying the security of Automotive Grade Linux. + +This document is firstly based on an existing AGL security-blueprint. + +**For security to be effective, the concepts must be simple. And by default, anything that is not allowed is forbidden.** + +We will cover topics starting from the lowest level (_Hardware_) up to the highest levels (_Connectivity_ and _Application_). We will move quickly on _Hardware_ and _Connectivity_ because this is not supported at our level. Solutions of connectivity problems concern updates and secured settings while hardware securing is related to the manufacturers. + +The document is filled with tags to easily identify important points: + + + +- The _config_ tag quickly identifies the configurations and the recommendations to take. + + + +- The _note_ tag allows you to notify some additional details. + + + +- The _todo_ tag shows the possible improvements. + + + +In annexes of this document, you can find all the _config_ and _todo_ notes. + +## Adversaries + +Adversaries and attackers within the Automotive space. + +- Enthusiast Attackers + +Enthusiast attackers have physical access to the Engine Control Units (ECUs) at the circuit board level. They can solder ‘mod chips’ onto the board and have access to probing tools. They also have information on ECUs that have been previously compromised and have access to softwares and instructions developed by other members of car modification forums. The goal of the enthusiast hacker could be, but is not limited to, adding extra horse power to the car or hacking it just for fun. + +- Corrupt Automotive Dealers + +Corrupt automotive dealers are attackers that have access to the same capabilities as enthusiasts, but also have access to the car manufacturer’s (OEM) dealer network. They may also have access to standard debugging tools provided by the car manufacturer. Their goal may be to support local car theft gangs or organized criminals. + +- Organized Criminals + +Organized criminals have access to all of the above tools but may also have some level of control over the internal network at many dealerships. They may have hacked and gained temporary control of the Over-The-Air (OTA) servers or the In-Vehicle Infotainment (IVI) systems. This is very much like the role of organized criminals in other industries such as paid media today. Their goal is to extort money from OEMs and/or governments by threatening to disable multiple vehicles. + +- Malware Developers + +Malware developers have developed malicious software to attack and compromise a large number of vehicles. The malicious software is usually designed to spread from one vehicle to another. Usually, the goal is to take control of multiple machines and then sell access to them for malicious purposes like denial-of-service (DoS) attacks or theft of private information and data. + +- Security Researchers + +Security researchers are ‘self-publicized’ security consultants trying to make a name for themselves. They have access to standard tools for software security analysis. They also have physical access to the vehicle and standard hardware debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to publicize attacks for personal gain or just to gain personal understanding with a sense of helping make things more secure. + +## Attack Goals + +In today’s connected vehicle, more and more functionality is moving to software control, meaning that the threat of attack becomes greater and greater. We see car features like navigation and summoning, car access/engine start, and motor/ECU upgrades all controlled through software and connections to the cloud. The risk of attack is high because there are high value targets in play. + +Here, we outline some of the major threats categories along with some sample attackers, example attacks, and a relative importance. These threat categories are intended to be general examples. There can be many nuances to threat types. Additionally, there can be many sub-attacks that eventually lead to these higher level attack goals. + +| Threat Category | Sample Attacker | Example Attacks | Relative Importance | +|-------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------| +| Vehicle theft | Individual, organized criminals | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity) | +| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury) | +| Vehicle hacking | Vehicle owner, competitor | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) | +| Sensitive asset theft | Organized criminals, blackmailers | Steal credit card numbers, health information, camera data, steal bandwidth | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later) | + +The Automotive Grade Linux (AGL) initiative builds upon open-source software including Linux and Tizen to offer a flexible application framework. However, the security provisions of the app framework, Cynara, and the security manager only go so far in keeping the biggest threats at bay. As experience has shown, providing a constrained app (like that in the Android Open Source Platform) and store development flow, signature verification, DAC sandboxing, and MAC (SMACK) controls over the platform can have a certain amount of success with the security of the system. However, the openness of the system invites many researchers, hobbyists and hackers and financially motivated attackers to compromise the system for their own gains. + +As AGL arrives on modern automobiles, this is inevitably inviting many capable actors to modify, attack, and compromise these well thought-out systems and their applications. With concerns like safety and security, the auto industry cannot afford to go the way of consumer devices like phones and tablets where security problems are encountered on a frequent basis. It is imperative to use a layered approach and defense-in-depth to protect the system from inevitable attack. + +## Assets and Security Categorization + +This section outlines some of the assets that are likely to be found in the vehicle and their relative sensitivity from an attack point of view. Additionally, the final column on the right lists some of the recommended protection types that can be applied to these types of assets (Note that the empty cells refer to the cells above them). A good protection approach will give priority to the most sensitive assets, using a defense-in-depth approach to cover these assets. Less sensitive assets are treated at a lower priority, typically protected with fewer protection techniques. A more fine-grained prioritization of the the assets in a concrete vehicle network can be achieved with detailed threat analysis which considers the topology of the vehicle network and access-controls that are in-place. e.g. the EVITA framework for attack trees. + +| Asset Category | Examples | Sensitivity | Recommended Protection Types | +|-------------------|--------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Software | ECU software, infotainment software, OS images | Critical | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS | +| Car Access | Biometric data, car keys | | | +| Payment Data | Credit cards, User profile critical data | | | +| Recordings | Internal camera recording, internal audio recording, external camera recording | High | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation | +| User Profile | Usernames and passwords, customization, calendar, contacts | | | +| Location | GPS coordinates, vehicle usage data | | | +| Purchased Content | Video, audio, licenses | | | +| Teleconference | Chat, audio, video | Medium | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission | +| Vehicle data | Vehicle info, sensor data | | | +| Navigation data | Static and dynamic maps | | | +| 3rd party data | Home automation commands, cloud game data | | | + +## Hardening term + +The term Hardening refers to the tools, techniques and processes required in order to reduce the attack surface on an embedded system, such as an embedded control unit (**ECU**) or other managed devices. The target for all hardening activities is to prevent the execution of invalid binaries on the device, and to prevent copying of security related data from the device. + + + +## AGL security overview + +AGL roots are based on security concepts. Those concepts are implemented by the security framework as shown in this picture: + +![AGL architecture](WhiteBoxArchi.png) + +-------------------------------------------------------------------------------- + +# Acronyms and Abbreviations + +The following table lists the strongest terms utilized within all this document. + +| Acronyms or Abbreviations | Description | +|---------------------------|-------------------------------------| +| _AGL_ | **A**utomotive **G**rade **L**inux | +| _ECU_ | **E**lectronic **C**ontrol **U**nit | + +-------------------------------------------------------------------------------- + + + +# References + +- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html). + - _http:// docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_ +- **[2017]** - [kernel security](https://www.kernel.org/doc/Documentation/security/). + - _https:// www.kernel.org/doc/Documentation/security/_ +- **[2017]** - [Systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf). + - _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_ +- **[2017]** - [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf). + - _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_ +- **[2017]** - [Improving Vehicle Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf). + - _https:// access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_ +- **[2016]** - [AGL framework overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html). + - _http:// docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_ +- **[2016]** - [SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf). + - _http:// iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_ +- **[2016]** - [Linux Automotive Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf). + - _http:// iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_ +- **[2016]** - [Automotive Security Best Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf). + - _https:// www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_ +- **[2016]** - [Gattacking Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf). + - _http:// gattack.io/whitepaper.pdf_ +- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf). + - _http:// www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_ +- **[2015]** - [Security in Automotive Bus Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf). + - _http:// citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_ +- **[2014]** - [IOActive Remote Attack Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf). + - _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_ +- **[2011]** - [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf). + - _https:// media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_ +- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf). + - _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_ +- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf). + - _https:// eprint.iacr.org/2010/332.pdf_ +- **[2010]** - [Wifi attacks wep wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf). + - _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_ +- **[2008]** - [SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf). + - _http:// schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_ diff --git a/docs/security-blueprint/WhiteBoxArchi.png b/docs/security-blueprint/WhiteBoxArchi.png new file mode 100644 index 0000000..d984d1a Binary files /dev/null and b/docs/security-blueprint/WhiteBoxArchi.png differ diff --git a/docs/security-blueprint/annexes/0_Abstract.md b/docs/security-blueprint/annexes/0_Abstract.md new file mode 100644 index 0000000..9db5fee --- /dev/null +++ b/docs/security-blueprint/annexes/0_Abstract.md @@ -0,0 +1,7 @@ +# Annexes + +The first part resumed all the configurations you must implement without any +explications since all the explanations are given as and when in the document. + +The second one allows to visualize all the todo notes in order to have a global +vision of the possible improvements of the document. diff --git a/docs/security-blueprint/annexes/ConfigNotes.md b/docs/security-blueprint/annexes/ConfigNotes.md new file mode 100644 index 0000000..b3770fa --- /dev/null +++ b/docs/security-blueprint/annexes/ConfigNotes.md @@ -0,0 +1,485 @@ +# Config notes + + +Domain | Object | Recommendations +-------------------- | ---------- | ---------------------------------- +Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. +Hardware-Integrity-2 | Board | Must use a HSM. +Hardware-Integrity-3 | RTC | Must not be alterable. + +Domain | Object | Recommendations +---------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. +Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. +Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. + +Domain | Object | Recommendations +----------------- | ---------- | ------------------------------------------------------------------------------------ +Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. +Hardware-Memory-2 | Bootloader | Internal NVM only +Hardware-Module-3 | - | HSM must be used to secure keys. + +Domain | _Variable_ / `Config` name | `Value` +---------------------- | -------------------------- | ------- +Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` +Boot-Image-Selection-2 | _bootdelay_ | `-2` + +Domain | `Config` name | _State_ +------------------------- | ---------------------------- | -------- +Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ +Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ +Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ +Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ +Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ +Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ + +Domain | Communication modes | _State_ +-------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- +Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. +Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. +Boot-Communication-3 | `Ethernet` | _Disabled_ +Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ +Boot-Communication-5 | `Serial ports` | _Disabled_ + +Domain | `Config` name | _State_ +------------------------ | ----------------------- | ------------- +Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ +Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ +Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ +Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ +Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ + +Domain | Communication modes | _State_ +-------------------- | -------------------- | --------------------------------------------------------------------------------------------- +Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. + +Domain | Object | Recommendations +-------------------- | --------------------------------- | ------------------------------------------------------------- +Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. + +Domain | `Command` name | _State_ +-------------------------- | -------------- | --------- +Boot-Communication-Flash-1 | `do_nand` | _Disable_ + +Domain | `Config` name | `Value` +---------------------- | --------------------------------------- | --------- +Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` +Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` +Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` + +Domain | `Environment variable` name | _State_ +---------------------- | --------------------------- | ------------- +Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ + +Domain | `Config` name | _State_ +-------------------------- | ---------------------------- | --------- +Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` +Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` +Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` +Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` +Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` +Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` +Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` +Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` +Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` +Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` +Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` +Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` + +Domain | `Command` name | _State_ +----------------------- | -------------- | ---------- +Boot-Consoles-MemDump-1 | `md` | _Disabled_ +Boot-Consoles-MemDump-2 | `mm` | _Disabled_ +Boot-Consoles-MemDump-3 | `nm` | _Disabled_ +Boot-Consoles-MemDump-4 | `mw` | _Disabled_ +Boot-Consoles-MemDump-5 | `cp` | _Disabled_ +Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ +Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ +Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ +Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ + +Domain | `Config` name | `Value` +-------------------- | -------------- | -------------------------------------- +Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m +Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m +Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y +Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y +Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y +Kernel-General-MAC-6 | CONFIG_SECURITY | y +Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y +Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y + +Domain | `Config` name | `Value` +---------------------- | -------------- | ------- +Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` + +Domain | `Config` name | `Value` +--------------------------- | --------------- | ------- +Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` + +Domain | `Config` name | `Value` +------------------------------- | ----------------------- | ------- +Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` + +Domain | `Config` name | `Value` +---------------------------- | --------------- | ------- +Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` + +Domain | `Config` name | `Value` +--------------------------- | ------------------------------ | ------- +Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` + +Domain | `Config` name | `Value` +---------------------------- | ---------------------- | ------- +Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` + +Domain | `Config` name | `Value` +-------------------------- | -------------------- | ------- +Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` +Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` + +Domain | `Config` name | `Value` +------------------------ | ---------------- | ------- +Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` + +Domain | `Config` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` + +Domain | `Variable` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` + +Domain | Object | _State_ +------------------------ | ------------------- | ---------- +Kernel-General-Drivers-1 | `USB` | _Disabled_ +Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ +Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ + +Domain | `compiler` and `linker` options | _State_ +-------------------------------- | ------------------------------- | -------- +Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ + +Domain | `compiler` and `linker` options | _State_ +--------------------------------- | ------------------------------- | -------- +Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ +Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ + +Domain | Object | Recommendations +------------------------------- | --------------- | -------------------------------- +Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. + +Domain | `Config` name | `Value` +------------------------------ | ---------------- | ------- +Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` + +Domain | `Config` name | `Value` +------------------------ | ------------------- | ------- +Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` + +Domain | `Config` name | `Value` +-------------------- | ------------- | ------- +Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` +Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` + +Domain | `Config` name | `Value` +--------------------- | -------------------------- | ------- +Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` + +Domain | `compiler` and `linker` options | _State_ +----------------------------- | ------------------------------- | -------- +Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ + +Domain | `compiler` options and `config` name | `Value` +------------------------------- | ------------------------------------ | ------- +Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` +Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` + +Domain | `Config` name | `Value` +------------------------ | ---------------------------- | ------- +Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` +Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` +Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` +Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` + +Domain | `Config` name | `Value` +----------------------------- | ------------------------- | ----------------------------------- +Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` +Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` +Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` + +Domain | `Config` name | `Value` +---------------------- | ------------- | ------- +Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` + +Domain | `Config` name | `Value` +----------------------- | -------------------- | ------- +Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` + +Domain | `Config` name | `Value` +------------------------------ | -------------------- | ------- +Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` + +Domain | `Config` name | `Value` +---------------------- | ------------------- | ------- +Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` + +Domain | `Config` name | `Value` +---------------------- | ---------------- | ------- +Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` + +Domain | `Config` name | `Value` +------------------------ | ------------------ | ------- +Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` +Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` + +Domain | `Config` name | `Value` +------------------------ | ------------------------- | ------- +Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` + +Domain | `Config` name | `Value` +------------------ | --------------------- | ------- +Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` +Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` + +Domain | `Config` name | `Value` +------------------------- | ----------------- | ------- +Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` + +Domain | `Config` name | `Value` +------------------ | ------------- | ------- +Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` + +Domain | `Config` name | `Value` +------------------------ | ----------------- | ------- +Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` + +Domain | `File` name | `Value` +---------------------------- | -------------------------------- | ------- +Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` + +Domain | `File` or `Directorie` name | _State_ +---------------------------- | --------------------------- | ----------------------------- +Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ + +Domain | `File` name | `Value` +-------------------- | --------------------------------- | ------- +Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` + +Domain | `Config` name | `Value` +--------------------- | ----------------- | ------- +Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` + +Domain | `Config` name | `Value` +------------------------ | --------------- | ------- +Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` +Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` + +Domain | `Partition` | `Value` +-------------------------- | ------------------- | ----------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. +Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. + +Domain | `Config` name | _State_ or `Value` +-------------------------- | ----------------------- | ----------------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. + +Domain | `Label` name | Recommendations +------------------ | ------------ | ----------------------------------------------------------- +Kernel-MAC-Floor-1 | `^` | Only for privileged system services. +Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. + +Domain | `Label` name | Recommendations +------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. +Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. +Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. +Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. +Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. + +Domain | `Label` name | Recommendations +------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. +Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. +Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. + +Domain | Object | Recommendations +------------------ | -------------- | ------------------------------------ +Platform-SystemD-1 | Security model | Use Namespaces for containerization. +Platform-SystemD-2 | Security model | Use CGroups to organise processes. + +Domain | Object | Recommendations +--------------- | -------------- | ------------------------------------ +Platform-DBus-1 | Security model | Use D-Bus as IPC. +Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ------- +Platform-Utilities-1 | `connman` | _Used_ as a connection manager. +Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. +Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. +Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. + +Domain | Object | Recommendations +---------------------- | -------------- | -------------------------------- +Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. + +Domain | Object | Recommendations +----------------------- | ----------- | ------------------------------------- +Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ---------------------------------------------------------------------- +Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. + +Domain | `Utility` name and normal `path` | _State_ +--------------------- | ---------------------------------------------------- | ---------- +Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ +Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ +Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ +Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ +Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ +Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ +Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ +Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ +Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ +Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ +Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ +Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ +Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ +Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ +Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ +Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ +Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ +Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ +Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ +Platform-Utilities-22 | `SSH` | _Disabled_ +Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ +Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ +Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ +Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ +Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ +Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ +Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ +Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ +Platform-Utilities-31 | `awk` (busybox) | _Enabled_ +Platform-Utilities-32 | `cut` (busybox) | _Enabled_ +Platform-Utilities-33 | `df` (busybox) | _Enabled_ +Platform-Utilities-34 | `echo` (busybox) | _Enabled_ +Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ +Platform-Utilities-36 | `grep` (busybox) | _Enabled_ +Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ +Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ +Platform-Utilities-39 | `printf` (busybox) | _Enabled_ +Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ +Platform-Utilities-41 | `tail` (busybox) | _Enabled_ +Platform-Utilities-42 | `tee` (busybox) | _Enabled_ +Platform-Utilities-43 | `test` (busybox) | _Enabled_ + +Domain | Object | Recommendations +--------------------- | ---------------- | ----------------------------------------------------- +Platform-Users-root-1 | Main application | Should not execute as root. +Platform-Users-root-2 | UI | Should run in a context on a user with no capability. + +Domain | `Utility` name | _State_ +--------------------- | -------------- | ------------- +Platform-Users-root-3 | `login` | _Not allowed_ +Platform-Users-root-4 | `su` | _Not allowed_ +Platform-Users-root-5 | `ssh` | _Not allowed_ +Platform-Users-root-6 | `scp` | _Not allowed_ +Platform-Users-root-7 | `sftp` | _Not allowed_ + +Domain | Object | Recommendations +-------------------------- | --------- | ----------------------------------------------------------------------- +Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. +Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. + +Domain | Tech name | Recommendations +---------------------------------- | --------- | -------------------------------------------------------------------------- +Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. + +Domain | Tech name | Recommendations +----------------------------------------- | --------- | ---------------------------------------------------------------------- +Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. +Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. +Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. +Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. + +Domain | Object | Recommendations +----------------------- | ------ | ------------------------------------------------------------------ +Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. + +Domain | Tech name or object | Recommendations +---------------------------- | ------------------- | ------------------------------------------------------------------------- +Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled +Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used +Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. +Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. +Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. + +Domain | Tech name | Recommendations +--------------------------------- | ------------- | ------------------------------------------------------------ +Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. +Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring +Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. +Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. +Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. + +Domain | Tech name | Recommendations +-------------------------------- | --------- | -------------------------- +Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid +Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. + +Domain | Tech name | Recommendations +----------------------------- | --------- | -------------------------------------------- +Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. + +Domain | Tech name | Recommendations +--------------------------- | --------- | ------------------------------------------------------ +Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. +Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. + +Domain | Object | Recommendations +---------------------------- | -------------- | -------------------------------------- +Application-Cloud-Download-1 | authentication | Must implement authentication process. +Application-Cloud-Download-2 | Authorization | Must implement Authorization process. + +Domain | Object | Recommendations +---------------------------------- | ------------- | ---------------------------------------------------------- +Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. +Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. +Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. +Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). +Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. + +Domain | Object | Recommendations +----------------------------- | ----------------------------------------- | --------------------------------- +Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. + + diff --git a/docs/security-blueprint/annexes/todoNotes.md b/docs/security-blueprint/annexes/todoNotes.md new file mode 100644 index 0000000..d1d4b6f --- /dev/null +++ b/docs/security-blueprint/annexes/todoNotes.md @@ -0,0 +1,80 @@ +# Todo notes + + +Domain | Improvement +--------------- | ---------------------------------------------------- +Boot-Abstract-1 | More generic and add examples (The chain of trust). + +Domain | Improvement +--------------- | ------------------------------------------- +Boot-Abstract-1 | Review the definition of the "boot loader". + +Domain | Improvement +--------------- | ------------------------------------ +Boot-Consoles-1 | Secure loader: No reference earlier? + +Domain | Improvement +--------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). + +Domain | Improvement +-------------------------------- | ----------------------------- +Kernel-General-IndependentExec-1 | Kernel or/and platform part ? + +Domain | Improvement +------------------------------- | --------------- +Kernel-General-LibraryLinking-1 | Keep this part? + +Domain | Improvement +------------------- | -------------------------------- +Platform-Abstract-1 | Create a graphics and sound part. + +Domain | Improvement +------------------- | ----------- +Platform-Services-1 | SystemD ? +Platform-Services-2 | Secure daemon ? + +Domain | Improvement +----------------------------- | ------------------------ +Platform-Users-Capabilities-1 | Kernel or Platform-user? +Platform-Users-Capabilities-2 | Add config note. + +Domain | Improvement +-------------------------- | ------------------------------ +Application-Installation-1 | Talk about AppFw offline mode. + +Domain | Improvement +----------------------- | ---------------------------------------------------------- +Application-Signature-1 | Add content (see secure build in Secure development part). + +Domain | Improvement +---------------------- | ------------ +Application-Services-1 | Add content (Which services?). +Application-Services-2 | Add Binder. + +Domain | Improvement +----------------------- | ----------------- +Connectivity-Abstract-1 | Improve abstract. + +Domain | Improvement +----------------------- | ------------------------------------------- +Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). + +Domain | Improvement +------------- | ----------------- +Update-SOTA-1 | Part to complete. + +Domain | Improvement +----------------------- | ------------ +SecureDev-SecureBuild-1 | Add content. + +Domain | Improvement +---------------------- | ------------ +SecureDev-Signatures-1 | Add content. + +Domain | Improvement +--------------------- | ----------------------------------------------------- +SecureDev-CodeAudit-1 | Add CVE analyser. +SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). + + diff --git a/docs/security-blueprint/index.md b/docs/security-blueprint/index.md new file mode 100644 index 0000000..1ca88b3 --- /dev/null +++ b/docs/security-blueprint/index.md @@ -0,0 +1,22 @@ +--- + +title : security-blueprint +date : 2017-12-07 +version : 4.99.4 +category: security +tags: security, architecture, automotive, linux +layout: techdoc + +--- + +## [Intro](./intro.html) +## [Hardware](./part-1/0_Abstract.html) +## [Secure Boot](./part-2/0_Abstract.html) +## [Hypervisor](./part-3/0_Abstract.html) +## [Kernel](./part-4/0_Abstract.html) +## [Platform](./part-5/0_Abstract.html) +## [Application](./part-6/0_Abstract.html) +## [Connectivity](./part-7/0_Abstract.html) +## [Update (OTA)](./part-8/0_Abstract.html) +## [Secure development](./part-9/0_Abstract.html) +## [Annexes](./annexes/0_Abstract.html) diff --git a/docs/security-blueprint/part-1/0_Abstract.md b/docs/security-blueprint/part-1/0_Abstract.md new file mode 100644 index 0000000..e13c464 --- /dev/null +++ b/docs/security-blueprint/part-1/0_Abstract.md @@ -0,0 +1,77 @@ +# Part 1 - Hardware + +## Abstract + +The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services. +The platform includes the following hardware: + +- SoC (System-on-Chip). +- Memory (RAM, ROM, storage, etc.). +- Peripherals. + +You will find in this first part everything that concerns the hardware security. +The goal is to protect system against all attacks that are trying to gain +additional privileges by recovering and/or changing cryptographic keys in order +to alter the integrity of the boot. We should also prevent hardware modifications +in order to achieve this goal. We will expose below some examples of possible +configurations. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | -------------------------------------- +_HSM_ | **H**ardware **S**ecurity **M**odule +_NVM_ | **N**on-**V**olatile **M**emory +_SHE_ | **S**ecure **H**ardware **E**xtensions + +-------------------------------------------------------------------------------- + +## Integrity + +The board must store hardcoded cryptographic keys in order to verify among others +the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and **SHE** to +enhance the security of their board. + + + +Domain | Object | Recommendations +-------------------- | ---------- | ---------------------------------- +Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. +Hardware-Integrity-2 | Board | Must use a HSM. +Hardware-Integrity-3 | RTC | Must not be alterable. + + + +-------------------------------------------------------------------------------- + + + +## Certificates + + + +Domain | Object | Recommendations +---------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. +Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. +Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. + + + +-------------------------------------------------------------------------------- + +## Memory + + + +Domain | Object | Recommendations +----------------- | ---------- | ------------------------------------------------------------------------------------ +Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. +Hardware-Memory-2 | Bootloader | Internal NVM only +Hardware-Module-3 | - | HSM must be used to secure keys. + + diff --git a/docs/security-blueprint/part-2/0_Abstract.md b/docs/security-blueprint/part-2/0_Abstract.md new file mode 100644 index 0000000..fa99d89 --- /dev/null +++ b/docs/security-blueprint/part-2/0_Abstract.md @@ -0,0 +1,64 @@ +# Part 2 - Secure boot + +## Abstract + + + +Domain | Improvement +--------------- | ---------------------------------------------------- +Boot-Abstract-1 | More generic and add examples (The chain of trust). + + + +Secure boot refers to preventing malicious software applications and +“unauthorized” operating systems from loading during the system start-up process. +The goal is to protect users from rootkits and other low-level malware attacks. +Modern bootloaders come with features that can be used to enable secure boot in the system. + +**Boot Hardening**: Steps/requirements to configure the boot sequence, in order +to restrict the device from executing anything other than the approved software +image. + +In this part, we will see a series of settings that will allow us to improve +security during boot phase. For the purposes of reference and explanation, we +are providing guidance on how to configure an embedded device that runs with a +3.10.17 Linux kernel. If the integrity is not checked or if a critical error +occurs, the system must boot on a very stable backup image. + +**Requirements**: These requirements must be met even if an alternative version +of the Linux kernel is chosen. + +**Recommendations**: Detailed best practices that should be applied in order to +secure a device. Although they are not currently listed as hard requirements, +they may be upgraded to requirements status in the future. In addition, specific +operators may change some of these recommendations into requirements based on +their specific needs and objectives. + + + +Domain | Improvement +--------------- | ------------------------------------------- +Boot-Abstract-1 | Review the definition of the "boot loader". + + + +**Boot loader**: The boot loader consists of the Primary boot loader residing +in **OTP** memory, sboot, U-Boot and Secure loader residing in external flash +(NAND or SPI/NOR flash memory). The CPU on power on or reset executes the +primary boot loader. The **OTP** primary boot loader makes the necessary initial +system configuration and then loads the secondary boot loader sboot from +external flash memory to ram memory. The sboot then loads the U-Boot along with +the Secure loader. U-Boot then verifies the Kernel/system image integrity, then +loads the Kernel/system image before passing control to it. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | ----------------------------------------------------------------------- +_FUSE_ | **F**ilesystem in **U**ser**S**pac**E** +_OTP_ | **O**ne-**T**ime-**P**rogrammable +_DOCSIS_ | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification diff --git a/docs/security-blueprint/part-2/1-Image.md b/docs/security-blueprint/part-2/1-Image.md new file mode 100644 index 0000000..453b397 --- /dev/null +++ b/docs/security-blueprint/part-2/1-Image.md @@ -0,0 +1,52 @@ +# Image + +## Image selection + +The boot process shall be uninterruptible and shall irrevocably boot the image +as specified in the boot environment. + +In U-Boot set the "_bootdelay_" environment variable and/or define +`CONFIG_BOOTDELAY` to _-2_. + + + +Domain | _Variable_ / `Config` name | `Value` +---------------------- | -------------------------- | ------- +Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` +Boot-Image-Selection-2 | _bootdelay_ | `-2` + + + +-------------------------------------------------------------------------------- + +## Image authenticity + +It shall not be possible to boot from an unverified image. The secure boot +feature in U-Boot shall be enabled. The secure boot feature is available from +U-Boot 2013.07 version. To enable the secure boot feature, enable the following +features: + +``` +CONFIG_FIT: Enables support for Flat Image Tree (FIT) uImage format. +CONFIG_FIT_SIGNATURE: Enables signature verification of FIT images. +CONFIG_RSA: Enables RSA algorithm used for FIT image verification. +CONFIG_OF_CONTROL: Enables Flattened Device Tree (FDT) configuration. +CONFIG_OF_SEPARATE: Enables separate build of u-Boot from the device tree. +CONFIG_DEFAULT_DEVICE_TREE: Specifies the default Device Tree used for the run-time configuration of U-Boot. +``` + +Generate the U-Boot image with public keys to validate and load the image. It +shall use RSA2048 and SHA256 for authentication. + + + +Domain | `Config` name | _State_ +------------------------- | ---------------------------- | -------- +Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ +Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ +Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ +Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ +Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ +Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ + + diff --git a/docs/security-blueprint/part-2/2-Communication-modes.md b/docs/security-blueprint/part-2/2-Communication-modes.md new file mode 100644 index 0000000..268da5d --- /dev/null +++ b/docs/security-blueprint/part-2/2-Communication-modes.md @@ -0,0 +1,89 @@ +# Communication modes + +## Disable USB, Serial and DOCSIS Support + +To disable USB support in U-Boot, following config's shall not be defined: + +``` +CONFIG_CMD_USB: Enables basic USB support and the usb command. +CONFIG_USB_UHCI: Defines the lowlevel part. +CONFIG_USB_KEYBOARD: Enables the USB Keyboard. +CONFIG_USB_STORAGE: Enables the USB storage devices. +CONFIG_USB_HOST_ETHER: Enables USB Ethernet adapter support. +``` + +In addition, disable unnecessary communication modes like Ethernet, Serial +ports, DOCSIS in U-Boot and sboot that are not necessary. + +Linux Kernel support for USB should be compiled-out if not required. If it is +needed, the Linux Kernel should be configured to only enable the minimum +required USB devices. User-initiated USB-filesystems should be treated with +special care. Whether or not the filesystems are mounted in userspace +(**FUSE**), restricted mount options should be observed. + + + +Domain | Communication modes | _State_ +-------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- +Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. +Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. +Boot-Communication-3 | `Ethernet` | _Disabled_ +Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ +Boot-Communication-5 | `Serial ports` | _Disabled_ + + + +Domain | `Config` name | _State_ +------------------------ | ----------------------- | ------------- +Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ +Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ +Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ +Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ +Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ + + + +-------------------------------------------------------------------------------- + +## Disable all unused Network Interfaces + +Only used network interfaces should be enabled. +Where possible, services should also be limited to those necessary. + + + +Domain | Communication modes | _State_ +-------------------- | -------------------- | --------------------------------------------------------------------------------------------- +Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. + + + +## Remove or Disable Unnecessary Services, Ports, and Devices + +Restrict the `services`, `ports` and `devices` to those used. + + + +Domain | Object | Recommendations +-------------------- | --------------------------------- | ------------------------------------------------------------- +Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. + + + +## Disable flash access + +**Recommendation**: + +In U-Boot following flash memory commands shall be disabled: + +**NAND**: Support for nand flash access available through `do_nand` has to be disabled. + + + +Domain | `Command` name | _State_ +-------------------------- | -------------- | --------- +Boot-Communication-Flash-1 | `do_nand` | _Disable_ + + + +Similarly sboot should disable flash access support through command line if any. diff --git a/docs/security-blueprint/part-2/3-Consoles.md b/docs/security-blueprint/part-2/3-Consoles.md new file mode 100644 index 0000000..0a8faed --- /dev/null +++ b/docs/security-blueprint/part-2/3-Consoles.md @@ -0,0 +1,107 @@ +# Consoles + +## Disable serial console + +Serial console output shall be disabled. To disable console output in U-Boot, +set the following macros: + + + +Domain | `Config` name | `Value` +---------------------- | --------------------------------------- | --------- +Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` +Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` +Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` + + + +Domain | Improvement +--------------- | ------------------------------------ +Boot-Consoles-1 | Secure loader: No reference earlier? + + + +And set "**silent**" environment variable. For the Secure loader, +disable the traces by not defining the below macro: + + + +Domain | `Environment variable` name | _State_ +---------------------- | --------------------------- | ------------- +Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ + + + +For sboot proper configuration needs to be done to disable the serial console. + +-------------------------------------------------------------------------------- + + + +## Immutable environment variables + +In U-Boot, ensure Kernel command line, boot commands, boot delay and other +environment variables are immutable. This will prevent side-loading of alternate +images, by restricting the boot selection to only the image in FLASH. + +The environment variables shall be part of the text region in U-Boot as default +environment variable and not in non-volatile memory. + +Remove configuration options related to non-volatile memory, such as: + + + +Domain | `Config` name | _State_ +-------------------------- | ---------------------------- | --------- +Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` +Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` +Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` +Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` +Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` +Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` +Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` +Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` +Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` +Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` +Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` +Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` + + + +-------------------------------------------------------------------------------- + + + +## (Recommendation) Removal of memory dump commands + +In U-Boot, following commands shall be disabled to avoid memory dumps: + +``` +md : Memory Display command. +mm : Memory modify command - auto incrementing address. +nm : Memory modify command - constant address. +mw : Memory write. +cp : Memory copy. +mwc : Memory write cyclic. +mdc : Memory display cyclic. +mtest : Simple ram read/write test. +loopw : Infinite write loop on address range. +``` + + + +Domain | `Command` name | _State_ +----------------------- | -------------- | ---------- +Boot-Consoles-MemDump-1 | `md` | _Disabled_ +Boot-Consoles-MemDump-2 | `mm` | _Disabled_ +Boot-Consoles-MemDump-3 | `nm` | _Disabled_ +Boot-Consoles-MemDump-4 | `mw` | _Disabled_ +Boot-Consoles-MemDump-5 | `cp` | _Disabled_ +Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ +Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ +Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ +Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ + + + +Similarly, memory dump support shall be disabled from sboot. diff --git a/docs/security-blueprint/part-3/0_Abstract.md b/docs/security-blueprint/part-3/0_Abstract.md new file mode 100644 index 0000000..c6e3942 --- /dev/null +++ b/docs/security-blueprint/part-3/0_Abstract.md @@ -0,0 +1,18 @@ +# Part 3 - Hypervisor + +Definition: "A hypervisor or virtual machine monitor (VMM) is computer software, +firmware or hardware that creates and runs virtual machines". + +It must include a signature verification (possibly delegated). + + + +Domain | Improvement +--------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). + + + +## Native or Bare-metal hypervisors + +These hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. Those are the ones we're interested in. diff --git a/docs/security-blueprint/part-4/0_Abstract.md b/docs/security-blueprint/part-4/0_Abstract.md new file mode 100644 index 0000000..01957e4 --- /dev/null +++ b/docs/security-blueprint/part-4/0_Abstract.md @@ -0,0 +1,60 @@ +# Part 4 - Kernel + +## Abstract + +**System Hardening:** Best practices associated with the configuration of an +embedded Linux based operating system. This section includes both hardening of +the kernel itself, as well as specific configurations and patches used to +protect against known vulnerabilities within the build and configuration of the +root filesystem. + +At the Kernel level, we must ensure that no console can be launched. It could be +used to change the behavior of the system or to have more information about it. +Another aspect is the protection of the memory used by the Kernel. + +The next sub-sections contain information on various kernel configuration +options to enhance the security in the kernel (3.10.17) and also for +applications compiled to take advantage of these security features. +Additionally, there are also configuration options that protect from known +vulnerable configuration options. Here's a high level summary of various kernel +configurations that shall be required for deployment. + +## Kernel Version + +The choice of kernel version for the AGL system is essential to its security. +Depending on the type of board and eventual production system, different kernel +versions are used. For example, one of the systems under study uses the +Linux kernel version 3.10, while another uses the Linux kernel version 4.4. +For the Linux kernel version 3.10.31, there are 25 known vulnerabilities. +These vulnerabilities would allow an attacker to gain privileges, +bypass access restrictions, allow memory to be corrupted, or cause denial of service. +In contrast, the Linux kernel version of 4.4 has many fewer known vulnerabilities. +For this reason, we would in general recommend the later kernel version as a basis +for the platform. + +Note that, although there are fewer known vulnerabilities in the most recent kernel +versions there may be many unknown vulnerabilities underlying. +A rule of thumb is to update the kernel as much as possible to avoid the problems +you do know, but you should not be complacent in the trust that you place in it. +A defense-in-depth approach would then apply. + +If there are constraints and dependencies in upgrading to a newer kernel version +(e.g. device drivers, board support providers) and you are forced to an older +Linux kernel version, there need to be additional provisions made to reduce +the risk of kernel exploits, which can include memory monitoring, watch-dog services, +and system call hooking. In this case, further defense-in-depth techniques +may be required to mitigate the risk of attacks to known vulnerabilities, +which can also include runtime integrity verification of components +that are vulnerable to tampering. + +## Kernel Build Configuration + +The kernel build configuration is extremely important for determining the level +of access to services and to reduce the breadth of the attack surface. +Linux contains a great and flexible number of capabilities and this is only controlled +through the build configuration. For example, the `CONFIG_MODULES` parameter +allows kernel modules to be loaded at runtime extending the capabilities of the kernel. +This capability needs to be either inhibited or controlled at runtime through +other configuration parameters. For example, `CONFIG_MODULE_SIG_FORCE=y` ensures +that only signed modules are loaded. There is a very large number of kernel +configuration parameters, and these are discussed in detail in this section. diff --git a/docs/security-blueprint/part-4/1-General.md b/docs/security-blueprint/part-4/1-General.md new file mode 100644 index 0000000..54c7ea8 --- /dev/null +++ b/docs/security-blueprint/part-4/1-General.md @@ -0,0 +1,278 @@ +# General configuration + +## Mandatory Access Control + +Kernel should controls access with labels and policy. + + + +Domain | `Config` name | `Value` +-------------------- | -------------- | -------------------------------------- +Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m +Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m +Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y +Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y +Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y +Kernel-General-MAC-6 | CONFIG_SECURITY | y +Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y +Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y + + + +Please also refer to the [**Mandatory Access Control** documentation in Platform](../part-5/1-MAC.html) part. +You can also find useful documentation and links on wikipedia about [**MAC**](https://en.wikipedia.org/wiki/Mandatory_access_control) +and about [**SMACK**](https://en.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel). + +-------------------------------------------------------------------------------- + +## Disable kexec + +**Kexec** is a system call that enables you to load and boot into another kernel from the currently running kernel. This feature is not required in a production environment. + + + +Domain | `Config` name | `Value` +---------------------- | -------------- | ------- +Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` + + + + + +**kexec** can load arbitrary kernels but signing of new kernel can be enforced like it is can be enforced for new modules. + + + +-------------------------------------------------------------------------------- + +## Disable kernel IP auto-configuration + +It is preferable to have an IP configuration performed using a user-space tool as these tend to have more validation. We do not want the network interface coming up until the system has come up properly. + + + +Domain | `Config` name | `Value` +--------------------------- | --------------- | ------- +Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Sysctl syscall support + +Enabling this will result in code being included that is hard to maintain and not well tested. + + + +Domain | `Config` name | `Value` +------------------------------- | ----------------------- | ------- +Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Legacy Linux Support + +There are some Kernel Configs which are present only to support legacy binaries. See also "Consoles" part in order to disabling support for legacy binary formats. The `uselib` system call, in particular, has no valid use in any `libc6` or `uclibc` system in recent times. This configuration is supported in **Linux 3.15 and greater** and thus should only be disabled for such versions. + + + +Domain | `Config` name | `Value` +---------------------------- | --------------- | ------- +Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable firmware auto-loading user mode helper + +The firmware auto loading helper, which is a utility executed by the kernel on `hotplug` events requiring firmware, can to be set `setuid`. As a result of this, the helper utility is an attractive target for attackers with control of physical ports on the device. Disabling this configuration that is supported in **Linux 3.9 and greater**. + + + +Domain | `Config` name | `Value` +--------------------------- | ------------------------------ | ------- +Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` + + + + + +It doesn't strictly need to be `setuid`, there is an option of shipping firmware builtin into kernel without initrd/filesystem. + + + +-------------------------------------------------------------------------------- + +## Enable Kernel Panic on OOPS + +When fuzzing the kernel or attempting kernel exploits attackers are likely to trigger kernel OOPSes. Setting the behavior on OOPS to PANIC can impede their progress. + +This configuration is supported in **Linux 3.5 and greater** and thus should only be enabled for such versions. + + + +Domain | `Config` name | `Value` +---------------------------- | ---------------------- | ------- +Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` + + + +-------------------------------------------------------------------------------- + + + +## Disable socket monitoring interface + +These monitors can be used to inspect shared file descriptors on Unix Domain sockets or traffic on 'localhost' which is otherwise assumed to be confidential. + +The `CONFIG_PACKET_DIAG` configuration is supported in **Linux 3.7 and greater** and thus should only be disabled for such versions. + +The `CONFIG_UNIX_DIAG` configuration is supported in **Linux 3.3 and greater** and thus should only be disabled for such versions. + + + +Domain | `Config` name | `Value` +-------------------------- | -------------------- | ------- +Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` +Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable BPF JIT + +The BPF JIT can be used to create kernel-payloads from firewall table rules. + +This configuration for is supported in **Linux 3.16 and greater** and thus should only be disabled for such versions. + + + +Domain | `Config` name | `Value` +------------------------ | ---------------- | ------- +Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` + + + +-------------------------------------------------------------------------------- + +## Enable Enforced Module Signing + +The kernel should never allow an unprivileged user the ability to load specific kernel modules, +since that would provide a facility to unexpectedly extend the available attack surface. + +To protect against even privileged users, systems may need to either disable +module loading entirely, or provide signed modules +(e.g. `CONFIG_MODULE_SIG_FORCE`, or dm-crypt with LoadPin), to keep from having +root load arbitrary kernel code via the module loader interface. + +This configuration is supported in **Linux 3.7 and greater** and thus should only be enabled for such versions. + + + +Domain | `Config` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` + + + +It is also possible to block the loading of modules after startup with "kernel.modules_disabled". + + + +Domain | `Variable` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` + + + +-------------------------------------------------------------------------------- + + + +## Disable all USB, PCMCIA (and other `hotplug` bus) drivers that aren't needed + +To reduce the attack surface, the driver enumeration, probe, and operation happen in the kernel. The driver data is parsed by the kernel, so any logic bugs in these drivers can become kernel exploits. + + + +Domain | Object | _State_ +------------------------ | ------------------- | ---------- +Kernel-General-Drivers-1 | `USB` | _Disabled_ +Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ +Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ + + + +-------------------------------------------------------------------------------- + +## Position Independent Executables + + + +Domain | Improvement +-------------------------------- | ----------------------------- +Kernel-General-IndependentExec-1 | Kernel or/and platform part ? + + + + + +Domain | `compiler` and `linker` options | _State_ +-------------------------------- | ------------------------------- | -------- +Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ + + + +Produce a position independent executable on targets which supports it. + +-------------------------------------------------------------------------------- + +## Prevent Overwrite Attacks + +`-z,relro` linking option helps during program load, several ELF memory sections need to be written by the linker, but can be turned read-only before turning over control to the program. This prevents some Global Offset Table GOT overwrite attacks, or in the dtors section of the ELF binary. + + + +Domain | `compiler` and `linker` options | _State_ +--------------------------------- | ------------------------------- | -------- +Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ +Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ + + + +During program load, all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only (due to `-z relro` above). This prevents GOT overwrite attacks. For very large application, this can incur some performance loss during initial load while symbols are resolved, but this shouldn't be an issue for daemons. + +-------------------------------------------------------------------------------- + + + +## Library linking + + + +Domain | Improvement +------------------------------- | --------------- +Kernel-General-LibraryLinking-1 | Keep this part? + + + +It is recommended that dynamic linking should generally not be allowed. This will avoid the user from replacing a library with malicious library. + + + +Domain | Object | Recommendations +------------------------------- | --------------- | -------------------------------- +Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. + + + + + +Linking everything statically doesn't change anything wrt security as binaries will live under same user:group as libraries and setuid executables ignore `LD_PRELOAD/LD_LIBRARY_PATH`. It also increases RSS footprint and creates problems with upgrading. + + diff --git a/docs/security-blueprint/part-4/2-Memory.md b/docs/security-blueprint/part-4/2-Memory.md new file mode 100644 index 0000000..d7af446 --- /dev/null +++ b/docs/security-blueprint/part-4/2-Memory.md @@ -0,0 +1,156 @@ +# Memory + +## Restrict access to kernel memory + +The /dev/kmem file in Linux systems is directly mapped to kernel virtual memory. This can be disastrous if an attacker gains root access, as the attacker would have direct access to kernel virtual memory. + +To disable the /dev/kmem file, which is very infrequently used by applications, the following kernel option should be set in the compile-time kernel configuration: + + + +Domain | `Config` name | `Value` +------------------------------ | ---------------- | ------- +Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` + + + +In case applications in userspace need /dev/kmem support, it should be available only for authenticated applications. + +-------------------------------------------------------------------------------- + +## Disable access to a kernel core dump + +This kernel configuration disables access to a kernel core dump from user space. If enabled, it gives attackers a useful view into kernel memory. + + + +Domain | `Config` name | `Value` +------------------------ | ------------------- | ------- +Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable swap + +If not disabled, attackers can enable swap at runtime, add pressure to the memory subsystem and then scour the pages written to swap for useful information. + + + +Domain | `Config` name | `Value` +-------------------- | ------------- | ------- +Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` + + + + + +- Enabling swap at runtime require `CAP_SYS_ADMIN`. +- Swap block device is usually under root:disk. +- Linux never swaps kernel pages. +- If swap disabling is not possible, swap encryption should be enabled. + + + +-------------------------------------------------------------------------------- + + + +## Disable "Load All Symbols" + +There is a /proc/kallsyms file which exposes the kernel memory space address of many kernel symbols (functions, variables, etc...). This information is useful to attackers in identifying kernel versions/configurations and in preparing payloads for the exploits of kernel space. + +Both `KALLSYMS_ALL` and `KALLSYMS` shall be disabled; + + + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` +Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` + + + +-------------------------------------------------------------------------------- + +## Stack protection + +To prevent stack-smashing, similar to the stack protector used for ELF programs in user-space, the kernel can protect its internal stacks as well. + +This configuration is supported in **Linux 3.11 and greater** and thus should only be enabled for such versions. + +This configuration also requires building the kernel with the **gcc compiler 4.2 or greater**. + + + +Domain | `Config` name | `Value` +--------------------- | -------------------------- | ------- +Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` + + + +Other defenses include things like shadow stacks. + +-------------------------------------------------------------------------------- + +## Disable access to /dev/mem + +The /dev/mem file in Linux systems is directly mapped to physical memory. This can be disastrous if an attacker gains root access, as the attacker would have direct access to physical memory through this convenient device file. It may not always be possible to disable such file, as some applications might need such support. In that case, then this device file should be available only for authenticated applications. + +This configuration is supported in **Linux 4.0 and greater** and thus should only be disabled for such versions. + + + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` + + + +-------------------------------------------------------------------------------- + + + +## Disable cross-memory attach + +Disable the process_vm_*v syscalls which allow one process to peek/poke the virtual memory of another. + +This configuration is supported in **Linux 3.5 and greater** and thus should only be disabled for such versions. + + + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` + + + +-------------------------------------------------------------------------------- + +## Stack Smashing Attacks + + + +Domain | `compiler` and `linker` options | _State_ +----------------------------- | ------------------------------- | -------- +Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ + + + +Emit extra code to check for buffer overflows, such as stack smashing attacks. + +-------------------------------------------------------------------------------- + +## Detect Buffer Overflows + + + +Domain | `compiler` options and `config` name | `Value` +------------------------------- | ------------------------------------ | ------- +Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` +Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` + + + +Helps detect some buffer overflow errors. diff --git a/docs/security-blueprint/part-4/3-Consoles.md b/docs/security-blueprint/part-4/3-Consoles.md new file mode 100644 index 0000000..c6cf80a --- /dev/null +++ b/docs/security-blueprint/part-4/3-Consoles.md @@ -0,0 +1,78 @@ +# Serial + +## Disable serial console + +The serial console should be disabled to prevent an attacker from accessing this powerful interface. + + + +Domain | `Config` name | `Value` +------------------------ | ---------------------------- | ------- +Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` +Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` +Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` +Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` + + + +-------------------------------------------------------------------------------- + +## Bake-in the kernel command-line + +The kernel command-line is used to control many aspects of the booting kernel, and is prone to tampering as they are passed in RAM with little to no reverse validation on these parameters. To prevent this type of attack, the kernel shall be configured to ignore commands line arguments, and use pre-configured (compile time) options instead. + +Set the kernel command line in the `CONFIG_CMDLINE KConfig` item and then pass no arguments from the bootloader. + + + +Domain | `Config` name | `Value` +----------------------------- | ------------------------- | ----------------------------------- +Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` +Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` +Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` + + + +It is recommended that any per-device settings (e.g: MAC addresses, serial numbers, etc.) be stored and accessed from read-only memory (or files), and that any such parameters be verified (signature checking) prior to their use. + +-------------------------------------------------------------------------------- + +## Disable KGDB + +The Linux kernel supports KGDB over USB and console ports. These mechanisms are controlled by the `kgdbdbgp` and `kgdboc` kernel command-line parameters. It is important to ensure that no shipping product contains a kernel with KGDB compiled-in. + + + +Domain | `Config` name | `Value` +---------------------- | ------------- | ------- +Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable magic sysrq support + +On a few architectures, you can access a powerful debugger interface from the keyboard. The same powerful interface can be present on the serial console (responding to serial break) of Linux on other architectures. Disable to avoid potentially exposing this powerful backdoor. + + + +Domain | `Config` name | `Value` +----------------------- | -------------------- | ------- +Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable support for binary formats other than ELF + +This will make possible to plug wrapper-driven binary formats into the kernel. It enables support for binary formats other than ELF. Providing the ability to use alternate interpreters would assist an attacker in discovering attack vectors. + + + +Domain | `Config` name | `Value` +------------------------------ | -------------------- | ------- +Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` + + diff --git a/docs/security-blueprint/part-4/4-Debug.md b/docs/security-blueprint/part-4/4-Debug.md new file mode 100644 index 0000000..cce5fc0 --- /dev/null +++ b/docs/security-blueprint/part-4/4-Debug.md @@ -0,0 +1,208 @@ +# Debug + +No debuggers shall be present on the file system. This includes, but is not limited to, the GNU Debugger client/server (commonly known in their short form names such as the `gdb` and `gdbserver` executable binaries respectively), the `LLDB` next generation debugger or the `TCF` (Target Communications Framework) agnostic framework. Including these binaries as part of the file system will facilitate an attacker's ability to reverse engineer and debug (either locally or remotely) any process that is currently executing on the device. + +## Kernel debug symbols + +Debug symbols should always be removed from production kernels as they provide a lot of information to attackers. + + + +Domain | `Config` name | `Value` +---------------------- | ------------------- | ------- +Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` + + + +These kernel debug symbols are enabled by other config items in the kernel. Care should be taken to disable those also. If `CONFIG_DEBUG_INFO` cannot be disabled, then enabling `CONFIG_DEBUG_INFO_REDUCED` is second best. + + + +At least `CONFIG_DEBUG_INFO_REDUCED` should be always enabled for developers to convert addresses in oops messages to line numbers. + + + +-------------------------------------------------------------------------------- + +## Disable Kprobes + +Kprobes enables you to dynamically break into any kernel routine and collect debugging and performance information non-disruptively. You can trap at almost any kernel code address, specifying a handler routine to be invoked when the breakpoint is hit. + + + +Domain | `Config` name | `Value` +---------------------- | ---------------- | ------- +Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Tracing + +FTrace enables the kernel to trace every kernel function. Providing kernel trace functionality would assist an attacker in discovering attack vectors. + + + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Profiling + +Profiling and OProfile enables profiling the whole system, include the kernel, kernel modules, libraries, and applications. Providing profiling functionality would assist an attacker in discovering attack vectors. + + + +Domain | `Config` name | `Value` +------------------------ | ------------------ | ------- +Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` +Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable OOPS print on BUG() + +The output from OOPS print can be helpful in Return Oriented Programming (ROP) when trying to determine the effectiveness of an exploit. + + + +Domain | `Config` name | `Value` +------------------------ | ------------------------- | ------- +Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Kernel Debugging + +There are development-only branches of code in the kernel enabled by the `DEBUG_KERNEL` conf. This should be disabled to compile-out these branches. + + + +Domain | `Config` name | `Value` +------------------ | --------------------- | ------- +Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` +Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` + + + +In some kernel versions, disabling this requires also disabling `CONFIG_EMBEDDED`, and `CONFIG_EXPERT`. Disabling `CONFIG_EXPERT` makes it impossible to disable `COREDUMP`, `DEBUG_BUGVERBOSE`, `NAMESPACES`, `KALLSYMS` and `BUG`. In which case it is better to leave this enabled than enable the others. + +-------------------------------------------------------------------------------- + + + +## Disable the kernel debug filesystem + +The kernel debug filesystem presents a lot of useful information and means of manipulation of the kernel to an attacker. + + + +Domain | `Config` name | `Value` +------------------------- | ----------------- | ------- +Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable BUG() support + +The kernel will display backtrace and register information for BUGs and WARNs in kernel space, making it easier for attackers to develop exploits. + + + +Domain | `Config` name | `Value` +------------------ | ------------- | ------- +Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable core dumps + +Core dumps provide a lot of debug information for hackers. So disabling core dumps are recommended in production builds. + +This configuration is supported in **Linux 3.7 and greater** and thus should only be disabled for such versions. + + + +Domain | `Config` name | `Value` +------------------------ | ----------------- | ------- +Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` + + + +-------------------------------------------------------------------------------- + + + +## Kernel Address Display Restriction + +When attackers try to develop "run anywhere" exploits for kernel vulnerabilities, they frequently need to know the location of internal kernel structures. By treating kernel addresses as sensitive information, those locations are not visible to regular local users. + +**/proc/sys/kernel/kptr_restrict is set to "1"** to block the reporting of known kernel address leaks. + + + +Domain | `File` name | `Value` +---------------------------- | -------------------------------- | ------- +Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` + + + +Additionally, various files and directories should be readable only by the root user: `/boot/vmlinuz*`, `/boot/System.map*`, `/sys/kernel/debug/`, `/proc/slabinfo` + + + +Domain | `File` or `Directorie` name | _State_ +---------------------------- | --------------------------- | ----------------------------- +Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ + + + +-------------------------------------------------------------------------------- + +## DMESG Restrictions + +When attackers try to develop "run anywhere" exploits for vulnerabilities, they frequently will use `dmesg` output. By treating `dmesg` output as sensitive information, this output is not available to the attacker. + +**/proc/sys/kernel/dmesg_restrict can be set to "1"** to treat dmesg output as sensitive. + + + +Domain | `File` name | `Value` +-------------------- | --------------------------------- | ------- +Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` + + + +Enable the below compiler and linker options when building user-space applications to avoid stack smashing, buffer overflow attacks. + +-------------------------------------------------------------------------------- + + + +## Disable /proc/config.gz + +It is extremely important to not expose the kernel configuration used on a production device to a potential attacker. With access to the kernel config, it could be possible for an attacker to build a custom kernel for the device that may disable critical security features. + + + +Domain | `Config` name | `Value` +--------------------- | ----------------- | ------- +Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` + + diff --git a/docs/security-blueprint/part-4/5-FileSystems.md b/docs/security-blueprint/part-4/5-FileSystems.md new file mode 100644 index 0000000..78f2050 --- /dev/null +++ b/docs/security-blueprint/part-4/5-FileSystems.md @@ -0,0 +1,60 @@ +# File System + +## Disable all file systems not needed + +To reduce the attack surface, file system data is parsed by the kernel, so any logic bugs in file system drivers can become kernel exploits. + +### Disable NFS file system + +NFS FileSystems are useful during development phases, but this can be a very helpful way for an attacker to get files when you are in production mode, so we must disable them. + + + +Domain | `Config` name | `Value` +------------------------ | --------------- | ------- +Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` +Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` + + + +-------------------------------------------------------------------------------- + + + +## Partition Mount Options + +There are several security restrictions that can be set on a filesystem when it is mounted. Some common security options include, but are not limited to: + +`nosuid` - Do not allow set-user-identifier or set-group-identifier bits to take effect. + +`nodev` - Do not interpret character or block special devices on the filesystem. + +`noexec` - Do not allow execution of any binaries on the mounted filesystem. + +`ro` - Mount filesystem as read-only. + +The following flags shall be used for mounting common filesystems: + + + +Domain | `Partition` | `Value` +-------------------------- | ------------------- | ----------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. +Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. + + + +If `CONFIG_DEVTMPFS_MOUNT` is set, then the kernel will mount /dev and will not apply the `nosuid`, `noexec` options. Either disable `CONFIG_DEVTMPFS_MOUNT` or add a remount with `noexec` and `nosuid` options to system startup. + + + +Domain | `Config` name | _State_ or `Value` +-------------------------- | ----------------------- | ----------------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. + + diff --git a/docs/security-blueprint/part-5/0_Abstract.md b/docs/security-blueprint/part-5/0_Abstract.md new file mode 100644 index 0000000..ddf7d2a --- /dev/null +++ b/docs/security-blueprint/part-5/0_Abstract.md @@ -0,0 +1,103 @@ +# Part 5 - Platform + +## Abstract + +The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services. +The platform includes the following software: + +- Linux **BSP** configured for reference boards. +- Proprietary device drivers for common peripherals on reference boards. +- Application framework. +- Windows/layer management (graphics). +- Sound resource management. +- An atomic software update system (chapter Update). +- Building and debug tools (based on Yocto project). + + + +Domain | Improvement +------------------- | -------------------------------- +Platform-Abstract-1 | Create a graphics and sound part. + + + +This part focuses on the AGL platform including all tools and techniques used to +upgrade the security and downgrade the danger. It must be possible to apply the +two fundamental principles written at the very beginning of the document. First +of all, security management must remain simple. You must also prohibit +everything by default, and then define a set of authorization rules. As cases +to deal with, we must: + +- Implement a **MAC** for processes and files. +- Limit communication between applications (_SystemBus_ and _SystemD_ part). +- Prohibit all tools used during development mode (_Utilities_ and _Services_ part). +- Manage user capabilities (_Users_ part). +- Manage application permissions and policies (_AGLFw_ part). + + + +The tools and concepts used to meet these needs are only examples. +Any other tool that meets the need can be used. + + + +In AGL, as in many other embedded systems, different security mechanisms settle +in the core layers to ensure isolation and data privacy. While the Mandatory +Access Control layer (**SMACK**) provides global security and isolation, other +mechanisms like **Cynara** are required to check application's permissions at +runtime. Applicative permissions (also called "_privileges_") may vary depending +on the user and the application being run: an application should have access to +a given service only if it is run by the proper user and if the appropriate +permissions are granted. + +## Discretionary Access Control + +**D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux method of separating +users and groups from one another. In a shared environment where multiple users +have access to a computer or network, Unix IDs have offered a way to contain access +within privilege areas for individuals, or shared among the group or system. +The Android system took this one step further, assigning new user IDs for each App. +This was never the original intention of Linux UIDs, but was able to provide +Android’s initial security element: the ability to sandbox applications. + +Although AGL mentions use of **DAC** for security isolation, the weight of the +security responsibility lies in the **M**andatory **A**ccess **C**ontrol (**MAC**) and **Cynara**. +Furthermore, there are system services with unique UIDs. however,the system +does not go to the extreme of Android, where every application has its own UID. +All sandboxing (app isolation) in AGL is handled in the **MAC** contexts. + +## Mandatory Access Control + +**M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**, +whereby extended attributes (xattr) are associated with the filesystem. +In the case of AGL, the smackfs filesystem allows files and directories +to be associated with a SMACK label, providing the ability of further +discrimination on access control. A SMACK label is a simple null terminated +character string with a maximum of 255 bytes. While it doesn’t offer the +richness of an SELinux label, which provides a user, role,type, and level, +the simplicity of a single value makes the overall design far less complex. +There is arguably less chance of the security author making mistakes in the policies set forth. + +-------------------------------------------------------------------------------- + + + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | -------------------------------------------------------------- +_ACL_ | **A**ccess **C**ontrol **L**ists +_alsa_ | **A**dvanced **L**inux **S**ound **A**rchitecture +_API_ | **A**pplication **P**rogramming **I**nterface +_AppFw_ | **App**lication **F**rame**w**ork +_BSP_ | **B**oard **S**upport **P**ackage +_Cap_ | **Cap**abilities +_DAC_ | **D**iscretionary **A**ccess **C**ontrol +_DDOS_ | **D**istributed **D**enial **O**f **S**ervice +_DOS_ | **D**enial **O**f **S**ervice +_IPC_ | **I**nter-**P**rocess **C**ommunication +_MAC_ | **M**andatory **A**ccess **C**ontrol +_PAM_ | **P**luggable **A**uthentication **M**odules +_SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel diff --git a/docs/security-blueprint/part-5/1-MAC.md b/docs/security-blueprint/part-5/1-MAC.md new file mode 100644 index 0000000..73543e9 --- /dev/null +++ b/docs/security-blueprint/part-5/1-MAC.md @@ -0,0 +1,165 @@ +# Mandatory Access Control + + + +We decided to put the **MAC** protection on the platform part despite the fact +that it applies to the kernel too, since its use will be mainly at the platform +level (except floor part). + + + +**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the +Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL +uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol +**K**ernel (**SMACK**). This protection involves the creation of **SMACK** +labels as part of the extended attributes **SMACK** labels to the file extended +attributes. And a policy is also created to define the behaviour of each label. + +The kernel access controls is based on these labels and this policy. If there +is no rule, no access will be granted and as a consequence, what is not +explicitly authorized is forbidden. + +There are two types of **SMACK** labels: + +- **Execution SMACK** (Attached to the process): Defines how files are + _accessed_ and _created_ by that process. +- **File Access SMACK** (Written to the extended attribute of the file): Defines + _which_ process can access the file. + +By default a process executes with its File Access **SMACK** label unless an +Execution **SMACK** label is defined. + +AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System +into the following domains: + +- Floor. +- System. +- Applications, Services and User. + +See [AGL security framework review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) and [Smack White Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf) +for more information. + +-------------------------------------------------------------------------------- + + + +## Floor + +The _floor_ domain includes the base system services and any associated data and +libraries. This data remains unchanged at runtime. Writing to floor files or +directories is allowed only in development mode or during software installation +or upgrade. + +The following table details the _floor_ domain: + +Label | Name | Execution **SMACK** | File Access **SMACK** +----- | ----- | ------------------- | --------------------------------------- +`-` | Floor | `r-x` for all | Only kernel and internal kernel thread. +`^` | Hat | `---` for all | `rx` on all domains. +`*` | Star | `rwx` for all | None + + + +- The Hat label is Only for privileged system services (currently only + systemd-journal). Useful for backup or virus scans. No file with this label + should exist except in the debug log. + +- The Star label is used for device files or `/tmp` Access restriction managed + via **DAC**. Individual files remain protected by their **SMACK** label. + + + +Domain | `Label` name | Recommendations +------------------ | ------------ | ----------------------------------------------------------- +Kernel-MAC-Floor-1 | `^` | Only for privileged system services. +Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. + + + +-------------------------------------------------------------------------------- + + + +## System + +The _system_ domain includes a reduced set of core system services of the OS and +any associated data. This data may change at runtime. + +The following table details the _system_ domain: + +Label | Name | Execution **SMACK** | File Access **SMACK** +---------------- | --------- | ----------------------------------------------- | --------------------- +`System` | System | None | Privileged processes +`System::Run` | Run | `rwxatl` for User and System label | None +`System::Shared` | Shared | `rwxatl` for system domain `r-x` for User label | None +`System::Log` | Log | `rwa` for System label `xa` for user label | None +`System::Sub` | SubSystem | Subsystem Config files | SubSystem only + + + +Domain | `Label` name | Recommendations +------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. +Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. +Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. +Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. +Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. + + + +-------------------------------------------------------------------------------- + + + +## Applications, Services and User + +The _application_, _services_ and _user_ domain includes code that provides +services to the system and user, as well as any associated data. All code +running on this domain is under _Cynara_ control. + +The following table details the _application_, _services_ and _user_ domain: + +Label | Name | Execution **SMACK** | File Access **SMACK** +------------------- | ------ | --------------------------------------------------------------------------- | --------------------------- +`User::Pkg::$AppID` | AppID | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App +`User::Home` | Home | `rwx-t` from System label `r-x-l` from App | None +`User::App-Shared` | Shared | `rwxat` from System and User domains label of $User | None + + + +Domain | `Label` name | Recommendations +------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. +Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. +Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. + + + +## Attack Vectors + +There are 4 major components to the system: + +- The LSM kernel module. +- The `smackfs` filesystem. +- Basic utilities for policy management and checking. +- The policy/configuration data. + +As with any mandatory access system, the policy management needs to be carefully separated +from the checking, as the management utilities can become a convenient point of attack. +Dynamic additions to the policy system need to be carefully verified, as the ability to +update the policies is often needed, but introduces a possible threat. Finally, +even if the policy management is well secured, the policy checking and failure response +to that checking is also of vital importance to the smooth operation of the system. + +While **MAC** is a certainly a step up in security when compared to DAC, there are still +many ways to compromise a SMACK-enabled Linux system. Some of these ways are as follows: + +- Disabling SMACK at invocation of the kernel (with command-line: security=none). +- Disabling SMACK in the kernel build and redeploying the kernel. +- Changing a SMACK attribute of a file or directory at install time. +- Tampering with a process with the CAP_MAC_ADMIN privilege. +- Setting/Re-setting the SMACK label of a file. +- Tampering with the default domains (i.e. /etc/smack/accesses.d/default-access-domains). +- Disabling or tampering with the SMACK filesystem (i.e. /smackfs). +- Adding policies with `smackload` (adding the utility if not present). +- Changing labels with `chsmack` (adding the utility if not present). diff --git a/docs/security-blueprint/part-5/2-SystemD.md b/docs/security-blueprint/part-5/2-SystemD.md new file mode 100644 index 0000000..35abe16 --- /dev/null +++ b/docs/security-blueprint/part-5/2-SystemD.md @@ -0,0 +1,60 @@ +# SystemD + +`afm-system-daemon` is used to: + +- Manage users and user sessions. +- Setup applications and services (_CGroups_, _namespaces_, autostart, permissions). +- Use of `libsystemd` for its programs (event management, **D-Bus** interface). + + + +Domain | Object | Recommendations +------------------ | -------------- | ------------------------------------ +Platform-SystemD-1 | Security model | Use Namespaces for containerization. +Platform-SystemD-2 | Security model | Use CGroups to organise processes. + + + +See [systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for more information. + +## Benefits + +- Removal of one privileged process: **afm-user-daemon** +- Access and use of high level features: + + - Socket activation. + - Management of users and integration of **PAM**. + - Dependency resolution to services. + - `Cgroups` and resource control. + - `Namespaces` containerization. + - Autostart of required API. + - Permissions and security settings. + - Network management. + + + +## CGroups + +Control Groups offer a lot of features, with the most useful ones you can +control: Memory usage, how much CPU time is allocated, how much device I/O is +allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise +processes (each service is a _CGroups_, and all processes started by that +service use that _CGroups_). By default, **SystemD** automatically creates a +hierarchy of slice, scope and service units to provide a unified structure for +the _CGroups_ tree. With the `systemctl` command, you can further modify this +structure by creating custom slices. Currently, in AGL, there are 2 slices +(**user.slice** and **system.slice**). + +## Namespaces + +### User side + +There are several ways of authenticating users (Key Radio Frequency, Phone, +Gesture, ...). Each authentication provides dynamic allocation of **uids** to +authenticated users. **Uids** is used to ensure privacy of users and **SMACK** +for applications privacy. + +First, the user initiates authentication with **PAM** activation. **PAM** +Standard offers highly configurable authentication with modular design like +face recognition, Voice identification or with a password. Then users should +access identity services with services and applications. diff --git a/docs/security-blueprint/part-5/3-SystemBus.md b/docs/security-blueprint/part-5/3-SystemBus.md new file mode 100644 index 0000000..e2af387 --- /dev/null +++ b/docs/security-blueprint/part-5/3-SystemBus.md @@ -0,0 +1,24 @@ +# D-Bus + +D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and +daemon) that helps applications to talk to each other. The use of D-Bus is great +because it allows to implement discovery and signaling. + +The D-Bus session is by default addressed by environment variable +`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable `DBUS_SESSION_BUS_ADDRESS` +is automatically set for user sessions. D-Bus usage is linked to permissions. + +D-Bus has already had several [security issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) +(mostly **DoS** issues), to allow applications to keep talking to each other. +It is important to protect against this type of attack to keep the system more +stable. + + + + +Domain | Object | Recommendations +--------------- | -------------- | ------------------------------------ +Platform-DBus-1 | Security model | Use D-Bus as IPC. +Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) + + diff --git a/docs/security-blueprint/part-5/4-Services.md b/docs/security-blueprint/part-5/4-Services.md new file mode 100644 index 0000000..013f693 --- /dev/null +++ b/docs/security-blueprint/part-5/4-Services.md @@ -0,0 +1,37 @@ +# System services and daemons + + + +Domain | Improvement +------------------- | ----------- +Platform-Services-1 | SystemD ? +Platform-Services-2 | Secure daemon ? + + + +## Tools + +- **connman**: An internet connection manager designed to be slim and to use as + few resources as possible. It is a fully modular system that can be extended, + through plug-ins, to support all kinds of wired or wireless technologies. +- **bluez** is a Bluetooth stack. Its goal is to program an implementation of + the Bluetooth wireless standards specifications. In addition to the basic stack, + the `bluez-utils` and `bluez-firmware` packages contain low level utilities such + as `dfutool` which can interrogate the Bluetooth adapter chipset in order to + determine whether its firmware can be upgraded. +- **gstreamer** is a pipeline-based multimedia framework. It can be used to build + a system that reads files in one format, processes them, and exports them in + another format. +- **alsa** is a software framework and part of the Linux kernel that provides an + **API** for sound card device drivers. + + + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ------- +Platform-Utilities-1 | `connman` | _Used_ as a connection manager. +Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. +Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. +Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. + + diff --git a/docs/security-blueprint/part-5/5-AppFw.md b/docs/security-blueprint/part-5/5-AppFw.md new file mode 100644 index 0000000..e92a0c6 --- /dev/null +++ b/docs/security-blueprint/part-5/5-AppFw.md @@ -0,0 +1,315 @@ +# Application framework/model (**AppFw**) + +The AGL application framework consists of several inter-working parts: + +- **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) that performs extended access control of the system. +- **Cynara**: the native gatekeeper daemon used for policy handling, updating to the database and policy checking. +- Security Manager: a master service, through which all security events are intended to take place. +- Several native application framework utilities: `afm-main-binding`, `afm-user-daemon`, `afm-system-daemon`. + +The application framework manages: + +- The applications and services management: Installing, Uninstalling, Listing, ... +- The life cycle of applications: Start -> (Pause, Resume) -> Stop. +- Events and signals propagation. +- Privileges granting and checking. +- API for interaction with applications. + + + +- The **security model** refers to the security model used to ensure security + and to the tools that are provided for implementing that model. It's an + implementation detail that should not impact the layers above the application + framework. + +- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess **C**ontrol), + **MAC** (Mandatory Access Control) and `Capabilities` are used by the system to + ensure security and privacy. It also includes features of reporting using + audit features and by managing logs and alerts. + + + +The **AppFw** uses the security model to ensure the security and the privacy of +the applications that it manages. It must be compliant with the underlying +security model. But it should hide it to the applications. + + + +Domain | Object | Recommendations +---------------------- | -------------- | -------------------------------- +Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. + + + +See [AGL AppFw Privileges Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) and [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) for more +information. + + + +The Security Manager communicates policy information to **Cynara**, +which retains information in its own database in the format of a text +file with comma-separated values (CSV). There are provisions to retain +a copy of the CSV text file when the file is being updated. + +Runtime checking occurs through **Cynara**. Each application that is +added to the framework has its own instantiation of a SMACK context +and D-bus bindings. The afb_daemon and Binder form a web-service that +is communicated to through http or a websocket from the application-proper. +This http or websocket interface uses a standard unique web token for API communication. + +![Application Framework Flow](App-flow.png) + +## Cynara + +There's a need for another mechanism responsible for checking applicative +permissions: Currently in AGL, this task depends on a policy-checker service +(**Cynara**). + +- Stores complex policies in databases. +- "Soft" security (access is checked by the framework). + +Cynara interact with **D-Bus** in order to deliver this information. + +Cynara consists of several parts: + +- Cynara: a daemon for controlling policies and responding to access control requests. +- Database: a spot to hold policies. +- Libraries: several static and dynamic libraries for communicating with Cynara. + +The daemon communicates to the libraries over Unix domain sockets. +The database storage format is a series of CSV-like files with an index file. + +There are several ways that an attacker can manipulate policies of the Cynara system: + +- Disable Cynara by killing the process. +- Tamper with the Cynara binary on-disk or in-memory. +- Corrupt the database controlled by Cynara. +- Tamper with the database controlled by Cynara. +- Highjack the communication between Cynara and the database. + +The text-based database is the weakest part of the system and although there are some +consistency mechanisms in place (i.e. the backup guard), these mechanisms are weak at best +and can be countered by an attacker very easily. + + + +Domain | Object | Recommendations +----------------------- | ----------- | ------------------------------------- +Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. + + + +### Policies + +- Policy rules: + + - Are simple - for pair [application context, privilege] there is straight + answer (single Policy Type): [ALLOW / DENY / ...]. + - No code is executed (no script). + - Can be easily cached and managed. + +- Application context (describes id of the user and the application credentials) + It is build of: + + - UID of the user that runs the application. + - **SMACK** label of application. + +## Holding policies + +Policies are kept in buckets. Buckets are set of policies which have additional +a property of default answer, the default answer is yielded if no policy matches +searched key. Buckets have names which might be used in policies (for directions). + +## Attack Vectors + +The following attack vectors are not completely independent. While attackers may +have varying levels of access to an AGL system, experience has shown that a typical +attack can start with direct access to a system, find the vulnerabilities, +then proceed to automate the attack such that it can be invoked from less accessible +standpoint (e.g. remotely). Therefore, it is important to assess all threat levels, +and protect the system appropriately understanding that direct access attacks +are the door-way into remote attacks. + +### Remote Attacks + +The local web server interface used for applications is the first point of attack, +as web service APIs are well understood and easily intercepted. The local web server +could potentially be exploited by redirecting web requests through the local service +and exploiting the APIs. While there is the use of a security token on the web +service API, this is weak textual matching at best. This will not be difficult to spoof. +It is well known that [API Keys do not provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/). + +It is likely that the architectural inclusion of an http / web-service interface +provided the most flexibility for applications to be written natively or in HTML5. +However, this flexibility may trade-off with security concerns. For example, +if a native application were linked directly to the underlying framework services, +there would be fewer concerns over remote attacks coming through the web-service interface. + +Leaving the interface as designed, mitigations to attacks could include further +securing the interface layer with cryptographic protocols: +e.g. encrypted information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). + +### User-level Native Attacks + +- Modifying the CSV data-base +- Modifying the SQLite DB +- Tampering with the user-level binaries +- Tampering with the user daemons +- Spoofing the D-bus Interface +- Adding executables/libraries + +With direct access to the device, there are many security concerns on the native level. +For example, as **Cynara** uses a text file data-base with comma-separated values (CSV), +an attacker could simply modify the data-base to escalate privileges of an application. +Once a single application has all the privileges possible on the system, exploits can +come through in this manner. Similarly the SQLite database used by the Security Manager +is not much different than a simple text file. There are many tools available to add, +remove, modify entries in an SQLite data-base. + +On the next level, a common point of attack is to modify binaries or daemons for exploiting +functionality. There are many Linux tools available to aid in this regard, +including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml), +and [radare2](https://rada.re/r/). With the ability to modify binaries, +an attacker can do any number of activities including: removing calls to security checks, +redirecting control to bypass verification functionality, ignoring security policy handling, +escalating privileges, etc. + +Additionally, another attack vector would be to spoof the D-bus interface. D-bus is a +message passing system built upon Inter-Process Communication (IPC), where structured +messages are passed based upon a protocol. The interface is generic and well documented. +Therefore, modifying or adding binaries/libraries to spoof this interface is a relatively +straight-forward process. Once the interface has been spoofed, the attacker can issue any +number of commands that lead into control of low-level functionality. + +Protecting a system from native attacks requires a methodical approach. First, the system +should reject processes that are not sanctioned to run. Signature-level verification at +installation time will help in this regard, but run-time integrity verification is much better. +Signatures need to originate from authorized parties, which is discussed further +in a later section on the Application Store. + +On the next level, executables should not be allowed to do things where they have not been +granted permission. DAC and SMACK policies can help in this regard. On the other hand, +there remain concerns with memory accesses, system calls, and other process activity +that may go undetected. For this reason, a secure environment which monitors all activity +can give indication of all unauthorized activity on the system. + +Finally, it is very difficult to catch attacks of direct tampering in a system. +These types of attacks require a defense-in-depth approach, where complementary software +protection and hardening techniques are needed. Tamper-resistance and anti-reverse-engineering +technologies include program transformations/obfuscation, integrity verification, +and white-box cryptography. If applied in a mutually-dependent fashion and considering +performance/security tradeoffs, the approach can provide an effective barrier +to direct attacks to the system. Furthermore, the use of threat monitoring provides a +valuable telemetry/analytics capability and the ability to react and renew a system under attack. + +### Root-level Native Attacks + +- Tampering the system daemon +- Tampering Cynara +- Tampering the security manager +- Disabling SMACK +- Tampering the kernel + +Once root-level access (i.e. su) has been achieved on the device, there are many ways +to compromise the system. The system daemon, **Cynara**, and the security manager are +vulnerable to tampering attacks. For example, an executable can be modified in memory +to jam a branch, jump to an address, or disregard a check. This can be as simple as replacing +a branch instruction with a NOP, changing a memory value, or using a debugger (e.g. gdb, IDA) +to change an instruction. Tampering these executables would mean that policies can be +ignored and verification checks can be bypassed. + +Without going so far as to tamper an executable, the **SMACK** system is also vulnerable to attack. +For example, if the kernel is stopped and restarted with the *security=none* flag, +then SMACK is not enabled. Furthermore, `systemd` starts the loading of **SMACK** rules during +start-up. If this start-up process is interfered with, then **SMACK** will not run. +Alternatively, new policies can be added with `smackload` allowing unforseen privileges +to alternative applications/executables. + +Another intrusion on the kernel level is to rebuild the kernel (as it is open-source) +and replace it with a copy that has **SMACK** disabled, or even just the **SMACK** filesystem +(`smackfs`) disabled. Without the extended label attributes, the **SMACK** system is disabled. + +Root-level access to the device has ultimate power, where the entire system can be compromised. +More so, a system with this level access allows an attacker to craft a simpler *point-attack* +which can operate on a level requiring fewer privileges (e.g. remote access, user-level access). + +## Vulnerable Resources + +### Resource: `afm-user-daemon` + +The `afm-user-daemon` is in charge of handling applications on behalf of a user. Its main tasks are: + +- Enumerate applications that the end user can run and keep this list available on demand. +- Start applications on behalf of the end user, set user running environment, set user security context. +- List current runnable or running applications. +- Stop (aka pause), continue (aka resume), terminate a running instance of a given application. +- Transfer requests for installation/uninstallation of applications to the corresponding system daemon afm-system-daemon. + +The `afm-user-daemon` launches applications. It builds a secure environment for the application +before starting it within that environment. Different kinds of applications can be launched, +based on a configuration file that describes how to launch an application of a given kind within +a given launching mode: local or remote. Launching an application locally means that +the application and its binder are launched together. Launching an application remotely +translates in only launching the application binder. + +The UI by itself has to be activated remotely by a request (i.e. HTML5 homescreen in a browser). +Once launched, running instances of the application receive a `runid` that identifies them. +`afm-user-daemon` manages the list of applications that it has launched. +When owning the right permissions, a client can get the list of running instances and details +about a specific running instance. It can also terminate, stop or continue a given application. +If the client owns the right permissions, `afm-user-daemon` delegates the task of +installing and uninstalling applications to `afm-system-daemon`. + +`afm-user-daemon` is launched as a `systemd` service attached to a user session. +Normally, the service file is located at /usr/lib/systemd/user/afm-user-daemon.service. + +Attacker goals: + +- Disable `afm-user-daemon`. +- Tamper with the `afm-user-daemon` configuration. + - /usr/lib/systemd/user/afm-user-daemon.service. + - Application(widget) config.xml file. + - /etc/afm/afm-launch.conf (launcher configuration). + +- Escalate user privileges to gain more access with `afm-user-daemon`. +- Install malicious application (widget). +- Tamper with `afm-user-daemon` on disk or in memory. + +### Resource: `afm-system-daemon` + +The `afm-system-daemon` is in charge of installing applications on the AGL system. Its main tasks are: + +- Install applications and setup security framework for newly installed applications. +- Uninstall applications. + +`afm-system-daemon` is launched as a `systemd` service attached to system. Normally, +the service file is located at /lib/systemd/system/afm-systemdaemon.service. + +Attacker goals: + +- Disable `afm-system-daemon`. +- Tamper with the `afm-system-daemon` configuration. +- Tamper `afm-system-daemon` on disk or in memory. + +### Resource `afb-daemon` + +`afb-binder` is in charge of serving resources and features through an HTTP interface. +`afb-daemon` is in charge of binding one instance of an application to the AGL framework +and AGL system. The application and its companion binder run in a secured and isolated +environment set for them. Applications are intended to access to AGL system through the binder. +`afb-daemon` binders serve files through HTTP protocol and offers developers the capability +to expose application API methods through HTTP or WebSocket protocol. + +Binder bindings are used to add APIs to `afb-daemon`. The user can write a binding for `afb-daemon`. +The binder `afb-daemon` serves multiple purposes: + +1. It acts as a gateway for the application to access the system. +2. It acts as an HTTP server for serving files to HTML5 applications. +3. It allows HTML5 applications to have native extensions subject to security enforcement for accessing hardware resources or for speeding up parts of algorithm. + +Attacker goals: + +- Break from isolation. +- Disable `afb-daemon`. +- Tamper `afb-demon` on disk or in memory. +- Tamper **capabilities** by creating/installing custom bindings for `afb-daemon`. \ No newline at end of file diff --git a/docs/security-blueprint/part-5/6-Utilities.md b/docs/security-blueprint/part-5/6-Utilities.md new file mode 100644 index 0000000..309cbc4 --- /dev/null +++ b/docs/security-blueprint/part-5/6-Utilities.md @@ -0,0 +1,78 @@ +# Utilities + +- **busybox**: Software that provides several stripped-down Unix tools in a + single executable file. Of course, it will be necessary to use a "production" + version of **busybox** in order to avoid all the tools useful only in + development mode. + + + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ---------------------------------------------------------------------- +Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. + + + +## Functionalities to exclude in production mode + +In production mode, a number of tools must be disabled to prevent an attacker +from finding logs for example. This is useful to limit the visible surface and +thus complicate the fault finding process. The tools used only in development +mode are marked by an '**agl-devel**' feature. When building in production mode, +these tools will not be compiled. + + + +Domain | `Utility` name and normal `path` | _State_ +--------------------- | ---------------------------------------------------- | ---------- +Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ +Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ +Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ +Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ +Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ +Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ +Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ +Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ +Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ +Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ +Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ +Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ +Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ +Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ +Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ +Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ +Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ +Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ +Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ +Platform-Utilities-22 | `SSH` | _Disabled_ +Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ +Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ +Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ +Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ +Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ +Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ +Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ +Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ +Platform-Utilities-31 | `awk` (busybox) | _Enabled_ +Platform-Utilities-32 | `cut` (busybox) | _Enabled_ +Platform-Utilities-33 | `df` (busybox) | _Enabled_ +Platform-Utilities-34 | `echo` (busybox) | _Enabled_ +Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ +Platform-Utilities-36 | `grep` (busybox) | _Enabled_ +Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ +Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ +Platform-Utilities-39 | `printf` (busybox) | _Enabled_ +Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ +Platform-Utilities-41 | `tail` (busybox) | _Enabled_ +Platform-Utilities-42 | `tee` (busybox) | _Enabled_ +Platform-Utilities-43 | `test` (busybox) | _Enabled_ + + + +The _Enabled_ Unix/Linux utilities above shall be permitted as they are often +used in the start-up scripts and for USB logging. If any of these utilities are +not required by the device then those should be removed. + + diff --git a/docs/security-blueprint/part-5/7-Users.md b/docs/security-blueprint/part-5/7-Users.md new file mode 100644 index 0000000..af5a686 --- /dev/null +++ b/docs/security-blueprint/part-5/7-Users.md @@ -0,0 +1,77 @@ +# Users + +The user policy can group users by function within the car. For example, we can +consider a driver and his passengers. Each user is assigned to a single group to +simplify the management of space security. + +## Root Access + +The main applications, those that provide the principal functionality of the +embedded device, should not execute with root identity or any capability. + +If the main application is allowed to execute at any capability, then the entire +system is at the mercy of the said application's good behaviour. Problems arise +when an application is compromised and able to execute commands which could +consistently and persistently compromise the system by implanting rogue +applications. + +It is suggested that the middleware and the UI should run in a context on a user +with no capability and all persistent resources should be maintained without any +capability. + +One way to ensure this is by implementing a server-client paradigm. Services +provided by the system's drivers can be shared this way. The other advantage of +this approach is that multiple applications can share the same resources at the +same time. + + + +Domain | Object | Recommendations +--------------------- | ---------------- | ----------------------------------------------------- +Platform-Users-root-1 | Main application | Should not execute as root. +Platform-Users-root-2 | UI | Should run in a context on a user with no capability. + + + +Root access should not be allowed for the following utilities: + + + +Domain | `Utility` name | _State_ +--------------------- | -------------- | ------------- +Platform-Users-root-3 | `login` | _Not allowed_ +Platform-Users-root-4 | `su` | _Not allowed_ +Platform-Users-root-5 | `ssh` | _Not allowed_ +Platform-Users-root-6 | `scp` | _Not allowed_ +Platform-Users-root-7 | `sftp` | _Not allowed_ + + + +Root access should not be allowed for the console device. The development +environment should allow users to login with pre-created user accounts. + +Switching to elevated privileges shall be allowed in the development environment +via `sudo`. + +-------------------------------------------------------------------------------- + + + +## Capabilities + + + +Domain | Improvement +----------------------------- | ------------------------ +Platform-Users-Capabilities-1 | Kernel or Platform-user? +Platform-Users-Capabilities-2 | Add config note. + + + +The goal is to restrict functionality that will not be useful in **AGL**. They +are integrated into the **LSM**. Each privileged transaction is associated with +a capability. These capabilities are divided into three groups: + +- e: Effective: This means the capability is “activated”. +- p: Permitted: This means the capability can be used/is allowed. +- i: Inherited: The capability is kept by child/subprocesses upon execve() for example. diff --git a/docs/security-blueprint/part-5/App-flow.png b/docs/security-blueprint/part-5/App-flow.png new file mode 100644 index 0000000..7b87c29 Binary files /dev/null and b/docs/security-blueprint/part-5/App-flow.png differ diff --git a/docs/security-blueprint/part-6/0_Abstract.md b/docs/security-blueprint/part-6/0_Abstract.md new file mode 100644 index 0000000..3617dbd --- /dev/null +++ b/docs/security-blueprint/part-6/0_Abstract.md @@ -0,0 +1,80 @@ +# Part 6 - Application + +## Abstract + +**Application Hardening**: Best practices to apply to the build and release of +user space applications, in order to reduce the number of attack surfaces used +by potential attackers. + +The term of Application (App) has a very wide definition in **AGL**. Almost +anything which is not in the core Operating System (OS) is an Application. +Applications can be included in the base software package (image) or can be +added at run-time. + +Application containment is achieved using the following protections: + +- Linux Native protection + - Mandatory Access Control (**MAC**) +- AGL Platform protections + - Origin Tracking and Validation + - Application Privilege Management and Enforcement via Cynara + - Authenticated Transport via D-Bus + +## Application Types + +AGL provides a framework for applications to be written in different forms: + +- Web application: HTML5 + JavaScript +- Qt application: in a QML file +- Native application: in C + +While there is no harm in providing multiple types of applications, from a +security perspective this does increase the attack surface for an intruder. +The application framework (**AppFw**) consists of a number of utilities and +daemons which provide context for the applications. +Isolation is provided through **SMACK** labels. + +## Application Store + +Although the Tizen system has defined a [system of App signing and signing flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates) +to avoid the spread of unauthorized Apps that might contain malware. +At this point, it is unclear how much of this flow AGL will adopt. +However, judging from the experience, it is an essential topic. For example, +the Google Play Store controls the authorization of Apps through signing, and still, +there are [many accounts of Apps containing malware on the store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play). + +Tizen defines 5 levels of certificates and signing at each level, including an author, +testing distributor, public level store distributor, partner level store distributor, +and platform level store distributor. AGL may define a different number of third parties, +but at a minimum an author and store distributor should be defined. + +![App Signing Flow](App_signing_flow.png) + +Once the number of signatures has been established, verification of those signatures needs +to be done at a minimum at installation time on the AGL device. It is important to ensure +the robustness/integrity of the public key used for signature verification. If the public key is modified, +then this compromised key can be used to verify an attacker's private key signature. + +Further to this, installation-time verification is limited. Attacks can happen to apps in-memory +at runtime. Any modifications made after installation will be missed by installation-time verification. +Integrity verification that runs during execution makes for a more complete security story. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | ---------------------------------------------------- +_3GPP_ | **3**rd **G**eneration **P**artnership **P**roject +_CASB_ | **C**loud **A**ccess **S**ecurity **B**roker +_DAST_ | **D**ynamic **A**pplication **S**ecurity **T**esting +_DPI_ | **D**eep **P**acket **I**nspection +_IDS_ | **I**ntrusion **D**etection **S**ystems +_IPS_ | **I**ntrusion **P**revention **S**ystems +_IPSec_ | **I**nternet **P**rotocol **Sec**urity +_LSM_ | **L**inux **S**ecurity **M**odule +_MITM_ | **M**an **I**n **T**he **M**iddle +_OSI_ | **O**pen **S**ystems **I**nterconnection +_SATS_ | **S**tatic **A**pplication **S**ecurity **T**esting diff --git a/docs/security-blueprint/part-6/1-Installation.md b/docs/security-blueprint/part-6/1-Installation.md new file mode 100644 index 0000000..e2972ce --- /dev/null +++ b/docs/security-blueprint/part-6/1-Installation.md @@ -0,0 +1,29 @@ +# Local + + + +Domain | Improvement +-------------------------- | ------------------------------ +Application-Installation-1 | Talk about AppFw offline mode. + + + +## Installation + +Applications can be delivered and installed with the base image using a special +offline-mode provided by the **AppFw**. Apps can also be installed at run time. + + + +During early release, default Apps are installed on the image at first boot. + + + + + +Domain | Object | Recommendations +-------------------------- | --------- | ----------------------------------------------------------------------- +Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. +Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. + + diff --git a/docs/security-blueprint/part-6/2-PrivilegeManagement.md b/docs/security-blueprint/part-6/2-PrivilegeManagement.md new file mode 100644 index 0000000..2f2455a --- /dev/null +++ b/docs/security-blueprint/part-6/2-PrivilegeManagement.md @@ -0,0 +1,7 @@ +# Local + +## Privilege Management + +Application privileges are managed by **Cynara** and the security manager in +the **AppFw**. For more details, please refer to the **AppFw** documentation +in Platform part. diff --git a/docs/security-blueprint/part-6/3-Signature.md b/docs/security-blueprint/part-6/3-Signature.md new file mode 100644 index 0000000..f7b48db --- /dev/null +++ b/docs/security-blueprint/part-6/3-Signature.md @@ -0,0 +1,9 @@ +# App Signature + + + +Domain | Improvement +----------------------- | ---------------------------------------------------------- +Application-Signature-1 | Add content (see secure build in Secure development part). + + diff --git a/docs/security-blueprint/part-6/4-Services.md b/docs/security-blueprint/part-6/4-Services.md new file mode 100644 index 0000000..d0414f0 --- /dev/null +++ b/docs/security-blueprint/part-6/4-Services.md @@ -0,0 +1,10 @@ +# Services + + + +Domain | Improvement +---------------------- | ------------ +Application-Services-1 | Add content (Which services?). +Application-Services-2 | Add Binder. + + diff --git a/docs/security-blueprint/part-6/App_signing_flow.png b/docs/security-blueprint/part-6/App_signing_flow.png new file mode 100644 index 0000000..56a7c23 Binary files /dev/null and b/docs/security-blueprint/part-6/App_signing_flow.png differ diff --git a/docs/security-blueprint/part-7/0_Abstract.md b/docs/security-blueprint/part-7/0_Abstract.md new file mode 100644 index 0000000..f7acbe5 --- /dev/null +++ b/docs/security-blueprint/part-7/0_Abstract.md @@ -0,0 +1,52 @@ +# Part 7 - Connectivity + +## Abstract + +This part shows different Connectivity attacks on the car. + + + +Domain | Improvement +----------------------- | ----------------- +Connectivity-Abstract-1 | Improve abstract. + + + +-------------------------------------------------------------------------------- + + + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | --------------------------------------------------------------------------------- +_ARP_ | **A**ddress **R**esolution **P**rotocol +_BLE_ | **B**luetooth **L**ow **E**nergy +_CAN_ | **C**ar **A**rea **N**etwork +_CCMP_ | **C**ounter-Mode/**C**BC-**M**ac **P**rotocol +_EDGE_ | **E**nhanced **D**ata **R**ates for **GSM** **E**volution - Evolution of **GPRS** +_GEA_ | **G**PRS **E**ncryption **A**lgorithm +_GPRS_ | **G**eneral **P**acket **R**adio **S**ervice (2,5G, 2G+) +_GSM_ | **G**lobal **S**ystem for **M**obile Communications (2G) +_HSPA_ | **H**igh **S**peed **P**acket **A**ccess (3G+) +_IMEI_ | **I**nternational **M**obile **E**quipment **I**dentity +_LIN_ | **L**ocal **I**nterconnect **N**etwork +_MOST_ | **M**edia **O**riented **S**ystem **T**ransport +_NFC_ | **N**ear **F**ield **C**ommunication +_OBD_ | **O**n-**B**oard **D**iagnostics +_PATS_ | **P**assive **A**nti-**T**heft **S**ystem +_PKE_ | **P**assive **K**eyless **E**ntry +_PSK_ | **P**hase-**S**hift **K**eying +_RDS_ | **R**adio **D**ata **S**ystem +_RFID_ | **R**adio **F**requency **I**dentification +_RKE_ | **R**emote **K**eyless **E**ntry +_SDR_ | **S**oftware **D**efined **R**adio +_SSP_ | **S**ecure **S**imple **P**airing +_TKIP_ | **T**emporal **K**ey **I**ntegrity **P**rotocol +_TPMS_ | **T**ire **P**ressure **M**onitoring **S**ystem +_UMTS_ | **U**niversal **M**obile **T**elecommunications **S**ystem (3G) +_USB_ | **U**niversal **S**erial **B**us +_WEP_ | **W**ired **E**quivalent **P**rivacy +_WPA_ | **W**ifi **P**rotected **A**ccess diff --git a/docs/security-blueprint/part-7/1-BusAndConnectors.md b/docs/security-blueprint/part-7/1-BusAndConnectors.md new file mode 100644 index 0000000..5ab9ab8 --- /dev/null +++ b/docs/security-blueprint/part-7/1-BusAndConnectors.md @@ -0,0 +1,68 @@ +# Bus + +We only speak about the **CAN** bus to take an example, because the different +attacks on bus like _FlewRay_, _ByteFlight_, _Most_ and _Lin_ use retro +engineering and the main argument to improve their security is to encrypt data +packets. We just describe them a bit: + +- **CAN**: Controller Area Network, developed in the early 1980s, is an + event-triggered controller network for serial communication with data rates + up to one MBit/s. **CAN** messages are classified over their respective + identifier. **CAN** controller broadcast their messages to all connected nodes + and all receiving nodes decide independently if they process the message. +- **FlewRay**: Is a deterministic and error-tolerant high-speed bus. With a data + rate up to 10 MBit/s. +- **ByteFlight**: Is used for safety-critical applications in motor vehicles + like air-bags. Byteflight runs at 10Mbps over 2 or 3 wires plastic optical + fibers. +- **Most**: Media Oriented System Transport, is used for transmitting audio, + video, voice, and control data via fiber optic cables. The speed is, for the + synchronous way, up to 24 MBit/s and asynchronous way up to 14 MBit/s. + **MOST** messages include always a clear sender and receiver address. +- **LIN**: Local Interconnect Network, is a single-wire subnet work for + low-cost, serial communication between smart sensors and actuators with + typical data rates up to 20 kBit/s. It is intended to be used from the year + 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN** + network is not required. + +On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits) +communicate over a CAN bus, which is a two-wire bus using hardware arbitration +for messages sent on the shared medium. This is essentially a *trusted* network +where all traffic is visible to all controllers and any controller can send any message. + +A malicious **ECU** on the CAN bus can easily inject messages destined for any +other device, including things like the instrument cluster and the head unit. +There are common ways for hardware to do USB to CAN and open source software to send +and receive messages. For example, there is a driver included in the Linux kernel +that can be used to send/receive CAN signals. A malicious device on the CAN bus can +cause a great number of harmful things to happen to the system, including: sending +bogus information to other devices, sending unintended commands to ECUs, +causing DOS (Denial Of Service) on the CAN bus, etc. + + + +Domain | Tech name | Recommendations +---------------------------------- | --------- | -------------------------------------------------------------------------- +Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. + + + +See [Security in Automotive Bus Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf) for more information. + +# Connectors + +For the connectors, we supposed that they were disabled by default. For example, +the **USB** must be disabled to avoid attacks like BadUSB. If not, configure the +Kernel to only enable the minimum require **USB** devices. The connectors used +to diagnose the car like **OBD-II** must be disabled outside garages. + + + +Domain | Tech name | Recommendations +----------------------------------------- | --------- | ---------------------------------------------------------------------- +Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. +Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. +Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. +Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. + + diff --git a/docs/security-blueprint/part-7/2-Wireless.md b/docs/security-blueprint/part-7/2-Wireless.md new file mode 100644 index 0000000..d3fda8b --- /dev/null +++ b/docs/security-blueprint/part-7/2-Wireless.md @@ -0,0 +1,244 @@ +# Wireless + +In this part, we talk about possible remote attacks on a car, according to the +different areas of possible attacks. For each communication channels, we +describe attacks and how to prevent them with some recommendations. The main +recommendation is to always follow the latest updates of these remote +communication channels. + + + +Domain | Object | Recommendations +----------------------- | ------ | ------------------------------------------------------------------ +Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. + + + +We will see the following parts: + +- [Wifi](#wifi) + +- [Bluetooth](#bluetooth) + +- [Cellular](#cellular) + +- [Radio](#radio) + +- [NFC](#nfc) + + + +Domain | Improvement +----------------------- | ------------------------------------------- +Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). + + + +-------------------------------------------------------------------------------- + +For existing automotive-specific means, we take examples of existing system +attacks from the _IOActive_ document ([A Survey of Remote Automotive Attack Surfaces](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf)) +and from the ETH document ([Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf)). + +- [Telematics](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A40%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) + +- [Passive Anti-Theft System (PATS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A11%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C574%2C0%5D) + +- [Tire Pressure Monitoring System (TPMS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A17%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) + +- [Remote Keyless Entry/Start (RKE)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A26%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) + +- [Passive Keyless Entry (PKE)](https://eprint.iacr.org/2010/332.pdf) + +-------------------------------------------------------------------------------- + + + +## Wifi + +### Attacks + +We can differentiate existing attacks on wifi in two categories: Those on +**WEP** and those on **WPA**. + +- **WEP** attacks: + + - **FMS**: (**F**luhrer, **M**antin and **S**hamir attack) is a "Stream cipher + attack on the widely used RC4 stream cipher. The attack allows an attacker + to recover the key in an RC4 encrypted stream from a large number of + messages in that stream." + - **KoreK**: "Allows the attacker to reduce the key space". + - **PTW**: (**P**yshkin **T**ews **W**einmann attack). + - **Chopchop**: Found by KoreK, "Weakness of the CRC32 checksum and the lack + of replay protection." + - **Fragmentation** + +- **WPA** attacks: + + - **Beck and Tews**: Exploit weakness in **TKIP**. "Allow the attacker to + decrypt **ARP** packets and to inject traffic into a network, even + allowing him to perform a **DoS** or an **ARP** poisoning". + - [KRACK](https://github.com/kristate/krackinfo): (K)ey (R)einstallation + (A)tta(ck) ([jira AGL SPEC-1017](https://jira.automotivelinux.org/browse/SPEC-1017)). + +### Recommendations + +- Do not use **WEP**, **PSK** and **TKIP**. + +- Use **WPA2** with **CCMP**. + +- Should protect data sniffing. + + + +Domain | Tech name or object | Recommendations +---------------------------- | ------------------- | ------------------------------------------------------------------------- +Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled +Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used +Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. +Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. +Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. + + + +See [Wifi attacks WEP WPA](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf) +and [Breaking wep and wpa (Beck and Tews)](https://dl.aircrack-ng.org/breakingwepandwpa.pdf) +for more information. + +-------------------------------------------------------------------------------- + + + +## Bluetooth + +### Attacks + +- **Bluesnarfing** attacks involve an attacker covertly gaining access to your + Bluetooth-enabled device for the purpose of retrieving information, including + addresses, calendar information or even the device's **I**nternational + **M**obile **E**quipment **I**dentity. With the **IMEI**, an attacker could + route your incoming calls to his cell phone. +- **Bluebugging** is a form of Bluetooth attack often caused by a lack of + awareness. Similar to bluesnarfing, bluebugging accesses and uses all phone + features but is limited by the transmitting power of class 2 Bluetooth radios, + normally capping its range at 10-15 meters. +- **Bluejacking** is the sending of unsolicited messages. +- **BLE**: **B**luetooth **L**ow **E**nergy [attacks](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf). +- **DoS**: Drain a device's battery or temporarily paralyze the phone. + +### Recommendations + +- Not allowing Bluetooth pairing attempts without the driver's first manually + placing the vehicle in pairing mode. +- Monitoring. +- Use **BLE** with caution. +- For v2.1 and later devices using **S**ecure **S**imple **P**airing (**SSP**), + avoid using the "Just Works" association model. The device must verify that + an authenticated link key was generated during pairing. + + + +Domain | Tech name | Recommendations +--------------------------------- | ------------- | ------------------------------------------------------------ +Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. +Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring +Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. +Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. +Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. + + + +See [Low energy and the automotive transformation](http://www.ti.com/lit/wp/sway008/sway008.pdf), +[Gattacking Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf), +[Comprehensive Experimental Analyses of Automotive Attack Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf) +and [With Low Energy comes Low Security](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf) +for more information. + +-------------------------------------------------------------------------------- + + + +## Cellular + +### Attacks + +- **IMSI-Catcher**: Is a telephone eavesdropping device used for intercepting + mobile phone traffic and tracking location data of mobile phone users. + Essentially a "fake" mobile tower acting between the target mobile phone and + the service provider's real towers, it is considered a man-in-the-middle + (**MITM**) attack. + +- Lack of mutual authentication (**GPRS**/**EDGE**) and encryption with **GEA0**. + +- **Fall back** from **UMTS**/**HSPA** to **GPRS**/**EDGE** (Jamming against + **UMTS**/**HSPA**). + +- 4G **DoS** attack. + +### Recommendations + +- Check antenna legitimacy. + + + +Domain | Tech name | Recommendations +-------------------------------- | --------- | -------------------------- +Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid +Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. + + + +See [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf) +for more information. + +-------------------------------------------------------------------------------- + +## Radio + +### Attacks + +- Interception of data with low cost material (**SDR** with hijacked DVB-T/DAB + for example). + +### Recommendations + +- Use the **R**adio **D**ata **S**ystem (**RDS**) only to send signals for audio + output and meta concerning radio. + + + +Domain | Tech name | Recommendations +----------------------------- | --------- | -------------------------------------------- +Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. + + + +-------------------------------------------------------------------------------- + + + +## NFC + +### Attacks + +- **MITM**: Relay and replay attack. + +### Recommendations + +- Should implements protection against relay and replay attacks (Tokens, etc...). +- Disable unneeded and unapproved services and profiles. +- NFC should be use encrypted link (secure channel). A standard key agreement + protocol like Diffie-Hellmann based on RSA or Elliptic Curves could be applied + to establish a shared secret between two devices. +- Automotive NFC device should be certified by NFC forum entity: The NFC Forum + Certification Mark shows that products meet global interoperability standards. +- NFC Modified Miller coding is preferred over NFC Manchester coding. + + + +Domain | Tech name | Recommendations +--------------------------- | --------- | ------------------------------------------------------ +Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. +Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. + + diff --git a/docs/security-blueprint/part-7/3-Cloud.md b/docs/security-blueprint/part-7/3-Cloud.md new file mode 100644 index 0000000..ec7edea --- /dev/null +++ b/docs/security-blueprint/part-7/3-Cloud.md @@ -0,0 +1,107 @@ +# Cloud + +## Download + +- **authentication**: Authentication is the security process that validates the + claimed identity of a device, entity or person, relying on one or more + characteristics bound to that device, entity or person. + +- **Authorization**: Parses the network to allow access to some or all network +functionality by providing rules and allowing access or denying access based +on a subscriber's profile and services purchased. + + + +Domain | Object | Recommendations +---------------------------- | -------------- | -------------------------------------- +Application-Cloud-Download-1 | authentication | Must implement authentication process. +Application-Cloud-Download-2 | Authorization | Must implement Authorization process. + + + +-------------------------------------------------------------------------------- + +## Infrastructure + +- **Deep Packet Inspection**: **DPI** provides techniques to analyze the payload + of each packet, adding an extra layer of security. **DPI** can detect and + neutralize attacks that would be missed by other security mechanisms. + +- A **DoS** protection in order to avoid that the Infrastructure is no more + accessible for a period of time. + +- **Scanning tools** such as **SATS** and **DAST** assessments perform + vulnerability scans on the source code and data flows on web applications. + Many of these scanning tools run different security tests that stress + applications under certain attack scenarios to discover security issues. + +- **IDS & IPS**: **IDS** detect and log inappropriate, incorrect, or anomalous + activity. **IDS** can be located in the telecommunications networks and/or + within the host server or computer. Telecommunications carriers build + intrusion detection capability in all network connections to routers and + servers, as well as offering it as a service to enterprise customers. Once + **IDS** systems have identified an attack, **IPS** ensures that malicious + packets are blocked before they cause any harm to backend systems and + networks. **IDS** typically functions via one or more of three systems: + + 1. Pattern matching. + 2. Anomaly detection. + 3. Protocol behavior. + + + + + +Domain | Object | Recommendations +---------------------------------- | ------------- | ---------------------------------------------------------- +Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. +Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. +Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. +Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). +Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. + + + +-------------------------------------------------------------------------------- + +## Transport + +For data transport, it is necessary to **encrypt data end-to-end**. To prevent **MITM** attacks, +no third party should be able to interpret transported data. Another aspect +is the data anonymization in order to protect the leakage of private information +on the user or any other third party. + +The use of standards such as **IPSec** provides "_private and secure +communications over IP networks, through the use of cryptographic security +services, is a set of protocols using algorithms to transport secure data over +an IP network._". In addition, **IPSec** operates at the network layer of the +**OSI** model, contrary to previous standards that operate at the application +layer. This makes its application independent and means that users do not need +to configure each application to **IPSec** standards. + +**IPSec** provides the services below : + +- Confidentiality: A service that makes it impossible to interpret data if it is + not the recipient. It is the encryption function that provides this service by + transforming intelligible (unencrypted) data into unintelligible (encrypted) + data. +- Authentication: A service that ensures that a piece of data comes from where + it is supposed to come from. +- Integrity: A service that consists in ensuring that data has not been tampered + with accidentally or fraudulently. +- Replay Protection: A service that prevents attacks by re-sending a valid + intercepted packet to the network for the same authorization. + This service is provided by the presence of a sequence number. +- Key management: Mechanism for negotiating the length of encryption keys + between two **IPSec** elements and exchange of these keys. + +An additional means of protection would be to do the monitoring between users +and the cloud as a **CASB** will provide. + + + +Domain | Object | Recommendations +----------------------------- | ----------------------------------------- | --------------------------------- +Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. + + diff --git a/docs/security-blueprint/part-8/0_Abstract.md b/docs/security-blueprint/part-8/0_Abstract.md new file mode 100644 index 0000000..e438e65 --- /dev/null +++ b/docs/security-blueprint/part-8/0_Abstract.md @@ -0,0 +1,76 @@ +# Part 8 - Update (**OTA**) + +## Abstract + +Updating applications and firmware is essential for the development of new +features and even more to fix security bugs. +However, if a malicious third party manages to alter the content during +transport, it could +alter the functioning of the system and/or applications. The security of the +updates is therefore a critical point to evaluate in order to guarantee the +integrity, the confidentiality and the legitimacy of the transmitted data. + +## Attack Vectors + +Updates Over The Air are one of the most common points where an attacker +will penetrate. An OTA update mechanism is one of the highest threats in the system. +If an attacker is able to install his own application or firmware on the system, +he can get the same level of access that the original application or firmware had. +From that point, the intruder can get unfettered access to the rest of the system, +which might include making modifications, downloading other pieces of software, +and stealing assets. + +### Man In The Middle (MITM) + +The man-in-the-middle attack is the most classic example of an attack, where an adversary +inserts himself between two communicating entities and grabs whatever is being communicated. +In the case of OTA attacks, the connection in the network may be intercepted: + +* On the internet, before the cloud back-end. +* At the base station, 3G,4G,5G connection to the internet. +* At the receiving antenna, connection to the car. +* Between the receiving antenna and the gateway router (if present), connection within the car. +* Between the gateway router and the target component (IVI, In-Vehicle Infotainment unit). + +There are many ways to mount a MITM attack. For example, proxy tools like Burp Proxy can +be used to intercept web traffic as a man-in-the-middle. Under the guise of being a testing tool, +the proxy server is often used in attack scenarios. It runs on a variety of platforms. + +As another example, false base station attacks are known to be fairly easy to set-up. +The problem is apparently fairly prevalent in countries like China and in the UK. +These fake base stations are sometimes just eavesdropping on the communication, +but others have the potential to do serious harm. + +Defenses against MITM attacks include encrypted and signed data pipes. Furthermore, +architects and developers are also recommended to encrypt and sign the payloads that are +being passed over these pipes, to defend against perusal of the data. + +### Man At The End (MATE) + +The man-at-the-end attack is when an intruder analyzes the end-point of the communication when +software is accessing the data communication. This is a more severe attack type where the attacker can: + +* Steal keys. + * For example, a simple debugging session in running software could reveal a key used in memory. +* Tamper software. + * For example, replacing just one function call in software with a NOP (i.e. no operation) can drastically change the behavior of the program. +* Jam branches of control. + * For example, making a program take one branch of control rather than the intended branch can mean the difference between an authorized and a non-authorized installation. +* Modify important data. + * For example, if the data changed is a key or data leading to a control path, then this attack can be severe. + * In the case of OTA updates, MATE attacks are particularly problematic for the system. One of the consequences of MATE attacks can be installed software that allows installation of any other software. For example, an attacker might install remote access software to control any part of the system. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | ------------------------------------------------------------------------- +_FOTA_ | **F**irmware **O**ver **T**he **A**ir +_MATE_ | **M**an **A**t **T**he **E**nd +_MITM_ | **M**an **I**n **T**he **M**iddle +_OTA_ | **O**ver **T**he **A**ir +_SOTA_ | **S**oftware **O**ver **T**he **A**ir +_TUF_ | **T**he **U**pdate **F**ramework diff --git a/docs/security-blueprint/part-8/1-FOTA.md b/docs/security-blueprint/part-8/1-FOTA.md new file mode 100644 index 0000000..3d7f58e --- /dev/null +++ b/docs/security-blueprint/part-8/1-FOTA.md @@ -0,0 +1,41 @@ +# Firmware Over The Air + +The firmware update is critical since its alteration back to compromise the +entire system. It is therefore necessary to take appropriate protective measures. + +AGL includes the _meta-updater_ Yocto layer that enables OTA software +updates via [Uptane](https://uptane.github.io), an automotive-specific extension +to [The Update Framework](https://theupdateframework.github.io/). Uptane and TUF +are open standards that define a secure protocol for delivering and verifying +updates even when the servers and network--internet and car-internal--aren't fully trusted. + +_meta-updater_ includes the application [`aktualizr`](https://github.com/advancedtelematic/aktualizr), +developed Advanced Telematic Systems (now part of HERE Technologies) that enables +OTA for an ECU. `aktualizr` combined with Uptane is suitable for updating the +firmware, software, and other packages on even functionally critical ECUs. +`aktualizr` can be enabled with the free, open souce backend +[`ota-community-edition`](https://github.com/advancedtelematic/ota-community-edition). + +This FOTA update mechanism can be enabled through the `agl-sota` feature. + +## Building + +To build an AGL image that uses `aktualizr`, the following can be used. + +``` +source meta-agl/scripts/aglsetup.sh -m agl-sota +``` + +During the build, _meta-updater_ will use credentials downloaded from `ota-community-edition` +to sign metadata verifying the build as authentic. These signatures are part of the Uptane +framework and are used to verify FOTA updates. + +## Atomic Upgrades with Rollbacks + +`aktualizr`'s primary method of updating firmware is to use `libostree` with binary diffs. +The binary diffs use the least amout of bandwidth, and by it's nature `libostree` stores +current and previous firmware versions on disk or in flash memory to allow for rollbacks. + +`libostree` is a content addressable object store much like `git`. Versions are specified +via SHA2-256. These hashes are signed in the Uptane metadata and are robust against +cryptographic compromise. diff --git a/docs/security-blueprint/part-8/2-SOTA.md b/docs/security-blueprint/part-8/2-SOTA.md new file mode 100644 index 0000000..57df6fc --- /dev/null +++ b/docs/security-blueprint/part-8/2-SOTA.md @@ -0,0 +1,20 @@ +# Software Over The Air + +Software updates in connected vehicles are a very useful feature, which can +deliver significant benefits. If not implemented with security in mind, +software updates can incur serious vulnerabilities. Any software update system +must ensure that not only are the software updates to devices done in a secure way, +but also that the repositories and servers hosting these updates are adequately +protected. As the process of updating software migrates from a Dealership update model +towards an **OTA** update model, securing these processes becomes a high priority. + +**SOTA** is made possible by **AppFw** (See Platform part). It will be possible +to manage in a simple way the packets (i.g. Android like). + + + +Domain | Improvement +------------- | ----------------- +Update-SOTA-1 | Part to complete. + + diff --git a/docs/security-blueprint/part-9/0_Abstract.md b/docs/security-blueprint/part-9/0_Abstract.md new file mode 100644 index 0000000..25d3f35 --- /dev/null +++ b/docs/security-blueprint/part-9/0_Abstract.md @@ -0,0 +1,62 @@ +# Part 9 - Secure development + +In order to save a lot of time in code auditing, developers must follow coding guidelines. + +## Secure build + +### Kernel build + +Tools like: + +- [Code optimisation](https://github.com/jduck/lk-reducer). +- [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf). + + + +Domain | Improvement +----------------------- | ------------ +SecureDev-SecureBuild-1 | Add content. + + + +## App/Widget signatures + + + +Domain | Improvement +---------------------- | ------------ +SecureDev-Signatures-1 | Add content. + + + +## Code audit + +These tools are used to check the correct implementation of functionalities and +compliance with related good practices. + +- [Continuous Code Quality](https://www.sonarqube.org/). + + + +Domain | Improvement +--------------------- | ----------------------------------------------------- +SecureDev-CodeAudit-1 | Add CVE analyser. +SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). + + + +### SATS + +- [RATS](https://github.com/andrew-d/rough-auditing-tool-for-security) (Maybe to old). +- [Flaw Finder](https://www.dwheeler.com/flawfinder/). + +- [wiki list](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis). + +- [Mathematical approach](https://perso.univ-rennes1.fr/david.lubicz/planches/David_Pichardie.pdf). + +It is necessary to verify that the application code does not use functions that +are depreciated and recognized as unsecured or cause problems. + +### DATS + +- [wiki list](https://en.wikipedia.org/wiki/Dynamic_program_analysis#Example_tools). diff --git a/docs/signaling/architecture.md b/docs/signaling/architecture.md new file mode 100644 index 0000000..823a6d2 --- /dev/null +++ b/docs/signaling/architecture.md @@ -0,0 +1,467 @@ +--- +title: AGL - Message Signaling Architecture +author: Fulup Ar Foll (IoT.bzh) +date: 2016-06-30 + +categories: architecture, appfw +tags: architecture, signal, message +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +## Context + +Automotive applications need to understand in real time the context in which +vehicles operate. In order to do so, it is critical for automotive application +to rely on a simple, fast and secure method to access data generated by the +multiple sensors/ECU embedded in modern cars. + +This signaling problem is neither new, neither unique to the automotive and +multiple solutions often described as Message Broker or Signaling Gateway have +been around for a while. + +The present document is the now implemented since AGL Daring Dab version, to +handle existing signaling/message in a car. It relies on [[APbinder]] +binder/bindings model to minimize complexity while keeping the system fast +around secure. We propose a model with multiple transport options and a full set +of security feature to protect the service generating the signal as well as +consuming them. + +## Objectives + +Our objectives are solving following 3 key issues: + +1. reduce as much as possible the amount of exchanged data to the meaningful + subset really used by applications +1. offer a high level API that obfuscates low level and proprietary interface to + improve stability in time of the code +1. hide specificities of low level implementation as well as the chosen + deployment distribution model. + +To reach first objective, events emission frequency should be controlled at the +lowest level it possibly can. Aggregation, composition, treatment, filtering of +signals should be supported at software level when not supported by the hardware. + +Second objectives of offering long term stable hight level API while allowing +flexibility in changing low level implementation may look somehow conflicting. +Nevertheless by isolating low level interface from high level and allowing +dynamic composition it is possible to mitigate both objectives. + +## Architecture + +Good practice is often based on modularity with clearly separated components +assembled within a common framework. Such modularity ensures separation of +duties, robustness, resilience and achievable long term maintenance. + +This document uses the term "**Service**" to define a specific instance of this +proposed common framework used to host a group of dedicated separated components +that handle targeted signals/events. Each service exposes to services/applications +the signals/events it is responsible for. + +As an example, a CAN service may want to mix non-public proprietary API with +CANopen compatible devices while hiding this complexity to applications. The +goal is on one hand to isolate proprietary piece of code in such a way that it +is as transparent as possible for the remaining part of the architecture. On a +second hand isolation of code related to a specific device provides a better +separation of responsibilities, keeping all specificity related to a given +component clearly isolated and much easier to test or maintain. Last but not +least if needed this model may also help to provide some proprietary code +directly as binary and not as source code. + +Communicating between the car and regular apps should be done using a 2 levels +AGL services which have two distincts roles: + +- low level should handle communication with CAN bus device (read, decoding, + basic and efficient filtering, caching, ...) +- high level should handle more complex tasks (signals compositions, complex + algorythms like Kalman filter, business logic...) + +![image](./images/signal-service-arch.svg "Signal Agent Architecture") + +To do so, the choice has been to use a similar architecture than [[OpenXC]], a +Ford project. Principle is simple, from a JSON file that describes all CAN +signals wanted to be handled, in general a conversion from a **dbc** file, AGL +generator convert it to a C++ source code file. This file which in turn is used +as part of the low level CAN service which can now be compiled. This service +reads, decodes and serves this CAN signals to a high level CAN service that +holds business logic and high level features like described is the above +chapter. + +![image](./images/can-generator.svg "AGL CAN generator") + +While in some cases it may be chosen to implement a single service responsible +for everything, other scenarii may chose to split responsibility between +multiple services. Those multiple services may run on a single ECU or on +multiple ECUs. Chosen deployment distribution strategy should not impact the +development of components responsible for signals/events capture. As well as it +should have a loose impact on applications/services consuming those events. + +A distributed capable architecture may provide multiple advantages: + +- it avoids to concentrate complexity in a single big/fat component. +- it leverages naturally multiple ECUs and existing network architecture +- it simplifies security by enabling isolation and sandboxing +- it clearly separates responsibilities and simplifies resolution of conflicts + +Distributed architecture has to be discussed and about now is not fully +implemented. Low level CAN service isn't fully functional nor tested to assume +this feature but its architecture let the possibility open and will be +implemented later. + +![image](./images/distributed-arch.png "Distributed Architecture") + +Performance matters. There is a trade-off between modularity and efficiency. +This is specially critical for signals where propagation time from one module to +the other should remain as short as possible and furthermore should consume as +little computing resources as possible. + +A flexible solution should provide enough versatility to either compose modules +in separate processes; either chose a model where everything is hosted within a +single process. Chosen deployment model should have minor or no impact on +development/integration processes. Deployment model should be something easy to +change, it should remain a tactical decision and never become a structuring +decision. + +Nevertheless while grouping modules may improve performance and reduce resource consumption, on the other hand, +it has a clear impact on security. No one should forget that some signals have very different level of security from other ones. +Mixing everything within a single process makes all signal's handling within a single security context. +Such a decision may have a significant impact on the level on confidence one may have in the global system. + +Providing such flexibility constrains the communication model used by modules: + +- The API of integration of the modules (the API of the framework) that enables + the connection of modules must be independent of the implementation of + the communication layer +- The communication layer must be as transparent as possible, its + implementation shouldn't impact how it is used +- The cost of the abstraction for modules grouped in a same process + must be as little as possible +- The cost of separating modules with the maximum of security must remain as + minimal as possible + +Another point impacting performance relates to a smart limitation on the number +of emitted signals. Improving the cost of sending a signal is one thing, +reducing the number of signals is an other one. No one should forget that the +faster you ignore a useless signal the better it is. The best way to achieve +this is by doing the filtering of useless signal as close as possible of the +component generating the signal and when possible directly at the hardware level. + +To enable the right component to filter useless signals, consumer clients must +describe precisely the data they need. A filter on frequency is provided since +Daring Dab version, as well as minimum and maximum limits. These filters can be +specified at subscription time. Also, any data not required by any client should +at the minimum never be transmitted. So only changed data is transmitted and if +another service needs to receive at a regular time, it has to assume that if no +events are received then it is that the value hasn't change. Furthermore when +possible then should even not be computed at all, a CAN signal received on +socket is purely ignored if no one asks for it. + +Describing expected data in a precise but nevertheless simple manner remains a +challenge. It implies to manage: + +- requested frequency of expected data +- accuracy of data to avoid detection of inaccurate changes +- when signaling is required (raising edge, falling edge, + on maintained state, ...), +- filtering of data to avoid glitches and noise, +- composition of signals both numerically and logically (adding, + subtracting, running logical operators like AND/OR/XOR, getting the mean, ...) +- etc... + +It is critical to enable multiple features in signal queries to enable modules +to implement the best computing method. The best computing method may have an +impact on which device to query as well as on which filters should be applied. +Furthermore filtering should happen as soon as possible and obviously when +possible directly at hardware level. + +### Transport Solutions + +D-Bus is the standard choice for Linux, nevertheless it has some serious +performance limitation due to internal verbosity. Nevertheless because it is +available and pre-integrated with almost every Linux component, D-Bus may still +remains an acceptable choice for signal with low rate of emission (i.e. HMI). + +For a faster communication, Jaguar-Land-Rover proposes a memory shared signal +infrastructure. Unfortunately this solution is far from solving all issues and +has some drawbacks. Let check the open issues it has: + +- there is no management of what requested data are. This + translate in computing data even when not needed. +- on top of shared memory, an extra side channel is required for processes + to communicate with the daemon. +- a single shared memory implies a lot of concurrency handling. This might + introduce drawbacks that otherwise would be solved through communication + buffering. + +ZeroMQ, NanoMSG and equivalent libraries focused on fast communication. Some +(e.g. ZeroMQ) come with a commercial licensing model when others (e.g. NanoMSG) +use an open source licensing. Those solutions are well suited for both +communicating inside a unique ECU or across several ECUs. However, most of them +are using Unix domain sockets and TCP sockets and typically do not use shared +memory for inter-process communication. + +Last but not least Android binder, Kdbus and other leverage shared memory, zero +copy and sit directly within Linux kernel. While this may boost information +passing between local processes, it also has some limitations. The first one is +the non support of a multi-ECU or vehicle to cloud distribution. The second one +is that none of them is approved upstream in kernel tree. This last point may +create some extra burden each time a new version of Linux kernel is needed or +when porting toward a new hardware is required. + +### Query and Filtering Language + +Description language for filtering of expected data remains an almost green +field where nothing really fit signal service requirements. Languages like +Simulink or signal processing graphical languages are valuable modelling tools. +Unfortunately they cannot be inserted in the car. Furthermore those languages +have many features that are not useful in proposed signal service context and +cost of integrating such complex languages might not be justified for something +as simple as a signal service. The same remarks apply for automation languages. + +Further investigations leads to some specifications already presents like the +one from Jaguar Land Rover [[VISS]], for **Vehicule Information Service +Specification** and another from Volkwagen AG named [[ViWi]], stand for +**Volkwagen Infotainment Web Interface**. Each ones has their differences and +provides different approach serving the same goal: + +| VISS | ViWi | +|---------------------------------------------------------------|-----------------------------------------------------------------| +| Filtering on node (not possible on several nodes or branches) | Describe a protocol | +| Access restrictions to signals | Ability to specify custom signals | +| Use high level development languages | RESTful HTTP calls | +| One big Server that handle requests | Stateless | +| Filtering | Filtering, sorting | +| Static signals tree not extensible [[VSS]] | Use JSON objects to communicate | +| Use of AMB ? | Identification of resources may be a bit heavy going using UUID | +| Use of Websocket | | + +About **[[VISS]]** specification, the major problem comes from the fact that +signals are specified under the [[VSS]], **Vehicle Signal Specification**. So, +problem is that it is difficult, if not impossible, to make a full inventory +of all signals existing for each car. More important, each evolution in signals +must be reported in the specification and it is without seeing the fact that +car makers have their names and set of signals that would mostly don't +comply with the [[VSS]]. VISS doesn't seems to be an valuable way to handle +car's signals, a big component that responds requests, use of **Automotive +Message Broker** that use DBus is a performance problem. Fujitsu Ten recent +study[[1]] highlights that processor can't handle an heavy load on CAN bus and +that Low level binding adopted for AGL is about 10 times[[2]] less impact on +performance. + +## Describing Signal Subscriptions using JSON + +JSON is a rich structured representation of data. For requested data, it allows +the expression of multiple features and constraints. JSON is both very flexible +and efficient. There are significant advantages in describing requested data at +subscription time using a language like JSON. Another advantage of JSON is that +no parser is required to analyse the request. + +Existing works exists to describe a signals that comes first from Vector with +its proprietary database (`DBC`) which widely used in industry. Make a +description based on this format appears to be a good solution and Open Source +community already has existing tools that let you convert proprietary file +format to an open one. So, a JSON description based on work from [[OpenXC]] is +specified [here](https://github.com/openxc/vi-firmware/blob/master/docs/config/reference.rst) +which in turn is used in Low level CAN service in AGL: + +```json +{ "name": "example", + "extra_sources": [], + "initializers": [], + "loopers": [], + "buses": {}, + "commands": [], + "0x3D9": { + "bus": "hs", + "signals": { + "PT_FuelLevelPct": { + "generic_name": "fuel.level", + "bit_position": 8, + "bit_size": 8, + "factor": 0.392157, + "offset": 0 + }, + "PT_EngineSpeed": { + "generic_name": "engine.speed", + "bit_position": 16, + "bit_size": 16, + "factor": 0.25, + "offset": 0 + }, + "PT_FuelLevelLow": { + "generic_name": "fuel.level.low", + "bit_position": 55, + "bit_size": 1, + "factor": 1, + "offset": 0, + "decoder": "decoder_t::booleanDecoder" + } + } + } +} +``` + +From a description like the above one, low level CAN generator will output +a C++ source file which let low level CAN service that uses it to handle such +signal definition. + +## Naming Signal + +Naming and defining signals is something very complex. For example just +***speed***, as a signal, is difficult to define. +What unit is used (km/h, M/h, m/s, ...)? +From which source (wheels, GPS, AccelMeter)? +How was it captured (period of measure, instantaneous, mean, filtered)? + +In order to simplify application development we should nevertheless agree on +some naming convention for key signals. Those names might be relatively complex +and featured. They may include a unit, a rate, a precision, etc. + +How these names should be registered, documented and managed is out of scope of +this document but extremely important and at some point in time should be +addressed. Nevertheless this issue should not prevent from moving forward +developing a modern architecture. Developers should be warned that naming is a +complex task, and that in the future naming scheme should be redefined, and +potential adjustments would be required. + +About Low level CAN signals naming a doted notation, like the one used by Jaguar +Landrover, is a good compromise as it describe a path to an car element. It +separates and organize names into hierarchy. From the left to right, you +describe your names using the more common ancestor at the left then more you go +to the right the more it will be accurate. Using this notation let you subscribe +or unsubscribe several signals at once using a globbing expression. + +Example using OBD2 standard PID: + +```path +engine.load +engine.coolant.temperature +fuel.pressure +intake.manifold.pressure +engine.speed +vehicle.speed +intake.air.temperature +mass.airflow +throttle.position +running.time +EGR.error +fuel.level +barometric.pressure +commanded.throttle.position +ethanol.fuel.percentage +accelerator.pedal.position +hybrid.battery-pack.remaining.life +engine.oil.temperature +engine.torque +``` + +Here you can chose to subscribe to all engine component using an expression +like : `engine.*` + +## Reusing existing/legacy code + +About now provided services use: + +- **Low Level** [[OpenXC]] project provides logic and some useful libraries to + access a CAN bus. It is the choice for AGL. + +- **High Level** In many cases accessing to low level signal is not enough. + Low level information might need to be composed (i.e. GPS+Gyro+Accel). + Writing this composition logic might be quite complex and reusing existing + libraries like: LibEkNav for Kalman filtering [[9]] or Vrgimbal for 3 axes + control[[10]] may help saving a lot of time. AGL apps should access CAN + signals through High Level service. High level can lean on as many low level + service as needed to compute its **Virtual signals** coming from differents + sources. Viwi protocol seems to be a good solution. + +## Leveraging AGL binder + +Such a model is loosely coupled with AGL binder. Low level CAN service as well +as virtual signal components may potentially run within any hosting environment +that would provide the right API with corresponding required facilities. +Nevertheless leveraging [[APbinder]] has multiple advantages. It already +implements event notification to support a messaging/signaling model for +distributed services. It enables a subscribe model responding to the +requirement and finally it uses JSON natively. + +This messaging/signalling model already enforces the notion of subscription for +receiving data. It implies that unexpected data are not sent and merely not +computed. When expected data is available, it is pushed to all waiting +subscriber only one time. + +The [[APbinder]] provides transparency of communication. +It currently implements the transparency over D-Bus/Kdbus and WebSocket. +Its transparency mechanism of communication is easy to extend to other +technologies: pools of shared memory or any proprietary transport model. + +When bindings/services are loaded by the same binder, it provides transparently +`in-memory` communication. This in-memory communication is really efficient: on +one hand, the exchanged JSON objects are not serialized (because not streamed), +on the other hand, those JSON objects provide a high level of abstraction able +to transfer any data. + +Technically a service is a standard [[APbinder]] binding which is also handled +by the system and launched as a daemon by systemD. +Therefore Signal/Agent inherits of security protection through SMACK, access +control through Cynara, transparency of API to transport layer, life cycle +management, ... Like any other [[APbinder]] process is composed of a set of +bindings. In signal service specific case, those bindings are in fact the +`signal modules`. + +The proposed model allows to implement low level dependencies as independent +signal modules. Those modules when developed are somehow like "Lego Bricks". +They can be spread or grouped within one or multiple services depending on +deployment constraints (performance, multi-ECU, security & isolation +constraints,...). + +On top of that low level signal modules, you should use a high level service. +A first implementation of [[ViWi]] is available [here](https://github.com/iotbzh/high-level-viwi-service) +and can be use to integrate business logic and high level features. + +The model naturally uses JSON to represent data. + +## Multi-ECU and Vehicule to Cloud interactions + +While this might not be a show stopper for current projects, it is obvious that +in the near future Signal/Agent should support a fully distributed +architectures. Some event may come from the cloud (i.e. request to start +monitoring a given feature), some may come from SmartCity and nearby vehicles, +and last but not least some may come from another ECU within the same vehicle or +from a virtualized OS within the same ECU (e.g. cluster & IVI). In order to do +so, Signal modules should enable composition within one or more [[APbinder]] +inside the same ECU. Furthermore they should also support chaining with the +outside world. + +![image](./images/cloud-arch.svg "Cloud & Multi-ECU Architecture") + +1. Application requests Virtual Signal exactly like if it was a low level signal +1. Agent Signal has direct relation to low level signal +1. Agent needs to proxy to an other service inside the same ECU to access the signal +1. Signal is not present on current ECU. Request has to be proxied to the outside world + +[AppFw]: http://iot.bzh/download/public/2016/appfw/01_Introduction-to-AppFW-for-AGL-1.0.pdf "Application Framework" +[APcore]: http://iot.bzh/download/public/2016/appfw/03_Documentation-AppFW-Core-1.0.pdf "AppFw Core" +[APmain]: https://gerrit.automotivelinux.org/gerrit/#/q/project:src/app-framework-main "AppFw Main" +[APbinder]: https://gerrit.automotivelinux.org/gerrit/#/q/project:src/app-framework-binder "AppFw Binder" +[APsamples]: https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-binder.git;a=tree;f=bindings/samples "AppFw Samples" +[Signal-K]: http://signalk.org/overview.html +[1]: http://schd.ws/hosted_files/aglmmwinter2017/37/20170201_AGL-AMM_F10_kusakabe.pdf +[2]: https://wiki.automotivelinux.org/_media/agl-distro/20170402_ften_can_kusakabe_v2.pdf +[6]: https://github.com/otcshare/automotive-message-broker +[7]: http://ardupilot.org/rover/index.html +[8]: https://github.com/ArduPilot/ardupilot/tree/master/libraries +[9]: https://bitbucket.org/jbrandmeyer/libeknav/wiki/Home +[10]: http://ardupilot.org/rover/docs/common-vrgimbal.html +[11]: http://elinux.org/R-Car/Boards/Porter:PEXT01 +[12]: https://github.com/gpsnavi/gpsnavi +[VISS]: http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html +[VSS]: https://github.com/GENIVI/vehicle_signal_specification +[ViWi]: https://www.w3.org/Submission/2016/SUBM-viwi-protocol-20161213/ +[OpenXC]: http://openxcplatform.com/ +[low level CAN service]: https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/low-level-can-generator +[high level ViWi]: https://github.com/iotbzh/high-level-viwi-service diff --git a/docs/signaling/images/OpenXC_to_AGL.png b/docs/signaling/images/OpenXC_to_AGL.png new file mode 100644 index 0000000..6e40336 Binary files /dev/null and b/docs/signaling/images/OpenXC_to_AGL.png differ diff --git a/docs/signaling/images/agent-arch.svg b/docs/signaling/images/agent-arch.svg new file mode 100644 index 0000000..bf3cede --- /dev/null +++ b/docs/signaling/images/agent-arch.svg @@ -0,0 +1,352 @@ + +image/svg+xmlLow Level binding -1 +Low Level binding -2 +Signal Agent General Architecture +Virtual Signal(Business Logic) +Access Control +Transport DBUS, WebSocket, ... +Publish/SubcribeSignal Exchange + \ No newline at end of file diff --git a/docs/signaling/images/agent-sample.svg b/docs/signaling/images/agent-sample.svg new file mode 100644 index 0000000..6fed96c --- /dev/null +++ b/docs/signaling/images/agent-sample.svg @@ -0,0 +1,426 @@ + +image/svg+xmlGPS NMEA +Geolocalisation Signal Agent +Geolocalisation(Business Logic) +Access Control +Transport DBUS, WebSocket, ... +Publish/SubcribeSignal Exchange +Accel + Gyro +ABS + others +IsFasterThanisOutOfZoneetc... +GetPositionGetSpeedIsMoving... + \ No newline at end of file diff --git a/docs/signaling/images/can-generator.svg b/docs/signaling/images/can-generator.svg new file mode 100644 index 0000000..f5a567c --- /dev/null +++ b/docs/signaling/images/can-generator.svg @@ -0,0 +1,244 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + CAN Low Level Bindng(Shared Library) + + + + + + + + + + + + + + OPENXC SignalDescription(JSON) + + + + + + + + + + + + + + + + + + + + + Low LevelBindingStatic Code(AGL) + + + + + + + + + + + + + + CANDecoding/EncodingC++ Code(vendor) + + + + + + + + + + + + + + OptionalMessageHandlers(vendor) + + + + + + + + + + + + + + + Call for decode/encode + + + + + + + + + + CANConfigGenerator + + + + + + + + + + C/C++Compiler + + + + + + + + + + + + + + OPENXC SignalDescription(JSON) + + + + + + + + + + + + + + OPENXC SignalDescription(JSON) + + + + + + + + \ No newline at end of file diff --git a/docs/signaling/images/cloud-arch.svg b/docs/signaling/images/cloud-arch.svg new file mode 100644 index 0000000..3cecbdc --- /dev/null +++ b/docs/signaling/images/cloud-arch.svg @@ -0,0 +1,837 @@ + +image/svg+xml +Access Control +Transport . +Custer ECU +Access Control +Transport DBUS, WebSocket, ... +NavigationService +Carte handling +POI management +etc... +CAN GPS +GeopositioningVirtualSignal +Multi ECU Architecture +ABS +Publish/Subscribe +IVI ECU +CAN-BUSVirtual Signal +Publish/Subscribe +Gyro, Acelerometer +CAN-BUS +LIN-BUS +ClusterVirtual Signal +Publish/Subscribe +Engine-CAN-BUS +ABS +1 +2 +3 +4 + \ No newline at end of file diff --git a/docs/signaling/images/distributed-arch.png b/docs/signaling/images/distributed-arch.png new file mode 100644 index 0000000..3c4f4a0 Binary files /dev/null and b/docs/signaling/images/distributed-arch.png differ diff --git a/docs/signaling/images/distributed-arch.svg b/docs/signaling/images/distributed-arch.svg new file mode 100644 index 0000000..b52b3a5 --- /dev/null +++ b/docs/signaling/images/distributed-arch.svg @@ -0,0 +1,717 @@ + +image/svg+xmlAgent-2Car Environement +Agent-3Engine +Agent-4Remote Signal +CAN Bus-A +LIN Bus-A +Audio +CAN Bus-B +Cluster-Unit +... +Smart City +RVI +Cloud +Transport + Acess Control +NavigationService +Carte handling +POI management +etc... +Log/SupervisionService +Carte handling +POI management +etc... +MultiMediaService +Media Player +Radio Interface +etc... +Signal Messaging Distributed Architecture + \ No newline at end of file diff --git a/docs/signaling/images/iotbzh_logo_small.png b/docs/signaling/images/iotbzh_logo_small.png new file mode 100644 index 0000000..6a98c60 Binary files /dev/null and b/docs/signaling/images/iotbzh_logo_small.png differ diff --git a/docs/signaling/images/logo_iot_bzh.svg b/docs/signaling/images/logo_iot_bzh.svg new file mode 100644 index 0000000..aa23e84 --- /dev/null +++ b/docs/signaling/images/logo_iot_bzh.svg @@ -0,0 +1,142 @@ + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + IOT + + BZH + + + + diff --git a/docs/signaling/images/signal-service-arch.svg b/docs/signaling/images/signal-service-arch.svg new file mode 100644 index 0000000..3dee802 --- /dev/null +++ b/docs/signaling/images/signal-service-arch.svg @@ -0,0 +1,296 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Binder + + + + + + + + CAN Low Level Binding(s)Decoding / EncodingAuthentication / Crypto / FirewallingTransaction (set… ack ...)Stats & MathsCaching (low freq. Signals, get() call)Debug + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + CAN High Level Binding(s)LogicAggregation (« vehicle.doors.any.open »)Advanced Ops + + + + + + + + + + + + + + + + + + + + + + + + + CAN BUS + + + + + + + + + + + + + + + + CAN frames - 011010010 + + + + + + + + + Signals - « vehicle.doors.left.open »(Binder Events) + + + + + + + + UI + + + + + + + + Publish Subscribe + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/docs/signaling/index.md b/docs/signaling/index.md new file mode 100644 index 0000000..cb466ae --- /dev/null +++ b/docs/signaling/index.md @@ -0,0 +1,50 @@ +# AGL Message Signaling + +## Architecture + +This [document](./architecture.md) presents an architecture for message signaling in AGL. + +Also available as a [PDF Document](http://iot.bzh/download/public/2016/signaling/AGL-Message-Signaling-Architecture.pdf) + +## Documentation + +Developer Guidelines are available as a [PDF Document](http://iot.bzh/download/public/2016/signaling/AGL-Message-Signaling-Developer-Guidelines.pdf) + +A GPS Binding example is available on Github: [github:iotbzh/af-gps-binding](https://github.com/iotbzh/af-gps-binding) + +## OpenXC Demo + +A reference HTML5 application has been developed: see [github:iotbzh/txc-demo](https://github.com/iotbzh/txc-demo). + +This application uses a [OpenXC trace file](http://openxcplatform.com/resources/traces.html) to display 4 different panels representing live vehicle data. + +It's available as an [AGL Application package](http://iot.bzh/download/public/2016/afb-demos/txc-demo_0.1.wgt) installable through AGL Application Framework. + +## Low level CAN service + +A project to access and decode CAN bus has been developed and part of AGL since Daring Dab version: [Low level CAN service](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/apps/low-level-can-service) + +This rewrite of OpenXC to adapt the project to AGL. + +Must be used in conjunction with the [low level CAN generator](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/low-level-can-generator) to custom your service. + +## High Level ViWi service + +An implementation of [ViWi](https://www.w3.org/Submission/2016/SUBM-viwi-protocol-20161213/) protocol has been made and available : [github.com:iotbzh/high-level-viwi-service](https://github.com/iotbzh/high-level-viwi-service) + +## Benchmarks + +Some tests to evaluate the performances of the framework have been done by simulating CAN Data: [AGL-AppFW-CAN-Signaling-Benchmark.pdf](http://iot.bzh/download/public/2016/signaling/AGL-AppFW-CAN-Signaling-Benchmark.pdf) + +## AMM Munich'16 Presentation + +[Jose's presentation at AGL AMM Munich'16](http://iot.bzh/download/public/2016/build-agl-application-AMM-Munich-2016/) + +## AMM Tokyo'17 Presentation + +[Kusakabe-san from Fujitsu-Ten presentation at AGL AMM Tokyo'17](http://schd.ws/hosted_files/aglmmwinter2017/37/20170201_AGL-AMM_F10_kusakabe.pdf) + +## F2F Karslruhe'17 Presentation + +[Romain's presentation at AGL F2F Karslruhe'17](http://iot.bzh/download/public/2017/F2F-Karslruhe/AGL-Signaling.pdf) +[Kusakabe-san from Fujitsu-Ten presentation at AGL F2F Karslruhe'17](https://wiki.automotivelinux.org/_media/agl-distro/20170402_ften_can_kusakabe_v2.pdf) diff --git a/getting-started/customize_bitbake_conf.md b/getting-started/customize_bitbake_conf.md deleted file mode 100644 index fa466ca..0000000 --- a/getting-started/customize_bitbake_conf.md +++ /dev/null @@ -1,53 +0,0 @@ -# Customize AGL build - -To customize the AGL build, you edit local.conf file, located in the build/conf directory. - -```bash -edit $AGL_TOP/build/conf/local.conf -``` - -## Buildhistory - -The OpenEmbedded build system creates this directory when you enable the build history feature. - -```bash -INHERIT += "buildhistory" -BUILDHISTORY_COMMIT = "1" -``` - -For more information please check [Here][buildhistory] - -## Deletion of temporary workspace - -Removes work files after the OpenEmbedded build system has finished with them. - -```bash -INHERIT += "rm_work" -``` - -For more information please check [Here][rm_work] - -## Share sstate cache - -The directory for the shared state cache. - -```bash -SSTATE_DIR = "${HOME}/workspace_agl/sstate-cache" -``` - -For more information please check [Here][share_sstatecache] - -## Share Download directory - -The central download directory used by the build process to store downloads. - -```bash -DL_DIR = "${HOME}/workspace_agl/downloads" -``` - -For more information please check [Here][share_download] - -[buildhistory]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-build-output-quality -[rm_work]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-tasks-rm_work -[share_sstatecache]: https://wiki.yoctoproject.org/wiki/Enable_sstate_cache -[share_download]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DL_DIR diff --git a/getting-started/footers/intel-footer.md b/getting-started/footers/intel-footer.md deleted file mode 100644 index 967feb4..0000000 --- a/getting-started/footers/intel-footer.md +++ /dev/null @@ -1,90 +0,0 @@ -## BIOS update - -Both Joule and MinnowBoard-Max (not needed on Turbo) require a BIOS upgrade before running AGL on them. - -**Do not loose any time trying without upgrading your BIOS first.** - -For instructions on how to update the BIOS on those platforms, please refer to these documents: -* [MinnowBoard](https://firmware.intel.com/projects/minnowboard-max) -* [Intel Joule](https://software.intel.com/en-us/flashing-the-bios-on-joule) -* Intel MRB contact your technical support representative to get the non signed ABL firmware
-**Note** MRB users need to replace the mkefi-agl.sh script by mkabl-agl.sh - -## Creating a bootable image - -Multiple options are avaiable but `dd` and `tar` can very easily let you down due to the requirement to pass SMACK labels, create a proper UEFI configuration and a few other tricks. -The script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) has been done to help you. -The option -h will print the help and the option -v will detail the operation and ease any debug. - -## Installing your image on the internal eMMC - -It can be interesting to install the AGL image directly on the internal eMMC rather than to boot from and SD or a USB removable device. -The easiest to do so, is to add the required tools in your removable boot device, boot AGL from the removable device and -then use the mkefi-agl.sh script to install the image image on the internal eMMC. - * Add the tools to the AGL image. - ** Add a file site.conf in your build/conf directory with the following content: - ``` - INHERIT += "rm_work" - IMAGE_INSTALL_append = " linux-firmware-iwlwifi-7265d" - IMAGE_INSTALL_append = " parted e2fsprogs dosfstools" - IMAGE_INSTALL_append = " linux-firmware-i915 linux-firmware-ibt linux-firmware-iwlwifi-8000c" - add the iwlifi for your own device as needed - ``` - * rebuild your image and install it on your removable device with mkefi-agl.sh. - * add the AGL image file on your removable device in the home directory (for later installation) - ``` - the AGL image file created by yocto (.wic.xz) - located in build/tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic.xz - ``` - * boot AGL from your removable device - * connect to the AGL running image either via serial link or ssh - * locate the eMMC device name - * install image with mkefi-agl.sh - ``` - cat /proc/partitions - ``` - * install the AGL image on the eMMC with mkefi-agl.sh script - * remove the USB or SD boot device - * reboot - -## Selecting the SD or USB to boot - -When booting a MinnowBoard or a Joule you can change the default boot device by hitting F2 during initial UEFI boot. -It's easier to achieve it in the right time with a USB keyboard than via serial link. -During boot USB hubs are not supported, you need to connect the keyboard directly in the USB socket. -It's also preferable to use F9 and to change the boot order once for all. -Please note: You can only change the boot order when a valid device is inserted in the corresponding port (USB or SD). - -The MinnowBoard, Joule, many laptops and NUCs will not accept to boot with some USB3 sticks. If you have some trouble to get your USB3 stick detected during boot, swap it for a USB2. In any case working with SD card is faster to flash and to boot. SD should be preferred. -The Joule seems to refuse to boot with my SD-HC-I type cards while I had no problem with the MinnowBoard. If you work with a Joule, use regular SD-HC (mode 4 and 10 work fine). - -## Serial debug Port - -Serial debug port ID varies with the HW platform. By default AGL build Intel target as a MinnowBoard where serial is `/dev/ttyS0`, on Joule and MRB the serial debug is `/dev/ttyS2`. -On Up boards the /dev/ttyS0 serial port is not easy to access and using /dev/ttyS4 which is routed on the Arduino connector.
[See pinout]( http://www.up-board.org/wp-content/uploads/2017/11/UP-Square-DatasheetV0.5.pdf) - -You may have to change the configuration in your bootloader which is located in the EFI partition. - -## Serial debug cable - -On the MinnowBoard the serial cable is an FTDI serial cable. The wiring can be found [here](http://wiki.minnowboard.org/MinnowBoard_MAX_HW_Setup).
-Up Boards use the same FDDI 3.3V adaptor than the Minnow but the pin out is not adjacent and requires to split the pins. -On the Joule the serial connection is done via the micro USB cable which is not provided in the Developer kit. Details can be found [here](https://software.intel.com/en-us/node/667851). -Interface speed is 115200 bps, 8 bits, no parity, no flow control - -## Which port name is used to define the connected display(s) - -Port naming may change with HW platforms and connected display. The simplest is to check following the first boot, in the systemd journal, which display names are listed. - -```bash -journalctl |grep Output -``` - -**Note:** The Output information is only listed if a real Display is connected to the connector on the board. -The file holding that configuration is `/etc/xdg/weston/weston.ini`. - -Common Display names for Intel are: - -* `HDMI-A-1` -* `HDMI-A-2` -* `LVDS-1` diff --git a/getting-started/footers/porter-footer.md b/getting-started/footers/porter-footer.md deleted file mode 100644 index 7d1417d..0000000 --- a/getting-started/footers/porter-footer.md +++ /dev/null @@ -1,23 +0,0 @@ -## Weston - -If Weston fails to start double check : -``/etc/xdg/weston/weston.ini`` -and verify that the output name and screen resolution matches the configured U-Boot environment. -For example on Renesas Porter board rev 1.0 with screen resolution 1024x768: - -```bash -[core] -shell=desktop-shell.so -backend=drm-backend.so - -[shell] -locking=true -# Uncomment below to hide panel -#panel-location=none - -[output] -name=HDMI-A-1 -mode=1024x768 -#mode=1920x1080 -#mode=173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync -``` diff --git a/getting-started/footers/raspberrypi-footer.md b/getting-started/footers/raspberrypi-footer.md deleted file mode 100644 index f5ff16f..0000000 --- a/getting-started/footers/raspberrypi-footer.md +++ /dev/null @@ -1,56 +0,0 @@ -# Commercial Licensed Packages - -Append to following lines to **conf/local.conf** to include libomxil under a commercial license to your build: - -```bash -# For libomxil -LICENSE_FLAGS_WHITELIST = "commercial" - -IMAGE_INSTALL_append = " libomxil" -``` - -# Raspberry Pi Touchscreen with Rotation - -If you have Raspberry Pi official 7" touchscreen connected, you can rotate it with these lines in /etc/xdg/weston/weston.ini - -```bash -root@raspberrypi3:/etc/xdg/weston# cat weston.ini -[core] -backend=drm-backend.so -shell=desktop-shell.so - -[shell] -locking=true -# Uncomment below to hide panel -#panel-location=none - -[launcher] -icon=/usr/share/weston/terminal.png -path=/usr/bin/weston-terminal - -[launcher] -icon=/usr/share/weston/icon_flower.png -path=/usr/bin/weston-flower - -[output] -name=DSI-1 -transform=270 -``` - -# Debugging - -It is possible to debug AGL images on Raspberry Pi using 3.3V USB to serial cable, such as [Olimex USB-Serial-Cable-F](https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/), connected to the UART of the board. Follow the instructions below to connect a cable to the board (do it on your own risk, no warranty is provided): - -* Connect the BLUE wire if you are using Olimex USB-Serial-Cable-F to pin 6 of Raspberry Pi, -* Connect the RX line of the cable (GREEN wire if you are using Olimex USB-Serial-Cable-F) to pin 8 (TX line) of Raspberry Pi, -* Connect the TX line of the cable (RED wire if you are using Olimex USB-Serial-Cable-F) to pin 10 (RX line) of Raspberry Pi. - -![Olimex USB-Serial-Cable-F attached to Raspberry PI 2 for debugging through the serial console](images/RaspberryPi2-ModelB-debug-serial-cable.jpg) - -* Plug the USB connector of the cable to your computer and use your favorite tool for serial communication, for example on Ubuntu and other Linux distributions you may use screen: - -```bash -sudo screen /dev/ttyUSB0 115200 -``` - -Pay attention that the colors of the cable may vary depending on the vendor. If you have USB console cable from Adafruit please have a look [here](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead). diff --git a/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg b/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg deleted file mode 100644 index e8026d6..0000000 Binary files a/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg and /dev/null differ diff --git a/getting-started/machines/R-Car-Starter-Kit-gen3.md b/getting-started/machines/R-Car-Starter-Kit-gen3.md deleted file mode 100644 index 68a3798..0000000 --- a/getting-started/machines/R-Car-Starter-Kit-gen3.md +++ /dev/null @@ -1,633 +0,0 @@ -# AGL Kickstart on Renesas R-Car Starter Kit Gen3 (h3ulcb, m3ulcb, salvator-x(optional)) - -## Prerequisites - -* At this step, you are assumed to have downloaded the [AGL source code](/docs/getting_started/en/dev/reference/source-code.html). - -See the related paragraph if not done yet. - -* For creating the microSD card, you will need **bmaptool** - -There are pre-built packages (.deb or .rpm) for the supported host OSes, available at [this location]( -https://build.opensuse.org/package/show/isv:LinuxAutomotive:AGL_Master/bmap-tools) - -## Hardware - -Here is a non exhaustive list of hardware parts that could be used to setup the R-Car Starter Kit Gen3 board development environment: - -* Starter Kit Gen3 board with its 5V power supply -* micro USB-A cable for serial console (optional if using ethernet and ssh connection) -* USB 2.0 Hub (optional) -* Ethernet cable (optional if using serial console) -* HDMI type D (Micro connector) cable and associated display -* micro-SD Card (at least 4GB) and recommend to use class 10 type. -* USB touch screen device like the GeChic 1502i/1503i (optional) - -For more information and latest news, please check : - -* [elinux page for h3ulcb][R-car h3ulcb] -* [elinux page for m3ulcb][R-car m3ulcb] -* [elinux page for salvator-x][R-car salvator-x] - -Infotainment Carrier Board : - -* [elinux page for Kingfisher][R-car Kingfisher] - -**Note**:That the Salvator-X has NDA restrictions, so less documentation is available both here and elsewhere. - -The following documents may also be helpful: - -* [Yocto-Gen3 on elinux][R-car yocto] - -## BSP Version of R-Car Starter Kit Gen3 - -| AGL Version| Renesas version | -|:-:|:-:| -| AGL master | 3.9.0 | -| AGL 6.0.0 | 3.7.0 | -| AGL 5.0.x, 5.1.0| 2.23.1 | -| AGL 4.0.x |2.19.0 | - -## Building the AGL Demo Platform for R-Car Starter Kit Gen3 - -Before setting up the build environment, you need to download the proprietary drivers. - -* The version of the drivers you need can be displayed this way: - -```bash -grep -rn ZIP_.= $AGL_TOP/meta-agl/meta-agl-bsp/meta-rcar-gen3/scripts/setup_mm_packages.sh -``` - -* Download Renesas graphics drivers with a "click through" license from [Renesas website][rcar Linux Drivers 2] - * Under the Target hardware: **R-Car H3/M3** section. - -**Note**: - -* You have to register with a free account on MyRenesas and accept the license conditions before downloading the drivers. - The operation is fast and simple nevertheless mandatory to access evaluation of non open-source drivers for free. - Once you registered, you can download two zip files. -* It is recommended to store these drivers into your download directory (usually $HOME/Downloads, pointed by $XDG_DOWNLOAD_DIR in some OS). - * To avoid any errors, check that $XDG_DOWNLOAD_DIR is set to the directory where the drivers are stored, if not, set it using 'export' command -* Be sure to have the need rights for these files using : - -```bash -chmod a+r $XDG_DOWNLOAD_DIR/*.zip -``` - -* Check that the needed drivers files are found using : - -```bash -ls -1 $XDG_DOWNLOAD_DIR -[master] --rw-r--r--. 1 1664 agl-sdk 5.0M Jun 28 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180627.zip --rw-r--r--. 1 1664 agl-sdk 3,1M Jun 28 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180627.zip - -[Flounder] --rw-r--r--. 1 1664 agl-sdk 4.9M Apr 24 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip --rw-r--r--. 1 1664 agl-sdk 3,0M Apr 24 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip - -[Eel] --rw-r--r--. 1 1664 agl-sdk 4.5M Dec 8 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip --rw-r--r--. 1 1664 agl-sdk 3,0M Dec 8 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip -``` - -### Setting up the build environment - -Define the type of R-Car Starter Kit board as a variable: - -* for machine **h3ulcb** (Starter Kit Premier/H3) : - -```bash -export MACHINE=h3ulcb -``` - -* for machine **m3ulcb** (Starter Kit Pro/M3): - -```bash -export MACHINE=m3ulcb -``` - -* for machine **h3-salvator-x**: - -```bash -export MACHINE=h3-salvator-x -``` - -Now, init your build environment: - -```bash -cd $AGL_TOP -source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo agl-netboot agl-appfw-smack agl-localdev -``` - -**IMPORTANT NOTE**: Read the log to be sure you had no error during your setup. - -In case of missing graphics drivers, you could notice an error message as follow: - -```bash -[snip] ---- fragment /home/working/workspace_agl_master/meta-agl/templates/machine/h3ulcb/50_setup.sh -/home/working/workspace_agl_master /home/working/workspace_agl_master/build_gen3 -The graphics and multimedia acceleration packages for -the R-Car Gen3 board can be downloaded from: - https://www.renesas.com/en-us/solutions/automotive/rcar-demoboard-2.html - -These 2 files from there should be store in your'/home/devel/Downloads' directory. - R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip - R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip -/home/working/workspace_agl_master/build_gen3 ---- fragment /home/working/workspace_agl_master/meta-agl/templates/base/99_setup_EULAconf.sh ---- end of setup script -OK -Generating setup file: /home/working/workspace_agl_master/build_gen3/agl-init-build-env ... OK ------------- aglsetup.sh: Done -[snip] -``` - -If you encounter this issue, or any other unwanted behavior, you can fix the error mentioned and then clean up by removing the “$AGL_TOP/build” directory then re-launch the procedure again. - -In any case, you can find out more information for the reason of the error in this file: - -```bash -[snip] - -~/workspace_agl/build/conf $ cat setup.log ---- beginning of setup script ---- fragment /home/thierry/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh ---- fragment /home/thierry/workspace_agl/meta-agl/templates/machine/m3ulcb/50_setup.sh -~/workspace_agl ~/workspace_agl/build -ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip+" NOT EXTRACTING CORRECTLY -ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip+" NOT EXTRACTING CORRECTLY -The graphics and multimedia acceleration packages for -the R-Car Gen3 board BSP can be downloaded from: - - -These 2 files from there should be stored in your -'/home/thierry/Downloads' directory. - R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip - R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip -ERROR: Script /home/thierry/workspace_agl/build/conf/setup.sh failed -[snip] -``` - -After this command, the working directory is changed to $AGL_TOP/build. - -If you do not want do this, another option is to add the '**-f**' option to agl_setup.sh. - -Users may want to check that the board is correctly selected in the environment: - -```bash -grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf - MACHINE = "h3ulcb" -or - MACHINE = "m3ulcb" -or - MACHINE = "h3-salvator-x" -``` - -Configure for Release or Development: - -* development images contain extra tools for developer convenience, in particular: - * a debugger (gdb) - * some tweaks, including a disabled root password - * a SFTP server - * the TCF Agent for easier application deployment and remote debugging - * some extra system tools (usb, bluetooth ...) - * ... - -We explicitely activate these debug facilities by specifying the “agl-devel agl-netboot” feature. - -### Build your image - -The process to build an image is simple: - -```bash -bitbake agl-demo-platform -``` - -You may need to install rpcgen to run this command. - -When finished (it may take few hours), you should get the final result: - -```bash -ls -l $AGL_TOP/build/tmp/deploy/images/$MACHINE -``` - -**Note**: - -In case of failure of the build it is safe to first check that the Linux distribution chosen for your host has been validated for the current version of Yocto used by AGL. - -## Booting AGL Image on R-Car Starter Kit Gen3 boards using a microSD card - -To boot the board using a micro-SD card, there are two operations that must be done prior to first initial boot: - -* Update all firmware on the device. -* Set up the board to boot on the SD-card. - -For each subsequent build you only need to rewrite the SD-card with the new image. - -### Firmware Update - -This proceedure is done in two steps. The 'Sample Loader and MiniMonitor update' step only needs to be done once per device. The 'Firmware stack update' step is mandatory only if you use AGl Eel (version 5.0) or later. - -#### Sample Loader and MiniMonitor update - -Follow the documentation on the [eLinux.org wiki][R-car loader update] to update to at least version 3.02. This is mandatory to run AGL. - -#### Firmware stack update - -As an AArch64 platform, both **h3ulcb** and **m3ulcb** have a firmware stack divided in : **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. - -If you use AGl Eel (version 5.0) or later, you must update the firmware using the following links to eLinux.org wiki: **[h3ulcb][R-car h3ulcb firmware update]** or **[m3ulcb][R-car m3ulcb firmware update]**. - -The files listed in the eLinux.org wiki table will be found in the directory: - -```bash -*\$AGL_TOP/build/tmp/deploy/images/$MACHINE* -``` - -The Salvator-X firmware update process is not documented on eLinux. - -### Prepare the SD-card on the host - -Plug the microSD card and get its associated device by either running *`dmesg | tail -15`* or *`lsblk`*, for example: - -```bash -dmesg | tail -15 - - [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 - [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found - [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through - [ 1971.463870] sdc: sdc1 sdc2 -``` - -Here, the SD-card is attached to the device /dev/sdc. - -```bash -lsblk - - NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT - sda 8:0 0 167,7G 0 disk - ├─sda1 8:1 0 512M 0 part /boot/efi - ├─sda2 8:2 0 159,3G 0 part / - └─sda3 8:3 0 7,9G 0 part [SWAP] - sdb 8:16 0 931,5G 0 disk - └─sdb1 8:17 0 931,5G 0 part /media/storage - sdc 8:32 1 14,9G 0 disk - ├─sdc1 8:33 1 40M 0 part - └─sdc2 8:34 1 788M 0 part -``` - -**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time: -so you should repeat this operation each time you insert the microSD card to confirm the device name. - -In the example above, we see: - -* the first SATA drive as 'sda'. -* 'sdc' corresponds to the microSD card, and is also marked as removable device by *lsblk* which is a good confirmation. -* Your desktop system probably offers a choice to mount the SD-card automatically in some directory. -* In the next sample code, we'll suppose that the SD-card mount directory is stored in the variable $SDCARD. -* For example, if the microSD card is associated with device *sdc*: - -Go to your build directory: - -```bash -cd $AGL_TOP/build/tmp/deploy/images/$MACHINE -``` - -You can use bmaptool to copy the **.wic.xz** file to the storage device, discovered in the previous step: - -```bash -bmaptool copy ./agl-demo-platform-$MACHINE.wic.xz $SDCARD -``` - -Or you can be uncompressed and written to the device: - -```bash - sudo umount /dev/sdc - xzcat ./agl-demo-platform-$MACHINE.wic.xz | sudo dd of=$SDCARD bs=4M - sync -``` - -### Booting the board - -* Turn the board off using the power switch. -* Insert the microSD-card. -* Verify that you have plugged in, at least : - * An external monitor on HDMI port - * An input device (keyboard, mouse, touchscreen...) on USB port. - -* Turn the board on using the power switch. - After a few seconds, you'll see the AGL splash screen on the display and you'll be able to log in on the console terminal or in the graphic screen. - -## Serial Console Setup - -### Install a serial client on your computer - -This can be “screen”, “picocom”, “minicom”. -The lighter of the 3 is “picocom” (it has less dependencies). - -### Plug a USB cable from your computer to the serial CP2102 USB port (micro USB-A) - -With “dmesg” you can check the device created for the serial link. -Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host. -To get it, you must switch the board on. -For example: - -```bash -dmesg | tail -[2097783.287091] usb 2-1.5.3: new full-speed USB device number 24 using ehci-pci -[2097783.385857] usb 2-1.5.3: New USB device found, idVendor=0403, idProduct=6001 -[2097783.385862] usb 2-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 -[2097783.385864] usb 2-1.5.3: Product: FT232R USB UART -[2097783.385866] usb 2-1.5.3: Manufacturer: FTDI -[2097783.385867] usb 2-1.5.3: SerialNumber: AK04WWCE -[2097783.388288] ftdi_sio 2-1.5.3:1.0: FTDI USB Serial Device converter detected -[2097783.388330] usb 2-1.5.3: Detected FT232RL -[2097783.388658] usb 2-1.5.3: FTDI USB Serial Device converter now attached to ttyUSB0 -``` - -The link is attached to the device /dev/ttyUSB0. -It is time to launch your serial client. -Example: - -```bash -picocom -b 115200 /dev/ttyUSB0 -``` - -or - -```bash -minicom -b 115200 -D /dev/ttyUSB0 -``` - -or - -```bash -screen /dev/ttyUSB0 115200 -``` - -### Power on the board to see a shell on the console - -* For machine h3ulcb: - -```bash -NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 -NOTICE: BL2: PRR is R-Car H3 ES1.1 -NOTICE: BL2: LCM state is CM -NOTICE: BL2: DDR1600(rev.0.15) -NOTICE: BL2: DRAM Split is 4ch -NOTICE: BL2: QoS is Gfx Oriented(rev.0.30) -NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 -NOTICE: BL2: Lossy Decomp areas -NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 -NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 -NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 -NOTICE: BL2: v1.1(release):41099f4 -NOTICE: BL2: Built : 19:20:52, Jun 9 2016 -NOTICE: BL2: Normal boot -NOTICE: BL2: dst=0xe63150c8 src=0x8180000 len=36(0x24) -NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=3072(0xc00) -NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) -NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) -NOTICE: BL2: dst=0x49000000 src=0x8640000 len=1048576(0x100000) - - -U-Boot 2015.04 (Jun 09 2016 - 19:21:52) - -CPU: Renesas Electronics R8A7795 rev 1.1 -Board: H3ULCB -I2C: ready -DRAM: 3.9 GiB -MMC: sh-sdhi: 0, sh-sdhi: 1 -In: serial -Out: serial -Err: serial -Net: Board Net Initialization Failed -No ethernet found. -Hit any key to stop autoboot: 0 -=> -``` - -* For machine m3ulcb: - -``` -NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 -NOTICE: BL2: PRR is R-Car M3 Ver1.0 -NOTICE: BL2: Board is Starter Kit Rev1.0 -NOTICE: BL2: Boot device is HyperFlash(80MHz) -NOTICE: BL2: LCM state is CM -NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 -NOTICE: BL2: DDR1600(rev.0.22)NOTICE: [COLD_BOOT]NOTICE: ..0 -NOTICE: BL2: DRAM Split is 2ch -NOTICE: BL2: QoS is default setting(rev.0.17) -NOTICE: BL2: Lossy Decomp areas -NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 -NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 -NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 -NOTICE: BL2: v1.3(release):4eef9a2 -NOTICE: BL2: Built : 00:25:19, Aug 25 2017 -NOTICE: BL2: Normal boot -NOTICE: BL2: dst=0xe631e188 src=0x8180000 len=512(0x200) -NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) -NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) -NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) -NOTICE: BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000) - - -U-Boot 2015.04-dirty (Aug 25 2017 - 10:55:49) - -CPU: Renesas Electronics R8A7796 rev 1.0 -Board: M3ULCB -I2C: ready -DRAM: 1.9 GiB -MMC: sh-sdhi: 0, sh-sdhi: 1 -In: serial -Out: serial -Err: serial -Net: ravb -Hit any key to stop autoboot: 0 -=> -``` - -### Configure U-boot parameters - -Follow the steps below to configure the boot from microSD card and to set screen resolution: - -* Turn the board on using the power switch. -* Hit any key to stop autoboot (warning you have only few seconds). -* Type **printenv** to check if you have correct parameters for booting your board: - * Example for a h3ulcb: - - ``` - => printenv - baudrate=115200 - bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 - bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 - bootdelay=3 - fdt_high=0xffffffffffffffff - initrd_high=0xffffffffffffffff - load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb - load_ker=ext4load mmc 0:1 0x48080000 /boot/Image - stderr=serial - stdin=serial - stdout=serial - ver=U-Boot 2015.04 (Jun 09 2016 - 19:21:52) - - Environment size: 648/131068 bytes - ``` - - * Example for a m3ulcb: - - ``` - => printenv - baudrate=115200 - bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 - bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 - bootdelay=3 - fdt_high=0xffffffffffffffff - filesize=cdeb - initrd_high=0xffffffffffffffff - load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb - load_ker=ext4load mmc 0:1 0x48080000 /boot/Image - stderr=serial - stdin=serial - stdout=serial - ver=U-Boot 2015.04 (Nov 30 2016 - 18:25:18) - - Environment size: 557/131068 bytes - ``` - - * To boot on a sd card, it is recommended to set your environment using these commands : - - ``` - setenv bootargs console=ttySC0,115200 ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2 - setenv bootcmd run load_ker\; run load_dtb\; booti 0x48080000 - 0x48000000 - setenv load_ker ext4load mmc 0:1 0x48080000 /boot/Image - ``` - - * For machine h3ulcb (BSP >= 2.19): - - ``` - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb.dtb - ``` - - * For machine h3ulcb (BSP < 2.19): - - ``` - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb - ``` - - * For machine m3ulcb: - - ```bash - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb - ``` - - * For machine m3ulcb with a kingfisher board: - - ```bash - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb-kf.dtb - ``` - - * For machine h3ulcb with a kingfisher board: - - ```bash - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb-kf.dtb - ``` - - * Finally save boot environment: - - ```bash - saveenv - ``` - -* Now you can boot: - -``` -run bootcmd -``` - -### Console boot - -After booting, you should see the wayland display on the external monitor and a login prompt on the console, such as: - -* For machine h3ulcb: - -```bash -Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 - -h3ulcb login: root -``` - -* For machine m3ulcb: - -```bash -Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0 - -m3ulcb login: root -``` - -Logging in on the console is easy: - -* login is 'root' -* password is empty (not asked) - -### Network access - -If the board is connected to a local network using ethernet and if a DHCP server is able to distribute IP addresses, -you can then determine the Gen3 board IP address and log in using ssh: - -```bash -m3ulcb login: root -Last login: Tue Dec 6 09:55:15 UTC 2016 on tty2 -root@m3ulcb:~# ip -4 a -1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default - inet 127.0.0.1/8 scope host lo - valid_lft forever preferred_lft forever -3: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 - inet 10.0.0.27/24 brd 10.0.0.255 scope global eth0 - valid_lft forever preferred_lft forever -root@m3ulcb:~# -``` - -Here, IP address is 10.0.0.27. Logging in using SSH is easy: - -```bash -$ ssh root@10.0.0.27 -Last login: Tue Dec 6 10:01:11 2016 from 10.0.0.13 -root@m3ulcb:~# cat /etc/os-release -ID="poky-agl" -NAME="Automotive Grade Linux" -VERSION="3.0.0+snapshot-20161202 (chinook)" -VERSION_ID="3.0.0-snapshot-20161202" -PRETTY_NAME="Automotive Grade Linux 3.0.0+snapshot-20161202 (chinook)" -``` - -## More Documentation - -Detailed guides on how to build AGL for Renesas boards and using AGL SDK inside a ready-to-use Docker container: - -* [AGL-Devkit-Build-your-1st-AGL-Application.pdf][Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application] - Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. -* [AGL-Devkit-HowTo_bake_a_service.pdf][Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service] - Generic guide on how to add a new service in the BSP. -* [AGL-Kickstart-on-Renesas-Porter-Board.pdf][Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board] -* [AGL-Devkit-Image-and-SDK-for-Porter.pdf][Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter] -* [AGL Developer Website](http://docs.automotivelinux.org) - -[R-car m3ulcb]: http://elinux.org/R-Car/Boards/M3SK -[R-car m3ulcb firmware update]: https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware -[R-car h3ulcb]: http://elinux.org/R-Car/Boards/H3SK -[R-car h3ulcb firmware update]: https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware -[R-car salvator-x]: https://elinux.org/R-Car/Boards/Salvator-X -[R-car loader update]: http://elinux.org/R-Car/Boards/Kingfisher#How_to_update_of_Sample_Loader_and_MiniMonitor -[R-car Kingfisher]: https://elinux.org/R-Car/Boards/Kingfisher -[R-car yocto]: http://elinux.org/R-Car/Boards/Yocto-Gen3 -[rcar Linux Drivers]: https://www.renesas.com/solutions/automotive/rcar-download/rcar-demoboard.html -[rcar Linux Drivers 2]: https://www.renesas.com/en-us/solutions/automotive/rcar-download/rcar-demoboard-2.html -[Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf -[Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf -[Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf -[Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf - diff --git a/getting-started/machines/intel.md b/getting-started/machines/intel.md deleted file mode 100644 index 34957a8..0000000 --- a/getting-started/machines/intel.md +++ /dev/null @@ -1,186 +0,0 @@ -# Running AGL on Intel MinnowBoard (and most Intel 64 bits HW) - -## Scope - -This documentation is aiming at people who want to run Automotive Grade -Linux (AGL) on Intel Hardware (HW). -While the reference HW used by AGL project is the Open Source MinnowBoard, this documentation [MinnowBoard wiki](https://minnowboard.org/) can be used to enable most of 64-bit Intel Architecture (IA) platforms using UEFI as boot loader. -In addition to the MinnowBoard, support for the [upCore & UpSquared boards](http://www.up-board.org/upsquared/) has been added. -You need to run the 64-bit version of the UEFI bootloader. -MinnowBoard Max and Turbot as well as Joule are both 64-bit capable. - -**Note**: This page is more focused on those who want to create bespoke AGL images and BSPs. - -If you are interested in creating ***applications*** to run on AGL, please visit the [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) documentation. - -UEFI has evolved a lot recently and you likely want to check that your HW firmware is up-to-date, this is mandatory for both the MinnowBoard-Max and the Joule. Not required on Minnowboard-Turbo and Up boards. - -[`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max) -[`https://software.intel.com/en-us/flashing-the-bios-on-joule`](https://software.intel.com/en-us/flashing-the-bios-on-joule) - -## Where to find an AGL bootable image - -### Download a ready made image - -AGL provides ready made images for developers. -You will find them on [AGL Download web site](https://download.automotivelinux.org/AGL/release) -image are located in YourPreferedRelease/intel-corei7-64/deploy/images/intel-corei7-64/ -Create a bootable SD card with the script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) -check the available options with the -v option. mkefi-agl.sh -v - -### Building an AGL image from scratch using Yocto - -**Note**: an alternative method for building an image is to use the AGL SDK delivered in a Docker container. - -There is currently no SDK dedicated to IA but the SDK provided for the Porter Board can build an IA image without changes (just `aglsetup.sh` needs to call for Intel). - -See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf "wikilink"). - -#### Download AGL source code - -Downloading the AGL sources from the various Git repositories is automated with the `repo` tool. Basic steps to download the AGL source code is described below and for more advanced topics involving the `repo` tool, please refer to the [`repo` documentation](https://source.android.com/source/using-repo.html "wikilink"). - -To install the `repo` tool: - -```bash - mkdir -p ~/bin; - export PATH=~/bin:$PATH; - curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo; - chmod a+x ~/bin/repo; -``` - -#### Configuring for the current *(older)* stable (Electric Eel 5.0.x) - -```bash - cd AGL-5.0.x; - repo init -b eel -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -``` - -#### Configuring for master (DD) - -```bash - cd AGL-master; - repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo; -``` - -Once that you repo is initialised either with the stable or WIP, you need to sync the repo to fetch the various git trees. - -#### Downloading the configured AGL source code - -```bash - repo sync; -``` - -#### Building the AGL distro - -You are now ready to initialise your Yocto build. -When running the command: - -```bash - source meta-agl/scripts/aglsetup.sh -h -``` - -You will notice the Intel entries - -```bash - intel-corei7-64 - joule -``` - -Simply select that entry to replace porter in the -m option. -**Note:** agl-netboot option is required to create the right initramfs even if you do not boot from a network - -```bash - source meta-agl/scripts/aglsetup.sh \ - -m intel-corei7-64 \ - -b build \ - agl-devel agl-demo agl-appfw-smack agl-netboot agl-audio-4a-framework -``` - -**Note:** use the option "-m joule" when building for a Joule developer Kit target. - -Start the build **This can take several hours depending of your CPU and -internet connection and will required several GB on /tmp as well as on your build directory** - -```bash - bitbake agl-demo-platform -``` - -**Your newly baked disk image (.wic.xz) will be located at**: - `tmp/deploy/images/intel-corei7-64/` - -##### Alternative: Download a *ready made* image from AGL web site - -The Continuous Integration (CI) process from AGL creates and publish daily and stable builds. -Pointers to both can be found in [AGL supported HW](https://wiki.automotivelinux.org/agl-distro) (see Reference BSP/Intel). - -Once you have validated your process you can start to play/work with the snapshot pointer. - -Note that snapshot build may not work. - -Follow the directory: - -`intel-corei7-64/deploy/images/intel-corei7-64/` - -and download the file: - -`agl-demo-platform-intel-corei7-64.hddimg` - -## Create a bootable media - -Depending your target HW you will use an USB stick, an SD card or a HDD/SDD. -The creation process remains the same independently of the selected support. -It does require to have access to a Linux machine with `sudo` or root password. - -### Insert you removable media in the corresponding interface - -### Check the device name where the media can be accessed with the command - -```bash - lsblk - # Note that you want the name of the raw device not of a partition on the media - #(eg. /dev/sdc or /dev/mmcblk0) -``` - -### Download the script `mkefi-agl.sh` - -This script is present in the directory meta-agl/scripts from blowfish 2.0.4 : [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) - -Alternatively you can download it from the following Git repo: - -[https://github.com/dominig/mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh) - -### check the available options - -```bash - sh mkefi-agl.sh -v; -``` - -### create your media with the command adjusted to your configuration - -```bash - sudo sh mkefi-agl.sh MyAglImage.hdd /dev/sdX - #/dev/sdX is common for USB stick, /dev/mmcblk0 for laptop integrated SD card reader -``` - -## Boot the image on the target device - -1. Insert the created media with the AGL image in the target device - -1. Power on the device - -1. Select Change one off boot option (generally F12 key during power up) - -1. Select your removable device - -1. Let AGL boot - -**Note:**: depending on the speed of the removable media, the first boot may not complete, in that case simply reboot the device. - -This is quite common with USB2 sticks. - -By default the serial console is configured and activated at the rate of 115200 bps. - -## How to create your 1st AGL application - -[Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) diff --git a/getting-started/machines/qemu.md b/getting-started/machines/qemu.md deleted file mode 100644 index 7bd14c0..0000000 --- a/getting-started/machines/qemu.md +++ /dev/null @@ -1,119 +0,0 @@ -# Building the AGL Demo Platform for QEMU - -To build the QEMU version of the AGL demo platform use machine **qemux86-64** along with features **agl-demo** and **agl-devel**: - -```bash -source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 agl-demo agl-devel -bitbake agl-demo-platform -``` - -By default, the build will produce a compressed *vmdk* image in **tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz** - -## Deploying the AGL Demo Platform for QEMU - -### Prepare an image for boot - -Decompress the **agl-demo-platform-qemux86-64.vmdk.xz** image to prepare it for boot. - -#### Linux - -```bash -cd tmp/deploy/images/qemux86-64 -xz -d agl-demo-platform-qemux86-64.vmdk.xz -``` - -#### Windows - -Download [7-Zip](http://www.7-zip.org/) and select **agl-demo-platform-qemux86-64.vmdk.xz** to be decompressed. - -## Boot an image - -### QEMU - -#### Install QEMU - -**Note**: if an AGL crosssdk has been created, it will contain a qemu binary for the host system. This SDK qemu binary has no graphics support and cannot currently be used to boot an AGL image. - -*Arch*: - -```bash -sudo pacman -S qemu -``` - -*Debian/Ubuntu*: - -```bash -sudo apt-get install qemu-system-x86 -``` - -*Fedora*: - -```bash -sudo yum install qemu-kvm -``` - -#### Boot QEMU - -Boot the **agl-demo-platform-qemux86-64.vmdk** image in qemu with kvm support: - -```bash -qemu-system-x86_64 -enable-kvm -m 2048 \ - -hda agl-demo-platform-qemux86-64.vmdk \ - -cpu kvm64 -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt \ - -vga virtio -show-cursor \ - -device virtio-rng-pci \ - -serial mon:stdio -serial null \ - -soundhw hda \ - -net nic,vlan=0 \ - -net user,hostfwd=tcp::2222-:22 -``` - -### VirtualBox - -#### Install VirtualBox - -Download and install [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 5.2.0 or later. - -#### Boot VirtualBox - -Boot the **agl-demo-platform-qemux86-64.vmdk** image in VirtualBox: - -* Start VirtualBox -* Click **New** to create a new machine - * Enter **AGL QEMU** as the *Name* - * Select **Linux** as the *Type* - * Select **Other Linux (64-bit)** as the *Version* - * Set *Memory size* to **2 GB** - * Click **Use an existing virtual hard disk file** under *Hard disk* - * Navigate to and select the **agl-demo-platform-qemux86-64.vmdk** image -* Ensure that the newly created **AGL QEMU** machine is highlighted and click **Start** - -### VMWare Player - -#### Install VMWare Player - -Download and install [VMWare Player](https://www.vmware.com/products/player/playerpro-evaluation.html) - -#### Boot VMWare Player - -Boot the **agl-demo-platform-qemux86-64.vmdk** image in VMWare Player: - -* Start VMWare Player -* Select **File** and **Create a New Virtual Machine** - * Select **I will install the operating system later** and click **Next** - * Select **Linux** as the *Guest Operating System*, **Other Linux 3.x kernel 64-bit** as the *Version*, and click **Next** - * Enter **AGL QEMU** as the *Name* and click **Next** - * Leave *disk capacity settings* unchanged and click **Next** - * Click **Finish** -* Select/highlight **AGL QEMU** and click **Edit virtual machine settings** - * Select/highlight **Memory** and click **2 GB** - * Select/highlight **Hard Disk (SCSI)** and click **Remove** - * Click **Add** - * Select **Hard Disk** and click **Next** - * Select **SCSI (Recommended)** and click **Next** - * Select **Use an existing virtual disk** and click **Next** - * Browse and select the **agl-demo-platform-qemux86-64.vmdk** image - * Click **Finish** - * Click **Keep Existing Format** - * Click **Save** -* Ensure that the newly created **AGL QEMU** machine is highlighted and click **Power On** diff --git a/getting-started/machines/raspberrypi.md b/getting-started/machines/raspberrypi.md deleted file mode 100644 index e016584..0000000 --- a/getting-started/machines/raspberrypi.md +++ /dev/null @@ -1,39 +0,0 @@ -# Building the AGL Demo Platform for Raspberry Pi - -## Raspberry Pi 3 - -To build AGL demo platform for Raspberry Pi 3 use machine **raspberrypi3** and feature **agl-demo**: - -```bash -source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-appfw-smack -bitbake agl-demo-platform -``` - -## Raspberry Pi 2 - -To build AGL demo platform for Raspberry Pi 2 use machine **raspberrypi2** and feature **agl-demo**: - -```bash -source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-appfw-smack -bitbake agl-demo-platform -``` - -## Booting AGL Demo Platform on Raspberry Pi - -Follow the steps below to copy the image to microSD card and to boot it on Raspberry Pi 2 or 3: - -* Connect your sdcard in your linux machine. -* Copy output image from build machine to linux machine that is connected your sdcard. (Often, those are same machines) -* Output Image location in build machine for Raspberry Pi 2: *tmp/deploy/images/raspberrypi2/agl-demo-platform-raspberrypi2.wic.xz* -* Output Image location in build machine for Raspberry Pi 3: *tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic.xz* -* Unmount the microSD card and after that flash output image to it card with root user: - -*Note: the sdimage files can also be named rpi-sdimg-ota in case you have the **"agl-sota"** feature enabled* - -```bash -sudo umount [sdcard device] -xzcat [output image] | sudo dd of=[sdcard device] bs=4M -sync -``` - -* Plug your microSD card into Raspberry Pi 2 or 3 and boot the board diff --git a/getting-started/setup-sdk-environment.md b/getting-started/setup-sdk-environment.md deleted file mode 100644 index 691702c..0000000 --- a/getting-started/setup-sdk-environment.md +++ /dev/null @@ -1,124 +0,0 @@ -# AGL SDK Quick Setup - -This tutorial explains how to quickly setup an environment suitable to building and packaging AGL Applications using the SDK and a Docker container. - -The current tutorial has been tested on Linux, but may work with a few adjustments for Windows or MacOS. - -## Step 1: install Docker - -First install docker on your host, if not already done. -General instructions for Linux are available on the [Docker Site](https://docs.docker.com/engine/installation/linux/). - -Add yourself to the docker group. - -## Step 2: setup persistent workspace - -Docker images are pre-configured to use a particular uid:gid to enable the use -of OpenEmbedded build system. They provide a dedicated user account *devel* -which belong to uid=1664(devel) gid=1664(devel). (Note: password is *devel*) - -The script 'create_container' presented below instantiates a new container -and shares some volumes with the host: - -* /xdt (the build directory inside the container) is stored in ~/ssd/xdt_$ID (specific to instance ID) -* /home/devel/mirror is stored in ~/ssd/localmirror_$ID (specific to instance ID) -* /home/devel/share => points to ~/devel/docker/share (shared by all containers) - -Those shared volumes with the host needs the proper permissions to be accessible -from the contained environment. - -```bash -mkdir ~/ssd ~/devel -chmod a+w ~/ssd ~/devel -``` - -**Note**: - -* To gain access from your host on files created within the container, your - host account requires to be added to group id 1664. - -## Step 3: install the "Generic AGL Worker" Docker Image - -### Get docker image - -#### Pre-built image - -A pre-built image is available on automotivelinux download public site and can be used directly. - -First, download and load the image in your local Docker instance: - -```bash -wget -O - https://download.automotivelinux.org/AGL/snapshots/sdk/docker/docker_agl_worker-latest.tar.xz | docker load; -docker images; - REPOSITORY TAG IMAGE ID CREATED SIZE - docker.automotivelinux.org/agl/worker-generic 5.99-95 6fcc19b4e0d7 2 weeks ago 1.56GB - jenkins latest 55720d63e328 5 weeks ago 711.9 MB - hello-world latest c54a2cc56cbb 5 months ago 1.848 kB -``` - -Identify the IMAGE_ID you just loaded. In the example above, this is 6fcc19b4e0d7 - -```bash -export IMAGE_ID=6fcc19b4e0d7 -``` - -#### Rebuilt image - -The Docker image for AGL Worker can be rebuilt using the scripts published here [docker-worker-generator](https://git.automotivelinux.org/AGL/docker-worker-generator/). - -### Start image - -Then, use the 'create_container' script to start a new, fresh container based on the AGL Worker image: - -**Note**: - -* The password for the id 'devel' inside the docker image is 'devel'. - -```bash -git clone https://git.automotivelinux.org/AGL/docker-worker-generator; -cd docker-worker-generator; -./contrib/create_container 0 $IMAGE_ID; -docker ps; - CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES - 4fb7c550ad75 6fcc19b4e0d7 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx -``` - -## Step 4: install the AGL SDK for your target - -Here, we assume that we just built an image 'agl-demo-platform-crosssdk' using the Yocto build procedure documented in the [Getting Started](../) section of the documentation. - -So we can copy such file to the shared volume. - -For example, we could have built the SDK from another worker container listening with SSH on port 2223: - -```bash -create_container 1; -ssh -p 2223 devel@mybuilder.local; -... [ prepare build environment ] ... -bitbake agl-demo-platform-crosssdk; -... [ build happens in /xdt/build ] ... -cp /xdt/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh ~/share; -``` - -then login to the first "SDK Container" and install the SDK: - -```bash -ssh -p 2222 devel@mysdk.local; -install_sdk ~/share/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh; -``` - -## Step 5: build your application - -First, you must source the SDK environment you wish to use (you MUST repeat this step each time you open a new shell): - -```bash -source /xdt/sdk/environment-setup- -``` - -You're then ready to go: get the sources, run the builds ... - -```bash -git clone ; -cd ; -cmake; make; make package; -``` diff --git a/getting-started/source-code.md b/getting-started/source-code.md deleted file mode 100644 index 3c5d6f4..0000000 --- a/getting-started/source-code.md +++ /dev/null @@ -1,201 +0,0 @@ -# Introduction: Building target AGL image with Yocto project - -The standard Yocto process is made of the following steps: - -* Setting up your operating system. -* Setting up the build environment for R-Car BSP. -* Downloading the proprietary drivers and installing them in the build environment (if needed). -* Build the image. -* Boot using SD-CARD. - * Create an SD-CARD. - * Configure to boot on SD-CARD. - * Copy the image to the SD-CARD. - * Boot the board on it. - -For convenience, the resulting development images are made available [Here][AGL snapshots master latest] - -If you want to bypass the build phase and quick boot the board, you can download the image tarball and the kernel then follow the installation procedure. - -## Setting up your operating system - -The very first step is to ensure that your system can run the build system of the Yocto Project. - -**Important**: it only runs on Linux - -* if your system is Windows© or iOS© you should use a virtualization solution (Virtualbox, VMWare ...) to run a Linux VM on your system. - -For AGL 6.0, Yocto Project 2.4, known as rocko, has been selected for the BSP and build system. - -Reference data for configuring your system can be found in the Yocto documentation [Here][yocto ref Manual] - -Here after an extract of this documentation for most common Linux distributions: - -* The build system should be able to run on any modern distributions that has the following versions for: - * Python - * Git 1.7.8 or greater - * tar 1.24 or greater - * GCC, … - -**Note**: - -* Python 2.7.3 or greater excluding Python 3.x, which is not supported. - -### Ubuntu and Debian - -The essential and graphical support packages you need for a supported Ubuntu or Debian distribution are shown in the following command: - -```bash -sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ - build-essential chrpath socat libsdl1.2-dev xterm cpio curl -``` - -**Note**: - -* Also note that for this tutorial, the utility 'curl' has been added to the list of packages to install. - -### Fedora - -The essential and graphical packages you need for a supported Fedora distribution are shown in the following command: - -```bash -sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ - diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ - ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \ - SDL-devel xterm curl -``` - -### OpenSUSE - -The essential and graphical packages you need for a supported OpenSUSE distribution are shown in the following command: - -```bash -sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \ - diffstat texinfo python-curses patch socat libSDL-devel xterm curl \ - python3 python3-curses glibc-locale -``` - -### CentOS - -The essential and graphical packages you need for a supported CentOS distribution are shown in the following command: - -```bash -sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ - diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ - socat SDL-devel xterm curl -``` - -## Download AGL Source Code - -The AGL source code and Yocto layers are maintained on the AGL Gerrit server. -For information on how to create accounts for gerrit see [Getting Started with AGL][Getting Started with AGL]. - -### Setting up the build environment - -In the following, your top level directory is noted as “AGL_TOP”. -For example, we will set AGL_TOP to point to a directory “$HOME/workspace_agl”: - -```bash -export AGL_TOP=$HOME/workspace_agl -mkdir -p $AGL_TOP -``` - -### Prepare Repo Tool - -AGL Uses the 'repo' tool for managing repositories. -You need to setup layers of AGL. -You can use the commands below to prepare Repo: - -```bash -mkdir -p ~/bin -export PATH=~/bin:$PATH -curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo -chmod a+x ~/bin/repo -``` - -**Note**: - -* More information about the tool 'repo' [Here][repo info] - -### Download source - -You can choose your source release - -### Download Latest Stable Release - -To download all layers for the for the latest stable release, eel 5.0.3: - -```bash -cd $AGL_TOP -repo init -b eel -m eel_5.1.0.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -repo sync -``` - -### Download Master Branch - -To download all code from master: - -```bash -cd $AGL_TOP -repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -repo sync -``` - -## Set up Build Environment Info - -AGL has created a set up script for defining the target build and desired optional features. - -To get a complete list of the options available run. - -```bash -cd $AGL_TOP -source meta-agl/scripts/aglsetup.sh -h -``` - -Once you run aglsetup.sh with your desired parameters, you can build any target desired. - -## Features supported by aglsetup - -Here is the list of features for AGL 2.1 that can be specified in the aglsetup.sh command line: - -* in **meta-agl** - * agl-all-features - * agl-appfw-smack: enables IoT.bzh Application Framework + SMACK + Cynara - * agl-archiver - * agl-ci - * agl-ci-change-features - * agl-ci-change-features-nogfx - * agl-ci-snapshot-features - * agl-ci-snapshot-features-nogfx - * agl-devel: activate development options (empty root password, debugger, strace, valgrind …) - * agl-gplv2 - * agl-isafw - * agl-netboot: enable network boot support through TFTP and NBD (see meta-netboot layer) - * agl-profile-graphical - * agl-profile-graphical-html5 - * agl-profile-graphical-qt5 - * agl-profile-hud - * agl-profile-telematics - * agl-ptest - * agl-sota: enable SOTA components and dependencies (meta-sota, meta-filesystems, meta-ruby, meta-rust are added) -* in **meta-agl-demo** - * agl-demo: enable layer meta-agl-demo and meta-qt5 - required to build * agl-demo-platform - * agl-iotivity - * agl-sdl -* in **meta-agl-devel** - * agl-audio-4a-framework - * agl-audio-soundmanager-framework - * agl-egvirt - * agl-hmi-framework - * agl-oem-extra-libs - * agl-renesas-kernel - * agl-telemetry -* in **meta-agl-extra** - * agl-localdev: add a local layer named “meta-localdev” in meta directory and a local.dev.inc conf file if present - * blsched - -For newer features or to get more details on a given feature, take a look at the configuration files stored for each feature and/or each machine in meta-agl/templates and meta-agl-extra/templates. - -[AGL snapshots master latest]: https://download.automotivelinux.org/AGL/snapshots/master/latest/ -[yocto ref Manual]: http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#detailed-supported-distros -[Getting Started with AGL]: https://wiki.automotivelinux.org/start/getting-started -[repo info]: https://source.android.com/source/using-repo.html diff --git a/getting-started/troubleshooting.md b/getting-started/troubleshooting.md deleted file mode 100644 index d3ad889..0000000 --- a/getting-started/troubleshooting.md +++ /dev/null @@ -1,210 +0,0 @@ -# Troubleshooting - -## Extended attributes MUST be copied - -**IMPORTANT, The extended attribute set during image construction MUST be copied to the SD card.** - -When using tar to create the SDcard, it is a common error to not copy the extended attributes. Find below instruction for using tar. - -Verify that **tar** version is 1.28 or newer: - -```bash -tar --version -tar (GNU tar) 1.28 -[snip] -``` - -If it is not the case, a native up-to-date version of tar is also generated while building AGL distribution: - -```bash -tmp/sysroots/x86_64-linux/usr/bin/tar-native/tar --version -tar (GNU tar) 1.28 -[snip] -``` - -To copy Automotive Grade Linux (AGL) files AND EXTENDED ATRIBUTES onto the SDcard using tar the command is: - -```bash -tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --totals \ - --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz -``` - -## meta-rust - -Due to a known bug in the upstream of meta-rust the Yocto/OE recipe for rust-cross may fail while building RVI SOTA Client or another application written in the Rust programming language. -Until the complete resolution of the issue the workaround is to disable all use of the CXX11 ABI by applying the following lines to **conf/local.conf**: - -```bash -LD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0" -TARGET_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0" -CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0" - -BUILD_CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" -TARGET_CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" -``` - -## Screen orientation for Splash and in Weston - -Depending of your scren mounting the default orientation of the UI an/or splash screen might be incorrect. -To change the orientation of the splash screen patch - -```bash -File: /etc/systemd/system/sysinit.target.wants/psplash-start.service -Line: ExecStart=/usr/bin/psplash -n -a 90 -``` - -To change the orientation of the UI in Weston patch - -```bash -File: /etc/xdg/weston/weston.ini -Line: transform=90 -``` - -## Disabling Homescreen in AGL 4.0.x DD release - -**Problem**: new installed applications are not available on Homescreen and even if started manually through afm-util, the application starts but no surface appears. - -**Answer**: this is due to IVI-Shell integration with Qt and Homescreen. - -To disable IVI-Shell and revert to the "plain old" weston desktop, you can follow the 4 steps below: - -* Modify */etc/xdg/weston/weston.ini* and comment the line mentioning IVI-shell. For example on Porter board: - -```bash - [core] - backend=drm-backend.so - #shell=ivi-shell.so - ... -``` - -* modify */etc/afm/unit.env.d/qt-for-ivi-shell* and comment the line specifying QT Wayland backend: - -```bash - ... - #Environment=QT_WAYLAND_SHELL_INTEGRATION=ivi-shell - ... -``` - -(If you use vi, remove backup files by `rm /etc/afm/unit.env.d/*~`) - -* disable Homescreen services: - -```bash - # systemctl --user mask HomeScreen.service -``` - -* Reboot your target and you should then be able to start apps on the standard weston screen using afm-util - -## Adding media files to play with MediaPlayer - -AGL include the default MediaPlayer sample app which can be used to play music. The `lightmediascanner.service` by default will search for media under the `/media` folder. So if you plug in any USB stick containing music, they would be recognized and showed in the playlist of the MediaPlayer app menu. - -The current supported format is OGG. Please convert your files to ogg to play with MediaPlayer. - -In case you want to store music in another place, modify the `/usr/lib/systemd/user/lightmediascanner.service` file and change the `--directory` parameter to the path of that folder. - -If you don’t want to touch the ligthmediascanner service, you can also add a folder named "Music" under `/home/root` and put your music files there. - -## Configuring the Audio hardware - -AGL uses alsa as Audio configuration master. If the correct HW is not setup, the Audio system will fail to start what will also fails the demo Home Screen launch. -You need to configure Audio in 2 places - -* alsa -* 4A HAL - -### alsa - - The file /etc/asound.conf (at the beginning) tells which hardware will be used. - For example on an Intel Minnow or UP board your need to enter the following configuration. - -```bash - pcm.Speakers { - type dmix - slave {pcm "hw:PCH,3"} - ipc_key 1001 # ipc_key should be unique to each dmix - } -``` - -The correct value (here hw:PCH,3) can be obtained with the command: - -```bash - aplay -l - **** List of PLAYBACK Hardware Devices **** - card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] - Subdevices: 1/1 - Subdevice #0: subdevice #0 - card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] - Subdevices: 1/1 - Subdevice #0: subdevice #0 -``` - -Using hw:PCH rather than hw:0 will avoid you many trouble.\ -NOTE that the device number is not always 0. If you give no device number, alsa will assume device 0 (and the not the first available device), what can fail your configuration.\ -As the default is hw:0 (card 0 device 0), it will always fail on a Minnow or UP board. - -For info HW device for common configuration are: - -* for USB Audio -> hw:AUDIO,0 -* for Intel Analog output -> hw:PCH,0 (not available on Minnow, Joule, Up boards, ...) -* for Intel via -> HDMI hw:PCH,3 -* for MOST Unicens -> hw:ep016ch,0 - -### 4A HAL configuration - -AGL 4A needs to know which HAL shall be used. This is configured in the file: - -```bash -/usr/agl-service-audio-4a/ahl-agl-service-audio-4a-config.json -``` - -At the beginning of that file you will find the slected HAL (note the there is no correct default value). - -```bash -{ - "version": "0.2.0", - "policy_module": "AudioPolicy_v1", - "description": "High-level binding configuration file", - "note": "Devices and routings are always listed in order of priority (for device selection rules)", - "hal_list": ["intel-minnow"], - "audio_roles": [ -``` - -Here you see "intel-minnow" but common values are: - -* Intel laptop -> intel-pc -* Intel via HDMI -> intel-minnow -* Renesas -> Rcar-M3 -* USB Audio Speaker -> usb-audio -* MOSTS Unicens -> hal-most-unicens - -More HAL can be found on Gerrit (search projects named as 4a-hal*) - -## Installing the Map for the Navigation Application - -While the Navigation App is installed with all other demo Apps at first boot, the Maps required to be installed manually. - -### a) Method 1 on target download - - 1. Install the new image on the target - 2. boot a first time to install the demo Apps - 3. via ssh or serial connection, execute the script - * /usr/AGL/apps/download_mapdata_uk.sh\ - or - * /usr/AGL/apps/download_mapdata_jp.sh - -### b) At image creation - -Download on your build machine the desired maps and uncompress them on your target image before 1st boot. -This method is quicker and does not require to have the network enabled on the target device. -Map can be found here. - -* -* - -Once that you have built your image on the SD card, uncompress the desired map in on the SD card at the position /YourMountPoint/var/mapdata\ -(YourMountPoint will vary with your build system). - -You can also use the script from the image to install the Mapdata on your SD card but there is little adavange in using that method. e.g. - -* download_mapdata_jp.sh /YourMountPoint diff --git a/platform/working-on-the-chinook-branch.md b/platform/working-on-the-chinook-branch.md deleted file mode 100644 index c211650..0000000 --- a/platform/working-on-the-chinook-branch.md +++ /dev/null @@ -1,122 +0,0 @@ -# Working on the chinook branch - -## Intro - -This is a quick howto for working on the 'Charming Chinook' branch. Working on the branch -is easy as we maintain all changes through gerrit.automotivelinux.org. -If you are unfamiliar with gerrit, please read these fine how-to pages were put together from the -Mediawiki community here: . This covers the basics very well. Of course we'll work with gerrit.automotivelinux.org instead so apply likewise. - -## Installation of tools - -Install `git` with your distributions package manager. -A very useful tool is "git-review" (cmdline is then `git review`). -Install it from your distro or with `sudo pip install git-review`. - -## Prerequisites - -It is important to setup git and gerrit properly (see the Tutorial page mentioned above): - -* prereq #1) make sure git is properly setup with name/email -* prereq #2) make sure your ssh key is in gerrit.automotivelinux.org - -## Cloning, editing and submitting for review - -Follow these steps to submit a change to the 'Charming Chinook' branch: - -1. cloning the (tip of the) branch - - ```bash - repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo - repo sync - ``` - -1. Change the recipe in question (one change at a time - small is better) - - ```bash - vi recipe-foo/bar/baz.bb - ``` - -1. Do a a few builds and tests (try 2 architectures if possible) - - ```bash - source meta-agl/scripts/aglsetup.sh .... agl-all-features - bitbake agl-demo-platform - ``` - -1. once satisfied do commit your change as usual in git - Make sure to do a proper commit message: - - - ```bash - git commit -s - - ``` - -1. All repos have .gitreview files already, so now it is just - - ```bash - git review - ``` - -1. (optional, but highly recommended!) Reset to gerrit/chinook - - ```bash - git checkout chinook` - git reset --hard gerrit/chinook - ``` - - It helps during the review process as gerrit would otherwise enforce - the whole series of patches to be reviewed/merged together (2nd depends on 1st patch). - -1. Rinse (=6) and repeat (=2-5) - -## Using git review to review/test-build a specific change in gerrit - -'git review' is also useful if you want to review a change. -Example for meta-agl: - -```bash - repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo - repo sync - cd meta-agl/ - git review -d 8105 -``` - -This will pull-down change 8105. Now we can build with it applied: - -```bash - cd .. - source ... - bitbake ... -``` - -## Using gerrit to amend a changeset while in review - -The same workflow applies if you want to _amend_ a changeset while it is in review (not merged, yet): - -```bash -cd meta-agl/ -git review -d 8105 -``` - -This will pull-down change 8105. You can now edit a file: - -```bash -vi recipes-foo/bar/baz.bb -git commit -s --amend -``` - - Don't forget a test build - -```bash -cd .. -source meta-agl/scripts/aglsetup.sh ..... agl-all-features -bitbake ... # e.g. agl-demo-platform -``` - - Finally call git review to upload the change - -```bash -git review -``` \ No newline at end of file diff --git a/platform/working-on-the-master-branch.md b/platform/working-on-the-master-branch.md deleted file mode 100644 index 31f0c04..0000000 --- a/platform/working-on-the-master-branch.md +++ /dev/null @@ -1,122 +0,0 @@ -# Working on the master branch - -## Intro - -This is a quick howto for working on the 'master' branch. Working on the branch -is easy as we maintain all changes through gerrit.automotivelinux.org. -If you are unfamiliar with gerrit, please read these fine how-to pages were put together from the -Mediawiki community here: . This covers the basics very well. Of course we'll work with gerrit.automotivelinux.org instead so apply likewise. - -## Installation of tools - -Install `git` with your distributions package manager. -A very useful tool is "git-review" (cmdline is then `git review`). -Install it from your distro or with `sudo pip install git-review`. - -## Prerequisites - -It is important to setup git and gerrit properly (see the Tutorial page mentioned above): - -* prereq #1) make sure git is properly setup with name/email -* prereq #2) make sure your ssh key is in gerrit.automotivelinux.org - -## Cloning, editing and submitting for review - -Follow these steps to submit a change to the 'master' branch: - -1. cloning the (tip of the) branch - - ```bash - repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo - repo sync - ``` - -1. Change the recipe in question (one change at a time - small is better) - - ```bash - vi meta-xyz/recipe-foo/bar/baz.bb - ``` - -1. Do a a few builds and tests (try 2 architectures if possible) - - ```bash - source meta-agl/scripts/aglsetup.sh .... agl-all-features - bitbake agl-demo-platform - ``` - -1. once satisfied do commit your change as usual in git - Make sure to do a proper commit message: - - - ```bash - git commit -s - - ``` - -1. All repos have .gitreview files already, so now it is just - - ```bash - git review - ``` - -1. (optional, but highly recommended!) Reset to gerrit/master - - ```bash - git checkout master - git reset --hard gerrit/master - ``` - - It helps during the review process as gerrit would otherwise enforce - the whole series of patches to be reviewed/merged together (2nd depends on 1st patch). - -1. Rinse (=6) and repeat (=2-5) - -## Using git review to review/test-build a specific change in gerrit - -'git review' is also useful if you want to review a change. -Example for meta-agl: - -```bash - repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo - repo sync - cd meta-agl/ - git review -d 8233 -``` - -This will pull-down change 8233. Now we can build with it applied: - -```bash - cd .. - source ... - bitbake ... -``` - -## Using gerrit to amend a changeset while in review - -The same workflow applies if you want to _amend_ a changeset while it is in review (not merged, yet): - -```bash -cd meta-agl/ -git review -d 8233 -``` - -This will pull-down change 8233. You can now edit a file: - -```bash -vi meta-xyz/recipes-foo/bar/baz.bb -git commit -s --amend -``` - - Don't forget a test build - -```bash -cd .. -source meta-agl/scripts/aglsetup.sh ..... agl-all-features -bitbake ... # e.g. agl-demo-platform -``` - - Finally call git review to upload the change - -```bash -git review -``` \ No newline at end of file diff --git a/security-blueprint/README.md b/security-blueprint/README.md deleted file mode 100644 index a3cf24c..0000000 --- a/security-blueprint/README.md +++ /dev/null @@ -1,158 +0,0 @@ -# Introduction - -Modern cars have become a lot more technologically sophisticated and different than those of the past. We are seeing a wider range of new features and functionality, with a lot more complex software. It is fair to say that the cars being introduced to the market today have much more in common with computing devices like cell phones, than their predecessors did. Modern car manufacturers are also integrating support for a broad range of communication technologies for these “connected” cars. With the advent of such vehicles, Linux has become a natural choice for the software platform, with Automotive Grade Linux as a promising example. - -From a security point of view, the remote capabilities of a connected car results in a much larger attack surface. This opens a whole new world of security vulnerabilities that need to be considered during the architectural design. History shows that physical access to a device is sufficient for a hacker to gain root privileges. This makes the car a hostile environment. - -The Security Blueprint documents the security features that are included as part of Automotive Grade Linux (AGL) and identifies areas that need to be addressed from a security perspective as part of AGL. It also gives guidance around existing technologies and solutions. - -Security domains will allow us to create a set of tests verifying the security of Automotive Grade Linux. - -This document is firstly based on an existing AGL security-blueprint. - -**For security to be effective, the concepts must be simple. And by default, anything that is not allowed is forbidden.** - -We will cover topics starting from the lowest level (_Hardware_) up to the highest levels (_Connectivity_ and _Application_). We will move quickly on _Hardware_ and _Connectivity_ because this is not supported at our level. Solutions of connectivity problems concern updates and secured settings while hardware securing is related to the manufacturers. - -The document is filled with tags to easily identify important points: - - - -- The _config_ tag quickly identifies the configurations and the recommendations to take. - - - -- The _note_ tag allows you to notify some additional details. - - - -- The _todo_ tag shows the possible improvements. - - - -In annexes of this document, you can find all the _config_ and _todo_ notes. - -## Adversaries - -Adversaries and attackers within the Automotive space. - -- Enthusiast Attackers - -Enthusiast attackers have physical access to the Engine Control Units (ECUs) at the circuit board level. They can solder ‘mod chips’ onto the board and have access to probing tools. They also have information on ECUs that have been previously compromised and have access to softwares and instructions developed by other members of car modification forums. The goal of the enthusiast hacker could be, but is not limited to, adding extra horse power to the car or hacking it just for fun. - -- Corrupt Automotive Dealers - -Corrupt automotive dealers are attackers that have access to the same capabilities as enthusiasts, but also have access to the car manufacturer’s (OEM) dealer network. They may also have access to standard debugging tools provided by the car manufacturer. Their goal may be to support local car theft gangs or organized criminals. - -- Organized Criminals - -Organized criminals have access to all of the above tools but may also have some level of control over the internal network at many dealerships. They may have hacked and gained temporary control of the Over-The-Air (OTA) servers or the In-Vehicle Infotainment (IVI) systems. This is very much like the role of organized criminals in other industries such as paid media today. Their goal is to extort money from OEMs and/or governments by threatening to disable multiple vehicles. - -- Malware Developers - -Malware developers have developed malicious software to attack and compromise a large number of vehicles. The malicious software is usually designed to spread from one vehicle to another. Usually, the goal is to take control of multiple machines and then sell access to them for malicious purposes like denial-of-service (DoS) attacks or theft of private information and data. - -- Security Researchers - -Security researchers are ‘self-publicized’ security consultants trying to make a name for themselves. They have access to standard tools for software security analysis. They also have physical access to the vehicle and standard hardware debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to publicize attacks for personal gain or just to gain personal understanding with a sense of helping make things more secure. - -## Attack Goals - -In today’s connected vehicle, more and more functionality is moving to software control, meaning that the threat of attack becomes greater and greater. We see car features like navigation and summoning, car access/engine start, and motor/ECU upgrades all controlled through software and connections to the cloud. The risk of attack is high because there are high value targets in play. - -Here, we outline some of the major threats categories along with some sample attackers, example attacks, and a relative importance. These threat categories are intended to be general examples. There can be many nuances to threat types. Additionally, there can be many sub-attacks that eventually lead to these higher level attack goals. - -| Threat Category | Sample Attacker | Example Attacks | Relative Importance | -|-------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------| -| Vehicle theft | Individual, organized criminals | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity) | -| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury) | -| Vehicle hacking | Vehicle owner, competitor | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) | -| Sensitive asset theft | Organized criminals, blackmailers | Steal credit card numbers, health information, camera data, steal bandwidth | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later) | - -The Automotive Grade Linux (AGL) initiative builds upon open-source software including Linux and Tizen to offer a flexible application framework. However, the security provisions of the app framework, Cynara, and the security manager only go so far in keeping the biggest threats at bay. As experience has shown, providing a constrained app (like that in the Android Open Source Platform) and store development flow, signature verification, DAC sandboxing, and MAC (SMACK) controls over the platform can have a certain amount of success with the security of the system. However, the openness of the system invites many researchers, hobbyists and hackers and financially motivated attackers to compromise the system for their own gains. - -As AGL arrives on modern automobiles, this is inevitably inviting many capable actors to modify, attack, and compromise these well thought-out systems and their applications. With concerns like safety and security, the auto industry cannot afford to go the way of consumer devices like phones and tablets where security problems are encountered on a frequent basis. It is imperative to use a layered approach and defense-in-depth to protect the system from inevitable attack. - -## Assets and Security Categorization - -This section outlines some of the assets that are likely to be found in the vehicle and their relative sensitivity from an attack point of view. Additionally, the final column on the right lists some of the recommended protection types that can be applied to these types of assets (Note that the empty cells refer to the cells above them). A good protection approach will give priority to the most sensitive assets, using a defense-in-depth approach to cover these assets. Less sensitive assets are treated at a lower priority, typically protected with fewer protection techniques. A more fine-grained prioritization of the the assets in a concrete vehicle network can be achieved with detailed threat analysis which considers the topology of the vehicle network and access-controls that are in-place. e.g. the EVITA framework for attack trees. - -| Asset Category | Examples | Sensitivity | Recommended Protection Types | -|-------------------|--------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Software | ECU software, infotainment software, OS images | Critical | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS | -| Car Access | Biometric data, car keys | | | -| Payment Data | Credit cards, User profile critical data | | | -| Recordings | Internal camera recording, internal audio recording, external camera recording | High | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation | -| User Profile | Usernames and passwords, customization, calendar, contacts | | | -| Location | GPS coordinates, vehicle usage data | | | -| Purchased Content | Video, audio, licenses | | | -| Teleconference | Chat, audio, video | Medium | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission | -| Vehicle data | Vehicle info, sensor data | | | -| Navigation data | Static and dynamic maps | | | -| 3rd party data | Home automation commands, cloud game data | | | - -## Hardening term - -The term Hardening refers to the tools, techniques and processes required in order to reduce the attack surface on an embedded system, such as an embedded control unit (**ECU**) or other managed devices. The target for all hardening activities is to prevent the execution of invalid binaries on the device, and to prevent copying of security related data from the device. - - - -## AGL security overview - -AGL roots are based on security concepts. Those concepts are implemented by the security framework as shown in this picture: - -![AGL architecture](WhiteBoxArchi.png) - --------------------------------------------------------------------------------- - -# Acronyms and Abbreviations - -The following table lists the strongest terms utilized within all this document. - -| Acronyms or Abbreviations | Description | -|---------------------------|-------------------------------------| -| _AGL_ | **A**utomotive **G**rade **L**inux | -| _ECU_ | **E**lectronic **C**ontrol **U**nit | - --------------------------------------------------------------------------------- - - - -# References - -- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html). - - _http:// docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_ -- **[2017]** - [kernel security](https://www.kernel.org/doc/Documentation/security/). - - _https:// www.kernel.org/doc/Documentation/security/_ -- **[2017]** - [Systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf). - - _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_ -- **[2017]** - [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf). - - _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_ -- **[2017]** - [Improving Vehicle Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf). - - _https:// access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_ -- **[2016]** - [AGL framework overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html). - - _http:// docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_ -- **[2016]** - [SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf). - - _http:// iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_ -- **[2016]** - [Linux Automotive Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf). - - _http:// iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_ -- **[2016]** - [Automotive Security Best Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf). - - _https:// www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_ -- **[2016]** - [Gattacking Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf). - - _http:// gattack.io/whitepaper.pdf_ -- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf). - - _http:// www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_ -- **[2015]** - [Security in Automotive Bus Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf). - - _http:// citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_ -- **[2014]** - [IOActive Remote Attack Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf). - - _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_ -- **[2011]** - [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf). - - _https:// media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_ -- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf). - - _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_ -- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf). - - _https:// eprint.iacr.org/2010/332.pdf_ -- **[2010]** - [Wifi attacks wep wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf). - - _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_ -- **[2008]** - [SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf). - - _http:// schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_ diff --git a/security-blueprint/WhiteBoxArchi.png b/security-blueprint/WhiteBoxArchi.png deleted file mode 100644 index d984d1a..0000000 Binary files a/security-blueprint/WhiteBoxArchi.png and /dev/null differ diff --git a/security-blueprint/annexes/0_Abstract.md b/security-blueprint/annexes/0_Abstract.md deleted file mode 100644 index 9db5fee..0000000 --- a/security-blueprint/annexes/0_Abstract.md +++ /dev/null @@ -1,7 +0,0 @@ -# Annexes - -The first part resumed all the configurations you must implement without any -explications since all the explanations are given as and when in the document. - -The second one allows to visualize all the todo notes in order to have a global -vision of the possible improvements of the document. diff --git a/security-blueprint/annexes/ConfigNotes.md b/security-blueprint/annexes/ConfigNotes.md deleted file mode 100644 index b3770fa..0000000 --- a/security-blueprint/annexes/ConfigNotes.md +++ /dev/null @@ -1,485 +0,0 @@ -# Config notes - - -Domain | Object | Recommendations --------------------- | ---------- | ---------------------------------- -Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. -Hardware-Integrity-2 | Board | Must use a HSM. -Hardware-Integrity-3 | RTC | Must not be alterable. - -Domain | Object | Recommendations ----------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. -Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. -Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. - -Domain | Object | Recommendations ------------------ | ---------- | ------------------------------------------------------------------------------------ -Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. -Hardware-Memory-2 | Bootloader | Internal NVM only -Hardware-Module-3 | - | HSM must be used to secure keys. - -Domain | _Variable_ / `Config` name | `Value` ----------------------- | -------------------------- | ------- -Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` -Boot-Image-Selection-2 | _bootdelay_ | `-2` - -Domain | `Config` name | _State_ -------------------------- | ---------------------------- | -------- -Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ -Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ -Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ -Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ -Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ -Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ - -Domain | Communication modes | _State_ --------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- -Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. -Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. -Boot-Communication-3 | `Ethernet` | _Disabled_ -Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ -Boot-Communication-5 | `Serial ports` | _Disabled_ - -Domain | `Config` name | _State_ ------------------------- | ----------------------- | ------------- -Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ -Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ -Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ -Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ -Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ - -Domain | Communication modes | _State_ --------------------- | -------------------- | --------------------------------------------------------------------------------------------- -Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. - -Domain | Object | Recommendations --------------------- | --------------------------------- | ------------------------------------------------------------- -Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. - -Domain | `Command` name | _State_ --------------------------- | -------------- | --------- -Boot-Communication-Flash-1 | `do_nand` | _Disable_ - -Domain | `Config` name | `Value` ----------------------- | --------------------------------------- | --------- -Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` -Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` -Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` - -Domain | `Environment variable` name | _State_ ----------------------- | --------------------------- | ------------- -Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ - -Domain | `Config` name | _State_ --------------------------- | ---------------------------- | --------- -Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` -Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` -Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` -Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` -Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` -Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` -Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` -Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` -Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` -Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` -Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` -Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` - -Domain | `Command` name | _State_ ------------------------ | -------------- | ---------- -Boot-Consoles-MemDump-1 | `md` | _Disabled_ -Boot-Consoles-MemDump-2 | `mm` | _Disabled_ -Boot-Consoles-MemDump-3 | `nm` | _Disabled_ -Boot-Consoles-MemDump-4 | `mw` | _Disabled_ -Boot-Consoles-MemDump-5 | `cp` | _Disabled_ -Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ -Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ -Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ -Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ - -Domain | `Config` name | `Value` --------------------- | -------------- | -------------------------------------- -Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m -Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m -Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y -Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y -Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y -Kernel-General-MAC-6 | CONFIG_SECURITY | y -Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y -Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y - -Domain | `Config` name | `Value` ----------------------- | -------------- | ------- -Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` - -Domain | `Config` name | `Value` ---------------------------- | --------------- | ------- -Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` - -Domain | `Config` name | `Value` -------------------------------- | ----------------------- | ------- -Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` - -Domain | `Config` name | `Value` ----------------------------- | --------------- | ------- -Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` - -Domain | `Config` name | `Value` ---------------------------- | ------------------------------ | ------- -Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` - -Domain | `Config` name | `Value` ----------------------------- | ---------------------- | ------- -Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` - -Domain | `Config` name | `Value` --------------------------- | -------------------- | ------- -Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` -Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` - -Domain | `Config` name | `Value` ------------------------- | ---------------- | ------- -Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` - -Domain | `Config` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` - -Domain | `Variable` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` - -Domain | Object | _State_ ------------------------- | ------------------- | ---------- -Kernel-General-Drivers-1 | `USB` | _Disabled_ -Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ -Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ - -Domain | `compiler` and `linker` options | _State_ --------------------------------- | ------------------------------- | -------- -Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ - -Domain | `compiler` and `linker` options | _State_ ---------------------------------- | ------------------------------- | -------- -Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ -Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ - -Domain | Object | Recommendations -------------------------------- | --------------- | -------------------------------- -Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. - -Domain | `Config` name | `Value` ------------------------------- | ---------------- | ------- -Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` - -Domain | `Config` name | `Value` ------------------------- | ------------------- | ------- -Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` - -Domain | `Config` name | `Value` --------------------- | ------------- | ------- -Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` -Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` - -Domain | `Config` name | `Value` ---------------------- | -------------------------- | ------- -Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` - -Domain | `compiler` and `linker` options | _State_ ------------------------------ | ------------------------------- | -------- -Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ - -Domain | `compiler` options and `config` name | `Value` -------------------------------- | ------------------------------------ | ------- -Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` -Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` - -Domain | `Config` name | `Value` ------------------------- | ---------------------------- | ------- -Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` -Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` -Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` -Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` - -Domain | `Config` name | `Value` ------------------------------ | ------------------------- | ----------------------------------- -Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` -Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` -Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` - -Domain | `Config` name | `Value` ----------------------- | ------------- | ------- -Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` - -Domain | `Config` name | `Value` ------------------------ | -------------------- | ------- -Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` - -Domain | `Config` name | `Value` ------------------------------- | -------------------- | ------- -Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` - -Domain | `Config` name | `Value` ----------------------- | ------------------- | ------- -Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` - -Domain | `Config` name | `Value` ----------------------- | ---------------- | ------- -Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` - -Domain | `Config` name | `Value` ------------------------- | ------------------ | ------- -Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` -Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` - -Domain | `Config` name | `Value` ------------------------- | ------------------------- | ------- -Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` - -Domain | `Config` name | `Value` ------------------- | --------------------- | ------- -Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` -Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` - -Domain | `Config` name | `Value` -------------------------- | ----------------- | ------- -Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` - -Domain | `Config` name | `Value` ------------------- | ------------- | ------- -Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` - -Domain | `Config` name | `Value` ------------------------- | ----------------- | ------- -Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` - -Domain | `File` name | `Value` ----------------------------- | -------------------------------- | ------- -Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` - -Domain | `File` or `Directorie` name | _State_ ----------------------------- | --------------------------- | ----------------------------- -Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ - -Domain | `File` name | `Value` --------------------- | --------------------------------- | ------- -Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` - -Domain | `Config` name | `Value` ---------------------- | ----------------- | ------- -Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` - -Domain | `Config` name | `Value` ------------------------- | --------------- | ------- -Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` -Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` - -Domain | `Partition` | `Value` --------------------------- | ------------------- | ----------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. -Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. - -Domain | `Config` name | _State_ or `Value` --------------------------- | ----------------------- | ----------------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. - -Domain | `Label` name | Recommendations ------------------- | ------------ | ----------------------------------------------------------- -Kernel-MAC-Floor-1 | `^` | Only for privileged system services. -Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. - -Domain | `Label` name | Recommendations -------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. -Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. -Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. -Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. -Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. - -Domain | `Label` name | Recommendations -------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. -Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. -Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. - -Domain | Object | Recommendations ------------------- | -------------- | ------------------------------------ -Platform-SystemD-1 | Security model | Use Namespaces for containerization. -Platform-SystemD-2 | Security model | Use CGroups to organise processes. - -Domain | Object | Recommendations ---------------- | -------------- | ------------------------------------ -Platform-DBus-1 | Security model | Use D-Bus as IPC. -Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) - -Domain | `Tool` name | _State_ --------------------- | ----------- | ------- -Platform-Utilities-1 | `connman` | _Used_ as a connection manager. -Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. -Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. -Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. - -Domain | Object | Recommendations ----------------------- | -------------- | -------------------------------- -Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. - -Domain | Object | Recommendations ------------------------ | ----------- | ------------------------------------- -Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - -Domain | `Tool` name | _State_ --------------------- | ----------- | ---------------------------------------------------------------------- -Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. - -Domain | `Utility` name and normal `path` | _State_ ---------------------- | ---------------------------------------------------- | ---------- -Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ -Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ -Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ -Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ -Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ -Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ -Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ -Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ -Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ -Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ -Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ -Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ -Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ -Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ -Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ -Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ -Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ -Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ -Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ -Platform-Utilities-22 | `SSH` | _Disabled_ -Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ -Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ -Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ -Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ -Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ -Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ -Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ -Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ -Platform-Utilities-31 | `awk` (busybox) | _Enabled_ -Platform-Utilities-32 | `cut` (busybox) | _Enabled_ -Platform-Utilities-33 | `df` (busybox) | _Enabled_ -Platform-Utilities-34 | `echo` (busybox) | _Enabled_ -Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ -Platform-Utilities-36 | `grep` (busybox) | _Enabled_ -Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ -Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ -Platform-Utilities-39 | `printf` (busybox) | _Enabled_ -Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ -Platform-Utilities-41 | `tail` (busybox) | _Enabled_ -Platform-Utilities-42 | `tee` (busybox) | _Enabled_ -Platform-Utilities-43 | `test` (busybox) | _Enabled_ - -Domain | Object | Recommendations ---------------------- | ---------------- | ----------------------------------------------------- -Platform-Users-root-1 | Main application | Should not execute as root. -Platform-Users-root-2 | UI | Should run in a context on a user with no capability. - -Domain | `Utility` name | _State_ ---------------------- | -------------- | ------------- -Platform-Users-root-3 | `login` | _Not allowed_ -Platform-Users-root-4 | `su` | _Not allowed_ -Platform-Users-root-5 | `ssh` | _Not allowed_ -Platform-Users-root-6 | `scp` | _Not allowed_ -Platform-Users-root-7 | `sftp` | _Not allowed_ - -Domain | Object | Recommendations --------------------------- | --------- | ----------------------------------------------------------------------- -Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. -Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. - -Domain | Tech name | Recommendations ----------------------------------- | --------- | -------------------------------------------------------------------------- -Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. - -Domain | Tech name | Recommendations ------------------------------------------ | --------- | ---------------------------------------------------------------------- -Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. -Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. -Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. -Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. - -Domain | Object | Recommendations ------------------------ | ------ | ------------------------------------------------------------------ -Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. - -Domain | Tech name or object | Recommendations ----------------------------- | ------------------- | ------------------------------------------------------------------------- -Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled -Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used -Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. -Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. -Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. - -Domain | Tech name | Recommendations ---------------------------------- | ------------- | ------------------------------------------------------------ -Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. -Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring -Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. -Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. -Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. - -Domain | Tech name | Recommendations --------------------------------- | --------- | -------------------------- -Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid -Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. - -Domain | Tech name | Recommendations ------------------------------ | --------- | -------------------------------------------- -Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. - -Domain | Tech name | Recommendations ---------------------------- | --------- | ------------------------------------------------------ -Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. -Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. - -Domain | Object | Recommendations ----------------------------- | -------------- | -------------------------------------- -Application-Cloud-Download-1 | authentication | Must implement authentication process. -Application-Cloud-Download-2 | Authorization | Must implement Authorization process. - -Domain | Object | Recommendations ----------------------------------- | ------------- | ---------------------------------------------------------- -Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. -Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. -Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. -Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). -Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. - -Domain | Object | Recommendations ------------------------------ | ----------------------------------------- | --------------------------------- -Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. - - diff --git a/security-blueprint/annexes/todoNotes.md b/security-blueprint/annexes/todoNotes.md deleted file mode 100644 index d1d4b6f..0000000 --- a/security-blueprint/annexes/todoNotes.md +++ /dev/null @@ -1,80 +0,0 @@ -# Todo notes - - -Domain | Improvement ---------------- | ---------------------------------------------------- -Boot-Abstract-1 | More generic and add examples (The chain of trust). - -Domain | Improvement ---------------- | ------------------------------------------- -Boot-Abstract-1 | Review the definition of the "boot loader". - -Domain | Improvement ---------------- | ------------------------------------ -Boot-Consoles-1 | Secure loader: No reference earlier? - -Domain | Improvement ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). - -Domain | Improvement --------------------------------- | ----------------------------- -Kernel-General-IndependentExec-1 | Kernel or/and platform part ? - -Domain | Improvement -------------------------------- | --------------- -Kernel-General-LibraryLinking-1 | Keep this part? - -Domain | Improvement -------------------- | -------------------------------- -Platform-Abstract-1 | Create a graphics and sound part. - -Domain | Improvement -------------------- | ----------- -Platform-Services-1 | SystemD ? -Platform-Services-2 | Secure daemon ? - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - -Domain | Improvement --------------------------- | ------------------------------ -Application-Installation-1 | Talk about AppFw offline mode. - -Domain | Improvement ------------------------ | ---------------------------------------------------------- -Application-Signature-1 | Add content (see secure build in Secure development part). - -Domain | Improvement ----------------------- | ------------ -Application-Services-1 | Add content (Which services?). -Application-Services-2 | Add Binder. - -Domain | Improvement ------------------------ | ----------------- -Connectivity-Abstract-1 | Improve abstract. - -Domain | Improvement ------------------------ | ------------------------------------------- -Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - -Domain | Improvement -------------- | ----------------- -Update-SOTA-1 | Part to complete. - -Domain | Improvement ------------------------ | ------------ -SecureDev-SecureBuild-1 | Add content. - -Domain | Improvement ----------------------- | ------------ -SecureDev-Signatures-1 | Add content. - -Domain | Improvement ---------------------- | ----------------------------------------------------- -SecureDev-CodeAudit-1 | Add CVE analyser. -SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). - - diff --git a/security-blueprint/index.md b/security-blueprint/index.md deleted file mode 100644 index 1ca88b3..0000000 --- a/security-blueprint/index.md +++ /dev/null @@ -1,22 +0,0 @@ ---- - -title : security-blueprint -date : 2017-12-07 -version : 4.99.4 -category: security -tags: security, architecture, automotive, linux -layout: techdoc - ---- - -## [Intro](./intro.html) -## [Hardware](./part-1/0_Abstract.html) -## [Secure Boot](./part-2/0_Abstract.html) -## [Hypervisor](./part-3/0_Abstract.html) -## [Kernel](./part-4/0_Abstract.html) -## [Platform](./part-5/0_Abstract.html) -## [Application](./part-6/0_Abstract.html) -## [Connectivity](./part-7/0_Abstract.html) -## [Update (OTA)](./part-8/0_Abstract.html) -## [Secure development](./part-9/0_Abstract.html) -## [Annexes](./annexes/0_Abstract.html) diff --git a/security-blueprint/part-1/0_Abstract.md b/security-blueprint/part-1/0_Abstract.md deleted file mode 100644 index e13c464..0000000 --- a/security-blueprint/part-1/0_Abstract.md +++ /dev/null @@ -1,77 +0,0 @@ -# Part 1 - Hardware - -## Abstract - -The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services. -The platform includes the following hardware: - -- SoC (System-on-Chip). -- Memory (RAM, ROM, storage, etc.). -- Peripherals. - -You will find in this first part everything that concerns the hardware security. -The goal is to protect system against all attacks that are trying to gain -additional privileges by recovering and/or changing cryptographic keys in order -to alter the integrity of the boot. We should also prevent hardware modifications -in order to achieve this goal. We will expose below some examples of possible -configurations. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | -------------------------------------- -_HSM_ | **H**ardware **S**ecurity **M**odule -_NVM_ | **N**on-**V**olatile **M**emory -_SHE_ | **S**ecure **H**ardware **E**xtensions - --------------------------------------------------------------------------------- - -## Integrity - -The board must store hardcoded cryptographic keys in order to verify among others -the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and **SHE** to -enhance the security of their board. - - - -Domain | Object | Recommendations --------------------- | ---------- | ---------------------------------- -Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. -Hardware-Integrity-2 | Board | Must use a HSM. -Hardware-Integrity-3 | RTC | Must not be alterable. - - - --------------------------------------------------------------------------------- - - - -## Certificates - - - -Domain | Object | Recommendations ----------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. -Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. -Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. - - - --------------------------------------------------------------------------------- - -## Memory - - - -Domain | Object | Recommendations ------------------ | ---------- | ------------------------------------------------------------------------------------ -Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. -Hardware-Memory-2 | Bootloader | Internal NVM only -Hardware-Module-3 | - | HSM must be used to secure keys. - - diff --git a/security-blueprint/part-2/0_Abstract.md b/security-blueprint/part-2/0_Abstract.md deleted file mode 100644 index fa99d89..0000000 --- a/security-blueprint/part-2/0_Abstract.md +++ /dev/null @@ -1,64 +0,0 @@ -# Part 2 - Secure boot - -## Abstract - - - -Domain | Improvement ---------------- | ---------------------------------------------------- -Boot-Abstract-1 | More generic and add examples (The chain of trust). - - - -Secure boot refers to preventing malicious software applications and -“unauthorized” operating systems from loading during the system start-up process. -The goal is to protect users from rootkits and other low-level malware attacks. -Modern bootloaders come with features that can be used to enable secure boot in the system. - -**Boot Hardening**: Steps/requirements to configure the boot sequence, in order -to restrict the device from executing anything other than the approved software -image. - -In this part, we will see a series of settings that will allow us to improve -security during boot phase. For the purposes of reference and explanation, we -are providing guidance on how to configure an embedded device that runs with a -3.10.17 Linux kernel. If the integrity is not checked or if a critical error -occurs, the system must boot on a very stable backup image. - -**Requirements**: These requirements must be met even if an alternative version -of the Linux kernel is chosen. - -**Recommendations**: Detailed best practices that should be applied in order to -secure a device. Although they are not currently listed as hard requirements, -they may be upgraded to requirements status in the future. In addition, specific -operators may change some of these recommendations into requirements based on -their specific needs and objectives. - - - -Domain | Improvement ---------------- | ------------------------------------------- -Boot-Abstract-1 | Review the definition of the "boot loader". - - - -**Boot loader**: The boot loader consists of the Primary boot loader residing -in **OTP** memory, sboot, U-Boot and Secure loader residing in external flash -(NAND or SPI/NOR flash memory). The CPU on power on or reset executes the -primary boot loader. The **OTP** primary boot loader makes the necessary initial -system configuration and then loads the secondary boot loader sboot from -external flash memory to ram memory. The sboot then loads the U-Boot along with -the Secure loader. U-Boot then verifies the Kernel/system image integrity, then -loads the Kernel/system image before passing control to it. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ----------------------------------------------------------------------- -_FUSE_ | **F**ilesystem in **U**ser**S**pac**E** -_OTP_ | **O**ne-**T**ime-**P**rogrammable -_DOCSIS_ | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification diff --git a/security-blueprint/part-2/1-Image.md b/security-blueprint/part-2/1-Image.md deleted file mode 100644 index 453b397..0000000 --- a/security-blueprint/part-2/1-Image.md +++ /dev/null @@ -1,52 +0,0 @@ -# Image - -## Image selection - -The boot process shall be uninterruptible and shall irrevocably boot the image -as specified in the boot environment. - -In U-Boot set the "_bootdelay_" environment variable and/or define -`CONFIG_BOOTDELAY` to _-2_. - - - -Domain | _Variable_ / `Config` name | `Value` ----------------------- | -------------------------- | ------- -Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` -Boot-Image-Selection-2 | _bootdelay_ | `-2` - - - --------------------------------------------------------------------------------- - -## Image authenticity - -It shall not be possible to boot from an unverified image. The secure boot -feature in U-Boot shall be enabled. The secure boot feature is available from -U-Boot 2013.07 version. To enable the secure boot feature, enable the following -features: - -``` -CONFIG_FIT: Enables support for Flat Image Tree (FIT) uImage format. -CONFIG_FIT_SIGNATURE: Enables signature verification of FIT images. -CONFIG_RSA: Enables RSA algorithm used for FIT image verification. -CONFIG_OF_CONTROL: Enables Flattened Device Tree (FDT) configuration. -CONFIG_OF_SEPARATE: Enables separate build of u-Boot from the device tree. -CONFIG_DEFAULT_DEVICE_TREE: Specifies the default Device Tree used for the run-time configuration of U-Boot. -``` - -Generate the U-Boot image with public keys to validate and load the image. It -shall use RSA2048 and SHA256 for authentication. - - - -Domain | `Config` name | _State_ -------------------------- | ---------------------------- | -------- -Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ -Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ -Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ -Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ -Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ -Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ - - diff --git a/security-blueprint/part-2/2-Communication-modes.md b/security-blueprint/part-2/2-Communication-modes.md deleted file mode 100644 index 268da5d..0000000 --- a/security-blueprint/part-2/2-Communication-modes.md +++ /dev/null @@ -1,89 +0,0 @@ -# Communication modes - -## Disable USB, Serial and DOCSIS Support - -To disable USB support in U-Boot, following config's shall not be defined: - -``` -CONFIG_CMD_USB: Enables basic USB support and the usb command. -CONFIG_USB_UHCI: Defines the lowlevel part. -CONFIG_USB_KEYBOARD: Enables the USB Keyboard. -CONFIG_USB_STORAGE: Enables the USB storage devices. -CONFIG_USB_HOST_ETHER: Enables USB Ethernet adapter support. -``` - -In addition, disable unnecessary communication modes like Ethernet, Serial -ports, DOCSIS in U-Boot and sboot that are not necessary. - -Linux Kernel support for USB should be compiled-out if not required. If it is -needed, the Linux Kernel should be configured to only enable the minimum -required USB devices. User-initiated USB-filesystems should be treated with -special care. Whether or not the filesystems are mounted in userspace -(**FUSE**), restricted mount options should be observed. - - - -Domain | Communication modes | _State_ --------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- -Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. -Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. -Boot-Communication-3 | `Ethernet` | _Disabled_ -Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ -Boot-Communication-5 | `Serial ports` | _Disabled_ - - - -Domain | `Config` name | _State_ ------------------------- | ----------------------- | ------------- -Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ -Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ -Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ -Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ -Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ - - - --------------------------------------------------------------------------------- - -## Disable all unused Network Interfaces - -Only used network interfaces should be enabled. -Where possible, services should also be limited to those necessary. - - - -Domain | Communication modes | _State_ --------------------- | -------------------- | --------------------------------------------------------------------------------------------- -Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. - - - -## Remove or Disable Unnecessary Services, Ports, and Devices - -Restrict the `services`, `ports` and `devices` to those used. - - - -Domain | Object | Recommendations --------------------- | --------------------------------- | ------------------------------------------------------------- -Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. - - - -## Disable flash access - -**Recommendation**: - -In U-Boot following flash memory commands shall be disabled: - -**NAND**: Support for nand flash access available through `do_nand` has to be disabled. - - - -Domain | `Command` name | _State_ --------------------------- | -------------- | --------- -Boot-Communication-Flash-1 | `do_nand` | _Disable_ - - - -Similarly sboot should disable flash access support through command line if any. diff --git a/security-blueprint/part-2/3-Consoles.md b/security-blueprint/part-2/3-Consoles.md deleted file mode 100644 index 0a8faed..0000000 --- a/security-blueprint/part-2/3-Consoles.md +++ /dev/null @@ -1,107 +0,0 @@ -# Consoles - -## Disable serial console - -Serial console output shall be disabled. To disable console output in U-Boot, -set the following macros: - - - -Domain | `Config` name | `Value` ----------------------- | --------------------------------------- | --------- -Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` -Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` -Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` - - - -Domain | Improvement ---------------- | ------------------------------------ -Boot-Consoles-1 | Secure loader: No reference earlier? - - - -And set "**silent**" environment variable. For the Secure loader, -disable the traces by not defining the below macro: - - - -Domain | `Environment variable` name | _State_ ----------------------- | --------------------------- | ------------- -Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ - - - -For sboot proper configuration needs to be done to disable the serial console. - --------------------------------------------------------------------------------- - - - -## Immutable environment variables - -In U-Boot, ensure Kernel command line, boot commands, boot delay and other -environment variables are immutable. This will prevent side-loading of alternate -images, by restricting the boot selection to only the image in FLASH. - -The environment variables shall be part of the text region in U-Boot as default -environment variable and not in non-volatile memory. - -Remove configuration options related to non-volatile memory, such as: - - - -Domain | `Config` name | _State_ --------------------------- | ---------------------------- | --------- -Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` -Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` -Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` -Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` -Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` -Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` -Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` -Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` -Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` -Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` -Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` -Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` - - - --------------------------------------------------------------------------------- - - - -## (Recommendation) Removal of memory dump commands - -In U-Boot, following commands shall be disabled to avoid memory dumps: - -``` -md : Memory Display command. -mm : Memory modify command - auto incrementing address. -nm : Memory modify command - constant address. -mw : Memory write. -cp : Memory copy. -mwc : Memory write cyclic. -mdc : Memory display cyclic. -mtest : Simple ram read/write test. -loopw : Infinite write loop on address range. -``` - - - -Domain | `Command` name | _State_ ------------------------ | -------------- | ---------- -Boot-Consoles-MemDump-1 | `md` | _Disabled_ -Boot-Consoles-MemDump-2 | `mm` | _Disabled_ -Boot-Consoles-MemDump-3 | `nm` | _Disabled_ -Boot-Consoles-MemDump-4 | `mw` | _Disabled_ -Boot-Consoles-MemDump-5 | `cp` | _Disabled_ -Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ -Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ -Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ -Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ - - - -Similarly, memory dump support shall be disabled from sboot. diff --git a/security-blueprint/part-3/0_Abstract.md b/security-blueprint/part-3/0_Abstract.md deleted file mode 100644 index c6e3942..0000000 --- a/security-blueprint/part-3/0_Abstract.md +++ /dev/null @@ -1,18 +0,0 @@ -# Part 3 - Hypervisor - -Definition: "A hypervisor or virtual machine monitor (VMM) is computer software, -firmware or hardware that creates and runs virtual machines". - -It must include a signature verification (possibly delegated). - - - -Domain | Improvement ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). - - - -## Native or Bare-metal hypervisors - -These hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. Those are the ones we're interested in. diff --git a/security-blueprint/part-4/0_Abstract.md b/security-blueprint/part-4/0_Abstract.md deleted file mode 100644 index 01957e4..0000000 --- a/security-blueprint/part-4/0_Abstract.md +++ /dev/null @@ -1,60 +0,0 @@ -# Part 4 - Kernel - -## Abstract - -**System Hardening:** Best practices associated with the configuration of an -embedded Linux based operating system. This section includes both hardening of -the kernel itself, as well as specific configurations and patches used to -protect against known vulnerabilities within the build and configuration of the -root filesystem. - -At the Kernel level, we must ensure that no console can be launched. It could be -used to change the behavior of the system or to have more information about it. -Another aspect is the protection of the memory used by the Kernel. - -The next sub-sections contain information on various kernel configuration -options to enhance the security in the kernel (3.10.17) and also for -applications compiled to take advantage of these security features. -Additionally, there are also configuration options that protect from known -vulnerable configuration options. Here's a high level summary of various kernel -configurations that shall be required for deployment. - -## Kernel Version - -The choice of kernel version for the AGL system is essential to its security. -Depending on the type of board and eventual production system, different kernel -versions are used. For example, one of the systems under study uses the -Linux kernel version 3.10, while another uses the Linux kernel version 4.4. -For the Linux kernel version 3.10.31, there are 25 known vulnerabilities. -These vulnerabilities would allow an attacker to gain privileges, -bypass access restrictions, allow memory to be corrupted, or cause denial of service. -In contrast, the Linux kernel version of 4.4 has many fewer known vulnerabilities. -For this reason, we would in general recommend the later kernel version as a basis -for the platform. - -Note that, although there are fewer known vulnerabilities in the most recent kernel -versions there may be many unknown vulnerabilities underlying. -A rule of thumb is to update the kernel as much as possible to avoid the problems -you do know, but you should not be complacent in the trust that you place in it. -A defense-in-depth approach would then apply. - -If there are constraints and dependencies in upgrading to a newer kernel version -(e.g. device drivers, board support providers) and you are forced to an older -Linux kernel version, there need to be additional provisions made to reduce -the risk of kernel exploits, which can include memory monitoring, watch-dog services, -and system call hooking. In this case, further defense-in-depth techniques -may be required to mitigate the risk of attacks to known vulnerabilities, -which can also include runtime integrity verification of components -that are vulnerable to tampering. - -## Kernel Build Configuration - -The kernel build configuration is extremely important for determining the level -of access to services and to reduce the breadth of the attack surface. -Linux contains a great and flexible number of capabilities and this is only controlled -through the build configuration. For example, the `CONFIG_MODULES` parameter -allows kernel modules to be loaded at runtime extending the capabilities of the kernel. -This capability needs to be either inhibited or controlled at runtime through -other configuration parameters. For example, `CONFIG_MODULE_SIG_FORCE=y` ensures -that only signed modules are loaded. There is a very large number of kernel -configuration parameters, and these are discussed in detail in this section. diff --git a/security-blueprint/part-4/1-General.md b/security-blueprint/part-4/1-General.md deleted file mode 100644 index 54c7ea8..0000000 --- a/security-blueprint/part-4/1-General.md +++ /dev/null @@ -1,278 +0,0 @@ -# General configuration - -## Mandatory Access Control - -Kernel should controls access with labels and policy. - - - -Domain | `Config` name | `Value` --------------------- | -------------- | -------------------------------------- -Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m -Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m -Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y -Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y -Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y -Kernel-General-MAC-6 | CONFIG_SECURITY | y -Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y -Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y - - - -Please also refer to the [**Mandatory Access Control** documentation in Platform](../part-5/1-MAC.html) part. -You can also find useful documentation and links on wikipedia about [**MAC**](https://en.wikipedia.org/wiki/Mandatory_access_control) -and about [**SMACK**](https://en.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel). - --------------------------------------------------------------------------------- - -## Disable kexec - -**Kexec** is a system call that enables you to load and boot into another kernel from the currently running kernel. This feature is not required in a production environment. - - - -Domain | `Config` name | `Value` ----------------------- | -------------- | ------- -Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` - - - - - -**kexec** can load arbitrary kernels but signing of new kernel can be enforced like it is can be enforced for new modules. - - - --------------------------------------------------------------------------------- - -## Disable kernel IP auto-configuration - -It is preferable to have an IP configuration performed using a user-space tool as these tend to have more validation. We do not want the network interface coming up until the system has come up properly. - - - -Domain | `Config` name | `Value` ---------------------------- | --------------- | ------- -Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Sysctl syscall support - -Enabling this will result in code being included that is hard to maintain and not well tested. - - - -Domain | `Config` name | `Value` -------------------------------- | ----------------------- | ------- -Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Legacy Linux Support - -There are some Kernel Configs which are present only to support legacy binaries. See also "Consoles" part in order to disabling support for legacy binary formats. The `uselib` system call, in particular, has no valid use in any `libc6` or `uclibc` system in recent times. This configuration is supported in **Linux 3.15 and greater** and thus should only be disabled for such versions. - - - -Domain | `Config` name | `Value` ----------------------------- | --------------- | ------- -Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` - - - --------------------------------------------------------------------------------- - -## Disable firmware auto-loading user mode helper - -The firmware auto loading helper, which is a utility executed by the kernel on `hotplug` events requiring firmware, can to be set `setuid`. As a result of this, the helper utility is an attractive target for attackers with control of physical ports on the device. Disabling this configuration that is supported in **Linux 3.9 and greater**. - - - -Domain | `Config` name | `Value` ---------------------------- | ------------------------------ | ------- -Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` - - - - - -It doesn't strictly need to be `setuid`, there is an option of shipping firmware builtin into kernel without initrd/filesystem. - - - --------------------------------------------------------------------------------- - -## Enable Kernel Panic on OOPS - -When fuzzing the kernel or attempting kernel exploits attackers are likely to trigger kernel OOPSes. Setting the behavior on OOPS to PANIC can impede their progress. - -This configuration is supported in **Linux 3.5 and greater** and thus should only be enabled for such versions. - - - -Domain | `Config` name | `Value` ----------------------------- | ---------------------- | ------- -Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` - - - --------------------------------------------------------------------------------- - - - -## Disable socket monitoring interface - -These monitors can be used to inspect shared file descriptors on Unix Domain sockets or traffic on 'localhost' which is otherwise assumed to be confidential. - -The `CONFIG_PACKET_DIAG` configuration is supported in **Linux 3.7 and greater** and thus should only be disabled for such versions. - -The `CONFIG_UNIX_DIAG` configuration is supported in **Linux 3.3 and greater** and thus should only be disabled for such versions. - - - -Domain | `Config` name | `Value` --------------------------- | -------------------- | ------- -Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` -Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` - - - --------------------------------------------------------------------------------- - -## Disable BPF JIT - -The BPF JIT can be used to create kernel-payloads from firewall table rules. - -This configuration for is supported in **Linux 3.16 and greater** and thus should only be disabled for such versions. - - - -Domain | `Config` name | `Value` ------------------------- | ---------------- | ------- -Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` - - - --------------------------------------------------------------------------------- - -## Enable Enforced Module Signing - -The kernel should never allow an unprivileged user the ability to load specific kernel modules, -since that would provide a facility to unexpectedly extend the available attack surface. - -To protect against even privileged users, systems may need to either disable -module loading entirely, or provide signed modules -(e.g. `CONFIG_MODULE_SIG_FORCE`, or dm-crypt with LoadPin), to keep from having -root load arbitrary kernel code via the module loader interface. - -This configuration is supported in **Linux 3.7 and greater** and thus should only be enabled for such versions. - - - -Domain | `Config` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` - - - -It is also possible to block the loading of modules after startup with "kernel.modules_disabled". - - - -Domain | `Variable` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` - - - --------------------------------------------------------------------------------- - - - -## Disable all USB, PCMCIA (and other `hotplug` bus) drivers that aren't needed - -To reduce the attack surface, the driver enumeration, probe, and operation happen in the kernel. The driver data is parsed by the kernel, so any logic bugs in these drivers can become kernel exploits. - - - -Domain | Object | _State_ ------------------------- | ------------------- | ---------- -Kernel-General-Drivers-1 | `USB` | _Disabled_ -Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ -Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ - - - --------------------------------------------------------------------------------- - -## Position Independent Executables - - - -Domain | Improvement --------------------------------- | ----------------------------- -Kernel-General-IndependentExec-1 | Kernel or/and platform part ? - - - - - -Domain | `compiler` and `linker` options | _State_ --------------------------------- | ------------------------------- | -------- -Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ - - - -Produce a position independent executable on targets which supports it. - --------------------------------------------------------------------------------- - -## Prevent Overwrite Attacks - -`-z,relro` linking option helps during program load, several ELF memory sections need to be written by the linker, but can be turned read-only before turning over control to the program. This prevents some Global Offset Table GOT overwrite attacks, or in the dtors section of the ELF binary. - - - -Domain | `compiler` and `linker` options | _State_ ---------------------------------- | ------------------------------- | -------- -Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ -Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ - - - -During program load, all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only (due to `-z relro` above). This prevents GOT overwrite attacks. For very large application, this can incur some performance loss during initial load while symbols are resolved, but this shouldn't be an issue for daemons. - --------------------------------------------------------------------------------- - - - -## Library linking - - - -Domain | Improvement -------------------------------- | --------------- -Kernel-General-LibraryLinking-1 | Keep this part? - - - -It is recommended that dynamic linking should generally not be allowed. This will avoid the user from replacing a library with malicious library. - - - -Domain | Object | Recommendations -------------------------------- | --------------- | -------------------------------- -Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. - - - - - -Linking everything statically doesn't change anything wrt security as binaries will live under same user:group as libraries and setuid executables ignore `LD_PRELOAD/LD_LIBRARY_PATH`. It also increases RSS footprint and creates problems with upgrading. - - diff --git a/security-blueprint/part-4/2-Memory.md b/security-blueprint/part-4/2-Memory.md deleted file mode 100644 index d7af446..0000000 --- a/security-blueprint/part-4/2-Memory.md +++ /dev/null @@ -1,156 +0,0 @@ -# Memory - -## Restrict access to kernel memory - -The /dev/kmem file in Linux systems is directly mapped to kernel virtual memory. This can be disastrous if an attacker gains root access, as the attacker would have direct access to kernel virtual memory. - -To disable the /dev/kmem file, which is very infrequently used by applications, the following kernel option should be set in the compile-time kernel configuration: - - - -Domain | `Config` name | `Value` ------------------------------- | ---------------- | ------- -Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` - - - -In case applications in userspace need /dev/kmem support, it should be available only for authenticated applications. - --------------------------------------------------------------------------------- - -## Disable access to a kernel core dump - -This kernel configuration disables access to a kernel core dump from user space. If enabled, it gives attackers a useful view into kernel memory. - - - -Domain | `Config` name | `Value` ------------------------- | ------------------- | ------- -Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` - - - --------------------------------------------------------------------------------- - -## Disable swap - -If not disabled, attackers can enable swap at runtime, add pressure to the memory subsystem and then scour the pages written to swap for useful information. - - - -Domain | `Config` name | `Value` --------------------- | ------------- | ------- -Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` - - - - - -- Enabling swap at runtime require `CAP_SYS_ADMIN`. -- Swap block device is usually under root:disk. -- Linux never swaps kernel pages. -- If swap disabling is not possible, swap encryption should be enabled. - - - --------------------------------------------------------------------------------- - - - -## Disable "Load All Symbols" - -There is a /proc/kallsyms file which exposes the kernel memory space address of many kernel symbols (functions, variables, etc...). This information is useful to attackers in identifying kernel versions/configurations and in preparing payloads for the exploits of kernel space. - -Both `KALLSYMS_ALL` and `KALLSYMS` shall be disabled; - - - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` -Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` - - - --------------------------------------------------------------------------------- - -## Stack protection - -To prevent stack-smashing, similar to the stack protector used for ELF programs in user-space, the kernel can protect its internal stacks as well. - -This configuration is supported in **Linux 3.11 and greater** and thus should only be enabled for such versions. - -This configuration also requires building the kernel with the **gcc compiler 4.2 or greater**. - - - -Domain | `Config` name | `Value` ---------------------- | -------------------------- | ------- -Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` - - - -Other defenses include things like shadow stacks. - --------------------------------------------------------------------------------- - -## Disable access to /dev/mem - -The /dev/mem file in Linux systems is directly mapped to physical memory. This can be disastrous if an attacker gains root access, as the attacker would have direct access to physical memory through this convenient device file. It may not always be possible to disable such file, as some applications might need such support. In that case, then this device file should be available only for authenticated applications. - -This configuration is supported in **Linux 4.0 and greater** and thus should only be disabled for such versions. - - - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` - - - --------------------------------------------------------------------------------- - - - -## Disable cross-memory attach - -Disable the process_vm_*v syscalls which allow one process to peek/poke the virtual memory of another. - -This configuration is supported in **Linux 3.5 and greater** and thus should only be disabled for such versions. - - - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` - - - --------------------------------------------------------------------------------- - -## Stack Smashing Attacks - - - -Domain | `compiler` and `linker` options | _State_ ------------------------------ | ------------------------------- | -------- -Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ - - - -Emit extra code to check for buffer overflows, such as stack smashing attacks. - --------------------------------------------------------------------------------- - -## Detect Buffer Overflows - - - -Domain | `compiler` options and `config` name | `Value` -------------------------------- | ------------------------------------ | ------- -Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` -Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` - - - -Helps detect some buffer overflow errors. diff --git a/security-blueprint/part-4/3-Consoles.md b/security-blueprint/part-4/3-Consoles.md deleted file mode 100644 index c6cf80a..0000000 --- a/security-blueprint/part-4/3-Consoles.md +++ /dev/null @@ -1,78 +0,0 @@ -# Serial - -## Disable serial console - -The serial console should be disabled to prevent an attacker from accessing this powerful interface. - - - -Domain | `Config` name | `Value` ------------------------- | ---------------------------- | ------- -Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` -Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` -Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` -Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` - - - --------------------------------------------------------------------------------- - -## Bake-in the kernel command-line - -The kernel command-line is used to control many aspects of the booting kernel, and is prone to tampering as they are passed in RAM with little to no reverse validation on these parameters. To prevent this type of attack, the kernel shall be configured to ignore commands line arguments, and use pre-configured (compile time) options instead. - -Set the kernel command line in the `CONFIG_CMDLINE KConfig` item and then pass no arguments from the bootloader. - - - -Domain | `Config` name | `Value` ------------------------------ | ------------------------- | ----------------------------------- -Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` -Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` -Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` - - - -It is recommended that any per-device settings (e.g: MAC addresses, serial numbers, etc.) be stored and accessed from read-only memory (or files), and that any such parameters be verified (signature checking) prior to their use. - --------------------------------------------------------------------------------- - -## Disable KGDB - -The Linux kernel supports KGDB over USB and console ports. These mechanisms are controlled by the `kgdbdbgp` and `kgdboc` kernel command-line parameters. It is important to ensure that no shipping product contains a kernel with KGDB compiled-in. - - - -Domain | `Config` name | `Value` ----------------------- | ------------- | ------- -Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` - - - --------------------------------------------------------------------------------- - -## Disable magic sysrq support - -On a few architectures, you can access a powerful debugger interface from the keyboard. The same powerful interface can be present on the serial console (responding to serial break) of Linux on other architectures. Disable to avoid potentially exposing this powerful backdoor. - - - -Domain | `Config` name | `Value` ------------------------ | -------------------- | ------- -Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` - - - --------------------------------------------------------------------------------- - -## Disable support for binary formats other than ELF - -This will make possible to plug wrapper-driven binary formats into the kernel. It enables support for binary formats other than ELF. Providing the ability to use alternate interpreters would assist an attacker in discovering attack vectors. - - - -Domain | `Config` name | `Value` ------------------------------- | -------------------- | ------- -Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` - - diff --git a/security-blueprint/part-4/4-Debug.md b/security-blueprint/part-4/4-Debug.md deleted file mode 100644 index cce5fc0..0000000 --- a/security-blueprint/part-4/4-Debug.md +++ /dev/null @@ -1,208 +0,0 @@ -# Debug - -No debuggers shall be present on the file system. This includes, but is not limited to, the GNU Debugger client/server (commonly known in their short form names such as the `gdb` and `gdbserver` executable binaries respectively), the `LLDB` next generation debugger or the `TCF` (Target Communications Framework) agnostic framework. Including these binaries as part of the file system will facilitate an attacker's ability to reverse engineer and debug (either locally or remotely) any process that is currently executing on the device. - -## Kernel debug symbols - -Debug symbols should always be removed from production kernels as they provide a lot of information to attackers. - - - -Domain | `Config` name | `Value` ----------------------- | ------------------- | ------- -Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` - - - -These kernel debug symbols are enabled by other config items in the kernel. Care should be taken to disable those also. If `CONFIG_DEBUG_INFO` cannot be disabled, then enabling `CONFIG_DEBUG_INFO_REDUCED` is second best. - - - -At least `CONFIG_DEBUG_INFO_REDUCED` should be always enabled for developers to convert addresses in oops messages to line numbers. - - - --------------------------------------------------------------------------------- - -## Disable Kprobes - -Kprobes enables you to dynamically break into any kernel routine and collect debugging and performance information non-disruptively. You can trap at almost any kernel code address, specifying a handler routine to be invoked when the breakpoint is hit. - - - -Domain | `Config` name | `Value` ----------------------- | ---------------- | ------- -Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Tracing - -FTrace enables the kernel to trace every kernel function. Providing kernel trace functionality would assist an attacker in discovering attack vectors. - - - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Profiling - -Profiling and OProfile enables profiling the whole system, include the kernel, kernel modules, libraries, and applications. Providing profiling functionality would assist an attacker in discovering attack vectors. - - - -Domain | `Config` name | `Value` ------------------------- | ------------------ | ------- -Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` -Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` - - - --------------------------------------------------------------------------------- - -## Disable OOPS print on BUG() - -The output from OOPS print can be helpful in Return Oriented Programming (ROP) when trying to determine the effectiveness of an exploit. - - - -Domain | `Config` name | `Value` ------------------------- | ------------------------- | ------- -Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Kernel Debugging - -There are development-only branches of code in the kernel enabled by the `DEBUG_KERNEL` conf. This should be disabled to compile-out these branches. - - - -Domain | `Config` name | `Value` ------------------- | --------------------- | ------- -Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` -Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` - - - -In some kernel versions, disabling this requires also disabling `CONFIG_EMBEDDED`, and `CONFIG_EXPERT`. Disabling `CONFIG_EXPERT` makes it impossible to disable `COREDUMP`, `DEBUG_BUGVERBOSE`, `NAMESPACES`, `KALLSYMS` and `BUG`. In which case it is better to leave this enabled than enable the others. - --------------------------------------------------------------------------------- - - - -## Disable the kernel debug filesystem - -The kernel debug filesystem presents a lot of useful information and means of manipulation of the kernel to an attacker. - - - -Domain | `Config` name | `Value` -------------------------- | ----------------- | ------- -Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` - - - --------------------------------------------------------------------------------- - -## Disable BUG() support - -The kernel will display backtrace and register information for BUGs and WARNs in kernel space, making it easier for attackers to develop exploits. - - - -Domain | `Config` name | `Value` ------------------- | ------------- | ------- -Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` - - - --------------------------------------------------------------------------------- - -## Disable core dumps - -Core dumps provide a lot of debug information for hackers. So disabling core dumps are recommended in production builds. - -This configuration is supported in **Linux 3.7 and greater** and thus should only be disabled for such versions. - - - -Domain | `Config` name | `Value` ------------------------- | ----------------- | ------- -Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` - - - --------------------------------------------------------------------------------- - - - -## Kernel Address Display Restriction - -When attackers try to develop "run anywhere" exploits for kernel vulnerabilities, they frequently need to know the location of internal kernel structures. By treating kernel addresses as sensitive information, those locations are not visible to regular local users. - -**/proc/sys/kernel/kptr_restrict is set to "1"** to block the reporting of known kernel address leaks. - - - -Domain | `File` name | `Value` ----------------------------- | -------------------------------- | ------- -Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` - - - -Additionally, various files and directories should be readable only by the root user: `/boot/vmlinuz*`, `/boot/System.map*`, `/sys/kernel/debug/`, `/proc/slabinfo` - - - -Domain | `File` or `Directorie` name | _State_ ----------------------------- | --------------------------- | ----------------------------- -Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ - - - --------------------------------------------------------------------------------- - -## DMESG Restrictions - -When attackers try to develop "run anywhere" exploits for vulnerabilities, they frequently will use `dmesg` output. By treating `dmesg` output as sensitive information, this output is not available to the attacker. - -**/proc/sys/kernel/dmesg_restrict can be set to "1"** to treat dmesg output as sensitive. - - - -Domain | `File` name | `Value` --------------------- | --------------------------------- | ------- -Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` - - - -Enable the below compiler and linker options when building user-space applications to avoid stack smashing, buffer overflow attacks. - --------------------------------------------------------------------------------- - - - -## Disable /proc/config.gz - -It is extremely important to not expose the kernel configuration used on a production device to a potential attacker. With access to the kernel config, it could be possible for an attacker to build a custom kernel for the device that may disable critical security features. - - - -Domain | `Config` name | `Value` ---------------------- | ----------------- | ------- -Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` - - diff --git a/security-blueprint/part-4/5-FileSystems.md b/security-blueprint/part-4/5-FileSystems.md deleted file mode 100644 index 78f2050..0000000 --- a/security-blueprint/part-4/5-FileSystems.md +++ /dev/null @@ -1,60 +0,0 @@ -# File System - -## Disable all file systems not needed - -To reduce the attack surface, file system data is parsed by the kernel, so any logic bugs in file system drivers can become kernel exploits. - -### Disable NFS file system - -NFS FileSystems are useful during development phases, but this can be a very helpful way for an attacker to get files when you are in production mode, so we must disable them. - - - -Domain | `Config` name | `Value` ------------------------- | --------------- | ------- -Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` -Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` - - - --------------------------------------------------------------------------------- - - - -## Partition Mount Options - -There are several security restrictions that can be set on a filesystem when it is mounted. Some common security options include, but are not limited to: - -`nosuid` - Do not allow set-user-identifier or set-group-identifier bits to take effect. - -`nodev` - Do not interpret character or block special devices on the filesystem. - -`noexec` - Do not allow execution of any binaries on the mounted filesystem. - -`ro` - Mount filesystem as read-only. - -The following flags shall be used for mounting common filesystems: - - - -Domain | `Partition` | `Value` --------------------------- | ------------------- | ----------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. -Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. - - - -If `CONFIG_DEVTMPFS_MOUNT` is set, then the kernel will mount /dev and will not apply the `nosuid`, `noexec` options. Either disable `CONFIG_DEVTMPFS_MOUNT` or add a remount with `noexec` and `nosuid` options to system startup. - - - -Domain | `Config` name | _State_ or `Value` --------------------------- | ----------------------- | ----------------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. - - diff --git a/security-blueprint/part-5/0_Abstract.md b/security-blueprint/part-5/0_Abstract.md deleted file mode 100644 index ddf7d2a..0000000 --- a/security-blueprint/part-5/0_Abstract.md +++ /dev/null @@ -1,103 +0,0 @@ -# Part 5 - Platform - -## Abstract - -The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services. -The platform includes the following software: - -- Linux **BSP** configured for reference boards. -- Proprietary device drivers for common peripherals on reference boards. -- Application framework. -- Windows/layer management (graphics). -- Sound resource management. -- An atomic software update system (chapter Update). -- Building and debug tools (based on Yocto project). - - - -Domain | Improvement -------------------- | -------------------------------- -Platform-Abstract-1 | Create a graphics and sound part. - - - -This part focuses on the AGL platform including all tools and techniques used to -upgrade the security and downgrade the danger. It must be possible to apply the -two fundamental principles written at the very beginning of the document. First -of all, security management must remain simple. You must also prohibit -everything by default, and then define a set of authorization rules. As cases -to deal with, we must: - -- Implement a **MAC** for processes and files. -- Limit communication between applications (_SystemBus_ and _SystemD_ part). -- Prohibit all tools used during development mode (_Utilities_ and _Services_ part). -- Manage user capabilities (_Users_ part). -- Manage application permissions and policies (_AGLFw_ part). - - - -The tools and concepts used to meet these needs are only examples. -Any other tool that meets the need can be used. - - - -In AGL, as in many other embedded systems, different security mechanisms settle -in the core layers to ensure isolation and data privacy. While the Mandatory -Access Control layer (**SMACK**) provides global security and isolation, other -mechanisms like **Cynara** are required to check application's permissions at -runtime. Applicative permissions (also called "_privileges_") may vary depending -on the user and the application being run: an application should have access to -a given service only if it is run by the proper user and if the appropriate -permissions are granted. - -## Discretionary Access Control - -**D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux method of separating -users and groups from one another. In a shared environment where multiple users -have access to a computer or network, Unix IDs have offered a way to contain access -within privilege areas for individuals, or shared among the group or system. -The Android system took this one step further, assigning new user IDs for each App. -This was never the original intention of Linux UIDs, but was able to provide -Android’s initial security element: the ability to sandbox applications. - -Although AGL mentions use of **DAC** for security isolation, the weight of the -security responsibility lies in the **M**andatory **A**ccess **C**ontrol (**MAC**) and **Cynara**. -Furthermore, there are system services with unique UIDs. however,the system -does not go to the extreme of Android, where every application has its own UID. -All sandboxing (app isolation) in AGL is handled in the **MAC** contexts. - -## Mandatory Access Control - -**M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**, -whereby extended attributes (xattr) are associated with the filesystem. -In the case of AGL, the smackfs filesystem allows files and directories -to be associated with a SMACK label, providing the ability of further -discrimination on access control. A SMACK label is a simple null terminated -character string with a maximum of 255 bytes. While it doesn’t offer the -richness of an SELinux label, which provides a user, role,type, and level, -the simplicity of a single value makes the overall design far less complex. -There is arguably less chance of the security author making mistakes in the policies set forth. - --------------------------------------------------------------------------------- - - - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | -------------------------------------------------------------- -_ACL_ | **A**ccess **C**ontrol **L**ists -_alsa_ | **A**dvanced **L**inux **S**ound **A**rchitecture -_API_ | **A**pplication **P**rogramming **I**nterface -_AppFw_ | **App**lication **F**rame**w**ork -_BSP_ | **B**oard **S**upport **P**ackage -_Cap_ | **Cap**abilities -_DAC_ | **D**iscretionary **A**ccess **C**ontrol -_DDOS_ | **D**istributed **D**enial **O**f **S**ervice -_DOS_ | **D**enial **O**f **S**ervice -_IPC_ | **I**nter-**P**rocess **C**ommunication -_MAC_ | **M**andatory **A**ccess **C**ontrol -_PAM_ | **P**luggable **A**uthentication **M**odules -_SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel diff --git a/security-blueprint/part-5/1-MAC.md b/security-blueprint/part-5/1-MAC.md deleted file mode 100644 index 73543e9..0000000 --- a/security-blueprint/part-5/1-MAC.md +++ /dev/null @@ -1,165 +0,0 @@ -# Mandatory Access Control - - - -We decided to put the **MAC** protection on the platform part despite the fact -that it applies to the kernel too, since its use will be mainly at the platform -level (except floor part). - - - -**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the -Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL -uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol -**K**ernel (**SMACK**). This protection involves the creation of **SMACK** -labels as part of the extended attributes **SMACK** labels to the file extended -attributes. And a policy is also created to define the behaviour of each label. - -The kernel access controls is based on these labels and this policy. If there -is no rule, no access will be granted and as a consequence, what is not -explicitly authorized is forbidden. - -There are two types of **SMACK** labels: - -- **Execution SMACK** (Attached to the process): Defines how files are - _accessed_ and _created_ by that process. -- **File Access SMACK** (Written to the extended attribute of the file): Defines - _which_ process can access the file. - -By default a process executes with its File Access **SMACK** label unless an -Execution **SMACK** label is defined. - -AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System -into the following domains: - -- Floor. -- System. -- Applications, Services and User. - -See [AGL security framework review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) and [Smack White Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf) -for more information. - --------------------------------------------------------------------------------- - - - -## Floor - -The _floor_ domain includes the base system services and any associated data and -libraries. This data remains unchanged at runtime. Writing to floor files or -directories is allowed only in development mode or during software installation -or upgrade. - -The following table details the _floor_ domain: - -Label | Name | Execution **SMACK** | File Access **SMACK** ------ | ----- | ------------------- | --------------------------------------- -`-` | Floor | `r-x` for all | Only kernel and internal kernel thread. -`^` | Hat | `---` for all | `rx` on all domains. -`*` | Star | `rwx` for all | None - - - -- The Hat label is Only for privileged system services (currently only - systemd-journal). Useful for backup or virus scans. No file with this label - should exist except in the debug log. - -- The Star label is used for device files or `/tmp` Access restriction managed - via **DAC**. Individual files remain protected by their **SMACK** label. - - - -Domain | `Label` name | Recommendations ------------------- | ------------ | ----------------------------------------------------------- -Kernel-MAC-Floor-1 | `^` | Only for privileged system services. -Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. - - - --------------------------------------------------------------------------------- - - - -## System - -The _system_ domain includes a reduced set of core system services of the OS and -any associated data. This data may change at runtime. - -The following table details the _system_ domain: - -Label | Name | Execution **SMACK** | File Access **SMACK** ----------------- | --------- | ----------------------------------------------- | --------------------- -`System` | System | None | Privileged processes -`System::Run` | Run | `rwxatl` for User and System label | None -`System::Shared` | Shared | `rwxatl` for system domain `r-x` for User label | None -`System::Log` | Log | `rwa` for System label `xa` for user label | None -`System::Sub` | SubSystem | Subsystem Config files | SubSystem only - - - -Domain | `Label` name | Recommendations -------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. -Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. -Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. -Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. -Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. - - - --------------------------------------------------------------------------------- - - - -## Applications, Services and User - -The _application_, _services_ and _user_ domain includes code that provides -services to the system and user, as well as any associated data. All code -running on this domain is under _Cynara_ control. - -The following table details the _application_, _services_ and _user_ domain: - -Label | Name | Execution **SMACK** | File Access **SMACK** -------------------- | ------ | --------------------------------------------------------------------------- | --------------------------- -`User::Pkg::$AppID` | AppID | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App -`User::Home` | Home | `rwx-t` from System label `r-x-l` from App | None -`User::App-Shared` | Shared | `rwxat` from System and User domains label of $User | None - - - -Domain | `Label` name | Recommendations -------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. -Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. -Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. - - - -## Attack Vectors - -There are 4 major components to the system: - -- The LSM kernel module. -- The `smackfs` filesystem. -- Basic utilities for policy management and checking. -- The policy/configuration data. - -As with any mandatory access system, the policy management needs to be carefully separated -from the checking, as the management utilities can become a convenient point of attack. -Dynamic additions to the policy system need to be carefully verified, as the ability to -update the policies is often needed, but introduces a possible threat. Finally, -even if the policy management is well secured, the policy checking and failure response -to that checking is also of vital importance to the smooth operation of the system. - -While **MAC** is a certainly a step up in security when compared to DAC, there are still -many ways to compromise a SMACK-enabled Linux system. Some of these ways are as follows: - -- Disabling SMACK at invocation of the kernel (with command-line: security=none). -- Disabling SMACK in the kernel build and redeploying the kernel. -- Changing a SMACK attribute of a file or directory at install time. -- Tampering with a process with the CAP_MAC_ADMIN privilege. -- Setting/Re-setting the SMACK label of a file. -- Tampering with the default domains (i.e. /etc/smack/accesses.d/default-access-domains). -- Disabling or tampering with the SMACK filesystem (i.e. /smackfs). -- Adding policies with `smackload` (adding the utility if not present). -- Changing labels with `chsmack` (adding the utility if not present). diff --git a/security-blueprint/part-5/2-SystemD.md b/security-blueprint/part-5/2-SystemD.md deleted file mode 100644 index 35abe16..0000000 --- a/security-blueprint/part-5/2-SystemD.md +++ /dev/null @@ -1,60 +0,0 @@ -# SystemD - -`afm-system-daemon` is used to: - -- Manage users and user sessions. -- Setup applications and services (_CGroups_, _namespaces_, autostart, permissions). -- Use of `libsystemd` for its programs (event management, **D-Bus** interface). - - - -Domain | Object | Recommendations ------------------- | -------------- | ------------------------------------ -Platform-SystemD-1 | Security model | Use Namespaces for containerization. -Platform-SystemD-2 | Security model | Use CGroups to organise processes. - - - -See [systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for more information. - -## Benefits - -- Removal of one privileged process: **afm-user-daemon** -- Access and use of high level features: - - - Socket activation. - - Management of users and integration of **PAM**. - - Dependency resolution to services. - - `Cgroups` and resource control. - - `Namespaces` containerization. - - Autostart of required API. - - Permissions and security settings. - - Network management. - - - -## CGroups - -Control Groups offer a lot of features, with the most useful ones you can -control: Memory usage, how much CPU time is allocated, how much device I/O is -allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise -processes (each service is a _CGroups_, and all processes started by that -service use that _CGroups_). By default, **SystemD** automatically creates a -hierarchy of slice, scope and service units to provide a unified structure for -the _CGroups_ tree. With the `systemctl` command, you can further modify this -structure by creating custom slices. Currently, in AGL, there are 2 slices -(**user.slice** and **system.slice**). - -## Namespaces - -### User side - -There are several ways of authenticating users (Key Radio Frequency, Phone, -Gesture, ...). Each authentication provides dynamic allocation of **uids** to -authenticated users. **Uids** is used to ensure privacy of users and **SMACK** -for applications privacy. - -First, the user initiates authentication with **PAM** activation. **PAM** -Standard offers highly configurable authentication with modular design like -face recognition, Voice identification or with a password. Then users should -access identity services with services and applications. diff --git a/security-blueprint/part-5/3-SystemBus.md b/security-blueprint/part-5/3-SystemBus.md deleted file mode 100644 index e2af387..0000000 --- a/security-blueprint/part-5/3-SystemBus.md +++ /dev/null @@ -1,24 +0,0 @@ -# D-Bus - -D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and -daemon) that helps applications to talk to each other. The use of D-Bus is great -because it allows to implement discovery and signaling. - -The D-Bus session is by default addressed by environment variable -`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable `DBUS_SESSION_BUS_ADDRESS` -is automatically set for user sessions. D-Bus usage is linked to permissions. - -D-Bus has already had several [security issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) -(mostly **DoS** issues), to allow applications to keep talking to each other. -It is important to protect against this type of attack to keep the system more -stable. - - - - -Domain | Object | Recommendations ---------------- | -------------- | ------------------------------------ -Platform-DBus-1 | Security model | Use D-Bus as IPC. -Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) - - diff --git a/security-blueprint/part-5/4-Services.md b/security-blueprint/part-5/4-Services.md deleted file mode 100644 index 013f693..0000000 --- a/security-blueprint/part-5/4-Services.md +++ /dev/null @@ -1,37 +0,0 @@ -# System services and daemons - - - -Domain | Improvement -------------------- | ----------- -Platform-Services-1 | SystemD ? -Platform-Services-2 | Secure daemon ? - - - -## Tools - -- **connman**: An internet connection manager designed to be slim and to use as - few resources as possible. It is a fully modular system that can be extended, - through plug-ins, to support all kinds of wired or wireless technologies. -- **bluez** is a Bluetooth stack. Its goal is to program an implementation of - the Bluetooth wireless standards specifications. In addition to the basic stack, - the `bluez-utils` and `bluez-firmware` packages contain low level utilities such - as `dfutool` which can interrogate the Bluetooth adapter chipset in order to - determine whether its firmware can be upgraded. -- **gstreamer** is a pipeline-based multimedia framework. It can be used to build - a system that reads files in one format, processes them, and exports them in - another format. -- **alsa** is a software framework and part of the Linux kernel that provides an - **API** for sound card device drivers. - - - -Domain | `Tool` name | _State_ --------------------- | ----------- | ------- -Platform-Utilities-1 | `connman` | _Used_ as a connection manager. -Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. -Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. -Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. - - diff --git a/security-blueprint/part-5/5-AppFw.md b/security-blueprint/part-5/5-AppFw.md deleted file mode 100644 index e92a0c6..0000000 --- a/security-blueprint/part-5/5-AppFw.md +++ /dev/null @@ -1,315 +0,0 @@ -# Application framework/model (**AppFw**) - -The AGL application framework consists of several inter-working parts: - -- **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) that performs extended access control of the system. -- **Cynara**: the native gatekeeper daemon used for policy handling, updating to the database and policy checking. -- Security Manager: a master service, through which all security events are intended to take place. -- Several native application framework utilities: `afm-main-binding`, `afm-user-daemon`, `afm-system-daemon`. - -The application framework manages: - -- The applications and services management: Installing, Uninstalling, Listing, ... -- The life cycle of applications: Start -> (Pause, Resume) -> Stop. -- Events and signals propagation. -- Privileges granting and checking. -- API for interaction with applications. - - - -- The **security model** refers to the security model used to ensure security - and to the tools that are provided for implementing that model. It's an - implementation detail that should not impact the layers above the application - framework. - -- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess **C**ontrol), - **MAC** (Mandatory Access Control) and `Capabilities` are used by the system to - ensure security and privacy. It also includes features of reporting using - audit features and by managing logs and alerts. - - - -The **AppFw** uses the security model to ensure the security and the privacy of -the applications that it manages. It must be compliant with the underlying -security model. But it should hide it to the applications. - - - -Domain | Object | Recommendations ----------------------- | -------------- | -------------------------------- -Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. - - - -See [AGL AppFw Privileges Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) and [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) for more -information. - - - -The Security Manager communicates policy information to **Cynara**, -which retains information in its own database in the format of a text -file with comma-separated values (CSV). There are provisions to retain -a copy of the CSV text file when the file is being updated. - -Runtime checking occurs through **Cynara**. Each application that is -added to the framework has its own instantiation of a SMACK context -and D-bus bindings. The afb_daemon and Binder form a web-service that -is communicated to through http or a websocket from the application-proper. -This http or websocket interface uses a standard unique web token for API communication. - -![Application Framework Flow](App-flow.png) - -## Cynara - -There's a need for another mechanism responsible for checking applicative -permissions: Currently in AGL, this task depends on a policy-checker service -(**Cynara**). - -- Stores complex policies in databases. -- "Soft" security (access is checked by the framework). - -Cynara interact with **D-Bus** in order to deliver this information. - -Cynara consists of several parts: - -- Cynara: a daemon for controlling policies and responding to access control requests. -- Database: a spot to hold policies. -- Libraries: several static and dynamic libraries for communicating with Cynara. - -The daemon communicates to the libraries over Unix domain sockets. -The database storage format is a series of CSV-like files with an index file. - -There are several ways that an attacker can manipulate policies of the Cynara system: - -- Disable Cynara by killing the process. -- Tamper with the Cynara binary on-disk or in-memory. -- Corrupt the database controlled by Cynara. -- Tamper with the database controlled by Cynara. -- Highjack the communication between Cynara and the database. - -The text-based database is the weakest part of the system and although there are some -consistency mechanisms in place (i.e. the backup guard), these mechanisms are weak at best -and can be countered by an attacker very easily. - - - -Domain | Object | Recommendations ------------------------ | ----------- | ------------------------------------- -Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - - - -### Policies - -- Policy rules: - - - Are simple - for pair [application context, privilege] there is straight - answer (single Policy Type): [ALLOW / DENY / ...]. - - No code is executed (no script). - - Can be easily cached and managed. - -- Application context (describes id of the user and the application credentials) - It is build of: - - - UID of the user that runs the application. - - **SMACK** label of application. - -## Holding policies - -Policies are kept in buckets. Buckets are set of policies which have additional -a property of default answer, the default answer is yielded if no policy matches -searched key. Buckets have names which might be used in policies (for directions). - -## Attack Vectors - -The following attack vectors are not completely independent. While attackers may -have varying levels of access to an AGL system, experience has shown that a typical -attack can start with direct access to a system, find the vulnerabilities, -then proceed to automate the attack such that it can be invoked from less accessible -standpoint (e.g. remotely). Therefore, it is important to assess all threat levels, -and protect the system appropriately understanding that direct access attacks -are the door-way into remote attacks. - -### Remote Attacks - -The local web server interface used for applications is the first point of attack, -as web service APIs are well understood and easily intercepted. The local web server -could potentially be exploited by redirecting web requests through the local service -and exploiting the APIs. While there is the use of a security token on the web -service API, this is weak textual matching at best. This will not be difficult to spoof. -It is well known that [API Keys do not provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/). - -It is likely that the architectural inclusion of an http / web-service interface -provided the most flexibility for applications to be written natively or in HTML5. -However, this flexibility may trade-off with security concerns. For example, -if a native application were linked directly to the underlying framework services, -there would be fewer concerns over remote attacks coming through the web-service interface. - -Leaving the interface as designed, mitigations to attacks could include further -securing the interface layer with cryptographic protocols: -e.g. encrypted information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). - -### User-level Native Attacks - -- Modifying the CSV data-base -- Modifying the SQLite DB -- Tampering with the user-level binaries -- Tampering with the user daemons -- Spoofing the D-bus Interface -- Adding executables/libraries - -With direct access to the device, there are many security concerns on the native level. -For example, as **Cynara** uses a text file data-base with comma-separated values (CSV), -an attacker could simply modify the data-base to escalate privileges of an application. -Once a single application has all the privileges possible on the system, exploits can -come through in this manner. Similarly the SQLite database used by the Security Manager -is not much different than a simple text file. There are many tools available to add, -remove, modify entries in an SQLite data-base. - -On the next level, a common point of attack is to modify binaries or daemons for exploiting -functionality. There are many Linux tools available to aid in this regard, -including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml), -and [radare2](https://rada.re/r/). With the ability to modify binaries, -an attacker can do any number of activities including: removing calls to security checks, -redirecting control to bypass verification functionality, ignoring security policy handling, -escalating privileges, etc. - -Additionally, another attack vector would be to spoof the D-bus interface. D-bus is a -message passing system built upon Inter-Process Communication (IPC), where structured -messages are passed based upon a protocol. The interface is generic and well documented. -Therefore, modifying or adding binaries/libraries to spoof this interface is a relatively -straight-forward process. Once the interface has been spoofed, the attacker can issue any -number of commands that lead into control of low-level functionality. - -Protecting a system from native attacks requires a methodical approach. First, the system -should reject processes that are not sanctioned to run. Signature-level verification at -installation time will help in this regard, but run-time integrity verification is much better. -Signatures need to originate from authorized parties, which is discussed further -in a later section on the Application Store. - -On the next level, executables should not be allowed to do things where they have not been -granted permission. DAC and SMACK policies can help in this regard. On the other hand, -there remain concerns with memory accesses, system calls, and other process activity -that may go undetected. For this reason, a secure environment which monitors all activity -can give indication of all unauthorized activity on the system. - -Finally, it is very difficult to catch attacks of direct tampering in a system. -These types of attacks require a defense-in-depth approach, where complementary software -protection and hardening techniques are needed. Tamper-resistance and anti-reverse-engineering -technologies include program transformations/obfuscation, integrity verification, -and white-box cryptography. If applied in a mutually-dependent fashion and considering -performance/security tradeoffs, the approach can provide an effective barrier -to direct attacks to the system. Furthermore, the use of threat monitoring provides a -valuable telemetry/analytics capability and the ability to react and renew a system under attack. - -### Root-level Native Attacks - -- Tampering the system daemon -- Tampering Cynara -- Tampering the security manager -- Disabling SMACK -- Tampering the kernel - -Once root-level access (i.e. su) has been achieved on the device, there are many ways -to compromise the system. The system daemon, **Cynara**, and the security manager are -vulnerable to tampering attacks. For example, an executable can be modified in memory -to jam a branch, jump to an address, or disregard a check. This can be as simple as replacing -a branch instruction with a NOP, changing a memory value, or using a debugger (e.g. gdb, IDA) -to change an instruction. Tampering these executables would mean that policies can be -ignored and verification checks can be bypassed. - -Without going so far as to tamper an executable, the **SMACK** system is also vulnerable to attack. -For example, if the kernel is stopped and restarted with the *security=none* flag, -then SMACK is not enabled. Furthermore, `systemd` starts the loading of **SMACK** rules during -start-up. If this start-up process is interfered with, then **SMACK** will not run. -Alternatively, new policies can be added with `smackload` allowing unforseen privileges -to alternative applications/executables. - -Another intrusion on the kernel level is to rebuild the kernel (as it is open-source) -and replace it with a copy that has **SMACK** disabled, or even just the **SMACK** filesystem -(`smackfs`) disabled. Without the extended label attributes, the **SMACK** system is disabled. - -Root-level access to the device has ultimate power, where the entire system can be compromised. -More so, a system with this level access allows an attacker to craft a simpler *point-attack* -which can operate on a level requiring fewer privileges (e.g. remote access, user-level access). - -## Vulnerable Resources - -### Resource: `afm-user-daemon` - -The `afm-user-daemon` is in charge of handling applications on behalf of a user. Its main tasks are: - -- Enumerate applications that the end user can run and keep this list available on demand. -- Start applications on behalf of the end user, set user running environment, set user security context. -- List current runnable or running applications. -- Stop (aka pause), continue (aka resume), terminate a running instance of a given application. -- Transfer requests for installation/uninstallation of applications to the corresponding system daemon afm-system-daemon. - -The `afm-user-daemon` launches applications. It builds a secure environment for the application -before starting it within that environment. Different kinds of applications can be launched, -based on a configuration file that describes how to launch an application of a given kind within -a given launching mode: local or remote. Launching an application locally means that -the application and its binder are launched together. Launching an application remotely -translates in only launching the application binder. - -The UI by itself has to be activated remotely by a request (i.e. HTML5 homescreen in a browser). -Once launched, running instances of the application receive a `runid` that identifies them. -`afm-user-daemon` manages the list of applications that it has launched. -When owning the right permissions, a client can get the list of running instances and details -about a specific running instance. It can also terminate, stop or continue a given application. -If the client owns the right permissions, `afm-user-daemon` delegates the task of -installing and uninstalling applications to `afm-system-daemon`. - -`afm-user-daemon` is launched as a `systemd` service attached to a user session. -Normally, the service file is located at /usr/lib/systemd/user/afm-user-daemon.service. - -Attacker goals: - -- Disable `afm-user-daemon`. -- Tamper with the `afm-user-daemon` configuration. - - /usr/lib/systemd/user/afm-user-daemon.service. - - Application(widget) config.xml file. - - /etc/afm/afm-launch.conf (launcher configuration). - -- Escalate user privileges to gain more access with `afm-user-daemon`. -- Install malicious application (widget). -- Tamper with `afm-user-daemon` on disk or in memory. - -### Resource: `afm-system-daemon` - -The `afm-system-daemon` is in charge of installing applications on the AGL system. Its main tasks are: - -- Install applications and setup security framework for newly installed applications. -- Uninstall applications. - -`afm-system-daemon` is launched as a `systemd` service attached to system. Normally, -the service file is located at /lib/systemd/system/afm-systemdaemon.service. - -Attacker goals: - -- Disable `afm-system-daemon`. -- Tamper with the `afm-system-daemon` configuration. -- Tamper `afm-system-daemon` on disk or in memory. - -### Resource `afb-daemon` - -`afb-binder` is in charge of serving resources and features through an HTTP interface. -`afb-daemon` is in charge of binding one instance of an application to the AGL framework -and AGL system. The application and its companion binder run in a secured and isolated -environment set for them. Applications are intended to access to AGL system through the binder. -`afb-daemon` binders serve files through HTTP protocol and offers developers the capability -to expose application API methods through HTTP or WebSocket protocol. - -Binder bindings are used to add APIs to `afb-daemon`. The user can write a binding for `afb-daemon`. -The binder `afb-daemon` serves multiple purposes: - -1. It acts as a gateway for the application to access the system. -2. It acts as an HTTP server for serving files to HTML5 applications. -3. It allows HTML5 applications to have native extensions subject to security enforcement for accessing hardware resources or for speeding up parts of algorithm. - -Attacker goals: - -- Break from isolation. -- Disable `afb-daemon`. -- Tamper `afb-demon` on disk or in memory. -- Tamper **capabilities** by creating/installing custom bindings for `afb-daemon`. \ No newline at end of file diff --git a/security-blueprint/part-5/6-Utilities.md b/security-blueprint/part-5/6-Utilities.md deleted file mode 100644 index 309cbc4..0000000 --- a/security-blueprint/part-5/6-Utilities.md +++ /dev/null @@ -1,78 +0,0 @@ -# Utilities - -- **busybox**: Software that provides several stripped-down Unix tools in a - single executable file. Of course, it will be necessary to use a "production" - version of **busybox** in order to avoid all the tools useful only in - development mode. - - - -Domain | `Tool` name | _State_ --------------------- | ----------- | ---------------------------------------------------------------------- -Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. - - - -## Functionalities to exclude in production mode - -In production mode, a number of tools must be disabled to prevent an attacker -from finding logs for example. This is useful to limit the visible surface and -thus complicate the fault finding process. The tools used only in development -mode are marked by an '**agl-devel**' feature. When building in production mode, -these tools will not be compiled. - - - -Domain | `Utility` name and normal `path` | _State_ ---------------------- | ---------------------------------------------------- | ---------- -Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ -Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ -Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ -Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ -Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ -Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ -Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ -Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ -Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ -Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ -Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ -Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ -Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ -Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ -Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ -Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ -Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ -Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ -Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ -Platform-Utilities-22 | `SSH` | _Disabled_ -Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ -Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ -Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ -Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ -Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ -Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ -Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ -Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ -Platform-Utilities-31 | `awk` (busybox) | _Enabled_ -Platform-Utilities-32 | `cut` (busybox) | _Enabled_ -Platform-Utilities-33 | `df` (busybox) | _Enabled_ -Platform-Utilities-34 | `echo` (busybox) | _Enabled_ -Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ -Platform-Utilities-36 | `grep` (busybox) | _Enabled_ -Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ -Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ -Platform-Utilities-39 | `printf` (busybox) | _Enabled_ -Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ -Platform-Utilities-41 | `tail` (busybox) | _Enabled_ -Platform-Utilities-42 | `tee` (busybox) | _Enabled_ -Platform-Utilities-43 | `test` (busybox) | _Enabled_ - - - -The _Enabled_ Unix/Linux utilities above shall be permitted as they are often -used in the start-up scripts and for USB logging. If any of these utilities are -not required by the device then those should be removed. - - diff --git a/security-blueprint/part-5/7-Users.md b/security-blueprint/part-5/7-Users.md deleted file mode 100644 index af5a686..0000000 --- a/security-blueprint/part-5/7-Users.md +++ /dev/null @@ -1,77 +0,0 @@ -# Users - -The user policy can group users by function within the car. For example, we can -consider a driver and his passengers. Each user is assigned to a single group to -simplify the management of space security. - -## Root Access - -The main applications, those that provide the principal functionality of the -embedded device, should not execute with root identity or any capability. - -If the main application is allowed to execute at any capability, then the entire -system is at the mercy of the said application's good behaviour. Problems arise -when an application is compromised and able to execute commands which could -consistently and persistently compromise the system by implanting rogue -applications. - -It is suggested that the middleware and the UI should run in a context on a user -with no capability and all persistent resources should be maintained without any -capability. - -One way to ensure this is by implementing a server-client paradigm. Services -provided by the system's drivers can be shared this way. The other advantage of -this approach is that multiple applications can share the same resources at the -same time. - - - -Domain | Object | Recommendations ---------------------- | ---------------- | ----------------------------------------------------- -Platform-Users-root-1 | Main application | Should not execute as root. -Platform-Users-root-2 | UI | Should run in a context on a user with no capability. - - - -Root access should not be allowed for the following utilities: - - - -Domain | `Utility` name | _State_ ---------------------- | -------------- | ------------- -Platform-Users-root-3 | `login` | _Not allowed_ -Platform-Users-root-4 | `su` | _Not allowed_ -Platform-Users-root-5 | `ssh` | _Not allowed_ -Platform-Users-root-6 | `scp` | _Not allowed_ -Platform-Users-root-7 | `sftp` | _Not allowed_ - - - -Root access should not be allowed for the console device. The development -environment should allow users to login with pre-created user accounts. - -Switching to elevated privileges shall be allowed in the development environment -via `sudo`. - --------------------------------------------------------------------------------- - - - -## Capabilities - - - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - - - -The goal is to restrict functionality that will not be useful in **AGL**. They -are integrated into the **LSM**. Each privileged transaction is associated with -a capability. These capabilities are divided into three groups: - -- e: Effective: This means the capability is “activated”. -- p: Permitted: This means the capability can be used/is allowed. -- i: Inherited: The capability is kept by child/subprocesses upon execve() for example. diff --git a/security-blueprint/part-5/App-flow.png b/security-blueprint/part-5/App-flow.png deleted file mode 100644 index 7b87c29..0000000 Binary files a/security-blueprint/part-5/App-flow.png and /dev/null differ diff --git a/security-blueprint/part-6/0_Abstract.md b/security-blueprint/part-6/0_Abstract.md deleted file mode 100644 index 3617dbd..0000000 --- a/security-blueprint/part-6/0_Abstract.md +++ /dev/null @@ -1,80 +0,0 @@ -# Part 6 - Application - -## Abstract - -**Application Hardening**: Best practices to apply to the build and release of -user space applications, in order to reduce the number of attack surfaces used -by potential attackers. - -The term of Application (App) has a very wide definition in **AGL**. Almost -anything which is not in the core Operating System (OS) is an Application. -Applications can be included in the base software package (image) or can be -added at run-time. - -Application containment is achieved using the following protections: - -- Linux Native protection - - Mandatory Access Control (**MAC**) -- AGL Platform protections - - Origin Tracking and Validation - - Application Privilege Management and Enforcement via Cynara - - Authenticated Transport via D-Bus - -## Application Types - -AGL provides a framework for applications to be written in different forms: - -- Web application: HTML5 + JavaScript -- Qt application: in a QML file -- Native application: in C - -While there is no harm in providing multiple types of applications, from a -security perspective this does increase the attack surface for an intruder. -The application framework (**AppFw**) consists of a number of utilities and -daemons which provide context for the applications. -Isolation is provided through **SMACK** labels. - -## Application Store - -Although the Tizen system has defined a [system of App signing and signing flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates) -to avoid the spread of unauthorized Apps that might contain malware. -At this point, it is unclear how much of this flow AGL will adopt. -However, judging from the experience, it is an essential topic. For example, -the Google Play Store controls the authorization of Apps through signing, and still, -there are [many accounts of Apps containing malware on the store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play). - -Tizen defines 5 levels of certificates and signing at each level, including an author, -testing distributor, public level store distributor, partner level store distributor, -and platform level store distributor. AGL may define a different number of third parties, -but at a minimum an author and store distributor should be defined. - -![App Signing Flow](App_signing_flow.png) - -Once the number of signatures has been established, verification of those signatures needs -to be done at a minimum at installation time on the AGL device. It is important to ensure -the robustness/integrity of the public key used for signature verification. If the public key is modified, -then this compromised key can be used to verify an attacker's private key signature. - -Further to this, installation-time verification is limited. Attacks can happen to apps in-memory -at runtime. Any modifications made after installation will be missed by installation-time verification. -Integrity verification that runs during execution makes for a more complete security story. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ---------------------------------------------------- -_3GPP_ | **3**rd **G**eneration **P**artnership **P**roject -_CASB_ | **C**loud **A**ccess **S**ecurity **B**roker -_DAST_ | **D**ynamic **A**pplication **S**ecurity **T**esting -_DPI_ | **D**eep **P**acket **I**nspection -_IDS_ | **I**ntrusion **D**etection **S**ystems -_IPS_ | **I**ntrusion **P**revention **S**ystems -_IPSec_ | **I**nternet **P**rotocol **Sec**urity -_LSM_ | **L**inux **S**ecurity **M**odule -_MITM_ | **M**an **I**n **T**he **M**iddle -_OSI_ | **O**pen **S**ystems **I**nterconnection -_SATS_ | **S**tatic **A**pplication **S**ecurity **T**esting diff --git a/security-blueprint/part-6/1-Installation.md b/security-blueprint/part-6/1-Installation.md deleted file mode 100644 index e2972ce..0000000 --- a/security-blueprint/part-6/1-Installation.md +++ /dev/null @@ -1,29 +0,0 @@ -# Local - - - -Domain | Improvement --------------------------- | ------------------------------ -Application-Installation-1 | Talk about AppFw offline mode. - - - -## Installation - -Applications can be delivered and installed with the base image using a special -offline-mode provided by the **AppFw**. Apps can also be installed at run time. - - - -During early release, default Apps are installed on the image at first boot. - - - - - -Domain | Object | Recommendations --------------------------- | --------- | ----------------------------------------------------------------------- -Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. -Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. - - diff --git a/security-blueprint/part-6/2-PrivilegeManagement.md b/security-blueprint/part-6/2-PrivilegeManagement.md deleted file mode 100644 index 2f2455a..0000000 --- a/security-blueprint/part-6/2-PrivilegeManagement.md +++ /dev/null @@ -1,7 +0,0 @@ -# Local - -## Privilege Management - -Application privileges are managed by **Cynara** and the security manager in -the **AppFw**. For more details, please refer to the **AppFw** documentation -in Platform part. diff --git a/security-blueprint/part-6/3-Signature.md b/security-blueprint/part-6/3-Signature.md deleted file mode 100644 index f7b48db..0000000 --- a/security-blueprint/part-6/3-Signature.md +++ /dev/null @@ -1,9 +0,0 @@ -# App Signature - - - -Domain | Improvement ------------------------ | ---------------------------------------------------------- -Application-Signature-1 | Add content (see secure build in Secure development part). - - diff --git a/security-blueprint/part-6/4-Services.md b/security-blueprint/part-6/4-Services.md deleted file mode 100644 index d0414f0..0000000 --- a/security-blueprint/part-6/4-Services.md +++ /dev/null @@ -1,10 +0,0 @@ -# Services - - - -Domain | Improvement ----------------------- | ------------ -Application-Services-1 | Add content (Which services?). -Application-Services-2 | Add Binder. - - diff --git a/security-blueprint/part-6/App_signing_flow.png b/security-blueprint/part-6/App_signing_flow.png deleted file mode 100644 index 56a7c23..0000000 Binary files a/security-blueprint/part-6/App_signing_flow.png and /dev/null differ diff --git a/security-blueprint/part-7/0_Abstract.md b/security-blueprint/part-7/0_Abstract.md deleted file mode 100644 index f7acbe5..0000000 --- a/security-blueprint/part-7/0_Abstract.md +++ /dev/null @@ -1,52 +0,0 @@ -# Part 7 - Connectivity - -## Abstract - -This part shows different Connectivity attacks on the car. - - - -Domain | Improvement ------------------------ | ----------------- -Connectivity-Abstract-1 | Improve abstract. - - - --------------------------------------------------------------------------------- - - - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | --------------------------------------------------------------------------------- -_ARP_ | **A**ddress **R**esolution **P**rotocol -_BLE_ | **B**luetooth **L**ow **E**nergy -_CAN_ | **C**ar **A**rea **N**etwork -_CCMP_ | **C**ounter-Mode/**C**BC-**M**ac **P**rotocol -_EDGE_ | **E**nhanced **D**ata **R**ates for **GSM** **E**volution - Evolution of **GPRS** -_GEA_ | **G**PRS **E**ncryption **A**lgorithm -_GPRS_ | **G**eneral **P**acket **R**adio **S**ervice (2,5G, 2G+) -_GSM_ | **G**lobal **S**ystem for **M**obile Communications (2G) -_HSPA_ | **H**igh **S**peed **P**acket **A**ccess (3G+) -_IMEI_ | **I**nternational **M**obile **E**quipment **I**dentity -_LIN_ | **L**ocal **I**nterconnect **N**etwork -_MOST_ | **M**edia **O**riented **S**ystem **T**ransport -_NFC_ | **N**ear **F**ield **C**ommunication -_OBD_ | **O**n-**B**oard **D**iagnostics -_PATS_ | **P**assive **A**nti-**T**heft **S**ystem -_PKE_ | **P**assive **K**eyless **E**ntry -_PSK_ | **P**hase-**S**hift **K**eying -_RDS_ | **R**adio **D**ata **S**ystem -_RFID_ | **R**adio **F**requency **I**dentification -_RKE_ | **R**emote **K**eyless **E**ntry -_SDR_ | **S**oftware **D**efined **R**adio -_SSP_ | **S**ecure **S**imple **P**airing -_TKIP_ | **T**emporal **K**ey **I**ntegrity **P**rotocol -_TPMS_ | **T**ire **P**ressure **M**onitoring **S**ystem -_UMTS_ | **U**niversal **M**obile **T**elecommunications **S**ystem (3G) -_USB_ | **U**niversal **S**erial **B**us -_WEP_ | **W**ired **E**quivalent **P**rivacy -_WPA_ | **W**ifi **P**rotected **A**ccess diff --git a/security-blueprint/part-7/1-BusAndConnectors.md b/security-blueprint/part-7/1-BusAndConnectors.md deleted file mode 100644 index 5ab9ab8..0000000 --- a/security-blueprint/part-7/1-BusAndConnectors.md +++ /dev/null @@ -1,68 +0,0 @@ -# Bus - -We only speak about the **CAN** bus to take an example, because the different -attacks on bus like _FlewRay_, _ByteFlight_, _Most_ and _Lin_ use retro -engineering and the main argument to improve their security is to encrypt data -packets. We just describe them a bit: - -- **CAN**: Controller Area Network, developed in the early 1980s, is an - event-triggered controller network for serial communication with data rates - up to one MBit/s. **CAN** messages are classified over their respective - identifier. **CAN** controller broadcast their messages to all connected nodes - and all receiving nodes decide independently if they process the message. -- **FlewRay**: Is a deterministic and error-tolerant high-speed bus. With a data - rate up to 10 MBit/s. -- **ByteFlight**: Is used for safety-critical applications in motor vehicles - like air-bags. Byteflight runs at 10Mbps over 2 or 3 wires plastic optical - fibers. -- **Most**: Media Oriented System Transport, is used for transmitting audio, - video, voice, and control data via fiber optic cables. The speed is, for the - synchronous way, up to 24 MBit/s and asynchronous way up to 14 MBit/s. - **MOST** messages include always a clear sender and receiver address. -- **LIN**: Local Interconnect Network, is a single-wire subnet work for - low-cost, serial communication between smart sensors and actuators with - typical data rates up to 20 kBit/s. It is intended to be used from the year - 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN** - network is not required. - -On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits) -communicate over a CAN bus, which is a two-wire bus using hardware arbitration -for messages sent on the shared medium. This is essentially a *trusted* network -where all traffic is visible to all controllers and any controller can send any message. - -A malicious **ECU** on the CAN bus can easily inject messages destined for any -other device, including things like the instrument cluster and the head unit. -There are common ways for hardware to do USB to CAN and open source software to send -and receive messages. For example, there is a driver included in the Linux kernel -that can be used to send/receive CAN signals. A malicious device on the CAN bus can -cause a great number of harmful things to happen to the system, including: sending -bogus information to other devices, sending unintended commands to ECUs, -causing DOS (Denial Of Service) on the CAN bus, etc. - - - -Domain | Tech name | Recommendations ----------------------------------- | --------- | -------------------------------------------------------------------------- -Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. - - - -See [Security in Automotive Bus Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf) for more information. - -# Connectors - -For the connectors, we supposed that they were disabled by default. For example, -the **USB** must be disabled to avoid attacks like BadUSB. If not, configure the -Kernel to only enable the minimum require **USB** devices. The connectors used -to diagnose the car like **OBD-II** must be disabled outside garages. - - - -Domain | Tech name | Recommendations ------------------------------------------ | --------- | ---------------------------------------------------------------------- -Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. -Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. -Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. -Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. - - diff --git a/security-blueprint/part-7/2-Wireless.md b/security-blueprint/part-7/2-Wireless.md deleted file mode 100644 index d3fda8b..0000000 --- a/security-blueprint/part-7/2-Wireless.md +++ /dev/null @@ -1,244 +0,0 @@ -# Wireless - -In this part, we talk about possible remote attacks on a car, according to the -different areas of possible attacks. For each communication channels, we -describe attacks and how to prevent them with some recommendations. The main -recommendation is to always follow the latest updates of these remote -communication channels. - - - -Domain | Object | Recommendations ------------------------ | ------ | ------------------------------------------------------------------ -Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. - - - -We will see the following parts: - -- [Wifi](#wifi) - -- [Bluetooth](#bluetooth) - -- [Cellular](#cellular) - -- [Radio](#radio) - -- [NFC](#nfc) - - - -Domain | Improvement ------------------------ | ------------------------------------------- -Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - - - --------------------------------------------------------------------------------- - -For existing automotive-specific means, we take examples of existing system -attacks from the _IOActive_ document ([A Survey of Remote Automotive Attack Surfaces](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf)) -and from the ETH document ([Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf)). - -- [Telematics](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A40%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - -- [Passive Anti-Theft System (PATS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A11%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C574%2C0%5D) - -- [Tire Pressure Monitoring System (TPMS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A17%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - -- [Remote Keyless Entry/Start (RKE)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A26%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - -- [Passive Keyless Entry (PKE)](https://eprint.iacr.org/2010/332.pdf) - --------------------------------------------------------------------------------- - - - -## Wifi - -### Attacks - -We can differentiate existing attacks on wifi in two categories: Those on -**WEP** and those on **WPA**. - -- **WEP** attacks: - - - **FMS**: (**F**luhrer, **M**antin and **S**hamir attack) is a "Stream cipher - attack on the widely used RC4 stream cipher. The attack allows an attacker - to recover the key in an RC4 encrypted stream from a large number of - messages in that stream." - - **KoreK**: "Allows the attacker to reduce the key space". - - **PTW**: (**P**yshkin **T**ews **W**einmann attack). - - **Chopchop**: Found by KoreK, "Weakness of the CRC32 checksum and the lack - of replay protection." - - **Fragmentation** - -- **WPA** attacks: - - - **Beck and Tews**: Exploit weakness in **TKIP**. "Allow the attacker to - decrypt **ARP** packets and to inject traffic into a network, even - allowing him to perform a **DoS** or an **ARP** poisoning". - - [KRACK](https://github.com/kristate/krackinfo): (K)ey (R)einstallation - (A)tta(ck) ([jira AGL SPEC-1017](https://jira.automotivelinux.org/browse/SPEC-1017)). - -### Recommendations - -- Do not use **WEP**, **PSK** and **TKIP**. - -- Use **WPA2** with **CCMP**. - -- Should protect data sniffing. - - - -Domain | Tech name or object | Recommendations ----------------------------- | ------------------- | ------------------------------------------------------------------------- -Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled -Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used -Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. -Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. -Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. - - - -See [Wifi attacks WEP WPA](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf) -and [Breaking wep and wpa (Beck and Tews)](https://dl.aircrack-ng.org/breakingwepandwpa.pdf) -for more information. - --------------------------------------------------------------------------------- - - - -## Bluetooth - -### Attacks - -- **Bluesnarfing** attacks involve an attacker covertly gaining access to your - Bluetooth-enabled device for the purpose of retrieving information, including - addresses, calendar information or even the device's **I**nternational - **M**obile **E**quipment **I**dentity. With the **IMEI**, an attacker could - route your incoming calls to his cell phone. -- **Bluebugging** is a form of Bluetooth attack often caused by a lack of - awareness. Similar to bluesnarfing, bluebugging accesses and uses all phone - features but is limited by the transmitting power of class 2 Bluetooth radios, - normally capping its range at 10-15 meters. -- **Bluejacking** is the sending of unsolicited messages. -- **BLE**: **B**luetooth **L**ow **E**nergy [attacks](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf). -- **DoS**: Drain a device's battery or temporarily paralyze the phone. - -### Recommendations - -- Not allowing Bluetooth pairing attempts without the driver's first manually - placing the vehicle in pairing mode. -- Monitoring. -- Use **BLE** with caution. -- For v2.1 and later devices using **S**ecure **S**imple **P**airing (**SSP**), - avoid using the "Just Works" association model. The device must verify that - an authenticated link key was generated during pairing. - - - -Domain | Tech name | Recommendations ---------------------------------- | ------------- | ------------------------------------------------------------ -Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. -Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring -Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. -Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. -Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. - - - -See [Low energy and the automotive transformation](http://www.ti.com/lit/wp/sway008/sway008.pdf), -[Gattacking Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf), -[Comprehensive Experimental Analyses of Automotive Attack Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf) -and [With Low Energy comes Low Security](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf) -for more information. - --------------------------------------------------------------------------------- - - - -## Cellular - -### Attacks - -- **IMSI-Catcher**: Is a telephone eavesdropping device used for intercepting - mobile phone traffic and tracking location data of mobile phone users. - Essentially a "fake" mobile tower acting between the target mobile phone and - the service provider's real towers, it is considered a man-in-the-middle - (**MITM**) attack. - -- Lack of mutual authentication (**GPRS**/**EDGE**) and encryption with **GEA0**. - -- **Fall back** from **UMTS**/**HSPA** to **GPRS**/**EDGE** (Jamming against - **UMTS**/**HSPA**). - -- 4G **DoS** attack. - -### Recommendations - -- Check antenna legitimacy. - - - -Domain | Tech name | Recommendations --------------------------------- | --------- | -------------------------- -Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid -Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. - - - -See [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf) -for more information. - --------------------------------------------------------------------------------- - -## Radio - -### Attacks - -- Interception of data with low cost material (**SDR** with hijacked DVB-T/DAB - for example). - -### Recommendations - -- Use the **R**adio **D**ata **S**ystem (**RDS**) only to send signals for audio - output and meta concerning radio. - - - -Domain | Tech name | Recommendations ------------------------------ | --------- | -------------------------------------------- -Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. - - - --------------------------------------------------------------------------------- - - - -## NFC - -### Attacks - -- **MITM**: Relay and replay attack. - -### Recommendations - -- Should implements protection against relay and replay attacks (Tokens, etc...). -- Disable unneeded and unapproved services and profiles. -- NFC should be use encrypted link (secure channel). A standard key agreement - protocol like Diffie-Hellmann based on RSA or Elliptic Curves could be applied - to establish a shared secret between two devices. -- Automotive NFC device should be certified by NFC forum entity: The NFC Forum - Certification Mark shows that products meet global interoperability standards. -- NFC Modified Miller coding is preferred over NFC Manchester coding. - - - -Domain | Tech name | Recommendations ---------------------------- | --------- | ------------------------------------------------------ -Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. -Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. - - diff --git a/security-blueprint/part-7/3-Cloud.md b/security-blueprint/part-7/3-Cloud.md deleted file mode 100644 index ec7edea..0000000 --- a/security-blueprint/part-7/3-Cloud.md +++ /dev/null @@ -1,107 +0,0 @@ -# Cloud - -## Download - -- **authentication**: Authentication is the security process that validates the - claimed identity of a device, entity or person, relying on one or more - characteristics bound to that device, entity or person. - -- **Authorization**: Parses the network to allow access to some or all network -functionality by providing rules and allowing access or denying access based -on a subscriber's profile and services purchased. - - - -Domain | Object | Recommendations ----------------------------- | -------------- | -------------------------------------- -Application-Cloud-Download-1 | authentication | Must implement authentication process. -Application-Cloud-Download-2 | Authorization | Must implement Authorization process. - - - --------------------------------------------------------------------------------- - -## Infrastructure - -- **Deep Packet Inspection**: **DPI** provides techniques to analyze the payload - of each packet, adding an extra layer of security. **DPI** can detect and - neutralize attacks that would be missed by other security mechanisms. - -- A **DoS** protection in order to avoid that the Infrastructure is no more - accessible for a period of time. - -- **Scanning tools** such as **SATS** and **DAST** assessments perform - vulnerability scans on the source code and data flows on web applications. - Many of these scanning tools run different security tests that stress - applications under certain attack scenarios to discover security issues. - -- **IDS & IPS**: **IDS** detect and log inappropriate, incorrect, or anomalous - activity. **IDS** can be located in the telecommunications networks and/or - within the host server or computer. Telecommunications carriers build - intrusion detection capability in all network connections to routers and - servers, as well as offering it as a service to enterprise customers. Once - **IDS** systems have identified an attack, **IPS** ensures that malicious - packets are blocked before they cause any harm to backend systems and - networks. **IDS** typically functions via one or more of three systems: - - 1. Pattern matching. - 2. Anomaly detection. - 3. Protocol behavior. - - - - - -Domain | Object | Recommendations ----------------------------------- | ------------- | ---------------------------------------------------------- -Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. -Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. -Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. -Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). -Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. - - - --------------------------------------------------------------------------------- - -## Transport - -For data transport, it is necessary to **encrypt data end-to-end**. To prevent **MITM** attacks, -no third party should be able to interpret transported data. Another aspect -is the data anonymization in order to protect the leakage of private information -on the user or any other third party. - -The use of standards such as **IPSec** provides "_private and secure -communications over IP networks, through the use of cryptographic security -services, is a set of protocols using algorithms to transport secure data over -an IP network._". In addition, **IPSec** operates at the network layer of the -**OSI** model, contrary to previous standards that operate at the application -layer. This makes its application independent and means that users do not need -to configure each application to **IPSec** standards. - -**IPSec** provides the services below : - -- Confidentiality: A service that makes it impossible to interpret data if it is - not the recipient. It is the encryption function that provides this service by - transforming intelligible (unencrypted) data into unintelligible (encrypted) - data. -- Authentication: A service that ensures that a piece of data comes from where - it is supposed to come from. -- Integrity: A service that consists in ensuring that data has not been tampered - with accidentally or fraudulently. -- Replay Protection: A service that prevents attacks by re-sending a valid - intercepted packet to the network for the same authorization. - This service is provided by the presence of a sequence number. -- Key management: Mechanism for negotiating the length of encryption keys - between two **IPSec** elements and exchange of these keys. - -An additional means of protection would be to do the monitoring between users -and the cloud as a **CASB** will provide. - - - -Domain | Object | Recommendations ------------------------------ | ----------------------------------------- | --------------------------------- -Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. - - diff --git a/security-blueprint/part-8/0_Abstract.md b/security-blueprint/part-8/0_Abstract.md deleted file mode 100644 index e438e65..0000000 --- a/security-blueprint/part-8/0_Abstract.md +++ /dev/null @@ -1,76 +0,0 @@ -# Part 8 - Update (**OTA**) - -## Abstract - -Updating applications and firmware is essential for the development of new -features and even more to fix security bugs. -However, if a malicious third party manages to alter the content during -transport, it could -alter the functioning of the system and/or applications. The security of the -updates is therefore a critical point to evaluate in order to guarantee the -integrity, the confidentiality and the legitimacy of the transmitted data. - -## Attack Vectors - -Updates Over The Air are one of the most common points where an attacker -will penetrate. An OTA update mechanism is one of the highest threats in the system. -If an attacker is able to install his own application or firmware on the system, -he can get the same level of access that the original application or firmware had. -From that point, the intruder can get unfettered access to the rest of the system, -which might include making modifications, downloading other pieces of software, -and stealing assets. - -### Man In The Middle (MITM) - -The man-in-the-middle attack is the most classic example of an attack, where an adversary -inserts himself between two communicating entities and grabs whatever is being communicated. -In the case of OTA attacks, the connection in the network may be intercepted: - -* On the internet, before the cloud back-end. -* At the base station, 3G,4G,5G connection to the internet. -* At the receiving antenna, connection to the car. -* Between the receiving antenna and the gateway router (if present), connection within the car. -* Between the gateway router and the target component (IVI, In-Vehicle Infotainment unit). - -There are many ways to mount a MITM attack. For example, proxy tools like Burp Proxy can -be used to intercept web traffic as a man-in-the-middle. Under the guise of being a testing tool, -the proxy server is often used in attack scenarios. It runs on a variety of platforms. - -As another example, false base station attacks are known to be fairly easy to set-up. -The problem is apparently fairly prevalent in countries like China and in the UK. -These fake base stations are sometimes just eavesdropping on the communication, -but others have the potential to do serious harm. - -Defenses against MITM attacks include encrypted and signed data pipes. Furthermore, -architects and developers are also recommended to encrypt and sign the payloads that are -being passed over these pipes, to defend against perusal of the data. - -### Man At The End (MATE) - -The man-at-the-end attack is when an intruder analyzes the end-point of the communication when -software is accessing the data communication. This is a more severe attack type where the attacker can: - -* Steal keys. - * For example, a simple debugging session in running software could reveal a key used in memory. -* Tamper software. - * For example, replacing just one function call in software with a NOP (i.e. no operation) can drastically change the behavior of the program. -* Jam branches of control. - * For example, making a program take one branch of control rather than the intended branch can mean the difference between an authorized and a non-authorized installation. -* Modify important data. - * For example, if the data changed is a key or data leading to a control path, then this attack can be severe. - * In the case of OTA updates, MATE attacks are particularly problematic for the system. One of the consequences of MATE attacks can be installed software that allows installation of any other software. For example, an attacker might install remote access software to control any part of the system. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ------------------------------------------------------------------------- -_FOTA_ | **F**irmware **O**ver **T**he **A**ir -_MATE_ | **M**an **A**t **T**he **E**nd -_MITM_ | **M**an **I**n **T**he **M**iddle -_OTA_ | **O**ver **T**he **A**ir -_SOTA_ | **S**oftware **O**ver **T**he **A**ir -_TUF_ | **T**he **U**pdate **F**ramework diff --git a/security-blueprint/part-8/1-FOTA.md b/security-blueprint/part-8/1-FOTA.md deleted file mode 100644 index 3d7f58e..0000000 --- a/security-blueprint/part-8/1-FOTA.md +++ /dev/null @@ -1,41 +0,0 @@ -# Firmware Over The Air - -The firmware update is critical since its alteration back to compromise the -entire system. It is therefore necessary to take appropriate protective measures. - -AGL includes the _meta-updater_ Yocto layer that enables OTA software -updates via [Uptane](https://uptane.github.io), an automotive-specific extension -to [The Update Framework](https://theupdateframework.github.io/). Uptane and TUF -are open standards that define a secure protocol for delivering and verifying -updates even when the servers and network--internet and car-internal--aren't fully trusted. - -_meta-updater_ includes the application [`aktualizr`](https://github.com/advancedtelematic/aktualizr), -developed Advanced Telematic Systems (now part of HERE Technologies) that enables -OTA for an ECU. `aktualizr` combined with Uptane is suitable for updating the -firmware, software, and other packages on even functionally critical ECUs. -`aktualizr` can be enabled with the free, open souce backend -[`ota-community-edition`](https://github.com/advancedtelematic/ota-community-edition). - -This FOTA update mechanism can be enabled through the `agl-sota` feature. - -## Building - -To build an AGL image that uses `aktualizr`, the following can be used. - -``` -source meta-agl/scripts/aglsetup.sh -m agl-sota -``` - -During the build, _meta-updater_ will use credentials downloaded from `ota-community-edition` -to sign metadata verifying the build as authentic. These signatures are part of the Uptane -framework and are used to verify FOTA updates. - -## Atomic Upgrades with Rollbacks - -`aktualizr`'s primary method of updating firmware is to use `libostree` with binary diffs. -The binary diffs use the least amout of bandwidth, and by it's nature `libostree` stores -current and previous firmware versions on disk or in flash memory to allow for rollbacks. - -`libostree` is a content addressable object store much like `git`. Versions are specified -via SHA2-256. These hashes are signed in the Uptane metadata and are robust against -cryptographic compromise. diff --git a/security-blueprint/part-8/2-SOTA.md b/security-blueprint/part-8/2-SOTA.md deleted file mode 100644 index 57df6fc..0000000 --- a/security-blueprint/part-8/2-SOTA.md +++ /dev/null @@ -1,20 +0,0 @@ -# Software Over The Air - -Software updates in connected vehicles are a very useful feature, which can -deliver significant benefits. If not implemented with security in mind, -software updates can incur serious vulnerabilities. Any software update system -must ensure that not only are the software updates to devices done in a secure way, -but also that the repositories and servers hosting these updates are adequately -protected. As the process of updating software migrates from a Dealership update model -towards an **OTA** update model, securing these processes becomes a high priority. - -**SOTA** is made possible by **AppFw** (See Platform part). It will be possible -to manage in a simple way the packets (i.g. Android like). - - - -Domain | Improvement -------------- | ----------------- -Update-SOTA-1 | Part to complete. - - diff --git a/security-blueprint/part-9/0_Abstract.md b/security-blueprint/part-9/0_Abstract.md deleted file mode 100644 index 25d3f35..0000000 --- a/security-blueprint/part-9/0_Abstract.md +++ /dev/null @@ -1,62 +0,0 @@ -# Part 9 - Secure development - -In order to save a lot of time in code auditing, developers must follow coding guidelines. - -## Secure build - -### Kernel build - -Tools like: - -- [Code optimisation](https://github.com/jduck/lk-reducer). -- [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf). - - - -Domain | Improvement ------------------------ | ------------ -SecureDev-SecureBuild-1 | Add content. - - - -## App/Widget signatures - - - -Domain | Improvement ----------------------- | ------------ -SecureDev-Signatures-1 | Add content. - - - -## Code audit - -These tools are used to check the correct implementation of functionalities and -compliance with related good practices. - -- [Continuous Code Quality](https://www.sonarqube.org/). - - - -Domain | Improvement ---------------------- | ----------------------------------------------------- -SecureDev-CodeAudit-1 | Add CVE analyser. -SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). - - - -### SATS - -- [RATS](https://github.com/andrew-d/rough-auditing-tool-for-security) (Maybe to old). -- [Flaw Finder](https://www.dwheeler.com/flawfinder/). - -- [wiki list](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis). - -- [Mathematical approach](https://perso.univ-rennes1.fr/david.lubicz/planches/David_Pichardie.pdf). - -It is necessary to verify that the application code does not use functions that -are depreciated and recognized as unsecured or cause problems. - -### DATS - -- [wiki list](https://en.wikipedia.org/wiki/Dynamic_program_analysis#Example_tools). diff --git a/signaling/architecture.md b/signaling/architecture.md deleted file mode 100644 index 823a6d2..0000000 --- a/signaling/architecture.md +++ /dev/null @@ -1,467 +0,0 @@ ---- -title: AGL - Message Signaling Architecture -author: Fulup Ar Foll (IoT.bzh) -date: 2016-06-30 - -categories: architecture, appfw -tags: architecture, signal, message -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Context - -Automotive applications need to understand in real time the context in which -vehicles operate. In order to do so, it is critical for automotive application -to rely on a simple, fast and secure method to access data generated by the -multiple sensors/ECU embedded in modern cars. - -This signaling problem is neither new, neither unique to the automotive and -multiple solutions often described as Message Broker or Signaling Gateway have -been around for a while. - -The present document is the now implemented since AGL Daring Dab version, to -handle existing signaling/message in a car. It relies on [[APbinder]] -binder/bindings model to minimize complexity while keeping the system fast -around secure. We propose a model with multiple transport options and a full set -of security feature to protect the service generating the signal as well as -consuming them. - -## Objectives - -Our objectives are solving following 3 key issues: - -1. reduce as much as possible the amount of exchanged data to the meaningful - subset really used by applications -1. offer a high level API that obfuscates low level and proprietary interface to - improve stability in time of the code -1. hide specificities of low level implementation as well as the chosen - deployment distribution model. - -To reach first objective, events emission frequency should be controlled at the -lowest level it possibly can. Aggregation, composition, treatment, filtering of -signals should be supported at software level when not supported by the hardware. - -Second objectives of offering long term stable hight level API while allowing -flexibility in changing low level implementation may look somehow conflicting. -Nevertheless by isolating low level interface from high level and allowing -dynamic composition it is possible to mitigate both objectives. - -## Architecture - -Good practice is often based on modularity with clearly separated components -assembled within a common framework. Such modularity ensures separation of -duties, robustness, resilience and achievable long term maintenance. - -This document uses the term "**Service**" to define a specific instance of this -proposed common framework used to host a group of dedicated separated components -that handle targeted signals/events. Each service exposes to services/applications -the signals/events it is responsible for. - -As an example, a CAN service may want to mix non-public proprietary API with -CANopen compatible devices while hiding this complexity to applications. The -goal is on one hand to isolate proprietary piece of code in such a way that it -is as transparent as possible for the remaining part of the architecture. On a -second hand isolation of code related to a specific device provides a better -separation of responsibilities, keeping all specificity related to a given -component clearly isolated and much easier to test or maintain. Last but not -least if needed this model may also help to provide some proprietary code -directly as binary and not as source code. - -Communicating between the car and regular apps should be done using a 2 levels -AGL services which have two distincts roles: - -- low level should handle communication with CAN bus device (read, decoding, - basic and efficient filtering, caching, ...) -- high level should handle more complex tasks (signals compositions, complex - algorythms like Kalman filter, business logic...) - -![image](./images/signal-service-arch.svg "Signal Agent Architecture") - -To do so, the choice has been to use a similar architecture than [[OpenXC]], a -Ford project. Principle is simple, from a JSON file that describes all CAN -signals wanted to be handled, in general a conversion from a **dbc** file, AGL -generator convert it to a C++ source code file. This file which in turn is used -as part of the low level CAN service which can now be compiled. This service -reads, decodes and serves this CAN signals to a high level CAN service that -holds business logic and high level features like described is the above -chapter. - -![image](./images/can-generator.svg "AGL CAN generator") - -While in some cases it may be chosen to implement a single service responsible -for everything, other scenarii may chose to split responsibility between -multiple services. Those multiple services may run on a single ECU or on -multiple ECUs. Chosen deployment distribution strategy should not impact the -development of components responsible for signals/events capture. As well as it -should have a loose impact on applications/services consuming those events. - -A distributed capable architecture may provide multiple advantages: - -- it avoids to concentrate complexity in a single big/fat component. -- it leverages naturally multiple ECUs and existing network architecture -- it simplifies security by enabling isolation and sandboxing -- it clearly separates responsibilities and simplifies resolution of conflicts - -Distributed architecture has to be discussed and about now is not fully -implemented. Low level CAN service isn't fully functional nor tested to assume -this feature but its architecture let the possibility open and will be -implemented later. - -![image](./images/distributed-arch.png "Distributed Architecture") - -Performance matters. There is a trade-off between modularity and efficiency. -This is specially critical for signals where propagation time from one module to -the other should remain as short as possible and furthermore should consume as -little computing resources as possible. - -A flexible solution should provide enough versatility to either compose modules -in separate processes; either chose a model where everything is hosted within a -single process. Chosen deployment model should have minor or no impact on -development/integration processes. Deployment model should be something easy to -change, it should remain a tactical decision and never become a structuring -decision. - -Nevertheless while grouping modules may improve performance and reduce resource consumption, on the other hand, -it has a clear impact on security. No one should forget that some signals have very different level of security from other ones. -Mixing everything within a single process makes all signal's handling within a single security context. -Such a decision may have a significant impact on the level on confidence one may have in the global system. - -Providing such flexibility constrains the communication model used by modules: - -- The API of integration of the modules (the API of the framework) that enables - the connection of modules must be independent of the implementation of - the communication layer -- The communication layer must be as transparent as possible, its - implementation shouldn't impact how it is used -- The cost of the abstraction for modules grouped in a same process - must be as little as possible -- The cost of separating modules with the maximum of security must remain as - minimal as possible - -Another point impacting performance relates to a smart limitation on the number -of emitted signals. Improving the cost of sending a signal is one thing, -reducing the number of signals is an other one. No one should forget that the -faster you ignore a useless signal the better it is. The best way to achieve -this is by doing the filtering of useless signal as close as possible of the -component generating the signal and when possible directly at the hardware level. - -To enable the right component to filter useless signals, consumer clients must -describe precisely the data they need. A filter on frequency is provided since -Daring Dab version, as well as minimum and maximum limits. These filters can be -specified at subscription time. Also, any data not required by any client should -at the minimum never be transmitted. So only changed data is transmitted and if -another service needs to receive at a regular time, it has to assume that if no -events are received then it is that the value hasn't change. Furthermore when -possible then should even not be computed at all, a CAN signal received on -socket is purely ignored if no one asks for it. - -Describing expected data in a precise but nevertheless simple manner remains a -challenge. It implies to manage: - -- requested frequency of expected data -- accuracy of data to avoid detection of inaccurate changes -- when signaling is required (raising edge, falling edge, - on maintained state, ...), -- filtering of data to avoid glitches and noise, -- composition of signals both numerically and logically (adding, - subtracting, running logical operators like AND/OR/XOR, getting the mean, ...) -- etc... - -It is critical to enable multiple features in signal queries to enable modules -to implement the best computing method. The best computing method may have an -impact on which device to query as well as on which filters should be applied. -Furthermore filtering should happen as soon as possible and obviously when -possible directly at hardware level. - -### Transport Solutions - -D-Bus is the standard choice for Linux, nevertheless it has some serious -performance limitation due to internal verbosity. Nevertheless because it is -available and pre-integrated with almost every Linux component, D-Bus may still -remains an acceptable choice for signal with low rate of emission (i.e. HMI). - -For a faster communication, Jaguar-Land-Rover proposes a memory shared signal -infrastructure. Unfortunately this solution is far from solving all issues and -has some drawbacks. Let check the open issues it has: - -- there is no management of what requested data are. This - translate in computing data even when not needed. -- on top of shared memory, an extra side channel is required for processes - to communicate with the daemon. -- a single shared memory implies a lot of concurrency handling. This might - introduce drawbacks that otherwise would be solved through communication - buffering. - -ZeroMQ, NanoMSG and equivalent libraries focused on fast communication. Some -(e.g. ZeroMQ) come with a commercial licensing model when others (e.g. NanoMSG) -use an open source licensing. Those solutions are well suited for both -communicating inside a unique ECU or across several ECUs. However, most of them -are using Unix domain sockets and TCP sockets and typically do not use shared -memory for inter-process communication. - -Last but not least Android binder, Kdbus and other leverage shared memory, zero -copy and sit directly within Linux kernel. While this may boost information -passing between local processes, it also has some limitations. The first one is -the non support of a multi-ECU or vehicle to cloud distribution. The second one -is that none of them is approved upstream in kernel tree. This last point may -create some extra burden each time a new version of Linux kernel is needed or -when porting toward a new hardware is required. - -### Query and Filtering Language - -Description language for filtering of expected data remains an almost green -field where nothing really fit signal service requirements. Languages like -Simulink or signal processing graphical languages are valuable modelling tools. -Unfortunately they cannot be inserted in the car. Furthermore those languages -have many features that are not useful in proposed signal service context and -cost of integrating such complex languages might not be justified for something -as simple as a signal service. The same remarks apply for automation languages. - -Further investigations leads to some specifications already presents like the -one from Jaguar Land Rover [[VISS]], for **Vehicule Information Service -Specification** and another from Volkwagen AG named [[ViWi]], stand for -**Volkwagen Infotainment Web Interface**. Each ones has their differences and -provides different approach serving the same goal: - -| VISS | ViWi | -|---------------------------------------------------------------|-----------------------------------------------------------------| -| Filtering on node (not possible on several nodes or branches) | Describe a protocol | -| Access restrictions to signals | Ability to specify custom signals | -| Use high level development languages | RESTful HTTP calls | -| One big Server that handle requests | Stateless | -| Filtering | Filtering, sorting | -| Static signals tree not extensible [[VSS]] | Use JSON objects to communicate | -| Use of AMB ? | Identification of resources may be a bit heavy going using UUID | -| Use of Websocket | | - -About **[[VISS]]** specification, the major problem comes from the fact that -signals are specified under the [[VSS]], **Vehicle Signal Specification**. So, -problem is that it is difficult, if not impossible, to make a full inventory -of all signals existing for each car. More important, each evolution in signals -must be reported in the specification and it is without seeing the fact that -car makers have their names and set of signals that would mostly don't -comply with the [[VSS]]. VISS doesn't seems to be an valuable way to handle -car's signals, a big component that responds requests, use of **Automotive -Message Broker** that use DBus is a performance problem. Fujitsu Ten recent -study[[1]] highlights that processor can't handle an heavy load on CAN bus and -that Low level binding adopted for AGL is about 10 times[[2]] less impact on -performance. - -## Describing Signal Subscriptions using JSON - -JSON is a rich structured representation of data. For requested data, it allows -the expression of multiple features and constraints. JSON is both very flexible -and efficient. There are significant advantages in describing requested data at -subscription time using a language like JSON. Another advantage of JSON is that -no parser is required to analyse the request. - -Existing works exists to describe a signals that comes first from Vector with -its proprietary database (`DBC`) which widely used in industry. Make a -description based on this format appears to be a good solution and Open Source -community already has existing tools that let you convert proprietary file -format to an open one. So, a JSON description based on work from [[OpenXC]] is -specified [here](https://github.com/openxc/vi-firmware/blob/master/docs/config/reference.rst) -which in turn is used in Low level CAN service in AGL: - -```json -{ "name": "example", - "extra_sources": [], - "initializers": [], - "loopers": [], - "buses": {}, - "commands": [], - "0x3D9": { - "bus": "hs", - "signals": { - "PT_FuelLevelPct": { - "generic_name": "fuel.level", - "bit_position": 8, - "bit_size": 8, - "factor": 0.392157, - "offset": 0 - }, - "PT_EngineSpeed": { - "generic_name": "engine.speed", - "bit_position": 16, - "bit_size": 16, - "factor": 0.25, - "offset": 0 - }, - "PT_FuelLevelLow": { - "generic_name": "fuel.level.low", - "bit_position": 55, - "bit_size": 1, - "factor": 1, - "offset": 0, - "decoder": "decoder_t::booleanDecoder" - } - } - } -} -``` - -From a description like the above one, low level CAN generator will output -a C++ source file which let low level CAN service that uses it to handle such -signal definition. - -## Naming Signal - -Naming and defining signals is something very complex. For example just -***speed***, as a signal, is difficult to define. -What unit is used (km/h, M/h, m/s, ...)? -From which source (wheels, GPS, AccelMeter)? -How was it captured (period of measure, instantaneous, mean, filtered)? - -In order to simplify application development we should nevertheless agree on -some naming convention for key signals. Those names might be relatively complex -and featured. They may include a unit, a rate, a precision, etc. - -How these names should be registered, documented and managed is out of scope of -this document but extremely important and at some point in time should be -addressed. Nevertheless this issue should not prevent from moving forward -developing a modern architecture. Developers should be warned that naming is a -complex task, and that in the future naming scheme should be redefined, and -potential adjustments would be required. - -About Low level CAN signals naming a doted notation, like the one used by Jaguar -Landrover, is a good compromise as it describe a path to an car element. It -separates and organize names into hierarchy. From the left to right, you -describe your names using the more common ancestor at the left then more you go -to the right the more it will be accurate. Using this notation let you subscribe -or unsubscribe several signals at once using a globbing expression. - -Example using OBD2 standard PID: - -```path -engine.load -engine.coolant.temperature -fuel.pressure -intake.manifold.pressure -engine.speed -vehicle.speed -intake.air.temperature -mass.airflow -throttle.position -running.time -EGR.error -fuel.level -barometric.pressure -commanded.throttle.position -ethanol.fuel.percentage -accelerator.pedal.position -hybrid.battery-pack.remaining.life -engine.oil.temperature -engine.torque -``` - -Here you can chose to subscribe to all engine component using an expression -like : `engine.*` - -## Reusing existing/legacy code - -About now provided services use: - -- **Low Level** [[OpenXC]] project provides logic and some useful libraries to - access a CAN bus. It is the choice for AGL. - -- **High Level** In many cases accessing to low level signal is not enough. - Low level information might need to be composed (i.e. GPS+Gyro+Accel). - Writing this composition logic might be quite complex and reusing existing - libraries like: LibEkNav for Kalman filtering [[9]] or Vrgimbal for 3 axes - control[[10]] may help saving a lot of time. AGL apps should access CAN - signals through High Level service. High level can lean on as many low level - service as needed to compute its **Virtual signals** coming from differents - sources. Viwi protocol seems to be a good solution. - -## Leveraging AGL binder - -Such a model is loosely coupled with AGL binder. Low level CAN service as well -as virtual signal components may potentially run within any hosting environment -that would provide the right API with corresponding required facilities. -Nevertheless leveraging [[APbinder]] has multiple advantages. It already -implements event notification to support a messaging/signaling model for -distributed services. It enables a subscribe model responding to the -requirement and finally it uses JSON natively. - -This messaging/signalling model already enforces the notion of subscription for -receiving data. It implies that unexpected data are not sent and merely not -computed. When expected data is available, it is pushed to all waiting -subscriber only one time. - -The [[APbinder]] provides transparency of communication. -It currently implements the transparency over D-Bus/Kdbus and WebSocket. -Its transparency mechanism of communication is easy to extend to other -technologies: pools of shared memory or any proprietary transport model. - -When bindings/services are loaded by the same binder, it provides transparently -`in-memory` communication. This in-memory communication is really efficient: on -one hand, the exchanged JSON objects are not serialized (because not streamed), -on the other hand, those JSON objects provide a high level of abstraction able -to transfer any data. - -Technically a service is a standard [[APbinder]] binding which is also handled -by the system and launched as a daemon by systemD. -Therefore Signal/Agent inherits of security protection through SMACK, access -control through Cynara, transparency of API to transport layer, life cycle -management, ... Like any other [[APbinder]] process is composed of a set of -bindings. In signal service specific case, those bindings are in fact the -`signal modules`. - -The proposed model allows to implement low level dependencies as independent -signal modules. Those modules when developed are somehow like "Lego Bricks". -They can be spread or grouped within one or multiple services depending on -deployment constraints (performance, multi-ECU, security & isolation -constraints,...). - -On top of that low level signal modules, you should use a high level service. -A first implementation of [[ViWi]] is available [here](https://github.com/iotbzh/high-level-viwi-service) -and can be use to integrate business logic and high level features. - -The model naturally uses JSON to represent data. - -## Multi-ECU and Vehicule to Cloud interactions - -While this might not be a show stopper for current projects, it is obvious that -in the near future Signal/Agent should support a fully distributed -architectures. Some event may come from the cloud (i.e. request to start -monitoring a given feature), some may come from SmartCity and nearby vehicles, -and last but not least some may come from another ECU within the same vehicle or -from a virtualized OS within the same ECU (e.g. cluster & IVI). In order to do -so, Signal modules should enable composition within one or more [[APbinder]] -inside the same ECU. Furthermore they should also support chaining with the -outside world. - -![image](./images/cloud-arch.svg "Cloud & Multi-ECU Architecture") - -1. Application requests Virtual Signal exactly like if it was a low level signal -1. Agent Signal has direct relation to low level signal -1. Agent needs to proxy to an other service inside the same ECU to access the signal -1. Signal is not present on current ECU. Request has to be proxied to the outside world - -[AppFw]: http://iot.bzh/download/public/2016/appfw/01_Introduction-to-AppFW-for-AGL-1.0.pdf "Application Framework" -[APcore]: http://iot.bzh/download/public/2016/appfw/03_Documentation-AppFW-Core-1.0.pdf "AppFw Core" -[APmain]: https://gerrit.automotivelinux.org/gerrit/#/q/project:src/app-framework-main "AppFw Main" -[APbinder]: https://gerrit.automotivelinux.org/gerrit/#/q/project:src/app-framework-binder "AppFw Binder" -[APsamples]: https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/app-framework-binder.git;a=tree;f=bindings/samples "AppFw Samples" -[Signal-K]: http://signalk.org/overview.html -[1]: http://schd.ws/hosted_files/aglmmwinter2017/37/20170201_AGL-AMM_F10_kusakabe.pdf -[2]: https://wiki.automotivelinux.org/_media/agl-distro/20170402_ften_can_kusakabe_v2.pdf -[6]: https://github.com/otcshare/automotive-message-broker -[7]: http://ardupilot.org/rover/index.html -[8]: https://github.com/ArduPilot/ardupilot/tree/master/libraries -[9]: https://bitbucket.org/jbrandmeyer/libeknav/wiki/Home -[10]: http://ardupilot.org/rover/docs/common-vrgimbal.html -[11]: http://elinux.org/R-Car/Boards/Porter:PEXT01 -[12]: https://github.com/gpsnavi/gpsnavi -[VISS]: http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html -[VSS]: https://github.com/GENIVI/vehicle_signal_specification -[ViWi]: https://www.w3.org/Submission/2016/SUBM-viwi-protocol-20161213/ -[OpenXC]: http://openxcplatform.com/ -[low level CAN service]: https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/low-level-can-generator -[high level ViWi]: https://github.com/iotbzh/high-level-viwi-service diff --git a/signaling/images/OpenXC_to_AGL.png b/signaling/images/OpenXC_to_AGL.png deleted file mode 100644 index 6e40336..0000000 Binary files a/signaling/images/OpenXC_to_AGL.png and /dev/null differ diff --git a/signaling/images/agent-arch.svg b/signaling/images/agent-arch.svg deleted file mode 100644 index bf3cede..0000000 --- a/signaling/images/agent-arch.svg +++ /dev/null @@ -1,352 +0,0 @@ - -image/svg+xmlLow Level binding -1 -Low Level binding -2 -Signal Agent General Architecture -Virtual Signal(Business Logic) -Access Control -Transport DBUS, WebSocket, ... -Publish/SubcribeSignal Exchange - \ No newline at end of file diff --git a/signaling/images/agent-sample.svg b/signaling/images/agent-sample.svg deleted file mode 100644 index 6fed96c..0000000 --- a/signaling/images/agent-sample.svg +++ /dev/null @@ -1,426 +0,0 @@ - -image/svg+xmlGPS NMEA -Geolocalisation Signal Agent -Geolocalisation(Business Logic) -Access Control -Transport DBUS, WebSocket, ... -Publish/SubcribeSignal Exchange -Accel + Gyro -ABS + others -IsFasterThanisOutOfZoneetc... -GetPositionGetSpeedIsMoving... - \ No newline at end of file diff --git a/signaling/images/can-generator.svg b/signaling/images/can-generator.svg deleted file mode 100644 index f5a567c..0000000 --- a/signaling/images/can-generator.svg +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CAN Low Level Bindng(Shared Library) - - - - - - - - - - - - - - OPENXC SignalDescription(JSON) - - - - - - - - - - - - - - - - - - - - - Low LevelBindingStatic Code(AGL) - - - - - - - - - - - - - - CANDecoding/EncodingC++ Code(vendor) - - - - - - - - - - - - - - OptionalMessageHandlers(vendor) - - - - - - - - - - - - - - - Call for decode/encode - - - - - - - - - - CANConfigGenerator - - - - - - - - - - C/C++Compiler - - - - - - - - - - - - - - OPENXC SignalDescription(JSON) - - - - - - - - - - - - - - OPENXC SignalDescription(JSON) - - - - - - - - \ No newline at end of file diff --git a/signaling/images/cloud-arch.svg b/signaling/images/cloud-arch.svg deleted file mode 100644 index 3cecbdc..0000000 --- a/signaling/images/cloud-arch.svg +++ /dev/null @@ -1,837 +0,0 @@ - -image/svg+xml -Access Control -Transport . -Custer ECU -Access Control -Transport DBUS, WebSocket, ... -NavigationService -Carte handling -POI management -etc... -CAN GPS -GeopositioningVirtualSignal -Multi ECU Architecture -ABS -Publish/Subscribe -IVI ECU -CAN-BUSVirtual Signal -Publish/Subscribe -Gyro, Acelerometer -CAN-BUS -LIN-BUS -ClusterVirtual Signal -Publish/Subscribe -Engine-CAN-BUS -ABS -1 -2 -3 -4 - \ No newline at end of file diff --git a/signaling/images/distributed-arch.png b/signaling/images/distributed-arch.png deleted file mode 100644 index 3c4f4a0..0000000 Binary files a/signaling/images/distributed-arch.png and /dev/null differ diff --git a/signaling/images/distributed-arch.svg b/signaling/images/distributed-arch.svg deleted file mode 100644 index b52b3a5..0000000 --- a/signaling/images/distributed-arch.svg +++ /dev/null @@ -1,717 +0,0 @@ - -image/svg+xmlAgent-2Car Environement -Agent-3Engine -Agent-4Remote Signal -CAN Bus-A -LIN Bus-A -Audio -CAN Bus-B -Cluster-Unit -... -Smart City -RVI -Cloud -Transport + Acess Control -NavigationService -Carte handling -POI management -etc... -Log/SupervisionService -Carte handling -POI management -etc... -MultiMediaService -Media Player -Radio Interface -etc... -Signal Messaging Distributed Architecture - \ No newline at end of file diff --git a/signaling/images/iotbzh_logo_small.png b/signaling/images/iotbzh_logo_small.png deleted file mode 100644 index 6a98c60..0000000 Binary files a/signaling/images/iotbzh_logo_small.png and /dev/null differ diff --git a/signaling/images/logo_iot_bzh.svg b/signaling/images/logo_iot_bzh.svg deleted file mode 100644 index aa23e84..0000000 --- a/signaling/images/logo_iot_bzh.svg +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - IOT - - BZH - - - - diff --git a/signaling/images/signal-service-arch.svg b/signaling/images/signal-service-arch.svg deleted file mode 100644 index 3dee802..0000000 --- a/signaling/images/signal-service-arch.svg +++ /dev/null @@ -1,296 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Binder - - - - - - - - CAN Low Level Binding(s)Decoding / EncodingAuthentication / Crypto / FirewallingTransaction (set… ack ...)Stats & MathsCaching (low freq. Signals, get() call)Debug - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CAN High Level Binding(s)LogicAggregation (« vehicle.doors.any.open »)Advanced Ops - - - - - - - - - - - - - - - - - - - - - - - - - CAN BUS - - - - - - - - - - - - - - - - CAN frames - 011010010 - - - - - - - - - Signals - « vehicle.doors.left.open »(Binder Events) - - - - - - - - UI - - - - - - - - Publish Subscribe - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/signaling/index.md b/signaling/index.md deleted file mode 100644 index cb466ae..0000000 --- a/signaling/index.md +++ /dev/null @@ -1,50 +0,0 @@ -# AGL Message Signaling - -## Architecture - -This [document](./architecture.md) presents an architecture for message signaling in AGL. - -Also available as a [PDF Document](http://iot.bzh/download/public/2016/signaling/AGL-Message-Signaling-Architecture.pdf) - -## Documentation - -Developer Guidelines are available as a [PDF Document](http://iot.bzh/download/public/2016/signaling/AGL-Message-Signaling-Developer-Guidelines.pdf) - -A GPS Binding example is available on Github: [github:iotbzh/af-gps-binding](https://github.com/iotbzh/af-gps-binding) - -## OpenXC Demo - -A reference HTML5 application has been developed: see [github:iotbzh/txc-demo](https://github.com/iotbzh/txc-demo). - -This application uses a [OpenXC trace file](http://openxcplatform.com/resources/traces.html) to display 4 different panels representing live vehicle data. - -It's available as an [AGL Application package](http://iot.bzh/download/public/2016/afb-demos/txc-demo_0.1.wgt) installable through AGL Application Framework. - -## Low level CAN service - -A project to access and decode CAN bus has been developed and part of AGL since Daring Dab version: [Low level CAN service](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/apps/low-level-can-service) - -This rewrite of OpenXC to adapt the project to AGL. - -Must be used in conjunction with the [low level CAN generator](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/low-level-can-generator) to custom your service. - -## High Level ViWi service - -An implementation of [ViWi](https://www.w3.org/Submission/2016/SUBM-viwi-protocol-20161213/) protocol has been made and available : [github.com:iotbzh/high-level-viwi-service](https://github.com/iotbzh/high-level-viwi-service) - -## Benchmarks - -Some tests to evaluate the performances of the framework have been done by simulating CAN Data: [AGL-AppFW-CAN-Signaling-Benchmark.pdf](http://iot.bzh/download/public/2016/signaling/AGL-AppFW-CAN-Signaling-Benchmark.pdf) - -## AMM Munich'16 Presentation - -[Jose's presentation at AGL AMM Munich'16](http://iot.bzh/download/public/2016/build-agl-application-AMM-Munich-2016/) - -## AMM Tokyo'17 Presentation - -[Kusakabe-san from Fujitsu-Ten presentation at AGL AMM Tokyo'17](http://schd.ws/hosted_files/aglmmwinter2017/37/20170201_AGL-AMM_F10_kusakabe.pdf) - -## F2F Karslruhe'17 Presentation - -[Romain's presentation at AGL F2F Karslruhe'17](http://iot.bzh/download/public/2017/F2F-Karslruhe/AGL-Signaling.pdf) -[Kusakabe-san from Fujitsu-Ten presentation at AGL F2F Karslruhe'17](https://wiki.automotivelinux.org/_media/agl-distro/20170402_ften_can_kusakabe_v2.pdf) -- cgit 1.2.3-korg