An apparatus, a method for providing digital production planning information, and a storage medium storing software executable by a computer

Abstract

An embodiment of the present disclosure provides a method for providing digital production planning information, comprising: providing an extensible software model and a logic set for generating production planning data to a client; receiving first input data comprising benchmark information of a manufacturing production system and second input data for parameter setting; and based on the first input data and the second input data, performing at least one of learning, evaluation, operation, deployment and management on at least one strategy to provide production planning data to the client.

Description

Technical Field

[0001] This disclosure relates to an apparatus, method, and storage medium for providing digital production planning information and storing computer-executable software. Background Technology

[0002] Manufacturing systems for producing products involve multiple operational steps and various resources. Depending on the product, these steps may be complex and may require expensive resources, necessitating optimized operations at each stage.

[0003] For example, in high-tech fields such as semiconductors, displays, secondary batteries, automobiles, steel, home appliances, and biotechnology, the resources invested are extremely expensive. Therefore, reducing process failures and improving efficiency are key factors for product competitiveness. There are many situations where the equipment responsible for the process is very expensive, or where further investment in equipment is impossible due to physical space constraints within the manufacturing system. Making good decisions in complex manufacturing processes without adding new equipment can improve production efficiency.

[0004] To optimize these operational steps, improve resource utilization efficiency, and increase productivity, various solutions are being developed.

[0005] Among these approaches, the use of digital modeling to realize manufacturing systems and solve related problems is increasing. Since real-world decisions are irreversible, this digital modeling approach has been proposed as a solution to improve decision-making and production efficiency.

[0006] Recently, with the development of artificial intelligence technology, methodologies for learning to make better decisions in various decision-making problems are being developed. Summary of the Invention

[0007] Technical issues The purpose of this disclosure is to provide an apparatus, method, and storage medium for providing digital production planning information and storing computer-executable software, which can provide reusability and scalability for manufacturing or production systems.

[0008] Another object of this disclosure is to provide an apparatus for providing digital production planning information, a method for providing digital production planning information, and a storage medium for storing computer-executable software for providing digital production planning information, which can predict real-time changes in a manufacturing or production system or efficiently provide production plans.

[0009] Another object of this disclosure is to provide an apparatus for providing digital production planning information, a method for providing digital production planning information, and a storage medium for storing computer-executable software for providing digital production planning information, which reproduces decisions in a virtual environment through digital modeling, thereby significantly saving time and reducing costs.

[0010] Another object of this disclosure is to provide an apparatus for providing digital production planning information, a method for providing digital production planning information, and a storage medium for storing computer-executable software for providing digital production planning information, which can solve a variety of decision-making problems through artificial intelligence learning.

[0011] Technical solutions One embodiment of this disclosure provides a method for providing digital production planning information, comprising: providing a client with an extensible software model and logic set for generating production planning data; receiving first input data including baseline information of a manufacturing production system and second input data for parameter settings; and performing at least one of learning, evaluation, operation, deployment, and management on at least one strategy based on the first input data and the second input data to provide production planning data to the client.

[0012] The step of providing production planning data is characterized by including: applying a list of decision elements and actions to at least one of a strategy function and a value function for strategic operation, in order to make a final decision.

[0013] The step of providing production planning data is characterized by including: preprocessing and learning the learning data for strategy learning, so as to generate at least one of a learned policy function and a learned value function.

[0014] The learning data is characterized by including at least one of the following: decision elements, action list, performance index information, reward information, decision time point, and final decision.

[0015] The step of providing production planning data is characterized by including: in order to utilize the dynamic operation of reinforcement learning, performing policy evaluation on at least one of the policy function and value function, and generating an optimal policy scenario.

[0016] The method is characterized by further comprising: performing a policy evaluation on at least one of the policy function and the value function, and passing a relearning command.

[0017] The step of providing production planning data is characterized by including: receiving the second input data to set decision-related parameters and initialize the system; at the decision time point, extracting decision elements and an action list based on the system's state characteristic values ​​and action characteristic values; and calculating at least one of the action probability and state value based on the extracted decision elements and the action list.

[0018] The step of providing production planning data is characterized by including: generating learning data; and performing policy learning on the generated learning data to provide at least one of a learned policy function and a learned value function.

[0019] The step of generating learning data is characterized by including: performing at least one simulation to obtain at least one of decision element values, action list, reward value and performance index value, thereby accumulating learning data.

[0020] The method is characterized by further comprising: determining whether a first user-specified condition is met; and, if the first user-specified condition is not met, performing the at least one simulation to obtain at least one of decision element values, action list, reward value, and performance index value, thereby accumulating learning data.

[0021] The step of providing at least one of the learned policy function and the learned value function is characterized by including: learning and storing the policy function using the generated learning data when the first user-specified condition is met; determining whether the second user-specified condition is met; and storing the policy after learning is terminated when the second user-specified condition is met.

[0022] The step of providing production planning data is characterized by including: acquiring at least one model for evaluating the at least one strategy; evaluating the acquired at least one strategy and the at least one model; and deploying the evaluated strategy and the evaluated model into operational scenarios and strategies.

[0023] The method is characterized by further comprising: determining whether the evaluated strategy and the evaluated model need to be relearned; and, based on the determination result, relearning at least one strategy if conditions specified by a third user are met.

[0024] One embodiment of this disclosure provides an apparatus for providing digital production planning information, comprising: a storage device for storing data; memory for storing a set of software-related library engines; and a processor for executing the software; wherein the processor: provides a client with a scalable software model and logic set for generating production planning data; receives first input data including baseline information of a manufacturing production system and second input data for parameter settings; and performs at least one of learning, evaluation, operation, deployment, and management on at least one strategy based on the first input data and the second input data to provide production planning data to the client.

[0025] One embodiment of this disclosure provides a storage medium having stored computer-executable software configured to: provide a client with an extensible software model and logic set for generating production planning data; receive first input data including baseline information about a manufacturing production system and second input data for parameter settings; and, based on the first input data and the second input data, perform at least one of learning, evaluation, operation, deployment, and management on at least one strategy to provide production planning data to the client.

[0026] Beneficial effects According to this disclosure, reusability and scalability of digital models for manufacturing or production systems can be provided.

[0027] According to this disclosure, real-time changes in manufacturing or production systems can be predicted, or production plans can be provided efficiently.

[0028] According to this disclosure, decision-making processes can be reproduced in a virtual environment by digitally modeling manufacturing or production systems, thereby significantly saving time and reducing costs; and various decision-making problems in manufacturing or production systems can be solved through artificial intelligence learning.

[0029] According to this disclosure, a series of processes can be automatically executed in manufacturing systems that require production plans of varying fineness. Attached Figure Description

[0030] Figure 1 This is a schematic diagram illustrating one embodiment of a method for providing digital production planning information.

[0031] Figure 2 This is a schematic diagram illustrating one embodiment of a computing system that provides digital production planning data.

[0032] Figure 3 This is a schematic diagram illustrating another embodiment of a computing system that provides digital production planning data.

[0033] Figure 4 This is a schematic diagram illustrating the steps of performing reverse planning logic according to one embodiment.

[0034] Figure 5 This is a schematic diagram illustrating the steps of reverse planning logic within an execution library engine set according to an embodiment.

[0035] Figure 6 This is a schematic diagram illustrating the execution of reverse programming according to one embodiment.

[0036] Figure 7 This is a flowchart illustrating how a production plan is generated using a software model and logic set including reverse planning logic, according to one embodiment.

[0037] Figure 8 This is a schematic diagram illustrating one embodiment of a device for providing digital production planning information.

[0038] Figure 9 This is a schematic diagram illustrating the steps of performing forward programming logic according to one embodiment.

[0039] Figure 10 This is a schematic diagram illustrating the steps of forward planning logic within an execution library engine set according to one embodiment.

[0040] Figure 11 This is a schematic diagram illustrating the state variables of a forward programming method according to one embodiment.

[0041] Figure 12 This is a schematic diagram illustrating an event queue performing forward planning according to one embodiment.

[0042] Figure 13 This is a flowchart illustrating how to generate a production plan using forward programming logic according to one embodiment.

[0043] Figure 14 This is a schematic diagram illustrating an event queue performing forward planning according to another embodiment.

[0044] Figure 15 This is a schematic diagram illustrating the steps of making input decisions in forward programming logic according to one embodiment.

[0045] Figure 16 This is a schematic diagram illustrating a forward planning dispatching process according to one embodiment.

[0046] Figure 17 This is a schematic diagram illustrating a forward planning dispatching process according to another embodiment.

[0047] Figure 18 This is a flowchart illustrating how to generate a production plan using forward programming logic according to one embodiment.

[0048] Figure 19 This is a schematic diagram illustrating the generation of a software model and logic set based on a data schema and library engine set, according to one embodiment.

[0049] Figure 20 This is a schematic diagram illustrating the generation of a logic set including hooking logic and simulation logic according to one embodiment.

[0050] Figure 21 This is a schematic diagram illustrating the generation of a software model and logic set in a method for providing digital production planning information according to one embodiment.

[0051] Figure 22This is a flowchart illustrating a method for generating a production plan by providing digital production planning information according to one embodiment.

[0052] Figure 23 This is a schematic diagram illustrating the generation of operational tasks based on a software model and a set of logic, according to one embodiment.

[0053] Figure 24 This is a schematic diagram illustrating the execution of operational tasks based on a software model and a set of logic, according to one embodiment.

[0054] Figure 25 This is a schematic diagram illustrating the setting of operational tasks in a system operation unit according to one embodiment.

[0055] Figure 26 This is a flowchart illustrating the generation and execution of operational jobs in a local computing system according to one embodiment.

[0056] Figure 27 This is a flowchart illustrating the generation and execution of operational jobs in a cloud computing system according to one embodiment.

[0057] Figure 28 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0058] Figure 29 This is a schematic diagram illustrating one embodiment of a device for providing digital production planning information.

[0059] Figure 30 This is a schematic diagram illustrating the analysis of production plans based on a software model and logic set according to one embodiment.

[0060] Figure 31 This is a schematic diagram illustrating a data query interface according to one embodiment.

[0061] Figure 32 This is a schematic diagram illustrating a pivot table query interface according to one embodiment.

[0062] Figure 33 This is a schematic diagram illustrating a data editing interface according to one embodiment.

[0063] Figure 34 This is a schematic diagram illustrating the experimental setup and execution interface according to one embodiment.

[0064] Figure 35 This is a flowchart illustrating the analysis of production plans based on a software model and logic set according to one embodiment.

[0065] Figure 36 This is a schematic diagram illustrating a computing system that provides digital production planning data according to one embodiment.

[0066] Figure 37 This is a schematic diagram illustrating the basic structure of an experimental platform based on a software model and logic set according to one embodiment.

[0067] Figure 38 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0068] Figure 39 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0069] Figure 40 This is a schematic diagram illustrating the generation of refined logic in an experimental platform file based on a software model and logic set, according to one embodiment.

[0070] Figure 41 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0071] Figure 42 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0072] Figure 43 This is a schematic diagram illustrating an experiment performed based on a software model and a set of logic, according to one embodiment.

[0073] Figure 44 This is a schematic diagram illustrating, according to one embodiment, the output of information about an experimental platform file based on a software model and a set of logic.

[0074] Figure 45 This is a schematic diagram illustrating the execution of an experiment in an experimental platform unit based on a software model and logic set, according to one embodiment.

[0075] Figure 46 This is a flowchart illustrating the generation and execution of an experimental platform according to one embodiment.

[0076] Figure 47 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0077] Figure 48 This is a schematic diagram illustrating the configuration of an iterative experimental design based on a software model and a logic set, according to one embodiment.

[0078] Figure 49 This is a schematic diagram illustrating an iterative experimental design based on a software model and a set of logic, according to one embodiment.

[0079] Figure 50This is a schematic diagram illustrating an iterative experimental design based on a software model and a set of logic, according to one embodiment.

[0080] Figure 51 This is a schematic diagram illustrating the setting of operational tasks in a system operation unit according to one embodiment.

[0081] Figure 52 This is a schematic diagram illustrating, according to one embodiment, the execution of an operational operation in an operational environment utilizing a fixed-scale experimental design.

[0082] Figure 53 This is a flowchart illustrating the setup and execution of an experimental platform operation according to one embodiment.

[0083] Figure 54 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0084] Figure 55 This is a schematic diagram illustrating the interface of an experimental platform according to one embodiment.

[0085] Figure 56 This is a schematic diagram illustrating the generation of files and registration of variables in an experimental platform interface according to one embodiment.

[0086] Figure 57 This is a schematic diagram illustrating the generation of data type variables and key performance indicators on a data table in an experimental platform file according to one embodiment.

[0087] Figure 58 This is a schematic diagram illustrating the model data variables used to generate an experimental platform file according to one embodiment.

[0088] Figure 59 This is a schematic diagram illustrating the data type variables used to generate an experimental platform file according to one embodiment.

[0089] Figure 60 This is a schematic diagram illustrating the data type variables used to generate an experimental platform file according to one embodiment.

[0090] Figure 61 This is a schematic diagram illustrating the data type variables used to generate an experimental platform file according to one embodiment.

[0091] Figure 62 This is a schematic diagram illustrating a model type variable for registering an experimental platform file according to one embodiment.

[0092] Figure 63 This is a schematic diagram illustrating a logical type variable for registering an experimental platform file according to one embodiment.

[0093] Figure 64This is a schematic diagram illustrating the key performance indicators (KPIs) for registering experimental platform files according to one embodiment.

[0094] Figure 65 This is a schematic diagram illustrating a method for editing an experimental platform according to another embodiment.

[0095] Figure 66 This is a flowchart illustrating the provision of digital production planning information according to one embodiment.

[0096] Figure 67 This is a schematic diagram illustrating a scenario refinement included in an experimental platform according to one embodiment.

[0097] Figure 68 This is a schematic diagram illustrating a scenario refinement included in an experimental platform according to one embodiment.

[0098] Figure 69 This is a schematic diagram illustrating experimental refining in an experimental platform according to one embodiment.

[0099] Figure 70 This is a schematic diagram illustrating experimental refining in an experimental platform according to one embodiment.

[0100] Figure 71 This is a schematic diagram illustrating the editing of an experimental design in an experimental platform file according to one embodiment.

[0101] Figure 72 This is a schematic diagram illustrating the editing of an experimental design in an experimental platform file according to one embodiment.

[0102] Figure 73 This is a schematic diagram illustrating the editing of an experimental design in an experimental platform file according to one embodiment.

[0103] Figure 74 This is a schematic diagram illustrating the execution of an experimental design according to an embodiment of an experimental platform file.

[0104] Figure 75 This is a schematic diagram illustrating the execution of an experimental design according to an embodiment of an experimental platform file.

[0105] Figure 76 This is a schematic diagram illustrating the execution of an experimental design according to an embodiment of an experimental platform file.

[0106] Figure 77 This is a schematic diagram illustrating the execution of an experimental design according to an embodiment of an experimental platform file.

[0107] Figure 78 This is a schematic diagram illustrating the confirmation of experimental execution results according to an experimental platform file of one embodiment.

[0108] Figure 79 This is a flowchart illustrating the provision of digital production planning information according to one embodiment.

[0109] Figure 80 This is a schematic diagram illustrating how, according to one embodiment, digital production planning information is provided based on a mathematical optimization model.

[0110] Figure 81 This is a schematic diagram illustrating the use of a variable time bucket according to one embodiment.

[0111] Figure 82 This is a flowchart illustrating the execution of a mathematical optimization model according to one embodiment.

[0112] Figure 83 This is a schematic diagram illustrating the execution of a mathematical optimization model according to one embodiment.

[0113] Figure 84 This is a flowchart illustrating the provision of digital production planning information according to one embodiment.

[0114] Figure 85 This is a schematic diagram illustrating the setting of operational tasks for dynamic strategy operations in a system operations unit according to one embodiment.

[0115] Figure 86 This is a schematic diagram illustrating the execution of operational tasks for dynamic policy operations in an operational environment according to one embodiment.

[0116] Figure 87 This is a schematic diagram illustrating the setting of operational tasks for dynamic strategy operations in a system operations unit according to one embodiment.

[0117] Figure 88 This is a schematic diagram illustrating the execution of operational tasks for dynamic policy operations in an operational environment according to one embodiment.

[0118] Figure 89 This is a flowchart illustrating, according to one embodiment, setting up and executing operational tasks for dynamic policy operations in an operational environment.

[0119] Figure 90 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0120] Figure 91 This is a schematic diagram illustrating, according to one embodiment, the use of a domain-specific engine to provide digital production planning information.

[0121] Figure 92 This is a schematic diagram illustrating the balanced production logic according to one embodiment.

[0122] Figure 93This is a schematic diagram illustrating the process of balancing production logic according to one embodiment.

[0123] Figure 94 This is a flowchart illustrating the balanced production logic according to one embodiment.

[0124] Figure 95 This is a schematic diagram illustrating the waiting time control logic according to one embodiment.

[0125] Figure 96 This is a schematic diagram illustrating the process of queue waiting time control logic according to one embodiment.

[0126] Figure 97 This is a flowchart illustrating queue waiting time control logic according to one embodiment.

[0127] Figure 98 This is a schematic diagram illustrating batch control logic according to one embodiment.

[0128] Figure 99 This is a schematic diagram illustrating a batch control logic process according to one embodiment.

[0129] Figure 100 This is a flowchart illustrating batch control logic according to one embodiment.

[0130] Figure 101 This is a flowchart illustrating the provision of digital production planning information according to one embodiment.

[0131] Figure 102 This is a schematic diagram illustrating one embodiment of a method for providing digital production planning information.

[0132] Figure 103 This is a schematic diagram illustrating one embodiment of a computing system that provides digital production planning data.

[0133] Figure 104 This is a schematic diagram illustrating a device that provides digital production planning data.

[0134] Figure 105 This is a schematic diagram illustrating one embodiment of a computing system that provides digital production planning data.

[0135] Figure 106 This is a schematic diagram illustrating a cloud system that provides digital production planning data.

[0136] Figure 107 This is a schematic diagram illustrating a site that provides digital production planning data for a cloud system.

[0137] Figure 108 This is a schematic diagram illustrating the buffer of a cloud system that provides digital production planning data.

[0138] Figure 109 This is a schematic diagram illustrating the BOM information of a cloud system that provides digital production planning data.

[0139] Figure 110 This is a schematic diagram illustrating alternative BOM information for a cloud system that provides digital production planning data.

[0140] Figure 111 This is a schematic diagram illustrating the process route of a cloud system that provides digital production planning data.

[0141] Figure 112 This is a schematic diagram illustrating the process of a cloud system that provides digital production planning data.

[0142] Figure 113 This is a schematic diagram illustrating the resources of a cloud system that provides digital production planning data.

[0143] Figure 114 This is a schematic diagram illustrating the work-in-process inventory of a cloud system that provides digital production planning data.

[0144] Figure 115 This is a schematic diagram illustrating the components of a cloud system that provides digital production planning data.

[0145] Figure 116 This is a flowchart illustrating the provision of digital production planning information in a standard model of a cloud system that provides digital production planning data.

[0146] Figure 117 This is a schematic diagram illustrating how, according to one embodiment, digital production planning information is provided based on reverse planning logic.

[0147] Figure 118 This is a schematic diagram illustrating an alignment process based on reverse planning logic according to one embodiment.

[0148] Figure 119 This is a schematic diagram illustrating an ISB attach process based on reverse planning logic according to one embodiment.

[0149] Figure 120 This is a schematic diagram illustrating an ISB process route based on reverse planning logic according to one embodiment.

[0150] Figure 121 This is a schematic diagram illustrating the process of process connection and process route based on reverse planning logic according to one embodiment.

[0151] Figure 122 This is a flowchart illustrating, according to one embodiment, how digital production planning information is provided based on reverse planning logic.

[0152] Figure 123This is another flowchart illustrating how, according to one embodiment, digital production planning information is provided based on reverse planning logic.

[0153] Figure 124 This is a schematic diagram illustrating how, according to one embodiment, digital production planning information is provided based on forward planning logic.

[0154] Figure 125 This is a schematic diagram illustrating the workpiece group selection process based on forward programming logic using the LFS method, according to one embodiment.

[0155] Figure 126 This is a schematic diagram illustrating the job selection process using an LFS approach based on forward programming logic, according to one embodiment.

[0156] Figure 127 This is a schematic diagram illustrating an input decision based on the LFS approach using forward programming logic, according to one embodiment.

[0157] Figure 128 This is a schematic diagram illustrating the bucket selection process in an RFS (Reverse Flow) approach based on forward programming logic, according to one embodiment.

[0158] Figure 129 This is a schematic diagram illustrating the workpiece group selection process based on forward programming logic in an RFS manner according to one embodiment.

[0159] Figure 130 This is a schematic diagram illustrating the workpiece selection process in an RFS (Research, Fiber, and Scrap) manner based on forward programming logic, according to one embodiment.

[0160] Figure 131 This is a schematic diagram illustrating a processing procedure based on forward programming logic according to one embodiment.

[0161] Figure 132 This is a flowchart illustrating, according to one embodiment, how digital production planning information is provided based on forward planning logic.

[0162] Figure 133 This is another flowchart illustrating how, according to one embodiment, digital production planning information is provided based on forward planning logic.

[0163] Figure 134 This is a schematic diagram illustrating how, according to one embodiment, digital production planning information is provided based on a comparative decision agent.

[0164] Figure 135 This is a flowchart illustrating a decision-making process based on a decision-making method, according to one embodiment.

[0165] Figure 136 This is a flowchart illustrating a decision-making process based on a weighted sum method, according to one embodiment.

[0166] Figure 137 This is a flowchart illustrating a decision-making process based on a weighted ranking method according to one embodiment.

[0167] Figure 138 This is another flowchart illustrating how, according to one embodiment, digital production planning information is provided based on a comparison decision agent.

[0168] Figure 139 This is a schematic diagram illustrating a strategy operation system tool according to one embodiment.

[0169] Figure 140 This is a schematic diagram illustrating the configuration of an action selector according to one embodiment.

[0170] Figure 141 This is a schematic diagram illustrating the configuration of a feature extractor according to one embodiment.

[0171] Figure 142 This is a schematic diagram illustrating the configuration of an evaluator according to one embodiment.

[0172] Figure 143 This is a schematic diagram illustrating the configuration of a policy manager according to one embodiment.

[0173] Figure 144 This is a schematic diagram illustrating the configuration of a reinforcement learning operations manager according to one embodiment.

[0174] Figure 145 This is a flowchart illustrating the generation of a production plan using dynamic tools according to one embodiment.

[0175] Figure 146 This is a schematic diagram illustrating a strategy operation system tool according to one embodiment.

[0176] Figure 147 This is a schematic diagram illustrating the execution entity of a strategy operation system according to one embodiment.

[0177] Figure 148 This is a schematic diagram illustrating the generation of a production plan through a strategy operation system according to one embodiment.

[0178] Figure 149 This is a schematic diagram illustrating the generation of a production plan through a strategy operation system according to another embodiment.

[0179] Figure 150 This is a flowchart illustrating, according to one embodiment, the execution of a simulation and generation of performance metrics through a strategy operation system.

[0180] Figure 151 This is a flowchart illustrating the steps of initializing a policy operation system according to one embodiment.

[0181] Figure 152 This is a flowchart illustrating the generation of production plan data through a strategy operation system according to one embodiment.

[0182] Figure 153 This is a schematic diagram illustrating a policy learning system tool according to one embodiment.

[0183] Figure 154 This is a schematic diagram illustrating the execution entity of a policy learning system according to one embodiment.

[0184] Figure 155 This is a schematic diagram illustrating policy learning performed by a policy learning system according to one embodiment.

[0185] Figure 156 This is a schematic diagram illustrating policy learning performed by a policy learning system according to another embodiment.

[0186] Figure 157 This is a flowchart illustrating the process of performing learning through a policy learning system according to one embodiment.

[0187] Figure 158 This is a flowchart illustrating the steps of initializing a policy learning system according to one embodiment.

[0188] Figure 159 This is a flowchart illustrating, according to one embodiment, the acquisition of rewards or performance metrics during policy learning.

[0189] Figure 160 This is a flowchart illustrating the generation of a policy through a policy learning system according to one embodiment.

[0190] Figure 161 This is a schematic diagram illustrating a dynamic strategy operation and learning system tool according to one embodiment.

[0191] Figure 162 This is a schematic diagram illustrating the execution entity of a dynamic strategy operation and learning system according to one embodiment.

[0192] Figure 163 This is a schematic diagram illustrating a simulation performed by a dynamic strategy operation and strategy learning system according to one embodiment.

[0193] Figure 164 This is a flowchart illustrating the execution of dynamic policy operations through a dynamic policy operation and learning system according to one embodiment.

[0194] Figure 165 This is a flowchart illustrating the generation of production plans through dynamic strategy operation and learning, according to one embodiment. Detailed Implementation

[0195] The following discloses embodiments that can solve the above-mentioned problems and overcome the above-mentioned technical inconveniences. Hereinafter, when referring to the configuration elements of the embodiments, unless specifically limited to physical devices, they can all be implemented by optimized hardware or software.

[0196] Figure 1 This is a schematic diagram illustrating one embodiment of a method for providing digital production planning information.

[0197] Receive data patterns about input data from the client executing the production plan, the input data including baseline information for production execution (S10).

[0198] Here, the reference information used for production execution refers to various reference information in the place where production is performed, such as within the manufacturing (production) system, the specific content of which will be described in detail below.

[0199] The data patterns include baseline information for production execution, and in addition to the general process data patterns required to generate digital production plans, they may also include customized data patterns that are only applicable to the corresponding products or processes.

[0200] This step can be omitted if the structure or type of the data related to the baseline information provided by the client is known in advance, or if the client has prepared production and operation data according to a predetermined data pattern.

[0201] Input data, including baseline information for production execution, may include specific points in time with a certain format and content, such as data at the current time, and data representing the status of the manufacturing production system.

[0202] Based on the data pattern received from the client, a software model and logic set can be generated (S20).

[0203] In this step, based on the data pattern received from the client, at least one software model or logical set capable of generating relevant production planning information can be generated.

[0204] Here, a software model refers to a program designed to execute on a computer, which is part of the computational software that generates results using received data.

[0205] On the other hand, the "logic" referred to herein refers to a computational model or program, which can be a file containing rules for data generation, storage, modification, etc.; this file can be regarded as a dataset, which includes the program used to determine the execution mode of the SW model during execution, and includes the data required to implement the core functions of the computational SW model. Therefore, the logic set can be a collection of structured rules defining what kind of job to process the input data into, and is provided in the form of a file.

[0206] At least one of these software models or model logics, at least a portion of which can be prepared in advance within the system. Furthermore, in order to generate relevant production planning information, a portion of the required software model and a portion of the logic can also be generated in this step.

[0207] For example, in a cloud system that provides production planning based on input data, a user-customized set of logic can be generated in this step, or this step can be omitted. Here, the input data includes baseline information provided by the client.

[0208] According to the data pattern, input data is received from the client (S30).

[0209] Input data can be prepared in advance based on the data pattern received from the client's system, or, when a data pattern is obtained from the client, input data that can be used to generate production plan information can be received from the client based on its data pattern.

[0210] If the input data is stored in the client's database, it can be configured to retrieve the input data from this database, or to receive it in a deterministic or automatic manner.

[0211] The generated software model and logic set can be tested (S40).

[0212] After receiving data that conforms to the data pattern from the client, the software model or logic generated above can be tested based on this data.

[0213] It can perform simulations based on software models or logic as a form of production planning system modeling, and query the results.

[0214] Here, you can modify various settings variables that affect production planning, or configure multiple options required for model execution. Based on changes to variables or settings, you can test whether the SW model generates optimized production planning data under various environments. For example, you can execute experiments that utilize a software model or logic to design various combinations of variables and performance indicators affecting production planning. An experiment can include one or more execution scenarios with specific variables or performance indicators selected for execution.

[0215] When using multiple software models or logic, an Experiment Hub (experiment platform) that includes multiple experiments can also be generated.

[0216] Furthermore, the engine, serving as the core of the software model or logic, can be used to generate output data, including production planning information, from the received input data. This step allows for testing of computer-implemented models that adapt to various scenarios involving changes to input data, the engine, output data, and other configuration elements.

[0217] If this test is not required and the variables that have already been set are used, for example, if a production plan type applicable to a specific industry sector has been set, this step can be omitted.

[0218] Based on the received input data, the software model and logic set are provided, or production plan data generated by executing the software model and logic set is provided (S50).

[0219] In this step of the embodiment, a software model and model logic can be provided to the client based on the generated production plan data. Alternatively, the software model and model logic can be executed based on the generated production plan data, and production plan data based on the execution results can be provided to the client.

[0220] The generated production plan data can be uploaded to the client system's database, etc.

[0221] One embodiment of this method for providing digital production planning information can be implemented through platforms such as on-premise computing systems or cloud computing systems. If the embodiment is implemented through a cloud computing system, the client can obtain the production plan via a SaaS (Software-as-a-Service) package that implements this embodiment.

[0222] Furthermore, when executing the generated software model and model logic, various extended functions for decision-making can be used. These extended functions can be used to modify parameters required for the scenario or simulation, or to perform machine learning to generate production planning data. Detailed embodiments of this will be described below.

[0223] The following is an embodiment of a computing system that implements a method for providing digital production planning information.

[0224] Figure 2 This is a schematic diagram illustrating one embodiment of a computing system that provides digital production planning data.

[0225] This figure is a schematic diagram illustrating one embodiment of a local computing system that provides digital production and operation data.

[0226] In one embodiment, a manufacturing production system 100 that executes production planning on a client side provides input data, including baseline information for production execution, to a local computing system 1000, and receives digital production planning data generated therefrom from the local computing system 1000.

[0227] In this embodiment, the manufacturing production system 100 includes a system operation unit 110 that comprehensively operates and manages the manufacturing process, a model execution unit 130 that generates production plan data according to the execution request of the system operation unit 110, and a database 150 that stores the execution results of the model execution unit 130, i.e., the production plan data.

[0228] In this embodiment, the local computing system 1000 can be located on the client side or provided by a service provider outside the client.

[0229] A local computing system 1000 according to one embodiment includes a model development unit 1100 and a server management unit 1200. The model development unit 1100 develops models related to production planning based on input data or input data patterns received from a client manufacturing system 100. The server management unit 1200 manages the client-side operation server to provide the models to clients and enable their execution.

[0230] According to one embodiment, the local computing system 1000 may further include a model analysis unit 1300, which is used to change and analyze the settings of software models or logic sets developed by the model development unit 1100.

[0231] Furthermore, according to one embodiment of the local computing system 1000, it may further include a model execution unit 1400, which is capable of pre-executing the software model or logic analyzed by the model analysis unit 1300 to obtain results. In this embodiment of the local computing system 1000, if the model analysis unit 1300 and the model execution unit 1400 are included, the execution results of the model to be executed in the client's manufacturing production system 100 can be pre-analyzed and modified, thereby generating an optimal production operation plan.

[0232] The local computing system 1000 receives data patterns related to production planning from the manufacturing system 100. The input data includes baseline information for production execution, and the data patterns of the input data include the basic format of the data required to execute the software model or logic. This data pattern allows data of various information and types, depending on the manufacturing system 100, to be received in a specific format and content.

[0233] The model development unit 1100 of the local computing system 1000, based on the received data patterns and the library engine set 1150, can generate software models or logical sets for generating production planning data. The library engine set 1150 may include a core library, a production planning engine, and production-specific engines.

[0234] In the following text, "engine" or "engine set" refers to a software engine, meaning a software module that includes multiple encapsulated functional blocks, such as libraries or objects. When software is executed, if an engine is used, the software model or logic connected to that engine software can perform common and essential functions.

[0235] The core libraries of the Library Engine Set 1150 are similar to those of the Production Planning Engine, including a collection of data structures for implementing production planning.

[0236] Furthermore, the production-specific engine of the library engine set 1150 inherits some of the functions of the production planning engine, and implements a dataset of logic for a specific production field, which can be defined differently depending on the industry or manufacturing production system.

[0237] The production planning engine of Library Engine Set 1150 is defined as a set of encapsulated functional blocks that generate production plans.

[0238] According to one embodiment, the core library of the library engine set 1150 includes a general library for generating software models and model logic.

[0239] That is, the model development unit 1100 receives the data pattern of input data from the client according to predefined rules. The model development unit 1100 can predefine the data pattern received from the client as the data format required to execute the software model and model logic.

[0240] The model development unit 1100 can also be configured to set the order for collecting baseline information of the manufacturing production system in the data model, or the necessary information required for the execution of the software model and model logic. For example, the model development unit 1100 can configure the method and data format for obtaining data from the database 150. For example, the size, order, and receiving conditions of the data download can be configured.

[0241] The model development unit 1100 provides a variety of development tools to generate appropriate software models and model logic based on the received data patterns and library engine set 1150.

[0242] The software model and model logic generated by the model development unit 1100 can include various modules, such as the pegging steps described later or various simulations. The model development unit 1100 can define the software model, define the data to be used, and store the generated data.

[0243] The model development unit 1100 allows for the setting of various variables or logic within the developed software model, model logic, scenario, or simulation-related modules. The software model and model logic can be used for, for example, production planning decision optimization, machine learning, and experimental design in various fields.

[0244] The model development unit 1100 can combine various modules to define the software model and model logic according to the production plan form expected by the client. For example, if only the plan for inputting products into the factory is desired, the input plan can be obtained using the reverse planning hook module described later.

[0245] In another embodiment, if a production plan that takes into account the monthly product input plan is to be obtained when formulating a weekly production plan, the input plan obtained in the first module, i.e. the hooking module, can be used as the input value of the second module, i.e. the simulation module, thereby creating a model that generates the production plan in sequence.

[0246] The model development unit 1100 can define the configuration elements of the various modules included in the software model. For example, the logic of the simulated factory, workpiece, input allocation, and constraints can be modified to be reproduced in the client's manufacturing system.

[0247] Furthermore, the model development unit 1100 can also manage the execution of multiple modules added to the software model and logic.

[0248] The server management unit 1200 transmits the software model and model logic generated by the model development unit 1100 to the client, and enables the client's manufacturing system 100 to generate production plan data for production operation.

[0249] The server management unit 1200 transmits the software model and model logic to the client's system operation unit 110, and defines, schedules, and registers jobs related to the execution of the software model. The client's system operation unit 110 can execute model execution jobs according to the specifications of the server management unit 1200 or its users.

[0250] The server management unit 1200 not only manages the system operation unit 110 of the client's manufacturing production system 100, but also manages triggers used for operation according to projects, tasks or plans, and changes and sets their monitoring and performance.

[0251] On the other hand, in one embodiment, the model analysis unit 1300 can change various settings of the software model and model logic, and generate production plan data in the model execution unit 1400 for testing and analysis.

[0252] The model analysis unit 1300 provides a tool that, based on the software model and model logic generated by the model development unit 1100 and the received data pattern, transmits the input data to the model execution unit 1400 and executes it, and then analyzes the results.

[0253] In the model analysis unit 1300, if the software model and model logic need to be changed based on the results, the library engine set 1150 can be changed.

[0254] For example, the model analysis unit 1300 can receive input data from the client's database 150 in the form of files through queries or other means. This input data includes a benchmark information dataset of the manufacturing production system.

[0255] The model analysis unit 1300 provides tools for experimental analysis of the software model and model logic developed by the model development unit 1100 by changing the library engine set 1150 and the baseline information of the input data.

[0256] For example, the model analysis unit 1300 can use the dataset containing baseline information in the received input data to generate production plan data through the model execution unit 1400.

[0257] The model analysis unit 1300 can provide a user interface for querying information about the software model and model logic, as well as the execution results.

[0258] The model analysis unit 1300 can provide users with input data for the software model and model logic, various setting information, and analysis results based on the modeling results.

[0259] The model analysis unit 1300 can set various scenario information when executing software models and model logic.

[0260] For example, as information for various scenarios, it is possible to modify the baseline information input values ​​of the manufacturing system, the version of the library engine set 1150, etc.

[0261] The model execution unit 1400 executes the software model and model logic and generates production plan data, thereby providing analyzable production plan data to the model analysis unit 1300.

[0262] When the system operation unit 110 of the client's manufacturing production system 100 receives the software model and model logic developed by the model development unit 1100 through the server management unit 1200, it obtains input data including baseline information data from the database 150 and uses this data to execute the received software model and logic set to generate production plan data.

[0263] The generated production plan data can be uploaded again and stored in database 150.

[0264] According to one embodiment, the local computing system 1000 can receive input data including manufacturing system baseline information from the client, execute the developed software model and model logic to generate production plan data. Alternatively, the client's manufacturing system 100 can also use the software model and logic set provided by the local computing system 1000 to generate production plan data.

[0265] Detailed embodiments of the configuration elements of the local computing system 1000 will be described below.

[0266] Figure 3 This is a schematic diagram illustrating another embodiment of a computing system that provides digital production planning data.

[0267] This diagram illustrates an embodiment of a cloud computing system that provides digital production operations data. According to one embodiment, the cloud computing system can provide digital production planning data in the form of SaaS (Software-as-a-Service).

[0268] In the disclosed embodiments, a client-side manufacturing system 100, including a database 150, provides input data, including manufacturing system baseline information, to a cloud computing system 2000, and receives production planning data as a result thereof.

[0269] The cloud computing system 2000 provides production planning data optimized for client system conditions, and may include an operations management unit 2100, a model execution unit 2400 that executes defined software models and logic sets, and a cloud database 2500.

[0270] The library engine set 2210 of the cloud computing system 2000 includes a core library and a production planning engine. The core library includes the main data used to generate software models, and the production planning engine is a set of various encapsulated functional blocks for generating production plans.

[0271] Unlike development on a local computing system, cloud computing systems 2000 include predefined software models and logic sets 2230 that are generalized for products or scenarios. However, they may further include a set of custom library engines 2250 for generating customized production and operation plans for clients.

[0272] The client-side manufacturing system 100 includes a database 150, which stores input data related to production operations and includes baseline information.

[0273] The client-side manufacturing system 100 can execute inbound logic 170 to convert the pattern of input data stored in database 150 and upload the converted input data to cloud database 2500.

[0274] According to the execution of the inbound logic 170 of the client manufacturing system 100, the input data, including client baseline information data, can be stored in the cloud database 2500.

[0275] The operations management unit 2100 can generate production plan data based on the library engine set 2210, the software model and logic set 2230, and the customized library engine set 2250, using the input data stored in the cloud database 2500, according to the settings of the client or cloud system administrator.

[0276] The generated production plan data can be stored again in cloud database 2500.

[0277] The cloud computing system 2000 provides the production plan data stored in the cloud database 2500 to the client through the outbound API 2710 in the form of a preset user interface.

[0278] The client may have interfaces for setting up model execution in the cloud computing system 2000, modifying the custom library engine set 2250, or obtaining the final production plan data.

[0279] The cloud computing system 2000 has various configuration elements with different functions than the local computing system 1000, and detailed embodiments of this will be described below.

[0280] In the following embodiments, embodiments for providing production planning data using software models and logic sets generated based on an installed library engine set will be disclosed in detail.

[0281] As previously mentioned, the model development unit 1100 of the local computing system 1000 provides a framework that can be used to develop software models and logic sets capable of generating production plans based on the library engine set 1150.

[0282] In another embodiment, the cloud computing system 2000 can provide multiple standardized software models and logic sets based on a library engine set, which can generate production plans.

[0283] In the disclosed embodiments, the software model and logic set capable of generating production plans can schedule production plans in a time-reverse calculation manner and calculate step targets. Step targets may include target quantity information and date information for the step. Here, the time-reverse calculation method for scheduling production plans can be referred to as backward planning.

[0284] The Library Engine Set 1150 provides a core library capable of generating reverse planning logic in a time-reverse calculation manner.

[0285] The model development unit 1100 can be configured to generate a software model and logic set, including reverse planning logic, based on the library engine set 1150. Here, reverse planning is a method of allocating workpieces by working backward from the delivery date and target output information of demand information to calculate the time and quantity.

[0286] That is, based on the waiting time (Wait TAT), run time (Run TAT), and yield (Yield) of each process set in order to complete production before the delivery date of the finished product included in the demand information, the quantity and time point of the input target (In Target) of the production process, as well as the quantity and time point of the completion target (Out Target) of the process are calculated.

[0287] For example, demand information, namely the delivery time and quantity of finished products, is used to calculate the quantity and time of the input target of the Nth process based on the quantity and time of the completion target set to meet the delivery time of the finished products, by reverse calculation of operation time and yield information.

[0288] Furthermore, based on the target quantity and time information of the Nth process set to meet the finished product delivery time, and taking into account the input waiting time, the target quantity and time information of the (N-1)th process can be calculated in reverse.

[0289] In this way, by reverse-calculating the operation time and yield information of each of the 1, 2, 3, ..., N processes, as well as the waiting time for the process to be put into operation, the production plan can be calculated.

[0290] In essence, backward planning involves calculating process target information to meet delivery dates and quantities based on demand information.

[0291] Here, the process target information may include the process's planned input date, planned input quantity, process completion date, and completion quantity.

[0292] In another embodiment, the process target information may also include the process input target time point information (InTarget Date), the input target time point quantity information (InTarget Quantity), the process completion target time point information (OutTarget Date), and the completion target time point quantity information (OutTarget Quantity).

[0293] Thus, depending on the circumstances, the process target information can use the process input plan information and completion information, or it can use input target information and completion target information.

[0294] Figure 4 This is a schematic diagram illustrating the steps of performing reverse programming logic according to one embodiment. Referring to this diagram, an embodiment of the steps of performing reverse programming logic is conceptually explained below.

[0295] Reverse planning logic refers to starting from the last process step and proceeding in reverse time from the beginning or end of the waiting or running state of each process step to obtain the information needed for production planning.

[0296] In this diagram, it is assumed that the production operations are carried out in the order of the first operation, ..., the (i-1)th operation and the ith operation.

[0297] When using reverse programming to generate a production plan, each process has input target information (including time point and quantity) and completion target information (including time point and quantity) for the workpieces put into each operation.

[0298] Here, arrows represent the input target information for the first process, the input target information for the (i-1)th process, and the time point information for the input target information for the i-th process. Furthermore, the completion target information for the (i-1)th process and the time point information for the completion target information for the i-th process are also shown.

[0299] In reverse planning logic, the input target time point and the completion target time point of each process can become the time processing points for calculating the production plan.

[0300] Each process operates within the operation time (running TAT), from the completion target time of process (completion target i-1) to the input target time of process i (input target i). The workpiece can wait during the input waiting time (waiting TAT), and each process can have yield information.

[0301] During reverse programming, information about the workload (running batch attachment), operation time, and yield is applied in the i-th operation. Furthermore, between the i-th and (i-1)-th operations, information about the workload (waiting batch attachment) and input waiting time is applied.

[0302] Thus, reverse planning logic unfolds in reverse time from the last process to the first process in the process sequence, thereby obtaining the information needed for production planning.

[0303] Figure 5This is a schematic diagram illustrating the execution steps of reverse planning logic within a library engine set according to one embodiment.

[0304] When the library engine set includes reverse planning logic, the software model and logic set generated based on the client's data pattern can generate a production plan according to the reverse planning logic.

[0305] In the following text, to facilitate the illustration of an embodiment of the reverse planning logic within the library engine set, an embodiment of generating production plan data based on the generated software model and logic set according to the reverse planning method is disclosed.

[0306] The reverse planning method may include demand information preprocessing (Demand Manipulation) S210, pegging initialization (Pegging Initialization) S220, site allocation (S230), pegging (Pegging) S240, and make inplan (make inplan) S250.

[0307] The generated software model and logic set can obtain demand information, actual production record information (ACT), work-in-process (WIP), process flow information (BOP), yield information, and time information (TAT) (input waiting time or operation time of each process) from the manufacturing production system baseline information in order to perform reverse planning.

[0308] The demand information preprocessing step S210 can preprocess the demand information based on the demand information, the actual production record information of the manufacturing system, the remaining demand quantity, and the production schedule in the data received by the manufacturing system.

[0309] For example, actual production records can be subtracted from demand information, and the remaining demand quantity can be calculated based on the work schedule.

[0310] If the demand information is based on a weekly plan with delivery dates, a preprocessing job can be performed that preprocesses the remaining demand quantity and delivery dates by day.

[0311] The initialization step S220 is a step that initializes the preprocessed requirement information into data for reverse planning. After the data initialization, it is verified to confirm that no problems will occur in subsequent steps. For example, the preprocessed and initialized requirement information can be grouped according to units such as the same product, product group, or process to initialize the job object information (PegPart) of the reverse planning object.

[0312] In reverse programming, information such as the operation time, operation process, quantity, and delivery date of each process will change. It is possible to initialize and generate work object information that changes according to each process. This will be explained below.

[0313] The site allocation step S230 receives the initialized job object information. When multiple production facilities exist in the manufacturing system, the site allocation step S230 can perform the step of allocating sites according to the allocation rules based on the demand information. When site allocation information is obtained in advance from the client's manufacturing system or from results exported from an external solution, the site allocation step S230 can be omitted.

[0314] In the hooking step S240, the initial job object information and the allocation information from the previous step, namely the site allocation step S230, are received.

[0315] The connection step S240 calculates the completion target time information, the quantity information of the completion target time points, the input target information and completion target information of each process based on the initial requirement information, and finally outputs log record information including connection history (Peghistory) and process target information.

[0316] Furthermore, the linking step S240 can calculate various object information, including input planning information (including quantity and time point) for the next process.

[0317] The attachment step S240 can serve as the output object information for each process, calculating the quantity information of the work-in-process. For example, the workpiece quantity information, which serves as the output object information, can include process priority sorting, process selection, process operation quantity, process delivery date information, process time update, process yield application, and process log record information.

[0318] The factory input plan calculation step S250 receives the information output from the previous step, i.e., the connection step S240, and calculates the factory input plan information (Release Plan) (including quantity and time point) of the initial process from the demand information of the final process.

[0319] Using input planning information (including quantity and time points), guidance information for forward planning to generate production plans in chronological order can be obtained. In one embodiment, the execution of input planning calculation step S250 can be omitted.

[0320] Therefore, according to one embodiment, if the software module and module logic execute reverse planning logic, the process target and the input plan information of the process can be calculated.

[0321] Figure 6 This is a schematic diagram illustrating the execution of reverse programming according to one embodiment.

[0322] Reverse planning involves working backward from demand information to calculate the input target information and the production plan within the process completion target.

[0323] In this embodiment, it is assumed that the actual process flow is performed in the order of the first process S1, the second process S2, and the third process S3. The reverse planning method is to consider the target demand information of the process including these three processes, and calculate the production plan in the reverse order of the third process S3, the second process S2, and the first process S1.

[0324] The baseline demand information is shown in Table 261. It is based on the remaining demand quantity after subtracting the actual production records from the demand information, and is divided and allocated to equipment A or B according to schedules D0, D1, D2, D3, and D4.

[0325] Reverse programming, based on Table 261, applies the process operation time of the third process S3 and a yield of 100% to calculate the intermediate production plan Table 263 for the arrival time (In Target) of the third process S3. Since the process operation time is 0 days and the yield is 100%, Table 263 has the same values ​​as Table 261.

[0326] Furthermore, reverse programming, based on the intermediate production schedule in Table 263, applies the input waiting time (Wait TAT: 1 day) for the third process S3 and the connection regarding the waiting amount (Wait lot pegging) to calculate Table 265, which serves as the intermediate production schedule for the completion target time of the second process S2. Table 265 applies the input waiting time (Wait TAT: 1 day) for the second process S2, and therefore has values ​​that shift the data in schedules D0, D1, D2, D3, and D4 of Table 263 by 1 day.

[0327] Reverse programming, based on the intermediate production plan in Table 265, applies the 50% yield of the second process S2, the linkage of process workload (running batch linkage), and the process operation time to calculate Table 267, which serves as the target entry time for the second process S2. The values ​​in each schedule of Table 267 are the results of reverse calculation of the 50% yield of the second process S2 and the process operation time (running TAT: 1 day). Therefore, the schedules in Table 265 are shifted, and their values ​​are twice those in Table 265.

[0328] In this embodiment, finally, reverse planning is performed on the intermediate production plan in Table 267 to calculate the connection and input waiting time (waiting TAT: 1 day) of the second process S2 at the target completion time of the first process S1, in order to calculate the production plan in Table 269. Table 269 has values ​​that shift each schedule in Table 267 due to the reverse calculation of the input waiting time (waiting TAT: 1 day) of the second process S2.

[0329] Thus, reverse planning is based on demand information, and in order to calculate the time and quantity of input targets, as well as the time and quantity of completion targets, it takes into account workload, waiting time, and yield to reverse calculate production plan information.

[0330] This reverse programming approach can calculate the target delivery date and output information in reverse order as described above to generate input and completion target information for each process. Furthermore, using this input and completion target information, the production plan is scheduled in chronological order, and the production plan can be calculated through forward programming.

[0331] Figure 7 This is a flowchart illustrating, according to one embodiment, the generation of a production plan using a software model and logic set including reverse planning logic.

[0332] Based on the data pattern of the client-side manufacturing production system, generate or provide a software model and logic set including reverse planning logic (S22).

[0333] The data pattern for the client executing the production plan can be prepared in advance if the structure or type of data related to the baseline information provided by the client is known in advance. Alternatively, a data pattern that includes baseline information as input data for production execution can be received from the client.

[0334] In a local computing system, if the library engine set includes reverse planning logic, a software model and logic set can be generated based on the client's data pattern.

[0335] Based on a library engine set that includes backward programming logic, the client can provide a software model and logic set for executing backward programming logic.

[0336] The software model and logic set may include the reverse programming logic disclosed above. Detailed embodiments of the reverse programming logic have been described in [the relevant documentation / documentation]. Figures 4 to 6 It is publicly available in China.

[0337] According to the data pattern, input data is received from the client (S30).

[0338] When production plans are generated and provided using a local computing system, various conditions can be added to the received software model and logic set, including reverse planning logic, to perform tests on the software model and logic set.

[0339] Input data may include baseline information from the client's manufacturing system. This baseline information may include demand information for each process, production record information or actual production performance information (ACT), the number of workpieces in the current operation (i.e., work-in-process quantity information), process flow information, yield information, and input waiting time (TAT) or process operation time as process time information.

[0340] Based on the received input data, a software model and logic set including the reverse planning logic are executed to provide generated production plan information (S55).

[0341] Reverse planning logic can generate process target information (quantity and target) from baseline information such as target output and demand information included in the input data in a time-reverse calculation manner.

[0342] In addition, the reverse planning logic can generate demand pegging information for each process and unprocessed job information after time pegging in each process, i.e., historical information (Peghistory), based on the baseline information.

[0343] If the aforementioned software model and logic set include forward programming logic, then production planning information can be generated in chronological order using the process target information and factory input plan information obtained from the reverse programming logic.

[0344] Detailed steps regarding the logic of reverse programming have been provided in [the document / document / etc.]. Figure 5 The explanation is as follows.

[0345] The software model and logic set of the embodiments disclosed above may include forward programming logic executed based on the result of the reverse programming logic or the reverse programming logic executed after execution.

[0346] Figure 8 This is a schematic diagram illustrating one embodiment of a device for providing digital production planning information.

[0347] An apparatus for providing digital production planning information according to one embodiment may include an input unit 310, a storage device 320, a memory 330, a processor 340, an output unit 350, and a user interface 360.

[0348] In the following description, the apparatus for providing digital production planning information according to one embodiment will be controlled according to user control and management of user interface 360.

[0349] Input unit 310 receives the data pattern of its manufacturing system from the client manufacturing system.

[0350] The storage device 320 stores the data pattern received by the input unit 310, or, if a standardized data pattern is prepared in advance, stores the standardized data pattern in the storage device 320. The storage device 320 may include volatile memory or non-volatile memory.

[0351] The 330MB of memory can store the library engine set disclosed above.

[0352] The library engine set may include a production planning engine, which is a collection of encapsulated function block files that generate production plans. The production planning engine may include files regarding the reverse planning logic disclosed above.

[0353] In addition, the library engine set may further include core library files that implement the data structure for production planning together with the production planning engine, as well as production domain-specific engines that inherit some of the functions of the production planning engine and implement logic for specific production domains.

[0354] In one embodiment, processor 340 can receive a data pattern stored in storage device 320. Furthermore, processor 340 can generate a software model and logic set based on the data pattern and an engine or library stored in memory 330. The generated software model and logic set can generate production plan data in a time-reverse calculation manner according to reverse programming logic. An embodiment of generating production plan data in a time-reverse calculation manner according to reverse programming logic has been described. Figures 4 to 6 It is publicly available in China.

[0355] The processor 340 can test or pre-execute the generated software model and logic set according to user requests from the user interface 360 ​​to obtain production plan data. Furthermore, the processor 340 can provide the user with analysis or test results of the software model and logic used to generate the production plan data through the user interface 360, according to user requests.

[0356] Based on the data pattern received from input unit 310, processor 340 can receive input data including the manufacturing production system reference information. Processor 340 can execute a software model and logic set including a time-reverse calculation method based on reverse programming logic to generate production plan data. Detailed embodiments for generating production plan data based on reverse programming logic have been described in [the relevant documentation / documentation]. Figures 4 to 6 It is publicly available in China.

[0357] Output unit 350 provides the client manufacturing system with production plan data based on the execution results of a software model and logic set, including reverse planning logic, so as to manage production or processes in the client system.

[0358] According to one embodiment, production planning information can be obtained based on baseline information received from the client manufacturing system, using a time-reverse scheduling method. Using this time-reverse method, process target information and input plan information for each process can be obtained, and the factory input plan information for the initial processes can be calculated based on the demand information of the final process generated by time-reverse calculation. This time-reverse method can generate and provide efficient production planning information.

[0359] Clients can execute production based on production plans generated in reverse time, or combine them with time-sequential production plans to obtain more detailed and efficient production plans.

[0360] The following will disclose in detail an embodiment of providing production planning data, which utilizes a software model and logic set generated based on an installed library engine set.

[0361] As previously mentioned, the model development unit 1100 of the local computing system 1000 provides a framework that can be used to develop software models and logic sets capable of generating production plans based on the library engine set 1150.

[0362] In another embodiment, the cloud computing system 2000 may provide multiple standardized software models and logic sets based on the library engine set 2210, which can generate production plans.

[0363] In the disclosed embodiments, a software model and logic set capable of generating production plans are used to simulate events occurring in an actual factory production system in a time-sequential manner to formulate production plans. This time-sequential scheduling of production plans can be referred to as forward programming.

[0364] The model development unit 1100 can be configured to generate a software model and logic set including forward programming logic based on the library engine set 1150. The forward programming method is to simulate the actual production plan by executing events that may occur in the factory in chronological order, starting from the initial input time of the workpiece, based on at least one of the factory input plan information, input plan information (including quantity and time point), process target information, and attachment history information output by the above reverse programming results.

[0365] For example, forward programming can use discrete event simulation to calculate, in chronological order, when, through which process route, and what operations the production plan will be executed from the time the actual workpiece is put into the factory until production ends (or is completed), thereby simulating the execution of the production plan.

[0366] In other words, forward planning is based on the process objectives calculated from the results of backward planning. For actual factory workpieces (lots) or equipment (equipment), detailed production plans are calculated by executing events such as process route, workpiece filter, workpiece transfer, dispatching, workpiece input, and workpiece out (disappearance).

[0367] Figure 9 This is a schematic diagram illustrating the steps of performing forward programming logic according to one embodiment. Referring to this diagram, an embodiment of the steps of performing forward programming logic is conceptually described below.

[0368] Forward programming logic refers to the process of simulating the actual factory by performing a time-series simulation of the equipment or workpiece from the moment the workpiece is first put into the factory until the moment it is completed, in order to calculate the production plan and production scheduling.

[0369] By using forward programming logic, a simulation model of the actual factory can be created and driven. Through events such as workpiece input, entry into the buffer zone, workpiece movement, process route, processing, tool change, input decision, workpiece screening, and workpiece exit, the dynamics of the real factory can be reproduced to formulate production plans.

[0370] Workpiece input is the event of planning when and how many workpieces will be input into the factory. Workpiece output is the event concerning the completion of the final process for a workpiece. Workpiece movement is the event of moving a workpiece to the next process after the current process is completed. Process routing is the event that determines which process a workpiece will be moved to. Furthermore, process handling is the event of processing assigned tasks on workpieces that have been input into equipment within a certain timeframe. Equipment changeover is the event of changing tools when tools need to be changed before a workpiece is input into equipment. Input decision is the event of deciding which workpiece to prioritize among waiting workpieces. Workpiece screening is the event of deciding on screening related to workpieces or equipment before the input decision.

[0371] For example, if a workpiece waiting in a certain process is selected and put into the equipment through an input decision, it is possible to determine which process route it will move to after a certain operation time. Alternatively, it can be determined that the workpiece will be completed through a process route after a certain operation time. Or, workpiece screening can be planned before the workpiece input decision is made.

[0372] Figure 10 This is a schematic diagram illustrating the execution steps of forward planning logic within a library engine set according to one embodiment.

[0373] When the library engine set includes forward planning logic, the software model and logic set generated based on the client's data pattern can generate a production plan according to the forward planning logic. In one embodiment, the software model and logic set generated based on the client's data pattern can use the result of the aforementioned reverse planning logic as input to generate a production plan according to the forward planning logic.

[0374] In the following, to facilitate the illustration of an embodiment of the forward programming logic within the library engine set, an embodiment is disclosed in which production plan modeling for discrete event simulation is performed by the generated software model and logic set according to the forward programming approach.

[0375] To implement this forward programming logic, discrete event simulation modeling can be performed. Unlike continuous event simulation, discrete event simulation models events in a forward-flowing sequence over time, where each event occurs at a specific point in time, thereby changing the state of the system.

[0376] Modeling in discrete event simulation can be achieved using a global clock, state variables, and event queues associated with the events. An event is the unit that causes a state transition in a manufacturing system. Furthermore, this embodiment illustrates the execution of forward planning for calculating a production schedule within a model that includes at least one piece of equipment or workpiece. For example, the model refers to a model used for manufacturing system planning, representing equipment, workpieces, or their dynamic relationships.

[0377] A global clock can represent simulation time during event execution. State variables can represent the simulated states (e.g., processes, equipment, workpieces, queues, etc.) within a manufacturing system. For example, each state variable may include at least one corresponding event. An event queue can represent a set of events arranged with at least one event. For example, in an event queue, at least one event is arranged in chronological order during simulation, so events can be executed in FIFO (First-In, First-Out) order.

[0378] First, the event queue can be initialized (S110). Furthermore, the state variables and global clock can also be initialized during event queue initialization. At this time, the global clock time can correspond to 0. That is, in the forward programming logic, the simulation of the manufacturing system can begin with the event queue, state variables, and global clock initialized.

[0379] Next, an event can be selected from the event queue (S120). In one embodiment, the event that appears first in chronological order among at least one event in the event queue can be selected. In another embodiment, when there are multiple events with the same chronological order, a priority can be assigned to which event should be executed first, and the event can be selected according to the priority.

[0380] For example, the events of a workpiece exploring the next process route and the events of the equipment exploring the next workpiece may occur simultaneously. In this case, priorities can be assigned so that the event of the workpiece exploring the next process route is executed first, followed by the event of the equipment exploring the next workpiece.

[0381] When an event is selected, the selected event can be executed and the global clock updated (S130). In addition, when the selected event is executed, the state variable corresponding to that event can also be updated at the same time.

[0382] For example, when a workpiece input event occurs, the corresponding state variable, i.e., the workpiece information (WIP), can be updated. Furthermore, the global clock can be updated based on the time interval between the previous event and the current event.

[0383] Next, after the event is executed, it can be determined whether the termination condition (S140) is met. For example, the termination condition could correspond to the situation where all operations assigned to the workpiece within the factory have been completed, but it is not limited to this. At this point, the event concerning the workpiece can be terminated.

[0384] On the other hand, if the job being executed for an event does not meet the termination conditions, the next event can be selected from the event queue (S150). At this time, step S130 is performed to execute the next event and update the global clock.

[0385] When an event concerning a model including at least one device or workpiece terminates, production planning, including executed events and related global clock and state variable information, can be modeled (S160).

[0386] Therefore, according to one embodiment, if the software and model logic perform forward programming, the production plan for the workpieces put into the factory can be calculated in chronological order.

[0387] Figure 11 This is a schematic diagram illustrating the state variables of a forward programming method according to one embodiment.

[0388] As mentioned above, forward programming executes events sequentially from the moment a workpiece enters the factory to calculate the production plan. During this process, the state variable 3300 corresponding to each event will change based on the execution of those events.

[0389] State variable 3300 is a collection of various variables used to simulate the manufacturing system, including physical variables 3100 and logical variables 3200. The physical variables 3100 represent physical elements such as products, processes, equipment, and tools in the simulation configuration elements. There may be multiple physical variables 3100 depending on their type. The logical variables 3200 represent the dynamic parts of the simulation modeling or elements related to input decisions. There may be at least one logical variable 3200 depending on its type.

[0390] For example, physical variables 3100 may include, but are not limited to, a plant (not shown), a workpiece queue (buffer) 3110, workpiece status (WIPs) 3120, equipment 3130, tools 3140, etc. Furthermore, logical variables 3200 may include, for example, a route (router) 3210, a filter (filter) 3220, a workpiece transfer (transfer) 3230, a dispatching agent (dispatching agent) 3240, a workpiece manager (WIP manager) 3250, and a workpiece in / out agent (in / out agent) 3260, etc., but are not limited to.

[0391] Work queue 3110 represents workpieces waiting for processing, workpiece information (WIPs) 3120 represents workpiece information within the factory, equipment 3130 represents the object that processes the workpiece, factory represents the location where the workpiece operation is performed, and tool 3140 represents the tool required to perform the operation on the equipment.

[0392] In addition, the workpiece status manager 3250 represents the location and information management of all workpieces in the factory, and the workpiece input / output 3260 can represent the input and output management of workpieces in the factory.

[0393] According to one embodiment, in forward programming logic, as simulations proceed with the selection and execution of events for at least one device or artifact within the model, the state variables corresponding to those events change. For example, the state of a device may include idle, running, tool change, maintenance, down, up, etc., and the state of an artifact may include waiting, moving, processing, etc., but is not limited to these.

[0394] For example, when a process start event is executed, the corresponding state variables, i.e., the equipment or workpiece (job or batch), will change. The equipment's state will change from idle to running, and the workpiece will change from waiting to running or processing. Furthermore, for example, when a tool change event is executed, the corresponding state variables, i.e., the tool and equipment, will change. The number of available tools decreases, and the tool used by the equipment changes.

[0395] At this point, events corresponding to or associated with the changed state variables can be added to event queue 3400. Furthermore, after associated events enter event queue 3400, they can be executed in a specified order or at a specified time. For example, when executing a workpiece movement event, the state variable corresponding to the workpiece movement will change. When workpiece movement begins, the state of the workpiece object changes to "TRANSFERRING"; after movement ends, it changes to "Waiting" and triggers events to enter the queue (BUFFER). At this time, based on the change in the state variable corresponding to workpiece movement, other events besides workpiece movement can be added to the event queue.

[0396] That is, as the event is executed, the state variable 3300 corresponding to the event will change. The physical and logical variables used in the factory are not limited to the variables shown in the figure, and may also include other variables related to the workpiece or equipment.

[0397] Figure 12 This is a schematic diagram illustrating an event queue performing forward planning according to one embodiment.

[0398] Forward planning calculates the production plan by executing the logic from the input of the workpiece into the first process to the completion of the process in chronological order.

[0399] The events shown in the diagram represent events arranged in the event queue according to a preset benchmark, with the workpiece as the reference. For example, the preset benchmark can follow a chronological order or a priority, but is not limited to these.

[0400] Furthermore, the events shown in this figure can represent system dynamics, including state changes related to a workpiece, process, or equipment. Hereinafter, these will be collectively referred to as events. Additionally, the events illustrated can correspond to events occurring within a model that includes at least one piece of equipment or workpiece.

[0401] According to one embodiment, in the event queue, after the workpiece is released 3510, the workpiece can be put into operation 3520 first, and then set in the order of process route 3530, workpiece movement 3540, put-in decision 3560, process processing 3580, process route 3530, and workpiece exit 3590.

[0402] Alternatively, after executing the workpiece movement 3540 event, the workpiece screening 3550 event can be executed, or after executing the input decision 3560 event, the equipment change 3570 event can be executed. The events in the event queue and their order are merely examples and are not limited thereto.

[0403] As described above, based on at least one of the factory input plan information 3640, input plan information (Inplan) 3610, process target information 3630 and connection history information 3620 output by the reverse planning results, the simulation of the actual production plan can be executed in chronological order starting from the initial input time of the workpiece.

[0404] For example, the workpiece generation event 3510 can be executed based on the factory input plan information 3640 scheduled by the reverse programming result; the workpiece input event 3520 can be executed based on the input plan information 3610 scheduled by the reverse programming result; the process route event 3530 can be executed based on the attachment history information 3620 scheduled by the reverse programming result; and the input decision event 3560 can be executed based on the process target information 3630 scheduled by the reverse programming result. Furthermore, for example, the workpiece screening event 3550 can be executed based on the process target information 3630.

[0405] On the other hand, the instrumental variables in the state variables may undergo state changes. In this case, the event corresponding to the instrumental variable, namely equipment change 3570, can be newly added to the event queue. Therefore, the tool change 3570 event can be inserted between the input decision 3560 and the process processing 3580.

[0406] Furthermore, during the sequential execution of events, if the termination condition that all processes of the workpiece have been completed is met when executing process route 3530, the workpiece can be dispatched at station 3590. For example, the termination condition may include exceeding a preset time in the global clock, an error occurring during event execution, etc., but is not limited to these.

[0407] Figure 13 This is a flowchart illustrating how to generate a production plan using forward programming logic according to one embodiment.

[0408] Based on the data model of the client-side manufacturing production system, a software model and logic set including forward programming logic can be generated or provided (S24).

[0409] Furthermore, a software model and logic set including forward programming logic can be generated or provided based on the software model and logic set including the aforementioned reverse programming logic.

[0410] That is, the software model and logic set may include the forward planning logic disclosed above, and may use at least one of the outputs of the reverse planning logic, namely, factory input plan information, input plan information, process target information and connection history information, as input data.

[0411] In a local computing system, if the library engine set includes forward planning logic, a software model and logic set can be generated based on the client's data pattern.

[0412] In a cloud computing system that generates production plans for clients based on input data including baseline information, this step can either generate a user-customized set of logic or omit this step altogether.

[0413] The generated software model and logic set can be configured to generate production plan data in chronological order based on forward programming logic. Detailed implementations of the forward programming logic are available in [the relevant documentation / documentation]. Figures 9 to 12 It is publicly available in China.

[0414] According to the data pattern, input data is received from the client (S30).

[0415] When using a local system to generate and provide production plans, various conditions can be attached to the received software model and logic set, including forward planning logic, to perform tests on the software model and logic set.

[0416] Based on the received input data, a software model and logic set including forward planning logic are executed to generate and provide production plan information (S57).

[0417] Forward programming logic refers to the method of simulating equipment or workpieces in the actual factory in chronological order from the time a workpiece is first put into the factory until its completion, in order to calculate the production plan and production scheduling.

[0418] The input data includes the results of the reverse programming logic described above. Specifically, the input data includes at least one of the following: factory input plan information, input plan information, process target information, and connection history information.

[0419] According to one embodiment, a production plan can be established chronologically based on baseline information received from a client-side manufacturing system. This chronological approach allows for the simulation of actual production schedules for workpieces or equipment within the factory. This forward planning method enables the generation and provision of efficient production planning information.

[0420] Clients can obtain more efficient production planning results by simulating actual factory conditions in a time-series manner.

[0421] Reference Figure 8This describes an embodiment of an apparatus for providing digital production planning information, the apparatus including forward planning logic.

[0422] One embodiment of the apparatus for providing digital production planning information may include an input unit 310, a storage device 320, a memory 330, a processor 340, an output unit 350, and a user interface 360.

[0423] In the following embodiment, the device for providing digital production planning information can be controlled under user control and management via user interface 360.

[0424] Input unit 310 receives the data pattern of its manufacturing system from the client manufacturing system.

[0425] The storage device 320 stores the data pattern received by the input unit 310, or, if a standardized data pattern has been prepared in advance, stores the standardized data pattern in the storage device 320. The storage device 320 may include volatile memory or non-volatile memory.

[0426] The 330MB of memory can store the library engine set disclosed above.

[0427] The library engine set may include a production planning engine, which is a collection of encapsulated functional block files that generate production plans. The production planning engine may include the forward planning logic-related files disclosed above.

[0428] In addition, the library engine set may further include core library files that implement the data structure for production planning together with the production planning engine, as well as production domain-specific engines that inherit some of the functions of the production planning engine and implement logic for specific production domains.

[0429] In one embodiment, processor 340 can receive a data pattern stored in storage device 320. Furthermore, processor 340 can generate a software model and logic set based on the data pattern and an engine or library stored in memory 330. The generated software model and logic set can then generate production plan data sequentially according to forward programming logic, based on the software model and logic set including reverse programming logic. An embodiment of generating production plan data sequentially according to forward programming logic has been implemented. Figures 9 to 12 It is publicly available in China.

[0430] Processor 340 can test or pre-execute the generated software model and logic set according to the user's request from user interface 360 ​​to obtain production plan data. Furthermore, processor 340 can provide the user with the results of analysis or testing of the software model and logic that generated the production plan data, according to the user's request.

[0431] Processor 340 can receive input data including the manufacturing system reference information from input unit 310 according to a data pattern. Processor 340 can execute a software model and logic set including forward programming logic, and generate production plan data in chronological order. Detailed embodiments for generating production plan data based on forward programming logic have been described in [the relevant documentation]. Figures 9 to 12 It is publicly available in China.

[0432] Output unit 350 provides the client manufacturing system with production plan data generated based on the execution results of a software model and logic set including forward programming logic, so as to manage production or processes in the client system.

[0433] The following will disclose in detail an embodiment of providing production planning data using a software model and logic set generated based on an installed library engine set.

[0434] As previously mentioned, the model development unit 1100 of the local computing system 1000 provides a framework that can be used to develop software models and logic sets capable of generating production plans based on the library engine set 1150.

[0435] In another embodiment, the cloud computing system 2000 may provide multiple standardized software models and logic sets based on the library engine set 2210 for generating production plans.

[0436] In the disclosed embodiments, a software model and logic set capable of generating production plans are used to virtually execute events occurring in the actual factory production system in a time-sequential manner to formulate production plans. This time-sequential scheduling of production plans can be referred to as forward programming.

[0437] The model development unit 1100 can be configured to generate a software model and logic set including forward programming logic based on the library engine set 1150. The forward programming method is to simulate the actual production plan by executing events that may occur in the factory in chronological order, starting from the initial input time of the workpiece, based on at least one of the factory input plan information, input plan information (including quantity and time point), process target information and attachment history information output by the above reverse programming results.

[0438] For example, forward programming can use discrete event simulation to calculate, in chronological order, when and through what process route a workpiece will be processed from the time it is put into the factory until the end of the operation, thereby simulating the production plan.

[0439] In other words, forward planning is based on the process objectives calculated by backward planning. In the actual factory, it is related to workpieces (batch) or equipment. It calculates detailed production plans by executing events such as process routes, workpiece screening, workpiece movement, input decisions, dummy processing, workpiece input, and workpiece output.

[0440] Figure 14 This is a schematic diagram illustrating an event queue that performs forward planning logic according to another embodiment.

[0441] Forward planning calculates the production plan by executing the logic sequentially from the generation of the workpiece and its input into the process until the process is completed.

[0442] As described above, forward programming logic can create and drive a simulation model of an actual factory, and reproduce the dynamics of the actual factory to formulate a production plan through events such as workpiece generation, workpiece input, entry into the queue, workpiece movement, process routing, process handling, equipment changeover, input decision, workpiece screening, and workpiece exit. In one embodiment, the input decision event may include the screening event.

[0443] Furthermore, as mentioned above, at least one of the following outputs from backward planning—factory input plan information, input plan information (including quantity and time points), process target information, and linked historical information—can be used as input values ​​for forward planning to execute forward planning events.

[0444] According to one embodiment, in the event queue, after workpiece generation 3701 and workpiece input 3702, events can be executed in the following order: process route 3703, workpiece movement 3704, workpiece buffer 3705, input decision 3706, and process handling 3708. Alternatively, a subset of events in the event queue can be excluded and executed. In another embodiment, the workpiece exit 3709 event can be executed after the process route 3703 event.

[0445] Optionally, the equipment change 3707 event can be executed after the input decision 3706 event, or the virtual process processing 3710 event can be executed after the workpiece movement 3704 event. The events arranged in the event queue and their order are only one example and are not limited to this.

[0446] Furthermore, input decisions 3706 are managed by an input decision agent, which corresponds to the logical variables among the aforementioned state variables. Moreover, input decisions are one of the most important factors determining production plan performance.

[0447] The input decision 3706 can be executed at different times depending on the type of object being processed. According to one embodiment, it can be executed when the workpiece is in the workpiece waiting state 3705, when the equipment is idle after process 3708, or at a certain time cycle. The input decision 3706 will be explained again below.

[0448] On the other hand, in forward programming logic, within the physical manufacturing environment, the processes of setting movement paths, moving along predetermined process routes, and selecting equipment, all related to equipment or workpieces, may require a large amount of computation due to their high level of detail. This is particularly true during workpiece selection (not shown) or input decision 3706. However, if the equipment is not a bottleneck, the process is fast, or there is a sufficient number of machines in the factory, then a large amount of computation may not be necessary. Therefore, this unnecessary level of detail can be reduced through virtual process handling.

[0449] Virtual process processing 3710 refers to an event that triggers the process route 3703 for the next process after a certain period of time following workpiece movement in forward programming logic. In other words, virtual process processing 3710 is a way to shorten execution time by omitting complex calculations such as workpiece screening (not shown) or input decision 3706. In this embodiment, virtual process processing 3710 is described as being performed after workpiece movement, but it can also be performed after a workpiece waiting event.

[0450] In the case of virtual process processing 3710, the target process (step) can be set as virtual process processing 3710 in the input value at the workpiece generation time point 3701 or the workpiece input time point 3702. Therefore, when the target process or equipment is set as virtual process processing 3710, it directly enters the process route 3703 without going through workpiece screening (not shown) or input decision 3706.

[0451] Furthermore, even if the virtual process processing 3710 is set in the input value, it can receive the production capacity of the process or equipment as a parameter to ensure that its execution does not exceed that value.

[0452] Figure 15 This is a schematic diagram illustrating the input decision execution steps in forward programming logic according to one embodiment.

[0453] In the following text, to facilitate the illustration of an embodiment of the forward planning logic within the library engine set, an embodiment of executing input decisions through an input decision agent, one of the system dynamics, is disclosed.

[0454] As mentioned above, work assignment is a factor affecting the performance of production planning in forward programming logic. The execution time of the work assignment event may differ depending on whether the execution target is a workpiece or a piece of equipment.

[0455] At the point in time to execute the input decision, the object of the input decision can first be determined (S310). As mentioned above, the input decision event can include a screening event. That is, before deciding on the method of input decision, screening to determine the object of the input decision can be performed.

[0456] For example, a piece of equipment in an idle state can be the object of an input decision to select one from n candidate workpieces; a workpiece that has entered the queue after completing the previous process can be the object of an input decision to select one from m candidate equipments. Furthermore, for example, all possible pairs of workpieces and equipment that may occur within the entire factory at regular intervals can be the object of an input decision.

[0457] Next, the method of input decision can be determined (S320). In this disclosure, the input decision method may include a weighted sum method, a weight sort method, and a combination of weighted sum and weight sort. The input decision method may be determined based on the type or quantity of workpieces or equipment in the factory, or by user settings.

[0458] Here, the weighted sum method involves multiplying each dispatching feature and its corresponding weight for each candidate input object (multiple workpieces or multiple devices), summing the results, and selecting the candidate object (workpiece or device) with the largest weighted sum. Furthermore, the weight ranking method involves evaluating the candidate input objects (multiple workpieces or multiple devices) starting with the features with the highest priority to select a candidate (workpiece or device).

[0459] If the input decision method is determined to be a weighted sum method, then the feature types and feature weights of the input candidate can be identified (S330). Here, the input decision feature corresponds to the numerical index of the features (or characteristics) of the possible alternatives in the input decision, and the feature weight corresponds to the weight of each feature. Furthermore, the feature type and weight values ​​can be changed during the weighted sum input decision process. Next, the weighted sum for the candidates can be evaluated (S340). Specifically, for each candidate, each feature value can be multiplied by its corresponding weight and summed to calculate the weighted sum.

[0460] Here, weighted evaluation can include linear weighted sums or nonlinear weighted sums utilizing nonlinear structures such as neural networks. Using nonlinear weighted sums with nonlinear structures, a score for each artifact can be calculated using at least one layer of a neural network employing a nonlinear activation function, and a decision can be made based on that score. For example, the artifact with the highest score can be selected, or a selection can be made based on that score using a SoftMax function.

[0461] Finally, a final candidate can be selected from multiple candidate objects based on a weighted sum (S350). In one embodiment, a weighted sum can be calculated for each of the multiple candidate objects, and the candidate object with the highest weighted sum can be selected. In another embodiment, a weighted sum can be calculated for each of the multiple candidate objects, and the candidate object with the lowest weighted sum can be selected. The decision regarding the weighting method will be explained again below.

[0462] On the other hand, if the input decision method is determined to be weighted sorting, the types and priorities of the input decision feature values ​​can be identified (S360). Here, priority corresponds to the order in which feature values ​​are compared based on the characteristics of the factory, equipment, or workpiece. Next, the feature value with the highest priority among the multiple feature value types can be determined (S365). In this embodiment, the feature value with the highest priority is shown, but it can also be set to determine the feature value with the lowest priority.

[0463] Next, the scores of the feature values ​​for that priority of the candidate can be evaluated (S370). For example, the scores of the feature values ​​with the first priority of multiple candidates can be compared. Then, it is determined whether there are multiple candidates with the same highest score on that feature value (S375). For example, in the case of 5 candidates, it can be determined whether there are at least 2 candidates with the same high score. Here, high score refers to the highest score among the multiple candidate scores.

[0464] If no other candidate has the same high score for the same feature value, the candidate with the highest score for that feature value can be selected as the final candidate (S380). In this embodiment, the example is to select the candidate with the highest score as the final candidate, but it can also be set to select the candidate with the lowest score as the final candidate.

[0465] In the presence of candidates with the same high score on the feature value, the feature value with the next priority can be determined (S385). Specifically, candidates that do not have the same highest score are excluded, and the feature value with the next priority is determined only for candidates with the same highest score. For example, if two out of five candidates have the same high score on the feature value with the first priority, the feature value with the second priority is determined only for these two candidates.

[0466] Next, the scores of the feature values ​​related to the priority of the candidates are evaluated. If no candidate has the same high score, proceed to step S380. Otherwise, if candidates have the same high score, return to step S385.

[0467] In other words, the weighted ranking method is a decision-making approach that sorts multiple candidates based on their feature values ​​until no candidates have the same score and only one candidate remains. This weighted ranking method can include decision-making methods with non-linear structures such as decision trees. For example, non-linear structures include decision trees, but are not limited to them.

[0468] On the other hand, although not illustrated in this embodiment, the weighted sum method and the weighted ranking method can be combined in the input decision-making process. For example, from the 10 items that are the input decision targets, the 5 with the highest weighted sum can be selected, and then, for these 5 selected items, a final candidate can be selected by weighted ranking. Furthermore, for example, from the 10 items that are the input decision targets, they can first be ranked by weight, and if there are still 5 items with the same priority score, then a final candidate can be selected by weighted sum for these 5 items. To avoid wasting computational resources, the features used in weighted ranking and the features used in weighted sum can correspond to different features.

[0469] Figure 16 This is a schematic diagram illustrating the dispatching of tasks according to one embodiment of forward planning logic.

[0470] Specifically, the diagram illustrates the input decision-making process using a weighted sum method, assuming one machine corresponds to three workpieces.

[0471] First, in this embodiment, the object of the input decision is workpiece 3720, which may include multiple candidate Lot 1, Lot 2, and Lot 3. Next, the input decision features and weights can be determined. In this embodiment, the input decision features 3725 are determined to be FIFO, SETUP, DELAY, and PROCESS TIME, and each workpiece can have different feature values ​​3730 according to its features.

[0472] The FIFO (First-In, First-Out) characteristic indicates that workpieces are processed preferentially according to their entry order; the SETUP characteristic indicates that a workpiece causes changes to equipment settings; the delay characteristic indicates a delay in workpiece processing; and the processing time characteristic is related to the time the workpiece takes to complete. This embodiment describes four characteristics, but the types of characteristics are not limited to these. Furthermore, input decision characteristics can include a wide variety of characteristics that can be quantified within the factory.

[0473] For example, in the case of candidate 1 (Lot 1), the FIFO characteristic value is 0.5, the set characteristic value is 1.0, the delay characteristic value is 0.1, and the processing time characteristic value is 0.2; in the case of candidate 2 (Lot 2), the FIFO characteristic value is 0.4, the set characteristic value is 0.5, the delay characteristic value is 0.3, and the processing time characteristic value is 0.2; in the case of candidate 3 (Lot 3), the FIFO characteristic value is 0.3, the set characteristic value is 1.0, the delay characteristic value is 1.0, and the processing time characteristic value is 0.4.

[0474] In one embodiment, the weight 3735 used for the input decision can be determined based on the device on which the input decision is based. In this embodiment, based on the device, the weight of the FIFO feature value is 50, the weight of the setting feature value is 200, the weight of the delay feature value is 300, and the weight of the processing time feature value is 100.

[0475] Next, the sum of the products of the eigenvalues ​​and corresponding weights of each candidate can be calculated, which is the weighted sum. In this embodiment, the weighted sum of candidate 1 (Lot 1) is 275, the weighted sum of candidate 2 (Lot 2) is 230, and the weighted sum of candidate 3 (Lot 3) is 555. Therefore, the candidate with the highest weighted sum, namely candidate 3 (Lot 3), is selected for the decision-making process in this embodiment.

[0476] In this embodiment, it is assumed that one machine has multiple workpieces. However, conversely, if one workpiece has multiple machines, the input decision can also be made using the same weighted sum method. The advantage of the weighted sum method is that, since the decision considers all characteristic values, a high-performance production plan can be calculated.

[0477] Figure 17 This is a schematic diagram illustrating the dispatching of tasks according to another embodiment of forward planning logic.

[0478] Specifically, the diagram illustrates the input decision-making process for a weighted sorting method, assuming one machine corresponds to three workpieces.

[0479] First, in this embodiment, the object of the decision-making process is workpiece 3740, which may include multiple candidates (Lot 1, Lot 2, Lot 3). Next, the decision feature values ​​and priorities can be determined. In this embodiment, the types 3725 of the decision feature values ​​are determined as FIFO, SETUP, DELAY, and PROCESS TIME, and the priorities 3750 are determined according to the importance of each feature value type. In this embodiment, the priority of the SETUP feature value is first, the priority of the DELAY feature value is second, the priority of the PROCESS TIME feature value is third, and the priority of the FIFO feature value is fourth.

[0480] Next, the candidates' scores can be evaluated in descending order of priority. In this embodiment, during the first round of evaluation (3755) of the highest priority SETUP feature value, the scores of candidate 1 (Lot 1) and candidate 2 (Lot 2) are evaluated the same, except for candidate 3 (Lot 3). At this time, during the second round of evaluation (3760) of the second priority DELAY feature value, the score of candidate 1 (Lot 1) is evaluated as lower than that of candidate 2 (Lot 2). Therefore, the decision-making object in this embodiment is the candidate that remains after the weighted ranking, namely candidate 2 (Lot 2).

[0481] Although not illustrated in this embodiment, if the scores of Candidate 1 (Lot 1) and Candidate 2 (Lot 2) are the same in the second round of evaluation 3760, the PROCESS TIME feature value, which has the third priority, can be further evaluated. Furthermore, although not illustrated in this embodiment, if the SETUP feature values ​​of all candidates are different in the first round of evaluation 3755, the candidate with the highest score can be ultimately selected as the decision-making target in the first round of evaluation.

[0482] In this embodiment, it is assumed that one device has multiple workpieces. However, conversely, if one workpiece has multiple devices, the same weighted ranking method can be used to make input decisions. The advantage of the weighted ranking method is that the number of candidates gradually decreases as the decision-making process proceeds, and it does not require calculating all feature values, thus reducing the computational load. Furthermore, due to the reduced computational load, rapid decisions can be made. In complex factories where the system is too complex to be simulated quickly, decisions can be made rapidly, thereby efficiently calculating production plans.

[0483] Figure 18 This is a flowchart illustrating how to generate a production plan using forward programming logic according to one embodiment.

[0484] It can generate or provide software models and logic sets that include input decision-making or virtual process processing positive planning logic (S25).

[0485] Furthermore, a software model and logic set including forward programming logic can be generated or provided based on the software model and logic set including the aforementioned reverse programming logic.

[0486] That is, the software model and logic set may include the forward planning logic disclosed above, and may use the output of the reverse planning logic, namely at least one of the following: factory input plan information, input plan information, process target information, and connection history information, as input data.

[0487] As mentioned above, forward programming logic can include input decisions or virtual process handling events. Input decisions can be made using methods such as weighted sums and weight ranking.

[0488] On the other hand, input decision-making can also be applied to reverse planning logic. According to one embodiment, it can be applied in the demand information preprocessing step and / or facility allocation step of the reverse planning logic. Regarding the method of input decision-making, it can include the weighted sum method, the weight ranking method, and a hybrid method of weighted sum and weight ranking. For example, in the demand information preprocessing step, the object of input decision-making can be an input decision object selected from n production performances, and a production performance can be an input decision object selected from n demand information; a pair of demand information and production performances can be the object of input decision-making. Furthermore, for example, in the facility allocation step, the object of input decision-making can be an input decision object selected from n demand informations for a site, and demand information can be an input decision object selected from n facilities; a pair of facilities and demand information can be the object of input decision-making.

[0489] In a local computing system, if the library engine set includes forward planning logic, a software model and logic set can be generated based on the client's data pattern.

[0490] In cloud computing systems that provide clients with input data, including baseline information, to generate production plans, this step can generate a user-customized set of logic or be omitted.

[0491] The generated software model and logic set can be configured to generate production plan data in chronological order based on forward programming logic. Detailed implementations of the forward programming logic are available in [the relevant documentation / documentation]. Figures 13 to 17 It is publicly available in China.

[0492] According to the data pattern, input data is received from the client (S30).

[0493] When using a local system to generate and provide production plans, various conditions can be added to the received software model and logic set, including forward planning logic, to perform tests on the software model and logic set.

[0494] Based on the received input data, the software model and logic set, including forward planning logic, are executed to generate production plan information (S57).

[0495] Forward programming logic refers to simulating the production process of equipment or workpieces in the actual factory in chronological order, from the time a workpiece is first put into the factory to the time of its completion, in order to calculate the production plan and production scheduling.

[0496] The input data includes the results of the reverse programming logic described above. Specifically, the input data includes at least one of the following: factory input plan information, input plan information, process target information, and connection history information.

[0497] According to one embodiment, a production plan can be established chronologically based on baseline information received from a client-side manufacturing system. This chronological approach allows for the simulation of the actual production process of workpieces or equipment within the factory. Using this forward planning method, efficient production planning information can be generated and provided.

[0498] Clients can execute production based on production plans generated in chronological order, thereby improving production efficiency.

[0499] Reference Figure 8 An embodiment of a device that includes forward planning logic and provides digital production planning information is described below.

[0500] One embodiment of the apparatus for providing digital production planning information may include an input unit 310, a storage device 320, a memory 330, a processor 340, an output unit 350, and a user interface 360.

[0501] The following is an embodiment of the device for providing digital production planning information, which can operate under user control and management via a user interface 360.

[0502] Input unit 310 receives the data pattern of its manufacturing system from the client manufacturing system.

[0503] The storage device 320 stores the data pattern received by the input unit 310, or, if a standardized data pattern has been prepared in advance, stores the standardized data pattern in the storage device 320. The storage device 320 may include volatile memory or non-volatile memory.

[0504] The 330MB of memory can store the library engine set disclosed above.

[0505] The library engine set may include a production planning engine, which is a collection of encapsulated functional module files that generate production plans. The production planning engine may include files regarding the forward planning logic disclosed above.

[0506] In addition, the library engine set may further include core library files that implement the data structure for production planning together with the production planning engine, as well as production domain-specific engines that inherit some of the functions of the production planning engine and implement logic for specific production domains.

[0507] In one embodiment, processor 340 can receive a data pattern stored in storage device 320. Furthermore, processor 340 can generate a software model and logic set based on the data pattern and an engine or library stored in memory 330. The generated software model and logic set can then generate production plan data sequentially based on forward planning logic, building upon a software model and logic set including reverse planning logic. As described above, forward planning logic can include input decisions or virtual process handling events. An embodiment of generating production plan data sequentially using forward planning logic has been implemented. Figures 14 to 17 It is publicly available in China.

[0508] Processor 340 can test or pre-execute the generated software model and logic set according to the user's request via user interface 360 ​​to obtain production plan data. Furthermore, processor 340 can provide the user with the results of analysis or testing of the software model and logic that generated the production plan data through user interface 360, according to the user's request.

[0509] Processor 340 can receive input data including the manufacturing system reference information from input unit 310 according to a data pattern. Processor 340 can execute a software model and logic set including forward programming logic, and generate production plan data in chronological order. Detailed embodiments for generating production plan data based on forward programming logic have been described in [the relevant documentation]. Figures 14 to 17 It is publicly available in China.

[0510] Output unit 350 can provide production plan data generated based on the execution results of the software model and logic set, including forward programming logic, to the client manufacturing system, enabling the client system to manage production or processes.

[0511] Figure 19 This is a schematic diagram illustrating the generation of a software model and logic set based on a data schema and library engine set, according to one embodiment.

[0512] In the illustrated embodiment, the model development unit 1100 of the local computing system 1000 provides a framework for developing software models and logic sets capable of generating production plans based on data patterns and library engine sets 1150.

[0513] In one embodiment, the model development unit 1100 may include a model generation module 401, a data definition module 402, a main module 403, and an execution module 404.

[0514] The model generation module 401 can generate a software model for the client manufacturing system. In one embodiment, the software model can be edited by modifying the software model parameters related to the client manufacturing system. The software model may include at least one of the following: the client manufacturing system's data schema, data source, query, and global variables.

[0515] Here, a data schema can represent the data structures and formats required to execute a software model or logic. In one embodiment, a data schema may include an input data schema and an output data schema. In one embodiment, the input data schema can be received from a client manufacturing system. Furthermore, the output data schema can be determined based on the input data schema or specified by the developer.

[0516] In addition, a data source can be used to establish a database connection to load data. Furthermore, a data source can be used to define input and output data and generate data actions. A query is an operation that requests data from a data source; at least one query can constitute a query management unit, i.e., a data action. Global variables can include variables that define options and settings for logical execution used during execution. For example, global variables can include logical execution start time, logical execution end time, model file name, etc., but are not limited to these and can include various variables.

[0517] In one embodiment, the model generation module 401 can generate persistent configuration information about input data and output data. Here, the persistent configuration information may include: input persist configuration information for loading input data corresponding to the data pattern into memory, and output persist configuration information for storing output data corresponding to the data pattern in memory.

[0518] The data definition module 402 can define the data classes used in the main module 403 and execution module 404 when performing logical processing. In one embodiment, the data definition module 402 can redefine the data classes provided by the library engine set 1150. In one embodiment, the data definition module 402 can define data storage settings for input data storage and output data storage.

[0519] In one embodiment, input data storage and output data storage refer to a collection and storage area used to store input data, intermediate data, and output data, wherein the collection is defined according to the data class. Here, a collection refers to table-structured data defined according to the data class. In one embodiment, the data storage can be referenced when executing the software model and logical set.

[0520] The main module 403 can control the execution of the execution module 404. In one embodiment, the main module 403 can set attributes and execution options related to the software model. In one embodiment, the main module 403 can control the overall execution flow for generating production plan data. For example, the main module 403 can control the loading of initial input data and the storage of output data after the execution module 404.

[0521] Execution module 404 can generate and execute at least one set of logic for the client manufacturing system based on the data model and library engine set 1150. This set of logic includes pegging logic or simulation logic. Execution module 404 may include at least one of a pegging module for generating pegging logic and a simulation module for generating simulation logic. Here, pegging logic may include logic for pegging work-in-process based on demand information according to reverse programming logic, and generating input and completion targets for each process for the remaining quantity. Furthermore, simulation logic may include logic for executing events that may occur in the factory in chronological order, starting from the initial input time of the workpiece, based on the results of reverse programming logic and forward programming logic, to simulate the actual production process. Please refer to the above description for details.

[0522] Figure 20 This is a schematic diagram illustrating, according to one embodiment, the generation of a logic set including hooking logic and simulation logic.

[0523] In the illustrated embodiment, a logic set including hooking logic and simulation logic can be generated through the core layer 405, control layer 406, and developer interaction layer 407 of the library engine set 1150.

[0524] The core layer 405 may include functional units of reverse planning logic corresponding to the hooking logic and forward planning logic corresponding to the simulation logic, as well as the relationships and interactions between these functional units. For example, in the case of simulation logic, the functional units may include factories, workpiece movement, input decisions, and equipment, but are not limited to these.

[0525] Control layer 406 may include events and event internal functions that control the functional units included in core layer 405. In one embodiment, each functional unit may constitute at least one event and event internal function. For example, it may include an event that evaluates characteristic values ​​of alternatives for input decision-making.

[0526] The developer interaction layer 407 may include at least one logic function code corresponding to an event and its internal function. Here, the logic function code may include function code for implementing the hooking logic and simulation logic. In one embodiment, the hooking logic and simulation logic can be generated by binding the events and their internal functions of the control layer 406 to the logic function code and calling the corresponding logic function code. In one embodiment, the logic function code of the developer interaction layer 407 may be pre-implemented and stored.

[0527] At this point, the binding code for a logical point corresponding to an event and its internal functions can have a 1:N relationship with the logical function codes. That is, a logical point can have multiple logical function codes. For example, in a logical point that evaluates the characteristic values ​​of alternative solutions used for input decisions, the same number of logical function codes as the number of evaluation conditions can be set. Thus, when binding code corresponds to multiple logical function codes, the execution order between the logical function codes can be specified.

[0528] In one embodiment, the logic development layer set, including the core layer 405, the control layer 406, and the developer interaction layer 407, can be constructed for attach logic and simulation logic, respectively. In one embodiment, the process of generating a logic set based on the logic development layer set can be controlled by the main module 403.

[0529] In one embodiment, the logic set managed by the main module 403 is not limited to the hook logic and simulation logic, and other logic can be added according to functional requirements.

[0530] Figure 21 This is a schematic diagram illustrating the generation of a software model and logic set in a method for providing digital production planning information according to one embodiment.

[0531] Determine a domain-specific engine for the client manufacturing system (S411). In one embodiment, since each client belongs to a different manufacturing domain, and each domain has unique elements, it is possible to model the client manufacturing system for a specific manufacturing domain to determine the corresponding domain-specific engine. In one embodiment, an applicable engine can be selected from pre-generated domain-specific engines based on the client manufacturing system.

[0532] In one embodiment, the production domain-specific engine of the library engine set 1150 is a dataset that inherits some functions from the production planning engine and is used to implement specific production domain logic. It can be defined differently depending on the industry or manufacturing production system.

[0533] In one embodiment, a production-domain-specific engine for a specific production domain can inherit logic from a general domain and further include logic related to that specific production domain. For example, a specific production domain may include the LCD field. In this case, the production-domain-specific engine corresponding to the LCD field can inherit the reverse programming logic and forward programming logic of the general domain as is, and further include logic related to the TFT (Thin Film Transistor), CF (Color Filter), and LC (Liquid Crystal) processes related to the LCD field.

[0534] A software model is generated for the client manufacturing system (S412). In one embodiment, a software model including at least one of a data schema, a data source, a query, and global variables can be generated for the client manufacturing system. In one embodiment, the software model can be edited via a user interface based on user input. Please refer to the above description for details.

[0535] Persistent configuration information is generated for the input and output data (S413). In one embodiment, the persistent configuration information may include input persistent configuration information and output persistent configuration information. In this case, the input persistent configuration information may represent the process and method of loading input data into memory. For example, the input persistent configuration information may include the query execution order in the database, the number of threads executing the query in the database, and the number of retries when the database network connection is disconnected, but is not limited to these.

[0536] Furthermore, output persistence configuration information can represent the program and method for storing output data in memory to a file or database. For example, output persistence configuration information may include settings for whether to store data and whether to record the data storage time, but is not limited to these.

[0537] In one embodiment, persistent configuration information can be generated based on user input, using at least one of data schema, data source, query, and global variables.

[0538] The input data loading operation and data structure are determined (S414). In one embodiment, the input data loading operation may refer to the operation of reading input data from the database. For example, the data loading operation may include an event executed when each row of data is read and an event executed after all data has been read.

[0539] In one embodiment, the data structures used in the internal logic of the model can be preprocessed during the data reading process. For example, if the Product / Process / Step tables each exist, logic can be implemented to connect Product, Process, and Step to each other in a dependent manner.

[0540] In one embodiment, the data structure may include data structures automatically generated and stored according to a structure defined in a data schema, as well as data structures generated and stored from user input. In one embodiment, items related to input values ​​and continuously used within the model's internal logic may be stored in the input data memory space, while items related to output values ​​and used as intermediate or final outputs within the model's internal logic may be stored in the output data memory space. Here, the data memory space may include virtual memory space that temporarily exists in memory during program execution.

[0541] Generate the attachment logic and simulation logic (S415). In one embodiment, logic function code can be written for the functional units related to reverse programming logic and forward programming logic in the library engine set, for their events and event internal functions, to generate the attachment logic and simulation logic. Please refer to the above content for a detailed explanation.

[0542] In one embodiment, when user click input for implementing a logic function is obtained through the user interface, logic function code for that function and binding code for connecting that function to the engine set can be automatically generated.

[0543] In one embodiment, the implemented portion of the function to be implemented can be stored in a specific file format (such as XML), so that even if the model development unit 1100 executes it again, the relevant content can still be confirmed and edited.

[0544] Obtain the software model file and logic file (S416). In one embodiment, obtain the software model file and logic file, which include the hook logic and simulation logic. In another embodiment, the model file and logic file can be obtained through a save and build operation.

[0545] In one embodiment, steps S414 to S416 can be performed in any order, or simultaneously or individually. Furthermore, if the relevant information has been predetermined, at least one step can be omitted.

[0546] Figure 22 This is a flowchart illustrating a method for generating a production plan by providing digital production planning information according to one embodiment.

[0547] Based on at least one of the data patterns and library engine sets of the client-side manufacturing system, a software model and logic set including the attachment logic or simulation logic of the client-side manufacturing system are generated or provided (S417). In one embodiment, the software model can be generated based on at least one of the data patterns, the data source of the input data, the query corresponding to the data patterns, and global variables (arguments).

[0548] In one embodiment, events and their internal functions corresponding to at least one functional unit in the library engine set are constructed, and at least one of the hook logic and simulation logic is generated by binding logical function code corresponding to at least one of the events and their internal functions.

[0549] In one embodiment, the library engine set may include at least one of reverse planning logic using a time-inverse calculation method and forward planning logic using a time-sequential method. For more information, please refer to... Figures 19 to 21 The content described in the text.

[0550] According to the data pattern, input data including reference information is received from the client (S418). In one embodiment, the input data may include at least one of product information, production process information, operation information, equipment information, movement time information, in-plant workpiece information, and quantity produced information. In another embodiment, the input data may include the result of the reverse programming logic described above. For more information, please refer to... Figures 19 to 21 The content described in the text.

[0551] Based on the received input data, the software model and logic set are executed to provide production planning data (S419). In one embodiment, when the software model and logic set includes forward planning logic, production planning information can be generated in chronological order using process target information and factory input plan information obtained from backward planning logic. For further details, please refer to... Figures 19 to 21 The content described in the text.

[0552] Reference Figure 8 An embodiment of an apparatus for providing digital production planning information based on at least one software model and logic set including hooking logic and simulation logic is described below.

[0553] One embodiment of the apparatus for providing digital production planning information may include an input unit 310, a storage device 320, a memory 330, a processor 340, an output unit 350, and a user interface 360.

[0554] In the following embodiment, the device for providing digital production planning information can be controlled according to user control and management based on the user interface 360.

[0555] Input unit 310 receives the data pattern of its manufacturing system from the client manufacturing system.

[0556] The storage device 320 stores the data pattern received by the input unit 310, or, if a standardized data pattern has been prepared in advance, stores the standardized data pattern in the storage device 320. The storage device 320 may include volatile memory or non-volatile memory.

[0557] Memory 330 can store the library engine set disclosed above. The library engine set may include a production planning engine, which is a collection of encapsulated functional module files that generate production plans. The production planning engine may include at least one file related to the reverse planning logic and forward planning logic disclosed above.

[0558] In addition, the library engine set may further include core library files that implement the data structure for production planning together with the production planning engine, as well as production domain-specific engines that inherit some of the functions of the production planning engine and implement logic for specific production domains.

[0559] In one embodiment, processor 340 may receive a data pattern stored in storage device 320 and generate a software model and logic set based on the data pattern and a library engine set stored in memory 330. Processor 340 may also generate or provide a software model and logic set, including hook logic or simulation logic, based on the data pattern of the client manufacturing system and at least one of the library engine sets. Please refer to the above description for details.

[0560] Processor 340 can test or pre-execute the generated software model and logic set according to the user's request via user interface 360 ​​to obtain production plan data. Furthermore, processor 340 can provide the user with the results of analysis or testing of the software model and logic that generated the production plan data through user interface 360, according to the user's request.

[0561] Processor 340 can receive input data, including the manufacturing system reference information, from input unit 310 according to a data pattern. Based on the input data, processor 340 can execute a software model and logic set, including hooking logic and simulation logic, to generate production plan data. Please refer to the above description for details.

[0562] Output unit 350 provides the client manufacturing system with production plan data generated based on the execution results of a software model including forward programming logic and logic set.

[0563] The following will disclose in detail an embodiment of providing production planning data using a software model and logic set generated based on an installed library engine set.

[0564] As previously mentioned, the model development unit 1100 of the local computing system 1000 provides a framework that can be used to develop software models and logic sets capable of generating production plans based on the library engine set 1150.

[0565] In another embodiment, the cloud computing system 2000 may provide multiple standardized software models and logic sets based on the library engine set 2210, which can generate production plans.

[0566] In one embodiment, the software model may include at least one of the following: data schema, data source, query, and global variables related to the client-side manufacturing system. Furthermore, the logic set may include not only the connection logic or simulation logic of the client-side manufacturing system, but also other logic defining the manufacturing system.

[0567] In the disclosed embodiments, the process of generating the jobs required to execute the software model and logic set by the system operation unit 110, and setting its execution cycle and dependencies will be described.

[0568] As described above, the system operation unit 110 can transmit the software model and logic set generated by the model development unit 1100 to the client, and enable the client manufacturing production system 100 to generate production plan data to carry out production operations.

[0569] The system operation unit 110 can manage triggers (execution conditions) used for operating projects or operations according to the project management or work plan of the client manufacturing production system 100, and set and adjust their monitoring methods and performance parameters.

[0570] For example, the system operations unit 110 may provide a server management unit 1200, which is a user interface for managing triggers, monitoring, and performance changes, thereby enabling the generation and management of jobs through the system operations unit 110. That is, job generation and management can be performed through the system operations unit 110 or the server management unit.

[0571] For example, system operation unit 110 may include a user interface (UI) for workpiece generation and management, and a backend system for workpiece generation and management.

[0572] Figure 23 This is a schematic diagram illustrating the generation of operational tasks based on a software model and a set of logic, according to one embodiment.

[0573] The system operation unit 110 can generate operation jobs based on the uploaded software model and logic set, and set the conditions for executing the operation jobs.

[0574] As described above, the model development unit 1100 can acquire (develop) a software model and logic set including hooking logic and simulation logic. For example, the software model may include at least one of data schema, data source, query, and global variables.

[0575] Furthermore, the software model and logic set acquired in the model development unit 1100 can be uploaded to the system operation unit 110. As described above, the system operation unit 110 includes a user interface provided to the user, allowing the user to confirm and control the operation of the system operation unit 110.

[0576] The system operation unit 110 may include a service unit 1260 and a historical management storage unit 1270.

[0577] Service unit 1260 may include license service unit 1205, job service unit 1210, deployment management service unit 1215, outfile service unit 1220, job scheduler service unit 1230, etc.

[0578] The license service unit 1205 is the part that manages whether the services allocated to each user are legally purchased, for example, by checking whether the licenses purchased by the user have expired.

[0579] The job service unit 1210 is used to generate operational jobs (tasks) and their execution cycles, etc. The deployment management service unit 1215 is the part that uploads the files received from the model development unit 1100 to the historical management storage unit 1270, and can be set to manage the version used based on user input.

[0580] The output file service unit 1220 is used to support downloading the results generated by the operation job from the outside, and the job scheduler service unit 1230 corresponds to the part of the operation job edited in the job service unit 1210 that is executed according to the execution conditions.

[0581] Furthermore, the historical management storage unit 1270 can temporarily store the software models and logical sets required for generating and setting up operational tasks in the system operation unit 110, and store files related to operational tasks. In addition, various setting values ​​used in the system operation unit 110 (data sources for each project, operational task lists, execution cycles, dependency conditions, etc.) can be stored in the historical management storage unit 1270 or a separate storage area.

[0582] For example, the deployment management service provided in deployment management service unit 1215 can store files in historical management storage unit 1270 according to the project path to which the deployed object belongs when a deployment (upload) occurs. At this time, when storing files, deployment management service unit 1215 can provide historical management of software models and logical sets according to the deployment time point.

[0583] Here, historical management involves separately managing the versions used in current operational tasks and the versions used in past operational tasks, so that either past or current versions can be used when needed. For example, suppose the software model and logic set for a weekly project were uploaded and the operational task was executed on January 1st. Then, on February 2nd, logic for a new product was added due to a customer request, the new software model and logic set were uploaded, and the operational task was executed. In this case, the version from February 2nd could correspond to the logic requiring additional computation. If, on March 3rd, the production plan for the new product is cancelled due to customer circumstances, and it is decided to use the logic from January 1st instead of the logic from February 2nd requiring additional computation, the deployment management service unit 1215 can be changed to the deployment version from January 1st and executed.

[0584] Furthermore, operational jobs can be generated through the job service unit 1210 of the system operation unit 110. At this time, the operational job corresponds to the job required to execute the software model and logic set. Operational jobs (job type) can include three types: sending emails, executing programs, and executing models. In addition, various execution jobs can be added according to user or system settings, such as jobs for experimental platform execution and jobs for dynamic operations. Furthermore, operational jobs correspond to the job units executed by the job scheduler service unit 1230.

[0585] The email sending job type includes jobs that send emails during the execution of software models and logic sets. For example, sender, recipient, subject, body, and attachments can be specified as global variables, and the email server can be set. Here, global variables correspond to variables that define logic execution options and settings. Furthermore, when the configured email sending job is executed, emails can be sent according to preset rules. The email sending job type can be set to send emails in cases such as the failure of a specific operational job executed by system operations unit 110 for management purposes.

[0586] Program execution job types are used to execute programs or scripts and can be associated with the execution of software models and logic sets. For example, in the event of operational failure of a software model or logic set, a verification script can be executed.

[0587] The model execution task type is used to execute the software model developed through the model development unit 1100. This model execution task type includes basic global variables used to set the model's operating mode. According to one embodiment, software model global variables stored in the history management storage unit 1270 can be used as basic global variables for the model execution task type.

[0588] Furthermore, the job service unit 1210 can set execution conditions (triggers) for operational jobs. Here, execution conditions correspond to the execution cycle, dependencies between operational jobs, etc. That is, an operational job refers to a work unit to be executed, and execution conditions refer to detailed conditions such as the execution cycle and dependencies of the operational job. At least one execution condition can be generated for an operational job, and at least one second execution condition can be generated for a first execution condition. The set execution conditions can be stored in the system operation unit.

[0589] Figure 24 This is a schematic diagram illustrating the execution of operational tasks based on a software model and a set of logic, according to one embodiment.

[0590] The model execution unit 130 can execute operational tasks according to the execution instructions of the job scheduler service unit 1230.

[0591] For example, when the execution conditions set for the operational job are met, the job scheduler service unit 1230 starts the model execution unit 130 and can pass the software model and logic set as parameters. At this time, the software model and logic set may include connection information and data table mapping information of the data extracted from the database 150.

[0592] At this time, the model execution unit 130 can receive actual input data from the client database 150 based on the software model and logic set. That is, the model execution unit 130 can perform queries according to the parameters to obtain data included in the database 150 of the client system.

[0593] According to one embodiment, when the model execution unit 130 executes the model according to the logic set, it can generate an output file 1286, which belongs to the output file 1280. In one embodiment, the format of the output file 1286 can be determined according to the settings of the software model (e.g., parameters added when creating a job by the job service unit 1210), and may include a compressed file format, etc.

[0594] At this point, output file 1286 may include production plan data. Here, the production plan data corresponds to the production plan obtained after executing the input data received from the client database within the developed software model and logic set. Additionally, log file 1283 regarding the results of operational job execution may also be generated. Log file 1283 may include information such as the operational job execution time, execution method, and whether the execution was successful or failed.

[0595] On the other hand, when generating experimental platform jobs as operational jobs, experimental platform executors can be added to execute one or more model execution units 130 in parallel.

[0596] The generated output file 1286 and log file 1283 can be uploaded to the database 150 of the client manufacturing system 100. During upload, the file can be uploaded as a compressed model file 1286, or it can be uploaded directly without compressing the contents of the compressed model file 1286.

[0597] On the other hand, the stored output file 1286 and log file 1283 can be provided with results through the query interface included in the manufacturing production system 100 on the client or the external file service unit 1220, so that the model analysis unit 1300 can query them.

[0598] Figure 25 This is a schematic diagram illustrating the setting of operational tasks in a system operation unit according to one embodiment.

[0599] The operational jobs generated by the job service unit 1210 can have execution conditions set for them. This corresponds to setting conditions for operational jobs related to the execution of developed software models and logic sets.

[0600] The execution conditions set by the execution condition service unit 1225 can be stored in the system operation unit 110.

[0601] Furthermore, at least one execution condition can be set for an operational task. For example, execution conditions can include periodic conditions, dependency conditions, etc. Additionally, periodic or dependency relationships can be established between multiple execution conditions. For example, at least one second execution condition can be set for a first execution condition. Alternatively, it can be configured not to configure a second execution condition for the first execution condition, and the task can terminate after the first execution condition completes.

[0602] Furthermore, even if execution conditions are set, whether or not those conditions are actually executed can be configured via parameters. In one embodiment, a procedure may be included that not only sets the execution conditions but also sets their activation / deactivation states. For example, even if a periodic condition 520 or a dependency condition 530 is set for the first operational job 510, execution can be performed after determining the activation / deactivation states of each execution condition.

[0603] In one embodiment, two periodic conditions 520 can be set for the first operation 510. The first periodic condition 521 corresponds to the conditions of the weekly operation model. The second periodic condition 522 corresponds to the conditions of the weekly test model. The periodic conditions can also be generated in various ways by the system or the user.

[0604] In addition, dependency conditions 530 can be generated for at least a portion of the periodic conditions 520. The first dependency condition 531 corresponds to the condition for successfully sending an email, the second dependency condition 532 corresponds to the condition for performing validation, and the third dependency condition 533 corresponds to the condition for sending a failed email. Dependency conditions can also be generated by the system or the user in various ways.

[0605] In one embodiment, a success / failure dependency condition 530 can be set based on the first cycle condition 521. The first dependency condition 531 can be set if the first cycle condition 521 executes successfully. That is, if the model is actually run every Monday, it is set as a condition for sending a successful email if successful, and thus the successful email sending job 534 can be actually executed. The successful email sending job 534 corresponds to the email sending type in the job types described above.

[0606] Furthermore, if the execution of the first cycle condition 521 fails, a second dependency condition 532 and a third dependency condition 533 can be set. That is, if the model is not actually run every Monday, it is set to verify the cause of failure, and thus a verification job 535 can be executed. Verification job 535 corresponds to the program execution type in the job types mentioned above.

[0607] Furthermore, when verification is performed, there is no need to set separate conditions for successful or failed verification; instead, it is directly set to send a failed email, and the failed email sending job 536 is executed accordingly. The failed email sending job 536 corresponds to the email sending job type mentioned above.

[0608] In this embodiment, the illustration shows that no other dependent conditions 530 are generated for the second cycle condition 522, but it is also possible to set other dependent conditions 530 to be generated. In addition, other conditions besides the cycle condition 520 and dependent conditions 530 shown in the illustration can also be set for the first operation 510.

[0609] Figure 26 This is a flowchart illustrating the generation and execution of operational jobs in a local computing system according to one embodiment.

[0610] Although not illustrated, the validity of a user's license can be checked through the license service unit 1205 before generating an operational job.

[0611] The software model and logic set can be uploaded to the system operation unit (S500). The system operation unit can generate and set up operational tasks related to the actual execution of the developed software model and logic set. As described above, the software model and logic set obtained in the model development unit 1100 can be uploaded to the system operation unit 110. In addition, the deployment management service unit 1215 of the system operation unit 110 can store files according to the project path when storing files.

[0612] Based on the uploaded software model and logic set, at least one operational job can be generated (S505). As described above, at least one operational job may include sending emails, executing programs, executing model jobs, etc., related to the execution of the software model and logic set. Furthermore, the types of operational jobs can include various jobs such as experimental platform execution.

[0613] Next, an execution cycle and inter-job dependencies can be set for at least one generated operational job (S510). As described above, at least one execution condition can be set for an operational job. Furthermore, when there are multiple different types of execution conditions, mutual conditions can also be set between multiple execution conditions. In one embodiment, a procedure can be further included that not only sets the execution conditions, but also sets the activation / deactivation state of the execution conditions.

[0614] Furthermore, operational tasks can be executed according to the set execution cycle and inter-job dependencies (S515). For example, when there is an execution instruction from the job scheduler service unit 1230, the model execution unit 130 can execute operational tasks based on input data. At this time, the model execution unit 130 can receive the software model and logic file stored in the historical management storage unit 1270 as parameters. In addition, the model execution unit 130 can extract actual data from the client database 150 based on parameters and logic (connection information, mode, mapping information, etc.) and execute operational tasks according to the logic set to generate output files. Moreover, log files on the execution status of operational tasks can also be generated simultaneously.

[0615] The execution results of operational tasks can be uploaded to the database (S520). For example, the generated output files and log files can be uploaded to the database 150 of the client's manufacturing process system. Furthermore, the results of operational tasks may include, for example, production plans, operational system logs, etc.

[0616] Although not illustrated, the uploaded results can be queried in the model analysis unit or query interface. For example, output files and log files can be queried in the model analysis unit 1300 through the query interface included in the manufacturing process system on the client or the external file service unit 1220.

[0617] Figure 27 This is a flowchart illustrating the generation and execution of operational jobs in a cloud computing system according to one embodiment.

[0618] Unlike local computing systems, in cloud computing systems, at least one operational job is pre-generated, thus eliminating the need to upload software model files and logic set files to the job operation unit or generate operational jobs.

[0619] The client-side manufacturing system 100 can execute inbound logic, which is used to transform the input data pattern stored in the database 150 and upload the transformed input data to the cloud database 2500. Furthermore, based on the execution of the inbound logic of the client-side manufacturing system 100, input data, including client baseline information data, can be stored in the cloud database 2500.

[0620] The cloud computing system's operation and management unit 2100 can perform the same functions as the local computing system's system operation unit 110, and its configuration elements can also be the same.

[0621] First, the model settings corresponding to at least one operational task can be edited (S525). According to one embodiment, in a cloud computing system, at least one parameter related to at least one operational task can be set, such as whether an input decision agent is used in forward planning, and whether a weighted sum or weight sorting method is used when using the input decision agent. As described above, the model settings can be edited through the operation management unit 2100 of the cloud computing system 2000.

[0622] Next, execution cycles and inter-job dependencies can be set for at least one operational job (S530). As described above, execution cycles and inter-job dependencies can be set in the operations management unit 2100. For related information, please refer to step S510 of the local computing system.

[0623] Furthermore, operational tasks can be executed according to the set execution cycle and inter-job dependencies (S535). For example, when the job scheduler service unit of the operations management unit 2100 issues an execution instruction, the model executor 2400 of the cloud computing system 2000 can execute operational tasks based on input data. For related information, please refer to step S515 of the local computing system.

[0624] The execution results of operational tasks can be uploaded to the database (S540). For example, the generated output files and log files can be uploaded to the cloud database 2500 of the cloud computing system.

[0625] In addition, the output files and log files stored in the cloud database 2500 can be queried by the client system through the outbound API 2710 provided in the form of a user interface.

[0626] Figure 28 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0627] Receives a software model and logic set generated based on at least one data pattern and library engine set from the client manufacturing production system (S550).

[0628] As in Figures 23 to 25 As described above, the software model and logic set generated in the model development unit can be uploaded to the system operation unit through the server management unit.

[0629] Based on the uploaded software model and logic set, at least one operational job is generated (S560).

[0630] The system operations unit can generate at least one operations job and set execution conditions for that job. Operations jobs may include sending emails, executing programs, executing models, etc. Furthermore, execution conditions may include periodic conditions, dependency conditions, etc.

[0631] In the case of a cloud computing system, this step can be omitted, and instead, the model settings for the corresponding operational job, as well as the already set operational job and execution condition parameters, can be edited.

[0632] As in Figures 23 to 27 As described above, the system operation unit can drive the execution of the model execution unit based on the transmitted software model and logic set through the server management unit.

[0633] Based on at least one generated operational task, the software model and logic set are executed based on the input data to provide production planning information (S580).

[0634] As in Figures 23 to 27As described above, the model execution unit can execute software models and logic sets based on input data to generate results including production plan information, operation system logs, etc., and upload them to the database of the client system.

[0635] Figure 29 This is a schematic diagram illustrating one embodiment of a device for providing digital production planning information.

[0636] One embodiment of the apparatus for providing digital production planning information may include an input unit 410, a storage device 420, a memory 430, a processor 440, an output unit 450, and a user interface 460. For example, the apparatus for providing digital production planning information may correspond to a client's manufacturing system.

[0637] In the following embodiment, the device for providing digital production planning information is controlled according to user control and management based on user interface 460.

[0638] Input unit 410 receives from the local computing system a software model and a logic set generated based on at least one data pattern and library engine set of the client manufacturing system.

[0639] Storage device 420 can store pre-prepared reference information or received software models and logic sets. Storage device 420 may include volatile memory or non-volatile memory.

[0640] The 430MB of memory can store the library engine set disclosed above.

[0641] In one embodiment, the processor 440 can generate at least one operational job based on the software model and the logic set according to a user's request. Furthermore, the processor 440 can set the execution cycle and inter-job dependencies for at least one operational job; detailed embodiments of this are described in [the relevant documentation]. Figures 23 to 28 The information is disclosed in the literature. Furthermore, in one embodiment, the processor 440 can execute the received software model and logic set according to a user's request to obtain production plan data.

[0642] In one embodiment, the processor 440 executes operational tasks based on input data according to a logical set, and generates output files and log files about the execution status of the operational tasks.

[0643] Output unit 450 provides production plan data generated from the execution results of the software model and logic set, so as to manage production or processes in the client system.

[0644] This embodiment enables the automatic execution of a series of processes in manufacturing systems that require production plans with varying degrees of precision.

[0645] Figure 30This is a schematic diagram illustrating the analysis of production plans based on a software model and logic set according to one embodiment.

[0646] In the illustrated embodiment, the model analysis unit 1300 of the local computing system 1000 provides a framework that can analyze production plans based on software models and logical sets.

[0647] In one embodiment, the model analysis unit 1300 may include a model acquisition unit 601, a model execution unit 602, and a result analysis unit 603.

[0648] The model acquisition unit 601 can acquire the software model and logic set of the client manufacturing system. In one embodiment, the model acquisition unit 601 can acquire the software model and logic set, including input data and output data, from the operation server or server management unit after the production plan is generated.

[0649] In one embodiment, the model acquisition unit 601 can acquire the software model and logic set based on at least one of the following model analysis unit configuration information (e.g., exe.config): software automatic update information, log file storage information, connection information of the operation server or server management unit, and model download service path information of the model analysis unit 1300.

[0650] In one embodiment, the model acquisition unit 601 can acquire the software model (e.g., xxx.vmodel) based on a pre-stored model information file (e.g., xxx.vinfo). In this case, the model information file may include at least one of the following: assembly information of the simulation logic file (DLL), the configuration file path of the simulation logic file, assembly information of the user interface (UI) logic file, and the configuration file path of the user interface logic file. In one embodiment, the model information file may be configured as a separate file from the software model, or it may be included within the software model to form a single file.

[0651] In one embodiment, the model acquisition unit 601 can acquire the software model and logic set generated by the model development unit. In this case, the software model and logic set may include input data prior to production plan calculation.

[0652] The model execution unit 602 can calculate data related to the production plan based on the software model and logic set. In one embodiment, the data related to the production plan may include at least one of model information, experiment plan information, and experiment result information. Details of this will be described below.

[0653] In one embodiment, the model execution unit 602 can execute a set of logic about the software model based on a configuration file (e.g., Sim.config) of the simulation logic file. Here, the configuration file of the simulation logic file can be used to record at least one of the following: the folder containing the simulation logs during experiment execution, the format of the log files, and the memory cache settings used in the simulation.

[0654] The results analysis unit 603 can provide data related to the production plan. In one embodiment, the results analysis unit 603 can provide data related to the production plan through a user interface. Details of this will be described below.

[0655] In one embodiment, the result analysis unit 603 can provide production plan-related data as analysis results based on the analysis user interface defined in the configuration file (e.g., App_GeneralUI.config) of the user interface logic file. Here, the configuration file of the user interface logic file can represent at least one of the following: menu configuration information of the analysis user interface, assembly connection information between the menu and the executable file, and interface settings information for input / output data.

[0656] Figure 31 This is a schematic diagram illustrating a data query interface according to one embodiment.

[0657] In the illustrated embodiment, a data query interface 604 can be provided through the user interface of the model analysis unit 1300 of this disclosure. Here, the data query interface 604 can display data related to the production plan of the client manufacturing system. For example, the data related to the production plan may include at least one of the production plan input data and output data of the client manufacturing system.

[0658] In one embodiment, the data items (i.e., fields) of the input and output data in the production planning related data can be displayed in a grid format on the data query interface 604. The grid can consist of rows and columns. For example, the grid columns may include device ID (EQP_ID), batch ID (LOT_ID), product ID (PRODUCT_ID), and job ID (PROCESS_ID), but are not limited to these; they can include multiple items.

[0659] In one embodiment, based on user input to the data query interface 604, data retrieval, data copying, data filtering, data sorting, and grouping functions can be performed on the data included in the grid. For example, the dragged area can be grouped by dragging columns, and the display settings of the grouped columns can be configured using a group summary editor. In one embodiment, the display settings can represent a summary value for the group. For example, the display settings may include the number of rows corresponding to the group and at least one of the average, maximum, minimum, and sum of the numeric columns other than the grouping columns.

[0660] Furthermore, in one embodiment, the position of a column within the grid can be changed based on user input to a specific column in the data query interface 604. For example, by clicking and dragging the input in the job ID column, the position of the job ID column (PROCESS_ID) can be moved from the right to the left of the product ID column (PRODUCT_ID). Therefore, according to this disclosure, changing the position of this column can improve the visualization of the correlation between columns. That is, when the number of columns is too large and the data exceeds the data query interface 604, changing the position of the columns can provide users with greater convenience in data analysis.

[0661] In one embodiment, multiple data tables in a grid format can be joined to query the data. In another embodiment, data in various formats can be imported or exported to the software model. For example, data in the form of Excel files or text files can be loaded, or data can be exported in the form of Excel files, text files, HTML, XML, RTF, PDF, or MHT files.

[0662] Figure 32 This is a schematic diagram illustrating a pivot table query interface according to one embodiment.

[0663] In the illustrated embodiment, a pivot table query interface 605 can be provided through the user interface of the model analysis unit 1300 in this disclosure. Here, the pivot table query interface 605 can display data related to the production plan of the client manufacturing production system in the form of a pivot grid.

[0664] In one embodiment, the data values ​​of the data items to be analyzed can be selectively viewed through the pivot table query interface 605 by setting the filter area, column area, row area, and data area.

[0665] For example, by setting the column range to production plan date (PLAN_DATE), the row range to process ID (STEP_ID), and the data range to output (OUT_QTY), the output of each process on each production plan date can be confirmed in numerical form.

[0666] In one embodiment, a data analysis charting interface 606 may be provided. Here, the data analysis charting interface 606 can display data created through pivot tables in chart form. For example, the chart form may include line charts, bar charts, point charts, and area charts, but is not limited to these; various chart forms may be used.

[0667] Figure 33 This is a schematic diagram illustrating a data editing interface according to one embodiment.

[0668] In the illustrated embodiment, a data editing interface 607 can be provided through the user interface of the model analysis unit 1300 in this disclosure. Here, the data editing interface 607 can be used to edit data related to the production plan.

[0669] In one embodiment, production plan-related data items displayed in a grid format in the data editing interface 607 can be edited based on user input. In another embodiment, filtering can be performed in the data editing interface 607, and batch modifications can be made to the filtered data. For example, when at least one column of the filtered data is selected and a value is entered, the data items in that column can be batch modified to that value.

[0670] For example, when the LINE_ID column is selected and its value is entered as LINE01, the values ​​of all rows in the LINE_ID column can be batch-modified to LINE01. Furthermore, in another embodiment, if the LINE_ID in the EQP table is filtered to LINE01, the STATUS can be batch-modified to UP.

[0671] Figure 34 This is a schematic diagram illustrating the experimental setup and execution interface according to one embodiment.

[0672] In the illustrated embodiment, an experiment setup and execution interface 608 can be provided through the user interface of the model analysis unit 1300 of this disclosure. Here, the experiment setup and execution interface 608 may include at least one of experiment plan information and experiment result information regarding the execution of the experiment.

[0673] In one embodiment, an experiment comprising at least one scenario can be generated, and experimental plan information can be set for the experiment. In one embodiment, the experimental plan information may represent an experimental plan related to a specific scenario in the input data table that can be queried through the experimental setup and execution interface 608, within the at least one scenario included in the experiment. At this time, the experimental plan corresponds one-to-one with the scenario, and as the experiment is executed, the experimental results for each scenario can be added to the corresponding experiment one by one. In one embodiment, the experimental plan information may include at least one of global variable settings, input data, input settings, and output settings.

[0674] In one embodiment, global variable settings may include at least one global variable from parameters such as the software model version, experiment start time, reverse engineering engine, forward engineering engine, debugging and job change agent. Furthermore, output settings may indicate how the results generated during experiment execution are stored.

[0675] In one embodiment, the input persistent configuration information includes a data collection order editing function. For example, the input settings information may include a data collection order editing function in the input persistent configuration information.

[0676] In one embodiment, experiments can be executed in a local environment based on configured experimental plan information to generate experimental results. In another embodiment, the generated experimental results can be stored according to output storage options. In yet another embodiment, global variable settings may include global variable settings based on the currently acquired software model, previously executed experimental results, or other versions of the software model.

[0677] Figure 35 This is a flowchart illustrating the analysis of production plans based on a software model and logic set according to one embodiment.

[0678] Obtain the software model and logic set of the client manufacturing system (S611). In one embodiment, the software model and logic set may include at least one of the input data and output data of the production plan of the client manufacturing system. Please refer to the above for details.

[0679] Based on the software model and logic set, at least one data related to the production plan is generated, including model information, experimental plan information, and experimental result information (S612). In one embodiment, the model information includes at least one of the following: a data pattern about the software model, a data source about the input data, a query about the data pattern, and global variables.

[0680] In one embodiment, the experimental planning information includes at least one of the following: experimental setup information regarding input and output data based on the software model and logic set, and experimental global variables, prior to the execution of the experiment.

[0681] In one embodiment, the experimental results information includes input and output data generated by executing the experiment using the software model and logic set according to the experimental plan information. For more information, please refer to... Figures 30 to 34 The content described in the text.

[0682] Provide production planning related data (S613). In one embodiment, the production planning related data includes at least one scenario set based on input data from a modified software model, and result data generated from executing an experiment including that scenario. For more information, please refer to... Figures 30 to 34 The content described in the text.

[0683] Reference Figure 8 An embodiment of an apparatus for analyzing production plans based on a software model and a logic set and providing digital production plan information is described below.

[0684] One embodiment of the apparatus for providing digital production planning information may include an input unit 310, a storage device 320, a memory 330, a processor 340, an output unit 350, and a user interface 360.

[0685] The following is an embodiment of the device for providing digital production planning information, which operates according to user control and management based on user interface 360.

[0686] Input unit 310 can acquire the software model and logic set of the client manufacturing system. Storage device 320 can store the software model and logic set received by input unit 310, or store the software model and logic set in storage device 320. Storage device 320 may include volatile memory or non-volatile memory. Memory 330 can store the library engine set disclosed above. The library engine set may include a production planning engine, which is a multi-encapsulated function block file for generating production plans.

[0687] In one embodiment, the processor 340 acquires a software model and logic set regarding the client's manufacturing production system, and based on the software model and logic set, calculates data related to the production plan, including at least one of model information, experimental plan information, and experimental result information, and provides the data related to the production plan. For details, please refer to the above description.

[0688] Processor 340 can test or pre-execute software models and logic sets to obtain production plan data based on user requests from the user interface 360. Furthermore, processor 340 can provide the user with the results of analysis or testing of the software models and logic used to generate the production plan data through the user interface 360, based on user requests. Please refer to the above description for details.

[0689] Output unit 350 provides analysis results data of software models and logic sets, as well as results data of experiments performed based on software models and logic sets, so as to manage production or processes in local environments and client systems.

[0690] The following will disclose in detail an embodiment of providing production planning data through an experimental platform using a software model and logic set generated based on an installed library engine set.

[0691] As described above, the system operation unit 110 of the client manufacturing production system 100, upon receiving the software model and model logic developed by the model development unit 1100 through the server management unit 1200, provides input data including baseline information data from the database 150, and uses this data to execute the received software model and logic set to generate production plan data.

[0692] When using a single software model and single logic to generate production plan data, the production plan data can be provided through the model execution unit 130. In this case, the model execution unit 130 executes the software model and model logic to generate production plan data, thereby providing production plan data that can be analyzed by the model analysis unit 1300.

[0693] On the other hand, when using multiple software models or logic, complex tasks involving multiple experiments can be executed through the experimental platform unit 140.

[0694] An experimental platform refers to a dataset containing the necessary information and experimental results required to conduct various experiments using at least one software model and at least one model logic. Furthermore, the experimental platform unit 140 corresponds to a configuration designed for querying, editing, executing, and analyzing the aforementioned experimental platform.

[0695] In the embodiments of this disclosure, an embodiment of performing complex tasks based on experimental platform unit 140 will be described.

[0696] Figure 36 This is a schematic diagram illustrating a computing system that provides digital production planning data according to one embodiment.

[0697] This figure illustrates an embodiment of a local computing system that provides digital production operation data. In this embodiment, the local computing system 1000 and the manufacturing production system 100 may further include, for example, Figure 2 The experimental platform unit in the illustrated embodiment.

[0698] In one embodiment, the manufacturing system 100, as a system that executes production planning on the client side, provides input data including baseline information for production execution to the local computing system 1000, and the model development unit 1100 can generate software models and model logic.

[0699] The server management unit 1200 transmits the software model and model logic generated by the model development unit 1100 to the client. The system operation unit 110 of the client 100 can define, set, register and execute operations related to the execution of the software model and model logic.

[0700] In one embodiment, the manufacturing production system 100 includes a system operation unit 110 responsible for the operation and management of the manufacturing process, a model execution unit 130 that generates production plan data according to the execution request of the system operation unit 110, an experimental platform unit 140 that requests the model execution unit 130 to perform various experiments, and a database 150 that stores the execution results of the model execution unit 130, i.e., the production plan data.

[0701] As described above, an experimental platform refers to a dataset containing the necessary information and experimental results required to conduct various experiments using at least one software model and at least one model logic. The local computing system 1000 and / or the client manufacturing process system 100 may include experimental platform units 140 and 1500. Furthermore, for querying, editing, and executing the experimental platform, experimental platform units 140 and 1500 may include an experimental platform editing unit, an experimental platform execution unit, and an experimental platform analysis unit. Related details will be described below.

[0702] Experimental platform units 140 and 1500, based on at least one software model and at least one logic, design experiments encompassing multiple scenarios and execute these experiments using pre-prepared input data from database 150 to provide production planning data. The production planning data may include experimental results as an experimental summary and scenario outcomes.

[0703] Figure 37 This is a schematic diagram illustrating the basic structure of an experimental platform based on a software model and logic set according to one embodiment.

[0704] As shown in the figure, the experimental platform is a collection of information including variables 722, key performance indicators (KPIs) 723, experimental design 724, experimental execution 725, and database (DB) connection information 726.

[0705] Factor 722 is the type of information corresponding to the modifiable elements used in a specified experiment. Factor value is the information value corresponding to the use of a specific variable in the experiment.

[0706] Variables may include at least one model type variable and at least one logical type variable. Each model type variable or logical type variable may have its own variable value. In addition, it may also include lower-level variables and have lower-level variable values.

[0707] Key Performance Indicators (KPIs) are functions that quantify the results of various scenarios. Each KPI can have its own value, known as a KPI value. A KPI value corresponds to the actual value obtained by applying the formula used for the KPI to the scenario results obtained through experimental execution.

[0708] On the other hand, a scenario is a software model that takes determined variable values ​​as input and prepares to be executed using the logic of those determined values. Scenario results are the outcomes obtained from executing the scenario and can be represented in tabular form. An experiment is a unit corresponding to multiple scenarios. For example, referring to the illustration, the experiment designed using Experiment Design 1 corresponds to an experiment including two scenarios.

[0709] Experimental design 724 is a structure encompassing scenario combinations using variables and key performance indicators (KPIs). For example, in experimental design 1 of this embodiment, it is a fixed-scale experimental design corresponding to two scenario combinations including variable values ​​1_1_2 and 1_1_3 of model variable 1_1. Furthermore, in experimental design 2 of this embodiment, it is an iterative experimental design corresponding to six or more scenario combinations including variable values ​​1_1_1 of model variable 1_1, variable values ​​1_2_1 and 1_2_2 of model variable 1_2, variable value 2_2 of logical variable 2, key performance indicator KPI_3, and iteration phase logic. However, it is not limited to these combinations and the number of scenarios can be increased or decreased. Fixed-scale and iterative experimental designs will be described below.

[0710] Furthermore, Experiment Execution 725 is a structure based on experimental design, which involves creating various scenarios, changing variable values, executing the experiment, and then calculating and storing the key performance indicators (KPIs) from the results. Its execution results can include experimental results. For example, an experiment summary can correspond to a table including variable values ​​and KPI values. Furthermore, Experiment Execution 725 is a structure based on experimental design, which involves creating various scenarios, changing variable values, executing the experiment, and then calculating and storing the KPIs from the results. Its execution results can include experimental results.

[0711] For example, in Experiment Execution 1 of this embodiment, according to Experiment Design 1 described above, variable values ​​are changed for two scenarios and experiments are executed. The results may include an experiment summary, which is a set of at least one variable value and at least one key performance indicator value. Furthermore, the results obtained from executing the experiment can be uploaded to a database based on database connection information. Using the above-described experimental platform, compared to repeatedly changing the variable values ​​of a single model logic through a model execution unit and then executing it, multiple model logics can be executed in a single experiment, thus completing complex tasks more efficiently. Furthermore, the results obtained from executing the experiment can be uploaded to a database based on database connection information. Compared to executing a single model logic through a model execution unit, using the above-described experimental platform allows for more efficient execution of complex tasks because the variable values ​​of multiple model logics can be changed multiple times during execution.

[0712] Figure 38 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0713] First, the experimental platform unit 140 can generate an experimental platform file. This experimental platform file corresponds to the object file from which variables related to the model and logic will be registered and generated later. Furthermore, when generating the experimental platform file, a storage path (storage location) can be specified as a parameter. This path can be an absolute or relative path on the software operating system (OS). For example, after generating the experimental platform file, the storage location of edit information is generally managed using the relative path of the experimental platform file, but an absolute path can also be specified.

[0714] Experimental platform files can store edited information and execution results, or they can be divided into separate files for management. For example, variable information and variable value information can be stored in separate files along with the execution results, so that the variable information and variable value information can be loaded and reused in other experimental platform files.

[0715] After generating the experimental platform file, at least one model type variable and at least one logic type variable can be registered in the generated experimental platform file. For example, each model and logic can be registered as a variable. At this time, the variable value of the model type variable is the model itself at the time of registration, corresponding to the complete set of information including input data, output data, logic, etc. In addition, the variable value of the logic type variable corresponds to the absolute / relative path of the logic file set in the model execution unit 130 for use with the model, or a compressed file including the absolute / relative path.

[0716] For example, refer to Figure 38 We can assume that the dispatch logic has been improved in a specific logic, resulting in three versions of the logic. Logic_0 represents the original logic, and logic_1 through logic_3 correspond to the improved logic. Users can verify the execution time and production plan quantity of the logic in the past 10 models to reflect the three well-performing logic versions. The experimental design reflecting this corresponds to... Figure 38 Experimental design 1.

[0717] At this point, after registering the future key performance indicators, the results of experiments covering a total of 40 scenarios, including 4 logical versions (original logic and 3 improved logics) and 10 past models, can be reviewed and decisions can be made. For example, based on the experimental results, if scenario 1 shows a shorter drive time and increased output, the user can make a decision by using the logical version corresponding to scenario 1.

[0718] Figure 39 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0719] Specifically, Figure 39 This diagram illustrates the registration of data type variables, variable values, and key performance indicators (KPIs) in the experimental platform file. Data type variables are subordinate concepts to model type variables and can be defined based on the data defined within the model type variables. Furthermore, variable values ​​can include both the values ​​of model type variables and the values ​​of data type variables. Figure 37 The value of model variable 1 corresponds to the value of the model type variable in the model.

[0720] In one embodiment, the object of a data type variable can be any single data point existing within the input data of the software model. For example, a single data point can be identified by the name of a global variable in the model. Alternatively, a single cell can be identified by the key and target columns in the data table. In this case, the variable value can be determined based on the type of the single data point. Data types can include not only numeric data but also text data, date data, and so on.

[0721] For example, in the Demand table of Model 1, Demand_ID / Quantity is given in the form of quantity. When Demand_ID is the key and the target column is the quantity, if the data is Demand_1 / 100, Demand_2 / 200, and Demand_3 / 100, then the quantity that satisfies the condition Demand_ID == "Demand_1" can be specified as the corresponding cell.

[0722] In another embodiment, the object of the data type variable can be all the input data tables of the model. In this case, the variable value can correspond to a data table, and the schema of the data table can be determined based on the original data schema. For example, the data table can modify at least one data cell value in the original data table. Furthermore, the data table can be edited by loading external files, batch modifying all data that meets key conditions, etc.

[0723] For example, in Figure 39 In this model, the data type variables for variable 1 can include quantity (711), simulation horizon (713), and process time table (715). For example, quantity (711), as a single cell variable, can generate three corresponding variable values: 50, 100, and 150. Simulation horizon (713), as a global variable, can generate two variable values: 30 days and 60 days. Furthermore, process time table (715), as a table variable, can generate two variable values: Table 1 and Table 2.

[0724] Key performance indicators (KPIs) can include function information that processes information from the scenario's input data and results. Furthermore, various functions can use registered model type variables and data type variables, all forms of data included in the model (global variables, input / output data), and other KPIs as parameters. KPI values ​​can be single scalar values ​​or vector values.

[0725] For example, whether a specific key performance indicator (KPI) is better when its value is higher or lower can be used as a parameter. This can be used to determine color differentiation, arrow direction, etc., when displaying improvement points in the experimental platform analysis unit or a separate results query user interface.

[0726] When one or more Key Performance Indicators (KPIs) are involved, the calculation order among KPIs can exist and can be edited because different KPIs can be used as parameters. For example, in production planning evaluation, suppose we derive a weighted sum of three values—output, equipment changeover frequency, and delivery delay quantity—to represent a composite score. In this case, we need to first register output, equipment changeover frequency, and delivery delay quantity as independent KPIs, with the composite score corresponding to each KPI. Then, we can first calculate the independent output, equipment changeover frequency, and delivery delay quantity, and then calculate the dependent KPI, i.e., the composite score, thus avoiding double counting.

[0727] On the other hand, when weekly, monthly, and quarterly output are used as key performance indicators (KPIs), independent indicators can be calculated first, followed by dependent indicators. In this embodiment, weekly output is calculated first, then the monthly output affected by it is calculated, and finally, quarterly output is calculated based on this. The calculated KPI values ​​can be used as parameters in subsequent indicator calculations, thereby avoiding duplicate calculations.

[0728] Furthermore, the functions provided in the key performance indicators (KPIs) can support table summaries, arithmetic expressions, and data type conversions. For example, summary functions may include, but are not limited to, Sum, Count, Avg, Min, Max, and Std. Additionally, summary functions may include, for example, Sum, Count, Avg, Min, Max, and Std, but are not limited to, summation (Sum), count, average, minimum (Min), maximum (Max), and standard deviation (Std). Data type conversions may include converting date formats to integer formats.

[0729] For example, refer to Figure 39Key performance indicators (KPIs) can include average product production time (product_1 Avg. CT) 717, total product quantity (Total Product qty) 719, and run time (Run Time) 721. For example, average product production time 717 calculates the average cycle time of Product 01 from entering the factory to leaving, and can include functions such as Average(Model_1.Output.InOutPlan, PRODUCT_ID == “Product_01”, Cycle_Time). Similarly, total product quantity 719 is calculated by reviewing the production records of all products and summing the output, and can include functions such as Sum(Model_1.Output.InOutPlan, None, Quantity). Furthermore, run time 721 is calculated by subtracting the start time from the end time to obtain the execution time, and then converting it to numerical data, and can include functions such as ConvertFromTimeSpanToDouble(Model_1.End_Time - Model_1.StartTime).

[0730] Figure 40 This is a schematic diagram illustrating the generation of refined logic in an experimental platform file based on a software model and logic set, according to one embodiment.

[0731] To use the model as desired by the user, the software model and model logic in the model development unit 1100 are typically already developed. However, there are exceptions. During the review of the model by other engineers on the experimental platform, even if the model and logic cannot be edited through the model development unit 1100, they may still want to further confirm certain information. In this case, refinement logic can be used. This embodiment will describe an example of setting up refinement logic for the results of each scenario or experiment.

[0732] Refinement logic can include refinement logic for each scenario result and refinement logic for each experiment result. Refinement logic is not a necessary component and can be used when the desired form of result cannot be obtained using the pattern already defined in the model file.

[0733] In one embodiment, the scenario result refinement logic can refine the scenario results to generate a new table at the end of each scenario. In this case, data can be stored in a separate schema, allowing schema generation and data input from an external source without going through the model development unit 1100. In this case, the data used is limited to the data included in the scenario results. For example, refer to... Figure 40In the model output pattern of the model development unit 1100, although the input and completion times (InOutPlan) 739 of each process for each workpiece exist, it is assumed that there is no record of the time (CycleTime(CT)) spent by the workpiece from entering the factory to leaving. In this case, a CycleTime(CT) table can be generated using the refinement logic of each scenario result, and workpiece ID, workpiece type, and cycle time can be generated using a pattern. For example, the CycleTime 743 of Lot_1 is the difference between the time of the first process 741 and the time of the last process 742 of Lot_1, and the CycleTime 747 of Lot_2 is the difference between the time of the first process 745 and the time of the last process 746 of Lot_2.

[0734] Furthermore, the tables generated through the refinement logic of each scenario's results can be used as parameters for key performance indicators. For example, refer to... Figure 40 You can refer to the InOutPlan for each scenario to create a custom pattern that outputs the difference between the start time of the first process and the end time of the last process for each batch, i.e., the workpiece cycle time, and input the data. Furthermore, it can be used as a key performance indicator to numerically represent the maximum cycle time and average cycle time for each scenario.

[0735] Furthermore, at the end of each scenario execution, the time difference between the start time of the first process and the end time of the last process for each workpiece can be calculated, and the data can be placed into a new table of cycle time patterns, thus providing a new table for the scenario results. For example... Figure 40 As shown, when scenario refinement logic 740 is executed on scenario 1, a CycleTime table 750 can be generated, and CycleTime data 743 and 747 can be added to each scenario. When scenario refinement logic 740 is executed not only on scenario 1, but also on all scenarios, the obtained CycleTime data can be added to the results 736 of each scenario.

[0736] In another embodiment, the experimental results refinement logic can generate results beyond the basic combinations of variables and key performance indicators provided.

[0737] For example, refer to Figure 40 Assuming all scenarios have been executed and their cycle times have been generated through refinement logic, an average cycle time can then be generated using the refinement logic based on the experimental results, with the workpiece type and average cycle time as input. Furthermore, the cycle times for all scenarios can be analyzed to calculate the average cycle time for each workpiece type, thus providing an average cycle time.

[0738] When executing experimental refinement logic 760, an average CycleTime table 765 can be generated, and average CycleTime data 759 for each product can be added. For example, the average CycleTime can correspond to the average of CycleTimes 751, 753, and 755 for all product batches. The average CycleTime data obtained when executing experimental refinement logic 760 can be added to the experimental results 733.

[0739] By refining the logic through various scenarios or experiments, users can obtain additional results for patterns not included in the model files defined by the model development unit.

[0740] Figure 41 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0741] After registering at least one model type variable and at least one logical type variable, and registering the associated model variables, variable values, and key performance indicators, you can design and execute experiments.

[0742] As mentioned above, experimental design can be done using variables and key performance indicators (KPIs) registered in the experimental platform file. For example, experimental design refers to the process of setting combinations of variable values ​​and KPIs. Furthermore, experimental design can include fixed-size experimental design and iterative experimental design. Fixed-size experimental design uses pre-registered variables and their combinations of values; it means that the number of all possible scenarios can be predetermined before the experiment is executed.

[0743] Experiment execution involves generating scenarios based on information included in the experimental design, and outputting the structure of the results after executing the experimental platform file. For example, the experimental platform execution unit of experimental platform unit 140 can generate multiple scenarios based on the information input in the generated experimental platform file, and pass the files corresponding to each scenario as parameters to model execution unit 130 for execution. After model execution unit 130 executes multiple scenarios, the experimental platform execution unit can calculate the key performance indicators for each scenario and collect them as an experimental summary.

[0744] The results may include the start and end times of the scenarios and their values, key performance indicators (KPIs) and their values. Furthermore, the experiment execution may include the number of parallel executions as a parameter. The number of parallel executions refers to the number of scenarios that can be executed simultaneously during the experiment. In a fixed-scale experiment design, if there are N scenarios and M parallel executions, the total number of executions is the rounded-up value (N / M), which is the number of times N is divided by M and then rounded up. Here, the number of parallel executions can be set to the number of physical CPU cores or can be set by the user.

[0745] For example, refer to Figure 41 Experimental Design 1 (770) is a fixed experimental design consisting of a combination of variable values ​​and key performance indicators (KPIs). In Experimental Design 1 (770), based on the combination of variable values ​​and KPIs, the total number of possible scenarios can be determined to be XY. In this case, a user interface can be provided, which allows users to selectively delete or modify scenarios after displaying a preview of all XY scenarios to determine the experiment. For example, the experimental order can be adjusted through the interface. Furthermore, Experiment Execution 1 (775) generates XY scenarios based on the information included in Experimental Design 1 (770) and can be executed a number of times, namely Ceiling(XY / 4), which is the number of times XY is divided by the number of parallel executions 4 (776) and rounded up.

[0746] On the other hand, fixed-scale experimental designs can include scenarios where both variables and their values ​​are predetermined. Suppose that when receiving orders from a customer, an estimated production scenario considering the order volume received so far is required. For example, given that orders for products A, B, and C have been received in quantities of 100 each as of January 30th, an existing customer requests to increase production of product A as much as possible. The production planner must be able to explain to the customer how much of product A can be added and by when. In this case, the quantity of product A in the order volume of products A, B, and C before January 30th can be set as a variable, increasing from 100 in increments of 10 to 300, generating and executing 21 scenarios to calculate the unmet delivery quantity for each product, total production volume, etc. If this information is provided to the customer, and the total production volume no longer increases and the unmet delivery quantity for each product remains below a certain value, it can be determined that X units of product A can be added by January 30th. Similarly, by providing relevant information with the delivery date of product A as a variable, it can be determined that X units can be added by day Y.

[0747] Furthermore, fixed-scale experimental designs can include states where variables are determined, but their values ​​are undetermined. For example, suppose an experiment is conducted where N features are used in a decision-making agent to perform a weighted sum and weight sort, and the feature priorities / weights are changed. For instance, suppose three features—FIFO, SETUP, and DELAY—are used for weight sorting, with lower priorities taking precedence. There are six possible priority permutations: 1,2,3 / 1,3,2 / 2,1,3 / 2,3,1 / 3,1,2 / 3,2,1 (i.e., 3!). In this case, the priority fields for the three features are selected as variables, and the values ​​generated from the permutations are entered—the undetermined feature values. After executing the experiment, the customer can choose the priority combination with the fewest device replacements as the final scenario.

[0748] Furthermore, after the experiment is completed, an experiment summary and scenario results can be obtained. At this point, the experiment summary corresponds to information related to variables and key performance indicators (KPIs). For example, the experiment summary may include variable values ​​for each scenario, KPI values ​​calculated through scenario execution, execution time and termination time, success or failure of execution, execution order, etc. If at least one KPI is registered in the experiment, KPI values ​​can be calculated sequentially based on a preset calculation order. As mentioned above, scenario results, as the result of executing a single model, may include data generated by the refinement logic and output data including production plan data.

[0749] On the other hand, during experiment execution, whether to delete at least a portion of the input and output data can be set as a parameter. This is because storage space may be insufficient when all information for all scenarios is available. Furthermore, whether to upload the experimental results to database 150 after experiment execution can also be configured as a parameter. That is, as needed, files containing compressed experimental platform information, experimental results, etc., can be uploaded to database 150.

[0750] Figure 42 This is a schematic diagram illustrating the generation of experimental platform files based on a software model and logic set according to one embodiment.

[0751] As mentioned above, experimental design can include fixed experimental design and iterative experimental design. Iterative experimental design uses pre-registered variables as its objects and determines variable values ​​through iterative stage logic to design the experiment. Therefore, the number of scenarios to be executed and the variable values ​​in each experimental step can be determined based on the corresponding iterative stage logic. Iterative experimental design can form adaptive experimental design based on the form of the iterative stage logic. For example, adaptive experimental design corresponds to designing the scenario for the next iteration based on the included scenario results in each iteration, aiming to improve a specific key performance indicator. In this case, "direction" refers to the direction of change of the variable value to improve the specific performance indicator, which can be applied in different ways based on the algorithm used in the iterative stage logic.

[0752] Furthermore, iterative experimental design can include termination conditions and iteration phase logic as parameters. For example, termination conditions can include the number of iterations, target time, target performance value, and drive time.

[0753] Furthermore, the input and output values ​​of at least one iterative stage logic included in the iterative experimental design can be determined based on arbitrary values ​​specified by the user, initial variable values ​​input by the user, the logic itself input by the user, or samples extracted from a specific distribution assumed in the logic.

[0754] The execution of iterative experimental designs is similar to that of fixed experimental designs, and can include the number of parallel executions as a parameter. In the case of iterative experimental designs, if the number of scenarios (L) executed in the iteration phase exceeds the number of parallel executions (M), then parallel execution is performed 10 times, i.e., L is divided by M and rounded up. After executing the iteration phase logic, the process moves to the next iteration phase.

[0755] Reference Figure 42 Experimental Design 2 (780), as an iterative experimental design, consists of a combination of variables and key performance indicators. Regarding the variable values, initial values ​​can be arbitrarily specified, or previously calculated variable values ​​from the iteration phase logic can be used. These variable values ​​are not constrained by previously set variables but are determined by the iteration phase logic. Furthermore, Experimental Execution 2 (785), based on the information included in Experimental Design 2 (780), performs parallel execution (787) on multiple scenarios in the initial iteration phase, and passes the results of the parallel execution as parameters to the iteration phase logic (789). After execution, it moves to the next iteration phase. At this point, the iteration phase logic (789) can determine the number of scenarios to be executed in the next iteration and the variable values. Based on the values ​​determined in the iteration phase logic (789), parallel execution is also performed in the next iteration phase, and this process can be repeated cyclically.

[0756] Figure 43 This is a schematic diagram illustrating an experiment performed based on a software model and a set of logic, according to one embodiment.

[0757] The experimental platform unit may include an experimental platform editing unit, an experimental platform analysis unit, and an experimental platform execution unit. This can be structurally identical to the experimental platform unit 140 of the client manufacturing process system and the experimental platform unit 1500 of the local computing system.

[0758] In the case of the local computing system 1000, the experimental platform analysis unit of the experimental platform unit 1500 can pass the experimental platform file as a parameter to the experimental platform execution unit. Furthermore, in the case of the client manufacturing process system 100, the experimental platform file edited by the experimental platform editing unit can be passed as a parameter to the experimental platform execution unit 143 through the job scheduler service unit 1230 of the system operation unit 110. Additionally, the experiments to be executed can also be passed as parameters. That is, multiple experimental platform execution units can be invoked simultaneously. For example, the experimental platform execution units can process multiple experiments included in an experimental platform file in parallel, or the order of multiple experiments can be passed as parameters.

[0759] In the following text, the operations performed in the experimental platform execution unit correspond to those performed in the same way in the client manufacturing process system and the local computing system. First, a scene file can be generated and variable values ​​applied (S610). For example, the generated scene file is generated by copying the model as the base model type variable and changing some variable values. On the other hand, in the case of iterative experimental design, the iterative experimental logic can be executed before executing step S610.

[0760] As described above, scene files are generated based on the number of variable values, and at least one scene file generated can be stored in scene storage area 771. Furthermore, at least one scene file stored in scene storage area 771 corresponds to a state that has not yet been executed.

[0761] Next, a scene execution command regarding at least one scene file can be passed to the model execution unit (S615). For example... Figure 43 As shown, for example, at least one scene file can be executed entirely within a single model execution unit. Furthermore, for example, each scene file can be assigned a corresponding model execution unit for parallel execution.

[0762] Furthermore, at least one scenario can be executed based on the scenario execution command of the model execution unit (S620). At this time, as described above, depending on the selection, not only can scenarios be executed, but experimental refinement logic can also be executed. For example, if the scenario results of the experimental refinement logic are used as parameters, the scenario results and experimental results can be refined based on the experimental refinement logic. Furthermore, as... Figure 43 As shown, the scenario results, scenario refinement results, and experiment refinement results can be stored in the result storage area 772. At this time, the data stored in the result storage area 772 can correspond to the result data 1266. For example, the scenario results may include result data from executing a single model, log data, etc.

[0763] Next, based on the scenario results, key performance indicators (KPIs) can be calculated, and KPI values ​​can be derived (S625). For example, KPI values ​​can be represented as scalars or vectors. KPI values ​​can be included in the experiment summary 774, and can also include variable values ​​for each scenario, execution time and termination time, execution success or failure, execution order, etc.

[0764] For the experimental platform unit 1500 of the local computing system 1000, the experimental summary 774 can be stored in the experimental platform file 773, and the original file of the experimental platform file 773 can be modified as needed. Furthermore, in the case of the experimental platform 140 of the client manufacturing process system 100, the experimental summary 774 can be transmitted as result data 1266.

[0765] Since the files stored in the result storage area 772 have a large capacity, they can be deleted according to the settings (S630). However, deleting files in the storage area is not always necessary, and there are cases where files are retained without being deleted.

[0766] Next, the experimental results can be uploaded to the database (S635). In addition, if the experiment performed is an iterative experimental design, iterative experimental logic can be followed, and the experiment can be repeated starting from step S610.

[0767] Figure 44 This is a schematic diagram illustrating, according to one embodiment, the output of information about experimental platform files based on a software model and a set of logic.

[0768] After generating the experimental platform file, a user interface can be provided for verifying experimental results during the design and execution of experiments. For example, result verification can be provided through a separate user interface or via an outbound API on a webpage. Furthermore, results can be automatically uploaded to database 150 during experiment execution.

[0769] The experiment summary file can exist as a separate file including a summary of the experimental platform, and can include various information, such as information related to variables, key performance indicators (KPIs), experimental design, and experimental execution. Furthermore, it can also include KPI results, variable / variable values ​​and combinations of KPIs, and experimental execution results.

[0770] Furthermore, the variables, key performance indicators (KPIs), experimental design, and experimental execution information included in other experimental platforms can be utilized by loading them from other experimental platforms. For example, when generating Experimental Platform 1 (790) for Client A, after generating scenario files for variables, KPIs, experimental design, and experimental execution, a new experimental platform, namely Experimental Platform 2 (795), may be generated for Client A. In this case, it is not necessary to regenerate variables, KPIs, etc. for Client A. Instead, the data can be reused by performing the operation of exporting relevant files from Experimental Platform 1 (790) or performing the import operation in Experimental Platform 2 (795).

[0771] Figure 45 This is a schematic diagram illustrating the execution of an experiment in an experimental platform unit based on a software model and logic set, according to one embodiment.

[0772] As described above, the experimental platform unit 140 may include an experimental platform editing unit 141, an experimental platform execution unit 142, and an experimental platform analysis unit 143. The experimental platform editing unit can generate an experimental platform file 1250, register variables and key performance indicators, etc., and upload them to the experimental platform storage unit 1250. The experimental platform execution unit can execute the experimental platform file uploaded to the system operation unit 110. The experimental platform analysis unit can analyze the experimental platform result file 1266.

[0773] Log file 1283 in the output file 1280 of the model execution unit is the log of the operation system, corresponding to the log recorded by the job scheduler service unit 1230. Result data 1286 in output file 1280 may include model logs about the results of the model execution unit 130 executing a single model and production plan data about that single model. Log file 1263 in the output file 1260 of the experimental platform execution unit is the log of the operation system, corresponding to the logs about the experimental platform recorded by the job scheduler service unit 1230. Result data 1266 in output file 1260 may include logs about the results of multiple model execution units executing and production plan data about multiple models. As described above, the experimental platform unit 140 generates an experimental platform, registers at least one model type variable and at least one logical type variable, generates model variables, variable values, and key performance indicators, and generates experimental designs based on these.

[0774] The experimental platform unit 140 can upload the generated experimental design to the experimental platform storage unit 1250 as an experimental platform file through the deployment management service unit 1215 of the system operation unit 110.

[0775] The job service unit 1210 of the system operation unit 110 is the part that generates operation jobs, operation job cycles, etc., and the job scheduler service unit 1230 corresponds to the part that executes the operation jobs edited in the job service unit 1210 according to the execution conditions.

[0776] Furthermore, the experimental platform storage unit 1250 can store at least one software model and at least one logical set received from the model development unit 1100. Additionally, the deployment management service provided by the deployment management service unit 1215 can store files in the experimental platform storage unit 1250 according to the project path to which the deployed object belongs during deployment (upload). At this time, the deployment management service unit 1215 can provide historical management of the software models and logical sets according to the deployment time point when storing files.

[0777] The experimental platform files stored in the experimental platform storage unit 1250 can be used to execute experiments in the model execution unit 130 according to the execution commands of the experimental platform unit 140. That is, the model execution unit 130 can execute a single model uploaded in the system operation unit 110, and the experimental platform execution units of the experimental platform unit 140 can sequentially or simultaneously call multiple model execution units 130 based on the information recorded in the experimental platform.

[0778] Model execution unit 130 can execute operational tasks according to the execution instructions of job scheduler service unit 1230 to generate output file 1280. At this time, output file 1280 can be used as production planning data including output file 1286, and can also include log file 1283 about the execution status of operational tasks.

[0779] After the model execution unit 130 executes the experimental platform file, it passes the results to the experimental platform unit 140, which can generate an experimental platform output file 1266 as an output file 1260. Additionally, a log file 1263 about the execution of the experimental platform can also be generated.

[0780] Output file 1280 can be uploaded to the database 150 of the client's manufacturing process system 100. Furthermore, output file 1260, as the result of the experimental platform execution, can also be uploaded to the database 150 of the client's manufacturing process system. During upload, it can be uploaded as a model compressed file 1286 or an experimental platform compressed file 1266, or it can be uploaded directly without compression.

[0781] On the other hand, the output files 1260 and 1280 can provide results through the query interface included in the client manufacturing process system 100 or the external file service unit 1220, so that they can be queried in the model analysis unit 1300 or the experimental platform analysis unit of the experimental platform unit 140.

[0782] Figure 46 This is a flowchart illustrating the generation and execution of an experimental platform according to one embodiment.

[0783] As described above, the experimental platform unit 140 can generate an experimental platform file (S720). Specifically, the experimental platform file can be generated by the experimental platform editing unit within the configuration of the experimental platform unit 140. The experimental platform file corresponds to the object for editing or executing experiments, and its storage path can be set as a parameter.

[0784] Next, the experimental platform unit 140 can register at least one model type variable and at least one logical type variable in the generated experimental platform file (S730). For example... Figure 37 As shown, in order to conduct experiments through the experimental platform, at least one model and at least one piece of logic need to be registered to the experimental platform file. Furthermore, the registered at least one model and at least one piece of logic can correspond to variables.

[0785] Furthermore, the experimental platform unit 140 can generate data type variables, variable values, and key performance indicators (S740) in the experimental platform file. For example, a data type variable can correspond to a single cell. A single cell can be determined by the model's global variables and the keys present in the data schema. Furthermore, the variable value can be determined based on the type of a single data item. Additionally, for example, a data type variable can correspond to all input data tables of the model. For example, when registering an input data table variable, the variable value type can be a table type with the same schema as that input data table. In this case, the user can load internal data from the original data table of the model type variable or from an external file. Furthermore, at least one modification can be made to the input data table, and the modified table can be used as the variable value.

[0786] Key performance indicators (KPIs) are function information that processes the input and result data of the scenarios included in the experiment.

[0787] On the other hand, depending on the selection, the result refinement logic for each scenario or experiment can be set (S745). For example... Figure 40 As shown, when it is difficult to obtain the desired result through the pattern defined by the model development unit, the result can be used to refine the logic and create another pattern to obtain the result.

[0788] Furthermore, experiments can be designed based on the variables and key performance indicators (KPIs) registered in the experimental platform file (S750). For example, the registered variable information can include the aforementioned model type variables, logical type variables, data type variables, and variable values. As mentioned above, experimental design can include fixed experimental design and iterative experimental design. In both fixed and iterative experimental designs, the number of scenarios that can be executed simultaneously, i.e., the number of parallel executions, can be set.

[0789] Next, the designed experiment (S760) can be performed. (Refer to...) Figure 44 The experimental platform editing unit of the experimental platform unit can generate the designed experimental platform files and upload them to the system operation unit. The experimental platform execution unit can generate scenarios based on the information input in the generated experimental platform files and pass the files corresponding to each scenario as parameters to the model execution unit 130 for execution. Furthermore, the model execution unit can send result data to the experimental platform execution unit. In the case of a client-side manufacturing system, the experimental platform execution unit can send the result data to the system operation unit. Additionally, the system operation unit can upload the experimental execution results to the database or output results through the model analysis unit or the analysis unit of the experimental platform unit.

[0790] Utilizing an experimental platform makes it easier to execute complex tasks compared to running a single model. Furthermore, the platform allows for the automatic aggregation of results through key performance indicators and time savings through parallel execution.

[0791] Figure 47 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0792] The system receives at least one software model and at least one model logic generated from at least one data pattern and library engine set based on the client manufacturing production system from the local computing system (S770). As described above, the software model and logic set generated in the model development unit can be uploaded to the system operation unit through the server management unit.

[0793] Generate an experiment that includes at least one software model and at least one model logic (S780). As described above, generating the experiment includes generating the experimental platform file, registering variables and key performance indicators, and designing the experiment.

[0794] Based on the input data, the generated experiment is executed to provide at least one production plan data (S790). Specifically, the at least one production plan data may include an experiment summary and scenario results as the results of the executed experiment. For example, the input data may represent data on the status of the client manufacturing production system, including data with a specific time point, formatted and containing specific content. Furthermore, for example, in the experimental platform, at least a portion of the input data of the model execution unit 130 may be designated as variables and partially modified according to the experimental design. As described above, at least one designed experiment can be executed to provide production plan data including at least one experiment summary and at least one scenario result. In addition, refinement results obtained through refinement logic may be included in the experiment summary. For related information, please refer to the above. Figures 36 to 45 .

[0795] The scenario results can include output data such as the results of executing a single model and log data. In addition, the experiment summary can include the variable values ​​for each scenario, the key performance indicator values ​​calculated through scenario execution, the execution time and termination time, whether the execution was successful or not, and the execution order. Furthermore, the above experiment summaries and scenario results can be uploaded to a database or sent to the analysis unit of the model analysis unit or the experiment platform unit.

[0796] Reference Figure 29 An embodiment of a device that includes an experimental platform and provides digital production planning information is described below.

[0797] One embodiment of the apparatus for providing digital production planning information may include an input unit 410, a storage device 420, a memory 430, a processor 440, an output unit 450, and a user interface 460. For example, the apparatus for providing digital production planning information may correspond to a client's manufacturing system.

[0798] In the following embodiment, the device for providing digital production planning information is controlled according to user control and management based on user interface 460.

[0799] Input unit 410 receives from the local computing system a software model and a logic set generated based on at least one data pattern and library engine set of the client manufacturing system.

[0800] Storage device 420 can store pre-prepared reference information or received software models and logic sets. Storage device 420 may include volatile memory or non-volatile memory.

[0801] Memory 430 can store the outputs obtained during the execution of the software model, input data, library engine set and library engine, model execution unit and experimental platform unit disclosed above. The library engine set may include a production planning engine, which is a series of encapsulated function block files that generate production plans.

[0802] In one embodiment, processor 440 can generate an experimental platform including at least one software model and at least one model logic. Processor 440 generates an experimental platform file, registering at least one model type variable and at least one logic type variable in the generated experimental file. Furthermore, processor 440 can generate data type variables, variable values, and key performance indicators (KPIs) in the experimental platform file. Processor 440 can design experiments based on the variable information and KPI information. In this case, the designed experiments can constitute a fixed experimental design or an iterative experimental design. Detailed embodiments are already described. Figures 38 to 42 The above is disclosed. Furthermore, in one embodiment, the processor 440 can execute the generated experiment based on the input data to obtain production plan data as the result of the experiment. Relatedly, please refer to the above. Figures 36 to 45 .

[0803] In one embodiment, the processor 440 can execute the designed experiment to generate output files and log files about the execution status of the experimental platform job.

[0804] Output unit 450 provides production planning data based on the results of the designed experiment, so as to manage production or processes in the client system.

[0805] The following will disclose in detail an embodiment of providing production planning data through an experimental platform using a software model and logic set generated based on an installed library engine set.

[0806] As mentioned above, an experimental platform refers to a dataset containing the necessary information and experimental results required to conduct various experiments using at least one software model and at least one model logic. Furthermore, an experimental platform file is generated. After registering at least one model type variable and at least one logic type variable, along with related data type variables, variable values, and key performance indicators, experiments can be designed and executed within the generated experimental platform file.

[0807] At this point, experimental design can be based on the variables and key performance indicators (KPIs) registered in the experimental platform file. Furthermore, experimental design can include fixed-scale experimental designs that use pre-registered variables and combinations of variable values, and iterative experimental designs that use pre-registered variables as objects and determine variable values ​​through iterative phase logic. Fixed-scale experimental designs correspond to experimental designs performed under the condition that the number of all possible scenarios is pre-determined. Iterative experimental designs correspond to experimental designs using pre-registered variables as objects, but where the number of scenarios executed in each step and the variable values ​​continuously change.

[0808] In the disclosed embodiments, an example of designing iterative experiments using experimental platform units 140 and 1500 will be described.

[0809] Figure 48 This is a schematic diagram illustrating the configuration of an iterative experimental design based on a software model and a logic set, according to one embodiment.

[0810] An iterative experimental design may include at least one iterative phase logic and at least one iterative step. The iterative phase logic can be predefined. The iterative experimental design can be configured as a multi-objective function or a single-objective function. The iterative step corresponds to executing a scenario combination step that includes at least one scenario. In the case of an iterative experimental design, the iterative phase logic and the iterative step can be designed to be executed alternately until a termination condition is met.

[0811] The iterative logic for single-objective optimization can include a single-objective algorithm and logic for generating the next scenario. A single-objective algorithm corresponds to an algorithm designed to maximize or minimize a single objective. Examples of single-objective algorithms include Stochastic Gradient Descent (SGD), Genetic Algorithm (GA), Simulated Annealing (SA), Particle Swarm Optimization (PSO), Bayesian Optimization (BO), Cross Entropy Method (CEM), and Policy Exploration with Parmeter-based Exploration Gradient (PEPG). Furthermore, single-objective algorithms can include user-specified logic or user-written logic. Multi-objective algorithms are designed to optimize multiple objectives simultaneously. They can correspond to some conflicting objectives among multiple objectives, and their objective may be finding a Pareto front. For example, multi-objective algorithms may include NSGA (Non-dominated Sorting Genetic Algorithms), NSGA-II (Non-dominated Sorting Genetic Algorithms II), SPEA (Strength Pareto Evolutionary Algorithm), SPEA-II (Strength Pareto Evolutionary Algorithm II), etc. Furthermore, multi-objective algorithms may include user-specified logic or user-written logic.

[0812] As shown in the figure, the iterative experimental design includes experimental parameters 1650, variables and key performance indicators 1660, iterative stage logic 1670, and experimental termination conditions 1690, which correspond to the input values ​​of the iterative experimental design.

[0813] Experimental parameters 1650, as parameters concerning the experiment itself, correspond to options regarding experiment execution. For example, they may include the number of iterations, the number of parallel experiments, and whether to record data in a database. Variables and key performance indicators 1660 may include object variables and object key performance indicators used in the experiment. For example, variables may include all input / output data belonging to the software model, and at least one of the global variables. For example, variables may include the input interval of the demand information table, the feature weights used in the input decision agent, the quantity, the driving time, etc., but are not limited to these. Furthermore, for example, key performance indicators may include, but are not limited to, the total output of the production plan derived from the processing and production results, the number of delayed deliveries, the number of equipment changes, the average driving time, etc., in the production plan.

[0814] The iteration phase logic 1670 can be provided in the manner shown in the figure, i.e., by setting the parameters and functions used in the logic, or it can be provided as a plug-in that pre-implements the above single / multi-objective algorithm.

[0815] The iteration phase logic 1670 may include logic parameters 1673, an initialization function 1676, an update function 1679, and a next scenario combination generation function 1682. Optionally, it may also include a logic log recording / storage function 1685. The functions included in the iteration phase logic 1670 are not limited to these; functions can be added or removed according to user settings.

[0816] In the iterative phase logic 1670, the initialization function 1676 is called first, followed by the next scene combination generation function 1682, and then the update function 1679. However, the order of function calls is not limited to this; after calling the update function 1679, the next scene combination generation function 1682, etc., can be called, and the order of function calls can be changed.

[0817] Furthermore, logic parameter 1673, various functions and their contents, variables, and performance indicators correspond to the input values ​​of iteration phase logic 1670. The next scenario combination generated in iteration phase logic 1670 and the results obtained after executing the logic log recording / storage function correspond to the intermediate or final output values ​​of iteration phase logic 1670. Additionally, when executing multiple iteration phase logics, the output value of the previous iteration phase logic can be used as the input value of the subsequent iteration phase logic.

[0818] In both single-objective and multi-objective algorithms, common logical parameters include a random seed and a random stream. Furthermore, depending on the type of algorithm, various parameters may exist. For example, in the case of PEPG, these may include the shape of the distribution, distribution parameter values ​​for the variables, and the learning rate for each parameter. Additionally, for example, genetic algorithms may include factors such as the population size, crossover rate, and mutation rate for each generation.

[0819] Initialization function 1676 initializes the input logic parameters. For example, when using PEPG logic, initialization function 1676 can use the received distribution parameter values ​​and random flow to generate a distribution for the entire iteration phase. Update function 1679 updates the logic parameters. For example, when using PEPG logic, update function 1679 can include updating the variable distribution using the results of the previous iteration phase (the scenario variable values ​​and key performance indicator values ​​of the previous phase), thereby creating a distribution that increases the probability of higher performance indicator values. Next scenario combination generation function 1682 generates the next scenario combination based on the updated logic parameters. For example, when using PEPG logic, next scenario combination generation function 1682 can include logic that symmetrically extracts variable values ​​from the updated distribution and assigns them as the variable values ​​for the scenarios executed in the next iteration phase. Logic log recording / storage function 1685 generates records of intermediate process outputs, final outputs, etc., generated during the logic-driven iteration phase. For example, it can record the initialization log of logic parameters, the update log of logic parameters, or the log of the generated next scenario combination. According to one embodiment, in the case of PEPG logic, the final distribution can be recorded in the form of a log, while in the case of genetic algorithms, the population gene change trend at each stage can be recorded in the form of a log.

[0820] The experiment termination condition 1690 is the condition for terminating the experiment in the iterative experimental design, and it can be preset. For example, the experiment termination condition 1690 may include reaching a set number of iterations, reaching a set execution time, reaching a target key performance indicator value, etc.

[0821] Figure 49 This is a schematic diagram illustrating an iterative experimental design based on a software model and a set of logic, according to one embodiment.

[0822] When deciding to use an iterative experimental design, the logic, variables, and initial parameters for the iteration phase can be set (S805). For example, setting the initial parameters corresponds to executing the initialization function 1676 mentioned above.

[0823] Furthermore, the variables set in step S805 can correspond to at least one of the above-mentioned model type variables, logical type variables, and model data variables.

[0824] Furthermore, the iterative phase logic can include first scenario combination information. Here, first scenario combination information refers to the combination information required for the subsequently generated scenario files. For example, when deciding to use the PEPG algorithm logic in a single-objective algorithm, it can include initial and average values ​​of parameters (mean, variance) of the target variable distribution, the learning rate of the variance, the corresponding model type variable, the logic type variable, and key performance indicators, based on which the first scenario combination is generated.

[0825] Next, the first iteration stage logic (S810) can be executed. Here, executing the first iteration stage logic corresponds to executing the update function 1679 or the next scenario combination generation function 1682 described above. Furthermore, the execution result of the first iteration stage logic may include scenario file information for the next iteration stage. For example, the scenario file information may include a combination of variable values, key performance indicators, etc.

[0826] After executing the logic of the first iteration phase, it can be determined whether the experiment termination condition (S815) is met. As mentioned above, the experiment termination condition may include, but is not limited to, reaching the set number of iterations, experiment execution time, achievement of key performance indicator target values, etc.

[0827] If the experiment termination conditions are met, the experiment terminates (S835), and the experiment results, including scenario results and an experiment summary, are obtained. For example, scenario results may include the result data and log data of each individual scenario in the multiple scenarios included in the experiment. In addition, the experiment summary may include the variable values ​​of each scenario, the key performance indicator values ​​calculated through scenario execution, the execution time and termination time, whether the execution was successful or not, the execution order, etc.

[0828] If the experiment termination condition is not met, a scenario file for the first iteration stage is generated based on the results of the first iteration stage logic (S820). Generating the scenario file for the first iteration stage involves generating at least one scenario file to be executed during the iteration stage, based on the scenario combination information from step S810. Here, the first iteration stage corresponds to the step of executing at least one scenario file generated based on the results of the first iteration stage logic after executing the first iteration stage logic. Furthermore, the results obtained from executing the first iteration stage, such as variable values ​​and key performance indicators, can be passed as parameters to the second iteration stage logic for execution.

[0829] Furthermore, variables used in the iterative phases of an iterative experimental design can be pre-set, but their values ​​can be determined based on the iterative phase logic executed in the previous iterative phase. That is, variables used in at least one iterative phase of the iterative experimental design can be pre-set, but their values ​​are determined based on the result of the iterative phase logic executed in the previous iterative phase, thus corresponding to changing values. Additionally, the variables used in at least one iterative phase and their values ​​can also be set in the iterative phase logic executed in the previous iterative phase.

[0830] Next, all scenes within the first iteration phase can be executed (S825). Relatedly, the experimental platform execution unit can command the scene files to be executed by the model execution unit. For example, the experimental platform execution unit can command the execution of all scene files within a single model execution unit. Alternatively, the experimental platform execution unit can assign each scene file to a separate model execution unit, with commands executed through multiple model execution units. Furthermore, all scenes within the first iteration phase can be executed n times in parallel, based on the set parallel execution count.

[0831] When executing a scenario, key performance indicator (KPI) values ​​are calculated, stored in the database, and then passed to the second iteration stage logic (S830). At this point, the second iteration stage logic can be determined based on the scenario results executed in the first iteration stage. Alternatively, the second iteration stage logic can be set independently or dependent on the scenario results executed in the first iteration stage. Furthermore, the number of scenarios in each iteration stage can be changed according to the iteration stage logic.

[0832] Next, after executing the second iteration stage logic, if the termination condition is not met, the second iteration stage is executed again, and the subsequent third iteration stage logic continues. That is, steps S810 to S830 above can be executed iteratively, and the experiment terminates when the termination condition is met. At this time, when executing step S810, the update function 1679 of the above iteration stage logic can be executed.

[0833] In addition, the above Figure 48 The logical log recording / storage function can be called in all steps of this embodiment. When called in each step, it can record / store logs about different information. For example, when the logical log recording / storage function is called in each step, it can record / store logs of intermediate outputs and final outputs in each step.

[0834] Figure 50 This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0835] The system receives at least one software model and at least one model logic generated from at least one data pattern and library engine set based on the client manufacturing production system from the local computing system (S850). As described above, the software model and logic set generated in the model development unit can be uploaded to the system operation unit through the server management unit.

[0836] Generate an experimental platform file for designing experiments. This file includes at least one software model and at least one model logic (S860). Generating experiments refers to generating the experimental platform file, registering variables and key performance indicators, and setting variable values, etc., to design experiments involving multiple scenarios. At this point, such as... Figure 48 and Figure 49 As shown, when generating an iterative experimental design, at least one iterative stage logic can be executed, forming a structure in which at least one iterative step is executed iteratively. The at least one iterative step can include multiple scenarios. The result of a scenario in one iterative stage can be used as input to the logic of the next iterative stage.

[0837] Based on the input data, an experiment including iterative experimental logic and at least one scenario is executed to provide at least one production plan data (S870). Specifically, as follows: Figure 48 and Figure 49 The experiment involves executing an iterative experimental design, performing at least one iterative step and at least one iterative experimental logic, and terminating the experiment when a termination condition is met. Upon termination, at least one production plan data point can be generated and stored in a database, or some files can be deleted. At least one production plan data point can serve as the experimental result, including an experimental summary and scenario results.

[0838] Reference Figure 29 An embodiment of a device that includes an experimental platform and provides digital production planning information is described below.

[0839] One embodiment of the apparatus for providing digital production planning information may include an input unit 410, a storage device 420, a memory 430, a processor 440, an output unit 450, and a user interface 460. For example, the apparatus for providing digital production planning information may correspond to a client's manufacturing system.

[0840] In the following embodiment, the device for providing digital production planning information is controlled according to user control and management based on user interface 460.

[0841] Input unit 410 receives from the local computing system a software model and a logic set generated based on at least one data pattern and library engine set of the client manufacturing system.

[0842] Storage device 420 can store pre-prepared reference information or received software models and logic sets. Storage device 420 may include volatile memory or non-volatile memory.

[0843] Memory 430 may store outputs obtained during the execution of the software model, input data, library engine set and library engine, model execution unit and experimental platform unit disclosed above. The library engine set may include a production planning engine, which is a multi-encapsulated functional block file that generates production plans. In one embodiment, memory 430 may store intermediate and / or final outputs related to the iteration phase logic, as well as logs related to this.

[0844] In one embodiment, processor 440 can generate an experimental platform file including at least one software model and at least one model logic. Processor 440 generates the experimental platform file and registers at least one model type variable and at least one logic type variable in the generated experimental file. Furthermore, processor 440 can generate data type variables, variable values, and key performance indicators (KPIs) in the experimental platform file. Processor 440 can design experiments based on the variable information and KPI information.

[0845] At this point, the designed experiment can be either a fixed experimental design or an iterative experimental design. An iterative experimental design can include iterative phase logic and iterative steps. For example... Figure 48 and Figure 49 The processor 440 can set multi-objective functions or single-objective functions for the iteration stage logic and set variable values ​​according to the set algorithm.

[0846] Furthermore, in one embodiment, the processor 440 can execute the generated experiment based on the input data to obtain production plan data as the experimental result. When executing the iterative phase logic, the processor 440 can generate scenario combination information for the next iteration step and generate a scenario file. Additionally, the processor 440 can execute the generated scenario file and execute the next iteration phase logic based on the scenario results.

[0847] In one embodiment, processor 440 can execute the designed experiment to generate output files and log files regarding the execution status of the experimental platform. After executing the iterative phase logic, processor 440 can terminate the experiment and obtain the experimental results when the termination condition is met. The experimental results, as production planning data, may include an experimental summary and scenario results.

[0848] Output unit 450 provides production planning data based on the results of the designed experiment, so as to manage production or processes in the client system.

[0849] As described above, the software model and logic set acquired (developed) in the model development unit 1100 can be uploaded to the system operation unit 110. The system operation unit 110 can generate operation jobs based on the uploaded software model and logic set, and set the conditions for executing the operation jobs. At this time, the operation job is the task required to execute the software model and logic set, corresponding to the work unit executed by the system operation unit 110.

[0850] When executing a single software model is insufficient to complete a task, multiple software models and external logic need to be introduced to automatically execute multiple tasks. When using multiple software models or logic, this can be achieved through an experimental platform unit 140 that includes multiple experiments. Relatedly, the system operation unit 110 can generate operational tasks for the experimental platform and set conditions for executing these tasks.

[0851] As described above, the system operation unit 110 includes a variety of service units, which may include a license service unit 1205, a job service unit 1210, a deployment management service unit 1215, an external file service unit 1220, a job scheduler service unit 1230, etc.

[0852] The job service unit 1210 of the system operation unit 110 can generate operation jobs. At this time, an operation job is a job required to execute the software model and logic set. Operation jobs can include three types: sending emails, executing programs, and executing models. In addition, depending on user settings or system settings, various other execution jobs can be added, such as experimental platform execution jobs and dynamic operation logic execution jobs. Furthermore, operation jobs correspond to the job units executed by the job scheduler service unit 1230.

[0853] Furthermore, the job service unit 1210 can set execution conditions for operational jobs. Here, execution conditions correspond to the execution cycle, dependencies between operational jobs, etc. That is, an operational job refers to a work unit to be executed, and execution conditions refer to detailed conditions such as the execution cycle and dependencies of the operational job. One or more execution conditions can be generated for an operational job, and one or more second execution conditions can be generated for a first execution condition. The set execution conditions can be stored in the system operation unit.

[0854] The following section will describe how operational tasks related to the experimental platform are generated and executed in the system operation unit 110.

[0855] Figure 51 This is a schematic diagram illustrating the setting of operational tasks in a system operation unit according to one embodiment.

[0856] Specifically, Figure 51This illustrates an example of using an experimental platform to generate deployment logic monitoring and operation jobs and set execution conditions for them. Figure 51 This is one example of an operational task related to the experimental platform. In addition, various operational tasks related to the experimental platform can be generated.

[0857] In this embodiment, although the deployment logic monitoring operation of the experimental platform is shown, it may also include the operation of the data collection experimental platform, the operation of the data evaluation experimental platform, etc. The experimental platform is written based on a given goal and is not limited to this.

[0858] As shown in the figure, the deployment logic monitoring operation job 2010 can be generated by the job service unit 1210. Here, the deployment logic monitoring operation job 2010 corresponds to an operation job that monitors whether production plan results, execution time, etc., change during logic deployment. The monitoring results can be used for deployment decisions. For example, when deploying new logic, if the results are the same but the execution time increases sharply, making it difficult to use, a rollback to the previous version of the logic may be necessary. Furthermore, for example, when deploying new logic, if improved results are obtained and the execution time is shortened, it is necessary to set the system to actively use the new version of the logic.

[0859] Furthermore, related to the deployment logic monitoring operation 2010, an experimental platform consisting of fixed-scale experimental designs can be set up. For example, a fixed-scale experiment can be designed to select the latest model on the operations server or N models specified by the user as model variable values, select M latest logics as logic variable values, and execute all combinations. Additionally, for example, the key performance indicators (KPIs) for a fixed-scale experimental design can be selected as indicators that can determine the execution time, the number of rows in the result table, the sum of specific columns, improved production planning indicators, etc., but are not limited to these.

[0860] At least one execution condition can be set for an operational task. For example, execution conditions may include periodic conditions, dependency conditions, etc. Furthermore, periodic conditions or dependency conditions can be set among multiple execution conditions. In addition, even if execution conditions are set, it may be further possible to include setting whether the program is actually activated / deactivated.

[0861] As shown in the figure, the deployment logic monitoring operation 2010 corresponds to the period condition 2020, which is the condition 2025 for executing monitoring according to the preset period. For example, the preset period can be set in various ways, such as immediately after the deployment logic, 5 minutes after the deployment logic, or 1 hour after the official deployment schedule.

[0862] Furthermore, a dependency condition 2030 can be generated (set) for the periodic condition 2020. In one embodiment, it can be configured to execute the first dependency condition 2032 upon successful execution of the periodic condition 2020. In this embodiment, the first dependency condition 2032 is configured to perform a judgment operation upon successful execution of monitoring according to the preset periodic condition. When executing the first dependency condition 2032, a judgment script job 2042 can be executed. Here, the judgment script job corresponds to a job that judges whether there are any anomalies in the deployed logic.

[0863] Furthermore, at least one dependency condition can be set for the first dependency condition 2032. In one embodiment, the second dependency condition 2034 can be executed when the first dependency condition 2032 succeeds. In this embodiment, the second dependency condition 2034 is set to send a success email upon successful verification. When executing the second dependency condition 2034, a success email sending job 2044 can be executed. Here, the success email sending job corresponds to sending an email indicating that no exceptions have occurred in the deployment logic.

[0864] Furthermore, in one embodiment, the third dependency condition 2036 can be executed if the first dependency condition 2032 fails. In this embodiment, the third dependency condition 2036 is configured to send a failure email upon failure. When executing the third dependency condition 2036, a deployment cancellation script job 2046 can be executed. Here, the deployment cancellation script job corresponds to the logic of canceling a deployment, preventing further deployment; it can also be configured to roll back to a previous version. Additionally, when executing the deployment cancellation condition 2036, the failure email sending condition 2038 can be executed. In this case, when executing the failure email sending condition 2038, a failure email sending job 2048 can be executed.

[0865] Related to the Deployment Logic Monitoring Operation Job 2010, although not illustrated, additional periodic conditions and dependencies can be set. Furthermore, even if periodic conditions and dependencies are already set, the operation job can be executed only after determining its activation / deactivation status. In addition, related to the experimental platform, not only the Deployment Logic Monitoring Operation Job 2010 can be set, but also various other operation jobs related to the execution of the experimental platform can be set.

[0866] Figure 52 This is a schematic diagram illustrating, according to one embodiment, the execution of an operational operation using a fixed-scale experimental design in an operational environment.

[0867] Specifically, Figure 52 This explains that in system operation unit 110, the above... Figure 51This is an example of a deployment logic monitoring operation job 2010. First, an experimental platform operation job 2110, a script execution operation job 2140, and an email sending operation job 2160 can be generated (set up). In this example, the experimental platform operation job 2110 can correspond to... Figure 51 The deployment logic monitoring operation job 2010 and script execution operation job 2140 can correspond to Figure 51 The interpretation script job 2042 or the deployment cancellation script job 2046, and the email sending operation job 2160 can correspond to Figure 51 Successful email sending job 2044 or failed email sending job 2048.

[0868] In this embodiment, when deciding on the deployment object logic 2100, it can be uploaded to the historical management storage unit 1270 of the system operation unit through the deployment service 1215 of the system operation unit 110. Here, the historical management storage unit 1270 can store software models and logic sets required for generating or setting up operational tasks in the system operation unit, and also stores files related to the operational tasks. At this time, the deployment object logic 2100 can be determined by the user or according to preset rules. For example, the deployment object logic 2100 can be determined by the model development unit. Furthermore, for example, in a cloud computing system, the deployment object logic can be pre-implemented and uploaded. Database 150 is the database of the client system and can include an operational model storage area and a logic storage area. Furthermore, the operational model storage area includes multiple software models, and the logic storage area includes multiple logic sets.

[0869] The N latest software models, M latest logic sets, and deployment object logic 2100 included in database 150 can be extracted as deployment logic monitoring job data 2105. For example, the experimental platform editing unit can select the N latest software models in database 150 as model variable values, and select the M latest logic sets and 1 deployment object logic 2100 as logic variable values ​​to complete a fixed-scale experimental design, thereby enabling all scenario combinations to be executed.

[0870] The experimental platform operation task 2110 may include a deployment logic monitoring experimental platform 2115, an experimental platform execution unit 2120, and a deployment logic monitoring experimental summary 2130. Relatedly, the deployment logic monitoring experimental platform 2115, generated by the experimental platform editing unit, can be set as an operational task of the experimental platform of the system operation unit. The deployment logic monitoring experimental platform 2115 corresponds to the deployment logic monitoring experiment 2125, which is set to be executed via commands from the experimental platform execution unit 2120, including N*(M+1) scenario combinations. In this embodiment, the key performance indicators (KPIs) for the fixed-scale experimental design of the deployment logic monitoring experiment 2125 can be selected as indicators that can determine the execution time, the number of rows in the result table, the sum of specific columns, and improved production plan indicators, etc.

[0871] The script execution operation job 2140 can be set with periodic conditions or dependencies related to the experimental platform operation job 2110, and can include deployment logic judgment script 2145, deployment cancellation script 2155, etc. Furthermore, the email sending operation job 2160 can be set with periodic conditions or dependencies related to the experimental platform operation job 2110, and can include tasks such as sending evaluation result emails 2165.

[0872] Before executing the operational task, a procedure can be performed to determine whether to activate the set periodic conditions or dependency conditions. In this embodiment, it is assumed that all conditions related to the experimental platform operational task 2110 are set to active.

[0873] When the job scheduler service unit 1230 executes the experimental platform operation job 2110, as described above, the deployment logic monitoring experiment 2125 set in the deployment logic monitoring experimental platform 2115 is executed as a fixed-scale experiment, and a deployment logic monitoring experiment summary 2130 is output. Here, the deployment logic monitoring experiment summary 2130 may include variable values ​​for each scenario, key performance indicator values ​​corresponding to the design purpose of the deployment logic monitoring experimental platform calculated through scenario execution, such as the execution time, the number of rows in the result table, the sum of specific columns, and other results.

[0874] Relatedly, the experimental platform execution unit 2120 can correspond to the experimental platform execution unit 143 of the aforementioned experimental platform unit 140. Furthermore, the experimental platform execution unit 143 can execute multiple scenarios included in the deployment logic monitoring experiment 2125 according to the execution command, and the experimental platform execution unit 143 can generate a deployment logic monitoring experiment summary 2130.

[0875] The job scheduler service unit 1230 can execute the deployment logic judgment script 2145 in the operation job 2140 based on the deployment logic monitoring experiment summary 2130. Furthermore, during deployment logic judgment, a deployment logic evaluation result 2150 can be obtained. Although not illustrated, when executing the deployment logic experiment platform 2110, in addition to the deployment logic monitoring experiment summary 2130, results for each scenario can also be output. For example, scenario results regarding one of the N latest software models and the deployment object logic can be output for judgment of the deployment logic. Furthermore, for example, the deployment logic judgment script can make the following judgment: if the number of rows in the table in the deployment logic monitoring experiment summary 2130 and the scenario result is the same as the number in the previous operation logic version, and the execution time is within ±10%, then the deployment is approved; otherwise, the deployment is canceled.

[0876] If the deployment logic evaluation is successful, the evaluation result email sending 2165 in email sending operation job 2160 can be executed. For example, if the deployment logic evaluation is successful, the success email sending as described above can be executed.

[0877] When the deployment logic evaluation fails, the deployment cancellation script 2155 in operation job 2140 can be executed, and the evaluation result email sending 2165 in email sending operation job 2160 can be executed. When executing deployment cancellation script 2155, deployment logic removal 2170 can be executed to remove deployment object logic 2100. Furthermore, when the deployment logic evaluation fails, the above-described actions can be performed. Figure 51 The email failed to send 2048.

[0878] Unlike this embodiment, the evaluation result email sending 2165 can also be configured to send an email only when an anomaly occurs in the evaluation result. Furthermore, unlike this embodiment, when executing the deployment cancellation script 2155, in addition to removing the deployment logic 2170, it is also possible to roll back to a previous version of the logic. Moreover, when executing the deployment cancellation script 2155, it is possible to roll back to the version of the logic with the optimal key performance indicator value based on the deployment logic monitoring experiment summary 2130 and / or the deployment logic evaluation result 2150.

[0879] Figure 53 This is a flowchart illustrating the setup and execution of operational tasks for an experimental platform according to one embodiment.

[0880] As described above, the generated experimental platform file can be uploaded (S910). Specifically, the experimental platform file generated through the experimental platform editing unit can be uploaded to the system operation unit. The experimental platform file refers to a file that includes at least one model type variable, at least one logical type variable, data type variable, variable values, key performance indicators, etc.

[0881] An experimental platform operation job (S920) can be generated. Specifically, after completing the data source connection for the software models and logic sets used in the experimental platform, an operation job can be generated. For example, in the case of the deployment logic monitoring operation job described above, the data source connection involves inputting information about the storage area that stores the latest software models and logic sets. Here, the information about the specified storage area may include connection information of the system where the software models and logic sets, which are the variable values ​​of the experimental platform, reside, the path to the historical management storage area, etc. As described above, an experimental platform that includes a combination of scenarios with multiple software models and multiple logic sets can be set up as an experimental platform operation job.

[0882] Next, execution cycles and inter-job dependencies can be set for the generated operational jobs (S930). As described above, at least one execution condition can be set for an operational job. Execution conditions may include cycle conditions and dependency conditions. Furthermore, before the operational job is executed, a procedure can be included to determine whether to activate the set execution conditions. For example, an experimental platform operational job can be set in association with a script execution operational job or an email sending operational job.

[0883] Furthermore, operational tasks can be executed according to the set execution cycle and dependencies (S940). For example, when there is an execution instruction from the job scheduler service unit, the experimental platform execution unit can send an execution command to the model execution unit, which can then execute the scenario combination included in the experimental platform operational tasks. Additionally, when the model execution unit terminates, the experimental platform execution unit can analyze the scenario results, calculate key performance indicator values, and refine the results. Figure 52 As shown, when performing experimental platform operation tasks, related scripts can be executed to perform operation tasks and email sending operation tasks according to conditions.

[0884] Results obtained through operational tasks can be uploaded to the database (S950). For example, the generated results may include production plans, operational system logs, etc. Furthermore, results obtained through operational tasks on the experimental platform can be queried via the client system's user interface or the experimental platform's analysis unit.

[0885] Reference Figure 45 An example of setting up and executing experimental platform operation tasks according to one embodiment is described below.

[0886] As described above, the experimental platform editing unit 141 of the experimental platform unit 140 can generate experimental platform files. As mentioned above, the experimental platform can include a set of information such as variables, key performance indicators, experimental design, experimental execution and database connection information, result refinement data patterns and logic, etc. Here, experimental design can include fixed-scale experimental design and iterative experimental design. Experimental execution is the process of executing scenarios based on the information included in the experimental design and outputting results.

[0887] The generated experimental platform files can be uploaded and stored in the experimental platform storage unit 1250 through the deployment management service unit 1215 of the system operation unit 110.

[0888] The job service unit 1210 can generate experimental platform operation jobs based on experimental platform files. Furthermore, the job service unit 1210 can set execution conditions such as execution cycles and dependencies for the experimental platform operation jobs. The job scheduler service unit 1230 can execute the operation jobs according to the execution conditions set in the job service unit 1210.

[0889] According to the commands of the job scheduler service unit 1230, the experimental platform execution unit 143 can execute the experiment. That is, the experimental platform execution unit 143 executes multiple scenario combinations included in the experimental platform file by calling the model execution unit 130.

[0890] The results of the experimental platform file executed in model execution unit 130 are passed to experimental platform unit 140, which can generate an experimental platform output file 1266 as an output file 1260 and a log file 1263 about the execution of the experimental platform. The experimental platform output file 1266 includes logs about the results of executing the experimental platform file and production plan data about multiple models.

[0891] The output file 1260 can be uploaded to the database 150 of the client manufacturing process system 100. During upload, it can be uploaded as a compressed experimental platform file 1266, or it can be uploaded directly without compression. Furthermore, the output file 1260 can be queried through the query interface included in the client manufacturing process system 100, or the results can be provided through the external file service unit 1220 for querying in the model analysis unit 1300 or the experimental platform analysis unit of the experimental platform unit 140.

[0892] By operating the aforementioned experimental platform, information obtained from the combination / processing of results from multiple scenarios can be easily acquired. This is because the processes of automatically generating scenarios based on variable values, executing them in parallel, and calculating / merging key performance indicators are all automated.

[0893] Figure 54This is a flowchart illustrating a method for providing digital production planning information according to one embodiment.

[0894] The system receives at least one software model and at least one model logic generated from at least one data pattern and library engine set based on the client manufacturing system from the local computing system (S960). As described above, the software model and logic set generated in the model development unit can be uploaded to the system operation unit through the server management unit.

[0895] Generate an operational task (S970) for an experimental platform that includes at least one software model and at least one model logic. For example... Figure 51 and Figure 52 The system operation unit can generate experimental platform operation jobs based on the uploaded experimental platform files. Furthermore, it can also generate execution conditions for these jobs. These execution conditions can be set to include periodic conditions and dependency conditions.

[0896] Based on the generated operational tasks, experiments are executed using the input data to provide at least one production plan data point (S980). This production plan data point may include an experiment summary and scenario results as the outcome of the executed experiments. Furthermore, if refinement logic is configured, the refinement results may be included in the experiment summary. The experiment summary may include variable values ​​for each scenario, key performance indicator values ​​obtained through scenario execution, execution / termination times, success or failure of execution, execution order, etc. Additionally, scenario results may include output data such as result data from executing a single model and log data.

[0897] Furthermore, the input data represents the status of the client's manufacturing system and can include data at a specific point in time with a certain format and content. As mentioned above, the experimental platform unit generates results including production plan information and operation system logs based on the execution results of the model execution unit, and can upload them to the client system's database.

[0898] Reference Figure 29 An embodiment of a device that includes an experimental platform and provides digital production planning information is described below.

[0899] One embodiment of the apparatus for providing digital production planning information may include an input unit 410, a storage device 420, a memory 430, a processor 440, an output unit 450, and a user interface 460. For example, the apparatus for providing digital production planning information may correspond to a client's manufacturing system.

[0900] In the following embodiment, the device for providing digital production planning information is controlled according to user control and management based on user interface 460.

[0901] Input unit 410 receives from the local computing system a software model and a logic set generated based on at least one data pattern and library engine set of the client manufacturing system.

[0902] Storage device 420 can store pre-prepared reference information or received software models and logic sets. Storage device 420 may include volatile memory or non-volatile memory.

[0903] Memory 430 may store outputs obtained during the execution of the software model, input data, library engine set and library engine, model execution unit and experimental platform unit disclosed above. The library engine set may include a production planning engine, which is a multi-encapsulated function block file that generates production plans. In one embodiment, memory 430 may store intermediate and / or final outputs related to the experimental platform operation.

[0904] In one embodiment, processor 440 can generate operational jobs for an experimental platform, including at least one software model and at least one model logic. Processor 440 can set execution cycles and dependencies between jobs for the generated operational jobs. As described above, the job service unit can be associated with the operational jobs of the experimental platform to generate (set) at least one of the scripts for executing operational jobs and sending emails. Furthermore, processor 440 can perform experiments based on the generated operational jobs and input data to obtain at least one production plan data point. For more information, please refer to the above. Figures 51 to 53 .

[0905] Output unit 450 provides production planning data based on the results of the designed experiment, so as to manage production or processes in the client system.

[0906] As mentioned above, an experimental platform refers to a data set of necessary information and experimental results required to conduct various experiments using at least one software model and at least one model logic.

[0907] Editing, execution, and analysis related to the experimental platform can be performed through the experimental platform user interface. In the disclosed embodiments, examples of performing experimental platform-related tasks through the experimental platform user interface will be described. Furthermore, the term "button" related to the exp...

Claims

1. A method for providing digital production planning information, comprising: Provide clients with an extensible software model and logical set for generating production planning data; Receives first input data including reference information of the manufacturing system and second input data for parameter setting; as well as Based on the first input data and the second input data, at least one of the following is performed on at least one strategy: learning, evaluation, operation, deployment, and management, in order to provide production planning data to the client.

2. The method according to claim 1, wherein, The step of providing production planning data includes: applying a list of decision elements and actions to at least one of the strategy function and value function to make a final decision for strategic operation.

3. The method according to claim 1, wherein, The step of providing production planning data includes: preprocessing and learning the learning data for strategy learning to generate at least one of a learned policy function and a learned value function.

4. The method according to claim 3, wherein, The learning data includes at least one of the following: decision elements, action list, performance index information, reward information, decision time point, and final decision.

5. The method according to claim 1, wherein, The step of providing production planning data includes: in order to utilize the dynamic operation of reinforcement learning, performing policy evaluation on at least one of the policy function and value function, and generating the optimal policy scenario.

6. The method according to claim 5, wherein, It further includes: performing a policy evaluation on at least one of the policy function and the value function, and passing a relearning command.

7. The method according to claim 1, wherein, The steps for providing production planning data include: Receive the second input data to set decision-related parameters and initialize the system; At the decision-making time point, based on the system's state characteristic values ​​and action characteristic values, decision elements and an action list are extracted; and Based on the extracted decision elements and the action list, at least one of the action probability and state value is calculated.

8. The method according to claim 1, wherein, The steps for providing production planning data include: Generate learning data; and The generated learning data is used to learn a policy to provide at least one of a learned policy function and a learned value function.

9. The method according to claim 8, wherein, The steps for generating learning data include: performing at least one simulation to obtain at least one of decision element values, action list, reward value, and performance index value, thereby accumulating learning data.

10. The method according to claim 9, wherein, Further includes: Determine whether the conditions specified by the first user are met; and If the conditions specified by the first user are not met, at least one simulation is performed to obtain at least one of the decision element values, action list, reward value, and performance index value, thereby accumulating learning data.

11. The method according to claim 10, wherein, The step of providing at least one of the learned policy function and the learned value function includes: If the conditions specified by the first user are met, the generated learning data is used to learn and store the policy function. Determine whether the conditions specified by the second user are met; and If the second user-specified condition is met, the storage policy is implemented after the learning process ends.

12. The method according to claim 1, wherein, The steps for providing production planning data include: Obtain at least one model for evaluating the at least one strategy; The at least one strategy and the at least one model obtained are evaluated; and Deploy operational scenarios and strategies based on the completed assessment of the strategies and models.

13. The method according to claim 12, wherein, Further includes: Based on the completed evaluation strategy and model, determine whether further learning is needed; and Based on the judgment result, if the conditions specified by the third user are met, at least one strategy is learned again.

14. An apparatus for providing digital production planning information, comprising: Storage device, used to store data; Memory, which is used to store the software-related library engine set; as well as A processor for executing the software; The processor provides the client with an extensible software model and logic set for generating production plan data; and receives first input data including baseline information of the manufacturing production system and second input data for parameter setting. Based on the first input data and the second input data, at least one of the following is performed on at least one strategy: learning, evaluation, operation, deployment, and management, in order to provide production planning data to the client.

15. A storage medium having stored thereon computer-executable software, the software being configured to: provide a client with a scalable software model and logic set for generating production planning data; receive first input data including baseline information about a manufacturing production system and second input data for parameter settings; and, based on the first input data and the second input data, perform at least one of learning, evaluating, operating, deploying, and managing at least one strategy to provide production planning data to the client.

Images