EETimes

Embedded Systems September 2000 Vol13_10

Issue link: http://dc.ee.ubm-us.com/i/71837

Contents of this Issue

Navigation

Page 227 of 229

BREAK POINTS e It's easy to succumb to an arrogance of the office, where we lose touch with real customer needs, when we listen on the phone with but a single ear to a repair person in the field who is upset, while we make faces and wish only that the turkey would shut up. irrepa•-able system is extremely poor The Batelco employees scattered on these remote islands remove parts from their stock of other failed boards, swap- ping them as necessary to make things work. That pile of bad boards that no one could repair is a resource full of potentially good components. They live wi th essentially no stock of known good parts, since the head office believe that one spare board is enough; in their wis- dom, management figures new boards are just a mail boat away. Life in the field gives the lie to such easy drean1s, so these engineers develop strategies, like stock- piling failed boards, to deal with reality. This older technology is perfectly adapted for the low-tech area it's des- tined for. Can you imagine this engi- neer--or one of us-in some remote spot with few tools, n-ying to repair a typ- ical modern embedded product? One that's chock full of high-density SMT parts? With everything integrated into a couple of prop•ieta.ry ASICs, which, of course, are no longer available? Next time your cell phone fails, or when it' time to upgrade and your current model becomes another item on the technology junk heap, tear it apart. You'll be astonished at the pack- aging engineering. You' ll find one or two boards covered front and back with micro-components soldered prac- tical ly on top of each other. Without removing par ts I bet you' ll find that just closing the case up is difficult. One of the worst symptoms of our headlong plunge into ever more elab- orate and sophisticated technology is how • -apidly parts become obsolete. Though d1is Batelco system used 8085 micropmcessors that are still easily and cheaply available, most of our sys- tems use components which won' t exist in a year or two. I can't count the times people have called m- e-mailed me in despair over parts issues. Their product is just about done. Six to 12 months of engineering has yieldedju t the thing d1e boss wants and the company needs. Yet as d1ey go to market, one m- more integrated cir- cui ts, be they microprocessors, PLDs, or memory components, no longer exists. The "last buy" message comes from the vendor even before mese poor folks have shipped a single unit. The panic d1at ensues is for all of d1e wrong rea- sons. Developers go into a frenzy because they need to ship product, usu- ally forgetting that obsolete or near- obsolete components mean d1e system cannot be repaired in a year or a decade. Shipping is swell, but long term maintenance is critical. The kinder, gender days when ven- dors had second sources for parts, when they produced even low volume components for 10 to 20 years, are gone. Some of the semiconductor folks tell me d1e solution is to design every- thing into high-density FPGAs and PLDs. I've made that mistake, and found that FPGAs, fo r instance, go obsolete as fast as any other part. The newer replacement version is almost never pin-compatible wim its predeces- sor, necessitating a board redesign. Wimout pin-compatible replaceme nt parts, d1e poor sod in the field will need a reliable stock of spare boards. In some parts of the world board stocks will always be thin to non-existent. Seem to me that building an engineerin g. I do recognize tha t today's reali ty sometimes mean that repair is not an option, that a defective unit gets immediately tossed out. In this landfilled world d1at's scary, but it's a part of the way d1ings work, no matter how annoying. But if your sys- tem is destined for a place where such casual eli posal isn' t possible, design- ing things that way is foolish. As an engineer, you' re making choices every day that will impact me life of your user. Recognize that some economies don't operate as frenetical- ly as the U.S.'s, that sometimes repair is more important d1an features, size, and power consumption. It's easy to succumb to an arrogance of d1e offi ce, where we lose touch wim real customer needs, when we listen on the phone with but a single ear to a repair per on in the field who is upset, while we make faces and wish only d1at the turkey would shut up. As an engi- neering manager I learned to send the developers into the field, to let mem do some service calls, interact with the customer, and feel first hand just how much pain mese folks experience wid1 the products. Let each engineer get beaten up in person by unhappy clients. It's a sure way to make mem consumer advocates when they return, to give them a sense of what is really impon ant. So if your product is destined for more remote a reas of the world, design appropriately. Help your cus- tomer succeed despite the challenges of me local environment. esp Jack G. Ganssle is a lecturer and consul- tant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies spe- cializing in embedded systems. Contact him at jack@ganssle.com. EMBEDDED SYSTEMS PROGRAMMING (ISSN 1040·3272) ls publi!>hed monthly, wilh an additionalt~sue pubhshed in September, by CMP Medit1, 525 Matket St.. Ste. 500. San Francisco, CA 94105, (4,5) 905-2200. Please direct advertisrng and editonal mquiries to th1s addr~~ ~UBSCRIPTION RATE for the United State~ I'> S55 for 13 issues. Canad1an/Mex1can orders must be accompanied by payment 10 U.S. funds wrth additional po

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10