DEMES: a Discrete-Event methodology for Modeling and simulation of Embedded Systems

1 2
Gabriel Wainer SMSCS Rodrigo Castro MSCS
1 2
Department of Systems and Computer Engineering Computer Science Department
VSim Centre. Carleton University. Ottawa, ON. Universidad de Buenos Aires and CIFASIS-
K1S 5B6. Canada. CONICET (Rosario, Santa Fe). Argentina.
http://www.sce.carleton.ca/faculty/wainer

In the last thirty years, the Software Engi- deals with these issues by using a model-based.
neering community has spent a tremendous ef- The approach combines the advantages of M&S
fort in creating formal methods and tools for de- with the rigor of a formal methodology based on
veloping embedded systems, in particular, those DEVS (Discrete Event systems Specification)
with real-time constraints. Despite these efforts, formalism [1]; it supports rapid prototyping and
most existing methods are still hard to scale up, encourages reuse. DEVS is a well-defined for-
and they require expensive testing efforts with malism that is expressive, operates at a high lev-
no guarantees for bug-free products. Instead, el of specification, and it can be used to
systems engineers have often relied on modeling represent both computing systems and the physi-
and simulation (M&S) techniques to improve the cal systems they control. DEVS models have a
development task and obtain higher quality rich structural representation of components, and
products. M&S-based testing is widely used for formal means for explicitly specifying their tim-
the early stages of a project; however, when the ing, which is central for real-time systems.
development tasks switch towards the target en- DEMES enables the incremental construc-
vironment, early models are often abandoned. In tion of such embedded applications using a dis-
order to deal with these issues, we introduce crete-event architecture for both simulation and
DEMES (Discrete-Event Modeling of Embed- the target product architecture. The use of DEVS
ded Systems) an M&S-based development me- for DEMES offers the following advantages:
thodology based on discrete-event systems spe- - Reliability: logical and timing correctness rely
cifications. DEMES combines the advantages of on DEVS system theoretical roots and sound
a practical approach with the rigor of a formal mathematical theory.
method, in which one consistently use models - Model reuse: DEVS has well-defined concepts
throughout the development cycle. for coupling of components and hierarchical,
modular model composition.
Introduction to DEMES
- Hybrid modeling and knowledge reuse: it
Formal methods for embedded systems de- has been proven that DEVS is the most general
velopment use mathematical notations to define discrete event formalism (i.e., every other me-
the system’s requirements, allowing proving sys- thod can be expressed as DEVS), and many
tem properties (liveness, timeliness, etc.). These techniques used for embedded systems have
techniques have had success, but they are still been mapped into DEVS (e.g., Verilog, VHDL,
difficult to apply and do not scale up well. In- Timed Automata, State Charts, etc.). Hence, we
stead, construction of system models and their can use different methods while keeping inde-
analysis through simulation (M&S) reduces cost pendence at the level of the executive, using the
and risk, allowing exploring changes and testing most adequate technique on each part of system
of dynamic conditions in a risk-free environ- architecture and reusing existing expertise.
ment. This is a useful approach, moreover con- - Process flexibility: these hybrid modeling ca-
sidering that testing under actual operating con- pabilities are transparent for the executive,
ditions may be impractical and in some cases which is defined by an abstract mechanism that
impossible. Despite the net gains, most project is independent from the model itself. Existing
managers are reluctant to use M&S because they DEVS tools have showed their ability to execute
require extra initial resources for models that such variety of models with high performance.
will not be part of the final application. DEMES
- Testing: defining experimental frames (i.e., the ronment after thorough testing in the simulated
set of conditions under which the system is ob- platform, allowing reusing of models throughout
served or experimented with) can be automated. the process. The approach does not impose any
DEMES uses M&S for the initial stages, order in the deployment in the actual hardware
and replaces models incrementally with hard- platform, providing flexibility to the overall
ware surrogates without modifying the original process. Figure 1 shows the architecture of the
models. The transition can be done in incremen- process used in DEMES.
tal steps, incorporating models in the target envi-

Figure 1. DEMES development cycle.

Initially (1), we define a specification mod- software and hardware models can be refined,
el of the System of Interest (SoI) using a formal progressively setting checkpoints in real proto-
model (using DEVS or alternative techniques types. The executive allows to execute dynamic
translated to equivalent DEVS models). Once models and to schedule static and dynamic tasks.
the DEVS specification model is complete, At this point, those parts that are still unve-
model-checking can be used for validation of the rified in the formal and simulated environments
model properties (2). The same models are then are tested, increasing the confidence of the engi-
used to run DEVS simulations of the behavior of neer into the implemented system (7). Any mod-
the different submodels under specific loads (3). ifications require going back to the same model
In brief, we first study system properties analyti- specifications (8), which ensure that we can pro-
cally, and complement the proofs using simula- vide a consistent set throughout the develop-
tion, which can also be used for hard- ment. This software lifecycle is cyclic, allowing
ware/software codesign (and for training). refinement following a spiral approach. On each
The same DEVS specification model is cycle of the spiral, we end with a prototype ap-
used to derive test cases (4), which can be also plication consisting of software/hardware com-
used for the simulation studies. Deriving test ponents interacting with simulated components.
cases from both the model (4) and from the si-
Other Model-Based approaches
mulation results (5) allows us to check that the
models conform to the requirements. Once we Different techniques have been proposed to
are satisfied with both analytical and simulated deal with the issues discussed earlier. For in-
results, the models are incrementally moved into stance, BIP [2] defines components as the super-
a target platform. A real-time Executive (6) ex- position of three layers: Behavior (a set of transi-
ecutes the models on the particular hardware (9). tions); Interactions (between transitions) and
If the hardware is not readily available, the soft- Priorities (to choose amongst interactions). BIP
ware components can still be developed incre- preserves properties during model composition
mentally and tested against a model of the hard- and supports analysis and transformations across
ware to verify viability and take early design de- heterogeneous boundaries (untimed/timed, asyn-
cisions. As the design process evolves, both chronous/synchronous, event /data-triggered).
 Ptolemy II [3] is a structured and hierar- cur before ta(s), the model activates the output
chical method for modeling heterogeneous sys- function λ (outputs Y) and moves to a new state
tems using specific MoC that covers the flow of determined by the internal transition function
data and control. ECSL (Embedded Control Sys- δint. A DEVS coupled model is:
tems Language) supports the development of CM = < X, Y, D, {Mi}, {Zij}, select >
distributed controllers [4], including a domain- CM represents a set of basic components
specific environment for automotive systems Mi (i∈D) interconnected through their interfaces
(extending the Matlab family with capabilities (X, Y). The translation function Zij converts the
for specification, verification, scheduling, per- outputs of a model into inputs for others, and the
formance analysis, etc.). select function is used for tie-breaking. The clo-
SystemC and Esterel are system-level lan- sure under coupling (i.e., a coupled model has an
guages used to simulate and execute models, atomic equivalent) enables model reuse.
which have widespread industry adoption [5]. In the last few years, DEVS has been used
SystemC represents hardware/software systems for modeling applications with real-time con-
at different abstraction levels, allowing choosing straints. RT-DEVS [7] introduced a DEVS-
the desired level of detail for each component. based framework for the transformation from the
Esterel is used for hardware/software synthesis system design to the implementation of embed-
through a synchronous reaction-based language ded systems. In [8] the authors present a formal
and higher-level statements for concurrency. mapping of DEVS models into timed Communi-
One of the most popular techniques, UML- cating Sequential Process (tCSP) for hard-
RT, provides an object-oriented methodology. A ware/software codesign. DEVS/DOC [9], a co-
comparison between DEVS and UML-RT [6] design methodology, was used to predict archi-
shows that, although available in the UML-RT tectural decisions that could lead to incorrect
Profile, time, scheduling and performance are system behavior, introducing a modeling layer
coded using UML constructions (i.e., not for- on top of fine grained DEVS modeling con-
mally defined). Instead, DEVS provides sound structs. In [10] DEVS was implemented on a
syntax/semantics for structure, behaviour, time TINI Chip using a just-as-needed real time envi-
representation and composition, which lend ronment to run on the chip efficiently. A co-
themselves to well-defined computation. DEVS, development methodology defined in [11] facili-
however, is not intended for software design and tated the repetitive testing of on-going system
development, and "it is key to support the trans- specifications. PowerDEVS, which supports
formation of simulation models to their software continuous and hybrid systems with quantized
model counterparts and their complementary state numerical methods was extended with real-
roles in handling modeling and computational time support.
complexity of embedded systems". DEMES
software development environment focuses on E-CD++: an environment for DEMES
complementing these shortcomings. CD++ [12] provides a mechanism to build
Modeling with DEVS DEVS models (which can be implemented in
C++ or using a built-in language) using DEVS
A real system modeled with DEVS [1] is formal specifications. The ButtonInputModule
described as a hierarchical and modular compo- model shows parts of the transition functions for
site of models that can be behavioral (atomic) or a component of a cruise control system (CCS).
structural (coupled). A DEVS atomic model is:
AM = < X, S, Y, δint, δext, λ, ta > ButtonInputModule::ButtonInputModule ( const
Every state s ∈ S is associated with a life-
string &name ) : Atomic( name ),
in_BUTTON( addInputPort("in_BUTTON") ),
time, defined by the time advance function ta(s). out_ON( addOutputPort("out_ON") ),
When a model receives an input event X, the ex- out_RESUME( addOutputPort("out_RESUME"))
{reactionTime = VTime( 0, 0, 0, 15 );}
ternal transition function δext is triggered. This
function uses the input event, the current state Model &ButtonInputModule::externalFunction (
const ExternalMessage &msg ) {
and the time elapsed since the last event to de- if( msg.port() == in_BUTTON ) {
termine the next model’s state. If no events oc- inType=(int)msg.value();
 holdIn( active, reactionTime );}}
Model &ButtonInputModule::outputFunction (
const InternalMessage &msg ) {
switch(inType) {
case ON: //take action {
sendOutput( msg.time(), out_ON, HIGH); }
case OFF: //take action {
sendOutput( msg.time(), out_OFF, HIGH);
...} ... } }

Model &ButtonInputModule::internalFunction (
const InternalMessage & ) {passivate();}

RT-CD++ [13] integrates simulation mod-

els and hardware components for the DEMES
methodology. We thoroughly tested the perfor-
mance of RT-CD++ using real applications and Figure 2. RT-CD++ simulation scheme
synthetic benchmarks. In all cases, we obtained
a small overhead (2% to 3% for large models) RT-CD++ was the base for Embedded
thanks to the use of a Flat Coordinator execu- CD++ (E-CD++) [14]. The time advance func-
tive, which enhanced performance by lowering tion is tied to the real-time clock, and in-
the internal messaging overhead. Figure 2 out- puts/outputs can interact with external devices.
lines the software hierarchy generated to execute The engine runs on a single board computer
the CCS model above. Root Coordinator man- (SBC), interacting with hardware components.
ages the interaction with an Experimental Frame An Eclipse-based IDE (E-CD++ Eclipse-based
(used to test the model). Coordinators synchron- IDE) helps non-expert users following the
ize the subcomponents. Each external input can DEMES methodology (including a graphical en-
be associated to a timing constraint. When the vironment based on DEVS-Graphs). We in-
processing of such an event is completed, the cluded a Flexible Dynamic Structure algorithm
Coordinator checks to see if the deadlines were in E-CD++ based on Dynamic structure DEVS
met (to obtain performance metrics, or to pro- [15], supporting structural changes for changing
vide alternate actions if a deadline is missed). environments.

Figure 3. E-CD++ Eclipse-based IDE

 logic of the ECU is located in the external transi-
Applying E-CD++ for DEMES
tion function, which handles the buttons pressed
We show how to use DEMES to develop and schedules the next internal transition to con-
embedded applications incrementally, integrat- trol the engine or to display a new value (e.g.,
ing simulation models and hardware compo- the elevator starts moving, or a new floor is
nents. Initially, we develop models entirely in E- reached). Users can define the activation time
CD++, and we replace them with hardware sur- for the engine, customizing its timing behavior.
rogates at later stages of the process, making the Different experimental frames were applied to
transition in incremental steps, incorporating this model, allowing the analysis of different
models in the target environment with hardware- scenarios. We started by analyzing the behavior
software components after thorough testing in of each submodel independently (using the spe-
the simulated platform (using the specification cifications for their physical counterparts) and
models throughout the process). then conducted integration tests as in Table 1.
On web reference http://youtube.com/arslab
the reader will find a sample application built as Time Deadline In-port Out-Port Val.
Experimental Frame
an experimentation environment for the con- 00:11:510 00:11:700 btn_3 led3 1
struction of robotic controllers. We also built a 00:14:600 00:14:800 sensor_2 flr_display 1
model of the CODEC of the Analog Devices 00:19:500 00:19:700 sensor_3 flr_display 1
... ...
2189M EZ-KITLITE. This was originally built Outputs
as a DEVS model, and it was later replaced it by 00:11:510 00:11:700 led3 1
a hardware prototype on a DSP board. These ex- 00:11:510 dir_display 1
00:14:610 00:14:800 flr_display 2
amples were used to experiment model-to- 00:19:510 00:19:700 led3 0
hardware transition without modifying the origi- 00:19:510 flr_display 3
00:19:510 dir_display 0
nal design. ... ...
Elevator Application Table 1. Experimental frame for the elevator.
We show the ideas above with a simple ex- Once satisfied with the overall behavior of
ample of an elevator servicing a four-floor build- the simulated model, we progressively replaced
ing. Initially we model and simulate the entire the models by hardware components. The first
system, using the structure presented in Figure 4. step was to replace the button controller (using a
bt n_1
bt n_2 keypad to send requests to the simulated ECU,
bt n_3
bt n_4 which remain unchanged). Replacing this com-
ponent is straightforward (we only removed the
But ton Co ntr oll er
original component from the coupled model de-
finition file and changed the coupling data).
El eva tor B ox
Testing the model only requires reusing the
E lev ato r Eng ine
Co ntr oll er experimental frames used for simulation. As we
Un it
built the button controller model following the
Sen sor
Co ntr oll er hardware specifications for the actual buttons,
D isp la y C ont rol ler
and the interfaces of the models do not change,
the transition is transparent (the results obtained
le d1
were equivalent to Table 1, regardless of the
le d2
.. .
changes). After conducting extensive tests, we
di r_d isp lay
fl r_d isp lay
also moved the remaining components to the
microcontroller (and only the elevator’s engine
Figure 4. Scheme of the elevator system is still simulated).
Embedded Network Control
The system consists of an Elevator Control
Unit (ECU), the Elevator Box (formed by two In this section we show how to apply
atomic models: the engine and a sensor control- DEMES to design a supervisory control for net-
ler), a button and display controllers. Most of the work Quality of Service (QoS) embedded in a
Network Processor. The goal is to enforce low- shaping actions. These actions regulate the thre-
level traffic shaping actions according to high- shold levels at the low-level algorithm RED
level QoS policies (which assign finite network (Random Early Detection). RED discards pack-
resources to multiple competing traffic flows) ets arriving from incoming queues according to
and the evolving performance of traffic [16]. a probability associated to the queue length. This
This discipline spans several domains, specifica- probability increases linearly (growing from 0
tion languages and temporal dynamics. At the when a Queue Minimum Threshold QmT is
higher levels, we find coarse-grained global pol- crossed, and stopping at 1 when a Queue Maxi-
icies (with a few changes per day). At lower le- mum Threshold QMT is reached). Our experi-
vels, QoS shaping algorithms modify the as- mental shaper sends commands to RED indicat-
signment of network resources to data-flows ing that QmT and QMT should be adjusted to
(every few seconds). At the lowest levels, spe- new values, thus affecting the packet drop-rate.
cific algorithms take granular decisions at the We used an Intel IXP2400 Network Processor,
microsecond time scale on a per-packet basis. an OC-48/2.5 Gbps line rate packet chip struc-
This scenario makes it difficult to design and test tured in two internal levels: a slow data path
QoS management, and to verify and validate the with an Intel XScale Core processor (XScale),
system-wide effects of layer-specific changes. and a fast data path with 8 multi-threaded pipe-
We designed a QoS shaper prototype that lined MicroEngines (ME). IXP2400 allows im-
accepts policies from higher levels while know- plementing reconfigurable rule engines that can
ing the status of the lowest level traffic (e.g., the be adapted on demand while sustaining high per-
current packet drop-rate). Depending on the pol- formance packet handling tasks [17].
icies and the drop-rate, control actions are sent We embedded E-CD++ into the XScale and
to the lower packet-level algorithms to enforce interfaced it to the MEs. The embedded models
granular decisions. QoS I/O information is ex- executed by E-CD++ interact in real-time with
changed through real-time ports between E- specialized packet handling code (microblocks)
CD++ and the packet handling circuitry. ran distributed in the MEs. We then followed
When a high-level QoS policy changes, DEMES for an incremental co-development pro-
model's parameters get different values, adapting totype of the QoS system.
the QoS Controller with a new behavior for the

Figure 5. Modeling a QoS processing system

 We first verified the system behavior in a logical correctness and timing), enables model
PC with a standalone version of the E-CD++ si- reuse, and permits reducing development and
mulator. Once the functionality of the QoS Con- testing times. Consequently, the development
troller was verified, we moved it into the XScale cycle is shortened, its cost reduced, and quality
processor. In this stage, as the simulator’s expe- and reliability of the final product improved.
rimental frame changed, a new verification Testing and maintenance phases are highly
phase was conducted to reassess simulation re- improved due to the use of a formal approach.
sults (Figure 5, left). QoS Actuator and Traffic Relying on experimental frameworks facilitates
Sensor send commands and sense drop-rate val- testing in a cost-effective manner, allowing users
ues, respectively. They talk to their counterparts to build and reuse test frames for each submodel.
in the Packet Processing system: a QoS Shaper Since DEVS is closed under coupling, models
and a Metering System. In the last stage, we can be decomposed in simpler versions, always
move from embedded simulation to real-time obtaining equivalent behaviour. Finally, the se-
execution of models (Figure 5, Right). mantics of models are not tied to particular in-
The MEs replace their DEVS equivalent terpretations, thus existing models can be reused.
models (which originally performed the traffic E-CD++ provides us with a tool for
generation and consumption, and functions QoS DEMES, in which embedded systems can be de-
Shaper, Metering System and Packet Processing signed following DEVS-based methodologies,
Pipeline). QoS Actuator and Traffic Sensor are and be implemented on different hardware
deployed into special Software/Hardware Map- (FPGA, SBCs, general purpose processors or
per models (signal adapters that invoke IXP li- specialized ones like the IXA platform). The ve-
braries to perform the mapping). The switch is rified models can be deployed to the targets
transparent for the DEVS QoS Controller sys- without modifying a single line of code.
tem. Finally, the whole system is validated using We are currently working on a verification
a constant-rate packet-dropping generator code toolkit to use the timing properties of the DEVS
running on the MEs. In the meantime, a separate models under development. In this way, we will
development team reprogrammed other hard- have an environment for DEMES in which the
ware pieces, preparing the RED algorithm to user builds models, test them in the simulated
react to the new Shaping commands, interleav- environment, uses verification tools to analyze
ing the software and hardware co-development timing properties, and downloads the resulting
process and starting a new incremental cycle of application to the target platform, being able to
system verification and validation. provide rapid prototyping and enhanced devel-
opment capabilities.
Conclusion
References
M&S techniques can offer significant sup-
port for the design and test of complex embed- [1] B. P. Zeigler, H. Praehofer and T. G. Kim.
ded applications. DEMES allows for a seamless Theory of Modeling and Simulation. 2nd. ed.
transition capability for studying models through Academic Press, 2000.
simulation in a model-based environment, and [2] A. Basu, M. Bozga and J. Sifakis. "Modeling
then execute the same models directly in hard- heterogeneous real-time components in BIP". In
ware. We showed the use of DEVS as the basis Proceedings of SEFM 2006. Pune, India, 2006.
for DEMES, which allowed us to develop in- [3] J. Eker, J. Janneck, E. Lee, J. Liu, X. Liu, J.
crementally different applications including Ludvig, S. Neuendorffer, S. Sachs and Y. Xiong.
hardware components and DEVS models. The "Taming heterogeneity—the Ptolemy approach".
transition from simulated models to the actual Proceedings of the IEEE, V 91, 127-144, 2003.
hardware can be incremental, incorporating dep- [4] K. Balasubramanian, A. Gokhale, G. Karsai,
loyed models into the framework when they are J. Sztipanovits and S. Neema. "Developing Ap-
ready. This approach does not impose any order plications Using Model-Driven Design Envi-
in the deployment of the hardware components, ronments". COMPUTER, V. 39, pp. 33-40, 2006.
providing flexibility to the overall process. The [5] J. Brandt and K. Schneider, "How different
use of DEVS improves reliability (in terms of are esterel and SystemC?". In Embedded Sys-
tems Specification and Design Languages. , vol. [17] S. Gavrilovska, A. Kumar and K. Schwan.
10, Springer, 2008. pp. 3-13. "The execution of event-action rules on pro-
[6] D. Huang and H. Sarjoughian. "Software and grammable network processors". In Proceedings
simulation modeling for real-time software- of Workshop on Operating System and Architec-
intensive systems". In Proceedings of Eighth tural Support for the on-Demand IT Infrastruc-
IEEE International Symposium on Distributed ture (OASIS 2004), Boston, MA, 2004.
Simulation and Real-Time Applications. DS-RT
Gabriel Wainer received the M.Sc. (1993) and
2004. pp. 196-203. 2004.
Ph.D. degrees (1998, with highest honors) of the
[7] T. G. Kim, S. M. Cho and W. B. Lee,
University of Buenos Aires, Argentina, and
"DEVS framework for systems development:
Université d’Aix-Marseille III, France. He is an
Unified specification for logical analysis, per-
Associate Professor at the Department of
formance evaluation and implementation". In
Systems and Computer Engineering, Carleton
Discrete Event Modeling & Simulation: Enabl-
University. He is the author of four books and
ing Future Technologies. Springer. 2000.
numerous research articles, edited four other
[8] S. Schulz, J. W. Rozenblit, M. Mrva and K.
books, and helped organizing numerous
Buchenriede. "Model-based codesign". Comput-
conferences, including being one of the founders
er, vol. 31, pp. 60-67, 1998.
of SIMUTools and SIMAud. Prof. Wainer is the
[9] D. Hild, H. Sarjoughian and B. Zeigler.
Vice-President Publications, and was a member
"DEVS-DOC: a modeling and simulation envi-
of the Board of Directors of SCS. He is Special
ronment enablingdistributed codesign". IEEE
Issues Editor of the SIMULATION, member of
Trans. On Systems, Man and Cybernetics A, (32),
the Editorial Board of Wireless Networks,
78-92, 2002.
JDMS, and International Journal of Simulation
[10] X. Hu, B. P. Zeigler and J. Couretas. "Devs-
and Process Modelling. He is the head of the
on-A-chip: Implementing DEVs in real-time ja-
Advanced Real-Time Simulation lab, at Carleton
va on A tiny internet interface for scalable facto-
University's Centre for advanced Simulation and
ry automation". In Proc. of IEEE SMC. Tucson,
Visualization (V-Sim). He has been the recipient
AZ. 2001.
of various awards, including IBM Eclipse
[11] K. C. Kang, J. Y. Lee and H. J. Kim. "Co-
Innovation, SCS Leadership, various Best
development of real-time systems and their si-
Papers, and the First Bernard P. Zeigler DEVS
mulation environments". In Proc. of APSEC
M&S.
2000. Singapore, 2000.
[12] G. Wainer. “Discrete-Event Modeling and Rodrigo Castro received a Ph.D degree (2010)
Simulation: a Practitioner’s approach”. CRC in EE from Universidad Nacional de Rosario,
Press. Taylor and Francis. 2009. Argentina. Since 2007 he is a Lecturer at the
[13] G. Wainer, E. Glinsky and P. MacSween, Computer Science Department, Universidad de
"Model-driven architecture of real-time systems". Buenos Aires (UBA), Argentina, where he is the
In Model-Driven Software Development - Re- head of the Discrete Event Simulation Group.
search and Practice in Software Engineering. He is also a lecturer at the Faculty of
vol. II, Springer-Verlag, 2005. Engineering, UBA. He has been a visiting
[14] Y. H. Yu and G. Wainer. "E-CD++: An en- scholar at the Advanced Real-Time Simulation
gine for executing DEVS models in embedded lab (Carleton University, Canada) and the
platforms". Proc. of SCSC. San Diego, CA, 2007. Modeling and Simulation Research Group (ETH
[15] F. J. Barros. "Modeling Formalisms for Zurich, Switzerland). Since 2000, he has
Dynamic Structure Systems". ACM Transactions participated in several projects with industry
on Modeling and Computer Simulation, vol. 7, (Siemens, CISCO, Hewlett-Packard) in the areas
pp. 501-515, October 1997. of networking and performance optimization.
[16] A. Kuzmanovic and E. W. Knightly. "Mea- Dr. Castro was awarded an Emerging Leaders in
surement-Based Characterization and Classifica- the Americas grant by the Government of
tion of QoS-Enhanced Systems". IEEE Trans. Canada, and he received recognitions from the
Parallel Distrib. Syst., V. 14, pp. 671-685, 2003. Organization of Ibero-American States for the
Education, Science and Culture (OEI) and UBA.