In this section, we present our approach to develop mechatronic systems using the FOCUS theory and its implementation, according to the design methodology, presented in the precedent section. Figure 4.2 illustrates the structure of our generalized development approach in a top-down manner. The boxes represent artefacts that have been developed and the arrows show which other artefacts are derived. The process starts by structuring initial requirements using specific syn- tactic patterns: this first step raises the level of precision by transforming the free text requirements into a structured form using specific pre-defined syntactic pat- terns, as presented in Fleischmann (2008).
An informal specification consists of a set of words, which can be classified into two categories: content words and keywords. Content words are system-specific words or phrases, e.g., “Off-button is pressed”. The set of all content words forms the logical interface of the system with its environment, which can be understood as a special kind of domain specific glossary that must be defined in addition.
Keywords are domain-independent and form relationships between the content words (e.g., “if”, “then”). Thus, a semi-formal specification consists of a number of requirements described via textual patterns, which can be easily understood even by engineers unfamiliar with formal methods. Using this description to structure the informal specification, missing information can be already discovered. Further- more, possible synonyms are identified that must be unified before proceeding to a
formal specification. Analysis of the semiformal specification document should also detect sentences, which need to be reformulated or extended. This specification can now be schematically transformed to a Message Sequence Charts (MSCs) representation, as an optional step relevant for highly interactive systems. Our approach for the development of embedded system was already used in industrial case studies (Campetelli and Spichkova2012).
The methodology proceeds with the translation of semi-formal specification to AutoFOCUS 3. As mentioned above, AutoFOCUS 3 is a modelling tool based on the semantics and the model of computation of the FOCUS modelling theory.
AutoFOCUS 3 supports the development of reactive, software-intensive, embedded systems and is implemented on top of the Eclipse3platform. In this tool, systems are modelled by software architectures composed of components with executable behaviour descriptions. AutoFOCUS 3 supports timed synchronous components with a discrete notion of time, that is, a subdivision of time in logical ticks or steps, in which the model components synchronously interact according to global clocks.
Development views in the tool support viewpoints from the SPES matrix. A requirement framework called Model-based Requirements Analysis (MIRA) sup- ports the specification of system requirements informally guided by templates (Teufl et al. 2013). The following formalization step of these informal Fig. 4.2 A representation of our generalized modelling approach
3http://www.eclipse.org
specifications is done using a set of integrated formal notations. This way the requirement specifications show a complete and structured description of system behaviour.
From the formal requirements is derived a hierarchy of system functions and sub-functions, and their behaviour. The requirements interface guide the mapping from requirements to functions and become part of the interface of the functions.
The functional architecture of the system is then a set of functions and their relations. The functional model is given by a set of communicating systems, each one with a defined interface and an implementation.
The realization of the functions of the functional architecture is modelled in the logical architecture. The logical architecture is a network of interconnected logical components, which can be also hierarchical structured in subcomponents. Each component has an interface composed by a set of i/o ports and its behaviour is specified by a relation between the input messages and output messages. The components exchange typed messages instantaneously through i/o ports. The inter- face of the components in the logical architecture has ports and types that are more technical in comparison to the functional architecture. One of goal of our modelling approach is to obtain comprehensive functional and logical architectures of the system. In these architectures, a fundamental step is to determine the context of the system and the relevant properties of the system environment.
We model with AutoFOCUS 3 two kinds of specifications: a formal specifica- tion of system requirements and corresponding architecture specifications. This prepares the basis to verify the system architecture specifications against the requirements using model checking techniques. The requirements specification is schematically translated to temporal logic or specification patterns, which gives basis to model-check the model (Campetelli et al. 2011). Model checking in AutoFOCUS 3 supports the following features: tight coupling of verification properties with model elements, visualization and simulation of counterexamples, and different specification languages for the formulation of properties. Formalized requirements are checked against the functional and logical architectures with automated analysis techniques, as simulation, formal verification, and model- based testing.
Finally, we proceed from the logical to the technical level, where we split our model into software and physical components. Hardware aspects are captured in a topology model, which describes execution and transmission units such as elec- tronic control units and bus systems. A deployment model allocates components to execution units and allows generating C code of the system, which can be compiled and installed into the demonstration hardware. We have shown that the C program produced by the AutoFOCUS 3 code generator is a reasonable simulation of the model. Altogether, the methodology guides us from an informal specification via stepwise refinement to a verified formal specification, a corresponding executable verification model, and a C code implementation.