Consider the architecture of the common hammer: a handle attached to a clawed head. Your average hardware superstore will carry a hundred variations on this theme, with differing combinations of weights, lengths, compositions, grips, head shapes, and claw styles. You can pay a small fortune for a state-of-the-art, counter-weighted, rubber-gripped,
titanium-alloyed framing hammer, or you can pay $8.95 for a basic wooden-handled household model. You can use a hammer in a thousand different ways, from driving nails and prying wood to digging holes and mashing thumbs. You can build a million things with a hammer, and can use the same hammer to tear them all down again. Yet for all of the hammer's variety of form and diversity of function, its architecture remains fundamentally the same: a handle attached to a clawed head.
Imagine embedded communication
devices as simply high-tech hammers. For all of their variation of form and application, these devices perform the same basic function of allowing two independent entities to communicate in a meaningful fashion. It is little surprise, then, that the software architectures of embedded communication devices tend to be variations on a theme, containing a remarkably common set of elements. This article examines these common elements in some detail.
Basic architecture
When it comes to embedded communication device architectures, there are as many possible variations as there are developers and applications. A common set of elements, however, tends to appear in a great many architectures.
Figure 1
illustrates the basic software architecture of a hypothetical embedded communication device. A couple of the elements are more or less unique to embedded communication devices, while the rest can
be found in some form or fashion in any number of embedded applications. Within a communication device, however, even some of the more mundane elements tend to adopt a communication-oriented flavor.
Protocol stack
The heart of any communication device is its communication protocol stack. A protocol is simply a set of rules and behaviors that govern how two or more entities engage one another. Our everyday lives
are permeated by protocol. We try not to interrupt when someone is talking. We are admonished not to yell "Fire!" in a crowded theater. When two lanes of traffic converge, we try to take turns merging. Violators of the lane-merging protocol are often subjected to a sign-language protocol that indicates severe disapproval. All types of communication are subject to some form of protocol. For a device to communicate with any other entity, it must know at least one communication protocol, and it must hope that
the targeted entity knows that same protocol.
Modern communication protocols are built upon the principal of client-server layering. Layers are "stacked" on top of one another to form the protocol stack. Each layer has a distinct responsibility within the protocol, and each layer provides services to the layers above while obtaining services from the layers below. This principle has been standardized in the Open Systems Interconnect (OSI) model, which defines seven layers of general protocol
responsibility (see
Figure 2
). Most standardized communication protocols roughly mirror some portion of the OSI model.
Embedded communication devices typically provide some portion of layers 2 and 3 in software. With the explosion of Internet Protocol (IP)-aware devices, higher layer functionality is becoming commonplace in embedded systems, such as that of layer 4-Transaction Control Protocol (TCP).
Layer 1 is typically implemented in hardware due to
prohibitive processing and electrical signaling requirements. But the line between hardware and software with respect to layering has become blurred. Special communication processors may perform many upper-layer functions in hardware, while many layer 1 functions may be performed in software. For example, a network processing unit (NPU) may perform portions of all seven layers in hardware, while a digital signal processor may perform some layer 1 functions in software.
The primary purpose of the lower
layers in a protocol stack is to establish and maintain a physical, logical, or virtual connection suitable for the reliable transport of upper layer information. The primary purpose of the upper layers is to transport information relevant to the application of the transporting entity. At any layer, various communication-oriented activities may occur, such as security checking, error detection and correction, flow control, flow multiplexing, address conversion, and any number of other functions.
The process of
establishing, maintaining, and releasing connections is inherently an event-driven process, in which a protocol layer requires some event to occur to proceed to the next step, or state, in the protocol. As such, these layers can be implemented as event-driven state machines.
Figure 3
depicts an extremely simple layer 2 state machine that establishes a connection, forwards data, and releases the connection based on indications and directives from layers 1 and 3, respectively.
Based on the sequential nature of this link control protocol, it can be seen that a state machine is an appropriate mechanism for implementing the protocol behavior.
Communication control
The communication control element is a generic container for the application or control functionality of the communication device. It may be an intelligent application that uses the protocol stack to communicate with a peer
entity on another device; it may be a bridge between the protocol stack and another protocol stack; it may be an interface between the protocol stack and a user; it may be an interface between the protocol stack and another application or device. No matter what its function, the communication control element effectively acts as the top-most layer of the protocol stack. The protocol stack becomes a service-provider to the communication control element. Like the protocol stack, the communication control element
tends to be event driven, and can be implemented as an event-driven state machine.
Data transport
The common denominator for any set of communication devices is that they all transport information to and from peer devices. In some cases, the volume of information is limited enough that the software can afford to construct every bit of the information sent and analyze every bit of the information received. It is
more often the case, however, that devices must transfer massive quantities of information in real time, such as voice, video, or Internet protocols. General-purpose microprocessors are typically ill-equipped to handle the raw processing requirements associated with such high data rates.
To accommodate the need for additional data bandwidth, the trend is that more of the protocol is being performed in communication-specific hardware logic, where maximum throughput can be attained. More
microprocessors contain built-in hardware peripherals that assist with the compute-intensive aspects of data transport. For example, because HDLC, which is a standardized layer 2 link control and data transport protocol, has been incorporated into numerous protocol stacks, many microprocessors provide HDLC assist logic that frees the software from the real-time strain of HDLC data transport. Other solutions include the use of communication-specific processors that are specially equipped to handle the activities of a
protocol or a family of protocols. For example, the communication industry is experiencing the rise of network processors that can be programmed to perform several networking protocols at hardware speeds.
Regardless of the type of hardware assist, the communication device's software effectively becomes a controller of data transport hardware logic, rather than performing the data transport directly. This control usually consists of setting up (programming) the hardware to transport data, and having
the hardware notify the software when something of interest occurs. Interesting information might include the appearance of an important piece of data, such as a device address, the occurrence of an error, the crossing of a threshold, or any number of things that require software attention. This "set-up-and-notify" approach allows a massive volume of data to be transported with minimal intervention from the software. The data transport is typically initiated and controlled by the protocol stack as it walks
through its various states.
Since the data transport is generally hardware assisted, the data transport control is typically implemented as a hardware device driver. The driver provides hardware access functions as well as hardware interrupt service routines.
Figure 4
depicts a general driver model not unlike that of any embedded application. The access functions are used for programming and controlling the data transport hardware, such as configuring the hardware to perform
data transport in a specific way, setting up interrupts, or initiating the flow of data. The interrupt service routines are used for processing interrupts from the data transport hardware, such as those indicating the receipt of interesting data or the occurrence of error conditions or threshold crossings.
Management application
Contemporary aircraft are equipped with an abundance of automated control mechanisms
and can fly great distances with little or no manual intervention. However, few of us would be willing to climb aboard an aircraft that didn't have a human pilot, because we understand that manual intervention is often needed to adjust the flight of the aircraft to changing conditions. In the world of embedded communication devices, the ability to manage a device in the face of changing conditions is often one of the most overlooked and underestimated aspects of device architecture. Many communication devices
are deployed with essentially only auto-pilot capabilities and experience degradation of performance as the environment changes. An adequate management interface is therefore needed to allow a device to be adjusted in response to changing conditions.
A management interface allows an external source, such as a management system or human user, to monitor and modify the operation of the communication device on the fly. Typical management activities include:
- Configuration-setting device parameters that affect the device's run-time behavior
- Performance monitoring-collecting information concerning the performance of the device, which may prompt reconfiguration
- Usage monitoring-collecting information concerning the usage of the device
- Fault monitoring-collecting information concerning the faults, errors, and warnings related to device operation
- Diagnostics and test-prompting the device to perform self-diagnostics and tests, and reporting the information to
the management source
The management-related information is typically exchanged between the device and the management system by way of a management protocol. The management protocol can be carried over a dedicated physical interface, such as a serial port to a command terminal. More often, however, the management protocol becomes a user of a device's communication protocol stack. In this case, the management protocol messages are multiplexed with other data being transported over
a device's existing communication interface.
The management interface performs a number of functions, so it may be implemented as a group of sub-elements.
Figure 5
illustrates a possible implementation of a management interface. The sub-elements include:
- Management protocol agent-The management interface must execute a management protocol to communicate with the external management system. This sub-element acts as the protocol agent for the other
management sub-elements, and hides the details of the management protocol from them. It can be implemented as an event-driven state machine, just as other protocol-oriented elements are
- Configuration manager-This sub-element maintains the configuration data in a data store and/or passes the data to the appropriate elements of the communication device
- Performance monitor, usage monitor, and fault monitor-These sub-elements access the performance, usage, and fault information from data stores
and/or the other elements of the communication device, and report the information through the management protocol agent to the external management system. In addition, the other elements of the communication device may autonomously request that the monitor sub-elements send updated information to the external management system
- protocol agent to the external management system
The manager and monitor sub-elements may be implemented as functions or methods, but may require state machine behavior, depending on the complexity of their interactions with other elements in the communication device.
Most embedded communication devices, by virtue of their purpose in life, are part of an often far-flung
network of communication equipment that must provide reliable service. To require a site visit every time a communication device or a section of the network exhibits erratic behavior can be prohibitively expensive to the network provider. It is imperative, therefore, that the network administrators be able to diagnose problems remotely and be able to make appropriate adjustments remotely when possible. To this end, embedded communication devices require robust self-diagnostic and test capabilities.
Furthermore, the management protocol should provide an avenue whereby the diagnostics and tests can be executed remotely and the results retrieved. The management interface working over the communication protocol stack can provide this avenue.
Diagnostics required by an embedded communication device are similar to those required by any embedded device, including tests to diagnose the health of the various hardware and software components in the device. The differentiating feature of an embedded communication
device, however, is that it is a node in a communication path that may traverse multiple communication devices. If the communication path fails or begins to degrade, it is of utmost importance that the network provider be able to remotely identify the point of degradation or failure and take corrective actions. This is typically realized through the liberal use of loopback points.
The loopback point, which allows a signal to be looped back to the sender for verification, is a tool commonly used
in embedded applications to verify the signaling between any two points. In embedded communication devices, the loopback is employed at the communication path level in order to diagnose the point of trouble. When communication path failure or degradation occurs, the diagnosing device can begin by activating a loopback at a nearby point in the communication path, sending data and verifying that the data sent is correctly received. If the data is correctly looped back, the diagnosing device can activate a
loopback farther down the communication path and repeat the test. The diagnosing device repeats this procedure until it is unable to activate a loopback or the looped-back data is incorrectly received, effectively isolating the point of failure.
Figure 6
illustrates a hypothetical loopback configuration.
Every communication device should contain at least one communication path level loopback point, implemented in either hardware or software. Multiple loopback points per
device give the network provider greater ability to isolate failures.
Support elements
The board support package (BSP), real-time operating system (RTOS), and application framework are elements found in most embedded systems in some form. In the context of embedded communication devices, these elements may provide some specific capabilities tailored to communication applications.
The BSP provides boot-up
services, as well as access and control of hardware through device drivers and interrupt service routines. In a communication device, the BSP may include one or more device drivers for accessing hardware that performs part of the protocol behavior. The data transport control element can effectively be part of the BSP. In cases where a specialized communication processor provides support for several layers of the protocol stack, the BSP communication device driver suite can be quite extensive. As with the data
transport control device driver, the BSP device drivers can be implemented as a combination of access functions and interrupt service routines (see
Figure 7
).
The RTOS provides a set of embedded OS services, such as tasking/scheduling, memory management, timer management, queuing, message handling, and semaphore handling. An off-the-shelf RTOS is generally application agnostic, so the fact that it is providing services for a communication device is hidden from the RTOS. A
home-grown RTOS, however, can be tailored to support protocol activity. For example, the message handling can be expanded to support the message structures used for the protocol messaging.
The application framework is a catchall for various library-like services that are necessary to support embedded operation. Typical services may include RTOS abstraction, RTOS extension, state machine control, resource management, BSP abstraction, and common library services. In a communication device the application
framework may provide special protocol-oriented services, such as CRC calculation, protocol message building, address resolution, and many other common functions.
Simple and painless
The architecture I've presented has highlighted some common software elements of embedded communication devices. Although less elementary than a handle and a clawed head, this architecture is simple enough to be applied to virtually
any type of embedded communication device, and it spares the thumbs to boot. esp
David Nix has been developing telecommunications software for 12 years with several different companies including AT&T Wireless, AMD, and Motorola. He has recently joined a startup company, Agere, Inc., in Austin, TX, to perform systems software engineering and build reference designs for network processor chipsets. He can be reached at
nix@agere.com
.
