TECH FEATURE
VME
2eSST VME Eases Design of Network-Centric Embedded Systems
The traditional embedded computing model has been fraught with obstacles and headaches. That is changing as technology advances create the possibility for a new “network-centric” approach to embedded computing that is shaking up the traditional industry.
DAVE BARKER AND BOB TUFFORD, MOTOROLA EMBEDDED COMMUNICATIONS COMPUTING GROUP
At the upper end of the embedded computing spectrum, there isn’t much of a notion of a “stand-alone” device anymore. Embedded computing isn’t just about a single processor monitoring and controlling some devices. Today’s high-end equipment can more accurately be described as embedded communications computing, which consists of multiple processors, multiple boards or multiple systems operating in a network with other equipment or systems. The processors in this “network” need to communicate to make the equipment function properly. What has been commonly referred to as “distributed processing” has been a growing part of embedded computing for a number of years. The “network” in a distributed processing application could be the VMEbus, the PCI bus, Ethernet or a proprietary interconnect like Race++.
The software environment in the traditional embedded computing arena has been fragmented, with many small Real-Time Operating System (RTOS) vendors and equipment manufacturers developing their own proprietary kernels. This resulted in a fragmented software market with many RTOSs that did not work together and required considerable effort to maintain and to port to new hardware.In addition, the only standard, widely used communications protocol was TCP/IP, but this was not generally adopted in the embedded computing space because of a lack of performance and software stacks in the fragmented RTOS arena. As a result, many proprietary communications protocols and transports were developed over the years to provide the performance required by embedded computing applications. Because there were no standardized data formats or protocols, it was not practical to interconnect heterogeneous equipment from multiple vendors.
Network-Centric Computing
Network-centric computing is based on interconnecting all of the computing elements using a common networking architecture (e.g., Gigabit Ethernet). Abstracting the hardware implementation means that applications may not have any knowledge of the underlying hardware and the same application software can run on any computing element in the network.
This shift to network-centric computing is being driven by necessity. Market demands are requiring equipment manufacturers to create bigger, faster, better systems, which equates to more complex environments. Traditional distributed processing methods are too hard to scale as the complexity of systems increases. Equipment manufacturers need an easier way to make multiple processors/boards/systems communicate so they can focus on serving the needs of their market. The network-centric computing model allows this. There are two major factors enabling this shift to network-centric computing.
The first of these factors is the advancement in networking technologies. Ethernet and the Internet Protocol (IP) are ubiquitous. Networking using Ethernet is inexpensive, easy to implement and it allows companies to leverage their existing networking infrastructure. The performance of Ethernet is continuing to increase from 10 Mbits a few years ago, to 100 Mbits, to Gigabit Ethernet today, and moving to 10 Gbit Ethernet in the near future with the benefit of powerful TCP/IP Offload Engines (TOEs) to boost performance even further.
The other factor has to do with software. The embedded computing software market has matured, resulting in considerable consolidation in the RTOS market. Linux is finally gaining traction within the embedded computing market with the release of Linux 2.6. These changes in the embedded computing software arena have made it practical for companies to develop middleware to make it easier for multiple processors, boards and systems to communicate and share data. With the right middleware, multiple heterogeneous hardware platforms can be supported and data can be freely exchanged between them.
Embedded communications middleware is a key element supporting the shift to the network-centric model because it allows developers to focus their efforts on their application rather than having to deal with writing code for specific hardware platforms. The equipment manufacturers are no longer tied to specific hardware implementations or specific hardware vendors. They are free to use the hardware platform that is best suited for each area of their application such as the user interface, data processing, real-time control, data storage, etc.
Various industries have standardized on communication protocols and middleware to support their chosen communication mediums. The telecom market has been a leader with the standardization on Ethernet and communication and management middleware to support the development of complex telecommunications infrastructure equipment. The industrial automation market has shifted from proprietary networks to factory networks based on Ethernet. The medical industry has standardized on Picture Archiving and Communications Systems (PACS) and Ethernet. The United States Navy has been working on its Open Architecture (OA) Initiative, which is centered on Gigabit Ethernet, Data Distribution Service (DDS) and Common Object Request Broker Architecture (CORBA) middleware.


Kontron
Interphase