Compensation-aware runtime monitoring

To avoid large overheads induced by runtime monitoring, the use of asynchronous log-based monitoring is sometimes adopted — even though this implies that the system may proceed further despite having reached an anomalous state. Any actions performed by the system after the error occurring are undesirable, since for instance, an unchecked malicious user may perform unauthorized actions. Since stopping such actions is not feasible, in this paper we investigate the use of compensations to enable the undoing of actions, thus enriching asynchronous monitoring with the ability to restore the system to the original state in which the anomaly occurred. Furthermore, we show how allowing the monitor to adaptively synchronise and desynchronise with the system is also possible and report on the use of the approach on an industrial case study of a financial transaction system.peer-reviewe

Combining testing and runtime verification

Testing and runtime verification are intimately related: runtime verification enables testing of systems beyond their deployment by monitoring them under normal use while testing is not only concerned with monitoring the behaviour of systems but also generat- ing test cases which are able sufficiently cover their behaviour. Given this link between testing and runtime verification, one is surprised to find that in the literature the two have not been well studied in each other’s context. Below we outline three ways in which this can be done: one where testing can be used to support runtime verification, another where the two techniques can be used together in a single tool, and a third approach where runtime verification can be used to support testing.peer-reviewe

Automatically generating runtime monitors from tests

A large portion of the software development industry relies on testing as the main technique for quality assurance while other techniques which can provide extra guarantees are largely ignored. A case in point is runtime verification which provides assurance that a system’s behaviour is correct at runtime. Compared to testing, this technique has the advantage of checking the actual runs of a system rather than a number of representative testcases.peer-reviewe

SMEDL: Combining Synchronous and Asynchronous Monitoring

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

Considerations for monitoring highly concurrent systems

Sequential monitoring tools such as Larva are impractical for monitoring highly concurrent systems such as online establishments handling hundreds of transactions a second — they lock valuable resources which may otherwise be used to serve valid user requests. In the context of an open-source e-commerce system, we discuss design issues involved in allowing monitors to run concurrently while at the same time ensuring that they remain correct: free from race conditions and faithful to the properties they embody.peer-reviewe

Programming compensations for system-monitor synchronisation

In security-critical systems such as online establishments, runtime analysis is crucial to detect and handle any unexpected behaviour. Due to resource-intensive operations carried out by such systems, particularly during peak times, synchronous monitoring is not always an option. Asynchronous monitoring, on the other hand, would not compete for system resources but might detect anomalies when the system has progressed further, and it is already too late to apply a remedy. A conciliatory approach is to apply asynchronous monitoring but synchronising when there is a high risk of a problem arising. Although this does not solve the issue of problems arising when in asynchronous mode, compensations have been shown to be useful to restore the system to a sane state when this occurs. In this paper we propose a novel notation, compensating automata, which enables the user to program the compensation logic within the monitor, extending our earlier results by allowing for richer compensation structures. This approach moves the compensation closer to the violation information while simultaneously relieving the system of the additional burden.peer-reviewe

Lifelong verification of software systems

Computers systems are increasingly interacting with our day-to-day life, but for this interaction to be facilitating and supporting, rather than interfering with our actions, these systems have to be dependable and trustworthy. The area of system verification and validation has a long history in computer science, but scaling up existing approaches to complex and large real-life systems is still an open-ended research question. In this paper we summarise and relate several ongoing research projects and tool development efforts in this field taking place within the Department of Computer Science.peer-reviewe

Recovery within long running transactions

As computer systems continue to grow in complexity, the possibilities of failure increase. At the same time, the increase in computer system pervasiveness in day-to-day activities brought along increased expectations on their reliability. This has led to the need for effective and automatic error recovery techniques to resolve failures. Transactions enable the handling of failure propagation over concurrent systems due to dependencies, restoring the system to the point before the failure occurred. However, in various settings, especially when interacting with the real world, reversal is not possible. The notion of compensations has been long advocated as a way of addressing this issue, through the specification of activities which can be executed to undo partial transactions. Still, there is no accepted standard theory; the literature offers a plethora of distinct formalisms and approaches. In this survey, we review the compensations from a theoretical point of view by: (i) giving a historic account of the evolution of compensating transactions; (ii) delineating and describing a number of design options involved; (iii) presenting a number of formalisms found in the literature, exposing similarities and differences; (iv) comparing formal notions of compensation correctness; (v) giving insights regarding the application of compensations in practice; and (vi) discussing current and future research trends in the area.peer-reviewe

Can We Monitor All Multithreaded Programs?

International audienceRuntime Verification (RV) is a lightweight formal method which consists in verifying that an execution of a program is correct wrt a specification. The specification formalizes with properties the expected correct behavior of the system. Programs are instrumented to extract necessary information from the execution and feed it to monitors tasked with checking the properties. From the perspective of a monitor, the system is a black box; the trace is the only system information provided. Parallel programs generally introduce an added level of complexity on the program execution due to concurrency. A concurrent execution of a parallel program is best represented as a partial order. A large number of RV approaches generate monitors using formalisms that rely on total order, while more recent approaches utilize formalisms that consider multiple traces. In this tutorial, we review some of the main RV approaches and tools that handle multithreaded Java programs. We discuss their assumptions, limitations, ex-pressiveness, and suitability when tackling parallel programs such as producer-consumer and readers-writers. By analyzing the interplay between specification formalisms and concurrent executions of programs, we identify four questions RV practitioners may ask themselves to classify and determine the situations in which it is sound to use the existing tools and approaches