Кількість кранів із закінченим терміном служби перевищує 90%.
Вся документація, пов'язана з експлуатацією кранів, включаючи огляди перед кожною зміною, виконується на паперових носіях вручну. Така система не дозволяє подати загальну картину стану кранового парку України, ускладнює отримання достовірної інформації про конкретний кран, його елементи, виконання належним чином функцій персоналом, що обслуговує кран. Назріла необхідність створення системи постійного спостереження за станом кранів і кожного крана окремо з закінченим терміном служби. Вирішити цю проблему може подання документації технічного стану крана та його обслуговування в електронному вигляді, що дозволило б постійно спостерігати, оцінювати та прогнозувати роботу кранів із закінченим терміном служби у режимі реального часу (Online documentation).
Для наближення такого «світлого майбутнього» пропонується проект технічного завдання (Т3) на дослідно-конструкторські роботи (ДКР) щодо створення системи моніторингу та управління ризиком кранів (МУРК). Моніторинг та ризик, тобто системи спостережень, оцінки та прогнозу небезпеки увійшли у всі галузі нашої діяльності, наприклад АЕС, банківські кредити, технічний стан будівель, екології, захворюваності дорослих та дітей, транспорт, якість освіти, застави у банку та кредити тощо.
Моніторинг та управління ризиком кранів це систематичний збір та обробка інформації про технічний стан елементів крана, виконання персоналом покладених на нього функцій та прийняття конкретних рішень для забезпечення вчасних привентивних заходів щодо зменшення ризику крана до допустимих меж.
МУРК має стати новою інформаційною технологією контролю та управління безпекою, комп'ютерною системою із програмним забезпеченням, якою зручно користуватися (Risk Watcher).
Система моніторингу та управління ризиками кранів із закінченим терміном служби повинна складатися з наступних блоків:
- оперативного для конкретного крана;
- довгострокового зберігання та обробки інформації про конкретний кран;
- довгострокового зберігання та обробки інформації для групи кранів або територіального органу Держпраці;
- математичного, інформаційно-лінгвістичного та програмного забезпечення.
Кожен блок повинен складатися з окремих модулів із програмним забезпеченням обробки інформації. Блок оперативний повинен складатися з модулів кранівника та відповідального персоналу.
Модуль кранівника повинен фіксувати виконання кранівником інструкцій, викладених у нормативних документах різних типів кранів:
- стрілові самохідні (НПАОП 0.00-5.03-95);
- баштових (НПАОП 0.00-5.05-95);
- мостового типу (НПАОП 0.00-5.18-96);
- портальних (НПАОП 0.00-5.19-96), а також безпечного ведення робіт стропальниками (НПАОП 0.00-5.04-95).
Модуль кранівника повинен утримувати виконання вимог до машиніста крана, викладених у нормативних документах різних типів кранів: стрілових самохідних, баштових, мостових та портальних.
Модуль особи, відповідальної за безпечне виконання робіт з переміщення вантажів кранами (НПАОП 0.00-5.06-94), повинен відображати фактичну роботу із забезпечення безпеки кранівником, стропальником, фіксувати видачу завдань, фіксацію та розбір порушень.
Модуль особи, відповідальної за утримання крана у справному стані (НПАОП 0.00-5.07-94) повинен відображати фактичну перевірку знань кранівників, стропальників, наявність та виконання графіків періодичних оглядів, ремонтів, перевірки роботи приладів безпеки, фіксувати несправності та ремонти, участь у огляді та експертному обстеженні.
Модуль ІТП з нагляду (НПАОП 0.00-5.20-94) повинен відображати фактичні плани роботи (місячний, квартальний, річний), обстеження кранів та вантажозахоплень, періодичний огляд зареєстрованих та не підлягаючих реєстрації кранів, участь у комісіях з атестації та перевірки знань, виявлені .
Блок довготривалого зберігання та обробки інформації про конкретний кран повинен складатися з модулів:
- Модуль відомостей (МВ) про кран повинен містити паспортні дані (загальні відомості, технічні дані та характеристики крана та складових частин), відомості про ремонти, результати технічних оглядів та експертних обстежень, рекомендації посібника з експлуатації.
- Модуль розрахунків (MP). На підставі відомостей реєстратора параметрів визначається фактичний режим навантаження та еквівалентні навантаження. Припущення, що максимальні навантаження у металоконструкціях відповідають допустимим напругам. Наводяться відомості про ресурс двигунів, рукавів, проводів та кабелів, ущільнень. Визначається тріщиностійкість у припущенні про величину переглянутої під час огляду тріщин у металоконструкції.
- Модуль аварій та несправностей (MA) містить перелік можливих відмов та методи їх усунення, несправності та відмови, що відбулися, прецеденти несправностей та аварій на кранах аналогічного типу.
- Модуль ризик-аналізу (PA) дозволяє встановити вплив стану елементів крана та якість роботи персоналу на можливу аварію або передчасний вихід із ладу складових частин крана.
- Модуль експертного обстеження (МЕ) складається із даних експертних обстежень крана.
Схема МУРК
Блок обробки та зберігання інформації групи кранів або територіальний орган Держпраці дозволяє обробити та узагальнити відомості з блоків усіх кранів цієї групи.
Блок математичного інформаційно-лінгвістичного та програмного забезпечення здійснює логічний зв'язок блоків та модулів, дозволяє зробити висновок про ризик крана на основі об'єктивної інформації про стан елементів крана та дій персоналу.
Етапи розробки МУРК
Ідентифікація. На цьому етапі визначаються завдання, що підлягають вирішенню, визначаються цілі розробки. Мета розробки – обґрунтування можливості експлуатації крана із закінченим терміном служби з мінімально допустимим ризиком. Підлягає вирішенню завдання моніторингу технічного стану крана та дій персоналу, що обслуговує кран. На цьому ж етапі визначається склад експертів та інженерів-кранівників, які братимуть участь у розробці системи.
Визначається склад користувачів системи, наприклад, ІТП з нагляду та відповідальний за утримання крана у справному стані, інспектор Держпраці.
Концептуалізація. Аналіз та вибір методів оцінки ризику за ISO 31010:2011, ISO 14798:2006, публікаціям та розрахунково-аналітичним процедурам прогнозування допустимого часу безпечної роботи крана з закінченим терміном служби.
Формалізація. Вибір програмних засобів розробки та способи представлення знань із кранів. Визначення способів представлення знань та формалізація основних понять.
Наповнення основи знань. Це найважливіший і трудомісткий етап, який поділяється на «вилучення» знань з експертів та уявлення знань. Основним результатом взаємодії інженера-кранівника з експертом є виявлення безлічі неформальних правил, якими експерт користується у своїй професійній діяльності.
Експерт-професіонал має знання двох типів - вербальні та невербальні. Вербальні знання виражаються словесно чи письмово. Невербальні (важковиразні) знання експерта становлять найбільший інтерес для проектування системи; ці знання дуже складно формалізувати, оскільки вони представляють прийоми, перевагу конкретного експерта. Отримати їх можна при розгляді прецедентів і ввести в базу знань.
Етап представлення знань визначає відомості, що використовуються під час управління ризиком. Це загальні терміни ISO 4306-1, перелік правил і нормативів, розрахункові залежності міцності, втоми, тріщиностійкості.
Розробка програми ризик-аналізу. Програма ризик-аналізу представляється переважно у матричній формі. Матриця ризик-аналізу стану елементів крана повинна містити перелік виявлених невідповідностей, можливі наслідки та величину збитків, якщо не відповідності не будуть усунені, а також перелік заходів та витрати на їх усунення. Аналогічна матриця ризику аналізу повинна бути представлена для оцінки впливу людського фактора на безпеку. Обов'язковим є уявлення прецедентів аварій на аналогічних типах кранів.
Тестування. Експерт та інженер-кранівник з використанням діалогових та пояснювальних засобів перевіряють демонстраційний прототип системи. Процес перевірки життєздатності виконується до того часу, поки експерт вирішить, що система досягла необхідного рівня компетентності.
Досвідчена експлуатація перевіряє придатність системи для використання. Розробка системи не повинна зводитися до дотримання суворої послідовності етапів. У ході розробки доведеться неодноразово повертатися на ранні етапи та переглядати прийняті там рішення. Розробка повинна вестись з паралельною роботою над усіма елементами системи, представленими на схемі.
