Formal Validation of Hierarchical State Machines against Expectations Ian Toyn Andy Galloway Dept of Computer Science, University of York, Heslington, York, YO10 5DD, UK {ian,andyg}@cs.york.ac.uk Abstract This paper explains some analyses that can be performed on a hierarchical finite state machine to validate that it per- forms as intended. Such a hierarchical state machine has transitions between states, triggered by conditions over in- puts, with outputs determined per state in terms of inputs. Intentions are captured per state as expectations on input values. These expectations are expressed using the same condition language as transition triggers, extended to con- strain rates of change as well as ranges. The analyses deter- mine whether the expectations are consistent and whether the state machine conforms to the expectations. For the analyses to find no problems, the explicit expec- tations on the root state will be at least as strong as the im- plicit expectations of the state machine. One way of using the analyses is to reveal these implicit expectations. The analyses have been automated for statecharts built with The MathWorks’ Stateflow tool. 1. Introduction In model-based design, models should be validated against intentions and corresponding code should be veri- fied against the model. This paper is concerned with the validation of models that are built as hierarchical finite state machines (section 2). It explains some analyses that can be performed on a hierarchical finite state machine to validate that it performs as intended [6]. Each state of the state machine can be annotated with the designer’s expectations for that state, then the analy- ses determine whether the expectations are consistent and whether the state machine conforms to the expectations. When a tool implementing an analysis finds an inconsis- tency or non-conformance, a counter-example may be re- ported. This counter-example guides the designer to correct the state machine or to mend the expression of expectations. For the analyses to find no problems, the expectations that have been made explicit as annotations on the root state will be at least as strong as what the state machine implic- itly expects of the environment in which it operates. Further validation is required to determine whether those expecta- tions are satisfied by the operational environment. The analyses have been automated by extensions to The MathWorks’ Stateflow tool [18]. The user chooses when to initiate analyses. They are performed by automatic theorem proving techniques, covertly to the user. When these tools find a problem, the user is notified and usually a counter- example is presented. The next section defines the notations to be analysed. Section 3 provides some context concerning a problem do- main (modelling control systems) and a solution domain (Stateflow). Section 4 presents an example to illustrate the analyses and what they can reveal, then section 5 formalises the analyses in general terms. The extensions to Stateflow to support the analyses are illustrated in section 6. Valida- tion of a state machine’s expectations of its environment is considered in section 7. The paper ends with assessments of the analyses and tools. 2. State machines and expectations The hierarchical state machines for which analyses are defined in this paper comprise basic states, grouped hier- archically by exclusive-or states. States are connected by transitions. Transitions have trigger conditions over inputs, local variables and constants, which can be of integer and boolean types. Outputs and local variables have their values defined per state. Transitions may be drawn via junction connectors (but the presentation of the analyses assumes that any connectors have already been expanded away). This set of notations is a syntactic subset of what is usu- ally called hierarchical state machines or statecharts. (Stat- echarts were introduced by Harel [7] as finite state machines extended with hierarchy, concurrency and communication.