3 ms·

I think the big problem in us being that slow is that you can't properly test changes. The initial programs get written under immense time pressure to put it pr

I think the big problem in us being that slow is that you can't properly test changes. The initial programs get written under immense time pressure to put it productive and what after that? Do you want to touch your productive system and refactor it and risk causing hundreds of thousands in damages for production loss? You pretty much need to nail your initial design and can't afford to do the usual "we will take care of our technical debt later". I hear you saying "but you have debuggers/simulators!", for anyone actually having worked in the field you will know they are pretty much useless for big changes in machines that speak to hundreds of other systems, sensors, motors, etc. At least that's what my experience was and nobody has a backup factory to test changes on. In the tight schedules we had during production stops (Sunday nights, mainly) we were busy enough maintaining everything else than having fun on a PLC. I completely agree that this is all a big mess and people don't tend to write maintainable programs, they just want their machines running and this is where everyone needs to be trained and improve.

WillReplyfFood 9y ago
The problem with testing changes is indeed that the environment at programming start is usually under construction and in itteration. Which is why a automatic proofer going over the state chart testing for edge cases would be great. Unittests against a simulation would allready be great if they would not test the whole process, but the working of components. Actuators and Sensors usually do not change that much- so basic test-coverage would be fine. Regarding the time, i found out there usually is time- a miserable long time at the project-end, where everyone crunches besides the allready deployed machine, personal loosing the overview of the architecture and thus leaving. We had programs where even base functionality had uncovered edge cases which would destroy parts of the machine. To detec these edge cases is absoluty doable with software or with decent planning. There is no real thinking about the life-cycle of fbs-during machine initalisation, start, stop and maintainenance. Instead something "working" is produced and then simply applied to a machine. Even companies who have some standards, meaning some internal guy who trys to keep software coherent and reusable, usually have a decay in architecture during the project. Statemachines, squished into one page long boolean statements and pages upon pages of copy paste code. Eletricians and mechanics coding with funny building blocks. This has to go.
jononor 9y ago
Manual simulators don't give much benefit, manual testing in simulation is only marginally better than manual test on hardware. Need automated tests in simulation, preferably based on data collected in real systems. Ideally also hardware in the loop testing.

WillReplyfFood 9y ago

The problem with testing changes is indeed that the environment at programming start is usually under construction and in itteration. Which is why a automatic proofer going over the state chart testing for edge cases would be great. Unittests against a simulation would allready be great if they would not test the whole process, but the working of components. Actuators and Sensors usually do not change that much- so basic test-coverage would be fine. Regarding the time, i found out there usually is time- a miserable long time at the project-end, where everyone crunches besides the allready deployed machine, personal loosing the overview of the architecture and thus leaving. We had programs where even base functionality had uncovered edge cases which would destroy parts of the machine. To detec these edge cases is absoluty doable with software or with decent planning. There is no real thinking about the life-cycle of fbs-during machine initalisation, start, stop and maintainenance. Instead something "working" is produced and then simply applied to a machine. Even companies who have some standards, meaning some internal guy who trys to keep software coherent and reusable, usually have a decay in architecture during the project. Statemachines, squished into one page long boolean statements and pages upon pages of copy paste code. Eletricians and mechanics coding with funny building blocks. This has to go.

jononor 9y ago

Manual simulators don't give much benefit, manual testing in simulation is only marginally better than manual test on hardware. Need automated tests in simulation, preferably based on data collected in real systems. Ideally also hardware in the loop testing.