CSE-E4675 Systems of Systems Lecture 5

Transcription

1 CSE-E4675 Systems of Systems Lecture 5 Kary Främling Professor, Computer Science (Building Information Management)

2 What do we need to implement? 2

3 Libelium Smart World examples 3

4 Smart City: biotope use cases biotope: Building an IoT OPen innovation Ecosystem for connected smart objects H2020 project, ICT-30 4 Internet of Things and Platforms for Connected Smart Objects, started January 2016

5 Example: Car arriving in town Find parking place close to I m driving in street xxx, location yyy Street temperature is Just drove into hole in the street! Need to charge my EV battery, N kwh ESP system activated, slippery!! Parking/ EV charging place reserved Hole in road 100 meters ahead! Slippery 100 meters ahead! 5 School class crossing street in 5 minutes, change route!

6 Requirements to keep in mind O-MI/ O-DF S. Tai, and I. Rouvellou, Strategies for integrating messaging and distributed object transactions in IFIP/ACM International Conference on Distributed systems platforms,

7 Our list of requirements for IoT interoperability FRÄMLING, Kary, KUBLER, Sylvain, BUDA, Andrea. Universal Messaging Standards for the IoT from a Lifecycle Management Perspective. IEEE Internet of Things, Vol. 1, Issue 4, pp Possible to implement for any kind of instances as independently of the application domain as possible Possible to implement for any kind of information systems, including embedded and mobile systems Support for synchronous messaging such as immediate read and write operations, including clientpoll subscriptions Not restricted to one communication protocol only, it must be possible to send messages using protocols such as plain HTTP, SOAP, SMTP, as file copies, etc. Possibility to create ad hoc, loosely-coupled, time-limited information flows on the fly Peer-to-peer communication possibility for all devices, i.e. client and server functionality can be implemented for any device, depending on available processing power, network connectivity, etc. Handling mobility and intermittent network connectivity, i.e. support for asynchronous messaging capabilities that imply for instance message persistence, time-to-live, etc. Context-dependent discovery of instances, instance-related services and meta-data about them Support for context- and domain-specific ontologies Queries by regular expressions for retrieving information about more than one instance and more than one kind of information Historical queries, i.e. retrieving values between two points in time 7

8 Examples of IoT platforms 8

9 OpenIoT General Vision OpenIoT providing a cloud-based middleware infrastructure in order to deliver on-demand access to IoT services, which could be formulated over multiple infrastructure providers. (such as smart cities and smart enterprises) OpenIoT User (Citizen, Corporate) Step 1: Sensing-as-a-Service Request Step 3: Service Provisioning (Utility Metrics) Knowledge-Based Future Internet Step 2: Sensor/Cloud Formulation Domain #1 Domain #N Infrastructure s provider(s) (e.g., Smart City)

10 Overview of (Supported) OpenIoT Capabilities What can I do with OpenIoT? Dynamic Sensor/ICO Discovery Visual IoT Service Definition & Deployment IoT Service Visualization (via Mashups) Sensor/ICO Deployment & Registration IoT Platform Architecture & Capabilities Resource Management and Optimization

11 ICO Integration, Deployment and Registration OpenIoT can be integrated virtually with any ICO through X-GSN Support for both physical sensors (e.g., cameras, microphones, temp etc.) and virtual sensors (e.g., algorithm, twitter streams) If a low level is available the process involves editing a simple metadata file Implementation of drivers for not supported sensors is a matter of 1-2 man days effort Deployed ICOs publish their data according to OpenIoT (W3 SSN) ontology via LSM

12 Dynamic Sensors/ICOs Discovery Dynamic ICOs and Sensors Look-up Takes place through the Scheduler Discovery Citeria including ICO/sensor type and location The Discoverer component (LSM) is deployed in the cloud SPARQL is used for accessing both sensor data and meta-data (dynamically)

13 Visual IoT Service Definition OpenIoT provides the means for dynamically selecting sensors/icos and synthesizing their data into services The «Request Presentation» visual tool (part of OpenIoT IDE) provides zeroprogramming interfaces The tool enables validation and deployment of the service Select Sensors/ICOs Filter & Combine Sensors/ICOs Select Sinks for Visualization/Presentation Validate & Deploy on OpenIoT middleware

14 IoT Service Visualization OpenIoT provides ready-touse mashup components (mashup library) Mashups are specified as part of IoT service specification/generation Integrators can override the mashups with their preferred presentation components

15 OpenIoT Services Control Design Principle 1. Module Monitoring & Management 2. Sensor Configuration and Deployment 3. Publish Available Sensors 4. Sensor Types Discovery 5. Service Definition 6. Service Registration 7. Indirect Sensor Activation 8. Data Production 9. Data Retrieval of Registered Service 10. Data Visualization 11. User Subscription 12. Sensor Activation 13. Real Time Data Streaming 14. Real Time Data Filtering 15. Real Time Data Presentation 16. Mobile Sensor Data Adaptation 17. Mobile Sensor Data Exchange

16 OpenHAB openhab.org 16

17 OpenHAB - Summary See: For integrated control of building automation devices Mainly for small houses, apartments Uses similar Event Bus as DIALOG Usually installed and run on Raspberry PI Not really support for distributed, multi-node installations Can be implemented using O-MI/O-DF, also using DIALOG connectivity 17

18 IoT platforms: DIALOG (Distributed information architectures for collaborative logistics) 18

19 DIALOG Distributed information architectures for collaborative logistics First version in 2001 claims that it was first IoT implementation in the world Written in Java Peer-to-peer philosophy All processing performed by agents Used in numerous applications, domains over the years Architecture still very up-to-date and appropriate for IoT platforms 19

20 DIALOG External interoperability Communication over message bus GUI container Default DB User interface Permanent storage 20

21 Tracking with Manufacturer Set Transp.comp. A ID@URI Transp.comp. B Transp.comp. C Destination ID@URI ID@URI ID@URI Location updates Manufacturer s tracking agent at URI Industrial pilots performed 2002, 2003 in multi-organisational and international context

22 Accessing product information with Electrical motor, manufactured by XXX, previous maintenance... Fetch information (text or WWW-page) URI_1 Fetch information (text or WWW-page) URI_2 Pizza containing..., last date of use..., heat one minute at 600W Fetch information (text or WWW-page) Bus stop XXX, next bus to your destination arrives in three minutes URI_3

23 Use Cases implemented at TKK Service company node (web application server with Dialog) Residential gateway node, running Dialog O-MI/O-DF messages: sensor readings periodic statistics alarms Smart fridge and Smart Adapter by Indesit Car diagnostics and sensor readings with OBD-II Other data Consumers (e.g. manufacturer)... Light-weight O-MI/O-DF node

24 Hardware for connecting to car s Engine Control Unit (ECU) Sufficiently new car with On-Board Diagnostics OBD-II capability OBD-II to RS-232 converter Plugs: OBD-II (below), RS-232 (above)

25 Car demonstration with OBD-II and UPnP/CorePAC

26 Accessing car Engine Control Unit over Bluetooth Bluetooth connection established Check Engine status and Diagnostic Trouble Codes fetched Standard Bluetooth module for wireless connectivity All information can be sent to remote nodes over O-MI / O-DF Subscriptions for more information could be sent to the mobile phone if needed

27 Vehicle Fleet Management Logging Service Provider(s) Data acquisition system(s) Vehicle O-MI & O-DF Other organizations Leasing/Service company End-user Company: Airport operator Finnish Post Current system Pilots implemented for Helsinki airport and former Finnish Post Objectives: Condition-based maintenance Fleet-level optimization Driver behavior analysis and feedback Reduced idling, promoting green values Reducing Total Cost of Ownership All products are mobile Mobile data transfer using proprietary protocols All other data transfer by O-MI & O-DF In the future Objectives: All-covering Fleet management based on collected information and optimization of different functions Many different organizations/users need different data from different devices Standard protocol needed! O-MI & O-DF do the job 27

28 Remote monitoring of vehicles: airport 28

29 Intelligent refrigerator

30 ENSTIB campus installation (Épinal, France)

31 Example of subscription created by the site manager, whose notifications must be sent to the BIM server

32 Initial results from ENSTIB Classroom was empty 83% of the experimental period (4 month experiment), while the temperature was maintained most of the time (8000 occurrences on a 5min basis) at 21 C. Substantial energy saving can be reached by controlling and sensibly reducing the temperature, e.g. by accessing the student timetable, the HVAC system can automatically adjust the indoor Temperature, or even proposing alternatives to the teacher (e.g., to ask a teacher to go in classroom B instead of A, initially scheduled, because B is free and at the right temperature, while A is not - need to warm up A).

33 O-MI / O-DF reference implementation 33

34 Reference Implementation Currently running at Published as Open Source Plan: disseminate through iot.eclipse.org Implements: URL-based discovery and read operations Web GUI for more advanced operations Source Code in Github : Implementations in several languages exist Data publication and acquisition for instance with simple Unix Shell Script 34

35 IoT CRUD 4. No O-MI delete yet 4. Remove system or parts of it Delete with O-MI and O-DF Create 1. New system appears 1. Publish with O-MI write Read 2. Read/subscribe to data, information, events, 2. O-MI read/ subscription 3. Update with O-MI write Update 3. Write data, information, events, 35

36 Smart House revisited in detail Local power production Manufacturers, maintenance and service companies, electricity providers,... Integrated control, Internet gateway Data acquisition, visualisation, analysis, control, etc. (server/cloud) Power monitoring House owner, inhabitants Ventilation, refrigerators,... Weather station Smart Grid Energy prices, forecasts, control commands etc. 1. Asemo internals (seecc+ webkeruudlogsender) 2. Temperature & humidity sensors 3. Enervent Pandion 36

37 Access Control Lists List of permissions attached to an object. Specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. *source: 38

38 Unix File System Permissions *source: 39

39 Idea for the security model Apply ACL and Unix FS Permissions principles to security module design considering differences: Only group related rights Only read and write operations (no execute) Using that ideology it s easy to store permissions for objects in DB. We can also store only necessary permissions. 40

40 Management UI 44

41 Management UI 45

42 Management UI 46

43 Management UI Basic CRUD (Create, Read, Update, Delete) operations for rules and groups. Supports recursive permissions Access to Management UI is restricted to Administrators only. The list of administrators is filled manually. The list is stored outside the webserver, so it can t be accessed by third party person (if the target server is properly configured in terms of remote access security) 47

44 HTTPS and SSL extension 48

45 Security challenges Reference implementation uses SSL with Client authentication Same certificate in all my (Kary s) devices Certificate management a challenge Access control currently read/write for O-DF Objects/InfoItems A O-MI node B O-MI node 49

46 ControlThings model: Mist 50

47 IoT today: many ecosystems Weak interoperability between ecosystems Data silos Proprietary APIs and Payload semantics Different interfaces for devices/machines and larger information systems Requires almost infinite amount of adapters plug-ins drivers

48 Add more connectivity using Mist = connections in any direction B Mist A Mist A network that binds systems together

49 Public open IoT standards B Mist A Mist Open Data Format (O-DF) Open Messaging Interface (O-MI)

50 Remote Mist systems System representation System model = technical representation of the underlying system Generic UI

51 Remote Mist systems Branded UI

52 Remote Mist systems Dashboard Collects the relevant info into a personalized set of widgets

53 Remote Mist systems Use case apps Tailored for accomplishing particular tasks.

54 Where Mist comes in Ecosystem C apps Smart Grid apps Smart Mobility apps Ecosystem A apps Ecosystem B apps Domain specific semantics (Ecosystem C) Smart Grid protocol IP networking Smart Mobility protocol IP networking Ecosystem A protocol IP networking Ecosystem B protocol IP networking Generic IoT layer Authentication using crypto identities Authorization (ACL) Addressing (p2p) System model IP networking

55 Mist demo setup Air quality sensor ESP8266 Relay ESP8266 Logger Mist UI Program logic node if( CO 2 > 900 ) { boost=true } else { boost=false }

56 Course conclusion and final instructions 60

57 Examination & Project Examination requirements (all found from Materials page of MyCourses page): 1. Lecture slides. 2. Tiwana, Platform Ecosystems. Only pages: How Smart, Connected Products Are Transforming Competition, by Michael E. Porter and James E. Heppelmann, Harvard Business Review, November MEYER, Gerben, FRÄMLING, Kary, HOLMSTRÖM, Jan. Intelligent Products: A survey. Computers in Industry, Volume 60, Issue 3 April pp FRÄMLING, Kary, HOLMSTRÖM, Jan, LOUKKOLA, Juha, NYMAN, Jan, KAUSTELL, André. Sustainable PLM through Intelligent Products. Engineering Applications of Artificial Intelligence, Volume 26, pp FRÄMLING, Kary, KUBLER, Sylvain, BUDA, Andrea. Universal Messaging Standards for the IoT from a Lifecycle Management Perspective. IEEE Internet of Things, Vol. 1, Issue 4, pp Systems Engineering Guide, MITRE, Only pages: Project work deadline: May 31st Re-examination possibilities on 6th September 2016 and 13th December 2016 Good Luck! 61