Using Online Model Checking Technique for ... - Science Direct

Available online at www.sciencedirect.com

ScienceDirect Procedia Computer Science 94 (2016) 404 – 409

The 2nd International Workshop on Communication for Humans, Agents, Robots, Machines and Sensors (CHARMS 2016)

Using Online Model Checking Technique for Survivability, Evaluating Different Scenarios on Runtime Mauricio Gomeza,*, Yongho Kima, James Goppertb, and Eric T. Matsona a

M2M Lab, Computer and Information Technology, Purdue University, West Lafayette, USA. b FDCHS Lab, Purdue University West Lafayette, Indiana, USA

Abstract Survivability or detecting and predicting failures for humans or animals is a matter of instinct. Unlike for robots, machines, or anything that bases its rationality in software, that assumption is not applicable, yet. In this paper we apply model checking techniques to avoid future complete malfunctioning. Scenarios where non existing states are evaluated in order to find solution to possible future problems. A model checker is used for online evaluation of all the states, including possible non-existing transitions and states. © by Elsevier B.V.by This is an open © 2016 2016Published The Authors. Published Elsevier B.V.access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Conference Program Chairs. Peer-review under responsibility of the Conference Program Chairs Keywords: Model checking; System survivability; Online Verification;

1. Introduction Although the field of robotics is still in an early stage, researchers have to make sure that solutions involving machines are reliable. In other words, to be trustworthy enough to autonomously interact with humans or other machines and not stop working when unexpected situations arise. Much research has been done on the verification and validation of individual systems. Nevertheless, online verification during unexpected situations for standalone systems study is still undergoing. Problems are becoming more complex-intensive, resource-demanding, costly, and * Corresponding author. Tel.: +1-765-494-8259. E-mail address: [email protected]

1877-0509 © 2016 Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Conference Program Chairs doi:10.1016/j.procs.2016.08.062

Mauricio Gomez et al. / Procedia Computer Science 94 (2016) 404 – 409

error-prone. Scenarios like a robot in real life are needed to be faced, detected, and lead into auto-corrected actions in order to avoid complete future malfunctioning. In this paper we focus in making a proof of concept on online verification towards survivability scenarios. Simulated scenarios are used to show that model checking is still a promising technique to implement self-* capabilities to machines and robots in a near future. The remainder of this paper is organized as follows. In section 2 concepts and previous work is presented. A description of the system design is then explained in section 3. While in section 4 it is explained how the tests or experiments took place. After that, in section 5 a short results discussion is presented. Finishing with conclusions and future work in section 6. 2. Related Work We start this section with a brief description of the terminologies and technologies that this field comprehends. 2.1. Autonomous Behavior Authors such as Arkin1, believe that behavioral or intelligent robots can be studied through two different system spectrums. On one hand, reactive or reflexive systems require low-level intelligence and simple computation. Hence, it leads to an instant responsive action. On the other hand, the other spectrum, deliberative or purely symbolic, is based on representation which implies a high-level of intelligence (cognitive), which, leads to slow and much studied answers. Meticulous time response studied adaptation takes latency and time dimension into consideration to make decisions. In this work we focus on the second spectrum where the agents or the system as a whole executes actions to avoid disruption of service. According to Geffner2, the basic problem of autonomous behavior is determining “what actions to take next”. The same author continues stating that there are three approaches in AI for next action studies. Programming-based, where the programmer assigns directly by coding the next action; learning-based, that is induced by the experience, let this be by itself, by other “instructors” agents or reinforced; and model-based, which is derived from a model of the actions, sensors, and goals. Autonomous behavior, mentioned by Psaier and Dustdar 3, should be able to operate and administer the whole system based on taking the adequate actions. The same authors continue stating that both trends of autonomic computing and self-adaptive agree on a combination of awareness of internal and external states allowing proper adaptation. The self-* concept was firstly coined in one executive Tek Reports as stated in 3,4. The Paradigm of self-* includes four self-properties tied to self-managing systems: Self-configuring, self-healing, self-optimization, and selfprotection. 2.2. Self-adaptive / Self-protection / Self-healing Gosh et al.5 defines a self-healing system to the ones that have capabilities to detect a non-expected situation. Detection is not enough up to now, also detecting should be done in running-time. This classification of systems is also considered as recovery oriented computing. Continuous availability is the driver for enhancing some systems with self-healing mechanism. Huebscher and McCann4, defined IBM's MAPE-K autonomic loop. MAPE-K contains the functions of monitor, analyze, plan, execute and knowledge. Detecting, diagnosing and recovery are the stages identified. Policies can be action, goal, or utility functions. 2.3. Verification One of the most reliable methods to perform detection on the stages mentioned in self-healing approaches, is formal verification. Verification techniques arose when the need of exhaustive software and hardware testing became impractical. It is considered applied mathematics for modeling and analyzing Information and Communication Technology (ICT) systems.

405

406


It is well known that catching software or system errors in early stages is more beneficial for the accomplishment of the goals. Camurati, Prinetto, and Torino6 determined that in formal verification at design stage the designer specifies what the system under development should do and how it should do it. What the system should do is called its specification, while any one of the possible devices that realizes the specification is called an implementation. The same authors continue stating that verification is mostly done using two different classes: safety and liveness properties. Safety properties are related to assure that wrong situations should be always avoided. Liveness properties concerned with the possibility of correct status will occur in the future. Verification techniques can be grouped into three: theorem proving, model checking, and testing 7. Theorem proving, which allows showing correctness of programs similarly as a proof in mathematics shows correctness of assumptions. Hence, it is manual and requires too much time. Model checking is an automatic approach usually applied to finite state machines or automata. Testing is more precise and diverse, but developed for specific purposes, which some other authors call monitoring tools. 2.4. Model Checking For Baier and Katoen8, model checking is a formal verification technique which allows for desired behavioral properties of a given system to be verified on the basis of a suitable model of the system through systematic inspection of all states of the model. It bases its results in a model of the system and a specification that will be verified if either it is satisfied or not. The same authors continue indicating that the process for model-checking consists of three phases: The modeling phase which requires a model of the system and a formal characterization of the property to be checked. Models of systems describe the behavior of systems and are mostly expressed using finite-state automata, consisting of a finite set of states and a set of transitions. In model checking temporal logic is used as a property specification language of system properties. Functional correctness, reach-ability, safety, and real-time are properties used in temporal logic. The running phase starts setting up the correct initializing values for the options and directives, followed by an exhaustive revision of all the states of the system model. The analysis phase which can have three possible outcomes: success, failure of the model or the computer ran out of resources to execute the complete exercise. Model checking is based on temporal logic that was devised by philosophers for making statements about changes in time9. A wide variety of applications have appeared as model checkers such as: SPIN 10, NuSMV11, PRISM12,13, DiVinE14, and many others. Recently, the study of model checkers grew very fast as it is stated in the benchmark done by Pelánek 15. Out of 80 papers that were found in the two decades period of 1994-2006, only 3 papers were categorized as exhaustive study. Two examples could be, NuSMV is used to indentify logical errors in a training system for a humanoid robot soccer 16 and also NuSMV model checker is used to validate if the system can continue its mession toward the gold in a given multi-agent environment17. 2.5. Online Detection and Testing Efforts for research on online detection or verification have not been around very long. Reactive adaptation results in an inefficient solution given that it may not be the best action that can be taken. They tend to be the kind of instant and myopic reflection where a lack of real adaptation happens due to not foreseeing what the next adaptations will cause. Leucker and Schallhart7 define that one of the main distinguishing features of run-time verification is due to its nature of being performed at run-time. It opens up the possibility to act whenever incorrect behavior of a software system is detected. The same authors make a comparison between run-time verification versus testing. They stated that run-time verification does not consider each possible execution of a system, but just a single or finite subset, it shares similarities with test, which terms a variety of usually incomplete verification techniques. Testing considers a finite set of finite input-output sequences forming a test suite. Test-case execution is then checking whether the output of a system agrees with the predicted one, when giving the input sequence to the system under test. In that study three different approaches were mentioned to react at run-time: FDIR, run-time reflection, monitor-based programming.


3. System Design The proposed approach as shown in Fig. 1, is a combination of tools that together make it possible an online verification. The first and more important is the programming language used to develop all the system, which is Python. The tool that we use for verification or specifically model checking is NuSMV 11. Although, NuSMV is a stand-alone model checker, hence we used the recent implementation of PyNuSMV 18 which makes it easy to verify a model through Python. PyNuSMV comprehends three layers: The first one is the original code of NuSMV written in C. On top of the first layer is the Simplified Wrapper and Interface Generator (SWIG) 19 layer which let programmers generate interfaces to a variety of scripting languages from a common interface description, in this case as a wrapper generator for C code, to wrap all NuSMV functions. Over the wrapper layer, PyNuSMV provides a library of classes and modules reflecting NuSMV’s main data structures (BDDs, expressions) at the Python level. In the system, it was used turtlesim program for illustration purposes. Turtlesim is a simulation of a turtle that comes in the normal installation package of ROS20.

Fig. 1. Tools Diagram.

In Fig. 2. is depicted the workflow of the solution. The workflow is divided into three different colors to exemplify the different working areas. The yellow color is going to be run in PyNuSMV which evaluates a temporal logic standard specification and it reads the model of a file. The file needs to be readable by NuSMV and as mentioned before it is a finite state automata layout. Orange color represents the interface that is needed to feed both different programs. On red color are marked two different activities mainly ran by the instance that needs to be monitored, which in this tests, as we mentioned before is the turtlesim program of ROS. The proposed solution starts checking an initial model that is already stored and has an initial flow of the system. If the verification gives a satisfactory result, then the model is uploaded to the program. Meaning that the table of states is updated in a database, so, the program can execute the transitions to determined safe states according to the model checking result. The process after uploading the model turns basically to run the program that in our tests is the simulation program of Turtlesim. This process comprehends as well a continuous evaluation of the system situation. On the other hand, if the result of the model verification is not satisfactory, the model has to be changed. This in order to verify the new model and this process can become as repetitive until the result is satisfactory enough to be uploaded to the program.

Fig. 2. Solution workflow.

407

408


4. Experiments As mentioned before, we use Turtlesim as an environment where the turtle might face a danger or a situation that may represent future complete malfunctioning. In this case, we generated a simulated case, where the turtle is going to be in continuous movement and depending on the state where it is located, it will decide what will be the next step. The three possible states are home, playground, and danger. The turtle has to go out of its comfort zone to go to look for food and bring it back home to store it. Although, food might be located in playground or danger zone. We assumed that in danger zone might be a predator that could hunt the turtle, hence find a possible complete malfunction of the system. Nevertheless, the other problem that the turtle can face it is to have 0 food, hence dying of starvation. As shown in Fig. 3, we defined the radius of home as 1 and 3 as the radius of playground leaving all the other space as danger, where the predator might appear. The turtle can bring back a maximum of 3 portions of food to home, but each time it goes out to look for one it consumes one in the effort of movilization. Not in all the trips the turtle goes out to find food is successful and each trip has different random paths that it takes. Due to the random component of the path, the turtle may pass through the same point many times.

Fig. 3. Test environment.

In the tests of this paper we used two different model files that were already developed. One that completely avoids going to danger zone. The second assigns a specified maximum wander time in the same danger zone. In other words, in the first model, the moment the turtle seems itself crossing the imaginary radius of playground to danger zone it turns back to home which implies bringing only the food it has collected. If that happens, often, depending on the locations of the food and also of the availability of it. It might make the turtle go hungrier and hungrier up to death of starvation. As just explained, in the program that is originally uploaded to the turtle it is explicitly programed to avoid the danger zone due to the fear of encountering predators. Although, when it is considered that the possible starvation can occur it is necessary to evaluate other models with the values that the different variables have in runtime. The system then evaluates the second model, which in this study is previously developed, and will evaluate if staying between the danger zone and the playground is still safe if hunger value is under a specified threshold. After receiving a successful result in the second model, the system proceeds to update the table of states in the database. As the model can be evaluated each time the system needs to take a decision, it can also make the system go back to normality where the turtle will completely avoid to go to danger zone if it is not needed anymore. 5. Results Discussion As stated before, this is a proof of concept paper. Since it was planned as a preliminary study to continue in a further and deeper research applying the model checking technique in runtime. Different versions of Python programming language used by ROS and PyNuSMV makes the system not able to make direct connection between the model checker and the simulation turtle program. Although the results obtained were successful enough to validate that the technique will be soon used to make runtime validation. Here it is presented that the software can be modified during runtime simply modifying a table of possible states that can be executed depending on specific values of the variables. This table is updated each time that the model verified gives a satisfactory result. One of the problems that can be faced when the evaluation of the model is executed online or live is the state explosion that is generated when verifying a model, which is out of the scope of this paper.


6. Conclusions and Future Work In this paper we propose an online verification method using PyNuSMV to be able to make formal verification during runtime. This approach lets us make some changes to the program executed in the system to try to maintain liveness and survivability properties of a system. This type of solutions are necessary to assure accomplishment of survivability for the systems, and also, to guarantee the system will be working as desired, especially when these systems/robots will be interacting with humans, where the margin of error should be as close as zero as possible. In the future, the possibility of building a new model from scratch according to the system environment status will make the system able to react more accurate to real situations. Also, the compatibility of different versions of programming languages is needed to be solved in order to make it completely autonomous. Other future path of this study is adding two variables to the evaluation of each scenario. The variables are, assigning probability, and time of the completion of malfunction happening. In the case of the first, given that it is a runtime system, deciding for the one with less probabilities of the problems to happen. The second is more related to have more time to evaluate a possible solution while the system is still working and is able to avoid the complete malfunctioning. More artificial intelligence techniques can be applied to this problem to optimize the performance as well. New ways to implement automatic uploads of software to be ran in systems is other path that this study can move to improve. Acknowledgements This material was supported by the National Science Foundation under the Grant Number CNS-1239171. References 1. R. C. Arkin, Behavior Based Robotics. Masachusetts: MIT Press, 1998. 2. H. Geffner, “The Model-based Approach to Autonomous Behavior : A Personal View,” in AAAI Conference on Artificial Intelligence, 2010, pp. 1–4. 3. H. Psaier and S. Dustdar, “A survey on self-healing systems : approaches and systems,” Computing, vol. 91, no. 1, pp. 43–73, 2011. 4. M. C. Huebscher and J. a McCann, “A survey of autonomic computing—degrees, models, and applications,” ACM Computing Surveys, vol. 40, no. 3, pp. 1–28, 2008. 5. D. Ghosh, R. Sharman, H. R. Rao, and S. Upadhyaya, “Self-healing systems — survey and synthesis,” Decision Support Systems, vol. 42, pp. 2164–2185, 2007. 6. P. Camurati, P. Prinetto, and P. Torino, “Formal Verification of Hardware Correctness : Introduction and Survey of Current Research,” Computer, vol. 21, no. 7, pp. 8–19, 1988. 7. M. Leucker and C. Schallhart, “A brief account of runtime verification,” Journal of Logic and Algebraic Programming, vol. 78, no. 5, pp. 293– 303, 2009. 8. C. Baier and J. Katoen, Principles of Model Checking. Masachusetts: MIT Press, 2008. 9. K. L. McMillan, Symbolic Model Checking, vol. 1. New York: Springer Science+Business Media, LLC, 1993. 10. G. J. Holzmann, “The Model Checker SPIN,” Ieee Transactions on Software Engineering, vol. 23, no. 5, pp. 279–295, 1997. 11. A. Cimatti, E. Clarke, F. Giunchiglia, and M. Roveri, “NUSMV: A new symbolic model checker,” International Journal on Software Tools for Technology Transfer, vol. 2, no. 4, pp. 410–425, 2000. 12. M. Kwiatkowska, G. Norman, and D. Parker, “PRISM : Probabilistic Symbolic Model Checker,” In Computer Performance Evaluation Modelling Techniques and Tools, vol. 2324, pp. 200–204, 2002. 13. M. Kwiatkowska, G. Norman, and D. Parker, “Verification of Probabilistic Real-Time Systems,” Lecture Notes in Computer Science, vol. 6806, pp. 585–591, 2011. 14. J. Barnat, L. Brim, V. Havel, J. Havlíček, J. Kriho, M. Lenčo, P. Ročkai, V. Štill, and J. Weiser, “DiVinE 3 . 0 – An Explicit-State Model Checker for Multithreaded C & C ++ Programs,” Computer Aided Verification, vol. 8044, no. LCNS, pp. 863–868, 2013. 15. R. Pelánek, “BEEM: Benchmarks for Explicit Model Checkers,” Lecture Notes in Computer Science, vol. 4595, no. 201, pp. 263–267, 2007. 16. Y. Kim, M. Gomez, J. Goppert, and E. T. Matson, “Model Checking of a Training System Using NuSMV for Humanoid Robot Soccer,” Robot Intelligence Technology and Applications 3, vol. 208, no. 96, pp. 531–540, 2015. 17. Y. Kim, J.-W. Jung, and E. T. Matson, “An Adaptive Task-Based Model for Autonomous Multi-Robot Using HARMS and NuSMV,” in Procedia Computer Science, 2015, vol. 56, no. MobiSPC, pp. 127–132. 18. S. Busard and C. Pecheur, “PyNuSMV: NuSMV as a Python library,” Lecture Notes in Computer Science, vol. 7871 LNCS, pp. 453–458, 2013. 19. D. Beazley, “{SWIG} and Automated {C/C++} Scripting Extensions,” Dr. Dobb’s Journal of Software Tools, vol. 23, no. 2, pp. 30,32,34– 36,100, 1998. 20. M. Quigley, K. Conley, B. Gerkey, J. FAust, T. Foote, J. Leibs, E. Berger, R. Wheeler, and A. Mg, “ROS: an open-source Robot Operating System,” Icra, vol. 3, no. Figure 1, p. 5, 2009.

409