The standard CLP development method is depicted below. It translates a mathematical model, written in Simulink language into executable code.
The starting point will always be a mathematical model that will specify various forms of processing. With the example of motor control from above, a model for the position control might look like this:
An example of a possible position control algorithm
A Simulink model contains a number of elementary building blocks that describe a particular form of processing to be carried out. The interconnections between the blocks define the flow of processing to be carried out.
Each Simulink building block will have an equivalent on the CLP. The CLP will come together with a library of elementary building blocks that will cover the most common forms of processing that are encountered in the control world (filters, integrators, limiters, transformations,…). The CLP user may create his own building blocks if desired, and the CLP development suite will include a tool for creating building blocks in a structured manner.
The building blocks need first to be validated on the CLP, in order to prove that they are representative of the processing of the model. The development suite contains tools to support this validation activity, and this activity can be highly automated.
When the building blocks behave correctly, the executable can be generated that includes the various building blocks, and it can then be validated on target. The development suite contains tools to support validation at applicative level.
The CLP processor has circuitry on board for the scheduling of SW execution, and for synchronisation with the outside world. The following figure shows how the control algorithm above executes on the processor.
Each part of the control algorithm is triggered by the scheduling circuitry. The position control e.g. reads the actual position from a sensor and compares it to the desired position and then computes a reference speed that is handed over to the speed control. This scheduling assures that SW execution is completely deterministic and is non-interruptible. There is no operating system needed.
For validation purposes, the processor will provide visibility on the executing software and on all hardware resources via a dedicated data reporting unit. This data reporting is transparent for the executing software but the user has full liberty on what he wants to see. Tools will be provided to define the desired data reporting and to capture and manage the data.
The control algorithm above will have to interact with the outside world (e.g. it must read a sensor value from a particular input, set a stimulus on a particular output, read a commanded value from a communication interface). The CLP library will include I/O routines for all interfaces that will hide the hardware details for the user.
There may be applications where there is no need for a mathematical model.
CLP development (C-based)
In those cases, the user may write code in a higher-order language (notably C) that will be compiled into an executable. It is currently under investigation whether the user will be able to include parts of the CLP library in his application. The user will still have the possibility to define his own scheduling and the data reporting desired.