jsimIO Assembly
Last updated
Last updated
The system consists in an assembly line to produce hinges.
The assembly line is composed of a linear conveyor belt, 20 stations and 4 buffers. It is assumed that the buffer of each part feeder has such capacity that there is no starvation risk. In this way it is possible to exclude the feeding system from the analysis of the system. The time required for each task is considered deterministic thanks to the high level of automation.
The stations are subject to failures.
Import the libraries required to instantiate the objects, perform the simulation and export the log file.
Define and initialize the objects required: Model, Source, Station, Sink, Fork, Part. Buffers are included in the object Station. Each instance has to be linked with the model taken into consideration.
Each machine is modelled as a station with fixed processing time and unitary capacity. The assembly process is not considered when building the stations, but it is defined by ad-hoc objects (Join).
The rotating transfer station is modelled as a set of machines, each one representative of one available position in the rotating table.
The conveyor belt acts also as buffer and processes the parts with a FIFO logic. Each buffer is modelled as a set of 5 machines with unitary capacity, each one representative of one available space. The number of available spaces depends on the distance between each set of stations.
The Fork allows to split the final product into its components. This procedure is required by the software, which needs the fork object if at least a join exists.
Define the different parts required for the assembly. The final product (final) is generated by the source. All the other components are generated from final by the fork. The first two components, are joined into "final" after the first Join. The only interarrival time that will be considered by the model is the one of Final Product, in fact each component is created in the simulation by the object fork from the object final.
Define the Joins, that are (# of "component" -1) that generate "final" everytime two components are joined.
Define the processing time of machines (buffers and conveyors included). The rotating buffer and the conveyor have a fixed processing time to take into account the transportation time required to move the pallets along a single position.
Define the routing of the parts with the successors of each instance. The source is connected to the fork, and the fork then is connected to each join (starting from component_b-join1). The fork takes the first component (component_a) and is connected with the following production machine, in this phase component_a represents the frame.
The Joins are visited just before the corresponding assembly machine, in this way each assembly operation can happen only if both the required parts are available in the needed position of the line. Each Join takes "final" as the output of the asembly operation and links it to the successive station.
Run the simulation.
A folder named "nameof_model""date"_"time" is created.
It contains an input file .jsimg for the simulation in JSIM, a file .jsim with the results of the simulation and a file .csv containing the log of the simulation.
The LOG table is created as shown below. The columns indicate in order:
Loggername: referred to the name of the station
Timestamp
Job_ID: referred to the number of the job
Class_ID: referred to the name of the part type.
This is part of the JsimGraph model created.
Among the evaluated performances, the throughput can be visualised as below:
Since JSIM automatically ends the simulation based on a spectral analysis of the output to ensure that the system reaches the steady state, the time and power of the processor required to get the results could be unavailable. To solve this issue some options to limit the number of processed samples, the number of events occurred in the system, the simulated time either the real time of execution can be implemented.
They have to be declared in substitution of the default values, then the model instance has to be defined by specifying these options.
Another way is to limit directly the RAM used by the device to address the simulation. This is a rough approach that does not allow the user to keep the control on the options of the simulation, so the first one is to be preferred.
