Factory monitoring systems are relatively simple because part manufacturing is not carried out in these systems; instead, the status of the factory is monitored with a variety of sensors. These sensors are attached to factory robots, which send status information about the factory workstations to which they belong. In addition, they send factory alarms concerning undesirable situations in the factory that require human intervention. Factory operators view the status of the different workstations and view and update alarm conditions.

In high-volume manufacturing plants, manufacturing workstations are physically laid out in a manufacturing line such as an assembly line (for an example, see Figure 15.1). Parts are moved between workstations on a conveyor belt. A part is processed at each workstation in sequence. Because workstations are programmable, variations on a given product can be handled. Typically, multiple parts of the same type are produced, followed by multiple parts of a different type.

Figure 15.1. High-volume manufacturing system

Each manufacturing workstation has a manufacturing robot for operating on the product and a pick-and-place robot for picking parts off and placing parts on the conveyor. Each robot is equipped with sensors and actuators. Sensors are used for monitoring operating conditions (e.g., detecting part arrival), and actuators are used for switching automation equipment on and off (e.g., switching the conveyor on and off). The first workstation is the receiving workstation, and the last workstation is the shipping workstation. These workstations have only a pick-and-place robot. All other workstations are referred to as line workstations; they have a manufacturing robot in addition to the pick-and-place robot. Factory operators look at workstation status and alarms.

The manufacturing steps required to manufacture a given part in the factory, from raw material to finished product, are defined in a workflow plan. The workflow plan defines the part type and the sequence of manufacturing operations. Each operation is carried out at a workstation. Workflow engineers create workflow plans and their constituent operations.

The processing of new parts in the factory is initiated when a human production manager creates a work order. The work order defines the quantity of parts required for a given part type.

In flexible manufacturing plants, a given part can be processed at any one of several manufacturing workstations of the same type. A part is dynamically allocated to a free workstation. Parts are moved between workstations on automated guided vehicles. Raw material, parts that have been partially processed, and finished parts are stored in an automated storage and retrieval system.

A flexible manufacturing system is a computer-controlled system for the automated manufacturing of parts in a factory. The flexible manufacturing system interfaces to robot controllers (abbreviated RC in Figure 15.2), an automated storage and retrieval system (ASRS), and an automated guided vehicle (AGV). In addition, it interacts with several human users—namely, production supervisors, human operators, and workflow engineers.

Figure 15.2. Flexible manufacturing system

An example of the layout of the factory floor for a flexible manufacturing system is shown in Figure 15.2. There are several manufacturing workstations, most of which have the following components:

An automated storage and retrieval system is similar to an automated warehouse and is used to store raw material, parts between operations (work in process), and finished parts (i.e., ready to be shipped). For storage, an automated forklift truck takes a part from a pickup/dropoff stand (labeled S on Figure 15.2) and stores it in a location in the ASRS. For retrieval, the truck removes the part from the ASRS and puts it on the stand. The ASRS has several stands, each of which may function as an input (IS) or output (OS) stand.

Parts are moved between workstations and to/from the ASRS via automated guided vehicles. An AGV picks up a part from a pickup/dropoff stand at the source workstation or ASRS, and delivers it to a stand at the destination workstation or at the ASRS.

The manufacturing steps required to manufacture a given part in the factory, from raw material to finished product, are defined in a workflow plan. The workflow plan defines the part type and the sequence of manufacturing operations. Each operation is carried out at a manufacturing workstation. The workflow plan is defined by a human workflow engineer.

The processing of new parts in the factory is initiated when a human production supervisor creates a work order. The work order defines the quantity of parts required for a given part type.

Factory monitoring systems are the simplest of the three major kinds of factory systems. They have one human actor: Factory Operator. Four use cases involve Factory Operator, as either primary or secondary actor, as depicted in Figure 15.3 and described here:

Figure 15.3. Factory Operator use cases

Next, the use cases for high-volume manufacturing systems are developed. The human actors are Production Manager, Factory Operator, and WorkflowEngineer. In addition, there are actors that correspond to external systems. These are the Manufacturing Robot and Pick & Place Robot actors. The use cases are described next and illustrated in Figures 15.3 through 15.5.

Figure 15.5. Production Manager use cases in a high-volume manufacturing system

Factory Operator initiates or participates in four use cases, as described for factory monitoring systems in the previous section (see Figure 15.3). These use cases—View Alarms, View Workstation Status, Generate Alarm and Notify, and Generate Workstation Status and Notify—are also used in high-volume manufacturing systems.

Workflow Engineer defines several manufacturing operations and then creates a workflow plan to define a sequence of operations to manufacture a part. Two related use cases are developed for this purpose (see Figure 15.4). The workflow engineer uses the Create/Update Operation use case to create, update, and modify manufacturing operations. Create/Update Operation is a base use case that is executed once for each operation created. Workflow Engineer can then use the Create/Update Workflow Plan use case to create, update, and modify a workflow plan that defines the sequence of operations to manufacture a part. The Create/Update Workflow Plan use case extends the Create/Update Operation use case. Thus an optional alternative in the Create/Update Operation use case is to create a workflow plan.

Figure 15.4. Workflow Engineer use cases

Production Manager initiates the Create/Modify Work Order use case to create and modify work orders. Production Manager also initiates a complex use case called Manufacture High-Volume Part, which deals with processing parts in a high-volume factory (see Figure 15.5). The production manager releases a work order to be processed in the factory. Each part starts processing at the receiving workstation, where a raw part is loaded onto the conveyor belt. At the next workstation the part is picked off the conveyor belt by the pick-and-place robot, has a manufacturing operation performed on it by the manufacturing robot, and is then placed back on the conveyor belt by the pick-and-place robot and transported to the next workstation. This process continues until the finished part reaches the shipping workstation where it is picked off the conveyor in preparation for shipping to the customer. A just-in-time algorithm is used in the factory, meaning that a workstation receives a part only when it is ready to process a part, so parts do not pile up at each workstation.

From examination of the Manufacture High-Volume Part use case, it can be determined that the use case is made more general by being divided into the following three abstract use cases, which are included in the Manufacture High-Volume Part concrete use case:

Flexible manufacturing systems have several use cases in common with factory monitoring and high-volume manufacturing systems. They support the same four Factory Operator use cases described in Section 15.2.1 and illustrated in Figure 15.3. And like high-volume systems, flexible manufacturing systems need three additional use cases: Create/Update Operation and Create/Update Workflow Plan (for workflow planning), and Create/Modify Work Order, as described in Section 15.2.2. However, flexible manufacturing systems handle part processing quite differently from high-volume systems.

The Flexibly Manufacture Part use case addresses part processing in a flexible manufacturing system (see Figure 15.6). The raw material to make the part is initially stored in the ASRS. The part is then retrieved by an ASRS forklift truck and moved to the ASRS stand. Next, an AGV is sent to pick up the part and move it to the input stand of the first workstation. After delivery, the part is processed at the workstation and then placed on the workstation output stand. From there the part is picked up by an AGV and either moved to the next workstation or moved back to the ASRS for temporary storage. A finished part is moved back to the ASRS and then shipped.

Figure 15.6. Production Manager use cases in a flexible manufacturing system

It is possible to have a more limited flexible manufacturing system that uses the ASRS only for storing raw material prior to the start of part manufacturing and for storing finished parts after the completion of part manufacturing. This more limited form of part manufacturing is addressed by the Flexibly Manufacture Part use case. The more general use case, in which the ASRS is used for intermediate storage and retrieval during part manufacturing, consists of two extension use cases to the Flexibly Manufacture Part use case—Store Part and Retrieve Part—as shown in Figure 15.6.

The concrete Flexibly Manufacture Part use case can be divided into four abstract inclusion use cases as follows:

The Store Part extension use case extends Flexibly Manufacture Part at the extension point Part Storage, and the Retrieve Part extension use case extends Flexibly Manufacture Part at the extension point Part Retrieval, as shown in Figure 15.6.

As described in Section 4.8.2, there is a product line condition that must be true for the extension use case to be enabled. A product line member that provides the ASRS extensions for intermediate storage has the product line condition called [storage] set to true. In addition, for the extension use case to be executed, the selection condition must also be true during runtime execution. To invoke the Store Part extension use case at the extension point Part Storage, both the product line condition and the selection condition [store command] must be true; thus, [storage AND store command] must be true (see Figure 15.6). For the Retrieve Part extension use case to be invoked at the extension point Part Retrieval, both the product line condition and the selection condition [retrieve command] must be true; thus, [storage AND retrieve command] must be true.

The static model for factory monitoring systems is quite simple, as shown in Figure 15.12. A factory consists of factory monitoring workstations, which generate alarms. Thus the Factory class is an aggregate class composed of the Factory Monitoring Workstation class.

Figure 15.12. Static model for a factory monitoring system

Because a workstation can generate multiple alarms, there is a one-to-many relationship between the Factory Monitoring Workstation class and the Alarm class. Each Factory Monitoring Workstation also generates Workstation Status (a one-to-one association), which is viewed by the Factory Operator. Any operator can view the status of any workstation, which implies a many-to-many association.

The static model for the high-volume manufacturing system is shown in Figure 15.13. Because a factory consists of workstations, Factory is modeled as an aggregate class composed of High-Volume Manufacturing Workstation classes. There are three types of high-volume manufacturing workstations—receiving workstations, line workstations, and shipping workstations—so they are modeled as a generalization/specialization hierarchy; that is, the High-Volume Manufacturing Workstation class is specialized into three subclasses: Receiving Workstation, Shipping Workstation, and Line Workstation.

Figure 15.13. Static model for a high-volume manufacturing system

A workflow plan defines the steps for manufacturing a part of a given type; it contains several operations, where an operation defines a single manufacturing step carried out at a workstation. Consequently, there is a one-to-many association between the Workflow Plan class and the Manufacturing Operation class. Because several different operations are processed at a given factory workstation, there is also a one-to-many association between the High-Volume Manufacturing Workstation class and the Manufacturing Operation class. A work order defines the number of parts to be manufactured of a given part type. Thus the Work Order class has a one-to-many association with the Part class. Because a workflow plan defines how all parts of a given part type are manufactured, the Workflow Plan class also has a one-to-many association with the Part class.

The static model for flexible manufacturing systems is more complicated, as shown in Figure 15.14. The factory is an aggregation of factory workstations, automated guided vehicles (AGVs), and an automated storage and retrieval system (ASRS). An ASRS consists of ASRS bins (where parts are stored), ASRS stands (where parts are placed after retrieval from an ASRS bin or prior to storage in an ASRS bin), and forklift trucks (which move parts from the stands to the bins for storage and vice versa for retrieval). The static model consists of an aggregate Factory class, which is composed of the Flexible Manufacturing Workstation class, the Automated Guided Vehicle class, and the Automated Storage & Retrieval System (ASRS) class. The ASRS class is also an aggregate class, composed of the ASRS Bin, ASRS Stand, and Forklift Truck classes. The Workflow Plan, Manufacturing Operation, Work Order, and Part classes are modeled in the same way as in the static model for the high-volume manufacturing system (see Figure 15.13).

Figure 15.14. Static model for a flexible manufacturing system

The way to develop the static model for the factory automation product line is to integrate the static models for the three different kinds of factory systems: factory monitoring systems, high-volume manufacturing systems, and flexible manufacturing systems. This kind of model integration is similar to view integration in logical database design, and for this reason the three different models are referred to as views in the following discussion. The integrated static model for the factory automation software product line is described in this section.

When the factory monitoring, high-volume manufacturing, and flexible manufacturing static models are integrated (see Figure 15.15), classes that are common to all three views become kernel classes. Classes that are in one view but not the others become optional classes. Classes that are different in each view are generalized so that the different classes become specialized subclasses of the superclass.

Figure 15.15. Static model for the factory automation software product line

Some classes exist in one kind of system but not the others; for example, the AGV and ASRS classes exist only in flexible manufacturing systems. Some classes exist in more than one kind of system; for example, Workflow Plan and Manufacturing Operation exist in both flexible and high-volume manufacturing systems.

Classes that vary from one kind of system to another, such as Factory Workstation, are designed as subclasses of a generalized superclass. Thus a Factory Workstation superclass is introduced (which does not exist in any of the three views shown in Figures 15.12 through 15.14) and specialized to produce three subclass variants: Factory Monitoring Workstation, High-Volume Manufacturing Workstation, and Flexible Manufacturing Workstation. As in the static model for the high-volume manufacturing system, High-Volume Manufacturing Workstation is specialized into three subclasses: Receiving Workstation, Line Workstation, and Shipping Workstation.

Factory is an aggregate class composed of the Factory Workstation class, the optional Automated Guided Vehicle (AGV) class, and the optional Automated Storage and Retrieval System (ASRS) class. The first of these is used by all factory systems, albeit specialized as required. The latter two classes are used only in flexible manufacturing systems. As in the static model for the flexible manufacturing system, the ASRS class is an aggregate class composed of the ASRS Bin, ASRS Stand, and Forklift Truck classes.

The attributes of the classes in the static model are depicted in Figure 15.16. It is necessary to determine the attributes of the entity classes in particular before developing the communication diagrams because several of the objects in communication diagrams read or update the values of the entity class attributes.

Figure 15.16. Classes and attributes for the factory automation software product line

The product line context class diagram, which defines the boundary of a product line system, is determined in the reverse engineering approach by consideration of the context class diagrams of each of the major factory systems. For a factory monitoring system, the external classes consist of one external user (Factory Operator) and two external systems (Manufacturing Robot and Pick & Place Robot), as shown in Figure 15.17.

Figure 15.17. Context class diagram for a factory monitoring system

For a high-volume manufacturing system (see Figure 15.18), the external classes consist of three external users (Production Manager, Workflow Engineer, and Factory Operator) and the same two external systems (Manufacturing Robot and Pick & Place Robot). A flexible manufacturing system has the same five external classes, as illustrated in Figure 15.19. In addition, there are two further external systems: Automated Guided Vehicle (AGV) and Automated Storage and Retrieval System (ASRS).

Figure 15.18. Context class diagram for a high-volume manufacturing system

Figure 15.19. Context class diagram for a flexible manufacturing system

The context class diagrams for each system are integrated to create the product line context class diagram, as shown in Figure 15.20. In this diagram the external classes that are required by all factory systems are kernel. Two of the external systems (Manufacturing Robot and Pick & Place Robot) and one external user (Factory Operator) fall into this category. However, because of an additional product line requirement that some factory systems should operate unmanned, the Factory Operator external user class is recategorized as optional. The remaining external classes are optional because they are needed in only some of factory automation systems, and individual members of the product line can be configured without them. The optional classes are the external systems AGV and ASRS (which are needed only in flexible manufacturing systems) and the two external users Production Manager and Workflow Engineer (which are needed by high-volume manufacturing systems and flexible manufacturing systems but not by factory monitoring systems).

Figure 15.20. Context class diagram for the factory automation software product line system

During dynamic modeling, the objects that participate in each use case are determined, and then the sequence of interactions among the objects is analyzed. The first step is to analyze how the factory automation product line is structured into objects.

Entity objects are long-living objects that store information. The entity objects for the factory automation product line are Workflow Plan, Manufacturing Operation, Work Order, and Part. There are also Workstation Status and Alarm entity objects. The entity objects are depicted in the static model in Figure 15.15, and their attributes are given in Figure 15.16. The entity objects are all server objects that are accessed by various client objects. Hence, on communication diagrams the entity objects are depicted as server objects: Workflow Plan Server, Manufacturing Operation Server, Work Order Server, Part Server, Workstation Status Server, and Alarm Server.

For each of the human actors there needs to be a user interface object. These objects are Workflow Engineer Interface, Production Manager Interface, and Factory Operator Interface.

For the factory automation product line, which is distributed in nature, several control objects provide distributed control. Several instances of the Workstation Controller class exist—one instance for each manufacturing workstation. However, different variants of this class are used by the different members of the product line. For high-volume systems, there is one instance of Receiving Workstation Controller, one of Shipping Workstation Controller, and several of Line Workstation Controller (one for each workstation). For flexible systems, there is one instance of Flexible Workstation Controller for each workstation. For factory monitoring systems, there is one instance of Monitoring Workstation Controller for each workstation.

After object structuring, dynamic modeling for product lines follows the kernel first approach as described in this section. First the communication diagrams for the kernel use cases—namely, the factory monitoring use cases—are determined. In analyzing the object communication for each use case, various architectural patterns are recognized for future reference during design,

Communication Diagrams for Client/Server Use Cases

Consider the Factory Operator use cases, which form the basis of the factory monitoring communication diagrams. Two of these communication diagrams involve the Client/Server pattern, in which a client—in this case a user interface client—interacts with a server. First consider the communication diagram for the View Alarms use case, depicted in Figure 15.21. The message sequence is as follows:

1. S1: The factory operator requests an alarm handling service—for example, to view alarms or to subscribe to receive alarm messages of a specific type.

2. S1.1: Operator Interface sends the alarm request to Alarm Handling Server.

3. S1.2: Alarm Handling Server performs the request—for example, reads the list of current alarms or adds the name of this client to the subscription list—and sends a response to the Operator Interface object.

4. S1.3: Operator Interface displays the response—for example, alarm information—to the operator.

Figure 15.21. Communication diagram for the View Alarms use case

The communication diagram for the View Workstation Status use case also represents the Client/Server pattern and is very similar (Figure 15.22). The message sequence is as follows:

1. V1: The factory operator requests a workstation status service—for example, to view the current status of a workstation.

2. V1.1: Operator Interface sends a workstation status request to Workstation Status Server.

3. V1.2: Workstation Status Server responds—for example, with the requested workstation status data.

4. V1.3: Operator Interface displays the workstation status information to the operator.

Figure 15.22. Communication diagram for the View Workstation Status use case

Communication Diagrams for Subscription/Notification Use Cases

The two other kernel use cases are Subscription/Notification patterns, in which a client is notified of new events previously subscribed to in a client/server use case. Consider the communication diagram for the Generate Alarm and Notify use case, shown in Figure 15.23. The message sequence is as follows:

1. M1: Workstation Controller receives workstation input from the external robot, indicating a problem condition.

2. M2: Workstation Controller sends an alarm to Alarm Handling Server.

3. M3: Alarm Handling Server sends a multicast message containing the alarm to all subscribers registered to receive messages of this type.

4. M4: Operator Interface receives the alarm notification and displays the information to the factory operator.

Figure 15.23. Communication diagram for the Generate Alarm and Notify use case

The communication diagram for the Generate Workstation Status and Notify use case is also a Subscription/Notification pattern and is shown in Figure 15.24. The message sequence is as follows:

1. N1: Workstation Controller receives workstation input from the external robot, indicating a change in workstation status—for example, part completed.

2. N2: Workstation Controller sends a workstation status message to Workstation Status Server.

3. N3: Workstation Status Server sends a multicast message containing the new workstation status to all subscribers registered to receive messages of this type.

4. N4: Operator Interface receives the workstation status message and displays the information to the factory operator.

Figure 15.24. Communication diagram for the Generate Workstation Status and Notify use case

With the product line evolution approach, the communication diagrams for the high-volume manufacturing use cases are determined next.

Consider first the interactions for the Factory Operator use cases. The first two communication diagrams—for View Alarms and View Workstation Status—are identical to the factory monitoring system diagrams for those use cases (see Figures 15.21 and 15.22). The other two communication diagrams—for Generate Alarm and Notify and Generate Workstation Status and Notify—are very similar to the factory monitoring system diagrams for those use cases (see Figures 15.23 and 15.24), with one subtle difference.

There are three different types of Workstation Controller objects: Monitoring Workstation Controller, (high-volume) Line Workstation Controller, and Flexible Workstation Controller. However, the way these three Workstation Controller variants operate in the Generate Alarm and Notify and Generate Workstation Status and Notify use cases is identical. Consequently, the generalized form of the Workstation Controller is used, rather than a specific subclass. (Workstation Controller is an abstract class that needs to be specialized as required for a given kind of factory before it can be instantiated.)

The workflow and work order use cases are those that involve workflow planning, as carried out by the workflow engineer, and work order management, as performed by the production manager.

Communication Diagrams for Workflow Planning Use Cases

Consider the workflow planning use cases initiated by Workflow Engineer. These use cases are used in both high-volume and flexible systems. A workflow engineer has to create manufacturing operations and then create a workflow plan that consists of a sequence of operations. Two use cases are used for this purpose (see Section 15.2.2 and Figure 15.8): Create/Update Operation and Create/Update Workflow Plan, where Create/Update Workflow Plan extends Create/Update Operation (see Figure 15.4). First consider the communication diagram for the Create/Update Operation use case (see Figure 15.25). The message sequence is as follows:

1. O1: Workflow Engineer inputs information for creating an operation to Workflow Engineer Interface. This information includes the operation name, workstation type, and robot programs to be used.

2. O1.1: Workflow Engineer Interface sends a Create Operation request to Manufacturing Operation Server.

3. O1.2: Manufacturing Operation Server sends a Check Workstation message to Workstation Status Server, which maintains information about all the manufacturing workstations.

4. O1.3: Workstation Status Server responds with a Workstation Status message, allowing Manufacturing Operation Server to check whether the workstation type exists for the new operation.

5. O1.4: Manufacturing Operation Server sends the operation information to Workflow Engineer Interface.

6. O1.5: Workflow Engineer Interface object displays the operation information to Workflow Engineer. The engineer may iterate, creating more operations.

Figure 15.25. Communication diagram for the Create/Update Operation and Create/Update Workflow Plan use cases

Now consider the Create/Update Workflow Plan use case (also shown in Figure 15.8), which extends Create/Update Operation because it creates the workflow plan from operations created in the Create/Update Operation use case. The message sequence for the communication diagram shown in Figure 15.25 is as follows (the sequence numbering starts with 2 because the sequence follows on from operation creation):

1. P2: Workflow Engineer inputs information for creating a workflow plan to Workflow Engineer Interface. This information includes the plan name and part type, raw material, and operation information for the first manufacturing operation.

2. P2.1: Workflow Engineer Interface sends a Create Workflow Plan request to Workflow Plan Server.

3. P2.2: Workflow Plan Server sends an Operation Request message to Manufacturing Operation Server.

4. P2.3: Manufacturing Operation Server responds with information about the requested operation.

5. P2.4: Workflow Plan Server sends the workflow plan information to Workflow Engineer Interface.

6. P2.5: Workflow Engineer Interface displays the workflow plan information to Workflow Engineer. The engineer adds other operations to the workflow plan.

Communication Diagrams for Work Order Management Use Cases

Next consider the communication diagram for the Create/Modify Work Order use case initiated by Production Manager, in which three entity objects—Work Order Server, Part Server, and Workflow Plan Server—are accessed (see Figure 15.26). The message sequence is as follows:

1. R1: Production Manager inputs production information to Production Manager Interface. This information includes the type of part to be manufactured.

2. R1.1: Production Manager Interface sends a Create request to Work Order Server.

3. R1.2: Work Order Server sends a Workflow Plan Request message to Workflow Plan Server, which retrieves workflow plan information for the specified part type.

4. R1.3: Workflow Plan Server returns the workflow plan information to Work Order Server.

5. R1.4: Work Order Server sends a Create request to Part Server for each part to be manufactured.

6. R1.5: Part Server acknowledges part creation.

7. R1.6: Work Order Server sends the work order information to Production Manager Interface.

8. R1.7: Production Manager Interface displays the production information to Production Manager.

Figure 15.26. Communication diagram for the Create/Modify Work Order use case

The high-volume manufacturing use case is a complex use case initiated by the production manager and called Manufacture High-Volume Part, in which a part is manufactured in the high-volume factory from raw material to finished product. This use case requires three different types of workstation controllers: a Receiving Workstation Controller object, several Line Workstation Controller objects, and a Shipping Workstation Controller object. There is one instance of the Line Workstation Controller class for each manufacturing workstation, and the instances are connected in series. When the production manager releases a work order to the factory, a Start Part message identifying the part ID and number of parts required is sent to Receiving Workstation Controller. This step ensures that for each part to be manufactured, a piece of raw material of the appropriate type is obtained and loaded onto the conveyor. At the shipping workstation, the Shipping Workstation Controller object removes finished parts from the conveyor and places them in a shipping area.

In a just-in-time algorithm, a workstation requests a part only when it is ready to process a part, so parts do not pile up at a workstation. When a workstation completes a part, it waits for a message from its successor workstation requesting the part. When the message is received, the workstation controller sends a Place command to the Pick & Place Robot to place the part on the conveyor. Next, the workstation controller sends a Part Coming message to the successor workstation and a Part Request message to the predecessor workstation. The Receiving Workstation Controller object maintains a count of the remaining number of parts for a given work order. Shipping Workstation Controller controls the removal of each finished part from the conveyor in preparation for shipping, after which it sends a Part Complete message to Production Manager Interface.

The three abstract use cases for part manufacturing (shown in Figure 15.9) are as follows:

A concrete use case for a part that has to visit n line workstations consists of one execution of the Receive Part use case (A), w – 1 (where w is the number of line workstation controllers) executions of the Process Part at High-Volume Workstation use case (B), and one execution of the Ship Part use case (C). The three part manufacturing abstract use cases are shown on communication diagrams (Figures 15.30 through 15.32), where events are labeled A, B, and C, corresponding to the three use cases described here.

Figure 15.30. Communication diagram for the Receive Part use case

Figure 15.32. Communication diagram for the Ship Part use case

In general, a workstation controller receives a part from a predecessor workstation controller (which could be a receiving or line workstation controller) and sends a part to a successor workstation controller (which could be a line or shipping workstation controller).

Because Workstation Controller is a state-dependent control object, it is defined by means of a statechart, which is described next, prior to the detailed description of the three communication diagrams.

The statechart for Line Workstation Controller consists of two orthogonal statecharts: the Part Processing statechart and the Part Requesting statechart. The two orthogonal statecharts are depicted as superstates on a high-level statechart, with a dashed line separating them (see Figure 15.27). At any one time, a workstation controller is in one of the substates of the High-Volume Part Processing superstate (see Figure 15.28), reflecting the current situation in processing of the part at this workstation; and in one of the substates of the Part Requesting superstate (see Figure 15.29), reflecting whether or not a part has been requested by the successor workstation. This orthogonal statechart does not imply that there is any concurrency within a Line Workstation Controller object, but merely that it is simpler to model these relatively independent event occurrences in this way.

Figure 15.27. Statechart for Line Workstation Controller: high-level statechart

Figure 15.28. Statechart for Line Workstation Controller: decomposition of the High-Volume Part Processing superstate

Figure 15.29. Statechart for Line Workstation Controller: decomposition of the Part Requesting superstate

The High-Volume Part Processing superstate contains the following substates. The transitions between the substates are described in the context of the communication diagrams (Figures 15.30–15.32):

The Part Requesting superstate has the following substates:

These two substates are used as conditions to be checked in the Part Processing statechart for determining what state to enter when robot manufacturing has completed.

The details of the three high-volume part manufacturing use cases are discussed in this section and illustrated in Figures 15.30 through 15.32. Each line and shipping workstation controller sends a Part Request message to its predecessor workstation at initialization. This message is represented by the B2 and C2 messages, which are also shown on the statechart in Figure 15.28. The production manager initiates the main event sequence by creating a work order (message A1). To make an abstract use case more reusable, an object in one use case–based communication diagram is allowed to send a message to an object in another use case–based communication diagram. Although the message numbers in the two use cases are usually different, the message numbers are said to be equivalent.

At system initialization, the message sequence is as follows:

Communication Diagram for the Process Part at High-Volume Workstation Use Case

In the communication diagram for the Process Part at High-Volume Workstation use case (Figure 15.31), Line Workstation Controller n sends a part to Line Workstation Controller n + 1. The following event sequence is shown on both the Process Part at High-Volume Workstation communication diagram (Figure 15.31) and the statechart for Line Workstation Controller (Figure 15.28). The message sequence is as follows:

1. B1, B2: As explained at the start of this section.

2. B3: On receiving the Part Coming message from the predecessor workstation, Line Workstation Controller transitions into the Part Arriving state (see Figure 15.28).

3. B4: The action associated with the state transition is that Line Workstation Controller issues to Workflow Plan Server a Next Operation Request message containing the part type and current workflow step number (initially 1).

4. B5: Workflow Plan Server increments the workflow step number for this part's workflow plan, determines the operation ID for this workflow step, and issues an Operation Request message to Manufacturing Operation Server for the next operation in sequence.

5. B6: Manufacturing Operation Server retrieves the operation information and sends it back.

6. B7: Workflow Plan Server sends the operation information to Line Workstation Controller.

7. B8: A sensor at Pick & Place Robot detects arrival of the part at the workstation and sends a Part Arrived message to Line Workstation Controller. As a result, Line Workstation Controller transitions to the Robot Picking state.

8. B9: As a result of the state transition, Line Workstation Controller sends a command to Pick & Place Robot to pick the part off the conveyor.

9. B10: Pick & Place Robot picks the part off the conveyor and places it in the workstation. On completion, Pick & Place Robot notifies Line Workstation Controller. Line Workstation Controller transitions to the Operating on Part state.

10. B11: Line Workstation Controller sends the Start Operation command to Manufacturing Robot, which operates on the part.

11. B12: On completion of the manufacturing operation, Manufacturing Robot sends an Operation End status message to Line Workstation Controller. If a part has been requested (C2), Line Workstation Controller transitions to the Robot Placing state; if not, Line Workstation Controller transitions to Awaiting Part Request from Successor Workstation.

12. B13: As a result of the transition to Robot Placing state, Line Workstation Controller sends a command to Pick & Place Robot to place the part on the conveyor.

13. B14: On completion of its job, Pick & Place Robot sends a Part Placed message to Line Workstation Controller. Line Workstation Controller transitions to Awaiting Part from Predecessor Workstation. As a result of the transition, two concurrent actions take place: B15 and B15a.

14. B15 = C3: Line Workstation Controller sends a Part Coming message to the successor workstation. Part Coming is an output event on the Part Processing statechart that is propagated to the Part Requesting orthogonal statechart, where it appears as an input event that causes a transition from Part Has Been Requested to Part Not Requested.

15. B15a (parallel sequence): Line Workstation Controller sends a Part Request message to the predecessor workstation.

Figure 15.31. Communication diagram for the Process Part at High-Volume Workstation use case

The communication diagram for the Ship Part abstract use case (Figure 15.32), in which last Line Workstation Controller sends a part to Shipping Workstation Controller, consists of the following message sequence (C1, C2, and C3 have been previously described):

1. C4: At Shipping Workstation Controller, a sensor detects part arrival and sends the Part Arrived message.

2. C5, C6: Pick & Place Robot picks the part off the conveyor and notifies Shipping Workstation Controller.

3. C7: Shipping Workstation Controller stores the part in the finished parts inventory and sends a Part Complete message to Production Manager Interface.

4. C8: Production Manager Interface displays the part completion information to the human production manager.

Now consider the communication diagrams for the flexible manufacturing use cases. In the Flexibly Manufacture Part use case, parts released to the factory floor are handled by Part Scheduler, which schedules parts to the various workstations on the basis of workstation availability and the workstation type required, as indicated by the next operation to be processed for that part. To move a part to the workstation, AGV Dispatcher is responsible for ensuring that the part is moved from its current location to the appropriate workstation. When the part has been delivered, Flexible Workstation Controller is informed that the part has arrived. Part Scheduler is informed of the completion of the operation so that it can schedule the part to the next workstation.

Flexible manufacturing systems use an automated storage and retrieval system (ASRS) to store raw material and finished parts. In some flexible manufacturing systems, parts in process are also temporarily stored in the ASRS as described by the Store Part and Retrieve Part extension use cases. In this situation, if all workstations are busy, Part Scheduler may decide to temporarily move the part to the ASRS. AGV Dispatcher is requested to move the part to the ASRS. When the part arrives at the ASRS, ASRS Handler is requested to place the part in storage.

To avoid having overly centralized part scheduling, part processing is divided as follows: Part Scheduler decides which workstation a part should move to next. Part Agent (one object for each part) acts on behalf of the part, making requests to the following objects:

This means that the part processing activity is divided between a decision maker (Part Scheduler) and an implementer of the scheduler's decisions for a given part (Part Agent). Part Agent executes a statechart that represents the part's progress through the factory. This design allows further decentralization, if deemed necessary, because it allows for a Workcell Scheduler, which schedules part processing for a given workcell (a workcell consists of all workstations of a given type). With this alternative design, there is no centralized Part Scheduler.

A high-level statechart for the processing of a part in a flexible manufacturing system, which is executed by the Part Agent object, is shown in Figure 15.33 (more detail is provided later, in Figure 15.34). The states are described here. How the Part Agent object transitions between the different states is described in the scenarios in Section 15.6.8.

Figure 15.33. Summary statechart of Part Agent

Figure 15.34. More-detailed statechart of Part Agent

A more detailed statechart for Part Agent is given in Figure 15.34, and the substates for the Part Processing at Flexible Workstation superstate are given in Figure 15.35. In each of these statecharts, both the events and the actions are shown.

Figure 15.35. Statechart of Part Agent: decomposition of Part Processing at Flexible Workstation superstate

The Part Processing at Flexible Workstation superstate is decomposed into the following states (see Figure 15.35):

The communication diagrams for the flexible manufacturing use cases are shown in Figures 15.36 through 15.38. Instead of having one large use case, the flexible manufacturing use cases are divided into the following abstract use cases:

Figure 15.36. Communication diagram for the Start Work Order use case

Figure 15.38. Communication diagram for the Move Part from Workstation use case

Because the use cases are state-dependent, events are shown on both communication diagrams and statecharts. The statecharts are for two particular state-dependent control objects that participate in these use cases: Part Agent and Flexible Workstation Controller. Thus, whenever an event is sent or received by one of these two objects, it is shown on both the communication diagram and the relevant statechart.

This section discusses the dynamic modeling for flexible workstation control—first the statechart for the Flexible Workstation Controller class and then the communication diagram for the Process Part at Flexible Workstation use case.

Statechart for Flexible Workstation Controller

The Flexible Workstation Controller statechart (Figure 15.39) consists of three orthogonal statecharts (Figures 15.40 and 15.41), each of which is depicted as a superstate. The superstates are as follows:

1. Input Stand Superstate. This superstate consists of two substates: Input Stand Available and Input Stand Occupied (see Figure 15.41a).

2. Output Stand Superstate. This superstate consists of two substates: Output Stand Available and Output Stand Occupied (see Figure 15.41b).

3. Flexible Part Processing Superstate. This superstate depicts the different states that a part goes through at a workstation. The Flexible Part Processing superstate contains the following substates (see Figure 15.40). The transitions between the substates are described in the context of the communication diagram (Figure 15.42):

   • Awaiting Part. This is the initial state, in which the workstation is idle, waiting for the arrival of a part.

   • Part Arrived. This state is entered when the workstation receives a message indicating that the next part has been placed on the input stand.

   • Robot Picking. Flexible Workstation Controller is in this state when pick-and-place robot is picking the part off the input stand and bringing it to the work location.

   • Operating on Part. Flexible Workstation Controller enters this state when it receives a message indicating that the part is ready at the workstation. The manufacturing robot is operating on the part.

   • Robot Placing. The pick-and-place robot is placing the part on the output stand. This state is entered when the robot operation has been completed and the output stand is available.

   • Waiting for Output Stand. This state is entered when robot manufacturing has been completed but the output stand is not available.

Figure 15.39. Statechart of Flexible Workstation Controller: high-level statechart

Figure 15.40. Statechart of Flexible Workstation Controller: decomposition of the Flexible Part Processing superstate

Figure 15.41. Statechart of Flexible Workstation Controller: decomposition of the Input Stand and Output Stand superstates

The kernel of the product line consists of those classes that are required by every member of the product line. Thus the classes required to support the common features form the kernel of the product line. The kernel classes of the factory automation software product line are Alarm Handling Server, Workstation Status Server, and Workstation Controller. In order to accommodate all kinds of factory automation systems, Workstation Controller is designed as a generalized abstract workstation controller class, which needs to be specialized into a specific subclass before it can be instantiated. Workstation Controller is specialized to give the following subclasses: Receiving Workstation Controller, Line Workstation Controller, Shipping Workstation Controller, Flexible Workstation Controller, and Monitoring Workstation Controller, as shown in the generalization/specialization hierarchy in Figure 15.43. In addition to being abstract and a kernel class, Workstation Controller is a variation point, so product line variability can be introduced through specialization of this class.

Figure 15.43. Generalization/specialization hierarchy for Workstation Controller

In order to determine the feature/class dependencies, it is necessary to determine the feature/object dependencies first. Thus it is necessary to analyze the dynamic model by considering the communication diagrams for each use case and the feature/use case dependencies. Start by considering the common feature, Factory Kernel, which relates to the four use cases involving the Factory Operator actor: View Alarms, View Workstation Status, Generate Alarm and Notify, and Generate Workstation Status and Notify (see Figure 15.7). The communication diagrams for these four use cases, created during dynamic modeling of the factory automation product line, are shown in Figures 15.21 through 15.24. The software objects that participate in these communication diagrams are Operator Interface, Alarm Handling Server, Workstation Status Server, and Workstation Controller. These four communication diagrams are integrated into a feature-based generic communication diagram as shown in Figure 15.44.

Figure 15.44. Feature-based communication diagram for the Factory Kernel feature

Because Workstation Controller is an abstract class, it does not have any instances; it is therefore necessary to depict an instance of one of its subclasses. For this exercise, the Monitoring Workstation Controller is chosen because it is the simplest to consider first. Usually the objects that participate in kernel use cases are all kernel objects supporting the Factory Kernel common feature. But because the product line needs to allow for factory systems that do not support a user interface (which is provided instead by an external system), it is necessary to categorize the Operator Interface object as an optional object, which supports a separate optional feature (Factory Operations User), as shown in Figure 15.44. Factory Kernel is supported by the two kernel objects: Alarm Handling Server and Workstation Status Server, which is a multi-instance object. Monitoring Workstation Controller is a variant object that supports the alternative feature Factory Monitoring.

The next step is to develop the feature/class dependencies, which follow directly from the feature-based communication diagram. The common Factory Kernel feature and the optional Factory Operations User feature are shown with the classes that support them in the feature-based class diagram in Figure 15.45, which is determined directly from Figure 15.44. The fact that the optional Factory Operations User feature depends on the common Factory Kernel feature is shown by the Is Client of association between the optional Operator Interface class and the kernel Alarm Handling Server and Workstation Status Server classes. Figure 15.45 also depicts the Factory Monitoring feature, which is an alternative feature because it is mutually exclusive with the High-Volume Manufacturing and Flexible Manufacturing features. The Factory Monitoring feature is supported by the variant Monitoring Workstation Controller class, which is a specialized subclass of the Workstation Controller kernel superclass, as shown in Figure 15.45. Thus a superclass can support one feature and be a kernel class while its variant subclasses support different features.

Figure 15.45. Feature-based class diagram for the Factory Kernel feature

Next, consider the optional use cases initiated by Workflow Engineer—that is, Create/Update Operation and Create/Update Workflow Plan (see Figure 15.4). As described in Section 15.3, these use cases are organized into two features: Workflow Management and Workflow Planning User. The communication diagram for the two use cases is depicted in Figure 15.25, which shows four objects: Workflow Engineer Interface, Workflow Plan Server, Manufacturing Operation Server, and Workstation Status Server. Of these four objects, Workstation Status Server has already been categorized as a kernel object. The other three objects are all categorized as optional objects. Because of the need for factory systems without a user interface, however, Workflow Engineer Interface is allocated to a different feature (Workflow Planning User) than the remaining two server objects (Workflow Plan Server and Manufacturing Operation Server), which are allocated to the Workflow Management feature, as shown in the feature-based communication diagram in Figure 15.46.

Figure 15.46. Feature-based communication diagram for workflow and work order features

Consider the optional use case initiated by Production Manager: Create/Modify Work Order. This use case is supported by the communication diagram shown in Figure 15.26. Of the four objects depicted there, Workflow Plan Server has already been allocated to the Workflow Management feature. Following a similar approach to that taken for the Workflow Engineer features, Work Order Server and Part Server are categorized as optional objects that are allocated to the optional Work Order Management feature, and Production Manager Interface is categorized as an optional object allocated to the optional Work Order User feature. The feature-based class diagram for all these features (Figure 15.47) is determined directly from the feature-based communication diagram (Figure 15.46).

Figure 15.47. Feature-based class diagram for workflow and work order features

Consider how the workflow and work order features (those initiated by Workflow Engineer and Production Manager) are used in flexible and high-volume manufacturing systems. The Workflow Planning User and Work Order User features are optional because it is possible to have a system in which workflow plans and work orders are downloaded from an external system and are not created or modified on this system. Of the optional classes shown in Figure 15.47, the server classes (namely, Workflow Plan Server and Manufacturing Operation Server) are always required by flexible and high-volume manufacturing systems and therefore should be kept separate from the client class Workflow Engineer Interface, which is required only sometimes. Thus a Workflow Management feature that includes the Workflow Plan Server and Manufacturing Operation Server classes is defined. This optional class, called Workflow Engineer Interface, is kept separate and is placed in the Workflow Planning User feature.

Now consider the feature/class dependencies that apply to only one kind of factory system. Classes that have already been allocated to kernel and optional features in the previous sections are factored out. For feature/class dependencies determined from the High-Volume Part Processing communication diagrams, the classes Production Manager Interface, Workflow Plan Server, and Manufacturing Operation Server are factored out because they are already in the workflow and work order features. Similarly, for feature/class dependencies determined from the Flexibly Manufacture Part communication diagram, the same three classes are factored out.

Consider the communication diagrams for the high-volume manufacturing use cases. There are four use cases, consisting of one concrete use case (Manufacture High-Volume Part) that includes three abstract use cases (Receive Part, Process Part at High-Volume Workstation, and Ship Part), which are are mapped to the alternative High-Volume Manufacturing feature, as shown in Figure 15.9. The abstract use cases contain all the functionality. The communication diagrams for these use cases are shown in Figures 15.30 through 15.32. The communication diagram for the Receive Part use case has the Production Manager Interface, Receiving Workstation Controller, and Line Workstation Controller objects (see Figure 15.30). The communication diagram for the Process Part at High-Volume Workstation use case has the Line Workstation Controller, Workflow Plan Server, and Manufacturing Operation Server objects (see Figure 15.31). The communication diagram for the Ship Part use case has the Line Workstation Controller, Shipping Workstation Controller, and Production Manager Interface objects (see Figure 15.32 ).

An integrated communication diagram would normally include all the objects from the three use case–based communication diagrams. In the feature-based communication diagram (Figure 15.48), however, the objects that appear in prerequisite communication diagrams are removed. In particular, the Workflow Plan Server, Manufacturing Operation Server, and Production Manager Interface objects are assigned to prerequisite communication diagrams and are thus removed from the feature-based communication diagram for the High-Volume Manufacturing feature. The remaining objects supporting this feature are Receiving Workstation Controller, Line Workstation Controller, and Shipping Workstation Controller.

Figure 15.48. Feature-based communication diagram for the High-Volume Manufacturing feature

The feature-based class diagram (Figure 15.49) is determined from the feature-based communication diagram in Figure 15.48. The class diagram also shows the abstract superclass Workstation Controller, from which the three subclasses Receiving Workstation Controller, Line Workstation Controller, and Shipping Workstation Controller are derived.

Figure 15.49. Feature-based class diagram for the High-Volume Manufacturing feature

Now consider the flexible manufacturing use cases, which support the alternative Flexible Manufacturing feature, as shown in Figure 15.10. The Flexibly Manufacture Part use cases (Start Work Order, Move Part to Workstation, Process Part at Flexible Workstation, and Move Part from Workstation) are mapped to the Flexible Manufacturing feature.

The communication diagrams for the flexible manufacturing use cases are shown in Figures 15.36 through 15.38. The feature-based communication diagram is created by integration of the individual flexible manufacturing communication diagrams and then removal of the objects that have already been allocated to other kernel and optional features—following the approach used in the previous section for the High-Volume Manufacturing feature. The result is shown in Figure 15.50, where all the objects are categorized as optional except for Flexible Workstation Controller, which is a variant class because it is a subclass of Workstation Controller. Further analysis indicates that it is possible for a flexible manufacturing system either to support intermediate storage and retrieval, in which parts are temporarily stored in the ASRS, or not. This refinement leads to two features: Flexible Manufacturing and Storage & Retrieval.

Figure 15.50. Feature-based communication diagram for the Flexible Manufacturing feature

The classes supporting the former feature are Part Scheduler, AGV Dispatcher, Flexible Workstation Controller, Part Agent, and ASRS Handler. The feature-based class diagram for this feature is shown in Figure 15.51.

Figure 15.51. Feature-based class diagram for the Flexible Manufacturing feature

The Store Part and Retrieve Part extension use cases are mapped to the Storage & Retrieval feature, which is supported by the specialized Part Scheduler With Storage class. The feature-based class diagram for this feature is shown in Figure 15.52.

Figure 15.52. Feature-based class diagram for the Storage & Retrieval feature

Storage & Retrieval is an optional feature that requires Flexible Manufacturing as a prerequisite. However, it is also necessary to extend Part Scheduler (which now needs to schedule trips to and from the ASRS) and Part Agent (whose statechart needs to be extended to allow ASRS handling). This extension of functionality could be handled by specialization: having ASRS variants of Part Scheduler and Part Agent. Alternatively, it could be handled by parameterization, meaning that the ASRS functionality is built into the components from the start and then the feature conditions [storage] and [no storage] are used. If the feature condition were set to [no storage], Part Scheduler would never schedule a part to the ASRS; otherwise, if the feature condition were set to [storage], it would. If a part were never scheduled to the ASRS, those states in Part Agent would never be entered. The solution adopted is to use parameterization for Part Agent because the feature conditions [storage] and [no storage] (as depicted on the statechart in Figure 15.35) determine whether or not a part is moved to the ASRS when a workstation is unavailable. Specialization is used for Part Scheduler because the scheduling algorithm needs to be extended to handle intermediate scheduling to the ASRS.

Figure 15.45 shows the static model for the Factory Monitoring feature together with the Factory Kernel feature and the Factory Operations User feature. Grouped together, these three features form the Factory Monitoring System, which is one of the target systems of the factory automation product line. The Monitoring Workstation Controller class in the Factory Monitoring feature is a specialization of the Workstation Controller class in the Factory Kernel feature.

Applying the component structuring criteria, the following components are determined:

Each component is depicted with two stereotypes: the component stereotype (what kind of component it is, as specified by the component structuring criteria) and the product line stereotype (the reuse category—kernel, optional, or variant). The components are structured into the layered architecture such that each component is in a layer where it needs the service provided by components in the layers below but not the layers above. This layered architecture is based on the Flexible Layers of Abstraction pattern, which is a less restrictive variant of the Layers of Abstraction pattern in which a layer can use the services of any of the layers below it, not just the layer immediately below it. This layered architecture, depicted in Figure 15.53, facilitates adaptation of the factory automation software product line architecture to derive individual application members of the product line:

Figure 15.53. Layered architecture of the factory automation software product line (Note: Layers are compressed due to page size.)

If two layers do not depend on each other, such as layers 3 and 4 above, the choice of which layer should be higher is a design decision. In addition to the Layers of Abstraction and Kernel architectural patterns, several other architectural structure patterns are applied in the factory automation software product line architecture:

The major application systems that can be derived from the factory automation software product line architecture are shown in Figures 15.54 through 15.56. These are the static models for factory monitoring systems, high-volume manufacturing systems, and flexible manufacturing systems, respectively. The dependencies between the components are determined by the Layers of Abstraction architecture and are depicted in detail in the static models.

Figure 15.54. Static model of a factory monitoring system

Figure 15.56. Static model of a flexible manufacturing system. (Note: Layers are compressed due to page size.)

The class diagram for the factory monitoring system (Figure 15.54) is developed from the layered architecture of the product line in Figure 15.53, combined with consideration of the components needed by the relevant features in this system. The components and relationships are determined from the corresponding communication diagrams (Figures 15.21–15.24) and the feature/class diagram in Figure 15.45, which incorporates components from the Factory Kernel, Factory Monitoring, and Factory Operations User features. Four executable components and three layers are involved. Both Monitoring Workstation Controller and Operator Interface are clients of the kernel Workstation Status Server and Alarm Handling Server components.

The class diagram for the high-volume manufacturing system (Figure 15.55) has five layers and ten components. In addition to kernel components from Figure 15.45, this architecture incorporates components from the workflow and work order features of Figure 15.47 and the High-Volume Manufacturing feature of Figure 15.49. The Production Management Server component in Figure 15.55 is a composition of Work Order Server and Part Server from Figure 15.47, and the Workflow Planning Server component is a composition of Workflow Plan Server and Manufacturing Operation Server.

Figure 15.55. Static model of a high-volume manufacturing system. (Note: Layers are compressed due to page size.)

The class diagram for the flexible manufacturing system (Figure 15.56) has six layers and twelve components. In addition to kernel components from Figure 15.45, this architecture incorporates components from the workflow and work order features of 15.47 and the Flexible Manufacturing feature of Figure 15.51.

The generic concurrent communication diagrams shown in Figures 15.57 through 15.59 depict the major application systems that can be derived from the factory automation software product line architecture. These diagrams are for factory monitoring, high-volume manufacturing, and flexible manufacturing systems, respectively. The diagrams depict the components structured according to the Layers of Abstraction architecture, but they omit the layer packages to make the communication between components clearer. The concurrent communication diagrams explicitly show the type of message communication—synchronous or asynchronous.

Figure 15.57. Dynamic model of a factory monitoring system

Figure 15.59. Dynamic model of a flexible manufacturing system

The components in the concurrent communication diagram for the factory monitoring system (Figure 15.57) are determined directly from the components in the class diagram in Figure 15.54. The communication between these components is determined from the communication diagrams in Figures 15.21 through 15.24 and the feature-based communication diagram of Figure 15.44, which show the messages passed between the components. Because of the client/server communication, the communication patterns used are Synchronous Message Communication with Reply and Subscription/Notification.

The concurrent communication diagram for the high-volume manufacturing system (Figure 15.58) is determined from the components in the class diagram in Figure 15.55 and the communication diagrams that support the high-volume manufacturing use cases (Figures 15.30–15.32), which show the messages passed between these components. This architecture adds asynchronous message communication between the distributed control components.

Figure 15.58. Dynamic model of a high-volume manufacturing system

The communication diagram for the flexible manufacturing system (Figure 15.59) is determined from the components in the class diagram in Figure 15.56 and the communication diagrams that support the flexible manufacturing use cases (Figures 15.36–15.38), which show the messages passed between these components. This architecture also uses a combination of patterns, with asynchronous communication between the control and coordinator components.

To handle the variety of communication between the components in the software product line architecture, several communication patterns are applied, as depicted on the communication diagrams in Figures 15.57 through 15.59:

The software architecture of each of the main factory automation systems is depicted in Figures 15.60 through 15.62. All the concurrent components communicate through ports. The ports are provided ports that support provided interfaces, required ports that support required interfaces, or complex ports that support both provided and required interfaces. The interfaces are explicitly depicted in subsequent figures. By convention, the name of a port with a provided interface starts with the prefix P (e.g., PAlarmServer), and the name of a port with a required interface starts with the prefix R (e.g., RAlarmServer).

Figure 15.60. Software architecture of a factory monitoring system

Figure 15.62. Software architecture of a flexible manufacturing system

The software architecture of the factory monitoring system (Figure 15.60) depicts two server components that each support one provided port with a provided interface and one complex port with provided and required interfaces. The two client components each support one required port with a required interface and one complex port with provided and required interfaces. In this architecture, it is Monitoring Workstation Controller that sends alarm status and workstation status messages to Alarm Handling Server and Workstation Status Server, respectively.

In the software architecture of the high-volume manufacturing system (Figure 15.61), three different workstation controllers (Receiving, Line, and Shipping) send alarm status and workstation status messages to Alarm Handling Server and Workstation Status Server, respectively. The multiple instances of the Workstation Controller components are connected in series so that they can provide distributed control. For greatest flexibility, each Line Workstation Controller component has a required port to communicate with its predecessor and a provided port to communicate with its successor. The Receiving Workstation Controller component has only a provided port, and the Shipping Workstation Controller component has only a required port.

Figure 15.61. Software architecture of a high-volume manufacturing system

In the software architecture of the flexible manufacturing system (Figure 15.62), Part Agent and Part Scheduler together provide the hierarchical control, controlling the lower-level Flexible Workstation Controller, AGV Dispatcher, and ASRS Handler objects. The lower-level controllers have provided ports to receive the commands sent by Part Agent through its corresponding required ports.

The interfaces for the individual components are depicted in Figures 15.63 through 15.75. For each component port, the required and/or provided interface used by that port is depicted. In addition, the operations provided by each interface are specified. Consider an example of a server component with its ports, interfaces, and operations; consider also the clients that communicate with this server. The example is the Alarm Handling Server component, which has two ports: PAlarmStatus and PAlarmServer (as shown in Figure 15.63). The PAlarmStatus port consists of one provided interface called IAlarmStatus, which provides one operation, called post Alarm. The PAlarmServer port has one provided interface (IAlarmServer) and one required interface (IAlarmNotification). The interfaces and operations are specified as follows:

Figure 15.63. Component interfaces of Alarm Handling Server

These interfaces are used as follows:

In Figures 15.63 through 15.75, each component is depicted with both its ports and its provided and required interfaces. Each interface is explicitly depicted in terms of the operations it provides. Each operation specifies its name, input parameters, and output parameters.

Figure 15.64. Component interfaces of Workstation Status Server

Figure 15.65. Component interfaces of Workflow Planning Server

Figure 15.67. Component interfaces of the Receiving, Shipping, and Line workstation controllers

Figure 15.68. Component interfaces of Flexible Workstation Controller

Figure 15.69. Generalization/specialization hierarchy for Workstation Controller

Figure 15.70. Component interfaces of AGVDispatcher

Figure 15.71. Component interfaces of ASRS Handler

Figure 15.72. Component interfaces of Part Scheduler

Figure 15.73. Component interfaces of Part Agent

Figure 15.74. Component interfaces of Production Management Server

Figure 15.75. Component interfaces of the user interface components