Merge branch 'master' into master

3 files changed, 94 insertions, 95 deletions

diff --git a/signaling/architecture.md b/signaling/architecture.md
index 48d596f..2132c4a 100644
--- a/signaling/architecture.md
+++ b/signaling/architecture.md
@@ -12,6 +12,7 @@ layout: techdoc
 **Table of Content**
 
 1. TOC
+
 {:toc}
 
 ## Context
@@ -38,9 +39,9 @@ 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
-2. offer a high level API that obfuscates low level and proprietary interface to
+1. offer a high level API that obfuscates low level and proprietary interface to
  improve stability in time of the code
-3. hide specificities of low level implementation as well as the chosen
+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
@@ -439,13 +440,10 @@ 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
-2. Agent Signal has direct relation to low level signal
-3. Agent needs to proxy to an other service inside the same ECU to access the
-   signal
-4. Signal is not present on current ECU. Request has to be proxied to the
-   outside world
+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"
diff --git a/signaling/high-level-viwi-service.md b/signaling/high-level-viwi-service.md
index 6b512b9..bfc27d7 100644
--- a/signaling/high-level-viwi-service.md
+++ b/signaling/high-level-viwi-service.md
@@ -46,7 +46,7 @@ git clone --recursive https://gerrit.automotivelinux.org/gerrit/apps/low-level-c
 
 ```bash
 export WD=$(pwd)
-git clone --recusive https://github.com/iotbzh/high-level-viwi-service.git
+git clone --recursive https://github.com/iotbzh/high-level-viwi-service.git
 ```
 
 ## Build
@@ -82,41 +82,41 @@ For instance:
 
 ```json
 {
-	"name": "/car/demoboard/",
-	"properties": {
-		"id": {
-			"type": "string",
-			"description": "identifier"
-		},
-		"uri": {
-			"type": "string",
-			"description": "object uri"
-		},
-		"name": {
-			"type": "string",
-			"description": "name"
-		},
-		"unit": {
-			"type": "string",
-			"description": "units"
-		},
-		"speed": {
-			"type": "double",
-			"description": "vehicle centerpoint speed as shown by the instrument cluster"
-		},
-		"rpm": {
-			"type": "double",
-			"description": "engine rotations per minute"
-		},
-		"level": {
-			"type": "double",
-			"description": "level of tankage"
-		},
-		"load": {
-			"type": "double",
-			"description": "engine load"
-		}
-	}
+    "name": "/car/demoboard/",
+    "properties": {
+        "id": {
+            "type": "string",
+            "description": "identifier"
+        },
+        "uri": {
+            "type": "string",
+            "description": "object uri"
+        },
+        "name": {
+            "type": "string",
+            "description": "name"
+        },
+        "unit": {
+            "type": "string",
+            "description": "units"
+        },
+        "speed": {
+            "type": "double",
+            "description": "vehicle centerpoint speed as shown by the instrument cluster"
+        },
+        "rpm": {
+            "type": "double",
+            "description": "engine rotations per minute"
+        },
+        "level": {
+            "type": "double",
+            "description": "level of tankage"
+        },
+        "load": {
+            "type": "double",
+            "description": "engine load"
+        }
+    }
 }
 ```
 
@@ -138,24 +138,24 @@ For instance:
 
 ```json
 {
-	"name": "/car/demoboard/",
-	"values": [{
-		"name": "vehicleSpeed",
-		"unit": "km/h",
-		"speed": "${diagnostic_messages.vehicle.speed,1000}"
-	}, {
-		"name": "engineSpeed",
-		"unit": "rpm",
-		"rpm": "${diagnostic_messages.engine.speed,1000}"
-	}, {
-		"name": "fuelLevel",
-		"unit": "litre",
-		"level": "${diagnostic_messages.fuel.level,1000}"
-	}, {
-		"name": "engineLoad",
-		"unit": "Nm",
-		"load": "${diagnostic_messages.engine.load,1000}"
-	}]
+    "name": "/car/demoboard/",
+    "values": [{
+        "name": "vehicleSpeed",
+        "unit": "km/h",
+        "speed": "${diagnostic_messages.vehicle.speed,1000}"
+    }, {
+        "name": "engineSpeed",
+        "unit": "rpm",
+        "rpm": "${diagnostic_messages.engine.speed,1000}"
+    }, {
+        "name": "fuelLevel",
+        "unit": "litre",
+        "level": "${diagnostic_messages.fuel.level,1000}"
+    }, {
+        "name": "engineLoad",
+        "unit": "Nm",
+        "load": "${diagnostic_messages.engine.load,1000}"
+    }]
 }
 ```
 
@@ -185,7 +185,7 @@ On another terminal, connect to the binding using previously installed
 _**AFB Websocket CLI**_ tool:
 
 ```bash
-$ afb-client-demo ws://localhost:1234/api?token=1
+afb-client-demo ws://localhost:1234/api?token=1
 ```
 
 You will be on an interactive session where you can communicate directly with
@@ -197,7 +197,7 @@ _unsubscribe_, which can take a JSON object as an argument.
 To use the _**AFB Websocket CLI**_ tool, a command line will be like the
 following:
 
-```
+```bash
 <api> <verb> <arguments>
 ```
 
@@ -209,7 +209,7 @@ Where:
 
 You can therefore use commands such as:
 
-```
+```json
 high-can subscribe {"name":"/car/doors/","interval":10000}
 high-can unsubscribe {"name":"/car/doors/","interval":10000}
 high-can get {"name":"/car/demoboard/"}
@@ -218,7 +218,7 @@ high-can get {"name":"/car/demoboard/","fields":["fuelLevel","engineLoad"]}
 
 For instance the output of the third command should be:
 
-```
+```json
 high-can get {"name":"/car/demoboard/"}
 ON-REPLY 1:high-can/get: {"response":{"\/car\/demoboard\/2159e2-5b638a-39e242-7a2f5":{"id":"2159e2-5b638a-39e242-7a2f5","name":"vehicleSpeed","speed":0.000000,"unit":"km\/h","uri":"\/car\/demoboard\/2159e2-5b638a-39e242-7a2f5"},"\/car\/demoboard\/22ad2c-5a3c2b-50fabb-324c82":{"id":"22ad2c-5a3c2b-50fabb-324c82","level":0.000000,"name":"fuelLevel","unit":"litre","uri":"\/car\/demoboard\/22ad2c-5a3c2b-50fabb-324c82"},"\/car\/demoboard\/3a3ab9-2bd52c-11d30-689acf":{"id":"3a3ab9-2bd52c-11d30-689acf","name":"engineSpeed","rpm":0.000000,"unit":"rpm","uri":"\/car\/demoboard\/3a3ab9-2bd52c-11d30-689acf"},"\/car\/demoboard\/5ae808-8093cb-99716-30a605":{"id":"5ae808-8093cb-99716-30a605","load":0.000000,"name":"engineLoad","unit":"Nm","uri":"\/car\/demoboard\/5ae808-8093cb-99716-30a605"}},"jtype":"afb-reply","request":{"status":"success","uuid":"44ce03f9-a7ca-49e1-a62a-40c74db0caa0"}}
 ```
@@ -232,5 +232,5 @@ You can find an example of data in high level binding, "samples" directory.
 For instance, on a third terminal:
 
 ```bash
-$ canplayer -I candata
-```
\ No newline at end of file
+canplayer -I candata
+```
diff --git a/signaling/low-level-can-service-guide.md b/signaling/low-level-can-service-guide.md
index 6b3eb47..821f3e9 100644
--- a/signaling/low-level-can-service-guide.md
+++ b/signaling/low-level-can-service-guide.md
@@ -18,7 +18,7 @@ CAN binding will be separated in two parts:
 
 ![CAN low and high level bindings mapping](images/CAN_level_mapping.png)
 
-- High level: Binding from which others applications will connect to.
+* High level: Binding from which others applications will connect to.
  It provides valuable access to the CAN bus by aggregate signals or providing
  new signals from several originals. For example, a signal exposing whether or
  not a door is open, no matter which one it is. Also, we can imagine an
@@ -27,7 +27,7 @@ CAN binding will be separated in two parts:
  a single event representing that behavior to the application which in turn will
  send a phone message to.
 
-- Low level: Decode messages that transit and send event through **Application
+* Low level: Decode messages that transit and send event through **Application
  Framework** to the subscribers with human readable message. It provides some
  basic access to the bus + some basic mathematical, statistical features
  (last_values, min, max, timestamps, averaging) as well as basic filter to get
@@ -40,13 +40,13 @@ OpenXC inspired [AGL low level CAN binding Generator](http://github.com/iotbzh/c
 
 # Prerequisites
 
-- An AGL system installed with latest Daring Dab version with latest Application
+* An AGL system installed with latest Daring Dab version with latest Application
  framework version >= 0.6.
-- Make sure you built the AGL generator else you will not be able to generate
+* Make sure you built the AGL generator else you will not be able to generate
  custom low-level CAN binding.
 It will produce a _application-generated.cpp_ file to paste in the source,
  _CAN-binder/low-can-binding/binding/_, directory.
-- Make sure you already set up the AGL SDK using the following
+* Make sure you already set up the AGL SDK using the following
  [SDK Quick Setup Guide](http://docs.iot.bzh/docs/getting_started/en/dev/reference/setup-sdk-environment.html).
  Alternatively, please refer to official guides available on [AGL Developer Site](http://docs.automotivelinux.org/docs/devguides/en/dev/#guides).
 
@@ -63,7 +63,7 @@ prepare_meta -f iotbzh -o /xdt -l /home/devel/mirror -p /home/devel/share/propri
 /xdt/build/m3ulcb/agl-init-build-env
 ```
 
-- (Optionnal) An [USB CAN adapter](http://shop.8devices.com/usb2can) connected to
+* (Optionnal) An [USB CAN adapter](http://shop.8devices.com/usb2can) connected to
  connector through the [right cable](http://www.mouser.fr/ProductDetail/EasySync/OBD-M-DB9-F-ES/))
 if you want to connect to a real car through the OBD2 connector.
 
@@ -73,8 +73,8 @@ if you want to connect to a real car through the OBD2 connector.
 
 ### Build requirements
 
-- CMake version 3.3 or later
-- G++, Clang++ or any C++11 compliant compiler.
+* CMake version 3.3 or later
+* G++, Clang++ or any C++11 compliant compiler.
 
 ### Compile
 
@@ -102,7 +102,7 @@ to the right the more it will be accurate.
 Let's take an example, here is an example about standard PID name following this
 convention:
 
-```
+```bash
 engine.load
 engine.coolant.temperature
 fuel.pressure
@@ -136,10 +136,10 @@ engine.torque
 
 You can use some basic decoder provided by default by the binding which are:
 
-- ***decoder_t::noopDecoder*** : Default decoder if not specified, return raw
+* ***decoder_t::noopDecoder*** : Default decoder if not specified, return raw
  value from signal's bitfield.
-- ***decoder_t::booleanDecoder*** : Coerces a numerical value to a boolean.
-- ***decoder_t::stateDecoder***s : Find and return the corresponding string
+* ***decoder_t::booleanDecoder*** : Coerces a numerical value to a boolean.
+* ***decoder_t::stateDecoder***s : Find and return the corresponding string
  state for a CAN signal's raw integer value.
 
 ### Generating JSON from Vector CANoe Database
@@ -152,9 +152,9 @@ be able to use the OpenXC `xml_to_json.py` script to make your JSON for you.
 First, export the Canoe .dbc file as XML - you can do this with Vector CANdb++.
 Next, create a JSON file according to the format defined above, but only define:
 
-- CAN messages.
-- Name of CAN signals within messages and their generic_name.
-- Optionnaly name of diagnostic messages and their name.
+* CAN messages.
+* Name of CAN signals within messages and their generic_name.
+* Optionnaly name of diagnostic messages and their name.
 
 To install the OpenXC utilities and runs `xml_to_json.py` script:
 
@@ -212,9 +212,9 @@ binding.
 
 ### Build requirements
 
-- Kernel >= 4.8
-- CMake version 3.3 or later
-- G++, Clang++ or any C++11 compliant compiler.
+* Kernel >= 4.8
+* CMake version 3.3 or later
+* G++, Clang++ or any C++11 compliant compiler.
 
 ### Compile
 
@@ -254,6 +254,7 @@ On the target, assuming _**wgt**_ file is in the root home directory:
 afm-util install low-can-service.wgt
 { "added": "low-can-service@4.0" }
 ```
+
 # Configure the AGL system
 
 ## Virtual CAN device
@@ -359,7 +360,7 @@ in section `CANbus-mapping`.
 Default binding configuration use a CAN bus named `hs` so you need to map it to
 the real one, here are some examples:
 
-- Using virtual CAN device as described in the previous chapter:
+* Using virtual CAN device as described in the previous chapter:
 
 ```ini
 [CANbus-mapping]
@@ -367,7 +368,7 @@ hs="vcan0"
 ls="vcan1"
 ```
 
-- Using real CAN device, this example assume CAN bus traffic will be on can0.
+* Using real CAN device, this example assume CAN bus traffic will be on can0.
 
 ```ini
 [CANbus-mapping]
@@ -375,7 +376,7 @@ hs="can0"
 ls="can1"
 ```
 
-- On a Rcar Gen3 board there is an embedded CAN device so `can0` already
+* On a Rcar Gen3 board there is an embedded CAN device so `can0` already
  exists. So you might want to use your USB CAN adapter plugged to the OBD2
  connector, in this case use `can1`:
 
@@ -388,7 +389,7 @@ hs="can1"
 > configuration file match those specified in your generated source file with
 > the `CAN-config-generator`.
 
-# Run it, test it, use it !
+# Run it, test it, use it
 
 You can run the binding using **afm-util** tool, here is the classic way to go:
 
@@ -438,7 +439,7 @@ JSON file used to generate cpp file for the binding.
 To use the _**AFB Websocket CLI**_ tool, a command line will be like the
 following :
 
-```
+```xml
 <api> <verb> <arguments>
 ```
 
@@ -515,13 +516,13 @@ It is possible to limits received event notifications into minimum and maximum
 boundaries as well as doing frequency thinning. This is possible using the
 argument filter with one or more of the filters available :
 
-- frequency: specify in Hertz the frequency which will be used to getting
+* frequency: specify in Hertz the frequency which will be used to getting
  notified of new CAN events for the designated signal. If, during the
  blocked time, further changed CAN messages are received, the last valid one
  will be transferred after the lockout with a RX_CHANGED.
-- min: Minimum value that the decoded value needs to be above to get pushed
+* min: Minimum value that the decoded value needs to be above to get pushed
  to the subscribed client(s).
-- max: Maximum value that the decoded value needs to be below to get pushed to
+* max: Maximum value that the decoded value needs to be below to get pushed to
  the subscribed client(s)
 
 Order doesn't matter neither the number of filters chosen, you can use one, two