Modeling of MARTe-Based Real-Time Applications With SysML

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 9, NO. 4, NOVEMBER 2013 2407

Modeling of MARTe-Based Real-TimeApplications With SysML

Gianmaria DeTommasi, Senior Member, IEEE, Riccardo Vitelli, Luca Boncagni, and André C. Neto, Member, IEEE

Abstract—Model-driven design is recently gaining a widespreading in different fields, such as design of mechatronics andembedded systems. Approaches based on either UML or SysMLpermit to efficiently manage the design of complex systems indifferent areas. In this paper a SysML modeling approach is pro-posed for the design of real-time applications based on the MARTeframework. TheMARTe framework has been recently adopted forthe development of real-time systems in several European experi-mental fusion reactors. The proposed approach allows to achievea better standardization of the development cycle and a betterdocumentation of the developed systems. Furthermore, by usingmodel-2-text tools it is possible to automatically generate part ofthe real-time executable code and the application configurationfile. The proposed approach has been applied for the modeling ofthe control system for the Frascati Tokamak Upgrade.

Index Terms—Control systems, fusion experiments, model-driven design, real-time software, SysML.

I. INTRODUCTION

M ODELING languages, such as the Unified ModelingLanguage (UML), help the designers to foster the de-

sign and understanding of complex systems.The Systems Modeling Language (SysML, [1]) extends the

UML, intending to unify the various modeling languages usedby systems engineers. In particular, SysML extends the appli-cation of UML to systems which are not purely software based,and can in particular be applied to design heterogeneous sys-tems. SysML also introduces a requirement diagram to structurethe requirements and link these to the system architecture andtest procedures.During the last decade UML and SysML have been used

to promote model-driven development in different fields, suchas manufacturing systems [2], [3], electronic systems [4], em-bedded systems [5]–[7], and automotive [8].In particular, in [2] Thramboulidis extends the UML to

define the Model-Integrated-Mechatronics paradigm. Such

Manuscript received May 15, 2012; revised November 07, 2012; acceptedDecember 07, 2012. Date of publication December 20, 2012; date of currentversion October 14, 2013. Paper no. TII-12-0358.G. De Tommasi is with the CREATE—Dipartimento di Ingegneria Elettrica

e Tecnologie dell’Informazione, Università degli Studi di Napoli Federico II,80125 Napoli, Italy (e-mail: [email protected]).R. Vitelli is with the Dipartimento di Informatica, Sistemi e Produzione, Uni-

versità di Roma, Tor Vergata, 0013 Roma, Italy.L. Boncagni is with the EURATOM-ENEA Fusion Association, Frascati Re-

search Centre, Division of Fusion Physics, Frascati, Italy.A. C. Neto is with the Associação EURATOM/IST, Instituto de Plasmas e

Fusão Nuclear—Laboratório Associado, 1049-001 Lisboa, Portugal.Color versions of one or more of the figures in this paper are available online

at http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/TII.2012.2235073

a paradigm supports the model-driven development of com-plex mechatronic systems, and it has been used to develop asystem platform called Archimedes that permits to automatethe development process of manufacturing systems. A recentextension that uses SysML to model industrial automationcontrol systems is presented in [9], while [6] and [10] also dealswith an application of model-driven engineering to real-timeautomation systems.Furthermore, SysML has been adopted in [3] to formally

specify mechatronics systems; such a description is then used togenerate models to be used for the verification of the automati-cally generated embedded control code. A similar approach toautomatically generate models from a SysML description hasbeen presented also in [11].More recently, the authors of [7] have used UML to propose

model-driven approach for the analysis of the so-called dynam-ically partially reconfigurable systems (DPRS), which are em-bedded system realizedwith an FPGAdevice with the capabilityof being partially reconfigurable. These systems enables moreapplications to be accelerated in hardware, making possible toreduce the overall system execution time.The Multi-threaded Application Real-Time executor

(MARTe, [12]) is a software framework for the develop-ment of real-time code and it represents one of the Europeanproposals for the development of real-time diagnostic andcontrol systems in experimental fusion devices1. MARTe ispresently used to develop real-time systems in several Europeantokamaks such as JET, ISTTOK and COMPASS [14].Tokamaks [15] have been proved to be the most promising ap-

proach to achieve nuclear fusion on Earth by means of magneticconfinement. In nuclear fusion two nuclei of light elements,such as the hydrogen isotope deuterium and tritium, are broughttogether within the range of their strong interactions. As a con-sequence the nuclei join together, forming a lighter particle, withthe consequent release of energy. In order to bring the two nu-clei together, the repelling Coulomb force has to be overcomeover a relatively long distance. Consequently, temperatures ofabout 100 millions degrees are required for fusion reactions. Atsuch high temperatures a gas enters a new state of the mattercalled plasma. There are two different possible approaches tonuclear fusion on Earth: inertial confinement [16] and magneticconfinement [15].The need to achieve increasingly better performance in

present and future tokamak devices has made plasma controlincreasingly important in tokamak engineering (see [17]).

1For the sake of clarity, it should be noticed that the MARTe framework wedeal with in this paper must not be confused with the UML extension for real-time systems called OMG MARTE [13].

1551-3203 © 2012 IEEE

2408 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 9, NO. 4, NOVEMBER 2013

Furthermore, the achievement of the required performanceis strictly dependent on the flexibility and reliability of thereal-time systems that operate the plant during the experiment[18]. In particular, it is crucial to have a real-time architecturethat:• supports and facilitates testing and validation by estab-lishing strict and well defined boundaries between the ap-plication algorithm and the interfaces with other plant sys-tems. This is particularly important in the experimentalcommunity, as the number of interfaces and cross depen-dencies with other plant systems tends to be significantlylarge;

• supports model-based development [17]; a modular archi-tecture together with the availability of reliable models ofthe plant to be controlled allows to validate software com-ponents against plant models, minimizing the risks andcommissioning/debugging efforts when developing com-plex control systems;

• guarantees low latency and low jitter in control cycleduring the execution of the control algorithm, i.e., the soft-ware architecture, together with the deployed hardware,allows to meet hard real-time constraints [19].

MARTe allows the user to fulfill the requirements listedabove. Being multi-platform, MARTe permits the execution ofthe same code on different operating systems, and it providesthe high level interfaces with hardware, external configurationprograms and user interfaces, assuring at the same time hardreal-time performances. Within the MARTe environment, theend users are required to define and implement algorithmsinside a well defined software component named GenericApplication Module (GAM), which is executed by a real-timecyclic executive.Being portable and modular, the MARTe framework permits:• the standardization of the development of real-timeapplications;

• the increasing of the code reusability;• the separation between the user application and the soft-ware required to interface with the plant infrastructure;

• the reduction of the time needed for commissioning.Being multi-platform and separating the algorithmic part of a

real-time application from the plant-interface software, MARTediffers from all the previous software framework that have beenproposed in the nuclear fusion community (see [20]–[24]). In-deed, all the previously proposed approaches are de-facto tightlylinked to the adopted hardware architecture and/or OS. Further-more, the most of these solutions are used only on the deviceswhere they have been developed [20]–[22], [24]. To the best ofthe author’s knowledge, only theMARTe and the DIII-D system[23] have been deployed also on other fusion devices [14], [25].However, while the former is multi-platform and open sourceframework, the latter is a single platform and closed source solu-tion. Furthermore, MARTe is the only framework that has beendeveloped by nuclear fusion experimentalists and has been ex-tended to other application fields, such as real-time control ofwind turbine blade on marine platforms [26].As it will be described in Section II, within theMARTe frame-

work a real-time application is made of a number of basic com-ponents, called GAMs, which are essentially C++ classes. In

order to configure a GAM, its parameters and its input andoutput signals are defined using a configuration language, whichis used also to specify the GAMs execution order once the appli-cation is deployed. Indeed, GAMs are executed by a real-timecyclic executive, according to the specified order, similar towhat is done by a Programmable Logic Controller.GAMs, as algorithmic blocks, declare which data are required

as input, and which one are generated as output. Data is movedon a software bus that guarantees consistency and ensure per-formance by reducing the number of data copies.GAMs configurations is specified in a human readable

format, hence it can be easily stored into text-file, but it can alsobe sent to a GAM via a C++ stream object. Furthermore, beingmulti-platform, a number of makefiles are needed to compilethe real-time application on different targets.It turns out that developing a MARTe-based real-time ap-

plication requires the production of several text files both forGAMs definition, configuration, and compilation.

A. Contribution of the Paper

Although model-driven design is a well-assessed method-ology in industry, it is not commonly used in big physics exper-iments, such as fusion devices. The main reason for that is thatscientists, who have the domain knowledge but are not softwarearchitects or developers, usually take care also of the implemen-tation of complex systems with strict real-time requirements.As a matter of fact, none of the existing real-time frameworksadopted by the fusion community is integrated within a softwaremodeling tool. This paper reports on the first attempt of doingsuch an integration for the MARTe framework.Since MARTe framework guarantees the separation of the

scientific part of a real-time system from the infrastructure soft-ware, the adoption of model-driven design and of model-2-texttools allows to improve system documentation. In order toachieve this goal, we proposed to use SysML to model aMARTe-based systems made up of a number of connectedGAMs. In particular:• by using SysML a better system documentation isachieved;

• internal block diagrams2 are used to specify the in-ternal structure of GAMs; this allows to explicitly showthe distinction between GAM internal parameters andinput/output signals, which enhance the self-documenta-tion of the project;

• interdependency amongGAMs is explicitly represented bymeans of block definition diagram that show the intercon-nections between the various module, also enhancing theoverall project documentation.

Having proposed a model-driven approach to design aMARTe application, is then possible to use model-2-texttools to automatically generate part of the real-time codeand of the configuration data, together with make files forthe compilation on different platforms. To this aim Topcasedhas been adopted as modeling tool, while Acceleo® [27] hasbeen chosen as model-2-text tool. Topcased is an open sourcetoolkit for system/software engineering which complies with

2Internal block diagrams and block definition diagrams are two among all thepossible SysML diagrams that can be used for structural modeling.

DETOMMASI et al.: MODELING OF MARTE-BASED REAL-TIME APPLICATIONS WITH SYSML 2409

the requirements of critical and embedded applications [28],[29]. Acceleo® is an open source code generator tool whichtransforms models into code.For the sake of completeness it should be remarked that

commercial tools such as Sparx Enterprise Architect® [30]and IBM Rational Rhapsody® [31] allow to model systemsby using UML/SysML and to automatically generate targetcode (e.g., code for the MARTe framework) by customizingtheir internal code generators. In particular, compared withTopcased and Acceleo®, they provide powerful user interfacesto perform such a customization (see for example the what yousee is what you get templates in Rhapsody), and integrationwith tools for requirements elicitation such as DOORS®.However, these commercial products are closed source andnot free; moreover they are not commonly adopted in bigphysics experiments. Hence proposing the use of these toolsfor modeling real-time applications based on MARTe wouldhave limited the dissemination of the proposed approach in thefusion community. On the other hand, although less powerfulthan the commercial softwares, Topcased is a mature modelingtool, supported by a group of partners among which thereare important companies such as Airbus, and public researchinstitutions like INRIA and CNRS. It integrates also tools formodeling system requirements and to map them on functionalcomponents. Acceleo® adds to Topcased the capability ofgenerating custom code, providing also an effective debugger.Finally note that an approach similar to the one presented in

this paper can be adopted to integrate modeling capabilities inthe ASDEX Upgrade’s Discharge Control System (DCS, [21]).Indeed, in DCS, similar to what MARTe does, the functionalcomponents are implemented in separated modules (like theGAMs)which are connected via their inputs and outputs signals,and the signals distribution is managed by a separate component(like the MARTe’s Dynamic Data Buffer, see Section II-B).The paper is organized as follows: Section II introduces the

MARTe framework, which has been recently adopted to de-velop real-time systems for several European experimental fu-sion reactors. In Section III the proposed methodology to modelMARTe-based real-time systems with SysML is presented. Abrief description on how to use model transformation tools toautomatically generate part of the real-time code is also givenin this section. An application of the proposed methodology isthen presented in Section IV, where the case study of the controlsystem for the Frascati Tokamak Upgrade (FTU) is considered.Eventually some conclusive remarks are given.

II. THE MARTE FRAMEWORK

The MARTe framework has been used since 2008 to developreal-time application for tokamak devices. Its developmentstarted in 2002 at the JET laboratory, while its first release,which was called JETRT [32], was adopted to develop theeXtreme Shape Controller in 2003 [17].This section first gives a brief introduction of the MARTe

architecture; afterwards the GAM component is presented.Thanks to the GAM component, it has been possible to achievea clear separation between the algorithmic part of a real-timeapplication and the plant-interface software (i.e., hardware

TABLE IGAM ABSTRACT INTERFACE AS DEFINED IN THE BASELIB2

interaction and system configuration), leveraging reusabilityand maintainability.The readers interested on more details on MARTe can refer

to [12].

A. MARTe Architecture: An Overview

MARTe is a C++ multi-platform framework for the devel-opment and deployment of real-time control systems. Its maingoals are to provide a clear boundary between algorithms, hard-ware interaction and system configuration. This functional di-vision also enables control systems simulation and incrementalcommissioning, by replacing some of its components by modelsand synthetic data producers.MARTe is built upon a C/C++ multiplatform real-time li-

brary named BaseLib2. Real-time is guaranteed by the under-lying OS, while BaseLib2 guarantees portability among dif-ferent platforms adding to C++ named objects and garbage col-lection. This library is organized in consecutive layers wherethe lowest level implements the different calls for each of theavailable operating systems (OS). In order to guarantee porta-bility, the remaining layers and the end-user code must use thefunctionalities provided by the library, avoiding OS-dependentcalls. Being multi-platform, MARTe minimizes the constraintswith the operational environments, so that the target applicationcan be easily run on a different operating system. Such a fea-ture allows the development and testing of code in non real-timeenvironments and to proceed to the final deployment on thereal-time target, only when the overall functionality of the con-trol system is asserted. MARTe was already ported and testedon the following operating systems: Wind River VxWorks®,Linux, Linux/RTAI, Solaris®, MS Windows NT® family, andOS/2.

B. The GAMs

The most important component of a MARTe application isthe GAM. A GAM is the core abstraction within the MARTeframework; a MARTe application is built by implementing anumber of GAMs and by specifying their order of execution.Data exchange among GAMs is obtained bymeans of a memorydata bus named Dynamic Data Buffer (DDB).A GAM is a C++ class implementing the abstract interface

reported in Table I.In order to instantiate GAMs within a Real-time Thread, the

BaseLib2 library provides a text-based configuration language.This configuration file is analyzed by a parser that instantiatesthe objects based on the requested classes. Once a GAM is suc-cessfully created, the Initialise() function reported in Table I


Fig. 1. GAMs chain of the JET vertical stabilization system. All the modules shown in this figure are executed for each control cycle by the Real-time Thread.

validates and assigns the configuration parameters against its in-ternal variables. The GAM is also responsible for handling andreporting any errors arising from invalid parameter values.Each GAM can produce and receive data using DDB named

channels. These are requested by the GAM upon configurationand the framework guarantees that all the required sources arepresent on the system. Indeed, during initialization, the modulesdeclare what data they expect to receive and what informationis going to be produced in output. Each type of input or output ischannel declared as a configurable named signal with a data typeassociated. This is the only available way to chain GAMs andprovides a clear boundary in the system: GAMs are not awareof other modules.The interface with the hardware and synchronization is

performed using a special module named IOGAM. It providesa standard hardware interface to MARTe, which expects thereal hardware interaction to be implemented at the driver level(e.g., configuration and data transferring). MARTe supports twotypes of synchronization mechanisms, one based on continuouspolling of a resource and the other as a response to an externalinterrupt. The framework can also have asynchronously, eventbased, triggered elements on the control chain, which collectthe latest data available and verify if the latency is acceptable.When using aMARTe framework, a real-time application (ei-

ther for data acquisition or for control) is built by chaining anumber of GAMs. This chain is then executed by the Real-timeThread component, which acts as a GAMs cyclic executive. Areal-time application can have one or more Real-time Threads,

running at different frequencies and with different priorities.Furthermore, if the underlying hardware and OS support it, dif-ferent threads can run in different CPU sets. These threads canalso be connected and share data between their DDBs, using aspecial IOGAM provided by the framework, where the outputof the thread producing data is connected to an input acquisitionmodule in the thread consuming the signals.Fig. 1 shows the GAMs chain that has been deployed to im-

plement the vertical stabilization control system at JET in 2009.

III. MODELING MARTE COMPONENTS WITH SYSML

SysML is used in this section to model GAMs and chains ofGAMs, that is their interconnections. In particular, the proposedapproach focuses on structural modeling and automatic codegeneration with model-2-text tools. Indeed, the obtained SysMLmodel is then used to automatically generate part of the codeneeded to deploy the modeled components in the MARTe-basedreal-time system. To this aim the use of block definition dia-grams and internal block diagrams is sufficient, as it will beshown in this section.In order to model a MARTe-based application with SysML,

we have first modeled the BaseLib2 components, enablingmodel reusability. Furthermore, a choice has been made abouthow to model the components properties in order to easilygenerate not only the code, but also the configuration files.In this section we introduce the proposed methodology by

means of a simple example. A real-world example will be con-


Fig. 2. Example of GAMs modeling. The block definition diagram reported in this figure is used to define three GAMs and to add to them the HTTP server, whichis implemented by the HttpInterface block.

sidered in Section IV, where the case of the control system foran existing tokamak is presented.

A. Modeling GAMs

Structural modeling of GAMs is achieved by using block def-inition diagrams (BDDs) and internal block diagrams (IBDs).BDDs realize a structural aspect of the model of a system andshow what conceptual “things ” exist in a system, and what re-lationships exist between them. Arguably, BDDs are the mostwidely used diagrams in SysML (similar to class diagrams inUML). IBDs are used to model the internal structure of a blockand can also be used to show how system elements are deployed.By using an IBD an emphasis may be put on the logical relation-ships between elements [1].Since the MARTe framework and the GAM components are

built using BaseLib2 (see Section II-A), this library has beenmodeled in SysML, and its model must be imported in everyGAM model. The BaseLib2 model contains all the commondefinitions (classes, types, etc.) needed to model GAMs; inparticular, it contains the definition of the abstract block GAMwhich specifies the interface reported in Table I. The modelingof BaseLib2 has been done at structural level. To this aimBDDs have been used to model BaseLib2 components andrelationship among them (i.e., inheritance, composition, etc.).With respect to UML class diagrams, BDDs allow the userto make a distinction between block parameters and blockI/O signals; such a distinction is then exploited to model thecomponents that communicate via the DDB (see Section II-B).Once the BaseLib2 model has been imported, the first step to

model GAMs is to define them by using a BDD. An example isshown in Fig. 2, where three GAMs are defined: a simple pro-portional-integral-derivative controller (PID), aWaveformGen-erator that generates the control reference, and a Plant block,

Fig. 3. Topcased hierarchical view of the model of the PID GAM block shownin Fig. 2.

which simulates the plant behavior and can be used to performoffline tuning and validation of the controller (a more completeexample showing how to useMARTe andGAMs for offline con-trol system validation can be found in [33]).The three GAMs reported in Fig. 2 inherits also from the

HttpInterface; this abstract class is included in the BaseLib2library and is used to introspect components members (e.g.,GAMs) from an HTTP server. This server has been designed


Fig. 4. Block definition diagram used to model the connections between GAMs.

to minimize any impact with the real-time activities, by care-fully executing all of its activities in low-priority tasks and, inthe case of multi-core environments, in cores not allocated forthe real-time threading. This scheme enables GAMs to publishrun-time execution information about the internal state of al-gorithms and data. When modeling a GAM it is possible to addinternal parameters (e.g., controller gains for the PID in the pro-posed example) and to extend the interface (e.g., the Gener-ateReference() function for the WaveformGenerator GAM).The definition of the internal parameters can be easily done

by using an IBD, where the internal structure of the PID GAMis modeled. Moreover IBDs are also used to model input andoutput signals of a given GAM. Input and output names shallmatch channel names into the DDB, while the distinction be-tween inputs and outputs allows to clearly identify the producersand consumers of each signal.By using the Topcased modeling tool, it is also easy to add

comments and expression objects to a GAM model, in order toadd comments to GAM parameters and signals, and to specifyinitial values, respectively (see Fig. 3). A part from achieving abetter documentation, this feature is also exploited to add com-ments and initial values to the automatic generated code, as it isdescribed in Section III-C.

B. Chaining GAMs

Once all the GAMs within a project have been modeled asdescribed in the previous section, BDDs can be used also todefine interconnections between GAMs. Such interconnectionimplicitly defines the execution order of the GAMs chain by theReal-time Thread (see Section II).Fig. 4 shows the GAMs chain for the simple example de-

scribed in the previous section. In particular, two additionalGAMs (ADC and DAC) have been added to model the dataacquisition boards of this simple real-time control system. Itshould be also noticed that these additional GAMs are specialones, called IOGAMs, that enable the connection of any hard-ware to the DDB, as long as a MARTe high level driver is de-veloped to provide the connection between the IOGAM and thehardware interface (usually through an operating system lowlevel driver). In Fig. 4 the Plant GAM has not been chained,

since this BDD models the behavior of the real system to be de-ployed, which therefore does not include the plant simulation.

C. Automatic Code Generation

Starting from the SysML model of the MARTe application tobe deployed, which consists of the definition of the GAMs andof the GAMs chain, the Acceleo® tool can be exploited to au-tomatically generate a large part of the whole real-time sourcecode and configuration files. Furthermore, in the proposed ap-proach, Acceleo® is also used to automatically generate themake files for multi-platform compilation.Acceleo® is a code generator tool which transforms models

into code, and it has been designed to improve software devel-opment productivity. Its approach deals with many conceptsgrouped together under the name Model Driven Architecture(MDA), which is obviously coherent with model-driven ap-proach proposed in this work. Although MDA is currentlybeing standardized by the Object Management Group[34],there is a lack of effective and operational tools. Acceleo® iscompatible with XMI 1.x and XMI 2, ensuring compatibilitywith the main SysML/UML modelers on the market. In addi-tion, Acceleo® is independent from the targeted technologyallowing to generate any textual format. Furthermore, it is fullyintegrated into Topcased and, in particular, it is easy to developAcceleo® plug-ins for Topcased.By using the Acceleo plug-in that can be found at [35], the

SysML model is parsed and a folder is created for each blockcorresponding to a GAM. In particular the following files eachGAM:• the C++ source files for the GAM class (a .h and a .cppfile);

• the definition of the data structures, one for the inputs andone for the outputs, used to interface the GAM with theDDB (two .h files)

• additional files for multi-platform compilation (includingmake files);

• the GAM configuration file (a .cfg text file).Furthermore, the MARTe configuration file is also produced,

which exploits the information stored in the BDD used to modelthe GAMs chain in order to extract the GAMs execution order


Fig. 5. Cross section of the FTU Tokamak.

within the Real-time Thread. Exploiting the information aboutGAMs inputs and outputs stored in the IBDs, the informationneeded to populate the DDB and to setup the correct access per-mission to the data (i.e., read, write, or read/write) is added tothis configuration file.

IV. A CASE STUDY: THE CONTROL SYSTEM OF

THE FTU TOKAMAK

As an example of application of the model-driven approachproposed in this paper, we have first modeled the plasma controlsystem of the Frascati Tokamak Upgrade (FTU). Afterwards alarge part of the code for the real-time system has been automat-ically generated via the procedure described in Section III.

A. The Frascati Tokamak Upgrade

The Frascati Tokamak Upgrade is a medium size Tokamak(minor and major radius of the chamber are, respectively, 0.31and 0.935 meters) operating since 1990 at the ENEA laborato-ries of Frascati, in the south of Rome (Italy). FTU is capable ofdischarges of up to 1.5 seconds of length with a toroidal field of8 T.The magnetic field responsible for plasma shaping and cur-

rent drive, is generated by four different amplifiers that feed acoils system that surrounds the tokamak vacuum chamber. Inparticular, two amplifiers, named AL-F and AL-V, are used forthe horizontal position control, while the AL-H amplifier for thevertical one, and AL-T for the plasma current.Fig. 5 shows a cross section of the FTU tokamak toroidal

vessel. The vacuum chamber (shown in Fig. 6 sits in the middleof the figure, while the coils lay around it, named following theamplifier to which they are connected (F, V, H and T).

B. FTU Plasma Control System

The block diagram of the Plasma Control System (PCS) ofFTU is reported in Fig. 7. The blocks in light grey representthe actuators and the plant, the white one is the algorithm whichreconstructs the plasma shape from the magnetic measurements,the oval blocks are the references and the feedforwards for the

Fig. 6. FTU vacuum chamber.

actual control systems, whose main blocks are depicted in darkgrey.The plasma control system is divided in two main parts: the

gas control system, which regulates the density of the plasma;and the plasma current and position control, which is madeby three PIDs (the vertical position feedback, which uses theAL-H amplifier, the horizontal one, which uses the AL-F am-plifier, and the AL-T controller which drives the plasma currentto the requested value). The feedback quantities for AL-F andAL-H (called DEP and DEZ) are the flux errors measured onthe horizontal and vertical axis of the vacuum chamber, and areproportional to the plasma position error. Those quantities areevaluated from the magnetic measurement by the realtime LastClosedMagnetic Surface estimation algorithm, “Plasma Shape”in Fig. 7 (see Tutorial 7 in [36]).The plasma current and position control system is also aug-

mented by three nonlinear controllers: a temperature controllerfor the experimental liquid lithium limiter (currently beingdeveloped), an extremum seeking algorithm for lower hybridpower optimization [37], and an allocator algorithm used tocontrol plasma elongation s[38].

C. FTU New Feedback System

In order to revamp and improve the FTU control systems,it was decided to reimplement it from scratch leveraging theMARTe Framework. To do so the PCS has been “packaged” insmall self-contained pieces which could be wrapped as GAMs.Note that the PCS reported in the figure is a simplified version,as we didn’t report on the safety and scheduling modules whichhad to be produced for a reliable operation of the device. Eachblock in Fig. 7 has been translated in a single GAM. As theAL-F PID has a different behavior than the other ones (moreprecisely it has been upgraded with an antiwindup system inorder to avoid low current oscillations [39]), instead of usingvarious instances of a single and standard PIDGAM, it has beendecided to develop three different PID-based controllers to leaveroom for future improvements.


Fig. 7. Block diagram of the FTU Plasma Control System.

The BDD diagram of the FTU PCS has been then fed to thedeveloped Accelleo plugin in order to generate the boilerplatecode. The vast majority of standard code, as well as a simplemaster configuration file, has been generated, greatly reducingdevelopment time. In particular about 60% of the code has beenautomatically generated, most of which was the one relative tothe initialization and visualization of each GAM’s parameters(i.e., the most error-prone code).

V. CONCLUSIONS

In this paper a model-driven approach is used to model real-time systems in the MARTe environment. By using such an ap-proach a better standardization of the development cycle and abetter documentation of the real-time systems is achieved. Fur-thermore, exploiting open source tools that relies on the SysMLmodeling language, it is possible to automatically generate partof the source code and of the compilation and configuration files.In particular the most of the error-prone source code can be gen-erated by using this tool, giving the possibility to the developersto focus on the scientific part of the real-time code.In order to show the effectiveness of the proposed approach,

the results of the modeling of the control system for the FrascatiTokamak Upgrade have been presented.In fusion community control and diagnostic experts prefer to

have total control on the implementation of the scientific algo-rithms, however in future it will be evaluated to extend the pro-posed modeling approach also to the scientific part of GAMs.Indeed, although implementation details are important in thiscase, the model-driven approach and the automatic code gener-ation are key factors when dealing with quality of the develop-ment process.

REFERENCES

[1] J. Holt and S. Perry, SysML for Systems Engineering. Herts, U.K.:The Institution of Engineering and Technology (IET), 2008.

[2] K. Thramboulidis, “Model-integrated mechatronics—Toward a newparadigm in the development of manufacturing systems,” IEEE Trans.Ind. Informat., vol. 1, no. 1, pp. 54–61, Feb. 2006.

[3] M. Foeken et al., “Model generation for the verification of automat-ically generated mechatronic control software,” in Proc. IEEE/ASMEInt. Conf. Mechat. Emb. Syst. Appl., Oct. 2008, pp. 275–280.

[4] Y. Vanderperren, W. Mueller, and W. Dehaene, “UML for electronicsystems design: A comprehensive overview,” Des. Autom. Embed.Syst., vol. 12, no. 4, pp. 261–292, 2008.

[5] R. Kawahara et al., “Verification of embedded system’s specificationusing collaborative simulation of SysML and simulink models,” inProc. Int. Conf. Model-Based Systems Eng., Mar. 2009, pp. 21–28.

[6] G. Doukas and K. Thramboulidis, “A real-time-Linux-based frame-work for model-driven engineering in control and automation,” IEEETrans. Ind. Electron., vol. 58, no. 3, pp. 914–924, Mar. 2011.

[7] C. Huang and P. Hsiung, “Model-based verification and estimationframework for dynamically partially reconfigurable systems,” IEEETrans. Ind. Informat., vol. 7, no. 2, pp. 287–301, May 2011.

[8] Y. Guo and R. Jones, “A study of approaches for model based devel-opment of an automotive driver information system,” in Proc. 3rd Ann.IEEE Syst. Conf., Mar. 2009, pp. 267–272.

[9] K. Thramboulidis and A. Buda, “ SysML view model forIEC61499 Function Block control systems,” in Proc. 8th Int. Conf.Ind. Informat., Jul. 2010, pp. 175–180.

[10] E. Estevez and M. Marcos, “Model-based validation of industrial con-trol systems,” IEEE Trans. Ind. Informat., vol. 8, no. 2, pp. 302–310,May 2012.

[11] T. Johnson, C. Paredis, J. Jobe, and R. Burkhart, “Modeling continuoussystem dynamics in SysML,” in Proc. ASME Int. Mech. Eng. Congr.Expo., Seattle, WA, USA, Nov. 2007.

[12] A. Neto et al., “MARTe: Amulti-platform real-time framework,” IEEETrans. Nucl. Sci., vol. 57, no. 2, pp. 479–486, Apr. 2010.

[13] The UML Profile for MARTe 2012 [Online]. Available: http://www.omgmarte.org

[14] A. Neto et al., “A survey of recent MARTe based systems,” IEEETrans. Nucl. Sci., vol. 58, no. 2, pp. 1482–1489, Aug. 2011.

[15] J. Freidberg, Plasma Physics and Fusion Energy. Cambridge, U.K.:Cambridge Univ. Press, 2007.


[16] M. K.Matzen et al., “Pulsed-power-driven high energy density physicsand inertial confinement fusion research,” Phys. Plasmas, vol. 12, pp.055503–055503, 2005.

[17] M. Ariola and A. Pironti, Magnetic Control of Tokamak Plasmas.New York, NY, USA: Springer, 2008.

[18] G. De Tommasi et al., “Real-time systems in tokamak devices. A casestudy: The JET tokamak,” IEEE Trans. Nucl. Sci., vol. 58, no. 2, pp.1420–1426, Aug. 2011.

[19] J. Liu, Real Time Systems. Englewood Cliffs, NJ, USA: Prentice-Hall, 2000.

[20] D. Moulin et al., “Real time data acquisition system for control andlong pulse operation in Tore Supra,” IEEE Trans. Nucl. Sci., vol. 45,no. 4, pp. 2033–2038, Aug. 1998.

[21] W. Treutterer et al., “ASDEX Upgrade’s new plasma control scheme,”Fus. Eng. Des., vol. 81, pp. 1927–1931, 2006.

[22] I. Yonekawa et al., “Current status and future prospects of the JT-60Ucontrol system,” Fus. Eng. Des., vol. 71, pp. 11–15, 2004.

[23] D. Humphreys et al., “Integrated plasma control in DIII-D,” Fus. Sci.Tech., vol. 48, no. 2, pp. 1249–1263, Oct. 2005.

[24] M. Cavinato, A. Luchetta, G. Manduchi, and C. Taliercio, “Gen-eral-purpose framework for real time control in nuclear fusionexperiments,” IEEE Trans. Nucl. Sci., vol. 53, no. 3, pp. 1002–1008,Jun. 2006.

[25] Y. Oh et al., “Commissioning and initial operation of KSTAR super-conducting tokamak,” Fus. Eng. Des., vol. 84, no. 2–6, pp. 344–350,Jun. 2009.

[26] Fusion Software Used for Wind Turbines 2011 [Online]. Available:http://www.efda.org/newsletter/fusion-software-used-for-wind-tur-bines/

[27] Acceleo 2012 [Online]. Available: http://www.eclipse.org/acceleo[28] TOPCASED—The Open-Source Toolkit for Critical System 2012

[Online]. Available: http://www.topcased.org[29] N. Pontisso and D. Chemouil, “TOPCASED combining formal

methods with model-driven engineering,” in Proc. 21st IEEE/ACMInt. Conf. Automated Software Eng., Sep. 2006, pp. 359–360.

[30] Enterprise Architect 2012 [Online]. Available: http://www.sparxsys-tems.com/products/ea/index.html

[31] Rational Software 2012 [Online]. Available: http://www-01.ibm.com/software/rational/

[32] G. De Tommasi, F. Piccolo, A. Pironti, and F. Sartori, “A flexible soft-ware for real-time control in nuclear fusion experiments,” Contr. Eng.Pract., vol. 14, no. 11, pp. 1387–1393, Nov. 2006.

[33] T. Bellizio et al., “A MARTe based simulator for the JET Vertical Sta-bilization system,” Fus. Eng. Des., vol. 86, no. 6–8, pp. 1026–1029,Oct. 2011.

[34] Object Management Group 2011 [Online]. Available: http://www.omg.org

[35] G. De Tommasi and R. Vitelli, Modeling GAMs With SysML 2011[Online]. Available: http://wpage.unina.it/detommas/MARTe.html

[36] A. Beghi and A. Cenedese, “Advances in real-time plasma boundaryreconstruction,” IEEE Contr. Syst. Mag., vol. 25, no. 5, pp. 44–64, Oct.2005.

[37] D. Carnevale et al., “A new extremum seeking technique and its appli-cation to maximize RF heating on FTU,” Fus. Eng. Des., vol. 84, no.2–6, pp. 554–558, Jun. 2009.

[38] L. Boncagni et al., “Plasma position and elongation regulation at FTUusing dynamic input allocation,” IEEE Trans. Contr. Syst., vol. 20, no.3, pp. 641–651, May 2011.

[39] L. Zaccarian et al., “Nonlinear instabilities induced by the F coil poweramplifier at FTU: Modeling and control,” Fus. Eng. Des., vol. 84, no.7–11, pp. 2015–2019, Jun. 2009.

Gianmaria De Tommasi (SM’11) was born inMilan, Italy, in 1975. He received the Laurea degree(summa cum laude) in electronic engineering fromthe University of Naples Federico II, Naples, Italy,in 2001.Since 2002 he is with Department of Computer and

Systems engineering of the University of Naples Fed-erico II, where he received the Research Doctoratedegree in Computer and Automatic Engineering in2005, and where he is currently Assistant Professor.Since 2002 he has been visiting researcher at the JET

tokamak (UK), where he has participated to various projects connected to theJET plasma current and shape control system. Recently he has been ProjectLeader of an international project at JET named Current Limit Avoidance Im-plementation (2010–11), aimed at developing and implementing an intelligentcontrol system to avoid to reach the current limits during tokamak operations.His current research interests include control of nuclear fusion devices, fault de-tection for discrete event systems, identification of discrete event systems mod-eled with Petri nets, and stability of hybrid systems. He has published more than100 journal and conference papers on these topics.Dr. De Tommasi is a member of the IEEEControl System Society Conference

Editorial Board.

RiccardoVitelliwas born in Rome, Italy, in 1983. Hereceived the Ph.D. degree in control engineering fromthe University of Rome Tor Vergata, Rome, Italy, in2012.From 2007 to 2009, he was with the Plasma Posi-

tion and Current Control Department, JET Tokamak,U.K., where he participated in the implementation ofthe real-time controller frameworkMARTe and in thePlasma Control Upgrade project. Currently he is col-laborating with the CODAC group of Fusion For En-ergy as a consultant in fusion engineering. His main

research interests include nonlinear control systems for nuclear fusion experi-ments and real-time operating systems.

Luca Boncagni received the M.E. degree in com-puter engineering from the Department of ComputerScience, Systems and Production, Faculty of Engi-neering, University of Rome “Tor Vergata,” Rome,Italy, in 2004.He is currently Researcher with the FTU team and

a Staff Member of the EURATOM–ENEA FusionAssociation, Division of Fusion Physics, FrascatiResearch Center, Frascati, Italy.

André C. Neto (M’10) received the B.S., M.S., andPh.D. degrees in physics engineering from the Tech-nical University of Lisbon, Lisbon, Portugal, in 2003,2006 and 2011, respectively. His Ph.D. thesis con-cerned the real-time control infrastructure of the JETvertical stabilisation system andwas awarded in 2009with the 1st prize of IEEE Nuclear and Plasma Sci-ences Society Outstanding Student Awards, with thework: “MARTe: a Multi-platform Real-time Frame-work”.Since 2003, he has been with Instituto de Plasmas

e Fusão Nuclear (IPFN), where he currently works as a Researcher, having asmain duties the design and development of distributed control and data acquisi-tion software and the installation and consultancy for data acquisition softwarein tokamaks. In 2008, he started working as an IPFN secondee, in the PlasmaOperations Group of the JET tokamak, U.K., where he has participated in thevertical stabilisation upgrade project. Recently he was responsible for the designand development of the required modifications to the plasma position and shapecontroller system, towards the operation with the new ITER-like berylliumwall.Since 2012 he has been working as an external engineering consultant at FusionFor Energy in the field of plasma diagnostics instrumentation and control. Hehas published more than 50 journal and conference papers. His current researchinterests include real-time operating systems and software, networks plasma op-erations and control of nuclear fusion devices.

Modeling of MARTe-Based Real-Time Applications With SysML

Documents

Transcript of Modeling of MARTe-Based Real-Time Applications With SysML