IOT Integration Introduction

High Level Overview

This introductory section provides a broad overview of the methodology employed for integrating building systems and devices with Twinview, a sophisticated digital twin platform. Twinview is designed to be hardware-agnostic, offering a multitude of integration options with various building systems, thus providing a flexible and versatile solution for diverse infrastructural setups.

Twinview functions primarily as a visualization layer, capable of aggregating and presenting data from a wide array of sources. This includes data from Building Management Systems (BMS), sensor networks, and various subsystems within the building infrastructure. The platform's ability to interface with these diverse data sources underscores its versatility and adaptability.

Data is ingested into Twinview by its Data ingestion service. Once the data is ingested into Twinview, it is represented as an 'IoT Data Stream Device'. These data streams can be associated with specific assets or rooms, displayed on a dashboard, incorporated into reports, or utilized in heat mapping, among other applications. This flexibility in data representation and usage allows for a comprehensive understanding of the building's operational dynamics.

The data ingested by Twinview is stored in an internal data lake, a scalable and secure storage repository. This data lake enables the retention of historical data, facilitating charting, reporting, and in-depth analysis. Moreover, it ensures high-level performance by providing efficient data retrieval and processing capabilities. The subsequent sections of this document will delve into the technical specifics of these processes, detailing the protocols, interfaces, and data models used.

Do you need a Gateway or DAD device?

A Gateway device is not always necessary, and your system or service may be able to interface with the Twinview Ingestion Service directly.

If your System or service allows you to make HTTP POST web-requests or webhooks to the internet, and you can define the JSON payload message schema then a gateway device might not be required. Refer to the Data Ingestion Service Document on how to format your payload and send this to the data ingestion service.

Even if your system or service is compatible with the Data Ingestion Service and a gateway is not needed, adding a gateway may offer other benefits that make it worth considering. Some examples include having the ability to Transform data, and create automations in a intuitive visual scripting interface.

The Twinview Gateway Device

Twinview uses a gateway device to communicate with your buildings systems and devices and we support the majority of the popular communication protocols such as BACnet, Modbus, HTTP Web Requests and MQTT.

The gateway securely integrates into the edge network of your building and communicates with the devices and/or services via one of the supported protocols. The gateway communicates with Twinview using the Twinview Data Ingestion service.

As well as its primary role as a Data Acquisition Device (DAD), the gateway can performs various secondary roles, some of which are below.

• An edge communication and data acquisition device (DAD)

• Logic engine for control and automation

• An on premis MQTT Broker

• Data Transformation Service

• Digital Display Server

Twinview has built in support for the following:

	Port	Security	Implementation Aproach
HTTPS Web Request	443	TLS1.3	Ingestion OR Gateway
HTTP Web Request	80	Disabled by Default	Ingestion OR Gateway
MQTT nonsecure	1883	Disabled by Default	Ingestion VIA Gateway
MQTT secure	8883	TLS1.3, X509	Ingestion VIA Gateway
BACnet IP	47808	TLS1.3	Ingestion VIA Gateway
Modbus	502	TLS1.3	Ingestion VIA Gateway

*Twinview optionally supports websocket connections on HTTPS and MQTT