aboutsummaryrefslogtreecommitdiffstats
path: root/docs/part-1/1-Architecture.md
blob: daf1e37094d413ffda42ffe38b2b56e1a6c7a0b1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# 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 divided in two parts,
 which are :
  - Transport Layer plug-in that are able to read/write a 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

A transport plug-in is a shared library that shared a common API to be compatible with **low level** services that is:

- **open/close**: method to open a handle which could be a socket, file or
 device by example.
- **read/write**: method to read and write a stream of data.

Configuration is made by sending a special packet using a write method to the
handle. In brief, this could be compared to the layer 1 and 2 of [OSI model].

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:

- **api**: a binding API name
- **action**: a function called at a certain time
- **callbacks**: a function called at a certain time
- **event**: the raw event that materialize the signal
- **sources**: a binding API name
- **signals**: an event generated by the **Application Framework**
- **virtual signals**: a signal composed of **raw signals** with value
 calculated by a **callbacks**
- **raw signals**: an event generated by a **low level** binding

[OSI model]: https://en.wikipedia.org/wiki/OSI_model
[GlobalArchitecture]: pictures/Global_Signaling_Architecture.png "Global architecture"