docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/1_Architecture.md

   1 ---
   2 edit_link: ''
   3 title: Architecture presentation
   4 origin_url: >-
   5   https://git.automotivelinux.org/apps/agl-service-signal-composer/plain/docs/part-1/1-Architecture.md?h=master
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/apis_services/master/agl-service-signal-composer-developer-guides-api-services-book.yml -->
   9
  10 # Signal Composer
  11
  12 ## Architecture
  13
  14 Here is a quick picture about the signaling architecture :
  15
  16 ![GlobalArchitecture]
  17
  18 Key here are on both layers, **low** and **high**.
  19
  20 - **Low levels** binding used as _AGL service_, handle data exchange protocol to
  21  decode/encode and retransmit with an AGL compatible format using **Application
  22  Framework** events. These are divided into two parts, which are :
  23   - A transport Layer binding's plug-in that is able to read/write from a device.
  24   - Decoding/Encoding parts that expose signals.
  25 - **High level signal composer** binding gathers multiple **low level** signaling
  26  sources. Then from these sources, it exposes theirs **raw** signals or more interesting
  27  can creates new virtuals signals from them. Example:
  28  A signal made from gps latitude and longitude that computes the heading of
  29  vehicle. This is modular and each signal source should be handled by specific
  30  plugins which take care of get the underlying event from **low level** or
  31  define signaling composition with simple or complex operation to output value
  32  from **raw** signals.
  33
  34 A transport plug-in is a shared library that shares a common API to be
  35 compatible with **low level** services that is:
  36
  37 - **open/close**: method to open a handle which could be a socket, file or
  38  device by example.
  39 - **read/write**: method to read and write a stream of data.
  40
  41 Configuration is made by sending a special packet using a write method to the
  42 handle. In brief, this could be compared to the layer 1 and 2 of [OSI model].
  43
  44 There are three main parts with **Signal Composer**:
  45
  46 - Configuration files which could be splitted in differents files. That will
  47  define:
  48   - metadata with name of **signal composer** api name
  49   - additionnals configurations files
  50   - plugins used if so, **low level** signals sources
  51   - signals definitions
  52 - Dedicated plugins
  53 - Signal composer API
  54
  55 ## Terminology
  56
  57 Here is a little terminology guide to set the vocabulary:
  58
  59 - **api**: a binding API name
  60 - **action**: a function called at a certain time
  61 - **callbacks**: a function called at a certain time
  62 - **event**: the raw event that materialize the signal
  63 - **plugins**: a C/C++ code with functions that be called by signal composer
  64  service
  65 - **sources**: an external binding API that generate signals for the signal
  66  composer service
  67 - **signals**: an event generated by the **Application Framework**
  68 - **virtual signals**: a signal composed of **raw signals** with value
  69  calculated by a **callbacks**
  70 - **raw signals**: an event generated by a **low level** binding
  71
  72 [OSI model]: https://en.wikipedia.org/wiki/OSI_model
  73 [GlobalArchitecture]: pictures/Global_Signaling_Architecture.png "Global architecture"