Статті‎ > ‎

Тлумачення та застосування стандарту по організації роботи тривог ANSI/ISA 18.2

опубліковано 23 трав. 2019 р., 03:14 Александр Пупена   [ оновлено 23 трав. 2019 р., 04:36 ]

Bill Hollifield, PAS Principal Alarm Management and HMI Consultant

Переклад: Альона Шишак (АКТСУ НУХТ), Олексанр Пупена (АКТСУ НУХТ)

Посилання на оригінал білої книги

Загальний огляд

За останні роки тема організації роботи тривогових систем стала предметом огляду у багатьох статтях, книгах  та на технічних симпозіумах. У 2003 році ISA розпочала розроблення стандарту по організації тривогових систем. Десяток, залучених  з різних промислових секторів, учасників робочої групи витратили десятки годин на формування стандарту. PAS приймав участь в цьому процесі як редактор та голосуючий член.

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

ISA-18.2 трохи відрізняється від "звичайних" ISA стандартів.  Цей стандарт не про вибір комунікаційних протоколів для взаємодії обладнання і не про проектування окремих компонентів керування. Цей стандарт про робочий процес саме людей. Організація роботи тривогових систем відповідає не за обладнання та програмне забезпечення, а обумовлює певний робочий процес. Тривогові системи, що функціонують неправильно не створюють самі себе. ISA-18.2 - це загальний стандарт, розроблений на основі методів, заснованих на відкритості, балансуванні інтересів, належному процесу та консенсусу. Такі компоненти вказують на те, що цей стандарт з нормативної точки зору є «визнаною та загальноприйнятою хорошою інженерною практикою».

У цій білій книзі розглянуті найбільш важливі аспекти, вимоги, рекомендації та інше, що стосується  ISA-18.2. Проте, цей документ не може замінити повну версію стандарту для цілковитого його розуміння.

1. Ціль та сфера застосування

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

Існує декілька розповсюджених неправильних уявлень щодо стандартів. Стандарти навмисно описують мінімально з того, що є загальноприйнятим, але при цьому не оптимальним. У стандартах навмисне приділяється увага тому «Що робити», однак вони не мають детального керівництва «Як робити». ISA-18.2 не включає приклади конкретних перевірених методологій чи детальних практичних реалізацій. Стандарт фокусується  на вимогах до робочого процесу («повинні») та на рекомендаціях («рекомендується») для ефективної організації роботи тривогових систем.

Читачі, які ознайомленні з літературою по організації тривогових систем не повинні очікувати якоїсь значно нової інформації, або такої що значно відрізняється від уже загальноприйнятої. Ключовою відмінністю є те, що ISA-18.2 – це стандарт, розроблений відповідно до ANSI методологій. Таким чином, він буде розглядатися нормативними органами як «визнана і загальноприйнята хороша інженерна практика» (RAGAGEP). Цей стандарт  знаходиться в процесі прийняття як міжнародного стандарту IEC (IEC 62682) (У 2014-му році стандарт був прийнятий. Прим. перекладача).

2. Чи слід саме Вам застосовувати ISA-18.2 ?

У центрі уваги ISA-18.2 є підсистеми тривог сучасних систем керування, таких як DCS, SCADA, PLC або систем безпеки. Стандарт впроваджується на виробництвах, де оператори реагують на сигнали тривог, які відображаються  на екранах комп'ютерного типу та/або сповіщувачах.

До таких виробництв належать:

  • нафтохімічне
  • хімічне
  • очисне
  •  електростанції
  • фармацевтичне
  • гірничодобувне

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

У розробленні стандарту ISA-18.2 брало участь багато представників різних промислових секторів.  Результатом стало те, що стандарт є прийнятним для різних промисловостей.

Стандарт ISA-18.2 вказує на межі тривогової системи відносно термінів, що використовуються в інших стандартах, таких як Базова система керування процесами (BPCS), система безпеки (SIS) і т.д. Перераховано декілька виключень, щоб не суперечити  іншим стандартам.

3. Регулятивний вплив

Ця біла книга не має на меті бути деталізованим тлумаченням таких регулятивних документів, як керування з охорони праці  (OSHA), Агентства з охорони навколишнього середовища США (EPA), Керування з безпеки трубопроводів і небезпечних матеріалів (PHMSA) або інших нормативних актів. Нормативне середовище є складним та поширюється на деякі промислові сегменти. Багато виробництв урегульовуються документом «Керування безпекою процесу» оприлюдненим OSHA , в якому є кілька згадувань про тривоги.  

Важливим є те, що регулятивні органи включають в свої нормативні документи пункти «загального призначення». Як приклад, розглянемо OSHA 1910.119 (d) (3) (ii), в якому стверджується, що роботодавець зобов'язаний документувати, що обладнання відповідає прийняті і загальновизнані належні інженерні практики (RAGAGEP).

Стандарти та практики, як правило, вважаються «прийнятими і загальновизнаними належними інженерними практиками». В роз’яснювальному листі OSHA до ISA, ISA-18.2 є RAGAGEP. Існує “Меморандум про домовленність” між OSHA і ANSI з цих питань.

В загальному, регульовані сектори промисловості можуть очікувати перевірки на відповідність прийнятим і загальновизнаним належним інженерним практикам (RAGAGEP) або показати,  що вони роблять щось так само добре або краще. Насправді,  OSHA  отримали дозвіл від ISA поширювати ISA-18.2 стандарт серед OSHA спостерігачів. Рада з розслідування хімічної безпеки і небезпеки США також буде використовувати ISA 18.2 у своїх розслідуваннях. Інші регуляторні органи також беруть до уваги цей стандарт.

Американський інститут нафти (API) скоро опублікує API RP-1167, Alarm Management Recommended Practices for Pipeline Systems. Цей документ API повністю узгоджується з ISA-18.2, а адміністрація з безпеки нафтопроводу та небезпечних матеріалів (PHMSA) зазвичай застосовує рекомендовану API-практику в своїй нормативній мові.

4. Наслідування

Пункт наслідування використаний іншими ISA стандартами , також використаний і в ISA-18.2.

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

Два згадування слова «повинні» у цитованому тексті позначають обов’язкові для виконання вимоги. Ця цитата імітує мову, використовувану в положеннях OSHA.

5. Означення в ISA-18.2

Для того, щоб забезпечити сумісність ISA-18.2 з іншими стандартами та нормативами було проведено велику кількість роботи по дослідженню та розробці означень. Стандарт ISA-18.2 означує тривогу як «Звукові та/або візуальні засоби індикації про несправність устаткування, відхилення від процесу, ненормального режиму роботи, які потребують реакції оператора»

6. Діаграма автомату станів тривог

Стандарт ISA-18.2  включає в себе помірно складну діаграму, що відображає стани та підстани тривог: «Нормальний стан», «Неквітована» (unacknowledged), «Підтверджена» («acknowledged»), «Повернена до нормального стану але не квітована» («returned to normal unacknowledged») та «Тривоги з фіксацією» («Latched»). (У новій версії стандарту в автоматі станів немає означений станів «Latched». Прим. перекладачів)  Окремої уваги заслуговують стани «Відтермінована тривога» (“Shelved”), «Проектно-блокована тривога» (“Suppressed by Design”) та «Виведена з обслуговування» (“Out of Service”). Ці стани мають специфічні значення:

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

Проектно-блокована тривога – це тривога навмисне блокована системою керування відповідно до алгоритму керування.

Виведена з обслуговування – це не функціонуюча тривога. У цей стан тривога зазвичай переходить внаслідок причин пов’язаних зі стадією обслуговування. Під час виведення тривоги з обслуговування також дотримуються адміністративних вимог як у випадку з відтермінованою тривогою.

Терміни «блокувати» («suppress») і «блокування тривоги» навмисне є загальними, а не специфічними для типу DCS. Вони використовуються у випадках, коли треба вказати, що тривога не буде сигналізуватися. Можливо, і, на жаль, є загальноприйнятим, блокування  тривоги поза належною практикою роботи, і виявлення таких небажаних ситуацій є частиною стадії моніторингу життєвого циклу.

7.Життєвий цикл організації роботи тривогової системи


рис.1.Життєвий цикл керування тривогами.

Стандарт ISA-18.2  означує структуру життєвого циклу, який включає 10 стадій:

  • Методологія тривог (alarm Philosophy): документує цілі тривогової системи та робочі процеси, які супроводжують досягнення цих цілей.
  • Ідентифікація (Identification): робочі процеси по означенню необхідних тривог.
  • Раціоналізація (Rationalization): процес підтвердження відповідності тривог поставленим в методології тривог вимогам. Ця стадія також включає задачі пріоритизації, класифікації, означення налаштувань тривог та документації.
  • Проектування(Detailed Design): відповідно до вимог, означених на стадіях раціоналізації та методології тривог проводиться процес проектування тривогової системи в цілому. На цій стадії приймаються рішення щодо відображення тривог на HMI, а також використовуються спеціальні техніки проектування тривог.
  • Впровадження(Implementation): розроблена тривогова система переводиться в операційний статус. Ця стадія може включати введення в експлуатацію, тестування та тренування персоналу.
  • Експлуатація (Operation): функціонування тривогової системи. Ця стадія також може включати підвищення кваліфікації персоналу.
  • Обслуговування(Maintenance): на даній стадії тривога не функціонує за причини тестування або налагоджувальних робіт.  Цю стадію не слід плутати з життєвим циклом обслуговування обладнання і їх функцій.
  • Моніторинг та оцінка (Monitoring and Assessment): Продуктивність роботи тривогової системи постійно моніториться та оцінюється відповідно до вимог, означених у документі методології тривог.
  • Керування змінами(Management of Change): відповідно до означених правил вносяться зміни до тривогової системи.
  • Аудит(Audit): проводиться періодична перевірка системи для підтримки цілісності тривогової системи і процесів організації її роботи.

7.1. Стадії життєвого циклу проти діяльностей

Не потрібно плутати стадії життєвого циклу з діяльностями. Життєвий цикл це спосіб структурування змісту усього стандарту ISA-18.2. Життєвий цикл не є конкретним або обов’язковим списком діяльностей, які необхідно провести  у означеному порядку.

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

Стадія моніторингу:  Інженер:  «Ну добре, виділю собі трохи часу на визначення хибних тривог. Які тривоги найчастіше зустрічаються у списку тривог?  Є одна така – тривога високого тиску у колоні»

Стадія Ідентифікації: Інженер: «Ах так, я пам’ятаю, що нам потрібна ця тривога для забезпечення якості; проте моя задача на сьогодні зробити так щоб ця тривога працювала правильно, а не вирішити чи взагалі потрібна нам ця тривога чи ні»

Стадія проектування: Інженер: «Перевірю налаштування цієї тривоги. Немає нічого незвичного. Хммм, я бачу, що зона нечутливості для тривоги дорівнює 0. Це точно неправильно і спричинює таку «вібруючу» поведінку тривоги. Передивлюся історію тривог і визначу найбільш підходящу зону нечутливості, користуючись хорошою книгою по організації роботи тривог»

Стадія експлуатації і обслуговування: Інженер: «Зараз я збираюся змінити налаштування зони нечутливості»

Стадія керування змінами: Інженер: «Поки що я нічого не змінив. Перед тим як я внесу зміни у налаштування зони нечутливості, я подумки переглядаю вимоги щодо керування змінами. Такий тип змін передбачений документом методології тривог і я маю повноваження внести такі зміни. Мені не потрібна згода інших уповноважених та якісь підписи. Однак, мені потрібно буде внести відповідний запис у головну базу даних тривог.

Стадія впровадження: Інженер: «Зараз я фактично змінюю зону нечутливості. Увожу нове значення та натискаю ‘ENTER’. Зроблено!»

Стадія раціоналізації: Інженер: «Оскільки у мене є належний доступ до безпеки, я додам цю нову настройку зони нечутливості до головної бази даних тривог, вказавши своє ім'я, дату та причину. Крім того, я зроблю примітку у щотижневому звіті по відстеженню хибних тривог. Поки я тут і дивлюся на цю тривогу,то зауважу, що вона налаштована з пріоритетом 3. Це здається розумним, але про всяк випадок перевірю головну базу даних тривог, щоб переглянути причини встановлення такого пріоритету. Хмм, вони виглядають досить добре. Якби цього не було, я б не міг самостійно змінити пріоритет. Мені потрібні спеціалісти, які займаються пріоритизацією. Операторів необхідно повідомляти про будь-які зміни пріоритету»

Стадія моніторингу: Інженер: «До моїх обов’язків входить слідкувати за даними тривоги, і переконатися в тому що зміна зони нечутливості була рішенням проблеми виникнення хибної тривоги»

За кілька хвилин для вирішення однієї задачі виконалось кілька стадій життєвого циклу. Для розуміння та застосування ISA-18.2, особливо не намагайтеся з'ясувати, на якому етапі життєвого циклу Ви перебуваєте в будь-який момент часу. Це структура вимог, а не означена послідовність робочого процесу.

В 2006 році, PAS опублікував «The Alarm Management Handbook», в якій пропонується визнана семи-крокова методологія для вирішення проблем функціонування тривогової системи та для досягнення ефективної організації роботи тривогової системи. Між таким семи-кроковим підходом та методологією, яка викладена у стандарті немає конфліктів; можливі відмінності  в переліку та постановці задач.

8. Стадія формування документу методології тривог

Стандарт ISA-18.2 визнає документ методології тривог ключовою вимогою для ефективної організації роботи тривогової системи. Документ методології тривог обов’язково повинен включати посадові обов’язки, означення тривоги, обґрунтування пріоритизації, керівництво для розробки HMI, показники ефективності функціонування тривогової системи, керування змінами, навчання персоналу та інше.

У стандарті не зустрічається значно нових термінів окрім «класифікація тривог» та «високоорганізовані тривоги» («highly managed alarms»).

8.1. Класифікація тривог

Класифікація тривог - це метод призначення та відстеження різних вимог до тривог, переважно адміністративних. Наприклад, деякі тривоги можуть вимагати періодичної перепідготовки персоналу, а інші - ні. Те ж саме стосується тестування, технічного обслуговування, звітності, відображення на HMI та подібних аспектів. Класи тривог використовують для відстеження цих вимог. За ISA-18.2 класи тривог необхідно означити обов'язково.

Це трохи незвична річ для стандартів. Зазвичай стандарт говорить про те, що робити, а не про те, як це робити, і не вимагає використовувати конкретний метод. Наприклад, у стандарті може стверджуватися: «Визначте та відслідковуйте тривоги, які вимагають періодичного тестування». Існує велика кількість методів, щоб успішно це реалізувати, і  класифікація – це тільки один з них. Проте комітет вирішив вимагати класифікаційну структуру, хоч вона і не повинна бути обтяжливою. Стандарт не наводить конкретних вимог до класів та не вказує мінімальну їх кількість. PAS рекомендує використовувати просту структуру класів з мінімальними варіаціями.

8.2. Високоорганізовані тривоги

Комітет вважав за необхідне чітко означити один клас тривог. Було розглянуто велику кількість різних назв означень, від «критичний» до «життєво важливого», «спеціального» та «супер-пупер». Назвою такого класу було обрано «Highly Managed Alarms» (високоорганізовані тривоги). Мета полягає в тому, щоб означити тривоги, до яких ставляться адміністративні вимоги високого рівня.

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

У декількох розділах стандарту ISA-18.2 згадуються різні обов'язкові вимоги до високоорганізованих тривог. До них відносяться:

  • Специфічні вимоги до блокування тривоги, наприклад, контроль доступу з відслідковуванням та реєстрацією подій, пов’язаних з тривогою (audit trail)
  • Специфічні вимоги до «виведення з обслуговування тривоги», такі як тимчасовий захист, контроль доступу, та реєстрація подій
  • Обов’язкова первинна підготовка та перепідготовка персоналу
  • Обов’язкове первинне та періодичне тестування
  • Обов'язкове навчання щодо вимог до технічного обслуговування
  • Обов’язкові вимоги до аудиту

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

9. Специфікація технічних вимог до тривогової системи (ASRS)

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

У такому випадку ASRS стає корисним документом для тестування та приймання.

10. Стадія ідентифікації

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

У деяких випадках можна використати один з цих доступних типів, у інших – необхідне створення специфічної тривоги з програмною логікою обробки або розрахунками. Це робиться з індивідуальних міркувань і може залежати від технологічного процесу. Такий тип тривоги може сторцюватися на основі  аналізу технологічних ризиків (PHA), аналізу рівня захисту (LOPA), аналізу збоїв та їх вплив (FMEA) і т.п.

11. Стадія раціоналізації

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

До діяльностей належать:

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

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

Цей розділ є достатньо коротким і навмисне уникає опису конкретних методів ефективної раціоналізації. Деякі приклади таких методів будуть наведені в майбутніх технічних звітах.  (Ці технічні звіти вже випущені. Прим. перекладачів)

12. Стадія базового (основного) проектування

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

13. Стадія розроблення людино-машинного інтерфейсу

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

У стандарті наводяться деякі аспекти:

  • Відображення станів тривог, пріоритетів і типів
  • Вимкнення сигналів тривог та їх підтвердження
  • Блокування тривог
  • Функціональність дисплею зведення тривог
  • Функціональність інших дисплеїв тривог
  • Звукові сигнали тривог
  • Інформація про тривоги та повідомлення
  • Сповіщувачі

Багато функціональних аспектів вказані як обов'язкові або рекомендовані. Основними обов'язковими елементами є конкретні зображення різних ситуацій (умов), пов'язаних з тривогами, а також спеціальні екрани HMI та їх функціональні можливості. Такі елементи зазвичай знаходяться в межах можливостей більшості сучасних систем керування. На початку розділу стандарту зазначено, що деякі описані функції не є доступними в деяких системах керування. Проте ваша тривогова система все ще може відповідати стандарту.

Я думаю, що стандарт ISA-101 про HMI випуститься через кілька років. Можливо це буде технічний звіт, а не стандарт. Тим часом, якщо ви хочете отримати більш детальну інформацію про підходи до розроблення HMI, ми рекомендуємо звертатися до книги The High Performance HMI Handbook, а також ASM Consortium Guidelines for Effective Operator Display Design. (Стандарт ISA-101 був випущений в 2015-му році. Прим. перекладача)

14. Покращені та вдосконалені (прогресивні) методи організації тривог

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

До таких типів прогресивних  методів, які коротко описані у стандарті, належать наступні:

  • Інформаційні зв’язки
  • Організація тривог на основі логіки керування
  • Організація тривог на основі моделі процесу
  • Зміни атрибутів тривог
  • Зовнішньо підтримувані системи
  • Логічне блокування або зміна атрибутів тривог
  • Організація тривог у відповідності зі станом ТП
  • Організація тривог у відповідності зі станом ТП на основі його моделі
  • Віддалені сповіщення тривог (не на АРМ)
  • передача сигналів тривог по електронній почті і віддалені системи сповіщення
  • Додаткові тривогові системи
  • Постійна зміна меж уставок тривог
  • Тривоги в Batch процесах
  • Системи навчання, тестування та перевірки (аудиту)
  • Постійне спостереження за налаштуваннями тривог

15. Стадія впровадження

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

До основних діяльностей належать:

  • Планування
  • Навчання користуванню новими системами чи внесеними до них змінами
  • Тестування та функціональна перевірка нових систем або модифікацій
  • Документування навчання та тестування

16. Стадія експлуатації

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

  • Процедура реагування на тривогу
  • Блокування тривог
  • Перепідготовка операторів

17. Стадія обслуговування

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

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

18. Стадія моніторингу та оцінки

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

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

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

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

Показники описані у стандарті:

  • Аналіз кількості виникнення(активації) тривог за операційний період (за день, за годину, за 10 хвилин)
  • Пікова кількість виникнення тривог за операційний період
  • Потоки тривог (методи розрахунку і рекомендації)
  • Частота виникнення тривог
  • Вібруюча та швидкоплинна тривоги
  • Застарілі тривоги
  • Розподіл пріоритетів тривог
  • Несанкціоноване подавлення тривоги
  • Моніторинг параметрів тривог

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

19. Стадія керування змінами

Цей розділ наводить обов'язкові вимоги та необов'язкові рекомендації щодо внесення змін у тривогові систему.

Пункти, описані у стандарті:

  • Зміни, які підпорядковані керуванню змінами
  • Вимоги до процесу перегляду змін, включаючи розгляд технічної бази, впливу внесених змін, процедуру та документування змін, авторизації для внесення змін
  •  Підтвердження відповідності змін вимогам наведеним у документі методології тривог
  • Тимчасові зміни
  • Впровадження змін
  • Вимоги та рекомендації до документування змін
  • Рекомендації до видалення тривог
  • Вимоги та рекомендації до змін параметрів тривог

20. Стадія аудиту

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

21. Висновки.

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

 

Післямова (від перекладачів)

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

На сьогоднішній день ISA-18.2 вже існує в 2-й редакції. Крім того, цей стандарт прийнятий також як IEC 62682, що робить його застосовним у всьому світі, у тому числі це може бути зроблено в Україні (завдання для комітету ТК-185).  Крім ISA-18.2 вийшло ряд технічних звітів, які деталізують окремі стадії та етапи життєвого циклу організації тривогової системи:

·         ISA-TR18.2.1-2018 - Alarm Philosophy

·         ISA-TR18.2.2-2016 - Alarm Identification and Rationalization

·         ISA-TR18.2.3-2015 - Basic Alarm Design

·         ISA-TR18.2.4-2012 - Enhanced and Advanced Alarm Methods

·         ISA-TR18.2.5-2012 - Alarm System Monitoring, Assessment, and Auditing

·         ISA-TR18.2.6-2012 - Alarm Systems for Batch and Discrete Processes

·         ISA-TR18.2.7-2017 - Alarm Management When Utilizing Packaged Systems

Ми сподіваємося, що ця біла книга спонукатиме спеціалістів з автоматизації принаймні ознайомитися з стандартом ISA-18.2. Окрім того, важливим стандартом також є ISA-101, який направлений на розробку та експлуатацію ЛМІ. По темі SCADA/HMI також доступні наступні матеріали українською мовою: відео вебінару від PAS, який був перекладений та озвучений в стінах кафедри АКТСУ та матеріали ТДА. На даний момент йде підготовка навчального посібника по SCADA/HMI, куди окремим розділом увійде Alarm Management.

   

 

 

 

 

 

 

 

 

 

 

Comments