- Email: [email protected]
Distributed Objects for Real-time Control Systems
Copyright © IFAC 12th Triennial World Congress, Sydney, Australia, 1993
DISTRIBUTED OBJECTS FOR REAL-TIME CONTROL SYSTEMS M. Fabian and B. Lennartson Control Engineering Laboratory, Chalmers University of Tec!mology, S-4]2 96 Goreborg, Sweden
Abstract In this paper we will show how object-oriented techniques can be used for the structuring and implementation of large real time control systems. We map the physical system into a set of selfcontained software models - internal resources - that interact through high-level messages. These objects encapsulate specific control aspects from the synchronization necessities of the overall system. The synchronization is administered by an application-specific entity - a controller. We further argue that this controller is best implemented as a distributed object, leading to a productrelated view of the system. Such a controller can be generalized, driven by adaptable recipes that describe the workprocess, giving a high-level implementation mechanism specifically developed for expressing distributed control of fabrication processes. Keywords Discrete event systems, Real time control, Object orientation, Distributed control, Finite automata, Process industry control
natural way, removing any intermingling of the separate devices' specific control structures. Furthermore, the scheme gives reusability between applications - each resource is a closed unit, exhibiting a well-defined interface towards the outside world. The high-level messages make the models adaptable to specific hardware details, not visible from the outside; only the resource itself knows its inner workings and these can be changed while the interface remains constant.
1. INTRODUCTION The current trend in implementation of real-time discrete-event control-systems offers general concepts on a relatively low level. Logical functions and sequences are usually the only available programming constructs, see SFC (1986). These mechanisms provide no, or little, means for hiding implementational matters from the usage of the implemented functionality. Also, they do not cater for reusability, nor make any provision for describing the synchronization aspects of the control of the global fabrication process at a sufficiently high abstraction-level.
The message-interaction also relaxes the coupling between the devices which further increases the reusability and extendibility of the system. The internal resources can be raised to equal levels of 'intelligence', whereby a synchronizing entity only has to consider high-level messages distinct from the low-level functions needed to implement this intelligence. The flexibility of the system is thus raised as the sequence through the system is not fixed, not dependant on the included objects.
A real time control system can be seen as consisting of two distinct but interconnected parts. On one hand we have the physical system, the hardware performing the actual processing, composed of a number of individual subsystems, recursively consisting of sub-subsystems in a hierarchical manner. On the other hand there is the control system, which is to issue control signals based on sensor-signals, thereby controlling, synchronizing and monitoring the physical system. Obviously there exist some kind of mapping, implicit or explicit, between (parts of) these two systems. We maintain that this mapping should be explicitly expressed, by a set of internal software models of the physical subsystems - self-contained, concurrently executing internal resources, communicating with messages.
In this paper we will show how object-oriented principles can be used to build such software models, based on the ability to extract general behavior into reusable entities offering generalized functions on a high abstraction-level. These functions utilize lower level, specific services to implement that behavior, and communicate through messages carefully designed to express the synchronizing aspects of the system. A number of such objects have been designed, implemented and used for control of various fabrication systems. We will also discuss the design of the synchronizing controller, showing how decentralization can lead to a general reusable approach, resulting in reCipes on a high level describing the requested fabrication process. For spatial concerns specific details must be referred to
Such an approach brings about several appealing advantages that all have to do with the structuring and flexibility of the system. For one, it distributes the I/O-signals and thus decreases the combinatorial complexity that arises as the number of components increases. The encapsulation enforces a modularization that structures the system in a
705
Fabian (1992, 1993). The reader is also referred to Adiga (1989) for related results.
variables tracking the availability of the resources that make up the system. Tracking whether a resource is available or not is essentially a matter of tracing information about its current state whenever a resource is IDLE it is available.
2. INTERNAL RESOURCES For the sake of reusability it is imperative that each internal resource contains as little 'knowledge' as possible of the specifics of its corresponding physical device as well as of the other resources present within' the system. If such knowledge is explicit within the internal resource, replacing the corresponding physical device would naturally mean massive recoding of the internal resource. However, it would also mean that (at least parts of) the other internal resources would have to be recoded, since their explicit knowledge of the replaced device is no longer correct. Thus, the removal of applicationspecificity is crucial for the generation of reu.sa?le software components. This can be done by splittmg the internal resource into two distinct parts, a general and a specific part, and by separating the synchronization of the overall fabrication system, from the control of the individual devices.
A number of parallel sequences within the controller, would handle the moving of material between the physical devices and the supervising of these entities, by exchanging messages with the internal resources. In essence, the centralized controller would be eventdriven by the messages coming from the internal resources. This approach builds on a global view of the system and could thus be called plant-related. The controller keeps track of each device explicitly, which naturally results in a complex implementational structure - the controller must be able to perform several tasks in parallel. 3.2 Virtual products A fabrication process involves a flow of material that is refined. Raw material enters the process at one end and is output at the other end as ready-made products, which can be further refined by other processes. In a continuos process, such as paper-pulp production, the in- and outputs are a (more or less) steady continuos flow. Naturally this demands a large amount of continuos control. In a discrete event manufacturing system the in- and output flows consist of discrete workpieces. Thus discrete event control is of the essence here. Batch processes, finally, lies somewhere in-between the other two extremes and requires a mix of continuos and discrete event control. For the sake of clarity we will in the following discuss our approach from a discrete manufacturing system point-of-view, but we will eventually show that the scheme is also applicable to batch processes.
2.1 The general part The general part of the software model represents an abstract view of the resource, effected by some state automata or Petri net. This state machine must track the state of the physical device. The general part must therefore interact with the specific part, mapping messages between them, as the internal messages are only received by the general part. See Fabian (1992a) for further details on the general part. It is noteworthy that the general part is inheritable, thereby making the object adaptable and specializable. 2.2 The specific part The functionality promised by the general part has to be implemented somewhere, and this is the specific part's purpose. This part is tailored to. the requirements of the actual device. Within an obJectoriented system, the specific part can be coupled to the general part as a set of virtual functions . Inheritance of the general part together with replacement of the specific, virtual functions, then results in a feasible way to adapt a software model. An example: "this lathe is a machine (the general part) but with these specific control aspects (the specific part)" .
Studying the parallel sequences that const~tu~e the synchronization of the internal resources wlthm the centralized controller we can see that they actually make up one complete sequence for each type of product - study, for instance, a workcell and how a single workpiece moves through the ~st~m . Modeling each physical workpiece as a dlstmct product-unit lets us have multiple instances of virtual products (VP's) running simultaneously. Such a scheme distributes large parts of the controller within the system. The one, total worksequence that each workpiece goes through thus exists in a number of separate instances. Each VP routes its own path through the system in a single sequence with just one step active at a time, and consequently the physical workpiece moves through the physical system. In this way we no longer have ~o implement with parallelism explicitly in mind. ThIS simplifies each workpiece's control sequence - each VP sees only to its own route through the system. Thus we achieve a product-related view, where the individual workpieces are our major concern, see Fig. I.
3. THE CONTROLLER In our model the control system consists of a number of internal resources interacting through messages. This message-interaction must be synchronized by an application-specific controller for profitable work to be carried out. In the following, we will discuss a way to implement a general controller - moving the application-specificity to a more easily adaptable data-part. 3.1 Centralized controller A centralized controller has a global view of the entire workprocess, which can be used for internal synchronization. The controller would possess 706
The VP's are application-specific - their sequence depends on the layout of the physical system, the actual machining that is to be carried out upon the physical workpieces. Accordingly, there has also to exist some entity within the system to supervise and synchronize the VP's. This entity, still a centralized controller, could then be viewed as the general part of the controller, since the actual controller consists of this general part, as well as of the applicationspecific VP's. So, with this scheme even the controller is split into two parts, one general and one specific. The general part of the controller encompasses a structure similar to that of the general parts of the resources. It includes an operator interface, and gives an abstract view of the state of the system. The specific part of the controller on the other hand, comprises the VP's.
VP's obey a simple rule of 'no exit - no entry' will resolve most cases of potential deadlocks. A mutual resource, RI, must not be claimed, and subsequently used, unless a 'safe' resource is available for the client when R I is finished . In most cases this guarantees that a circular wait will not occur. This model of usage of the resources is consistent with the standard method of resource-usage in most concurrent software-systems, such as operating systems. In the cases that the 'no exit - no entry' rule does not suffice, algorithms can thus be borrowed from the computer science society to resolve deadlock problems within the control system, and hence in the physical system. Also, algorithms for synthesis of non-blocking controllers are available. See for instance Ramadge (1987).
3.4 General controller With the described distributed controller, every VP consists of a relatively simple message-sequence; 'send a request then wait for a response' is the essential building stone. These messages can be extracted from the actual sequence, and feeded to a general virtual product (GVP) capable of taking such a list of messages as input-data. This input-data would direct the GVP's route through the system, forming a recipe for the fabrication of such products.
Of course, distribution introduces new problems. The main problem in this case would be how to coordinate the use of the resources. We cannot coordinate the VP's by global variables tracking the resources IDLE-states, because the reading and setting of such variables may not be an atomic action, possibly resulting in two VP's trying two access the same mutual resource simultaneously. A solution to this problem can be found by distributing the coordination to the resources themselves. This can be done in a general and reusable way, by incorporating a booking procedure with each resource. To use a resource, every client (i.e. VP) must begin by booking the resource. If the resource is idle, it responds immediately, marking itself as booked. However, should the resource be booked by another client at the time, then no response is given. The attempted user will hang waiting for the resource to be available. When released by the current user, the resource sends a response to the next booker, saying that it is idle and available. (This last feature may of course be overridden if the client is not content with waiting for the resource.)
The centralized controller cannot without severe bookkeeping problems handle this scheme. It would behave like a single processor executing multiple programs simultaneously, dealing with multiple program locations. This not an unresolvable issue, but nonetheless it constitutes complexity problems that we can do without. Each of the distributed controllers that the VP's comprise, contain their own current program-location as an internal state. In essence they form a set of multiple processors, each executing a single program within its own memory space. Moreover, allowing for parametrizable collections of messages, we can implement even higher-level structures. By formalising such collections we gain a high-level language for implementing control and
Thus, a resource must first be claimed, can then be used, and is finally released by the client. Having the
Resource system
Specific part
Fig 1. The VP's route their own way through the control-system, using the resources to have the physical workpieces processed. The resource-system is a conglomerate of inter-working resources used as a single resource. Observe that the resource-system can incorporate its own VP's, most probably distinct from the 'higher-level' VP's. 707
synchronization of fabrication processes. In this respect the internal messages act as an assemblerlanguage, which the GVP interprets as a program. Thus recipes can be described in a facile, easily manageable way.
scheme emphasizes the separation of the synchronization aspects of the overall system, from the lower-level individual device control. The internal resources are then used by an application-specific controller to carry out the specified work. We have here discussed how virtual products can make this controller distributed, which facilitates implementation of control systems. This distributed controller acts as multiple processors, each executing a single program for each physical workpiece within its own memory space, utilizing the resources to accomplish useful work.
These high-level recipes can be stored in a global database, with sub-recipes being references into that database. Such named references makes the recipes even more adaptable, since we can change the entire recipe at that location as long as the location remains the same. With a data-base manager even this is no requisite.
Such a distributed controller can be implemented as a general unit, with worksequences given as parametrizable recipes, further raIsmg the implementational level. These recipes can be stored in a database, and would contain references to other recipes for adaptability. These lower-level recipes are then data, or executables, governing the actions of the resources on the workpieces.
3.4 Hierarchies With the described scheme it is feasible to put the resources and the recipes into hierarchical structures. Resources most aptly used together can be encapsulated with a local controller to form a resource-system composed of sub-resources, see Fig l. This distributes control-structures even further than the mere separation of general and specific parts within the resources. Likewise, the recipes can be hierarchically decomposed, with functionality on higher levels implemented by lower-level functions . A recipe governing the actions of a resource-system, thus consists of sub-recipes for the sub-resources.
Coming research includes applying techniques for automatic synthesis of the controller according to some formal specification of the system behavior. 5. ACKNOWLEDGEMENTS We thank professor Bo Egardt, Michael Tittus and Klas Wallenius, all active at our department, for enlightening discussions around the presented topics.
4. APPLICA nONS AND CONCLUSIONS A number of physical and conceptual case studies has been carried out according to the principles described above. The resulting reusable software components are described in Fabian (1993).
6. REFERENCES Adiga, S., (1989). Software Modelling of Manufacturing Systems: A Case for an Object Oriented Approach, Annals of Operations Research, Vol. 17, No. 1-4, pp 363-378
4.1 Manufacturing Systems Our main point of concern has been manufacturing systems, and control of a small manufacturing cell has been carried out. The cell consists of three NCmachines serviced by a robot, see Fabian (1992a).
Fabian, M., B. Lennartson, (1992a). Control of Manufacturing Systems: an Object Oriented Approach, Pre-prints of the 7th IF AC Symposium on Information Control Problems in Manufacturing Technology, May 25-28 Toronto
4.2 Batch Processes A batch process is normally less flexible than a manufacturing system. The physical devices are not only connected by information flows, but also physically; tanks and reactors are connected by valves and pipes, etc. However, a strong separation between the functions of the batch system and the usage of these functions has been advocated. Such a separation typically results in a recipe identical to what we have described above. Thus, though our approach has been developed from a manufacturing point of view, it is equally suitable for control of batch processes, see Fabian (1993).
Fabian, M., B. Lennartson, (1992b). Object Oriented Structuring of Real Time Control Systems, Preprints of the 31st IF AC Conference on Decision and Control, Dec. 16-18, Tucson, Arizona Fabian, M., B. Lennartson, (1992c). Object-Oriented and Distributed Control of Manufacturing Systems (internal report), Control Eng. Lab., Chalmers University of Technology, Goteborg Fabian, M., (1993). Reusable Software Components for Structuring Real-time Control Systems, Technical Report l43L, Control Eng. Lab., Chalmers University of Technology, Goteborg
4.3 Conclusions and further research We have shown how object-oriented principles can be used for the structuring of real time systems. For reusability and flexibility we model the external devices as internal objects, comprising two distinct parts - a general and a specific part. The general part is common for all units of one and the same type, and it incorporates a state machine that keeps track of the external object's internal state. The specific part is tailored to a specific make, model etc. This
Ramadge, P.l , W.M. Wonham, (1987). Supervisory Control of a Class of Discrete Event Processes, SIAM Journal of Control and Optimization, Vol. 25, No 1, September 1987 SFC, (1987). Standard for Programmable Controllers - Part 3: Programming Languages, IEC SC65NWG6, Working Draft
708
DISTRIBUTED OBJECTS FOR REAL-TIME CONTROL SYSTEMS M. Fabian and B. Lennartson Control Engineering Laboratory, Chalmers University of Tec!mology, S-4]2 96 Goreborg, Sweden
Abstract In this paper we will show how object-oriented techniques can be used for the structuring and implementation of large real time control systems. We map the physical system into a set of selfcontained software models - internal resources - that interact through high-level messages. These objects encapsulate specific control aspects from the synchronization necessities of the overall system. The synchronization is administered by an application-specific entity - a controller. We further argue that this controller is best implemented as a distributed object, leading to a productrelated view of the system. Such a controller can be generalized, driven by adaptable recipes that describe the workprocess, giving a high-level implementation mechanism specifically developed for expressing distributed control of fabrication processes. Keywords Discrete event systems, Real time control, Object orientation, Distributed control, Finite automata, Process industry control
natural way, removing any intermingling of the separate devices' specific control structures. Furthermore, the scheme gives reusability between applications - each resource is a closed unit, exhibiting a well-defined interface towards the outside world. The high-level messages make the models adaptable to specific hardware details, not visible from the outside; only the resource itself knows its inner workings and these can be changed while the interface remains constant.
1. INTRODUCTION The current trend in implementation of real-time discrete-event control-systems offers general concepts on a relatively low level. Logical functions and sequences are usually the only available programming constructs, see SFC (1986). These mechanisms provide no, or little, means for hiding implementational matters from the usage of the implemented functionality. Also, they do not cater for reusability, nor make any provision for describing the synchronization aspects of the control of the global fabrication process at a sufficiently high abstraction-level.
The message-interaction also relaxes the coupling between the devices which further increases the reusability and extendibility of the system. The internal resources can be raised to equal levels of 'intelligence', whereby a synchronizing entity only has to consider high-level messages distinct from the low-level functions needed to implement this intelligence. The flexibility of the system is thus raised as the sequence through the system is not fixed, not dependant on the included objects.
A real time control system can be seen as consisting of two distinct but interconnected parts. On one hand we have the physical system, the hardware performing the actual processing, composed of a number of individual subsystems, recursively consisting of sub-subsystems in a hierarchical manner. On the other hand there is the control system, which is to issue control signals based on sensor-signals, thereby controlling, synchronizing and monitoring the physical system. Obviously there exist some kind of mapping, implicit or explicit, between (parts of) these two systems. We maintain that this mapping should be explicitly expressed, by a set of internal software models of the physical subsystems - self-contained, concurrently executing internal resources, communicating with messages.
In this paper we will show how object-oriented principles can be used to build such software models, based on the ability to extract general behavior into reusable entities offering generalized functions on a high abstraction-level. These functions utilize lower level, specific services to implement that behavior, and communicate through messages carefully designed to express the synchronizing aspects of the system. A number of such objects have been designed, implemented and used for control of various fabrication systems. We will also discuss the design of the synchronizing controller, showing how decentralization can lead to a general reusable approach, resulting in reCipes on a high level describing the requested fabrication process. For spatial concerns specific details must be referred to
Such an approach brings about several appealing advantages that all have to do with the structuring and flexibility of the system. For one, it distributes the I/O-signals and thus decreases the combinatorial complexity that arises as the number of components increases. The encapsulation enforces a modularization that structures the system in a
705
Fabian (1992, 1993). The reader is also referred to Adiga (1989) for related results.
variables tracking the availability of the resources that make up the system. Tracking whether a resource is available or not is essentially a matter of tracing information about its current state whenever a resource is IDLE it is available.
2. INTERNAL RESOURCES For the sake of reusability it is imperative that each internal resource contains as little 'knowledge' as possible of the specifics of its corresponding physical device as well as of the other resources present within' the system. If such knowledge is explicit within the internal resource, replacing the corresponding physical device would naturally mean massive recoding of the internal resource. However, it would also mean that (at least parts of) the other internal resources would have to be recoded, since their explicit knowledge of the replaced device is no longer correct. Thus, the removal of applicationspecificity is crucial for the generation of reu.sa?le software components. This can be done by splittmg the internal resource into two distinct parts, a general and a specific part, and by separating the synchronization of the overall fabrication system, from the control of the individual devices.
A number of parallel sequences within the controller, would handle the moving of material between the physical devices and the supervising of these entities, by exchanging messages with the internal resources. In essence, the centralized controller would be eventdriven by the messages coming from the internal resources. This approach builds on a global view of the system and could thus be called plant-related. The controller keeps track of each device explicitly, which naturally results in a complex implementational structure - the controller must be able to perform several tasks in parallel. 3.2 Virtual products A fabrication process involves a flow of material that is refined. Raw material enters the process at one end and is output at the other end as ready-made products, which can be further refined by other processes. In a continuos process, such as paper-pulp production, the in- and outputs are a (more or less) steady continuos flow. Naturally this demands a large amount of continuos control. In a discrete event manufacturing system the in- and output flows consist of discrete workpieces. Thus discrete event control is of the essence here. Batch processes, finally, lies somewhere in-between the other two extremes and requires a mix of continuos and discrete event control. For the sake of clarity we will in the following discuss our approach from a discrete manufacturing system point-of-view, but we will eventually show that the scheme is also applicable to batch processes.
2.1 The general part The general part of the software model represents an abstract view of the resource, effected by some state automata or Petri net. This state machine must track the state of the physical device. The general part must therefore interact with the specific part, mapping messages between them, as the internal messages are only received by the general part. See Fabian (1992a) for further details on the general part. It is noteworthy that the general part is inheritable, thereby making the object adaptable and specializable. 2.2 The specific part The functionality promised by the general part has to be implemented somewhere, and this is the specific part's purpose. This part is tailored to. the requirements of the actual device. Within an obJectoriented system, the specific part can be coupled to the general part as a set of virtual functions . Inheritance of the general part together with replacement of the specific, virtual functions, then results in a feasible way to adapt a software model. An example: "this lathe is a machine (the general part) but with these specific control aspects (the specific part)" .
Studying the parallel sequences that const~tu~e the synchronization of the internal resources wlthm the centralized controller we can see that they actually make up one complete sequence for each type of product - study, for instance, a workcell and how a single workpiece moves through the ~st~m . Modeling each physical workpiece as a dlstmct product-unit lets us have multiple instances of virtual products (VP's) running simultaneously. Such a scheme distributes large parts of the controller within the system. The one, total worksequence that each workpiece goes through thus exists in a number of separate instances. Each VP routes its own path through the system in a single sequence with just one step active at a time, and consequently the physical workpiece moves through the physical system. In this way we no longer have ~o implement with parallelism explicitly in mind. ThIS simplifies each workpiece's control sequence - each VP sees only to its own route through the system. Thus we achieve a product-related view, where the individual workpieces are our major concern, see Fig. I.
3. THE CONTROLLER In our model the control system consists of a number of internal resources interacting through messages. This message-interaction must be synchronized by an application-specific controller for profitable work to be carried out. In the following, we will discuss a way to implement a general controller - moving the application-specificity to a more easily adaptable data-part. 3.1 Centralized controller A centralized controller has a global view of the entire workprocess, which can be used for internal synchronization. The controller would possess 706
The VP's are application-specific - their sequence depends on the layout of the physical system, the actual machining that is to be carried out upon the physical workpieces. Accordingly, there has also to exist some entity within the system to supervise and synchronize the VP's. This entity, still a centralized controller, could then be viewed as the general part of the controller, since the actual controller consists of this general part, as well as of the applicationspecific VP's. So, with this scheme even the controller is split into two parts, one general and one specific. The general part of the controller encompasses a structure similar to that of the general parts of the resources. It includes an operator interface, and gives an abstract view of the state of the system. The specific part of the controller on the other hand, comprises the VP's.
VP's obey a simple rule of 'no exit - no entry' will resolve most cases of potential deadlocks. A mutual resource, RI, must not be claimed, and subsequently used, unless a 'safe' resource is available for the client when R I is finished . In most cases this guarantees that a circular wait will not occur. This model of usage of the resources is consistent with the standard method of resource-usage in most concurrent software-systems, such as operating systems. In the cases that the 'no exit - no entry' rule does not suffice, algorithms can thus be borrowed from the computer science society to resolve deadlock problems within the control system, and hence in the physical system. Also, algorithms for synthesis of non-blocking controllers are available. See for instance Ramadge (1987).
3.4 General controller With the described distributed controller, every VP consists of a relatively simple message-sequence; 'send a request then wait for a response' is the essential building stone. These messages can be extracted from the actual sequence, and feeded to a general virtual product (GVP) capable of taking such a list of messages as input-data. This input-data would direct the GVP's route through the system, forming a recipe for the fabrication of such products.
Of course, distribution introduces new problems. The main problem in this case would be how to coordinate the use of the resources. We cannot coordinate the VP's by global variables tracking the resources IDLE-states, because the reading and setting of such variables may not be an atomic action, possibly resulting in two VP's trying two access the same mutual resource simultaneously. A solution to this problem can be found by distributing the coordination to the resources themselves. This can be done in a general and reusable way, by incorporating a booking procedure with each resource. To use a resource, every client (i.e. VP) must begin by booking the resource. If the resource is idle, it responds immediately, marking itself as booked. However, should the resource be booked by another client at the time, then no response is given. The attempted user will hang waiting for the resource to be available. When released by the current user, the resource sends a response to the next booker, saying that it is idle and available. (This last feature may of course be overridden if the client is not content with waiting for the resource.)
The centralized controller cannot without severe bookkeeping problems handle this scheme. It would behave like a single processor executing multiple programs simultaneously, dealing with multiple program locations. This not an unresolvable issue, but nonetheless it constitutes complexity problems that we can do without. Each of the distributed controllers that the VP's comprise, contain their own current program-location as an internal state. In essence they form a set of multiple processors, each executing a single program within its own memory space. Moreover, allowing for parametrizable collections of messages, we can implement even higher-level structures. By formalising such collections we gain a high-level language for implementing control and
Thus, a resource must first be claimed, can then be used, and is finally released by the client. Having the
Resource system
Specific part
Fig 1. The VP's route their own way through the control-system, using the resources to have the physical workpieces processed. The resource-system is a conglomerate of inter-working resources used as a single resource. Observe that the resource-system can incorporate its own VP's, most probably distinct from the 'higher-level' VP's. 707
synchronization of fabrication processes. In this respect the internal messages act as an assemblerlanguage, which the GVP interprets as a program. Thus recipes can be described in a facile, easily manageable way.
scheme emphasizes the separation of the synchronization aspects of the overall system, from the lower-level individual device control. The internal resources are then used by an application-specific controller to carry out the specified work. We have here discussed how virtual products can make this controller distributed, which facilitates implementation of control systems. This distributed controller acts as multiple processors, each executing a single program for each physical workpiece within its own memory space, utilizing the resources to accomplish useful work.
These high-level recipes can be stored in a global database, with sub-recipes being references into that database. Such named references makes the recipes even more adaptable, since we can change the entire recipe at that location as long as the location remains the same. With a data-base manager even this is no requisite.
Such a distributed controller can be implemented as a general unit, with worksequences given as parametrizable recipes, further raIsmg the implementational level. These recipes can be stored in a database, and would contain references to other recipes for adaptability. These lower-level recipes are then data, or executables, governing the actions of the resources on the workpieces.
3.4 Hierarchies With the described scheme it is feasible to put the resources and the recipes into hierarchical structures. Resources most aptly used together can be encapsulated with a local controller to form a resource-system composed of sub-resources, see Fig l. This distributes control-structures even further than the mere separation of general and specific parts within the resources. Likewise, the recipes can be hierarchically decomposed, with functionality on higher levels implemented by lower-level functions . A recipe governing the actions of a resource-system, thus consists of sub-recipes for the sub-resources.
Coming research includes applying techniques for automatic synthesis of the controller according to some formal specification of the system behavior. 5. ACKNOWLEDGEMENTS We thank professor Bo Egardt, Michael Tittus and Klas Wallenius, all active at our department, for enlightening discussions around the presented topics.
4. APPLICA nONS AND CONCLUSIONS A number of physical and conceptual case studies has been carried out according to the principles described above. The resulting reusable software components are described in Fabian (1993).
6. REFERENCES Adiga, S., (1989). Software Modelling of Manufacturing Systems: A Case for an Object Oriented Approach, Annals of Operations Research, Vol. 17, No. 1-4, pp 363-378
4.1 Manufacturing Systems Our main point of concern has been manufacturing systems, and control of a small manufacturing cell has been carried out. The cell consists of three NCmachines serviced by a robot, see Fabian (1992a).
Fabian, M., B. Lennartson, (1992a). Control of Manufacturing Systems: an Object Oriented Approach, Pre-prints of the 7th IF AC Symposium on Information Control Problems in Manufacturing Technology, May 25-28 Toronto
4.2 Batch Processes A batch process is normally less flexible than a manufacturing system. The physical devices are not only connected by information flows, but also physically; tanks and reactors are connected by valves and pipes, etc. However, a strong separation between the functions of the batch system and the usage of these functions has been advocated. Such a separation typically results in a recipe identical to what we have described above. Thus, though our approach has been developed from a manufacturing point of view, it is equally suitable for control of batch processes, see Fabian (1993).
Fabian, M., B. Lennartson, (1992b). Object Oriented Structuring of Real Time Control Systems, Preprints of the 31st IF AC Conference on Decision and Control, Dec. 16-18, Tucson, Arizona Fabian, M., B. Lennartson, (1992c). Object-Oriented and Distributed Control of Manufacturing Systems (internal report), Control Eng. Lab., Chalmers University of Technology, Goteborg Fabian, M., (1993). Reusable Software Components for Structuring Real-time Control Systems, Technical Report l43L, Control Eng. Lab., Chalmers University of Technology, Goteborg
4.3 Conclusions and further research We have shown how object-oriented principles can be used for the structuring of real time systems. For reusability and flexibility we model the external devices as internal objects, comprising two distinct parts - a general and a specific part. The general part is common for all units of one and the same type, and it incorporates a state machine that keeps track of the external object's internal state. The specific part is tailored to a specific make, model etc. This
Ramadge, P.l , W.M. Wonham, (1987). Supervisory Control of a Class of Discrete Event Processes, SIAM Journal of Control and Optimization, Vol. 25, No 1, September 1987 SFC, (1987). Standard for Programmable Controllers - Part 3: Programming Languages, IEC SC65NWG6, Working Draft
708