Wat is OTAP?

OTAP (Ontwikkeling, Test, Acceptatie en Productie) is een werkwijze waarbij software- en configuratiewijzigingen vier gescheiden omgevingen doorlopen, zodat elke wijziging getest en formeel goedgekeurd is voordat zij het productieproces raakt. Binnen industriële automatisering gebruikt u OTAP voor wijzigingen in bijvoorbeeld SCADA-systemen, PLC-software, HMI-schermen of Historian-configuraties. Internationaal heet hetzelfde model DTAP (Development, Test, Acceptance, Production). Het verschil met kantoor-IT: in OT betekent een fout niet alleen een storing, maar mogelijk stilstand, productverlies of een veiligheidsrisico.

Het doel van OTAP is om wijzigingen eerst te verifiëren en valideren voordat ze impact hebben op de productieomgeving, om zo risico’s op fouten en downtime te minimaliseren.


🧠 Wat gebeurt er in elke OTAP-fase?

Elke fase heeft een eigen omgeving, eigen rechten en eigen documentatie-eisen. Een wijziging gaat pas door naar de volgende fase als het uitgangscriterium van de huidige fase is gehaald.

Fase Doel Wie Typische OT-invulling Uitgangscriterium
Ontwikkeling (O) Ontwerpen en programmeren Engineer, systeemintegrator Engineeringsoftware met PLC-simulator op een engineering station Code compileert, review gedaan, versie vastgelegd
Test (T) Technisch testen Engineer, tester Simulatie van IO, testbank met losse besturing, virtuele SCADA-server Logica, alarmen en interlocks werken in simulatie
Acceptatie (A) Functioneel goedkeuren Eindgebruiker, operator, procestechnoloog Omgeving gelijk aan productie, of FAT bij de leverancier Formeel akkoord volgens testplan en change management
Productie (P) Operationeel gebruik Operations, beheer Live installatie op het OT-netwerk Succesvolle uitrol, SAT en nazorg afgerond

De klassieke activiteiten per fase blijven daarbij:

  1. Ontwikkeling - ontwerpen en programmeren van software, scripts of configuraties in een afgeschermde omgeving, met versiebeheer (bijvoorbeeld Git).
  2. Test - technische testen van syntax en logica, IO-simulaties en waar nodig hardware-in-the-loop, waarbij echte besturingshardware tegen een gesimuleerd proces draait.
  3. Acceptatie - functionele tests door eindgebruikers of engineers, validatie tegen specificaties en normen, vaak inclusief goedkeuring via change management.
  4. Productie - definitieve uitrol, monitoring en logging tijdens de eerste productiecyclus en een vooraf getest rollbackplan.

🎯 Waarom is OTAP in OT lastiger dan in IT?

In IT is een extra testserver goedkoop. In OT kunt u een reactor, een verpakkingslijn of een rioolgemaal niet kopiëren. Daardoor ziet een OTAP-straat in een fabriek er anders uit dan in een datacenter:

  • Het proces is niet te dupliceren - de testomgeving bevat de besturing en software, maar het fysieke proces wordt gesimuleerd.
  • Hardware is duur en merkgebonden - een identieke DCS-controller of veiligheids-PLC voor de acceptatieomgeving kan evenveel kosten als het productiesysteem zelf.
  • Lange levensduur - installaties draaien 15 tot 25 jaar; de testomgeving moet dezelfde firmware- en softwareversies blijven volgen.
  • Realtime gedrag - timing, scantijden en netwerkbelasting gedragen zich in simulatie anders dan op de vloer.
  • Onderhoudsvensters - uitrol naar productie kan vaak alleen tijdens een geplande stop.

Daarom combineert OT vaak virtuele en fysieke middelen. PLC-simulators zoals Siemens S7-PLCSIM in TIA Portal of een TwinCAT-runtime op een gewone pc vullen de testfase. Virtuele inbedrijfstelling met een digital twin van de machine laat u besturingslogica testen tegen een procesmodel, nog voordat de hardware bestaat. Met virtualisatie zijn SCADA-, historian- en MES-servers eenvoudig te klonen voor test en acceptatie.


🏭 Hoe ziet een OTAP-straat eruit in een fabriek?

Component Ontwikkeling Test Acceptatie Productie
PLC-software Simulator op engineering station Testbank-PLC of simulator met IO-model Identieke hardware of FAT-paneel Live PLC
SCADA / HMI Lokale ontwikkelinstantie Virtuele testserver Kopie van productieconfiguratie Redundante productieservers
Historian Lege ontwikkeldatabase Testdatabase met gesimuleerde tags Geanonimiseerde of geselecteerde productiedata Productiehistorian
Netwerk / Firewall Geen koppeling met productie Eigen testsegment Gelijke regels als productie Productiezones en conduits

Typische wijzigingen die deze straat doorlopen zijn PLC-programma’s, SCADA-schermen en scripts, nieuwe alarmlogica volgens alarmmanagement, receptenbeheer in ISA-88-batchomgevingen, rapportages en firmware- en netwerkconfiguraties. Ook updates van besturingssystemen volgen dezelfde route: patchmanagement in OT betekent dat een patch eerst in test of acceptatie bewijst dat de besturingssoftware blijft werken.


🔄 Hoe verhoudt OTAP zich tot FAT, SAT en validatie?

In projecten valt de acceptatiefase vaak samen met formele testmomenten uit IEC 62381:2024. Die norm beschrijft de Factory Acceptance Test (FAT) bij de leverancier, de in 2024 toegevoegde optionele Factory Integration Test (FIT), de Site Acceptance Test (SAT) op locatie en de Site Integration Test (SIT) met de rest van de installatie. OTAP is daarmee de doorlopende beheerversie van wat in een nieuwbouwproject eenmalig gebeurt.

In de farmaceutische en voedingsindustrie staat de gevalideerde toestand centraal. GAMP 5 (tweede editie, ISPE, juli 2022), de FDA-regel 21 CFR Part 11 en EU GMP Annex 11 schrijven het woord OTAP niet voor, maar eisen wel dat wijzigingen aan geautomatiseerde systemen beheerst, getest en gedocumenteerd worden. Een OTAP-straat is de gebruikelijke manier om dat aan te tonen. Een grondig herziene Annex 11 lag van juli tot oktober 2025 ter consultatie; tot de nieuwe tekst definitief van kracht wordt, geldt de versie uit 2011.


🔍 Wat is het verschil tussen OTAP, DevOps en directe wijzigingen?

Wijzigingsmodel Structuur Risico op fouten Beheersbaarheid Typisch in OT
OTAP (handmatig) Gefaseerd, met formele overdracht Laag Hoog Standaard bij PLC, DCS en SCADA
DevOps / CI/CD Dezelfde fasen, geautomatiseerd via een pipeline Laag bij goede tests Hoog, bij goede inrichting Opkomend bij MES, edge en Docker-applicaties
Directe wijziging Rechtstreeks online in productie Hoog Laag Alleen bij noodingrepen, achteraf vastleggen

DevOps is dus geen alternatief voor OTAP, maar een manier om de overgang tussen de fasen te automatiseren. Online wijzigen in een draaiende PLC blijft in de praktijk voorkomen; een volwassen organisatie legt zo’n noodwijziging achteraf alsnog vast en zet de wijziging terug in de ontwikkelomgeving, zodat de omgevingen niet uit elkaar groeien.


🔐 Welke beveiligingseisen horen bij OTAP?

ISO/IEC 27002:2022 noemt de scheiding van ontwikkel-, test- en productieomgevingen expliciet in maatregel 8.31 (in de editie van 2013 waren dat 12.1.4 en 14.2.6). Via ISO 27001 en de BIO geldt die maatregel ook voor veel Nederlandse organisaties. Maatregel 8.33 vraagt daarnaast om testgegevens te beschermen: productiedata met persoonsgegevens mag niet zomaar naar test, mede vanwege de AVG. NIST SP 800-82 Rev. 3 (september 2023) adviseert in OT om updates eerst in een representatieve testomgeving te beproeven, In het zone-en-conduitmodel van IEC 62443 krijgt de testomgeving doorgaans een eigen zone met gecontroleerde verbindingen.

Concrete maatregelen:

  • Gescheiden toegang - toegangsbeheer en access control per fase; ontwikkelaars hebben standaard geen schrijfrechten op productie.
  • Geautoriseerde uitrol - alleen goedgekeurde, versiebeheerde releases gaan naar productie.
  • Audit en logging - wie wat wanneer heeft gewijzigd, is herleidbaar via audit-trails in acceptatie en productie.
  • Back-up vóór uitrol - een herstelbare kopie van de huidige productieversie, bij voorkeur als immutable backup tegen ransomware.
  • Netwerkscheiding - test- en acceptatieomgevingen fysiek of logisch gescheiden van productie via netwerksegmentatie.
  • Change management - elke wijziging met autorisatie, impactanalyse en rollbackplan.

Een vaak onderschat risico is de testomgeving zelf: die is minder streng beheerd, bevat kopieën van productieprojecten en wordt soms tijdelijk aan zowel kantoor als productie gekoppeld. Zo’n brug ondermijnt de hele segmentatie. Voor organisaties onder de Cyberbeveiligingswet en NIS2 valt beveiliging bij ontwikkeling en onderhoud van systemen bovendien onder de zorgplicht.


🧭 Hoe richt u een OTAP-straat in stap voor stap?

  1. Inventariseer wat verandert - welke systemen (PLC, SCADA, historian, netwerk) krijgen regelmatig wijzigingen? Gebruik uw assetregister als basis.
  2. Bepaal per systeem het aantal omgevingen - niet elk systeem heeft vier fysieke omgevingen nodig; vaak volstaan O en T gecombineerd op een engineering station plus een acceptatieomgeving.
  3. Kies simulatie of hardware - simulatie voor logica, fysieke testbank voor timing, communicatie en firmware.
  4. Houd de omgevingen gelijk - leg firmware-, software- en configuratieversies vast in configuratiebeheer en synchroniseer acceptatie na elke productiewijziging.
  5. Leg overdrachtscriteria vast - testplan, testrapport en akkoord per fase, gekoppeld aan het change-proces.
  6. Plan de uitrol - onderhoudsvenster, back-up, rollbackprocedure en wie aanwezig is bij de eerste productierun.
  7. Evalueer - vergelijk na uitrol het gedrag in productie met de acceptatieresultaten en verbeter testscenario’s.

❓ Veelgestelde vragen

Wat is het verschil tussen OTAP en DTAP?

Er is geen inhoudelijk verschil: OTAP is de Nederlandse afkorting en DTAP de Engelse (Development, Test, Acceptance, Production). Beide beschrijven dezelfde vier gescheiden omgevingen waar een wijziging achtereenvolgens doorheen gaat.

Heeft elke OT-installatie vier aparte OTAP-omgevingen nodig?

Nee, het aantal omgevingen hangt af van risico en kosten. Veel organisaties combineren ontwikkeling en test op een engineering station met simulatie en houden alleen een aparte acceptatieomgeving aan voor kritische systemen.

Hoe test u PLC-software zonder een tweede installatie?

U test PLC-software met een simulator, zoals S7-PLCSIM voor Siemens of een TwinCAT-runtime op een pc, gekoppeld aan een IO- of procesmodel. Voor timing en communicatie vult een testbank met dezelfde hardware de simulatie aan; virtuele inbedrijfstelling met een digital twin gaat nog een stap verder.

Mag ik productiedata gebruiken in de OTAP-testomgeving?

Procesdata zonder persoonsgegevens wordt vaak gebruikt om realistisch te testen, maar wel onder dezelfde beveiliging als productie. Bevat de data persoonsgegevens, zoals operatornamen in audit-trails of batchrecords, dan vragen ISO 27002 maatregel 8.33 en de AVG om maskering of anonimisering.

Is OTAP wettelijk verplicht?

OTAP als term staat in geen enkele wet. Wel eisen ISO 27002, de BIO, GMP Annex 11 en de zorgplicht uit NIS2 dat wijzigingen beheerst en getest worden, en een OTAP-straat is de gangbare manier om dat aan te tonen.

Waar plaatst u de OTAP-testomgeving in het netwerk?

De testomgeving hoort in een eigen netwerkzone, gescheiden van productie en kantoor, met alleen gecontroleerde verbindingen voor het overzetten van goedgekeurde releases. Zo voorkomt u dat een minder streng beheerde testomgeving een brug wordt tussen IT en de productiezones.


📌 Samengevat

OTAP is een gestructureerde methode om wijzigingen veilig en gecontroleerd door te voeren in industriële netwerken, door elke wijziging te laten passeren langs ontwikkeling, test, acceptatie en productie. In OT vraagt dat om slimme combinaties van simulatie, testbanken en FAT/SAT, strikte scheiding van omgevingen en change management, zodat het risico op downtime, fouten en veiligheidsproblemen sterk wordt beperkt.