Почему недостаточно Arduino, чтобы автоматизировать производство?
Источник фото: Unsplash.com
Сегодня доступен целый ассортимент электронных конструкторов, которые можно использовать для автоматизации пет-проектов. Хочется самодельный робот-пылесос или 3D-принтер — пожалуйста, есть Lego, Arduino или Raspberry Pi. Их просто купить и легко запрограммировать. Почему же нельзя использовать тот же подход в профессиональных применениях? Зачем тратить в несколько раз больше денег и сил на разработку и программирование специализированной промышленной электроники?
На факультете программной инженерии и компьютерной техники в ИТМО уже больше 30 лет занимаются разработкой специализированных систем. Мы, декан факультета, Павел Кустарев и руководитель международной лаборатории «Архитектура и методы проектирования встраиваемых систем и систем на кристалле», Алексей Платунов, рассказываем, почему решения на базе «бытовых» конструкторов ненадежны во всех отношениях.
Одна история про автоматизацию на Raspberry Pi
Обычная история — берем Raspberry Pi или Arduino, красивую и простую среду разработки и создаем собственное устройство, которое будет выполнять какую-то полезную функцию.
Пример проекта на конструкторе
За примерами далеко ходить не надо: один из профессоров нашего факультета на даче собрал инкубатор для яиц. Купил компоненты, проработал алгоритм, запустил, убедился, что схема работает без сбоев, и уехал. А вернувшись, получил вместо птиц десяток яиц всмятку. Как выяснилось, в его отсутствие произошел сбой по питанию и система некорректно перезапустилась, в результате яйца спеклись.
Для нашего профессора история закончилась подпорченным настроением и затратами на покупку второго десятка перепелиных яиц. Но представим, что это не собственный проект с минимальными затратами, а, например, сборочная линия на производстве или система управления наружным освещением на удаленной трассе. Здесь цена ошибки гораздо выше— испорченная партия продукции в первом случае и повышенная аварийность на сложных участках дороги во втором. И если на производстве обычно есть контроль качества, который быстро отреагирует и отправит ремонтную бригаду в нужный цех, то быстро приехать к участку без освещения на трассе уже нельзя, да и в принципе приехать дорого. При этом каждый час простоя системы — прямой риск для людей.
Что не так с конструкторами
Запрограммировать алгоритм для плат из «бытовых» конструкторов легко. И все будет работать, но в идеальных условиях на рабочем столе — при комнатной температуре, стандартной влажности, в отсутствии электропомех и при стабильном электропитании. Как только речь зайдет о реальных промышленных применениях, начнутся сложности.
Источник фото: Tindie.com
На физическом уровне микросхемы, да и прочие компоненты устройств имеют несколько вариантов исполнения. Коммерческое исполнение — более дешевое. Оно предназначено для «бытового» применения. Как правило, это не критичные устройства, при поломке которых не возникнет опасности для жизни человека и не будет серьезных финансовых потерь. При производстве компонент в промышленном исполнении применяется другой уровень контроля качества, да и в целом иные технологии производства. О них и поговорим.
Температура и влажность
Используемая в коммерческих устройствах компонентная база (микросхемы и другие элементы) обычно имеет рабочий диапазон от -10 до +70 градусов по Цельсию.
Если греть схемы до более высоких температур, они будут работать некорректно — уедут заданные производителем частоты, чаще будут появляться ошибки. Из-за температурных колебаний меняются параметры диэлектриков и электролитов, они могут безвозвратно деградировать, в результате схемы перестают корректно работать. Начинают врать датчики, сбоить источники питания, неправильно работают аппаратные интерфейсы. В итоге устройство как бы не вышло из строя, но со своей задачей уже не справляется. А при нарушении работы цепей питания может и перегореть.
Материалы, используемые для производства устройств (тот же пластик), имеют свои коэффициенты температурного расширения. На жаре корпус из такого пластика будет слишком расширяться и перестанет достаточно хорошо защищать плату, так что к ней проникнет влага. В зависимости от внешних условий меняются и другие их характеристики. Например, некоторые пластики на холоде становятся хрупкими, поэтому их нельзя использовать для производства разъемов или корпусов устройств, которые будут эксплуатироваться на морозе.
Выше мы не зря использовали пример с системой управления наружным освещением. Одна из наших лабораторий разрабатывает контроллеры, управляющие внешним освещением, которые работают в достаточно жестких условиях — на улицах городов с разным климатом и на протяженных трассах.
Температура воздуха в местах установки контроллеров варьируется от -45 до +45. А внутри корпуса с учетом солнца в жаркий полдень и разогрева самих компонент во время работы в отдельных точках платы может быть все +90. Уже по этому температурному диапазону платы из электронных конструкторов типа Arduino не подходят — допустимые температуры для них от -25 до +70 градусов Цельсия (хотя в datasheet указаны более широкие диапазоны, сам производитель озвучивает в FAQ такие рекомендации).
Источник: youtube-канал LET’S MELT THIS
На то чтобы учесть все климатические особенности отдельных регионов — выявить все нестабильности в работе и устранить их за счет технических решений — у нас ушло около 5 лет. То год выдастся особенно солнечный, и мы боремся с излишним нагревом, то зимой слишком сыро, так что все обледеневает. Одно дело — видеть усредненную статистику по климату, например, в Архангельске, но совсем другое — постоянно сталкиваться с реальными проблемами в точке, для которой и статистики-то нет — где-нибудь на краю болота или на горке с сильным ветром. В одних случаях нужно предусмотреть дополнительные уплотнения крышки корпуса, а где-то, наоборот, проработать теплоотведение за счет вентиляции корпуса или иного монтажа на плате.
Вибрации и электромагнитные помехи
Промышленные контроллеры используются для управления оборудованием, которое работает в условиях повышенных вибраций и электромагнитных помех. Если все это не учитывать в проектировании, используя «бытовые» компоненты, срок нормальной эксплуатации устройства сильно сокращается. И иногда речь даже не про годы, а про часы и минуты.
Несколько лет назад мы делали систему управления мощным дизель-генератором. Во время его запуска в непосредственной близости от генератора мог загораться светодиод, подсоединенный к обычному проводу в воздухе — настолько большими были электромагнитные поля. Кстати, это типичная проблема любых элементов управления мощными электрическими установками.
Сложность была в том, что система управления должна была размещаться непосредственно на корпусе генератора. Электроника работала в этих условиях не более минуты. Далее она зависала, а двигатель генератора продолжал вращаться без контроля.
Помещать контроллер в защитный корпус не было никакого смысла, потому что к нему подключались проводные датчики, снимающие показания с генератора. Даже если удалось бы создать корпус, полностью изолирующий от помех, плата все равно получала свои скачки напряжения через эти провода. Можно было бы изобрести сложные фильтры, но это только снизило бы вероятность, но не защитило бы полностью от сбоев. Оказалось проще и надежнее решить проблему на уровне ПО — разработать систему, которая очень часто сохраняет свое состояние, обнаруживает зависание, перезапускает контроллер и продолжает работать с точки остановки так, что внешне это незаметно (во время перезапуска генератор продолжает работать на последних настройках). Без погружения в самый низкий уровень проектирования ПО в красивом редакторе бытового «конструктора» реализовать такое невозможно.
Внешние ограничения
Как правило, промышленная электроника не работает сама по себе. Она встраивается в другие системы, где есть свои ограничения. Самый яркий пример из нашей практики — разработка компонента космического аппарата, в котором были жесткие рамки энергопотребления. На орбите лишние милливатты взять неоткуда. Поэтому под каждый блок на уровне главного конструктора выделялась определенная мощность. В случае, если ты превышаешь эту планку, система более высокого уровня отрубает весь блок.
Мы разрабатывали компонент, который собирает данные с датчиков и обрабатывает их для отправки на Землю. На разных процессорах параллельно работало три алгоритма. У каждого из них потребление энергии зависело от этапа расчетов.
На испытаниях выяснилось, что самые энергоемкие фазы алгоритмов в случайный момент могут совпадать. В эти периоды суммарное энергопотребление на миллисекунды превышает заявленную норму, и блок отрубается внешними системами. Сложность была в том, что ошибка могла проявиться раз в несколько дней или даже раз в месяц. Попробуй такое выявить и исправить, не представляя, как это работает! А еще сложнее сократить энергопотребление, не имея доступа к переделке электроники (как это реализовано в конструкторе).
Срок эксплуатации
В отличие от обычной бытовой техники, промышленная электроника должна эксплуатироваться дольше. Никто не будет раз в год менять автоматику на предприятии. Как правило, ее внедряют на десятилетие, а то и не одно. Это значит, что в разработке надо помнить о сроках эксплуатации каждого компонента и думать, чем его заменить через десять или даже двадцать лет, не переделывая полностью систему.
Те же электролитические конденсаторы могут иметь срок службы 2, 5 или 10 тыс. часов. Если использовать самый дешевый вариант для устройства, которое должно непрерывно проработать много лет, когда конденсаторы высохнут, схема начнет работать некорректно. Даже если все остальное будет исправно, оно начнет сбоить и отключится окончательно.
А еще следует помнить о том, что флэш-память имеет ограниченное число циклов перезаписи и время хранения информации даже в энергонезависимых блоках. Можно бездумно писать в нее 100 тыс. раз, сколько гарантирует производитель, а можно создавать циклический буфер, из которого данные записывать все время в разные ячейки, продлевая срок службы микросхемы. Скорее всего, это значит, что разрабатывать придется не в комфортном высокоуровневом фреймворке, а на более низком уровне, где можно точно узнать, что происходит с информацией.
Безопасность для человека
С точки зрения разработки промышленной электроники безопасность — это отдельная большая тема. Каждое устройство должно иметь несколько контуров защиты — от механических травм, поражения электрическим током и т.п. Все это регулируется не только соображениями логики, но и определенными стандартами.
На примере системы управления светом — ее периодически надо отключать, чтобы заменить лампы или выполнить другие работы. И зачастую главный рубильник расположен не на столбе, где меняют лампу, а в удаленном центре управления, который может оказаться в 30 км от места ремонта. Механизмы отключения при этом должны обеспечивать полную безопасность работы людей. Не должно быть никаких самопроизвольных включений. Наоборот, нужна логика экстренного отключения, если человек вдруг вытянул руку туда, куда не следует. И если основное функционирование задается алгоритмами прикладного уровня, то система безопасности должна быть заложена на уровне системном.
Проблемы ПО
Было бы здорово, если бы плата управления работала корректно или не работала вовсе. Но обычно происходит не так. Поэтому с учетом требований к надежности программное обеспечение промышленного контроллера должно быть другим (отличным от ПО «бытового» конструктора) на системном уровне. Мы уже упомянули некоторые особенности разработки ПО для промышленного использования, здесь же немного дополним картину.
Выше мы уже поговорили о проблемах, которые возникают у плат, если эксплуатировать их вне заявленного рекомендованного температурного диапазона. На уровне ПО это проявляется в виде ошибок. Сначала одной на миллион операций, потом при ухудшении условий, допустим, одной на 100 тыс., потом чаще. Обработку этих ошибок, механизмы восстановления поврежденных участков данных и дублирование информации необходимо закладывать на уровне ПО, иначе страдает надежность систем. Нужно устанавливать так называемые сторожевые таймеры, которые определяют, как часто система сама проверяет свою работоспособность и перезагружается при необходимости. Или даже выделять небольшую, но очень устойчивую часть схемы под то, чтобы она следила за корректностью работы остальной системы и при необходимости восстанавливала ее из резервной копии. Отличный пример такого подхода — специальное кодирование с защитой от помех. В «бытовых» конструкторах таких механизмов самокоррекции не предусмотрено.
Почему это игнорируют в платформах-конструкторах
Любые устройства создаются под определенную задачу — они должны выполнять заданную функцию, требуя при этом минимальных вложений на производстве. Именно поэтому бытовая техника для широкого потребителя проектируется, исходя из минимальной стоимости. Она не решает критичных задач. Тот же ресивер для спутникового телевидения или мультиварка могут работать некорректно. В худшем случае мы лишимся трансляции футбола или не получим вкусный йогурт. Для массового использования нет смысла создавать ультра-надежный чайник, который сможет кипятить воду при -70 градусах по Цельсию и не перезагружать свою электронику даже во время ядерного взрыва. Также как нет смысла создавать конструктор, из которого можно будет проектировать промышленную автоматизацию для работы в любых условиях.
Пример проекта на конструкторе
Кто все это разрабатывает
Чтобы разрабатывать устройства промышленного уровня, недостаточно быть хорошим алгоритмистом или математиком. Нужно на физическом уровне понимать, как это должно работать и какие процессы могут там происходить — видеть не только слой функциональности, но и множество других аспектов. А кроме того нужно понимать организационную составляющую. Например, тот факт, что к устройству, установленному в лесу, будет сложно регулярно ездить, чтобы менять настройки, и нужно закладывать стабильные механизмы дистанционного изменения программного обеспечения, которые не превратят контроллер в «кирпич».
Нужен системный взгляд в целом на проектируемое изделие. И работать придется не в рамках так называемого happy way (когда ты исходишь из представлений о наилучшем пути развития), а опираясь на известный закон Мерфи: «Если что-то плохое может произойти, оно произойдет». От себя хочется добавить, что иногда самый негативный сценарий может воплотиться в жизнь в двукратном размере, поэтому нужно всегда понимать на самом низком уровне, что происходит и что может произойти в разрабатываемой системе.
Нужно уметь правильно выбрать точку на воображаемой шкале между низкой ценой и надежностью (при заданной функциональности). И если в бытовых применениях в почете функциональность, которая впечатляет пользователя, в промышленной электронике часто мы уходим в сторону надежности, выбирая соответствующие компоненты и алгоритмы. К сожалению, этого не видно наглядно — результат не вызывает никакого «вау-эффекта». Он будет виден только на больших промежутках времени, когда техника будет продолжать работать десятилетиями, даже сверх заявленного срока эксплуатации.
Из архива факультета программной инженерии и компьютерной техники ИТМО
Описанный взгляд на проектирование в IT в целом проповедуют на факультете программной инженерии и компьютерной техники. Это касается как программно-информационных систем (о которых мы особо не говорили сегодня), так и управляющих компьютерных систем, разработкой, производством (да, тут есть современное производство электроники!) и внедрением которых занимается несколько команд на факультете.
