Повышение производительности подсистемы планирования

Подсистема планирования ресурсов используется при планировании маршрутов для запланированных и выпущенных производственных заказов. Подсистема первоначально была выпущена как часть Dynamics AX 2012 и претерпела несколько улучшений с момента ее выпуска.

Проблема планирования производственных заданий является чрезвычайно сложной комбинаторной проблемой, в которой время решения растет экспоненциально с количеством переменных принятия решения. Часто клиенты настраивают маршруты производства и соответствующие данные таким образом, что проблема планирования не может быть решена за разумное время даже на самом современном оборудовании. Эта статья поможет понять подсистему планирования и определить влияние определенной настройки на производительность.

Когда дело доходит до повышения производительности планирования, общие рекомендации рекомендуют уменьшить сложность проблемы, которую должна решить подсистема. Ниже приведены основные факторы, которые могут повлиять на производительность:

• Маршруты с большим количеством операций
• Маршруты с параллельными операциями
• Операции с количеством ресурсов более единицы
• Операции с многими применимыми ресурсами
• Использование жестких связей
• Использование ограничения по мощности
• Число различных используемых календарей
• Число интервалов рабочего времени в день в календаре
• Общая длительность маршрута
• Параллельное выполнение нескольких подсистем планирования

Обзор основного потока планирования

Чтобы понять, как данная настройка может влиять на производительность, важно понять, как выполняется процесс, как внутри подсистемы, так и в коде 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

При отправке этого в подсистему он разделяется на восемь заданий, как показано на следующем рисунке (выберите изображение, чтобы увеличить его).

Стандартная связь между двумя заданиями — это FinishStart, что означает, что время завершения одного задания должно предшествовать времени начала другого задания. Так как эта настройка должна выполняться тем же ресурсом, который позже выполнит процесс, существуют ограничения OnSameResource между ними. Между заданиями для первичной и вторичной операции для 10 имеются связи StartStart и FinishFinish, что означает, что задания должны начинаться и заканчиваться одновременно, и существуют ограничения NotOnSameResource, которые не допускают один и тот же ресурс для первичной и вторичной операций.

Для операции 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	Добавляет сведения о том, что задание является основным заданием в наборе параллельных заданий.

Решатель

Сама по себе подсистема является специализированным средством решения ограничений с добавленными настраиваемыми эвристиками. Поиск решения базируется на двух основных элементах: переменных и ограничениях.

Переменная

Переменная представляет домен возможных значений. Подсистема планирования имеет два типа переменных:

• Переменная DateTime — имеет домен всех дат и времени, и этот домен можно ограничить, переместив нижнюю и верхнюю границы для времени переменных ближе друг к другу.
• Переменная ресурса — имеет домен применимых ресурсов, и этот домен может быть ограничен путем исключения ресурсов из списка.

Ограничение

Ограничение действует на переменные путем ограничения их доменов, но оно также зависит от переменных, так что оно активируется при изменении переменных. Процесс "распространение ограничения" происходит в том случае, когда ограничение выполняет свою основную функцию и сообщает основной логике, было ли выполнение успешным.

Переменная считается связанной, если ее дальнейшее ограничение невозможно, что для переменной DateTime означает, что верхние и нижние границы одинаковы, и для переменной ресурса означает, что она имеет только один подходящий ресурс. Когда все переменные связаны, найдено решение.

Уровни ограничений

Когда планирование выполняется как часть этапа покрытия планировании потребностей в материалах (MRP), заказы будут планироваться назад от даты потребности. Однако, если невозможно найти график, который начинается сегодня или позднее и заканчивается до даты потребности, то направление планирования изменится на "вперед от текущей даты".

Это основное бизнес-правило обрабатывается путем организации ограничений в уровнях. Если при использовании ограничений на самом высоком уровне решения не обнаружены, то все ограничения на этом уровне удаляются, и выполняется попытка на более низком уровне. На практике это означает, что при обратном планировании модель будет содержать уровень 1 с целями задания с самым последним временем начала при заданном максимальном ограничении времени окончания (датой потребности) и уровнем 0 с целями задания более раннего времени окончания и заданным значением минимального ограничения времени начала, равным текущей дате.

Алгоритм

Основные этапы алгоритма подсистемы следующие:

1. Поиск последовательностей (цепочек заданий), которые могут быть решены отдельно.
2. Попытка найти исходное решение для последовательности с максимальным уровнем ограничения.
   1. Сортировка заданий в последовательности на основе целей и приоритетов заданий, чтобы можно было найти начальное задание.
   2. Просмотр заданий в цикле в следующем порядке:
      1. Поиск всех ограничений, которые необходимо распространить, и выполнение распространения.
      2. Если все переменные для задания связаны, то обнаружено решение для этого задания.
      3. Если одну из переменных невозможно связать без нарушения ограничений, выполняется откат привязки переменных, опробуется другое значение в домене (для переменной ресурса) и перезапускается распространение ограничения.
3. Если решение не найдено, удаляются все ограничения на текущем уровне ограничения, уровень ограничения снижается (если доступны более низкие уровни) и повторный поиск решения выполняется с новым набором ограничений.
4. Если подходящее решение было обнаружено, будет запущен этап оптимизации, который попытается найти лучшее решение, пока не будет достигнуто время ожидания оптимизации либо все сочетания ресурсов не будут исчерпаны.

Средство решения ограничений не знает о специфике алгоритма планирования. Вся "магия" происходит при определении и сочетании различных ограничений.

Определение значений рабочего времени

Большая часть (внутренних) ограничений в подсистеме управляет рабочим временем и емкостью ресурса. Фактически задача состоит в том, чтобы пройти по интервалам рабочего времени для ресурса, начиная с заданной точки, в определенном направлении, и найти достаточно длинный интервал, в течение которого требуемая мощность (время) для задания может поместиться.

Для этого подсистеме необходимо знать значения рабочего времени ресурса. В отличие от основной модели данных, значения рабочего времени загружаются с отложенным запуском, то есть они загружаются в подсистему по мере необходимости. Причиной этого подхода является то, что часто существуют значения рабочего времени в Supply Chain Management для календаря в течение очень долгого времени, и обычно существует много календарей, так что данные могут быть очень большими для предварительной загрузки.

Сведения о календаре запрашиваются подсистемой в виде фрагментов путем вызова метода класса X++ WrkCtrSchedulingInteropDataProvider.getWorkingTimes. Этот запрос предназначен для определенного кода календаря в заданном интервале времени. В зависимости от состояния кэша сервера в Supply Chain Management каждый из этих запросов может закончиться в нескольких вызовах базы данных, что занимает много времени (относительно чистого времени вычислений). Кроме того, если календарь содержит очень сложные определения рабочих часов с множеством интервалов рабочего времени в день, это увеличивает время загрузки.

Когда данные о рабочем времени загружаются в подсистему планирования, это сохраняется во внутреннем кэше для соответствующего календаря, что означает, что если какие-либо другие задания или ресурсы используют этот же календарь, следующие операции подстановки могут быть выполнены быстро из памяти. Одна из наиболее частых причины плохой производительности состоит в том, что для каждого ресурса используется отдельный код календаря, так как в этом случае необходимо запрашивать данные для каждого календаря, даже если содержимое календарей может быть одинаковым.

Ограничение по мощности

При использовании ограничения по мощности размеры ячеек рабочего времени из календаря разбиваются и уменьшаются на основе существующих резервирований мощностей. Эти резервирования также выбираются с помощью того же класса WrkCtrSchedulingInteropDataProvider, что и календари, но вместо этого используется метод getCapacityReservations. При планировании при сводном планировании учитываются резервирования для данного сводного плана и, если это разрешено на странице Параметры сводного планирования, также включаются резервирования из утвержденных производственных заказов. Аналогично, при планировании производственного заказа также можно включить резервирования из существующих спланированных заказов, хотя это используется не так часто, как обратное.

Использование ограничения по мощности приведет к тому, что планирование займет больше времени из-за нескольких причин:

• Выборка сведений о емкости из базы данных является медленным действием, и кэширование сведений о емкости на стороне сервера обычно работает не так хорошо, как и в случае значений рабочего времени, поскольку обычно они не являются общими для ресурсов, в отличие от календарей.
• Число интервалов рабочего времени для перебора увеличивается увеличение из-за разбиения, а также интервалы для более долгого периода времени должны обычно исследоваться, прежде чем можно будет найти решение.
• После завершения планирования необходимо выполнить проверку на наличие конфликтующих резервирований (подробные сведения см. в разделе "Параллельное выполнение нескольких подсистем планирования").

Изучение комбинаций ресурсов

Если последовательность заданий содержит только стандартные ссылки FinishStart, то есть она образует простую цепь без ветвей, оптимальный результат (с точки зрения отдельного заказа, а не по всем заказам) может быть достигнут путем поиска лучшего решения для первого задания, а затем поиска лучшего решения для следующего задания. Наилучшим решением для задания является поиск ресурса, который может получить начальную и конечную даты задания, ближайшие к цели задания (при планировании вперед это означает получение конечной даты задания как можно раньше), в то же время учитывая ограничения.

При наличии параллельных заданий поиск решения может включать в себя анализ различных комбинаций ресурсов. Число возможных комбинаций ресурсов равно произведению количества применимых ресурсов для связанных параллельных заданий. В частности, при планировании заказа в обратном направлении от даты потребности логика может потратить много времени, чтобы выяснить, что нет решения проблемы, которая позволит уместить параллельные задания до сегодняшней даты, так как в этом случае потребуется проверить все комбинации, так как могут быть некоторые ресурсы с большей эффективностью или другим календарем, которые могут дать результат. Это означает, что если ограничение времени ожидания не было задано, логика будет работать в течение длительного времени перед переходом на направление вперед.

Эта комбинаторная логика также означает, что при дополнительном увеличении числа соответствующих ресурсов подсистема может работать еще медленнее. Если проблемы с производительностью возникают при использовании параллельных операций и планировании с бесконечной мощностью, это можно частично исправить, если конструктор маршрута принимает решение о том, какой ресурс следует использовать, а затем назначет ресурс непосредственно в операции (поскольку в большинстве случаев подсистема всегда будет выбирать один и тот же ресурс, поэтому конечный результат будет одинаковым).

Жесткие связи

Задание типа связи между двумя заданиями на жесткое позволяет гарантировать отсутствие разрыва по времени между окончанием одного задания и началом следующего. Это может быть очень полезно в сценариях, например, когда металл нагревается в одном задании, а затем обрабатывается в следующем задании, где нежелательно, чтобы металл в промежутке остыл.

При стандартных мягких связях и прямом планировании если маршрут образует простую цепь без ветвей, результат можно получить, выполнив поиск решения для первого задания, удовлетворяющего собственным ограничениям, и затем перемещаясь по цепочке, выполняя распространение времени окончания предыдущего задания на следующее задание. Если текущее задание не может найти никакой мощности, время начала для него будет перемещено далее без последствий для предыдущих заданий, что потенциально создает зазоры между заданиями. Однако при работе с жесткими связями (особенно в связи с ограничением по мощности) для того же сценария тот факт, что одно задание далее в цепи не может найти емкость, означает, что все предыдущие запланированные задания придется "перетаскивать" по одному и, таким образом, перепланировать несколько раз. Жесткие связи, особенно в сценариях с высокой загрузкой для нескольких ресурсов, могут вызывать цепную реакцию, в которой задания влияют друг на друга, и необходимо выполнить несколько итераций, прежде чем результат будет стабилизироваться до появления подходящего графика.

Параллельное выполнение подсистем планирования

При планировании в процессе выполнения сводного планирования, когда используются помощники, все вспомогательные потоки сводного планирования также могут скомплектовать задачи по планированию производственных заказов. Это означает, что в одно и то же время может выполняться несколько подсистем планирования. Хотя многопоточность в общем случае дает очень значительной выигрыш в производительности, при планировании могут также быть некоторые функциональные недостатки.

В MRP все производственные заказы данного уровня спецификации (BOM) планируются в последовательности дат потребности, то есть заказы с самой ранней датой потребности должны быть запланированы первыми и тем самым получит наибольшую шансы получить доступную мощность ресурса. Однако когда несколько подсистем выбирают из списка незапланированных заказов, последовательность больше не гарантируется, так как одна подсистема можно завершиться быстрее, чем другая.

Кроме того, при планировании с ограничением по мощности и при попытке нескольких экземпляров подсистем планировать заказы, которые потенциально могут использовать одни и те же ресурсы за один и тот же интервал времени, может произойти условие гонки. Количество таких состояний гонки записывается в поле Конфликты планирования на странице журнала сводных планов. Логика разрешения конфликтов выглядит следующим образом:

• Планирование заказа (без блокировки) и получение резервирований мощности.
• Выполнение блокировки.
• Проверка наличия более новых резервирований мощности для запланированных ресурсов в интервале времени.
  • Если нет, зазаписывается емкость и освобожается блокировка.
  • Если да, снимается блокировка и заказ перепланируется с начала.

Таким образом, при планировании с использованием нескольких экземпляров подсистемы результат не является полным детерминированным, поскольку он будет зависеть от точного времени каждого из потоков.

Производительность планирования операций

Хотя планирование операций также известно как грубое планирование загрузки, наблюдаемое с точки зрения подсистемы, это может быть более сложным проблемой, если используется ограничение по мощности, так как для определения осуществимости потребуется большее количество данных.

Мощность группы ресурсов зависит от того, какие и сколько ресурсов являются участниками группы ресурсов. Группа ресурсов сама по себе не имеет никакой мощности — только когда ресурсы являются участниками группы, она будет иметь мощность. Поскольку членство в группах ресурсов может меняться со временем, мощность должна оцениваться за день.

При планировании операций календарь группы ресурсов используется для определения начального и конечного времени каждой операции. Это означает, что календарь группы ресурсов ограничивает время, в течение которого операции могут быть запланированы, одной операцией в один день в одной группе ресурсов. В противоположность календарю для конкретных ресурсов, данные о эффективности календаря игнорируются для группы ресурсов, поскольку они просто обозначают открытые часы и не имеют фактической мощности.

Например, если рабочее время для группы ресурсов на одну конкретную дату равно от 8:00 до 16:00, одна операция не может поместить большую загрузку на группу ресурсов, чем может быть помещено в 8 часов, вне зависимости от того, сколько мощностей доступно в группе ресурсов в этот день в целом. Доступная мощность может, однако, дополнительно ограничивать загрузку.

Загрузка из планирования заданий по всем ресурсам, включенным в группу ресурсов на данный день, учитывается, когда рассчитывается доступная мощность для группы ресурсов в одном и том же дне. Для каждой даты расчет следующий:

Доступная мощность группы ресурсов = мощность для ресурсов в группе на основе их календаря – загрузка спланированных заданий на ресурсы в группе – Загрузка ресурсов в группе спланированная по операциям – загрузка спланированных операций в группе – загрузка спланированных операций в группе ресурсов

На вкладке Потребности в ресурсах в операции маршрута можно указать требования к ресурсам с помощью определенного ресурса (в этом случае операция будет запланирована с использованием этого ресурса), для группы ресурсов, для типа ресурсов или для одной или нескольких возможностей, навыков, курсов или сертификатов. Хотя использование всех этих параметров обеспечивает большую гибкость в проектировании маршрута, это также усложняет планирование для подсистемы, поскольку мощность должна учитываться по "свойствам" (абстрактное имя, используемое в подсистеме для возможностей, навыков и т. д.).

Мощность группы ресурсов для возможности является суммой мощностей для всех ресурсов в группе ресурсов, имеющих рассматриваемую возможность. Если ресурс в группе имеет возможность, он будет учитываться независимо от того, какой уровень мощности требуется.

При планировании операций доступная мощность для определенной возможности для группы ресурсов будет уменьшена при загрузке с операцией, требующей наличия требуемой возможности. Если для операции требуется более одной возможности, мощность будет уменьшена для всех необходимых возможностей.

Для каждой даты требуемый расчет следующий:

Доступная мощность для возможности = Мощность для возможности – спланированная загрузка заданий на ресурсы с конкретной мощностью, включенная в группу ресурсов – Спланированная загрузка операций на ресурсы с конкретными возможностями, включенная в группу ресурсов – спланированная загрузка операций в самой группе ресурсов, для которых требуются конкретные возможности

Это означает, что если загружается конкретный ресурс, нагрузка учитывается в расчете доступной мощности для группы ресурсов по возможностям, так как загрузка конкретного ресурса сокращает его вклад в мощность группы ресурсов для возможности, независимо от того, относится ли загрузка конкретного ресурса к этой конкретной возможности. Если на уровне группы ресурсов имеется загрузка, она учитывается в расчете доступной мощности группы ресурсов по возможностям только в том случае, если загрузка производится из операции, требующей наличия конкретной возможности.

Вышеописанная логика сложная, поскольку она одинакова для каждого типа "свойства", так что для использования планирования операций с ограничением по мощности требуется загрузка значительного объема данных.

Улучшение производительности MRP

В следующем видео с технологической конференции представлено несколько советов по улучшению производительности сводного планирования при использовании MRP с устаревшим механизмом сводного планирования: Помогите! MRP работает медленно!.

Просмотр ввода и вывода подсистемы планирования

Чтобы получить подробные сведения о вводе и выводе процесса планирования, включите ведение журнала, перейдя на страницу Управление организацией > Настройка > Планирование > Панель трассировки планирования.

На этой странице сначала выберите Включить ведение журналов на панели операций. Затем выполните планирование для производственного заказа. После завершения вернитесь на страницу Панель трассировки планирования и выберите Отключить ведение журналов на панели операций. Обновите страницу и в сетке появится новая строка. Выберите новую строку и выберите Загрузить на панели операций. Вы получите сжатую ZIP-папку, содержащую следующие файлы:

• Log.txt- Это файл журнала, в котором описываются шаги, выполняемые движком. Он очень сложный и может быть немного ошеломляющим, но если используется как часть эксперимента с настройкой маршрута для устранения проблем с производительностью, первое, что нужно искать, — это разница времени между первой и последней строкой, поскольку в этом случае будет выдаваться точное время, затраченное планировщиком.
• XmlModel.xml - Содержит модель, построенную на X++ и на которой работает двигатель. Значение JobId, используемое в файле, соотносится со значением RecId из исходной таблицы, содержащей задания (ReqRouteJob или ProdRouteJob). Обычно в этом файле следует искать, что даты, указанные в полях ConstraintJobStartsAt и ConstraintJobEndsAt соответствуют ожидаемым, что свойство JobGoal установлено правильно, а также что задания связаны друг с другом через ограничения JobLink.
• XmlSlots.xml - Содержит все рабочие времена и резервированную мощность, запрошенные двигателем. Рабочее время и резервирования календаря будут запрашиваться подсистемой только для периодов времени, в которые она пытается поместить задания (и дополнительный буфер), так что если файл содержит время далеко в будущем, это может свидетельствовать о проблеме с настройкой. Узлы ResourceProperty будут показывать для каждого ресурса, с какими группами ресурсов и какими возможностями он связан для каких периодов.
• Result.xml - Содержит результат выполнения планирования.

Обратите внимание на то, что функциональные возможности трассировки могут добавлять значительные накладные расходы производительности, поэтому их следует использовать только для исследования планирования определенных заказов управляемым образом. Если она включена во время выполнения сводного планирования, оно быстро достигает предельного размера и прекращает выполнение.

Устранение неполадок производительности

Как можно понять из всех предыдущих разделов, есть несколько ловушек, связанных с настройкой и использованием подсистемы планирования, что может повлечь за собой проблемы с производительностью. Для устранения подобных проблем можно использовать следующий контрольный список. Важно взглянуть на все точки, поскольку чаще всего сочетание нескольких факторов ведет к проблемам.

Выполнение планирования в рамках MRP, когда это не требуется

Несмотря на то, что маршруты используются для целей управления производством, таких как калькуляция затрат и отчетность, это может оказаться ненужным для учета в ходе MRP. В некоторых случаях для планирования достаточно стандартного времени производственного цикла, указанного для номенклатуры. Чтобы отключить планирование маршрутов, установите для временных границ мощности нулевые значения. Если планирование должно быть выполнено, то временные границы мощности должны быть тщательно настроены, поскольку в этом случае может отсутствовать необходимость учета маршрутов для всей области временных границ покрытия MRP.

Обратите внимание, что если заказ не запланирован в ходе MRP, тогда его потребуется запланировать при утверждении спланированного заказа. Это означает, что процесс утверждения займет больше времени, поэтому, в зависимости от того, сколько предложенных спланированных заказов было утверждено, увеличение производительности в ходе MRP может быть потеряно при утверждении.

Маршрут с ненужными операциями

При разработке маршрута заманчиво пытаться точно моделировать реальный мир со всеми этапами производства. Хотя это может быть полезно в некоторых случаях, это плохо для производительности, так как модель, с которой необходимо работать подсистеме, становится больше (в отношении заданий и ограничений), и для вставки и обновления заданий и резервирования мощностей будут выполняться больше инструкций SQL. Кроме того, имеется дальнейший эффект необходимости последующей отчетности о ходе выполнения заданий, что может быть уменьшено с помощью автоматической разноски. Если данные не используются ни для каких целей, они создают ненужную нагрузку.

Рекомендуется создавать только те операции, которые строго необходимы для планирования (как правило, являются ресурсами, представляющими узкие места) и/или для калькуляции затрат. В качестве альтернативы необходимо сгруппировать многие более мелкие операции в одну большую операцию, представляющую большую часть процесса.

Много применимых ресурсов для операции

Количество применимых ресурсов для операции определяется требованиями к ресурсам, установленными в связи с операцией. Требование может быть либо для конкретного (отдельного) ресурса, либо быть основано на принадлежности ресурса к группе ресурсов или возможности.

Если планирование не выполняется с ограничением по мощности и все соответствующие ресурсы имеют одинаковый календарь и эффективность, то подсистема планирования всегда будет выбирать один и тот же ресурс для операции, но только после того, как все соответствующие ресурсы будут проверены на предмет того, что он "лучше", чем другие. В этом случае нагрузка планирования может быть значительно уменьшена путем простого постоянного назначения определенного ресурса операции во время разработки маршрута.

Маршрут с параллельными операциями

Хотя параллельные операции (первичные/вторичные) являются мощным средством моделирования сценариев, например, когда машина и оператор оба необходимы для выполнения конкретной задачи, это также источник многих вопросов, связанных с производительностью. Если требование для определенного индивидуального ресурса назначается и основной, и вторичной операциям, обычно это не проблема. Но если имеется много возможных ресурсов для каждой из операций, то при планировании добавляется значительная сложность вычислений.

Альтернативой использованию параллельных операций является моделирование этих пар как "виртуальных" ресурсов (которые затем представляют группу, которая всегда объединяются для влкючения в действие) или просто отказ от моделирования одной из операций, если она не представляет узкого места.

Маршрут с количеством ресурсов более 1

Если количество ресурсов, необходимых для выполнения операции, более единицы, то эффективно будет работать точно так же, как и при использовании первичных/вторичных операций, так как в подсистему отправляются несколько параллельных заданий. Однако в этом случае невозможно использовать конкретное назначение ресурсов, поскольку количество, большее единицы, требует, чтобы для операции было применимо более одного ресурса.

Вторичная операция с количеством загрузки ресурсов больше единицы означает, что указанное количество вторичных ресурсов требуется для каждого ресурса первичной операции. Например, если первичная операция имеет количество ресурсов, равное 2, а для вторичной операции задано количество ресурсов, равное 3, то для вторичной операции потребуется шесть ресурсов.

Излишнее использование ограничения по мощности

Использование ограничения по мощности требует от подсистемы загрузки информации о емкости из базы данных и может иметь вычислительные накладные расходы, поскольку это затрудняет поиск решения, особенно в средах, в которых ресурсы резервируются ближе к максимальной мощности. В результате важно аккуратно оценить, действительно ли ресурсы должны использовать ограничение по мощности или они могут иметь избыточное резервирование. Поскольку может быть различие между ресурсами с ограничением по мощности в отношении важности исключения из избыточного резервирования, рекомендуется использовать параметр "узкое место" на ресурсе в сочетании с отдельным значением в плане в параметре "Временная граница мощности по минимальным доступным ресурсам". Использование концепции узкого места может обеспечить возможность уменьшения общей временной границы ограничения по мощности.

Задание жестких связей

Стандартный тип связи маршрута — мягкая, что означает, что между временем завершения одной операции и временем начала следующей операции допускается промежуток. Разрешение этого может привести к нежелательному эффекту, при котором если материал или мощность недоступны для одной из операций в течение очень длительного времени, производство может достаточно должно простаивать ,что является причиной возможного увеличения незавершенного производства. Это не произойдет с жесткими связями, поскольку окончание и начало должны быть идеально совмещены. Однако настройка жесткой связи повышает сложность задачи планирования, так как пересечения рабочего времени и мощности должны рассчитываться для двух ресурсов операций. Если используются также параллельные операции, это добавляет значительное время вычислений. Если ресурсы двух операций имеют разные календари, которые не перекрываются вообще, проблема не имеет решения.

Жесткие связи рекомендуется использовать только в том случае, если это строго необходимо, и следует тщательно продумать, требуется ли каждая операция маршрута.

Для уменьшения незавершенного производства без применения жестких связей можно запланировать заказ дважды, использовав противоположное направление для второго прохода. Если первое расписание было выполнено в обратном направлении от даты поставки, то второе должно быть выполнено вперед от запланированной даты начала. Это приведет к тому, что задания будут сжиматься максимально возможно, чтобы минимизировать незавершенное производство.

Отдельный календарь для каждого ресурса

Одним из основных источников данных для подсистемы планирования являются сведения из календаря, которые могут быть дорогостоящими для загрузки из базы данных. Так как календари создаются на основе шаблонов, есть соблазн создать календарь для каждого ресурса, а затем скорректировать сведения в этом календаре, когда ресурс имеет простой и другие проблемы. Однако это очень существенно ограничивает возможности подсистем для кэширования данных календаря, поскольку им потребуется запросить новые данные для каждого ресурса и это может быть большой источник проблем производительности. Вместо этого рекомендуется в максимальной степени повторно использовать календари между ресурсами, а затем управлять изменениями времени простоя, назначая другой код календаря для этого периода.

Большое число интервалов рабочего времени на календарный день

Так как подсистема функционирует путем проверки временных интервалов по одному для мощности, полезно минимизировать количество временных интервалов за каждый календарный день. Это можно сделать, например, с помощью рассмотрения того, важно ли для результирующего графика то, что работники имеют перерыв на 5 минут каждый час.

Большие (или отсутствующие) тайм-ауты планирования

Производительность подсистемы планирования может быть оптимизирована с помощью параметров, находящихся на странице Параметры планирования. Параметры Время ожидания планирования включено и Время ожидания оптимизации планирования включено должны всегда иметь значение Да. Если установлено значение Нет, планирование может потенциально работать бесконечно, если был создан недопустимый маршрут со множеством параметров.

Значение параметра Максимальное время планирования на одну последовательность определяет, сколько секунд можно, как минимум, потратить на попытку поиска решения для одной последовательности (в большинстве случаев последовательность соответствует отдельному заказу). Значение, которое следует использоваться здесь, сильно зависит от сложности маршрута и настроек, таких как ограничение по мощности, но максимум около 30 секунд является хорошей отправной точкой.

Значение параметра Время ожидания попыток оптимизации определяет, сколько максимально секунд можно использовать для поиска лучшего решения, чем то, которое было найдено. Это влияет только на маршруты, использующие параллельные операции, так как для них необходимо тестирование различных комбинаций.

Примечание

Значения, установленные для параметров времени ожидания, применяются как для планирования выпущенных производственных заказов, так и для спланированных заказов как часть MRP. В результате задание очень больших значений может значительно увеличить время выполнения MRP при запуске для плана с множеством спланированных производственных заказов.