Главное преимущество на рынке устройств интернета вещей — стоимость. Поэтому приоритет отдается дешевым, но ненадежным компонентам. Ненадежные устройства ломаются, совершают ошибки, зависают и требуют обслуживания. Про ненадежность не принято говорить на конференциях, но как раз этому был посвящен доклад Станислава Елизарова (elstas) на InoThings++ — тому, как всё не работает.



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


О спикере: Станислав Елизаров занимается отделом сетевой инфраструктуры в компании «СТРИЖ», которая производит счетчики, датчики, базовые LTE-станции, а также собирает показания там, где любые другие системы связи просто не работают.

Ненадежность

«Если что-то не работает, то оно уже устарело».

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

Первые ошибки

Тема надежности, особенно ее часть — отказоустойчивость, такая же большая, как и безопасность. Буква S в термине IoT отвечает за Security, а буква R отвечает за Reliability — надежность.

Если говорить про надежность и ошибки, то давайте вспомним Иоганна Гутенберга. Официально он первый печатник, а по версии Ильфа и Петрова — первый опечатник, потому что в своей Библии допустил много ошибок.



Технология Гутенберга прогрессировала, рынок книг рос, увеличивались объемы, а с ними и ошибки. Через 50 лет после первой отпечатанной книги, Габриэль Пьерри придумал эррату — список опечаток в конце книги. Это был хороший трюк, потому что перепечатывать большие партии неудобно и экономически невыгодно. Если читатель заметит опечатку, то просто откроет список ошибок и посмотрит на критические исправления. Лидером опечаток был Фома Аквинский и его «Сумма теологии» — 180 страниц ошибок в официальной эррате.

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



Еще пример — микропроцессор MSP430, построенный на наборе команд. Микропроцессор примерно такой же, как PDP-11, на котором Керниган и Ритчи разрабатывали Unix. Это не эррата Фомы Аквинского, но 27 страниц ошибок производитель нам предлагает, многие из которых даже сам не знает, как решать.

Это именно то, что неочевидно в интернете вещей. Мы читаем datasheet дешёвого чипа и видим, что всё хорошо и всё работает, пока не открываем последние страницы со списком ошибок.

Человеческий фактор

С железом более-менее понятно, ошибки описаны и воспроизводимы, но самый больший источник ошибок в IoT-системах — человек.

13 января 2018 года всем жителям Гаваев на мобильные телефоны пришел alert о ракетной угрозе и о том, что нужно скрыться в бомбоубежище.



Непонятно, кто именно ошибся: оператор или человек, который проектировал интерфейс. Но если посмотреть на картинку, то ответ напрашивается сам собой. На что нажать, чтобы вызвать тестовое, а не боевое, оповещение о ракетной угрозе? Если вы не знаете ответ, то ошибетесь.




Оператор нажал не на ту кнопку, и запустилась массовая рассылка. У системы не было никаких параметров, по которым можно было бы предотвратить или подтвердить отправку: «Вы уверены, что хотите предупредить о ракетной угрозе?». 30 минут потребовалось сотрудникам центра, чтобы осознать произошедшее и выслать сообщение, в котором говорилось, что атака ложная.

Человек — надежная система

Почему мы не видим этих ошибок и не считаем, что что-то не так? Потому что сам человек и исправляет все ошибки.

Мы привыкли исправлять ошибки.

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

На фотографии ниже изображена человеческая смекалка, которой можно гордиться. Три человека болтались в «Аполлон-13» между Землей и Луной и смогли решить нетривиальную задачу — засунуть квадратный фильтр в круглое отверстие. Кроме квадратных фильтров, миссии не везло и в другом: взрыв кислородного баллона, нехватка воды, повреждение двигателя. Команда пыталась выжить с помощью носков, изоленты и упаковок от костюмов.



Человек, как говорили в NASA, — очень хорошая резервная система и многое исправляет. Решение проблем на космическом корабле с помощью изоленты и носков можно назвать почти надежным: оно выполнено в короткие сроки, гарантированно сработает и люди вернутся живыми, но в продакшн это пускать нельзя.

Проблема отказоустойчивости

Проблема отказоустойчивости для интернета вещей очень важна, потому что количество устройств растет. В отчете консалтинговой компании McKinsey, в 2013 году в мире работало 10 млрд. устройств IoT, а к 2020 году это число вырастет до 30 млрд.



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

В 2018 году в СМИ и научных журналах промелькнула новость, что китайцы покрыли 100 000 датчиков 2 канала общей длиной 1400 км. Всего 130 видов датчиков: воды, ветра, камеры. С точки зрения операционных расходов, система просто катастрофическая: какое количество людей нужно, чтобы протирать камеры или убирать коряги? Весь штат будет занят только чисткой и обслуживанием системы — она очень не автономна.

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

Представим: настанет тот день, когда к вам придут инвесторы за отчетом о проекте, и вам требуется показать работающий продукт. С чего начать, чтобы не облажаться?

Упрощение

На картинке ниже два не связанных друг с другом прибора. Слева — игрушка, которая называется «сортер»: вставляем круглое в круглое, а квадратное в квадратное. Годовалый ребенок научится пользоваться игрушкой за 2-3 попытки, потому что с «прибором» невозможно ошибиться — треугольник в квадрат не залезет.



Эту же идею предложила компания Harris, которая выпускает военные радиостанции. На картинке справа — Harris Falcon 3, чудо инженерной мысли. Посмотрите на интерфейсы, они все различные. В состоянии боя, в условиях, когда нет времени подумать, оператор физически не сможет сделать что-то не то. В разъем от антенны не войдет кабель питания, и простым перебором радист подключит все системы, даже не включая мозг. Это простой и работающий способ, чтобы не допустить ошибок и снизить их вероятность. Вы скажете:

— А если у нас завтра презентация. Нам что, все интерфейсы перепаивать? Мы там всё сделали одинаково: 4 usb-порта, 5 ethernet-портов, мы точно ошибемся.

Не вопрос, упрощение здесь тоже работает — всё закрыть. Если у вас 4 usb-порта и один их них гарантированно работает — оставьте, а все остальные закройте. Например, изолентой — почувствуйте себя астронавтом.

Упрощение — это не только создание интерфейса, в котором невозможны ошибки, но и удаление всего лишнего. С этого начинается надежность.

Мы создали простое устройство — прототип, готовый к показу. Что дальше? Дальше подумаем об избыточности.

Избыточность

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



Пример избыточности — сеть «СТРИЖ». Большинство устройств в сети передаются без подтверждения: устройство излучает сигнал, и базовая станция его принимает.

Представим ситуацию. У нас есть зона с помехами, в которой вероятность доставки сообщения на базовую станцию 90%, а на презентации требуется показать не больше 1% потерь. Кажется, что работы много: исправлять протоколы, уменьшать дальность, но быстрое и простое решение — избыточность. Рядом со станцией, которая принимает сигнал с вероятностью доставки 0,9 ставим вторую, с такой же вероятностью доставки, и вероятность отказа обеих станций одновременно равна 0,01. Здесь действует теорема умножения вероятностей: вероятность отказа каждой станции по отдельности — 0,1, а отказа сразу обеих как раз 1% при условии, что базовые станции независимы. В этой зоне между базовыми станциями будет самая высокая вероятность приема.



Еще один способ демонстрации принципа избыточности — Watchdog Timer. Это физическое устройство, которое встраивается большинством производителей процессоров. Если Watchdog Timer не принял сигнал от компьютера спустя определенный интервал времени, то устройство перезагружает компьютер.



При использовании WT повышается не надежность, а доступность. Компьютер детектирует проблему, принимает управляющие действия и перезагружает компьютер. Это очень любит NASA и знает множество разных способов использования Watchdog Timer.

Ниже пример многоступенчатого Watchdog Timer: при наступлении определенных событий он посылает NMI — аппаратное прерывание, которое будет обязательным в работе над процессором. Когда наступает некоторое событие, Watchdog сообщает компьютеру: «Попробуй перезагрузиться сам, иначе отключим питание». Если первый таймер не сработал, то будет работать второй.



Избыточность хорошо работает в рамках операционной системы. Наша базовая станция примерно так и устроена. Она состоит из различных и независимых модулей. Автономность модулей предотвращает попадание ошибки из одного модуля в другой — создается «бассейн» с ошибками, который мы блокируем. Выше по иерархии — набор супервайзеров: скрипты, которые мониторят ситуацию по определенным параметрам. Например, что процесс есть в операционной системе, он не Зомби и не течет по памяти. Корневой элемент — планировщик, например, cron.



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

Переход в другую систему отсчета

Мой самый любимый и популярный среди математиков метод. Если известно, при каких условиях работает оборудование, то в этих условиях и нужно проводить пилот. Покажу на примерах.

Пример № 1. Мы создали устройство, которое хорошо работает при комнатной температуре, а нам сообщают:

— Проект демонстрируем на Дальнем Севере. Сейчас там ?40, но сделайте так, чтобы все работало.

Мы бежим в интернет и ищем решение:

— Нам нужны термостабильные кварцы и флешки, которые не откажут при ?40.

Время идет, ресурсов всё меньше, а паники — больше. Мы думаем, что проект провален, но нас спасёт переход в систему отсчета, в которой работает базовая станция. Поместим устройство в ящик, в котором находятся подогреватель и термореле. Они достаточно стабильные ребята и работают практически всегда. Когда снаружи холодно — ящик подогревается, и устройство работает в нормальных условиях — мы перешли в систему отсчета, в которой знаем и используем решение.



Пример № 2. Переход в движущиеся системы отсчета. Представим, что собираем данные контейнеров с поезда. Первое стандартное решение — использовать gsm-модемы. Этот способ не подходит: для быстро перемещающихся объектов следует использовать LTE или 5G устройства, которые хорошо справляются с доплером, а это дорого. Если поезд двигается по России, то когда он прибудет на ж/д станцию, все модемы подключатся к станции и она просто упадет из-за перегрузки сети.

Решение: переход в неподвижную систему отсчета. Вспомним про относительность движения: поместим базовую станцию внутри поезда и относительно движущегося состава она неподвижна. Станция будет собирать информацию со всех датчиков и передавать дальше с помощью шлюза, спутника или LTE-модема.

Этот подход повышает надежность, помогает решать невозможные задачи и организовать delay-tolerant networking — сеть, устойчивую к разрывам. Подход почему-то не любят в России, но активно продвигает подразделение Disney Research той же корпорации. У них не интернет вещей, а интернет игрушек — Internet of Toys. В компании беспокоятся, что африканские дети не смотрят Диснеевские мультики. Проводить сети передачи данных, устанавливать вышки, тянуть оптоволокно в Африке дорого, и всё равно всё украдут, поэтому они пошли другим путём и использовали идеи Ричарда Хэмминга:

Передача на расстоянии — то же самое, что передача во времени, то есть хранение. Если вы не можете передать — сохраните информацию и перевезите её к приемнику.

В Disney так и сделали: оснастили автобусные станции и автобусы системой из самых дешевых Wi-Fi роутеров и набора жестких дисков. Автобус подъезжает к станции, быстро закачивает на диски набор фильмов Disney по Wi-Fi и едет дальше. Приезжает в одну деревню, в другую, и в каждой выгружает фильмы — африканские дети довольны. Это, так называемая Мул-Нетворкс — дешевые мулы, которые передвигаются медленно, плохо справляются с доплером, но доставляют информацию во все точки.



Подобные разработки в Disney существуют и для передачи email — письмо приедет к вам на автобусе. Очень забавная технология, но ее любит, например, компания Amazon.

У Amazon есть сервис для перевозки эксабайт данных — одного миллиона терабайт. Если у вас большой дата-центр и вы думаете перемещаться на Amazon, потому что все уже там, то в Америке они могут подогнать к вам такой грузовик и перевезти ваши данные. Если вам не важны задержки, то это хороший способ: скорость передачи данных порядка десятков или сотен Гбит/с. Кроме грузовиков, Amazon может прислать к вам сумку с жесткими дисками — snowball.



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

Красота

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

Выводы

Будущее интернета вещей — ненадежность: IoT нацелен на массовые рынки, а для масс-маркета решающий фактор — это цена. Значит интернет вещей будет состоять из множества дешевых и ненадежных устройств. С ростом числа устройств будет расти и число отказов. У нас просто не хватит рук, чтобы исправлять все ошибки. Поэтому единственный путь — устройства должны самостоятельно бороться с последствиями отказов. Это автономные системы, которые должны учиться чинить себя сами.

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

Книг или набора статей по надежности нет. Чтобы углубиться в тему, начните со статьи о работоспособности, надежности, безопасности, а дальше изучайте опыт лаборатории реактивного движения NASA. Они создали Voyager и Curiosity и знают про надёжность всё. Вдохновляйтесь великими.

До следующей конференции разработчиков интернета вещей InoThings++ осталось чуть больше месяца, она пройдет 4 апреля. Мы подготовим программу, которая охватит все аспекты мира интернета вещей: разработку аппаратного и программного обеспечения устройств, безопасность для пользователей, способы передачи информации между устройствами и «сервером» и их тестирование, эксплуатацию и изменение бизнес-процессов под влиянием IoT-технологий. Но, возможно, именно вашего доклада не хватает, чтобы осветить все темы — подайте заявку до 1 марта.