- Email: [email protected]
Open System Controllers – A Challenge for the Future of the Machine Tool Industry
-
Open System Controllers A Challenge for the Future of the Machine Tool Industry G.Pritschow (11, Ch. Daniel, G. Junghans, W. Sperling Received on January 15,1993
Summanr This contribution deals with the present situation of the European machine tool industry and the control manufacturers as well, as with the motivation to start with the design of a vendor-neutral open control system. The problems of configuration and control-internal Communication are discussed and solutions are given. Furthermore, the ESPRIT project OSACA is presented which aims at the specification of vendor-neutral standards for open control systems. L
l-immdh The machine tool industries in Europe are struggling to survive. Many vendors, mainly belonghg to the medium-size industries, compete each other with the result of small lots and the disadvantages of this kind of production. Besides the mechanical construction of the machine tool, the numerical control is very important for the success on the market. For numerical controls there is a great number of vendors. Additionally same machine tool manufacturers are developping their own controls. As well as in the machine tool industries, the control vendors, too. are struggling for shares on the market with similar, but all the same different concepts and a great number of special functions. Therefore it is time for the machine tool as well as the control manufacturers to join forces, to elaborate common concepts, to develop basic technologies and to produce basic components together. This is necessary to be able to exist on the market with competitive prices by means of larger numbers of products and better quality, as well as by using synergy effects with products, which are interesting for a large number of customers. lor an oDen
Numerical control systems have been and even today are mainly offered as closed manufacturer-specific solutions. Such systems are characterized by the fact that, on the one hand, function enlargements are not or only possible in a complicated way and mostly only with the help of the control manufacturer. On the other hand, a transition from a control system of one manufacturer to that of another manufacturer or even a transition between systems of one control family of a manufacturer are only realizable with great difficulties. Even scopes for possibilities of differentiation, e.g. at the man machine interface, or possibilities to use synergy effects or to save costs by common developments are not existing or even in a very restricted way. As a result of the present situation, there are mainly two reasons for demanding an open control system: the securing of investments and the reduction of costs. Two further arguments have to be taken into account, which are not important for all, but lor an increasing number of machine tool manufacturers: the protection of technology-specific know how as well as possibilities for differenciation. The demand for open control systems is not new. As early as at the end of the seventies and the beginning of the eighties and under the German abbreviation of mpst (mufti-processor control system), a consortium consisting of different machine tool and control manufacturers has agreed on a common control concept, which was to avoid the disadvantages mentioned above. The basic ideas of this concept are still state of the art, but due to a strong linkage to hardware characteristics the evoked standard is no longer useful. Today, almost all control manufacturers offer or announce their product as an 'open' system. But according to IEEE 'an open system provides capabilities that enable properly implemented applications to run on a
Annals of the ClRP Vol. 42/1/1993
variety of platforms from multiple vendors and interoperate with other systems applications". This implies, that only systems which follow common vendor-neutral conventions, can be described as open systems. So, in spite of disclosing construction principles and internal interfaces, the above-mentioned systems are remaining mainly manufacturerspecific and can therefore not be considered as open systems. Only with a generally accepted framework, which is freely available to everybody and based on standards, it is possible to cooperate in the development and production of basic components, thus finally reaching a reduction of costs by producing bigger lots. A generally accessible framework enables the experienced machine tool manufacturer to add technology-specific functionalities to the control system by himsetl. Thus, the retention of technological knowledge to competitors can be secured. Further, the usage of machine tool manufacturer-specific functionalities gives the possibility to differenciate oneself to the competitors. The demand for a real open control system will certainly not cease as long as such a common uniform architecture is missing, on which all or at least most of the important vendors have agreed and which is generally accepted as a standard.
The open system architecture is a specification of capabilities and services that provides the interconnecting structure and a definition of the interface between interoperating components.
FU functional unit DATA FUdatabase CONF FU system configuration GRAPH FU graphic system API application program interface Faure 1;System platform and functional units Main goals for the specification of an open system architecture are interoperability, portability, scaleability and interchangeability. Interoperability will only be guaranteed by using standardized data semantics and behavioral models, communication and interaction mechanisms. Portability allows to operate the system components on different platforms. Scaleability is a feature, which enables the customer to increase or decrease the functionality of a system by upgrading or downgrading
449
specific components. Interchangeability allows to SubstRute one component with another due to its capabilities, reliability or performance. To achieve these goals, it is necessary to introduce the idea of platforms (fig. 1). A platform consists of the hardware and a number of generic, control-independent software pieces, like operating, communication and graphic system. The platform offers a uniform set of services to the control specific functional units. The application program interface (API) between FUs and the platform is based on a well defined profile of services. Introducing platforms leads to portability, scaleablility and interchangeability. To fulfill the requirement of interoperability, also services to be offered from functional units have to be specified. svsta The increasing demand for functional flexibility in numerical control systems requires in addition to the structural conception of this flexiblity the availability of comfortable tools for the configuration and handling of the complete system. The building nf a software configuration optimized for the control task, i.e. the providing of the necessary software modules, is done within a modular control system by generating the necessary software topology of reusable software modules. Figure 2a gives an example of a simple configuration of an NC kernel for three feedfornard axes in path connection, a single axis and a controlled spindle. By using the same software modules, the control of two synchronized NC channels with three feedforward axes in the path connection each..two or three single axes and one contolled spindle is possible by means of the configuration shown in figure 2b. The synchronization of the NC channels is realized by an additional software module. The kind, in which the adapted software topology can be generated, is decisive for the degree of the flexibility of a modular control system. Here the maximal flexibility is reached by the dynamic generation of the software topology in the operating time or in the run-up phase of the NC. By providing standardized software modules the number of different versions, which is necessary to cover a spectre of configurations, can be drastically reduced. Hereby, the efficiency of the NC is increased by better care and maintenance of the control software.
Fiaure
Configuration function - dynamical generation of software topology
For ordering the control system with configuration tasks, Standardized configuration services (2) within the message-based information exchange between the functional units have to be specified for the following items: - the determination of the software topology by the selection of software modules from the module library as well as by the building of the data flow between the chosen modules, - parametrization of the functional contents of these modules,
- providing status information on the present software configuration. The integration of the chosen software modules into the data flow requires the specification of standardized interfaces to the operating system (3).Providing the access to the dynamically generated functional unit is done by involving the function and data objects of the modules. which participate in the control process, in the object list of a control-internal communication system (4). To increase the acceptance of a modular control system all phases of the configuration process must be supported by a well-rounded configuration concept (figure 4). That means: - specification of the software configuration, - ordering the NC with the generation of a control configuration,
-
executing the configuration task by a dynamic generation of the software topology, - confirmation by providing status information,
-
verification of the software configuration. Here, besides the control-integrated configuration function, comfortable tools made for the user for generating and administering the software configurations are necessary.
Software configuration - software topology For the realization of a dynamic generation of the software topology, the conception of a control-integrated functional unit for configuration is necessary. This configuration function belongs to the kernel functionality of a configurable modular control system (figure 3). Here the coniigurable software modules are provided in a module library. The access to the software modules is done by an uniform functional interface (1). The functionality of this interface has to accomplish in a standardized way the following requirements: - the completion of the provided control functionality by integration of new software modules, - the modification of the control functionality by exchanging or removing software modules, - the access to information of software modules.
450
Fiaure 4; Phases of the configuration process well-rounded configuration concept
Due to the proportionate set-up cost, higher requirements are made on the configuration system (figure 5) as an equipment-independent functionality to take into operation or configurate a modular control system. The flexibility of the complete system also requires the Specification of a flexible configuration system with standardized interfaces. A uniform user interface (2) becomes necessary to specify the software configuration. This tool should be based on an adaptable problem-orien-
tated man-machine interlace and hide the complexity of the complete system. Plausiblitiy tests for the specified configurations und verification of the generated software configuration by visualizing the results were to support all configuration steps. The adaption of the configuration system to the functionality of an NC requires the standardization of the interface to the system speckation (3) by standardized describing languages for the integrated software modules concerning their properties and the control-technical execution environment.
These requirements especially the demand for an arbitrary coupling of microprocessors can be satisfied best by a message-based communication system. Although the MMS protocol fulfills this it is too complex and does not offer all the features needed for communication within a control. Therefore a new attempt has to be made. Due to missing standards for message interchange in operating systems and the fact that within controls heterogeneous operating system solutions are quite common a universal transport system for messages has to be developped. A general transport entity (GTE) together with a uniform transport interface are defined (Fig 6). The tasks of GTE are to offer services for a safe transmission of arbitrary messages and to adapt to various existing communication systems and system connections.
-fast first implementation
- optimized time behaviour
- small expenditure for few messages to exchange m D
- unifwm, predefined solutions - easy to extend - clear behaviour in errw situations
- easy to understand - uniform documentation - managment and encoding within communication system
- decreasing expenditure for
growing number of information
- not reusable
Configuration system - uniform interfaces The demand for a uniform administration of the configurated control systems is fulfilled by a computer-aided generation of standardized documentation data. The standardization of the describing syntax offers the user the possibility to verify, reuse and modHy existing control configurations. The specification of standardized open modular control systems offers flexibility to the control manufacturer as well as to the user to be able to realize complete concepts of their own concerning the configuration of the NC functionality.
A communication system for information interchange between functional units (FU) in future open systems has to support concentrated as well as distributed control structures. Thus small machines, large manufacturing cells and transfer lines can be operated with the same universal software structure. The communication system has to enable FU's to communicate w M each other independently from specific hardware solutions or operating systems.
LAN Local Area Network if. interface Architecture for a communication system for control-internal information interchange
b-
m - difficult to extend E unpredictable behaviour in m 4 errw situations 3 - difficuH to understand 8 - difficult to document managrnent and e m d i n g within amlication
- high expenditure for first implementation
- time behaviour not alwavs
-
Fioure 7; Comparison of methods for information modelling Based on the transport system an application entity (AE) with an application interface is defined for application specific information interchange. It has to be decided how information is mapped to messages. In principle two approaches are possible: A first possibility is to define for each piece of information a specially taylwed message which can be directly transferred by the GTE. Although this solution offers best perlormance and fast results in a first implementation it implies a number of grave disadvantages (Fig 7a). A second possibility is to classify the information exchanged between FU's and to define generic information models onto which information is mapped. These guarantee that similar information is always accessed in the same way. The structuring of information can best be achieved by using objectoriented information models in connection with finite state machines. The available information is structured into objects which represent each a certain aspect of an FU and can be accessed via the FU's service access point. Each object contains a number of attributes that represent the information accessible from external and a set of services to access, modify etc. the attributes. Finite state machines describe the relationship between invoked services, state transitions and produced output. Similar objects are put together into object classes which render an abstract model for objects by defining a fixed set of attributes, services, states and state transitions.
F
m
Extended clienVserver relationship
451
'
Services are invoked by sending requesf messages and on the termination of the execution of a service a response message is generated containing the results. An FU can at the same time own objects and offer services thus acting as a sewer and also invoke services of other FU's thus acting as a client (Fig. 8a). In addition to the 'classic' clienVserver relationship here a server can also unsollcitedly inform cllents about object-related events. To achieve this the server sends report messages to clients that are confirmed by them through report response messages (Fig. 8b). Figure 7b shows the advantages of object-oriented information models. They are though only useful d R is possible to map all the needed information onto the defined models and object classes. Therefore R is important to collect and classrfy the information to be interchanged before defining models and object classes. The object classes then speclfied define the generic framework for information interchange which is however not sufficient to achieve the ability to interchange FU's of the same type. For this, instances of the specdied object classes have to be defined and d necessary be standardized.
Object classes and servtces for NC
In a lirst step an NC system can. with respect to decentralisation and standardization, be decomposed into the following 5 major FU's: manmachine control, motion control, logic control, process control and external communication. After a collection and classification of the information interchanged between these FU's six object classes are defined that cover all the interchanged information (Fig. 9). The object class Functlonal Unit (FU) manages the overall behaviour of an FU. The object class Data Access serves for read and write access to structured data. In addition to normal read and wite access the objects are able to cyclically report their content to other FU's. The object class Process Control is used to control tasks and processes within an FU. It contains a generic state machine for processes with states like running or stopped. For each individual object a specific state machine can be configured out of the generic one and supplied with functions for state transitions. The object class Evenf Management is used for event reporting and the object class File Access supports message-based file access. Timn
1
TC
I
Tt
I
Tt
I
Ts lTsumlTsurnl
Tc mean execution time in the client's application layer Tt mean transmission time (request + response) Ts mean execution time in the server's application layer Tsum = Tc + Tt + Ts (all times measured in msec) mernxshared memory TCP=TCP/IP transport system Foure 1Q; Response times of the communication system
The communication system described was implemented on different hardware platforms (Motorola 68030 processor board and Intel 80386 personal computer) to support information interchange between the
452
above mentioned five major FU's of an NC system. Time measurements (fig. 10) with TCP/IP and shared memory as transport systems show that the mechanisms and protocols developped are suitable for information interchange within controls even in distributed systems connected via Ethernet and TCPllP as the transport system. §
ODen Svstem Arch itecture for C Svstems (OSACA)
Automatim
The motivation for a joint action between machine tool and control manufacturers to specify an open control system was given in chapter 2. This is also the reason for starting the OSACA project. It will develop a strongly modular and highly configurable concept for control systems to achieve a fast and cost-efficient adaption to new problems. Work will also include the specification of mechanisms for machine tool manufacturers to integrate their own functionalities into the controls without having to disclose their specific know-how. The main goal of the OSACA project is the definition of a hardware-independent reference architecture for numerical machine tool equipment including the functionalities of numerical controls (NC), robot controls (RC), programmable logic controls (PLC) and cell controls (CC). This will build a framework consisting of functional units and their interfaces, communication protocols and mechanisms, and interfaces to operating and database systems. The OSACA reference model will form a common base for standard numerical and robot controls up to sophisticated cell controls including e.g. tool- and workpiece-handling systems. It will be open for the integration of new functionalities and for the use of new computing equipment. Project work will include a detailed analysis of the state of the art as well as of user needs and will lead to implementation guides for control and machine tool vendors. Prototypes will be implemented to validate project results. Demonstrations will be given to promote the new architecture. Project work will not include development of new hardware components, communication. operating or database systems. Instead of all that existing standards will be used whereever possible. The knowledge about user needs and the technology gained from the project will be used to work with national, European and international standardization bodies to ensure representation of European industrial requirements and achieve widely acceptable specifications. OSACA will result in shortening the development time. increased flexibility for the adaption of controls to the special demands of machine tools and manufacturing cells. Costs for development, adaption, commissioning, training, documentation and maintenance will be reduced. The project has been started in May 1992 wrth a duration of 3 years. The consortium comprises European control vendors, machine tool manufacturers and research institutes from France, Germany, Italy, Spain and Switzerland.
7 ConchsiQn Despite all conventions and ingenious technical solutions, the advantage of open systems for the user as well as for the manufacturer strongly depends on the degree of uniformity of the components of different manufacturers and their general use. Their degree of uniformity determines which services can be done when combining the components and their general use determines how many users have accass to these components. Both factors, however, can be determined neither by the individual manufacturer nor by the individual user.
(1) Pritschow, G., 1990, Automation Technology - On the way to an open
system architecture, Robotics B Computer Integrated Manufacturing, 1/2:103-111. (2) Pritschow, G., Miller, J., 1992, Entwicklung einer modularen numerischen Steuerung mit einheitlich strukturierten Funktionsmodulen, Maschinennahe Steuerungstechnik in der Fertigung, 3-18.
Open System Controllers A Challenge for the Future of the Machine Tool Industry G.Pritschow (11, Ch. Daniel, G. Junghans, W. Sperling Received on January 15,1993
Summanr This contribution deals with the present situation of the European machine tool industry and the control manufacturers as well, as with the motivation to start with the design of a vendor-neutral open control system. The problems of configuration and control-internal Communication are discussed and solutions are given. Furthermore, the ESPRIT project OSACA is presented which aims at the specification of vendor-neutral standards for open control systems. L
l-immdh The machine tool industries in Europe are struggling to survive. Many vendors, mainly belonghg to the medium-size industries, compete each other with the result of small lots and the disadvantages of this kind of production. Besides the mechanical construction of the machine tool, the numerical control is very important for the success on the market. For numerical controls there is a great number of vendors. Additionally same machine tool manufacturers are developping their own controls. As well as in the machine tool industries, the control vendors, too. are struggling for shares on the market with similar, but all the same different concepts and a great number of special functions. Therefore it is time for the machine tool as well as the control manufacturers to join forces, to elaborate common concepts, to develop basic technologies and to produce basic components together. This is necessary to be able to exist on the market with competitive prices by means of larger numbers of products and better quality, as well as by using synergy effects with products, which are interesting for a large number of customers. lor an oDen
Numerical control systems have been and even today are mainly offered as closed manufacturer-specific solutions. Such systems are characterized by the fact that, on the one hand, function enlargements are not or only possible in a complicated way and mostly only with the help of the control manufacturer. On the other hand, a transition from a control system of one manufacturer to that of another manufacturer or even a transition between systems of one control family of a manufacturer are only realizable with great difficulties. Even scopes for possibilities of differentiation, e.g. at the man machine interface, or possibilities to use synergy effects or to save costs by common developments are not existing or even in a very restricted way. As a result of the present situation, there are mainly two reasons for demanding an open control system: the securing of investments and the reduction of costs. Two further arguments have to be taken into account, which are not important for all, but lor an increasing number of machine tool manufacturers: the protection of technology-specific know how as well as possibilities for differenciation. The demand for open control systems is not new. As early as at the end of the seventies and the beginning of the eighties and under the German abbreviation of mpst (mufti-processor control system), a consortium consisting of different machine tool and control manufacturers has agreed on a common control concept, which was to avoid the disadvantages mentioned above. The basic ideas of this concept are still state of the art, but due to a strong linkage to hardware characteristics the evoked standard is no longer useful. Today, almost all control manufacturers offer or announce their product as an 'open' system. But according to IEEE 'an open system provides capabilities that enable properly implemented applications to run on a
Annals of the ClRP Vol. 42/1/1993
variety of platforms from multiple vendors and interoperate with other systems applications". This implies, that only systems which follow common vendor-neutral conventions, can be described as open systems. So, in spite of disclosing construction principles and internal interfaces, the above-mentioned systems are remaining mainly manufacturerspecific and can therefore not be considered as open systems. Only with a generally accepted framework, which is freely available to everybody and based on standards, it is possible to cooperate in the development and production of basic components, thus finally reaching a reduction of costs by producing bigger lots. A generally accessible framework enables the experienced machine tool manufacturer to add technology-specific functionalities to the control system by himsetl. Thus, the retention of technological knowledge to competitors can be secured. Further, the usage of machine tool manufacturer-specific functionalities gives the possibility to differenciate oneself to the competitors. The demand for a real open control system will certainly not cease as long as such a common uniform architecture is missing, on which all or at least most of the important vendors have agreed and which is generally accepted as a standard.
The open system architecture is a specification of capabilities and services that provides the interconnecting structure and a definition of the interface between interoperating components.
FU functional unit DATA FUdatabase CONF FU system configuration GRAPH FU graphic system API application program interface Faure 1;System platform and functional units Main goals for the specification of an open system architecture are interoperability, portability, scaleability and interchangeability. Interoperability will only be guaranteed by using standardized data semantics and behavioral models, communication and interaction mechanisms. Portability allows to operate the system components on different platforms. Scaleability is a feature, which enables the customer to increase or decrease the functionality of a system by upgrading or downgrading
449
specific components. Interchangeability allows to SubstRute one component with another due to its capabilities, reliability or performance. To achieve these goals, it is necessary to introduce the idea of platforms (fig. 1). A platform consists of the hardware and a number of generic, control-independent software pieces, like operating, communication and graphic system. The platform offers a uniform set of services to the control specific functional units. The application program interface (API) between FUs and the platform is based on a well defined profile of services. Introducing platforms leads to portability, scaleablility and interchangeability. To fulfill the requirement of interoperability, also services to be offered from functional units have to be specified. svsta The increasing demand for functional flexibility in numerical control systems requires in addition to the structural conception of this flexiblity the availability of comfortable tools for the configuration and handling of the complete system. The building nf a software configuration optimized for the control task, i.e. the providing of the necessary software modules, is done within a modular control system by generating the necessary software topology of reusable software modules. Figure 2a gives an example of a simple configuration of an NC kernel for three feedfornard axes in path connection, a single axis and a controlled spindle. By using the same software modules, the control of two synchronized NC channels with three feedforward axes in the path connection each..two or three single axes and one contolled spindle is possible by means of the configuration shown in figure 2b. The synchronization of the NC channels is realized by an additional software module. The kind, in which the adapted software topology can be generated, is decisive for the degree of the flexibility of a modular control system. Here the maximal flexibility is reached by the dynamic generation of the software topology in the operating time or in the run-up phase of the NC. By providing standardized software modules the number of different versions, which is necessary to cover a spectre of configurations, can be drastically reduced. Hereby, the efficiency of the NC is increased by better care and maintenance of the control software.
Fiaure
Configuration function - dynamical generation of software topology
For ordering the control system with configuration tasks, Standardized configuration services (2) within the message-based information exchange between the functional units have to be specified for the following items: - the determination of the software topology by the selection of software modules from the module library as well as by the building of the data flow between the chosen modules, - parametrization of the functional contents of these modules,
- providing status information on the present software configuration. The integration of the chosen software modules into the data flow requires the specification of standardized interfaces to the operating system (3).Providing the access to the dynamically generated functional unit is done by involving the function and data objects of the modules. which participate in the control process, in the object list of a control-internal communication system (4). To increase the acceptance of a modular control system all phases of the configuration process must be supported by a well-rounded configuration concept (figure 4). That means: - specification of the software configuration, - ordering the NC with the generation of a control configuration,
-
executing the configuration task by a dynamic generation of the software topology, - confirmation by providing status information,
-
verification of the software configuration. Here, besides the control-integrated configuration function, comfortable tools made for the user for generating and administering the software configurations are necessary.
Software configuration - software topology For the realization of a dynamic generation of the software topology, the conception of a control-integrated functional unit for configuration is necessary. This configuration function belongs to the kernel functionality of a configurable modular control system (figure 3). Here the coniigurable software modules are provided in a module library. The access to the software modules is done by an uniform functional interface (1). The functionality of this interface has to accomplish in a standardized way the following requirements: - the completion of the provided control functionality by integration of new software modules, - the modification of the control functionality by exchanging or removing software modules, - the access to information of software modules.
450
Fiaure 4; Phases of the configuration process well-rounded configuration concept
Due to the proportionate set-up cost, higher requirements are made on the configuration system (figure 5) as an equipment-independent functionality to take into operation or configurate a modular control system. The flexibility of the complete system also requires the Specification of a flexible configuration system with standardized interfaces. A uniform user interface (2) becomes necessary to specify the software configuration. This tool should be based on an adaptable problem-orien-
tated man-machine interlace and hide the complexity of the complete system. Plausiblitiy tests for the specified configurations und verification of the generated software configuration by visualizing the results were to support all configuration steps. The adaption of the configuration system to the functionality of an NC requires the standardization of the interface to the system speckation (3) by standardized describing languages for the integrated software modules concerning their properties and the control-technical execution environment.
These requirements especially the demand for an arbitrary coupling of microprocessors can be satisfied best by a message-based communication system. Although the MMS protocol fulfills this it is too complex and does not offer all the features needed for communication within a control. Therefore a new attempt has to be made. Due to missing standards for message interchange in operating systems and the fact that within controls heterogeneous operating system solutions are quite common a universal transport system for messages has to be developped. A general transport entity (GTE) together with a uniform transport interface are defined (Fig 6). The tasks of GTE are to offer services for a safe transmission of arbitrary messages and to adapt to various existing communication systems and system connections.
-fast first implementation
- optimized time behaviour
- small expenditure for few messages to exchange m D
- unifwm, predefined solutions - easy to extend - clear behaviour in errw situations
- easy to understand - uniform documentation - managment and encoding within communication system
- decreasing expenditure for
growing number of information
- not reusable
Configuration system - uniform interfaces The demand for a uniform administration of the configurated control systems is fulfilled by a computer-aided generation of standardized documentation data. The standardization of the describing syntax offers the user the possibility to verify, reuse and modHy existing control configurations. The specification of standardized open modular control systems offers flexibility to the control manufacturer as well as to the user to be able to realize complete concepts of their own concerning the configuration of the NC functionality.
A communication system for information interchange between functional units (FU) in future open systems has to support concentrated as well as distributed control structures. Thus small machines, large manufacturing cells and transfer lines can be operated with the same universal software structure. The communication system has to enable FU's to communicate w M each other independently from specific hardware solutions or operating systems.
LAN Local Area Network if. interface Architecture for a communication system for control-internal information interchange
b-
m - difficult to extend E unpredictable behaviour in m 4 errw situations 3 - difficuH to understand 8 - difficult to document managrnent and e m d i n g within amlication
- high expenditure for first implementation
- time behaviour not alwavs
-
Fioure 7; Comparison of methods for information modelling Based on the transport system an application entity (AE) with an application interface is defined for application specific information interchange. It has to be decided how information is mapped to messages. In principle two approaches are possible: A first possibility is to define for each piece of information a specially taylwed message which can be directly transferred by the GTE. Although this solution offers best perlormance and fast results in a first implementation it implies a number of grave disadvantages (Fig 7a). A second possibility is to classify the information exchanged between FU's and to define generic information models onto which information is mapped. These guarantee that similar information is always accessed in the same way. The structuring of information can best be achieved by using objectoriented information models in connection with finite state machines. The available information is structured into objects which represent each a certain aspect of an FU and can be accessed via the FU's service access point. Each object contains a number of attributes that represent the information accessible from external and a set of services to access, modify etc. the attributes. Finite state machines describe the relationship between invoked services, state transitions and produced output. Similar objects are put together into object classes which render an abstract model for objects by defining a fixed set of attributes, services, states and state transitions.
F
m
Extended clienVserver relationship
451
'
Services are invoked by sending requesf messages and on the termination of the execution of a service a response message is generated containing the results. An FU can at the same time own objects and offer services thus acting as a sewer and also invoke services of other FU's thus acting as a client (Fig. 8a). In addition to the 'classic' clienVserver relationship here a server can also unsollcitedly inform cllents about object-related events. To achieve this the server sends report messages to clients that are confirmed by them through report response messages (Fig. 8b). Figure 7b shows the advantages of object-oriented information models. They are though only useful d R is possible to map all the needed information onto the defined models and object classes. Therefore R is important to collect and classrfy the information to be interchanged before defining models and object classes. The object classes then speclfied define the generic framework for information interchange which is however not sufficient to achieve the ability to interchange FU's of the same type. For this, instances of the specdied object classes have to be defined and d necessary be standardized.
Object classes and servtces for NC
In a lirst step an NC system can. with respect to decentralisation and standardization, be decomposed into the following 5 major FU's: manmachine control, motion control, logic control, process control and external communication. After a collection and classification of the information interchanged between these FU's six object classes are defined that cover all the interchanged information (Fig. 9). The object class Functlonal Unit (FU) manages the overall behaviour of an FU. The object class Data Access serves for read and write access to structured data. In addition to normal read and wite access the objects are able to cyclically report their content to other FU's. The object class Process Control is used to control tasks and processes within an FU. It contains a generic state machine for processes with states like running or stopped. For each individual object a specific state machine can be configured out of the generic one and supplied with functions for state transitions. The object class Evenf Management is used for event reporting and the object class File Access supports message-based file access. Timn
1
TC
I
Tt
I
Tt
I
Ts lTsumlTsurnl
Tc mean execution time in the client's application layer Tt mean transmission time (request + response) Ts mean execution time in the server's application layer Tsum = Tc + Tt + Ts (all times measured in msec) mernxshared memory TCP=TCP/IP transport system Foure 1Q; Response times of the communication system
The communication system described was implemented on different hardware platforms (Motorola 68030 processor board and Intel 80386 personal computer) to support information interchange between the
452
above mentioned five major FU's of an NC system. Time measurements (fig. 10) with TCP/IP and shared memory as transport systems show that the mechanisms and protocols developped are suitable for information interchange within controls even in distributed systems connected via Ethernet and TCPllP as the transport system. §
ODen Svstem Arch itecture for C Svstems (OSACA)
Automatim
The motivation for a joint action between machine tool and control manufacturers to specify an open control system was given in chapter 2. This is also the reason for starting the OSACA project. It will develop a strongly modular and highly configurable concept for control systems to achieve a fast and cost-efficient adaption to new problems. Work will also include the specification of mechanisms for machine tool manufacturers to integrate their own functionalities into the controls without having to disclose their specific know-how. The main goal of the OSACA project is the definition of a hardware-independent reference architecture for numerical machine tool equipment including the functionalities of numerical controls (NC), robot controls (RC), programmable logic controls (PLC) and cell controls (CC). This will build a framework consisting of functional units and their interfaces, communication protocols and mechanisms, and interfaces to operating and database systems. The OSACA reference model will form a common base for standard numerical and robot controls up to sophisticated cell controls including e.g. tool- and workpiece-handling systems. It will be open for the integration of new functionalities and for the use of new computing equipment. Project work will include a detailed analysis of the state of the art as well as of user needs and will lead to implementation guides for control and machine tool vendors. Prototypes will be implemented to validate project results. Demonstrations will be given to promote the new architecture. Project work will not include development of new hardware components, communication. operating or database systems. Instead of all that existing standards will be used whereever possible. The knowledge about user needs and the technology gained from the project will be used to work with national, European and international standardization bodies to ensure representation of European industrial requirements and achieve widely acceptable specifications. OSACA will result in shortening the development time. increased flexibility for the adaption of controls to the special demands of machine tools and manufacturing cells. Costs for development, adaption, commissioning, training, documentation and maintenance will be reduced. The project has been started in May 1992 wrth a duration of 3 years. The consortium comprises European control vendors, machine tool manufacturers and research institutes from France, Germany, Italy, Spain and Switzerland.
7 ConchsiQn Despite all conventions and ingenious technical solutions, the advantage of open systems for the user as well as for the manufacturer strongly depends on the degree of uniformity of the components of different manufacturers and their general use. Their degree of uniformity determines which services can be done when combining the components and their general use determines how many users have accass to these components. Both factors, however, can be determined neither by the individual manufacturer nor by the individual user.
(1) Pritschow, G., 1990, Automation Technology - On the way to an open
system architecture, Robotics B Computer Integrated Manufacturing, 1/2:103-111. (2) Pritschow, G., Miller, J., 1992, Entwicklung einer modularen numerischen Steuerung mit einheitlich strukturierten Funktionsmodulen, Maschinennahe Steuerungstechnik in der Fertigung, 3-18.