Larmhantering

Larmhantering är tillämpningen av mänskliga faktorer och ergonomi tillsammans med instrumentteknik och systemtänkande för att hantera designen av ett larmsystem för att öka dess användbarhet . Oftast är det stora användbarhetsproblemet att det finns för många larm i en anläggningsstörning, vanligen kallad larmöversvämning (liknande en avbrottsstorm), eftersom det är så likt en översvämning som orsakas av överdriven nederbörd med en i princip fixerad avloppskapacitet . Det kan dock också finnas andra problem med ett larmsystem som dåligt utformade larm, felaktigt inställda larmpunkter, ineffektiva tillkännagivanden, oklara larmmeddelanden etc. Dålig larmhantering är en av de främsta orsakerna till oplanerad driftstopp, vilket bidrar till över 20 miljarder USD i förlorad produktion varje år, och av stora industriella incidenter som den i Texas City. Att utveckla bra praxis för larmhantering är inte en diskret aktivitet, utan mer av en kontinuerlig process (dvs. det är mer en resa än en destination).

Larmproblemhistorik

Från deras uppfattning krävde stora kemikalie-, raffinerings-, kraftgenererings- och andra bearbetningsanläggningar användningen av ett kontrollsystem för att hålla processen igång framgångsrikt och producera produkter. På grund av komponenternas bräcklighet jämfört med processen, krävde dessa styrsystem ofta ett kontrollrum för att skydda dem från elementen och processförhållandena. I kontrollrummens tidiga dagar använde de vad som kallades " paneltavlor " som var laddade med kontrollinstrument och indikatorer. Dessa var knutna till sensorer placerade i processströmmarna och på utsidan av processutrustning. Sensorerna vidarebefordrade sin information till styrinstrumenten via analoga signaler, såsom en 4-20 mA strömslinga i form av tvinnade kablar. Till en början gav dessa system bara information, och en välutbildad operatör krävdes för att göra justeringar antingen genom att ändra flödeshastigheter eller ändra energitillförseln för att hålla processen inom dess designade gränser.

Larm lades till för att uppmärksamma operatören på ett tillstånd som var på väg att överskrida en designgräns, eller som redan hade överskridit en designgräns. Dessutom användes ESD-system (Emergency Shut Down) för att stoppa en process som riskerade att överskrida antingen säkerhets-, miljö- eller monetärt acceptabla processgränser. Larmet indikerades för operatören med signalhorn och lampor i olika färger. (Till exempel betydde gröna lampor OK, gula betydde inte OK och röda betydde DÅLIG.) Panelbrädor var vanligtvis utlagda på ett sätt som replikerade processflödet i anläggningen. Så instrumentering som indikerar driftenheter med anläggningen grupperades för igenkänningsskull och för att underlätta problemlösningen. Det var en enkel sak att titta på hela panelen och se om någon del av anläggningen fungerade dåligt. Detta berodde både på instrumentens utformning och implementeringen av de larm som hör ihop med instrumenten. Instrumentföretag lägger mycket kraft på designen och den individuella layouten av de instrument de tillverkade. För att göra detta använde de beteendepsykologiska metoder som avslöjade hur mycket information en människa kunde samla in i en snabb blick. Mer komplexa anläggningar hade mer komplexa paneler och därför ofta mer mänskliga operatörer eller styrenheter.

Sålunda, i de tidiga dagarna av panelkortsystem, reglerades larm av både storlek och kostnad. I grund och botten var de begränsade av mängden tillgängligt kortutrymme och kostnaden för att dra ledningar och koppla upp en signalgivare (horn), indikator (ljus) och strömbrytare för att vända för att bekräfta och rensa ett löst larm. Det var ofta så att om det behövdes ett nytt larm så fick man avstå från ett gammalt.

Allt eftersom tekniken utvecklades fick styrsystemet och styrmetoderna i uppdrag att fortsätta att främja en högre grad av anläggningsautomatisering för varje år som gick. Mycket komplex materialbearbetning krävde mycket komplexa kontrollmetoder. Den globala konkurrensen tvingade också tillverkningsverksamheten att öka produktionen samtidigt som den använde mindre energi och producerade mindre avfall. På paneltavlarnas dagar krävdes en speciell typ av ingenjör för att förstå en kombination av den elektroniska utrustningen förknippad med processmätning och kontroll, de kontrollalgoritmer som var nödvändiga för att styra processen (PID-grunderna) och den faktiska processen som pågick. används för att tillverka produkterna. Runt mitten av 80-talet gick vi in ​​i den digitala revolutionen. Distribuerade styrsystem (DCS) var en välsignelse för industrin. Ingenjören kunde nu kontrollera processen utan att behöva förstå den utrustning som krävs för att utföra kontrollfunktionerna. Panelkort behövdes inte längre, eftersom all information som en gång kom över analoga instrument kunde digitaliseras, stoppas in i en dator och manipuleras för att uppnå samma kontrollåtgärder som en gång utfördes med förstärkare och potentiometrar.

Som en bieffekt innebar det också att larm var enkla och billiga att konfigurera och distribuera. Du skrev helt enkelt in en plats, ett värde att larma på och satte det till aktivt. Det oavsiktliga resultatet var att folk snart skrämde allt. Initiala installatörer ställer in ett larm på 80 % och 20 % av driftintervallet för valfri variabel bara som en vana. Integreringen av programmerbara logiska styrenheter, säkerhetsinstrumenterade system och styrenheter för paketerad utrustning har åtföljts av en överväldigande ökning av associerade larm. En annan olycklig del av den digitala revolutionen var att det som en gång täckte flera kvadratmeter panelutrymme nu måste passas in i en 17-tums datorskärm. Flera sidor med information användes således för att replikera informationen på den ersatta panelen. Larm användes för att säga åt en operatör att gå och titta på en sida han inte tittade på. Larm användes för att berätta för en operatör att en tank höll på att fyllas. Varje misstag som gjordes i verksamheten resulterade vanligtvis i ett nytt larm. Med implementeringen av OSHA 1910-reglerna krävde HAZOPS-studier vanligtvis flera nya larm. Larm var överallt. Incidenter började samlas på grund av att en kombination av för mycket data kolliderade med för lite användbar information.

Alarmhanteringshistorik

I att inse att larm började bli ett problem, slog användare av industriella kontrollsystem sig samman och bildade Alarm Management Task Force, som var en kundrådgivning ledd av Honeywell 1990. AMTF inkluderade deltagare från kemiska, petrokemiska och raffineringsverksamheter. De samlade in och skrev ett dokument om frågorna i samband med larmhantering. Denna grupp insåg snabbt att larmproblem helt enkelt var en delmängd av ett större problem och bildade Abnormal Situation Management Consortium (ASM är ett registrerat varumärke som tillhör Honeywell). ASM -konsortiet utvecklade ett forskningsförslag och beviljades finansiering från National Institute of Standards and Technology (NIST) 1994. Fokus för detta arbete var att ta itu med den komplexa interaktionen mellan människa och system och faktorer som påverkar framgångsrika prestanda för processoperatörer. Automationslösningar har ofta utvecklats utan hänsyn till den människa som behöver interagera med lösningen. Larm är särskilt avsedda att förbättra situationsmedvetenheten för kontrollrumsoperatören, men ett dåligt konfigurerat larmsystem når inte detta mål.

ASM-konsortiet har tagit fram dokument om bästa praxis inom larmhantering, såväl som operatörens situationsmedvetenhet, operatörens effektivitet och andra operatörsorienterade frågor. Dessa dokument var ursprungligen endast för ASM-konsortiets medlemmar, men ASMC har nyligen erbjudit dessa dokument offentligt.

ASM-konsortiet deltog också i utvecklingen av en riktlinje för larmhantering publicerad av Engineering Equipment & Materials Users' Association (EEMUA) i Storbritannien. ASM-konsortiet tillhandahöll data från sina medlemsföretag och bidrog till redigeringen av riktlinjen. Resultatet är EEMUA 191 "Alarm Systems- A Guide to Design, Management and Procurement".

Flera institutioner och föreningar tar fram standarder för larmhantering för att hjälpa sina medlemmar med bästa praxis för användning av larm i industriella tillverkningssystem. Bland dem finns ISA (ISA 18.2), API (API 1167) och NAMUR (Namur NA 102). Flera företag erbjuder också mjukvarupaket för att hjälpa användare att hantera larmhanteringsfrågor. Bland dem finns DCS-tillverkningsföretag och tredjepartsleverantörer som erbjuder tilläggssystem.

Begrepp

Det grundläggande syftet med larmmeddelanden är att uppmärksamma operatören på avvikelser från normala driftförhållanden, dvs onormala driftsituationer. Det slutliga målet är att förhindra, eller åtminstone minimera, fysisk och ekonomisk förlust genom operatörsingripande som svar på det tillstånd som larmades. För de flesta användare av digitala styrsystem kan förluster bero på situationer som hotar miljösäkerhet, personalsäkerhet, utrustningsintegritet, driftsekonomi och produktkvalitetskontroll samt anläggningens genomströmning. En nyckelfaktor för operatörens reaktionseffektivitet är den hastighet och noggrannhet med vilken operatören kan identifiera de larm som kräver omedelbar åtgärd.

Som standard utgör tilldelningen av larmutlösningspunkter och larmprioriteter grundläggande larmhantering. Varje enskilt larm är utformat för att ge en varning när den processindikeringen avviker från det normala. Det största problemet med grundläggande larmhantering är att dessa funktioner är statiska. Det resulterande larmmeddelandet reagerar inte på förändringar i driftsättet eller driftförhållandena.

När en stor del av processutrustning som en laddpump, kompressor eller eldad värmare stängs av, blir många larm onödiga. Dessa larm är inte längre oberoende undantag från normal drift. De indikerar i den situationen sekundära, icke-kritiska effekter och ger inte längre operatören viktig information. På samma sätt, under uppstart eller avstängning av en processenhet, är många larm inte meningsfulla. Detta är ofta fallet eftersom de statiska larmförhållandena står i konflikt med de erforderliga driftskriterierna för uppstart och avstängning.

I alla fall av större utrustningsfel, uppstarter och avstängningar måste operatören söka larmmeddelanden och analysera vilka larm som är betydande. Detta slösar bort värdefull tid när operatören behöver fatta viktiga driftsbeslut och vidta snabba åtgärder. Om den resulterande översvämningen av larm blir för stor för operatören att förstå, har det grundläggande larmhanteringssystemet misslyckats som ett system som gör att operatören kan reagera snabbt och exakt på de larm som kräver omedelbar åtgärd. I sådana fall har operatören praktiskt taget ingen chans att minimera, än mindre förhindra, en betydande förlust.

Kort sagt, man behöver utvidga målen för larmhantering utöver den grundläggande nivån. Det är inte tillräckligt att använda flera prioritetsnivåer eftersom själva prioriteringen ofta är dynamisk. På samma sätt ger inte larmavaktivering baserat på enhetsassociation eller undertryckande av hörbar meddelande baserat på prioritet dynamisk, selektiv larmmeddelande. Lösningen måste vara ett larmhanteringssystem som dynamiskt kan filtrera processlarmen baserat på den aktuella anläggningens drift och förhållanden så att endast de för närvarande betydande larmen aviseras.

Det grundläggande syftet med dynamisk larmmeddelande är att uppmärksamma operatören på relevanta onormala driftssituationer. De inkluderar situationer som har ett nödvändigt eller möjligt svar från operatören för att säkerställa:

  • Personal och miljösäkerhet,
  • Utrustningsintegritet,
  • Produktkvalitetskontroll.

De slutliga målen skiljer sig inte från de tidigare grundläggande målen för hantering av larmmeddelanden. Dynamisk larmmeddelandehantering fokuserar operatörens uppmärksamhet genom att eliminera främmande larm, ger bättre igenkänning av kritiska problem och säkerställer snabbare och mer exakt operatörsrespons.

Behovet av larmhantering

Larmhantering är vanligtvis nödvändig i en processtillverkningsmiljö som styrs av en operatör som använder ett övervakande kontrollsystem, såsom en DCS , en SCADA eller en programmerbar logisk styrenhet (PLC) . Ett sådant system kan ha hundratals individuella larm som fram till helt nyligen troligen har utformats med endast begränsad hänsyn till andra larm i systemet. Eftersom människor bara kan göra en sak i taget och kan uppmärksamma ett begränsat antal saker åt gången, måste det finnas ett sätt att säkerställa att larm presenteras i en takt som kan assimileras av en mänsklig operatör, särskilt när växten är upprörd eller i ett ovanligt tillstånd. Larm måste också kunna rikta operatörens uppmärksamhet på det viktigaste problemet som han eller hon behöver agera på, med hjälp av en prioritet för att ange grad av betydelse eller rang, till exempel. För att säkerställa en kontinuerlig produktion, en sömlös service, en perfekt kvalitet när som helst på dygnet måste det finnas en organisation som innebär att flera team av människor hanterar, en efter en, de inträffade händelserna.

Detta kallas oftare för jourhantering. Jourledningen förlitar sig på ett team med en eller flera personer (platschef, underhållspersonal) eller på extern organisation (väktare, teleövervakningscentral). För att undvika att ha en heltidsanställd person att övervaka en enskild process eller en nivå, är information och/eller händelseöverföring obligatorisk. Denna informationsöverföring kommer att göra det möjligt för jourpersonalen att vara mer mobil, effektivare och att den kan utföra andra uppgifter samtidigt.

Några förbättringsmetoder

Teknikerna för att uppnå taktsänkning sträcker sig från de extremt enkla att minska olägenheter och lågvärdeslarm till att göra om larmsystemet på ett holistiskt sätt som tar hänsyn till relationerna mellan enskilda larm.

Designguide

Detta steg innebär att dokumentera metodiken eller filosofin för hur man designar larm. Det kan innehålla saker som vad som ska larmas, standarder för larmmeddelanden och textmeddelanden, hur operatören kommer att interagera med larmen.

Rationalisering och dokumentation

Denna fas är en detaljerad genomgång av alla larm för att dokumentera deras designsyfte, och för att säkerställa att de är valda och korrekt inställda och uppfyller designkriterierna. Helst kommer detta steg att resultera i en minskning av larm, men gör det inte alltid.

Avancerade metoder

Ovanstående steg kommer ofta fortfarande att misslyckas med att förhindra en larmöversvämning i en driftsstörning, så avancerade metoder som larmundertryckning under vissa omständigheter är då nödvändiga. Som ett exempel kommer att stänga av en pump alltid orsaka ett lågflödeslarm på pumpens utloppsflöde, så lågflödeslarmet kan undertryckas om pumpen stängdes av eftersom det inte tillför något värde för operatören, eftersom han eller hon redan vet det orsakades av att pumpen stängdes av. Denna teknik kan naturligtvis bli mycket komplicerad och kräver stor omsorg vid design. I fallet ovan kan man till exempel hävda att lågflödeslarmet ger ett mervärde eftersom det bekräftar för operatören att pumpen verkligen har stannat. Processgränser (Boundary Management) måste också beaktas.

Larmhantering blir mer och mer nödvändig i takt med att tillverkningssystemens komplexitet och storlek ökar. Mycket av behovet av larmhantering uppstår också eftersom larm kan konfigureras på en DCS till nästan noll inkrementell kostnad, medan tidigare på fysiska kontrollpanelsystem som bestod av individuella pneumatiska eller elektroniska analoga instrument krävde varje larm utgifter och kontrollpanel område, så mer funderade vanligtvis på behovet av ett larm. Många katastrofer som Three Mile Island , Tjernobylolyckan och Deepwater Horizon har etablerat ett tydligt behov av larmhantering.

De sju stegen till larmhantering

Steg 1: Skapa och anamma en larmfilosofi

Ett omfattande design- och riktlinjedokument tas fram som definierar en anläggningsstandard som använder en bästa praxis för larmhanteringsmetodik.

Steg 2: Benchmarking för larmprestanda

Analysera larmsystemet för att fastställa dess styrkor och brister och kartlägg effektivt en praktisk lösning för att förbättra det.

Steg 3: "Dålig skådespelare" larmupplösning

Av erfarenhet vet man att runt hälften av hela larmbelastningen vanligtvis kommer från ett relativt fåtal larm. Metoderna för att få dem att fungera korrekt är dokumenterade och kan tillämpas med minimal ansträngning och maximal prestandaförbättring.

Steg 4: Larmdokumentation och rationalisering (D&R)

En fullständig översyn av larmsystemet för att säkerställa att varje larm överensstämmer med larmfilosofin och principerna för god larmhantering.

Steg 5: Larmsystemrevision och verkställighet

DCS-larmsystem är notoriskt lätta att ändra och saknar i allmänhet ordentlig säkerhet. Det behövs metoder för att säkerställa att larmsystemet inte driver från sitt rationella tillstånd.

Steg 6: Larmhantering i realtid

Mer avancerade larmhanteringstekniker behövs ofta för att säkerställa att larmsystemet stöder, snarare än hindrar, operatören i alla driftsscenarier. Dessa inkluderar Alarm Shelving, State-Based Alarming och Alarm Flood Suppression-teknik.

Steg 7: Styr och underhåll larmsystemets prestanda

Korrekt hantering av förändringar och långsiktig analys och KPI-övervakning behövs för att säkerställa att vinsterna som har uppnåtts av att utföra stegen ovan inte minskar med tiden. Annars kommer de att göra det; principen om "entropi" gäller definitivt för ett larmsystem.

Se även

Anteckningar

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Alarm_management&oldid=1102335153 "