DESF library

1.0

This is the docmentation of DESF (Distributed Embedded System Framework) library.
Author: Roberto Sartori.

Overview


The DESF (Distributed Embedded System Framework) library helps the development of system architectures where multiple activities runs in parallel exchanging data and synchronizing their workflow through synch and data messages.
DESF approaches the architecture design in terms of tasks. A task is a subpart of a system or a program that exchanges data with other tasks by means of the mechanism of notification.

DESF_Task_Example.jpg

Figure 1.1) an activity that is not a DESF task (A) and how it can be thought as composed by two tasks (B)

An example:
a single threaded application that is looping the sampling and the logging of an accelerometer's value is not a DESF task because it does not require to exchange data with other applications, threads or devices (see fig. 1.1A). Differently, sampling and logging operations could be thought as two separated tasks where the sampler notifies the new value and the logger will receive a notification containing the new value (see fig. 1.1B): both can be now considered to be DESF tasks because they now exchange data eachother using notification mechanism.

Notifications


A notification is a message exchanged between tasks and dispatched by DESF. DESF library implements the software layer in charge of this notification dispatching. Four type of notifications are implemented:

Each of these notifications are now introduced in order to describe the usage of DESF in different possible scenarios.

Asynchronous data exchange

DESF_Asynch_Data_Example.jpg

Figure 1.2) possible usage of asynchronous data notification between tasks

In this scenario a task (producer) generates new data and notifies the new values to all tasks (consumers) that has been configured to receive that notification.
In this scenario, the notification embeds binary data.

Events

DESF_Event_Example.jpg

Figure 1.3) possible usage of asynchronous data notification between tasks

In event-driven scenarios, DESF allows tasks to notify the raising of an event and all tasks that have been registered to be notified by this event will receive that notification. In this scenario, the event notification does not transport any data.

On-request data

DESF_onRequest_Example.jpg

Figure 1.4) client-server architecture based on on-request data DESF protocol

This scenario refers to that situations in which a data is not required to be continously produced but it is supposed to be produced only when a task asks for it. Thus, this mechanism allows a task (master) to "ask for a data" and the task that is in charge for producing that data (slave) will respond to the master with a notification containing the required data. If needed, the master's notification can transport data to the slave.

Acknowledged data exchange

DESF_Acknowledge_Example.jpg

Figure 1.5) Acknowledge data exchange example

This scenario involves the exchange of data between tasks including an acknowledge response in order to confirm that the data has been received. This scenario is important in all that cases where the reception of a data must be acknowledged in order to continue the task. As an example, the software that manages critical processes (see fig. 1.5) must confirm that correct configuration parameters are received by the user

The DESF Manager


DESF_general_distributed_architecture.jpg

Figure 1.5) a generic DESF architecture and the role of DESF Managers

The mechanism of notification dispatching is realized by DESF managers. A DESF manager is a software module that is linked to a physical hardware device and allows the user to :

In fig. 1.5 a generic DESF architecture shows several possible configurations where each task is registered on one or more DESF managers:

In DESF, the comunication between local tasks is implement by a shared memory virtual device: in fig. 1.5, task 9 and 10 on board 2 can comunicate eachother by means of this virtual driver, the same for task 11 and 12 on board 1. Differently, a DESF manager installed on a physical comunication device does not allows the notification dispatching between local registered tasks (shared memory device has to be used for this scenario).

Next: Technical description