Overview of this article
- You will learn:
- The value proposition of connecting your Tulip solution to machines and devices.
- An overview of the various connectivity options.
- An overview of the common approach for large-scale implementations (OT Gateway with an MQTT broker or OPC UA server).
- A decision tree that recommends the appropriate connectivity option per use case.
Why to connect machines and devices to your Tulip solution
- Augment the human experience.
- Allow your operators to work with devices within arm's reach.
- Allow your operators to get information from devices outside of arm's reach.
- Improve Availability: monitor shop floor machines to provide insight into their state, OEE, etc...
- Improve Performance: accelerate time to capture data.
- Improve Quality: mitigate human errors in data entry.
- Contextualize data from machines and devices with human-centric context.
Options to connect your Tulip solution to machines and devices
The diagram below shows at high-level the various options with which you can connect your Tulip instance to machines and devices. Following this diagram we will go into further detail on each of the four options.
Path A - Tulip Player Drivers
Tulip Player has built-in drivers for many common devices (e.g. barcode scanners, Zebra label printers, serial devices, etc...). These drivers are not dependent on connectivity to the Tulip platform in the cloud and have low latency.
A full current list of drivers supported in Tulip Player can be seen at 'Edge Driver support In Tulip'
Plug and play devices
These devices directly connect to computers running the Tulip Player.
Path B - Tulip Edge Driver SDK
When the other paths are not practical options and you need to integrate specialized devices not natively supported by Tulip, or you've developed custom hardware specifically for your workflow, custom Edge drivers are an option via the Tulip Edge Driver SDK. Learn more about this option in the Edge Driver SDK article here.
Path C - Edge Devices
Use an Edge Device to connect to hardware that isn’t natively supported on Player, to connect a mobile player through an the device, or to communicate with devices that aren’t within reach of your operator.
Many devices are supported with built-in drivers. In addition, Edge devices run Node-RED natively, providing a flexible and stable environment. Read here for additional use cases and here for how to manage Edge devices.
There are two different Tulip Edge Devices:
Edge IO
Edge IO allows you to connect to hardware through digital input/ouputs, analog inputs, legacy serial (RS242/RS485), USB, and network(LAN and WAN).
Edge MC
Edge MC allows you to connect to hardware through analog inputs, USB, and network (LAN and WAN).
Path D - OT Gateway (MQTT or OPC UA Machine Data Sources)
This approach is the most common for enterprise-level large-scale connectivity. The below diagram illustrates at a high-level how a shop floor machine would be connected to Tulip via an OT gateway with an MQTT broker.
OT gateway with MQTT broker architecture summary
This architecture (as seen in the image above) consists of:
- Tulip Machines
- Machine Types
- Machine Attributes - mapped to MQTT topics
- MQTT Machine Data Source
- MQTT Broker (note: Tulip currently does not support Sparkplug B)
- e.g. HiveMQ MQTT Broker, Litmus UNS, Mosquito
- DataOps Platform (Optionally)
- e.g. Litmus Edge or HighByte
- Driver platform
Node-RED
Tulip is compatible with the free, open source Node-RED tool, which allows you to write flows and handle devices that have an analog input, don’t have a driver built, or need data processing before coming into Tulip.
Tulip has written and published nodes for interfacing with the Tulip Machine and Tables APIs.
Decision tree - which connectivity option to use
Further Reading
- Tulip Solution Architecture Fundamentals
- Architecture Fundamentals of Integrating Tulip to a Transactional Business System