IoT Smart Buildings Challenge

1. IoT Smart Buildings Challenge Contacts: Kathy Walsh walsh@iiconsortium.org Evan Birkhead evan@trusted-iot.org July 23, 2019

2. Evaluation Criteria The submitted proposals will be evaluated according to the following criteria: Business How well does the proposal support the outlined use cases, provide value-add for the partners and deliver innovation? Technology How 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. Community Contribution How well have the contributors supported the challenge events reflected in the timeline? Submission deadline: August 30, 2019

3. 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. Fill out each slide from the following, using the appendix for additional material. Optional: • 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

4. About Your Company OR Challenge Team Please submit on this slide: • Company name(s) • Submitter name(s) and e-mail addresses • Identify who agreed to the Contestant Agreement, if different from this submitter • Link(s) to company home page(s) • Who is representing which part of this submission (if it is a joint submission)

5. Use Case(s) Addressed • 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.

6. 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.

7. Solution Design: Business Perspective 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.

8. 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?

9. Solution Design: Differentiation Differentiation -- how would your proposed solution differentiate itself from others in the market?

10. Solution Design: Architecture • Please provide an overview of the proposed solution architecture • Optional • For IIoT: Please use an IIC architecture pattern (e.g. 3-Tier IIoT architecture) in the Appendix as the “canvas” and map the main elements of your solution onto it • For DLT-centric solutions with IoT, please use the TIOTA Reference Architecture in the Appendix as a “canvas” and map the main elements of your solution onto it

11. 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.

12. 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. • Scaling up on the business and operational level: How would you ensure this?

13. 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.

14. Tentative Timeline • Provide a tentative pilot timeline: • Key milestone dates • Proposed date when you believe your PoC will be live

15. Appendix • Attach any supporting materials to this appendix

16. Optional (for DLT-centric solution proposals): Mapping against TIOTA Reference Architecture Field Asset Layer • Examples: Truck, Train, Machine • Includes local and remote communication and processing (on asset, fog) • Can include local blockchain clients Asset ❷ Gateway WAN IoT Cloud ❸ IoT Cloud Layer • Asset connectivity & FOTA • Digital Twin, Asset-related data, event management • Enterprise Application Integration Application Logic Blockchain Cloud Enterprise Applications (ERP, Legacy, etc) ❹ Blockchain Cloud Layer • Asset-related ledger entries • Peer-to-Peer Middleware for management of BCs • Network of compute nodes for BC ❺ ❶ BC Middleware ❻ BC Network Backend 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

17. Optional: Architecture Canvas for your Solution Proposal Field 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. Asset Gateway WAN IoT Cloud Application Logic Blockchain Cloud BC Middleware BC Network Backend

18. Optional: Identity and Trusted Lifecycle Trusted IoT Lifecycle Phases • Provisioning • Tracing - Chain of Custody - Usage Tracing - External Events - Structural Changes • Decommissioning IoT Identity • Assets • Users Lifecycle 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?

19. Optional: Key/Certificate Lifecycle Management 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, … If applicable: Please explain how your solution is supporting the lifecycle management of keys in a distributed environment (again, using the TIOTA reference architecture)

20. 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.

21. Mapping Between a Three-tier Architecture to the Functional Domains

22. 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.

23. 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.

24. A Three-layer Databus Architecture

25. Join Us Now! • Submit your application before August 30, 2019 • Fill in the Submission PPT Template and email it to: Kathy Walsh walsh@iiconsortium.org or Evan Birkhead evan@trusted-iot.org