3.4 Parallel Runtime Verification Framework (PRVF) Model
4.2.1 Assertion Points
Assertion points is a mechanism that enables systems engineer/analyst to gather information within a source code of these systems to analyse their behaviour over time. Assertion points get asserted after every state which is a mapping between variables and their values. A set of variables which is used to express the property of interest has to be determined. After that, the assertion points get inserted directly after the value assignment to these variables. Figure 4.3
illustrates assertion points general mechanism where B1and B2are the assertion points to reflect
the change of code chunk of C1.
Figure 4.3: Assertion Points and Chunks [301]
Assertion points generate data which reveal information at runtime about a system under scrutiny. This information includes States and Time Stamps:
• States information maps between the variables that express a property and their values. This mapping technique has the format hVar, Vali, for instance:
hP id, 1ihRW, 0ihAddr, 3i
where three variables hPid, RW, Addri and their values h1, 0, 3i are inserted respectively. The inserted variables represent a processor identification Pid, Read or Write operation RW, Memory Address Addr. These variables are part of the cache controller case study which is intended to be studied in Chapter5. The above assertion point reveals that a cache controller system creates a request to read (RW= 0 read, RW= 1 write) a memory address
Memory[Addr] and this request is assigned to a processor which has a Pids value 1. This generation of information can then reveal and check whether a system’s behaviour is either satisfying or violating a certain property which has to be met.
• Time Stamps information maps between different assertion points where variables and their values within these assertion points are changed and to record at what time a change has occurred. A system’s clock is used to obtain time stamps. In addition to variable and values parameters, a time stamp parameter is included to form sets of triples instead of pairs. The triple format is hVar, Val, Time Stampi, for instance:
hP id, 1, 8ihRW, 0, 8ihAddr, 3, 8i · · · Code Chunk · · · · hP id, 1, 9ihRW, 0, 9ihAddr, 3, 9i
where the assertion points add a time stamp value to show a change of the asserted data between time unit 8 and 9. Time stamps could be in microseconds, seconds, minutes, hours etc. When a memory address, Memory[3], has changed its value within these time stamps, then a judgement in regards of a property of interest can be made.
The determination of a location and number of assertion points within a source code is still manual and relies on systems engineer/analyst’s understanding of a system under scrutiny [300]. The mechanism of capturing and interpreting assertion points is illustrated in Figure4.4. There are two components which are intended to receive assertion data generated by assertion points within a source code of a system, and then split them accordingly into three groups.
The groups as the figure illustrates are variable name, value, and time stamps. The first component is Data Capture, and it captures the assertion data as strings and then forwards them
Figure 4.4: Processing Assertion Points [301]
to Data Interpret component. The string has the following format:
!PROG: assert variable name: value: time stamp: !
The above clause has a set of markers. Each marker has a meaning as follows: “!PROG” This marker indicates that assertion data are generated from a program. “assert” indicates the data being asserted.
“:” The colon symbol separates the asserted data.
“!” The exclamation symbols terminates the assertion data clause.
Based on these markers, a Data Interpret component divides the strings into three groups which are variable name, value, and time stamps. Then these assertion data are sent to Tem-
pura interpreter in order to execute them and then send the corresponding output to the monitor. Listing4.1illustrates how assertion points look like within a Java external program.
Listing 4.1: Generating Assertion Points within Java Program
1 class AssertionPoints {
2 public static void main(String[] args) {
3 int Pid,RW,Addr,Timestamp;
4 Pid=1;RW=0;Addr=3;Timestamp=9;
5 System.out.println("!PROG: assert Pid:"+Pid+":"+Timestamp+":!");
6 System.out.println("!PROG: assert RW:"+RW+":"+Timestamp+":!");
7 System.out.println("!PROG: assert Addr:"+Addr+":"+Timestamp+":!"); }
8 }
The assertion points in line 5, 6, and 7 within Listing 4.1inserts three variables names and their values in addition to the time stamp’s value. The variable set is hPid, RW, Addri, while the value set of these variables is h1, 0, 3i respectively to their variables names in addition to the time stamp value which is 9. The external Java program represents a system to analyse. AnaTempura allows systems to be plugged-in with Tempura interpreter via a monitor. To associate an external program with a Tempura file, line 3 within Listing4.2has to be placed here. Figure4.5illustrates a successful compilation of an external Jave program via AnaTempura which is plugged in to a Tempura program. Once a Java external program is executed, a string of assertion data is sent to
Tempura program after they get captured and interpreted accordingly. Tempura has a mechanism that allows the assertion data to be assigned to a list of variables within the Tempura program intended to be checked via specific functions. These functions are listed in lines 4, 5 and 6 within Listing4.2. The function in line 4 is intended to pass variable names. The function in line 5 is intended to pass values of those variables, while the functions in line 6 are intended to pass the time stamps in seconds. These functions allow us to pass the assertion data through them and assign the received values to internal variables to be deployed internally.
Listing 4.2: Collecting Assertion Data within Tempura Program
1 load "../library/conversion".
2 load "../library/exprog".
3 /* java AssertionPoints 0 */
4 define avar(X) = {X[0]}.
5 define aval(X) = {X[1]}.
6 define atime(X) = {strint(X[2])}.
7 set print_states = true.
8 define get_var(Variable,Value,Timestamp) = {
9 exists T : {
10 get2(T) and
11 Variable = avar(T) and
12 Value = strint(aval(T)) and
13 Timestamp = atime(T) and
14 format("Assertion data <%s, %d, %d> are received!\n",Variable,Value,Timestamp)
15 }
16 }.
17 /* run */ define Test() = {
18 exists Variable,Value,Timestamp: {
19 {get_var(Variable,Value,Timestamp) and len(0)};skip;
20 {get_var(Variable,Value,Timestamp) and len(0)};skip;
21 {get_var(Variable,Value,Timestamp) and len(0)}
22 }
Once Tempura runs a test in line 17 within Listing4.2, the monitor shows the assertion data imported to the test. The assertion data, which has been asserted within an external Jave program, are successfully printed out within the monitor as Figure4.6illustrates.
Figure 4.6: RUNNINGTEMPURA PROGRAM