Increasing Reliability in the Development of Intelligent Environments Juan Carlos AUGUSTO a;1 a University of Ulster and Computer Science Research Institute, UK Abstract. Little is reported in the literature on the methodology used to develop Intelligent Environments. These are inherently complex systems as they are the product of a multidisciplinary approach. Their main purpose is to help people directly, which leads to these environments to take on enormous responsibilities of safety and well being of the users of the environment. We illustrate in this paper how techniques and tools developed in other areas of Computer Science to increase the reliability of software can be applied at design and modelling stages to guide the engineering and developing team to reduce the potential for future malfunctioning. Keywords. Intelligent Environments, Model Checking, Reliability of Software.
Introduction Intelligent Environments (IEs) is a new and thriving area which have emerged in the last decade [1,2,3] from the combination of several pre-existing disciplines like networking, Human-Computer Interaction, sensing devices, Pervasive Computing, AI, etc. [4]. IEs can be defined as “a digital environment that proactively, but sensibly, supports people in their daily lives." [5]. Some recent applications include assisting drivers and monitoring vulnerable people in such a way the system alerts designated carers when safety may be compromised. There are many more interesting applications being the subject of intensive research. All them refer to an artificial system which is trusted to take certain responsibilities on assisting humans. As the scenarios described above indicate some of those can actually be so important that may be involved on situations which carry a risk of life loss or harm to humans. Despite the importance of the responsibility these systems have there is little emphasis in the literature on the correctness of such systems. In [6] the model checker AVISPA is used to verify security issues within the networking protocol used for a Smart Home and, although important, this is only a very specific dimension of the complexity entailed by an Intelligent Environment. In [7] relevant work has been developed to aid the construction of Robots. Although useful steps, they are fairly isolated. This paper emphasizes precisely the importance of using all the available technology to increase the reliability of an IE. We illustrate how well established methods and tools can be used to develop safer systems which will lead to artificial systems more properly aligned with the underlying principles of the area and, hopefully, to safer users. 1 Corresponding Author’s E-mail:
[email protected].
1. Simulating an Artificial Environment Intelligent environments see the world through sensors. These sensors offer diverse readings: on/off (triggered or not triggered) in a Passive Infrared Sensor (PIR), a few coordinates in an accelerometer, an ID number for an RFID (Radio-Frequency Identification), a range of values for a blood sugar level device, video cameras can provide quite detailed information about that part of the world they can ‘see’, microphones allow the gathering of sound from the limited area within their reach, just to name a few options. Each intelligent environment has a combination of different sensors. It does not matter how many we put together what the artificial system will gather and use to make sense of the reality will always be a ‘murky’, ‘distorted’ and limited view of reality, probably similar to some extent to what we see when we are driving in a foggy day. Our intelligence and our experience help us to make decisions in real-time, but because is foggy not all decisions are optimal (or even good!). Probing the judgement of our system with as many as possible different scenarios and understanding how the system we are trying to implement will react in critical circumstances is therefore a very important step in our way to implement a reliable system. Ideally one wants to try the system as much as possible with the real final users, but this is usually impossible until the system has reached some stability and provides some level of reliability. Therefore simulations in the lab are necessary. But labs are usually unflexible to some extent and not easy to adapt to the different real environments the system will be finally deployed in. Hence simulation with artificially generated data is unavoidable and can offer huge rewards at initial stages of the design of a system given its flexibility and low cost. The FADG (Flexible Artificial Data Generator) can provide such artificial data on demand. It is a program that have a generic part and a domain specific part. The first one selects the next event from a set of possible choices, do the time stamping, provides the frequency each event occurs at, and other elements from the generation process which do not depend on the specific domain. The domain specific component provides the knowledge of a particular environment: for example, the layout of a specific home, the devices present in that home, etc. It can generate events at any level of frequency, and it is efficient (in a quarter of an hour it can generate the equivalent to several years of data). The data is generated with format of a 4-tuple: TimeStamp(Date-Time), Place, Status, Intensity. A sample is included in Figure 1. The most important element is its flexibility as sensors and devices can be added or taken out of the model at ease. Part of the specification of the system has to do with semantics. For example, making sure that an occupant moves from room to room in a logical way: if there is no door connecting the living room with the bathroom then it has to go first to the reception area and only then can access the bathroom. We have used FADG as a sort of a high level generator for the artificial system. For example during the implementation of the PUBS learning system [8] one member of the team induced the FADG algorithm to produce more often events related to particular places or activities and other member of the team applied the learning algorithm, then the team met to verify the algorithm was capable to successfully identify those patterns of behaviour that were favored by the the event generator.
2008-4-25-T13:23:53,at_bedroom,on,1 2008-4-25-T13:24:00,bLights,on,100 2008-4-25-T15:3:15,bLights,off,0 2008-4-25-T15:3:17,at_reception,on,1 2008-4-25-T15:4:05,at_toilet,on,1 2008-4-25-T15:19:11,shower,on,1 2008-4-25-T15:38:19,shower,off,0 Figure 1. Sample of Artificial Data generated.
2. Verifying Correct Interaction There are certainly many methods with associated tools [9] that can be used for verification of software (as there are many others for the verification of hardware). From all them SPIN [10,11] is one of the most well-known and used system given its user friendly interface, efficiency, reliability and good team support. The system can be downloaded by anyone completely for free. The system is also open source for whoever wants to develop it further. Given space constraints and the focus of this paper we cannot provide a tutorial on SPIN hence the interested reader is referred to the literature provided above for more information. The rest of this section will focus on illustrating how we have used SPIN to help us design an Intelligent Environment. Modeling, like programming, allows for many possible solutions to be encoded. Each model will typically represent an implementation strategy under scrutiny. Therefore there is no unique answer on how to model an intelligent environment in Promela (PROcess MEta-LAnguage, the modelling language for SPIN). Figure 2 shows a basic skeleton of a Promela model that we have used to represent different Smart Homes settings. Due to space limitations we omit details and also rearrange the location of the processes to minimize the space covered. There are many options to model the different components of a Smart Home in SPIN. What are the features that are useful for our purpose of modelling an intelligent environment? Sensors of different types can be modelled as follows: Sensors with on/off (activated/deactivated) can be modelled in isolation with a boolean variable or with an array of them, e.g., bool pir[20]=0, if we can keep reasonable track which PIR sensor pir[12]=true refers to (is it the one in the kitchen?). Sensors/devices with a range of values (e.g., a blood pressure measuring machine) can be captured through a variable of type short, or an array of them if needed. Modelling other type of sensors or sensing devices (e.g., cameras and mics) or even the user’s interaction with them may ...Definition of Global data structures (e.g., sensors)... active [...] proctype Occupant() {...(local data structures)... (behaviour modelling) }
active [...] proctype Visitor() {...(local data structures)... (behaviour modelling) }
active [...] proctype SensorAct() {...(local data structures)... (behaviour modelling) }
active [1] proctype Central_Unit() {...(local data structures)... (behaviour modelling) }
Figure 2. Basic skeleton of an environment in SPIN.
Figure 3. SPIN in action.
require mytype definitions stating the different possible outputs (e.g., mtype=standing, walking, falling, laying, moving, screaming). Figure 3 shows the use of SPIN over a Promela model of a Smart Home. The model is shown partially on the left hand side. The sequence of messages modelling communication within the network caused by the actions of the occupant and visitors as they trigger PIR sensors is depicted in the right hand side. The panels in the middle provide other useful information on the simulation up to that stage. The top panel provides details of each statement executed in the model. The middle panel shows the level of activity exhibited by each process defined in the model. The bottom panel shows how the interleaved steps of each process unfolded in time. We were able to prove several properties and also to find many flaws in our models at intermediate steps of the design. One example of such properties we explored was one showing the system was aware of the structure of the house. The LTL formula (see [11], ch. 4 for more details) []((b && o) -> (b && (r && o))) stating “always is the case that if a person wants to move from the bathroom to outside of the house then at some stage has to go through the reception hall”. Other properties related to the potential behaviours of people as captured by the model for example, verifying [] nurse_out, stating “it is eventually possible for the nurse to stay outside the house”, was true for a model meant that model included the scenario which allowed the nurse never to come inside the house. Notice that because we are not dealing with explicit time in SPIN (explicit time handling is feasible but costly) then we cannot model how fast the nurse comes to house after an alarm is triggered.
Neither we can model that if an occupant does not answer ‘fast enough’ a phone call or a doorbell whilst being at home then we want to label that as a situation where potentially help is needed. For that we need a tool like the one we are considering next.
3. Focusing on Time Constraints One problem with SPIN is that while representing clocks for the analysis of time constraints is feasible in Promela the resulting model will be more complicated and inefficient given that clocks are not provided as a primitive element of the modelling language. There are many optional systems however that have been created to assist with the design and modelling of Real-Time systems and which are very appropriate in this case. UPPAAL [12,13] is one of the most well-known and used systems for this type of task. Its best assets being the same than SPIN, user friendly interface, efficiency, reliability and good supporting team. Again this is a system that is used outside of academy by important companies to verify specific core elements of their safety-critical systems, several of those success stories have been published. Its input is a bit more abstract than in the case of SPIN as it is based on networks of timed automata which can be either drawn and defined in the windows like interface or can be generated (even automatically) as an XML file which the system can pick up as an input. Again due to the focus of this paper the reader who wants to know more about UPPAAL should familiarize her/himself with the extensive literature available. The rest of this section will focus on illustrating how we have used UPPAAL to help us design an Intelligent Environment. Figure 4 shows the declaration of global variables for all automata involved in the modelling of a specific smart home. Figure 5 shows the simulation panel which exhibits only a few of the automata composing the whole system’s model, in this case the sensor detection manager (upper middle) which is processing with a PIR sensor triggering in the living room. The are multiple benefits in using tools like UPPAAL: (a) modelling itself forces the developing team to reflect upon subtle aspects of the system, (b) simulation provides a way to explore potential scenarios and try ideas before actual implementation, and (c) verification provides a way to prove/disprove behavioural properties reflecting the requirements of the system. Most interestingly, in trying to prove those fundamental behavioural properties the tool will find counterexamples that show us why a property (formal expression of a requirement) is still not captured with the solution strategy represented in the current model. In the case of UPPPAL the classical patterns in the specification of behavioural properties for formal verification are: EP (P is reachable), E [] P (potentially always P), A P (inevitable P), A [] P (invariantly P) and P -> Q (consequence). Examples on how we used those templates instantiated in the context of a Smart Home design we explored follow: (a) Template: E P (Does a path exist where P eventually holds?). Instantiation: E (EnvironmentController.on and AtHome==false) with intuitive meaning: “Is it possible for the system to reach a state where the patient is not at home but the heating/air conditioning system is on?” (b) Template: E [ ] P (Does a path exist where P always holds?). Instantiation: E[ ] burglarAlarm.active imply burglarAlarm.idle with intuitive meaning: “Does a path exist where an activated burglar alarm will be deactivated?” (c) Template: A P (Will P eventually hold for all paths?). Instantia-
Figure 4. UPPAAL: global variables declaration.
tion: AThermostat.idle with intuitive meaning: “Will the thermostat eventually return to the idle state?” (d) Template: A [ ] P (Does P always hold for all paths?) . Instantiation: A [ ] ! (vitalSignsMonitor.bloodSugar>0 && AtHome==false) with intuitive meaning: “It is not possible for the system to reach a state where blood sugar is monitored when the patient is not at home”. (e) Template: P –> Q (Whenever p holds will q also hold?). Instantiation: kitchenSmokeAlarm.active -> AlarmManager.contactFireBrigade with intuitive meaning: “Whenever the kitchen smoke alarm is active, the alarm manager will contact the fire brigade”. Figure 6 shows UPPAAL verification interface. At the top there is a list of properties that have been loaded for verification. The software developer in the team has already requested to model-check (see button on the top right hand side) the first property in that list and the result (the property is valid with regards to the current model) on the lower window of the panel. Notice some of these properties has explicit time constraints, which would not have been suitable for checking with SPIN.
4. Conclusions We have explained how well established methods and tools can be successfully applied to better understand a solution for an Intelligent Environment at design and modelling
Figure 5. UPPAAL: simulation panel.
stages. This has as an important practical consequence that the system can be implemented in a safer way. This has so far been mostly overlooked in the literature of the area but it should not be that way given the tremendous responsibility we put on some of these systems (for example taking care of vulnerable people to raise alerts when safety may have been compromised). Therefore this paper focus on showing how a system for an Intelligent Environment can be developed more safely leading to a product with increased reliability. Surely not all aspects of the final implemented system can be considered, for example, it does not guarantee that if a sensor is moved to a different location then the system will still work correctly, but it helps ensuring that if the system implementation follows its specification then its logic will be sound. If the system is changed then that is a different system and the modifications have to be reviewed. As a final reflection, it can be seen that there are certain features of Intelligent Environments which cannot be covered by the methods and tools considered here and given these represent the state of the art in verification of software systems this mean may not be a way with current technology to cover those issues as comfortably as we should. Therefore the content of this paper carries an implicit message and invitation to the communities of Intelligent Systems and Software Engineering to develop in collaboration methods and tool that are better suited to encompass the diversity of components making up an Intelligent Environment. Some steps have been given in that direction, more has to be done.
Figure 6. UPPAAL: verification panel.
References [1] [2] [3] [4] [5] [6]
[7] [8]
[9] [10] [11] [12] [13]
M. Weiser, “The computer for the twenty-first century,” Scientific American, vol. 165, pp. 94–104, 1991. IST Advisory Group, “The european union report, scenarios for ambient intelligence in 2010,” 2001, uRL: ftp://ftp.cordis.lu/pub/ist/docs/istagscenarios2010.pdf. Proceedings of The International Workshop on Intelligent Environments (IE 05). IEE, 2005. D. J. Cook, J. C. Augusto, and V. R. Jakkula, “Ambient intelligence: applications in society and opportunities for artificial intelligence,” Pervasive and Mobile Computing, 2009, to appear. J. C. Augusto, Ambient Intelligence: the Confluence of Ubiquitous/Pervasive Computing and Artificial Intelligence, ser. Intelligent Computing Everywhere. Springer London, 2007, pp. 213–234. A. Muñoz, A. Maña, and D. Serrano, “Model cheking ambient intelligence with avispa,” in Ambient Intelligence Perspectives, ser. Book Series on Ambient Intelligence and Smart Environments, P. Mikulecký, T. Lišková, P. Cech, and V. Bureš, Eds. IOS Press, 2009, vol. 1, pp. 182–193. S. Bensalem, M. Gallien, F. Ingrand, I. Kahloul, and T.-H. Nguyen, “Towards a more dependable software architecture for autonomous robots,” IEEE Robotics and Automation Magazine, 2009. A. Aztiria, J. C. Augusto, A. Izaguirre, and D. Cook, “Learning accurate temporal relations from user actions in intelligent environments,” in Proc. of the 3th Symposium of Ubiquitous Computing and Ambient Intelligence, J. M. Corchado, D. I. Tapia, and J. Bravo, Eds. Springer, 2008, pp. 274–283. B. Berard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci, P. Schnoebelen, and P. McKenzie, Systems and Software Verification (Model Checking Techniques and Tools). Springer Verlag, 1999. http://spinroot.com/spin/whatispin.html. G. J. Holzmann, The SPIN Model Checker : Primer and Reference Manual. Addison-Wesley, 2003. http://www.uppaal.com/. K. G. Larsen, P. Pettersson, and W. Yi, “Uppaal in a nutshell,” Int. Journal on Software Tools for Technology Transfer, vol. 1, pp. 134–152, 1997.
