О важности подтверждения управляющих команд на примере «Делимобиля»

При проектировании IoT-систем, например, каршеринга, очень важно учитывать возможные сбои. В противном случае вас ожидает критическая нагрузка на техподдержку и недовольство клиентов.

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

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

Этапы могут зависеть от архитектуры системы, но сценарий в общем случае такой:

Вы нажимаете кнопку "Забронировать". Посылается команда на сервер. Она может дойти или не дойти.

Вы нажимаете кнопку "Открыть машину". Посылается команда на сервер. Она может дойти или не дойти. Сервер посылает команду машине. Она может дойти или не дойти. Бортовое устройство пытается исполнить команду. Она может выполниться или не выполниться.

Вы нажимаете кнопку "Начать поездку". Посылается команда на сервер. Она может дойти или не дойти. Сервер посылает команду машине. Она может дойти или не дойти. Бортовое устройство пытается исполнить команду. Она может выполниться или не выполниться.

Да, это поверхностно и на самом деле проблем безумное количество, но рассмотрим сейчас только эти.

Предположим, что все команды дошли и все актуаторы сработали - успех! Можно демонстрировать инвесторам.

Но что будет, если, например, до машины не дойдет команда "Открыть двери"?

Во-первых, об этом должен узнать сервер. Для того, чтобы реальное состояние машины было синхронизировано с сервером обычно используют подтверждение приёма команды (ACK). И еще подтверждение исполнения команды. Ведь "команда не доставлена" и "команда не исполнена" - разные события и подразумевают разные попытки решения.

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

В Делимобиле у вас начнется поездка.

И разговор с оператором техподдержки.

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

Холодным вечером 24 сентября я возвращался домой. Забронировал машину и пришел к ней.

Нажал "Начать осмотр", но двери не открылись.

- Ну ладно, наверное, опять сбой связи. Возьму другую. Тем более, вон их как много!

Нажал "Завершить аренду" - "Ты находишься вне зоны парковки"

Звоню в поддержку, описываю ситуацию. Оператор пытается открыть двери. Неудача. Музыка. Двери открываются. Спасибо.

- Наверное, серваки сбоили. Ладно, поехали. Жму "Начать поездку" - приложение начало отсчитывать деньги.

Не заводится.

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

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

Стекло не опускается. Видимо, без команды от сервера машина не включает зажигание. Но где ж её взять - связи то нет.

- Тогда нужно дождаться механика. 1-1.5 часа.

- Но тут холодно. Тут еще 3-4 человека вокруг машин Делимобиля с телефонами ходят. Может к ним уже выслали меха...

<двери машины внезапно закрылись>

- А, все. Спасибо. Поеду на маршрутке.

Во-первых, если с машиной связи нет, возможно, её не стоит отображать на карте.

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

В-третьих, можно создать резервный канал связи - второй модем с другим оператором (На телефоне то у меня интернет был). Или Bluetooth, как это сделано в Белке и YouDrive. (Возможно, этот вариант не для Делимобиля, так как это увеличит затраты на разработку и поддержку, а ДМ самый дешевый среди массовых)

А пока Делимобиль копит машины "закрытые вручную " и нагружает свою техподдержку из-за отсутствия подтверждения о доставке управляющих команд. При этом машины без связи видны на карте и доступны для бронирования.

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

Но почему тогда могла возникнуть такая ситуация? На мой взгляд, вероятные причины две.

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

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

Часто эффективное руководство может требовать новые функции, которые, по их мнению, увеличат доходы компании. При этом, коммерческого потенциала в увеличении надежности они не видят.

Локально, Делимобилю нужно решать проблему с парковкой в Сколково. Там простаивают очень много машин. Маловероятно, что им удастся договориться с сотовым оператором об улучшении качества связи. Поэтому, самым вероятным мне кажется исход, при котором они запретят там парковаться и своими силами перевезут машины в Москву. Грустный исход :( Как вы думаете, можно решить эту проблему по-другому?

Глобально - технические менеджеры должны отстаивать необходимость увеличения надежности. По крайней мере в Делимобиле теперь у них есть аргумент.

P.S. Отдельное спасибо замученным ребятам из техподдержки. Они вежливые и стараются решить проблему.