This one is both easy and straight forward to understand.
Do as much as possible in software.
But it doesn’t stop there. Do as much as possible in software at every stage of the development. Here is how that pans out:
- replace hardware with software that does the same function
- verify operation using unit tests and system tests within a soft environment
- do production test using on board software so the ATE is very simple
- do field diagnostics with on board software to make the diagnostics as cheap as possible
- do service and scheduled maintenance with on board software to minimise time and cost in these areas
- where suitable, use a bootloader to allow in field upgrade of the software
If you don’t already know, ATE = Automated Test Equipment.
The best thing about making software the core part of each of these areas, is that the manufacturing cost of software is effectively the jig and the time to program and test the parts. Automation can be expensive, but if the device contains it’s own automation, then the production process costs plummet. A simplified example:
You have a device with 8 inputs and 3 outputs. You want to test all the inputs and outputs to make sure they work. The traditional approach is to have a production ATE which applies known loads to test points and then measures against a series of scheduled tests which are controlled from one of the major production test equipment and systems suppliers. It is not unusual to spend $50K on such a system even for a relatively simple device. If you don’t believe; add up the software toolset costs, the man hours spent designing then building then coding then debugging then commissioning, the opportunity cost of those man hours and the materials costs. It really does all add up.
Electronics Manufacture – lets look at the alternative
The test jig merely connects the outputs to the inputs with the appropriate loads in place. The device is programmed with its own ATE code that then goes through the test process including requesting a serial number, and communicates the outcome back to the system which merely records the time, date, serial number, product version and test results. It doesn’t matter if the inputs are analog or digital, the same philosophy can apply. And if there is a big mismatch in the inputs and outputs, then put a simple multiplexer on the jig and let the unit manage it’s own test sequencing.
Another bonus: you update the system but the interconnections remain the same however the test sequence would have required altering the ATE software. No need! The on board ATE sequencer does it automatically and you don’t have to alter the production process at all. It even tells you it is the new product and you didn’t have to touch a thing.
Of course there are classes of products that do need more than this. Processes like burn in and quality metrics based acceptance testing. But these are the 5% cases. The alternative approach outlined above covers the other 95% and at a cost which can be orders of magnitude lower. And you can always add extra features to the test jig if required and still let them be controlled by the unit under test.
Yet another bonus: self calibration! The unit can calibrate itself based on the test results. No need to support multiple different calibration techniques at the ATE. It just says “I read X” and the unit under test looks at this value and what it reads and uses the one calibration process that applies to it.
And this features in one of our earlier posts on Strategies To Be More Profitable as it applies to Low Cost Electronics Manufacture in Australia.
Now I know this is simplifying it to its core essential elements, but that makes it easy to see the advantages and how much you can leverage them.
Less Electronics Hardware = Less Cost
The same applies to the other areas mentioned above. Removing hardware and doing the same work in software is pretty obvious. Less parts usually leads to less cost. Above we looked at production line ATE. And the same concept can obviously be applied to field and service diagnostics.
Field and service diagnostics
So here is another scenario. Imagine you have a customer with a pump that isn’t pumping. What to check first? Easy, the simplest thing to swap out is the pump controller. So you send them a replacement pump controller. They pull the plugs, remove the device, put in a new one, and send the old one back under warranty. You send it to the manufacturer. They test it and there is nothing wrong and send it back to you. But it’s pretty grubby and not suitable for resale as brand new. Well maybe their test process isn’t up to scratch and it really wasn’t working in the field. Anyway, it was still the thing to try first since anything else is a much bigger job to swap out. But now you’ve got all the hassle, a potential dispute with the manufacturer and the pump might still not pump with the new controller. The score is basically NIL all round for this. Everyone loses.
Now imaging this: the customer rings you and you ask them to go and press the orange button on the side of the pump controller. It says via it’s LCD “Check Valve Reversed”. Aha. Not a pump controller problem at all. The customer calls the plumber and gets him to fix the installation. Done. You look good, the customer got timely service and you sure are going to recommend this pump controller to the next customer ahead of the ones that don’t do this.
For each product category, the equivalent of the above 2 situation exists. So will your product look this good if the customer has an issue. It can if you think about it, and the cost might be trivial. It might even cost less at manufacture, but it will always cost less in the long run.
And of course, if the product can have its software updated in the field, that saves a lot compared to having to return it to the manufacturer. Orders of magnitude this time.
So that looks at parts cost, production process costs and support costs.
Reducing Development Cost
The second of the bullet points is looking at development cost. The up front cost to get a working product. We do a lot of work with small 8 bit and 16 bit microcontrollers and the development environments often don’t give you a lot of facilities to find faults. It’s the combinations that get you. Stop when input A is on, output B is off and the variable C is exactly 122 so I can look at what’s going wrong with my code. Or you might have to pay a lot for an emulator with all those features. And of course you have to put the hardware into the exact state you want as well. How do you do that again? That’s right, either sea of pots and switches or some clever and expensive hardware test equipment.
What we do a lot is build the project inside a software clone of the final system. In the software industry this is called a mock. Then we can use our standard PC coding and debugging tools to create scenarios and test against them. You can test your logic in an automated way and you can put every possible input combination in and make sure it responds correctly. Robert Bosch Australia Pty Ltd is one of our clients and we have worked on a number of projects for them. For those who don’t know, the volume of Australian Electronics Manufacture they do at their Clayton Facility in Melbourne is very impressive. They design, make and export millions of automotive electronic control units (ECUs) to Europe, Japan and the USA. And the body electronics supplied by Bosch to the rest of the world is designed and made there. Great stuff guys.
So a simple example of how we use this in our projects with them is a battery charging system we did which was all in software. You will find reference to it from one of our Linked In recommenders Dale O’Brien who saw the process in action. Basically, the full suite of tests took a week in real time, the primary test sequence required 54 hours, one test required sub-zero temperatures and none of this was 100% coverage. Using a software mock of the system we were able to do all the testing in 15 seconds including tests specifically to ensure 100% coverage. That’s roughly a million time faster. Debugging at light speed! So we were able to address the logic and algorithm issues quickly and efficiently and have a very high confidence in the system. Final verification in real time with final hardware and a normal test platform confirmed the operation but it was 6 months later. So maybe we were really 25 million times faster.
Don’t get me wrong, I firmly believe in testing on the final hardware. After all, assumptions are one of the greatest dangers we face. But at least prove you did correctly implement your solution within the assumptions you did make first. Then when you learn something new you are only fixing one problem and not arguing about whether it was the assumption or the test that is wrong.
I feel a bit like I got on my hobby horse over that lot. But I really do believe this can make a huge difference.
OK, time to go and design some more products for low cost electronics manufacture in Australia 
Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years. For more information go to his LinkedIn profile.
