Features of the ThingWorx EMS
This topic presents an overview of the capabilities of the ThingWorx Edge MicroServer (EMS). The sections listed below describe the features that enable your edge devices to communicate with the ThingWorx Platform:. Click the title of a section to display its content; click the title again to hide the content:
Connecting to ThingWorx
Your edge devices collect data and respond to commands. How do you get that data to the ThingWorx Platform? It is possible to use REST Web Services over HTTP/HTTPS. However, that option tends to have a high connection overhead. Another alternative is MQTT, which requires a server and additional open ports.
If you need a fast connection that stays on continuously and is always ready to relay your data to the server and execute commands using existing open ports on your firewall, the EMS and LSR can provide this connection for your devices. The EMS uses the ThingWorx AlwaysOn protocol, which is based on the Open WebSocket Standard RFC6455 (https://tools.ietf.org/html/rfc6455). If you need to create an application for a resource-constrained devices, consider the ThingWorx Edge C SDK. The C SDK also uses the AlwaysOn protocol and enables you to write edge applications with minimal footprints.
AlwaysOn™ Protocol
The ThingWorx AlwaysOn protocol is a binary protocol that uses the WebSocket protocol as its transport. The EMS uses the AlwaysOn protocol for communications with EMS. This protocol provides a number of benefits:
• The devices that are running an EMS initiate all connections, which eliminates the need to open ports for inbound connections if the edge devices are deployed behind a firewall.
• The AlwaysOn protocol uses HTTP and the standard HTTP/HTTPS ports (80 and 443) to initiate and maintain connectivity, which eliminates the need for opening secondary ports for outbound communications.
• The protocol supports the TLS standard for securing the connection to a ThingWorx Platform. Refer to the section below, Security, for more information.
• Once a connection is established, AlwaysOn binary messages are passed between the edge device and ThingWorx Platform. AlwaysOn binary messages do not require re-initiating the HTTP connection for each request and therefore do not require the additional overhead of the standard HTTP messages. A ping/pong exchange of messages between an EMS and a ThingWorx Platform keep the connection alive during periods when the connection might be closed due to inactivity..
• The connections are persistent, which allows the EMS to make outbound requests to an edge device. ThingWorx Platform can send requests to read or write properties, and to invoke services at the device, all with very low latency.
For devices that need to be offline or that do not need to be constantly connected, the EMS also supports duty cycle modulation. This feature allows developers to configure the periods of time that the device running the EMS will be online and offline. For more information, refer to Configuring Duty Cycle Modulation.
Security
The following default settings for the configuration of EMS support secure communications:
• Encryption — By default, the EMS always attempts to connect to a ThingWorx Platform using TLS. As of v.5.4.8, the EMS and Lua Script Resource use a data security library that provides automatic encryption of sensitive configuration data, such as application keys and passwords on startup. For details, refer to Automatic Configuration Encryption in the topic, Protecting Data with Encryption.
• Certificates — By default, the EMS attempts to validate the certificate presented by ThingWorx during TLS negotiation. As of v.5.4.8, the EMS supports TLS host name validation. Refer to Setting Up Security for the EMS and Using a Custom Certificate and Private Key. As of v.5.4.8, the EMS also supports TLS Host Name Validation.
 | Starting with release 5.4.7 of the EMS, the distribution bundles for Linux and Windows have version 1.1.1 of OpenSSL binaries for secure connections. This version of OpenSSL implements TLS v.1.3, which you can use between the EMS and an LSR. Once the ThingWorx Platform is updated to support TLS v.1.3, you will be able to use TLS v.1.3 between the EMS and the platform. |
Lua Script Resource (LSR)
The optional Lua Script Resource (LSR)is a statically linked application that is used to run Lua scripts and configure things (devices) for integration with the host system. The LSR supports secure HTTP connections, and as of release 5.4.0, you can customize the certificate/private key that you want to use.
HTTP Interface for REST Web Services
In addition to the AlwaysOn interface, the EMS has an HTTP interface that supports REST Web Service calls. This HTTP interface allows other applications to interact with a ThingWorx Platform through the AlwaysOn connection of the EMS. Since this other interface is HTTP, a custom application or the Lua Script Resource can be on a machine that is separate from the EMS and still communicate with it. The HTTP/REST interface of the EMS is a reflection of the REST interface of EMS.
Support for ThingWorx SCM Extension in ThingWorx Asset Advisor
The EMS and LSR support the use of the ThingWorx SCM Extension for the ThingWorx Platform. If you have this extension and ThingWorx Asset Advisor installed (imported) on your ThingWorx Platform, you can use SCM to send software and firmware updates to edge devices that are running EMS or the LSR. To set up SCM for your devices, refer to Using ThingWorx Asset Advisor with EMS and LSR.