Technology Selection
Before we look at how to choose a Technology, what does Technology mean?
In very general terms, Technology is understanding how stuff works and how to get it to do what you want.
There is lots of different stuff available. In the case of Electronics Design this stuff is the type of Electronics you will use and how you will make use of it. The most important choice to make is to determine:
- What functions will I implement using Electronic Hardware ?
- What functions will I implement using Embedded Software ?
- What functions will I implement using local or Remote Communications ?
- What does the user do?
- How is it powered?
- How is it packaged?
- Does it need to sense anything?
- Does it involve any chemical processes?
In looking at the answers to these questions I also need to consider:
- Cost to Design
- Cost to Manufacture
- Cost to support
- Production Volume
- Power Consumption
- Performance
- Time to market
In the process of Product Development it is often Technology Selection that can make the biggest difference.
Electronics Hardware
If there is no software involved, then this is the choice of which devices can be used to implement the design and how best to use them.
A recent example for us was the interface and power supply for a new GPS module for the Yarra Trams Passenger Information Systems. There was a problem with the existing GPS modules in scenarios where buildings either side caused the GPS module to lose position. And guess what you have a lot of in the central part of a city? That’s right, taller buildings. The Passenger Information Systems required an accurate GPS position to work correctly. So the GPS module had been selected including the use of dead reckoning to update the position based on the wheel rotation and the interface between this and the rest of the tram had to be designed including some level shifting to adjust voltage levels. We also manufactured the interfaces for them.
So that is an example of a project that required no Software.
But most of the time there will be Embedded Software involved. And there are several really good reasons for this:
- Embedded Software costs less in manufacture – see Reducing Electronics Manufacturing Parts Cost
- Embedded Software is extremely flexible
- Embedded Software can test itself
- Embedded Software improves field support, service and upgrade capability
- The Electronics Hardware to run Embedded Software gets cheaper every year
- Remote Communications is getting cheaper all the time
So today we spend 80% of our time writing Embedded Software in C and C++ to run on the Electronics Hardware we design through the PCB Prototype or even Production. This is known as an Embedded System.
For this typical project type we do as much in Software as we can.
Embedded Software
Embedded Software is the software that runs on the Electronics Hardware. Unless the product must be super Low Power Electronics, we will do everything in Software except for the power supply and physical interfaces to the outside world. But there are a few caveats:
- signal filtering is usually more power effective in Analog Electronics than DSP
- sleep and wake timing for high powered systems is often best done with external Electronics Hardware
- you have to be able to select a Microcontroller that has the right combination of price, features and performance
Given the enormous range of devices available today you would think the last point was easily covered but a recent project we did ended up with only 1 possible choice in the whole world for the Microcontroller. Here is the requirements list:
- Run from a button cell for at least 2 years
- Has a beeper
- Has an LED
- Operated from -20C to +70C
- After a period of dormancy, start flashing the LED and activating the beeper
- Beeper frequency, on time, off time, number of cycles and gap time are configurable
- LED on time, off time, number of cycles and gap time are configurable
- Dormant period is configurable
- Unit timing must be accurate to better than 1 hour per year
- Unit price in 100K quantities must be less than US$1
- Software must be protected from copying
The solution was an MSP430 based device from Texas Instruments with a 32KHz crystal. Actual cost ended up at US$0.71. And absolutely everything was done in Software.
Remote Communications
With ubiquitous Internet enabled devices, knows as the Internet of Things or IoT, it is more cost effective than ever to add Remote Communications to products. This can have many benefits that reduce the cost of field and service support for a product and also makes possible features you could not have provided any other way.
An example from a recent water metering project we undertook. This is a remote water dispensing system, also known as a Bulk Filling Station, that records who took water, how much water, when and where. The transaction is sent to a website via GSM modem and the Council can get the records to bill for the water without having to travel. It also means the tanker drivers don’t have to manually fill out log books and the Council don’t have to chase them for the data. Great savings there alone. But there were some extra benefits for us and the client that they hadn’t considered. These were:
- Remote updates to the system application
- Maintenance monitoring of batteries and valves
- Regular check in to confirm the system was still operational
So if a new feature is needed, we can update the software and remotely distribute it the units in the field. Since these are currently spread over half of the east half of Australia that is an enormous saving.
And we can also determine when the batteries need to be swapped out so that can be a preventative maintenance operation at a time of the Council’s choosing and not an emergency call out when a truck driver can’t get water. It is quite common for the first tanker to fill up before dawn when the solar charging has been off overnight and the temperature is at its minimum for the day. The worst timing from the batteries perspective so it just works better all round if we known for sure how the batteries are travelling by keeping track. It also means that if a solar panel is damaged the Council can see there is an issue before the system stops working.
And the regular check in allows the Council to know if a unit is still operational or not. A recent example from NSW was a fire fighting crew going to a water dispensing point to refill their tanker during a bushfire only to find it had failed sometime last winter and never been repaired. With Remote Communications you can avoid that and although it costs more to design, manufacture and operate (due to SIM costs) it can still reduce the overall cost of a system significantly.
So that is the general process. Once we have decided what we will do in Electronics Hardware, Embedded Software and how much Remote Communications to use we are ready to get into the Electronics Design in detail.
And of course, no post like this is complete without an input from Dilbert.
Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.