We designed the production cell using RTEdge. Specifically, we modeled the five major capsules: feed belt, rotary table, robot, press, and deposit belt; and omitted the crane as, similarly to others [49], we found it was unnecessary for our purpose. These are individu-al capsules since they individu-all have to achieve their task independently and they must ensure the correct processing by communication. We assumed movements of a plate in the Pro-duction Cell take time and, similarly to others [49], we assumed specific movements (e.g., travelling on the feed belt to the table) take fixed amounts of time, and different movements require different durations. For example, the forging of a plate in the press needs more time than moving the robot.
We simplified the interactions between the controlling software we model and its envi-ronment made of sensors and actuators. Specifically, we replaced the sensors in the mod-el with actions in the modmod-el thereby simulating how time mod-elapses during those move-ments. As a result, when a capsule in some particular state needs a sensor value to
pro-ceed with the simulation, then it will wait a specific amount of time in its current state before moving to the next state (where the sensor data is used), thereby simulating that there might be a delayed response by the sensor. For instance, the robot must read a sen-sor in order to bring its fist arm next to the press.
Fig. 10. shows an overview of the RTEdge Production Cell model, with its capsules and their communication links. The five primary capsules, representing the belts, table, robot and press are located at the center of the model. The other (surrounding) capsules simu-late the environment, such as the arrival of a psimu-late or movements, as discussed above.
The feed belt communicates with an external capsule to simulate the receipt of a new plate, and it communicates with the rotary table to simulate a plate moving to the table.
The press only communicates with the robot. The robot has to communicate with the ele-vating rotary table and the deposit belt since it also exchanges plates with these capsules.
RTEdge models the behavior of a capsule as a state model. We designed all the com-municating state machines of the model (i.e., the capsules) such that certain safety re-quirements are enforced. Specifically, the capsules communications ensure that specific sequences of signals will be ignored. For instance, the table will not accept a signal speci-fying the arrival of a new plate if it is already holding a plate (i.e., the table waits until it is ready to accept a new plate): as a result, when this is the case, the feed belt stops and waits until the table is again ready to accept a new plate. Table 1 shows each capsule and its corresponding number of states and transitions.
Fig. 10. –Overview of the RTEdge model for the Production Cell
Table 1.—Number of states (total 138) and transitions (total 168) in the capsules of Fig. 10 Capsule Name States Transitions Capsule Name States Transitions
Feed Belt 7 7 A6 9 16
Elevating Rotary
Table 11 11 A7 5 8
Robot 47 47 A11 4 4
Press 14 14 A12 4 4
Deposit Belt 7 7 Add_Plate External 1 1
A1 6 12 Add_Plate Proxy 2 2
A2 9 16 Remove_Plate Proxy 2 2
A3 9 16 Remove_Plate External 1 1
When the Feed_Belt receives a new plate from the proxy on the FB_Proxy port, this makes the belt transition from waitForInput to ReceivePlate: Fig. 12 (a). As a re-sult the belt has a new plate: the transient state RecievePlate has an activity, which code is shown in Fig. 11 (the code updates the feed belt’s local variable). Once the local variables are updated, an activate signal is sent to the feed belt’s actuator to start moving.
As a result the belt transitions from RecievePlate to ActivatyActuator. When ActivatyActuator receives an ack1 signal on port actuator_1, the belt starts moving: this is modeled by the BeltMoving state. To simulate how time passes as
plates move around, we created transients states with attached activities that make time pass. We specified a transient state for each plate movement. BeltMoving simulates the movement of a plate from the beginning of the feed belt to its end. (Recall transient states are distinguished from stable states by their dash border and must be further specified with an activity which code executes while in the state.) The feed belt sends another sig-nal to stop the actuator (i.e., the motor), when the plate reaches the end of the belt, result-ing in the belt transitionresult-ing from DeactivatyActuator The actuator will send an ack-stop signal. As a result the feed belt will be in the ReadyToSendPlate state. At this point, the feed belt has a plate at its end, so it sends a signal to the rotary table, in-forming it that a plate is in the right position. After that, the Ready signal is sent on port ERT_FB to make the table transition from state waitForInput to state ProcessNew-Plate: Fig. 12 (b), bottom right. As a result, the table sends the SendPlate signal to the belt on port FB_ERT, making the belt’s capsule transition to state SendPlate where the belt updates its local variables. After that the plate is sent to the table, resulting in the belt transitioning to the WaitForInput state. As a result the belt is ready to accept a new plate and the table has a new plate.
Fig. 11. Feed Belt activity code to process a new plate.
(a) (b) Fig. 12–Details of the feed belt (a) and rotary table (b) capsules
In Fig. 12 (b), when the table is ready to receive a plate (state ProcessNewPlate), it sends signal SendPlate on port FB_ERT. As a result the table transitions from Pro-cessNewPlate to RecievedPlate where the local variables are updated. The table sends a signal to its actuator to start rotating, resulting in the table transitioning from RecievedPlate to PlateOnTable. Once PlateOnTable receives an ack_Rot_Left on port actuator_7, the table transitions to the StartRotating state. StartRotating simulates the table rotation from the feed belt position to robot position. After a fixed delay (again, we simulate movement with activities on transient states), we consider the table is in the right position to service the robot. Then the table sends another signal to stop its actuator (transition from state StartRotating to state StopRotating), the actuator will send an ack-stop signal. At this point, the table has a plate at the right position to service the Robot. The table sends the robot a signal to in-form it that it has a plate in the right position.