What’s Driving the Industrial Marketplace?

When Sumiya Donna Imam took over as manager of industrial market development at Freescale Semiconductor, she told Control Engineering that her first task would be to determine the forces driving adoption of embedded systems by developers of industrial control systems. We invited her to present this exclusive report summarizing her research.

By Sumiya Donna Imam, Freescale Semiconductor October 1, 2007
Sidebars:
Synchronization

When Sumiya Donna Imam took over as manager of industrial market development at Freescale Semiconductor, she told Control Engineering that her first task would be to determine the forces driving adoption of embedded systems by developers of industrial control systems. We invited her to present this exclusive report summarizing her research.

Industrial control applications were once considered unique in their needs—requiring custom, proprietary, complicated redundant systems designed for robustness and reliability in harsh, corrosive and sometimes explosive environments. These industries are now embracing open, off-the shelf, readily available technologies that not only help simplify management and monitoring of their operations, but also address nuances of specific applications.

Today, machine builders expect every electronic device to have the inherent ability to network easily and securely, with enough flexibility to deliver immediate and efficient remote access, right down to the lowest node levels. This need for seamless interoperability forces several changes to industrial control applications, including:

  • Migration from 8-bit to 32-bit architectures,

  • Ethernet everywhere and

  • Commercial off-the shelf (COTS) hardware.

Skipping 16-bit

Even though peripheral set, low price and power requirements continue to keep 8-bit architectures shipping in high volume, there is an increasing trend towards 32-bit architectures to support future upgradeability, despite their higher initial cost. Depending on the application, software and systems designers must evaluate the cost of porting their applications to 16-bit architecture and possibly having to repeat the task later, when additional network functionality calls for 32-bit architecture.

High-performance, high-accuracy, high-speed analog and digital measurements; sampling; and signal conditioning requirements in applications such as motion control are just a few of the many reasons developers continue to migrate directly to 32-bit architectures, skipping 16-bit designs. Primarily, they see minimal price difference between low-end 32-bit processors and 16-bit processors, but they also consider that the advantages of migration outweigh the overall effort.

Where the need for low power combines with a large number of sensor points, a multiple 8-bit processor design may provide the required boost needed for processing power. This, however, works well only when processors need to exchange limited amounts of information.

Deterministic and high-frequency communication requirements, along with need for higher performance processing makes the 32-bit a more attractive option. The 32-bit processors’ ability to run protocol stacks efficiently is another compelling reason for the move. These stacks require a larger silicon footprint and the flexibility of field programmable gate arrays (FPGAs), which some 32-bit processors are able to handle in one device instead of two. A 32-bit architecture is also clearly better for systems that must execute complex control functions, drive human machine interfaces and run real-time operating systems for task management.

Connectivity over Ethernet seals the deal

Ethernet as a means of connectivity for communication and monitoring is no longer an exotic solution or an emerging trend for use in hybrid control systems comprising both digital and analog devices. Since its use became commonplace in the 1990s, Ethernet has been establishing itself as the predominant physical layer standard for industrial networks. As a world wide, easily accessible, high-bandwidth, open standard, Ethernet allows control equipment vendors to address the demand for software-centric and highly reconfigurable systems that can also be remotely accessed by the user.

With the need for advanced levels of processing at nodes where I/O devices (such as sensors, valves or solid-state relays) and slave devices reside comes the need for increased bandwidth of data transmission and direct connectivity to higher network levels based on existing Ethernet.

Most vendors will agree that customers in industries subject to hazardous environments—which include varying temperatures, electromagnetic and RF interference and vibration—need tailored, stand-alone solutions and overwhelmingly prefer Ethernet to other communication solutions.

The Ethernet cable alone does not allow communication; TCP and IP communication protocols assure the network connectivity that we enjoy in our homes and offices. However, these protocols do not address the special needs of industrial equipment users. To ensure tasks are completed and data is routed in a timely fashion, with recovery mechanisms built in for fail-safe behavior, “determinism” is a necessary element that industrial protocols provide.

In the past, many manufacturers relied on proprietary “homegrown” protocols to solve unique industrial problems. Consequently, today legacy protocols or fieldbuses such as PROFIBUS and CAN are still popular and growing because they are tested, proven and widely supported in the market by a range of products.

Availability of products based on legacy fieldbuses hasn’t stopped system integrators from recognizing the benefits of a high-speed machine network, nor the ability to leverage existing Ethernet hardware and software to define the application layer protocols for configuration, access and control of industrial devices. Inevitably, integrators are demanding control components compatible with the real-time Ethernet-based protocols such as Ethernet/IP, Ethernet Powerlink (EPL) and time-synchronization protocol (IEEE 1588). Networks interconnecting Ethernet-based systems with fieldbus systems are an interim response to this trend.

PROFIBUS, with greater than 15 million devices installed globally, is the world’s leading fieldbus. It was specifically designed to eliminate point-to-point cabling and help reduce network implantation cost and complexity for a wide spectrum of applications. These include factory automation, fail-safe devices, motor drives and motion control applications.

Fieldbuses are more sensitive to wiring and layout faults, and common transmission methods (such as RS-485) limit the maximum number devices on one PROFIBUS segment to 32. Fieldbuses such as PROFIBUS as are being challenged by Ethernet-based protocols such as EPL because they use all the traditional Ethernet hardware and software to configure, access and control industrial devices. Ethernet provides the avenue to leverage faster and higher-bandwidth communications.

EPL is a deterministic real-time protocol for standard Ethernet. It is a completely license-free protocol managed by the Ethernet Powerlink Standardization Group (EPSG).

Suitable for applications that must guarantee transfer of time-critical data within microseconds and time-synchronization of nodes with sub-microsecond precision, EPL is a SW only implementation and hence is compatible with all Ethernet hardware and Transmission Control Protocol (TCP)/IP protocol suite.

Current implementations have reached 100μs cycle time with a timing deviation (Jitter) below 1 μs, which meets the highest requirements for hard real time and determinism.

EPL’s seamless communication down to sensors and actuators is achieved by using IP-based protocols in real-time and non-real-time domains. The clear separation of real-time and non-real-time domains through a dedicated router ensures security in all aspects.

Although EPL still is emerging and not as widely adopted as PROFIBUS, one of EPL’s major advantages is that its application interface employs mechanisms defined in the CANopen profile, so it supports easy migration and integration from/with CANopen. This offers customers potential for more technology sources and more vendor-independent system design.

COTS hardware eases migration

Several design complexities appear when system engineers attempt to reap the advantage of 32-bit performance. Power consumption, pin compatibility, tools migration and additional programming complexity top the ghostly list. The amount of time it takes for a design team to transition from one architecture to another, learn new tools and design a new board can cost more than the value of getting to market first—or even on time.

This leads to the third major driver of change seen in the industrial market space—the move toward COTS hardware and communication stacks. Notably, one of the biggest COTS users is the aerospace and defense industry. This trend is now strong and growing among other vertical industrial markets. Growth of consortia such as the PCI Industrial Computer Manufacturers Group (PICMG), an association of more than 450 companies to collaboratively develop open specifications such COM Express for high-performance industrial applications, exemplify this trend.

The relatively inexpensive nature of COTS hardware, the need to reduce design-cycle time as users move from 8-bit to 32-bit architectures and the luxury of avoiding certification and standards compliance can contribute to this trend. Most important, it allows the designer to spend time on enhancements, increased features and functionality, and possibly on reducing end-product costs. Like COTS hardware, pre-configured, tested and ported software protocol stacks are also enjoying increasing demand among a wider customer base.

Customized and proprietary hardware and software solutions, once perceived by vendors as a market advantage, are no longer desired by users wanting flexibility and interoperability between devices. The cost of developing and sustaining unique hardware and software platforms outweighs the cost of leveraging and reusing COTS protocol stacks.

Early on, Freescale Semiconductor recognized these trends meant silicon alone could no longer attract system designers working on the complex next-generation networked industrial devices and systems. To meet engineers’ growing needs for high-performance, deterministic and real-time solutions, Freescale delivered a comprehensive production-ready development platform MPC8360E-RDK in partnership with leading vendors of hardware and software solutions. The platform helps address the top three trends driving the industrial marketplace. Pre-integrated, pre-tested and application-ready, the system is based on the MPC8360E communications in which processor contains the fully featured QUICC Engine of the PowerQUICC II Pro family running up to 500 MHz, along with an e300 core operating up to 667 MHz.

The QUICC Engine can support a wide range of networking protocols on one device. Its programmable microcode allows future revisions to protocols similar to FPGAs, while providing more flexibility than an application-specific integrated circuit approach. It also off loads the core processor from communication and protocol traffic optimizing processor performance.

Author Information
Sumiya Donna Imam is an industrial market development manager for Freescale Semiconductor in the networking systems division where she is responsible for determining strategies for the medical, test & instrumentation, single-board computing and metering markets. Contact her at donna.imam@freescale.com .

Synchronization

IEEE 1588-2002 is a precision clock synchronization protocol for networked measurement and control systems. It was developed to synchronize clocks of various inherent precision, resolution and stability levels to achieve systemwide synchronization accuracy in the sub-microsecond range. What sets the standard apart is its ability to synchronize time between nodes on a network—sensors, actuators and power-grid switches with minimal network and local clock computing resources. This allows simple systems to be installed and operated with minimal maintenance.