Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Note
Grupos de interesse da comunidade mudaram-se do Yammer para o Microsoft Viva Engage. Para ingressar em uma comunidade Viva Engage e participar das discussões mais recentes, preencha o formulário Requeste o acesso à Comunidade Viva Engage de Finanças e Operações e escolha a comunidade que você deseja ingressar.
O motor de agendamento de recursos programa rotas para ordens de produção planejadas e liberadas.
O problema no agendamento de trabalhos é um problema extremamente complexo no qual o tempo da solução aumenta exponencialmente com o número de variáveis de decisão. Os clientes geralmente configuram rotas de produção e dados relacionados de maneiras que criam problemas de agendamento que não são solvíveis em tempo razoável, mesmo no hardware moderno. Este artigo explica o mecanismo de agendamento e como uma configuração específica influencia o desempenho.
Melhore o desempenho de agendamento reduzindo a complexidade do problema que o mecanismo resolve. Alguns dos principais fatores que podem afetar o desempenho incluem:
- Roteiros com muitas operações
- Roteiros com operações paralelas
- Operações com mais de um recurso
- Operações com vários recursos aplicáveis
- Uso de links rígidos
- Uso de capacidade finita
- Número de calendários diferentes usados
- Número de intervalos de tempo de trabalho por dia no calendário
- Duração total do roteiro
- Executar vários mecanismos de agendamento em paralelo
Visão geral do fluxo de agendamento básico
Para entender como uma determinada configuração afeta o desempenho, você precisa saber como o processo flui dentro do mecanismo e no código X++ que o envolve.
O processo básico de agendamento de uma ordem consiste em três etapas principais:
- Carregando dados – os modelos de dados X++ se transformam no modelo de dados interno do motor como tarefas e restrições.
- Agendamento – O mecanismo processa o modelo e as restrições fornecidas para gerar um resultado. Ele solicita informações de tempo de trabalho e reservas de capacidade existentes do X++ conforme necessário.
- Salvar dados – o código X++ processa o resultado do mecanismo, na forma de slots de reserva de capacidade de trabalho, para salvar reservas de capacidade e atualizar os horários de início e término dos trabalhos, da operação ou da ordem.
Carregar dados no mecanismo
O mecanismo de agendamento usa um modelo de dados mais abstrato do que o banco de dados Gerenciamento da Cadeia de Suprimentos porque é um mecanismo genérico que manipula várias fontes de dados. Os conceitos de rota, operações secundárias e tempo de execução são traduzidos para o modelo genérico de trabalho e restrição que o mecanismo expõe. A lógica de criação do modelo inclui lógica de negócios significativa e varia dependendo dos dados de origem. A classe X++ responsável é WrkCtrScheduler, que inclui classes derivadas para pedidos de produção planejados, ordens de produção liberadas e previsões de projeto.
Por exemplo, considere uma rota mostrada na tabela e imagem a seguir, que é relativamente simples.
| Oper. Não. | Priority | Tempo de preparação | Tempo de execução | Tempo de espera posterior | Quantidade de recursos | Avançar |
|---|---|---|---|---|---|---|
| 10 | Primária | 1,00 | 2.00 | 1 | 20 | |
| 10 | Secundário 1 | 1 | 20 | |||
| 20 | Primária | 3.00 | 1,00 | 3 | 0 |
Quando você envia essa rota para o mecanismo, ela divide a rota em oito trabalhos, conforme mostrado na ilustração a seguir (selecione a imagem para ampliá-la).
O vínculo padrão entre dois trabalhos é FinishStart, o que significa que a hora de término de um trabalho deve ocorrer antes da hora de início de outro. A configuração deve ser feita pelo mesmo recurso que manipula o processo posteriormente, portanto, há OnSameResource restrições entre eles. Entre os trabalhos da operação primária e secundária para 10, há StartStart e FinishFinish links, o que significa que os trabalhos devem iniciar e terminar ao mesmo tempo. Além disso, há NotOnSameResource restrições que impedem que o mesmo recurso seja usado para operações primárias e secundárias.
Para a operação 20, em que a quantidade de recursos é definida como 3, o trabalho de processo é dividido em três trabalhos distintos em que todos os trabalhos devem ser executados exatamente ao mesmo tempo. Nesse caso, o grupo de rotas é configurado para não reservar capacidade para filas subsequentes, por isso há apenas uma única tarefa para a fila posterior.
O mecanismo de agendamento entende apenas os conceitos de trabalhos e não reconhece operações. Essa limitação significa que, durante o agendamento da operação, o sistema divide as operações em trabalhos, embora esses trabalhos não sejam persistidos no banco de dados.
Para cada trabalho, você define qual é o requisito de capacidade do trabalho (o número de segundos necessário). Dependendo de como os requisitos de recursos são definidos, você também pode enviar, para cada trabalho, uma lista de todos os recursos aplicáveis potenciais em que o trabalho pode ser executado e qual é o requisito de capacidade para esse recurso específico. Embora você envie a lista de recursos aplicáveis ao compilar o modelo, o mecanismo garante que a atribuição de recursos permaneça válida durante toda a duração do trabalho.
Componentes internos do mecanismo de agendamento
Interface do mecanismo de agendamento
Para entender como o mecanismo funciona internamente, examine a funcionalidade que ele expõe externamente. No X ++, a interface principal é WrkCtrSchedulerEngineInterface. Ele tem os métodos descritos nas subseções a seguir.
Mecanismo geral
| Método | Propósito |
|---|---|
run |
Agenda todos os trabalhos carregados e retorna o código de erro. |
getJobSchedulingSequenceResult |
Obtém o resultado do agendamento e o primeiro trabalho de erro para a sequência identificada por um trabalho específico. |
validateJobCapacityReservations |
Valida as reservas de capacidade para todos os trabalhos armazenados pelo mecanismo. |
setReservationsTimeStamp |
Envia um carimbo de data/hora para o mecanismo definido em todas as novas reservas de capacidade para os trabalhos agendados no cache do mecanismo. |
addPropertyToGroupAggregation |
Adiciona um prefixo de propriedade ao conjunto de propriedades usado quando a capacidade é agregada. |
addResource |
Adiciona um recurso ao pool de recursos do mecanismo de agendamento. |
addResourceGroup |
Adiciona um grupo de recursos ao grupo de recursos do mecanismo de agendamento. |
addResourceGroupMembership |
Adiciona um recurso como membro a um grupo de recursos. |
addOptimizationGoal |
Adiciona uma meta de otimização de agendamento (duração ou prioridade). |
Trabalhos individuais
| Método | Propósito |
|---|---|
addJobInfo |
Adiciona um registro de informações do trabalho que informa o mecanismo sobre um trabalho que deve ser agendamento. |
addConstraintJobEndsAt |
Adiciona uma restrição que um trabalho deve ser concluído em uma data e hora especificadas. |
addConstraintJobStartsAt |
Adiciona uma restrição de que um trabalho deve ser iniciado em uma data e hora especificadas. |
addConstraintMaxJobDays |
Define a restrição que um trabalho pode abranger durante um número máximo especificado de dias. |
addConstraintResourceRequirement |
Adiciona a restrição de que o trabalho deve ser agendado em um recurso específico. |
addJobBindPriority |
Adiciona uma prioridade de associação de trabalho para um par (trabalho, nível de restrição). Um valor de prioridade mais alto significa que as variáveis de trabalho são atribuídas mais cedo. O trabalho é processado antes de trabalhos com valor de prioridade mais baixo na mesma sequência. |
addJobCapacity |
Adiciona informações de capacidade máxima de um trabalho (como o tempo de execução necessário para o trabalho), não importa em qual recurso o trabalho é executado. |
addJobResourceCapacity |
Adiciona um recurso ao conjunto de recursos que podem ser usados para executar um trabalho e indica a capacidade necessária durante a execução nesse recurso. |
addJobGoal |
Adiciona informações de meta de trabalho para um nível de restrição específico (hora de término mais antiga ou hora de início mais recente). |
addJobResourcePriority |
Adiciona a prioridade a ser usada quando um trabalho é agendado em um recurso. |
addJobResourceRuntime |
Especifica uma hora de trabalho dependente do recurso em que o trabalho está agendado. |
addJobRuntime |
Especifica uma hora de trabalho independente do recurso no qual o trabalho está agendado. |
scheduleJobOnResourceGroup |
Marca um trabalho para agendamento no nível de grupo de recursos. |
setJobResourcePreemptionAllowed |
Define se um resgate é permitido para um trabalho em um recurso (se o mecanismo tiver permissão para agendar o trabalho em slots de capacidade não contínuos). |
setRequiredNumberOfResources |
Define o número de recursos necessários para agendar um trabalho (somente para o agendamento de operações). |
Restrições entre trabalhos
| Método | Propósito |
|---|---|
addJobLink |
Adiciona um link (como término>início) entre dois trabalhos. |
addConstraintEndsDelayed |
Define a restrição de que um trabalho não pode terminar antes que outros trabalhos terminem, além de algum tempo de atraso. |
addConstraintJobListWorkingTimeIntersect |
Adiciona uma restrição de que os slots de capacidade reservados para os trabalhos devem estar nos horários trabalho em interseção para os dois recursos usados pelos trabalhos. |
addConstraintJobOverlap |
Adiciona uma restrição que define como os trabalhos são sequenciados quando uma determinada quantidade de um item pode ser movida entre dois recursos enquanto o primeiro recurso ainda não está concluído, para que o segundo recurso possa iniciar o processamento. |
addConstraintNotOnSameResource |
Adiciona uma restrição de que dois trabalhos não devem ser agendados no mesmo recurso. |
addConstraintOnSameResource |
Adiciona uma restrição de que dois trabalhos devem usar o mesmo recurso. |
addJobSameReservations |
Adiciona uma restrição de que um trabalho deve ser concluído com reservas de capacidade para os mesmos slots de horário que o trabalho principal. |
setPrimaryParallelJob |
Adiciona informações sobre o trabalho que é o principal em um conjunto de trabalhos paralelos. |
Agente de resolução
O mecanismo é um solucionador de restrições especializado com heurística personalizada. O agente de resolução se baseia em dois elementos principais: variáveis e restrições.
Variable
Uma variável representa um domínio de valores possíveis. O mecanismo de agendamento tem dois tipos de variáveis:
- Variável DateTime – Tem um domínio de todas as datas e horas. Você pode restringir o domínio movendo os limites inferior e superior para o tempo da variável mais próximo um do outro.
- Variável de recurso – tem um domínio de recursos aplicáveis. Você pode restringir o domínio eliminando recursos da lista.
Restrição
Uma restrição atua em variáveis restringindo seus domínios. Ele também depende de variáveis, portanto, ele é ativado quando as variáveis são alteradas. O processo de "propagação de restrições" é quando uma restrição executa sua função principal e relata novamente a lógica principal, se for bem-sucedido.
Uma variável é considerada associada quando não pode ser restrita ainda mais. Para uma variável DateTime, essa condição significa que os limites superior e inferior são os mesmos. Para a variável Resource, isso significa que ela tem apenas um único recurso aplicável. Quando todas as variáveis são limites, uma solução é encontrada.
Níveis de restrição
Quando o agendamento faz parte da fase de cobertura do MRP (planejamento de requisitos materiais), o sistema agenda os pedidos para trás da data de requisito. No entanto, se o sistema não conseguir encontrar uma agenda que comece hoje ou mais tarde e termine antes da data do requisito, ele alterará a direção de agendamento para avançar a partir de hoje.
O sistema organiza as restrições em níveis para lidar com essa regra de negócios principal. Se o sistema não encontrar uma solução ao usar as restrições no nível mais alto, ele descartará todas as restrições nesse nível e tentará o nível inferior. Na prática, esse processo significa que, para o agendamento retroativo, o modelo contém um nível 1 com metas de trabalho de hora de início mais tardia, dada uma restrição de hora de término máxima (a data de requisito) e um nível 0 com metas de trabalho de hora de término mais cedo e uma restrição de hora de início mínima de hoje.
Algoritmo
As etapas principais do algoritmo do mecanismo são:
- Encontre sequências (cadeias de trabalho) que podem ser resolvidas separadamente.
- Tente encontrar uma solução inicial para a sequência no nível de restrição mais alto.
- Classifique os trabalhos na sequência com base na meta de trabalho e nas prioridades, para que o sistema possa encontrar um trabalho inicial.
- Percorra os trabalhos na seguinte sequência:
- Localize todas as restrições que precisam ser propagadas e execute a propagação.
- Se todas as variáveis para o trabalho estiverem associadas, uma solução para esse trabalho será encontrada.
- Se uma das variáveis não puder ser associada sem violar as restrições, reverta a associação de variável, tente um valor diferente no domínio (para variável de recurso) e execute novamente a propagação de restrição.
- Se nenhuma solução for encontrada, remova todas as restrições no nível de restrição atual, reduza o nível de restrição (se houver níveis inferiores disponíveis) e tente novamente a pesquisa de solução com o novo conjunto de restrições.
- Se uma solução viável for encontrada, inicie a fase de otimização, que tenta encontrar uma solução melhor até que o tempo limite de otimização seja atingido ou todas as combinações de recursos sejam esgotadas.
O solucionador de restrições não leva em consideração as especificidades do algoritmo de agendamento. A "mágica" ocorre na definição e combinação das várias restrições.
Determinar horários de trabalho
Uma grande parte das restrições (internas) no mecanismo controla o horário de trabalho e a capacidade de um recurso. Essencialmente, a tarefa é percorrer os slots de tempo de trabalho para um recurso a partir de um determinado ponto em uma determinada direção e encontrar um intervalo longo o suficiente no qual o tempo necessário do trabalho possa caber.
Para isso, o mecanismo precisa saber os horários de trabalho de um recurso. Ao contrário dos dados do modelo principal, os tempos de trabalho são carregados lentamente, o que significa que eles são carregados no mecanismo conforme necessário. O motivo dessa abordagem é que muitas vezes há tempos de trabalho na Gestão da Cadeia de Suprimentos por um longo período e, normalmente, existem muitos calendários, portanto, os dados seriam significativamente grandes para carregar previamente.
O mecanismo solicita informações de calendário em partes invocando o método WrkCtrSchedulingInteropDataProvider.getWorkingTimesde classe X++. A solicitação é para uma ID de calendário específica em um intervalo de tempo específico. Dependendo do estado do cache do servidor no Gerenciamento da Cadeia de Suprimentos, cada uma dessas solicitações pode resultar em várias chamadas de banco de dados, o que leva muito tempo (em relação ao tempo computacional em si). Além disso, se o calendário contiver definições de tempo de trabalho muito elaboradas com muitos intervalos de tempo de trabalho por dia, essa complexidade aumenta o tempo que o carregamento leva.
Quando o mecanismo de agendamento carrega os dados em tempo de trabalho, ele retém esses dados em seu cache interno para o calendário específico. Essa retenção significa que, se outros trabalhos ou recursos usarem o mesmo calendário, as próximas pesquisas poderão ser executadas rapidamente da memória. Uma causa comum de desempenho incorreto é se uma ID de calendário separada é usada para cada recurso, porque os dados são solicitados para cada calendário, mesmo que o conteúdo dos calendários possa ser o mesmo.
Capacidade finita
Quando você usa a capacidade finita, o sistema divide e reduz os slots de tempo de trabalho do calendário com base nas reservas de capacidade existentes. A mesma WrkCtrSchedulingInteropDataProvider classe busca essas reservas junto com os calendários, mas usa o getCapacityReservations método. Ao agendar durante o planejamento mestre, o sistema considera as reservas para o plano mestre específico. Se você habilitar a configuração na página Parâmetros de Planejamento Mestre, o sistema também incluirá reservas de pedidos de produção firmes. Da mesma forma, ao agendar uma ordem de produção, você pode optar por incluir reservas de pedidos planejados existentes, embora essa sequência não seja tão comum quanto o contrário.
O agendamento leva mais tempo quando você usa a capacidade finita por vários motivos:
- Buscar as informações de capacidade do banco de dados é uma operação lenta. O armazenamento em cache das informações de capacidade no lado do servidor normalmente não é tão eficiente quanto para os horários de trabalho, porque essas informações não são compartilhadas entre os recursos da mesma forma que os calendários geralmente são.
- O número de intervalos de tempo de trabalho a serem percorridos aumenta devido às divisões. Normalmente, o sistema precisa investigar slots por um período de tempo mais longo antes de encontrar uma solução.
- Depois que o agendamento for concluído, o sistema deverá verificar se há reservas conflitantes (consulte a seção "Executando mecanismos de agendamento em paralelo" para obter detalhes).
Examinar as combinações de recursos
Se a sequência de trabalhos contiver apenas os links padrão FinishStart, o que significa que ela forma uma cadeia simples sem ramificações, o sistema pode obter um resultado ideal (considerando apenas uma única ordem, e não várias ordens) encontrando a melhor solução para o primeiro trabalho e então passar a encontrar a melhor solução para o próximo trabalho. A melhor solução para um trabalho é encontrar o recurso que pode obter as datas de início e término do trabalho mais próximas do objetivo do trabalho (em agendamento avançado isso significa obter a data de término do trabalho o mais cedo possível), enquanto ainda respeita as restrições.
Quando há trabalhos paralelos, encontrar uma solução pode envolver 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 os trabalhos paralelos conectados. Especialmente ao agendar um pedido retroativamente a partir de uma data de requisito, pode demorar um pouco até que o sistema perceba que não há solução que permita que os trabalhos paralelos se encaixem antes da data de hoje. A lógica precisa verificar todas as combinações porque pode haver alguns recursos que tenham uma eficiência maior ou um calendário diferente que possa dar um resultado. Essa condição significa que, se você não definir um limite de tempo limite, o processo será executado por um longo tempo antes de alterar a direção para avançar.
Essa lógica combinatória também significa que a adição de recursos mais aplicáveis pode tornar o mecanismo mais lento. Se ocorrerem problemas de desempenho quando você tiver operações paralelas e agendamento com capacidade infinita, você poderá corrigir parcialmente o problema fazendo com que o designer de rotas tome uma decisão sobre qual recurso deve ser usado e atribua o recurso diretamente na operação (porque o mecanismo na maioria dos casos sempre acaba escolhendo o mesmo recurso, portanto, o resultado final é o mesmo).
Links físicos
Ao definir o tipo de vínculo entre dois trabalhos como difícil, verifique se não há intervalo de tempo entre o término de um trabalho e o início do próximo. Essa condição é útil em cenários em que o metal é aquecido em um trabalho e processado no próximo, e o resfriamento entre trabalhos não é desejável.
Usando links simbólicos padrão e agendamento de encaminhamento, se a rota forma uma cadeia simples sem ramificações, você pode obter um resultado encontrando uma solução para o primeiro trabalho que atenda a suas próprias restrições e, em seguida, avançando pela cadeia e propagando a hora de término do trabalho anterior para o próximo trabalho. Se o trabalho atual não conseguir encontrar nenhuma capacidade disponível, o sistema moverá o tempo de início ainda mais, sem qualquer consequência para os trabalhos anteriores. Essa ação potencialmente cria lacunas entre os trabalhos. No entanto, usando links rígidos (especialmente em conexão com a capacidade finita) para o mesmo cenário, o fato de que um trabalho mais tarde na cadeia não pode encontrar capacidade, significa que todos os trabalhos agendados anteriores devem ser "arrastados" um a um e, assim, reagendados várias vezes. Especialmente em cenários com alta carga para vários recursos, os links rígidos podem causar uma reação em cadeia em que os trabalhos afetam uns aos outros e várias iterações devem ser executadas antes que o resultado se estabilize em um agendamento viável.
Executar mecanismos de agendamento em paralelo
Quando você executa o agendamento como parte de uma execução de planejamento mestre em que usa funções auxiliares, cada um dos threads auxiliares de planejamento mestre também pode assumir tarefas de agendamento de ordem de produção. Essa abordagem significa que vários mecanismos de agendamento podem ser executados ao mesmo tempo. Embora o multithreading forneça um benefício de desempenho significativo, ele também apresenta algumas desvantagens funcionais para agendamento.
No contexto do MRP, o sistema agenda todos os pedidos de produção para um determinado nível de lista de materiais (BOM) na ordem de datas de necessidade. Essa sequência significa que o sistema agenda esses pedidos com a data de necessidade mais antiga primeiro, para que eles tenham a maior chance de obter a capacidade de recursos disponíveis. No entanto, quando vários mecanismos escolhem da lista de pedidos não programados, a sequência não é assegurada porque um mecanismo pode concluir mais rápido que o outro.
Quando você agenda com capacidade finita e várias instâncias do mecanismo, pode ocorrer uma condição de concorrência ao tentar agendar pedidos que usam os mesmos recursos ao mesmo tempo. O campo Conflitos de agendamento na página de histórico de planos mestres registra o número de condições de corrida. A lógica de resolução de conflitos segue estas etapas:
- Agende uma ordem (sem bloqueio) e obtenha reservas de capacidade.
- Faça o bloqueio.
- Verifique se existem reservas de capacidade mais recentes para os recursos agendados no período de tempo.
- Em caso negativo, anote a capacidade e libere o bloqueio.
- Em caso afirmativo, libere o bloqueio e agende novamente a ordem desde o início.
Ao agendar com várias instâncias do mecanismo, o resultado não é totalmente determinístico porque depende do tempo exato de cada thread.
Desempenho do agendamento de operações
O agendamento de operação, também conhecido como planejamento de capacidade de corte bruto, pode ser mais difícil de resolver do ponto de vista do mecanismo se a capacidade finita for usada porque mais dados são necessários para determinar a viabilidade.
A capacidade de um grupo de recursos depende de quais e quantos recursos são membros do grupo de recursos. Um grupo de recursos em si não tem nenhuma capacidade– somente quando os recursos são membros do grupo, ele tem capacidade. Como a associação do 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 é usado para determinar as horas de início e término de cada operação. Esse calendário coloca um limite de quanto tempo você pode agendar operações para uma operação em um dia em um 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 ele só indica horários de abertura, não capacidade real.
Por exemplo, se a hora de trabalho de um grupo de recursos em uma data específica for das 8:00 às 16:00, uma operação não poderá colocar mais carga no grupo de recursos do que o que pode caber em 8 horas, não importa a capacidade que o grupo de recursos tenha disponível no total naquele dia. No entanto, a capacidade disponível pode limitar ainda mais a carga.
A carga de agendamento de trabalho em todos os recursos no grupo de recursos para um determinado dia é considerada ao calcular a capacidade disponível para esse dia. Para cada data, o cálculo é:
Capacidade do grupo de recursos disponível = Capacidade de recursos no grupo com base em seu calendário – Carga agendada de trabalho nos recursos do grupo – Carga agendada de operações nos recursos do grupo – Carga agendada de operações no grupo de recursos
Na guia Requisitos de recurso na operação de rota, você pode especificar os requisitos de recurso usando um recurso específico (nesse caso, a operação é agendada usando esse recurso), um grupo de recursos, um tipo de recurso ou um ou mais recursos, habilidade, curso ou certificado. O uso de todas essas opções fornece flexibilidade no design de rotas, mas complica o agendamento para o mecanismo porque a capacidade deve ser contabilizada por "propriedade" (um termo abstrato usado no mecanismo para descrever capacidade, habilidades e assim por diante).
A capacidade do grupo de recursos para uma funcionalidade é a soma da capacidade de todos os recursos no grupo de recursos que têm a capacidade em questão. Se um recurso no grupo tiver uma funcionalidade, o mecanismo o considerará não importa o nível de capacidade exigido.
No agendamento de operações, a capacidade disponível para uma determinada funcionalidade para um grupo de recursos é reduzida quando é carregada com uma operação que requer a funcionalidade em questão. Se a operação exigir mais de uma capacidade, a capacidade operacional será reduzida para todas as capacidades necessárias.
Para cada data, o cálculo necessário é:
Capacidade disponível para uma funcionalidade = Capacidade para a funcionalidade – Carga agendada de trabalho nos recursos com a funcionalidade específica, incluída no grupo de recursos – Carga agendada de operações nos recursos com a funcionalidade específica, incluída no grupo de recursos – Carga agendada de operações no próprio grupo de recursos que exige a capacidade específica
Se um recurso específico tiver uma carga, o mecanismo o considerará ao calcular a capacidade disponível do grupo de recursos por funcionalidade, pois a carga reduz sua contribuição para a capacidade do grupo, independentemente de a carga ser para essa funcionalidade específica. Se houver carga no nível do grupo de recursos, o mecanismo o considerará no cálculo da capacidade disponível do grupo de recursos por funcionalidade somente se a carga for de uma operação que exija a funcionalidade específica.
Essa lógica se aplica a cada tipo de propriedade, portanto, usar o agendamento de operações com capacidade finita requer o carregamento de uma quantidade significativa de dados.
Melhorar a performance do MRP
O vídeo de conferência técnica a seguir fornece dicas para melhorar o desempenho do planejamento mestre ao usar o MRP com o mecanismo de planejamento mestre preterido: Ajuda! O MRP está lento!
Exibir a entrada e a saída do mecanismo de agendamento
Para obter detalhes específicos sobre a entrada e a saída do processo de agendamento, habilite o registro em log acessando Administração da organização>Configuração>Agendamento>Cockpit de rastreamento de agendamento.
Nesta página, selecione Habilitar registro em log no painel de ações e execute o agendamento para a ordem de produção. Ao concluir, retorne à página Ferramenta cockpit de rastreamento de agendamento e selecione Desabilitar log no Painel de ações. Atualize a página e uma nova linha será exibida na grade. Selecione a nova linha e, em seguida, selecione Baixar no Painel de Ação. Esta ação fornece uma pasta compactada .zip que contém os seguintes arquivos:
- Log.txt – Este arquivo de log descreve as etapas pelas quais o mecanismo passa. Ele é detalhado e pode parecer complexo, mas quando você experimenta ajustes na rota para resolver questões de desempenho, observe a diferença de tempo entre a primeira e a última linha. Essa diferença mostra o tempo exato gasto pelo agendador.
-
XmlModel.xml – esse arquivo contém o modelo que é integrado em X++ e no qual o mecanismo opera. O
JobIdusado no arquivo se correlaciona com oRecIdda tabela de origem que contém os trabalhos (ReqRouteJobouProdRouteJob). Neste arquivo, verifique se as datas emConstraintJobStartsAteConstraintJobEndsAtestão conforme o esperado, a propriedadeJobGoalestá definida corretamente, e as tarefas estão relacionadas por meio das restriçõesJobLink. -
XmlSlots.xml – esse arquivo contém todos os tempos de trabalho e reservas de capacidade que o mecanismo solicita. **
Os horários de trabalho e as reservas do calendário são solicitados apenas pelo sistema para os períodos em que ele tenta alocar as tarefas (e um buffer extra), portanto, se o arquivo contiver horários muito à frente no futuro, pode ser um sinal de um problema na configuração. Os
ResourcePropertynós exibem o grupo de recursos e as capacidades associadas a cada recurso, juntamente com os períodos de tempo relevantes. - Result.xml – esse arquivo contém o resultado da execução de agendamento.
A funcionalidade de rastreamento adiciona uma sobrecarga de desempenho significativa, portanto, use-a apenas para investigar o agendamento de pedidos específicos de maneira controlada. Se você ativá-lo durante uma execução de planejamento mestre, ele atingirá rapidamente seu limite de tamanho e para.
Solucionar problemas de desempenho
Como você pode ver nas seções anteriores, algumas armadilhas na instalação e no uso do mecanismo de agendamento podem levar a problemas de desempenho. A lista de verificação a seguir pode ajudá-lo a solucionar esses problemas. Examine todos os pontos porque geralmente é uma combinação de vários fatores que leva a problemas.
Dica
A tabela a seguir resume os problemas de desempenho de agendamento de trabalho mais comuns e suas soluções recomendadas. Use os links para ir para as diretrizes detalhadas para cada área.
| Problema | Recomendação | Detalhes |
|---|---|---|
| Agendamento não necessário durante a execução do MRP | Defina o limite de tempo de capacidade como zero ou use um tempo de execução de produção padrão | Agendamento como parte do MRP |
| Muitos recursos aplicáveis | Atribuir um recurso específico à operação em tempo de design de rota | Muitos recursos aplicáveis |
| Operações paralelas tornam o agendamento lento | Modelar pares como recursos "virtuais" ou excluir operações de não gargalo | Operações paralelas |
| Quantidade de recursos maior que uma | Examine se vários recursos são realmente necessários para a operação | Quantidade de recursos |
| Sobrecarga de capacidade finita | Usar a opção de gargalo e definir uma restrição de tempo de capacidade para recursos críticos | Capacidade finita |
| Vínculos rígidos complicam o agendamento | Usar links rígidos somente quando estritamente necessário | Links rígidos |
| Separar calendário por recurso | Reutilizar calendários entre recursos o máximo possível | Calendários |
| Muitos intervalos de tempo por dia do calendário | Minimizar os intervalos de tempo de trabalho (por exemplo, ignorar a modelagem de interrupção de cinco minutos) | Intervalos de tempo |
| Tempos limite de agendamento ausentes ou demasiado grandes | Habilitar ambas as configurações de tempo limite; definir o tempo máximo de agendamento para cerca de 30 segundos | Timeouts |
Executar o agendamento como parte do MRP quando não é necessário
Embora as rotas sejam usadas para fins de controle de produção, como custos e relatórios, talvez não precisem ser consideradas durante o MRP. Em alguns casos, o prazo de entrega padrão especificado da produção do item será suficiente para o planejamento. Defina o limite de tempo de capacidade como zero para desativar o agendamento de rotas. Se o agendamento for necessário, defina cuidadosamente a cerca de tempo de capacidade porque as rotas talvez não precisem ser consideradas para toda a extensão da cerca de tempo de cobertura do MRP.
Se a ordem não for programada durante o MRP, ela precisará ser agendada quando a ordem planejada for confirmada. Isso significa que o processo de confirmação levará mais tempo, de forma que, dependendo de quantas ordens planejadas sugeridas forem confirmadas, o ganho de desempenho durante o MRP poderá ser perdido na confirmação.
Roteiro com operações desnecessárias
Ao projetar a rota, evite tentar modelar o mundo real exatamente com todas as etapas pelas quais o processo de produção passa. Embora essa abordagem possa ser útil em alguns casos, ela não é boa para o desempenho porque o modelo do mecanismo aumenta (em termos de trabalhos e restrições) e mais instruções SQL são executadas para inserir e atualizar trabalhos e reservas de capacidade. Além disso, há o efeito a jusante de ter que eventualmente relatar o progresso das tarefas, o que as postagens automáticas podem atenuar. Se os dados não forem usados para nada, ele criará uma carga desnecessária.
Crie apenas as operações estritamente necessárias para planejamento (normalmente recursos que representam gargalos) ou propósitos de cálculo de custos. Em vez disso, agrupe muitas operações distintas menores em uma operação maior que representa uma parte maior do processo.
Muitos recursos aplicáveis para uma operação
Os requisitos de recurso definidos na relação de operação determinam o número de recursos aplicáveis para uma operação. O requisito pode ser para um recurso específico ou pode ser baseado na associação do recurso em um grupo de recursos ou funcionalidade.
Se você não usar a capacidade finita para agendamento e todos os recursos aplicáveis tiverem o mesmo calendário e eficiência, o mecanismo de agendamento sempre escolherá o mesmo recurso para uma operação, mas somente depois de tentar todos os recursos aplicáveis para verificar se há um que seja melhor do que os outros. Nesse caso, você pode reduzir muito a carga do agendamento sempre atribuindo um recurso específico à operação no momento do design da rota.
Roteiro com operações paralelas
Embora as operações paralelas (primária/secundária) sejam uma ferramenta poderosa para modelar cenários como quando um computador e um operador são necessários para executar uma tarefa específica, elas também são a fonte de muitos problemas de desempenho. Se você atribuir um requisito para um recurso individual específico à operação primária e secundária, normalmente não será um problema. Mas se houver vários recursos possíveis para cada uma das operações, isso adicionará uma complexidade computacional significativa ao agendamento.
Uma alternativa ao uso de operações paralelas é modelar os pares como recursos "virtuais" (que representam a equipe que sempre se reúne para a operação) ou simplesmente não modelar uma das operações se ela não representar um gargalo.
Rota com quantidade de recursos maior que um
Se a quantidade de recursos necessários para uma operação for maior que uma, o resultado será efetivamente o mesmo que usar operações primárias/secundárias porque vários trabalhos paralelos são enviados para o mecanismo. No entanto, para esse caso, você não pode usar atribuições de recurso específicas porque uma quantidade maior que uma requer que mais de um recurso seja aplicável à operação.
Uma operação secundária que tem uma quantidade de carga de recursos maior que um indica que a quantidade especificada de recursos secundários é necessária para cada recurso da operação principal. Por exemplo, se uma operação primária tiver sua quantidade de recursos definida como dois e sua operação secundária tiver sua quantidade de recursos definida como três, será necessário um total de seis recursos para a operação secundária.
Uso excessivo de capacidade finita
O uso da capacidade finita requer que o mecanismo carregue informações de capacidade de um banco de dados, o que pode adicionar sobrecarga computacional, especialmente em ambientes em que os recursos são reservados perto da capacidade máxima. Como resultado, é importante avaliar cuidadosamente se um recurso realmente precisa usar a capacidade finita ou se ele pode ser sobrebookado. Porque pode haver uma diferença entre os recursos de capacidade finita no quão importantes eles são para evitar overbooking, use a opção de gargalo em um recurso em combinação com um valor separado no plano em "Limite de tempo de capacidade para recursos de gargalo". O uso do conceito de gargalo pode permitir a redução do limite geral de tempo de capacidade finita.
Configurar links rígidos
O tipo de link padrão da rota é flexível, o que permite um intervalo de tempo entre a hora de término de uma operação e o início da próxima. Se você permitir essa lacuna, ela poderá fazer com que a produção fique ociosa se os materiais ou a capacidade não estiverem disponíveis para uma das operações. Essa situação pode levar a um aumento no trabalho em andamento. Esse problema não ocorre com links rígidos porque o término e o início devem se alinhar perfeitamente. No entanto, a configuração de links rígidos dificulta o problema de agendamento porque o sistema deve calcular interseções de tempo de trabalho e capacidade para os dois recursos das operações. Se o agendamento também envolver operações paralelas, esse requisito adicionará um tempo computacional significativo. Se os recursos das duas operações tiverem calendários diferentes que não se sobrepõem, o problema não poderá ser resolvido.
Use links rígidos somente quando estritamente necessário e avalie cuidadosamente a necessidade de cada operação no caminho.
Para reduzir o processo em andamento sem aplicar links rígidos, agende a ordem duas vezes, com mudança para a direção oposta na segunda passagem. Se o primeiro agendamento tiver sido feito anteriormente da data de entrega, o segundo agendamento deverá ser feito de acordo com a data de início agendada. Essa abordagem compacta os trabalhos o máximo possível para que o trabalho em andamento seja minimizado.
Calendário separado para cada recurso
Uma das principais fontes de dados do mecanismo de agendamento são as informações de calendário, que podem ser caras para carregar do banco de dados. Como os calendários são gerados com base em modelos, pode parecer tentador gerar um calendário para cada recurso e ajustar as informações neste calendário quando o recurso tiver tempo de inatividade e outros problemas. No entanto, essa abordagem limita severamente a capacidade do mecanismo de armazenar em cache os dados do calendário porque ele precisa solicitar novos dados para cada recurso. Essa abordagem pode causar problemas de desempenho. Reutilize calendários o máximo possível entre recursos e controle as alterações de tempo de inatividade atribuindo uma ID de calendário diferente por um período.
Alto número de slots de horário de trabalho por dia do calendário
Como o mecanismo funciona examinando os slots de tempo um a um para capacidade, é benéfico minimizar o número de slots de tempo por dia no calendário. Por exemplo, considere se é importante que o agendamento resultante reflita que os trabalhadores realizem uma pausa de cinco minutos a cada hora.
Tempos limite de agendamento longos (ou nenhum)
Você pode otimizar o desempenho do mecanismo de agendamento usando parâmetros encontrados na página de parâmetros de agendamento . Sempre defina o tempo limite de agendamento habilitado e as configurações habilitadas para tempo limite de otimização de agendamento como Sim. Se você defini-los como Não, o agendamento pode continuar indefinidamente caso uma rota inviável com várias opções seja criada.
O valor para Tempo máximo de agendamento por sequência controla o número de segundos que podem, no máximo, ser gastos na tentativa de encontrar uma solução para uma única sequência (na maioria dos casos, uma sequência corresponde a uma única ordem). O valor a ser usado aqui depende muito da complexidade da rota e das 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 usados para encontrar uma solução melhor do que aquela encontrada inicialmente. Esse valor influencia apenas as rotas que usam operações paralelas, pois essas operações tornam necessário testar combinações diferentes.
Note
Os valores definidos para os tempos limite se aplicam ao agendamento de pedidos de produção liberados e aos pedidos planejados como parte do MRP. Como resultado, a definição de valores muito altos pode aumentar significativamente o tempo de execução do MRP ao executar um plano com muitos pedidos de produção planejados.
Erros comuns de agendamento de trabalho
A tabela a seguir lista erros conhecidos de agendamento de trabalho com links para informações que podem ajudá-lo a resolvê-los.
| Mensagem de erro | Resolução |
|---|---|
| A ordem de produção planejada deve ser agendada antes de ser confirmada | A ordem de produção planejada deve ser agendada antes de ser firmada |
| O agendamento de produção não considera as margens de segurança | O agendamento de produção não considera as margens de segurança |
| O planejamento principal está programando mais do que a capacidade disponível | O plano mestre está programando mais do que a capacidade disponível |
| Não foi possível encontrar capacidade suficiente |
Não foi possível encontrar capacidade suficiente Corrigir o erro do mecanismo de agendamento "Não foi possível encontrar capacidade suficiente" |
| O valor do atraso não é atualizado quando você reagenda uma ordem planejada | O valor do atraso não é atualizado quando você reagenda uma ordem planejada |