5 ms·
Having worked on a number of "real time" machine control applications: 1) There is always a possibility that something fails to run by its due date. Planes c
by abe_m 3y ago
Having worked on a number of "real time" machine control applications:
1) There is always a possibility that something fails to run by its due date. Planes crash sometimes. Cars won't start some times. Factory machinery makes scrap parts sometimes. In a great many applications, missing a real time deadline results in degraded quality, not end of life, or regional catastrophy. The care that must be taken to lower the probability of failure needs to be in proportion to the consequence of the failure. Airplanes have redundant systems to reduce (but not eliminate) possibility of failure, while cars and trucks generally don't.
2) Even in properly working real time systems, there is a tolerance window on execution time. As machines change modes of operation, the amount of calculation effort to complete a cycle changes. If the machine is in a warm up phase, it may be doing minimal calculations, and the scan cycle is fast. Later it may be doing a quality control function that needs to do calculations on inputs from numerous sensors, and the scan cycle slows down. So long as the scan cycle doesn't exceed the limit for the process, the variation doesn't cause problems.
- mlsu 3y agoThat is true, but generally not acceptable to a regulating body for these critical applications. You would need to design and implement a validation test to prove timing in your system. Much easier to just use an RTOS and save the expensive testing.
- vlovich123 3y agoBut you still need to implement the validation test to prove that the RTOS has these requirements…
- mlsu 3y agoYou do not, if you use an RTOS that is already certified by the vendor. This saves not only a lot of time and effort for verification and validation, but also a lot of risk, since validation is unpredictable and extremely expensive. Therefore it'd be remarkable not to see a certified RTOS in such industries and applications where that validation is required, like aerospace or medical.
- blt 3y agoHow is your point 2) a response to any of the earlier points? Hard realtime systems don't care about variation, only the worst case. If your code does a single multiply-add most of the time but calls `log` every now and then, hard realtime requirement is perfectly satisfied if the bound on the worst-case runtime of `log` is small enough.
- abe_m 3y agoI suppose it isn't, but I bristle when I see someone tossing around statements like "close enough doesn't really exist". In my experience when statements like that start up, there are people involved that don't understand variation is a part of every real process. My point is that if you're going to get into safety critical systems, there is always going to be some amount of variation, and there is always a "close enough", as there is never an "exact" in real systems.
- jancsika 3y agoThe point is to care about the worst case within that variation. Most software cares about the average case, or, in the case of the Windows 10/11 start menu animation, the average across all supported machines apparently going 20 years into the future.