스케줄링 엔진 성능 향상

리소스 스케줄링 엔진은 계획 및 릴리스된 생산 주문에 대한 경로를 스케줄링할 때 사용됩니다. 엔진은 원래 Dynamics AX 2012의 일부로 출시되었으며 출시 이후 몇 가지 개선을 거쳤습니다.

작업 샵 스케줄링 문제는 결정 변수의 수에 따라 솔루션 시간이 기하급수적으로 증가하는 매우 복잡한 조합 문제입니다. 종종 고객은 가장 현대적인 하드웨어에서도 합리적인 시간에 해결할 수 없는 스케줄링 문제가 발생하는 방식으로 생산 경로 및 관련 데이터를 설정합니다. 이 문서는 스케줄링 엔진과 특정 설정이 성능에 미치는 영향을 이해하는 데 도움이 됩니다.

스케줄링의 성능을 향상시키는 것과 관련하여 일반 지침은 엔진이 해결해야 하는 문제의 복잡성을 줄이는 것이 좋습니다. 성능에 영향을 줄 수 있는 몇 가지 주요 요인은 다음과 같습니다.

• 작업이 많은 경로
• 병렬 작업이 있는 경로
• 리소스 양이 1보다 많은 작업
• 적용 가능한 리소스가 많은 작업
• 하드 링크 사용
• 한정된 용량의 사용
• 사용된 다른 캘린더의 수
• 달력의 하루 작업 시간 슬롯 수
• 경로의 총 소요 시간
• 여러 스케줄링 엔진을 병렬로 실행

기본 일정 흐름 개요

주어진 설정이 성능에 어떤 영향을 미칠 수 있는지 이해하려면 엔진 내부와 이를 둘러싼 X++ 코드 모두에서 프로세스가 어떻게 흐르는지 이해하는 것이 중요합니다.

주문을 예약하는 기본 프로세스는 세 가지 주요 단계로 구성됩니다.

• 데이터 로드 중 – 여기에서 X++ 데이터 모델은 작업 및 제약 조건의 형태로 엔진의 내부 데이터 모델로 변환됩니다.
• 스케줄링 – 주어진 모델과 제약 조건을 처리하고 결과를 생성하는 스케줄링의 주요 소스입니다. 이 과정에서 엔진은 필요에 따라 X++에서 작업 시간 정보와 기존 용량 예약을 요청합니다.
• 데이터 저장 – 작업 용량 예약 슬롯 형태의 엔진 결과는 용량 예약을 저장하고 작업/작업/주문의 시작 및 종료 시간을 업데이트하기 위해 X++ 코드로 처리됩니다.

엔진에 데이터 로드

스케줄링 엔진은 다양한 데이터 소스를 처리할 수 있는 일반 엔진으로 구축되었기 때문에 Supply Chain Management 데이터베이스보다 더 추상적인 데이터 모델을 가지고 있습니다. 경로, 보조 작업 및 런타임의 개념은 엔진이 노출하는 일반 작업 및 제약 조건 모델로 "변환"되어야 합니다. 모델을 구축하기 위한 로직은 상당한 양의 비즈니스 로직을 가지고 있으며 소스 데이터에 따라 다릅니다. 담당 X++ 클래스는 WrkCtrScheduler이며 계획 생산 주문, 출시 생산 주문 및 프로젝트 예측에 대한 파생 클래스가 있습니다.

예를 들어, 비교적 간단해 보이는 다음 표와 이미지에 표시된 경로를 고려하세요.

작업. 아니요.	우선 순위	설정 시간	실행 시간	다음 이후의 큐 시간	리소스의 양	다음
10	기본	1.00	2.00		1	20
10	보조 1				1	20
20	기본		3.00	1.00	3	0

이것을 엔진에 보낼 때 다음 그림과 같이 8개의 작업으로 나뉩니다(확대하려면 이미지를 선택하세요).

두 작업 사이의 표준 링크는 FinishStart이며, 이는 한 작업의 종료 시간이 다른 작업의 시작 시간 이전이어야 함을 의미합니다. 나중에 프로세스를 수행할 동일한 리소스에서 설정을 수행해야 하므로 둘 사이에 OnSameResource 제약이 있습니다. 10에 대한 1차 작업과 2차 작업을 위한 작업 사이에는 작업이 동시에 시작 및 종료되어야 함을 의미하는 StartStart 및 FinishFinish 링크가 있고 1차 및 2차 작업에 대해 동일한 리소스를 방지하는 NotOnSameResource 제약 조건이 있습니다.

리소스 수량이 3으로 설정된 작업 20의 경우 프로세스 작업이 모든 작업이 정확히 동시에 실행되어야 하는 3개의 개별 작업으로 분할되었습니다. 이 경우 경로 그룹은 다음 시간 이후에 큐에 대한 용량을 예약하지 않도록 설정되어 있으므로 이후 큐에 대해 단일 작업만 있습니다.

스케줄링 엔진은 작업의 개념만 이해하고 작업의 개념이 없습니다. 즉, 작업 일정을 수행할 때 작업이 작업으로 분할되지만 데이터베이스에 유지되지는 않습니다.

각 작업에 대해 작업 용량 요구 사항(필요한 시간(초))도 정의합니다. 리소스 요구 사항이 정의된 방식에 따라 각 작업에 대해 작업을 실행할 수 있는 모든 잠재적인 적용 가능한 리소스 목록과 해당 특정 리소스에 대한 용량 요구 사항을 보낼 수도 있습니다. 모델을 빌드할 때 적용 가능한 리소스 목록이 전송되더라도 엔진은 여전히 리소스 할당이 전체 작업 기간 동안 실제로 유효한지 확인해야 합니다.

스케줄링 엔진 내부

스케줄링 엔진 인터페이스

엔진이 내부적으로 어떻게 작동하는지 이해하려면 엔진이 외부에 노출하는 기능을 살펴보는 것이 가장 좋습니다. X++에서 메인 인터페이스는 WrkCtrSchedulerEngineInterface입니다. 다음 하위 섹션에 설명된 방법이 있습니다.

일반 엔진

메서드	목적
run	로드된 모든 작업을 예약하고 오류 코드를 반환합니다.
getJobSchedulingSequenceResult	특정 작업으로 식별된 시퀀스에 대한 스케줄링 결과와 첫 번째 오류 작업을 가져옵니다.
validateJobCapacityReservations	엔진이 저장한 모든 작업에 대한 용량 예약을 검증합니다.
setReservationsTimeStamp	엔진 캐시의 예약된 작업에 대한 모든 새 용량 예약에 대해 엔진 세트에 타임스탬프를 보냅니다.
addPropertyToGroupAggregation	용량이 집계될 때 사용되는 속성 집합에 속성 접두사를 추가합니다.
addResource	스케줄링 엔진 리소스 풀에 리소스를 추가합니다.
addResourceGroup	스케줄링 엔진 리소스 그룹 풀에 리소스 그룹을 추가합니다.
addResourceGroupMembership	리소스를 리소스 그룹에 구성원으로 추가합니다.
addOptimizationGoal	일정 최적화 목표(기간 또는 우선순위)를 추가합니다.

개별 작업

메서드	목적
addJobInfo	예약해야 하는 작업에 대해 엔진에 알리는 작업 정보 레코드를 추가합니다.
addConstraintJobEndsAt	작업이 지정된 날짜 및 시간에 종료되어야 한다는 제약 조건을 추가합니다.
addConstraintJobStartsAt	작업이 지정된 날짜 및 시간에 시작되어야 한다는 제약 조건을 추가합니다.
addConstraintMaxJobDays	작업이 지정된 최대 일 수에 걸쳐 있을 수 있는 제약 조건을 정의합니다.
addConstraintResourceRequirement	특정 리소스에서 작업을 예약해야 한다는 제약 조건을 추가합니다.
addJobBindPriority	(작업, 제약 수준) 쌍에 대한 작업 바인딩 우선 순위를 추가합니다. 우선 순위 값이 높을수록 작업 변수가 더 일찍 바인딩됩니다. 작업은 동일한 순서에서 우선 순위 값이 낮은 작업보다 먼저 처리됩니다.
addJobCapacity	작업이 실행되는 리소스에 관계없이 작업에 대한 용량 로드 정보(예: 필수 작업 런타임)를 추가합니다.
addJobResourceCapacity	작업을 수행하는 데 사용할 수 있는 리소스 집합에 리소스를 추가하고 해당 리소스에서 실행할 때 필요한 용량을 나타냅니다.
addJobGoal	특정 제약 수준(가장 빠른 종료 시간 또는 가장 늦은 시작 시간)에 대한 작업 목표 정보를 추가합니다.
addJobResourcePriority	리소스에 작업이 예약될 때 사용할 우선 순위를 추가합니다.
addJobResourceRuntime	작업이 예약될 리소스에 종속되는 작업 시간을 지정합니다.
addJobRuntime	작업이 예약될 리소스와 독립적인 작업 시간을 지정합니다.
scheduleJobOnResourceGroup	리소스 그룹 수준에서 예약할 작업을 표시합니다.
setJobResourcePreemptionAllowed	리소스의 작업에 대해 선점이 허용되는지 여부를 설정합니다(엔진이 비연속 용량 슬롯에서 작업을 예약할 수 있는 경우).
setRequiredNumberOfResources	작업을 예약하는 데 필요한 리소스 수를 설정합니다(작업 예약에만 해당).

작업 간의 제약

메서드	목적
addJobLink	두 작업 사이에 링크(예: 마침>시작)를 추가합니다.
addConstraintEndsDelayed	다른 작업이 끝나기 전에 작업을 끝낼 수 없다는 제약 조건과 약간의 지연 시간을 정의합니다.
addConstraintJobListWorkingTimeIntersect	작업에 예약된 용량 슬롯이 작업에서 사용하는 두 리소스에 대해 교차 작업 시간에 있어야 한다는 제약 조건을 추가합니다.
addConstraintJobOverlap	첫 번째 리소스가 아직 처리를 완료하지 않은 상태에서 두 번째 리소스가 처리를 시작할 수 있도록 주어진 수량의 항목을 두 리소스 간에 이동할 수 있는 경우 작업 순서를 정의하는 제약 조건을 추가합니다.
addConstraintNotOnSameResource	두 작업이 동일한 리소스에 예약되어서는 안 된다는 제약 조건을 추가합니다.
addConstraintOnSameResource	두 작업이 동일한 리소스를 사용해야 한다는 제약 조건을 추가합니다.
addJobSameReservations	작업이 기본 작업과 동일한 시간 슬롯에 대해 용량 예약을 가져야 한다는 제약 조건을 추가합니다.
setPrimaryParallelJob	병렬 작업 세트에서 어떤 작업이 기본 작업인지에 대한 정보를 추가합니다.

솔버

엔진 자체는 기본적으로 맞춤형 휴리스틱이 추가된 특수 제약 조건 솔버입니다. 솔버는 변수와 제약 조건이라는 두 가지 주요 요소를 기반으로 합니다.

변수

변수는 가능한 값의 영역을 나타냅니다. 스케줄링 엔진에는 두 가지 유형의 변수가 있습니다.

• 날짜/시간 변수 - 모든 날짜와 시간의 영역을 가지며, 변수의 시간에 대한 하한과 상한을 서로 가깝게 이동하여 영역을 제한할 수 있습니다.
• 리소스 변수 - 해당 리소스의 도메인을 가지며, 목록에서 리소스를 제거하여 도메인을 제한할 수 있습니다.

제한

제약 조건은 도메인을 제한하여 변수에 작용하지만 변수에 따라 달라지므로 변수가 변경되면 활성화됩니다. "제약 전파" 프로세스는 제약 조건이 주요 기능을 수행하고 성공하면 주요 논리에 다시 보고하는 경우입니다.

변수는 더 이상 제한할 수 없는 경우 바인딩된 것으로 간주됩니다. 이는 날짜/시간 변수의 경우 상한과 하한이 동일함을 의미하고 리소스 변수의 경우 적용 가능한 리소스가 하나만 있음을 의미합니다. 모든 변수가 바인딩되면 솔루션이 검색됩니다.

제한 수준

스케줄링이 자재 소요량 계획(MRP) 적용 단계의 일부로 실행되면 주문은 소요량 일자로부터 뒤로 스케줄링됩니다. 단, 오늘 또는 그 이후에 시작하여 요구일 이전에 종료되는 일정을 찾을 수 없는 경우 오늘부터 앞으로로 일정 방향이 변경됩니다.

이 주요 비즈니스 규칙은 제약 조건을 수준으로 구성하여 처리됩니다. 최고 수준의 제약 조건을 사용할 때 솔루션을 찾을 수 없으면 해당 수준의 제약 조건이 모두 삭제되고 더 낮은 수준이 시도됩니다. 실제로 이는 역방향 스케줄링의 경우 모델에 최대 종료 시간 제약 조건(요구 날짜)이 지정된 가장 늦은 시작 시간의 작업 목표가 있는 수준 1과 가장 빠른 종료 시간과 최소 시간이 주어진 작업 목표가 있는 수준 0이 포함됩니다.

알고리즘

엔진 알고리즘의 주요 단계는 다음과 같습니다.

1. 개별적으로 해결할 수 있는 시퀀스(작업 체인)를 찾습니다.
2. 가장 높은 제약 수준에 대한 시퀀스의 초기 솔루션을 찾으세요.
   1. 시작 작업을 찾을 수 있도록 작업 목표와 우선 순위에 따라 작업을 순서대로 정렬합니다.
   2. 다음 순서로 작업을 반복합니다.
      1. 전파해야 하는 모든 제약 조건을 찾고 전파를 실행합니다.
      2. 작업에 대한 모든 변수가 바인딩된 경우 해당 작업에 대한 솔루션을 찾은 것입니다.
      3. 제약 조건을 위반하지 않고 변수 중 하나를 바인딩할 수 없는 경우 변수 바인딩을 롤백하고 도메인에서 다른 값(리소스 변수에 대해)을 시도하고 제약 조건 전파를 다시 실행합니다.
3. 솔루션이 발견되지 않으면 현재 제약 수준의 모든 제약 조건이 제거되고 제약 조건 수준이 낮아지고(더 낮은 수준이 사용 가능한 경우) 솔루션 검색이 새 제약 조건 세트로 재시도됩니다.
4. 실행 가능한 솔루션이 발견되면 최적화 시간 초과에 도달하거나 모든 리소스 조합이 소진될 때까지 더 나은 솔루션을 찾으려고 시도하는 최적화 단계가 시작됩니다.

제약 조건 솔버는 스케줄링 알고리즘의 세부 사항을 인식하지 못합니다. "매직"이 발생하는 것은 다양한 제약 조건의 정의와 조합입니다.

근무 시간 결정

엔진의 (내부) 제약의 대부분은 리소스의 작업 시간과 용량을 제어합니다. 기본적으로 작업은 주어진 방향으로 주어진 지점에서 리소스에 대한 작업 시간 슬롯을 탐색하고 작업에 필요한 용량(시간)이 들어갈 수 있을 만큼 충분히 긴 간격을 찾는 것입니다.

이를 위해 엔진은 리소스의 작업 시간을 알아야 합니다. 기본 모델 데이터와 달리 작업 시간은 지연 로드되어 필요에 따라 엔진에 로드됩니다. 이 접근 방식을 사용하는 이유는 Supply Chain Management에서 매우 긴 기간 동안 일정에 대한 작업 시간이 종종 있고 일반적으로 많은 일정이 존재하므로 데이터가 미리 로드하기에는 상당히 크기 때문입니다.

캘린더 정보는 엔진에서 X++ 클래스 메소드 WrkCtrSchedulingInteropDataProvider.getWorkingTimes를 호출하여 청크로 요청합니다. 특정 시간 간격의 특정 캘린더 ID에 대한 요청입니다. Supply Chain Management의 서버 캐시 상태에 따라 이러한 각 요청은 여러 데이터베이스 호출로 끝날 수 있으며 시간이 오래 걸립니다(순수 계산 시간에 비해). 또한 달력에 하루에 많은 작업 시간 간격이 있는 매우 정교한 작업 시간 정의가 포함되어 있으면 로드 시간이 늘어납니다.

작업 시간 데이터가 일정 엔진에 로드되면 이는 특정 일정에 대한 내부 캐시에 유지됩니다. 즉, 다른 작업이나 리소스가 동일한 일정을 사용하는 경우 메모리에서 다음 조회를 빠르게 수행할 수 있습니다. 성능 저하의 일반적인 원인 중 하나는 각 리소스에 대해 별도의 캘린더 ID가 사용되는 경우입니다. 그러면 캘린더의 내용이 같더라도 각 캘린더에 대해 데이터를 요청해야 하기 때문입니다.

한정된 용량

한정된 용량을 사용하는 경우 캘린더의 작업 시간 슬롯이 기존 용량 예약을 기반으로 분할 및 축소됩니다. 이 예약도 달력과 같은 WrkCtrSchedulingInteropDataProvider 클래스를 통해 가져오지만 대신 getCapacityReservations 메서드를 사용합니다. 기준 계획 중 스케줄링할 때 특정 기준 계획에 대한 예약이 고려되며 기준 계획 매개 변수 페이지에서 활성화된 경우 확정 생산 주문의 예약도 포함됩니다. 유사하게, 생산 주문을 스케줄링할 때 기존 계획 주문의 예약을 포함하는 옵션도 있지만 이는 반대의 경우만큼 일반적이지는 않습니다.

한정된 용량을 사용하면 다음과 같은 몇 가지 이유로 일정이 더 오래 걸립니다.

• 데이터베이스에서 용량 정보를 가져오는 것은 느린 작업이며 용량 정보의 서버 측 캐싱은 일반적으로 캘린더와 같은 리소스 간에 공유되지 않기 때문에 일반적으로 작업 시간만큼 좋지 않습니다.
• 이동하는 작업 시간 슬롯의 수는 분할로 인해 증가하며 일반적으로 솔루션을 찾기 전에 더 긴 시간 동안의 슬롯을 조사해야 합니다.
• 스케줄링이 완료된 후 충돌하는 예약에 대한 확인을 수행해야 합니다(자세한 내용은 "스케줄링 엔진 병렬 실행" 섹션 참조).

리소스 조합 검사

작업 순서에 표준 FinishStart 링크만 포함되어 분기가 없는 단순한 체인을 형성하는 경우 첫 번째 작업에 대한 최상의 솔루션을 찾은 다음 이동하여 최적의 결과(주문 전체가 아닌 단일 주문에서 볼 수 있음)를 얻을 수 있습니다. 다음 작업을 위한 최상의 솔루션을 찾기 위해 계속됩니다. 작업에 대한 최상의 솔루션은 여전히 제약 조건을 준수하면서 작업 목표에 가장 가까운 작업의 시작 날짜와 종료 날짜를 가져올 수 있는 리소스를 찾는 것입니다(앞으로 스케줄링에서 이는 작업의 종료 날짜를 가능한 한 빨리 가져오는 것을 의미함).

병렬 작업이 있는 경우 솔루션을 찾는 데 다양한 리소스 조합을 조사해야 할 수 있습니다. 가능한 리소스 조합의 수는 연결된 병렬 작업에 대해 적용 가능한 리소스 수의 곱입니다. 특히 요구 사항 날짜에서 뒤로 주문을 예약할 때 논리가 모든 조합을 확인해야 하므로 오늘 날짜 이전에 병렬 작업을 맞추는 문제에 대한 해결이 없다는 것을 깨닫는 데 꽤 오랜 시간이 걸릴 수 있습니다. 효율성이 더 높은 일부 리소스나 결과를 제공할 수 있는 다른 일정이 있을 수 있기 때문입니다. 즉, 타임아웃 제한이 설정되지 않은 경우 방향을 정방향으로 변경하기 전에 오랫동안 실행됩니다.

이 조합 논리는 적용 가능한 리소스를 더 추가하면 엔진 실행 속도가 느려질 수 있음을 의미합니다. 병렬 작업 및 무한 용량의 스케줄링 시 성능 문제가 발생하는 경우 경로 설계자가 어떤 리소스를 사용해야 하는지 결정한 다음 작업에 직접 리소스를 할당하도록 하여 부분적으로 수정할 수 있습니다(대부분의 경우 엔진이 항상 동일한 리소스를 선택하므로 최종 결과는 동일합니다).

하드 링크

두 작업 간의 링크 유형을 하드로 설정하면 한 작업의 완료와 다음 작업의 시작 사이에 시간 간격이 없습니다. 이것은 금속이 한 작업에서 가열된 후 다음 작업에서 처리되는 경우와 같은 시나리오에서 매우 유용할 수 있습니다.

표준 소프트 링크 및 순방향 스케줄링을 사용하여 경로가 분기 없이 단순한 체인을 구성하는 경우, 자체 제약 조건을 충족하는 첫 번째 작업에 대한 솔루션을 찾은 다음 해당 경로에서 이전 작업에서 다음 작업으로 종료 시간을 전파하는 체인을 통해 이동하여 결과를 얻을 수 있습니다. 현재 작업에서 용량을 찾을 수 없는 경우 이전 작업이 잠재적으로 작업 사이에 간격을 만드는 결과 없이 시작 시간을 더 멀리 이동합니다. 그러나 동일한 시나리오에 대한 하드 링크(특히 유한 용량과 관련하여)에서 체인의 나중에 하나의 작업이 용량을 찾을 수 없다는 사실은 이전에 예약된 모든 작업을 하나씩 "끌어다 놓아야" 하고 그에 따라 몇 번이고 일정을 조정해야 한다는 것을 의미합니다. 특히 여러 리소스에 대한 로드가 높은 시나리오에서 하드 링크는 작업이 서로 영향을 미치고 결과가 실행 가능한 일정으로 안정화되기 전에 많은 반복을 수행해야 하는 연쇄 반응을 일으킬 수 있습니다.

스케줄링 엔진을 병렬로 실행

도우미가 사용되는 기준 계획 실행의 일부로 일정을 수행할 때 각 기준 계획 도우미 스레드는 생산 주문 일정 작업을 선택할 수도 있습니다. 이는 여러 스케줄링 엔진이 동시에 실행될 수 있음을 의미합니다. 일반적으로 멀티스레딩은 매우 중요한 성능 이점이지만 스케줄링과 관련하여 몇 가지 기능적 단점도 있습니다.

MRP에서 주어진 BOM(자재 명세서) 수준에 대한 모든 생산 주문은 요구 사항 날짜 순서대로 스케줄링됩니다. 즉, 가장 빠른 요구 사항 날짜가 있는 주문이 먼저 스케줄링되어 가용 자원 능력을 얻을 가능성이 가장 높습니다. 그러나 예약되지 않은 주문 목록에서 여러 엔진을 선택하면 하나가 다른 것보다 더 빨리 완료될 수 있으므로 순서가 더 이상 보장되지 않습니다.

또한 유한한 용량을 사용하여 예약할 때와 여러 엔진 인스턴스가 동일한 시간 간격에 동일한 리소스를 잠재적으로 사용하는 주문을 예약하려고 할 때 경쟁 조건이 발생할 수 있습니다. 이러한 경쟁 조건의 수는 기준 계획 기록 페이지의 스케줄링 충돌 필드에 기록됩니다. 충돌 해결 논리는 다음과 같습니다.

• 주문(잠금 없음)을 예약하고 용량 예약을 받습니다.
• 잠금을 진행합니다.
• 일정 기간 동안 예약된 리소스에 대한 최신 용량 예약이 있는지 확인합니다.
  • 아니요인 경우 용량을 기록하고 잠금을 해제합니다.
  • 예일 경우 잠금을 해제하고 처음부터 주문을 다시 예약합니다.

따라서 여러 엔진 인스턴스로 스케줄링할 때 각 스레드의 정확한 타이밍에 따라 결과가 완전히 결정적이지 않습니다.

작업 스케줄링 성능

작업 스케줄링은 엔진의 관점에서 볼 때 개략 용량 계획이라고도 하지만 타당성을 결정하기 위해 더 많은 데이터가 필요하기 때문에 유한 용량을 사용하는 경우 해결하기 어려운 문제가 될 수 있습니다.

리소스 그룹의 용량은 리소스 그룹의 구성원인 리소스와 리소스 수에 따라 다릅니다. 리소스 그룹 자체에는 용량이 없습니다 리소스가 그룹의 구성원인 경우에만 용량이 생깁니다. 리소스 그룹 구성원은 시간이 지남에 따라 달라질 수 있으므로 용량을 매일 평가해야 합니다.

작업 예약에서 리소스 그룹의 캘린더는 각 작업의 시작 및 종료 시간을 결정하는 데 사용됩니다. 즉, 리소스 그룹의 달력은 한 리소스 그룹에서 하루에 한 작업에 대해 작업을 예약할 수 있는 시간에 제한을 둡니다. 특정 자원에 대한 달력과 반대로 자원 그룹에 대한 달력의 효율성 데이터는 실제 용량이 아니라 단순히 영업 시간을 나타내므로 무시됩니다.

예를 들어 특정 날짜의 리소스 그룹 작업 시간이 8:00~16:00인 경우 한 작업으로 리소스 그룹에 로드할 수 있는 로드가 8시간에 해당하는 것보다 클 수는 없습니다. 해당 날짜에 리소스 그룹이 사용할 수 있는 총 용량입니다. 그러나 사용 가능한 용량은 로드를 더 제한할 수 있습니다.

자원 그룹에 포함된 모든 자원에 대한 작업 스케줄링으로 인한 로드는 같은 날 자원 그룹의 가용 용량을 계산할 때 고려됩니다. 각 날짜에 대한 계산은 다음과 같습니다.

사용 가능한 리소스 그룹 용량 = 달력을 기반으로 한 그룹의 리소스 용량 – 그룹의 리소스에 대한 작업 예약 로드 – 그룹의 리소스에 대한 작업 예약 로드 – 리소스 그룹에 대한 작업 예약 로드

경로 작업의 리소스 요구 사항 탭에서 리소스 요구 사항은 특정 리소스(이 경우 작업은 해당 리소스를 사용하여 예약됨), 리소스 그룹, 리소스 유형 또는 하나 이상의 능력, 기술, 과정 또는 인증서를 사용하여 지정할 수 있습니다. 이러한 모든 옵션을 사용하면 경로 설계에 큰 유연성을 제공하지만 용량은 "속성"(능력, 기술 등에 대해 엔진에서 사용되는 추상 이름)별로 설명되어야 하므로 엔진 일정을 복잡하게 만듭니다.

기능에 대한 리소스 그룹의 용량은 해당 기능이 있는 리소스 그룹의 모든 리소스에 대한 용량의 합계입니다. 그룹의 리소스에 기능이 있으면 필요한 용량 수준에 관계없이 고려됩니다.

작업 스케줄링에서 리소스 그룹의 특정 기능에 대해 사용 가능한 용량은 해당 기능이 필요한 작업으로 로드될 때 감소합니다. 작업에 둘 이상의 기능이 필요한 경우 필요한 모든 기능에 대해 용량이 줄어듭니다.

각 날짜에 필요한 계산은 다음과 같습니다.

기능에 사용 가능한 용량 = 기능에 대한 용량 – 리소스 그룹에 포함된 특정 기능이 있는 리소스에 대한 작업 예약 로드 – 리소스 그룹에 포함된 특정 기능이 있는 리소스에 대한 작업 예약 로드 – 리소스 그룹에 포함된 작업 예약 로드 특정 기능이 필요한 리소스 그룹 자체

즉, 특정 리소스에 대한 로드가 있는 경우 특정 리소스에 대한 로드가 다음 상황에 관계없이 리소스 그룹의 능력에 대한 기여도를 감소시키기 때문에 능력당 리소스 그룹의 가용 용량을 계산할 때 로드가 고려됩니다. 특정 리소스에 대한 로드는 해당 특정 기능에 대한 것입니다. 리소스 그룹 수준에 로드가 있는 경우 로드가 특정 기능을 필요로 하는 작업에서 발생한 경우에만 기능당 리소스 그룹의 가용 용량 계산에서 고려됩니다.

위의 논리는 각 유형의 "속성"에 대해 동일하기 때문에 복잡하므로 유한 용량으로 작업 일정을 사용하려면 상당한 양의 데이터를 로드해야 합니다.

향상된 MRP 성능

다음 기술 컨퍼런스 동영상에서는 더 이상 사용되지 않는 마스터 계획 엔진과 함께 MRP를 사용할 때 마스터 계획 성능을 향상시키는 방법에 대한 몇 가지 팁을 제공합니다. 도와주세요! MRP가 느립니다!.

스케줄링 엔진 입력 및 출력 보기

스케줄링 프로세스의 입력 및 출력에 대한 특정 세부 정보를 얻으려면 조직 관리 > 설정 > 스케줄링 > 추적 조종석 스케줄링으로 이동하여 로깅을 활성화합니다.

이 페이지에서 먼저 작업 창에서 로깅 사용을 선택합니다. 그런 다음 생산 주문에 대한 스케줄링을 실행합니다. 완료되면 추적 조종석 예약 페이지로 돌아가서 작업 창에서 로깅 사용 중지를 선택합니다. 페이지를 새로 고치면 그리드에 새 줄이 나타납니다. 새 줄을 선택하고 작업 창에서 다운로드를 선택합니다. 그러면 다음 파일이 포함된 .zip 압축 폴더가 생성됩니다.

• Log.txt - 엔진이 거치는 단계를 설명하는 로그 파일입니다. 매우 정교하고 다소 부담을 수 있지만 성능 문제를 해결하기 위해 경로 설정을 실험하는 일부로 사용할 때 가장 먼저 찾아야 할 것은 첫 번째 줄과 마지막 줄 사이의 시간 차이입니다. 이는 스케줄러가 보낸 정확한 시간이기 때문입니다.
• XmlModel.xml - 여기에는 X++로 빌드되고 엔진이 작동하는 모델이 포함됩니다. 파일에 사용된 JobId는 작업(ReqRouteJob 또는 ProdRouteJob)이 포함된 소스 테이블의 RecId와 상관 관계가 있습니다. 이 파일에서 일반적으로 찾아볼 수 있는 것은 ConstraintJobStartsAt과 ConstraintJobEndsAt에 주어진 날짜가 예상대로이고 JobGoal 속성이 올바르게 설정되어 있으며 JobLink 제약을 통해 작업이 서로 관련되어 있다는 것입니다.
• XmlSlots.xml - 여기에는 엔진이 요청한 모든 작업 시간 및 용량 예약이 포함됩니다. 달력 작업 시간 및 예약은 작업(및 추가 버퍼)을 배치하려고 시도하는 기간 동안만 엔진에서 요청하므로 파일에 매우 먼 미래의 시간이 포함되어 있으면 설정에 문제가 있습니다. ResourceProperty 노드는 각 리소스에 대해 어떤 리소스 그룹과 기능이 어떤 기간 동안 연결되어 있는지 표시합니다.
• Result.xml - 스케줄링 실행의 결과를 포함합니다.

추적 기능은 상당한 성능 오버헤드를 추가할 수 있으므로 제어된 방식으로 특정 주문의 일정을 조사하는 데만 사용하세요. 기준 계획 실행 중에 켜져 있으면 크기 제한에 빠르게 도달하여 중지됩니다.

성능 문제 해결

모든 이전 섹션에서 이해할 수 있듯이 스케줄링 엔진의 설정 및 사용과 관련하여 성능 문제를 유발할 수 있는 몇 가지 함정이 있습니다. 다음 체크리스트는 이러한 문제를 해결하는 데 사용할 수 있습니다. 여러 가지 요인이 복합적으로 작용하여 문제를 일으키는 경우가 대부분이므로 모든 점을 살펴보는 것이 중요합니다.

필요하지 않을 때 MRP의 일부로 스케줄링 수행

경로가 비용 계산 및 보고와 같은 생산 제어 목적으로 사용되더라도 MRP 중에 경로를 고려할 필요가 없을 수도 있습니다. 어떤 경우에는 항목에 대해 표준 생산 리드 타임을 지정하면 계획에 충분합니다. 라우트 스케줄링을 끄려면 용량 타임펜스를 0으로 설정하세요. 스케줄링을 수행해야 하는 경우 MRP의 적용 범위 타임펜스 전체 범위에 대한 경로를 고려할 필요가 없을 수 있으므로 용량 타임펜스를 신중하게 설정해야 합니다.

주문이 MRP 동안 스케줄링되지 않은 경우 계획 주문이 확정될 때 대신 스케줄링해야 합니다. 이는 확정 프로세스가 더 오래 걸린다는 것을 의미하므로 제안된 계획 주문 중 확정되는 수에 따라 MRP 동안 성과 이득이 확정 시 손실될 수 있습니다.

불필요한 작업이 있는 경로

경로를 설계할 때 프로덕션이 거치는 모든 단계와 함께 실제 세계를 정확하게 모델링하려고 하는 유혹이 있습니다. 이것은 어떤 경우에는 유용할 수 있지만 엔진이 작업해야 하는 모델이 더 커지고(작업 및 제약 조건 측면에서) 더 많은 SQL 구문이 작업과 용량 예약의 삽입 및 업데이트를 위해 실행되기 때문에 성능에 좋지 않습니다. 또한 최종적으로 작업 진행 상황을 보고해야 하는 다운스트림 효과가 있으며 이는 자동 전기로 완화될 수 있습니다. 데이터를 아무 용도로 사용하지 않으면 불필요한 로드가 발생합니다.

예약(일반적으로 병목 리소스) 및/또는 비용 계산 목적에 엄격하게 필요한 작업만 생성하는 것이 좋습니다. 또는 많은 작은 개별 작업을 프로세스의 더 큰 부분을 나타내는 하나의 큰 작업으로 그룹화해야 합니다.

작업에 적용 가능한 많은 리소스

작업에 적용할 수 있는 리소스의 수는 작업 관계에 설정된 리소스 요구 사항에 따라 결정됩니다. 요구 사항은 특정(개별) 리소스에 대한 요구 사항이거나 리소스 그룹 또는 기능의 리소스 구성원 자격을 기반으로 할 수 있습니다.

유한 능력을 사용하여 스케줄링이 수행되지 않고 적용 가능한 모든 리소스가 동일한 달력 및 효율성을 갖는 경우 스케줄링 엔진은 항상 공정에 대해 동일한 리소스를 선택하게 되지만 해당 리소스가 다른 것보다 "더 나은" 리소스인지 확인하기 위해 모든 적용 가능한 리소스를 시도한 후에만 종료됩니다. 이 경우 경로 설계 시 항상 특정 리소스를 작업에 할당하는 것만으로도 스케줄링의 부담을 크게 줄일 수 있습니다.

병렬 작업이 있는 경로

병렬 작업(1차/2차)은 특정 작업을 수행하는 데 기계와 작업자가 모두 필요한 경우와 같은 시나리오를 모델링하는 강력한 도구이지만 많은 성능 문제의 원인이기도 합니다. 특정 개별 자원에 대한 요구 사항이 기본 및 보조 작업 모두에 할당된 경우 일반적으로 문제가 되지 않습니다. 그러나 각 작업에 대해 가능한 리소스가 많으면 일정에 상당한 계산 복잡성이 추가됩니다.

병렬 작업을 사용하는 대신 쌍을 "가상" 리소스로 모델링하거나(그러면 작업을 위해 항상 함께 가는 팀을 나타냄) 병목 현상을 나타내지 않는 경우 작업 중 하나를 단순히 모델링하지 않습니다.

리소스 양이 1보다 많은 경로

작업에 필요한 리소스의 양이 1보다 크면 여러 병렬 작업이 엔진으로 전송되기 때문에 기본/보조 작업을 사용하는 것과 사실상 동일한 결과가 나타납니다. 그러나 이 경우 특정 리소스 할당을 사용하는 것이 불가능합니다. 1보다 큰 수량은 작업에 둘 이상의 리소스를 적용해야 하기 때문입니다.

리소스 로드 수량이 1보다 큰 보조 작업은 기본 작업의 각 리소스에 지정된 수량의 보조 리소스가 필요함을 의미합니다. 예를 들어, 기본 작업의 리소스 수량이 2로 설정되고 보조 작업의 리소스 수량이 3으로 설정된 경우 보조 작업에는 총 6개의 리소스가 필요합니다.

한정된 용량의 과도한 사용

한정된 용량을 사용하려면 엔진이 데이터베이스에서 용량 정보를 로드해야 하고 특히 리소스가 최대 용량에 가깝게 예약되어 있는 환경에서 솔루션을 찾기가 더 어렵기 때문에 계산 오버헤드가 있을 수 있습니다. 결과적으로 리소스가 실제로 한정된 용량을 사용해야 하는지 아니면 초과 예약될 수 있는지 신중하게 평가하는 것이 중요합니다. 유한 용량 리소스 간에 초과 예약하지 않는 것이 얼마나 중요한지에 차이가 있을 수 있으므로 "병목 리소스에 대한 용량 타임펜스" 계획의 별도 값과 함께 리소스에 병목 옵션을 사용하는 것이 좋습니다. 병목 현상 개념을 사용하면 일반적인 유한 용량 타임펜스를 낮출 수 있습니다.

하드 링크 설정

경로의 표준 링크 유형은 소프트입니다. 즉, 한 작업의 완료 시간과 다음 작업의 시작 사이에 시간 간격이 허용됩니다. 이를 허용하면 작업 중 하나에 자재 또는 용량을 매우 오랫동안 사용할 수 없는 경우 생산이 꽤 오랫동안 유휴 상태가 되어 진행 중인 작업이 증가할 수 있는 불행한 결과가 발생할 수 있습니다. 마무리와 시작이 완벽하게 정렬되어야 하기 때문에 하드 링크에서는 이런 일이 발생하지 않습니다. 그러나 하드 링크를 설정하면 작업의 두 리소스에 대해 작업 시간과 용량 교차를 계산해야 하므로 일정 문제가 더 어려워집니다. 병렬 작업도 관련된 경우 상당한 계산 시간이 추가됩니다. 두 작업의 리소스에 전혀 겹치지 않는 다른 달력이 있는 경우 문제를 해결할 수 없습니다.

하드링크는 꼭 필요한 경우에만 사용하는 것을 권장하며, 각 경로의 운영에 필요한지 여부를 신중히 고려하시기 바랍니다.

하드 링크를 적용하지 않고 진행 중인 작업을 줄이기 위한 트릭은 두 번째 패스에 대해 반대 방향으로 변경하면서 순서를 두 번 예약하는 것입니다. 첫 번째 일정이 배달 날짜보다 뒤로 수행된 경우 두 번째 일정은 예정된 시작 날짜부터 앞으로 수행해야 합니다. 이렇게 하면 작업이 최대한 압축되어 진행 중인 작업이 최소화됩니다.

각 리소스에 대한 별도의 캘린더

스케줄링 엔진의 주요 데이터 소스 중 하나는 데이터베이스에서 로드하는 데 비용이 많이 들 수 있는 달력 정보입니다. 달력은 템플릿을 기반으로 생성되기 때문에 각 자원에 대한 달력을 생성한 다음 자원에 가동 중지 시간 및 기타 문제가 있는 경우 이 달력의 정보를 조정하고 싶을 것입니다. 그러나 이렇게 하면 각 리소스에 대해 새 데이터를 요청해야 하고 성능 문제의 큰 원인이 될 수 있으므로 엔진이 캘린더 데이터를 캐시하는 기능을 심각하게 제한합니다. 대신 리소스 간에 캘린더를 최대한 재사용한 다음 일정 기간 동안 다른 캘린더 ID를 할당하여 가동 중지 시간 변경을 제어하는 것이 좋습니다.

달력일당 많은 근무 시간 슬롯

엔진은 용량에 대해 시간 슬롯을 하나씩 검사하여 작동하므로 달력 일당 시간 슬롯 수를 최소화하는 것이 좋습니다. 예를 들어, 작업자가 매시간 5분의 휴식 시간을 갖는다는 것을 결과 일정에 반영하는 것이 중요한지 여부를 고려하여 이를 수행할 수 있습니다.

큰(또는 없음) 일정 시간 초과

스케줄링 엔진 성능은 스케줄링 매개 변수 페이지에 있는 매개 변수를 사용하여 최적화할 수 있습니다. 예약 시간 초과 사용 및 예약 최적화 시간 초과 사용 설정은 항상 예로 설정해야 합니다. 아니요로 설정하면 많은 옵션이 있는 실행 불가능한 경로가 생성된 경우 일정이 잠재적으로 무한대로 실행될 수 있습니다.

시퀀스당 최대 예약 시간 값은 단일 시퀀스(대부분의 경우 시퀀스는 단일 주문에 해당)에 대한 솔루션을 찾는 데 사용할 수 있는 최대 시간(초)을 제어합니다. 여기서 사용할 값은 경로의 복잡성과 유한한 용량과 같은 설정에 따라 크게 달라지며, 최대 약 30초가 좋은 출발점입니다.

최적화 시도 시간 초과 값은 원래 찾은 것보다 더 나은 솔루션을 찾는 데 사용할 수 있는 시간(초)을 제어합니다. 이는 병렬 작업을 사용하는 경로에만 영향을 미치므로 서로 다른 조합을 테스트해야 합니다.

참고

시간 초과에 대해 설정된 값은 MRP의 일부로 릴리스된 생산 주문 및 계획 주문의 스케줄링에 모두 적용됩니다. 결과적으로 계획된 생산 주문이 많은 계획을 실행할 때 매우 높은 값을 설정하면 MRP의 실행 시간이 크게 늘어날 수 있습니다.