Design Principles for Real-Time Process Control Systems

Report 94-42

Khalil Simaan

Faculteit der Technische Wiskunde en Informatica Faculty of Technical Mathematics and Informatics Technische Universiteit Delft Delft University of Technology

ISSN 0922-5641 Copyright c 1994 by the Faculty of Technical Mathematics and Informatics, Delft, The Netherlands. No part of this Journal may be reproduced in any form, by print, photoprint, microlm, or any other means without permission from the Faculty of Technical Mathematics and Informatics, Delft University of Technology, The Netherlands. Copies of these reports may be obtained from the bureau of the Faculty of Technical Mathematics and Informatics, Julianalaan 132, 2628 BL Delft, phone +3115784568. A selection of these reports is available in PostScript form at the Facultys anonymous ftp-site. They are located in the directory /pub/publications/tech-reports at ftp.twi.tudelft.nl

Designing Principles for Real-Time Process Control Systems

Khalil Sima'an Software Engineering Departement Faculty of Mathematics and Informatics Delft University of Technology 22-1-94
This report discusses a framework for formal requirements and design speci cation, and designing of Real-Time process Control systems (RTC-systems). The framework combines axiomatic with operational speci cation approaches for expressing respectively requirements and design. In addition, a design method is discussed and the principles and necessary instrumentation it assumes are identi ed and embedded in a notation based on ASTRAL 18]. This design method enables the incremental designing of total RTC-systems by interleaved application of top-down and bottom-up designing steps. Since the goal of the report is the identi cation of the principles, and since it does not concern any speci c subclass of RTC-systems' requirements speci cations, then the principles are kept as general as possible. When necessary, these general principles can be limited to any chosen subclass of these requirements speci cations.

Abstract

Contents

1 Introduction

1.1 Real-time Process-Control systems : : : : : : : : : : : : : : : : : : : : : : : : 1.2 Safety of RTC-systems : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1.3 This text : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

2
2 2 4

2 A framework for modeling, speci cation and designing

2.1 Modeling total systems : : : : : : : : : : : : : : : : : : : 2.2 Dual notation: Speci cation of requirements and design 2.2.1 Formal speci cation languages : : : : : : : : : : 2.3 A designing method : : : : : : : : : : : : : : : : : : : : 2.4 Usability of formal notations : : : : : : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

4
4 5 5 7 8

3 System designing

3.1 Bottom-up: Composition : : : : : : 3.2 Top-down: Stepwise-design : : : : : 3.2.1 Requirements speci cation : 3.2.2 The rst design speci cation 3.3 Implementation of design : : : : : : 3.4 The necessary design principles : : : 1

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

: : : : : :

9 10 12 14 14 17

4 Modeling, speci cation and designing principles

4.1 Introduction : : : : : : : : : : : : : : : : : : : 4.1.1 Notation : : : : : : : : : : : : : : : : : 4.2 Designing: Non-determinism and abstraction 4.3 Modeling: Closed system view : : : : : : : : : 4.3.1 Example : : : : : : : : : : : : : : : : : 4.4 Speci cation: Expressibility : : : : : : : : : : 4.4.1 Requirements speci cations : : : : : : 4.4.2 Example : : : : : : : : : : : : : : : : : 4.4.3 Design: Functional behavior : : : : : : 4.4.4 Examples : : : : : : : : : : : : : : : : 4.4.5 Design: Temporal constraints : : : : : 4.5 Designing: Decomposition and composition : 4.5.1 Example : : : : : : : : : : : : : : : : : 4.6 Designing: Re nement : : : : : : : : : : : : : 4.6.1 Example : : : : : : : : : : : : : : : : : 4.7 Designing: Separation of concerns : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

18

18 18 19 19 21 22 22 23 24 25 26 27 29 30 32 34

5 Discussion and last remarks 6 Acknowledgements A ASTRAL

A.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 38 A.2 Language Constructs : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 38

36 37 38

1 Introduction

1.1 Real-time Process-Control systems

Real-time process-control systems (RTC systems hereafter) are systems which consist of a physical-process and a control element, and possibly interact with the environment (e.g. a human user). The control part, implemented in a combination of hardware and software components, controls and directs the physical-process to achieve a certain desired behavior. Examples of physical-processes are nuclear plants, automatic-pilot driven airplanes and chemical factories. The RTC-systems considered here are large in detail and complex in behavior. The control element in these systems must communicate and interact with the physical-process (PP hereafter) which is working in parallel to it. The correctness of the PP's behavior depends on timing and on scheduling its actions correctly; this time-dependency constrains the system and makes its realization harder. A characteristic aspect of RTC-systems is the criticality of safety in their use (see the examples above). Safety can be implemented by introducing a controller which has the explicit function of directing the physical-process towards achieving the desired behavior. However, 2

1.2 Safety of RTC-systems

since it is not always possible to predict the environment and the physical-process, alarm and warning in case of malfunction are the implicit functions of this controller. Safety aspects of RTC-systems emphasize that the correctness of their behavior, rather than their e ciency, should be the primary concern of their designers and implementors. E ciency may be considered meaningless if the system fails and does not behave as required. The behavior's correctness should be guaranteed rst of all on the requirements and design level, before implementation takes place; needless to say, implementing wrong designs results in wrong systems. Moreover, generally speaking, the consequences of wrong designs are much more expensive (in terms of both lives and money) and are harder to correct than are the consequences of wrong implementation 49], 7]. This implies the need for assurances with respect to the correctness of designs. To achieve such correctness, designing must be a well understood process based on rigorous and reliable methods. A clear conclusion from these studies concerning the reasons for failure and catastrophe in RTC-systems, is that RTC-systems were and still are being designed using methods not adequate for the task. Inspection of various designs of systems which failed has found them to be incorrect with respect to the stated requirements. Moreover, requirements speci cations were often found to be ambiguous (incomplete so that various interpretations were possible) and inconsistent 7]. Mere stepwise and structured design did not eliminate these problems and could not provide the necessary guarantees of safety and correct behavior. Soon it became clear that this situation calls for more radical measures which provide some guarantees and assurances not provided by these designing methods. The main characteristic of the current speci cation and designing methods is informality, which implies the lack of unambiguous semantics (using mathematical systems) for their notations, which in its turn implies their inability to provide any guarantees or assurances with respect to the correctness of obtained designs. Without formality, design steps become unveri able with respect to requirements speci cations and the latter remain ambiguous and inconsistent. It is impossible to provide any guarantees without formalizing the specication and designing methods by basing them on formal notations and formal veri cation instrumentation. In this respect, I do not wish to imply that design processes are amenable to full formalization or that they should follow a recipe provided by a design method. After all, it is the human designer which makes design decisions and steps, based on heuristics and experience. Nevertheless, a design process should be supported by reliable design tools which are obtained by studying a certain model of design processes. If a designer applies such tools in a process of designing, then he should be able to predict the result of this application (i.e. he should be certain about the result). Thus, we study formal designing methods as models for design processes and expect such study to indicate what tools are necessary and when are they reliable. However, designing is generally preceded by both modeling and requirements speci cation. If the tools used to achieve the last two are not reliable then the resulting formal designs are not useful. Such designs might be based on unsuitable models and the requirements from the system might be wrong or incomplete. Therefore, it is also necessary to have a suitable modeling strategy and a formal requirements speci cation language. At this point it became clear that it is necessary to have a framework in which suitable modeling, formal requirements and design speci cation tools are present. In addition, such a framework should provide the necessary tools to bridge the gap between the model and requirements on the one hand, and between requirements and design on the other hand. 3

Needless to say, the goal of system realization is in fact the product: a running system. Usually for achieving the product, designs must be implemented. The reason for excluding the implementation task from the framework is that at at this point it is still highly unclear. In section 3.3, however, we advocate the need for an implementation method to support engineers in implementing designs, and discuss the constraints imposed by the implementation task on the framework described above. In this report we study a framework for designing RTC-systems. The framework consists of the following instrumentation. Firstly, a general modeling strategy for modeling total systems. Secondly, a dual notation for the speci cation of both requirements and designs; the duality of the notation expresses the needs of the axiomatic and operational speci cation approaches. Thirdly, analysis and veri cation instrumentation for analizing designs and requirements speci cations. And nally a designing method which helps bridging the gap between requirements and designs. The goals we have from studying the framework are various. Firstly, to identify the principles of designing which are necessary for enabling designing total systems. Secondly, to identify the language constructs necessary for basing such a framework on the mentioned principles. And nally, to clarify designing of systems and identify in it points of weakness which need further research. In the next section we present the framework and discuss its modeling, speci cation and designing approaches. In addition, we re ect on the usability of formal notations of which the identi cation of the necessary instrumentation is a basic necessity. In section 3, we discuss the designing method and identify the designing principles and instrumentation it implies. In section 4, we discuss the principles of modeling, speci cation and designing, and identify the language constructs the imply are identi ed and embedded in a notation based on ASTRAL 18]. Finally, in section 5 we discuss the results to this study and possible further work.

1.3 This text

2 A framework for modeling, speci cation and designing

The importance of capturing all participants of a system in one model for correctness of behavior has been pointed out by Ostro 33]: Real-time software is part of a greater system. Computational models must be exible enough to represent both controllers (software) as well as the plant (the environment). Software harms no one. It is the plant that the software must control that does the damage. The total system, consisting of controllers and plant, must be modeled and validated. Our main reasons for supporting this statement can be summerized in two. Firstly, traditional design of systems begins with a given plant and hardware (or assumptions with respect to their design) which imply the requirements from the software. This may result in requirements which are unful llable on part of the software but may also result in less 4

2.1 Modeling total systems

e cient systems. Secondly, the rst goal of designing a system is achieving its requirements. Achieving correct controllers may support this but does not provide any guarantees with respect to the correctness of the whole system. If the requirements of the system (or part of it e.g. the plant) are wrong or ambiguous then this might have consequences on the controller. To model total systems, it is important to have a modeling strategy of total systems. The modeling strategy we choose, closed system view, results in systems which are called closed: these are closed in the sense that it includes all parties which participate and in uence the goals from building it (stated in the requirements from it). As discussed above, it is necessary to express both requirements and designs. Since requirements declare intentions and goals, we believe that their speci cation should be more declarative than designs which should include information about e.g. choices of structuring the system. This implies the need for two notation which di er in their approaches. In this respect two levels of abstraction in system speci cation exist. The rst states that a system is a set of behaviors of a certain implicit abstract machine , while the second states that the system is the abstract machine itself. The rst is called axiomatic approach while the second operational 39]. In our view, requirements should be stated in terms of logical formulae which state what set of behavior the system must have. Design, on the other hand should construct an abstract machine. For system realization it is important to bring both ways of speci cation under the same framework since requirements guide designing and form its reference for veri cation. In addition, the two notations should be related to each other to enable the necessary formal veri cation of designs.

2.2 Dual notation: Speci cation of requirements and design

2.2.1 Formal speci cation languages

Formal speci cation languages underly the formal designing methods and form their basis. They provide the syntax and semantics for expressing requirements and designs, and enable the steps of design by providing the necessary design instrumentation assumed by the designing method. Moreover, these languages are usually supported by veri cation facilities which enable the necessary veri cation during designing. Formality of a language is achieved by rstly disambiguating its syntax and secondly basing its semantics on mathematical systems (e.g. algebra and rst order logic). This establishes an unambiguous meaning of any possible report written in such a language and enables the veri cation activities provided by the mathematical systems. The last decade or two, there has been much research in the eld of speci cation of RTC-systems which resulted in many speci cation formalisms. The main existing speci cation formalisms can be identi ed as either operational or axiomatic. As mentioned earlier, the rst category speci es abstract models for the solutions to the problem at hand. To this category belong among others process-algebras 6] and Petri-Nets 47]. The axiomatic category speci es the abstract properties of the solutions to the problem (i.e. their desired behavior) mentioning as little as possible of design and detail. To this category belong the 5

formalisms based on logics such as Temporal logic 43] and rst-order predicate logic. Formal speci cation found successful use in some domains outside the real-time systems domain, such as in language speci cation and automated compiler generation. In the world of RTC-system design, process algebras have found their use in communication-protocols speci cation. The main characteristics of this last domain of problems is that it has clearer designs which use heavy communication; for such domains process algebra's seem to be adequate. However, in cases where design is misty and detail may only complicate decisions, process algebra becomes too hard to use and at a certain level even too concrete. More abstraction is necessary for many RTC-systems and, as will be discussed later in this text, abstraction from some issues at rst design steps is even essential. In addition, requirements speci cations (stated in process algebra) are also operational speci cations, which makes later design veri cation and reuse harder tasks 39] (a design is another operational speci cation - verifying its correctness is a matter of comparing the behavior of two operational programs). Nevertheless, there are clear positive sides to the operational attitude of process algebra among which the clarity of the implementation task is the most important. In this text, we have chosen temporal-logic-based formalisms as basis. The main reasons for this are that they provide a high level of abstraction, state both requirements and design in the same notation, and enable the employment of the design instrumentation necessary for implementing the designing method mentioned earlier. However, most aspects studies in this report are applicable also to other kinds of formalisms. Temporal logics were studied by (among others) Manna and Pneuli 43], Misra and Chandy 10], Lamport 39], and Morzenti 17] (respectively introduced the formalisms Temporallogic, the logic of UNITY, TLA, and TRIO). In the context of this work, we nd the unifying aspects of these formalisms more interesting than those which di er them. Here we list some of the most important unifying aspects and consider them as a guiding framework for the formalisms which we consider as underlying the design instrumentation we identify as necessary and adequate for RTCsystems. Some of the unifying aspects of the temporal logic based formalisms are the following. They all model RTC-systems as transition systems. Their semantics are interleaved and their computational models include the introduction of measures which relate their interleaving model to real-concurrency (such as fairness notions). Real-time aspects and constraints are considered by these formalisms as a re nement step of abstract temporal behavior, and a requirements speci cation as a combination of liveness and safety properties. As mentioned above, we choose the transition system (TS) model 27] as the generic computational model for RTC-systems. Needless to say, a choice of a model can not be supported by proofs of its adequacy to certain systems. Rather, the adequacy of a model should be studied and veri ed in order to discover the realities it is applicable to. However, our choice for transition systems is based on two facts. Firstly, it is the most general generic model we are aware of, and secondly it is extendible to support modeling of hybrid systems (mixture of discrete and continuous processes). In 41], timed transition systems (TTS) were extended to accommodate continuous systems. The extended version of TTS is called phase transition systems (PhTS), described in 6

the same work as follows: As a generic computational model we take phase transition systems which represent the behavior of a system as a sequence of phases alternating between continuous and discrete changes. A continuous phase takes positive time and allows continuous change of variables governed, for example, by a set of differential equations. The discrete phase consists of a nite number of discrete transitions, each of which causes a (possibly) discontinuous change in the value of the variables. Phase transition systems might be adequate for certain hybrid systems but inadequate to other hybrid systems. Application of this model is necessary for gaining knowledge about the characteristics of the systems for which it is adequate. In this study however we have limited our speci cation to using timed transition systems for the simple reason that we still do not have a suitable speci cation language. A few existing languages based on transition systems seem appealing to us as a starting point for the speci cation of designs of which ASTRAL 18] seems most attractive. In order to extend languages based on TTSs to languages which describe PhTSs (design) experience with the models, designs and continuous descriptions used by control engineers is necessary. The designing method advocated here is formal (i.e. uses formal notations for expressing designs) and combines the two complementary paradigms of design, top-down and bottomup, represented respectively by stepwise-design and design-by-composition. It serves as a model for studying the design processes which might be applied in practice, in which design is obtained by an interleaving of bottom-up and top-down design steps. This designing method enables the designer to work out a detailed design, step by step, from a requirements speci cation, maintaining consistency in two ways; internal consistency of the design and its consistency with respect to the requirements speci cation. The main guiding heuristic rules of such design processes are two; the rst states that each step should bring the resulting design a step closer to ful lling the requirements (i.e. disambiguating design), and the second states that designs should be implementable with the existing techniques. A design which is consistent with the requirements but does not ful ll them completely is considered uncomplete; such design must be completed before implementing it since otherwise implementations would be possible which show undesired behavior. Note that according to this view, design might begin at a point where the rst design speci cation is not complete (i.e. does not ful ll the requirements speci cation yet); It is unacceptable to assume that the rst design speci cation is complete since this is usually impossible to achieve in one step. Both completing the design and, at later stages, making it concreter step by step (i.e. re nement) are identi ed as one design process. A designing method assumes a certain necessary designing instrumentation for application during design-processes; this instrumentation implements the design principles upon which the method is based. The designing instrumentation should be embedded in the unifying environment which enables speci cation, designing and veri cation of systems. The designing instrumentation assumed by the present designing method are identi ed in the next section where the method is presented in detail. 7

2.3 A designing method

In spite of their obvious advantages, (almost) none of the existing formal notations has won territory from the informal notations used for designing RTC-systems. In my view, the fact that the abstract notations used by formal languages are not popular and do not appeal to software and design engineers, does not provide su cient explanation for the situation. It is mainly the lack of adequate and useful design instrumentation which results in unused speci cation formalisms. In addition, the unclear relation between design and implementation (i.e. in programming languages) for the control part forms another major obstacle for the application of formal methods in RTC-systems realization. The mere identi cation of the necessary design instrumentation makes design possible but is not enough for usability. Such instrumentation should be adapted towards the needs of RTC-systems design and designers if it is to become useful. Moreover, its relation with the implementation in programming languages should be clari ed, and supported with the necessary instrumentation. Adequacy of a speci cation formalism (and its associated veri cation possibilities) addresses aspects of its application; of these aspects the following three are major. Firstly, its ability to accommodate the design instrumentation assumed by a designing method. Secondly, the adequacy of this instrumentation for a speci c subclass of RTC-systems' requirements speci cations (since it has become clear that limited application domains for formalisms are unavoidable). And nally, how tuned is this instrumentation towards optimal pro t from formality (e.g. explicit limiting of the application of the instrumentation to those situations where guarantees and clarity exist with respect to the results of the application). User-orientation of speci cation formalisms addresses providing the user with readable and easy to use notation, with instrumentation which is clear and easy to apply, and with tools which enhance productivity. The adequacy and user-orientation of a designing method are essential for its usability. Adequacy of a speci cation formalism to the special needs of the design process is the primary requirement of their designer. Beyond adequacy, user-orientation is the selection rule which decides between adequate formalisms since time-saving and convenient tools imply economical superiority. However, users should believe in formal methods and their abilities, and get acquainted to the ways of thinking they require. From future systems designers, more familiarity with mathematical systems and formality should be expected since this probably will become unavoidable for optimal use of formal designing methods. A study of adequacy and user-orientation aspects of formal designing methods is necessary since its conclusions should direct the development of such methods towards usefulness; without clear objectives, it is hard (if not impossible) to develop adequate and useful methods. In addition, such a study may serve for evaluating the usefulness of designing methods. Guide-lines for both evaluation of usability and development of useful design instrumentation are lacking in the eld of RTC-systems design. This situation may be explained by the fact that concrete results of studies of formal design methods for real-time systems were achieved only during the last decade or two.

2.4 Usability of formal notations

3 System designing
In this section we discuss a designing method and identify the necessary designing principles it implies. As mentioned earlier, the designing method enables the designer to combine both bottom-up and top-down strategies into the designing process. The method should be seen as a theoretical model for studying designing processes since these are almost never found as clear sequential processes of steps. A designing process begins by introducing a rst design, based on the requirements speci cation, and proceeds by stepwise design to ful ll the requirements. Decomposition is considered as a design choice which results in another step of design. Composition of the resulting subsystems should be possible at all stages of their designing such that correctness of the whole system can be checked whenever necessary. This non-determinism in interleaving the application of either stepwise or composition (see 3.1) is essential in this designing model since it should be able to accommodate the possible designing processes (i.e. those conducted using stepwise and composition). Next we discuss both composition and stepwise design and identify the necessary principles assumed by this designing method. Subsequently we clarify requirements speci cation, the introduction of the rst design speci cation, and the importance of non-determinism in the whole process of design. Design by composition enhances reusability of speci cations and encourages the designer to decompose a complex system into small manageable subsystems. The last of these two requires from the designer some insight in the chosen design (i.e. decomposition into subsystems). In principle, it should be possible to decide whether to compose a few systems (designs) into a whole solely on basis of the properties described in their requirements speci cations (assuming that the designs ful ll their requirements speci cations). This is of course if one is only interested in obtaining a design of the whole system without any other considerations such as e ciency. The formality of the notation enables the designer to study the composition at the level of requirements speci cations and make the decision of whether it is meaningful. In general, composition of two systems must follow a previous activity of decomposition; this activity might concern either actual or virtual decomposition of the RS of this system. The rst kind is usually carried out as a step in applying the divide and conquer strategy. While the second serves as a tool for accomplishing reuse of existing design. Next we elaborate on this observation. Divide and conquer begins usually with dividing the RS of a certain system into RS's of subsystems which must be designed and veri ed previous to composing the resulting designs into one for the original system. In contrast, composition for reuse initially assumes the existence of both RS's and DS's for subsystems; the DS's are composed only after verifying that the RS's imply the RS of the desired system. In this case, the designer seems to have applied a certain virtual decomposition (based on heuristics) of the RS previous to chosing the subsystems which are to be reused. In both cases however, we conclude that composition is an activity which takes place after decomposition (or alternatively, decomposition leads 9

3.1 Bottom-up: Composition

to composition). This observation is the basis for combining top-down with bottom-up design; while composition is bottom-up, a previous decomposition may be considered a step in stepwise design. This enables a certain interleaving of bottom-up and top-down steps during design. Composition implies the need for suitable modularity tools in the speci cation principles. It emphasizes the need for suitable interfaces of modules and suitable ways to connect them through these interfaces. As stated above, the connection of modules should be veri able and has clear consequences on the properties of the resulting system. Stepwise-design has been advocated by many researchers in the eld of speci cation and modeling of systems 34]. It is a designing method which does not assume or impose any restriction on the number of designing steps which maybe exercised by the designer. It allows the designer to work out the system step by step. At each step, the designer adds detail to the speci cation. At rst, detail addition limits the non-determinism in the speci cation (resulting from abstraction) and removes ambiguities with respect to the requirements speci cation (i.e. resulting in a complete speci cation). Afterwards, detail addition serves for implementing abstract algorithms of the speci cation by concreter ones (i.e. applying re nement). However, stepwise design must always be guided by a formal requirements speci cation which states the requirements from the system to be designed. This requirement speci cation in uences design decisions and serves as reference for checking the resulting designs on being consistent with it. The ultimate goal of the designer is to implement this requirements speci cation fully using existing "e cient" algorithms. Next we describe the stepwise designing method and name the principles necessary for its application in RT-systems design. The method is iterative and is guided by selection rules between design choices (applied on a heuristical basis by the human designer). Our departure point is the separation of the functional and temporal concerns in system designing and speci cation. This is based on the view that the functional side of the system generates its unconstrained behavior (in which quantitative time plays no role), which is constrained by the temporal side (i.e. timing constraints) in order to achieve the desired timed behavior. This view does not con ict with the fact that correctness of RT-systems behavior is in general time-dependent. It is always possible to abstract from time stamps in timed behaviors obtaining mere temporal behavior (i.e. speaking in terms of always and eventually ). This abstraction simpli es the designer's task of achieving correct designs; correctness of functionality should be rst design concern, while timing-aspects constrain the functionally correct behavior to achieve the correct real-time behavior. For the moment being, assume that we have at hand an unambiguous and consistent requirements speci cation (RS hereafter) of a system. Assume also that we already have a design speci cation (DS hereafter) which, on the one hand does not con ict with the RS, but on the other hand does not completely ful ll it either. Stepwise design proceeds from this point on by steps (see gure 1). At each step, a design technique is chosen for achieving the requirements in the RS and its detail is added to the DS and to the RS to obtain a new pair of DS and RS. Subsequently both, the internal-consistency of the new design and its consistency with the new RS, are veri ed by formal analysis and proof methods. We note 10

3.2 Top-down: Stepwise-design

RS
Requirements Specification complete process Design Specification

Empty DS

RS

DS

RS
disambiguate

RS
Complete refine

and remove inconsistencies

disambiguate and remove inconsistencies

DS

process

DS

Requirements Specification

Implementation Key: RS DS a design step requirements specification design specification Implementation

RS

Design Specification

DS

Key: ovals represent functions arrows into ovals represent their parameters arrows out of ovals represent their results

Figure 1: Left: Stepwise design. Right: Veri cation after each step. that modularity in system design implies decomposition into subsystems which is considered here a mere design choice. Notice that the design steps concern the pair RS, DS]. The choice for this is based on the fact that the separation of the functional from the temporal concern in the rst phases of speci cation and design, imply the need to re ne both the RS and DS. At rst, the RS represents the desired functional behavior and a DS must be achieved which ful lls it. Later on, the temporal constraints are added to the RS and subsequently to the DS to obtain the temporal behavior of the system. However, gure 1 shows the addition of detail to the RS at all steps. This might not be necessary since many steps just re ne the design by adding concrete detail (which has nothing to do with separation of functional from temporal behavior); instead of re ning the RS also, it is possible to re ne only the DS and verify whether the re nement step is correct (i.e. resulting behaviors are a (nonempty) subset of the original). Nevertheless, the above gure was chosen as a general model (and picture) of design steps, forced by our choice to employ separation of concerns. The actual designing processes might apply re nement to the RS in chosen and isolated points where the e ects of separation of concerns are removed such as shown in gure 2. As can be seen from this description of stepwise-design, two primary (heuristic) selection rules guide the designer in the choice of design steps. The rst of these rules inspects whether the chosen technique brings the DS closer to ful lling the RS. And the second, inspects whether it does not result in a design which con icts with the RS. However, among the many other implicit selection rules (such as the economical), one speci c rule should be mentioned explicitly here: the chosen technique must always lead to an implementable design. This rule is aimed at preventing design from becoming an unimplementable abstract description of the system. In the above sketched stepwise designing method there is an implicit separation of two design tasks; it is suggested to rst obtain a DS which ful lls the RS completely before beginning with re ning the designs (i.e. implementing abstract algorithms with concreter ones). 11

Empty DS
complete process Functional

Complete Functional

Real-Time

DS
add timing constraints

DS

Real-Time

RS
add timing constraints

RS

refine process

Refined Real-Time

DS
Implement Process
Implementation

Key: RS DS

requirements specification design specification

Figure 2: A possible designing process This order of the design tasks leaves the necessary freedom of choice of design-techniques for each of the system parts. Moreover, it also enables easier and e cienter veri cation and analysis activities, since implementation detail may only complicate these activities without providing any advantages at early design stages. In contrast, too early (i.e. before reaching completeness) implementation of certain parts of the system, might lead to designs which are hard to complete (i.e. these implementations are hard to limit and desired designs for the rest of the system can not achieve completeness). Moreover, such implementation choices might turn out to lead to behavior which is too restricted, in the sense that it prohibits the system from showing desirable behaviors acceptable by the RS. In the next sections, the assumptions of having both an unambiguous and consistent RS, and a rst DS of the system as start point of stepwise design will be removed. This will be done by explaining how to achieve these two speci cations given an RT-system. We sugar the discussion with examples which refer to the Gantry Crane system described in gure 3. We close this section with a short discussion of the relation design-implementation and its consequences with respect to designing methods. The process of producing a system begins with identifying its goals. A system has many interesting aspects and each user of the system (e.g. the manager which wants to employ it in her company) sees only those aspects which serve her goal from using it. A system is, to this user, a box which emits some desirable behavior. According to this abstract view, a system has a few observable variables; the desirable behavior of the system can be described in terms of properties of these observables. These properties must hold always and at all circumstances. In general, such properties may be classi ed into either safety or liveness properties; safety properties require that something 12

3.2.1 Requirements speci cation

trolley

destination

wall rail overshoot

wall load

A trolley is placed on a track of known length. The trolley may move either to the left or to the right on the track. Under it, a load is hanging by a rope. The objective is to obtain a system which brings the load to a pre-speci ed destination point as fast as possible, under the constraint that only a very limited overshoot of the load in the horizontal direction is allowed. In addition, neither the load nor the trolley may be outside the borders of the track. Figure 3: The Crane system must hold always, while liveness properties require that something will eventually happen. For example, in the Crane system the observable variables may be: the place of the trolley (or load), the destination and the swing angle of the load. The desired property of the Crane system is safe arriving at destination of the trolley (or load) always. This property can be analized to basic safety and liveness properties. One such basic safety property is that little overshoot of load and remaining between the borders of the track. A liveness property is that the load must arrive eventually to its destination. A requirements speci cation must be consistent and unambiguous. Consistency requires that the requirements in an RS must not lead to con icts. This can be veri ed by formal analysis methods. Unambiguity (i.e. completeness) on the other hand requires that the RS contains enough properties to specify exactly the desired goals from the system. This may be veri ed in two ways; rstly against the requirements of the person who ordered building the system, and secondly by checking heuristic standard constructs which RS's must contain 29]. The second kind of check is syntactic en does not guarantee completeness of the RS but provides a tool for elimination of obvious ambiguity. The rst kind of check cannot be veri ed from inside the RS itself and asks for inspection of the observable behavior of the RS against the desired behavior (e.g. by means of simulation, property deduction). For a designing method to be adequate for formal design, it should provide constructs for expressing RS's (properties of systems) and for checking their consistency and completeness. It also should enable the designer to check whether a proposed design is consistent with the RS (or even ful lls it). The crane system example has shown that the speci cation principles 13

must provide a high level of abstraction which enables the designer to speak in terms of properties. In addition, a speci cation principles should provide the adequate constructs to state both design and requirements side by side in the same notation.

Closed-system view An implicit model which underlies this manner of requirements

speci cation is the closed-system model. As mentioned earlier, a system is closed in the sense that all stimuli to which the system must produce reactions are internal; thus the system has only observables. This view in system modeling is used in many branches of science and our choice for it is supported in the next section since it is considered one of the necessary speci cation principles assumed by the designing method.

At rst, when there is no design yet, little is clear about implementation issues and how the desirable behavior of the system will be achieved. At this stage of speci cation, only the clear relations between the observable variables, mentioned in the RS, may be stated in the DS. In many cases, the behavior of some observables is determined only later on, when solutions and design decisions are introduced. The behavior of such observables should be assumed completely nondeterministic at this point. This non-determinism implies that the DS may not yet ful ll the RS. To ful ll the RS, this non-determinism should be reduced by design choices. Notice that the rst goal is to achieve a speci cation which ful lls the requirements and only then implement its abstract algorithms by concreter algorithms. Usually it is unclear how one should construct a speci cation which ful lls the requirements without working it out step by step. This is why it is unacceptable to assume that one starts design with a speci cation which ful lls the requirements. For example, in the Crane case one may express in the initial speci cation the clear relations which exist between the place of the load and the boolean observation whether it hit one of the walls. In addition, the observation whether the swing is still acceptable may also be expressed in another relation. Examples of observables which are left nondeterministic at this stage are the horizontal place of the trolley, the angle and the destination applied by the user. It is impossible to specify the behavior of these entities without designing the internal parts of the system (e.g. by identifying a controller and a human user; the second applies destinations while the rst drives the trolley towards these destinations by applying power for example). Needless to say, speci cation and design are two stages of system realization which has the function of enabling the third stage which is implementation. In our case we deal with software implementations. The goal of the implementation task is to translate a complete and re ned DS into a program in a target programming language. This program may implement only the software part of the controller, but may also represent the whole controller as a software prototype of it. The translation process from DS into a program is another process which needs veri cation. If this last step in system realization is conducted ad hoc and without any formal veri cation then a big share of the e orts invested in formal speci cation and design is wasted; no assurances may be provided with respect to the program's correctness and safety. 14

3.2.2 The rst design speci cation

3.3 Implementation of design

For this reason it is necessary to study the translation step from design into implementation and support it with the necessary principles. In this respect little has been achieved yet, which might be one of the main reasons for the reserved attitude of system designers and implementors towards formal methods. Although this report does not deal with implementation, we believe that it is important to see its in uence on the design stage and its principles. For this reason we provide a short discussion of design-implementation and state some observations about its implications on the designing method. In this discussion we consider the three following views concerning the relation between design and implementation. Firstly, an implementation is obtained from design by one translation step (possibly automatic). Secondly, an implementation is obtained by an implementation method which relates design to implementation in analogy to the way a designing method relates requirements to design. Thirdly, an implementation is the lowest level of re ned design (i.e. re ne design as much as "necessary" to consider it as implementation). Next we consider the main assumptions each of the above mentioned views makes and state the questions they imply with respect to the the reslation design-implementation. We do not attempt to answer these questions here but to state them explicitly as problems which must be solved upon making a choice between the three above mentioned views. In contrast to the third view, the rst two assume that a design speci cation, re ned as it might be, is not a program. The questions which may be raised at this point are what is a program and what is a speci cation ? what are the di erences and resemblenesses between these two notions ? are the di erences essential to imply the need for the above special treatment of implementation ?. On the other hand, is it possible to ever achieve e cient execution of speci cations such that they can be considered programs ? obviously before such a step one senses the need to annotate the speci cation with information pertaining the real world which are missing in its model as assumed by the speci cation. Beyond the above mentioned common assumption of the rst and second views, the rst makes an assumption which the second does not; It assumes that it is possible to identify and de ne implementability of designs, such that implementable designs may be translated in one step into programs. The questions which arise from this assumption are: what are the criteria for implementability of designs, e.g. How far is it necessary to re ne designs before attempting implementing them ?. This question concerns the information a speci cation must contain in order to enable the translation into implementation. Many attempt to answer the last question as follows A design speci cation must be rened to the point where the assumptions it makes are realizable in the implementation, and the detail it contains is su cient to make the translation of its abstract notions into concrete notions possible. However, this answer remains vague and does not provide enough

information for reconciling designing and implementation.

A conclusion from the above short discussion reveals the following simple observation: designing methods cannot be totally implementation independent if designs are to be implementable (note that design's correctness should maintain independency from implementation choice however). Designing is a process which should be guided by the target implementation language in the sense that this language requires certain detail and information from 15

designs; a design is implementable in a certain language only if it provides this detail. As this report discusses a designing method then it is clear from this conclusion that it is necessary to solve the problems which result from the relation between design and implementation. To me the third view of this relation, mentioned above, seems too ambitious at the moment as the experience with both functional and logic languages has shown (i.e. that use of abstract programming methods is limited by their lack of e ciency). The rst view, like any other, asks for deep insights in the relation between design and implementation which do not exist yet and its "one step" paradigm does not provide enough space for learning (i.e. obtaining these insights). As long as we do not have the necessary insights, it is necessary to provide a method which enables on the one hand more reliable implementations but on the other hand the gain of these insights. In this respect, the second view o ers the combination of stepwise work on reconciling design and implementation and the possibility of small steps which may be veri ed but also changed if needed. Moreover, the ability to work stepwisely provides space for learning and gaining insights. However, this view needs support by tools which result from studying the needs of such an implementation method. It is clear that such an implementation method leaves to the implementor the points of creativity (this ts well in the overall view of formalization discussed in this text: Neither design nor implementation processes are fully amenable to formalization). As already mentioned above, it is necessary to verify whether an implementation ful lls the design speci cation. If such veri cation should be based on formal methods then it might be necessary that both implementation and design share a common semantics. This is to say that both design and implementation must be translatable to a common formal language which provides the necessary veri cation facilities. However, since requirements and design must also share a common semantics, then in fact all three stages must share one common semantics (see gure 4).
RS Translate RS

Temporal Logic Translate Translate Translate DS

Translate DS

Translate

Temporal Logic Translate Implemmentation

Process Algebra Translate

Implemmentation

Figure 4: Semantics Left: only TL Right: combination of PA and TL. Temporal logic seems a good candidate for being the common semantics of RS's and DS's. For the implementation level programming languages however there is little done to translate programs into temporal logic formulae. This task is hard since its core action is abstraction. As mentioned in the former section, process-algebra seems inadequate for expressing 16

RS's. However, the fact that it is operational in nature makes it a better candidate as common semantics for implementation and design. This implies that design should have both operational and axiomatic faces. But this is not surprising since designs are meant to bridge the gap between RS's and implementations (see gure 4). A conclusion from the above is that it is necessary to study the translation of implementation languages into process algebra. Not less important is to study the translation and relation between temporal logic and process algebra. Although this o ers a longer route of study than the case where "everything" is given a temporal semantics, it might be an easier one to conduct. In this section we identi ed certain principles and instrumentation which are necessary for the process of design. We divide this principles and instrumentation into two categories according to their use during design; speci cation and veri cation. In addition, a third category of instrumentation may be identi ed as a result of user-orientation in developing a designing method; this category provides user-support tools (see gure 5).
Stepwise Design Top-down Design by composition Bottom-up

3.4 The necessary design principles

Implement by

Analysis and Verification Methodology

Specification Methodology

Apply Adequacy and User-Orientation to achieve

User-support Tools

Analysis and Verification Methodology

Specification Methodology

Useful Design Methodology

Key:

function entity apply function to entity entity is result of fucntion

Figure 5: Achieving usability of designing methods

17

Modeling, speci cation and designing principles provide the ability, both, to express RS and DS of the system and to apply the design steps to them. In this category we nd: closed-system view, expressibility (of properties, functional design and timing-constraints), non-determinism, re nement (design completing and implementation of design), modularity (decomposition and composition), separation of concerns (what vs. how, correctness vs. e ciency, functional vs. temporal). Veri cation and analysis instrumentation enables the designer to check whether the RS is consistent and unambiguous, whether the DS is consistent, both internally and with respect to the RS. And in addition, whether the completeness of the DS with respect to the RS is already achieved. In this category we nd: RS and DS analysis and veri cation tools (internal-consistency, unambiguity, simulation, history checks, property proof). User-support tools, the third kind of instrumentation, enables the designer to work e ciently and provides convenient tools to this end. In this category we nd: syntax-directed editors, animators, and debuggers. Since it is hard to identify a minimal set of necessary tools in this category, and since it's goal is support then we do not discuss it in this text. As mentioned earlier, in this report we discuss only the rst category. This is done in the next section where also identify the language constructs these principles imply and embed them in a notation based on ASTRAL.

4 Modeling, speci cation and designing principles

In this section we discuss brie y the speci cation instrumentation which was identi ed in the former section. The discussion addresses for each instrument brie y: a de nition, justication of the choice for it (in case there are other choices), and what constructs it implies in speci cation languages. These constructs are embedded in a notation based on ASTRAL. First we explain the basics of this notation alater during discussing the principles we extend it further with constructs. The notation we use is chosen on basis of its simplicity, compactness and readability for people from di erent disciplines of engineering. Most constructs of the notation correspond to ASTRAL constructs and should be interpreted as such. In addition, we assume the same execution models as ASTRAL. As mentioned earlier, the generic model assumed is a state transition system. Instead of explicit transitions we have chosen to use the guarded-command notation and multiassignment statements. A guarded command has two parts which are separated by an arrow. The rst part is a logical proposition (guard) and the second is a multi-assignment (body) which refers to variables such as in UNITY 10]. This command is equal to a transition which is enabled when the guard is true and when executed has the e ect of assigning to the variables such as stated in the body. Such a guarded command is considered an atomic action. Guarded commands may be labeled. The label must appear to the left of the command. Syntactically speaking a multi-assignment consists of a few assignments (each denoted with :=) separated by k . A bare (multi-) assignment command is simply a guarded command of which the guard is a tautology. 18

4.1 Introduction

4.1.1 Notation

Overlining state-variables (e.g. x) implies taking their value in the previous state (equal to priming variables in ASTRAL).

4.2 Designing: Non-determinism and abstraction

Non-determinism in a design speci cation language is the freedom during execution in the choice of next state. Non-determinism is an essential tool in the design of complex RT-systems 34]. It is almost never clear from the beginning which design choices are appropriate and thus it should be possible to maintain some freedom of design choices for later stages of design. In addition, a designer might want to analize and verify a partial design (i.e. in which some behavior is still unspeci ed); this might be necessary since some of the already made choices might a ect future choices. Assuming non-deterministic behavior of those parts not yet designed enables this early veri cation. Non-determinism has two places in a design language: execution model and design constructs. The execution model should provide non-determinism in the sense that the scheduling policy, number of processors (i.e. underlying hardware) and communication policy it assumes must be general enough to be able to accommodate all desireable existing policies and hardware. As mentioned earlier, the language should also supply the constructs for limiting this non-determinism. The design constructs of the language should support non-determinism. If a statevariable must be completely non-deterministic in assuming values then the constructs should enable expressing a transition which has pre and post conditions which express this fact pre-condition is a tautology and post-condition is random choice of value from the type of the variable. The fact that such a transition is enabled always does not mean that it must be taken always but that it is schedulable (for example some fairness notion says that such a transition must be executed in nitely often since it is enabled in nitely often). While non-determinism admits all behaviors to the system model, stepwise design is the tool of the designer to remove this non-determinism for obtaining only those behaviors acceptable by the RS. This view of design emphasizes system evolution during design. At rst, all behaviors are allowed and all design choices compete for limiting this non-determinism. Stepwise design introduces evolution steps (i.e. design steps) and the selection rules mentioned above guide the whole process by eliminating those designs which do not comply to them. Only those designs which ful ll the selection rules "survive" and reach the stage of implementability and use. A closed system view assumes a model of the system which does not react to any stimulus from the environment (i.e. outside the closed system). The model re ects this assumption by having only observables in its interface to the environment; it considers all possible interactions to be internal to the system. The closed-system principle has been applied successfully in science for modeling systems (e.g. in physics, chemistry and biology). It is based on the assumption that some facts of reality are neglectable; those stimuli which has little or no in uence may be neglected. 19

4.3 Modeling: Closed system view

For example, in the Crane system, the closed system model might consist of: the physical construction of the Crane, the controller and a user which applies destinations for the load. Stimuli such as friction, possible wind and weather disturbances and earth rotation are all neglected in this model. Whether these stimuli are really neglectable is a question of whether the chosen model is adequate for the given reality; this is of course a question about the intended use of the model and its adequacy for achieving it. In fact, the above example model for the Crane system, makes an assumption with respect to the power supply for both the controller and the motor of the trolley; power is supplied continuously without any failure. However, this assumption might be unacceptable in some applications where alarming is necessary in absence of power supply for reasons of safety; in such cases power supply should be part of the closed model. A closed system approach to modeling RTC-systems is preferred to an approach whereby only the control part is speci ed in an open system. Some of the most important reasons for this are: The rst goal of speci cation and design is to support the correctness of the system as a whole. The mere correct implementation of a function in a control part, without relating it to the whole system, leaves no possibility for verifying the adequacy of this function to its intended role in the system while designing it. Moreover, it does not provide any possibility for early veri cation of the correctness of the system as a whole. The crane-system (but many other RTC-systems also) shows that it is very hard (if not impossible) to identify abstract properties of the control part alone such that implementation choices can be left open. A speci cation which does not leave such basic choices open, prohibits reuse and leaves no room for negotiation of design choices between the various parts of a system. For example, in the case of the Crane system, the choice for a PID-controller is an implementation rather than a speci cation of the controller. It does not leave any choice for implementation by other control-techniques (i.e. this speci cation is not reusable), and it limits software use to simulating existing hard-wired controllers rather than enabling other new possible control-algorithms. A closed-system model consists of only the necessary and su cient parts; the adequacy of this model (i.e. whether it is su cient) is always considered with respect to its intended use. This adequacy can be studied against the stated requirements early before design takes place and the requirements can be revised by consulting the party which ordered building the system. In contrast, a model of the controller alone is bounded to make assumptions about its environment (e.g. physical-process, human users) both on the requirements and design levels; veri cation of the model against the requirements provides no guarantee with respect to its adequacy and other veri cation is not directly available. Hence, it might be too late if these assumptions turn out to be unrealistic. It is relatively much easier to adapt the controller's requirements than make the environment conform to assumptions. In any case, without a closed system speci cation it is impossible to discover the need for adapting the control part in time. 20

The speci cation tools we have at hand enable us to integrate the process of system design. This integration is desirable since it makes it possible to acquire a complete and unambiguous speci cation of the whole system. The complete and unambiguous speci cation of the control part can then be found in the context of the whole system. Any correct implementation of it, should be able to serve the goal of achieving the system's requirements. A closed-system model guides requirements speci cation and design. It identi es the necessary and su cient observables and system parts for them; the requirements state the desired observable behavior which must be achieved by design (such as described in 3.2.1). Moreover, it isolates the assumptions with respect to the environment; any part not explicitly mentioned in the model, is neglectable and should not contribute to the requirements. Some parts of a closed-system might have unrestricted behavior (e.g. human users); it is hard if not impossible to identify properties of their behavior, and any assumptions in that respect might be unsafe. Designs of such parts should be unspeci ed in the sense that it must be left as non-deterministic. This non-determinism might, on the one hand, re ect the need to restrict the interface to the user, but on the other hand serves for the veri cation and testing activities as a kind of behavior-generator. The choice for the closed system model has consequences on the speci cation languages; it in uences both requirements and design expression tools. These are discussed in the following section.

4.3.1 Example
dest

Xt

Wall

Figure 6: The Crane system The closed Crane system model is deduced from the RS as given in gure 6. The observable variables the system has are: l, , xt , dest (correspond respectively to the length of the 21

rope, overshoot, place and destination of trolley). However, the values these variables have are less important to the observer than the abstract observations: the load hit the wall (i.e. HitWall), maximum overshoot allowed exceeded (i.e. SwingOk), trolley on or beyond border (i.e. OnBorder ). Moreover, the requirements speci cation seems to be more natural if written in terms of the last variables rather than in terms of, for example, . However, we have chosen not to abstract from xt and dest (by speaking of their di erence for example) for convinience. In the notation we use, we distinguish the level of the Closed System where there are only Observables from the Subsystem level where the system has Input and Output. Closed System and Subsystem correspond respectively to the ASTRAL Global Specication and Speci cation levels. Observables, Locals, Input and Output are all equally variable declaration parts in ASTRAL. Closed System GCS Observables l; xt; dest : Integer; SwingOk, HitWall, OnBorder : Boolean; Locals : Integer;

4.4 Speci cation: Expressibility

A speci cation language for RTC-systems should provide the tools to express both requirements and design in the same language (possibly translating them into the same language at least). In the next we emphasize the separation of the temporal from the functional concern; to enable this the language has to provide the suitable tools of design and speci cation.

Considering our choice to model RTC-systems as transition systems, a behavior of a RTCsystem is an in nite sequence of states 43]. A property identi es certain behaviors (sequences) of all those possible for a system. A RS, can be seen as a sieve which lets through only those behaviors desired from the system, by stating the properties which they must have. A complete requirements speci cation of a closed system must state the necessary and su cient properties its behaviors have. A requirements speci cation contains the necessary and su cient properties if any other desired property of the system may be deduced from it. The desired behaviors (properties also) of the system are always found in the wishes of the person who ordered building it (which we call informal RS). In subsection 3.2.1, we described modeling RTC-systems as closed-systems and how a RS should be constructed from properties of the observables of a closed-system. These properties were classi ed as either safety or liveness properties 39]. Lamport describes safety and liveness properties as follows: "Safety properties state what the program may or may not do, not what it must do. : : : Liveness properties assert that the program must do something." 22

4.4.1 Requirements speci cations

Thus, a safety property 2P admits only those behaviors in which P holds at each point (i.e. state). A liveness property P ?! Q admits those behaviors in which if P holds at some point then Q eventually holds at (same or) a later point. However, safety and liveness properties (especially the last) are abstract properties of systems; actual properties speak about quantities (e.g. of time) in behavior and not only about its qualities. Although some researchers doubt the usefulness of such abstract notions and consider them interesting only for theoretical studies, we think that they emphasize the separation of concerns in the speci cation task, mainly the separation between quantity and quality. In particular they emphasize the separation between order of events (i.e. temporal) and their time stamps. As will be discussed later this separation is essential for maintaining correctness in speci cation and designing. The main actual properties which can be obtained from safety and liveness are respectively bounded-invariance and bounded-response. Bounded-invariance admits those behaviors in which it holds in certain interval of points; bounded-response admits those behaviors in which it eventually holds before a prespeci ed point (i.e. the occurrence of another event). Although bounded-response corresponds to liveness, it reduces in fact to a safety property (under the assumption that time progresses 3]). In general, the goal of an RTC-system is to optimize a certain quantity; in the Crane this quantity is embodied in the distance of the trolley from the destination applied by the human user. This distance must reach eventually the value zero, and remain so as long as the destination is not changed. A liveness property of the system has the e ect of a driving force; for achieving the optimization e ect, it should be controlled by another safety property which makes its e ect decay when the optimal value is achieved. Such a pair of properties implies design solutions as will be discussed in the next subsection. Thus a language for expressing requirements speci cations must be able to de ne the observable variables of the system (and possibly local variables), safety and liveness properties, and properties of bounded character. Such languages were studied by various temporal logic frameworks (a survey is given in 3], and other temporal logics are described for example in 43], 17]). In the notation we use we state the RS in the Requirements part and the design in the Design part. Both share the same state-variables declaration part supplied by the Closed System as Observables and Locals. Requirements are not possible to state in ASTRAL and ask for TRIO's axiomatic approach (TRIO 17]). The requirements speci cation has a few parts of which the de nitions and the properties parts are the most important. The de nitions part relates the observables to the local variables (i.e. internal variables). The properties part expresses the safety and liveness requirements from the closed system. The Crane system has the following three properties: 1. Safety property: The trolley stays at its destination (when it's already there) as long as the destination has not changed (and the situation is safe otherwise). 2. Safety property: The trolley or the load are not allowed to ever hit the wall or reach the borders, and the angle should remain less than 15. 3. Liveness property: The trolley should reach its destination at a certain moment. 23

4.4.2 Example

Requirements Speci cation

Locals Constants
Safe : Boolean; Range = 120 cm minl = 63 cm maxl = 129 cm

xl := SwingOk := HitWall := OnBorder := Safe :=

De nitions

Properties Always (minl l maxl) Always ( (xt = dest) and (dest = dest) and Safe ) ?! (xt = xt) Always Safe Eventually (xt = dest)

not j j 15 not j xl j < Range not j xt j < Range SwingOk and not (HitWall or OnBorder)

xt + l

sin( )

A design speci cation should show "how" the behaviors described in the functional RS must be achieved; it describes constructively how these behaviors are obtained. As mentioned in 3.2.2, it initially states the relations between the observables; unspeci ed relations (nondeterministic) are speci ed stepwisely by adding design. This results in algorithms and internal parts to the system. A complete functional design speci cation should specify the parts of a transition system which has exactly the set of behaviors admitted by the functional RS. Thus, the speci cation language must provide the necessary constructs for specifying transition systems. As mentioned above, certain safety and liveness properties of the RS imply the need for optimizing a quantity (which is the main goal of RTC-systems). Optimizing a quantity is usually achieved by applying two forces which have opposite directions, or alternatively, one driving force; in any case, these forces must be functions of the quantity and should decay as it converges to its optimal value. In the Crane system for example, a driving force must be applied to the trolley to move it in the direction of the destination. This force must decay if the trolley gets closer to its destination. Moreover, it must change direction if the trolley passes to the other side of the destination. In the design of a closed system, some observables represent the quantity to be optimized. In general, these observables are left unspeci ed (non-deterministic) in the rst design specication, since they imply the need for further design to achieve the e ect of optimization. In our running example, the system is designed by identifying a controller which applies power to the motor of the trolley (see gure 7). This power must be a function of the trolley's distance from its destination (which implies that the controller must monitor the change in 24

4.4.3 Design: Functional behavior

trolley's place).

Controller

Power

Physical Process

Overshoot

Xt Destination
Human User

Observables of the closed system

Figure 7: Crane system

As mentioned above, a design speci cation language must express a transition system. Many such languages has been studied and they vary from report to graphical notations. State-charts 25], Joint-action systems 34], state-machines 18], action-event model ?], Petri-Nets 47], are some of these languages. The choice for a closed system model means that the DS of a system must have only observables and no input variables. In contrast, a subsystem should have both input and output variables. An example of a language which enables such speci cation is ASTRAL 18] which provides the notions Global speci cation and speci cation. Both the closed-system and subsystem levels should provide all parts of a transition system. In a closed-system, neither the state-variables nor transition enabling can be in uenced from outside the system (thus these state variables are either observables or local). A subsystem however, may have input variables also which can be in uenced from outside the subsystem. Input variables are a means for communication between subsystems and transitions of a subsystem may be enabled from outside by changing their value. Both the closed-system and subsystem notions should enable the speci cation of initialstates, functional constraints on transitions (i.e. which state must (not) follow which state) and other useful features such as constants and de nitions.

4.4.4 Examples

The design speci cation we have adopted is speci c for the case where the length of the rope l is constant and equal to 60cm (this is a simple design decision which ful ls the requirements). The variables which depend on the design decision to be taken later are left nondeterministic Nondeterministic. The Nondeterministic constructs corresponds to an ASTRAL transition of which the ENTRY part is a tautology and the EXIT part is a random choice of a value from the type of the variable which is declared Nondeterminis25

tic(see 4.6).

Design Speci cation

Constants
l = 60 cm;

GCS

Assignments Nondeterministic , xt, dest; 4.4.5 Design: Temporal constraints

A temporal constraint limits the validity of a property (i.e. safety or liveness) to a certain interval or point in time. The result of constraining such a property is a bounded property.

Timed transition systems and timed temporal logic 43], 17] enable the expression of timing constraints of real-time systems respectively for design and requirements expression. However, only phase transition systems 43] and an extension of timed temporal logic (under research) enable the expression of designs and requirements for continuous systems. These tools of expression are not yet fully developed, but the problem of specifying continuous systems faithfully goes beyond expression tools. The discrete models provided for continuous systems often do not mention all (temporal) constraints under which they are valid. For example, in 12], timing constraints of real-time systems and the constructs for expressing them are analized. The timing constraints discussed there apply to discrete systems i.e. also to discrete models of continuous systems. However, when a continuous system is constraints in requirements it is impossible to study the discrete model, and it is hard to nd out what kind of constraints should there be while designing and implementing the system. Examples of such constraints are: deadlines for computation and output of the controller, and sampling times of the continuous process. We consider the expression constructs provided in 12] as low level. These might underly the constructs we consider as speci cation constructs. In a design speci cation (i.e. transition system) a temporal constraint is translated into constraints on the scheduling policy and durations of transitions. Clearly these constructs ask also for time domain and clocks to refer to. However, reference to absolute time is unnecessary. ASTRAL 18], for example, refers to the current time using the global clock Now. Schedule is a logical formula containing references to the quantitative time of occurances of transitions (their start and end times), stating their order and minimal, maximal or durational time which must ellapse between them. A schedule construct is in fact a kind of requirements speci cation for the scheduling policy which is chosen later while implementing the system. A requirements speci cation on the scheduling policy is necessary since the execution model of the speci cation language 26
modeled by a discrete state machine it is necessary to keep in mind that this step results in implicit timing constraints. Also these timing constraints should be captured in the requirements speci cation as temporal constraints on the discrete model. Without capturing these

assumes an abstract scheduling policy (e.g. ASTRAL assumes maximal parallelism for subsystems, interleaving in every subsystem with fairness for all its transitions. UNITY assumes full non-determinism with fairness in interleaving multi-assignments). During presenting the design framework in section 3 we discussed decomposition and composition of systems. The reasons for adopting these two notions can be summerized in two. Firstly, there is a need to reuse of existing speci cations of systems by composing them together into larger systems. Secondly, there is also the need to decompose complex tasks into less complex subtasks; in system designing it is often possible to identify subsystems (intuitively) which are less hard to design. Decomposition and composition enable also the
v1 System v2 v3 v4

4.5 Designing: Decomposition and composition

Higher level of abstraction ( lower level of detail) Decompose Lower level of abstraction

subsystem1 v1

v3

v4

subsystem3

subsystem2 v2 Legend: variable Communication

. hierarchical speci cations of total systems (see gure 8); at rst the closed system is speci ed without any detail of design then it is decomposed into subsystems which compose into another speci cation of the system on another level of detail. For example, the last level deals with local variables to subsystems, with more detailed computations inside the subsystems, and with communication between subsystems. Decomposition and composition of a system must preserve the properties it had before decomposition. In the language UNITY 10] for example, there exists a Union operation which unites the texts of two programs (i.e. combines the respective sections of the programs - with some syntactic constraints to prevent problems such as two di erent de nitions of same variable). This operation enables the composition of subsystems predicting the properties of the composed system. We refer to the level of speci cation where the system is to be decomposed with the term decomposed and to the level where subsystems are composed with the term composed level. 27

Figure 8: Hierarchy implied by decomposition and composition

The decomposed level is more abstract (less detailed) than the composed level. In our view, each level of speci cation in the resulting hierarchy of speci cations for the same system represents certain interests. Execution on a certain level reveals certain detailed behavior and execution on a higher level (of abstraction) abstracts from detail and shows a more abstract behavior. For this reason all levels should be maintained in a hierarchy of speci cations. Moreover, decomposition and composition should enable incremental designing; this stimulates hierarchical designing of systems and provides means for viewing the designed system on various levels of abstraction (and not only various levels of design). For example, execution of the system on the composed level might result e.g. in computations which are more accurate, these results should be reported to the decomposed level in order to be observable on that level too. However, to achieve these goals, a designing language must provide the necessary constructs. The following constructs are necessary: An open system notion (subsystem) which enables both input and output variables, communication constructs for communication of values between subsystems, constructs for the correct report of change to more abstract levels of the system in the hierarchy of speci cations (and the correct translation to the semantical level), and nally a construct for the statement of requirements/assumptions on subsystems. Next we elaborate on these constructs. An open system is a system which has input variables as well as output variables. Since subsystems must communicate values then an abstract communication strategy (such as that of ASTRAL's execution model) should be provided (implicitly). Constructs for communicating the values should be also provided (such as reading variables or reporting changes to all interested parties). Both the communication strategy and the communication constructs should not show any preference to synchrony/asynchrony but should abstract from it. When a system is decomposed into subsystems, its state-variables are decomposed into state-variables of the subsystems; each subsystem encapsulates part of the variables. To encourage hierarchical designing, the language should enable decomposition by augmentation of the existing hierarchy with the composed level (i.e. incremental designing) rather than copying of and addition to the former level. This implies that levels of speci cation should be related to each other on the semantical level in a correct way. This relation is achievable by translating the hierarchical speci cation into a plain speci cation of the whole system. The translation has the following steps. First, the variables in a subsystem should be inherited from the speci cation on the decomposed level, such that any change in their values is directly reported to it. This can be done, for example, by forcing subsystems to refer to the same variables they inherit (thus both levels refer to the same variable). Second, a transition for an inherited variable in the decomposed level speci cation should be replaced by all transitions appearing in the composed level speci cation. Finally, all other parts of the composed level speci cation, such as scheduling constraints and invariants etc., should be added to the respective parts as done by union in UNITY. This translation achieves the same result of design completing as action 3.a in section 4.6, provided that guard or body of the transitions of the subsystem are strengthened (limiting the non-determinism on the former level). If there is no change in transitions of the inherited variable (no strengthening of guard or body) then the result of this action is equal to superposition. We note that any other form of decomposition and composition than the last two is unsafe (for example, making the transition of an inherited variable to be enabled more often than in the decomposed level results in a new level which might not ful ll the 28

same properties). Since one of our stated goals was to allow negotiation of obligations during designing then on the subsystem level this should be possible too. A subsystem has input and output variables. To design the subsystem it might be necessary to make assumptions with respect to the input variables (preconditions). These assumptions are in fact requirements from the subsystems which supply (output) these variables. Thus a construct for the statement of requirements/assumptions on subsystems is necessary. The construct invariant in the language ASTRAL is such a construct. The importance of having such a construct is that the design speci cation of the whole system reveals all requirements and assumptions from each party, including the controller. If the requirements and assumptions of two parties do not t together then negotiation during designing of "who does what" is then necessary in order to achieve this t. Decomposition of the system into controller, user and physical crane system results in dividing the state into states of subsystems and in a suitable interfaces between them. In our notation we allow the decomposition of a system and its composition in one speci cation: Composed implies that this is another level of the system's design. The Composed level has subsystems Subsystem connected together, each encompassing part of the state variables of the original system. A variable is declared as to belong to a subsystem by declaring it again in the subsystem preceded by *. The * implies that this variable is inherited from the former level. The speci cation of the Composed GRC as shown bellow expresses the global design of controlled systems where the feedback loop between the controller and the physical parts is central. Driving the trolley is done by applying voltage to it. The choice of the speci c motor of the trolley implies requirements from the controller (what is the range of voltage it is allowed to apply to it). Notice that invariants Invariantson input variables of a subsystem are assumptions (i.e. preconditions) it makes on its input, while invariants on output variables are in fact requirements which it must ful l (i.e. postconditions). For example, the Crane subsystem requires that the controller supply voltage which is in a certain range (due to the choice of motor). In addition, it states for the Controller the in uence of voltage on the direction of movement as a function of the voltage. Invariantscorrespond to the Invariant construct of ASTRAL (although in our notation we view it as a requirements part for subsystems for stating preconditions and posconditions). The User subsystem states requirements which limit the destinations the user may apply to those which are between the borders of the rail. An implementation of the system may achieve this by using a limiter of values in the interface between the controller and the user or by supplying the user with a limited scale button.

4.5.1 Example

29

Composed
Constants

GCS

umax = 100 f* maximum allowed voltage *g uPmin= 12 f* min. necessary positive voltage for movement *g uNmax= ?16 f* max. necessary negative voltage for movement *g Subsystem User Output dest : Integer;

Invariants

Input Output Assignments Invariants

Subsystem

j dest j Range

Crane u : Integer; xt , : Integer; u := Controller.u

Subsystem
in1 in2 in3

Input , xt, dest : Integer; Output u : Integer; Assignments Nondeterministic u;

dest := User.dest; := Crane. ; xt := Crane.xt;

Controller

j u j umax uNmax u uPmin ?! (xt = xt ) u uPmin ?! (xt > xt ) u uNmax ?! (xt < xt )

Re nement denotes, in our view, the two processes of design completing and implementation of design (layering). The process of completing-design forms the main instrument for bridging the gap between an RS and a complete DS. Implementation denotes the process of detail addition of complete designs in order to achieve concreter levels of design (yet not necessary implemented using a programming language). This distinction is based on the fact that it is possible to separate completeness of design from the implementation of it, since the core action of the rst is design-choice while the second's is implementing this choice by existing techniques or detail addition for reasons of concreteness necessary for realistic programexecution.
Design completing

4.6 Designing: Re nement

Design-completing has the goal of limiting the non-determinism in the DS such that it admits only those behaviors the RS admits.
Implementation

30

Implementation of the abstract notions in the DS e.g. algorithms, data structures and model of execution, using concreter notions than those used in the DS, has the goal of getting closer to the detail of the physical level of the system. As mentioned earlier the gap which exists between an RS and a complete DS is often too large to bridge in one step. It is necessary to stepwisely make design choices and add them to the rst (fully non-deterministic) DS. As pointed out by researchers e.g. 34], on the semantical level this process begins with a tautology (representing full non-determinism) which is then limited by conjuncting to it, stepwisely, logical formulae (which has the e ect of limiting the non-determinism). Re nement can be achieved either by change of the transition system (the DS) or by limiting the execution model. The possible actions which can be taken are as follows: 1. Strengthen the guard of an existing transition by conjuncting to it boolean formulae. 2. Strengthen body of an existing transition. The body can be strengthened in the sense that if there is in the assignments some random choice in the values assigned to variables then this is limited (by limiting the domain or elleminating the randomness). 3. Add new variables to the state-variables and do one of the following: a. Add new transitions which do not assign to old variables at all (assign to new variables only). b. Extend old transitions with assignments only on the new variables, or conjunct to their guards formulae on new variables only. c. Do any of a or b but allow either the change of values of old variables (in old or new transitions), or the conjunction of formulae to guards of old transition which refer to old variables. 4. Limit any of the abstract elements of the execution model e.g. scheduling policy (e.g. obligatory chains of states in behaviors), choice of hardware (e.g. level of concurrency), communication method (e.g. synchronous, asynchronous or other). The rst and second actions in the above list result in a DS which ful lls additional properties to those of the original DS. They limit the set of behaviors and result in a DS which ful lls stronger requirements. Clearly such actions may be used during the design completing process. However, the result of application of these actions might also be an empty set of behaviors ! (trivial solutions). Actions a and b of the third element in the list above are denoted superposition in 10], and called respectively the restricted union rule and augmentation rule. Their application on a DS is guaranteed to preserve the old properties fully. The core action of superposition is layering in system design which is an implementation technique. A layer is added on top of another by introducing new variables and transitions which do not alter the old DS. This way an implementation is obtained in terms of other variables than the abstract variables in the original DS. Action c of the third element can be partially achieved using the union operation 10] which is a method of composing speci cations in a controlled manner. The wild application of this action seems unattractive since there are no guarantees with respect to the results 31

of its application beyond those of the union operation of UNITY. We discuss this shortly in section 4.5. As noted often in discussions of design principles by various authors e.g. 10], the last action in the list above should be left to the stage of implementation of design (i.e. implementation beyond the mere re nement of design using superposition). Seperation of complexity from correctness is the main argument behind this principle, as discussed by e.g. Chandy and Misra 10]. The discussion of implementation of design has been done in section 3.3. However, at this point we nd the context of re nement suitable for discussing implementation of design since it can be seen as part of it. Implementation of design is both the implementation of the complete design speci cation and its execution model. It seems that the implementation task should be of both parts by negotiating their implementations. One of our start points in system realization is that we do not assume that the concrete execution model should be a given reality for the software but that it should be left as a choice to be negotiated with the DS during its implementation. For example, during implementation it might seem necessary to limit the scheduling policy. Such limits can be stated as requirements from the scheduling policy, and may take the form of logical formulae. Such requirements from the abstract notions of the execution model can be viewed also as assumptions. They must be ful lled by any chosen concrete notions. For example, if a certain requirement on the scheduling policy is stated during designing, then any later choice of a concrete scheduling algorithm must ful ll it. As can be seen from this discussion, it is necessary to have a speci cation tool for the statements of assumptions (requirements) on (from) the execution model in an implementation language, for enabling the study of the possible design implementations. Re nement constructs, in a design speci cation language, should syntactically re ect both their intended use and the guarantees they provide (e.g. no application of re nement where no guarantees can be provided). Moreover, these constructs must be easy to apply, e.g. Disco 32] advocates extension of speci cations in a syntactically layered manner for application of superposition, rather than the simple approach of direct extension of constructs inside speci cations. The safety property (not OnBorder) can be implemented in various ways and can be realized either by the Controller or by the Crane subsystem. The hard and challenging solution is that the Controller should apply voltage in a controlled way such that the trolley remains between the borders. However, we have chosen for a simpler and easier solution; physical limiters were added on the borders of the rails. Each time the trolley touched these limiters it was braked and the voltage was shut-o . For this reason, an invariant is added to the Crane subsystem. It expresses the need to limit output variable xt when building the physical Crane system. To allow the augmentation of speci cations when re nement is applied we use Re ned as a syntactic construct. It implies that parts of the speci cation are to be modi ed or additions

4.6.1 Example

32

to it are done.

Re ned
Invariants

Crane

j xt j < Range;

As an example of implementing controller's we show the speci cation which re ects the decision to use PID controllers for the crane system. At this level of speci cation, one nds all controller's requirements; these are stated as requirements on it by other subsystems and assumptions it makes on other subsystems. The goal of designing and implementing the controller is to achieve the global requirements of the total system. A PID controller assumes discrete input variables from the environment (i.e. both the user and the Crane physical system). This discritization should be speci ed in the controller part as requirements from its input variables. In addition, the voltage supplied by the controller should assume analog values when it arrives by the Crane subsystem. The last two requirements (resulting from the design decision of using a PID controller) are found in the implementation as A/D (analog to digital) and D/A (digital to analog) converters. In our speci cation however, we have not admitted two kinds of variables such as continuous and discrete and the relation between them (how the discritization is to be achieved). This needs to be explored in further work. In the following speci cation of the PID controller we declared constants but gave them no value yet since these values form the key to the optimization of the controller (i.e. their values should be found out through execution and testing). The decision that the controller recieves (or reads) all input values at the same moment is achieved by one multi-assignment input which consists of the three original input assignments: in1, in2 and in3. This design decision limits the nondeterminism in the execution of assignments. For example, at the new level in1, in2 and in3 must take place at the same time (i.e. In the interleaved execution model only interleavings of the three appear in behaviors. In the concurrent execution model their execution must be synchronized). Scheduling construct using the SCHEDULE construct is the same as in ASTRAL. START, END and quanti cation over execution of commands are also taken from ASTRAL. The schedule part of the GCS speci cation here bellow prescribes for any scheduling policy (chosen for implementation) the (partial) order of commands. Only those policies which schedule commands as prescribed are correct implementations.

33

Re ned
input in1 in2 in3 output

Assignments

Controller Constants GF , b, a, PB, K Locals bias, Corr, : Integer; f* bias and correction variables *g

xt := Crane.xt k := Crane. k dest := User.dest u :=

100 GF PB a

( ? Corr) + bias ?K

Internal1 Internal2

:= dest ? xt k Corr := (b Corr ) + (10 b xt ) + (10 b xt )

bias :=(a bias ) + (1 ? a) u

SCHEDULE Forall k: Integer f START-k (output) > END-k (Internal2) START-k (Internal2) > END-k (Internal1) START-k (Internal1) > END-k (Input)
g
If timing constraints to be speci ed (i.e. using the timed version of a TS) then it is necessary to have the domain Time such as in ASTRAL. This will allow, in addition to the schedule speci ed above, the speci cation of periodical commands (input and output for example are such commands in the implementation of the GCS), and durations for transitions. However, the addition of time has its in uence on the choice of execution model, in our case it is Maximal parallelism (MP). In 34] it is shown that MP is too eager in scheduling and results in behaviors which do not correspond to those considered by the interleaved execution model used for reasoning (i.e. TRIO). This discripancy between the two execution models may be reconciled if MP is restricted as shown in 34]. Although separation of concerns appears last it was in fact, through out the whole report, the strategy which guided us in making the choices of how to model, specify and design systems. At rst we separated requirements speci cation from design speci cation, data from control ow, and execution for reasoning (i.e. interleaving) from actual execution (i.e. real concurrency). Later on we separated correctness from e ciency which, in its turn, implied separation of design completing from implementation, and functional behavior from timed behavior. 34

4.7 Designing: Separation of concerns

Generally speaking, a domain task (e.g. designing systems where designing is the task and systems is the domain) is separable into two (or more) concerns (i.e. subtasks) if the imposition of the one concern on the result of applying the other concern rst achieves the goals of the task (e.g. system requirements if functionality is rst concern and timing is second in designing systems then, their application in this order should achieve system requirements). Separable concerns are often also called orthogonal. We denote the rst concern (more important one) with the term major and the other with the term minor. Separation of concerns is a tool for convinience since people can only deal with so much information a time. It goes hand in hand together with non-determinism; the start point of a task should always be full non-determinism where the application of the major concern limits it partially and the imposition of the minor limits it further. At each point where separation of certain concerns was used in the former sections we explained our choice for separation, its correctness and the way it is to be applied. Hereunder we list only the basic separation of concerns mentioned earlier in the report (for discussion of the other separations we refer the reader to the other sections where they were applied).

Requirements speci cation vs. design speci cation: in our view, designs are operational (for de nitions of the terms operational and axiomatic see section 1). As noted often e.g. 39], operationality in programming (also in designing) is dangerous since experience has shown that it is a way of thinking which may result in leaving things out of consideration. Requirements guide designing and form the start point of system realization. Their speci cation should be more amenable to faults than in the operational approach. A more declarative approach is necessary and the axiomatic approach seems to be a good candidate for that.
Control ow is not a unifying concept 1. Programs for di erent architectures employ di erent forms of control ow. Program design at early stages should not be based on considerations of control ow, which is a later concern. It is easier to restrict the ow of control in a program having few restrictions than to remove unnecessary restrictions from a program having too many. This separation result in two notions: a program and an execution model. The program has no execution notions or control ow (e.g. requirements speci cations in temporal logic) while the execution model dictates the control ow. interleaved semantics for reasoning since it is a simpler model which yet hasn't been proved unsuitable for this purpose. It is simpler to reason about interleaved behaviors than concurrent behaviors. However, actual systems have various parts which execute concurrently. Moreover for reasons of e ciency it is often necessary to execute parts concurrently. Therefore its is necessary to have a concurrent execution (real concurrency) model also. The two models, interleaved and real-concurrency, should be related to each other and should result in equal sets of behaviors for any given program (i.e. there should be one translation scheme which translates each behavior in the one set to a behavior in the other and vice versa).
1

Data vs. control ow: In this respect we quote Chandy and Misra 10]:

Execution for reasoning vs. actual execution: In 35] 34], Kurki Suonio defends

i.e. Unifying concept for programs

35

5 Discussion and last remarks

In this report we discussed a framework for RTC-systems designing. This framework consists of: A modeling strategy for modeling total systems. The strategy is based on the well known closed-system view. A system is modeled as a closed entity in which all interactions which in uence the behavior (as stated in the requirements speci cation) take place internally. Such a model of a system has only observable variables. A dual approach and notation which enables both axiomatic and operational speci cation of systems for the expression of, respectively, requirements and designs of systems. The dual notation is based semantically on temporal logic. The operational part, however, enables the explicit construction of timed state transition systems. A designing method which enables the designing of RTC-systems beginning from requirements and working stepwisely towards full designs. The method enables any interleaved application of bottom-up and top-down designing steps represented by, respectively, stepwise designing and composition of systems. In addition, we identi ed the principles and instrumentation the framework necessitates. These principles are divided into two categories: modeling, speci cation and designing category, and analysis and veri cation category. The rst category consists of: closed-system view, expressibility (of properties, functional design and timing-constraints), nondeterminism, re nement (design completing and implementation of design), modularity (decomposition and composition) and separation of concerns. The second category consists of instrumentation to enable the designer to check whether the RS is consistent and unambiguous, whether the DS is consistent, both internally and with respect to the RS. And in addition, whether the completeness of the DS with respect to the RS is already achieved. In this category we nd: RS and DS analysis and veri cation tools (internal-consistency, unambiguity, simulation, history checks, property proof etc.). In this report we concentrated on the rst category and embedded the instrumentation it implies in a notation which is based on and extends ASTRAL 18] (description of ASTRAL can be found in the appendix). The duality of notations for expressing both requirements and designs underlies many of the existing languages. Temporal logic based languages are most clear in enabling this duality. However, this duality in most existing languages addresses the needs of veri cation only. Expression of requirements and designs in the same framework is not equally addressed as a necessity of designing systems since this last task was not the rst goal from developing these languages either. As a result many of the existing languages which enable this duality may be seen as the nuclea for a framework for designing. For example, ASTRAL and Disco are good candidates as basis for such a framework since they are based on most principles it necessitates. In fact, both languages had big in uence on the choices made in this text. This report was meant in the rst place as a proposal for further research. In this respect the report has posed some questions and made some remarks of which we nd some worth mentioning here. The notations we used, temporal logic for expressing requirements and guarded commands based notation for expressing transition systems, seem to be too abstract for engi36

neers especially the rst. This must be remedied since notations must be easy to use and understand. Furthermore, usability as addressed in section 2.4 should be also studied. It is important to remember that there exist no subclasses of RTC-systems. There are subclasses of requirements speci cations of RTC-systems. A system is real-time, for example, only if the requirements from it make as such. For further discussion on this misconception see 35]. Phase transition systems and a suitable temporal logic are very needed for expressing continuous systems and are being studied. However, the descritization step which often connects a discrete model of a continuous system to the controller should be studied also. One point were we sense weakness in software engineering is in understanding this descritization and in seeing that it results in fact in implicit temporal constraints on the system. It is important that control engineers study their models of descritizing continuous systems and identify the conditions under which these descritizations are valid (i.e. what they require from the controller). These conditions can then be made explicit to help in developing notations for enabling expression of descritizations and their analysis. Global models for control systems such as the feedback loop model and speci c control models such as PID control model, should form the basis for a uni ed structure of abstract speci cations in which the designer only lls in the speci c details. In these speci cations one may nd place to express variables of the model, its entities (e.g. controller, physical system, user) and the connections between them. This also applies to the closed system model as well of course. As discussed in section 3.3, implementation of designs is a point of weakness for formal speci cation languages. This weakness is due to the fact that implementation is often still being done ad hoc. In addition, little has been done to clarify how re nement should lead to implemented systems. Formalizing the process of implementation is as important as formalizing the process of designing and the begin point of the rst of these two should be equal to the end point of the second. In section 3.3 we also expressed the need for studying the relation bewteen process algebras and temporal logics since the operational approach of the rst seems to be closer to implementations than the latter and might help in bridging the gap between designs and implementations.

6 Acknowledgements
I thank Jan van Katwijk and Ronald Huijsman for their comments and discussions on priliminary texts which led to this last version. I also thank Klaas Brink and Gerhard Frensel with whom I conducted experiments and had long discussions. Our work together in the the Beek-project in uenced my knowledge of control systems and my ways of thinking about them. Finally, the sceptism and critique of Hans Toetenel were useful in conducting this work.

37

A ASTRAL

A.1 Introduction

ASTRAL 18] is a formal speci cation language for real-time systems based on the languages ASLAN (RT-ASLAN) and TRIO 18]. The language TRIO is a real-time temporal-logic-based language where dense models of time are allowed. TRIO provides ASTRAL with its formal semantics which are de ned as a translation of ASTRAL speci cations into TRIO speci cations. Quantitative time is incorporated into TRIO by providing two basic operators, Past(F, t) and Future(F, t), which state the truth of F at a time instance, respectively in the future or past, which is separated t time units from the current time (which is left implicit). TRIO's semantics is model-theoretic; the notion of a temporal structure provides an environment where the truth value of a given TRIO speci cation can be evaluated. Executability of TRIO speci cations is based on the constructive tableaux algorithm where the satis ability question for a given speci cation can be decided provided that the time domain and all domains of variables appearing in it are restricted to nite domains. ASTRAL adapted ASLAN's operational generic model of sequential systems to the special needs of speci cation of real-time systems. According to this model a system is a composition of state machines, each corresponding to an intuitive subsystem, connected together through a global state machine to form the entire system. The adaptation of the model was mainly for the purpose of providing the means for specifying timing constraints. For expressing these constraints: each transition is augmented with a duration, start and end-times of executions of transitions are made visible to other transitions when necessary (part of the state variables can also be made visible), and suitable constructs for imposing constraints on the transition function and for specifying schedules and invariants are provided. ASTRAL, being semantically based on TRIO, uses quantitative-temporal-logic formulae to describe the various parts of a state machine (system). The computational model ASTRAL assumes consists of the above mentioned generic model and the following assumptions: 1. Maximal parallelism, noninterruptible and nonoverlapping transitions in a process instance. Each logical process is assumed to operate on its own physical processor and processors are never idle whenever there is a transition to execute. 2. Implicit multicast message passing communication. Each change in the visible part of the state of a process results in broadcasting the change and the start and end-times of the transition which caused it, to all interested processes, the moment this transition's execution ends.

A.2 Language Constructs

An ASTRAL full speci cation of a real-time system corresponds to the generic model for realtime systems mentioned above. It consists of one single GLOBAL SPECIFICATION module and a SPECIFICATION module for every process-type in the speci ed system. A speci cation module is a generic module where a certain subsystem type (process-type) is speci ed 38

of which more than one instance can exist in the system. A global speci cation consists of mainly the declarations of the globally used types and constants, and the scheduling constraints which should be imposed on transitions from di erent process-types. A process-type is expressed in a speci cation module which consists of the following parts: IMPORT part where the names of the imported entities are stated. TYPES and VARIABLE parts. Two parts in which respectively the types and names of state variables are declared. EXPORT part where the speci cation may export some of its state variables but also some of its transitions. CONSTANT part where constants are de ned. CONSTRAINT part in which the functional constraints on transitions are expressed. INVARIANT part in which one expresses the functional constraints that must hold in every reachable state of the speci cation. SCHEDULE part in which one expresses how transitions must be scheduled. Here one can express the timing constrainst. TRANSITION part for each transition where it is given a name, a duration and and an ENTRY and EXIT clauses. The ENTRY clause expresses the enabling condition for the transition while the EXIT clause indicates the value changes in state variables. There are also EXCEPT and EXIT pair which provide the possibility of specifying exceptional cases and the way the transition should be taken. There are four primitive types in ASTRAL: Boolean, Integer, Time and ID. For the type Time, the set of real-numbers but also any numerical set derived from it can be assumed. The type ID can be used for distinguishing between di erent instances of the same process-type; it provides each of the instances with an identity.
Digit TYPEDEF d:Integer (d >= 0 & d <= 9) Digit List IS LIST OF Digit

Figure 9: Example: De nition of new types New types are de ned using the operators TYPEDEF and IS LIST OF. The rst of the two de nes a new type in the same manner a set is de ned in mathematics and the second de nes the set of all lists of a certain type (see gure 9).

39

ASTRAL provides the basic arithmetic and relational operators, the logical connectives ( , j, &, ?!), the two quanti ers FORALL and EXISTS, and a few more operators on the type ID and operators which address temporal aspects of systems. The operator IDTYPE returns the type of its argument which should be of type ID, and by using the operator Self a process can refer to its own identity. The operators which address temporal aspects of systems are few. The operator Now refers to the current time which is always implicit in ASTRAL. As mentioned in the former section, it is possible to obtain the start and end times of executions of certain transitions of a given process. This is done using the operators START and END, which when applied to the label of an exported transition yield respectively the start and end times of its last execution (the variants START-k and END-k refer respectively to the times of the k-th execution before the last). For requiring about the value of state variables at a certain time instance in the past one can use the operator PAST. However, as mentioned before values of statevariables of a certain process are visible to other processes provided that the process exports them explicitly in its EXPORT part. Reference to an exported variable or transition v of SPECIFICATION S by another SPECIFICATION is by the construction S:v (however, if v is not declared anywhere else than S then using the name v is su cient).

References
1] Morzenti A. Validating real-time systems by extending logic speci cations. In RealTime Theory in Practice, Proceedings REX Workshop, LNCS 600, 1991. 2] M. Abadi and L. Lamport. An old-fashioned recipe for real-time. LNCS 600. 3] R. Alur and Th.A. Henzinger. Logics and models of real-time: A survey. LNCS 600, 1991. 4] R.J.R. Back and R. Kurki-Suonio. Serializability in distributed systems with handshaking. LNCS 317, pages 52{66, 1988. 5] R.J.R. Back and R. Kurki-Suonio. Decentralization of process nets with a centralized control. Distributed Computing 3, pages 73{83, 1989. 6] J.C.M. Baeten and J.A. Bergstra. Real time process algebra. Formal Aspects of Computing 3, 1991. 7] B.W. Boehm. Software Engineering Economics. Prentice-Hall International, 1981. 8] K. Brink, R.D. Huijsman, and J. van Katwijk. Seal: a simple language for prototyping action-event speci cations. In B. Gra Mortensen F. Vajda, editor, Proceedings of the 19th Euromicro Conference, Barcelona, Spain, 1993. 9] P. Caspi, D. Pilaud, N. Halbwachs, and J.A. Plaice. LUSTRE: A declarative language for programming synchrounous systems. In Proceedings 14th ACM Symposium on Principles of Programming Languages, pages 178{188. ACM, 1987. 10] K.M. Chandy and J. Misra. Parallel Program Design: A Foundation. Addison-Wesley, 1988. 40

11] E. Ciapessoni, E. Corsetti, A. Montanari, and P. San Pietro. Embedding time granularity in a logical speci cation language for synchronous real-time systems. Science of Computer Programming 20,, pages 141{171, 1993. 12] B. Dasarathy. Timing constraints of real time systems: Constructs for expressing them, methods of validating them. IEEE Transactions on Software Engineering, SE-11(1):80{ 86, January 1985. 13] Jahanian F. and A.K-L. Mok. Safety analysis of timing properties in real-time systems. IEEE TSE, se-12(9):890{904, sep 1986. 14] M. Felder and A. Morzenti. Validating real-time systems by executing logic speci cations in TRIO. IEEE/ACM ICSE 14, 1992. 15] M. Felder and A. Morzenti. Validating real-time systems by history-checking TRIO speci cations. 1992. 16] M. Filiali and Ph.M. Padiou. Unity, as a tool for reactive systems speci cation and derivation. 1993. 17] C Ghezzi, Mandrioli D., and Morzenti A. TRIO: A Logic Language for Executable Speci cations of Real-Time Systems. J. SYSTEMS SOFTWARE, 12(2):107{123, 1990. 18] C. Ghezzi and R.A. Kemmerer. ASTRAL: an Assertion Language for Specifying Realtime Systems. In Proceedings of the Third European Software Engineering Conference, pages mmm{nnn, Milano, Italy, October 1991. 19] C. Ghezzi and R.A. Kemmerer. Executing formal speci cations: the ASTRAL to TRIO translation approach. In Symposium on Testing, Analysis and Veri cation, Victoria, B.C., Canada, October 1991. 20] Mandrioli D. Ghezzi C., Jazayeri M. Fundamentals of Software Engineering. PrenticeHall International Editors, Englewood Cli s, N.J., 1991. 21] N. Halbwachs, P. Caspi, P. Raymond, and Pilaud D. The synchronous data ow programming language lustre. IEEE Proceedings Vol. 79, No. 9, 1991. 22] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The Synchronous Data Flow Programming Language LUSTRE. In Proceedings of the IEEE, volume 79, pages 1305{ 1320. IEEE, 1991. 23] N. Halbwachs, F. Lagnier, and Ch. Ratel. Programming and verifying real-time systems by means of the synchronous data- ow language lustre. IEEE Transactions on Software Engneering, 18, 1992. 24] K.M. Hansen, A.P. Ravn, and H. Rischel. Specifying and verifying requirements of real-time systems. In ACM SIGSOFT 91' Conference on Software for Critical Systems, 1991. 25] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming 8, pages 231{274, 1987. 41

26] T.A. Henzinger, Z. Manna, and Pnueli A. Temporal proof methodologies for real-time systems. In Proceedings of the 18th Annual Symposium on Principles of Programming Languages , pages 353{366. ACM Press. 27] Th. A. Henzinger, Z. Manna, and A. Pnueli. Timed transition systems. LNCS, (600), June 1991. 28] B. Hoogeboom and W.A. Halang. The concept of time in the speci cation of real-time systems. Real-time Systems ENgineering and Applications. 29] M.S. Ja e, N.G. Levenson, M.P.E. Heimdahl, and Melhart B.E. Software requirements analysis for real-time process-control systems. IEEE Transactions on Software ENgineering, 17, No.3, March 1991. 30] H.-M. Jarvinen. Ph.D Thesis: The Design of a Speci cation Language for Reactive Systems. Tampere University of Technology, 1993. 31] H.-M. Jarvinen and R. Kurki-Suonio. Action system approach to the speci cation and design of distributed systems. In Fifth Internatiuonal Workshop On Software Speci cation and Design, pages 34{40. ACM Software Engineering Notes 14, 3, May 1989. 32] H.-M. Jarvinen and R. Kurki-Suonio. Disco speci cation language: marriage of actions and objects. In Proc. 12th International Conference on Software Engineering, Nice, France, March 1990. IEEE Computer Science Society Press. 33] Ostro J.S. Formal methods for the speci cation and design of real-time safety critical systems. The Journal of Systems and Software, April 1992. 34] R. Kurki-Suonio. Stepwise design of real-time systems. SigSoft '91, Conference on Software Speci cation for Control Systems, 1991. 35] R. Kurki-Suonio. Real-time: Further misconceptions or half-truths. Invited paper, Euromicro 5 Workshop, June 1993. 36] R. Kurki-Suonio, K. Systa, and J. Vain. Real-time speci cation and modeling with joint actions. In Proceeding 6th International Workshop on Software Speci cation and Design, Como, Italy, October 1991. 37] R. Kurki-Suonio, K. Systa, and J. Vain. Scheduling in real-time models. Formal Techniques in Real-Time and Fault Tolerant Systems, pages 327{339, 1991. 38] Lamport L. A simple approach to specifying concurrent systems. Communication of the ACM, 32, 1, January 1989. 39] L. Lamport. What good is temporal logic ? In R.E. Mason, editor, INFORMATION PROCESSING 83, volume IFIP. Elsevier Science Publishers B.V. (North Holland), 1983. 40] B.P. Mahony and I.J. Hayes. A case-study in timed re nement: A mine pump. IEEE Transactions on Software ENgineering, 18, No.9, September 1992. 41] O. Maler, Z. Manna, and A. Pnueli. From timed to hybrid systems. LNCS, (600), June 1991. 42

42] Z. Manna and A. Pnueli. The anchored version of the temporal framework. Linear Time, Branching Time, and Partial Order Logics in Logics and Models for Concurrency, LNCS 354, pages 201{284, 1989. 43] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems. Springer-Verlag, 1992. 44] Halbwach N. Synchronous Programming of Reactive Systems. Kluwer Acdemic Publishers, 1993. 45] Plat N. Ph.D. Thesis: Experiments with Formal Methods in Software Engineering. Delft Univeristy of Technology, 1993. 46] Zave P. An insider's evaluation of paisley. IEEE Transactions on Software Engineering, 17, No.3, 1991. 47] J.L. Peterson. Petri Net Theory and the Modeling of Systems. Englewood Cli s, NJ: Prentice-Hall, 1981. 48] A. Pnueli. Applications of temporal logic to the speci cation and veri cation of reactive systems: A survey of current trends. Current Trends in Concurrency, LNCS 224, pages 510{584, 1986. 49] Charette R.N. Software Engineering Environments, Conbcepts and Technology. McGraw-Hill, 1986. 50] W.J. Toetenel. Ph.D. Thesis: Model Oriented Speci cation of Communicating Agents (MOSCA). Delft University of Technology, 1992.

43