Андре Кокуччо, директор MSE International, основатель ClearSeas Maritime и CMarTech FIMarEST AFNI сформулировал 10 правил, которые должны лежать в основе проектирования и эксплуатации беспилотных морских систем. Мне они понравились, не хочу их критиковать, но при их изучении возникают вопросы. 

1. Безопасность жизни должна оставаться первостепенным принципом

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

Хороший лозунг, но хотелось бы спрость - а как быть в ситуациях конфликта рисков? Как определить допустимый риск? Возможно стоило бы связать этот тезис с подходами ALARP (As Low As Reasonably Practicable) - это концепция управления рисками, которая предполагает снижение рисков до минимально возможного уровня, который является приемлемым с экономической, социальной и практической точек зрения, с проектированием на основе оценки рисков (risc-based design)?

2. Поведение системы должно быть узнаваемым как пример хорошего мореходства

Система не должна просто выдавать технически надежный результат. Она должна вести себя таким образом, чтобы другие моряки, операторы и органы власти могли интерпретировать, предвидеть и реагировать на это с уверенностью. В море безопасное поведение зависит не только от правильности, но и от ясности, сдержанности и своевременности.

В целом идея понятна, но есть разные походы в разных странах и даже COLREG допускают толкования. Было бы неплохо двигаться от "узнаваемое" к "формально описываемое, проверяемое, машинно-интерпретируемое". 

3. Соответствие должно быть продемонстрировано на практике

Недостаточно просто заявить, что система разработана с учетом правил. Она должна функционировать таким образом, чтобы демонстрировать практическое соответствие навигационным обязательствам, включая наблюдение, безопасную скорость, предотвращение столкновений и принятие обоснованных решений в контексте. Нормативно-правовое соответствие, существующее только на бумаге, имеет ограниченную практическую ценность.

Тезис поддерживаю, но важно было бы пояснить, о какой методологии демонстрации идет речь - это симуляции, испытания, сертификация и т.п.? 

4. Система должна распознавать и управлять неопределенностью

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

Очень важный тезис, но как именно измерять неопределенность? Что считать деградацией или потерей уверенности? Без количественной модели - это лозунг, а не инженерное требование. 

5. Эксплуатационные ограничения должны быть четко определены

Беспилотные морские системы должны иметь четко определенные эксплуатационные параметры, охватывающие окружающую среду, сложность движения судов, характеристики связи, целостность датчиков и условия выполнения миссии. Эти ограничения должны быть понятны не только проектировщикам, но и операторам, регулирующим органам и другим соответствующим инстанциям. Система, границы которой нечеткие, — это система, безопасность которой трудно обеспечить.

Кто должен установить ограничения? Речь же про  ODD (Operational Design Domain), границы, за пределами которых система не гарантирует корректной и безопасной работы? Разработчик, оператор, класс, регулятор, страховщик? В зависимости от ответа на этот вопрос возможны различные риски, например, если доверить ODD разработчику, то возможен конфликт интересов, если этим займется регулятор, это будет замедлять инновации, если это будет делать оператор - это риски. 

6. Система должна безопасно выходить из строя и безопасно деградировать

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

В море не всегда реализуемы ни safe fail, ни safe degrade. Остановка, маневр и дрейф - любое из этих действий может быть опасным для судна или окружающих в зависимости от операционной обстановки. Люди не всегда справляются с решением этой задачи, почему мы можем ожидать этого от техники. Возможно стоит задуматься о зависящих от операционной обстановки режимах безопасного поведения, продумать иерархию состояний безопасности.   

7. Ответственность человека должна оставаться очевидной

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

Да, все хотели бы, чтобы ответственным оставался человек. Сейчас это уже "политический лозунг". Но это противоречит развитию технологий. Если система, например, принимает решения и действует быстрее человека, то как "оператор" или "наблюдающий" за автономной системой могут за это отвечать? В авиации, например, это уже вызывает дискуссии. Кроме того, здесь стоит выделять разных ответственных - оператора, проектировщика системы автономизации (?), производителя робота (?). 

8. Взаимодействие человека и машины должно быть оперативно надежным

В тех случаях, когда беспилотные системы взаимодействуют с береговыми операторами, бортовым персоналом, системами управления движением судов (VTS), портами или другими судами, эти интерфейсы должны быть четкими, проверенными и однозначными. Слабые механизмы передачи управления, нечеткие роли мониторинга или плохо понятая логика вмешательства — это не незначительные проблемы проектирования. Это операционные риски.

Реальные проблемы HMI в автономных и дистанционно управляемых системах, как правило, возникают не из-за плохих интерфейсов как таковых, а из-за когнитивных ограничений человека, конфликтов полномочий между человеком и автоматикой, задержек, неопределенностей и потери контекста. В целом человек плохо справляется с задачами класса "просто следим и вмешиваемся, если что-то пошло не так". Очень часто проблема в том, что система ведет себя не так, как оператор думает, что как она себя ведет. Экспериментально доказано, что в случае систем с высокой автономией человек начинает доверять системе больше, чем нужно, игнонируя реальность и интуицию и в итоге не вмешивается вовремя. 

Важно придерживаться подхода HFE - важно не столько то, что "интерфейс удобен", сколько то, чтобы человек мог реально ею управлять. Он должен учитывать нагрузку на оператора, время его реакции, усталость и стресс, количество одновременно контролируемых объектов, вероятности ошибок и так далее. 
В целом в случае автономных систем важно учитывать теорию управляющего контроля, поскольку человек не управляет напрямую, а контролирует автоматическую систему, которая сама собой управляет. Проблема в том, что человек не находится постоянно в контуре принятия решений, а значит рано или поздно теряет контекст и понимание ситуации в целом не готов быстро вмешаться в нее. 

9. Киберустойчивость и целостность данных должны рассматриваться как вопросы безопасности

В беспилотных морских операциях киберустойчивость неотделима от навигационной безопасности. Система, зависящая от цифровой инфраструктуры, удаленных каналов связи, данных позиционирования, объединения данных с датчиков и программной логики принятия решений, не может считаться оперативно надежной, если эти элементы уязвимы для компрометации, повреждения или потери. Поэтому устойчивость должна быть частью обоснования безопасности, а не находиться вне его.

Наверное стоило бы говорить не узко о кибербезопасности, но в целом о целостности и защищенности системы. 

10. Решения должны быть объяснимы и поддаваться проверке после события

В случае инцидента должна быть возможность понять, что именно система обнаружила, как она интерпретировала ситуацию, какие предположения сделала, какие варианты рассмотрела и почему действовала именно так. Без объяснимости гарантия становится слабой. Без возможности проверки подотчетность становится еще слабее.

Объяснимость важна, но здесь может наблюдаться конфликт с производительностью. Есть известная проблема: "объяснимость" как правило не дает оптимальных результатов. Такие системы как ML, sensor fusion и вероятностные планеры, как правило, не полностью объясним. Если требовать полной объяснимости, мы можем вычеркнуть целые классы лучших решений. Возможно стоило бы быть менее категоричными в требованиях объяснимости и говорить об уровне объяснимости, уровне проверяемости и уровне отслеживаемости причин решений. 

--  

Понятно, что автор не предлагал стандарт, но некоторую философию, отношение к проблеме - в этом плане его хочется всячески поддержать. Но даже на уровне философии, хотелось бы представлять, как увязываются различные правила из списка. Например, что важнее - объяснимость или безопасность, автономия или узнаваемость. Конфликты здесь неизбежны. 

Было бы интересно попробовать формализовать эту философию, ввести количественные критерии, мехнизмы проверки и разрешения конфликтов между принципами. Только в этом случае появилась бы основа для проектирования, сертификации и эксплуатации беспилотных морских систем.  □