1. MARTe Framework Middleware for RT Control Development
André Neto*+, F. Sartori,
G. De Tommasi, D. Alves,
R. Vitelli, L. Zabeo,
A. Barbalace, D.F. Valcárcel and
EFDA-JET PPCC contributors
*Instituto de Plasmas e Fusão Nuclear
Instituto Superior Técnico
Lisbon, Portugal
+JET-EFDA
Culham Science Centre, UK
Present mysefl
MARTe is a software C++ multi-platform RT framework. It was developed as a joint collaboration between several European fusion associations, lead by the plasma position and current control operator group of the JET tokamak 1

2. Framework important functions
Provides development and execution environment for control systems
Defines a way of designing/developing
Limits what you can do to what is needed!
Reduces mistakes
Provides standard interfaces to outside world
Facilitates test & commissioning
Ensures and monitors real-time

3. Main ideas Multi-platform C++ middleware Modular
Simulink-like way of describing the problem
Modular
Clear boundary between algorithms, hardware interaction and system configuration
Reusability and maintainability
Simulation
Minimize constraints with the operational environments (portability)
Data driven
Provide live introspection tools
Without sacrificing RT
The main goals were to develop a modular framework that allowed to reuse as much modules as possible.
We wanted to provide a clear distinction between code related to the hardware and algorithms and , wherever possible, to have data driven software. All of this is important only if one the key features is usability and as so we tried to create a set of important query tools.
This without forgetting performance.

4. Multi-platform? Why? How? Possible?
Debug and develop in non RT targets
Eases the debugging process
Usually better developing environment
Debugger
IDE
How?
Provide an abstraction layer/library which solves all the specificities of a given OS
Optimize code here
Possible?
Yes, runs in Linux, Linux+RTAI, VxWorks, Solaris and MS Windows

5. BaseLib2 – support library
The library provides a large amount of functionality which can drastically improve the quality of the code produced, especially in large projects with several developers.
BaseLib2 tries to minimize the usage of pointers and to maximize the use of references The main features are a garbage collector with named objects. String and full data streaming is also very well supported.
Baselib2 objects can be automatically created and configured by the library. This is performed by a parser that knows how to read a specific grammar and by an internal tree based database.
There is also support for mathematical operations, optimized as much as possible to the operating systems but most of the existent code is related to matrix calculations.

6. Data driven components
Define common language
As simple as possible
But complete
Human understandable configuration
Should provide built-in validation
Should provide a clear way of expressing the problem
Components are expected to be parsed only once per configuration request
Avoid unpleasant surprises

7. Object Configuration Structured syntax Similar to XML
+HttpServer = {
Class = HttpService
Port = 8084 }
...
+Control = {
Class = ControlGAM
Controller = {
NoPlasmaVelocityGain = 0.0
NoPlasmaCurrentGain = 40.0
IPWaveform = {
Times = {0 120}
Amplitudes = { }
Rounding = 50
Structured syntax
Similar to XML
Classes are automatically created
Configuration is validated by the created object
Asserting and parsing functions available
Objects are configured using a structure similar to XML
Classes can be automatically created and asserting and parsing functions are available. If something fails during the object creation an error is issued. In the example at the left tree an HTTP browser is created at the port 8084

8. Configuration DB +HttpServer = { Class = HttpService Port = 8084 }
+MARTe = {
Class = MARTeContainer
+RTThread1 = {
Class = RealTimeThread
+Controller = {
NoPlasmaCurrentGain = 40.0
IPWaveform = {
Times = {0 120}
Amplitudes = { }
...
By reading the configuration the library automatically creates an internal database.
By searching on this database a reference to an object can be obtained and used.
Objects have absolute names provided by gluing together all the node names from the object until the root node. All of this again data driven and no code has to be written once the modules are finished.
MARTe.RTThread1.Controller

9. Modularity (GAMs) Define boundaries Algorithms and hardware don't mix!
Modules do only what they advertise
No interdependence or a priori knowledge
Generic by design
Same goals, same module
Reusability and maintainability
Simulation
Replace actuators and plants with models
Keep all the other modules untouched

10. Common GAMs
The most common GAMs that you can find in an application built with MARTe are for hardware interface, where MARTe already provides an high level interface for I/O operations.
Also GAMs for the implementation of algorithms, taking decisions and for saving data are already provided out of the box.
Since the system is completely built independently of the GAMs one can introduce and remove GAMs to perform debug whenever required, without having to change anything.
This is particularly useful for simulation and emulation purposes

11. IOGAM

12. Dynamic Data Buffer GAMs shared data through a memory bus
MARTe guarantees coherency between requested and produced signals
Set of GAMs allow to stream data to different MARTe systems
A GAM must, through configuration, specify what signals it requires and what signals it is going to produce. The framework then checks and guarantees coherency. This can also be performed across networks and different systems.

13. RT-Thread Sequentially executes GAMs
Works as micro-scheduler
Can be allocated to specific CPUs
Keeps accurate information about execution times
Requires an external time and triggering mechanism
Multiple RTThreads can run in parallel
synchronously or asynchronously
The thread can be allocated to one or more processors and several can run in parallel.
It works as a micro-scheduler to execute the application modules. It provides and keeps track of execution times for the overall system and for each of the GAMs.

14. Synchronisation Asynchronous Synchronous Routinely used both schemes
Get latest available value
Verify acceptable latency (sample too late?)
Synchronous
Routinely used both schemes
ADC, time input, ...
Network
From other control loop

15. Synchronisation demo (1)
ETTS waits for trigger from time source
Current time multiple of cycle time?
If so, unlock realtime thread and execute GAMs
ETTS can be configured to exit after timeout
Trigger an error

16. Synchronisation demo (2)

17. Interfacing with MARTe (1)
Why?
Send configurations
Retrieve acquired data
Query status
How?
Message server accepts orders from outside
MARTe is interface agnostic
No predefined GUI
No predefined high level protocols

18. Interfacing with MARTe (2)
Price?
Requires the development of a module which translates your language to MARTe's language
MARTe forwards the messages internally
A message server is provided
HTTP interaction is widely used for retrieving information
Can also be used to change values
GAMs configuration
State machine
...
The components described so far are enough for a MARTe system. Particularly if the system just has to repeat some kind of action without interchanging information with the external world.
When one wants to change the GAMs configuration, for instance, or to query the state of the system or to downlaod signals then MARTe provides a two standardized interfaces.
One is based on a message based protocol as described before while the other is based on HTTP.

19. MARTe Internal State Machine
MARTe has its internal state machine
It can be triggered by
External events
Has its own message interface
Internal events
e.g. errors while executing
Capable of sending messages upon state changing

20. Introspection Automatically built Probe the system
Without sacrificing RT
Crucial for an expedite debugging
Does this still makes sense?
New data streaming concepts, leverage concept?
Stream your probes?
Automatically built

21. MARTe - logger Relay across networks Retrieve history Plug-in based
Another important tool provided by MARTe and BaseLib is an advanced logging mechanism which allow to relay messages across networks and to add new nodes on the fly.
By using Baselib objects the logger messages inherit automatically a lot of information like the name and the address in memory. These are automatically appended to the end of the message.
It was designed to not compromise real-time. This is performed through a producer/consumer scheme, where the consumer only sends the messages when it has some time available and has a a very low priority.
Relay across networks
Retrieve history
Plug-in based
Transparent to producers

22. MARTe World MARTe RTThread 1 Internal state machine GAM 1 DDB GAM 2
GAM N
Driver pool
RTThread N
GAM 1
DDB
External time
triggering services
GAM 2
GAM N

23. MARTe Universe State machine Logger Server HTTP Server MARTe
Any other
Object N
Configuration
provider
Data retrieval
facility

24. Does it work? It is possible! VS Achieved: 50 ± 0.10 ms
Modular
Data driven
Introspection
Reliable
Performance
Low jitter
VS Achieved:
50 ± 0.10 ms
(max jitter of 0.80 ms)
JET VS
JET EFCC
COMPASS SC
COMPASS VS
ISTTOK Tomography
Linux-RTAI
VxWorks
Linux*
50 ms
200 ms
500 ms
100 ms
Working systems

26. What GAMs for the water tank?

27. GAMs for the water tank
Apart from the water tank model all GAMs are generic and can be easily reused
For this presentation we only add to write the code for this GAM
More on development and deployment on this afternoon's talk

28. Future work MARTe is interface agnostic...
Would be good to have standard tools which help on the development and deployment of new systems
Simulink, Ptolemy
EPICS
MARTe has its own language
Would be good to have a meta-language with builtin validation features
XML
More and better documentation
We have quite a lot (thanks to Antonio) focused on the core system logic and the library classes (> 280pp)
Practically none targeted at the end user
Deployment and installation manual, GAM development manual
Configuration file writer manual, Real world examples
Tutorials

29. Backup slides