The magazine of record for the embedded computing by RTC Media

FEATURED

in this issue

The magazine of record for the embedded computing industry

April 2007

Ethernet Adapts • for Industrial Control

www.rtcmagazine.com

VME, CompactPCI and DSP

TEAM for SCIENCE "Keeping Cool" • with ATCA Java Goes Real-Time • ...Really!

Curtiss-Wright's

Tom Quinly:

“The Market for VME/VPX . . . will continue to grow.”

An RTC Group Publication

FAST-FORWARD YOUR PROJECT WITH WINDOWS® EMBEDDED. Change happens. Don’t let it slow you down. Get to market faster with end-to-end development toolkits, building blocks to create tailored solutions, and the support of a highly qualiﬁed partner community. See how Magellan cut six months from development of its devices at microsoft.com/embedded © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, the Windows logo, and “Your potential. Our passion.” are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Slow Motion?

Fast Finish.

GE Fanuc Embedded Systems

Simplify. Start your search with Neternity™, our extensive line of Ethernet switches. Locating the perfect embedded Ethernet switch can be messy, unless you start your search at gefanucembedded.com. You’ll find nearly every possible form factor, protocol and configuration, including IPv6, PICMG® 2.16 and RoHS compliant models and switches with 10Gb/s links. We have switches with Layer 2/3 switching and routing; switches that support IPv6 switching/ routing in hardware; plus rugged switches capable of withstanding extreme environments. All this

backed by our strong engineering team with years of experience in the business. As if that weren’t enough, many Neternity™ switches also feature OpenWare™, our powerful Linux®-based suite of protocol stacks and management tools optimized for embedded applications. So save yourself a lot of time and trouble and put “Check out Neternity™” at the top of your To Do list.

Neternity RM921 IPv6 Gigabit Ethernet Switch with OpenWare

www.gefanucembedded.com/neternity

Departments 7

Editorial: How May I Network Thee? Let Me Count the Ways

Industry Insider

www.rtcmagazine.com

60 Products & Technology

Features Technology in Context

Controllers for High-End Science

12 V ME, CompactPCI & DSP Team Up to Control Giant Telescope Tom Williams

Solutions Engineering

Industrial Ethernet

20 E thernet Powerlink: A Deterministic Alternative for Distributed Control Frank Foerster and Bill Seitz, IXXAT

24 E therCAT: Implementing Deterministic Control over Ethernet Hardware Torsten Sehlinger, Sysgo and Gerhard Spiegel, Koenig Prozessautomatisierung

28 R apidIO and Ethernet for Backplane Applications: A Practical Technical Comparison Greg Shippen, Freescale Semiconductor and RapidIO Trade Association

Industry Insight Thermal Management on ATCA

Engineering drawing of the LBT showing the LBT interferometer mounted at instrument stations between the two mirrors. Instruments mounted on swing arms above the mirrors can be used to quickly change the configuration of the telescope. From top to bottom are the secondary mirrors, which will incorporate the adaptive optics, the primary focus camera and the tertiary mirror, which diverts the beam to the instrument stations. Below the mirror cells are place holders for instruments that can be placed at the Gregorian focus. • Pg. 12

36 T hermal Interoperability Challenges ATCA Systems Dave Baker and Dan Carter, Intel

40 Designing ATCA Cards for Optimal Thermal Performance in Managed Chassis Mike Coward, Continuous Computing

46 A utomated Thermal Characterization of ATCA Shelf, Blades Delivers Thermal Interoperability Todd Keaffaber and Rajesh Nair, Communications Platforms Trade Association

Executive Interview 50 R TC Interviews Tom Quinly, CEO, Curtiss-Wright Controls Embedded Computing

Ethernet HDR

Data

CRC

Several EtherCAT frames included in one Ethernet packet • Pg. 24

Software & Development Tools Real-Time Java 54 T rade-Offs in the Design of Hard Real-Time Java Technologies Kelvin Nilsen, Aonix

Cover Photo: This color image of the face-on spiral galaxy, NGC 6946, was taken at LBT on 18 September 2006. NGC 6946 lies at a distance of about 16 million light years from Earth. The false-color composite was made from images taken through near-ultraviolet, blue, and green filters, using one primary mirror and one Large Binocular Camera (blue optimized). Source: LBT. Photo credits: Vincenzo Testa and Cristian DeSantis; Observatory photo: John Hill

Device Server Automages Remote Equipment with Real-Time Event Management • Pg. 60 April 2007

April 2007 Publisher PRESIDENT John Reardon, johnr@r tcgroup.com EDITORIAL DIRECTOR/ASSOCIATE PUBLISHER Warren Andrews, warrena@r tcgroup.com

Editorial

EDITOR-IN - CHIEF Tom Williams, tomw@r tcgroup.com SENIOR EDITOR Ann Thr y f t, annt@r tcgroup.com MANAGING EDITOR Rebecca Bauer, rebeccab@r tcgroup.com COPY EDITOR Rochelle Cohn

Art/Production

CREATIVE DIRECTOR Jason Van Dorn, jasonv@r tcgroup.com PRODUCTION DESIGNER Kirsten Wyatt, kirstenw@r tcgroup.com GRAPHIC DESIGNER Barr y Karsh, barr yk@r tcgroup.com DIRECTOR OF WEB DEVELOPMENT Marke Hallowell, markeh@r tcgroup.com WEB DEVELOPER Brian Hubbell, brianh@r tcgroup.com

Advertising/Web Advertising WESTERN REGIONAL SALES MANAGER Lauren Hintze, laurenh@r tcgroup.com (949) 226 -2014 EASTERN REGIONAL SALES MANAGER Nancy Vanderslice, nancy v@r tcgroup.com (978) 443 -2402 EMEA SALES MANAGER Marina Tringali, marinat@r tcgroup.com (949) 226 -2020 BUSINESS DEVELOPMENT MANAGER Jessica Grindle, jessicag@r tcgroup.com (949) 226 -2012

Billing

Mag gie McAuley, mag giem@r tcgroup.com (949) 226 -2024

Our heatsinks are

DOWN RIGHT frosty Introducing our new INL Series: aluminum plate n, low prole, high efciency cooling products. They attach easily with our EZ SnapTM mounting clips

Buy on-line at: www.radianstore.com

The INL series is an off-the-shelf solution which provide optimum cooling for various package sizes and airow.

web: www.radianheatsinks.com tel: 800-689-2802

fax: 408-988-0683

Radian Heatsinks is a division of Intricast Company Inc.

April 2007

To Contact RTC magazine: HOME OFFICE The RTC Group, 905 Calle Amanecer, Suite 250, San Clemente, CA 92673 Phone: (949) 226-2000 Fax: (949) 226-2050, www.rtcgroup.com EASTERN SALES OFFICE The RTC Group, 96 Dudley Road, Sudbury, MA 01776 Phone: (978) 443-2402 Fax: (978) 443-4844 Editorial Office Warren Andrews, Editorial Director/Associate Publisher 39 Southport Cove, Bonita, FL 34134 Phone: (239) 992-4537 Fax: (239) 992-2396 Tom Williams, Editor-in-Chief 245-M Mt. Hermon Rd., PMB#F, Scotts Valley, CA 95066 Phone: (831) 335-1509 Fax: (408) 904-7214 Ann Thryft, Senior Editor 15520 Big Basin Way, Boulder Creek, CA 95006 Phone: (831) 338-8228

Published by The RTC Group Copyright 2007, The RTC Group. Printed in the United States. All rights reserved. All related graphics are trademarks of The RTC Group. All other brand and product names are the property of their holders.

Editorial April 2007

How May I Network Thee? Let Me Count the Ways by Tom Williams, Editor-in-Chief

ave you ever stopped to think how many different types of network technologies there are out there? Just the ones that come to mind as I sit here typing this: Ethernet (under that, 10M, 100M, 1G and 10G), Firewire, Fibre Channel, USB, FDDI, EtherCat, Ethernet Powerlink, Profibus, CAN, DSL, DeviceNet, AppleTalk, InfiniBand, RapidIO, PCI Express, StarGen. The list goes on. Then there are all the wireless technologies, and then the worldwide telephone systems along with a host of cellular systems and the Internet. It’s difficult to decide what constitutes a network “technology,” a network “protocol” or a network “topology” because ingenious people have figured out ways to make most of these things talk to each other. We’ve got gateways, routers, switches, protocol converters, DNS servers, base stations, server farms, satellite links—all the way down to kids with tin cans and strings. Most of us spend our days trying to keep up with the needs of the market and consulting gurus, analysts and chicken entrails trying to figure out what the needs and direction of that market are. At the same time technology keeps advancing. Barely are we coming to terms and actually seeing installation of 10G Ethernet than 100G starts to appear on the horizon. Looming behind all that is the expectation of IMS—IP Multimedia Subsystems—which, among other things, will be used to support “triple play,” the integrated delivery of voice, data and video over an IP network. A recent study has revealed that the adoption of IMS is running about two years behind what had been expected. There are various explanations offered including the risks involved, the readiness of consumers to commit to new services, how compelling the appeal of such services may be and so forth. However, I wonder if there may not be something else at work, which, although it involves all the above considerations, has not been distinctly named. I’m talking about legacy infrastructure and that may actually be a many-headed monster. It has long been a truism that the old POTS telephone network would inevitably be replaced by an all-IP network. For the past ten or so years the industry has been diligently building up the Internet, which has indeed been taking over more traditional telephone services and providing the technical basis for additional services. That’s why we see all these nifty diagrams of the network infrastructure with all the services, gateways, routers, switches and

stuff arranged around the “cloud.” The cloud, it was assumed, would inexorably expand and, like the old B-movie, The Blob, devour and digest all the gateways and interfaces that were needed to support the legacy infrastructure, resulting in a brave new world of an all-IP network circling the globe and offering all the traditional services. The question I have—and I don’t know the answer—is, were these assumptions and the associated build-out made without appreciating the demands that a full-blown IMS world network would make on the infrastructure? In other words: Has the recently deployed IP network, essentially today’s Internet, itself become a legacy infrastructure? Will it serve as a basis on which to build technologies capable of delivering the volumes of data at the bandwidths required to support a planet of IMS users? If there was unwillingness to simply junk the old POTS network and start over, there will be even less inclination to do so with the existing IP network. Does that mean that IMS will represent a new “cloud” taking shape that will one day engulf the cloud that ate POTS? It’s probably an easier transition in any event since the move to IMS will at least be based on the same set of protocols and will not need to deal with all the gateways and protocol issues all over again. And, we can probably still use all the “legacy” IP hardware. We’ll just need more of it until faster stuff comes on line, so that’s not a terrible impediment. However, it may be that the issue of “pipes” does represent a real hurdle. It seems inescapable that everything will have to move to fiber and that wireless bandwidth will eventually be overwhelmed. But don’t despair. Back when the telephone first came into being there were those who said it would never amount to much because to do so, we would have to string wires over the whole country. Yeah . . . So to support the dream of IMS, it looks like we are going to have to make some radically larger assumptions about infrastructure. That means bigger and more powerful servers, but we knew that. It also means going to an almost exclusively fiber opticsbased Web—and that all the way to the home and office. POTS will be completely digested and the current IP network absorbed and integrated. Hey, that’s not so bad as long as the needed investment does not intimidate the acceptance by users. And that may additionally help explain why it is taking longer than we thought. We have to adjust our assumptions. April 2007

Positions available in northern NJ

Your career drives their success and returns them home safely

Our technologies make a positive difference every day. Thanks to our talented employees, we develop applications that meet our customers' exacting requirements and tackle some of the world's most complex problems. Inclusion and diversity at ITT allow us to leverage differences and generate innovation. Now you can make a difference, too. Join the ITT team and watch your career take flight.

Visit us online at www.defense.itt.com/careers_main.htm

Select "Join Our Team" to find your geographic preference.

Domestic and International opportunities available. Most positions require U.S. Citizenship and the ability to obtain a security clearance. An equal opportunity employer.

Communications Sensing & Surveillance Space Solutions Advanced Engineering & Integrated Services

Industry Insider

April 2007

Study Shows IMS Deployment Two Years Behind Venture Development Corporation has compared its first edition of the IP Multimedia Subsystem (IMS): Global Market Analysis to the just-published 2nd edition, and has found that fully compliant and operational IMS deployments are 24 months behind the original forecast. VDC has found that most of the early adopters of the complex model are taking a go-slow approach to deployment. VDC had forecasted in the 2005 edition of the IMS study from data supplied by vendors and service providers that functionally complete IMS infrastructures would be operational in 2008—new data now indicates that this will happen most likely in 2010 or later. This raises the specter that full IMS deployments could be an infinitely receding opportunity. Respondents gave many reasons for this, according to VDC, but it all comes down to the lack of a strong business case based on revenue increases. Many pointed out that while a multitude of cost savings benefits can come from IMS, the savings by themselves did not provide a compelling reason to go full-speed ahead.

IMS Adoption Timeline Ideal IMS

Real IMS

Some IMS

Pre IMS

Not IMS 2005

2006

2007 2007 Viewpoint

2008

2009

2010

2005 Viewpoint

Still, professional services appear to present a major opportunity because of the complexity of the IMS reference model. Service providers will be looking for companies that can engineer the network fabric from its piece parts in situ and ensure that it fits seamlessly with existing infrastructure. Application providers stand to gain the most from successful IMS. The applications they provide will be limited only by the willingness for the communications subscribers to consume and will not be limited by broadband access or any other secondary effect. Once the service providers are convinced that applications exist to warrant a shift to IMS reference models, the floodgates will open to this community and only the limitations placed by the service providers will limit the innovation and penetration.

Mountain View Alliance Holds Inaugural Comms Ecosystem Conference

The Mountain View Alliance (MVA), a consortium of open specification organizations in the communications industry, held its MVACEC—the first and only event to address the breadth of issues of building open specifications-based commercial offthe-shelf equipment for the carrier grade platforms used in the wireless, service provider / telecom and Internet infrastructure markets. The conference opened with Rob Davidson, representing the Mountain View Alliance, reviewing “Why This Event – Why Now.” Mr. Davidson was followed by keynote speaker Mark Kent, head of technology for BT Global, as he demonstrated the true progress of open specifications and the challenges being faced from an operator’s perspective (visit www.mvacec.com to view Mr. Kent’s keynote presentation). Leading representatives from BT Global, Ericsson, IBM, Intel, Motorola, NTT, Nokia, Verizon, and many more throughout the industry gathered for the event in San Diego, California. Tom Cox, executive director of the RapidIO Association, was excited with the outcome and stated, “MVACEC was an attendee mix of the whole communications ecosystem that you don’t get anywhere else. The eight MVA special interest groups each reach a different audience, all with a vested interest to be here. This conference brought focused players in both hardware and software.” The Mountain View Alliance mission is to accelerate the adoption of platforms and building blocks based on the specifications of member organizations. The goal of the MVA is to optimize effectiveness of its member organization through coordinate marketing activities including joint trade show participation, joint meetings, April 2007

Industry Insider

and outreach activities. As the need arises, the MVA will also facilitate multi-faceted cooperation between its member organizations. Through such activities, the MVA aims to promote a diverse and thriving ecosystem of open specification-based components and platforms. MVACEC will be presented in Northern California’s Silicon Valley in March 2008.

RapidIO Specification 1.3 Approved as ANSI Standard

The American National Standards Institute (ANSI) has approved RapidIO Interconnect Specification 1.3 as a new ANSI standard. RapidIO technology is a scalable, packet-switched, highperformance fabric specifically developed to address the needs of equipment designers in the wireless infrastructure, edge networking, storage, scientific, military and industrial markets. “The approval of the RapidIO specification as an ANSI standard is further testament to the technology’s market momentum,” said Tom Cox, executive director of the RapidIO Trade Association. “The ecosystem is strong and OEM developers have a solid base of products for use in their designs.” Accreditation by ANSI signifies that the procedures used by the standards body in connection with the development of American National Standards meet the Institute’s essential requirements for openness, balance, consensus and due process. The American National Standards process includes consensus on a proposed standard by representatives from materially affected and interested parties as well as broad-based public review and comment on draft standards.

KSE and ObjectAutomation Complete Merger

KSE Protech and ObjectAutomation Corporation (OA) have joined forces in a move that combines OA’s industrial automation and distributed process control technology with KSE’s strengths in global automation software and hardware solution delivery. 10

April 2007

The resulting company, known as OA International (www.oa.com), is now a 200+ employee global automation solutions provider. KSE Protech has been an OA business partner for eight years. In that period, KSE has been successful in developing and delivering OA software and hardware solutions to several industries across Europe, the Middle East and Asia. ObjectAutomation develops object-based industrial automation solutions. The OA core product allows for graphical PC-based and embedded control, HMI and process visualization, alarms and event notification, data historian and trending, and Web-based visibility. The newly merged OA International will focus its efforts into four major industry verticals. In the Food and Feed industry, OA International offers solutions for production control, batch processing, recipe management, tracking and tracing and specific operational solutions for intake, dosing, weighing, mixing, pressing and outbound loading. Energy and Utilities customers use OA to control and monitor pipelines, wells, compressor stations, electric power grids and water / wastewater treatment operations. In Industrial Manufacturing, OA is used for production automation, equipment control, track and trace and quality / laboratory control. And in Industrial Services, OA provides solutions for airport management, material handling automation and tank storage.

Open Source High-Availability Operating Environment Based on SAF Standards

Motorola has announced it is initiating a new open source project to develop a complete high-availability operating environment based on Service Availability Forum (SAF) standards. The objective of the new “OpenSAF” project is to accelerate broad adoption of an SAF-compliant operating environment. The goals of the OpenSAF project involve creating an open source implementation of a highavailability operating environment that includes the SAF Application

Interface Specification (AIS) as well as developing necessary additional complementary services necessary to deploy and manage the software. The aim is also to accelerate the development of SAF specifications by proposing enhancements implemented in the OpenSAF project. The effort hopes to establish a broadly adopted highavailability operating environment that can be leveraged by computing technology companies, NEPs and other industries requiring high availability, and ISVs. This can be enabled by Utilize, an open source licensing model not tied to any commercial implementation. With this approach, network equipment providers (NEPs) will be able to leverage the implementation of a deployed high-availability software platform with the knowledge that enhancements will be proposed to the SAF for inclusion in future open specifications. NEPs also will be able to help service providers lower operating costs by using a common software platform across multiple types of equipment. Common predictive actions and common provisioning and monitoring interfaces will help reduce training and specialization, enabling service providers to use their resources more flexibly, efficiently and productively. Both Motorola and Ericsson will contribute resources from the beginning of the initiative to enhance the open source product and accelerate the development and deployment of SAF specifications based on industry requirements. Motorola initially will contribute its NetPlane Core Service (NCS) software to the OpenSAF project. NCS is a complete operating environment that includes SAF services and a complementary set of required services necessary for a deployable implementation.

Biometrics Research Getting Boost with $500,000 NSF Grant

A West Virginia University faculty member was recently awarded a $500,000 grant from

the National Science Foundation (NSF) for research in biometric systems. Arun Ross, an assistant professor in WVU’s Lane Department of Computer Science and Electrical Engineering in the College of Engineering and Mineral Resources, received the NSF’s Faculty Early Career Development Program Award (CAREER). The grant will be used for biometrics research over a five-year period. Biometrics is the science of establishing human identity based on physical or behavioral traits. WVU has the only undergraduate degree program in biometric systems in the nation. The research is expected to have a positive impact on the design and development of large-scale multibiometric systems for identity recognition management. In addition, this research will enhance the current biometrics curricula, engage students in cutting-edge research and promote the use of biometric technology in diverse applications. Ross is one of the key faculty members conducting research for the WVU Center for Identification Technology Research (CITeR), an industry/university cooperative research center that provides a method to leverage research conducted in academia into industry. Along with CITeR founding director Larry Hornak, Ross also has been instrumental in establishing the Multibiometric Data Collection Laboratory at WVU.

ESLX Joins VaST’s Galaxy Network of SystemC Services Providers

VaST Systems has announced that ESLX has joined its Galaxy network of SystemC service providers. VaST’s Galaxy Network provides SystemC training and services to help customers ramp their engineering competency in SystemC-based systemlevel design. ESLX is a consulting services company specializing in system-level hardware and software design methodologies.

Industry Insider

ESLX has guided the evolution of electronic system level (ESL) methodologies through active participation in standardization bodies, the development of educational materials and the delivery of cutting-edge ESL consulting and training. This experience makes ESLX well suited to propel its customers through the adoption of ESL methodologies, languages and tools such as those offered by VaST Systems. VaST solutions have contributed to the adoption and proliferation of SystemC. VaST’s system-level modeling tools deliver on the long-standing promise of enabling concurrent hardware and software design that make SystemC a hugely popular modeling language. VaST, together with ESLX and other ecosystem partners, delivers complete endto-end solutions to accelerate realization of the productivity gains afforded by system-level design.

Event Calendar 04/29-05/01/07

05/17/07

05/30-06/01/07

53rd Int’l Instrumentation Symposium (IIS) Tulsa, OK www.isa.org

Real-Time & Embedded Computing Conference Austin, TX www.rtecc.com/austin

AdvancedTCA Summit / MicroTCA Summit 2007 Baltimore, MD www.microtcasummit.com

04/30-05/02/07

05/21-22/07

06/12/07

IT360o Conference & Expo 2007 Toronto, Canada www.it360.ca

Int’l Service Availability Symposium 2007 (ISAS) Durham, NH www.saforum.org

Real-Time & Embedded Computing Conference Chicago, IL www.rtecc.com/chicago

05/21-23/07

06/14/07

Microprocessor Forum San Jose, CA www.instat.com

Real-Time & Embedded Computing Conference Minneapolis, MN www.rtecc.com/minneapolis

05/08-11/07 JavaOne Conference San Francisco, CA www.java.sun.com

05/15/07 Real-Time & Embedded Computing Conference Dallas, TX www.rtecc.com/dallas

05/22/07 Real-Time & Embedded Computing Conference Houston, TX www.rtecc.com/houston

If your company produces any type of industry event, you can get your event listed by contacting sallyb@rtcgroup.com. This is a FREE industry-wide listing.

Untitled-2 1

April2/9/07 20079:38:21 AM11

TechnologyInContext

VME, CompactPCI & DSP Team Up to Control

Giant

Photo Source LBT, photo by Wiphu Rujopkam

Telescope A combination of COTS and custom embedded systems are harnessed to bring the precision and flexibility needed to control the worldâ&#x20AC;&#x2122;s largest telescope. Real-time systems are taking another step in the search for Earth-like planets.

by Tom Williams, Editor-in-Chief

April 2007

TechnologyInContext Controllers for High-End Science

hey call them “sky islands,” these mountainous outcroppings that rise suddenly from the Arizona high desert. As if separated in an ocean, each has its own ecosystem and unique character. The highest of these, Mount Graham, rises to an altitude of 10,700 feet above sea level. It is here that the University of Arizona’s Steward Observatory in partnership with the Max Plank Institute and other participants, is building what will for a time be the world’s most powerful optical telescope, the Large Binocular Telescope (LBT). When it is completed, the LBT will have two 8.4 meter mirrors, each of which is over half again the diameter of Palomar. When used together, the mirrors will provide a diffraction-limited image sharpness of a 22.8 meter aperture. Astronomers will be able to use the mirrors in tandem or individually. For example, different instruments on each mirror could capture optical and infrared images of the same object. The binocular design enables a number of unique instrumentation and research possibilities (see Why a Binocular Telescope? p. 17). The LBT weighs approximately 580 metric tons and has a combination of focal stations for different instruments and observation tasks (Figure 1). Accurately pointing, focusing and controlling a precision instrument of this size is an enormous challenge, especially in the light of external factors such as temperature The LBT is an international collaboration among institutions in the United States, Italy and Germany. The LBT Corporation partners are: • The University of Arizona on behalf of the Arizona universities • Istituto Nazionale di Astrofisica, Italy • LBT Beteiligungsgesellschaft, Germany, representing the Max Planck Society, the Astrophysical Institute Potsdam, and Heidelberg University • The Ohio State University • The Research Corporation, on behalf of The University of Notre Dame, University of Minnesota and University of Virginia

April 2007

variations and the buffeting of high winds at such an altitude. It is a challenge that could only be met and overcome through the application of powerful embedded and real-time computing technology consisting of a combination of COTS and custom hardware and software. The open-loop, full-sky pointing accuracy is currently 0.3 arcseconds with a tracking performance of 0.01 arcseconds. Like the end users of any other embedded system, astronomers do not want to have to worry about the details of pointing and controlling the telescope. They want it pointed and focused accurately and reliably so that they can effectively use their instruments and obtain the data needed for their science projects. So the engineering issues in question here are with those tasks rather than with the scientific instrumentation. Basically, the LBT is what is called an “altazimuth” mount. That is, one axis turns in relationship to the surface of the Earth, the azimuth, while the other moves up and down in elevation. This is different from more traditional telescope equatorial mounts in which one axis is aligned with the axis of Earth’s rotation. Equatorial mounts become prohibitive in size for telescopes beyond a certain aperture. To point an altazimuth telescope, a pointing control system must translate the standard location of an object in the sky, which is cataloged in terms of right ascension with respect to 0 degrees longitude, and declination with respect to the equator into altitude and azimuth coordinates for the telescope. These are based on its geographical coordinates and the local time. But that’s the easy part. Once pointed, the instrument has to track the object, incrementally changing its altitude and azimuth settings, as the Earth moves on its axis. In addition to the pointing problem, there is also the issue of optical accuracy. Corrections must be done through a system of adaptive optics to cancel the distortion of the Earth’s atmosphere and the stresses from tilting, and temperature on the 8.4

meter primary mirrors must be sensed and corrected to keep a perfect shape. In the case of the primary mirrors these are small increments, but we are dealing here with the wavelengths of light, and each mirror weighs 41,500 pounds. Accurately moving such a massive piece of equipment is done by essentially “floating” it on a film of oil supplied by hydrostatic bearings and using four powerful motors on each axis with position information gathered from a set of inductive strip encoders mounted on the outer radius of each axis. It also involves a dynamic balance system, which operates by shifting water in and out of ballast tanks to keep the telescope in balance. Three major control systems include the Mount Control System (MCS), the Adaptive Optic System (AOS) and the Primary Mirror Controller (PMC). These operate under the main Telescope Control System (TCS), which includes, among others, the MCS GUI and the Pointing Control System (PCS). The mount control system operates the altitude and azimuth controls, the swing arms, which are used to bring instruments and the secondary and tertiary mirrors into one of the focal points of the telescope, the instrument rotators and the enclosure rotation system. In addition, it interfaces with the stand-alone hydrostatic bearing system, mainly to control the pumps, which provide a film of oil at 1800 psi so that the enormous thing can be moved at all. The mount control system computer is a CompactPCI system from BittWare (Figure 2), which includes an Intel processor-based CPU board running Linux and other boards supporting ten Analog Devices SHARC 21160 DSPs, two Xilinx Virtex II FPGAs as well as subsystems for real-time clock and analog inputs and outputs. Each axis has a cluster for four DSPs plus one FPGA card dedicated to it. Non-real-time state logic and communications tasks run under Linux. The card is a BittWare HH6U cPCI card with eight SHARC processors plus two daughter

TechnologyInContext

boards each with an FPGA and yet another processor for I/O. So this one cPCI card handles the servo logic for both the azimuth and the elevation axes. Much of the DSP code and all of the Linux-to-DSP interface was written by Dan Cox. According to software engineer, Tom Sargent, with a 2 kHz control loop and four dedicated DSPs, there in no need for a real-time version of Linux or an RTOS. “With four DSPs and all kinds of highspeed interfaces between the link ports, which we use, we can have them all operate round robin deterministically—just by using the link ports and interrupts and telling them, ‘I need you to do this now,’ and the DSP will go ahead and do whatever it needs to do.” Get Connected with technology and Among the things the DSPs are jug- companies providing solutions now gling are the inputs from the encoders, Get Connected is a new resource for further exploration which have a specified resolution of 0.005 into products, technologies and companies. Whether your goal is to research the latest datasheet from a company, speak directly arcseconds but thanks to interpolation with an Application Engineer, or jump to a company's technical page, the performed by the DSPs, this has reached goal of Get Connected is to put you in touch with the right resource. 1 Engineering drawing of the LBT showing the LBT interferometer mounted a repeatable resolution of 0.002 Whichever arcsec-level ofFigure service you require for whatever type of technology, instrument between onds. The DSPs resolve the commands Get Connected will help youatconnect with the stations companies and productsthe two mirrors. Instruments mounted on swing arms above the mirrors can be used to quickly change the you are searching for. and polynomials sent from the PCS into configuration of the telescope. From top to bottom are the secondary www.rtcmagazine.com/getconnected control algorithms and commands to the mirrors, which will incorporate the adaptive optics, the primary focus positioning motors as well as taking in abcamera and the tertiary mirror, which diverts the beam to the instrument errations caused by wind and making mistations. Below the mirror cells are place holders for instruments that nor corrections, plus tracking the object as can be placed at the Gregorian focus. the Earth moves while also controlling the Source: LBT instrument derotators (Figure 3). Get Connected with technology and companies providing solutions now The latter are used to correct a prob- eliminate gear play. The circular azimuth degrees under all conditions including Get Connected is a new resource for further exploration into products, technologies and companies. Whether your goal is to research the l lem inherent in altazimuth mounts. In datasheet an axis well as speak a pairdirectly of large C-rings used speeds up to 80 km per hour. fromas a company, with an Application Engineer,wind or jump to a company's technical page, the goal of Get Connected equatorial mount with one axis aligned to drive the altitude axis, are with The interface between the MCS and in touch with the right resource. Whichever levelmounted of service you require for whatever type of technology, Get Connected you connect and productsmany you are of searching to the axis of the Earth, the telescope can large will rimhelp gears drivenwith by the thecompanies motor pinion thesefor. subsystems, except for www.rtcmagazine.com/getconnected track an object in the sky without the field gears. The motors are also equipped with the main axes and instrument derotarotating around it. With an altazimuth optical shaft encoders. tor hardware, takes place via an Allenmount, the camera or instrument must be The observatory building moves inde- Bradley ControlLogix programmable rotated in the opposite direction to com- pendently of, but in synchronization with, logic controller (PLC). Referring to the pensate for field rotation. Tracking is done, the telescope. It has large, vertical open- MCS, Tom Sargent remarks, “It’s amazaccording to Sargent, by the PCS emitting ings that are open during observing ses- ing how this thing can make a 600-ton polynomials for both axes and the appro- sions in order to keep the optics as close telescope twitch.” priate derotators, which fortunately have to ambient temperature as possible, but it There are certain other factors that drive motors and shaft encoders similar to still presents a huge profile to the wind. affect the pointing accuracy of the telethe motors controlling the axes. The building moves on four large bogies scope but are not under the control of the In the case of the axis motors, one (Figure 4), each of which has two large Get the Connected companies and The building, under control pair supplies torque to move azimuthwith AC motors. Get Connected products featured in this section. with companies mentioned in this article. axis on its hydrostatic bearings, while the of the enclosure rotation controller (ERC), www.rtcmagazine.com/getconnected www.rtcmagazine.com/getconnected other pair supplies some reverse force to must follow the telescope within =/- 1.5

Ad Index

Products

End of Article

April 2007

Get Connected with companies mentioned in this arti www.rtcmagazine.com/getconnected

TechnologyInContext

Figure 2

This CompactPCI chassis from BittWare contains the mount control system processing unit (MCSPU). Photo: Tom Williams

TCS

Control LAN Mount Control System

MCSPU Main Axes Hardware

PLC LAN TPLC

Instrument Rotator Hardware

Swing Arms Hardware

Dynamic Balance Hardware

ERPLC Mirror Cover Hardware

Enclosure Rotation Hardware

Hydrostatic Bearing System

Figure 3

The mount control system directly controls the main axes and instrument rotator hardware and connects via a PLC LAN to the telescope PLC with interfaces to other mount control subsystems. Source: LBT

MCS. The MCS can detect and correct for wind disturbances on the telescope (as opposed to the enclosure) in real time by means of the inductive encoders and the MCS software. However, the effects of 16

April 2007

temperature and flexure of the structure cannot be detected by the MCS and must be corrected optically. These involve the primary mirror controller (PMC) and the adaptive optics system (AOS). Flexure in

the structure is about 1 mm top to bottom and can mostly be taken care of by adjusting the primary mirror. The primary mirror is big and heavy and does not lend itself to real-time control The AOS corrects for atmospheric turbulence by changing the secondary mirror shape to cancel the refractive effects of the atmosphere. The application of adaptive optics corrections to the secondary mirror as a facility instrument is a first in astronomy. Normally, it is done by means of a much smaller forth or fifth mirror in the optical path. The AOS consists of a wavefront sensor, which detects the optical distortions in the atmosphere and sends data to a custom-built DSP box called the “slope computer” that computes the needed shape of the secondary mirror in terms of an array of slopes. The slope computer then sends commands to an array of 672 actuators that bend the mirror at an update rate of 2 kHz. That is, the system can sense, compute and reconfigure the mirror 2,000 times per second, including the latency of the actuators. The computational task is immense. The wavefront sensor consists of a pyramidal lens over a two-dimensional sensor. The sensor is looking at a reference star during observation. The patterns formed on the sensor must be computed as two-dimensional parameters then into slope data and finally into positioning commands to the actuator array. Each DSP controls four actuators for a total of 168 DSPs in the system. A slope is formed by the position of sensors in relationship to each other over the back of the mirror. In addition, the software includes safety checking so that no combinations arise that could break the glass mirror. The secondary mirror in the LBT is 911 mm in diameter and the glass shell is only 1.6 mm thick. The third major control system in the LBT is the primary mirror controller—one for each mirror. Each primary mirror is made of a single piece of borosilicate glass weighing 41,500 pounds and is 0.894 meter thick at the edge, narrowing due to the convex shape to 0.437 meter at the center. The mirrors are thinner at the center (where there is a 1-me-

TechnologyInContext

ter hole for a focal station) because the concave surface was formed by melting the glass in a 10-meter diameter rotating furnace and then cooling it. During this process a honeycomb pattern was formed in the back by the melted glass shaping around forms set up in the bottom of the mold. A mirror of this size will experience some change of shape due to sagging when the telescope is repositioned and temperature can also affect the mirror shape (Figure 5). Each PMC is built on a VME rack that includes a Cougar-10 board based on the PowerPC 7410 running at 550 MHz from Curtiss-Wright Controls Embedded

Computing. The Cougar-10 boards run VxWorks from Wind River Systems. According to Christopher Biddick, the software engineer responsible for the PMC, the I/O subsystem includes RS-422 serial interface cards, a 48-bit parallel card and a 12-bit A/D card all from Acromag. These go out to custom cards based on the 18F252 PIC microcontroller from Microchip Technology that control the actuators in the primary mirror cell. One VME card controls one mirror via 160 pneumatic actuators glued to the back of the mirror. 108 of these are dualaxis actuators—one vertical and one attached at a 45° angle—and another 52

are single-axis actuators. This arrangement gives the mirror six degrees of freedom: in the X, Y and Z directions and in “moments” around each X, Y and Z axis. Six so-called “hard points” measure the position and force exerted by the mirror on them and this data is used to control the actuators. When the telescope tilts, there are slight but measurable effects from gravity that change the mirror’s position and its shape—again, we are dealing with the wavelengths of light. The data from the hard points is computed to issue commands to the actuators in order to equalize the forces on the

Why a Binocular Telescope? There are a number of instruments and experiments that can take advantage of the Large Binocular Telescope. For example, there is a high-resolution spectrograph with dual independent polarimeters that will be able to simultaneously linearly and circularly polarize light with high spectral and temporal resolution. Another advantage is interferometry—the ability to combine two input waves of light to produce a different output wave. By combining the waves at the same or different phases, they can be added to each other or made to cancel each other. One interferometer, called LINC-NIRVANA, will provide a beam combiner to allow imagery over a wide field of view. When used with the LBT in so-called Fizeau mode, it will provide the sensitivity of a 12-meter telescope and the spatial resolution of a 23-meter telescope over a field of approximately 10 to 20 square arcseconds. Another interferometer is the NASA-funded LBT Interferometer (LBTI). It is partly being developed to study the technique that will be used later in NASA’s orbiting terrestrial planet finder (TPF). On the one hand, the LBTI will be able to combine the light from the two beams for an effective aperture of 23 meters resulting in an ability to produce images ten times the sharpness of the Hubble Space Telescope. Its other use for planet detection will be as nulling interferometer. The difficulty with discerning terrestrial-size planets around stars is that such planets are so small with respect to the star and so relatively close that they cannot be seen due to the glare of the starlight. The LBTI incorporates a universal beam combiner, which brings in the two beams to a common focal plane and the nulling interferometer, which adjusts the phases of the wavelengths of starlight to suppress the light

Figure

The LBTI will be placed between two instrument stations at the bent Gregorian focus between the two mirrors of the LBT. The beams from each mirror will be combined and phased and sent to an imaging camera and instruments at the bottom of the vertical section.

from a star. A nulling optimized mid-infrared camera (NOMIC) will then be used to form an image of the field around the star and detect infrared emissions from any surrounding disks of dust and/or planets thanks to the high resolving power of the telescope. The plan is to survey a large sample of nearby stars to try to determine what percentage of stars may have make-ups similar to our solar system and which stars may potentially have terrestrial-sized and potentially life-bearing planets. The holy grail of such a search would, of course, be to detect the spectral lines for water.

April 2007

TechnologyInContext

hard points and assure a perfect shape. As with the secondary mirror, there are combinations of forces, which, if

Figure 4

Figure 5

applied, could break the mirror. So the software must guard against any and all such cases.

One of the bogies beneath the enclosure building used to rotate the telescope enclosure. Photo: Tom Williams

One of the LBT’s 8.4 meter primary mirrors. The circular openings to the right are stations with derotators for mounting instruments at the bent Gregorian focus, which requires that the tertiary mirror be positioned in the light path. Photo: Tom Williams

April 2007

The effects of temperature are also monitored and controlled by the PMC, mainly by maintaining the mirror as close to ambient temperature as possible. The specifications call for a temperature gradient of less than 0.1°C across the entire surface of the mirror. The honeycomb pattern in the back of the mirror is ventilated and the system monitors the temperature to keep it within parameters. According to Biddick, there are other corrections the PMC can make. “If, for example, there is astigmatism or other aberrations, then we have the math that will take Zernike coefficients from a camera or imaging system and make corrections.” These coefficients are converted into what are called “surface displacement errors.” The bending modes of the mirrors were calculated using finite element analysis, and, given that knowledge, when there is a need to change the surface displacement the system is able to apply the proper forces based on the bending mode distribution. The Large Binocular Telescope has so many degrees of freedom and so many opportunities for adjustment that a sort of macro-system may be needed to negotiate among the possibilities for the optimum solution. So much precision and control has been applied to such a large device because its assignments will be truly astronomical. The realistic hope is that with this Earth-based instrument it will be possible to get far better images than currently possible with the Hubble telescope based in space. The instrument packages that will be used with it demand the utmost in pointing precision and image stability. These are solutions that have been and are being achieved with the concerted application of embedded and real-time computing technology through which we may actually find new worlds supporting life. Large Binocular Telescope Observatory University of Arizona. [www.lbto.org].

Don’t Settle For the Slow Lane

0 to1.5 GBytes in One Second Flat 4Gb Fibre Channel – Delivering Performance to Network and Storage Applications You design-in Fibre Channel for performance and now you can have it — • Extensive driver and software library support • AMC, XMC & PMC form factors • Comprehensive storage and networking protocol support • 1.5GBytes/second sustained transfer rate • 4/2/1Gbps dual channel Critical I/O offers an unparalleled level of engineering expertise and integration support to guide your team down the winding Fibre Channel road toward maximum performance with minimum risk.

AMC

XMC

Make sure your systems are ready for the long haul. Contact Critical I/O about 4Gb Fibre Channel for embedded systems — today. PMC

visit our website at www.criticalio.com

SolutionsEngineering Industrial Ethernet

Ethernet Powerlink: A Deterministic Alternative for Distributed Control Ethernet Powerlink offers real-time deterministic network control that can be integrated with non real-time environments and requires relatively little modification of existing interfaces. by F rank Foerster and Bill Seitz IXXAT

y virtue of their adoption in microcontrollers and the number of installed nodes, two worldwide communications standards have emerged over the past fifteen years. As an embedded communications standard, Controller Area Network (CAN or CANbus), originally developed for distributive control in automobiles, is a commonly available, virtually free on-chip serial interface offered by over twenty-five semiconductor manufacturers. CAN is further supported by CANopen and DeviceNet as the most popular application protocols in transportation, medical, building and industrial automation. Ethernet is the world standard for IT and is rapidly appearing in more industrial automation applications. Many automation users and machine OEMs are demanding faster, more precise distributed control systems that synchronize the ever-increasing number of sensors and actuators on a single network. There is compelling justification for why Industrial Ethernet is attractive for automation applications. For one thing, Ethernetâ&#x20AC;&#x2122;s 100 Mbit/s data rate offers 1 to 2 orders of magnitude more bandwidth than most current field-buses, and with the emergence of Gigabit Ethernet, even greater bandwidth is possible. In addition, Internet protocols provide integration and data transparency 20

April 2007

on all networking levels, and Ethernet is a proven cost-effective worldwide standard. This has led to a wide selection of lowcost silicon devices with on-chip Ethernet available from multiple vendors. Ethernet Powerlink (EPL) responds

to the users and machine OEMâ&#x20AC;&#x2122;s demands by featuring microsecond-fast time-deterministic cycle times that separate each cycle into cyclic (isochronous) and noncyclic (asynchronous) segments. While this mechanism responds to the microsec-

Managing Node MN

Non-Real-Time Domain

Controlled Node CN Router/Bridge

Router/Bridge

PLC

Drive

I/O

PLC

Drive

EPL Segment Real-Time Domains

Figure 1

Ethernet Powerlink can be implemented as separate real-time domains, each of which has a managing node overseeing a number of controlled nodes that send and receive real-time data within that domain. Connection to non-real-time domains such as Ethernet or the Internet takes place via router/bridge gateways.

SolutionsEngineering

ond performance demanded by users and OEMs, it also addresses issues of domain separation by isolating data from external non-real-time domains that are transferring asynchronous data from isochronous data at the machine level. This single feature alone eliminates “out of sync” data from encroaching into the time-deterministic domain. EPL operates on standard Ethernet and features connectivity to common nonreal-time legacy IP network topologies via gateways (Figure 1). An EPL system can be implemented as a set of controlled nodes (CN) and a managing node (MN), where the MN is requesting all CNs to send their data within a defined cycle and in a defined order as shown in Figure 2.

Ethernet Powerlink (EPL)

Ethernet Powerlink (EPL) is the first available real-time Ethernet protocol adopting the well-proven CANopen object dictionary concept and its communication mechanisms that provide features like interoperability, flexibility and configurability, which are essential to fast and accurate real-time communication. Today, CANopen is used worldwide in thousands of applications and devices. This experience now directly benefits the further development of the EPL communication stack. Working through the Ethernet Powerlink Standardization Group (EPSG), Ixxat has participated in the creation of the EPL specification with the focus on extensive integration of the mechanisms developed for CANopen on EPL. The lower layers of the EPL software are specifically designed to follow the EPL cycle schedule and to guarantee fast response times for real-time events on the EPL bus (Figure 3). For the transfer of acyclic data like configuration data or parameters, EPL foresees the so-called Service Data Objects (SDOs), which are typically transferred via UDP. The EPL stack can be combined with a regular TCP/IP stack providing the UDP capability (which is typically provided by the operating system). Access to and handling of the Ethernet controller is encapsulated within a separate module, the lower layer driver

Managing Node (MN) Start Period SoC

Asynchronous Period

Isochronous Period PReq to CN 1

PRes from MN

PReq to CN 2 PRes from CN 1

PRes from CN 2

Idle Period

SoA ASnd

Timeslot for CN 1 Controlled Node (CN)

Figure 2

An EPL packet has separate periods reserved for isochronous and asynchronous data communication.

(LLD). To implement EPL on a specific CPU or hardware platform, the LLD is the only EPL module that must be modified. This abstraction between hardware-dependent routines and the higher layers of the EPL software ensures a high degree of scalability and adaptability. EPL provides two basic mechanisms for data communication. Cyclic, realtime critical data like I/O or closed-loop control data are transferred via Process Data Objects (PDOs) in the first part of the EPL cycle, while non-real-time critical data like configuration parameters are transferred in the asynchronous period of an EPL cycle. In general, every controlled node participating in real-time processes is granted bus access in every cycle by the managing node to send its PDOs with cyclic data. SDO data are transferred in the asynchronous period of an EPL cycle.

Object Dictionary and Programming Interface

The object dictionary, as conceived in the CANopen specification, is the interface between application and communication. Each object dictionary entry directly allocates a reference to a variable containing application data. Communication services, such as PDOs and SDOs, access these application variables directly. Therefore, only minor modifications to an existing CANopen application are necessary to integrate an EPL protocol stack. In the event of access requests to these

objects, user-specific call-back functions are linked to every application object that enables an event-controlled notification of the application. This mechanism allows a direct, application-specific reaction on modifications to the application data caused on the bus side. The EPL stack can be used with or without an operating system. The software has an internal scheduler that ensures the optimal allocation of the available process time resources to the various stack functions. By using an operating system, the EPL stack is executed as one task. Only basic operating system functions like semaphores and tasks are required. These functions are encapsulated by the abstraction layer and are easily adapted to the operating system. EPL protocol stacks are offered in a generic version for direct porting to various target platforms and operating systems as well as a complete solution including a stack version dedicated to hardware reference designs. Provided as hardware-independent C-code, the software can be used on various target systems based on different μC platforms. Access to and handling of the Ethernet controller is encapsulated by a separate lower layer driver module with a standardized interface. This provides users with the ability to implement the EPL stack for specific Ethernet controllers and hardware designs. The delivery includes the code to run the EPL stack directly on a reference platform, which facilitates a quick start from April 2007

SolutionsEngineering

Application Object Dictionary (OBD) SDO GOE

SIS

NVM

Error Handling

NMT

PDO

TCP

UDP IP

Powerlink Driver (PLD) Lower Layer (LLD)

EPL Stack

Ethernet Controller

Figure 3

The EPL stack is designed such that the lower level driver (LLD) layer is the only module that must be modified to adapt EPL to a given CPU or hardware environment.

CPU/MCU

I/O Application

FLASH

Host API

RAM

Host I/F

Cyclone II with NIOS Core

Host API EPL Stack

TCP/IP

EPL HW Abstraction

FLASH

EPL Package Handler

RAM

Ethernet Controller HUB

EPL CN

EPL

Figure 4

An EPL stack with its own soft core processor communicates with the CPU but processes the EPL protocols on an FPGA.

scratch. The EPL stack has been developed in close cooperation with leading vendors of Ethernet Powerlink-enabled devices like B&R Automation, Lenze and Hirschmann.

EPL Performance

The performance criteria associated with time-deterministic Ethernet are jitter, 22

April 2007

minimum cycle time and the response time of the individual nodes. Jitter is a term used to describe the timing deviation of cyclic events. For example, if an event should occur every 500 μs, and it actually occurs after 498 μs in the best case and 504 μs in the worst case, the difference is referred to as jitter. In this example, the jitter is 6 μs. Net-

work jitter refers to the jitter caused by the network and its components, including all connected devices. EPL has a maximum network jitter of less than 1 μs. Therefore, the timing fluctuation between any of the connected devices is always less than 1 μs. The jitter precision of EPL is solely determined by the managing node (MN), which is responsible for correctly sending a Start of Cycle (SoC) message. Most applications target a cycle time of 1 ms. In some applications, 500 μs or 250 μs are required, but these generally have a reduced number of nodes. The EPL cycle time is determined by the total of all communications on the bus, which is easy to determine by totaling all request/ response packets. Since every individual node has to perform specific tasks like SoC processing, PDO mapping, asynchronous SDO traffic and other application tasks, there are also node-internal processes like network management and the EPL cycle state machine that must be considered. When considering EPL, it is important to calculate cycle times that take into account all the message events on the EPL bus. Another important performance criterion is the response time, which is, in the case of a controlled node (CN), the time gap between the reception of an incoming request and the transmission of the response. The response time of an MN is the time gap between the reception of an incoming response from CN “A” and the transmission of the request to CN “B.” The lower the response times of a node, the higher is the bandwidth usage of the bus. Since they have to do the low-level package handling (reception/transmission) in software, typical microcontrollers are able to achieve response times in the range of 3-10 μs. Low response times on microcontrollers can typically be achieved with highly optimized assembler routines, which makes such routines very specific. The drawback of this approach is that changing the hardware microcontroller platform is problematic due to the uncertainty of performance levels that can be achieved on alternative systems. An alternative to the microcontroller approach is to encapsulate the whole EPL protocol handling in an exclusive resource that provides deterministic processing of the communication data as well as fast

SolutionsEngineering reactions on bus events. For combining hardware state machines with a state-of the art RISC architecture, the FPGA is the first choice as a generic communication platform. The EPL hub and Ethernet controller are implemented in hardware the same as a hardware state machine for package handling (both in VHDL), which makes the response time much faster and more deterministic. The hardware state machine is completely independent of factors like interrupt latencies or DMA speed. Providing such IP in VHDL language reduces the dependencies on specific processor platforms. The FPGA approach guarantees response times of less than 1 μs and makes packet processing independent of application processing, which is typically performed on another dedicated microcontroller.

FPGA as Communication Coprocessor (CN)

The implementation of the EPL functionality on a FPGA, like an Altera Cyclone II, is very powerful and extremely flexible. The FPGA contains an Ethernet hub and an Ethernet controller/EPL packet handler. In addition, an Altera NIOS II processor core is also included in the FPGA. This processor core provides the flexibility to execute a scalable amount of software. For slower CNs (i.e., slower I/O), the whole EPL stack plus application software can be implemented without a Host CPU. For faster CNs, only the EPL stack has to be implemented. In one case, the EPL stack is executed on the FPGA NIOS II while the Host API is provided to access the FPGA from the host processor. The most important advantage of this approach is that the host processor is isolated from EPL critical real-time processes. Figure 4 illustrates the host CPU with additional Altera Cyclone II FPGA containing the NIOS II core. The application code is executed on the Host CPU and the EPL Stack is executed on the FPGA NIOS II. The FPGA contains the Ethernet Controller and hub, which guarantees ultra low response times of less than 1 μs. Although the EPL protocol software can be implemented on virtually any platform making use of any standard Ethernet Controller, the performance impact

of industrial real-time Ethernet Protocols like EPL on the application CPU has to be evaluated carefully. Today, it is widely accepted to introduce an exclusive communication resource in addition to the application microcontroller into automation devices in order to provide a dedicated communication performance independent from the application. The FPGA seems to be the component of choice for this integration strategy. The combination of programmable hardware and a high-performance RISC

architecture provides optimal flexibility for protocol stack execution as well as unparalleled performance in hardware state machine-based packet data processing. This feature combination is also beneficial for other industrial Ethernet protocols like EtherNet/IP, Profinet and Modbus TCP. IXXAT Bedford, NH. (603) 471-0800. [www.ixxat.com].

Essential building blocks … Innovative solutions. From Digital Signal Processing, to I/O interfaces, to IP cores and Software tools … ... at BittWare you’ll find the essential building blocks you need for your signal processing applications. Whether your application needs to thrive under extreme conditions of the battlefield, meet the ever-changing requirements of the communications market, or process highly-precise medical imaging data, BittWare has the capabilities to meet your needs. Reliable cutting-edge products are backed by timely delivery, reduced cost, and a dedicated support team – enabling your innovative solutions.

w w w. B i t t Wa re . c o m

Untitled-3 1

April4/4/07 20074:46:34 PM23

SolutionsEngineering Industrial Ethernet

EtherCAT: Implementing Deterministic Control over Ethernet Hardware Looking at today’s landscape of available industrial connectivity and especially industrial Ethernet solutions, it is hard to compare them in every detail. However, a recent industrial Ethernet standard called EtherCAT, offers attractions in terms of performance, flexibility and affordability. by T orsten Sehlinger, Sysgo and Gerhard Spiegel, Koenig Prozessautomatisierung

tandard Ethernet cannot guarantee predefined reaction times due to sporadic collisions caused by nonsynchronized masters attempting to access the common wire. These collisions can be avoided by having only one master. Communication between the master and the slaves can be based on polling (request/ response) or on fixed time slices. Each real-time Ethernet implementation approach that implements direct communication between master and slave using request/response methodology suffers from much higher payload and poor efficiency. Ethernet for Control Automation Technology (EtherCAT) is an Ethernetbased Fieldbus standard that overcomes these performance issues. The idea is to have a single master running on a standard real-time operating system utilizing only IEEE 802.3 components. The EtherCAT slave device incorporates dedicated EtherCAT hardware, which is available as a dedicated chip or IP core. The wiring is standard industrial Ethernet in terms of mechanical and electromagnetic stability. EtherCAT can be used in star or tree topology using Ethernet switches, but also as a simple line structure (bus), saving the costs for expensive industrial switches. 24

April 2007

Jump on the Train

Similar to a train passing through a railway station, with a short delay for loading and unloading, an EtherCAT packet sent by the master passes a slave device, while the slave device reads the data addressed to it and writes its output concurrently. Therefore, the frame is only delayed for some nanoseconds before being on the wire again. So instead of reading the complete Ethernet frame and interpreting it, the slave only extracts the necessary information, thus only necessary bits are copied and written. The EtherCAT frames are located in the payload area of the Ethernet packet. Since an EtherCAT frame has its own Ethertype (88A4h), the complete frame transfer can be done using standard hardware components (Figure 1). Very accurate time synchronization is needed in distributed environments. Therefore, EtherCAT time synchronization is based on pure hardware mechanisms implemented in each slave device. One of these slave devices becomes the timing master. Each slave device can measure the time-distance between a frame’s leaving the chip until its entry on the way back. So all communication jitters are known. All this timing information leads to a common time base in all devices with an accuracy of roughly 100 ns.

Performance

The delay inside the EtherCAT slave is about 600 ns per direction. 500 ns comes from the transformer and is Ethernet standard. Assume, for example, that we have eight EtherCAT nodes. A thousand I/Os are 125 bytes of data, plus an offset of 12 bytes per node, which makes additional 96 bytes plus another 32 bytes as frame offset. All together we end up at 253 bytes. Transferring one byte in a 100 Mbit/s network takes 80 ns. So 253 bytes will need 20.2 µs. The eight nodes add an additional propagation delay of 8* (600 ns *2) = 9.6 µs. So updating a thousand I/Os will only take 29.8 µs. This is just a third of what Profinet IRT would take or 300% faster than Profinet RT. Since several EtherCAT frames from different devices can reside in a single Ethernet packet, the utilization of a single Ethernet packet can be much higher compared to each device using its own Ethernet packet to transmit information (Figure 2). The maximum transmission unit (MTU) of an Ethernet frame is 1538 bytes (including CRC and inter-frame gap). And 1498 of them can be used as payload. For each EtherCAT device, a 12 byte offset is to be applied. Assuming 10 devices are sharing one frame, the data rate can be calculated

SolutionsEngineering

to (1498-120 / 1538) * 100 = 90%. EtherCAT not only supports a star topology, but also a line topology with up to 65,535 nodes for each segment, drop lines and flexible tree structures. Other industrial Ethernet implementations claim to support line topology but request that the number of nodes be limited to 20 nodes that can be connected without having too many delays due to cascaded switches in between. EtherCAT requires no hubs or switches at all. The user can also have redundancy in wiring (ring). The master has two network adapters shown as green in Figure 3. Many companies and industries are endorsing EtherCAT simply because of topology advantages. EtherCAT offers several ways of addressing a device. During start-up, the EtherCAT master assigns incremental addresses to the network components. The configuration actually found is compared with the specified configuration, so that cabling errors or invalid device selections are detected quickly and reliably. Manual adjustment of the node addresses using rotary or DIP switches and all the pain with double assignment can thus be avoided. On the other hand, service people need to exactly identify one out of many devices of the same kind. So the user can assign a name or “alias” to each device after the start-up. Using this alias a user can change positions of devices without adapting the I/O addresses in the application on the master side. Even the removal and addition of preconfigured devices is possible while the network is running. This is called “hot-plug.” The EtherCAT master accepts missing or added hot-pluggable devices without any user inquiry.

compares the actual working counter with the expected value being calculated by the EtherCAT configuration tool. In case of a non-match, the master sends individual

frames to each slave to verify its state, updates its topology (Figure 4) and notifies the master application. In case of a communication fault, a counter is incremented

EtherCAT Configuration Tool Host OS

Standard Ethernet Chip & Phy UDP EtherCAT Master Stack

RTOS

Standard Ethernet Chip & Phy EtherCAT

Figure 1

Slave Application 1

Slave Application 2

Slave Application 3

Standard Ethernet Phy

EtherCAT Chip IP Core

EtherCAT Topology and Components.

Easy Diagnostics

A frame sent by an EtherCAT master propagates through all slaves and is redirected by the last reachable slave back to the master. The operating principle of EtherCAT is a logical ring. When receiving the return frame, the master checks the correctness of all data using CRC. For checking whether all slaves are alive, a working counter is used. This is incremented by each slave after reading or writing data to the frame passing by. Having received the return frame, the master

Ethernet HDR

Figure 2

Data

CRC

Several EtherCAT frames included in one Ethernet packet. April 2007

SolutionsEngineering for each slave, which helps to identify unstable connections. EtherCAT is the only real-time industrial Ethernet technology that does not need a special plug-in card for the master, nor a coprocessor or a lot of processing power at all. What is needed is an Ethernet MAC. This means the lowest possible hardware costs on the master side. The lack of a PCI board as a plug-in also avoids an additional asynchronous

Figure 3

cycle and speeds up reaction time by a factor of two. On the installation side there is no need for switches or hubs. A line bus topology of—in comparison to star topology—reduces cable length and costs. Thus EtherCAT is cheap in installation. Standard switches also have a non-predictable delay, and high-end switches are really expensive. The slave controller chips are in the same range as standard Ethernet chips (roughly $5

Two drives and four I/O systems, with two connected as stubs to the “physical ring.”

April 2007

in quantity 10,000). The synchronization mechanism for EtherCAT is already built in. Other solutions that rely on IEEE 1588 require an extra chip. All together this makes EtherCAT a very affordable technology.

Combining EtherCAT Master, Operator Interface and MES

As previously mentioned, the EtherCAT master must be hosted on a real-time operating system. Traditionally this would be VxWorks, QNX or something similar. Today, more and more companies tend to look at embedded Linux as an option to replace such traditional RTOSs and for combining real-time applications with operator interfaces and manufacturing execution systems (MES) interconnections based on open standards instead of proprietary APIs. Still, even today’s built-in real-time modifications of the Linux Kernel only enable soft real-time, not a proven deterministic behavior. But somehow the idea of utilizing the available features and technologies from Embedded Linux while concurrently running EtherCAT with hard real-time performance is explicitly attrac-

SolutionsEngineering

The Harsher the Environment, the More You Need MEN Micro! Intel® Pentium®M up to Core™(2) Duo CompactPCI®/Express

Figure 4

Redundant design allows master to reach slave drives even with missing link.

MES Client

Operator Interface

Linux

EtherCAT Master

For the harshest industrial and mobile applications, MEN Micro offers more solutions, including:

PikeOS Separation Microkernel Hardware MES Network EtherCAT

■

Core™ 2 Duo T7400, 2.16 GHz

■

Core™ Duo T2500, 2 GHz

■

Figure 5

Real-time separation kernel hosts both Ethercat implementation and Linux-based client application.

tive and would appear to be cost-effective. Sysgo, in cooperation with Koenig Automation, delivers such a solution. Sysgo’s PikeOS offers a unique combination of a hard real-time operating system and a virtualization environment, enabling a Koenig Automation EtherCAT master running concurrently with Embedded Linux in strictly separated environments (partitions) on top of PikeOS (Figure 5). Customers can use Embedded Linux to hook up the system to the MES as well as to implement an operator interface while concurrently running the EtherCAT master in another partition—all on one PC.

■

Pentium® M 760/Celeron M 373, 1.2 GHz Side cards - UART, multimedia, USB and more! Compatible 3U Intel® family with scalable computing performance Long-term availability- up to 15 years

All this could still guarantee execution of the EtherCAT master, even if Linux is disabled for any reason. Sysgo Klein-Winterheim, Germany. +49 6136 99480. [www.ssgo.com]. Koenig Prozessautomatisierung Lauf a. d. Pegnitz, Germany. +49 9218 725 652. [www.koenig-pa.de].

RoHS MEN Micro, Inc. COMPLIANT 24 North Main Street 2002/95/EC Ambler, PA 19002 Tel: 215.542.9575 E-mail: sales@menmicro.com

www.menmicro.com

April 2007

SolutionsEngineering Industrial Ethernet

RapidIO and Ethernet for Backplane Applications: A Practical Technical Comparison For embedded backplane applications, higher speed 1 and 10 Gigabit Ethernet may not be the most efficient approach. RapidIO deserves a close look in terms of latency, jitter, quality of service and efficiency. by G reg Shippen Freescale Semiconductor and RapidIO Trade Association

thernet is currently the incumbent backplane technology across a wide range of storage, wireless, wireline, military, industrial and other embedded applications. It has been the de facto choice as developers continue to move away from proprietary implementations in an effort to reduce development time while increasing performance and functionality, all at a reduced cost. However, as data rates continue to increase, it has become apparent that many high-performance applications exceed the limits of this traditional protocol. Designing an efficient embedded backplane interconnect with excellent performance requires addressing a number of key design challenges, including header efficiency, protocol processing efficiency, effective bandwidth and quality of service while strictly managing cost. To meet these challenges, many developers are turning to RapidIO as an alternative to Ethernet. Many of the differences between Ethernet and RapidIO stem from their initial design constraints. Ethernet was designed to connect a large number of endpoints with a flexible and extensible architecture, leading to the choice of a simple header and support for a single transaction type. 28

April 2007

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 4

Preamble Preamble

SFD

Destination MAC Address (con’t)

Source MAC Address

16 20

Source MAC Address (con’t)

Packet PDU

Type/Length Packet PDU

1522

FCS

1526 1538

Inter-Frame Gap 1500 Byte Max Packet PDU 1538 Bytes Total (Frame + Overhead) Logical Layer

8 12

Destination MAC Address

Transport Layer

Bytes

Physical Layer

Preamble/SFD

L2 Header

IP Header

8 Bytes

14 Bytes

20 Bytes

TCP Header

User PDU

20 Bytes

1460 Bytes

FCS

IFG

4 Bytes

12 Bytes

1460 Byte Max User PDU 1538 Bytes Total (Frame + Overhead)

Figure 1

Many embedded Ethernet applications use TCP/IP to handle packet loss because of off-the-shelf software support. While higher-layer protocols simplify application development, they also add substantial overhead— 40 bytes in the case of TCP/IP—reducing overall bandwidth efficiency.

...but your decision for real-time and embedded development just got easier.

C++ INTRODUCING PERC PICO THE FIRST RESOURCE-CONSTRAINED / HARD REAL-TIME SOLUTION FOR JAVA™ DEVELOPERS � Speed, footprint comparable to C / C++ � Low microsecond response times � Access to low level devices � Predictable memory management � Support for all major RTOS environments � PowerPC, x86, XScale, ARM, and more

ENTER TO WIN 42” PLASMA TV www.aonix.com 1-800-97-AONIX 1-800-87-AONIX

www.aonixnews.com/plasma.htm Enter Promo Code: RTC

SolutionsEngineering

Ethernet was originally intended to connect computer workstations. Therefore hardware is only required to identify packet boundaries, necessitating a relatively large software stack to manage protocol processing. While this serves well in LAN and WAN applications because of the presence of powerful processors, the hardware/software trade-off imposes a formidable performance bottleneck in high-speed embedded applications. RapidIO was originally conceived as a next-generation front-side bus for high-speed embedded processors. The value of a front-side bus that could also function as a system-level interconnect was recognized early in the specification’s development. As a consequence,

and protocol encapsulation, to name a few of its capabilities.

Header and Protocol Efficiency

Ethernet’s extreme flexibility is one of the main sources of its inefficiency. The use of a simple, generalized header enables Ethernet to add higher-level services as new protocol layers, but even basic services require additional header fields. Ethernet’s firm requirement for backward compatibility also introduces inefficiencies such as maintaining preamble and IFG fields required for the original half-duplex shared coax PHY. However, more recently defined PHYs have less need for these. Since there is no opportunity to optimize the overall

Ethernet

OSI Layer

RapidIO

Application Layer 5+ Layer 4: Transport Layer 3: Network

RDMA

Custom

TCP

UDP IP

Transport Layer

Layer 2: Data Link

Ethernet

Layer 1: Physical

10/100/100 Base-T Software

Figure 2

Custom

Reliable Delivery LP-LVDS LP-Serial Hardware

While Ethernet is a fairly flexible standard supporting many optional layer 3+ protocols, lack of a single, uniform implementation results in a diversity of actual implementations and, as a consequence, increased Ethernet stack complexity. Unique partitioning of processing between hardware and software ends up tying developers to vendor-specific implementations.

RapidIO was designed with a focus on embedded in-the-box and chassis control plane applications, emphasizing reliability with minimal latency, limited software impact, protocol extensibility and simplified switches while achieving effective data rates from 667 Mbits/ s to 30 Gbits/s. Protocol processing takes place in hardware and supports read/write operations, messaging, data streaming, QoS, data plane extensions 30

Read, Write, Messaging, Datagram, Encapsulation

April 2007

header, the presence of multiple headers increases parsing complexity and latency. While the processing of Ethernet headers can be optimized as custom protocol stacks on top of Ethernet layer 2, the cost of supporting custom stacks across multiple vendors or even multiple generations of the same vendor hardware can become prohibitive. As a consequence, many systems take a performance hit to utilize UDP or TCP/IP rather than com-

municate directly through the more efficient lower layers. RapidIO was designed with optimization of the header in mind. Embedded backplanes need to support significantly fewer endpoints than LANs, so a smaller address field can be utilized. This amounts to only one or two bytes compared to Ethernet’s MAC address of six bytes plus four bytes when IP is used. The specification provides header support for common services such as read and write transaction types that require additional header layers in Ethernet. Redundant fields are removed; duplicate addressing schemes are avoided and fields are compressed where possible. Ethernet offers only best-effort service unless higher-layer protocols are employed to handle packet loss. Many embedded Ethernet applications use IP with UDP or TCP to handle packet loss because software support is widely available and understood. TCP/IP, while simplifying application development, adds significantly to the overall Ethernet header, introducing 40 bytes of overhead (Figure 1). UDP can be used when this overhead is too high but then reliable delivery, if required, must be implemented in a proprietary fashion. Overall, Ethernet is a fairly flexible standard supporting many optional layer 3+ protocols developed by different standards organizations for a broad range of applications. However, because no single, unified specification is uniformly implemented, these have resulted in a diversity of actual implementations and, as a consequence, increased Ethernet stack complexity. Even as necessary a technology as the TCP/IP offload engine (TOE) is plagued with many proprietary implementations, each with its own unique partitioning of processing between hardware and software and a vendor-specific Ethernet stack that ties down developers (Figure 2). There isn’t even a standard SERDES PHY for 1 or 10 Gigabit Ethernet backplanes. The RapidIO specification offers a single, uniform protocol with consistent layering managed by a single standards organization. RapidIO also guarantees delivery by providing end-to-end error checking, retrying link errors, not allowing switches to drop packets, and supporting virtual channels. Since RapidIO directly implements the protocol in hardware, headers can be processed in a straightforward and less processor-

SolutionsEngineering

Effective Bandwidth

Ethernet supports a payload size from 64 to 1500 bytes (up to over 9000 with jumbo packets) and its efficiency is best with a maximum payload, although this comes at the cost of increased latency jitter. RapidIO transports 1 to 256 bytes, balancing large payload jitter against small payload inefficiency. As Figure 3 shows, RapidIO achieves better efficiency across the payload sizes most common to embedded backplane applications. For control plane applications that cannot tolerate packet loss, an Ethernet fabric must be significantly over-provisioned to tolerate packet loss and limit associated latency and jitter. Given 25-35% usage for many applications, this translates to a sustainable effective throughput for layer 2 traffic of approximately 250 Mbits/s for 1 Gigabit Ethernet and 2.5 Gbits/s for 10 Gigabit Ethernet, depending on average packet size. Note that performance is defined, not by PHY symbol rate, but rather the effective rate in which a protocol reliably transports data (Figure 4). Additionally, even with over-provisioning, end-to-end latency can still run in milliseconds since traffic must traverse multiple software stacks. By implementing protocol processing in hardware, RapidIO greatly reduces effective latency in comparison to Ethernet and can deliver much higher fabric usage in complex topologiesâ&#x20AC;&#x201D;well in excess of 50%. For control plane applications, link-level error correction minimizes latency jitter caused by soft errors, potentially reducing end-to-end latency below 500 ns. Throughput is also affected by overhead for operations such as reading, writing and messaging. Ethernet RDMA provides read and write operations, but as a layer 4 protocol, its high overhead is not well suited for small control-oriented load/store operations. TCP/IP services resemble RapidIO

100% 90% 80% 70%

Efficiency

intensive manner than equivalent Ethernet implementations, which utilize partial hardware offload and custom stacks. The result is lower implementation cost, reduced overall design complexity, and more stable interoperability between vendors.

60% 50% 40%

RapidIO: NWRITE Ethernet: L2 Ethernet: UDP

30% 20% 10% 0 1

100

1000

10000

PDU Size (Bytes)

Actual Values for Points on Graph RapidIO: NWRITE

Ethernet: UDP

4, 8, 17, 33, 50, 67, 80, 86, 93, 93, 93, 93, 93

1, 2, 5, 10, 19, 33, 49, 66, 80, 89, 94, 96, 97, 99, 99

Ethernet: L2 1, 2, 5, 10, 19, 38, 63, 77, 87, 93, 96, 98, 97, 99, 100

Figure 3

Ethernet achieves its best efficiency with a maximum payload, although this comes at the cost of increased latency jitter. By balancing large payload jitter against small payload inefficiency, RapidIO achieves better overall efficiency across the payload sizes most common to embedded backplane applications.

Network with the SBC6713e, our highest-performance stand-alone DSP board with on-board 10/100 Ethernet Features

Applications

300MHz, 32-bit, f oating-point TMS320C6713 DSP Powerful C/C++ libraries, Windows debugger

10/100 Ethernet via DM642 coprocessor for realtime network I/O Two OMNIBUS I/O expansion sites

Embedded Servo Control Remote Data Acquisition Industrial Test & Measurement OEM Instrumentation

Wide selection of analog input/output Up to 24-bit resolution, up to 64 MHz sample rate

Capable of 100% stand-alone operation 3U Size 100mm x 160mm 4 Mb Flash ROM

Fantastic, on-board peripherals RS232, 32-bit digital I/O, watchdog 600K gate Spartan-IIE for user-logic (optional)

Download

ts Data Shee NOW!

805.578.4260 phone www.innovative-dsp.com April 2007

SolutionsEngineering

Bandwidth (Gbps)

10 8

SRIO 4x 3.125G: NWRITE SRIO 4x 2.5G: NWRITE SRIO 4x 1.125G: NWRITE 10G Ethernet: UDP 1G Ethernet: UDP

6 4 2 0 1

100

1000

10000

PDU Size (Bytes)

Actual Values for Graph: SRIO 4x 3.125G: NWRITE 0.4, 0.8, 1.7, 3.3, 5.0, 6.7, 8.0, 8.6, 9.3, 9.3, 9.3, 9.3, 9.3 SRIO 4x 2.5G: NWRITE 0.3, 0.7, 1.3, 2.7, 4.0, 5.3, 6.4, 6.9, 7.4, 7.4, 7.4, 7.4, 7.4 SRIO 4x 1.125G: NWRITE 0.2, 0.3, 0.5, 1.3, 2.0, 2.7, 3.2, 3.5, 3.7, 3.7, 3.7, 3.7, 3.7 10G Ethernet: UDP 0.1, 0.2, 1.0, 1.9, 3.3, 4.9, 6.6, 8.0, 8.9, 9.4, 9.6, 9.7, 9.8, 9.9 1G Ethernet: UDP 0.0, 0.02, 0.05, 0.19, 0.33, 0.49, 0.66, 0.80, 0.89, 0.94, 0.96, 0.97, 0.98, 0.99

Figure 4

For control plane applications that cannot tolerate packet loss, an Ethernet fabric must be significantly over-provisioned to tolerate packet loss and limit associated latency and jitter, which significantly impacts its effective bandwidth compared to RapidIO.

messaging but where RapidIO messaging supports convenient 4 Kbyte messages and is often fully implemented in hardware, TCP/IP supports 64 Kbyte messages that are much more dependent on software for processing. Additionally, RapidIO defines a protocol for keeping caches coherent across the interconnect. Ethernetâ&#x20AC;&#x2122;s too low header efficiency, high latency and inconsistent levels of hardware support make such a feat ineffective to implement. Extensive packet handling by Ethernet switches also increases the overall complexity and processing load. When IP packets are routed, numerous fields must be updated and the FCS recalculated. RapidIO switches typically only update the AckID field, which is not covered by the CRC and so does not force a recalculation. 32

April 2007

Quality of Service

Quality of Service (QoS) is essential for many backplane applications. While Ethernet through TCP/IP can support millions of individual streams and differentiate traffic by port number and protocol fields, no commonly used class of service (CoS) field exists. RapidIO defines up to six flows that can be considered prioritized classes of service. Through the use of Type 9 encapsulation and virtual channels, it is able to differentiate millions of streams as well. QoS is also affected by Ethernetâ&#x20AC;&#x2122;s best-effort service, which commonly manages congestion by dropping packets, which leads to latency jitter. Since flow control belongs to upper-layer protocols such as TCP, congestion cannot be proactively managed to prevent packet loss. By the time TCP flow controls are invoked,

latency jitter has already occurred. This lack of short-term, link-level flow control requires larger endpoint receive buffers to avoid overruns. Further exacerbating latency is the fact that error detection and recovery occurs at the system rather than link level. Thus, timeouts exist only at layer 3 and above and are managed by offload hardware in the best case or by software in the worst case, resulting in much longer timeouts and significantly increased latency jitter. Additionally, no standards exist for hardware-based recovery such as retries or timeouts, so Ethernet drops packets for a significant period of time before failure is detected. While there are protocols such as bidirectional forwarding detection that use exchange packets to detect failures, these continuously impose bandwidth overhead dependent on the responsiveness required. According to the specification, all RapidIO networks must provide a minimum level of prioritized service to implement logical layer ordering and avoid deadlock. This also improves average latency since packets marked with a higher relative priority must make forward progress because they might be responses. Optionally, switches can reorder packets from different flows and offer head-of-line blocking avoidance as well as other QoS features. With the exception of link-level retry, all flow control mechanisms are proactive and allow congestion to be managed before there is a significant impact on network performance. RapidIO also defines a link-layer protocol for error recovery and various hardwarebased link-to-link and end-to-end timeout mechanisms, enabling virtually all errors to recover at the link level without software intervention. Also, because RapidIO links carry valid traffic at all times, a broken link is promptly detected locally at the link level. As a result, failure rates, defined as undetected packet or control symbol errors, are significantly less than the hard failure rate of the devices on either end of the link, depending upon operating conditions.

Cost

From a silicon standpoint, it might seem that the often-touted high-volume cost economies of Ethernet would provide it a significant advantage over RapidIO. While this is likely true for 4-8 port

SolutionsEngineering

Gigabit Ethernet switches used in LANs, Ethernet switches for use in embedded applications require more specialized functionality such as VLAN QoS and SERDES PHYs, significantly reducing the number of accommodating vendors, overall shipping volume and, therefore, cost economies. Additionally, RapidIO in general assumes a maximum backplane or board-level channel of 100 cm using copper traces on FR4-like materials. Ethernet PHYs for twisted-copper pair must support channels 100 times longer than RapidIOâ&#x20AC;&#x2122;s and, since Ethernet cabling assumes bundling with many other similar pairs, it must tolerate significantly more crosstalk. Together, these result in significantly higher PHY complexity than is actually required for backplane applications. Computing true PHY cost must also be done carefully. For example, one commercially available RapidIO endpoint supporting messaging was only 25% larger than a Gigabit Ethernet controller lacking full TOE capabilities on the same processor. Likewise, a four-lane RapidIO SERDES is about 50% larger than a single XAUI lane. This suggests that the silicon complexity required for endpoints is comparable. For its part, RapidIO offers 2.5 times more effective bandwidth per link than Gigabit Ethernet. Additionally, the cost per port of a 16-port RapidIO switch is half that of a similar Gigabit Ethernet switch. For applications requiring more than 1 Gbit/s, the only alternative for Ethernet is 10 Gbit/s. Today, RapidIO offers higher effective bandwidth for payloads less than 1024 bytes at lower cost, even without taking into consideration the cost imposed on Ethernet endpoints to process protocol stacks at 10 Gbits/s. Such processing also has a significant impact on power consumption because using a GHzclass processor to terminate each Gigabit Ethernet link increases power by watts. Virtually any application layer service can be supported by either Ethernet or RapidIO. The difference between the two technologies, however, lies in their individual inefficiencies and the level of hardware processing supported. Ethernet has a long history in the LAN, which because of backward compatibility, header and protocol inefficiencies, soft-

ware dependence, complex and proprietary offloading mechanisms, and lack of implementation standards, makes it less than an ideal choice for backplane applications. RapidIO was specifically designed to provide optimized performance for embedded applications. By eliminating unnecessary overhead and implementing protocol processing in hardware, it provides a stable specification resulting in standardized implemen-

tations. RapidIO focuses on maximizing effective throughput, supporting sufficient quality of service mechanisms, and providing cost-effective silicon supported by an extensive ecosystem, and thus provides the interconnect technology that will carry embedded developers well into the future. RapidIO Trade Association [www.rapidio.org].

design.

develop. d

deploy.

Are You Board With Me?

design. The next generation of connected devices.

Start with an AMCC PowerPC 405 Processor. Specify your I/O requirements.

develop. Your products based on our platform.

deploy. Your solution faster.

EP885 Stack Advert V4.indd 1

Choose your operating system. Relax while Embedded Planet delivers your rugged and reliable system. 4760 Richmond Rd / Cleveland, OH 44128 Tel: 216.245.4180 / Fax: 216.292.0561 www.embeddedplanet.com

1/11/2006 1:24:11 PM

April 2007

IndustryInsight Thermal Management on ATCA

Thermal Interoperability Challenges ATCA Systems Achieving thermal interoperability among ATCA blades and shelves/chassis requires correlating between different vendor methods of measurement, as well as careful, in-depth analysis and comparison of board and shelf thermal characteristics. by D ave Baker and Dan Carter Intel

hat could accelerate market adoption of a standards-based platform such as ATCA? One answer lies in delivering the truly interoperable components that were the intent and promise of the PICMG specification developers. Through multiple interoperability workshops sponsored by PICMG, product developers have steadily worked to deliver on that promise. Great progress has been made over the years in areas such as the fabric interface and manageability. Yet system integrators still face challenges in other areas, in particular, achieving thermal interoperability among ATCA blades and shelves/chassis.

Cooling System Design in the ATCA Shelf

Before discussing the thermal issues, it may be helpful to briefly review the cooling system design in an ATCA shelf (Figure 1). In a typical airflow pattern, fresh air is drawn into the shelf at the bottom front and moves through the card cage from bottom to top. The heated air is exhausted from the top rear of the shelf. Air is moved with fans or blowers configured in a push, push-pull or pull configuration. 36

April 2007

The characteristics of airflow through the card cage where the blades are installed are different for each slot, and differ within the slots from front to rear. These differences are created by the location of the fans or blowers within the shelves. As blades are installed into the shelf, they also have an influence on airflow within the shelf based upon their characteristic impedance. Blade impedance is typically illustrated by a flow pressure (P-Q) curve that shows the pressure drop at specific levels of airflow (Figure 2). As airflow increases so does the associated pressure. The greater the height and density of a bladeâ&#x20AC;&#x2122;s components, the greater blade impedance will be. A board with the typical SBC P-Q curve is the Intel NetStructure SBC MPCBL0050 (Figure 3). Air moving through the shelf tends to take the path of least resistance. If there is an empty slot adjacent to a blade, more of the air will move through the empty slot. This is one reason most shelf suppliers recommend or require the use of air management blades in unused slots. Since blades typically have different impedance characteristics, system integrators are now looking for mechanisms at the blade and shelf levels that will help distribute available airflow more evenly where it is needed.

Incompatibilities and Varying Methodologies

In early versions of the PICMG spec, the front and rear slot power was limited to 200 watts. The first generation of ATCA shelves was designed to provide around 200W per slot of cooling capacity. In subsequent generations, blade power dissipation limits have been raised and shelf capabilities have been increased. However, a basic problem remains for the system integrator to make sure that a selected set of blades can be adequately cooled in a specific slot configuration. In short, putting a blade with a dissipation of 200W into a slot in a shelf with 200W/ slot cooling capacity was no guarantee of compatibility under all operating conditions, due to the variance in slot flow patterns and blade cooling requirements. What was needed was a way to characterize the shelf slot airflow and to use that information to determine if a blade could be adequately cooled in a given slot. Although it was a common problem, shelf suppliers and blade developers worked independently to develop methods for measuring and characterizing airflow. Several good methods were developed, but there was little effort to correlate data from the different methodolo-

IndustryInsight

gies among ATCA suppliers, and there were enough discrepancies in the data to cause continued problems. For example, using one methodology a blade developer may experimentally determine that 15 cubic feet per minute (cfm) of airflow is required to cool a blade. A shelf developer using a different methodology may determine that the shelf provides 16 cfm to the slot. It looks like a good match, but the blade supplierâ&#x20AC;&#x2122;s airflow measurement methodology might determine that the shelf is only providing 13 cfm, due to a lack of correlation between methodologies. Characterizing airflow within the slot and getting good correlation between differing methods is not easily accomplished.

Although these tools and methods help blade designers more effectively make use of available airflow to cool

the blade, they are generally not effective in helping integrators determine optimum configurations for their systems.

Using Thermal Simulation Tools

Y X

Figure 1

Typical airflow pattern in an ATCA shelf as shown from the side.

Wind Tunnel Results -- ATCA Blades 6/27/05

0.50 0.45

ICD FSB

0.40

Pressure (in wtr)

Aside from measurement methods to determine blade cooling requirements, developers commonly use thermal simulation tools such as Flotherm or IcePak to model the blade operational environment. A physical model of the blade is created that includes all of the components that significantly contribute to heat dissipation. Modeling is complex and time-consuming, but it allows developers to analyze and evaluate different component placement options to more effectively use available airflow for cooling the components. Even though modeling can be quite detailed, there will always be some inaccuracies. To supplement thermal simulation, blade developers also use thermal mockups to evaluate potential component placements. A mock-up is a board mounted with devices that dissipate heat equivalent to the components used in a design. The mock-up board is instrumented with thermocouples and then installed into a slot in the shelf to measure key component temperatures to determine if they are being adequately cooled. These thermal mock-ups can be a very effective tool in helping blade designers to understand thermal characteristics of their board designs, as well as for feedback into the simulation models to improve the accuracy of future simulations.

0.35 0.30 Air Mgmt. Blade

Typical SBC

0.25 0.20 0.15 0.10 0.05

Switch Blade

0.00 0

Flow (CFM)

Figure 2

Signal Blade

Typical flow pressure curves for blades. April 2007

IndustryInsight

So the problems of the systems integratorsystem integrator in selecting thermally interoperable components remain to be resolved.

Determining Airflow Rates and Impedance Characteristics

Another methodology for determining the ability of an ATCA-compliant board to operate in an ATCA-compliant shelf slot is based on airflow rate and impedance characteristics of the board and the shelf slot. For a system integrator to make this determination, data on the blade’s airflow and impedance characteristics, as well as the shelf’s airflow and impedance characteristics, must be determined. With this data, the system integrator needs to make the following judgments: a) does the shelf provide adequate airflow pressure characteristics to meet the board’s requirements, and b) is the airflow provided by the shelf adequate to meet the minimum flow rate for the power dissipated by the board? The shelf slot’s airflow capability to meet the power dissipation requirements from the board can be determined by the equation that relates power dissipated by board components into the air stream to the ability of the air stream to absorb and carry away the heat. This is given by: Q = PCpVdT

Figure 3

The Intel NetStructure SBC MPCBL0050 contains two Dual-Core Intel Xeon processors and has a typical SBC P-Q curve.

where Q = power dissipation, P = density of air, Cp = specific heat of air, V = volumetric flow rate, dT = temperature rise of air across the board. The system integrator must determine if the flow-impedance characteristics of the blade and the flow-impedance characteristics of the target shelf are compatible in meeting this requirement. The process for determining this consists of several major steps. The board P-Q curve alone measures only board characteristics, not how those characteristics are affected by the shelf. The latter P-Q curve adds the flow effects from items such as air filters, EMI screens

Adjusted Chassis Fan Curve vs. Empty Slot PQ Curve 1.4

Pressure (inches water)

1.2 1.0 0.8

0.6 0.4

0.2 0.0 0

100 150 200 250 300 350 400 450 500 550 600 650 700

CFM

Figure 4 38

CFM

Adjusted shelf fan curve plotted with the empty slot P-Q curve.

April 2007

and entry/exit grills, and also includes effects of flow patterns internal to the slot created by the position of fans or blowers. Therefore, the slot airflow-impedance or P-Q curve for the board must be combined with the P-Q curve for an empty or unpopulated slot to yield the P-Q curve for the board in the shelf slot. Next, the effects of the shelf fans or blowers, subsequently referred to as air movers, need to be determined for the individual slot under analysis in order to determine a slot fan curve. Starting with the air mover manufacturer’s specification or measured data, this curve may need to be modified based on the particular air mover position and orientation. For example, axial fans in series with flow-straightening vanes increase not only back-pressure performance, but slightly modify flow velocity across the outboard fan, due to the improved angle of attack of the straightened flow from the inboard fan. This enhanced fan curve needs to be adjusted to a shelf-wide curve, which can be achieved by increasing the flow output as a function of the number of air movers at constant pressure drop to provide an adjusted shelf fan curve. When the adjusted shelf fan curve is plotted with the empty shelf slot curve, the pressure differentials captured successively to the left of the intersection of these two curves and plotted against the corresponding flow rates divided by the number of slots in the shelf will generate the coordinates of the slot fan curve (Figure 4). The slot fan curve can then be plotted against the board in slot P-Q curve to define the slot operating point. Solutions consistent with the board and slot characteristic flow pressure requirements will be located at flow rates to the left of the intersection of these two curves. In this example, the required flow rate is slightly to the left of the operating point. Therefore, the shelf will barely meet minimum blade requirements, with only a small margin for operation based on airflow and flow impedance characteristics (Figure 5). For added margin, greater flow rates are thus indicated. This analysis method provides a general guideline for the system integrator to determine whether a particular board will

IndustryInsight

CP-TA Standards and ATCA Thermal Interoperability

In 2006, the Communications Platforms Trade Association (CP-TA) was formed with the mission of addressing interoperability issues, including ATCA thermal interoperability. The publication in early 2007 of an Interoperability Compliance Document version 1.0, along with a Test Procedures Manual, starts to address some of the thermal interoperability issues discussed above. As a significant first step, a slot airflow measurement tool has been developed by CP-TA with the intent of creating an industry standard for slot airflow measurement. This tool enables characterization of shelf capabilities under normal, full-fan speed, fan failure and fan tray replacement conditions. It measures airflow in the four separate quadrants of the front slot and also in the rear transition module area of the slot. The reports generated from this testing will enable integrators to get a more consistent and reliable evaluation of different product capabilities than has ever been available before. As blade performance continues to grow, so will the challenges of working within the limitations of the ATCA thermal environment. Thermals are just one area where work is ongoing. Blade and shelf designers must continue to strive to ease the effort of system integrators if they are to realize the promise of truly interoperable components. It is the success of these efforts that will accelerate market adoption of standards-based platforms such as ATCA.

Slot Operating Point 1.3 1.2 1.1 1.0 0.9

Pressure WC

operate in a target slot. However, to use this method the system integrator must be capable of gaining reliable data from board and shelf vendors on the flow-impedance characteristics of their products. In addition, this approach is intended only as an initial step. To improve confidence it should be followed by more in-depth analysis focused on a detailed thermal investigation of board-specific thermal characteristics, such as hot spots.

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 0

CFM

Figure 5

Determination of operating point.

We Listen. Think. And Create. Distributed I/O

Digital I/O

Serial I/O

Industrial Computing

HMI

SeaLINK Ethernet Serial Servers Offer:

SeaLINK Ethernet serial servers are the fastest, most reliable way to connect serial devices to your network.

• 1, 2, 4, 8, and 16-Port Models • RS-232, RS-422, RS-485, and Optically Isolated Versions • Included Software Enables Virtual COM Port Operation • Easy Installation and Conguration • DIN Rail or Table Mount Design • Extended Temperature Option Available

F CUS On Success

Intel Santa Clara, CA. (408) 765-8080. [www.intel.com].

April 2007

IndustryInsight Thermal Management on ATCA

Designing ATCA Cards for Optimal Thermal Performance in Managed Chassis The thermal design of high-powered ATCA cards is especially challenging because the standard depends on multiple vendors. Designers can take specific steps to ensure that cards will work as expected in managed chassis. by M ike Coward Continuous Computing

April 2007

Thermal Objectives of ATCA Systems

A well-designed system should satisfy three key thermal requirements. All chips must run within their specified thermal limits, and all fans should run at the minimum possible speed in order to maximize lifetime and minimize acoustical noise. Finally, the system must be able to operate across a wide temperature range, from -5° to +55°C according to the Network Equipment Building System (NEBS) specification, or from -5° to +45°C according to the European Telecommunications Standards Institute (ETSI). Three cooling approaches can be used to satisfy these requirements. In the simplest approach, fans always run at maximum speed and provide the best possible cooling. However, they are generally too noisy and limit the cooling system’s lifetime.

Airflow

esigners who are new to AdvancedTCA often feel relatively unconstrained by this platform and its form-factor. Compared to cards based on other standards, such as VME or CompactPCI, AdvancedTCA cards are bigger, components can be taller and power is three to four times more available. Of course, the needs of the application and the creativity of the engineer soon fill the blades and these limits are tested. Thermal design in AdvancedTCA (ATCA) systems poses a particular challenge because ATCA is a multi-vendor standard. Consequently, customers expect interoperability between various blades, shelf managers and chassis from different vendors. There are certain steps the designer can take in order to ensure that the card will work as expected in a managed chassis.

Figure 1

High-power components should be placed correctly across the blade to avoid concentrating the thermal load. In Continuous Computing’s 10 Gigabit Ethernet packet processing blade, the FlexPacket ATCAPP50, the CPUs and switch, shown here in colored squares, are staggered across the blade.

GE Fanuc Embedded Systems

Flexibility like this deserves applause Introducing the industry’s most flexible 6U Compact PCI single board computers Of course, you could change your project. But wouldn’t it be better if you didn’t have to? If you could find the single board computer that precisely meets your needs? Look no further. The new Intel®-based family of PICMG 2.1-compliant 6U CompactPCI SBCs from GE Fanuc Embedded Systems is characterized by outstanding flexibility in the range of options it offers. Market-leading performance is a given – and remarkably low power dissipation, coupled with optional ruggedization, means it can perform in the most challenging environments.

processor – coupled with ATI 2D and 3D graphics. Up to 4GB memory (soldered, in order to maximize robustness and reliability). Dual Gigabit Ethernet. Flash drive or UDMA hard disk – or both. Two RAID-capable SATA channels. Two PMC sites. Four USB 2.0 ports. There’s even a choice of operating system.

But it’s in its flexibility that it excels. Three choices of processor, including a state of the art Intel® Core™2 Duo

www.gefanucembedded.com

The CP11, CT11 and CR11 from GE Fanuc Embedded Systems. We designed them to be flexible so you don’t have to be.

CR11 6U Compact PCI single board computer with Intel® Core™2 Duo or Intel® Core™ Duo processors

IndustryInsight

Critical Alert Condition

Upper Critical Threshold Critical Hysteresis Upper Major Threshold Major Hysteresis Upper Minor Threshold Minor Hysteresis

AGH

DGH Major Alert Condition

AGH

DGH Minor Alert Condition

AGH

DGH Normal Operation Condition

AGH = Assertion Going High

Figure 2

DGH = De-Assertion Going High

IPMI thresholds from the PICMG 3.0 R2.0 specification. Courtesy of PICMG.

In a temperature-compensated approach, fan speed varies directly with incoming air temperature. A temperaturecompensated approach is straightforward to implement, but has obvious limitations: a system full of low-power blades might be over-cooled and a system full of highpower blades might be under-cooled. The best solution is therefore a third approach, an adaptive cooling strategy, where fan speed is adjusted according to thermal measurements taken from the blades. An adaptive cooling strategy ensures that blades receive sufficient airflow for reliable operation, but also minimizes fan noise and lengthens fan lifetime by running the fans below their maximum speed. Implementing an adaptive cooling strategy in a multi-vendor environment

such as that of ATCA requires considerable detailed specifications for how blades, shelf manager and fan trays should interact. Fortunately, the ATCA specification delivers a rich set of specifications, tools and requirements to ensure thermally managed solutions.

Component Placement in Thermal Design

The most important factor in thermal design is correct placement of high-power components. These should be arranged across the blade to avoid concentrating the thermal load in any one section. For example, in Continuous Computing’s 10 Gigabit Ethernet packet processing blade, the FlexPacket ATCA-PP50, the three highest-power components dis-

Measurement(s)

Root Cause

Corrective Action

- Ambient temperature is too hot - CPUs are too hot

Room air conditioner failure

Repair air conditioner

- Ambient OK - Both CPUs too hot

Replace fan module and/or Insufficient airflow: air filter bad fan module or clogged filter

- Ambient OK - One CPU too hot - One CPU OK

Failure of CPU chip or thermal pad failure

Table 1

Replace blade

Remotely diagnosing the root cause and assigning corrective action for thermal alert conditions is made easier for high-performance blades when they are equipped with one sensor per critical component.

April 2007

sipate 50, 50 and 20 watts each, respectively (Figure 1). These components are staggered across the blade so that each receives a separate column of air and none of the components affect each other thermally. In addition, the two hottest components are strategically located at the top half of the blade. This placement ensures that the hot air from these two upper processors does not affect other sensitive components in the design.

Selection and Placement of Thermal Sensors

The correct selection and placement of temperature sensors is critical for the blade’s participation in the thermal management of the overall system. Temperature sensors should be placed strategically: one sensor on each of the design’s high-power ICs and at least one sensor to measure incoming air, or ambient, temperature. The most critical measurement in the system is the silicon die temperature of the blade’s high-power devices. These components usually constitute the limiting factor in the thermal design of the blade because they generate the most heat, yet they are the most sensitive to heat. Providing an accurate measurement of the silicon temperature allows the limits of the design to be properly explored and monitored. Many vendors include a thermal diode on the die itself to provide accurate temperature measurements. This diode has a known correlation between temperature and voltage drop, and this voltage drop can be measured with high accuracy to determine the temperature of the die. Ascertaining silicon die temperature is a tricky analog measurement. However, a number of ICs are available that connect directly to this diode and include the conversion circuitry necessary to report the temperature as a digital measurement over the inter-integrated circuit (I2C) or serial peripheral interface (SPI) bus. In addition to measuring die temperature, an ambient temperature sensor should be included as part of the design. The ambient temperature sensor should be placed near the bottom edge of the

IndustryInsight

blade to measure the temperature of incoming air and located away from any high-power components to avoid erroneous measurements. Each of these sensors should be connected to the Intelligent Platform Management Controller (IPMC), not to the payload CPU, in order to allow the IPMC to accurately monitor and report on the thermal condition of the blade.

Multiple ATCA Power Levels

parameters but is nearing their limits. A critical alert is when the blade is outside of normal operating range. When all sensors are in the normal operation condition the shelf manager minimizes the fan speed, or sometimes sets the fan speed based on the current ambient temperature measurements. If a sensor reaches the minor alert condition level, the shelf manager increases the speed of the fans to bring the

blade back to normal operation condition. If it is unsuccessful and the blade continues to heat up and reaches the major alert condition, the shelf manager sets the fans to maximum speed and instructs the blade to assume a lower ATCA power profile. If a sensor reaches the critical alert condition, the shelf manager is expected to take the blade out of service and turn it off to prevent damage.

AdvancedTCA defines multiple power levels for a blade. It includes an infrastructure that can query the possible power levels that a particular blade can support and can then set the bladeâ&#x20AC;&#x2122;s maximum power level. Blades can implement multiple levels by using CPUs that operate at different speeds, such as Intel Xeon processors with Speedstep technology. A second useful implementation of power levels allows AMC carriers to enable different numbers of modules to comply with the assigned power level. These multiple power levels are intended to be used in two situations. The first is during configuration, when a chassis is designed for less than 200W/ slot and needs to limit the current draw in order to stay within the system-level maximums. The second is at run-time, if the ambient air temperature is too high and the shelf cannot sufficiently cool the cards even with the fans operating at maximum speed. In this case, the shelf manager can instruct the blades to use a lower power level in order to stay within specification.

Temperature Threshold Limitations

The ATCA specification requires that every blade have at least one temperature sensor, but high-performance blades should have one sensor per critical component. There are four thermal state levels for blades in ATCA systems (Figure 2). Normal operation is when the blade is operating within thermal limits. A minor alert occurs when the blade is operating within these limits, but is getting warm. In a major alert, the blade is within these April 2007

IndustryInsight

One example that illustrates the power of a rich set of sensor data is how an over-temperature alarm would be handled. In an unmanaged central office, it is critically important that a faulty component be diagnosed with a high degree of accuracy in order to generate appropriate corrective actions for a technician. For example, a packet processing blade that is reported to be overheat-

ing may have two thermally monitored CPUs and an ambient temperature sensor (Table 1). Even with only three sensors, the root cause and appropriate corrective action can be determined with a high degree of accuracy.

Other Thermal Considerations

One other significant consideration to system-level thermal design is ensuring that the chassis airflow reaches the most

critical blades, that is, those that most need airflow. It is an unfortunate quirk of nature that blades that need the most airflow, such as a CPU blade, tend to have the largest heat sinks and present a high blockage to airflow. These blades are the most difficult to cool effectively in a chassis environment. At the same time, blades with a small number of active components, such as switch blades, require very little airflow, but present little resistance to the airflow. When a switch blade with low impedance is placed next to a CPU blade with high impedance, air will tend to flow preferentially across the switch blade. In order to ensure sufficient airflow across the CPU, the fan speed will have to increase. Consequently, the excess airflow across the switch blade will be wasted. In the best case, the CPU receives sufficient airflow and the only system cost is excessive noise and wear on the fans themselves. In the worst case, the CPU does not receive sufficient airflow even with fans at maximum speed, and the system will not perform properly across the full ambient temperature range. The solution to this dilemma is to add baffles to the low-impedance cards, which restricts air on these cards and ensures that the higher-impedance cards receive sufficient airflow. Recent work on this is being driven by the Communications Platform Trade Association (CP-TA), which is working to establish interoperability standards for ATCA, including electrical and thermal concerns. CP-TA is defining airflow profiles, and suggests the use of impedance matching baffles. Although thermal design is sometimes treated as an afterthought, it can be a challenge to ensure robust operation across the thermal environment required by NEBS/ETSI, especially given the complexities posed by varied system configurations and a multi-vendor community. Continuous Computing San Diego, CA. (858) 882-8800. [www.ccpu.com].

April 2007

Cool. Calm. Collected. The Themis Slice™ architecture can handle whatever you or the outside world throw at it.

Cool.

Innovative and cost-effective cooling system can tame the hottest of processors in four 100 Watt sockets that support eight processor cores. Air and liquid heat exchanger options.

Calm.

Standardized mechanical footprint designed to survive in high shock and vibration environments - up to 40G shock and 1 grms vibration.

Collected.

Scalable - up to 16 processor cores. High-density, processor-independent architecture implemented with SPARC®, IBM®, PowerPC and x86 technology. Solaris™, Windows®, and Linux® operating systems. All networked in a single system. All managed in real-time.

Themis’ Slice technology is a breakthrough in lifecycle management for mission-critical computing. By functionally disaggregating commercial computing resources and housing them in a standardized footprint, purpose-built enclosure, Slice provides resilience with superior thermal and kinetic management. This open and modular design allows for spiral technology refresh, extending computing infrastructure investments for complete lifecycle management. Themis’ real-time resource manager integrates all computing resources, under dynamic policy control, to optimize application quality of service. Themis Slice is transformational technology offering the most robust and efficient platform available. No other platform will enable the 21st century war fighter as effectively.

www.themis.com (510) 252-0870

Transformational. © 2005. Themis Computer, Themis, Themis logo and Themis Slice are trademarks or registered trademarks of Themis Computer. All other trademarks are property of their respective owners.

IndustryInsight Thermal Management on ATCA

Automated Thermal Characterization of ATCA Shelf, Blades Delivers Thermal Interoperability A wind tunnel that measures ATCA board impedance, and automated test tools that measure flow volumes through ATCA shelf slots, help determine whether blades and shelves are thermally interoperable. by T odd Keaffaber, Technical Work Group Chair, Communications Platforms Trade Association Rajesh Nair, Thermal Task Force Chair, Communications Platforms Trade Association

he interoperability of ATCA modules depends on their thermal compatibility. The Communications Platforms Trade Association (CP-TA) has developed methods for measuring Advanced TCA (ATCA) shelf and board characteristics to ascertain their thermal interoperability, consisting of automated test tools that measure the flow volumes through each slot in an ATCA shelf, and a special wind tunnel created to measure the impedance of an ATCA board. These tools and test processes are derived from the Interoperability Compliance Document (ICD) and the Test Procedure Manual (TPM) documents released by the CP-TA. The ICD, the TPM and the concept behind these test tools were developed with the help of members of the CP-TA Thermal Task Force.

CP-TA Interoperability Efforts

The CP-TA, an association of thirty communications platform and building block providers, is dedicated to accelerating the adoption of special interest group-governed, open specification-based 46

April 2007

communications platforms through interoperability certification. With industry collaboration, the CP-TA plans to drive a mainstream market for open industry standards-based communications platforms by certifying interoperable building blocks. The CP-TA has developed interoperability requirements for PICMGâ&#x20AC;&#x2122;s ATCA specification in the ICD. CP-TA and

PICMG have completed a liaison agreement that will allow the two organizations to exchange information. The groups will also work together on joint interoperability plugfests and training sessions. Released in February 2007, the ICD defines a set of requirements for building interoperable communications platforms. The TPM defines test procedures for those requirements. Together, these two docu-

Chassis Airflow Distribution

FBQ4

FBQ3

FBQ2

FBQ1

20 15 10 05 0 Slot 01

Figure 1

Slot 02

Slot 03

Slot 04

Slot 05

Slot 06

Slot 07

Slot 08

Slot 09

Slot 10

Slot 11

Slot 12

Slot 13

Volumetric airflow through each quadrant of a 14-slot shelf.

Slot 14

High Sampling Rate PCI and PXI Data Acquisition Cards for Higher Throughput per Channel Available in both PCI and PXI form factors, the DAQ-2016 and PXI-2016 feature a sample rate up to 800kS/s per channel. Designed for large-scale data collection and industrial automation, these four-channel cards offer 16-bit resolution, 24-bit programmable DIO, and a variety of analog and digital trigger sources and modes for efficient multi-channel simultaneous sampling. Both the DAQ-2016 and PXI-2016 cards can synchronize multiple external devices using a system synchronization interface or a PXI trigger bus.

High-Performance 3U CompactPCI Intel® Pentium® M/Celeron® M Processor SBC with Dual GbE on PCI Express

For more info, go to: www.adlinktech.com/products

The cPCI-3915 CPU board is a 3U 4HP or 8HP system slot single-board computer with up to 2.0GHz for the Intel ® Pentium ® M CPU. This SBC is based on the Intel ® 915GM chipset with 400 or 533 MHz FSB. One SO-DIMM socket carries up to 1GB 400/533 MHz non-ECC DDR2 RAM. The cPCI-3915 offers two Gigabit Ethernet ports, two RS-232 ports, one IDE ATA 100/66/33 port, one CompactFlash socket, two SATA-150 interfaces, three USB 2.0 ports, and a VGA/DVI interface. The Ethernet ports support PXE remote boot. For more info, go to: www.adlinktech.com/products

These low-power, high-performance compact motherboards feature:

Compact Multi-Application Computer with new CPU options The GEME-52000 is the latest improvement of the GEME family by offering an Intel ® Pentium® M processor Low Voltage (up to 1.6GHz), USB 2.0 ports, LVDS support, and DDR RAM. GEME units can be controlled from remote locations and run continuously in vital applications, such as machine tools control and digital video capture. The GEME-52000 also comes equipped with anti-vibration features. For more info, go to: www.adlinktech.com/products

Highly-efficient Intel® Core™2 Duo processors Dual-Channel DDR2 memory (up to 2GB at 533/667MHz) Dual Gigibit Ethernet ports via x1 PCI Express® bus Intel® 945G Express chipset PCI Express® and PCI expansion slots

The M-946 Features: microATX form factor Up to 1066MHz front side bus 1600 x 1200 (DVI) and 1600 x 900 (LVDS) display resolutions x16 PCI Express® lane for optional high-end graphics card LGA775 Socket for Intel® Core™2 Duo, Intel® Pentium® D, Intel® Pentium® 4, and Intel® Celeron® D processors

The M-885 Features:

Get to Market Quickly while Lowering Your Development Costs with ETXexpress Modules The high performance ETXexpress-IA533 features an Intel ® Pentium® M processor up to 2.0GHz running on a 400/533MHz FSB. The ETXexpress-IA533 is complimented with the Intel ® 915GM Express chipset supporting dual channel DDR2 at 533MHz and four x1 PCI Express lanes. In addition to the on-board integrated graphics, a graphic PCI Express x16 slot is also available.

FlexATX form factor 533/667 front side bus 1600 x 1200 (LVDS) display resolution Socket M for mobile Intel® Core™2 Duo, Intel® Core™ Duo, Intel® Core™ Solo, and Intel® Celeron® M processors

Call us toll-free at (866) 4-ADLINK or email info@adlinktech.com

All ADLINK ETXexpress modules also come as part of a development kit for creating fully operational host target environments for embedded Linux software development in record time. For more info, go to: www.adlinktech.com/products

www.adlinktech.com

IndustryInsight

ments will allow vendors to design and deliver interoperable, open specificationsbased products. These test requirements are aligned to the ATCA profile published by the SCOPE Alliance. The ICD and TPM address three integral areas of interest for communications providers that construct ATCA platforms: thermal, manageability and data transport. Thermal interoperability is a gating factor for the interoperability of ATCA modules. In addition to the ICD and TPM, CP-TA members are developing thermal test tools—the Chassis Scan and the Blade Profiler—to enable vendors to test their products for CP-TA compliance to the thermal requirements spelled out in the ICD.

Thermal Interoperability Between Modules

In an open specifications-based architecture such as ATCA, proper interoperability between modules determines the commercial success of the

Pressure Sensor

platform. Interoperability is required for all interfaces between modules from mechanical fit, electrical power and signal integrity, to inter-module communications protocol compliance and thermal compatibility. Thermal interoperability is defined here as the ability for a compliant shelf to adequately cool a compliant blade. To achieve this, it is necessary to match the thermal and airflow characteristics of shelf slots and blades. An ATCA shelf is responsible for providing a minimum airflow and pressure performance in each slot. A compatible blade is required to utilize available shelf airflow effectively for cooling devices mounted on the blade. To facilitate the thermal interoperability of both the shelf and the blade, it is necessary to characterize them independently using a standard test process and standard tools. The test method and tools must accurately measure the airflow through the chassis slots as well as the impedance of the boards, and should

Airflow Sensor

Airflow Sensors

Airflow/Pressure Sensor and Tunnel Controller

Figure 2

Blade Profiler, a wind tunnel system for flow impedance measurement.

April 2007

be able to simulate a variety of conditions automatically.

Characterization of the Shelf

The airflow characteristics of a shelf are primarily defined by two quantities: 1) the volumetric airflow the shelf supplies to each slot at a specified slot resistance, or impedance, and 2) the airflow distribution within a slot, from front to back. Using this information, it can be determined if a given blade with known impedance and power dissipation can be cooled adequately. In an effort to evaluate the airflow characteristics of a chassis, a test tool called Chassis Scan was developed.

The Chassis Scan Test Tool

Currently, there is no industryaccepted standard measurement technique for comparing shelves in terms of airflow volume through each slot in the shelf. However, an automated methodology of measuring the volumetric airflow delivered to each slot in an ATCA shelf has been developed. Adopting this technique allows the data to be used to benchmark each shelf. The Chassis Scan test tool enables evaluation of airflow characteristics through each slot position in a shelf and the flow distribution within each slot. The system consists of four types of modules that fit into ATCA front and rear slots. Two of these modules have airflow sensors in them, namely, the front flow measurement board (FFMB) and the rear flow measurement board (RFMB). The other two modules—flow impedance boards for the front slots and the rear slots (FFIB and RFIB, respectively)—provide identical impedance to the slot. All modules contain a mechanism to straighten the airflow at the intake and exhaust. The FFMB and the FFIB have equivalent impedances, and the RFMB and the RFIB have equivalent impedances. The FFMB and RFMB each have low-profile airflow sensors, specifically hot wire anemometers, positioned at the midline of the board. The FFMB is built with twelve sensors and the RFMB has three sensors. The twelve sensors in

The airflow profile within the shelf is reported for each test condition mentioned before, as a graph showing flow through each quadrant in each slot (Figure 1). This information helps the user in selecting the best slot in the shelf for locating a blade with high power and impedance characteristics. The CP-TA Interoperability Compliance Document (ICD 1.0) categorizes shelves into classes per its airflow characteristics as tested using this method.

Characterization of the Blade

The airflow over a blade in a shelf depends primarily on two factors: the flow characteristics of the shelf slot and the flow impedance of the blade. The impedance is defined as: Z = P/Q2 where P is the pressure drop across the blade and Q is the volumetric airflow over it.

Airflow, Q

Figure 3

Airflow impedance curve of a blade.

Airflow, Q (CFM)

the FFMB are distributed among four quadrants. These sensors are calibrated to measure and transmit linear velocity to a PC where a software application converts the data to volumetric airflow. The application provides the total volumetric airflow for the slot and the volumetric airflow through each quadrant. The FFMB and RFMB are manually stepped through each slot to obtain the overall airflow profile across slots in the shelf. This airflow profiling process is repeated for several operating conditions of the shelf such as: • Fans operating at 7.2 Bels acoustic noise level, the Network Equipment Building System (NEBS) specification limit • Fans operating at maximum speed, a failure condition • Fans operating at minimum speed, normal operating conditions • Each of the fans under a failed condition, either a single fan failure or a locked rotor failure • Each fan module removed, a service condition

Pressure, P

IndustryInsight

Future Interoperability Work Q1

Figure 4

the channel. A sensor measures the pressure drop across the blade. The fan speed can be varied to generate different airflow levels by the PC (Figure 2). The PC application determines the flow impedance by varying the fan speed and measuring airflow and pressure drop, which is then plotted (Figure 3). The flow distribution across the blade is measured by the array of sensors and the airflow levels in the quadrants are plotted (Figure 4). This enables the blade designer to evaluate component placement in order to address flow blockage and heat dissipation.

Q3 Q2 Quadrants

Airflow distribution over a blade.

Matching the airflow impedance with the airflow performance of a slot is necessary to ensure reliable operation and adequate cooling. The impedance measurement consists of measuring the airflow over the blade and the pressure drop across it when placed in a shelf slot. Often, the impedance distribution over the blade is not uniform. There may be a channel for air to bypass high-density, high-wattage devices altogether. The measured impedance may look low, but many of the critical devices may not experience any airflow. To address this, it is important to measure airflow at multiple locations across the exhaust end of the blade.

The Blade Profiler Test Process

The blade can be profiled for both gross impedance and airflow distribution in a wind tunnel with pressure and flow sensors. The Blade Profiler is a wind tunnel specifically designed to mimic a slot in an ATCA shelf and measure the impedance presented by the blade. It has several airflow sensors that measure linear flow distributed across

Currently there is no industry-accepted methodology for measuring the volumetric airflow and impedance of ATCA shelves and blades. Following CP-TA’s ICD and TPM, the Chassis Scan and Blade Profiler automated tools have enabled a standard platform, such as ATCA, to offer better interoperability between shelves and blades from different vendors. Following the conclusion of the recent Mountain View Alliance Communications Ecosystem Conference (MVACEC) in San Diego, CP-TA and PICMG members participated in a Thermal InteropFest that allowed them to use the Chassis Scan and Blade Profiler to test their products for the first time. In the near future, CP-TA will address interoperability requirements for PICMG’s MicroTCA and AMC specifications, as well as specifications from the Linux Foundation and the Service Availability Forum. CP-TA members will be able to conduct self-testing in the first half of this year. The association plans a third-party interoperability lab to be running in Q4 2007. Vendors of products that pass the third-party certification testing will be able to label their products as certified by the CP-TA. Communications Platforms Trade Association Beaverton, OR. (503) 619-0680. [www.cp-ta.org]. April 2007

Executive Interview

“The Market for VME/VPX won’t decline, but instead will continue to grow.” RTC Interviews Tom Quinly, CEO, Curtiss-Wright Controls Embedded Computing

RTC: There seems to be a trend in the from competitors, and by encouraging embedded computer industry to atthe growth of outsourced content, which tempt to supply more and more comcontinues to be the largest opportunity plete systems to OEMs, thus climbing for our industry. As far as consolidation up the food chain in hopes of increasing is concerned, we do see it continuing berevenue with the additional parts of the cause of the many benefits it provides for systems supplied. It would appear that customers. Curtiss Wright has done this through a variety of acquisitions over the past “Our core value several years. The idea apparently is xploration r your goal for companies to provide additional proposition—to be the ak directly parts of systems—and in some cases page, the entire subsystems and systems. Do you resource. leader in transitioning believe the industry will continue to hnology, nd products consolidate in this way? At what point do you think embedded computer supcommercial technologies pliers will begin competing with their customers? into deployed highQuinly: First, I’d like to make an important distinction between competing with performance applications.” customers and becoming an important component in their value chain. We don’t anies providing solutions now compete withandour customers, Today, ation into products, technologies companies. Whetherwe youroffload goal is to research the latest our customers are putting by taking onpage, technology increased on their value chain cation Engineer,their or jumpburden to a company's technical the goal ofand Get Connected is toemphasis put you ce you require for whateverintegration type of technology, system challenges for the speand they’re actively looking for vendors es and products cific you areareas searching for. of their problem for which we to provide more of the solution. In some have expertise and IP, enabling them to cases the customer has already made the get to market faster by focusing on their transitional decision that they don’t want own unique strengths. They have enough to buy boards anymore, but instead they’re challenges at the application and the syslooking for fully integrated solutions. For tem level. While growth comes partly these customers, if you’re not in the pofrom new product lines and roadmaps, sition to address those needs you won’t for us it also comes from providing techeven make their short list. And for some nology leadership in the rugged deployed customers, they are just now opening up defense and aerospace market, by sucto the concept after they realize that we cessfully taking significant market share can help solve a lot of their time-to-market challenges. Get Connected Driving much of this move up the with companies mentioned in this article. food chain for embedded vendors like www.rtcmagazine.com/getconnected Curtiss-Wright is how rapidly the com-

End of Article

April 2007 Get Connected with companies mentioned in this article. www.rtcmagazine.com/getconnected

plexity of systems is increasing, while at the same time the customer is getting pressed by their own customer to get solutions deployed quickly. System complexity brings challenges, such as high-speed backplane fabrics and thermal management issues, which have to be solved at the chassis level. These challenges bring customers to us because of our expertise at the backplane and board level. For many customers, the COTS integrator can better coordinate the boards and thermal management at a packaging and subsystem level. RTC: RoHS has been the bane of many electronic manufacturing companies since it became effective back in July. Already many companies are claiming compliance and the transition appears to have been somewhat less severe than anticipated—or has it? Curtiss-Wright has been largely involved with military projects that are largely immune from RoHS restrictions, yet it and many other defense contractors are forced to use commercial—therefore RoHScompliant components. In addition, other companies such as Verizon totally refuse to use any lead-free parts, boards, systems or subsystems. What impact has this had on your company, and has whatever effect it will or has had already been discounted? Quinly: Our focus on the defense and aerospace market necessitates a different perspective on RoHS due to our customers’ compelling mandate for high reliability. The RoHS challenge suits our core value proposition very well—to be the

ExecutiveInterview

leader in transitioning commercial technologies into deployed high-performance applications. We are taking an active leadership position to support the long lifecycle and high-reliability needs of our customers. We have experience and expertise in selectively using lead-free components in high-reliability applications and we continue to work with industry research groups and invest in independent advanced packaging research work to help understand what the issues with lead-free components are and how best to mitigate any concerns with their use. We expect that over the coming years the component industry, driven by the volume of commercial and industrial users, will continue a shift to lead-free only versions. This means that a move to the use of lead-free components for economic reasons is inevitable. In our market, we initially saw “no lead-free” as the primary reaction. There has been almost no demand for lead-free products. But as people are getting better educated and more data is being developed, customers will come to accept that there will be mixed use of both lead and lead-free components. We are also taking leadership roles in committees to track the research on lead-free, and once we determine that the reliability issues can be overcome, we will be poised to take the appropriate steps. RTC: It’s now closing in on one year since GE Fanuc acquired one of your competitors, SBS Technologies. Prior to that SBS had a string of nine acquisitions. After SBS, GE Fanuc acquired Radstone Technology, which previously acquired ICS and others. Before that GE Fanuc acquired Condor, VMIC, Computer Dynamics and a small handful of others. Have you seen any indication of the landscape changing? In what ways? Quinly: We know from our own experience that in the short-term GE Fanuc is facing tremendous integration challenges. Leadership, channels, branding, strategies, reporting, product roadmaps, pricing, margin/profits—all these suddenly become open game for discussion.

It’s a challenging period, which likely explains the extent to which we have felt any signs of a changing landscape. Industry consolidation is inevitable as a market matures. From our perspective, we look forward to having healthy competition because it’s good for customers, good for us, because it keeps us sharply focused, and last but not least, it’s good

dards such as VITA 41 and VITA 46 and others rapidly displace VME? On what timetable do you expect to see this happening? Why? Quinly: For many applications, including system control, net-centric transformation and some levels of general purpose processing, VME continues to be a great solution. The ecosystem and criti-

for the industry. We believe that there’s still plenty of room for all of us to grow. That’s because our biggest opportunity continues to be getting our customers to increase their outsourcing, which is currently less than 15% of the available market. The presence of established, reliable names such as GE Fanuc and CurtissWright will only help to establish more confidence in customers.

cal mass of vendor support is there to ensure that customers will be supported for years to come. Curtiss-Wright continues to invest in new products for the VME64x roadmap. But there’s no question that next-generation bandwidth and ruggedization were needed to continue to deliver the benefits of the VME community to newer more demanding applications that just couldn’t be satisfied with VME64x. That’s why we’ve taken a lead in bringing VPX (VITA 46) to market. This year we gave the first public demonstration of a working VPX system at the Bus & Board Conference. At B&B seven leading vendors showed products or announced their own VPX and VPX-REDI (VITA 48) roadmaps. The products are real and design-ins are happening.

RTC: VMEbus has been a mainstay in the military and aerospace markets for the past 20-plus years. And while there have been mid-life kickers to upgrade the technology, it would appear to be reaching the end of a long run. Do you believe VME can continue to be a viable approach throughout and beyond this decade? Will other, newer stan-

April 2007

ExecutiveInterview

RTC: Not too long ago, VITA 58, the can specification that addresses ruggedness and cooling, was being billed as a major factor for all newer systems both military and commercial. In recent months, however, the media has heard little of the proposed standard. Do you believe that a standard such as VITA 58 is significant and will be the future of embedded computers? Quinly: It appears that VITA 58 was promoted by some of the defense mil integrator interests that were focused on a particular program. The direction of that program has shifted toward a Line Replaceable Module (LRM) solution rather than the Line Replaceable Unit (LRU) approach of VITA 58. We haven’t seen any notable VITA 58 standardization activity since this change in direction to LRMs. We certainly endorse the LRM approach, which is supported in VPX and VPXREDI, because of the significant reduction in logistics and cost, it makes it possible to spare and replace individual cards in the field rather than entire LRUs or subsystems. Standardized LRU form-factors or “cans” could also have benefits for the user base in particular applications, so we remain open to VITA 58 development.

Quinly: We support ex ante procedures because we believe that end users are best served by ensuring that there are no proprietary technologies built into open standards. We are strong supporters of the open standard/open architecture model. The use of patented technologies brings the threat of detrimental cost factors, as reflected by the FTC’s ruling against RAMbus. Ex ante does not inherently benefit any particular standards body members. It only ensures that there will be an ecosystem of competitors that can offer best value to their customers without concern for latent or closet monopolies to hurt them and the industry. For these reasons, we believe that VITA’s ex ante procedures initiative will help ensure the health of the open standards model. RTC: The VME Standards Organization recently started up a committee for VITA 56 that is defined as a frontpanel access, live-insertion mezzanine card that will be available in versions to handle full military shock and vibration requirements. The dimensions and capabilities are somewhat similar to AdvancedMC. Do you think there’s room for two similar mezzanine form-

“The presence of established, reliable names such as GE Fanuc and Curtiss-Wright will only help to establish more confidence in customers.” RTC: Over the past several months there has been a lot of whispering concerning the ex ante procedures that the VSO is trying to implement. There have been many comments ranging from the idea that it favors smaller companies when compared with larger companies that already have a treasure of patents and regularly trade in intellectual property, to the concept that ex ante is probably a good idea but likely to embroil companies and the organization in legal battles. Do you have any position on the ex ante procedures? What? Why? 52

April 2007

factors—one for rugged applications, the other for more benign jobs? Would the industry be better served getting behind a single specification and making it fit both types of applications? PICMG—and some of its members— have already received a lot of interest in AMC, and there are currently at least two approaches under development to ruggedized standard commercial AMC cards. Would you be in favor of a new standard, or one that already has critical mass such as AMC. Quinly: No, it doesn’t make sense to have another standard. The rugged deployed

market has already looked at and solved the problems of rugged, high-bandwidth mezzanine cards with XMC VITA 42, and the opportunities for high-performance rugged small form-factor processing are well addressed with 3U VPX. We see AMC as a telco standard. It uses a type of connector that was looked at by mil system integrators when we began the process of defining the VPX standard. We collectively realized then that we needed a connector that could survive in harsh environments. AMC’s connector is really aimed at the telco industry. It’s not designed for the rugged mil environment. The better approach is to develop a solution that addresses the unique requirements of the rugged deployed market rather than taking something designed for a benign, commercial environment and “ruggedizing” it. If the goal is to leverage the benefits of a standard commercial product, and by ruggedizing it you make it so different that it’s a unique product, then the only remaining benefit to leverage is the original product’s brand name. In comparison to AMC, the rugged mil community is basing its next-generation designs on XMC because it provides a great stepping stone up from PMC, the previous-generation standard, which everyone has used. XMC was defined with backward/forward compatibility in mind and it’s applicable to both rugged and benign environments, leveraging the same investment for both markets. For highbandwidth, serial switched fabric small form-factor computing we support 3U VPX. There will be benign military applications that can use AMC as it is. To introduce a third standard would just help to fragment the market further. RTC: VME has been a staple in CurtissWright’s embedded computer strategy for many years largely serving the military market. However, the business is changing radically. Several major players have gone end-of-life on many designs or have abandoned the architecture and chosen to focus significantly on ATCA and communications designs. While the remaining VME market remains relatively strong, 1) can it continue to be a viable force in the embed-

ExecutiveInterview

ded computer board and subsystem market in light of growing competition, and 2) will a critical mass of suppliers continue to offer the variety of products required? 3) Does there continue to be a market for VME outside the military? Quinly: As I was stating earlier, the COTS ecosystem supplying the defense market is now vital and large enough to sustain itself. The market for VME/VPX won’t decline, but instead will continue to grow. The recent acquisitions in our market reflect the perceived growth opportunity. And there continues to be new entrants into this market. These new players will, as has proved the case in the past, find solutions to problems not addressed by the bigger companies. The technological advantages and rapid acceptance of VPX proves that the VME ecosystem’s success was based on its ability to adapt. The embedded market has critical mass now, with sizable suppliers investing significant R&D to provide the latest technology to mil and aerospace customers. Another part of the answer, again, is that the current COTS market is only a small piece of the total available market. In regard to markets outside of the military, there may well be a market for VME, but it doesn’t concern us whether there is or isn’t. Our focus is strongly on the mil market. RTC: Curtiss-Wright has been successful in the marketplace primarily based on VME and cPCI products. However, requirements change. As, for example, the military moves to a more networkcentric structure, systems based on ATCA and perhaps in the not too distant future, MicroTCA, may migrate from the commercial world to some military applications—particularly shipboard and land-based. Has Curtiss-Wright any plans to join the ATCA/MicroTCA marketplace? Why/why not? Can we expect to see product introduction in the not too distant future? Quinly: We agree that the mil market is absolutely endorsing a net-centric architecture and we are responding with products that directly address those needs including Gigabit Ethernet and IPv6, support for which is embedded in our current and future generation products, whether

based on VME, CompactPCI, PMC/ XMC or VPX. We address serial switched fabric applications with form-factors that were defined with input from mil custom-

lar, we have seen growth both in interest and commitment from customers toward open standards development. One of the key benefits that consolidation brings to

“Our customers are best served by the implementations that address their unique requirements.” ers. Serial switched fabrics don’t require an ATCA/MicroTCA solution. Our opportunities aren’t satisfied with telco commercial grade hardware. We have no current plans to, nor do we intend to go into the market for telco commercial grade hardware. Our customers are best served by the implementations that address their unique requirements. We’re able to offer customers the latest, most advanced technology on VPX, CompactPCI and VME. In fact, just this year we’ve introduced new designs based on P.A. Semi PWRfficient, Intel Core Duo and the latest Freescale Power Architecture processors, as well as Xilinx’s latest FPGA, the Virtex-5. RTC: To take a look at the “big picture,” do you think the time will eventually come when there are only a small handful of system makers and the traditional merchant board market will go away? What impact would this have on standards organizations? Quinly: We are currently in a cycle of consolidation, but we’ve witnessed many of these cycles over the last three decades. Consolidation is typically followed by the proliferation of startups. If VITA and PICMG are any indication, the membership rosters of the standards organizations are growing, which is a reflection of continued belief in the open standards industry. The fact that VITA and PICMG have continued to keep their membership fees attractive has certainly helped. They’ve also both stayed nimble enough to enable our industry to continue to develop standards and build ecosystems that truly benefit the embedded computing customer base. In the mil market in particu-

the market is that the larger players have the increased financial incentive and the ability to invest in the development of the new standards that the market needs. RTC: Curtiss-Wright has a vision statement that includes “shaping the future.” What is one of the new technology areas that you’re going to invest in that reflects this vision? Quinly: Some of the exciting areas we’re investing in under our COTS Continuum common-user interface initiative include power management, security and system management. All of these are areas we think will deliver great dividends for embedded system design. We also continue to expand and improve our innovative Common Software Architecture effort, which drives interoperability across our current and future product lines, and greatly reduces the time and complexity involved in developing board support packages or performing technology insertions.

April 2007

Software&Development Tools Real-Time Java

Trade-offs in the Design of Hard Real-Time Java Technologies An early implementation of a hard real-time Java development environment is based on the standardization work that has been done within the Open Group and the JCP. It is expected that the technologies discussed will evolve to support full compliance with the safety-critical Java standard once that standard is published.

er exploration ther your goal speak directly cal page, the ht resource. technology, s and products

by Kelvin Nilsen Aonix

mpanies providing solutions now

ploration into products, technologies and companies. Whether your goal is to research the latest pplication Engineer, or jump to a company's technical page, the goal of Get Connected is to put you uringtype the past decade since commercial release of the rvice you require for whatever of technology, Java development platform, the use of Java for back-office anies and products you are searching for.

software systems has grown significantly. Within the last several years, software industry market analysts have seen Java overtake C and C++ as the language of preference for implementation of new functionality. In part, the popularity of Java is driven by its support for high-level programming abstractions, ease of porting between platforms, and the diversity of powerful off-the-shelf libraries. Widespread adoption of Java by universities as the preferred language for core curriculum offerings has also contributed to market migration toward increased use of the language. In recent years, Java has also begun to infiltrate the embedded Get marketplace. Early Java successes in the embedded Connected space have two primary market niches: mobile telewithfocused companieson mentioned in this article. www.rtcmagazine.com/getconnected phones and soft real-time infrastructure. In mobile telephones, micro-edition Java enables small location-based services such as restaurant lookup, gasoline price searches, games and mass

End of Article

Get Connected with companies mentioned in this article. www.rtcmagazine.com/getconnected

2007

transportation maps and schedules. Soft real-time infrastructure software includes telecommunication servers, supervisory control of industrial automation processes, and mission planning in unmanned aircraft. Until now, adoption of Java for traditional deeply embedded systems has been hindered by certain tradeoffs that are inherent in the design of mainstream Java. A market survey conducted by Embedded Market Forecasters in 2005 identified specific hurdles that have impeded adoption by these traditional real-time developers. Among the top obstacles identified by this survey were: 1) speed, 2) footprint, 3) inability to access lowlevel devices, 4) inability to satisfy hard real-time constraints, and 5) lack of support for safety certification. For the last several years, the Open Groupâ&#x20AC;&#x2122;s Embedded and Real-Time Forum has been working with various industry partners to establish guidelines for development of safety-critical software using the Java language. In 2006, the Open Group sponsored creation of a Java Community Process (JCP) expert group to formalize creation of a JCP standard around safetycritical Java. This activity was assigned Java Specification Request (JSR) number 302.

Software&Development Tools

The Hard Real-Time Java Development Environment

Figure 1 provides a schematic diagram of the hard realtime Java development environment. Software engineers use standard Java 5.0 syntax to develop their safety-critical Java software components, placing annotations into the source code using the Java 5.0 meta-data annotation system. The standard Eclipse Java source code compiler translates the source code to traditional Java class files. The Eclipse development environment automatically invokes the PERC Pico verifier to enforce that the Java program uses only capabilities that are appropriate for the hard real-time Java subset and that there is consistency between every annotated interface definition, the method implementation, and all invocations of the method. If the Pico verifier encounters verification errors, these are reported immediately within the Eclipse development environment so that the programmer can address the problem within the source code. Note that the byte-code

PERC Pico debugger

Eclipse

C tools compile/link Eclipse ANT

PERC Pico translator

PERC Pico builder

PERC Pico verifier Eclipse Javac

Vanilla Java Source Files with Real-Time Annotations

Figure 1

Java .class Files

Hard real-time Java development environment.

verification is performed one class at a time, without requiring the entire program to be completed or assembled. This development environment automates the translation of high-level Java source code to very efficient optimized C code. In earlier experiments, we have found that this automatically generated code generally offers throughput and memory footprint very similar to hand-written C code. Often, the automatically generated code is more efficient than hand-written C code, because the automatic translation system uses stack allocation instead of emitting malloc() and free() invocations.

A Representative Experimental Workload

Many modern software systems are comprised of multiple layers of complexity. At the highest layers, there may be no real-time constraints, but considerable complexity. At the lowest layers of the hierarchy, it is common to see severe memory footprint, throughput and hard real-time constraints. Examples of low-level software include signal processing for radar, sonar and software defined radios, interrupt handlers for device drivers, and performancecritical computations for image rendering and cryptography. In between the extremes, there are varying degrees of software complexity, size, determinism and efficiency Executable PERC constraints. Pico Program For purposes of this demonstration, we have selected a simple Mandelbrot image rendering application. This uses perforNative Runtime Object Files mance-critical complex arithmetic to render a fractal image. Higher-level software draws the rendered image to a graphical Portable window. C Source files Java source code for the Mandelbrot algorithm is provided in Figure 2. Note that the a and bi arguments to mandelbrotAugmented Test represent the real and imaginary .class Files parts of a complex number. For the purpose of comparing the tradeoffs associated with design of hard real-time Java technologies, we have compiled and measured three versions of this application. One version runs with the Sun Java HotSpot virtual machine, version 1.5.

Average (ms)

Minimum (ms)

Maximum (ms)

Java HotSpot

149

140

190

Hard Real-Time Java

130

Optimized C

130

Table 1

Comparative Performance of MandelbrotTest. 2007

Software&DevelopmentTools One version runs with a prototype implementation of the hard real-time Java technology. And the third version is implemented as C code, compiled with the GNU gcc 3.4.2 compiler, using optimization level â&#x20AC;&#x201C;O2. All three versions of the benchmark are essentially the same.

Performance Comparisons

In each measurement, we invoke the mandelbrotTest 1,048,576 times to render the image for a 1024 x 1024 pixel image. The Java version includes annotations that are designed to facilitate the static analysis proofs of important program properties that are required in hard real-time and safety-critical applications to enable reliable and efficient deployment. The HotSpot execution of the Java source ignores the hard real-time annotations. The comparative performance of the three program versions is summarized in Table 1.

timized C implementations would both run deterministically closer to their minimum measured execution times if they ran without interference from other tasks on a true hard real-time operating system. For the Java HotSpot version of the benchmark, the variation in execution times also results mainly from interference from the operating system, because this particular application does not create garbage memory. However, the run-time environment embedded within the Java HotSpot virtual machine is quite complex, and there is no basis for arguing that execution times of traditional Java code would be deterministic. In a traditional virtual machine implementation, predicting execution times is very difficult because of interference from dynamic class loading, dynamic compilation, garbage collection activities, priority inversion and various undocumented heuristic optimization techniques.

public static int mandelbrotTest(double a, double bi, int limit) { double atmp, btmp; int number = 1; double z = a, zi = bi; while ( (number < limit) && ((z * z + zi * zi) < 4)) { number++; atmp = (z * z) - (zi * zi); btmp = (z * zi) + (zi * z);

}

Figure 2

z = atmp + a; zi = btmp + bi;

if (number == limit) { return -1; } else { return number; }

mandelbrotTest method.

The measurements were taken on a quiescent Windows XP computer. Because Windows is not a real-time operating system, any outlier measurements were discarded, under the assumption that the measurement was impacted by interference from other tasks running on the same computer. The algorithm itself and the machine code implementations of the hard real-time Java and optimized C versions are fully deterministic. The variation in timings for these measurements are due to interference from device drivers and caching effects that result when a running task is temporarily preempted by other activities. We expect that the hard real-time Java and op56

April 2007

There are a number of reasons why the hard real-time Java technology offers higher performance than the traditional Java HotSpot implementation. The hard real-time Java approach provides some key performance benefits. First, since the hard real-time Java system does not include support for automatic garbage collection, the code generated for accessing the data contained within Java objects and arrays is much simpler. There is no need to coordinate with an asynchronously executing garbage collection thread. In safety-critical hard real-time applications, software developers are expected to prove that software runs reliably,

“The QNX Neutrino microkernel OS has the perfect DNA for multi-core processors” Dan Dodge. QNX CEO & CTO. Pioneer in distributed and multiprocessor computing.

Introducing the QNX® Momentics® development suite Multi-Core Edition, the industry’s most comprehensive software platform for multi-core systems. Powered by the massively scalable QNX Neutrino® RTOS, this fully integrated solution supports AMP, SMP, and BMP, a groundbreaking technology that simplifies code migration and future-proofs

QNX Unlocks the Power of Multi-Core

your designs for quad-core and beyond. It’s the latest innovation from QNX Software Systems, the undisputed leader in multiprocessing technology.

Maximize performance. Eliminate complexity. Accelerate migration. Only QNX offers: �

Maximum Choice for Multi-Core Only QNX gives you the power to choose the best multiprocessing model for your multi-core design: SMP

BMP

AMP

�

Seamless resource sharing Scalable beyond dual-core

Limited

�

Mixed OS environment

Asymmetric Multiprocessing (AMP) for full developer control and fault tolerance Symmetric Multiprocessing (SMP) for maximum concurrency and scalability Bound Multiprocessing (BMP) for the fastest code migration and minimum design complexity Transparent Inter-Processor Communication (TIPC) protocol for seamless Linux connectivity

Dedicated processor by function Inter-core messaging

Fast (OS primitives)

Slower (application)

�

System tracing tools for fast debugging and optimization of multi-core applications

Thread synchronization between cores Dynamic load balancing System-wide debug & optimization

Discover how Dan and the QNX team deliver the shortest migration path to multi-core. Call 1 800 676 0566 or visit www.qnx.com/innovate. QNX, Momentics, and Neutrino are trademarks or registered trademarks of QNX Software Systems GmbH & Co. KG and are used under license by QNX Software Systems International Corporation. All other trademarks belong to their respective owners. 301786 MC339.05

�

Off-the-shelf BSPs for multi-core platforms based on MIPS®, PowerPC®, and x86 architectures

Software&DevelopmentTools

Mini-ITX systems & solutions for embedded applications, industrial & mobile computing. Mini-ITX Mainboards with VIA, Intel, or AMD processors. x86 platform small form factor design Linux and Windows XP compatible fully customizable systems

Fanless Mini-ITX Systems Utilizing heat pipe technology, these completely fanless Mini-ITX systems offer durability, reliability, and power-efficiency for a wide range of embedded applications in harsh, remote environments.

LOGICSUPPLY.COM info@logicsupply.com 802 244 8302 LogicSupply_3.5x4.75.indd 1

4/16/2007 3:10:17 PM

portabledesign conference & exhibition

santa clara c o n v e n t i o n

c e n t e r

october 3rd - 4th 2007

Join the industry leaders in the premier portable and mobile design conference Keynotes, Conference Sessions and Panel Discussions on: Low-power design--tools and techniques Wireless communications--3G LTE, WiMAX, Zigbee, NFC, 802.11n, Bluetooth Consumer electronics--design challenges and innovative solutions

registration

opens june 1st 2007

portabledesign.com