FP7-ICT-2013-EU-Japan ClouT: Cloud of Things for empowering the citizen clout in smart cities FP7 contract number: 608641
NICT management number: 167 ア Project deliverable
D3.1 - Reusable components, techniques and standards for City Platform as a Service (CPaaS)
ABSTRACT
The objective of this document is to describe the reusable components in the City Platform-as-a- Service (CPaaS) layer. The services, and the API’s exposed by CPaaS infrastructure, depend on the requirements and on the architecture defined in WP1. WP3 also describes the non-functional requirements, such as the security requirements. This WP is focused on city information infrastructure, cloud storage components, with the dependents interfaces, security layer and all the infrastructure necessary to access and manage data. WP3 is focused also on the access control and fault-tolerance methods for access and manage data.
D3.1 - Reusable components and techniques for CPaaS
Disclaimer
This document has been produced in the context of the ClouT Project which is jointly funded by the European Commission (grant agreement n° 608641) and NICT from Japan (management number 167ア). All information provided in this document is provided "as is" and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. This document contains material, which is the copyright of certain ClouT partners, and may not be reproduced or copied without permission. All ClouT consortium partners have agreed to the full publication of this document. The commercial use of any information contained in this document may require a license from the owner of that information. For the avoidance of all doubts, the European Commission and NICT have no liability in respect of this document, which is merely representing the view of the project consortium. This document is subject to change without notice.
The ClouT consortium is composed of the following institutions
No. Participant organisation name Short name Country
Commissariat à l’énergie atomique et aux énergies CEA 1 France alternatives (coordinator)
2 Engineering Ingegneria Informatica SpA ENG Italy
3 University of Cantabria UC Spain
4 STMicroelectronics S.r.l. ST Italy
5 Santander City Municipality SAN Spain
6 Genova Municipality GEN Italy
7 Nippon telegraph and telephone East Corporation NTTE Japan (NTT East) (coordinator)
8 Nippon Telegraph and telephone corporation (NTT NTTRD Japan R&D)
9 Keio University KEIO Japan
10 Panasonic System Solution PANA Japan
11 National Institute of Informatics NII Japan
ClouT – 31.07.2013 Page 2
D3.1 - Reusable components and techniques for CPaaS
EU Editor Cosimo Greco, ENG JP Editor Kenji Tei, NII Authors [Cosimo Greco, ENG], [Levent Gurgen, CEA], [Yazid Benazzouz, CEA], [Stefania Manca, GEN], [Takuro Yonezawa, Keio], [Kenji Tei, NII], [Fuyuki Ishikawa, NII], [Jose Antonio Galache, UC], [Fernando Mons Nunez, SAN] Internal reviewer Marco GRELLA, ST Deliverable type R Dissemination level PU (Confidentiality) Contractual Delivery Date 31/07/2013 Actual Delivery Date 31/07/2013 Keywords ClouT, Cloud Computing, IoT, Smart Cities, CPaaS, Reusable Components
Revision history
Revision Date Description Author (Organisation)
V0.1 10.06.2013 Table of Contents ENG created V0.2 08.07.2013 First draft with ENG contributions from all partners V0.3 12.07.2013 Second draft with ENG contributions from all partners V0.4 19.07.2013 Added Santander ENG contributions. V0.5 19.07.2013 First consolidated ENG version sent for internal review V0.6 26.07.2013 Reviewed version ST V1.0 31.07.2013 Final version ENG
ClouT – 31.07.2013 Page 3
D3.1 - Reusable components and techniques for CPaaS
TABLE OF CONTENTS
TABLE OF CONTENTS ...... 4 LIST OF FIGURES ...... 5 LIST OF TABLES ...... 7 LIST OF ABBREVIATIONS AND DEFINITIONS ...... 8 EXECUTIVE SUMMARY ...... 9 1. INTRODUCTION ...... 10
1.1. SCOPE OF THE DOCUMENT ...... 10 1.2. TARGET AUDIENCE ...... 10 1.3. STRUCTURE OF THE DOCUMENT ...... 10 2. SERVICE COMPOSITION PLATFORMS FOR CITIZEN’S APPLICATIONS ...... 12
2.1. INTRODUCTION ...... 12 2.2. SERVICE COMPOSITION AND MASH-UP TOOLS REUSABLE COMPONENTS ...... 13 WIRECLOUD ...... 13 Mycocktail ...... 14 Enterprise Mashup Markup Language ...... 15 OpenSocial ...... 16 Yahoo! Pipes ...... 17 Apache Shindig ...... 18 iPojo ...... 20 BPMN ...... 22 BPEL ...... 24 2.3. DEPENDABLE SERVICE COMPOSITIONS REUSABLE COMPONENTS ...... 25 Robust Service Composition METHOD ...... 25 QoS-based Service/CLOUD Selection Method ...... 26 Metadata-based Behavior Insertion FRAMEWORK ...... 27 Verification Framework of Time and Resource Constraints on Business Process ...... 28 Verification Framework of ECA Specification on Physical Interactions ...... 29 3. BIG DATA PROCESSING ...... 30
3.1. INTRODUCTION ...... 30 3.2. DATA/EVENT PROCESSING AND DECISION MAKING REUSABLE COMPONENTS ...... 31 Esper ...... 31 FI-WARE Gateway Data handling ...... 33 Jboss Drools Expert ...... 35 MongoDB ...... 36 3.3. SELF-HEALING FOR DATA/EVENT STREAMING REUSABLE COMPONENTS ...... 37 Self-healing Framework for Sensory Data ...... 37 Fault Classification Model ...... 39 4. SECURE AND DEPENDABLE ACCESS TO CITY DATA ...... 40
4.1. INTRODUCTION ...... 40 4.2. OPEN CITY DATA HOSTING AND ACCESS REUSABLE COMPONENTS ...... 41 HYPERTABLE ...... 42
ClouT – 31.07.2013 Page 4
D3.1 - Reusable components and techniques for CPaaS
Hbase...... 43 HDFS ...... 45 OPEN STACK SWIFT ...... 47 CEPH ...... 48 object Storage GE - FI-WARE Implementation ...... 50 CDMI Proxy ...... 50 Rest/soap apis for idas access ...... 51 TESTBED RUNTIME ...... 51 SOA3 ...... 52 4.3. DEPENDABILITY TOOLS FOR ACCESSING CITY DATA REUSABLE COMPONENTS ...... 53 D-Case Monitoring tool ...... 53 5. OTHER REUSABLE CPAAS ASSETS FROM CITIES ...... 57
5.1. INTRODUCTION ...... 57 5.2. GENOA REUSABLE CPAAS ASSETS ...... 57 RoadVisior - eMixer Platform ...... 57 WEATHER StatioN ...... 59 5.3. SANTANDER REUSABLE CPAAS ASSETS ...... 60 GIS PlaTFORM ...... 60 OPEN DATA PLATFORM ...... 65 Oracle Database Platform ...... 67 SAE Platform ...... 69 Incisis Platform ...... 70 5.4. FUJUSAWA REUSABLE CPAAS ASSETS ...... 72 Disaster prevention GIS system ...... 72 digital signage systeM ...... 73 5.5. MITAKA REUSABLE CPAAS ASSETS ...... 74 GIS system ...... 74 6. CONCLUSIONS...... 75
6.1. SERVICE COMPOSITION PLATFORMS FOR CITIZEN’S APPLICATIONS ...... 75 6.2. BIG DATA PROCESSING ...... 76 6.3. SECURE AND DEPENDABLE ACCESS TO CITY DATA ...... 76 6.4. CITY RESOURCES ...... 76 7. APPENDIX ...... 77
7.1. TG3.1 REUSABLE COMPONENTS...... 77 7.2. TG3.2 REUSABLE COMPONENTS...... 93 7.3. TG3.3 REUSABLE COMPONENTS...... 97 REFERENCES ...... 115
LIST OF FIGURES
ClouT – 31.07.2013 Page 5
D3.1 - Reusable components and techniques for CPaaS
Figure 1. ClouT City Architecture for Smart City Ecosystem ...... 10 Figure 2. WIRECLOUD Architecture ...... 13 Figure 3. MYCocktail web tool ...... 14 Figure 4 Open MyCocktail ...... 15 Figure 5. Yahoo pipes mashup tool ...... 17 Figure 6. apache shindig overall architecture ...... 18 Figure 7. apache shindig server architecture ...... 19 Figure 2-8iPojo Component example ...... 21 Figure 9Example of BPD (Stephen A. White) ...... 22 Figure 10. Robust Service Composition Method ...... 25 Figure 11. QoS-based Service ...... 26 Figure 12. Metadata-based Behaviour Insertion Framework ...... 27 Figure 13. Verification Framework of Time and Resource Constrains on Business Process ...... 28 Figure 14. Verification Framework of ECA Specification on Physical Interactions ...... 29 Figure 15CEP principle (Angelo Corsaro) ...... 31 Figure 16Esper integration to OSGi ...... 32 Figure 17Data Handling GE Architecture ...... 33 Figure 18High-Level production rule system ...... 35 Figure 19 Self-Healing Framework for Sensory Data ...... 37 Figure 20 - Fault Classification Model ...... 39 Figure 21 - Hypertable Architecture Overview ...... 42 Figure 22- Hbase architecture overview ...... 44 Figure 23 - Hbase cyclic replication overview architecture ...... 44 Figure 24. Apache Hadoop HDFS architecture overview ...... 46 Figure 25 - Apache Hadoop Cluster Server Roles ...... 46 Figure 26 - CEPH UNIFIED STORAGE ...... 48 Figure 27 Screenshot of D-Case Monitoring Tool ...... 53 Figure 28 System Overview of D-Case Monitoring Tool ...... 54 Figure 29 Web Page for Detailed Monitoring Data ...... 55 Figure 30 Santander cluster database architecture ...... 67 Figure 31 SANTANDER INCISIS implementation architecture ...... 70 Figure 32 Santander INCISIS FUNCTIONAL SCHEMA ...... 70 Figure 33 INCISIS SERVICE EXAMPLE SCHEMA ...... 71 Figure 30: Fujisawa disaster prevention gis system ...... 72 Figure 31. Overview of Fujisawa Signage ...... 73 Figure 32:Mitaka GIS system ...... 74
ClouT – 31.07.2013 Page 6
D3.1 - Reusable components and techniques for CPaaS
LIST OF TABLES
Table 1. List of ABBREVIATIONS ...... 8 Table 2. List of KEY TERMS ...... 8 Table 3 List of Available Monitoring Programs ...... 54 Table 4 – OPEN STACK SWIFT ...... 77 Table 5- Wirecloud ...... 78 Table 6- MyCoctails ...... 79 Table 7- Enterprise mashup markup language ...... 81 Table 8- opensocial ...... 82 Table 9- Yahoo! pipes ...... 83 Table 10- apache shindig ...... 84 Table 11- iPojo ...... 85 Table 12- BPMN ...... 86 Table 13- BPEL ...... 87 Table 14 – ROBUST SERVICE COMPOSITION Method ...... 88 Table 15 – QOS-BASED service/cloud SELECTION method ...... 89 Table 16 – metadata-based BEHAVIOR INSERTION Frmaework ...... 90 Table 17 – BPMN VerifiCation ...... 91 Table 18 – ECA VERIFICATION ...... 92 Table 19- ESPER ...... 93 Table 20- FI-Ware Gateway Data Handling ...... 94 Table 21- JBoss DRools Expert ...... 95 Table 22- MongoDB ...... 96 Table 23- REST/SOAP API’s for IDAS access ...... 97 Table 24- Testbed Manager ...... 98 Table 25 D-case monitoring tool ...... 99 Table 26 – Self-Healing Framework for Sensory Data ...... 100 Table 27 – Fault Classification Model ...... 101 Table 28– HYPERTABLE ...... 102 Table 29 – HBASE...... 103 Table 30 – HADOOP HDFS ...... 104 Table 31 – OPEN STACK SWIFT ...... 106 Table 32 – CEPH ...... 108 Table 33 – Object Storage GE - FI-WARE Implementation ...... 110 Table 34 – CDMI Proxy ...... 112 Table 35 – SOA3 ...... 114
ClouT – 31.07.2013 Page 7
D3.1 - Reusable components and techniques for CPaaS
LIST OF ABBREVIATIONS AND DEFINITIONS
TABLE 1. LIST OF ABBREVIATIONS
CIaaS City Infrastructure as a Service CPaaS City Platform as a Service CSaaS City Service as a Service IoT Internet of Things IoT-A Internet of Things - Architecture TG Task Group Wsan Wireless sensor and actuator network RDF Resource Description Framework OSGi Open Services Gateway Initiative API Application Programming Interface REST REpresentational State Transfer JSON JavaScript Object Notation [RFC 4627]. NGSI Next Generation Services Interface iPojo Plain Old Java Object OSGi Open Services Gateway initiative BPMN Business Process Modeling Notation BPD Business Process Diagram UML Unified Modeling Language BPEL Business Process Execution Language GIS Geographic information system RSS Feed Really Simple Syndication Feed
TABLE 2. LIST OF KEY TERMS
Cloud Storage Cloud Storage is a mode to abstract the physical infrastructure, based on silos (federated servers, cluster servers, etc.) where the data are stored. Sensors Equipment used to measure and convert physical quantity (e.g. temperature) or human information (e.g. social data). Actuators Mechanical devices that perform action on command, but also social networks can be used as actuator.
ClouT – 31.07.2013 Page 8
D3.1 - Reusable components and techniques for CPaaS
EXECUTIVE SUMMARY
This document aims at collecting some existing and reusable components, techniques and standards, focusing on the City Platform as a Service (CPaaS) layer. They belong to various categories, such as the cloud storages, databases and standards used to access and manage data stored in the Cloud.
Each partner has described all possible reusable components to be used in this phase of project: in the document are described all the details of the components, with the assessment, for each one, the Known Limitations of the components and the license of use. Some components are used by the cities involved in the project: Santander and Genova in Europe, Mitaka and Fujisawa in Japan.
The content of this deliverable will be used to define the Reference Architecture for ClouT - and the subsequent implementation of the Smart City Ecosystem. Therefore, not all presented objects will be used in the final version of the architecture, but only those ones that better respond to requirements.
ClouT – 31.07.2013 Page 9
D3.1 - Reusable components and techniques for CPaaS 1. Introduction
1.1. Scope of the Document
This document describes initiatives, tools, solutions and available assets from cities on which leverage on to build the CPaaS layer of the ClouT architecture.
As this deliverable, along with D2.1, will serve as starting point for the initial definition of Cloud Architecture (D1.2 deliverable), for each reusable asset it is proposed a short description of its main features along with several useful details are provided. Furthermore a short assessment is given, in terms of opportunities, capabilities and known limits and threats in adopting the reusable component as part of the ClouT architecture.
Figure 1. ClouT City Architecture for Smart City Ecosystem
1.2. Target Audience
The document targets the ClouT platform developers.
1.3. Structure of the Document
Chapter 2 to 4 introduce all candidate components that are part of the TG3.1, TG3.2 and TG3.3 with reference to Description of Work. Chapter 5 lists a set of other existing assets from ClouT involved cities that may be also included as part of CPaaS. The Appendix reports, for each reusable component, a table containing additional details of the component itself. Finally, conclusions are drawn in Chapter 7.
ClouT – 31.07.2013 Page 10
D3.1 - Reusable components and techniques for CPaaS Each chapter is dedicated to a single topic, as shown in the following picture:
Chapter 2 is related to the Service composition and mash-up components.
Chapter 3 describes all the components dedicated to the Big data processing.
Chapter 4 is referred to the secure access and all the components involved.
Chapter 5 is related to the city reusable components.
In details, the Chapter 5 lists a set of further existing assets, extracted from ClouT involved cities – Genoa (Italy), Santander (Spain), Mitaka (Japan) and Fujisawa (Japan). Finally, all conclusions are exposed in the Chapter 6, while the Appendix reports a table for each reusable object, containing general and additional details about them.
ClouT – 31.07.2013 Page 11
D3.1 - Reusable components and techniques for CPaaS 2. Service Composition Platforms for citizen’s applications
2.1. Introduction
This section provides a list of tools that are potentially reusable for the service composition and data mashup objective of the ClouT project. The main goal is to provide a tool to the users (experienced developers, non-technical users, etc.) in order that they can build their own services, therefore making them actively part of the city ecosystem. The list varies from service component models to frameworks that provide verification and validation of the composition.
The main idea behind the platform is to enable a user that comes with its own IoT device, to create its service and publish it in the cloud and share (or un-share) it within a given community. Other services can be created by composing high level services from existing base services and platform services.
This section focuses on the service composition platform (at the CPaaS layer) that will give to the users the opportunity of building their own IoT+Cloud services. Variety of tools exists for different types of users, from most experienced ones (professionals) to inexperienced users (end-users). With a service oriented approach, ClouT will define modular IoT and Cloud service models and identify way of interactions between these services. The interaction will be based on an event-based approach to better reflect the IoT device interaction model. The tool will give the opportunity to the users to define actions to take when specific events occur under given conditions (e.g., Event-Condition-Action rules) that will determine the behavior of the created services.
Some of the tools presented here provide validation and optimization techniques for dependability assurance in the service composition platform. The foundational model of service composition is provided for analysis and reasoning, which supports event-driven, context-aware behavior in the complex and dynamic environment. Functional validation is conducted to detect and prevent undesirable situations, possibly caused by feature interactions. Quality of service is also optimized and assured for user-oriented, end-to-end criteria, through efficient exploration of different possibilities of service composition. Thus these frameworks also provide the underlying components that help users, who develop service compositions, refine and configure the composition to achieve dependability properties.
ClouT – 31.07.2013 Page 12
D3.1 - Reusable components and techniques for CPaaS
2.2. Service composition and mash-up tools reusable components
In this paragraph are listed all the mash-up reusable components: for each of them is reported a short description, with figures if needed, and a link to the correspondent component table in the Appendix.
WIRECLOUD
The Wirecloud Mashup Platform is a framework that allows end-users to create specific mashups composing widgets that are the building blocks to create new applications. The widgets (also called gadgets) can be downloaded from a catalogue and can be provided by 3rd parties. In particular the Wirecloud Mashup Platform is composed by three different components: the Application Mashup Editor, the Mashup Execution Engine and the Catalogue.
The Application Mashup Editor is a web-based composition editor used by the end users to compose their own applications. The editor is a workspace where the users can graphically connect the widgets, downloaded from the catalogue, performing an input-output mapping. The widgets can be connected to back-end services or data sources through an extendable set of operators, including filters, aggregators and adapters.
The Mashup Execution Engine is the component that provides the mashup functionalities coordinating the gadgets execution and communication, mashup, state persistence, and cross- domain proxy. The engine functionalities are exposed to the editor through a set of API: new external modules can be added in order to extend the functionalities.
The gadgets used in the editor can be found and downloaded from the Catalogue, that is an independent component with respect to the previous two: the gadgets published in the catalogue are described in a standard description language. In particular the gadgets can be described through an XML Widget description language and with RDF widget description language. The mashups created by the users can be published in the same catalogue: additionally, the catalogue allows to tag and rate widgets to foster discoverability and share ability.
FIGURE 2. WIRECLOUD ARCHITECTURE
ClouT – 31.07.2013 Page 13
D3.1 - Reusable components and techniques for CPaaS The Wirecloud Mashup Platform has been developed in the FI-WARE project as Generic Enabler reference implementation: it supports linked-USDL and it is integrated with FI-WARE's Marketplace, Stores and Repositories.
For further information please refer to the table in the appendix.
MYCOCKTAIL
MyCocktail is a web application that provides a graphical user interface to easily build mashup easily. MyCocktail provides two different web tools: the mashup builder and the page editor. The mashup builder is a graphical environment that allows combining and modifying data, using specific filters, information coming from REST services, and connecting these data with web gadgets creating mashups. The gadgets can be exported as Google or Netvibes gadgets being compliant with the open social specification. In particular there are three different types of elements that can be combined in the builder:
FIGURE 3. MYCOCKTAIL WEB TOOL
Services: it is possible to use in the mashup information obtained by specific services. MyCocktail provides a set of predefined services to get specific information from several popular services or social networks such as Amazon, Delicious, Flickr, Google, Twitter etc. For example it is possible to perform search on Google or get information about the Twitter followers. Also it is possible to import in the editor new custom REST services using the WADL descriptions (Web Application Description Language). Operators: the data objects obtained from the services invocation can be manipulated using a set of operators. These operators can work on objects, arrays or strings performing a series of functions such as sorting, parsing, splitting etc. Renderers: are graphical elements and widgets that allow rendering the information obtained and manipulated using services and operators. The final graphical output can be exported in different format such as Google or Netvibes gadgets.
ClouT – 31.07.2013 Page 14
D3.1 - Reusable components and techniques for CPaaS The Page Editor allows designing a web page through a GUI allowing integrating mashups created with MyCocktail with other HTML elements. It is based on FCKEditor, a web text editor. The page editor has a complete toolbar in which the elements and the properties to be included in the design area that shows the result page can be selected.
FIGURE 4 OPEN MYCOCKTAIL
For further information please refer to the table in the appendix.
ENTERPRISE MASHUP MARKUP LANGUAGE
EMML (Enterprise Mashup Markup Language) is an XMLmarkup language for creating enterprise mashups promoted by the Open Mashup Alliance. EMML is a declarative mashup domain-specific language (DSL) that eliminates the need for complex, time-consuming and repeatable procedural programming logic to create enterprise mashups.
EMML provides a mashup-domain vocabulary to consume different data-sources. Additionally, the EMML provides a uniform syntax to invoke heterogeneous service technologies (e.g. Web services, rest services, RSS etc.) and to combine different data formats (JSON, XML, JDBC etc).
EMML files can be considered scripts that describe the process flow for a mashup: these scripts must be processed by an EMML engine that interprets EMML statements to perform the mashup. The EMML language provides several functionalities such as:
Data manipulation using filters Connection with heterogeneous services Semantic annotation of services Merge and split datasets Support for scripting languages (e.g. JavaScript, JRuby, Groovy, XQuery) Conditional statements
ClouT – 31.07.2013 Page 15
D3.1 - Reusable components and techniques for CPaaS Data scraping from HTML page
The Open Mashup Alliance has made the EMML schema available for download as well as an EMML reference runtime implementation that processes mashup scripts written in EMML.
For further information please refer to the table in the appendix.
OPENSOCIAL
OpenSocial is a set of common APIs (Application Programming Interface), initially developed by Google, in order to create a single programming model for social applications such as gadgets that can operate on any social network that uses this standard.
Based on HTML and JavaScript, as well as the Google Gadgets framework, OpenSocial includes multiple APIs for social software applications to access data and core functions on participating social networks. Each API addresses a different aspect. It also includes APIs for contacting arbitrary third party services on the web using a proxy system and OAuth for security.
In particular, OpenSocial provides four different categories of APIs that can be used to:
develop Social Application, such as gadgets, that run in specified OpenSocial containers implement Web Container: host social networking environments in which the social applications can be executed allow interaction between web sites and social networks that support the Open Social standard. In particular, existing sites can have access to several information, for instance: o the user profile (user data); o information about user’s friends (social graph); o profile activities (posts, photos, video, news feeds etc.)
The goal of the project is, therefore, to:
increase power and pervasiveness of the social Web capabilities, providing to the developers the tools needed to build applications that can be accessed by an ever increasing number of users, regardless of social networks used; increase interoperability between applications; promoting the portability of web-based components; stimulate the creativity of the user, in order to have new ideas "from below"; create a "framework" open and free that is compatible with the highest number of social networks. OpenSocial is not, a product or a service distributed by Google, but it is an open standard supported by a large community of developers. Furthermore, it is important to highlight how the project is significantly different from what has been achieved in recent years by Facebook which, despite the huge community of developers, has focused mainly on the use of proprietary protocols and languages, maintaining a more conservative approach.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 16
D3.1 - Reusable components and techniques for CPaaS
YAHOO! PIPES
Yahoo! Pipes is a visual programming environment that gives people the ability to create web mashups and web-based applications that combine data from multiple sources. The name comes from the Unix Pipes, which allowed connecting to data source filters and utility of different types. Yahoo! Pipes does not require any type of installation because it is an online service, available at http://pipes.yahoo.com, only a Yahoo! account is required.
It is a free service and allows the management of RSS Feeds and creating interesting mashups.
FIGURE 5. YAHOO PIPES MASHUP TOOL
It is also composed of a graphical editor intuitive and very user friendly.
The core component of Yahoo ! Pipes is the Pipe editor that is composed of three panes which are the canvas, the library and the debugger. The user creates a pipe using these panes using Drag & Drop through which the various modules are composed from existing services. Through Yahoo! Pipes it is possible for example to combine many feeds into one, sort, filter and to geocode the favorite feeds browsing the items on an interactive map. After creation the user can decide to publish the pipes on the website http://pipes.yahoo.com to make them visible to other people than can reuse or modify the pipes.
The output can be in different formats widgets, RSS, JSON, PHP.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 17
D3.1 - Reusable components and techniques for CPaaS APACHE SHINDIG
Shindig is an open source project of the Apache Software Foundation that has the aim to implement an open container in compliance with the Open Social gadgets specifications. According to the Apache Foundation, the project's goal "is to allow new sites to start hosting the social apps in less than an hour's work", creating an infrastructure able to render gadgets, process proxy requests, and handle REST and RPC requests. In the market there are many examples of containers that are based on Shindig, such as LinkedIn, hi5, Partuza, WSO2, Jartuza. From the architectural point of view Shindig consists of four basic components:
Gadget Container JavaScript: component written in JavaScript that manages many gadgets functionalities such as safety, communication, graphical user interface and the access to the OpenSocial API. Gadget Rendering Server: server used to render the gadget XML file in JavaScript and HTML for the container in order to expose the gadget through the Container JavaScript. OpenSocial Container JavaScript: the JavaScript environment that lies on the top of the Gadget Container JavaScript and provides OpenSocial specific functionality, such as profiles, list of friends, activities, datastore. OpenSocial Date Server: is the implementation of a server interface for the access to specific information of the container, and it includes the OpenSocial REST API.
Shindig, from architectural point of view, has a client and a server component. In particular the client part of the system is composed by three elements: The container for gadgets, fully compliant with the OpenSocial gadgets specifications (GadgetsContainer). The OpenSocial container itself (opensocial. Container). The container that supports the exchange of data in the JSON and Caja format to the REST standard (RestfulContainer).
FIGURE 6. APACHE SHINDIG OVERALL ARCHITECTURE
In particular, the latter is an extension of the component OpenSocial container and deals to pass all calls to the API OpenSocial REST endpoint that will take care of both the direct HTTP calls and those from the OpenSocial API.
ClouT – 31.07.2013 Page 18
D3.1 - Reusable components and techniques for CPaaS All calls to the server will be executed by the RestfulContainer and GadgetsContainer through the XmlHttpRequest Gadgets.io that will instantiate an object in order to send requests to HTTP Server.
The Shindig components of the server side are:
Persistent Data Access Layer: loading mechanism of the persistent data. Gadget Rendering Server Components: infrastructure for rendering gadgets. Open Social Components Server: server-side implementations of the OpenSocial API.
FIGURE 7. APACHE SHINDIG SERVER ARCHITECTURE
There are currently two versions of Apache Shindig written in Java and PHP, and a third, written in .NET that is external to the project.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 19
D3.1 - Reusable components and techniques for CPaaS
IPOJO iPOJO (iPojo) (Plain Old Java Object) is a service component runtime aiming to simplify OSGi application development and to build service-oriented component model.
Early efforts, such as the Service Binder and Service Tracker, attempted to give more flexibility to OSGi developers and more recent efforts, such as Declarative Services and Spring Dynamic Modules alleviate some of these issues. iPOJO is another such effort in this area. It has two goals:
providing services, using services, and dealing with dynamism should require as little effort as possible from the developer; component configuration, synchronization, and composition should be incorporated to OSGi mechanisms.
For example, trying to create an OSGi-based application with services is challenging. The OSGi API is complex and a lot of knowledge about internal mechanisms has to be known to avoid synchronization issues. iPOJO provides a very simple development model. The component (Figure 2-8) is a central concept in iPOJO. In the core iPOJO model, a component describes service dependencies, provided services, and call backs; this information is recorded in the component's metadata. In fact, a service is an object that implements a given Java interface. In addition, iPOJO introduces a call back concept to notify a component about various state changes.
To provide a service:
@Component @Provides public class MyServiceImplementation implements MyService { //.... }
In this way, the component is declared as the MyService provider and corresponding OSGi service is created automatically.
To require a service:
@Component public class MyServiceConsumer{ @Requires private MyService myservice;
// Just use your required service as any regular field ! }
After components, the next most important concept in iPOJO is the component instance. A component instance is a special version of a component. By merging component metadata and instance configuration, the iPOJO runtime is able to discover and inject required services, publish provided services, and manage the component's life cycle.
ClouT – 31.07.2013 Page 20
D3.1 - Reusable components and techniques for CPaaS
FIGURE 2-8IPOJO COMPONENT EXAMPLE
iPOJO works on any R4.1 OSGi implementation. It also works on many Java virtual machines such as Oracle JRockit, JamVM, Dalvik (Android), and Mika. iPOJO only requires a J2ME Foundation 1.1 virtual machine. So, iPOJO can be embedded inside mobile phone applications or inside your washing machine. iPOJO is small and was designed to stay small. The core size of iPOJO is approximately 205k (compared to 816k for Guice-Peaberry and 2112k for the minimal Spring-DM configuration). In addition to the core, you only deploy the features you require. For example, if you need proxy injection, just deploy the temporal dependency bundle (less than 70Kb). The run-time overhead of iPOJO is also small. On the Peaberry benchmark, iPOJO has the following performance results:
Guice-Peaberry: 276.00 ns/call iPOJO Service Dependency: 118.00 ns/call Spring-DM: 2384.00 ns/call iPOJO Temporal Dependency: 159.00 ns/call iPOJO Temporal Dependency w/ proxy: 173.00 ns/call
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 21
D3.1 - Reusable components and techniques for CPaaS
BPMN
The Business Process Modeling Notation (BPMN) (BPMN) is a graphical notation that depicts the steps in a business process. A business process spans multiple participants and coordination can be complex. Moreover, well-supported standard modeling notation will reduce confusion among business and IT end-users. BPMN depicts the end to end flow of a business process. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. The following figure shows a Business Process Diagram.
FIGURE 9EXAMPLE OF BPD (STEPHEN A. WHITE)
A BPD is made up of a set of graphical elements. These elements enable the easy development of simple diagrams that will look familiar to most business analysts (e.g., a flowchart diagram). The elements were chosen to be distinguishable from each other and to utilize shapes that are familiar to most modelers. For example, activities are rectangles and decisions are diamonds. It should be emphasized that one of the drivers for the development of BPMN is to create a simple mechanism for creating business process models, while at the same time being able to handle the complexity inherent to business processes. The approach taken to handle these two conflicting requirements was to organize the graphical aspects of the notation into specific categories. This provides a small set of notation categories so that the reader of a BPD can easily recognize the basic types of elements and understand the diagram. Within the basic categories of elements, additional variation and information can be added to support the requirements for complexity without dramatically changing the basic look-and-feel of the diagram. The four basic categories of elements are: Flow Objects, Connecting Objects, Swimlanes and Artifacts.
A key goal in the effort to develop BPMN to help alleviate the modeling technical gap was to create a bridge from the business-oriented process modeling notation to IT-oriented execution languages that will implement the processes within a business process management system. The graphical objects of BPMN, supported by a rich set of object attributes, have been mapped to the Business Process Execution Language for Web Services (BPEL4WS v1.1), the standard for process execution. For example, the core of jBPM (jBPM, 2013) is a light-weight, extensible
ClouT – 31.07.2013 Page 22
D3.1 - Reusable components and techniques for CPaaS workflow engine written in pure Java that allows you to execute business processes using the latest BPMN 2.0 specification. It can run in any Java environment, embedded in your application or as a service.
Other solutions to BPMN exist for example, UML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains (EPCs). The following section illustrates the difference between UML and BPMN and thus it helps to understand more the relationships between these solutions.
BPMN & UML (BPMN)
The unified modeling language (UML) takes an object-oriented approach for modeling applications, while BPMN takes a process-oriented approach for modeling systems. Where BPMN has a focus on business processes, the UML has a focus on software design and therefore the two are not competing notations but are different views on systems. The BPMN and the UML are compatible with each other. A business process model does not necessarily have to be implemented as an automated business process in a process execution language. Where this is the case, business processes and participants can be mapped to constructs such as use cases and behavioral models in the UML.
BPMN TO XML (BPMN 2.0 by Example, 2010)
The XML serialization for BPMN is provided in machine-readable form, which has the OMG Document Number dtc/2010-06-03. It is an international standard formally approved by OMG, it creates XML code that is generated when a person creates a process model.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 23
D3.1 - Reusable components and techniques for CPaaS BPEL
BPEL (BPEL) is the standard for assembling a set of discrete services into an end-to-end process flow, radically reducing the cost and complexity of process integration initiatives.
BPEL (BPEL Definition) is an orchestration language, and not a choreography language. The primary difference between orchestration and choreography relies on the executablility and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. Choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration (e.g., in the form of a BPEL process) for each peer involved in it.
BPEL has no graphical notation witch conducted to a variety of different notations causing ambiguities and misunderstanding. BPMN is then used to fill this gap.
The following figure (Leymann, 2010) explains more the relationship between BPEL and BPMN using a concrete example.
ORACLE BPEL
Oracle BPEL (ORACLE BPEL Process Manger, 2009) process Manager is a tool for designing and running business processes. This product provides a comprehensive, standards-based and easy to use solution for creating, deploying and managing cross-application business processes with both automated and human workflow steps – all in a service-oriented architecture. Oracle BPEL Process Manager could be used in isolation to implement business processes, but the real power comes when it is used in conjunction with other SOA components. For example, you can instrument your BPEL processes using the Oracle BPEL Process Manager’s sensor framework. Sensors can fire events under conditions specified by the administrators and send events to any endpoint that administrators choose. This makes it easy to monitor processes when there are hundreds or thousands running in parallel.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 24
D3.1 - Reusable components and techniques for CPaaS
2.3. Dependable Service Compositions reusable components
In this paragraph are listed all the Dependable Service Composition reusable components. For each component it is reported a short description and a link to the correspondent component table in the Appendix.
ROBUST SERVICE COMPOSITION METHOD
This method provides foundations for service composition that deal with differences in service functionality and quality as well as their faults or changes. It can be instantiated as an analysis and design method by human developers, or an algorithm for automated service composition. The core of the method is a modeling structure to efficiently represent and analyze slightly different service functions. It can be used to: - understand the differences - efficiently find matching between service functions - efficiently find alternatives for a certain function - and assess feasibility or sustainability about realization of a certain function by external providers. For the automated usage, an efficient algorithm is provided: it uses the model and it constructs a robust service composition plan by analyzing alternatives or risks of lock-in. The algorithm has some customizations using the alternative information on a genetic algorithm so that semi-optimal solutions are obtained efficiently, even though the problem is much more complex than standard ones by considering alternatives.
FIGURE 10. ROBUST SERVICE COMPOSITION METHOD
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 25
D3.1 - Reusable components and techniques for CPaaS
QOS-BASED SERVICE/CLOUD SELECTION METHOD
This method provides an algorithm for QoS-based selection of services or clouds to use. This method basically follows and handles the standard problem of QoS-based service selection, which selects services to use in a service composition according to a variety of QoS (Quality of Service). The methods considers both of preferences over multiple criteria (e.g., price is more important than execution time) and end-to-end constraints (e.g., total execution time must be less than $1 per invocation). The method extends this standard setting by also considering network QoS between interacting services. It thus includes model that defines aggregated quality of services and networks involved in a service composition. It also provides an efficient algorithm for QoS optimization by customizing a genetic algorithm to reflect location of services in a network model.
FIGURE 11. QOS-BASED SERVICE
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 26
D3.1 - Reusable components and techniques for CPaaS
METADATA-BASED BEHAVIOR INSERTION FRAMEWORK
This framework provides a way to insert additional behaviors into service compositions to achieve value-added functions often for non-functional requirements. It defines an algorithm to properly insert additional behaviors according to constraints or rules. These constraints or rules work on metadata attached on service compositions. Thus they are simple and one specification item can trigger insertions in multiple execution points in multiple compositions (e.g., insert logging behavior before "PRIVACY" data is sent to a "THIRD PARTY").
FIGURE 12. METADATA-BASED BEHAVIOUR INSERTION FRAMEWORK
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 27
D3.1 - Reusable components and techniques for CPaaS
VERIFICATION FRAMEWORK OF TIME AND RESOURCE CONSTRAINTS ON BUSINESS PROCESS
This framework provides a capability to verify time and resource constraints on service compositions or business processes through model checking. It provides a small annotation syntax on BPMN (Business Process Modeling Language) for time and resource constraints. It has conversion rules from BPMN with the annotations into UPPAAL, a timed model checker, which exhaustively explores possible state changes to verify the constraints.
FIGURE 13. VERIFICATION FRAMEWORK OF TIME AND RESOURCE CONSTRAINS ON BUSINESS PROCESS
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 28
D3.1 - Reusable components and techniques for CPaaS
VERIFICATION FRAMEWORK OF ECA SPECIFICATION ON PHYSICAL INTERACTIONS
This framework provides a capability to verify complex combinations of ECA (Event-Condition- Action) rules that have effects on shared spaces often by multiple users. It provides a language for high-level specification of physical interactions (e.g., visual, audio). It also defines conversion rules of the description into SPIN, a model checker. Several templates are provided for proper formula to check, which are difficult to properly define by temporal logic.
x FIGURE 14. VERIFICATION FRAMEWORK OF ECA SPECIFICATION ON PHYSICAL INTERACTIONS
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 29
D3.1 - Reusable components and techniques for CPaaS
3. Big data processing
3.1. Introduction
This section gives the currents state of the art in terms of reusable data processing components that can be considered when developing ClouT’s data processing subsystem. Given the ubiquity and increasing number of devices in the future Internet of Things, scalable data processing infrastructures are necessary to collect and process a ”terabyte torrent” coming from trillions of devices. The ClouT’s data processing subsystem will provide an event processing engine that will collect events from the city, process them to obtain higher level information that can be accessed by other services and applications (e.g., subscribers). Traditional SQL-based database languages are not any more adequate for managing the high stream of data from IoT. The querying and processing techniques should be revised in order to take into account the real-time nature of the applications. One part of the processing should be when possible done at the device level, thus exploiting devices processing capabilities.
Data need to be processed by data stream management systems in real-time and not by using the typical store-and-process paradigm. This section thus analyses noSQL solutions for data processing. In addition, since ClouT will provide an event processing mechanism with a publish/subscribe facility, existing solutions on that are also listed in this section. ClouT project also deals with the non-functional issues of the data processing system, such as the fault detection. In fact, the data should be “clean” in order to be properly used by real-time applications. Faulty data should be detected and isolated, and necessary measures should be taken if the faults are frequent. One of the big challenges is that this should be done in real-time on a big quantity of data. Some solutions of online fault detection are presented in this section.
ClouT – 31.07.2013 Page 30
D3.1 - Reusable components and techniques for CPaaS
3.2. Data/event processing and decision making reusable components
In this paragraph are described all the Data/Event processing and decision making reusable component. For each of them it is reported a short description with a link to the correspondent component table in the Appendix.
ESPER
The Esper engine (Inc, 2012) has been developed to address the requirements of applications that analyze and react to events. The Esper engine works a bit like a database turned upside- down. Instead of storing the data and running queries against stored data, the Esper engine allows applications to store queries and run the data through. Response from the Esper engine is real-time when conditions occur that match queries. The execution model is thus continuous rather than only when a query is submitted.
Esper provides two principal methods or mechanisms to process events: event patterns and event stream queries. Event pattern are expression-based event that matches expected sequences of presence or absence of events or combinations of events. It includes time-based correlation of events. Esper event stream addressed event stream analysis requirements of CEP applications. Event stream queries provide the windows, aggregation, joining and analysis functions for use with streams of events. These queries are following the Event Processing Language (EPL) syntax. EPL has been designed for similarity with the SQL query language but differs from SQL in its use of views rather than tables. Views represent the different operations needed to structure data in an event stream and to derive data from an event stream.
Figure 15 shows the event processing principle that Esper follows. First the data we would like to analyze need to be structured in the form of objects before it can be thrown down the pipe to our CEP engine. Esper provides multiple choices for representing an event for example Java object and DOM node. There is no absolute need for you to create new Java classes to represent an event. Then, we need to inform the engine about the kind of objects it will have to handle. Events can then be thrower of the pipe of the CEP engine. The CEP engine will then filter the data it receives, and trigger events whenever that data meets the selection rule, or fulfils the pattern defined in the statement in the form of EPL.
FIGURE 15CEP PRINCIPLE (ANGELO CORSARO)
ClouT – 31.07.2013 Page 31
D3.1 - Reusable components and techniques for CPaaS
ESPER&OSGI
Esper is a server side component and it can be deployed on platforms that perform data gathering and processing. It is possible to deploy Esper in terms of a bundle into an OSGi gateway. The Figure 2-8 shows a possible integration of Esper to OSGi.
FIGURE 16ESPER INTEGRATION TO OSGI
An integration of Esper into OSGi has been developed by the FI-WARE project. Next section briefly presents that component.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 32
D3.1 - Reusable components and techniques for CPaaS
FI-WARE GATEWAY DATA HANDLING
FI-Ware Gateway data handling (Fiware Data Handeling) is a complex event processing component proposed by Orange Labs France. It is based on Esper4FastData CEP engine. It is able to collect vast amounts of asynchronous events of different types and correlate them into single events, called Complex Events. It can read from and write to numerous different channels using various different protocols. It is driven using a domain specific language called “Dolce”.
The Gateway Data Handling GE of the Figure 17 is also the first stage of intelligence transforming data into events using smart rules. Applications are now able to collect in real-time large amounts of data, but only relevant data avoiding boring and asynchronous data analysis. You will not manage only raw data but also define some local rules to add value on raw data and send only relevant events when a typical situation happens. You will also be able to add and change the rules.
FIGURE 17DATA HANDLING GE ARCHITECTURE
The Data Handling API is NGSI compliant. It accepts events from any NGSI compliant Event Producer. In the IoT Service Enablement architecture, the Gateway Device Management GE publishes device events and data towards the Data Handling GE. In this setup, the Gateway Device Management GE registers itself as an NGSI context provider, by calling the NGSI-9 register Context method exposed by the Data Handling GE. After context registration, the Gateway Device Management GE sends events by calling the NGSI-10 update Context method of the Data Handling GE.
Data Handling GE implementation allows rules building by graphically wiring blocks together. The resulting diagram is then converted into EPL syntax, which is the CEP rule language. The
ClouT – 31.07.2013 Page 33
D3.1 - Reusable components and techniques for CPaaS Graphical rules editor is optional, but useful to manage CEP rules, in a user-friendly environment.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 34
D3.1 - Reusable components and techniques for CPaaS
JBOSS DROOLS EXPERT
Drools Expert is a declarative, rule based, coding environment. This allows you to focus on "what it is you want to do", and not on the "how to do this".
Drools life is a specific type of rule engine called Production Rule System (PRS) and was based around the Rete algorithm (usually pronounced as two syllables, e.g., REH-te or RAY-tay). The Rete algorithm, developed by Charles Forgy in 1974, forms the brain of a Production Rule System and is able to scale to a large number of rules and facts. A Production Rule is a two-part structure: the engine matches facts and data against Production Rules - also called Productions or just Rules - to infer conclusions which result in actions. The process of matching the new or existing facts against Production Rules is called pattern matching. The figure below shows the high-level architecture of production system. when
FIGURE 18HIGH-LEVEL PRODUCTION RULE SYSTEM
The following is a simple "reactive" monitoring example that sends a message every four hours when the alarm is raised. The calendar attribute ensures the rule only executes on weekdays. Monitoring examples like this would be a long running application. rule "Weekday Alarm Response" timer(int 4h) calendar "weekday" when a : Alarm( ) then sendMessage( "There is an alert" + a); end
An interesting fact is that Drools can be integrated to jbpm. The drools camel server (drools- camel-server) (Drools-Camel Server) module is a war (Web application Archive) file which you can deploy to execute Knowledge Bases remotely for any sort of client application. This is not limited to JVM application clients, but any technology that can use HTTP, through a REST interface. This version of the execution server supports stateless and state full sessions in a native way.
ClouT – 31.07.2013 Page 35
D3.1 - Reusable components and techniques for CPaaS For further information please refer to the table in the appendix.
MONGODB
MongoDB (MongoDB) (from "humongous") is an open-source document database, leading of NoSQL databases. Data in MongoDB has a flexible schema. Collections do not enforce document structure, although you may be able to use different structures for a single data set. In MongoDB, different data models may have significant impacts on application performance.
MongoDB (MongoDB Overview) is open-source. It features: document data model with dynamic schemas, full and flexible index support, auto-Sharding for horizontal scalability, built-in replication for high availability, text search, rich queries and advanced security.
Instead of storing data in rows and columns as one would with a relational database, MongoDB stores a binary form of JSON documents (BSON). Relational databases impose flat, rigid schemas across many tables. By contrast, MongoDB is an agile NoSQL database that allows schemas to vary across documents and to change quickly as applications evolve, while still providing the functionality developers expect from relational databases, such as secondary indexes, a full query language and strong consistency.
In addition, MongoDB is built for scalability, performance and high availability. Auto-sharding allows MongoDB to scale from single server deployments to large, complex multi-data center architectures. Leveraging native caching and RAM, MongoDB provides high performance for both reads and writes. Built-in replication with automated failover enables enterprise-grade reliability and operational flexibility. MongoDB also provides native, idiomatic drivers for all popular programming languages and frameworks to make the development natural.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 36
D3.1 - Reusable components and techniques for CPaaS
3.3. Self-healing for data/event streaming reusable components
In this paragraph are listed the Self-healing for data/event streaming reusable components. For each of them it is reported a shot description and a link to the correspondent component table in the Appendix.
SELF-HEALING FRAMEWORK FOR SENSORY DATA
This framework provides runtime detection, classification, and correction capabilities for sensory data faults that appear in sensory data. It includes a fault classification model and a model-learning component based on statistical pattern matching.
FIGURE 19 SELF-HEALING FRAMEWORK FOR SENSORY DATA
Figure 19 illustrates overview of the framework. This framework addresses a full cycle of self- healing mechanism, which includes detection, diagnosis, resiliency mechanisms and fault models.
Detection phase is self-explanatory, and neighborhood vote with the statistical analysis of data is sufficient for successful detection. Classification is a part of the diagnosis. It relies on the duration and the impact faults have on the data behavior. To complete the classification, we have a phase of fault model learning. Models are later applied to correct readings from the respective faulty nodes. Each of these phases can be implemented with a different set of applicable algorithms.
ClouT – 31.07.2013 Page 37
D3.1 - Reusable components and techniques for CPaaS In the absence of ground truth, data modeling is vital. A good set of models enables grouping data into good or faulty, including the type of fault. The challenge here is to define the distinction between faulty behavior and an outlier of a new event. If the expected range of readings is known, a reading that falls out of that range is not necessarily faulty, but it might indicate the occurrence of a new event. We focus on the case where this knowledge is not available and propose model learning from the past behavior of the network. Expectations of correct behavior are established based on collected readings over the initial phase of operation. In this way, the network is not bound by a-priori assumptions and has the freedom to establish what ground truth is. Network learns a model of fault for each faulty node and can apply that model for the fault correction.
Both modeling and classification rely on data features, which are usually statistical in nature. Since the fault can belong only to a limited number of proposed classes, statistical pattern recognition to learn an appropriate model of the fault is suitable. This model is then applied to correct the readings of a respective node.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 38
D3.1 - Reusable components and techniques for CPaaS
FAULT CLASSIFICATION MODEL
This model provides a decision tree to classify data faults into four types: bias fault, drift fault, malfunction fault and random fault. Applied to sensory readings, this model proposes a complete and consistent classification based on frequency and the continuity of occurrence and observable and learnable patterns.
FIGURE 20 - FAULT CLASSIFICATION MODEL
Figure 20 illustrates this classification. From here we can define types of faults. If a sensor reading is represented with ri + εi , where ri is a true value of a measured phenomena and εi is a fault, we can define fault classification as follows:
• Discontinuous - Fault occurs from time to time, occurrence of εi is discrete.
– Malfunction – Frequent occurrence of faulty readings, εi> τ, where τ is threshold frequency. Also, there is no observable pattern in the fault occurrences.
– Random – Infrequent occurrence of faulty readings, εi≤τ.
•Continuous - After the certain point in time, a sensor returns constantly inaccurate readings, and it is possible to observe a pattern in the form of a function:
εi = f(t,[α1,α2....])
where αi are coefficients of the function and t is time.
– Bias - The function of the error is a constant, εi = const. This can be a positive or a negative offset.
– Drift - The deviation of data follows a learnable function, such as polynomial change