iot smart buildings challenge - iiconsortium.orgthe customer can use the data about the energy and...
TRANSCRIPT
Evaluation Criteria
Community Contribution
How well have the contributors supported the challenge events reflected
in the timeline?
TechnologyHow well does the proposal describe how it will ensure
scalability and realistic rollout in an enterprise environment? Proof of concepts will be given bonus consideration.
BusinessHow well does the proposal
support the outlined use cases, provide value-add for
the partners and deliver innovation?
For participation in the 17 September Workshop, the entry deadline is 6 September 2019
The submitted proposals will be evaluated according to the following criteria:
Challenge SubmissionPlease use the following slides to make your submission to the challenge
Use this PowerPoint template to submit your proposed concept for the challenge.
NOTE: This template is used multiple times over the course of the Challenge. The first use is to submit your preliminary entry where the target use case must be identified. The first submission should reflect a reasonable assessment of the problem and your solution. As the Challenge progresses, there will be additional, announced, opportunities to offer updated submissions, with the final submission of your solution due on February 1, 2020.
Fill out each slide from the following, using the appendix for additional material.
Optional (and not expected with initial entry):
▪ Video• Highly recommended• Should provide insights into the work you did for the challenge (not simply product advertisement)• Please attach or embed this into this PPT
▪ Code / PoC (proof of concept) Results• Optional, but highly desirable• Include high-level overview in PPT, with link to your repo
About Your Company OR Challenge Team - REQUIRED
Please submit on this slide:
• Company name(s): MOECO smart Metering Solution ( MOECO Power Meter & MOECO Water Management Solution)
• Submitter name(s) and e-mail addresses: Alexa Lopez- [email protected]
• Identify who agreed to the Contestant Agreement, if different from this submitter• Link(s) to company home page(s): www.moeco.io
• Who is representing which part of this submission (if it is a joint submission): MOECO IOT LLC
Use Case(s) Addressed - REQUIRED
• Describe how your solution addresses one or more of the Smart Buildings Challenge use cases –(1) Smart Space Flow Analytics (2) Smart Metering in Multi-Tenant Commercial Buildings (3) Smart Automated Building or (4) Smart Building Cockpit.
• One Use Case per Submission. Multiple submissions welcome.Based on the core of MOECO IoT Connectivity Solution we have created MOECO Power Meter and MOECO Water Management Solution to address the second use case of the Smart Buildings Challenge- Smart Metering in Multi-Tenant Commercial Buildings.
With the help of our proprietary non invasive smart sensors we can: ● Measure electricity consumption for various tenants within the building or commercial facility● Analyze water consumption on a detailed levelWe use MOECO Connectivity Solution as the existing infrastructure for these Solutions.Based on the data we collect from the sensors, we can analyze energy and waterconsumption and detect anomalies and provide suggestion for optimization of the infrastructure.
Contributions to the Smart Buildings Challenge
Please describe the contributions your team has made to building the smart buildings community, e.g. by participating in challenge-related hackathons, attending or organizing challenge-related workshops, promoting the challenge actively via social media or presentations, helping to advance the TIOTA framework, helping to advance the IIC reference architecture, etc.
- Our company is a part of Trusted IoT Alliance and we are participating in most of the meetings, discussions, bringing our experience and expertise in DLT-centric solutions with IoT, helping to advance the TIOTA framework and partnerships
- We are constantly sharing the news of TIOTA in MOECO’s social media profiles and would be happy to promote the challenge actively right after the application
- Our founder is an active speaker at various conferences related to smart cities building sharing his knowledge and use cases for the benefits of IoT for smart construction and maintenance
Solution Design: Business Perspective - REQUIRED
Describe your proposed solution from a business/end-user perspective (e.g., how would the solution - when fully deployed - create value for participants in the ecosystem including owners, operators and tenants of industrial buildings.
● Energy and water saving solutions are one of the most well-established IoT applications. Energy and water management systems rely on smart meters, which collect the information about energy usage and provide the information back to central management system in order to efficiently allocate resources. This data also can be used to identify and address outages. Our sensor can:
● Measure alternative current in a wire
● Support different wire thickness
● Use BLE or LoRa for data transfer
● 6+ months of battery life
Solution Design: GTM Perspective
If the go-to-market (GTM) for your solutions involves multiple stakeholder from the challenge ecosystem (e.g. your team, and/or some of the sponsors), please describe:
• The business model which would allow the ecosystem participants to jointly benefit from the solution
- For example: How will we deal with IP which is created in the ecosystems?- Potential legal form and organization: How will the solution be developed, sold and
supported?
MOECO solution as the connectivity solution fully belongs to Moeco IoT Corp, US based company.MOECO’s Power Meter Solution and MOECO Water Management Solution can be brought into the partner’s ecosystem and developed as the solution, sold and supported by the partners of this challenge. Then the ownership of the IP will be discussed with Moeco IoT LLC and those partners separately.
Solution Design: Differentiation
Differentiation -- how would your proposed solution differentiate itself from others in the market?All the energy and water saving solutions on the market could not integrate seamlessly and provide the accurate data directly to the facility owner in order to optimize the energy consumption.
Our sensors are integrated seamlessly into the existing eco-system and collect the accurate data with no effort from the customer’s side.
The customer can use the data about the energy and water consumption of each unit and optimize the existing eco-system in a smart way.
We charge for the data provided directly to the customer in the encrypted manner and this data belongs to the household / business owner.
Solution Design: Architecture
• Moeco architecture is represented in 4 layers
• Sensors and Sensor SDK
• Gateways (for Bluetooth and LoRA) and Gateways SDK
• Masternode (on-premise data server platform)
• Blockchain architecture
Solution Design: Technology
Describe your proposed solution from a technology perspective. In your description, please describe how IoT and/or blockchain/distributed ledger-based technology will be used in your solution.
Optional: Please describe how your description will leverage technologies provided by the Challenge’s Enabling Technology Partners.
Solution Design: Scale
• Scaling up on the technical level: At what scale do you expect the solution to work, e.g. size of property, throughput, transaction times, etc.
• Construction and management companies will be able to seamlessly implement IoT solutions on construction sites or constructed buildings / facilities
• Sensors connected to MOECO can be installed seamlessly. Companies could just place sensors where they need them. There is no need to deploy a network for them. All devices will automatically be connected to the network if they are in the MOECO ledger.
• Scaling up on the business and operational level: How would you ensure this?
• Companies that have successful local cases can scale them worldwide. MOECO is roaming-free and there is no need to up- date device's firmware, so companies won't have additional costs moving to other regions.
• LPWAN and Bluetooth sensors are cost-effective and have long battery life. Placing these sensors within the packages requires no alteration of the delivery process and improves the quality of service simultaneously providing the company with logistics insights.
Potential Issues/Challenges
What issues/challenges might you encounter when creating your solution? Challenges might be related to the underlying technology, integrations, platform development, etc.
- timeline for creating of the sensors might take longer than expected (depending on the facility size and infrastructure number of sensors may vary)- customer interface can be developed according to the customer’s desire, might take longer in
this case (depending on the customer’s needs)
- Integration and data collection will be smooth and seamless, but if customer wants data analysis and predictive maintenance of the facility, it might take more time after the pilot (the system needs to generate enough data and the time to define the repetitive anomalies patters)
- We will need to hire more people in our team to complete this challenge smoothly (more dataanalytics and managers for the current project or projects)
Tentative Timeline
• Provide a tentative pilot timeline:- Key milestone dates- Proposed date when you believe your PoC will be live
- The samples of MOECO’s Power Meters are ready as well as the connectivity solution.- We need to do the following in the month of October:- 1) define the object of the pilot – choose the facility to run the pilot- 2) define the solution tech specs : number of sensors, the platform for the customer- 3) create the legal set up between Moeco IOT LLC and the customer / sponsor - In the month of November we will need to:- 1) produce the defined number of sensors for the chosen facility- 2) create platform (interface for the user of the solution)- 3) set up the agreement about the solution scaling / additional features if desired
Appendix
• Attach any supporting materials to this appendix
Field
Backend
Asset
IoT Cloud
BC Middleware
BC Network ❻❺❹
❸
❷Asset Layer▪ Examples: Truck, Train, Machine▪ Includes local and remote communication and
processing (on asset, fog)▪ Can include local blockchain clients
IoT Cloud Layer▪ Asset connectivity & FOTA▪ Digital Twin, Asset-related data, event management▪ Enterprise Application Integration
▪ Asset-related ledger entries▪ Peer-to-Peer Middleware for management of BCs▪ Network of compute nodes for BC
Blockchain Cloud Layer
WANAp
plic
atio
n Lo
gic
Optional (for DLT-centric solution proposals): Mapping against TIOTA Reference Architecture
Blockchain Cloud
❶
Application Logic▪ Distributed across the different layers, e.g. apps + HMI on the asset; digital twin-
based apps in the IoT Cloud; or smart contracts in the blockchain cloud
Gateway
EnterpriseApplications
(ERP, Legacy, etc)
Field
Backend
Asset
IoT Cloud
BC Middleware
BC Network
WANAp
plic
atio
n Lo
gic
Optional: Architecture Canvas for your Solution Proposal
Blockchain Cloud
Gateway
Please use this slide as a canvas for your solution proposal. This
will help us to compare the different proposals, and to build up a library of re-usable design
patterns.
If you feel there are elements missing of the structure is not
right, please feel free to change it as you see fit.
Optional: Identity and Trusted Lifecycle
Trusted IoT Lifecycle Phases1. Provisioning2. Tracing
- Chain of Custody- Usage Tracing- External Events- Structural Changes
3. Decommissioning
IoT Identity1. Assets2. Users
If applicable: Please explain how your solution is using DLTs etc. to enable identity management for the IoT.How is your solution supporting the trusted IoT lifecycle, in the context of the reference architecture?
Lifecycle
Optional: Key/Certificate Lifecycle Management
If applicable: Please explain how your solution is supporting the lifecycle management of keys in a distributed environment (again, using the TIOTA reference architecture)
Key/Certificate Lifecycle Management
▪ Secure generation of keys and certificates ▪ Root of Trust: Keys and certificates
injection at chip wafer level▪ Tamper resistance to ensure protection of
keys in the supply chain and in the field (e.g. via TPM)
▪ Secure key management and forward security: key negotiation, key wrapping, key regeneration, …
IIC 3-Tier IIoT System Architecture
The edge tier collects data from the edge nodes, using the proximity network. The architectural characteristics of this tier, including the breadth of distribution, location, governance scope and the nature of the proximity network, vary depending on the specific use cases.
The platform tier receives, processes and forwards control commands from the enterprise tier to the edge tier. It consolidates processes and analyzes data flows from the edge tier and other tiers. It provides management functions for devices and assets. It also offers non-domain specific services such as data query and analytics.
The enterprise tier implements domain-specific applications, decision support systems and provides interfaces to end-users including operation specialists. The enterprise tier receives data flows from the edge and platform tier. It also issues control commands to the platform tier and edge tier.
The proximity network connects the sensors, actuators, devices, control systems and assets, collectively called edge nodes. It typically connects these edge nodes, as one or more clusters related to a gateway that bridges to other networks.
The access network enables connectivity for data and control flows between the edge and the platform tiers. For example, it could be a corporate network, an overlay private network over the public Internet or a 4G/5G network.
Service network enables connectivity between the services in the platform tier and the enterprise tier, and the services within each tier. It may be an overlay private network over the public Internet or the Internet itself, allowing the enterprise grade of security between end-users and various services.
Mapping Between a Three-tier Architecture to the Functional Domains
IIC Gateway-Mediated Edge Connectivity and Management Pattern
The local network may use different topologies as described below:
In a hub-and-spoke topology, an edge gateway acts as a hub for connecting a cluster of edge nodes to each other and to a wide area network. It has a direct connection to each edge entity in the cluster allowing in-flow data from the edge nodes, and out-flow control commands to the edge nodes.
In a mesh network (or peer-to-peer) topology, an edge gateway also acts as a hub for connecting a cluster of edge nodes to a wide area network. In this topology, however, some of the edge nodes have routing capability. As result, the routing paths from an edge node to another and to the edge gateway vary and may change dynamically. This topology is best suited to provide broad area coverage for low-power and low-data rate applications on resource-constrained devices that are geographically distributed.
In both topologies, the edge nodes are not directly accessible from the wide area network. The edge gateway acts as the single entry point to the edge nodes and as management point providing routing and address translation.
The edge gateway supports the following capabilities:
• Local connectivity through wired serial buses and short-range wireless networks. New communication technologies and protocols are emerging in new deployments.
• Network and protocol bridging supporting various data transfer modes between the edge nodes and the wide area network: asynchronous, streaming, event-based and store-and-forward.
• Local data processing including aggregation, transformation, filtering, consolidation and analytics.
• Device and asset control and management point that manages the edge nodes locally and acts an agent enabling remote management of the edge nodes via the wide area network.
• Site-specific decision and application logic that are performed within the local scope.
IIC Layered Databus Architecture
This architecture provides low-latency, secure, peer-to-peer data communications across logical layers of the system. It is most useful for systems that must manage direct interactions between applications in the field, such as control, local monitoring and edge analytics.
Smart machines use databuses for local control, automation and real-time analytics. Higher-level systems use another databus for supervisory control and monitoring. Federating these systems into a “system of systems” enables complex, Internet-scale, potentially-cloud-based, control, monitoring and analytic applications.
A databus is a logical connected space that implements a set of common schema and communicates using those set of schema between endpoints. Each layer of the databus therefore implements a common data model, allowing interoperable communications between endpoints at that layer.
A Three-layer Databus Architecture
Join Us Now!
• Submit your application before September 6, 2019 to participate in the 17 September workshop.
• Fill in the Submission PPT Template and email it to:
Kathy [email protected]
orEvan Birkhead