[Technology Report]
My Embedded System Is On The Internet–What About Yours?
In the fight for seamless communications, embedded and information systems are joining forces and drawing upon the Net.
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.
Reprints
