Open road ahead for manufacturing control

As a new standard for industrial control is proposed, Chris Edwards considers how and where it might be implemented, and whether it could indeed provide the panacea for automation.

Those with long memories will remember the last attempt by GM (General Motors) to define a standard for industrial automation: the ill-fated MAP (Manufacturing Automation Protocol). An expansive form of fieldbus, MAP was, as it turned out, way ahead of its time. You only have to look at the slow progress fieldbuses have made in the last 10 years to see how even the cheaper implementations have struggled to gain acceptance in manufacturing. But the revolution is taking place. In place of the token-bus protocol chosen for MAP, Ethernet and RS485-based networks have taken hold.

This time around, GM has kept away from the network and focused on the software. The OMAC (Open Manufacturing Architecture Controller) proposed by Chrysler, Ford and GM is a much more pragmatic approach to opening up the world of manufacturing automation.

Reflecting the growing complexity of manufacturing automation, OMAC is focused on the problem of maths-intensive control, which is not the PLC’s traditional strength. Systems need to be reconfigurable so that algorithms can be changed easily. The traditional distinction between CNC and PLC-based control is also blurring.

In an automative plant, the demands on CNC and PLC can vary widely. For example, component manufacturing using CNC machines is generally high speed and high volume. Die machining is low volume but needs long, continuous machining operations. Vehicle body assembly, chassis painting and general assembly are typically implemented using PLC-based discrete-event control.

These systems are now being tied together using networks or fieldbuses, making it possible to integrate processes. Ideally, CNC and PLC functions will be supported on the same platform in varying proportions. The hardware that makes this possible is a modular controller.

Instead of trying to bring a whole new set of programming interfaces and protocols to an industry that is never keen on changing, OMAC makes use of existing standards.

At the user interface level, this means Microsoft Windows running software that can provide a user interface that follows the basic guidelines contained in the EIE-441 standard. For reliability reasons, much of the attention has fallen on Windows NT, and a number of equipment suppliers have already standardised on this operating system in favour of Unix.

Split into a number of interworking modules, OMAC-compliant systems may employ motion control and discrete-event control as well as sensor interfaces, all based on a design that makes use of common hardware buses such as ISA, PCI or VMEbus.

The motion and discrete event control parts of an OMAC controller also make use of existing standards. A motion controller has to be able to understand EIA-274D profiles. However, the most important standard in OMAC is arguably the one used for discrete-event control, and for coordinating tasks in the controller. For those jobs, IEC1131-3 is needed if the controller is to be considered ready for OMAC.

In contrast to previous efforts at standardisation in industrial control, OMAC does not demand the use of a particular network or fieldbus to link controllers together. In fact, GM’s Powertrain Group has implemented two completely different schemes in the USA and Europe for its latest projects. As there is currently no clear winner in the marketplace, GM has selected Interbus-S for its next major programmes in North American plants. Although not a vendor-independent standard, Interbus-S was picked because there are a large number of components that support it. Also, Interbus-S allows both messaging and I/O transfers across the same network, so that motion profiles can be downloaded to tools dynamically.

For similar reasons, GM Europe’s Assembly and Powertrain operations selected Profibus-DP as their standard device-level network.

Similarly, Europe does not have to adopt the US-oriented OMAC. A number of European projects have been assembled under the banner of the OSACA (Open System Architecture for Controls within Automation Systems). However, it is considerably more abstract than its American cousin although there are vague plans to align the two once they are complete. The defined interfaces in OSACA are at a lower level than those in its US cousin, so they do not prevent OMAC-compliant tools from generating software that fits the OSACA model. Given that a number of traditional PLC suppliers in Europe have adopted IEC1131-3 as well as entrants backing modular designs, there are major portions of OMAC that can easily be adopted, with or without the work from OSACA. Also, since the PC forms the backbone for much of the hardware, OMAC has received enthusiastic backing from industrial PC and software suppliers such as Imagination Systems, Intellution, Microsoft, Nematron, RadiSys, Venturcom and Wonderware.


After years of neglect, Microsoft has woken up the manufacturing market with ambitious plans to have Windows NT running on just about everything on the factory floor.

One potential problem that faces any machine builder aiming to build an OMAC-compliant system is whether Windows is cut out for the job. OMAC does not demand that Windows be used throughout. Many implementations are likely to separate the real-time control portion of a controller from its Windows-based user interface, running them on separate processors. However, a number of the vendors putting together OMAC software are trying to use Windows NT as a real-time system. Nematron’s OpenControl software uses technology from Imagination Systems to do just that.

The discussions as to whether Windows can really handle real-time applications has taken on almost theological proportions. Often the demands of the application will determine whether a Windows-based system can handle all of the real-time tasks, or not.

It seems likely that new entrants, offering systems based entirely on PC hardware will tend to favour a Windows-only approach. A closely coupled link between a real-time processor and a Windows engine, perhaps across a VMEbus or CompactPCI backplane, offers the existing PLC and CNC vendors a way of offering OMAC compliant hardware without completely redesigning their systems.

Although there are perhaps not that many companies in Europe that will adopt OMAC in its entirety, the fat that it has three automotive manufacturers and Boeing behind it will at least grab the attention of PLC and CNC suppliers. A lot more systems will adopt Windows and IEC1131-3, even if they are not going into an OMAC-based plant.


Split into a number of interworking modules, OMAC-compliant systems may employ motion control and discrete-event control as well as sensor interfaces, all based on a design that makes use of common hardware buses such as ISA, PCI or VMEbus.


EIA (Electronic Industry Association) US

EIA-274D standard describing motion profiles of machine tools

EIA-441 overview standard for user interface formats

IEC1131-1 International specification to standardise the programming languages of PLCs.


OMAC (AUTOMATION RESEARCH CORP). Tel: 001 781 461 9100 Ext. 112

NEMATRON. Tel: +31 346 574000

INTELLUTION. Tel: 01908 325209

WONDERWARE (PANTEK IN UK). Tel: 0161 4288506.

Contributing Editor Chris Edwards has more than 10 years experience as a journalist covering the electronics, computer and industrial automation industries.