Design Patterns for Process Automation Systems

Transcription

1 Design Patterns for Process Automation Systems A dissertation for the degree of Doctor of Technical Sciences presented by Dipl.-Ing. Wolfgang Narzt submitted to the Johannes Kepler University Linz accepted on the recommendations of o.univ.-prof. Dipl.-Ing. Dr. Hanspeter Mössenböck o.univ.-prof. Dipl.-Ing. Dr. Gustav Pomberger Linz, July 2000

2

3 Abstract By now, European companies are the market leaders in the development of process automation software. Current numbers indicate, however, that this market position is going to change in favor of US and Far East companies. This thesis can be regarded as a contribution to keep the leading market position because it presents an innovative software architecture for process automation systems which promises a high reuse factor up to 70% and therefore helps to save time and costs for the development of future process automation software. Until now, software in this domain has been developed with traditional programming languages like Fortran or C, which restrict the reuse of software to a rather low level (source code and procedure libraries), whereas object-oriented techniques even allow to reuse the whole logic of a system. Design Patterns are considered as a very popular architectural guideline in objectoriented systems because they briefly describe a common way of implementing frequently appearing problems. This thesis presents five design patterns for different kinds of communication mechanisms occurring in process automation systems. They deal with the difficulties in telegram-based communication when telegrams (data streams) are transferred between different operating systems. The telegrams need to be converted to the data format of the target system. In addition, the design patterns offer a general technique to distribute the contents of the (converted) telegrams; and they provide a flexible, event-based architecture for data requests and commands in a distributed environment. The design patterns in this thesis have been implemented on Windows NT 4.0 with Microsoft Visual C and the CORBA implementation Orbix 2.3c for inter-process communication. A special configuration mechanism, based on a selfdefined meta information concept, even increases the power of the design patterns. It enables the users to customize the software without touching the source code. The applicability of the design patterns has finally been validated by tests under real-time conditions at the hot rolling mill of VOEST-Alpine Stahl Linz AG. They all fulfill the requirements in terms of efficiency, flexibility, adaptability, reuse and portability and can henceforth be considered as a platform for the development of future process automation software.

4

5 Acknowledgements I would like to thank all those persons who have directly or indirectly contributed to the successful elaboration of this thesis. My advisor Prof. Hanspeter Mössenböck deserves special thanks for his personal encouragement and competent scientific support. Despite his comprehensive work at the university, he has always found time for my personal concerns. I also want to express my gratitude to Prof. Gustav Pomberger, who has promoted my work at the REFORM project and who has introduced me to many companies and universities in Austria and abroad. Finally, Prof. Peter Rechenberg has been my great teacher in concerns of didactic skills. I have learned many considerable things from him. Very special thanks is due to my friend any colleague Joe Pichler, who has offered up many hours of his valuable time for fertile discussions. It was a pleasure to have a competent expert and simultaneously a good mate in the project team. I also owe many thanks to Klaus Pirklbauer, who has enabled my participation in the project and from whom I have learned a lot in concerns of managing a project. Martin Zwinz (alias Zwax) has been a valuable addition both in terms of scientific work and in spending our spear time. Not to forget Charly Artmann, who has often made our hard work more relaxed by his unsurpassed sense of humor. Chris Ertl, Didi Birngruber and Thomas Stranzinger have also contributed their big part that the project could be worked out in a pleasant atmosphere. Thanks a lot for that! Furthermore, I would like to express my acknowledgements to Herbert Exner, a very sociable and also economically skilled person. I was always surprised by his eloquent way of selling his opinion to the audience and also by his experienced knowledge about good restaurants and ancient wine. His contributors Ned Blurock and Harald Wahl have not minor been great partners in the REFORM project. Special thanks also belongs to our friends at VOEST Rupert Langer, Andreas Ortner, Erich (Joe) Fenzl, Harry Schmolmüller and Andreas Gewessler, who have provided a pleasant working environment and competent domain knowledge. Christian Schuderer has done a great job as the project manager. Besides his technical knowledge, he has always been a good friend for all of us. Very special thanks for that! I also want to thank all of our other colleagues at Siemens, Thomas Heimke, Andreas Geisler and Peter Balzer for their competent help and cooperation. The next persons in my long list of acknowledgements are our partners from the University of Hamburg. Prof. Heinz Züllighoven deserves special thanks for his encouragement of the commercial exploitation of the project. Henning Wolf and Stefan Roock have once more provided a good working climate within the project. It was always a great pleasure for all of us when our Swedish project partners and friends visited us in Austria. Janne Lindh has learned to appreciate and love the Austrian culture, and we had always a lot of fun together with him. I can tell the same about Mattias Nylen; we enjoyed his company very much! Unfortunately, Bo Hagerf has left the team too early. Last, but not least, I would like to thank my colleagues and friends at our department. Prof. Günther Blaschek has always been a competent contact person in scientific questions. Christian Rutzinger (soon Kenngott) was both professional aid and moral support during my work for this thesis. And finally, Rainer Lischka and Monika Scholl have always provided a good working atmosphere for all of us. Thank you all!

6

7 Contents 1 Introduction and Overview Motivation Results Outline Process Automation Systems OverallStructure Tasks Conventional Implementations Design Patterns Telegram Pattern Motivation Parsing the Telegram Extracting the Telegram Id Converting the Telegram Summary Dispatcher Pattern Motivation The Receiver Objects Dispatching Information Dispatcher Summary Condition Pattern Motivation Object Observation The Condition Class Summary I

8 3.4 Request Pattern Motivation The Value Dictionary The Request Class The Plant Configuring the Request Returning the Request Summary Instruction Pattern Motivation The Instruction Class Summary Conclusion Meta Information and Pattern Configuration Meta Information A Configuration Mechanism Configuring the Design Patterns The Design Patterns in Process Automation Software The Hot Rolling Mill Domain SoftwareArchitecture Modifications of the Design Patterns Run-Time Behavior and Memory Allocation Comparable Patterns Pipes and Filters Notification Repository Architecture Broker Client-Dispatcher-Server Summary Conclusion Critical Assessment FutureWork Bibliography 101 II

9 List of Figures 2.1 Automation Levels Tasks within Process Automation Systems Excerpt of the current VASL Automation Telegram Description Telegram Class Hierarchy Strategy Pattern for Reading Telegrams Attempt of a TelegramHandler Class TelegramId Class Hierarchy Pattern for Extracting the Telegram Id Extended Telegram Description TelegramConversion Generic Parsing Implementation Automatic Value Conversion Telegram Conversion Summary Telegram Pattern, Class Diagram Telegram Pattern, Object Diagram Dispatching Mechanism Arrays and Structures within a Telegram Receiver Class Hierarchy Dispatching Information Hierarchy Dispatching Information for the Telegram Structured Dispatching Information for Transient Objects Dispatching Information for Transient Objects Dispatcher Dispatcher Pattern, Class Diagram Dispatcher Pattern, Object Diagram Event-Driven Communication III

10 3.25 Observer Mechanism for all Classes Condition Object Condition Base Class Composite Conditions Condition Pattern, Class Diagram Condition Pattern, Object Diagram for a single Condition Condition Pattern, Object Diagram for compound Conditions Data Requests from remote Processes Value Dictionary Sending a Data Request Request Class Interface for the Mapping of Value Names to Holders Cloning a Request Properties of the Plant Value Descriptor Generic Template Interfaces for Data Retrieval Trigger Condition for Requests Request for Current Values Request for a Value Sequence Restoring the Semantics of a Request Requester Interface Request Pattern, Class Diagram Request Pattern, Object Diagram Wrapping an incompatible Model Interactive Operations from Remote Processes Instruction Class Instruction for Storing Values at Aggregates Instruction for Transient Objects Instruction Pattern, Class Diagram Instruction Pattern, Object Diagram Hooks for the Design Patterns in Process Automation Systems Meta Information Concept Meta Class ConfigurableObject Configuring Object References IV

11 4.5 Configuration Routine for the Telegram Handler Configuration Routine for the Telegram Configuration Routine for the Descriptor Hot Rolling Mill TasksfortheRoughingMillatVASL Separation of Telegram Pattern and Dispatcher Pattern Telegram Database Network Configuration CPU Usage for the Telegram Pattern CPU Usage for the Dispatcher Pattern Memory Usage for the Dispatcher Pattern Correlation between Strips and Value Objects in the Plant CPU Usage for the Request Pattern (MMI connected) CPU Usage for the Request Pattern (all components connected) Memory Usage for the Request Pattern Pipes and Filters Notification Repository Architecture Broker V

12

13 1 Chapter 1 Introduction and Overview It seems as if the techniques of modern software engineering [PB1996] already provide a common solution for any kind of problem occurring in the programmer s world. Today, nobody questions the advantages of object- and component-oriented programming [Str1997], [Sam1997], offering a generally agreed larger amount of flexibility, reuse and adaptability compared to conventional software development. In fact, these techniques are nowadays considered as state of the art. Nevertheless, they cannot be regarded as a guarantee for successful software development unless they are used properly. But how should a class or a component be designed so that it can be accepted as properly built? Many popular books try to guide the software developer through the design process by providing design patterns [GHJV1995], [Pre1994] for common problems. Design patterns make it easier to reuse successful design and architecture. Current design patterns address domain-independent problems such as creating, composing or decorating objects. There are hardly any design patterns for specific domains, though, such as manufacturing or process automation. This thesis introduces new design patterns primarily developed for the communication flow in process automation systems. They deal with various communication mechanisms and provide a flexible way to overcome the difficulties between different operating systems. The design patterns in this thesis cover a large area of problems occurring in nearly every automation system and can therefore be taken as a guide for the development of process automation software. 1.1 Motivation Every software developer has certainly had the feeling that a problem he is currently working on is familiar to him and he has worked out a solution for a similar problem in the past. A déjàvu like this is nothing unusual, as many problems appear similar in structure and logic in everyday life. For example, think of an editor for modifying HTML documents in various ways: A pure textual view lets the user conventionally edit a document, whereas a WYSI- WYG view gives a more convenient representation. Of course, both views should be displayed in parallel on the same document and it goes without saying that changes to one view should be reflected in all other views. This problem reappears in every editing tool and therefore demands a general strategy for its solution. Experienced

14 2 Chapter 1. Introduction and Overview software developers immediately recognize the MVC (model view controller) concept [KP1988] behind this problem and know that the observer design pattern [GHJV1995] provides a solution to it. Problems like this have led to the development of many efficient design patterns. Nevertheless, there is still a wide area of tasks without design patterns providing a satisfying solution. As an example, the domain of the process automation industry brings out problems whose solutions show a common pattern, but which are solved from scratch every time they appear. Even without a detailed knowledge of process automation software it is reasonable that the following examples in this domain long for an architectural guide: In most automation systems there is a clear separation between the involved tasks: Low-level tasks, controlling the underlying hardware, and high-level tasks, responsible for optimal throughput, quality etc., are executed separately on different computers and quite often even on different operating systems. Hence, communication within such a network is only possible by exchanging data telegrams (byte streams of predefined format). It is always hard work for the programmer to correctly build and split up these telegrams byte by byte. Sometimes, values within the telegrams have to be scaled because the sender process uses other units than the receiver process. And sometimes, different platforms and therefore possibly different byte ordering within the telegrams force the programmer to insert byte switching routines. But basically, there is no mental challenge in this task, it s just monotonous and highly error-prone. Consequently, the programmer would be released from a heavy burden if he had a design pattern for the telegram traffic problem enabling him to quickly perform the exhaustive telegram conversions and to decrease the probability of making mistakes. Sending telegrams is just one way of communication and used only when different operating systems prevent the use of more convenient techniques like remote method invocation through CORBA [Mow1995]. It should be obvious even to non-experts that process automation systems consist of several processes communicating with each other: A visualization process has to be supplied with data in the same way as a logging process, to name just two of them. Every process needs different data and is consequently designed with a unique interface to access the data. As in the previous example, it is hard work to collect the corresponding data floating around in the system. Scenarios like, I want to display the fifth data element from the second telegram in the visualization or, I need the average value computed between two specific time stamps are quite common and often lead to unsystematic implementations because it seems that there is no general implementation strategy behind them. It is just an accidental collection of data, tailored for a particular configuration, which appears to prevent a general solution. The scenario gets even worse when the software should be adapted to another automation system with a different telegram structure and different sets of data. Thus, it would be a great improvement if a design pattern for data requests could be taken as a guideline for the implementation, enabling all processes to request their data with one common mechanism. Summarizing the glimpse at the problems mentioned in this section unconditionally leads to the realization that the process automation industry is up to now confronted with tasks having no general architecture for their efficient solution. Although a couple of tools already support the software developer in particular tasks, most of them cannot satisfy the requirements of modern software development. As an example, WinCC is capable of visualizing a production process and keeping track of the produced material, but it does not offer an object-oriented implementation.

15 1.2. Results 3 Whereas the general software market provides dozens of design patterns for very common software problems, the domain-specific software market lamely walks behind. One reason for this is maybe the fact that most industrial software is confidential and never reaches the public market. There is no commonly valid statement about that. But it can be taken for granted, that process automation software is not mass software and doesn t bring out particular design strategies because every developer uses its own implementations. So, process automation software has been individually developed and adapted for every automation plant despite the fact that up to 70 percent of the software could be reused [Ref1999a]. Recent research projects have confirmed these figures and have set up a tendency supporting the development of flexible design strategies to overcome the lack of architectural guidelines in the domain-specific software market. 1.2 Results This thesis can be regarded as a first approach towards software development for process automation systems with well structured design patterns for domain-specific tasks. Basically, the design patterns refer to communication problems between processes and different operating platforms. They show several innovative ways of resolving the difficulties coming along with data exchange in process automation systems and simultaneously offer a satisfying solution for non-functional requirements like efficiency, flexibility, adaptability, reuse and portability. The design patterns in this thesis have successfully passed all examinations in a prototype implementation for the process automation system of the hot rolling mill [Sie1988] at VOEST-Alpine Stahl Linz AG in the course of the Esprit project REFORM [Ref1999a] (A Reusable Framework for Rolling Mills) and can therefore be considered as proven. Process automation systems always demand efficient implementations in order to fulfill near real-time requirements [ZA1995]. An incoming high frequency cyclic data stream, containing information about the current state of an automation plant, has to be processed in a predefined interval of time. Hence, the challenge for the development of all patterns in general was to design an architecture guaranteeing the required near real-time demand. Inter-process collaborations were identified as the bottleneck for the efficient implementation of process automation software which resulted in the design of a compact pattern interface. Keeping the interprocess traffic low and optimizing the data stream to be sent has turned out to be a good solution to resolve the bottleneck. The design patterns, specially developed for process automation systems, also stand in for a large amount of flexibility. Automation plants cannot be seen as static entities, always performing the same tasks and processing the same data. Rather, they have to be considered as dynamic structures, changing their environment in irregular time intervals. Moved sensors, additional measuring devices etc. always affect the corresponding software. So, it is essential to build upon a flexible software design enabling the programmer to easily and quickly react on changes in the system. In many cases, the design patterns presented here automatically can be adapted to distinct environments without modifying the code. The prototype implementation, mentioned above, has shown that minor changes in the plant could be adapted in just a few minutes even by the customer, whereas the same solution in the conventional implementation lasted significantly longer and had to be done by an expert.

16 4 Chapter 1. Introduction and Overview The prototype implementation has also proven the adaptability of the design patterns. Kept general in architecture and collaboration, the design patterns offer several hooks for the adaptation of concrete implementations. These hooks may be found in the derivation of new classes, as usual, or in simple configuration files enabling the user to initialize the software components without touching the implementation. Beyond the main design patterns for process automation software, this thesis additionally presents a selective configuration mechanism which enables the user to adaptively configure the design patterns to different needs of the customers. As a consequence, the combination of the presented design patterns and the configuration mechanism distinctly reduces the effort of writing new code for the adaptation of the software to new automation plants and therefore helps to save development time and costs. In certain respects, a high degree of reuse comes together with adaptability, for a design pattern can also be considered as reusable when it is easily adaptable for customer-specific requirements. Besides, it was one of the major goals to design a reusable architecture for process automation systems. The design patterns have been implemented with Microsoft Visual C++ on Windows NT in order to validate the functionality. Nevertheless, the architecture is platform-independent with a maximum amount of portability. The requirements for the implementation languages are quite common and can be fulfilled by almost every object-oriented language. It is the author s conviction, though, that Java in connection with the current libraries is still unqualified for the implementation because it is too slow for the run-time demands of process automation systems. Summarizing this section, the design patterns presented here offer a comprehensive guideline for the development of communication strategies in process automation software. Nevertheless, they only deal with a part of the functions and tasks appearing in process automation systems, so the overall topic is not fully covered in this thesis. The reader will get an insight into the general structure of process automation systems and will experience the collaborations among the involved processes. He will learn about automatic methods for object instantiation enabling the user to quickly build complex and fully functional object hierarchies without recompiling the code. In general, the design patterns in this thesis support the software developer in the construction of process automation software and represent a new approach in reducing development time and costs. 1.3 Outline The following chapters give a detailed view on the methods and techniques enabling the construction of a flexible software architecture for process automation systems. Chapter 2 gives a common introduction on automation systems. It presents the typical three layer architecture of automation systems and shows the major tasks, processes and collaborations within these layers. Furthermore, the chapter examines the structure of conventional software systems in this domain and brings out their difficulties and disadvantages. Chapter 3 represents the main part in this thesis introducing five innovative complex design patterns providing solutions for various communication problems occurring within process automation systems. The design patterns are actually made for the domain of process automation systems, but are kept general enough to be used in similar areas.

17 1.3. Outline 5 Chapter 4 enhances the flexibility of the design patterns by describing a highly sophisticated configuration mechanism allowing the users to adapt the design patterns to specific requirements without modifying the code. This goal is reached by the introduction of additional meta-information, which also leads to the ability to dynamically create objects from a class name given in a configuration file. Chapter 5 presents a concrete implementation of all listed design patterns for the hot rolling mill at VOEST-Alpine Stahl Linz AG. The feasibility of the (slightly modified) design patterns is shown here. Chapter 6 compares the approach of the design patterns in this thesis with other techniques for communication and tries to justify the development of the new design patterns. And finally, chapter 7 critically summarizes the design patterns and gives a glimpse on the future development in the domain of process automation software.

18

19 7 Chapter 2 Process Automation Systems The design patterns in this thesis have been developed for the domain of process automation systems. Thus, it is indispensable in the beginning to give a precise definition of the term process automation system, to show how it is embedded into the huge area of automation systems and which tasks are involved. The term process automation system is used for a variety of distinct components in industrial systems. Single computer-controlled machines are referred to as process automation systems as well as whole factory automation systems. [PPW1994] Basically, process automation systems control the manufacturing of industrial products. Their major task is to optimize both the quality and the throughput of the produced goods. In order to achieve these goals, the requirements to the software for such systems are high and have to cover near real-time demands. The following sections will give a deeper insight into the functions and the structure of process automation systems. 2.1 Overall Structure A process automation system is a self-contained part within an overall automation system, which is generally divided into three levels of inter-operating software systems [Sie1988] (see Figure 2.1). Figure 2.1: Automation Levels The top level is the production planning and control system responsible for planning and coordinating work tasks in advance. It determines a production schedule which has to be accomplished, controlled and pushed to an optimum by the underlying level 2 representing the process automation system. Finally, the fundamental base at level 1 is the basic automation system directly controlling the involved hardware.

20 8 Chapter 2. Process Automation Systems The reason for the pyramid-shaped structure of the three automation levels lies within the fact that the basic automation system causes the majority of the costs compared to the other automation levels. The costs for the remaining systems continually go down with increasing levels, explaining the pyramid-shaped format. Within the software of the different automation layers, we can identify a cyclic data flow (see Figure 2.1) starting at level 1, which passes all data accumulated at the production process (i.e. signals and measured values) to the process automation system at level 2. Here, the data is used to calculate setpoint values (e.g. a new production velocity) for the machines of the basic automation system in order to influence the production process. This step closes the cycle. The production planning and control system is regularly notified about the progress and if required modifies the schedule in order to optimize the production process. [NPPZ1998] 2.2 Tasks As already indicated, one of the major tasks of process automation software is to calculate setpoint values for the basic automation layer. However, process automation software consists of several event-driven tasks working in parallel and communicating mutually [Pir1994]. Figure 2.2 gives an overview on the major tasks appearing in the software of process automation systems. Figure 2.2: Tasks within Process Automation Systems Typically, process automation systems supervise a production line where the produced objects sequentially follow a predefined route. In order to keep track of the movements, material tracking (MT) represents an elementary task in process automation software. The purpose of material tracking is to logically follow the produced objects through the production line, but it is not always necessary to exactly know where the objects are. It is sufficient to know the current production location. It depends on the type of the production process, though, how precise

21 2.2. Tasks 9 this task has to be. Apart from the exactness of material tracking, recent design reviews on automation software show a trend towards increasing the intelligence of level 1 and shifting the responsibility of material tracking to the basic automation system [Ref1999a]. But the fact if material tracking is assigned to level 2 or rather to level 1 has no impact on the results of this thesis. The second core task besides material tracking is measured value processing (MVP) [LA1994], [Lan1996]. The purpose of measured value processing is to collect and store the incoming measured values (e.g. sensor states, temperature, speed, dimensions of the produced material, etc.) and to selectively prepare them for statistical calculations. This task strongly differs from one plant to another, for the group of data to be stored depends on the type of the production process which is controlled. But generally, every process automation system consists of a measured value processing part, providing methods to store and access values attained at the production process. These values are submitted as the input for various mathematical models calculating setpoint values for the basic automation system in order to control and optimize the production process. Usually, the mathematical models have continually evolved and contain the experience of the automation engineers. Modern techniques such as fuzzy logic [Kle1993], neuronal networks [Roj1996] or machine learning approaches [Blu1999] are on the advance, though. One example of a mathematical model is the pacing model [Sie1988] (also known as sequencing model), responsible for finding a strategy to optimize the throughput of the production process. It calculates a new production velocity. Another example is the wear model, supervising the conditions of the machines and ordering possible repairs. This model determines when a (part of a) machine is worn out. Any number of mathematical models may be connected to the core it just depends on the automation plant. Furthermore, process automation systems commonly offer a man machine interface (MMI) to let the operator interact with the system. It visualizes the production process and notifies the operator on important events and errors. It also offers the opportunity to actively intervene into the production course and control the system manually. Another significant task within a process automation system is the reporting and logging mechanism. All measured values, calculated values or exceptional conditions have to be reported for quality assurance and as a kind of feedback for the customer. Several types of data storage are possible: Whereas in former times a direct printout caused loads of paper, the possibilities nowadays range from simple ASCII files over HTML documents to object-oriented databases. There are no restrictions in the type of storage. All tasks presented so far concern internal functions within a process automation system. It is essential, though, to communicate with the outer world at level 1 and level 3, thus special connectivity tasks are responsible for establishing connections to the surrounding automation layers: The connection to the basic automation system at level 1 is generally based on exchanging data telegrams. A telegram is a compact byte stream which sequentially contains e.g. sensor states, the temperature measured by a particular device, the dimensions of the produced goods, etc. It comes quite frequently that there are different operating systems in the two automation levels or that the software was implemented by different vendors, so it has been proved as an appropriate technique to use telegrams for inter-process communication between level 1 and level 2. As a consequence, a telegram handler converts and interprets the incoming telegrams and distributes their contents within the core.

22 10 Chapter 2. Process Automation Systems In order to communicate with the production planning and control system, an additional communication channel has to be established, which turns out to be the connection to the level 3 above. Whether this connection is again telegram-based (like the connection to level 1) or if other techniques are involved, strongly depends on the automation plant and the corresponding hardware. However, some process automation systems miss this connection, because the communication to level 3 is not automated, yet. It is definitely possible that a large production line (e.g. in the steel industry) is divided into smaller autonomous parts in order to control them separately. Several process automation systems (as well as their underlying basic automation systems) are then put sequentially one behind the other. The production planning and control system may supervise the whole automation line. The primary task in such a system is to enable the information flow between the coupled layers. Again, it depends on the hardware and the software vendors of the autonomous parts what type of communication is used between the linked parts. The tasks presented here do not claim to be complete. Optionally, it is possible that a process automation system also includes other tasks or even runs with fewer tasks than listed above, but Figure 2.2 shows the most important tasks appearing in a process automation system as well as their general structure and collaborations. For a more detailed insight into process automation systems, the author refers to [LG1999], [Wei1994], [Sie1989] and [NPPPZ1999]. 2.3 Conventional Implementations Up to now, there are still many automation plants which are controlled by 20- or 30-year old software systems. As an example, a particular automation sector in the hot rolling mill at VOEST-Alpine Stahl Linz AG (VASL) is one of them, with a software system for the level 1 and level 2 automation which is in use since the 1970s. The following statements reflect the author s personal experience, gained from a software project at VASL [Ref1999a] and from discussions with automation experts at Siemens. Former automation software has generally been implemented in low level programming languages like Fortran, C or even assembler. Because of the lack of generic features of those languages, the software for process automation systems has been re-implemented from scratch for every automation plant. The only possibility of reuse was restricted to basic libraries or to cut and paste from existing programs, which negatively affected the development time and the cost for the automation software. Furthermore, conventional software implementations exhibited major deficiencies in terms of flexibility and maintenance. It was e.g. not possible to install a new sensor in the plant without stopping and modifying the software. Modern software systems should almost naturally be up to such demands. It was also a large problem to connect new components to the core system. When e.g. a new mathematical model calculated special setpoints, which had not been considered before in the automation, the programmer team was faced with a lot of work to adapt the software to the new circumstances. Generally, the production line of an automation plant is steadily confronted with a changing environment, where e.g. sensors and measuring devices are added or placed to different locations, working tools have to be exchanged, when they are worn

23 2.3. Conventional Implementations 11 out, etc. All these changes in connection with conventional automation software required a program stop and a modification of the code because most parts within these systems were hard-coded, without any chance of dynamic configuration. The following assembler code is an excerpt of the currently used automation software of the hot rolling mill at VASL. In total, the software consists of approximately 15 MB assembler source code. Figure 2.3: Excerpt of the current VASL Automation The snapshot in Figure 2.3 shows a connection routine, which is responsible for attaching a communication channel to a remote process. As it is clearly recognizable, the code is not prepared for comfortable reading. Without a detailed documentation, it is nearly impossible to maintain or extend the code. Consequently, the needs for a new and flexible automation software, which conquers all the problems mentioned before, is more than urgent. The succeeding chapters introduce an innovative software architecture for process automation systems which allows software reuse on a high level and therefore helps to save development time and money.

24

25 13 Chapter 3 Design Patterns Chapter 2 has provided an insight into the domain of process automation systems, their involved tasks and their various types of communication techniques both within the process automation system as well as to the outside. The communication network ranges from a telegram exchange mechanism over inter process data requests to setpoint transmissions for the underlying hardware. Different operating systems, protocols, data formats and requirements of the involved tasks are common problems in this area, and it has always been tedious and error-prone work in conventional systems to establish communication channels, but it was no intellectual challenge. Thus, it turned out that the different communication problems raise the desire for a general strategy to overcome the lack of implementation guidelines in this domain. This thesis introduces innovative design patterns providing a common solution for the communication problem in process automation systems facing all the variants of communication mentioned above. Because of the extent of the problems, the corresponding design patterns are not just collaborations of a few classes, as the reader might assume knowing the classical design patterns from Gamma, Helm, Johnson and Vlissides [GHJV1995]. Rather, they consist of or they use several already existing design patterns and link them together to new complex design patterns enabling the programmer to solve many architectural problems. Nevertheless, the original definition of design patterns is still valid: A design pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice. It names, abstracts and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. [GHJV1995] Upon closer consideration, the term architectural pattern would also be acceptable for this area of responsibility. Architectural patterns express fundamental structural organization schemas for software systems. They provide a set of predefined subsystems, specify their responsibilities, and include rules and guidelines for organizing the relationships between them. [BMRSS1996] Although both terms apply to the following implementation strategies, there is a slight difference between them: Whereas architectural patterns examine the problems and their collaborations at a course level of abstraction, design patterns con-

26 14 Chapter 3. Design Patterns centrate on a more detailed view, and this is exactly what the patterns in this thesis are about. So, the author prefers the term design patterns and uses it consistently throughout the document. The following chapter describes five new powerful design patterns especially developed for the communication flow in process automation systems. In a sense, they build up a core structure and a new architecture for future process automation systems, gradually coming into existence during the description of the individual design patterns. They are all closely related to each other, because they share a common base, forced upon by the domain. Hence, it is essential to read sequentially through this chapter in order to understand the collaborations among the design patterns. The succeeding sections also include sample C++ code [Str1998] and UML diagrams [BRJ1999] to illustrate the patterns. 3.1 Telegram Pattern The Telegram Pattern provides a flexible solution guideline for telegram-based communication between processes on miscellaneous platforms. It parses and converts the transmitted data by abstracting from the underlying operating system Motivation Consider two distinct processes with the needs of mutual data exchange, but implemented in different programming languages and running on different systems. This scenario often appears between the basic automation system on level 1 and the process automation system on level 2 (see Chapter 2). In order to solve the communication problems, most systems use telegrams, i.e. byte streams of predefined format. A written document containing detailed information about the contents of the telegrams can be regarded as the interface description between the two processes. Figure 3.1: Telegram Description The left part of Figure 3.1 shows a typical telegram description exactly defining the names, the number of bytes and the types of the data sequentially contained in the telegram. Knowing this information, the byte stream sent from process 1 can be interpreted by the receiver process (see right part of Figure 3.1). On the first glance, the problem seems quite trivial with a simple telegram description as the key to the solution. The problem is harder, though, when we take a closer look at it: First of all, it is necessary to distinguish between ASCII and binary telegrams. Whereas ASCII telegrams are quite easy to handle, binary telegrams are

27 3.1. Telegram Pattern 15 typically shorter, but they depend on the different representation of the data types caused by different operating systems. One operating system might store integer types in two bytes, whereas the other expects four bytes for them. Furthermore, the byte representations for numbers differ between little endian and big endian machines [RP1999]. It is also possible that types and units do not match. The sender process transmits a certain value in millimeters as integer, and the receiver process needs it as float in meters or as a fraction of inches. There are many further examples of communication barriers between telegram sender and receiver longing for a general implementation guide. The Telegram Pattern provides such a guide and acts as a bridge between level 1 and level 2. In the following sections, the Telegram Pattern is introduced step by step, continually increasing its capability to solve the problems mentioned above Parsing the Telegram The first task of the receiver process is to read the incoming telegram byte by byte and to restore the information contained in it. The experienced object-oriented programmer probably thinks of an architecture where Telegram objects parse their corresponding byte streams themselves. So, there should be a Telegram base class providing the interface for parsing a byte stream. Every kind of telegram is then represented by a subclass, which implements the interface due to the structure of the telegram. We additionally create a member variable for every value contained in the telegram and try to assign the correct value during the parsing process. Thus, the goal within this section should be to read a structured byte stream and store the retrieved results in a corresponding Telegram object with member variables for every value. Figure 3.2: Telegram Class Hierarchy Figure 3.2 shows an idealistic view of the problem with a simplified implementation of the parsing method. Actually, the implementation must be more powerful to solve the problems mentioned in section The parsing method must distinguish between ASCII or binary byte streams, decide if the byte order needs to be swapped etc. Nevertheless, the implementation as shown in Figure 3.2 is quite comfortable and should not be overloaded with parsing details. It should remain as simple as it is, and the actual process of reading the byte stream should be shifted to an external class.

28 16 Chapter 3. Design Patterns There is already a design pattern for this kind of problem the Strategy Pattern. It defines a family of algorithms, encapsulates each one, and makes them interchangeable [GHJV1995]. This is exactly what we need here: We define a family of algorithms for the different ways of reading a byte stream, encapsulate each family in a corresponding class, and make them interchangeable for the already defined Telegram classes. Figure 3.3: Strategy Pattern for Reading Telegrams An abstract base class Reader provides the interface for all kinds of reading operations, which are implemented as separate methods in the derived classes. Reading an integer from an ASCII stream is different from reading it from a binary stream, and again different when the byte order is swapped. The detailed implementation of these algorithms is irrelevant, though, and not shown here. Furthermore, it is also of minor importance whether the reading methods receive the byte stream through their interface or if the byte stream is assigned to the Reader just once in the beginning of the parsing method (like in Figure 3.3). But, what is important, however, is the extensible class hierarchy consisting of various Reader classes, which enable a further simple implementation of the parsing method (see right bottom of Figure 3.3). The architecture shown in Figure 3.3 appears as a flexible solution for the first step in telegram traffics for parsing the incoming byte stream. A new telegram can be handled by deriving a new Telegram class and implementing the parsing method without considering the type of the byte stream. This task is delegated to the various Readers, which can be individually assigned or exchanged even at run-time.

29 3.1. Telegram Pattern Extracting the Telegram Id Although the strategy introduced in the previous section provides a very adaptable approach of software design for the telegram communication mechanism, it still neglects one important aspect: When the sender process transmits several telegrams of different structure, the very first task of the receiver process is to identify which telegram has just arrived. This task should be done at a central point within the receiver, let us call it TelegramHandler. A TelegramHandler sequentially receives different kinds of telegrams and has to find out which Telegram classes can handle them. In order to distinguish between the byte streams, every telegram carries a unique identification (the telegram id) in the first bytes of the stream. But this fact raises the next problem: Different software vendors use different telegram types, which makes it impossible to find out how many bytes should be read and how they should be interpreted in order to extract the correct id out of the byte stream. It could be an ASCII telegram with a four-byte string id or it could be a binary telegram with a two-byte integer id. Even if there are telegrams of the same type (e.g. ASCII telegrams), the id might be different with a two byte string in one telegram and a four byte string in the other, when the telegrams come from miscellaneous software vendors. Consequently, the area of responsibility for a TelegramHandler has to be restricted in a way that one TelegramHandler can only handle telegrams of the same kind, and the same type and size for the id. So, if a process e.g. receives ASCII and binary telegrams, it has to provide two TelegramHandlers in order to interpret the telegrams correctly. The connection to the TelegramHandlers has to be established once in the beginning, to ensure that one TelegramHandler only receives one type of telegrams. Figure 3.4 shows a first attempt of a design for a corresponding class. Figure 3.4: Attempt of a TelegramHandler Class Due to the fact that every TelegramHandler is now restricted to one type of telegram, it correspondingly references only one Reader object. It can have several differently-structured Telegrams, though, with a prototype object of each Telegram stored in the telegramlist. In order to ensure the same type also in the implementation, every Telegram object added to the TelegramHandler is immediately initialized with the same Reader object (see top right implementation in Figure 3.4). The TelegramHandler does not create Telegram objects. It uses the prototype objects for parsing; and they must be processed before the next byte stream arrives. A TelegramHandler must at least have a method for receiving a byte stream. The first action within this method is to extract the telegram id from the stream, in