Team Pop Art

Overall Objectives
Scientific Foundations
Application Domains
New Results
Contracts and Grants with Industry
Other Grants and Activities

Section: New Results

Component-Based Construction

Participants : Alain Girault, Gregor Gössler [contact person] , Gideon Smeding.

Specification Enforcing Refinement for Convertibility Verification

Protocol conversion deals with the automatic synthesis of an additional component or glue logic, often referred to as an adaptor or an interface, to bridge mismatches between interacting components, often referred to as protocols. A formal solution, called convertibility verification, has been recently proposed, which produces such a glue logic, termed as a converter, so that the parallel composition of the protocols and the converter also satisfies some desired specification. A converter is responsible for bridging different kinds of mismatches such as control and clock mismatches. Mismatches are usually removed by the converter (similar to controllers in supervisory control of discrete event systems) by disabling undesirable paths in the protocol composition. In [82] we defined a solution to the converter synthesis problem for control mismatches based on a refinement relation called Specification Enforcing Refinement (SER) between a protocol composition and a desired specification.

We are currently working on a generalization of this convertibility verification problem in order to take data exchange — and hence, incompatibilities stemming from inconsistent protocol specifications of how data are exchanged — into account.

Contract-based Design

Contracts have first been introduced as a type system for classes [77] : a method guarantees some post-condition under the assumption that its pre-condition is satisfied. In the component-based programming community, contracts are increasingly focus of research as a means to achieve one of the main goals of the component paradigm, namely the deployment and reuse of components in different, a priori unknown contexts. As components may interact under various models of communication, the notion of contract has been generalized from pre- and post-conditions in the form of predicates to behavioral interfaces such as interface automata [86] , allowing to reason about the temporal behavior of environments with which a component can be composed.

Probabilistic Contracts

Typical embedded and distributed systems often encompass unreliable software or hardware components, as it may be technically or economically impossible to make a system entirely reliable. As a result, system designers have to deal with probabilistic specifications such as “the probability that this component fails at this point of its behavior is less than or equal to 10-4 ”. More generally, uncertainty in the observed behavior is introduced by abstraction of black-box — or simply too complex — behavior of components, the environment, or the execution platform.

In [26] , we have introduced a framework for the design of correct systems from probabilistic, interacting components. To model components, we adopt the discrete time Interactive Markov Chain (IMC) semantic model [70] , which combines Labeled Transition System (LTS) and Markov Chain. Components communicate through interactions, that is, synchronized action transitions. Interactions are essential in component frameworks, as they allow the modeling of how components cooperate and communicate. We use the BIP framework [5] to model interactions between components.

Since the deploying context of a component is not known at design time, we use probabilistic contracts to specify and reason about correct behaviors of a component. Contracts allow us to specify what a component can expect from its context, what it must guarantee, and explicitly limit the responsibilities of both.

The framework we have proposed allows us to model components, their interactions, and uncertainty in their observed behavior. It supports different steps in a design flow: refinement and abstraction, parallel composition, and conjunction (shared refinement). We have proved that these operations satisfy the desired properties of independent implementability and congruence for parallel composition, and soundness for conjunction. Thus,

Causality Analysis in Contract Violation

Establishing liabilities in case of litigation is generally a delicate matter. It becomes even more challenging when IT systems are involved. Generally speaking, a party can be declared liable for a damage if a fault can be attributed to that party and that fault has caused the damage. The two key issues are thus to establish convincing evidence with respect to (1) the occurrence of the fault and (2) the causality relation between the fault and the damage. The first issue concerns the technique used to log the relevant events of the system and to ensure that the logs can be produced (and have some value) in court. The second issue is especially complex when several faults are detected in the logs and the impact of these faults on the occurrence of the failure has to be assessed. In [6] we have focused on this second issue and proposed a formal framework for reasoning about causality. A system based on this framework could be used to provide relevant information to the expert, the judge, or the parties themselves (in case of amicable settlement) to analyze the origin of the failure of an IT system.

The notion of causality has been studied for a long time in computer science, but with very different perspectives and goals. In the distributed systems community, causality (following Lamport's seminal paper [75] ) is seen essentially as a temporal property. In our context, the temporal ordering contributes to the analysis, but it is obviously not sufficient to establish the logical causality required to rule on a matter of liability: the fact that an event e1 has occurred before an event e2 does not imply that e1 was the cause for e2 (or that e2 would not have occurred if e1 had not occurred).

Our formal model is based on components interacting according to well identified interaction models [5] . Each component is associated with an individual contract which specifies its expected behavior. The system itself is associated with a global contract which is assumed to be implied by the composition of the individual contracts.

We have defined several variants of logical causality. The first variant, necessary causality, characterizes cases when the global contract would not have been violated if the local contract had been fulfilled. The second variant, sufficient causality, characterizes cases when the global contract would have been violated even if all the other components had fulfilled their contracts. In other words, the violation of its contract by a single component was sufficient to violate the global contract.

We have further shown that our definitions of causality are decidable in the introduced setting. We have also provided conditions for decidability on trace suffixes. Such a possibility is of great practical significance because it makes it possible to analyze traces back to a given point in the past. Indeed, the analysis of liability in real cases can hardly assume that all traces of the past can always be produced and analyzed.

In order to be able to trace the propagation of faults, we have defined horizontal causality, which relates prefixes of local traces of components on the same level of hierarchy. Horizontal causality allows to analyze causality among violations of component contracts.

This work opens a number of new directions for further research, in particular, the generalization to different models of communication, and to a setting where the result of causality analysis is not Boolean but a probability.

This research has been conducted as part of the LISE project on liability issues in software engineering [29] .


Logo Inria