Software Toolbox has been involved with Industrial Automation communications for over 20 years now and some of us for even longer. When you've done something for such a long time you can forget that many people in this industry or IT don’t know as much about the topic as they would like.
To help share the collective knowledge we've gained throughout the years, we're starting a series of articles on why protocols matter for getting the most out of your projects.
This introductory blog post to the series will discuss my insights starting out in this industry as an Applications Consultant at Software Toolbox with respect to just how important the actual communications protocol and understanding of its strengths and weaknesses can be to the success of a project.
As a Mechanical Engineer just getting into the Industrial Automation industry, I started with very little as far as a background in communications protocols were concerned. Through my involvement in various projects, it became clear very quickly how critical choosing an appropriate communications protocol was to a well-functioning system.
As it goes with most complex problems, most people would agree that once you have the big picture – i.e. the plan of what you are going to do – you start at the bottom and work your way up. So why is it that when it comes to selecting a communications protocol, it is a common practice to treat it as an afterthought rather than the building blocks on which the rest of the system is not only built, but that will define how the rest of the system behaves.
A line that I hear very often is “Oh, the protocol doesn’t matter to us, as long as it works” (these are systems that typically end up with Modbus handling their critical infrastructure). Don’t get me wrong, there is nothing inherently wrong with Modbus; but it is typically chosen for the wrong reasons (E.g. because it’s a very simple protocol). Just having the right control system hardware in place means very little when the system is unable to serve the data at a rate needed to make informed business decisions – ultimately costing a company time and money.
Naturally, I am not the only person who has come to understand how important protocols can be. Engineers from many disciplines, many industries, and many different levels of automation have struggled to create open standards that can be used to meet the information requirements of the business. The goal being that a wide variety of hardware vendors will adopt the standard and provide systems that meet their communication needs.
I find that choosing the right protocol for a system is similar to choosing the best tool for a job. Could you get a nail hammered down with a screwdriver? Sure, you could (eventually); but a hammer is going to get the job done a whole lot quicker, and with a lot less effort on your part.
Just like there is an ideal tool to use for a job, there is a protocol that will be best suited for the application; where SNMP might be ideal for IT to gather data on managed devices on the network, BACnet is probably best suited for monitoring actuators and sensors in a building automation project, and DNP3 is ideally suited for systems where RTUs are spread over a wide area and communicating using radios, satellites, or similar bandwidth limited mediums and timestamping at the event occurrence is critical.
In short, the Protocol used in a project really does matter so much more than many people may think. Knowing more about the topic in general and the specific protocol being used in your situation can have a great impact on its success both technically and financially. We invite you to subscribe to our blog and watch out for our coverage on some of the Protocols I mentioned above as well as similar threads like Kevin Rutherford’s Protocol Docs - The Good, the Bad, the Ugly and Five Sources of Actionable JSON Data for Your HMI/SCADA/MES
