diff options
Diffstat (limited to 'docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer')
5 files changed, 285 insertions, 0 deletions
diff --git a/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/1_Architecture.md b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/1_Architecture.md new file mode 100644 index 0000000..62c2f0f --- /dev/null +++ b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/1_Architecture.md @@ -0,0 +1,73 @@ +--- +edit_link: '' +title: Architecture presentation +origin_url: >- + https://git.automotivelinux.org/apps/agl-service-signal-composer/plain/docs/part-1/1-Architecture.md?h=master +--- + +<!-- 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 --> + +# Signal Composer + +## Architecture + +Here is a quick picture about the signaling architecture : + +![GlobalArchitecture] + +Key here are on both layers, **low** and **high**. + +- **Low levels** binding used as _AGL service_, handle data exchange protocol to + decode/encode and retransmit with an AGL compatible format using **Application + Framework** events. These are divided into two parts, which are : + - A transport Layer binding's plug-in that is able to read/write from a device. + - Decoding/Encoding parts that expose signals. +- **High level signal composer** binding gathers multiple **low level** signaling + sources. Then from these sources, it exposes theirs **raw** signals or more interesting + can creates new virtuals signals from them. Example: + A signal made from gps latitude and longitude that computes the heading of + vehicle. This 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 shares 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 +- **plugins**: a C/C++ code with functions that be called by signal composer + service +- **sources**: an external binding API that generate signals for the signal + composer service +- **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" diff --git a/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/2_Configuration.md b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/2_Configuration.md new file mode 100644 index 0000000..6bd3a8a --- /dev/null +++ b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/2_Configuration.md @@ -0,0 +1,109 @@ +--- +edit_link: '' +title: Configuration +origin_url: >- + https://git.automotivelinux.org/apps/agl-service-signal-composer/plain/docs/part-1/2-Configuration.md?h=master +--- + +<!-- 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 --> + +# 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/local/lib/afm/applications/signal-composer/VER/etc/_, +VER is the version of **signal composer**. +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** (optional): 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 : + +- **uid**: self-explanatory +- **version** (optional): self-explanatory +- **api** (optional): name that the binding will be initialized to and later + be accessible by **Application Framework** +- **info** (optional): self-explanatory +- **require** (optional): list of required external apis. + +## Plugins + +This section is the only which is optional, 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/local/lib/afm/applications/signal-composer/VER/lib/plugins_. +Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a +semicolon separated list of directory. + +Fields are: + +- **uid**: Define the plugin name. This is that label that will be used on + **sources** and **signals** callbacks. +- **ldpath** (optional): path to the plugin directory +- **info** (optional): self-explanatory +- **basename**: shared library file name **without** the extension. +- **files** (optional): list of additionnals files. **ONLY NAME** or part of + it, without extension. Don't mix up section object with this key, either one + or the other but avoid using both + +## 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: + +- **uid**: An unique identifier name for thatuid source API. +- **api**: Name of the source API. +- **info** (optional): self-explanatory +- **init** (optional): an **action** to take to initialize a source. May you + have to call a verb from that API, of create a files etc. +- **getSignals** (optional); 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**. +- **files** (optional): list of additionnals files. **ONLY NAME** or part of + it, without extension. Don't mix up section object with this key, either one + or the other but avoid using both + +## 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. + +- **uid**: 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. +- **retention** (optional): retention duration in seconds +- **unit** (optional): Unit used to exprime the signal +- **frequency** (optional): 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! +- **files** (optional): list of additionnals files. **ONLY NAME** or part of + it, without extension. Don't mix up section object with this key, either one + or the other but avoid using both diff --git a/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/3_Plugins.md b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/3_Plugins.md new file mode 100644 index 0000000..aa0ebb4 --- /dev/null +++ b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/3_Plugins.md @@ -0,0 +1,32 @@ +--- +edit_link: '' +title: Plugins +origin_url: >- + https://git.automotivelinux.org/apps/agl-service-signal-composer/plain/docs/part-1/3-Plugins.md?h=master +--- + +<!-- 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 --> + +# Plugins + +Plugins are C/C++ shared libraries 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` + +A default plugin (builtin) is provided with 2 functions: + +- **defaultOnReceived**: set and record a new signal value and its timestamp + in the signal composer service. It simply tooks the incoming event JSON object + and search for *key* `value` and `timestamp` then call function + `setSignalValue`. +- **setSignalValueWrap**: a `lua2c` function the could be called from any LUA + script to record a new signal value. + +> **CAUTION**: `timestamp` value has to be typed as *uint64_t* with +> a **nanosecond** precision using a realtime clock. To correctly store it in +> a JSON-C object use the int64 type with the according fonctions: +> *json_object_new_int64()* +> *json_object_get_int64()* +> *json_object_set_int64()* +> *...* diff --git a/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/4_SignalComposerAPI.md b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/4_SignalComposerAPI.md new file mode 100644 index 0000000..cc1688c --- /dev/null +++ b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/4_SignalComposerAPI.md @@ -0,0 +1,71 @@ +--- +edit_link: '' +title: Signal Composer API +origin_url: >- + https://git.automotivelinux.org/apps/agl-service-signal-composer/plain/docs/part-1/4-SignalComposerAPI.md?h=master +--- + +<!-- 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 --> + +# Signal Composer API + +## subscribe/unsubscribe + +Using subscribe you can get update on change for signals you chose and you can +using wildcard to subscribe several signals in the same time. + +```json +signal-composer subscribe {"signal": "rear_left*"} +ON-REPLY 1:signal-composer/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"3d4b743b-7ac6-4d3c-8fce-721107f9dee5"}} +``` + +Then event comes up like the following: + +```json +ON-EVENT signal-composer/257b343e-8ea9-4cd7-8f9e-1904fa77f8f2({"event":"signal-composer\/257b343e-8ea9-4cd7-8f9e-1904fa77f8f2","data":{"uid":"rear_left_door","event":"low-can\/messages.doors.rear_left.open","timestamp":4833910845032292484,"value":false},"jtype":"afb-event"}) +``` + +Unsubscribe happens the same way. When no more signals are holded by the client +then it unsubscribe from the *AGL Application Framework* event handle. + +## addObjects + +Let you add sources or signals objects to the signal composer service after +its initialization phase. Use this verb and specify the file as argument, you +could use only the file name or the file name with its absolute path. + +```json +signal-composer addObjects {"file": "sig_doors.json"} +ON-REPLY 1:signal-composer/addObjects: {"jtype":"afb-reply","request":{"status":"success","uuid":"00d7a519-816e-486a-8163-3afb1face4fa"}} +signal-composer addObjects {"file": "/tmp/sig_doors.json"} +ON-REPLY 2:signal-composer/addObjects: {"jtype":"afb-reply","request":{"status":"success"}} +``` + +You can follow the activity using the service log journal and check that the +correct number of objects has been added. + +> **CAUTION**: You need to get the following permission to be able to load new +objects : `urn:AGL:permission::platform:composer:addObjects` + +## 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 some simple mathematical functions 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. diff --git a/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/pictures/Global_Signaling_Architecture.png b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/pictures/Global_Signaling_Architecture.png Binary files differnew file mode 100644 index 0000000..5cfba98 --- /dev/null +++ b/docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/pictures/Global_Signaling_Architecture.png |
