DESIGN FRAMEWORK OF PLC-BASED CONTROL FOR RECONFIGURABLE MANUFACTURING SYSTEMS
Matthias Schreyer and Mitchell M. Tseng Department of Industrial Engineering and Engineering Management The Hong Kong University of Science & Technology Clear Water Bay, Kowloon, Hong Kong Email:
[email protected]
ABSTRACT: Design for reconfigurability becomes an important issue in manufacturing systems research because of the increasing needs of rapid response to the changing customer demands. The control system plays a key role in the reconfiguration of manufacturing systems. It enables the flexibility of the manufacturing system and determines the overall system performance. In particular, with the manufacturing control systems evolving to network-based systems and the Programmable Logic Controllers (PLC) as the processing kernel, the design of PLC systems has become an essential concern for the reconfigurability of modern manufacturing systems. This paper outlines a framework for reconfiguration design of PLC-based control systems. It consists of a concurrent design method, which integrates manufacturing and control system design by taking the recent technological progress of controller and communication hardware into account. The design framework is based on axiomatic design theory and involves formal modelling notations, a reusable component library, and a design method capable to support the quick reconfiguration of the control of the required manufacturing processes. Keywords: design methodology, concurrent engineering, manufacturing control system
INTRODUCTION The ability of a manufacturing system being reconfigurable addresses the rapid adaptation of its processes, operations, and control systems with respect to diverse, customized services or products. According to Koren et al. [1999], reconfigurability of manufacturing systems is a “design procedure in order to quickly adjust production capacity and functionality, exactly when needed.” Since this is a new perspective on manufacturing systems, reconfigurable manufacturing systems involve new design concepts and new computer-aided tools [NRC, 1999]. Essentially, these tools should support the combination of basic operations in a flexible and quick manner, thereby adapting to new sets of customer demands. Enabling technologies for reconfigurable manufacturing systems (RMS) consist of reconfigurable hardware and software components with a high degree of independence and a system configurator to compose those components timely and economically. This can be achieved with a modular architecture of hardware and software components that are stored in a repository. The composition and configuration of independent components require a concurrent engineering approach to the manufacturing system and the control system.
Programmable logic controllers (PLC) have been one of the important players in reconfigurable manufacturing systems and many other applications. Each year, more than 15 million PLC are sold worldwide with the hardware value alone accounted for more than 8 billion US dollars [Frost and Sullivan, 1995]. However, there are no systematic design approaches to deal with PLC based control systems to support the growing demand for flexibility and reconfigurability of manufacturing systems. This paper proposes a concurrent engineering approach to design PLC based control systems for reducing the uncertainty of managing the control software development, increasing the flexibility of the systems, and facilitating the use of simulation technology for systems validation. This approach considers a design framework involving systematic design principles, formal modelling techniques, and a generic software component library structure. Information technology including control and communication technology provides the underlying infrastructure, architecture, and algorithms for acquiring knowledge about the customers, products, and processes and converting it into operational knowledge for generating, scheduling and controlling manufacturing processes. Improved design methodologies will capture the descriptive knowledge in a concurrent way in order to support the efficient adaptation of the manufacturing processes. Reconfiguring processes will require a top-down design method that can compile manufacturing operations according to single incoming product orders. Achieving system’s flexibility will also depend on the capability to use this design method goal-oriented, quickly, and efficiently.
BACKGROUND The industry of PLC based manufacturing control systems encounters the software dilemma in the same as the entire software industry. Hardware performance and reliability are steadily increasing, while software design is proliferating into complex and unmanageable dimensions. The productivity in software design is still considered far from being adequate in the quick developing computer industry. Moreover, superimposing this dilemma, control systems are dedicated to interact with the environmental system in real-time. Two emerging trends in the manufacturing control systems have further accentuated the needs for a new approach to the control of manufacturing system. These are (1) the increasing demand for reconfiguration in response to changing products and processes, and (2) the seemingly growing complexity due to the need for more functionality. A common industrial control application often has more than 10.000 programmable control nodes. Accordingly, the cost of software has grown to be the dominant portion of the total system’s life cycle cost. For instance, in industrial automation systems, 80~90% of these costs are made up by software maintenance, debugging, adaptation and expansion to meet the changing needs [Simmons et al., 1998].
Programmable Logic Controllers (PLCs) PLCs are mostly used in manufacturing systems for operating and controlling material handling and transport. In existing flexible manufacturing systems, the PLC programs are fixed and there are rarely incentives for modification. In reconfigurable manufacturing systems, however, when a rearrangement of the material flow occurs, the controller hardware and the accompanied control programs have to be modified as well.
A PLC is a simple computing device encapsulating a programmable memory for the internal storage of instructions, input and output modules and a scanning logic to read the inputs and write the outputs periodically. Incoming signals from sensors are connected to input channels, and the output channels are linked to actuators or other peripheral devices. The PLC may also exchange data with parallel control nodes over a network. The PLC operates in a cyclic manner with three phases: (a) polling the input channels, (b) computing the outputs according to the program instructions, and (c) updating the outputs in the output channels.
Research in PLC Based Control Systems In academia, little work has been carried out into systematic design of PLC based control systems. Most of the work deals with how to model dynamic systems. Wonham [1988] has developed a comprehensive theory of discrete event systems modelling. Fodor [1998] has recently suggested to handle practical PLC based control problems by using such discrete event models. There are many other modelling techniques such as queuing theory, state machines, formal languages, and Petri nets. An excellent brief survey of discrete event modelling regarding PLC based control systems is given in Ben-Naoum et al. [1995] and the references therein. Hierarchical control structures and the application of artificial intelligence, such as agentbased systems, have taken complexity issues into consideration. Timeliness and controller performance are widely discussed in computer science community [Gooma, 1993; Kopetz, 1997; Burns and Wellings, 1997; Olderog, 1998]. Duran and Batocchio [1999] developed a prototypical PLC software generator interface by using objectoriented software specification techniques in reference to an earlier work of Bhatnagar and Linn [1990]. Halang and Kraemer [1992] reported a programming tool for designing and validating PLC software with function block diagrams based on a reusable component library. Their work was focussed on how to ease the programming of PLC based control systems, however, without introducing an integrated design context.
Integration of Control System Design into a Total System’s Design Approach The need to integrate the control design into a total and concurrent engineering design method has already been advocated by some researchers. An integrated control design approach for planning, scheduling, and monitoring the execution of the operation sequence in manufacturing systems has been presented by Chaar et al. [1991]. Boucher and Jafari [1992; 1994] proposed an integrated approach to manufacturing system design and controller design by employing SADT (IDEF-0) and Petri net notation. Based on their idea, Lopez et al. [1997] have presented a distributed network-based software architecture for a discrete manufacturing cell control. Software engineering issues such as graphical expression of the system control logic, simulation of the cell control logic during system design stage, graphical monitoring, simplicity of configuration control, and concurrent design and implementation of control software and manufacturing system have been discussed therein. Recent research projects focus on object-oriented modelling and design of control systems [Idelmerfaa and Richard, 1998; Liu et al., 1998; Suarez et al., 1998; Kovacs et al., 1999; Maione and Piscitelli, 1999] as part of an entire enterprise-modelling concept. Hereby, various modelling tools and methods like OOAD [Booch, 1994], OMT [Rumbaugh et al., 1991], and CORBA [OMG, 1999] are employed. Object-oriented modelling and design methods provide a very effective approach to penetrate design problems, especially in a domain involving substantial complexity. Likewise, they provide a natural mapping
of modern networked-based control architecture [Dilts et al., 1991] into corresponding distributed and uncoupled software architectures.
Current Practice in Software Development for PLC Bases Control In today’s industry, the software development process for PLC based control systems follows a rigorous sequential project methodology. Milestones of this design process are the (1) functional specification, (2) hardware design, manufacturing and procurement, (3) system development and integration, (4) factory acceptance test (FAT), and (5) delivery, documentation and installation. Software programming of PLCs is still predominantly conducted with classical relay ladder logic language. However, though control engineers can easily develop a program code for small applications, this language has some severe shortcomings. Ladder logic gives only a myopic view of the system processes, lacks semantic and conceptual integrity, and is not adequate for developing reusable software components. Industry and standardization committees have already recognized these problems and started to provide alternate programming languages such as sequential function charts and function block diagrams. The international standard IEC 61131, part 3, [IEC 61131-3, 1993] defines five languages in total: sequential function charts (SFC), ladder diagrams (RLL), function block diagrams (FBD), instruction list, and structured text. SFC also refers to the Petri-net-based language GRAFCET [IEC 60848, 1988]. Function block diagrams gain recognition in PLC programming due to its top-down modular decomposition concept [IEC 61499, 1997] and is still under development in the IEC TC65/WG6 [1998]. Recently, the acceptance of state languages to industrial practice is discussed. State languages are advantageous since they provide a direct cognitive mapping of the functionality to the design constructs (states). Still, the major barrier is that state transition models are nonconforming with the commonly used ladder logic diagrams. Experiences in industry have shown the difficulty to train control engineers using state languages [Rockwell Automation, 1999].
RECONFIGURATION DESIGN OF PLC-BASED CONTROL SYSTEMS Control engineers need a tool in order to accomplish the reconfiguration process of the control system alongside the hardware system and the desired functionality. Adding or removing sensors, actuators, or changing the computing hardware causes a change of parts of the software system or adaptation of configuration parameters. The framework of reconfiguration design for PLC based control system involves three subsystems: (1) A run-time system enables the execution of the configured control application. In PLC based control this run-time system is a build-in of the controller and cannot be changed. With the advent of distributed networked-based controller systems, the run-time system is also a part of the communication platform. For instance, in our research we use a Controller Area Network (CAN) based platform [ISO 11898, 1993]. (2) A communication system based on standardized protocols defines the type of connection, the type of messages that can be passed among the network nodes, and the profiles of the nodes in order to enable the information exchange. The type of connections defines the role between communicating network nodes, for instance master/slave, multi-master, or peer-to-peer. The message type determines the bit data transfer between the nodes. Each fieldbus system has its own proprietary message specification. A profile defines the interface of a physical device as viewed from the network. It manages information
about provided services and data format of the device, the configurable parameters, and an object model representing the internal software structure and object behaviour. Device profiles and application profiles are currently a subject of standardization in ISO 15745 [1999] for CAN based systems (part 2) and Profibus (part 3) systems. (3) A control configuration system is combining and instantiating software/hardware modules into a particular application. The control configurator provides a design methodology that guides the designer through the configuration process. The configuration process is based on a software component repository. Component based software consists of software components and software architecture. The software architecture is an enclosing abstract structure constituting the organization, control and communication between the components. The run-time and communication aspects have already been elaborated in many research projects as socalled open control architectures, for example, the Open System Architecture for Controls within Automation Systems (OSACA) project in Europe, the Open Modular Architecture (OMAC) in USA, and the Open System Environment for Controller Architecture in (OSEC) in Japan [Koren et al., 1996]. This kind of an open system platform serves as an underlying concept for our research enabling the integration, extension, substitution, and reuse of mechanical, electronic and software components. Since our research is related to CAN based systems we apply our framework to the open architecture of the Open DeviceNet Vendor Association [ODVA, 1997] on fieldbus level.
Concurrent Design Methodology Academic research in design theory deals with the search for scientific principles in order to make design repeatable, traceable and measurable. Meeting these requirements is not trivial because the question of how to describe and generalize the procedural and tacit knowledge accumulated by designer’s experience arises. There are a number of design methodologies evolved from different engineering fields such as system design, mechanical design and software design. However, a domain-specific design method for control software design has not been yet developed. To this end, our work started with the search for a suitable design methodology potentially applicable to PLC based control software design. Yien and Tseng [1996] compared various common accepted design methodologies in systems modelling and design and derived a conceptual methodology for integrated product and manufacturing systems applicable to CIM architectures. Their methodology follows the ideas of axiomatic design [Suh, 1990, 1999] because it is a simple and at the same time powerful tool. It provides a general set of design rules valid for all design situations. The axiomatic design forces the designer to think systematically from a top-down perspective and always takes the customer or user requirements into account. Axiomatic design has been developed originally for mechanical design problems, but it can be applied to nearly any other design problem, such as manufacturing system design, business process design, service process design and others. Axiomatic design provides a domain concept that consists of four domains capturing and connecting the different semantics of (1) customer requirements (CR), (2) functional requirements (FR), (3) design parameters (DP), and (4) process variables (PV). The domain concept let the designer distinguish between the whats on the left-hand side domain and the hows on the right-hand side domain. This is performed topdown by zigzagging between the domains creating congruent decomposition trees in each domain. The contribution of Yien and Tseng refers to the interrelationship of these particular four domains in an integrated and concurrent methodology for product design and manufacturing system design, respectively.
Compared to Suh’s basic 4-domain concept, their methodology indicates a concurrent product and system design approach being essential in reconfiguration design, when the system has to be adapted according to frequent changes of product and volume. The result of Yien’s work was a five-domain framework with (1) customer domain, (2) functional domain, (3) product domain, (4) process domain, and (5) resource domain. The domains in this framework have the following interpretations: The customer domain describes both the desired product attributes and the desired system attributes and performance issues. Similarly, the functional domain is divided into two sections. One section describes the functional requirements for the product, while the other section represents the functional requirements for the manufacturing system. A system’s functional requirement is, for instance, to ensure material transfer from location A to B. The process functional requirements are neutral with respect to any particular process which can achieve those requirements. The product functional requirements are mapped into the design parameters of the product domain. The product domain and the process functional requirements determine the process domain describing solution-neutral manufacturing and enterprise processes needed to make the product. According to the process selection, resources are selected in the resource domain. Resources can be organizational entities, production facilities, and particular manufacturing subsystems, or hardware components and human operators. Customer Domain
Functional Domain
Product Domain
Process Domain
Resource Domain
Product Design (PD)
CR
FR
DP
PV
CR - Customer Requirements FR - Functional Requirements DP - Design Parameter PV - Process Variables
Manufacturing System Design (MSD)
CR
FR
DP
PV
Control System Design (CSD)
CR
FR
DP
Control Domain
PV
Figure 1. Concurrent design methodology In a similar way, Sohlenius [1992] and Vallhagen [1996] developed a concurrent design methodology based on axiomatic design. Their framework introduces a clear separation between the product design stage (product world) and the manufacturing design stage (process world), indicating that the functional requirements of the processes logically depend on the product design. This kind of sequential nature of the design decision-making process is not as obvious in Yien’s five-domain framework. Thus, we want to take the opportunity to rearrange the domain framework in order to expose the partial sequential nature of the design process. Our framework decouples the domains back into the four basic domains (CR, FR, DP, and PV) for product design and manufacturing system design, respectively. The interrelationships between the domains of product design and manufacturing system design are shown in Figure 1. In this manner, the functional requirements for the manufacturing system are determined by the product outcome and the user requirements for the manufacturing system. These functional requirements in turn are mapped into a process-oriented but solution-neutral description, the design parameters of the manufacturing system.
Subsequently, suitable resources (resource domain) are selected, denoted as the PVs of the manufacturing system design. After choosing the process enabler, the question of how to operate these process enablers in order to achieve the desired behaviour and output of the manufacturing system arises. We may extend Yien’s fivedomain framework with an additional domain representing the control parameter. However, extending this framework in this simple way will also merge the functional requirements for the control system and manufacturing system, which have, in fact, a different source. Functional requirements for the manufacturing system result from product demand and the desired performance criteria such as throughput, lead-time et cetera. On the contrary, functional requirements for the control system are the processes, activities, control actions, and also requirements in terms of temporal and logical correctness. Therefore, we may decouple the design process into manufacturing system design and control system design and investigate the connectivity between these two procedures. In fact, the functional requirements for the control system design are merged from the DP domain (processes, activities) of the manufacturing system design procedure and the user requirements with respect to performance and correctness. The enabler of the processes and activities are particular hardware components (control devices), abstract objects or states (DPs). This representation will finally be mapped into the implementation domain of the control system (PV) depending on the selected control programming language and run-time platform.
Software Library for the Reuse of Control Software Reusable elements and modules are essential for reconfiguring control systems. Each level of abstraction may provide elements that can be reused. We may obtain reusability of functions, design parameters and modules, or even the reusability of software code on implementation level. A library of mechanical modules captures the structural, functional and behavioural information. Similarly, control software modules are systematically catalogued and stored for re-use in reference to these hardware modules. They are encapsulated into independent units containing structural, functional and behavioural information as well. Based on this library, new configurations are generated by selecting the components according to the desired performance and by associating the provided communication interfaces with each other. Predefined templates and building plans can help and speed up the configuration procedure. A graphical computer-aided configuration tool assists this procedure without any programming effort in lowlevel programming. A code generator is automatically producing the code for the target platform.
Reconfigurable Software Components Reconfigurable software components are modular entities with the highest degree of modularity [Stewart et al., 1997]. In other words, they are designed to be independent of replacement. A bus structure is a typical example of reconfigurable components. Each component has a specified interface for communicating with other modules alongside the bus and with a common communication language. Compared with objects in the object-oriented modelling and programming, components have a higher degree of independence. Objects may directly call methods from a second objects through the public interface of the second object. However, in case the methods of the second object are modified, the calling object might modify the call method as well. Components, however, are interacting with calling methods defined in the interface of the interacting components or specified in the communication language. The request of a particular data or methods is wrapped up inside a calling procedure or method.
Module Structure
Module Chart
Transport Module FRs
M.x Process Plan PF-A
n
n
Process Plan PF-B
n
Straight Segments
Control Unit Process Plan Prod. B1
[I.x0]
2
Event-Output-Port Event-Output-Port
[EQ.x0] [EQ.x1]
Input-Port
Output-Port
[Q.x0]
4
Proximity Sensor Modules/DPs
Event-Input-Port Event-Input-Port
T-Points
Process x Process y
[EI.x0] [EI.x1]
Pneumatic Actuator
Composite Module Process Module A
Network Model
State Chart
Process Module B Transport Module Elementary Module
S.x1
Electronic Element
t.x1: I.x1/Q.x1
Bar-Code Reader
t.x2: I.x2/Q.x2
Sensor
S.x2
Software Element
t.x22: I.x22/Q.x22
Reading Bar-Code Sensing Signal
S.x22
S.x21 Mechanical Element
t.x21: I.x21/Q.x21
Actuator
Figure 2. Component library
Formal Modelling In order to capture the descriptive knowledge, formal modelling representations that are appropriate to describe the structure and behaviour of the control system and the environmental system are selected. A natural way to represent structural system’s information is the object-based formalism. State languages are very powerful and suitable to describe the internal behaviour of reactive and non-deterministic systems and components. Our research will employ the object-oriented formalism combined with statechart formalism because both are hierarchically decomposable and capable to capture the semantic of different perspectives. The formal notations follow the definitions as described in Harel et al. [1996]. These notations are adjusted with PLC specific constructs such as I/O ports. Modules are derived form the manufacturing system architecture, whereby the statecharts describe the internal behaviour of the modules. Statecharts may also act as a linkage between the modular structure and the logic of the control system. Functional requirements can be mapped into objects and states during a natural top-down decomposition in the design procedure. States and objects are hereby considered as design parameter. A more detailed elaboration with respect to axiomatic design is given in [Schreyer and Tseng, 2000].
CONCLUSION Reconfigurability of manufacturing systems and their dedicated control systems become essential in today’s changing markets. The ability of a manufacturing system of being reconfigurable addresses system’s flexibility with respect to economical volume, functionality, and response time. A key enabler of reconfigurable manufacturing system is the control system that has to be reconfigured alongside the hardware changes. To this end, this paper has proposed a conceptual concurrent design framework for manufacturing and control design based on the ideas and terminology of axiomatic design. The proposed framework provides the system designer with effective guidelines to think in a top-down and systematic way so as to cope with system complexity. In order to integrate control system design process, the domain concept has been extended. According to the degree of reconfiguration the designer may step back to the
manufacturing design stage, or even to the product design stage so that the functional requirements of the control system can be adjusted for the rapid adaptation. Changing functional requirements are traceable from the product design stage to the control system design stage. This simplifies and partly automates the generation of new designs and control software. A control software library with configurable components and composed subsystems will assist the designer to configure the intended solution.
REFERENCES 1. Ben-Naoum L, Boel R, Bongaerts L, de Schutter B, Peng Y, Valckenaers P, Vandewalle J, and Wertz V. (1995), “Methodologies for discrete event dynamic systems: a survey,” Journal of the American Society for Horticultural Science, 36(4), pp.3-14. Publisher: Koninkliijke Vlaamse Ingenieursvereniging, Belgium. 2. Bhatnagar, S., and Linn, R. (1990), "Automatic programmable logic controller program generator with standard interface," Manufacturing Review, 3(2), l990, pp. 98-105. 3. Booch, G. (1994), Object-Oriented Analysis and Design with Applications, Benjamin/Cummings. 4. Boucher, T.O., and Jafari, M.A. (1992), “Design of a factory floor sequence controller from a high level system specification,” Journal of Manufacturing Systems, 11(6), pp. 401-417. 5. Burns, A., and Wellings, A. (1997). Real-Time Systems and Programming Languages, AddisonWesley, 2nd ed. Massachusetts. 6. Chaar, J.K., Volz, R.A., and Davidson, E.S. (1991), “An integrated approach to developing manufacturing control software,” Proceedings of the IEEE International Conference on Robotics and Automation, Sacramento, California, pp. 1979-1984. 7. Dilts, D.M., Boyd, N.P., and Whorms, H.H. (1991), “The evolution of control architecture automated manufacturing system,” Journal of Manufacturing Systems, 10, pp. 79-93. 8. Duran, O. and Batocchio, A. (1999), “Automatic PLC software generator with a natural interface,” International Journal of Production Research, 37(4), pp. 805-819. 9. Fodor, G.A. (1998), Ontologically Controlled Autonomous Systems: Principles, Operations, and Architectures, Kluwer Academic Publishers, Massachusetts. 10. Frost, and Sullivan (1995), “World programmable logic controller markets: increasing functionality promises continued growth,” Frost & Sullivan, http://www.plcopen.org/wwmarket. 11. Gooma, H. (1993), Software Design Methods for Concurrent and Real-Time Systems, AddisonWesley. 12. Halang, W.A., and Kraemer, B. (1992), “Achieving high integrity of process control software by graphical design and formal verification,” Software Engineering Journal, January, pp. 53-64. 13. Harel, 13. Idelmerfaa, Z., and Richard, J. (1998), “CIM systems modelling for control re-usability,” International Journal of Computer Integrated Manufacturing, 3, pp. 195-204. 14. IEC 60848 (1988), Preparation of Function Charts for Control Systems, International Electrotechnical Commission, Geneva. 15. IEC 61131-3 (1993), Programmable Controllers Part 3: Programming Languages, International Electrotechnical Commission, Geneva. 16. IEC 61499-1/2 (1997), Function Blocks for Industrial-Process Measurement and Control Systems, International Electrotechnical Commission, 65/216/CD and 65/217/CD, Geneva. 17. IEC TC65/WG6 (1998), Function Blocks for Industrial-Process Measurement and Control Systems – Part 1 - Architecture, (Working Draft), International Electrotechnical Commission, Technical Committee No.65: Industrial-Process Measurement and Control, Working Group 6. 18. ISO 11898 (1993), Road Vehicles – Interchange of Digital Information – Controller Area Network (CAN) for high-speed communication.
19. ISO 15745-1 (1999), Industrial Automation System and Integration – Open system Application Framework – Part 1: Generic Concepts, Elements, and Rules, ISO TC 184/SC 5/WG 5, preparatory standard for ISO 15745–1, SNZ Secretariat. 20. Jafari, M.A., and Boucher, T.O. (1994), “A rule-based system for generating a ladder logic control program from a high-level systems model,” Journal of Intelligent Manufacturing, 5, pp. 103-120. 21. Kopetz, H. (1997), Real-Time Systems – Design Principles for Distributed Embedded Applications, Kluwer Academic Publishers, Boston. 22. Koren, Y., Pasek, Z.A., Ulsoy, G., Benchetrit, U. (1996), “Real-time open control architectures and system performance,” Annals of the CIRP, 45(1), pp. 377-380. 23. Koren, Y., Heisel, U., Jovane, F., Morikawa, T., Pritschow, G. Ulsoy, G., and Van Brussel, H. (1999), ”Reconfigurable manufacturing systems,” Annals of the CIRP, 48(2), pp.1-14. 24. Kovacs, G.L. et al. (1999), “Application of software reuse and object-oriented methodologies for the modelling and control of manufacturing systems,” Computers in Industry, 39, pp. 177-189. 25. Liu, C.M., Chien, C.F., and Ho, I.Y. (1997), “An object-oriented analysis and design method for shop floor control systems,” International Journal of Computer Integrated Manufacturing, 11(5), pp. 379-400. 26. Lopez, J.M., Llorente, J.I., Burgos, A., and Martija, I. (1997), “ A software engineering method for the design of discrete manufacturing cell control,” International Journal of Computer Integrated Manufacturing, 10(1-4), 126-141. 27. NRC – National Research Council (1999), “Visionary manufacturing challenges for 2020,” American Chemical Society, May, pp. 49-56. 28. Object Management Group (OMG) (1999), http://www.omg.org. 29. ODVA (1997), DeviceNet Specification, Open DeviceNet Vendor Association, vol. 1 & 2. 30. Olderog, E.R. (1998), “Formal methods in real-time systems,” Proceedings of IEEE EuroMicro ’98, Berlin, pp. 254-263. 31. Rockwell Automation (1999), Discussion during Project Meeting with RA, Hong Kong. 32. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorenzen, W. (1991), Object-Oriented Modelling and Design, Prentice Hall. 33. Schreyer, M., and Tseng, M.M. (2000), “Hierarchical state decomposition for control software design based on axiomatic design theory,” First International Conference on Axiomatic Design, Cambridge. 34. Simmons, D.B., Ellis, N.C., Fujihara, H., and Kuo, W. (1998), Software Measurement, A Visualization Toolkit for Project Control & Process Improvement, Prentice-Hall. 35. Sohlenius, G. (1992), “Concurrent engineering,” Annals of the CIRP, 41(2), pp. 645-655. 36. Stewart, D.B, Volpe, R.A., Khosla, P.K. (1997), “Design of dynamically reconfigurable real-time software using port-based objects,” IEEE Transactions on Software Engineering, 23(12), pp. 759776. 37. Suh, N.P. (1990), The Principles of Design, Oxford University Press, New York. 38. Suh, N.P. (1999), Axiomatic Design: Advances and Applications, to be published by Oxford University Press, New York. 39. Vallhagen, J. (1996), “Axiomatic design applied to manufacturing systems design,” Proceedings of the 1996 ASME Design Engineering Technical Conference and Computers in Engineering Conference, Irvine, California, pp. 1-16. 40. Wonham, W.M. (1988), “A control theory for discrete event systems,” Advanced Computing Concepts and Techniques in Control Engineering, M.J. Denham, A.J. Laub (editors), Springer– Verlag, pp.129-169. 41. Yien, J.T, and Tseng, M.M. (1996), “A manufacturing systems design methodology,” Proceedings of the 3rd CIRP Workshop on Design and Implementation of Intelligent Manufacturing Systems, Tokyo, Japan, June 19-22, pp. 110-118.
