Статті

Тлумачення та застосування стандарту по організації роботи тривог 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.

   

 

 

 

 

 

 

 

 

 

 

Перепрошивка TSX Premium з PL7 PRO на Unity PRO (відео)

опубліковано 3 лист. 2018 р., 11:18 Александр Пупена

Після оновлення лабораторної бази Шнейдер Електрик, відпала необхідність у старому програмному забезпеченні PL7 PRO, що використовувалися для програмування ПЛК TSX Micro та TSX Premium. Хоч обладнання 90-х ніхто не збирається утилізовувати :) (нам ще й старенькі TSX Nano в нагоді ставали), деякий хард 2000-х, а саме TSX Premium ще може згодитися для навчального процесу. Було вирішено два ЦПУ TSX Premium перепрошити під сучасний софт Unity PRO (щоб робочих стало чотири замість двох).

Сказано – зроблено! Дмитро Мацебула взявся за справу, а Володимир Полупан взявся за документування цього процесу. Що з цього вийшло – дивіться на відео! Може комусь знадобиться, може у вас теж завалявся подібний TSX Premium.    

 

Керування періодичними процесами та виробництвами на базі сучасних технологій та стандартів (ISA-88)

опубліковано 12 січ. 2017 р., 22:32 Александр Пупена

Доступні відеоматеріали та презентації з семінара-конференції ТДА16-2, який проходив 1.10.2016 в НУХТ.
За цими матеріалами можна отримати багато інформації щодо керування періодичними (batch) виробництвами.  

Індустрія 4.0 – 4-та Індустріальна Революція

опубліковано 9 бер. 2016 р., 23:53 Александр Пупена   [ оновлено 9 бер. 2016 р., 23:54 ]

На Світовому Економічному Форумі 2016 в Давосі оголосили: «Четверта Індустріальна Революція» розпочалася. Німецький Уряд заявив: «Arbeiten, громадяни, будуємо Індустрію 4.0!». А американці і різного роду стартапери вже декілька років стверджують, що настає ера «Інтернету всього на світі». Китайці стверджують: «де криза, там і можливості». Спробуємо розібратись в темі і пошукати можливості для українських інженерів і бізнесу.
Читати далі

Електронний посібник по стандарту ISA S88.01

опубліковано 5 січ. 2016 р., 07:30 Александр Пупена

Сьогодні інтегроване виробництво не може обійтись без знань міжнародних стандартів, в яких відображаються кращі практики проектування, створення та експлуатації таких систем. Серед таких стандартів для систем MES дуже актуальними є ISA-88 та ISA-95.
Вашій увазі пропонується переклад електронного посібника (теж в електронному вигляді) з назвою "S88.01 Tutorial", в якому доступною мовою розповідається про основи стандарту ISA S88. Переклад зроблено співробітником нашої кафедри.
 
Приємного чтива!
 
 

Навчання інженерів з автоматизації та управління з використанням комбінованих практичних, дистанційних та віртуальних лабораторій

опубліковано 10 груд. 2015 р., 11:04 Александр Пупена

(за матеріалами статті C. Pereira, S. Paladini, F.M. Schaf "Control and Automation Engineering Education: combining physical, remote and virtual labs" // Systems, Signals and Devices (SSD), 2012 9th International Multi-Conference on)
Переклад та адаптація: Олександр Пупена

1. Вступ

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

2. Практичні, імітаційні, дистанційні, віртуальні та віртуально-світові лабораторії (та інші)

    Для інженерної та ІТ освіти лабораторні роботи мають дуже велике значення. На сьогоднішній день доступна велика кількість технологій, що дозволяють будувати багато різних типів лабораторій. Термінологія, яка використовується для назв цих типів лабораторій відрізняється в різних джерелах. Тим не менше можна умовно виділити наступні типи лабораторій, в залежності від особливостей реалізації об’єкта дослідження:
  • практичні (реальні) локальні лабораторії;
  • практичні віддалені (дистанційні) лабораторії;
  • імітаційні локальні лабораторії;
  • імітаційні дистанційні лабораторії;
  • комбіновані лабораторії;  
    Практичні лабораторні роботи, і відповідно лабораторії, виділяються наступними особливостями:
  1. в лабораторії повинно бути встановлене фізичне обладнання;
  2. студенти, що виконують лабораторні роботи фізично присутні в лабораторії.
    Обидві характеристики дають свої недоліки: високі витрати для встановлення, експлуатації та обслуговування реального фізичного обладнання, які можуть використовуватися тільки на обмежену кількість студентів, як із-за обмежень в просторі лабораторії, так із-за кількості обладнання, яке може одночасно використовуватися. 
    У імітаційних лабораторіях (також називаються віртуальними лабораторіями, або  VLabs) вся інфраструктура, що потрібна для лабораторій не являється реальною, а імітується на комп’ютерах. Для моделювання та імітації поведінки реальних об’єктів та проведення експериментів використовується різноманітне спеціалізоване ПЗ  як MatLab, LabView, Modelica і т.д. Значне збільшення обчислювальної потужності зробила поява багато-ядерних процесорів, графічних процесорів, доступних навіть для університетів в країнах, що розвиваються. Такі комп’ютери дали можливість моделювати і представляти в графічному вигляді складні технологічні процеси в близькому до реального часу.
    Моделювання може проводитися в зменшеному масштабі часу відносно реального для зменшення часу на виконання експериментів. Наприклад для експериментів з управлінням рівнем у великих ємностей може зайняти декілька годин при реальних обставинах, в може бути швидко виконана за допомогою моделювання, залишаючи більше часу на аналізу експериментальних характеристик, наприклад визначення сталої часу, перерегулювання і т.д.  Крім того під час імітаційного експерименту студенти можуть "зупинити час" перейти на крок назад або виконати експеримент по часовим інтервалам, тим самим краще розуміючи його.       
    Зараз у світі існує велика кількість імітаційних лабораторій. Хорошим прикладом віртуальних лабораторій є VCLab, EasyJava (інтегрується з MatLab), SimQuest.       
    Одним з головних недоліків імітаційних лабораторій є те, що вони часто базуються на ідеалізованих моделях, які не повністю відповідають реальному життю. У зв’язку з відмінністю теоретичних моделей та реальних може бути пропущений важливий досвід. Альтернативою імітаційним та практичним лабораторіям є використання віддаленого доступу до реальних лабораторій, тобто дистанційних лабораторій. Від реальних лабораторій їх відрізняє наявна відстані між експериментатором та експериментальним обладнанням. Дистанційні лабораторії стають дуже популярними. Вони надають можливість отримати реальні експериментальні дані в декількох навчальних закладах, розподіляючи фізичні пристрої між ними і надаючи доступ усім. Крім того, в дистанційних лабораторіях можна розширити можливості звичайних лабораторій збільшуючи кількість місць та експериментів в декілька раз, а їх доступність поширюється на більшу кількість студентів.
    Дослідження показують, що студенти являються більш мотивовані до готовності працювати в дистанційних лабораторіях. Деякі студенти вважають, що дистанційні лабораторії більш ефективні ніж імітаційні. На сьогоднішній день навчальні та дослідницькі експерименти присутні в декількох різноманітних областях: управління дискретним виробництвом, аерокосмічні застосування, PID регулювання, прогнозуюче управління, вбудовані комунікаційні системи, потокове відео та аудіо та інші. Є також декілька проектів, в яких ряд закладів об'єднують свої зусилля, щоб зробити дистанційну мережу лабораторій, таких як LabNet, CyberLab, RwmLAB, DSP-based Remote Control Laboratory, DEEDS, NCS Laboratory,  MARVEL, RExNET,  iLabs та інші.
    Хоч на перший погляд концепції практичних, імітаційних та дистанційних лабораторій дуже різні і дещо суперечливі, більш детальний аналіз показує деякі цікаві загальні риси.     Перш за все слід відмітити, що у практичних лабораторіях студенти працюють безпосередньо біля пристрою і неправильна їх експлуатація може потягнути за собою небезпечні ситуації для обладнання, студентів та персоналу. Враховуючи необхідність безпечної експлуатації лабораторних робіт студентами більшість практичних лабораторій для вивчення дисциплін промислової автоматики включають в себе системи безпеки, такі як блокувальні пристрої, автоматичні системи захисту а також віддаленого контролю та супервізорного управління. У деяких випадках студенти можуть взаємодіяти тільки через засоби людино-машинного інтерфейсу (ЛМІ), так що навіть у випадку фізичних експериментів між експериментатором та об’єктом знаходиться комп’ютер.     Нерідко також буває, що такі ЛМІ розміщуються в диспетчерських, аналогічно як і на реальному виробництві, ізольовано від фізичних об’єктів.
    Це приводить до того, що в усіх видах розглянутих вище лабораторій (практичні, імітаційні чи дистанційні) експерименти проводяться опосередковано через комп’ютер, стираючи межі між ними, цим самим роблячи "психологію присутності" більш важливою ніж технологію.
    Враховуючи плюси та мінуси фізичних та імітаційних експериментів, можна побачити що в деякому сенсі вони являються взаємодоповнюючими, так що поєднання обидвох дає додаткові переваги. Імітаційне моделювання, хоч і не є реальним, має деякі особливості, які можуть бути використані в різних навчальних сценаріях. Одна з головних переваг використання імітаційних лабораторій полягає в тому, що вони можуть бути легко повторно відтворені. Студенти можуть використовувати декілька копій (реплікацій) одних і тих саме моделей одночасно. Як вже згадувалося, ще одна перевага використання імітаційного моделювання в тому, що студенти можуть прискорити повільну динаміку систем для швидкої отримання результатів. Крім того, проблеми безпеки виходу імітаційної змінної за межі не так важливі як в фізичному експерименті, так як процес не може зашкодити життю і здоров'ю людини.
    Наявність переваг різних типів експериментів стало мотивацією для створення стратегії взаємодоповнюючих компонентів, яка була розроблена, щоб дозволити поєднання реальних (фізичних) і імітаційних компонентів в навчанні інженерів з автоматизації. Основна ідея передбачає, що студенти, як правило, взаємодіють як з реальним так і імітованим об’єктом через засоби ЛМІ. Таким чином ЛМІ забезпечує тільки відображення стану та опосередковане управління, тому експериментатори не в змозі відрізнити чи працюють вони з реальним обладнанням чи з імітатором. Імітаційні компоненти можуть бути комбіновані з реальним обладнанням для ілюстрації різноманітних навчальних ситуацій. Для прикладу, імітаційне виробництво може використовуватися для оцінки та контролю можливих наслідків спрацювання, уникаючи пошкодження фізичного обладнання, яке могло би відбутися в реальному виробництві у випадку помилок в алгоритмі керування. А імітований регулятор, взаємодіючий з реальним процесом може допомогти краще оцінити поведінку регульованої змінної.     Використання імітованого виробництва разом з імітаційним алгоритмом управління може бути дуже корисним, оскільки змінюючи налаштування швидкості поведінки повільних технологічних процесів можна пришвидшити процеси ідентифікації та параметрування.
    Наведена вище ідея знайшла розвиток в концепції віртуальних лабораторій. Віртуальні лабораторії являють собою середовища розподіленого моделювання, які призначені для виконання інтерактивного моделювання математичних моделей реальних систем, який по суті значить віртуальний доступ до імітаційної лабораторії. По відношенню до цього визначення важливо відмітити, що термінологія, яка використовуються в існуючій літературі не являються послідовною і часто є заплутаною.     У таблиці 1 коротко показані основні характеристики типів лабораторій, які обговорювалися вище.
 

доступ

обладнання

Тип лабораторії

 

локальний

реальне

практичні лабораторії

імітаційне

імітаційні лабораторії

 

віддалений (дистанційний)

реальне

дистанційна лабораторія

імітаційне

віртуальна лабораторія

віддалений або/та локальний

 

реальне/імітаційне

 

взаємозалежні компоненти

    Зовсім недавно були зроблені великі досягнення в таких областях як комп’ютерна графіка, змішана реальність та віртуальна реальність. Віртуальна реальність визначається як "переживання, в якому людина оточена тривимірними комп’ютерно-генерованими представленнями, здатна пересуватися у віртуальному світі і побачити його з різних кутів, щоб досягнути його,  захватити його, і змінити його".
Інше визначення віртуальної реальності як "таке, в якому користувач знаходиться в інтерактивній обстановці що є або реальною з віртуальним розширенням реальності (доповнена реальність) або віртуальною з розширенням фізичними(реальними) засобами (доповнена віртуальність) "
    Базуючись на вищенаведених визначеннях, "змішана або доповнена реальність" визначена як реальний, прямий або непрямий вид практичних лабораторій, де фізичні пристрої доповнені комп’ютерно-генерованими елементами чуттєвого введення звуку, відео, графіки або іншої інформації. Інтерфейси змішаної реальності можуть накладати графіку, відео і аудіо на реальний світ і відображати результат на планшетних та вмонтованих дисплеях з відображенням інформації. З них студенти можуть отримати інформацію про структуру та поведінку обладнання і як на ньому працювати.     Аналогічним чином можна побудувати цифровий макет в 2D та 3D перспективі, для графічного представлення пристрою в віртуальних лабораторіях, що дає можливість графічно представити реальні пристрої їх віртуальними моделями. Приклад гнучкої експериментальної конфігурації є система deriveSERVER.
    Додатково до інших підходів, концепція "відчуття знаходження на місці" може бути широко розширена через занурення користувача в навколишнє середовище. Тобто користувачі повністю бачать себе в лабораторії (відчуття поглинання). Вони вивчають цей віртуальний світ (метавсесвіт) через свої аватари, тому віртуальна присутність приймається всіма користувачами, особливо під час взаємодії. Порівняно з іншими електронними інструментами для дистанційного зв’язку, представлення метавсесвіту покращує почуття знаходження там (в класі), а не бути безтілесним спостерігачем, як в більшості 2D віртуальних середовищах. Прикладами доступного програмного середовища, що може використовуватися для побудови лабораторії віртуальних світів є Second Life, Active Worlds AWEDU, Open Simulator та Open Wonderland. Враховуючи, що за допомогою цих інструментів можна побудувати додатки, аналогічні іграм, але з метою професійного використання (у даному випадку для цілей освіти), вони називаються "серйозні ігри". 
    У цій області є декілька термінів, якими користуються при застосуванні віртуальних світів як платформу для віртуальних лабораторій. Визначення “FutureLabs” використовується для     відношення цієї теми до проекту ScienceSim. Дослідники з університету Деусто і Іспанії використовують  Second Life для побудови «WebLabs», де віртуальні об’єкти зв’язані з програмними утилітами, розроблені для програмування microbot'а (маленького робота). Після програмування робота, користувач може подивитися відео поведінки робота онлайн в Second Life. Вони назвали їх лабораторію як “Second Labs”. В тому ж напрямку MIT дослідники скористувалися реалізацію бувшого Wonderland (тепер Open Wonderland) як розсадник для цілого ряду фізичних експериментів з їх iLabs. Ці реалізації посулговуються  Java-технологіями та їх концепцією TEAL (Technology Enabled Active Learning) для підвищення дидактичності в деяких реалістичних експериментах з фізики.
    Більшість теперішніх реалізацій лабораторій на базі віртуальних світів, змішаної реальності, додаткової реальності і віртуальної реальності покладаються тільки на комп’ютерні медіа–інтерфейси між студентом та лабораторією. Хоч ці інтерфейси мають підвищену здатність генерувати дуже реалістично візуалізацію, вони як правило надають тільки візуальні та звукові зворотні зв’язки, які можуть бути достатніми для деяких застосувань. Однак, в окремих областях навчання, наприклад інженерів з автоматизації або медицині, теж важливі такі почуття як смак, запах, температура, рівновага і прискорення. Це породило розвиток того, що можна назвати "лабораторією множини почуттів", які доповнюють лабораторії на базі віртуальних світів додатковими інтерфейсами, таким як тактильні (дотик), теплові і т.д. Взаємодія може бути зроблена з одним або декількома користувачами на одному і тому ж самому фізичному місці і включають різні почуття.


3. Вбудовування лабораторій в системи електронного навчання (E-LEARNING системи)

 
    Вище розглянута еволюція лабораторій, що активувалася з розвитком ІТ. Однак досвід показав, що наявність цих різних видів лабораторій не являється достатнім для забезпечення успіху у процесі навчання інженерів з автоматизації. Наприклад, дистанційні лабораторні експерименти, стратегія яких базується на методі "спроб і помилок"  без додаткового навчального матеріалу, мають набагато меншу ефективність, ніж очікувалося. Крім того, цілодобова доступність лабораторій також вимагає цілодобової доступності вчителів та тьюторів для забезпечення онлайнової допомоги.     Для того, щоб полегшити ці проблеми, дистанційні експерименти можуть бути інтегровані з віртуальними навчальними середовищами  (VLEs) для управління і надавання навчальних матеріалів до і під час експерименту. Автори [1] вважають, що такі комп’ютерно-підтримувані суміщені середовища (Computer Supported Collaborative Environments CSCEs) для навчання інженерів з автоматизації та керування повинні включати:
- загальну робочу область для освітніх засобів і теоретичних матеріалів модулів – віртуальний простір для розміщення загального навчального матеріалу (як правило виконуються VLEs);
  • 3D соціальний інтерфейс – відповідає за надання можливості користувачу занурюватися у віртуальний всесвіт, що керується середовищем e-learning
  • зворотній зв'язок користувача і адаптація контенту – використовується для створення автоматичного зворотного зв’язку та/або адаптації контенту (навчального матеріалу)
  • інтеграція лабораторії або експериментів з системами електронного навчання (VLEs)
  • система навчання, що включає декілька моделей користувачів і може автоматично дати вказівку (зазвичай називається інтелектуальними системами навчання)
  • підтримка роботи команди та співробітництва між студентами
  • розширення відчуття занурення – використання декількох рівнів систем реагування не тільки зору та слуху а також смаку, температури, балансу і т.д.
  • концепція серйозних ігор – використання ігор-подібних рішень, які захватують увагу і навчають під час розгляду 
    На сьогоднішній день немає такої реалізації системи, яка б інтегрувала усі вказані функції, але є декілька цікавих робіт, які включають дві або більше із цих характеристик і які будуть обговорюватися нижче.    
    Використання віртуальної реальності, як інструменту для навчання було запропоновано і обговорено декількома дослідниками. Інтерфейси комбінованої (змішаної) реальності дозволяють створювати загальні робочі області, які суміщають переваги віртуальних середовищ в контакті з реальним навколишнім середовищем. Накладання інформації використовується для можливості розмови віч на віч, виробництва загальних інтерактивних віртуальних моделей. У цьому випадку методи комбінованої реальності може виробити загальне почуття реальності присутності. Таким чином підходи комбінованої реальності ідеальні для мульти-користувацьких колективних лабораторій та робочих застосунків    
    Майстерність колективного навчання в основному пов’язана з соціально-конструкціоністською педагогічною лінією навчання. Колабораторії (загальний робочий простір) – є добре відомими асоціаціями колективних інструментів з дистанційними лабораторіями (експерементами). Це рішення приносить не тільки підтримку співробітництва, але і сприяє тому, що декілька студентів взаємодіють в одному експерименті.       
    Інтерактивні VLEs є ефективними педагогічними ресурсами, які добре підходять для веб і дистанційної освіти. Їх інтерактивність заохочує студентів грати більш активну роль в процесі навчання і забезпечує реалістичний практичний досвід. Крім того VLEs широко використовується для науки, навчання в таких областях як машинобудування, фізика, математика або біологія, оскільки вони надають доступ через загальнодоступні Веб-сайти для практичних експериментів з будь якої точки світу. Тим не менше, більшість VLEs, що добавлені в  середовище Web-навчання призначені для індивідуального використання, і вони не дозволяють колективно діяти студентам і викладачам або групам для здійснення якоїсь діяльності. Інтеграція VLEs всередині середовища колективного навчання можна побачити в  eMersion. Ця Web-сумісна платформа вміщує декілька VLEs за допомогою яких студенти можуть експериментувати і добиватися результатів разом з іншими студентами та викладачами.  
    Злиття  Web-сумісних VLEs та Віртуальних Світів представляє один із підходів під назвою    SLOODLE, проект що описує злиття 3D-сприйняття світу Second Life з платформою MOODLE для відображення на Веб-сумісний навчальний клас з навчальним середовищем та інтерактивними об’єктами.  Спільнота SLOODLE-партнерства розробила опен-соурс безкоштовний пакет, який включає в себе скрипти і модуль  MOODLE (набір файлів PHP) забезпечуючи прямі посилання ресурсів VLE на HTTP і XML-RPC запити.  
    Електронна навчальна Лабораторія сонячної енергетики має систему комплексного навчання (MOODLE) з декількома навчальними матеріалами і "вікторини" для визначення рівня розуміння. Спочатку студенти повинні пройти декілька теоретичних випробувань, після чого система надає доступ до дистанційного експерименту, тобто реальної сонячної електростанції. Є також аналогічні системи для експерименту по налаштуванню PID. Аналіз експериментальних даних дає можливість визначити проблеми в налаштуваннях PID і автоматично виводить який навчальний матеріал повинен бути розглянутий студентами.

 

Старт Робочого комітету «Просвіта та підготовка кадрів»

опубліковано 21 лист. 2015 р., 00:33 Александр Пупена

17 листопада Робочий комітет АППАУ «Просвіта та підготовка кадрів» (далі - Комітет) офіційно запустив свою діяльність. В РК ППК війшли 16 членів – представники кафедр КПІ,НУХТ, Львівської політехніки, ХНУРЕ, Криворізького університету, Одеської академії зв’язку, керівництво АППАУ, а також представники від замовників – ЧАЕС, АМКР, вендорів ДП «Фесто-Україна», «Клінкманн-Україна», інтегратора «Союзцветавтоматика».
Головою комітету обрано доцента кафедри ІАСУ НУХТ Пупену Олександра, його заступником – представника кафедри АТЕП/ТЕФ КПІ Некрашевич Олену.

Комітет визначив на перший період 3 напрямки діяльності

1 – просвіта ринку: на найбільш важливі теми розвитку АСУ ТП планується організувати серії оф-лайн (семінари, лекції) та он-лайн (вебінари) заходів. Ці заходи будуть проходити для різних аудиторій - студентів, викладачів, а також для учасників ринку.  Відповідальним за цей напрямок є технічний директор «Клінкманн-Україна» Батюк Сергій Георгієвич.

2 – стандарти промислової автоматизації: на першому етапі питання гармонізації український ГОСТ-ів – ДСТУ в області пром. Автоматизації планується вирішувати в 3 кроки – 1) збір сучасних стандартів на єдину площадку – ознайомлення спільноти, 2) визначення пріоритетів, 3) організація нарад з Держстандартом – визначення можливостей допомоги та кінцевого плану дій. Відповідальні за цей напрямок керівництво Комітету.

3 – широке залучення найбільш зацікавлених осіб: тут мова йде про залучення широких кіл спільноти промислової автоматизації та постановку конкретних завдань для кожного члена Комітету. В рамках цього напрямку планується проведення круглих столів з кінцевими замовниками, концептуалізація конкурсів-олімпіад для студентів, нових проектів на нових технологіях (ІоТ), приєднання до світових конкурсів (як WorldSkills),  тощо. Власне можливості та вибір тем тут необмежені, ми виходимо з єдиного принципу – наявність ідей-напрацювань, а ще краще – готових продуктів та відповідність попиту на них в спільноті. Однак за кожне подібне завдання відповідає сам власник-генератор цієї ідеї. Відповідальний за весь напрямок – Юрчак Олександр Володимирович.

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

Побажаємо Комітету плідної роботи, взаєморозуміння та швидких перших результатів.  Принагідно нагадаємо для наших читачів, що двері комітету відкриті – будь-яка організація, чи професіонал на індивідуальній основі, може приєднатись до роботи комітету. Звертатись за адресою info@appau.org.ua

Матеріал взятий з Сайту АППАУ 

За кулисами борьбы за первый ПЛК

опубліковано 23 черв. 2015 р., 23:11 Александр Пупена

В 1970 году в мичиганском подразделении автоматических трансмиссий – Гидраматик – компании Дженерал Моторс разгорелась ожесточенная борьба. На кону стояли права собственности на то, что впоследствии стало первым программируемым логическим контроллером, а результат борьбы обещал повлиять не только на архитектуру первых ПЛК, но и на успех или провал их защитников.

Внутренняя конкуренция в Гидраматик

 Нет ничего странного в том, что подразделение Гидраматик, технологический лидер в составе GM, стал инкубатором для программируемого логического контроллера. Гидраматик одним из первых начал использовать компьютеры в своем производстве – модель IBM 1801.

В апреле 1968 года молодой инженер подразделения Гидраматик, Дэйв Эмметт, выдвинул идею о разработке «стандартного устройства управления». Этот контроллер, по его замыслу, должен был заменить релейные системы, управлявшие работой станков. Эмметт отвечал за Группу схемотехники и предсказывал появление устройства, которое сможет сократить стоимость обслуживания, улучшить качество диагностики оборудования и сократить место, необходимое для панелей управления.

Эмметт имел четкое представление о своей цели. Ему нужно было «разработать технологию, которая позволила бы существенно сократить время, необходимое для внесения изменений в последовательность управляющих воздействий. В случае с реле нужно сначала разработать документацию, а затем внести изменения в оборудование. Это слишком долго».

Примерно в то же время вторая группа сотрудников Гидраматик задумала другую систему управления оборудованием для Дженерал Моторс. Компьютерная группа привлекла компанию Information Instruments, Inc. (3-I) для создания компьютерной системы управления сборочной машиной для линии сборки муфт переднего хода. Эта новая система управления не имела ограничений по количеству элементов в лестничной диаграмме, обеспечивала параллельную обработку или могла включать сложные булевы уравнения.

Сотрудники компании 3-I вспоминают, что конкуренция между двумя группами в рамках подразделения Гидраматик была очень жесткой. Группа схемотехники хотела дублировать существующие лестничные диаграммы, а Компьютерная группа собиралась использовать непоследовательное программирование, аналогичное тому, которое использовалось в системах испытаний при сходе с конвейера. Этот подход должен был обеспечить более устойчивый набор команд и сократить время обработки. Преимущества и недостатки обоих подходов должны были выясниться по мере развития проекта.

Три финалиста, три решения

 В апреле и мае 1968 года в Гидраматик шла работа над запросом предложений, который отличался заметной простотой по сравнению с нашими современными стандартами. Этот запрос, опубликованный в июне 1968 года, содержал всего четыре страницы технических требований, включая фразу «длина слова памяти должна составлять не менее восьми бит». Дуглас Брент работал в то время в Гидраматик и отвечал за спецификации на поступавшее оборудование. По его словам, в процессе работы над спецификациями соперничество между Компьютерной группой и Группой схемотехники было очень острым, причиной чему, скорее всего, был обычный дележ территории.

Из всех компаний, получивших запрос предложений, для дальнейшей оценки были выбраны три: Digital Equipment Corporation (DEC), 3-I и консалтинговая фирма Bedford Associates. Эти компании представили, соответственно, модели PDP-14 (DEC), PDQ-II (3-I) и Modicon 084 (Bedford Associates). Название Modicon складывалось из начальных букв слов MOdular DIgital CONtroller.

В июне 1969 года контроллер PDP-14 компании DEC был установлен на шлифовальном станке. Несмотря на прочные отношения между Дженерал Моторс и DEC опасения DEC по поводу ошибок памяти существенно ограничивали конкурентоспособность модели PDP-14. Для внесения изменений в программу необходимо было отослать программу разработчикам, чтобы они затем выслали назад плату памяти. Необходимость снимать память контроллера при каждом изменении делала этот вариант нежизнеспособным.

Две группы Гидраматик

В процессе оценки предложенных вариантов конкуренция между Компьютерной группой и Группой схемотехники ожесточилась до предела. Компания 3-I нашла общий язык с Компьютерной группой Гидраматик. Для Компьютерной группы преимущества использования логики более высокого уровня, а значит и выбор в пользу модели PDQ-II были очевидны. Предложенное компанией 3-I решение для линии сборки муфт переднего хода с его сложным программированием работало прекрасно.

В то же время Группа схемотехники выступала за Modicon 084. Программирование, которое компьютерная группа рассматривала как преимущество, команда Эмметта считала недостатком. Благодаря тому, что язык программирования Modicon был идентичен уже знакомым релейным многозвенным диаграммам, он должен был обеспечить наиболее плавный переход и наименьшую стоимость обучения и поддержки и, как следствие, более широкое применение новой технологии.

Дополнительным преимуществом Modicon 084 был тот факт, что в отличие от двух других вариантов этот контроллер был встроен в усиленный корпус, обеспечивающий защиту.

Сравнение устройства ПЛК

 В течение следующих двух лет все три контроллера проходили испытания, пока, наконец, 3 июня 1970 года не был готов документ, в котором сравнивались характеристики этих приборов. Как и ожидалось, конкуренция была сильна не только между производителями, но и их защитниками из рядов Гидраматик.

Дуглас Брент вспоминает, что экономический потенциал контроллера был очевиден. Достаточно было зайти на какой-нибудь завод, подсчитать количество станков и провести несложные расчеты. Цифры выходили астрономические.

Ограничения, которые в конечном итоге сыграли против модели PDP-14, разработанной DEC, были выявлены при сравнении с техническими требованиями Гидраматик. Модель PDP-14 не выполняла требование к хранению памяти данных, потому что имела только постоянную память. Кроме того, DEC, единственный из троих участников соревнования, не предоставлял листинг программы таблицы соединений. В результате сравнения документ отдает преимущество моделям 3-I и Modicon, так как «программный листинг таблицы соединений ускоряет процесс установки и отладки, а также сокращает количество ошибок».

Все три компании испытали свои «стандартные устройства управления» в условиях реального производства, но модели Modicon и 3-I оказались наиболее эффективными. Компания 3-I была куплена Allen-Bradley в 1971 году, а используемый Modicon язык программирования, копирующий многозвенные релейные логические схемы, до сих пор используется производителями ПЛК. Дуглас Брент не оспаривает первенство Модикон в изобретении ПЛК: «Предложенное ими решение было настолько похоже на уже используемые лестничные диаграммы, что победа была очевидной». Если даже Модикон был не первым ПЛК, эта модель была единственной выжившей из первых трех контроллеров, установленных на реальном производстве. Кроме того, функционал модели Modicon 084 фактически стал отраслевым стандартом.

 (по материалам CE)
 
 
Джерело Insist Avtomatika на Facebook

Вэбинар Motion Control это просто

опубліковано 22 трав. 2015 р., 22:30 Александр Пупена   [ оновлено 12 черв. 2015 р., 08:43 ]

Відділом технічної підтримки Шнейдер Електрик Україна було організовано безкоштовний вебінар з назвою "Motion Control это просто", в якому ведучий, Юрій Кузьмич дуже доступно розповів про функціонування та управління сервоприводами.

Запис вебінару доступний за цим посиланням.
Презентації з вебінару доступні за цим посиланням.
  

1-10 of 26