4 ms·

Because this software is not made by software engineers, it's made by plc programmers, electric circuit designers and whoever did drift into the field. Except

Because this software is not made by software engineers, it's made by plc programmers, electric circuit designers and whoever did drift into the field. Except for beckhoff to tc3 they haven't made it to object orientation yet, so the field is stuck as a whole in the blue screen mines of yore. Managing complexity with thin standard docs, no version control while the machines grow ever more complex sensor and actuator wise.. You can not treat modern machines like small embedded hobby devices - but the industry does. Some outside-programmers make good money coming in and solving these yesterday's problems with proper software architecture and good c development practices. But the industries doesn't learn from this. Making software will forever not be a profession for them.

wsc981 3y ago
> ... they haven't made it to object orientation yet, ... Not always a blessing and I've actually recently been thinking (e.g. in context of Lua) if object orientation is in most situations not better to avoid.
danhor 3y ago
I'm not sure if you've ever used modern software. It's sometimes amazing just how unreliable it is. Web browsers crash every few weeks, windows is known for regularly needing a reboot, evince regularly crashes on me, you can't call 911 with some of cell phones, ... . This reminds me of https://danluu.com/everything-is-broken/ https://danluu.com/everything-is-broken/ . The clearest example of the difference of reliability is looking at public digital signage (on transit and elsewhere). If it's based on LED segments or something similarly basic (with old-school embedded software development) it will basically always work. New LCD Screens inside trains/busses and outside working with a modern software setup (using an OS, often with a pc architecture, quite often just displaying a website) are broken ~10%-20% of the time. Looking at (for example) busses, a large portion of the time the screen will either be blank, not display anything, old information or just wrong information. Going inside fast food restaurants with large LCDs for the menu, often something is broken, frozen or something else. It is of course possible to make modern software more reliable. It's just much, much harder than making embedded software or PLC programming reliable. Software can be easily made more complex, but it's hard to make it non-complex or to wrap the complexity so it isn't an issue anymore. The ecosystem isn't set up for non-complexity.
- trealira 3y ago
  I think to make software more reliable, you'd have to go back to the "waterfall" method of development. If we went back to Dijkstra's notion of correctness by construction, then a specification for the program would be made, and then a programmer would prove their part of the code correct to the specification. They would write the precondition and postcondition of every effectful statement, document the invariant of every loop, and prove by induction that each loop does what it's supposed to do. Basically, annotate your program with Hiare triples. (There are books about how to do this). Then, extensive tests should be run for as much of rhe program as possible. Nowadays, we have tools for this so that we don't actually have to write a proof by induction for every loop; instead, we have bounded model checkers. In theory, the manual proof writing could be isolated to the parts of the program whose properties a bounded model checker cannot verify. However, it seems like this whole plan is infeasible unless regulations are written that enforce this onto the industry. It would make them a lot less productive, and therefore less profitable. The only benefit would be that software is more reliable. By necessity, it would have to become simpler, too. For instance, there's absolutely no way that web browsers like Chromium, with 38 million lines of code, will ever be verified, because they're too large and complex.
  - SoftTalker 3y ago
    Such regulations exist for avionics and aerospace. They were written in blood.
- SoftTalker 3y ago
  Yep, I don't eat fast food nearly as much as I used to but whenever I go in to a place with self-service ordering "kiosks" one or more of the kiosks is often out of service or frozen up, sometimes with a Windows error screen, or just stuck in a reboot loop, or it randomly resets in the middle of entering an order.
  - Log_out_ 3y ago
    [flagged]
- 3y ago
mr337 3y ago
100% agree with this. IMO there are a few efforts to modernize PLC programming but I feel like they are still stuck in the 1990s software development. Take a look at Codesys, got Git support few years ago and in very bad shape. How do you test your code, in the field or buy another Codesys testing plugin....which is in rough shape. The issue is as machines get way more complex this issue gets worse. Also there are generations of PLC devs that still want to stick with ladder logic. Huge fragmentation.
- applied_heat 3y ago
  Ladder is a fine choice for visually animating Boolean logic The fact is the unmodernized plc platforms deliver working machines and plants. The projects are built, commissioned, and unlike modern software they are finished and left to operate instead of constantly modified With no benefit to the end user
  - Kim_Bruning 3y ago
    ... sort of. Past a certain level of complexity you get into trouble with just PLC programmers alone. Don't get me wrong. <PLC programmers> tend to also have electrical skills and some are pretty good at their jobs, and you can learn a lot from them! But ... they're not programmer programmers. It's a different skill-set with only so much overlap.
    - applied_heat 3y ago
      The ladder paradigm has its place, as does function block diagrams, as does what the plc vendors call ‘structured text’. controlling physical processes like oil refineries, power generation, or sawmills is different from most computer programs as are the consequences of bugs or errors so it makes sense that it takes different people with different interests and skills.
      - Kim_Bruning 3y ago
        I can't do the nuances justice here for sure. But to make a long story short: PLCs replace relay circuits for Industrial Electrical technicians (hence: Ladder). And make no mistake: relay circuits are important, and is something they are very adept at! However, this doesn't imply that they are automatically able to write or debug regular Python or C code or what have you. ----- PS. If you let a PLC programmer at any language, they'll find a way to do ladder logic. Illustrative example (combining some features I've seen in textbooks and IRL, formatting included): if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Up : move_left = True move_right = False if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Down: move_left = False move_right = True if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == False and Finished == False and Belt == Not_Ready and Stage == 5 and (Position_Left_Arm == Down or Position_Left_Arm == Up): move_left = False move_right = False etc ...
hulitu 3y ago
> Because this software is not made by software engineers, it's made by plc programmers, electric circuit designers and whoever did drift into the field. There are more "engineers" writing software for your car or a train than "engineers" at Microsoft, Google, Apple or Facebook. I don't think that someone will be happy when driving with 100 km/h on a highway, the car will suddenly decide to restart itself. There are bugs everywhere where profits are put before engineering but calling those people names is not constructive. Especially when they use SW created by "engineers" which crash with no apparent reason when they are doing their work.

wsc981 3y ago

> ... they haven't made it to object orientation yet, ... Not always a blessing and I've actually recently been thinking (e.g. in context of Lua) if object orientation is in most situations not better to avoid.

danhor 3y ago

I'm not sure if you've ever used modern software. It's sometimes amazing just how unreliable it is. Web browsers crash every few weeks, windows is known for regularly needing a reboot, evince regularly crashes on me, you can't call 911 with some of cell phones, ... . This reminds me of https://danluu.com/everything-is-broken/ https://danluu.com/everything-is-broken/ . The clearest example of the difference of reliability is looking at public digital signage (on transit and elsewhere). If it's based on LED segments or something similarly basic (with old-school embedded software development) it will basically always work. New LCD Screens inside trains/busses and outside working with a modern software setup (using an OS, often with a pc architecture, quite often just displaying a website) are broken ~10%-20% of the time. Looking at (for example) busses, a large portion of the time the screen will either be blank, not display anything, old information or just wrong information. Going inside fast food restaurants with large LCDs for the menu, often something is broken, frozen or something else. It is of course possible to make modern software more reliable. It's just much, much harder than making embedded software or PLC programming reliable. Software can be easily made more complex, but it's hard to make it non-complex or to wrap the complexity so it isn't an issue anymore. The ecosystem isn't set up for non-complexity.

trealira 3y ago
I think to make software more reliable, you'd have to go back to the "waterfall" method of development. If we went back to Dijkstra's notion of correctness by construction, then a specification for the program would be made, and then a programmer would prove their part of the code correct to the specification. They would write the precondition and postcondition of every effectful statement, document the invariant of every loop, and prove by induction that each loop does what it's supposed to do. Basically, annotate your program with Hiare triples. (There are books about how to do this). Then, extensive tests should be run for as much of rhe program as possible. Nowadays, we have tools for this so that we don't actually have to write a proof by induction for every loop; instead, we have bounded model checkers. In theory, the manual proof writing could be isolated to the parts of the program whose properties a bounded model checker cannot verify. However, it seems like this whole plan is infeasible unless regulations are written that enforce this onto the industry. It would make them a lot less productive, and therefore less profitable. The only benefit would be that software is more reliable. By necessity, it would have to become simpler, too. For instance, there's absolutely no way that web browsers like Chromium, with 38 million lines of code, will ever be verified, because they're too large and complex.
- SoftTalker 3y ago
  Such regulations exist for avionics and aerospace. They were written in blood.
SoftTalker 3y ago
Yep, I don't eat fast food nearly as much as I used to but whenever I go in to a place with self-service ordering "kiosks" one or more of the kiosks is often out of service or frozen up, sometimes with a Windows error screen, or just stuck in a reboot loop, or it randomly resets in the middle of entering an order.
- Log_out_ 3y ago
  [flagged]
3y ago

mr337 3y ago

100% agree with this. IMO there are a few efforts to modernize PLC programming but I feel like they are still stuck in the 1990s software development. Take a look at Codesys, got Git support few years ago and in very bad shape. How do you test your code, in the field or buy another Codesys testing plugin....which is in rough shape. The issue is as machines get way more complex this issue gets worse. Also there are generations of PLC devs that still want to stick with ladder logic. Huge fragmentation.

applied_heat 3y ago
Ladder is a fine choice for visually animating Boolean logic The fact is the unmodernized plc platforms deliver working machines and plants. The projects are built, commissioned, and unlike modern software they are finished and left to operate instead of constantly modified With no benefit to the end user
- Kim_Bruning 3y ago
  ... sort of. Past a certain level of complexity you get into trouble with just PLC programmers alone. Don't get me wrong. <PLC programmers> tend to also have electrical skills and some are pretty good at their jobs, and you can learn a lot from them! But ... they're not programmer programmers. It's a different skill-set with only so much overlap.
  - applied_heat 3y ago
    The ladder paradigm has its place, as does function block diagrams, as does what the plc vendors call ‘structured text’. controlling physical processes like oil refineries, power generation, or sawmills is different from most computer programs as are the consequences of bugs or errors so it makes sense that it takes different people with different interests and skills.
    - Kim_Bruning 3y ago
      I can't do the nuances justice here for sure. But to make a long story short: PLCs replace relay circuits for Industrial Electrical technicians (hence: Ladder). And make no mistake: relay circuits are important, and is something they are very adept at! However, this doesn't imply that they are automatically able to write or debug regular Python or C code or what have you. ----- PS. If you let a PLC programmer at any language, they'll find a way to do ladder logic. Illustrative example (combining some features I've seen in textbooks and IRL, formatting included): if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Up : move_left = True move_right = False if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Down: move_left = False move_right = True if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == False and Finished == False and Belt == Not_Ready and Stage == 5 and (Position_Left_Arm == Down or Position_Left_Arm == Up): move_left = False move_right = False etc ...

hulitu 3y ago

> Because this software is not made by software engineers, it's made by plc programmers, electric circuit designers and whoever did drift into the field. There are more "engineers" writing software for your car or a train than "engineers" at Microsoft, Google, Apple or Facebook. I don't think that someone will be happy when driving with 100 km/h on a highway, the car will suddenly decide to restart itself. There are bugs everywhere where profits are put before engineering but calling those people names is not constructive. Especially when they use SW created by "engineers" which crash with no apparent reason when they are doing their work.