Плутанина режимів автоматизації: чому оператор неправильно розуміє стан і поведінку системи
Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика
Плутанина режимів автоматизації виникає тоді, коли фактичний стан автоматизованої системи й уявлення оператора про цей стан розходяться настільки, що людина прогнозує іншу поведінку системи, ніж та реально виконує або збирається виконати. У дослідженнях людських факторів це явище описують термінами mode confusion, mode awareness, mode error та automation surprise. Класична робота Nadine Sarter і David Woods 1995 року показала, що збільшення кількості режимів і можливостей автоматизації створює для оператора нову задачу: безперервно розуміти, у якому режимі перебуває система, що саме вона контролює і як її поведінка зміниться за наступної умови або команди.
Ця проблема належить до ядра людських факторів та ергономіки. Її предметом є координація людини з технічною системою, а не пошук «винного оператора». Сучасна безпекова логіка розглядає плутанину режимів як властивість взаємодії між архітектурою автоматизації, інтерфейсом, процедурами, навчанням, умовами роботи й людською здатністю підтримувати точну модель динамічної системи. У повномасштабному дослідженні Sarter і Woods прямо описували недостатню обізнаність про режим як симптом порушення координації людини й машини, а не як ізольовану проблему пілота Sarter & Woods, 2000.
Поняття має усталений статус у дослідженнях автоматизації, авіаційних людських факторів, автоматизованого водіння, робототехніки та інших багаторежимних систем. Водночас універсальної шкали, єдиного порога «плутанини» або одного показника, який надійно вимірював би явище в усіх галузях, немає. Огляд інтерфейсів mode awareness в автоматизованих транспортних засобах, робототехніці та авіації показує спільність проблеми й водночас значну залежність рішень від конкретної системи та контексту Dönmez Özkan та співавт., 2021.
Що таке плутанина режимів автоматизації
Режим автоматизації — це конфігурація системи, у якій однакові команди, сигнали або умови можуть мати визначене для цього стану значення, а сама система використовує певний набір правил керування. У багаторежимній системі оператор взаємодіє не лише з функцією, а й зі станом, у якому ця функція виконується. Тому команда може бути правильною за однієї конфігурації та давати інший результат за іншої.
Плутанина режимів виникає, коли оператор помилково вважає активним інший режим, не помічає переходу, хибно тлумачить значення індикатора або правильно бачить назву режиму, але неправильно прогнозує його наслідки. У класичному описі проблеми важлива не сама етикетка на дисплеї, а обізнаність про поточний і майбутній стан та поведінку автоматизації Sarter & Woods, 1997.
Mode error, або помилка режиму, стосується дії: оператор виконує дію, яка була б доречною для режиму, що він припускає, але не відповідає фактичному режиму. Mode confusion описує розбіжність у розумінні стану, а mode error — один із можливих поведінкових наслідків цієї розбіжності. Такий поділ корисний для розслідування, тому що помилкова дія сама по собі ще не доводить, що людина справді неправильно розуміла режим.
Науковий статус поняття — конструкція людських факторів і когнітивної ергономіки, що описує взаємодію людини з багаторежимною автоматизацією. Клінічні категорії тут не застосовуються. У професійній практиці термін використовується для аналізу проєктування, сертифікації, випробувань, навчання та безпеки систем, а доказова база складається з лабораторних і симуляційних досліджень, польових спостережень, аналізу інцидентів, формальних моделей і галузевих рекомендацій.
Що означає «режим» у людино-технічній системі
Degani, Shafto і Kirlik запропонували розглядати режими як конструкції, що змінюють поведінку системи та спосіб взаємодії з нею, і окремо аналізувати неоднозначність режимів та очікування користувача Degani, Shafto & Kirlik, 1999. Практично це означає, що «режим» існує не лише в коді або в назві на екрані. Він існує як зв’язок між станом системи, доступними діями, розподілом контролю та тим, що оператор очікує після своєї дії.
Деякі режими обирає людина явно. Інші активуються автоматично за певних умов, переходять у резервний стан після відмови, змінюються внаслідок іншої команди або залежать від прихованого системного параметра. Ризик зростає, коли автоматизація має вкладені режими, коли кілька підсистем змінюють стан одночасно або коли режим однієї підсистеми впливає на іншу.
Поточний стан, підготовлений стан і майбутня поведінка
Для безпечної взаємодії операторові часто потрібно знати більше, ніж назву активного режиму. Важливими є щонайменше чотири елементи: що система робить зараз, які функції готові активуватися далі, яка подія спричинить перехід і хто після цього матиме контроль або відповідальність за конкретну задачу.
Це пояснює, чому індикатор «AUTO» або піктограма можуть формально повідомляти стан, але залишати головну невизначеність. Якщо оператор не може передбачити наступну дію системи, режим залишається когнітивно непрозорим. Для safety-critical систем знання майбутньої поведінки часто так само важливе, як знання поточного стану.
Режим як зміна правил взаємодії
Модальність стає небезпечною, коли один і той самий орган керування, команда або жест означає різні речі залежно від стану системи. Людина повинна спочатку правильно встановити режим, а вже потім інтерпретувати наслідок своєї дії. Якщо перша частина ланцюга помилкова, друга може бути логічною з погляду оператора і водночас неприйнятною для фактичної системи.
Саме тому дизайн режимів стосується не лише «видимості статусу». Він охоплює відповідність між цілями людини, доступними діями, позначеннями, системними переходами й наслідками. Загальні принципи взаємодії ISO 9241-110:2020 включають самопояснюваність, відповідність очікуванням користувача, керованість і стійкість до помилок використання; стандарт задає загальну рамку, а конкретні safety-critical вимоги визначаються галуззю ISO 9241-110:2020.
Як виникає розрив між фактичним станом системи та уявленням оператора
Плутанина режимів рідко має одну причину. Вона формується на стику кількох властивостей системи: кількості режимів, способу переходів, видимості стану, відповідності позначень очікуванням, частоти використання, навантаження, переривань, розподілу контролю та якості зворотного зв’язку. Чим більше оператор повинен «додумувати» замість того, щоб одержувати однозначну інформацію від системи, тим більше простору для розходження між фактичним і уявним станом.
Розмноження режимів і прихована складність
Гнучка автоматизація часто накопичує режими в міру розвитку продукту. Кожна нова функція може бути локально логічною, але сукупність режимів створює велику кількість можливих конфігурацій. Sarter і Woods показували саме ціну такої гнучкості: оператор отримує більше можливостей, але одночасно повинен підтримувати більше знань про стан і більше уваги витрачати на відстеження автоматизації.
Важливо оцінювати не лише кількість режимів, а їхню когнітивну відмінність. Десять режимів із чіткими різними функціями можуть бути зрозумілішими за три режими, які мають подібні назви, майже однакові екрани і різну поведінку лише в критичній умові.
Слабка видимість стану
Система може технічно показувати режим і водночас погано підтримувати його усвідомлення. Малий текст, короткочасне повідомлення, колір без дублювання змістом, віддалене від органу керування позначення або індикатор, який відображає лише частину стану, створюють різні форми інформаційного розриву.
Видимість має включати не тільки факт переходу, а його значення. Якщо система повідомляє «режим X», а операторові для дії потрібно знати «тепер автоматизація більше не контролює швидкість», корисною одиницею інформації стає зміна функції та ролі, а не лише технічна назва.
Автоматичні, непрямі та умовні переходи
Особливо складні переходи, які запускаються не прямою командою оператора, а умовою середовища, таймером, досягненням порога, станом іншої підсистеми або логікою захисту. Людина може пам’ятати, що ввімкнула певний режим, і не мати достатньо помітного сигналу про те, що система вже вийшла з нього.
Формальні дослідження mode confusion показали, що потенційно проблемні властивості логіки переходів можна шукати ще на етапі специфікації. Leveson та колеги описали підхід до раннього виявлення автоматизаційних особливостей, які можуть провокувати помилки, щоб змінювати не тільки інтерфейс або навчання, а й саму функціональну логіку Leveson та співавт., 1998.
Одна дія — різні наслідки
Модальні інтерфейси збільшують залежність дії від контексту. Кнопка, важіль, команда, число або жест можуть працювати по-різному в різних режимах. Це саме по собі не робить систему небезпечною, але вимагає дуже надійного зв’язку між станом і дією.
Коли наслідок залежить від режиму, дизайн повинен допомагати операторові перевіряти цей режим до дії та одразу бачити результат після неї. Чим вища ціна помилки, тим слабшою є стратегія, яка покладається лише на пам’ять про те, «що ми вибрали кілька хвилин тому».
Неповна або застаріла ментальна модель
Оператор взаємодіє з автоматизацією через власну модель її логіки: які умови потрібні для активації, що система контролює, коли вона відмовиться від функції, що означає конкретний індикатор і які переходи можливі. Така модель може бути достатньою для звичайних сценаріїв і виявитися неповною саме в рідкісній або часово критичній ситуації.
Експериментальне дослідження Sarter і Woods показало, що пілоти могли ефективно користуватися автоматизацією у звичних умовах, але приховані прогалини в знанні логіки проявлялися в нетипових і часочутливих сценаріях Sarter & Woods, 1994. Для проєктування це принципово: успішне виконання типового завдання ще не доводить, що користувач сформував точну модель системи.
Психічне робоче навантаження, переривання і перемикання уваги
Під високим навантаженням оператор має менше ресурсів для відстеження другорядних індикаторів і перевірки переходів. Переривання може розірвати послідовність «команда — підтвердження — контроль результату», а повернення до задачі відбувається вже з припущенням про стан, який міг змінитися. У F08 це перетинається з окремим поняттям психічного робочого навантаження, але плутанина режимів зберігає власний intent: об’єктом аналізу є правильність розуміння конфігурації та поведінки автоматизації.
Навантаження діє не як універсальна причина, а як умова, що підсилює вразливість певного дизайну. Добре спроєктований стан має залишатися читабельним у реальному робочому контексті, де є паралельні задачі, часовий тиск, спілкування та несподівані події.
Відмова, деградація і повернення в резервний режим
Автоматизація часто має деградовані стани: частина функцій зберігається, частина вимикається, контроль повертається людині або система переходить до простішого резервного режиму. Саме такі переходи небезпечні для розуміння, якщо інтерфейс повідомляє лише «відмова» без пояснення того, що залишилося активним.
Проєктування резервних режимів повинно відповідати на практичне запитання оператора: які можливості втрачено, які збереглися, що тепер контролює система, що контролюю я і яка дія потрібна далі. Це особливо важливо там, де рідкісна відмова одночасно збільшує навантаження.
Розподіл ролей між людиною й автоматизацією
Плутанина режимів стає й плутаниною відповідальності, коли режим змінює не тільки технічну функцію, а роль людини. В одному стані оператор може безпосередньо керувати процесом, в іншому — задавати ціль, у третьому — лише контролювати, у четвертому — бути резервом для втручання.
Цей механізм безпосередньо пов’язаний із людиною в контурі керування та виходом людини з контуру автоматизації. Якщо архітектура передає контроль туди й назад, інтерфейс має робити передачу однозначною для обох сторін взаємодії: система повинна сигналізувати свою роль, а оператор — мати зрозумілий спосіб прийняти або відхилити контроль.
Плутанина режимів — системна проблема координації
Системний підхід змінює питання після інциденту. Замість «чому оператор натиснув не ту кнопку?» аналіз починається з відтворення того, який режим був фактично активний, що показував інтерфейс, який режим очікувала людина, які переходи відбулися, які сигнали були доступні, які задачі виконувалися паралельно і чому помилкове припущення залишалося правдоподібним.
Це узгоджується з ширшою дисципліною людської помилки, де дія розглядається в контексті системи. Плутанина режимів особливо наочно показує обмеження персональної логіки вини: система може працювати цілком відповідно до своєї специфікації, оператор може діяти послідовно відповідно до своєї моделі, а небезпечний результат виникає саме через невідповідність між цими двома моделями.
FAA описує людські фактори у flight deck як дисципліну, що охоплює взаємодію пілота з дисплеями, органами керування, процедурами, навчанням і автоматизацією, а також розглядає human error, workload та complexity як системні теми FAA Flight Deck Human Factors. Така рамка добре передає сучасний принцип: безпечність створюється конфігурацією всієї людино-технічної системи.
Чим плутанина режимів відрізняється від споріднених понять
Близькі терміни часто описують різні рівні одного епізоду. Для якісного аналізу важливо встановити, що саме було порушено: знання стану, прогноз поведінки, розподіл ролей, довіра, увага чи вибір дії. Це запобігає ситуації, коли будь-яку проблему автоматизації називають mode confusion.
Плутанина режимів і помилка режиму
Плутанина режимів описує хибне або неповне розуміння фактичної конфігурації. Помилка режиму описує дію, яка відповідає уявному режиму, але не фактичному. Між ними немає автоматичного причинного зв’язку: людина може неправильно назвати режим і все одно виконати безпечну дію, або виконати неправильну дію з іншої причини.
Тому оцінювання повинно поєднувати дані про розуміння стану з поведінкою. Методологічна робота Plum і Shi звертає увагу на те, що mode-inadequate поведінка має кілька можливих причин, а висновок про mode awareness потребує обережної багатометодної інтерпретації Plum & Shi, 2025.
Плутанина режимів і automation surprise
Automation surprise — ширше поняття для ситуації, коли автоматизація поводиться не так, як очікує оператор. Причиною може бути плутанина режимів, неповна модель системи, рідкісна логіка, невідома залежність або інший фактор. У класичних авіаційних дослідженнях automation surprises пов’язували з недостатньою обізнаністю про поточний і майбутній стан автоматизації Sarter & Woods, 1997.
Для дизайнера «сюрприз» є діагностичним сигналом: десь між фактичною логікою системи та очікуванням людини виникла невідповідність. Подальший аналіз повинен встановити її механізм.
Плутанина режимів і ситуаційна обізнаність
Ситуаційна обізнаність охоплює ширше розуміння того, що відбувається в середовищі й системі та як ситуація розвиватиметься. Mode awareness стосується специфічнішої частини цього завдання — стану й поведінки багаторежимної автоматизації. У деяких дослідницьких традиціях mode awareness описують як системно-специфічний аспект situation awareness, але операціоналізація різниться між галузями.
Практично оператор може чудово розуміти зовнішню ситуацію й водночас помилятися щодо активного режиму автоматизації. Можлива й зворотна ситуація: режим визначено правильно, але загальна ситуаційна обізнаність недостатня.
Плутанина режимів і вихід людини з контуру
Вихід людини з контуру автоматизації описує ширшу проблему зменшення залученості, моніторингу, знання стану процесу або готовності до втручання, коли автоматизація бере на себе значну частину роботи. Mode confusion може бути одним із наслідків такої архітектури, але виникає і в активно керованих системах із погано видимими режимами.
Важлива різниця в об’єкті аналізу: out-of-the-loop performance problem питає, наскільки людина зберігає здатність ефективно контролювати й втручатися; mode confusion питає, чи правильно вона розуміє конкретний режим і його поведінкові наслідки.
Плутанина режимів і довіра до автоматизації
Довіра до автоматизації стосується очікувань щодо надійності й компетентності системи та того, як ці очікування впливають на покладання на автоматизацію. Людина може довіряти системі й правильно розуміти режим або не довіряти їй і водночас точно знати її стан.
Після серії automation surprises довіра може знижуватися, але це вже інший механізм. Для безпеки важливо окремо проєктувати зрозумілу автоматизацію й окремо підтримувати адекватне калібрування довіри.
Плутанина режимів і автоматизаційне упередження
Автоматизаційне упередження описує схильність надмірно покладатися на автоматизовані підказки або рішення. Плутанина режимів стосується стану й логіки системи. Оператор може знати, який режим активний, але безпідставно прийняти рекомендацію автоматизації; так само він може критично ставитися до рекомендації, але помилятися щодо того, хто саме зараз контролює процес.
Ці явища можуть взаємодіяти в одному інциденті, проте мають різні canonical intents і потребують різних заходів дизайну та оцінювання.
Типовий ланцюг плутанини режимів
У багатьох епізодах можна відтворити схожу послідовність. Людина має операційну ціль і припускає, що система перебуває в певному режимі. Вона вводить команду або очікує автоматичної дії. Система фактично перебуває в іншому стані або переходить до нього за умовою. Інтерфейс недостатньо чітко показує зміну або її наслідок. Наступна дія оператора є логічною щодо припущеного режиму, але не щодо реального.
Далі можливі різні сценарії: система виконує неочікувану дію, не виконує очікувану, передає контроль людині, змінює підсистему або входить у стан, з якого потрібне швидке відновлення. Automation surprise з’являється вже після розходження моделей. Тому дизайн, що лише краще пояснює помилку після факту, слабший за дизайн, який зменшує саму ймовірність розходження.
Цей ланцюг корисний для розслідування, але не перетворюється на універсальну причинну модель. У реальних системах переходи можуть бути командними, автоматичними, каскадними й взаємозалежними; ролі можуть розподілятися між кількома людьми та підсистемами.
Авіація: історичний контекст і системний урок
Авіація стала однією з головних галузей, де поняття mode confusion було розроблене емпірично, тому що високий рівень автоматизації, численні режими автопілота й керування польотом та висока ціна помилкової взаємодії зробили проблему особливо помітною. Це не означає, що феномен «авіаційний» за природою; авіаційні дослідження дали точну мову для загальної проблеми багаторежимних систем.
FAA Human Factors Team у звіті 1996 року аналізувала взаємодію екіпажів із сучасними системами flight deck і звертала увагу на труднощі, пов’язані з несподіваними діями автоматизації, невідомим активним режимом, неочікуваними переходами та недостатньою підтримкою розуміння стану FAA Human Factors Team Report, 1996. Ключовий висновок для сучасних систем ширший за авіацію: передбачуваність і прозорість переходів є властивістю дизайну, яку треба вбудовувати, а не очікувати від оператора як постійного компенсаторного зусилля.
Катастрофа Air Inter 148 біля Страсбурга як приклад взаємодії факторів
У матеріалах FAA про аварію Air Inter A320 20 січня 1992 року описано епізод, у якому під час заходу на посадку екіпаж, імовірно, обрав режим вертикальної швидкості замість кута траєкторії та ввів 3300 футів за хвилину замість 3,3 градуса. FAA наводить серед чинників autopilot mode confusion, особливості дизайну органів керування, пізню зміну процедури заходу, високе навантаження, комунікацію екіпажу та контроль траєкторії FAA Lessons Learned.
Сила цього прикладу саме в багатофакторності. Він не підтримує спрощене твердження «пілот переплутав режим — отже, причина в пілоті». Навпаки, він показує, як схожість введення, модальність контролера, робоче навантаження, процедурний контекст і відображення стану можуть зійтися в одному ланцюзі.
Сучасна FAA й далі розглядає automation, alerting, workload, complexity і human error як взаємопов’язані питання flight deck human factors, а в січні 2026 року оновила сторінку Human Factors in Aviation Safety з посиланнями на актуальні матеріали для дизайну й оцінювання FAA Human Factors in Aviation Safety.
Автоматизоване водіння: коли режим визначає роль водія
У частковій автоматизації водіння режим часто змінює не тільки функцію автомобіля, а й обов’язки людини: що вона має контролювати, чи повинна безперервно стежити за дорогою, які дії дозволено делегувати і як швидко треба бути готовою перебрати керування. Тому помилка щодо режиму одночасно стає помилкою щодо власної ролі.
Дослідження Tinga та співавторів показало, що HMI може підтримувати mode awareness, якщо безперервно повідомляє інформацію, потрібну для розуміння актуальної ролі й обмежень автоматизації, а не лише технічний статус Tinga та співавт., 2022. Це одне дослідження в конкретному домені, тому його результати не варто переносити як універсальний закон, але воно добре ілюструє дизайн-принцип: інформація має відповідати рішенню, яке повинен прийняти користувач.
Експериментальна робота з різними способами організації HMI для автоматизованих транспортних засобів також показала, що форма подання режимів може впливати на частоту mode confusion Mode confusion of human–machine interfaces for automated vehicles, 2022. Такі результати підтримують інженерну гіпотезу про роль інтерфейсу, але ефекти залежать від конкретного дизайну, сценарію та учасників.
Monsaingeon та співавтори у 2023 році досліджували мультимодальні інтерфейси й подання надійності автоматизації та показали, що різні способи зворотного зв’язку по-різному впливають на увагу, mode awareness і довіру Monsaingeon та співавт., 2023. Для практики це означає, що «додати більше сигналів» — недостатня стратегія: сигнали треба оцінювати як частину цілісної взаємодії.
Промислові, роботизовані та інші керовані системи
Проблема режимів з’являється всюди, де автоматизація змінює правила керування, розподіл функцій або реакцію системи на однакову дію. Це можуть бути промислові системи керування, роботизовані комплекси, транспорт, складні медичні пристрої або програмні інтерфейси з критичними станами. Конкретні ризики й нормативні вимоги різняться, але спільним залишається завдання підтримувати точне розуміння стану.
Ще у 1983 році Lisanne Bainbridge описала «іронії автоматизації»: автоматизація може зменшити обсяг рутинної ручної роботи, але залишити людині рідкісні, складні й критичні завдання моніторингу та відновлення Bainbridge, 198390046-8). Mode confusion є одним із конкретних механізмів, через які ця загальна проблема може проявлятися.
Огляд 2021 року, що порівнював автоматизоване водіння, робототехніку й авіацію, виявив спільні труднощі з підтримкою mode awareness і показав, що прості індикатори часто не масштабуються зі зростанням складності системи Dönmez Özkan та співавт., 2021. Це підтримує перехід від «лампочки режиму» до дизайну, що пояснює стан, межі та очікувану поведінку.
Чому простого індикатора активного режиму часто недостатньо
Назва режиму відповідає лише на одне запитання — «як система називає свій поточний стан». Операторові зазвичай потрібні ще три: «що система реально робить», «що вона зробить далі» і «що тепер маю робити я». Якщо ці відповіді потребують знання прихованої логіки, інтерфейс переносить когнітивну роботу на людину.
Режим також може бути формально правильним, але недостатньо інформативним. Наприклад, загальна позначка автоматичного керування не пояснює, які підфункції активні, яка з них обмежена умовами, яка готова перейти в інший стан і за якою подією. У складній системі mode awareness є структурованим розумінням, а не розпізнаванням одного напису.
Інтерфейс має підтримувати причинно-наслідковий зв’язок. Коли система змінює режим, оператор повинен бачити сам факт переходу, його причину в тій мірі, у якій вона потрібна для дії, і наслідок для контролю. Так формується передбачуваність — одна з ключових якостей безпечної автоматизації.
Яку інформацію має давати інтерфейс
Добрий інтерфейс режимів дозволяє операторові швидко відновити цілісну картину навіть після переривання. Він показує поточний стан, активні функції, межі автоматизації, джерело команди або причину переходу, очікувану наступну поведінку та розподіл контролю між людиною і системою. У критичних системах важливо також бачити деградовані можливості й шлях відновлення.
Інформація повинна бути достатньо стійкою в часі. Короткий спливаючий напис легко пропустити під час іншої задачі; постійний статус або доступна історія переходів дає можливість перевірити припущення пізніше. Водночас надмірна кількість постійних індикаторів створює іншу проблему — конкуренцію за увагу. Тому рішення потребує дослідження реальної задачі, а не максимізації кількості сигналів.
Сенс має перевагу над технічною термінологією. Якщо системна назва режиму не збігається з мовою, якою оператор мислить про свою задачу, інтерфейс має допомогти зв’язати ці рівні. Людина повинна розуміти не тільки «X2 активний», а «система тепер утримує параметр А, але параметр B контролюю я».
Принципи дизайну, що зменшують ризик плутанини режимів
Мінімізуйте приховану модальність
Кожен режим створює додаткову умову для інтерпретації дії. Там, де одна й та сама задача може бути виконана без прихованого стану, зменшення модальності спрощує взаємодію. Це не означає механічно «прибрати всі режими»: у складній системі різні конфігурації можуть бути функціонально необхідними. Мета — зменшити режими, які не дають користувачеві цінності, і зробити решту очевидними.
Корисне інженерне запитання звучить так: чи може користувач передбачити наслідок дії, не пам’ятаючи невидимий стан? Якщо відповідь негативна, або стан треба зробити явним, або саму взаємодію перебудувати так, щоб дія не залежала від прихованої модальності.
Робіть переходи помітними і стійкими
Перехід — окрема подія, а не просто новий статичний стан. Він потребує такого зворотного зв’язку, який дає операторові шанс помітити зміну в реальному робочому контексті. Особливо це стосується автоматичних переходів, які відбуваються без прямої команди людини.
Стійкість означає, що інформація про новий стан не зникає до того, як людина матиме реальну можливість її сприйняти. Для критичних переходів може бути потрібне поєднання візуального, слухового або тактильного каналу, але вибір сигналу залежить від задачі й не повинен створювати неконтрольовану сигналізацію.
Показуйте не тільки стан, а намір і наслідок
Sarter і Woods підкреслювали важливість розуміння не лише поточного, а й майбутнього стану автоматизації. Для сучасного дизайну це означає підтримку прогнозу: що система збирається робити, за якої умови змінить режим і який параметр після цього контролюватиме Sarter & Woods, 1997.
Прогноз особливо корисний у системах із «підготовленими» режимами, автоматичними переходами або каскадною логікою. Коли оператор бачить не лише те, що вже сталося, а й очікувану траєкторію станів, шанс виявити невідповідність моделі зростає раніше.
Узгоджуйте назви та структуру з цілями оператора
Технічна архітектура й користувацька модель системи часто мають різні рівні абстракції. Розробник бачить підсистеми, стани й прапорці; оператор — цілі, обмеження й необхідні дії. Інтерфейс повинен зв’язувати ці два представлення.
ISO 9241-210:2019 задає життєвий цикл людиноцентрованого проєктування, де розуміння користувачів, задач і контексту є частиною процесу створення інтерактивних систем ISO 9241-210:2019. Для mode confusion це означає, що назви, переходи й відображення режимів перевіряють на реальних задачах, а не лише на відповідності внутрішній логіці програмного забезпечення.
Підтримуйте керованість і відновлення
Оператор повинен мати зрозумілий спосіб підтвердити стан, скасувати небажану команду, вийти з невідомої конфігурації або перейти до безпечнішого способу керування, якщо це передбачено архітектурою системи. Відновлення має бути частиною дизайну, а не імпровізацією після помилки.
Коли ручне втручання доступне, інтерфейс повинен чітко показувати момент передачі контролю. «Людина може втрутитися будь-коли» не гарантує безпеки, якщо вона не знає, що саме зараз робить автоматизація або який ефект матиме її дія.
Проєктуйте для нештатних і рідкісних сценаріїв
Багато проблем режимів не проявляються під час звичайного демо-сценарію. Їх видно під час відмов, граничних умов, рідкісних переходів, швидкої зміни задачі, переривання або високого навантаження. Саме ці умови повинні бути частиною human-in-the-loop оцінювання.
Робота Leveson та співавторів важлива тут тим, що переносить аналіз ще раніше — до рівня специфікації. Якщо небезпечна неоднозначність закладена в логіку режимів, косметичне покращення індикатора може лише частково компенсувати проблему. Деякі конфігурації потребують зміни самого автоматизованого контролю Leveson та співавт., 1998.
Сигнали переходу: коли більше повідомлень означає менше ясності
Природна реакція на непомічені переходи — додати сигнал. Це може допомогти, але кожне нове сповіщення конкурує за увагу з іншими задачами. У системі з частими переходами постійні звукові або візуальні повідомлення швидко втрачають інформаційну цінність.
Тому інтерфейс режимів і система тривог мають проєктуватися разом. Втома від сигналів тривоги виникає як окремий safety-system intent, коли велика кількість сигналів знижує їхню практичну ефективність. Рішенням для mode awareness часто є не «ще одна тривога», а краще постійне представлення стану, пріоритезація критичних переходів і доступна історія змін.
Дослідження слухових сигналів у частково автоматизованих транспортних засобах показують потенціал мультимодального зворотного зв’язку, але ефективність залежить від того, чи користувач правильно розуміє сигнал і може пов’язати його зі своєю задачею. Це емпіричне питання, яке треба перевіряти для конкретного інтерфейсу.
Чому навчання не замінює дизайн
Навчання потрібне для складної автоматизації, але його функція — формувати точну модель системи й тренувати роботу з нею, а не компенсувати систематичну неоднозначність інтерфейсу. Якщо режим важко побачити, перехід відбувається без чіткого зворотного зв’язку, а однакова команда має небезпечно різні наслідки, додаткове запам’ятовування процедур залишає основний механізм ризику на місці.
FAA Human Factors Team ще у 1996 році розглядала дизайн, процедури й навчання як взаємопов’язані компоненти проблеми flight deck automation FAA Human Factors Team Report. Leveson та колеги також прямо зазначали, що інтерфейс і навчання — лише частина можливих відповідей; інколи треба змінювати саму автоматизацію.
Якісне навчання охоплює не тільки «яку кнопку натискати», а логіку переходів, межі функцій, деградовані стани, ознаки невідповідності, ручне відновлення та рідкісні сценарії. Воно також тренує перевірку режиму як частину робочої процедури, якщо така перевірка справді потрібна системі.
Як вимірюють mode awareness і плутанину режимів
Вимірювання складне, тому що mode awareness — внутрішнє знання про стан системи, а дослідник бачить його через відповіді, дії, час реакції, погляд або самооцінку. Один поведінковий епізод має кілька можливих пояснень. Саме тому сильне дослідження поєднує кілька джерел даних і прив’язує їх до конкретної моделі системи.
Систематичний огляд способів вимірювання mode awareness в автоматизованому водінні виявив різноманіття методів: пряме визначення режиму, freeze-probe техніки, час реакції, аналіз поведінки, погляд, опитувальники й експертне кодування. Це демонструє відсутність єдиного «золотого стандарту» й залежність показника від дослідницького завдання.
Прямі перевірки розуміння режиму
Найпряміший підхід — запитати, який режим активний, що саме контролює система, хто має виконувати конкретну функцію або що відбудеться далі. Такі перевірки ближчі до самого конструкта, але можуть втручатися в задачу й змінювати увагу учасника.
У симуляціях іноді використовують коротку зупинку сценарію, щоб перевірити розуміння стану без довгої ретроспективи. Важливо ставити запитання не лише про назву режиму, а й про функціональне значення: правильна етикетка не завжди означає правильний прогноз поведінки.
Поведінкові показники
До поведінкових індикаторів належать дії, що відповідають або не відповідають фактичному режиму, непотрібне вимкнення автоматизації, запізніле втручання, неправильна передача контролю, час реакції на зміну стану та спосіб відновлення після сюрпризу.
Перевага таких показників у тому, що вони відображають практичну взаємодію. Обмеження полягає в багатопричинності: та сама дія може бути наслідком неправильного розуміння режиму, стратегії, ризикового вибору, відволікання, перевантаження або іншого фактора. Plum і Shi, 2025 пропонують посилювати висновки комбінацією метрик.
Погляд і фізіологічні дані
Eye tracking допомагає встановити, чи дивився оператор на індикатор режиму, як довго його оглядав і як змінювався розподіл уваги. Проте фіксація погляду не дорівнює розумінню. Людина може побачити індикатор і неправильно його інтерпретувати або, навпаки, правильно знати стан без повторного погляду.
Фізіологічні показники можуть інформувати про навантаження або активацію, але не є прямим виміром того, який режим людина вважає активним. Їх доцільно використовувати як додатковий контекст.
Аналіз інцидентів і операційних даних
Реальні інциденти показують, як проблема проявляється в складному контексті, де одночасно діють процедури, команда, навантаження, організаційні умови та технічна логіка. Їхня сила — екологічна реалістичність; слабкість — неповнота даних про внутрішнє розуміння оператора.
Тому категорія mode confusion має присвоюватися після реконструкції станів і доступних сигналів, а не лише за фактом неправильної дії. Інакше аналіз ризикує перетворити будь-який невдалий контроль у «помилку режиму».
Формальні методи й аналіз станів
Ще один напрям — описати автоматизацію та очікувану модель користувача як системи станів і шукати сценарії, де їхня поведінка розходиться. Model checking та інші формальні методи дають змогу знаходити деякі потенційні automation surprises до створення готового інтерфейсу Rushby, 200200092-8).
Формальний аналіз не замінює випробування з людьми: він працює з явною моделлю того, що користувач знає або очікує. Його цінність у тому, що він виявляє структурні суперечності й небезпечні переходи, які потім можна перевірити емпірично.
Як тестувати систему на ризик плутанини режимів
Початок тестування — карта режимів і переходів. Команда повинна явно описати, які стани існують, хто або що ініціює перехід, які умови його запускають, які функції змінюються, які сигнали отримує користувач і яка дія очікується після переходу. Уже на цьому етапі часто стають видимими приховані стани та неочевидні залежності.
Другий крок — модель задачі оператора. Для кожного критичного переходу треба встановити, що людина реально повинна знати: технічну назву режиму, активну функцію, межу автоматизації, наступну подію, свою роль чи комбінацію цих елементів. Тестування має перевіряти саме це знання.
Третій крок — сценарії. Крім номінального використання потрібні переривання, швидкі повторні команди, автоматичні переходи, граничні умови, деградація, повернення з резервного режиму, передача контролю, конфліктні сигнали та рідкісні послідовності. Система, зрозуміла лише в «ідеальній демонстрації», ще не довела стійкість взаємодії.
Четвертий крок — комбінація метрик. Варто поєднувати пряме розуміння режиму, поведінку, час реакції, помічені переходи, спостереження за інтерфейсом і якісне пояснення користувача. Це дає змогу відрізнити справжню плутанину від інших причин дії.
П’ятий крок — повторне проєктування й перевірка. Human-centred design у сенсі ISO 9241-210 є ітеративним процесом: результати оцінювання повертаються в дизайн ISO 9241-210:2019. Для safety-critical систем до цього додаються галузеві вимоги сертифікації, hazard analysis і validation.
Ознаки підвищеного ризику mode confusion у готовій системі
Ризик варто перевіряти, коли оператори регулярно запитують одне одного «у якому ми зараз режимі?», коли назва стану зрозуміла лише після довгого навчання, коли автоматичні переходи відбуваються мовчки або повідомляються на мить, коли однакові органи керування мають суттєво різні наслідки, а інтерфейс не робить контекст явним.
Сильним сигналом є також розходження між тим, що інженери вважають «очевидною логікою», і тим, як її пояснюють досвідчені оператори. Якщо для правильного прогнозу поведінки люди змушені запам’ятовувати винятки, не представлені в інтерфейсі, система накопичує когнітивний борг.
Окремої уваги потребують режими, які використовуються рідко, але виникають у критичній ситуації. Саме тут слабка практика, високий стрес і незвична конфігурація можуть збігтися. Дизайн повинен забезпечувати відновлення розуміння стану навіть для користувача, який давно не бачив цього сценарію.
Що робити після інциденту, пов’язаного з режимом
Розслідування починають із часової лінії технічних станів: який режим був активний, коли й чому відбувся перехід, які команди надійшли, що система показала, які підсистеми змінили поведінку. Потім цю лінію порівнюють із діями й доступною операторові інформацією.
Наступне завдання — реконструювати робочу модель людини: який режим вона вважала активним, чого очікувала від команди, які сигнали помітила, які пропустила та чому її припущення здавалося правдоподібним. Інтерв’ю корисне, але його треба зіставляти з логами, відео, телеметрією та інтерфейсними станами.
Далі аналізують дизайн, процедури, навчання, навантаження, переривання, командну взаємодію й організаційні умови. Така структура дозволяє сформувати коригувальні дії на правильному рівні: змінити режимну логіку, зробити перехід явним, перебудувати позначення, додати історію станів, змінити процедуру або оновити навчання.
У цьому сенсі плутанина режимів є конкретним прикладом того, чому людську помилку продуктивніше аналізувати як подію в системі, а не як остаточне пояснення.
Практичний приклад: одна кнопка, два режими
Уявімо систему, де кнопка «START» у режимі підготовки запускає автоматичний цикл, а в режимі паузи — лише відновлює останній етап. Якщо режим відображається маленькою піктограмою в кутку, оператор після переривання може натиснути кнопку, очікуючи повний запуск, хоча система продовжить процес із середини.
Тут немає потреби пояснювати інцидент неуважністю. Архітектура створила модальну залежність: одна дія має два різні наслідки, а критичний контекст слабко представлений. Варіанти редизайну включають різні команди для різних цілей, явне повідомлення про режим біля органу керування, попередній перегляд дії або підтвердження лише для справді небезпечного переходу.
Найкраще рішення залежить від частоти задач, ціни помилки, часу на дію та інших обмежень. Саме тому евристика «завжди додавайте підтвердження» не є універсальним психологічним законом: надлишкові підтвердження можуть стати ритуалом і втратити захисну функцію.
Роль ситуаційної обізнаності, навантаження і надійності людини
Плутанина режимів взаємодіє з іншими конструкціями F08, але зберігає власну предметну межу. Ситуаційна обізнаність допомагає описати ширший стан розуміння динамічної ситуації. Психічне робоче навантаження описує вимоги задачі до обмежених ресурсів. Людська надійність розглядає ймовірність успішного виконання функції в конкретних умовах.
Mode confusion фокусується на конкретному розриві: фактичний режим і модель режиму в оператора не збігаються або оператор неправильно прогнозує поведінку автоматизації. Таке фокусування дозволяє будувати спеціалізовані заходи дизайну замість загальної поради «зменшити навантаження» чи «покращити ситуаційну обізнаність».
Комерційні UX-евристики й safety-critical дизайн
Звичайні UX-евристики на кшталт «видимості стану системи» добре резонують із проблемою режимів, але евристика є професійним інструментом оцінювання, а не самостійним доказом безпеки. У safety-critical системі потрібні предметні hazard analysis, вимоги до людських факторів, випробування в реалістичних сценаріях і, де застосовно, регуляторна або стандартна верифікація.
ISO 9241-110 дає загальні принципи взаємодії, а ISO 9241-210 — процес людиноцентрованого проєктування. Сам ISO 9241-110 прямо зазначає, що загальна рамка не покриває специфіку кожної галузі, зокрема safety-critical систем ISO 9241-110:2020. Тому її використовують як один шар вимог, а не як заміну галузевим стандартам.
Так само популярні «закони UX» або дизайн-патерни не перетворюються автоматично на психологічні закони про mode confusion. Їхню доречність визначають механізм, контекст і емпірична перевірка.
Наукові межі доказової бази
Доказова база щодо mode confusion сильна в тому, що явище багаторазово описане в різних багаторежимних системах, має довгу історію human factors досліджень і підтримується операційними даними, симуляціями, експериментами, формальним аналізом та галузевими звітами. Особливо добре розроблена авіаційна традиція.
Водночас немає універсальної оцінки поширеності «плутанини режимів» для всіх систем, єдиної валідованої шкали або одного порога, після якого інтерфейс можна назвати небезпечним. Частина сучасних досліджень зосереджена на автоматизованому водінні, а їхні кількісні ефекти залежать від конкретних інтерфейсів і сценаріїв.
Окреме методологічне обмеження — латентність конструкта. Невідповідна режиму дія не доводить автоматично, що людина неправильно розуміла стан. Самозвіт також не є безпосереднім записом когнітивного процесу. Найсильніший висновок виникає, коли різні метрики збігаються і коли дослідник має точний запис фактичних режимів системи.
Тому професійне формулювання звучить так: mode confusion — емпірично підтримувана проблема взаємодії людини з багаторежимною автоматизацією; конкретний ризик і конкретне рішення треба встановлювати для певної системи, задачі та контексту.
FAQ
Чи є плутанина режимів просто різновидом людської помилки?
Плутанина режимів описує конкретний механізм розходження між фактичним режимом і розумінням системи оператором. Помилкова дія може бути наслідком цього розходження, але сама по собі не встановлює його. Для безпекового аналізу корисно відтворювати всю людино-технічну взаємодію, а не завершувати пояснення ярликом «людська помилка».
Чи достатньо постійно показувати назву активного режиму?
Назва допомагає, але повноцінна mode awareness часто потребує знання активних функцій, меж автоматизації, майбутнього переходу та ролі людини. Якщо технічна назва не дозволяє спрогнозувати поведінку, інтерфейс має дати функціональний контекст.
Чи допомагають звукові сигнали про зміну режиму?
Вони можуть покращити помітність переходу, особливо коли візуальний канал зайнятий. Ефект залежить від того, чи сигнал розрізнюваний, зрозумілий, достатньо рідкісний і пов’язаний із потрібною дією. Надлишкова сигналізація може створювати конкуренцію за увагу та взаємодіяти з втомою від сигналів тривоги.
Чи виникає mode confusion лише в авіації?
Ні. Авіація дала класичну доказову базу, але проблема досліджується також в автоматизованому водінні, робототехніці та інших багаторежимних системах. Огляд 2021 року прямо порівнює кілька таких доменів Dönmez Özkan та співавт., 2021.
Чи можна повністю усунути режими?
У багатьох складних системах режими функціонально необхідні. Проєктувальна мета полягає в тому, щоб мінімізувати приховану й непотрібну модальність, зробити важливі стани та переходи зрозумілими й забезпечити передбачувану поведінку.
Чи свідчить плутанина режимів про недостатню компетентність оператора?
Компетентність і навчання впливають на взаємодію, але mode confusion може виникати й у досвідчених користувачів, якщо логіка режимів складна, переходи приховані або сигнали не відповідають задачі. Класичні дослідження human factors саме тому розглядають явище як проблему координації людини й автоматизації.
Чим mode confusion відрізняється від out-of-the-loop problem?
Mode confusion фокусується на тому, чи правильно оператор розуміє конкретний стан і поведінку автоматизації. Вихід людини з контуру описує ширшу втрату залученості, знання процесу або готовності до втручання внаслідок автоматизації. Одне може посилювати інше, але механізми різні.
Як mode confusion пов’язане із ситуаційною обізнаністю?
Mode awareness часто розглядають як специфічний аспект розуміння людино-технічної системи всередині ширшої ситуаційної обізнаності. Для mode confusion ключове питання — чи збігається модель режиму й очікуваної поведінки з фактичним станом автоматизації.
Як перевірити ризик до запуску системи?
Потрібно описати режими й переходи, визначити знання, необхідне операторові, проаналізувати приховані й автоматичні зміни, провести human-in-the-loop випробування з номінальними та нештатними сценаріями й поєднати прямі та поведінкові метрики. Для критичних систем це доповнюється галузевими методами hazard analysis і верифікації.
Чи існує один стандарт, який вирішує проблему mode confusion?
Загальні стандарти ISO 9241-110 і ISO 9241-210 задають принципи взаємодії та людиноцентрованого проєктування. Safety-critical галузі мають додаткові нормативні вимоги й рекомендації. Mode confusion є міждисциплінарною проблемою, тому її контроль спирається на поєднання загальних принципів, предметних стандартів, human factors evidence та випробувань конкретної системи.