Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 1 of 8

Part of the EE Times Network

Top news from EE Times:

Alcatel-Lucent squeezes 300-Mbit/s from DSL

All

Articles

Products

Course

TechPaper

Webinars

Login | Register Welcome, Guest

HOME

DESIGN

FORUMS

E-LEARNING

PRODUCTS

Thursday, June 10, 2010

Guide to Embedded Systems Architecture - Part 1: Defining middleware

Part 1 of an excerpt from the book "Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers" begins by defining "middleware" and
looking at some networking middleware driver examples.

The line between middleware and application software is blurred, which is why this chapter introduces both together. Middleware is software that has been abstracted out of the
application layer for a variety of reasons. One reason is that it may already be included as part of the off-the-shelf OS package.

Other reasons to remove it from the application layer are: to allow reusability with other applications, to decrease development costs or time by
purchasing it off-the-shelf-through a third party vendor, or to simplify application code. The remaining sections of this chapter define what
middleware and application software is or isn't, and provide real-world pseudocode examples of middleware and application software.

10.1 What Is Middleware?

In the most general terms, middleware software is any system software that is not the OS kernel, device drivers, or application software. Note
that some OSes may integrate middleware into the OS executable (see Chapter 9). In short, in an embedded system middleware is system
software that typically sits on either the device drivers or on top of the OS, and can sometimes be incorporated within the OS itself.

Figure 10-1: Middleware within the Embedded Systems Model

Middleware is usually the software that mediates between application software and the kernel or device driver software. Middleware is also software that mediates and serves
different application software. Specifically, middleware is an abstraction layer generally used on embedded devices with two or more applications in order to provide flexibility,
security, portability, connectivity, intercommunication, and/or interoperability mechanisms between applications.

One of the main strengths in using middleware is that it allows for the reduction of the complexity of the applications by centralizing software infrastructure that would traditionally
be redundantly found in the application layer. However, in introducing middleware to a system, one introduces additional overhead, which can greatly impact scalability and
performance. In short, middleware impacts the embedded system at all layers.

There are many different types of middleware elements, including message oriented middleware (MOM), object request brokers (ORBs), remote procedure calls (RPCs),
database/database access, and networking protocols above the device driver layer and below the application layers of the OSI model. However, most types of middleware commonly
fall under one of two general categories:

• general-purpose, meaning they are typically implemented in a variety of devices, such as networking protocols above the device driver layer and below the

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 2 of 8

application layers of the OSI model, file systems, or some virtual machines such as the JVM.

• market-specific, meaning they are unique to a particular family of embedded systems, such as a digital TV standard-based software that sits on an OS or JVM.

Whether general purpose or market-specific, a middleware element can be further categorized as proprietary, meaning it is closed software supported by a company that licenses it to
others for use, or open, meaning it is standardized by some industry committee and can be implemented and/or licensed by any interested party.

More complex embedded systems usually have more than one middleware element, since it is unusual to find one technology that supports all specified application requirements. In
this case, the individual middleware elements are typically selected based upon their interoperability with each other, so as to avoid later problems in integration.

In some cases, integrated middleware packages of compatible middleware elements are available commercially, off-the-shelf, for use in embedded systems, such as the Sun
embedded Java solutions, Microsoft's .NET Compact Framework, and CORBA from the Object Management Group (OMG), to name a few. Many embedded OS vendors also
provide integrated middleware packages that run "out-of-the-box" with their respective OS and hardware platforms.

Section 10.3 of this chapter provides specific real-world examples of individual middleware networking elements, as well as integrated middleware Java packages.

10.2 What Is an Application?

The final type of software in an embedded system is the application software. As shown in Figure 10-2, application software sits on top of the system software layer, and is
dependent on, managed, and run by the system software.

Figure 10-2: Application layer and Embedded Systems Model

It is the software within the application layer that inherently defines what type of device an embedded system is, because the functionality of an application represents at the highest
level the purpose of that embedded system and does most of the interaction with users or administrators of that device, if any exists. (Note: I say most because features such as
powering on or off the device when a user hits a button may trigger a device driver function directly for the power-on/power-off sequence, rather than bringing up an application—it
depends on the programmer how that is handled.)

Like embedded standards, embedded applications can be divided according to whether they are market specific (implemented in only a specific type of device, such as video-on-
demand applications in a interactive digital TV) or general-purpose (can be implemented across various types of devices, such as a browser).

Section 10.4 introduces real-world examples of types of application software, and how they contribute to an embedded system's architecture.

10.3 Middleware Examples

10.3.1 Networking Middleware Driver Examples

As discussed in Chapter 2, one of the simplest ways to understand the components needed to implement networking in an embedded device is to visualize networking components
according to the OSI model and to relate that to the Embedded Systems Model. As shown in Figure 10-3, software that falls between the upper data-link and session layers can be
considered networking middleware software components.

Figure 10-3: OSI model and middleware

The examples given in this section, UDP and IP (shown in Figures 10-4a and b), are protocols that fall under the TCP/IP protocol stack and are typically implemented as middleware.
As introduced in Chapter 2, this model is made up of four layers: the network access layer, internet layer, transport layer, and the application layer.

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 3 of 8

Figure 10-4a: TCP/IP, OSI Models and Embedded Systems Model block diagram

Figure 10-4b: TCP/IP model and protocols block diagram

The TCP/IP application layer incorporates the functionality of the top three layers of the OSI model (the application, presentation, and session layers), and the network access layer
incorporates the layers of the OSI model (physical and data-link). The internet layer corresponds to the network layer in the OSI model and the transport layers of both models are
identical. This means that, in reference to TCP/IP, networking middleware falls under the transport, internet, and upper portion of the network access layers (see Figure 10-4a).

Network Access/Data-link Layer Middleware Example: PPP (Point-to-Point Protocol)

PPP (point-to-point protocol) is a common OSI data-link (or network access layer under the TCP/IP model) protocol that can encapsulate and transmit data to higher layer protocols,
such as IP, over a physical serial transmission medium (see Figure 10-5). PPP provides support for both asynchronous (irregular interval) and synchronous (regular interval) serial
communication.

Figure 10-5: Data-link middleware

PPP is responsible for processing data passing through it as frames. When receiving data from a lower layer protocol, for example, PPP reads the bit fields of these frames to ensure
that entire frames are received, that these frames are error free, that the frame is meant for this device (using the physical address retrieved from the networking hardware on the
device), and to determine where this frame came from. If the data is meant for the device, then PPP strips all data-link layer headers from the frame, and the remaining data field,
called a datagram, is passed up to a higher layer. These same header fields are appended to data coming down from upper layers by PPP for transmission outside the device.

In general, PPP software is defined via a combination of four submechanisms:

• The PPP encapsulation mechanism (in RFC 1661) such as the high-level data-link control (HDLC) framing in RFC1662 or the link control protocol (LCP) framing
defined in RFC 1661 to process (i.e., demultiplex, create, verify checksum, etc).

• Data-link protocol handshaking, such as the link control protocol (LCP) handshaking defined in RFC 1661, responsible for establishing, configuring, and testing the
data-link connection.

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 4 of 8

• Authentication protocols, such as PAP (PPP authentication protocol) in RFC 1334, used to manage security after the PPP link is established.

• Network control protocols (NCP), such as IPCP (Internet protocol control protocol) in RFC 1332, that establish and configure upper-layer protocol (i.e., OP, IPX,
etc.) settings.

These submechanisms work together in the following manner: a PPP communication link, connecting both devices, can be in one of five possible phases at any given time, as shown
in Table 10-1. The current phase of the communication link determines which mechanism - encapsulation, handshaking, authentication, and so on - is executed.

Table 10-1: Phase table [10-1]

Phase Description
The link necessarily begins and ends with this phase. When an external event (such as carrier detection or network administrator configuration) indicates that
Link Dead the physical layer is ready to be used, PPP proceeds to the Link Establishment phase. During this phase, the LCP automaton (described later in this chapter) will
be in the Initial or Starting states. The transition to the Link Establishment phase signals an Up event (discussed later in this chapter) to the LCP automaton.
The link control protocol (LCP) is used to establish the connection through an exchange of configuration packets. An establish link phase is entered once a
Establish Link
Configure-Ack packet (described later in this chapter) has been both sent and received.
Authentication Authentication is an optional PPP mechanism. If it does take place, it typically does so soon after the establish link phase.
Network Layer Once PPP has completed the establish or authentication phases, each network-layer protocol (such as IP, IPX, or AppleTalk) MUST be separately configured
Protocol by the appropriate network control protocol (NCP).
Link Termination PPP can terminate the link at any time. after which PPP should proceed to the Link Dead phase.

How these phases interact to configure, maintain, and terminate a point-to-point link is shown in Figure 10-6.

Figure 10-6: PPP phases [10-1]

As defined by PPP layer 1 (i.e., RFC1662), data is encapsulated within the PPP frame, an example of which is shown in Figure 10-7.

Figure 10-7: PPP HDLC-like frame [10-1]

The flag bytes mark the beginning and end of a frame, and are each set to 0x7E. The address byte is a high-level data-link control (HDLC) broadcast address and is always set to
0xFF, since PPP does not assign individual device addresses. The control byte is an HDLC command for UI (unnumbered information) and is set to 0x03.

The protocol field defines the protocol of the data within the information field (i.e., 0x0021 means the information field contains IP datagram, 0xC021 means the information field
contains link control data, 0x8021 means the information field contains network control data - see Table 10-2). Finally, the information field contains the data for higher level
protocols, and the FCS (frame check sequence) field contains the frame's checksum value.

Table 10-2: Protocol information [10-1]

Value (in hex) Protocol Name

0001 Padding Protocol
0003 to 001f reserved (transparency inefficient)
007d reserved (Control Escape)
00cf reserved (PPP NLPID)
00ff reserved (compression inefficient)
8001 to 801f unused
807d unused
80cf unused
80ff unused
c021 Link Control Protocol
c023 Password Authentication Protocol
c025 Link Quality Report
c223 Challenge Handshake Authentication Protocol

The data-link protocol may also define a frame format. An LCP frame, for example, is as shown in Figure 10-8.

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 5 of 8

Figure 10-8: LCP frame [10-1]

The data field contains the data intended for higher networking layers, and is made up of information (type, length, and data). The length field specifies the size of the entire LCP
frame. The identifier is used to match client and server requests and responses. Finally, the code field specifies the type of LCP packet (indicating the kind of action being taken); the
possible codes are summarized in Table 10-3.

Table 10-3: LCP codes [10-1]

Code Definition
1 configure-request
2 configure-ack
3 configure-nak
4 configure-reject
5 terminate-request
6 terminate-ack
7 code-reject
8 protocol-reject
9 echo-request
10 echo-reply
11 discard-request
12 link quality report

Frames with codes 1 thru 4 are called link configuration frames, 5 thru 6 are link termination frames, and the rest are link management packets.

The LCP code of an incoming LCP datagram determines how the datagram is processed, as shown in the pseudocode example below.

....
if (LCPCode) {
= CONFREQ: RCR(...); //see table 10-3
end CONFREQ;
= CONFACK: RCA(..); //see table 10-3
end CONFACK;
= CONFNAK or CONFREJ: RCN(...); //see table 10-3
end LCPCode;
= TERMREQ:
event(RTR);
end TERMREQ;
= TERMACK:
....
}
.....

In order for two devices to be able to establish a PPP link, each must transmit a data-link protocol frame, such as LCP frames, to configure and test the data-link connection. As
mentioned, LCP is one possible protocol that can be implemented for PPP, to handle PPP handshaking.

After the LCP frames have been exchanged (and thereby a PPP link established), authentication can then occur. It is at this point where authentication protocols, such as PPP
Authentication Protocol or PAP, can be used to manage security, through password authentication and so forth. Finally, Network Control Protocols (NCP) such as IPCP (Internet
Protocol Control Protocol) establish and configure upper-layer protocols in the network layer protocol settings, such as IP and IPX.

At any given time, a PPP connection on a device is in a particular state, as shown in Figure 10-9; the PPP states are outlined in Table 10-4.

Figure 10-9: PPP connection states and events [10-1]

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 6 of 8

Table 10-4: PPP states [10-1]

States Definition
Initial PPP link is in the Initial state, the lower layer is unavailable (Down), and no Open event has occurred. The Restart timer is not running in the Initial state.
The Starting state is the Open counterpart to the Initial state. An administrative Open has been initiated, but the lower layer is still unavailable (Down). The Restart
Starting
timer is not running in the Starting state. When the lower layer becomes available (Up), a Configure-Request is sent.
The Stopped state is the Open counterpart to the Closed state. It is entered when the automaton is waiting for a Down event after the This-Layer-Finished action, or
Stopped
after sending a Terminate-Ack. The Restart timer is not running in the Stopped state.
In the Closed state, the link is available (Up), but no Open has occurred. The Restart timer is not running in the Closed state. Upon reception of Configure-Request
Closed
packets, a Terminate-Ack is sent. Terminate-Acks are silently discarded to avoid creating a loop.
The Stopping state is the Open counterpart to the Closing state. A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not yet
Stopping
been received.
In the Closing state, an attempt is made to terminate the connection. A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not
Closing yet been received. Upon reception of a Terminate-Ack, the Closed state is entered. Upon the expiration of the Restart timer, a new Terminate-Request is transmitted,
and the Restart timer is restarted. After the Restart timer has expired Max-Terminate times, the Closed state is entered.
Request- In the Request-Sent state an attempt is made to configure the connection. A Configure-Request has been sent and the Restart timer is running, but a Config-ure-Ack
Sent has not yet been received nor has one been sent.
In the Ack-Received state, a Configure-Request has been sent and a Configure-Ack has been received. The Restart timer is still running, since a Configure-Ack has not
ACK-sent
yet been sent.
In the Opened state, a Configure-Ack has been both sent and received. The Restart timer is not running. When entering the Opened state, the implementation
Opened SHOULD signal the upper layers that it is now Up. Conversely, when leaving the Opened state, the implementation SHOULD signal the upper layers that it is now
Down.

Events (also shown in Figure 10-9) are what cause a PPP connection to transition from state to state. The LCP codes (from the RFC 1661 spec) in Table 10-5 define the types of
events that cause a PPP state transition.

Table 10-5: PPP events [10-1]

Event
Event Description
Label
Up lower layer is UP This event occurs when a lower layer indicates that it is ready to carry packets.
Down lower layer is Down This event occurs when a lower layer indicates that it is no longer ready to carry packets.
This event indicates that the link is administratively available for traffic; that is, the network administrator (human or program) has
Open administrative Open indicated that the link is allowed to be Opened. When this event occurs, and the link is not in the Opened state, the automaton attempts
to send configuration packets to the peer.
This event indicates that the link is not available for traffic; that is, the network administrator (human or program) has indicated that
Close administrative Close the link is not allowed to be Opened. When this event occurs, and the link is not in the Closed state, the automaton attempts to
terminate the connection. Futher attempts to re-configure the link are denied until a new Open event occurs.
This event indicates the expiration of the Restart timer. The Restart timer is used to time responses to Configure-Request and
TO+ Timeout with counter > 0 Terminate-Request packets. The TO+ event indicates that the Restart counter continues to be greater than zero, which triggers the
corresponding Configure- Request or Terminate-Request packet to be retransmitted.
TO" Timeout with counter expired The TO- event indicates that the Restart counter is not greater than zero, and no more packets need to be retransmitted.
An implementation wishing to open a connection MUST transmit a Configure-Request. The Options field is filled with any desired
RCR+ receive configure request good
changes to the link defaults. Configuration Options SHOULD NOT be included with default values.
An implementation wishing to open a connection MUST transmit a Configure-Request. The Options field is filled with any desired
RCR" receive configure request bad
changes to the link defaults. Configuration Options SHOULD NOT be included with default values.
This event occurs when a valid Configure-Ack packet is received from the peer. The Configure-Ack packet is a positive response to a
Configure-Request packet. An out of sequence or otherwise invalid packet is silently discarded.

If every Configuration Option received in a Configure-Request is recognizable and all values are acceptable, then the implementation
RCA receive configure ack MUST transmit a Configure-Ack. The acknowledged Configuration Options MUST NOT be reordered or modified in any way.

On reception of a Configure-Ack, the Identifier field MUST match that of the last transmitted Configure-Request. Additionally, the
Configuration Options in a Configure-Ack MUST exactly match those of the last transmitted Configure-Request. Invalid packets are
silently discarded.
This event occurs when a valid Configure-Nak or Configure-Reject packet is received from the peer. The Configure-Nak and
RCN receive configure nak/rej Configure-Reject packets are negative responses to a Configure-Request packet. An out of sequence or otherwise invalid packet is
silently discarded.
This event occurs when a Terminate-Request packet is received. The Terminate-Request packet indicates the desire of the peer to close
RTR receive terminate request
the connection.
This event occurs when a Terminate-Ack packet is received from the peer. The Terminate-Ack packet is usually a response to a
RTA receive terminate ack Terminate-Request packet. The Terminate-Ack packet may also indicate that the peer is in Closed or Stopped states, and serves to re-
synchronize the link configuration.
RUC receive unknown code This event occurs when an un-interpretable packet is received from the peer. A Code-Reject packet is sent in response.
This event occurs when a Code-Reject or a Protocol-Reject packet is received from the peer. The RXJ+ event arises when the rejected
receive code reject permitted or
RXJ+ value is acceptable, such as a Code-Reject of an extended code, or a Protocol-Reject of a NCP. These are within the scope of normal
receive protocol reject
operation. The implementation MUST stop sending the offending packet type.

RXJ- receive code reject catastrophic The RXJ- event arises when the rejected value is catastrophic, such as a Code-Reject of Configure-Request, or a Protocol-Reject of

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 7 of 8

or receive protocol reject LCP! This event communicates an unrecoverable error that terminates the connection.
receive echo request, receive
This event occurs when an Echo-Request, Echo-Reply or Discard-Request packet is received from the peer. The Echo-Reply packet is
RXR echo reply, or receive discard
a response to an Echo-Request packet. There is no reply to an Echo-Reply or Discard-Request packet.
request

As PPP connections transition from state to state, certain actions are taken stemming from these events, such as the transmission of packets and/or the starting or stopping of the
Restart timer, as outlined in Table 10-6.

Table 10-6: PPP actions [10-1]

Action
Action Definition
Label
This action indicates to the upper layers that the automaton is entering the Opened state. Typically, this action is used by the LCP to signal the Up event to
tlu this layer up
a NCP, Authentication Protocol, or Link Quality Protocol, or MAY be used by a NCP to indicate that the link is available for its network layer traffic.
This action indicates to the upper layers that the automaton is leaving the Opened state. Typically, this action is used by the LCP to signal the Down event
this layer
tld to a NCP, Authentication Protocol, or Link Quality Protocol, or MAY be used by a NCP to indicate that the link is no longer available for its network
down
layer traffic.
this layer This action indicates to the lower layers that the automaton is entering the Starting state, and the lower layer is needed for the link. The lower layer
tls
started SHOULD respond with an Up event when the lower layer is available. This results of this action are highly implementation dependent.
This action indicates to the lower layers that the automaton is entering the Initial, Closed or Stopped states, and the lower layer is no longer needed for the
this layer link. The lower layer SHOULD respond with a Down event when the lower layer has terminated. Typically, this action MAY be used by the LCP to
tlf
finished advance to the Link Dead phase, or MAY be used by a NCP to indicate to the LCP that the link may terminate when there are no other NCPs open. This
results of this action are highly implementation dependent.
initialize This action sets the Restart counter to the appropriate value (Max-Terminate or Max-Configure). The counter is decremented for each transmission,
irc
restart count including the first.
zero restart
zrc This action sets the Restart counter to zero.
count
send Configure-Request packet is transmitted. This indicates the desire to open a connection with a specified set of Configuration Options. The Restart timer is
scr configure started when the Configure-Request packet is transmitted, to guard against packet loss. The Restart counter is decremented each time a Configure-Request
request is sent.
send
sca configure A Configure-Ack packet is transmitted. This acknowledges the reception of a Configure-Request packet with an acceptable set of Configuration Options.
ack
A Configure-Nak or Configure-Reject packet is transmitted, as appropriate. This negative response reports the reception of a Configure-Request packet
send
with an unacceptable set of Configuration Options. Configure-Nak packets are used to refuse a Configuration Option value, and to suggest a new,
scn configure
acceptable value. Configure-Reject packets are used to refuse all negotiation about a Configuration Option, typically because it is not recognized or
nak/rej
implemented. The use of Configure-Nak versus Configure-Reject is more fully described in the chapter on LCP Packet Formats.
send
A Terminate-Request packet is transmitted. This indicates the desire to close a connection. The Restart timer is started when the Terminate-Request
str terminate
packet is transmitted, to guard against packet loss. The Restart counter is decremented each time a Terminate-Request is sent.
request
send
A Terminate-Ack packet is transmitted. This acknowledges the reception of a Terminate-Request packet or otherwise serves to synchronize the
sta terminate
automatons.
ack
send code
scj A Code-Reject packet is transmitted. This indicates the reception of an unknown type of packet.
reject
send echo
ser An Echo-Reply packet is transmitted. This acknowledges the reception of an Echo-Request packet.
reply

PPP states, actions, and events are usually created and configured by the platform-specific code at boot-time, some of which is shown in pseudocode form in the next several pages. A
PPP connection is in an initial state upon creation; thus, among other things, the "initial" state routine is executed. This code can be called later at runtime to create and configure
PPP, as well as respond to PPP runtime events (i.e., as frames are coming in from lower layers for processing).

For example, after PPP software demuxes a PPP frame coming in from a lower layer, and the checksum routine determines the frame is valid, the appropriate field of the frame can
then be used to determine what state a PPP connection is in and thus what associated software state, event, and/or action function needs to be executed. If the frame is to be passed to
a higher layer protocol, then some mechanism is used to indicate to the higher layer protocol that there is data to receive (IPReceive for IP, for example).

Coming up in Part 2: PPP (LCP) State Pseudocode and Internet Layer Middleware Example: Internet Protocol (IP).

Printed with permission from Newnes, a division of Elsevier. Copyright 2005. "Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers" by
Tammy Noergaard. For more information about this title and other similar books, please visit www.elsevierdirect.com.

Related links:
Making the case for commercial communication integration middleware
What's different about multiprocessor software? (Part 4)
Beyond the Internet: Building Location-Based Services for Multiplatform Device Communities

All materials on this site Copyright © 2010 EE Times Group, a Division of United Business Media LLC All rights reserved.

Privacy Statement

|

Terms of Service

|

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010
Guide to Embedded Systems Architecture - Part 1: Defining middleware Page 8 of 8

Contact

http://embeddedinternetdesign.com/design/224400725;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWATM... 6/10/2010