This section consists of the following:

SmartServer IoT and IAP Overview

SmartServer IoT enables clients such as web browsers, workstations, and end applications to seamlessly interact with industrial IoT networks. With the SmartServer IoT, you can monitor, control, automate, and provide management services for devices commonly used in the industrial IoT edge including LON, BACnet/IP, Modbus TCP, and Modbus RTU, and other wired and wireless devices. Custom drivers can be created for the SmartServer IoT to extend its capabilities to emerging IoT protocols.

SmartServer IoT architecture is based on open, standards-based IoT Access Protocol (IAP), which standardizes web services interfaces based on MQTT and REST to industrial networks. Built on a Linux platform, it offers simple application development using standard Linux development tools and libraries combined with the IAP APIs. 

Typical first steps to start using the SmartServer IoT require installation and connection setup, network configuration, device and system definition, system integration, and automation. For developers, the SmartServer IoT offers APIs and tools for creating internal applications, custom drivers, custom web pages, and custom services. For more information on how to start setting up and using your SmartServer IoT, see SmartServer IoT Getting Started. 

Tutorial Exercises Objective

Through a series of exercises in this tutorial, you will build up to an example floor installation for a building that is part of Mango HQ (figure shown below). This example is a simplified representation of a real world IoT deployment where sensors and controllers are used to regulate the environmental conditions and energy consumption in a smart building.

The example floor installation consists of an open floor plan that is divided into four sections (virtual rooms), with each section containing two room sensors and a VAV controller. The room sensors detect the occupancy and temperature of the area and report this information to the VAV controller. The VAV controller manages the hot and cold air flow into the rooms to maintain a pre-determined temperature set point based on whether the area is occupied or unoccupied.

Example floor installation for a building that is part of Mango HQ

A typical building control systems installation and setup begins with mapping out the architectural plans of the campus facility and building within the facility to a digital representation. This involves provisioning the SmartServers to one or more buildings in the campus facility, or alternatively provisioning SmartServers to one or more floor in a building depending on the number of devices (sensors) that need to be connected.

Doing so requires planning and mapping the control devices (sensors) that have been installed in the building to their actual physical location on the architectural plans, for example: Sensors S1 and S2 to Room 1... 4, in Building 2 on the Mango HQ campus. In many cases, this task occurs prior to visiting the facility location and forms the basis of developing a digital model of a physical world. All subsequent interactions with the system and the devices that are provisioned in the system are held through this digital model.

Therefore, defining a digital model of a physical world, known as a context, is key to allow easy navigation, control, and management of the hundreds of devices that are installed in the building/campus facility, and to establish a bridge between the physical positions of these sensor devices and their digital representations in the system. 

Setting up the SmartServer CMS Widgets

The Device Types widget provides the ability to create, view, and edit device types, as well as to import device types, and to export device type definition (DTD) files with a .dtd extension. A DTD file is a CSV file that lists the device type names, program identifier (ID), application image names, and graphics assets to be used as icons for specified device types. Device types are defined for the devices you plan to provision, manage, monitor, and control with the SmartServer IoT. To define a device type, definition files are created that define the devices types, define how the devices should be monitored, define alarm conditions for the device datapoints, and define how the devices should be connected with other devices. Once these files are created, you can package them into a zip archive and import them into the Device Types widget.

The Datapoint Properties widget is used to create, view, and edit datapoint monitoring, logging, and alarming properties, and to export the datapoint property definitions to datapoint logging and alarming (DLA) files with a .dla extension. You can also manually create a DLA file as a CSV to be imported into the CMS.

The Devices widget provides the ability to create and provision devices, view device information, manage and maintain devices, and assign devices to contexts.  These tasks are discussed in the Site Provisioning section.

The Planning widget is used to create contexts in the SmartServer IoT CMS. Contexts are created based on type (i.e., campus, building, floor, room, or area) and can be linked to one or more system entities such as devices or device groups. 

The Sequencing widget is used to create the control logic that connects the sensors to the controllers, as well as the floor plan and equipment visualization on a web browser. Together, the Planning and Sequencing widgets provide system integrators and engineers powerful capabilities to customize the SmartServer IoT for any virtual type of IoT deployment or management scenario. 

Refer to the SmartServer IoT Getting Started for complete details.

Implementing the Starter Kit 

To make this example more realistic, you can use the sensors and controllers in the SmartServer IoT Starter Kit to create and consume the data in the tutorials. To get a Starter Kit, please contact your EnOcean sales representative. Refer to the SmartServer IoT Starter Kit User's Guide for more information about setting up and using this kit.

If you do not have a Starter Kit, you can still go through these exercises using the interface and configuration files, however, you will not have any real devices producing data.

The Starter Kit includes a SmartServer IoT and U60 (FT network interface) along with some pre-wired devices to demonstrate a multi-protocol network (refer to the figure below). The relevant devices in the Starter Kit used in this tutorial include a EnOcean FT 6050 EVB device (programmable LON evaluation device), a LON sensor (Smart Controls SC 100-MP), and BACnet sensor (Viconics VT7200F5031B Thermostat), and are described below. The room sensors output occupancy status and room temperature. 

For this tutorial, we will program the FT 6050 EVB to become a VAV (variable air volume) controller which requires the VAV controller application to be loaded onto the FT 6050 EVB. A VAV system supplies hot or cold air to maintain a temperature set point and is a critical part of the HVAC system. 

• The FT 6050 EVB is a programmable board that can run any application and represents represents the VAV controller. The FT 6050 EVB communicates over LON FT channel connected to the SmartServer IoT via a U60 network interface. The VAV controller application should be loaded into this board for this tutorial. Information on how to load the VAV controller application is described in Class 2 - Contexts and IAP Nodes (see Exercise 2.1 – Using IAP Nodes).

• The SC 100-MP room controller is used as a LON room sensor. This device has a temperature sensor connected to ports #13 and 14. The switch on the top right of the unit is connected to UI1 and is used to emulate occupancy sensor. Turning the switch on and off changes the occupancy state from occupied to unoccupied. The SC 100-MP also communicates over LON FT channel connected to the SmartServer IoT via the same U60 network interface.

• The Viconics VT7200F5031B Thermostat room controller is used as the BACnet room sensor. This device also has a built in temperature sensor that reports space temperature. It is connected to the bottom switch, to the left of the Viconics thermostat, which emulates occupancy state. 

The table below provides descriptions of the datapoints used in this tutorial. Only a subset of available datapoints in these devices is listed since not all of the datapoints that are available in the system will be used.

The block diagrams shown in the figure below represent the device with relevant input (left side of the box) and output (right side of the box) datapoints to better visualize the relationship between devices and datapoints. You will get a better understanding of how these datapoints are used as you complete the exercises in this tutorial. For now, it is sufficient to recognize that a device type (which is a type of a device) is defined by its input and output datapoints and this definition is provided in the interface file (which uses the extension XIF).

Starter Kit Front Panel

Next Step

Once you have read the information in this section, continue with Class 1 - Node-RED Primer.