See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/262152775

Modeling road traffic signals control using UML and the MARTE profile

Conference Paper · June 2012

DOI: 10.1007/978-3-642-31128-4_1

CITATIONS READS

5 5,585

2 authors:

Eduardo Silvestre Michel S. Soares

Instituto Federal de Educação, Ciência e Tecnologia do Triângulo Mineiro Universidade Federal de Sergipe
8 PUBLICATIONS   25 CITATIONS    98 PUBLICATIONS   566 CITATIONS   

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Michel S. Soares on 20 September 2015.

The user has requested enhancement of the downloaded file.

 Modeling Road Traffic Signals Control using
UML and the MARTE Profile

Eduardo Augusto Silvestre and Michel dos Santos Soares

Federal University of Uberlândia (UFU), Computing Faculty (FACOM),

Av. João Naves de Ávila, 2121, Bloco 1B
Uberlândia - Brazil
eduardosilvestre@iftm.edu.br
mics.soares@gmail.com

Abstract. The problem of software modeling and design of road traffic

signals control has long been taken into consideration. A variety of mod-
eling languages have been applied in this field. However, still no single
modeling language can be considered a standard to model distributed
real-time systems such as traffic signals systems. Thus, further evalu-
ation is necessary. In this article, a UML profile created for designing
real-time systems, MARTE, is applied to model a traffic signals control
system. MARTE is compared with UML and SPT, a former UML pro-
file. The result is that with MARTE, UML models are more specific, but
also more complex.

Keywords: MARTE, UML, Road Traffic Control, Real-Time Systems

1 Introduction
When designing distributed real-time systems for critical infrastructures, such
as road traffic, system complexity is increased due to the large number of ele-
ments, strict real-time constraints, and reliability factors, as these systems in-
volve human life. There are many characteristics that make the development
of distributed real-time systems difficult. Normally, these systems present high
complexity, being hard to comprehend, design, implement and verify.
Traffic signals are one of the main approaches to control intersections. They
regulate, warn and guide transportation with the purpose of improving safety
and efficiency of pedestrians and vehicles. When not well-designed, traffic signals
may lead to excessive delays when cycle lengths are too long and increase the
risk of collisions.
The behavior of a traffic signal can be modeled as a Discrete Event System
(DES). These systems are often large, distributed systems in which events occur
at specific instants of time [9]. From a DES point of view, a road junction (inter-
section) can be seen as a resource that is shared by vehicles at certain instants of
time. The design of the control logic of a traffic signal must take care of efficiency
and speed, but also of safety and security. The main purpose of traffic signals is
to provide safe, efficient and fair crossing of the junction.
 The problem of software modeling and design of road traffic signals control
has long been taken into consideration, with a variety of modeling languages
applied in this field, including Fuzzy Logic [40], Statecharts [14] [16], and Petri
nets [21] [33]. Therefore, there is no standard modeling language in this domain.
Since its introduction, UML [29] has been applied to model real-time systems
in a variety of domains [11]. Considering the road traffic domain, which is the one
of interest of this article (Section 3), UML has been applied in previous works [3]
[19]. In many of these works, UML presented flaws that were well-documented.
For instance, the representation of time is considered poor, too informal and
insufficient, and it does not include deadlocks and periods [6] [7] [13]. Behavior
diagrams, such as the Sequence diagram, cannot represent time constraints effec-
tively [34], as they are essentially untimed, expressing only chronological order
[2]. UML does not provide mechanisms to describe aspects of task management
such as priorities [6].
In order to solve these issues, the SPT profile was proposed [23]. Although
the SPT profile was studied and applied in some works [39] [1] [38] [5], it was not
well-received by the real-time community [28], mainly because it lacks character-
istics to represent hardware platforms, the representation of time is insufficient,
and it was not in conformance with UML 2.x. Therefore, a new UML profile for
real-time systems, including distributed and embedded systems, was proposed.
An overview of the MARTE profile is presented in section 2. The practical appli-
cation of MARTE is still very incipient [10], but some results have been published
in domains such as system-on-chip [31], networks [12] and the development of
software product lines [4].
To the best of our knowledge MARTE has not yet been applied to model
traffic signals control, as is done in this article through the case study presented
in Section 4. In addition, a comparison of MARTE with the former UML profile
for real time systems, SPT, and with the pure UML specification is presented in
the discussion (Section 5). The comparison is based on our own experience on
modeling with MARTE, as shown in this article, but mainly considering articles
previously published.

2 Overview on the MARTE Modeling Language

The UML profile MARTE (Modeling and Analysis of Real-Time and Embed-
ded systems) [27] is a recently adopted OMG standard that specializes UML
by adding concepts for modeling and analysis of real-time and embedded sys-
tems. MARTE is an evolution over the former UML profile SPT (Schedulability,
Performance, and Time) [23].
As illustrated in Figure 1, MARTE is organized around three main packages.
The MARTE Foundations package defines concepts for real-time and embed-
ded systems. These concepts cover the modeling of generic applications and
platform artifacts. The Foundations package is composed of the following sub-
packages: Core Elements (CoreElements), Non-Functional Properties Modeling
(NFPs), Time Modeling (Time), Generic Resource Modeling (GRM) and Allo-
cation Modeling (Alloc). These foundation concepts are refined for design pur-
pose into the MARTE Design Model package and for analysis purpose into the
MARTE Analysis Model package [22].

Fig. 1. The MARTE Profile [28]

The MARTE Design Model package provides support required for a variety
of activities, from specification to detailed design of real-time systems. It is
composed of four sub-packages. The Generic Component Model (GCM) package
presents additional concepts to address the modeling of artifacts in the context
of real-time systems. The GCM extends the UML component model by adding
two specializations of ports: message ports and flow ports.
The High-Level Application Modeling (HLAM) package provides high-level
modeling concepts to deal with real-time and embedded features modeling. The
HLAM package allows to specify temporal properties of calls. HLAM can model
active objects (active components), i.e., entities that provide their own thread
of control. The Detailed Resource Modeling (DRM) package provides a set of
detailed resources for modeling both software and hardware platforms by spe-
cializing the concepts defined within the GRM. DRM is divided into two sub-
packages: Software Resource Modeling (SRM) and Hardware Resource Modeling
(HRM).
The MARTE Analysis Model package offers concepts for the analysis of mod-
els. The analysis of models can detect problems early in the development life cycle
and is useful to reduce cost and risk of software development. The MARTE Anal-
ysis Model is composed of three sub-packages. The Generic Quantitative Analysis
Modeling (GQAM) package supports generic concepts for types of analysis based
on system execution behavior, which may be represented at different levels of
detail.
GQAM is used to specify Schedulability Analysis Modeling (SAM) and Per-
formance Analysis Modeling (PAM), offering facilities to annotate models with
information required to perform schedulability or performance analysis.

3 Domain Characteristics
Traffic signals at road intersections are the major control measures applied in
urban networks. The design of the control logic of a traffic signal must take care
of efficiency and speed, but also of safety and security. The main purpose of
traffic signals is to provide safe, efficient and fair crossing of the junction. When
properly installed and operated, traffic signals provide a number of benefits [32],
including the increase of the capacity of critical junction movements, reduction
in the frequency and severity of accidents, and safe crossing of pedestrians and
vehicles by providing interruptions in heavy streams. However, when poorly de-
signed, traffic signals can cause excessive delays when cycle lengths are too long,
increase the number of accidents (especially rear-end collisions), violations of
red light, and lead to sub-optimal rerouting by drivers who want to avoid traffic
signals.
Among the main advantages of traffic signals are the flexibility of the sig-
naling scheme, the ability to provide priority treatment and the feasibility of
coordinated control along streets. Modern traffic controllers implement signal
timing and ensure that signal indications operate consistently and continuously
in accordance with the pre-programmed phases and timing.
Many non-functional requirements are important for road traffic signals sys-
tems. These requirements do not have simple yes/no satisfaction criteria. Instead,
it must be determined to what degree a non-functional requirement has been sat-
isfied. Scalability is of great significance because there may occur changes in the
road network, which may include new sensors and actuators to be accommodated
into the system. Thus, new software objects may be inserted into the software
architecture every time the network grows. This is important to allow the system
to evolve over time.
Performance is also an issue, as there are many components to be controlled.
Real-time constraints must be observed as data should be updated regularly.
Example of available data are road traffic measurements information that are
geographically distributed within the network. Availability of data is of consid-
erable influence to system reliability and overall performance. Finally, flexibility
is essential due to the possible change of component types, interfaces, and func-
tionality.

4 Case Study
This case study is focused on the application of the MARTE profile together
with UML in activities of modeling and design for a road traffic signal intersec-
 Fig. 2. Use Case Diagram

tion control. The work was initially inspired by the modeling of an intersection
with UML proposed in [20]. The user requirements modeled in this case study
are the requirements described in the following subsection. For a more realistic
modeling of the system, the MARTE extensions that are best suitable to the
main characteristics and problems described in Section 1 and 3 were applied.
The following subsections describe the requirements, the structural design and
the dynamic design for the road traffic signal intersection control.

4.1 User Requirements

It is important to notice that the user requirements presented in this subsection
have high degree of abstraction. During system design, these requirements are
refined into more detailed software requirements. The Use Case diagram cor-
responding to these requirements is illustrated in Figure 2. The following user
requirements are used for system modeling.

1. The system shall control the traffic pattern of vehicles at the intersection.
2. The system shall control the traffic pattern of pedestrians at the intersection.
3. The system shall control the traffic flow of vehicles at all road sections related
to the intersection.
4. The system shall control the traffic pattern of vehicles at all road sections
related to the intersection.
5. The system shall allow fixed traffic control policy.
6. The system shall allow actuated traffic control policy.
7. The system shall allow adaptive traffic control policy.
8. The system shall allow green waves.
9. The system shall allow priotities for road sections.
10. The system shall detect the presence of pedestrians.
11. The system shall allow remote maintenance.
12. The system shall keep track of vehicle history at all road sections related to
the intersection.
13. The system shall keep track of traffic policy during all year.
14. The system shall allow the implementation of new traffic policies.
15. The system shall keep track of accidents at the intersection.

4.2 Structural Design

Structural design is described in this article using the Class and the Deployment
diagrams.
The class diagram supports the functional requirements and a set of key
abstractions, taken in the form of objects. A UML Class diagram utilizing the
extensions from MARTE is depicted in Figure 3. The structure of the class
diagram is centralized mainly in the classes named IntersectionController and
Approach. The intersection controller class is a singleton responsible for manag-
ing all features of the traffic signals control. It contains relationships with the
approaches and phases. The approach class is responsible for managing the in-
dividual features of each approach in the intersection. It contains references to
semaphores and push buttons.
The application of the MARTE profile in the class diagram is concentrated
in new stereotypes. The stereotype <<rtUnit>> is used to represent active
classes. The stereotype <<storageResource>> is used to represent entity classes.
The stereotype <<deviceResource>> represents an external device that may be
manipulated or invoked by the platform.
The stereotype <<clockType>> is related to time, which is a crucial feature
of real time systems. The stereotype creates a new clock. In this case study
two MARTE clock types are added in the class diagram. The first one is the
predefined IdealClock. The IdealClock models the abstract and ideal time which
is used in physical laws, i.e., it is a dense time. The IdealClock should be imported
in models that refer to chronometric clock. The second is used to represent a
scenario. The Scenario represents a scenario of utilization of the system, and the
possible policies that can be applied in the traffic signals intersection control.
The several values - references to quantities - presented in the class diagram are
described using the VSL (Value Specification Language) notation [28].
The representation of resources and their further allocation are key features in
the development of real-time systems. The definition of resources are important
to deal with concurrency, distributed elements, and parallelism. The allocation
of resources represents the allocation of functional application elements onto the
available resources.
The most suitable UML diagram used to model resources and their alloca-
tion is the deployment diagram. The deployment diagram models the run-time
configuration in a static view and visualizes the distribution of components in
an application. Figure 4 depicts a deployment diagram to represent resources
and Figure 5 a deployment diagram to represent allocation of resources.
Figure 4 is about the physical view of the software architecture of the inter-
section controller. It contains the main components of the system, such as the
operating system, the application software, the network and also the physical
components where the whole system is executed.
 Fig. 3. Class Diagram with MARTE extensions

The representation of resources in MARTE is centralized in the stereotype

<<resource>>. In this case study the <<communicationMedia>> is used in
several parts of the deployment diagram. It represents the means to transport
data from one location to another. Thus, its use represents the flow of data. The
<<deviceResource>> and the <<storageResource>> stereotypes are the same
as described in the class diagram. The <<computingResource>> represents
Fig. 4. Deployment Diagram with MARTE extensions for representation of resources

either virtual or physical processing devices capable of storing and executing the
software. In this case study, for example, the real-time operating system can be
considered a <<computingResource>>.
Figure 5 shows an example of allocation of resources with three layers. The
first layer describes the application, the second layer represents a real-time op-
erating system (RTOS) and the last layer shows the hardware parts.
The top layer is the application view. This view has the same components
presented in Figure 4. The stereotype <<allocated>> is applied to named ele-
ment that has at least one allocation relationship with another named element,
and the tagged valued {kind = application} indentifies an allocation end as being
on the application side of the allocation.
The intermediate layer, the RTOS, is not the focus of this case study. It
supports the allocations at different abstraction levels. The RTOS is related to
the hardware through the stereotype <<allocate>> that is a bridge between
elements from a logical context to elements in a more physical context. The
nature is an enumeration type that defines literals used to specify the purpose of
the allocation. The tagged value {nature = timeScheduling} indicates that the
allocation consists of a temporal/behavioural ordering of the suppliers.
The lower layer in the diagram represents the hardware elements. The ele-
ments CPU, Memory, BUS and Disk are annotated with stereotypes described
previously, such as <<computingResource>> and <<communicationMedia>>.
All elements have the tagged value {kind = executionPlatform} that identifies an
Fig. 5. Deployment Diagram with MARTE extensions for representation of allocation
of resources

allocation end as being on the execution platform side of the allocation. Besides,
this layer shows the relationship <<allocate>> between the components. This
stereotype is attached with the tagged values {nature = spatialDistribution}
and {nature = timeScheduling}. The timeScheduling was described previously
and the spatialDistribution indicates that the allocation consists of a tempo-
ral/behavioural ordering of the suppliers.

4.3 Dynamic Design

Dynamic design is described in this article using the Sequence, State-Machine

and Time diagrams.
The sequence diagram is applied to model the flow of logic within the system
in a visual manner, which focuses on identifying the behavior within the system.
A UML Sequence diagram utilizing the extensions from MARTE is depicted in
Figure 6.
The sequence diagram shows the normal operation of the road traffic signal
control. The diagram depicts the operation from the first action until the normal
flow of the software.
 Fig. 6. Sequence Diagram with MARTE extensions

For this purpose, the sequence diagram shows the IntersectionController, Ap-
proach and IntersectionStandard classes. The IntersectionController manages all
system control. The Approach represents a specific approach in the intersection
and the IntersectionStandard represents traffic signals. The vehicles’ traffic sig-
nals is represented by the object vehicleTS and the pedestrians’ traffic signals
by the object pedestrianTS. The figure shows the initialization of the system,
the creation of objects and the exchange of messages between the objects.
The sequence diagram focus is on time representation. In order to reach this
purpose, the stereotype <<timedConstraint>> is used together with the VSL
package. The TimedConstraint is an abstract superclass of TimedInstantCon-
straint and TimedDurationConstraint. It allows to constraint when an event
may occur or constraint the duration of some execution or even constraint the
temporal distance between occurrences of two events.
 The state machine diagrams are useful in the real-time and embedded do-
main. They allow the description of a system behavior in terms of states and
transitions between these states. A UML state machine diagram utilizing the ex-
tensions from MARTE is depicted in Figure 7. The state machine shows states
Waiting Signal and Pedestrian Crossing. The first one represents a moment in
which the pedestrian is waiting for the signal. The last represents the moment
in which the pedestrian is crossing the signal. The transitions between the two
states represent the response to a pedestrian pressing the push button.
The application of the MARTE profile in the state machine diagram has new
stereotypes as focus. The states are represented by the stereotype <<mode>>.
It identifies an operational segment within the system execution. The transitions
between states are represented by the stereotype modeTransition. It describes
the modeled system under mode switching. The state machine is represented by
two stereotypes. The <<modeBehavior>> specifies a set of mutually exclusive
modes, i.e., only one mode can be active at a given instant. The stereotype
<<timedProcessing>> represents activities that have known start and finish
times or a known duration.

Fig. 7. State Machine with MARTE extensions

The time diagram is used to explore the behaviors of one or more objects
throughout a given period of time. Timing diagrams are often used to design real-
time systems. A UML timing diagram for traffic signals utilizing the extensions
from MARTE is depicted in Figure 8. It shows that pedestrians have the right
to cross when both traffic signals are at a red state.

5 Discussion
The comparison between UML, SPT and MARTE is not yet clear in present
literature. In order to permit a broader view of the potential of MARTE, Table
 Fig. 8. Time Diagram with MARTE extensions

5 presents a comparison between these OMG specifications based on specific

criteria most common when designing real-time systems.

Criteria UML [25] SPT [23] MARTE [28]

Modeling of time #[13] [10] G
#[24]
Modeling of processes #[15] G
# [10]
Modeling of resources G
# G
#[24] [10]
Modeling of resource allocation G
#[15] G
#[10] [24]
Modeling of hardware #[37] [26] #[10] G
#[8]
Modeling of performance #[15] G
#[30] [8]
Modeling of schedulability #[?] [15] G
#
Modeling of run-time execution #[10] G
#[24] [10] [10]
Modeling of task management #[6] [15] [10]
Modeling of requirements #[15] # #[8]
CBSE # #[30] [24] [8]
Alignment with UML 2.x not applied G
#[10] [24]
Formalism #[6] [15] # #[8]
Consistency of diagrams #[17] [36] [15] # #[18]
Ease of Use G
#[15] #[24] #
Software tools # #
Table 1. Comparison of UML, SPT and MARTE

Table 5 shows the characteristics presented for each modeling language. The
columns are annotated with the symbols #, # G e . Columns annotated with #
means that the characteristic is not present in the modeling language or it is not
satisfactory. Columns annotated with means that the characteristic is highly
present in the modeling language, i.e., its application is satisfactory. And columns
annotated with G # means that the characteristics is not yet well-known, was not
fully evaluated, or the language does not fully support the characteristic. Most
evaluations were based on previous references, as indicated, and the languages
specifications (UML [25], SPT [23], and MARTE [28]). Our own evaluation was
considered only for the MARTE profile.
The main highlights to the table in this article are the references to UML and
SPT problems and MARTE strengths and challenges. Overall, UML is weak for
real-time systems design because the language is not capable of representing key
real-time features, for instance, modeling time and processes. The table shows
the strengths of MARTE for modeling real-time systems. These strengths are
described by previous works, as indicated in the table, and also by the application
of MARTE in the case study shown in this article. For instance, design based
on components (Component Based Software Engineering - CBSE) has improved
with MARTE, as well as modeling time and resources.
Some challenges of MARTE are the same challenges of UML and SPT, such
as increasing its formalism and improving consistency in diagrams. Another ex-
ample is the modeling of requirements at an abstract level. The studied languages
are tailored to model scenarios of requirements, often at a lower abstraction level.
Another UML profile, the SysML, can fill this gap [35]. In addition, with too
many stereotypes, constraints and tagged values, MARTE is a difficult language
to master. Finally, there is a lack of software tools which can fully implement
MARTE capabilities.

6 Conclusion

The design of real-time systems is a complex activity. Many modeling languages

have been applied in this field. However, no single modeling language can be
considered a standard in this area. The purpose of this article is to apply a new
UML profile, MARTE, to model a distributed real-time system in the field of road
traffic control, more specifically, traffic signals control. MARTE is used together
with UML, complementing some UML aspects that are historically considered
weak, including modeling of time, resources and processes. With MARTE, UML
models are more specific. For instance, the modeling of resources has improved.
However, MARTE also has weak characteristics. It is too complex, and it lacks
software tools that implement the proposed stereotypes and extensions. Due to
its complexity, mastering the MARTE language is a hard challenge.
It is worth to note that MARTE is an extensible profile, which means that
further stereotypes can be created and added to the profile when necessary,
which also increases its complexity. The industrial application of MARTE is still
very incipient, and even in academia the language is still not well-known. This
means that further evaluation and discussion on its applicability is necessary. A
first attempt to compare UML, SPT and MARTE was shown in this article, but
it still needs further evaluation in future research.
7 Acknowledgements
This work was supported by FAPEMIG (www.fapemig.br - EDITAL FAPEMIG
01/2011).

References
1. Addouche, N., Antoine, C., Montmain, J.: UML Models for Dependability Analysis
of Real-Time Systems. In: Proceedings of the IEEE International Conference on
Systems, Man and Cybernetics. pp. 5209–5214 (2004)
2. André, C., Mallet, F., de Simone, R.: Modeling Time(s). In: 10th International
Conference on Model Driven Engineering Languages and Systems (MODELS ’07).
pp. 559–573. Springer Verlag (2007)
3. Bate, I., Hawkins, R., Toyn, I.: An Approach to Designing Safety Critical Systems
using the Unified Modelling Language. In: Proceedings of the Workshop on Critical
Systems Development with UML. pp. 3–17 (2003)
4. Belategi, L., Sagardui, G., Etxeberria, L.: MARTE Mechanisms to Model Vari-
ability When Analyzing Embedded Software Product Lines. In: Bosch, J., Lee, J.
(eds.) Software Product Lines: Going Beyond, Lecture Notes in Computer Science,
vol. 6287, pp. 466–470. Springer Berlin / Heidelberg (2010)
5. Bennett, A.J., Field, A.J.: Performance Engineering with the UML Profile for
Schedulability, Performance and Time: A Case Study. In: Proceedings of the The
IEEE Computer Society’s 12th Annual International Symposium on Modeling,
Analysis, and Simulation of Computer and Telecommunications Systems. pp. 67–
75 (2004)
6. Berkenkotter, K.: Using UML 2.0 in Real-Time Development - A Critical Review.
In: International Workshop on SVERTS: Specification and Validation of UML
Models for Real Time and Embedded Systems (2003)
7. Berkenkötter, K., Bisanz, S., Hannemann, U., Peleska, J.: The HybridUML profile
for UML 2.0. International Journal on Software Tools for Technology 8, 167–176
(2006)
8. Boutekkouk, F., Benmohammed, M., Bilavarn, S., Auguin, M.: UML 2.0 Profiles
for Embedded Systems and Systems On a Chip (SOCs). JOT (Journal of Object
Technology) 8(1), 135–157 (2009)
9. Cassandras, C.G., Lafortune, S.: Introduction to Discrete Event Systems. The In-
ternational Series on Discrete Event Dynamic Systems, Kluwer Academic Publish-
ers, Norwell, MA, USA (1999)
10. Demathieu, S., Thomas, F., André, C., Gérard, S., Terrier, F.: First Experiments
Using the UML Profile for MARTE. In: Proceedings of the 2008 11th IEEE Sym-
posium on Object Oriented Real-Time Distributed Computing. pp. 50–57. IEEE
Computer Society (2008)
11. Douglass, B.P.: Real Time UML: Advances in the UML for Real-Time Systems.
Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 3rd edn.
(2004)
12. Elhaji, M., Boulet, P., Tourki, R., Zitouni, A., Dekeyser, J.L., Meftali, S.: Mod-
eling Networks-on-Chip at System Level with the MARTE UML profile. In: M-
BED’2011. Grenoble France (2011)
13. Graf, S., Ober, I., Ober, I.: A Real-Time Profile for UML. International Journal
on Software Tools for Technology Transfer 8, 113–127 (2006)
14. Harel, D.: Statecharts: A Visual Formalism for Complex Systems. Science of Com-
puter Programming 8(3), 231–274 (1987)
15. Henderson-Sellers, B.: Uml - the good, the bad or the ugly? perspectives from a
panel of experts. Software and Systems Modeling 4(1), 4–13 (2005)
16. Huang, Y.S., Liau, S.X., Jeng, M.D.: Modeling and Analysis of Traffic Light Con-
troller using Statechart. In: Proceedings of the IEEE International Conference on
Systems, Man and Cybernetics. pp. 557–562 (2010)
17. Jacobson, I.: Use cases - Yesterday, today, and tomorrow. Software and System
Modeling. 3(3), 210–220. (2004)
18. Jin, W., Wang, H., Zhu, M.: Modeling MARTE Sequence Diagram with Timing
Pi-Calculus. In: ISORC. pp. 61–66 (2011)
19. K.Ranjini, A.Kanthimathi, Y.Yasmine: Design of Adaptive Road Traffic Control
System through Unified Modeling Language. International Journal of Computer
Applications 14(7), 36–41 (2011)
20. Laplante, P.A.: Real-Time System Design and Analysis. John Wiley & Sons (2004)
21. List, G.F., Cetin, M.: Modeling Traffic Signal Control Using Petri Nets. IEEE
Transactions on Intelligent Transportation Systems, 5(3), 177–187 (2004)
22. Mraidha, C., Tanguy, Y., Jouvray, C., Terrier, F., Gerard, S.: An Execution Frame-
work for MARTE-Based Models. In: 13th IEEE International Conference on En-
gineering of Complex Computer Systems. pp. 222–227 (2008)
23. OMG: UML Profile for Schedulability, Performance, and Time, Version 1.1. Tech.
Rep. formal/2005-01-02, OMG (2005)
24. OMG: MARTE Tutorial: UML Profile for Develop for Real-Time and Embedded
systems. Tech. Rep. formal/2007-03-28, OMG (2007)
25. OMG: OMG Unified Modeling Language (OMG UML) Superstructure, Version
2.3. Tech. Rep. formal/2010-05-03, OMG (2010)
26. OMG: Systems Modeling Language (SysML) - Version 1.2 (2010)
27. OMG: UML Profile for MARTE: Modeling and Analysis of Real-time Embedded
Systems - version 1.1 (2010)
28. OMG: Uml profile for marte: Modeling and analysis of real-time embedded systems
version, 1.1. Tech. Rep. formal/2011-06-02, OMG (2011)
29. OMG: Unified Modeling Language (UML): Superstructure - version 2.4.1 (2011)
30. Petriu, D.C., Woodside, M.: Extending the UML Profile for Schedulability Perfor-
mance and Time (SPT) for Component-Based Systems (2004)
31. Quadri, I.R., Yu, H., Gamatié, A., Meftali, S., Dekeyser, J.L., Rutten, É.: Target-
ing Reconfigurable FPGA based SoCs using the MARTE UML profile: from high
abstraction levels to code generation. International Journal of Embedded Systems
p. 18 p (2010)
32. Roess, R.P., Prassas, E.S., McShane, W.R.: Traffic Engineering. Prentice Hall, New
Jersey, NJ, USA, 3 edn. (2003)
33. Soares, M.S.: Modeling and Analysis of Discrete Event Systems Using a Petri Net
Component. In: Proceedings of the IEEE International Conference on Systems,
Man, and Cybernetics. pp. 814–819 (2011)
34. Soares, M.S., Julia, S., Vrancken, J.: Real-time Scheduling of Batch Systems using
Petri Nets and Linear Logic. Journal of Systems and Software 81(11), 1983–1996
(2008)
35. Soares, M.S., Vrancken, J.L.M., Verbraeck, A.: User Requirements Modeling and
Analysis of Software-Intensive Systems. Journal of Systems and Software 84(2),
328–339 (2011)
 36. Staines, A.S.: A Comparison of Software Analysis and Design Methods for Real
Time Systems. In: World Academy of Science, Engineering and Technology. pp.
55–59 (2005)
37. Süß, J., Fritzson, P., Pop, A.: The Impreciseness of UML and Implications for
ModelicaML. In: Proceedings of the 2nd International Workshop on Equation-
Based Object-Oriented Languages and Tools (2008)
38. Thramboulidis, K.: Using UML in Control and Automation: A Model Driven Ap-
proach. In: Proceddings of the IEEE International Conference on Industrial Infor-
matics. pp. 587–593 (2004)
39. Xu, J., Woodside, M., Petriu, D.: Performance Analysis of a Software Design Using
the UML Profile for Schedulability, Performance and Time. In: Proceedings of the
13th International Conference on Modelling Techniques and Tools for Computer
Performance Evaluation (TOOLS 03. pp. 291–310. Springer-Verlag (2003)
40. Zeng, R., Li, G., Lin, L.: Adaptive Traffic Signals Control by Using Fuzzy Logic.
In: ICICIC ’07: Proceedings of the Second International Conference on Innovative
Computing, Information and Control. pp. 527–530 (2007)

View publication stats