Kelvin Bridges¶
On this page you will learn about what is a Kelvin Bridge and how they fit into the Kelvin Core.
What is a Kelvin Bridge ?¶
A Kelvin Bridge is a communication tool developed and maintained by the Kelvin Development Team. It is a special Kelvin App which you can deploy to your Kelvin Cluster from the Cloud Server.
The Kelvin Cluster will automatically assign the Kelvin Bridge to one of the Kelvin Clusters in the cluster.
If you are using an asset communication which is directly related to a particular Kelvin Cluster, such as serial communications, then you must use a single node Kubernetes cluster to guarantee the Kelvin Bridge is deployed to the correct hardware.
The Kelvin Bridge will collect data from your assets as Kelvin Metrics and send and store them in the main database on the Cloud Server.
Types of Kelvin Bridges¶
There are currently five types of Kelvin Bridges available.
- Using the OPC UA communication protocol (deploy by Kelvin Manager UI or SDK)
- Using the MQTT communication protocol (deploy by Kelvin Manager UI or SDK)
- Using the Emerson ROC communication protocol (deploy by Kelvin Manager UI or SDK)
- Modbus RTU (Serial) and TCP communication protocol (deploy by SDK only)
- ABB TotalFlow® communication protocol (deploy by SDK only)
Below are general descriptions about the different protocols. You can find more by visiting the developers' homepages.
Each protocol is very powerful and capable to perform many types of communications for many different scenarios.
Kelvin utilizes a subset of these protocols to perform the required tasks for the Kelvin Core. Some features mentioned in the description below are not available as they are not required in the Kelvin Core Services.
OPC UA¶
The OPC Unified Architecture (UA), released in 2008, is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework.
This multi-layered approach accomplishes the original design specification goals of:
- Functional equivalence: all COM OPC Classic specifications are mapped to UA
- Platform independence: from an embedded micro-controller to cloud-based infrastructure
- Secure: encryption, authentication, and auditing
- Extensible: ability to add new features without affecting existing applications
- Comprehensive information modeling: for defining complex information
The multi-layered architecture of OPC UA provides a "future proof" framework. Innovative technologies and methodologies such as new transport protocols, security algorithms, encoding standards, or application-services can be incorporated into OPC UA while maintaining backwards compatibility for existing products. UA products built today will work with the products of tomorrow.
The OPC UA information modeling framework turns data into information. With complete object-oriented capabilities, even the most complex multi-level structures can be modeled and extended.
This framework is THE fundamental element of OPC Unified Architecture. It defines the rules and base building blocks necessary to expose an information model with OPC UA. While OPC UA already defines several core models that can be applied in many industries, other organizations build their models upon them, exposing their more specific information with OPC UA.
MQTT¶
MQTT (Message Queue Telemetry Transport) is a lightweight network protocol to transport messages between devices. It uses a publish-subscribe architecture and usually runs over TCP/IP but can be used on many other communication protocols.
It has become a popular method to transfer continuous streams of data as it is very simple to implement and requires very low bandwidth. It also allows the clients who create information (publisher client) to be independent and not connected to clients who consume information (subscriber client).
The MQTT broker is the glue which manages the transfer of information between publishers and subscribers. MQTT clients will connect to the MQTT broker only.
Emerson ROC¶
Emerson Remote Operations Controller combines the ruggedness and low power consumption of a RTU, the scalability, speed and control of a PLC, and the audit trails and historical data of a flow computer enabling you to measure, control and optimize your oil and gas operations using a single device.
You can communication to the Emerson Remote Operations Controller (ROC), FloBoss, and RegFlo using the Emerson ROC or ROC plus protocol. It can be used to access and retrieve information from the database configuration, real-time clock, events, alarm logs, live data and historically archived data.
Communications over TCP / IP and serial (direct, radio, or dialup) links are supported.
Modbus RTU and Modbus TCP¶
Modbus is a data communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol and is now a commonly available means of connecting industrial electronic devices. It is now popular in industrial environments because it is openly published and royalty-free. It was developed for industrial applications, is relatively easy to deploy and maintain compared to other standards, and places few restrictions - other than the datagram (packet) size - on the format of the data to be transmitted.
The Modbus protocol can use many types of transport layers. For Kelvin we support RTU serial communication and TCP Ethernet transport layers.
Modbus supports communication to and from multiple devices connected to the same cable or Ethernet network. For example, there can be a device that measures temperature and another device to measure humidity connected to the same cable, both communicating measurements to the same computer.
Modbus is often used to connect a plant/system supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems in the electric power industry. Many of the data types are named from industrial control of factory devices, such as ladder logic because of its use in driving relays: A single physical output is called a coil, and a single physical input is called a discrete input or a contact.
The development and update of Modbus protocols have been managed by the Modbus Organization since April 2004, when Schneider Electric transferred rights to that organization. The Modbus Organization is an association of users and suppliers of Modbus-compliant devices that advocates for the continued use of the technology.[4] Modbus Organization, Inc. is a trade association for the promotion and development of Modbus protocol.
ABB TotalFlow®¶
The ABB Totalflow communications protocol is used by ABB Totalflow devices which are typically used by ABB's flow computers and analyzers.
The protocol comes in two native protocols - DB1 and DB2. It can be setup for use over two different type of transport layers; serial communications or TCP Ethernet.
This protocol is powerful and can manage many areas of an ABB TotalFlow® computer like the G2 Late, G3, G4 Early, G4 Late, and G5. The main task is to poll the EFM data, events, alarms, historical logs, configs, QTR (quantitative transaction records), etc.
There are many features and subsets available. Too many to fully describe here. For example the protocol supports AAR addresses to access data from standard and custom applications running on the flow computer. It also supports “Auto-Discovery” to obtain information about applications running on the Totalflow computer. ABB supplies standard .ini files for different applications so that third party products can auto-configure the array-register definitions and create default poll groups for all enabled applications.
Kelvin Control Change Manager¶
Kelvin Control Change allows you to send variable changes to the edge devices such as PLC's or HMI's from the Cloud Server.
The changes can be performed by Kelvin API, Kelvin Maps or Kelvin CoPilot.
This process is different from a standard Read/Write data variable as the change at the edge will be written and the control change manager at the edge will communicate with the Kelvin Bridges to ensure the write is completed and verified successfully.
The process itself is explained in this infographic;
You can learn more about Kelvin Control Manager at;
- Kelvin Overview -> Technologies-> Kelvin Control Change
- Getting Started Guides -> GSG Common Features -> GSG
- Control Change
Other Related Links¶
- Kelvin Manager UI -> Connection -> Bridges -> Creating an OPC UA Bridge
- Kelvin Manager UI -> Connection -> Bridges -> Creating an MQTT Bridge
- Kelvin Manager UI -> Connection -> Bridges -> Creating an Emerson Controller ROC Bridge
Credits¶
- OPC UA Quotation and Infographic from https://opcfoundation.org/about/opc-technologies/opc-ua/
- MQTT Infographic from https://mqtt.org
- Emerson ROC Quotation and controller picture from https://www.emerson.com/en-us/catalog/emerson-roc800-series
- Modbus description (edited to suit Kelvin environment) from https://en.wikipedia.org/wiki/Modbus
Last Modified¶
Last Modified on 20th June 2023
20th June 2023
* Updated Kelvin Platform to Kelvin Core Services and Kelvin Core Server
* Updated link locations
31st May 2023
* Updated to incorporate the new Kubernetes setup with Kelvin Clusters and Kelvin Nodes
30th June 2022
* New last modified section started
Kelvin Documentation AI Support
Hi. My name is KevDocBot. How can I help you?









