Added documentation

Change-Id: Iaa6bb0470652d3d0dc97c6320dbf210567ccec80
Signed-off-by: Romain Forlot <romain.forlot@iot.bzh>

7 files changed, 165 insertions, 0 deletions

diff --git a/docs/part-1/0_Abstract.md b/docs/part-1/0_Abstract.md
new file mode 100644
index 0000000..beb610a
--- /dev/null
+++ b/docs/part-1/0_Abstract.md
@@ -0,0 +1,9 @@
+# Signal Composer binding: A high level signal handler
+
+## Abstract
+
+You will find in this documentation a presentation about Signal Composer
+architecture. Signal Composer is an Application Framework binding meant to
+facilitate handling signaling, by compose, divide and create new virtuals
+signals from RAW signals coming from _low level_ binding that handle read/write,
+encode/decode on different protocols that a car could use (CAN, LIN, Ethernet, GPS, i2c, ...).
diff --git a/docs/part-1/1-Architecture.md b/docs/part-1/1-Architecture.md
new file mode 100644
index 0000000..a907882
--- /dev/null
+++ b/docs/part-1/1-Architecture.md
@@ -0,0 +1,44 @@
+# Signal Composer
+
+## Architecture
+
+Here is a quick picture about the signaling architecture :
+
+![GlobalArchitecture]
+
+Key here are on both layer, **low** and **high**.
+
+- **Low level** are in charge of handle a data exchange protocol to decode/encode and retransmit
+ with an AGL compatible format, most convenient way using **Application Framework** event. These are divised in two parts, which are :
+  - Transport Layer plug-in that read/write 1 protocol.
+  - Decoding/Encoding part that expose signals and a way to access them.
+- **High level signal composer** gathers multiple **low level** signaling sources and creates new
+ virtuals signals from the **raw** signals defined (eg. signal made from gps latitude and
+ longitude that calcul the heading of vehicle). It is modular and each signal source should be
+ handled by specific plugins which take care of get the underlying event from **low level** or
+ define signaling composition with simple or complex operation to output value from **raw** signals
+
+There are three main parts with **Signal Composer**:
+
+- Configuration files which could be splitted in differents files. That will define:
+  - metadata with name of **signal composer** api name
+  - additionnals configurations files
+  - plugins used if so, **low level** signals sources
+  - signals definitions
+- Dedicated plugins
+- Signal composer API
+
+## Terminology
+
+Here is a little terminology guide to set the vocabulary:
+
+- **sources**
+- **signals**
+- **api**
+- **event**
+- **callbacks**
+- **action**
+- **virtual signals**
+- **raw signals**
+
+[GlobalArchitecture]: pictures/Global_Signaling_Architecture.png "Global architecture"
diff --git a/docs/part-1/2-Configuration.md b/docs/part-1/2-Configuration.md
new file mode 100644
index 0000000..a68fd62
--- /dev/null
+++ b/docs/part-1/2-Configuration.md
@@ -0,0 +1,75 @@
+# Configuration
+
+Configuration defines all in **Signal composer** each signals and sources has to be defined in it.
+At start, configuration will be searched in default binding configuration directory which should be
+_/var/lib/afm/applications/signal-composer/1.0/etc/_. Binding search for a file name as _init-daemon*.json_. Others files could be used to split sections and don't have 1 big fat definitions file.
+
+Saying that you have 4 sections to define:
+
+- **metadata**: Main parts and the only one that can't be in a separates configuration. This must appears in the main configuration file.
+- **plugins** (optionnal): Declare plugins that will be used by *sources* and *signals* for the subscription and composition.
+- **sources**: Declare **low level** signals sources (eg. low-can, gps, mraa, ...).
+- **signals**: Declare signals, virtuals and raw.
+
+## Metadata
+
+Here we define some metadata about **signal composer** binding. Fields to configure
+are :
+
+- **label**: self-explanatory
+- **version** (optionnal): self-explanatory
+- **api**: name that the binding will be initialized to and later be accessible by **Application Framework**
+- **info** (optionnal): self-explanatory
+- **require** (optionnal): list of required external apis.
+- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of it without extension. These
+ files are loaded to find sections: *plugins*, *sources* and *signals*.
+
+## Plugins
+
+This section is the only which is optionnal, it is needed if you develop specifics C/C++ plugins
+to be used with signal-composer. LUA and API consumption does not need plugins.
+
+Default path to search for a plugin is in the binding library directory in a subdirectory _plugins_
+_/var/lib/afm/applications/signal-composer/1.0/lib/plugins_. Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a semicolon separated list of
+directory.
+
+Fields are:
+
+- **label**: Define the plugin name. This is that label that will be used on **sources** and
+ **signals** callbacks.
+- **version** (optionnal): self-explanatory
+- **info** (optionnal): self-explanatory
+- **basename**: shared library file name **without** the extension.
+
+## Sources
+
+A source is a **low level** API that will be consume by the **signal composer**
+to be able to expose those signals with additionnals treatments, filtering,
+thinning,... and create new virtuals signals composed with basic raw signals.
+
+A source is defined with following fields:
+
+- **api**: Name of the source API.
+- **info** (optionnal): self-explanatory
+- **init** (optionnal): an **action** to take to initialize a source. May you have  to call a verb from that API, of create a files etc.
+- **getSignals** (optionnal); an **action** to take to get signals from that
+ source. These callback will be used for each signals defined later in the **signals** section. Dedicated arguments for each signal could be defined in
+ **signals**.
+
+## Signals
+
+A signal definition could be either a **raw** one or a **virtual** one. A **virtual signal** is a set of existing **raw signals** associated to an **action**
+on reception which will compute the value of the signal.
+
+- **id**: Unique identifier used inside **signal composer**, used to compose virtual signals.
+- **event**: specify a **raw signal** coming from **low level** sources. Couldn't
+ be used with **depends** field, only one of them is possible.
+- **depends**: specify others signals **id** that compose it (eg: heading is
+ composed with longitude+latitude signals.). Couldn't be used with **event** field
+ at same time.
+- **unit** (optionnal): Unit used to exprime the signal
+- **frequency** (optionnal): Frequency maximum at which the signal could be
+ requested or sent. This is a thinning made at **high level** so not best suited for performance. Used **low level** native filtering capabilities when possible.
+- **getSignalsArgs**: a JSON object used at subscription time. Meant to enabled
+ filtering capabilities at subscription and to be able to customize in general a subcription request by signal if needed.
+- **onReceived**: an **action** to take when this signal is received!
diff --git a/docs/part-1/3-Plugins.md b/docs/part-1/3-Plugins.md
new file mode 100644
index 0000000..1cfb580
--- /dev/null
+++ b/docs/part-1/3-Plugins.md
@@ -0,0 +1,4 @@
+# Plugins
+
+Plugins are C/C++ shared library that is loaded by the binding to execute some simple routine. Routine could be on reception of a new signal or at sources
+initialization time or signal subscription with the respective JSON field **onReceived**, **init** and **getSignals**.
diff --git a/docs/part-1/4-SignalComposerAPI.md b/docs/part-1/4-SignalComposerAPI.md
new file mode 100644
index 0000000..6e53800
--- /dev/null
+++ b/docs/part-1/4-SignalComposerAPI.md
@@ -0,0 +1,33 @@
+# Signal Composer API
+
+## get
+
+You can get a signal value be requesting the API with the verb *get*:
+
+```json
+signal-composer get {"signal": "vehicle_speed", "options": {"average": 10}}
+signal-composer get {"signal": "vehicle_speed", "options": {"minimum": 10}}
+signal-composer get {"signal": "vehicle_speed", "options": {"maximum": 10}}
+signal-composer get {"signal": "vehicle_speed"}
+```
+
+You apply apply some simple mathematical function by default present in the binding
+, by default **last** is used:
+
+- **average**: make an average on X latest seconds.
+- **minimum**: return the minimum value found in the X latest seconds.
+- **maximum**: return the maximum value found in the X latest seconds.
+- **last**: return the latest value.
+
+## list
+
+Verb **list** will output the list of defined signals.
+
+## loadConf
+
+Verb **loadConf** let you add new files to be able to add new **sources** or
+**signals**.
+
+```json
+signal-composer loadConf {"filepath": "/path/to/your/json/file.json"}
+```
diff --git a/docs/part-1/pictures/Global_Signaling_Architecture.png b/docs/part-1/pictures/Global_Signaling_Architecture.png
new file mode 100644
index 0000000..7934d3f
--- /dev/null
+++ b/docs/part-1/pictures/Global_Signaling_Architecture.png
diff --git a/docs/part-1/pictures/iotbzh_logo_small.png b/docs/part-1/pictures/iotbzh_logo_small.png
new file mode 100644
index 0000000..6a98c60
--- /dev/null
+++ b/docs/part-1/pictures/iotbzh_logo_small.png