“Any fool can know. The point is to understand.” – Albert Einstein

In this post I am going to highlight some challenges of learning and managing operational technology while introducing a new project that aims to simplify this process.

The Challenges of Learning Operational Technology

Almost five years ago I commenced my career in the Australian mining industry with BHP. I remember my first day of work in the Perth office on October 12th 2015. I was taken up into the Integrated Remote Operations Center (“IROC”) and given a tour of all the operational technology (“OT”) I was expected to support. This included mining, plant, port and rail control systems, as well as many other non-production applications which were used by the scheduling teams. To say that I was completely overwhelmed is an understatement!

This feeling of being overwhelmed by OT is something that is not exclusive to myself. Over the last 5 years I have had the pleasure of training new employees and meeting a lot of people within the mining, oil & gas, and manufacturing industries. Like any room full of technical personnel and engineers we all disagree on things, but common ground is established on the fact that it is bloody* hard to learn OT.

My “research” into this field has concluded that there are four ways people learn OT:

  1. There is a sage on site (Very Rare). They have grey hair, a pencil on top of their ear, and when they look at broken equipment it just starts working for no apparent reason. They have either implemented or supported every conceivable piece of technology on site, and in a sense, are the living embodiment of that site. You count yourself blessed if they take you under their wing or give you time out of their day to explain how things work.
  2.  Your department has a very good training budget (Rare). You’re booked into expensive vendor training and are shown how their product(s) work by (mostly) excellent trainers. If you’re lucky, they will be familiar with your site and can answer very specific and niche questions.
  3. You have downtime on shift and can consult dense vendor documentation (Uncommon). Somehow the stars have aligned and you have enough downtime in your day to proactive research problems and issues. Unfortunately the one snippet of knowledge you are seeking is trapped within thousands of pages of vendor documentation. It is difficult but you figure out how the thing works and then HOPEFULLY produce documentation for the rest of your team.
  4. You wing it and figure it out when it breaks (Common). It’s 2-O’Clock in the morning and that system which has been running without any issues for 20 years finally stops working. Catastrophe. You need to figure out how the heck it worked but can’t because the knowledge is not readily available or the last person who worked on the technology recently died (this has happened to me). So everyone puts their heads together, “MacGyver’s” a solution, and HOPEFULLY documents knowledge after-the-fact, else this process repeats ad infinitum.

So, how do we fix this, at least from an industrial networking perspective? The answer is by documenting what we do know and simplifying that which already exists.


Introducing the Industrial Network Automation Project

The primary aim of this multi-year project is to develop content which allows the reader to understand how industrial networking protocols and features work. It will primarily focus on Cisco’s Industrial Ethernet (“IE Series”), IoT Gateway, connected smart grid and building management devices, however this may expand to other vendors in the future (e.g.: Hirschmann).

Content will be developed to the following standards:

  • An in-depth analysis of the topic will be conducted;
  • Lab diagrams, schematics and configurations will be shared via my GitHub Repository for the reader to use and follow along with;
  • Troubleshooting documentation will be developed to help you investigate issues with the technology – this is a one stop shop for you to get your operations up and running. Note that you are responsible for ensuring that recommendations are safe and suitable for your environment, so don’t hold me accountable for any plant trips or equipment crashes; and
  • Where work can be automated examples will be provided.

I want to highlight that this content is also going to cover new and emerging technologies too! You will be Taylor, an OT Specialist working for Mining Enterprise Materials (“MEM”), who is in charge of investigating design changes, solutions and product integrations for MEM’s various plants. The below topology showcases ONE of the interconnection between MEM’s HQ and a remote plant and some of the technologies Taylor would be working with. You can view this image in higher resolution or in PDF format on my GitHub Repository.


Content Availability & Timing

Content is currently being written on a casual basis outside of my working and university commitments. I am aiming to produce between one (1) and three (3) articles per quarter. I have strict quality standards for the content that I wish to produce, so please understand this is going to take some time to complete. A content schedule will be published in the coming weeks on my GitHub which will outline everything that is on my radar and act as a public project tracker too.

I want to address content availability now rather than later. Everything that will be hosted on this site is going to be free forever. Yes, that’s right – no accounts required, no payment, no catches – 100% free for you to use and consume as you wish. There is a lot of work to be done, lab gear to purchase and set up, so I will be upfront and disclose that I will be exploring paid content options in the future as a means to augment and compliment what I publish here.

To stay up to date with this project be sure to check back on the site regularly, follow me on GitHub, and/or connect with me on LinkedIn!


* Bloody: An Australian term which emphasises difficulty or frustration. E.g.: “That exam was bloody hard!” translates to “That exam was very difficult”.