Deze pagina is een Draft, de inhoud is nog niet compleet en kan errors bevatten.
In dit artikel staat beschreven wat de ISA-18 inhoud en hoe deze behandeld dient te worden. Om dit allemaal duidelijk te krijgen zijn er een aantal verschillende artikelen gemaakt die ieder een stukje van de ISA-18 behandelen,hiervan is dit artikel de inleiding. De artikelen zijn allemaal los te lezen maar ook via een navigatie pad, wanneer het navigatie pad wordt gebruikt worden de verschillende artikelen in chronologische volgorde getoond.
1 Inleiding ISA-18
In dit artikel staat beschreven wat de ISA-18 inhoud en hoe deze behandeld dient te worden. Om dit allemaal duidelijk te krijgen zijn er een aantal verschillende artikelen waarvan deze de inleiding is. De artikelen zijn allemaal los te lezen maar ook via een navigatie pad, wanneer het navigatie pad wordt gebruikt worden de verschillende artikelen in chronologische volgorde getoond.
De ISA-18 is een standaard die ontwikkeld is voor het standaardiseren van een alarm systeem en beschrijft hoe dit gestructureerd opgezet en/of onderhouden kan worden. De ISA-18 is niet alleen te gebruiken in een nieuw alarm systeem maar is ook toe te passen in een bestaand alarm systeem, hierop zal later verder ingegaan worden.
1.1 Alarm Management Lifecycle (AML)
Alarm Management lifecycle (AML)
De Alarm Management Lifecycle beschrijft het verloop en volgorde van de verschillende stappen die nodig zijn om een efficiënt en goed werkend alarm systeem te krijgen en te houden.
De alarm management lifecycle fases die te zien zijn in de figuur hiernaast worden kort beschreven in de volgende subparagrafen, hiervoor zijn letterlabels (A-J) gebruikt, deze zijn terug te vinden in de titels. Een diepgaandere uitleg van de iedere fase staat per fase in een apart artikel uitgelegd.
1.2 Fases
1.2.1 Alarm Philosophy (A)
Voordat je begint met het maken van een alarm systeem is het belangrijk dat je vooraf goed vast legt wat de doelen zijn. Dit wordt gedaan in de alarm philosophy, hierin wordt gedocumenteerd wat de doelen zijn van het alarm systeem en wat de stappen zullen zijn om deze doelen te bewerkstelligen.
De philosophy begint met basis definities en zal deze uiteindelijk uitbreiden tot operationele definities.
De definitie van alarm prioriteiten, klassen, performence metrics, performence limits and reporting requirements worden bepaald op basis van de doelen, definities en principes. De bepalingen voor het weergeven van alarm meldingen in de HMI, inclusief het gebruik van prioriteiten, worden ook in de philosophy vastgelegd, deze dienen overigens wel aan te sluiten bij het algehele HMI ontwerp
De philosophy specificeert ook de werkprocessen die gevolgd dienen te worden voor iedere fase van de lifecycle. De philosophy dient te worden bijgewerkt iedere keer als er een aanpassing is gedaan aan het ontwerp, dit om ervoor te zorgen dat er gedurende de alarm system lifecycle een up to date alarm management is.
Het opstellen van de alarm system requirements wordt ook gedaan in de philosophy fase. Het grootste deel van deze specificaties zijn systeem specifiek maar. De specificaties zijn gedetailleerder dan de alarm philosophy en kan dienen als een goede leidraad tijdens het systeem ontwerp.
1.2.2 Identification (B)
In deze fase worden de alarmen geïdentificeerd, zoals de naam al doet vermoeden. Dit kan doormiddel van verschillende methoden deze methoden zijn gedefinieerd bijten deze standaard om. De verschillende methodes kunnen formeel zijn zoals process hazards analysis, safety requirements specifications, recommendations from an incident investigation, good manufacturing practice, milieu vergunningen, P&ID ontwikkeling of operating procedure review. Proces aanpassingen en bedienings tests kunnen ook leiden tot alarmen die gegenereerd of aangepast dienen te worden. Sommige alarmen komen pas aan het ligt na het monitoren van de alarm system performance. Aan het eind van deze fase is een alarm volledig geïdentificeerd en kan die behandeld worden in de Rationalization fase.
1.2.3 Rationalization (C)
In deze fase worden de geïdentificeerde alarmen of aanpassingen samengevoegd met de Alarm philosophy. Deze stappen kunnen zowel in een keer als los uitgevoerd worden. Het eindresultaat van de rationalization fase zal zijn, een helder document van een alarm inclusief geavanceerde alarm technieken.
In het document dat is ontstaan aan het eind van deze fase staan een aantal belangrijke zaken vastgelegd zoals:
1.2.4 Detailed design (D)
In de design fase worden de alarm attributen en gespecificeerd en ontworpen op basis van de requirements vastgesteld in de rationalization fase. Het design kent 3 onderdelen: Basic alarm design, HMI design en design van geavanceerde alarm technieken.
Basic design: ieder alarm volgt een bepaalde weg gebaseerd op het type alarm en het specifieke besturing systeem.
HMI design: Hierin worden de manier van weergave en aankondiging van een alarm ontworpen, inclusief de indicaties van prioriteit.
Geavanceerde alarm technieken: doormiddel van deze extra toevoeging(en) kan de effectiviteit van een alarm systeem verbeterd worden hierbij moet gedacht worden aan status gebaseerd alarmeren en dynamisch prioritering.
1.2.5 Implementation (E)
In de implementation fase worden de alarmen of het alarm systeem geïmplementeerd en volledig online gebracht. Het implementeren van een nieuw alarm of alarm systeem beslaat
Tijdens de implemenatie fase worden ook de operators opgeleid zodat ze kunnen omgaan met alarmen, daarnaast is het testen van nieuwe alarmen ook een requirement voor deze fase. de documentatie voor training, testing en in bedrijfsstelling zal per systeem verschillen en opgesteld worden volgens de richtlijnen zoals opgesteld in de philosophy fase.
1.2.6 Operation (F)
In de operation fase werkt het alarm of het alarm systeem zoals deze bedoeld is. Een herhalingscursus voor zowel het alarm philosophy en het doel van elk alarm is opgenomen in deze fase.
1.2.7 Maintenance (G)
In de maintenance fase van de alarm management lifecycle is het alarm systeem niet operationeel maar wordt het getest, onderhouden of gerepareerd. Periodiek onderhoud is nodig om de het alarm systeem te laten werken zoals het is ontworpen.
1.2.8 Monitoring and Assessment (H)
In de Monitoring and Assesment fase wordt de performence van het alarm systeem en de individuele alarmen continu gemonitoord en de resultaten worden vergeleken met de doelen zoals deze zijn vastgelegd in de Philosophy fase. Het monitoren en beoordelen van de data die wordt gegenereerd uit de operation fase kan mogelijk leiden tot het doen van onderhoud of tot het aanbrengen van wijzigingen in het alarm systeem of de manier van werken. Daarnaast zal het monitoren en beoordelen van data uit de maintenance fase bied een beeld van de efficiëntie van het onderhoud. Als deze fase niet of slecht wordt uitgevoerd dan kan dit leiden tot het verouderen en verslechteren van het alarm systeem.
1.2.9 Management of change (I)
In de management of change fase worden aanpassingen aan het systeem voorgesteld en wordt deze goedgekeurd. Vervolgens zal voor de aanpassing de fases indetification tot en met implementation opnieuw moeten worden doorlopen.
1.2.10 Audit (J)
In de audit fase worden periodiek beoordelingen uitgevoerd om de integriteit van het alarm systeem en het management te bewaken. Audits van de prestaties van het systeem kan mogelijke gaten aan het licht brengen die niet duidelijk of zichtbaar waren in de reguliere monitoring.
Als de audit wordt afgezet tegen de philosophy dan kan dit helpen bij het identificeren van verbeteringen voor het systeem, zoals verbeteringen aan de alarm philosophy. Audits kunnen mogelijk ook leiden tot het verbeteren van de discipline binnen de organisatie met betrekking tot het volgen van de alarm philosophy.
1.3 Alarm lifecycle start punten
Afhankelijk van de gekozen benaderings wijze, zijn er 3 verschillende startpunten in de alarm management lifecycle.
- Alarm philosophy
- Monitoring and assement
- Audit
Deze startpunten zijn in het Alarm Management Lifecycle te herkennen aan de blokken met afgeronde hoeken. Als startpunt zijn deze fases maar een initiële stap bij het managen van een alarm systeem. Alle stappen dienen echter te worden doorlopen om een goed alarm management systeem te krijgen.
1.3.1 Start met alarm philosphy (A)
Wanneer een nieuw alarm systeem gemaakt dient te worden dan is dit het startpunt. In deze fase wordt de basis gelegd voor het volledige alarm management systeem, zo worden in deze fase de doelen beschreven en vastgelegd welke weer gebruikt kunnen worden in alarm system requirements specification.
1.3.2 Start met Monitoring and Assesment (H)
Wanneer er een bestaand alarm systeem is kan ervoor worden gekozen om deze te monitoren en te beoordelen. Zo kunnen alarmen die problemen of gebreken vertonen gevonden worden en daarna doorgezet worden naar de maintenance of de management of change fase.
1.3.3 Start met Audit (J)
Het derde mogelijke startpunt is een initiële controle van alle aspecten van het alarm management tegenover een set gedocumenteerde praktijken, zoals die zijn opgenomen in deze norm. de resultaten van de initiële audit kan worden gebruikt bij de ontwikkeling van een filosofie.
1.4 Simultaneous and Encompassing Stages
Het lifecycle diagram is getekend om opeenvolgende fases weer te geven, maar er zijn een aantal fases die tegelijker tijd plaats kunnen vinden. Sommige van deze fases omvatten activiteiten uit andere fases.
- De monitoring and assesment fase (H) wordt tegelijkertijd uitgevoerd met de operation en maintenance fases.
- De management of change fase (I) vormt de inleiding van het aanpassing proces van waaruit de benodigde fases worden geautoriseerd en afgerond.
- De audit fase (J) is een overkoepelende activiteit die op elk moment in de lifecycle kan optreden en bevat een overzicht van de activiteiten van de overige fases.
1.5 Alarm Management Lifecycle Loops
In navolging van de verschillende lifecycle fases, zijn er nog drie loops in de lifecycle. Elke loop voert een functie uit tijdens de lifecycle.
1.5.1 Monitoring en maintenance loop
Deze loop identificeert probleem alarmen voor maintenance. Gerepareerde alarmen worden terugbracht naar operation.
1.5.2 Monitoring en management of change loop
Deze fase wordt geactiveerd wanneer routine monitoring een alarm naar voren brengt die werkt voor het ontwerp, maar niet compatible is met de alarm philosophy. Het ontwerp dient mogelijk te worden aangepast of er dienen geavanceerde alarm technieken te worden gebruikt. Het alarm mag in bedrijf blijven zolang de management of change geactiveerd en de verschillende fases van de lifecycle worden doorlopen.
1.5.3 Audit en philosophy loop
Dit is de gehele lifecycle en het proces van continue verbeteringen aan het alarm systeem. De audit proces identificeert de zwakke schakel in de lifecycle.
1.5.4 Alarm management lifecycle stage inputs en outputs
Zoals in de Alarm Managment Lifecycle te zien is zijn er verbanden tussen de verschillende fases. In de tabel hieronder staat beschreven wat deze verbindingen inhouden en wat ze betekenen voor de lifecycle.
2 Process condition model
Het process condition model geeft de grenzen van proces omstandigheden weer, van normale en doel voorschriften tot de abnormale omstandigheden als verstorende, stoppen of verwijderen. Dit simpele model helpt bij het ontwikkelen van alarm principes en de alarm philosophy. De waarschuwingen en indicaties zijn er niet om te suggereren dat er een alarm vereist is, maar alleen dat onder bepaalde omstandigheden een alarm wenselijk kan zijn. Daarnaast zal ieder alarm gerationaliseerd worden om het toetsen of het alarm echt nodig is.
Process condition model
2.1 Process conditions
De proces condities zoals weergegeven in Figuur 3 3 worden hieronder nader uitgelegd.
2.1.1 Target
Dit zijn de ideale productie omstandigheden met betrekking tot alle belangrijke facetten zoals, hoogste rendement, laagste kosten of doel capaciteit.
2.1.2 Normal
Dit zijn de omstandigheden welke de productie waarschijnlijk zal halen, dit wordt soms de standaard productie omstandigheden genoemd.
2.1.3 Upset
De verstorende omstandigheden kunnen resulteren in off-quality product, non-standard product, verhoogde uitstoot of mogelijk ernstigere consequenties.
2.1.4 Shutdown/disposal
Dit is het resultaat van manueel of automatisch ingrijpen om onacceptabele productie omstandigheden of onacceptabele producten te voorkomen.
2.2 Proces condities waarschuwingen en indicaties
De overgangen tussen proces omstandigheden zijn de mogelijke momenten voor het generen van alarmen.
2.2.1 Off-target indication
Deze komt op wanneer er wordt afgeweken van de target conditie maar het proces zit nog wel in normale omstandigheden.
2.2.2 Pre-upset warning
Deze wordt geactiveerd wanneer abnormale omstandigheden dreigen te ontstaan. Waar verstorende of non-standaard omstandigheden ernstige gevolgen kunnen hebben, kan er een waarschuwing komen zodat er nog genoeg tijd is om in te grijpen om upset omstandigheden te voorkomen.
2.2.3 Upset indication
Wanneer een pre-upset waarschuwing niet is verantwoord kan dit de eerste melding zijn van abnormale omstandigheden.
2.2.4 Pre-trip warning
Deze waarschuwing is een gelegenheid om een shutdown te voorkomen of het vernietigen van een complete batch. De shutdown kan herleid worden tot een noodstop procedure van een plant of een plaatselijke proces interlock op een enkele machine.
2.2.5 Trip indication
Dit is the point of no return. Zodra deze melding komt is er een noodstop geweest of een product is onbruik baar geworden door het overschrijden van proces limieten.
3 Alarm toestanden
De alarm status overgang diagram zoals weergegeven in Figuur 3 4 presenteert de statussen en de daarbij behorende overgangen voor typische alarmen. Natuurlijk zijn er uitzonderingen te bedenken, maar desondanks is dit diagram een goed hulpmiddel voor het ontwikkelen van alarm systeem principes en HMI functies. Note sommige termen die in dit diagram worden gebruikt zijn ook in het process condition model, Figuur 3 3.
Alarm status overgang digram
3.1 Alarm states
De cirkels in Figuur 3 4 staan voor de statussen van alarmen, de letterlabels die in deze cirkels staan worden in de onderstaande tekst gebruikt bij de uitleg.
- Normal (A) Dit is de toestand waarin het proces normaal werkt, het alarm is weg en oude alarmen zijn acknowledged.
- Unack Alarm (B) Dit is de eerste fase waarin een alarm terecht komt. Eerder acknowledged alarmen kunnen zo zijn ontworpen dat ze kunnen heralarmeren en terug keren in deze toestand.
- Ack Alarm (C) Een alarm komt in deze toestand wanneer het alarm niet is verholpen maar de operator heeft deze wel acknowledged.
- RTN Unack (D) Een alarm bereikt deze status wanneer het proces automatisch de normale status bereikt en het alarm gereset wordt, zonder tussenkomst van de operator.
- Latch Unack (E) Net als bij RTN Unack status, komt een alarm in de Latch Unack status wanneer het alarm automatisch wordt acknowledged zonder tussenkomst van de operator. Het alarm blijft vergrendeld en vereist verdere acties van de operator om het alarm te resetten. Dit is een optionele functie.
- Latch Ack (F) Zodra de operator een alarm, dat de Latch Unack status heeft, acknowledged dan zal dit alarm in deze status krijgen totdat de operator het alarm reset. Latch Ack is een optioenel functie.
- Shelved (G) Deze status wordt gebruikt wanneer een alarm tijdelijk onderdrukt wordt, gebruikmakend van een gecontroleerde methodiek. Een alarm in de shelved status is onder directe controle en verantwoording van de operator.
- Suppressed by Design (H) Deze status wordt gebruikt om alarmen doormiddel van de logica te onderdrukken, dit wordt bepaald aan de hand van de proces condities en/of de plant status.
- Out-of-Service (I) Deze status wordt gebruikt wanneer een alarm tijdelijk onderdrukt wordt, t.b.v. maintenance. Een alarm in de out-of-service status is onder directe controle en verantwoording van maintenance.
3.2 Alarm Cycle Transistion Paths
De pijlen in het diagram representeren overgangen tussen de verschillende statussen.
- Alarm Occurs (A->B) Het proces is buiten de normal range gegaan en is hier lang genoeg gebleven om het alarm te activeren.
- Operator Ack (B->C) Een operator heeft een actief alarm acknowledged.
- Re-Alarm (C->B) Het re-alarm pad zorgt voor een periodieke heralarmering zolang het alarm in de alarm status blijft staan.
- Process RTN Alarm clears (C->A) De route voor alarmen die geen separate reset vereisen na het terug keren in normale proces condities.
- Process RTN (C->F) Een alarm dat een separate reset vereist volgt deze route nadat het proces in normale conditie is belandt en wordt vervolgens vergrendeld.
- Process RTN and Alarm Clears (B->D) Het proces keert terug in normale condities maar de operator heeft het alarm nog niet acknowledged en het alarm kan niet vergrendelen.
- Operator Ack (D->A) Een alarm is al automatisch opgelost maar moest nog acknowledged worden.
- Process RTN (B->E) Het proces keert terug in normale condities maar de operator heeft het alarm nog niet acknowledged en het alarm wordt vergrendelen.
- Operator Resets (E->D) Een operator reset een alarm alvorens te acknowledge.
- Operator Ack (E->F) Een operator acknowledges een vergrendeld alarm waarvan het proces naar een normale toestand is teruggekeerd.
- Operator Resets (F->A) Het alarm is acknowledged en het proces is terug in een normale toestand. Wanneer het alarm wordt gereset zal het alarm naar de status normal terugkeren.
- Shelve (Any State->G) and Un-shelve (G->Any State) Een operator kan een alarm wegzetten om een ervoor te zorgen dat het alarm display overzichtelijk blijft. Dit is meestal een manuele handeling.
- Designed Suppression (Any State->H) and Designed Un-Suppression (H->Any State) Proces condities en/of statussen kunnen er voor zorgen dat een alarm automatisch onderdrukt wordt. Dit kan ook terugui9t worden uitgevoerd.
- Remove-from-Service (Any State->I) and Return-to-Service (I->Any State) Een operator kan een alarm uit de het systeem halen voor onderhoud of andere redenen en kan het weer terg plaatsen wanneer weer beschikbaar. Dit is meestal een manuele handeling.
4 Alarm response tijdlijn
Figuur 3 5 representeert een proces meeting waarbij het proces veranderd van een normale conditie naar abnormale omstandigheden en de twee mogelijke scenario’s die gebaseerd zijn op mogelijk juiste of onjuiste correctie van de operator. Door gebruik te maken van Figuur 3 4 is het mogelijk om sommige statussen in deze tijdlijn te plaatsen zodat er duidelijkheid geschept kan worden in sommige tijdgerelateerde definities zijn.
Alarm tijdlijn
4.1 Normal (A)
Dit staat gelijk aan de status uit paragraaf 3.4.1.1.
4.2 Unack Alarm (B)
Deze status resulteert uit het overschrijden van de alarm setpoint. Er zijn verschillende factoren die de onzekerheid van de alarmtijd beïnvloeden, zoals:
- Meet nauwkeurigheid,
- Alarm vertagingstijd.
4.3 Ack and Response (C)
De acknowledged alarm state wordt bereikt nadat een alarm door de operator word acknowledged. Er zijn verschillende factoren die bijdragen aan de onzekerheid over de operator response tijd, zoals:
- System processing snelheid
- HMI design en duidelijkheid
- Besef en training operator
- Werkdruk operator
- Complexiteit voor het bepalen van de juiste corrigerende actie
- Complexiteit van de corrigerende actie
De tijd die tussen het triggeren van een alarm en de actie van de operator is de werkelijke response tijd van het alarm, ofwel operator response delay. Dit is inclusief detectie van het alarm, situatie analyse en de overweging van de corrigerende actie.
4.4 Return to Normal (D)
Dit zou moeten gebeuren wanneer de operator de juiste beslissing heeft genomen binnen de toegestane response tijd. Er zijn verschillende factoren die de onzekerheid bieden over de return to normal tijd, zoals:
- Operator response tijd,
- Mate van maatregelen die genomen zijn,
- Dode proces tijd in reactie op de corrigerende actie
- Reactie tijd proces op genomen maatregelen
- Nauwkeurigheid van metingen
- Dodeband van de alarm setpoint
- Operationele snelheid van het alarm systeem
4.5 Consequentie grens
Dit resulteert wanneer de operator te laat, de verkeerde, onvoldoende of helemaal geen actie onderneemt op een alarm. Dit is “the point of no return”.
5 Feedback model van operator – proces interactie
feedback model van operator -> process interactie
In Figuur 3 6 is schematisch weergegeven de interactie tussen operator en het proces. In reactie op welke verstoring dan ook zal een operator uiteindelijk gaan proberen om het proces weer in goede banen te leiden. Om deze actie te starten dienen er drie activiteiten plaats te hebben:
- Er is een afwijking geconstateerd van de normale proces operatie
- De situatie is beoordeeld en de juiste corrigerende actie is gekozen
- De actie word uitgevoerd om de afwijking te compenseren.
1 Detect
De operator constateert de afwijking
2 Diagnose
De operator bepaald aan de hand van kennis en ervaring wat de juiste corrigerende handeling is.
3 Respond
De operator voert de gekozen handeling uit.
 | Klik op het PDF icon. Volledige ISA-18. |