Virtually every embedded designer is looking to use digital communications to enhance or expand the reach of embedded systems. With new designs breaking ground and existing ones adding capabilities, the competition to develop the most compelling communications model is fierce.
The answer won't be found by looking at what others are trying to do. The "me too" approach was useful in providing alternatives to established products in the past. But it simply won't make the grade in product cycles measured in months, rather than years.
Engineers have to look to embedded communications architectures that might become viable in the future. They must examine the communications infrastructure, as well as existing and emerging standards for embedded systems and communications. New models for communications networks and embedded architectures also will have to be investigated.
Wireless protocols and standards comprise one enabling technology for the class of information appliances currently under development. That's a critical issue, because the full potential of mobile devices will depend on improvements in the digital wireless technologies needed to deliver high-bandwidth data to small portable devices. So far, the devices are arriving on the scene much faster than the bandwidth needed to support them.
But wire-based technologies are far from dead. They're actively vying for the lead in delivering data to an interconnected world. The telecoms have an advantage right now, with an array of medium and bandwidth options ranging from analog plain old telephone service (POTS) to T-3 and beyond with the optical carrier (OC) standards. But delays and misunderstandings remain common in the installation and configuration of anything with higher bandwidth than POTS. It also boasts a complex pricing strategy. So telecoms may not be best prepared to provide the communications infrastructure.
By taking advantage of that telecom infrastructure, some vendors have adapted copper wire to several different types of digital-subscriber-line (DSL) service. Currently, DSL technologies are being offered to commercial and residential customers as alternatives to POTS and ISDN. But the DSL signal has range limitations that prevent large parts of the potential user base from taking advantage of it. Plus, installing it in telephone-company head offices all over the country requires expensive equipment. Broadband through cable lines is growing steadily, but it's primarily a residential-only alternative.
High-End Systems Being Served Special-purpose networks are emerging, however, for those who can justify their own infrastructure. For high-end embedded systems, vendors like CETIA offer ATM networking for VME bus systems. Gigabit Ethernet interconnections also are available. Typically, these systems use networking to deliver streaming video or multimedia, or to multiplex a large number of data channels.Meanwhile, wireless standards for data communications are advancing. The latest specification to become available is the Wireless Application Protocol, or WAP. It can be built on any operating system and provides service interoperability even between different device families. WAP specifies two essential elements of wireless communication: an end-to-end application protocol and an application environment based on a browser.
The application protocol is known as the Wireless Transfer Protocol (WTP). It's a lightweight communications protocol that's based on TCP/IP and embedded in each WAP-enabled device. On the application side, there's a language called the Wireless Markup Language (WML). Derived from the XML meta language, it's designed for use on devices without keyboards.
The network side includes a server gateway implementing the other end of the protocol, which is capable of communicating with any WAP devices. This gateway handles requests from the device and goes out onto the Internet or other network to gather the requested data. It then formats the data and sends it to the device.
WAP presents an intriguing model for wireless applications. But not all devices need both the capabilities and the limitations of wireless communications. In reality, embedded communications will be some combination of wired and wireless. Wireless communications is simply too convenient, especially for mobile devices. Significant problems stand to be overcome, however, with both bandwidth and RF interference.
Devices will want to take advantage of the elaborate wire networks already in existence. They're likely to be fixed in the home or office, and will need a new or existing LAN to connect with one another, the gateway, and the rest of the entire world.
The Choice May Not Be Obvious Deciding on the method of communications for an embedded device will be one of the key initial decisions for product design. In some cases, such as mobile phones, the decision is obvious. But with products like home appliances or office equipment, the answer won't be so obvious. The choice between the two will likely be based on the availability of gateways and servers to provide access to all of these devices.An equally critical issue will be determining the amount of processing power and intelligence that resides on the device. Remember, these factors also will influence the network architecture. In the past, this was a straightforward decision because it figured directly into price and performance considerations. But in a future of internetworked servers and devices, the equation certainly becomes much more complex.
There are two fundamental models for building communications into embedded devices. The first is to put as little intelligence as possible into the device, and depend on most of the services and applications being provided by a server. Or, a full real-time OS can be incorporated on the device. It could be made to act as an intelligent client to a less powerful server.
The first model, probably best exemplified by EmWare's EMIT technology and its Embed The Internet (ETI) consortium, provides for cheaper information appliances. They'll need less powerful processors and less memory. EMIT, for example, can run on 8-bit microprocessors and under 1 kbyte of memory. Therefore, a type of networking can be built into a wide variety of everyday devices.
Traditional RTOSs As Well The latter model is represented by traditional RTOSs, such as QNX and Windows CE, which have full OS implementations right on the device. These systems can store data directly on the device and act as a full-fledged member of the network. But this reduces the pervasiveness of networking, because the technologies have such high computing requirements.The model that dominates will influence the extent of communications devices in the years to come. QNX and Windows CE require 32-bit processors and several megabytes of memory to fully implement communications on an embedded device. There may be major systems, such as automobiles or factory-control systems, that join the network to report operational and diagnostic data. But don't expect to see QNX running on a microwave oven.
EMIT can be implemented for pennies per device, though, which makes it possible to put basic communications into virtually any electronic device: refrigerators, microwave ovens, utility meters, and even vending machines. EmWare incorporates a lightweight proprietary protocol that connects a minimal device to an EMIT gateway (Fig. 1). That gateway, running a conventional server OS such as Linux or Windows NT, translates the EMIT protocol into TCP/IP for transmission of data across the Internet. In this regard, it works similar to the WAP discussed earlier on.
Another minimal solution is NetMedia's BasicX, a custom processor with both an RTOS and a subset of Microsoft's Visual Basic incorporated on the chip. The OS contains multithreading, interprocess communications, task management, a real-time clock, interrupt processor, event handler, and semaphores. With the VB engine, you'll typically write a VB program on a PC and download parts of that program to run on the BasicX.
Note that EMIT and other embedded technologies solve a difficult problem by turning the usual Internet model on its head. For traditional computing, the smaller system is typically the client. It runs the web browser to make requests on the network. In EMIT, the device is actually the server, with the ability to respond to simple HTTP requests. It's the other end of the network that makes those requests using larger and more complex browser software.
There's probably room for both thick and thin devices. More complex devices will need the services provided by a full RTOS, but they'll typically be limited to those that can justify a 32-bit processor. EMIT and WAP make it possible to network virtually everything, providing end users with the ability to at least query devices remotely. And keep an eye out for what might turn into a real dark horse in the operating-platform race (see "Will Linux Play An Embedded Role?," p. 102).
Joining IT And Embedded Worlds The only certainty is that embedded communications devices won't continue to remain separate from the enterprise computing infrastructure. Corporate databases, Internet service providers, and embedded systems are all converging into the same application spaces.For embedded developers, this translates into more dependence on traditional information technology than at any time in recent history. For engineers who have successfully resisted following advances in PC and server technology, this means a crash course in server application programming interfaces, object-oriented technologies like CORBA and COM, and relational databases.
The digital cell phone, for one, will become an extension of the enterprise information server, creating and uploading database queries and downloading regular production statistics. The device itself will be a special-purpose extension of the network, gaining many features from the network rather than itself. Look at the way QNX provides the ability to manage its systems through a Windows interface (Fig. 2).
This doesn't necessarily mean that the cell phone will run Windows or Unix and become a client as is understood today in client/server technology on the desktop. But it will force every device designer and embedded software developer to incorporate features with an enterprise or ISP server in mind.
It's already started. Relational databases, once the exclusive preserve of corporate information systems, are starting to make significant inroads into embedded-systems development. Sybase's SQLAnywhere and Centura Software's SQLBase are both targeting data storage and organization tasks for embedded systems. With its VxDCOM, Wind River Systems scales down Microsoft's DCOM technology so that it will suit embedded systems and then embeds it onto its Tornado II integrated development environment (Fig. 3). VxDCOM enables programmers to create fast and compact embedded applications that interact with PCs using Microsoft's distributed technologies.
Standards help a great deal in this regard, enabling design diversity without necessarily hindering interoperability. Take the family of protocols under the TCP/IP umbrella. It represents an almost universal standard
for packet-switched communications.
From an applications standpoint, some ad-hoc standards also exist. An e-mail client can have any look, feel, and features that make sense for the device, as long as it uses either the POP or IMAP protocols for communicating with the server. But choosing what standards to support can influence the overall design. POP represents a client-centric orientation, while IMAP is typically implemented through a server-based infrastructure.
Custom Processors Can Use Standards Standards may be built into custom-processor versions, ease the design process, and speed time-to-market. NETsilicon's NET+ARM is an integrated package that incorporates standard hardware and system software solutions. It's built around the ARM7 processor. NET+ARM includes a 10/100 Ethernet MAC-level interface, integrated cache, memory controllers, bus controller, timer and clock generator, and I/O.Problems do exist with the existing infrastructure that may affect the future viability of some standards, however. There clearly aren't enough IP addresses for each device to have its own. Only about four billion IP addresses reside in the traditional naming scheme, and some are reserved for specific uses. Typically, on traditional computer networks, addresses are dynamically allocated as they are required. But many embedded devices will require addresses at all times. IPng (also known as IPv6), which adds another triplet to the existing scheme, is being reviewed by standards committees. Unfortunately, possible embedded devices could overwhelm even this enhancement.
Here's where the minimal client approach might have an advantage. A proprietary interface between a set of clients and a gateway means that only the gateway needs an Internet addressing scheme, but each full TCP/IP client must have an address.
Solutions also exist that work to resolve issues with the full RTOS, including using a gateway that spoofs the network into thinking that a network segment is actually a single machine with one IP address. This product decision is largely based on the surrounding network architecture and various services available for individual devices.
For possibly the first generation ever of embedded devices, C and assembly language aren't automatically the best alternatives for application development. In the past, both languages offered the high efficiency and small executable footprint needed to wring the most out of an embedded systems' limited computing resources.
Today, Java's potential for cross-platform applications is making that language a mainstream alternative on embedded systems. Java is really the only choice for applications intended to be stored on a server and downloaded to an unknown client. Plus, the language and environment include network components that must be developed separately for other languages.
Some enterprising vendors have already found ways to use Java in cases where soft or possibly even hard real-time responses are required. NewMonics has its own real-time Java Virtual Machine (JVM). To enable that hard, real-time response, it's made a few extensions of the language to its clean-room implementation. Others have worked out ways to avoid invoking garbage collection, or have even enabled a just-in-time (JIT) native compilation on the device for faster execution.
Obviously, these imaginative initial solutions reveal that Java need not be relegated to a secondary role in the future. It has other advantages, too. The language isn't usually natively compiled, which enhances development because programmers can use desktop integrated development environments (IDEs). These offer more productive tools and new debugging technologies. Further, because Java doesn't directly allocate memory, the programmer is relieved of the error-prone task of managing memory use.
In other words, this language bears strong software-engineering credentials. Whether the code runs on a JVM without real-time capabilities, uses real-time extensions to handle time-critical tasks, or is natively compiled for speed, Java could possibly become at least as popular as some of those other old standbys.
Other languages do target the development of applications for communications-enabled devices. Embedded C++ compilers prohibit multiple inheritance, exceptions, and run-time-type identification. By doing so, they preserve the object-oriented capability of C++ while achieving the memory and execution efficiency of C. There also are a variety of special-purpose languages that are usually associated with a single platform. These include Visual Basic for Windows CE and Slang for QNX.
Performance and executable footprint haven't lost their importance. It's just that other factors now come into play when it comes to selecting a language for embedded applications. Say a language offers facilities for establishing and sending data along network connections. Or maybe it offers easy access to data or system resources. Then it becomes a candidate for employment in an embedded communications application.
The path to the future demands that engineers define and implement new design rules for products. Simple, inexpensive single-purpose devices with minimal processing power and software are unlikely to prosper. Yet the same goes for the powerful and costly general-purpose platforms that purport to do everything that a desktop computer can do.
Embedded systems, whether personal, in-dustrial, or office-oriented, will succeed with a combination of well-defined, built-in features. They'll also need the ability to do more through communications with a specific server or with access to the Internet in general. Finding the right combination will require input from many sources, and may still involve a large measure of luck.
Of course, none of this is guaranteed. Any attempts by vendors to break from some of the widely established standards, such as TCP/IP and XML/HTML, will fragment products and drastically slow adoption. Infrastructure difficulties, especially the ability of telephone companies to attractively price and field high-bandwidth data services, could change the outlook significantly.
Are there any design principles to be drawn from this vision of the future? Essentially, it's no longer important how many features can be squeezed into a given embedded platform. Tomorrow's product features will encompass not only what is on the device, but what can be accessed on the network. Design and implementation issues will center around what to incorporate on the device versus on the network, and how to best access those network services.
Don't forget that embedded communications systems will be tied inescapably to information systems. Whether you view your embedded device as a peripheral of the server, or the server as a data source for your device, there's no getting around interoperability with Windows and Unix. TCP/IP provides the bulk of this need. In order to configure and call the needed services, however, designers still must be cognizant of the capabilities of server-based operating systems.
Lastly, it won't pay to copy what someone else has done. The life cycle of products running on Internet time has grown so compressed that a lead of weeks is enough to assure the success of the first product. Time-to-market is critical, of course, but so is real product differentiation.
Embedded-systems design will be harder and trickier in the future, as designers look for the right way to package/partition both communications and product features between devices and network services. Yet there also will be more opportunities for innovation and creativity in the hundreds of new designs with different processors, applications, connectivity options, and form factors. It opens up a great opportunity for embedded designers and engineers seeking to field radical products and solutions.