POLITECNICO DI MILANO
Department of Electronics, Information and Bioengineering
Master of Science in Computer Engineering
BRIDGE PROJECT DESIGN AND IMPLEMENTATION OF A
RULE SYSTEM COMPATIBLE WITH CEP METHOD
Supervisor: Prof. Sara Comai
Co-advisors: Simone Mangano, Fabio Veronese
Master Graduation Thesis by Nasim Salehimobarakeh
Student ID Number 780022
Acknowledgment
I would like to extend my sincerest thanks to Prof. Sara Comai for her immeasurable guidances, continuous patience, intuition and
discipline she has provided gently throughout this research.
I would like to give my special gratitude to Simone Mangano and Fabio Veronese for their precious suggestions and help in
the practical part of my thesis.
My special thanks also to all my dearest friends, who were inspirational and supportive during my experience in Politecnico.
A deepest appreciation goes to my father, for his constant encouragement, my mother for her well esteemed patience and both for their loving hearts, without them I
wouldn’t be who I am today.
I would like to also thank Politecnico di Milano for this fabulous experience. I am deeply blessed to be a part of Polimi’s family.
1 Introduction 6
1.1 Context 6
1.2 Problem statement 10
1.2.1 A Description of Devices, Sensors and Actuators 11
1.2.2 Sensors and device description 13
1.2.3 Possible Real Scenarios 16
1.3 Proposed solution 18
1.4 Structure of the thesis 19
2 Background and related work 21
2.1 Relevant scientific results 22
2.2 Relevant technologies 24
2.3 Other Related Works addressing the same problem 26
3 Requirements Analysis 27
3.1 General Requirements 27
3.2 Comparison among Several Approaches 29
4 Design of the Solution 42
4.1 Priority Features List for the User Interface 42
4.2 Most Required Features List 43
4.2.1 General Required List for Rules 43
4.2.2 Required Specific Functionalities for “Events” 46
4.2.3 Required Specific Functionalities for “Conditions” 46
4.2.4 Required Specific Functionalities for “Actions” 48
4.2.5 Some examples 49
4.3 Suggested Features on the User Interface 50
4.3.1 General Structure of the Pages 51
5 Implementation 53
5.1 System implemented for Validating the Idea 53
5.1.1 First View 54
5.1.2 Panel Side Menu 54
5.1.4 Functionalities for Events 59
5.1.5 Functionalities for Conditions 62
5.1.6 Functionalities for Actions 63
5.1.7 A Technical Overview about Bridge Ruler 65
6 Conclusions 70
6.1 Short summary of work done 70
6.2 Critical discussion of the results 70
6.3 Possible future work 72
Some for the Glories of This World; and some Sigh for the Prophet's Paradise to come; Ah, take the Cash, and let the Credit go, Nor heed the rumble of a distant Drum! Omar Khayyám
1 Introduction
1.1 Context
According to statistics the mean age of the planet population is increasing 1. While the
health and hygienic services get more accessible and thanks to the advancements in medical knowledge a slight but steady increase in mean age is beingobserved. As a result of statistical processing from the U.S. Census Bureau international database, the population of people aged over 65 predicted to rise to around 1,400 million by 2050.
As it could be seen in Figure 1.1 predictions indicate this rising to carry on continuously.
The graph predicts how the number of people aged 65 and over (vertical axis) will change with time (horizontal axis) in each continent. This observation of such a growth causes the necessity of accessing to reliable and smooth facilities for the elder population on the planet.
Figure 1.1
Graph predicts how the number of people aged 65 and over (shown on the vertical axis) will change with time (shown on the horizontal axis) in each continent.
Elders, often with cognitive and physical impairment, need assistance in their activities of daily living (ADLs), which is usually provided by human caregivers (HCGs). Some of these phenomenon preeminent issues include the long-term viability of current social support systems and the increasing difficulty in delivering care and assistance within the family. The slope of the line related to the groups over 65 and 80 shows even higher rates among this group as it can be seen in Figure 1.2.
Figure 1.2
The 150 percent expansion of the population aged 65 and over in the next 35 years, in contrast to the youth population (under age 20) remaining flat in 2015 and 2050
As the elderly are supposed to receive satisfactory services toward their health and well-being in their living environment, multiple settlements have been proposed to help them coping with their special needs.
Nowadays, approaches like Ambient Assisted Living (AAL) and Independent Living (IL) are demonstrated as an alternative to the issue that states the necessity for improvement of human lives 2. General facilities for daily needs are advancing due to
new technologies. This well being system should be also able to target particular groups of people like the ones who suffer from any kind of impairments. Those kinds of disabilities may contain cognitive or physical difficulties that prevent them experiencing an autonomous and independent life. The fragility of their life circumstances cause them to feel dependent and it can induce a feeling of being weak. Whilst, their normal activities, health aspects and any other side of the life that necessitates autonomy could be practically impossible to accomplish in absence of other human being.
Since this situation requires a wide and still accurate coverage, these cases ultimately oblige presence of a second person as a full time caregiver or collaboration of a whole family or close relatives. But, not all the impaired people are being so lucky or rich enough to find someone with this kind of characteristics around themselves.
Both of the situations drive the same kind of advantageous; in the latter case, in shape of the need for impaired people who need to be assisted. In any case, this kind of
problems could found a provocative origin relating to the same ground of requirements.
Addressing these problems, multiple choices have been developed to let elderly or disabled people being facilitated by an automated system. These tools are supposed to be easily learnt and applicable for this target group in a proactive manner. Therefore, these both two elements are forming to a critical requirement that should be resolved by taking appropriate solutions.
The work presented in this document is part of the project “Bridge ” (Behaviour dRift 1
compensation for autonomous InDependent livinG2). This project as its name implies,
defines the specification and implements an infrastructure of an ambient assisted living project. The project has been designed as a solution to the situation in which elderly or disabled people must be aimed in order to experience a more smoothing and easier life. The Bridge project’s fundamental infrastructure is composed of two main subsystems. One is a local and the other is a remote subsystem. While the former has home automation devices, sensors, and a local server, the remote subsystem is based on more powerful hardware for the long term storage. This stores the data coming from the local subsystem for future analysis over a long period of time. Moreover, it enables remote house control and can provide information to the caregivers about the house and its inhabitants statuses. The project which is done and described in this document enriches the remote house control subsystem by enabling it to define customized rules according to the happenings that might occur. This rules could be found and created by the caregivers or the elderly or disabled person herself. The capability of new specific rules per each user allows us to have a flexible system that can be used by the final user accordingly. The project is called “Bridge Ruler” and it is responsible for providing a lightweight frontend with respect to the requirements of general specifications of the project Bridge.
Figure 1.3 illustrates the local subsystem architecture, which interconnects the smart home’s autonomous components, making them interoperable and providing the tools to control and monitor the whole house. The house services layer (bottom of the Figure 1.3) comprises a set of heterogeneous services used to compose the smart home and its extensions. The Bridge Ruler application mainly plays the role of an interface in which a presentation layer is developed. This subsystem serves the Bridge project as a part of the “House Service Layer” that lays down in the lowest section of the Figure 1.3. This interface is implemented in order to connect the Smart Home local architecture with the backend layer which is a binder rule subsystem. According to this architecture, Bridge Ruler supplies a front end in which by composing rules an interconnection is made between the data turning out from the set of house sensors and actuators and other services or extensions in the “Services Abstraction Layer".
Figure 1.3
1.2 Problem statement
In the Bridge project we are dealing with handling risky or critical situations that are plausible to occur when an elder person is living in a house on her own. Projects that are known generally as Smart Home projects generally have been introduced to solve the case in which a person with disability needs to be supported with her daily activities in her house 3. The Smart Home project has been proposed and allotted as a
solution for elderly or people with any types of disability. It provides house control interfaces in which bahavioural habits of the person in a house are monitored by means of sensors or actuators installed inside the house. The interface is supplied with the data that gets accumulated by sensors and actuators. The ambient assistant system then will smooth the procedure of automation control of house appliances and this
information will be applied in an intelligent system as well. This system that must carry the ability to recognize the bahavioural patterns of the intended society then should be capable of detecting dangerous circumstances. The ambient assisted systems usually take advantage of apparatuses that let the system to equip a disabled person to define the situations in which she wishes to control and act appropriately but due to disability she is incapable of doing them by her own self.
The problem must be seen of two major sides. One aspect involves identifying insecure terrains which might happen by detecting patterns in person’s specific procedures for a person classified as being ”fragile”. This implies applying a method that can recognize the sequence of events that may lead to a dangerous situation. The other considerable task that this kind of issues reflects is occasions that are exclusively related to one’s life habits and personal routines.
In the latter one, it is required to facilitate elderly or impaired people by a customizable software that allow them to define specific situations in which they believe extra help is needed. Notably, efforts must now focus on the analysis of the data which is generated from the devices within the house as a means of producing patterns of the users and providing intelligent services to them.
As the events and rules in general are established upon the devices that we have installed in the house, so those play a major role in the project design and it is useful to have a general view of the devices, sensors and actuators. There will be given some description of them in the next part. Then, for more clarification some real case scenarios are described here.
1.2.1 A Description of Devices, Sensors and Actuators
In order to organize the events that might trigger rules in this Ambient Assisted Living system, we have some devices settled in the house in particular. Also several sensors and actuators exist to serve the backend layer with the data coming from the house. So in the Smart Home some equipments must place in order to communicate the data that emerges from the environmental condition and also the fragile person behaviour. Figure 1.4 depicts typical layout of a person’s apartment.In the Bridge project the general overview of the person and the house perspective could be described as:
1. The mission is to monitor the status of fragile person (elder or disabled people, etc.).
2. They are settled in a demotic house equipped with sensors and house appliances controllers get monitored.
3. We need to check if the person is “in danger” by the information could be aggregated from the Ambient Assisted Living system.
Figure 1.4
The apartment has the ability to detect the movement of a person throughout the house and in addition provides a number of interfaces to monitor the person’s interaction with various home appliances. As it is shown in the picture “Motion Sensors” applying and those are able to pursue the presence of a person as they move around their living quarters. A pressure pad sensor as well placed at the side of the bed detects a person getting out of bed. Additionally, sensors detect if the fridge’s door has been opened or closed. Also there is a sensor to detect if the main gate has been turned open or closed. Alarms may also be raised if the smoke or temperature sensors are activated as well. There are five main categories of user services dependent on sensor or actuator. Here the most significant ones that are currently used for collection data from the Smart Home are mentioned:
1. House control sensor, this may indicate lighting and shutter control in order to adjust the brightness or temperature of the house according to the environmental changes.
2. Home appliance monitoring for user activity recognition and energy consumption measurements, for instance the bedroom light switch meter for measuring the light or temperature of the bedroom and adjusting it automatically.
3. Presence detection, that is, identifying the presence of people in specific areas of the house.
4. Localization and status, this is designed for identifying a specific user’s precise indoor position along with status (moving, sitting, falling, and so on). This ability is provided by a Laura ASOs which provides IHL events 2 3
for every person wearing a mobile device. This device is designed to be worn on a necklace or wristband or simply carried in a pocket. By its signal magnitude, it facilitates to identify if the person is standing, walking, lying or falling.
5. Event and status-based information transmission to inform caregiver promptly about specific events. This may happen when a restricted or prohibited area is violated, no movement is detected after a predefined period of time, or a fall is detected.
1.2.2 Sensors and device description
The data we account for them to detect the fragile person in a Smart Home are collected using sensors and devices. In the sequel, the data monitored for the person and in the house are briefly described for making a basic acquaintance with the house environment and existing equipments.
PERSON
Some information describing the person’s body condition and situation are necessary to be kept. We need to monitor the body temperature, heart rate, blood pressure, location and the posture (with prebuilt postures: standing, walking, lying down, sitting or falling down).
2 Abstract Service Objects 3 Indoor Human Localization
HOUSE
We need to store the map of the house that is composed of some rooms and localize the person. Based on some parameters the house rooms (bedrooms, kitchen, living room, corridors) can been represented as regular or polygons. Some devices and sensors should be installed and some of them are already existing as in every common house. In the following most of the devices that are of interest and could be informative are listed.
Elements of the house
The elements in the house that may be significant in order to keep the AAL system informed about how the circumstances is going in the house are as:
● Window shutter ● House temperature ● Air conditioning ● Doors ● Lights ● Humidity ● Security Alarm
Elements of the kitchen
● Stove
● Heater ● Oven ● Boiler ● Ventilation ● Chairs ● Smoke Sensor ● Tap Water ● Dishwasher ● Microwave
Elements of the living room
● TV● Couch ● Stereo
Element of the bedroom
● BedElements of the bathroom
● ShowerIn Table 1.1 a list of the devices and respective sensors or properties is listed. Device Door status Power consumption On/off sensor Location sensor Active Sensor TV ╳ ✔ ✔ ✔ ✔ Cooler ╳ ✔ ✔ ✔ ╳ Shower ╳ ✔ ✔ ✔ ╳ Radiator ╳ ✔ ✔ ✔ ✔ Oven ✔ ✔ ✔ ✔ ╳ Stove ✔ ✔ ✔ ✔ ╳ Stereo ✔ ✔ ✔ ✔ ╳ Tap water ╳ ✔ ✔ ✔ ╳ Heater ╳ ✔ ✔ ✔ ╳ Light ╳ ✔ ✔ ✔ ╳ Washing machine ✔ ✔ ✔ ✔ ✔ Dishwasher ✔ ✔ ✔ ✔ ╳ Security Alarm ╳ ✔ ✔ ✔ ╳ Emergency button ╳ ✔ ✔ ✔ ╳ Boiler ╳ ✔ ✔ ✔ ✔ Cupboard ✔ ✔ ✔ ✔ ╳ Air conditioner ╳ ✔ ✔ ✔ ╳ Bed ╳ ✔ ✔ ✔ ╳ Table 1.1
A description about the sensors and the use of them explained in the following:
● Door Status Sensor: for some devices like washing machine or microwave the door status should be checked and kept because if the door is open and the device is on this is a critical danger.
● Power Consumption Sensor: for devices like oven or boiler checking the power consumption range could be informative in case that the device is out of work (for example is destroyed) and at a certain time the consumption of electricity suddenly gets high and/or down, which could be a case of danger.
● On-off Sensor: this sensor helps us monitoring the devices that are currently working and consume electricity power. They must be observed so that not to be overloaded by more than maximum electricity.
● Location sensor: for devices, which their location in house should be monitored. ● Active Sensor: this helps us recognize the functioning or standing by the devices
that can be on but in stand by status.
1.2.3 Possible Real Scenarios
In the table 1.2 some real scenarios that may occur on the devices and conditions which should be check using data coming from sensors and the action that must be triggered in that rule are illustrated.
Scenarios
Event(s)
Condition(s)
Action(s)
Scenario 1
Value Change on the Common-Kitchen-Livi ng-Button-Light If both Kitchen-Lamp-Switc h AND Living Room-Light-Switch are Off Set Kitchen-Lamp-Switch On, then set Living
Room-Light-Switch On
Scenario 2
Value Change on the Common-Kitchen-Livi ng-Button-Light If both Kitchen-Lamp-Switc h AND Living Room-Light-Switch are On Set Kitchen-Lamp-Switch Off, then set Living
Room-Light-Switch Off
Scenario 3
Trigger Event on the Corridor Pir turning to 1
If Bed-Room-Switch is Off
Set Kitchen-Button-Light On, then set
Corridor-Ambient-Light On
Scenario 4
Battery Charge Change Event on
Kitchen-Lamp-Power-Meter
NO CONDITION SendTextMessage “Battery Charge Change happened”
Table 1.2 some real cases for defining rules
1.3 Proposed solution
The emergence of broadband internet connections, smartphones and tablets the smart house market shows a considerable upsurge. This has led to a need for platforms that allow the integration of different systems, protocols or standards and that provide a uniform way of user interaction and higher level services. Providing a flexible framework for Smart Home and AAL (ambient assisted living) solutions, the Bridge project focuses on the use cases of user interaction domain, e.g. on easy automation and visualization aspects. The project introduces an infrastructure that allows building smart house solutions that have a strong focus on heterogeneous environments for aiming despaired people who are in need of assistance in their normal life routines.
As stated, the target of such a system introduced is not only to provide intelligent assistance to those who encounter the obligation to cope with their lives problems alone, but also contribute to define customized situations they might need extra help. In order to achieve such a system, designing a “Rule-based” system is felt to be necessary. The major goal of the thesis described in this document is to introduce and explain the project “Bridge Ruler” which acts as an interface for the disabled people or the related caregiver to define rules that occur during their daily routine.
Briefly, it could be stated that Bridge Ruler is a system in which, based on the occurred events (or sequence of events) and validating some conditions some rules may have to be triggered. The triggered action in this system usually is a command that acts on a device in the house and sets a new value, change the status of a device or send a message to a caregiver. Some related scenarios already have been explained in section 1.2.
Certainly, there are already several existing solutions in the market that address this kind of issue. Although, there are some specific needs in high demand that claim such an assistant system to be customizable. Most of the designed systems do not provide functionalities to the user that take into account particular needs and they do not suggest exclusive services per user. Conversely, the Bridge architecture is modular, so different services can be easily combined. Bridge’s design takes into account requirements such as low-cost, low impact on the house (easy-to-install, unobtrusive), and usability.
1.4 Structure of the thesis
Following those specifications that elicited by speculating about solutions to respond appropriately the problem, this thesis encloses a three step work.
1. The primary phase has initiated by getting to know the Bridge requirements from the scenarios we may encounter in real life for the final user (fragile person) in the Smart Home according to some predefined conditions and facilities. Afterwards, contemplating to analyze situations, we extracted the entire requirements that would be needed under these distinct circumstances. This phase contained designing the database structural schema according to the devices and events could be regarded upon those devices. Then the scenarios contributed to determine necessary triggers that should be considered in the implementation. Most of the activities have been done during the first phase, represent the work to investigation and conclusion of which kind of events can yield to specific triggers. By the scenarios evoked from this step some final Rules turned out to be critical. This has consisted of a “design and modify” cycle until the ultimate solution appeared to be enough efficient.
2. In the second phase, as the requirements analysis claimed a technical method which could be able to address those needs, the results from the other colleagues research that has led to a particular solution formed the technical foundation for this work. The research has already triggered the basic layer. The solution found and decided as the best to answer is CEP . The engine that has 4
been chosen for the practical part is “Esper”. Esper is an open source engine which will be more discussed in the part of technical aspects of the project. Therefore, the whole technical work supposed to fall into this space to respect the selected technique and engine chosen. In this phase, research has been done in order to acquire the orientation of CEP and investigation of the relevant works with Esper engine. As a sequel that came out from comparison between various platforms and technical works done according to CEP method, some conclusions have raised on the implementation aspects.
3. On the third phase, the concentration has been placed on functional aspects and established some basics for the implementation side. Most of those requirement analysis that has been pointed to in second phase proposed a rule-based system that allows the user to define customized rules according to the events. These events are obviously correlated to the devices. The devices on their own are
assigned to several sensors and actuators which enable the rule-based architectural system to be responsive to the events might occur in that context. Esper engine in particular, would enhance the rule definition and management procedure by letting the user the freedom to add sequence of events and define new customized rules accordingly.
As a matter of fact, multiple functionalities recognized to be necessary for the front end layer. The major work done in this thesis covers the front end capabilities and meets the presentation layer demands for the customized rule-based enhancement for the final user.
As a result. the principal functionalities that have been taken into account in the specification of the Bridge Ruler project aimed to help the final user experiencing a user-friendly, liable, efficient, easy-to-use tool. Meanwhile, presenting a lightweight, affordable and smooth layer which benefits from the latest technologies introduced in the market has been under consideration.
2 Background and related work
Since lots of “events” may be happening across the various layers of an organization the need for a solution in the enterprise scale is widely understood in some verticals, where it is actively deployed to perform various business critical tasks. Some sectors as sales and order leads, financial trading, fraud identification and process monitoring systems are highly demanding for a remedy for automating situations where we need to identify, make sense of, and react quickly to emerging patterns in a stream of data events.
There are some special fields in which utilizing CEP4 has been of positive outcome.
A CEP system could help in fraud detection depending on the distance between the location of the events. For example if two credit card transactions on the same card happen within a window of thirty minutes from two different locations which are five hundreds kms apart, then it could be reasonable to conclude that there is something wrong. Another field in which CEP Track and Trace of RFID data. ‘Situation Assessment’ out of airline operational delays (plus their causal events) could be named as another example. Also, ‘Sense and Respond’ to fraud indicators in internet transactions is a tangible instance of CEP applications in IT services area.
CEP engines history collides back to 90's. They were mostly used in decent number of real world use cases. However, they were a shallow and still expensive. Aftermath of Big Data taking off, people started to look for streaming analytics solution similar to ‘Hadoop’ and ‘Storm’. Storm is a Stream processing engine. It used to mirror the MapReduce model, in which it would be feasible to write some code and attach them to a processing graph. Initiatives of CEP solutions could be seen as ideas stolen the limelight out from MapReduce technique.
In the Figure 1.5 a top representational overview is depicted in order to exhibit the role that a Complex Event Processing system acts upon that in an infrastructure.
Figure 1.5 an overview of Complex Event Processing method
2.1 Relevant scientific results
According to several advantages CEP and specifically Espertech5 may provide, a
concept of detecting events sequences and organizing them in an intended manner seems favourable. In other words, if there could be a way for events to be routed through an intelligent system that can find the correlation between the events and then take proactive action based on that then it could be of immense use to a variety of situations. As mentioned before, one of the straightforward directions frequently used nowadays is CEP. The primary building-block in CEP is to process events in an event-driven environment. The concept behind CEP is addressing the necessity of detecting behavioural patterns in events occur frequently in order to identify significant trends (threatening or favourable) and infer other events or derive any beneficial conclusion. These conclusions usually are drawn from real-time stream processing and integrating multiple sources of data upon the infrastructure. According
to the complicated circumstances which has been raised by occurring complex events may yield to a decision either of executing an action or inferring a meaningful event. This kind of situations typically induce more critical circumstances.
Another viewpoint of a CEP system could be like the typical database model turned upside down. Whereas a typical database stores data, and runs queries against the data, a CEP stores queries in shape of “Events” and runs data through executing queries. These queries usually use EPL (Event Processing Language) to fetch the data stream. At the other side, Listeners designed and coded to ‘do an action if queries back with results’.
Generally, what CEP practically does is to invert the routine that the database does. As mentioned, in the RDBMS context, the data is stored in DB and then queries are executed on the database to ascertain the trends, any rules which need to be triggered on the basis of already existing data etc. So having the data already exists, the queries would work on them. Conversely, if we invert that scenario, there is no data. Instead we are dealing with some queries or rules which exist. The data flows through the CEP system. While the data flows, different rules try to make sense of the data (represent or generalize the significant trend in the data) and take an action in the real-time. So the process aims to extract what data could represent which can be remarked as a “pattern” or “rule”.
EsperTech is an engine that provides the Event Processing Language (EPL) designed for concisely expressing situations and fast execution against both historical and currently-arriving events. The specification brings forward is a platform for highly scalable, elastic, distributable and fault tolerant event processing.
Esper, is a lightweight and embeddable engine based on java. It facilitates the demonstration of coping with the all events flowing through an event-based system at a high rate while preserving flexibility. It acts sufficient in handling massive growing data volumes that need to be restrained upon a fundamental layered architecture. In the Bridge project we are taking advantage of the abilities of Espertech and solutions CEP has been provided in order to build an infrastructure in which it would be possible to define rules according to exclusive situation, detecting patterns in behaviourl habits, and ultimately identifying critical (risky) situations. Espertech engine supplies technical requirement for which we need to recognize a sequence of events that if occur within a “Time Window” may lead to realize a complex situation or another event.
2.2 Relevant technologies
There are several paths to achieve an intelligent system for these cases. One which is worth mentioning other than CEP could be Rule Engines. We will take a look on the philosophy and various functionalities or properties of both of these.
Business rules are another possible solution that could be applied in the similar situations to provide procedural management in an automated manner.
Business Rules indicate declarative statements that govern the conduct of business processes. A rule consists of a condition and actions. The condition is evaluated, and if it evaluates to true, the rule engine initiates one or more actions.
Rules in the Business Rules Framework are defined by using the following format:
“ ON `event` IF `condition` THEN `action` ”
Consider the following example as a simple rule in a sales partition:
On change the value last month profit
IF the current budget is greater than or equal to available funds
THEN update the catalogue price and send the catalogue to sales department
This rule determines whether an update transaction will be conducted by applying business logic, in the form of a comparison of two monetary values, to data or facts, in the form of an update in prices amount which yields in a transaction to be done at database level.
A “Rule Composer” is supposed to provide the capability to create, modify, version, and deploy business rules. Alternatively, we can perform the preceding tasks programmatically.
Rule-based systems can be used to perform lexical analysis to compile or interpret computer programs, or in natural language processing named as NLP as well.
Rule-based reasoning engines typically produce inferred information by means of artificial intelligence methods. Though, there is a difference to take care of, Rule-based systems do not produce new information in the form of inferred complex events in general.
On the other side, CEP engines, are supposed to be responsible of tracking the state of the system by processing the events and identifying patterns, as well as supplying a swift response to the current situation.
In other words, CEP applies pattern detection algorithms in critical tasks similar to fraud detection, monitoring, algorithmic trading, social media analysis, stock market feeds, traffic reports, weather forecast services and a huge other kinds of data. As analysts suggest, CEP engine is supposed to filter the data accumulated from several streams of data while revealing results for execution paradigms. By applying available archetypes for pattern detection CEP engine will be able to generate actionable events for an organization according to the state of the system. The CEP engine might have been fed by event clouds and streams or their related histories.
It could be briefed that while rule-based systems are more used in order to define the determined situation which can be seen as rules, CEP engines represent an intelligent way to both recognize those kind of situations, verifying them by means of pattern detection algorithms and take an act according to the identified situation.
2.3 Other Related Works addressing the same
problem
Due to three following main reasons, another trend, known as “IoT” (Internet of Things) might bring CEP back into spotlight again6:
A. IOT data are time series data in which the data assumed to be autocorrelated. CEP is much better designed to handle them.
B. Most IoT use cases have something in common or originally rooted with the real life cases.. CEP owns a bold advantage in turnaround time.
C. IoT use cases mostly are complex, and they seek and address functionalities beyond what is related to calculating aggregating data. Those use cases need support for complex operators like time windows and temporal query patterns.7
Here CEP is placed to meet a specific requirement, the need to supply time windows for detecting sequence of events happening in a particular order.
Knowing this fact that major number of ‘ IoT’ use cases have very high event rates. So the entire event technology technologies used in those use cases need to be able to scale up to fit the real situation we might deal with in life. Stream processing can cope with this issue better than CEP. However, these two markets are merging and it is not possible to determine a line upon which one may win over the other one yet.
3 Requirements Analysis
3.1 General Requirements
The need to provide an integrated way of user interaction and higher level services for the ambient assisted living systems has been clarified. By providing a flexible framework for Smart Home and ambient assisted living solutions, the Bridge project has settled its concentration mostly on the use cases regarding user interaction arena; for instance on easy automation and visualization aspects. Bridge project tries to apply previously experienced Smart House solutions in order to build a firm infrastructure on heterogeneous environments for aiming those people who are in need of assistance in their normal life routines.
In the Bridge Ruler project, we analysed the high priority requirements of elderly people live in a house alone. Due to disabilities and limitations that this people may encounter, a frontend layer for creating their own “rules” in the house seemed to be necessary. There are some dangerous occasions for an impaired alone person in a house that demands a second person or secondary source help. In case that there is not the possibility to have a person present all the time to take care of these elderly people, the design of a front end to help to these specific known situations is a must. Therefore, the Bridge Ruler project by benefiting of latest lightweight technical solution like AngularJS and HTML5 committed to supply these group of people with a frontend that let them define their routines that might be seen as a “rule” in a “Customizable Rule Definition” system. Moreover, this project gives the possibility to edit the rules already defined. The data storage benefits from JSON data files. JSON (JavaScript Object Notation) which a lightweight data-interchange format allows an easy alternative for data read and write. It is based on a subset of the JavaScript
Programming Language, easy for machines to parse and generate as well as efficient for integrating with AngularJS framework and libraries. These two techniques (AngularJS and JSON) cooperate in an efficient way in the front end layer in Bridge Ruler.
On the other side, as we have discussed in the introduction and Background parts, the risky situations that elderly people may experience can be a result of some sequence of events happening within a specific time window. The Bridge Ruler frontend let creating desired sequence of events and assigning a time window to the sequence. This ability enables Espertech engine in the backen layer to be able to detect the events regarded by a time window and helps for identifying complex events patterns. If any single event needed to be defined, that would be feasible to define it as well (obviously no time window would be required to be assigned in this case).
The major functionalities arises to be most significant contains the following:
1. Ability to create customized rules
2. Ability to define events, either a single event or a sequence of events by a time window assigned
3. Ability to define conditions that contributing with an event occurred may have some meaning in the system
4. Ability to define actions regarding to events occurred and conditions satisfied to command a device to act as needed in that situation
More capabilities of the implemented application will be discussed in details in the Design and Solution (chapter 4) and the Implementation (chapter 6) parts.
3.2 Comparison among Several Approaches
In the following, we will investigate about ten different rule engines and their features, especially for the way that the user interaction with a rule engine for a normal user (without programming or business analyst knowledge or experience) in them has been designed and implemented. Then discussing the capabilities and characteristics of every single engine we will compare them in a table. Ultimately, for the aim of leading the analysis phase to the Design of the Solution, we will collect those functionalities that we need in Bridge Ruler project and include them as the design.
First, for every rule engine observed , some brief and key features are introduced. Then, in cases that photos could help to show the environment and the functionalities better, related screenshots added as well for the aim of demonstration.
1. XpertRule9
2. Web Rule control (Code Effects)10
● It has a tester form to test the rule immediately after creating ● It supports two kinds of rules:
1- Execution type (with an action to take if the conditions are true) and
2- Evaluation type (just checks to see if the conditions are true), this type lets us to touch the ability of Reusable Rules. The feature that allows to reuse any evaluation type rule in any other rule as if it were a simple field of System.Boolean type. (Imagine if your organization used a simple condition of Age is greater or equal to 21 in hundreds of its business rules. Obviously, if the value of 21 changes tomorrow, your organization would need to edit, test, and re-deploy all those rules with the new value. Having that condition as a reusable rule allows for much greater flexibility, because any change to that rule is instantly adapted by all other rules that may use it.) ● Code Effects component generates business rules in XML format
Because it's an XML document, a rule can be stored pretty much anywhere. There are e two options to store rules:
1- Simply store each rule as a separate XML file
2- Store multiple rules in a single XML file. Such file is known as ruleset. (This feature could be considered in our architecture as a possibility to make different permissions on different rules defined from caregivers and final user)
● Invalid rules or incomplete rules are flagged with useful mouse over error messages for each problem.
● The editor offers multilingual support ● Multiple themes are presented
● The engine supports caching of rules to improve performance when the same rules are called repeatedly
● Rule-Based Data Filtering, and it can be used with any LINQ provider as long as it supports common operators, such as contains, less than, is null, and so on. It would be possible to try this feature by using A filter is nothing more than a business rule attached to a data selection query. It would be safe to say that rule-based data filtering is a logical "side effect" of business rules.
In the Figure 3.1 the possibility of using common operators in “Web Rule” business rule engine is demonstrated.
Figure 3.1
In the picture the page related to create a rule is shown. The rule editor could be used to define a new rule (Figure 3.2) and predefined phrases which have been stored as glossaries (sometimes called vocabulary according to the context of rule engines) are displayed to be used when a rule is getting defined (Figure 3.3).
Figure 3.2
Figure 3.3
3. OpenRules, Inc.11
● Represent Decision Tables (some demonstrations in Figure 3.4)
● Define Business Glossaries, according to some variables and their values we may decide which rule to generate or execute, thus we need a glossary of decision variables (Figure 3.5)
● Create and Execute Test Cases
● Efficiently Execute Business Decisions ● Predictive analytics
● Dynamic Rules Updates (If a business rule is changed, OpenRulesEngine automatically reloads the rule when necessary.)
● Constraint solving, optimization ● There is no rule language to learn ● No coding of rules is required
● It allows OpenRules customers to use standard spreadsheet editors such as MS Excel™, OpenOffice™, or Google Docs™ as OpenRules Editors
● If a business rule is changed, OpenRulesEngine automatically reloads the rule when necessary.
● These are normal steps to work with OpenRules:
i. Rule Harvesting: initializing and defining data types needed to define a new rule
ii. Rule Automation: adding in decision tables necessary implementation details using snippets of Java code inside Excel's hidden rows
iii. Rule Testing and Analysis: finally, creating simple tests using Data tables and we running business rules against different data to analyse and tune our business rules.
Figure 3.5 Decision Table in OpenRules, Inc.
4. MAGENTO12
Magento is an Order Management Platform in which rules are defined in order to address eCommerce requirements. It coordinates customers’ orders in a sales fulfilment channel. Its orchestrating and optimizing systems is based on rules and processes. In the plain rule editor provided in order to coordinate Catalog price rules can be used to selectively put products on sale under certain conditions. Catalog price rules benefits from a plain lightweight editor to define rule. The views are designed simply according to the boldest requirements and includes the following steps:
1. Step 1: Add a New Rule (Figure 3.6)
Figure 3.6
2. Step 2: Define the Conditions (Figure 3.7)
Figure 3.7
3. Step 3: Define the Actions
Figure 3.8
5. Drools13: Business Rules Management System (BRMS) solution. It provides a core Business Rules Engine (BRE), a web authoring and rules management application (Drools Workbench) and an Eclipse IDE plugin for core. In Figure 3.9 a view of the frontend is displayed.
● It is a part of JBoss community
● It is a project that has community releases from JBoss.org that come without support.
6. RuleBurst14: Oracle has acquired Ruleburst Holdings Limited, the parent
company of Haley Limited (Haley15).
● A comprehensive enterprise policy automation solution
● An enhanced offering for social services customers from an end-to-end packaged application solution
● Enhanced policy modeling and automation capabilities for legislative and regulated industries such as public sector, financial services and insurance
● Reduction in claims administration costs, payment errors and appeals ● Empowerment of business users to manage complex policies and
business rules without the need for specialized programming skills ● RuleBurst’s framework for compliance has workflow, neural networks
(for fraud detection) and rules.
● It implified the provision of complex government information to citizens; banking, finance and insurance industry compliance and process solutions; and entitlement and benefit assessment for government and the private sector
7. NxBRE16, is a lightweight Business Rule Engine (aka Rule Based Engine) for the
.NET platform.
● NxBRE does not expose in any way the rules to the development environment: the rules are interpreted by the engine itself. The responsibility of the application is to expose information to the rule engine so it can process the rules
● If you work with the Flow Engine, the information is exposed as pure objects via the engine Context; if you work with the Inference Engine, the information is exposed as facts (which are basic pieces of data - predicates - related together by a named relationship : eg. "A is the father of B", A and B are predicates and "is the father of" is the fact type). ● So the steps an application does are the following:
i. load a rule file in the engine, ii. expose information to the engine, iii. ask the engine to process,
iv. analyze the deductions made by the engine.
● It is possible to either create rules with an XML editor, Visio, a text editor (if some may use NxDSL) or even create your own editor
8. Acumen Business17 (for RuleML): The Rule Manager is a Business Rules
RuleML, Windows Workflow Foundation and BizTalk. In Figure 3.10 a demonstration of the Rule Editor view is displayed.
The feature are consisting as the following: ● Business friendly term names ● Intelligent type conversions ● Term lookup suggestions
● Operator insertion: – ‘>’ key inserts ‘is greater than’ ... ● Invalid expression mark
● Edit time user input constraints ● Restrictive editing
● Detection of Self Anomalies and Rule Anomalies: it can track inconsistencies or incompleteness among the business rules by avoiding:
i. Contradictions ii. Redundancies iii. Tautologies
iv. Incompleteness
● Easily visualized in Rule Conflict Network graphs
● Interactive Rule Graph explores the rule dependency network ● Search and Filter for managing large rulesets
● Rule Map (Cause-effect diagram) becomes a simulation of the actual rule execution.
● Every term can be set as a goal
● Test scenarios and expected outcomes can be saved for regression tests (next release)
● Rule Documentation
● Export to Windows Workflow Foundation ● Rule Report generation to PDF format
Figure 3.10
9. BizTalk18 is a server implemented by Microsoft that automates processes with
enterprise-wide application integration. The automation service enables business process execution and workflow by seamlessly connecting on-premises systems to cloud-based applications. It provides an efficient inference engine that can link highly readable, declarative, semantically rich rules to any business objects (.NET components), XML documents, or database tables. Application developers can build business rules by constructing rules from small building blocks of business logic (small rule sets) that operate on information (facts). The design owns the following special characteristics are regarded to it:
● With the deployment history it provides an audit trail of when the current version of the rule was deployed/published
● We can set the can access permission to Business Rules for the chosen user.
A view of the Business Rules editor is shown while defining the rule for a loan approval procedure in Figure 3.11.
Figure 3.11
10. InRule19 is a business rules management system for financial services,
government insurance, healthcare. Some interesting capabilities are as: ● Capability of importing rules from
i. Another IRAuthor application ii. .Net Assembly
iii. JSON Snippet iv. XML schema (XSD)
v. Database schema
● Supports Business language rule (non-developer-friendly)
● Toggle between expression syntax to be used by developer user and also business language syntax for the normal user
● Smart and rich in detecting the entities are needed on an entity and providing several basic methods
● Decision table support ● Test environment available
● Rule tracing: it enables us to view and trace all the states that a special rule has passed giving us the ability to do changes in the
● Authorize permissions in order to assign roles to users for different applications and users
● No need for recompile even refreshing for applying rule modifications The editor has the Microsoft common interface as shown in Figure 3.12.
Figure 3.12
In Figure 3.13 the Create rule view is demonstrated.
Finally, we may see a brief and swift comparison between the user interfaces have been observed in the following Table 3.1.
Table 3.1 User Interface features comparison
The final list of desired features have been elicited from the comparison which have been done and the outcomes related to the requirement analysis phase as well. In the next chapter, we will determine which features to be implemented. Also, the technologies that we have chosen and the manner to implement the final system will be discussed as the design of the solution.
4 Design of the Solution
4.1 Priority Features List for the User Interface
According to chapter 2 section 2.2, from the comparison we made between Rule-based architectures and CEP solution, we may have in mind two approaches for the user interaction in our target User Interface. Some engines which allow CEP (Complex Event Processing) introduce “query based CEP” or “rule-based CEP” as our solution. While query based CEP could be highly challenging for the normal user in Bridge, rule-based solution can be a proper response to the need. In the following specification, the characteristics of a easy-to-use and user-friendly User Interface introduced which we intend to implement and apply in order to benefit from a smooth and convenient user interaction in Bridge. Our purpose is to provide a uniform access to devices and information and to facilitate different kinds of interactions with them. The priorities extracted from investigating provided solutions and doing R&D on this field are presented as list below:
1. Reusability of rules
2. Easy use for normal users
3. Support for common operators that are familiar for the user 4. Business glossary or vocabulary definition
5. Supporting decision tables
6. Detection of self-anomalies or rule anomalies (having the feature of detecting some errors while creating rule using for example mouse over event in javascript while making an error of comparing 2 different types in the if statement)
7. Conflict handling between different rules or duplicates
8. Caching of rules for proficiency aims (perhaps would be applicable in this phase of the project)
9. Hot deployment (not necessary in this phase) 10. Import/export rules (not necessary in this phase) 11. Multi-lingual support (not necessary in this phase)
4.2 Most Required Features List
Aside from the priority list we mentioned in the previous part, our specific functional features of interest in the rule editor to be implemented could be observed as a list that will be presented in the below; though all of them will not be present in this version of the project, we mention all the extracted features here and then in the following parts related to Suggested Features and General Structure respectively, we will finalize what has been considered and done.
4.2.1 General Required List for Rules
1. Considering specific list of elements of the concepts or values that could be repeatedly used in the condition part by multiple rules (like what we do via Enums in java), for instance if any of the lights of the following list is on, set the night mode in house. For this kind of comparisons we might supply the user by the capability of creating a list of possible values in order to define a group of things or various statuses (of devices or other particular statuses or modes) or diverse cases of concepts like:
“The house is complebright or is dark”
This categorizing of concepts or statuses can help the user to avoid redundancy of defining similar situations in conditions, actions and even events; while makes the rule definition procedure customized for each user. This categories may be used as keywords for extracting the pattern detection of user's behaviour.
2. Supporting priority definition for rules 3. Enable statuses: active and inactive for rules 4. Having a trace and test environment
5. Ability to import entities from database
6. Ability to receive data from external resources (for ex. a web service which provides the weather forecast, other one which could provide emergency numbers, or the service that can receive the time and date).
7. Supporting of detecting empty or invalid parts of the rule (type-checking for entity attributes or data types, and if those are compared with right type, for actions).
8. Vocabulary Management (glossary): Business Terms are the building blocks to write rules. Terms are organized into vocabularies, and are managed similarly
to rules. Defining terms and providing a clear semantics is essential in order to avoid misunderstanding and redundancy as well. For example ‘Legal Age’ is predefined already as equal or greater than 16.
9. Ability to integrate with Java Applications (or other programming languages in case) to merge other apps functionalities to the system.
10. Define edit-time constraints on terms: The value of the temperature must be strictly inside an interval. Constraints should be enforced by the business rule editor. For example if the rule author(final user) while defining the rule tries to compare a field which has been detected to be integer and strictly inside a particular interval with an out of quota restrictions value, the input text borders should get red and in the same way we may show a red text hint in front of or under the text field to warn the user and preventing to save the rule before elaborating the text files in a proper way.
11. Considering the cases in which some sequences of events could come up and how to provide the user by easy and handy ability to be able to define this kind of scenarios so that Espertech could take advantage of them to process determine the behavioral patterns. This is related to the “Events” in particular and the required design will be discussed in section 4.2.2
As a consequence of comparison and investigation on the features that can be considered in order to design a UI and the ones that are currently both in high priority and useful, the Table 4.1 is extracted. It gives a categorization between functional and nonfunctional features. By functional we mean those characteristics which claim technical implementation involvement and imply programming effort to enhance or add an operational task. The Executive versus Interactive column contrasts the distinction whether the property influences the interface or the backend business layer or both.
Feature
Non-functional Functional or Executive or interactiveVocabularies or glossaries ✔ exe
Priority for rules ✔ exe
Status for rules ✔ exe
Enhancing the UI environment and
style ✔ UI
Boosting the rule
creation/modification procedure ✔ exe/UI Test or trace functionality ✔ exe Elaborating the user interface
structure ✖ UI
Stop/resume functionality ✔ exe
History of rules ✔ exe
Support for common operators ✖ exe
Detection of self-anomalies in rules ✔ exe/UI
Ability to import entities from
database ✔ exe
Define edit-time constraints on terms ✔ exe/UI
Categorization the events by the
underlying device ✔ exe/UI
Import/export rules (not necessary in
this stage) ✔ --
Caching of rules (not necessary in
this stage) ✔ --
Ability to integrate with Java
Applications ✔ --
Hot deployment (not necessary in
this stage) ✔ --
Multi-lingual support (not necessary
in this stage) ✔ --
Twitter attachment ✔ --
4.2.2 Required Specific Functionalities for “Events”
The UI is supposed to assume this fact that the user doesn’t have the mentality of business logic or programming languages capabilities. Therefore, the aimed user interface is supposed to make the user equipped by tools to define the events that should be handled as a whole (status of devices or magnitude of some factors or elements like temperature threshold, time period stay in every special section of the house, brightness level). These kind of occasions, in which several or all of the cases might occur inline, includes the possibility of coincidence in some events and might be seen as cases by Espertech engine for extracting the information and leads it to identify a pattern or specific prototypic recognition of a common behavior.
Addressing this requirement which seems essential for the “Events”, we may consider some statements as the following:
In case of occurrence of: a. All of the following events are happening b. None of the following events happened c. Any of the following events has happened
d. The sequence of the following events has happened (sometimes it causes considering time window to detect some patterns by Espertech engine) e. Terminating any of the following events
f. Terminating all of the following events
4.2.3 Required Specific Functionalities for “Conditions”
Following functionalities are required to be considered building with respect to “conditions” are as the following:a. All of the following conditions are true, this implies a “condition set” to be met and it can be used in occasions in which more than one condition should be satisfied to let an action happen.
b. All of the following conditions are false, this feature implies a “condition set” to be evaluated as false and it can be used in occasions in which more than one condition should bring about as false before that an action can happen.
c. Any of the following conditions are true, in this feature if one of the conditions included in a “condition set” is evaluated as true the related action in the respected rule can happen.
d. Any of the following conditions are false, in this case if any of the conditions included in a “condition set” is evaluated as false the related action in the respected rule must be prevented to happen.
e. None of the following conditions are true, in this feature the whole of conditions included in a “condition set” must be evaluated as false. f. None of the following conditions are false, in this feature the whole of
conditions included in a “condition set” must be evaluated as true. g. At most, this case is to make a comparison to a maximum threshold or in
a condition set having not more than some conditions evaluated as true. h. At least, this is to new a condition in which we intend to make a comparison to a minimum threshold or check to have at least one condition in a set to be true.
i. Exactly, this is the case that we want to cope with the situations in which some specific conditions amounts to be equal to a certain value or a determined set of conditions must behave in a particular way.
j. More than, this proper to compare a value and the outcome would be true just if the value compared to is less than or equal to the one mentioned in the specified condition.
k. Less than, again this is for the cases that we want to compare a value and the outcome would be true just if the value compared to is greater than or equal to the one mentioned in the specified condition.
l. Between, the case to evaluate some values to fall into a particular interval.
m. Other than, this means like except for, it points out to the case that if any other unspecified conditions except for the ones specified are evaluated as true.
It should be noted that all the options that have been mentioned are not needed for the frontend in the Bridge Ruler project. For the implementation selection options, we had in mind to provide maximum simplicity and easy-to-use features to keep the final user experience as a plain but efficient one.
4.2.4 Required Specific Functionalities for “Actions”
For Actions, we may handle several actions or other common functionalities if needed. Though most of the times the actions could be defined as core commands and this feature might not be of much interest. In the following the plausible functionalities that may be useful in some scenarios are listed:
a. Next b. Wait c. Repeat d. Start e. Stop f. Pause
This list considers a variety of requirements and most of them would be useful in exceptional or special cases. In the Bridge Ruler application some of them are eliminated and the focus has been drawn to implement the most usable ones. Therefore, in the current version initiating actions on devices are possible (start, stop or pause an act on a related device); the other ones have not been determined useful in case of having the devices and appliances available at the current stage and could be kept for future extensions.
4.2.5 Some examples
examples are brought here to clarify these kind of situations: ❖ Scenario 1
➢ Event: kettle for boiling the water is switched on: waiting for the water to boil,
➢ Condition: temperature goes beyond 120° F (or in other case the timer finishes counting and the time is over),
➢ Action: Send a notification to a device (mobile, tablet, laptop,...)
❖ Scenario 2
➢ Event: The microwave is switched on (waiting the food to get reheated)
➢ Condition: The temperature goes beyond 200° F or the timer is over)
■ Case 1: If both conditions are satisfied
■ Case 2: If any of the conditions is terminated
■ Case 3: If the order of termination of defined conditions is as follows:
● Firstly, microwave finishes working (timer is over) ● Secondly, both conditions met (waiting until both
temperature and time constraints are satisfied) ➢ Action:
■ Case 1
● Send me an alert and
● Turn on the kitchen light and play a notification alert, or turn the bedroom light on
■ Case 2: Send me a notification alert
■ Case 3: Turn on the light of the kitchen on and turn the bedroom light off
4.3 Suggested Features on the User Interface
As a result of requirement analysis and comparisons we have made in the documents far, there are some suggestions that seem to be appropriate to be considered and get implemented in the frontend.
The list below contains an entire features list. Some are implemented in the current version of Bridge Ruler project, the others will remain as the future works.
1. Assuming status for rules (implemented)
2. Enhancing the UI capabilities in general (increasing readability, CSS improvement, elaborating the style, changing the position of buttons, etc.) (implemented)
3. Boosting the rule creation procedure by applying constraints on the time of definition (checking types, constraint validation, conflict between rules), on this issue, we may use javascript to detect the empty fields or type errors which are detected while making the rule to improve the efficiency of UI. (not implemented in this version)
4. Instead of having a dialogue window get opened we may consider the environment with a sidebar panel on the left for (implemented):
a. Rules
b. Events (sequence or single)
c. Conditions (single or a set of Conditions) d. Actions
e. Devices
5. Stop and resume functionality for rules (implemented) 6. Assuming priority to rules (implemented)
7. History of rules, ability to revert to previous rule, helping the user to keep track of changes and recently changes- especially for elderly uses that may have memory problems (not implemented)
8. Twitter part will give the ability to the user to add or remove twitter account, whereas we can also represent to the user the possibility of monitoring a history or report of the messages which have been sent from the application to the caregivers, so that if there’s any of them that the user doesn’t feel comfortable with can modifications of them (not implemented).
