System and method for controlling a transmitter in a virtual environment

Abstract

Systems and methods for controlling conveyors in a virtual environment are disclosed. A system for controlling conveyors in a virtual environment includes a twin model module including control logic and configured to virtualize a control system for conveyors installed in a plant. The system also includes a digital plant module configured to virtualize a conveyor installed in the plant and create a virtual plant model controlled by the twin model module. The virtualized conveyor includes a plurality of paths formed by joint-based splitting of the conveyor. The twin model module is configured to control a transport path of the product based on the joint.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to Korean Patent Application No. 10-2023-0139557, filed on October 18, 2023, which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present disclosure relates to systems and methods for controlling a conveyor in a virtual environment. Background Art

[0004] Digital twin technology involves creating a virtual representation of a facility or plant in a virtual space, where the virtual representation is the same or similar to the actual facility or plant in order to conduct various simulations for testing purposes. This technology has been introduced and used across different fields, including manufacturing, aviation, construction, healthcare, energy, defense, urban planning, etc.

[0005] Digital twin technology enables monitoring the status of facilities or systems in virtual space to identify the time for maintenance or repair. Digital twin technology also facilitates testing of various situations that may occur during operation, allowing accidents to be prevented in advance and the risk of accidents to be reduced. In addition, this technology can improve productivity, optimize facilities and significantly reduce the cost and time associated with manufacturing trial products.

[0006] This digital twin system can be implemented on a personal computer or on a server. Users can use a personal computer or access a related server to simulate a virtual factory to test the actual factory.

[0007] The virtual factory may include a conveyor for conveying products as basic components constituting a warehouse. Through the conveyor, the conveying flow of products can be controlled in the virtual factory environment, and the virtualized conveyor allows effective simulation of the virtual factory.

[0008] The discussion in this section is intended only to provide background information and does not constitute an admission of prior art. Summary of the invention

[0009] Embodiments of the present disclosure provide a system and method for controlling a conveyor in a virtual environment, which can effectively control a virtual conveyor in a virtual factory by dividing the virtual conveyor into a plurality of paths based on joints and controlling the conveying paths of products.

[0010] Other embodiments of the present disclosure provide systems and methods for controlling a conveyor in a virtual environment, wherein a control system and a physical plant of a plant may be virtualized in separate modules, respectively.

[0011] The technical tasks of the present disclosure are not limited to those tasks mentioned above. From the following description, ordinary technicians in the field to which the present disclosure belongs should more clearly understand other technical tasks not mentioned above.

[0012] According to one aspect of the present disclosure, a system for controlling a conveyor in a virtual environment is provided. The system includes: a twin model module, which includes control logic and virtualizes the control system of a conveyor installed in a factory. The system also includes a digital factory module, which virtualizes the conveyor installed in the factory and creates a virtual factory model controlled by the twin model module. The virtualized conveyor includes a plurality of paths formed by dividing the conveyor based on joints. The twin model module can control the conveying path of the product based on the joint.

[0013] In an embodiment, when a product is conveyed through multiple paths included in a conveyor, the twin model module can verify whether the distance between the product and the previous product is within a predetermined range, and when the distance is within the predetermined range, the product in conveyance is stopped by controlling the control logic.

[0014] In an embodiment, the predetermined range may correspond to a safety distance set to prevent a collision with a previous product.

[0015] In an embodiment, the plurality of paths may include at least one straight path and at least one turning path.

[0016] In an embodiment, the twin model module may set at least one of a length, a slope angle, and a moving speed for each straight path.

[0017] In an implementation, the twin model module may set at least one of a turning segment, a turning angle, and a moving speed for each turning path.

[0018] In an embodiment, the twin model module may set a conveying path of a product conveyed by a conveyor based on a combination of a plurality of paths.

[0019] In an embodiment, a direction changing unit for changing the direction may be provided in each joint.

[0020] In an embodiment, the direction changing unit comprises a barcode or a barcode reader.

[0021] In an embodiment, the barcode may include information on whether to change the direction.

[0022] In an embodiment, when it is verified as a result of barcode scanning that the product being conveyed is not an object of direction change, the twin model module may control the product being conveyed to go straight through the control logic.

[0023] In an embodiment, when it is verified as a result of barcode scanning that the number of products on the entrance section of the conveyor is equal to or greater than a predetermined number, the twin model module may control the products in the conveyor to move straight through the control logic.

[0024] In an embodiment, when it is verified as a result of barcode scanning that it is not the turn for the product to enter, the twin model module can control the product in the conveyance to go straight through the control logic.

[0025] In an embodiment, when it is verified as a result of barcode scanning that the product being conveyed is a subject of direction change, the twin model module may control the product being conveyed to change its direction through control logic.

[0026] In an embodiment, a system for controlling a conveyor in a virtual environment may include a plurality of twin model modules, and may further include a simulator module for controlling the plurality of twin model modules.

[0027] In an embodiment, multiple twin model modules are executed on at least one graphics processing unit (GPU) server, and when a first twin model module among the multiple twin model modules is executed, the simulator module can assign resources in at least one GPU server for executing the first twin model module.

[0028] In an embodiment, the simulator module may set conditions for control logic for each twin model module to control the virtual factory.

[0029] In an embodiment, the simulator module may create a web page to set the condition of the control logic, and set the condition of the control logic using a setting value input through the web page.

[0030] In an embodiment, each twin model module and digital factory module can communicate with each other using any one of the interfaces including remote procedure call (RPC), RestAPI, socket, Kafka, and message queue (MQ).

[0031] In an embodiment, the factory may include a production factory or a logistics factory.

[0032] In an implementation, the digital factory module may report the result corresponding to the control command to the twin model module connected to the digital factory module.

[0033] In embodiments, product boxes may be used to deliver the product.

[0034] According to another aspect of the present disclosure, a method for controlling a conveyor in a virtual environment is provided. The method includes: registering and initializing a model for a digital factory including a virtualized conveyor through a simulator module, the virtualized conveyor being a virtual representation of a conveyor installed in an actual factory. The method also includes requesting the start of a simulation from a twin model module by the simulator module, the twin model module being a virtual representation of a control system for a factory. The method further includes generating control logic for the digital factory by the twin model module. The method further includes transmitting, by the twin model module, commands generated based on the control logic to the digital factory module. The method also includes processing, by the digital factory module, operations corresponding to commands received from the twin model module for simulation. The virtualized conveyor is divided into multiple paths based on joints, and the twin model module can control the conveying path of the product based on the joints.

[0035] In an embodiment, when a product is conveyed through multiple paths included in a conveyor, the twin model module can verify whether the distance between the product and the previous product is within a predetermined range, and when the distance is within the predetermined range, the product in conveyance is controlled to stop through control logic.

[0036] In an embodiment, the predetermined range may correspond to a safety distance set to prevent a collision with a previous product.

[0037] In an embodiment, the plurality of paths may include at least one straight path and at least one turning path.

[0038] In an embodiment, the twin model module may set at least one of a length, a slope angle, and a moving speed for each straight path.

[0039] In an embodiment, the twin model module may set at least one of a turning segment, a turning angle, and a moving speed for each turning path.

[0040] In an embodiment, the twin model module may set a conveying path of a product conveyed by a conveyor based on a combination of a plurality of paths.

[0041] In an embodiment, a direction changing unit for changing the direction may be arranged in each joint.

[0042] In an embodiment, the direction changing unit comprises a barcode or a barcode reader.

[0043] In an embodiment, the barcode may include information on whether to change the direction.

[0044] In an embodiment, when it is verified as a result of barcode scanning that the product being conveyed is not an object of direction change, the twin model module may control the product being conveyed to go straight through the control logic.

[0045] In an embodiment, when it is verified as a result of barcode scanning that the number of products on the entrance section of the conveyor is equal to or greater than a predetermined number, the twin model module may control the products in the conveyor to move straight through the control logic.

[0046] In an embodiment, when it is verified as a result of the barcode scanning that it is not yet the turn for the product to enter, the twin model module can control the product in the conveyance to go straight through the control logic.

[0047] In an embodiment, when it is verified as a result of barcode scanning that the product being conveyed is a subject of direction change, the twin model module may control the product being conveyed to change its direction through control logic.

[0048] In an embodiment, the factory may include a production factory or a logistics factory.

[0049] In an implementation, the digital factory module may report the result corresponding to the control command to the twin model module connected to the digital factory module.

[0050] In embodiments, product boxes may be used to deliver the product.

[0051] As described above, the embodiments of the present disclosure achieve effective control of a virtual conveyor in a virtual factory by dividing the virtual conveyor into a plurality of paths based on joints to control the conveying path of a product.

[0052] Furthermore, embodiments of the present disclosure also enable various combinations of control systems and plants to be simulated by virtualizing each of the plant's control systems and each of the physical plants as separate modules.

[0053] In addition to the above-mentioned effects, various other effects directly or indirectly understood from the present disclosure can be provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order that the present disclosure may be better understood, various forms of the present disclosure given by way of example will now be described with reference to the accompanying drawings, in which:

[0055] Figure 1 is a diagram illustrating a concept of comparison between a virtual space and a real space according to an embodiment of the present disclosure;

[0056] Figure 2 is a flowchart showing a control process of a digital twin system according to an embodiment of the present disclosure;

[0057] Figure 3 is a block diagram illustrating a digital twin system according to an embodiment of the present disclosure;

[0058] Figure 4is a block diagram illustrating a digital twin system according to an embodiment of the present disclosure;

[0059] Figure 5 is a diagram showing a combination of a twin model and a digital factory according to an embodiment of the present disclosure;

[0060] Figure 6 is a diagram showing a process for simulating a factory according to an embodiment of the present disclosure;

[0061] Figure 7 is a diagram illustrating a concept of simulation of a plant according to an embodiment of the present disclosure;

[0062] Fig. 8A A diagram illustrating a concept of simulating a factory using a simulator according to an embodiment of the present disclosure;

[0063] Figure 8B A diagram illustrating a concept of simulating a factory using a twin model according to an embodiment of the present disclosure;

[0064] Fig. 9 is a diagram illustrating operations or steps of editing and managing the configuration of each model according to an embodiment of the present disclosure;

[0065] Fig.10 is a diagram showing setting values ​​for configuration of each model according to an embodiment of the present disclosure;

[0066] Fig.11 is a flowchart illustrating operations or steps of editing and managing the configuration of each model according to an embodiment of the present disclosure;

[0067] Fig.12 is a diagram showing a structure for generating a set of configurations according to an embodiment of the present disclosure;

[0068] Fig.13 is a diagram illustrating editing a set of configurations according to an embodiment of the present disclosure;

[0069] Fig.14 is a diagram showing a flow of processing data according to an embodiment of the present disclosure;

[0070] Fig.15 is a diagram illustrating a method of processing data according to an embodiment of the present disclosure;

[0071] Fig.16 is a diagram illustrating a method of generating an index of simulation results according to an embodiment of the present disclosure;

[0072] Fig.17A and Fig. 17B A diagram showing a system for controlling a conveyor in a virtual environment according to an embodiment of the present disclosure;

[0073] Fig.18 is a flowchart showing a control process of a conveyor according to an embodiment of the present disclosure;

[0074] Fig.19 is a diagram showing program logic for controlling a transport mechanism in a virtual environment according to an embodiment of the present disclosure;

[0075] Fig. 20 is a flowchart showing a control process of a conveyor according to an embodiment of the present disclosure;

[0076] Fig.21 is a flowchart showing a control process of a conveyor according to an embodiment of the present disclosure;

[0077] Fig. 22 is a flowchart showing a control process of a conveyor according to an embodiment of the present disclosure;

[0078] Fig.23 is a flowchart showing a control process of a conveyor according to an embodiment of the present disclosure; and

[0079] Fig.24 is a configuration diagram of hardware of a computing device according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0080] Hereinafter, embodiments of the present disclosure are described in detail with reference to the accompanying drawings. Advantages and features of the present disclosure and methods for achieving them should be more clearly understood by referring to the accompanying drawings and the embodiments described below.

[0081] However, the present disclosure is not limited to the embodiments disclosed below, but can be implemented in various types of embodiments that are different from each other. These embodiments are provided only to complete the present disclosure and to fully teach the scope of the present disclosure to those of ordinary skill in the art to which the present disclosure belongs. The present disclosure is limited only by the scope of the claims and their equivalents.

[0082] In describing the present disclosure, detailed description of well-known configurations or functions related to the present disclosure is omitted if it is determined that the detailed description will unnecessarily obscure the gist of the present disclosure. Hereinafter, embodiments of the present disclosure are described with reference to the accompanying drawings.

[0083] When a component, device, module, element, etc. of the present disclosure is described as having a purpose or performing an operation, function, etc., the component, device, or element should be considered herein as being “configured to” satisfy the purpose or perform the operation or function.

[0084] Hereinafter, embodiments of the present disclosure are described in detail with reference to the accompanying drawings.

[0085] Figure 1 is a diagram illustrating a concept of comparison between a virtual space and a real space according to an embodiment of the present disclosure.

[0086] Reference Figure 1 The digital twin system can be realized by simulating a virtual facility or a virtual factory in the virtual space 110 that is identical or similar to the actual facility in the actual space 120 .

[0087] According to an embodiment, the factory 123 in the actual space may be controlled by the factory control system 122. The administrator 124 may set up a control logic (or business logic) or input a control command through an input device of the factory control system 122. The factory control system 122 may generate commands for various operations or steps according to the established control logic to control various parts of the factory 123. For example, the factory control system 122 may cause the delivery of a product or control the movement of a robot according to a specific control logic. In the embodiment described below, the factory 123 may include a production plant or a logistics plant. However, the present disclosure is not limited thereto. For example, all physical facilities that can be controlled by a control logic may be included in the factory of the present disclosure.

[0088] According to an embodiment, the factory 123 in the actual space 120 may be virtualized as a digital factory 113. The digital factory 113 may include a software and / or hardware module that virtualizes the factory 123 in the actual space 120 so as to be simulated by a computer or a server. Therefore, the digital factory 113 may be referred to as a digital factory module. However, the present disclosure is not limited to this term.

[0089] According to an embodiment, the plant control system 122 in the actual space 120 may be virtualized as a twin model 112. The twin model 112 may include a software and / or hardware module for virtualizing the plant control system 122 in the actual space 120 for simulation by a computer or server. Therefore, the twin model 112 may be referred to as a twin model module. However, the present disclosure is not limited to this term.

[0090] According to an embodiment, the twin model 112 may be controlled by a simulator 111. The simulator 111 may include a software or hardware module. The simulator 111 may be referred to as a simulator module. However, the present disclosure is not limited to this term.

[0091] According to an embodiment, multiple twin models 112 can control multiple digital factories 113 respectively. The simulator 111 can create multiple digital factories 113 for simulation (e.g., through virtualization of 3D modeling) by managing multiple twin models 112. The user can access the simulator 111 through the user terminal 114. The user can access the simulator 111 through the user terminal 114 to input various configurations for simulating the digital factory 113. Example embodiments in this regard are described in more detail below.

[0092] Figure 2 is a flowchart illustrating a control process of a digital twin system according to an embodiment of the present disclosure.

[0093] Reference Figure 2 According to an embodiment, in operation or step 201, the simulator 111 may register a model for simulating and setting up initial data about a digital factory. In operation or step 203, the simulator 111 may request to start simulation from a specific twin model 112 (e.g., a first twin model) among multiple twin models. In operation or step 205, the twin model 112 may generate control logic (or business logic) in response to a request from the simulator 111. According to another embodiment, the twin model 112 may generate control logic before the simulator 111 requests to start simulation and confirm the generated control logic in response to the request to start simulation. In operation or step 207, the twin model 112 may sequentially generate commands for controlling the factory based on the generated control logic, and then transmit the generated commands to the relevant digital factory 113 (e.g., the first digital factory) among multiple digital factories. In operation or step 209, the digital factory 113 may receive commands for controlling the factory from the twin model 112 and perform operations based on the received commands. For example, the digital factory 113 may convey products, operate conveyor belts, or operate robots according to commands.

[0094] According to an embodiment, in operation or step 211, the digital factory 113 may report the result of the operation to the twin model 112 or the simulator 111 in real time. In operation or step 213, the twin model 112 may transmit the result of the operation received from the digital factory 113 to the simulator 111 as log data. After the digital factory 113 has performed the operation according to the command based on the control logic as described above, the simulation may be terminated in operation or step 215. When the simulation is terminated, in operation or step 217, the twin model 112 may transmit the result data to the simulator 111. In operation or step 219, the simulator 111 may generate the result of the analysis simulation based on the log data and / or result data received from the twin model 112 or the digital factory 113, and may output the generated result.

[0095] Figure 3 is a block diagram illustrating a digital twin system according to an embodiment of the present disclosure.

[0096] refer to Figure 3 , the digital twin system according to the embodiment may include a central processing unit (CPU) server 310 and a graphics processing unit (GPU) server 320. In addition, the CPU server 310 may be operated in conjunction with an external related system 330 (e.g., an advanced planning and scheduling system (APS) (production planning system) 331, a manufacturing execution system (MES) (factory management system) 332, an enterprise resource planning (ERP) 333, a warehouse control system (WCS) 334, a programming logic control (PLC) 335, or an automatic control system (ACS) (robot control system) 336). The CPU server 310 may include a simulator 111 and a database 313. In addition, the CPU server 310 may also include a visualization module 311, a conversion module 312, a studio program 314, and a core program 315. The simulator 111 may communicate with the external related system 330 through an API gateway.

[0097] According to an embodiment, the GPU server 320 may include multiple twin models 112 and multiple digital factories 113. Each twin model 112 and each digital factory 113 may be connected to each other to simulate a virtual factory. For example, the GPU server 320 may include multiple combinations of twin models 112 and digital factories 113 to simulate multiple virtual factories. According to an embodiment, the following reference Figure 5 Embodiments in this regard are described in more detail.

[0098] According to an embodiment, each twin model 112 and each digital factory 113 can communicate with each other using any one of the interfaces including remote procedure call (RPC) (e.g., gRPC), RestAPI, Socket, Kafka, and message queue (MQ). For example, the first twin model 112a can communicate with the first digital factory 113a via the RPC interface, the second twin model 112b can communicate with the second digital factory 113b via the RPC interface, the third twin model 112c can communicate with the third digital factory 113c via the RPC interface, and the fourth twin model 112d can communicate with the fourth digital factory 113d via the RPC interface.

[0099] According to the implementation mode, Figure 3As shown, each twin model 112 can communicate with the simulator 111 of the CPU server 310 directly or through the model manager 321. For example, the first twin model 112a can communicate with the first model manager 321a through a RESTful API, and the first model manager 321a can communicate with the simulator 111 through a RESTful API. The second twin model 112b can communicate with the second model manager 321b through a RESTful API, and the second model manager 321b can communicate with the simulator 111 through a RESTful API. The third twin model 112c can communicate with the third model manager 321c through a RESTful API, and the third model manager 321c can communicate with the simulator 111 through a RESTful API. The fourth twin model 112d can communicate with the fourth model manager 321d through a RESTful API, and the fourth model manager 321d can communicate with the simulator 111 through a RESTful API. In the embodiment described below, an example is provided in which the first twin model 112a and the first digital factory 113a operate through the first model manager 321a, which corresponds to the first node 320a. The same or similar operations may be performed in the remaining nodes 320b, 320c, 320d.

[0100] According to an embodiment, the simulator 111 may send messages related to the progress of the simulation to each twin model 112. For example, the simulator 111 may send a request message for starting, stopping, restarting, or checking the status of the simulation to each twin model 112. The request message may include at least one of the type of module (e.g., a twin model (TM) or a digital factory (DF)), an Internet Protocol (IP) address, a port, and build version information. Each twin model 112a, 112b, 112c, 112d in the plurality of twin models 112 may receive a request message from the simulator 111 and perform processing corresponding to the request.

[0101] According to an embodiment, the digital factory 113 may receive commands from the twin model 112 based on the control logic and perform operations corresponding to the received commands. The log data 322a generated during the simulation performed in the first twin model 112a or the first digital factory 113a may be collected by the collection module 323a and transmitted to the conversion module 312 of the CPU server 310. The conversion module 312 of the CPU server 310 may convert the collected log data 322a into processable data. The visualization module 311 may create a visual image of the data with simulation results based on the data converted by the conversion module 312. According to different embodiments, at least one CPU 324 (e.g., 324a, 324b, 324c, 324d) may be connected to each node in the GPU server 320 to process operations related to the conduct of the simulation.

[0102] According to the implementation mode, Figure 3 As shown, at least one GPU server 320 may include multiple nodes 320a, 320b, 320c, 320d configured to implement simulations of various digital factories (e.g., 3D digital factories). In addition, according to an embodiment, a single simulator 111 included in the CPU server 310 can manage and control multiple nodes 320a, 320b, 320c, 320d configured to perform simulations. For example, the simulator 111 can check and manage the state of each simulation performed in each of the multiple nodes 320a, 320b, 320c, 320d of the GPU server 320 in real time, and control the operation of each simulation. When the GPU server 320 is restarted due to a problem with the GPU server 320, even if the server cannot be logged in due to a lack of a server administrator, the simulator 111 can perform the simulation normally. According to an embodiment, a model agent can be developed in the form of at least two Windows services. For example, a Windows service can be provided to communicate with the simulator 111 via a RESTful API, and another Windows service can be provided to check whether the actual simulation process is performed normally, otherwise drive or restart is executed. Here, commands between Windows services can be handled by inter-process communication (IPC) and can involve Windows services installed in each node and model manager to centrally control and monitor them. Figure 4 A more detailed description is given in this regard.

[0103] According to the implementation mode, Figure 3As shown, when the service is driven normally, the Windows service implemented in the GPU server 320 can be automatically executed even if the Windows service is not logged in. Therefore, even when the GPU server 320 needs to be restarted due to a specific reason and cannot be logged in to the server due to the lack of a server administrator, the GPU server 320 can receive commands related to the conduct of the simulation. In addition, since the simulation is a process performed by the Windows service, the simulation process can be directly controlled remotely (for example, by the simulator 111) even if there is no direct access to the Windows server. According to an embodiment, the CPU server 310 can be a Linux server. However, the present disclosure is not limited to this.

[0104] Figure 4 is a block diagram illustrating a digital twin system according to an embodiment of the present disclosure.

[0105] Reference Figure 4 , the simulator 111 may be implemented in a CPU server. The simulator 111 may include a simulator network 411, a simulator core 412, a simulator data logic 413, a simulator runner 414, and a model manager 415. The GPU server may include a plurality of nodes 320a, 320b, 320c. Each node 320 may include a model agent 421, a twin model 112, and a digital factory 113. For example, the first node 320a may include a first model agent 421a, a first twin model 112a, and a first digital factory 113a. The second node 320b may include a second model agent 421b, a second twin model 112b, and a second digital factory 113b. The third node 320c may include a third model agent 421c, a third twin model 112c, and a third digital factory 113c.

[0106] According to an embodiment, the simulator 111 may communicate with a module (e.g., the twin model 112 or the digital factory 113) included in each node 320 directly or through the model manager 415. For example, the simulator runner 414 of the simulator 111 may perform operations related to the simulation, and the model manager 415 may perform connection or communication with each of the plurality of nodes 320 to enable the plurality of nodes 320 to share functions.

[0107] According to an embodiment, the simulator 111 may perform a health check (normal operation check) of each node 320 through the model manager 415. For example, the simulator 111 may send a request message related to the progress of the simulation (e.g., a request message including the start, stop, restart, or health check of the simulation) to each model agent 421 of each node 320 through the model manager 415. The request message may include at least one of the type of module (e.g., a twin model (TM) or a digital factory (DF)), an Internet Protocol (IP) address, a port, and build version information. Each twin model 112 may receive a request message from the simulator 111 and perform processing corresponding to the request. For example, each node 320 may check its status and report to the simulator 111 whether the node is operating (e.g., the result from an operation, reoperation, or stop command).

[0108] Figure 5 is a diagram illustrating a combination of a twin model and a digital factory according to an embodiment of the present disclosure.

[0109] refer to Figure 5 When a digital twin system is implemented according to an embodiment, various virtual factories can be implemented by separating a module for controlling a factory system and a module for virtualizing a factory. For example, the twin model 112, which is a virtual representation of a factory control system, can generate a command for executing a control logic (or business logic) and transmit the command to the digital factory 113. The digital factory 113, as a physical engine that executes the command received from the twin model 112, can virtualize the relevant factory and perform simulation. Therefore, Figure 5 As shown, various types of simulations can be performed by implementing the components responsible for control logic and the components responsible for executing commands in separate modules.

[0110] For example, a combination in which the management system for warehouse A is set as the first twin model 511 and warehouse a for large products and warehouse b for medium products are set as the first digital factory 512 may be simulated; a combination in which the management system for warehouse A is set as the second twin model 521 and only warehouses for large products are set as the second digital factory 522 may be simulated; a combination in which the management system for warehouse A is set as the third twin model 531 and only warehouse b for medium products is set as the third digital factory 532 may be simulated; or a combination in which the management system for warehouse B is set as the fourth twin model 541 and only warehouse b for medium products is set as the fourth digital factory 542 may be simulated. The simulator 111 may combine the twin models 511, 521, 531, 541 and the digital factories 512, 522, 532, 542 in various ways.

[0111] Therefore, by implementing a twin model as a virtual representation of a plant control system and a digital factory as a virtual representation of an actual factory in separate modules, it is possible to design an architecture for flexible simulation of a factory. For example, there may be common logic or common facilities that can be applied to each factory in the simulation. Here, according to an embodiment, separating the components responsible for logic and the components responsible for execution enables the use of common logic or common facilities without implementing new logic or equipment for each factory simulation project. As described above, the twin model is a virtual representation of the plant control system of the actual system. The twin model can copy the logic and data of the system. In addition, instead of simply performing calculations using algorithms, the twin model 112 can perform a higher level of simulation by reflecting the control logic (or business logic). The digital factory 113 can embody a 3D virtual factory based on a physical engine and build a factory environment identical to reality based on a CAD drawing. According to an embodiment, the twin model 112 and the digital factory 113 are connected through an RPC communication interface. As described above, the twin model 112 can transmit commands to the digital factory 113, and the digital factory 113 can report the results based on the commands to the twin model 112.

[0112] Figure 6 is a diagram illustrating a process for simulating a factory according to an embodiment of the present disclosure.

[0113] refer to Figure 6 , for example, if the factory is a production factory, data related to the work organization for simulation can be input 601, and if the factory is a logistics factory, data related to the logistics order for simulation can be input 601. As described above, the digital twin system 600 according to the embodiment can be implemented in separate modules of the twin model 112 and the digital factory 113. The twin model 112 can generate commands for operating in the digital factory 113 based on the input data (e.g., control logic). The data processed in the twin model 112, that is, condition-based logical data, may include internal logical data or link logical data. The digital factory 113 can be simulated based on the commands received from the twin model 112. The data processed in the digital factory 113 (i.e., dynamic result data based on a physical engine) may include data for 3D visualization, data related to working time, data related to working methods, etc. However, the present disclosure is not limited thereto.

[0114] According to an embodiment, the result data 602 generated by the digital twin system 600 through the simulation operation can be transformed into the processing result data 603 through the analysis and processing of the data analysis module 620. For example, the data generated in the digital twin system 600 may include the operating rate of each workshop, the on-time component release rate, the average processing time, etc. in the case of a logistics warehouse, and may include the unit component supply time, the unit port component waiting time, etc. in the case of a production plant. However, the present disclosure is not limited to this. The data processed by the data analysis module 620 may include the minimum number of workers required for the daily production target, the processing volume that can be handled when a specific facility problem occurs, the best method for storing components in an automatic warehouse to produce various types of vehicles, etc. However, the present disclosure is not limited to this.

[0115] According to an embodiment, the result data 602 generated in the digital twin system 600 may be fed back to the verification request module for verification, and the verification request module may perform verification in conjunction with the relevant system 330 (e.g., APS 331, MES 332, ERP 333, WCS 334, PLC 335, or ACS 336). The data analysis module 620 may input improved input values ​​reflecting the analysis results into the digital twin system 600, and this realizes continuous realization of the simulation. In addition, the data analyzed and processed by the data analysis module 620 may be provided as a basis for decision making that may be reflected in the plant control system of the actual plant 120.

[0116] Figure 7 is a diagram illustrating a concept of simulation of a plant according to an embodiment of the present disclosure.

[0117] refer to Figure 7 As described above, according to an embodiment, by constructing an architecture for flexible plant simulation, results from various scenarios can be confirmed or data can be verified using a virtual space and a simulator. For example, as described above, by establishing a similar environment about a desired scenario in a digital twin system and performing simulation, the results can be verified.

[0118] According to an embodiment, as an example of scenario 710, when a user wants to confirm or verify "if the order is placed using the logistics order data I created, is there any problem with the issuance of the component?", as described above, the user can use the twin model 112 and the digital factory 113 in the digital twin system 600 to simulate and verify the result data. For example, as the result data from the simulation, the comparative rate of the logistics order data and the actual component supply (for example, data including bottlenecks, delays, processing speeds, operating rates of each facility, etc.) can be verified. By viewing the result data, users who use the digital twin system 600 for simulation can verify whether the product can be supplied and optimize the configuration of the logistics facilities. In addition, the user can improve the logistics order data after verifying the result data.

[0119] Fig. 8A is a diagram illustrating a concept of simulating a factory using a simulator according to an embodiment of the present disclosure.

[0120] refer to Fig. 8A , a simulator 810 may be used to simulate a factory. For example, the simulator 810 may include an interface for communicating with a simulator client, a configuration, and a data generator. The simulator 810 may include a data generation function and a response function of a data generator to act as a prototype during development. The simulator 810 may generate data suitable for a commonly available desired application. However, it may be difficult to apply the data to an actual system. Therefore, the data may be used before production, but may not be used during or after production.

[0121] Figure 8B is a diagram illustrating a concept of simulating a factory using a twin model according to an embodiment of the present disclosure.

[0122] refer to Figure 8B According to an embodiment, a factory simulation can be performed using the twin model 820 as described above. For example, the twin model 820 may include a virtualization model, a logical environment, and a data generator. The twin model 820 is a dedicated model for a specific system, and can replicate the control logic (e.g., business logic) and data of the system. The twin model 820 can be linked to the actual system. Therefore, the twin model 820 can virtualize the subject system according to the purpose of the simulation. It can be used to confirm the results of various scenarios of a specific system or verify data.

[0123] Fig. 9 is a diagram illustrating operations or steps of editing and managing the configuration of each model according to an embodiment of the present disclosure.

[0124] refer to Fig. 9According to the implementation, the digital twin system can store, edit and manage the settings of each simulation model. For example, the digital twin system can establish a simulation by managing various configurations. The properties of the simulation can be managed with settings to perform various simulations and can be changed.

[0125] In order to manage the properties of the simulation and change them in various ways, the architecture may be necessary. According to an embodiment, initial data or initial data master data can be established according to the version of the model. The initial data can include categories and attributes. The user can customize frequently used values ​​by modifying the initial data. The values ​​frequently used by the user can be referred to as a customized set (or custom set). However, the present disclosure is not limited to this term. Moreover, the user can set the initial data for each simulation. The data set by the user for each simulation can be referred to as user initial data, but the present disclosure is not limited to this term.

[0126] According to an embodiment, the above-mentioned initial data master data can be generated or set according to the version of the simulation model. The initial data master data can be set by model and / or version. For example, the initial data master data of the first twin model and the first digital factory can be set and registered as the first initial data master data. The twin model 112 and the digital factory 113 (or virtual factory) can generate data including categories and attributes as initial data and can use various set values ​​to set the data. The category can be segmented according to the characteristics of each simulation model. For example, when the category is buffer capacity, the attributes may include conveyors, workshops, warehouse buffers, etc. When the category is facility capacity, the attributes may include the size of the workshop, the size of the buffer room, and the number of racks / channels / floors / units of the warehouse. When the category is an operating rule, the attributes may include the number of pallet pushes, the maximum number of disposals, and the maximum number of releases.

[0127] According to an embodiment, the above-mentioned customized set can be obtained by modifying or changing only the frequently used values ​​in the initial data master data. When performing a simulation, the user can import and apply the corresponding customized set. For example, storing and managing customized sets enables the initial data for multiple simulations to be set to be the same. Custom sets can be used when the user wants to change the input files to manage them through the simulation unit. Custom sets can be used when the user wants to simulate in different nodes. In addition, customized sets can be used when there is common data in the data that is changed when performing a simulation. In such a case, the user can establish a customized set with frequently used conditions, and when performing a simulation, import the established customized set to apply it to the simulation.

[0128] According to an embodiment, user initial data can be newly set for each simulation. For example, the user can change the setting value in the initial data master data or the customized set and store it as the user initial data for the relevant simulation. The user initial data changed and stored in this way can be mapped to the simulation history (e.g., simulation time, simulation identification number). The user initial data (which is a condition that is only applied to the relevant simulation when it is performed) may not affect other simulations. Since the user initial data is linked to the simulation history to be stored, the simulation can be re-performed with the same data.

[0129] According to an embodiment, when simulating by a simulation model, the initial data as described above may be applied. As described above, the initial data may be managed by the simulator 111 in an integrated manner and stored in the database 313. For example, instead of storing the initial data by a model (e.g., a twin model 112 or a digital factory 113) installed in each node, the simulator 111 may centrally manage the initial data in an integrated manner so that multiple nodes may utilize it as the same common data. In addition, because the data utilized in each simulation model is centrally managed, the relevant model (e.g., a twin model 112 or a digital factory 113) may only participate in the conduct of the simulation and focus on it.

[0130] Fig.10 is a diagram illustrating setting values ​​for configuration of each model according to an embodiment of the present disclosure.

[0131] Reference Fig.10 , according to the implementation method, can be as referenced Fig. 9 The configuration is edited and managed for each simulation model as described. For example, node management (node_mgt) 1031 may include node ID (node_id), name (name), IP (ip), CPU name (cpu), GPU name (gpu), ram (ram), whether it is used (used), creation date (creation_date), update date (update_date), creation user (creation_user), update user (update_user) and whether it is deleted (deleted).

[0132] The user initial data 1013 may include a user initial data ID (user_initial_data_id), a simulation ID (sim_id), a history ID (history_id), an initial data ID (initial_data_id), a value (value), a creation date (creation_date), an update date (update_date), and a user (user).

[0133] The customized set 1011 may include a customized set ID (customized_set_id), a model version ID (model_version_id), a set name (set_name), a description (description), a creation date (creation_date), an update date (update_date), a creation user (creation_user), and an update user (update_user).

[0134] The customized setting data 1012 may include a customized setting data ID (cuntom_set_data_id), a customized setting ID (custom_set_id), an initial data ID (initial_data_id), a value (value), and a user (user).

[0135] The initial data (initial_data) 1021 may include an initial data ID (initial_data_id), a model version ID (model_version_id), a category ID (category_id), a property ID (property_id), a value (value), a description (description), whether it is used (used), whether it is changeable (changeable), a creation user (creation_user), an update user (update_user), a creation date (creation_date) and an update date (update_date).

[0136] The simulation manager (sim_mgt) 1041 may include a simulation ID (sim_id), a scene ID (scene_id), a name (name), a status (status), a creation date (creation_date), an update date (update_date), a creation user (creation_user), an update user (update_user), whether deleted (deleted), and a current history ID (current_history_id).

[0137] The history manager (history_mgt) 1042 may include a history ID (history_id), a simulation ID (sim_id), a result (result), a start date (start_date), an end date (end_date), a simulation user (sim_user), and whether deleted (deleted).

[0138] The history data set (history_data_set) 1014 may include a history data ID (history_data_id), a history ID (history_id), a model type (model_type), a key (key), and a value (value).

[0139] The category manager (category_mgt) 1023 may include a category ID (category_id), a model version ID (model_version_id), a code (code), a name (name), and a parent ID (parent_id). The favorite category (fav_category) 1022 may include a favorite category ID (fav_category_id), a category ID (category_id), and a user (user). The property manager (property_mgt) 1024 may include a property ID (property_id), a model version ID (model_version_id), a code (code), a name (name), a unit (unit), and a type (type).

[0140] Fig.11 is a flowchart illustrating operations or steps of editing and managing settings of each model according to an embodiment of the present disclosure.

[0141] Reference Fig.11 , according to an embodiment, the simulation may be initialized. In operation or step 1101, a user may request modification of parameters (e.g., configuration) of the simulator 111 (e.g., simulator server) through the user terminal 114. In operation or step 1103, the simulator 111 may store the parameters. In operation or step 1105, the simulator 111 may notify the user terminal 114 of the completion of the modification.

[0142] According to an embodiment, in operation or step 1107, the user may request the start of the simulation of the simulator 111 through the user terminal 114. In operation or step 1109, the simulator 111 may request the twin model 112 to initialize the simulation. In operation or step 1111, the twin model 112 may request parameters from the simulator 111 in response to the request of the simulator 111. In operation or step 1113, the simulator 111 may transmit the corresponding parameters to the twin model 112 in response to the request. Here, if the parameters are dynamic parameters, in operation or step 1115, the twin model 112 may update the transmitted parameters. In operation or step 1117, the twin model 112 may transmit the updated parameters to the simulator 111 and request the simulator 111 to store the updated parameters. The simulator 111 may store the updated parameters and send a message indicating that the modification is completed to the twin model 112 in operation or step 1119.

[0143] According to an embodiment, after the update of the parameters has been completed, in operation or step 1121, the twin model 112 may request the initialization of the simulation of the digital factory 113. In operation or step 1123, the digital factory 113 may request the parameters from the simulator 111 in response to the request for initialization. In operation or step 1125, the simulator 111 may transmit the corresponding parameters to the digital factory 113 in response to the request. Here, if the parameters are dynamic parameters, the digital factory 113 may update the transmitted parameters in operation or step 1127. In operation or step 1129, the digital factory 113 may transmit the updated parameters to the simulator 111 and request the simulator 111 to store the updated parameters. The simulator 111 may store the updated parameters and send a message indicating the completion of the modification to the digital factory in operation or step 1131. After the modification of the parameters has been completed, in operation or step 1133, the digital factory 113 may request the parameters from the simulator 111. In operation or step 1135, the simulator 111 may transmit the corresponding parameters to the digital factory 113 in response to the request. In operation or step 1137, the digital factory 113 having received the parameters may send a message to the twin model 112 indicating that the initialization is complete.

[0144] According to an embodiment, after receiving the message indicating that the initialization is complete, the twin model 112 may request parameters from the simulator 111 in operation or step 1139. In operation or step 1141, the simulator 111 may transmit the corresponding parameters to the twin model 112 in response to the request. In operation or step 1143, the twin model 112 that has received the parameters may send a message indicating that the initialization is complete to the simulator 111. In operation or step 1145, the simulator 111 that has received the message indicating that the initialization is complete may send a message indicating that a simulation is to be performed. The twin model 112 that has received the message indicating that a simulation is to be performed may perform a simulation in conjunction with the digital factory 113.

[0145] Fig.12 is a diagram illustrating a structure for generating a configuration set according to an embodiment of the present disclosure.

[0146] refer to Fig.12 According to an embodiment, a configuration set can be created by a combination of categories and attributes. For example, the categories may include conveyors, forklifts, and cranes. Attributes may include moving speed, number of loaded products, and loading time.

[0147] Depending on the implementation, the conveyor can be mapped to the movement speed or the loading time. A forklift or crane can be mapped to the movement speed, the number of loaded products or the loading time, respectively. Fig.12 As shown, a configuration set may be established, including a conveyor moving speed set to 5 m / s, a forklift moving speed set to 3 m / s, and a crane moving speed set to 2 m / s. The number of loaded products for the forklift may be set to 5, and the number of loaded products for the crane may be set to 2. The loading time of the forklift may be set to 15 seconds, and the loading time of the crane may be set to 10 seconds.

[0148] When the simulation is performed, as described above and Fig.12 The configuration set shown in can be stored as history. Here, by modifying a specific set, another customized set can be created using a branching structure. Fig.13 An example of creating a custom collection using a branching structure according to an embodiment is described in more detail.

[0149] Fig.13 is a diagram illustrating an edit configuration set according to an embodiment of the present disclosure.

[0150] Reference Fig.13 , according to the implementation mode, in Fig.12 In the configuration set of , you can create a new custom set by changing the moving speed of the conveyor from 5m / s to 10m / s.

[0151] Fig.14 is a diagram illustrating a flow of processing data according to an embodiment of the present disclosure.

[0152] Reference Fig.14 According to an implementation, the digital twin system 600 may include a simulator 111 , a twin model 112 , a digital factory 113 , and a data analysis module 620 .

[0153] According to an embodiment, in the data receiving operation or step 1410, the log data generated in real time in the simulator 111, the data receiving twin model 112, and the digital factory 113 can be used to create a log file 1411. In the data collection operation or step 1420, the data collection module 1421 can collect log data. For example, the data collection module 1421 can be implemented by an application such as "Filebeat", but the present disclosure is not limited to this. In the above-mentioned data collection operation or step 1420, the metric collection module 1422 can collect system metrics 1412. For example, the metric collection module 1422 can be implemented by an application such as "Metricbeat". However, the present disclosure is not limited to this.

[0154] According to an embodiment, in the data processing operation or step 1430, the link module 1431 may process the two pieces of data by linking the log data collected by the log collection module 1421 and the metric data collected by the metric collection module 1422 to each other. For example, the link module 1431 may be implemented by an application such as "Logstash". However, the present disclosure is not limited thereto.

[0155] According to an embodiment, in the data storage operation or step 1440, the database 1441 may store the simulation result data generated by the simulator 111 and the twin model 112. In the data storage operation or step 1440, the search engine 1442 may receive the log data and the metric data from the link module 1431 and perform a search based on the data. For example, the search engine 1442 may be implemented by an application such as "Elasticsearch". However, the present disclosure is not limited thereto.

[0156] According to an embodiment, in the visualization operation or step 1450, the first visualization module 1451 can visually display the analysis results based on the simulation result data stored in the database 1441 and the log data received by the search engine 1442. For example, the first visualization module 1451 can be implemented by an application such as "Grafana", but the present disclosure is not limited to this. In the visualization operation or step 1450, the second visualization module 1452 can receive the log data and the metric data from the search engine 1442 and visually display the analysis results. For example, the second visualization module 1452 can be implemented by an application such as "Kibana", but the present disclosure is not limited to this.

[0157] According to an embodiment, the log data collected in the data collection operation or step and Fig.14 The simulation results are shown in Table 1 below.

[0158] Table 1

[0159]

[0160] Fig.15 is a diagram illustrating a method of processing data according to an embodiment of the present disclosure.

[0161] Reference Fig.15 , in the above reference Fig.14 The data visualized in the described visualization operation or step 1450 may be divided into data of a domain dashboard 1510 and data of a system dashboard 1520. The domain dashboard 1510 as a user access area may be divided into a single simulation dashboard 1511 and a plurality of simulation dashboards 1512.

[0162] According to an embodiment, a single simulation dashboard 1511 may include simulation summary information, pallet manufacturing status, case picking status, operation rate of each logistics workshop, workload of each logistics workshop, cycle inefficiency count, delayed work pallet list, delayed work case list, operation rate of each crane, operation rate of each robot, etc. Multiple simulation dashboards 1512 may include comparison of operation rate averages of logistics workshops, comparison of pallet completion time averages, comparison of case release time averages, comparison of the number of completed pallets, comparison of the number of discarded cases, and comparison of the number of cases re-stocked during disposal.

[0163] According to an embodiment, the system dashboard 1520 as an administrator or developer access area may include a metrics dashboard 1521 and discovery 1522. The metrics dashboard 1521 may include information about the operating system (OS) and Docker containers as digital twin system support information. Information about the OS may include CPU usage, memory usage, disk usage, network traffic, etc. Information about discovery 1522 may include digital twin system log information.

[0164] Fig.16 is a diagram illustrating a method of generating an index of a simulation result according to an embodiment of the present disclosure.

[0165] Reference Fig.16 As described above, a simulation result index (e.g., a logistics simulation result index) can be created based on the log data collected when the simulation is performed. Here, in order to compare the simulation results with the actual operation results, the numerical values ​​obtained during the simulation and the result values ​​after the simulation is completed can also be the main index. According to an embodiment, for the storage and indexation of the values ​​obtained during the simulation, no matter when the communication between the twin model 112 and the digital factory 113 is performed during the simulation, the relevant values ​​can be recorded in a predetermined log data format and the method name, time, status, location, etc. can be verified from the log data to make them as an indication. According to an embodiment, when creating a simulation model, the data can be divided into data about the item 1610, data about the mover 1620, and data about the worker 1630, and these data can be combined. An index can be generated by utilizing the combined data when performing a simulation.

[0166] According to an embodiment, the log data format may be “node_name│node_id│sim_id│app_type│app_name│caller│call_type│call_name│call_time│call_parameter│call_return│info.” However, the present disclosure is not limited thereto.

[0167] Here, as a first example, an index may be created by searching for operations having a method name of "caller" or "call_name" and based on the time at which the operation is performed. As a second example, an index for each shop may be created by searching for operations having a method name of "caller" or "call_name" and a place at which the operation is performed in "call_parameter". As a third example, an index for each facility may be created by searching for operations of a facility having a method name of "caller" or "call_name" and "call_parameter".

[0168] According to an embodiment, Fig.16 The article 1610 may include a small pallet, a component box, a set box, a set box rack, a large pallet, a component, a body, a chassis, etc. The position change history or the state change history can be identified based on the article 1610. The mover 1620 may include an autonomous mobile robot, an unmanned transport vehicle, a conveyor belt, a diverter, a turntable, a sequence buffer, a sequence separator, an elevator, a stacking crane, a shuttle, a lifter, a trailer, and a component picking workshop. The target time for the start of the movement and the target time for the completion of the movement can be identified based on the mover 1620. The worker 1630 may include an assembly process, a disassembly robot, a cutting robot, a component picking robot, a single-arm discarding robot, a double-arm discarding robot, a cargo loading and unloading area, a compression area, a set box rack loading point, a set box rack retrieval point, a pallet stacker, a pallet depalletizer, a component picking operator, and a battery charging station. The target time for the start of the operation and the target time for the completion of the operation can be identified based on the worker 1630.

[0169] In the following, according to the embodiment, reference is made to FIG. 17A to FIG. 23 A system and method for controlling a conveyor in a virtual environment are described in detail, which can control a conveyor virtualized in a digital twin system.

[0170] Fig.17A and Fig. 17B A diagram illustrating a system for controlling a conveyor in a virtual environment according to an embodiment of the present disclosure.

[0171] refer to Fig.17A and Fig. 17B , a virtual factory in a virtual environment according to an embodiment may include a conveyor 10 (or a conveyor system). On the conveyor 10, a product 13 (e.g., a product box) may be conveyed from a starting position 40 to an arrival position 50. For example, the virtual factory in the virtual environment may use the virtualized conveyor 10 to simulate the movement or flow of products.

[0172] According to an embodiment, the conveyor 10 in the virtual environment as described above can be created by a digital factory 113 (e.g., a digital factory module). The conveyor 10 created by the digital factory module can be controlled by a twin model 112 (e.g., a twin model module), which is a virtual representation of a control system.

[0173] According to an embodiment, the virtualized conveyor 10 may include a plurality of paths 30 (or routes) obtained by segmenting the conveyor based on joints 41, 43, 45, 47. Products 13 (e.g., product boxes) placed at a starting position on the conveyor 10 may be delivered to a destination position by being transported on the plurality of paths 30. For example, a transport path from the starting position to the destination position may be formed by a plurality of paths 30 obtained by segmentation based on joints 41, 43, 45, 47.

[0174] According to an embodiment, when the product 13 is conveyed through the plurality of paths 30 included in the conveyor 10, the twin model module may verify in real time whether the distance between the product and the previous product is within a predetermined range. When the distance with the previous product is within the predetermined range, the twin model module may control the product being conveyed to stop through the control logic of the twin model module. Here, the predetermined range may correspond to a safety distance set to prevent collision with the previous product.

[0175] According to an embodiment, the plurality of paths 30 may include at least one straight path 31 (e.g., a straight conveying mechanism) and at least one turning path 32 (or curved path) (e.g., a turning conveyor belt). The twin model module may set at least one of the length, the slope angle, and the moving speed for each straight path 31 to simulate the product flow corresponding to those in the actual factory. In addition, the twin model module may set at least one of the turning segment, the turning angle, and the moving speed for each turning path 32 to simulate the product flow corresponding to those in the actual factory. For example, the twin model module may set a conveying path for the product 13 conveyed by the conveyor 10 based on a combination of a straight path 31 and a turning path 32.

[0176] According to an embodiment, a direction changing unit (e.g., a diverter or a converter) for changing the direction of the product may be provided in the joints 41, 43, 45, 47 provided between the paths 31, 32. The product 13 conveyed on the conveyor 10 may be controlled in its forward direction by controlling the twin model module so as to travel in a straight line or change its direction by the direction changing unit. According to an embodiment, the direction changing unit may include a barcode or a barcode reader. The barcode may include information about whether to change the direction. By means of the barcode or the barcode reader, it may be determined whether to change the moving direction of the product or whether to move the product in a straight line without changing the direction.

[0177] According to an embodiment, when it is verified as a result of a barcode scan that the product being conveyed is not an object of a direction change, the twin model module can control the product being conveyed to move in a straight line through control logic. In addition, when it is verified as a result of a barcode scan that the number of products on the entrance section of the conveyor is equal to or higher than a predetermined number, the twin model module can control the product being conveyed to move in a straight line through control logic. For example, the twin model module can control the product to enter the entrance section only when the number of products (e.g., product boxes) on the entrance section of the conveyor is less than the maximum allowable number. In this way, the buffer amount of the conveyor can be managed.

[0178] According to an embodiment, when it is verified as a result of barcode scanning that it is not the turn of the product to enter (i.e., when it is verified that the product being conveyed has not entered the conveyor), the twin model module can control the product being conveyed to go straight through the control logic. When it is verified as a result of barcode scanning that the product being conveyed is the object of direction switching, the twin model module can control the product being conveyed to change its direction through the control logic. For example, the product being conveyed on the conveyor can also be moved from the second floor to the third floor by the direction changing unit.

[0179] For example, refer to Fig. 17B , the products 13 stacked in the automatic storage 11 can be moved down 40 from the stacking position by the crane 12 and placed on the straight path 31. When the product 13 approaches the first joint 41, the destination (e.g., the arrival position) of the product 13 can be verified using the barcode arranged in the first joint 41. Through this verification, the product 13 can travel 42 in a straight line in the first joint 41. When the product 13 travels 42 in a straight line and approaches the second joint 43, it can be determined by the barcode arranged in the second joint 43 whether to change the direction. Through such verification, the product 13 can turn 44 in the second joint 43. When the product 13 approaches the third joint 45 by turning 44, it can be determined by the barcode arranged in the third joint 45 whether to change the direction. Through such verification, the product 13 can travel 46 in a straight line in the third joint 45. When the product 13 approaches the fourth joint 47 by traveling 46 in a straight line, it can be determined by the barcode arranged in the fourth joint 47 whether to change the direction. Through such verification, the product 13 can turn 50 in the fourth joint 47. Through the turn 50 , the product 13 can reach the destination.

[0180] Fig.18 is a flowchart illustrating a control process of a conveyor according to an embodiment of the present disclosure.

[0181] Reference Fig.18 According to an embodiment, in operation or step S1810 , the twin model module may convey the product through conveying paths 31 , 32 .

[0182] According to an embodiment, in operation or step S1820, the twin model module may control scanning of a barcode in a direction changing unit (eg, a diverter or a converter) disposed between a plurality of paths 31, 32 obtained by segmentation based on joints.

[0183] According to an embodiment, in operation or step S1830, the twin model module may determine whether to change the direction based on the result of the barcode scanning. Figure 20 to Figure 23 Describe in more detail.

[0184] Fig.19 is a diagram illustrating program logic for controlling a transporter in a virtual environment according to an embodiment of the present disclosure.

[0185] Reference Fig.19 According to an embodiment, the logic for determining the transmission of an item in the twin model module can be determined based on at least one of the texture, shape, and slope of the conveyor 10. For example, the texture may include the texture of a roller or rubber. However, the present disclosure is not limited thereto. The shape may include a straight line or a curve. However, the present disclosure is not limited thereto. The slope may include no slope (none), an upward slope (up), and a downward slope (down). However, the present disclosure is not limited thereto.

[0186] According to an embodiment, the moving speed of the item may be updated by the algorithm described in Table 2.

[0187] Table 2

[0188]

[0189] For example, referring to Table 2 above, the moving speed of the object can be processed by “CalculateSpeed(Texture texture, Shape shape, Slope slope)”.

[0190] In the following, reference Figure 20 to Figure 23 , describes a process of determining whether to change direction based on a scanning result of a barcode included in a direction change unit in a twin model module according to an implementation.

[0191] Fig. 20 is a flowchart illustrating a control process of a conveyor according to an embodiment of the present disclosure.

[0192] Reference Fig. 20 According to an embodiment, in operation or step S2010, the twin model module can convey the product (or product box) through the path of the virtualized conveyor.

[0193] According to an embodiment, in operation or step S2020, the twin model module may verify the distance between the product and the previous product. When, as a result of the verification, the distance from the previous product is equal to or greater than a predetermined distance, it may be determined in operation or step S2030 to ensure a safe distance. When it is determined that the safe distance is ensured, the product may keep moving. When the product in transit arrives at the destination, in operation or step S2050, 2060, the twin model module may control the product to stop moving.

[0194] According to an embodiment, when the distance to the previous product is less than a predetermined distance as a result of verifying the distance to the previous product, the twin model module may determine that the safety distance is not ensured and may temporarily stop the delivery of the product in operation or step S2040. The twin model module may verify the distance to the previous product in real time, and when it is verified that the distance to the previous product is equal to or greater than the predetermined distance, the stopped product may be re-delivered.

[0195] Fig.21 is a flowchart illustrating a control process of a conveyor according to an embodiment of the present disclosure.

[0196] Reference Fig.21 , according to an embodiment, in operation or step S2110, the twin model module may convey the product (or product box) through a virtualized conveyor path.

[0197] According to an embodiment, in operation or step S2120, the twin model module may control scanning of a barcode in the direction change unit. When it is verified as a result of the barcode scanning that the product is an object of direction change, in operations or steps S2130 and S2140, the twin model module may change the direction of the product. On the contrary, when it is verified as a result of the barcode scanning that the product is not an object of direction change, in operations or steps S2130 and S2150, the twin model module may control the product to go straight without changing direction.

[0198] Fig. 22 is a flowchart illustrating a control process of a conveyor according to an embodiment of the present disclosure.

[0199] Reference Fig. 22 According to an embodiment, in operation or step S2210, the twin model module can convey the product (or product box) through the path of the virtualized conveyor.

[0200] According to an embodiment, in operation or step S2220, the twin model module may control scanning of a barcode in the direction change unit. When, as a result of the barcode scanning, the number of products on the entrance section of the conveyor meets the maximum buffer amount (e.g., the number is less than the maximum buffer amount), in operations or steps S2230, S2240, the control logic of the twin model module may change the forward direction of the product to the entrance section. On the contrary, when the number of products on the entrance section of the conveyor does not meet the maximum buffer amount (e.g., the number is equal to or greater than the maximum buffer amount), in operations or steps S2230, S2250, the control logic of the twin model module may control the conveyed product not to enter the entrance section, but to go straight.

[0201] Fig.23 is a flowchart illustrating a control process of a conveyor according to an embodiment of the present disclosure.

[0202] Reference Fig.23 , according to an embodiment, in operation or step S2310, the twin model module can convey the product (or product box) through the path of the virtualized conveyor.

[0203] According to an embodiment, in operation or step S2320, the twin model module may control the barcode to be scanned in the direction change unit. When it is the product's turn to enter the relevant entrance section as a result of the barcode scanning, in operations or steps S2330 and S2340, the control logic of the twin model module may change the product's forward direction to the entrance section. On the contrary, when it is not the product's turn to enter the relevant entrance section as a result of the barcode scanning, in operations or steps S2330 and S2350, the control logic of the twin model module may control the conveying product not to enter the entrance section but to go straight.

[0204] According to various embodiments, when the Fig.21 , Fig. 22 and Fig.23 When all the conditions described are met, the control logic of the twin model module can control the product to change its advancing direction. For example, as a result of barcode scanning, when it is verified that the product is the object of direction change, the number of products on the entrance section of the conveyor is less than the maximum buffer amount, and it is the turn of the product to enter the relevant entrance section, the control logic of the twin model module can change the advancing direction of the product to convey the product to the entrance section.

[0205] Fig.24 is a configuration diagram of hardware of a computing device according to some embodiments of the present disclosure.

[0206] Reference Fig.24, each device or module (e.g., a twin model module, a digital factory module, or a simulator module) forming the digital twin system may be composed of a computing device 2400. For example, the computing device 2400 may include at least one processor 2410, a system bus 2460, a communication interface 2420, a memory 2440 for loading a computer program 2441 to be executed by the processor 2410, and a storage device 2430 for storing a computer program 2431.

[0207] The processor 2410 generally controls the operation of the various components of the computing device 2400. The processor 2410 may perform calculations on at least one application or program to perform methods / operations according to various embodiments of the present disclosure. The memory 2440 stores various data, commands and / or information. The memory 2440 may load at least one computer program 2441 from the storage device 2430 to perform methods / operations according to different embodiments of the present disclosure. The bus 2460 provides communication between components of the computing device 2400. The communication interface 2420 supports Internet communication of the computing device 2400. The storage device 2430 may store at least one computer program 2431 non-temporarily. The computer program 2431 may include one or more instructions for implementing the methods / operations according to various embodiments of the present disclosure. When the computer program 2431 is loaded into the memory 2440, the processor 2410 may execute one or more instructions to perform methods / operations according to various embodiments of the present disclosure.

[0208] The computer program 2431 may include instructions for executing methods / operations according to various embodiments of the present disclosure.

[0209] For example, computer program 2431 may include: instructions for registering and initializing models of multiple digital factories by a simulator module, where the multiple digital factories are virtual representations of the multiple factories; instructions for requesting a simulation start from a first twin model among multiple twin models, where the twin model is a virtual representation of the control systems of the corresponding multiple factories; instructions for generating control logic for a first digital factory among the multiple digital factories by the first twin model; and instructions for transmitting commands generated based on the control logic to the first digital factory module through the first twin model.

[0210] In addition, the computer program 2431 may include instructions for receiving a request to start simulation from a simulator module by a first twin model, wherein the first twin model is one of multiple twin models, and the multiple twin models are virtual representations of control systems for each of the multiple factories; instructions for generating control logic for a first digital factory among multiple digital factories by the first twin model, and the control logic is a virtual representation of the multiple factories; instructions for transmitting commands generated based on the control logic to the first digital factory module through the first twin model; and instructions for processing operations corresponding to the commands received from the first twin model through the first digital factory module for simulation.

[0211] In the above, reference has been made to Figure 1-Figure 24 Various embodiments of the present disclosure and their benefits are described. The benefits according to the technical spirit of the present disclosure are not limited to those mentioned above. Other benefits not mentioned above should be more clearly understood by those of ordinary skill in the art from the above description.

[0212] The technical spirit of the present disclosure described above can be implemented as a computer-readable code on a computer-readable medium. The computer program recorded on the computer-readable recording medium can be transmitted to another computing device via a network such as the Internet and installed in another computing device, so that the computer program can be used in another computing device.

[0213] Although operations are shown in a particular order in the drawings, it should not be understood that only when the operations are performed in that particular order or sequence or when all operations are performed, the desired results can be obtained. In some cases, multitasking and / or parallel processing can be advantageous.

[0214] Although the embodiments of the present disclosure have been described with reference to the accompanying drawings, it should be understood by those skilled in the art that the present disclosure may be modified or changed in other specific forms without changing the technical spirit or basic features. Therefore, the above embodiments should be understood as illustrative rather than restrictive in all aspects. The scope of protection of the present disclosure should be interpreted according to the following claims, and all technical concepts within the equivalent scope should be interpreted as included within the scope of rights of the technical concepts defined in the present disclosure.

Claims

1. A system for controlling a conveyor in a virtual environment, the system comprising: a twin model module including control logic and configured to virtualize a control system of a conveyor installed in a factory; as well as a digital factory module configured to virtualize the conveyor installed in the factory and create a virtual factory model controlled by the twin model module; wherein the virtualized conveyor includes a plurality of paths formed by segmenting the conveyor based on joints, and wherein the twin model module is configured to control a conveying path of the product based on the joints.

2. The system according to claim 1, wherein: The twin model module is configured as follows: When a product is conveyed through the plurality of paths included in the conveyor, verifying whether the distance between the product and the previous product is within a predetermined range, and When the distance is within the predetermined range, the control logic controls the product being transported to stop.

3. The system according to claim 1, wherein: The plurality of paths include at least one straight path and at least one turning path, and The twin model module is configured to set at least one of a length, a slope angle, and a moving speed for each straight path.

4. The system according to claim 1, wherein: The plurality of paths include at least one straight path and at least one turning path, and The twin model module is configured to set at least one of a turning segment, a turning angle, and a moving speed for each turning path.

5. The system according to claim 1, wherein: The twin model module is configured to set a conveying path for conveying the product through the conveyor based on a combination of the plurality of paths.

6. The system according to claim 1, wherein: A direction changing unit for changing the direction is arranged in each joint, and wherein the direction changing unit comprises a barcode or a barcode reader.

7. The system according to claim 6, wherein: The twin model module is configured to control the product being conveyed to go straight through the control logic when it is verified as a result of barcode scanning that the product being conveyed is not an object of direction change.

8. The system according to claim 6, wherein: The twin model module is configured to control the straight movement of the products in the conveyor through the control logic when it is verified as a result of barcode scanning that the number of products on the entrance section of the conveyor is equal to or greater than a predetermined number.

9. The system according to claim 6, wherein: The twin model module is configured to control the product being conveyed to move straight through the control logic when it is verified as a result of barcode scanning that the product being conveyed does not enter the conveyor.

10. The system according to claim 6, wherein: The twin model module is configured to control the product being conveyed to change the direction of the product through the control logic when it is verified as a result of barcode scanning that the product being conveyed is a subject of direction change.

11. The system according to claim 1, wherein: The twin model module is one of a plurality of twin model modules included in the system, and The system further includes a simulator module, which is used to control the multiple twin model modules.

12. The system according to claim 11, wherein: The multiple twin model modules are executed on at least one graphics processing unit (GPU) server, and The simulator module is configured to allocate resources for executing a first twin model module in the at least one GPU server when the first twin model module among the multiple twin model modules is executed.

13. The system according to claim 11, wherein: The simulator module is configured to set a condition of the control logic for each of the plurality of twin model modules to control a virtual factory.

14. The system according to claim 13, wherein: The simulator module is configured to create a web page to set the condition of the control logic, and to set the condition of the control logic using a setting value input through the web page.

15. A method for controlling a conveyor in a virtual environment, the method comprising: registering and initializing, by the simulator module, a model for a digital factory, the digital factory including a virtualized conveyor, the virtualized conveyor being a virtual representation of a conveyor installed in an actual factory; Requesting, by the simulator module, the start of a simulation from a twin model module, the twin model module being a virtual representation of a control system of the actual plant; Generating control logic for the digital factory by the twin model module; The twin model module transmits the command generated based on the control logic to the digital factory module; as well as processing, by the digital factory module, operations corresponding to the commands received from the twin model module for simulation, Wherein, the virtualized conveyor is divided into a plurality of paths based on joints, and wherein the twin model module is configured to control a conveying path of the product based on the joints.

16. The method according to claim 15, further comprising: When a product is conveyed through the plurality of paths included in the conveyor, the twin model module verifies whether the distance between the product and the previous product is within a predetermined range, and When the distance is within the predetermined range, the twin model module controls the product being transported to stop through the control logic.

17. The method according to claim 15, wherein: A barcode or barcode reader for changing direction is provided in each joint, and, The method includes controlling the product being conveyed to move straight through the control logic by the twin model module when it is verified as a result of barcode scanning that the product being conveyed is not an object of direction change.

18. The method according to claim 15, wherein: A barcode or barcode reader for changing direction is provided in each joint, and, The method includes controlling the straight movement of products in the conveyor by the twin model module through the control logic when it is verified as a result of barcode scanning that the number of products on the entrance section of the conveyor is equal to or greater than a predetermined number.

19. The method according to claim 15, wherein: A barcode or barcode reader for changing direction is provided in each joint, and, The method includes controlling the product being conveyed to move straight through the control logic by the twin model module when it is verified as a result of barcode scanning that the product being conveyed does not enter the conveyor.

20. A non-transitory computer-readable recording medium storing instructions that, when executed by at least one processor, cause the at least one processor to: registering and initializing a model for a digital factory using a simulator module, the digital factory including a virtualized conveyor, the virtualized conveyor being a virtual representation of a conveyor installed in an actual factory; requesting, using the simulator module, a start of a simulation from a twin module, the twin module being a virtual representation of a control system for the actual plant; generating control logic for the digital factory using the twin model module; using the twin model module to transmit commands generated based on the control logic to a digital factory module; as well as processing, using the digital factory module, operations corresponding to the commands received from the twin model module for simulation, Wherein, the virtualized conveyor is divided into a plurality of paths based on joints, and wherein the twin model module is configured to control a conveying path of the product based on the joints.

Images