select other options to lower memory consumption such as different compression levels and storage of states on hard disk.
[mc]square presents counterexamples, which are created during model checking, in the assembly code, in the control flow graph of the assembly code, in the C code, and as a state space graph. Hence, users can pick the representation that suites their needs best. In each of these representations, they can analyze the values of registers, I/O registers, and variables and the truth values of the formulas.
4.2 Architecture
This section describes the current architecture of [mc]square, which was developed to reflect the requirements shown in Sect. 3.3. Figure 4.1 shows the layered archi-tecture of [mc]square as a UML package diagram [12, 17, 61, 113, 119] consisting of the six basic packages: Parser, Static Analyzer, Model Checker, State Space, Simulator, and Graphical User Interface (GUI ). For clarity, we left out support packages such as Util, Error, and Exception, which execute miscellaneous supporting functions such as array operations, compression algorithms, or hard disk operations.
The relations between the packages shown in the figure are access relations. In the implementation, the packages shown in Fig. 4.1 are directly mapped to Java packages.
Every step of the model checking process is implemented in a separate package.
Additionally, the Simulator and the State Space are separated into single pack-ages. The communication between packages is conducted by means of well-defined interfaces. Therefore, single parts of the process can be exchanged independently.
By separating the Model Checker and the Simulator, model checking is conducted independently from the underlying microcontroller.
In the following, a short description of each of the six packages is given. Chapters 5–
7 detail the three important packages: Simulator, Static Analyzer, and Model Checker.
GUI The GUI serves two purposes. First, it handles the interaction with the user.
That is, it presents data to the user and gets input from the user. The user can, for example, load files, edit formulas, simulate programs, model check programs, and inspect counterexamples. The second purpose of the GUI is to control the different processes used in [mc]square. That is, it starts, for instance, static analysis, simulation, and model checking. The different processes are implemented as threads within the corresponding packages. The GUI uses the observer pattern [47] to collect the data that is presented to the user. Furthermore, we implemented the model-view-controller pattern to separate the data (model) from its representation (view).
4 [mc]square
[mc]square
Model Checker
Parser Static Analyzer
State Space
Graphical User Interface Simulator
fake
Visual Paradigm for UML Standard Edition(RWTH Aachen)
Figure 4.1: The layered architecture of [mc]square.
4.2 Architecture
Parser The Parser package provides capabilities to parse different file formats, such as ELF, and logics, such as CTL, and to transfer them into the corresponding internal representations used throughout [mc]square. It is, for example, used to process programs and formulas provided by the user.
Static Analyzer The Static Analyzer conducts different static analyses and abstrac-tion techniques and annotates the program. It is used before model checking.
The Simulator uses the annotations to limit the size of the state space during creation. Furthermore, the Static Analyzer creates a control flow graph of the assembly code, which is, for instance, used to present the counterexample.
Chapter 6 details the Static Analyzer.
State Space The State Space package is used to store the states. It uses the Simulator to create successor states on demand. The State Space contains different state space implementations. Some use the main memory, whereas others use the hard disk to store the states. The interface to access the State Space is independent from the method used to store the states. Hence, model checking is implemented independent from the method used to store the states.
Chapter 7 describes details of the State Space.
Simulator The Simulator package serves different purposes. First, it is used by the State Space package to create successors of given states. When creating successor states, the Simulator natively handles nondeterminism and creates an over-approximation of the behavior exhibited by the corresponding micro-controller. This is important to preserve the validity of the formulas checked.
Most of the abstraction techniques, which are used to limit the size of the state space, are implemented within the Simulator. The second purpose of the Simulator is to allow other packages to get information about the mi-crocontroller and the program without the need to implement specifics of the different microcontrollers and programs. We implemented three different microcontrollers within the Simulator. Chapter 5 presents the internals of the Simulator.
Model Checker The Model Checker conducts the actual model checking. In this package, the different model checking algorithms are implemented. Currently, it includes a global and a local model checking algorithm and an algorithm to check invariants. Depending on the chosen algorithm, states are created before model checking or on-the-fly during model checking. The Model Checker does not manage the creation of states. It only requests states from the State Space, which creates states using the Simulator if required. Moreover, the Model Checker is responsible for the creation and processing of counterexamples.
Chapter 7 details the Model Checker.
4 [mc]square