Post History
If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual r...
#20: Post edited
by
Pete W
·
2026-08-14T22:34:49Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known test-fail-cases of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification - but do reduce if multiple DUT-production-failmodes result in the same production-test-failure, because the purpose of the OQ was to show the test-equipment function, which is catching the DUT-test-fail-case, regardless of which DUT-production-failmode caused it.To back up a little bit, the take-home of this might be that you should be clear about:- * what are the functions of the DUT, and of the test-equipment
- * distinguish between design-failmode and production-failmode, of both the DUT and test-equipment
- * aggregate DUT-production-failmodes into DUT-test-fail-cases
- * have a systematic process to identify design-failmodes connected to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z"
- * special attention to "withstands defective DUT stress-cases" and "withstands miswire in the context of the test-equipment being integrated into field-wired industrial automation"
Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. The possibility space includes all the known weaknesses of the C language, for starters. The "CERT" guidelines can be starting point there.One difference in approach for the firmware vs hardware is that the failures-of-implied-functions for firmware are less dominated by the "withstands external-condition-X" pattern. Although there's some of that too, e.g. improper string input to the UART. But you also have things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets).- But those above are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices.
- Other helpful mentalities to reduce the combinations of the unpredictable in firmware, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it across the board due to the nature of the platform/language/stateful system. But it should be possible to structure the code so that like 90%+ is written in a style that facilitates verification and behaves consistently when parts of the system not directly connected to it are changing.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics seems to take a different pattern from that of the firmware. In both cases, besides the actual function of the device, the real challenge lies in demonstrating robustness, which can be idiosyncratic in both firmware and hardware, but in different ways.
- Implicit functions of hardware, IME, seem to be dominated by the pattern "withstands X Y Z". For an industrial setting, there are also common weak points related field wired hook ups (ie when your test equipment gets integrated into an industrial automation system on a production line, which commonly have field-wired terminal strip type construction in the control boxes). Special attention should be paid to these miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip).
- When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known test-fail-cases of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification - but do reduce if multiple DUT-production-failmodes result in the same production-test-failure, because the purpose of the OQ was to show the test-equipment function, which is catching the DUT-test-fail-case, regardless of which DUT-production-failmode caused it.
- To back up a little bit, the take-home of this might be that you should be clear (ie we're talking spreadsheets here) about:
- * what are the functions of the DUT, and of the test-equipment
- * distinguish between design-failmode and production-failmode, of both the DUT and test-equipment
- * aggregate DUT-production-failmodes into DUT-test-fail-cases
- * have a systematic process to identify design-failmodes connected to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z"
- * special attention to "withstands defective DUT stress-cases" and "withstands miswire in the context of the test-equipment being integrated into field-wired industrial automation"
- Returning to the firmware, you can apply the same principles, but attempting a generative approach with spreadsheets (systematically identifying failmodes), which is a huge chore but at least doable for the hardware, gets out of hand entirely for nontrivial firmware projects. The possibility space includes all the known weaknesses of the C language, for starters. The "CERT" guidelines can be starting point there.
- Previously mentioned difference in emphasis in implicit requirements between firmware vs hardware. For firmware, it's not as much dominated by the "withstands external-condition-X" pattern. Although there's some of that too, e.g. improper string input to the UART. But you also have things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), not corrupting your data in a million ways that C lets you do, not using uninitialized data, etc etc etc.
- But those above are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices.
- Other helpful mentalities to reduce the combinations of the unpredictable in firmware, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it across the board due to the nature of the platform/language/stateful system. But it should be possible to structure the code so that like 90%+ is written in a style that facilitates verification and behaves consistently when parts of the system not directly connected to it are changing.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
#19: Post edited
by
Pete W
·
2026-08-14T22:28:15Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. Other helpful mentalities to least reduce the combinations of the unpredictable, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it across the board due to the nature of the platform/language/stateful system. But it should be possible to structure the code so that like 90%+ is written in a style that facilitates verification and behaves consistently when parts of the system not directly connected to it are changing.- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known test-fail-cases of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification - but do reduce if multiple DUT-production-failmodes result in the same production-test-failure, because the purpose of the OQ was to show the test-equipment function, which is catching the DUT-test-fail-case, regardless of which DUT-production-failmode caused it.
- To back up a little bit, the take-home of this might be that you should be clear about:
- * what are the functions of the DUT, and of the test-equipment
- * distinguish between design-failmode and production-failmode, of both the DUT and test-equipment
- * aggregate DUT-production-failmodes into DUT-test-fail-cases
- * have a systematic process to identify design-failmodes connected to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z"
- * special attention to "withstands defective DUT stress-cases" and "withstands miswire in the context of the test-equipment being integrated into field-wired industrial automation"
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. The possibility space includes all the known weaknesses of the C language, for starters. The "CERT" guidelines can be starting point there.
- One difference in approach for the firmware vs hardware is that the failures-of-implied-functions for firmware are less dominated by the "withstands external-condition-X" pattern. Although there's some of that too, e.g. improper string input to the UART. But you also have things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets).
- But those above are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices.
- Other helpful mentalities to reduce the combinations of the unpredictable in firmware, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it across the board due to the nature of the platform/language/stateful system. But it should be possible to structure the code so that like 90%+ is written in a style that facilitates verification and behaves consistently when parts of the system not directly connected to it are changing.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
#18: Post edited
by
Pete W
·
2026-08-14T22:08:15Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. Other helpful mentalities to least reduce the combinations of the unpredictable, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it due to the nature of the platform/language/stateful system.- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. Other helpful mentalities to least reduce the combinations of the unpredictable, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it across the board due to the nature of the platform/language/stateful system. But it should be possible to structure the code so that like 90%+ is written in a style that facilitates verification and behaves consistently when parts of the system not directly connected to it are changing.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
#17: Post edited
by
Pete W
·
2026-08-14T22:05:56Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. Other helpful mentalities to least reduce the combinations of the unpredictable, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it due to the nature of the platform and language.- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. Other helpful mentalities to least reduce the combinations of the unpredictable, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it due to the nature of the platform/language/stateful system.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
#16: Post edited
by
Pete W
·
2026-08-14T22:05:01Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. The functional-programming mentality is helpful to at least reduce the combinations of the unpredictable, even if the actual implementation is imperative mood.- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. Other helpful mentalities to least reduce the combinations of the unpredictable, are the principles of functional decomposition (helps testability), encapsulation (reduces cross-interactions), and actual functional programming (guarantees testability in principle) even if you can't realize it due to the nature of the platform and language.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
#15: Post edited
by
Pete W
·
2026-08-14T22:02:59Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. The functional-programming mentality is helpful to at least reduce the combinations of the unpredictable, even if the actual implementation is imperative mood.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. The functional-programming mentality is helpful to at least reduce the combinations of the unpredictable, even if the actual implementation is imperative mood.
- Also since you mentioned it, mechanical relays can introduce electrical transients which if you're just starting out in designing this stuff, they can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... but that's its own subject.
#14: Post edited
by
Pete W
·
2026-08-14T22:01:57Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer and ), not having unbounded memory use (test: stack paint and guard, best-practice: no heap), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. The functional-programming mentality is helpful to at least reduce the combinations of the unpredictable, even if the actual implementation is imperative mood.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer), not having unbounded memory use (test: stack paint and guard, best-practice: no heap, possible practice: periodic resets), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. The functional-programming mentality is helpful to at least reduce the combinations of the unpredictable, even if the actual implementation is imperative mood.
#13: Post edited
by
Pete W
·
2026-08-14T21:57:25Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
Returning to the firmware, you can apply the same principles, but it gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer and ), not having unbounded memory use (test: stack paint and guard, best-practice: no heap), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- Returning to the firmware, you can apply the same principles, but attempting a generative approach (systematically identifying failmodes) gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer and ), not having unbounded memory use (test: stack paint and guard, best-practice: no heap), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices. The functional-programming mentality is helpful to at least reduce the combinations of the unpredictable, even if the actual implementation is imperative mood.
#12: Post edited
by
Pete W
·
2026-08-14T21:55:28Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- Returning to the firmware, you can apply the same principles, but it gets out of hand fast. One of the differences vs hardware is that the failures-of-implied-functions is less about "withstands external-condition-X" (although there's some of that too, e.g. improper string input to the UART), but also things like not crashing (test: clear-on-reset variable and watchdog timer and ), not having unbounded memory use (test: stack paint and guard, best-practice: no heap), and a myriad of arithmetic gotchas, many of which are included in the "CERT" guidelines for C programming for example. But these are all one-offs and and I haven't yet worked on anything with a comprehensive approach, since for better or worse the quality people I've encountered have all been too scared to touch the software and firmware side of things, and basically left the geeks to their own devices.
#11: Post edited
by
Pete W
·
2026-08-14T21:41:15Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes, aggregate production-failmodes into test-fail-cases, and have a systematic process to identify failures of implicit functions (e.g. functions which can be verbalized in the form "withstands X Y Z".)- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes of both, aggregate production-failmodes of the DUT into test-fail-cases, and have a systematic process to identify design-failmodes of your test equipment related to implicit functions, which are most often functions which can be verbalized in the form "withstands X Y Z".
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#10: Post edited
by
Pete W
·
2026-08-14T21:39:32Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own DFMEA. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes, aggregate production-failmodes into test-fail-cases, and have a systematic process to identify failures of implicit functions (e.g. functions which can be verbalized in the form "withstands X Y Z".)- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own design and analysis. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes, aggregate production-failmodes into test-fail-cases, and have a systematic process to identify failures of implicit functions (e.g. functions which can be verbalized in the form "withstands X Y Z".)
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#9: Post edited
by
Pete W
·
2026-08-14T21:38:38Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own DFMEA. In other words, the DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter).- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own DFMEA. The DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter). To back up a little bit, the take home of this might be that you should be clear about what are the functions of the DUT and the test equipment, distinguish between design and production failmodes, aggregate production-failmodes into test-fail-cases, and have a systematic process to identify failures of implicit functions (e.g. functions which can be verbalized in the form "withstands X Y Z".)
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#8: Post edited
by
Pete W
·
2026-08-14T21:36:23Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and test-fail-case is a matter for the DUT's own DFMEA).- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple DUT-production-failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and DUT-test-fail-case is a matter for the DUT's own DFMEA. In other words, the DUT's design failmodes can be thought of as either catching the DUT's production-failmode, or catching the DUT-test-fail-cases, which are subtly different, and there are fewer of the latter).
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#7: Post edited
by
Pete W
·
2026-08-14T21:33:58Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification).- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases and non-stress DUT-test-fail-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification, but do reduce if multiple failmodes result in the same production-test-failure. because the purpose of the OQ is to show the test is executed, whereas the connection between DUT-production-failmode and test-fail-case is a matter for the DUT's own DFMEA).
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#6: Post edited
by
Pete W
·
2026-08-14T21:19:00Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that the test equipment design survived it, caught the failure, and kept going normally -- repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT.- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, reduce them for symmetry (ie since there were multiple output lines of identical design), which resulted in qualitatively unique stress-cases that numbered slightly more than the number of connections, something like 10 vs 8p connector in that particular case. We then constructed physical specimens of the "bad" DUT's with each of those miswirings, to demonstrate that the test equipment design survived them, caught the failure, and kept going normally -- and this was repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT, as well as non-stress specimens of "good DUT" and "bad DUT" representing the known production-failmodes of the DUT (in that case not reduced for symmetry, since it was an operational qualification as well as a design verification).
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#5: Post edited
by
Pete W
·
2026-08-14T21:14:59Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that the test equipment design survived it, caught the failure, and kept going normally -- repeated for several specimens of the test equipment, each vs all specimens of the "stress-case-generating" DUT.
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#4: Post edited
by
Pete W
·
2026-08-14T21:11:57Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.
Also, mechanical relays also introduce electrical transients which if doing them for the first time can hurt both the relay drive circuit, and the relay itself is vulnerable to welding the contacts permanently closed-circuit if the load they're switching is driven carelessly ... so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.
- Also, mechanical relays also introduce electrical transients which if designing them just starting out, can stress both the relay's drive circuit, and the relay contact themselves can be overstressed by certain loads and are vulnerable to the contacts spot-welding themselves closed-circuit ... so that's its own subject.
#3: Post edited
by
Pete W
·
2026-08-14T21:10:25Z (about 1 month ago)
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.
Also, mechanical relays also introduce electrical transients that can hurt your circuit down the road or in unlucky set of conditions, and also can be more prone to welding themselves permanently open if the load they're switching is driven carelessly so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.
- Also, mechanical relays also introduce electrical transients which if doing them for the first time can hurt both the relay drive circuit, and the relay itself is vulnerable to welding the contacts permanently closed-circuit if the load they're switching is driven carelessly ... so that's its own subject.
#2: Post edited
by
Pete W
·
2026-08-14T21:09:01Z (about 1 month ago)
If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code. Big agreement with Lundin's answer about doing both "black box" verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan) and subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.
- Also, mechanical relays also introduce electrical transients that can hurt your circuit down the road or in unlucky set of conditions, and also can be more prone to welding themselves permanently open if the load they're switching is driven carelessly so that's its own subject.
- If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code.
- Big agreement with Lundin's answer about doing not only black-box design verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan), but also subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious.
- Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption.
- Also, mechanical relays also introduce electrical transients that can hurt your circuit down the road or in unlucky set of conditions, and also can be more prone to welding themselves permanently open if the load they're switching is driven carelessly so that's its own subject.
#1: Initial revision
by
Pete W
·
2026-08-14T21:07:54Z (about 1 month ago)
If the main function is logic and activation of on/off signals, and the number of output combinations and their timing needs are not prohibitive, The minimal test with actual mcu hardware, actual relays, and indicator lights to make visible the relay output. You could also use an oscilloscope with digital inputs, or any gpio device to record the outputs in more detail. You'd have to arrange whatever inputs needed to exercise all your code. Big agreement with Lundin's answer about doing both "black box" verification testing (ie as opposed to production testing, where you take for granted the design is robust if executed to plan) and subsystem verification testing, since it's just so common that black-box-only misses failmodes that could've been elicited at subsystem level. Beyond that you're entering into the world of DFMEA, which will make your designs better but also tremendously laborious. Design verification of the electronics is also very different from that of the firmware. Besides the actual function of the device, the challenge is demonstrating robustness, which is more idiosyncratic than in firmware land (IMHO). For an industrial setting, which implies field wired hook ups, special attention should be paid to miswire scenarios, including multiple failures (ie wires exchanged, line of connections shifted down on a terminal strip). When faced with this in the context of "operational qual" for a factory test equipment of a product which has with 24V "high speed" plc signaling, I took the time to generate all possible combinations of miswiring in its 8p connector (in that case, the miswiring originating from production errors in the internal wire harness of the DUT), identify the stress cases, of which there were slightly more than the number of connections, something like 10 in that case, constructed physical specimens with those miswirings, and at least demonstrate that several specimens of the test equipment design survived it and kept working normally without interruption. Also, mechanical relays also introduce electrical transients that can hurt your circuit down the road or in unlucky set of conditions, and also can be more prone to welding themselves permanently open if the load they're switching is driven carelessly so that's its own subject.