AGV simulation af ruteoptimering (AnyLogic)

I denne artikel præsenterer jeg en simpel AGV- simuleringsmodel . Det er ment som et eksempel på, hvordan man simulerer del routings på en fabrik. Jeg implementerede simuleringen i AnyLogic.

Jeg har allerede givet nogle andre grundlæggende introduktioner til AnyLogic. Mere specifikt har jeg f.eks. tidligere introduceret nogle grundlæggende transportbåndsmodeller i en serie af YT-videoer. Her er en liste over nogle grundlæggende introduktioner til AnyLogic simuleringsmodellering:

Jeg illustrerede et konceptuelt layout af AGV-simuleringen i figuren længere nede i næste afsnit.

Brug af AnyLogic til AGV-simulering med routings

I tidligere indlæg på denne blog har jeg allerede introduceret forskellige muligheder for simuleringssoftware til diskrete begivenheder. Jeg lister nogle eksempler nedenfor. Det er klart, at jeg er fan af gratis og åbne simuleringsværktøjer og rammer (se f.eks. “simmer”). AnyLogic er dog et kommercielt værktøj.

Gennem forskellige simuleringsprojekter har jeg arbejdet med forskellige simuleringsværktøjer til diskrete hændelser , ikke kun dem, der er nævnt ovenfor. For AGV-simuleringer, der er indlejret i materialeflowstudier, finder jeg dog, at AnyLogic og Simio er blandt de bedste simuleringsværktøjer til diskrete hændelser . Jeg har også set mulighederne for FlexSim og Plant Simulation med hensyn til AGV-simulering, og du kunne også disse. Men med hensyn til at kunne tilpasse foretrækker jeg AnyLogic. Primært på grund af dens struktur, dokumentation og gennemsigtighed – og det faktum, at AnyLogic er kodet i JAVA.

Simuleringsundersøgelser kræver en proceduremodel

En almindelig fejl, som jeg ofte observerer, når forsyningskædeanalytikere begynder at simulere, er, at de springer direkte til modellering. En god simuleringsmodel kan dog først udvikles, når målet med simuleringsstudiet er klart defineret. Desuden er dette normalt kun muligt, når det underliggende system eller problem er blevet fuldt ud forstået af alle involverede parter. Jeg anbefaler at bruge en proceduremodel til enhver simuleringsundersøgelse. Nedenstående figur illustrerer min proceduremodel.

Diskret-hændelse simuleringsprocedure model for AGV simulering.

Faktisk er proceduremodellen anvendt af mig blevet offentliggjort på denne blog i tidligere indlæg. Her er to relevante relaterede artikler:

I de tidlige stadier af simuleringsstudiet er det derfor vigtigt at forstå situationen fuldt ud. Passende udtryk for dette trin er f.eks. situationsanalyse, gapanalyse og problemdefinition. Dataindsamling er en del af dette trin. Bagefter definerer jeg som regel eksplicit, hvad der er og ikke er en del af den simuleringsmodel, der skal udvikles. For eksempel simulerede jeg engang en sporvognsdrift og sporvognsplaner i Zürich (Schweiz). I det projekt besluttede jeg, at fodgængerstrømmen, der blokerer sporvognsskinnerne, ikke vil blive implementeret i detaljer. I stedet beskrev jeg jernbaneblokeringsfrekvens og varighed med en tilfældig fordelingskurve.

Til sidst fortsætter simulationsstudiet med at udvikle et layout og en konceptuel model. Konceptuel modellering involverer fx flowdiagram samt definition af tilstandsovergangsdiagrammer for relevant udstyr. Dette gør den faktiske implementering af simuleringsmodellering meget lettere og sikrer en velstruktureret kode.

Jeg skitserede et simpelt layout af AGV-simuleringen

Afhængigt af det projekt, jeg arbejder på, vil jeg normalt selv tegne et groft layout. Alternativt vil jeg stole på en AutoCAD-tegning (eller lignende) leveret til mig af kundens ingeniørteam.

Enkelt layoutudkast til AGV-simuleringsmodel.

Ovenstående figur viser et centralt modtageområde, der videresender modtaget inputmateriale via rullebaner. Kraner eller robotter placerer dele på AGV’er for enden af ​​transportøren.

AGV’erne letter materialestrømmen fra den første modtagelse

AGV’erne, der repræsenterer kernen i denne AGV-simulering i AnyLogic, dirigerer dele til arbejdsområder. Denne routingproces kan kræve beslutningstagning, muligvis på et meget komplekst niveau.

For eksempel vil jeg måske tildele den nærmeste AGV til opgaven, eller den AGV med den laveste udnyttelse. Jeg kan også stå over for en situation, hvor jeg ønsker at modellere den faktiske rutebeslutning. Det vil sige, at en AGV tager rute A, og en anden AGV tager rute B gennem AGV-banenettet.

Implementering af AGV-simuleringen i AnyLogic

Jeg implementerede denne AGV-simulering i AnyLogic. Et skærmbillede af modellen kan ses nedenfor.

AGV-simuleringsmodel i AnyLogic.

Grundlæggende består modellen af ​​en kilde, der genererer delankomster. Disse delankomster sendes videre til transportøren. Når delene ankommer til den definerede endeposition af transportøren, frigives en transportopgave. Faktisk er denne opgaveafsendelsesproces en standard AnyLogic-proces. Jeg kunne dog have implementeret en brugerdefineret opgaveafsendelseslogik ved hjælp af JAVA.

Når en af ​​AGV’erne er blevet tildelt til transporten, ved hjælp af standard AnyLogic-logik som beskrevet ovenfor, beslutter modellen, hvilket arbejdsområde delen skal transporteres til. Til dette implementerede jeg en brugerdefineret, men simpel beslutningslogik til demonstrationsformål. Jeg beskriver denne tilpassede logik i det følgende kapitel nedenfor.

Da dette er et simpelt eksempel, implementerede jeg ikke arbejdsområderne i detaljer. Desuden implementerede jeg heller ikke i nogen detaljer pick and place-betjeningen af ​​en robot eller kran ved transportørens udgang. Med henvisning til min proceduremodel, er dette helt fint. Jeg har “lov” til at implementere disse procestrin på et højere abstraktionsniveau, så længe studiemålet og problemdefinitionen ikke indikerer, at jeg skal implementere disse procestrin i specificeret detaljer. Pick and place-operationen kan f.eks. modelleres med en tidsforsinkelse. Denne tidsforsinkelse kan fordeles tilfældigt, hvis det er relevant for det valgte materialehåndteringsudstyr.

Faktisk er en anden abstraktion, at jeg ikke visualiserede arbejdsområderne og ikke implementerede noget tilpasset objekt til at repræsentere dem. I stedet brugte jeg simpelthen et standardknudeobjekt fra AnyLogic. Den aktuelt aktive målknude, dvs. det aktuelt relevante arbejdsområde, refereres af stationsvariablen . Denne variabel opdateres af en brugerdefineret routingalgoritme. Det vil jeg forklare længere nede i denne artikel.

AGV simulering arbejdsområder referencer efter station i form af AnyLogic noder

Når delene er ankommet til arbejdsområdet, opholder delen sig i arbejdsområdet i en specificeret standardtid. Til sidst kommer delen ind i vasken. Vasken sletter delen og fjerner den derved fra modellen.

Implementering af tilpasset routingbeslutning med JAVA

Når jeg implementerer AGV-simuleringer, er en ting, som jeg gerne vil påvirke, routingbeslutningerne. Det er klart, fordi routings letter enhver materialestrøm. Hvis jeg i dette tilfælde antager, at hver del, der kommer fra modtagelse, repræsenterer det samme inputmateriale, f.eks. rådele til fræsning eller anden forarbejdning, kan jeg ikke bare rute baseret på materialetypen. Jeg vil måske i stedet for rute baseret på arbejdscenterudnyttelse eller andre kriterier. Pointen er, at routingbeslutning skal være let at tilpasse. Jeg skrev dette blogindlæg for at give et simpelt eksempel på, hvordan man kunne gøre dette i AnyLogic.

I denne simple AGV- simuleringsmodel letter jeg brugerdefineret routing med 4 variabler og 1 funktion:

  • output_01 til output_03 måler det samlede antal dele leveret til det respektive arbejdsområde
  • station refererer til delens destinationsarbejdsområde (AnyLogic nodeobjekt)
  • set_route er en funktion, der letter skræddersyet, tilpasset routingbeslutning

Nedenstående skærmbillede viser indholdet af set_route- funktionen.

Brugerdefineret routinglogik implementeret i AGV-simulering i AnyLogic

Set_route -funktionen implementerer simpelthen cyklisk routing. Det vil sige, at den første del går til station_a , den anden del går til station_b , og så videre. Jeg kunne dog specificere yderligere funktioner og variabler og andre typer beslutningstagning, hvis det var nødvendigt. I sidste ende afhænger logikken at implementere af den specifikke situation.

Set_route  funktionen kaldes, når en agent går ind i moveTo_a -blokken i den nedenstående kæde af logiske blokke.

Logiske blokke til at kalde brugerdefineret routing i AGV-simulering

Denne kæde af logiske blokke implementerer følgende flow:

  • src genererer dele med tilfældigt fordelte intervaltider
  • convey transporterer delen fra start- til slutpositionen af ​​conveyor-markeringen
  • get_transport anmoder en AGV om at hente delen fra transportørens udgang
  • moveTo_a kalder set_route og transporterer en del til nodereferencerne i station
  • forsinkelse får delen til at opholde sig i knudepunktet (repræsenterer arbejdsområdet) i nogen tid
  • vask fjerner delen fra modellen

Jeg kan angive funktionskaldet i OnEnter-sektionen i moveTo_a-blokken. Se skærmbilledet nedenfor.

flytte blokering af opkald routing logik

Konklusion og relateret indhold

I dette simple AGV-simuleringseksempel demonstrerede jeg, hvordan du kan gå om at tilpasse del routings i AnyLogic. Routingkriterierne og routinglogikken brugt i dette eksempel var meget enkle. En rigtig routingalgoritme ville ofte være mere sofistikeret og skræddersyet til kravene fra den fabrik, den opererer i. Sådanne routingalgoritmer bliver hurtigt komplekse og kan være udfordrende.

Igennem denne artikel har jeg allerede givet en bred vifte af links til relateret indhold. Ikke desto mindre er her nogle yderligere artikler, som jeg gerne vil dele med den interesserede læser:

You May Also Like

Leave a Reply

Leave a Reply

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *

This site uses Akismet to reduce spam. Learn how your comment data is processed.