Melhorar o desempenho do motor de agendamento

Observação

Os grupos de interesse comunitário mudaram agora do Yammer para o Microsoft Viva Engage. Para se juntar a uma comunidade Viva Engage e participar nas discussões mais recentes, preencha o formulário Solicitar acesso à Comunidade Viva Engage de Finanças e Operações e escolha a comunidade à qual pretende juntar-se.

O motor de agendamento de recursos agenda rotas para ordens de produção planeadas e lançadas.

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. Os clientes frequentemente configuram rotas de produção e dados relacionados de formas que criam problemas de agendamento que não são resolvíveis em tempo razoável, mesmo em hardware moderno. Este artigo explica o motor de agendamento e como uma configuração específica influencia o desempenho.

Melhorar a performance de agendamento reduzindo a complexidade do problema que o motor de processamento resolve. Alguns dos principais fatores que podem afetar o desempenho incluem:

Rotas com muitas operações
Rotas com operações paralelas
Operações com mais do que um recurso
Operações com muitos recursos aplicáveis
Utilização de ligações fixas
Utilização da capacidade finita
Número de calendários diferentes utilizados
Número de horários 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 perceberes como uma determinada configuração afeta o desempenho, precisas de saber como o processo flui dentro do motor e 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 – Os modelos de dados X++ transformam-se no modelo de dados interno do motor de execução como trabalhos e restrições.
Agendamento – O motor processa o modelo dado e as restrições para gerar um resultado. Solicita, conforme necessário, informações sobre tempo de trabalho e reservas de capacidade existentes ao X++.
Guardar dados – O código X++ processa o resultado do motor, sob a forma de espaços de reserva de capacidade de trabalho, para guardar reservas de capacidade e atualizar os horários de início e fim dos trabalhos, operações ou ordem.

Carregar dados no motor

O motor de agendamento utiliza um modelo de dados mais abstrato do que a base de dados Supply Chain Management porque é um motor genérico que lida com múltiplas fontes de dados. Os conceitos de rota, operações secundárias e tempo de execução são traduzidos no modelo genérico de trabalho e restrição que o motor expõe. A lógica para construir o modelo inclui uma lógica de negócio significativa e varia consoante os dados de origem. A classe X++ responsável é WrkCtrScheduler, que inclui classes derivadas para ordens de produção planeadas, ordens de produção lançadas e previsões de projeto.

Por exemplo, considere uma rota mostrada na tabela e imagem seguintes, que é relativamente simples.

Oper. Não.	Prioridade	Tempo de configuração	Tempo de execução	Tempo de fila posterior	Quantidade de recursos	Seguinte
10	Primário	1,00	2,00		1	20
10	Secundário 1				1	20
20	Primário		3.00	1,00	3	0

Exemplo de diagrama de roteamento.

Quando envia esta rota para a locomotiva, ela divide-se em oito tarefas, como mostrado na ilustração seguinte (selecione a imagem para a ampliar).

A ligação padrão entre dois trabalhos é FinishStart, o que significa que a hora final de um trabalho deve ocorrer antes do início de outro. A configuração tem de ser feita pelo mesmo recurso que mais tarde gere o processo, pelo que existem OnSameResource restrições entre eles. Entre os trabalhos para as operações primária e secundária para 10, existem ligações StartStart e FinishFinish, o que significa que os trabalhos devem iniciar e concluir ao mesmo tempo. Além disso, existem NotOnSameResource restrições que impedem que o mesmo recurso seja utilizado tanto para operações primárias como secundárias.

Para a operação 20, onde a quantidade de recursos é definida para 3, o trabalho de processo é dividido em três tarefas distintas onde todas as tarefas têm de ser executadas exatamente ao mesmo tempo. Neste caso, o grupo de rotas está configurado para não reservar capacidade para uma fila subsequente, razão pela qual só há uma única tarefa para a fila posterior.

O motor de agendamento compreende apenas os conceitos de trabalhos e não reconhece operações. Esta limitação significa que, durante o agendamento de operações, o sistema divide as operações em tarefas, embora estes trabalhos não sejam mantidos na base de dados.

Para cada trabalho, defines qual é o requisito de capacidade do trabalho (o número de segundos necessários). Dependendo de como os requisitos de recursos são definidos, pode também enviar, para cada tarefa, uma lista de todos os recursos potenciais aplicáveis em que o trabalho pode funcionar e qual é o requisito de capacidade para esse recurso específico. Embora envie a lista de recursos aplicáveis ao construir o modelo, o motor garante que a atribuição de recursos se mantém válida durante toda a duração do trabalho.

Elementos internos do motor de agendamento

Interface do motor de agendamento

Para perceberes como o motor funciona internamente, revê a funcionalidade que ele expõe externamente. Em X++, a interface principal é WrkCtrSchedulerEngineInterface. Tem os métodos descritos nas seguintes subsecções.

Motor geral

Método	Objetivo
`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	Objetivo
`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 alto significa que as variáveis do trabalho são vinculadas mais cedo. O trabalho é processado antes de trabalhos com 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 pode ser usado para executar uma tarefa e indica a capacidade necessária ao executar 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 um tempo de trabalho que depende do recurso onde o trabalho está agendado.
`addJobRuntime`	Especifica um tempo de trabalho independente do recurso em que o trabalho está agendado.
`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	Objetivo
`addJobLink`	Adiciona um ligação (como finish>start) entre duas tarefas.
`addConstraintEndsDelayed`	Define a restrição de que um trabalho não pode terminar antes de outro trabalho terminar, 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`	Adiciona uma restrição que define como os trabalhos são sequenciados quando uma dada quantidade de um item pode ser movida entre dois recursos enquanto o primeiro recurso ainda não está terminado de ser processado, para que o segundo recurso possa começar a processar.
`addConstraintNotOnSameResource`	Adiciona uma restrição de que dois trabalhos não devem ser agendados 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 é um solucionador especializado de restrições com heurísticas personalizadas. O solucionador baseia-se em dois elementos principais: variáveis e restrições.

Variable

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 com todas as datas e horas. Pode restringir o domínio ao aproximar os limites inferior e superior para o tempo da variável.
Variável de recurso - Tem um domínio de recursos aplicáveis. Podes restringir o domínio eliminando recursos da lista.

Restrição

Uma restrição atua sobre variáveis ao restringir os seus domínios. Também depende das variáveis, por isso é ativado 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 limitada quando não pode ser restringida mais. Para uma variável DateTime, esta condição significa que os limites superior e inferior são iguais. Para a variável Recurso, significa que tem apenas um recurso aplicável. Quando todas as variáveis estão vinculadas, encontra-se uma solução.

Níveis de restrição

Quando o agendamento faz parte da fase de planeamento de requisitos de materiais (MRP), o sistema agenda as encomendas de trás para a frente a partir da data da necessidade. No entanto, se o sistema não conseguir encontrar um cronograma que comece hoje ou mais tarde e termine antes da data do requisito, altera a direção do agendamento para avançar a partir de hoje.

O sistema organiza as restrições por níveis para lidar com esta regra principal de negócio. Se o sistema não encontrar uma solução ao usar as restrições no nível mais alto, elimina todas as restrições desse nível e tenta o nível inferior. Na prática, este processo significa que, para o agendamento retroativo, o modelo contém um nível 1 com objetivos de trabalho com a última hora de início possível, dada uma restrição de tempo de fim máximo (a data de requisito), e um nível 0 com objetivos de trabalho com a hora de término mais cedo possível, e uma restrição de início mínimo de hoje.

Algoritmo

Os principais passos do algoritmo do motor são:

Encontre sequências (cadeias de tarefas) que possam ser resolvidas separadamente.
Tente encontrar uma solução inicial para a sequência ao nível de restrição mais alto.
1. Ordena os trabalhos na sequência com base no objetivo e prioridades do trabalho, para que o sistema possa encontrar um emprego inicial.
2. Percorra os trabalhos 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 do trabalho estiverem ligadas, então encontra-se uma solução para esse trabalho.
  3. Se uma das variáveis não puder ser limitada sem violar as restrições, reverte a ligação à variável, tenta um valor diferente no domínio (para a variável de recurso) e volta a executar a propagação da restrição.
Se não for encontrada solução, remover todas as restrições ao nível atual da restrição, baixar o nível da restrição (se houver níveis inferiores disponíveis) e tentar novamente a pesquisa da solução com o novo conjunto de restrições.
Se for encontrada uma solução viável, inicia-se a fase de otimização, que tenta encontrar uma solução melhor até que o timeout da otimização seja atingido ou todas as combinações de recursos sejam esgotadas.

O solucionador de restrições não tem em conta as especificidades do algoritmo de agendamento. A "magia" acontece na definição e combinação das várias restrições.

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 de um recurso a partir de um dado ponto numa dada direção, e encontrar um intervalo suficientemente longo para que a capacidade (tempo) necessária da tarefa se encaixe.

Para tal, o motor precisa de conhecer os tempos de trabalho de um recurso. Ao contrário dos dados principais do modelo, os tempos de trabalho são carregados sob demanda, o que significa que são carregados na aplicação conforme necessário. A razão para esta abordagem é que, em Supply Chain Management, muitas vezes existem tempos de trabalho definidos para um calendário durante um período muito longo. Além disso, normalmente existem muitos calendários, pelo que os dados seriam bastante grandes para carregamento antecipado.

O motor solicita informação do calendário em blocos invocando o método WrkCtrSchedulingInteropDataProvider.getWorkingTimesde classe X++ . 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 contiver definições muito elaboradas de tempo de trabalho com muitos intervalos de tempo de trabalho por dia, esta complexidade acrescenta ao tempo que o carregamento demora.

Quando o motor de agendamento carrega os dados de tempo de trabalho, mantém esses dados na sua cache interna para o calendário específico. Esta retenção significa que, se outros trabalhos ou recursos utilizarem o mesmo calendário, as próximas consultas podem ser feitas rapidamente de memória. Uma causa comum de mau desempenho é se for usado um ID de calendário separado para cada recurso, porque os dados são então solicitados para cada calendário, mesmo que o conteúdo dos calendários possa ser o mesmo.

Capacidade finita

Quando se usa capacidade finita, o sistema divide e reduz os intervalos de tempo de trabalho do calendário com base nas reservas de capacidade existentes. A mesma WrkCtrSchedulingInteropDataProvider classe recolhe estas reservas juntamente com os calendários, mas usa o getCapacityReservations método. Ao agendar durante o planeamento mestre, o sistema considera as reservas para o plano diretor específico. Se ativar a definição na página Parâmetros de Planeamento Mestre, o sistema também inclui reservas de ordens de produção confirmadas. De forma semelhante, ao agendar uma ordem de produção, pode optar por incluir reservas de ordens planeadas existentes, embora esta sequência não seja tão comum quanto o inverso.

O agendamento demora mais quando se usa capacidade finita por várias razões:

Obter a informação de capacidade da base de dados é uma operação lenta. O cache do lado do servidor da informação de capacidade normalmente não é tão eficiente como nos horários de trabalho, pois não é partilhada entre recursos como ocorre tipicamente com os calendários.
O número de intervalos de tempo de trabalho a atravessar aumenta devido às divisão. O sistema normalmente precisa de investigar slots durante mais tempo antes de encontrar uma solução.
Após a conclusão do agendamento, o sistema deve verificar reservas conflitantes (ver a secção "Executar motores de agendamento em paralelo" para mais detalhes).

Examinar as combinações de recursos

Se a sequência de tarefas contiver apenas os elos padrão FinishStart , ou seja, formar uma cadeia simples sem ramos, o sistema pode alcançar um resultado ótimo (visto a partir da ordem única, não entre ordens) ao encontrar a melhor solução para a primeira tarefa e depois avançar para encontrar a melhor solução para a tarefa seguinte. A melhor solução para um emprego é encontrar o recurso que permita aproximar o início e a data de chegada do trabalho mais próximo do objetivo do trabalho (no agendamento antecipado, isto significa obter a data final do trabalho o mais cedo possível), respeitando ainda as limitações.

Quando existem empregos paralelos, encontrar uma solução pode envolver examinar 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 ao agendar uma encomenda retroativamente a partir de uma data de requisito, pode demorar bastante tempo até a lógica perceber que não há solução para o problema que faça os trabalhos paralelos encaixarem antes da data atual. A lógica precisa de verificar todas as combinações porque pode haver recursos com maior eficiência ou um calendário diferente que possa dar um resultado. Esta condição significa que, se não definir um limite de timeout, o processo corre durante muito tempo antes de mudar a direção para avançar.

Esta lógica combinatória também significa que adicionar mais recursos aplicáveis pode fazer com que o motor funcione mais lentamente. Se ocorrerem problemas de desempenho quando tem operações e agendamento paralelos com capacidade infinita, pode-se resolver parcialmente o problema fazendo com que o designer de rotas tome uma decisão sobre qual recurso deve ser usado e depois atribua o recurso diretamente à operação (porque o motor, na maioria dos casos, acaba sempre por escolher o mesmo recurso, Portanto, o resultado final é o mesmo).

Ligações rígidas

Quando defines o tipo de ligação entre dois trabalhos para difícil, certificas-te de que não há intervalo de tempo entre o fim de um trabalho e o início do seguinte. Esta condição é útil em cenários em que o metal é aquecido num trabalho e processado no seguinte, e o arrefecimento entre trabalhos não é desejável.

Utilizando links simbólicos padrão e agendamento antecipado, se a rota formar uma cadeia simples sem ramificações, pode-se obter um resultado encontrando uma solução para o primeiro trabalho que satisfaça as suas próprias restrições e, em seguida, continuar pela cadeia propagando o tempo de conclusão do trabalho anterior para o próximo. Se o emprego atual não conseguir encontrar capacidade, o sistema adia o horário de início, sem qualquer consequência para os empregos anteriores. Esta ação pode criar lacunas entre os empregos. No entanto, ao usar elos rígidos (especialmente em relação à capacidade finita) para o mesmo cenário, o facto de um trabalho mais tarde na cadeia não conseguir encontrar capacidade significa que todos os trabalhos previamente agendados têm de ser "arrastados" um a um e, assim, reagendados várias vezes. Especialmente em cenários com elevada carga para múltiplos recursos, os elos rígidos podem causar uma reação em cadeia onde os trabalhos se afetam mutuamente e várias iterações devem ser realizadas antes de o resultado estabilizar num cronograma viável.

Executar motores de agendamento em paralelo

Quando realiza o agendamento como parte de uma execução de planeamento mestre onde utiliza ajudantes, cada um dos threads auxiliares de planeamento mestre pode também executar tarefas de agendamento de ordens de produção. Esta abordagem significa que múltiplos motores de agendamento podem funcionar ao mesmo tempo. Embora o multithreading ofereça um benefício significativo em desempenho, também introduz algumas desvantagens funcionais para o agendamento.

Na MRP, o sistema agenda todas as ordens de produção para um dado nível de lista de materiais (BOM) numa sequência de datas de requisito. Esta sequência significa que o sistema agenda essas ordens com a data de requisito mais cedo primeiro, pelo que têm a maior probabilidade de obter a capacidade de recursos disponível. No entanto, quando várias locomotivas escolhem da lista de ordens não agendadas, a sequência não é garantida porque uma pode completar mais rapidamente do que a outra.

Quando agendas com capacidade finita e múltiplas instâncias de motor, pode ocorrer uma condição de corrida se tentares agendar ordens que usem os mesmos recursos ao mesmo tempo. O campo de conflitos de calendário na página de história dos planos diretores regista o número de condições de corrida. A lógica de resolução de conflitos segue estes passos:

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

Ao agendar com múltiplas instâncias do motor de execução, o resultado não é totalmente determinístico porque depende do tempo exato de cada thread.

Desempenho do agendamento de operações

O planeamento operacional, também conhecido como planeamento aproximado da capacidade, pode ser mais difícil de resolver do ponto de vista do motor se for usada capacidade finita, pois 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 capacidade — só quando os recursos são membros do grupo é que tem 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. Este calendário coloca um limite no tempo que pode dedicar ao agendamento de operações, limitando a uma operação por dia num grupo de recursos. Ao contrário do calendário para recursos específicos, os dados de eficiência do calendário do grupo de recursos são ignorados porque indicam apenas o horário de funcionamento, 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 caberia em 8 horas, independentemente da capacidade total disponível nesse dia. No entanto, a capacidade disponível pode limitar ainda mais a carga.

A carga de agendamento de tarefas em todos os recursos do grupo de recursos para um dado dia é considerada ao calcular a capacidade disponível para esse dia. Para cada data, o cálculo é:

Capacidade disponível do grupo de recursos = Capacidade de recursos no grupo com base no seu calendário − Carga agendada de trabalhos nos recursos do grupo − Carga agendada de operações nos recursos do grupo − Carga agendada de operações no grupo de recursos − Carga agendada de operações no grupo de recursos

No separador Requisitos de Recursos na operação de rota, pode especificar os requisitos de recursos usando um recurso específico (caso em que a operação é agendada usando esse recurso), um grupo de recursos, um tipo de recurso, ou uma ou mais capacidades, competências, cursos ou certificados. Usar todas estas opções proporciona flexibilidade no desenho das rotas, mas complica o planeamento do motor porque a capacidade deve ser contabilizada por 'propriedade' (um nome abstrato usado no motor para capacidade, competências, etc.).

A capacidade de um grupo de recursos para uma capacidade específica é a soma da capacidade de todos os recursos desse grupo que possuem a capacidade em questão. Se um recurso do grupo tiver uma capacidade, o motor considera-a independentemente do nível de capacidade necessário.

No escalonamento de operações, a capacidade disponível de um grupo de recursos é reduzida quando é atribuída a uma operação que requer a capacidade em questão. Se a operação exigir mais do que uma capacidade, a capacidade é 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 programada de trabalho sobre os recursos com a capacidade específica, incluída no grupo de recursos − Carga programada de operações sobre os recursos com a capacidade específica, incluída no grupo de recursos − Carga agendada de operações no próprio grupo de recursos que requerem a capacidade específica

Se um recurso específico tiver uma carga, o motor considera-a ao calcular a capacidade disponível por capacidade do grupo de recursos porque a carga reduz a sua contribuição para a capacidade do grupo, independentemente de a carga ser para essa capacidade específica. Se houver carga ao nível do grupo de recursos, o motor considera-a no cálculo da capacidade disponível por capacidade do grupo de recursos apenas se a carga for de uma operação que exija essa capacidade específica.

Esta lógica aplica-se a cada tipo de propriedade, pelo que usar escalonamento de operações com capacidade finita requer carregar uma quantidade significativa de dados.

Melhorar desempenho de MRP

O vídeo seguinte da conferência tecnológica fornece dicas para melhorar o desempenho do planeamento mestre quando usa MRP com o motor de planeamento mestre obsoleto: Ajuda! O MRP é lento!

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

Para obter detalhes específicos sobre a entrada e saída do processo de agendamento, ative o registo acedendo à administração da organização>, Configuração>, Agendamentos> e cockpit de rastreamento.

Nesta página, selecione Ativar registo no Painel de Ações e depois 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. Ao atualizar a página, aparece uma nova linha na grelha. Selecione a nova linha e depois selecione Download no Painel de Ação. Esta ação dá-lhe uma pasta comprimida .zip contendo os seguintes ficheiros:

Log.txt – Este ficheiro de registo descreve os passos que o motor segue. É detalhado e pode ser avassalador, mas quando experimentares com a configuração da rota para resolver problemas de desempenho, analisa a diferença de tempo entre a primeira e a última linha. Esta diferença mostra o tempo exato que o agendador despendeu.
XmlModel.xml – Este ficheiro contém o modelo construído em X++ e sobre o qual o motor opera. O JobId utilizado no ficheiro correlaciona-se com RecId na tabela de origem que contém as tarefas (ReqRouteJob ou ProdRouteJob). Neste ficheiro, verifique se as datas em ConstraintJobStartsAt e ConstraintJobEndsAt são as esperadas, a JobGoal propriedade está corretamente definida e os trabalhos estão relacionados através das JobLink restrições.
XmlSlots.xml – Este ficheiro contém todos os tempos de trabalho e reservas de capacidade que o motor solicita. Os tempos de trabalho do calendário e as reservas são solicitados apenas pelo motor de agendamento para os períodos em que tenta colocar as tarefas (e um buffer adicional), por isso, se o ficheiro contiver tempos muito distantes no futuro, pode indicar um problema na configuração. Os ResourceProperty nós mostram o grupo de recursos e as capacidades associadas a cada recurso, assim como os períodos de tempo relevantes.
Result.xml – Este ficheiro contém o resultado da execução de agendamento.

A funcionalidade de rastreamento acrescenta um overhead significativo ao desempenho, por isso utilize apenas para investigar o agendamento de ordens específicas de forma controlada. Se o ativares durante uma execução de planeamento mestre, rapidamente atinge o limite de tamanho e para.

Resolver problemas de desempenho

Como pode ver nas secções anteriores, algumas armadilhas na configuração e utilização do motor de agendamento podem levar a problemas de desempenho. A lista de verificação seguinte pode ajudá-lo a resolver estes problemas. Olha para todos os pontos porque muitas vezes é uma combinação de vários fatores que leva aos problemas.

Tip

A tabela seguinte resume os problemas de desempenho mais comuns no agendamento de tarefas e as suas soluções recomendadas. Utilize os links para aceder às orientações detalhadas de cada área.

Problema	Recommendation	Details
Não é necessário agendamento durante o MRP	Defina o limite de tempo de capacidade para zero ou use um prazo padrão de produção	Agendamento como parte do MRP
Demasiados recursos aplicáveis	Atribuir um recurso específico à operação no momento do desenho da rota	Muitos recursos aplicáveis
Operações paralelas resultam em um agendamento lento	Modelar pares como recursos "virtuais" ou excluir operações que não sejam gargalos.	Operações paralelas
Quantidade de recursos superior a um	Rever se são realmente necessários múltiplos recursos para a operação	Quantidade de recursos
Sobrecarga de capacidade finita	Utilize a opção de gargalo e limite temporal de capacidade separada para recursos de gargalo	Capacidade finita
Links rígidos complicam o agendamento	Use links físicos apenas quando estritamente necessário	Ligações rígidas
Calendário separado por recurso	Reutilizar calendários entre recursos tanto quanto possível	Calendários
Muitos horários por dia de calendário	Minimizar os horários de trabalho (por exemplo, evitar incorporar pausas de cinco minutos)	Intervalos horários
Tempos de agendamento em falta ou excessivos	Ativar ambas as definições de timeout; definir o tempo máximo de agendamento para cerca de 30 segundos	Timeouts

Realizar agendamento como parte do MRP quando não é necessário

Embora as rotas sejam usadas para fins de controlo de produção, como cálculo de custos e relatórios, podem não precisar de ser consideradas durante o MRP. Em alguns casos, ter um prazo normal de produção especificado para o item será suficiente para o planeamento. Defina o limite de tempo de capacidade para zero para desligar o agendamento da rota. Se for necessário agendar, defina cuidadosamente a cerca temporal de capacidade, pois as rotas podem não precisar de ser consideradas para a cerca temporal total de cobertura do MRP.

Se a encomenda não for agendada durante o MRP, terá de ser agendada quando a ordem 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

Quando desenhar a rota, evite tentar modelar o mundo real exatamente com todas as etapas que o processo de produção segue. Embora esta abordagem possa ser útil em alguns casos, não é boa para o desempenho porque o modelo do motor cresce (em termos de tarefas e restrições), e mais instruções SQL são executadas para inserir e atualizar tarefas e reservas de capacidade. Além disso, há o efeito posterior de ter de em algum momento reportar o progresso das tarefas, o que as publicações automáticas podem mitigar. Se os dados não forem usados para nada, criam uma carga desnecessária.

Crie apenas as operações estritamente necessárias para o agendamento (normalmente recursos de gargalo) ou para fins de cálculo de custos. Em vez disso, agrupe muitas operações menores e distintas numa operação maior que represente uma parte maior do processo.

Muitos recursos aplicáveis para uma operação

Os requisitos de recursos definidos na relação operacional determinam o número de recursos aplicáveis para uma operação. O requisito pode ser para um recurso específico ou pode basear-se na pertença do recurso a um grupo ou capacidade de recursos.

Se não usares capacidade finita para agendamento e todos os recursos aplicáveis tiverem o mesmo calendário e eficiência, o motor de agendamento escolhe sempre o mesmo recurso para uma operação, mas só depois de tentar todos os recursos aplicáveis para verificar se existe algum que seja melhor do que os outros. Neste caso, pode reduzir significativamente a carga do agendamento atribuindo sempre um recurso específico à operação no momento do desenho 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 realizar uma tarefa específica, são também a fonte de muitos problemas de desempenho. Se atribuir um requisito para um recurso individual específico tanto à operação primária como à 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 representam a equipa que está sempre em conjunto na operação) ou simplesmente não modelar uma das operações se esta não representar um gargalo.

Rota com uma quantidade de recursos superior a um

Se a quantidade de recursos necessária para uma operação for superior a um, o resultado é efetivamente o mesmo que usar operações primárias/secundárias porque múltiplos trabalhos paralelos são enviados para o motor. No entanto, neste caso, não pode usar atribuições específicas de recursos porque uma quantidade superior a um requer mais do que um recurso para ser aplicável à 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

Usar capacidade finita requer que o motor carregue informação de capacidade de uma base de dados, o que pode adicionar sobrecarga computacional, especialmente em ambientes onde os recursos são reservados próximos da capacidade máxima. Por isso, é importante avaliar cuidadosamente se um recurso precisa realmente de usar capacidade finita ou se pode estar sobrecarregado. Como pode haver uma diferença entre os recursos de capacidade finita na importância de não sobrecarregar, use a opção de gargalo num recurso em combinação com um valor separado no plano em "Limite de tempo de capacidade para recursos de gargalo." Usar o conceito de gargalo pode permitir baixar a barreira de tempo de capacidade finita geral.

Definir ligações fixas

O tipo de ligação padrão da rota é flexível, o que permite um intervalo de tempo entre o tempo de conclusão de uma operação e o início da seguinte. Se permitir esta lacuna, pode fazer com que a produção fique parada se não houver materiais ou capacidade disponíveis para uma das operações. Esta situação pode levar a um aumento do trabalho em curso. Este problema não acontece com ligações rígidas porque o acabamento e o início têm de se alinhar perfeitamente. No entanto, a configuração de ligações fixas torna o problema de agendamento mais difícil porque o sistema tem de calcular o tempo de trabalho e as sobreposições de capacidade para os dois recursos envolvidos nas operações. Se o cronograma também envolver operações paralelas, este requisito acrescenta 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.

Use ligações fixas apenas quando estritamente necessário e considere cuidadosamente se é necessário para cada operação da rota.

Para reduzir o trabalho em curso sem aplicar ligações rígidas, agende a ordem duas vezes, mudando para o sentido oposto na segunda passagem. Se o primeiro cronograma foi elaborado retroativamente a partir da data de entrega, então o segundo cronograma deve ser feito a partir da data de início programada. Esta abordagem comprime os trabalhos o máximo possível para minimizar o trabalho em progresso.

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, pode parecer tentador gerar um calendário para cada recurso e depois ajustar a informação desse calendário quando o recurso tiver períodos de inatividade ou outros problemas. No entanto, esta abordagem limita severamente a capacidade do motor de armazenar em cache os dados do calendário, pois precisa de solicitar novos dados para cada recurso. Esta abordagem pode causar problemas de desempenho. Reutilizar calendários tanto quanto possível entre recursos e controlar as alterações de tempo de inatividade atribuindo um ID de calendário diferente para um período.

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

Como o motor funciona analisando as faixas horárias uma a uma para a capacidade, é benéfico minimizar o número de faixas horárias por dia. Por exemplo, considere se é importante que o horário resultante reflita que os trabalhadores fazem uma pausa de cinco minutos a cada hora.

Tempo limites de agendamento grandes (ou nenhum)

Pode otimizar o desempenho do motor de agendamento usando parâmetros encontrados na página de parâmetros de agendamento . Defina sempre as definições de timeout de Agendamento ativadas e timeout de otimização de Agendamento ativadas como Sim. Se os definir para Não, a programação pode executar indefinidamente se for criado um percurso inviável com muitas opções.

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 usar aqui depende muito da complexidade da rota e de configurações como a capacidade finita, mas 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. Este valor só afeta rotas que utilizam operações paralelas, pois estas operações tornam necessário testar diferentes combinações.