software standardization integrating industrial automation systems

ELSEVIER Computers in Industry 25 (1994) 113-124

COMPUTERS IN INDUSTRY

Software standardization integrating industrial automation systems

Gaetano Messina *, Guido Tricomi

Istituto di lnf?~rmatica e Telecornunicazioni, Facolth di Ingegneria, Unit,ersith di Catania, Male A. Doria 6, 95125 Catania, Italy

Received 18 October 1993; accepted in revised form 15 August 1994

Abstract

In order to achieve the maximum level of integration, it is necessary to develop appropriate standards for both software and communication systems. As far as the latter are concerned, the work of the international standardization organizations has already given results which will soon be used by manufacturers, vendors and users of industrial automation systems. Of great interest, however, in the industrial environment is the recent setting up of standardization activity in various sectors linked to the development of software for industrial automation systems.

In this paper, on the basis of the work carried out by ISO TC184, the authors analyze the current state of development of standards for software to be used in industrial environments, and discuss foreseeable future orientations. In particular, the following standards are outlined: STEP (STandard for the Exchange of Product model data), which deals with a computer-interpretable representation of product data independent of any particular computer system; MAPL~ (Manufacturing Application Programming Language Environment), which is a structured set of tools needed for integration of different application programs in an industrial environment; ~C'R (Intermediate Code for Robots) and PER (Programming Language for Robots), which are part of a robot system programming environment.

Keywords: Software standardization; Industrial automation systems; Programming environment; STEP: MAPLE; ~CR; PLR

1. Introduction

In the last few years, r igid indust r ia l p roduc- tion l ines have been t r ans fo rmed into more flexible a u t o m a t e d systems al lowing prof i t ab le product ion in smal ler batches , thanks to cons ider - able improvemen t s in c o m p u t e r technology, da ta process ing and communica t ion systems. This new

* Corresponding author.

kind of manufac tu r ing is to ta l ly compute r - a s - sisted, from p lann ing to final delivery, and the in tegra t ion of the var ious process ing systems is what is genera l ly known as C o m p u t e r I n t e g ra t ed Manufac tu r ing (CIM). In o r d e r to achieve the max imum level of in tegra t ion , it is necessary to develop a p p r o p r i a t e s t anda rds for both software and communica t ion systems.

As far as the l a t t e r a re concerned , the work of the in te rna t iona l s t anda rd iza t ion organ iza t ions ISO TC184 and IEC TC65 have a l ready given

0166-3615/94/$07.(10 ~ 1994 Elsevier Science B.V. All rights reserved SSD1 0166-3615(94)00021-2

114 G. Messina, G. Tricomi / Computers in Industry 25 (1994) 113-/24

results which will soon be used by manufacturers, vendors and users of industrial automation systems. This has been fiaade possible by using the standards already existing in the field of information technology, such as those referring to the ISO-OSI (Open Systems Interconnect) architecture and its derivate MAP (Manufacturing Appli- cations Protocol) and TOP (Technical Office Pro- tocol), or research projects developed by international consortia such as ESPRIT, whose CNMA (Communication Network for Manufacturing Ap- plications), however, is still based on the ISO-OSI architecture. Once the requirements of an industrial environment were established, the production of basic standards for industrial communication has been quite rapid, an example being given by the ISO MMS (Manufacturing Message Speci- fication) [1], which is utilized at the ISO-OSI application level and forms the core of the corn-

munication software of several industrial automation systems. In addition, functional standards are being developed as a result of the basic standards mentioned above, along with sets of specific industrial requirements, 1he most important of which is MAP in its various forms: Full MAP, MINI-MAP, MAP-EPA (MAP-Enhanced Performance Architecture).

On the other hand, development in the field of software standardization is slower, essentially on account of the lack of standards close to the requirements of industrial automation systems.

Of great interest, however, in the industrial environment is the recent setting up of standardization activity in various sectors linked to the development of software for industrial automation systems. As already mentioned, nowadays all the activities involved in industrial manufacturing processes are supported by the use of electronic:

R&D policy

Finance Corporate

Management

Marketing policy

1

Production policy

Finance

Sales forecast

Marketing & Sales

Budget

R & D Product requirements availability

. ~ ~ & quality Research & Development Product design

requirements

Bill of Materials

Production Engineering I

I Engineering info

H Resource Procurement Management

Production Management

Purchase order

Shop Floor Production

Production commands

Ship status

Product

Shipping

Products

Ship order

.......... t t Prso~Urrc eeds Maintenance R ~ r tue~tnce

Maintenance F Management

Production status

Fig. 1. Typical arrangement of manufacturing activities.

G. Messina, G. Tricomi / Computers in Industry 25 (1994) 113-124 115

processing systems. So, in order to ensure the maximum flow of information between the main activities involved in a discrete parts plant, there is a need at all levels for application software which is capable of integration. These manufacturing activities, identified in ISO TR 10314-1 [2], comprise but are not limited to: Corporate management, Finance, Marketing and Sales, Re- search and Development, Product design and Production engineering, Production management, Procurement, Shipping, Waste material treat- ment, Resource management, Maintenance management, Shop Floor Production (see Fig. 1).

As is known, high-level activities have so far only been partially based on the use of processing systems, which are essentially used for data analysis and prediction and as decision support systems. Planning, design and production activities, on the other hand, are based on extensive use of these processing systems in the form of CAD, CAE, CAM, NC machines, programmable logic controllers, robot systems, etc. The most urgent need for standardization is therefore felt as referring to these activities.

In this paper, on the basis of the work carried out by ISO TC184, the authors analyze the current state of development of standards for software to be used in industrial environments, and discuss foreseeable future orientations. In particular, the following standards are outlined: STEP (STandard for the Exchange of Product model data), which deals with a computer-interpretable representation of product data independent of any particular computer system; MAPLE (Manu- facturing Application Programming Language Environment), which is a structured set of tools needed for integration of different application programs in an industrial environment; ICR (In- termediate Code for Robots) and PER (Progr)m- ruing Language for Robots), which are part of a robot system programming environment.

2. Standard for the Exchange of Product Model Data

Each product, during its life-cycle, may be described by a set of features relevant to the

particular purpose. In fact, the selection of features relevant for the design or production stages of manufacturing might be quite different from that required by the quality control or maintenance ones.

The whole set of features needed in the various stages forms a Product Data Model, whose primary aim is to maintain product data complete and consistent throughout the product life-cycle.

Having provided a suitable computer-interpretable form for the information contained in the product data model, product data may be pro- cessed by computer systems. Moreover, by choos- ing a mechanism capable of describing product data in a way independent of any particular implementation, different computer systems may be able to exchange product data freely.

Standardization work in this field includes the development of international standards for the use of digital product data. ISO 10303 [3], unoffi- cially called STEP (Standard for the Exchange of Product model data), covers a range of standards for the basic representation of product information. Another future standard will deal with a mechanism which can represent standard parts data necessary for the implementation of libraries of component parts.

The STEe project is an attempt to answer the requirements outlined above for product data, focusing on the representation and exchange of product models which can be interpreted directly by advanced application programs without the need for human interaction. It aims at achieving a standard product model which will be informa- tionally complete for purposes such as generating manufacturing process instructions, directing quality control and performing product support functions. The model will be suitable not only for file exchange, but also as a basis for implement- ing and sharing product databases and archiving. Besides shape and solid representations for both boundary and constructive geometrical forms, the standard will provide a range of non-geometrical data, such as features, tolerance specifications, material properties, surface finish and other specifications. Together with the relationship information from the sending system, this standard will allow a complete product model to be corn-

116 G. Messina, G. Tricomi / Computers in lndust~ 25 (t994) 113-124

municated. Besides the standard itself, work is being done to develop a series of companion documents to support implementation, testing and engineering.

The form of ISO 10303, which does not de- pend on any particular computer system, enables consistent implementation across a number of applications and systems and allows testing for conformance. Different technologies can be used to store, access and transmit product data. In ISO 10303 the representation of product information is separate from the implementation methods. One definition of product data is common to many applications and can be tailored to meet the requirements of specific applications. The information for one or more applications is rep- resented by an application protocol.

A formal data specification language, EXPRESS,

is used to specify the Product Data Model. By using a formal language, the representation is made consistent and precise and the development of implementations is facilitated. ISO 10303 also supplies a methodology and framework for conformance testing.

A product data model for a particular product is made up of a collection of product data subsets called Integrated Resources in ISO 10303 terminology. Integrated resources are to be seen as logical abstractions of the features or capabilities of a particular product. The definitions of the integrated resources are as general as is possible without creating ambiguity or loss of meaning. Each definition is independent of any specific method of implementation.

Integrated resources, in their turn, are made up of basic building blocks called Resource Con- structs, which identify similar subsets of product data from different domains. Resource constructs can be specialized to support a particular application with the addition of specific constraints and relationships. All the resource constructs are defined by the formal language EXPRESS.

The approach used by ISO 10303 is to provide one definition of product data common to many applications, so we can distinguish two categories of integrated resources: Generic Resources, which are independent of all applications and can reference one another, and Application Resources,

which correspond to a group of similar applications, referencing and extending the generic resources. As far as generic resources are concerned, the subsets of product data include: product description, geometrical and topological rep.- resentation, shape representation, product structure and visual presentation. For application resources they include drafting. Each subset contains one or more interdependent EXPRESS modules, thus avoiding duplication of constructs. Tex- tual definitions are provided to clarify the meaning and context of the constructs.

Integrated resources define a partial model tor product data and so cannot support the information requirements of an application without more specific definitions and constraints. This, however, is achieved by means of Application Proto- cols, which select the appropriate integrated resources and specify any necessary constraints (see Fig. 2). This specialization is called interpreta- tion, its result being an Application Interpreted Model which is documented as part of an ISO 10303 application protocol. The relation between a specific application and the selected integrated resources it requires is maintained by document- ing the scope and information requirements in the terminology of the application. The application protocol provides a mapping which shows how the resources are used to meet these requirements. Regional or national organizations as well as company projects may produce application protocols to satisfy their needs, according to the common guidelines provided by ISO.

EXPRESS, the formal data specification language used for the definition of product data in integrated resources and application protocols, avoids ambiguity and guarantees consistency. It can be read by humans and also interpreted by computers to generate computer-interpretable applications and supporting tools. EXPRESS provides a mechanism for the normative description of product data for both integrated resources and application protocols and can be supplemented with additional supporting text. The normative description it provides is independent of any implementation method. This language allows the definition of entities from data elements, constraints and other properties, which go to make

G. Messina, G. Tricomi / Computers in Industry 25 (1994) 113-124

Product Data Model Integrated Resources ,Generic Resources Product % 0 Description

Product 0 k Structure 0

Geometrical O~ Representation

Shape 0 V Representation

,,, r /

Application Resources

selected resource

constructs

0 Resource Construct

Application Interpreted Model

Application Protocol

Application Activity Model ~ Processes constraints

Information Flow attributes Functional Requirements

I Context

Information Requirements

Application Reference Model

Formal information model of the application ]

Fig. 2. Relationships between various entities in ISO 10303.

Resource Constructs O O O O 0

interpreted to meet the product data requirements of the application protocol

117

up the valid constructs of product data. It allows classification and structuring of constructs and the generalization or specialization of the charac- teristics of these constructs, specialization being a mechanism which facilitates the development of application protocols by adding constraints and attributes to already existing constructs. EXPRESS primitives (schemas, types, rules, functions) have unique names within the integrated resources.

3. Manufacturing Application Programming Lan- guage Environment

Manufacturing involves a wide range of tasks which in turn have various requirements and constraints. On account of the diversity of these requirements and constraints, for the programming of tasks it is necessary to have a variety of manufacturing application programming languages. Each language has its own environment

of methodology, development, simulation tools and run-time services. It is therefore difficult, although desirable, for the developer or designer to coordinate the different languages for the single tasks of a project. Again, systems engineers and integrators encounter great difficulty in com- bining programs which use different manufacturing languages on account of the fact that they use different run-time services.

What is needed in order to solve these prob- lems is a Manufacturing Application Program- ming Language Environment (MAPLE), which is a structured set of capabilities connecting the objects (data, tools) used in C1M to the required user services [4]. The "objects" referred to are mainly part machining programs, lists and geometric descriptions of parts, manufacturing schedules or virtual manufacturing devices, and they have to conform with certain data interface specifications which allow the MAPt.E to access them. The term "user services" refers to applica-

118 G. Messina, G. Tricorni / Computers in Industry 25 (1994) 113-124

tion programs such as language editors and schedulers for manufacturing resources, programs for the display of data, or the simulation of manufacturing sequences as specified by a machining or material handling program. These, too, have to conform with user service interface specifications. Whereas some services use the MAPI.E without being part of it (e.g. language editors) others are so widely used and generic that they are included in standard MAPLE librarieS.MAPLE will support activities such as the design and development of programs written in application programming languages, and the operation and management of production software. Its standards will prove useful to a number of users, such as the developers of MAPLE tools, CAE systems and manufacturing application languages, who will provide tools for MAPLE users such as manufacturing plant and product designers, process planners, station level device programmers, systems engineers and integrators, and installation and production engineers. The end users of the information, tasks and resources they provide will include machine tool and material handler operators, cell and shop supervisors, maintenance per- sonnel and production schedulers.

It is necessary to program various kinds of functions at the Station, Cell and Section levels of the ISO Shop Floor Production Model. Exam- ples of these functions are management and control of equipment in a workstation, coordination of the workstations in a cell, supervision of cell activities and communication between entities from the Station level upwards.

In general, the MAPLE will have to produce executable programs to control, command, coordinate and supervise any kind of automated manufacturing equipment, and will have to be usable in the programming of various kinds of equipment, conforming to both existing and foreseeable future requirements.

The scope of the MAPLE ranges from product design and production to management and control. This includes a great range of data and languages: STEP (Express) in product design, the ANSI Input Language, CLData, IRData and Communications Protocols in product manufacturing. It will make use of several programs:

CAD/CAM compilers, interpreters, and data conversion/manipulation programs~

In this scenario, the MAPH:: will have to support the economic installation, integration and use of software packages. This can be achieved by logically positioning the main manufacturing software functions within the ISO 1(i)314-I architecture, specifying interfaces for data transfer between elements in the architecture, defining data storage specifications for the data shared by the applications in the architecture, and lastly by specifying user interfaces ill order to reduce the unnecessary differences between applications and support "transparent" integration.

The components which will be programmed by the MAPLE, as can be deduced from the various MAPLE users, will include virtual devices (e.g. ter- minals, stations, displays, indicators'), PCs~ NC machines, robots, inspection machines, automated guided vehicles, machining centres, material handling systems and cell controllers.

Again, the needs of the various MAPL~ users determine the functions to be programmed. These include motion, manipulation and transport, machine settings, the computation of product geom- etry and workpiece parameters, the adjustment of equipment parameters, the selection and order- ing of auxiliary tools and attachments, the selection of production equipment, the management and coordination of equipment, cells and stations, communication between devices and interfaces with operators, process control, the preparation of process documentation, route development, job and task description, and the organiza- tion, coordination and supervision of the shop floor.

In order to reach the maximum degree of automation, Station level components will have to communicate with the other entities involved, so that equipment can be controlled and monitored. Fault detection will be rapid, and data to support decision process will be provided as required. Moreover, Equipment and Station level control programs need to base their decisions on parameters from other parts of the enterprise. Flexible interfacing will be facilitated by the standardization of data formats and interface protocols at these levels.

G. Messina, G. Tricomi / Computers in htdustry 25 (1994) 113-124 119

Equipment parameters are initially defined on the basis of the kind of processes being carried out, the tools used and the parts handled. They are mostly defined from knowledge bases con- taining empirical data, but adjustments based on actual data (e.g. from vision or adaptive control systems) become necessary during the process itself. Performance will be greatly improved if these data acquisition and parameter adjustment functions are programmed.

At the Cell and Section levels, the functions to be programmed mainly concern planning, coordination and supervision, their task being to ensure the functioning of equipment at the lower levels. This can only be achieved if all the "objects" required are in the right place at the right time. An example is provided by NC machining centres, which include the pieces to be machined, the tools required to perform the task, information about these tools and the necessary NC program. When the task has been successfully completed, the higher level is notified; if, on the other hand, the task is not completed, the higher levels will be notified of the fact and take the necessary action

to solve the problem. All this entails data collection, processing and analyzing capacities.mAPLE user productivity can be enhanced not only by providing them with integrated tools but also by making manual intervention in otherwise automated operations unnecessary. The activities which will have to be supported to achieve this include requirements analysis, analytical mod- elling, specification of functions and interfaces, prototyping, program development and testing, quality control, the preparation of user documentation, user training, the generation of problem reports and the maintenance of schedules.

As outlined above, MAPLE is a structured set of capabilities connecting the objects (data, tools) used in CIM to the required user services. Fig. 3 shows the general MAPLE architecture. Its purpose is to provide a working environment which will facilitate user operations and therefore en- hance productivity.

The three services the MAPLE provides are a "User Interface Service", a "Tool Integration Service" and a "Data Handling Service".

Access to the User Interface Service is mostly

Manufacturing Software Dev. Support Tools

MAPLE User Interface Services

I ( I

I I Manufacturing General Simulation . . . . . Purpose Support Tools Software Tools

I I I MAPLE Tool Integration Services

Manufacturing Data Tools

I I

I

Manufacturing Data Handling Services

~ Manufacturing Specific

Database (Distributed)

] MAPLE

I General Tools I

(Design, Graphics, Analysis, Text)

I

Fig. 3. Conceptual model for a MAPLE.

Application Tools

Basic Tools

120 G. Messina, G. Tricomi / Computers in Industry 25 (1994) 113-124

gained through the User Interface Services Inter- face. The interface service puts several commands at the user's disposal ("Fetch Data", "Simulate", "Display", etc.), according to which it sets up the appropriate connection between the user and a specific Application Tool.

Application tools require the use of other basic tools, some of which belong to the MAPLF, program library while others (e.g. application tools) do not. Several basic tools are manufacturing specific but there are also a number of general ones which are widely used in data processing. Linking between the types of tools is provided by programs in the MAPLE Tool Integration Area, by means of the Tool Integration Service Interface. For purposes such as animation, command translation of process execution, the MAPLE Program Library provides generic basic programs.

The execution of Application Tools calls Basic Tool, which may need read or write access to data: By means of the Data Handling Services Interface, access is gained to the MAPLE "Data Handling Area", which provides programs to ex- amine data set labels and, by means of the data templates contained in the Data Template Li- brary, MAPLE provides the possibility to check data compatibility and format conversion. The templates supply formatting standards and data dictionaries for generic groups of manufacturing data.

A MAPLE provides complete tool integration by means of the three-level integration service described above (manufacturing data handling, tool integration and user interface).

The lowest level service (manufacturing data handling) integrates the basic database handling tools and provides interfaces for access to the manufacturing database. The tool integration service (second level) provides interfaces for the integration of basic tools in order to construct application tools, and are the most powerful integration kits. The service checks data compatibility and, if necessary, links a suitable format conversion facility. Future improvements should make the service capable of identifying and linking any number of basic tools. The highest level, or user interface service, provides simple user-friendly kits for the running and use of application tools.

The most common, generic basic tools are prepared by MAPLE as standard libraries, of which there are two kinds: a data template library and a programs or services one. The former typically provides glossaries or templates for all the data items in the user's database, and is therefore a useful source of information in determining the proper data model to expect in the database files the tools have to access. The latter contains generic basic tools of routine use, such as those for the static display or animation of parts of the manufacturing process, models of virtual manu. facturing devices from which to derive virtual models of specific devices, tools to translate or decompose commands, etc.

As these standard libraries are very large, they have been classified in 3-dimensional space to facilitate consultation. The three axes of this space are the abstraction level (generic, partial, particular), the domain of basic tools (processing, description, presentation and management) and the type of object (product, facili~~ task or process and knowledge).

All the elements they contain have to conform to the tool integration services interface and the manufacturing data handling services defined by the MAPLV: model outlined above. If every ele- ment in the libraries consists of integration interfaces, a library core and data handling interfaces, application tools can easily be structured by putting together appropriate libraries and connecting interfaces.

4. Robot programming languages in ISO

There are two lines of standardization in ISO activity concerning robot programming languages: l('n (Intermediate Code for Robots) [5] and PI_R (Programming Language for Robots) [6-8], which are part of a robot system programming environ.. ment (see Fig. 4).

User requirements in a specific application are expressed in terms of a program, which is then written in a user-oriented language. It is trans- lated into a lower-level code and then loaded into the robot control unit, which subsequently exe- cutes it.


USER Central Control

Robot Programming

Language (PLR)

Robot Programming System

Other Programming Methods

Intermediate Code (ICR)

I Robot I Control

Systems

Fig. 4. Programming environment for a robot system.

Since there are several different robot controllers, a general programming language is needed to supply a global interface betwen the user and the different systems. This is provided by PER, which aims to support robot control and task description.

The robot control unit, on the other hand, has a structure of its own and frequently its own low-level language. A bridge is therefore required between the low-level languages of robot controllers and the high-level user-oriented programming languages which have evolved. This is provided by ICR, by means of which user programs and data can be exchanged between different robot controllers a n d / o r between a robot programming system and control.

4.1. Intermediate Code for Robots

As specified above, the ICR code can be used for the exchange of user programs and data between robot control units a n d / o r a robot pro-

gramming system and control. It consists of a sequence of records which represent different instructions (e.g. data or type definition) includ- ing arithmetic and stack operations, thus allowing arithmetical expressions to be calculated efficiently with respect to a postfix notation. The ~C'R can be used as an intermediate code to provide a standard format between the programming system and the controller, and as an interface between different machines.

There are two ways to execute a program written in tCR: it can be converted into a user- specified code by a translator and then transferred to the control unit, or it can be transferred to the control unit in file or through a communication line and then executed directly on the control unit.

The configuration of the system and implementation of the control unit vary according to the system developer. In our standard the control unit structure is taken to be the one shown in Fig. 5. - The path generator computes the trajectory of

the industrial manipulator. - The servo system creates the path through a

servo system. - The peripheral controller controls digital and

analog i n p u t / o u t p u t units. - As far as the sensors are concerned, digital

i n p u t / o u t p u t is assumed, as no specific devices are defined.

- An optional file storage system is available.

robot control unit I

---'~ path generator I

I I servo system H joints I

[ peripheralcontro' I

~ ] sensors ]

I communication line I

I file storage system I

Fig. 5. Scheme of a robot control unit.

122 G. Messina, G. Tricomi / Computers in Industry 25 (1994) 113-124

An articulated robot with six degrees of freedom (or fewer) is assumed. No redundant degrees of freedom are provided for in the standard.

ICR is a pseudo-machine level programming code. It is a stack-based machine with explicit i npu t /ou tpu t statements, the data stack being explicit and the program return stack implicit. Subroutine and exception return addresses are therefore protected. Variables can be either local or variable. The former have to be on the stack to allow reeursion, while the latter can be on the stack or in a separate pool, depending on the implementation. In the following section we de- scribe the main features of the tCR.

The simple kinds of data are the ones which can usually be found in common programming languages: integer, real, boolean, character. The representation of texts through strings of up to 255 chars is not provided for, nor is there provision for explicitly structured data such as arrays or records. Arrays can, however, be defined and used efficiently with a block addressing mode which allows use of a single entry point for all components in the array. There are also certain kinds of geometrical data (some portable, others robot-dependent) to define the robot's status, configuration, orientation and position, both in Cartesian and joint coordinates.

For data declarations, provision is made for a set of instructions called Memory and Data Man- agement. The instructions to control program execution and timing use typical assembler language modes (conditional jump, jump with de- crease, subroutine). There is also provision for wait possibilities, along with suspension of the program in order to enter the teach-in mode, and axis and orientation control.

As regards arithmetic and boolean operations, operations with one or two operands are possible. These operands have to be on the top of the stack and are replaced by the result of the operation. Provision is also made for for operations between geometric robot data (e.g. conversions between systems of coordinates, translations of axes, cinematic transformations, distance calcula- tions, comparisons). Typical operations on strings are also included.

Since the language is based on a stack machine, it is possible to perform typical stack operations such as pop and push on aggregate simple data.

Movement control is performed by means oI a group of instructions allowing the usual definition of robot movements: point to point, polynomial, interpolated linear and circular movements. The trajectories defined can be either in Cartesian or joint coordinates. A trajectory can also be defined using the learning box (teach-in). A further set of instructions permits movement parameters such as speed and acceleration to be defined.

Data communication control is achieved by a set of primitives, similar to those used in assembler languages, for the acquisition of analog and digital data and communication channels.

4.2. Programming Language ]'or Robots

PER is a problem-oriented programming language which can be used by shop-floor workers as well as expert system engineers. It is independent of the application field and robot controls, and permits on- and off-line programming, with and without using the robot, interaction with external devices and sensors, and all kinds of trajectory programming possibilities. It supports structured programming using a "normal" level language like PASCAL, MODULA or C and the concepts of high-level programming languages. The language definition is compiler-oriented with respect to an incremental compilation. Program parts are par- allelly executed (multitasking) and, lastly, the portability of user programs is provided for.

The robot system is a manipulating industrial robot with 1 to 6 degrees of freedom, although redundant degrees of freedom and additional axes are also possible. A single robot is typically assumed, but two or more can be coordinated. Peripheral equipment is programmed by the robot controller; any kind of end-effector or sensor can be controlled.

There are no particular specifications concerning the kind of computer, but workstations and robot controllers are assumed. Again, no operating system or architecture are specified. The main environment is text programming.


It is possible to specify graphic man-machine interfaces and programming aids as conformance classes and a minimum of interactive action will be necessary. Compiling a n d / o r interpreting should be possible.

PER is a language for application programming, but not one which describes an operating system. The PER output may be an ICR program. For implementation it will be necessary to have an interface with files and the Manufacturing Mes- sage Specification (MMS).

A PER program is structured in much the same way as common high-level programming languages. It consists of a heading, clauses for specification of the system, a declaration part, definition of routines, and an executive part.

The types of data are those which are normally found in both structured and simple languages like PASCAL, C or MODULA. A number of pre-defined records allow the geometric and dynamic features of the robot to be described, for example position, orientation, pose (position and orientation), robot target (pose plus status and movement information) and joint coordinates. The latter is system-dependent.

Operations on numerical data and strings are the same as those used in Pascal-like languages. A feature which is specific to robot applications is that the operators applied to geometric data take on another meaning and are usually interpreted as vectorial operators. Another operator provides for calculation of translations and rotations.

The instructions, cycles and conditionals are similar to those used in general-purpose programming languages. By means of some instructions robot movements are defined as is typical of industrial environments (i.e. by points, linear, circular). A further set of instructions allows inter- ruption, suspension or connection of the various movements. Finally provision is made for a primitive to allow movewments to refer to a specific arm, in systems with more than one arm.

By means of a set of clauses I / O signals can be assigned the names and types of variables to be used. Normal file management primitives are obviously included. The relatively complete management of multitasking is possible through a set of primitives which essentially replicate the UNIX

primitive fork. Lastly, a rendez-vous mechanism is provided for to cope with synchronization.

5. Conclusions

In the previous sections we have discussed the current state of development of the main standards for industrial automation software systems. The most important features of these emerging standards have been outlined and discussed. For some of them (e.g. STEP) significant results are expected in a relatively short time: implementation of the generic specifications of the standard will soon be achieved and the activity of the various work groups will continue to develop libraries for classes of applications (standard parts, electrical and electronic applications, etc.).

As far as MAPLE is concerned, development will foreseeably be slower. Documents regarding MAPLE will have to be compiled in the form of Technical Reports, as they are meant to provide an informative overview rather than a normative recommendation.

As regards the two languages described--pER and ~CR--it has been pointed out that they belong to a class of languages concerning manipulator movements. This class is the only one that can be standardized at present because it has already reached an appropriate level of reliability, having been widely used in industrial applications for a reasonable length of time. In addition, a consid- erable knowledge of the techniques and proce- dures which characterize these languages has already been achieved by designers. Although this class of languages will foreseeably continue to be used, even in the presence of more advanced languages, we feel that future standards will have to include the features of third-level languages, thus allowing the programming of robots at a sufficient level of abstraction to enable their tasks to be described as operations on the objects they manipulate. ~cR and PER will therefore have to be configured as a nucleus with the possibiility of subsequent addition of new elements.

A number of experts may criticize the approach and methodology followed by ISO in the standardization of the subjects dealt with above,

124 G. Messina, G. Tricomi / Computers in Industry 25 (t994) 113-I24

and even single features of these standards, but it must be borne in mind that a standard is always a compromise between the differing requirements of producers, vendors and users. Not all these requirements can be met; in an early stage, at least, only the most important will be taken into account. A standard is not, however, a final product, but only a starting point of reference which can subsequently be integrated with additional modules to satisfy a wider range of application requirements.

Finally, it appears that the advantage of adopt- ing standards like these is the interoperability they provide between systems produced by different manufacturers without recourse to integration software. Again, modularity is a decidedly advantageous feature, as it allows selection of the most suitable system components for a specific application and thus the replacement of components in the event of technological evolution or variations in application requirements.

References

[l] ISO DIS 9506, Manufacturing Message Specification. [2] ISO TR 10314-1, Industrial Automation--Shop floor

production--Reference Model for standardization and a methodology for identification of requirements.

[3] ISO CD 10303-1, Product Data Representation and Ex- change-Par t 1: Overview and Fundamental Principles.

[4] ISO/TC184/SC5/WG4 N.76, Manufacturing Automa- tion Programming Language Environment (MAPLE)---A Common Support Facility for Multiple, Independent, Programming Languages for Manufacturing Devices and Controls: Part 1--Overview.

[5] ISO/TCI84/SC2/WG4 N.104, Manipulating Industrial Robot: Intermediate Code for Robots, Committee Draft.

[6] ISO/TC184/SC2/WG4 N.94, Requirements for a High Level Robot Language.

[7] ISO/TC184/SC2/WG4 N.II5, Manipulating Industrial Robot: Programming Language for Robots, Working Draft.

[8] ISO/TCI84/SC2/WG4 N.ItlR2, hnportant Issues on PLR

[9] G. Messina and G. Tricomi, °'Intelligent systems for advanced manufacturing", Proc 1AS*2. Amsterdam. The Netherlands, December 1989.

[10] G. Messina and G. Tricomi, "Manufacturing communication architectures", Computers in Industry. Vol. 13, No~ 4, March 1990, pp. 285-293.

[11] G. Messina and G. Tricomi, "Virtual representation o~ the robotic vision process", Proc. tCSE 91, CoventD. Polytechnic, United Kingdom, 10-.!2 September 1991.

Gaetano Messina was born in Cata- nia, Italy in 1945. He received a degree in physics from the University of Catania in 1968. lie was Assistant Professor from 1973 to 1974 in the Engineering Faculty of the University of Catania. Since 1978~ he has been an Associate Professor in Computer Science in the same faculty, ttis areas of interest are architectural aspects of communication and management of industrial LANs, microcomputer and

multi-microcomputer based technologies, CIM, robotics, vision systems and knowledge-based systems. Professor Messina is President of the National Technical Committee acting as Italian Member body in ISO/TC184, and is also Convener o1 ISO/TC184/SC1/WG5 for vision systems, lie is responsible for the objective: "parallel architecture in vision systems" of the National Finalized Project on Robotics.

Guido Tricomi received his Elec- trotechnical Engineering degree cure laude in 1984 from the Engineering Faculty of the University of Catania. where he is currently a researcher. An Italian expert in ISO/TC184, he participates in the activities of several working groups. In particular, he participates in ISO/TC184/SC1/WG5 which is responsible for "Vision systems integration in manufacturing environments". His areas of interest are

CIM, real-time communication, architectural aspects in multi-microcomputer systems, robotics and vision systems.