The OMAC concept has been presented to many control vendors, equipment builders, and end users, and the OMAC direction is being embraced by many companies. However, during the interactions with many companies about OMAC, many non-technical issues were raised concerning the feasibility of large-scale implementation of OMAC-based systems on the factory floor. Many similar concerns were voiced repeatedly, and perspectives from GM Powertrain are presented in this section to address these issues.
Reliability of PC Hardware
The GM Powertrain Windsor and Romulus plants have installed and are in the process of installing more than 500 PC based controllers. The reliability and the uptime of these PC control systems have been excellent, and there is no reason to believe that the PC-based systems for the Premium V6 and L850 programs will be any different.
The high mean-time-between-failure (MTBF) of the standardized PC mother boards should ease the concern about the reliability of PC hardware. It is obvious that one should be cautious in selecting a reputable vendor for such PC components. It is known that every PC board is not created equal. Large personal computer suppliers, such as Intel, IBM, COMPAQ and HP, produce millions of mother boards a year, and the test specifications of their motherboard products are similar, if not more stringent, than 'low-volume' industrial control products.
Packaging and system integration of PC-based control systems are still extremely critical, and certain protection of PC components needs to be incorporated for the harsh environment in GMPTG plants. However, the necessary packaging is no worse than that of PLC equipment.
GMPTG personnel expect the operation of PC-based control system will be at least comparable, if not more stable, than a PLC based control system.
Integration of open control systems
GMPTG anticipates utilizing the services of major system integrators, either GM internal resources or outside system integrators, to assist in the implementation of large programs, similar to the current practice. It should be noted that the cost of integration support through 'Tier II' suppliers is presently built into the cost of products, and GMPTG is moving toward addressing the integration cost and the product cost separately.
It is possible for a vendor to perform the role of control system integration only. In this role, a control system integrator selects and acquires control modules, in both software and hardware, from control component suppliers, and integrates them into an OMAC to meet particular GMPTG application needs. The control system integrator will support the OMAC as if it were one of its own products and serve as the 'Tier II' control supplier to machine tool OEM's and system integrators. The control system integrator will then be responsible for the warranty of the OMAC product. Several control companies demonstrated interests in becoming control system integrators and are in the process of evaluating the business issues. This is no different than many PC companies today that sell PC's where most of the major subsystems such as motherboard, hard drive, CD-ROM, monitor, and interface cards are built by other high volume producers. These PC companies warranty the complete system and sell it as if it were their own.
Liability of open control systems
It is a myth to believe that users will be replacing the internal modules of control systems frequently, beyond the control of system integrators and control vendors. Open systems provide the users the ability to choose the most appropriate components at the system design stage and implement incremental changes after the systems are installed. It is impractical for GMPTG personnel to replace modules inside a controller unless there is a good technical and business case to do so. After a system is installed, GMPTG will concentrate on operating the system efficiently rather than tinkering with the internals of the control system.
In other words, GMPTG is treating the implementation of OMAC-based systems the same as the implementation of proprietary control systems. GM is always sharing the liability for injuries to plant personnel regardless of the type of control equipment that is used. Significant features for safe operations are required for GMPTG's Industrial Equipment Specifications.
Support of open control system implementations
On the system level, GMPTG expects the system integrators to be fully responsible for the equipment that they have installed and correct any problems related to the performance of the manufacturing systems. On the OMAC controller level, the control system integrator is the one responsible for the hardware and software problems related to the controller. The control system integrator may utilize the warranty from the suppliers of PC hardware to cover the repair of hardware components. GM electricians will perform the maintenance of the hardware in the plants. Use of standard interfaces will allow GMPTG personnel to more easily determine where problems exist and replace failed components without having to learn and understand numerous proprietary interfaces and systems.
The testing of PC based software is still the responsibility of the software supplier. GMPTG has a validation and testing procedure for vendor products before the products can be implemented in a major program. The necessary evaluation and testing of products may be performed by GMPTG or vendor personnel. If a common set of application programming interface specifications has been defined and accepted by most vendors, then a third party conformance testing organization needs to be established to certify that software modules are compliant to the specifications.
Relationship between user and vendor
GMPTG believes that the OMAC concept promotes closer cooperation between the end users and technology suppliers. The traditional more confrontational and self-centered relationship between vendors and users will no longer be productive in the open environment. Many technology and implementation issues need to be addressed jointly by users and suppliers, and longer-term partnerships need to be developed to perform incremental upgrades of enhanced functions continuously. It is also easier to transform user requirements and needs into actual implementations, benefiting both parties.
One of the benefits of OMAC is allowing the integration of modules from different suppliers. If a small company has the best module for a particular function, OMAC allows the end users to purchase the module and integrate it into an OMAC controller. This capability provides business opportunities to smaller control suppliers who traditionally have difficulties obtaining business from GMPTG and also promotes technology innovation because the marketplace will continue to develop better ways to accomplish a particular function.
Progression toward OMAC systems
Implementation of OMAC technologies will take place gradually when opportunities arise. Different elements of OMAC are being incorporated in each new program at GMPTG. The OMAC technologies that are implemented for a particular GMPTG program will be determined when the timing of the program requires. Because of the on-going technology evaluation and validation, GMPTG engineers can determine which technologies are 'matured' and are confident that they are reliable and suitable for the program. In other words, elements of OMAC to be implemented will only be selected when the decision is needed based on the timing of the major program. As new implementations occur, GMPTG will upgrade certain machines or purchase new machines using OMAC technologies.
Globalization of the OMAC concept
GMPTG engineers are currently working with engineers from the GM International Operations (GMIO) powertrain operations in defining common control architecture because future GMPTG programs will mostly be global programs. OMAC is an integral part of the common control architecture, and initial steps have been taken to investigate the differences and similarities between OMAC and other open architecture development efforts in the world. Examples of such efforts are the Open System Architecture for Controls within Automation Systems (OSACA) project in Europe and the Open System Environment for Controller Architecture (OSEC) project in Japan.
Because of various constraints within each open system development effort, a workable process of cooperation is still being discussed. However, all parties agreed that closer cooperation will benefit all development efforts and sharing of API definitions will result in a global standard and make open, modular controls a worldwide reality.