Rapid control prototyping applications

Early proof of concept

One of the key benefits of RCP is the ability to prove out a control algorithm early in the design process.

No software coding is necessary – using a model-based design approach, engineers can quickly create the model graphically using Simulink, or state diagram using Stateflow, and build an executable directly from the host PC. In minutes the algorithm can be tested in real hardware.

This is called auto-coding, automatically creating the code that can be compiled, linked, downloaded and executed on real-time hardware simply from a diagrammatic modelling environment.

So what type of hardware is required?

RCP hardware typically comprises a single, small, portable unit that can be run within the same environment as the final intended controller, with sufficient processing capability to run the auto-coded model and with all the I/Os necessary to interface to the system in which testing is to be performed.

How do you know the I/Os are suitable?

Modern RCP systems, such as MICROGen, are built from the ground up to provide a wide range of I/O types with sufficient flexibility and capability to cover a wide range of applications. Technologies such as Genix greatly increase the suitability of the RCP controller by offering more flexibility and configuration of each I/O line, allowing electrical changes to be made all from the control of the modelling environment.

RCP Input dialogue example

RCP Input block example

But what if I need special interfaces?

RCP hardware often has the ability to be expanded using plug-in boards or distributed I/O expansion via a communications bus; such as our intelligent I/O range.

What if I need to test an entire fleet of vehicles?

One of the main benefits of modern RCP controllers is their appropriateness for step and repeat builds. Because the RCP hardware forms part of a standard range, it can be deployed across one or more variants for testing.

Once the model has been compiled and tested, it is straightforward enough to replicate the downloadable code and install a number of RCP units in a fleet for software durability and robustness testing. This increases the chances of more users assessing the proposed control strategy and feeding back to the development team on how suitable it is.

RCP hardware, such as MICROGen, is usually designed for deployment to harsh environments such as in-vehicle use.

How can I control and interrogate the controller strategy?

In a similar fashion to how a C program requires a debugger, RCP applications need the ability to perform debugging too.

Because the model is an abstracted version of the underlying controller code, it makes sense to provide debugging which is abstracted from low level code too.

Typically, RCP interface debugging involves monitoring and controlling the real-time target from a host graphical user interface (GUI) application, using parameters and signals referenced in the controller model.

This supports fine-tuning of control loops, displaying graphs of real-time signals and even selecting different algorithms to attempt comparative test techniques.

One such diagnostic tool is VISUALCONNX for MICROGen.

Example user interface used for test