The Production Line System models a plant that generates hammers. There is a generator of heads and another one of handles. These pieces are moved by conveyors until they get on a tray from which they are taken by an assembler. This one produces hammers which finally get on a tray and are collected by an user.
The metamodel of this system is shown here:
The plant is composed of elements which have a specific position. There are different kinds of machines (head generators, handle generators and assemblers), containers (users and containers with a limited capacity, such as trays and conveyors) and parts (head, handles and hammers). They all have a position in the plant, indicated by a set of coordinates. Generators will produce as many parts as their counter indicates and deposit them in conveyors; conveyors move parts from machines to trays with a speed; and assemblers consume parts from trays to create hammers, which are deposited in conveyors and finally collected by users. Parts can be either defective or not. Machines work according to a production time (pt) that dictates the average number of time units that they take to produce a part. They also have an attribute (defective rate) that shows the percentage of defective parts they produce, which depends on their production time (normally, the faster they work the more defective parts they produce). Trays and conveyors may contain parts up to their capacity.
We associate every class of the metamodel with a picture. This graphical concrete syntax will be used for the definition of the behavioral rules.
We have designed seven rules to model the behavior of the system, including the rule that initializes the system.
The InitialRule creates the initial model. There is a machine for producing handles and another that produces heads. The production time of both of them is 40 units of time, and the defective rate is 2%. The assembler also has a production time of 40 units of time and it has a defective rate of 1%. The NAC pattern forbids the triggering of the rule if was already thrown before.
The GenHandle and GenHead rules generate a new handle and head, respectively, every time they are launched. As they are very similar, let us only describe the GenHandle rule. The time it spends when generating a handle depends on its production time attribute (pt). Instead of a fixed time, we use a random value from the interval [hg.pt - 3; hg.pt + 3] to calculate its duration. This is specified using the random(n) function available in e-Motions that returns an integer value between 0 and n. For this rule to be applied, the LHS pattern indicates that the system has to have a HandleGen generator which has to be, in turn, connected to a Conveyor. The LHS pattern has also a condition (see the WITH clause), so the rule will only be applied if the attribute counter of the GenHandle object is greater than 0 and the Conveyor has room for the generated part. In the RHS pattern a new Handle is generated and it acquires the position of the Conveyor connected to the HandleGen machine. For deciding whether the new Handle generated is a defective part or not, we check if a random variable (rdm) is smaller than the defective rate of the generator. If it is, we have a defective Handle, otherwise, we have a normal (nondefective) one. The counter value of the GenHandle is decreased in 1 unit, which models that a new handle has been created.
The Carry rule specifies how a Part is transported from the beginning of a Conveyor to the end of it. In the LHS pattern of the rule, the Part is related to the Conveyor with the parts reference, indicating that the part is placed at the beginning of it. In the RHS pattern, the relation between both objects is outParts, which indicates that the part is placed at the end of the Conveyor and is ready to be transferred to the Tray connected to it. The time this rule spends, which simulates the time needed to move a part through a conveyor, is the corresponding speed of the conveyor (15 time units in this case).
Once there is a Part on a Conveyor ready to be transferred to the Tray connected to the end of it, the instantaneous Transfer rule deals with it. The LHS pattern specifies that this Part must be placed in the outParts part of the Conveyor for this rule to be applied. The rule condition forbids the triggering of the rule when the Tray is full of parts, or when there is only one part needed to reach the capacity of the Tray and the parts on it are of the same type of part p. This last condition, together with the restriction of generators to produce a part when their out conveyor is full, prevents the system from deadlocking: if all the parts in the Assembler’s input Tray were of the same type, the Assembler could not assemble anymore and the production line would stop.
The Assemble rule models the behavior of generating a Hammer from one Head and one Handle. We can see in the LHS pattern that the Tray which is connected to the Assembler has to contain a Head and a Handle. The NAC indicates that this rule cannot be triggered if the Assembler is already participating in an action of type Assemble, i.e., if it is already assembling a Hammer. In the RHS pattern we see how the Head, the Handle and their associated observers have been removed and a new Hammer has been created in the position of the Conveyor connected to the assembler. The defective attribute of the new collected Hammer will be true either if one of the assembled parts (or both) was defective or if the random variable (rdm) is smaller than the defective rate of the Assembler. Analogously to the GenHandle rule, the prodTime variable represents the duration of the rule and depends on the production time of the Assembler. It is in the range [a.pt - 3; a.pt + 3].
The Collect rule models the behavior of the system when the User finally collects an assembled Hammer. The User acquires the position of the Hammer and gets associated to it. The time this rule spends is defined by the Manhattan distance between the Hammer and the User plus one, which is stored in the variable collectTime. There is also a NAC in this rule, which forbids users to collect more than one hammer at a time. This is expressed by an action execution that represents the action (Collect) being executed by the same user (u).
We can configure eMotions launcher to run the simulation as shown in the next figure. Please note that we do not need to specify an initial model of the system since we have a rule that creates it.
The PLS.zip file contains the project with all files required to try this example: the metamodel definition, the graphical concrete syntax for the metamodel and its corresponding behavioral specifications. To import this project, right click on the navigation view Import...-> General -> Existing Projects into Workspace -> Select archive file and then select the PLS.zip.