Modular refinement of hierarchic reactive machines

Abstract

Scalable formal analysis of reactive programs demands integration of modular reasoning techniques with existing analysis tools. Modular reasoning principles such as abstraction, compositional refinement, and assume-guarantee reasoning are well understood for architectural hierarchy that describes the communication structure between component processes, and have been shown to be useful. In this paper, we develop the theory of modular reasoning for behavior hierarchy that describes control structure using hierarchic modes. From STATECHARTS to UML, behavior hierarchy has been an integral component of many software design languages, but only syntactically. We present the hierarchic reactive modules language that retains powerful features such as nested modes, mode reuse, exceptions, group transitions, history, and conjunctive modes, and yet has a semantic notion of mode hierarchy. We present an observational trace semantics for modes that provides the basis for mode refinement. We show the refinement to be compositional with respect to the mode constructors, and develop an assume-guarantee reasoning principle.

Formalizing UML State Machines for Automated Verification – A Survey

“…While some of these works were discussed in the former survey [BR04], we did not integrate this line of works in our survey, because their semantics differs too much from that of UML state machines. In [AG04], it is explicitly mentioned that the "mode" (as a central component of their behavioral description) has several strong semantic differences with Statecharts and UML state machines: such differences include notably the fact that i) transitions can originate from and target entry/exit points only, ii) a default exit always retains the history, and iii) the priority between transitions differs. In that sense, the semantics of [AG04] is closer to Room [SGW94] than UML state machines.…”

“…In [AG04], it is explicitly mentioned that the "mode" (as a central component of their behavioral description) has several strong semantic differences with Statecharts and UML state machines: such differences include notably the fact that i) transitions can originate from and target entry/exit points only, ii) a default exit always retains the history, and iii) the priority between transitions differs. In that sense, the semantics of [AG04] is closer to Room [SGW94] than UML state machines. In [AY01], hierarchical state machines are discussed; they differ too significantly from UML state machines to be integrated to our survey.…”

“…In [AY01], hierarchical state machines are discussed; they differ too significantly from UML state machines to be integrated to our survey. In [AMY02], hierarchical reactive modules [AG04] are considered. Again, while sharing some similarities with UML state machines, the semantics of actual UML state machines is not discussed.…”

Instruction-Level Abstraction (ILA): A Uniform Specification for System-on-Chip (SoC) Verification

“…Models with formally-defined operational semantics are amenable to formal analyses such as equivalence and property checking. Examples include StateCharts, SystemC, Esterel, Transaction Level Modeling (TLM), and others [1,4,9,14,31,[34][35][36]. A notable effort in this category is BlueSpec, a high-level specification and design language that describes hardware as sets of state change rules (guarded atomic actions) which execute atomically [7,51].…”