atpv

Навчальні матеріали з автоматизації технологічних процесів та виробництв, розроблені спільнотою

<- До підрозділу

Розроблення підсистеми тривожної сигналізації

1. Важливість і стандарти впровадження підсистем тривожної сигналізації

Функції тривожної сигналізації є одними з найважливіших у системах SCADA/HMI, тому входять до комплектності усіх засобів цього типу і нерідко є виділеною підсистемою. Добре пророблені функції запобігають аварійним ситуаціям і можуть не тільки зменшити збитки, а й зберегти життя людей і довкілля. З іншого боку, якщо підсистема або окремі її функції погано реалізовані, то це може звести нанівець усю її роботу. Останнє, на жаль, часто спостерігається на вітчизняних підприємствах, де до розроблення функцій тривожної сигналізації ставляться легковажно. Наступний приклад може здатися багатьом дуже знайомим.

Класичним способом контролю роботи двигунів є використання в якості зворотного зв’язку додаткових контактів, які замикаються при спрацюванні пускачів. Таким чином система тривожної сигналізації відслідковує сигнал керування та зворотний зв’язок по функції логічного AND з урахуванням затримки часу. На одному з об’єктів, при впроваджені системи АСУТП, замовник узяв на себе частину робіт щодо забезпечення керування та контролю спрацювання двигунів на насосах та інших механізмах, у тому числі роботи з прокладання кабельних проводок та підключення. У результаті виявилося, що на момент пуско-налагоджувальних робіт замовник не виконав цієї частини роботи. Це призвело до великої кількості тривог, які пов’язані з двигунами. Враховуючи, що ці тривоги займали велику кількість повідомлень у журналі, інші тривоги були невидимими й ігнорувалися оператором. Зрештою оператор взагалі не сприймав тривожну сигналізацію, оскільки вона постійно видавала повідомлення. У наведеному прикладі, здавалось би, винуватий замовник, але це не зовсім так. Система керування повинна передбачати механізми відключення (блокування) таких тривог.

Це тільки один з прикладів недостатньо продуманої підсистеми тривожної сигналізації, однак таких випадків дуже багато. У дослідженнях організації “Управління з охорони праці Великобританії” (HSE) наведено багато прикладів [1], [2], коли недостатньо продумана система тривожної сигналізації призводила до фатальних наслідків, які супроводжувалися забрудненням довкілля, нанесенням шкоди здоров’ю і, навіть смертю великої кількості людей. Одна з причин – відсутність на той час затверджених в стандартах кращих практик, інша – недотримання існуючих.

На відміну від України, в усіх високорозвинутих країнах охорона праці розглядається як економічний важіль у боротьбі з необґрунтованими збитками. Завдання таких організацій, як “Управління з охорони праці Великобританії”, “Адміністрація з безпеки та гігієни праці” (OSHA, “Міністерство праці США”), “Федеральний інститут з безпеки і гігієни праці” (ВАuА, Німеччина), охоплюють сфери від наукових досліджень, розроблення практичних рекомендацій, впровадження у виробництво методів поліпшення стану безпеки та гігієни праці до консультування підприємців та навчання спеціалістів і службовців у галузі безпеки та гігієни праці на виробництві. Такі практичні рекомендації та наукові дослідження досить серйозно зосереджуються на темі організації систем тривожної сигналізації.

У цивілізованому світі до проблеми розроблення ефективної тривожної сигналізації ставляться дуже відповідально, про що свідчить поява стандартів та ряд практичних рекомендацій. Зокрема, нам відомі такі практичні рекомендації та стандарти, присвячені саме системам тривожної сигналізації:

Існують також інші стандарти та практичні рекомендації, присвячені системам тривожної сигналізації, зокрема [3], [4], [5], [6]. Частина з них прийняті в Україні, але ці стандарти розглядають усі системи тривожної сигналізації як такі, які не пов’язані зі SCADA/HMI, або не приділяють їм достатньої уваги. Це сильно ускладнює використання їх у життєвому циклі розроблення системи.

Щоб спеціалісти, які задіяні в процесі розроблення системи тривожної сигналізації змогли проектувати і розроблювати ефективні АСУТП, в одному з комітетів ISA (International Society of Automation) розроблено стандарт ISA-18.2 “Організація функціонування систем тривожної сигналізації в переробних галузях промисловості” (“Management of Alarm Systems for the Process Industries”). Як зазначено в стандарті, “у звітах про розслідування серйозних інцидентів неефективні системи тривожної сигналізації часто наводяться як визначальні фактори впливу” [7]. Цей стандарт надає методологію, застосування якої приведе до поліпшення безпеки, якості та функціонування переробних галузей промисловості. Стандарт ISA-18.2 включає практики, викладені в інших стандартах і практичних рекомендаціях.

У ході розроблення ISA-18.2 було докладено всіх зусиль, щоб зберегти термінологію і практики відповідно до попередньої роботи всіх організацій і комітетів, що передували йому. У 2014 році було прийнято стандарт IEC 62682, який є аналогом ISA-18.2. Це значить, що даний стандарт можна гармонізувати з українськими хоча б методом підтвердження. В Україні цей стандарт є одним із пріоритетних для пророблення в технічному комітеті ТК 185 “Промислова автоматизація”.

2. Місце підсистеми тривожної сигналізації в системі автоматизованого керування

Згідно зі стандартом ISA-18.2 тривога (з англ. alarm), – це звукові та/або візуальні засоби індикації для оператора про несправність устаткування, відхилення від процесу, ненормальні умови, які потребують своєчасного реагування. Слід сказати, що в зарубіжних та вітчизняних стандартах є інші означення тривоги, зокрема в ДСТУ 3960-2000 та ДСТУ EN 50136-1-1-2014, які дещо відрізняються.

Згідно зі стандартом ISA-18.2, сукупність апаратного і програмного забезпечення, яке виявляє стан тривоги, повідомляє про це операторові і записує в журнал зміни стану, називається системою тривожної сигналізації (alarm system). При цьому наголошується, що оператор є частиною цієї системи. Є також інші означення у вітчизняних стандартах, зокрема у ДСТУ 3960-2000, де система тривожної сигналізації – це електричне устатковання, призначене для виявлення та попередження про наявність небезпеки. У посібнику використовується термін “система тривожної сигналізації”, взятий з українського стандарту, а означення терміну – з ISA-18.2 як більш сучасне та застосовне для SCADA/HMI.

Стандарт ISA-18.2 побудований на принципах розгляду системи тривожної сигналізації через призму життєвого циклу, що характерно для більшості сучасних стандартів ISA (і не тільки), зокрема спорідненого до нього ISA-101. Це типова практика системної інженерії, яка останні кілька десятків років сильно впливає на стандарти інженерії в цілому. Більшість функцій та сутності тривожної сигналізації в стандарті ISA-18.2 не розкриваються детально, а лише коротко описуються. Однак найбільш фундаментальні сутності, а також структура в стандарті описані на достатньому рівні, щоб їх зрозуміти. Крім того, після виходу першої версії стандарту вийшло також ряд технічних звітів, які надають рекомендації щодо впровадження підходів, викладених в ISA-18.2 (деталізують сутності та функціонування). У цьому розділі зупинимося на найбільш фундаментальних сутностях, описаних у стандарті, “вирвавши” їх із контексту життєвого циклу.

Стандарт розглядає систему тривожної сигналізації в контексті взаємодії з іншими системами. До сфери її діяльності можуть входити БСКТП/BPCS (базова система керування технологічними процесами/the basic process control system), СПАЗ/SIS (система протиаварійного захисту/the safety instrumented system) та інші автономні системи (packaged systems), кожна з яких використовує свої датчики вимірювання для стеження за умовами проходження процесу і логіку генерування тривог ( рис. 1). Система тривожної сигналізації забезпечує передачу інформації про тривогу операторові через HMI (зазвичай являє собою екран комп’ютера) або на панель оповіщення (annunciator panel) (рис. 2). До додаткових функцій системи тривожної сигналізації належать ведення журналу тривог (alarm log), сховища тривог (alarm historian) та розрахунок показників ефективності функціонування системи.

Рис. 1. Функціональна структура тривожної сигналізації

Рис. 2. Приклад панелі оповіщення

На рис. 1 у зоні дій системи тривожної сигналізації показано елементи, які стосуються не тільки її функцій. У стандарті зазначено, що ці засоби не входять у зону її діяльності, але можуть мати функції, які стосуються систем тривожної сигналізації. Зокрема:

Ефективність систем (або підсистем) тривожної сигналізації та інших наведених вище підсистем з аналогічними функціями, ґрунтується на правильному налаштуванні тривоги. Від цього залежить своєчасне реагування на тривогу та усвідомлення наступних дій, які має провести оператор. Для кращого розуміння правильного налаштування тривог варто розглянути їх через взаємодію оператора з процесом.

3. Взаємодія оператора з процесом

Розробники АСКТП нерідко забувають, що система тривожної сигналізації розроблена саме для оператора, який у даному контурі посідає головне місце. Саме його реакція і дії визначають досягнення цілей функціонування тривог. Система тривожної сигналізації лише допомагає операторові виявити тривогу та надати йому інструменти для швидкого орієнтування в ситуації. Дії щодо виправлення нештатної ситуації він повинен сформувати і провести самостійно. Тому в стандарті ISA-18.2 велику увагу приділяють опису моделі контуру тривоги через взаємодію оператора з процесом (рис. 3).

Тривога потрібна для усунення оператором або іншою уповноваженою особою нештатної ситуації в тому випадку, коли алгоритми автоматичного керування не передбачають цього. Наприклад, якщо зміна в процесі істотно відхиляється від бажаного стану, а система керування не може це виправити, оператор повинен вжити певних заходів, щоб повернути процес до норми. Якщо устатковання або система керування має несправність, то обслуговуючий персонал повинен вчасно зробити дії щодо її усунення. Будь-яка з наведених ситуацій передбачає, що оператор повинен виявити факт нештатної ситуації, діагностувати її та вжити відповідних дій:

1) виявлення (detect): оператор дізнається про відхилення від бажаного стану або несправності устатковання за допомогою відповідного сигналу тривоги. Структура системи тривожної сигналізації та інтерфейс оператора повинні сприяти виявленню відхилень;

2) діагностування (diagnose): у відповідь на відхилення оператор використовує свої знання та навички для інтерпретації інформації, діагностування ситуації та визначення необхідних коригувальних дій. Діагностувати ситуацію операторові допомагають процедури реагування на тривогу;

3) реагування (respond): вживаються коригувальні дії для компенсації збурення. У відповідь на відхилення оператор (або інша уповноважена особа) приймає коригувальні дії і контролює процес, щоб визначити, чи було виправлене це відхилення.

Рис. 3. Модель контуру тривоги через взаємодію оператора з процесом

Кожен із цих етапів дуже важливий і потребує окремої уваги на всіх стадіях життєвого циклу системи. Крім того, треба врахувати, що людина в цьому контурі є найбільш непередбачуваною ланкою. На здатність оператора виконувати свої функції впливає багато факторів, у тому числі:

При розробленні системи тривожної сигналізації неврахування якогось із наведених факторів може призвести до проблем. Зокрема, кількість активних тривог та частота зміни їх стану можуть стати причиною неефективності роботи системи тривожної сигналізації. Згідно зі стандартом ISA-18.2, ситуація, при якій частота виникнення тривог більша, ніж оператор може їх ефективно опрацювати, називається переповненням тривог (з англ. alarm flood). Прикладом переповнення тривог може бути показник частоти більший ніж 10 тривог за 10 хвилин. Для усунення цього негативного ефекту в стандарті ISA-18.2 означено багато механізмів та рекомендацій щодо побудови життєвого циклу організації системи тривожної сигналізації, деякі з них наведені в цьому та 10-му розділі посібника.

Розглянемо контур тривоги в системі як взаємопов’язані функції (рис. 4):

На рис. 4 підсистема тривожної сигналізації включає в себе тег ALRM, однак це є умовним позначенням, і наявність такого типу тегів залежить від реалізації. Також слід нагадати, що підсистема тривожної сигналізації (позначена як ALARM) може бути реалізована як у вигляді окремого сервера (навіть на окремому ПК), так і не існувати як підсистема, натомість її функції реалізовуватимуть в інших частинах SCADA/HMI.

Рис. 4. Деталізована модель тривогового контуру

Перелічені вище функції формують ланцюжок, який будемо називати тривоговим контуром. Як видно з рис. 4, швидкість виявлення спрацювання тривоги залежить від каналу вимірювання, швидкості опитування ПЛК та взаємодії між підсистемами. Діагностуванню в технічному плані можуть допомогти підсистема HMI та додаткові підсистеми. Реагування оператора може проводитись як через підсистеми SCADA, так і безпосередньо через ручні засоби керування (на рис. 4 показано бордовими лініями).

4. Автомат станів тривог

Принципово важливим для означення функцій тривог є формалізація їх автомату станів. На практиці трапляються неодноразові випадки, коли не тільки обслуговуючий персонал, а й розробники не могли чітко пояснити роботу тривог, закладену постачальниками інструментів SCADA/HMI. Іншим типовим випадком є власно придумані автомати станів, або відсутність їх (автоматів) взагалі. Недостатньо формалізований автомат станів може призвести до неправильного його тлумачення учасниками життєвого циклу підсистеми тривожної сигналізації і може спричинити непередбачувані наслідки! Навіть якщо в проекті буде реалізовано власний автомат станів, відмінний від стандартного, його треба обов’язково описати в документації у відповідному розділі проекту. У стандарті означення автомату станів є одним із фундаментальних механізмів, на яких ґрунтуються всі інші сутності.

Тривога може знаходитися в кількох станах, зміни яких можуть бути викликані різними джерелами в системі керування, включаючи польовий пристрій (наприклад, датчики і виконавчі механізми), систему керування (базову чи СПАЗ) та HMI (дії оператора). У стандарті ISA-18.2 наведено діаграму автомату станів тривоги, що показана на рис. 5. Стани тривоги представлені на рисунку колами, в яких наводиться опис стану, що включає літерну мітку (ідентифікатор стану), назву стану, опис умови проходження процесу та комбінацію статусів:

Таким чином, стан – це узагальнюючий показник, який залежить від плинного значення статусів та від попереднього стану.

Рис. 5. Автомат станів тривог згідно з ISA-18.2

У нижній частині діаграми показано можливі стани блокованих тривог (alarm suppression). Стрілки на рис. 5 відповідають переходам між станами. Діаграма не показує безпосередньо вплив зон нечутливостей чи затримок на спрацювання, які включені в оцінку статусу тривоги (тобто активної або неактивної). Більшість із них є очевидними, тому при описі станів прокоментуємо тільки деякі з них. Нормальний стан (A – Normal, NORM) означується як стан, в якому процес працює в межах нормальних характеристик, статус тривоги не є активним і попередні виникнення тривоги були підтверджені. Стан непідтвердженої тривоги (B – Unacknowledged state, UNACK) є початковим станом тривоги, що стає активною внаслідок ненормальних умов і є не підтвердженою оператором. Стан підтвердженої тривоги (C – Acknowledged state, ACKED) – це стан, в якому статус тривоги є активною і оператор її підтвердив. Повернена до нормального стану, непідтверджена тривога (D – Return to normal unacknowledged state, RTNUN) – це стан, в якому процес вже знаходиться в межах норми, але попередній активний стан тривоги не був підтверджений оператором.

У стандарті наведений типовий автомат станів, який реалізований у більшості відомих засобів SCADA/HMI. Деякі з інструментальних засобів передбачають два автомати станів: стандартний і без наявності статусу підтвердження.

Окрім наведених “класичних” станів, стандарт передбачає можливість блокувати тривоги, що повинно убезпечити систему тривожної сигналізації від ефекту переповнення тривог (alarm flood), про який уже згадувалося. Це стани тривоги: відтермінована (Shelved), проектно-блокована (Suppressed-by-design) та виведена з обслуговування (Out-of-service). На цих станах варто зупинитися детальніше, оскільки далеко не всім розробникам АСКТП вони відомі.

Стан відтермінованої тривоги (E – Shelved state, SHLVD) – це стан, в якому тривога тимчасово блокується оператором, тобто для неї не проводиться оповіщення. Перехід до відтермінованої (будь-який стан → E) відбувається тоді, коли оператор командою з HMI відтерміновує сигнал тривоги, щоб уникнути її появи на дисплеях активних тривог. Відтермінування – ручна операція, а от розблокування (unshelve) може відбуватися як автоматично (після заданого часу), так і вручну оператором. Якщо статус тривоги в цей час активний, перехід повинен здійснюватися до стану непідтвердженої тривоги, а якщо не активна – до нормального стану. Таким чином, функція відтермінування передбачає, що оператор задає час, протягом якого тривога буде заблокована. Система тривожної сигналізації повинна забезпечувати виконання таких функцій:

Стан проектно-блокованої тривоги (F – Suppressed-by-design, DSUPR) – це стан, в якому тривога блокується з причини певних умов експлуатації або стану установки, і для неї не потрібно проводити оповіщення. Тривога в цьому стані перебуває під контролем логіки, що означує актуальність тривоги. Перехід до стану проектно-блокованої тривоги (будь-який стан → F) відбувається тоді, коли виникли певні умови або стан процесу, які означені в проекті для блокування тривоги. Означене проектом блокування зазвичай є автоматичною операцією. Перехід від проектно-блокованої тривоги до нормального стану або стану непідтвердженої тривоги (F → A або B) відбувається тоді, коли виникли умови або змінився стан технологічного процесу, що означений для розблокування тривоги. Це зазвичай відбувається автоматично.

Щодо проектно-блокованих тривог система тривожної сигналізації повинна забезпечувати виконання таких функцій:

Стан виведеної з обслуговування тривоги (G – Out-of-service state, OOSRV) – це стан, в якому тривога блокується вручну оператором, як правило, при проведенні технічного обслуговування, і тому в цьому стані не потрібно проводити оповіщення. Тривога в цьому стані перебуває під контролем технічного обслуговування. Виведена з обслуговування тривога – це не те саме, що виведення з обслуговування устатковання або його частини. Устатковання може бути виведене з обслуговування, тоді як відповідні тривоги – ні. Перехід до цього стану (будь-який стан → G) відбувається тоді, коли тривога блокується з метою технічного обслуговування устатковання або з інших причин. Як правило, виведення з обслуговування – це ручна операція. Перехід від стану виведеної з обслуговування тривоги до нормального стану або непідтвердженої тривоги (G → A або B) відбувається, як правило, також вручну, після закінчення обслуговування.

Для виведених з обслуговування тривог система повинна виконувати функції:

На відміну від класичного автомату станів, механізм блокування не завжди передбачається розробником, що приводить до наслідків, описаних на початку розділу. Не дивлячись на те, що сучасні SCADA/HMI включають ці функції (або принаймні певні з них), їх часто ігнорують розробники АСКТП.

Слід звернути увагу на те, що назви станів можуть не збігатися у різних інструментальних засобах SCADA/HMI. Очевидно, це пов’язано з тим, що стандарт вийшов порівняно недавно.

Для узагальнення розуміння автомату станів у стандарті наводиться таблиця станів (табл. 1).

Таблиця 1.

Стани тривоги

ID Ско­рочено Назва стану Стан техноло­гічного процесу Статус тривоги Статус оповіщення Статус підтвердження
A NORM Нормальний В межах норми Неактивна Немає оповіщення Підтверджена
B UNACK Непідтверджена тривога За межами норми Активна Оповіщується Непідтверджена
C ACKED Підтверджена тривога За межами норми Активна Оповіщується Підтверджена
D RTNUN Повернена до нормального стану непідтвердженої тривога В межах норми Неактивна Оповіщується Непідтверджена
E SHLVD Відтермінована тривога В межах або за межами норми Неактивна або активна Заблоковане -
F DSUPR Проектно-блокована тривога В межах або за межами норми Неактивна або активна Заблоковане -
G OOSRV Виведена з обслуговування тривога В межах або за межами норми Неактивна або активна Заблоковане -

5. Приклад діаграми поведінки тривоги в часі

Означення автомату станів – це тільки перший крок для створення вдалої системи тривожної сигналізації. Для правильного налаштування тривог треба розуміти послідовність проходження в тривоговому контурі (рис. 3 та 4) етапів у часі. Не слід забувати, що завдання системи тривожної сигналізації – це своєчасно поінформувати оператора про відхилення, допомогти йому усвідомити причину такого відхилення і максимально допомогти в прийнятті рішення. Якщо оператор не встигне зробити необхідні дії через недостатню усвідомленість, несвоєчасне прийняття дій або з інших причин, то об’єкт може перейти в аварійно небезпечний стан. Для того, щоб краще зорієнтуватися у виборі налаштувань для тривог, у стандарті наводиться приклад діаграми поведінки тривоги в часі (рис. 6). На рисунку показано вимірювану технологічну змінну, яка зростає від нормального стану до ненормального (тривожного) за двох можливих сценаріїв, що залежать від того, чи вживає оператор коригувальні дії.

Розглянемо поведінку через діаграму на рис. 6 детальніше. Нормальний стан (A) означується як стан, в якому технологічний процес працює в межах звичайних характеристик. Коли вимірювальне значення перетинає уставку тривоги (alarm setpoint), вона переходить до стану непідтвердженої (B). Існує кілька факторів, що впливають на оповіщення про тривогу, які не показані на діаграмі, наприклад (рис. 4):

Рис. 6. Діаграма поведінки тривоги в часі

Сигнал не відразу підтверджується оператором, проходить певний час (затримка до підтвердження, acknowledge delay), після якого оператор підтверджує тривогу, і вона переходить до стану підтвердженої тривоги (C). Оператор може вжити заходів як до підтвердження тривоги, так і після цього. Протягом цього часу тривога знаходиться в активному стані. Фактичний час реагування (з actual response time) для сигналу тривоги – це максимальний час, що проходить між оповіщенням про тривогу і моментом, коли оператор повинен вжити заходів для уникнення наслідків. Фактичний час реагування включає в себе виявлення сигналу тривоги, діагностування ситуації та визначення оператором коригувальних дій, а також виконання цих дій. Верхня межа часу відгуку – допустимий час реагування (allowable response time) – це максимальний час, що проходить між оповіщенням і моментом, коли оператор повинен вжити заходів для уникнення наслідків. Якщо дія не буде виконана за цей час, то наслідки будуть негативними. На рис. затримка реагування оператора (operation response delay) відображається в межах допустимого часу. Існує кілька факторів, які впливають на час реагування оператора (operator response time):

Результатом правильної дії оператора в межах допустимого часу реагування повинно бути повернення до нормального стану (D). Поріг наслідків (consequence threshold) є значенням змінної процесу, при якому починається виникнення наслідків. Це може відбутися тоді, коли оператор не виконує жодних дій, вживається неправильна або недостатня дія або дія не завершується протягом допустимого часу відповіді. Вплив зони нечутливості тривоги (alarm deadband) показаний на рис. 6 через затримку нечутливості (deadband delay). На рисунку видно, що після перетину уставки тривога повертається до нормального стану не відразу, а лише через певний час. Існує кілька факторів, які впливають на час повернення до нормального стану:

Наведена на рис. 6 діаграма дає змогу на всіх етапах життєвого циклу ґрунтовно підійти до вибору правильних налаштувань. Навіть усвідомлення процесів такого вибору без формального їх виконання допомагає розробникові при створенні підсистем тривожної сигналізації.

6. Типи, групування та класифікація тривог

При означенні тривог у проекті необхідно чітко знати, з яких причин вони можуть виникати. Враховуючи, що типи умов бувають різними, в стандарті ISA-18.2 означене поняття тип тривоги (alarm type) – атрибут, який вказує на умову спрацювання тривоги. У табл.2 наведено типи тривог, які означені в стандарті ISA-18.2.

Таблиця 2.

Типи тривог

Назва українська Назва англійська Умова спрацювання
абсолютна тривога absolute alarm вихід за уставку тривоги; наприклад, дуже високе, високе, низьке, дуже низьке значення
тривога відхилення deviation alarm різниця між двома значеннями перевищує уставку тривоги; наприклад, відхилення сигналів вимірювань між первинними та резервними приладами або відхилення між дійсним та заданими значеннями змінної процесу
тривога швидкості зміни змінної rate-of-change alarm швидкість зміни змінної процесу (dPV/dt) перевищує уставку
тривога невідповідності discrepancy alarm очікуваний стан установки або пристрою та його фактичний стан відрізняються; наприклад, після команди на двигун немає зворотного сигналу про те, що він запустився
обчислювальна тривога calculated alarm генерується за розрахунковим значенням, а не за прямим вимірюванням процесу
керована рецептом тривога recipe-driven alarm вихід за уставку, що змінюється системою залежно від рецепту, який у даний час виконується
тривога по бітовому шаблону bit-pattern alarm шаблон цифрових сигналів (комбінація кількох бітів) відповідає встановленому
тривога по виходу регулятора controller-output alarm вихід за уставку вихідного сигналу алгоритму керування (наприклад, ПІД-регулятору); на противагу абсолютній тривозі використовується не прямий вимірювальний сигнал процесу, а вихід регулятора
системно-діагностична тривога system diagnostic alarm несправність у системі апаратного чи програмного забезпечення або компонентів; генерується системою керування, а не застосунком; наприклад, комунікаційна помилка
тривога діагностування приладу instrument diagnostic alarm несправність польового пристрою або його сигналу; наприклад, тривога виходу сигналу за межі
налаштовувана оператором тривога adjustable alarm вихід за уставку, яка може бути змінена вручну оператором
адаптивна тривога adaptive alarm вихід за уставку, яка змінюється алгоритмом; наприклад, уставка розраховується на основі швидкості вироблення продукції
повторно сигналізована тривога re-alarming alarm після спрацювання тривоги виникають нові умови для повторного оповіщення
статистична тривога statistical alarm результат статистичного оброблення технологічної змінної чи змінних не задовольняє вказаному в умові тривоги
першопричинна тривога first-out alarm спрацювання умови раніше, ніж в інших з вказаної послідовності; наприклад, при вимкненні кількох одиниць устатковання в короткий проміжок часу одне з них, яке вимкнулося раніше, буде причиною
тривога помилки вимірювання bad-measurement alarm сигнал вимірювальної величини перебуває за межами очікуваного діапазону (наприклад, 3,8 мА для сигналу від 4 до 20 мА)

Кожен тип потребує окремого розгляду. Не всі з перерахованих типів тривог можуть бути доступними в SCADA/HMI. Крім того, у деяких випадках може знадобитися інший тип тривог, який не входить до переліку табл.2. Також дозволяється комбінувати типи.

У системі тривожної сигналізації кількість тривог може сягати сотні й тисячі. Означення таких тривог потребує опису та означення пріоритетів, дій, які необхідно зробити операторові при їх виникненні, правила адміністрування та т. ін. Проведення цих робіт окремо для кожної тривоги займає багато часу і є неефективним. Натомість у стандарті ISA-18.2 рекомендується використовувати класифікацію тривог та означення необхідних параметрів вже не для конкретної тривоги, а для всього класу. Клас тривог (alarm class) – сукупність тривог із загальними вимогами щодо організації функціонування тривог (наприклад, вимоги до тестування, підготовки, моніторингу та планової перевірки). Приклад класу – тривоги протиаварійного захисту. Одна тривога може входити до кількох класів одночасно, тобто класи можуть перекриватися.

Крім об’єднання за класом тривог, є сенс їх групувати за ознакою приналежності до устатковання або частини процесу. Група тривог (alarm group) – набір тривог, які мають спільні взаємозв’язки з частиною технологічного процесу, установкою, набором устатковання або послугою. Використавши в журналах фільтрування тривог за назвою групи, можна спростити і прискорити аналіз причин виявлення відмов як у реальному часі, так і в пост-аналізі.

При виникненні кількох тривог операторові слід швидко визначитися з тим, яку з них необхідно опрацювати першою. Для цього в стандарті означено поняття пріоритет тривоги (alarm priority) – це відносна важливість, призначена тривозі в системі для позначення терміновості реагування на тривогу (наприклад, серйозність наслідків і допустимий час реагування). При розробленні пріоритети вибираються виходячи з того, що вищі пріоритети призначаються рідше, ніж нижчі. Більша кількість тривог мають найнижчий пріоритет (найменш важливі), а менша кількість – найвищий (найважливіші). Отримані пріоритети потрібно узгодити з наслідками і допустимим часом реагування. Таким чином, тривоги з найнижчим пріоритетом повинні мати найменш тяжкі наслідки і найбільший допустимий час реагування, а найвищого – найсерйозніші наслідки (наприклад, пожежні та сигналізації загазованості) і найменший допустимий час реагування.

7. Атрибути тривог

Наведені вище властивості мають бути описані та зконфігуровані в системі для кожної з тривог. Ці властивості означені в стандарті як атрибути тривог (alarm attribute). Тривоги повинні містити такі атрибути:

У найпростішому варіанті системи ці атрибути задаються в підсистемі тривог статично, однак у багатьох випадках їх значення повинні змінюватися оператором або програмно. Необхідність у зміні цих атрибутів може бути пов’язана з типом виготовлюваного продукту або станом технологічного процесу. Атрибути тривог зазвичай можуть бути програмно модифіковані з одного або декількох джерел:

Основні концепції зміни атрибутів тривог, що належить до прогресивних методик описані в підрозділі 9.

8. Людино-машинний інтерфейс для систем тривожної сигналізації

8.1. Загальні концепції

Враховуючи, що саме людина є ключовим елементом контуру тривожної сигналізації, велика увага в її організації надається людино-машинному інтерфейсу. Він повинен чітко відображати неблоковані активні тривоги із зазначенням їх станів, пріоритетів, типів та іншої додаткової інформації. Крім відображення, HMI повинен надати можливість операторові здійснювати такі дії:

Для забезпечення цих функцій відображення та дій HMI має надавати певні інструментальні засоби. Стандарт передбачає підтримку, як мінімум, таких засобів HMI:

Наведені дисплеї містять відображення стану тривог у вигляді записів. Запис тривоги (alarm record) – це набір інформації, який документує зміну стану тривоги. Тобто зміна стану тривоги приводить до формування нового запису (в деяких зведеннях – зміни запису попереднього стану). Згідно з ISA-18.2, запис тривоги повинен мати такі атрибути:

Окрім цього, рекомендується, щоб запис тривоги мав такі елементи:

8.2. Оповіщення про стани тривог

Для однозначного розрізнення станів тривог на HMI A-D (див. рис. 5) використовуються комбінації візуальних індикаторів та/або звукових сигналів. У цьому параграфі наведено рекомендації до способів оповіщення, які часто використовуються на практиці.

Нормальний стан не повинен використовувати звуковий сигнал. Візуальна індикація нормального стану має бути такою самою, як і індикації без тривоги.

У стані непідтвердженої тривоги слід використовувати як звуковий сигнал, так і візуальну індикацію. Звукове оповіщення повинно відключатися командою придушення або командою підтвердження (ACK) оператора. Візуальна індикація має чітко відрізнятися від звичайного стану за допомогою кольорів і символів (наприклад, форми або тексту). Візуальна індикація для непідтвердженої тривоги повинна включати миготливий елемент.

Стан підтвердженої тривоги не повинен використовувати звукове оповіщення. Візуальна індикація підтвердженого стану тривоги повинна чітко відрізнятися від індикації звичайного стану (не тривожного) за допомогою символів (наприклад, форми або тексту) і повинна бути пов’язана за кольором з індикацією стану непідтвердженої тривоги. Наприклад, червоний миготливий – для непідтвердженої і червоний – для підтвердженої. У візуальній індикації підтвердженої тривоги не повинен використовуватися миготливий елемент.

Стан повернутої до нормального стану, непідтвердженої тривоги не повинен використовувати звуковий сигнал. Візуальна індикація цього стану може бути такою самою, як і звичайний стан, або може вказувати на непідтверджений стан за допомогою миготливого елемента.

Стан блокованих тривог (відтермінованої, проектно-блокованої та виведеної з обслуговування) може бути показаний у HMI візуальними засобами, явно відмінним способом від інших станів. Звукову сигналізацію використовувати для блокованих тривог не дозволяється.

Рекомендації щодо звукової сигналізації та індикації залежно від станів наведено в табл.3.

Таблиця 3. Поведінка звукової сигналізації та індикації в залежності від стану тривог.

Стан тривоги Звук Візуальна індикація: Колір Візуальна індикація: Символ Візуальна індикація: Миготіння
нормальний ні ні ні ні
непідтверджена ТАК ТАК ТАК ТАК
підтверджена ні ТАК ТАК ні
повернена до нормального стану, непідтверджена ні Комбінація Опція  
відтермінована ні Опція н/з  
проектно-блокована ні Опція н/з  
виведена з обслуговування ні Опція н/з  

Примітка: н/з показує, що умова не застосовна або не має відношення до стану тривоги; комбінація вказує, що індикація є комбінацією візуальних кольорових і символьних індикацій; опція вказує, що індикація не є обов’язковою.

Звукова сигналізація для непідтверджених тривог може також використовуватися для зазначення пріоритету, ділянки процесу або групи тривог залежно від означеної методології. У середовищах, де звукова сигналізація не є ефективною (наприклад, середовища з високим рівнем шуму), для непідтвердженого стану тривоги слід використовувати чітку візуальну індикацію, яка завжди знаходиться в зоні оператора.

Для виділення пріоритетних тривог у системі необхідно використовувати візуальні індикатори, звукові сигнали або їх поєднання. Усі станції HMI в системі керування, включаючи відокремлені підсистеми, повинні надавати можливість різної індикації принаймні для трьох різних пріоритетів.

Для кожного пріоритету тривоги слід використовувати окрему кольорову індикацію, за винятком операційних середовищ, де це не є практичним. Першочергові кольори тривоги повинні бути зарезервовані і не повинні використовуватися для інших елементів HMI.

У стандарті даються рекомендації, прийняті в промисловій практиці. Зокрема, для підсилення виділення пріоритету тривоги, окрім кольорової індикації рекомендується використовувати унікальний символ, наприклад фігуру або текст, а також супроводження звуковою сигналізацією. У середовищах, де звукова сигналізація не використовується як індикатор пріоритету, слід застосовувати тільки візуальну індикацію.

Повідомлення тривоги передбачає подальше уточнення тривоги відображенням назви тегу, стану та пріоритету. Він може також включати частину дії оператора або посилання на процедуру відповіді на тривогу.

8.3. Дисплеї тривог

Стандартом ISA-18.2 передбачено, що у HMI може бути кілька типів дисплеїв, які можна використати для системи тривожної сигналізації. До них входять:

Також для відображення стану тривог можуть використовуватися різні дисплейні елементи, наприклад тривогові банери, які з’являються у вигляді смуг на екрані (над усіма вікнами) з відображенням останньої тривоги.

Згідно з вимогами стандарту, потрібен щонайменше один дисплей зведення тривог (alarm summary display) що також називається дисплей списку тривог (alarm list display), який надає список неблокованих активних тривог. Існує кілька обов’язкових і рекомендованих функцій для дисплея зведення тривог, які наведені в табл.4. Приклад дисплея зведення тривог показано на рис. 7 та 8.

Таблиця 4. Функції дисплея зведення тривог

Відображення на дисплеї Функції керування
Для кожної тривоги повинні відображатися:
- назва тегу для тривоги;
- опис тегу або опис тривоги;
- стан тривоги (alarm state), включаючи статус підтвердження;
- пріоритет тривоги;
- час/дата, коли тривога стала активною;
- тип тривоги. Рекомендується:
- плинне значення змінної процесу;
- уставка тривоги; - група тривоги або ділянка процесу;
- повідомлення тривоги.
Для всього списку рекомендується:
- кількість тривог у зведеному списку;
- кількість непідтверджених тривог у зведеному списку		 Повинні бути:
- упорядкування тривог за хронологічним порядком;
- упорядкування тривог за пріоритетом;
- індивідуальне підтвердження кожної тривоги;
- підтвердження кількох тривог з методами керування доступом, якщо це допускається в методології тривог.
Рекомендується:
- навігаційне посилання на відповідний дисплей процесу;
- доступ до процедур реагування на тривогу;
- фільтрація тривог за часом сигналу;
- фільтрація тривог за пріоритетом;
- фільтрація тривог за типом;
- фільтрація тривог за групою або ділянкою процесу;
- фільтрація тривог за назвою тегу;
- часові обмеження для фільтрів;
- упорядкування тривог за назвою тегу.
При задіянні фільтрів це повинно чітко відоб­ражатися на дисплеї. Також може викорис­товуватися лімітування за часом, коли фільтр видаляється після закінчення періоду часу

Рис. 7. Приклад дисплея зведення тривог у DeltaV від Emerson

Рис. 8. Приклад дисплея зведення тривог у WinCC v.7.3

Повинен бути наданий дисплей зведення статусу тривог (alarm summary status display), який показує кількість непідтверджених активних тривог за вибраним пріоритетом для кожної ділянки процесу. Зокрема, для кожної ділянки процесу рекомендується показувати:

Повинен бути наданий дисплей журналу тривог (alarm log display), який забезпечує доступ до записів тривог в архіві для кожної зміни стану (наприклад, підтвердження, повернення до нормального стану і т. п.). Функції дисплея журналу тривог показані в табл. 5, а приклад – на рис. 9.

Таблиця 5. Функції дисплея журналу тривог.

Відображення на дисплеї Функції керування
Для кожної тривоги рекомендується відображати
- ім’я тегу для тривоги;
- опис тегу або тривоги;
- стан тривоги (включаючи статус підтвердження);
- пріоритет тривоги;
- дата і час тривоги;
- дата і час підтвердження;
- дата і час повернення до нормального стану; - тип тривоги		 рекомендується забезпечувати фільтрацію по:
- імені;
- часу або зміні стану;
- стану тривоги;
- пріоритету;
- типу тривоги;
- групі тривоги або ділянки процесу

Рис. 9. Приклад дисплея журналу тривог

Дисплей процесу забезпечує інформацію про тривоги через контекст елементів. На ньому рекомендується відображати:

Приклад відображення інформації про тривогу на дисплеї процесу показано на рис. 10.

Рис. 10. Приклад відображення інофрмації про тривогу на дисплеї процесу

Дисплей інформації про тег (tag detail display) повинен забезпечувати детальний опис тегу тривоги. У ньому рекомендується надавати таку інформацію:

У системі тривожної сигналізації повинен бути передбачений дисплей відтермінованих тривог (shelved alarm display) та дисплей виведених з обслуговування тривог (out-of-service alarm display). Дисплей проектно-блокованих тривог (suppressed-by-design alarm display) має бути тільки у випадку використання цих типів тривог. Наведені дисплеї блокованих тривог повинні забезпечувати виконання функцій, зазначених у табл.6. На рис. 11 показано приклад відображення дисплея проектно-блокованих тривог, а на рис. 12 – відтермінованих тривог.

Таблиця 6. Функції дисплеїв блокованих тривог

Тип дисплею На дисплеї повинні відображатися Функції керування
Дисплей усіх блокованих тривог - назва тега тривоги;
- опис тегів або опис тривоги;
- тип тривоги;
- статус тривоги (тобто активна чи неактивна) ;
- пріоритет тривоги		 Повинні забезпечувати:
- упорядкування тривог за хронологічним порядком або за часом блокування;
- упорядкування тривог за пріоритетом. Шлях розблокування при активному статусі тривоги (перехід в стан):
- при ручному розблокуванні – в активний підтверджений стан;
- при автоматичному – в непідтверджений стан
Дисплей відтерміно-ваних тривог Додатково:
- час, що залишився, або час і дата виникнення тривоги		 Повинен забезпечувати додатково:
- індивідуальне розблокування тривог.
Рекомендується:
- упорядкування тривог за тегом
Дисплей відтерміно-ваних тривог Додатково:
- час, що залишився, або час і дата виникнення тривоги		 Повинен забезпечувати додатково:
- індивідуальне розблокування тривог.
Рекомендується:
- упорядкування тривог за тегом
- фільтрацію тривог за пріоритетом;
- фільтрацію тривог за станом тривоги;
- фільтрація тривог за ділянкою процесу;
- записування оператора про причину відтермінування тривоги;
- групове розблокування тривог;
- навігаційне посилання на дисплей технологічного процесу;
- навігаційне посилання на дисплей інформації про тег
Дисплей виведених із обслуго-вування тривог Додатково:
- час і дата, коли тривога була виведена з обслуговування		 Повинен забезпечувати додатково:
- упорядкування тривог за статусом тривоги (наприклад активні чи неактивні) ;
- упорядкування тривог за ділянкою процесу;
- індивідуальне розблокування тривоги.
Рекомендується:
- введення оператором причини виведення тривоги з обслуговування
Дисплей проектно-блокованих тривог Додатково:
- час і дата блокування;
- інформація про метод блокування, наприклад, спроекто­ване блокування (рекомендується)		 Повинен забезпечувати додатково:
- упорядкування тривог за статусом тривоги (наприклад активні чи неактивні) ;
- упорядкування тривог за ділянкою процесу; Рекомендується:
- можливість розблокування оператором тривоги або відключення функції проектного блокування

Рис. 11. Приклад відображення дисплея проектно-блокованих тривог

Рис. 6 .12. Приклад відображення дисплею відтермінованих тривог у WinCC v.7.3

9. Розширені та прогресивні методи організації тривог

Розширені (enhanced) та прогресивні (advanced) методи організації тривог забезпечують додаткову функціональність системи тривожної сигналізації. Згідно зі стандартом ISA-18.2, ці методи передбачають додаткові шари логіки, програмування або моделювання, які використовуються для зміни атрибутів тривог. Прогресивне керування тривогами (Advanced alarming) передбачає зміну поведінки тривоги, ґрунтуючись на різних методах. У багатьох випадках воно використовується для позбавлення або пом’якшення ефекту переповнення тривог, які не забезпечують базові методи розроблення тривоги. До методів прогресивного керування тривогами входять:

У доповнення до цього – розширене керування тривогами (enhanced alarming). Воно надає операторові додаткову інформацію з інших підсистем або/та перенаправляє тривогу вказаному отримувачу в іншій підсистемі.

Розширені та прогресивні методи керування тривогами часто використовуються в тому випадку, коли базовий функціонал тривожної сигналізації не досягає цілей продуктивності, зазначених у методології системи тривожної сигналізації. Складність розширених і прогресивних методів керування тривогами потребує додаткових ресурсів для проектування, впровадження та обслуговування. Щоб зменшити залежність реалізації методик від можливостей SCADA/HMI, розробники нерідко реалізовують ці функції на рівні ПЛК, зокрема, як це робиться в PAC Framework [8], [9].

Системи тривожної сигналізації можуть бути посилені розширеними методами прив’язування до інформації в основній базі даних тривоги (наприклад, дії оператора або наслідку). Це розширення надає можливість при виникненні тривоги надати операторові інформацію з центральної бази даних тривоги, або навпаки – занести туди проведені дії оператора. Інформація також може бути пов’язана з іншими джерелами, включаючи: операційні процедури, журнали операторів, історію обслуговування або проектні документи.

Деяким розширеним і прогресивним методам керування тривогами потрібно мати можливість змінювати певні атрибути тривоги (наприклад, змінити уставку або пріоритет тривоги). Така модифікація потребується з причини зміни умов експлуатації процесу або установки. До таких належить стано-орієнтоване керування тривогами – прогресивний метод, який змінює атрибути тривоги на підставі означених робочих станів для устатковання або процесів. Стани часто визначаються через:

На окрему увагу заслуговує керування тривогами для Batch процесів для багато-рецептурних виробництв. Batch виробництво (порційне, багаторецептурне) – це виробництво, в якому кожен продукт виготовляється поетапно за окремим рецептом (див. також параграф 8.4.2). По суті, рецепт означує набір етапів та задані параметри. Тут є багато особливостей, які характерні саме для таких процесів і які треба враховувати якщо порівнювати з неперервними виробництвами:

Це тільки деякі з особливостей Batch-керування, більше про це можна прочитати в стандарті ISA-88, коротко про це описано в [10]. У будь-якому випадку тривоги у Batch-процесах потребують зміни атрибутів залежно від умов, станів та етапів процесу. Якщо це не враховується, система тривожної сигналізації приречена на переповнення тривог. Крім того, у звичайних системах тривожної сигналізації дані та записи тривоги зазвичай фіксують календарний час. Для інформативності журналів тривог для Batch процесів більш важливим є відносний час, тобто час від початку партії або кроку процесу. У цьому випадку особливістю прогресивних методів є можливість фіксувати календарні відмітки часу початку кроку або етапу партії і виводити тривоги відносно цього часу. Слід також враховувати, що такі виробництва часто потребують прив’язки записів тривог до номера партії. У такому випадку при виборі номера партії можна вивести усі записи тривог та повідомлення, які відбувалися під час виготовлення продукту.

Крім того, у звичайних системах тривожної сигналізації дані та записи тривоги зазвичай фіксують календарний час. Для інформативності тривог для Batch процесів важливішим є відносний час, тобто час від початку партії або кроку процесу. У цьому випадку особливістю прогресивних методів є можливість фіксувати календарні відмітки часу початку кроку або етапу партії і виводити тривоги відносно цього часу. Крім того, такі виробництва часто потребують прив’язки записів тривог до номера партії. У такому випадку при виборі номера партії можна вивести усі записи тривог та повідомлення, які відбувалися під час виготовлення продукту (рис. 13).

Деякі методи ґрунтуються на змінах атрибутів одних тривог від стану інших. До таких належать першо-причинні тривоги (first-out alarms) – тривоги, що визначаються першими для виведення їх як причини виникнення у випадку виникнення послідовності тривог.

До прогресивних методів належить також керування тривогами на базі моделей (Model-based alarming), які можуть бути використані в тих областях, де потрібна складніша система сповіщення про тривогу, наприклад:

Рис. 13. Приклад відображення дисплею тривог, сформованих за ідентифікатором партії BatchID

У віддалених системах тривожної сигналізації (remote alarm system) оператор не перебуває безпосередньо в пункті керування. У таких системах для відправлення повідомлень може використовуватися пейджинговий зв’язок, SMS-оповіщення, електронна пошта тощо. У віддалених системах тривожної сигналізації важливою проблемою є надійність доставки повідомлень. Для підвищення надійності слід використовувати періодичні тестові повідомлення, може також виявитися необхідним забезпечити віддалене підтвердження. Зокрема, система може передбачати після відправки SMS додзвон до оператора і очікування взяття трубки з передачею голосового повідомлення. Якщо оператор не піднімає трубку, додзвон може відбуватися іншому оператору.

Якщо основна система тривожної сигналізації не може забезпечити виконання необхідного функціоналу, стандарт передбачає використовувати додаткові системи тривожної сигналізації (Supplementary alarm systems), наприклад, експертна система.

10. Події

У першому розділі зазначалося, що окрім тривог, засоби SCADA/HMI мають можливість вести журнал подій. Подія(Event) – це штатна зміна значення змінної або виконання команди. Події, за великим рахунком, не потребують означення автомату стану, або точніше, там є два стани: виникнення події і відсутність події. Факт виникнення події потребує фіксації в журналі або у вікні подій.

Деякі засоби SCADA/HMI не підтримують події, що призводить до певних незручностей. Виходом із такої ситуації може стати використання тривоги. Припустимо, необхідно в такому засобі фіксувати в журналі подію включення певного двигуна. Однак тривога, за означенням, повинна підтверджуватися оператором, що в даному випадку не потрібно і може призвести до затоплення тривог. Припустимо, що система підтримує непідтверджувані тривоги, тобто ті, які мають всього два стани: є тривога і немає тривоги. З першого погляду, це дуже схоже до функціоналу підсистеми подій. Однак у журналі (тривог) будуть фіксуватися дві події, а не одна: тривога виникла і тривога зникла. Ці два записи тільки заплутують оператора при аналізі журналу тривог та подій.

Для перегляду подій у засобах SCADA/HMI можуть бути передбачені як окремі переглядачі, так і суміщені з переглядачами тривог.

Контрольні запитання

  1. Поясніть важливість стандартів на розроблення підсистем тривожної сигналізації.

  2. Які міжнародні стандарти є базовими для розроблення систем тривожної сигналізації?

  3. Що таке тривога? Як оператор може дізнатися про тривогу?

  4. Що таке система тривожної сигналізації відповідно до означення ISA-18.2/IEC 62682? Чому людина є частиною цієї системи?

  5. За рис. 1 поясніть взаємодію системи тривожної сигналізації з іншими системами.

  6. Яку роль у системі тривожної сигналізації відіграє оператор?

  7. В які етапи проходить ідентифікація нештатної ситуації та проведення коригуючих дій оператором?

  8. Які людські фактори впливають на здатність оператора виконувати свої функції?

  9. Поясніть, що таке переповнення тривог. Наведіть приклади.

  10. Які функції формують тривоговий контур?

  11. Поясніть, що таке автомат станів тривоги. Чому важливо зосереджуватися на автоматі станів при розробленні та експлуатації систем керування?

  12. Поясніть призначення кожного стану з автомату станів тривог та умови переходів між станами.

  13. Розкажіть про призначення та поведінку тривог у станах блокування.

  14. Прокоментуйте діаграму поведінки тривоги в часі, яка показана на рис. 6.

  15. Яке призначення затримки на включення тривоги? Покажіть на прикладі однієї з програм SCADA/HMI, де вона задається.

  16. Яке призначення зони нечутливості тривоги? Покажіть на прикладі однієї з програм SCADA/HMI, де вона задається.

  17. На що вказує тип тривоги? Покажіть на прикладі однієї з програм SCADA/HMI, які типи тривоги підтримуються.

  18. Назвіть кілька типів тривог та поясніть, за якими умовами вони спрацьовують.

  19. Для чого використовуються класи тривог?

  20. Для чого використовуються групи тривог? Покажіть на прикладі однієї з програм SCADA/HMI, як можна групувати тривоги.

  21. Для чого використовуються пріоритети тривог?

  22. Які атрибути повинні містити тривоги?

  23. Наведіть приклади, коли атрибути тривог повинні змінюватися під час роботи.

  24. Які можливості повинен надавати HMI для користувачів?

  25. Які засоби HMI відповідно до стандарту ISA-18.2 повинні надаватися для реалізації функцій тривог?

  26. Що таке запис тривоги? Які атрибути повинен містити запис тривоги?

  27. Які рекомендації даються в стандарті ISA-18.2 щодо проведення оповіщення для різних станів тривог?

  28. Які рекомендації даються в стандарті ISA-18.2 щодо використання миготіння та блимання для тривог?

  29. Які рекомендації даються в стандарті ISA-18.2 щодо використання звукового сповіщення для тривог?

  30. Які рекомендації даються в стандарті ISA-18.2 щодо використання кольору та додактових символів для тривог?

  31. Які дисплеї тривог використовуються для системи тривожної сигналізації? Покажіть на прикладі однієї з програм SCADA/HMI, які типи дисплеїв тривог підтримуються.

  32. Яке призначення дисплея зведення (списку) тривог? Перерахуйте функції, які він повинен надавати.

  33. Яке призначення дисплея журналу тривог? Перерахуйте функції, які він повинен надавати.

  34. На прикладі однієї з програм SCADA/HMI покажіть, яким чином і в якому вигляді можна переглянути журнал тривог? Яка саме інформація може бути доступна для перегляду?

  35. Як рекомендується показувати тривоги на дисплеях процесу? Покажіть на прикладі однієї з програм SCADA/HMI, як це можна реалізувати.

  36. Розкажіть про призначення фільтрів у переглядачах тривог та подій? Покажіть на прикладі однієї з програм SCADA/HMI, як це реалізовано.

  37. Яке призначення дисплеїв блокованих тривог? Перерахуйте функції, які вони повинні надавати.

  38. Навіщо потрібні методи прогресивного керування тривогами? Які методи прогресивного керування тривогами Ви знаєте?

  39. Навіщо потрібні методи розширеного керування тривогами? Які методи розширеного керування тривогами Ви знаєте?

  40. Які особливості керування тривогами необхідно враховувати для порційних (Batch) виробництв?

  41. У чому особливість подій порівняно з тривогами? З якими труднощами може зустрітися розробник при реалізації подій у вигляді тривог?

Список використаних джерел

  1. J. Bacon. The costs to Britain of workplace accidents and work-related ill health in 1995/96. Richmond, USA. HSE Books, 1999.

  2. Out of control: Why control systems go wrong and how to prevent failure [Електронний ресурс]. Доступно: http://www.hse.gov.uk/pubns/books/hsg238.htm..

  3. International Organization for Standardization(1999). ISO 11064-3:1999, Ergonomic design of control centres – Part 3: Control room layout [Електронний ресурс]. Доступно: https://www.iso.org/standard/19044.html

  4. Control room management. [Електронний ресурс]. Доступно: https://www.law.cornell.edu/cfr/text/49/195.446.

  5. Functional Safety and IEC 61508. [Електронний ресурс]. Доступно: https://www.iec.ch/functionalsafety/.

  6. PAS and EPRI publish Alarm Management Applications Guidelines. [Електронний ресурс]. Доступно: https://www.automation.com/library/resources/pas-and-epri-publish-alarm-management-applications-guidelines.

  7. The International Society of Automation. (2016). ANSI/ISA-18.2-2016, Management of Alarm Systems for the Process Industries [Електронний ресурс]. Доступно: https://www.isa.org/products/ansi-isa-18-2-2016-management-of-alarm-systems-for

  8. PAC Framework V1.02. Функціональний каркас для розроблення прикладного програмного забезпечення для промислових контролерів [Електронний ресурс]. Доступно: https://github.com/pupenasan/PACFramework

  9. O. Pupena, R. Mirkevich, O. Klymenko and V. Polupan. Development of the framework for the controllers of the process base management system to meet the requirements for integration with other subsystems and to implement service functions and diagnostics service. Енергетика і автоматика. № 4, p. 78-89, 2017.

  10. O.Pupena, I. Elperin, R. Mirkevich and O. Klymenko. Computer integrated manufacturing: overview of modern standarts. Automation of technological and business processes. №8, p. 63–74, 2017.

  11. Alarm management challenge 5: keeping an overview and finding specific alarms. [Електронний ресурс]. Доступно: https://www.copadata.com/download/4/46/18a8dce0-1e0b-471a-8a19-5983bbcdac86

  12. B. Hollifield, E. Habibi. The Alarm Management Handbook. Houston, USA. PAS, 2010. [Електронний ресурс]. Доступно: https://www.amazon.com/Alarm-Management-Handbook-Bill-Hollifield/dp/0977896927/ref=sr_1_1?keywords=The+Alarm+Management+Handbook&qid=1567846650&s=digital-text&sr=1-1-catcorr

Теоретичне заняття розробив Олександр Пупена.