An alternative approach to embedded program definition

The standard approach to embedded program design can be characterized as:

    "timer tick->get all inputs->do all processing->set all outputs->go to sleep"

This approach produces a series of problems which are entirely the creation of the software design. Whilst there will be a few signals for which the maximum speed of response is required most will be associated with physical quantities which cannot change quickly.

There is simply no need to process all of the inputs, all of the time.

The "get the inputs, do the processing, set the outputs" certainly isn't the way the design will be specified. It is much more likely to be represented as a number of, largely independent, control sequences. Typically

This style of representing the requirements indicates a set of independent (or relatively loosely coupled) control sequences. These could be regarded as largely separate and implemented as such. It also highlights the dependencies within each element of the control algorithms. You know precisely when the volume must be recalculated - it is whenever either the pressure or temperature changes. As importantly, if they don't change then there is no need to perform any of the processing. If neither the pressure not temperature changes then the output is guaranteed to be stable.

deltaFSD exploits this approach by marrying:

  • A graphic programming tool which matches this design approach.
  • An execution engine which exploits the dependencies which are defined.

The deltaFSD design for the above might look like:

Using a graphical approach to defining a sequence of functions for execution isn't very impressive - any flow chart or structure diagram does this.

What marks out deltaFSD - and makes it practical for real time applications is that the graphical element is used to define a set of function sequences which can be fed to an execution engine.

The graphical tool outputs a function:variable framework which can be applied directly to the final application. The framework incorporates the dependiecies needed for each element of the control.

The overal operation, and inherent simplicity, is best understood by considering the operation of the execution "engine" - the code which is driven by the function:variable data framework.

Essentially this execution engine implement two rules:

  1. If a variable (or input) changes we need to execute all of the functions dependant on it.
  2. If a function is recalculated then it will (in general) modify all of its output variables.

Because the engine only ever works on one point (function or variable) of the function:variable framework at any time the tree of dependencies does not need to expanded. All that is required is that the individual elements are specified:

    The input temperature changes

    The scaled temperature must be recalculated using the Mulitply function

    The scaled temperature has changed so the volume (temperature*prerssure) must be recalculated using the Mulitply function

    The volume has changed so the threshold limit must be checked

    If the threshold limit changes the heater output will need to be recalculated

The framework data which drives the engine to produce this only needs to specify things like:

    Function 2 is Multiply, it has as inputs Variable 3 and Variable 4 and produces as output Variable 7

    Function 5 is Threshold, it has as inputs Variable 6 and Variable 7 and produces as output Variable 9

    V3 changes

    F2 depends on V3 so the Mulitply must be called

    V7 is changed by F2

    F5 depends on V7 so the Threshold must be called


    More information on the:

    and for the originators of deltaFSD:


deltaFSD is now a Sourceforge project

  At 06:08:02 06/24/17© Copyright DeDf 2003 - 2010Base: design
File: design.txt
Side: gifs/deltafsdside.gif