Страница 2: ДСТУ ISO 11064-1:2009. Проектування центрів керування ергономічне. Частина 1. Принципи проектування (62855)

На практиці процеси проектування зазвичай повторюються. Оцінювання потрібно повторювати доти, поки взаємодія між операторами і спроектованими об’єктами не досягне функційних вимог і цілей. Ізольоване визначення обґрунтованості окремого елемента проекту не гарантує, що зібрану систему буде затверджено. Будь-які зміни, навіть незначні, можуть призвести до небажаних результатів, навіть якщо сама зміна правомірна (див. ISO 6385). Має існувати офіційний процес визначення і кон­тролю за механізмами і процедурами у разі масштабних змін усіх аспектів проекту центру керування.

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

Рисунок 1 — Ергономічний підхід до проектування систем

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

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

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

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

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

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

Участь користувача — це структурний підхід, коли до проектування центру керування залу­чають майбутніх користувачів. З метою оптимізації довгострокової взаємодії «людина-машина» важлива участь користувача у проектуванні протягом усього процесу і створення почуття його власної причетності до проектування.

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

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

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

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

4. СТРУКТУРА ПРОЦЕСУ ЕРГОНОМІЧНОГО ПРОЕКТУВАННЯ

Рисунок 2 показує структуру процесу проектування центру керування, який складається з п’яти стадій (рисунок 2 показує спрощений варіант ітераційних циклів). Зазвичай усі стадії має бути ви­конано з повним зусиллям, розподіленим відповідно до сфери застосування проектної розробки.

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

Процес, структуру, якого наведено нижче і подано на рисунку 2, складається з таких стадій:

• Стадія А. З’ясування

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

• Стадія В. Аналіз і визначення

Аналізують функційні й експлуатаційні вимоги після попереднього розподілу функцій і робіт;

• Стадія С. Концептуальне проектування

Розробляють початкове планування приміщення, конструкцію меблів, дисплеїв, органів ке­рування та інтерфейс зв’язку для задоволення потреб, визначених на стадії В;

• Стадія D. Робоче проектування

Розробляють технічні вимоги до проектів, необхідних для побудови і/або оснащення центру керу­вання, його інформаційного вмісту, експлуатаційних інтерфейсів та устатковання робочого середовища;

Стадія А. З’ясування

Рисунок 2 — Процес ергономічного проектування центру керування

— Стадія Е. Експлуатаційний зворотний зв’язок

Після запуску в дію переглядають проект з метою визначення його успіхів і недоліків для по­зитивного впливу на наступні проекти.

Кожну з наведених вище стадій детальніше розглянуто в розділах 6—10, відповідно.

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

Примітка. Цей стандарт переважно стосується стадій А, В, С і Е процесу проектування, показаних на рисунку 2.

6 СТАДІЯ А. З’ЯСУВАННЯ

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

Потрібно визначити і підтвердити документально роль центру керування і його зв’язків з іншими підсистемами. Типовий приклад цього показано на рисунку 3. Потрібно визначити і задо­кументувати опис і функції підсистем, наприклад блоків оброблення даних, енергосистем, систем зв’язку тощо.

зв язки

Підсистема

Окремий пост керування

Офіс

Підсистема

Підсистема

Навчальне примі­щення

Апаратна

Підсистема

Блок керування

Центр керування

Підсистема

Керована система

Рисунок 3 — Центр керування і його зв’язки з іншими підсистемами

Зовнішні

Переміщення керування

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

Вихідна інформація кроку 1 містить такі елементи:

• вимоги користувача;

• інструктивні настанови, стандарти та іншу нормативну документацію;

• технічну інформацію про наявні системи і центри керування;

• інформацію про оперативний зворотний зв’язок;

• аналіз будь-яких наявних або подібних ситуацій.

Результатами кроку 1 є:

• функції системи (тобто цілі роботи);

• різноманітні відповідні вимоги і обмеження (див. додаток В);

• суперечливі вимоги і шляхи знаходження компромісу.

Деякі загальноприйняті методи охоплюють також:

• перегляд документів, наприклад проектних завдань, виокремлення коштів, початкових про­ектних рішень;

• проведення співбесіди з персоналом щодо керівництва заводу, функціювання експлуатаційно- технічних служб, обслуговування заводу, а також збирання інших форм усної інформації;

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

• проведення технологічних переглядів, тобто аналізування останніх методів і методик інтер­фейсу «оператор-система»;

• проведення ергономічних та інших навчань на вибір.

Будь-які вимоги або обмеження, які треба враховувати під час проектування центру керу­вання, необхідно визначити і задокументувати. До цих вимог мають входити усі вимоги, наведені в додатку В.

Зокрема, необхідно враховувати:

• функційні цілі;

• кодекси і постанови;

• вимоги щодо надійності і безпеки;

• експлуатаційні вимоги і вимоги до контролю;

• ергономічні вимоги;

• вимоги до роботи і до організації робіт:

• технічне обслуговування системи;

• політику компанії;

• стандарти компанії;

• технічні обмеження;

• обмеження в ресурсах;

• досвід роботи;

• формалізацію проекту невизначеності і організацію внесення змін;

• естетику і архітектуру.

Потрібно об’єднати експлуатаційний зворотний зв’язок з іншими проектами (див. 10.2), а суперечності щодо вимог, отримані з досвіду, необхідно задокументувати, оцінити і вирішити.

7 СТАДІЯ В. АНАЛІЗ І ВИЗНАЧЕННЯ

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

Ці п’ять кроків такі:

• Крок 2: визначають робочі характеристики системи (функційний аналіз і опис);

• Крок 3: розподіляють функції між людиною і/або машиною;

• Крок 4: визначають вимоги до завдань;

• Крок 5: проектують роботу і організацію робіт;

• Крок 6: перевіряють і підтверджують отримані результати.

На підставі результатів кроку 1 стадії А необхідно провести і підтвердити документально функційний аналіз, щоб визначити ергономічні потреби (залучення, аналіз і ухвалення рішення) для досягнення цілей, визначених на стадії А.

Функційний аналіз можна проводити кількома методами, а саме: функційним розподілом (ІЕС 60964), графічним представленням, моделюванням і експлуатаційним наскрізним аналізом.

Сфери застосування функційного аналізу мають охоплювати усі очікувані експлуатаційні ре­жими керованої системи:

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

2. звична робота в умовах перехідних процесів (запуск, вимкнення), наприклад операція або послі­довність операцій, які змінюють процес або керовану систему з одного головного режиму або стану на інший (наприклад початок або зупинення процесу, сортування продукту і/або зміна норми виробітку);

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

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