Forbedre ytelsen til planleggingsmotoren

Ressursplanleggingsmotoren planlegger ruter for planlagte og utgitte produksjonsordrer.

Planlegging av jobbproduksjonsproblem er et ekstremt komplekst kombinasjonsproblem der løsningstiden øker eksponentielt med antallet beslutningvariabler. Kunder konfigurerer ofte produksjonsruter og relaterte data på måter som skaper planleggingsproblemer som ikke kan løses på rimelig tid, selv på moderne maskinvare. Denne artikkelen forklarer planleggingsmotoren og hvordan et bestemt oppsett påvirker ytelsen.

Forbedre planleggingsytelsen ved å redusere kompleksiteten i problemet motoren løser. Noen av hovedfaktorene som kan påvirke ytelsen omfatter:

• Ruter med mange operasjoner
• Ruter med parallelle operasjoner
• Operasjoner med mer enn én ressurs
• Operasjoner med mange gjeldende ressurser
• Bruk av harde koblinger
• Bruk av begrenset kapasitet
• Antall ulike kalendere som brukes
• Antall arbeidstidsluker per dag i kalenderen
• Samlet varighet for ruten
• Kjøre flere planleggingsmotorer parallelt

Oversikt over grunnleggende planleggingsflyt

Hvis du vil forstå hvordan et gitt oppsett påvirker ytelsen, må du vite hvordan prosessen flyter inne i motoren og i X++-koden som omgir den.

Den grunnleggende prosessen med planlegging av en ordre består av tre hovedtrinn:

• Laster inn data – X++-datamodeller transformeres til motorens interne datamodell som jobber og begrensninger.
• Planlegging – Motoren behandler den angitte modellen og betingelsene for å generere et resultat. Den ber om arbeidstidsinformasjon og eksisterende kapasitetsreservasjoner fra X++ etter behov.
• Lagre data – X++-kode behandler motorresultatet, i form av plass for reservasjon av jobbkapasitet, for å lagre kapasitetsreservasjoner og oppdatere start- og sluttidspunktene for jobbene, operasjonen eller bestillingen.

Laste inn data i motoren

Planleggingsmotoren bruker en mer abstrakt datamodell enn den administrasjon av forsyningskjede databasen fordi den er en generisk motor som håndterer flere datakilder. Begrepene rute, sekundære operasjoner og kjøretid oversettes til den generiske jobb- og begrensningsmodellen som motoren viser. Logikken for å bygge modellen inkluderer betydelig forretningslogikk og varierer avhengig av kildedataene. Den ansvarlige X++-klassen er WrkCtrScheduler, som inkluderer avledede klasser for planlagte produksjonsordrer, utgitte produksjonsordrer og prosjektprognoser.

Vurder for eksempel en rute som vises i tabellen og bildet nedenfor, noe som er relativt enkelt.

Når du sender denne ruten til motoren, deles ruten inn i åtte jobber, som vist i illustrasjonen nedenfor (velg bildet for å forstørre den).

Standardkoblingen mellom to jobber er FinishStart, noe som betyr at sluttidspunktet for én jobb må skje før starttidspunktet for en annen. Oppsettet må gjøres av den samme ressursen som senere håndterer prosessen, så det er OnSameResource begrensninger mellom dem. Mellom jobbene for den primære og sekundære operasjonen for 10, er StartStart det og FinishFinish koblinger, noe som betyr at jobbene må både starte og slutte samtidig. I tillegg finnes NotOnSameResource det begrensninger som hindrer at den samme ressursen brukes for både primære og sekundære operasjoner.

For operasjon 20, der antallet ressurser er satt til 3, deles prosessjobben inn i tre forskjellige jobber der alle jobbene må kjøres på nøyaktig samme tid. I dette tilfellet er rutegruppen konfigurert til ikke å reservere kapasitet for kø etter klokkeslett, og derfor er det bare én enkelt jobb for køen etter.

Planleggingsmotoren forstår bare konseptene for jobber og gjenkjenner ikke operasjoner. Denne begrensningen betyr at systemet deler operasjoner i jobber under operasjonsplanlegging, selv om disse jobbene ikke beholdes i databasen.

For hver jobb definerer du hva jobbkapasitetskravet er (antall sekunder som kreves). Avhengig av hvordan ressurskravene er definert, kan du også sende, for hver jobb, en liste over alle potensielle gjeldende ressurser som jobben kan kjøre på, og hva kapasitetskravet er for den bestemte ressursen. Selv om du sender listen over gjeldende ressurser når du bygger modellen, sikrer motoren at ressurstildelingen forblir gyldig for hele jobbvarigheten.

Internt i planleggingsmotorer

Grensesnitt for planleggingsmotorer

Hvis du vil forstå hvordan motoren fungerer internt, kan du se gjennom funksjonaliteten den viser eksternt. I X++ er hovedgrensesnittet WrkCtrSchedulerEngineInterface. Det inneholder metodene som er beskrevet i underdelene nedenfor.

Generell motor

Enkeltjobber

Begrensninger mellom jobber

Problemløser

Motoren er en spesialisert begrensningsløser med egendefinert heuristikk. Problemløseren er basert på to hovedelementer: variabler og begrensninger.

Variabel

En variabel representerer et domene med mulige verdier. Planleggingsmotoren har to typer variabler:

• DateTime-variabel – har et domene for alle datoer og klokkeslett. Du kan begrense domenet ved å flytte nedre og øvre grense for tidspunktet for variabelen nærmere hverandre.
• Ressursvariabel – har et domene med gjeldende ressurser. Du kan begrense domenet ved å fjerne ressurser fra listen.

Begrensning

En begrensning fungerer på variabler ved å begrense domenene. Det avhenger også av variabler, slik at det aktiveres når variabler endres. Prosessen for overføring av betingelser er når en begrensning utfører sin hovedfunksjon og rapporterer tilbake til hovedlogikken hvis vellykket.

En variabel anses som bundet når den ikke kan begrenses ytterligere. For en DateTime-variabel betyr denne betingelsen at øvre og nedre grense er den samme. For ressursvariabelen betyr det at den bare har én enkelt gjeldende ressurs. Når alle variabler er bundet, blir det funnet en løsning.

Betingelsesnivåer

Når planlegging er en del av dekningsfasen for materialkravplanlegging (MRP), planlegger systemet ordrer bakover fra kravdatoen. Hvis systemet imidlertid ikke finner en tidsplan som starter i dag eller senere og slutter før kravdatoen, endrer det planleggingsretningen til fremover fra i dag.

Systemet organiserer begrensningene i nivåer for å håndtere denne hovedregelen for virksomheten. Hvis systemet ikke finner en løsning når du bruker betingelsene på høyeste nivå, faller det alle begrensningene på dette nivået og prøver det lavere nivået. I praksis betyr denne prosessen at modellen for bakoverplanlegging inneholder et nivå 1 med jobbmål for siste starttidspunkt gitt en maksimal sluttidsbetingelse (kravdatoen) og et nivå 0 med jobbmål for tidligste sluttidspunkt og gitt en minimum starttidsbegrensning i dag.

Algoritme

Hovedtrinnene i motorens algoritme er:

1. Finn sekvenser (jobbkjeder) som kan løses separat.
2. Prøv å finne en innledende løsning for sekvensen på høyeste begrensningsnivå.
   1. Sorter jobbene i sekvensen basert på jobbmål og prioriteringer, slik at systemet kan finne en startjobb.
   2. Gå gjennom jobbene i følgende sekvens:
      1. Finn alle begrensninger som må overføres, og kjør overføring.
      2. Hvis alle variabler for jobben er bundet, blir det funnet en løsning for denne jobben.
      3. Hvis en av variablene ikke kan bindes uten å bryte betingelsene, kan du rulle tilbake variabelbindingen, prøve en annen verdi i domenet (for ressursvariabel) og kjøre begrensningsoverføringen på nytt.
3. Hvis ingen løsning blir funnet, fjerner du alle begrensninger på gjeldende betingelsesnivå, senker betingelsesnivået (hvis noen lavere nivåer er tilgjengelige), og prøver løsningssøk på nytt med det nye settet med begrensninger.
4. Hvis en mulig løsning blir funnet, starter du optimaliseringsfasen, som prøver å finne en bedre løsning til tidsavbruddet for optimalisering er nådd eller alle ressurskombinasjoner er oppbrukt.

Begrensningsløseren tar ikke hensyn til detaljene i planleggingsalgoritmen. Den "magiske" skjer i definisjonen og kombinasjonen av de ulike begrensningene.

Bestemme arbeidstider

En stor del av (interne) begrensningene i motoren styrer arbeidstiden og kapasiteten til en ressurs. I hovedsak er aktiviteten å krysse arbeidstidslukene for en ressurs fra et gitt punkt i en gitt retning, og finne et langt nok intervall der jobbens nødvendige kapasitet (tid) kan passe.

For å gjøre dette må motoren kjenne til arbeidstiden til en ressurs. I motsetning til hovedmodelldataene er arbeidstiden lat lastet inn, noe som betyr at de lastes inn i motoren etter behov. Årsaken til denne fremgangsmåten er at det ofte er arbeidstid i administrasjon av forsyningskjede for en kalender i en svært lang periode, og vanligvis finnes det mange kalendere, slik at dataene vil være ganske store å forhåndslaste.

Motoren ber om kalenderinformasjon i deler ved å aktivere X++-klassemetoden WrkCtrSchedulingInteropDataProvider.getWorkingTimes. Forespørselen gjelder for en bestemt kalender-ID i et bestemt tidsintervall. Avhengig av statusen til serverens hurtigbuffer i administrasjon av forsyningskjede, kan hver av disse forespørslene ende opp i flere databasekall, noe som tar lang tid (i forhold til bare beregningstiden). Hvis kalenderen inneholder svært omfattende arbeidstidsdefinisjoner med mange arbeidstidsintervaller per dag, legger også denne kompleksiteten til tiden innlastingen tar.

Når planleggingsmotoren laster inn arbeidstidsdataene, beholdes disse dataene i den interne hurtigbufferen for den bestemte kalenderen. Denne oppbevaringen betyr at hvis andre jobber eller ressurser bruker samme kalender, kan de neste oppslagene utføres raskt fra minnet. Én vanlig årsak til dårlig ytelse er hvis en egen kalender-ID brukes for hver ressurs, fordi dataene deretter blir forespurt for hver kalender, selv om innholdet i kalenderne kan være det samme.

Begrenset kapasitet

Når du bruker begrenset kapasitet, deler systemet og reduserer arbeidstidslukene fra kalenderen basert på eksisterende kapasitetsreservasjoner. WrkCtrSchedulingInteropDataProvider Samme klasse henter disse reservasjonene sammen med kalenderne, men den getCapacityReservations bruker metoden. Når du planlegger under hovedplanlegging, vurderer systemet reservasjonene for den spesifikke hovedplanen. Hvis du aktiverer innstillingen på hovedplanleggingsparametersiden , inkluderer systemet også reservasjoner fra faste produksjonsordrer. Når du planlegger en produksjonsordre, kan du på samme måte velge å inkludere reservasjoner fra eksisterende planlagte ordrer, selv om denne sekvensen ikke er like vanlig som omvendt.

Planlegging tar lengre tid når du bruker begrenset kapasitet av flere årsaker:

• Å hente kapasitetsinformasjonen fra databasen er en treg operasjon. Hurtigbufringen på serversiden av kapasitetsinformasjonen er vanligvis ikke så god som for arbeidstid, fordi de ikke deles mellom ressurser som kalendere vanligvis er.
• Antallet arbeidsrelaterte tidsluker som skal gjennomgås øker på grunn av oppdelingene. Systemet må vanligvis undersøke spor i en lengre tidsperiode før det kan finne en løsning.
• Når planleggingen er fullført, må systemet se etter motstridende reservasjoner (se delen «Kjørende planleggingsmotorer parallelt» for mer informasjon).

Undersøke ressurskombinasjonene

Hvis jobbsekvensen bare inneholder standardkoblingene FinishStart , noe som betyr at den danner en enkel kjede uten grener, kan systemet oppnå et optimalt resultat (sett fra den ene rekkefølgen, ikke på tvers av ordrer) ved å finne den beste løsningen for den første jobben og deretter gå videre for å finne den beste løsningen for neste jobb. Den beste løsningen for en jobb er å finne ressursen som kan få fra- og til-datoen for jobben nærmest jobbmålet (i planlegging fremover betyr dette å få sluttdatoen for jobben så tidlig som mulig) samtidig som du respekterer betingelsene.

Når det finnes parallelle jobber, kan det å finne en løsning innebære å undersøke ulike kombinasjoner av ressurser. Antallet mulige ressurskombinasjoner er produktet av antallet gjeldende ressurser for de tilkoblede parallelle jobbene. Spesielt når du planlegger en ordre bakover fra en kravdato, kan det ta litt tid før logikken innser at det ikke finnes noen løsning på problemet som vil få parallelle jobber til å passe før dagens dato. Logikken må kontrollere alle kombinasjonene fordi det kan være noen ressurser som har høyere effektivitet eller en annen kalender som kan gi et resultat. Denne betingelsen betyr at hvis du ikke angir en tidsavbruddsgrense, kjører prosessen i lang tid før du endrer retningen til fremover.

Denne kombinatoriske logikken betyr også at å legge til mer gjeldende ressurser kan få motoren til å kjøre tregere. Hvis det oppstår ytelsesproblemer når du har parallelle operasjoner og planlegging med uendelig kapasitet, kan du delvis løse problemet ved at ruteutformingen tar en beslutning om hvilken ressurs som skal brukes, og deretter tilordner ressursen direkte på operasjonen (fordi motoren i de fleste tilfeller alltid ender opp med å plukke den samme ressursen, slik at sluttresultatet er det samme).

Harde koblinger

Når du angir koblingstypen mellom to jobber til hardt, sikrer du at det ikke er tidsavstand mellom slutten på én jobb og starten på den neste. Denne betingelsen er nyttig i scenarioer der metall varmes opp i én jobb og behandles i den neste, og kjøling mellom jobber er ikke ønskelig.

Hvis ruten danner en enkel kjede uten grener, kan du oppnå et resultat ved å finne en løsning for den første jobben som tilfredsstiller sine egne begrensninger, og deretter gå videre gjennom kjeden som overfører sluttidspunktet fra forrige jobb til neste jobb. Hvis den gjeldende jobben ikke finner noen kapasitet, flytter systemet starttidspunktet lenger ut, uten noen konsekvens for de tidligere jobbene. Denne handlingen skaper potensielt mellomrom mellom jobbene. Men ved å bruke harde koblinger (spesielt i forbindelse med begrenset kapasitet) for det samme scenarioet, betyr det at én jobb senere i kjeden ikke finner kapasitet, at alle tidligere planlagte jobber må «dras» langs én etter én og dermed planlegges på nytt flere ganger. Spesielt i scenarioer med høy belastning for flere ressurser, kan de harde koblingene forårsake en kjedereaksjon der jobbene påvirker hverandre og flere gjentakelser må utføres før resultatet stabiliserer seg til en mulig tidsplan.

Kjøre planleggingsmotorer parallelt

Når du utfører planlegging som en del av et hovedplanleggingsløp der du bruker hjelpere, kan hver av hjelpetrådene for hovedplanlegging også hente planleggingsoppgaver for produksjonsordrer. Denne fremgangsmåten betyr at flere planleggingsmotorer kan kjøre samtidig. Selv om flertrådsfunksjon gir en betydelig ytelsesfordel, introduserer den også noen funksjonelle ulemper for planlegging.

I MRP planlegger systemet alle produksjonsordrer for et gitt stykklistenivå i kravdatosekvens. Denne sekvensen betyr at systemet planlegger disse ordrene med den tidligste kravdatoen først, slik at de har størst sjanse for å få den tilgjengelige ressurskapasiteten. Men når flere motorer velger fra listen over ikke-planlagte ordrer, er sekvensen ikke sikret fordi én motor kan fullføre raskere enn den andre.

Når du planlegger med begrenset kapasitet og flere motorinstanser, kan det oppstå en race condition hvis du forsøker å planlegge ordrer som benytter de samme ressursene samtidig. Feltet Planleggingskonflikter på loggsiden for hovedplaner registrerer antall løpsbetingelser. Konfliktløsningslogikken følger disse trinnene:

1. Planlegg en ordre (uten lås), og hent kapasitetsreservasjoner.
2. Ta låsen.
3. Kontroller om det finnes nyere kapasitetsreservasjoner for de planlagte ressursene i tidsperioden.
   • Hvis nei, skriver du kapasiteten og frigir låsen.
   • Hvis ja, frigir du låsen og planlegger ordren på nytt fra begynnelsen.

Når du planlegger med flere motorforekomster, er ikke resultatet fullstendig deterministisk fordi det avhenger av nøyaktig tidsberegning for hver tråd.

Ytelse for grovplanlegging

Planlegging av operasjoner, også kjent som grov-cut kapasitetsplanlegging, kan være vanskeligere å løse fra et motorsynspunkt hvis begrenset kapasitet brukes fordi mer data er nødvendig for å bestemme muligheten.

Kapasiteten til en ressursgruppe avhenger av hvilke og hvor mange ressurser som er medlemmer av ressursgruppen. En ressursgruppe har ingen kapasitet – bare når ressurser er medlemmer av gruppen, har den kapasitet. Fordi medlemskapet i ressursgrupper kan variere over tid, må kapasiteten evalueres per dag.

I grovplanlegging brukes ressursgruppens kalender til å fastslå start- og sluttidspunktene for hver operasjon. Denne kalenderen setter en grense for hvor mye tid du kan planlegge operasjoner for én operasjon på én dag i én ressursgruppe. I motsetning til kalenderen for bestemte ressurser ignoreres effektivitetsdataene i ressursgruppens kalender fordi den bare angir åpningstider, ikke faktisk kapasitet.

Hvis for eksempel arbeidstiden for en ressursgruppe på én bestemt dato er fra 08:00 til 16:00, kan ikke én operasjon legge mer belastning på ressursgruppen enn det som kan passe inn i 8 timer, uansett hvor mye kapasitet ressursgruppen har tilgjengelig totalt den dagen. Den tilgjengelige kapasiteten kan imidlertid begrense belastningen ytterligere.

Jobbplanleggingens belastning på alle ressurser i ressursgruppen for en gitt dag vurderes ved beregning av den tilgjengelige kapasiteten. For hver dato er beregningen:

Tilgjengelig ressursgruppekapasitet = Kapasitet for ressurser i gruppen basert på kalenderen − Planlagt belastning på ressursene i gruppen − Planlagt belastning av operasjoner på ressursene i gruppen − Planlagt belastning for operasjoner i gruppen − Planlagt belastning for ressursgruppen

På fanen Ressurskrav på ruteoperasjonen kan du angi ressurskravene ved hjelp av enten en bestemt ressurs (i så fall er operasjonen planlagt ved hjelp av denne ressursen), en ressursgruppe, en ressurstype eller én eller flere funksjoner, kompetanse, kurs eller sertifikat. Bruk av alle disse alternativene gir fleksibilitet i ruteutforming, men kompliserer planleggingen for motoren fordi kapasiteten må gjøres rede for per egenskap (et abstrakt navn som brukes i motoren for funksjonalitet, ferdigheter og så videre).

Ressursgruppens kapasitet for en kapasitet er summen av kapasiteten for alle ressursene i ressursgruppen som har den aktuelle funksjonen. Hvis en ressurs i gruppen har en funksjon, vurderer motoren det uansett hvilket kapasitetsnivå som kreves.

I operasjonsplanlegging reduseres den tilgjengelige kapasiteten for en bestemt kapasitet for en ressursgruppe når den lastes inn med en operasjon som krever den aktuelle funksjonen. Hvis operasjonen krever mer enn én funksjon, reduseres kapasiteten for alle nødvendige funksjoner.

For hver dato er den nødvendige beregningen:

Tilgjengelig kapasitet for en funksjon = Kapasitet for funksjonen − Planlagt jobbbelastning på ressursene med den spesifikke funksjonaliteten, inkludert i ressursgruppen − Planlagt belastning på ressursene med den spesifikke funksjonaliteten, inkludert i ressursgruppen − Operasjoner planlagt belastning på selve ressursgruppen som krever den spesifikke funksjonaliteten

Hvis en bestemt ressurs har en belastning, vurderer motoren den ved beregning av ressursgruppens tilgjengelige kapasitet per funksjon fordi belastningen reduserer bidraget til gruppens kapasitet, uavhengig av om belastningen er for den bestemte funksjonen. Hvis det er belastning på ressursgruppenivået, vurderer motoren det i beregningen av ressursgruppens tilgjengelige kapasitet per funksjon bare hvis belastningen er fra en operasjon som krever den spesifikke funksjonen.

Denne logikken gjelder for hver type egenskap, så bruk av operasjonsplanlegging med begrenset kapasitet krever innlasting av en betydelig mengde data.

Forbedre MRP-ytelsen

Følgende tekniske konferansevideo gir tips for å forbedre hovedplanleggingsytelsen når du bruker MRP med den avskrevne hovedplanleggingsmotoren: Hjelp! MRP er treg!

Vis inndata og utdata for planleggingsmotor

Hvis du vil ha spesifikke detaljer om inndata og utdata fra planleggingsprosessen, aktiverer du logging ved å gå til Organisasjonsadministrasjon>Innstillinger>Planlegging>Planleggingssøkekontroll.

Velg Aktiver logging på handlingsruten på denne siden, og kjør deretter planleggingen for produksjonsordren. Når dette er fullført, går du tilbake til siden Cockpit for sporing av planlegging og velger Deaktiver logging i handlingsruten. Oppdater siden, og en ny linje vises i rutenettet. Velg den nye linjen, og velg deretter Last ned i handlingsruten. Denne handlingen gir deg en .zip komprimert mappe som inneholder følgende filer:

• Log.txt – Denne loggfilen beskriver trinnene motoren går gjennom. Den er detaljert og kan være overveldende, men når du eksperimenterer med ruteoppsettet for å løse ytelsesproblemer, kan du se etter tidsforskjellen mellom første og siste linje. Denne forskjellen viser nøyaktig den tiden planleggeren brukte.
• XmlModel.xml – denne filen inneholder modellen som er bygget i X++ og som motoren fungerer på. JobId som er brukt i filen, samsvarer med RecId fra kildetabellen som inneholder jobbene (ReqRouteJob eller ProdRouteJob). I denne filen kontrollerer du at datoene er i ConstraintJobStartsAt og ConstraintJobEndsAt er som forventet, JobGoal egenskapen er riktig angitt, og at jobbene er relatert gjennom JobLink betingelsene.
• XmlSlots.xml – denne filen inneholder alle arbeidstider og kapasitetsreservasjoner som motoren ber om. Kalenderens arbeidstid og reservasjoner er bare forespurt av motoren for tidsperiodene der den prøver å plassere jobbene (og en ekstra buffer), så hvis filen inneholder tider svært langt i fremtiden, kan det være en indikasjon på et problem med oppsettet. Nodene ResourceProperty viser ressursgruppen og funksjonene som er knyttet til hver ressurs, sammen med de relevante tidsperiodene.
• Result.xml – Denne filen inneholder resultatet av planleggingskjøringen.

Sporingsfunksjonaliteten legger til betydelige ytelseskostnader, så bruk den bare til å undersøke planlegging av bestemte ordrer på en kontrollert måte. Hvis du slår den på under en hovedplanleggingskjøring, når den raskt størrelsesgrensen og stopper.

Feilsøke ytelse

Som du kan se fra de forrige inndelingene, kan enkelte fallgruver i oppsettet og bruken av planleggingsmotoren føre til ytelsesproblemer. Følgende sjekkliste kan hjelpe deg med å feilsøke disse problemene. Se på alle punktene fordi det ofte er en kombinasjon av flere faktorer som fører til problemer.

Utføre planlegging som en del av MRP når det ikke er nødvendig

Selv om ruter brukes til produksjonskontrollformål som etterkalkulering og rapportering, trenger de kanskje ikke å vurderes under MRP. I noen tilfeller er det tilstrekkelig å angi standard leveringstid for produksjon for varen for planlegging. Angi kapasitetstidsgjerdet til null for å deaktivere ruteplanlegging. Hvis planlegging er nødvendig, må du nøye angi kapasitetstidsgjerdet fordi ruter kanskje ikke trenger å vurderes for hele omfanget av MRPs dekningstidsgjerde.

Hvis bestillingen ikke er planlagt under MRP, må den i stedet planlegges når den planlagte bestillingen er fast. Dette betyr at autorisasjonsprosessen vil ta lenger tid, og avhengig av hvor mange av de foreslåtte planlagte ordrene som autoriseres, vil ytelsesgevinsten under MRP kanskje gå tapt under autoriseringen.

Rute med unødvendige operasjoner

Når du utformer ruten, unngår du å prøve å modellere den virkelige verden nøyaktig med alle trinnene produksjonsprosessen går gjennom. Selv om denne tilnærmingen kan være nyttig i noen tilfeller, er den ikke bra for ytelsen fordi motorens modell blir større (når det gjelder jobber og begrensninger), og flere SQL-setninger utføres for å sette inn og oppdatere jobber og kapasitetsreservasjoner. Det er også nedstrømseffekten av å måtte rapportere fremdriften etter hvert på jobbene, noe automatiske innlegg kan redusere. Hvis dataene ikke brukes til noe, oppretter det unødvendig belastning.

Opprett bare operasjonene som er strengt nødvendige for planlegging (vanligvis flaskehalsressurser) eller kostnadsformål. Grupper i stedet mange mindre distinkte operasjoner i én større operasjon som representerer en større del av prosessen.

Mange gjeldende ressurser for en operasjon

Ressurskrav som er angitt for operasjonsrelasjonen, bestemmer antall gjeldende ressurser for en operasjon. Kravet kan enten være for en bestemt ressurs, eller det kan være basert på ressursens medlemskap i en ressursgruppe eller kapasitet.

Hvis du ikke bruker begrenset kapasitet til planlegging og alle gjeldende ressurser har samme kalender og effektivitet, velger planleggingsmotoren alltid den samme ressursen for en operasjon, men bare etter at den prøver alle gjeldende ressurser for å kontrollere om det finnes en som er bedre enn de andre. I dette tilfellet kan du redusere belastningen på planleggingen ved å alltid tilordne en bestemt ressurs til operasjonen på utformingstidspunktet for ruten.

Rute med parallelle operasjoner

Parallelle operasjoner (primær/sekundær) er et kraftig verktøy for å modellere scenarier som når en maskin og en operator begge er nødvendige for å utføre en bestemt oppgave, er de også kilden til mange ytelsesproblemer. Hvis du tilordner et krav for en bestemt enkeltressurs til både den primære og sekundære operasjonen, er det vanligvis ikke noe problem. Men hvis det er mange mulige ressurser for hver av operasjonene, legger den til betydelig kompleksitet for grovberegning i planleggingen.

Et alternativ til å bruke parallelle operasjoner er enten å modellere parene som "virtuelle" ressurser (som deretter representerer teamet som alltid går sammen for operasjonen) eller å rett og slett ikke modellere en av operasjonene hvis den ikke representerer en flaskehals.

Rute med antall ressurser høyere enn én

Hvis antallet ressurser som kreves for en operasjon, er større enn én, er resultatet i praksis det samme som å bruke primære/sekundære operasjoner fordi flere parallelle jobber sendes til motoren. I dette tilfellet kan du imidlertid ikke bruke bestemte ressurstildelinger fordi et antall som er høyere enn én, krever at mer enn én ressurs gjelder for operasjonen.

En sekundær operasjon som har et ressursbelastningsantall som er større enn én, betyr at det angitte antallet sekundære ressurser er nødvendig for hver ressurs i den primære operasjonen. Hvis for eksempel en primæroperasjon har ressursmengden satt til to, og den sekundære operasjonen har ressursantallet satt til tre, kreves det totalt seks ressurser for den sekundære operasjonen.

Ubegrenset bruk av begrenset kapasitet

Bruk av begrenset kapasitet krever at motoren laster inn kapasitetsinformasjon fra en database, noe som kan legge til beregningskostnader, spesielt i miljøer der ressurser er bestilt nær maksimal kapasitet. Derfor er det viktig å vurdere nøye om en ressurs virkelig trenger å bruke begrenset kapasitet, eller om de kan overbestilles. Fordi det kan være en forskjell mellom begrensede kapasitetsressurser i hvor viktig de er å ikke overbooke, kan du bruke flaskehalsalternativet på en ressurs i kombinasjon med en egen verdi i planen i Kapasitetstidsgjerde for flaskehalsressurser. Bruk av flaskehalskonseptet kan gjøre det mulig å senke det generelle tidsgjerdet for begrenset kapasitet.

Angi harde koblinger

Standard koblingstype for ruten er myk, noe som gir et tidsgap mellom sluttidspunktet for én operasjon og starten på den neste. Hvis du tillater dette gapet, kan det føre til at produksjonen er inaktiv hvis materialer eller kapasitet ikke er tilgjengelig for en av operasjonene. Denne situasjonen kan føre til en økning i arbeidet som pågår. Dette problemet oppstår ikke med harde koblinger fordi avslutning og start må tilpasses perfekt. Hvis du angir harde koblinger, blir imidlertid planleggingsproblemet vanskeligere fordi systemet må beregne arbeidstid og kapasitetsskjæringspunkt for de to ressursene i operasjonene. Hvis tidsplanen også omfatter parallelle operasjoner, legger dette kravet til betydelig beregningstid. Hvis ressursene for de to operasjonene har forskjellige kalendere som ikke overlapper i det hele tatt, er problemet uløselig.

Bruk harde koblinger bare når det er strengt nødvendig, og vurder nøye om det er nødvendig for hver operasjon av ruten.

Hvis du vil redusere arbeidet som pågår uten å bruke harde koblinger, må du planlegge rekkefølgen to ganger med endring i motsatt retning for det andre passet. Hvis den første tidsplanen ble utført bakover fra leveringsdatoen, bør den andre tidsplanen gjøres fremover fra den planlagte startdatoen. Denne tilnærmingen komprimerer jobbene så mye som mulig, slik at det pågående arbeidet minimeres.

Atskilt kalender for hver ressurs

En av de hoveddatakildene for planleggingsmotoren er kalenderinformasjon, som kan være kostbar å laste inn fra databasen. Fordi kalendere genereres basert på maler, kan det virke fristende å generere en kalender for hver ressurs og deretter justere informasjonen i denne kalenderen når ressursen har nedetid og andre problemer. Denne fremgangsmåten begrenser imidlertid motorens mulighet til å bufre kalenderdataene fordi den må be om nye data for hver ressurs. Denne fremgangsmåten kan forårsake ytelsesproblemer. Bruk kalendere på nytt så mye som mulig mellom ressurser, og kontroller nedetidsendringer ved å tilordne en annen kalender-ID for en periode.

Stort antall spor for arbeidstid per dag kalenderdag

Fordi motoren fungerer ved å undersøke tidsluker én etter én for kapasitet, er det nyttig å minimere antall tidsluker per kalenderdag. Vurder for eksempel om det er viktig for den resulterende tidsplanen å gjenspeile at arbeidere tar en fem minutters pause hver time.

Store (eller ingen) tidsavbrudd for tidsplaner

Du kan optimalisere ytelsen til planleggingsmotoren ved hjelp av parametere som finnes på planleggingsparametersiden . Angi alltid tidsavbruddet for planlegging aktivert , og tidsavbrudd for planlegging av optimalisering aktiverte innstillinger til Ja. Hvis du setter dem til Nei, kan planleggingen potensielt kjøre uendelig hvis det opprettes en umulig rute med mange alternativer.

Verdien for Maksimal planleggingstid per serie kontrollerer styrer maksimalt antall sekunder som kan brukes til å prøve å finne en løsning for én enkelt sekvens (i de fleste tilfeller tilsvarer en serie én enkelt ordre). Verdien som skal brukes her, avhenger av kompleksiteten i ruten og innstillingene som begrenset kapasitet, men maksimalt ca. 30 sekunder er et godt utgangspunkt.

Verdien for Tidsavbrudd for optimaliseringsforsøk styrer hvor mange sekunder som kan brukes til å finne en bedre løsning enn den som opprinnelig ble funnet. Denne verdien påvirker bare ruter som bruker parallelle operasjoner, da disse operasjonene gjør det nødvendig å teste ulike kombinasjoner.

Vanlige jobbplanleggingsfeil

Tabellen nedenfor viser kjente jobbplanleggingsfeil med koblinger til informasjon som kan hjelpe deg med å løse dem.

Relatert informasjon

• Kalendere og hovedplanlegging
• Beregn ønskede forsendelsesdatoer for bestillinger
• Parametere for dato og klokkeslett som brukes av planleggingsoptimalisering
• Sikkerhetsmarginer