Today it all seems obvious. Why shouldn't the office copy
machine email the repair guy when it needs service? Why not give
every robot on the factory floor its own home page where, using a
browser, the operations staff can remotely change settings or
perform diagnostics? Considering how obvious embedded networking
seems, why has it taken so long to arrive?
Three relatively recent events have enabled embedded networking
to advance. Each has vastly affected the economics of developing
and marketing embedded solutions. The first is a convergence on
networking standards, specifically TCP/IP and 10/100Base-T. Second
is the growing availability of off-the-shelf chips and custom ASICs
incorporating both CPU and networking components. The third is
software tools which support networking protocols in a real-time
environment. Until these three items fell into place, economic
success developing embedding networking solutions was unlikely.
Prior to the convergence of TCP/IP, computer manufacturers
developed proprietary, largely incompatible networking protocols.
Novell developed IPX; Apple developed AppleTalk; the Unix community
developed TCP/IP. If someone were looking at networking something
other than a computer, say a vending machine, they had to try and
determine which protocol to implement, or more frequently, how many
of them to implement. Choosing one often meant ruling out customers
of the others. With TCP/IP becoming a standard, an embedded
networking vendor no longer rules out a third or more of its
potential market by supporting a single protocol: TCP/IP.
How would one connect vending machines and copiers to the Net?
Using thick coax with vampire-bite taps? Around the country
thousands of networks are hooked up with every conceivable
topology. It's only recently that 10/100Base-T has become the
winner in the topology war. Today, almost all new buildings are
being wired with Category 5 wiring compatible with either 10Base-T
or 100Base-T. Virtually all NIC cards sold today are compatible
with 10/100Base-T. An embedded networking vendor doesn't have to
develop multiple versions of its product to support multiple
The next obstacle to embedding networking was embedded computer
hardware expense. To develop a high-end networking controller, one
would typically need to purchase some sort of PC on a board,
effectively spending $300-400 in order to assemble an Ethernet
solution. If you couldn't afford that, then you would need to
select a microprocessor, assemble all the support chips, add an
Ethernet chip and design a PCB incorporating the 100+ resistors,
capacitors and chokes that traditionally accompany such Ethernet
chips. The hardware to connect to Ethernet varied from as little as
$80 to as much as $300 or $400 for a PC board-based platform.
Had a company been lucky enough to select TCP/IP, 10/100Base-T,
and settle on an HTTP server, it would still face the complexity of
doing the hardware/software design and integration. Unless you were
going to buy a pre-built PC board, you had to engineer the board,
as well as write an Ethernet driver, which is not a trivial task.
If you planned to assemble your own solution, you'd need to hire a
networking expert, or else you would learn a lot of expensive
lessons doing it yourself. Imagine you'd selected TCP/IP.
Implementing TCP/IP requires the implementation of several smaller
protocols which run along with it. For instance, BootP, DHCP, and
ICPM. Most people are unaware of these protocols' existence, but
they're absolutely necessary to run any sort of TCP/IP system.
BootP and DHCP are used to acquire your IP address. Without an
IP address your device cannot even speak on the network. ICPM is
also known as PING, and is commonly used by network administrators
to detect whether a device is alive or broken. Telnet allows you to
establish a serial connection to a device, as would be necessary
for command and control. Then you've got FTP, perhaps to download
new code to EEPROM or NVRAM in your device, and mail protocols,
which the device could use for notification and alerts. Many people
wanting to embed networking are not networking experts. They are
experts in building robots, vending machines, copiers, and so
forth. The diversity of potential networking problems can quickly
become overwhelming. The problem is compounded because many
embedded networking "solutions" currently being offered, are, in
fact, quite incomplete.
Software tools were the final enabling technology. Specifically,
RTOSs (Real-Time Operating Systems) began adding networking
support. Initially networking extensions like TCP/IP and NFS were
added to enable communication between the RTOS host (development)
computer and target systems. Later, developers began applying these
extensions to create Internet fluency within their products. The
ability to use a commercial RTOS provides performance, reliability,
and time-to-market advantages over coding your own solution. RTOS
vendors offer some of the needed TCP/IP stacks, and optionally
supply HTTP servers. Third party vendors have begun supplying other
Internet protocols and development tools.
A company can now choose a suitable microcontroller, select a
networking-fluent RTOS, add some protocols from a third party,
integrate, and end up with a complete embedded networking solution,
sometimes referred to as a "thin server" or embedded Internet
device. Still, most they would have to make many design decisions,
integrate all the pieces, debug their design and networking code,
and provide long term support. Even with today's tools and software
components, many companies have come to the realization that it is
preferable to purchase a complete solution with all the engineering
and integration already done. For many, the solution is one chip,
with all the networking debugged by someone else, and with room to
add custom code in external RAM/ROM. This gives manufacturers the
opportunity to add value where they have expertise and market
knowledge, rather than having to develop expertise in RTOS
development, networking, and other technical details.
Osicom's NET+ARM product is the first offering in this class of
product, an embedded networking solution. NET+ARM incorporates all
the hardware and software needed to embed networking. Users need
only add external RAM/ROM to their device, be it a vending machine,
robot, or copier. Hardware built into NET+ARM includes a 10/100MAC,
32-bit RISC µP, memory controller, interrupt controller,
timers, etc. NET+ARM also includes complete networking software
with a choice of RTOS kernel, TCP/IP support, complete HTTP server,
drivers, and APIs that integrators can use to build their custom
applications. Development tools even include a form of in-circuit
One of the first applications for embedded networking was in
networked laser printers. Users wanted to be able to remotely check
on the status of a printer down the hall, determine whether it was
turned on, out of paper, and so forth. The intensely competitive
market for laser printers demanded an ever-lower cost solution to
embedded networking. Eventually market forces demanded a single
chip solution, and NET+ARM was born. Recognizing a general solution
disguised as a chip for printers, Osicom engineers removed features
specific to printers, added general purpose interfaces, and
designed a development board for use by customers.
Fast forward to where this technology could lead. When you drop
a package in a FedEx dropbox, the dropbox will automatically get
added to the driver's route. Coke machines will signal the
dispatcher they need refilling. The Maytag repairman will patiently
play Solitaire while waiting for email from a washer or dryer in
distress. What will make all this happen? Integrated solutions
based on systems on silicon that reduce both the cost and
complexity of embedded networking.
NET+ is a trademark of Osicom Technologies.
ARM is a registered trademark of ARM Holdings.