scispace - formally typeset

Book ChapterDOI

SMEDL: Combining Synchronous and Asynchronous Monitoring

27 Sep 2016-pp 482-490

TL;DR: A hybrid approach is explored, where low-level properties are checked synchronously, while higher-level ones are checked asynchronously, in runtime verification of monitors based on an architecture specification.
Abstract: Two major approaches have emerged in runtime verification, based on synchronous and asynchronous monitoring. Each approach has its advantages and disadvantages and is applicable in different situations. In this paper, we explore a hybrid approach, where low-level properties are checked synchronously, while higher-level ones are checked asynchronously. We present a tool for constructing and deploying monitors based on an architecture specification. Monitor logic and patterns of communication between monitors are specified in a language SMEDL. The language and the tool are illustrated using a case study of a robotic simulator.

Summary (2 min read)

1 Introduction

  • Runtime verification(RV) [1] has emerged as a powerful technique for correctness monitoring of critical systems.
  • Synchronous monitoring incurs high execution overhead for the target system, and less critical properties may not require such strict guarantees.
  • The tool uses the language SMEDL to specify monitoring architecture and individual monitors.
  • MaC(Monitoring and Checking) [4] is an architecture for asynchronous runtime monitoring.
  • Section 4 uses the case study of simple robot simulator to evaluate the performance of the tool.

2.1 SMEDL concepts

  • A SMEDL monitoring system can be divided as four parts: target system, monitoring specification, SMEDL code generator and runtime checkers, as illustrated in Fig.
  • The SMEDL specification contains a set of monitoring objects and an architecture that captures patterns of communication between them.
  • Objects can include a set of parameters whose values are fixed when the object is instantiated.
  • SMEDL events are instantaneous occurrences that ultimately originate from observations of the execution of target system.
  • Raised events can be delivered to other monitors for checking or serve as alarms.

2.2 Brief description of the language

  • The SMEDL specification contains two parts: a definition for each monitor object and a description of the monitor network that specifies monitor instances and connections between them.
  • A SMEDL monitoring object is a collection of extended finite state machines sharing a set of internal state variables and events.
  • Semantics for single monitors determines macro-steps, that is, synchronous compositions of individual transitions of state machines (referred to as micro-steps) in response to an imported event from delivered from the environment.
  • Monitors may receive events either from the target system or from other monitors.
  • Apart from the source and target monitoring objects and events, connection patterns also specify matching rules between source and target monitor instances according to instance parameters or attributes of the event. [15] gives a detailed description of the language.

3 Tool Implementation

  • The authors have developed a toolchain for deploying monitors based on SMEDL specifications, shown in Fig.
  • The monitor generator generates the code for a single monitor object, while the configurator is responsible for integrating monitor instances and target program, based on the SMEDL architecture specification.
  • The monitor API consists of a set of function calls corresponding to imported events of the monitor object.
  • To support the asynchronous communication between monitors, the authors use the publish-subscribe mechanism of the RabbitMQ middleware [16].
  • The toolchain and the case study used in this paper is available for downloading.

4 Explorer: a Case Study

  • Explorer is a multi-threaded program for simulating robots locating and retrieving targets on a two-dimensional map.
  • Event count is used to count the number of robots having taken so far.
  • Every time count is triggered, the state variable move count is increased by 1.
  • There are three sources of overhead for synchronous monitoring: instantiation of monitors, checking of observations, and communication.
  • The second experiment considers the overhead as a function of the map size.

5 Discussion and Conclusions

  • The authors presented a tool to support generation and deployment of hybrid, i.e., synchronous and asynchronous, monitors specified in the language SMEDL.
  • A prototype of the tool has been implemented.
  • The authors first discuss some of their design decisions.
  • This restricts synchronous monitoring to a single computing node.
  • The authors assume that each monitor object in the architecture is deployed either synchronously or asynchronously.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

University of Pennsylvania University of Pennsylvania
ScholarlyCommons ScholarlyCommons
Departmental Papers (CIS) Department of Computer & Information Science
9-2016
SMEDL: Combining Synchronous and Asynchronous Monitoring SMEDL: Combining Synchronous and Asynchronous Monitoring
Teng Zhang
University of Pennsylvania
, tengz@cis.upenn.edu
Peter Gebhard
University of Pennsylvania
, pgeb@cis.upenn.edu
Oleg Sokolsky
University of Pennsylvania
, sokolsky@cis.upenn.edu
Follow this and additional works at: https://repository.upenn.edu/cis_papers
Part of the Computer Engineering Commons, and the Computer Sciences Commons
Recommended Citation Recommended Citation
Teng Zhang, Peter Gebhard, and Oleg Sokolsky, "SMEDL: Combining Synchronous and Asynchronous
Monitoring",
The 16th Conference on Runtime VeriBcation (RV 2016)
, 482-490. September 2016.
The 16th Conference on Runtime VeriBcation (RV 2016), pp. 482--490. Madrid, Spain, September 2016.
This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_papers/825
For more information, please contact repository@pobox.upenn.edu.

SMEDL: Combining Synchronous and Asynchronous Monitoring SMEDL: Combining Synchronous and Asynchronous Monitoring
Abstract Abstract
Two major approaches have emerged in runtime veriBcation, based on synchronous and asynchronous
monitoring. Each approach has its advantages and disadvantages and is applicable in different
situations. In this paper, we explore a hybrid approach, where low-level properties are checked
synchronously, while higher-level ones are checked asynchronously. We present a tool for constructing
and deploying monitors based on an architecture speciBcation. Monitor logic and patterns of
communication between monitors are speciBed in a language SMEDL. The language and the tool are
illustrated using a case study of a robotic simulator.
Keywords Keywords
monitor generation, synchronous monitoring, asynchronous monitoring
Disciplines Disciplines
Computer Engineering | Computer Sciences
Comments Comments
The 16th Conference on Runtime VeriBcation (RV 2016), pp. 482--490. Madrid, Spain, September 2016.
This conference paper is available at ScholarlyCommons: https://repository.upenn.edu/cis_papers/825

SMEDL: Combining Synchronous and
Asynchronous Monitoring
Teng Zhang
1
, Peter Gebhard
1
, and Oleg Sokolsky
1
University of Pennsylvania, Philadelphia PA 19104, USA,
{tengz,pgeb,sokolsky}@cis.upenn.edu
Abstract. Two major approaches have emerged in runtime verification,
based on synchronous and asynchronous monitoring. Each approach has
its advantages and disadvantages and is applicable in different situations.
In this paper, we explore a hybrid approach, where low-level proper-
ties are checked synchronously, while higher-level ones are checked asyn-
chronously. We present a tool for constructing and deploying monitors
based on an architecture specification. Monitor logic and patterns of
communication between monitors are specified in a language SMEDL.
The language and the tool are illustrated using a case study of a robotic
simulator.
Keywords: Monitor generation, Synchronous monitoring, Asynchronous
monitoring
1 Introduction
Runtime verification(RV) [1] has emerged as a powerful technique for correct-
ness monitoring of critical systems. Numbers of approaches have been proposed
among which synchronous monitoring [2] and asynchronous monitoring [3] are
broadly used. Synchronous monitoring will block the execution of the system
being monitored until validity of an observation is confirmed, ensuring that po-
tentially hazardous behavior is not propagated to the system environment. This
makes this method suitable for safety- and security-related contexts. However,
synchronous monitoring incurs high execution overhead for the target system,
and less critical properties may not require such strict guarantees. On the other
hand, asynchronous monitoring may allow to check the properties with less over-
head for the target system, but as the system continues its execution while
checking is performed, it may not be suitable for some critical properties. More-
over, the error point is hard to locate: when the monitor reports the violation
of the property, the target system may have already left the position causing
the problem. Most RV tools target one of these two approaches. Furthermore,
synchronous monitoring may not be suitable for distributed systems. In many
practical cases, it is desirable to combine the two approaches to get the benefits
of both and reduce effects of drawbacks.
The contribution of this paper is a tool for construction and deployment
of hybrid monitoring. The tool uses the language SMEDL to specify monitoring

architecture and individual monitors. Properties to be checked are represented in
a state-machine style in monitors. Generated monitors can be integrated with the
target system or deployed separately, according to the architecture specification.
Execution within a monitor is synchronous while the communication among
monitors is asynchronous. This allows us to monitor properties on multiple time
scales and levels of criticality.
Related work. MaC(Monitoring and Checking) [4] is an architecture for
asynchronous runtime monitoring. A distributed version of MaC, DMaC [5],
is proposed mainly for monitoring the properties of network protocols. MOP
(Monitoring Oriented Programming) [6] is a generic framework for properties
specification and the checking of the properties at runtime. Based on the work
of MOP, RV-Monitor [7] can monitor hundreds of properties of Java API specifi-
cations at the same time. Using the concepts of AOP [8] and MOP, MOVEC [9]
is compiler supporting the parametric runtime verification for systems written
in C. [10] proposes an architecture allowing for switching between synchronous
and asynchronous monitoring but it is not clear how to use synchronous and
asynchronous monitoring simultaneously. [11] proposed PT-DTL, a temporal
logical to describe the temporal properties of distributed system, and a decen-
tralized monitoring algorithm for PT-DTL. However, the proposed tool, DIANA,
only supports the asynchronous monitoring for distributed program with a fixed
architecture. [12] presents a method for monitoring multi-threaded component-
based systems described in BIP but it is not suitable for distributed systems. [13]
proposes a primitive condition rule-based system RuleR which supports the hi-
erarchy architecture of monitors but asynchronous monitoring is not supported.
Thus, despite the variety of available tools, there is presently no support for
combining synchronous and asynchronous monitoring.
The paper is organized as follows. Section 2 gives a overview of SMEDL.
Section 3 introduces the implementation of the SMEDL tool. Section 4 uses the
case study of simple robot simulator to evaluate the performance of the tool.
Section 5 concludes the paper and presents the future work.
2 Overview of SMEDL
2.1 SMEDL concepts
A SMEDL monitoring system can be divided as four parts: target system, moni-
toring specification, SMEDL code generator and runtime checkers, as illustrated
in Fig. 1. Target system is the system to be monitored and checked. The SMEDL
specification contains a set of monitoring objects and an architecture that cap-
tures patterns of communication between them. A monitoring object can be an
abstraction of a system object or an abstract entity that represents interactions
between multiple system objects. Objects can include a set of parameters whose
values are fixed when the object is instantiated. Internal state can be maintained
in an object to reflect the history of its evolution. SMEDL events are instanta-
neous occurrences that ultimately originate from observations of the execution
of target system. Events can also be raised by monitors in response to other

events. Raised events can be delivered to other monitors for checking or serve as
alarms. A SMEDL specification is independent from the system implementation
so that the monitoring specification does not need to be changed as long as the
specification remains the same, even if the implementation has been changed.
Instead, the definition of events in terms of observations on the target system is
modified. Each monitoring object is converted to executable code by the SMEDL
code generator and can be instantiated multiple times with different parameters,
either statically during the target system startup or dynamically at run time,
in response to system events such as the creation of a new thread in the target
system.
Fig. 1. SMEDL overview
2.2 Brief description of the language
The SMEDL specification contains two parts: a definition for each monitor object
and a description of the monitor network that specifies monitor instances and
connections between them.
Monitoring objects. A SMEDL monitoring object is a collection of ex-
tended finite state machines (EFSMs) sharing a set of internal state variables and
events. More precisely, a monitoring object is a tuple hinterf ace, implementationi,
where interface contains the name, unchangeable identity parameters and event
declarations; implementation contains state variables and state machines of the
monitor. In SMEDL syntax, illustrated in the case study, state machines are rep-
resented as scenarios. Three kinds of events, imported, exported and internal,
can be specified in the event declaration. Imported events of a monitor can
be received and used to trigger the execution of the monitor; exported events
are raised in the monitor and are sent to other monitors; internal events are
processed within the monitor instance. State machines are used to define the
behavior of the monitor. Transitions of the state machines are labelled with
events that trigger the transition. In addition to an event, each transition may
also be labeled by a guard, which is a predicate over state variables and event
attributes, and a set of actions, each action is either an assignment to a local
variable, or a statement that raises an event. Semantics for single monitors deter-
mines macro-steps, that is, synchronous compositions of individual transitions

Citations
More filters

01 Jan 2009-
TL;DR: This paper presents a meta-modelling framework for modeling and testing the robustness of the modeled systems and some of the techniques used in this framework have been developed and tested in the field.
Abstract: ing WS1S Systems to Verify Parameterized Networks . . . . . . . . . . . . 188 Kai Baukus, Saddek Bensalem, Yassine Lakhnech and Karsten Stahl FMona: A Tool for Expressing Validation Techniques over Infinite State Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 J.-P. Bodeveix and M. Filali Transitive Closures of Regular Relations for Verifying Infinite-State Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Bengt Jonsson and Marcus Nilsson Diagnostic and Test Generation Using Static Analysis to Improve Automatic Test Generation . . . . . . . . . . . . . 235 Marius Bozga, Jean-Claude Fernandez and Lucian Ghirvu Efficient Diagnostic Generation for Boolean Equation Systems . . . . . . . . . . . . 251 Radu Mateescu Efficient Model-Checking Compositional State Space Generation with Partial Order Reductions for Asynchronous Communicating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Jean-Pierre Krimm and Laurent Mounier Checking for CFFD-Preorder with Tester Processes . . . . . . . . . . . . . . . . . . . . . . . 283 Juhana Helovuo and Antti Valmari Fair Bisimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Thomas A. Henzinger and Sriram K. Rajamani Integrating Low Level Symmetries into Reachability Analysis . . . . . . . . . . . . . 315 Karsten Schmidt Model-Checking Tools Model Checking Support for the ASM High-Level Language . . . . . . . . . . . . . . 331 Giuseppe Del Castillo and Kirsten Winter Table of

1,687 citations


Book ChapterDOI
11 Feb 2018-
TL;DR: This chapter surveys runtime verification research related to distributed systems and reports solutions that study how to monitor system with some distributed characteristic, solutions that use a distributed platform for performing a monitoring task, and foundational works that present semantics for decomposing monitors or expressing specifications amenable for distributed systems.
Abstract: This chapter surveys runtime verification research related to distributed systems. We report solutions that study how to monitor system with some distributed characteristic, solutions that use a distributed platform for performing a monitoring task, and foundational works that present semantics for decomposing monitors or expressing specifications amenable for distributed systems.

49 citations


Cites background or methods from "SMEDL: Combining Synchronous and As..."

  • ...[94] explores the idea of decoupling the execution of monitors from the systems under scrutiny....

    [...]

  • ...[94], Attard and Francalanza [3], minimizes monitor intrusiveness because it requires less instrumentation effort....

    [...]

  • ...[94] show that this method of instrumentation can substantially reduce monitoring overhead....

    [...]


Journal ArticleDOI
TL;DR: This paper compares and contrast the various types of monitoring methodologies found in the current literature, and classify them into a spectrum of monitoring instrumentation techniques, ranging from completely asynchronous monitoring on the one end and completely synchronous monitoring onThe other.
Abstract: Runtime Monitoring is a lightweight and dynamic verification technique that involves observing the internal operations of a software system and/or its interactions with other external entities, with the aim of determining whether the system satisfies or violates a correctness specification. Compilation techniques employed in Runtime Monitoring tools allow monitors to be automatically derived from high-level correctness specifications (aka. properties). This allows the same property to be converted into different types of monitors, which may apply different instrumentation techniques for checking whether the property was satisfied or not. In this paper we compare and contrast the various types of monitoring methodologies found in the current literature, and classify them into a spectrum of monitoring instrumentation techniques, ranging from completely asynchronous monitoring on the one end and completely synchronous monitoring on the other.

22 citations


Cites background from "SMEDL: Combining Synchronous and As..."

  • ...This assumption was investigated and confirmed in [5, 29], after conducting a series of empirical experiments using various levels of synchronisations in the employed monitoring mechanisms....

    [...]


Journal ArticleDOI
23 Aug 2017-
Abstract: Runtime Monitoring is a lightweight and dynamic verification technique that involves observing the internal operations of a software system and/or its interactions with other external entities, with the aim of determining whether the system satisfies or violates a correctness specification Compilation techniques employed in Runtime Monitoring tools allow monitors to be automatically derived from high-level correctness specifications (aka properties) This allows the same property to be converted into different types of monitors, which may apply different instrumentation techniques for checking whether the property was satisfied or not In this paper we compare and contrast the various types of monitoring methodologies found in the current literature, and classify them into a spectrum of monitoring instrumentation techniques, ranging from completely asynchronous monitoring on the one end and completely synchronous monitoring on the other

19 citations


Journal ArticleDOI
Adrian Francalanza1Institutions (1)
TL;DR: This work develops a behavioural theory for monitors, computational entities that passively analyse the runtime behaviour of systems so as to infer properties about them, and identifies contextual behavioural preorders that allow us to relate monitors according to criteria defined over monitored executions of piCalculus processes.
Abstract: We develop a behavioural theory for monitors, computational entities that passively analyse the runtime behaviour of systems so as to infer properties about them. First, we present a monitor language and an instrumentation relation used for piCalculus process monitoring. We then identify contextual behavioural preorders that allow us to relate monitors according to criteria defined over monitored executions of piCalculus processes. Subsequently, we develop alternative monitor preorders that are compositional, since they allow us to relate monitors without resorting to their composite behaviour when they instrumented with systems. Importantly, we show that the latter alternative preorders are sound and complete with respect to the contextual preorders. Finally, we demonstrate how these preorders can assist the development of correct monitor synthesis tools.

9 citations


References
More filters

Proceedings ArticleDOI
Gregor Kiczales1, Erik Hilsdale2Institutions (2)
01 Sep 2001-
TL;DR: This tutorial shows how to use AOP to implement crosscutting conerns in a concise modular way and includes a description of their underlying model, in terms of which a wide range of AOP languages can be understood.
Abstract: Aspect-oriented programming (AOP) is a technique for improving separation of concerns in software design and implementation. AOP works by providing explicit mechanisms for capturing the structure of crosscutting concerns. This tutorial shows how to use AOP to implement crosscutting conerns in a concise modular way. It works with AspectJ, a seamless aspect-oriented extension to the Java(tm) programming language, and with AspectC, an aspect-oriented extension to C in the style of AspectJ. It also includes a description of their underlying model, in terms of which a wide range of AOP languages can be understood.

3,142 citations


"SMEDL: Combining Synchronous and As..." refers methods in this paper

  • ...Using the concepts of AOP [8] and MOP, MOVEC [9] is compiler supporting the parametric runtime verification for systems written in C....

    [...]

  • ...Using the concepts of AOP [8] and MOP, MOVEC [9] is compiler supporting the parametric runtime verification for systems written in C. [10] proposes an architecture allowing for switching between synchronous and asynchronous monitoring but it is not clear how to use synchronous and asynchronous monitoring simultaneously....

    [...]


01 Jan 2009-
TL;DR: This paper presents a meta-modelling framework for modeling and testing the robustness of the modeled systems and some of the techniques used in this framework have been developed and tested in the field.
Abstract: ing WS1S Systems to Verify Parameterized Networks . . . . . . . . . . . . 188 Kai Baukus, Saddek Bensalem, Yassine Lakhnech and Karsten Stahl FMona: A Tool for Expressing Validation Techniques over Infinite State Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 J.-P. Bodeveix and M. Filali Transitive Closures of Regular Relations for Verifying Infinite-State Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Bengt Jonsson and Marcus Nilsson Diagnostic and Test Generation Using Static Analysis to Improve Automatic Test Generation . . . . . . . . . . . . . 235 Marius Bozga, Jean-Claude Fernandez and Lucian Ghirvu Efficient Diagnostic Generation for Boolean Equation Systems . . . . . . . . . . . . 251 Radu Mateescu Efficient Model-Checking Compositional State Space Generation with Partial Order Reductions for Asynchronous Communicating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Jean-Pierre Krimm and Laurent Mounier Checking for CFFD-Preorder with Tester Processes . . . . . . . . . . . . . . . . . . . . . . . 283 Juhana Helovuo and Antti Valmari Fair Bisimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Thomas A. Henzinger and Sriram K. Rajamani Integrating Low Level Symmetries into Reachability Analysis . . . . . . . . . . . . . 315 Karsten Schmidt Model-Checking Tools Model Checking Support for the ASM High-Level Language . . . . . . . . . . . . . . 331 Giuseppe Del Castillo and Kirsten Winter Table of

1,687 citations


Journal ArticleDOI
TL;DR: A comparison to well-known verification techniques like model checking and testing is provided, and applications in which runtime verification brings out its distinguishing features are pointed out.
Abstract: In this paper, a brief account of the field of runtime verification is given. Starting with a definition of runtime verification, a comparison to well-known verification techniques like model checking and testing is provided, and applications in which runtime verification brings out its distinguishing features are pointed out. Moreover, extensions of runtime verification such as monitor-oriented programming, and monitor-based runtime reflection are sketched and their similarities and differences are discussed. Finally, the use of runtime verification for contract enforcement is briefly pointed out.

701 citations


"SMEDL: Combining Synchronous and As..." refers background in this paper

  • ...Runtime verification(RV) [1] has emerged as a powerful technique for correctness monitoring of critical systems....

    [...]


Journal ArticleDOI
Moonzoo Kim1, Mahesh Viswanathan2, Sampath Kannan3, Insup Lee3  +1 moreInstitutions (3)
01 Mar 2004-
Abstract: We describe Java-MaC, a prototype implementation of the Monitoring and Checking (MaC) architecture for Java programs. The MaC architecture provides assurance that the target program is running correctly with respect to a formal requirements specification by monitoring and checking the execution of the target program at run-time. MaC bridges the gap between formal verification, which ensures the correctness of a design rather than an implementation, and testing, which does not provide formal guarantees about the correctness of the system. Use of formal requirement specifications in run-time monitoring and checking is the salient aspect of the MaC architecture. MaC is a lightweight formal method solution which works as a viable complement to the current heavyweight formal methods. In addition, analysis processes of the architecture including instrumentation of the target program, monitoring, and checking are performed fully automatically without human direction, which increases the accuracy of the analysis. Another important feature of the architecture is the clear separation between monitoring implementation-dependent low-level behaviors and checking high-level behaviors, which allows the reuse of a high-level requirement specification even when the target program implementation changes. Furthermore, this separation makes the architecture modular and allows the flexibility of incorporating third party tools into the architecture. The paper presents an overview of the MaC architecture and a prototype implementation Java-MaC.

235 citations


Journal ArticleDOI
Patrick O'Neil Meredith1, Dongyun Jin1, Dennis Griffith1, Feng Chen1  +1 moreInstitutions (1)
01 Jun 2012-
TL;DR: An overview of the, monitoring oriented programming framework (MOP), and an explanation of parametric trace monitoring and its implementation is given.
Abstract: This article gives an overview of the, monitoring oriented programming framework (MOP). In MOP, runtime monitoring is supported and encouraged as a fundamental principle for building reliable systems. Monitors are automatically synthesized from specified properties and are used in conjunction with the original system to check its dynamic behaviors. When a specification is violated or validated at runtime, user-defined actions will be triggered, which can be any code, such as information logging or runtime recovery. Two instances of MOP are presented: JavaMOP (for Java programs) and BusMOP (for monitoring PCI bus traffic). The architecture of MOP is discussed, and an explanation of parametric trace monitoring and its implementation is given. A comprehensive evaluation of JavaMOP attests to its efficiency, especially in comparison with similar systems. The implementation of BusMOP is discussed in detail. In general, BusMOP imposes no runtime overhead on the system it is monitoring.

235 citations


"SMEDL: Combining Synchronous and As..." refers background in this paper

  • ...MOP (Monitoring Oriented Programming) [6] is a generic framework for properties specification and the checking of the properties at runtime....

    [...]


Network Information
Related Papers (5)
01 Jan 2008

Katell Morin-Allory, Laurent Fesquet +2 more

16 Feb 2004

Mohammad Reza Mousavi, P. Le Guernic +3 more

23 Jun 2005

B. D'Angelo, Sriram Sankaranarayanan +6 more

01 Apr 2005

Grigore Rosu, Klaus Havelund

Performance
Metrics
No. of citations received by the Paper in previous years
YearCitations
20211
20192
20183
20173
20091