Open, Modular Architecture Controls at GM Powertrain — Technical Issues

By C. Michael Taylor, et al. January 25, 1998

Operating Systems Hardware Platform Motion Control Open Device Level Networks User Interface Control Software Manufacturing Information System (MIS) Level Networks Application Programming Interfaces (API)

It should be clear to the controls community that GMPTG is not trying to dictate the development of OMAC by specifying technical details for every aspect of OMAC. GMPTG is not going to lead the development of any new technology but will ride the technology wave! However, GMPTG engineers are not oblivious to the technical issues associated with OMAC systems. In this section, several OMAC technical areas will be examined. GMPTG’s requirements, desires, issues, target selections, alternative selections, and current implementations for each technical area are discussed.

Operating Systems

The operating system for an OMAC must meet real-time control requirements of CNC and discrete logic applications and also support a Microsoft Windows environment. Because the Windows technology is not designed for real time control applications, control system developers and integrators have the alternatives of: (1) integrating co-process cards in the Windows environment to handle real time tasks, (2) integrating two separate processors, one with a commercial, real time operating system for executing real time tasks and the other with the Windows OS for executing non-real time tasks, and (3) integrating the real-time capability into the Microsoft Windows operating system.

The preferred solution is to have a commercial operating system that fully supports the Microsoft Windows environment with integrated real-time capability. It is desirable to eliminate the need of using two separate operating systems and writing special device drivers when new hardware is being integrated. Easy integration of off-the-shelf third party packages and the ability to use off-the-shelf development tools are key considerations. No such operating system is available commercially at this time, but the DOE-ICON project and other commercial development projects are addressing this need. Alternatives being developed are Windows 95 with an integrated real-time kernel and Windows NT with an integrated real-time kernel.

Various operating system configurations currently implemented or being evaluated at GM NAO and GMPTG are:

proprietary software running on the PC platform,

Windows 95 with motion and/or logic co-processor cards on the PC platform,

Windows NT, Windows 3.1, and Windows 95 based PC front ends with proprietary CNC controllers,

Windows 3.1 PC front end with off-the-shelf real-time operating system based CNC controller,

QNX.

Hardware Platform

The basic requirements of the OMAC hardware platform are high reliability, competitive cost, easy incremental upgrades, and easy integration of off-the-shelf components. It is desirable to use generic PC hardware and components without requiring specialized industrial versions. The reliability of generic PC mother boards is an issue to many people in the industry, however, the mean time between failure (MTBF) for selected commercial PC boards, such as mother boards manufactured by Intel, is in the 90,000 hour range which is better than many industrial controllers. The target OMAC hardware platform is a personal computer with both an ISA and PCI bus.

Further investigation still needs to be conducted to determine the trade-off between implementing PC mother boards and passive backplanes. The passive backplane approach offers more flexibility and modularity of components, however, the mother board approach is lower cost. Investigation of an industrialized PCI bus, such as Compact PCI, is still being conducted. Compact PCI specifications enable multiple masters to be integrated in a single backplane and specify more reliable mechanical components. It is suitable for the high-end applications, but the potential added costs make it less attractive for low end applications.

Current FloPror implementations incorporate industrial ISA Bus PC’s. There are only a few applications using generic ISA Bus PC’s. Other hardware platforms currently being used at GMPTG include VMEbus based PC’s and proprietary controllers with PC front ends.

Motion Control

The motion control technologies being deployed at GMPTG need to support a wide range of applications from simple single axis motion to high speed, high accuracy machining applications. Another requirement of a motion control system is to support the existing motion and CNC part programming languages. In order to fully support the math-based manufacturing strategy, GMPTG is also working with control and CAD/CAM system suppliers to develop the common interface between a CAM system and an OMAC-based CNC controller. The objective is to program the CNC directly from the CAM system using surface information of the math model of a part to be machined.

GMPTG is a strong proponent of using non-proprietary interfaces between a motion controller and drives. The specification of SERCOS as the standard controller-drive interface for the up-coming GMPTG programs created concerns from many control vendors and machine tool manufacturers. The common complaint is that the performance of SERCOS is not sufficient for many machining applications. It must be re-emphasized that 95% of the GMPTG applications are considered to be ‘low end’ applications with most of them requiring only three-axis coordinated motion during machining. The current SERCOS implementations using 2 millisecond position loop time for 8-axis coordinated motion is more than capable of handling the majority of GMPTG applications. With the 4 Megabit SERCOS implementations in the near future, the performance issue should not be a concern. It must also be clarified that SERCOS is the only available digital drive interface standard at the present time, and the selection of a standard digital drive interface will be re-evaluated when the decision has to be made for the next GMPTG major program. GMPTG will select the most appropriate standard interface at that time.

Figure 8. Motion Control Diagram

Figure 8 illustrates a functional diagram of a servo system with all its interfaces. SERCOS specifications allow three level of interfaces: position, velocity, and torque. The majority of GMPTG implementations will utilize the position level interface which means intelligent drives will be incorporated to perform all loop closure functions.

The higher cost of implementing SERCOS is another issue being discussed to counter the selection of SERCOS as the standard digital drive interface at GMPTG. This argument is not valid since the cost of the 2 MB SERCOS ASIC has been lowered to the $5.00 range and the added cost for each SERCOS node is less than $100.

Implementation of SERCOS technology also raises the issue of the conformance testing of SERCOS compatible products. User defined parameters need to be coordinated to achieve ‘plug and play’ of products from different vendors.

CNC system configurations that have been implemented or are under evaluation at GMPTG include:

proprietary CNC controller with an analog interface to drives and motors;

proprietary CNC controller with proprietary digital interface to drives and motors;

proprietary controller with SERCOS interface;

PC-based controller with PC motion control card and analog interface to drives and motors;

software based PC controller with SERCOS interface.

Other alternatives that are being investigated include the use of the Multi-Axis Control Ring Optical (MACRO) digital drive interface and motion control on a Controller Area Network (CAN) based or other de facto standard networks.

Open Device Level Networks

Choice of ‘open’ device level networks has been a hot topic in the controls community recently since there are many different ‘open’ device level networks in the marketplace with no clear winner that will become the ‘de facto’ standard at the present time. The main objectives of implementing device level networks at GMPTG are to: (1) reduce wiring costs of field devices; (2) create opportunities to select proven or validated devices from various vendors; (3) specify generic devices rather than vendor specific devices; (4) realize the benefits of the increasing diagnostics capability and added intelligence of the devices; and (5) provide interchangeability of drive products using same motion programs over an open device network.

Since there is currently no clear winner in the marketplace, GMPTG selected Interbus S technology for the next major programs in the GMPTG North American plants. The selection was based on the availability of the types of components and application support that meets the program requirements. Additionally, Interbus S allows both messaging and I/O on the same network so that motion profiles may be uploaded or downloaded over the network. Similar rationale prompted GM Europe Assembly and Powertrain operations to select Profibus DP as their standard device level network. It needs to be emphasized again that the selection of the device network will be re-evaluated in the future when the control architecture of the next major program is being designed.

Issues related to the selection of device networks include market acceptance, availability of components and support, conformance testing of devices, costs of implementation, and distributed control capability for future implementations. All these factors need to be considered before a selection is made. Currently, proprietary I/O systems are implemented in many GMPTG facilities. Examples of these I/O networks include GE Fanuc Genius I/O, Group Schneider MODBUS, and Allen Bradley Remote I/O.

The emergence of a low-cost, high-speed serial link in the personal computer marketplace to connect peripheral devices, such as keyboard, mouse, monitor, etc., is worth following. Universal Serial Bus and Fire Wire technologies are not designed to handle industrial I/O’s but development efforts to investigate the feasibility of adopting the technologies for controlling I/O’s for low end applications should be initiated. Implementing smart devices will also become more important in the future because control systems will be configured to be more distributed, with decisions being made locally with information from smart devices.

User Interface

As described earlier, GMPTG adopted the strategy to implement operator interfaces with a common look and feel for operator screens in a commonly accepted operating environment, e.g. Microsoft Windows. It is also desirable to have one operator interface station for all programmable devices in a work cell and a common operator interface console hardware. GMPTG has already developed and implemented common operator screens on PC-based flowchart control systems, and an effort has been initiated to develop screens with an identical look and feel for PC front end on CNC applications. This standard operator interface package will be implemented in GMPTG major programs that are already underway.

It is also important to note that the user interface on a machine will also be used as the programming terminal and will contain tools to help maintenance personnel service the equipment. The common Microsoft Windows operating environment enables easy integration of these requirements. Additionally, the user interface needs to incorporate different levels of security so that only proper levels of access will be granted.

Topics related to user interfaces that are being evaluated by GMPTG personnel include: reducing the cost of implementing a PC front end for each machine, determining the need of using a touch screen and/or pointing device in addition to function keys, and the packaging of PC front end consoles.

Current implementations of user interfaces include proprietary displays, Windows based interfaces without common screens, PC front end with proprietary CNC, and common screens based on Visual Basic.

Control Software

Flow chart and/or IEC 1131-3 compatible languages are specified by GMPTG personnel to program discrete logic controls applications and RS-274D for CNC applications. All programming packages to be used on the plant floor should be Windows based packages.

For discrete logic controls, it is also desirable to have the ability to program in one language and display the program in another. This ability allows the engineers to develop application programs using the language that they are most efficient in, and also enables the plant personnel to maintain the program using the language that they are familiar with. The Premium V6 and L850 programs are committed to use Nematron FloPror software for discrete programming. GMPTG is working with Nematron to modularize the software to better align the product with the OMAC concept. GMPTG personnel also continue to evaluate other discrete logic programming packages in different pilot projects and will select the most appropriate package for the next program. Examples of these packages are Steeplechase Visual Logic Controller, Arbor Coast ControlSuite, ASAP ASIC-100, and Wizdom Paradym-31. Issues related to discrete logic controls are centered around the real time capability of the operating system such as the real time performance under the MS Windows environment and seamless integration of the real-time operating system with the MS Windows as discussed in the operating system section earlier.

For CNC applications, the ability to support Non-Uniform Rational Bezier Splines (NURBS) based programming is critical to the implementation of the math-based manufacturing strategy in the near future. The use of a NURBS interface eliminates the issue of block processing time in a CNC. Use of a NURB spline to represent a curve to be machined can eliminate hundreds of blocks of data that currently are the bottleneck in high speed CNC machining. This type of machining is used primarily in the area of die repair at GMPTG. Programming a CNC manually at the machine on the plant floor is not a major issue since most of the programming is done either by the Original Equipment Manufacturer (OEM) or is completed using Unigraphics CAM systems. However, the need to centrally perform machine specific post-processing of part programs in a CAM room will be eliminated in the future. The post-processing function will become the responsibility of the CNC controller so that machine independent part programs can be sent to different machines based on the availability of the machines.

Manufacturing Information System (MIS) Level Networks

Because of the increasing need to link controllers together on the plant floor and to the plant wide manufacturing information system (MIS) network, it is important to achieve a low cost networking solution using off-the-shelf components and common protocol. It is also mandatory to support the existing GM plant network protocol and hardware. GMPTG is also investigating the feasibility of using the same MIS networking technology to support peer-to-peer controller communication when necessary. Since Ethernet technology with TCP/IP protocol is the de facto standard for MIS level communications, the standard will be the target implementation at GMPTG with the addition of Manufacturing Messaging Specification (MMS) protocol on top of the TCP/IP for controller applications. The PC-based control direction allows GMPTG to take advantage of many Ethernet and other communication protocol products that are available on the PC platform without having to ask control vendors to develop specialized hardware and software products for MIS level communication tasks.

There are MIS networks with the broadband technology using the full seven-layer Open System Interconnect (OSI) model and MMS protocol in existence. Some plants in GMPTG are converting to fiber based networks. Another alternative of MIS level networking is the use of Ethernet with OSI/MMS.

Application Programming Interfaces (API)

The key to achieve true plug and play capability in an open controller is the definition of modules that need to be included in an OMAC and the application programming interface for each module. In addition to the API development effort being sponsored by the DOE TEAM program, the European Community has an open architecture development project, OSACA, which also defined a set of controller modules and API’s. The Japanese International Robotics and Factory Automation (IROFA) group is also starting an effort to develop an open architecture control standard. It is the desire of GMPTG to have one set of open architecture module definition and API specifications. Initial information exchange activities have taken place among OSACA, OMAC, and IROFA projects, and further cooperation is needed to achieve one acceptable open architecture interface specification in the future, before the highest level of openness can be achieved.