IT/OT Convergence Affects Diagnostics

  • Post category:TECH TIPS
  • Reading time:5 mins read

What follows is an excerpt from the “Convergence of OT and IT from a Diagnostics Point of View” White Paper. Read on to learn more and download the complete White Paper below.

Table of Contents

  • Chapter 1 – Introduction to Diagnostics in Operational Technology
    • Basic needs of OT
    • Proprietary Protocols
    • Open Protocols
    • Ethernet-based Protocols
    • Summary of Chapter 1
  • Chapter 2 – OT Network Diagnostic Requirements
    • PROFIBUS Experience
    • Industrial Ethernet Experience
    • Chapter 2 Summary
  • Chapter 3 – IT/OT Convergence
    • Diagnostics from IT
    • Requirements of IT vs OT
    • Chapter 3 Summary
  • Chapter 4 – Ethernet Troubleshooting Tools
    • Packet Sniffers
    • IT Tools
    • OT Tools
    • Summary of Chapter 4
  • Chapter 5 – Conclusion and Future Direction
    • Conclusion
    • Future Direction

Chapter 1 – Introduction to Diagnostics in Operational Technology

Operational Technology (OT) deals with all the technology used to control a factory or process plant. In the last 30 years, it has seen three significant changes. The first was the introduction of proprietary serial-based communications protocols. The second was the introduction of open serial-based communications protocol. The third has been the more recent introduction of Information Technology into their world.

Open communication protocols are protocols that no one company owns and are ‘open’ to every company to implement. Before the rise of open protocols, OT had only proprietary protocols, protocols owned by one company, and available only to them.

Figure 1: The convergence of OT and IT – they share Ethernet standards but have different goals and priorities

Information Technology (IT) deals with all the technology used by a business for daily operations centered around the office environment. Today, we have many open protocols that make use of Ethernet standards that come from IT. This so-called convergence of OT to IT has created many challenges and opportunities.

The change from proprietary to open protocols and the introduction of IT has had a massive effect on how people maintain and troubleshoot their systems, including what diagnostics are available and how they are handled. This paper will examine how this has developed over time and how it has addressed or not addressed end-user needs.

Basic needs of OT

Factories and process plants need to run continuously for years with as few interruptions as possible. The dream of any plant manager is to commission a plant, where they only had to throw one switch, and the process would start and continue to work on its own for the next 30 years – no downtime and no maintenance.

It is a great goal, but it is a fantasy. In the real world, things break down, and we must fix them. It is possible through good design and installation methods to minimize maintenance. Unfortunately, even for these perfectly designed and installed plants, devices still age and fail; the mechanical proximity switch can only flip so many times before needing replacement. The robot cable is designed to move a lot, but even flexible cable can only be bend so many times. The screw that you tightened down will, through temperature changes and vibration, eventually loosen.

Maintenance is a necessary evil. It is necessary because we must do it. If we do not, the factory or process plant will simply stop working. It is ‘evil’ because it is not something that a business wants to spend money on.

For maintenance to be effective, the plant technician must know what is going on and where to fix things. They get this information by using diagnostics. There are three diagnostic types: process diagnostics, device diagnostics, and network diagnostics.

  • Process diagnostics are things like the vessel temperature is too hot, packages are all clumped up on the belt, or low flow. Process diagnostics are sorted out by the design engineer when the plant or factory is designed.
  • Device diagnostics are things like the input is shorted out, or the output card is not responding, or the sensor malfunctioned. Device diagnostics are typically incorporated into the communication protocol.
  • Network diagnostics are things like a device that has dropped off the network or a lost packet. Network diagnostics are partially incorporated into the communication protocol itself and partially external.
Figure 2: The three types of diagnostics: Network, Device, and Process

Since Process diagnostics are the realm of the process design engineers, we will focus on device and network diagnostics.

Click Here to Read the Full White Paper