El concepto del género gramatical desde una perspectiva cognitiva

Extendability and maintainability are the requirements that notably influenced the architecture. These two requirements are achieved by the chosen division of packages. Each step of the model checking process, that is, parsing, static analysis, state space building, and model checking, is conducted within a single package.

Communication between these packages is conducted by means of well-defined interfaces. Thereby, parts of these processes can be exchanged without the need to change the complete application. For example, model checking is conducted independently of the microcontroller used, and hence, adding new microcontrollers can be done without changing the model checking.

To show that [mc]square is extendable, we already extended it in several directions. The first version of [mc]square used a patched version of a simulator called Avrora [117, 118] to build the state space. Avrora is a cycle-accurate simulator for microcontroller assembly programs written for the ATMEL ATmega16, 32, and 128. We had to change Avrora because it is cycle-accurate and does not natively support nondeterminism. Preserving cycle-accuracy would lead to real-time model checking [14, 71, 72], which suffers even more from the state-explosion problem.

Using the patched version of Avrora, we found out that [mc]square spent 85%

to 95% of the processing time building the state space. Therefore, we decided to concentrate on improving the creation of state spaces instead of the model checking.

Changing Avrora was rather involved because it was built for cycle-accurate simulation of microcontroller programs and not for the creation of state spaces for model checking. Many parts of Avrora were automatically created and not written by hand and thus, these parts were not easy to understand and difficult to change.

Every time a new version of Avrora was published, we had to apply the same changes. In the second version of [mc]square, we exchanged Avrora by our own simulator, which adopted some parts of Avrora, to avoid these changes and to ease the adaption of the state space creation. Our simulator natively handles nondeterminism and builds a safe over-approximation of the behavior shown by the microcontroller. The simulator is implemented within the Simulator package.

Later, we added an additional ATMEL ATmega microcontroller and the Infineon XC167 microcontroller to the Simulator package [100, 103]. In the Model Checker package, we added a local model checking algorithm and an algorithm used to check invariants [103]. The State Space package was extended to store states on hard disk [103, 106]. Furthermore, we added the capability to conduct different static analyses to [mc]square [107]. This was obtained by adding the Static Analyzer package and adapting the procedures using the static analyses. During these extensions, we adapted the architecture of [mc]square to better reflect the requirements of extendability and maintainability. This makes it easier to extend [mc]square in

4.3 Evaluation

the future.

However, extendability has its limits. At present, based on the classification given by Visser [123], all model checking algorithms implemented within [mc]square are explicit, graph-based, structural model checking algorithms. Changing to an automata-based algorithm or to symbolic model checking algorithms is more involved than just changing single parts of a procedure. Schommer [109] tried to extend [mc]square to support symbolic model checking. This try was very involved, but it was not successful in the end. We finally removed it from [mc]square.

It failed because known abstractions, such as modulo and interval abstractions, did not work as expected, and no abstractions that solve this problem could be found within this work. It did not fail due to the architecture of [mc]square.

Schommer [109] gives details in his thesis. Although we were not successful in adding symbolic model checking to [mc]square, we combined explicit and symbolic model checking techniques within [mc]square. Chapter 5 explains the details about the combination of explicit and symbolic techniques.

Our aim is to use [mc]square as a research platform and as a tool that can be applied in industry. Extendability is important because new model checking algorithms, new microcontrollers, and new abstraction techniques have to be added to [mc]square. As described above, [mc]square satisfies the requirement of extendability and maintainability. Additionally, the modular structure enables students to work on parts of [mc]square that they are specialized and interested in. For example, a student interested in static analysis does not have to bother with model checking. Beside extendability, usability is also important for our aim.

The architecture supports usability by hiding all internals except for the CTL specifications from the user via the GUI .

4 [mc]square

5 State Space Building in [mc]square

It turned out that the main focus of this thesis is the domain-specific creation of state spaces for model checking microcontroller assembly code. This includes the application of domain-specific abstraction techniques. In [mc]square, the Simulator package builds the state space. It uses a similar process to build the state space as is used in typical simulators, which simulate the behavior of microcontroller programs.

That is, it simulates the effect of instructions on the model of the microcontroller.

Our Simulator differs in two important respects from other simulators. First, it natively supports nondeterminism and second, it creates an over-approximation of the real behavior of the microcontroller to preserve validity of the model checking results. We integrated abstraction techniques into the Simulator to limit the size of the state space already during creation.

Another purpose of the Simulator is to hide microcontroller peculiarities from the other packages of [mc]square. Thus, the other packages can access the micro-controller or the states of the micromicro-controller without considering the peculiarities of the respective microcontroller. Hence, the other packages of [mc]square are implemented hardware independently.

This chapter describes the modeling of the ATMEL ATmega16 microcontroller within the Simulator. The general structure and functionality of the Simulator is similar for all microcontrollers. Different microcontroller models only vary in hardware-dependent details such as memory, external devices, instructions, and interrupts.

The first section gives an overview of the Simulator package. Section 5.2 describes the states that are used within the Simulator. The subsequent sections detail the four important parts of the Simulator package. First, the model of the microcontroller (Sect. 5.3) and the model of the program (Sect. 5.4) are described. These two are the representation of the real microcontroller and the real program within [mc]square.

Then, the creation of successor states, which is done by the InstructionSimulator, is explained in detail in Sect. 5.5. Section 5.6 details the Determinizer, which handles nondeterminism within the Simulator. Section 5.7 describes the formal model of the Simulator. Then, this formal model is used to establish the correctness of the delayed nondeterminism abstraction technique. Section 5.8 presents related work regarding model checking of assembly code and delayed nondeterminism.

We published the general idea of using a simulator to build a state space in several papers [102, 103]. Furthermore, we outlined the ideas presented in Sect. 5.6

5 State Space Building in [mc]square

fake

InstructionSimulator

Microcontroller

Program

Determinizer

ATMega ATMega16

ATMegaProgram

ATMegaInstructionSimulator ATMega16InstructionSimulator

ATMegaDeterminizer ATMega16Determinizer SimulatorState

Visual Paradigm for UML Standard Edition(RWTH Aachen)

Figure 5.1: Classes of the Simulator package related to the ATMEL ATmega16 microcontroller.

in another paper [60] and published a summary of the formal model described in Sect. 5.7 elsewhere [60, 88].

5.1 Simulator Overview

The Simulator package generates states for model checking by simulating the effects of instruction executions on the model of the microcontroller. Additionally, the Simulator package provides facilities for the other packages to access the microcon-troller model through well-defined interfaces. Thus, other packages do not have to deal with the peculiarities of the different microcontrollers.

Figure 5.1 gives an overview of the Simulator package. It is a UML class diagram [12, 17, 61, 113, 119] depicting the topmost classes of the Simulator package. Minor classes are omitted for clarity. On the left side of the figure, the superclasses are shown, and on the right side of the figure, the specialized subclasses are shown. We follow this guideline in all UML class diagrams shown in this chapter.

The Microcontroller class and its subclasses represent microcontrollers and their different features within [mc]square. In these classes, for instance, the memory, the registers, and the external devices are modeled. Section 5.3 provides details on the modeling of these different features. The program run on the microcontroller is