ABSTRACT

                        The usual reason for embedding a computer is to interact with the environment, often by monitoring and controlling external machinery. Many embedded systems have substantially different design constraints than desktop computing applications. No single characterization applies to the diverse spectrum of embedded systems. Some combination of cost pressure, long life-cycle, real-time requirements, reliability requirements, and design culture dysfunction can make it difficult to be successful applying traditional computer design methodologies and tools to embedded applications there is currently little tool support for expanding embedded computer design to the scope of holistic embedded system design. Knowing the strengths and weaknesses of current approaches can set expectations appropriately, identify risk areas to tool adopters, and suggest ways in which tool builders can meet industrial needs?

                                Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. The demands of the specific application and the interface with external equipment may dominate the system design. Long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput.

                Recent interest in hardware/software co design is a step in the right direction, as it permits tradeoffs between hardware and software that are critical for more cost-effective embedded systems.

INTRODUCTION

WHAT IS AN EMBEDDED SYSTEM?

           As the name signifies, an embedded system is ’embedded’ or built into something else, which is non-computing device, say a car, TV, or toy. Unlike a PC, an embedded computer in a non-computing device will have very specific function, say control a car, or display a web page on TV screen. So, it need not have all the functionality and hence all the components that a PC have. Similarly, the operating system and application need not perform all the tasks that their counterparts from the PC sphere are expected to.

In short, we can define an embedded system as a computing device that is not a computer, and meant for doing specific computing tasks. These computing tasks could range from acquiring or transferring data about the work done by the mother device to displaying information or controlling the mother device. Embedded systems could thus enable us to build intelligent machines.

Embedded system is not a new and exotic topic that is still confined to research theses. There are many live examples of embedded systems around us. MP3 players   (computing capability built into a music system), Pads (computing in what essentially is an organizer), car-control systems, and intelligent toys are but a few examples of such systems already in place.

A typical embedded system consists of hardware (typically VLSI circuits) specifically built for the purpose, an embedded operating system, and the specific application or applications required. The user interface could be push buttons, numeric displays, and LCD panes and so on.

One of the problems with building specific hardware for each type of application is that for every new application you have to literally start from scratch and reinvent the wheel. This increases the costs of the system as well as time taken to develop one. On the other hand, in the world of PC, you can plug in a mass-produced add-on card and get the required functionality (sound or networking, for example) instantaneously. But the PC and its add-on cards-ISA and PCI cards are pretty bulky devices, and could take up quite a lot of space.

But the benefits of using standard PC components in embedded systems were obvious. So, a method was developed to shrink the PC. What was done was to make the PC bus smaller, and also make the cards stackable, one on the top of another, instead of connecting all cards to one big motherboard, so that space is saved. The PC/104 standard, established in 1992 defines the embedded PC. The specification is considered to be ad extension of the ISA bus specification. The PC/104 standard has since been extended to PC/104-plus to include the PCI bus. So, today you have PC-based embedded systems that have the ISA bus, the PCI bus, or both.

There are many challenges for this field, which are opportunities to improve methodology and tool support as well as impediments to deploying such support to embedded system design teams. Instead of executing spreadsheets, word processing and engineering analysis, embedded systems typically execute control laws, finite state machines, and signal processing algorithms. They must often detect and react to faults in both the computing and surrounding electromechanical systems, and must manipulate application-specific user interface devices. Some differences with desktop computing may be:

• The human interface may be as simple as a flashing light or as complicated as real-time robotic vision.

• The diagnostic port may be used for diagnosing the system that is being controlled -- not just for diagnosing the computer.

• Special-purpose field programmable (FPGA), application specific (ASIC), or even non- digital hardware may be used to increase performance or safety.

SSI EMBEDDED SYSTEM PROGRAMMING:-

1992 - In response to AT&T Bell Labs deal with Memorex Telex regarding their data communication division and then subsequent company reorganization, Michele Mordacq launches Systems & Synchronous, Inc. (SSI). Twelve engineers leave to join SSI and begin work on a multi-year contract secured with Memorex Telex to write embedded software for communications controllers.

1994 - SSI develops and releases two software packages: LANSleuth, a software network protocol analyzer, and DejaView, a TCP/IP communication package providing LAN connectivity to synchronous and asynchronous hosts. AT&T contracts SSI for CCC Platform. 

1996 - SSI moves to a larger lab facility in Aurora, Illinois. LANPanther is released, a gateway product tailored to large corporations migrating from IBM concentric backbones. Other AT&T sites contract SSI for communication software projects.

1997 - A transitional year for SSI. While we have a number of technically excellent products, consumer demand is light. With the exception of LANSleuth, the decision is made to discontinue enhancements to SSI's software products. Our business objective evolves from providing both development services and producing marketable products to providing embedded software consulting services only. 

1998 - Motorola and Westell each contract SSI for embedded software development. The long term relationships with these companies provide opportunities for SSI to develop embedded software for automotive and switching/routing products. Lucent also contracts SSI for a network conversion product.

1999 - Begin doing business as to better reflect our expertise. We continue to expand our customer base of hi-tech Chicago area clients.

2000 - Contract opportunities expand to the retail and printing industries.

2001 - Our customer base continues to expand to cutting edge VC (venture capital) funded startups including those in the streaming media and biotech industries.

2002 - Release LANSleuth 6.0. LANSleuth continues to be a viable product and in-house tool. 

COMPUTER DESIGN REQUIREMENTS

Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.

 Real time/reactive operation

                     Real time system operation means that the correctness of a computation depends, in part, on the time at which it is delivered. The Signal Processing and Mission Critical example systems have a significant requirement for real time operation in order to meet external I/O and control stability requirements.

Reactive computation means that the software executes in response to external events.   These events may be periodic, in which case scheduling of events to guarantee performance may be possible. On the other hand, many events may be a periodic, in which case the maximum event arrival rate must be estimated in order to accommodate worst case situations. Most embedded systems have a significant reactive component.

     Design challenge:

• Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics (e.g., cache memory).

      Small size, low weight

In transportation and portable systems, weight may be critical for fuel economy or human endurance. Among the examples, the Mission Critical system has much more stringent size and weight requirements than the others because of its use in a flight vehicle, although all examples have restrictions of this type.

Design challenges:

1. Non-rectangular, non-planar geometries.
2. Packaging and integration of digital, analog, and power circuits to reduce  

      size.

Safe and reliable

Some systems have obvious risks associated with failure. In mission-critical applications such as aircraft flight control, severe personal injury or equipment damage could result from a failure of the embedded computer.

 However, many embedded systems that could cause personal or property damage. This vulnerability is often resolved at the system level.

Design challenge:

3. Low-cost reliability with minimal redundancy.

Communication Protocols for Embedded Systems

The past few years have seen the beginning of a trend to dramatically increase the embedded electronics content of automobiles, elevators, building climate control systems, jet aircraft engines, and other traditionally electro-mechanically controlled systems. In many large systems this increasing electronics content is being accompanied by a proliferation of subsystems having separate CPUs.

The increase in the number of processors in a system is often driven by computation and I/O growth. In some development environments, the increase may also be driven by a need to ease system integration burdens among multiple design groups or to provide system flexibility through "smart sensors" and "smart actuators". But, whatever the reasons, once there is more than one CPU in a system there must be some means of communication to coordinate action.

While some high-end embedded systems communicate over a VME backplane or similar arrangement, the embedded systems we're working on use physically distributed CPUs and thus involve some sort of Local Area Network (LAN), also called a multiplexed network or a communication bus. At the heart of the LAN is the media access protocol, which arbitrates (picks the next transmitter for) access to the shared network medium (typically a wire, fiber, or RF frequency).

The protocols we discuss are: Connection Oriented Protocols, Polling, Time Division Multiple Access (TDMA), Token Ring, Token Bus, Binary Countdown, Carrier Sense Multiple Access with Collision Detection (CSMA/CD), and Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA).

SPECIAL CONSIDERATIONS FOR EMBEDDED APPLICATIONS

In practice, we have found that embedded real-time networks require high efficiency, deterministic latency, operational robustness, configuration flexibility, and low cost per node.

Because cost limits the network bandwidth available to many applications, protocol efficiency (message bits delivered compared to raw network bandwidth) is very important. The embedded systems we have studied are characterized by a predominance of short, periodic messages. So, an obvious optimization is to reduce overhead bits used for message packaging and routing (it is not unusual for 8 bits of data to be packed in a message that is 32 or even 64 bits long).

Once message overhead has been reduced as much as possible, media access overhead must be reduced. For the most part, this is accomplished by minimizing the network bandwidth consumed by arbitration (e.g., passing a token or resolving collision conflict). Because worst-case behavior is usually important, efficiency should be evaluated both for light traffic as well as heavy traffic. For example, CSMA/CD (often used in workstation LANs) is highly efficient for light traffic but gives poor performance if heavily loaded, while Token Bus protocols have the reverse properties.

Determinacy, or the ability to calculate worst-case response time is important for meeting the real-time constraints of many embedded control applications. A prioritization capability is usually included in systems to improve determinacy of messages for time-critical tasks such as exception handling and high-speed loop control. Priorities can be either assigned by node number or by message type. Additionally, protocols can support local or global priority mechanisms. In local prioritization, each node gets a turn at the network in sequence and sends its highest priority queued message (thus potentially forcing a very high priority message to wait for other nodes to have their turns first). In global prioritization the highest priority message in the entire system is always transmitted first. This mechanism, which is fundamentally enabled by the media access protocol, is highly desirable for many safety critical applications.

Many applications require robust operation under extreme conditions. We call a protocol robust if it can quickly detect and recover from errors (e.g., duplicate or lost tokens), added nodes, and deleted nodes. In some systems it is also important to quickly recover from a reset or power glitch that forces a restart of the network.

Varied operating environments may dictate use of a media access protocol that is flexible in supporting multiple media as well as mixed topologies. For example, portions of a system may require expensive fiber in noisy environments, while other portions can tolerate low-cost twisted pair wires in benign environments. Further, a bus topology may be optimum for wires, but a ring or star topology maybe needed for fiber.

Finally, a vital consideration is the cost per node. In this article, the order of the media access discussion progresses from very simple to complex, high performance protocols. Simple protocols require less hardware and software resources and are therefore likely to be less expensive. For extremely cost-sensitive high-volume applications, these protocols are good candidates. However, for growth-expected applications, more advanced protocols provide a stronger foundation. In general costs are decreasing over time due to advances in IC manufacturing technology and the increasing availability of off-the-shelf protocols. Consequently, we envision advanced cost-effective protocols used in many embedded applications.

MEDIA ACCESS PROTOCOLS

Now that we have a feel for the issues to deal with in embedded networks, let's examine the various commonly available media access protocols. While many variations and combinations are possible, we'll just discuss the plain versions of each protocol.

Connection Oriented Protocols

Before LANs became popular, connection-oriented protocols were heavily used to connect remote terminals to mainframes. These protocols support only two nodes per physical transmission medium, and are typically connected via modem with serial lines. Figure 1 shows an example of a four-processor network using this protocol. Communication between nodes not physically connected requires multiple transmissions through intermediate nodes. These protocols are deterministic between directly connected nodes. For indirectly connected nodes, latency can be high.

For an embedded system with modest communication requirements, this might be a cost effective protocol (readily available hardware and software from mature technology). For demanding applications, nodes that handle a lot of pass-through traffic can become swamped, prohibiting use of low-cost nodes in a large system. Sometimes, this type of protocol is combined with a more complex communication system to provide backward compatibility to older systems or to allow simple remote modem access to the system (e.g., BACnet). This type of protocol is used by the X.25 public network standard (network services offered by telephone companies) and IBM's System Network Architecture (SNA) [2].

Figure 1: An example network using connection oriented protocols 

Polling

Polling is one of the more popular protocols for embedded systems because of its simplicity and determinacy. In this protocol, a centrally assigned master periodically polls (by sending a polling message) the slave nodes, giving them explicit permission to transmit on the network.

Figure 2: Master node sequentially polling slave nodes for information

Figure 2 shows the polling order (dotted lines) of a simple four-node bus network. The majority of the protocol software is stored in the master and the communication work of slave nodes is minimal (therefore, the network costs tend to be smaller). This protocol is ideal for a centralized data acquisition system where peer-to-peer communication and global prioritization are not required. However, in embedded systems we have worked with, the single-point-of-failure from the master node (or the cost of installing redundant master hardware) is unacceptable. Additionally, the polling process consumes considerable bandwidth regardless of network load (poor efficiency). These protocols have been standardized by the military (MIL-STD-1553B) for aircraft subsystem communications. Some variants of this protocol allow inter-slave communication through the master as well as improved robustness by using multiple masters (e.g., Profibus).

Time Division Multiple Access (TDMA)

TDMA is heavily used in satellite communications [3], but is applicable to local area networks as well. In this protocol, a network master broadcasts a frame sync signal before each round of messages to synchronize clocks of all the nodes. After the sync, each node transmits during its uniquely allocated time slice as in Figure 3. Performance is similar to polling, but with greater efficiency at heavy loads due to elimination of individual polling messages. Costs for slave nodes are greater with TDMA than with polling, because each slave node must have a stable time base to measure slices. An additional weakness for TDMA is the need for fixed-length messages to fit into time slices. In some TDMA variations, unused slices are truncated by tacit agreement among nodes. Time-based protocols have been popular in aerospace applications. For example, DATAC (Digital Autonomous Terminal Access Communications) is being used by NASA and Boeing.

Figure 3: Time Slices of TDMA protocols

Token Ring

In a Token Ring network, the nodes are connected in a ring-like structure using point-to-point links as shown in Figure 4. A special token signal is passed from node to node around the ring. When a node has something to send, it stops the token circulation, sends its message all the way around the ring, and then passes the token on. Since worst-case token waiting time can easily be calculated, this protocol is deterministic. Under light traffic, Token Ring has moderate token passing overhead. However, the protocol provides efficient throughput under heavy traffic conditions since idle token passing is minimized. A frequent implementation strategy is to have a one-bit delay at each node, so a token can visit all nodes in N+T bit times, where N is the number of nodes and T is the number of bits in the token. Global prioritization is accomplished by altering the priority field of the token as it visits the nodes. This field enables only the nodes with a higher priority to send messages on the network. Initialization of the token message, and detection of accidentally duplicated or lost tokens adds complexity and cost to the protocol. A break in the cable or a failed node disabling the entire network is a common concern for many users. Consequently, node bypass hardware and dual rings are used to address this concern at additional cost. Because the ring connections themselves are point-to-point, it is well suited for fiber optics. Consequently, many LANs and Wide Area Networks (WANs) are moving to this type of protocol. For example, FDDI (Fiber Distributed Data Interface) uses dual counter-rotating rings to achieve higher reliability than bus or star topologies.

Figure 4: Token passing in the Token Ring networks

Token Bus

The operation of a Token Bus is very similar to a Token Ring -- a token is passed from node to node in a virtual ring as in Figure 5. The holder of the token has the access to the network. Like Token Ring, Token Bus works well under heavy traffic with a high degree of determinacy. However, Token Bus broadcasts the message simultaneously to all nodes instead of passing it bit-by-bit along a physical ring. The minimum time for a token to traverse the logical ring of nodes is thus N*T bit times instead of N+T bit times as in token ring (because there is no parallelism in the connections). This makes global prioritization of messages largely impractical.

Unlike unidirectional Token Ring, a break in the cable or a failed node does not necessarily disable the entire network. A lengthy reconfiguration process, where each node identifies its neighbors, is used to maintain the virtual ring when nodes are added or deleted from the network. Because bus-like topologies are well suited for manufacturing plants, MAP, Manufacturing Automation Protocol, adopted this protocol. Additionally, ARCnet [4], Attached Resource Computer Network, uses this protocol for LAN connectivity and process control. Adaptive Networks' PLC-192 power line carrier chip uses a hybrid Token Bus protocol: under light traffic, nodes dynamically join and leave from the logical ring; under heavy traffic, all nodes join the ring to maintain stability.

Figure 5: Token passing in Token Bus protocols 

Binary Countdown

In Binary Countdown, also known as the Bit Dominance protocol, all nodes wait for an idle channel before transmitting a messages. Competing nodes (transmitting simultaneously) resolve contention by broadcasting a signal based on their unique node identification value. The transmission medium must have the characteristic that one value (say, a "1") overrides the opposite value (a "0"). During this transmission, a node drops out of the competition if it detects a dominant signal opposite to its own as shown in Figure 6. Thus, if a "1" signal is dominant, the highest numbered transmitting node will win the competition and gains ownership of the channel.

Figure 6: Arbitration in Binary Countdown Protocols 

Global prioritization can be achieved by arbitrating over message ID values rather than the node IDs . Since the arbitration is part of the message, this protocol has good throughput and high efficiency. Additionally, the protocol is more robust because node configuration (transmission order) is not required and inactive nodes are ignored. However, since all messages are prioritized, there is no simple way to guarantee equally fair access among all nodes under heavily loaded conditions. Also, some transmission techniques (such as current-mode transformer coupling commonly used in high-noise environments) aren't compatible with the bit dominance requirement. Using this protocol, Bosch developed the Controller Area Network (CAN[5]) specification for automotive applications. The Society of Automotive Engineers standard SAE J-1850 also uses this protocol.

Carrier Sense Multiple Access with Collision Detection (CSMA/CD)

CSMA/CD has been widely researched with a large number of published variations[2]. In the simplest case, a node waits for the network to go idle before transmission (as in binary countdown). If multiple stations transmit almost simultaneously (within a round-trip transmission delay on the network), the messages collide as in Figure 7. The nodes must detect this collision, and resolve it by waiting for a random time before retrying.

Figure 7: Collisions in CSMA/CD networks 

The key advantage to this protocol is that in principle it supports an unlimited number of nodes that don't require pre-allocated slots or inclusion in token passing activities. Thus, CSMA/CD allows the nodes to enter and leave the network without requiring network initialization and configuration. For light traffic conditions, overhead is very small. However, under heavy traffic the overhead is unbounded due to high probability of repeated collisions. Consequently, this protocol has poor determinacy and low efficiency. Furthermore, detecting collisions may require analog circuitry that adds to the system expense. In fact, if the network environment is very noisy or the wiring runs are long and poor quality, collision detection may not work at all. The popular Ethernet protocol used in workstation LANs is based on this protocol.

Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)

Many researchers have developed hybrid protocols that combine the light traffic efficiency of CSMA/CD with the heavy traffic efficiency of token-based protocols. The resulting protocols are often called CSMA/CA, or collision avoidance algorithms. As in CSMA/CD, nodes transmit after detecting an idle channel. However, if two or more stations collide, a jam signal is sent on the network to notify all nodes of collision, synchronize clocks, and start contention time slots. Each contention time slot, typically just over a network round-trip propagation delay time, is assigned to a particular station. Each station is allowed to initiate transmission during its contention slot. Figure 8 shows a slot progression for a three node network. In this example, transmitter 2 and 3 collide and initiate a jam. Contention slots follow the jam signal. Since processor one has nothing to send, slot1 goes idle. Transmitter two starts sending its message during slot2. Other stations detect the message, and stop the slot progression. After end of the message, all nodes initiate new contention slots. However, to ensure fairness and determinacy, the slots are rotated (change positions) after each transmission. Additionally, the pslots, or the priority slots can precede each slot progression to support global prioritization for high priority messages. The network returns to an idle state when all the slots go unused.

Figure 8: Slot progression in CSMA/CA protocols 

The contention slots in CSMA/CA protocol help in avoiding collisions. In general, there are two distinct variations of CSMA/CA protocols. If the number of slots equals the number of stations, the protocol is called Reservation CSMA or RCSMA. The RCSMA variation works efficiently under all traffic conditions [6]. However, because of the one-to-one relation of the node to the slot, RCSMA is not practical for a network with a large number of nodes. In another variation, the number of slots are less than the number of stations and the slot assignments are randomly allocated to minimize collisions. Echelon's LON [7] (Local Operating Network) uses the latter variation and dynamically varies the number of slots based on expected traffic prediction. Unlike CSMA/CD, there are ways to eliminate the need for collision detection hardware, such as by sending dummy messages that keep slots going in the absence of network traffic.

MEDIA ACCESS PROTOCOL SUMMARY AND TRADEOFFS

In the above discussions we have described the major media access protocols and noted clear differences. Table 1 summarizes some of the common traits and our assessment of their strengths and weaknesses for embedded real-time applications. The important points to take into consideration when evaluating alternatives are:

• Polling, TDMA, and connection-based protocols are simple, but may not provide sufficient flexibility for advanced systems.
• Token-based protocols are predictable, but can have high overhead and require complex software to maintain robustness.
• Binary count-down protocols rely heavily on the bit dominance characteristics of the physical medium.
• CSMA/CD is a poor choice for hard real-time systems with heavy traffic.

Table 1: Media Access Tradeoffs 

For our embedded systems, we have found that CSMA/CA, and in particular Reservation CSMA is a good choice. While your application will no doubt have characteristics that are somewhat different than ours, this article's discussion of the special considerations and media access protocol strengths and weaknesses should allow you to select the best protocol to match your needs. We believe the electronic contents of embedded systems will continue to grow, and communication networks provide strong foundation for supporting this growth.

EMBEDDED, REAL-TIME OPERATING SYSTEMS:

      The term ‘Embedded’ means ‘combined’. An embedded hardware device           contains a single chip that stores hardware and software components of a computer, like the memory and the base operating system, together. Embedded software can be used for various purposes – right from powering hand-held mobile devices like pocket PCs to large scale factory automation. To run this software, you need operating systems. Embedded operating systems are used in PDAs, high-end cellular phones, MP3 players, and Palmtop computers.

      Embedded operating systems are available in three flavors: Windows, Linux and others.

• Windows CE 3.0 There are no fewer than four versions of the Windows CE kernel designed for varying types of hardware. Windows CE includes 32-bit Windows technology and networking support amongst other features familiar to normal Windows users. A number of development tools are available for this platform. Database is available through an SQL Server 2000, Windows CE Edition.
• Embedded Linux Linux is a powerful and full featured operating system, and its embedded version is no exception. Embedded Linux is free just like its PC counterpart. Its source code is freely available, and allows developers of hardware devices to modify the core of embedded Linux to their preferences without having to go through long processes of licensing and paying for the operating system. In fact, many have predicted that the future of Linux is in the embedded world.
• Windows NT embedded Windows NT embedded is a little different from Windows CE. This embedded operating system is built on Windows technology it excels in networking and communications, hence its name. Its price to hardware manufactures is higher than most other embedded operating systems, and therefore it is not a very popular alternative to Windows Edition.
• Palm OS Created by 3Com, it is designed exclusively for PDAs. While the operating system supports only 8-bit (256) colors and networking is slower when compared to other embedded operating systems, the main difference between other operating systems and Palm OS is that the Palm OS kernel is optimized for a specific hardware platform designed completely by Palm Computing. Other OEMs (such as IBM) have taken the core of the Palm OS and added new features to it, but they can’t change things such as the CPU, screen and controller chips.
• QNX Rea-time Platform The ‘real-time platform’ of the QNX OS signifies something unique. It represents something present in both a real-time operating system and a platform OS. That fundamentally means that QNX has ‘priority driven multitasking’ and allows many tasks to be performed together at once without having one application running extremely slow or fast. QNX also has a very flexible kernel that consists of four parts (the process, file system, device and networking managers).
• RT Kernel RT kernel is another real-time OS from On-time, which runs on x86 CPUs in real mode, and is designed real-time multitasking under paradigm and DOS tools. The OS supports many debuggers including Turbo Debug, Codename, Paradigm and the Borland/MS integrated debuggers. The base price is $550, and upgrades are not free. The company provides unlimited and free technical support via FAQs and phone.
• Tiny BIOS It has a base price of $1995, and supports only x86 real and protected modes. No free technical support is offered by the manufacturer.

DEVELOPMENT INITIATIVES IN EMBEDDED SYSTEMS:

          A lot of development is happening on embedded systems with many development platforms, environments, and operating systems being created to help with this process. Two popular initiatives are as:

Inferno

          Inferno was developed by Computer Science Research Center of Bell Labs. Its core feature is virtual machine called Dies which makes it portable across various platforms, including Intel x86, Sun Spark, MIPS, power PC. So it can be used across all the major Ross like Windows (NT and 95), and many flavors of UNIX including Linux. Inferno runs as a service under these Ross. It also has its own micro-kernel, so it can be deployed on embedded devices without a native operating system underneath.

         Inferno’s memory requirements as low as 1 MB-possible due to its modular architecture. All user applications as well as core services of Inferno are available as modules that can be dynamically loaded into the memory when required. Likewise, thy can also be unloaded and the memory area reclaimed for subsequent use by a service called Garbage Collector that continuously runs in the background.

          Inferno can be used in a distributed environment, a necessary feature so that all the intelligent gadgets can communicate with each other. It uses a communication protocol called Styx, which runs above the transport layer and is independent of transport layer protocols like TCP and UDP. Styx has built-in security using Public Key Cryptography for communication.

          Under Inferno, all services like network services are represented as files, which can be written (inputs) and read (outputs).for example a DNS service represented in a file named /net /dens can be written with a FQDN (Fully Qualified Domain Name ) like www.yahoo.com  and when read, this file yield the corresponding IP address (216.115.108.243). The same scheme is adopted to represent I/O devices attached to the gadgets, which can use a variety of input and output devices ranging from simple keypads, touch screens to radio wave based I/O. The interface to all devices is also represented as files. This make it easy for developers, as they can be read or written without worrying about complexity (or simplicity) of the device.

          A new programming language called Limbo is used to develop Inferno applications. Limbo borrows its syntax from C and Pascal, and is ideal for coding multitasking applications, the library function that can be used while programming is also available as modules. Limbo programs when compiled result in byte codes which are instruction to the virtual machine Dis. At runtime, Dies translates the byte code instructions to those of the native operating system of the embedded device. An on-the-fly compiler is also available which converts byte codes directly into native instructions thus boosting the execution speeds.

Chai

This development environment (runtime and compile time) provides tools to develop applications for embedded devices. It is based on Java and consists of following components:

• ChaiVM: The Chai virtual machine
• ChaiAWT: Graphics library for coding GUI components
• Teraserver: For intercommunication and remote configuration of Chai     applications
• ChaiAppliance Plug and Play: an open-standard technology for automatic and transparent connectivity between embedded devices
• Chai/E-speak: Libraries which enables Chai applications to act as e-services
• Chai/Open View: Enables management of Chai application by Hip’s Open View Network Node Manager
• Chamfered: A Web browser for embedded devices
• Oracle 8i late: Database for embedded devices

The core of this technology is also a virtual machine called ChaiVM, which runs on top of an embedded device’s hardware and native operating system. The memory requirements of ChaiVM can be reduced to as low as 228 kobo by selecting only those components (class libraries, data structure), which are required on a particular embedded device. ChaiFreezeDry, a part of ChaiVM, is a class loader, which converts the Java class bytes (resulting from compilation of a Java program) into a compact format, before loading them onto the VM. It is claimed that this saves about 50 percent usage of primary memory.

       ChaiAWT is a set of Java class libraries (similar to Java AWT libraries) and native methods that enables coding GUI interfaces for embedded devices. This library supports monochrome, grayscale and colored displays, a must for embedded devices with different display capabilities. Chai Appliance PnP (Plug and Play) technology makes Chai applications Universal PnP ready. Universal PnP is a specification in which new devices can announce their presence to other devices, and get auto-configured when plugged into a network. Chai Appliance PnP uses Java implementation of Universal PnP.

       A 200 kobo Web server called Teraserver provides a Web-based interface to access and configure Chai applications. It also facilitates inter-communication between Chai applications running on different gadgets via Web protocols like HTTP. Complementing the Web server is a Chamfered Web browser, with small memory footprints (about 220 kobo). Apart from HTML including CSS (Cascading Style Sheets), it also supports XML (extensible Markup Language).

          Chain/E-speak enables Chain applications to be exposed as reusable e-services across the local network the Internet. Hip’s Open View Network Node Manager (NNM) is a network management tool, which provides a graphical map of the devices connected to a network. Using Chai/Openview component Chain applications running on embedded devices become visible to the Open View Network Node Manager. This allows their discovery and management using the NNM.

           The Chain Appliance Platform integrates Oracle 8i late, a database for embedded devices. This DBMS supports to ODBC, JDBC and SQLJ. With ODBC, virtually data in any database can be accessed by any application using the so-called ODBC drivers. JBDC is similar to ODBC but specific to Java applications. SQLJ specifications allow SQL statements to be embedded in Java programs. Oracle 8i Late includes connects technology, which facilitates secure data synchronization from other systems using HTTP or other file transfer protocols like Oracle’s Net8.

            A suite of development tools is provided to help with coding for the Chain Appliance platform. This includes separate corresponding tools for each of its components like ChaiVM toolkit, Chaiserver toolkit, Chai/E-speak toolkit and a Chai/OpenView toolkit. Add to these a TurboChai compiler, which can translate the Java class bytes to the native instructions of the embedded device and the performance is increased.

COMPUTERS EMBED YOUR LIFE

         Embedded systems are finding their way into robotic toys and electronic pets, intelligent cars, and remote-controllable home appliances.

ELECTRONIC PETS:

          Due to wonders in the modern electronics, toys are getting a new life. They have been given feelings that get affected based on how you behave with them. All the major toy makers across the world have been coming out with advanced interactive toys that can become your friends for life. These toys are electromechanical in nature, have sensors to listen, see, talk, and feel your touch. They have complex circuitry, and some uses micro-controller chips to control everything. They have memory to store the code that drives the micro-controller, which in turn operates the remaining parts. In other words, toys are the most popular examples of embedded systems.

Aibo, the smart dog:

           Aibo are the robotic dogs created by Sony Corporation. The Aibo has two meanings. The ‘Ai’ stands for Artificial Intelligence and ‘bo’ represent robot. Aibo also translate to mean ‘partner’ or ‘pal’ in Japanese.

Aibo has sensors to detect various emotions. It learns and matures by interacting with people. It has a state-of -the-art voice recognition system that understands what you say. For instance, if you praise it for playing with a ball, it will continue doing so. However, if you scold it, Aibo will not even look at the ball. Aibo recognize its name, so it will respond through electronic tones if you call its names. Other than that, it can recognize and respond to about 50 words. It has six emotions to display its happiness, anger, sadness, surprise, fear, and dislike. It has CCD camera and a distance sensor that allows it to avoid obstacles, and even recognize colors it likes or dislikes. In fact, the camera can also be used to take pictures. It recognizes the command “take a picture”. Of course, you need extra accessories to be able to view those pictures on computer screen. It has four sensors similar to humans and animals, of touch, hear, see, and a sense of balance.

         The robotic dog is amongst the most intelligent implementations of an embedded system. It has 18 joints that can produce 250 different types of movement. So it can run, dance, sit, and play with a ball. All actions of Aibo are recorded on an 8 MB memory stick. There’s even a development tool called Aibo Master Studio that can be used to create original motion and sound data for Aibo.

REMOTE CONTROL YOUR HOME

          Home appliances, from refrigerators and air-conditioners to televisions and microwave ovens, are going the embedded way. This means that you’ll soon be able to control the temperature of your air-conditioner over the internet, check e-mail on your refrigerator, make your microwave download recipes from the internet, or surf the web on your television. Several home-appliance players have entered the embedded arena and more are expected to follow.

           LG electronics Digital DIOS refrigerator can be used for surfing the Internet, checking e-mail, making video phone calls, and watching TV. It has 15.1” TFT-LCD touch screen and its own port to connect to the Internet. You can use LCD information window to find out more about what you’ve stored in the refrigerator: tips on food, nutrition and expiry dates of products, recipes, nutrition information on the products inside and how to make them, as well as refrigerator’s temperature.

           LG’s stables also contain a washing machine and a microwave oven that are Internet-ready. The washing machine has a communication cable that you can link to a PC with an Internet connection. You can then connect to the washing machine’s websites, download washing programs suitable to the different types of cloth you want to wash, and store them in the washing machine. A terminal for home net-working and a modem for the washing machine are under development. These will allow you to download program directly into the washing machine from the Internet and to control the machine’s operation from a remote location.

         The microwave oven has a built-in modem that it uses to access websites on cooking. It also goes a step ahead and automatically downloads information like cooking time and microwave level for different recipes. So you can put your dish in the microwave and let it figure out how to cook it. You can also add your own information and bookmark your favorite food sites.

          IBM and Carrier are working on developing air-conditioners that you can control over the Internet. A service called Myappliance.com will let you control the temperature of your Carrier Internet-enabled air-conditioner and switch it on and off through the website. You will also be able to use the website to transmit fault codes and diagnostic alerts to mobile phones, e-mail addresses or fax machines of Carrier dealers.

Challenges for the Embedded Development Engineer Designing Optical Gigabit Ethernet Network Devices:

Summary  

        The Embedded Systems market is on the verge of a great expansion. Gigabit Ethernet will lead the way as the interface of choice due to the overwhelming desire of the consumer to have smart devices connected to the network and the ability of current technology to deliver new functionality. Whether, the embedded device is a switch, router or hub, a NIC card, handheld computer, building automation system, aircraft control system, automobile diagnostic system, home appliance, voice over IP phone, video gaming station, television, or a cell phone, almost all products have a requirement to be connected.

       Embedded systems must also be connected in a "standard" manner to enable products to communicate with third party devices. So it stands to reason that the connection of choice is IP over Ethernet. Packet switched IP is the standard to which the entire networking world is synchronizing.

        Today, the price, power and speed of silicon has enabled many embedded products to utilize high powered processors and operating systems with integrated TCP/IP stacks, and, incorporate many of the standard buses and components found in the standard/desktop PC.

        This enables the embedded system to take advantage of economies of scale for components like DRAM and flash. Additionally, standard expansion buses, such as PCI, PCIX, Infiniband, USB, and PL3/4, enable the embedded product to utilize new third party devices once used only in the PC community. All that said, Ethernet has grown into one of, if not the most popular, interfaces in embedded systems. In a relatively short timeframe, the traditional 16 bit 20MHz system has turned into the 32/64 bit 1GHz, with Optical Gigabit Ethernet access, system of today.

         As the semiconductor process continues to advance, silicon vendors find they have more space, power and speed to add new peripherals. Ethernet, specifically Gigabit Ethernet, is at the top of the list.

         Advances in ASIC, FPGA and network processor technologies have enabled engineering departments to achieve faster processing at the packet level, thus freeing the core processor to do other work. These technologies will enable a host of new, innovative products that have no problem keeping up with the line rate of Gigabit Ethernet.

          In designing and developing these more complex embedded systems, the engineer is required to generate network packets in a controlled manner, and stimulate (at up to line rate) the device under test on a known good physical interface. In addition, the engineer must be able to capture traffic (at up to line rate) to inspect what the device under test is sending out onto the network.

         Traditionally, network stimulus, capture and decode tools have been geared for the L2/L3 switch, and, the QA engineer who is tasked with testing packet handling, routing algorithms and traffic throughput of multi-port switches. This equipment is often very expensive, complicated to use, and has many features only needed for the QA process.

           Until now, the embedded engineer has been forced to buy an expensive unit that is not tailored to his application, borrow or timeshare a unit with the QA lab, or more often than not, fashion a home grown test solution. The issue with all of these approaches to testing is that it costs the engineer time and effort that is better spent focused on the product itself. With the advent of cost effective optical networking, the old testing and debug methodologies are no longer viable.

        Singulus G1™ is the first in a series of network development tools from IneoQuest Technologies, Inc, that offers a cost effective, tailored solution for the embedded engineer at all stages of the product life cycle.

Singulus G1™ - 1 Gigabit Ethernet Stimulus and Measurement System

       Integrated with the Tektronix Logic Analyzer, Singulus G1™ has been built to facilitate the needs of the embedded engineer at all phases of development - hardware bring up, firmware development, software integration, regulatory approval process, manufacture/test, and field deployment. The Singulus G1™ system is a feature-balanced network stimulus/analysis system that integrates seamlessly into the embedded engineer's lab.

Embedded Technology  

    How did we get to the current state of embedded systems? It was not long ago that RS485 was the network bus of choice between distributed devices, and modems were the interface to the internet. Embedded processors at that time were 16 bit instruction cores, running at speeds of about 20 MHz. These devices often required hand crafted assembly, and the only essential network debug tool was a simple serial analyzer.

      Today, the processing power and cost effective technology available to the embedded product will demand faster networking connectivity. This puts pressure on embedded development engineers to find new, secure, reliable methods of design and test for these new products.  

Hardware Engineer

        The embedded hardware engineer is typically responsible for the design, development and test of the physical hardware product. This engineer will specify the components, perform schematic capture, and follow the hardware through the layout, route and fabrication phase.

Some of the issues the hardware engineer will face are:

 1. Overall system complexity continues to increase

     a. Leads to longer learning curve

     b. Leads to more difficult debugging solutions

     c. Faster external stimulus stresses overall system, i.e. Gigabit Ethernet

 2. Independent component technology continues to advance

     a. Faster processors, 1GHz and beyond

      b. More complex peripherals, higher density FPGAs, Double Data Rate

           RAM (DDR), highly integrated communication semiconductors, etc.

     c. Faster buses, PCI, USB, Infiniband, PL3, UTOPIA, etc…

     d. Differential bus signaling, PL4, Rapid I/O, etc

  3. Components are more delicate

     a. Trace lengths and route paths are more critical in the PCB design

      b. Optics require tighter tolerance components

      c. Micro-BGAs leading to greater than 12 layer boards

Firmware Engineer

        The firmware engineer will typically design and develop the low-level software for the system. This engineer is responsible for the board bring-up diagnostics and peripheral driver operation, often referred to as the Board Support Package (BSP).

The issues arising in this phase include:

   1. Peripheral complexity continues to increase

      a. Gigabit Ethernet semiconductors often have several hundred registers to

          be configured

       b. Many semiconductors have multiple functions to assist processor

       c. Leads to longer learning curve

  2. Visability into the DUT is sometime limited

       a. Buses and processors run too fast to use the "printf" debug methodology

       b. Tools solutions are sometimes not available for the processor in a DUT

  3. Drivers are more complex

       a. Complex ISR handling for multifunction semiconductors

       b. Fast networks stress buffer management

       c. Tools for accurate testing are very expensive and lack a complete    

            solution

  Software Engineer

        The software engineer is responsible for the software application that sits on top of the BSP and typically writes code at the C or C++ level. With Gigabit Ethernet, applications vary from control-plane protocol stacks to data-plane protocol stacks to custom applications over IP, such as Voice over IP (VoIP), video applications, or Storage Area Network (SAN) type applications.

The software engineer must deal with:

1. More complex stacks

   a. New in-band routing stacks for switching applications, such as, RSVP-TE

        for MPLS

    b. Application specific stacks, such as, VoIP

    c. Code size increases and performance is stressed

2. More Threads

   a. More functionality add more tasks

   b. Memory utilization and system resources are stressed

   c. Debugging thread issues and performance bottlenecks harder

3. Larger code tree

    a. Harder to exercise all code paths without external stimulus

    b. Harder to measure rare function execution paths

    c. More error handlers and recovery systems to debug

Testing Solutions for Gigabit Ethernet Systems  

        Up until now, if an embedded system had a 10/100 Mbps copper interface it could be marginally tested by the unpredictable packet generation of the local LAN. The embedded space was catching up to network technology, so 10/100 Mbps Ethernet in most cases was present on the lab LAN, as the product was being designed.

     Now, optical networks may or may not be present in the lab. And when they are, they are certainly on a switched network making packet stimulus for testing the new system more difficult. Moreover, the demands for Quality of Service (QoS) require embedded devices to be designed and tested with a more intelligent network stimulus.

     The buses used in Gigabit Ethernet are faster and more complex than those used in the 10/100 Ethernet. So in addition to known data on the Gigabit Ethernet cable it may sometimes be necessary to correlate bus activity with the network data. In the base step Singulus G1™ can stimulate a DUT with user defined network packets at line rate. Singulus G1™ provides counter and error statistics for all traffic on the wire. In this first setup, the engineer can test component compliance, verify hardware assembly, test register and semiconductor setup, test bus setup, processor ISR handling and test thread operation. In addition, stimulus and counters are effectively used for verifying and developing embedded drivers for buffer management and performance.

                    First Setup: Singulus G1® and DUT (Power PC 405 with GB Ethernet on PCI)

        When there is a need to capture traffic and analyze the content of packets, the engineer can use the Tektronix Logic Analyzer (TLA). The second setup shows an example of a TLA capturing line rate traffic from the DUT while the Singulus G1™ stimulates the DUT and records counters. The LA provides deep capture as well as filters and triggers.

   Second Setup: Singulus G1™, Tektronix 600 Series LA and DUT

     Other solutions can be architected by using cross triggering with other Tektronix probing equipment. The third setup for example shows a DUT being stressed under line rate stimulus while being probed with the Tektronix Oscilloscope TDS 3032. The fourth setup includes both the TDS 3032 and the Tektronix Logic Analyzer.

 Third Setup: Singulus G1™, Tektronix TDS 3032 Series Oscilloscope and DUT 

 Fourth Setup: Singulus G1™, Tektronix 600 Series LA, Tektronix TDS 3032 Series Oscilloscope and DUT

These are some basic examples of how Singulus G1™ integrates the engineering lab and helps the engineer over come the complex problems of Gigabit Ethernet solutions in an embedded system.

FUTURE TRENDS

      Embedded systems are the applications that fuel some of the microprocessors that play a hidden but crucial role in our everyday lives. These are the tiny, quick, and smart microprocessors that live inside printers, answering machines, elevators, cars, cash machines, refrigerators, thermostats, wristwatches, and even toasters. Embedded systems are on the cutting edge of consumer electronics, poised to revolutionize various technologies by making them "smarter." A branch of the embedded-systems industry wants to see some of this newly smart equipment hooked up to the Internet, so that networking capabilities become a ubiquitous feature of modern machines.
        Some experts estimate that embedded systems technology, which in 1998 is a $250 million industry, will be worth more than $2 billion within three years. Predictions are based on the commercial promise of smart devices. According to market researchers, consumers love electronic equipment that can do "smart" things like: transmit instructions to other devices wirelessly via infrared signals; be programmed to operate automatically; and connect to super-technologies, such as satellites, to bring remote power into their own hands.
        An embedded system consists of two components: a compact, ultra reliable operating system that controls the microprocessor inside a device, and the suite of applications that runs on the operating system. Various corporations are racing to develop embedded systems for Internet-enabled devices, which include network computers (also called Internet appliances or thin clients), Internet phones, and traditional machines embedded with Internet connections -- such as printers, various medical devices, and thermostats.
       The thermostat in a family home is an example of a theoretical Internet-enabled appliance of the future. The thermostat would be embedded with a smart microprocessor that supports an Internet server connection, a Web browser (and screen) for viewing Web information, software and graphics for programming and displays, and a protocol for communicating with the Internet.    Users would be able to program the thermostat to gather information from the Web, such as local weather forecasts, to use in regulating the temperature of the house. In addition, users would be able to contact the thermostat remotely, via the Web, to instruct it to alter its settings.
        Internet-enabled appliances might also become a staple of the future version of the home entertainment center, the "digital data center." A multimedia set of living-room devices might include, for example, a digital television that doubles as a personal computer, Web browser, and e-mail host; a stereo that can download tunes off of the Internet; and a video camera that can record the kids' pillow fight, send the video images directly onto the Web, and install them on the family's home page.
        Cisco, Wind River Systems, Sun Microsystems, Integrated Systems, Microware Systems, and QNX Software Systems are among the prominent developers of embedded systems. In December 1998 Microsoft held a "soft" or low-publicity launch of AutoPC, a car stereo with a Windows-based operating system, featuring voice recognition, wireless messaging, and a global positioning system (GPS). The several-thousand-dollar price tag is sure to limit AutoPC's popularity for a time -- but that price is just as sure to drop in the coming years.

         The world envisioned by embedded-systems engineers and executives is one in which the long fingers of the global Internet stretch and reach into every conceivable aspect of the modern person's life. With the fast pace of technological progress, that future may be right around the corner.

CONCLUSIONS:

Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. In particular, the demands of the specific application and the interface with external equipment may dominate the system design. Also, long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput.

Recent interest in hardware/software codesign is a step in the right direction, as it permits tradeoffs between hardware and software that are critical for more cost-effective embedded systems. However, to be successful future tools may well need to increase scope even further to include life-cycle issues and business issues.

REFERENCES

• PCQUEST  (MAY 2001)
• Daniel D. Gajski, Frank Vahid, Sanjiv Narayan & Jie Gong, Specification and  

      Design of Embedded Systems, PTR Prentice Hall, Englewood Cliffs NJ, 1994.

• www.google.com
• www.search.com
• www.altavista.com
• www.askjeeves.com
• www.abcsearch.com