design of an embedded control systems laboratory experiment

Copyright (c) 2009 IEEE. Personal use is permitted. For any other purposes, Permission must be obtained from the IEEE by emailing [email protected].

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.

1

Design of an Embedded Control SystemsLaboratory Experiment

Pau Martı, Member, IEEE,Manel Velasco, Josep M. Fuertes,Member, IEEE,Antonio Camacho,and Giogio ButtazzoSenior Member, IEEE

Abstract—This paper presents a prototype laboratory exper-iment to be integrated in the education of embedded controlsystems engineers. The experiment, a real-time control of adynamical system, is designed to drive students to a deeperunderstanding and integration of the diverse theoretical con-cepts that often come from different disciplines such as real-time systems and control systems. Rather than proposing theexperiment for a particular course within an embedded systemsengineering curriculum, the paper describes how the experimentcan be tailored to the needs and diverse background of bothundergraduate and graduate students education.

Index Terms—Embedded systems education, real-time systems,control systems, laboratory experiment.

I. I NTRODUCTION

T HE economic importance of embedded systems hasgrown exponentially as electronic components are in

everyday use devices. Hence, embedded systems education isa strategic asset, and university curricula are being adaptedaccordingly to cover this domain [1]. Embedded systemscourses are being integrated into existing science and engi-neering curricula [2], [3], but also specific curricula havebeendeveloped to integrate the broad set of concepts into a coursesequence [4]–[7]. In addition, modern teaching practices,suchas problem based learning [8], international project collabora-tion [9], cooperative learning [10], on-line competitions[11],educational games [12], or remote laboratories [13], have alsobeen applied to the embedded system education. To providestudents with in-depth understanding across all the areas anddisciplines involved in embedded systems is a difficult task.Hence, laboratory activities are crucial to consolidate thediverse theoretical material [14].

Since many embedded systems are control systems [15],and considering that there is an increasing trend to adopt real-time technology for the embedded computing platform [16],laboratory experiments including topics of real-time and con-trol systems are becoming more and more important for the

Manuscript received March 10, 2009; revised June 15, 2009; accepted forpublication December 23, 2009. This work was partially supported by NoEArtistDesign IST-FP7-2008-214373, and by Spanish Ministerio de Educaciony Ciencia Project ref. CICYT DPI2007-61527.

Copyright c© 2009 IEEE. Personal use of this material is permitted.However, permission to use this material for any other purposes must beobtained from the IEEE by sending a request to [email protected].

P. Martı, M. Velasco, Josep M. Fuertes and Antonio Camacho are withthe Automatic Control Department, Technical University of Catalonia, PauGargallo 5, 08028 Barcelona, Spain. E-mail:pau.marti, manel.velasco,josep.m.fuertes, [email protected]

G. Buttazzo is with The Computer Engineering Department, Scuola Supe-riore Sant’Anna of Pisa, RETIS Lab, Area CNR Via Moruzzi, 1, 56124 Pisa,Italy. E-mail:[email protected]

education of embedded systems engineers. The traditionalteaching approach to real-time systems and to control systemscourses can be quite math-intensive and abstract, thus failingto introduce students to the realities of embedded controlsystem implementation. Moreover, the natural interactionandintegration between these two disciplines is often neglecteddue to the traditional compartmentalized nature of scienceand engineering education. Since control systems are real-time systems, control engineers must have an understandingof computers and real-time systems, while computer engineersmust understand control theory.

To overcome such limitations, this paper presents a labora-tory experiment to be integrated in the education of embeddedcontrol systems engineers that flexibly combines two main dis-ciplines: real-time systems and control systems. The flexibilityis achieved by describing a set of problems/observations thatprovide the spectrum of possible choices that instructors/stu-dents have and the work that has to be done to complete theexperiment. This permits elaborating diverse assignmentsforthe laboratory experiment with open problems rather than pro-viding tight guidelines, while providing the tools for assessingwhether the students design and implementation choices werecorrect. Finally, through the experiment, it is shown that thecombination of both disciplines do not rise conflicts. It ratherprovides complementary approaches/views that help in themultidisciplinary learning process required in the embeddedsystems education.

The experiment main activity includes the implementationof a real-time control application, consisting in controllinga physical plant by a controller implemented as a softwaretask executing on top of a real-time operating system (RTOS).Rather than proposing an experiment for a particular coursewithin an embedded systems engineering curriculum, the paperdescribes how the experiment can be tailored to the needsof both undergraduate and graduate students education, andto the diverse background of the target audience. A tentativelaboratory program covering the different stages requiredtocarry out the experiment is presented, and its integration intoa master-level students course is also reported.

The rest of the paper is organized as follows. Section IIsets the objectives, competence and learning outcomes for thedesigned experiment. Section III discusses the selection of thecontrolled plant and processing platform/RTOS. Section IVintroduces the set of problems/observations for carrying outthe activity. Section V presents an outline of the experimentand its adaptation to a course. Section VI concludes the paper.

Authorized licensed use limited to: UNIVERSITA PISA S ANNA. Downloaded on June 17,2010 at 09:41:35 UTC from IEEE Xplore. Restrictions apply.

IEEE Transactions on Industrial Electronics, Vol. 57, No. 10, October 2010.

giorgio

Rettangolo



2

TABLE IREQUIRED SKILLS

1 Understanding embedded control systems, their importance,limitations, restrictions, and application areas

2 Analysis and synthesis capabilities3 Explanation capability for efficient oral and written communication4 Capability of integrating autonomous learning with team work5 Capability of analyzing and assessing the economical, social and

environmental impact of the solutions

TABLE IILEARNING OUTCOMES

1 Identify embedded systems features2 Identify components, concepts and design methodologies3 Interpret data-sheets, documentation and specifications4 Design, build and troubleshoot an embedded control system5 Practice on modelling, analysis and design of control systems6 Practice on real-time programming and operating systems7 Evaluate system performance

II. OBJECTIVES, COMPETENCE AND LEARNING OUTCOMES

The experiment objectives are twofold. First, the positivebenefits of experimental learning are well known in educationand professional activities. Students confidence and enthusi-asm in experiments grow as they practice in problem solving,team work, design skills, etc. Second, and more specifically,experiments should educate students in embedded controlsystems, providing additional knowledge they cannot acquirefrom theory.

Looking at the ECTS (European Credit Transfer System),program objectives are preferably specified in terms of thelearning outcomes and competence to be acquired. Althoughthe proposed experiment is not tailored to a specific program,nor to any specific level of study (undergraduate, graduate),the main skills to be acquired by students are listed in TableI.Skills 1-2 relate to technical aspects and theoretical knowledgeon embedded control systems, skills 3-4 relate to practicalissues and experimental learning, whereas skill 5 refers tosustainability issues. The multidisciplinary nature of embeddedsystems requires more background and transversal knowledgein different fields, combined with the capability of integratingdifferent skills for a system wide objective. The learningoutcomes are more specific because they state what is expectedfrom a student as a result of the learning process.

The learning outcomes are listed in Table II. The firstthree outcomes are related to understanding embedded controlsystems, from a technical point of view, taking into accountthe multidisciplinary nature of the field. In this process, it isalso crucial for students to be able to read, understand, anduseexisting documentation, like data-sheets, application program-ming interface (API) reference manuals, etc. Outcomes 4 to 6are related to implementation issues, which are essential forreproducing an experiment. Finally, the evaluation of systemperformance is crucial to assess if the specifications are met.

The required background for students to carry out theexperiments is a basic knowledge on control systems theoryand real-time programming using an operating system.

III. SELECTION OF THE CONTROLLED PLANT AND

PROCESSING PLATFORM

The controlled plant and processing platform (hardware andreal-time operating system) have been carefully selected tohave a friendly, flexible, and powerful experimental set-up.Both must be simple to avoid discouraging those students withstrong control systems background but weak real-time systemsbackground when facing the programming part, or vice-versa,to avoid discouraging those students with strong real-timesystems background but weak control systems backgroundwhen facing the controller design stage.

A. Plant

Many standard basic and advanced controller design meth-ods rely on the accuracy of the plant mathematical model. Themore accurate the model, the more realistic the simulations,and the better the observation of the effects of the controller onthe plant. Hence, the plant was selected among those for whichan accurate mathematical model could easily be derived.

Plants such as an inverted pendulum or a direct currentmotor are the defacto plants for benchmark problems incontrol engineering [17]. However, their modelling is nottrivial and the resulting model is often not accurate. Thisleads to a first controller design that has to be adjusted by”engineering experience”, thus requiring knowledge that isdifficult to formalize and transmit to the students. To avoidsuch a kind of drawbacks, a simple electronic circuit in theform of anRCRC (Figure 1a) was selected. The simplicity ofits components and their simple and intuitive physical behaviorhave been the main reasons for its selection. Note however thatexperiments using other plants can be complementary to theapproach presented here, e.g. [15], [18]–[20]. Indeed, Lim[19]also proposes electronic circuits. However, they are slightlymore sophisticated because they include operational ampli-fiers. Although richer dynamics can be achieved, the intuitivebehavior and thus the modeling of operational amplifiers isnot straightforward.

The selection of an electronic circuit as a plant has alsoanother important advantage: depending on the specific circuit,it can be directly plugged into a micro-controller without usingintermediate electronic components, as shown in Figure 1b,where thezohbox (zero order hold) represents the actuator andthe box above represents the sampler. That is, the transistor-transistor logic (TTL) level signals provided by the micro-controller can be enough to carry out the control. Notethat this is not the case, for example, for many mechanicalsystems. Such a simplification in terms of hardware reducesthe modelling effort to study the plant and no models foractuators or sensors are required. Additional benefits of thesetypes of plants are that systems can be easily built, are cheap,have light weight, and can be easily transported and powered.

The control objective would be to have the circuit outputvoltageVout (controlled variable) to track a reference signal orto settle to a constant value while meeting for example giventransient response specifications, which mandates to use track-ing structures. The control will be achieved by samplingVout,executing the control algorithm and applying the calculated



giorgio

Rettangolo



3

(a) RCRC circuit

(b) Control setup

Fig. 1. Plant and control setup.

control signal to the circuit via varying the circuit input voltageVin (manipulated variable). Disturbances can be injected by avariable load voltage placed in parallel to the output voltage.

B. Processing platform

The processing platform consists of the hardware platformand the real-time operating system. As hardware platform,a micro-controller based architecture was selected becauseembedded systems are typically implemented using this typeof hardware. Note, however, that too small micro-controllersmay not be powerful enough for running an RTOS, as dis-cussed in [22]. Among the several possibilities available onthe market [23], it was decided to adopt the Flex board [24].

The Flex board (in its full version) represents a good com-promise between cost, processing power, and programmingflexibility. It was produced as a development board for buildingand testing real-time applications using standard componentsand open source software. The board includes a MicrochipdsPIC DSC micro-controller dsPIC33FJ256MC710, a socketfor the 100 pin Plug-In Module (PIM), an ICD2 (in-circuit de-bugger) programmer connector, a USB (Universal Serial Bus)connector for direct programming, power supply connectors,a set of leds for monitoring the board, an on-board MicrochipPIC18F2550 micro-controller for integrated programming,anda set of connectors for daughter boards piggybacking.

The board has several key benefits that make it suitable tobe used for educational purposes. First has a robust electronicdesign, which is an important feature when it is employedby non skilled users. Second, it has a modular architecture,which allows users to easily develop home-made daughterboards using standards components. A set of daughter boardscan be added to the Flex board for easy development, suchas a multi-bus board equipped with CAN (Controller AreaNetwork), Ethernet, I2C (Inter-Integrated Circuit), and othercommunication protocols. On one hand, the availability ofCAN or Ethernet permits to build and experiment with net-worked control applications. On the other hand, the availablenetworks can be used for debugging purposes or for extracting

data from the board, which is a difficult task when dealing withembedded systems.

As far as the real-time kernel is concerned, different pos-sibilities were considered. First, many well-known real-timeoperating systems, such as real-time Linux [25], target proces-sors that may be too powerful for embedded applications. Butmore important, their internal structure is often too complexfor those students with a low profile in (real-time) operatingsystems. Hence, it looks more desirable to work with smallreal-time kernels (see e.g. [26]–[31] for small real-time kernelstargeting small architectures) whose internals are accessible,easy to understand and modify, in order to tailor them to thespecific application needs. On the other hand, from a userpoint of view, programming and configuring the kernel (in-cluding creating tasks, assigning priorities/periods/deadlines,and setting the scheduling policy) should be friendly enoughto attract non-skilled programmers.

From the considerations mentioned above, Erika Enterprisereal-time kernel [24] was selected. Erika provides full supportto the Flex board in terms of drivers, libraries, programmingfacilities, and sample applications. The kernel, available underthe General Public License and OSEK (Open Systems andtheir Interfaces for the Electronics in Motor Vehicles, [32])compliant, is a RTOS for small micro-controllers based on anAPI similar to those proposed by the OSEK consortium. Thekernel gives support for preemptive and non-preemptive mul-titasking, and implements several scheduling algorithms [33].The API provides support for tasks, events, alarms, resources,application modes, semaphores, and error handling. All thesefeatures permits to enforce real-time constraints to applicationtasks to show students the effects of sampling periods, delaysand jitter on control performance.

The development environment for Erika Enterprise is basedon cross-compilation, avoiding typical students misconcep-tions when the development platform and the target sharethe same hardware. A tool, named RT-Druid [24] (based onEclipse [34]), can be used as a default development platformto program in C, with support from Microchip for the com-piler and for the programming development kit. The latteris important because Microchip web-pages [35] are always agood place where to share experiments experiences and code:a good place for instructors and students to visit. RT-Druidim-plements an OIL (OSEK Implementation Language) languagecompiler, which is able to generate the kernel configurationfrom an OIL specification. Apart from programming in C, theFlex board can also be programmed automatically using theScilab/Scicos [36] code generator (similar to what can be donewith MATLAB/Simulink [37] and its Real-Time Workshop, asused for example in [38] for rapid control prototyping). Thisis an important benefit for non-skilled C programmers.

From an education point of view, it is also important to notethat there is the possibility to build a community around thisprocessing platform to create a repository of control softwarefor education. In fact, a set ofapplication notesthat describe aset of control experiments (inverted pendulum, ball and plate,etc.) developed with Erika on Flex can be found in [24].

Finally, it must be stressed that the price of the Flex boardlies in the lower bound of evaluation board prices, and that



giorgio

Rettangolo



4

the Erika kernel and the associated development tools areopen source, available for free, or available for free in studentedition format. Hence, it is an economically atractive option.

IV. EXAMPLE OF THE LAB EXPERIMENT

This section presents some of the activities in the form ofproblems and solutions (and observations) required to carryout the lab experience, which are later ordered in the workplan. The emphasis is in the control analysis and design part.

A. Problem 1. Plant modelling

If qi represents the charge on capacitorCi, the differentialequations of the circuit, in terms of the currentsqi at eachRi,are given by

q1R1 + (q1 − q2)1

C1

= Vin

q2R2 + (q2 − q1)1

C1

+ q2

1

C2

= 0 (1)

q2

1

C2

= Vout,

For example, using state-space formalism, a state-spaceform is given by

x(t) =

[

0 1−1

R1R2C1C2

−R1C1+R2C2+R1C2

R1R2C1C2

]

x(t)

+

[

01

R1R2C1C2

]

u(t)

y(t) =[

1 0]

x(t)

(2)

whereu(t) is the control signal,y(t) is the plant output, andx(t) = [ x1 x2 ] is the state vector, wherex1 correspondsto the output voltageVout, andx2 is q2/C2.

Observation 1:The modelling of the plant could have beenalso done in terms of a transfer function (see [39] for theanalysis). Even obtaining the differential equations is a goodexercise. Adopting the state space formalism may add anotherbenefit if using model (2). Since only the output voltagex1 canbe physically measured, the control algorithm requires theuseof observers for predictingx2. This opens the door to experi-ment with several types of observers and the implementationof the controller has to include them. Also, the selection ofthestate variables is arbitrary, and therefore, students haveto takedesign decisions. For example, the voltages in both capacitorscould also have been chosen as a state variables. In any case,if possible, it is interesting to chose the state variables in sucha way that the controlled variable is directly available throughthe output matrix in order to minimize computations in themicro-controller.

B. Problem 2. Electronic components

The selection of the electronic components is very impor-tant for several reasons. The output impedance must be lowenough to properly connect the circuit to the analog-to-digitalconverter (ADC) or to some external instrumentation, suchas an oscilloscope. For example, given the initial componentsR1 = R2 = 1 KΩ andC1 = C2 = 33 µF, a manageable circuit

0 0.5 1 1.5 20

0.5

1

1.5

2

2.5

3

3.5

(a) Open loop response

0 0.5 1 1.5 20

0.5

1

1.5

2

2.5

3

3.5

(b) Faster closed loop response

0 0.5 1 1.5 20

0.5

1

1.5

2

2.5

3

3.5

(c) Overshoot closed loop response

Fig. 2. Simulated RCRC responses.

impedance is obtained. With these components, the state spacemodel becomes

x(t) =

[

0 1−976.56 −93.75

]

x(t) +

[

0976.56

]

u(t)

y(t) =[

1 0]

x(t).(3)

Observation 2:Students can be given other values. Forexample, withR1 = R2 = 330 KΩ and C1 = C2 = 100ηF, it is easy to see that the equivalent output impedance istoo high for the ADC. To derive such a conclusion, studentshave to consult the dsPIC data sheet.

C. Problem 3. Open loop simulation

Open loop dynamics can be observed by injecting referencesignals to the circuit via its inputVin. For example, byinjecting a square wave that oscillates between1 V and2.5 Vat 1Hz, the obtained dynamics are illustrated in Figure 2a. Thevoltage outputVout (solid curve) slowly tracks the reference(dashed curve).

Observation 3:The electronic components determine thecircuit open loop dynamics. Students must be aware of thisby playing with different electronic components. In addition,simulation can be done by standard software packages used incontrol engineering (e.g., MATLAB/Simulink, Scilab/Scicos)



giorgio

Rettangolo



5

or by programming the response in C or even using anspreadsheet application.

D. Problem 4. Controller design: sampling period and per-formance specifications

For the chosen plant, there can be different control goals. Apossibility can be to modify theRCRC transient response byaccelerating it, or by arbitrarily achieving a given overshoot.In any case, the selection of the sampling period and thecontroller itself have a strong impact on control performance.Also, they have to be selected and designed taking into accountthe processing platform. If avoiding intermediate electronicsbetween plant and dsPIC is the assumption, the control signal(Vin) can be generated using the Pulse Width Modulation(PWM) (by adjusting the duty cycle) and the controlledvariable (Vout) can be obtained through the ADC. Therefore,the reference, the sampling period, and the controller mustbechosen/designed so that the voltage levels of the control signaland generated peak current levels lie within the hardwarelimitations.

Given the previous square reference signal, through aniterative design stage, and according to standard rules ofthumb, two state feedback controllers can be designed, one thataccelerates the response, namedfast controller, and anotherthat produces overshoot, namedovershootcontroller. For thefast controller, the period is set toh = 0.01 s, and thediscrete state feedback controller is designed to place thecontinuous closed loop poles atp1,2 = −30 (note that the openloop system has poles at−12 and−81, approximately). Theovershoot controller has a sampling period ofh = 0.1 s, andthe controller places the closed-loop poles atp1,2 = −10±20i.

It is worth noting that, using only standard rules of thumbfor selecting sampling periods [39], both controllers shouldhave a slightly shorter sampling period. Thefast controllershould be given a period ofh = 0.007 s and theovershootcontroller a period ofh = 0.03 s. However, since longer sam-pling periods result in lower controller resource demands,aniterative simulation process was used to find longer samplingperiods for both controllers without introducing unacceptableperformance degradation.

Observation 4:Selecting sampling periods, desired closedloop poles, or even having a higher amplitude for the referencesignal may cause the values of the control signal to be outof range. Relations illustrating trade offs in the design ofembedded control systems can also be taught to the students,such as showing that increasing sampling rates means strongercontrol signals (saturation problem) but also more processorusage (feasibility/schedulability problem).

E. Problem 5. Controller design: tracking

The controller design has to consider that the goal is to tracka voltage. The standard tracking structure [39], that includesNu as the matrix for the feed-forward signal to eliminatesteady-state errors andNx as the matrix that transforms thereferencer into a reference state, can be adopted. Followingthe case study,Nu = [1] andNx = [1 0], and discrete gains

CPU mySystem OS myOs EE_OPT = "DEBUG";CPU_DATA = PIC30 APP_SRC = "code.c";MULTI_STACK = FALSE;

ICD2 = TRUE;;MCU_DATA = PIC30 MODEL = PIC33FJ256MC710;;BOARD_DATA = EE_FLEX USELEDS = TRUE;;KERNEL_TYPE = EDF NESTED_IRQ = TRUE;TICK_TIME = "25ns";;;TASK myTask REL_DEADLINE = "10ms";PRIORITY = 1;STACK = SHARED;SCHEDULE = FULL;;COUNTER myCounter;ALARM myAlarm COUNTER = "myCounter";ACTION = ACTIVATETASK TASK = "myTask";;;

;

Fig. 3. Kernel configuration file

areK = [0.0685 −0.0249] or K = [1.0691 −0.0189] forthe fast or overshoot controller.

Observation 5:Students can practice other tracking struc-tures, such as integral control, and can study whether the codeof the controller would suffer significant changes.

F. Problem 6. Controller design: closed loop simulation

The simulated closed loop response for the fast and over-shoot controllers is shown in Figure 2 b) and c), respectively.

Observation 6:As before, simulations can be done usingdifferent methods.

G. Problem 7. Controller design: observers

For the simulation, the two state variables are available.However, in the real experiment, an observer must be included.For simplicity in coding the control task, a reduced observercan been chosen for observing the second state variablex2. Forexample, the observer discrete gain isKr = −37.81 or Kr =−13.42 for the fast and overshoot controller if the observercontinuous closed loop pole are located atpob = −50.

Observation 7:Students can design and evaluate by sim-ulation different types of observers (reduced, complete, etc.)with different dynamics. That is, they can also evaluate theeffect of different locations for the observer poles. Froman implementation point of view, students can also assessthe effect that splitting the control algorithm into two parts(calculate control signal and update state) has on input-outputdelays and schedulability [41].

H. Problem 8. Implementation: kernel configuration and con-trol algorithm

The first implementation involves coding the controller ina periodic task that will execute in isolation on top of Erika.The main pseudo-codes are illustrated in Figures 3, 4 and 5.

Figure 3 is theconf.oil file that specifies the kernel con-figuration with EDF (Earliest Deadline First, [40]) schedulingalgorithm and a periodic task that will be used to implement,for instance, the fast controller. The basics of the main codeare illustrated in Figure 4. First, the timer T1 is initialized and,together withSetRelAlarm, will produce the periodic activation



giorgio

Rettangolo



6

int main(void)T1_program();EE_time_init(); // EDF initializationADC_init(); // ADC1 configurationPWM_config(); // PWM1 configurationSetRelAlarm(myAlarm, 1, 10);for (;;) // reference signal // generation

Delay(100000);reference = 2.5;Delay(100000);reference = 1;

return 0;

Fig. 4. Main code

TASK(myTask)

x_1 = read_adc()r = reference;x_2 = observer(Kr,x1,r,x_1old,x_2old);u = r*NU + K_1*(r*NX_1 - x_1) + k_2*(r*NX_2 - x_2);write_pwm(u);x_1old = x_1;x_2old = x_2;

Fig. 5. Control task code

of the control task every10 ms (the processor speed wasconfigured at40 MIPS - Million Instructions Per Second).Figure 5 shows the control task code including the observerand the tracking structure.

Observation 8:Carrying out the kernel configuration andprogramming the controller could be taught following anordered sequence of steps, such as: 1) introduction to kernelconfiguration, 2) introduction to periodic tasks, 3) introductionto input/output operations (PWM, ADC).

I. Problem 9. Implementation: setup and monitoring details

Figure 6a shows the experimental setup that includes anoscilloscope (for displaying the circuit output voltage) toshow the open loop response (Figure 6b) and the closed loopresponses (Figures 7a and b) achieved by each controllerexecuting in isolation. The oscilloscope screen-shots confirmthat the implementation achieves the control goal: the systemoutput performs the desired fast tracking or achieves thespecified overshoot.

Observation 9:An oscilloscope has been used to monitorboth the responses. It can also be of interest to monitor whetherthe control task executes when specified. Another option couldbe to use the Multibus board to send the data of interest viaEthernet or any other available communication protocol. Thiswould pose interesting challenges in terms of the real-timesystem such as non-invasive debugging.

J. Problem 10. Multitasking: simulation

A second implementation is introduced to illustrate moreadvanced concepts. In the previous implementation a controltask was executing in isolation. However, in many high-tech systems, the processor is used not only for the control

(a) Setup

(b) Open loop response

Fig. 6. Experiment setup and monitoring.

(a) Fast closed loop response

(b) Overshoot closed loop response

Fig. 7. RCRC responses.

computation, but also for interrupt handling, error manage-ment, monitoring, etc. And it is known that in a multitaskingreal-time control systems, jitters, i.e. timing interferences oncontrol tasks due to the concurrent execution of other tasks,deteriorate control loops performance [41]. The objectiveofthis implementation is to observe these degrading effects andimplement corrective actions, e.g. [42]–[44].

A starting point is to inject a new task in the kernel foreach control task. The new task, named noisy task, when to



giorgio

Rettangolo



7

0 0.5 1 1.50.5

1

1.5

2

2.5

3

(a) Partial schedule

0 0.5 1 1.5 20

0.5

1

1.5

2

2.5

3

3.5

(b) Faster multitasking closed loop response

0 0.5 1 1.5 20

0.5

1

1.5

2

2.5

3

3.5

(c) Overshoot multitasking closed loop re-sponse

Fig. 8. Simulated multitasking RCRC responses and schedule.

be executed together with the fast controller, is given a period(and relative deadline) of11 ms, and it is imposed anartificialexecution time of9 ms. The noisy task that goes together withthe overshoot controller has a period and relative deadlineof110 ms with90 ms of execution time. The simulation of eachmultitasking system was done in the TrueTime simulator [45].Putting together each control task with the corresponding noisytask under EDF results in timing variability (jitter) for thecontrol task, as illustrated for the first multitasking system inthe schedule of Figure 8a. In this figure, the bottom curverepresents the execution of the fast controller task, whereasthe top curve represents the execution of the noisy task. Ineach graph, the low-level line denotes no-execution (that is,intervals in which the processor is idle), the middle level linedenotes a task ready to execute (i.e., waiting in the readyqueue), whereas the high-level line denotes a task in execution.Note that the control task has a measured execution time of0.12 ms, which is much less than the noisy task.

Looking at the plant responses in Figures 8 b) and c), it canbe appreciated that the fast controller does not exhibit a controlperformance degradation, while the overshoot controller suf-fers some degradation: overshoots are bigger, square amplitudediffers, transient response varies, etc. This fact indicates thatthe current control design for the fast controller is robustagainst jitters induced by scheduling, while the second oneis more fragile.

Observation 10:Adopting an iterative simulation study,students can learn which parameters play an important role

(a) Partial schedule

(b) Faster multitasking response

(c) Overshoot multitasking response

Fig. 9. Implemented multitasking RCRC responses and schedule.

when jitters appear. Are shorter sampling periods, or non-overshootted responses, a guarantee for having robust controldesigns? Which role do deadlines play in reducing jitters? Forfurther questions and solutions, see [46] and references therein.

K. Problem 11. Multitasking: implementation and monitoringdetails

The new implementation requires specifying the noisy taskby modifying the kerneloil file in terms of defining thenew task and the associated alarm. Also, the new task hasto be coded: forcing an artificial execution time is achievedby placing a delay into the code. Themain code has to bemodified to configure the new alarm associated to the newtask.

After the implementation, in the first multitasking system,it can be verified that scheduling conflicts (as illustrated inthe simulated schedule shown in Figure 8a) may occur, asillustrated in Figure 9a. In this sub-figure, the execution ofthe fast controller task sets an output pin to0 and 1 ateach job start and finishing time. And the noisy task setsan output pin to0 and 0.5 at each job start and finishingtime. In addition, similar responses for the fast and overshootcontroller are obtained (see sub-figures 9 b) and c)), showingthat the overshoot controller suffers degradation from jitters,



giorgio

Rettangolo



8

(a) Overshoot controller with/without jitters

(b) Overshoot controller eliminating the jit-ter problem

Fig. 10. Overshoot controller: degradation and solution

while the fast controller shows the same response as it isexecuted in isolation. To illustrative purposes, Figure 10ashows the overshoot controller response when executing inisolation (dark curve) and when executing in the multitaskingsystem (grey curve).

Observation 11:Undergraduate students may work the ex-periment up to this problem. It shows the importance ofconcurrency and resource sharing with respect to controlperformance in a multitasking embedded control system.

L. Problem 12: Multitasking: design for eliminating or mini-mizing the jitter problem

Recent research literature has faced the problems introducedby jitter and many solutions have been proposed. Here, thesolution proposed by Lozoya et al. [44] has been adopted.

The basic idea is to synchronize the operations within eachcontrol loop at the actuation instants. In this way, the timeelapsed between consecutive actuation instants, namedtk−1

andtk, is exactly equal to the sampling period,h. Within thistime interval, the system state is sampled, namedxs,k, andthe sampling time recorded,ts,k ∈ (tk−1, tk). The differencebetween this time and the next actuation time

τk = tk − ts,k (4)

is used to estimate the state at the actuation instant as

xk = Φ(τk)xs,k + Γ(τk)uk−1 (5)

whereΦ(t) = eAt and Γ(t) =∫ t

0eAsdsB, being A and B

the system and input matrices in (3), anduk−1 the previouscontrol signal. Then, making use ofxk, the control commandis computed using the original control gainK as

uk = Kxk. (6)

The control commanduk is held until the next actuationinstant. A control strategy using (4)-(6) relies on the timereference given by the actuation instants, ifuk is applied to theplant by hardware interrupts, for example. In addition, samplesare not required to be periodic becauseτk in (4) can vary ateach closed-loop operation.

After implementing this strategy on the overshoot controllerin the multitasking system, Figure10 b) shows the result.Specifically, it shows the overshoot controller response whenexecuting in isolation (dark curve) and when executing in themultitasking system using the algorithm that eliminates jitters(grey curve).

Observation 12:The problem presented above and its solu-tion can be split into several tasks, like analysis and modellingof the new control algorithm, implementation of the controlalgorithm, etc. An interesting issue is how synchronized ac-tuation instants can be forced in the kernel. For example, asolution could be to use a periodic task for computinguk andanother periodic task for applyinguk at the required time.Another solution could be to enforce synchronized executionsat the kernel level, using the EDF tick counter. Moreover,since different solutions to the jitter problem such as [42]or [43] could have also been applied, students more confidentor interested in specific fields can select the solution that bettermeets their preferences.

V. TENTATIVE WORK PLAN AND ITS APPLICATION TO A

SPECIFIC COURSE

The previous section has detailed some of the steps requiredto successfully carry out the lab activity presented in thispaper.This section summarizes them in order to propose a tentativework plan that is divided into several sessions, each one beinga two-hour lab.

S1 - Introduction: Introduction to the activity, and sim-ulation of the open-loop response after obtaining the state-space form of theRCRC circuit from the circuit differentialequations (1) (consider random values forR andC). Here itis assumed that state-space notation is chosen.

S2 - Problem specification (a):This session should beused to specify the problem in terms of the levels for thereference signal and for discrete controller design, whichincludes selecting the sampling period and closed loop polelocations, if pole placement is used. Other control approaches,like optimal control, could also be used.

S3 - Problem specification (b):To complement the previ-ous session, observers should also be designed and simulated.The outcome of this session should be the complete simulationsetup.

S4 - Basic implementation (a):Build the RCRC circuitand verify its dynamics in open-loop. Start the controller im-plementation in a periodic hard real-time task in the processingplatform.

S5 - Basic implementation (b): Finish the controllerimplementation and test its correctness.

S6 - Multitasking (a): Incorporate a noisy task in thesimulation setup to evaluate the effects of jitter. This stepwould require to use, for example, the TrueTime simulator.



giorgio

Rettangolo



9

S7 - Multitasking (b): Incorporate the noisy task in theimplementation and validate the previous simulation results.

S8 - Advanced implementation (a):If degradation in con-trol performance is detected in the previous session, simulateadvanced control algorithms or adopt real-time techniquestosolve or reduce the jitter problem.

S9 - Advanced implementation (b):Implement the previ-ous solutions and validate them.

Note that the program timing, layout and the set of coveredtopics should be adapted to particular needs/background ofthetarget audience or to the goals of the specific curriculum. Forexample, the proposed activity has been introduced as a partof the curriculum of the 2-year master degree onAutomaticControl and Industrial Electronicsin the Engineering Schoolin Vilanova i la Geltru (EPSEVG) of the Technical Univer-sity of Catalonia (UPC) [47]. In particular, since 2007, theexperiment was tailored to become part of the laboratory forthe Control Engineering course, which covers continuous anddiscrete linear time invariant (LTI) control systems, as well asnon-linear control systems, all using state-space formalism.Sessions S1 to S5 were adopted for the laboratory of thediscrete LTI control systems part.

The Control Engineering course can be followed by studentseither in the first semester of the first year or in the firstsemester of the second year. Students choosing the secondoption simultaneously attend a course on real-time systems.Therefore, within the same classroom, not all the students arefamiliar with real-time systems. To overcome this apparentdrawback, teams of three students were formed containing atleast a student with competence on real-time systems. Withinsuch heterogeneous teams in terms of skills and theoreticalbackground, it was observed that students took their respon-sibilities and team-work was significantly improved.

As in every course edition, after finishing the discrete LTIcontrol systems part, a short and simple questionnaire is givento the students to let them evaluate several aspects of this partof the course. The questionDo the laboratory activities permitto better understand the theoretical concepts?is the only onerelated to the laboratories. Looking at the students answers,and taking into account that before introducing the presentedexperiment the lab activities were focused on the simulation ofan inverted pendulum, the percentage of students appreciatingthe practical part has increased significantly. Although thestandard course evaluation indicates this positive trend,amore complete evaluation tailored to the introduction of thisexperiment is required.

VI. CONCLUSIONS

This paper has presented a laboratory activity to be in-tegrated in the education curriculum of embedded controlsystems engineers. The activity consists of a real-time con-troller of a RCRC electronic circuit. The potential benefits,competences to be acquired, and expected learning outcomesfor students have been presented. The selection of the plantandprocessing platform has been discussed. Extensive detailsofa sample implementation have been presented and a tentativework plan for carrying out the activity has been provided.

In summary, the proposed activity poses severalreal chal-lenges to the students that can be met by putting togetherinterdisciplinary skills (electronics, real-time systems, controltheory, programming) towards a single goal: building a work-ing system.

REFERENCES

[1] D. J. Jackson and P. Caspi, “Embedded systems education: future direc-tions, initiatives, and cooperation”,SIGBED Rev., vol. 2, no. 4, pp. 1-4,Oct. 2005.

[2] A. Crespo, J. Vila, F. Blanes, and I. Ripoll, “Real-time education ina control engineering curriculum,” inThird IEEE Real-Time SystemsEducation Workshop, 1998.

[3] K. G. Ricks, D. J. Jackson, and W. A. Stapleton, “Incorporating embeddedprogramming skills into an ECE curriculum”,SIGBED Rev., vol. 4, no.1, pp. 17-26, Jan. 2007.

[4] W. A. Halang,“A curriculum for real-time computer and control systemsengineering”,IEEE Transactions on Education, vol. 33, no. 2, pp. 171-178, May 1990.

[5] P. Caspi, A. San Giovanni-Vincentelli, et al., “Guidelines for a graduatecurriculum on embedded software and systems”,ACM Transactions onEmbedded Computing Systems, vol. 4, no. 3, pp. 587 - 611, Aug. 2005.

[6] A. Sangiovanni-Vincentelli and A. Pinto, “An overview of embeddedsystem design education at Berkeley”,ACM Transactions on EmbeddedComputing Systems, vol. 4, no. 3, pp. 472-499, Aug. 2005.

[7] K. G. Ricks, D. J. Jackson, and W. A. Stapleton, “An embeddedsystems curriculum based on the IEEE/ACM model curriculum”,IEEETransactions on Education, vol. 51, n. 2, pp. 262-270, May 2008.

[8] D. Davcev, B. Stojkoska, S. Kalajdziski, and K. Trivodaliev, “Projectbased learning of embedded systems”, inProceedings of the 2nd WSEASinternational Conference on Circuits, Systems, Signal andTelecommuni-cations, 2008.

[9] S. Nooshabadi and J. Garside, “Modernization of teaching in embeddedsystems design–An international collaborative project”,IEEE Transac-tions on Education, vol. 49, no. 2, pp. 254-262, May 2006.

[10] J. W. Bruce, J. C. Harden, and R. B. Reese, “Cooperative and progres-sive design experience for embedded systems”,IEEE Transactions onEducation, vol. 47, no. 1, pp. 83-92, Feb. 2004.

[11] J. Fernandez, R. Marin, and R. Wirz, “Online competitions: an openspace to improve the learning process,”IEEE Transactions on IndustrialElectronics, vol.54, no.6, pp. 3086-3093, Dec. 2007.

[12] U. Munz, P. Schumm, A. Wiesebrock, and F. Allgower, “Motivationand learning progress through educational games,”IEEE Transactions onIndustrial Electronics, vol.54, no.6, pp. 3141-3144, Dec. 2007.

[13] L. Gomes, and S. Bogosyan, “Current Trends in Remote Laboratories,”IEEE Transactions on Industrial Electronics, vol. 56, no. 12, pp. 4744-4756, Dec. 2009.

[14] D. T. Rover, R. A. Mercado, Z. Zhang, M. C. Shelley, and D.S. Helvick,“Reflections on teaching and learning in an advanced undergraduatecourse in embedded systems,”IEEE Transactions on Education, vol.51,no.3, pp.400-412, Aug. 2008.

[15] K.-E. Arzen, A. Blomdell, and B. Wittenmark, “Laboratories and real-time computing: integrating experiments into control courses,” IEEEControl Systems Magazine, vol. 25, no. 1, pp. 30-34, Feb. 2005.

[16] G. Buttazzo, “Research trends in real-time computing forembeddedsystems”,ACM SIGBED Review, vol. 3, no. 3, Jul. 2006.

[17] P. Horacek, “Laboratory experiments for control theorycourses: Asurvey,” Annual Reviews in Control, vol. 24, pp. 151162, 2000.

[18] M. Moallem, “A laboratory testbed for embedded computer control,”IEEE Transactions on Education, vol. 47, no. 3, pp. 340-347, Aug. 2004.

[19] D.-J. Lim, “A laboratory course in real-time software forthe control ofdynamic systems”,IEEE Transactions on Education, vol. 49, no. 3, pp.346-354, Aug. 2006.

[20] M. Huba and M. Simunek, “Modular approach to teaching PIDcontrol,”IEEE Transactions on Industrial Electronics, vol. 54, no. 6, pp. 3112-3121, Dec. 2007.

[21] VxWorks operating system from WindRiver, http://www.windriver.com/[22] R. Marau, P. Leite, M. Velasco, P. Martı, L. Almeida, P. Pedreiras, and

J. M. Fuertes, “Performing flexible control on low cost microcontrollersusing a minimal real-time kernel”,IEEE Transactions on IndustrialInformatics, vol. 4, no. 2, pp. 125-133, May 2008.

[23] F. Salewski, D. Wilking, and S. Kowalewski, “Diverse hardware plat-forms in embedded systems lab courses: a way to teach the differences”,SIGBED Rev., vol. 2, no. 4, pp. 70-74, Oct. 2005.



giorgio

Rettangolo



10

[24] Evidence srl., http://www.evidence.eu.com/[25] Real-time Linux Foundation, Inc., http://www.realtimelinuxfoundation.org/[26] J. A. Stankovic and K. Ramamritham, “The spring kernel: a new

paradigm for real-time operating systems,”SIGOPS Oper. Syst. Rev.,vol. 23, no. 3, pp. 54–71, 1989.

[27] K. M. Zuberi, P. Pillai, and K. G. Shin, “Emeralds: a small-memoryreal-time microkernel,” in7th ACM symposium on Operating SystemsPrinciples, pp. 277–299, 1999.

[28] P. Gai, G. Lipari, L. Abeni, M. di Natale, and E. Bini, “Architecture fora portable open source real-time kernel environment,” inProceedings ofthe Second Real-Time Linux Workshop and Hand’s on Real-TimeLinuxTutorial, Nov. 2000.

[29] E. Mumolo, M. Nolich, and M. Noser, “A hard real-time kernel for mo-torola microcontrollers,” in23rd International Conference on InformationTechnology Interfaces, Jun. 2001.

[30] P. Gai, L. Abeni, M. Giorgi, and G. Buttazzo, “A new kernel approachfor modular real-time systems development,” in13th IEEE EuromicroConference on Real-Time Systems, Jun. 2001.

[31] D. Henriksson and A. Cervin, “Multirate feedback control using theTinyRealTime kernel,” inProceedings of the 19th International Sympo-sium on Computer and Information Sciences, Antalya, Turkey, Oct. 2004.

[32] OSEK/VDX Portal, http://www.osek-vdx.org/.[33] G. Buttanzo,Hard Real-Time Computing Systems: Predictable Schedul-

ing Algorithms and Applications, Norwell, MA, USA: Kluwer AcademicPublishers, 1997.

[34] Eclipse portal, http://www.eclipse.org/.[35] Microchip portal, http://www.microchip.com/.[36] Scilab/Scicos portal, http://www.scilab.org/.[37] MathWorks portal, http://www.mathworks.com/.[38] D. Hercog, B. Gergic, S. Uran, and K. Jezernik, “A DSP-based remote

control laboratory,”IEEE Transactions on Industrial Electronics, vol. 54,no. 6, pp. 3057-3068, Dec. 2007.

[39] K. Ogata,Modern Control Engineering, 4th Edition, Prentice Hall, 2001.[40] C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogram-

ming in a hard-real-time environment,”Journal of the Association forComputing Machinery, vol. 20, no. 1, pp. 46–61, Jan. 1973.

[41] K.-E. Arzen, A. Cervin, J. Eker, and L. Sha, “An introduction to controland scheduling co-design,” in39th IEEE Conference on Decision andControl, 2000.

[42] J. Skaf and S. Boyd, “Analysis and synthesis of state-feedback con-trollers with timing jitter,” IEEE Transactions on Automatic Control, vol.54, no. 3, pp. 652-657, March 2009.

[43] P. Balbastre, I. Ripoll, J. Vidal, and A. Crespo, “A taskmodel to reducecontrol delays,”Real-Time Systems, vol. 27, no. 3, pp. 215-236, Sep.2004.

[44] C. Lozoya, M. Velasco, and P. Martı, “The one-shot task modelfor robust real-time embedded control systems”,IEEE Transactions onIndustrial Informatics, vol. 4, no. 3, pp. 164-174, Aug. 2008.

[45] D. Henriksson, A. Cervin, and K.-E.Arzen, “TrueTime: simulation ofcontrol loops under shared computer resources,” in15th IFAC WorldCongress, 2002.

[46] Y. Wu, E. Bini, and G. Buttazzo, “A framework for designing embeddedreal-time controllers”, in14th IEEE International Conference on Embed-ded and Real-Time Computing Systems and Applications, Aug. 2008.

[47] EPSEVG School portal, http://www.epsevg.upc.edu/.

Pau Mart ı (M’02) received the degree in com-puter science and the Ph.D. degree in automaticcontrol from the Technical University of Catalonia,Barcelona, Spain, in 1996 and 2002, respectively.Since 1996, he has been an assistant professor in theDepartment of Automatic Control at the TechnicalUniversity of Catalonia. During his Ph.D. he was avisiting student at Malardalen University, Vasteras,Sweden. From 2003 to 2004, he held a researchfellow appointment in the Computer Science Depart-ment at the University of California at Santa Cruz.

His research interests include embedded systems, control systems, real-timesystems, and communication systems.

Manel Velasco graduated in maritime engineeringin 1999 and received the Ph.D. degree in automaticcontrol in 2006, both from the Technical Universityof Catalonia, Barcelona, Spain. Since 2002, he hasbeen an assistant professor in the Department ofAutomatic Control at the Technical University ofCatalonia. His research interests include artificialintelligence, real-time control systems, and collabo-rative control systems, especially on redundant con-trollers and multiple controllers with self-interactingsystems.

Josep M. Fuertes (S’74-M’96) received the de-gree in industrial engineering and the Ph.D. degreefrom the Technical University of Catalonia (UPC),Barcelona, in 1976 and 1986, respectively.

From 1975 to 1986, he was a Researcher at theInstitut de Cibernetica (Spanish Consejo Superiorde Investigaciones Cientficas). In 1987, he becamea Permanent Professor with the UPC. In 1987, hegot a position for a year at the Lawrence BerkeleyLaboratory, Berkeley, CA, where he was a VisitingScientific Fellow for the design of the Active Control

System of the W. M. Keck 10-m segmented telescope (Hawaii). From1992, he was the responsible of the University Research Linein AdvancedControl Systems and later of the Distributed Control Systems Group. From1996 to 2001, he acted as a Spanish Representative at the Council of theEuropean Union Control Association. His research interests are in the areasof distributed, networked and real-time control systems and applications. Since1989, he has been coordinating projects at the national and international levelsrelated to the aforementioned areas of expertise. He is a memberof theAdministrative Committee of the IEEE Industrial Electronics Society, wherehe is chairing the Technical Committee of Networked Based Control Systemsand Applications. He has collaborated as the Organizer, Chairman, SessionOrganizer, and member of program committees for several internationalconferences.

Antonio Camacho received the B.S. degree inchemical engineering in 2000 and the M.S. degreein automation and industrial electronics in 2009,both from the Technical University of Catalonia,Barcelona, Spain. Currently, he is pursuing the Ph.D.degree in electronic engineering also at the Techni-cal University of Catalonia. His research interestsinclude networked and embedded control systems,industrial informatics, and power electronics.

Giorgio Buttazzo (SM’05) received the degree inelectronic engineering from the University of Pisa,Pisa, Italy, in 1985, the master degree in com-puter science from the University of Pennsylvania,Philadelphia, in 1987, and the Ph.D. degree incomputer engineering from the Scuola SuperioreSantAnna of Pisa in 1991.

He is a Full Professor of computer engineering atthe Scuola Superiore SantAnna of Pisa. From 1987to 1988, he worked on active perception and real-time control at the G.R.A.S.P. Laboratory of the

University of Pennsylvania. His main research interests include real-timeoperating systems, dynamic scheduling algorithms, quality ofservice control,multimedia systems, advanced robotics applications, and neural networks. Hehas authored six books on real-time systems and over 200 papersin the fieldof real-time systems, robotics, and neural networks.



giorgio

Rettangolo

design of an embedded control systems laboratory experiment

Documents