The How And Why Behind Internet-Enabled Embedded Systems

The use of TCP/IP-based communication protocols is not a new development. As the burgeoning success of the Internet attests, TCP/IP usage is widespread. Until now, the use of TCP/IP—particularly over the Internet—has been the domain of large and expensive server systems and resource-rich desktop-client machines. Even the developing market for Internet-enabled handheld computing is based upon powerful processors. Typically, those processors are embedded within devices that carry a price tag of several hundred dollars. Now, TCP/IP-based Internet networking is facing its next big development: the connection of large numbers of embedded systems featuring relatively low processing power. These low-cost embedded systems will use a thin-client model. While communicating over the Internet to central servers, they will perform a wide range of monitoring and control applications.

The benefits of remotely monitoring and controlling embedded systems have been evident for a long time. Yet one simple factor has inhibited the development and deployment of such systems—cost. For connectivity to be incorporated into an embedded system, it must invite benefits that outweigh the cost of its inclusion. For example, efficiency savings could be made possible by remote management or monitoring. Or, manufacturers could benefit from the ability to charge more for the final product, thanks to value-added features made possible by connectivity.

Until recently, the costs associated with incorporating connectivity into a system were high. Typically, no TCP/IP-stack software was available for the small 8- and 16-b microcontrollers used in embedded systems. Even if the software was available, the memory demand was usually prohibitive in both ROM and expensive RAM. Without the ability to 'talk' TCP/IP, companies had to look to proprietary network solutions in order to get their embedded clients connected to their servers. Obviously, the creation of such network infrastructures was difficult and expensive.

Fortunately, this is no longer the situation. Recent developments in software technology have made stacks available for the small, low-cost microcontrollers at the heart of many high-volume embedded systems. In addition, these stacks are ultra efficient. They allow TCP/IP-based systems to be developed for microcontrollers with as little as 16K of ROM and 2K of RAM. TCP/IP is the key that opens the existing Internet infrastructure, enabling it to be used as a network to connect embedded systems to their servers. The possibility of using the ubiquitous Internet as the transmission network removes a major potential barrier to the rollout of connected embedded applications.

With the introduction of TCP/IP-based connectivity into embedded applications, developers may have to get involved in areas of software functionality that they have never tackled. Typically, 'Internet programming' has been the domain of the desktop system programmer rather than the embedded-software engineer. When adding Internet connectivity to a product, it is essential that developers of high-volume, low-cost embedded systems remain true to the 'golden rules' of embedded-systems programming. Application development should focus on the conservation of scarce resources. Developers must not adopt the 'memory-no-object' style of programming that is prevalent among creators of desktop software applications.

To select an off-the-shelf TCP/IP solution for use in such systems, look at the credentials of the supplier as an embedded-systems solution provider. Do not think in terms of a networking or desktop pedigree. For embedded systems, there is little value in taking a UNIX-style TCP/IP stack and attempting to slim it down to fit the available resources. Such a choice will not meet the cost constraints that are inherent in high-volume deployments. It is best if the stack has been developed from scratch to meet the requirements of the applicable RFCs using sound embedded-engineering principles.

DISTRIBUTED RESOURCES Most applications that involve low-cost embedded systems communicating via TCP/IP will be designed to use the thin-client model. This model partitions the functionality of the application across one or many embedded systems and a number of desktop servers. To optimize the efficiency of the application, the system developer can therefore make best use of the available computing resources. Though such a concept may be new to embedded-systems developers, it has the potential to reduce the cost of a product while adding value to it.

When considering the thin-client model, the designer will need to evaluate the available system resources at both the embedded and server ends. The model enables designers to distribute resources. Through analysis, they also can focus on what can be implemented more effectively at either end. The resources required by each application will vary, but there are some key questions to consider: Can data storage and access be handled more effectively on a larger computer (server) rather than an embedded controller? What is the cost per byte to store large amounts of data? Will it be cheaper on a disk drive versus integrated-circuit memory? Also, can application management, data gathering, and dissemination be performed more efficiently via centralized storage?

Many factors affect the selection of connection hardware. The designer should consider what hardware is available locally at the embedded end. For example, if Ethernet is available with an Internet gateway, it could be used to connect to the Internet. As always, security is an issue. Invariably, various levels of security can be implemented in different ways. In some cases, higher levels of security will be more suited to implementation on a larger computer, which also acts as the centralized data store.

RESOURCE REQUIREMENTS Usually, embedded systems are required to use the minimum amount of resources possible. As a result, adding TCP/IP communication to the system must not increase the resources used by the system. Any TCP/IP software should use the minimum amount of memory and CPU cycles. It also should avoid interfering with the primary purpose of the system, which will often be to control some economically sensitive process.

It is almost inevitable that hardware will have to be added as a means of providing TCP/IP communication for a system. It could be a direct RS-232 link, a modem, or an Ethernet controller. Initially, using a gateway solution to separate the TCP/IP connectivity from the main embedded system may seem attractive. When considering the overall cost of the project, however, be sure to take into account the high per-unit cost of such devices, the extra development effort incurred in their use, and the lack of flexibility that they provide. A better solution is for the main system microcontroller to implement the primary embedded application and TCP/IP connectivity.

This microcontroller should have sufficient free code and data space for the TCP/IP stack, together with a means of interfacing to the chosen connectivity medium. To operate in single-chip mode, the Ethernet controllers that typically suit embedded systems will require around 16 I/O lines. A modem or serial interface will usually require a dedicated UART peripheral. Also, consider the provision of storage for nonvolatile data, such as IP and Ethernet addresses. A small EEPROM or similar device will usually suffice. A good embedded TCP/IP software solution will offer the developer complete control of all of these choices. Ideally, the solution will not reserve any hardware resources for its own use. At most, the user will need to choose a single hardware timer to provide a 'tick' to the TCP/IP stack. It can then perform time-based housekeeping.

INTERNET PROTOCOLS To implement its connectivity, an embedded application will need various Internet protocols. It already will have the core protocols, which form the basic packet-transmission layer. In addition, the stack will need the relevant application and datalink protocols that are necessary to implement the application. Usually, a commercially available product provides many types of protocols (FIG. 1).

The core protocols include the Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). IP is the base protocol that enables devices to communicate across the Internet. Every machine connected to the Internet has a unique IP address. This address is used to route IP packets, which contain data, around the network. Essentially, it is the job of the IP protocol to build, transmit, and receive these packets. IP is used to carry data that is sourced from higher-level protocols.

TCP provides a reliable, connection-oriented transport protocol for transaction-oriented applications. Each transmitted packet will be acknowledged by the receiver, thereby allowing re-transmissions to take place if a packet is lost. TCP is used by many of the Internet-application protocols that require a reliable, error-correcting transport layer. They can therefore ensure that data does not get lost or corrupted.

UDP, on the other hand, makes no provision for data loss. Packets are sent to a destination and no acknowledgment is expected. UDP is most often used with applications that make heavy use of broadcasts or multicasts. It also is commonly used with applications that need fast turnaround times on lookups and queries. UDP provides a low-overhead transport service for application protocols that either do not need or cannot use the connection-oriented services offered by TCP.

Finally, ICMP provides a mechanism that can be used by Internet devices when they need to exchange information about network problems. If a Web browser should request a non-existent Web page, for example, a suitable error message should be returned. ICMP also is used for the Ping utility. With this utility, it is possible to find out if a particular Internet host is responding to TCP/IP traffic.

As mentioned, application and data-link protocols also are needed by the stack to implement the application. These protocols include the following:

• Hypertext Transfer Protocol (HTTP) for serving Web pages
• File Transfer Protocol (FTP) for TCP file transfer
• Simple Mail Transfer Protoco (SMTP), which sends e-mail
• Simple Network Time Protocol (SNTP) for retrieving a timestamp from a remote server
• Trivial File Transfer Protocol (TFTP) for UDP file transfer
• Dynamic Host Configuration Protocol (DHCP), which leases IP addresses over Ethernet
• Domain Name System (DNS) for resolving IP addresses from URLs
• Ping, which responds to ICMP echo requests

Originally, these protocols were designed for use on desktop systems. For embedded-systems use, it may not be possible to provide a complete implementation of all of the features of a particular protocol. For instance, an FTP server can be used to hold predefined files on a data logger. It may not make economic sense, however, to enable new files to be uploaded to the device.

Once the connected-application designer is past the protocol hurdle, he or she must decide what datalink to use for the embedded system. A datalink comprises the hardware and software that allow data packets to be transmitted onto a network. Among the common datalinks are Ethernet and modems. An Ethernet datalink is essentially a controller chip with associated drivers. It also houses the DHCP and Address Resolution Protocol (ARP), which automatically maintain the link between IP and Ethernet addresses.

A modem datalink, on the other hand, consists of a modem device and its drivers. It may use either the Serial Line Internet Protocol (SLIP) or Point-to-Point Protocol (PPP). SLIP is more appropriate in certain situations—say, when the embedded system will have a fixed IP address. PPP is more useful where dial-up connections to an Internet Service Provider (ISP) will be made—especially because the ISP will allocate an IP address for the embedded system.

TCP/IP DATA TRANSPORT When data is transmitted over the Internet, it will pass through the various stages of the protocol stack. Starting at the application layer, data will then travel downward through the stack. At each layer, protocol-specific data is added to the application data, along with a header and checksum.

The major element wrapped in the Ethernet frame is an IP packet (FIG. 2). A TCP or UDP segment is wrapped inside that IP packet. This segment carries the application data. The Internet routers will deliver the IP packet to the destination address. At the destination, data will travel upward through the stack. The appropriate wrappers are removed at each stage. Finally, the data is passed up to the application layer.

A PRE-EMPTIVE OS In the embedded-systems realm, it is far from standard to use an OS in projects that feature 8- or 16-b microcontrollers. Frequently, operating systems are seen as overkill for embedded applications. Increased software complexity and resource usage are common complaints related to this issue. But using a well-designed operating system can bring several advantages. This is especially true when the use of TCP/IP for communication is concerned.

Traditionally, embedded systems are designed to use a cyclic scheduling approach. Their operation is broken down into a sequence of functions. These functions are repeatedly executed in an endless loop. This approach makes it relatively easy to analyze the required responses that the system must generate. It also is easier to implement the software so that the responses are generated at the correct time in each cycle of the control loop.

Of course, adding TCP/IP connectivity to a system makes this design approach somewhat more complex. By its very nature, TCP/IP is non-deterministic. Packets of data can arrive at any time. As a result, it is difficult and wasteful to allow time for the packets' processing in every cycle of the control loop. For a more efficient approach, use an operating system to schedule data processing upon the arrival of a packet. TCP/IP communication will then be kept to a minimum.

When using a pre-emptive OS, the application is partitioned into tasks. These tasks are analogous to the functions in a cyclic system. Each one has a priority. The operating-system scheduler will use that priority to determine the order in which the tasks will run. In the system, the highest-priority task that is ready to run will always run. It does not matter if this means halting or pre-empting a lower-priority task that is already running (FIG. 3).

When two tasks can block each other from executing, a problem arises that is known as priority inversion or deadlock. In response, the operating system should implement the Priority Ceiling Protocol (PCP). Using the PCP with a pre-emptive OS will ensure that the system will be free of deadlock and priority-inversion problems.

When TCP/IP is used with a pre-emptive operating system, each TCP/IP application protocol can be implemented using a task. In this way, the tasks will run only when they are needed for communication to take place. Other tasks, which make up the primary application of the embedded system, can have priorities allocated to them. In this way, the TCP/IP communication will not unduly interfere with the system's primary purpose. Without a pre-emptive OS, the TCP/IP communication could dominate the microcontroller. It would then prevent the embedded system from carrying out its primary purpose.

Aside from scheduling tasks, the OS should provide features that help to implement the application. Among these features could be semaphores for serializing accesses to memory and peripherals; alarms for time-dependent behavior; and pipes that communicate between tasks and mutual-exclusion (mutex) groups to control task pre-emption. In addition, the OS must be capable of dealing with all of the possible interrupts in the system. When interrupts are detected, the OS should run user handler routines. Interrupts may be controlled, which means that they have full access to OS features at the cost of some latency. Or, they may be uncontrolled. In this case, they have minimal latency but no access to the OS.

STATIC CONFIGURATION Most embedded systems that use an OS have a resource-constrained nature. As a result, they are well suited to static configuration. All of the OS features that will be used by the application are thus specified at the design stage. They can be configured appropriately using a PC-based tool. Once they are configured, there is no possibility of dynamically creating new features at run time. The total memory requirements of the system can thus be determined at build time.

When the designer knows the entire configuration of the system, he or she gets the opportunity to perform various optimizations. This is especially true when the TCP/IP stack to be used is designed to run on a pre-emptive OS. A suitable configuration tool can capture the necessary TCP/IP stack usage and operating-system features. It can then generate appropriate source code and data structures. The majority of data structures can be allocated to ROM. Only those that require run-time modification need to be placed in RAM. In this way, the RAM usage of the system is minimized. As much RAM as possible is left free for the embedded system's primary application.

Because the system is statically configured and no new features can be dynamically created at run time, the amount of API programming is much reduced. There is no need to create, initialize, and release OS features. The elimination of these functions reduces both the CPU overhead and the stack space requirements of the system.

Static configuration also offers another advantage: A lot of intelligence regarding the TCP/IP stack and the operating system can be built into the configuration tool. The developer can therefore focus on creating the primary application of the embedded system instead of learning the details of the TCP/IP software package. Suitable dialog boxes can assist the developer to quickly set up the necessary TCP/IP connections for an application. These connections can then be automatically mapped onto the required OS features. In addition, suitable source code is generated. These generated source files can be combined with the other files that make up the application. All of the files can be compiled and linked in the usual manner (FIG. 4).

PROGRAMMING TECHNIQUES By using a pre-emptive OS with a TCP/IP stack, the developer greatly simplifies the creation of embedded applications for the thin-client model. He or she can take advantage of TCP/IP and implement a connectivity scheme that is tailored to the application in question. It is likely that the application's server side has CPU resources that are several orders of magnitude higher than the embedded-client side. As a result, it makes the most sense to have the server perform any computationally intensive operations that may be necessary. The embedded client or clients can then be dedicated to the tasks for which they are most suited: monitoring, control, data logging, and so on.

Security is an important aspect of any system that relies on TCP/IP communication over the Internet. This is especially true when commercially sensitive data is being processed. Regarding the TCP/IP stacks that are suitable for 8- and 16-b embedded microcontrollers, it is unlikely that they will be able to implement any effective security measures to guard against hacker attacks. By their very nature, embedded systems are often designed to remain in the field for as long as possible without requiring code upgrades.

Hacking continues to become ever more sophisticated. In addition, the techniques used for hacking change rapidly. It is almost impossible for any countermeasures shipped with an embedded system to remain effective for long. Such measures will, however, consume valuable resources that could well be used for other purposes.

It is far more effective to design the complete system with security in mind. Computationally intensive security algorithms, such as Secure Sockets Layer (SSL), should be implemented on the server when the necessary resources exist. This security interface is the one presented to system users. It may, for example, allow a secure Web interface to be constructed. Communication between the server and its clients can then use the security techniques for which the embedded-systems side has resources.

One possible scheme involves generating an MD5 key of data. This data key is transmitted between the client and the server. MD5 can be performed efficiently even on 8-b microcontrollers. Any data will be transmitted in an unencrypted form. But the key ensures that any tampering will be evident. Further data from that client will be treated with suspicion. Off-the-shelf middleware software is available that performs the client and server ends of such a scheme. Such software may lead to greatly reduced development time for thin-client systems.

Another aspect of security for embedded thin-client systems involves the TCP/IP protocols used to perform the data communication. Most of the TCP/IP stacks sold for use in embedded systems will offer standard protocols, such as HTTP and FTP. These protocols are well understood. They can lead to a powerful and easy-to-develop Internet interface for embedded systems. Due to the fact that they are well understood, however, these protocols are vulnerable to attack. It may therefore be better to develop a protocol that is unique to the application at hand. The casual Internet snooper will not understand this protocol. It will therefore be less prone to data tampering, especially if combined with the MD5 keying technique described earlier. A well-designed embedded TCP/IP stack will make implementing custom protocols easy for the application developer.

In essence, a simple protocol will be no more complex than packing a number of data values into an array and sending this array over the chosen TCP/IP connection. In the configuration tool for the TCP/IP software, a connection can be defined as the following: using a specific port on the local system; a transport protocol (TCP or UDP); and a task in the OS that will handle incoming TCP/IP traffic to this connection. In the application code, the developer has to make calls to connect to a port on the server and send the data array. Upon reception of data packets from the server, the OS will activate the connection's handler task to process the incoming data. This task can perform any necessary actions that are encoded in the protocol. In this way, the internal workings of the TCP/IP stack and the underlying datalink are abstracted away from the application developer.

Adopting the thin-client model is an efficient way to add TCP/IP connectivity to embedded systems, even if they rely on 8- and 16-b microcontrollers and have limited memory resources available. Be sure to use an embedded TCP/IP software package from a supplier with good embedded-software credentials. Slimmed-down desktop TCP/IP stacks and operating systems are unlikely to offer the flexibility that is necessary for embedded-systems development.

A dedicated OS and a static-configuration tool can introduce many optimizations and efficiencies into the workings of TCP/IP-connected applications. To implement security in an application, partition the necessary functionality to where it makes the most sense in the system. Put heavyweight algorithms on the server and lightweight algorithms and custom protocols on the embedded thin client. Keep in mind that with existing off-the-shelf software packages, it's now possible to add low-overhead TCP/IP connectivity to embedded systems while achieving fast time to market.