Abstract not found

. We introduce Oikos adtl, a specification language for distributed systems based on asynchronous communication via remote writings. The language is designed to support the composition of specifications. It allows expressing the global properties of a system in terms of the local properties of the components and of coordination patterns. Oikos adtl is based on an asynchronous, distributed, temporal logic, which extends Unity to deal with components and events. We present the specification language and its semantics, introduce a number of compositionality theorems, and discuss some coordination patterns. A fragment of a standard case study is used to validate pragmatically the approach, with respect to expressiveness and work-ability. 1 Introduction The design of quality software for distributed systems is becoming more and more critical, due to the current impact of software on every technical accomplishment, and the fact that networks pervade any current application. The p...

In order to increase the flexibility and performance of hydraulically actuated machines there is a demand for more intelligent controllers. This leads to a rapid increase in complexity of the control systems. To manage the complexity and to ensure reliability of these systems, adequate software development methods are needed. In this work, we propose a methodology for structured design of digital hydraulics controllers in Simulink/Stateflow. A model architecture based on mode-automata is introduced to separate control and data processing. Furthermore, design by contract is advocated as a method for system development. The contracts can be used to mathematically reason about correctness of Simulink/Stateflow models and thereby increase the safety and reliability of the developed systems. The usefulness of these concepts are demonstrated on a larger case study from the area of digital hydraulics.

The HOL Light theorem prover can be difficult to get started with. While the manual is fairly detailed and comprehensive, the large amount of background information that has to be absorbed before the user can do anything interesting is intimidating. Here we give an alternative ‘quick start ’ guide, aimed at teaching basic use of the system quickly by means of a graded set of examples. Some readers may find it easier to absorb; those who do not are referred after all to the standard manual. “Shouldn’t we read the instructions?”

This paper concerns the introduction of an iterator into the refinement calculus. The construct is based on concepts from functional programming, and the work gives an interesting example of cross-fertilisation between the functional and imperative programming worlds. Specifically, the iterator construct it..ti uses the idea of a catamorphism — the unique homomorphism from an initial algebra. The datatype for which the iterator is to be defined is considered as an initial algebra of an appropriate functor. The it..ti construct is formally defined as a recursive procedure, and it is shown that, if the value to be obtained by an iteration can be expressed as a catamorphism, then the it..ti construct provides a very natural implementation. Examples are given to show typical uses of the new construct. 1

Simulink is a popular tool for model-based development of control systems. However, due to the complexity caused by the increasing demand for sophisticated controllers, validation of Simulink models is becoming a more difficult task. To ensure correctness and reliability of large models, it is important to be able to reason about model parts and their interactions. This paper provides a definition of contracts and refinement using the action systems formalism. Contracts enable abstract specifications of model parts, while refinement offers a framework to reason about correctness of implementation of contracts, as well as composition of model parts. An example is provided to illustrate system development using contracts and refinement.

This paper reports on preliminary experiences with the theorem prover Isabelle [7], that we are evaluating as a candidate technology to build a designer's assistant for the development of mobile systems in Mob adtl

In [Hyv04b] we gave a denotational model whose core was the "trivial" relational model. The structure added on top of it was that of a predicate transformer. In the presence of atoms, this gave a non-trivial denotational model of full linear logic where proofs are interpreted by postfixed-points of the associated predicate transformer. We extend this model to # logic and then to full second-order. Contents 1 First order in a nutshell 2 1.1 Relations, predicate transformers and multisets . . . . . . . . . . 2 1.2 Interpreting formulas . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Interpreting proofs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Main result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 (linear) logic 5 2.1 Motivations and ideas . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 The state space, permutations and renaming . . . . . . . . . . . 6 2.2.1 State space: relational interpretation . . . . . . . . . . . . 6 2.2.2 Permutations . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 The model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Some examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 The empty type . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.2 The singleton type . . . . . . . . . . . . . . . . . . . . . . 9 2.4.3 The booleans . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.4 Linear booleans . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Interpreting open formulas 11 3.1 The relational model . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1 Preliminaries about injections . . . . . . . . . . . . . . . . 11 3.1.2 Stable functors . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.3 Trace of a stable functor . . . . . ....

Abstract not found

As embedded control systems are becoming more complex, there is a need for new software development and structuring techniques. The combination Simulink/Stateflow has become a popular tool for model-based design for this type of hybrid systems, due to the simulation and analysis tools available. To enable design and validation of large complex systems in Simulink/Stateflow, an appropriate model architecture is needed. Mode-automata is such an architecture, where control is strictly separated from signal processing. In this paper we give a formal definition of mode-automata in Simulink/Stateflow. This gives a precise definition of an architecture that restricts Simulink/Stateflow to a safe and easy to use subset that is easy to verify, but still usable in practice. We propose syntactic rules to check that a given Simulink/Stateflow model complies to our mode-automata architecture and we illustrate the approach with a controller for a digital hydraulics system.