This article describes the semantics of the language of statecharts as implenented in the STATEMATE system [Harel et al. 1990; Harel and Politi 1996]. The initial version of this semantics was developed by a team about.10 years ago. With the added experience of the users of the system it has since been extended and modified. This executable semantics has been in operation in driving the simulation, dynamic tests, and code generation tDols of STATEMATE since 1987, and a technical report describing it has been available from i-Logix, Inc. since 1989. We have now decided to revise and publish the report so as to make it more widely accessible, to alleviate some of the confusion about the "official semantics of the language, and to counter a number of incorrect comments made in the literature about the way statecharts have been implemented. For example, the survey [yon der Beek 1994] does not mention the STATEMATE implementation of statecharts or the semantics adopted for it at all, although this semantics is different from the ones surveyed therein (and was developed earlier than all of them except for Harel et al. [1987]). As another example, Leveson et al. [1995] describe a case that exhibits an unacceptable kind of behavior in a statechart, which they say is what the "semantics of statecharts" leads to (pp. 695-697). Unfortunately, they base their discussion of statechart semantics on one of the many semantics proposed by various authors (that of Pnueli and Shalev [1991]) and give the reader the impression that this is the official semantics of the language

We characterize high-performance streaming applications as a new and distinct domain of programs that is becoming increasingly important.

This paper describes a formal analysis technique, called consistency checking, for automatic detection of errors, such as type errors, nondeterminism, missing cases, and circular definitions, in requirements specifications. The technique is designed to analyze requirements specifications expressed in the SCR (Software Cost Reduction) tabular notation. As background, the SCR approach to specifying requirements is reviewed. To provide a formal semantics for the SCR notation and a foundation for consistency checking, a formal requirements model is introduced; the model represents a software system as a finite state automaton, which produces externally visible outputs in response to changes in monitored environmental quantities. Results are presented of two experiments which evaluated the utility and sealability of our technique for consistency checking in a real-world avionics application. The role of consistency checking during the requirements phase of software development is discussed.

Copyright © 2006, by the author(s).

In this paper, we present our experiences in using symbolic model checking to analyze a specification of a software system for aircraft collision avoidance. Symbolic model checking has been highly successful when applied to hardware systems. We are interested in whether model checking can be effectively applied to large software specifications. To investigate this, we translated a portion of the state-based system requirements specification of Traffic Alert and Collision Avoidance System II (TCAS II) into input to a symbolic model checker (SMV). We successfully used the symbolic model checker to analyze a number of properties of the system. We report on our experiences, describing our approach to translating the specification to the SMV language, explaining our methods for achieving acceptable performance, and giving a summary of the properties analyzed. Based on our experiences, we discuss the possibility of using model checking to aid specification development by iteratively applying the technique early in the development cycle. We consider the paper to be a data point for optimism about the potential for more widespread application of model checking to software systems.

This paper studies the semantics of hierarchical finite state machines (FMS's) that are composed using various concurrency models, particularly dataflow, discrete-events, and synchronous/reactive modeling. It is argued that all three combinations are useful, and that the concurrency model can be selected independently of the decision to use hierarchical FSM's. In contrast, most formalisms that combine FSM's with concurrency models, such as Statecharts (and its variants) and hybrid systems, tightly integrate the FSM semantics with the concurrency semantics. An implementation that supports three combinations is described.

: The state/transition paradigm has been used extensively for the description of event-driven, parallel systems. However, the lack for hierarchic structure in such descriptions usually prevents us from using this paradigm in a real programming language. We propose the Argos language for reactive systems. The basic components of a program are input/output-labeled transition systems verifying reactivity (a property similar to input-enabling in IOautomata) . The composition operations (parallel composition and refinement, providing hierarchy) are based upon the synchronous broadcast mechanism of Esterel. We define the language formally in an algebraic framework, and give an operational semantics. The main result is the compositionality of the semantics; we prove that the bisimulation of models induces an equivalence which is a congruence for the operators we propose. An interesting point is the way we introduce hierarchy in a compositional way. 1 1 Introduction The problem ...

This paper is a survey of our specification and verification techniques, in a very general, language independent, framework. Section 1 introduces a simple model of synchronous input/output machines, which will be used throughout the paper. In section 2, we show how such a machine can be designed to check the satisfaction of a safety property, and we discuss the use of such an observer in program verification. In section 3, we use an observer to restrict the behavior of a machine. This is the basic way for representing assumptions about the environment. Applications to modular and inductive verification are considered. In modular verification, one has to find, by intuition, a property of a subprogram that is strong enough to allow the verification of the whole program without fully considering the subprogram. In section 4, we consider the automatic synthesis of such a property, and in section 5, we investigate the possibility of deducing the subprogram from such a synthesized specification.

We present an expressive agent design language for reinforcement learning that allows the user to constrain the policies considered by the learning process.The language includes standard features such as parameterized subroutines, temporary interrupts, aborts, and memory variables, but also allows for unspecified choices in the agent program. For learning that which isn’t specified, we present provably convergent learning algorithms. We demonstrate by example that agent programs written in the language are concise as well as modular. This facilitates state abstraction and the transferability of learned skills. 1

Esterel [8, 10, 3, 4] is an imperative synchronous parallel programming lan guage dedicated to reactive systems [17]. Esterel is tailored for programming hardware or software synchronous controllers for which the control-handling aspects are predominant. Esterel programs are input-driven: they wait for inputs and compute corresponding outputs in a cycle-based way. An in put-output computation is called a reaction...