Libmodbus – A modbus library for Linux, Mac OS, FreeBSD and windows | Hacker News Reader

Libmodbus – A modbus library for Linux, Mac OS, FreeBSD and windows

github.com

26 pointsmaydemir13 comments

Not sure what the intended use is, but traditional modbus is generally regarded as insecure. It's difficult to implement and meet requirements for cyber security required by functional safety, as one case example.

Here are just a couple of many possible references:

https://www.incibe-cert.es/en/blog/deconstructing-modbus

https://www.researchgate.net/publication/290732323_MODBUS_pr...

Additionally, managing address based protocols like modbus, esp where they span a battery limit or responsibility boundary can be far, far more expensive in engineering alignment efforts than most people realise. Once you go tag based, your never willingly go back to address based.

These days the use OPC is often preferred, having the ability to be both secure and encrypted, as well as all the advantages of being a tag based protocol.

NB: In my younger days I implemented many, many modbus links, over RS-232/485 and TCP and it really filled many practical needs, not least of which being a default industry standard that vastly increased you chances of communication between devices made by differing vendors.

But these days, the focus on cyber security has really started to curb enthusiasm for modbus, but there is a drive to a newer version with security addressed. I would think the complexity added means, just go with OPC where possible.

> These days the use OPC is often preferred [...]

Wishful thinking. Especially in the industry sector RS485 based Modbus is still the norm, even for new products.

Also I guess you are talking about OPC UA, as OPC is just as old/bad in regards to cyber security.

The current state of cyber security in industrial networks is quite scary. Many systems rely on legacy software and can not be upgraded. Also take into account the old people running the system are often hesitant to try new technologies and often do not have the wide ranging IT and cyber security knowledge to make the right decisions. Even getting isolated networks and changing default passwords can be difficult.

You won't be building your Grandma's control systems much longer, a whole new world is already here and OPC UA is a big part of it.

A lot of PLC CPUs now come with an OPC server (and sometimes client) built in. Siemens rep here has said that medium to long term they see all their products converging on OPC and MQTT as preferred protocols.

I just delivered multiple systems using the CPU based OPC server as the main serial link on Siemens S7-1500 PLC series. Just by virtue of being a tag based structure, including attributes alone, using OPC saved huge amounts of time and effort all thru testing and commissioning.

Also, if your control system has functional safety involved then you will be complying with IEC/ISA 62443 cybersecurity standards as a requirement, and even if you don't have FS then you should be considering complying for best practice. OPC can be a big part of easy compliance.

ICS cyber-security implementation is increasingly being mandated - https://www.whitehouse.gov/briefing-room/statements-releases...

Using OPC UA as a serial link protocol of choice provides so many general benefits over modbus that you would be stupid not to use it if it was an option, and once there it's basically tick the box in the config to throw in security and encryption for almost zero extra effort.

OPC Foundation has heaps of info at their website, it's all open source with standards, examples and reference versions of code for servers/clients available. There are also plenty of free OPC servers/clients/plugins/tools etc on the web to download and use both in design and production, but also to learn a little without shelling out cash.

You can get an OPC server/client onto a sub $10 microprocessor, in an excel plug-in, thru to Oracle and SAP now have OPC modules to allow access of P2B data, as just some examples.

OPC is much easier for fault finding and debugging as well, especially when you can connect multiple clients to any given server, then view any tags with their descriptions, scaling, units etc embedded, try that with modbus. If you are smart how you strcuture it, all that tag data you used to have to type in twice (PLC and HMI, scaling, units, boolean sense etc), if you are smart how you implement, you are only entering that once, in the PLC.

And the protocol can support the equivelent of mammoth amounts of data exchange compared to available bandwidth, by virtue of report by exception, that is fully tuneable by the user.

Having bulk equivelent bandwidth available means things like multistate indicators on your HMI can be sent to the HMI from the PLC as strings as well, ready for display, instead of just coded integers. This means you never get mismatched state indication text on your HMI and you only ever need to change the HMI state indication text in your PLC.

Reality is get started learning OPC, or get left behind.

While there, grab any opportunity that comes past to get a recognised competency in ICS cybersecurity - the standards require recognised and managed relevant competencies to be held for any persons that can impact cyber security during all phases of system design/implementation and ownership. Be that guy.

Nice enthusiastic marketing fuzz.

> You won't be building your Grandma's control systems much longer, a whole new world is already here and <new tech> is a big part of it.

Yeah, I hear that claim from different sales reps of basically every relevant company in the industry automation sector since the early 90s.

> You can get an OPC server/client onto a sub $10 microprocessor.

Yes. All you need on top of that is an Ethernet phy and a OPC UA software stack, which are basically free, right?

Modbus RTU (basically any µC capable of UART) plus the RS485 phy are less than a dollar.

Cabling and controlling all that RS485 is bigger obstacle these days, it seems, than enjoying plug & play profinet with PoE combined with OPC UA for higher levels

Try ESP32 with wifi and Ethernet built in, just over $2 USD in ones.

As for marketing, I am not trying to sell you anything - I am telling you what I have done, and what I am doing, for controls systems on processing plants being put into service, today.

Most recently a $2B+ processing plant that will supply a significant portion, maybe 20%, of the global requirements for a very high demand mineral product.

I see there is comfort, certainty and perceived low risk rolling out the established and straightforward controls solutions that (old and aging) management are prepared to sign off on. But the benefits available from some of the contemporary technologies are rapidly becoming overwhelming in the risk vs reward balance. It's rapidly becoming of the nature where you innovate or be left behind, in the industrial controls sector. This is especially the case as a huge portion of the worlds control systems are past due for rejuvenation, roll out the same old, same old now and you heavily buy into being stuck with that architecture another 30 years, if the business can remain competitive for that long.

> I am not trying to sell you anything - I am telling you what I have done, and what I am doing, for controls systems on processing plants being put into service, today.

I am not trying to convince you or anything - I am telling you what I have done, and what I am doing and will be doing, according to the market of industrial automation, for the next two decades at least.

> Most recently a $2B+ processing plant that will supply a significant portion, maybe 20%, of the global requirements for a very high demand mineral product.

Most recently a €5B+ automation line on global scale that will supply a significant portion of I don't know how many percent of global molding machine equipment and operation ranging from spoons, medical equipment to car parts of basically every major vendor you can think of.

See, it's cool you use OPC UA on a infrastructure level. But on the field it's digital and analog IOs with Modbus and other archaic field buses. If you bought into the idea that every light, sensor and actuator having OPC UA wouldn't add costs in the billions for large installations, well, I have bad news for you ...

Anyone who's running Modbus TCP or any other fieldbus is going to do it on an isolated VLAN and if for some reason it needs to run inter site, set up a site2site VPN. I don't see the added value of encrypting the protocol itself if you have all the earlier things I said which you're supposed to do anyway regardless of the security provisions of the application protocol.

s/is going to/should/;

It's frightening how many industrial product are completely insecure, assuming/hoping/wishing the installers only use them on a secure network. But all too often that "secure network" is the network for the whole facility, with every laptop, phone, device, etc on the same "secure" network. Sure, it's got a NAT "firewall" between it and the scary scary internet. But it's far from isolated the way it should be.

Former SRE here.

I sure wish more people understood that security means way more than isolation, and hardening is impossible with a bunch of squishy devices that practically conspire to flatten your security model.

Zerotrust networking is the current best practice. If you’re relying on network security for something, you’ve already failed.

I looked at this library for a project where I had to support modbus, but I then geeked out and wrote my own library to support as much of the useless parts of the standard as I could simply for the enjoyment of it. It gets pretty hairy at the edges because the standard isn’t complete. But most of the stuff in there I’ve never actually seen being used in the wild.

Reply on news.ycombinator.com