This section describes the requirements that our model checker for microcontroller assembly code has to satisfy. Table 3.2 presents the non-functional requirements (qualities)1, and Tab. 3.3 shows the functional requirements1.
The aim of our development is a model checker that serves two purposes. First, it is usable by developers working in industry, which are not familiar with the application of formal methods. Second, the model checker serves as a research tool that can be utilized to evaluate new algorithms and abstraction techniques. These
1We use the terms functional requirement and quality as defined by Bass et al. [12].
3.3 Requirements for an Assembly Code Model Checker
two purposes are reflected by qualities Q1 and Q2. These two qualities implicate other qualities and requirements. Extendability (Q3–Q6) in different directions is an implication of both qualities. The model checker is extendable to support new microcontrollers to be applicable in industry. Moreover, it is possible to integrate existing simulators into the model checker. To use the model checker as a research tool in academia, it is extendable to use other model checking algorithms and abstraction techniques. Since there are different operating systems used in industry and academia, the tool is executable on the three major operating systems (Q7).
Table 3.2: List of non-functional requirements.
Number Requirement
Q1 The model checker is usable by developers working in industry, which are not familiar with formal methods.
Q2 The model checker is usable as a research tool in academia to evaluate new algorithms in different areas (e.g., model checking, static analysis, simulation of systems).
Q3 The model checker is extendable to support new microcontrollers.
Q4 It is possible to use external simulators to build the state space.
Q5 The model checker is extendable to support new model checking algorithms.
Q6 The model checker is extendable to support new abstraction techniques.
Q7 The model checker works on the following operating systems: Microsoft Windows, Mac OS, and Linux.
Q1 and Q2 are the driving qualities (see Bass et al. [12]) of our model checker’s de-velopment. These two qualities implicate most of the functional requirements shown in Tab. 3.3. To support users of the model checker, arbitrary assembly programs (F1) for certain microcontrollers (F2 and F3) are supported without the need to manually prepare them. Debug information in Dwarf [40] or Stabs [46] format is used to map information from assembly code to C code (F4). Specifications are given in CTL (F5), and it is possible to use atomic propositions about registers, I/O registers, and variables (F6). For every program under verification, the specifications is stored in a list (F7). To minimize the size of the state space and to evaluate abstraction techniques, the model checker implements different abstraction techniques (F8).
The tool provides a GUI (F9). Within this GUI, users are able to choose between various abstraction techniques, model checking algorithms, and state compression techniques (F10). Counterexamples are presented in source code (assembly and C), as a state space graph, and in the CFG of the assembly code (F11). Within all these representations, users are able to step through the counterexample and to survey in each state the values of registers, I/O registers, variables, and formulas (F12).
3 Model Checking Software for Microcontrollers
Table 3.3: List of functional requirements.
Number Requirement
F1 The model checker accepts arbitrary microcontroller assembly code files given in ELF file format as input.
F2 The model checker first supports the ATMEL ATmega16 microcontroller. Other microcontrollers, such as the ATMEL ATmega128 and Infineon XC167, are added later.
F3 The model checker supports all constructs found in assembly code for the supported microcontrollers.
F4 The model checker handles debug information given in Dwarf or Stabs format to map information between assembly and C code.
F5 The model checker accepts specifications given in CTL.
F6 The model checker allows to use propositions about registers, I/O registers, and variables within the specification.
F7 For every program under verification, users are able to store a list of specifications.
F8 The model checker implements different abstraction techniques (e.g., dead variable reduction and path reduction).
F9 The model checker provides a GUI.
F10 User are able to choose between different abstraction techniques, model checking algorithms, and state compression techniques.
F11 Counterexamples (witnesses) are presented in the source code (assembly and C), as a state space graph, and in the CFG of the assembly code.
F12 Users are able to step through the counterexample and to analyze the values of registers, I/O registers, variables, and formulas.
The requirements presented in this section are the basis for the development of our model checker. The next chapter describes the model checker [mc]square, which is the result of this development.
4 [mc]square
[mc]square stands for Model Checking MicroControllers. It is a discrete CTL model checker for microcontroller assembly code. We have developed [mc]square at the embedded software laboratory during the last four years. It is written in Java as one requirement is that the model checker is usable on any of the three major operating systems. Currently, we are using Java SE 6.
This chapter gives an overview of [mc]square1. Section 4.1 presents the features of [mc]square. The subsequent section details the architecture of [mc]square. In the end, we evaluate the chosen architecture in Sect. 4.3.
We published a preliminary version of this architecture in a paper [103].
4.1 Features
[mc]square is a discrete CTL model checker for microcontroller assembly code.
Following, a list of the main features of [mc]square.
• Supported microcontrollers – ATMEL ATmega16 – ATMEL ATmega128 – Infineon XC167
• Inputs
– Assembly program given as an ELF file – Specification given as a CTL formula
• Stepwise simulation of the program
• Model checking by means of three different algorithms – Global
– Local – Invariant
1We use revision 2233 of [mc]square in this thesis unless otherwise quoted.
4 [mc]square
• Abstraction techniques to tackle the state-explosion problem – Dead variable reduction
– Delayed nondeterminism – Lazy interrupt evaluation – Lazy stack evaluation – Path reduction
• Minimization of memory requirements via
– Compression algorithms such as run-length encoding and ZIP compression – Storage of states on hard disk
– Incremental storage of states
• Presentation of Counterexamples (witnesses) in – Assembly code
– Control flow graph of the assembly code – C code
– State space graph
At present, [mc]square handles assembly code of the following microcontrollers:
ATMEL ATmega16, ATMEL ATmega128 and Infineon XC167. It handles programs given in Executable and Linking Format (ELF) [116] and the specifications given as CTL formulas. The specification may contain propositions about registers, I/O registers, and variables (including C variables). Additionally, [mc]square checks for stack overflows, stack underflows, and non-intended use of microcontroller features such as write access to reserved registers. Furthermore, users can use [mc]square to stepwise simulate the assembly program.
We have implemented three explicit model checking algorithms in [mc]square:
a global CTL model checking algorithm presented by Clarke et al. [33], a local CTL algorithm first introduced by Vergauwen and Lewi [121] and later adapted by Heljanko [57], and an algorithm used to verify invariants. Section 7.1 describes details of the applied model checking algorithms.
During state space creation, [mc]square uses various abstraction techniques to lower the size of the state space. These abstraction techniques include, for example, dead variable reduction, path reduction, and delayed nondeterminism. Chapters 5–7 give detailed descriptions of the implemented abstraction techniques.
The users can choose the abstraction techniques that are applied during model checking. Thereby, they are able to adjust the granularity of the abstraction used and hence, influence the size of the resulting state space. Furthermore, they can