WMS vs. WCS: Hvem styrer hvad på et automatiseret lager?
Få et klart overblik over, hvordan lagersystemer, styring og automatiseret udstyr arbejder sammen – og hvilket system der bør eje den enkelte beslutning.
En tydelig ansvarsfordeling mellem WMS, WCS og maskinstyring reducerer integrationsrisikoen, gør testen enklere og hjælper driften med at komme sikkert videre, når noget ikke går som planlagt.
Den enkle forskel på et WMS og et WCS
WMS’et planlægger lagerets opgaver. WCS’et koordinerer i realtid det automatiserede udstyr, der udfører dem.
Styrer lagerdriften på forretningsniveau
WMS-systemet har overblik over lagerbeholdning, ordrer, prioriteter og lageropgaver. Det beslutter normalt, hvad der skal ske, og hvor en vare i sidste ende skal hen.
- Lagertilgængelighed og allokering
- Prioritering af ordrer og plukkebølger
- Plukke- og genopfyldningsopgaver
- Destination efter kunde, butik, transportør eller rute
- Labels, forsendelsesdata og ordreafslutning
Koordinerer bevægelsen gennem det automatiserede anlæg
WCS-systemet arbejder tættere på udstyret. Det følger hver vare, vælger den aktuelle rute og koordinerer scannere, transportbaner, sorteringsanlæg og anden automation.
- Identifikation og sporing af varer i realtid
- Rutevalg på transportbaner og destinationer i sorteringsanlægget
- Logik for fletning, akkumulering og fulde baner
- Resultater fra måling, scanning og enheder
- Undtagelser, alternative ruter og statushændelser
Den præcise grænse varierer fra projekt til projekt. Det afgørende er, at hver vigtig beslutning har én aftalt ejer, før udviklingen begynder.
Sådan hænger ERP, WMS, WCS og maskinstyring sammen
Hvert lag har sin egen opgave. De bedste projekter holder rollerne tydelige og sikrer samtidig, at information flyder stabilt mellem dem.
Forretnings- og virksomhedssystemer
Kunder, produkter, indkøb, fakturering og data på virksomhedsniveau.
Lagerplanlægning
Lagerbeholdning, ordrer, plukkeopgaver, bølger, prioriteter og krav til forsendelser.
Koordinering i realtid
Rutevalg, koordinering af udstyr, sporing, undtagelser og driftsstatus.
Styring af maskiner og enheder
Motorer, sensorer, scannere, udskubbere, transportbanezoner, robotter og maskinsekvenser.
Hvad sker der fra indføring til destination?
En veltilrettelagt integration skal gøre den fysiske rejse let at følge – fra den første ruteinstruktion til den afsluttende bekræftelse.
Scanning, måling og sporing forbinder den fysiske pakke med dens digitale instruktion.
Rute tildelt
WMS’et sender varens identitet og destination til WCS’et. Der kan også medsendes forventet vægt, mål, serviceniveau eller prioritet.
Varen identificeres
WCS’et koordinerer stregkodelæsning, billedregistrering og sporing, så den fysiske vare kobles til den korrekte digitale identitet.
Data kontrolleres
Målt vægt, dimensioner, stregkodens gyldighed og vareprofil kan sammenholdes med forventede værdier og aftalte tolerancer.
Varen dirigeres
WCS’et koordinerer transportbaner, fletninger og destinationer i sorteringsanlægget og reagerer samtidig på banetilgængelighed, blokeringer, fejl og undtagelser.
Resultatet bekræftes
WCS’et rapporterer hændelser som ankommet, aflæst, frasorteret, ingen aflæsning eller uden for tolerance, så WMS’et kan opdatere ordren.
Hvem bør eje den enkelte beslutning?
Tabellen er et praktisk udgangspunkt – ikke en fast regel. Projektspecifikationen bør dokumentere den aftalte ejer af hver vigtig beslutning og undtagelse.
| Beslutning eller funktion | Typisk ansvarlig | Praktisk forklaring |
|---|---|---|
| Ordreprioritet | WMS | Baseres på kunde, serviceniveau, bølge og driftsmæssige krav. |
| Lagerallokering | WMS | Afgør hvilken tilgængelig beholdning der skal opfylde ordren. |
| Endelig forretningsdestination | WMS | Definerer butik, transportør, rute, kunde eller procesdestination. |
| Aktuel rute gennem udstyret | WCS | Vælger den aktuelle rute ud fra udstyrets tilgængelighed og aftalte fallback-regler. |
| Koordinering af scanning og måling | WCS | Koordinerer aktivering af enheder, resultater og koblingen til den rigtige vare. |
| Motor-, sensor- og maskinsekvens | PLC | Udfører den lokale maskinsekvens og styring af enheder. |
| Håndtering af fuld bane | WCS | Aktiverer den aftalte midlertidige rute, buffer eller regel om stop for indføring. |
| Løsning af forretningsmæssige undtagelser | Delt ansvar | Kombinerer normalt WMS-status, operatørens arbejdsgang og WCS’ets fysiske håndtering. |
| Status for udstyrsfejl | WCS / PLC | Oprettes lokalt og rapporteres videre til operatøren og forretningssystemerne. |
| Sikkerhedsfunktioner | Sikkerhedsstyring | Håndteres af det konstruerede sikkerhedssystem – ikke af almindelig routelogik. |
| Historik over driftshændelser | Delt ansvar | WCS’et registrerer udstyrshændelser, mens WMS’et registrerer forretnings- og ordreresultater. |
De fleste integrationsproblemer opstår, før udstyret bliver installeret
Hardwareproblemer er synlige. Problemer med ansvar og data er sværere at opdage – og skaber ofte større forsinkelser.
To systemer ejer begge routingen
Produktdata stemmer ikke overens
Labellogikken besluttes for sent
Undtagelser har ingen ansvarlig
Forretningsregler er gemt i PLC-koden
Adfærd ved afbrudt forbindelse er ikke defineret
Integrationen kan være enkel – men den skal være præcis
Systemerne behøver ikke udveksle alle lagerdata. De har brug for et pålideligt sæt beskeder, som gør det muligt at identificere, dirigere, spore og bekræfte hver vare.
Ruteanmodning
Vare-ID, destination og eventuelt forventet vægt, dimensioner, serviceniveau og prioritet.
Driftshændelse
Vare-ID, hændelsestype, tidsstempel, station, målte data, billedreference eller struktureret fejlkode.
Opslagsanmodning
Bruges når WCS’et identificerer en vare, men endnu ikke kender den nødvendige destination eller forretningsinstruktion.
Heartbeat og status
Bekræfter at forbindelsen og systemerne er tilgængelige og gør kommunikationsbrud hurtigt synlige.
Design interfacet til kontrolleret genetablering
REST API’er kan fungere godt til request-response-flow. Filoverførsel kan stadig være velegnet til klart afgrænsede batchprocesser, og andre arkitekturer kan også være relevante. Det afgørende er en stabil og dokumenteret grænseflade.
- Entydige vareidentiteter
- Definerede tidsstempler og tidszoner
- Idempotent behandling
- Genforsøg og time-outs
- Registrering af dubletter
- Adfærd offline og ved genetablering
- Strukturerede fejlkoder
- Logning og sporbarhed
{
"item_id": "ABC123",
"event_type": "DIVERTED",
"destination": "D23",
"station": "SORTER-02",
"timestamp": "2026-06-20T10:15:27Z",
"measured_weight_g": 740,
"error_code": null
}
Hvad bør normalt ske lokalt i WCS’et?
Hurtige driftsbeslutninger bør ikke afhænge af unødvendige ture frem og tilbage til overordnede forretningssystemer.
Varesporing
Bevar identiteten og positionen for hver vare, mens den bevæger sig gennem det automatiserede flow.
Scanning og måling
Koordinér aktivering af scanner, kamera, vægt og dimensionsmåling, og knyt resultatet til den korrekte vare.
Bevægelse og afstand
Koordinér afstande på transportbanen, rækkefølge ved fletning, akkumulering og lokal routing gennem tilgængelige veje.
Håndtering af fulde baner
Anvend aftalte fallback-regler, når en destination, rute eller efterfølgende proces ikke er tilgængelig.
Koordinering ved stop og genstart
Understøt kontrolleret stop, genetablering og genstart uden at miste varernes sporbarhed.
Status for enheder og system
Overvåg scannere, drev, sensorer, transportbanezoner og automationens tilgængelighed.
Routing af undtagelser
Send uaflæste, overdimensionerede og afvigende varer til deres aftalte fysiske destinationer.
Oprettelse af hændelser
Opret en sporbar hændelseshistorik, og send de vigtige forretningsresultater tilbage til WMS’et.
Et velfungerende system kendes på, hvordan det håndterer de usædvanlige varer
Hver undtagelse skal have en fysisk destination, en systemreaktion og en tydelig operatørhandling. “Send den til fejlsortering” er ikke en komplet proces.
| Undtagelse | Fysisk reaktion | Systemreaktion | Operatørhandling |
|---|---|---|---|
| Stregkode kan ikke læses | Send til en bane for manuel aflæsning eller et separat undtagelsesspor. | Opret en NO_READ-hændelse, og bevar sporingsreferencen. | Identificér, ommærk eller undersøg varen. |
| Vægt uden for tolerance | Send til kontrolvejning eller inspektion. | Opret en WEIGHT_EXCEPTION-hændelse med den målte værdi. | Kontrollér ordren eller produktdataene. |
| Destination ikke tilgængelig | Brug den aftalte buffer, fallback-bane eller et kontrolleret stop. | Rapportér ruteændringen eller den utilgængelige destination. | Frigiv eller genåbn destinationen. |
| Overdimensioneret vare | Brug en særlig undtagelsesrute eller et punkt til manuel håndtering. | Opret en OVERSIZE-hændelse. | Håndtér varen efter den aftalte specialproces. |
| Dubletidentitet | Stop, tilbagehold eller frasortér den berørte vare. | Opret en DUPLICATE-hændelse, og undgå dobbelt afslutning. | Undersøg kilden, og ret dataene. |
| Scanner offline | Brug en aftalt fallback-proces, eller stop indføringen. | Opret en enhedsalarm og en hændelse om systemtilgængelighed. | Genetablér scanneren, og afstem de berørte varer. |
Test ikke kun maskinerne. Test hele driften.
Den afsluttende test skal dokumentere, at udstyr, routing, data, undtagelser og operatørarbejdsgange fungerer sammen under realistiske forhold.
Driftstest
- Vedvarende kapacitet med en defineret varemiks
- Korrekt destination under en repræsentativ bølge
- Standardvarer og vanskelige vareprofiler
- Driftsforhold ved spidsbelastning
- Operatørarbejdsgange og håndtering af undtagelser
- Kontrolleret genetablering efter et stop
System- og datatest
- Aflæsningsgrad for stregkoder ved designhastighed
- Tolerancer for vægt og dimensioner
- Svartid og fuldstændighed for hændelser
- Forebyggelse af dubletter og genforsøg
- Forbindelsesbrud og offline-adfærd
- Genstart, afstemning og korrekthed af hændelser
Udsagn som “systemet kører fint” er ikke acceptkriterier.
Konfigurér hvor det er muligt. Tilpas kun, hvor det skaber tydelig værdi.
Standardkonfiguration er lettere at teste, supportere og ændre. Specialudvikling bør løse et reelt driftsbehov – ikke kompensere for beslutninger, der er truffet for sent.
Standardindstillinger og driftsparametre
- Destinationsnavne og routingtabeller
- Transportbanehastigheder og driftstilstande
- Scannervinduer og enhedsindstillinger
- Tolerancer for vægt og dimensioner
- Brugerroller og rettigheder
- API-endpoints og alarmgrænser
Særlige arbejdsgange med målbar værdi
- Særlig kundespecifik routelogik
- Håndtering af ikke-standardvarer
- Specialtilpassede undtagelsesprocesser
- Særlige rapporteringskrav
- Integration med usædvanlige legacy-systemer
- Særlige operationelle interfaces
Spørgsmål der bør besvares, før udstyret vælges
Når spørgsmålene besvares tidligt, bliver valg af teknologi, leverandøransvar og projektgodkendelse langt tydeligere.
01 Forretningsansvar
- Hvilket system ejer destinationen?
- Hvilket system ejer varernes masterdata?
- Hvor og hvornår oprettes labels?
- Hvem har ansvaret for at løse undtagelser?
02 Interfacedesign
- Hvilke beskeder udveksles?
- Hvilke identifikatorer anvendes?
- Hvor hurtigt skal hændelser returneres?
- Hvad sker der, når et system ikke er tilgængeligt?
03 Ydelse
- Krav til vedvarende kapacitet og spidskapacitet
- Krav til aflæsningsgrad for stregkoder
- Routingnøjagtighed og svartid
- Tolerancer for vægt og dimensioner
04 Lokation og udstyr
- Omfang af udstyr og automation
- Klargøring af strøm, netværk og gulv
- Sikkerhedsinterfaces og operatørstationer
- Manuel fallback og genetableringsproces
05 Test og godkendelse
- Ansvar for FAT og SAT
- Repræsentative testvarer og data
- Målbare acceptkriterier
- Navngivne ansvarlige og endelige godkendere
06 Support og ændringer
- Hvem vedligeholder det enkelte system?
- Hvordan godkendes ændringer i routing?
- Hvilke logs og diagnoseværktøjer er tilgængelige?
- Hvordan tilføjes fremtidigt udstyr?
Ét koordineret projekt på tværs af udstyr, styring og software
Udstyret kan ikke adskilles fra den information, der fortæller det, hvad det skal gøre. Vi udvikler driftsprocessen, styringsansvaret og interfacene som ét sammenhængende projekt.
Forstå driften
Gennemgå processer, systemer, vareprofiler, kapacitet, undtagelser og forretningskrav.
Fastlæg ansvaret
Aftal ansvaret mellem WMS, WCS, PLC, operatører og tredjeparter før udviklingen.
Aftal interfacene
Dokumentér beskeder, identifikatorer, fejl, timing, offline-adfærd og regler for genetablering.
Test hele processen
Test hardware, routing, data, undtagelser og operatørhandlinger som ét samlet driftssystem.
Idriftsæt og supportér
Forbered go-live, overvåg ydelsen, og skab et praktisk fundament for fremtidig udvidelse.
Ofte stillede spørgsmål om WMS og WCS
Har alle automatiserede lagre brug for et WCS?
Ikke altid. En mindre, selvstændig maskine kan styres lokalt. Et WCS bliver mere værdifuldt, når flere anlæg, ruter eller processer skal arbejde sammen og dele sporing, routing og regler for undtagelser.
Kan et WMS styre transportbaner direkte?
Et WMS kan sende overordnede instruktioner, men koordinering i realtid af transportbaner, scannere, sorteringsanlæg og aktuelle ruter håndteres normalt tættere på automationslaget af et WCS og lokal maskinstyring.
Hvad er forskellen på et WCS og en PLC?
Et WCS koordinerer vareidentiteter, ruter og udstyr på tværs af den samlede proces. PLC’er styrer maskinsekvenser, sensorer, motorer, drev og enheder. Det præcise interface afhænger af systemarkitekturen.
Hvor bør routelogikken ligge?
Den forretningsmæssige destination kommer normalt fra WMS’et. WCS’et styrer den fysiske rute i realtid og den aftalte fallback-adfærd, når en rute, bane eller maskine midlertidigt ikke er tilgængelig.
Hvad sker der, hvis forbindelsen til WMS’et afbrydes?
Adfærden skal være defineret før go-live. Afhængigt af driften kan WCS’et færdigbehandle kendte varer, buffere dem, bruge midlertidige regler eller stoppe indføringen kontrolleret. Genetablering og afstemning skal også være fastlagt.
Kan CoreConvey integrere med vores eksisterende WMS?
Ja, når der kan aftales et egnet interface med WMS-leverandøren eller jeres interne IT-team. Projektet bør tydeligt definere beskeder, ansvar, timing, test og supportansvar.
Hvad skal testes før go-live?
Testen bør omfatte kapacitet, stregkodelæsning, routing, tolerancer, undtagelser, levering af hændelser, forbindelsesbrud, genstart, afstemning og operatørarbejdsgange – ikke kun de enkelte maskiners input og output.
Bør vi konfigurere eller specialtilpasse WCS’et?
Konfigurér standardfunktioner, hvor det er praktisk muligt. Brug specialudvikling, hvor det skaber reel driftsmæssig værdi, og sørg for, at hver specialregel er dokumenteret, testet og vedligeholdelsesvenlig.
Fastlæg systemansvaret, før udstyret ankommer
Send CoreConvey en oversigt over automationsomfanget, jeres eksisterende WMS, routingkrav og forventede kapacitet. Vi kan hjælpe med at fastlægge de interfaces, ansvarsområder og acceptkriterier, der er nødvendige for et koordineret projekt.
