(3) 8. Взаимодействие человека и машины должно быть оперативно надежным ✦ В тех случаях, когда беспилотные системы взаимодействуют с береговыми операторами, бортовым персоналом, системами управления движением судов (VTS), портами или другими судами, эти интерфейсы должны быть четкими, проверенными и однозначными. Слабые механизмы передачи управления, нечеткие роли мониторинга или плохо понятая логика вмешательства — это не незначительные проблемы проектирования. Это операционные риски. Реальные проблемы HMI в автономных и дистанционно управляемых системах, как правило, возникают не из-за плохих интерфейсов как таковых, а из-за когнитивных ограничений человека, конфликтов полномочий между человеком и автоматикой, задержек, неопределенностей и потери контекста. В целом человек плохо справляется с задачами класса "просто следим и вмешиваемся, если что-то пошло не так". Очень часто проблема в том, что система ведет себя не так, как оператор думает, что как она себя ведет. Экспериментально доказано, что в случае систем с высокой автономией человек начинает доверять системе больше, чем нужно, игнонируя реальность и интуицию и в итоге не вмешивается вовремя. Важно придерживаться подхода HFE - важно не столько то, что "интерфейс удобен", сколько то, чтобы человек мог реально ею управлять. Он должен учитывать нагрузку на оператора, время его реакции, усталость и стресс, количество одновременно контролируемых объектов, вероятности ошибок и так далее. В целом в случае автономных систем важно учитывать теорию управляющего контроля, поскольку человек не управляет напрямую, а контролирует автоматическую систему, которая сама собой управляет. Проблема в том, что человек не находится постоянно в контуре принятия решений, а значит рано или поздно теряет контекст и понимание ситуации в целом не готов быстро вмешаться в нее. 9. Киберустойчивость и целостность данных должны рассматриваться как вопросы безопасности ✦ В беспилотных морских операциях киберустойчивость неотделима от навигационной безопасности. Система, зависящая от цифровой инфраструктуры, удаленных каналов связи, данных позиционирования, объединения данных с датчиков и программной логики принятия решений, не может считаться оперативно надежной, если эти элементы уязвимы для компрометации, повреждения или потери. Поэтому устойчивость должна быть частью обоснования безопасности, а не находиться вне его. Наверное стоило бы говорить не узко о кибербезопасности, но в целом о целостности и защищенности системы. 10. Решения должны быть объяснимы и поддаваться проверке после события ✦ В случае инцидента должна быть возможность понять, что именно система обнаружила, как она интерпретировала ситуацию, какие предположения сделала, какие варианты рассмотрела и почему действовала именно так. Без объяснимости гарантия становится слабой. Без возможности проверки подотчетность становится еще слабее. Объяснимость важна, но здесь может наблюдаться конфликт с производительностью. Есть известная проблема: "объяснимость" как правило не дает оптимальных результатов. Такие системы как ML, sensor fusion и вероятностные планеры, как правило, не полностью объясним. Если требовать полной объяснимости, мы можем вычеркнуть целые классы лучших решений. Возможно стоило бы быть менее категоричными в требованиях объяснимости и говорить об уровне объяснимости, уровне проверяемости и уровне отслеживаемости причин решений. (..)