Linux Might Drop Fieldbus Support For Industrial Systems With No One Maintaining It

[phoronix]

Phoronix: Linux Might Drop Fieldbus Support For Industrial Systems With No One Maintaining It

Merged back in 2019 was the Fieldbus system for connecting different systems/components/instruments within industrial environments. Five years later the code isn't being well maintained and looks like it will be on its way out the door if no one steps up to better maintain this driver support for industrial systems for process automation...

https://www.phoronix.com/news/Linux-Might-Drop-Fieldbus

[kpedersen]

If anyone is actually using Fieldbus, they can stick to using current Linux LTS versions -- after all, the LTS kernels are more likely to be used within industrial systems.

Yep but unless future LTS kernels will specifically "re-add" fieldbus support back in, the sorts of lifespan that industrial systems tend to aim for is well beyond what an LTS kernel released today will have.

Luckily, Fieldbus looks to be one of those many things that was dumped into the Linux kernel that probably should not have been accepted into mainline in the first place (though it is quite cool tech. I always wondered how large plants organised their comms).

[equeim]

Yep but unless future LTS kernels will specifically "re-add" fieldbus support back in, the sorts of lifespan that industrial systems tend to aim for is well beyond what an LTS kernel released today will have.

Luckily, Fieldbus looks to be one of those many things that was dumped into the Linux kernel that probably should not have been accepted into mainline in the first place (though it is quite cool tech. I always wondered how large plants organised their comms).

I doubt these kinds of systems even update their kernel (not even to patch versions). They will just use whatever kernel they were released with, forever.

[TheMightyBuzzard]

I doubt these kinds of systems even update their kernel (not even to patch versions). They will just use whatever kernel they were released with, forever.

Usually not unless there's a fix for a bug that's been annoying them. Or if they have a high severity CVE come out that directly impacts their setup and is a genuine danger and if they can convince management to stop production for an update that they guarantee won't have them down an unknown amount of time.

[kpedersen]

I doubt these kinds of systems even update their kernel (not even to patch versions). They will just use whatever kernel they were released with, forever.

If it was a closed-loop / logically air-gapped system (i.e controlling a single device), certainly. Why change what isn't broken.

But for an overall communication system across the entire factory, I imagine they will want to keep that a little more maintained (or at least half-maintained!).

[oiaohm]

Yep but unless future LTS kernels will specifically "re-add" fieldbus support back in, the sorts of lifespan that industrial systems tend to aim for is well beyond what an LTS kernel released today will have.

Luckily, Fieldbus looks to be one of those many things that was dumped into the Linux kernel that probably should not have been accepted into mainline in the first place (though it is quite cool tech. I always wondered how large plants organised their comms).

http://www1.gcanbox.com/fsd/gsxw/CAN-and-RS485.html

Newer setups happen to be more often than not CAN. There are also bridges from CAN to Fieldbus. The issue is Fieldbus might have a higher max transfer speed of 10Mbps vs CAN 1Mbps but this is only in ideal environments. In non Ideal environments Fieldbus performance drops of quite quickly. Yes ripping out runs of Fieldbus and replacing those runs with CAN cabling and 0bridges to and from Fieldbus can in fact result in higher Fieldbus network performance.

Please note 1Mbps speed limit is copper based CAN. Optical fiber based can is 8Mbps and this works perfectly in high noise environments..

Yes as noted there stuff out of china is likely to be CAN only.

https://new.abb.com/drives/connectivity/fieldbus-connectivity/ethernet-ip

Yes due to fieldbus that not Can being a mega pain you find fieldbus to normal networking over and over again. This means you are not going to connect fieldbus controllers direct to PC. The problem is noted above fieldbus don't like multi earthing attachment yes the "grounded at a single point" limitation. How do you over come this fieldbus limitation that right either bridge to can or bridge to Ethernet.

This is my problem fieldbus in the Linux kernel comes why.

https://docs.arduino.cc/tutorials/opta/user-manual/

Yes arduino opta comes to mind. Not running Linux but works on open source software as bridge back to 10/100 networking.

kpedersen its more that fieldbus card support that was added to the Linux kernel end up not making much sense. Deployed Fieldbus will either be bridged to Can or bridged to Ethernet. Yes connecting fieldbus to a card(RS485) in your computer for anything more than device testing is likely to break the only connect to earth in one location and introduce noise that end up upsetting the complete connect set of fieldbus devices.

The Arduino IDE having fieldbus RS485 support when it for small micro-controllers that are not drawing a lot of power and not generating lots of signal noise makes sense.

Will the Linux kernel dropping the fieldbus drivers stop a Linux PC from interfacing with existing fieldbus deployed solutions the answer is mostly no. The effected parties will just have to add a fieldbus RS485 to fieldbus TCP/IP bridge and run a bit of networking cable from the Linux PC to the bridge. The TCP/IP ethernet side of fieldbus solutions does not require any Linux kernel special drivers. Yes lots of modern field-bus hardware has ethernet ports at the master control points.

Yes over 99% of the time under 50 dollars worth of investment is required to make the in PC fieldbus card no longer require and by removing card from the PC you make your fieldbus communication more stable. The 1 percent of time it going to cost having to buy the bridge bit of hardware but fitting the bridge will still improve the field-bus stability.

I think the Linux kernel fieldbus drivers are one of those things it seams like a good idea at the time to add it to the Linux kernel but in reality the hardware that those drivers support causes more trouble than they are worth(grounding and noise problems) so no one has been maintaining the drivers because either the users have stop using it or the users still using the hardware really should stop using the field-bus(rs485) cards and migrate to either can or fieldbus by ip from Linux. Yes the bridge hardware from RS485 field bus to IP are very compact written bits of software running on very small microcontrollers where even the most cut down current mainline and LTS Linux kernel do not run so being area for Arduino and the like.

Item made pointless by fieldbus over Ip and can is the simplest answer here.

I doubt these kinds of systems even update their kernel (not even to patch versions). They will just use whatever kernel they were released with, forever.

They do update kernels and software for internet facing items. Yes scary how much civil infrastructure is in fact connected to the internet yes without even a good firewall..

[mahlersand]

Hm. Not sure if it is the right time to decide that.

I would wager that fieldbus systems have been a bit of a non-starter on industry systems because there was no real use for them, on account of Linux not being a sensible operating system for industrial operations without strong real-time guarantees. There is no point in setting up a difficult-to-maintain RT-capable Linux system on an industry machine if there are sufficient real time operating systems with much lower footprint and requirements. With the move towards a more integrated control over industrial systems, I think a real-time Linux system may become more viable, especially since the real-time patches and sched-ext have been merged. Control systems could now utilize off-the-shelf components with a more or less stock Linux kernel to control e.g. their production line and communicate to fieldbus systems in real time AND provide human-interactable interfaces directly on the system.

The best course of action would of course be to never have introduced those kernel subsystems and to just now develop them to get some attention from the industry, because I think they could be promising for some usecases.

[stormcrow]

If it was a closed-loop / logically air-gapped system (i.e controlling a single device), certainly. Why change what isn't broken.

But for an overall communication system across the entire factory, I imagine they will want to keep that a little more maintained (or at least half-maintained!).

Not really. Factory systems are usually maintained (and certified) as a cohesive whole. It takes an act of god practically to update industrial control systems, especially those that are critical to the site's continued functioning. Many factories run 3 8 hour shifts 24/7. They only interrupt that if there's a physical breakdown, and even then only that particular line. This is why operations security is such a problem. Most of these factories can't shut down production lines while they're active without causing a lot of knock-on effects everywhere along the supply chain. Good luck getting Mr. Middle Manager to realize that connecting the facility's CAM hub to the LAN (also connected to the corporate WAN which is in turn connected to the Internet) so he can laze about in his office is a Bad Thing.

[Yndoendo]

If it was a closed-loop / logically air-gapped system (i.e controlling a single device), certainly. Why change what isn't broken.

But for an overall communication system across the entire factory, I imagine they will want to keep that a little more maintained (or at least half-maintained!).

This depends on the client and how tightly the system is integrated. Product I work on, one of those big US shipping companies wanted their system upgraded even though they are air-gapped. Sneaker net systems are still vulnerable to rouge employees. They even wanted secure USB cables, plugs, and NIC connectors installed.

Most often system are are updated during maintenance, if there is a bug that only becomes apparent during production, or a new feature that they want.

Upgrades are eased when there is clear separation between solution software. Example, the system controls are managed by a PLC and the human interaction is a separate program that does not affect the other during upgrades. This is like having a service that is managed by an user application, such as MariaDB and phpMyAdmin.

Then you also have the clients that don't want to spend any money on upgrades and are still running end of life operating systems like Windows XP, Window 7 pre and post SP1. I still have to maintain build support for Windows 7 pre-SP1 for some solutions. I don't even know if those systems are even air-gapped.

[oiaohm]

I would wager that fieldbus systems have been a bit of a non-starter on industry systems because there was no real use for them, on account of Linux not being a sensible operating system for industrial operations without strong real-time guarantees.

Not it.

https://www.hilscher.com/products/pc-cards-for-industrial-ethernet-fieldbus/pci-express/cifx-50e-2dp

Its cards like above. Yes these first appear as PCI cards then as PCIe cards. This kind of stuff was done pre fieldbus over IP. Look at that card and spot the problem. Yes you connect two fieldbus networks to one card and a fieldbus network is works right when "grounded at a single point" yes connecting two like this you can now caused the double grounded problem.

Today we have the likes of the following.

https://www.prosoft-technology.com/Products/Gateways/PLX5x/PROFIBUS-DP-Master-Slave-to-EtherNet-IP-Modbus-TCP-IP-R-or-Modbus-R-Serial-Gateway

The best course of action would of course be to never have introduced those kernel subsystems and to just now develop them to get some attention from the industry, because I think they could be promising for some usecases.

The reality they did not have a crystal ball at the time. In 9 July 2019 when fieldbus was added to the Linux kernel we did not have in any major number fieldbus to ip bridge devices. At that time the PCI/PCIe cards made sense because if you want to bridge to IP for any reason you would be using industrial pc right. But since then we have got fieldbus to ip bridges using 2 core or less micro-controllers these are way less Electromagnetic interference(EMI). generating devices.

Not really. Factory systems are usually maintained (and certified) as a cohesive whole. It takes an act of god practically to update industrial control systems,.

This is the problem here there is act of god problems( to be correct humans). Factories using fieldbus have been suffering from issues. The above bridge device allows you to covert a section of fieldbus to ethernet. Yes 10 devices on one side of the bridge then a cat5/6 from that bridge to another bridge that is then connect the master those devices use to connect to. Why would you do this so you can add another grounding point to reduce the effect of Electromagnetic interference(EMI).

Why would a production line that has functioned correctly for decades start having problems now. This is change in actions of human. To be correct human with modern mobile phones and the like moving around factories doing their job. EMI noise floor has increased in factories because of this. CAN bus this is fine due to their high noise tollerance. Fieldbus solutions this is not fine due to their low noise tolerance.

Yes human walking around with EMI source device causing random issues when they happen to be in particular locations and particular locations only seam at first like your factory is suffering from random acts of god.

RS485 fieldbus in a lot of ways is obsolete and problem child technology that will take ages to remove. Yes 1200meters range but speed will only be 100kbs if you do that. CAN 1Mbps is functional out to it full 10km.

This is worse than you think max range you can do 10Mbps Ethernet over copper without repeater at full speed is 500 meters(thicknet coax). 500 meter of field bus you are already under 1Mbps. Do note there is faster more modern Ethernet over copper using coax that goes out to 1.4km in run length.

RS485 is a 1983 technology and this is what Fieldbus RS485 is based on and has a serous limitation.

https://en.wikipedia.org/wiki/RS-485

RS-485 supports inexpensive local networks and multidrop communications links, using the same differential signaling over twisted pair as RS-422. It is generally accepted that RS-485 can be used with data rates up to 10 Mbit/s[a] or, at lower speeds, distances up to 1,200 m (4,000 ft).[2] As a rule of thumb, the speed in bit/s multiplied by the length in meters should not exceed 108. Thus a 50-meter cable should not signal faster than 2 Mbit/s.

Notice this insane drop off you have got to 50 meters and fieldbus using RS-485 is already under 2Mbit of performance. Yes at 100meters Fieldbus RS485 is at CAN bus speed any distance past that you are operating less CAN bus speed.

Also note that length in meters is your total fieldbus/RS-485 length. So yes spitting a 100 meter fieldbus RS485 in the middle with two bridge devices and ethernet cable end up basically doubling transmission speed. Yes the 10Mbps of RS-485 only exists over a cable length of 1 meter any longer kiss good buy to 10Mbps second.

Now think about it you want a PC to access a industrial fieldbus what are you going to run to the PC. Cat5/6/7.. Ethernet or Coax Ethernet or Fiber optic Ethernet connected to a IP field-bus bridge or Fieldbus RS-485 cable..

The answer is basically anything Ethernet because that run of RS-485 cable to the PC is going to be downgrading the complete Fieldbus network performance that is normally not the great to start off with due to the max speed of fieldbus being based on max cable length between all the fieldbus items on RS-485 section.

Now if you ask the question again with fieldbus replaced with CAN it is a lot harder choice because the performance is not going to degraded unless you are going to cross the 10km cabling limit. 1Mbps is not super fast but is still decent enough for most control stuff. CAN you keep fairly simple wiring without the most of issues. Yes adding each 100Meters to a CAN to connect to back of PC in 99.9% is not going to do anything bad. Its only the 0.1 where you hit the CAN bus 10Km limit.

The reality here is the fieldbus implemented in the Linux kernel does not make practical sense to use today because we have fieldbus IP bridges and what in the Linux kernel is for RS-485 fieldbus straight on the back of PC. In 2019 when fieldbus was added to the Linux kernel fieldbus IP bridges were not common devices. The limitations of RS-485 means you want to run as little RS-485 as you can so you can have best RS-485 performance. RS-485 limitations encourages bridging to CAN or Ip/ethernet to get better performance.(remember the operator at the PC will normally want to be somewhat away from the factory noise)

Fieldbus RS-485 is not that real-time its not that high performance. Lot of new fieldbus devices don't have the RS-485 port they are fieldbus over 100/10 Mbps IP/Ethernet Cat5 or nothing. Fieldbus over 100/10Mbps IP/Ethernet does not require any Linux kernel drivers can be operated by userspace code doing normal tcp/ip network communication.

Now removing all the Fieldbus RS-485 from factories with how short factories are off line for this is going to take decades. Yes segment by segment cut out and replaced by Fieldbus over IP or CAN bridges depending on the companies choice what there future control system is going to look like and with each shorting of the RS-485 seen the general performance of the control system improve.

All the based RS-485 stuff need only exist in museums we have way better alternatives that don't have the insane drop off in performance that RS-485 has.

There is always going to be these bits of technology added to the Linux kernel that few years down the track it comes really clear it was pointless keeping these items long because the technology had a major design flaw and should be totally deprecated out of existence.