ELSEVIER Computers in Industry 33 (1997) 285-293

Design principles for open and reusable shop-floor control software

Niklas Andersson ’

Chalmers University of Technology, Department of Production Engineering. 41296 Gothenburg, Sweden

Abstract

Integrating a hete.rogeneous manufacturing environment means using information technology to provide appropriate access to accurate aml timely information. While individual systems provide valuable solutions to particular manufacturing or transport problems, quick and easy information-sharing throughout the shop-floor has become almost impossible. Yet, information-sharing is increasingly critical for the success of the company and its manufacturing goals. Whether data comes from a device or an application in the manufacturing environment, the critical success factor in shop-floor integration is the ability to turn data into useful information, to distribute it, and to share it regardless of application, device, hardware, operating system, and network used. Manufacturing environments are changing constantly and the technology surrounding and supporting them is often changing faster. Solving manufacturing problems by acquiring a variety of incompatible hardware and software from multiple vendors has created a complex application and device integration problem. This paper describes an appr0ac.h that makes the task of application integration easier. The concept focuses on achieving application independence and was verified in an assembly cell at a truck component factory. 0 1997 Elsevier Science B.V.

Keywords: Shop-floor control; Software architectures: Application enablers; Flexibility; Generic; Reusability

1. Introduction

Building and maintaining manufacturing applica-

tions have been difficult tasks in developing inte- grated manufacturing environments. Software engi- neers have used a variety of C programming lan- guages to generate manufacturing application codes. As a result, the application is rigid, difficult to change, and requires an almost complete develop- ment cycle to adoipt new manufacturing configura- tions. In fact, these applications have degraded and, with continued unlplanned maintenance ‘fixes’, the applications become less reliable. In addition, the

I E-mail: nand@pe.chalmers.se.

software engineers who developed the systems sub-

sequently become unavailable. The manufacturing

engineers are left with systems that need mainte-

nance and lack an easy way to make changes. To best serve the interests of the manufacturing engi- neers, manufacturing software must achieve the same stage of evolution as administrative software. What is needed in industry is manufacturing software equivalent to the popular spreadsheet packages. These programs revolutionised the business world by putting financial application tools on the desktop and directly into the hands of users who know the appli- cation best. The same productivity benefits can be enjoyed in the manufacturing environment, if engi- neers have application software tools tailored to their knowledge set [l].

0166-3615/97/$17.00 0 1997 Elsevier Science B.V. All rights reserved. PII SO166-3615(97!00034-1

286 N. Andersson / Computers in Industv 33 (1997) 285-293

Manufacturing engineers are experts in designing

and operating manufacturing systems. They know how the environment operates and understand the logic. Yet, they cannot program the control and integration logic required for manufacturing applica-

tions because they are not trained to use traditional programming languages. Instead, industry usually

depends on software engineers to handle program- ming and integration requirements. It is a highly iterative and tedious process in which manufacturing engineers typically conceptualise the system, define the specifications, and spell out requirements while the application programmers attempt to code the application accordingly. More often than not, soft- ware engineers tend to develop applications based on

their own interpretation of what works best.

2. Problem definition

In this case SCANIA CV was the end-user, IBM Sweden delivered the software modules, and Enator Sweden was acting as system integrators.

Utilisation of integrated shop-floor control sys- tems has been fragmentary in end-user companies. The manufacturing environment itself is highly flexi- ble, but the control system is inherently inflexible. For compatibility, application developers are forced to use a programming environment, network proto-

col, and target system from a single vendor. Further- more, information is scattered across various incom-

patible networks, devices, computers, and operating systems, all of which employ different proprietary protocols. Writing software directly to native net- work protocols is expensive and a very time-consum- ing way to integrate manufacturing applications. When application developers are forced to work in a complex and heterogeneous world, productivity suf- fers and applications can be infested with large software modules that are forced to be network-

specific. However, locked-in developers have fewer oppor-

tunities to take advantage of the best cost/perfor- mance solutions available for a specific application. What SCANIA require is a software architecture that makes it possible for each manufacturing application to get adequate information wherever it needs it, whenever it needs it and for all kinds of network protocols.

The design and especially maintenance and ex- pandability of manufacturing applications still con- tribute to major difficulties. The reason is that manu- facturing applications essentially are generated in an ad hoc manner. A truly industrial approach is needed

to replace the craft of application development in integrated manufacturing environments [3,5]. Key

factors that hold that evolution back are the exorbi- tant cost, time, complexity, and inflexibility of de- veloping customised communication software. No matter how talented a skilled software engineer is, customised solutions are slow to implement, expen- sive and inflexible.

SCANIA needs to be able to incorporate new technologies into its manufacturing environments, without discarding existing investments and disturb-

ing shop-floor operators. It wants flexibility to meet future changes, and freedom of choice, and the cer-

tainty that any new manufacturing resource will be compatible with the existing manufacturing environ-

ment. In summary, application and device integration

are major bottlenecks when designing and imple-

menting integrated assembly systems. Information exchange and portability between devices and appli- cations are hampered by incompatibility of these

systems. The following sections will define, describe, and

verify a software architecture that makes the task of

application integration easier.

3. Approach

Software architecture must provide services and functions to overcome platform barriers to interoper- ability, and also provide portability that insulates the application from underlying platform differences. This unified software environment must build on a comprehensive architecture that enables applications to be distributed across computers in the cell net- work [3,5]. As a result, redundant application-level coding can be eliminated, isolated manufacturing applications can be tied together, and meaningful manufacturing solutions that address the needs of the entire manufacturing environment can effectively be created and maintained.

N. Andersson/Computers in Industry 33 (1997) 285-293 281

This software environment is similar to graphical user interfaces (GUI). A good graphical interface gives computer user-friendly and efficient access to powerful PCs or workstations. Without such inter- faces, the average user will never take full advantage of desktop technologies. Likewise, software architec- tures furnish manufacturing applications with friendly

and efficient access to multi-vendor applications and networks. Without this enabling software environ- ment the average application developer will never take full advantage of Internet work technologies.

Obviously, there is a need to have software mod- ules that can be use:d in other application areas. If the modules allow applications to communicate through a transparent facmry network, then the application can be distributed on different computers in the

factory network. Furthermore, the application can be moved to another computer, at a later stage, to balance the shop-floor control system or adapt to changed conditions. As a result, the integration task

will be simplified [6]. Those software modules should meet the following general requirements: * Generic behaviour: The functional architecture

must support a generic approach. It should be possible to use the architecture on different con- trol systems.

Information t0

Fig. 1. Production activity control (PA0 141.

* Integration: The architecture must support inte- gration of shop-floor activities between and within levels in the control hierarchy.

* Modularisation: The activities within the architec-

ture must be modularised with well defined com- munication interfaces.

* Portability: It must be possible to adopt this architecture in a heterogeneous manufacturing en-

vironment. To satisfy the above demands, there is a need for

software architectures and application enablers that allow the creation of applications over many dissimi-

lar networks. The most important facility for such a tool is the application programming interface (API). It must be simple and provide for exchanging mes-

sages between two or more parts of a distributed application [2,7]. This message-delivering layer must be able to co-operate with multiple protocol stacks to

ensure that separate applications can interoperate, even when they operate on dissimilar networks that

use different protocol stacks.

Esprit project 477, Control Systems for Integrated Manufacturing (COSIMA) [4], has formulated a functional software architecture at cell level within the IS0 control hierarchy. It consists of five well-de- fined functional modules. The modules are repre-

sented at the operational level and grouped into a concept named Production Activity Control (PAC).

The PAC architecture consists of the following modules (see Fig. 1):

- Scheduler: This module plans the manufacturing resources in terms of manpower, tooling, and

work station capacity to create production orders. * Dispatcher: It is this module that acts in real-time

control over the manufacturing environment to distribute instructions or commands to associated devices.

* Monitor: The monitor module collects shop-floor data to give a logical view of actual status in the manufacturing environment.

- Producers: The final step in the control system is

to instruct the devices responsible for processing raw material and parts.

- Movers: The mover module manages material handling devices in the cell or between cells. This architecture formalises and simplifies the

activities necessary for building up a shop-floor con- troller. However, the architecture does not specify or

288 N. Andersson / Computers in Industry 33 (19971 285-293

define how messages and information will be passed between the PAC modules. SCANIA decided to use distributed software technology when realising this software architecture to provide access to accurate

and up-to-date information in an automated fashion, whether this information resides in different work cells or in different production areas.

4. Case study

This test case verifies and illustrates how software

and communication architectures can be applied in practice to control an assembly cell. The target sys- tem is a flexible assembly cell preassembling wheel-

hubs for an assembly line producing truck axles. The cell consists of nine robots and three presses con- trolled by two cell controllers and one database server connected through a cell network (see Fig. 2)

[9]. Raw and bulk materials are received by a global

camper system. The functional software design is based on a similar approach to the COSIMA archi-

tecture.

4.1. Functional architecture

The cell controller is generic and the specific cell logic is implemented by using an event-based cell control language. By describing the discrete manu- facturing scenario in terms of assembly operations it is possible for manufacturing engineers to implement and change the cell logic without any time-consum- ing traditional software programming. The control program carries out the task of managing the work in progress so that the order schedule is met. It contains a set of rules designed to react to any predictable

event within the assembly cell and make a decision which will result in the best possible course of action. Those rules are stored in a sequential event

table ready to be read by the task server. The event table consists of generic device commands defining

-= ii

Fig. 2. Production layout of the physical assembly cell [9].

N. Anderson/Computers in Industry 33 (1997) 285-293 289

Scheduler

, ,d MoverProducer 1, ,

( 1 Device Manager ] 1

Monitor

Fig. 3. Functional architecture of the cell controller.

the logical flow of raw and bulk material within the cell. Each command has a set of parameters that defines which producer/mover, material positions, and buffers are involved in the action.

The shop-floor controller consists of the following software modules [5,8] (see Fig. 3): - Scheduler: This module manages order and mate-

rial handling. It consists of an operator interface

to the manufacturing database providing services for order and m,aterial handling. When an order is released this module sends a message to the task server to start, if there is enough parts and bulk material in the cell.

- Dispatcher: This module generates and dis- tributes task requests necessary to fulfil required production orders. It consists of a task server and a task dispatcher, with the logical material flow in the cell defined in an event table. This table is the input for the decision-making process within the task server. The first phase in the task server is to determine which conditions are satisfied given the current state of the event table for the cell. If there is a match, a task is generated for that

particular producer/mover and the message is distributed to the task dispatcher to be forwarded to and received by a mover/producer module.

- Monitor: Alarm and production disturbances are handled by this module. It consists of an alarm manager and an event handler to invoke operator

action to eliminate the disturbance on the shop- floor. when a task fails it can be repeated, deleted, or acknowledged depending on the action se-

lected by the operator. Producers: These modules interface to production equipment on the shop-floor. They consist of a

device manager and communication modules con- nected to specific devices. There are six produc- ers connected to three hydraulic presses and three assembly robots. These modules receive generic

device commands from the task dispatcher, and convert and forward them into proprietary device instructions. when a task is completed, or for

some reasons runs out of time, the device man- ager redirects the return code from the device either to the task dispatcher or to the monitor

module. Movers: Any movement of materials and products within the assembly cell is managed by these

modules. They are connected to six material han- dling robots in the assembly cell and consist of

structures similar to those of the producer con- cept.

4.2. Production scenario

The given production scenario is a simplified view of the real assembly scenario that the shop-floor controller co-ordinates. The aim of this example is only to explain the logical principles for how the shop-floor controller works at runtime.

The simplified assembly cell consists of:

seven movers (Mover-1 to Mover_7); four producers (Producer-l to Producer_4); ten material positions (Pl to PlO); three control positions (Dl to D3); five material buffers containing wheelhubs, bear- ings, wheel bolts, oil catchers, and an outpallet for finished wheelhubs (Sl to SS).

When a production order is released and the cell ready and running, the dispatcher distributes in-

structions to production devices to fulfil the order. In this case (Fig. 4) the material flow and the assigned tasks are as follows:

Step I: Mover-1 picks up wheelhubs from buffer Sl and places them in one of the material positions Pl-P3.

290 N. Andersson/Computers in Industry 33 (/9Y71285-293

EJ si @ Qi 4% Pi P2 P3

0 Material PositIon

Control Position

storage (S)

El Order queue

0 D3 0 02

53 52

B Q5

Fig. 4. Material flow within the assembly cell.

H a4

Step 2: Mover-2 picks up a wheelhub from one of the positions Pl-P3 and places the wheelhub in position P8, a position in Producer-l.

Step 3: Mover-3 moves a pair of bearings from S2 and separates the outer race from the bearing. Outer races are placed on P4 and P5. Those are positions in Producer-l. Inner races are placed on positions P6 and P7.

Step 4: Mover-4 picks up a pair of outer races from positions P4 and P5. Those outer races are

placed on position P8, a position in Producer-l. Step 5: Producer-l performs the requested pro-

ducer action, a press operation. Step 6: Mover-5 moves the wheelhub from posi-

tion P8 to P9. Step 7: Producer-2 picks wheel bolts from buffer

S3 and puts them in the wheelhub on position P9. Step 8: Producer-3 performs a press operation to

fix the wheel bolts in the hub.

Step 9: Mover-6 moves a pair of inner races from positions P6-P7 and an oil catcher from buffer S4 to position PlO, a position in Producer_4.

Step IO: Mover-5 picks’ up the wheelhub from Producer-3 and moves it to position PlO, a position in Producer_4.

Step I I: Producer-4 assembles the material in position PlO.

Step 12: Finally, Mover-7 gets the finished wheelhub from position PlO and places it in buffer s5.

The message flow (Fig. 5) between the software modules is as follows:

Step 1: An order is released.

Step 2: The task server receives a start message. It checks for any available task to perform.

Step 3: If there is a match in the event table it requests task parameters from the data base and builds a task message.

Step 4: The task dispatcher receives the task message and redirects the message to the device

manager. Step 5: The device manager determines which

mover/producer that will perform the task. Step 6: The selected mover/producer sends out

necessary instructions to perform the requested task. It sends out device-specific commands.

Step 7: An acknowledgement is received from the device and the message is forwarded to the device

Order Ma-

Material Manager ‘* Database Manager

2. - 3.

5 Task Server 4

4. 9. 12.

Task Dispatcher Event Manager

6. 7. T Production Resource

Fig. 5. Logical message flow

modules.

between the shop-floor control

N. Andersson / Computers in Industy 33 (1997) 285-293 291

manager if the task was OK, but to the alarm man-

ager in case of a failure. Step 8: The device manager sends the acknowl-

edgement back to lhe task dispatcher.

Step 9: The task dispatcher re-routes the message back to the task server that will try a new recognise-

act. Step 10: If the task fails the alarm manager will

be notified. It handles the alarm and activates neces- sary actions to overcome the alarm.

Step 11: The event manager executes and requests an operator-initiated action. All disturbances on the shop-floor must bl: handled by operators and they notify the alarm manager when the problem is solved.

Step 12: When the disturbance is eliminated the

event manager notifies the task server to continue the search for new taslks in the event table.

5. Discussion

The software modules in the PAC architecture were implemented with an application enabler, Plant- Works/Distributed Application Environment (PW/DAE) from IBM, and distributed over three

nodes in the shop-floor network (see Fig. 6 >. The basic idea behind an application enabler is to extend

operating systems, protocols, networks, production equipment, and data facilities to address the unique requirements associated with the integration of the manufacturing environment. This software architec- ture should support application development trans- parent to constantly emerging new hardware, operat-

Ethernet/NetBIOS

Node 1

!L

OS12 OS12 OS/2 DAE DAE DAE PlantWorks PlantWorks PlantWorks Scheduler Monitor DBl2 Dispatcher Movers Monitor Monitor Producers Movers Producers

Fig. 6. Hardware and software configuration of the cell controller.

ing systems, and protocols. It provides build-time and run-time services to create and run shop-floor

control applications, which are sets of instructions that control, co-ordinate, monitor, and report on manufacturing operations. A family of programming services provides a software base to simplify devel- oping integrated manufacturing applications in dis- tributed shop-floor environments. It integrates shop- floor applications by providing a common, uniform, graphical application programming interface (API). This interface provides functions for application pro-

cessing, messaging, device communication, and data collection. Applications using this generic software architecture have access to shop-floor data without

needing to know where it resides, or which shop-floor application generated it.

This application enabler allows applications to communicate with each other in a controlled envi- ronment. The message-passing mechanism provides distributed services which improve portability of function, ease of configuration, and maintenance-free use.

These features give the following advantages: The sending application does not need to know where on the cell network the receiving applica-

tion resides. Applications on the cell network do not to bother

about what kind of network (LAN) or network protocol the sending/receiving node uses. Applications do not need to concern themselves with conversion from simple ASCII to compiled binary, or bit-mapped graphic data. The experience from the test cases using a generic

software architecture, such as the COSIMA and the application enabler PW/DAE, is that:

-The PAC modules enable software and mechani- cal engineers to understand the functional be- haviour of a manufacturing application. It is easy to distribute the PAC modules, since they are designed modular and support client

server principles. The PAC modules make a good framework, but are not enough. It is necessary to expand the model to fit in an existing manufacturing environ- ment. The quality of the software is increased when the design and implementation phases are subordinate to an industrial approach (COSIMA, PW/DAE).

292 N. Andersson/ Computers in Industry 33 (1997) 285-293

* It is possible to use an incremental approach when implementing large integrated manufactur- ing systems. It is easy to integrate a new work cell because of the well-defined interfaces be- tween monitor and dispatching modules. It will be a matter of configuring the manufacturing data base rather than reprogramming the application code.

- Application enablers still are a software tool for skilled C programmers. The application program- ming interfaces (API) and data representation are

very complex and hard to understand for mechan- ical engineers.

* It is easy to integrate new manufacturing equip- ment into a Producer module. By using a device- independent approach, when communicating with a device, it is possible to change from an existing device to one from another vendor without chang- ing the application code in the Producer.

- The task of writing device-generic driver is diffi- cult. Due to the complexity of a proprietary proto- col there is a high threshold to overcome before

the programmer understands the semantics and syntax of the device protocol.

6. Conclusions

The evolution of application software has been rather tortuous. The introduction of higher program- ming languages, software development tools, and application enablers provides the means to become more abstracted from the internal details of computer hardware and operating systems. It permits express- ing manufacturing problems with their corresponding solutions at an abstraction level even closer to the application area. The role of integrated manufactur- ing is to plan and control effectively the actual resources in the manufacturing environment so as to meet the production goals. The resources include production equipment, materials, tools and fixtures, storage and transportation equipment. The main de- sirable characteristics of the manufacturing system are flexibility, product variety, product quality and rapid response to changing requests.

In order to preserve this step-by-step character of the development process, it is necessary to adopt a

generalised and formalised development methodol- ogy. Increasing the experience with application en- ablers (PW/DAE), when developing manufacturing

applications, will incrementally transform discrete manufacturing from islands of automation into inte- grated shop-floor systems. The main argument for

selecting a generic application enabler (PW/DAE) is that traditional programming environments available on general operating systems do not address the complex problems encountered in developing soft-

ware in a discrete manufacturing environment. An application enabler provides the application devel- oper with generic tools and functions that make this task easier. To conclude, the following general state- ments can be made:

- Application integration. Application enablers are a way to achieve the cross-platform consistency that open systems and standards strive for, thereby

adding a new dimension of functionality to manu- facturing control systems.

- Device Integration. The concept of a generic

approach to device integration gives the applica- tion programmer a consolidated view of devices in the manufacturing environment. It is important that these architectures provide both access trans- parency and location transparency.

* Sofhvare Architectures. It is important that manu- facturing applications be allied with a functional architecture. Such architecture allows software modules to be developed and tested separately, and there will be no problem with the integration of the system. The verification of the approach against a true

industrial test case showed that: - The quality of manufacturing application code is

raised when the design and implementation phases were subordinated to an industrial approach.

- The maintenance and expandability of manufac- turing applications are simplified when using open and reusable software modules.

- Generic software architectures enable both soft- ware and mechanical engineers to understand the functional behaviour of a manufacturing applica- tion.

* Application enablers still are software tools for skilled software engineers. The application pro-

N. Andersson/ Computers in Industry 33 (1997) 285-293 293

gramming interfaces (API) and the data represen- tation are very complex and hard to understand for non-professional programmers.

- By using a cell control language consisting of assembly operations it is possible for manufactur- ing engineers to implement and change the cell

logic without any time-consuming traditional

software programming. Finally, it is important that manufacturing engi-

neers focus on the manufacturing problems, not on

the software integration problems. This is achieved by adopting a good software architecture. A good software architecture derives from manufacturing re- quirements and creates a flexible integration frame- work for an increlmental implementation and for future changes. This paper shows that it is possible

to design and implement generic software modules

in an industrial environment.

Acknowledgements

The co-operation and support from SCANIA CV, IBM, and ENATOR. and their personnel is gratefully

acknowledged.

References

111

121

[31

[41

151

[61

t71

Dl

[91

N. Andersson, Achieving application independence on the

shop-floor, Proceedings of the IFAC Conference on CIM in

Process and Manufacturing Industries, Espoo, 1992.

N. Andersson, Dispatching intercell material handling systems

in discrete manufacturing, Proceedings of the Esprit Confer-

ence in Realising CIMs Industrial Potential, Amsterdam, IOS

Press, 1993.

N. Andersson, Application software architectures in an inte-

grated manufacturing environment, Department of Production

Engineering, Chalmers University of Technology, Lit. Thesis,

1993.

A. Bauer, R. Bowden, .I. Browne, J. Duggan, G. Lyons,

Shop-floor Control Systems, Chapman & Hall, Chap. 3-5,

1991.

P. Norrman, system design specification--IBM shop-floor

controller, IBM Sweden, 356/SDN-01, 1994.

L-F. Pau, J.-O. Willurns, Manufacturing Software at the

Crossroad, 10s Press, Amsterdam, Chap. 10, 1993.

K. Siggaard, Development and implementation of shop-floor

control systems, Ph.D. Thesis, Laboratory of Process and

Production Engineering, Institute of Manufacturing, Technical

University of Denmark, 1992.

.I. S&h&, Functional requirements specification-IBM shop-

floor controller, IBM Sweden, 356/FSP-01, 1994.

M. Thun, System requirements specification-wheelhub as-

sembly cell at SCANIA CV, Enator Sweden, 331/SSP-01,

1994.