This requirement document is generated based on the original open, modular architecture controller (OMAC) requirement document that was created by Clark Bailo of GM Powertrain, Gary Alderson of GM Hughes Information Technology Company, and Jerry Yen of GM North American Operations Manufacturing Center.
The draft copies of this document have been reviewed by personnel from the following organizations:
General Motors Corporation
GM Hughes Information Technology Company
GM Powertrain Group
North American Operations - Manufacturing Center
North American Operations - Research and Development Center
North American Operations Midsize Car Division
North American Truck Platforms
Packard Electric
Saginaw Division
Ford Motor Company
Alpha Manufacturing Development Center
Ford Research Laboratory
Office of the General Counsel
Powertrain Operations Engine Engineering
Powertrain Operations Engineering Test and Development Center
Transmission and Chassis Operations, Plant Engineering
Chrysler Corporation
Power Train Operations - Control Systems and Tool Technology
Power Train Operations - New Manufacturing Technologies
The main purpose of this document is to make the requirements for an open, modular architecture controller known to the supplier and technology development communities. The expectation is that through awareness and a better understanding of customer needs, such products will become widely available in the marketplace.
Currently, most CNC, motion and discrete control applications within the automotive industry incorporate proprietary control technologies. There are difficulties associated with using proprietary technologies such as vendor-dictated pricing structures, non-common interfaces, higher integration costs and the requirement of specific training for troubleshooting and operation,.
Controller elements, a modularity concept, and higher level requirements for various elements of an open modular architecture controller are stated to convey the definitions of open, architecture controller in the context of automotive applications. Satisfying these requirements will enable an open, modular controller to be economical, maintainable, open, modular and scaleable thus meet the manufacturing needs in the automotive industry. Expected benefits of having open, modular architecture controllers include reduced initial investments, low life cycle costs, maximized machine uptime, minimized machine downtime, easy maintenance of machines and controllers, easy integration of commercial and user proprietary technologies, plug and play of various hardware and software components, efficient reconfiguration of controllers to support new processes, and incorporation of new technologies.
The main purpose of this document is to make the requirements for an open, modular architecture controller known to the supplier and technology development communities. The expectation is that through awareness and a better understanding of customer needs, such products will become available in the marketplace.
This document describes high level requirements for various elements of an open, modular architecture controller (OMAC). Satisfying these requirements will enable vendors to better address manufacturing needs in the automotive industry.
Currently, most CNC, motion, and discrete control applications within the automotive industry incorporate proprietary control technologies. Even though these proprietary technologies have been proven to be reliable and capable of meeting application needs, there are difficulties associated with using them, Examples of these difficulties include vendor-dictated pricing structures, no-common interfaces, higher integration costs, higher costs of extension and enhancement, and the requirement of specific training for operation troubleshooting.
A controller with an open, modular architecture will provide benefits such as reduced initial system cost, simplified integration tasks, easier incorporation of diagnostic functions for the controller, machine and process, and better integration of user proprietary knowledge. The concept of open, modular control also facilitates the math-based manufacturing strategy being implemented in the automotive industry. Math based manufacturing requires easily reconfigurable machining operations and the integration of low cost, high speed communications in machining lines for transferring large amounts of data. Flexible, modular controllers are key enablers for making math-based manufacturing easier to implement and cost justifiable.
The wide range of manufacturing applications in the auto industry impose different capability and functionality demands on equipment controllers. These applications are generally categorized into two major classes:
Computer Numerical Control (CNC) type applications requiring coordinated-axis motions and the control of a small number of discrete I/O points such as machining operations, and
programmable logic control (PLC), discrete event-oriented type applications requiring mostly sequential logic solving, with some non coordinated motions such as transfer line operations.
Within each, the operation requirements can vary greatly. For example, machining applications include all component manufacturing that is general high speed and high volume, and die machining that is low volume but requires long and continuous machining operations. Traditionally, operations in vehicle body assembly, paint chassis, and general assemble are generally discrete event-oriented. More complex operations such as robot control, welding, process monitoring, etc. are controlled by separate, dedicated controllers. PLCs are used mainly for overall coordination of these controllers and transfer of vehicles from station-to-station. However, the complexity of systems in an assembly plant ranges from simple single-station operations to multi-station applications that are linked with local area networks. With the availability of open, modular controllers, the distinction between CNC and discrete applications will become blurred. The modularity and salability of the controller architecture enable easy integration of particular functions for specific applications, hence reduce the need to have controllers with dedicated functions.
Because of the need to support a wide range of applications and the continual pressure to be more cost competitive, automotive companies are migrating toward controllers that provide agility and flexibility. In the future, it will no longer be acceptable to take the approach of replacing existing controllers with newer and better models when a few new functions need to be added.
Needs of automotive manufacturing applications be examined in the following categories:
Safety and Liability
It is absolutely mandatory for an open, modular architecture controller to meet all safety, reliability, robustness, and environmental requirements currently in place in a manufacturing environment. It should also satisfy all government and company specific electrical, mechanical, and safety standards in the manufacturing environment.
Being an open system, a machine and its controller are potentially more vulnerable to safety violations. However, it is the responsibility of both the controller vendors and machine builders to implement appropriate precautionary procedures to minimize potentially dangerous situations for the products they provide. If a third party is used to perform system integration tasks, verification of the safety-worthiness of the overall system should be the responsibility of the integrator.
Cost
It is critical that the life cycle cost- to-benefit ratio associated with controls is minimized. Some factors affecting life cycle economics are:
costs of wiring, interconnections, and making changes in physical equipment configuration;
costs of machine down time due to controller failures;
costs of training personnel in operation, maintenance, programming, making changes and upgrades;
costs of opportunities lost by not performing upgrades because it is difficult to enhance the functionality of the proprietary equipment without replacing them;
costs associated with not having the ability to reuse and easily integrate available and proven hardware and software components, tools, and aids.
These factors must be considered when decisions are made to select controllers for particular applications.
Even though life cycle cost is emphasized, the initial implementation cost of an open, modular control system is still an important factor. It is desirable to have the initial cost lower than that of a proprietary control system for equivalent functionality. One of the purposes of specifying open architecture controllers is to have the ability to integrate and leverage multi-vendor control solutions. With wider choices of products, lower cost to performance ratio can be achieved for required functions. Control systems should leverage the rapid technology advancements in the general purpose computing industry in order to improve the overall cost to performance ratio.
Flexibility
Because of rapid changes in market demands, manufacturing systems in the automotive industry need to have the flexibility to adjust the product and volume mix. Such adjustments include model changeovers, as well as changes to productions schedules due to unexpected interruptions of production and sudden shifts of customer demands. Controllers of these systems must support changes with minimal change over delay, yet maintain performance requirements. The controllers should also allow users to easily add to or upgrade controller functionality without relying on technology vendors and controller suppliers.
Connectivity
Most machines on the factory floor are generally required to be connected to the manufacturing information system in the plat. Controllers of these machines should allow easy integration of appropriate hardware and software tools to support such connection with minimal cost and effort. It is preferable that off-the-shelf third party components are available to be integrated in the controller for this purpose so that the use of higher cost proprietary technology can be avoided.
Factory floor systems generally have I/O systems, controllers should have integrated diagnostic capability and help functions for both the controllers and the machines being controlled to assist in preventive maintenance and troubleshooting activities. Since different diagnostic functions may be needed for different machines and/or applications, controllers should have tools available for users to develop customized diagnostic functions easily.
Maintenance
In order to minimize the downtime of manufacturing systems, controllers should have integrated diagnostic capability and help functions for both the controllers and the machines being controlled to assist in preventive maintenance and troubleshooting activities. Since different diagnostic functions may be needed for different machines and/or applications, controllers should have tools available for users to develop customized diagnostic functions easily.
Training
Retraining the workforce to work with an open, modular architecture controller could be a significant cost issue. The controller architecture should be designed to provide an intuitive, user-friendly environment so that the cost of training can be minimized.
It is our belief that, in order to satisfy the application needs stated here, it is necessary to purchase controllers that economical, maintainable, open, modular, and scaleable for automotive manufacturing applications. Particular definitions of these terms are:
economical:
achieving low life cycle cost;
maintainable:
supporting robust plant floor operation (maximum uptime), expeditious repair (minimal downtime), and easy maintenance (extensive support from controller suppliers, small spare part inventory, integrated self-diagnostic and help functions, etc.)
open:
allowing the integration of off-the-shelf hardware and software components into a controller infrastructure that supports a de facto standard environment;
modular:
permitting "plug and play" of a limited number of components for selected controller functions;
scaleable:
enabling easy and efficient reconfiguration to meet specific application needs, from low to high end;
III. Controller Descriptions and Modularity Concepts
Functional descriptions of controller elements and the software modularity concept of an OMAC are presented in this section. The controller presented in this document is assumed to have a centralized controller architecture, i.e. controller components are located in a controller enclosure. However, there is no reason why the modularity concept cannot be applied to control systems with components at separate locations connected through a high speed network. The objective of describing a model of the controller is NOT to dictate how an OMAC should be configured and integrated. The main objective is to help explain the view of what an open, modular architecture controller is from the perspective of automotive applications.
Both the openness and modularity of an OMAC are achieved mostly in software modules rather than hardware components. If an appropriate hardware platform is selected, the interchangeability of hardware components should not be a major obstacle. Figure 1 illustrates the concept of modularity as various pieces cooperating to perform the different controller functions.
Figure 1. Modularity Concept
Ideally, the salability of the controller can be achieved by adding, removing, or replacing modules to the controller architecture. For example, modules for motion, sensing and network interface can be removed from the controller architecture to meet the requirements of a low end discrete control application. However, all these modules can be integrated to control a complicated, sensor adaptive controlled machining operation.
The modularity concept also allows replacement of a module with another that meets the same interface requirements even if the replacement module may not have identical, detailed internal functions. Instead of replacing a module, the model also allows incremental functional improvements to each module be implemented either by end users or third party integrator.
Core Modules
The real-time kernel, database, and the graphical user interface environment form the core of an OMAC, and many of the issues in these areas need to be resolved before an OMAC can be successfully implemented. The graphical user interface environment is a critical element of the controller because an OMAC must maintain a common user interface environment across all applications in order for the salability to be achieved. An open, modular controller architecture should have the flexibility to allow a controller designer to select the most appropriate operating system kernel for a particular application. In other words, a controller designed to satisfy applications with real-time requirements in the range of seconds may require an operating system kernel that is different from the one implemented in a controller that is used primarily in applications with less than 10 millisecond real-time requirements. However, both controllers must have the same interface environment to the users.
Application Programming Interface Modules
This is an important layer of the controller architecture that allows a plug and play concept to be accomplished. With well defined and commonly accepted application programming interfaces (API) modules from various vendors can be integrated into the controller infrastructure without extensive reprogramming of the controller. While effort will be required to integrate device specific software (e.g. device drivers), the overall task should be well defined and straight forward. The API layer is the one that will require the most developmental work, and agreements among component suppliers for needed interface standard.
The modules presented in Figure 1 give an illustration of how modules can be linked together and how they can interact with each other through services provided by the operating environment. These modules can also be grouped into eight controller elements, as illustrated in Figure 2, so that the functions and requirements for each element can be more clearly presented. These elements are organized according to functionality, and descriptions for each functional element of the controller are given below.
Figure 2. Elements of an Open, Modular Architecture Controller
Infrastructure
The controller infrastructure consists of the hardware platform, operating systems, and the underlying system level software that interacts with all other elements by sending and receiving information such as commands, status, and data. The GUI/Windows Environment and the Real Time Kernel modules in Figure 1 are included in the infrastructure element.
Information Base
The Information Base element, illustrated as the Real Time Data Base module in Figure 1. is responsible for storing, updating, and sharing system information and data that are needed for the machine or process to operate properly. This module may also supply data to a higher level manufacturing information system.
Task Coordination
The Human Interface element provides a user with the ability to interact with not only the controller but also the machine or process operations. It is used to input system parameters, program machine and process operations, operate the machine or process being controlled, monitor machine and process performance, display controller and process status, receive and display diagnostic information, etc. The Application User Screens, Screen Generation Package, User Interface API, User programming Environment, Application Programs, and Programming Environment API modules in Figure 1 are included in the Human Interface element.
Motion control
Path Planning, trajectory generation, and trajectory tracking (servo-loop) are the key functions of a Motion Control element. The RS-274D Translator, Part Program API, Servo Algorithm, Trajectory Generation, and Motion API modules illustrated in Figure 1 are included in this controller element. Encoder inputs and other I/O devices that are needed for servo-loop closure can be a part of this element since they are generally connected directly to the control element. However, this should not be considered as a requirement. If the controller architecture has the ability to handle this critical I/O information in a timely manner, the I/O information that is needed for servo-loop closure can conceivably be provided through the real-time database of the system.
Not all the motion control functions have to be executed by a dedicated motion control board in the controller. Some or all of them can be executed by the main CPU of the controller. However, the motion control application interface between the infrastructure system software and the motion control element should remain the same regardless of the motion control hardware configuration of the controller.
Discrete Event Control
The Discrete Event control element interacts with the environment external to the controller. It includes the I/O System Drive, Discrete I/O API, and portions of the User Programming Environment modules in Figure 1. The element should interact with the multiple PLC type I/O systems and have the flexibility to incorporate the interfaces to newer buses and I/O systems. It collects input information, executes the discrete logic, enables output devices, and also supplies I/O information to the real-time database for other controller elements to make proper decisions and take appropriate actions.
Sensing Interface
The sensing interface element includes the Sensor Driver and Sensing System API modules in Fig. 1. It provides a means to gather information form the environment outside of the controller, and then supplies the information to other elements in the controller for decisions and actions. The category of sensing interface includes more complex sensing devices and systems, such as vision systems and force monitoring systems, that generally acquire and process a large amount of data. Simple sensors such as proximity switches are generally categorized in the Discrete Event Control element.
As indicated earlier in the description of the Motion Control element, sensing inputs necessary for servo-loop closures can be categorized as a part of the controller, including the real-time database and the operating system kernel, is capable of providing timely services such that information being acquired through the Sensing System module can be provided to the Motion Control module for servo-loop closure, then it is appropriate to categorize these sensing systems in the Sensing System element instead of including them in the Motion Control element.
Network Connection
The Network Connection element ensures that information and data of the processes, machine and controller are transferred to the plant manufacturing information system when they are requested. It should also support program upload and download when necessary. It consists of Communication Driver and Network API module seen in figure 1.
This section contains the requirements for an open, modular architecture controller to meet the goals stated in this document.
Infrastructure
The controller architecture must incorporate commercially available hardware and software products and be built to industrial standard specifications.
The controller infrastructure must have the ability to perform all tasks in a deterministic fashion and satisfy specific timing requirements of an application.
Controller hardware bus structure must be a de facto standard in the marketplace. VMEbus or some other form of PC bus architecture such as ISA, EISA, or PCI is preferred.
The overall cost of the controller infrastructure must be minimized.
The controller infrastructure must provide the flexibility for integration of user proprietary technologies.
The controller infrastructure must provide appropriate, multi-level security access procedures for using and modifying system and application software programs.
Information Base Management
The information base of the controller must be kept simple.
The information base management scheme must support built-in operating and information integrity and ensure that data is valid for all tasks executed in the system. For example, I/O update must be completed before the data is used by other elements in the controller.
The information base management must support proper authorization and priority schemes.
The information base must meet the real-time requirements of the system.
The interface of the information base must be simple and allow data sharing and update from other controller components, e.g. the motion control component of the system.
Task coordination
The controller architecture must support both messaging and direct memory access capabilities for information exchange.
The programming tool for task coordination should have the common look-and-feel of the discrete I/O programming tool. The task coordination functions need to be programmed using IEC-1131-3 or a flow chart type programming language.
Human Interface
The controller architecture must support a commonly accepted graphical user interface environment that is easily configurable, e.g. Microsoft Windows.
The controller architecture must support the standard operator interface functions of NC as defined in EIA Standard RS-441.
The human interface function must include software tools that enable users to customize the interface screen easily for specific needs.
The environment represented by the human interface must have the ability to emulate existing CNC interfaces for machining operations.
The human interface must be flexible in its cost structure. In other words, run time version must be substantially less costly than the development version. Multiple copy discount and site license options must be available.
Run time and development versions of the human interface component must be separated. The executable module of the run time version must not be burdened with the full functionality that comes with the development system.
The human interface must have the ability to interface with other elements in the controller, using a "well accepted" messaging scheme, such as DDE in a Windows environment.
Motion Control
The controller must support standard part programming inputs, such as RS-274D, and other related standards, such as RS-267B Axis and Motion Nomenclature for NC Machines.
The motion control element of the controller requires an editing and display method that resides underneath the control systems graphical user interface environment and interfaces with the human interface element of the controller.
The controller architecture must support standard output to server drives, either digital or analog drives.
The controller architecture must have the flexibility of keeping the trajectory planning and servo control as an entity or separating them.
The controller architecture must support a wide spectrum of motion control modules, from a simple bus interface card to a full-function motion control module.
The controller architecture must have a common motion control interface that supports multiple vendor products.
The controller architecture must allow for easily integration of additional axes when required.
Discrete Event Control
The discrete I/O system of the controller requires an editing and display method that resides underneath the control systems graphical user interface and interfaces with the human interface element of the controller.
The IEC 1131-3 standard programming languages must be used to program discrete I/O logic.
The controller architecture must have the flexibility to allow for the integration of other programming methods that have the flexibility to allow for the integration or other programming methods that have demonstrated track records of being easy to understand, learn and use, such as flow charting and state logic programming.
The controller architecture must have the capability to interface with various I/O systems, including those commonly used I/O systems on the market, such as Allen Bradley Remote I/O and GE Genius I/O.
The controller architecture must provide a development environment that allows system integrators to easily develop or modify device drivers for specific I/O systems.
The controller architecture must provide the capability that allows users to modify I/O logic while the I/O logic is being executed, i.e., the on-line editing function.
The controller architecture must have the flexibility of integrating special functions such as traces or historical records of discrete I/O events.
Sensing Interface
Sensing interface must have the flexibility to support one or all four major categories of sensor information:
coupling tightly with servo control and providing information directly to the servo loop control;
providing discrete information only;
providing sender and part position information with tie samples for trajectory planning and compensation;
providing other information such as temperature, time, coolant flow, etc.
The sensing interface must be provide a scheme for sensor configuration, initialization, and calibration.
Sensor data needs to be in pre-defined format that can be processed by the controller.
It is clear that openness in controller architecture brings many advantages, but the openness also creates a set of new issues that need to be addressed. Acceptance of the new technologies and the willingness to have a different way of thinking by plant floor personnel are key success factors for open, modular controller to realize perceived benefits. Different business practices are required to address retraining of workforce, spare parts inventories, preventative maintenance procedures, repair procedures, etc. Using OMAC also requires users to be more involved in system integration and assume additional responsibilities for keeping systems operational. Users cannot rely on technology providers to take care of all the problems with systems anymore. These are concerns that prevent some people from using the OMAC in their manufacturing applications. However, these real and perceived problems with open, modular architecture controllers can certainly be overcome if proper long-term strategies are developed and acceptable migration paths are established. Efforts should be devoted to developing these strategies instead of resisting the implementations of the OMAC technologies.
In this document, the concept of an open, modular architecture controller is presented, and the functions of various elements and software modules of an OMAC are described. The high level requirements are stated so that controller vendors, university, and government technology organizations can develop products to meet the needs of the US automotive industry.
General Information
