 | Level: Intermediate Lewin Edwards (sysadm@zws.com), Design Engineer, Freelance
17 Oct 2006 Between IP litigation and ever greater demands for "baseline" functionality that requires licensing, developing new products has become a treacherous minefield for engineers to navigate. In this article, Lewin Edwards outlines some of the dangers which are making it harder for engineers to just get out there and build something.
Working in one of the engineering departments of an enormous
multinational company, I naturally hear a lot of water-cooler doom and
gloom about outsourcing. Specifically, I have frequently heard it said
that so much of America's design work is being outsourced that we will
soon have little or no domestic supply of engineering jobs. Our colleges
will cease to offer engineering degrees (since there is no demand), and
the knowledge of how to design and build machinery will pass forever
into the hands of our outsourcing partners. To borrow a peculiarly
apposite image from H.G. Wells, we will become the consumer Eloi, with
the rest of the world predatory Morlocks who both feed us and prey upon us.
I imagine our colleagues around European water coolers hear the same
sort of talk. This sort of thing irritates me to no end, because there are
much more important things than outsourcing to worry an engineer in the
twenty-first century.
In a recent book, I described this alarmist line of thinking as the
Malthusian school of thought, in a nod to Thomas Malthus (1766-1834).
Malthus famously predicted that the human population would expand
exponentially, outstripping the food supply, with catastrophic results.
He was wrong; thus far, technological advances have kept the total
potential world food supply well in excess of the needs of our total
world population. In my opinion, the Malthusian-style outsourcing
doomsayers are wrong as well, but certainly it is becoming progressively
harder to get into the engineering field. This is true both from the
perspective of an entrepreneur wanting to make a new product, or a
prospective engineering student simply trying to decide what to learn in
order to be marketable, and cramming all this knowledge into his or her
skull.
In this article, I rave at some length about the major barriers to
entry in electronic engineering generally and the embedded systems
development field in particular.
Intellectual property issues
The single biggest barrier to entry in product development, particularly
for the U.S. market, is intellectual property (IP) issues. Due in part (it
is said) to the privations suffered by tech firms after the dot-com
implosion, we live in a society of unparalleled IP-related
litigiousness. It should be no surprise to you that patents and other IP
disputes are a major business -- and for some technology companies, the only
profit-making business. All over America are erstwhile investors
who presently hold the worthless remnants of failed companies. Tucked
away inside many of these paper corporations is a dusty shoe box full of
assorted patents. Armies of lawyers are poring over these documents as
you read this, trying to determine if any extant product can be argued
to infringe upon those patents.
This sort of thing is typified by the brouhaha that has swirled in the
last four years or so concerning a patent (U.S. Patent #4,698,672,
commonly called "the '672 patent") that entangles certain parts of the
JPEG image-compression algorithm. Without getting into all the sordid
details, a patent was granted in 1986 on an algorithm that comprises an
essential facet of the commonly used JPEG file format. In 2002, the
present owner of that patent (it has changed hands a couple of times,
and remained in its shoe box all the while) discovered this potential
goldmine and began writing nasty letters in an attempt to extract cash
payments from more or less everyone who has ever decoded or encoded a
JPEG. (Something similar happened a few years earlier with the LZW
compression algorithm, patented in 1983, that was used in the GIF file
format -- the patent holder did, however, eventually back off trying to
collect royalties on what was then an industry standard. Plus ca change).
The '672 patent expires in October of 2006, and the USPTO (through the FTC)
is investigating the matter with a view to having the patent invalidated
anyway. Hence, by the time you read this, you might be in the clear on
that particular booby trap, but a million other
similar stories are just waiting to happen. Another recent headline news
item that's almost as egregious is the dispute between RIM and NTP over
technologies used in the BlackBerry PDA/e-mail device. Even though the
primary NTP patent was invalidated by the USPTO, RIM still paid out a
considerable sum to keep its production line running.
There exists an apocryphal "quotation," variously attributed (see Resources), that in the late 1800s someone quit his position at the U.S.
Patent Office because "everything that can be invented, has been
invented." While that silly situation will never happen, we are already
very close to the point where it's no longer possible to build any
practical device that doesn't rely on patented technology owned by
someone else. This is partly the inherent nature of science and
engineering; no sane engineer builds everything from scratch. He or she
will obviously use time-proven techniques and add whatever new
innovation the application requires. In theoretical science, all that's
necessary is to cite the proper references when you publish your
research, and there are no problems. When you're developing a commercial
product, however, big-money patent issues pop up. No product you will
ever make can possibly evade this tar pit.
The examples I've mentioned above are, at least, fairly nonmalicious. A
much worse situation exists with so-called "submarine patents," where
the patent holder deliberately suppresses information about the grant
(or intentionally delays the final grant) while observing the patented
technology become an industry standard. When the moment appears right
(for example, some large company such as Microsoft® announces a huge
commitment to develop software that requires the technology), out come
the lawyers and the demands for license fees.
The reason I bring up these IP issues is that as a small entrepreneurial
engineering company, you might not be able to afford detailed IP
searches for every product you intend to develop. Unfortunately, this
means that when you release a product, you're playing Russian roulette
with the gun held to your head for a very long time -- as much as twenty
years, or even longer. Large companies, which can afford to pay for full
searches, also have the option of either buying the patent in question,
or negotiating cross-licensing agreements with their own patent
portfolio; these luxuries are inaccessible to the small firm.
Sometimes you might not notice these IP issues, because they are more or
less invisible. For instance, oftentimes the license fees for a patent
portfolio will be silently included in the purchase price of your
components. (Even the jewel case you use to ship your promotional CD-ROM
to potential investors contains patented technology, and there are
royalties going to the stakeholders.) As a data point for you, something
like half the wholesale cost of those US$39.95 DVD players you see at
discount stores is swallowed up by royalties on the DVD patent portfolio.
One of the other reasons you're so likely to be bitten by a patent
problem when you build a product these days is that interoperability
with very recent commercial standards is much more important now than it
used to be. In the good old days, the only industry standards you
absolutely had to follow were very broad and mostly out-of-patent. For
instance, you might need to have a U.S.-style line plug on your widget
and the relevant circuitry to make it run off 110VAC mains. Apart from
those "big" standards, different companies had their own methods for
doing things, and it was possible for them to avoid treading on each
others' toes patent-wise and yet still offer saleable products.
Today, the software and protocol landscape is much more homogeneous than
it was twenty years ago. It might not always appear that way to a
developer, of course -- there are seemingly millions of new extant
standards, simply because computers and networks now have many
capabilities that didn't exist back in the 1980s. However, in a given
field (say, operating systems) there are usually only two or three
usefully popular standards, at most. If you want to attach to a modern
LAN, you'd be crazy not to support TCP/IP over Ethernet, not to mention
a commonly used higher-level protocol like SMB or HTTP. The fact that so
many players are implementing products on the same foundations increases
the chance that they are going to infringe on each others' IP rights.
Europe has made a step in the right direction by formally repudiating
the idea of granting software patents, but the definitions in this
legislation are non-obvious, and besides, many of these same issues
affect hardware designs also.
System complexity issues
Closely related to the latter point, another big barrier to entry is
that these immensely complicated modern systems contain a huge amount of
functionality (executed either in software or by the hardware of the
system) compared to their more elderly counterparts. It is a stated goal
of several large corporations to raise the barriers to entry in their
industry by training consumers to require more and more "free"
functionality as a baseline.
Consider an application like a cell phone. An old analog (AMPS) phone
typically ran on an eight-bit microcontroller. It had a keypad, a display so
you could see what you were typing, and some rudimentary operator
feedback enunciators like battery level and signal strength. All the
hardware had to do was send a small chunk of information up to the
tower, listen for return instructions, and then program the radio to use
a certain channel for transmit and a certain channel for receive.
A modern GSM cell phone is expected to negotiate amongst two or three
networks, possibly on different frequencies, and decide based on
information in your SIM card which network is cheapest to connect with
(for your service provider, not for you). The phone has to perform
elaborate encrypted authentication sequences with the SIM and with the
network. During the course of a call, it needs to encode your speech
with the GSM compression algorithm and transmit it; simultaneously, it
has to decode the downlink data stream and play it back into your ear,
all in real time. The controller has to monitor the charge state of the
battery during the recharge process -- improper software or hardware
design here can turn a lithium-ion battery into a small bomb.
The user interface is now a GUI of sorts, with a full-color screen --
many phones actually have multiple displays. A Java™ runtime is mandatory
so that third parties can sell us pocket-size applications. Many phones
have an internal camera, which requires control software and
compression/decompression codecs. Software widgets such as alarm clocks,
schedulers, contact managers, and so on are necessary. Polyphonic
synthesizers are used for ring tones. MP3 decoders are used for the same
purpose. Many phones have motion video codecs. Bluetooth and IrDA are
almost mandatory. An onboard USB interface is also required. Any company
that wants to offer cell phones to the U.S. market needs to have, or buy,
the know-how to implement all of these features -- otherwise it simply
won't be able to compete.
The increase in complexity is amazing and quite daunting. It's possible
for a one-person outfit to build a home-brewed AMPS cell phone out of
off-the-shelf parts. A GSM phone contains so much technology,
particularly software, that it's inconceivable that a single person
could build it all from scratch. Additionally, many of the components
required to implement such a device are application-specific standard
products (ASSPs) that are quite impossible for a small shop to acquire.
By the way, some people will argue with this last point. They will point
out that a huge amount of infrastructure IP (often free) is now
available to get your project off the ground, so the overall effort of
developing a new application might even be less than it was in the "good
old days." While it is certainly true that there exists a vast amount of
software and reference hardware design material available for free, or
at least a reasonable cost, I'll point out that this merely trades
engineering hours spent writing from scratch for engineering hours
integrating and testing. The testing effort required to certify correct
operation of a modern product is quite unbelievable (it increases
exponentially with a linear increase in the size of the system), and in
many cases skipping tests on "proven" components, particularly software
components, is foolhardy.
Speaking of software components brings up another barrier: the cost
of getting set up to develop with modern 32- and 64-bit microcontrollers
and their support components. Developing a completely custom hardware
platform based around a high-speed microcontroller is definitely a
non-trivial task, and it can't be undertaken using the old breadboarding
techniques used many years ago. The only real way to build such a
platform is to design a prototype PCB in the knowledge that you'll
probably have to throw away this first-round layout. Worse, you might
not be able to debug it with just an oscilloscope and a multimeter -- you might frequently need to employ a logic analyzer when tracking
down hardware bugs.
This isn't all bad news; the good news is that it's definitely much
cheaper to develop and debug on lower-end platforms now than it used to
be -- almost all the eight-bit parts (and most 32-bit parts, for that matter)
have on-chip JTAG interfaces, and there are cheap adapters available for
you to talk to these from a computer. Gone are the days when you needed
to buy a full in-circuit emulator.
However, developing the software certainly isn't cost-free either; you
need to acquire a compiler or assembler (or both), a debugger, and some kind
of debugging hardware. Not too long ago, this set of software and
hardware had a five-figure price tag, at least for the high-end
microcontrollers. As recently as 2003, many semiconductor vendors
wouldn't support you using anything other than a handful of proprietary
toolchains and operating systems.
I'd like to state that the pendulum has swung on this matter, but I
can't quite say it with a straight face (yet). Most of the popular
microcontroller architectures are indeed supported by the gcc compiler
(or a variant thereof). Semiconductor manufacturers have also
legitimized gcc, to a large degree -- particularly since it forms the
basis of several commercial toolchains. However, gcc by itself is not a
complete answer to the problem. Unfortunately, it's not as efficient as
the commercial compilers, and this really matters in a high-volume,
performance-critical application like a cell phone.
Conclusion
In summary then, I wouldn't worry too much about our colleagues in the
various outsourcing destinations of the world. The really innovative
made-in-your-parents'-basement products are far more threatened by the
various problems I've outlined above. I hope I haven't discouraged you
too much.
In the next article in this series, I talk about how the factors above, in
addition to other issues, have reduced the mean time between failures
(MTBF) and increased the mean cost of repair, even though everybody
"knows" that hardware today is cheaper and more reliable than it was in
times of yore.
Resources Learn
Get products and technologies
Discuss
About the author | | |
Lewin A.R.W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer. Prior to that, he spent five years
developing x86, ARM and PA-RISC-based networked multimedia appliances at
Digi-Frame Inc. He has extensive experience in encryption and security
software and is the author of two books on embedded systems development.
He can be reached at sysadm@zws.com.
|
Rate this page
| |
