이하의 개시는, 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획을 제공하는, 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체를 제공하는 것이다.The following disclosure provides a device for providing digital production plan information, a method for providing digital production plan information, and a storage medium storing computer-executable software for providing a digital production plan.
제품을 생산하는 제조시스템에는 여러 가지 작업 단계들이 포함되고 여러 가지 자원들이 포함된다. 제품에 따라 여러 가지 복잡한 단계들이 포함될 수 있고, 제품에 따라 고가의 자원이 필요할 수 있으며, 각 단계마다 최적의 작업들이 요구된다.Manufacturing systems that produce products involve multiple work steps and resources. Depending on the product, multiple complex steps may be involved, expensive resources may be required, and optimal operations are required at each step.
예를 들면, 반도체, 디스플레이, 이차전지, 자동차, 철강, 가전, 바이오 등의 첨단 분야에서는 매우 고가의 자원이 투입되기 때문에 공정의 실패를 줄이고 효율성을 높이는 것이 제품의 경쟁력을 가지도록 하는 요소가 된다. 공정을 담당하는 장비의 가격이 매우 높거나 제조 시스템의 물리적 공간제약으로 장비를 추가로 투입할 수 없는 경우가 많았다. 장비의 증설 없이 복잡한 제조 공정에서 좋은 의사결정을 내리면 생산 효율을 높일 수 있다.For example, in cutting-edge fields like semiconductors, displays, secondary batteries, automobiles, steel, home appliances, and biotechnology, where extremely expensive resources are invested, reducing process failures and increasing efficiency are crucial for product competitiveness. Often, the high cost of equipment responsible for these processes, or physical space constraints within the manufacturing system, prevented the deployment of additional equipment. Without additional equipment, making sound decisions in complex manufacturing processes can improve production efficiency.
이러한 작업 단계들을 최적화하고 자원의 사용 효율성을 높이고 생산성을 증가시키기 위해 여러 가지 방안들이 개발되고 있다.Several methods are being developed to optimize these work steps, increase resource efficiency, and increase productivity.
그 중 제조시스템을 디지털 모델링을 통해 구현하고 제조시스템 상의 문제점을 해결하는 방식이 늘어나고 있다. 현실에서 의사결정은 비가역적이기 때문에 이러한 디지털 모델링을 통해 의사결정과 생산 효율을 높이는 문제를 해결하는 방안이 제안되고 있다 .Among these, methods for implementing manufacturing systems through digital modeling and resolving manufacturing system issues are increasing. Because decision-making in the real world is irreversible, digital modeling is being proposed as a way to address these issues, improving decision-making and production efficiency.
최근에는 인공지능 기술의 발달로 다양한 의사결정 문제에서 학습을 통해 더 나은 결정을 내릴 수 있는 방법론들이 개발되고 있다.Recently, with the advancement of artificial intelligence technology, methodologies are being developed to make better decisions through learning in various decision-making problems.
이하 본 개시의 목적은 제조 또는 생산 시스템에 대한 재사용성 및 확장성을 제공할 수 있는, 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법, 및 디지털 생산 계획을 제공하는, 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체를 제공하는 것이다.The purpose of the present disclosure is to provide a device for providing digital production planning information, a method for providing digital production planning information, and a storage medium storing computer-executable software for providing digital production planning, which can provide reusability and expandability for a manufacturing or production system.
본 개시의 다른 목적은 제조 또는 생산 시스템의 실시간 변화를 예측하거나 효율적으로 생산 계획을 제공할 수 있는, 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획을 제공하는, 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체를 제공하는 것이다.Another object of the present disclosure is to provide a device for providing digital production planning information, a method for providing digital production planning information, and a storage medium storing computer-executable software for providing a digital production plan, which can predict real-time changes in a manufacturing or production system or provide an efficient production plan.
본 개시의 또 다른 목적은, 디지털 모델링을 통해 의사결정을 가상 환경에서 재현하여 시간과 비용을 크게 줄일 수 있는, 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획을 제공하는, 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체를 제공하는 것이다.Another object of the present disclosure is to provide a device 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, which can significantly reduce time and cost by reproducing decision-making in a virtual environment through digital modeling.
본 개시의 또 다른 목적은, 다양한 의사결정 문제를, 인공지능의 학습을 통해 해결할 수 있는 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획을 제공하는, 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체를 제공하는 것이다.Another object of the present disclosure is to provide a device for providing digital production planning information that can solve various decision-making problems through artificial intelligence learning, a method for providing digital production planning information, and a storage medium for storing computer-executable software that provides a digital production plan.
개시하는 일 실시예는, 클라이언트 제조생산시스템의 소프트웨어모델 및 로직 세트에 대한 개발 사용자 인터페이스(user interface, UI)를 표시하는 단계; 상기 개발 사용자 인터페이스에 대한 사용자 입력에 따른 상기 소프트웨어 모델 및 로직 세트에 대한 설정값에 대응하는 상기 소프트웨어 모델 및 로직 세트를 생성하는 단계; 및 상기 소프트웨어모델 및 로직 세트에 기반하는 상기 클라이언트 제조생산시스템에 대한 생산 계획 데이터를 제공하는 단계;를 포함하는, 디지털 생산 계획 정보를 제공하는 방법을 제공한다.One embodiment of the disclosure provides a method for providing digital production planning information, comprising: displaying a development user interface (UI) for a software model and a logic set of a client manufacturing production system; generating a software model and a logic set corresponding to setting values for the software model and the logic set according to a user input to the development user interface; and providing production planning data for the client manufacturing production system based on the software model and the logic set.
상기 설정값은, 상기 클라이언트 제조생산시스템에 대한 도메인 설정값, 소프트웨어 모델 설정값, 퍼시스트 구성 설정값, 데이터 모델 설정값 및 로직 세트 설정값 중 적어도 하나를 포함하는 것을 특징으로 한다.The above setting value is characterized in that it includes at least one of a domain setting value, a software model setting value, a persistent configuration setting value, a data model setting value, and a logic set setting value for the client manufacturing production system.
상기 생성하는 단계는, 상기 클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나에 기반하여, 상기 설정값에 대응하는 상기 소프트웨어 모델 및 로직 세트를 생성하는 단계;를 포함하는 것을 특징으로 한다.The above generating step is characterized by including a step of generating the software model and logic set corresponding to the setting value based on at least one of the data schema and library engine set of the client manufacturing production system.
상기 제공하는 단계는, 상기 클라이언트 제조생산시스템의 데이터 스키마에 따라 상기 클라이언트 제조생산시스템으로부터 기준정보를 포함하는 입력데이터를 수신하는 단계; 및 상기 수신된 입력데이터를 기반으로 상기 소프트웨어모델 및 로직 세트를 수행하여 상기 생산 계획 데이터를 제공하는 단계; 를 포함하는 것을 특징으로 한다.The step of providing the above is characterized by including: a step of receiving input data including reference information from the client manufacturing production system according to a data schema of the client manufacturing production system; and a step of providing the production plan data by performing the software model and logic set based on the received input data.
개시하는 실시 예는, 데이터를 저장하는 데이터베이스; 및 상기 데이터를 처리하는 프로세서를 포함하고, 상기 프로세서는, 클라이언트 제조생산시스템의 소프트웨어모델 및 로직 세트에 대한 개발 사용자 인터페이스(user interface, UI)를 표시하고, 상기 개발 사용자 인터페이스에 대한 사용자 입력에 따른 상기 소프트웨어 모델 및 로직 세트에 대한 설정값에 대응하는 상기 소프트웨어 모델 및 로직 세트를 생성하며, 상기 소프트웨어모델 및 로직 세트에 기반하는 상기 클라이언트 제조생산시스템에 대한 생산 계획 데이터를 제공하는, 디지털 생산 계획 정보를 제공하는 장치를 제공한다.The disclosed embodiment provides a device for providing digital production planning information, comprising: a database for storing data; and a processor for processing the data, wherein the processor displays a development user interface (UI) for a software model and a logic set of a client manufacturing production system, generates the software model and the logic set corresponding to setting values for the software model and the logic set according to a user input to the development user interface, and provides production planning data for the client manufacturing production system based on the software model and the logic set.
상기 설정값은, 상기 클라이언트 제조생산시스템에 대한 도메인 설정값, 소프트웨어 모델 설정값, 퍼시스트 구성 설정값, 데이터 모델 설정값 및 로직 세트 설정값 중 적어도 하나를 포함하는 것을 특징으로 한다.The above setting value is characterized in that it includes at least one of a domain setting value, a software model setting value, a persistent configuration setting value, a data model setting value, and a logic set setting value for the client manufacturing production system.
상기 프로세서는, 상기 클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나에 기반하여, 상기 설정값에 대응하는 상기 소프트웨어 모델 및 로직 세트를 생성하는 것을 특징으로 한다.The above processor is characterized in that it generates the software model and logic set corresponding to the setting value based on at least one of the data schema and library engine set of the client manufacturing production system.
상기 프로세서는, 상기 클라이언트 제조생산시스템의 데이터 스키마에 따라 상기 클라이언트 제조생산시스템으로부터 기준정보를 포함하는 입력데이터를 수신하고, 상기 수신된 입력데이터를 기반으로 상기 소프트웨어모델 및 로직 세트를 수행하여 상기 생산 계획 데이터를 제공하는 것을 특징으로 한다.The above processor is characterized in that it receives input data including reference information from the client manufacturing production system according to the data schema of the client manufacturing production system, and performs the software model and logic set based on the received input data to provide the production plan data.
개시하는 일 실시 예는, 클라이언트 제조생산시스템의 소프트웨어모델 및 로직 세트에 대한 개발 사용자 인터페이스(user interface, UI)를 표시하고, 상기 개발 사용자 인터페이스에 대한 사용자 입력에 따른 상기 소프트웨어 모델 및 로직 세트에 대한 설정값에 대응하는 상기 소프트웨어 모델 및 로직 세트를 생성하며, 상기 소프트웨어모델 및 로직 세트에 기반하는 상기 클라이언트 제조생산시스템에 대한 생산 계획 데이터를 제공하는 단계를 수행하는 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장매체를 제공한다.One embodiment of the disclosure provides a storage medium storing computer-executable software that performs the steps of displaying a development user interface (UI) for a software model and a logic set of a client manufacturing production system, generating the software model and the logic set corresponding to setting values for the software model and the logic set according to a user input to the development user interface, and providing production planning data for the client manufacturing production system based on the software model and the logic set.
이하의 개시에 따르면 제조 또는 생산 시스템에 대한 디지털 모델의 재사용성 및 확장성을 제공할 수 있다.The disclosure below can provide reusability and scalability of digital models for manufacturing or production systems.
이하의 개시에 따르면 제조 또는 생산 시스템의 실시간 변화를 예측하거나 효율적으로 생산 계획을 제공할 수 있다.According to the disclosure below, it is possible to predict real-time changes in a manufacturing or production system or provide efficient production planning.
이하의 개시에 따르면, 제조 또는 생산 시스템의 디지털 모델링을 통해 의사결정을 가상 환경에서 재현하여 시간과 비용을 크게 줄일 수 있고, 제조 또는 생산 시스템에서 다양한 의사결정 문제를 인공지능의 학습을 통해 해결할 수 있다.According to the disclosure below, digital modeling of manufacturing or production systems can significantly reduce time and cost by reproducing decision-making in a virtual environment, and various decision-making problems in manufacturing or production systems can be solved through artificial intelligence learning.
이하의 개시에 따르면, 다양한 세밀도의 생산계획을 요구하는 제조생산시스템에서 일련의 과정을 자동으로 수행할 수 있게 된다.According to the disclosure below, a series of processes can be automatically performed in a manufacturing production system that requires production plans of various levels of detail.
도 1은 디지털 생산 계획을 제공하는 방법의 일 실시 예를 개시한 도면
도 2는 디지털 생산 계획 데이터를 제공하는 컴퓨팅 시스템의 일 실시 예를 개시한 도면
도 3은 디지털 생산 계획 데이터를 제공하는 컴퓨팅 시스템의 다른 일 실시 예를 개시한 도면
도 4는 실시 예에 따른 백워드 플래닝 로직이 수행하는 절차들을 예시한 도면
도 5는 실시 예에 따른 라이브러리 엔진 세트 내의 백워드 플래닝 로직의 수행 단계를 예시한 도면
도 6은 실시 예에 따른 백워드 플래닝을 수행하는 일 예를 나타낸 도면
도 7은 실시 예에 따른 백워드 플래닝 로직을 포함하는 소프트웨어 모델 및 로직 세트를 이용하여 생산 계획을 생성하는 흐름도
도 8은 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 개시한 도면
도 9는 실시 예에 따른 포워드 플래닝 로직이 수행하는 절차들을 예시한 도면
도 10은 실시 예에 따른 라이브러리 엔진 세트 내의 포워드 플래닝 로직의 수행 단계를 예시한 도면
도 11은 실시 예에 따른 포워드 플래닝의 상태 변수의 일 예를 나타내는 도면
도 12는 실시 예에 따른 포워드 플래닝을 수행하는 사건 대기열의 이벤트의 일 예를 나타낸 도면
도 13은 실시 예에 따른 포워드 플래닝 로직을 이용하여 생산 계획을 생성하는 흐름도
도 14는 실시 예에 따른 포워드 플래닝 로직이 수행하는 사건 대기열의 이벤트의 다른 일 예를 나타낸 도면
도 15는 실시 예에 따른 포워드 플래닝 로직이 수행하는 투입의사결정 수행 단계를 예시한 도면
도 16은 실시 예에 따른 포워드 플래닝 로직이 수행하는 디스패칭의 일 예를 나타낸 도면
도 17은 실시 예에 따른 포워드 플래닝 로직이 수행하는 디스패칭의 다른 일 예를 나타낸 도면
도 18은 실시 예에 따른 포워드 플래닝 로직을 이용하여 생산 계획을 생성하는 흐름도
도 19는 실시 예에 따른 데이터 스키마 및 라이브러리 엔진 세트에 기반하여 소프트웨어모델 및 로직 세트를 생성하는 예를 개시하는 도면
도 20은 실시 예에 따른 페깅 로직 및 시뮬레이션 로직을 포함하는 로직 세트를 생성하는 예를 개시하는 도면
도 21은 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법이 소프트웨어모델 및 로직 세트를 생성하는 예를 개시하는 도면
도 22는 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법이 생산 계획을 생성하는 예를 개시하는 흐름도
도 23은 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 운영 작업을 생성하는 예를 개시하는 도면
도 24는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 운영 작업을 실행하는 예를 개시하는 도면
도 25는 실시 예에 따른 시스템운영부에서 운영 작업을 설정하는 예를 개시한 도면
도 26은 실시 예에 따른 온프레미스 컴퓨팅시스템에서 운영작업을 생성하고 실행하는 예를 개시하는 흐름도
도 27은 실시 예에 따른 클라우드 컴퓨팅시스템에서 운영작업을 생성하고 수행하는 예를 개시하는 흐름도
도 28은 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법을 개시하는 흐름도
도 29는 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 개시한 도면
도 30은 실시 예에 따른 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하는 예를 개시하는 도면
도 31은 실시 예에 따른 데이터 조회 화면의 예를 개시하는 도면
도 32는 실시 예에 따른 피벗 그리드 조회 화면의 예를 개시하는 도면
도 33은 실시 예에 따른 데이터 편집 화면의 예를 개시하는 도면
도 34는 실시 예에 따른 실험 설정 및 실행 화면의 예를 개시하는 도면
도 35는 실시 예에 따른 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하는 예를 개시하는 흐름도
도 36은 실시 예에 따른 디지털 생산 계획 데이터를 제공하는 컴퓨팅 시스템의 일 실시예를 개시하는 도면
도 37는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브의 기본구조의 예를 개시하는 도면
도 38는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면
도 39는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면이다.
도 40는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일에서 정제 로직을 생성하는 예를 개시하는 도면
도 41는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면
도 42는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면
도 43는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 실험을 실행하는 예를 개시하는 도면
도 44는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일에 대한 정보를 출력하는 예를 개시하는 도면
도 45은 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 실험허브부에서 실험을 수행하고 실행하는 예를 개시하는 도면
도 46은 실시 예에 따른 실험 허브를 생성하고 수행하는 예를 개시하는 흐름도
도 47는 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법을 개시하는 흐름도
도 48은 실시 예에 따른 소프트웨어모델 및 로직 세트를 생성하는 예를 개시하는 도면
도 49는 실시 예에 따른 도메인 설정 화면의 예를 개시하는 도면
도 50은 실시 예에 따른 모델 정보 화면의 예를 개시하는 도면
도 51은 실시 예에 따른 전역변수 설정 화면의 예를 개시하는 도면
도 52는 실시 예에 따른 데이터베이스 설정 화면의 예를 개시하는 도면
도 53은 실시 예에 따른 데이터 스키마 설정 화면의 예를 개시하는 도면
도 54는 실시 예에 따른 쿼리 설정 화면의 예를 개시하는 도면
도 55는 실시 예에 따른 퍼시스트 구성 화면의 예를 개시하는 도면
도 56은 실시 예에 따른 퍼시스트 구성의 쿼리 실행 설정 화면의 다른 예를 개시하는 도면
도 57은 실시 예에 따른 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하는 예를 개시하는 흐름도FIG. 1 is a drawing disclosing one embodiment of a method for providing a digital production plan.
FIG. 2 is a diagram illustrating one embodiment of a computing system that provides digital production planning data.
FIG. 3 is a diagram disclosing another embodiment of a computing system providing digital production planning data.
Figure 4 is a diagram illustrating procedures performed by backward planning logic according to an embodiment.
FIG. 5 is a diagram illustrating the execution steps of backward planning logic within a library engine set according to an embodiment.
Figure 6 is a drawing showing an example of performing backward planning according to an embodiment.
Figure 7 is a flowchart of generating a production plan using a software model and logic set including backward planning logic according to an embodiment.
FIG. 8 is a drawing disclosing one embodiment of a device providing digital production planning information.
FIG. 9 is a diagram illustrating procedures performed by forward planning logic according to an embodiment.
FIG. 10 is a diagram illustrating the execution steps of forward planning logic within a library engine set according to an embodiment.
Figure 11 is a diagram showing an example of state variables of forward planning according to an embodiment.
FIG. 12 is a diagram showing an example of an event in an event queue performing forward planning according to an embodiment.
Figure 13 is a flowchart for generating a production plan using forward planning logic according to an embodiment.
FIG. 14 is a diagram showing another example of an event in an event queue performed by forward planning logic according to an embodiment.
Figure 15 is a diagram illustrating an investment decision-making execution step performed by forward planning logic according to an embodiment.
FIG. 16 is a diagram showing an example of dispatching performed by forward planning logic according to an embodiment.
FIG. 17 is a diagram showing another example of dispatching performed by forward planning logic according to an embodiment.
Figure 18 is a flowchart for generating a production plan using forward planning logic according to an embodiment.
FIG. 19 is a diagram disclosing an example of generating a software model and a logic set based on a data schema and a set of library engines according to an embodiment.
FIG. 20 is a diagram disclosing an example of creating a logic set including pegging logic and simulation logic according to an embodiment.
FIG. 21 is a drawing disclosing an example of a method for providing digital production planning information according to an embodiment of the present invention, wherein the method generates a software model and a logic set.
Figure 22 is a flowchart disclosing an example of a method for providing digital production plan information according to an embodiment of the present invention to generate a production plan.
FIG. 23 is a diagram disclosing an example of generating an operational task based on a software model and logic set according to an embodiment.
FIG. 24 is a diagram disclosing an example of executing an operational task based on a software model and logic set according to an embodiment.
Figure 25 is a drawing showing an example of setting up an operation task in a system operation unit according to an embodiment.
Figure 26 is a flowchart disclosing an example of creating and executing an operational task in an on-premise computing system according to an embodiment.
Figure 27 is a flowchart disclosing an example of creating and performing an operational task in a cloud computing system according to an embodiment.
Figure 28 is a flowchart disclosing a method for providing digital production planning information according to an embodiment.
FIG. 29 is a drawing disclosing one embodiment of a device providing digital production planning information.
FIG. 30 is a diagram disclosing an example of analyzing a production plan based on a software model and logic set according to an embodiment.
Figure 31 is a drawing disclosing an example of a data inquiry screen according to an embodiment.
Figure 32 is a drawing disclosing an example of a pivot grid query screen according to an embodiment.
Figure 33 is a drawing disclosing an example of a data editing screen according to an embodiment.
Figure 34 is a drawing disclosing an example of an experimental setup and execution screen according to an embodiment.
Figure 35 is a flowchart disclosing an example of analyzing a production plan based on a software model and logic set according to an embodiment.
FIG. 36 is a diagram disclosing one embodiment of a computing system that provides digital production planning data according to an embodiment.
Figure 37 is a diagram disclosing an example of the basic structure of an experimental hub based on a software model and logic set according to an embodiment.
FIG. 38 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
FIG. 39 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
FIG. 40 is a diagram disclosing an example of generating refinement logic from an experimental hub file based on a software model and logic set according to an embodiment.
FIG. 41 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
FIG. 42 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
Figure 43 is a diagram disclosing an example of executing an experiment based on a software model and logic set according to an embodiment.
FIG. 44 is a diagram disclosing an example of outputting information about an experimental hub file based on a software model and logic set according to an embodiment.
FIG. 45 is a diagram disclosing an example of performing and executing an experiment in an experimental hub based on a software model and logic set according to an embodiment.
Figure 46 is a flowchart disclosing an example of creating and performing an experimental hub according to an embodiment.
Figure 47 is a flowchart disclosing a method for providing digital production planning information according to an embodiment.
Figure 48 is a drawing disclosing an example of creating a software model and logic set according to an embodiment.
Figure 49 is a drawing disclosing an example of a domain setting screen according to an embodiment.
Figure 50 is a drawing disclosing an example of a model information screen according to an embodiment.
Figure 51 is a drawing disclosing an example of a global variable setting screen according to an embodiment.
Figure 52 is a drawing disclosing an example of a database setting screen according to an embodiment.
Figure 53 is a drawing disclosing an example of a data schema setting screen according to an embodiment.
Figure 54 is a drawing disclosing an example of a query setting screen according to an embodiment.
Figure 55 is a drawing disclosing an example of a persistence configuration screen according to an embodiment.
FIG. 56 is a drawing disclosing another example of a query execution setting screen of a persistent configuration according to an embodiment.
Figure 57 is a flowchart disclosing an example of analyzing a production plan based on a software model and logic set according to an embodiment.
이하에서는 위와 같은 문제점을 해결하고 거래를 위해 기술적인 불편함을 해결할 수 있는 실시 예들을 개시한다. 이하에서 실시 예들의 구성요소를 언급하는 경우, 특별히 물리장치로 제한하지 않는 한 최적화된 하드웨어 또는 소프트웨어로 모두 구현이 가능하다.Below, we present embodiments that address the aforementioned issues and address technical inconveniences associated with transactions. When referring to components of the embodiments below, unless specifically limited to physical devices, they can all be implemented using optimized hardware or software.
도 1은 디지털 생산 계획을 제공하는 방법의 일 실시 예를 개시한 도면이다.FIG. 1 is a drawing disclosing one embodiment of a method for providing a digital production plan.
생산 계획을 실행하는 클라이언트로부터 생산 실행을 위한 기준 정보를 포함하는 입력데이터의 데이터 스키마를 수신한다(S10).A data schema of input data including reference information for production execution is received from a client executing a production plan (S10).
여기서, 생산 실행을 위한 기준 정보는 생산을 실행하는 장소, 예를 들어 제조(생산)시스템(Manufacturing System) 내의 여러 가지 기준 정보를 지칭하는데 제조생산시스템 내의 다양한 기준 정보는 이하에서 상세히 후술한다.Here, the reference information for production execution refers to various reference information within the place where production is executed, for example, the manufacturing (production) system. Various reference information within the manufacturing production system is described in detail below.
생산 실행을 위한 기준 정보를 포함하는 데이터 스키마는, 디지털 생산 계획을 생성하는데 필요한 널리 사용되는 공정의 일반적인 데이터 스키마 이외에 해당 제품이나 공정에만 적용되는 커스텀화된 데이터 스키마를 포함할 수 있다.The data schema containing the reference information for production execution may include customized data schemas that are specific to the product or process in addition to the general data schemas of widely used processes required to generate digital production plans.
클라이언트가 제공하는 기준 정보와 관련된 데이터의 구조나 종류 등을 미리 알고 있거나, 또는 클라이언트가, 미리 정해진 데이터 스키마에 따라 생산 운영 데이터를 준비하였다면, 이 단계는 생략될 수 있다.If the structure or type of data related to the reference information provided by the client is known in advance, or if the client has prepared production operation data according to a pre-determined data schema, this step can be omitted.
생산 실행을 위한 기준 정보를 포함하는 입력데이터는 일정한 형식과 내용을 포함한 특정 시점, 예를 들어 현재 시점의 데이터를 포함할 수 있고, 제조생산시스템의 상태를 나타내는 데이터를 포함한다.Input data containing reference information for production execution may include data at a specific point in time, for example, the current point in time, with a certain format and content, and may include data indicating the status of the manufacturing production system.
상기 클라이언트로부터 수신한 데이터 스키마를 기반으로 소프트웨어모델 및 로직 세트를 생성한다(S20).A software model and logic set are created based on the data schema received from the client (S20).
이 단계에서 클라이언트로 수신한 데이터 스키마를 기반으로 관련된 생산 계획 정보를 생성할 수 있는 소프트웨어(SW)모델 또는 로직(logic)세트 중 적어도 하나를 생성할 수 있다.At this stage, at least one of a software (SW) model or a set of logic can be created that can generate relevant production planning information based on the data schema received from the client.
여기서 소프트웨어 모델은 수신된 데이터를 사용하여 결과를 생성하는 컴퓨팅 소프트웨어의 일부로서 구현하고자 하는 현실의 시스템을 컴퓨터에서 수행되도록 설계한 프로그램을 지칭한다.Here, a software model refers to a program designed to be executed on a computer as a part of computing software that uses received data to produce results, which is a real-world system that is to be implemented.
한편 여기서 로직(logic)은 컴퓨팅 모델 또는 프로그램이, 데이터 생성, 저장, 수정 등을 수행하는 규칙을 포함한 파일로서, SW모델이 실행될 경우 위 SW모델이 어떻게 동작해야 하는지를 결정하는 절차를 포함하는 데이터 세트를 의미하고, 컴퓨팅 SW모델의 핵심 기능을 구현하는 데 필요한 데이터를 지칭한다. 따라서 로직 세트는 입력데이터를 어떤 작업으로 처리할지 정의한 구조화된 규칙의 집합으로서 파일 형태로 제공될 수 있다.Meanwhile, logic here refers to a file containing rules for computing models or programs to perform data creation, storage, and modification. It refers to a data set containing procedures that determine how the SW model should operate when executed, and refers to the data required to implement the core functions of the computing SW model. Therefore, a logic set can be provided in file form as a structured set of rules that define how input data will be processed.
이러한 소프트웨어(SW)모델 또는 모델로직 중 적어도 하나는 시스템 내에 적어도 일부분이 미리 준비될 수도 있다. 또한 관련된 생산 계획 정보를 생성하기 위해 필요한 일부의 소프트웨어(SW)모델과 일부의 로직(logic)을 이 단계에서 생성할 수도 있다.At least one of these software (SW) models or model logic may already be partially prepared within the system. Additionally, some of the software (SW) models and some of the logic required to generate the relevant production planning information may also be created at this stage.
예를 들어 클라이언트로부터 기준 정보를 포함하는 입력데이터를 기반으로 생산 계획을 제공하는 클라우드 시스템인 경우 이 단계에서 사용자의 커스텀화된 일부 로직 세트를 생성하거나, 또는 이 단계에서 생략될 수 있다.For example, if the system is a cloud system that provides production plans based on input data containing baseline information from the client, this step may create some customized set of logic for the user, or it may be omitted at this step.
상기 데이터 스키마에 따라 상기 클라이언트로부터 입력데이터를 수신한다(S30).Input data is received from the client according to the above data schema (S30).
클라이언트의 시스템으로부터 수신한 데이터 스키마에 따라 미리 입력데이터를 준비하거나 또는 클라이언트로부터 데이터 스키마를 얻은 경우에 그 데이터 스키마에 따라 클라이언트로부터 생산 계획정보를 생성할 수 있는 입력데이터를 수신할 수 있다.Input data can be prepared in advance according to a data schema received from the client's system, or, if a data schema is obtained from the client, input data that can generate production plan information can be received from the client according to the data schema.
클라이언트의 데이터베이스에 입력데이터가 저장된 경우 이 데이터베이스로부터 그 입력데이터를 쿼리하거나 정해진 방식 또는 자동으로 수신하도록 설정될 수 있다.If the input data is stored in the client's database, the input data can be queried from this database or set to be received in a set manner or automatically.
상기 생성한 소프트웨어모델 및 로직 세트에 대한 테스트를 수행할 수 있다(S40).Testing can be performed on the software model and logic set created above (S40).
클라이언트로부터 데이터 스키마에 따른 데이터를 수신한 경우 이를 기반으로 위에서 생성한 소프트웨어 모델 또는 로직을 테스트할 수 있다.If you receive data from the client according to the data schema, you can test the software model or logic created above based on it.
소프트웨어 모델이나 로직에 따른 생산 계획 시스템 모델링의 일종인 시뮬레이션을 실행하고 그 결과를 조회할 수 있다.You can run a simulation, which is a type of production planning system modeling based on a software model or logic, and view the results.
여기서, 생산 계획에 영향을 미치는 여러 가지 설정 변수 등을 수정하거나 모델 수행에 필요한 여러 가지 옵션들을 설정할 수 있다. 변수나 설정의 변경에 따라 SW모델이 여러 가지 환경에서 최적화된 생산 계획 데이터를 생성하는지 테스트할 수 있다.Here, you can modify various configuration variables that affect production planning or configure various options required for model execution. You can test whether the SW model generates optimized production plan data in various environments based on variable or configuration changes.
예를 들면, 일종의 소프트웨어(SW) 모델 또는 로직을 이용해 생산 계획에 영향을 미치는 여러 변수들의 조합과 성능 지표를 설계한 실험을 수행할 수 있다. 하나의 실험은 특정 변수나 특정 성능 지표를 선택하여 수행되는 하나 이상의 실행 시나리오들 포함할 수 있다.For example, an experiment can be conducted using a software (SW) model or logic to design combinations of variables and performance indicators that influence production planning. A single experiment can include one or more execution scenarios, each of which selects a specific variable or performance indicator.
여러 소프트웨어 모델들 또는 로직들이 사용될 경우 다수의 실험을 포함하는 실험허브(Experiment Hub)를 생성할 수도 있다.When multiple software models or logics are used, an Experiment Hub containing multiple experiments can also be created.
그리고, 수신한 입력데이터를 소프트웨어(SW) 모델 또는 로직의 핵심 부분인 엔진을 활용하여 생산 계획 정보를 포함하는 출력데이터를 생성할 수 있다. 이 단계는 입력데이터, 엔진, 출력데이터 등의 구성요소를 변경한 여러 가지 시나리오로서 컴퓨터로 구현한 모델들을 테스트할 수 있다.Furthermore, the received input data can be used to generate output data containing production planning information using a software (SW) model or engine, which is a core component of the logic. This step allows for testing computer-implemented models under various scenarios that change components such as the input data, engine, and output data.
만약 이러한 테스트가 필요없이 기 설정된 변수를 사용하는 경우, 예를 들어 특정 산업 분야에 적용되는 생산 계획의 유형이 기 설정되는 등의 경우에 이 단계는 생략될 수 있다.This step can be omitted if pre-defined variables are used without the need for such testing, for example, if the type of production plan applied to a specific industry is pre-defined.
상기 수신된 입력데이터를 기반으로 상기 소프트웨어모델 및 로직 세트를 제공하거나 또는 상기 소프트웨어모델 및 로직 세트를 수행하여 생성한 생산 계획 데이터를 제공한다(S50).Based on the input data received above, the software model and logic set are provided, or production plan data generated by performing the software model and logic set are provided (S50).
실시 예의 이 단계는 상기 생성된 생산 계획 데이터를 기반으로 소프트웨어 모델 및 모델 로직을 클라이언트에 제공할 수 있다. 또는 상기 생성된 생산 계획 데이터를 기반으로 소프트웨어 모델 및 모델 로직을 수행하고 수행된 결과에 따른 생산 계획 데이터를 클라이언트에 제공할 수도 있다.This step of the embodiment may provide a software model and model logic to the client based on the above-mentioned generated production plan data. Alternatively, the software model and model logic may be performed based on the above-mentioned generated production plan data, and production plan data based on the performed results may be provided to the client.
생성된 생산 계획 데이터는 클라이언트 시스템의 데이터베이스 등에 업로드(upload)될 수 있다.The generated production plan data can be uploaded to a database of the client system, etc.
이러한 디지털 생산 계획 데이터를 제공하는 방법의 일 실시 예는 온프레미스(on-premise) 컴퓨팅 시스템이나 클라우드 컴퓨팅 시스템 등의 플랫폼을 통해 구현될 수 있다. 실시 예가 클라우드 컴퓨팅 시스템으로 구현될 경우 클라이언트는 SaaS (Software-as-a-Service)방식으로 이 실시 예를 구현하는 소프트웨어 패키지를 통해 생산 계획을 얻을 수 있다.One embodiment of a method for providing such digital production planning data can be implemented via a platform such as an on-premise computing system or a cloud computing system. If the embodiment is implemented via a cloud computing system, the client can obtain the production plan via a software package implementing the embodiment in a Software-as-a-Service (SaaS) manner.
또한 상기 생성된 소프트웨어 모델 및 모델 로직을 실행할 경우, 의사결정을 위한 여러 확장 기능 이 사용 될 수 있다. 이 경우 확장 기능은 시나리오들이나 시뮬레이션들에 필요한 매개변수를 수정하거나 기계학습을 진행하여 생산계획데이터를 생성하는데 사용될 있다. 이에 대한 상세한 실시 예는 이하에서 후술한다.Additionally, when executing the generated software model and model logic, various extensions for decision-making can be utilized. These extensions can be used to modify parameters required for scenarios or simulations, or to generate production planning data through machine learning. Detailed examples of these extensions are described below.
이하에서는, 디지털 생산 계획 데이터를 제공하는 방법의 일 실시 예를 구현하는 컴퓨팅 시스템의 실시 예들을 개시한다.Below, embodiments of a computing system implementing one embodiment of a method for providing digital production planning data are disclosed.
도 2는 디지털 생산 계획 데이터를 제공하는 컴퓨팅 시스템의 일 실시 예를 개시한다.FIG. 2 discloses one embodiment of a computing system that provides digital production planning data.
이 도면은 디지털 생산 운영 데이터를 제공하는 온프레미스(on-premise) 컴퓨팅 시스템의 일 실시 예를 개시한다.This drawing discloses one embodiment of an on-premise computing system that provides digital production operations data.
일 실시 예에서 제조생산시스템 등에서 생산 계획을 실행하는 클라이언트 측의 제조생산시스템(100)은 온프레미스 컴퓨팅 시스템(1000)에 생산 실행을 위한 기준 정보를 포함하는 입력데이터를 제공하고, 온프레미스 컴퓨팅 시스템(1000)으로부터 그에 따라 생성된 디지털 생산 계획 데이터를 제공받는다.In one embodiment, a client-side manufacturing production system (100) that executes a production plan in a manufacturing production system, etc., provides input data including reference information for production execution to an on-premise computing system (1000), and receives digital production plan data generated accordingly from the on-premise computing system (1000).
이 실시 예에서 제조생산시스템(100)은, 제조 공정을 전반적으로 운영 및 관리하는 시스템운영부(110), 시스템운영부(110)의 실행 요청에 따라 생산 계획 데이터를 생성하는 모델실행부(130) 및 모델실행부(130)의 실행한 결과인 생산 계획 데이터를 저장하는 데이터베이스(150)을 포함한다.In this embodiment, the manufacturing production system (100) includes a system operation unit (110) that operates and manages the manufacturing process as a whole, a model execution unit (130) that generates production plan data according to an execution request of the system operation unit (110), and a database (150) that stores the production plan data that is the result of execution of the model execution unit (130).
이 실시 예에서 온프레미스 컴퓨팅 시스템(1000)은 클라이언트 측에 위치할 수도 있고, 클라이언트 외부의 서비스 제공자로부터 제공될 수도 있다.In this embodiment, the on-premise computing system (1000) may be located on the client side or may be provided by a service provider external to the client.
실시 예에 따른 온프레미스 컴퓨팅 시스템(1000)은 클라이언트의 제조생산시스템(100)으로부터 수신한 입력데이터 또는 입력데이터의 스키마를 기반으로 생산 계획에 관련된 모델을 개발하는 모델개발부(1100) 및 개발된 모델을 클라이언트에 제공하고 실행하도록 클라이언트 운영서버를 관리하는 서버관리부(1200)를 포함한다.An on-premise computing system (1000) according to an embodiment includes a model development unit (1100) that develops a model related to a production plan based on input data or a schema of input data received from a client's manufacturing production system (100), and a server management unit (1200) that manages a client operation server to provide and execute the developed model to the client.
실시 예에 따른 온프레미스 컴퓨팅 시스템(1000)은 모델개발부(1100)가 개발한 소프트웨어(SW)모델 또는 로직 세트의 설정 등을 변경하고 분석하는 모델분석부(1300)를 더 포함할 수 있다.The on-premise computing system (1000) according to the embodiment may further include a model analysis unit (1300) that changes and analyzes settings of a software (SW) model or logic set developed by a model development unit (1100).
또한 실시 예에 따른 온프레미스 컴퓨팅 시스템(1000)은 모델분석부(1300)가 분석한 소프트웨어(SW)모델 또는 로직을 사전에 실행하여 결과를 얻을 수 있는 모델실행부(1400)를 더 포함할 수도 있다. 이와 같은 온프레미스 컴퓨팅 시스템(1000)의 실시 예가 모델분석부(1300)와 모델실행부(1400)를 포함할 경우 클라이언트의 제조생산시스템(100)에서 수행될 모델의 결과를 사전에 분석하고 변경할 수 있어 최적의 생산 운영 계획을 생성할 수 있다.In addition, the on-premise computing system (1000) according to the embodiment may further include a model execution unit (1400) that can obtain results by executing the software (SW) model or logic analyzed by the model analysis unit (1300) in advance. When the embodiment of the on-premise computing system (1000) includes the model analysis unit (1300) and the model execution unit (1400), the results of the model to be executed in the client's manufacturing production system (100) can be analyzed and modified in advance, thereby generating an optimal production operation plan.
온프레미스 컴퓨팅 시스템(1000)는 제조생산시스템(100)으로부터 생산 계획에 관련된 데이터 스키마를 수신한다. 생산 실행을 위한 기준 정보를 포함하는 입력데이터의 데이터 스키마는 소프트웨어(SW)모델 또는 로직을 수행하는데 필요한 데이터의 기본 형식을 포함한다. 이러한 데이터 스키마는, 제조생산시스템(100)에 따라 여러 가지 정보와 타입을 가진 데이터가 일정한 형식과 내용으로 수신될 수 있도록 할 수 있다.The on-premise computing system (1000) receives a data schema related to a production plan from the manufacturing production system (100). The data schema of the input data, which includes reference information for production execution, includes the basic format of data required to execute a software (SW) model or logic. This data schema can enable data with various information and types to be received in a consistent format and content, depending on the manufacturing production system (100).
온프레미스 컴퓨팅 시스템(1000)의 모델개발부(1100)는, 수신된 데이터 스키마와 라이브러리 엔진세트(1150)에 기반하여 생산 계획 데이터를 생성하는 소프트웨어 모델 또는 로직 세트를 생성할 수 있다. 라이브러리 엔진세트 (1150)는 코어라이브러리, 생산계획엔진, 생산도메인특화엔진 등을 포함할 수 있다.The model development unit (1100) of the on-premise computing system (1000) can generate a software model or logic set that generates production planning data based on the received data schema and the library engine set (1150). The library engine set (1150) can include a core library, a production planning engine, a production domain-specific engine, etc.
이하에 엔진 또는 엔진세트라 함은 소프트웨어 엔진을 지칭하는 것으로 여러 가지 캡슐화된 기능 블록을 포함하는 라이브러리나 객체 등을 포함한 소프트웨어 구성 모듈을 의미한다. 소프트웨어를 실행할 경우 엔진을 이용하면 그 소프트웨어와 연결된 소프트웨어 모델이나 로직들이 공동적이고 본질적인 기능을 수행할 수 있다.Hereinafter, the term "engine" or "engine set" refers to a software engine, a software component module that includes libraries or objects containing various encapsulated functional blocks. When executing software, the engine enables the software models and logic associated with the software to perform common and essential functions.
라이브러리 엔진세트(1150)의 코어라이브러리는 생산계획엔진과 함께 생산 계획을 구현하는 자료 구조를 포함하는 집합이다.The core library of the library engine set (1150) is a set that includes data structures that implement production planning together with the production planning engine.
그리고 라이브러리 엔진세트(1150)의 생산도메인특화엔진은 생산계획엔진의 일부 기능을 상속받아서 특정 생산 도메인에서 사용하는 로직을 구현한 데이터 세트로서 산업이나 제조생산시스템에 따라 다르게 정의될 수 있다.And the production domain specialized engine of the library engine set (1150) inherits some functions of the production planning engine and is a data set that implements logic used in a specific production domain and can be defined differently depending on the industry or manufacturing production system.
라이브러리 엔진세트(1150)의 생산계획엔진은 생산 계획을 생성하는 여러 캡슐화된 기능블록세트로 정의한다.The production planning engine of the library engine set (1150) is defined as a set of several encapsulated function blocks that generate a production plan.
라이브러리 엔진세트(1150)의 코어라이브러리는 실시 예에 따라 소프트웨어(SW)모델 및 모델 로직을 생성하는 전반적인 라이브러리를 포함한다.The core library of the library engine set (1150) includes an overall library that generates software (SW) models and model logic according to an embodiment.
즉, 모델개발부(1100)는 사전에 정의한 바에 따라 클라이언트로부터 입력데이터의 데이터 스키마를 수신한다. 모델개발부(1100)는 클라이언트로부터 수신하는 데이터 스키마가 소프트웨어(SW)모델 및 모델 로직의 실행에 필요한 데이터 형식이 되도록 사전에 데이터 스키마를 정의할 수도 있다.That is, the model development unit (1100) receives a data schema of input data from the client according to a predefined definition. The model development unit (1100) may also define a data schema in advance so that the data schema received from the client becomes a data format required for executing the software (SW) model and model logic.
모델개발부(1100)는 데이터 스키마에 제조생산시스템의 기준 정보를 수집하기 위한 순서의 설정이나 소프트웨어(SW)모델 및 모델 로직이 실행되기 위해 필요한 정보를 설정을 할 수도 있다. 예를 들어 모델개발부(1100)는 데이터베이스(150)로부터 데이터를 가져오는 방식, 그 데이터의 형식 등을 설정할 수 있다. 예를 들어 데이터의 크기 다운로드 순서, 수신 조건 등을 설정할 수 있다.The model development unit (1100) can also set the order in which the manufacturing production system's baseline information is collected from the data schema, or the information required for the execution of the software (SW) model and model logic. For example, the model development unit (1100) can set the method for retrieving data from the database (150), the format of the data, etc. For example, the model development unit can set the data size, download order, reception conditions, etc.
모델개발부(1100)는 수신된 데이터 스키마와 라이브러리 엔진 세트(1150)를 기반으로 적절한 소프트웨어(SW)모델 및 모델 로직을 생성하도록 여러 가지 개발도구를 제공할 수 있다.The model development unit (1100) can provide various development tools to create appropriate software (SW) models and model logic based on the received data schema and library engine set (1150).
모델개발부(1100)가 생성하는 소프트웨어(SW)모델 및 모델 로직은 다양한 모듈들, 예를 들면 이후에 개시할 페깅단계나 다양한 시뮬레이션들을 포함할 수 있다. 모델개발부(1100)는 소프트웨어 모델을 정의하고 사용할 데이터 정의하고 생성되는 데이터를 저장할 수 있다.The software (SW) model and model logic generated by the model development unit (1100) may include various modules, such as a pegging step to be initiated later or various simulations. The model development unit (1100) may define the software model, define the data to be used, and store the generated data.
모델개발부(1100)에 의해 개발된 소프트웨어(SW)모델 및 모델 로직과 시나리오들이나 시뮬레이션들에 관련된 모듈들의 여러 변수들이나 로직들을 설정하도록 할 수도 있다. 소프트웨어(SW)모델 및 모델 로직은, 예를 들면 생산 계획을 위한 의사 결정의 최적화, 기계학습, 다양한 분야의 실험 설계 등을 위해 사용될 수 있다.The software (SW) model and model logic developed by the Model Development Department (1100) can also be configured to set various variables and logics of modules related to scenarios or simulations. The software (SW) model and model logic can be used, for example, for decision-making optimization for production planning, machine learning, and experimental design in various fields.
모델개발부(1100)은 클라이언트가 원하는 생산 계획의 형태에 따라 다양한 모듈을 조합하여 소프트웨어(SW)모델 및 모델 로직을 정의할 수 있다. 예를 들어 공장에 제품을 투입하는 계획만 얻고 싶을 경우 이후에 설명할 백워드 플래닝의 페깅(Pegging) 모듈을 사용하여 투입 계획을 얻을 수 있다.The Model Development Department (1100) can define software (SW) models and model logic by combining various modules according to the client's desired production plan. For example, if only a plan for product input into a factory is desired, the input plan can be obtained using the Pegging module of backward planning, described later.
다른 예로서, 주간 생산 계획을 수립하는데 있어 월간 제품 투입계획을 고려한 생산 계획을 얻고 싶다면, 제 1 모듈인 페깅(Pegging) 모듈에서 얻은 투입 계획을 제 2 모듈인 시뮬레이션(Simulation) 모듈의 입력값으로 하여 순차적으로 생산계획을 생성하는 모델을 만들 수 있다.As another example, if you want to obtain a production plan that takes into account the monthly product input plan when establishing a weekly production plan, you can create a model that sequentially generates a production plan by using the input plan obtained from the first module, the Pegging module, as an input value for the second module, the Simulation module.
모델개발부(1100)은 소프트웨어 모델에 포함된 개별 모듈의 구성요소를 정의할 수 있도록 할 수있다. 예를들어 시뮬레이션(Simulation) 의 공장, 작업물, 투입 할당, 제약조건 등의 로직을 클라이언트의 제조 시스템에서 재현할 수 있도록 수정할 수 있다.The model development unit (1100) can define the components of individual modules included in a software model. For example, the logic of simulations, such as factories, workpieces, input allocation, and constraints, can be modified to be reproduced in the client's manufacturing system.
그리고 모델개발부(1100)는 소프트웨어 모델 및 로직에 추가된 여러 모듈들의 실행 관리 등에 대한 설정이나 실행을 관리하도록 할 수도 있다.And the model development department (1100) can also manage the settings and execution of various modules added to the software model and logic.
서버관리부(1200)는 모델개발부(1100)가 생성한 소프트웨어(SW)모델 및 모델 로직을 클라이언트에 전달하고, 클라이언트의 제조생산시스템(100)이 생산 계획 데이터를 생성하게 하여 생산 운영이 진행되도록 할 수 있다.The server management unit (1200) can transmit the software (SW) model and model logic created by the model development unit (1100) to the client and cause the client's manufacturing production system (100) to create production plan data so that production operations can proceed.
서버관리부(1200)는 클라이언트의 시스템운영부(110)에 소프트웨어(SW)모델 및 모델 로직을 전달하고, 그 소프트웨어(SW)모델의 실행에 관련된 작업을 정의, 예약 및 등록할 수 있다. 클라이언트의 시스템운영부(110)은 서버관리부(1200) 또는 그 사용자의 지정한 바에 따라 모델 실행 작업을 수행할 수 있다.The server management unit (1200) can transmit software (SW) models and model logic to the client's system operation unit (110), and define, schedule, and register tasks related to the execution of the software (SW) models. The client's system operation unit (110) can perform model execution tasks according to the specifications of the server management unit (1200) or its user.
서버관리부(1200)는, 클라이언트의 제조생산시스템(100)의 시스템운영부(110)의 관리 뿐만 아니라 프로젝트나 작업 관리, 계획에 따라 프로젝트 또는 작업을 운영하기 위한 트리거의 관리, 및 그 모니터링과 성능을 변경하고 설정할 수 있다.The server management unit (1200) can manage not only the system operation unit (110) of the client's manufacturing production system (100), but also manage projects or tasks, manage triggers for operating projects or tasks according to plans, and change and set the monitoring and performance thereof.
한편, 실시 예에서 모델분석부(1300)는 소프트웨어(SW)모델 및 모델 로직의 여러 가지 설정 정보 등을 변화시켜 모델실행부(1400)에서 생산 계획 데이터를 생성하여 테스트하고 분석할 수 있다.Meanwhile, in the embodiment, the model analysis unit (1300) can change various setting information of the software (SW) model and model logic to generate production plan data in the model execution unit (1400) to test and analyze it.
모델분석부(1300)는 모델개발부(1100)가 생성한 소프트웨어(SW)모델 및 모델 로직 및 수신된 데이터 스키마에 따라 입력데이터 모델실행부(1400)에 전달하여 실행하게 하고 그 결과를 분석하는 도구를 제공할 수 있다.The model analysis unit (1300) can provide a tool for executing the input data model execution unit (1400) according to the software (SW) model and model logic and received data schema created by the model development unit (1100) and analyzing the results.
모델분석부(1300)에서 그 결과에 따라 소프트웨어(SW)모델 및 모델 로직의 변경이 필요한 경우 라이브러리 엔진 세트(1150)를 변경할 수도 있다.In the model analysis unit (1300), if a change in the software (SW) model and model logic is required based on the results, the library engine set (1150) may be changed.
예를 들어 모델분석부(1300)는 쿼리 등을 통해 클라이언트의 데이터베이스(150)로부터 제조생산시스템의 기준 정보 데이터 세트를 포함된 입력데이터를 파일 등의 형태로 수신할 수 있다.For example, the model analysis unit (1300) can receive input data including a standard information data set of the manufacturing production system from the client's database (150) in the form of a file or the like through a query or the like.
모델분석부(1300)는 모델개발부(1100)가 개발한 소프트웨어(SW)모델 및 모델 로직을, 라이브러리 엔진 세트(1150)와 입력데이터의 기준 정보 등을 변경하면서 실험 분석하는 도구를 제공한다.The model analysis department (1300) provides a tool for experimental analysis of the software (SW) model and model logic developed by the model development department (1100) by changing the library engine set (1150) and the standard information of the input data.
예를 들어 모델분석부(1300)는 수신된 입력데이터 내의 기준 정보를 포함한 데이터 세트를 이용하여 모델실행부(1400)를 통해 생산 계획 데이터를 생성할 수 있다.For example, the model analysis unit (1300) can generate production plan data through the model execution unit (1400) using a data set including reference information in the received input data.
모델분석부(1300)는 소프트웨어(SW)모델 및 모델 로직의 정보, 그 실행 결과를 조회할 수 있는 사용자 인터페이스를 제공할 수 있다.The model analysis unit (1300) can provide a user interface that can view information on software (SW) models and model logic, as well as execution results.
모델분석부(1300)는 소프트웨어(SW)모델 및 모델 로직의 입력데이터, 여러 가지 설정 정보, 모델링 결과에 따른 결과 분석을 사용자에게 제공할 수 있다.The model analysis unit (1300) can provide users with input data of software (SW) models and model logic, various setting information, and result analysis based on modeling results.
모델분석부(1300)는 소프트웨어(SW)모델 및 모델 로직이 수행되는 경우 여러 가지 시나리오 정보를 설정할 수 있다.The model analysis unit (1300) can set various scenario information when a software (SW) model and model logic are performed.
예를 들어 여러 가지 시나리오 정보로 제조 시스템 기준 정보 입력값, 라이브러리 엔진 세트(1150)의 버전 등을 수정 할 수 있다.For example, the input values of manufacturing system reference information, the version of the library engine set (1150), etc. can be modified with various scenario information.
모델실행부(1400)는 소프트웨어(SW)모델 및 모델 로직을 실행하고 생산 계획 데이터를 생성하여 모델분석부(1300)가 분석할 수 있는 생산 계획 데이터를 제공할 수 있다.The model execution unit (1400) can execute a software (SW) model and model logic and generate production plan data to provide production plan data that can be analyzed by the model analysis unit (1300).
클라이언트의 제조생산시스템(100)의 시스템운영부(110)는, 모델개발부(1100)가 개발한 소프트웨어(SW)모델 및 모델 로직을 서버관리부(1200)를 통해 수신한 경우, 데이터베이스(150)로부터 기준 정보 데이터가 포함된 입력데이터를 제공받고, 이를 이용하여 수신한 소프트웨어모델 및 로직세트직세트를 실행하여 생산 계획 데이터를 생성할 수 있다.When the system operation unit (110) of the client's manufacturing production system (100) receives the software (SW) model and model logic developed by the model development unit (1100) through the server management unit (1200), it receives input data including reference information data from the database (150) and can use this to execute the received software model and logic set to generate production plan data.
생성된 생산 계획 데이터는 데이터베이스(150)에 다시 업로드되어 저장될 수 있다.The generated production plan data can be uploaded back to the database (150) and stored.
실시 예에 따르면 온프레미스 컴퓨팅 시스템(1000)은 클라이언트로부터 제조생산시스템의 기준 정보를 포함하는 입력데이터를 수신하여 개발한 소프트웨어(SW)모델 및 모델 로직을 실행하여 생산 계획 데이터를 생성할 수 있다. 또는 온프레미스 컴퓨팅 시스템(1000)가 제공한 소프트웨어모델 및 로직세트를 이용하여 클라이언트의 제조생산시스템(100)은 생산 계획 데이터를 생성할 수도 있다.According to an embodiment, the on-premise computing system (1000) may receive input data including reference information of a manufacturing production system from a client and execute a developed software (SW) model and model logic to generate production plan data. Alternatively, the client's manufacturing production system (100) may generate production plan data using the software model and logic set provided by the on-premise computing system (1000).
온프레미스 컴퓨팅 시스템(1000)의 각 구성요소의 상세한 실시 예들은 이하에서 후술한다.Detailed embodiments of each component of the on-premise computing system (1000) are described below.
도 3은 디지털 생산 계획 데이터를 제공하는 컴퓨팅 시스템의 다른 일 실시 예를 개시한다.FIG. 3 discloses another embodiment of a computing system that provides digital production planning data.
이 도면은 디지털 생산 운영 데이터를 제공ff하는 클라우드 컴퓨팅 시스템의 일 실시 예를 개시한다. 실시 예에 따른 클라우드 컴퓨팅 시스템은 디지털 생산 계획 데이터를 SaaS (Software-as-a-Service)로 제공할 수 있다.This drawing discloses an embodiment of a cloud computing system that provides digital production operation data. According to the embodiment, the cloud computing system can provide digital production planning data as a Software-as-a-Service (SaaS).
개시하는 실시 예는 데이터베이스(150)를 포함하는 클라이언트 제조생산시스템(100)은, 클라우드 컴퓨팅 시스템(2000)에 제조생산시스템의 기준 정보가 포함된 입력데이터를 제공하고 그 결과로서 생산 계획 데이터를 제공받을 수 있다.In the disclosed embodiment, a client manufacturing production system (100) including a database (150) can provide input data including reference information of the manufacturing production system to a cloud computing system (2000) and receive production plan data as a result.
클라이언트 시스템의 상황에 최적화된 생산 계획 데이터를 제공하는 클라우드 컴퓨팅 시스템(2000)은, 운영관리부(2100), 정의된 소프트웨어모델 및 로직세트를 실행하는 모델실행부(2400) 및 클라우드 데이터베이스(2500)을 포함할 수 있다.A cloud computing system (2000) that provides production planning data optimized for the circumstances of a client system may include an operation management unit (2100), a model execution unit (2400) that executes a defined software model and logic set, and a cloud database (2500).
클라우드 컴퓨팅 시스템(2000)의 라이브러리 엔진 세트(2210)는 소프트웨어 모델을 생성하는 주요 데이터를 포함하는 코어라이브러리와 생산 계획을 생성하는 여러 캡슐화된 기능블록세트인 생산 계획 엔진을 포함한다.The library engine set (2210) of the cloud computing system (2000) includes a core library containing key data for generating a software model and a production planning engine which is a set of several encapsulated function blocks for generating a production plan.
클라우드 컴퓨팅 시스템(2000)은 온프레미스 컴퓨팅 시스템에서 별도로 개발한 것과 다르게 제품이나 시나리오에 일반화되어 이미 정의된 소프트웨어모델 및 로직세트(2230)을 포함한다. 하지만 클라이언트의 커스텀화된 생산 운영 계획을 생성하기 위한 커스텀 라이브러리 엔진 세트(2250)을 더 포함할 수 있다.Unlike separately developed on-premise computing systems, the cloud computing system (2000) includes pre-defined software models and logic sets (2230) generalized to products or scenarios. However, it may further include a set of custom library engines (2250) for generating customized production operation plans for clients.
클라이언트 제조생산시스템(100)은 제조생산시스템의 기준 정보를 포함하는 생산 운영에 관련된 입력데이터를 저장한 데이터베이스(150)를 포함한다.The client manufacturing production system (100) includes a database (150) that stores input data related to production operations including standard information of the manufacturing production system.
클라이언트 제조생산시스템(100)은 데이터베이스(150)에 저장된 입력데이터의 스키마를 변환하는 인바운드로직(170)을 실행하고 변환된 입력데이터를 클라우드 데이터베이스(2500)에 업로드할 수있다.The client manufacturing production system (100) can execute inbound logic (170) that converts the schema of input data stored in the database (150) and upload the converted input data to the cloud database (2500).
클라이언트 제조생산시스템(100)의 인바운드로직(170)의 실행에 따라 클라이언트의 기준 정보 데이터를 포함하는 입력데이터가 클라우드 데이터베이스(2500)에 저장될 수 있다.According to the execution of the inbound logic (170) of the client manufacturing production system (100), input data including the client's reference information data can be stored in the cloud database (2500).
운영관리부(2100)는 클라이언트나 클라우드 시스템 관리자의 설정에 따라 라이브러리 엔진 세트(2210), 소프트웨어모델 및 로직세트(2230) 및 커스텀 라이브러리 엔진 세트(2250)를 기반으로 클라우드 데이터베이스(2500)에 저장된 입력데이터를 이용하여 생산 계획 데이터를 생성한다.The operation management unit (2100) generates production plan data using input data stored in the cloud database (2500) based on the library engine set (2210), software model and logic set (2230), and custom library engine set (2250) according to the settings of the client or cloud system administrator.
생성된 생산 계획 데이터는 다시 클라우드 데이터베이스(2500)에 저장될 수 있다.The generated production plan data can be stored again in the cloud database (2500).
클라우드 컴퓨팅 시스템(2000)은 클라우드 데이터베이스(2500)에 저장된 생산 계획 데이터를 일정한 사용자 인터페이스로 제공하는 아웃바운드 API(2710)를 통해 클라이언트에 제공한다.The cloud computing system (2000) provides production plan data stored in a cloud database (2500) to a client through an outbound API (2710) that provides a consistent user interface.
클라이언트는 클라우드 컴퓨팅 시스템(2000)에서 모델을 실행을 위한 설정하거나, 커스텀 라이브러리 엔진 세트(2250)를 수정하거나 또는 최종 생산 계획 데이터를 얻을 수 있는 인터페이스를 가질 수 있다.The client may have an interface to set up a model for execution on a cloud computing system (2000), modify a set of custom library engines (2250), or obtain final production plan data.
온프레미스 컴퓨팅 시스템(1000)과 다른 기능을 가지는 클라우드 컴퓨팅 시스템(2000)의 각 구성요소들의 상세한 실시 예들은 이하에서 후술한다.Detailed embodiments of each component of a cloud computing system (2000) having different functions from an on-premise computing system (1000) are described below.
이하의 실시 예에서는 설치된 라이브러리 엔진 세트를 기반으로 생성된 소프트웨어모델 및 로직 세트를 이용하여 생산 계획 데이터를 제공하는 일 예를 상세히 개시한다.The following examples detail an example of providing production planning data using a software model and logic set generated based on an installed set of library engines.
설명한 바와 같이 온프레미스 컴퓨팅 시스템(1000)의 모델개발부(110)은, 라이브러리 엔진 세트(1150)를 기반으로 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트를 개발할 수 있는 프레임을 제공한다.As described, the model development unit (110) of the on-premise computing system (1000) provides a frame for developing a software model and logic set capable of generating a production plan based on a library engine set (1150).
다른 예로서, 클라우드 컴퓨팅 시스템(2000)은, 라이브러리 엔진 세트를 기반으로 생산 계획을 생성할 수 있는 정형화된 다수의 소프트웨어모델 및 로직 세트들을 제공할 수 있다.As another example, the cloud computing system (2000) may provide a number of standardized software models and logic sets that can generate production plans based on a set of library engines.
개시하는 실시 예에서 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트는 시간 역산 방식으로 생산 계획을 스케줄링하여 공정목표(Step Target)을 산출할 수 있다. 공정목표(Step Target)는 공정의 목표생산수량(Quantity) 정보와 시점(Date) 정보를 포함할 수 있다. 여기서 시간 역산 방식으로 생산 계획을 스케줄링하는 방식을 백워드 플래닝(backward planning)으로 호칭할 수 있다.In the disclosed embodiment, a software model and logic set capable of generating a production plan can schedule the production plan using a time-reversal method to derive a process target (Step Target). The process target (Step Target) may include information on the target production quantity (Quantity) and time point (Date) of the process. Here, the method of scheduling the production plan using a time-reversal method may be referred to as backward planning.
라이브러리 엔진 세트(1150)은 시간 역산 방식으로 백워드 플래닝(backward planning) 로직을 생성할 수 있는 코어 라이브러리를 제공할 수 있다.The library engine set (1150) can provide a core library capable of generating backward planning logic in a time-reversal manner.
모델개발부(110)는 라이브러리 엔진 세트(1150)를 기반으로 백워드 플래닝(backward planning) 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하도록 할 수 있다. 여기서, 백워드 플래닝(backward planning) 방식은, 수요(demand) 정보의 납기일과 목표생산수량(Quantity) 정보로부터 시간과 수량을 역산하여 작업물을 할당하는 방식이다.The model development unit (110) can generate a software model and logic set including backward planning logic based on a library engine set (1150). Here, the backward planning method is a method of allocating work by calculating the time and quantity backward from the due date of demand information and target production quantity information.
즉, 수요 정보에 포함된 완제품의 납기일까지 생산되기 위해 공정별 투입대기시간(Wait TAT), 공정별 작업시간(Run TAT) 및 공정별 수율(Yield)을 기반으로, 생산 프로세스의 공정의 투입목표(In Target)의 수량(Qunatity)과 시점(Date), 공정의 완료목표(Out Target)의 수량(Quantity)과 시점(Date)을 산출할 수 있다.That is, based on the process-specific input waiting time (Wait TAT), process-specific operation time (Run TAT), and process-specific yield (Yield), the quantity (Quantity) and date of the process's input target (In Target) and the quantity (Quantity) and date of the process's completion target (Out Target) can be calculated in order to produce the finished product included in the demand information by the due date.
예를 들어 수요 정보, 즉 완제품의 납기시점과 수량 정보는, 완제품의 납기시점을 맞추기 위한 제N 공정의 완료목표(Out Target)의 수량(Quantity)과 시점정보(Date)를 기반하여 작업시간(RUN TAT)과 수율 정보(YIELD)로 역산하여 제 N 공정의 투입목표(In Target)의 수량(Qunatity)과 시점(Date) 정보를 산출한다.For example, demand information, that is, the delivery time and quantity information of the finished product, is calculated based on the quantity (Quantity) and time information (Date) of the completion target (Out Target) of the Nth process to meet the delivery time of the finished product, and the work time (RUN TAT) and yield information (YIELD) are used to produce the quantity (Quantity) and time (Date) information of the input target (In Target) of the Nth process.
그리고, 완제품의 납기시점을 맞추기 위한 제 N 공정의 투입목표(In Target)의 수량(Qunatity)과 시점(Date) 정보을 기반하여 투입대기시간(Wait TAT) 등을 고려하면 제 (N-1) 공정의 완료목표(Out Target)의 수량(Qunatity)과 시점(Date)정보를 역산할 수 있다.And, based on the quantity (Quantity) and time (Date) information of the input target (In Target) of the Nth process to meet the delivery time of the finished product, the quantity (Quantity) and time (Date) information of the completion target (Out Target) of the (N-1)th process can be reverse-calculated by considering the input waiting time (Wait TAT).
이와 같이 1, 2, 3,…N 개의 공정별 작업시간(Run TAT) 및 수율정보(Yield)와, 그 공정의 투입대기시간(Wait TAT)을 역산하면 생산 계획을 산출할 수 있다.In this way, by calculating the operation time (Run TAT) and yield information (Yield) for each process (1, 2, 3,… N) and the input waiting time (Wait TAT) for that process, a production plan can be derived.
결과적으로 백워드 플래닝(backward planning) 방식은 수요 정보에 대해 납기일과 수량을 만족하기 위한 공정목표(Step Target) 정보를 산출할 수 있다.As a result, the backward planning method can produce step target information to satisfy the delivery date and quantity based on demand information.
여기서 공정목표(Step Target) 정보는, 공정의 투입계획시점정보(Inplan Date), 투입계획시점의 수량정보(Inplan Quantity), 공정의 완료정보(Outplan Date), 및 완료시점의 수량정보(Outplan Quantity)를 포함할 수 있다.Here, the process target (Step Target) information may include process input plan time information (Inplan Date), input plan quantity information (Inplan Quantity), process completion information (Outplan Date), and completion time quantity information (Outplan Quantity).
다른 예로서 공정목표(Step Target) 정보는, 공정의 투입목표시점정보(In Target Date), 투입목표시점의 수량정보(In Target Quantity), 공정의 완료목표시점정보(Out Target Date), 및 완료목표시점의 수량정보(Out Target Quantity)를 포함할 수도 있다.As another example, the step target information may include the process input target date information (In Target Date), input target date quantity information (In Target Quantity), process completion target date information (Out Target Date), and completion target date quantity information (Out Target Quantity).
위와 같이 경우에 따라 공정목표(Step Target) 정보는 공정의 투입계획(Inplan)정보와 완료정보 (Outplan)를 사용할 수도 있고, 투입목표(In Target)정보와 완료목표(Out Target)정보를 사용할 수도 있다.As above, in some cases, the process target (Step Target) information may use the process input plan (Inplan) information and completion information (Outplan), or the input target (In Target) information and completion target (Out Target) information.
도 4는 실시 예에 따른 백워드 플래닝 로직이 수행하는 절차들을 예시한 도면이다. 이 도면을 참조하여 백워드 플래닝 로직이 수행하는 절차들의 실시 예를 개념적으로 설명하면 다음과 같다.Figure 4 is a diagram illustrating the procedures performed by backward planning logic according to an embodiment. Referring to this diagram, an embodiment of the procedures performed by the backward planning logic is conceptually explained as follows.
백워드 플래닝 로직은, 공정 별 작업의 대기 상태(Wait) 또는 작업 상태(Run)의 시작 또는 완료시점에서 프로세스의 마지막 공정부터 시간 역산 방향으로 전개하면서 생산 계획에 필요한 정보를 얻을 수 있다.Backward planning logic can obtain information necessary for production planning by progressing backwards in time from the last process of the process at the start or completion point of the waiting state (Wait) or the working state (Run) of each process.
이 도면에서 생산을 위한 작업이 제1공정(step 1),…제 (i-1) 공정(step i-1) 및 제 I 공정 (step i)의 순으로 진행된다고 가정한다.In this drawing, it is assumed that the work for production proceeds in the order of the first process (step 1), the (i-1) process (step i-1), and the I process (step i).
백워드 플래닝을 이용해 생산 계획을 생성하면 각 공정은 각 작업에 작업물이 투입되는 투입목표정보(In Target)(시점과 수량 포함)와 완료목표정보(Out Target)(시점과 수량 포함)을 가진다.When creating a production plan using backward planning, each process has input target information (In Target) (including time and quantity) and completion target information (Out Target) (including time and quantity) for inputting work materials to each task.
여기서, 제1공정(step 1)의 투입목표정보(In target 1), 제 (i-1) 공정의 투입목표정보(In target i-1), 및 제 I 공정의 투입목표정보(In target i)의 시점정보를 각각 화살표로 표시하였다. 그리고, 제 (i-1) 공정의 완료목표정보(Out target i-1), 및 제 I 공정의 완료목표정보(Out target i)의 시점정보를 나타내었다.Here, the input target information (In target 1) of the first process (step 1), the input target information (In target i-1) of the (i-1) process, and the time point information of the input target information (In target i) of the I process are indicated by arrows. In addition, the time point information of the completion target information (Out target i-1) of the (i-1) process and the completion target information (Out target i) of the I process are indicated.
백워드 플래닝 로직에서 각 공정의 투입목표시점과 완료목표시점은, 생산 계획을 산출하는 시간 처리 포인트가 될 수 있다.In backward planning logic, the input target time and completion target time of each process can become time processing points for producing a production plan.
각 공정은 작업시간(Run TAT) 동안 작업이 진행되며, 제 (i-1) 공정의 완료목표시점(Out target i-1)으로부터 제 I 공정의 투입시점(In target i)까지 작업물은 투입대기시간(Wait TAT)동안 대기할 수 있으며 각 공정은 수율정보(Yield)를 가질 수 있다.Each process is performed during the work time (Run TAT), and the workpiece can wait for the input waiting time (Wait TAT) from the completion target time (Out target i-1) of the (i-1) process to the input time (In target i) of the I process, and each process can have yield information (Yield).
백워드 플래닝 시에, 제 I 공정에서 그 공정의 작업 분량에 대한 페깅(Run lot pegging), 작업시간(Run TAT) 및 수율정보(Yield)가 반영된다. 그리고, 제 I 공정과 제 (i-1) 공정 사이에서는 작업 대기 분량에 대한 페깅(Wait lot pegging)과, 투입대기시간(Wait TAT)이 반영된다.In backward planning, the pegging of the work volume of the process (Run Lot Pegging), the work time (Run TAT), and yield information (Yield) are reflected in Process I. Furthermore, between Process I and Process (i-1), the pegging of the work volume waiting (Wait Lot Pegging) and the input waiting time (Wait TAT) are reflected.
이와 같이 백워드 플래닝 로직은, 공정들의 순서인 프로세스의 마지막 공정으로부터 첫 공정까지 시간의 역방향으로 전개하면서 생산 계획에 필요한 정보를 얻을 수 있다.In this way, backward planning logic can obtain the information necessary for production planning by progressing backwards in time from the last process of the process to the first process, which is the sequence of processes.
도 5는 실시 예에 따른 라이브러리 엔진 세트 내의 백워드 플래닝 로직의 수행 단계를 예시한 도면이다.FIG. 5 is a diagram illustrating the execution steps of backward planning logic within a library engine set according to an embodiment.
라이브러리 엔진 세트가 백워드 플래닝 로직을 포함하는 경우, 클라이언트의 데이터 스키마를 기반으로 생성된 소프트웨어 모델 및 로직 세트는 백워드 플래닝 로직에 따라 생산 계획을 생성할 수 있다.If the library engine set includes backward planning logic, the software model and logic set generated based on the client's data schema can generate a production plan according to the backward planning logic.
이하에서는 라이브러리 엔진 세트 내의 백워드 플래닝 로직의 실시 예를 용이하게 설명하기 위해, 생성된 소프트웨어 모델 및 로직 세트가 백워드 플래닝 방식에 따라 생산 계획 데이터를 생성하는 예를 개시한다.Below, to facilitate the explanation of an embodiment of backward planning logic within a library engine set, an example is disclosed in which a generated software model and logic set generate production planning data according to a backward planning method.
백워드 플래닝(backward planning) 방식은 수요정보전처리단계(Demand Manipulation)(210), 페깅초기화단계(Pegging Initialization)(220), 시설분배단계(Site allocation)(230), 페깅단계(Pegging)(240) 및 투입계획산출단계(make inplan)(250)을 포함할 수 있다.The backward planning method may include a demand manipulation stage (210), a pegging initialization stage (220), a site allocation stage (230), a pegging stage (240), and a make inplan stage (250).
생성된 소프트웨어모델 및 로직 세트는, 백워드 플래닝(backward planning)을 수행하기 위해 제조생산시스템 기준 정보로부터 수요 정보(demand), 기 생산기록 정보(ACT), 현재 작업중인 작업물 수량정보(Wip, work in process), 공정흐름정보(BOP, Bill of process), 수율정보(Yield), 및 공정별 시간정보(TAT)( 투입대기시간(Wait TAT) 또는 공정별 작업시간(Run TAT))를 얻을 수 있다.The generated software model and logic set can obtain demand information (demand), production record information (ACT), work-in-process (WIP) quantity information (WiP), process flow information (BOP, Bill of Process), yield information (Yield), and process-specific time information (TAT) (Wait TAT or Run TAT)) from the manufacturing production system reference information to perform backward planning.
수요정보전처리단계(S210)은 제조생산시스템으로 수신된 데이터 중 수요정보(demand), 제조생산시스템의 실제 기 생산기록정보(act), 잔여 수요 수량, 및 생산 일정에 기반하여 수요정보(demand)를 전처리할 수 있다.The demand information preprocessing step (S210) can preprocess demand information (demand) based on the demand information (demand), actual production record information (act) of the manufacturing production system, remaining demand quantity, and production schedule among the data received by the manufacturing production system.
예를 들어, 수요정보(demand)로부터 실제 기 생산기록(act)을 차감한 잔여 수요 수량(demand quality)을 작업 일정에 따라 나누어 산출할 수 있다.For example, the remaining demand quantity (demand quality) obtained by subtracting the actual production record (act) from the demand information (demand) can be calculated by dividing it according to the work schedule.
수요 정보(demand)가 주간 계획에 따라 납기일이 작성되었다면 잔여 수요 수량(demand quality)과 납기를 일별로 분배하는 전처리된 일별 계획으로 변경하는 전처리 작업(Preprocess)을 할 수 있다.If the demand information (demand) has a due date written according to the weekly plan, a preprocessing task (preprocessing) can be performed to change it into a preprocessed daily plan that distributes the remaining demand quantity (demand quality) and due date by day.
페깅초기화단계(S220)는 전처리된 수요 정보를 백워드 플래닝하는 데이터로 초기화하는 단계로서, 해당 데이터를 초기화 후 검증하여 이후 단계에 문제가 없는지 확인할 수 있다. 예를 들면 전처리되어 초기화된 수요정보 중 동일 제품, 제품 그룹, 공정 등의 단위로 그룹화하여 백워드 플래닝의 대상이 되는 작업객체 정보(PegPart)를 초기화할 수 있다.The peg initialization step (S220) initializes preprocessed demand information as data for backward planning. This data can be verified after initialization to ensure there are no issues in subsequent steps. For example, among the preprocessed and initialized demand information, work object information (PegPart) that is the target of backward planning can be initialized by grouping it into units such as the same product, product group, or process.
백워드 플래닝 방식에서 각 공정별로 작업시간, 공정, 수량, 납기 등의 정보가 변하는데 각 공정에 따라 변하는 작업객체 정보(PegPart)를 초기화하여 생성할 수 있다. 이에 대해서는 후술한다.In backward planning, information such as working hours, processes, quantities, and delivery dates change for each process. Work object information (PegPart) that changes depending on each process can be initialized and created. This will be described later.
시설분배단계(S230)는 초기화된 작업객체 정보(PegPart)를 입력받는다. 시설분배단계(S230)은 하나의 제조생산시스템에 여러 개의 생산 시설(Site)가 존재할 경우, 수요정보를 분배 규칙(Rule)에 따라 생산 시설별로 분배하는 단계를 수행할 수 있다. 시설분배단계(230)의 수행은 클라이언트의 제조생산시스템 혹은 별도의 외부 솔루션에서 도출된 결과물로부터 사전에 시설분배정보를 얻는 경우 시설분배단계(S230)의 수행은 생략될 수 있다.The facility distribution step (S230) receives initialized work object information (PegPart). If multiple production facilities (Sites) exist in a single manufacturing production system, the facility distribution step (S230) can distribute demand information to each production facility according to a distribution rule (Rule). The facility distribution step (230) can be omitted if facility distribution information is obtained in advance from the client's manufacturing production system or results derived from a separate external solution.
페깅단계(S240)는 초기화된 작업객체 정보(PegPart)와 전단계인 시설분배단계(S230)의 분배정보를 입력받는다.The pegging step (S240) receives the initialized work object information (PegPart) and the distribution information of the previous step, the facility distribution step (S230).
페깅단계(S240)는 초기화된 수요 정보를 기준으로 각 공정의 완료목표시점정보(Out Target Date), 및 완료목표시점의 수량정보(Out Target Quantity), 각 공정의 투입목표(In Target)정보와 완료목표(Out Target)정보 등을 계산하여 최종적으로 페깅 히스토리(Peghistory)를 포함하는 로그 기록 정보와 공정목표(Step Target) 정보를 출력할 수 있다.The pegging step (S240) calculates the completion target date information (Out Target Date) of each process, the quantity information at the completion target date (Out Target Quantity), the input target (In Target) information and the completion target (Out Target) information of each process based on the initialized demand information, and can output log record information including the pegging history (Peghistory) and the process target (Step Target) information.
그리고 페깅단계(S240)는 다음 단계의 공정에 대한 투입계획(Inplan)정보(수량 및 시점포함)를 포함하는 여러 가지 객체 정보를 산출할 수 있다.And the pegging step (S240) can produce various object information including input plan (Inplan) information (including quantity and timing) for the process of the next step.
페깅단계(S240)는 각 공정의 산출 객체 정보로서 각 공정의 작업 중인 작업물 수량정보(Wip)에 포함되는 정보들을 각각 산출할 수 있다. 예를 들어 산출 객체 정보로서 작업물 수량정보(Wip)는 공정들에 따른 우선 순위 정렬, 공정의 선택, 공정의 작업 수량, 공정의 납기 정보, 공정 시간 갱신, 공정의 수율 적용, 공정의 로그 기록 정보 등을 포함할 수 있다.The pegging step (S240) can generate information contained in the work-in-progress quantity information (WIP) of each process as output object information for each process. For example, the work-in-progress quantity information (WIP) as output object information can include priority sorting by process, process selection, process work quantity, process due date information, process time update, process yield application, process log record information, etc.
공장투입계획산출단계(S250)는 전단계인 페깅단계(S240)의 출력한 정보를 수신하고, 최후 공정 단계의 수요 정보로부터 최초 공정의 공장투입계획정보(Release Plan)(수량 및 시점포함)를 산출할 수 있다.The factory input plan calculation step (S250) receives the information output from the previous step, the pegging step (S240), and can calculate the factory input plan information (Release Plan) (including quantity and timing) of the first process from the demand information of the final process step.
투입계획(Inplan)정보(수량 및 시점포함)를 이용하면 시간 순으로 생산 계획을 생성하는 포워드 플래닝(Forward planning)의 가이드 정보를 얻을 수 있으며, 실시 예에서 투입계획산출단계(250)의 수행은 생략될 수도 있다.By using the input plan (Inplan) information (including quantity and time), guide information for forward planning that creates a production plan in chronological order can be obtained, and in the embodiment, the execution of the input plan calculation step (250) may be omitted.
따라서, 실시 예에 따라 소프트웨어 모듈 및 모듈 로직이 백워드 플래닝 로직을 수행하면 공정 목표(Step Target) 및 공정의 투입계획(Inplan)정보를 산출할 수 있다.Therefore, when the software module and module logic perform backward planning logic according to an embodiment, the process target (Step Target) and process input plan (Inplan) information can be produced.
도 6은 실시 예에 따른 백워드 플래닝을 수행하는 일 예를 나타낸 도면이다Figure 6 is a diagram showing an example of performing backward planning according to an embodiment.
백워드 플래닝은 수요 정보로부터 역산하여 공정의 투입목표(In Target)정보와 공정의 완료목표정보(Out Target)에서 생산 계획을 산출할 수 있다.Backward planning can calculate the production plan from the process input target (In Target) information and the process completion target information (Out Target) by calculating backwards from the demand information.
이 예에서 실제 공정 프로세스는, 제 1 공정(step S1), 제 2 공정(step S2), 제 3 공정(step S3) 순으로 진행된다고 가정한다. 백워드 플래닝 방식은, 이 3개의 공정들을 포함하는 프로세스의 목표 수요(demand) 정보를 고려하여 제 3 공정(step S3), 제 2 공정(step S2), 제 1 공정(step 200)순으로 공정들의 순서를 역으로 하여 생산 계획을 산출한다.In this example, it is assumed that the actual production process proceeds in the following order: Step 1 (step S1), Step 2 (step S2), and Step 3 (step S3). The backward planning method considers the target demand information for the process including these three processes and generates a production plan by reversing the order of the processes in the following order: Step 3 (step S3), Step 2 (step S2), and Step 1 (step 200).
기준 정보의 수요 (demand) 정보는, 표(261)같이, 그 수요 정보로부터 실제 기 생산기록(act)을 차감한 잔여 수요 수량(demand quality)에 대해 일정(D0, D1, D2, D3, D4)에 따라 나누어 장비(A 또는 B)에 배치된다.The demand information of the standard information is divided into schedules (D0, D1, D2, D3, D4) and placed on equipment (A or B) based on the remaining demand quantity (demand quality) obtained by subtracting the actual production record (act) from the demand information, as shown in Table (261).
백워드 플래닝은, 표(261)에 대해 제 3 공정(step S3)의 공정 작업시간(Run TAT)과 수율(Yield) 100%를 반영하여 제 3 공정(step S3)의 도달시점(In target)의 중간 생산 계획인 표(263)을 산출할 수 있다. 표(263)은 공정 작업시간(Run TAT)이 0 day(일)이고 수율(Yield) 100%이므로 표(261)와 동일한 값을 갖는다.Backward planning can produce an intermediate production plan (Table 263) for the arrival point (In target) of the third process (step S3) by reflecting the process operation time (Run TAT) and yield (Yield) of 100% for the third process (step S3) in Table (261). Table (263) has the same value as Table (261) because the process operation time (Run TAT) is 0 day and the yield (Yield) is 100%.
그리고 백워드 플래닝은, 표(263)의 중간 생산 계획에 대해 제 3 공정(step S3)의 투입대기시간(Wait TAT) (1 일)과 작업 대기 분량에 대한 페깅(Wait lot pegging)을 반영하여, 제 2 공정(step S2)의 완료목표시점(out target)의 중간 생산 계획인 표(265)을 산출할 수 있다. 표(265)는 제 2 공정(step S2)의 투입대기시간(Wait TAT) (1 일)을 반영하여 표(263)의 일정들(D0, D1, D2, D3, D4) 내의 데이터가 1일씩 쉬프트된 값을 가진다.And backward planning can produce table (265), which is an intermediate production plan for the out target time of the second process (step S2), by reflecting the Wait TAT (1 day) of the third process (step S3) and the pegging for the waiting work amount for the intermediate production plan of table (263). Table (265) has data in the schedules (D0, D1, D2, D3, D4) of table (263) shifted by 1 day by reflecting the Wait TAT (1 day) of the second process (step S2).
백워드 플래닝은, 표(265)의 중간 생산 계획에 대해, 제 2 공정(step S2)의 수율(50%), 작업 분량에 대한 페깅(Run lot pegging), 및 공정 작업시간(Run TAT)을 반영하여, 제 2 공정(step S2)의 투입목표(In Target) 시점의 중간 생산 계획인 표(267)을 산출할 수 있다. 표(267)의 각 일정 내의 값은 제 2 공정(step S2)의 수율(505)과 공정 작업시간(Run TAT)(1 day)을 역산하여, 표(265)의 각 일정이 쉬프트되고 표(265)의 값보다 두배의 값을 가질 수 있다.Backward planning can produce an intermediate production plan (Table 267) at the input target (In Target) point of the second process (step S2) by reflecting the yield (50%), pegging for the work amount (Run lot pegging), and process operation time (Run TAT) of the second process (step S2) for the intermediate production plan of Table (265). The values in each schedule of Table (267) can be shifted and have twice the values of Table (265) by backward calculating the yield (50%) and process operation time (Run TAT) (1 day) of the second process (step S2).
이 예에서 마지막으로 백워드 플래닝은, 표(267)의 중간 생산 계획에 대해, 제 1 공정(step S1)의 완료목표(Out Target) 시점에서 제 2 공정(step S2)의 작업 대기 분량에 대한 페깅(Wait lot pegging)과 투입대기시간(Wait TAT) (1일)을 역산하여 표(269)의 생산 계획을 산출할 수 있다. 표(269)는 제 2 공정(step S2)의 투입대기시간(Wait TAT) (1일)을 역산하여 표(267)의 각 일정이 쉬프트된 값을 가질 수 있다.In this example, the last backward planning can produce the production plan of Table (269) by calculating the Wait Lot Pegging and Wait TAT (1 day) for the work waiting amount of the second process (step S2) at the time of the Out Target of the first process (step S1) for the intermediate production plan of Table (267). Table (269) can have each schedule of Table (267) shifted by calculating the Wait TAT (1 day) of the second process (step S2) backward.
이와 같이 백워드 플래닝은 수요 정보에 대해, 투입목표(In Target)의 시점과 수량, 그리고 완료목표(Out Target)의 시점과 수량을 산출하기 위해 작업 분량, 대기 분량, 및 수율 등을 고려하여 생산 계획 정보를 역산하여 산출할 수 있다.In this way, backward planning can calculate production plan information by considering work volume, waiting volume, and yield to calculate the timing and quantity of the input target (In Target) and the timing and quantity of the completion target (Out Target) based on demand information.
이와 같은 백워드 플래닝은 목표 납기일과 생산량인 정보를 위와 같은 방식으로 역산하여 공정의 투입목표(In Target)정보와 완료목표(Out Target)정보를 생성할 수 있다. 그리고 투입목표(In Target)정보와 완료목표(Out Target)정보를 활용하여 시간 순방향에 따라 생산 계획을 스케줄링하는 포워드 플래닝 방식으로 계산하면 생산 계획을 산출할 수 있다.This type of backward planning can generate process input target (In Target) and output target (Out Target) information by calculating target delivery dates and production volumes in the same manner as described above. Furthermore, by using the input target (In Target) and output target (Out Target) information, a forward planning method can be used to schedule production in a chronologically forward direction, resulting in a production plan.
도 7은 실시 예에 따른 백워드 플래닝 로직을 포함하는 소프트웨어 모델 및 로직 세트를 이용하여 생산 계획을 생성하는 흐름도이다.FIG. 7 is a flowchart illustrating a production plan using a software model and logic set including backward planning logic according to an embodiment.
클라이언트 제조생산시스템의 데이터 스키마를 기반으로 백워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공한다(S22).Create or provide a software model and logic set including backward planning logic based on the data schema of the client manufacturing production system (S22).
생산 계획을 실행하는 클라이언트의 데이터 스키마는 그 클라이언트가 제공하는 기준 정보와 관련된 데이터의 구조나 종류 등을 미리 알고 있을 경우 미리 준비할 수 있다. 또는 상기 클라이언트로부터 생산 실행을 위한 기준 정보를 포함하는 입력데이터의 데이터 스키마를 수신할 수도 있다.The data schema of a client executing a production plan can be prepared in advance if the structure and type of data related to the reference information provided by the client are known in advance. Alternatively, a data schema of input data containing reference information for production execution can be received from the client.
온프레미스 컴퓨팅 시스템에서 라이브러리 엔진 세트가 백워드 플래닝 로직을 포함하는 경우, 클라이언트의 데이터 스키마를 기반으로 소프트웨어모델 및 로직 세트를 생성할 수 있다.In on-premises computing systems, if a set of library engines includes backward planning logic, it is possible to generate a set of software models and logic based on the client's data schema.
클라우드 컴퓨팅 시스템의 경우 백워드 플래닝 로직을 포함하는 라이브러리 엔진 세트를 기반으로 백워드 플래닝 로직을 실행하는 소프트웨어모델 및 로직 세트를 제공할 수 있다.For cloud computing systems, a software model and logic set that executes backward planning logic can be provided based on a set of library engines that include backward planning logic.
소프트웨어모델 및 로직 세트는 위에서 개시한 백워드 플래닝 로직을 포함할 수 있다. 백워드 플래닝 로직에 대한 상세한 실시 예는 도 4 내지 도 6에서 개시하였다.The software model and logic set may include the backward planning logic described above. Detailed embodiments of the backward planning logic are described in FIGS. 4 to 6.
상기 데이터 스키마에 따라 상기 클라이언트로부터 입력데이터를 수신한다(S30).Input data is received from the client according to the above data schema (S30).
온프레미스 컴퓨팅 시스템을 이용하여 생산 계획을 생성하고 제공할 경우 수신된 백워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 대해 여러 가지 조건들을 추가하여 소프트웨어모델 및 로직 세트에 대한 테스트를 수행할 수 있다.When generating and providing production plans using on-premise computing systems, you can perform tests on software models and logic sets by adding various conditions to the software models and logic sets that contain the received backward planning logic.
입력데이터는 클라이언트 제조생산시스템의 기준정보를 포함할 수 있다. 여기서 기준 정보는 각 공정의 수요 정보(demand), 기 생산기록 정보 또는 실적정보(Act), 현재 작업중인 작업물 수량정보(Wip, work in process), 공정흐름정보(BOP, Bill of process), 수율정보(Yield), 및 공정시간정보(TAT)로서 투입대기시간(Wait TAT) 또는 공정작업시간(Run TAT))를 포함할 수 있다.Input data may include baseline information of the client's manufacturing system. The baseline information may include demand information for each process, production record information or performance information (Act), work-in-process (WIP) quantity information, process flow information (BOP, Bill of Process), yield information (Yield), and process time information (TAT), such as wait time for input (Wait TAT) or process operation time (Run TAT).
수신된 입력데이터를 기반으로 상기 백워드 플래닝 로직을 포함하는 소프트웨어 모델 및 로직 세트를 수행하여 생성한 생산 계획 정보를 제공할 수 있다(S55).Based on the received input data, the software model and logic set including the above backward planning logic can be performed to provide the generated production plan information (S55).
백워드 플래닝 로직은, 입력데이터에 포함된 목표 생산량인 수요 정보를 포함하는 기준 정보로부터 시간 역산 방식으로 공정목표(step target) 정보(수량 및 목표)를 생성할 수 있다.Backward planning logic can generate process target (step target) information (quantity and target) in a time-reverse manner from reference information including demand information, which is the target production volume included in the input data.
또한 백워드 플래닝 로직은, 예시한 기준 정보에 대해 각 공정의 수요 역산(Lot-Demand pegging) 정보와 각 공정에서 시간 역산 후 최종 처리되지 않은 작업의 정보를 포함하는 히스토리 정보(Peghistory)를 생성할 수 있다.Additionally, the backward planning logic can generate history information (Peghistory) that includes the demand back-calculation (Lot-Demand pegging) information of each process for the exemplified reference information and the information of the final unprocessed work after time back-calculation in each process.
만약 위 소프트웨어모델 및 로직 세트가 포워드 플래닝 로직을 포함할 경우, 백워드 플래닝 로직으로부터 얻은 공정목표정보(Step Target) 및 공장투입계획정보(Release Plan)를 이용하여, 시간 순방향에 따라 생산 계획 정보를 생성할 수 있다.If the above software model and logic set include forward planning logic, production plan information can be generated in the forward time direction using the process target information (Step Target) and factory input plan information (Release Plan) obtained from the backward planning logic.
실시 예에 따른 백워드 플래닝 로직의 상세한 절차는 도 5에 예시하였다.A detailed procedure of the backward planning logic according to the embodiment is illustrated in Fig. 5.
위에서 개시한 실시 예들의 소프트웨어모델 및 로직 세트는 위와 같은 백워드 플래닝 로직 또는 백워드 플래닝 로직을 수행한 후 그 결과물에 따라 수행되는 포워드 플래닝 로직을 포함할 수 있다.The software model and logic set of the embodiments disclosed above may include backward planning logic as above or forward planning logic that is performed based on the result after performing the backward planning logic.
도 8은 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 개시한 도면이다.FIG. 8 is a drawing disclosing one embodiment of a device that provides digital production planning information.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(310), 저장장치(320), 인메모리(330), 프로세서(340), 출력부(350), 및 사용자인터페이스(360)를 포함할 수 있다.One embodiment of a device providing digital production planning information may include an input unit (310), a storage unit (320), an in-memory unit (330), a processor (340), an output unit (350), and a user interface (360).
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(360)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (360).
입력부(310)는 클라이언트 제조생산시스템으로부터 그 제조생산시스템의 데이터 스키마를 수신할 수 있다.The input unit (310) can receive the data schema of the manufacturing production system from the client manufacturing production system.
저장장치(320)는 입력부(310)가 수신한 데이터 스키마를 저장하거나 또는 정형화된 데이터 스키마가 미리 준비된 경우는 정형화된 데이터 스키마를 저장장치(320)에 저장에 저장할 수 있다. 저장장치(320)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다.The storage device (320) may store the data schema received by the input unit (310), or, if a standardized data schema is prepared in advance, store the standardized data schema in the storage device (320). The storage device (320) may include volatile memory or non-volatile memory.
인메모리(330)는 위에서 개시한 라이브러리 엔진세트를 저장할 수 있다.In-memory (330) can store the library engine set disclosed above.
라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다. 생산 계획 엔진은 위에서 개시하는 백워드 플래닝 로직에 대한 파일을 포함할 수 있다.A library engine set may include a production planning engine, which is a set of encapsulated function block files that generate production plans. The production planning engine may include files for the backward planning logic described above.
추가적으로 라이브러리 엔진세트는, 생산계획엔진과 함께 생산 계획을 구현하는 자료 구조가 포함된 파일인 코어라이브러리, 및 생산계획엔진의 일부 기능을 상속받아서 특정 생산 도메인에서 사용하는 로직을 구현하는 생산도메인특화엔진을 더 포함할 수 있다.Additionally, the library engine set may further include a core library, which is a file containing data structures that implement a production plan together with a production planning engine, and a production domain-specific engine that inherits some of the functions of the production planning engine and implements logic used in a specific production domain.
실시 예의 프로세서(340)는 저장장치(320)에 저장된 데이터 스키마를 입력받을 수 있다. 그리고, 프로세서(340)는 상기 데이터 스키마 및 인메모리(330)에 저장된 엔진 또는 라이브러리에 기초하여 소프트웨어모델 및 로직세트를 생성할 수 있다. 생성된 소프트웨어모델 및 로직세트는 백워드 플래닝 로직에 따라 시간 역산 방식으로 생산 계획 데이터를 생성하도록 할 수 있다. 백워드 플래닝 로직에 따라 시간 역산 방식으로 생산 계획 데이터를 생성하는 실시 예들은 도 4 내지 6에서 개시하였다.The processor (340) of the embodiment can receive a data schema stored in the storage device (320). In addition, the processor (340) can generate a software model and a logic set based on the data schema and an engine or library stored in the in-memory (330). The generated software model and logic set can generate production plan data in a time-reversal manner according to backward planning logic. Embodiments of generating production plan data in a time-reversal manner according to backward planning logic are disclosed in FIGS. 4 to 6.
프로세서(340)는 사용자인터페이스(360)의 사용자의 요청에 따라 상기 생성된 소프트웨어모델 및 로직세트를 테스트하거나 사전 실행하여 생산 계획 데이터를 얻을 수 있다. 그리고 프로세서(340)는 사용자의 요청에 따라 생산 계획 데이터를 생성하는 소프트웨어모델 및 로직을 분석하거나 테스트한 결과를 사용자인터페이스(360)를 통해 사용자에게 제공할 수 있다.The processor (340) can obtain production plan data by testing or pre-executing the generated software model and logic set at the user's request via the user interface (360). Furthermore, the processor (340) can analyze or test the software model and logic that generate the production plan data at the user's request, and provide the results to the user via the user interface (360).
프로세서(340)는 입력부(310)로부터 수신된 데이터 스키마에 따라 상기 제조생산시스템의 기준정보를 포함하는 입력데이터를 수신할 수 있다. 프로세서(340)는 백워드 플래닝 로직에 따라 시간 역산 방식이 포함된 소프트웨어모델 및 로직세트를 실행하여 생산 계획 데이터를 생성할 수 있다. 백워드 플래닝 로직에 따라 생산 계획 데이터를 생성하는 상세한 예시는 도 4 내지 도 6에 개시하였다.The processor (340) can receive input data including reference information of the manufacturing production system according to the data schema received from the input unit (310). The processor (340) can generate production plan data by executing a software model and logic set including a time inversion method according to backward planning logic. Detailed examples of generating production plan data according to backward planning logic are disclosed in FIGS. 4 to 6.
출력부(350)는 백워드 플래닝 로직을 포함한 소프트웨어모델 및 로직세트의 실행 결과에 따른 생산 계획 데이터를 클라이언트 제조생산시스템에 제공하여 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (350) can provide production plan data based on the execution results of a software model and logic set including backward planning logic to a client manufacturing production system, thereby enabling the client system to manage production or processes.
실시 예에 따르면, 클라이언트 제조생산시스템으로부터 수신되는 기준 정보에 기초하여 시간 역산 방식의 스케줄링에 따라 생산 계획 정보를 얻을 수 있다. 시간 역산 방식에 따라 각 공정의 공정목표(Step Target)정보 및 투입계획정보(Inplan)를 얻을 수 있고, 시간 역산에 따른 최후 공정의 수요 정보에 기반하여 최초 공정의 공장투입계획정보(Release Plan)를 산출할 수 있다. 이러한 시간 역산 방식을 이용하여 효율적인 생산 계획 정보를 생성하여 제공할 수 있다.According to an embodiment, production planning information can be obtained through scheduling using a time-reversal method based on reference information received from a client manufacturing system. The time-reversal method can be used to obtain process target (Step Target) information and input plan information (Inplan) for each process. Furthermore, based on demand information for the final process based on the time-reversal method, the factory input plan information (Release Plan) for the first process can be derived. Using this time-reversal method, efficient production planning information can be generated and provided.
클라이언트는 시간 역산 방식으로 생성된 생산 계획에 따라 생산을 수행하거나 또는 이를 시간 순서에 따른 생산 계획에 연결하여 조금 더 상세하고 효율적인 생산 계획을 얻을 수 있다.Clients can either perform production according to the production plan generated in a time-reverse manner or link it to a time-sequenced production plan to obtain a more detailed and efficient production plan.
이하의 실시 예에서는 설치된 라이브러리 엔진 세트를 기반으로 생성된 소프트웨어모델 및 로직 세트를 이용하여 생산 계획 데이터를 제공하는 일 예를 상세히 개시한다.The following examples detail an example of providing production planning data using a software model and logic set generated based on an installed set of library engines.
설명한 바와 같이 온프레미스 컴퓨팅 시스템(1000)의 모델개발부(1100)는 라이브러리 엔진 세트(1150)를 기반으로 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트를 개발할 수 있는 프레임을 제공한다.As described, the model development unit (1100) of the on-premise computing system (1000) provides a frame for developing a software model and logic set capable of generating a production plan based on a library engine set (1150).
다른 예로서, 클라우드 컴퓨팅 시스템(2000)은 라이브러리 엔진 세트(2210)를 기반으로 생산 계획을 생성할 수 있는 정형화된 다수의 소프트웨어 모델 및 로직 세트들을 제공할 수 있다.As another example, the cloud computing system (2000) may provide a number of standardized software models and logic sets that can generate production plans based on a set of library engines (2210).
개시하는 실시 예에서 생산 계획을 생성할 수 있는 소프트웨어 모델 및 로직 세트는 시간 순행 방식으로 실제 공장의 생산 시스템에서 이루어지는 이벤트를 가상으로 실행하여 생산 계획을 수립하는 절차들을 수행한다. 여기서 시간 순행 방식으로 생산 계획을 스케줄링하는 방식을 포워드 플래닝(forward planning)으로 호칭할 수 있다.In the disclosed embodiment, a software model and logic set capable of generating a production plan perform procedures to establish a production plan by virtually executing events occurring in an actual factory production system in a time-forward manner. The method of scheduling a production plan in a time-forward manner can be referred to as forward planning.
모델개발부(1100)는 라이브러리 엔진 세트(1150)를 기반으로 포워드 플래닝(forward planning) 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하도록 할 수 있다. 포워드 플래닝(forward planning) 방식은, 상술한 백워드 플래닝의 결과로 출력된 공장투입계획(release plan)정보, 투입계획(Inplan)정보(수량 및 시점포함), 공정 목표(Step Target)정보 및 페깅 히스토리(Peghistory)정보 중 적어도 하나에 기초하여 작업물의 최초 투입시점부터 시간 순서대로 공장 내에 발생할 수 있는 이벤트를 실행시켜 실제 생산계획의 시뮬레이션을 수행하는 방식이다.The model development unit (1100) can generate a software model and logic set including forward planning logic based on the library engine set (1150). The forward planning method is a method of performing a simulation of an actual production plan by executing events that may occur in the factory in chronological order from the time of the first input of a workpiece based on at least one of the factory release plan information, the input plan (Inplan) information (including quantity and time), the process target (Step Target) information, and the pegging history (Peghistory) information output as a result of the above-described backward planning.
예를 들어, 포워드 플래닝(forward planning) 방식은 이산 사건 시뮬레이션(discrete event simulation) 방식으로 실제 작업물이 공장 내에 투입되어 생산 종료(혹은 완료)까지 어떤 시점에 어떤 경로를 통해 어떤 작업을 처리할지를 시간 순서대로 산출하여 생산 계획의 시뮬레이션을 수행할 수 있다.For example, the forward planning method is a discrete event simulation method that can simulate the production plan by calculating in chronological order which tasks will be processed through which path at which point in time from the time an actual work item is introduced into the factory until the end (or completion) of production.
즉, 포워드 플래닝(forward planning) 방식은 백워드 플래닝(backward planning)의 결과로 산출한 공정 목표를 기초로 하여 실제 공장에서 작업물(lot) 또는 장비(equipment)와 관련하여, 작업물 배치(route), 작업물 필터링(filter), 작업물 이동(transfer), 투입 의사결정(dispatching), 작업물 투입(in), 작업물 소멸(out) 등의 이벤트 실행을 통해 세부적인 생산 계획을 산출 할 수 있다.That is, the forward planning method can produce a detailed production plan by executing events such as work lot placement (route), work filtering (filter), work transfer, input decision (dispatching), work input (in), and work output (out) in relation to work lots or equipment in an actual factory based on the process goals produced as a result of backward planning.
도 9는 실시 예에 따른 포워드 플래닝 로직이 수행하는 절차들을 예시한 도면이다. 이 도면을 참조하여 포워드 플래닝 로직이 수행하는 절차들의 실시 예를 개념적으로 설명하면 다음과 같다.Figure 9 is a diagram illustrating the procedures performed by forward planning logic according to an embodiment. Referring to this diagram, an embodiment of the procedures performed by forward planning logic is conceptually explained as follows.
포워드 플래닝 로직은, 작업물이 처음 공장에 투입되는 시점부터 완료되는 시점까지 장비 또는 작업물을 시간순서대로 실제 공장을 시뮬레이션 하여 생산 계획 및 생산 스케쥴을 산출하는 방식에 해당한다.Forward planning logic is a method of producing a production plan and schedule by simulating an actual factory in chronological order, from the time the work is first introduced to the factory until it is completed.
포워드 플래닝 로직을 통해, 실제 공장의 시뮬레이션 모델을 만들어 구동해 볼 수 있으며, 작업물 투입(in), 대기열 진입(Buffer), 작업물 이동(transfer), 작업물 배치(route), 공정 처리(processing), 장비 교체(tool change), 투입 의사결정(dispatching), 작업물 필터링(filtering), 작업물 소멸(out) 등의 이벤트를 통해 현실의 공장의 역학(dynamic)을 재현하는 생산계획을 만들 수 있다.Through forward planning logic, you can create and run a simulation model of an actual factory, and create a production plan that reproduces the dynamics of a real factory through events such as work input (in), queue entry (Buffer), work transfer (transfer), work placement (route), process processing (processing), equipment change (tool change), input decision (dispatching), work filtering (filtering), and work disappearance (out).
작업물 투입(in)은 언제 몇 개의 작업물이 공장에 투입될 지 계획하는 이벤트에 해당하고, 작업물 소멸(out)은 작업물에 대한 마지막 공정이 끝나서 작업이 완료되는 이벤트에 해당한다. 작업물 이동(transfer)는 현재 작업이 끝난 이후 작업물이 다음 공정으로 이동하는 이벤트에 해당하고, 작업물 배치(route)는 작업물이 어떤 공정으로 이동할지 결정하는 이벤트에 해당한다. 또한, 공정 처리(processing)은 장비에 투입된 작업물에 일정시간동안 할당된 작업이 처리되는 이벤트에 해당하고, 장비 교체(tool change)는 장비에 작업물이 투입되지 전에 도구 교체가 필요한 경우, 도구 교체를 진행하는 이벤트에 해당한다. 투입 의사결정(dispatching)은 대기 중인 작업물 중 어떤 작업물을 우선 작업할 거인지 결정하는 이벤트에 해당하고, 작업물 필터링(filtering)은 투입 의사결정(dispatching) 전에 작업물 또는 장비에 관련된 필터링을 결정하는 이벤트에 해당한다.Work input (in) corresponds to the event of planning when and how many work pieces will be input into the factory, while work output (out) corresponds to the event of completing the work when the last process for the work piece has finished. Work transfer (transfer) corresponds to the event of moving the work piece to the next process after the current process is finished, and work routing (route) corresponds to the event of determining which process the work piece will be moved to. In addition, process processing (processing) corresponds to the event of processing the work assigned to the work piece input into the equipment for a certain period of time, and tool change (tool change) corresponds to the event of performing a tool change if a tool change is required before the work piece is input into the equipment. Dispatching (dispatching) corresponds to the event of deciding which work piece among the waiting work pieces will be processed first, and work filtering (filtering) corresponds to the event of determining filtering related to the work piece or equipment before dispatching.
예를 들어, 어떤 공정에 대기 중이던 작업물이 투입의사 결정(dispatching)에 의해 선택되어 장비에 투입된다면, 일정 작업( 시간 이후에 어떤 공정으로 이동할지 작업물 배치(route)가 이루어질 수 있다. 또는, 작업물이 일정 작업 시간 이후에 작업물 배치(route)를 통해 작업이 완료(out)되는 것으로 결정될 수 있다. 또는, 작업물의 투입 의사결정(dispatching)이 이루어지기 전에 작업물 필터링(filtering)이 이루어지도록 계획을 만들 수 있다.For example, if a workpiece waiting for a process is selected through dispatching and put into equipment, the workpiece can be routed to a process after a certain work time. Alternatively, the workpiece can be determined to be completed (out) through workpiece routing after a certain work time. Alternatively, a plan can be made for workpiece filtering to be performed before the workpiece dispatching decision is made.
도 10은 실시 예에 따른 라이브러리 엔진 세트 내의 포워드 플래닝 로직의 수행 단계를 예시한 도면이다.FIG. 10 is a diagram illustrating the execution steps of forward planning logic within a library engine set according to an embodiment.
라이브러리 엔진 세트가 포워드 플래닝 로직을 포함하는 경우, 클라이언트의 데이터 스키마를 기반으로 생성된 소프트웨어 모델 및 로직 세트는 포워드 플래닝 로직에 따라 생산 계획을 생성할 수 있다. 일 예로서, 클라이언트의 데이터 스키마를 기반으로 생성된 소프트웨어 모델 및 로직 세트는 상술한 백워드 플래닝 로직의 결과물을 입력으로 사용하여 포워드 플래닝 로직에 따라 생산 계획을 생성할 수 있다.If the library engine set includes forward planning logic, the software model and logic set generated based on the client's data schema can generate a production plan based on the forward planning logic. For example, the software model and logic set generated based on the client's data schema can use the output of the aforementioned backward planning logic as input to generate a production plan based on the forward planning logic.
이하에서는 라이브러리 엔진 세트 내의 포워드 폴래닝 로직의 실시 예를 용이하게 설명하기 위해, 생성된 소프트웨어 모델 및 로직 세트가 포워드 플래닝 방식에 따라 이산사건 시뮬레이션 방식의 생산계획 모델링을 수행하는 예를 개시한다.In order to easily explain an embodiment of forward planning logic within a library engine set, an example is disclosed below in which a generated software model and logic set perform production plan modeling in a discrete event simulation manner according to a forward planning method.
이러한 포워드 플래닝 로직이 구현되기 위하여 이산사건 시뮬레이션(discrete event simulation) 방식의 모델링이 수행될 수 있다. 이산사건 시뮬레이션 방식은 연속사건과 달리 시간의 정방향 흐름에 따른 이벤트 순서로 모델링하되, 각 이벤트는 특정 시점에 발생하여 시스템의 상태를 변화시키게 된다.To implement this forward planning logic, discrete event simulation (CES) can be used. Unlike continuous events, CES models events as a sequence of events that flow forward in time. However, each event occurs at a specific point in time and alters the system's state.
이산사건 시뮬레이션(discrete event simulation) 방식의 모델링은 이벤트(event)와 관련된 전역 시계(global clock), 상태 변수(state variable), 사건 대기열(event queue)을 통해 구현될 수 있다. 이벤트(event)는 제조 생산 시스템에서 상태의 전이를 발생시키는 단위에 해당한다. 또한, 본 실시예는 적어도 하나의 장비 또는 작업물을 포함하는 모델에서 생산계획을 산출하기 위해 포워드 플래닝이 수행되는 경우를 나타낸다. 예를 들어, 모델은 제조 시스템에서 플래닝을 위한 모형을 의미하며, 장비, 작업물, 또는 이들의 역학관계 등을 표현한 것에 해당할 수 있다.Discrete event simulation (CES) modeling can be implemented using a global clock, state variables, and event queues related to events. An event corresponds to a unit that causes a state transition in a manufacturing system. Furthermore, this embodiment illustrates a case where forward planning is performed to derive a production plan from a model that includes at least one piece of equipment or workpiece. For example, a model refers to a model for planning in a manufacturing system and may correspond to a representation of equipment, workpieces, or their dynamic relationships.
전역 시계(global clock)는 이벤트가 수행되는 동안 시뮬레이션의 시간을 나타낼 수 있다. 상태 변수(state variable)는 공장 내의 제조 생산 시스템에서 시뮬레이션의 상태(예. 공정, 장비, 작업물, 대기열 등)에 대한 변수를 나타낼 수 있다. 예를 들어, 각각의 상태변수(state variable)은 대응되는 적어도 하나의 이벤트를 포함할 수 있다. 사건 대기열(event queue)는 적어도 하나의 이벤트(event)가 정렬되어 있는 이벤트의 집합을 나타낼 수 있다. 예를 들어, 사건 대기열(event queue)은 시뮬레이션 시간 상 빠른 순서로 적어도 하나의 이벤트가 정렬되어 있어, 시간 순에 따라 FIFO(first-in-first-out)으로 이벤트가 수행될 수 있다.A global clock can represent the time of the simulation while an event is being performed. State variables can represent variables related to the state of the simulation (e.g., process, equipment, workpiece, queue, etc.) in a manufacturing production system within a factory. For example, each state variable can include at least one corresponding event. An event queue can represent a set of events in which at least one event is ordered. For example, an event queue can have at least one event ordered in the earliest order in simulation time, so that events can be executed in a first-in-first-out (FIFO) order.
먼저, 사건 대기열(event queue)이 초기화될 수 있다(S110). 또한, 사건 대기열(event queue)가 초기화되는 경우, 상태 변수(state variable) 및 전역 시계(global clock)도 초기화될 수 있다. 이때, 전역 시계(global clock)의 시간은 0에 해당할 수 있다. 즉, 포워딩 플래닝 로직에서는 사건 대기열(event queue), 상태 변수(state variable), 전역 시계(global clock)가 초기화된 상태에서 제조생산시스템의 시뮬레이션이 시작될 수 있다.First, an event queue can be initialized (S110). Furthermore, when the event queue is initialized, state variables and a global clock can also be initialized. At this time, the global clock time can correspond to 0. In other words, in the forwarding planning logic, simulation of the manufacturing system can begin with the event queue, state variables, and global clock initialized.
다음으로, 사건 대기열(event queue) 중 하나의 이벤트가 선택될 수 있다(S120). 일 예로서, 사건 대기열(event queue)에 있는 적어도 하나의 이벤트 중 시간 순서 상 가장 앞에 있는 이벤트가 선택될 수 있다. 다른 일 예로서, 시간 순서가 동일한 복수의 이벤트가 있는 경우, 어떤 이벤트가 먼저 수행되어야할 지에 대한 우선순위(priority)가 부여될 수 있으며, 우선순위에 따라 이벤트가 선택될 수 있다.Next, an event from the event queue may be selected (S120). For example, the event that is chronologically closest in the event queue may be selected. As another example, if there are multiple events with the same chronological order, a priority may be assigned to determine which event should be performed first, and the event may be selected based on the priority.
예를 들어, 작업물이 다음 경로를 탐색하는 이벤트와 장비가 다음 작업물을 탐색하는 이벤트가 동시에 발생할 수 있다. 이 경우, 작업물을 다음 경로를 탐색하는 이벤트가 먼저 수행되고, 장비가 다음 작업물을 탐색하는 이벤트를 이후에 수행하는 것으로 우선순위가 부여될 수 있다.For example, an event for a workpiece to explore its next path and an event for a device to explore its next task may occur simultaneously. In this case, the event for the workpiece to explore its next path may be prioritized so that it occurs first, followed by the event for the device to explore its next task.
하나의 이벤트가 선택되는 경우, 선택된 이벤트가 실행되고 전역 시계(global clock)가 업데이트될 수 있다(S130). 또한, 선택된 이벤트가 실행되는 경우, 이벤트에 대응되는 상태 변수(state variable)도 함께 업데이트될 수 있다.When an event is selected, the selected event is executed and the global clock may be updated (S130). Furthermore, when the selected event is executed, the state variable corresponding to the event may also be updated.
예를 들어, 작업물 투입(in) 이벤트가 발생되는 경우, 이에 대응되는 상태 변수인 작업물 정보(WIP)가 업데이트될 수 있다. 또한, 전역 시계(global clock)은 이전에 마지막으로 실행했던 이벤트와 현재 실행된 이벤트의 시간 간격만큼 업데이트될 수 있다.For example, when a work input (in) event occurs, the corresponding status variable, Work in Process (WIP), can be updated. Additionally, the global clock can be updated by the time difference between the last executed event and the currently executed event.
다음으로 이벤트가 실행된 후 종료 조건(terminal condition) 해당하는지 판단할 수 있다(S140). 예를 들어, 종료 조건(terminal condition)은 공장 내에서 작업물에 할당된 모든 작업이 완료된 경우에 해당할 수 있으며, 이에 한정되지 아니한다. 이 경우, 작업물에 대하여 이벤트가 종료될 수 있다.Next, after the event is executed, it can be determined whether a terminal condition is met (S140). For example, the terminal condition may be, but is not limited to, the completion of all tasks assigned to a workpiece within the factory. In this case, the event may be terminated for the workpiece.
한편, 이벤트가 실행된 작업물이 종료 조건(terminal condition)에 해당하지 않는 경우, 사건 대기열(event queue) 중 다음 이벤트가 선택될 수 있다(S150). 이 경우, S130 단계가 진행되어, 다음 이벤트가 실행되고 전역 시계(global clock)가 업데이트될 수 있다.Meanwhile, if the task for which the event is executed does not meet the terminal condition, the next event may be selected from the event queue (S150). In this case, step S130 may be performed, executing the next event and updating the global clock.
적어도 하나의 장비 또는 작업물을 포함하는 모델에 대한 이벤트가 종료되는 경우, 실행된 이벤트 및 이와 관련된 전역 시계 및 상태 변수의 정보를 포함하여 생산계획의 모델링이 구현될 수 있다(S160).When an event is terminated for a model including at least one piece of equipment or workpiece, modeling of a production plan can be implemented including information about the executed event and the global clock and state variables associated with it (S160).
따라서, 실시 예에 따라 소프트웨어 및 모델 로직이 포워드 플래닝 을 수행하면, 공장에 투입된 작업물에 대한 시간 순서에따라 생산 계획이 산출될 수 있다.Therefore, when the software and model logic perform forward planning according to an embodiment, a production plan can be produced according to the time sequence of work pieces input into the factory.
도 11은 실시 예에 따른 포워드 플래닝의 상태 변수의 일 예를 나타내는 도면이다.Fig. 11 is a diagram showing an example of state variables of forward planning according to an embodiment.
상술한 바와 같이, 포워드 플래닝은 공장 내에 작업물의 투입시점부터 시간 순서대로 이벤트를 실행하면서 생산 계획을 산출하게 된다. 이때, 상술한 이벤트의 실행에 따라, 이벤트에 대응되는 상태 변수(state variable)(3300)에 변화가 발생한다.As described above, forward planning generates a production plan by executing events in chronological order from the time work items are introduced into the factory. As the events described above are executed, changes occur in the state variables (3300) corresponding to the events.
상태 변수(state variable)(3300)은 생산제조시스템을 시뮬레이션하는데 사용되는 다양한 변수의 집합에 해당하며, 물리적 변수(physical variable)(3100)와 논리적 변수(logical variable)(3200)를 포함한다. 상태 변수(state variable)의 물리적 변수(3100)는 시뮬레이션의 구성 요소 중 제품, 공정, 장비, 도구와 같은 물리적인 요소를 나타내고 물리적 변수(3100)는 종류에 따라 복수 개로 포함될 수 있으며, 논리적 변수(3200)는 시뮬레이션 모델링에서의 역학적인 부분 또는 투입 의사결정과 관련된 요소를 나타내고 논리적 변수(3200)는 종류별로 적어도 한 개가 포함될 수 있다.The state variable (3300) corresponds to a set of various variables used to simulate a production manufacturing system, and includes a physical variable (3100) and a logical variable (3200). The physical variable (3100) of the state variable represents a physical element such as a product, process, equipment, or tool among the components of the simulation, and the physical variable (3100) may be included in multiple numbers depending on the type, and the logical variable (3200) represents an element related to the dynamic part or input decision-making in simulation modeling, and at least one logical variable (3200) may be included depending on the type.
예를 들어, 물리적 변수(Physical variable)(3100)는 공장(factory)(미도시), 작업물 대기열(buffer)(3110), 작업물 현황(WIPs)(3120), 장비(equipment)(3130), 도구(tool)(3140) 등을 포함하며 이에 한정되지 아니한다. 또한, 예를 들어, 논리적 변수(logical variable)(3200)는 작업물 배치(route)(3210), 필터링(filter)(3220), 물류이동(transfer)(3230), 투입 의사결정(dispatching agent)(3240), 작업물 관리(WIP manager)(3250), 작업물 투입/소멸(in/out agent)(3260) 등을 포함하며 이에 한정되지 아니한다.For example, physical variables (3100) include, but are not limited to, a factory (not shown), a buffer (3110), work in process (WIPs) (3120), equipment (3130), and tools (3140). In addition, for example, logical variables (3200) include, but are not limited to, a route (3210), a filter (3220), a transfer (3230), a dispatching agent (3240), a WIP manager (3250), and an in/out agent (3260).
작업물 대기열(buffer)(3110)는 대기 중에 있는 작업물을 나타내고, 작업물 정보(WIPs, work in progress)(3120)는 공장 내에 있는 작업물의 정보를 나타내고, 장비(equipment)(3130)는 작업물이 처리되는 대상을 나타내고, 공장(factory)은 작업물의 공정이 수행되는 위치를 나타내고, 도구(tool)(3140)은 장비에서 공정이 진행되기 위해 필요한 도구를 나타낼 수 있다.The workpiece queue (buffer) (3110) represents workpieces in progress, workpiece information (WIPs, work in progress) (3120) represents information on workpieces within the factory, equipment (3130) represents the target of the workpiece processing, factory represents the location where the workpiece process is performed, and tool (3140) may represent a tool required for the process to proceed in the equipment.
또한, 작업물 현황관리(WIP manager)(3250)는 공장 내의 모든 작업물의 위치 및 정보 관리를 나타내고, 작업물 투입/소멸(in/out agent)(3260)는 공장 내의 작업물 투입 및 반출에 대한 관리를 나타낼 수 있다.In addition, the work-in-process management (WIP manager) (3250) can indicate the location and information management of all work-in-process within the factory, and the work-in/out agent (3260) can indicate the management of work-in and out within the factory.
일 예로서, 포워드 플래닝 로직에서, 모델 내의 적어도 하나의 장비 또는 작업물에 대한 이벤트가 선택되고 실행되는 시뮬레이션이 진행됨에 따라 이벤트에 대응되는 상태 변수에 변화가 발생하게 된다. 예를 들어, 장비의 상태는 유휴(IDLE), 작업중(RUN), 도구교체(SETUP), 정비(PM), 고장(DOWN), 가용(UP) 등을 포함할 수 있고, 작업물의 상태는 대기(WAIT), 이동중(TRANSFER), 작업중(PROCESSING) 등을 포함할 수 있으며, 이에 한정되지 아니한다.For example, in forward planning logic, as an event for at least one piece of equipment or workpiece within the model is selected and the simulation progresses, a change occurs in the state variable corresponding to the event. For example, the state of the equipment may include idle (IDLE), working (RUN), tool change (SETUP), maintenance (PM), breakdown (DOWN), and availability (UP), and the state of the workpiece may include, but is not limited to, wait (WAIT), transport (TRANSFER), and processing (PROCESSING).
예를 들어, 공정 처리(process) 시작 이벤트가 실행되는 경우 이에 대응되는 상태변수인 장비(equipment) 또는 작업물(Job or Lot)에 변화가 발생하게 된다. 장비의 경우 유휴 상태(IDLE)에서 가동중(RUN)으로 변화하고 작업물 또한 대기 상태(WAIT)에서 작업중 상태(RUN or Processing) 상태로 변화한다. 또한, 예를 들어, 도구 교체(tool change) 이벤트가 실행되는 경우 이에 대응되는 상태변수인 도구(tool)와 장비(equipment)에 변화가 발생하게 된다. 도구의 경우 가용 수량 차감, 장비의 경우 사용 중인 도구가 변한다.For example, when a process start event is executed, the corresponding state variables, such as equipment or workpiece (Job or Lot), change. For equipment, the state changes from idle (IDLE) to running (RUN), and for workpieces, the state changes from waiting (WAIT) to running (RUN) or processing. In addition, for example, when a tool change event is executed, the corresponding state variables, such as tool and equipment, change. For tools, the available quantity is deducted, and for equipment, the tool in use changes.
이 경우, 변화된 상태 변수에 대응되는 또는 연계된 이벤트(event)가 사건 대기열(event queue)(3400)에 신규 진입될 수 있다. 또한, 연계된 이벤트는 사건 대기열(3400)에 진입되어, 지정된 순서 또는 시간에 실행될 수 있다. 예를 들어, 작업물 이동(transfer) 이벤트가 실행되는 경우, 작업물 이동(transfer)에 대응하는 상태 변수에 변화가 발생하게 된다. 작업물 이동이 시작 될 경우 대상 작업물의 상태가 이동중(TRANSFERING)으로 변경되고, 이동이 종료되었을 경우 대기상태(WAIT)로 변경되며, 대기열(BUFFER) 진입 이벤트를 발생 시킨다. 이 경우, 작업물 이동(transfer)에 대응하는 상태 변수의 변화에 따라, 작업물 이동(transfer) 외의 다른 이벤트를 사건 대기열에 진입시킬 수 있다.In this case, an event corresponding to or linked to the changed state variable may be newly entered into the event queue (3400). In addition, the linked event may be entered into the event queue (3400) and executed in a specified order or time. For example, when a workpiece transfer event is executed, a change occurs in the state variable corresponding to the workpiece transfer. When the workpiece transfer begins, the state of the target workpiece is changed to moving (TRANSFERING), and when the transfer is completed, it is changed to waiting (WAIT) and a queue (BUFFER) entry event is generated. In this case, depending on the change in the state variable corresponding to the workpiece transfer, an event other than the workpiece transfer may be entered into the event queue.
즉, 이벤트의 실행에 따라, 이벤트에 대응되는 상태 변수(state variable)(3300)에 변화가 발생하게 되며, 공장 내에서 사용되는 물리적 변수와 논리적 변수는 이 도면에 도시된 변수에 한정되지 아니하고, 작업물 또는 장비에 관련된 다른 변수를 포함할 수도 있다.That is, depending on the execution of an event, a change occurs in the state variable (3300) corresponding to the event, and the physical variables and logical variables used within the factory are not limited to the variables shown in this drawing, and may include other variables related to workpieces or equipment.
도 12는 실시 예에 따른 포워드 플래닝을 수행하는 사건 대기열의 이벤트의 일 예를 나타낸 도면이다.FIG. 12 is a diagram illustrating an example of an event in an event queue performing forward planning according to an embodiment.
포워드 플래닝은 공장에 작업물이 첫 공정에 투입되어 공정이 완료되는 순간까지의 로직을 시간 순서대로 실행시켜 생산 계획을 산출하는 것이다.Forward planning is a production plan that executes the logic in chronological order from the moment work is put into the first process in the factory until the process is completed.
도시된 각각의 이벤트는 공장에 투입된 작업물 기준으로 사건 대기열(event queue)에 기 설정된 기준에 따라 정렬되어 있는 이벤트를 나타낼 수 있다. 예를 들어, 기 설정된 기준은 시간 순서에 따르거나, 우선순위에 따를 수 있고, 이에 한정되지 아니한다. 본 실시예의 경우, 도시된 각각의 이벤트가 시간 순서대로 정렬되어 있는 경우로 가정한다.Each depicted event may represent an event sorted according to predefined criteria in an event queue based on work items delivered to the factory. For example, the predefined criteria may be based on chronological order or priority, but is not limited thereto. In this embodiment, it is assumed that each depicted event is sorted in chronological order.
또한, 이 도면에 도시된 각각의 이벤트는 작업물, 공정 또는 장비와 관련된 상태의 변이를 포함하는 시스템 역학(dynamics)를 나타낼 수 있다. 이하에서는 이를 통칭하여 이벤트로 명칭하도록 한다. 또한, 도시된 각각의 이벤트는 적어도 하나의 장비 또는 작업물을 포함하는 모델 내에서 발생하는 이벤트에 해당할 수 있다.Additionally, each event depicted in this diagram may represent system dynamics, including state transitions related to a workpiece, process, or equipment. These are collectively referred to as "events" hereinafter. Furthermore, each depicted event may correspond to an event occurring within a model that includes at least one piece of equipment or workpiece.
일 예로서, 사건 대기열에서는 작업물 생성(release)(3510) 이후 먼저 작업물 투입(in)(3520)이 이루어진 후 다음으로 작업물 배치(routing)(3530), 작업물 이동(transfer)(3540), 투입 의사결정(dispatching)(3560), 공정처리(processing)(3580), 작업물 배치(routing)(3530), 작업물 반출(out)(3590)의 순서로 설정될 수 있다.As an example, in the event queue, after work creation (release) (3510), work input (in) (3520) may be performed first, followed by work routing (3530), work transfer (3540), input decision (dispatching) (3560), process processing (3580), work routing (3530), and work output (out) (3590).
선택적으로, 작업물 이동(transfer)(3540) 이벤트가 실행된 후, 작업물 필터링(filtering)(3550) 이벤트가 실행되거나, 투입 의사결정(dispatching)(3560) 이벤트가 실행된 후, 장비 교체(tool change)(3570) 이벤트가 실행될 수 있다. 사건 대기열(event queue)에 정렬되어 있는 이벤트 및 이벤트 순서는 일 예로서, 이에 한정되지 아니한다.Optionally, after the workpiece transfer (3540) event is executed, the workpiece filtering (3550) event may be executed, or after the dispatching (3560) event is executed, the tool change (3570) event may be executed. The events and event sequences arranged in the event queue are examples and are not limited thereto.
상술한 바와 같이, 백워드 플래닝의 결과로 출력된 공장투입계획(release plan)정보(3640), 투입계획(Inplan)정보(3620), 공정목표(Step Target)정보(3630) 및 페깅히스토리(peghistory)정보(3610) 중 적어도 하나에 기초하여 작업물의 최초 투입시점부터 시간 순서대로 실제 생산계획의 시뮬레이션을 수행할 수 있다.As described above, based on at least one of the factory release plan information (3640), the input plan (Inplan) information (3620), the process target (Step Target) information (3630), and the pegging history information (peghistory) information (3610) output as a result of backward planning, a simulation of an actual production plan can be performed in chronological order from the time of the first input of the workpiece.
예를 들어, 작업물 생성(release)(3510) 이벤트는 백워드 플래닝 결과로 스케줄링된 공장투입계획(release plan)정보(3640)에 기초하여 실행될 수 있고, 작업물 투입(in)(3520) 이벤트는 백워드 플래닝 결과로 스케줄링된 투입계획(Inplan)정보(3610)에 기초하여 실행될 수 있고, 작업물 배치(route)(3530) 이벤트는 백워드 플래닝 결과로 스케줄링된 페깅히스토리(peg history)정보(3620)에 기초하여 실행될 수 있고, 투입 의사결정(dispatching(3560)) 이벤트는 백워드 플래닝 결과로 스케줄링된 공정 목표(Step Target)정보(3630)에 기초하여 실행될 수 있다. 또한, 예를 들어, 작업물 필터링(filtering)(3550) 이벤트는 공정 목표(Step Target)정보(3630)에 기초하여 실행될 수 있다. `For example, a workpiece creation (release) (3510) event can be executed based on factory input plan (release plan) information (3640) scheduled as a result of backward planning, a workpiece input (in) (3520) event can be executed based on input plan (Inplan) information (3610) scheduled as a result of backward planning, a workpiece placement (route) (3530) event can be executed based on peg history (peg history) information (3620) scheduled as a result of backward planning, and an input decision (dispatching (3560)) event can be executed based on process target (Step Target) information (3630) scheduled as a result of backward planning. In addition, for example, a workpiece filtering (filtering) (3550) event can be executed based on process target (Step Target) information (3630). `
한편, 상태 변수 중 도구(tool) 변수에 상태 변화가 발생할 수 있다. 이 경우, 도구(tool) 변수에 대응되는 이벤트인 장비 교체(tool change)(3570)가 사건 대기열(event queue)에 신규 진입할 수 있다. 따라서, 투입 의사결정(dispatching)(3560)과 공정처리(processing)(3580) 사이에 도구 변경(tool change)(3570)이 추가되어 이벤트가 실행될 수 있다.Meanwhile, a state change may occur in the tool variable among the state variables. In this case, an event corresponding to the tool variable, tool change (3570), may be newly entered into the event queue. Accordingly, a tool change (3570) may be added between dispatching (3560) and processing (3580), and the event may be executed.
또한, 이벤트가 순서대로 실행되는 중에 작업물 배치(routing)(3530)에서 작업물의 공정이 모두 끝난 종료 조건(terminal condition)에 해당되는 것으로 판단된 경우, 작업물 반출(out)(3590)이 이루어질 수 있다. 예를 들어, 종료 조건(terminal condition)은 전역 시계(global clock)에서 기 설정된 시간이 지난 경우, 이벤트 실행 시에 오류가 발생한 경우 등을 포함할 수 있으며, 이에 한정되지 아니한다.Additionally, if it is determined that the work process has completed all the tasks in the work routing (3530) while the events are being executed sequentially, the work may be taken out (3590). For example, the terminal condition may include, but is not limited to, when a preset time has passed on the global clock, when an error occurred during event execution, etc.
도 13은 실시 예에 따른 포워드 플래닝 로직을 이용하여 생산 계획을 생성하는 흐름도이다.Figure 13 is a flowchart for generating a production plan using forward planning logic according to an embodiment.
클라이언트 제조생산시스템의 데이터 스키마를 기반으로 포워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공할 수 있다.(S24).A software model and logic set including forward planning logic can be created or provided based on the data schema of the client manufacturing production system (S24).
또한, 상술한 백워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 기반하여, 포워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공할 수 있다.Additionally, based on the software model and logic set including the above-described backward planning logic, a software model and logic set including forward planning logic can be generated or provided.
즉, 소프트웨어모델 및 로직 세트는 위에서 개시한 포워드 플래닝 로직을 포함할 수 있으며, 백워드 플래닝 로직의 출력인 공장투입계획(release plan)정보, 투입계획(Inplan)정보, 공정 목표(Step Target)정보 및 페깅히스토리(peghistory) 정보 중 적어도 하나를 입력데이터로 사용할 수 있다.That is, the software model and logic set may include the forward planning logic disclosed above, and may use at least one of the factory release plan information, the input plan (Inplan) information, the process target (Step Target) information, and the peghistory information, which are outputs of the backward planning logic, as input data.
온프레미스 컴퓨팅 시스템에서 라이브러리 엔진 세트가 포워드 플래닝 로직을 포함하는 경우, 클라이언트의 데이터 스키마를 기반으로 소프트웨어모델 및 로직 세트를 생성할 수 있다.In on-premises computing systems, if a set of library engines includes forward planning logic, a software model and set of logic can be generated based on the client's data schema.
클라이언트로부터 기준 정보를 포함하는 입력데이터를 기반으로 생산 계획을 제공하는 클라우드 시스템인 경우, 본 단계에서 사용자의 커스텀화된 일부 로직 세트를 생성하거나, 또는 이 단계는 생략될 수 있다.If the system is a cloud system that provides production plans based on input data containing reference information from the client, this step may create some customized logic sets for the user, or this step may be omitted.
생성된 소프트웨어모델 및 로직세트는 포워드 플래닝 로직에 따라 시간 순서에 따른 생산 계획 데이터를 생성하도록 할 수 있다. 포워드 플래닝 로직에 대한 상세한 실시 예는 도 9 내지 도12에서 개시하였다.The generated software model and logic set can generate production planning data in chronological order according to forward planning logic. Detailed examples of the forward planning logic are disclosed in FIGS. 9 to 12.
상기 데이터 스키마에 따라 상기 클라이언트로부터 입력데이터를 수신한다(S30).Input data is received from the client according to the above data schema (S30).
온프레미스 시스템을 이용하여 생산 계획을 생성하고 제공할 경우 수신된 포워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 대해 여러 가지 조건들을 추가하여 소프트웨어모델 및 로직 세트에 대한 테스트를 수행할 수 있다.When creating and providing production plans using on-premise systems, you can perform tests on software models and logic sets that contain received forward planning logic by adding various conditions to the software models and logic sets.
수신된 입력데이터를 기반으로 포워드 플래닝 로직을 포함하는 소프트웨어 모델 및 로직 세트를 수행하여 생성한 생산 계획 정보를 제공할 수 있다(S57).It is possible to provide production plan information generated by executing a software model and logic set including forward planning logic based on received input data (S57).
포워드 플래닝 로직은, 작업물이 처음 공장에 투입되는 시점부터 완료되는 시점까지 장비 또는 작업물을 시간순서대로 실제 공장을 시뮬레이션 하여 생산 계획 및 생산 스케쥴을 산출하는 방식에 해당한다.Forward planning logic is a method of producing a production plan and schedule by simulating an actual factory in chronological order, from the time the work is first introduced to the factory until it is completed.
입력데이터는 상술한 백워드 플래닝 로직의 결과물을 포함한다. 여기서, 입력데이터는 공장투입계획(release plan)정보, 투입계획(Inplan)정보, 공정 목표(Step Target)정보 및 페깅히스토리(peghistory)정보 중 적어도 하나를 포함할 수 있다.The input data includes the results of the backward planning logic described above. Here, the input data may include at least one of the following: release plan information, inplan information, step target information, and peghistory information.
실시 예에 따르면, 클라이언트 제조생산시스템으로부터 수신되는 기준 정보에 기초하여 시간의 순방향 흐름에 따라 생산 계획을 설립할 수 있다. 시간 순행 방식에 따라 공장 내에서 작업물 또는 장비의 실제 생산계획을 시뮬레이션할 수 있다. 이러한 포워드 플래닝 방식을 이용하여 효율적인 생산 계획 정보를 생성하여 제공할 수 있다.According to an embodiment, a production plan can be established based on reference information received from a client manufacturing system, following a forward flow of time. The actual production plan for workpieces or equipment within the factory can be simulated using this forward planning method. Using this forward planning method, efficient production planning information can be generated and provided.
클라이언트는 시간 순행 방식으로 실레 공장상황을 시뮬레이션하여 생성된 생산 계획에 따라 보다 더 효율적인 생산 계획을 얻을 수 있다.Clients can simulate the actual factory situation in a time-forward manner and obtain more efficient production plans based on the generated production plan.
도 8을 참조하여 포워드 플래닝 로직을 포함하는 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 설명하면 다음과 같다.Referring to FIG. 8, an embodiment of a device providing digital production planning information including forward planning logic is described as follows.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(310), 저장장치(320), 인메모리(330), 프로세서(340), 출력부(350), 및 사용자인터페이스(360)를 포함할 수 있다.One embodiment of a device providing digital production planning information may include an input unit (310), a storage unit (320), an in-memory unit (330), a processor (340), an output unit (350), and a user interface (360).
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(360)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (360).
입력부(310)는 클라이언트 제조생산시스템으로부터 그 제조생산시스템의 데이터 스키마를 수신할 수 있다.The input unit (310) can receive the data schema of the manufacturing production system from the client manufacturing production system.
저장장치(320)는 입력부(310)가 수신한 데이터 스키마를 저장하거나 또는 정형화된 데이터 스키마가 미리 준비된 경우는 정형화된 데이터 스키마를 저장장치(320)에 저장에 저장할 수 있다. 저장장치(320)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다.The storage device (320) may store the data schema received by the input unit (310), or, if a standardized data schema is prepared in advance, store the standardized data schema in the storage device (320). The storage device (320) may include volatile memory or non-volatile memory.
인메모리(330)는 위에서 개시한 라이브러리 엔진세트를 저장할 수 있다.In-memory (330) can store the library engine set disclosed above.
라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다. 생산 계획 엔진은 위에서 개시하는 포워드 플래닝 로직에 대한 파일을 포함할 수 있다.A library engine set may include a production planning engine, which is a set of encapsulated function block files that generate production plans. The production planning engine may include files for the forward planning logic described above.
추가적으로 라이브러리 엔진세트는, 생산계획엔진과 함께 생산 계획을 구현하는 자료 구조가 포함된 파일인 코어라이브러리, 및 생산계획엔진의 일부 기능을 상속받아서 특정 생산 도메인에서 사용하는 로직을 구현하는 생산도메인특화엔진을 더 포함할 수 있다.Additionally, the library engine set may further include a core library, which is a file containing data structures that implement a production plan together with a production planning engine, and a production domain-specific engine that inherits some of the functions of the production planning engine and implements logic used in a specific production domain.
실시 예의 프로세서(340)는 저장장치(320)에 저장된 데이터 스키마를 입력받을 수 있다. 그리고, 프로세서(340)는 상기 데이터 스키마 및 인메모리(330)에 저장된 엔진 또는 라이브러리에 기초하여 소프트웨어모델 및 로직세트를 생성할 수 있다. 생성된 소프트웨어모델 및 로직세트는 백워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 기반하여, 포워드 플래닝 로직에 따라 시간 순행 방식으로 생산 계획 데이터를 생성하도록 할 수 있다. 포워드 플래닝 로직에 따라 시간 순행 방식으로 생산 계획 데이터를 생성하는 실시 예들은 도 9 내지 12에서 개시하였다.The processor (340) of the embodiment can receive a data schema stored in the storage device (320). In addition, the processor (340) can generate a software model and a logic set based on the data schema and an engine or library stored in the in-memory (330). The generated software model and logic set can generate production plan data in a time-forward manner according to forward planning logic based on the software model and logic set including backward planning logic. Embodiments of generating production plan data in a time-forward manner according to forward planning logic are disclosed in FIGS. 9 to 12.
프로세서(340)는 사용자인터페이스(360)의 사용자의 요청에 따라 상기 생성된 소프트웨어모델 및 로직세트를 테스트하거나 사전 실행하여 생산 계획 데이터를 얻을 수 있다. 그리고 프로세서(340)는 사용자의 요청에 따라 생산 계획 데이터를 생성하는 소프트웨어모델 및 로직을 분석하거나 테스트한 결과를 사용자인터페이스(360)를 통해 사용자에게 제공할 수 있다.The processor (340) can obtain production plan data by testing or pre-executing the generated software model and logic set at the user's request via the user interface (360). Furthermore, the processor (340) can analyze or test the software model and logic that generate the production plan data at the user's request, and provide the results to the user via the user interface (360).
프로세서(340)는 입력부(310)로부터 수신된 데이터 스키마에 따라 상기 제조생산시스템의 기준정보를 포함하는 입력데이터를 수신할 수 있다. 프로세서(340)는 포워드 플래닝 로직에 따라 시간 순행 방식이 포함된 소프트웨어모델 및 로직세트를 실행하여 생산 계획 데이터를 생성할 수 있다. 포워드 플래닝 로직에 따라 생산 계획 데이터를 생성하는 상세한 예시는 도 9 내지 도 12에 개시하였다.The processor (340) can receive input data including reference information of the manufacturing production system according to the data schema received from the input unit (310). The processor (340) can generate production plan data by executing a software model and logic set including a time-forward method according to forward planning logic. Detailed examples of generating production plan data according to forward planning logic are disclosed in FIGS. 9 to 12.
출력부(350)는 포워드 플래닝 로직을 포함한 소프트웨어모델 및 로직세트의 실행 결과에 따른 생산 계획 데이터를 클라이언트 제조생산시스템에 제공하여 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (350) can provide production plan data based on the execution results of a software model and logic set including forward planning logic to a client manufacturing production system so that the client system can manage production or processes.
이하의 실시 예에서는 설치된 라이브러리 엔진 세트를 기반으로 생성된 소프트웨어모델 및 로직 세트를 이용하여 생산 계획 데이터를 제공하는 일 예를 상세히 개시한다.The following examples detail an example of providing production planning data using a software model and logic set generated based on an installed set of library engines.
설명한 바와 같이 온프레미스 컴퓨팅 시스템(1000)의 모델개발부(1100)는 라이브러리 엔진 세트(1150)를 기반으로 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트를 개발할 수 있는 프레임을 제공한다.As described, the model development unit (1100) of the on-premise computing system (1000) provides a frame for developing a software model and logic set capable of generating a production plan based on a library engine set (1150).
다른 예로서, 클라우드 컴퓨팅 시스템(2000)은 라이브러리 엔진 세트(2210)를 기반으로 생산 계획을 생성할 수 있는 정형화된 다수의 소프트웨어 모델 및 로직 세트들을 제공할 수 있다.As another example, the cloud computing system (2000) may provide a number of standardized software models and logic sets that can generate production plans based on a set of library engines (2210).
개시하는 실시 예에서 생산 계획을 생성할 수 있는 소프트웨어 모델 및 로직 세트는 시간 순행 방식으로 실제 공장의 생산 시스템에서 이루어지는 이벤트를 가상으로 실행하여 생산 계획을 수립하는 절차들을 수행한다. 여기서 시간 순행 방식으로 생산 계획을 스케줄링하는 방식을 포워드 플래닝(forward planning)으로 호칭할 수 있다.In the disclosed embodiment, a software model and logic set capable of generating a production plan perform procedures to establish a production plan by virtually executing events occurring in an actual factory production system in a time-forward manner. The method of scheduling a production plan in a time-forward manner can be referred to as forward planning.
모델개발부(1100)는 라이브러리 엔진 세트(1150)를 기반으로 포워드 플래닝(forward planning) 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하도록 할 수 있다. 포워드 플래닝(forward planning) 방식은, 상술한 백워드 플래닝의 결과로 출력된 공장투입계획(release plan) 정보, 투입계획(Inplan)정보(수량 및 시점포함), 공정 목표(Step Target)정보및 페깅 히스토리(Peghistory)정보 중 적어도 하나에 기초하여 작업물의 최초 투입시점부터 시간 순서대로 공장 내에 발생할 수 있는 이벤트를 실행시켜 실제 생산계획의 시뮬레이션을 수행하는 방식이다.The model development unit (1100) can generate a software model and logic set including forward planning logic based on the library engine set (1150). The forward planning method is a method of performing a simulation of an actual production plan by executing events that may occur in the factory in chronological order from the time of the first input of a workpiece based on at least one of the factory release plan information, the input plan (Inplan) information (including quantity and time), the process target (Step Target) information, and the pegging history (Peghistory) information output as a result of the above-described backward planning.
예를 들어, 포워드 플래닝(forward planning) 방식은 이산 사건 시뮬레이션(discrete event simulation) 방식으로 실제 작업물이 공장 내에 투입되어 작업 종료까지 어떤 시점에 어떤 경로를 통해 어떤 작업을 처리할지를 시간 순서대로 산출하여 생산 계획의 시뮬레이션을 수행할 수 있다.For example, the forward planning method is a discrete event simulation method that can simulate production plans by calculating in chronological order what work will be done, through what path, at what point in time, from the time an actual work item is put into the factory until the work is completed.
즉, 포워드 플래닝(forward planning) 방식은 백워드 플래닝(backward planning) 방식을 통해 산출한 공정 목표를 기초로 하여 실제 공장에서 작업물(lot) 또는 장비(equipment)와 관련하여, 작업물 배치(route), 작업물 필터링(filter), 작업물 이동(transfer), 투입 의사결정(dispatching), 더미 공정처리(dummy processing), 작업물 투입(in), 작업물 소멸(out) 등의 이벤트 실행을 통해 세부적인 생산 계획을 산출 할 수 있다.That is, the forward planning method can produce a detailed production plan by executing events such as work lot placement (route), work filtering (filter), work transfer (transfer), input decision (dispatching), dummy processing, work in, and work out (out) in relation to work lots or equipment in an actual factory based on the process goals produced through the backward planning method.
도 14는 실시 예에 따른 포워드 플래닝 로직이 수행하는 사건 대기열의 이벤트의 다른 일 예를 나타낸 도면이다.FIG. 14 is a diagram illustrating another example of an event in an event queue performed by forward planning logic according to an embodiment.
포워드 플래닝은 공장에 작업물이 생성되어 공정에 투입된 후 공정이 완료되는 순간까지의 로직을 시간 순서대로 실행시켜 생산 계획을 산출하는 것이다.Forward planning is a production plan that is created by executing the logic in chronological order from the moment work items are created in the factory and put into the process until the process is completed.
상술한 바와 같이, 포워드 플래닝 로직을 통해, 실제 공장의 시뮬레이션 모델을 만들어 구동해 볼 수 있으며, 작업물 생성(release), 작업물 투입(in), 대기열 진입(queue), 작업물 이동(transfer), 작업물 배치(route), 공정 처리(processing), 장비 교체(tool change), 투입 의사결정(dispatching), 작업물 필터링(filtering), 작업물 소멸(out) 등의 이벤트를 통해 현실의 공장의 역학(dynamic)을 재현하는 생산계획을 만들 수 있다. 일 예로서, 투입 의사결정(dispatching) 이벤트는 필터링(filter) 이벤트를 포함할 수 있다.As described above, through forward planning logic, a simulation model of an actual factory can be created and operated, and a production plan that reproduces the dynamics of an actual factory can be created through events such as workpiece creation (release), workpiece input (in), queue entry (queue), workpiece transfer (transfer), workpiece placement (routing), process processing (processing), equipment change (tool change), dispatching decision-making (dispatching), workpiece filtering (filtering), and workpiece disappearance (out). For example, the dispatching decision-making event may include a filter event.
또한, 상술한 바와 같이, 백워드 플래닝의 결과로 출력된 공장투입계획(release plan) 정보, 투입계획(Inplan)정보(수량 및 시점포함), 공정 목표(Step Target)정보 및 페깅 히스토리(Peghistory)정보 중 적어도 하나를 포워드 플래닝의 입력값으로 사용하여, 포워드 플래닝 이벤트가 실행될 수 있다.In addition, as described above, a forward planning event can be executed by using at least one of the factory release plan information, the input plan (Inplan) information (including quantity and timing), the process target (Step Target) information, and the peghistory information output as a result of backward planning as an input value of forward planning.
일 예로서, 사건 대기열에서는 작업물 생성(release)(3701) 및 작업물 투입(in)(3702)이 이루어진 후 다음으로 작업물 배치(route)(3703), 작업물 이동(transfer)(3704), 작업물 대기(buffer)(3705), 투입의사결정(dispatching)(3706), 공정처리(processing)(3708)의 순서로 이벤트가 실행될 수 있다. 또한, 상술한 사건 대기열에 정렬된 이벤트 중 일부 이벤트는 제외되고 실행될 수 있다. 다른 일 예로서, 작업물 배치(route)(3703) 이벤트가 실행된 후 작업물 완료(out)(3709) 이벤트가 실행될 수 있다.For example, in the event queue, after work creation (release) (3701) and work input (in) (3702), events may be executed in the following order: work placement (route) (3703), work transfer (transfer) (3704), work waiting (buffer) (3705), dispatching (dispatching) (3706), and processing (processing) (3708). In addition, some events among the events arranged in the above-described event queue may be executed while being excluded. As another example, the work completion (out) (3709) event may be executed after the work placement (route) (3703) event is executed.
선택적으로, 투입의사결정(dispatching)(3706) 이벤트가 실행된 후, 장비교체(tool change)(3707) 이벤트가 실행될 수 있고, 작업물 이동(transfer)(3704) 이벤트가 실행된 후 더미 공정처리(dummy processing)(3710) 이벤트가 실행될 수 있다. 사건 대기열에 정렬되어 있는 이벤트 및 이벤트 순서는 일 예로서, 이에 한정되지 아니한다.Optionally, after the dispatching decision (3706) event is executed, the tool change (3707) event may be executed, and after the workpiece transfer (3704) event is executed, the dummy processing (3710) event may be executed. The events and event sequences arranged in the event queue are examples and are not limited thereto.
또한, 투입 의사결정(dispatching)(3706)은 투입의사결정 에이전트에 의해 관리되며, 투입의사결정 에이전트는 앞서 상술한 상태 변수 중 논리적 변수에 해당한다. 또한, 투입 의사결정은 생산 계획에서 성능을 좌우하는 가장 중요한 요소 중 하나에 해당한다.Additionally, dispatching (3706) is managed by an dispatching agent, which corresponds to a logical variable among the state variables described above. Furthermore, dispatching is one of the most important factors influencing performance in production planning.
투입 의사결정(dispatching)(3706)은 이벤트가 실행되는 대상의 종류에 따라 수행되는 시점이 상이할 수 있다. 일 예로서, 작업물이 작업물 대기(buffer)(3705) 상태에 있는 경우, 장비가 공정처리(processing)(3708) 이후 유휴 상태가 되는 경우, 또는 일정 시간주기마다 주기적으로 이루어질 수 있다. 투입의사결정(dispatching)(3706)과 관련하여, 이하에서 다시 설명하도록 한다.Dispatching (3706) may be performed at different times depending on the type of target for which the event is being executed. For example, it may be performed when a workpiece is in the workpiece buffer (3705) state, when equipment becomes idle after processing (3708), or periodically at regular intervals. Dispatching (3706) will be further described below.
한편, 포워드 플래닝 로직에 있어서, 물리적인 제조환경에서는 장비 또는 작업물과 관련하여, 이동 경로를 설정하고, 설정된 경로를 이동하여 장비에 선택되는 과정에서 높은 세밀도로 인해 많은 양의 연산이 요구될 수 있다. 특히 작업물 필터링(filtering)(미도시) 또는 투입 의사결정(dispatching)(3706) 과정에서 많은 양의 연산이 요구될 수 있다. 다만, 병목장비가 아니거나, 처리속도가 빠른 공정, 공장 내에 장비 수가 충분히 많은 경우에는 많은 양의 연산이 필요하지 않을 수 있어, 이러한 불필요한 세밀도를 줄이기 위한 공정처리가 필요하다.Meanwhile, in forward planning logic, in a physical manufacturing environment, the process of setting a movement path for equipment or workpieces and selecting them along the established path may require a significant amount of computation due to the high level of detail. In particular, workpiece filtering (not shown) or dispatching (3706) may require a significant amount of computation. However, in cases where equipment is not a bottleneck, the process has a fast processing speed, or the number of equipment within the factory is sufficient, this large amount of computation may not be necessary. Therefore, process processing is necessary to reduce this unnecessary detail.
더미 공정처리(dummy processing)(3710)은 포워드 플래닝 로직에 있어서 작업물 이동(transfer) 이후일정 시간이 지나면 다음 공정을 위한 작업물 배치(route)(3704)가 이루어지게 하는 이벤트에 해당한다. 즉, 더미 공정처리(dummy processing)(3710)는 작업물 필터링(filtering)(미도시) 또는 투입 의사결정(dispatching)(3706)과 같은 복잡한 연산을 생략하고 수행시간을 단축하기 위한 방식이다. 본 실시예에서는 작업물 이동(transfer) 이후에 더미 공정처리(dummy processing)(3710)가 진행되는 것으로 기재하였으나, 작업물 대기(buffer) 이벤트 이후에 더미 공정처리(3710)가 진행되는 것도 가능하다.Dummy processing (3710) corresponds to an event that causes workpiece routing (3704) for the next process to occur after a certain period of time has elapsed after workpiece transfer in the forward planning logic. In other words, dummy processing (3710) is a method for shortening the execution time by omitting complex operations such as workpiece filtering (not shown) or input decision-making (dispatching) (3706). In this embodiment, dummy processing (3710) is described as being performed after workpiece transfer, but it is also possible for dummy processing (3710) to be performed after a workpiece waiting (buffer) event.
더미 공정처리(dummy processing)(3710)의 경우, 작업물 생성(release)(3701) 시점 또는 작업물 투입(in)(3702) 시점, 즉 입력 값에서 더미 공정처리(dummy processing)(3710) 대상 공정(step)으로 설정되게 된다. 따라서, 더미 공정처리(dummy processing)(3710) 대상 공정(step) 또는 장비로 설정되는 경우, 작업물 필터링(filtering)(미도시) 또는 투입의사결정(dispatching)(3706)을 거치지 않고 작업물 배치(route)(3703)로 진행된다.In the case of dummy processing (3710), the target process (step) for dummy processing (3710) is set at the time of workpiece creation (release) (3701) or workpiece input (in) (3702), i.e., at the input value. Accordingly, when the target process (step) or equipment for dummy processing (3710) is set, the workpiece is routed (3703) without going through workpiece filtering (not shown) or input decision (dispatching) (3706).
또한, 더미 공정처리(dummy processing)(3710)은 입력 값에서 설정되더라도 공정 또는 장비의 생산 역량(production capacity)를 매개 변수로 받아, 이를 초과하여 실행되지 않도록 설정될 수 있다.Additionally, dummy processing (3710) can be set to not be executed in excess of the production capacity of the process or equipment by receiving the production capacity as a parameter even if it is set in the input value.
도 15는 실시 예에 따른 포워드 플래닝 로직이 수행하는 투입의사결정 수행 단계를 예시한 도면이다.Figure 15 is a diagram illustrating an investment decision-making execution step performed by forward planning logic according to an embodiment.
이하에서는 라이브러리 엔진 세트 내의 포워드 플래닝 로직의 실시 예를 용이하게 설명하기 위해, 시스템 역학(dynamics)의 일종인 투입의사결정 에이전트(dispatching agent)에 의해 투입 의사결정을 수행하는 예를 개시한다.In order to easily explain an embodiment of forward planning logic within a set of library engines, an example of dispatching decision making is presented below by a dispatching agent, which is a type of system dynamics.
상술한 바와 같이, 디스패칭(dispatching)은 포워드 플래닝 로직에서 생산 계획의 성능에 영향을 미치는 요소에 해당한다. 작업물 또는 장비인지에 따라 디스패칭 이벤트가 실행되는 시점은 상이할 수 있다.As mentioned above, dispatching is a factor influencing the performance of production plans in forward planning logic. Depending on whether the task is a workpiece or a piece of equipment, the timing of the dispatching event may vary.
투입 의사결정이 실행되는 시점에서, 먼저, 투입 의사결정 대상이 결정될 수 있다(S310). 상술한 바와 같이, 투입 의사결정 이벤트는 필터링 이벤트를 포함할 수 있다. 즉, 투입 의사결정에 대한 방식을 결정하기 이전에 투입 의사결정 대상을 결정하는 필터링을 수행할 수 있다.At the point when the input decision is executed, the input decision target can first be determined (S310). As described above, the input decision event can include a filtering event. That is, filtering can be performed to determine the input decision target before determining the method for the input decision.
예를 들어, 유휴 상태가 된 장비 1대가 작업물 후보들 n개 중 하나를 고르기 위한 투입 의사결정의 대상이 될 수 있고, 이전 공정을 마친 후 대기열에 추가된 작업물 1개가 장비 후보들 m개 중 하나를 고르기 위한 투입 의사결정의 대상이 될 수 있다. 또한, 예를 들어, 일정 시간 마다 공장 전체에서 발생 가능한 작업물과 장비 1쌍이 투입 의사결정의 대상이 될 수 있다.For example, a single idle piece of equipment could be the subject of an input decision to select one of n workpiece candidates, and a single workpiece added to the queue after completing a previous process could be the subject of an input decision to select one of m equipment candidates. Furthermore, for example, pairs of workpieces and equipment that can occur throughout the factory at regular intervals could be the subject of an input decision.
다음으로, 투입 의사결정의 방식이 결정될 수 있다(S320). 본 개시에서, 투입 의사결정 방식은 가중합(weight sum) 방식, 가중치 정렬(weight sort) 방식 및 가중합과 가중치 정렬의 혼합 방식을 포함할 수 있다. 투입 의사결정 방식은 공장 내의 작업물 또는 장비의 종류 또는 수량에 기초하여 결정되거나, 사용자의 설정에 의해 결정될 수 있다.Next, the input decision-making method can be determined (S320). In the present disclosure, the input decision-making method may include a weighted sum method, a weight sort method, or a combination of weighted sum and weight sort methods. The input decision-making method may be determined based on the type or quantity of workpieces or equipment within the factory, or may be determined by user settings.
여기에서, 가중합 방식은 투입 대상 후보들(복수의 작업물들 또는 복수의 장비들)에 대하여 모든 특성값(dispatching feature) 및 가중치의 곱을 다 계산해서 가중합이 가장 큰 후보(작업물 또는 장비)를 선택하는 방식에 해당한다. 또한, 가중치 정렬 방식은 투입 대상 후보들(복수의 작업물들 또는 복수의 장비들)에 대하여 우선도(priority)가 높은 특성값(dispatching feature)부터 평가하여 하나의 후보(작업물 또는 장비)를 선택하는 방식에 해당한다.Here, the weighted sum method calculates the product of all dispatching features and weights for input candidates (multiple workpieces or pieces of equipment) and selects the candidate (workpiece or piece of equipment) with the largest weighted sum. Furthermore, the weighted sorting method evaluates the highest priority dispatching feature among input candidates (multiple workpieces or pieces of equipment) and selects a single candidate (workpiece or piece of equipment).
만약, 투입 의사결정의 방식이 가중합 방식으로 결정되는 경우, 투입 대상 후보들에 대한 투입 의사결정의 특성(dispatching feature)의 종류 및 가중치(feature weight)을 식별할 수 있다(S330). 여기에서, 투입 의사결정의 특성은 투입 의사결정에서 발생될 수 있는 대안의 특징(혹은 특성)을수치화한 것에 해당할 수 있고, 특성 가중치(feature weight)는 각각의 특성의 가중치에 해당할 수 있다. 또한, 가중합 방식으로 투입 의사결정이 이루어지는 동안 특성의 종류와 가중치의 값이 변경될 수 있다. 다음으로, 후보들에 대한 가중합을 평가할 수 있다(S340). 보다 상세하게는 복수의 후보들 각각에 대하여 특성 및 가중치를 곱하여 가중합을 계산할 수 있다.If the input decision-making method is determined by a weighted sum method, the types and weights of dispatching features for input target candidates can be identified (S330). Here, the dispatching feature can correspond to a numerical representation of the features (or characteristics) of alternatives that may arise from the input decision-making, and the feature weights can correspond to the weights of each feature. Furthermore, the types and weights of features can change while the input decision-making is performed by a weighted sum method. Next, the weighted sum for the candidates can be evaluated (S340). More specifically, the weighted sum can be calculated by multiplying the features and weights for each of the multiple candidates.
여기에서, 가중합 평가는 선형 가중합 또는 신경망과 같은 비선형구조를 활용한 비선형 가중합을 포함할 수 있다. 비선형구조를 활용한 비선형 가중합 방식은 비선형 활성화 함수(Activation Function)을 사용하는 적어도 하나 이상의 신경망 층으로 구성된 신경망을 통해 작업물 별 점수를 산출할 수 있고, 해당 점수에 기반해 의사결정하는 방식이다. 예를 들어, 최대 점수를 지니는 작업물을 선택하거나 점수를 기반으로 SoftMax 함수를 이용하여 선택할 수 있다.Here, the weighted sum evaluation can include linear weighted sum or nonlinear weighted sum utilizing a nonlinear structure such as a neural network. A nonlinear weighted sum method utilizing a nonlinear structure can calculate scores for each task through a neural network composed of at least one neural network layer using a nonlinear activation function, and makes decisions based on these scores. For example, the task with the highest score can be selected, or the SoftMax function can be used to select tasks based on scores.
마지막으로, 가중합에 기초하여, 복수의 후보들 중에서 최종 후보를 선택할 수 있다(S350). 일 예로서, 복수의 후보들에 대하여 각각의 가중합을 계산하여, 가장 높은 가중합을 갖는 최종 후보가 선택될 수 있다. 다른 일 예로서, 복수의 후보들에 대하여 각각의 가중합을 계산하여, 가장 낮은 가중합을 갖는 최종 후보가 선택될 수 있다. 가중합 방식의 투입 의사결정과 관련하여, 이하에서 다시 설명하도록 한다.Finally, based on the weighted sum, a final candidate can be selected from among multiple candidates (S350). For example, the weighted sums of each candidate can be calculated, and the final candidate with the highest weighted sum can be selected. In another example, the weighted sums of each candidate can be calculated, and the final candidate with the lowest weighted sum can be selected. The weighted sum-based input decision-making process will be further explained below.
한편, 투입 의사결정의 방식이 가중치 정렬로 결정되는 경우, 투입 의사결정의 특성값의 종류 및 우선도(priority)를 식별할 수 있다(S360). 여기에서, 우선도는 공장의 특성, 장비 또는 작업물의 특성에 따라 특성값을 비교하는 순서에 해당할 수 있다. 다음으로, 복수의 특성값 종류 중 우선도가 가장 높은 특성값을 결정할 수 있다(S465). 본 실시예에서는 우선도가 가장 높은 특성값을 결정하는 것을 예시하였으나, 우선도가 가장 낮은 특성값으로 결정하는 것으로 설정될 수 있다.Meanwhile, if the input decision-making method is determined by weight sorting, the types and priorities of the characteristic values for the input decision-making can be identified (S360). Here, the priority may correspond to the order in which characteristic values are compared based on the characteristics of the factory, equipment, or workpiece. Next, the characteristic value with the highest priority among the multiple characteristic value types can be determined (S465). In this embodiment, the characteristic value with the highest priority is exemplified, but it can also be set to be determined as the characteristic value with the lowest priority.
다음으로, 후보들에 대하여 해당 우선도를 갖는 특성값의 점수를 평가할 수 있다(S370). 예를 들어, 복수의 후보들에 대하여 첫번째 우선도를 갖는 특성값의 점수를 비교할 수 있다. 이후, 복수이 후보들 중 특성값에 대한 동일한 점수를 갖는 후보들이 있는지 여부를 판단할 수 있다(S375). 예를 들어, 5개의 후보가 있는 경우, 적어도 2개 이상의 후보가 동일한 높은 점수를 갖는지 판단할 수 있다. 여기에서, 높은 점수는 복수의 후보들이 갖는 각각의 점수들 중 가장 높은 점수에 해당할 수 있다.Next, the scores of the feature values with the corresponding priority can be evaluated for the candidates (S370). For example, the scores of the feature values with the first priority can be compared for multiple candidates. Thereafter, it can be determined whether any of the multiple candidates have the same score for the feature value (S375). For example, if there are five candidates, it can be determined whether at least two candidates have the same high score. Here, the high score can correspond to the highest score among the scores of the multiple candidates.
특성값에 대한 동일한 높은 점수를 갖는 후보들이 없는 경우, 해당 특성값에서 높은 점수를 갖는 후보를 최종 후보로 선택할 수 있다(S380). 본 실시예에서는 높은 점수를 갖는 후보가 최종 후보로 선택되는 것을 예시하였으나, 낮은 점수를 갖는 후보가 최종 부호로 선택되는 것으로 설정될 수 있다.If there are no candidates with the same high score for a characteristic value, the candidate with the highest score for that characteristic value can be selected as the final candidate (S380). While this embodiment exemplifies the selection of a candidate with a high score as the final candidate, it is also possible to configure a candidate with a low score to be selected as the final candidate.
특성값에 대한 동일한 높은 점수를 갖는 후보들이 있는 경우, 다음 우선도를 갖는 특성값을 결정할 수 있다(S385). 보다 상세하게는, 동일한 높은 점수를 갖는 후보들이 아닌 나머지 후보는 제외하고, 동일한 높은 점수를 갖는 후보들에 대해서만 다음 우선도를 갖는 특성값을 결정할 수 있다. 예를 들어, 5개의 후보들 중에서 첫번째 우선도를 갖는 특성값에서 동일한 높은 점수를 갖는 후보가 2개 있는 경우, 2개의 후보에 대해서만 두번째 우선도를 갖는 특성값을 결정할 수 있다.If there are candidates with identical high scores for a feature value, the feature value with the next priority can be determined (S385). More specifically, the feature value with the next priority can be determined only for candidates with identical high scores, excluding candidates that do not have identical high scores. For example, if there are two candidates with identical high scores for the feature value with the first priority among five candidates, the feature value with the second priority can be determined only for those two candidates.
다음으로, 후보들에 대하여 해당 우선도를 갖는 특성값의 점수를 평가하고, 동일 높은 점수를 갖는 후보들이 없는 경우 S380 단계로 진행된다. 또한, 동일 높은 점수를 갖는 후보들이 있는 경우 다시 S385 단계를 반복하게 된다.Next, the scores of the feature values with the corresponding priority are evaluated for the candidates. If no candidates have the same high score, the process proceeds to step S380. If there are candidates with the same high score, step S385 is repeated.
즉, 가중치 정렬 방식은 복수의 후보들에 대하여 동일 특성값에 기초하여 정렬하였을 때, 동일한 점수 없이 1개의 후보가 남을때까지 반복하는 의사결정 방식에 해당한다. 이러한 가중치 정렬 방식은 의사결정 나무와 같은 비선형 구조의 의사결정 방식을 포함할 수 있다. 예를 들어, 비선형 구조는 의사결정 나무를 포함하며, 이에 한정되지 않는다.In other words, the weighted sorting method is a decision-making method that iterates through sorting multiple candidates based on the same feature value until only one candidate remains without identical scores. This weighted sorting method may include a nonlinear decision-making structure, such as a decision tree. For example, nonlinear structures include, but are not limited to, decision trees.
한편, 본 실시예에서는 도시되지 않았으나, 투입 의사결정에 있어서, 가중합 방식 및 가중치 정렬 방식을 복합적으로 수행할 수도 있다. 예를 들어, 투입 의사결정의 대상이 되는 10개의 작업물들 중 가중합이 가장 높은 5개를 선택하고, 선택된 5개에 대하여 다시 가중치 정렬 방식으로 하나의 후보를 최종 선택할 수 있다. 또한, 예를 들어, 투입 의사결정의 대상이 되는 10개의 작업물들 중 가중치 정렬 먼저하여 마지막 우선도까지 점수가 같은 5개가 남은 경우, 5개에 대해서 가중합 방식으로 하나의 후보를 최종 선택할 수 있다. 이때, 연산 낭비를 방지하기 위하여, 가중치 정렬에서 썼던 특성과 가중합 방식에서 썼던 특성은 다른 특성에 해당할 수 있다.Meanwhile, although not illustrated in this embodiment, the weighted sum method and the weighted sorting method can be combined to perform the input decision-making. For example, among the 10 tasks subject to the input decision-making, the 5 with the highest weighted sums can be selected, and then one candidate can be finally selected using the weighted sorting method among the 5 selected tasks. In addition, for example, among the 10 tasks subject to the input decision-making, if the weight sorting method is performed first and 5 tasks with the same score until the last priority are left, one candidate can be finally selected using the weighted sum method among the 5. In this case, to prevent computational waste, the features used in the weighted sorting method and the features used in the weighted sum method can correspond to different features.
도 16은 실시 예에 따른 포워드 플래닝 로직이 수행하는 디스패칭의 일 예를 나타낸 도면이다.FIG. 16 is a diagram illustrating an example of dispatching performed by forward planning logic according to an embodiment.
보다 상세하게는, 이 도면의 예는 장비 1대에 대하여 작업물이 3개인 경우를 가정하여, 가중합(weight sum) 방식의 투입 의사결정의 일 예를 나타내는 도면이다.More specifically, this drawing is an example of a weighted sum method of input decision making, assuming that there are three workpieces for one piece of equipment.
먼저, 본 실시예에서, 투입 의사결정의 대상은 작업물(3720)로서, 복수의 후보들(Lot1, Lot2, Lo3)을 포함할 수 있다. 다음으로, 투입 의사결정의 특성 및 가중치를 결정할 수 있다. 본 실시예에서, 투입 의사결정의 특성의 종류(3725) FIFO, SETUP, DELAY, PROCESS TIME으로 결정되고, 각각의 작업물들은 작업물의 특성에 따라 서로 다른 특성값(3730)을 가질 수 있다.First, in this embodiment, the target of the input decision is a workpiece (3720), which may include multiple candidates (Lot1, Lot2, Lo3). Next, the characteristics and weights of the input decision can be determined. In this embodiment, the types of characteristics of the input decision (3725) are determined as FIFO, SETUP, DELAY, and PROCESS TIME, and each workpiece can have different characteristic values (3730) depending on its characteristics.
FIFO(First In First Out) 특성은 다른 작업보다 빨리 진입한 작업을 먼저 처리할 수 있는 특성을 나타내고, SETUP 특성은 작업이 셋업 변화를 야기하는 특성을 나타내고, DELAY는 작업이 지연되는 특성을 나타내고, PROCESS TIME은 작업이 진행되는 시간과 관련된 특성을 나타낼 수 있다. 본 실시예에서는 4가지 특성에 대하여 기재되었으나, 특성의 종류는 이에 한정되지 아니한다. 이밖에도, 투입 의사결정의 특성은 공장 내에서 수치화할 수 있는 다양한 종류의 특성을 포함할 수 있다.The FIFO (First In First Out) characteristic indicates that tasks that enter earlier than other tasks can be processed first. The SETUP characteristic indicates that tasks cause setup changes. DELAY indicates that tasks are delayed. PROCESS TIME can indicate a characteristic related to the time it takes for a task to proceed. In this example, four characteristics are described, but the types of characteristics are not limited to these. In addition, the characteristics of input decision-making can include various types of characteristics that can be quantified within the factory.
예를 들어, 후보1(Lot1)의 경우, FIFO 특성값은 0.5, SETUP 특성값은 1.0, DELAY 특성값은 0.1, PROCESS TIME 특성값은 0.2에 해당하고, 후보 2(Lot2)의 경우, FIFO 특성값은 0.4, SETUP 특성값은 0.5, DELAY 특성값은 0.3, PROCESS TIME 특성값은 0.2에 해당하고, 후보 3(Lot3)의 경우, FIFO 특성값은 0.3, SETUP 특성값은 1.0, DELAY 특성값은 1.0, PROCESS TIME 특성값은 0.4에 해당한다.For example, for candidate 1 (Lot1), the FIFO characteristic value is 0.5, the SETUP characteristic value is 1.0, the DELAY characteristic value is 0.1, and the PROCESS TIME characteristic value is 0.2; for candidate 2 (Lot2), the FIFO characteristic value is 0.4, the SETUP characteristic value is 0.5, the DELAY characteristic value is 0.3, and the PROCESS TIME characteristic value is 0.2; and for candidate 3 (Lot3), the FIFO characteristic value is 0.3, the SETUP characteristic value is 1.0, the DELAY characteristic value is 1.0, and the PROCESS TIME characteristic value is 0.4.
일 예로서, 투입 의사결정을 위한 가중치(3735)는 투입 의사결정의 기준이 되는 장비에 따라 결정될 수 있다. 본 실시예에서, 장비를 기준으로 FIFO 특성값의 가중치는 50, SETUP 특성값의 가중치는 200, DELAY 특성값의 가중치는 300, PROCESS TIME 특성값의 가중치는 100에 해당한다.As an example, the weight (3735) for the input decision-making may be determined based on the equipment that serves as the basis for the input decision-making. In this embodiment, based on the equipment, the weight of the FIFO characteristic value is 50, the weight of the SETUP characteristic value is 200, the weight of the DELAY characteristic value is 300, and the weight of the PROCESS TIME characteristic value is 100.
다음으로, 각 후보들에 대하여 특성값 및 가중치를 곱한 합인 가중합을 계산할 수 있다. 본 실시예에서, 후보1(Lot1)의 가중합은 275, 후보2(Lot2)의 가중합은 230, 후보3(Lot3)의 가중합은 555에 해당한다. 따라서, 본 실시예의 투입 의사결정의 대상은 가중합이 가장 높은 후보인 후보3(Lot3)에 해당한다.Next, the weighted sum, which is the sum of the product of the feature values and weights for each candidate, can be calculated. In this example, 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 target of the input decision in this example corresponds to candidate 3 (Lot 3), the candidate with the highest weighted sum.
본 실시예의 경우, 장비 1대에 대하여 작업물이 복수인 경우를 가정하여 설명하였으나, 이와 반대로 작업물 1개에 대하여 장비가 복수인 경우에도 동일한 방식으로 가중합 방식을 수행하여, 투입 의사결정이 이루어질 수 있다. 가중합 방식은 의사결정이 모든 특성값을 고려하기 때문에 높은 성능의 생산 계획을 산출할 수 있는 장점이 있다.This example assumes multiple workpieces per piece of equipment. However, even in cases where multiple pieces of equipment are used per piece of equipment, the same weighted sum method can be used to make input decisions. The weighted sum method has the advantage of producing high-performance production plans because decision-making considers all characteristic values.
도 17은 실시 예에 따른 포워드 플래닝 로직이 수행하는 디스패칭의 다른 일 예를 나타낸 도면이다.FIG. 17 is a diagram illustrating another example of dispatching performed by forward planning logic according to an embodiment.
보다 상세하게는, 이 도면의 예는 장비 1대에 대하여 작업물이 3개인 경우를 가정하여, 가중치 정렬(Weight Sort) 방식의 투입 의사결정의 일 예를 나타내는 도면이다.More specifically, this drawing is an example of an input decision-making process using a weight sort method, assuming that there are three workpieces for one piece of equipment.
먼저, 본 실시예에서, 투입 의사결정의 대상은 작업물(3740)로서, 복수의 후보들(Lot1, Lot2, Lot3)을 포함할 수 있다. 다음으로, 의사결정 특성값 및 우선도(priority)를 결정할 수 있다. 본 실시예에서, 투입 의사결정의 특성값의 종류(3725) FIFO, SETUP, DELAY, PROCESS TIME으로 결정되고, 특성값의 우선도(3750)은 특성값 종류별로 가장 중요한 요소별로 순위가 결정되게 된다. 본 실시예에서, SETUP 특성값은 우선도가 첫번째이고, DELAY 특성값은 우선도가 두번째이고, PROCESS TIME 특성값은 우선도가 세번째이고, FIFO 특성값은 우선도가 네번째에 해당한다.First, in this embodiment, the target of input decision-making is a workpiece (3740), which may include multiple candidates (Lot 1, Lot 2, Lot 3). Next, decision-making characteristic values and priorities may be determined. In this embodiment, the types (3725) of characteristic values for input decision-making are determined as FIFO, SETUP, DELAY, and PROCESS TIME, and the priorities (3750) of the characteristic values are determined in order of importance for each characteristic value type. In this embodiment, the SETUP characteristic value has the first priority, the DELAY characteristic value has the second priority, the PROCESS TIME characteristic value has the third priority, and the FIFO characteristic value has the fourth priority.
다음으로, 우선도가 가장 높은 순서부터 후보들 간의 점수를 평가할 수 있다. 본 실시예에서, 우선도가가장 높은 SETUP 특성값에 대하여 첫번째 평가(3755)가 이루어질 경우, 후보 3(Lot3)을 제외하고, 후보 1(Lot1) 및 후보 2(Lot2)의 점수가 동일한 경우로 평가된다. 이 경우, 우선도 2번째인 DELAY 특성값에 대하여 두번째 평가(3760)이 이루어지고, 후보 1(Lot1)의 점수가 후보 2(Lot2)의 점수에 비해 낮은 것으로 평가된다. 따라서, 본 실시예의 투입 의사결정의 대상은 가중치 정렬에서 마지막으로 남은 후보인 후보 2(Lot2)에 해당한다.Next, the scores of the candidates can be evaluated in order of highest priority. In this embodiment, when the first evaluation (3755) is performed on the SETUP feature value with the highest priority, the scores of candidate 1 (Lot1) and candidate 2 (Lot2) are evaluated as being the same, except for candidate 3 (Lot3). In this case, the second evaluation (3760) is performed on the DELAY feature value with the second priority, and the score of candidate 1 (Lot1) is evaluated as being lower than the score of candidate 2 (Lot2). Therefore, the target of the input decision in this embodiment corresponds to candidate 2 (Lot2), which is the last candidate remaining in the weighted sorting.
본 실시예에 도시되지 않았으나, 만약, 두번째 평가(3760)에서도 후보 1(Lot1) 및 후보 2(Lot2)의 점수가 동일할 경우, 우선도 3번째인 PROCESS TIME 특성값에 대하여 추가 평가가 이루어질 수도 있다. 또한, 본 실시예에 도시되지 않았으나, 첫번째 평가(3755)에서 모든 후보가 SETUP 특성값이 모두 상이한 경우, 후보들 중 가장 높은 점수를 갖는 후보가 첫번째 평가에서 투입 의사결정의 대상으로 최종 선택될 수 있다.Although not shown in this embodiment, if the scores of candidate 1 (Lot 1) and candidate 2 (Lot 2) are the same in the second evaluation (3760), an additional evaluation may be performed on the PROCESS TIME characteristic value, which is the third priority. Also, although not shown in this embodiment, if all candidates have different SETUP characteristic values in the first evaluation (3755), the candidate with the highest score among the candidates may be finally selected as the target of the input decision in the first evaluation.
본 실시예의 경우, 장비 1대에 대하여 작업물이 복수인 경우를 가정하여 설명하였으나, 이와 반대로 작업물 1개에 대하여 장비가 복수인 경우에도 동일한 방식으로 가중치 정렬 방식을 수행하여, 투입 의사결정이 이루어질 수 있다. 가중치 정렬 방식은 의사결정이 진행됨에 따라 경우의 수가 줄어들고, 모든 특성값을 계산하지 않아도 되므로, 연산량이 적은 장점이 있다. 또한, 연산량이 적어짐에 따라 빠른 의사결정을 내릴 수 있어, 복잡한 공장에서 시뮬레이션하는 것이 어려운 경우(너무 복잡해서 너무 많은 시간이 걸리는 경우), 빠르게 의사결정을 할 수 있어, 효율적으로 생산계획을 산출할 수 있다.In this example, the case where multiple workpieces are allocated to a single piece of equipment is explained. However, conversely, even in cases where multiple pieces of equipment are allocated to a single piece of equipment, the same weighted sorting method can be used to make input decisions. The weighted sorting method has the advantage of reducing the number of cases as the decision-making process progresses, and reducing the computational complexity because not all characteristic values need to be calculated. Furthermore, the reduced computational complexity allows for faster decision-making. Therefore, in cases where simulation is difficult (e.g., due to excessive complexity and time-consuming) in complex factories, rapid decision-making is possible, enabling efficient production planning.
도 18은 실시 예에 따른 포워드 플래닝 로직을 이용하여 생산 계획을 생성하는 흐름도이다.Figure 18 is a flowchart for generating a production plan using forward planning logic according to an embodiment.
클라이언트 제조생산시스템의 데이터 스키마를 기반으로 배포 의사결정 또는 더미 공정처리를 포함하는 포워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공할 수 있다.(S25).A software model and logic set including forward planning logic including distribution decision making or dummy process processing based on the data schema of the client manufacturing production system can be created or provided (S25).
또한, 상술한 백워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 기반하여, 포워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공할 수 있다.Additionally, based on the software model and logic set including the above-described backward planning logic, a software model and logic set including forward planning logic can be generated or provided.
즉, 소프트웨어모델 및 로직 세트는 위에서 개시한 포워드 플래닝 로직을 포함할 수 있으며, 백워드 플래닝 로직의 출력인 공장투입계획(release plan)정보, 투입계획(Inplan)정보, 공정 목표(Step Target)정보 및 페깅히스토리(peghistory) 정보 중 적어도 하나를 입력데이터로 사용할 수 있다.That is, the software model and logic set may include the forward planning logic disclosed above, and may use at least one of the factory release plan information, the input plan (Inplan) information, the process target (Step Target) information, and the peghistory information, which are outputs of the backward planning logic, as input data.
상술한 바와 같이, 포워드 플래닝 로직은 투입 의사결정 또는 더미 공정처리 이벤트를 포함할 수 있다. 투입 의사결정은 방식에 따라 가중합 방식 및 가중치 정렬 방식을 포함할 수 있다.As described above, forward planning logic may include input decision-making or dummy process processing events. Depending on the method, input decision-making may include a weighted sum method or a weighted sort method.
한편, 배포 의사결정은 백워드 플래닝 로직에서도 적용될 수 있다. 일 예로서, 백워드 플래닝 로직의 수요정보전처리단계 및/또는 시설분배단계에서 적용될 수 있다. 투입 의사결정에 대한 방식은 상술한 가중합(weight sum) 방식, 가중치 정렬(weight sort) 방식 및 가중합과 가중치 정렬의 혼합 방식을 포함할 수 있다. 예를 들어, 수요정보전처리단계에서, 투입 의사결정 대상은 수요정보(demand)가 실적 n 개 중 하나를 고르기 위한 투입 의사결정의 대상이 될 수 있고, 실적이 수요정보(demand) n 개 중 하나를 고르기 위한 투입 의사결정의 대상이 될 수 있고, 수요정보와 실적 1 쌍이 투입 의사결정의 대상이 될 수 있다. 또한, 예를 들어, 시설분배단계에서, 투입 의사결정 대상은 시설(site)가 수요정보(demand) n 개 중 하나를 고르기 위한 투입 의사결정의 대상이 될 수 있고, 수요정보가 시설 n 개 중 하나를 고르기 위한 투입 의사결정의 대상이 될 수 있고, 시설과 수요정보 1 쌍이 투입 의사결정의 대상이 될 수 있다.Meanwhile, distribution decision-making can also be applied in backward planning logic. For example, it can be applied in the demand information preprocessing stage and/or the facility distribution stage of backward planning logic. The input decision-making method can include the weight sum method, the weight sort method, and a combination of the weight sum and weight sort methods described above. For example, in the demand information preprocessing stage, the input decision target may be demand information (demand) to select one out of n performances, performance may be the input decision target for selecting one out of n demand information, and a pair of demand information and performance may be the input decision target. Furthermore, for example, in the facility distribution stage, the input decision target may be a facility (site) to select one out of n demand information, demand information may be the input decision target for selecting one out of n facilities, and a pair of facility and demand information may be the input decision target.
온프레미스 컴퓨팅 시스템에서 라이브러리 엔진 세트가 포워드 플래닝 로직을 포함하는 경우, 클라이언트의 데이터 스키마를 기반으로 소프트웨어모델 및 로직 세트를 생성할 수 있다.In on-premises computing systems, if a set of library engines includes forward planning logic, a software model and set of logic can be generated based on the client's data schema.
클라이언트로부터 기준 정보를 포함하는 입력데이터를 기반으로 생산 계획을 제공하는 클라우드 시스템인 경우, 본 단계에서 사용자의 커스텀화된 일부 로직 세트를 생성하거나, 또는 이 단계는 생략될 수 있다.If the system is a cloud system that provides production plans based on input data containing reference information from the client, this step may create some customized logic sets for the user, or this step may be omitted.
생성된 소프트웨어모델 및 로직세트는 포워드 플래닝 로직에 따라 시간 순서에 따른 생산 계획 데이터를 생성하도록 할 수 있다. 포워드 플래닝 로직에 대한 상세한 실시 예는 도 13 내지 도 17에서 개시하였다.The generated software model and logic set can generate production planning data in chronological order according to forward planning logic. Detailed examples of the forward planning logic are disclosed in FIGS. 13 to 17.
상기 데이터 스키마에 따라 상기 클라이언트로부터 입력데이터를 수신한다(S30).Input data is received from the client according to the above data schema (S30).
온프레미스 시스템을 이용하여 생산 계획을 생성하고 제공할 경우 수신된 포워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 대해 여러 가지 조건들을 추가하여 소프트웨어모델 및 로직 세트에 대한 테스트를 수행할 수 있다.When creating and providing production plans using on-premise systems, you can perform tests on software models and logic sets that contain received forward planning logic by adding various conditions to the software models and logic sets.
수신된 입력데이터를 기반으로 포워드 플래닝 로직을 포함하는 소프트웨어 모델 및 로직 세트를 수행하여 생성한 생산 계획 정보를 제공할 수 있다(S57).It is possible to provide production plan information generated by executing a software model and logic set including forward planning logic based on received input data (S57).
포워드 플래닝 로직은, 작업물이 처음 공장에 투입되는 시점부터 완료되는 시점까지 장비 또는 작업물을 시간순서대로 실제 공장을 시뮬레이션 하여 생산 계획 및 생산 스케쥴을 산출하는 방식에 해당한다.Forward planning logic is a method of producing a production plan and schedule by simulating an actual factory in chronological order, from the time the work is first introduced to the factory until it is completed.
입력데이터는 상술한 백워드 플래닝 로직의 결과물을 포함한다. 여기서, 입력데이터는 공장투입계획(release plan)정보, 투입계획(Inplan)정보, 공정 목표(Step Target)정보 및 페깅히스토리(peghistory)정보 중 적어도 하나를 포함할 수 있다.The input data includes the results of the backward planning logic described above. Here, the input data may include at least one of the following: release plan information, inplan information, step target information, and peghistory information.
실시 예에 따르면, 클라이언트 제조생산시스템으로부터 수신되는 기준 정보에 기초하여 시간의 순방향 흐름에 따라 생산 계획을 설립할 수 있다. 시간 순행 방식에 따라 공장 내에서 작업물 또는 장비의 실제 생산계획을 시뮬레이션할 수 있다. 이러한 포워드 플래닝 방식을 이용하여 효율적인 생산 계획 정보를 생성하여 제공할 수 있다.According to an embodiment, a production plan can be established based on reference information received from a client manufacturing system, following a forward flow of time. The actual production plan for workpieces or equipment within the factory can be simulated using this forward planning method. Using this forward planning method, efficient production planning information can be generated and provided.
클라이언트는 시간 순행 방식으로 실레 공장상황을 시뮬레이션하여 생성된 생산 계획에 따라 보다 더 효율적인 생산 계획을 얻을 수 있다.Clients can simulate the actual factory situation in a time-forward manner and obtain more efficient production plans based on the generated production plan.
도 8을 참조하여 포워드 플래닝 로직을 포함하는 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 설명하면 다음과 같다.Referring to FIG. 8, an embodiment of a device providing digital production planning information including forward planning logic is described as follows.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(310), 저장장치(320), 인메모리(330), 프로세서(340), 출력부(350), 및 사용자인터페이스(360)를 포함할 수 있다.One embodiment of a device providing digital production planning information may include an input unit (310), a storage unit (320), an in-memory unit (330), a processor (340), an output unit (350), and a user interface (360).
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(360)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (360).
입력부(310)는 클라이언트 제조생산시스템으로부터 그 제조생산시스템의 데이터 스키마를 수신할 수 있다.The input unit (310) can receive the data schema of the manufacturing production system from the client manufacturing production system.
저장장치(320)는 입력부(310)가 수신한 데이터 스키마를 저장하거나 또는 정형화된 데이터 스키마가 미리 준비된 경우는 정형화된 데이터 스키마를 저장장치(320)에 저장에 저장할 수 있다. 저장장치(320)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다.The storage device (320) may store the data schema received by the input unit (310), or, if a standardized data schema is prepared in advance, store the standardized data schema in the storage device (320). The storage device (320) may include volatile memory or non-volatile memory.
인메모리(330)는 위에서 개시한 라이브러리 엔진세트를 저장할 수 있다.In-memory (330) can store the library engine set disclosed above.
라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다. 생산 계획 엔진은 위에서 개시하는 포워드 플래닝 로직에 대한 파일을 포함할 수 있다.A library engine set may include a production planning engine, which is a set of encapsulated function block files that generate production plans. The production planning engine may include files for the forward planning logic described above.
추가적으로 라이브러리 엔진세트는, 생산계획엔진과 함께 생산 계획을 구현하는 자료 구조가 포함된 파일인 코어라이브러리, 및 생산계획엔진의 일부 기능을 상속받아서 특정 생산 도메인에서 사용하는 로직을 구현하는 생산도메인특화엔진을 더 포함할 수 있다.Additionally, the library engine set may further include a core library, which is a file containing data structures that implement a production plan together with a production planning engine, and a production domain-specific engine that inherits some of the functions of the production planning engine and implements logic used in a specific production domain.
실시 예의 프로세서(340)는 저장장치(320)에 저장된 데이터 스키마를 입력받을 수 있다. 그리고, 프로세서(340)는 상기 데이터 스키마 및 인메모리(330)에 저장된 엔진 또는 라이브러리에 기초하여 소프트웨어모델 및 로직세트를 생성할 수 있다. 생성된 소프트웨어모델 및 로직세트는 백워드 플래닝 로직을 포함하는 소프트웨어모델 및 로직 세트에 기반하여, 포워드 플래닝 로직에 따라 시간 순행 방식으로 생산 계획 데이터를 생성하도록 할 수 있다. 상술한 바와 같이, 포워드 플래닝 로직은 투입 의사결정 또는 더미 공정처리 이벤트를 포함할 수 있다. 포워드 플래닝 로직에 따라 시간 순행 방식으로 생산 계획 데이터를 생성하는 실시 예들은 도 14 내지 도 17에서 개시하였다.The processor (340) of the embodiment may receive a data schema stored in the storage device (320). In addition, the processor (340) may generate a software model and a logic set based on the data schema and an engine or library stored in the in-memory (330). The generated software model and logic set may generate production planning data in a time-forward manner according to forward planning logic based on the software model and logic set including backward planning logic. As described above, the forward planning logic may include an input decision or a dummy process processing event. Embodiments of generating production planning data in a time-forward manner according to forward planning logic are disclosed in FIGS. 14 to 17.
프로세서(340)는 사용자인터페이스(360)의 사용자의 요청에 따라 상기 생성된 소프트웨어모델 및 로직세트를 테스트하거나 사전 실행하여 생산 계획 데이터를 얻을 수 있다. 그리고 프로세서(340)는 사용자의 요청에 따라 생산 계획 데이터를 생성하는 소프트웨어모델 및 로직을 분석하거나 테스트한 결과를 사용자인터페이스(360)를 통해 사용자에게 제공할 수 있다.The processor (340) can obtain production plan data by testing or pre-executing the generated software model and logic set at the user's request via the user interface (360). Furthermore, the processor (340) can analyze or test the software model and logic that generate the production plan data at the user's request, and provide the results to the user via the user interface (360).
프로세서(340)는 입력부(310)로부터 수신된 데이터 스키마에 따라 상기 제조생산시스템의 기준정보를 포함하는 입력데이터를 수신할 수 있다. 프로세서(340)는 포워드 플래닝 로직에 따라 시간 순행 방식이 포함된 소프트웨어모델 및 로직세트를 실행하여 생산 계획 데이터를 생성할 수 있다. 포워드 플래닝 로직에 따라 생산 계획 데이터를 생성하는 상세한 예시는 도 14 내지 도 17에 개시하였다.The processor (340) can receive input data including reference information of the manufacturing production system according to the data schema received from the input unit (310). The processor (340) can generate production plan data by executing a software model and logic set including a time-forward method according to forward planning logic. Detailed examples of generating production plan data according to forward planning logic are disclosed in FIGS. 14 to 17.
출력부(350)는 포워드 플래닝 로직을 포함한 소프트웨어모델 및 로직세트의 실행 결과에 따른 생산 계획 데이터를 클라이언트 제조생산시스템에 제공하여 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (350) can provide production plan data based on the execution results of a software model and logic set including forward planning logic to a client manufacturing production system so that the client system can manage production or processes.
도 19는 실시 예에 따른 데이터 스키마 및 라이브러리 엔진 세트에 기반하여 소프트웨어모델 및 로직 세트를 생성하는 예를 개시하는 도면FIG. 19 is a diagram disclosing an example of generating a software model and a logic set based on a data schema and a set of library engines according to an embodiment.
도시한 예에서 온프레미스 컴퓨팅 시스템(1000)의 모델개발부(1100)는 데이터 스키마 및 라이브러리 엔진 세트(1150)를 기반으로 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트를 개발할 수 있는 프레임을 제공한다.In the illustrated example, the model development unit (1100) of the on-premise computing system (1000) provides a frame for developing a software model and logic set capable of generating a production plan based on a data schema and library engine set (1150).
일 실시 예에서, 모델개발부(1100)는 모델 생성 모듈(401), 데이터 정의 모듈(402), 메인 모듈(403) 및 실행 모듈(404)을 포함할 수 있다.In one embodiment, the model development unit (1100) may include a model creation module (401), a data definition module (402), a main module (403), and an execution module (404).
모델 생성 모듈(401)은 클라이언트 제조생산시스템에 대한 소프트웨어 모델을 생성할 수 있다. 일 실시 예에서, 클라이언트 제조생산시스템에 대한 소프트웨어 모델 관련 매개변수를 수정하여 소프트웨어 모델을 편집할 수 있다. 일 실시 예에서, 소프트웨어 모델은 클라이언트 제조생산시스템에 대한 데이터 스키마, 데이터 소스, 쿼리(query) 및 전역 변수 중 적어도 하나를 포함할 수 있다.The model generation module (401) can generate a software model for a client manufacturing system. In one embodiment, the software model can be edited by modifying parameters related to the software model for the client manufacturing system. In one embodiment, the software model can include at least one of a data schema, a data source, a query, and a global variable for the client manufacturing system.
여기서, 데이터 스키마는 소프트웨어(SW)모델 또는 로직을 수행하는데 필요한 데이터 구조 및 형식을 나타낼 수 있다. 일 실시 예에서, 데이터 스키마는 입력 데이터 스키마 및 출력 데이터 스키마를 포함할 수 있다. 일 실시 예에서, 입력 데이터 스키마는 클라이언트 제조생산시스템으로부터 수신될 수 있다. 또한, 출력 데이터 스키마는 입력 데이터 스키마에 대응하여 결정되거나, 개발자에 의해 지정될 수 있다.Here, the data schema may represent the data structure and format required to perform a software (SW) model or logic. In one embodiment, the data schema may include an input data schema and an output data schema. In one embodiment, the input data schema may be received from a client manufacturing system. Additionally, the output data schema may be determined in accordance with the input data schema or specified by the developer.
또한, 데이터 소스는 데이터를 불러오기 위한 데이터베이스 연결을 구축할 수 있다. 또한, 데이터 소스는 입력 데이터 및 출력 데이터를 정의하고 데이터 액션(Data Action)을 생성하는 데이터 소스를 포함할 수 있다. 또한, 쿼리는 데이터 소스에 대해 데이터를 요청하는 것을 의미하며, 적어도 하나의 쿼리로 구성될 수 있는 쿼리 관리 단위는 데이터 액션으로 지칭 될 수 있다. 전역 변수는 실행 시 사용되는 로직 실행의 옵션 및 설정값을 정의하는 변수를 포함할 수 있다. 예를 들어, 전역 변수는 로직 실행 시작 시간, 로직 실행 종료 시간, 모델 파일 명 등을 포함할 수 있으나, 이에 제한되지 않고 다양한 변수가 포함될 수 있다.Additionally, a data source can establish a database connection to retrieve data. Furthermore, a data source can include a data source that defines input and output data and creates a data action. Furthermore, a query refers to requesting data from a data source, and a query management unit that can consist of at least one query can be referred to as a data action. Global variables can include variables that define options and settings for logic execution used during execution. For example, global variables can include, but are not limited to, the logic execution start time, the logic execution end time, the model file name, etc., and can include various variables.
일 실시 예에서, 모델 생성 모듈(401)은 입력 데이터 및 출력데이터에 대한 퍼시스트 구성 정보를 생성할 수 있다. 여기서, 퍼시스트 구성 정보는 데이터 스키마에 대응하는 입력데이터를 메모리 상에 로딩하는 입력 퍼시스트 구성(input persist configuration) 정보 및 메모리 상의 데이터 스키마에 대응하는 출력데이터를 저장하는 출력 퍼시스트 구성(output persist configuration) 정보를 포함할 수 있다.In one embodiment, the model generation module (401) may generate persistent configuration information for input data and output data. Here, the persistent configuration information may include input persist configuration information for loading input data corresponding to a data schema into memory, and output persist configuration information for storing output data corresponding to the data schema in memory.
데이터 정의 모듈(402)은 로직 처리를 수행하는 메인 모듈(403) 및 실행 모듈(404)의 실행 시 사용되는 데이터 클래스를 정의할 수 있다. 일 실시 예에서, 데이터 정의 모듈(402)은 라이브러리 엔진세트(1150)에서 제공하는 데이터 클래스를 재정의할 수 있다. 일 실시 예에서, 데이터 정의 모듈(402)은 입력 데이터 스토리지(input data storage)와 출력 데이터 스토리지(output data storage)에 대한 데이터 저장 설정을 정의할 수 있다.The data definition module (402) can define data classes used when executing the main module (403) and the execution module (404) that perform logic processing. In one embodiment, the data definition module (402) can redefine 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.
일 실시 예에서, 입력 데이터 스토리지와 출력 데이터 스토리지는 해당 데이터의 데이터 클래스에 따라 정의된 데이터 컬렉션(collection)과 입력 데이터, 중간 데이터 및 출력 데이터를 저장하는 저장소를 의미할 수 있다. 여기서 데이터 컬렉션은 해당 데이터가 데이터 클래스에 따라 테이블 형태로 정의된 데이터 테이블을 의미할 수 있다. 일 실시 예에서, 데이터 스토리지는 소프트웨어 모델 및 로직 세트가 실행되는 경우 참조될 수 있다.In one embodiment, the input data storage and the output data storage may refer to a data collection defined according to the data class of the corresponding data, and a repository for storing input data, intermediate data, and output data. Here, the data collection may refer to a data table in which the corresponding data is defined in a table format according to the data class. In one embodiment, the data storage may be referenced when the software model and logic set are executed.
메인 모듈(403)은 실행 모듈(404)의 실행을 제어할 수 있다. 일 실시 예에서, 메인 모듈(403)은 소프트웨어 모델에 대한 속성 및 실행 옵션을 설정할 수 있다. 일 실시 예에서, 메인 모듈(403)은 생산 계획 데이터를 제공하기 위한 전체 실행을 제어할 수 있다. 예를 들어, 메인 모듈(403)은 초기 입력 데이터를 로딩하고 실행 모듈(404)을 실행한 후 출력 데이터를 저장하는 과정을 제어할 수 있다.The main module (403) can control the execution of the execution module (404). In one embodiment, the main module (403) can set properties and execution options for the software model. In one embodiment, the main module (403) can control the entire execution for providing production planning data. For example, the main module (403) can control the process of loading initial input data, executing the execution module (404), and then saving the output data.
실행 모듈(404)은 데이터 스키마 및 라이브러리 엔진세트(1150)에 기반하여 클라이언트 제조생산시스템에 대한 페깅 로직(pegging logic) 및 시뮬레이션 로직(simulation logic) 중 적어도 하나를 포함하는 로직 세트를 생성하고 실행할 수 있다. 실행 모듈(404)은 페깅 로직을 생성하는 페깅 모듈과 시뮬레이션 로직을 생성하는 시뮬레이션 모듈 중 적어도 하나를 포함할 수 있다. 여기서, 페깅 로직은 백워드 플래닝 로직에 따라 수요(demand) 정보에 기반하여 재공(work in process)을 페깅하고 잔량에 대한 공정별 공정의 투입목표(In Target) 및 공정의 완료목표(Out Target)을 생성하는 로직을 포함할 수 있다. 또한, 시뮬레이션 로직은 포워드 플래닝 로직에 따라 백워드 플래닝 로직의 결과물에 기반하여 작업물의 최초 투입시점부터 시간 순서대로 공장 내에 발생할 수 있는 이벤트를 실행시켜 실제 생산계획의 시뮬레이션을 수행할 수 있다. 이에 대한 자세한 내용은 상술한 내용을 참고한다.The execution module (404) can generate and execute a logic set including at least one of pegging logic and simulation logic for the client manufacturing production system based on the data schema and library engine set (1150). The execution module (404) can include at least one of a pegging module that generates pegging logic and a simulation module that generates simulation logic. Here, the pegging logic can include logic for pegging work in process based on demand information according to backward planning logic and generating an input target (In Target) and an output target (Out Target) for each process for the remaining quantity. In addition, the simulation logic can perform a simulation of an actual production plan by executing events that may occur in the factory in chronological order from the time of the first input of a workpiece based on the results of the backward planning logic according to the forward planning logic. For more details, refer to the above-described contents.
도 20은 실시 예에 따른 페깅 로직 및 시뮬레이션 로직을 포함하는 로직 세트를 생성하는 예를 개시하는 도면FIG. 20 is a diagram disclosing an example of creating a logic set including pegging logic and simulation logic according to an embodiment.
도시한 예에서 라이브러리 엔진세트(1150)의 코어 레이어(core layer)(405) 및 컨트롤 레이어(control layer)(406)와 사용자와의 상호작용을 위한 사용자 인터페이스에 대한 개발자 인터랙션 레이어(developer interaction layer)(407)를 통해 페깅 로직 및 시뮬레이션 로직을 포함하는 로직 세트가 생성될 수 있다.In the illustrated example, a logic set including pegging logic and simulation logic can be created through a core layer (405) and a control layer (406) of a library engine set (1150) and a developer interaction layer (407) for a user interface for interaction with a user.
코어 레이어(405)는 페깅 로직에 대응하는 백워드 플래닝 로직과 시뮬레이션 로직에 대응하는 포워드 플래닝 로직의 기능 단위 및 이러한 기능 단위들의 연계 관계 및 상호 작용 정보를 포함할 수 있다. 예를 들어, 기능 단위는 시뮬레이션 로직의 경우 공장(factory), 물류이동(transfer), 투입 의사결정(dispatching) 및 장비(equipment)를 포함할 수 있으나, 이에 제한되지 않는다.The core layer (405) may include functional units of backward planning logic corresponding to pegging logic and forward planning logic corresponding to simulation logic, as well as information on the linkage relationships and interactions between these functional units. For example, in the case of simulation logic, functional units may include, but are not limited to, factory, transfer, dispatching, and equipment.
컨트롤 레이어(406)는 코어 레이어(405)에 포함된 기능 단위를 제어하는 이벤트 및 이벤트 내부 함수를 포함할 수 있다. 일 실시 예에서, 각 기능 단위에 대응하는 적어도 하나의 이벤트 및 이벤트 내부 함수가 구성될 수 있다. 예를 들어, 투입 의사결정에 대한 대안 특성의 값을 평가하는 이벤트가 포함될 수 있다.The control layer (406) may include events and internal event functions that control the functional units included in the core layer (405). In one embodiment, at least one event and internal event function corresponding to each functional unit may be configured. For example, an event that evaluates the value of an alternative characteristic for an input decision may be included.
개발자 인터랙션 레이어(407)는 이벤트 및 이벤트 내부 함수 중 적어도 하나에 대응하는 로직 함수 코드를 포함할 수 있다. 여기서, 로직 함수 코드는 페깅 로직 및 시뮬레이션 로직을 구현하기 위한 함수 코드를 포함할 수 있다. 일 실시 예에서, 컨트롤 레이어(406)의 이벤트 및 이벤트 내부 함수와 로직 함수 코드를 바인딩(binding)하는 바인딩 코드와 로직 함수 코드를 구현함으로써 페깅 로직 및 시뮬레이션 로직이 생성될 수 있다. 일 실시 예에서, 개발자 인터랙션 레이어(407)의 로직 함수 코드는 사전 구현되어 미리 저장되어 있을 수 있다.The developer interaction layer (407) may include logic function code corresponding to at least one of an event and an event internal function. Here, the logic function code may include function code for implementing pegging logic and simulation logic. In one embodiment, the pegging logic and simulation logic may be generated by implementing binding code and logic function code that bind the event and event internal function of the control layer (406) and the logic function code. In one embodiment, the logic function code of the developer interaction layer (407) may be pre-implemented and pre-stored.
이 경우, 이벤트 및 이벤트 내부 함수에 대응하는 로직 포인트에 해당하는 바인딩 코드는 로직 함수 코드와 1:N의 관계를 가질 수 있다. 즉, 하나의 로직 포인트에 복수의 로직 함수 코드가 설정될 수 있다. 예를 들어, 투입 의사결정에 대한 대안 특성의 값을 평가하는 로직 포인트에서는 평가 조건의 수만큼 로직 함수 코드가 설정될 수 있다. 이와 같이, 바인딩 코드에 대한 로직 함수 코드가 다수 개인 경우, 로직 함수 코드 간 실행 순서가 지정될 수 있다.In this case, the binding code corresponding to the logic point corresponding to the event and the event internal function can have a 1:N relationship with the logic function code. That is, multiple logic function codes can be set for a single logic point. For example, in a logic point that evaluates the value of an alternative characteristic for an input decision, as many logic function codes as the number of evaluation conditions can be set. In this way, when there are multiple logic function codes for a binding code, the execution order between the logic function codes can be specified.
일 실시 예에서, 코어 레이어(405), 컨트롤 레이어(406) 및 개발자 인터랙션 레이어(407)를 포함하는 로직 개발 레이어 세트는 페깅 로직 및 시뮬레이션 로직 각각에 대하여 구성될 수 있다. 일 실시 예에서, 로직 개발 레이어 세트에 기반하여 로직 세트를 생성하는 과정은 메인 모듈(403)에 의해 제어될 수 있다.In one embodiment, a set of logic development layers including a core layer (405), a control layer (406), and a developer interaction layer (407) may be configured for each of the pegging logic and the simulation logic. In one embodiment, the process of generating a logic set based on the set of logic development layers may be controlled by the main module (403).
일 실시 예에서, 메인 모듈(403)에 의해 관리되는 로직 세트는 페깅 로직과 시뮬레이션 로직에 제한되지 않으며, 기능에 따라 다양한 로직이 추가될 수 있다.In one embodiment, the logic set managed by the main module (403) is not limited to pegging logic and simulation logic, and various logics may be added depending on the function.
도 21은 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법이 소프트웨어모델 및 로직 세트를 생성하는 예를 개시하는 도면FIG. 21 is a drawing disclosing an example of a method for providing digital production planning information according to an embodiment of the present invention, wherein the method generates a software model and a logic set.
클라이언트 제조생산시스템에 대한 생산도메인특화엔진을 결정한다(S411). 일 실시 예에서, 클라이언트 별로 생산 분야가 다르고 해당 분야마다 특징적인 요소가 있기 때문에 어떤 분야, 즉, 특정 생산 도메인의 클라이언트 제조생산시스템에 대한 모델링을 수행할 것인지 선택하여 생산도메인특화엔진을 결정할 수 있다. 일 실시 예에서, 미리 생성된 생산도메인특화엔진 중 클라이언트 제조생산시스템에 기반하여 어떤 생산도메인특화엔진을 사용할 지 결정할 수 있다.A production domain-specific engine for the client manufacturing system is determined (S411). In one embodiment, since each client has a different production field and each field has unique elements, the production domain-specific engine can be determined by selecting which field, i.e., a specific production domain, to model for the client manufacturing system. In one embodiment, among the pre-generated production domain-specific engines, the production domain-specific engine to use can be determined based on the client manufacturing system.
일 실시 예에서, 라이브러리 엔진세트(1150)의 생산도메인특화엔진은 생산계획엔진의 일부 기능을 상속받아서 특정 생산 도메인에서 사용하는 로직을 구현한 데이터 세트로서 산업이나 제조생산시스템에 따라 다르게 정의될 수 있다.In one embodiment, the production domain-specific engine of the library engine set (1150) inherits some functions of the production planning engine and is a data set that implements logic used in a specific production domain and may be defined differently depending on the industry or manufacturing production system.
일 실시 예에서, 특정 생산 도메인에 대한 생산도메인특화엔진은 일반(general) 도메인에 대한 로직이 그대로 상속되어 있으며, 추가적으로 해당 특정 생산 도메인 관련 로직을 포함할 수 있다. 예를 들어, 특정 생산 도메인은 LCD 도메인을 포함할 수 있다. 이 경우, LCD 도메인에 해당하는 생산도메인특화엔진은 일반(general) 도메인에 대한 백워드 플래닝 로직과 포워드 플래닝 로직이 그대로 상속되어 있으며, 추가적으로 LCD 도메인에 대한 TFT(Thin Film Transistor) 공정, CF(Color Filter) 공정 및 LC(Liquid Crystral) 공정 관련 로직을 포함할 수 있다.In one embodiment, a production domain-specific engine for a specific production domain may inherit the logic for a general domain as is, and may additionally include logic related to the specific production domain. For example, the specific production domain may include an LCD domain. In this case, the production domain-specific engine corresponding to the LCD domain may inherit the backward planning logic and forward planning logic for the general domain as is, and may additionally include logic related to a TFT (Thin Film Transistor) process, a CF (Color Filter) process, and an LC (Liquid Crystral) process for the LCD domain.
클라이언트 제조생산시스템에 대한 소프트웨어 모델을 생성한다(S412). 일 실시 예에서, 클라이언트 제조생산시스템에 대한 데이터 스키마, 데이터 소스, 쿼리 및 전역 변수 중 적어도 하나를 포함하는 소프트웨어 모델을 생성할 수 있다. 일 실시 예에서, 소프트웨어 모델은 사용자 인터페이스를 통한 사용자 입력에 따라 편집될 수 있다. 이에 대한 자세한 내용은 상술한 설명을 참조한다.A software model for the client manufacturing system is created (S412). In one embodiment, a software model including at least one of a data schema, a data source, a query, and a global variable for the client manufacturing system can be created. In one embodiment, the software model can be edited based on user input via a user interface. For more details, see the above description.
입력 데이터 및 출력데이터에 대한 퍼시스트 구성 정보를 생성한다(S413). 일 실시 예에서, 퍼시스트 구성 정보는 입력 퍼시스트 구성 정보 및 출력 퍼시스트 구성 정보를 포함할 수 있다. 이 경우, 입력 퍼시스트 구성 정보는 입력 데이터를 메모리 상의 데이터로 로딩하는 절차와 방식을 나타낼 수 있다. 예를 들어, 입력 퍼시스트 구성 정보는 DB에서 쿼리 실행 순서, DB에서 쿼리 수행 스레드 개수 및 DB 네트워크 연결 해제 시 재시도 횟수를 포함할 수 있으나, 이에 제한되지 않는다.Generate persistent configuration information for input data 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 indicate the procedure and method for loading input data as data in memory. For example, the input persistent configuration information may include, but is not limited to, the query execution order in the DB, the number of query execution threads in the DB, and the number of retries when the DB network connection is disconnected.
또한, 출력 퍼시스트 구성 정보는 메모리 상의 출력 데이터를 파일이나 데이터베이스(DB)에 저장하는 절차와 방식을 나타낼 수 있다. 예를 들어, 출력 퍼시스트 구성 정보는 데이터 저장 여부 설정 및 데이터 저장 시간 기록 여부 설정을 포함할 수 있으나, 이에 제한되지 않는다.Additionally, output persistence configuration information may indicate the procedure and method for storing output data in memory to a file or database (DB). For example, output persistence configuration information may include, but is not limited to, settings for whether to store data and whether to record the data storage time.
일 실시 예에서, 퍼시스트 구성 정보는 데이터 스키마, 데이터 소스, 쿼리(query) 및 전역 변수 중 적어도 하나에 기반하여 사용자 입력에 따라 생성될 수 있다.In one embodiment, the persistent configuration information can be generated based on user input based on at least one of a data schema, a data source, a query, and a global variable.
입력 데이터 불러오기 동작 및 데이터 구조를 결정한다(S414). 일 실시 예에서, 입력 데이터 불러오기 동작은 입력 데이터를 DB에서 읽어올 때의 동작을 의미할 수 있다. 예를 들어, 데이터를 불러오는 동작은 데이터를 1줄 읽어 올 때마다 실행되는 이벤트 및 모든 데이터를 다 읽어온 후 실행되는 이벤트를 포함할 수 있다.The input data retrieval operation and data structure are determined (S414). In one embodiment, the input data retrieval operation may refer to an operation performed when reading input data from a database. For example, the data retrieval operation may include an event executed each time a line of data is read and an event executed after all data has been read.
일 실시 예에서, 데이터를 읽어오는 과정에서 모델 내부 로직에서 사용할 데이터 구조를 전처리할 수 있다. 예를 들어, Product/Process/Step 테이블이 각각 존재하는 경우, Product, Process 및 Step 각각을 서로 종속적으로 연결해주는 로직을 구현할 수 있다.In one embodiment, data structures used in the model's internal logic can be preprocessed during the data read process. For example, if Product/Process/Step tables exist, logic can be implemented to interlink Product, Process, and Step in a dependent manner.
일 실시 예에서, 데이터 구조는 데이터 스키마에 정의된 구조가 자동으로 생성되어 저장되는 자료 구조 및 사용자 입력에 의해 생성되는 자료 구조를 포함할 수 있다. 일 실시 예에서, 입력 값에 관여하고 모델 내부 로직에서 지속적으로 사용될 항목은 입력 데이터 메모리 공간에 저장하고, 출력 값에 관여하고 모델 내부 로직의 중간/최종 산출물은 출력 데이터 메모리 공간에 저장할 수 있다. 여기서, 해당 데이터 메모리 공간은 메모리 상 프로그램이 동작할 때 임시로 존재하는 가상 메모리 공간을 포함할 수 있다.In one embodiment, the data structure may include a data structure in which a structure defined in a data schema is automatically generated and stored, and a data structure generated by user input. In one embodiment, items that are involved in input values and will be continuously used in the internal logic of the model may be stored in an input data memory space, and items that are involved in output values and intermediate/final outputs of the internal logic of the model may be stored in an output data memory space. Here, the data memory space may include a virtual memory space that temporarily exists when a program is executed in memory.
페깅 로직 및 시뮬레이션 로직을 생성한다(S415). 일 실시 예에서, 라이브러리 엔진세트의 백워드 플래닝 로직 및 포워드 플래닝 로직 관련 기능 단위에 대한 이벤트 및 이벤트 내부 함수에 대한 세부 로직 함수 코드를 작성하여 페깅 로직 및 시뮬레이션 로직을 생성할 수 있다. 이에 대한 자세한 설명은 상술한 내용을 참고한다.Generate pegging logic and simulation logic (S415). In one embodiment, pegging logic and simulation logic can be generated by writing detailed logic function code for events and internal event functions for functional units related to backward planning logic and forward planning logic of the library engine set. For a detailed description, refer to the above description.
일 실시 예에서, 로직 함수를 구현하기 위한 사용자 인터페이스에 대한 사용자의 클릭 입력이 획득되는 경우, 해당 함수에 대한 로직 함수 코드와 그 함수를 엔진세트에 연결하는 바인딩 코드가 자동 생성될 수 있다.In one embodiment, when a user click input for a user interface for implementing a logic function is obtained, logic function code for that function and binding code connecting that function to a set of engines can be automatically generated.
일 실시 예에서, 구현 대상 함수 중에 구현된 부분은 특정 파일 형식(예: xml 등)으로 저장될 수 있으며, 모델 개발부(1100)가 다시 실행되는 경우에도 편집 내용을 이어서 확인할 수 있다.In one embodiment, the implemented portion of the implementation target function can be saved in a specific file format (e.g., xml, etc.), and the edited contents can be continuously checked even when the model development unit (1100) is executed again.
소프트웨어 모델 파일 및 로직 파일을 획득한다(S416). 일 실시 예에서, 페깅 로직 및 시뮬레이션 로직을 포함하는 소프트웨어 모델 파일 및 로직 파일을 획득할 수 있다. 일 실시 예에서, 저장 및 빌드를 통해 해당 모델 파일 및 로직 파일을 획득할 수 있다.Obtain a software model file and a logic file (S416). In one embodiment, a software model file and a logic file including pegging logic and simulation logic may be obtained. In one embodiment, the model file and logic file may be obtained through storage and build.
일 실시 예에서, S414 내지 S416 단계는 순서에 관계없이 수행될 수 있으며, 동시에 또는 별도로 수행될 수 있다. 또한, 해당 정보가 미리 결정되어 있는 경우 적어도 하나의 단계가 생략될 수 있다.In one embodiment, steps S414 to S416 may be performed in any order and may be performed simultaneously or separately. Additionally, at least one step may be omitted if the corresponding information is predetermined.
도 22는 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법이 생산 계획을 생성하는 예를 개시하는 흐름도Figure 22 is a flowchart disclosing an example of a method for providing digital production plan information according to an embodiment of the present invention to generate a production plan.
클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나에 기반하여 상기 클라이언트 제조생산시스템에 대한 페깅 로직(pegging logic) 및 시뮬레이션 로직(simulation logic) 중 적어도 하나를 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공한다(S417). 일 실시 예에서, 상기 데이터 스키마, 상기 입력데이터에 대한 데이터 소스(data source), 상기 데이터 스키마에 대한 쿼리(query) 및 전역 변수(argument) 중 적어도 하나에 기반하여 소프트웨어 모델을 생성할 수 있다.A software model and logic set including at least one of pegging logic and simulation logic for a client manufacturing system are generated or provided based on at least one of a data schema and a library engine set of the client manufacturing system (S417). In one embodiment, the software model may be generated based on at least one of the data schema, a data source for the input data, a query for the data schema, and a global variable (argument).
일 실시 예에서, 라이브러리 엔진세트에 포함된 적어도 하나의 기능 단위에 포함된 작업물 또는 장비에 대한 이벤트 및 이벤트 내부 함수 중 적어도 하나를 구성하고, 이벤트 및 이벤트 내부 함수 중 적어도 하나에 대응하는 로직 함수 코드를 바인딩(binding)하여 페깅 로직 및 시뮬레이션 로직 중 적어도 하나를 생성할 수 있다.In one embodiment, at least one of an event and an event internal function for a workpiece or equipment included in at least one functional unit included in a library engine set may be configured, and at least one of the pegging logic and the simulation logic may be generated by binding logic function code corresponding to at least one of the event and the event internal function.
일 실시 예에서, 라이브러리 엔진세트는, 시간 역행 방식의 백워드 플래닝(backward planning) 로직 및 시간 순행 방식인 포워드 플래닝(forward planning) 로직 중 적어도 하나를 포함할 수 있다. 이에 대하여는 도 19 내지 21에서 상술한 내용을 참고하도록 한다.In one embodiment, the library engine set may include at least one of backward planning logic in a time-reversing manner and forward planning logic in a time-forward manner. For details, refer to the descriptions in FIGS. 19 to 21.
데이터 스키마에 따라 상기 클라이언트로부터 기준정보를 포함하는 입력데이터를 수신한다(S418). 일 실시 예에서, 입력데이터는 제품 정보, 생산흐름 정보, 공정 정보, 장비 정보, 이동시간 정보, 공장내부 작업물 정보 및 기생산물량 정보 중 적어도 하나를 포함할 수 있다. 일 실시 예에서, 입력데이터는 상술한 백워드 플래닝 로직의 결과물을 포함할 수 있다. 이에 대하여는 도 19 내지 21에서 상술한 내용을 참고하도록 한다.Input data including reference information is received from the client according to the data schema (S418). In one embodiment, the input data may include at least one of product information, production flow information, process information, equipment information, travel time information, factory-internal workpiece information, and production volume information. In one embodiment, the input data may include the results of the aforementioned backward planning logic. For more information, please refer to the contents described in FIGS. 19 to 21.
수신된 입력데이터를 기반으로 상기 소프트웨어모델 및 로직 세트를 수행하여 생산 계획 데이터를 제공한다(S419). 일 실시 예에서, 소프트웨어모델 및 로직 세트가 포워드 플래닝 로직을 포함할 경우, 백워드 플래닝 로직으로부터 얻은 공정목표정보(Step Target) 및 공장 투입계획정보(Release Plan)를 이용하여, 시간 순방향에 따라 생산 계획 정보를 생성할 수 있다. 이에 대하여는 도 19 내지 21에서 상술한 내용을 참고하도록 한다.Based on the received input data, the software model and logic set are executed to provide production planning data (S419). In one embodiment, if the software model and logic set include forward planning logic, the process target information (Step Target) and factory release plan information (Release Plan) obtained from the backward planning logic can be used to generate production planning information in a time-forward direction. For more information, please refer to the details described above in Figures 19 to 21.
도 8을 참조하여 페깅 로직 및 시뮬레이션 로직 중 적어도 하나를 포함하는 소프트웨어모델 및 로직 세트에 기반하여 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 설명하면 다음과 같다.Referring to FIG. 8, an embodiment of a device for providing digital production planning information based on a software model and logic set including at least one of pegging logic and simulation logic is described as follows.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(310), 저장장치(320), 인메모리(330), 프로세서(340), 출력부(350), 및 사용자인터페이스(360)를 포함할 수 있다.One embodiment of a device providing digital production planning information may include an input unit (310), a storage unit (320), an in-memory unit (330), a processor (340), an output unit (350), and a user interface (360).
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(360)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (360).
입력부(310)는 클라이언트 제조생산시스템으로부터 그 제조생산시스템의 데이터 스키마를 수신할 수 있다.The input unit (310) can receive the data schema of the manufacturing production system from the client manufacturing production system.
저장장치(320)는 입력부(310)가 수신한 데이터 스키마를 저장하거나 또는 정형화된 데이터 스키마가 미리 준비된 경우는 정형화된 데이터 스키마를 저장장치(320)에 저장에 저장할 수 있다. 저장장치(320)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다.The storage device (320) may store the data schema received by the input unit (310), or, if a standardized data schema is prepared in advance, store the standardized data schema in the storage device (320). The storage device (320) may include volatile memory or non-volatile memory.
인메모리(330)는 위에서 개시한 라이브러리 엔진세트를 저장할 수 있다. 라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다. 생산 계획 엔진은 위에서 개시하는 백워드 플래닝 로직 및 포워드 플래닝 로직 중 적어도 하나에 대한 파일을 포함할 수 있다.The in-memory (330) can store the library engine set disclosed above. The library engine set can include a production planning engine, which is a number of encapsulated function block files that generate a production plan. The production planning engine can include files for at least one of the backward planning logic and forward planning logic disclosed above.
추가적으로 라이브러리 엔진세트는, 생산계획엔진과 함께 생산 계획을 구현하는 자료 구조가 포함된 파일인 코어라이브러리, 및 생산계획엔진의 일부 기능을 상속받아서 특정 생산 도메인에서 사용하는 로직을 구현하는 생산도메인특화엔진을 더 포함할 수 있다.Additionally, the library engine set may further include a core library, which is a file containing data structures that implement a production plan together with a production planning engine, and a production domain-specific engine that inherits some of the functions of the production planning engine and implements logic used in a specific production domain.
실시 예의 프로세서(340)는 저장장치(320)에 저장된 데이터 스키마를 입력받을 수 있다. 그리고, 프로세서(340)는 상기 데이터 스키마 및 인메모리(330)에 저장된 엔진 또는 라이브러리에 기초하여 소프트웨어모델 및 로직세트를 생성할 수 있다. 일 실시 예에서, 프로세서(340)는 클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나에 기반하여 클라이언트 제조생산시스템에 대한 페깅 로직(pegging logic) 및 시뮬레이션 로직(simulation logic) 중 적어도 하나를 포함하는 소프트웨어모델 및 로직 세트를 생성하거나 제공할 수 있다. 이에 대한 상세한 내용은 상술한 설명을 참조한다.The processor (340) of the embodiment may receive a data schema stored in the storage device (320). In addition, the processor (340) may generate a software model and a logic set based on the data schema and an engine or library stored in the in-memory (330). In one embodiment, the processor (340) may generate or provide a software model and a logic set including at least one of pegging logic and simulation logic for the client manufacturing production system based on at least one of the data schema and the library engine set of the client manufacturing production system. For details thereof, refer to the above description.
프로세서(340)는 사용자인터페이스(360)의 사용자의 요청에 따라 상기 생성된 소프트웨어모델 및 로직세트를 테스트하거나 사전 실행하여 생산 계획 데이터를 얻을 수 있다. 그리고 프로세서(340)는 사용자의 요청에 따라 생산 계획 데이터를 생성하는 소프트웨어모델 및 로직을 분석하거나 테스트한 결과를 사용자인터페이스(360)를 통해 사용자에게 제공할 수 있다.The processor (340) can obtain production plan data by testing or pre-executing the generated software model and logic set at the user's request via the user interface (360). Furthermore, the processor (340) can analyze or test the software model and logic that generate the production plan data at the user's request, and provide the results to the user via the user interface (360).
프로세서(340)는 입력부(310)로부터 수신된 데이터 스키마에 따라 상기 제조생산시스템의 기준정보를 포함하는 입력데이터를 수신할 수 있다. 프로세서(340)는 입력데이터를 기반으로 페깅 로직 및 시뮬레이션 로직에 따라 소프트웨어모델 및 로직세트를 실행하여 생산 계획 데이터를 생성할 수 있다. 이에 대한 상세한 내용은 상술한 설명을 참조한다.The processor (340) can receive input data containing reference information of the manufacturing production system according to the data schema received from the input unit (310). Based on the input data, the processor (340) can execute a software model and logic set according to the pegging logic and simulation logic to generate production plan data. For details, refer to the above description.
출력부(350)는 포워드 플래닝 로직을 포함한 소프트웨어모델 및 로직세트의 실행 결과에 따른 생산 계획 데이터를 클라이언트 제조생산시스템에 제공하여 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (350) can provide production plan data based on the execution results of a software model and logic set including forward planning logic to a client manufacturing production system so that the client system can manage production or processes.
이하의 실시 예에서는 설치된 라이브러리 엔진 세트를 기반으로 생성된 소프트웨어모델 및 로직 세트를 이용하여 생산 계획 데이터를 제공하는 일 예를 상세히 개시한다.The following examples detail an example of providing production planning data using a software model and logic set generated based on an installed set of library engines.
설명한 바와 같이 온프레미스 컴퓨팅 시스템(1000)의 모델개발부(1100)는 라이브러리 엔진 세트(1150)를 기반으로 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트를 개발할 수 있는 프레임을 제공한다.As described, the model development unit (1100) of the on-premise computing system (1000) provides a frame for developing a software model and logic set capable of generating a production plan based on a library engine set (1150).
다른 예로서, 클라우드 컴퓨팅 시스템(2000)은 라이브러리 엔진 세트(2210)를 기반으로 생산 계획을 생성할 수 있는 정형화된 다수의 소프트웨어 모델 및 로직 세트들을 제공할 수 있다.As another example, the cloud computing system (2000) may provide a number of standardized software models and logic sets that can generate production plans based on a set of library engines (2210).
일 실시 예에서, 소프트웨어 모델은 클라이언트 제조생산시스템에 대한 데이터 스키마, 데이터 소스, 쿼리(query) 및 전역 변수 중 적어도 하나를 포함할 수 있다. 또한, 로직 세트는 클라이언트 제조생산시스템에 대한 페깅 로직(pegging logic) 또는 시뮬레이션 로직(simulation logic)뿐만 아니라 제조생산시스템을 정의하는 다른 로직을 포함 할 수 있다.In one embodiment, the software model may include at least one of a data schema, a data source, a query, and a global variable for the client manufacturing system. Additionally, the logic set may include pegging logic or simulation logic for the client manufacturing system, as well as other logic defining the manufacturing system.
개시하는 실시 예에서는 시스템운영부(110)를 통해 소프트웨어 모델 및 로직 세트의 실행에 필요한 작업들을 생성하고 실행 주기 및 의존성을 설정하는 절차를 수행하는 예를 설명한다.In the disclosed embodiment, an example of performing a procedure for creating tasks necessary for executing a software model and logic set and setting an execution cycle and dependency through a system operation unit (110) is described.
상술한 바와 같이, 시스템운영부(110)는 모델개발부(1100)가 생성한 소프트웨어 모델 및 로직 세트를 클라이언트에 전달하고, 클라이언트의 제조생산시스템(100)이 생산 계획 데이터를 생성하게 하여 생산 운영이 진행되도록 할 수 있다.As described above, the system operation unit (110) can transmit the software model and logic set created by the model development unit (1100) to the client and cause the client's manufacturing production system (100) to create production plan data so that production operation can proceed.
시스템운영부(110)는, 클라이언트의 제조생산시스템(100)의 프로젝트나 작업 관리, 계획에 따라 프로젝트 또는 작업을 운영하기 위한 트리거(실행조건)의 관리, 및 그 모니터링과 성능을 변경하고 설정할 수 있다.The system operation department (110) can manage the project or task of the client's manufacturing production system (100), manage triggers (execution conditions) for operating a project or task according to a plan, and change and set the monitoring and performance thereof.
예를 들어, 시스템운영부(110)는 작업을 운영하기 위한 트리거 관리, 모니터링과 성능 변경을 위한 사용자 인터페이스인 서버 관리부(1200)를 제공하여, 시스템운영부(110)를 통해 작업을 생성 및 관리할 수 있도록 할 수 있다. 즉, 작업을 생성하고 관리를 수행하는 것은 시스템운영부(110) 또는 서버관리부를 통해서 이루어진 것으로 설명될 수 있다.For example, the system operation unit (110) may provide a server management unit (1200), which is a user interface for trigger management, monitoring, and performance changes for operating tasks, so that tasks can be created and managed through the system operation unit (110). In other words, creating and managing tasks can be explained as being performed through the system operation unit (110) or the server management unit.
예를 들어, 시스템운영부(110)는 작업물 생성 및 관리에 대하여 사용자에게 시각적으로 보여지는 사용자 인터페이스(UI) 및 작업 생성 및 관리에 대한 백엔드(backend) 시스템을 포함할 수 있다.For example, the system operation unit (110) may include a user interface (UI) that visually displays to the user the creation and management of work items and a backend system for the creation and management of work items.
도 23은 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 운영 작업을 생성하는 예를 개시하는 도면이다.FIG. 23 is a diagram disclosing an example of generating an operational task based on a software model and logic set according to an embodiment.
시스템운영부(110)는 업로드된 소프트웨어 모델 및 로직 세트에 기반하여 운영 작업을 생성하고 운영 작업을 수행하기 위한 조건들을 설정할 수 있다.The system operation unit (110) can create an operation task based on the uploaded software model and logic set and set conditions for performing the operation task.
상술한 바와 같이, 모델 개발부(1100)는 페깅 로직 및 시뮬레이션 로직을 포함하는 소프트웨어 모델 및 로직 세트를 획득(개발)할 수 있다. 예를 들어, 소프트웨어 모델은 데이터 스키마, 데이터 소스, 쿼리(query) 및 전역 변수 중 적어도 하나를 포함할 수 있다.As described above, the model development unit (1100) can acquire (develop) a software model and logic set including pegging logic and simulation logic. For example, the software model may include at least one of a data schema, a data source, a query, and a global variable.
또한, 모델 개발부(1100)에서 획득된 소프트웨어 모델 및 로직 세트는 시스템운영부(110)에 업로드될 수 있다. 상술한 바와 같이, 시스템운영부(110)는 사용자에게 제공되는 사용자 인터페이스를 포함하여, 시스템운영부(110)의 동작을 사용자가 확인하고 제어할 수 있도록 한다.Additionally, the software model and logic set acquired from 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 check and control the operation of the system operation unit (110).
시스템운영부(110)는 다양한 서비스를 포함하는 서비스부(1260), 이력관리 저장부(1270)을 포함할 수 있다.The system operation unit (110) may include a service unit (1260) including various services and a history management storage unit (1270).
서비스부(1260)는 라이선스서비스부(license service)(1205), 작업서비스부(job service)(1210), 배포관리서비스부(deploy management service)(1215), 외부파일서비스부(outfile service)(1220), 작업스케쥴러서비스부(job scheduler service)(1230) 등을 포함할 수 있다.The service unit (1260) may include a license service unit (1205), a job service unit (1210), a deploy management service unit (1215), an outfile service unit (1220), a job scheduler service unit (1230), etc.
라이선스서비스부(license service)(1205)는 사용자별로 할당된 서비스가 적법하게 구매된 것인지 관리하는 파트로서, 예를 들어, 사용자가 구매한 라이선스가 만료되었는지 점검하는 방식으로 동작될 수 있다.The license service (1205) is a part that manages whether the services allocated to each user have been legally purchased. For example, it can operate by checking whether the license purchased by the user has expired.
작업서비스부(job service)(1210)는 운영작업(task), 운영작업의 주기 등을 생성하는 파트이고, 배포관리서비스부(deploy management service)(1215)는 모델개발부(1100)로부터 수신된 파일을 이력관리 저장부(1270)로 업로드하는 파트로서, 사용자의 입력에 따라 사용 버전을 관리하도록 설정될 수 있다.The job service (1210) is a part that creates operational tasks, operational task cycles, etc., and the deploy management service (1215) is a part that uploads files received from the model development (1100) to the history management storage (1270), and can be set to manage the usage version according to the user's input.
외부파일서비스부(outfile service)(1220)는 운영작업을 통한 결과물을 외부에서 다운로드할 수 있게 해주는 파트이고, 작업스케쥴러 서비스(job scheduler service)(1230)는 작업서비스부(1210)에서 편집된 운영작업을 실행조건에 따라 실행시키는 파트에 해당할 수 있다.The external file service (outfile service) (1220) is a part that allows the results of an operation task to be downloaded from the outside, and the job scheduler service (1230) may correspond to a part that executes an operation task edited in the job service (1210) according to execution conditions.
또한, 이력관리 저장부(1270)는 시스템운영부(110)에서 운영작업을 생성 및 설정하기 위해 필요한 소프트웨어 모델 및 로직 세트를 일시적으로 저장할 수 있고, 운영작업과 관련된 파일을 저장할 수 있다. 또한, 시스템운영부(110)에서 사용되는 각종 설정값(프로젝트별 데이터 소스, 운영작업 목록, 실행주기, 의존성 조건 등)은 이력관리 저장부(1270) 또는 별도의 저장부에 저장될 수 있다.In addition, the history management storage unit (1270) can temporarily store software models and logic sets required to create and set up operation tasks in the system operation unit (110), and can store files related to the operation tasks. In addition, various setting values (project-specific data sources, operation task lists, execution cycles, dependency conditions, etc.) used in the system operation unit (110) can be stored in the history management storage unit (1270) or a separate storage unit.
예를 들어, 배포관리서비스부(1215)에서 제공하는 배포관리서비스는 배포(업로드)가 발생할 때 이력관리 저장부(1270)에 배포 대상이 속한 프로젝트별 경로에 파일을 저장할 수 있다. 이때, 배포관리서비스부(1215)는 파일을 저장 시 배포 시점 별로 소프트웨어 모델 및 로직세트의 이력관리를 제공할 수 있다.For example, the distribution management service provided by the distribution management service department (1215) can store files in the project-specific path to which the distribution target belongs in the history management storage department (1270) when distribution (upload) occurs. At this time, the distribution management service department (1215) can provide history management of software models and logic sets by distribution time when storing files.
여기에서, 이력관리는 현재 운영작업에 적용하는 버전과 과거 운영작업에 적용하는 버전을 별도로 관리하고 있어, 필요에 따라 과거 또는 현재 버전을 사용할 수 있게 하는 것이다. 예를 들어, 1월1일 시점에 주간계획 프로젝트의 소프트웨어 모델 및 로직 세트을 업로드하여 운영작업을 실행해 온것으로 가정할 수 있다. 이 경우, 2월2일에 고객 요청으로 신규 제품에 대한 로직이 추가되어 신규 소프트웨어 모델 및 로직 세트가 업로드되어 운영작업을 실행할 수 있다. 이때, 2월2일 버전은 추가 연산을 요구하는 로직에 해당할 수 있다. 3월3일에 고객 사정으로 신규제품에 대한 생산계획이 취소되어 추가 연산이 요구되는 2월2일 로직대신 1월1일 로직을 사용하기로 결정되는 경우, 배포관리서비스부(1215)는 1월1일 배포 버전으로 변경하여 실행할 수 있다.Here, history management separately manages the version applied to the current operation and the version applied to the past operation, allowing the use of either the past or present version as needed. For example, let's assume that the software model and logic set for the weekly plan project were uploaded and the operation was executed on January 1st. In this case, on February 2nd, logic for a new product is added at the customer's request, and the new software model and logic set can be uploaded and the operation can be executed. In this case, the February 2nd version may correspond to logic that requires additional calculation. If the production plan for the new product is canceled on March 3rd due to customer circumstances and it is decided to use the January 1st logic instead of the February 2nd logic that requires additional calculation, the Distribution Management Service Department (1215) can change it to the January 1st distribution version and execute it.
또한, 시스템운영부(110)의 작업서비스부(1210)를 통해 운영작업이 생성될 수 있다. 이때, 운영 작업은 소프트웨어 모델 및 로직 세트를 실행(운영)하는데 필요한 작업에 해당한다. 운영 작업(job type)은 전자메일 보내기, 프로그램 실행, 모델 실행의 3가지를 포함할 수 있고, 이외에도 사용자의 설정 또는 시스템 설정에 따라 실험허브(experiment hub) 실행, 동적운영을 위한 작업 등 다양한 실행작업이 추가될 수 있다. 또한, 운영작업은 작업스케쥴러 서비스부(1205)가 실행하는 작업의 단위에 해당할 수 있다.Additionally, operational tasks can be created through the task service unit (1210) of the system operation unit (110). At this time, operational tasks correspond to tasks required to execute (operate) software models and logic sets. Operational tasks (job types) can include three types: sending emails, executing programs, and executing models. Additionally, various execution tasks, such as executing experiment hubs and tasks for dynamic operation, can be added based on user or system settings. Furthermore, operational tasks can correspond to units of tasks executed by the task scheduler service unit (1205).
전자메일 보내기 작업유형(job type)은 소프트웨어 모델 및 로직 세트의 실행과 관련되어 전자메일을 보내는 작업을 포함한다. 예를 들어, 전역 변수(argument)로 보낸사람, 받는사람, 제목, 본문 및 첨부파일을 지정될 수 있고, 보내는 메일 서버(SMTP)가 설정될 수 있다. 여기에서, 전역 변수는 로직 실행의 옵션 및 설정값을 정의하는 변수에 해당할 수 있다. 또한, 설정된 전자메일 보내기가 실행되면 미리 설정된 바에 따라 전자 메일이 발송될 수 있다. 전자메일 보내기 작업유형(job type)은 시스템운영부(110)에 의해 관리목적으로 실행되는 특정 운영작업이 실패하는 경우 등에 메일을 발송하도록 설정될 수 있다.The Send Email job type involves the execution of a software model and logic set, and includes tasks for sending emails. For example, a sender, recipient, subject, body, and attachments may be specified as global variables (arguments), and an outgoing mail server (SMTP) may be configured. Here, the global variables may correspond to variables defining options and settings for logic execution. Furthermore, when the configured Send Email is executed, an email may be sent according to preset settings. The Send Email job type may be configured to send an email when a specific operational task executed for management purposes by the system operation unit (110) fails, for example.
프로그램 실행 작업유형(job type)은 소프트웨어 모델 및 로직 세트의 실행과 관련되어 프로그램이나 스크립트를 실행하게 할 수 있다. 예를 들어, 소프트웨어 모델 및 로직 세트의 운영이 실패하는 경우, 이에 대한 검증 스크립트를 실행할 수 있다.The program execution job type can execute programs or scripts related to the execution of software models and logic sets. For example, if the operation of a software model or logic set fails, a verification script can be executed.
모델 실행(model task) 작업유형은 모델개발부(1100)를 통해 개발된 소프트웨어 모델을 실행하기 위한 작업 유형에 해당한다. 모델실행 작업유형은 모델의 구동방식을 설정하기 위한 기본 전역변수를 포함하고 있다. 일 예로서, 이력관리 저장부(1270)에 저장된 소프트웨어 모델의 전역변수는 모델실행 작업유형의 기본 전역변수로 사용될 수 있다.The model execution (model task) task type corresponds to a task type for executing a software model developed through the model development unit (1100). The model execution task type includes basic global variables for setting the model's operation method. For example, the global variables of a software model stored in the history management storage unit (1270) can be used as basic global variables for the model execution task type.
또한, 작업서비스부(1210)는 운영작업에 대한 실행조건(trigger)를 설정할 수 있다. 여기에서, 실행조건(trigger)는 실행주기, 운영작업 간 의존성 등에 해당한다. 즉, 운영작업은 실행을 위한 작업단위를 의미하고, 실행조건은 운영작업의 실행 주기 및 의존성과 같은 세부 조건을 의미할 수 있다. 운영작업에 대하여 적어도 하나이상의 실행조건이 생성될 수 있고, 제1 실행조건에 대하여 적어도 하나 이상의 제2실행조건이 생성되는 것도 가능하다. 설정된 실행조건은 시스템운영부에 저장될 수 있다.Additionally, the operation service unit (1210) can set execution conditions (triggers) for operational tasks. Here, execution conditions (triggers) correspond to execution cycles, dependencies between operational tasks, etc. In other words, an operational task refers to a work unit for execution, and execution conditions may refer to detailed conditions such as the execution cycle and dependencies of the operational task. At least one execution condition may be created for an operational task, and at least one second execution condition may also be created for a first execution condition. The set execution conditions may be stored in the system operation unit.
도 24는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 운영 작업을 실행하는 예를 개시하는 도면이다.FIG. 24 is a diagram disclosing an example of executing an operational task based on a software model and logic set according to an embodiment.
모델실행부(130)는 작업스케쥴러 서비스부(1230)의 실행 지시에 따라 운영작업을 실행할 수 있다.The model execution unit (130) can execute operational tasks according to execution instructions from the task scheduler service unit (1230).
예를 들어, 작업스케쥴러 서비스부(1230)는 운영작업에 대하여 설정된 실행 조건이 만족되었을 때, 모델실행부(130)를 실행하고, 소프트웨어 모델 및 로직 세트를 매개변수로 전달할 수 있다. 이때, 소프트웨어 모델 및 로직 세트는 데이터베이스(150)에서 추출 대상이 되는 데이터의 연결 정보와 데이터 테이블 매핑(mapping) 정보를 포함할 수 있다.For example, when the execution conditions set for an operational task are satisfied, the task scheduler service unit (1230) may execute the model execution unit (130) and pass a software model and logic set as parameters. At this time, the software model and logic set may include connection information for data to be extracted from the database (150) and data table mapping information.
이 경우, 모델실행부(130)는 소프트웨어 모델 및 로직 세트에 기초하여 클라이언트 데이터베이스(150)로부터 실제 입력 데이터를 수신할 수 있다. 즉, 모델실행부(130)는 매개변수에 기초하여 쿼리하여 클라이언트 시스템의 데이터베이스(150)에 포함된 데이터를 가져올 수 있다.In this case, 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 retrieve data contained in the database (150) of the client system by querying based on parameters.
실시 예로서, 모델 실행부(130)는 로직 세트에 따라 모델 실행이 수행되는 경우, 출력파일(1280)로서 아웃풋 파일(1286)을 생성할 수 있다. 일 예로서, 아웃풋 파일(1286)의 형식은 소프트웨어 모델의 설정값(예.작업서비스부(1210)를 통한 작업 생성시 매개변수로 추가)에 따라 결정될 수 있고, 압축파일 형태 등을 포함할 수 있다.As an example, the model execution unit (130) may generate an output file (1286) as an output file (1280) when model execution is performed according to a logic set. As an example, the format of the output file (1286) may be determined according to the settings of the software model (e.g., added as a parameter when creating a task through the task service unit (1210)) and may include a compressed file format, etc.
이때, 아웃풋 파일(1286)은 생산 계획 데이터를 포함할 수 있다. 여기에서, 생산 계획 데이터는 클라이언트의 데이터베이스로부터 수신한 입력 데이터를 개발된 소프트웨어 모델 및 로직 세트에서 실행시켜 도출한 생산 계획에 해당한다. 또한, 운영작업이 실행된 결과에 대한 로그파일(1283)도 함께 생성될 수 있다. 이때, 로그파일(1283)에는 운영작업이 언제 어떻게 실행되었는지, 실행이 실패하였는지, 실행이 성공하였는지 등에 대한 정보를 포함될 수 있다.At this time, the output file (1286) may include production plan data. Here, the production plan data corresponds to a production plan derived by executing input data received from the client's database on the developed software model and logic set. Additionally, a log file (1283) regarding the results of the operational task execution may also be generated. At this time, the log file (1283) may include information regarding when and how the operational task was executed, whether the execution failed, or whether the execution was successful.
한편, 실험허브 작업이 운영작업으로 생성되는 경우, 실험허브 실행기가 추가되어 하나 이상의 모델실행부(130)가 병렬 실행될 수 있다.Meanwhile, when an experimental hub task is created as an operational task, an experimental hub executor is added so that one or more model execution units (130) can be executed in parallel.
생성된 아웃풋 파일(1286) 및 로그파일(1283)은 클라이언트의 제조공정시스템(100)의 데이터베이스(150)에 업로드될 수 있다. 업로드시에 모델 압축 파일(1286) 형태로 업로드하거나 모델 압축 파일(1286)에 포함된 내용물 자체를 압축시키지 않고 업로드하는 것도 가능하다.The generated output file (1286) and log file (1283) can be uploaded to the database (150) of the client's manufacturing process system (100). When uploading, it is also possible to upload in the form of a model compression file (1286) or to upload without compressing the contents contained in the model compression file (1286).
한편, 저장된 아웃풋 파일(1286) 및 로그파일(1283)은 클라이언트의 제조공정시스템(100)에 포함된 조회 인터페이스 또는 외부파일서비스부(1220)를 통해 결과물을 제공하여 모델분석부(1300)에서 조회할 수 있게 된다.Meanwhile, the saved output file (1286) and log file (1283) can be viewed in the model analysis unit (1300) by providing the results through the inquiry interface included in the client's manufacturing process system (100) or the external file service unit (1220).
도 25는 실시 예에 따른 시스템운영부에서 운영 작업을 설정하는 예를 개시한 도면이다.Figure 25 is a drawing showing an example of setting up an operation task in a system operation unit according to an embodiment.
작업서비스부(1210)를 통해 생성된 운영작업은 작업서비스부(1210)를 통해 운영작업에 대한 실행조건(trigger)를 설정할 수 있다. 이는, 개발된 소프트웨어 모델 및 로직 세트의 실행과 관련된 운영작업들이 실행되기 위한 조건을 설정하는 것에 해당한다.Operational tasks created through the Operation Service Unit (1210) can set execution conditions (triggers) for the operational tasks through the Operation Service Unit (1210). This corresponds to setting conditions for the execution of operational tasks related to the execution of the developed software model and logic set.
실행조건서비스부(1225)를 통해 설정된 실행조건은 시스템운영부(110)에 저장될 수 있다.The execution conditions set through the execution condition service unit (1225) can be stored in the system operation unit (110).
또한, 1개의 운영작업에 대하여 적어도 하나의 실행조건이 설정될 수 있다. 예를 들어, 실행조건은 주기조건, 의존성조건 등을 포함할 수 있다. 또한, 복수의 실행조건들 사이에서도 주기조건 또는 의존성 조건이 설정될 수 있다. 예를 들어, 제 1 실행조건에 대하여 적어도 하나의 제 2 실행조건이 설정될 수 있다. 한편, 제 1 실행조건에 대하여 제 2 실행조건이 설정되지 않고, 제 1 실행조건에서 종료되는 것으로 설정되는 것도 가능하다.Additionally, at least one execution condition may be set for a single operation task. For example, the execution condition may include a periodic condition, a dependency condition, etc. Furthermore, a periodic condition or a dependency condition may be set between multiple execution conditions. For example, at least one second execution condition may be set for a first execution condition. Alternatively, the second execution condition may not be set for the first execution condition, and may be set to end at the first execution condition.
또한, 실행조건이 설정되어 있더라도, 실제로 실행조건을 실행할지 여부가 매개변수로 포함되어 있다. 일 예로서, 실행조건 설정뿐만 아니라 실행조건의 활성화/비활성화 여부를 설정하는 절차를 추가로 포함할 수 있다. 예를 들어, 제1 운영작업(510)에 주기 조건(520) 또는 의존성 조건(530)이 설정되어 있더라도, 각각의 실행조건의 활성화/비활성화여부를 먼저 결정한 후에 실행이 이루어지게 할 수 있다.Additionally, even if execution conditions are set, whether or not the execution conditions are actually executed is included as a parameter. For example, in addition to setting execution conditions, a procedure for determining whether to activate or deactivate the execution conditions may be additionally included. For example, even if a periodic condition (520) or a dependency condition (530) is set for the first operation task (510), the activation/deactivation of each execution condition can be determined first before execution.
실시 예에서, 제1 운영작업(510)은 두 개의 주기조건(520)이 설정될 수 있다. 제1 주기조건(521)은 매주 월요일 모델을 운영(operation)해보는 조건에 해당한다. 제2 주기조건(522)는 매주 화요일에 모델을 테스트(test)해보는 조건에 해당할 수 있다. 주기 조건은 이외에도 시스템 또는 사용자에 의해 다양하게 생성될 수 있다.In an embodiment, the first operation task (510) may be configured with two cycle conditions (520). The first cycle condition (521) corresponds to a condition for operating the model every Monday. The second cycle condition (522) may correspond to a condition for testing the model every Tuesday. In addition, cycle conditions may be created in various ways by the system or the user.
또한, 주기조건(520) 중 적어도 일부에 대하여 의존성 조건(530)이 생성될 수 있다. 제1 의존성 조건(531)은 성공 메일을 보내는 조건이고, 제2 의존성 조건(532)는 검증(validation)을 수행하는 조건이고, 제3 의존성 조건(533)은 실패 메일을 보내는 조건에 해당할 수 있다. 의존성 조건은 이외에도 시스템 또는 사용자에 의해 다양하게 생성될 수 있다.Additionally, dependency conditions (530) may be generated for at least some of the periodic conditions (520). The first dependency condition (531) may be a condition for sending a successful email, the second dependency condition (532) may be a condition for performing validation, and the third dependency condition (533) may be a condition for sending a failed email. In addition, various dependency conditions may be generated by the system or the user.
실시 예에서, 제1 주기 조건(521)의 성공/실패에 의존하는 의존성 조건(530)이 설정될 수 있다. 제1 주기 조건(521)의 수행이 성공적인 경우, 제1의존성 조건(531)이 설정될 수 있다. 즉, 매주 월요일에 실제 운영을 해보는 경우, 성공 메일을 보내는 것으로 조건이 설정되고, 이에 따라 실제로 성공 전자메일 보내기 작업(534)이 수행될 수 있다. 성공 전자메일 보내기 작업(534)은 상술한 작업 타입 중 전자메일 보내기에 해당할 수 있다.In an embodiment, a dependency condition (530) that depends on the success/failure of the first cycle condition (521) may be set. If the first cycle condition (521) is successfully performed, the first dependency condition (531) may be set. That is, in the case of actual operation every Monday, the condition is set to send a success email, and accordingly, the task of sending a success email (534) may be actually performed. The task of sending a success email (534) may correspond to sending an email among the task types described above.
또한, 제1 주기 조건(521)의 수행이 실패인 경우, 제2 의존성 조건(532) 및 제3 의존성 조건(533)이 설정될 수 있다. 즉, 매주 월요일에 실제 운영이 이루어지지 않는 경우, 실패한 이유에 대하여 검증이 수행되도록 설정되고, 이에 따라 검증 작업(535)이 수행될 수 있다. 검증 작업(535)은 상술한 작업 타입 중 프로그램 실행에 해당할 수 있다.Additionally, if the execution of the first cycle condition (521) fails, the second dependency condition (532) and the third dependency condition (533) may be set. That is, if actual operation is not performed every Monday, verification is set to be performed for the reason for the failure, and verification work (535) may be performed accordingly. The verification work (535) may correspond to program execution among the above-described work types.
또한, 검증이 이루어지는 경우, 검증의 성공/실패에 대한 별도 조건없이 실패 메일을 보내는 것으로 조건이 설정되고, 이에 따라 실패 전자메일 보내기 작업(536)이 수행될 수 있다. 실패 전자메일 보내기(536)은 상술한 작업 타입 중 전자메일 보내기에 해당할 수 있다.Additionally, when verification is performed, a condition is set to send a failure email without a separate condition for the success/failure of verification, and accordingly, a task of sending a failure email (536) may be performed. The task of sending a failure email (536) may correspond to sending an email among the task types described above.
본 실시 예에서, 제2 주기 조건(522)에는 다른 의존성 조건(530)이 생성되지 않는 것으로 도시되어 있으나, 다른 의존성 실행조건(530)이 생성되는 것으로 설정되는 것도 가능하다. 또한, 제1 운영작업(510)에 도시된 주기조건(520) 및 의존성조건(530) 외에 추가적인 조건이 설정되는 것도 가능하다.In this embodiment, the second cycle condition (522) is illustrated as not generating another dependency condition (530), but it is also possible to set another dependency execution condition (530) to be generated. Furthermore, it is also possible to set additional conditions in addition to the cycle condition (520) and dependency condition (530) illustrated in the first operation task (510).
도 26은 실시 예에 따른 온프레미스 컴퓨팅시스템에서 운영작업을 생성하고 실행하는 예를 개시하는 흐름도이다.FIG. 26 is a flowchart disclosing an example of creating and executing an operational task in an on-premise computing system according to an embodiment.
도시되지 않았으나, 운영작업의 생성이 이루어지기 전에, 라이선스서비스부(1205)를 통해 사용자의 라이선스 적합유무가 점검될 수 있다.Although not shown, before the creation of an operational task, the user's license eligibility can be checked through the License Service Department (1205).
소프트웨어 모델 및 로직 세트를 시스템운영부에 업로드할 수 있다(S500). 시스템운영부는 개발된 소프트웨어 모델 및 로직 세트의 실제 실행과 관련된 운영작업을 생성하고 설정할 수 있다. 상술한 바와 같이, 모델 개발부(1100)에서 획득된 소프트웨어 모델 및 로직 세트는 시스템운영부(110)에 업로드될 수 있다. 또한, 시스템운영부(110)의 배포관리서비스부(1215)는 파일을 저장 시 프로젝트별 경로에 파일을 저장할 수 있다.Software models and logic sets can be uploaded to the system operation unit (S500). The system operation unit can create and configure operational tasks related to the actual execution of the developed software models and logic sets. As described above, the software models and logic sets acquired from the model development unit (1100) can be uploaded to the system operation unit (110). In addition, the distribution management service unit (1215) of the system operation unit (110) can store files in a project-specific path when saving files.
업로드된 소프트웨어 모델 및 로직 세트에 기초하여 적어도 하나의 운영작업을 생성할 수 있다(S505).상술한 바와 같이, 적어도 하나의 운영작업은 소프트웨어 모델 및 로직 세트의 실행에 관련된 전자메일 보내기, 프로그램 실행, 모델 작업 등을 포함할 수 있다. 또한, 운영작업의 종류에 실험허브 실행 등 다양한 작업이 추가될 수 있다.At least one operational task can be created based on the uploaded software model and logic set (S505). As described above, the at least one operational task may include sending an email, executing a program, or performing a model task related to the execution of the software model and logic set. Furthermore, various tasks, such as running an experiment hub, may be added to the operational task types.
다음으로, 생성된 적어도 하나의 운영작업에 대하여 실행 주기 및 작업간 의존성을 설정할 수 있다(S510). 상술한 바와 같이, 1개의 운영작업에 대하여 적어도 하나의 실행조건이 설정될 수 있다. 또한, 다른 종류에 해당하는 복수의 실행조건들이 존재하는 경우, 실행조건들 사이에서도 조건이 설정될 수 있다. 일 예로서, 실행조건 설정뿐만 아니라 실행조건의 활성화/비활성화 여부를 설정하는 절차를 추가로 포함할 수 있다.Next, execution cycles and inter-task dependencies can be set for at least one generated operational task (S510). As described above, at least one execution condition can be set for each operational task. Furthermore, if multiple execution conditions of different types exist, conditions can also be set between the execution conditions. For example, in addition to setting the execution conditions, a procedure for setting whether to enable or disable the execution conditions can be additionally included.
또한, 설정된 실행 주기 및 작업간 의존성에 따라 운영작업을 수행할 수 있다(S515). 예를 들어, 작업스케쥴러 서비스부(1230)의 실행 지시가 있는 경우, 모델실행부(130)는 입력데이터를 기반으로, 운영작업을 실행할 수 있다. 이때, 모델실행부(130)는 이력관리 저장부(1270)에 저장되어 있는 소프트웨어 모델 및 모델 파일을 매개변수로 전달받을 수 있다. 또한, 모델실행부(130)는 매개변수 및 로직(연결정보, 스키마, 매핑정보 등)에 기초하여 클라이언트 데이터베이스(150)로부터 실제 데이터를 추출할 수 있고, 로직 세트에 따라 운영작업을 실행하여, 아웃풋 파일을 생성할 수 있다. 뿐만 아니라, 운영작업의 실행 상황에 대한 로그 파일도 함께 생성될 수 있다.In addition, the operation task can be performed according to the set execution cycle and inter-task dependency (S515). For example, when there is an execution instruction from the task scheduler service unit (1230), the model execution unit (130) can execute the operation task based on the input data. At this time, the model execution unit (130) can receive the software model and model file stored in the history management storage unit (1270) as parameters. In addition, the model execution unit (130) can extract actual data from the client database (150) based on the parameters and logic (connection information, schema, mapping information, etc.), and execute the operation task according to the logic set to generate an output file. In addition, a log file regarding the execution status of the operation task can also be generated.
수행된 운영작업의 결과물을 데이터베이스에 업로드할 수 있다(S520). 예를 들어, 생성된 아웃풋 파일 및 로그 파일은 클라이언트의 제조공정시스템의 데이터베이스(150)에 업로드될 수 있다. 또한, 예를 들어, 운영작업의 결과물은 생산 계획, 운영 시스템 로그 등을 포함할 수 있다.The results of the performed operational tasks can be uploaded to a database (S520). For example, generated output files and log files can be uploaded to the database (150) of the client's manufacturing process system. Furthermore, for example, the results of the operational tasks can include production plans, operational system logs, etc.
도시되지 않았으나, 업로드된 결과물은 모델분석부 또는 조회 인터페이스에서 결과물을 조회할 수 있다. 예를 들어, 아웃풋 파일 및 로그파일은 클라이언트의 제조공정시스템에 포함된 조회인터페이스 또는 외부파일서비스부(1220)를 통해 모델분석부(1300)에서 조회할 수 있다.Although not shown, uploaded results can be viewed in the model analysis unit or the query interface. For example, output files and log files can be viewed in the model analysis unit (1300) via the query interface included in the client's manufacturing process system or the external file service unit (1220).
도 27은 실시 예에 따른 클라우드 컴퓨팅시스템에서 운영작업을 생성하고 수행하는 예를 개시하는 흐름도이다.Figure 27 is a flowchart disclosing an example of creating and performing an operational task in a cloud computing system according to an embodiment.
상술한 온프레미스 컴퓨팅시스템과는 달리, 클라우드 컴퓨팅시스템에서는 적어도 하나의 운영작업이 이미 생성된 상태에 해당하여, 작업운영부에 소프트웨어 모델 파일 및 로직 세트 파일을 업로드하거나, 운영작업을 생성하는 절차가 생략될 수 있다.Unlike the on-premise computing system described above, in a cloud computing system, at least one operational task has already been created, so the process of uploading a software model file and a logic set file to the task operation unit or creating an operational task can be omitted.
클라이언트 제조생산시스템(100)은 데이터베이스(150)에 저장된 입력데이터의 스키마를 변환하는 인바운드 로직을 실행하고 변환된 입력데이터를 클라우드 데이터베이스(2500)에 업로드할 수 있다. 또한, 클라이언트 제조생산시스템(100)의 인바운드 로직의 실행에 따라 클라이언트의 기준 정보 데이터를 포함하는 입력데이터가 클라우드 데이터베이스(2500)에 저장될 수 있다.The client manufacturing production system (100) can execute inbound logic that converts the schema of input data stored in the database (150) and upload the converted input data to the cloud database (2500). In addition, according to the execution of the inbound logic of the client manufacturing production system (100), input data including the client's reference information data can be stored in the cloud database (2500).
클라우드 컴퓨팅 시스템의 운영관리부(2100)는 온프레미스 컴퓨팅시스템의 시스템운영부(110)와 동일한 역할을 수행할 수 있고, 구성요소가 동일하게 포함되어 있을 수 있다.The operation management unit (2100) of the cloud computing system can perform the same role as the system operation unit (110) of the on-premise computing system and can include the same components.
먼저, 적어도 하나의 운영작업에 대응하는 모델 설정값이 편집될 수 있다(S525). 실시 예로서, 클라우드 컴퓨팅시스템에서 적어도 하나의 운영작업에 관련된 적어도 하나의 매개변수가 설정될 수 있으며, 예를 들어, 포워드플래닝에서 투입 의사결정 에이전트 사용여부, 투입 의사결정 에이전트를 사용할 때 가중합 방식 또는 가중치정렬 방식의 사용여부 등을 포함할 수 있다. 상술한 바와 같이, 클라우드 컴퓨팅시스템(2000)의 운영관리부(2100)를 통해 모델 설정값이 편집될 수 있다.First, model settings corresponding to at least one operational task can be edited (S525). As an example, at least one parameter related to at least one operational task in a cloud computing system can be set, including, for example, whether to use an input decision agent in forward planning, and whether to use a weighted sum method or a weighted sort method when using the input decision agent. As described above, model settings can be edited through the operation management unit (2100) of the cloud computing system (2000).
다음으로, 적어도 하나의 운영작업의 실행주기 및 작업 간 의존성을 설정할 수 있다(S530). 상술한 바와 같이, 운영 관리부(2100)에서 실행주기 및 작업 간 의존성일 설정할 수 있다. 이와 관련하여, 온프레미스 컴퓨팅 시스템의 S510 단계를 참조하도록 한다.Next, the execution cycle and inter-task dependencies of at least one operational task can be set (S530). As described above, the operational management unit (2100) can set the execution cycle and inter-task dependencies. In this regard, refer to step S510 of the on-premise computing system.
또한, 설정된 실행 주기 및 작업간 의존성에 따라 운영작업을 수행할 수 있다(S535). 예를 들어, 클라우드 컴퓨팅시스템(2000)의 모델 실행기(2400)는 운영관리부(2100)의 작업스케쥴러 서비스부의 실행지시가 있는 경우, 입력데이터에 기초하여, 운영작업을 실행할 수 있다. 이와 관련하여, 온프레미스 컴퓨팅 시스템의 S515 단계를 참조하도록 한다.Additionally, operational tasks can be performed based on the set execution cycle and inter-task dependencies (S535). For example, the model executor (2400) of the cloud computing system (2000) can execute operational tasks based on input data when there is an execution instruction from the task scheduler service unit of the operations management unit (2100). In this regard, reference is made to step S515 of the on-premise computing system.
수행된 운영작업의 결과물을 데이터베이스에 업로드할 수 있다(S540). 예를 들어, 생성된 아웃풋 파일 및 로그 파일은 클라우드 컴퓨팅시스템의 클라우드 데이터베이스(2500)에 업로드될 수 있다.The results of the performed operational tasks can be uploaded to a database (S540). For example, the generated output files and log files can be uploaded to a cloud database (2500) of a cloud computing system.
또한, 클라우드 데이터베이스(2500)에 저장된 아웃풋 파일 및 로그 파일은 사용자 인터페이스로 제공하는 아웃바운드 API(2710)를 통해 클라이언트 시스템에서 조회될 수 있다.Additionally, output files and log files stored in the cloud database (2500) can be retrieved from a client system through an outbound API (2710) provided as a user interface.
도 28은 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법을 개시하는 흐름도이다.FIG. 28 is a flowchart disclosing a method for providing digital production planning information according to an embodiment.
클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나를 기반으로 생성된 소프트웨어 모델 및 로직 세트를 온프레미스 컴퓨팅 시스템으로부터 수신할 수 있다(S550).A software model and logic set generated based on at least one of the data schema and library engine sets of the client manufacturing production system can be received from the on-premise computing system (S550).
도 23 내지 25에서 상술한 바와 같이, 모델개발부에서 생성된 소프트웨어 모델 및 로직 세트는 서버관리부를 통해 시스템운영부에 업로드될 수 있다.As described above in Figures 23 to 25, the software model and logic set created in the model development department can be uploaded to the system operation department through the server management department.
업로드된 소프트웨어 모델 및 로직 세트에 기초하여 적어도 하나의 운영작업을 생성할 수 있다(S560).At least one operational task can be created based on the uploaded software model and logic set (S560).
시스템운영부는 적어도 하나의 운영작업을 생성하고, 운영작업에 대한 실행조건을 설정할 수 있다. 운영작업은 전자메일 보내기, 프로그램 실행, 모델 실행 등을 포함할 수 있다. 또한, 실행조건은 주기 조건, 의존성 조건 등을 포함할 수 있다.The system operation unit can create at least one operational task and set execution conditions for the task. Operational tasks can include sending emails, executing programs, and executing models. Execution conditions can also include cycle conditions and dependency conditions.
클라우드 컴퓨팅시스템의 경우, 본 단계가 생략될 수 있고 대신 운영 작업에 대응하는 모델 설정값 및 기 설정된 운영 작업, 실행 조건의 매개변수가 편집될 수 있다.In the case of cloud computing systems, this step may be omitted, and instead, model settings corresponding to the operational tasks and parameters of the preset operational tasks and execution conditions may be edited.
도 23 내지 도 27에서 상술한 바와 같이, 시스템 운영부는 서버관리부를 통해 전달된 소프트웨어 모델 및 로직 세트에 기반하여 모델실행부를 실행시킬 수 있다.As described above in FIGS. 23 to 27, the system operation unit can execute the model execution unit based on the software model and logic set transmitted through the server management unit.
생성된 적어도 하나의 운영작업에 따라, 입력데이터를 기반으로 상기 소프트웨어모델 및 로직 세트를 수행하여 생산 계획 정보를 제공할 수 있다(S580)Based on at least one generated operational task, the software model and logic set can be performed based on input data to provide production planning information (S580).
도 23 내지 도 27에서 상술한 바와 같이, 모델실행부는 입력데이터를 기반으로 소프트웨어 모델 및 로직 세트를 수행하여 생산계획 정보, 운영 시스템 로그 등을 포함하는 결과물을 생성하여, 클라이언트 시스템의 데이터베이스에 업로드할 수 있다.As described above in FIGS. 23 to 27, the model execution unit executes a software model and logic set based on input data to generate results including production plan information, operating system logs, etc., and can upload them to the database of the client system.
도 29는 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 개시한 도면이다.FIG. 29 is a drawing disclosing one embodiment of a device that provides digital production planning information.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(410), 저장장치(420), 인메모리(430), 프로세서(440), 출력부(450), 및 사용자인터페이스(460)를 포함할 수 있다. 예를 들어, 디지털 생산 계획 정보를 제공하는 장치는 클라이언트의 제조생산시스템에 해당할 수 있다.An embodiment of a device providing digital production plan information may include an input unit (410), a storage unit (420), an in-memory unit (430), a processor (440), an output unit (450), and a user interface (460). For example, the device providing digital production plan information may correspond to a client's manufacturing production system.
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(450)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (450).
입력부(410)는 클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나를 기반으로 생성된 소프트웨어 모델 및 로직 세트를 온프레미스 컴퓨팅 시스템으로부터 수신할 수 있다.The input unit (410) can receive a software model and logic set generated based on at least one of the data schema and library engine set of the client manufacturing production system from the on-premise computing system.
저장장치(420)는 미리 준비된 기준정보를 저장하거나 수신된 소프트웨어 모델 및 로직 세트를 저장할 수 있다. 저장장치(420)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다.The storage device (420) can store pre-prepared reference information or store received software models and logic sets. The storage device (420) can include volatile memory or non-volatile memory.
인메모리(430)는 위에서 개시한 라이브러리 엔진 세트를 저장할 수 있다.In-memory (430) can store the set of library engines disclosed above.
실시예의 프로세서(440)는 사용자의 요청에 따라 상기 소프트웨어 모델 및 상기 로직 세트에 기초하여 적어도 하나의 운영작업을 생성할 수 있다. 또한, 프로세서(440)는 적어도 하나의 운영작업의 실행 주기 및 작업 간 의존성을 설정할 수 있으며, 상세한 예시는 도 23 내지 도 28에 개시하였다. 그리고 실시예의 프로세서(440)는 사용자 인터페이스(460)의 사용자의 요청에 따라 상기 수신된 소프트웨어 모델 및 로직 세트를 실행하여 생산 계획 데이터를 얻을 수 있다.The processor (440) of the embodiment can generate at least one operational task based on the software model and the logic set at the user's request. Furthermore, the processor (440) can set the execution cycle and inter-task dependencies of the at least one operational task, detailed examples of which are disclosed in FIGS. 23 to 28. Furthermore, the processor (440) of the embodiment can execute the received software model and logic set at the user's request via the user interface (460) to obtain production planning data.
실시 예의 프로세서(440)는 로직 세트에 따라 입력데이터에 기반하여, 운영작업을 실행하고, 아웃풋 파일 및 운영작업의 실행 상황에 대한 로그 파일을 생성할 수 있다.The processor (440) of the embodiment can execute an operation task based on input data according to a logic set, and generate an output file and a log file on the execution status of the operation task.
출력부(450)는 소프트웨어 모델 및 로직 세트의 실행 결과에 따른 생산 계획 데이터를 제공하여 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (450) can provide production plan data based on the execution results of the software model and logic set to enable the client system to manage production or processes.
본 실시 예를 통하여, 다양한 세밀도의 생산계획을 요구하는 제조생산시스템에서 일련의 과정을 자동으로 수행할 수 있게 된다.Through this embodiment, a series of processes can be automatically performed in a manufacturing production system that requires production plans of various levels of detail.
도 30은 실시 예에 따른 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하는 예를 개시하는 도면FIG. 30 is a diagram disclosing an example of analyzing a production plan based on a software model and logic set according to an embodiment.
도시한 예에서 온프레미스 컴퓨팅 시스템(1000)의 모델분석부(1300)는 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석할 수 있는 프레임을 제공한다.In the illustrated example, the model analysis unit (1300) of the on-premise computing system (1000) provides a frame that can analyze production plans based on software models and logic sets.
일 실시 예에서, 모델분석부(1300)는 모델 획득부(601), 모델 실행부(602) 및 결과 분석부(603)를 포함할 수 있다.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).
모델 획득부(601)는 클라이언트 제조생산시스템에 대한 소프트웨어모델 및 로직 세트를 획득할 수 있다. 일 실시 예에서, 모델 획득부(601)는 운영 서버 또는 서버 관리부로부터 생산 계획 산출 후 입력 데이터 및 출력 데이터를 포함하는 소프트웨어모델 및 로직 세트를 획득할 수 있다.The model acquisition unit (601) can acquire a software model and logic set for a client manufacturing production system. In one embodiment, the model acquisition unit (601) can acquire a software model and logic set including input data and output data after generating a production plan from an operating server or server management unit.
일 실시예에서, 모델 획득부(601)는 모델분석부(1300)의 소프트웨어 자동 업데이트 정보, 로그 파일 저장 정보, 운영 서버 또는 서버 관리부에 대한 연결 정보 및 모델 다운로드 서비스 경로 정보 중 적어도 하나를 포함하는 모델분석부 구성 정보(예: exe.config)에 기반하여 소프트웨어모델 및 로직 세트를 획득할 수 있다.In one embodiment, the model acquisition unit (601) can acquire a software model and logic set based on model analysis unit configuration information (e.g., exe.config) including at least one of software automatic update information of the model analysis unit (1300), log file storage information, connection information for an operating server or server management unit, and model download service path information.
일 실시 예에서, 모델 획득부(601)는 미리 저장된 모델 정보 파일(예: xxx.vinfo)에 기반하여 소프트웨어모델(예: xxx.vmodel)을 획득할 수 있다. 이 경우, 모델 정보 파일은 시뮬레이션 로직 파일(Dll)의 어셈블리(assembly) 정보, 시뮬레이션 로직 파일의 구성 파일 경로, 사용자 인터페이스(user interface, UI) 로직 파일의 어셈블리 정보 및 사용자 인터페이스 로직 파일의 구성 파일 경로 중 적어도 하나를 포함할 수 있다. 일 실시 예에서, 모델 정보 파일은 소프트웨어 모델과 별개의 파일로 구성되거나, 소프트웨어 모델에 포함되어 하나의 파일로 구성될 수 있다.In one embodiment, the model acquisition unit (601) may acquire a 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 assembly information of a simulation logic file (Dll), a configuration file path of a simulation logic file, assembly information of a user interface (UI) logic file, and a configuration file path of a user interface logic file. In one embodiment, the model information file may be configured as a separate file from the software model, or may be configured as a single file included in the software model.
일 실시 예에서, 모델 획득부(601)는 모델 개발부에 의해 생성된 소프트웨어모델 및 로직 세트를 획득할 수 있다. 이 경우, 소프트웨어모델 및 로직은 생산 계획 산출 전 입력 데이터를 포함할 수 있다.In one embodiment, the model acquisition unit (601) may acquire a software model and logic set generated by the model development unit. In this case, the software model and logic may include input data prior to production plan output.
모델 실행부(602)는 소프트웨어모델 및 로직 세트에 기반하여 생산 계획 관련 데이터를 산출할 수 있다. 일 실시 예에서, 생산 계획 관련 데이터는 모델 정보, 실험 계획 정보 및 실험 결과 정보 중 적어도 하나를 포함할 수 있다. 이에 대한 자세한 내용은 아래에서 설명된다.The model execution unit (602) can generate production plan-related data based on a software model and logic set. In one embodiment, the production plan-related data may include at least one of model information, experimental plan information, and experimental result information. This is described in detail below.
일 실시 예에서, 모델 실행부(602)는 시뮬레이션 로직 파일의 구성 파일(예: Sim.config)에 기반하여 소프트웨어 모델에 대한 로직 세트를 실행할 수 있다. 여기서, 시뮬레이션 로직 파일의 구성 파일은 실험 수행에 따른 시뮬레이션 로그를 기록하는 폴더 및 해당 로그 파일의 포맷 및 시뮬레이션에서 사용되는 메모리 캐싱 설정 중 적어도 하나를 나타낼 수 있다.In one embodiment, the model execution unit (602) may execute a set of logic for a software model based on a configuration file (e.g., Sim.config) of a simulation logic file. Here, the configuration file of the simulation logic file may indicate at least one of a folder for recording simulation logs according to experiment execution, a format of the corresponding log file, and a memory caching setting used in the simulation.
결과 분석부(603)는 생산 계획 관련 데이터를 제공할 수 있다. 일 실시 예에서, 결과 분석부(603)는 사용자 인터페이스를 통한 다양한 화면을 통해 생산 계획 관련 데이터를 제공할 수 있다. 이에 대한 상세한 내용은 아래에서 설명된다.The result analysis unit (603) can provide data related to production planning. In one embodiment, the result analysis unit (603) can provide data related to production planning through various screens via a user interface. Details thereof are described below.
일 실시 예에서, 일 실시 예에서, 결과 분석부(603)는 사용자 인터페이스 로직 파일의 구성 파일(예: App_GeneralUI.config)에 기반하는 분석 사용자 인터페이스를 통해 분석 결과인 생산 계획 관련 데이터를 제공할 수 있다. 여기서, 사용자 인터페이스 로직 파일의 구성 파일은 분석 사용자 인터페이스의 메뉴 구성 정보, 메뉴와 실행파일의 어셈블리 연결 정보 및 입출력 데이터의 화면 설정 정보 중 적어도 하나를 나타낼 수 있다.In one embodiment, the result analysis unit (603) may provide data related to a production plan, which is an analysis result, through an analysis user interface based on a configuration file (e.g., App_GeneralUI.config) of a user interface logic file. Here, the configuration file of the user interface logic file may indicate at least one of menu configuration information of the analysis user interface, assembly connection information of the menu and the executable file, and screen setting information of input/output data.
도 31은 실시 예에 따른 데이터 조회 화면의 예를 개시하는 도면Figure 31 is a drawing disclosing an example of a data inquiry screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 분석부(1300)의 사용자 인터페이스를 통해 데이터 조회 화면(604)이 제공될 수 있다. 여기서, 데이터 조회 화면(604)은 클라이언트 제조생산시스템의 생산 계획 관련 데이터를 표시할 수 있다. 예를 들어, 생산 계획 관련 데이터는 클라이언트 제조생산시스템의 생산 계획에 대한 입력 데이터 및 출력 데이터 중 적어도 하나를 포함할 수 있다.In the illustrated example, a data inquiry screen (604) may be provided through the user interface of the model analysis unit (1300) according to the present disclosure. Here, the data inquiry screen (604) may display data related to the production plan of the client manufacturing and production system. For example, the production plan-related data may include at least one of input data and output data for the production plan of the client manufacturing and production system.
일 실시 예에서, 생산 계획 관련 데이터에 포함된 입력 데이터 및 출력 데이터의 데이터 아이템(즉, 필드)은 데이터 조회 화면(604)에서 그리드(grid) 형태로 표시될 수 있다. 이 경우, 그리드는 행(row)과 열(column)의 격자 형태로 구성될 수 있다. 예를 들어, 그리드의 열은 장비 ID(EQP_ID), 로트 ID(LOT_ID), 제품 ID(PRODUCT_ID) 및 작업 ID(PROCESS_ID)를 포함할 수 있으며, 이에 제한되지 않고 다양한 항목들이 포함될 수 있다.In one embodiment, data items (i.e., fields) of input data and output data included in production plan-related data may be displayed in a grid format on a data query screen (604). In this case, the grid may be configured in a grid format of rows and columns. For example, the columns of the grid may include equipment ID (EQP_ID), lot ID (LOT_ID), product ID (PRODUCT_ID), and job ID (PROCESS_ID), but are not limited thereto and may include various other items.
일 실시 예에서, 데이터 조회 화면(604)에 대한 사용자 입력에 따라 그리드에 포함된 데이터에 대한 데이터 검색, 데이터 복사, 데이터 필터링, 데이터 정렬 및 그룹핑 기능이 수행될 수 있다. 예를 들어, 열에 대한 드래그(drag) 입력을 통해 해당 드래그 영역을 그룹핑하고, 그룹핑된 열에 대한 그룹핑 요약 편집기(group summary editor)를 통해 그룹핑된 열에 대한 표시 설정이 수행될 수 있다. 일 실시 예에서, 표시 설정은 해당 그룹에 대한 설정 요약 값을 나타낼 수 있다. 예를 들어, 표시 설정은 해당 그룹에 해당하는 행의 수, 그룹핑된 열 이외의 숫자 열에 대한 평균, 최대, 최소 및 합 중 적어도 하나를 포함할 수 있다.In one embodiment, data search, data copy, data filtering, data sorting, and grouping functions may be performed on data included in a grid based on user input on the data query screen (604). For example, drag input for a column may group the corresponding drag area, and display settings for the grouped columns may be performed through a group summary editor for the grouped columns. In one embodiment, the display settings may indicate a set summary value for the group. For example, the display settings may include at least one of the number of rows corresponding to the group, and the average, maximum, minimum, and sum for numeric columns other than the grouped columns.
또한, 일 실시 예에서, 데이터 조회 화면(604)에서 특정 열에 대한 사용자 입력에 따라 그리드 내에서 해당 열의 위치를 변경할 수 있다. 예를 들어, 작업 ID 열에 대한 클릭 앤 드래그 입력으로 작업 ID 열(PROCESS_ID)의 위치를 제품 ID(PRODUCT_ID)의 우측에서 좌측으로 이동시킬 수 있다. 따라서, 본 개시에 따르면, 해당 열의 위치를 변경함으로써 열 간의 상관성을 관측하는데 가시성을 높일 수 있다. 즉, 열의 수가 많을 경우 데이터 조회 화면(604)을 초과하는 데이터가 발생하는 경우 열의 위치를 변경함으로써 사용자에게 데이터 분석 편의성을 제공할 수 있다.Additionally, in one embodiment, the position of a column within the grid can be changed based on user input for a specific column in the data query screen (604). For example, a click-and-drag input for the task ID column can move the position of the task ID column (PROCESS_ID) from the right to the left of the product ID (PRODUCT_ID). Therefore, according to the present disclosure, by changing the position of the column, the visibility for observing the correlation between columns can be improved. That is, when the number of columns is large and data exceeding the data query screen (604) occurs, the position of the column can be changed to provide the user with convenience in data analysis.
일 실시 예에서, 그리드 형태의 여러 데이터 테이블을 결합(join)하여 해당 데이터가 조회될 수 있다. 일 실시 예에서, 해당 소프트웨어 모델에 다양한 형태의 데이터를 불러오거나(import), 내보낼 수 있다(export). 예를 들어, 액셀(excel) 파일이나 텍스트(text) 파일 형태의 데이터를 불러오거나, 데이터를 엑셀 파일, 텍스트 파일, HTML, XML, Rtf, Pdf, MHT 파일 형태로 추출할 수 있다.In one embodiment, multiple data tables in a grid format can be joined to retrieve the corresponding data. In one embodiment, various types of data can be imported or exported into the software model. For example, data can be imported in the form of an Excel file or text file, or extracted in the form of an Excel file, text file, HTML, XML, RTF, PDF, or MHT file.
도 32는 실시 예에 따른 피벗 그리드 조회 화면의 예를 개시하는 도면Figure 32 is a drawing disclosing an example of a pivot grid query screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 분석부(1300)의 사용자 인터페이스를 통해 피벗 그리드 조회 화면(605)이 제공될 수 있다. 여기서, 피벗 그리드 조회 화면(605)은 클라이언트 제조생산시스템의 생산 계획 관련 데이터를 피벗 그리드(pivot grid) 형태로 표시할 수 있다.In the illustrated example, a pivot grid query screen (605) may be provided through the user interface of the model analysis unit (1300) according to the present disclosure. Here, the pivot grid query screen (605) may display data related to the production plan of the client manufacturing production system in the form of a pivot grid.
일 실시 예에서, 피벗 그리드 조회 화면(605)를 통해 필터 영역(filter area), 열 영역(column area), 행 영역(row area) 및 데이터 영역(data area)을 설정하여 분석이 필요한 데이터 아이템에 대한 데이터 값을 선택적으로 확인할 수 있다.In one embodiment, a filter area, a column area, a row area, and a data area can be set through the pivot grid query screen (605) to selectively check data values for data items requiring analysis.
예를 들어, 열 영역을 생산 계획 일자(PLAN_DATE), 행 영역을 공정 ID(STEP_ID) 및 데이터 영역을 생산 수량(OUT_QTY)으로 설정한 경우, 생산 계획 일자별 공정별 생산량을 수치로 확인할 수 있다.For example, if the column area is set to the production plan date (PLAN_DATE), the row area is set to the process ID (STEP_ID), and the data area is set to the production quantity (OUT_QTY), you can check the production quantity by process for each production plan date in numerical form.
일 실시 예에서, 데이터 분석 차트 화면(606)이 제공될 수 있다. 여기서, 데이터 분석 차트 화면(606)은 피벗 그리드로 만든 데이터를 차트 형태로 표시할 수 있다. 예를 들어, 차트 형태는 라인 차트(line chart), 바 차트(bar chart), 포인트 차트(point chart) 및 영역 차트(area chart)를 포함할 수 있으나, 이에 제한되지 않고 다양한 형태의 차트가 사용될 수 있다.In one embodiment, a data analysis chart screen (606) may be provided. Here, the data analysis chart screen (606) may display data created using a pivot grid in the form of a chart. For example, the chart types may include, but are not limited to, a line chart, a bar chart, a point chart, and an area chart, and various types of charts may be used.
도 33은 실시 예에 따른 데이터 편집 화면의 예를 개시하는 도면Figure 33 is a drawing disclosing an example of a data editing screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 분석부(1300)의 사용자 인터페이스를 통해 데이터 편집 화면(607)이 제공될 수 있다. 여기에서, 데이터 편집 화면(607)을 통해 생산 계획 관련 데이터의 편집이 수행될 수 있다.In the illustrated example, a data editing screen (607) may be provided through the user interface of the model analysis unit (1300) according to the present disclosure. Here, editing of production plan-related data may be performed through the data editing screen (607).
일 실시 예에서, 사용자 입력에 의해 데이터 편집 화면(607)에 그리드 형태로 표시된 생산 계획 관련 데이터의 각 데이터 아이템이 편집될 수 있다. 일 실시 예에서, 데이터 편집 화면(607)에서 필터링을 수행하고, 필터링된 데이터에 대한 일괄 수정이 수행될 수 있다. 예를 들어, 필터링된 데이터의 적어도 하나의 열(column)을 선택하고 값을 입력하는 경우, 해당 열의 데이터 아이템이 해당 값으로 일괄 수정될 수 있다.In one embodiment, each data item of production plan-related data displayed in a grid format on a data editing screen (607) can be edited by user input. In one embodiment, filtering can be performed on the data editing screen (607), and batch modifications can be performed on the filtered data. For example, if at least one column of the filtered data is selected and a value is entered, the data items in the corresponding column can be batch modified to the corresponding value.
예를 들어, LINE_ID 열을 선택하고 해당 열의 값(value)을 LINE01로 입력하는 경우, LINE_ID 열의 각 열의 값이 LINE01로 일괄 수정될 수 있다. 또한, 다른 예를 들어, EQP 테이블의 LINE_ID는 LINE01로 필터링되고, STATUS는 UP으로 일괄 수정될 수 있다.For example, if you select the LINE_ID column and enter LINE01 as the value of that column, the values of each column in the LINE_ID column can be batch-modified to LINE01. In addition, as another example, the LINE_ID in the EQP table can be filtered to LINE01, and the STATUS can be batch-modified to UP.
도 34는 실시 예에 따른 실험 설정 및 실행 화면의 예를 개시하는 도면Figure 34 is a drawing disclosing an example of an experimental setup and execution screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 분석부(1300)의 사용자 인터페이스를 통해 실험 설정 및 실행 화면(608)이 제공될 수 있다. 여기에서, 실험 설정 및 실행 화면(608)은 실험 계획 정보 및 실험 실행에 따른 실험 결과 정보 중 적어도 하나를 포함할 수 있다.In the illustrated example, an experiment setup and execution screen (608) may be provided through the user interface of the model analysis unit (1300) according to the present disclosure. Here, the experiment setup and execution screen (608) may include at least one of experiment plan information and experiment result information according to experiment execution.
일 실시 예에서, 적어도 하나의 시나리오를 포함하는 실험을 생성하고, 해당 실험에 대한 실험 계획 정보를 설정할 수 있다. 일 실시 예에서, 실험 계획 정보는 실험에 포함된 적어도 하나의 시나리오 중 실험 설정 및 실행 화면(608)을 통해 조회 가능한 입력 데이터 테이블에 해당하는 하나의 시나리오에 대한 실험 계획을 나타낼 수 있다. 이 경우, 실험 계획은 해당 하나의 시나리오에 대응하여 하나씩 존재하며, 실험이 실행됨에 따라 시나리오에 대한 실험 결과가 실험에 하나씩 추가될 수 있다. 일 실시 예에서, 실험 계획 정보는 전역변수 설정 정보, 입력 데이터, 입력 설정 정보 및 출력 설정 정보 중 적어도 하나를 포함할 수 있다.In one embodiment, an experiment including at least one scenario may be created, and experiment plan information for the experiment may be set. In one embodiment, the experiment plan information may indicate an experiment plan for one scenario corresponding to an input data table viewable through the experiment setup and execution screen (608) among at least one scenario included in the experiment. In this case, one experiment plan exists corresponding to each scenario, and as the experiment is executed, experiment results for the scenarios may be added to the experiment one by one. In one embodiment, the experiment plan information may include at least one of global variable setting information, input data, input setting information, and output setting information.
일 실시 예에서, 전역변수 설정 정보는 소프트웨어 모델의 버전, 실험 시작 시간, 백워드 플래닝 엔진, 포워드 플래닝 엔진, 디버그 및 작업 변경 에이전트 등의 매개변수 중 적어도 하나에 대한 전역변수를 포함할 수 있다. 또한, 출력 설정 정보는 실험을 수행함에 따라 생성되는 결과물에 대한 저장 방식을 나타낼 수 있다.In one embodiment, the global variable configuration information may include global variables for at least one of the following parameters: a software model version, an experiment start time, a backward planning engine, a forward planning engine, a debugger, and a task change agent. Additionally, the output configuration information may indicate a storage method for the results generated during the experiment.
일 실시 예에서, 입력 설정 정보는 입력 데이터 스키마에 따른 데이터 수집 순서를 나타낼 수 있다. 예를 들어, 입력 설정 정보는 입력 퍼시스트 구성(input persist configuration) 정보 중 데이터 수집 순서 편집 기능을 포함할 수 있다.In one embodiment, the input configuration information may indicate a data collection order according to an input data schema. For example, the input configuration information may include a data collection order editing function among input persist configuration information.
일 실시 예에서, 설정된 실험 계획 정보에 기반하여 로컬(local) 환경에서 실험을 실행하여 실험 결과 정보를 생성할 수 있다. 일 실시 예에서, 생성된 실험 결과 정보는 출력 저장 옵션에 따라 저장될 수 있다. 일 실시 예에서, 전역변수 설정 정보는 현재 획득된 소프트웨어 모델에 기반하여 이전에 수행한 실험의 결과 또는 다른 버전의 소프트웨어 모델에 대응하는 전역변수 설정 정보를 포함할 수 있다.In one embodiment, experiments can be performed locally based on established experimental plan information to generate experimental result information. In one embodiment, the generated experimental result information can be stored according to output storage options. In one embodiment, the global variable setting information can include the results of previously performed experiments based on the currently acquired software model or global variable setting information corresponding to other versions of the software model.
도 35는 실시 예에 따른 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하는 예를 개시하는 흐름도Figure 35 is a flowchart disclosing an example of analyzing a production plan based on a software model and logic set according to an embodiment.
클라이언트 제조생산시스템에 대한 소프트웨어모델 및 로직 세트를 획득한다(S611). 일 실시 예에서, 클라이언트 제조생산시스템의 생산 계획에 대한 입력 데이터 및 출력 데이터 중 적어도 하나를 포함하는 상기 소프트웨어모델 및 로직 세트를 획득할 수 있다. 이에 대하여는 상술한 내용을 참고하도록 한다.A software model and logic set for a client manufacturing system are acquired (S611). In one embodiment, the software model and logic set including at least one of input data and output data for a production plan of the client manufacturing system can be acquired. For more information, please refer to the above description.
소프트웨어모델 및 로직 세트에 기반하여 모델 정보, 실험 계획 정보 및 실험 결과 정보 중 적어도 하나를 포함하는 생산 계획 관련 데이터를 산출한다(S612). 일 실시 예에서, 모델 정보는, 상기 소프트웨어모델에 대한 데이터 스키마, 입력 데이터에 대한 데이터 소스(data source), 상기 데이터 스키마에 대한 쿼리(query) 및 전역 변수(argument) 중 적어도 하나를 포함할 수 있다.Based on a software model and logic set, production plan-related data including at least one of model information, experimental plan information, and experimental result information is generated (S612). In one embodiment, the model information may include at least one of a data schema for the software model, a data source for input data, a query for the data schema, and a global variable (argument).
일 실시 예에서, 실험 계획 정보는, 상기 소프트웨어모델 및 로직 세트에 기반하여 실험(experiment)을 수행하기 전 입력 데이터 및 출력 데이터에 대한 실험 설정 정보 및 실험 전역 변수 중 적어도 하나를 포함할 수 있다.In one embodiment, the experimental plan information may include at least one of experimental setup information for input data and output data and experimental global variables before performing an experiment based on the software model and logic set.
일 실시 예에서, 실험 결과 정보는, 상기 소프트웨어모델 및 로직 세트를 이용하여 상기 실험 계획 정보에 기반하는 실험(experiment)을 수행함에 따른 입력 데이터 및 출력 데이터를 포함할 수 있다. 이에 대하여는 도 30 내지 34에서 상술한 내용을 참고하도록 한다.In one embodiment, the experimental result information may include input data and output data resulting from performing an experiment based on the experimental plan information using the software model and logic set. For details, please refer to the contents described above in FIGS. 30 to 34.
생산 계획 관련 데이터를 제공한다(S613). 일 실시 예에서, 생산 계획 관련 데이터는 소프트웨어 모델의 입력 데이터를 변경함에 따라 설정된 적어도 하나의 시나리오를 포함하는 실험을 수행하여 생성된 결과물을 포함할 수 있다. 이에 대하여는 도 30 내지 34에서 상술한 내용을 참고하도록 한다.Production plan-related data is provided (S613). In one embodiment, the production plan-related data may include results generated by performing an experiment that includes at least one scenario set by changing the input data of the software model. For details, please refer to the details described above in FIGS. 30 to 34.
도 8을 참조하여 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하여 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 설명하면 다음과 같다.Referring to FIG. 8, an embodiment of a device for analyzing a production plan based on a software model and logic set and providing digital production plan information is described as follows.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(310), 저장장치(320), 인메모리(330), 프로세서(340), 출력부(350), 및 사용자인터페이스(360)를 포함할 수 있다.One embodiment of a device providing digital production planning information may include an input unit (310), a storage unit (320), an in-memory unit (330), a processor (340), an output unit (350), and a user interface (360).
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(360)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (360).
입력부(310)는 클라이언트 제조생산시스템에 대한 소프트웨어모델 및 로직 세트를 획득할 수 있다. 저장장치(320)는 입력부(310)가 수신한 소프트웨어모델 및 로직 세트를 저장하거나 또는 소프트웨어모델 및 로직 세트를 저장장치(320)에 저장에 저장할 수 있다. 저장장치(320)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다. 인메모리(330)는 위에서 개시한 라이브러리 엔진세트를 저장할 수 있다. 라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다.The input unit (310) can obtain a software model and logic set for the client manufacturing production system. The storage device (320) can store the software model and logic set received by the input unit (310) or store the software model and logic set in the storage device (320). The storage device (320) can include volatile memory or non-volatile memory. The in-memory (330) can store the library engine set disclosed above. The library engine set can include a production planning engine, which is a plurality of encapsulated function block files that generate a production plan.
실시 예의 프로세서(340)는 클라이언트 제조생산시스템에 대한 소프트웨어모델 및 로직 세트를 획득하고, 상기 소프트웨어모델 및 로직 세트에 기반하여 모델 정보, 실험 계획 정보 및 실험 결과 정보 중 적어도 하나를 포함하는 생산 계획 관련 데이터를 산출하며, 상기 생산 계획 관련 데이터를 제공할 수 있다. 이에 대한 상세한 내용은 상술한 설명을 참조한다.The processor (340) of the embodiment may acquire a software model and logic set for a client manufacturing system, and based on the software model and logic set, generate production plan-related data including at least one of model information, experimental plan information, and experimental result information, and provide the production plan-related data. For details, refer to the above description.
프로세서(340)는 사용자인터페이스(360)의 사용자의 요청에 따라 소프트웨어모델 및 로직세트를 테스트하거나 사전 실행하여 생산 계획 데이터를 얻을 수 있다. 그리고 프로세서(340)는 사용자의 요청에 따라 생산 계획 데이터를 생성하는 소프트웨어모델 및 로직을 분석하거나 테스트한 결과를 사용자인터페이스(360)를 통해 사용자에게 제공할 수 있다. 이에 대한 상세한 내용은 상술한 설명을 참조한다.The processor (340) can obtain production planning data by testing or pre-executing software models and logic sets at the user's request via the user interface (360). Furthermore, the processor (340) can analyze or test the software models and logic sets that generate production planning data at the user's request, and provide the results to the user via the user interface (360). For further details, please refer to the above description.
출력부(350)는 소프트웨어 모델 및 로직 세트의 분석 결과 데이터 및 소프트웨어 모델 및 로직 세트에 기반하여 실험을 수행한 결과 데이터를 제공하여 로컬 환경 및 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (350) can provide analysis result data of a software model and logic set and result data of an experiment performed based on the software model and logic set to enable production or process management in a local environment and client system.
이하의 실시 예에서는 설치된 라이브러리 엔진 세트를 기반으로 생성된 소프트웨어 모델 및 로직 세트를 이용하여 실험 허브를 통해 생산 계획 데이터를 제공하는 일 예를 상세히 개시한다.The following examples detail an example of providing production planning data through an experiment hub using a set of software models and logic generated based on a set of installed library engines.
상술한 바와 같이, 클라이언트의 제조생산시스템(100)의 시스템운영부(110)는, 모델개발부(1100)가 개발한 소프트웨어(SW) 모델 및 모델 로직을 서버관리부(1200)를 통해 수신하는 경우, 데이터베이스(150)로부터 기준정보 데이터가 포함된 입력데이터를 제공받고, 이를 이용하여 수신한 소프트웨어 모델 및 로직 세트를 실행하여 생산계획 데이터를 생성할 수 있다.As described above, when the system operation unit (110) of the client's manufacturing production system (100) receives the software (SW) model and model logic developed by the model development unit (1100) through the server management unit (1200), it receives input data including reference information data from the database (150) and can use this to execute the received software model and logic set to generate production plan data.
단일 소프트웨어 모델 및 단일 로직을 사용하여 생산 계획 데이터를 생성하는 경우, 모델실행부(130)를 통해 생산 계획 데이터를 제공할 수 있다. 이 경우, 모델실행부(130)는 소프트웨어 모델 및 모델 로직을 실행하고 생산 계획 데이터를 생성하여 모델분석부(1300)가 분석할 수 있는 생산 계획 데이터를 제공할 수 있다.When generating production plan data using a single software model and single logic, the production plan data can be provided through the model execution unit (130). In this case, the model execution unit (130) can execute the software model and model logic, generate production plan data, and provide production plan data that can be analyzed by the model analysis unit (1300).
한편, 단일 소프트웨어 모델의 실행만으로 작업이 충분하지 않은 경우가 발생할 수 있다. 이 경우에는 복수의 소프트웨어 모델 및 외부 로직의 도입을 통해 복수의 작업을 자동으로 실행할 필요가 있다. 예를 들어, 복수의 소프트웨어 모델들 또는 로직들이 사용될 경우, 다수의 실험을 포함하는 실험허브부(140)를 통해 수행될 수 있다.Meanwhile, there may be instances where executing a single software model alone is insufficient. In these cases, the automated execution of multiple tasks requires the introduction of multiple software models and external logic. For example, when multiple software models or logics are used, these tasks can be performed through an experiment hub (140) containing multiple experiments.
실험허브는 적어도 하나의 소프트웨어 모델 및 적어도 하나의 모델 로직을 이용해 다양한 실험을 하기 위해 필요한 정보 및 실험 결과물을 저장하는 자료의 집합체에 해당한다. 또한, 실험허브부(140)는 상술한 실험허브를 조회, 편집, 실행, 분석하기 위한 구성에 해당한다.The Experiment Hub is a collection of data that stores the information and experimental results necessary for conducting various experiments using at least one software model and at least one model logic. Furthermore, the Experiment Hub section (140) is a component for viewing, editing, executing, and analyzing the aforementioned Experiment Hub.
개시하는 실시예에서는 실험허브부(140)를 기초로 복잡한 작업을 수행하는 예를 설명한다.In the disclosed embodiment, an example of performing a complex task based on the experimental hub unit (140) is described.
도 36은 실시 예에 따른 디지털 생산 계획 데이터를 제공하는 컴퓨팅 시스템의 일 실시예를 개시한다.FIG. 36 discloses one embodiment of a computing system that provides digital production planning data according to an embodiment.
본 도면은 디지털 생산 운영 데이터를 제공하는 온프레미스(on-premise) 컴퓨팅 시스템의 일 실시 예를 개시한다. 이 실시 예에서, 온프레미스 컴퓨팅 시스템(1000) 및 제조생산시스템(100)은 상술한 도 2의 실시 예에서 실험허브부를 더 포함할 수 있다.This drawing discloses an embodiment of an on-premise computing system that provides digital production operation data. In this embodiment, the on-premise computing system (1000) and manufacturing production system (100) may further include a test hub unit, similar to the embodiment of FIG. 2 described above.
일 실시 예에서 제조생산시스템 등에서 생산 계획을 실행하는 클라이언트 측의 제조생산시스템(100)은 온프레미스 컴퓨팅 시스템(1000)에 생산 실행을 위한 기준 정보를 포함하는 입력데이터를 제공하고, 모델개발부(1100)는 소프트웨어 모델 및 모델 로직을 생성할 수 있다.In one embodiment, a client-side manufacturing production system (100) that executes a production plan in a manufacturing production system, etc., provides input data including reference information for production execution to an on-premise computing system (1000), and a model development unit (1100) can create a software model and model logic.
서버관리부(1200)는 모델개발부(1100)가 생성한 소프트웨어 모델 및 모델 로직을 클라이언트에 전달하고, 클라이언트(100)의 시스템운영부(110)는 소프트웨어 모델 및 모델 로직의 실행에 관련된 작업을 정의, 예약, 등록 및 실행할 수 있다.The server management unit (1200) transmits the software model and model logic created by the model development unit (1100) to the client, and the system operation unit (110) of the client (100) can define, schedule, register, and execute tasks related to the execution of the software model and model logic.
일 실시 예에서 제조생산시스템(100)은, 제조 공정을 전반적으로 운영 및 관리하는 시스템운영부(110), 시스템운영부(110)의 실행 요청에 따라 생산 계획 데이터를 생성하는 모델실행부(130) 및 모델 실행부(130)에 다양한 실험을 수행하도록 요청하는 실험허브부(140), 모델실행부(130)의 실행한 결과인 생산 계획 데이터를 저장하는 데이터베이스(150)을 포함한다.In one embodiment, the manufacturing production system (100) includes a system operation unit (110) that operates and manages the manufacturing process as a whole, a model execution unit (130) that generates production plan data according to an execution request of the system operation unit (110), an experiment hub unit (140) that requests the model execution unit (130) to perform various experiments, and a database (150) that stores production plan data that is the result of execution of the model execution unit (130).
상술한 바와 같이, 실험허브는 적어도 하나의 소프트웨어 모델 및 적어도 하나의 모델 로직을 이용해 다양한 실험을 해보기 위해 필요한 정보 및 실험 결과물을 저장하는 자료의 집합체에 해당한다. 온프레미스컴퓨팅 시스템(1000) 및/또는 클라이언트 제조공정시스템(100)은 실험허브부(140, 1500)를 포함할 수 있다. 또한, 실험허브부(140, 1500)는 실험허브를 조회, 편집, 실행하기 위하여 실험허브 편집부, 실험허브 실행부, 실험허브 분석부를 포함하여, 이와 관련하여 이하에서 설명한다.As described above, the experiment hub is a collection of data that stores information and experiment results necessary for conducting various experiments using at least one software model and at least one model logic. The on-premise computing system (1000) and/or the client manufacturing process system (100) may include an experiment hub unit (140, 1500). In addition, the experiment hub unit (140, 1500) includes an experiment hub editing unit, an experiment hub execution unit, and an experiment hub analysis unit to view, edit, and execute the experiment hub, which will be described below.
실험허브부(140, 1500)는 적어도 하나의 소프트웨어 모델 및 적어도 하나의 모델 로직에 기초하여 다양한 시나리오를 포함하는 실험을 설계하고, 데이터베이스(150)에 미리 준비된 입력 데이터에 기초하여, 실험을 수행하여 생산 계획 데이터를 제공할 수 있다. 생산 계획 데이터는 실험 요약 및 시나리오 결과를 포함하는 실험 결과에 해당할 수 있다.The experimental hub (140, 1500) can design experiments including various scenarios based on at least one software model and at least one model logic, and perform experiments based on input data prepared in advance in the database (150) to provide production planning data. The production planning data can correspond to experimental results including an experiment summary and scenario results.
도 37는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브의 기본구조의 예를 개시하는 도면이다.FIG. 37 is a diagram disclosing an example of the basic structure of an experimental hub based on a software model and logic set according to an embodiment.
도시된 바와 같이, 실험허브는 변인(722), 주요성능지표(723), 실험설계(724), 실험수행(725) 및 DB(database) 연결정보(726) 등을 포함하는 정보의 집합체에 해당한다.As shown, the experimental hub corresponds to a collection of information including variables (722), key performance indicators (723), experimental design (724), experimental performance (725), and database connection information (726).
변인(factor)(722)는 실험에서 사용될 변경 가능한 요소를 특정하는 정보의 종류에 해당한다. 변인 값(factor value)는 특정된 변인이 실험에서 사용되기 위하여 나타내는 정보의 값에 해당한다.A factor (722) is a type of information that specifies a changeable element to be used in an experiment. A factor value is the value of information that a specified variable represents for use in an experiment.
변인은 적어도 하나의 모델 타입 변인 및 적어도 하나의 로직 타입 변인을 포함할 수 있고, 각각의 모델 타입 변인 또는 로직 타입 변인은 그 자체의 변인 값을 가질 수 있고, 또한, 하위 레벨의 변인을 포함하여, 하위 레벨의 변인 값을 가질 수 있다.A variable may include at least one model type variable and at least one logic type variable, and each model type variable or logic type variable may have its own variable value, and may also have lower-level variable values, including lower-level variables.
주요성능지표(KPI, Key Performance Indicator)(723)는 개별 시나리오 결과물을 가공하여 수치화하기 위한 함수에 해당한다. 주요성능지표는 그 자체의 값인 주요성능지표 값을 가질 수 있다. 주요성능지표 값(KPI value)는 주요성능지표에 적용된 수식을 실험 수행을 통한 시나리오 결과물에 적용하여 얻은 실제 값에 해당한다.A Key Performance Indicator (KPI) (723) is a function used to process and quantify individual scenario results. A KPI can have its own value, called a KPI value. A KPI value is the actual value obtained by applying the formula applied to the KPI to the scenario results obtained through experimental execution.
한편, 시나리오(scenario)는 결정된 변인 값을 입력으로 하여 결정된 로직을 사용하여 실행할 준비가 된 소프트웨어 모델 1개 세트를 나타낸다. 시나리오 결과(scenario result)는 시나리오를 실행하여 얻은 결과물로, 테이블 형태로 나타낼 수 있다. 실험(experiment)은 복수의 시나리오들을 포함하는 단위에 해당한다. 예를 들어, 도시된 바를 참조하면, 실험 설계1을 통해 설계된 실험은 2개의 시나리오를 포함하는 실험에 해당한다.Meanwhile, a scenario represents a set of software models ready for execution using determined logic and inputting determined variable values. A scenario result is the output obtained by executing a scenario and can be represented in table form. An experiment corresponds to a unit that includes multiple scenarios. For example, referring to the diagram, an experiment designed through Experimental Design 1 corresponds to an experiment that includes two scenarios.
실험 설계(experiment design)(724)는 변인과 주요성능지표를 이용하여 수행될 시나리오 조합 정보를 포함하는 구조에 해당한다. 예를 들어, 본 실시예의 실험 설계1은 고정크기 실험 설계로 모델 변인1_1의 변인값 1_1_2, 변인값 1_1_3를 포함하는 2개의 시나리오 조합에 해당할 수 있다. 또한, 본 실시예의 실험 설계2는 반복 실험 설계로 모델 변인 1_1의 변인값 1_1_1, 모델 변인 1_2의 변인 값 1_2_1, 변인 값 1_2_2, 로직 변인 2의 변인 값 2_2, 주요성능지표 KPI_3 및 반복단계 로직을 포함하여 6개 이상의 시나리오 조합에 해당할 수 있으나, 이에 국한되지 않고 증가하거나 감소할 수 있다. 고정크기 실험 설계 및 반복실험 설계와 관련하여 후술하도록 한다.Experimental design (724) corresponds to a structure including information on combinations of scenarios to be performed using variables and key performance indicators. For example, Experimental design 1 of the present embodiment may correspond to two scenario combinations including variable values 1_1_2 and 1_1_3 of model variable 1_1 as a fixed-size experimental design. In addition, Experimental design 2 of the present embodiment may correspond 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 logic variable 2, key performance indicator KPI_3, and repetition step logic as a repeated experimental design, but is not limited thereto and may increase or decrease. The fixed-size experimental design and the repeated experimental design will be described later.
또한, 실험 수행(experiment execution)(725)은 실험 설계에 기초하여 개별 시나리오가 만들어지고 변인 값을 변경하고 실행한 다음 결과물에서 주요성능지표를 계산하여 저장하고 있는 구조로서, 수행 결과물로서 실험 결과를 포함할 수 있다. 예를 들어, 실험요약은 변인 값 및 주요성능지표 값이 포함된 테이블에 해당할 수 있다. 또한, 실험 결과는 실험 요약 및 시나리오 결과를 포함할 수 있다. 여기에서, 시나리오 결과는 단일 모델을 실행한 결과 데이터, 로그 데이터 등을 포함하는 출력 데이터를 포함할 수 있다.Additionally, experiment execution (725) is a structure in which individual scenarios are created based on the experimental design, variable values are changed, execution is performed, and then key performance indicators are calculated and stored from the results. The execution results may include experimental results. For example, the experiment summary may correspond to a table containing variable values and key performance indicator values. Furthermore, the experiment results may include an experiment summary and scenario results. Here, the scenario results may include output data, such as result data from executing a single model, log data, etc.
예를 들어, 본 실시예의 실험 수행 1은 상술한 실험 설계 1에 따라 2개의 시나리오에 대하여, 변인 값을 변경하여 실험을 실행한 결과물로서 적어도 하나의 변인 값과 적어도 하나의 주요성능지표 값의 집합인 실험 요약을 포함할 수 있다. 또한, 실험 수행을 통해 얻게 된 결과물은 DB 연결정보에 따라 데이터베이스에 업로드할 수 있게 된다. 상술한 실험허브를 이용하는 경우, 모델실행부를 통해 단일 모델 로직의 변인 값을 여러 번 변경하여 수행하는 것에 비하여 복수의 모델 로직을 한번의 실험으로 수행할 수 있으므로 복잡한 작업을 보다 효율적으로 실행할 수 있게된다.For example, Experimental Execution 1 of the present embodiment may include an experiment summary, which is a set of at least one variable value and at least one key performance indicator value, as a result of executing an experiment by changing variable values for two scenarios according to Experimental Design 1 described above. In addition, the results obtained through the experiment execution can be uploaded to a database according to the DB connection information. In the case of using the experiment hub described above, multiple model logics can be executed in a single experiment compared to executing a single model logic by changing variable values multiple times through the model execution unit, so that complex tasks can be executed more efficiently.
도 38는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면이다.FIG. 38 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
먼저, 실험허브부(140)는 실험허브 파일을 생성할 수 있다. 이때, 실험허브 파일은 이후에 모델 및 로직과 관련된 변인을 등록하고 생성하게 될 대상 파일에 해당한다. 또한, 실험허브 파일 생성에는 저장 경로(저장 위치)가 매개변수로 주어질 수 있다. 이때, 경로는 소프트웨어 운영 시스템(OS) 상의 절대경로 또는 상대경로가 사용될 수 있다. 예를 들어, 실험허브 파일이 생성된 이후 편집된 정보의 저장 위치는 기본적으로 실험허브 파일의 상대경로를 사용하여 관리하지만, 절대 경로가 지정될 수도 있다.First, the experiment hub unit (140) can create an experiment hub file. At this time, the experiment hub file corresponds to a target file that will later register and create variables related to the model and logic. In addition, a storage path (storage location) can be given as a parameter when creating the experiment hub file. At this time, an absolute path or a relative path on the software operating system (OS) can be used as the path. For example, the storage location of edited information after the experiment hub file is created is basically managed using the relative path of the experiment hub file, but an absolute path can also be specified.
실험허브 파일은 편집된 정보와 실행 결과를 모두 저장할 수 있고, 별도 파일로 분할하여 관리될 수도 있다. 예를 들어, 변인 정보와 변인 값 정보를 실행 결과와 별도의 파일로 저장하여 다른 실험 허브 파일에서도 변인 정보와 변인 값 정보를 불러와 재사용할 수 있다. 또한, 실험 단위 별 결과 파일만을 출력하여 편집된 정보를 포함하는 실험허브 파일과 별개로 조회할 수있다.Experimental hub files can store both edited information and execution results, and can also be managed as separate files. For example, variable information and variable value information can be stored separately from execution results, allowing them to be retrieved and reused in other experiment hub files. Furthermore, only the results files for each experimental unit can be output, allowing them to be viewed separately from the experiment hub file containing the edited information.
실험허브 파일이 생성된 후, 생성된 실험 허브 파일에 적어도 하나의 모델타입 변인과 적어도 하나의 로직타입 변인이 등록될 수 있다. 예를 들어, 각 모델과 로직은 변인으로 등록될 수 있다. 이 경우, 모델타입 변인의 변인 값은 등록될 당시의 모델 그 자체로서, 입력데이터, 출력데이터, 로직 등을 모두 포함하는 정보 집합체에해당한다. 또한, 로직타입 변인의 변인 값은 모델실행부(130)에서 모델과 함께 사용되기 위한 로직 파일들이 위치하는 절대/상대 경로 또는 절대/상대 경로가 포함된 압축 파일에 해당할 수 있다.After the experimental hub file is created, at least one model type variable and at least one logic type variable can be registered in the created experimental hub file. For example, each model and logic can be registered as a variable. In this case, the variable value of the model type variable corresponds to the model itself at the time of registration, which is an information set including input data, output data, logic, etc. In addition, the variable value of the logic type variable may correspond to an absolute/relative path or a compressed file including an absolute/relative path where logic files to be used together with the model are located in the model execution unit (130).
예를 들어, 도 38를 참조하면, 특정 로직에서 디스패칭 로직을 개선한 로직이 3가지 버전으로 제안된 상황을 가정해볼 수 있다. 로직_0는 원본 로직을 나타내고, 로직_1 내지 로직 _3은 개선된 로직에 해당한다. 사용자는 제조생산시스템의 과거 10개의 모델들에서 로직의 수행시간, 생산 계획 수량을 확인하여 성능이 좋았던 로직 버전 3가지를 반영하고자 할 수 있다. 이를 반영한 실험 설계가 도 38의 실험 설계 1에 해당한다.For example, referring to Fig. 38, we can assume a situation where three versions of logic are proposed that improve dispatching logic in a specific logic. Logic_0 represents the original logic, and logic_1 to logic_3 correspond to improved logic. The user may want to reflect the three logic versions that performed well by checking the execution time and production plan quantity of the logic in the past 10 models of the manufacturing production system. The experimental design reflecting this corresponds to Experimental Design 1 of Fig. 38.
이 경우, 향후 주요성능지표에 대한 등록이 완료된 후, 로직 버전 4가지(원본 로직 및 3가지 개선된 로직)과 과거 10개의 모델로 총 40개의 시나리오를 포함하는 실험을 수행한 결과를 검토하여 의사결정을 내릴 수 있을 것이다. 예를 들어, 실험 수행의 결과, 시나리오 1의 경우 구동시간이 짧아지고 생산량이 증가하는 결과가 도출된다면, 사용자는 시나리오 1에 대응되는 로직 버전을 사용하는 방식으로 의사결정을 내릴 수 있다.In this case, after registration for key performance indicators is completed, decisions can be made by reviewing the results of experiments involving four logic versions (original logic and three improved logic versions) and 10 previous models, for a total of 40 scenarios. For example, if the experiment results in a shorter run time and increased production for Scenario 1, the user can make a decision by using the logic version corresponding to Scenario 1.
도 39는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면이다.FIG. 39 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
보다 상세하게는, 도 39는 실험허브 파일에 데이터 타입 변인, 변인 값과 주요성능지표를 등록하는 예를 개시하는 도면이다. 데이터 타입 변인은 모델타입 변인의 하위 개념으로서, 모델타입 변인에 정의된 데이터에 따라 종속적으로 정의될 수 있다. 또한, 변인 값은 모델타입 변인의 값 및 데이터 타입 변인의 값을 포함할 수 있다. 도 37의 모델 변인 1의 변인 값은 모델타입 변인의 값으로서 모델에 해당한다.More specifically, Fig. 39 is a diagram disclosing an example of registering data type variables, variable values, and key performance indicators in an experiment hub file. Data type variables are subordinate concepts of model type variables and can be defined dependently based on data defined in the model type variables. In addition, variable values can include values of model type variables and values of data type variables. The variable value of model variable 1 in Fig. 37 corresponds to the model as a value of the model type variable.
일 예로서, 데이터 타입 변인은 소프트웨어 모델의 입력 데이터에 존재하는 모든 개별데이터가 대상이 될 수 있다. 예를 들어, 개별 데이터는 모델 전역변수(model argument)의 이름으로 특정될 수 있다. 또한, 데이터 테이블에서 데이터 스키마에 존재하는 키(key)와 대상(target) 열(column)을 통해 단일 칸(cell)이 특정될 수 있다. 이 경우, 변인 값은 개별 데이터의 타입에 따라 정해질 수 있다. 데이터 타입은 수치 데이터뿐만 아니라, 문자 데이터, 날짜 데이터 등도 포함될 수 있다.For example, a data type variable can target all individual data in the input data of a software model. For example, individual data can be specified by the name of a model argument. Furthermore, a single cell in a data table can be specified through the key and target columns in the data schema. In this case, the variable value can be determined based on the type of the individual data. Data types can include not only numeric data, but also character data, date data, and more.
예를 들어, 모델 1의 Demand 테이블에 Demand_ID/Quantity가 수량으로 주어지고, Demand_ID가 Key이고, 대상 열(Target column)이 수량(quantity) 일때, 데이터가 Demand_1/100, Demand_2/200, Demand_3/100으로 주어져 있다면, Demand_ID==”Demand_1”인 조건을 만족하는 수량은 한 칸으로 특정될 수 있다.For example, in the Demand table of Model 1, if Demand_ID/Quantity is given as quantity, Demand_ID is the Key, and the Target column is quantity, and the data is given as Demand_1/100, Demand_2/200, Demand_3/100, then the quantity that satisfies the condition Demand_ID==”Demand_1” can be specified in one space.
다른 일 예로서, 데이터 타입 변인은 모델의 모든 입력 데이터 테이블이 대상이 될 수 있다. 이 경우, 변인 값은 데이터 테이블에 해당할 수 있고, 데이터 테이블의 스키마는 원본 데이터 스키마에 따라 결정될 수 있다. 예를 들어, 데이터 테이블은 원본 데이터 테이블로부터 적어도 하나 이상의 데이터 칸 값이 수정될 수 있다. 또한, 데이터 테이블은 외부 파일 불러오기, 키(key) 조건에 해당하는 모든 데이터 일괄 변경 등의 방식으로 편집이 가능하다.As another example, a data type variable can target all input data tables in the model. In this case, the variable values can correspond to data tables, and the data table schema can be determined based on the original data schema. For example, a data table can have at least one data field value modified from the original data table. Furthermore, data tables can be edited through methods such as importing external files or batch-modifying all data matching key conditions.
예를 들어, 도 39, 모델 변인 1의 데이터 타입 변인은 수량(quantity)(711), 시뮬레이션 기간(simulation horizon)(713), 프로세싱 타임 테이블(process time table)(715)을 포함할 수 있다. 예를 들어, 수량(711)은 단일 칸 변인으로서, 3가지 변인 값인 50, 100, 150이 생성될 수 있다. 예를 들어, 시뮬레이션 기간(713)은 전역 변수 변인으로서, 2가지 변인 값인 30일, 60일이 생성될 수 있다. 또한, 예를 들어, 프로세싱 타임 테이블(715)은 테이블 변인으로서, 2가지 변인 값인 테이블1, 테이블2이 생성될 수 있다.For example, in Fig. 39, the data type variables of model variable 1 may include quantity (711), simulation horizon (713), and processing time table (715). For example, quantity (711) may be a single-cell variable, and three variable values of 50, 100, and 150 may be generated. For example, simulation horizon (713) may be a global variable, and two variable values of 30 days and 60 days may be generated. In addition, for example, processing time table (715) may be a table variable, and two variable values of table 1 and table 2 may be generated.
주요성능지표(KPI)는 시나리오 입력데이터와 결과물에 포함된 정보를 가공하는 함수 정보를 포함할 수 있다. 또한, 각종 함수에서 등록된 모델타입 변인과 데이터 타입 변인, 모델에 포함된 모든 형태의 데이터(전역변수, 입/출력 데이터) 그리고 다른 주요성능지표를 매개변수로 사용할 수 있다. 주요성능지표의 값은 수치 데이터로서 단일 수치 값(scalar) 및 벡터 값을 포함할 수 있다..Key performance indicators (KPIs) can include function information that processes information contained in scenario input data and output. Furthermore, registered model type variables and data type variables, all types of data included in the model (global variables, input/output data), and other KPIs can be used as parameters in various functions. KPI values can be numerical data, including single numeric values (scalar values) and vector values.
예를 들어, 주요성능지표는 값이 높을수록 좋은지, 낮을수록 좋은지를 매개변수로 특정할 수 있고, 이는 추후 실험허브부의 실험허브 분석부 또는 별도의 결과 조회 사용자 인터페이스를 통해 개선점을 표시하는 경우, 색상 구분, 화살표 방향 등을 정할 때 사용될 수 있다.For example, a key performance indicator can be specified as a parameter, such as whether a higher value is better or a lower value is better, and this can be used to determine color distinction, arrow direction, etc. when indicating improvement points through the Experimental Hub Analysis Department of the Experimental Hub Department or a separate result inquiry user interface.
하나 이상의 주요성능지표가 포함되는 경우, 서로 다른 주요성능지표는 매개변수로 사용될 수 있기 때문에, 주요성능지표 사이의 계산 순서가 존재하며, 이를 편집할 수도 있다. 예를 들어, 생산 계획평가에서 단 1개의 지표인 종합 점수로 나타나기 위하여 생산량, 장비교체 횟수, 납기지연 수량의 3가지 수치의 가중합을 도출하는 경우를 가정한다. 이 경우, 주요성능지표로 상술한 생산량, 장비교체 횟수, 납기지연 수량의 3가지를 먼저 등록해야 하며, 종합 점수도 주요성능지표에 해당할 수 있다. 이때, 독립적인 주요성능지표인 생산량, 장비교체 횟수, 납기지연 수량을 먼저 계산한 후 이에 종속적인 지표인 종합 점수를 계산할 수 있다.When more than one KPI is included, different KPIs can be used as parameters, so there is a calculation order between the KPIs, and this can be edited. For example, suppose a production plan evaluation requires the weighted sum of three figures—production volume, number of equipment replacements, and number of delivery delays—to produce a single KPI, the overall score. In this case, the three KPIs described above—production volume, number of equipment replacements, and number of delivery delays—must be registered first, and the overall score can also be considered a KPI. In this case, the independent KPIs—production volume, number of equipment replacements, and number of delivery delays—can be calculated first, and then the dependent KPI—the overall score—can be calculated.
한편, 주별 생산량, 월별 생산량, 분기별 생산량이 주요성능지표인 경우, 독립적인 지표부터 계산하고, 종속적인 지표를 계산할 수 있다. 본 실시예에서, 주별 생산량이 먼저 계산된 후, 주별 생산량에 영향을 받는 월별 생산량이 계산될 수 있고, 또한, 월별 생산량이 계산된 후, 분기별 생산량이 계산될 수 있다. 이전에 계산된 주요생산지표 값을 다음 주요생산지표의 산술식에 매개변수로 사용할 수 있어, 중복 계산을 피할 수 있다.Meanwhile, when weekly, monthly, or quarterly production volumes are key performance indicators, independent indicators can be calculated first, followed by dependent indicators. In this example, weekly production volume can be calculated first, followed by monthly production volume, which is influenced by weekly production volume. Furthermore, monthly production volume can be calculated first, followed by quarterly production volume. Previously calculated key production indicator values can be used as parameters in the arithmetic formulas for subsequent key production indicators, thereby avoiding duplicate calculations.
또한, 주요성능지표에서 제공되는 함수는 테이블 요약/산술식/데이터 타입 전환 등을 지원할 수 있다. 예를 들어, 요약 함수는 Sum, Count, Avg, Min, Max, Std를 포함하며, 이에 한정되지 아니한다. 또한, 예를 들어, 수학은 더하기, 빼기, 곱하기, 나누기, 올림, 내림, 반올림, 루트, 제곱, 로그 등을 포함하며, 이에 한정되지 아니한다. 예를 들어, 데이터 타입 전환은 날짜형식을 정수형식으로 전환하는 경우 등을 포함할 수 있다.Additionally, functions provided in key performance indicators can support table summarization/arithmetic expressions/data type conversion, etc. For example, summary functions include, but are not limited to, Sum, Count, Avg, Min, Max, and Std. Furthermore, for example, mathematics includes, but is not limited to, addition, subtraction, multiplication, division, rounding up, down, square root, logarithm, etc. For example, data type conversion may include converting date format to integer format, etc.
예를 들어, 도 39를 참조하면, 주요성능지표는 평균제품생산시간(product_1 Avg. CT)(717), 총 제품 수량(Total Product qty)(719), 러닝 타임(Run Time)(721)을 포함할 수 있다. 예를 들어, 평균제품생산시간(717)은 Product 01 제품이 공장에 들어와서 나가기까지의 평균 사이클 타임을 구하는 것으로, Average (Model_1.Output.InOutPlan, PRODUCT_ID == “Product_01”,Cycle_Time)와 같은 함수 정보를 포함할 수 있다. 예를 들어, 총 제품 수량(719)는 모든 제품의 생산 기록을 보고 생산량의 총합을 구하는 것으로, Sum(Model_1.Output.InOutPlan,None,Quantity)와 같은 함수 정보를 포함할 수 있다. 또한, 예를 들어, 러닝 타임(721)은 종료시각에서 시작시각을 차감하여 수행 시간을 구한 후 수치데이터로 변환하는 것으로, ConvertFromTimeSpanToDouble (Model_1.End_Time - Model_1.StartTime)와 같은 함수 정보를 포함할 수 있다.For example, referring to FIG. 39, key performance indicators may include average product production time (product_1 Avg. CT) (717), total product quantity (Total Product qty) (719), and running time (Run Time) (721). For example, average product production time (717) is to obtain the average cycle time from when Product 01 enters the factory to when it leaves the factory, and may include function information such as Average (Model_1.Output.InOutPlan, PRODUCT_ID == “Product_01”,Cycle_Time). For example, total product quantity (719) is to obtain the sum of the production amount by looking at the production records of all products, and may include function information such as Sum (Model_1.Output.InOutPlan,None,Quantity). Additionally, for example, the running time (721) is calculated by subtracting the start time from the end time to obtain the execution time and then converting it into numerical data, and may include function information such as ConvertFromTimeSpanToDouble (Model_1.End_Time - Model_1.StartTime).
도 40는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일에서 정제 로직을 생성하는 예를 개시하는 도면이다.FIG. 40 is a diagram disclosing an example of generating refinement logic from an experimental hub file based on a software model and logic set according to an embodiment.
사용자가 원하는 모델을 사용하기 위해서는 일반적으로 모델 개발부(1100)에서 소프트웨어 모델 및 모델 로직이 개발이 완료되어 있음이 보통이다. 다만, 예외적으로 실험허브를 수행하는 다른 엔지니어가 모델을 검토하는 중에 모델개발부(1100)를 통해 모델 및 로직을 편집할 수 없음에도 어떤 정보를 추가로 확인하고자 할 수 있다. 이 경우, 정제 로직을 활용할 수 있으며, 본 실시예는 시나리오가 시나리오별 또는 실험별 결과 정제 로직을 설정하는 예를 설명한다.Typically, for a user to use a desired model, the software model and model logic are already developed in the model development unit (1100). However, in exceptional cases, another engineer performing the experiment hub may wish to review additional information while reviewing the model, even though the model and logic cannot be edited through the model development unit (1100). In this case, refinement logic can be utilized, and this embodiment describes an example in which a scenario sets result refinement logic for each scenario or experiment.
정제 로직은 시나리오 별 결과 정제 로직 및 실험 별 결과 정제 로직을 포함할 수 있다. 정제 로직은 필수적으로 이루어져야 하는 구성은 아니며, 기존에 모델 파일에 정의된 스키마로 원하는 형태의 결과를 얻을 수 없는 경우에 사용될 수 있다.Refinement logic can include scenario-specific result refinement logic and experiment-specific result refinement logic. Refinement logic is not a mandatory component and can be used when the desired results cannot be achieved with the schema defined in the existing model file.
일 예로서, 시나리오 별 결과 정제 로직은 시나리오가 끝날 때마다, 시나리오 결과를 정제하여 새로운 테이블을 생성할 수 있다. 이 경우, 별도의 스키마에 데이터를 저장할 수 있도록 하여, 모델개발부(1100)를 거치지 않고, 외부에서 스키마를 생성하고 데이터를 입력할 수 있게 된다. 이때, 사용되는 데이터는 시나리오 별 결과에 포함된 데이터에 한정된다. 예를 들어, 도 40를 참조하면, 모델개발부(1100)에 의해 모델 출력물 스키마에 개별 작업물의 공정 별 투입시각과 종료시각(InOutPlan)(739)이 존재하지만, 작업물이 공장에 들어와서 나갈 때까지 걸리는 시간(CycleTime(CT))이 기록되어 있지 않은 경우인 것으로 가정한다. 이 경우, 시나리오 별 결과 정제 로직을 이용하여 CycleTime(CT) 테이블을 생성하고 스키마로 작업물 ID, 작업물 종류, cycle time을 생성한다. 예를 들어, 이 중 Lot_1의 CycleTime(743)은 Lot_1의 첫 공정 시간(741)과 마지막 공정 시간(742)의 차이이고, Lot_2의 CycleTime(747)은 Lot_2의 첫 공정 시간(745)과 마지막 공정 시간(746)의 차이에 해당한다.For example, the scenario-specific result refinement logic can refine the scenario results and create a new table each time a scenario ends. In this case, by allowing data to be stored in a separate schema, the schema can be created and data entered externally without going through the model development unit (1100). At this time, the data used is limited to the data included in the scenario-specific results. For example, referring to FIG. 40, it is assumed that the model development unit (1100) has the input time and end time (InOutPlan) (739) of each process of an individual workpiece in the model output schema, but the time it takes for the workpiece to enter and leave the factory (CycleTime (CT)) is not recorded. In this case, the scenario-specific result refinement logic is used to create a CycleTime (CT) table, and the workpiece ID, workpiece type, and cycle time are created as a schema. For example, among these, CycleTime (743) of Lot_1 corresponds to the difference between the first process time (741) and the last process time (742) of Lot_1, and CycleTime (747) of Lot_2 corresponds to the difference between the first process time (745) and the last process time (746) of Lot_2.
또한, 시나리오 별 결과 정제 로직으로 생성된 테이블은 주요 성능 지표의 매개변수로 사용될 수 있다. 예를 들어, 도 40를 참조하면, 개별 시나리오의 InOutPlan을 참조하여 Lot별 최초 공정의 시작시간과 최후 공정의 종료 시각의 차이 시간으로 작업물 별 Cycle Time을 출력하는 커스텀 스키마를 만들고 데이터를 입력할 수 있다. 또한, 이를 주요성능지표에 활용하여 최대 Cycle Time이 얼마였는지 평균 Cycle Time이 얼마였는지를 시나리오 별로 수치화할 수 있다.Additionally, the tables generated by scenario-specific result refinement logic can be used as parameters for key performance indicators. For example, referring to Figure 40, a custom schema can be created and data entered to output the Cycle Time for each workpiece as the difference between the start time of the first process and the end time of the last process for each lot, by referencing the InOutPlan for each scenario. Furthermore, this can be utilized for key performance indicators to quantify the maximum and average Cycle Time for each scenario.
또한, 각각의 시나리오 실행 종료시마다 작업물 별 첫 공정의 투입시각과 마지막 공정의 종료시각의 시간차를 계산하여 새로운 cycle time 스키마에 테이블을 넣어 시나리오 결과물에 새로운 테이블을 제공할 수 있다. 도 40에 도시된 바와 같이, 시나리오 1에 대하여 시나리오 정제 로직(740)을 실행하는 경우, CycleTime 테이블(750)을 생성하여, 각각의 CycleTime 데이터(743, 747)을 추가할 수 있다. 시나리오 1뿐만 아니라 모든 시나리오에 대하여 시나리오 정제 로직(740)을 각각 실행된 경우, 획득된 CycleTime 데이터는 시나리오 별 결과(736)에 추가될 수 있다.In addition, at the end of each scenario execution, the time difference between the input time of the first process for each workpiece and the end time of the last process can be calculated and a table can be inserted into a new cycle time schema to provide a new table in the scenario results. As illustrated in Fig. 40, when the scenario refinement logic (740) is executed for scenario 1, a CycleTime table (750) can be created and each CycleTime data (743, 747) can be added. When the scenario refinement logic (740) is executed for all scenarios, not just scenario 1, the acquired CycleTime data can be added to the scenario-specific results (736).
다른 일 예로서, 실험 별 결과 정제 로직은 기본 제공되는 변인 및 주요성능지표의 조합 이외의 결과물을 생성할 수 있다.As another example, the experiment-specific results refinement logic may produce outputs other than the combinations of variables and key performance indicators provided.
예를 들어, 도 40를 참조하면, 모든 시나리오가 수행되고, 모든 시나리오에 cycle time 테이블이 정제 로직을 통해 생성된 것으로 가정하도록 한다. 이 경우, 실험 별 결과 정제 로직을 통해 평균 cycle time 테이블을 생성하고 스키마로 작업물 종류, 평균 cycle time을 입력할 수 있다. 또한, 모든 시나리오의 cycle time 테이블을 읽어 작업물 종류마다 cycle time의 평균을 구한 후 평균 cycle time 테이블을 제공할 수 있다.For example, referring to Figure 40, let's assume that all scenarios are performed and that cycle time tables for all scenarios are generated through purification logic. In this case, an average cycle time table can be generated through experiment-specific result purification logic, and the workpiece type and average cycle time can be input into the schema. Additionally, the cycle time tables for all scenarios can be read to obtain the average cycle time for each workpiece type, and then the average cycle time table can be provided.
실험 정제 로직(760)을 실행하는 경우, 평균 CycleTime 테이블(765)을 생성하여, 제품별 평균 CycleTime 데이터(759)를 추가할 수 있다. 예를 들어, 평균 CycleTime은 제품별 Lot 전체의 Cycle Time(751, 753, 755)의 평균에 해당할 수 있다. 실험 정제 로직(760)이 실행된 경우, 획득된 평균Cycle Time 데이터는 실험 결과(733)에 추가될 수 있다.When executing the experimental refinement logic (760), an average CycleTime table (765) may be created, and product-specific average CycleTime data (759) may be added. For example, the average CycleTime may correspond to the average of the CycleTimes (751, 753, 755) of the entire lot for each product. When the experimental refinement logic (760) is executed, the obtained average CycleTime data may be added to the experimental results (733).
시나리오 별 또는 실험 정제 로직을 통해 유저는 모델개발부에 의해 모델파일에 정의된 스키마에 포함되어 있지 않은 결과물을 추가로 얻을 수 있다.Scenario-specific or experimental refinement logic allows users to obtain additional results not included in the schema defined in the model file by the model development department.
도 41는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면이다.FIG. 41 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
적어도 하나의 모델타입 변인과 적어도 하나의 로직타입 변인이 등록되고, 이와 관련된 모델의 변인, 변인 값과 주요 성능지표가 등록되고 나면, 실험을 설계하고 설계된 실험을 수행할 수 있다.Once at least one model type variable and at least one logic type variable are registered, and the related model variables, variable values, and key performance indicators are registered, an experiment can be designed and the designed experiment can be performed.
상술한 바와 같이, 실험 설계(Experiment Design)는 실험허브 파일에 등록된 변인 및 주요성능지표 정보를 통해 설계될 수 있다. 예를 들어, 실험 설계는 변인 값 및 주요 성능 지표의 조합을 설정하는 것을 나타낸다. 또한, 실험 설계는 고정크기 실험 설계 및 반복 실험 설계를 포함할 수 있다. 고정크기 실험 설계(Fixed-size Experiment Design)은 미리 등록된 변인과 변인 값의 조합으로 실험을 설계하는 것으로, 실험이 수행되기 전에 발생할 수 있는 모든 시나리오의 경우의 수를 알고 있는 실험 설계에 해당한다.As described above, an experimental design can be designed using information on variables and key performance indicators registered in the Experiment Hub file. For example, an experimental design refers to setting combinations of variable values and key performance indicators. Furthermore, an experimental design can include a fixed-size experimental design and a replicated experimental design. A fixed-size experimental design is an experimental design that designs experiments using pre-registered combinations of variables and variable values, corresponding to an experimental design in which all possible scenarios are known before the experiment is conducted.
실험 수행(Experiment Execution)은 실험 설계에 포함된 정보에 기초하여 시나리오를 생성하여 실험 허브 파일을 실행한 후 결과물을 출력하는 것을 나타낸다. 예를 들어, 실험허브부(140)의 실험허브 실행부는 생성된 실험허브 파일에 입력된 정보를 기반으로 복수의 시나리오를 생성하고 각 시나리오에 대응되는 파일을 모델 실행부(150)에 매개변수로 전달하여 실행될 수 있도록 한다. 모델 실행부(150)가 복수의 시나리오를 수행한 후 실험허브 실행부에서 각 시나리오 별 주요성능지표를 계산하여 실험 요약으로 수집할 수 있다.Experiment execution refers to generating scenarios based on information included in the experimental design, executing the experiment hub file, and then outputting the results. For example, the experiment hub execution unit of the experiment hub unit (140) generates multiple scenarios based on information entered in the generated experiment hub file, and passes the file corresponding to each scenario as a parameter to the model execution unit (150) so that it can be executed. After the model execution unit (150) executes multiple scenarios, the experiment hub execution unit can calculate key performance indicators for each scenario and collect them as an experiment summary.
결과물은 시나리오의 시작 및 종료 시간의 변인과 변인 값, 주요 성능 지표 및 주요 성능 지표의 값 정보 등을 포함할 수 있다. 또한, 실험 수행은 병렬 실행 수를 매개변수로 포함할 수 있다. 병렬 실행 수는 실험 수행 시 동시에 수행할 수 있는 시나리오 수를 의미한다. 고정크기 실험 설계의 경우, 시나리오 수를 N개, 병렬 실행 수를 M으로 하는 경우, 총 실행 횟수는 Ceilng(N/M)로서, N을 M으로 나눠서 올림한 수에 해당한다. 여기에서, 병렬 실행 수는 CPU의 물리 코어의 개수로 설정될 수 있고, 사용자에 의해 설정될 수도 있다.The output can include variables and variable values of the scenario start and end times, key performance indicators, and key performance indicator values. In addition, the experiment execution can 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 when executing the experiment. In the case of a fixed-size experiment design, if the number of scenarios is N and the number of parallel executions is M, the total number of executions is Ceilng(N/M), which is the number obtained by dividing N by M and rounding up. Here, the number of parallel executions can be set to the number of physical cores of the CPU, and can also be set by the user.
예를 들어, 도 41를 참조하면, 실험 설계 1(770)는 고정 실험 설계로서, 변인 값 및 주요 성능 지표의 조합으로 구성될 수 있다. 실험 설계 1(770)에서 변인 값 및 주요성능지표의 조합에 기초하여, 발생할 수 있는 모든 시나리오 개수는 XY 개임을 확인할 수 있다. 이 경우, 모든 시나리오 XY개에 대하여 미리보기를 보여준 뒤 사용자가 선택적으로 삭제/수정하여 실험을 확정하는 사용자 인터페이스가 제공될 수 있다. 예를 들어, 인터페이스를 통해 실험 순서를 변경할 수 있다. 또한, 실험 수행 1(775)은 실험 설계1(770)에 포함된 정보에 기초하여 시나리오를 XY개 생성하고, 병렬 횟수 4(776)로 나눠서 올림한 수인 Ceiling(XY/4) 횟수만큼 실행될 수 있다.For example, referring to FIG. 41, Experimental Design 1 (770) is a fixed experimental design, which can be composed of a combination of variable values and key performance indicators. Based on the combination of variable values and key performance indicators in Experimental Design 1 (770), it can be confirmed that the number of all scenarios that can occur is XY. In this case, a user interface can be provided that shows a preview of all XY scenarios and allows the user to selectively delete/modify them to confirm the experiment. For example, the order of the experiments can be changed through the interface. In addition, Experimental Execution 1 (775) can generate XY scenarios based on the information included in Experimental Design 1 (770) and execute them a number of times equal to Ceiling(XY/4), which is the number rounded up by dividing by the number of parallel runs 4(776).
한편, 고정크기 실험 설계는 변인과 변인 값이 모두 정해져 있는 상태를 포함할 수 있다. 고객으로부터 수주 받을 때 현재까지 수주받은 물량을 고려하여 예상 생산 시나리오를 제공해주는 경우를 가정하도록 한다. 예를 들어, 현재 A,B,C 3가지 제품의 수주를 1월 30일까지 각각 100, 100, 100씩 받은 상태에서, 기존 고객이 A 제품을 기존 수주물량 이외에 추가로 가능한 많이 생산해달라고 요청할 수 있다. 생산 계획을 만드는 입장에서는 고객에게 A 제품을 얼마만큼 언제까지 추가로 만들어 줄 수 있는지 설명해줄 수 있어야한다. 이 경우, A,B,C 제품의 1월 30일까지 수주 물량의 수량 중 A 제품의 수량을 변인으로 설정하고, 100 부터 300까지 10씩 증가시켜가면서 21번의 시나리오를 생섬 및 실행하여 각 제품별 납기불만족 생산 수량, 전체 생산 수량 등을 도출할 수 있다. 이러한 정보가 고객에게 제공하게 되면, 전체 생산 수량이 더 이상 증가하지 않으면서 각 제품별 납기 불만족 생산 수량이 일정 수치 이하인 경우, 고객에게 A 제품은 1월 30일까지 X개 추가 생산 가능하다는 판단을 내릴 수 있게 된다. 이와 비슷한 방식으로 A 제품의 납기일을 변인으로 추가하여 정보를 제공하면 고객은 Y일까지 X개 추가 생산 가능하다는 판단을 내릴 수 있게 된다.Meanwhile, a fixed-size experimental design can include situations where both variables and variable values are fixed. Let's assume that when receiving an order from a customer, a projected production scenario is provided considering the current order quantity. For example, if orders for three products, A, B, and C, are currently 100, 100, and 100, respectively, by January 30th, an existing customer may request that the company produce as much of Product A as possible in addition to the existing order quantity. As a production planner, you need to be able to explain to the customer how much additional Product A you can produce and by when. In this case, the quantity of Product A among the orders for Products A, B, and C by January 30th can be set as a variable, and 21 scenarios can be generated and executed by increasing the quantity by 10 from 100 to 300, thereby deriving the number of unsatisfactory delivery times for each product and the total production quantity. If this information is provided to the customer, the customer can decide that X additional units of Product A can be produced by January 30th if the total production quantity no longer increases and the unsatisfactory delivery quantity for each product is below a certain level. Similarly, if the delivery date of Product A is provided as a variable, the customer can decide that X additional units can be produced by Y date.
또한, 고정크기 실험 설계는 변인은 정해져 있으나, 변인 값이 미정인 상태를 포함할 수 있다. 디스패칭 에이전트에서 N개의 특성을 사용하여 가중합(WeightSum), 가중치 정렬(WeightSort)를 수행할 경우, 특성 우선순위/특성 가중치를 변경하는 실험을 하는 경우를 가정하도록 한다. 예를 들어, FIFO/SETUP/DELAY 3가지 특헝으로 가중치 정렬을 하고, 우선순위가 작을수?? 우선시되는 상황에 있을 수 있다. 만들어질 수 있는 우선순위의 경우의 수는 1,2,3/1,3,2/2,1,3/3,1,2/3,2,1로 6가지에 해당할 수 있다(3개이므로 3!). 이 경우, 변인으로 3가지 특성의 우선순위 칸을 선택하고, 아직 정해지지 않은 특성 값은 순열에서 만들어지는 값을 입력할 수 있다. 이를 통해, 실험을 수행한 후 고객은 장비 교체 횟수가 가장 작았던 우선순위 조합을 최종 시나리오로 채택할 수 있다.Furthermore, fixed-size experimental designs can include situations where variables are fixed but variable values are unknown. For example, suppose a dispatching agent performs WeightSum and WeightSort using N features, and an experiment is conducted to change feature priorities/feature weights. For example, if weights are sorted using three features: FIFO/SETUP/DELAY, and a situation arises where a lower priority is given priority, the number of possible priorities is 1,2,3/1,3,2/2,1,3/3,1,2/3,2,1, which corresponds to six cases (three because there are three!). In this case, the priority boxes of the three features can be selected as variables, and the feature values that are not yet determined can be entered as values generated from the permutation. Through this, after conducting the experiment, the customer can select the priority combination that resulted in the fewest equipment replacements as the final scenario.
또한, 실험 수행이 완료된 경우,실험 요약 및 시나리오 결과가 획득될 수 있다.. 이때, 실험 요약은 변인 및 주요성능지표와 관련된 정보에 해당한다. 예를 들어, 실험 요약은 시나리오별 변인 값, 시나리오 실행을 통해 도출된 주요성능지표 값, 실행/종료된 시각, 실행 성공여부, 실행 순번 등을 포함할 수 있다. 적어도 하나의 주요성능지표가 실험에 등록된 경우, 기 설정된 계산 순서에 기초하여 주요성능지표 값이 도출될 수 있다. 상술한 바와 같이, 시나리오 결과는 단일 모델을 실행한 결과물로서 정제 로직에 의해 생성된 데이터, 생산 계획 데이터를 포함하는 출력 데이터를 포함할 수 있다.In addition, when the experiment is completed, an experiment summary and scenario results can be obtained. At this time, the experiment summary corresponds to information related to variables and key performance indicators. For example, the experiment summary may include variable values for each scenario, key performance indicator values derived through scenario execution, execution/end time, execution success or failure, execution order, etc. If at least one key performance indicator is registered in the experiment, the key performance indicator value can be derived based on a preset calculation order. As described above, the scenario result may include output data including data generated by refinement logic and production plan data as a result of executing a single model.
한편, 실험 수행의 경우, 시나리오의 실행 후 입/출력물의 적어도 일부에 대한 삭제여부가 매개변수로 사용될 수 있다. 이는, 모든 시나리오에 대해 모든 정보를 갖는 경우, 저장공간이 부족할 수 있기 때문이다. 또한, 실험 수행 후 실험 결과물을 데이터베이스(150)에 업로드 여부가 매개변수에 해당할 수 있다. 즉, 필요에 따라, 모든 실험 허브 정보를 압축한 파일, 실험 결과물 등을 데이터베이스(150)에 업로드할 수 있다.Meanwhile, when conducting experiments, whether to delete at least some of the input/output data after scenario execution can be used as a parameter. This is because, if all information for all scenarios is available, storage space may be insufficient. Furthermore, whether to upload the experimental results to the database (150) after conducting the experiment can be a parameter. That is, if necessary, a compressed file containing all experimental hub information, experimental results, etc. can be uploaded to the database (150).
도 42는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일을 생성하는 예를 개시하는 도면이다.FIG. 42 is a diagram disclosing an example of generating an experimental hub file based on a software model and logic set according to an embodiment.
상술한 바와 같이, 실험 설계는 고정 실험 설계 및 반복 실험 설계를 포함할 수 있다. 반복 실험 설계(Iterative Experiment Design)은 미리 등록된 변인을 대상으로 변인 값을 반복 단계 로직에 의해 결정하여 실험을 설계하는 것에 해당한다. 따라서, 매 실험 단계마다 실행되어야할 시나리오 수와 변인 값은 대응되는 반복 단계 로직에 기초하여 결정될 수 있다. 반복 실험 설계는 반복 단계 로직의 형태에 따라 적응형 실험 설계(Adaptive Experiment Design)을 구성할 수도 있다. 예를 들어, 적응형 실험 설계는 매 반복에 포함된 시나리오 결과에 기초하여 특정 주요성능지표가 개선되는 방향으로 다음 반복의 시나리오를 설계하는 경우에 해당한다. 이때, 방향은 특정 성능지표가 개선되기 위한 변인 값의 변화 방향을 의미하며 반복 단계 로직에서 사용되는 알고리즘에 기초하여 상이하게 적용될 수 있다.As described above, experimental designs can include fixed experimental designs and iterative experimental designs. Iterative experimental designs design experiments by determining variable values for pre-registered variables through iterative step logic. Therefore, the number of scenarios to be executed and variable values for each experimental step can be determined based on the corresponding iterative step logic. Depending on the form of the iterative step logic, iterative experimental designs can also be configured as adaptive experimental designs. For example, an adaptive experimental design designs scenarios for the next iteration based on the results of the scenarios included in each iteration, aiming to improve a specific key performance indicator. In this case, the direction refers to the direction of change in variable values for the improvement of a specific performance indicator, and can be applied differently based on the algorithm used in the iterative step logic.
또한, 반복 실험 설계는 매개 변수로 실험 종료 조건과 반복 단계 로직을 포함할 수 있다. 예를 들어, 실험 종료 조건은 반복 횟수, 목표 시간, 목표 성능치, 구동 시간 등을 포함할 수 있다.Additionally, a repeatable experimental design can include experimental termination conditions and iteration step logic as parameters. For example, experimental termination conditions can include the number of repetitions, target time, target performance value, and running time.
또한, 반복 실험 설계에 포함된 적어도 하나의 반복 단계 로직의 입력값 및 출력값은 사용자가 생성 방식을 지정한 임의의 값, 사용자가 입력한 초기 변인 값, 사용자가 입력한 로직 그 자체, 또는 로직에서 가정한 특정 분포에서 추출된 표본 등에 기초하여 결정될 수 있다.Additionally, the input and output values of at least one repetition step logic included in the repeated experiment design can be determined based on a random value that the user specifies as a generation method, an initial variable value input by the user, the logic itself input by the user, or a sample drawn from a specific distribution assumed in the logic.
반복 실험 설계의 실험 수행은 고정 실험 설계와 같이, 병렬 실행 수를 매개변수로 포함할 수 있다. 반복 실험 설계의 경우, 반복 단계에서 수행될 시나리오 수(L)이 병렬 실행 수(M)을 초과한다면, 병렬 실행 횟수는 Ceiling(L/M)로서, L을 M으로 나눠서 올림한 수만큼 병렬 실행을 발생시키고, 반복 단계 로직을 수행한 후 다음 반복 단계로 이동할 수 있다.Experimental execution in a repeatable design, like in a fixed-experiment design, can include the number of parallel runs as a parameter. In a repeatable design, if the number of scenarios (L) to be performed in an iteration step exceeds the number of parallel runs (M), the number of parallel runs is set to a ceiling (L/M), which is the number of parallel runs equal to L divided by M and rounded up. After executing the iteration step logic, the program can move on to the next iteration step.
도 42을 참조하면, 실험 설계2(780)는 반복 실험 설계로서, 변인 및 주요 성능 지표의 조합으로 구성될 수 있다. 이 경우, 변인에 대한 변인 값은 초기 값이 임의로 지정되거나 이전에 반복 단계 로직에서 도출된 변인 값을 사용할 수 있으며, 이는 이전에 설정된 변인에 종속되지 않는 값으로서 반복 단계 로직에 영향을 받는 값에 해당한다. 또한, 실험 수행 2(785)는 실험 설계2(780)에 포함된 정보에 기초하여 최초 반복 단계에서 복수의 시나리오에 대하여 병렬 실행(787)을 수행하고, 병렬 실행의 결과를 매개변수로 전달받아 반복 단계 로직(789)을 수행한 후 다음 반복 단계로 이동할 수 있다. 이때, 반복 단계 로직(789)에서는 다음 반복에서 수행되어야할 시나리오 수 및 변인 값이 결정될 수 있다. 반복 단계 로직(789)에서 결정된 값에 따라, 다음 반복 단계에서도 병렬 실행을 수행하고, 반복 단계 로직을 수행한 후 다음 반복 단계로 이동하는 순서가 반복될 수 있다.Referring to Fig. 42, Experimental Design 2 (780) is a repeatable experimental design and may be composed of a combination of variables and key performance indicators. In this case, the variable values for the variables may be arbitrarily assigned as initial values or may use variable values derived from the previous repeatable step logic, which correspond to values that are not dependent on previously set variables and are affected by the repeatable step logic. In addition, Experimental Execution 2 (785) may perform parallel execution (787) on multiple scenarios in the first repeatable step based on the information included in Experimental Design 2 (780), receive the results of the parallel execution as parameters, perform the repeatable step logic (789), and then move to the next repeatable step. At this time, the repeatable step logic (789) may determine the number of scenarios and variable values to be performed in the next iteration. Depending on the values determined in the repeatable step logic (789), the order of performing parallel execution in the next repeatable step, performing the repeatable step logic, and then moving to the next repeatable step may be repeated.
도 43는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 실험을 실행하는 예를 개시하는 도면이다.FIG. 43 is a diagram disclosing an example of executing an experiment based on a software model and logic set according to an embodiment.
실험허브부는 실험허브 편집부, 실험허브 분석부 및 실험허브 실행부를 포함할 수 있다. 이는 클라이언트 제조공정시스템의 실험허브부(140) 및 온프레미스 컴퓨팅 시스템의 실험허브부(1500)에서 동일하게 구성될 수 있다.The experimental hub section may include an experimental hub editing section, an experimental hub analysis section, and an experimental hub execution section. These sections may be configured identically in the experimental hub section (140) of the client manufacturing process system and the experimental hub section (1500) of the on-premise computing system.
온프레미스 컴퓨팅 시스템(1000)의 경우, 실험허브부(1500)의 실험허브분석부에서 실험허브 파일을 매개변수로 실험허브 실행부에 전달할 수 있다. 또한, 클라이언트 제조공정시스템(100)의 경우, 실험허브 편집부를 통해 편집된 실험허브 파일이 시스템운영부(110)의 작업스케쥴러서비스부(1230)를 통해 실험허브 파일을 매개변수로 실험허브 실행부(143)에 전달할 수 있다. 또한 실험허브 파일에 포함된 적어도 하나의 실험 중 어떤 실험을 실행할 지 여부에 대해서도 매개변수로 전달될 수 있다. 즉, 이 경우, 실험허브 실행부도 동시에 여러 개가 호출될 수 있다. 예를 들어, 실험허브 실행부가 하나의 실험허브 파일에 포함된 복수의 실험을 병렬로 처리하도록 하거나, 복수의 실험들 간의 순서를 매개변수로 전달할 수 있다.In the case of an on-premise computing system (1000), the experiment hub analysis unit of the experiment hub unit (1500) can pass the experiment hub file as a parameter to the experiment hub execution unit. In addition, in the case of a client manufacturing process system (100), the experiment hub file edited by the experiment hub editing unit can be passed as a parameter to the experiment hub execution unit (143) through the task scheduler service unit (1230) of the system operation unit (110). In addition, whether to execute which experiment among at least one experiment included in the experiment hub file can also be passed as a parameter. That is, in this case, multiple experiment hub execution units can be called simultaneously. For example, the experiment hub execution unit can process multiple experiments included in one experiment hub file in parallel, or can pass the order between multiple experiments as a parameter.
이하의 실험허브 실행부에서 수행되는 동작들은 클라이언트 제조공정시스템 및 온프레미스 컴퓨팅 시스템에서 동일하게 수행되는 것에 해당한다. 먼저, 시나리오 파일이 생성되고 변인 값이 적용될 수 있다(S610). 예를 들어, 생성되는 시나리오 파일은 기초가 되는 모델타입 변수의 모델을 복사하고 변인 값을 일부 변경하여 생성될 수 있다. 한편, 반복 실험 설계의 경우, 반복 실험 로직이 먼저 수행된 이후에 S610 단계가 수행될 수 있다.The following operations performed in the Experimental Hub execution unit correspond to those performed identically in the client manufacturing process system and on-premise computing system. First, a scenario file is created and variable values can be applied (S610). For example, the generated scenario file can be created by copying the underlying model type variable model and modifying some variable values. Meanwhile, in the case of a repeatable experimental design, the repeatable experiment logic may be executed first, followed by step S610.
상술한 바와 같이 변인 값의 개수에 따라 시나리오 파일이 생성되고, 생성된 적어도 하나의 시나리오 파일은 시나리오 저장소(771)에 저장될 수 있다. 또한, 시나리오 저장소(771)에 저장된 적어도 하나의 시나리오 파일은 아직 실행되지 않은 상태에 해당한다.As described above, a scenario file is generated based on the number of variable values, and at least one generated scenario file can be stored in the scenario storage (771). In addition, at least one scenario file stored in the scenario storage (771) corresponds to a state that has not yet been executed.
다음으로, 적어도 하나의 시나리오 파일에 대하여 모델 실행부에 시나리오 수행 명령이 전달될 수 있다(S615). 도 43에 도시된 바와 같이, 예를 들어, 적어도 하나의 시나리오 파일은 하나의 모델 실행부에서 모두 실행될 수 있다. 또한, 예를 들어, 적어도 하나의 시나리오 파일 각각은 대응되는 모델 실행부가 지정되어 병렬로 실행될 수 있다.Next, a scenario execution command can be transmitted to the model execution unit for at least one scenario file (S615). As illustrated in Fig. 43, for example, at least one scenario file can be executed entirely by a single model execution unit. Furthermore, for example, each of at least one scenario file can be designated with a corresponding model execution unit and executed in parallel.
또한, 모델 실행부의 시나리오 수행 명령에 따라, 적어도 하나의 시나리오가 수행될 수 있다(S620). 이때, 상술한 바와 같이, 선택에 따라 시나리오 수행 뿐만 아니라 실험 정제 로직이 수행될 수 있다. 예를 들어, 실험 정제 로직에 시나리오 결과를 매개변수로 사용하게 되면, 실험 정제 로직에 따라 시나리오를 정제하고 실험을 정제할 수 있다. 또한, 도 43에 도시된 바와 같이, 시나리오 결과, 시나리오 정제 결과, 실험 정제 결과는 결과물 저장소(772)에 저장될 수 있다. 이때, 결과물 저장소(772)에 저장되는 데이터는 결과 데이터(1266)에 해당할 수 있다. 예를 들어, 시나리오 결과는 단일 모델을 실행한 결과 데이터, 로그 데이터 등을 포함할 수 있다.In addition, at least one scenario can be executed according to a scenario execution command of the model execution unit (S620). At this time, as described above, in addition to scenario execution, experimental refinement logic can be executed depending on the selection. For example, if the scenario result is used as a parameter in the experimental refinement logic, the scenario can be refined and the experiment can be refined according to the experimental refinement logic. In addition, as illustrated in FIG. 43, the scenario result, the scenario refinement result, and the experimental refinement result can be stored in the result storage (772). At this time, the data stored in the result storage (772) may correspond to the result data (1266). For example, the scenario result may include result data from executing a single model, log data, etc.
다음으로, 시나리오 결과에 기초하여, 주요성능지표가 계산되어 주요성능지표 값이 도출될 수 있다(S625). 예를 들어, 주요성능지표 값은 스칼라 또는 벡터로 표시될 수 있다. 주요성능지표 값은 실험 요약(774)에 포함될 수 있고, 시나리오별 변인 값, 실행/종료된 시각, 실행 성공여부, 실행 순번 등이 함께 포함될 수 있다.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 expressed as scalars or vectors. KPI values can be included in the experiment summary (774), which can also include scenario-specific variable values, execution/end times, execution success/failure, and execution order.
온프레미스 컴퓨팅시스템(1000)의 실험허브(1500)의 경우, 실험 요약(774)은 실험허브 파일(773)에 저장될 수 있으며, 경우에 따라, 실험허브 파일(773)의 원본 파일이 수정될 수 있다. 또한, 클라이언트 제조공정시스템(100)의 실험허브(140)의 경우, 실험 요약(774)은 결과 데이터(1266)으로 전송될 수 있다.In the case of an experiment hub (1500) of an on-premise computing system (1000), an experiment summary (774) may be stored in an experiment hub file (773), and in some cases, the original file of the experiment hub file (773) may be modified. In addition, in the case of an experiment hub (140) of a client manufacturing process system (100), an experiment summary (774) may be transmitted as result data (1266).
결과물 저장소(772)에 저장된 파일은 대용량에 해당되므로, 설정에 따라, 저장소의 파일이 삭제 수 있다(S630). 다만, 저장소의 파일 삭제는 필수사항이 아니며, 저장소의 파일이 삭제되지 않고 그대로 남아있는 경우도 가능하다.Since the files stored in the result storage (772) are large in size, the files in the storage may be deleted (S630) depending on the settings. However, deleting the files in the storage is not mandatory, and it is possible for the files in the storage to remain as they are without being deleted.
다음으로, 실험 결과가 데이터베이스에 업로드 될수 있다(S635). 또한, 수행된 실험이 반복 실험 설계에 의한 경우, 반복 실험 로직을 따르게 될 수 있고, 다시 S610 단계부터 반복될 수 있다.Next, the experimental results can be uploaded to the database (S635). Additionally, if the experiment was performed using a repeatable experimental design, the repeatable experimental logic can be followed, and the process can be repeated from step S610.
도 44는 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하는 실험허브 파일에 대한 정보를 출력하는 예를 개시하는 도면이다.FIG. 44 is a diagram disclosing an example of outputting information about an experimental hub file based on a software model and logic set according to an embodiment.
실험허브 파일이 생성된 이후, 실험을 설계하고 설계된 실험을 수행하게 되는 경우, 실험 결과에 대하여 확인할 수 있는 사용자 인터페이스가 제공될 수 있다. 예를 들어, 결과 확인은 별도의 사용자 인터페이스를 제공하거나 웹상에서 아웃바운드API를 통해 제공될 수 있다. 이밖에도, 실험이 수행되는 경우, 결과물은 데이터베이스(150)에 자동으로 업로드하는 것이 가능하다.After the experimental hub file is created, a user interface can be provided to check the experimental results when designing and performing the designed experiment. For example, results can be checked through a separate user interface or via an outbound API on the web. Additionally, when an experiment is performed, the results can be automatically uploaded to a database (150).
실험요약 파일은 실험허브의 요약을 포함하는 별개의 파일로 존재할 수 있고, 다양한 종류의 정보로서, 변인, 주요 성능 지표, 실험 설계, 실험 수행과 관련된 정보를 포함할 수 있다. 뿐만 아니라, 주요 성능 지표의 결과물, 변인/변인 값 및 주요 성능 지표의 조합, 실험 수행 결과물 등을 포함할 수 있다.The experiment summary file can exist as a separate file containing a summary of the experiment hub. It can contain various types of information, including variables, key performance indicators, experimental design, and experimental execution. It can also include key performance indicator results, variables/variable values, key performance indicator combinations, and experiment execution results.
또한, 실험 허브에 포함된 변인, 주요성능지표, 실험 설계, 실험 수행에 대한 정보는 다른 실험 허브에서 불러오기를 통해 활용될 수 있다. 예를 들어, A 고객에 대하여 실험허브1(790)를 생성하면서, 변인, 주요 성능 지표, 실험 설계, 실험 수행에 대한 시나리오 파일이 생성된 상태에서, A 고객에 대하여 새로운 실험허브인 실험허브2(795)를 생성하게 될 수 있다. 이 경우, A 고객에 대하여 변인, 주요 성능 지표 등을 새롭게 생성하지 않고, 실험허브 1(790)에서 생성 및 사용되었던 변인/변인 값 정보 파일, 성능지표 함수 정보 파일, 실험 설계 파일, 실험 수행 결과물 파일 등을 내보내기 절차를 수행하거나 실험허브 2(795)에서 불러오기 절차를 수행하여, 실험허브 2(795)에서 실험허브 1(790)의 자료를 사용하여, 재사용성을 확보할 수 있다.In addition, information about variables, key performance indicators, experimental design, and experimental execution included in an experimental hub can be utilized by importing from another experimental hub. For example, when creating Experimental Hub 1 (790) for Customer A, scenario files for variables, key performance indicators, experimental design, and experimental execution can be created, and then a new Experimental Hub, Experimental Hub 2 (795), can be created for Customer A. In this case, instead of newly creating variables, key performance indicators, etc. for Customer A, the variable/variable value information file, performance indicator function information file, experimental design file, and experimental execution result file that were created and used in Experimental Hub 1 (790) can be exported or imported into Experimental Hub 2 (795), thereby ensuring reusability by using the data of Experimental Hub 1 (790) in Experimental Hub 2 (795).
도 45은 실시 예에 따른 소프트웨어 모델 및 로직 세트에 기반하여 실험허브부에서 실험을 수행하고 실행하는 예를 개시하는 도면이다.FIG. 45 is a diagram disclosing an example of performing and executing an experiment in an experimental hub based on a software model and logic set according to an embodiment.
상술한 바와 같이 실험허브부(140)는 실험허브 편집부(141), 실험허브 실행부(142) 및 실험허브 분석부(143)를 포함할 수 있다. 실험허브 편집부는 실험허브 파일(1250)을 생성하고 변인 및 주요성능지표 등을 편집하여, 실험허브 저장부(1250)에 포함된 실험허브 파일을 시스템운영부(110)에 업로드할 수 있고, 실험허브 실행부는 시스템운영부(110)에 업로드된 실험허브 파일을 실행시킬 수 있고, 실험허브 분석부는 실험허브 결과 파일(1266)을 분석할 수 있다.As described above, the experiment hub unit (140) may include an experiment hub editing unit (141), an experiment hub execution unit (142), and an experiment hub analysis unit (143). The experiment hub editing unit may create an experiment hub file (1250), edit variables and key performance indicators, etc., and upload the experiment hub file included in the experiment hub storage unit (1250) to the system operation unit (110). The experiment hub execution unit may execute the experiment hub file uploaded to the system operation unit (110), and the experiment hub analysis unit may analyze the experiment hub result file (1266).
모델실행부의 출력 파일(1280) 중 로그파일(1283)은 운영시스템의 로그이고, 작업스케쥴러 서비스부(job scheduler service)(1230)이 기록하는 로그에 해당한다. 출력 파일 (1280) 중 결과 데이터(1286)은 모델실행부(130)가 단일 모델을 수행한 결과에 대한 모델 로그 및 단일 모델에 대한 생산 계획 데이터를 포함할 수 있다. 실험허브 실행부의 출력파일(1260) 중 로그파일(1263)은 운영시스템의 로그이고, 작업스케쥴러 서비스부(job scheduler service)(1230)이 기록하는 실험허브에 대한 로그에 해당한다. 출력 파일(1260) 중 결과 데이터(1266)은 복수의 모델 실행부가 수행한 결과에 대한 로그 및 복수의 모델에 대한 생산 계획 데이터를 포함할 수 있다. 상술한 바와 같이, 실험허브부(140)는 실험 허브를 생성하고, 적어도 하나의 모델타입 변인과 적어도 하나의 로직타입 변인을 등록하고, 모델의 변인, 변인 값 및 주요 성능 지표를 생성한 후, 이를 바탕으로 실험 설계를 생성할 수 있다.Among the output files (1280) of the model execution unit, the log file (1283) is a log of the operating system and corresponds to a log recorded by the job scheduler service (1230). The result data (1286) among the output files (1280) may include a model log for the result of the model execution unit (130) executing a single model and production plan data for the single model. Among the output files (1260) of the experiment hub execution unit, the log file (1263) is a log of the operating system and corresponds to a log for the experiment hub recorded by the job scheduler service (1230). The result data (1266) among the output files (1260) may include a log for the result of the execution of multiple model execution units and production plan data for multiple models. As described above, the experimental hub unit (140) can create an experimental hub, register at least one model type variable and at least one logic type variable, create model variables, variable values, and key performance indicators, and then create an experimental design based on the same.
실험허브부(140)는 생성된 실험 설계를 시스템운영부(110)의 배포관리서비스부(deploy management service)(1215)를 통해 실험허브 저장부(1250)에 실험 허브 파일을 업로드할 수 있다.The experimental hub unit (140) can upload the generated experimental design to the experimental hub storage unit (1250) through the deployment management service unit (1215) of the system operation unit (110).
시스템 운영부(110)의 작업서비스부(1210)는 운영작업, 운영작업의 주기 등을 생성하는 파트에 해당하고, 작업스케쥴러 서비스부(job scheduler service(1230)는 작업서비스부(1201)에서 편집된 운영작업을 실행조건에 따라 실행시키는 파트에 해당한다.The job service section (1210) of the system operation section (110) corresponds to a part that creates operation tasks, cycles of operation tasks, etc., and the job scheduler service section (1230) corresponds to a part that executes operation tasks edited in the job service section (1201) according to execution conditions.
또한, 실험허브 저장부(1250)는 모델개발부(1100)로부터 수신된 적어도 하나의 소프트웨어 모델 및 적어도 하나의 로직 세트를 저장할 수 있다. 또한, 배포관리서비스부(1215)에서 제공하는 배포관리서비스는 배포(업로드)가 발생할 때 실험허브 저장부(1250)에 배포 대상이 속한 프로젝트별 경로에 파일을 저장할 수 있다. 이때, 배포관리서비스부(1215)는 파일을 저장 시 배포 시점 별로 소프트웨어 모델 및 로직세트의 이력 관리를 제공할 수 있다.In addition, the experiment hub storage unit (1250) can store at least one software model and at least one logic set received from the model development unit (1100). In addition, the distribution management service provided by the distribution management service unit (1215) can store files in the path for each project to which the distribution target belongs in the experiment hub storage unit (1250) when distribution (upload) occurs. At this time, the distribution management service unit (1215) can provide history management of the software model and logic set by distribution time when storing the file.
실험허브 저장부(1250)에 저장된 실험 허브 파일은 실험허브부(140)의 실행 명령에 따라, 모델 실행부(130)에서 실험 수행이 이루어질 수 있다. 즉, 모델 실행부(130)는 시스템운영부(110)에 업로드된 단일 모델을 실행할 수 있고, 실험허브부(140)의 실험허브 실행부는 실험허브에 기록된 정보에 기초하여 복수의 모델 실행부(130)를 순차적으로 또는 동시에 호출하게 할 수 있다. .The experiment hub file stored in the experiment hub storage unit (1250) can be used to perform experiments in the model execution unit (130) according to the execution command of the experiment hub unit (140). That is, the model execution unit (130) can execute a single model uploaded to the system operation unit (110), and the experiment hub execution unit of the experiment hub unit (140) can sequentially or simultaneously call multiple model execution units (130) based on information recorded in the experiment hub.
모델실행부(130)는 작업스케쥴러서비스부(1230)의 실행 지시에 따라, 운영작업을 실행하여 출력 파일(1280)을 생성할 수 있다. 이때, 출력 파일(1280)은 생산 계획 데이터를 아웃풋 파일(1286)로서 포함할 수 있고, 운영작업이 실행된 결과에 대한 로그파일(1283)을 포함할 수 있다.The model execution unit (130) can execute an operation task according to the execution instructions of the task scheduler service unit (1230) and generate an output file (1280). At this time, the output file (1280) can include production plan data as an output file (1286) and a log file (1283) regarding the results of the execution of the operation task.
모델 실행부(130)에서 실행된 실험허브 파일은 그 결과물이 실험허브부(140)로 전달하고, 실험허브부(140)는 출력파일(1260)로서 실험허브 아웃풋 파일(1266)을 생성할 수 있다. 또한, 실험 허브 수행에 대한 로그파일(1263)도 함께 생성될 수 있다.The experimental hub file executed in the model execution unit (130) transmits its results to the experimental hub unit (140), and the experimental hub unit (140) can generate an experimental hub output file (1266) as an output file (1260). In addition, a log file (1263) for the execution of the experimental hub can also be generated.
출력 파일(1280)은 클라이언트의 제조공정시스템(100)의 데이터베이스(150)에 업로드될 수 있다. 또한, 실험허브 수행 결과물인 출력파일(1260)은 클라이언트 제조공정시스템의 데이터베이스(150)에 업로드될 수 있다. 업로드시에 모델 압축 파일(1286) 형태 또는 실헙허브 압축 파일(1266) 형태로 업로드하거나 결과 자체를 압축시키지않고 업로드하는 것도 가능하다.The output file (1280) can be uploaded to the database (150) of the client's manufacturing process system (100). In addition, the output file (1260), which is the result of the experiment hub execution, can be uploaded to the database (150) of the client's manufacturing process system. When uploading, it is possible to upload in the form of a model compressed file (1286) or an experiment hub compressed file (1266), or to upload without compressing the result itself.
한편, 출력파일(1260,1280)은 클라이언트 제조공정시스템(100)에 포함된 조회 인터페이스 또는 외부파일서비스부(1220)를 통해 결과물을 제공하여 모델분석부(1300) 또는 실험허브부(140)의 실험허브 분석부에서 조회할 수 있게 된다.Meanwhile, the output files (1260, 1280) 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 searched in the model analysis unit (1300) or the experiment hub analysis unit of the experiment hub unit (140).
도 46은 실시 예에 따른 실험 허브를 생성하고 수행하는 예를 개시하는 흐름도이다.Figure 46 is a flowchart disclosing an example of creating and performing an experimental hub according to an embodiment.
상술한 바와 같이, 실험허브부(140)는 실험허브 파일을 생성할 수 있다(S720). 보다 상세하게는, 실험허브부(140)의 구성 중 실험허브편집부에서 실험허브 파일이 생성될 수 있다. 실험허브 파일은 실험을 편집 또는 실행하기 위한 대상에 해당하며, 저장 경로가 매개변수로 설정될 수 있다.As described above, the experiment hub unit (140) can generate an experiment hub file (S720). More specifically, the experiment hub file can be generated in the experiment hub editing unit within the experiment hub unit (140). The experiment hub file corresponds to a target for editing or executing an experiment, and its storage path can be set as a parameter.
다음으로, 실험허브부(140)는 생성된 실험허브 파일에 적어도 하나의 모델타입 변인과 적어도 하나의 로직타입 변인을 등록할 수 있다(S730). 도 37에 도시된 바와 같이, 실험 허브를 통한 실험이 진행되기 위해서는 적어도 하나의 모델과 적어도 하나의 로직이 실험허브 파일에 등록되는 것이 필요하다. 또한, 등록된 적어도 하나의 모델 및 적어도 하나의 로직은 변인에 해당할 수 있다.Next, the experiment hub unit (140) can register at least one model type variable and at least one logic type variable in the generated experiment hub file (S730). As illustrated in Fig. 37, in order for an experiment to proceed through the experiment hub, at least one model and at least one logic must be registered in the experiment hub file. Additionally, at least one registered model and at least one logic may correspond to a variable.
또한, 실험허브부(140)는 실험허브 파일에 데이터 타입 변인, 변인 값과 주요성능지표를 생성할 수 있다(S740). 예를 들어, 데이터 타입 변인은 단일 칸(cell)에 해당할 수 있다. 단일 칸은 모델 전역변수 및 데이터 스키마에 존재하는 키(key)를 통해 특정될 수 있다. 또한, 변인 값은 개별 데이터의 타입에 따라 결정된다. 또한, 예를 들어, 데이터 타입 변인은 모델의 모든 입력 데이터 테이블에 해당할 수 있다. 예를 들어, 입력데이터 테이블 변인이 등록되면 변인 값의 타입은 해당 입력데이터 테이블과 동일한 스키마를 갖는 테이블 타입이 될 수 있다. 이 경우, 사용자는 내부 데이터를 모델타입 변인의 원본 데이터 테이블에서 불러오거나 외부 파일로부터 불러올 수 있다. 또한, 입력한 데이터 테이블에서 적어도 1개 이상의 수정 사항을 반영한 테이블을 변인 값으로 활용할 수 있다.In addition, the experiment hub unit (140) can create data type variables, variable values, and key performance indicators in the experiment hub file (S740). For example, a data type variable may correspond to a single cell. A single cell may be specified through a key existing in the model global variable and data schema. In addition, variable values are determined according to the type of individual data. In addition, for example, a data type variable may correspond to all input data tables of the model. For example, when an input data table variable is registered, the type of the variable value may be a table type having the same schema as the corresponding 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. In addition, a table reflecting at least one modification in the input data table can be used as a variable value.
주요성능지표는 실험에 포함된 시나리오의 입력 데이터와 결과 데이터에 포함된 정보를 가공하는 함수 정보에 해당한다. 주요성능지표의 값은 실험 결과에 따라 나타나는 수치 데이터에 해당한다.Key performance indicators (KPIs) represent function information that processes information contained in the input and output data of the scenarios included in the experiment. The values of KPIs correspond to numerical data that appear based on the experimental results.
한편, 선택에 따라, 시나리오 별 또는 실험 별 결과 정제 로직을 설정할 수 있다(S745). 도 40에 도시된 바와 같이, 모델 개발부에 정의된 스키마로 원하는 결과를 얻기 어려운 경우, 결과 정제 로직을 활용하여 스키마를 별도로 만들어 결과를 도출할 수 있다.Meanwhile, depending on your choice, result refinement logic can be set for each scenario or experiment (S745). As illustrated in Figure 40, if it is difficult to obtain the desired results with the schema defined in the model development unit, the result refinement logic can be used to create a separate schema and derive the results.
또한, 실험허브 파일에 등록된 변인 및 주요성능지표 정보에 기초하여 실험을 설계할 수 있다(S750). 예를 들어, 등록된 변인 정보는 상술한 모델타입 변인, 로직타입 변인, 데이터 타입 변인, 변인 값을 포함할 수 있다. 상술한 바와 같이, 실험 설계는 고정 실험 설계 및 반복 실험 설계를 포함할 수 있다. 고정 실험 설계 및 반복 실험 설계에서 동시에 실행할 수 있는 시나리오 수에 해당하는 병렬 실행 수는 설정될 수 있다.Additionally, experiments can be designed based on the variable and key performance indicator information registered in the experimental hub file (S750). For example, the registered variable information may include the model type variables, logic type variables, data type variables, and variable values described above. As described above, the experimental design may include a fixed experimental design and a repeated experimental design. In the fixed experimental design and the repeated experimental design, the number of parallel executions corresponding to the number of scenarios that can be executed simultaneously can be set.
다음으로, 설계된 실험을 수행할 수 있다(S760). 도 44를 참조하면, 실험허브부의 실험허브 편집부는 설계된 실험허브 파일을 생성하여 시스템 운영부에 업로드하고, 실험허브 실행부는 생성된 실험허브 파일에 입력된 정보를 기반으로 시나리오를 생성하고 각 시나리오에 대응하는 파일을 모델 실행부(130)에 매개변수로 전달하여 실행될 수 있도록 한다. . 또한, 모델 실행부는 결과 데이터를 실험허브 실행부에 전송하고, 클라이언트 제조공정시스템의 경우, 실험허브 실행부는 결과 데이터를 시스템운영부에 전송할 수 있다. 또한, 시스템 운영부는 실험 수행 결과를 데이터베이스에 업로드 하거나 모델분석부 또는 실험허브부의 분석부를 통해 결과를 출력할 수 있다.Next, the designed experiment can be performed (S760). Referring to FIG. 44, the experiment hub editing section of the experiment hub section creates a designed experiment hub file and uploads it to the system operation section, and the experiment hub execution section creates a scenario based on the information entered in the created experiment hub file and transmits a file corresponding to each scenario as a parameter to the model execution section (130) so that it can be executed. In addition, the model execution section transmits the result data to the experiment hub execution section, and in the case of a client manufacturing process system, the experiment hub execution section can transmit the result data to the system operation section. In addition, the system operation section can upload the experiment execution results to a database or output the results through the model analysis section or the analysis section of the experiment hub section.
실험 허브를 활용하는 경우, 단일 모델에 대한 실행을 수행하는 것에 비해 복잡한 작업을 용이하게 수행할 수 있다. 또한, 실험 허브를 통해, 주요성능지표를 통해 결과물이 자동으로 요약되고, 병렬 실행을 통한 시간 절약 등이 가능하다.Leveraging the Experiment Hub facilitates complex tasks compared to running experiments on a single model. Furthermore, the Experiment Hub automatically summarizes results using key performance indicators and enables time savings through parallel execution.
도 47는 실시 예에 따른 디지털 생산 계획 정보를 제공하는 방법을 개시하는 흐름도이다.FIG. 47 is a flowchart disclosing a method for providing digital production planning information according to an embodiment.
클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나를 기반으로 생성된 적어도 하나의 소프트웨어 모델 및 적어도 하나의 모델 로직을 온프레미스 컴퓨팅시스템으로부터 수신할 수 있다(S770). 상술한 바와 같이, 모델개발부에서 생성된 소프트웨어 모델 및 로직 세트는 서버관리부를 통해 시스템운영부에 업로드될 수 있다.At least one software model and at least one model logic set generated based on at least one of the data schema and library engine sets of the client manufacturing system can be received from the on-premise computing system (S770). As described above, the software model and logic set generated by the model development unit can be uploaded to the system operation unit via the server management unit.
적어도 하나의 소프트웨어 모델 및 적어도 하나의 모델 로직을 포함하는 실험을 생성할 수 있다(S780). 상술한 바와 같이, 실험을 생성하는 것은, 실험허브 파일을 생성하고, 변인 및 주요성능지표를 등록하고, 실험을 설계하는 것을 포함할 수 있다.An experiment including at least one software model and at least one model logic can be created (S780). As described above, creating the experiment may include creating an experiment hub file, registering variables and key performance indicators, and designing the experiment.
입력데이터를 기반으로, 생성된 실험을 수행하여 적어도 하나의 생산 계획 데이터를 제공할 수 있다(S790). 보다 상세하게는, 적어도 하나의 생산 계획 데이터는 수행된 실험의 결과인 실험 요약 및 시나리오 결과를 포함할 수 있다. 예를 들어, 입력데이터는 클라이언트 제조생산시스템의 상태를 나타내는 데이터로서, 일정한 형식과 내용을 포함한 특정 시점의 데이터를 포함할 수 있다. 또한, 예를 들어, 실험허브에서 입력데이터는 모델실행부(130)에 입력되는 입력데이터 중 적어도 일부가 변인으로 지정되어 실험 설계에 따라 일부 변경된 입력데이터에 해당할 수 있다. 상술한 바와 같이, 설계된 적어도 하나의 실험을 수행하여 적어도 하나의 실험 요약 및 적어도 하나의 시나리오 결과를 포함하는 적어도 하나의 생산 계획 데이터 를 제공할 수 있다. 또한, 정제 로직을 통해 추가로 획득된 정제 결과가 실험 요약에 포함되어 제공될 수 있다. 이와 관련하여, 상술한 도 36 내지 도 45를 참고하도록 한다.Based on the input data, at least one production plan data can be provided by performing the generated experiment (S790). More specifically, at least one production plan data can include an experiment summary and a scenario result, which are the results of the performed experiment. For example, the input data is data indicating the status of the client manufacturing production system and can include data at a specific point in time with a certain format and content. In addition, for example, in the experiment hub, the input data may correspond to input data that has been partially changed according to the experiment design by designating at least some of the input data input to the model execution unit (130) as variables. As described above, at least one designed experiment can be performed to provide at least one production plan data including at least one experiment summary and at least one scenario result. In addition, the refined result additionally acquired through the refinement logic can be included in the experiment summary and provided. In this regard, reference is made to FIGS. 36 to 45 described above.
시나리오 결과는 단일 모델을 실행한 결과 데이터, 로그 데이터 등을 포함하는 출력 데이터를 포함한다. 또한, 실험 요약은 시나리오별 변인 값, 시나리오 실행을 통해 도출된 주요성능지표 값, 실행/종료된 시각, 실행 성공여부, 실행 순번 등을 포함할 수 있다. 또한, 상술한 실험 요약 및 시나리오 결과는 데이터베이스에 업로드 되거나 모델분석부 또는 실험허브부의 분석부로 전송될 수 있다.Scenario results include output data, including the results of executing a single model, log data, and more. Furthermore, the experiment summary may include variable values for each scenario, key performance indicators derived from the scenario execution, execution/end times, success/failure of the execution, and the execution order. Furthermore, the aforementioned experiment summary and scenario results can be uploaded to a database or transmitted to the analysis unit of the model analysis unit or experiment hub.
도 29을 참조하여 실험 허브를 포함하는 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 설명하면 다음과 같다.Referring to FIG. 29, an embodiment of a device providing digital production planning information including an experimental hub is described as follows.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(410), 저장장치(420), 인메모리(430), 프로세서(440), 출력부(450), 및 사용자인터페이스(460)를 포함할 수 있다. 예를 들어, 디지털 생산 계획 정보를 제공하는 장치는 클라이언트의 제조생산시스템에 해당할 수 있다.An embodiment of a device providing digital production plan information may include an input unit (410), a storage unit (420), an in-memory unit (430), a processor (440), an output unit (450), and a user interface (460). For example, the device providing digital production plan information may correspond to a client's manufacturing production system.
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(460)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (460).
입력부(410)는 클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나를 기반으로 생성된 소프트웨어 모델 및 로직 세트를 온프레미스 컴퓨팅 시스템으로부터 수신할 수 있다.The input unit (410) can receive a software model and logic set generated based on at least one of the data schema and library engine set of the client manufacturing production system from the on-premise computing system.
저장장치(420)는 미리 준비된 기준정보를 저장하거나 수신된 소프트웨어 모델 및 로직 세트를 저장할 수 있다. 저장장치(420)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다.The storage device (420) can store pre-prepared reference information or store received software models and logic sets. The storage device (420) can include volatile memory or non-volatile memory.
인메모리(430)는 위에서 개시한 소프트웨어 모델, 입력데이터, 라이브러리 엔진 세트 및 라이브러리 엔진, 모델 실행부 및 실험허브부를 통해 수행하는 과정에서 얻어진 산물을 저장할 수 있다. 라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다.In-memory (430) can store the software model, input data, library engine set, and products obtained during the process performed through the library engine, model execution unit, and experiment hub unit disclosed above. The library engine set can include a production planning engine, which is a number of encapsulated function block files that generate a production plan.
실시예의 프로세서(440)는 적어도 하나의 소프트웨어 모델 및 적어도 하나의 모델 로직을 포함하는 실험허브를 생성할 수 있다. 프로세서(440)는 실험허브 파일을 생성하고, 생성된 실험파일에 적어도 하나의 모델타입 변인과 적어도 하나의 로직타입 변인을 실험허브 파일에 등록할 수 있다. 또한, 프로세서(440)는 실험허브 파일에 데이터 타입 변인, 변인 값 및 주요성능지표를 생성할 수 있다. 프로세서(440)는 변인 정보 및 주요성능지표 정보에 기초하여 실험을 설계할 수 있다. 이때, 설계된 실험은 고정 실험 설계 또는 반복 실험 설계로 구성될 수 있다. 상세한 예시는 도 38 내지 도 42에 개시하였다. 그리고 실시예의 프로세서(440)는 입력데이터를 기반으로, 생성된 실험을 수행하여 실험 결과에 해당하는 생산 계획 데이터를 얻을 수 있다. 이와 관련하여, 상술한 도 36 내지 도 45를 참고하도록 한다.The processor (440) of the embodiment can generate an experiment hub including at least one software model and at least one model logic. The processor (440) can generate an experiment hub file and register at least one model type variable and at least one logic type variable in the generated experiment file. In addition, the processor (440) can generate data type variables, variable values, and key performance indicators in the experiment hub file. The processor (440) can design an experiment based on the variable information and key performance indicator information. At this time, the designed experiment can be configured as a fixed experiment design or a repetitive experiment design. Detailed examples are disclosed in FIGS. 38 to 42. In addition, the processor (440) of the embodiment can perform the generated experiment based on input data to obtain production plan data corresponding to the experiment results. In this regard, reference is made to FIGS. 36 to 45 described above.
실시 예의 프로세서(440)는 설계된 실험을 실행하여, 아웃풋 파일 및 실험허브 작업의 실행 상황에 대한 로그 파일을 생성할 수 있다.The processor (440) of the embodiment can execute the designed experiment and generate an output file and a log file on the execution status of the experiment hub task.
출력부(450)는 설계된 실험의 실행 결과에 따른 생산 계획 데이터를 제공하여 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (450) can provide production plan data based on the execution results of the designed experiment so that production or processes can be managed in the client system.
도 48은 실시 예에 따른 소프트웨어모델 및 로직 세트를 생성하는 예를 개시하는 도면Figure 48 is a drawing disclosing an example of creating a software model and logic set according to an embodiment.
도시한 예에서 온프레미스 컴퓨팅 시스템(1000)의 모델개발부(1100)는 데이터 스키마 및 라이브러리 엔진 세트(1150)를 기반으로 생산 계획을 생성할 수 있는 소프트웨어모델 및 로직 세트를 개발하는 프레임을 제공한다.In the illustrated example, the model development unit (1100) of the on-premise computing system (1000) provides a frame for developing a software model and logic set capable of generating a production plan based on a data schema and library engine set (1150).
일 실시 예에서, 모델개발부(1100)는 사용자 인터페이스 제공부(801), 모델 설정부(802) 및 모델 생성부(803)를 포함할 수 있다.In one embodiment, the model development unit (1100) may include a user interface provision unit (801), a model setting unit (802), and a model generation unit (803).
사용자 인터페이스 제공부(801)는 클라이언트 제조생산시스템의 소프트웨어모델 및 로직 세트에 대한 개발 사용자 인터페이스(user interface, UI)를 표시할 수 있다. 일 실시 예에서, 사용자 인터페이스 제공부(801)는 소프트웨어 모델 및 로직 세트에 대한 모델 편집 UI, 데이터 편집 UI 및 로직 편집 UI 중 적어도 하나를 포함하는 개발 사용자 인터페이스를 표시할 수 있다. 일 실시 예에서, 개발 사용자 인터페이스는 이러한 편집 기능을 수행하기 위한 UI를 표시하는 다양한 화면을 포함 수 있으며, 이에 대한 자세한 내용은 아래에서 설명된다.The user interface providing unit (801) may display a development user interface (UI) for a software model and logic set of a client manufacturing production system. In one embodiment, the user interface providing unit (801) may display a development user interface including at least one of a model editing UI, a data editing UI, and a logic editing UI for the software model and logic set. In one embodiment, the development user interface may include various screens that display UIs for performing such editing functions, and details thereof will be described below.
모델 설정부(802)는 개발 사용자 인터페이스에 대한 사용자 입력에 따른 소프트웨어 모델 및 로직 세트에 대한 설정값을 획득할 수 있다. 여기서, 설정값은 소프트웨어 모델 및 로직 세트에 대한 속성, 타입, 파라미터 등 개발을 위해 사용자에 의해 설정되는 다양한 정보를 나타낼 수 있다. 일 실시 예에서, 설정값은, 클라이언트 제조생산시스템에 대한 도메인 설정값, 소프트웨어 모델 설정값, 퍼시스트 구성 설정값, 데이터 모델 설정값 및 로직 세트 설정값 중 적어도 하나를 포함할 수 있다. 이에 대한 자세한 예시는 아래에서 설명된다.The model setting unit (802) can obtain setting values for a software model and logic set according to user input on the development user interface. Here, the setting values can represent various information set by the user for development, such as properties, types, and parameters for the software model and logic set. In one embodiment, the setting values can include at least one of a domain setting value, a software model setting value, a persistent configuration setting value, a data model setting value, and a logic set setting value for the client manufacturing production system. Detailed examples thereof are described below.
모델 생성부(803)는 사용자 입력에 따른 설정값에 대응하는 소프트웨어 모델 및 로직 세트를 생성할 수 있다. 일 실시 예에서, 모델 생성부(803)는 설정값에 따라 도메인 라이브러리를 결정하고, 모델, 데이터 및 로직 관련 매개변수를 편집하여 소프트웨어 모델 및 로직 세트를 생성할 수 있다. 이에 대한 자세한 내용은 상술한 내용을 참고한다.The model generation unit (803) can generate a software model and logic set corresponding to the settings based on user input. In one embodiment, the model generation unit (803) can determine a domain library based on the settings and edit model, data, and logic-related parameters to generate a software model and logic set. For further details, please refer to the above description.
도 49는 실시 예에 따른 도메인 설정 화면의 예를 개시하는 도면Figure 49 is a drawing disclosing an example of a domain setting screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 도메인 설정 화면(804)이 제공될 수 있다. 일 실시 예에서, 도메인 설정 화면(804)은 사용자 입력에 의해 도메인 설정값이 설정될 수 있다. 예를 들어, 도메인 설정값은 모델 개발을 위한 해당 프로젝트의 기본 자료 구조의 명칭, 사용할 엔진 라이브러리의 버전 및 도메인 라이브러리 중 적어도 하나를 포함할 수 있다.In the illustrated example, a domain setting screen (804) may be provided through the user interface of the model development unit (1100) according to the present disclosure. In one embodiment, the domain setting screen (804) may set domain setting values by user input. For example, the domain setting values may include at least one of the name of the basic data structure of the corresponding project for model development, the version of the engine library to be used, and the domain library.
여기서, 해당 프로젝트의 기본 자료 구조의 명칭은 해당 프로젝트의 프리픽스(prefix)를 나타낼 수 있으며, 소프트웨어 모델 파일의 명칭과 엔진 라이브러리에서 제공하는 기본 자료 구조의 이름을 결정할 때 사용될 수 있다. 예를 들어, 해당 프로젝트의 기본 자료 구조의 명칭은 FabSimulator로 설정될 수 있다.Here, the name of the project's basic data structure can represent the project's prefix and can be used to determine the names of software model files and the basic data structures provided by the engine library. For example, the name of the project's basic data structure can be set to "FabSimulator."
또한, 사용할 엔진 라이브러리의 버전은 소프트웨어 모델 생성 시 설정되거나, 소프트웨어 모델 생성 이후에 수정될 수 있다. 예를 들어, 사용할 엔진 라이브러리의 버전은 2023.124.0.40으로 설정될 수 있다.Additionally, the version of the engine library to be used can be set when creating the software model or modified afterward. For example, the version of the engine library to be used can be set to 2023.124.0.40.
또한, 도메인 라이브러리는 어떤 분야(도메인)의 모델링 라이브러리인지 나타낼 수 있다. 예를 들어, 도메인 라이브러리는 반도체 도메인에 해당하는 SemiFab으로 설정될 수 있다.Additionally, a domain library can indicate which domain the modeling library is for. For example, a domain library could be set to SemiFab, which corresponds to the semiconductor domain.
일 실시 예에서, 도메인 설정 화면(804)을 통해 도메인 라이브러리와 엔진 라이브러리의 버전이 설정되는 경우, 모델 구조 화면(805)을 통해 소프트웨어 모델 및 로직 세트의 기본 자료 구조가 제공될 수 있다. 일 실시 예에서, 기본 자료 구조는 소프트웨어 모델 항목, 퍼시스트 구성 항목, 메인 모듈 항목, 데이터 모델 항목, 전역 함수 항목 및 로직 세트 항목(예: 페깅 로직 항목, 시뮬레이션 로직 항목) 중 적어도 하나를 포함할 수 있다. 각 항목에 대한 자세한 내용은 아래에서 설명된다.In one embodiment, when the versions of the domain library and engine library are set through the domain setting screen (804), the basic data structure of the software model and logic set may be provided through the model structure screen (805). In one embodiment, the basic data structure may include at least one of a software model item, a persistent configuration item, a main module item, a data model item, a global function item, and a logic set item (e.g., a pegging logic item, a simulation logic item). Details for each item are described below.
도 50은 실시 예에 따른 모델 정보 화면의 예를 개시하는 도면Figure 50 is a drawing disclosing an example of a model information screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 모델 정보 화면(806)이 제공될 수 있다. 일 실시 예에서, 모델 정보 화면(806)은 사용자 입력에 의해 소프트웨어 모델 설정값이 설정될 수 있다. 예를 들어, 소프트웨어 모델 설정값은 도메인 라이브러리에 대한 버전(Version), 카테고리(Category), 모델명(Title), 모델 식별자(Guid), 어셈블리명(Assembly), 구성 파일(Configuration File), 개별 경로(Private Path), UI 어셈블리명 및 UI 구성 파일 중 적어도 하나를 포함할 수 있다.In the illustrated example, a model information screen (806) may be provided through a user interface of a model development unit (1100) according to the present disclosure. In one embodiment, the model information screen (806) may set software model settings by user input. For example, the software model settings may include at least one of a version, a category, a model name, a model identifier, an assembly name, a configuration file, a private path, a UI assembly name, and a UI configuration file for a domain library.
여기서, 버전은 해당 도메인 라이브러리에 대한 버전을 나타낼 수 있다. 일 실시 예에서, 버전은 설치되어 있는 도메인 라이브러리에 따라 변경될 수 있다. 예를 들어, 버전은 2023.124.0.40으로 설정될 수 있다.Here, the version may indicate the version of the corresponding domain library. In one embodiment, the version may vary depending on the installed domain library. For example, the version may be set to 2023.124.0.40.
카테고리는 소프트웨어 모델의 유형을 나타낼 수 있다. 일 실시 예에서, 카테고리의 기본값은 해당 프로젝트 생성 시의 사이트 프리픽스(Site Prefix)로 설정될 수 있다. 예를 들어, 카테고리는 Site로 설정될 수 있다.A category can represent a type of software model. In one embodiment, the default value of a category can be set to the site prefix when the project is created. For example, the category can be set to "Site."
모델명은 소프트웨어 모델의 명칭을 나타낼 수 있다. 예를 들어, 모델명은 FabSimulator로 설정될 수 있다.The model name can represent the name of the software model. For example, the model name can be set to FabSimulator.
모델 식별자는 소프트웨어 모델의 식별자(예: GUID)를 나타낼 수 있다. 일 실시 예에서, 모델 식별자는 소프트웨어 모델을 기반으로 생성된 테스크(Task)를 구분하기 위해 사용될 수 있다. 예를 들어, 모델 식별자는 E8FFF8A2-7EF0-4229-B5C6-F61650BEA8F2로 설정될 수 있다.The model identifier may represent an identifier (e.g., a GUID) of the software model. In one embodiment, the model identifier may be used to distinguish tasks created based on the software model. For example, the model identifier may be set to E8FFF8A2-7EF0-4229-B5C6-F61650BEA8F2.
어셈블리명은 소프트웨어 모델을 실행하기 위한 Dll(Dynamic Link Library) 명칭을 나타낼 수 있다. 예를 들어, 어셈블리명은 FabSimulator로 설정될 수 있다.The assembly name can indicate the name of the DLL (Dynamic Link Library) used to execute the software model. For example, the assembly name can be set to FabSimulator.
구성 파일은 소프트웨어 모델의 실행을 위한 설정 파일을 나타낼 수 있다. 개별 경로는 어셈블리 파일을 위치시키는 파일 경로를 나타낼 수 있다. 예를 들어, 개별 경로는 D:\FabWISE 모델\Engine\bin\Debug\net6.0으로 설정될 수 있다.A configuration file can specify a configuration file for executing a software model. Individual paths can specify file paths that locate assembly files. For example, an individual path can be set to D:\FabWISE Model\Engine\bin\Debug\net6.0.
UI 어셈블리명은 어셈블리에 대한 사용자 인터페이스 명칭을 나타낼 수 있다. 예를 들어, UI 어셈블리명은 FabSimulatorUI로 설정될 수 있다.The UI assembly name can represent the user interface name for the assembly. For example, the UI assembly name can be set to FabSimulatorUI.
UI 구성 파일은 소프트웨어 모델의 실행을 위한 사용자 인터페이스 설정 파일을 나타낼 수 있다. 예를 들어, UI 구성 파일은 C:\Program Files (x86)\FabSimulatorUI.json으로 설정될 수 있다. 일 실시 예에서, 모델 정보는 외부로부터 불러오거나(import), 내보낼 수 있다(export).The UI configuration file may indicate a user interface settings file for executing the software model. For example, the UI configuration file may be set to C:\Program Files (x86)\FabSimulatorUI.json. In one embodiment, model information may be imported or exported from an external source.
도 51은 실시 예에 따른 전역변수 설정 화면의 예를 개시하는 도면Figure 51 is a drawing disclosing an example of a global variable setting screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 전역변수 설정 화면(807)이 제공될 수 있다. 일 실시 예에서, 전역변수 설정 화면(807)을 통해 소프트웨어 모델에서 사용되는 전역변수 및 하이퍼 파라미터가 편집될 수 있다. 일 실시 예에서, 전역변수 설정 화면(807)은 사용자 입력에 의해 소프트웨어 모델 설정값 중 전역변수 설정값이 설정될 수 있다. 예를 들어, 전역변수 설정값은 중 전역변수 카테고리(Category), 전역변수명(Name), 타입(Type), 컬렉션 타입(Collection Type), 이니셜값(Initial Value) 및 설정 값 범위(Value Range) 적어도 하나를 포함할 수 있다.In the illustrated example, a global variable setting screen (807) may be provided through the user interface of the model development unit (1100) according to the present disclosure. In one embodiment, global variables and hyperparameters used in a software model may be edited through the global variable setting screen (807). In one embodiment, the global variable setting screen (807) may set global variable setting values among software model setting values by user input. For example, the global variable setting value may include at least one of a global variable category (Category), a global variable name (Name), a type (Type), a collection type (Collection Type), an initial value (Initial Value), and a setting value range (Value Range).
여기서, 전역변수 카테고리는 그룹핑된 번역변수에 대한 카테고리를 나타낼 수 있다. 일 실시 예에서, 전역변수 카테고리는 동일한 카테고리에 대한 그룹핑을 통해 리스트로 표시될 수 있다. 예를 들어, 카테고리는 Forward, Backward, Simulation Logic 등으로 표시될 수 있다.Here, the global variable category can represent a category for grouped translation variables. In one embodiment, the global variable category can be displayed as a list by grouping variables within the same category. For example, the categories can be displayed as Forward, Backward, Simulation Logic, etc.
전역변수명은 전역변수의 명칭을 나타낼 수 있다. 일 실시 예에서, 전역변수명은 고유 값으로 나타내며, 실험 허브와 모델 로직의 변인 대상 지정 시 사용될 수 있다. 예를 들어, 전역변수명은 start-time, period 또는 scenarioID로 설정될 수 있다.A global variable name can indicate the name of a global variable. In one embodiment, a global variable name is represented by a unique value and can be used when specifying variable targets in the experiment hub and model logic. For example, a global variable name can be set to start-time, period, or scenarioID.
타입은 전역변수의 유형을 나타낼 수 있다. 예를 들어, 타입은, DateTime, Single 또는 String으로 설정될 수 있다. 컬렉션 타입은 전역변수를 집합변수로 생성할 때 입력하여 특정할 수 있다. 일 실시 예에서, 컬렉션 타입은 List, Set 또는 Dictionary로 설정될 수 있다.The type can indicate the type of a global variable. For example, the type can be set to DateTime, Single, or String. The collection type can be specified by inputting it when creating a global variable as a set variable. In one embodiment, the collection type can be set to List, Set, or Dictionary.
이니셜값은 전역변수의 초기값을 나타낼 수 있다. 예를 들어, period에 대한 이니셜값은 3으로 설정될 수 있다. 설정 값 범위는 전역변수가 특정 범위로 설정되어야 하는 경우 해당 범위를 나타낼 수 있다.The initial value can indicate the initial value of a global variable. For example, the initial value for period can be set to 3. The set value range can indicate the range within which the global variable should be set.
도 52는 실시 예에 따른 데이터베이스 설정 화면의 예를 개시하는 도면Figure 52 is a drawing disclosing an example of a database setting screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 데이터베이스 설정 화면(808)이 제공될 수 있다. 일 실시 예에서, 데이터베이스 설정 화면(808)을 통해 소프트웨어 모델에서 데이터베이스의 연결 설정의 편집이 수행될 수 있다. 일 실시 예에서, 데이터베이스 설정 화면(808)은 사용자 입력에 의해 소프트웨어 모델 설정값 중 데이터베이스 설정값이 설정될 수 있다. 예를 들어, 데이터베이스 설정값은 데이터베이스 명칭(Name) 및 연결 정보 중 적어도 하나를 포함할 수 있다.In the illustrated example, a database setting screen (808) may be provided through the user interface of the model development unit (1100) according to the present disclosure. In one embodiment, editing of database connection settings in a software model may be performed through the database setting screen (808). In one embodiment, the database setting screen (808) may set database setting values among software model setting values by user input. For example, the database setting values may include at least one of a database name (Name) and connection information.
일 실시 예에서, 지원대상이 되는 데이터 제공자(Data Provider)가 설정될 수 있다. 예를 들어, 데이터 제공자는 Oracle, MySQL, SQLite, Access, SqlServer, DB2 등으로 설정될 수 있다. 일 실시 예에서, 데이터베이스의 형태가 결정되면, 데이터베이스 별 연결 스트링(Connection String)에 맞게 접속 정보가 자동 완성될 수 있다.In one embodiment, a supported data provider can be configured. For example, the data provider can be configured as Oracle, MySQL, SQLite, Access, SqlServer, DB2, etc. In one embodiment, once the database type is determined, connection information can be automatically completed according to the database-specific connection string.
일 실시 예에서, 연결 정보는 해당 데이터베이스에 연결하기 위한 연결 속성 정보를 나타낼 수 있다. 예를 들어, 연결 정보는 해당 데이터베이스의 서버 명칭, 로그인 정보를 포함할 수 있다. 이 경우, 해당 연결 정보에 따른 데이터베이스에 연결 테스트(Test Connection)이 수행될 수 있다.In one embodiment, the connection information may indicate connection attribute information for connecting to the corresponding database. For example, the connection information may include the server name and login information for the corresponding database. In this case, a connection test (Test Connection) may be performed on the database based on the connection information.
도 53은 실시 예에 따른 데이터 스키마 설정 화면의 예를 개시하는 도면Figure 53 is a drawing disclosing an example of a data schema setting screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 스키마 설정 화면(809)이 제공될 수 있다. 일 실시 예에서, 스키마 설정 화면(809)을 통해 소프트웨어 모델에 대한 입력 및 출력 데이터 스키마의 편집이 수행될 수 있다. 일 실시 예에서, 스키마 설정 화면(809)은 사용자 입력에 의해 소프트웨어 모델 설정값 중 데이터 스키마 설정값이 설정될 수 있다. 예를 들어, 데이터 스키마 설정값은 속성 정보(Properties) 및 뷰 정보(Views) 중 적어도 하나를 포함할 수 있다.In the illustrated example, a schema setting screen (809) may be provided through a user interface of a model development unit (1100) according to the present disclosure. In one embodiment, input and output data schemas for a software model may be edited through the schema setting screen (809). In one embodiment, the schema setting screen (809) may set data schema setting values among software model setting values by user input. For example, the data schema setting value may include at least one of property information (Properties) and view information (Views).
일 실시 예에서, 속성 정보는 입력 및 출력 데이터에 대한 테이블명(Name), 속성 타입(Property Type), 키(key), 널(Null), 숨김(Hidden) 및 디폴트값 중 적어도 하나를 포함할 수 있다.In one embodiment, the property information may include at least one of a table name (Name), property type (Property Type), key (Key), Null (Null), Hidden (Hidden), and default value for input and output data.
여기서, 테이블명은 데이터 스키마의 테이블 속성의 명칭을 나타낼 수 있다. 예를 들어, 테이블명은 SCENARIO_ID, LINE_ID, PART_ID 등으로 설정될 수 있다.Here, the table name can represent the name of a table attribute in the data schema. For example, the table name can be set to SCENARIO_ID, LINE_ID, PART_ID, etc.
속성 타입은 테이블 속성의 데이터 타입을 나타낼 수 있다. 예를 들어, 속성 타입은 텍스트 데이터를 나타내는 string으로 설정될 수 있다.The attribute type can represent the data type of a table attribute. For example, the attribute type can be set to string, which represents text data.
키는 테이블명을 실험 허브에서 변인을 특정하기 위한 키로 사용할지 여부를 나타낼 수 있다. 널은 테이블의 빈 값을 허용할지 여부를 나타낼 수 있다. 숨김은 해당 테이블 속성을 노출시킬지 여부를 나타낼 수 있다.Key can indicate whether the table name will be used as a key to identify variables in the experiment hub. Null can indicate whether empty values are allowed in the table. Hidden can indicate whether the table attribute will be exposed.
디폴트값은 초기화 시 초기값을 산출하기 위한 함수를 나타낼 수 있다. 예를 들어, 티폴트값은 = 20으로 설정될 수 있으며, 이 경우, 일괄 초기값이 20으로 입력될 수 있고, ==Process.Route.Count()로 설정되는 경우 제품 공정의 경로 수가 입력될 수 있다.The default value can represent a function that calculates an initial value upon initialization. For example, the default value can be set to = 20, in which case the batch initial value can be input as 20, and if set to ==Process.Route.Count(), the number of routes in the product process can be input.
일 실시 예에서, 뷰 정보는 해당 데이터 정보를 확인하기 위한 키 요소를 나타낼 수 있다. 예를 들어, 뷰 정보는 뷰 명칭(Name)과 키 요소(Keys) 중 적어도 하나를 포함할 수 있다. 일 실시 예에서, 뷰 정보는 시뮬레이션 수행 시 생성된 엔티티 테이블의 데이터를 사용할 때 키 요소에 따라 설정될 수 있다.In one embodiment, view information may indicate key elements for identifying corresponding data information. For example, view information may include at least one of a view name (Name) and key elements (Keys). In one embodiment, view information may be set based on key elements when using data from an entity table generated during simulation.
일 실시 예에서, 데이터 스키마는 데이터베이스 설정값이 입력되어 있는 데이터베이스로부터 불러올 수 있다.In one embodiment, the data schema can be retrieved from a database that contains database settings.
도 54는 실시 예에 따른 쿼리 설정 화면의 예를 개시하는 도면Figure 54 is a drawing disclosing an example of a query setting screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 쿼리 설정 화면(810)이 제공될 수 있다. 일 실시 예에서, 쿼리 설정 화면(810)은 모델 구조 화면의 소프트웨어 모델 항목 중 입력 항목을 통해 접근할 수 있다. 일 실시 예에서, 쿼리 설정 화면(810)을 통해 적어도 하나의 쿼리의 설정이 수행될 수 있다. 일 실시 예에서, 쿼리 설정 화면(810)은 사용자 입력에 의해 소프트웨어 모델 설정값 중 쿼리 설정값이 설정될 수 있다. 예를 들어, 쿼리 설정값은 데이터 항목(Data Item), 데이터 소스(Data Source), 데이터 액션(Data Action) 및 커맨드(Command) 중 적어도 하나를 포함할 수 있다.In the illustrated example, a query setting screen (810) may be provided through the user interface of the model development unit (1100) according to the present disclosure. In one embodiment, the query setting screen (810) may be accessed through an input item among the software model items of the model structure screen. In one embodiment, at least one query may be set through the query setting screen (810). In one embodiment, the query setting screen (810) may set a query setting value among the software model setting values by user input. For example, the query setting value may include at least one of a data item, a data source, a data action, and a command.
여기서, 데이터 항목은 쿼리의 대상이 되는 데이터 항목을 나타낼 수 있다. 예를 들어, 데이터 항목은 Default로 설정될 수 있다.Here, the data item can represent the data item that is the target of the query. For example, the data item can be set to Default.
데이터 소스는 데이터베이스 설정 화면을 통해 설정된 소프트웨어 모델에서 데이터베이스의 연결 설정을 나타낼 수 있다. 데이터 소스에 대한 상세한 내용은 상술한 내용을 참조한다.A data source can represent a database connection setting in a software model configured through the database settings screen. For more information on data sources, see the section above.
데이터 액션은 다수 개의 쿼리로 구성될 수 있는 쿼리 관리 단위를 나타낼 수 있다. 일 실시 예에서, 하나의 데이터 항목에 대하여 다수의 데이터 액션이 등록된 경우, 각 데이터 액션에 대한 활성화(Activate) 여부가 선택될 수 있다. 즉, 운영 환경에서는 활성화 되어 있어 데이터베이스로부터 데이터를 불러들일 필요가 있으나, 테스트 환경에서 매번 데이터베이스에 접속할 필요는 없어 비활성화 시켜둘 수 있다. 예를 들어, 데이터 액션은 LineA 및 LineB로 설정될 수 있다.A data action can represent a query management unit that can be composed of multiple queries. In one embodiment, if multiple data actions are registered for a single data item, the activation of each data action can be selected. Specifically, in a production environment, it is activated, requiring data to be retrieved from the database. However, in a test environment, it can be deactivated, eliminating the need to connect to the database every time. For example, data actions can be set to LineA and LineB.
커맨드는 데이터 액션에 대한 쿼리 문장을 나타낼 수 있다. 일 실시 예에서, 하나의 데이터 액션에는 적어도 하나의 커맨드가 설정될 수 있다. 일 실시 예에서, 상단의 메뉴바의 “””“버튼을 통해 커맨드가 추가될 수 있으며, 위 화살표와 아래 화살표 버튼을 통해 커맨드 실행 순서가 조정될 수 있다. 이후, 커맨드 트리(Tree)에서의 커맨드 순서대로 실행될 수 있다. 예를 들어, 커맨드는 SELECT, A.PRODUCT_ID, A.PROCESS_ID, A.STEP_ID, A.RECIPE_ID, A.EQP_ID, A.CONDITION, FROM, MZT_MFG_EQP_ARRANGE A와 같은 쿼리문으로 작성될 수 있다. 예를 들어, 쿼리문은 Select, Update, Delete, Create, From, Where, OrderBy 등과 같은 데이터베이스에 대한 명령으로 구성될 수 있다. 또한, 예를 들어, 작성된 커맨드는 Default 하단의 LineA와 LineB와 같이 등록될 수 있다.A command can represent a query statement for a data action. In one embodiment, at least one command can be set for one data action. In one embodiment, commands can be added through the “””” button in the menu bar at the top, and the command execution order can be adjusted through the up and down arrow buttons. Thereafter, the commands can be executed in the order of the commands in the command tree. For example, a command can be written as a query statement such as SELECT, A.PRODUCT_ID, A.PROCESS_ID, A.STEP_ID, A.RECIPE_ID, A.EQP_ID, A.CONDITION, FROM, MZT_MFG_EQP_ARRANGE A. For example, a query statement can be composed of commands for a database such as Select, Update, Delete, Create, From, Where, OrderBy, etc. In addition, for example, the written command can be registered as LineA and LineB under Default.
일 실시 예에서, 복수의 데이터 액션이 설정되어 활성화된 경우, 위에서부터 실행한 쿼리 결과를 연계하여 추가할 수 있다. 일 실시 예에서, 복수의 데이터 액션에 따른 복수의 쿼리가 사용되는 경우, 데이터의 같은 열(Column) 데이터를 서로 다른 데이터소스로부터 가져올 수 있다. 예를 들어, LineA의 데이터소스로부터 데이터가 획득되고, LineB의 데이터소스로부터 데이터가 획득될 수 있다.In one embodiment, when multiple data actions are configured and activated, the results of queries executed from above can be linked and added. In one embodiment, when multiple queries are used according to multiple data actions, data in the same column can be retrieved from different data sources. For example, data can be obtained from the data source for Line A and data can be obtained from the data source for Line B.
일 실시 예에서, 데이터베이스로부터 데이터를 불러와 맵핑하는 쿼리가 작성될 수 있다. 또한, 일 실시 예에서, 쿼리가 사용자 입력에 의해 직접 작성되거나, 데이터 스키마로부터 편집할 수 있는 UI를 통해 작성될 수 있다.In one embodiment, a query may be written to retrieve and map data from a database. Furthermore, in one embodiment, the query may be written directly by user input or through a UI that allows editing of a data schema.
도 55는 실시 예에 따른 퍼시스트 구성 화면의 예를 개시하는 도면Figure 55 is a drawing disclosing an example of a persistence configuration screen according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 퍼시스트 구성 화면(811)이 제공될 수 있다. 일 실시 예에서, 퍼시스트 구성 화면(811)을 통해 데이터 스키마에서 정의한 입력 및 출력 데이터의 소프트웨어 모델에 대한 작업 순서, 방식, 데이터 검증 및 로직 설정이 수행될 수 있다. 일 실시 예에서, 퍼시스트 구성 화면(811)은 사용자 입력에 의해 퍼시스트 구성 설정값이 설정될 수 있다. 예를 들어, 퍼시스트 구성 설정값은 입력 데이터 항목별 로딩 시 데이터 항목명(Name), 데이터 로딩 여부(Enable), 로직 개발(On after load item), 데이터 액션 실행(Executing action), 로그 퍼포먼스(Log performance) 및 컨텍스트 일시 사용(Use temporary context) 중 적어도 하나를 포함할 수 있다.In the illustrated example, a persistent configuration screen (811) may be provided through a user interface of a model development unit (1100) according to the present disclosure. In one embodiment, the persistent configuration screen (811) may be used to perform work order, method, data verification, and logic settings for a software model of input and output data defined in a data schema. In one embodiment, the persistent configuration screen (811) may be used to set persistent configuration settings by user input. For example, the persistent configuration settings may include at least one of a data item name (Name), whether to load data (Enable), logic development (On after load item), data action execution (Executing action), log performance (Log performance), and context temporary use (Use temporary context) when loading each input data item.
데이터 항목명은 로딩 시 사용할 데이터 아이템 및 데이터 스키마 중 적어도 하나의 명칭을 나타낼 수 있다. 예를 들어, 데이터 항목명은 Process로 설정될 수 있다.The data item name can indicate the name of at least one of the data items and data schemas to be used during loading. For example, the data item name can be set to Process.
데이터 로딩 여부는 데이터의 로딩 여부를 나타내며, 활성화가 체크(예: V)되지 않은 경우, 데이터 아이템이 자동으로 로드되지 않을 수 있다.Whether to load data indicates whether data is loaded or not, and if activation is not checked (e.g. V), data items may not be loaded automatically.
로직 개발은 데이터 항목의 각 데이터의 행(row)별로 데이터의 변환이나 검증과 같은 로직을 개발하기 위한 로직 개발 포인트를 나타낼 수 있다. 예를 들어, 로직 개발은 OnAfterLoad_Process로 설정되어 Process 데이터 항목에 대한 로직 개발을 위한 데이터 변환이 설정될 수 있다.Logic development can represent a logic development point for developing logic, such as data transformation or validation, for each row of data within a data item. For example, logic development can be set to OnAfterLoad_Process, which sets up data transformation for logic development for the Process data item.
데이터 액션 실행은 전체 데이터를 모두 엔티티 테이블(Entity Table)에 로딩한 후 해당 엔티티 테이블의 전체 내용에 기반하여 로딩된 데이터를 처리하는 로직 개발 포인트를 나타낼 수 있다.Data action execution can represent a logic development point that loads all data into an entity table and then processes the loaded data based on the entire contents of the entity table.
로그 퍼포먼스는 데이터 항목의 로딩 시간 기록 여부를 나타낼 수 있다. 컨텍스트 일시 사용은 메모리 유지 여부를 나타낼 수 있다. 일 실시 예에서, 컨텍스트 일시 사용의 활성화가 체크(예: V)되는 경우, 입력 데이터의 로딩이 완료되는 시점에 데이터가 메모리에서 삭제되며, 활성화가 체크되지 않는 경우, 엔진 또는 모델 수행이 종료되는 시점까지 데이터가 메모리에 유지될 수 있다.Log performance can indicate whether the loading time of data items is recorded. Context temporary use can indicate whether memory is maintained. In one embodiment, if the context temporary use is enabled (e.g., V), data is deleted from memory when the loading of input data is complete. If the enablement is not enabled, data may be maintained in memory until the engine or model execution is terminated.
일 실시 예에서, 출력 퍼시스트 구성의 경우, 특정 건 단위로 자동 저장 후 메모리에서 삭제하는 자동 쓰기(Auto write) 방식, 데이터를 실제 파일이 아닌 버퍼(buffer)에만 기록하고, 시뮬레이션 종료 후 버퍼의 데이터는 출력으로 이동시키는 버퍼 방식, 러닝 타임 동안 출력 데이터를 메모리에 유지하는 메모리 유지 방식 중 적어도 하나로 저장 방식이 설정될 수 있다.In one embodiment, for the output persistence configuration, the storage method may be set to at least one of an auto write method that automatically saves and then deletes data from memory in units of specific cases, a buffer method that records data only in a buffer rather than an actual file and moves the data in the buffer to the output after the simulation ends, and a memory retention method that maintains output data in memory during the running time.
도 56은 실시 예에 따른 퍼시스트 구성의 쿼리 실행 설정 화면의 다른 예를 개시하는 도면FIG. 56 is a drawing disclosing another example of a query execution setting screen of a persistent configuration according to an embodiment.
도시한 예에서, 본 개시에 따른 모델 개발부(1100)의 사용자 인터페이스를 통해 퍼시스트 구성의 쿼리 실행 설정 화면(812)이 제공될 수 있다. 일 실시 예에서, 쿼리 실행 설정 화면(812)을 통해 입력 데이터의 다운로드 순서 조절이 수행될 수 있다. 일 실시 예에서, 쿼리 실행 설정 화면(812)은 사용자 입력에 의해 퍼시스트 구성의 쿼리 실행 설정값이 입력될 수 있다. 예를 들어, 쿼리 실행 설정값은 쓰레드 카운트(Thread count), DB 재연결 카운트(DB job retry count), 예외 정책(Exception Policy) 및 다운로드 순서 중 적어도 하나를 포함할 수 있다.In the illustrated example, a query execution setting screen (812) of a persistent configuration may be provided through a user interface of a model development unit (1100) according to the present disclosure. In one embodiment, the download order of input data may be controlled through the query execution setting screen (812). In one embodiment, the query execution setting screen (812) may input query execution setting values of a persistent configuration by user input. For example, the query execution setting values may include at least one of a thread count, a DB reconnection count, an exception policy, and a download order.
여기서, 쓰레드 카운트는 데이터베이스에서 쿼리의 수행 쓰레드 개수를 나타낼 수 있다. 예를 들어, 쓰레드 카운트는 1로 설정될 수 있다.Here, the thread count can represent the number of threads executing a query in the database. For example, the thread count can be set to 1.
DB 재연결 카운트는 데이터베이스의 네트워크 연결이 해제되는 경우 연결을 재시도하는 횟수를 나타낼 수 있다. 예를 들어, DB 재연결 카운트는 3으로 설정될 수 있으며, 이 경우, 1차는 2초x1, 2차는 1차+2차x2, 3차는 2차+2초x3으로, 12초 동안 3회 시도될 수 있다.The DB reconnection count can indicate the number of times to retry a connection if the database's network connection is lost. For example, the DB reconnection count can be set to 3, in which case the first reconnection attempt will be 2 seconds x 1, the second attempt will be 1st + 2nd x 2, and the third attempt will be 2nd + 2 seconds x 3, for a total of 3 attempts over 12 seconds.
예외 정책은 예외 발생 시 유효한 정책을 나타낼 수 있다. 예를 들어, 예외 정책은 로그 기록 후 수행(종료되지 않음)되는 LogOnly로 설정될 수 있다.An exception policy can indicate the policy in effect when an exception occurs. For example, an exception policy can be set to LogOnly, which executes (but does not terminate) after logging.
다운로드 순서는 위에서부터 아래 순서로 쿼리가 수행되는 순서를 나타낼 수 있다. 일 실시 예에서, 쓰레드 카운트가 2 이상인 경우, 위에서부터 쓰레드 카운트만큼 동시에 쿼리가 실행될 수 있다.The download order may indicate the order in which queries are executed from top to bottom. In one embodiment, if the thread count is 2 or greater, queries may be executed concurrently from top to bottom as many times as the thread count.
도 57은 실시 예에 따른 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하는 예를 개시하는 흐름도Figure 57 is a flowchart disclosing an example of analyzing a production plan based on a software model and logic set according to an embodiment.
클라이언트 제조생산시스템의 소프트웨어모델 및 로직 세트에 대한 개발 사용자 인터페이스(user interface, UI)를 표시한다(S821). 일 실시 예에서, 개발 사용자 인터페이스는 소프트웨어모델 및 로직 세트를 생성하기 위한 다양한 설정 화면을 포함할 수 있다. 이에 대하여는 도 48 및 56에서 상술한 내용을 참고하도록 한다.A development user interface (UI) for the software model and logic set of the client manufacturing system is displayed (S821). In one embodiment, the development user interface may include various configuration screens for creating the software model and logic set. For details, refer to the details described above in FIGS. 48 and 56.
개발 사용자 인터페이스에 대한 사용자 입력에 따른 소프트웨어 모델 및 로직 세트에 대한 설정값에 대응하는 소프트웨어 모델 및 로직 세트를 생성한다(S822). 일 실시 예에서, 설정값은, 상기 클라이언트 제조생산시스템에 대한 도메인 설정값, 소프트웨어 모델 설정값, 퍼시스트 구성 설정값, 데이터 모델 설정값 및 로직 세트 설정값 중 적어도 하나를 포함할 수 있다.A software model and a logic set corresponding to the settings for the software model and logic set according to user input for the development user interface are generated (S822). In one embodiment, the settings may include at least one of a domain setting value, a software model setting value, a persistent configuration setting value, a data model setting value, and a logic set setting value for the client manufacturing production system.
일 실시 예에서, 클라이언트 제조생산시스템의 데이터 스키마 및 라이브러리 엔진세트 중 적어도 하나에 기반하여, 설정값에 대응하는 소프트웨어 모델 및 로직 세트를 생성할 수 있다. 이에 대하여는 도 48 및 56에서 상술한 내용을 참고하도록 한다.In one embodiment, a software model and logic set corresponding to the set values can be generated based on at least one of the data schema and library engine set of the client manufacturing system. For details, refer to the contents described above in FIGS. 48 and 56.
소프트웨어모델 및 로직 세트에 기반하는 클라이언트 제조생산시스템에 대한 생산 계획 데이터를 제공한다(S823). 일 실시 예에서, 클라이언트 제조생산시스템의 데이터 스키마에 따라 클라이언트 제조생산시스템으로부터 기준정보를 포함하는 입력데이터를 수신하고, 수신된 입력데이터를 기반으로 소프트웨어모델 및 로직 세트를 수행하여 생산 계획 데이터를 제공할 수 있다. 이에 대하여는 도 48 및 56에서 상술한 내용을 참고하도록 한다.Production planning data for a client manufacturing system based on a software model and logic set is provided (S823). In one embodiment, input data including reference information may be received from the client manufacturing system according to the data schema of the client manufacturing system, and the production planning data may be provided by executing a software model and logic set based on the received input data. For details, please refer to the details described above in FIGS. 48 and 56.
도 8을 참조하여 소프트웨어모델 및 로직 세트에 기반하여 생산 계획을 분석하여 디지털 생산 계획 정보를 제공하는 장치의 일 실시예를 설명하면 다음과 같다.Referring to FIG. 8, an embodiment of a device for analyzing a production plan based on a software model and logic set and providing digital production plan information is described as follows.
디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 입력부(310), 저장장치(320), 인메모리(330), 프로세서(340), 출력부(350), 및 사용자인터페이스(360)를 포함할 수 있다.One embodiment of a device providing digital production planning information may include an input unit (310), a storage unit (320), an in-memory unit (330), a processor (340), an output unit (350), and a user interface (360).
이하에서 디지털 생산 계획 정보를 제공하는 장치의 일 실시예는 사용자인터페이스(360)에 의한 사용자 제어 및 관리에 따라 제어될 수 있다.An embodiment of a device providing digital production planning information below can be controlled by user control and management via a user interface (360).
입력부(310)는 클라이언트 제조생산시스템에 대한 소프트웨어모델 및 로직 세트를 획득할 수 있다. 저장장치(320)는 입력부(310)가 수신한 소프트웨어모델 및 로직 세트를 저장하거나 또는 소프트웨어모델 및 로직 세트를 저장장치(320)에 저장에 저장할 수 있다. 저장장치(320)는 휘발성 메모리 또는 비휘발성 메모리를 포함할 수 있다. 인메모리(330)는 위에서 개시한 라이브러리 엔진세트를 저장할 수 있다. 라이브러리 엔진세트는 생산 계획을 생성하는 여러 캡슐화된 기능블록 파일인 생산 계획 엔진을 포함할 수 있다. 일 실시 예에서, 인메모리(330)는 소프트웨어 모델 및 로직 세트 중 적어도 하나에 대한 설정값을 저장할 수 있다. 예를 들어, 인메모리(330)는 소프트웨어 및 로직 세트 중 적어도 하나를 편집한 결과물을 저장할 수 있다.The input unit (310) can obtain a software model and a logic set for the client manufacturing production system. The storage unit (320) can store the software model and the logic set received by the input unit (310) or can store the software model and the logic set in the storage unit (320). The storage unit (320) can include volatile memory or non-volatile memory. The in-memory (330) can store the library engine set disclosed above. The library engine set can include a production planning engine, which is a plurality of encapsulated function block files that generate a production plan. In one embodiment, the in-memory (330) can store settings for at least one of the software model and the logic set. For example, the in-memory (330) can store the result of editing at least one of the software model and the logic set.
실시 예의 프로세서(340)는 클라이언트 제조생산시스템의 소프트웨어모델 및 로직 세트에 대한 개발 사용자 인터페이스(user interface, UI)를 표시하고, 개발 사용자 인터페이스에 대한 사용자 입력에 따른 소프트웨어 모델 및 로직 세트에 대한 설정값에 대응하는 소프트웨어 모델 및 로직 세트를 생성하며, 소프트웨어모델 및 로직 세트에 기반하는 클라이언트 제조생산시스템에 대한 생산 계획 데이터를 제공할 수 있다. 이에 대한 상세한 내용은 상술한 설명을 참조한다.The processor (340) of the embodiment may display a development user interface (UI) for a software model and a logic set of a client manufacturing production system, generate a software model and a logic set corresponding to settings for the software model and the logic set according to user input to the development user interface, and provide production planning data for the client manufacturing production system based on the software model and the logic set. For details thereof, refer to the above description.
프로세서(340)는 사용자인터페이스(360)의 사용자의 요청에 따라 소프트웨어모델 및 로직세트를 개발할 수 있다. 또한, 프로세서(340)는 개발된 소프트웨어모델 및 로직 세트의 테스트 및 사전 실행하여 생산 계획 데이터를 얻을 수 있다. 그리고 프로세서(340)는 사용자의 요청에 따라 생산 계획 데이터를 생성하는 소프트웨어모델 및 로직을 분석하거나 테스트한 결과를 사용자인터페이스(360)를 통해 사용자에게 제공할 수 있다. 이에 대한 상세한 내용은 상술한 설명을 참조한다.The processor (340) can develop software models and logic sets at the user's request via the user interface (360). Furthermore, the processor (340) can test and pre-execute the developed software models and logic sets to obtain production planning data. Furthermore, the processor (340) can analyze or test the software models and logic that generate production planning data at the user's request, and provide the results to the user via the user interface (360). For further details, please refer to the above description.
출력부(350)는 소프트웨어 모델 및 로직 세트의 분석 결과 데이터 및 소프트웨어 모델 및 로직 세트에 기반하여 실험을 수행한 결과 데이터를 제공하여 로컬 환경 및 클라이언트 시스템에서 생산 또는 공정을 관리할 수 있도록 할 수 있다.The output unit (350) can provide analysis result data of a software model and logic set and result data of an experiment performed based on the software model and logic set to enable production or process management in a local environment and client system.
100: 클라이언트 제조생산시스템
110: 시스템운영부
130: 모델실행부
140: 실험허브부
150: 데이터베이스
200: 클라이언트 제조생산시스템
310: 입력부
320: 저장장치
330: 인메모리
340: 프로세서
350: 출력부
1000: 온프레미스시스템
1100: 모델개발부
1200: 서버관리부
1150, 2210: 라이브러리 엔진 세트
1130, 2230: 소프트웨어모델 및 로직세트
1300: 모델분석부
1400: 모델실행부
1500: 실험허브부
2000: 클라우드 컴퓨팅 시스템
2100: 운영관리부100: Client Manufacturing Production System
110: System Operation Department
130: Model Execution Department
140: Experimental Hub Department
150: Database
200: Client Manufacturing Production System
310: Input section
320: Storage device
330: In-memory
340: Processor
350: Output section
1000: On-premise system
1100: Model Development Department
1200: Server Management Department
1150, 2210: Library Engine Set
1130, 2230: Software Model and Logic Set
1300: Model Analysis Department
1400: Model Execution Department
1500: Experimental Hub
2000: Cloud Computing Systems
2100: Operations Management Department
| Publication Number | Publication Date |
|---|---|
| KR102868403B1true KR102868403B1 (en) | 2025-10-14 |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200082546A1 (en)* | 2018-09-10 | 2020-03-12 | Siemens Aktiengesellschaft | Tracking and traceability of parts of a product |
| US20210157312A1 (en)* | 2016-05-09 | 2021-05-27 | Strong Force Iot Portfolio 2016, Llc | Intelligent vibration digital twin systems and methods for industrial environments |
| US20230281358A1 (en)* | 2022-03-04 | 2023-09-07 | Slate Technologies Inc. | System and method for manufacture and customization of construction assemblies in a computing environment |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210157312A1 (en)* | 2016-05-09 | 2021-05-27 | Strong Force Iot Portfolio 2016, Llc | Intelligent vibration digital twin systems and methods for industrial environments |
| US20200082546A1 (en)* | 2018-09-10 | 2020-03-12 | Siemens Aktiengesellschaft | Tracking and traceability of parts of a product |
| US20230281358A1 (en)* | 2022-03-04 | 2023-09-07 | Slate Technologies Inc. | System and method for manufacture and customization of construction assemblies in a computing environment |
| Publication | Publication Date | Title |
|---|---|---|
| US8340995B2 (en) | Method and system of using artifacts to identify elements of a component business model | |
| RU2610288C2 (en) | Providing capabilities of configured technological process | |
| US11263562B1 (en) | System and method for computer-assisted improvement of business intelligence exosystem | |
| US10956400B2 (en) | Query processing using primary data versioning and secondary data | |
| CN108037919A (en) | A kind of visualization big data workflow configuration method and system based on WEB | |
| CN111309712A (en) | Optimized task scheduling method, device, equipment and medium based on data warehouse | |
| US12105939B1 (en) | System and methods for process mining using ordered insights | |
| US20140149186A1 (en) | Method and system of using artifacts to identify elements of a component business model | |
| Bellini et al. | Graph databases methodology and tool supporting index/store versioning | |
| CN118550671A (en) | Job set scheduling method, device, computer equipment and storage medium | |
| KR102868403B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868413B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868393B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868416B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868427B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868422B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868373B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868383B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868432B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868436B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868431B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR102868365B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information | |
| KR20190143595A (en) | Method and system for optimizing concurrent schedule | |
| US20130245804A1 (en) | Network based calculations for planning and decision support tasks | |
| KR102868437B1 (en) | Apparatus for providing digital production plan information, method thereof, and computationally-implementable storage medium for storing a software for providing digital production plan information |