1 Integrative Specification of Distributed Production ... - CiteSeerX

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing Ulrich Nickel, Wilhelm Schäfer and Albert Zündorf.

Abstract

This paper describes how to use SDL block diagrams, UML class diagrams, and UML behavior diagrams like collaboration diagrams, activity diagrams, and statecharts as a visual, precisely defined specification language. We describe a modeling approach for flexible, autonomous production agents, so-called holons, which form the constituent parts of a decentralized production control system. We, particularly address the precise semantic definition of UML-like behavior diagrams and the corresponding code generation. Generally, generating code from UML behavior diagrams is not well understood. Frequently, the semantics of a UML behavior diagram depends on the topic and the aspect that is modeled and on the designer that created it. In addition, UML behavior diagrams usually model only example scenarios and do not describe all possible cases and possible exceptions. We overcome these problems by restricting the UML notation to a subset of the language. In addition, we define which kind of diagram should be used for which purpose and how the different kinds of diagrams are integrated to a consistent overall view. Finally, the paper sketches the code generation algorithms for Java and PLCs (Programmable Logic Controllers) which is a widely used technology in industry to build holons. The Java code is used for the simulation of a complete production line.

1.1

Introduction

Today’s manufacturing industry demands flexible and decentralized production control systems. Those systems, which are composed of so-called autonomous production agents or holons (e.g. manufacturing cells, shuttles, gates in track-based transportation systems), avoid hours of downtime of the production line in case of a failure of a single agent. They also support the sometimes parallel production of a flexible mixture of different products in small lot sizes. As these holons are usually driven by microprocessors and consequently by software, their construction requires a carefully designed and executed process which, for the scope of this paper, means especially a well-defined software development process. Such a process only guarantees the required high-quality software. Such a process in turn should include an appropriate domain-

1

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing oriented, machine- or microprocessor independent specification of the functionality of the software. This specification enhances readability of the code and consequently improves software evolution. It can also enable formal analysis of the system behavior concerning lifeness or safety properties by appropriate methods and tools like model checking. Current specification languages for embedded systems, like SDL [11] and statecharts [9], focus on the specification of (re)active components of production control systems like control units, actors (e.g. motors, valves), and sensors (e.g. switches, light borders, pressure, and temperature sensors), and on the interaction of such reactive components via events and signals. They provide no appropriate means for the specification of complex application specific object-structures as required by the mentioned autonomous production agents. Common object-oriented modeling languages, like UML, support the modeling of complex application specific object-structures. However, UML focuses on early phases of the software lifecycle like object-oriented analysis and object-oriented design, cf. [2]. Thus, UML behavior diagrams, like collaboration and sequence diagrams, usually model typical scenarios describing only parts of the desired functionality. With these problems and the industrial demands in mind, the German National Science Foundation (DFG - Deutsche Forschungsgemeinschaft) created a special research program (“Schwerpunktprogramm”) in 1998. The goal of this program which includes the funding of 11 collaborative projects between computer science and mechanical or electrical engineering in various German universities is to explore the possibilities of modern software specification languages concerning their usefulness for the specification of holonic production systems. This may require e.g. changes to, extensions of or laying semantic foundations to these languages. As a common background all projects use one of two reference case studies. One of these studies is the definition of a realistic industrial holonic production system. This paper reports about one out of the 11 projects, namely the ISILEIT project (ISILEIT is the acronym for the german translation of the title of this paper). This project focuses on the design and implementation phase. We are exploring the usefulness of executable specifications and code generators. We use SDL block diagrams for the specification of the agents of a production control system and their communication channels (signal routes). We use statecharts for the specification of the reactive behavior of the production agents. Instead of pseudo-code, we use a well defined subset of collaboration diagrams as a visual (executable) specification language for the specification of do, entry, exit, and transition actions within statecharts. We define a precise operational semantics for collaboration diagrams based on graph grammar theory. This precise semantics allows the automatic translation of such collaboration diagrams to object-oriented programming languages like Java or C++ and even PLCs (Programmable Logic Controllers) which is a widely used (non object-oriented) technology in industry to build holons. Consequently, this paper integrates SDL block diagrams, statecharts and collaboration diagrams to form an executable specification language that allows to specify reactive behavior as well as complex application specific object-structures. Although, we use the simulation of a production control system as a running example in this paper, we are confident that our modeling approach suits well for other application areas that deal with collaborating reactive objects and that employ complex application specific object-structures. The next chapter discusses related work in more detail. Chapter 1.3 introduces our modeling approach. Chapters 1.4, 1.5, 1.6 and 1.7 then describe the different phases of the approach in more detail and illustrate the use and semantic definition of the different diagrams used. Those phases include reactive behavior modeling by statecharts, action and method body modeling by collaboration diagrams, code generation for Java and PLCs and simulation. Chapter 1.8 summarizes our work and outlines current and future perspectives.

2

1.2 Related Work

1.2

Related Work

Current approaches for the specification of production agents use SDL [11] or statecharts [9]. SDL is very popular in the electrical and mechanical engineering community. SDL block diagrams are used to specify processes and channels between such processes as well as messages passed via these channels. The behavior of embedded system processes is specified either using SDL process diagrams or using statecharts. Both notations basically model finite state automata which react on signals by executing some actions, sending signals, and changing to new states. Both languages have a well defined formal semantics and tool support for analysis and simulation and code generation is available [1] [4] [7] [8] [18] [20] [21]. Compared to SDL process diagrams, statecharts provide more expressive language features like nested states, and-states, and history-states. In addition, the modeling of the internal process behavior becomes the domain of software developers (instead of mechanical or electrical engineers) which are more used to statecharts than to SDL process diagrams. Thus, we decided to adopt statecharts for the purpose of modeling internal process behavior. However, statecharts (as well as SDL process diagrams) lack appropriate means for the specification of the actual actions triggered by the received signals. Usually, one has to use pseudo code for this purpose and in case of code generation one actually deals with the nasty details of current textual programming languages. Statecharts provide sophisticated means for the specification of (concurrent) control flows for reactive objects. However, by purpose statecharts abstract from the complex application specific object structures that build up the concrete states of a system. Statecharts do not explicitly deal with values of attributes or with links to other objects nor with the evolution and changes of these object-structures caused by the execution of usual methods. The specification of application specific object-structures is a well known application area for graph grammars, cf. [19] [22]. Basically, a graph rewrite rule allows the specification of changes to complex object-structures by a pair of before and after snapshots. The before snapshot specifies which part of the object-structure should be changed and the after snapshot specifies how it should look like afterwards, without caring how these changes are achieved. While graph grammars are appropriate for the specification of object-structure modifications, they lack appropriate means for the specification of control flows. Even the well known graph rewrite system Progres [22] provides only textual control structures. To overcome this problem, in previous work, we introduced UML activity diagrams as highlevel control flow notation for graph rewrite rules, cf. [5] [13]. However, those diagrams still lack means for the specification of the reactive behavior of communicating and collaborating production agents. Furthermore, graph grammars in its various forms are not a diagrammatic language which is known and accepted in industry and even in academia. “Hiding” graph grammars behind a collaboration diagram notation, as we suggest in this paper, is a promising way to go to avoid acceptance problems.

3

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing

1.3

The Phases of the Modeling Approach

A small part of the above mentioned case study is used as a running example in this paper. Figure 1 shows a schematic overview of our case study. On this production line we produce bottle openers, which consist of several components. The system is specified in a way, that one can assign a production task to a shuttle, which means that one shuttle is responsible for the production of certain components. The first step in the working task is to move to station 1, where somebody equips the shuttle with the appropriate material. A display shows the worker, which pieces are needed. By pushing a button, the worker signals the material flow system, that the shuttle is completely equipped. The shuttle now moves to station 2, where the Figure 1 Schematic Overview of the Sample Factory portal robot takes the material from the shuttle and hands it over to the rotator, where the required manufacturing step is performed. After that, the portal robot takes the assembled good from the rotator and puts it on the waiting shuttle. The shuttle now moves to the storage (station 4) where the good is stored. If the control station does not assign a new task to the shuttle, it will rotate on the main loop, until it gets a new task again. Note, that station 3 does not have any functionality at the moment. In the near future, it will connect this production line to a second one. We define the software development process for such a type of system by six phases as follows: Analysis Consolidation Phase: Based on the results from a previously carried out informal requirements gathering phase which is beyond the scope of this paper, in this phase the topology of the planned production control system is modeled. This includes the identification of the number and types of participating processes as well as the definition of communication channels and of all kinds of interchanged signals. We use SDL block diagrams for this purpose, since SDL block diagrams are very popular in engineering disciplines and this work is done in close collaboration with mechanical and electrical engineers. In other application areas one might use ROOM [21] capsules and ports for the same purpose. Design Phase: In the next step, one derives the initial (UML) class diagram of the desired system. At this, each process(type) identified in the SDL block diagram generates a class in the class diagram. In addition, each signal received by a process in an SDL block diagram creates a signal method in the corresponding class.

4

1.3 The Phases of the Modeling Approach Reactive Behavior Modeling Phase: SDL block diagrams (and the derived class SDL state charts diagrams) specify the particular signals block (event handling, which are provided and understood by the high-level control flow) diagrams different processes. Now, we have to define how each process will react on these signals. Thus, for each process class, one has to provide a statechart describing activity diagrams the general process behavior. These stateclass charts should at least cover all signals that diagrams (control flow) are understood by / declared in the corresponding process class. collaboration diagrams In the engineering field, usually (graph grammar semantics) SDL process diagrams are used for this (object structure handling) purpose. We chose statecharts due to their additional expressive power over SDL process diagrams provided by nested states dynamic aspects static aspects and and-states. Action Modeling Phase: Statecharts Figure 2 The ISILEIT modeling phases specify in which states a certain process reacts to a particular signal. In response to a signal a process might change its state and execute some additional activities. For a flexible production agent, these activities might again include complex computations. These complex computations might employ or modify complex objectoriented data structures in order to reflect the surrounding world or the execution of manufacturing plans for certain products. For the specification of such complex computations we use UML-like collaboration diagrams. Consequently, we use collaboration diagrams to specify complex control flows of methods employed as actions within statecharts. Frequently, one will need more than a single collaboration diagram to model a number of object structure modifications. Therefore, we combine statecharts (and activity diagrams) with collaboration diagrams to a powerful visual specification language. Basically, we allow using collaboration diagrams as the specification of activities instead of just pseudo code statements. Code Generation Phase: Once all aspects of the system are specified, the Fujaba environment is able to generate a complete, executable Java implementation from the class and behavior diagrams. This implementation is further used for the following simulation phase. Furthermore, as will be explained later, generation for PLCs is also possible and supported. Simulation Phase: One of the main problems in today’s manufacturing industry is long down times of assembly lines due to long testing phases of newly installed software. Our approach allows to simulate the production process beforehand in order to shorten software reconfiguration down-times of physical assembly lines. In our approach, the different diagrams are logically and mutually dependent on each other. The SDL block diagrams specify the minimal number of (process) classes to be contained in the class diagram and for each such class all its signal methods. In addition, each process class is equipped with one main statechart. This statechart has to define the response to all signals of the corresponding class. In addition to state changes, this response might include actions. Each of these actions is specified using one behavior diagram (which in turn may apply additional diagrams for sub-activities). Thus, within the resulting overall specification each aspect of the system is specified by exactly one diagram and it is absolutely clear how these different diagrams are related to each other and how they form the whole specification. In addition, a specification is complete only if all aspects identified in the SDL block diagram are covered by class diagrams and statecharts and if in 5

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing turn all auxiliary aspects introduced in these diagrams are covered by additional behavior diagrams (until transitive closure is reached). Note that the mentioned completeness of specification diagrams is enforced for the final system specification only. One might use additional UML behavior diagrams in order to analyze certain scenarios during early informal requirements gathering. Such diagrams need not to be complete and there may be multiple diagrams that overlap in several aspects. One may study such scenarios at any time during the specification process and one should keep such diagrams for documentation purpose. As mentioned, this requirements analysis phase is beyond the scope of this paper but work is underway to include such a phase in our approach and to support partially automatic transformation into SDL block diagrams and UML class diagrams. The next chapters discuss the phases of our approach in more detail. We do not discuss details of the first two phases in more detail, because developing SDL block diagrams and deriving UML class diagrams is straightforward and also discussed elsewhere [3].

1.4

Reactive Behavior via State-charts

As mentioned in the introduction, there is a change from centrally to decentrally organized control and monitoring systems, i.e., complex production lines are constructed by a system of communicating production agents which all have separate control and monitoring systems. New processor and bus technologies allow decentralized control systems that are more robust, more flexible and more scalable. As many other approaches, we propose to use statecharts for the specification of the reactive behavior of control units. However, a decentralized system using a large number of asynchronously communicating control units requires a number of modifications to the usual Harel semantics of statecharts. Especially, event broadcasting and the zero execution time of actions and transitions (i.e. the perfect synchrony hypotheses) are not appropriate anymore. Using a single control unit, event broadcasting as employed in Harel statecharts is a perfectly valid assumption. However, in case of a large number of decentralized control units, event broadcasting becomes a bottleneck. To avoid these problems, in our approach events are not broadcasted but events are explicitly send to certain receivers using dedicated communication channels. These communications channels are defined by the SDL block diagrams. A communication channel transports event messages between a number of predefined processes. In our statechart specifications, an event is sent to a certain reactive object by just calling the according event method on that object. This provides a very convenient and uniform way to issue services on a reactive object. It also enables a standard adaption of inter process communication services like Java-RMI or CORBA. These mechanisms allow a flexible (re)location of control processes on different computation nodes, thus facilitating load balancing. To ensure overall consistency, sending an event to a neighbor object within a statechart specification is allowed only if the corresponding SDL block diagram defines a communication channel between the participating processes. Harel statechart semantics assume zero execution time for actions and transitions. In real time systems this means, computation needs always to be completed in very short time frames (typically some milliseconds) before the next external event occurs. In addition, Harel statechart semantics defines that whole sets of simultaneously occurring events are consumed in parallel. This parallel execution step may create a new set of simultaneously occurring reaction events that are subject to

6

1.5 Combining Statecharts and Collaboration Diagrams for Action Modeling the next synchronous execution step. This is a valid assumption for a central control unit and fairly simple computation tasks. In our approach, actions used in statecharts may perform complex computations, e.g. routing tasks, that may need some more time. In addition, different control processes may be located on different processor nodes with varying speed and work load. In such an environment zero time execution and perfect synchrony hypotheses are no longer appropriate. Thus, our approach handles events asynchronously. The different processes execute independent of each other at their own speed. This implies that events may occur at any point in time while the receiving process may still be busy consuming previous events. Thus, arriving events are stored in event queues until the receiving process has finished its previous tasks. This enables the use of control processes that perform time consuming computations without blocking other system parts. In addition, malfunctioning control processes do not block event senders and thus failure is localized. On the other hand, this decoupling of event sending and event consumption hampers the realization of certain real time properties like guaranteed reaction times. In our ISILEIT case study we have avoided such real time problems by exploiting domain knowledge about our application area. For example in our track system, the event input for a given gate or station is always limited to the events send by the next approaching shuttle. This makes it easy to choose a processor with appropriate speed for these track units that guarantees a timely reaction to incoming events. For more complex situations, we plan to introduce priorities for real time critical events. This will allow guaranteeing respond times for some safety critical events independent of complex computations for less critical events. For a more complete discussion of these issues see [16] [17] [23], which also give a formal semantic definition of “our” statecharts, based on graph grammar theory. Note, our statechart semantics is close to the semantics of ROOM charts [21]. However, ROOM charts do not provide and-states. As Harel, we consider and-states as a very important means for dealing with loosely coupled parallel tasks within a single control process.

1.5

Combining Statecharts and Collaboration Diagrams for Action Modeling

The previous chapter described how one may use statecharts to model the reaction of a process object to signals. Depending on their current state, process objects execute certain actions and change to new states. What is missing are appropriate means for the modeling of the actual actions triggered by the signals. Therefore, we propose to combine statecharts and collaboration diagrams. We use statecharts to specify complex control flows and collaboration diagrams to specify the entry, exit, do, and transition actions that deal with complex object-structures. Originally, collaboration diagrams are intended to model scenarios of complex message flows between a group of collaborating objects. In this context, collaboration diagrams do not have a precise execution semantics. In order to use collaboration diagrams as a visual programming language one has to add a lot of details on how the participating objects are found and how object structure modifications are executed. As an example, Figure 3 shows a detailed collaboration diagram for the activity doPuttingGood which is part of the statechart for class AssemblyLine, cf. Figure 5.

7

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing The collaboration diagram of Figure 3 employs 5 objects that are connected via various links. The collaboration messages 1 to 3 look up associations attached to the this object and fill variables s, factory, and cont with appropriate values. Note, that according to the class diagram, holds is a to-many association. Thus, looking up the holds association results in a set of objects represented by the multiobject cont. Step 4 retrieves the first element from this set of objects and assigns the result to variable g. At this point, all parFigure 3 Collaboration Diagram with Graph-Grammar Semantics ticipating objects are found and the actual operations can be executed. Step 5 removes the retrieved good g from the set cont and step 6 creates a carries link between shuttle s and good g and step 7 changes the value x of the amount attribute of object factory to the new value x+1. Finally, step 8 sends a goOn signal to shuttle s. Provided with such detailed collaboration messages code generation becomes very simple, cf. Figure 4. Basically, the messages are required to conform to usual Java statements that are just copied into the target code. In addition, the message numbers are exploited to generate control flow statements. Note, collaboration message numbers may contain condition execution and loops. However, this usage of collaboration diagrams adds little abstraction compared to direct programming. We raise the level of abstraction by assigning a standard semantics to certain graphical elements of collaboration diagrams and by a systematic simplification of required elements. This allows us to generate large amounts of complex Java code from the graphical elements of collaboration diagrams. For example, the simplified collaboration diagram shown as do action of state puttingGood at the bottom of Figure 5 still has the same semantics as the detailed collaboration diagram of Figure 3 and it still generates the same (amount of) code. In our context, a collaboration diagram specifies the body of a certain do method. At this, all collaboration messages originate from the this object. All boxes depict local variables of the current method or globals declared in the class diagram. Thus, it is clear which kind of objects are denoted and all «self», «global», and «local» links may Figure 4 Generated Java Code for Method doPuttingGood be omitted. Finally, only «association» links will remain. Thus, the «association» stereotype is superfluous, too. Next, it is clear, that the method variables have to be filled using the depicted links between the objects. The Fujaba code 8

1.5 Combining Statecharts and Collaboration Diagrams for Action Modeling generator is able to compute the necessary look-up operations, automatically, cf. [5] [25]. Thus, one may omit the association look-up operations (step 1 to 4). In Figure 3, the multi-object cont is used to look up the holds association and to select one of its elements. Our code generator derives these two steps, automatically. Thus, a single holds link from this to g suffices. Next, the depicted constraints {new} and {destroyed} indicate the creation and deletion of the corresponding elements, clearly. Thus, steps 5 and 6 can be generated by our code generator and may be omitted. Additionally, we simplify the frequent case of attribute assignments by allowing inscriptions like amount:=amount+1 in the attribute compartment of an object. Thus, the two occurrences of the factory object and their connecting «becomes» link may be combined to a single box. The bottom state in Figure 5 shows the resulting simplified collaboration diagram for activity doPuttingGood. In addition to the discussed simplifications we use series of (green/light grey) plus symbols and two parallel (red/dark grey) canceling lines instead of {new} and {destroyed} constraints, respectively. Experiences in teaching our notation to students have shown, that the textual constraints are frequently overlooked and that the new graphical notation is much easier to read. In our usage, collaboration diagrams depict the effects of operations in terms of changed attribute values and created and destroyed objects and links. Thus, the initial Figure 5 Statechart of Class AssemblyLine situation modeled by a collaboration diagram corresponds to the left-hand side of a graph rewrite rule. Accordingly, the situation resulting from the execution of the collaboration diagram corresponds to the right-hand side of that graph rewrite rule. This view allows the execution and translation of collaboration diagrams using code generation techniques known from the graph grammar field, cf. [5] [22] [24]. In addition, the rich graph grammar theory facilitates the proof of complex system properties, cf. [19] for an overview of graph grammar theory and [14] for an application of this theory to the database re-engineering field. Figure 5 shows how we combine statecharts and collaboration diagrams to so-called story charts. Figure 5 shows the story chart of our assembly lines. Our assembly lines loop through 4 major states. Usually an assembly line is in state waiting. When it receives a produce event, it stores the wanted parameter into its task attribute and changes to state getMaterial. State getMaterial 9

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing shows its do method as a collaboration diagram, directly. The do method looks up the shuttle s that should currently stay at this assembly line and the good g that is carried by s. It just cancels the carries link between g and s and creates a holds link between this and g, thus simulating that the assembly line takes the carried material from the shuttle. The collaboration diagram of the next state producing simulates that the assembly line turns the held material into the desired good. For simplicity reasons this is done by simply changing the type attribute of g to the value of this.task. The transition to state puttingGood fires after 20000 milliseconds, simulating that the manufacturing process needs some time. Finally, state puttingGood loads the manufactured good on the shuttle again and increments the amount of manufactured goods of its factory. In addition the collaboration message 1: goOn() sends a signal to the shuttle which should then switch from its state produce to state goDeliver and proceed with its tasks. Figure 5 illustrates the expressive power of story charts, the combination of statecharts and collaboration diagrams. Beyond just specifying the reactions to signals in terms of method activations and state changes, the embedded collaboration diagrams show the object-structures that model the concrete internal states of our production agents and how these states evolve over time. Due to our experiences with a combination of activity diagrams and collaboration diagrams cf. [5] [13] [15] the combination of high-level control flow specifications (statecharts or activity diagrams) and highlevel object structure rewrite rules (collaboration diagrams) results in a powerful visual programming language. This powerful visual programming language is an ideal means for the specification of the reactive behavior of flexible production agents that use an object-oriented representation of the world they are living in and of the plans and tasks they are executing. Note, due to the formal semantics of statecharts and graph rewrite rules, the semantics of story charts is well defined. Similarly, the Fujaba environment provides a code generator for story charts generating a table-driven implementation for the statechart parts and usual Java code for the collaboration diagrams as shown in Figure 4.

1.6

Code-Generation

The translation of class diagrams to an object-oriented programming language is straight-forward and provided by most current OO-CASE tools, [18] [20]. The Fujaba generator [5] translates UML classes to Java classes. Methods are translated into Java method declarations. The method bodies are usually empty (but a designer may specify a body using UML behavior diagrams see chapter 1.5). According to the Java Beans style guides, we translate attributes to private Java attributes accessible via appropriate get- and set-methods. UML associations are usually bi-directional. Thus, we implement associations by pairs of references in the respective classes. For multi-valued associations, like the (reverse direction of the) choices association between Path and Shuttle, we use standard container classes provided by the Java Foundation Classes [12]. In order to guaranty the consistency of the pairs of references that implement an association, the respective access methods for reference attributes call each other. Overall, the implementation of associations is close to the strategy of the Rhapsody tool [18].

10

1.6 Code-Generation However, in our case study, we use Programmable Logic Controllers (PLC) to program the basic functionality of a production agent of the production line. For the specification of the behavior of such a controller, different approaches exist, which cover different abstraction levels [10]. Sequential Function Charts for example describe the sequence of a PLC program as a state transition diagram, whereas Structural Text (ST) is a notation similar to PASCAL. For the automatic generation of PLC-code, we adapted the code generation mechanisms to produce Structural Text instead of Java code. Note, that as a classical procedural programming language ST does not support typical object oriented concepts, like inheritance or polymorphism. Thus, a direct mapping of the static and dynamic semantic aspects of the here introduced formalisms is not possible. These concepts have to be managed explicitly by the generated code and will be described in the latter of this section.

Figure 6 Class diagram of a portal robot

Figure 6 depicts a part of the class diagram of the control software for the portal robot, which is part of our case study (cf. Figure 1). Taking differently shaped material, such a robot also needs different grippers. Corresponding to the shape of the material which has to be handled, the robot changes the gripper at runtime. Different numerical control programs are called to drop the old gripper and install the new one. The class diagram models this functionality by a so called strategy pattern [6]. At any point in time, only one tool can be installed, which is modelled by the cardinality of the association current. The steps, which are necessary for dropping and installing the different tools are encapsulated in the classes ParallelGripper and CentricGripper. DATA_BLOCK portal STRUCT instanceOf:INT; // Object Type this:INT; // Object ID attr:PortalRobotAttr; // Attributes END_STRUCT; BEGIN // Initialize instanceOf:=PortalRobot; TYPE PortalRobotAttr this:=1; STRUCT attr.currentTool:=3; busy:BOOL; // Attribute attr.availableTool[1]:=4; currentTool:INT; // Assoc (0..1) attr.availableTool[2]:=5; availableTool:array [1..2] OF INT; END DATA BLOCK // Assoc (0..n) END_STRUCT END_TYPE

Figure 7 Instantiation of class PortalRobot in ST-Code

11

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing The dynamic allocation of memory during runtime is not allowed. Thus, all instances must be known at compile time. Therefore, the PLC code generation module employs a method called init, which instantiates all used classes. In other methods, the creation and deletion of such instances is not allowed. We can map these instances to so called data units, which are registered in the symbol table. Figure 7 shows the PLC coding of the instance portal of class PortalRobot. The attributes of the class are defined by the user defined type PortalRobotAttr. The type of the instance is defined by a predefined constant, which is assigned to the instanceOf variable. Moreover, the instance portal has a unique identification number (this) which corresponds to the number of the data block which is predetermined in the symbol table. Associations are mapped to attributes of type integer or array of integer. The maximum cardinality of an association, which is known at compile time, determines the size of the array. Two or more instances can then be associated by assigning their IDs (this) to the attributes which represent these associations. The generated functions have to cover the polymorphic behavior which is introduced by the object oriented specification. Therefore, the function expects the object ID of the instance, on which the method is called, to dereference the corresponding data block. In turn, the type of the instance can be discovered, whereas the constant instanceOfOffset determines the offset in the data block. Figure 8 depicts the implementation of the function dropTool of class PortalRobot, which, in turn, calls the function Tool_dropTool of the associated instance of class Tool. FUNCTION PortalRobot_dropTool:BOOL VAR_INPUT objectID:INT; END_VAR VAR retValue:BOOL; END_VAR BEGIN IF WORD_TO_BLOCK_DB(objectID).DW[instanceOfOffset]=PortalRobot THEN retValue:=Tool_dropTool(WORD_TO_BLOCK_DB(objectID).DW20); // Offset generated END IF;

Figure 8 Implementation of methods in ST-Code

1.7

Validation via Simulation

Once the specification reaches a complete and consistent state, the Fujaba code generators may translate them to an executable Java implementation. To facilitate simulation and graphical debugging of the generated application, the Fujaba environment provides Mr. Dobs, our Dynamic Object Browsing System. Mr. Dobs uses Java runtime type information and dynamic method invocation features for analyzing Java runtime object structures and for the user driven execution of application specific methods. Figure 9 shows a screen-shot of a Dobs session running an example specification. Note, on the creation of reactive objects, like shuttles, stations, and gates, the corresponding event handling threads start automatically. After selection of an object, the left column of Mr. Dobs shows all invokable methods of that object. One may interactively invoke one of these methods. If the invoked

12

1.8 Conclusions method requires parameters, a generic dialog window is opened, allowing to enter parameter values. After a(n interactive or event driven) method execution, Mr. Dobs reflects the changed object structure. In Figure 9 we have invoked the event method assign for all shuttles, asking them to produce keys and locks. From that on, the shuttles execute their manufacturing task. They travel along the tracks, communicate with gates, assembly lines, and storages, fetch material, trigger assembly lines, and deliver the created goods. Studying the running simulation, one may already observe specification errors like communication problems or deadlocks. One may also recognize bottlenecks or productivity problems due to unemployed production agents. Within the running system, one may create new objects, e.g. additional gates and tracks, and connect them to the existing object structure. Thereby, alternative system configurations might be tested. Additionally, one may simulate defects of some components, e.g. by disconnecting an assembly line, and analyze the behavior of the remaining production agents. In Figure 9 we just have disabled the upper-right assembly line. Due to their flexible specification, our shuttles are not threatened by Figure 9 Screenshot of the Simulation Environment this drop-out, but just travel to the alternative lower-right assembly line. However, the single functioning assembly line has become a bottleneck such that one shuttle (left of the lower assembly line) is already blocked, queuing for service. Mr. Dobs already provides an easy to use but restricted animation possibility for the Java code generated from story-chart specifications. A better integration with the specification, e.g. an animation of the executed story-charts for selected reactive objects is current work. We also try to improve the user interaction e.g. by attaching buttons and other GUI elements to depicted objects. Eventually, an adapted version of such a user interface might even serve as an user interface for the actual production system.

1.8

Conclusions

This paper discusses the use of UML diagrams as a visual executable specification language. For class diagrams the translation to an object-oriented program is straight-forward. The translation of statecharts is based on a table driven approach inspired by [4]. The use of collaboration diagrams and their translation to Java is taken from our previous work [5][13][23]. The main contribution of this paper is the integration of SDL block diagrams and class diagrams and statecharts and collaboration diagrams to a sound and complete specification language for flexible production control

13

1 Integrative Specification of Distributed Production Control Systems for the Flexible Automated Manufacturing systems, as discussed in chapter 1.3 and shown in Figure 2. The resulting specification language and modeling approach combines the power of statecharts, providing sophisticated means for modeling concurrent reactive objects, with the power of graph grammars, providing appropriate means for the specification of application specific object-structures on a very-high level of abstraction. In addition, this paper describes a possible semantics for the various UML diagrams (via their translation to Java). This may facilitate the reading of certain UML diagrams (by thinking in terms of the corresponding implementation concepts) and clarify ambiguous modeling. In addition, one may learn which UML diagram should be used for which purpose and how different UML diagrams may be combined to cover mixed cases. Thereby, we think that one may transfer our results to other application areas. The concepts described in this paper have lead to the construction of a CASE tool called Fujaba (From UML to Java and Back Again). The Fujaba environment supports editing of SDL block diagrams and UML class diagrams and story-charts and story-diagrams that combine statecharts and activity diagrams and collaboration diagrams. Code generation is provided for all these diagrams but SDL block diagrams. We already generate class diagrams from SDL block diagrams. The generation of process distribution and initialization code from SDL block diagrams is current work. The current prototype of the Fujaba environment is available as free software and comprises about 750 000 lines of pure Java code. The release of Fujaba is available via: http://www.fujaba.de We simulate multiple concurrent production agents via threads that communicate via events and share some common memory. However, for the distribution of production agents on multiple processors, the concept of shared memory is not appropriate. We have to decide how to distribute the common data and how to ensure a consistent access. For handling object structures we use collaboration diagrams. To keep these distribution aspects transparent to the developer, we thus defined a message passing protocol that maps the realization of the collaboration diagrams to the distributed case while preserving their semantics. This protocol ensures properties like exclusive access to objects or atomicity of actions. Currently, we adapt the code generation part of Fujaba to cover this new aspect. In our application domain, we deal with concurrent processes that face the usual concurrency problems like deadlocks, race-conditions, lifeness, safety. Equipped with the rich theory of statecharts and graph grammars, future work will try to provide verification mechanisms for simple cases of these problems.

References

[1]

[2] [3]

[4]

14

J. Ali, J. Tanaka: Implementation of the Dynamic Behavior of Object Oriented System; IDPT Vol. 4, 1998, Proc. of third biennial world conference on integrated design and process technology, 281-288, ISSN No. 1090-9389, Society for Design and Process Science (1998) G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language User Guide; Addison Wesley, ISBN 0-201-57168-4 (1999) I. Diethelm, L. Geiger, T. Maier, A. Zündorf: Turning Collaboration Diagram Strips into Storycharts; Workshop on Scenarios and state machines: models, algorithms, and tools; ICSE 2002, Orlando, Florida, USA (2002) B. P. Douglass: Real Time UML; Addison Wesley, ISBN 0-201-32579-9 (1998)

1.8 Conclusions [5]

[6] [7] [8]

[9]

[10] [11] [12] [13]

[14]

[15]

[16] [17] [18] [19] [20] [21] [22] [23] [24] [25]

T. Fischer, J. Niere, L. Torunski, A. Zündorf: Story Diagrams: A new Graph Rewrite Language based on the Unified Modeling Language and Java; in Proc. of the 6th International Workshop on Theory and Application of Graph Transformation (TAGT), Paderborn, November 1998, LNCS, Springer Verlag, to appear (1999) E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns; Addison Wesley, ISBN 0201-63361-2, 1995 U. Glässer, R. Karges, Abstract State Machine Semantics of SDL, in Journal of Universal Computer Science, Vol. 3, No., 12, 1997 D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-Tauring, and M. Trakhtenbrot, STATEMATE: A Working Environment for the Development of Complex Reactive Systems, IEEE Trans. Soft. Eng., 16, 403-414, 1990, D. Harel, E. Gery: Executable Object Modeling with Statecharts; Proc. 18th Int. Conf. on Software Engineering (ICSE ’18), Berlin, pp 246-257, IEEE, SIGSOFT, ISBN 0-81867246-3 (1996) International Electrotechnical Commission, Technical Committee No. 65. Programmable Controllers - Programming Languages, IEC 61131-3, 1993. ITU-T Recommendation Z.100, Specification and Description Language (SDL), International Telecommunication Union (ITU), Geneva, 1994 + Addendum 1996. Technical reference of the Java Foundation Classes, contained in the Java Development Kid v1.2 (Java2) http://www.sun.java.com/ J.-H. Jahnke and A. Zündorf: Specification and Implementation of a Distributed Planning and Information System for Courses based on Story Driven Modeling; in proceedings of the Ninth International Workshop on Software Specification and Design April 16-18, IseShima, Japan, IEEE Computer Society, pp. 77-86, ISBN 0-8186-8439-9 J.-H. Jahnke and A. Zündorf: Applying Graph Transformations To Database ReEngineering. Handbook of Graph Grammars and Computing by Graph Transformation, Volume 2 - Application. World Scientific, Singapore, 1999. J. Niere, A. Zündorf: Using Fujaba for the Development of Production Control Systems; accepted for Proc. of AGTIVE 99 - Applications of Graph Transformations With Industrial Relevance, Monastry Rolduc, Kerkrade, The Netherlands, Sept. 1-3, 1999, LNCS, 1999 H. J. Köhler, U. Nickel, J. Niere, A. Zündorf: Using UML as a visual programming language, technical report, tr-ri-99-205, University of Paderborn, 1999 H. J. Köhler: Code Generation for UML Collaboration, Sequence, and Statechart Diagrams; Master Thesis, in German, Dep. Computer Science, University of Paderborn, 1999. The Rhapsody case tool reference manual; Version 1.2.1, ILogix, http://www.ilogix.com/ G. Rozenberg (ed): Handbook of Graph Grammars and Computing by Graph Transformation, World Scientific, 1997. The Rational-Rose Realtime case-tool, http:// www.rational.com B. Selic, G. Gullekson, P. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, New York, NY, 1994. A. Schürr, A. J. Winter, A. Zündorf. Graph grammar engineering with PROGRES. In W. Schäfer, Editor, Software Engineering - ESEC ’95, LNCS 989, Springer Verlag, 1995. A. Zündorf: Rigorous Objectoriented Software Development; Habilitation Thesis, University of Paderborn (2001) A. Zündorf: A Development Environment for PROgrammed Graph REwriting Systems; (in German), Dissertation, RWTH Aachen, Germany, 1996. A. Zündorf: Graph Pattern Matching in PROGRES; In: Cuny J., Ehrig H., Engels G., Rozenberg G. (eds.): Proc. 5th. Int. Workshop on Graph-Grammars and their Application to Computer Science; LNCS 1073, Springer, 1996. 15