D32 Scalability: Difference between revisions

From Event-B
Jump to navigationJump to search
imported>Ilya.lopatkin
imported>Tommy
mNo edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Overview ===
= Overview =
Regarding scalability of the Rodin platform, the following contributions has been made:
Regarding scalability of the Rodin platform, the following contributions has been made:


Line 10: Line 10:
* Emre Yilmaz and Thai Son Hoang (ETH Zurich) has developed a plug-in supporting an extension of Event-B with qualitative reasoning. The extension allows developer to declare an event converges probabilistically (with probability 1). This is in contrast with standard certain termination, where convergent events ''must decrease'' the declared variant. Provided that the variant is bounded above, an event probabilistically converges if it ''might decrease'' the variant. The extension enables Event-B to model systems with ''almost certain termination'' properties, e.g. IEEE 1394 Firewire protocol<ref name="ieee1394">J.-R. Abrial, D. Cansell, D. Mery.  A Mechanically Proved and Incremental Development of IEEE 1394 Tree Identify Protocol. ''Formal Asp. of Comput.'' 14(3):215-227, 2003</ref> or Rabin's Choice Coordination algorithm <ref name="rabin">M. Rabin. The Choice Coordination Problem. ''Acta Informatica, 17:121-134'', 1982.</ref>.
* Emre Yilmaz and Thai Son Hoang (ETH Zurich) has developed a plug-in supporting an extension of Event-B with qualitative reasoning. The extension allows developer to declare an event converges probabilistically (with probability 1). This is in contrast with standard certain termination, where convergent events ''must decrease'' the declared variant. Provided that the variant is bounded above, an event probabilistically converges if it ''might decrease'' the variant. The extension enables Event-B to model systems with ''almost certain termination'' properties, e.g. IEEE 1394 Firewire protocol<ref name="ieee1394">J.-R. Abrial, D. Cansell, D. Mery.  A Mechanically Proved and Incremental Development of IEEE 1394 Tree Identify Protocol. ''Formal Asp. of Comput.'' 14(3):215-227, 2003</ref> or Rabin's Choice Coordination algorithm <ref name="rabin">M. Rabin. The Choice Coordination Problem. ''Acta Informatica, 17:121-134'', 1982.</ref>.


=== Motivations ===
= Motivations =


==== Flow plug-in ====
== Flow plug-in ==
The flows tool was applied by Bosch in the development of the cruise control model to verify deadlock-freedom and liveness properties of the model. Being a sizable case-study, this was an important test for the ideas and techniques behind the plug-in. The general conclusion was that a tool of this kind is essential and the current version should be improved in many directions. This experience has uncovered a rather fundamental issues with the size and complexity of the generated proof obligations. These were the largest theorems ever generated in Rodin and the only positive aspect is that this helped to stress-test and debug the proof handling facilities of the Rodin. It was clear that such proof obligations can never be comfortably handled by Rodin tools (although there were some encouraging results in the application of ProB as a disprover for these kind of proofs) and it was decided that the approach to proof generation requires a complete redesign.  
The flows tool was applied by Bosch in the development of the cruise control model to verify deadlock-freedom and liveness properties of the model. Being a sizable case-study, this was an important test for the ideas and techniques behind the plug-in. The general conclusion was that a tool of this kind is essential and the current version should be improved in many directions. This experience has uncovered a rather fundamental issues with the size and complexity of the generated proof obligations. These were the largest theorems ever generated in Rodin and the only positive aspect is that this helped to stress-test and debug the proof handling facilities of the Rodin. It was clear that such proof obligations can never be comfortably handled by Rodin tools (although there were some encouraging results in the application of ProB as a disprover for these kind of proofs) and it was decided that the approach to proof generation requires a complete redesign.  


==== Group Refinement ====
== Group Refinement ==
One of the project industrial partners (Bosch) has identified a recurring refinement pattern that did not fit well the existing laws of refinement. It is a case of atomicity refinement where a previously atomic action (event) is split into a number of steps which combined effect achieves the effect of the abstract atomic event. The Event-B approach is to introduce new variables in a refinement machine and thus have a hidden concrete state on which the steps are defined. There is a further event summarising the effect of the computations accomplished on the hidden state and explicitly relating it to the abstract state. This is the event for which the refinement relation is demonstrated while the events defining the actual computation steps would have no formal link to the abstract event.
One of the project industrial partners (Bosch) has identified a recurring refinement pattern that did not fit well the existing laws of refinement. It is a case of atomicity refinement where a previously atomic action (event) is split into a number of steps which combined effect achieves the effect of the abstract atomic event. The Event-B approach is to introduce new variables in a refinement machine and thus have a hidden concrete state on which the steps are defined. There is a further event summarising the effect of the computations accomplished on the hidden state and explicitly relating it to the abstract state. This is the event for which the refinement relation is demonstrated while the events defining the actual computation steps would have no formal link to the abstract event.


When the hidden state does not naturally follow as a part of the modelling process this refinement style leads to a contrived model. There appear auxiliary variables and auxiliary events that play no part in the characterisation of the system behaviour but are a codification of the refinement relation to an abstract model. Since such elements accumulate during refinement this has a profound effect on the development of a large model.  
When the hidden state does not naturally follow as a part of the modelling process this refinement style leads to a contrived model. There appear auxiliary variables and auxiliary events that play no part in the characterisation of the system behaviour but are a codification of the refinement relation to an abstract model. Since such elements accumulate during refinement this has a profound effect on the development of a large model.  


==== Modes ====
== Modes ==
We have conducted a study of approaches to complex critical systems development, and the requirements documents within DEPLOY, and arrived at the following:
We have conducted a study of approaches to complex critical systems development, and the requirements documents within DEPLOY, and arrived at the following:
* Separation of concerns is a major approach to tackle the complexity of the systems development.
* Separation of concerns is a major approach to tackle the complexity of the systems development.
Line 36: Line 36:
* Provide consistent way of stepwise development of mode and FT aspects by a notion of views refinement.
* Provide consistent way of stepwise development of mode and FT aspects by a notion of views refinement.


==== Qualitative Reasoning ====
== Qualitative Reasoning ==
Probability is used in many distributed systems for breaking the symmetry between different components/processes, e.g. IEEE 1394 Firewire protocol <ref name="ieee1394"/>, Rabin Choice Coordination algorithm <ref name="rabin"/>. For such systems, termination cannot be guaranteed for certain. Instead, a slightly weaker property is mostly appropriate: ''termination with probability one''. As an example for this type of systems is to consider tossing a coin until it comes up tail. Provided that the coin is fair (in that sense that no face is ignored forever), eventually, the coin will eventually come up head.
Probability is used in many distributed systems for breaking the symmetry between different components/processes, e.g. IEEE 1394 Firewire protocol <ref name="ieee1394"/>, Rabin Choice Coordination algorithm <ref name="rabin"/>. For such systems, termination cannot be guaranteed for certain. Instead, a slightly weaker property is mostly appropriate: ''termination with probability one''. As an example for this type of systems is to consider tossing a coin until it comes up tail. Provided that the coin is fair (in that sense that no face is ignored forever), eventually, the coin will eventually come up head.


Line 43: Line 43:
The plug-in allows developers to declare an event to be probabilistic convergent and generate appropriate proof obligations. Since the obligations are in standard first-order logic supported by the Rodin platform, we do not need to make any extension for the provers to handle the new proof obligations.
The plug-in allows developers to declare an event to be probabilistic convergent and generate appropriate proof obligations. Since the obligations are in standard first-order logic supported by the Rodin platform, we do not need to make any extension for the provers to handle the new proof obligations.


=== Choices/Decisions ===
= Choices/Decisions =


==== Flow plug-in ====
== Flow plug-in ==
The single most important feature of the new version of the Flows plug-in is the introduction of a new form of diagram structuring to prevent the appearance of large proof obligations. The typical source of such proof obligations is demonstrating that an event enables one or more events from a long list of events. Technically, the proof would state that the after-state of the event implies the disjunction of the guards of the next events. To prevent the appearance of such a disjunction a modeller is encouraged to split the list into a set of sub-models. Each sub-model has a pre- and post-conditions and there are proof obligations demonstrating that all the entry events of the sub-model are enabled when the precondition is satisfied and, symmetrically, every exit event satisfies the sub-model post-condition. Externally, a sub-model appears to be a simple atomic event.  
The single most important feature of the new version of the Flows plug-in is the introduction of a new form of diagram structuring to prevent the appearance of large proof obligations. The typical source of such proof obligations is demonstrating that an event enables one or more events from a long list of events. Technically, the proof would state that the after-state of the event implies the disjunction of the guards of the next events. To prevent the appearance of such a disjunction a modeller is encouraged to split the list into a set of sub-models. Each sub-model has a pre- and post-conditions and there are proof obligations demonstrating that all the entry events of the sub-model are enabled when the precondition is satisfied and, symmetrically, every exit event satisfies the sub-model post-condition. Externally, a sub-model appears to be a simple atomic event.


 
== Group Refinement ==
==== Group Refinement ====
In this work one obvious source of inspiration is the Classical B method <ref name="bbook">J. R. Abrial. The B-Book: Assigning Programs to Meanings</ref>where an abstract atomic statement may be refined into an operation which body is made of a sequence of assignments. However, the introduction of the semicolon operator in Event-B is a substantial change affecting most aspects of the method. This would also reintroduce one of the problems of the Classical B that Event-B tries to address: proof scalability. Accumulation of sequential composition through refinement steps may result in unmanageable proof obligations. It is also more difficult to conduct subsequent refinement of events with sequential actions.
In this work one obvious source of inspiration is the Classical B method <ref name="bbook">J. R. Abrial. The B-Book: Assigning Programs to Meanings</ref>where an abstract atomic statement may be refined into an operation which body is made of a sequence of assignments. However, the introduction of the semicolon operator in Event-B is a substantial change affecting most aspects of the method. This would also reintroduce one of the problems of the Classical B that Event-B tries to address: proof scalability. Accumulation of sequential composition through refinement steps may result in unmanageable proof obligations. It is also more difficult to conduct subsequent refinement of events with sequential actions.


Line 58: Line 57:
The method is not limited to sequential composition and there is also a form of parallel composition. An essential property of the method is that the group refinement relation is demonstrated not just for a single arrangement of concrete events but for a whole set of traces of concrete events. There is a simple notation for the removal of undesired traces and constraining the model to specific traces. For each trace there appears one instance of action simulation proof obligation (and possibly other refinement and consistency proof obligations). Thus, for practical reasons, it is necessary to keep number of traces low. This is best accomplished by doing small refinement steps with few concrete events.  
The method is not limited to sequential composition and there is also a form of parallel composition. An essential property of the method is that the group refinement relation is demonstrated not just for a single arrangement of concrete events but for a whole set of traces of concrete events. There is a simple notation for the removal of undesired traces and constraining the model to specific traces. For each trace there appears one instance of action simulation proof obligation (and possibly other refinement and consistency proof obligations). Thus, for practical reasons, it is necessary to keep number of traces low. This is best accomplished by doing small refinement steps with few concrete events.  


==== Modes ====
== Modes ==
We have conducted a study of approaches to complex critical systems development, and the requirements documents within DEPLOY, and arrived at the following:
The main objective in the tool design was to make a simple to use environment that can be used by a non-Event-B user (e.g. requirements engineer, fault tolerance specialist), yet provides the necessary functionality for an Event-B modeller. The tool was designed to be as much an external environment to Event-B models as possible.
* Separation of concerns is a major approach to tackle the complexity of the systems development.
* We decided not to extend the Rodin database with modal and fault tolerance elements and to keep them as separate models. This led to less platform dependencies and easier maintenance.
* A large amount of critical systems are developed using a notion of operation modes.
* The static check is separated from the Rodin SC, and realized by the GMF validation since it does not logically belong to Rodin / Event-B. However, since the proofs are a part of the modelling process, we properly extended the Rodin proof obligation generator.
* All critical systems involve operations with important aspects of human activity (e.g. lives, finance) hence critical. And all of them inevitably have faults due to changing environmental conditions, hardware failures etc. A high percentage of requirements to such systems (up to 40% according to our study within DEPLOY) include fault tolerance as a way to mitigate the consequences of errors.
* A modal/FT documents form a refinement chain that mimics the Event-B refinement. This allows our tool to be used with the existing types of decomposition / modularisation.
* Requirements evolve, including FT.
* During the initial experiments we have identified a possible need for multiple views on a single model. The tool supports this by keeping the references to the models in the views and not the opposite.
 
There were neither mode nor fault tolerance viewpoints in the state of the art Event-B development. The UML-B approach of statecharts is closely related to modal views. However, the statecharts drive the development by generating Event-B models as opposed to the mode views which facilitate the development by leaving the Event-B modelling activity with the user. On the fault tolerance side, we are aware of the work on ProR framework for tracing requirements, and we plan to integrate the tracing framework with our modelling approach.
 
The Mode/FT Views approach is to assist the main Event-B development by an additional set of abstractions and a toolset to facilitate modal and fault tolerance development. We were motivated by the following stimuli:
* Facilitate the modal and fault tolerance development in Event-B with a comprehensible modelling approach.
* Stimulate the consideration of fault tolerance at the very first phases of development.
* Explicitly covering mode and fault tolerance concerns, we wanted to improve the requirement traceability and fulfilment.
* Help make planning decisions. Focusing the developer attention on specific aspects of development leads to better understanding of the problem and planning of the solution.
* Provide consistent way of stepwise development of mode and FT aspects by a notion of views refinement.


==== Qualitative Reasoning ====
== Qualitative Reasoning ==
* Ideally, we would like to have a new value for the '''convergence''' attribute of Event-B events.  However, this is not currently supported by the Rodin platform.  Instead, a new '''probabilistic''' attribute is defined for events, with the value is either ''standard'' or ''probabilistic''.
* Ideally, we would like to have a new value for the '''convergence''' attribute of Event-B events.  However, this is not currently supported by the Rodin platform.  Instead, a new '''probabilistic''' attribute is defined for events, with the value is either ''standard'' or ''probabilistic''.


Line 85: Line 75:
More details of our approach is in our report at AVoCS'10 <ref name="avocs10">[http://deploy-eprints.ecs.soton.ac.uk/258/ E. Yilmaz and T.S. Hoang, Development of Rabin's Choice Coordination Algorithm in Event-B. ''Proceedings of AVoCS'10'', Dusseldorf, Germany, 2010]</ref>.
More details of our approach is in our report at AVoCS'10 <ref name="avocs10">[http://deploy-eprints.ecs.soton.ac.uk/258/ E. Yilmaz and T.S. Hoang, Development of Rabin's Choice Coordination Algorithm in Event-B. ''Proceedings of AVoCS'10'', Dusseldorf, Germany, 2010]</ref>.


=== Available Documentation ===
= Available Documentation =


==== Flow plug-in ====
== Flow plug-in ==
* An extensive example of the application of the flows in the modelling (the old version) is available to the DEPLOY Project members as a part of the Bosch cruise control case study.
* An extensive example of the application of the flows in the modelling (the old version) is available to the DEPLOY Project members as a part of the Bosch cruise control case study.
* There is a wiki page describing the core proof obligations generated by the tool - Flows
* There is a wiki page describing the core proof obligations generated by the tool - Flows
* Tutorial slides available from the project file share  
* Tutorial slides available from the project file share  


==== Group Refinement ====
== Group Refinement ==
* There is a wiki page - [[Group refinement plugin]] - briefly introducing the approach and the tool
* There is a wiki page<ref name="grp">http://wiki.event-b.org/index.php/Group_refinement_plugin</ref> briefly introducing the approach and the tool
* Slides
* Slides


==== Qualitative Reasoning ====
== Modes ==
* There is a wiki page<ref>http://wiki.event-b.org/index.php/Mode/FT_Views</ref> with details of the plug-in functionality, installation guide, and a simple example.
* Papers on modal specifications <ref>[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.6369&rep=rep1&type=pdf A.Iliasov, A.Romanovsky, F.L.Dotti. Structuring Specifications with Modes. Fourth Latin-American Symposium on Dependable Computing - LADC 09, September 1-4, 2009]</ref> and <ref>[http://deploy-eprints.ecs.soton.ac.uk/153/1/paper105%2DICFEM09.pdf F.L.Dotti, A.Iliasov, L.Riberiro, A.Romanovsky. Modal Systems: Specification, Refinement and Realisation. In: International Conference on Formal Engineering Methods - ICFEM 09 , December 9 -12, 2009, Rio de Janeiro, Brazil]</ref>, and fault tolerance <ref>[http://www.cs.ncl.ac.uk/publications/trs/papers/1188.pdf I.Lopatkin, A.Iliasov, A.Romanovsky. On Fault Tolerance Reuse during Refinement. In: 2nd International Workshop on Software Engineering for Resilient Systems - SERENE 2010, April 13-16, 2010, London]</ref>.
* Also, we are working on a medium-scale case study
 
== Qualitative Reasoning ==
* Master thesis of Emre Yilmaz on developing tool support for qualitative reasoning in Event-B <ref>[http://e-collection.ethbib.ethz.ch/view/eth:1677  E. Yilmaz. Tool support for qualitative reasoning in Event-B. Master's thesis, Department of Computer Science, ETH Zurich, Switzerland, Aug. 2010]</ref>.
* Master thesis of Emre Yilmaz on developing tool support for qualitative reasoning in Event-B <ref>[http://e-collection.ethbib.ethz.ch/view/eth:1677  E. Yilmaz. Tool support for qualitative reasoning in Event-B. Master's thesis, Department of Computer Science, ETH Zurich, Switzerland, Aug. 2010]</ref>.


Line 103: Line 98:
* A paper describing the development of Rabin Choice Coordination algorithm and tool support in the Proceedings of AVoCS'10 <ref name="avocs10"/>.
* A paper describing the development of Rabin Choice Coordination algorithm and tool support in the Proceedings of AVoCS'10 <ref name="avocs10"/>.


=== Planning ===
= Planning =


==== Flow plug-in ====
== Flow plug-in ==
The plan is to gather feedback from the users within the Project and encourage the external users to try out the plug-in and provide feedback and feature requests. There are many ideas on the tool extension, in particular using the tool to document event refinement (split, merge, group, refinement diagrams) and provide mechanised patterns for some of the more important cases.  
The plan is to gather feedback from the users within the Project and encourage the external users to try out the plug-in and provide feedback and feature requests. There are many ideas on the tool extension, in particular using the tool to document event refinement (split, merge, group, refinement diagrams) and provide mechanised patterns for some of the more important cases.  


==== Group Refinement ====
== Group Refinement ==
The immediate plan is to produce a technical report on the semantics of group refinement during the first quarter of 2011. Long term plans are the tool maintenance and the investigation of the possibility of more expressive form of group refinement permitting branches and loops.  
The immediate plan is to produce a technical report on the semantics of group refinement during the first quarter of 2011. Long term plans are the tool maintenance and the investigation of the possibility of more expressive form of group refinement permitting branches and loops.  


==== Modes ====
== Modes ==
(Ilya)
Current status is version 1.0.0 for Rodin 2.0
In a long term we plan:
* A few usability improvements
* Integration with ProR requirements tracing framework
* Event-B model generation and editing driven by FT patterns


==== Qualitative Reasoning ====
== Qualitative Reasoning ==
In DEPLOY's fourth year, we plan to implement the missing proof obligations. More importantly, we will investigate the interaction between refinement and almost certain termination. This allows us to prove convergence properties early in the development and guarantee that refinement will maintain these convergent properties.
In DEPLOY's fourth year, we plan to implement the missing proof obligations. More importantly, we will investigate the interaction between refinement and almost certain termination. This allows us to prove convergence properties early in the development and guarantee that refinement will maintain these convergent properties.


=== References ===
== References ==
<references/>
<references/>


[[Category:D32 Deliverable]]
[[Category:D32 Deliverable]]
[[Category:Books]]

Latest revision as of 15:28, 27 January 2011

Overview

Regarding scalability of the Rodin platform, the following contributions has been made:

  • Flows plug-in development. The main purpose of the Flows plug-in [1] is to give a modeller a clean and concise view of the control flow aspects of a model without cluttering the model with program counter variables and associated guards and actions. The plug-in is essentially a graphical notation for formulating certain kind of theorems. The new version is to be released in February 2011 and this will include facilities for expressing a wider range of enabledness properties as well as tools for describing event refinement. It is going to address one of the critical shortcomings of the previous version: generation of unwieldy proof obligations (a large disjunction in a goal comprising several hundreds of terms). The tool is developed by Newcastle University with the requirements and suggestions from Bosch and SAP.
  • Group Refinement. Group refinement plug-in is a tool realising an alternative set of Event-B refinement laws in the Rodin platform. It lets a modeller to switch to differing style of event atomicity refinement for the scope of a single refinement steps. For a certain case of atomicity refinement the alternative laws result in a more natural and compact model with fewer and simpler proof obligations. The method and the tool were development by Newcastle University, the pattern of refinement was discovered by the Bosch formal modelling team.
  • Modes. The Mode and Fault Tolerance Views plug-in is a modelling environment for constructing modal and fault tolerance features in a concise manner and formally linking them to Event-B models. As many systems are developed using the notion of operation modes, the tool allows to separate the modal modelling as a refinement chain from the main Event-B models. This makes possible to model explicitly modal behaviour and certain fault tolerance aspects of systems and formally show the consistency between the models and their views. The theory and plug-in were developed by Newcastle University.
  • Emre Yilmaz and Thai Son Hoang (ETH Zurich) has developed a plug-in supporting an extension of Event-B with qualitative reasoning. The extension allows developer to declare an event converges probabilistically (with probability 1). This is in contrast with standard certain termination, where convergent events must decrease the declared variant. Provided that the variant is bounded above, an event probabilistically converges if it might decrease the variant. The extension enables Event-B to model systems with almost certain termination properties, e.g. IEEE 1394 Firewire protocol[2] or Rabin's Choice Coordination algorithm [3].

Motivations

Flow plug-in

The flows tool was applied by Bosch in the development of the cruise control model to verify deadlock-freedom and liveness properties of the model. Being a sizable case-study, this was an important test for the ideas and techniques behind the plug-in. The general conclusion was that a tool of this kind is essential and the current version should be improved in many directions. This experience has uncovered a rather fundamental issues with the size and complexity of the generated proof obligations. These were the largest theorems ever generated in Rodin and the only positive aspect is that this helped to stress-test and debug the proof handling facilities of the Rodin. It was clear that such proof obligations can never be comfortably handled by Rodin tools (although there were some encouraging results in the application of ProB as a disprover for these kind of proofs) and it was decided that the approach to proof generation requires a complete redesign.

Group Refinement

One of the project industrial partners (Bosch) has identified a recurring refinement pattern that did not fit well the existing laws of refinement. It is a case of atomicity refinement where a previously atomic action (event) is split into a number of steps which combined effect achieves the effect of the abstract atomic event. The Event-B approach is to introduce new variables in a refinement machine and thus have a hidden concrete state on which the steps are defined. There is a further event summarising the effect of the computations accomplished on the hidden state and explicitly relating it to the abstract state. This is the event for which the refinement relation is demonstrated while the events defining the actual computation steps would have no formal link to the abstract event.

When the hidden state does not naturally follow as a part of the modelling process this refinement style leads to a contrived model. There appear auxiliary variables and auxiliary events that play no part in the characterisation of the system behaviour but are a codification of the refinement relation to an abstract model. Since such elements accumulate during refinement this has a profound effect on the development of a large model.

Modes

We have conducted a study of approaches to complex critical systems development, and the requirements documents within DEPLOY, and arrived at the following:

  • Separation of concerns is a major approach to tackle the complexity of the systems development.
  • A large amount of critical systems are developed using a notion of operation modes.
  • All critical systems involve operations with important aspects of human activity (e.g. lives, finance) hence critical. And all of them inevitably have faults due to changing environmental conditions, hardware failures etc. A high percentage of requirements to such systems (up to 40% according to our study within DEPLOY) include fault tolerance as a way to mitigate the consequences of errors.
  • Requirements evolve, including FT.

There were neither mode nor fault tolerance viewpoints in the state of the art Event-B development. The UML-B approach of statecharts is closely related to modal views. However, the statecharts drive the development by generating Event-B models as opposed to the mode views which facilitate the development by leaving the Event-B modelling activity with the user. On the fault tolerance side, we are aware of the work on ProR framework for tracing requirements, and we plan to integrate the tracing framework with our modelling approach.

The Mode/FT Views approach is to assist the main Event-B development by an additional set of abstractions and a toolset to facilitate modal and fault tolerance development. We were motivated by the following stimuli:

  • Facilitate the modal and fault tolerance development in Event-B with a comprehensible modelling approach.
  • Stimulate the consideration of fault tolerance at the very first phases of development.
  • Explicitly covering mode and fault tolerance concerns, we wanted to improve the requirement traceability and fulfilment.
  • Help make planning decisions. Focusing the developer attention on specific aspects of development leads to better understanding of the problem and planning of the solution.
  • Provide consistent way of stepwise development of mode and FT aspects by a notion of views refinement.

Qualitative Reasoning

Probability is used in many distributed systems for breaking the symmetry between different components/processes, e.g. IEEE 1394 Firewire protocol [2], Rabin Choice Coordination algorithm [3]. For such systems, termination cannot be guaranteed for certain. Instead, a slightly weaker property is mostly appropriate: termination with probability one. As an example for this type of systems is to consider tossing a coin until it comes up tail. Provided that the coin is fair (in that sense that no face is ignored forever), eventually, the coin will eventually come up head.

Qualitative probabilistic reasoning has been integrated into Event-B [4]: a new kind of actions is added, namely probabilistic actions with an assumption that the probability for each possible alternative is bounded away from 0 or 1. Most of the time, probabilistic actions behave the same as (standard) non-deterministic actions (e.g. invariant preservation). The difference between probabilistic and non-deterministic actions is with convergence proof obligation: probabilistic actions are interpreted angelically, whereas non-deterministic actions are interpreted demonically. The result is a practical method for handling qualitative reasoning that generates proof obligations in the standard first-order logic of Event-B.

The plug-in allows developers to declare an event to be probabilistic convergent and generate appropriate proof obligations. Since the obligations are in standard first-order logic supported by the Rodin platform, we do not need to make any extension for the provers to handle the new proof obligations.

Choices/Decisions

Flow plug-in

The single most important feature of the new version of the Flows plug-in is the introduction of a new form of diagram structuring to prevent the appearance of large proof obligations. The typical source of such proof obligations is demonstrating that an event enables one or more events from a long list of events. Technically, the proof would state that the after-state of the event implies the disjunction of the guards of the next events. To prevent the appearance of such a disjunction a modeller is encouraged to split the list into a set of sub-models. Each sub-model has a pre- and post-conditions and there are proof obligations demonstrating that all the entry events of the sub-model are enabled when the precondition is satisfied and, symmetrically, every exit event satisfies the sub-model post-condition. Externally, a sub-model appears to be a simple atomic event.

Group Refinement

In this work one obvious source of inspiration is the Classical B method [5]where an abstract atomic statement may be refined into an operation which body is made of a sequence of assignments. However, the introduction of the semicolon operator in Event-B is a substantial change affecting most aspects of the method. This would also reintroduce one of the problems of the Classical B that Event-B tries to address: proof scalability. Accumulation of sequential composition through refinement steps may result in unmanageable proof obligations. It is also more difficult to conduct subsequent refinement of events with sequential actions.

Actions Systems [6]has an atomicity refinement technique where one can refine an atomic action into a loop of new actions[7]. This is general enough to address the problem but, seemingly, the associated proof cost is prohibitively high and there is no evidence that such proofs may be efficiently mechanised.

The challenge was addressed by offering a method that lets a modeller to select an alternative set of refinement laws whenever the identified pattern of refinement is encountered. The new refinement laws are based on a different interpretation of a model: split refinement (a case of event refinement when an abstract event is refined into two or more concrete alternatives) is understood as a refinement into a composite event made of the concrete events arranged in some way. One simple arrangement case is when the concrete events are understood to execute sequentially. Then the refinement relation is demonstrated for the after-state produced by executing one event after another.

The method is not limited to sequential composition and there is also a form of parallel composition. An essential property of the method is that the group refinement relation is demonstrated not just for a single arrangement of concrete events but for a whole set of traces of concrete events. There is a simple notation for the removal of undesired traces and constraining the model to specific traces. For each trace there appears one instance of action simulation proof obligation (and possibly other refinement and consistency proof obligations). Thus, for practical reasons, it is necessary to keep number of traces low. This is best accomplished by doing small refinement steps with few concrete events.

Modes

The main objective in the tool design was to make a simple to use environment that can be used by a non-Event-B user (e.g. requirements engineer, fault tolerance specialist), yet provides the necessary functionality for an Event-B modeller. The tool was designed to be as much an external environment to Event-B models as possible.

  • We decided not to extend the Rodin database with modal and fault tolerance elements and to keep them as separate models. This led to less platform dependencies and easier maintenance.
  • The static check is separated from the Rodin SC, and realized by the GMF validation since it does not logically belong to Rodin / Event-B. However, since the proofs are a part of the modelling process, we properly extended the Rodin proof obligation generator.
  • A modal/FT documents form a refinement chain that mimics the Event-B refinement. This allows our tool to be used with the existing types of decomposition / modularisation.
  • During the initial experiments we have identified a possible need for multiple views on a single model. The tool supports this by keeping the references to the models in the views and not the opposite.

Qualitative Reasoning

  • Ideally, we would like to have a new value for the convergence attribute of Event-B events. However, this is not currently supported by the Rodin platform. Instead, a new probabilistic attribute is defined for events, with the value is either standard or probabilistic.
  • Since standard refinement does not maintain probabilistic convergent property, we put a restriction on the development method for almost-certain termination systems in two steps as follows.
    1. Establish the model of the systems with various anticipated events
    2. While proving convergence properties of events (either standard or probabilistic), we keep the variable and event system the same (i.e. no refinement is allowed).
  • For probabilistic convergence, the variant need to be bounded above. A combination of standard and probabilistic convergence events results in a probabilistic convergence system. Moreover, the use of anticipated events and refinement allowed us to construct an lexicographic variant by combining the sub-variant at different level of refinements. For probabilistic convergence system, this lexicographic variant need to be bounded above, which require all the sub-variants to be bounded above (not only those variant concern with probabilistic events).

More details of our approach is in our report at AVoCS'10 [8].

Available Documentation

Flow plug-in

  • An extensive example of the application of the flows in the modelling (the old version) is available to the DEPLOY Project members as a part of the Bosch cruise control case study.
  • There is a wiki page describing the core proof obligations generated by the tool - Flows
  • Tutorial slides available from the project file share

Group Refinement

  • There is a wiki page[9] briefly introducing the approach and the tool
  • Slides

Modes

  • There is a wiki page[10] with details of the plug-in functionality, installation guide, and a simple example.
  • Papers on modal specifications [11] and [12], and fault tolerance [13].
  • Also, we are working on a medium-scale case study

Qualitative Reasoning

  • Master thesis of Emre Yilmaz on developing tool support for qualitative reasoning in Event-B [14].
  • The development of Rabin's Choice Coordination Algorithm is available at the DEPLOY Repository [15].
  • A paper describing the development of Rabin Choice Coordination algorithm and tool support in the Proceedings of AVoCS'10 [8].

Planning

Flow plug-in

The plan is to gather feedback from the users within the Project and encourage the external users to try out the plug-in and provide feedback and feature requests. There are many ideas on the tool extension, in particular using the tool to document event refinement (split, merge, group, refinement diagrams) and provide mechanised patterns for some of the more important cases.

Group Refinement

The immediate plan is to produce a technical report on the semantics of group refinement during the first quarter of 2011. Long term plans are the tool maintenance and the investigation of the possibility of more expressive form of group refinement permitting branches and loops.

Modes

Current status is version 1.0.0 for Rodin 2.0 In a long term we plan:

  • A few usability improvements
  • Integration with ProR requirements tracing framework
  • Event-B model generation and editing driven by FT patterns

Qualitative Reasoning

In DEPLOY's fourth year, we plan to implement the missing proof obligations. More importantly, we will investigate the interaction between refinement and almost certain termination. This allows us to prove convergence properties early in the development and guarantee that refinement will maintain these convergent properties.

References

  1. A. Iliasov. Augmenting Event-B Specifications with Control Flow Information. Nodes 2010. Copenhagen June 3-4 2010, Technical University of Denmark
  2. 2.0 2.1 J.-R. Abrial, D. Cansell, D. Mery. A Mechanically Proved and Incremental Development of IEEE 1394 Tree Identify Protocol. Formal Asp. of Comput. 14(3):215-227, 2003
  3. 3.0 3.1 M. Rabin. The Choice Coordination Problem. Acta Informatica, 17:121-134, 1982.
  4. S. Hallerstede, T.S. Hoang. Qualitative Probabilistic Modelling in Event-B. iFM 2007: Integrated Formal Methods, Oxford, U.K. July 2007
  5. J. R. Abrial. The B-Book: Assigning Programs to Meanings
  6. R.J.R. Back and R.Kurki-Suonio, Decentralization of process nets with centralized control. 2nd annual symposium on principles of distributed computing, Montreal 1983
  7. R.J.R. Back. Atomicity Refinement in a Refinement Calculus Framework (Back92:atomicity)
  8. 8.0 8.1 E. Yilmaz and T.S. Hoang, Development of Rabin's Choice Coordination Algorithm in Event-B. Proceedings of AVoCS'10, Dusseldorf, Germany, 2010
  9. http://wiki.event-b.org/index.php/Group_refinement_plugin
  10. http://wiki.event-b.org/index.php/Mode/FT_Views
  11. A.Iliasov, A.Romanovsky, F.L.Dotti. Structuring Specifications with Modes. Fourth Latin-American Symposium on Dependable Computing - LADC 09, September 1-4, 2009
  12. F.L.Dotti, A.Iliasov, L.Riberiro, A.Romanovsky. Modal Systems: Specification, Refinement and Realisation. In: International Conference on Formal Engineering Methods - ICFEM 09 , December 9 -12, 2009, Rio de Janeiro, Brazil
  13. I.Lopatkin, A.Iliasov, A.Romanovsky. On Fault Tolerance Reuse during Refinement. In: 2nd International Workshop on Software Engineering for Resilient Systems - SERENE 2010, April 13-16, 2010, London
  14. E. Yilmaz. Tool support for qualitative reasoning in Event-B. Master's thesis, Department of Computer Science, ETH Zurich, Switzerland, Aug. 2010
  15. E. Yilmaz. Rabin's Choice Coordination Development.