Have you ever wished you could troubleshoot a networking problem faster, more accurately, and with greater efficiency? Stay tuned for the next few series of blog posts where we’ll discuss exactly how you can do that.

Have you ever wondered how data gets from one side of the Internet to the other? How an email you send from California ends up in Paris in just a couple of seconds? How your programmable automation controllers send data to your groov appliance to be displayed on your smartphone or tablet, wherever you are in the world? The magic behind all of this is called the TCP/IP model.

The TCP/IP model is based on its predecessor, the OSI reference model, or Open Systems Interconnection reference model. OSI became an ISO standard in roughly 1984 and defined communication in computer and telecommunications systems. As time passed and legacy protocols were used less and less, a new and more simplified standard was formed, called the TCP/IP model. 

What is it?

The TCP/IP model is the basis for all of the networking applications and networking devices you use every day. From your email to your web browser to the PC that runs those applications and connects them to the Internet, all of them are based on the core concepts of the TCP/IP model.  

It’s what allows a system or device from one vendor to be able to communicate with a system or device from a completely different vendor. Your Windows PC knows how to communicate with a website on the Internet that may be running a completely different operating system, like Linux, because of the TCP/IP model. It is the backbone of modern computing and telecommunications. It’s a set of rules that all devices on the local network and Internet must use to communicate with each other. More importantly, it’s an open standard that vendors develop their products against.

But why should you care?

Simple. Almost every industrial device on the market today, installed in your plant or factory, has some form of Ethernet connection built into it—and Ethernet is part of the TCP/IP Model.

Ethernet has made its way into the industrial world as the standard for communication. You find it on your HMI, your PACs, your PLCs, sometimes even on the sensors you connect your field devices to.

Industrial equipment is now using the same protocols that were once predominantly found in the telecommunication and information technology world. 

Technologies we’re already familiar with, such as email, web browsing, and text messaging, have found their way into the industrial space.

Every day we open our email, type whatever we want to say, click send, and voila, the magic happens on its own. Or we connect into our HMI, make sure everything is running as it should, and go about our business.

But what happens when we open our HMI and, oh no! The tags have disconnected. We’re not seeing any data. Everything was fine when we went home yesterday. Who’s been in our control room!? Who touched our console!? That’s a frightening moment. Especially when you realize that for whatever reason, you weren’t notified by email or text message of this problem.

You have no idea how long the system has been down and what the root cause is. You have no idea where to begin troubleshooting. Even worse, you spend the better part of a day trying to fix what appears to be a very complex problem, only to find out that the tab of an RJ45 connector broke off an Ethernet cable and the connector wasn’t seated properly in the switch it was plugged into. You’ve wasted a lot of time, and money.

So this is why you should really care. If you know the TCP/IP model from the bottom to the top, no matter what type of device or overall system you’re working with, you’ll be able to move through troubleshooting much faster and more efficiently. Using the TCP/IP model during your troubleshooting, you can parse out different layers of communication and interoperability so you can systematically and accurately troubleshoot. You will save time and money. And you will be better at your job.

Stay tuned for the next post (the TCP/IP Model - Troubleshooting the Link layer), where we’ll dive deeper into the model, get a better understanding of its layers, and see how we’ll use it to troubleshoot faster and solve problems more efficiently.