The Elis Platform: Enabling Mobile Services for Energy Efficiency in Existing Buildings
Today, most buildings have technology that controls ventilation, heating and other systems that make a building energy efficient and comfortable to live in. Buildings, just like modern cars, are controlled by computer systems that ensure that all technical devices work together with the same goals. Many buildings older than five-ten years have not just one but several systems, and these systems have previously been hard to integrate so that they collaborate with each other as one ecosystem. For instance, lighting is commonly separate from heating systems as well as alarm systems, which makes it hard to use smart reasoning such as ‘a window is open in this room, so turning off the heat is a good idea’ and ‘as the lights are being turned off and it is dark outside, the person leaving the room should be reminded that the window is still left open’. The Elis platform has been developed to allow existing building systems to be connected with each other, which makes smarter building services simpler to create. Through the Elis platform, existing technologies and systems already used individually may be integrated into one system, thereby forming an ecosystem that may exchange information through the Elis platform. This integration could be between several buildings also, as the platform does not have to run locally. While the platform is first and foremost intended for energy efficiency, not just ventilation or heating, but also home entertainment systems or automated pet-feeding devices could be integrated. Through a single (and open source) API, the Elis platform allows services to be developed that build upon what all your systems and devices control. The Elis platform connects to existing systems and devices through so-called adapters. These adapters are needed to connect systems, and essentially translate the system-specific behavior to the Elis platform, which together with the system services then are made available to services through one single API. The API is where you access data on which you then build services or apps. A system owner is primarily interested in the API and the adapters, while a platform developer is also interested in the architecture of the Elis platform, which is built according to the Internet of Things Reference Architecture (IoT–A). Without the Elis platform, development of smart services would have to use different APIs for each system and device that the service would want to interact with.
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
The Elis Platform: Enabling Mobile Services for Energy Efficiency in Existing Buildings
- 1. HOW TO BUILD AN OPEN PLATFORM FOR SMART BUILDINGS ULRIK EKLUND 2015
- 2. IoT research has focused on technological infrastructure But in order to develop successful products and services, the perspective of the users must be integrated We are about 25 researchers from Computer Science and Interaction Design at MAH focusing on: Interaction technology Embedded intelligence User-centered development
- 3. ELIS PROJECT Funded by Vinnova: Utmaningsdriven Innovation and the collaborating partners
- 5. PROBLEM A lot of talk about smart buildings! Why don’t we see more of this already? • Vertically integrated systems • No 3rd party services • Contract form of construction • Cost of infrastructure – fixed installations – Sensors, control systems, wiring, cost of work, etc.
- 6. CHALLENGES ADDRESSED Energy waste in buildings – Use IoT technology – develop ecosystem of services (apps) Existing buildings – use retro-fit technology – reuse of existing hardware and infrastructure
- 7. CHALLENGES ADDRESSED Technological “lock-in” – interoperability – provide open API:s Usability – mobile devices as user-interfaces – user-centered development (Living labs)
- 8. THE ELIS APPROACH Integration of existing systems Open platform Minimal subsequent installations Can mobile services minimize the need of infrastructure? – Indoor positioning? – Mobile phone sensors?
- 9. CONSORTIUM
- 10. ELIS PROJECT GOALS Open platform for mobile energy efficiency services – Enabling 3rd-party developers to provide mobile services A set of mobile services evaluated at two types of test sites: – Apartment buildings – Schools
- 11. ELIS PROJECT GOALS Business models and value-creation mechanisms – Create win-win-win for all parties in the user-supplier-provider chain Knowledge development – Lessons learned – Identification of future challenges
- 12. EXAMPLE SERVICE: ELIS MOBILE (FOR APARTMENTS) Shows energy and water consumption for a specific user’s apartment Lists and shows devices in an apartment Allows the user to answer questions about the app, their consumption and also provide general feedback
- 13. ANOTHER SERVICE: IF THIS THEN THAT
- 14. DELIVERABLES APIs – REST-based API for 3rd-party developers – Internal Java-based API for platform developers Platform reference implementation – https://github.com/iotap-center/elis- platform Mobile service prototypes (e.g. Crowdis)
- 15. MORE DELIVERABLES Documentation – Platform deployment instructions – Code & design documentation – Platform development documentation – API documentation Security roadmap Proposed future work Lessons learned
- 16. PLATFORM ARCHITECTURE Design decisions driving the platform architecture
- 17. ARCHITECTURE QUALITIES Openness: Easy to develop new applications utilising the API Interoperability/integrability: The platform shall not be dependent on services or devices supplied by a certain organisation Modifiability: It shall be easy to extend the platform over time with new services – those provided by different vendors, and – those services available through the API
- 18. ARCHITECTURE QUALITIES Security: Certain services shall only be allowed to authenticated users – services shall be possible to restrict Cost, in particular: – Infrastructure, things for making stuff happen; servers, gateways, physical devices, etc. – Application service development cost – Operation costs for running a system Availability: The uptime of platform services shall be maximised
- 19. ARCHITECTURE QUALITIES • Usability for the end-user is the responsibility of the applications service developers – The platform should support abstractions relevant for the end-user to be used by developers • Performance: A service provided by the platform shall respond sufficiently fast • Scalability: The number of devices a platform can manage shall not be limited by the software implementation of the platform
- 20. DESIGN RATIONALE Simplicity and interoperability of the public API are prioritised Public API conforms to REST – Accepting that not all proprietary services can be implemented or be made available to 3rd -party developers
- 22. DESIGN RATIONALE Modifiability, scalability and cost for infrastructure are prioritised OSGi as the framework for implementing the platform – Accepting translation of device and vendor services to and from Java within the platform
- 23. LOGICAL VIEW
- 24. DEPLOYMENT CONFIGURATION Showing how various running software interacts
- 26. 1ST EXAMPLE OF PHYSICAL IMPLEMENTATION Deployment where the Elis platform runs on a separate cloud server Typical implemen- tation when proto- typing
- 27. 2ND EXAMPLE OF PHYSICAL IMPLEMENTATION Deployment where both the vendor services and the Elis platform runs on a local server within the building system
- 28. SERVICES WITHIN THE ELIS PLATFORM
- 29. DEVELOPMENT OF THE ELIS PLATFORM Agility in practice
- 30. WAYS-OF-WORKING Architecture Platform Prototype 4 week cycle One page architecture Internet of things architectu Service oriented architectur OSGi Java OpenAPI Rapid prototyping Mock-ups Living labs
- 31. SOME EXPERIENCES The devil is in the details No standards for designing devices
- 32. SOME EXPERIENCES Hard to find the killer app Vision changes during a long project, both • what services should be offered, • the technical infrastructure
Editor's Notes
- Interaction technology: How do users interact with the connected devices? User-centered development: How can users be involved in the development of new IoT services and products? Embedded intelligence: How can intelligence, e.g. integrated in the devices, improve the usability and functionality of IoT services and products?
- Part of the pilot for Green Digital City Sweden’s leading environmental city
- The HTTP API used between the user and the service conforms to REST principles level 2 on the REST maturity model (REST Maturity Levels, http://martinfowler.com/articles/richardsonMaturityModel.html)
- http://www.osgi.org/ http://www.iot-a.eu/public
- The key aspect for 3rd party developers is the consistency of the open API (the red line) over different systems (buildings, schools, etc), enabled by the Platform API adapter layer. The key aspect for developing the Elis platform is the Infrastructure adapter layer. A third adapter, Web service adapter, allows platforms services access to web services outside the system These adapter layers, and the services between them in the platform are developed within the OSGi framework, which supports modifiability, scalability and independence of the hardware on which the platform runs on top of.
- the unequivocal deployment between the logical elements and how they are deployed to running software. The platform services are shown as being deployed to “a cloud” indicating the hardware independence of where it is executed.
- In the building there are a number electrical devices connected (e.g., via “smart-plugs”) to a “local unit” that consist of a communication function (i.e., gateway) and possibly a local server with processing and storage capabilities. The gateway enables IP-based communication with external units. The local server may include intelligence useful for implementing energy management services. This intelligence (and the data storage) could also reside in a remote cloud server. The users interface the system via a personal computer or a mobile device (e.g., a smartphone or a tablet computer), which then communicates either with the cloud server or the communication gateway in the building. The intelligence and data storage may also reside in the PC or mobile device.
- There are at least three different ways the deployment configuration elements are allocate to a physical system, with the main difference how the vendor and platform services are deployed, either locally to the building/home or deployed to a cloud server.
- The Elis platform and its underlying services can be represented in a model of successive “shells” encompassing each other (see image). These shells represent two things: Stages in how the system is built, i.e. each shell (including those inside) can be a standalone system not depending on the outer shells. Core Services Shell The current services in the “Core Services” layer represent the lowest level of the Elis platform, that is the services and packages that are required to instantiate the platform. Publisher/Consumer Shell Outside the “Core Services Shell” is the “Publisher / Consumer Shell” shell. This shell is divided into two areas: the top half called the publisher shell, publishes functionality in the platform through an API. The lower half, the consumer shell, consumes services from Building Management Systems (BMS) and repurposes that in another API. Analytics & Automation Shell Outside the “Publisher / Consumer” is the “Analytics & Automation Shell”. This shell contains services that both utilizes and modifies existing data, but also receives new data from external sources.