[Из песочницы] Как мы строили систему аварийной сигнализации дата-центра
Так получилось, что в команде проекта Embox у меня больше всех опыта в области АСУ: на предыдущем месте работы я разрабатывал промышленные контроллеры. Поэтому не удивительно, что когда возникла задача сделать систему автоматического управления светодиодами в датацентре, именно меня попросили проработать архитектуру проекта. Изначально планировалось закупить готовые контроллеры удаленного управления портами ввода-вывода, но после более тщательной проработки требований стало ясно, что для заказчика более предпочтителен вариант разработки заказного контроллера. Собственно его вы и видите на фотографии.Тем, кому интересно узнать о том, на какие грабли мы наступили, как выглядят взорвавшиеся микросхемы, как правильно подключать землю на DC/DC конвертере, ну и, конечно, почему мы применили наш проект, прошу под кат. Осторожно, много картинок! Желание заказчика — законИзначально задача казалось очень стандартной, нужно управлять диодами +24В по сообщениям приходящим от SCADA-системы заказчика. Конечно, от SCADA поступают сообщения о состоянии всяких датчиков, а не о том, что нужно зажечь или погасить какой-то конкретный диод, но это решается разработкой своеобразного PROXY который переводит сообщения типа аварийная ситуация в шкафу N в соответствующую команду, посылаемую по протоколу Modbus на конкретный контроллер.Соответственно, предложенная мной архитектура была очень простой и исходила из моего опыта в области АСУ. А именно — взять электрические щиты, типа тех, в которых стоят счётчики, набить их контроллерами с максимальным набором дискретных выходов, например, MOXA ioLogik E1211, поставить источники питания, и, в принципе, все. То есть, картина представлялась следующей: щит, как и положено в АСУ, монтируется на стену, в него заходит один сетевой провод Ethernet и питание 220, а выходят куча пар проводов, которые идут к светодиодам. Были, конечно, вопросы по поводу такого большого количества диодов, но они легко решались увеличением количества шкафов.
Но при дальнейшем уточнении деталей начали всплывать нюансы, которые начали влиять на столь простую и понятную схему реализации. Первым условием, пошатнувшим нашу уверенность, было то, что оборудование нужно монтировать только в телекоммуникационные шкафы. С одной стороны, DIN рейки никто не отменял, но с другой, согласитесь, как-то убого будет выглядеть телекоммуникационная стойка, если там будут навешаны контроллеры ввода-вывода и блоки питания к ним. К тому же, монтаж и обслуживание подобной конструкции представляет собой довольно нетривиальную задачу. Очевидным решением было использовать rack корпус, а уже в нем скрыть всю недоступную для глаз «пользователя» кухню. Для того, чтобы было проще масштабировать схему и наращивать количество выходов, я предложил использовать контроллеры, работающие не по Ethernet, а по RS485 (например ioLogik R1212), а на входе поставить преобразователь Modbus-RTU в Modbus/TCP (MGate MB3170-T).
Но пожелание заказчика иметь дружелюбный пользовательский web-интерфейс сильно спутало наши планы. Я начал предлагать уже не столь красивые решения, например — поставить в каждый корпус по прокси и так далее. Эти идеи были не очень удачными, но я продолжал отстаивать решение сделать всё на готовых элементах, пока не выяснилось, что срок поставки готовых контроллеров в достаточном количестве не укладывается в срок заказа.
Собственный велосипед должен быть удобным Стали обдумывать другие решения. Ребята из команды говорили: «Да что там вообще делать? Нам ведь просто нужно ногами контроллера управлять, пусть напряжение и ток довольно большие, но ведь есть ключи типа ULN2803A. У нас вот сейчас на столе лежат пара отладочных плат STM32F4Discovery, на них прекрасно решается подобная задача. Кроме того, если использовать эти отладки, можно очень просто реализовать web-интерфейс, поскольку web-сервер там уже работает.»
Я возразил, что не всё так просто, что у нас, например, нет поддержки протокола ModBus, что является стандартом для подобного рода устройств. На что один из членов нашей команды 0xdde на следующий день сделал поддержку, перенеся библиотеку libmodbus.В общем, я сдался, и было решено делать контроллер с помощью имеющейся STM32F4Discovery, монтажной платы, провода МГТФ, ключей и какой-то матери.
Для того, чтобы красиво смотрелось, мы решили вместо клемм поставить разъемы на три контакта W7166–03PSGB00, поскольку, как я уже говорил, управление ведётся парами диодов, и у них общая земля. К сожалению, разъемов на три контакта с нормальным сроком поставки мы найти не смогли и поставили разъемы W7166–04PSGB00 на четыре контакта. Изначально мы хотели, чтобы на одном контроллере было расположенною 80 таких разъемов, но тут мы опять столкнулись с тем, что 80 таких разъемов с трудом влезают на крышку rack корпуса U1. Кроме того, у нас получалось, что блок питания 24В должен быть не менее, чем на 20А. Поэтому мы решили ограничиться 40 разъемами (парами диодов) и поставить всё в корпус U2.
Следующий вопрос, который возник, заключался в том, что на нашей STM32F4Discovery не было 80 свободных выводов для управления 40 парами диодов. На помощь пришлось призвать сдвиговые регистры 74HCT164N.
Анализ требований это важно
Проблемы с закупками компонент мы опускаем. А вот про наш недосмотр при чтении описания микросхемы ключей я расскажу. Если это и не интересно, то как минимум поучительно.
Как я уже говорил, диоды у нас сведены в пары и имеют общий провод — землю. Управляются же диоды положительным напряжением на управляющих контактах. Так вот, когда приехали диоды, мы включили один диод, успешно им поуправляли и успокоились. Но когда дело дошло до проверки на реальной паре, выяснилось, что эти ключи управляют разрыванием земли (общего провода), то есть схема включения должка была быть такой, как на картинке.
В общем, нам срочно пришлось менять тип ключей, сначала на UDN2981A-T, а затем на TD62783APG, поскольку первые считались устаревшими, и, кроме того что они стоили совсем не мало, их оказалось ещё и трудно купить.
Когда, наконец, схема на один каскад была создана, выглядело это приблизительно так.
Итогом недосмотра по документации стали пара потерянных дней и наличие пары сотен микросхем, которые к тому времени уже успели приехать.
Навесной монтаж не так уж прост После того, как у нас, наконец, заработал один каскад под управлением STM32F4, мы приступили к следующей стадии, а именно — к созданию полноценного прототипа устройства.Идея была следующая.Берем монтажную плату, расставляем на ней микросхемы и разъёмы. Припаиваем всё это, соединяем по довольно простой схеме (будет дальше), добавляем пару разъёмов, один для питания и один штыревой для управляющих сигналов от STM32F4Discovery, затем подаём питание, соединяем шлейфом с Discovery, и всё- остается только корпус. В общем, всё представлялось простым и лёгким. Впрочем, реальность оказалось не настолько радужной.
Первая проблема, с которой мы столкнулись, была в навесном монтаже. Дело в том, что есть большая разница между пайкой десятков проводов и сотен проводов, и последнее оказалось жутким занятием.
В общем, паяли долго, но это ещё не самое плохое. Когда, наконец, спаяли, прозвонили и подали питание, произошёл взрыв. Выключили, прозвонили ещё раз, оказалось, коротыш между землей (5В) и +24В. Мы просто вели две шины, и они коснулись одного и того же металлизированного отверстия, а мы не прозвонили питания между собой. В общем, сами виноваты, но было очень страшно.
Мы заклеили изолентой место коротыша (да, да, без изоленты не обошлось):
И тут же совершили еще одну ошибку, а именно — не убрали из схемы взорвавшуюся микросхему. По крайней мере, мы думаем, что причина следующего взрыва была именно в этом.
А вот так выглядят микросхемы, вырезанные с платы после такого коротыша.
Не стоит работать в субботу Мы добились того, что после подачи питания на схему ничего не взрывалось, не дымилось и сильно не грелось. Обрадовавшись, подключили шлейфом Discovery и даже попробовали управлять диодами, правда, безрезультатно. Нужно было искать проблему. Прежде всего, мы проверили напряжения питания (+5В и +24В). Они были корректны. Затем напряжения на выходных контактах сдвиговых регистров, — они тоже были правильные. И ими даже можно было управлять. Но, как ни странно, на выходах ключей ничего не менялось, они всегда были открыты. Долгая проверка схемы подключения оказалась безрезультатной.Измеряя напряжение в очередной раз, мы очень удивились, увидев, что на выходном контакте сдвигового регистра +5В, а на входе ключа нечто странное, хотя они просто соединены проводом. Чуть позже выяснилось, что мы измеряем напряжения в этих точках от разных земель. Измерили разность потенциалов между землями 5В и 24В и увидели 5В. Оказалось, что мы просто неправильно подключили микросхему DC/DC конвертера TRECO TEN 12–2411. Даже не знаю, как нам в голову такое пришло, ведь очевидно, что если два напряжения приходят на одну и туже микросхему, то у них должна быть общая земля, а мы земли не соединили и получили на схеме два развязанных напряжения. В свое оправдания могу сказать только то, что мы программисты, хотя и системные, и даже очевидный факт про общую точку нам подсказали знакомые инженеры.
В общем, поняли свою ошибку и решили соединить земли, но так как уже было где-то десять часов вечера в субботу, решили сделать это тоненьким проводком, причем придерживая руками, просто коротнув эти точки на плате. Не знаю уж, что произошло дальше, то ли рука дрогнула у человека, который держал провод, то ли после предыдущих аварий ещё один ключ вылетел, но на этот раз я увидел как горит микросхема, в буквальном смысле горит, а ведь раньше я думал, что ни керамический корпус, ни металлические контакты гореть не могут. В общем, ещё минус микросхема ключа и сдвигового регистра, который мы выкусили, помятуя о предыдущем опыте. И на этой прекрасной ноте мы пошли домой, поскольку дальнейшие попытки сделать что-то в спешке нам казались неуместными. Ведь у нас ключей не хватало даже на одно устройство. Хорошо хоть они должны были прийти уже в понедельник.
Простота спасет мир
По итогам субботних битв мы всё-таки получили работающий прототип устройства, и выглядел он следующим образом: 
Резисторы (300 Ом) на фото имитируют нагрузку. Перед демонстрацией заказчику мы делали тестовые прогоны по несколько часов. Грелись резисторы, кстати, до 120 градусов.
Я не буду рассказывать про работы с корпусом и окончательную сборку, просто приведу фотографии внутренностей, и то ради того, чтобы рассказ был полным:
Мы продемонстрировали работу заказчику, функциональность его устроила, внешний вид тоже. Единственное, что он попросил изменить — это поставить вместо наших разъемов что-нибудь из принятых в телекоммуникации: RJ45 или RJ11, поскольку это сильно привычнее, а значит и проще в эксплуатации и обслуживании. На этот раз, проконсультировавшись с инженерами на предмет того, выдержат ли нужные токи подобные разъемы, хватит ли места на лицевой панели и так далее, решили поставить RJ12. Они были на складе в наличии, ну и констуктивно занимают меньше места, чем RJ45. Кроме того, учитывая предыдущий опыт, мы решили, что паять на макетной плате не вариант, и заказали проектирование печатной платы. А поскольку она оказалась очень простая, двусторонняя даже без металлизации, то нам выпустили её меньше, чем за неделю.
Проведенные модернизации сильно упростили нам жизнь и сделали саму плату более красивой.
При чем тут Embox? Самым сильным аргументом, как вы понимаете, для применения Embox было то, что нам он хорошо известен, если не сказать больше.Но все же хочется отметить технические характеристики, которые сильно упрощали создание требуемого устройства. Главное, конечно, — это наличие полноценного web-сервера с поддержкой cgi. В результате управлять нашим устройством можно с помощью браузера, внешний вид страницы максимально приближен к реальной лицевой панели.
Конечно, можно возразить, что есть более простой способ получить web-сервер на устройстве, а именно — использовать Linux. Не спорю это так, и он будет, безусловно, более функциональный и позволит использовать для разработки кучу фреймворков и языков программирования. Но, во-первых, мы искренне убежденны, что управлять GPIO из под Linux-а это не совсем правильный подход. А во-вторых, он на такую аппаратную платформу попросту не встанет без специальных ухищрений.
Ну, а если использовать FreeRTOS с lwIP стеком, который идет в комплекте, то реализация подобного функционала сильно усложняется, ну и, конечно, libmodbus так просто уже не перенести.
P.S. При разработке данного устройства ни один светодиод в датацентре не пострадал
