Stap 3: Ontwerp maken

Het ontwerp van een meet- en regelsysteem is verdeeld in drie fasen: functioneel ontwerp, dit is een uitwerking van het programma van eisen; voorontwerp, dit is de de vertaling van het functioneel ontwerp naar hard- en software componenten; definitief ontwerp, dit is een nadere detaillering van het voorontwerp. Functioneel ontwerp Het functioneel ontwerp is een nadere uitwerking van het programma van eisen en geeft specifiek aan hoe het systeem moet functioneren. Hierin staan bijvoorbeeld: tabellen met locaties, benamingen en parameters; de validatie regels die worden gebruikt voor de meetgegevens; de alarmparameters; de exacte formules en instellingen van de regelaars.  Het functioneel ontwerp beschrijft onder meer de volgende functionaliteiten van het meet- en regelsysteem: De samenhang en interactie van de verschillende onderdelen van het meet- en regelsysteem. Meestal bestaat zo’n systeem uit een centrale post en enkele lokale posten ook wel onderstations genoemd. Een onderstation kan meerdere sublocaties hebben, zoals een waterstandmeting bovenstrooms en waterstandmeting benedenstrooms. Functies en werking van de centrale bediening en besturing, met de bijbehorende instelpara­meters. Daarbij is onderscheid mogelijk naar de verschillende bedrijfsomstandigheden. Functies en werking van de onderstations. Hierbij is onderscheid in onder meer meet- en regel­locaties, wijze van inzameling en verwerking van data, statussen, storingen, bedienings- en besturingscommando’s, en de besturingswijze van de regelkunstwerken. Afwikkeling van storingen en alarmen, en de verwerking van gegevens en presentatie op de cen­trale post. Het functioneel ontwerp moet alle typen storingen en alarmen (inclusief de bijbehorende parameters) beschrijven. Ook geeft het expliciet aan welke parameters het systeem met welke tijdsintervallen en eenheden moet inlezen en opslaan. Beheer. Welke beheeracties zijn nodig, hoeveel tijd nemen deze in beslag en wie voert ze uit? Noem deze expliciet om te voorkomen dat onderhoud wordt vergeten. Overwegingen vanuit beheer kunnen bepalend zijn voor het voorontwerp en definitief ontwerp. Voorontwerp Het voorontwerp is de vertaling van de functionaliteiten uit het functioneel ontwerp naar benodigde hard- en software. Het voorontwerp identificeert de belangrijkste (en kostenbepalende) eenheden van het besturingssysteem met hun onderlinge relaties. Deze onderdelen zijn vaak: Het meet- en telemetriesysteem. De kunstwerken en de benodigde aanpassingen. De lokale automatisering op de kunstwerken. De centrale automatisering. Verder stelt het voorontwerp het systeemconcept voor de automatisering op. Daarbij spelen onder meer de beschikbaarheidseisen bij calamiteiten een rol. Een risicoanalyse is een goede basis om de zwakke schakels in het meet- en regelsysteem aan te duiden. Het ontwerp of de projectuitvoering is hierop aan te passen. Daarbij kan worden gedacht aan een ontwerp waarbij de basis blijft draaien ook als er onderdelen van het systeem uitvallen, zoals metingen of brandmodules.   Het voorontwerp bevat ook een kostenraming voor de besturingsinstallatie, de elektrotechnische en werktuigbouwkundige installaties en het eventuele civiele werk. Definitief ontwerp Het definitieve ontwerp is een nadere uitwerking van het voorontwerp. Hierbij is vaak onderscheid in civieltechnische aspecten, de elektromechanische onderdelen en de telemetrie. Op basis van het definitieve ontwerp kan de gemeente een eenduidig bestek schrijven.   Het definitieve ontwerp is een uitwerking van: het gekozen systeemconcept; de definitieve bepaling en functionele invulling van de besturingsinstallaties op alle meet- en regellocaties in een besturingsplan; het ontwerp van alle benodigde elektrotechnische en werktuigbouwkundige installaties en eventueel benodigde civieltechnische werken. Overigens is een definitief ontwerp niet altijd nodig, omdat veel systemen of systeemcomponenten op de markt beschikbaar zijn. Afhankelijk van de opzet en mate van detail van het functioneel ont­werp, kan de gemeente het voorontwerp en het definitieve ontwerp integreren. Op basis van de kostenraming van het definitieve ontwerp moet de gemeente (samen met eventueel andere betrok­ken beheerders) een definitief besluit nemen over het wel of niet implementeren van het meet- en regelsysteem, de definitieve ‘go’. Regelaarontwerp Het regelaarontwerp vormt een apart specialistisch onderdeel van het ontwerp. Hoewel steeds meer standaardsoftware beschikbaar is, is het regelaarontwerp voor elk systeem anders. Als de regelaar te weinig is doordacht en uitgewerkt, kunnen problemen ontstaan. Bijvoorbeeld door ‘slordigheids­fouten’ kan de regelaar de schuif open zetten in plaats van dicht. Ook kunnen er problemen ont­staan met de stabiliteit van de regelaar waardoor de kunstwerken te snel en te veel gaan schakelen. Naast de regeling moet het ontwerp aandacht besteden aan zaken als: wat gebeurt bij uitval van het systeem (meetdata komen tijdelijk niet door) of een onderdeel (gemaal is in onderhoud)? Ontstaat dan wateroverlast of een noodlozing? ‘Master slave’-configuratie Voor grotere systemen is een regelhiërarchie gebruikelijk, gebaseerd op een ‘master slave’-configuratie. Daarbij is de master een centrale regelaar die het systeem op hoofdlijnen regelt en bewaakt. De instelling van de centrale regelaar is maatwerk, daarin wordt de beoogde werking van het meet- en regelsysteem geprogrammeerd. De slave is een lokale regelaar, gebaseerd op een feedbackregeling en geprogrammeerd in de lokale PLC nabij het betreffende kunstwerk. De slave reageert direct op de inkomende meetsignalen en krijgt periodiek nieuwe (setpoint)instructies van de master controller. Voor de slave is meestal standaardsoftware (SCADA) te gebruiken. Toetsen in simulatiemodel Toets een regelaarontwerp bij voorkeur in een simulatiemodel. Houd daarbij rekening met het (soms grote) verschil tussen een regelaar in een simulatiemodel en de echte regelaar. In een simulatie­omgeving zijn de omstandigheden gecontroleerd en kan de aandacht alleen uitgaan naar de regel­technische werking. In de praktijk kunnen allerlei storingen en onverwachte omstandigheden het systeem ontregelen. Daarom is de programmacode van de regelaar uit het simulatiemodel een klein onderdeel (20%) van de feitelijke regelaar in de praktijk. Aandachtspunten Enkele simulatieprogramma’s beschikken over een module waarin regelaars zijn te ontwikkelen en te testen. Maar de hiermee ontwikkelde regelaar is niet geschikt om direct over te zetten naar de praktijkomgeving. Diverse randmodules voor datavalidatie, filtering en beperkingen zijn namelijk niet nodig bij een simulatie, maar wel in de praktijk. Let ook op de programmeeromgeving. Een bureaustudie gebruikt vaak Matlab of Visual Basic. Maar deze code is niet altijd voldoende robuust voor praktijkcondities, waarin software jaren achtereen storingsvrij moet draaien. Alternatieven zijn bijvoorbeeld C of Java code.  Figuur A Voorbeeld van een rwa-besturingssysteem, het modelleren van een dergelijk gestuurd systeem is veel complexer dan het modelleren van een ongestuurd systeemVergroot afbeelding