Hacker News new | past | comments | ask | show | jobs | submit login

Part of the reason PLCs (and to a certain extent DCS) exist today is because the range of skills required to design and build real time control and safety systems spans so much that wildly bespoke programming environments on top of all that are not really welcome.

Big Company wants to know that they got a system where they can get another guy off the street and he has a chance of working out how it all fits together and solve a problem that has occured, hardware or software.

Part of that can occur because of certain levels of standardisation in the architecture and code.

If you were starting again from scratch today, maybe the PLC is not the place you would go to first up, but the inertia is high. Specialised systems like Safety PLCs have extensive diagnostics integrated into firmware, and it is really only with these diagnostics that suitable performance can be arrived at.

If you were do bespoke micro or server based type implementations, that's easily doable today, but all the design and testing for custom system parts done by OEM firmware would kill you, unless you are making a shitload of whatevers, eg automobile industry.

If what you are saying is likely in the short tem, why haven't I s=for the last ten years been buying process sub-systems arriving integrated with a raspberry PI running the show as a local package controller? It would save some capital dollars, but this just hasn't been happening, for a lot of reasons including above.

If I can get STM and TI $5 microcontrollers with SIL 2 capability (or SIL 3 with HFT=1) why am I paying 25k for a Siemens PLC safety CPU? - for all the firmware and support of a large company making a mass produced device that can be programmed by tens of thousands of people around the world, probably more. Plus a global system of dealers and reps that sell parts that I know I can add on and make work out of the box, eg more I/O or a comms card or maybe a CPU with more memory and faster CPU, just download the same program, etc etc

So, a certain part of the market will move to Industry 4.0 controller etc over time as opportunities present and this is the best option, but only a part and only as it becomes viable and economically attractive. For many big plants where a processing train generates say, a billion dollars in revenue pa, capital cost of the controllers is not actually very high on the list of considerations, safety and availability are kings. Avoidance of downtime - save a few minutes a year of downtime, you can put the msot expensive controller you can find in there and still be in front.

Finally, and I am sure there will be many people where this does not fit, but IT people normally do not do real time industrial controls well, compared to electrical engineers, process engineers and their ilk. There is just too much non IT stuff of technical nature you got to understand in all sorts of detail, a lot of management know this at different levels and are wary.

I have personally witnessed numerous disasters where it was "we will just get the IT guys to run with that, it is only a fancy computer after all" (or "it has a blue hose ethernet cable going to it, it must be IT, let them look after it")

And there is no "Just send that email again" equivelent in industrial controls, it is relatively small amounts of data that has to get there, on time, every time.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: