A Virtual Setup for Full-stack Industry 4.0

The main goal of this project was to develop a virtual setup for Industry 4.0, with the aim of applying the simulations in a laboratory context.

Methodology

To simulate the Field level, SimTwo was used. FEUPAutom was chosen to control the various components of the factory. The Manufacturing Execution System level (MES) and the Enterprise Resources level (ERP) were developed with Lazarus and PgAdmin4.

Case Study

Machinery

1) ASRS – This module is composed by: a set of storage rack; a robotic manipulator with 4 degrees of freedom that moves products, parts and raw materials between the mentioned racks and belts.

2) Serial Machines – Includes two hydraulic pressing machines. Two of the belts in this module have the ability to rotate around the vertical axis.

3) Paralel Machines – Consists of two painting ovens. This module not only requires rotating conveyor belts but also ones that slide through one of the horizontal axis.

4) Mount with robotic manipulator – In this module, the same robotic manipulator as in the ASRS module was used, it was also required to include a mounting bench.

5) Input & Output (I/O) - Consists of three actuators that push specific final products out of the main belt and into an exit zone.

Fig.1 - ASRS

Fig.2 - Serial Machines

Fig.3 - Paralel Machines

Fig.4 - Mount with robotic manipulator

Fig.5 - I/O

Parts

In this project, it was required that all of the following parts were endowed with magnetic properties to allow the robot, that incorporates a solenoid, to pick and place these.

1) Raw materials – Cubic solids that can be either blue or green.

2) Work in progress (WIP) after first press – Solid dimensions are changed due to the pressing process.

3) WIP after second press – A small ledge is created due to the action of the second press.

4) Final part – The part described in 3) is submited to one of two possible painting ovens, each with its own paint job

Fig.6 - Parts

Plant Layout and Flow of Parts

For this factory, considering the positioning of all the conveyor belts, machines and rack, the best course the raw material must take to be pressed and then be stored (while there are other pieces leaving the factory) is presented in the following scheme.

That way, there are only two fluxes on the factory and, when they “collide”, they do not interfere with each other. That is, they share the same direction and sense of that flux.

Fig.7 - Best Flow

In the demo, since the raw material only goes through the presses before leaving the factory and never goes to the rack, the used course was the following.

There is only one flux, and it is reduced to a line. There is no collision with itself.

Fig.8 - Flow Used

Production Planning Assumptions

1) The suppliers’ delivery time is 1 week.

2) Planning`s periodicity and time horizon is 1 week.

3) The customers´ delivery time is 2 weeks.

4) The production system has infinite capacity.

5) Make-to-order production system.

6) The suppliers and production system are unreliable.

7) Raw materials are received at the inbound dock station and then transferred to the warehouse by inbound orders.

8) Prior to expedition, customers may change or cancel their orders.

9) The company maintains a safety stock defined for each type of raw material.

Device Level

To build the factory in SimTwo it was necessary to create an XML file necessarily named scene.xml in which the different robots were called and positioned. Each robot is defined in its own XML file and may be made up of:

Solids – Three-dimensional geometries with mass and other physical properties.
Shells – Similar to solids but with no physical properties. Their position is always fixed in relation to a defined solid.
Articulations – These allow the developer to constrain the relative movement between two solids or between a solid and the scene itself, for example a slider type articulation only allows one linear degree of freedom and a hinge type only allows one rotating degree of freedom. Each articulation is associated with a motor and an encoder.
Sensors – There are many types of sensors available in SimTwo. In this project most of the used sensors were of the IRSharp, a proximity sensor.

Control Level

SimTwo

The SimTwo Code Editor features an IDE for high level Pascal control algorithm.

To control the XML Scene, the following functions were used:

1) GetSensorVal(ID_machine,ID_sensor) – Returns the sensor value. The parameters identify the sensor. If sensor value is greater than zero, the sensor state is TRUE, otherwise, the sensor state is FALSE.

2) RCButtonPressed(ID_machine,ID_sensor) - Returns the button state. The parameters identify the button. If thebutton state is TRUE, the button is pressed, if the button state is FALSE, the button is not pressed.

3) SetBeltSpeed(ID_machine,ID_solid,Speed) - Defines the belt speed. The first two parameters identify the belt and the third one defines its speed. It should be noted that the belt speed can be positive or negative, depending on the intended direction of operation.

4) SetAxisVoltageRef(ID_machine,ID_articulation, Voltage)- Applies voltage. The first two parameters identify the reference, and the last parameter defines the voltage value to apply. This function was used to operate the press.

5) SetSolidSize(ID_piece, ID_solid, x,y,z)- Sets the solid size. The first two parameters identify the solid, it is possible to change its dimension on the x-axis, the y-axis, and the z-axis with the last three parameters. This function was used to simulate a pressed part.

The ID of a robot corresponds to the order in which it was declared in scene.xml. To identify a sensor, solid or articulation within a robot, another ID will be required. The second ID corresponds to the order in which the sensor, solid or articulation was declared within its class in the corresponding XML file.

To establish communication through the Modbus TCP protocol, the following functions were used:

6) setModbusInput(Input_Bit, Value) - Sends Boolean value to input bit address. Example:

setModbusInput (Input_Bit , (GetSensorVal(ID_ machine , ID_ arti) > 0));

To send this information to SoftPLC, using the MosBusTCP protocol, we use the function setModbusInput:

The first parameter is the input bit that we are going to change. The second is a Boolean (True or False) which in our case will be changed automatically, for example, by GetSensorVal.

7) getModbusCoil(Output_bit))- Returns value from output bit address. Example:

if (getModbusCoil (Output_bit)) then

SetBeltSpeed (ID_machine, ID_solid, Speed)

else SetBeltSpeed(ID_machine,ID_solid,0);

To control these procedures, we use the getModbusCoil function, which has as a unique parameter the bit that receives the information via ModBus: this function returns a Boolean so we can use it directly in the writing of an actuator.

As we can see in the example: When the bit is active, we operate the machine as intended. When it is inactive, we turn off the actuator.

Once the data is sent by the protocol in question, it can be controlled by any SoftPLC. It just needs to support the ModBusTCP protocol. Our choice was FEUPAutom, which will be explained in more detail below.

It is important to mention that trying to control the simulation of the factory as one is very computationally complex and when data is sent via ModBus, packets are lost when there are FPS breaks. So, the solution would be to use a different computer for each module in the factory. However, for the modules to be connected efficiently, it would be necessary to have an identifier associated with each part, for example an RFID or a QRcode.

FEUPAutom

To be able to effectively control all presses and conveyor belts, FEUPAutom was used. Using its programming language of Sequential Flow Charts, a grafcet was created. It sequentially connects the mats that the piece will have to go through, evolving according to these points:

1) If the conveyor belts sesnor returns the value TRUE (theres a piece on top of it), it will wait for the following mat to be able to receive it.

2) When the next conveyor is empty or already sending a piece, both transporters will start moving. If one of the conveyors are rotative, it will first rotate to align the two. If the conveyor has a press, it will first actuate it to then send the piece.

3) After the piece gets to the second conveyor (it returns the value TRUE), both will stop.

4) Restart with point 4) until the piece gets to the last matt.

Moreover, the grafcet was programed in a way that it was possible to introduce more than one piece. As previously mentioned, the conveyor belt is only able to receive a piece when it becomes free or is already sending another one, which makes it possible to have a maximum number of pieces equal to the number of matts in the factory.

Since the conveyors can receive a piece when already sending another, it is necessary to know that the pieces will move at the same speed. Otherwise, if there are two pieces, one after another, on two conveyors, one will collide with the other. To make sure this does not happen, the conveyors must move at the same speed.

Fig.9 - Grafcet

Operation

DEMO

Pressing Machine + Rotating Belt

MES level

This level’s inputs consist of the number of production orders, inbound orders and expedition orders while the outputs are data on the status of this orders. Its function can be decomposed in four main tasks:

1) Scheduling orders - define the sequence of orders, received from enterprise resource planning (ERP), to meet the production goals, making optimal use of local resources. The are static schedules and dynamic schedulers, with advantages and disadvantages. In this case, a simple heuristic would allow to achieve the ‘almost best sequence’ by resecheduling the orders when previous order finishes and the factory resources are free.

2) Dispatching orders - decide which order must be executed at each moment and adjust orders to unanticipated conditions.

3) Execution of orders - inform other systems about the progress of the orders and performing checks on resources.

4) Collection of data - collection, storage and exchange of process data, equipment status, material information and production logs.

For this to be possible, we must know the flow of each order and consider the following restrictions:

· Inbound area can only receive 1 part at a time.

· Warehouse has a capacity of 54 positions and can only execute an operation at a time.

· A part can only enter into a conveyor if that conveyor is free. Otherwise, it waits at the entrance. This is ensured by the control-level.

· Parts cannot surpass others.

· The defined flow of parts cannot be changed.

· There are 2 cells to paint the part in different colors.

· There are 2 expedition exits.

Note that the MES controls manufacturing operations by sending commands to the PLC (FEUPAutom), such as: ‘Load part’, ‘Unload part’, ‘Inbound part’, ‘Paint part in color A’, ‘Expedite part A’, and receives the location and status of each part by the PLC.

ERP level

This level’s objective is to plan production, supplier and expedition orders in the plant during next week, knowing the quantity and delivery date of each committed customer order and the inventory hold in the warehouse (raw materials and final products).

Database Model

Backoffice administration of data was ensured with a Postgres database. The UML class-diagram is presented.

Fig.10 - UML class-diagram

Specifications

Considering the planning assumptions, the user will interact with the ERP in a cyclical matter which translates into the process detailed in the flowchart. During the week, the user seeks to be aware of the current objectives and recent performance of the factory. Also, manages the entities, mainly for the insertion of customer orders. At the end of the week, reports the fulfilment of weekly objectives and creates the next plan of expedition, production and supplier orders.

1) Update server: introduce database credentials.

2) Be on top of things during week N: a dashboard that provides information on actual stock at warehouse in the beginning of the week, current week’s plan and last 4 week’s report of defective parts, delays on supplier and customer orders.

3) Manage entities during week N: suppliers, orders to suppliers, customers, orders to customers, materials and final products.

4) Report week N: It is possible to proceed to the following week, update the local data structures and update the occurrences, individually, namely:

a) Indicate if the supplier order has been delivered

b) Indicate the number of defective products

c) Confirm expedition orders

5) Plan the next week N+1: create the forecast plan and some other sophisticated features:

a) Notify non-executed expedition orders and the reason

b) Fulfill expediton orders, according to FIFO criteria

c) Reinforce the impact of defective products from previous week in the planning of production orders

d) Select supplier for new orders, based on an heuristic of lowest number of overdue orders. The tiebreaker criteria is to choose the company's supplier with the longest-standing relationship

1.mp4

Database + Manage entities + Be on top of things

2.mp4

Report + Plan + Be on top of things

Fig. 11 - Algorithm based on weekly periodicity

Algorithm

To implement the solution designed a simple algorithm was required. Let variables be defined as:

M_t: stock of raw materials in end of week t

F_t: final ok products in end of week t

O_t: quantity ordered in week t

R_t: quantity received by suppliers in week t

NR_t: quantity not received by suppliers in week t

P_t: quantity produced in week t

Q_t: ok quantity produced in week t

NQ_t: defective quantity produced in week t

NP : auxiliary variable with production orders not executed due to shortage of raw material

E_t: quantity to expedite in period t

NE_t: quantity from weeks previous to week t not yet expedited

Firstly, report week N. By providing NR_t,and NQ_t, the system updates inventory

M_t = M_t - P_{t +}R_t

R_t = O_t-NR_t

F_t = F_t-1- E_{t +}Q_t

Q_t = P_t- NQ_t

Note that we assume, one raw material is need to produce one final product.

Then, an expedition order will be planned for week N+1 per each customer order with delivery date in week N+1. There will be one expedition order per customer order. For this a simple if statement is enough. Note that ∑ NE are previous customer orders not expedited due to product shortage (either from suppliers failing delivery or production of defective parts).

If F_t+1> E_t+1 + NE then

Create expedition order for each open customer order

Else

Create as many expedition orders as possible, according to FIFO criteria

End

Considering production lead time of 1 week, products to be delivered at week N+1 should be produced during week N. Each week, there will be just 1 production order per product type. Consequently, its quantity will equal the sum of the quantities of the expedition orders planned for week N+1.

P_t+1 = E_t+2 + (E_t+1 + NE)_{still open} - F_t

NP = 0

If M_t<P_t+1 then

NP = P_t+1- M_t

P_t+1= M_t

End

At the end of week N, will be issued the supplier orders for the raw materials that will be used in the production orders of week N+2 (equal to customer orders foreseen for week N+3). These orders will be delivered by the suppliers during week N+1.

P_t+2= E_t+3

O_t+1 = P_t+2 + P_t+1-M_t + NP + SS

To sum up, the flow of materials in the supply chain corresponds to a total lead time of 2 weeks. Raw materials ordered at the end of week N arrive in the plant till the end of week N+1. These materials are used in the production orders of week N+2. Finally, the finished products are expedited to customers during week N+3.

Conclusions and future work

To conclude, it is possible to implement a complete virtual factory following the proposed methodology. In the future, it is necessary to implement part identification and to divide the factory into different modules that will connect with each other through different computers.

References

[1] T. K. TRAN, H. YAHOUI and N. SIAUVE, "An interactive approach to teach automation in the training of the industry 4.0," 2019 13th International Conference on Software, Knowledge, Information Management and Applications (SKIMA), 2019, pp. 1-4, doi: 10.1109/SKIMA47702.2019.8982491..

[2] F. Shrouf, J. Ordieres and G. Miragliotta, "Smart factories in Industry 4.0: A review of the concept and of energy management approached in production based on the Internet of Things paradigm," 2014 IEEE International Conference on Industrial Engineering and Engineering Management, 2014, pp. 697-701, doi: 10.1109/IEEM.2014.7058728.

[3] K. J. Valle-Gómez, P. Delgado-Pérez, I. Medina-Bulo and J. Magallanes-Fernández, "Software Testing: Cost Reduction in Industry 4.0," 2019 IEEE/ACM 14th International Workshop on Automation of Software Test (AST), 2019, pp. 69-70, doi: 10.1109/AST.2019.00018.

[4] D. M. F. L. Pereira, "Simulação Hierárquica de Sistema de Produção Miniaturizado" 2013 IFEUP

Page updated

Report abuse