Melhorar o desempenho do motor de agendamento

O motor de agendamento de recursos é utilizado para agendar rotas para as ordens de produção planeadas e lançadas. O motor foi originalmente lançado como parte do Dynamics AX 2012 e tem passado por várias melhorias desde o seu lançamento.

O problema de agendamento de tarefas da fábrica é um problema combinatório extremamente complexo onde o tempo de solução cresce exponencialmente com o número de variáveis de decisão. Muitas vezes, os clientes configuram rotas de produção e dados relacionados de uma forma que resulta num problema de agendamento que não pode ser resolvido em tempo razoável mesmo no hardware mais moderno. Este artigo irá ajudá-lo a entender o motor de agendamento e como uma configuração específica pode ter influência no desempenho.

No que diz respeito à melhoria do desempenho do agendamento, as diretrizes gerais recomendam a redução da complexidade do problema que o motor precisa de resolver. Alguns dos principais fatores que podem afetar o desempenho incluem:

• Rotas com muitas operações
• Rotas com operações paralelas
• Operações com quantidade de recursos superiores a uma
• Operações com muitos recursos aplicáveis
• Utilização de ligações fixas
• Utilização da capacidade finita
• O número de calendários diferentes utilizados
• O número de intervalos de tempo de trabalho por dia no calendário
• Duração total da rota
• Execução de vários motores de agendamento em paralelo

Descrição geral do fluxo de agendamento básico

Para entender como uma determinada configuração pode afetar o desempenho, é importante entender como o processo flui, tanto dentro do motor como no código X++ que o rodeia.

O processo básico de agendamento de uma encomenda consiste em três passos principais:

• Carregamento de dados – Aqui, os modelos de dados X++ são transformados no modelo de dados internos do motor sob a forma de tarefas e restrições.
• Agendamento – Esta é a principal origem de agendamento que processa o modelo e as restrições especificadas e gera um resultado. Durante este processo, o motor solicitará informações sobre o tempo de trabalho e as reservas de capacidade existentes a partir de X++, conforme necessário.
• Guardar dados – O resultado do motor na forma de intervalos de reserva de capacidade de tarefas é processado pelo código X++ para guardar as reservas de capacidade e atualizar as hora de início e fim das tarefas/operação/encomenda.

Carregar dados no motor

O motor de agendamento tem um modelo de dados mais abstrato do que a base de dados do Supply Chain Management porque foi criado como um motor genérico que pode lidar com diferentes origens de dados. Os conceitos de rota, operações secundárias e tempo de execução precisam de ser "traduzidos" para o modelo genérico de tarefa e restrição que o motor expõe. A lógica de criação do modelo tem uma lógica de negócio significativa e é diferente dependendo dos dados de origem. A classe X++ responsável é WrkCtrScheduler e tem classes derivadas para ordens de produção planeadas, ordens de produção lançadas e previsões de projetos.

Como exemplo, considere uma rota mostrada na tabela e imagem seguintes que parece ser relativamente simples.

N.º Oper.	Prioridade	Tempo de configuração	Tempo de execução	Tempo de fila posterior	Quantidade de recursos	Seguinte
10	Principal	1.00	2.00		1	20
10	Secundário 1				1	20
20	Principal		3.00	1	3	0

Quando envia isto para o motor, é dividido em oito tarefas, como mostra a seguinte ilustração (selecione a imagem para ampliá-la).

A ligação padrão entre duas tarefas é FinishStart, o que significa que a hora de fim de uma tarefa deve ser anterior à hora de início de outra tarefa. Como a configuração deve ser realizada pelo mesmo recurso que irá posteriormente fazer o processo, existem restrições OnSameResource entre si. Entre as tarefas da operação primária e secundário para 10, existem ligações StartStart e FinishFinish, o que significa que as tarefas devem começar e terminar ao mesmo tempo, e existem restrições NotOnSameResource que impedirão o mesmo recurso para primário e secundário.

Para a operação 20, em que a quantidade de recursos foi definida como 3, a tarefa do processo foi dividida em três tarefas distintas, onde todas as tarefas têm de ser executadas ao mesmo tempo. Neste caso, o grupo de rotas foi configurado para não reservar capacidade para filas após as horas, razão pela qual só há uma única tarefa para a fila depois.

O motor de agendamento só compreende os conceitos de tarefas e não sabe o que são operações. Isto significa que, ao fazer o agendamento de operações, as operações também são divididas em tarefas, embora estas não persistam na base de dados.

Para cada tarefa, também definiremos qual é o requisito de capacidade da tarefa (o número de segundos necessários). Dependendo da forma como os requisitos de recursos foram definidos, podemos também, para cada tarefa, enviar uma lista de todos os potenciais recursos aplicáveis que o tarefa poderia executar e qual é o requisito de capacidade para esse recurso específico. Mesmo que a lista de recursos aplicáveis seja enviada ao criar o modelo, o motor ainda terá de garantir que a atribuição de recursos é efetivamente válida para toda a duração da tarefa.

Elementos internos do motor de agendamento

Interface do motor de agendamento

Para ter uma ideia de como o motor funciona internamente, o melhor é olhar para a funcionalidade que expõe externamente. Em X++, a interface principal é WrkCtrSchedulerEngineInterface. Tem os métodos descritos nas seguintes subsecções.

Motor geral

Método	Finalidade
run	Agenda todas as tarefas carregadas e devolve o código de erro.
getJobSchedulingSequenceResult	Obtém o resultado do agendamento e a primeira tarefa de erro para a sequência identificada por uma tarefa específica.
validateJobCapacityReservations	Valida as reservas de capacidade para todas as tarefas armazenadas pelo motor.
setReservationsTimeStamp	Envia um carimbo de data/hora para o motor definido em todas as novas reservas de capacidade para as tarefas agendadas na cache do motor.
addPropertyToGroupAggregation	Adiciona um prefixo de propriedade ao conjunto de propriedades utilizadas quando a capacidade é agregada.
addResource	Adiciona um recurso ao conjunto de recursos do motor de agendamento.
addResourceGroup	Adiciona um grupo de recursos ao conjunto de grupos de recursos do motor de agendamento.
addResourceGroupMembership	Adiciona um recurso como membro a um grupo de recursos.
addOptimizationGoal	Adiciona um objetivo de otimização de agendamento (duração ou prioridade).

Tarefas individuais

Método	Finalidade
addJobInfo	Adiciona um registo de informações da tarefa que informa o motor sobre uma tarefas que deve ser agendada.
addConstraintJobEndsAt	Adiciona uma restrição de que uma tarefa deve terminar numa data e hora especificadas.
addConstraintJobStartsAt	Adiciona uma restrição de que uma tarefa deve começar numa data e hora especificadas.
addConstraintMaxJobDays	Define a restrição que uma tarefas pode abranger ao longo de um número máximo especificado de dias.
addConstraintResourceRequirement	Adiciona a restrição de que a tarefa deve ser agendada num recurso específico.
addJobBindPriority	Adiciona uma prioridade de vinculação de tarefa para um par (tarefa, nível de restrição). Um valor de prioridade mais elevado significa que as variáveis da tarefa serão vinculadas antecipadamente. A tarefa será processada antes das tarefas com um valor de prioridade inferior na mesma sequência.
addJobCapacity	Adiciona informação de carga de capacidade para uma tarefa (como runtime da tarefa necessário) qualquer que seja o recurso em que a tarefa é executada.
addJobResourceCapacity	Adiciona um recurso ao conjunto de recursos que podem ser utilizados para executar uma tarefa e indica a capacidade necessária para execução nesse recurso.
addJobGoal	Adiciona informações sobre o objetivo da tarefa para um nível de restrição específico (hora de fim mais precoce ou hora de início mais tardia).
addJobResourcePriority	Adiciona a prioridade a utilizar quando uma tarefa é agendada num recurso.
addJobResourceRuntime	Especifica uma hora da tarefa que depende do recurso em que a tarefa será agendada.
addJobRuntime	Especifica uma hora da tarefa que independente do recurso em que a tarefa será agendada.
scheduleJobOnResourceGroup	Marca uma tarefa para agendamento ao nível do grupo de recursos.
setJobResourcePreemptionAllowed	Define se a preempção é permitida para uma tarefa num recurso (se o motor for autorizado a agendar a tarefa em intervalos de capacidade não contíguos).
setRequiredNumberOfResources	Define o número de recursos necessários para agendar uma tarefa (apenas para agendamento de operações).

Restrições entre funções

Método	Finalidade
addJobLink	Adiciona um ligação (como finish>start) entre duas tarefas.
addConstraintEndsDelayed	Define o restrição de que uma tarefa não pode terminar antes do fim de outras tarefas mais algum tempo de atraso.
addConstraintJobListWorkingTimeIntersect	Adiciona uma restrição de que os intervalos de capacidade reservados para as tarefas devem pertencer às horas de trabalho de interseção para os dois recursos utilizados pelas tarefas.
addConstraintJobOverlap	Adicione uma restrição que define como as tarefas são sequenciadas quando uma determinada quantidade de um item pode ser movida entre dois recursos enquanto o processamento do primeiro recurso ainda não terminou e de modo a que o processamento do segundo recurso possa ser iniciado.
addConstraintNotOnSameResource	Adiciona uma restrição para que não sejam agendadas duas tarefas no mesmo recurso.
addConstraintOnSameResource	Adiciona uma restrição para que duas tarefas usem o mesmo recurso.
addJobSameReservations	Adiciona uma restrição de que uma tarefa deve acabar por ter reservas de capacidade para os mesmos intervalos de tempo da tarefa principal.
setPrimaryParallelJob	Adiciona informações sobre que tarefa é a tarefa principal num conjunto de tarefas paralelas.

Solucionador

O motor em si é essencialmente um solucionador de restrições especializado com heurística personalizada adicionada. O solucionador baseia-se em dois elementos principais: variáveis e restrições.

Variável

Uma variável representa um domínio de valores possíveis. O motor de agendamento tem dois tipos de variáveis:

• Variável DateTime - Tem um domínio de todas as datas e horas e o domínio pode ser restringido movendo o limite inferior e superior para a hora da variável mais próxima uma da outra.
• Variável Resource - Tem um domínio de recursos aplicáveis e o domínio pode ser restringido eliminando recursos da lista.

Restrição

Uma restrição atua em variáveis restringindo os seus domínios, mas também depende de variáveis para que seja ativada quando as variáveis mudam. O processo de "propagação de restrições" é quando uma restrição executa a sua função principal e reporta de volta à lógica principal se for bem-sucedida.

Uma variável é considerada vinculada quando não pode ser restringida ainda mais, o que para a variável DateTime significa que o limite superior e inferior é o mesmo, e para a variável Resource que tem apenas um único recurso aplicável. Quando todas as variáveis estão vinculadas, encontra-se uma solução.

Níveis de restrição

Quando o agendamento for executado como parte da fase de cobertura do planeamento de requisitos de material (MRP), as encomendas serão agendadas retroativamente a partir da data do requisito. No entanto, se não for possível encontrar um agendamento que comece hoje ou mais tarde e termine antes da data do requisito, então a direção de agendamento mudará para a frente a partir de hoje.

Esta regra principal de negócio é tratada através da organização dos níveis de restrição. Se não for encontrada solução ao utilizar as restrições no nível superior, então as restrições nesse nível são ignoradas e experimenta-se o nível inferior. Na prática, isto significa que, para agendamento retroativo, o modelo conterá um nível 1 com objetivos de tarefa com a hora de início mais tardia dada uma restrição de tempo de fim (a data de requisito) máximo e um nível 0 com objetivos de tarefa de hora de fim mais precoce e dada uma restrição de hora de início mínima para hoje.

Algoritmo

Os principais passos do algoritmo do motor são:

1. Encontre sequências (cadeias de tarefas) que podem ser resolvidas separadamente.
2. Tente encontrar uma solução inicial para a sequência para o nível de restrição mais elevado.
   1. Ordenar as tarefas na sequência com base em objetivos e prioridades de tarefa para poder encontrar uma tarefa de início.
   2. Organize as tarefas na seguinte sequência:
      1. Encontre todas as restrições que precisam de ser propagadas e execute a propagação.
      2. Se todas as variáveis da tarefa foram vinculadas, então foi encontrada uma solução para essa tarefa.
      3. Se uma das variáveis não puder ser vinculada sem violar as restrições, então reverta a vinculação da variável, tente um valor diferente no domínio (para a variável Resource) e volte a repetir a propagação da restrição.
3. Se não for encontrada nenhuma solução, então todas as restrições no nível de restrição atual são removidas, o nível de restrição diminuiu (se houver níveis mais baixos) e a procura de solução é repetida com o novo conjunto de restrições.
4. Se for encontrada uma solução viável, então a fase de otimização é iniciada, que tentará encontrar uma solução melhor até que o tempo limite de otimização seja atingido ou todas as combinações de recursos tenham sido esgotadas.

O solucionador de restrições não está ciente das especificidades do algoritmo de agendamento. É na definição e na combinação dos várias restrições que a "magia" acontece.

Determinar os tempos de trabalho

Uma grande parte das restrições (internas) do motor controla o tempo de trabalho e a capacidade de um recurso. Essencialmente, a tarefa consiste em percorrer os intervalos de tempo de trabalho para um recurso a partir de um determinado ponto numa determinada direção e encontrar um intervalo suficientemente longo no qual a capacidade (tempo) de que as tarefas precisam se enquadre.

Para tal, o motor precisa de conhecer os tempos de trabalho de um recurso. Ao contrário dos dados do modelo principal, os tempos de trabalho são carregamento em diferido, o que significa que são carregados no motor conforme necessário. A razão para esta abordagem é que muitas vezes há tempos de trabalho no Supply Chain Management para um calendário por um período muito longo e normalmente existem muitos calendários, pelo que os dados seriam bastante grandes para pré-carregar.

As informações do calendário são solicitadas pelo motor em blocos, invocando o método de classe X++ WrkCtrSchedulingInteropDataProvider.getWorkingTimes. O pedido é para um ID de calendário específico num intervalo de tempo específico. Dependendo do estado da cache do servidor no Supply Chain Management, cada um destes pedidos pode acabar em várias chamadas de base de dados, o que demora muito tempo (em relação ao tempo de cálculo puro). Além disso, se o calendário contém definições de tempo de trabalho muito elaboradas com muitos intervalos de tempo de trabalho por dia, isso aumenta o tempo que o carregamento demora.

Quando os dados do tempo de trabalho são carregados no motor de agendamento, isto é mantido na sua cache interna para o calendário específico, o que significa que se quaisquer outros trabalhos ou recursos estiverem a usar o mesmo calendário, então as próximas pesquisas podem ser realizadas rapidamente a partir da memória. Uma causa comum de mau desempenho é se um ID de calendário separado é utilizado para cada recurso, porque os dados terão então de ser solicitados para cada calendário, mesmo que o conteúdo dos calendários possa ser o mesmo.

Capacidade finita

Ao utilizar a capacidade finita, os intervalos de tempo de trabalho do calendário são divididas e reduzidas com base nas reservas de capacidade existentes. Estas reservas também são recolhidas através da mesma classe WrkCtrSchedulingInteropDataProvider que os calendários, mas em vez disso utilizam o método getCapacityReservations. Ao agendar durante o planeamento principal, as reservas para o plano principal específico são consideradas e, se ativadas na página de Parâmetros do planeamento principal, as reservas de ordens de produção confirmadas também são incluídas. Do mesmo modo, ao agendar uma ordem de produção, é também uma opção incluir reservas de encomendas planeadas existentes, embora tal não seja tão comum.

A utilização da capacidade finita fará com que o agendamento demore mais tempo devido a várias razões:

• Recolher a informação de capacidade da base de dados é uma operação lenta e, normalmente, a colocação em cache no lado do servidor da informação de capacidade não é tão eficiente quanto os tempos de trabalho porque não há partilha entre recursos como acontece geralmente com os calendários.
• O número de intervalos de tempo de trabalho a percorrer aumenta devido às divisões e os intervalos por um período mais longo devem normalmente ser investigados antes de se encontrar uma solução.
• Após a conclusão do agendamento, deve ser efetuado um controlo das reservas em conflito (consulte a secção "Executar motores de agendamento em paralelo" para obter mais detalhes).

Examinar as combinações de recursos

Se a sequência de trabalho apenas contiver os ligações FinishStart padrão, o que significa que forma uma cadeia simples sem ramos, um resultado ideal (para uma encomenda única e não entre encomendas) pode ser alcançado encontrando a melhor solução para a primeira tarefa e, em seguida, avançando para a procura da melhor solução para a tarefa seguinte. A melhor solução para uma tarefa significa encontrar o recurso que pode obter a data de início e fim da tarefa mais próxima do objetivo da tarefa (no agendamento para a frente isto significa obter a data de fim da tarefa o mais cedo possível) e ainda respeitar as restrições.

Quando há tarefas paralelas, encontrar uma solução pode implicar a análise de diferentes combinações de recursos. O número de possíveis combinações de recursos é o produto do número de recursos aplicáveis para as tarefas paralelas ligadas. Especialmente, quando se agenda uma encomenda retroativamente a partir de uma data de requisito, pode levar algum tempo para que a lógica perceba que não há solução para o problema que tornará as tarefas paralelas adequadas a data de ontem, pois terá de verificar todas as combinações porque poderia haver alguns recursos que tivessem uma maior eficiência ou um calendário diferente que pudesse dar um resultado. Isto significa que, se não for definido um tempo limite, irá ser executado durante muito tempo antes de mudar para a direção para a frente.

Esta lógica de combinação também significa que adicionar recursos mais aplicáveis pode tornar o motor mais lento. Se ocorrerem problemas de desempenho quando existem operações paralelas e o agendamento com capacidade infinita, os mesmos podem ser parcialmente corrigidos ao fazer com que o designer de rotas tome uma decisão sobre que recurso deve ser utilizado e, em seguida, atribuir o recurso diretamente na operação (porque o motor, na maioria dos casos, acabará sempre por escolher o mesmo recurso e o resultado final será o mesmo).

Ligações fixas

Definir o tipo de ligação entre duas tarefas é difícil, garante que não há um intervalo de tempo entre o fim de uma tarefa e o início da próxima. Isto pode ser muito útil em cenários como quando o metal é aquecido numa tarefa e depois processado na tarefa, onde não é desejável ter metal arrefecido entre tarefas.

Com ligações flexíveis padrão e o agendamento para a frente, se a rota formar uma cadeia simples sem quaisquer ramos, um resultado pode ser alcançado encontrando uma solução para a primeira tarefa que satisfaça as suas próprias restrições e, em seguida, avançando na cadeia para propagar a hora de fim da tarefa anterior para a tarefa seguinte. Se a tarefa atual não encontrar capacidade, a respetiva hora de início será adiada, sem qualquer consequência para as tarefas anteriores, como a criação de lacunas entre tarefas. No entanto, com as ligações fixas (especialmente relacionadas com a capacidade finita) para o mesmo cenário, o facto de uma tarefa posterior na cadeia não conseguir encontrar capacidade, significará que todas as tarefas agendadas anteriores terão de ser "arrastadas" uma a uma e, assim, reagendadas várias vezes. Especialmente em cenários com elevada carga para múltiplos recursos, as ligações fixas podem causar uma reação em cadeia onde as tarefas se afetarão mutuamente e uma série de iterações terá de ser realizada antes de o resultado estabilizar num agendamento exequível.

Executar motores de agendamento em paralelo

Ao realizar o agendamento como parte de uma execução de planeamento principal em que são utilizados programas auxiliares, cada um dos threads do programa auxiliar do planeamento principal também pode selecionar tarefas de agendamento de ordens de produção. Isto significa que vários motores de agendamento podem estar a funcionar ao mesmo tempo. Embora o multithreading em geral seja um benefício de desempenho muito significativo, também existem algumas desvantagens funcionais no que diz respeito ao agendamento.

Em MRP, todas as ordens de produção para um determinado nível de lista de materiais (BOM) são agendadas pela sequência de datas de requisito, o que significa que essas encomendas com a data de requisito mais antiga devem ser agendadas primeiro e, assim, têm uma maior probabilidade de obter a capacidade de recursos disponível. No entanto, com vários motores a escolher a partir da lista de encomendas não programadas, a sequência já não está assegurada, uma vez que uma pode ser concluída mais rapidamente do que a outra.

Além disso, ao agendar usando a capacidade finita e quando várias instâncias do motor estão a tentar agendar encomendas que estão potencialmente usando os mesmos recursos no mesmo intervalo de tempo, pode ocorrer uma condição race. O número de tais condições race é registado no campo Conflitos de agendamento na página de histórico dos planos principais. A lógica da resolução de conflitos é a seguinte:

• Agende uma encomenda (sem bloqueio) e obtenha reservas de capacidade.
• Defina o bloqueio.
• Verifique se existem reservas de capacidade mais recentes para os recursos programados no período de tempo.
  • Se não, escreva a capacidade e liberte o bloqueado.
  • Se sim, liberte a bloqueio e reprograme a encomenda desde o início.

Assim, ao agendar com múltiplas instâncias do motor, o resultado não é totalmente determinístico porque vai depender do tempo exato de cada um dos threads.

Desempenho do agendamento de operações

Embora o agendamento de operações também seja conhecido como planeamento de capacidade de rascunho, visto do ponto de vista do motor, pode ser um problema mais difícil de resolver se a capacidade finita for utilizada, uma vez que são necessários mais dados para determinar a viabilidade.

A capacidade de um grupo de recursos depende dos tipos e de quantos recursos são membros do grupo de recursos. Um grupo de recursos em si não tem qualquer capacidade - apenas quando os recursos são membros do grupo terá capacidade. Como a adesão ao grupo de recursos pode variar ao longo do tempo, a capacidade deve ser avaliada por dia.

No agendamento de operações, o calendário do grupo de recursos é utilizado para determinar as horas de início e de fim para cada operação. Isto significa que o calendário do grupo de recursos coloca um limite para o tempo em que podem ser agendadas operações para uma operação num só dia num grupo de recursos. Em comparação com o calendário para recursos específicos, os dados de eficiência do calendário são ignorados para o grupo de recursos, uma vez que simplesmente denota as horas de abertura e não a capacidade real.

Por exemplo, se o tempo de trabalho de um grupo de recursos numa data específica for das 8:00 às 16:00, uma operação não pode colocar mais carga no grupo de recursos do que o que pode ser ajustado em 8 horas, independentemente da capacidade que o grupo de recursos tem disponível no total nesse dia. No entanto, a capacidade disponível pode limitar ainda mais a carga.

A carga do agendamento de tarefas em todos os recursos incluídos no grupo de recursos num determinado dia é considerada quando é calculada a capacidade disponível para o grupo de recursos no mesmo dia. Para cada data, o cálculo é:

Capacidade disponível do grupo de recursos = Capacidade para os recursos do grupo com base no calendário - Carga agendada da tarefa nos recursos do grupo - Carga agendada das operações nos recursos do grupo - Carga agendada das operações no grupo de recursos

No separador Requisitos de recursos na operação da rota, os requisitos de recursos podem ser especificados usando um recurso específico (nesse caso, a operação será agendada usando esse recurso), para um grupo de recursos, para um tipo de recurso ou para uma ou mais capacidades, competência, curso ou certificado. Embora a utilização de todas estas opções dê uma grande flexibilidade na estruturação da rota, também complica o agendamento para o motor, uma vez que a capacidade deve ser contabilizada por "propriedade" (o nome abstrato utilizado no motor para capacidade, competências, etc.).

A capacidade do grupo de recursos para uma capacidade é a soma da capacidade de todos os recursos do grupo de recursos que tem a capacidade em questão. Se um recurso no grupo tiver uma capacidade, será considerado independentemente do nível de capacidade necessário.

No agendamento de operações, a capacidade disponível para uma determinada capacidade para um grupo de recursos será reduzida quando é carregada com uma operação que requer a capacidade em questão. Se a operação necessitar de mais de uma capacidade, a capacidade será reduzida para todas as capacidades necessárias.

Para cada data, o cálculo necessário é:

Capacidade disponível para uma capacidade = Capacidade para a capacidade - Carga agendada da tarefa nos recursos com a capacidade específica, incluída no grupo de recursos - Carga agendada de operações nos recursos com a capacidade específica, incluída no grupo de recursos - Carga agendada de operações no próprio grupo de recursos que requer a capacidade específica

Isto significa que, se houver carga num recurso específico, a carga é considerada no cálculo da capacidade disponível do grupo de recursos por capacidade, porque a carga num recurso específico reduz o seu contributo para a capacidade do grupo de recursos para uma capacidade, independentemente de a carga no recurso específico ser para essa capacidade específica. Se houver carga no nível do grupo de recursos, é considerada no cálculo da capacidade disponível do grupo de recursos por capacidade, apenas se a carga for de uma operação que exija a capacidade específica.

A lógica acima é complicada, pois é a mesma para cada tipo de "propriedade"; pelo que a utilização do agendamento de operações com capacidade finita requer o carregamento de uma quantidade significativa de dados.

Melhorar desempenho de MRP

O seguinte vídeo técnico fornece várias dicas sobre como melhorar o desempenho do planeamento principal quando estiver a utilizar MRP com o motor de planeamento principal preterido: Ajuda! O MRP está lento!

Ver a entrada e a saída do motor de agendamento

Para obter detalhes específicos da entrada e saída do processo de agendamento, faça a ativação do registo ao aceder a Administração da organização > Configuração > Agendamento > Cockpit de monitorização do agendamento.

Nesta página, selecione Ativar registo no Painel de Ações. Em seguida, execute o agendamento para a ordem de produção. Quando estiver concluído, volte à página Cockpit de monitorização do agendamento e selecione Desativar registo no Painel de Ações. Atualize a página e aparecerá uma nova linha na grelha. Selecione a nova linha e selecione Transferir no Painel de Ações. Obtém uma pasta .zip comprimida contendo os seguintes ficheiros:

• Log.txt - É o ficheiro de registo que descreve os passos que o motor executa. É muito elaborado e pode ser um pouco avassalador, mas quando utilizado como parte da experiência com a configuração da rota para resolver problemas de desempenho, a primeira coisa a procurar é a diferença de tempo entre a primeira e a última linha, pois indica o tempo exato gasto pelo agendador.
• XmlModel.xml - Contém o modelo que é criado em X++ e em que o motor funciona. O JobId utilizado no ficheiro correlaciona-se com RecId na tabela de origem que contém as tarefas (ReqRouteJob ou ProdRouteJob). A coisa típica a procurar neste ficheiro é se as datas dadas em ConstraintJobStartsAt e ConstraintJobEndsAt são as esperadas, se a propriedade o JobGoal está corretamente definida e se as tarefas estão relacionadas umas com as outras através das restrições JobLink.
• XmlSlots.xml - Contém todos os tempos de trabalho e reservas de capacidade que o motor solicitou. Os tempos de trabalho e as reservas do calendário só serão solicitados pelo motor durante os períodos em que tenta colocar as tarefas (e um tempo de reserva extra), pelo que, se o ficheiro contiver tempos muito distantes no futuro, poderá ser uma indicação de um problema com a configuração. Os nós ResourceProperty mostrarão para cada recurso que grupo de recursos e capacidades está associados a que períodos.
• Resultado.xml - Contém o resultado da execução do agendamento.

Note que a funcionalidade de monitorização pode adicionar uma sobrecarga de desempenho significativa, por isso use-a apenas para investigar o agendamento de encomendas específicas de forma controlada. Se for ativada durante uma execução de planeamento principal, rapidamente atingirá o seu limite de tamanho e irá parar.

Resolver problemas de desempenho

Como se pode entender a partir de todas as secções anteriores, existem algumas armadilhas no que diz respeito à configuração e utilização do motor de agendamento, o que pode levar a problemas de desempenho. A seguinte lista de verificação pode ser utilizada para resolver problemas. É importante olhar para todos os pontos, pois é, na maior parte das vezes, uma combinação de múltiplos fatores que conduz a problemas.

Realização do agendamento como parte do MRP, quando não é necessário

Embora as rotas sejam utilizadas para efeitos de controlo da produção, tais como custos e relatórios, talvez não seja necessário considerá-las durante o MRP. Em alguns casos, ter um prazo normal de produção especificado para o item será suficiente para o planeamento. Para desativar o agendamento da rota, defina o tempo limite de capacidade como zero. Se o agendamento for necessário, então o tempo limite de capacidade deve ser cuidadosamente definido, pois pode não ser necessário considerar as rotas para toda a extensão do tempo limite de cobertura do MRP.

Note que, se a encomenda não for agendada durante o MRP, terá de ser agendada quando a encomenda planeada for confirmada. Isto significa que o processo de confirmação demorará mais tempo, pelo que, dependendo de quantas das encomendas planeadas sugeridas são confirmadas, o ganho em desempenho durante o MRP pode perder-se na confirmação.

Rota com operações desnecessárias

Ao desenhar a rota, é tentador tentar modelar o mundo real exatamente com todos os passos da produção. Embora isso possa ser útil em alguns casos, não é bom para o desempenho, uma vez que o modelo que o motor precisa para trabalhar fica maior (tanto em termos de tarefas como de restrições) e mais instruções de SQL serão executadas para inserção e atualização das tarefas e reservas de capacidade. Além disso, existe o efeito a jusante de ter de, eventualmente, comunicar os progressos das tarefas, o que pode ser mitigado com lançamentos automáticos. Se os dados não forem utilizados para nada, criam carga desnecessária.

Recomendamos que crie apenas operações estritamente necessárias para o agendamento (que normalmente serão os recursos de estrangulamento) e/ou para fins de custo. Em alternativa, deve agrupar muitas operações distintas menores numa operação maior que represente uma maior parte do processo.

Muitos recursos aplicáveis para uma operação

O número de recursos aplicáveis para uma operação é determinado pelos requisitos de recursos definidos na relação da operação. O requisito pode ser para um recurso específico (individual) ou pode basear-se na adesão do recurso a um grupo de recursos ou capacidade.

Se o agendamento não for feito utilizando a capacidade finita e todos os recursos aplicáveis tiverem o mesmo calendário e eficiência, então o motor de agendamento acabará sempre por escolher o mesmo recurso para uma operação, mas só depois de tentar todos os recursos aplicáveis para verificar se há um que é "melhor" do que os outros. Neste caso, a carga do agendamento pode ser reduzida significativamente ao simplesmente atribuir sempre um recurso específico à operação no tempo de conceção da rota.

Rota com operações paralelas

Embora as operações paralelas (primárias/secundárias) sejam uma ferramenta poderosa para modelar cenários como quando uma máquina e um operador são ambos necessários para executar uma tarefa específica, é também a fonte de muitos problemas de desempenho. Se um requisito para um recurso individual específico é atribuído à operação primária e secundária, normalmente não é um problema. Mas ,se há muitos recursos possíveis para cada uma das operações, então adiciona uma complexidade computacional significativa ao agendamento.

Uma alternativa à utilização de operações paralelas é modelar os pares como recursos "virtuais" (que depois representarão a equipa que vai sempre junta para a operação) ou simplesmente não modelar uma das operações, se não representar um estrangulamento.

Rota com quantidade de recursos superiores a 1

Se a quantidade de recursos necessários para uma operação for maior que um, então o resultado é efetivamente o mesmo que a utilização de operações primárias/secundárias, uma vez que serão enviadas múltiplas tarefas paralelas para o motor. No entanto, para este caso, não é possível utilizar atribuições específicas de recursos, porque uma quantidade superior a um requer que mais de um recurso seja aplicável para a operação.

Uma operação secundária que tenha uma quantidade de carga de recursos superior a um significa que é necessária a quantidade especificada de recursos secundários para cada recurso da operação principal. Por exemplo, se uma operação principal tiver a sua quantidade de recursos definida como dois e a sua operação secundária tiver a sua quantidade de recursos definida como três, então é necessário um total de seis recursos para a operação secundária.

Utilização excessiva da capacidade finita

A utilização da capacidade finita requer que o motor carregue a informação de capacidade a partir de uma base de dados e possa ter uma sobrecarga computacional porque será mais difícil encontrar uma solução, especialmente em ambientes onde os recursos são reservados perto da sua capacidade máxima. Como resultado, é importante avaliar cuidadosamente se um recurso realmente precisa de usar a capacidade finita ou pode ser reservado em excesso. Como pode haver uma diferença entre os recursos de capacidade finito relativamente à importância de não serem reservado em excesso, recomendamos a utilização da opção de estrangulamento num recurso em combinação com um valor separado no plano em "Tempo limite de capacidade para recursos de estrangulamento". A utilização do conceito de estrangulamento pode permitir a redução do tempo limite de capacidade finita geral.

Definir ligações fixas

O tipo de ligação padrão da rota é flexível, o que significa que é permitida uma lacuna de tempo entre o tempo de conclusão de uma operação e o início da seguinte. Se os materiais ou a capacidade não estiverem disponíveis para uma das operações durante muito tempo, permitir isto pode ter o infeliz efeito de a produção poder ficar inativa durante algum tempo, o que significa um possível aumento do trabalho em curso. Isto não vai acontecer com ligações fixas porque o fim e o início devem alinhar-se perfeitamente. Mas a definição de ligações fixas dificulta o problema do agendamento, uma vez que as interseções entre o tempo de trabalho e a capacidade devem ser calculadas para os dois recursos das operações. Se também houver operações paralelas envolvidas, isto adiciona um tempo computacional significativo. Se os recursos das duas operações têm calendários diferentes que não se sobrepõem, o problema é insolúvel.

Recomendamos a utilização de ligações fixas apenas quando estritamente necessário e pondere cuidadosamente se é necessário para cada operação da rota.

Para reduzir o trabalho em curso sem aplicar ligações fixas, um truque é agendar a encomenda duas vezes com a mudança para a direção oposta para a segunda passagem. Se o primeiro agendamento foi feito para trás a partir da data de entrega, então o segundo deve ser feito para a frente a partir da data de início agendada. Isto resultará na compressão das tarefas tanto quanto possível, de modo a minimizar o trabalho em curso.

Separar o calendário para cada recurso

Uma das principais origens de dados para o motor de agendamento é a informação do calendário, que pode ser dispendiosa para carregar a partir da base de dados. Como os calendários são gerados com base em modelos, seria tentador gerar um calendário para cada recurso e, em seguida, ajustar a informação neste calendário quando o recurso tem tempo de inatividade e outros problemas. No entanto, ao fazê-lo, limitará severamente a capacidade dos motores colocarem em cache os dados do calendário, uma vez que necessitaria de solicitar novos dados para cada recurso e pode ser uma grande fonte de problemas de desempenho. Em vez disso, recomendamos que reutilize os calendários o máximo possível entre os recursos e, em seguida, controle as alterações de tempo de inatividade atribuindo um ID de calendário diferente a um período.

Número elevado de intervalos de tempo de trabalho por dia

Como o motor funciona examinando intervalos de tempo um a um para a capacidade, é benéfico minimizar o número de intervalos de tempo por dia de calendário. Isto poderia ser feito, por exemplo, considerando se é importante para o agendamento resultante refletir que os trabalhadores têm uma pausa de 5 minutos a cada hora.

Tempo limites de agendamento grandes (ou nenhum)

O desempenho do motor de agendamento pode ser otimizado usando parâmetros encontrados na página Parâmetros de agendamento. As definições Tempo limite de agendamento ativado e Tempo limite de otimização do agendamento devem ser sempre definidas como Sim. Se definidas como Não, o agendamento pode potencialmente funcionar infinitamente se uma rota inviável com muitas opções tiver sido criada.

O valor para Tempo máximo de agendamento por sequência controla quantos segundos podem, no máximo, ser gastos a tentar encontrar uma solução para uma única sequência (na maioria dos casos uma sequência corresponde a uma única encomenda). O valor a utilizar aqui depende muito da complexidade da rota e definições como a capacidade finita, um máximo de cerca de 30 segundos é um bom ponto de partida.

O valor para Tempo limite de tentativas de otimização controla quantos segundos podem, no máximo, ser utilizados para encontrar uma solução melhor do que a encontrada originalmente. Isto só influenciará rotas que utilizam operações paralelas, uma vez que estas tornam necessário testar diferentes combinações.

Nota

Os valores definidos para os tempos limites serão aplicados tanto para o agendamento das ordens de produção lançadas como para as encomendas planeadas como parte do MRP. Como resultado, a definição de valores muito elevados poderia aumentar significativamente o tempo de execução do MRP ao executar para um plano com muitas ordens de produção planeadas.