Safety Requirement Specification (SRS)
SRS (Safety Requirement Specification) is een beschrijving van de eisen en de werking die aan een SIF (Safety Instrumented Function) worden gesteld. In dit document staat alle essentiële informatie om de SIF in detail te ontwerpen:
- Doel van de SIF
- Algemene vereisten voor de SIF
- Het benodigde SIL niveau, bepaald uit een HAZOP/LOPA
- De vereiste mode van de SIF (Low Demand <1/jaar, High Demand of Continuous Demand)
- De vereisten voor een handmatige shutdown.
- De benodigde reactietijd van de totale SIF (Sensor – Logic Solver – Final Element), bepaald uit een HAZOP/LOPA studie, vaak in combinatie met een process engineering berekening (Process Safety Tijd (PST)). Bijvoorbeeld hoe snel loopt de druk op in een destillatiekolom als de koelwaterpomp uitvalt. De reactietijd van de SIF moet dus binnen de PST liggen.
- De locatie en functie van de sensors en actuators
- Definitie van de veilige stand van de SIF (b.v. Toevoerklep dicht of Pomp gestopt)
- Redundantie eisen om aan het SIL niveau te voldoen of om de beschikbaarheid te verhogen
- Vereisten voor definiëren van de Common Cause Failures.
- Maintenance override functies (MOS, Maintenance Override Switches) of Operational override functies (OOS, Operational Override Switches) om bijvoorbeeld op te kunnen starten. Deze zijn bij voorkeur automatisch en vallen automatisch af na een (bij voorkeur) korte tijd.
- Lekklasse van kleppen
- Communicatie met andere systemen
- Eventuele voorkeur merken en modellen van de componenten, bijvoorbeeld om gemeenschappelijke reserveonderdelen (common spares) in voorraad te hebben van kritische instrumentatie.
- Vereisten aan de Test Intervallen en de vereiste Test Coverage Factoren (TCF)
- Vereisten gerelateerd aan Energize of De-Energize naar trip
- Vereisten aan resetting na een shutdown (b.v. vereisten voor manual, semi-automatisch, of automatisch resets van het final element na een trip).
SRS
Vanuit het SIL verificatie programma aeShield kan een SRS in verschillende formaten (afhankelijk van de detaillering) worden gegenereerd. Het Formaat D van de aeShield SRS is geheel in overeenkomst met de IEC 61511 ed.2.
Wil je meer weten over Safety Requirement Specification (SRS) en wat pro6com hierin voor jouw plant kan betekenen?
Veelgestelde vragen over Safety Requirement Specification (SRS)
Een SRS zorgt ervoor dat de veiligheidsfunctie die uit een risicoanalyse voortkomt ook correct wordt vertaald naar engineering.
Zonder duidelijke specificatie kunnen verschillende disciplines — zoals process engineering, automatisering en operations — verschillende interpretaties hebben van hoe een veiligheidsfunctie moet werken.
Door de eisen expliciet vast te leggen wordt voorkomen dat:
-
veiligheidsfuncties anders worden geïmplementeerd dan bedoeld
-
belangrijke ontwerpcriteria verloren gaan
-
inconsistenties ontstaan tussen ontwerp en operatie
Een goede SRS zorgt ervoor dat alle betrokken disciplines hetzelfde uitgangspunt hanteren.
Een Safety Requirements Specification wordt opgesteld nadat is vastgesteld dat een veiligheidsfunctie nodig is om een procesrisico te beheersen.
De SRS wordt meestal ontwikkeld tijdens de engineeringfase van een project, voordat de veiligheidsfunctie daadwerkelijk wordt geïmplementeerd in het besturingssysteem.
Dit zorgt ervoor dat alle technische en operationele eisen duidelijk zijn voordat de engineering van de functie begint.
Een SRS beschrijft de technische en functionele eisen van een veiligheidsfunctie.
Dit kan bijvoorbeeld betrekking hebben op:
-
de procescondities die een actie moeten activeren
-
de gewenste reactie van het systeem
-
de benodigde responstijd van de functie
-
de relatie met andere proces- of veiligheidsfuncties
-
eisen voor testen en beheer gedurende de lifecycle
Door deze informatie systematisch vast te leggen ontstaat een duidelijk kader voor het ontwerp en beheer van de veiligheidsfunctie.
In de praktijk zien we dat SRS-documentatie soms onvoldoende detail bevat of niet goed aansluit op de implementatie van het systeem.
Veel voorkomende problemen zijn bijvoorbeeld:
-
onduidelijke of incomplete specificaties
-
inconsistenties tussen verschillende documenten
-
aannames die niet expliciet zijn vastgelegd
-
wijzigingen in installaties die niet worden doorgevoerd in de documentatie
Daardoor kan een veiligheidsfunctie anders functioneren dan oorspronkelijk bedoeld.
Pro6com ondersteunt organisaties bij het ontwikkelen en beoordelen van Safety Requirements Specifications voor industriële installaties.
Daarbij zorgen we dat de specificatie aansluit op zowel de risicoanalyse als de praktische uitvoering in de installatie. Onze ondersteuning kan onder andere bestaan uit:
-
het vertalen van risicoanalyses naar functionele eisen
-
het structureren van SRS-documentatie volgens IEC 61511
-
het controleren van consistentie tussen engineeringdocumentatie
-
het verbeteren van lifecyclebeheer van veiligheidsfuncties
Zo zorgen we dat de veiligheidsfunctie niet alleen goed wordt ontworpen, maar ook duidelijk en consistent wordt vastgelegd.
Een Safety Requirement Specification, of SRS, legt vast wat een veiligheidsfunctie precies moet doen en aan welke eisen zij moet voldoen. Dat klinkt eenvoudig, maar in de praktijk is dit één van de belangrijkste documenten in de hele functional safety lifecycle. Hier wordt namelijk vastgelegd:
-
wanneer een functie moet ingrijpen
-
welke metingen en setpoints relevant zijn
-
wat de gewenste actie is
-
hoe snel het systeem moet reageren
-
hoe de functie getest en beheerd wordt
Zonder goede SRS ontstaat al snel ruimte voor interpretatieverschillen tussen procesengineering, automatisering, onderhoud en operations. En juist daar ontstaan fouten. Een goede SRS verbindt risicoanalyse, ontwerp en uitvoering. Het maakt duidelijk wat bedoeld is, zodat de veiligheidsfunctie in de praktijk ook echt doet wat nodig is.
