Controls Software Requirements for Global Commonization

By Sushil Birla, Jerry Yen, Frank Skeries, and Dave Berger, General Motors Corp. January 1, 1999

Business drivers for GM Powertrain (GMPT) Competitive pressures to introduce better-quality new products to global markets faster and at lower cost are driving the need to improve the controls engineering processes, standards, and tools in a globally common manner. Subgoals affecting operation include reduction of downtime and quality-loss. Subgoals affecting engineering costs include reuse of assets such as software components. To this intent, GMPT has tasked expert teams to define a future vision, requirements, and migration plan for engineering, design, documentation, and programming of manufacturing automation controls.

There are many challenges. Lead-time reduction forces overlap in product engineering, manufacturing process engineering, and controls engineering, requiring running changes to machine/process control programs. Additional differences in production controls stem from differences in plant-replication timings around the globe, application characteristics, regional regulations, conventions, standards and skill-base constraints. Rapid technological obsolescence forces upgrades to platform components and tools before a product-program is completely implemented. Due to short lifecycle relative to manufacturing equipment, computer technologies have to be upgraded many times over the life of the equipment. As a result, many versions of platform components and tools are in use in production, increasing maintenance difficulty and refresher training costs.

To meet these challenges, the GMPT commonization effort will bring together best practices and lessons learned from around the world into a common global specification. Key technical concepts include: (1) use of mainstream technologies, (2) a modular component-based architecture that maximizes software reuse and minimizes the cost of changes in requirements, technology, execution platforms and presentation forms, (3) unified engineering and programming tools and environment, and (4) harmonization of international standards.

Use of mainstream technologies As often as possible, the solutions should leverage computing and communication/networking hardware, platform software, tools, and software components used in mainstream high volume applications. It is uneconomic to create and maintain equivalent functionality in a manner specific to the manufacturing automation industry. Volume is so small that the amortized unit cost is high and the specialized skill-base needed is short in supply and costly to maintain.

Interfaces should be common to the mainstream of computing and networking, e.g., web tools, communication services, and operating system services, when such mainstream services meet the requirements of the application in a reliable, maintainable manner. In any case, interfaces should be mappable onto mainstream services. Consequently, there is a need to select a notation or ‘language’ for which mainstream, economic, well-supported transformation tools and skills are available. The language structure and paradigm should not be specific to manufacturing automation.

Modular component-based architecture Control logic software should be modular, portable, and composed of reusable library components and language elements having public, supplier-neutral interfaces, standardized across respective application domains and users. The user organization, in its manufacturing operations, should be able to reuse these libraries and administer version and configuration control, distribution, and maintenance, to assure consistency across the whole program.

Referring to the figure, common elements, as shown near the bottom, include general-purpose elements (equivalent to IEC 61499 Annexes B and E) that are not specific to any presentation form or application domain or industry. The block above ‘common elements’ depicts application-independent system services (per concept of IEC 61499 service interface types), built up from the common elements and system service primitives. Services include communication with networked I/O, including human-machine interfaces. From these elements, application domain-oriented basic building blocks are formed, e.g., a simple one-axis motion device with two stable states or a sophisticated servo-controlled axis of motion. These components are independent of machine cycle control flow. Therefore, they are reusable across many projects, machines, and workstations.

Application class library components may be sourced from suppliers of the controller, the programming tools, the machine tool, the hardware component supplier, the control integrator, or a third-party software component supplier. A control logic sequence, modeled as a state transition network, is composed from functions of instances of these classes. Repetitive patterns of control cycles in a particular application domain are reusable as library classes. The overall machine control logic program is composed of reusable library components described above, specialized or instantiated as required. In this manner, machine-specific programming is minimized. Reuse of class libraries also helps preserve a consistent structure and reduces follow-on training time. The idea of designing systems with standard components and using a high-level language is well established in the field of electronic hardware.

Video-dependent database All library components and their assemblies into state-transition networks, including the whole program, should be available and accessible in a view-independent database through a set of defined software interfaces. This structure allows the flexibility to integrate pre-existing library components implemented in a computer programming language such as C/C++, an IEC 61131 presentation language, or through flowcharting. View-specific data, associated with control logic data, should be isolated. This separation allows views or presentations to be in the forms best suited to the usage. For example, in certain cases, program data may be supplied more efficiently as lists, tables, spreadsheets, or through ‘forms’ and ‘dialog boxes’ to construct the ‘view-independent database.’

Engineering and programming tools and environment Unnecessary variety of engineering tools and programming languages should be eliminated. For example, a unified programming environment is needed for all the functionality to be programmed in a given work cell. Programmable functions include the overall sequence of operations, coordinated motion of multiple motion elements (servo-controlled or two-position), in-process inspection of the workpiece, work-holding and handling, tool condition monitoring and the interaction and interlocking across these functions. The scope of integration includes programmable peripheral functions, e.g., human machine interaction, diagnostics, setup, and configuration. Consider the case where an automatic cycle of machine motions stops unexpectedly. The control program should notify the operator the state in which cycle it stopped, the active motion element, the unfulfilled enabling condition, and the identification, location, and state of that input device, if pertinent. This diagnostic information should be presented to the operator without any application-specific programming. Context-sensitive help and documentation should be available as further assistance. Troubleshooting should not require study of the original control logic program.

Whereas a typical high-productivity manufacturing workstation integrates a variety of processing and supporting functions, the user organization faces the burden of acquiring, maintaining, and integrating multiple programming environments and languages and skills in its use. It should be possible to specify a variety of interacting, intermingled processes in the same programming environment.

Harmonization of international standards needed Unfortunately, there are separate programming-language standards for ‘different’ types of manufacturing automation, e.g., ISO 6983 or EIA RS 274 for numerical control, DMIS for dimensional measurement and inspection, IEC 61131 for discrete logic control, ISO 9506 for communication. These differences have become institutionalized in standardization committee structures, e.g., ISO TC 184 (technical committee for manufacturing automation). The vocabulary of each language is limited in its expressivity to its traditional narrow focus. There is significant nonvalue adding overlap in functionality. The languages have unnecessarily confusing differences in semantics for the same concept. Furthermore, programming for human machine interfaces and communications (accounting for the largest share of total effort) is still vendor-specific. The amount of discrete logic control is becoming a smaller and smaller proportion of the programming and maintenance cost. Its programming environment is inadequate for specifying efficiently the breadth of control functionality in use today.

Harmonization of these standards is needed to facilitate the needed efficiency improvement and integration. However, ongoing standards efforts continue to be uncoordinated. For example, the model for specifying a sequence of operations, including synchronization, conditional branching, and concurrency, in ISO 14649 (targeted successor of ISO 6983 to use path trajectory data in the form of ISO 10303, STEP) is not coordinated with the model under consideration in IEC 61499. Neither is coordinated with ISO 10303 AP224 responsible for defining the flow structure of process plans. IEC 61499 introduces the notion of state- and event-based flow of control-a step in the right direction. There is a need for a common control flow model across ISO TC 184 and IEC 65 in their respective future standards. Different programming languages is another example of divergence-a subset of ‘C’ is proposed for ISO 14649, whereas the corresponding language in IEC 61131-3 is ‘ST.’ Neither of them packs the power of object-orientation, coming in common use in mainstream computing. IEC 61499 utilizes the concept of abstract data types in its function block types-another step in the right direction. However, generalization-specialization hierarchy (inheritance) is not exploited. There is a need for a common object model (e.g., the model adopted by the Object Management Group) across ISO TC 184 and IEC 65.

To control software lifecycle cost of application programs and tools, we need very efficient transformation of a higher-level process plan into a finer-granularity process plan up to the final transformation into a program that controls a manufacturing machine tool or cell. The simpler and more direct the transformation (mapping) the better it would be. Therefore, the equivalent of the process plan or sequence of operations should be decomposable and mappable into the controller APIs as directly as possible. However, there is no concerted effort to coordinate development of specifications for language architecture and controller architecture. As an initial integration step, standardization efforts should seek semantic equivalence of different forms of expression.

Current standards do not assure portability of application software, nor interchangeability and interoperability of multi-sourced components. Much additional effort is needed in developing the necessary standards, conformance tests, and competent certification facilities.

Summary There are tremendous improvement opportunities in manufacturing operations through automated control, monitoring and diagnostics. Key enabling technologies are emerging in mainstream computer applications. However, programming technologies and standards used in manufacturing automation are not keeping up. As a first step to tackle the problem, we urge major users to work together towards a common set of requirements for the future, following the success model used in electronic hardware design.

Sushil Birla, Jerry Yen, Frank Skeries, Dave Berger,General Motors Corp. (Pontiac, Mich.)