Verifying OSEK/VDX Applications: An Optimized SMT ... - IEEE Xplore

Verifying OSEK/VDX Applications: An Optimized SMT-based Bounded Model Checking Approach ∗ School

† School

Haitao Zhang∗ , Zhuo Cheng† , Cong Tian‡ , Yonggang Lu∗ , and Guoqiang Li§

of Information Science and Engineering, Lanzhou University, China, {htzhang, ylu}@lzu.edu.cn of Information Science, Japan Advanced Institute of Science and Technology, Japan, [email protected] ‡ ICTT and ISN Laboratory, Xidian University, China, [email protected] § School of Software, Shanghai Jiao Tong University, China, [email protected]

Abstract—OSEK/VDX, a standard of automobile OS, has been widely adopted by many manufacturers to design and implement a vehicle-mounted OS. Currently, with increasing functionalities in vehicles, more and more complex applications are developed based on the OSEK/VDX OS. However, how to ensure the reliability of developed applications is becoming a challenge for developers. Based on our previous work, in this paper we present an efficient approach to verify the developed OSEK/VDX applications. In the presented approach, SMT-based bounded model checking technique is used to carry out verification in order to handle complex applications. Moreover, a series of optimization strategies are proposed and employed to improve the checking capability of our approach. We have implemented a tool according to the proposed approach and conducted many experiments. The experiment results show that our approach is capable of checking the safety property of large-scale OSEK/VDX applications. We also compared our approach with existing checking method, the comparison results indicate that our approach is an efficient and powerful technique in verifying OSEK/VDX applications. Keywords—OSEK/VDX Application; Deterministic Scheduler; Bounded Model Checking; SMT

I.

I NTRODUCTION

OSEK/VDX [1], a standard of automobile OS, has been widely adopted by many automobile manufacturers to design and develop a vehicle-mounted OS, such as BMW, Volkswagen and Toyota. With the increasing demands for driving fun and safety in vehicles, more and more complex applications are developed based on the OSEK/VDX OS. However, how to ensure the reliability of the developed OSEK/VDX applications is becoming a challenge for developers with the increasing complexity in the development. To ensure the reliability of OSEK/VDX applications, model checking [2] as an exhaustive technique can be adopted to verify the developed OSEK/VDX applications. However, it is hard to use model checking to verify a large-scale OSEK/VDX application which holds a lot of states because of the state space explosion (an experience report can be found in our previous work [3]). As to overcome the state space explosion, SMT-based bounded model checking (BMC) [4] as a more powerful technique has been applied to verify large-scale sequential software [5] and general multi-threaded software [6]. Unfortunately, the existing methods cannot be employed to verify OSEK/VDX applications, since the execution characteristics of OSEK/VDX application are different from sequential software and general multi-threaded software. E.g., in contrast Zhuo Cheng is the corresponding author.

978-1-5090-0806-3/16/$31.00 copyright 2016 IEEE ICIS 2016, June 26-29, 2016, Okayama, Japan

External Environment (
 

) Application (multi-tasks) Task Task Task Task

Configuration File API(e.g., ActivateTask(t))

OSEK/VDX OS Event Process Scheduler Module ready queue Module 
    Resource Process Module 

Fig. 1.

The structure of an application running on OSEK/VDX OS.

to sequential software, OSEK/VDX application is a multi-tasks software. Moreover, compared with the general multi-threaded software, OSEK/VDX adopts a deterministic scheduler to dispatch tasks within applications (non-deterministic scheduler is used to dispatch threads in general multi-threaded software). If we employed existing SMT-based BMC methods for checking multi-threaded software to verifying OSEK/VDX applications, it is too imprecise1 because a lot of unnecessary interleavings of states will be checked in the verification. To successfully apply advanced SMT-based BMC to verify OSEK/VDX applications, we have proposed an initiative approach in our previous work [7]. In the approach, a technique named execution path generator (EPG) is used to construct checking model (transition system) for target OSEK/VDX application. Although the proposed approach can handle largescale OSEK/VDX applications, it is not able to verify a practical application, e.g., the application that can communicate with external environment such as receiving an input, as shown in Fig. 1. In addition, the optimization strategies for boosting checking efficiency and capability are not considered in the verification process. Furthermore, an automatic verification tool is not implemented. In this paper, as to make our approach more efficient and practical, we continue our work and the following improvements are integrated into our approach. 1 In general multi-threaded software, the running thread cannot be explicitly determined because non-deterministic scheduler is used to dispatch threads. To exhaustively verify such multi-threaded software, in model checking the constructed checking model holds all of possible state interleavings of threads. In contrast to non-deterministic scheduler, the running task is explicit in OSEK/VDX application since deterministic scheduler is adopted to dispatch tasks.

•

To improve the efficiency of our approach, static single assignment (SSA) [8] is applied in EPG in order to reduce the cost of constructing checking model. • Two optimization strategies in the scheduling level for cutting unnecessary task states and accelerating the speed of bug detection are proposed and used in our approach. • To automatically carry out verification, a corresponding tool named osek-bmc2 is developed in our work. We have investigated the efficiency and capability of our approach based on many experiments. The experiment results show, the improved approach is more efficient and capable than our previous method in verifying the large-scale OSEK/VDX applications, especially when optimization strategies are valid in the verification process. We also compared our approach with the Spin-based checking method [3]. The comparison results indicate that our SMT-based BMC is more powerful than the method in handling the OSEK/VDX applications which hold a large number of states. Note that, our approach is not limited to OSEK/VDX applications, it also can be applied in the multi-tasks/threads software in which a deterministic scheduler is adopted to dispatch tasks/threads. To the best of our knowledge, there is no work that considers a SMT-based BMC method to verify the software like OSEK/VDX applications. The main contributions of our paper are, (i) we firstly apply SMT-based BMC in the scope of deterministic scheduler based multitasks/threaded software; (ii) our two optimization strategies present an estimable example to optimize the verification of deterministic scheduler based multi-tasks/threaded software. The rest of the paper is structured as follows. The preliminaries of OSEK/VDX OS and a motivating application are presented in section II. Based on the discussion about the execution characteristics of the motivating example, EPG technique in our previous work is described in section III. The improvements of our approach are demonstrated in section IV. As to evaluate our approach, the experiments are carried out in section V. Related work is discussed in section VI. Conclusion are placed in the last section. II.

P RELIMINARIES OF OSEK/VDX OS AND A PPLICATION

A. OSEK/VDX OS A general OSEK/VDX OS consists of a scheduler module, synchronization event process module and shared resource process module, as shown in Fig. 1. Based on these system modules, OSEK/VDX OS supports a standardized application interfaces (APIs) for user to develop customized applications. The overview of OSEK/VDX OS is presented below. 1) Scheduler module: OSEK/VDX OS can process two types of tasks, basic task and extended task. The states of a basic task consist of running state, suspended state, and ready state. Compared with basic task, the extended task can hold synchronization events and has a unique state called waiting state. In the scheduling process, static priority scheduling policy with non-preemptive and full-preemptive strategies is adopted by scheduler to conduct the executions of tasks, and moreover, scheduler manages a ready queue to lay out the execution order of tasks. Besides, scheduler can respond to four service APIs 2 http://www.jaist.ac.jp/∼s1320205/osek-bmc.htm



 !
#
#
#
$ 
!,'()

'
43
()



22$



!"! '!-($

*

 )



22$



!"! '!.($

*

!"! '!/($

! '($ * 
!-'()

'
4
+(



%%$

 



22$

! '($ * 
!.'()

3$

3'2(&$

! '($ * 
!/'()

 !'
4
($

! '($ *

Fig. 2.

  

  
!,)

3 $

3$

  30$

 3$ *$ 
!)

3 $

3 $

  31$

 3$ *$ 
!. )

3 $

3 $

  3/$

 3$ *$ 
!/ )

3 $

3 $

  3/$

 3$ *$

Motivating example.

(T erminateT ask, ActivateT ask, ChainT ask, and Schedule) invoked from tasks to switch task states. For instance, the service API ActivateT ask(t) is invoked by running task to activate a suspended task t, scheduler will move task t from suspended state to ready state. 2) Synchronization event process module: There are three service APIs (SetEvent, W aitEvent, and ClearEvent) that can be responded by synchronization event process module, and tasks can invoke these service APIs to implement the synchronous executions. E.g., when running task t1 invokes API W aitEvent(evt1 ) to waits for an unhappened event evt1 , running task will stop its executions until the waited event evt1 is set by other tasks (basic tasks or extended tasks) using service API SetEvent(t1 ,evt1 ). 3) Shared resource process module: OSEK/VDX OS adopts Priority Ceiling Protocol to coordinate the behaviors of task accessing shared resources in the resource process module. The resource process module supports two service APIs (GetResource and ReleaseResource), and tasks can invoke these two APIs to create a critical section for accessing a shared resource. B. OSEK/VDX Application and Execution Characteristics As shown in Fig. 2, an OSEK/VDX application consists of two files, one is the source file, and the other is the configuration file. The source file is used to present the concrete behaviors of the application, which can be developed by C programming language. The configuration file is used to define tasks, synchronization events, and shared resources. As to clearly comprehend the execution characteristics of OSEK/VDX applications, the motivating application shown in Fig. 2 is symbolically executed below. 1) Executions of Motivating Application: In the motivating application shown in Fig. 2, only the attribute AUTOSTART of t1 is set to be TRUE. That is, only task t1 starts from ready state in the initial state, and other tasks start from suspended state. Thus, t1 will be firstly moved to running state by scheduler and then executed in the initial state. As shown in




  

"!

"!    

  





  

  

  
 

"



   

        

"



   

   

     

   

 
"


   

ʌ1 Fig. 3.



   

!

 
"


 
"


        

  

       

ʌ2

Task CFGs

EPG Stack

Config. File

! 

       

Source File

ʌ3

Execution tree of the example shown in Fig. 2.

Fig. 3, when the service API ActivateT ask(t2) is invoked by t1 (the branch (b >= a) is chosen to symbolically execute), scheduler will be loaded to respond to the service API (task t2 is moved from suspended state to ready state). At this moment, the running task t1 will be preempted by t2 since the attribute SCHEDUL of t1 is set to be FULL, which means task t1 can be preempted by higher priority tasks, and the priority of t1 is lower than t2 (the context switch happens after the service API ActivateT ask(t2)). Currently, task t2 will be executed, and goes to suspended state when the service API T erminateT ask()3 is invoked. When task t2 terminates itself, scheduler will dispatch task t1 to run from preempted point. Then, task t4 is activated by API ActivateT ask(t4) (the context switch will not happen, since the priority of task t4 is less than t1). Finally, task t4 is executed after running task t1 terminates itself. Based on the conducted symbolic executions, we can get a task execution sequence t1, t2, t1, t4 in the execution path π1 and π2 . Accordingly, if the service API ActivateT ask(t3) is invoked by task t1 (the branch !(b >= a) is chosen to symbolically execute), we can get a different task execution sequence t1, t3, t4 in the execution path π3 . 2) Execution characteristics: According to the symbolic executions of the motivating application, we can easily find the following execution characteristics. • Running task within OSEK/VDX application is explicitly determined by scheduler according to the task priority and configuration data, and invoked APIs will dynamically change the scheduling of tasks. • The different service APIs locating at different branches will lead to different task execution sequences, and the context switch of tasks may happen when a service API is invoked by running task. As we know, the key work of using SMT-based BMC to verify a target system is how to construct a transition system (checking model). Based on the above execution characteristics, there 3 T erminateT ask() is used to terminate the executions of a task, and the terminated task will be moved from running state to suspended state by scheduler. If the running task is terminated, scheduler then dispatches the head task in the ready queue to run when ready queue is not empty.

Fig. 4.

OS Model

Bounds

Execution Paths Transition System SMT Z3

The key processes of EPG.

are several challenges that should be addressed when applying SMT-based BMC to verify OSEK/VDX applications, e.g., (i) how to implement the behaviors of OSEK/VDX OS such as the scheduling behaviors; (ii) how to deal with the service APIs within tasks. As to overcome these challenges, we proposed an approach in our previous work [7]. In the approach, a technique named execution path generator (EPG) is used to construct transition system. The summary of EPG technique is demonstrated in the next section. III. S UMMARY OF EPG A. Overview of EPG The key processes of EPG are shown in Fig. 4. As to easily analyze an application, we firstly use control flow graph (CFG) to describe behaviors of tasks within application. According to the execution characteristics of OSEK/VDX applications, we have found that the different service APIs locating at different branches will lead to different task execution sequences. Then, EPG explores all of possible execution paths of target application in order to precisely construct a transition system. In particular, as to implement behaviors of OSEK/VDX OS, an OS model corresponding to the OSEK/VDX specification is embedded in EPG to respond to invoked service APIs and conduct the executions of tasks. Finally, SMT solver Z3 [9] is employ to check whether the constructed transition system satisfies a given property or not. Note that, like other bounded model checkers such as CBMC [10], the depth bound and loop bound are also supported by our approach. The details of EPG have been presented in our previous work [7]. B. Task CFG DEFINITION 1 (CFG of task): The CFG of a task is a tuple tid tid Ωtid =(N tid , ntid , Rtid ). Where, tid is the identifier 0 , ne , Σ of tasks. N tid is the set of locations, ntid 0 ∈ N is the start location, ntid ∈ N is the end location. Σtid is the set of e statements of task tid, the expression of a statement α ∈ Σtid is as follows: α ::= condition | assignment | goto | assertion | API Rtid ⊆ N tid×Σtid×N tid is the set of directed edges labelled by task statements. E.g., the CFGs for the motivating application are shown in Fig. 5. C. EPG and Transition system According to the execution characteristics of OSEK/VDX applications, we have to address two problems in order to apply SMT-based BMC to verify OSEK/VDX applications, one is how to implement the behaviors of OSEK/VDX OS, and the other is how to deal with service APIs invoked from tasks. To solve these two problem, we embed an OSEK/VDX OS model in EPG (checking algorithm flat) to conduct the executions of tasks, and the embedded OS model is called to respond to APIs invoked from tasks, i.e., when running task invokes a service API, the embedded OS model will be called to respond





  





  



 




 





               



          

      


 

 

 Fig. 5.

Fig. 6.

to the invoked API. In addition, since the different service APIs locating at different branches will lead to different task execution sequences, we explore all of possible execution paths based on stack to construct a precise transition system for target application, e.g., for the motivating application, EPG will generate three execution paths which have been illustrated in Fig. 3. The definition of execution path is state below. DEFINITION 2 (execution path): an execution path π is the α α α α task statement sequence π = s0 −→ s1 −→ s2 −→ s3 −→ ···, where s is the state consisted of values of variables, α ∈ Σtid is the statement of tasks. Based on the generated execution paths, we can construct a k-step transition system for the target application. Here, we use function [[πj ]]k to convert an execution path πj into CNF expression under depth bound k. The CNF expression for an execution path πj is defined in the formula (1), where Lsi ,si+1 represents a task statement α mapped in the edge si ,si+1 of execution path πj . According to the formula (1), we can construct a transition system [[M ]]k for the given application when translating all of the execution paths into CNF expression. The expression of the constructed transition system [[M ]]k is defined in the formula (2), where I(s0 ) is the initial function used to initialize each global variable and local variable declared in the target application, w is the number of execution paths. k 

[[Lsi ,si+1]]

i=0

[[M ]]k := I(s0 ) ∧ (

w 

[[πj ]]k )

The SSA form for the system with branches.

shown in Fig. 6, in BMC the transition system is not established on the execution paths, instead, the static single assignment (SSA) [8] technique is usually used to recode the branches into linear structure. In this paper, in order to reduce the cost of exploring execution paths, we apply SSA to linearize the branches without APIs before exploring paths. E.g., for the motivating application, EPG just explores two execution paths if we apply SSA to linearize the branches within task t2.

The task CFGs for the motivating application.

[[πj ]]k :=

Ÿ

SSA Form     

 

(1) (2)

j=1

IV. B OOSTING EPG USING O PTIMIZATION S TRATEGIES A. Reduction of Execution Paths Based on the execution characteristics of OSEK/VDX applications, we have found that the different APIs locating at different branches will lead to the different task execution sequences. In our previous work, we explore all of possible execution paths in order to construct a transition system for target application. Although we can obtain a precise transition system, EPG should spend much cost exploring execution paths if the target application holds a lot of branches, which will slow down the performance of our approach. Actually, as

B. Acceleration Bug Detection According to the execution characteristics of the OSEK/VDX applications, we can found: the invoked service APIs will dynamically change the scheduling data within OSEK/VDX OS (e.g., service API ActivateT ask() will change the data in ready queue), and the changed data may lead to the different task execution sequences in the future. However, there is a particular service API T erminateT ask() that will not lead to the different task execution sequences, because it will not change the scheduling data. In other words, the service API T erminateT ask () will not change the states of other tasks. If a task just holds API T erminateT ask(), it thus will not change the task execution sequence. In our paper, we name this type of tasks as pure task. Moreover, based on the pure task, an optimization strategy named acc-sch is proposed to accelerate the speed of bug detection. The key idea of acc-sch strategy is to make scheduler firstly dispatch the pure tasks that hold assertions. E.g., as shown in Fig. 7, there are two pure tasks t1 and t2 in the same queue, scheduler can firstly dispatch task t2 in order to accelerate bug detection. In the example, tasks t1 and t2 are independent (see DEFINITION 3), and task t2 holds an assertion in contrast with task t1. Therefore, we can swap the execution order of tasks t1 and t2, and the swapping process will not alter the intrinsical execution behaviors. Based on the shown example, we can stipulate the swapping condition, that is, if two adjacent tasks t and t are pure tasks and locate at the same priority-queue, and t and t are independent with each other, then the execution order of t and t can be swapped in the scheduling queue. DEFINITION 3 (independence of two tasks): two tasks t={R, W } and t ={R , W  }, if and only if the accessed variables satisfy the condition R ∩ W  =  and R ∩ W =  and W ∩ W  = , tasks t and t are independent, where R and W are the sets of read-variables and write-variables of task, respectively. C. State Reduction In addition to the acc-sch strategy, as to make our approach more scalable, we propose an other optimization strategy named cut-task to cut the unnecessary task states. The key idea of the cut-task strategy is that, if a pure task does not hold assertions and it is independent with other tasks, the states of the task can be reduced in the process of constructing execution paths. The process for detecting the unnecessary tasks from application is as follows,

 
#&  
# &



















"











""!# 



!#"



!#"

' ' %
$$ 

 
 

Application Source File

Config. File

 



EPG Unfolding loops according to the loop bound





 # Fig. 7.

OSEK/VDX OS model

The example for acc-sch strategy

initialize two sets P and Q, where P is the set of unnecessary tasks. step 2 for each task t within application, do: if task t is pure task and the task does not hold assertions, then P = P ∪{t}; otherwise, Q = Q∪{t}. step 3 if ∃t ∈ P and ∃t ∈ Q are not independent, then Q = Q∪{t}, P = P \{t}. Repeat step 3 until there is no new task that is put into Q. In the process of constructing execution paths, as to avoid the states of an unnecessary task to be mapped in the execution paths, OS model can directly move the task into suspended state when it becomes the currently running task. E.g., for the motivating application, we can reduce the states of task t2 in the process of constructing execution paths.

Bounds 





Execution path constructor

acc-sch strategy

 

cut-task strategy

step 1

D. Implementation We have developed a tool named osek-bmc according to the proposed approach. The tool consists of five modules, implemented on the Visual Studio 2010 with 9400 lines of C++ code. The architecture of osek-bmc is shown in Fig. 8. In the first module, as to conveniently applied our approach to verify an OSEK/VDX application, we develop a front-end interpreter to interpret the behaviors of tasks within the application into the corresponding CFGs based on the C intermediate language (CIL) [11] (the interpreter for now can accept the main characteristics of C programming language except pointer, struct and function calls). The second module is to unfold loops within tasks according to the loop bound. The third module is used to linearize the branches without APIs based on the SSA technique. The fourth module is to implement the functionality of EPG, where optimization strategies acc-sch and cut-task are used to reduce the unnecessary task states and accelerate bug detection. The last module is to call SMT solver Z3 to check whether the constructed transition system satisfies a given property or not, if not, a counterexample will be reported, especially the depth-first strategy is adopted to perform the verification in order to improve the capability of our approach. Furthermore, as to simulate the external environment, an interface function random(low, high) is supported by the implemented tool, e.g., we can use “var=random(1, 10)” to simulate the input of variable var whose value is in [1, 10]. V.

E XPERIMENTS AND D ISCUSSION

A. Experiments An OSEK/VDX application usually consists of tasks, APIs, loops, synchronization events and shared resources. In the experiments, as to comprehensively investigate the effectiveness of our approach on the realistic applications, the applications

 


execution path transition system

  
  





 
  

Fig. 8.

The architecture of osek-bmc

which hold different task number, API number and loop number are selected as our benchmarks. In addition, as to really represent the execution behaviours of an OSEK/VDX application, the non-preemptive scheduling behaviour, fullpreemptive scheduling behaviour, mix-preemptive scheduling behaviour, synchronous behaviour, and accessing shared resource behaviour are also taken into account in the selected benchmarks shown in TABLE I. Furthermore, assertions as given properties are inserted into the selected benchmarks. In the experiments, our Spin-based checking method [3] and EPG technique without SSA, acc-sch and cut-task strategies are considered as our comparison objects. All of the experiments are conducted on the Intel Core(TM)i7-3770 CPU with 32G RAM, and we set the time limit and memory limit to 1000 seconds and 1GB, respectively. The benchmarks used in the experiments and osek-bmc are available at http://www.jaist.ac.jp/∼s1320205/osek-bmc.htm. Note that, in osek-bmc, the max depth is set to “20,000,000”, and the loop bound is set to 10. In Spin-based checking method, the “C compiler” of Spin is set to “-DVECTORSZ=16384 DBITSTATE”, and the max depth is set to “20,000,000”. The experiment results have been listed in TABLE I. In the result table, #t is the number of tasks, #l is the number of loops, #API is the number of invoked APIs, #s is the number of explored states. “Mb” is the memory consumption measured in Mbyte, “time” is the time consumption measured in second. M.O. and T.O. represent time out and memory out, respectively. B. Discussion According to the conducted experiments, we can find that the Spin-based checking method fails to verify the benchmarks which hold a lot of tasks and APIs (e.g., lines 4, 12 and 20). This is because, in Spin-based checking method, the checking model is a combination model of OSEK/VDX OS model and application model, where OS model is used to conduct the executions of tasks and respond to invoked APIs. In the verification, Spin will not only check the behaviors of application, but also verify the OS model, which will limit the checking capability extremely. Compared with Spin-based

C OMPARISON : S PIN - BASED CHECKING APPROACH , PLAIN OSEK - BMC , IMPROVED OSEK - BMC

TABLE I. benchmark 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

msgp1 safe msgp2 bug msgp3 safe msgp4 bug token1 safe token2 bug token3 safe token4 bug rw var1 safe rw var2 safe rw var3 safe rw var4 safe sync1 safe sync2 safe sync3 bug sync4 safe acc res1 safe acc res2 safe acc res4 bug acc res3 safe

size #t 6 8 10 18 4 6 9 13 5 9 13 13 5 8 11 12 2 9 12 13

#l 0 0 0 0 4 6 9 13 5 9 13 12 4 7 10 11 3 9 12 13

Spin-based approach #API 11 14 17 35 61 101 161 241 101 161 241 13 14 23 32 42 4 320 25 480

#s 4652 25253 103835 20501 34371 46990 13541 2443 24159 210841 382329 13907 -

Mb 17.7 81.1 303 2.45 126 138 M.O. 54.7 M.O. M.O. M.O. 11.6 86.8 612 998 56.5 M.O. M.O. M.O.

checking method, our improved SMT-based checking approach is more scalable and efficient, because (i) the state-of-the-art SMT solver Z3 is used to perform the verification, and (ii) only the behaviors of application are checked in verification (i.e., OS model is embedded in EPG (checking algorithm flat) to conduct the executions of tasks and respond to invoked APIs). In addition, in contrast with our plain SMT-based checking approach, the improved approach is more efficient in verifying the applications which hold a lot of loops, e.g., the plain approach runs out of time in checking the benchmarks listed in lines 8, 11, 20. This is because, in the improved approach, SSA technique is employed to reduce the cost of exploring execution paths, especially the strategies acc-sch and cuttask are applied to speed up the bug detection and reduce the state space. These efforts make our improved approach more efficient. Overall, the experiment results indicate that our approach is an efficient and practical technique in verifying the large-scale OSEK/VDX applications. VI.

osek-bmc

time 0.21 0.71 2.67 T.O. 0.10 1.12 1.26 0.44 0.15 0.78 5.37 9.62 0.46 -

is presented in paper [12]. However, this method is not able to handle large-scale applications because of state space explosion (like our Spin-based method [3]). Compared with the method, our approach applies SMT-based BMC to carry out verification, it is more scalable. In the scope of verifying multi-threaded software, there exist several model checking methods [6][13]. Even so, these methods cannot precisely verify OSEK/VDX applications, since these methods focus on the non-deterministic scheduler. If we directly employ the existing methods to verify OSEK/VDX applications (the deterministic scheduler is used in OSEK/VDX OS), spurious bugs will be usually found in the verification. In contrast with the existing works, our approach can precisely verify OSEK/VDX applications. VII. C ONCLUSION In this paper, we presented an approach that can formally verify OSEK/VDX applications based on SMT-based BMC. Particularly, as to make our approach more efficient and practical, a series of optimization strategies are applied in our

Mb 2.17 2.18 2.19 2.22 2.26 2.23 2.41 2.30 2.41 2.34 2.22 2.27 2.31 2.33 2.32 2.41 2.34 -

time 0.29 0.35 0.49 0.58 43.4 139 192 78.4 450 13.4 4.02 7.14 10.7 11.9 88.8 509 13.9 -

osek-bmc acc-sch & Mb 2.17 2.18 2.19 2.13 2.26 2.23 2.41 2.48 2.30 2.41 2.45 2.34 2.22 2.27 2.31 2.33 2.32 2.41 2.34 2.54

cut-task time 0.29 0.35 0.49 0.56 43.4 139 192 463 78.4 450 190 5.95 4.02 7.14 7.17 11.9 88.8 509 6.09 665

approach, such as SSA technique, state reduction and acceleration bug detection strategies. In addition, a tool named osekbmc is implemented in our work according to the proposed approach. We have conducted many experiments using osekbmc, the experiment results indicate that our approach is an efficient and practical checking technique in verifying largescale OSEK/VDX applications. ACKNOWLEDGE This work is partially supported by the National Natural Science Foundation of China (Grants No. 61272213). R EFERENCES [1] [2]

[3]

R ELATED W ORK

With the development of OSEK/VDX OS standard, OSEK/VDX has been widely applied in the vehicles. To verify the developed OSEK/VDX applications, an UPPAAL-based method

#s 89 55 157 145 2470 2283 6417 T.O. 3259 6459 T.O. 940 336 585 458 917 3491 6779 552 T.O.

SSA & #s 89 55 157 89 2470 2283 6417 5513 3259 6459 4979 472 336 585 326 917 3491 6779 282 1332

[4] [5]

[6]

[7] [8] [9] [10] [11]

[12]

[13]

J. Lemieux, Programming in the OSEK/VDX Environment. Suite 200 Lawrence, KS 66046, USA: CMP, 2001. E. M. Clarke, O. Grumberg and D. E. Long, “Model Checking and Abstraction,” ACM Transactions on Programming Languages and Systems, vol. 16, no. 5, pp. 1512–1542, 1994. H. Zhang, T. Aoki and Y. Chiba, “A Spin-based Approach for Checking OSEK/VDX Applications,” 3rd International Workshop FTSCS in ICFEM, pp. 187–202, 2014. A. Biere, E. M. Clarke and Y. Zhu, “Bounded Model Checking,” Advances in Computers, vol. 58, no. 11, pp. 117–148, 2003. A. Armando, J. Mantovani and L. Platania, “Bounded model checking of software using SMT solvers instead of SAT solvers,” STTT, vol. 11, no. 1, pp. 69–83, 2009. L. Cordeiro and B. Fischer, “Verifying Multi-threaded Software using SMT-based Context-Bounded Model Checking,” ICSE’ 11, pp. 331– 340, 2011. H. Zhang, T. Aoki, et al., “SMT-based Bounded Model Checking for OSEK/VDX Applications,” 20th APSEC, pp. 307–314, 2013. R. Cytron, J. Ferrante, et al., “An efficient method of computing static single assignment form.” POPL’89, pp. 25–35, 1989. Leonardo de Moura, Nikolaj B., “Z3: An Efficient SMT Solver,” 14th TACAS, pp. 337–340, 2008. D. Kroening, M. Tautschnig, “CBMC-C Bounded Model Checker,” 20th TACAS, pp. 389–391, 2014. G. C. Necula, et al., “CIL: Intermediate Language and Tools for Analysis and Transformation of C Programs,” Compiler Construction, pp. 213–228, 2002. L. Waszniowski, Z. Hanzlek, “Formal verification of multitasking applications based on timed automata model,” Real-Time Systems, pp. 39–65, 2008. A. Cimatti, A. Micheli, I. Narasamdya and M. Roveri, “Verifying SystemC: A software model checking approach,” FMCAD, pp. 51–59, 2010.