Definition of OMAC Terms
Definitions of key terms associated with the open, modular control systems described in the OMAC White paper are restated in the following table:
allowing the integration of off-the-shelf hardware and software components into a 'de facto' standard environment
permitting 'plug and play' of components
enabling easy and efficient reconfiguration to meet specific application needs
achieving low life cycle cost
supporting robust plant floor operation (maximum uptime), expeditious repair (minimal downtime), and easy maintenance
These definitions also accurately reflect the OMAC concept at GMPTG. Two important elements in the definition of 'open' are (1) the requirement of a 'de facto' standard environment, and (2) the availability of commercial control hardware and software components. GMPTG is not going to wait for an international standard for an open architecture control to be defined before it will start implementing OMAC systems. The 'de facto' environment that the market is embracing will be the one that open systems will be built in. In today's marketplace, the Microsoft Windows environment is the 'de facto' standard, and is the one supported by many commercial control hardware and software products. Even though Microsoft Windows was not designed to support real time control applications, it certainly can be used effectively to support many aspects of control functions, and there are various approaches that can be implemented to develop a control system using this environment. Further discussions of this topic are explained in the chapter entitled, 'Technical Issues' in this document.
There are times when a module of a control system needs to be replaced to provide additional benefits, such as additional capability and/or lower cost, to the user of the control system. Modularity defines the ability for a user to replace a component or a module in a control system easily without having to devote a great amount of engineering effort to re-integrate the control system before it is functional. It is the desire of the end users to 'plug' in the new module and start to 'play' with minimal effort such as simply loading a new software driver. 'Plug and Play' in this sense means to integrate and validate in a controlled environment. After thorough and rigorous validation of a control system change, this change can be implemented on the plant floor. Discussion of GMPTG's validation procedure is presented later.
When changes occur in a manufacturing process, it is necessary to increase or decrease the functionality of the control systems associated with the equipment in the process. The scaleability of a control system allows control modules to be added or removed from the control system and provides appropriate control capability to match application needs.
One important aspect of implementing OMAC systems is to reduce the costs associated with a control system. However, as important as minimizing the initial purchase cost of a control system is, it is not as critical as minimizing the total cost over the life cycle of the control system. Initial implementation costs will decrease as a natural consequence of control products being driven by the larger market forces of the Personal Computer industry. When changes to a control system are required due to changes in products and/or processes, it becomes important to implement the changes as cost effectively as possible. Open, modular systems allow incremental upgrades and easy integration of components, thus reducing the cost of making changes to a control system. Implementing open, modular control systems is certainly a cost effective way if product and process changes are imminent and flexibility in manufacturing systems is required.
OMAC-based manufacturing systems have the same reliability requirements as the proprietary controller based systems. They have to be maintainable with maximum uptime and minimum downtime to satisfy the requirements in a plant environment.
Illustration of the OMAC Concept
A distinction of an OMAC-based system is the utilization of standard interfaces to achieve openness, modularity, and scaleability stated earlier. The standard interfaces are beyond using common commercial computer backplanes such as Industry Standard Architecture (ISA), VME (VERSA Module Eurocard), Peripheral Component Interconnect (PCI), etc. even though they are important building blocks for OMAC systems. Standard interfaces that are needed in an OMAC system include common application programming interfaces (API) for control software modules, device level networks, digital drive interface, and higher level network interfaces.
Figure 1 gives a simplified view of an OMAC-based system with the external interfaces that need to be standardized. It is a centralized configuration, i.e. the control functions (or modules) and associated API's are enclosed in one central box, thus software modules are contained within the controller box.
Figure 1. Open Modular Architecture Controller with Its Interfaces
The block diagram illustrated in Figure 2 demonstrates the concept of an open, modular architecture computer numerical controller (CNC) with its functional modules. This block diagram is not a technical architecture and should not be considered as the technically accurate way of implementing an OMAC-based CNC. It is used to further explain the notion of modularity and scaleability.
Figure 2. Open, Modular Architecture Controller Concept Block Diagram
The API of each module defines the method of communication with other modules within the controller. If all commercially available 'Discrete Logic Solving' modules conform to the same API, it is certainly feasible to replace the existing 'Discrete Logic Solving' module in a functional control system with another one, and the total system should again be functional after certain simple integration and validation procedures are completed. The common API enables not only the 'plug and play' requirement but also the scaleability of the OMAC concept. Modules can be added or removed from the systems depending on the desired applications. For example, the 'Part Program Translator,' 'Trajectory Generation,' and 'Control Loop' modules can be removed from the system, and the controller becomes a programmable logic controller (PLC) instead of a CNC. For a complicated application, additional custom modules can be added to the system to perform the additional functions. Adding a 'Vision Processing' module is a good example of scaling up the capability of a control system with minimum integration effort. Similarly, the OMAC system enables the replacement of device level networks and communication networks with minimum impact on the rest of the system.
Various Levels of Openness
Based on the definition of 'open' given in the previous section, it is important to note that there are several levels of 'openness' that one can achieve in implementing a control system. The progression of openness of a control system is shown in Figure 3.
Figure 3. The Progression of Open Systems
The first level of openness beyond the proprietary control is labeled the 'Open Environment Controller.' The 'open environment' in today's market is defined as the IBM Personal Computer compatible hardware platform with Microsoft Windows operating system. Many commercial hardware and software control products are available in this environment and they can be integrated into a system to perform the desired control tasks. However, comprehensive engineering effort is required to integrate these components into a functional control system initially, and extensive engineering effort is required to replace or upgrade portions of the control system when necessary. Even though the modularity and scaleability are not there for the open environment controllers, users can certainly gain benefits of the open environment because of the choice of available components from multiple vendors and greater freedom of configuring the system to meet particular application needs.
A critical factor to increase the level of openness is the definition of a common set of API's. With the availability of common API's and products conforming to the API's, it is possible for the users to re-configure the control systems without extensive engineering effort. Thus, the second level of open control is labeled, 'Open Environment with Common Interface Controller' which allows the integration of special purpose hardware and software modules with common API's in an open environment. The 'plug and play' and 'scaleability' now becomes a reality.
The final level of openness removes proprietary hardware elements from the control system. This 'Open, Modular Architecture Control' level can be considered as a software based controller with generic processors running software control modules without special hardware such as motion control cards and discrete logic control cards that are plugged in the controller backplane. It is technically difficult at the present time to realize this level of openness because of the limitation of the Microsoft Windows operating system. Even with the NT operating system, the issue of real-time performance is a real concern. One alternative is to implement two operating systems with a real time operating system to handle time-critical tasks and the Microsoft Windows to handle non-real time tasks.
It is important to understand that all levels of openness are beneficial to users, and it is not the intention of GMPTG to implement only the controller systems with the highest level of openness. Control systems with the proper level of openness will be implemented depending on the application needs and program timing. GMPTG will continue to encourage the development of common API's and the highest level of openness, but has already begun implementation of open environment control as technologies are validated to be ready for large scale plant implementation.
Realization of the OMAC concept requires more than the selection of control modules and the definition of standard interfaces. It also demands commercially available components conforming to the standard interfaces, software tools to assist the users to integrate commercial components, and support from control component suppliers and system integrators for implementations. These factors are not parts of OMAC architecture, but they need to be available for the OMAC concept to be successfully implemented.