Решение проблем стороннего вмешательства в работу сервера штабелеров

[korvin]

Сейчас возникла проблема, когда на Deliver Ezz даются команды роботам в неотключенным сервером штабелеров. Это сбивает логику работу сервера, и приводит к простоям. Сделать возможным обработку таких "вмешательств" со стороны сервера, как предложил Олег Жижий, считаю нереальным. Поскольку таким образом кардинально решить проблему не получится. Лишь до бесконечности затыкать дыры. И, помимо этого, усложнять и так непростой код сервера штабелеров.
Предлагаю сделать вот что:

• на стороне робота завести:
  
  • регистр-ячейку "Master" памяти - на кого сейчас работает робот - три варианта:
    
    • на сервер штабелеров
    • на сторонние программы
    • неопределено
  • если робот работает на сервер штабелеров, то он не принимает команды от сторонних программ
  • если робот работает на сторонних программы, то он не принимает команды от сервера штабелеров
  • если команда от сервера штабелеров, то в ней будет встроен специальный маркер. Команды от других программ к роботам будут идти без этого маркера
  • переключение между "хозяевами" робота происходит следующим образом:
    
    • если "Master"= неопределено, то любая команда от сервера штабелеров переводит "Master"=на сервер штабелеров
    • если "Master"= неопределено, то любая команда от сторонней программы переводит "Master"=на сторонние программы
    • если "Master"= на стороннюю программу, то переключение "Master" в "на сервер штабелеров" происходит по специальной команде
    • если "Master"= на сервер штабелеров, то переключение "Master" в "неопределено" происходит по специальной команде
      
• на стороне сервера штабелеров:
  
  • любой робот можно будет поставить "на паузу" - при этом шлется соотв. команда роботу по смене "Master" на "неопределено"
  • любой робот из паузы можно будет "снять" - при этом шлется соотв. команда роботу по смене "Master" на "на сервер штабелеров"
  • при постановке на паузу всего АСК, соотв. команды шлются всем роботам
  • при снятии с паузы всего АСК, соотв. команды шлются всем роботам
  • также при снятии с паузы всего АСК или перезапуске системы сервер штабелеров проверяет соответствие реальной ситуации с тем, что есть в его модели. Если что-то не соответствует, то:
    
    • то, что можно, сервер пытается поправить в своей модели
    • если расхождения большие, то сервер выдает сообщение об ошибке с детальным указанием, что стоит поправить, и не снимает АСК с паузы

[Tymofiy]

1) Проблема не в сторонних командах. "ПО сервера штабеллеров" с момента создания должно анализировать идентификатор команды
и только после этого результат выполнения. Для обеспечения работоспособности в "ПО Агент.Сенсорлинк" уже добавлено несколько костылей,
один из которых сломался на Деливириз.
2) Считаю правильным исправить ПО сервер штабеллеров:
- логичность. Привести в соответствие с идеями заложенными в начале;
- простота реализации. Если идентификатор не совпадает с текущим - игнорировать состояние команды робота;
- оптимальность. Изменение протокола влечет за собой изменение всего существующего ПО как Сармат так и Сенсорлинк, а изменение
сервера штабелеров ведет к изменению только ПО Сармат.
3) Так же считаю необходимым добавить в алгоритм анализ наличия контейнера на площадке стола.

[Zhyzhiy]

Насколько я понимаю данное предложение в разы сложнее моего предложения и потребует массу тестов и проверок мое же предложение достаточно простое.
Сейчас замечено 2 ошибки в работе сервера:
1. (довольно старая и существует со времен ЭТМ) роботы обнаружены не в своих секциях, сейчас в данном случае происходит крах сервера с вмешательством для решения разработчика, что необходимо для исправления:
В случае появления роботов не в ожидаемых секциях перевести сервер в паузу и предложить:
а. в ручном режиме переместить роботов в указанные позиции
б. добавить в сервер возможность нажатием кнопки дать 2 команды move роботам (с учетом их не столкновения) в нужные секции.
В режим work сервер не переводить до тех пор пока роботы не окажутся в нужных секциях выдавая соответствующее сообщение при нажатии на кнопку work.
На мой взгляд такая переделка не потребует особых изменений, т.к. сервер уже определяет. что роботы не в своих секциях.
2. (обнаружился вчера). При ложном возврате серверу состояния робота READY CMD_FAULT с несуществующим для сервера id команды, по не понятной причине привел к проблеме работы сервера, хотя изначально оговаривалось, что у каждой команды есть свой уникальный id, который и позволяет определять для какой команды состояние возвращается. При этом у сервера не было текущих команд, состояния которых надо было бы анализировать.
Также есть 2 варианта решения:
а. перевести сервер в паузу с сообщением вернуть роботов с нужные секции, обеспечить на роботах состояние READY и CMD_SUCCESS. При нажатии work, в случае не соблюдения нужных условий, выдавать сообщение и не изменять состояние сервера.
б. добавить в анализ результата команды еще и анализ соответствия id команды, что было предусмотрено изначально. В случае, если id не совпадает и нет не завершенной команды, то и анализировать состояние команды нет смысла. Если команда есть, но id не совпадает, то выдать соответствующее сообщение и перейти в состояние паузы. Далее как в п.2.а.

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

[Tymofiy]

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

[korvin]

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

Такое можно сделать, но проблема в том, что мы не можем знать и не можем предугадать, как именно человек вмешается в работу роботов. А раз так, то у нас имеется бесконечный автомат. А не классический конечный как сейчас. Можно, конечно же, попытаться покрыть бесконечный автомат путем расширения конечного автомата. К примеру, сейчас у конечного автомата есть около 20 состояний, которые отрабатываются сервером штабелеров. При этом в логике автомата предполагается, что роботом управляет только он. Это сделано для упрощения логики и снижения конечных состояний автомата.
Чтобы система корректно работала в процессе ручного вмешательства, нужно каждое из этих состояний усложнить на порядок. Т.е. получаем 20*10=200 состояний, которые сервер штабелеров должен корректно обрабатывать. Тогда, с 95% вероятностью, сервер штабалеров будет обрабатывать вмешательства в его работу сторонних программ. На детальное описание, обработку, тестирование, проверку на реальных роботах каждого состояния уйдет как минимум 1 рабочий день программиста. Т.е. для реализация конечного автомата из 200 состояний потребуется как минимум 200 трудодней АСУТП программиста и реальный 2-х роботный огурец для тестирования. Поскольку на эмуляторе невозможно со 100% точностью восстановить ситуацию с ошибками.
Кроме того, конечный автомат из 200 состояний все равно не даст 100% гарантии, поскольку на практике обходятся даже сложные банковские системы защиты, ибо человеческий фактор, что-то не доглядели, или пользователь извернулся и сделал по-хитрому.
Мне же не хочется что-то делать на-шармачка. Хочется сделать реально надежную вещь. А для этого нужно разграничить ответственность. Если сервер управляет роботами, то никто в это не должен вмешиваться (кроме срочных команд STOP в экстремальных случаях).
Если у Вас есть мысли, как по-иному добиться блокировки робота программой - предлагайте!

[korvin]

Насколько я понимаю данное предложение в разы сложнее моего предложения и потребует массу тестов и проверок мое же предложение достаточно простое.
Сейчас замечено 2 ошибки в работе сервера:
1. (довольно старая и существует со времен ЭТМ) роботы обнаружены не в своих секциях, сейчас в данном случае происходит крах сервера с вмешательством для решения разработчика, что необходимо для исправления:
В случае появления роботов не в ожидаемых секциях перевести сервер в паузу и предложить:
а. в ручном режиме переместить роботов в указанные позиции

такое сделать несложно.

б. добавить в сервер возможность нажатием кнопки дать 2 команды move роботам (с учетом их не столкновения) в нужные секции.

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

Тут отдельный вопрос по ЭТМ - у них работает старая версия ПО. У нас есть новая, в т.ч. с механизмом простого перехода на работу с одним роботом. Но чтобы накатить новую версию, нужно время. Также нужно время для отладки - ненапряжная работа АСК в течении 1-2 дней. Но как на ЭТМ это организовать?

2. (обнаружился вчера). При ложном возврате серверу состояния робота READY CMD_FAULT с несуществующим для сервера id команды, по не понятной причине привел к проблеме работы сервера, хотя изначально оговаривалось, что у каждой команды есть свой уникальный id, который и позволяет определять для какой команды состояние возвращается. При этом у сервера не было текущих команд, состояния которых надо было бы анализировать.
Также есть 2 варианта решения:
а. перевести сервер в паузу с сообщением вернуть роботов с нужные секции, обеспечить на роботах состояние READY и CMD_SUCCESS. При нажатии work, в случае не соблюдения нужных условий, выдавать сообщение и не изменять состояние сервера.
б. добавить в анализ результата команды еще и анализ соответствия id команды, что было предусмотрено изначально. В случае, если id не совпадает и нет не завершенной команды, то и анализировать состояние команды нет смысла. Если команда есть, но id не совпадает, то выдать соответствующее сообщение и перейти в состояние паузы. Далее как в п.2.а.

Это все можно сделать, но это - затычка, до новых вмешательств.

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

Аварийные команды - это "Stop" - они должны отрабатываться в любом случае. И в любом случае для восстановления работоспособности АСК нужна будет работа специалиста.

[Tymofiy]

Если вы покажете диаграмму состояний автомата, я возможно смогу что-то посоветовать или признать свою неправоту.

[korvin]

Если вы покажете диаграмму состояний автомата, я возможно смогу что-то посоветовать или признать свою неправоту.

Для высокоуровневых программ диаграмму состояний автомата не составляют - слишком она получается большой и нечитаемой. Для примера могу выставить серверный исходник управления роботами - ловите! Там 3000 строк кода, и практически каждый if ... then ... else это есть состояния автомата.
Для понимания сложности - к примеру, последняя ошибка - когда робот возвращает cmd_fault с несуществующим cmd_id. Кажется, мелчоь - проверить возвращенный cmd_id, и, если такой команды сервер не давал, то игнорировать этот cmd_fault и действовать по общему алгоритму. Однако:

• этот момент нужно отладить, а не надеяться на авось, для этого нужно доработать нашу систему генерации ошибок эмулятора, чтобы она умела генерировать такие ошибки. Сейчас наш эмулятор такие ошибки генерить не умеет.
• после доработки эмулятора, нужно оттестировать такое состояние автомата со всеми его подсостояниями. Ведь может быть вариант, когда нельзя игнорировать неверное cmd_id при cmd_fault. Вопрос - когда. Тут нужно думать.
• и самое печальное, что мы все равно не сможем гарантировать, что на 100% обработали эту ошибку. Как оно будет в реальности? Возможно, сервер проигнорирует данную ошибку, а ее игнорировать нельзя было.

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