Сегодня доступен целый ассортимент электронных конструкторов, которые можно использовать для автоматизации пет-проектов. Хочется самодельный робот-пылесос или 3D-принтер - пожалуйста, есть Lego, Arduino или Raspberry Pi. Их просто купить и легко запрограммировать. Почему же нельзя использовать тот же подход в профессиональных применениях? Зачем тратить в несколько раз больше денег и сил на разработку и программирование специализированной промышленной электроники?
На факультете программной инженерии и компьютерной техники в ИТМО уже больше 30 лет занимаются разработкой специализированных систем. Мы, декан факультета, Павел Кустарев и руководитель международной лаборатории "Архитектура и методы проектирования встраиваемых систем и систем на кристалле", Алексей Платунов, рассказываем, почему решения на базе “бытовых” конструкторов ненадежны во всех отношениях.
Одна история про автоматизацию на Raspberry Pi
Обычная история — берем Raspberry Pi или Arduino, красивую и простую среду разработки и создаем собственное устройство, которое будет выполнять какую-то полезную функцию.
За примерами далеко ходить не надо: один из профессоров нашего факультета на даче собрал инкубатор для яиц. Купил компоненты, проработал алгоритм, запустил, убедился, что схема работает без сбоев, и уехал. А вернувшись, получил вместо птиц десяток яиц всмятку. Как выяснилось, в его отсутствие произошел сбой по питанию и система некорректно перезапустилась, в результате яйца спеклись.
Для нашего профессора история закончилась подпорченным настроением и затратами на покупку второго десятка перепелиных яиц. Но представим, что это не собственный проект с минимальными затратами, а, например, сборочная линия на производстве или система управления наружным освещением на удаленной трассе. Здесь цена ошибки гораздо выше— испорченная партия продукции в первом случае и повышенная аварийность на сложных участках дороги во втором. И если на производстве обычно есть контроль качества, который быстро отреагирует и отправит ремонтную бригаду в нужный цех, то быстро приехать к участку без освещения на трассе уже нельзя, да и в принципе приехать дорого. При этом каждый час простоя системы — прямой риск для людей.
Что не так с конструкторами
Запрограммировать алгоритм для плат из “бытовых” конструкторов легко. И все будет работать, но в идеальных условиях на рабочем столе — при комнатной температуре, стандартной влажности, в отсутствии электропомех и при стабильном электропитании. Как только речь зайдет о реальных промышленных применениях, начнутся сложности.
На физическом уровне микросхемы, да и прочие компоненты устройств имеют несколько вариантов исполнения. Коммерческое исполнение — более дешевое. Оно предназначено для “бытового” применения. Как правило, это не критичные устройства, при поломке которых не возникнет опасности для жизни человека и не будет серьезных финансовых потерь. При производстве компонент в промышленном исполнении применяется другой уровень контроля качества, да и в целом иные технологии производства. О них и поговорим.
Температура и влажность
Используемая в коммерческих устройствах компонентная база (микросхемы и другие элементы) обычно имеет рабочий диапазон от -10 до +70 градусов по Цельсию.
Если греть схемы до более высоких температур, они будут работать некорректно — уедут заданные производителем частоты, чаще будут появляться ошибки. Из-за температурных колебаний меняются параметры диэлектриков и электролитов, они могут безвозвратно деградировать, в результате схемы перестают корректно работать. Начинают врать датчики, сбоить источники питания, неправильно работают аппаратные интерфейсы. В итоге устройство как бы не вышло из строя, но со своей задачей уже не справляется. А при нарушении работы цепей питания может и перегореть.
Материалы, используемые для производства устройств (тот же пластик), имеют свои коэффициенты температурного расширения. На жаре корпус из такого пластика будет слишком расширяться и перестанет достаточно хорошо защищать плату, так что к ней проникнет влага. В зависимости от внешних условий меняются и другие их характеристики. Например, некоторые пластики на холоде становятся хрупкими, поэтому их нельзя использовать для производства разъемов или корпусов устройств, которые будут эксплуатироваться на морозе.
Выше мы не зря использовали пример с системой управления наружным освещением. Одна из наших лабораторий разрабатывает контроллеры, управляющие внешним освещением, которые работают в достаточно жестких условиях — на улицах городов с разным климатом и на протяженных трассах.
Температура воздуха в местах установки контроллеров варьируется от -45 до +45. А внутри корпуса с учетом солнца в жаркий полдень и разогрева самих компонент во время работы в отдельных точках платы может быть все +90. Уже по этому температурному диапазону платы из электронных конструкторов типа Arduino не подходят — допустимые температуры для них от -25 до +70 градусов Цельсия (хотя в datasheet указаны более широкие диапазоны, сам производитель озвучивает в FAQ такие рекомендации).
На то чтобы учесть все климатические особенности отдельных регионов — выявить все нестабильности в работе и устранить их за счет технических решений — у нас ушло около 5 лет. То год выдастся особенно солнечный, и мы боремся с излишним нагревом, то зимой слишком сыро, так что все обледеневает. Одно дело — видеть усредненную статистику по климату, например, в Архангельске, но совсем другое — постоянно сталкиваться с реальными проблемами в точке, для которой и статистики-то нет — где-нибудь на краю болота или на горке с сильным ветром. В одних случаях нужно предусмотреть дополнительные уплотнения крышки корпуса, а где-то, наоборот, проработать теплоотведение за счет вентиляции корпуса или иного монтажа на плате.
Вибрации и электромагнитные помехи
Промышленные контроллеры используются для управления оборудованием, которое работает в условиях повышенных вибраций и электромагнитных помех. Если все это не учитывать в проектировании, используя “бытовые” компоненты, срок нормальной эксплуатации устройства сильно сокращается. И иногда речь даже не про годы, а про часы и минуты.
Несколько лет назад мы делали систему управления мощным дизель-генератором. Во время его запуска в непосредственной близости от генератора мог загораться светодиод, подсоединенный к обычному проводу в воздухе — настолько большими были электромагнитные поля. Кстати, это типичная проблема любых элементов управления мощными электрическими установками.
Сложность была в том, что система управления должна была размещаться непосредственно на корпусе генератора. Электроника работала в этих условиях не более минуты. Далее она зависала, а двигатель генератора продолжал вращаться без контроля.
Помещать контроллер в защитный корпус не было никакого смысла, потому что к нему подключались проводные датчики, снимающие показания с генератора. Даже если удалось бы создать корпус, полностью изолирующий от помех, плата все равно получала свои скачки напряжения через эти провода. Можно было бы изобрести сложные фильтры, но это только снизило бы вероятность, но не защитило бы полностью от сбоев. Оказалось проще и надежнее решить проблему на уровне ПО — разработать систему, которая очень часто сохраняет свое состояние, обнаруживает зависание, перезапускает контроллер и продолжает работать с точки остановки так, что внешне это незаметно (во время перезапуска генератор продолжает работать на последних настройках). Без погружения в самый низкий уровень проектирования ПО в красивом редакторе бытового “конструктора” реализовать такое невозможно.
Внешние ограничения
Как правило, промышленная электроника не работает сама по себе. Она встраивается в другие системы, где есть свои ограничения. Самый яркий пример из нашей практики — разработка компонента космического аппарата, в котором были жесткие рамки энергопотребления. На орбите лишние милливатты взять неоткуда. Поэтому под каждый блок на уровне главного конструктора выделялась определенная мощность. В случае, если ты превышаешь эту планку, система более высокого уровня отрубает весь блок.
Мы разрабатывали компонент, который собирает данные с датчиков и обрабатывает их для отправки на Землю. На разных процессорах параллельно работало три алгоритма. У каждого из них потребление энергии зависело от этапа расчетов.
На испытаниях выяснилось, что самые энергоемкие фазы алгоритмов в случайный момент могут совпадать. В эти периоды суммарное энергопотребление на миллисекунды превышает заявленную норму, и блок отрубается внешними системами. Сложность была в том, что ошибка могла проявиться раз в несколько дней или даже раз в месяц. Попробуй такое выявить и исправить, не представляя, как это работает! А еще сложнее сократить энергопотребление, не имея доступа к переделке электроники (как это реализовано в конструкторе).
Срок эксплуатации
В отличие от обычной бытовой техники, промышленная электроника должна эксплуатироваться дольше. Никто не будет раз в год менять автоматику на предприятии. Как правило, ее внедряют на десятилетие, а то и не одно. Это значит, что в разработке надо помнить о сроках эксплуатации каждого компонента и думать, чем его заменить через десять или даже двадцать лет, не переделывая полностью систему.
Те же электролитические конденсаторы могут иметь срок службы 2, 5 или 10 тыс. часов. Если использовать самый дешевый вариант для устройства, которое должно непрерывно проработать много лет, когда конденсаторы высохнут, схема начнет работать некорректно. Даже если все остальное будет исправно, оно начнет сбоить и отключится окончательно.
А еще следует помнить о том, что флэш-память имеет ограниченное число циклов перезаписи и время хранения информации даже в энергонезависимых блоках. Можно бездумно писать в нее 100 тыс. раз, сколько гарантирует производитель, а можно создавать циклический буфер, из которого данные записывать все время в разные ячейки, продлевая срок службы микросхемы. Скорее всего, это значит, что разрабатывать придется не в комфортном высокоуровневом фреймворке, а на более низком уровне, где можно точно узнать, что происходит с информацией.
Безопасность для человека
С точки зрения разработки промышленной электроники безопасность — это отдельная большая тема. Каждое устройство должно иметь несколько контуров защиты — от механических травм, поражения электрическим током и т.п. Все это регулируется не только соображениями логики, но и определенными стандартами.
На примере системы управления светом — ее периодически надо отключать, чтобы заменить лампы или выполнить другие работы. И зачастую главный рубильник расположен не на столбе, где меняют лампу, а в удаленном центре управления, который может оказаться в 30 км от места ремонта. Механизмы отключения при этом должны обеспечивать полную безопасность работы людей. Не должно быть никаких самопроизвольных включений. Наоборот, нужна логика экстренного отключения, если человек вдруг вытянул руку туда, куда не следует. И если основное функционирование задается алгоритмами прикладного уровня, то система безопасности должна быть заложена на уровне системном.
Проблемы ПО
Было бы здорово, если бы плата управления работала корректно или не работала вовсе. Но обычно происходит не так. Поэтому с учетом требований к надежности программное обеспечение промышленного контроллера должно быть другим (отличным от ПО “бытового” конструктора) на системном уровне. Мы уже упомянули некоторые особенности разработки ПО для промышленного использования, здесь же немного дополним картину.
Выше мы уже поговорили о проблемах, которые возникают у плат, если эксплуатировать их вне заявленного рекомендованного температурного диапазона. На уровне ПО это проявляется в виде ошибок. Сначала одной на миллион операций, потом при ухудшении условий, допустим, одной на 100 тыс., потом чаще. Обработку этих ошибок, механизмы восстановления поврежденных участков данных и дублирование информации необходимо закладывать на уровне ПО, иначе страдает надежность систем. Нужно устанавливать так называемые сторожевые таймеры, которые определяют, как часто система сама проверяет свою работоспособность и перезагружается при необходимости. Или даже выделять небольшую, но очень устойчивую часть схемы под то, чтобы она следила за корректностью работы остальной системы и при необходимости восстанавливала ее из резервной копии. Отличный пример такого подхода — специальное кодирование с защитой от помех. В “бытовых” конструкторах таких механизмов самокоррекции не предусмотрено.
Почему это игнорируют в платформах-конструкторах
Любые устройства создаются под определенную задачу — они должны выполнять заданную функцию, требуя при этом минимальных вложений на производстве. Именно поэтому бытовая техника для широкого потребителя проектируется, исходя из минимальной стоимости. Она не решает критичных задач. Тот же ресивер для спутникового телевидения или мультиварка могут работать некорректно. В худшем случае мы лишимся трансляции футбола или не получим вкусный йогурт. Для массового использования нет смысла создавать ультра-надежный чайник, который сможет кипятить воду при -70 градусах по Цельсию и не перезагружать свою электронику даже во время ядерного взрыва. Также как нет смысла создавать конструктор, из которого можно будет проектировать промышленную автоматизацию для работы в любых условиях.
Кто все это разрабатывает
Чтобы разрабатывать устройства промышленного уровня, недостаточно быть хорошим алгоритмистом или математиком. Нужно на физическом уровне понимать, как это должно работать и какие процессы могут там происходить — видеть не только слой функциональности, но и множество других аспектов. А кроме того нужно понимать организационную составляющую. Например, тот факт, что к устройству, установленному в лесу, будет сложно регулярно ездить, чтобы менять настройки, и нужно закладывать стабильные механизмы дистанционного изменения программного обеспечения, которые не превратят контроллер в “кирпич”.
Нужен системный взгляд в целом на проектируемое изделие. И работать придется не в рамках так называемого happy way (когда ты исходишь из представлений о наилучшем пути развития), а опираясь на известный закон Мерфи: “Если что-то плохое может произойти, оно произойдет”. От себя хочется добавить, что иногда самый негативный сценарий может воплотиться в жизнь в двукратном размере, поэтому нужно всегда понимать на самом низком уровне, что происходит и что может произойти в разрабатываемой системе.
Нужно уметь правильно выбрать точку на воображаемой шкале между низкой ценой и надежностью (при заданной функциональности). И если в бытовых применениях в почете функциональность, которая впечатляет пользователя, в промышленной электронике часто мы уходим в сторону надежности, выбирая соответствующие компоненты и алгоритмы. К сожалению, этого не видно наглядно — результат не вызывает никакого “вау-эффекта”. Он будет виден только на больших промежутках времени, когда техника будет продолжать работать десятилетиями, даже сверх заявленного срока эксплуатации.
Описанный взгляд на проектирование в IT в целом проповедуют на факультете программной инженерии и компьютерной техники. Это касается как программно-информационных систем (о которых мы особо не говорили сегодня), так и управляющих компьютерных систем, разработкой, производством (да, тут есть современное производство электроники!) и внедрением которых занимается несколько команд на факультете.
Комментарии (50)
pavia
26.07.2022 13:15+11А что мешало целому профессору отладить сбой питания и перезагрузку? Ровно то же, что и помешало бы ему отладить ту же саму ситуацию на промышленном контроллере. Может всё дело не в конроллерах, а в данных профессорах?
alexesDev
26.07.2022 13:29+3Любое хоть сколько нибудь production ready решение это минимум 3-6 интераций разработки. Надеяться что все заработает с первого раза... это не проблема arduino. И цена убитых птиц будет входить в итоговую цену рабочего продукта.
ciuafm
26.07.2022 13:51+2Страшно подумать что входит в итоговую цену разработки медицинского оборудования согласно вашей логике...
TroLLik
26.07.2022 14:26+2"Техника безопасности написана кровью" (c)
"У каждого врача есть своё кладбище" (с)
Давайте вместе подумаем над смыслом этих "крылатых фраз".
alexesDev
27.07.2022 02:24+1Огромное количество животных на тесты? И местами людей https://habr.com/ru/company/pvs-studio/blog/307788/?
AndreyDmitriev
26.07.2022 14:42Несколько лет назад работал я на пусконаладке одной железки, и рядом трудился коллега из другой фирмы, налаживая конвейер, подающий детальки в нашу систему. Ну, разговорились, кто чем раньше занимался... Он сказал, что до этого работал в пищевой промышленности. Я его спросил - зачем он сменил тепличные условия на шумный и грязный цех литья, а он мне говорит - а ты видел несколько сот литров пива на полу из-за неверно открытых клапанов? Ну вот так-то.
На самом деле есть куча железок, которые надо запускать с первого раза, так как цену изуродованных конвейеров в итоговую цену заказчик включать скорее всего таки не будет. Но современные средства разработки позволяют симулировать практически всё, так что основную часть работы и проверки можно выполнить в уютном офисе. Ну и опять же ошибка ошибке рознь - забыть какую-то копеечную индикацию это одно, а вот уронить многотонную двенадцатиметровую стальную газовую трубу мимо конвейера - это уже несколько другое.alexesDev
27.07.2022 02:10Поэтому в промышленности и берут максимум готовый протестированных модулей, которые будут без ошибок + с зашитыми системами защиты от дурака... вроде все логично. Если мы делаем production ready из 10 production ready решений, то чаще всего все будет ок. Но каждая железяка в отдельности прошла этот путь от прототипа через 3-6 итераций разработки (минимум, я для себя минимум так закладываю всегда), потом альфа, бета и пару поколений устройства с фиксами от клиентов.
AndreyDmitriev
27.07.2022 08:58+1А, понял, вы имеете ввиду собственно ПЛК. Ну, как пользователь я в общем ожидаю, что железка будет сразу работать так как заявлено и делать то, что от неё просят (тем более, что стоимость этих игрушек не ардуиновская), и производитель не будет на мне упражняться со своими итерациями. Но баги встречаются, это да.
a-tk
27.07.2022 08:52Вот и получаются рентгеновские аппараты, выдающие пациенту мощность излучения в десятки тысяч рад.
Sun-ami
26.07.2022 14:30+6Решать проблему электромагнитных помех, приводящих к сбоям раз в минуту программно? По-моему это в корне порочный путь, потому что сбои - это вероятностное событие, и с какой-то вероятностью могут участиться настолько, что система не успеет вовремя отреагировать на событие, потому что будет непрерывно перезагружаться дольше заданного времени реакции. Быстрое восстановление работоспособнособности через перезагрузку в таких условиях нужно, но чтобы система гарантировано работала нормально, сбои должны происходить не чаще, чем раз в неделю (а то и раз в год, в зависимости от задачи), а не раз в минуту. А так это очень похоже на широко распространённый костыль, про который в итоге забывают до тех пор, пока не случится что-то серьёзное, и потом приходится всё переделывать с нуля.
An_private
26.07.2022 15:20Проблема даже не только в этом. Вотчдог - это ровно такая же цифровая часть процессора, как и всё остальное. И если железяка работает в условиях непрерывных перезагрузок из-за ЭМ помех - вотчдог точно также может зависнуть. Я уж не говорю, что при таком уровне помех, что идут непрерывные перезагрузки - возможно всё, вплоть до физического повреждения железа.
Sun-ami
26.07.2022 16:14Использования для перезагрузки при сбоях в условиях интенсивных электромагнитных помех только вотчдога совершенно недостаточно - нужно также контролировать валидность всех хранимых данных непосредственно перед их использованием, правильность вычислений их дублированием, целостность хранимых данных, а также целостность содержимого флэш-памяти и исправность используемых блоков контроллера. Но в статье и не говорится, что для этого используется только вотчдог - напротив, говорится о необходимости "погружения в низкий уровень ПО". Ну а насчёт физического повреждения железа - можно измерить уровень помех, и оценить вероятность такого развития событий, она может оказаться и приемлемой, всё зависит от схемотехники и конструкции контроллера.
Indemsys
26.07.2022 15:14+5Arduino - это целая экосистема. Там есть весьма надёжные платы.
И по существу у конструкторов только один недостаток - их нельзя купить сразу пару тысяч и ожидать поддержки и выпуска без изменений в течении 10 лет.
Поэтому приходится разрабатывать платы точно такие же как Arduino, но на своей компонентной базе.
Arduino IDE отдельная тема. Да, эта IDE довольно ограничена. Но теперь Arduino можно программировать и в VS Code и в Visual Studio и даже в MATLAB-е.
Странно читать про некие ограничения софта в Arduino если эти Arduino сделаны точно на тех же микроконтроллерах что и стиральные машины, и микроволновки, и духовки, и пылесосы, и промышленные ПЛК.
Можно придираться, конечно, к отсутствию специальных цепей защиты, отсутствию гальвано-изоляции, минимализму цепей самодиагностики на платах Arduino. Но автор признался, что сам не ставит достаточно защитных средств на своих платах, поскольку платы у него сбоят. Всем известно, защита - это дорого и её стоимость может превысить цену риска и издержек. В этом смысле Arduino может даже следовало бы похвалить за некую оптимальность.
Zuy
26.07.2022 18:19+1Так а если для производства промышленного устройства нужно все равно свою плату делать и партия намечается больше 10к штук то зачем вообще тут нужно Arduino? Почему просто не взять софт от производителя контроллера и не написать свою прошивку? Не совсем понимаю в чём тут экономия в случае реальных устройств.
Для быстрого прототипирования да, все понятно, но если уж свою железку делать то все равно программисты нужны. Или тут расчет, что вместо нормальных эмбеддеров можно студентами за еду обойтись?
Indemsys
26.07.2022 19:07+1Например такую Arduino плату я бы взял, но её в стока единицы.
Там софт будет и от производителя (HAL) и популярный опенсорс (mbed) и непосредственно либы Arduino. Все вместе интегрировано, есть сразу загрузчик, WiFi и USB с драйверами, IoT и т.д.
Чем плохо или ненадёжно? Не хуже "профессиональных" решений на FreeRTOS и прочих подобных.Zuy
26.07.2022 19:27+1Надежно оно или нет, это надо бы тестирование какое-то провести.
Но опять же все упрется в то что ее в нормальных количествах не найти. На обьемы даже от 1к штук придется разрабатывать что-то свое. В итоге, минимум, грамотный электронщик нужен и к нему грамотный программист. И получится, что этим людям плату сделать и софт написать тоже не проблема. Тогда встанет вопрос, а зачем в этом процессе Ардуино вообще нужно.А еще же есть такая подстава, как сертификация. Можно встрять, с тем, что вначале устройство и так продается, а при выходе на нового клиента или рынок, потребуется сертификация. И как бы всю эту энчиладу не пришлось переписывать.
В целом я не против Ардуино и согласен, что она сильно продвинула в массы разработку программируемой электроники. Но я не понимаю какую пользу, кроме прототипирования, она может дать компаниям которые профессионально занимаются разработкой электроники.
Indemsys
26.07.2022 23:35На моей практике часто видел практические применения Arduino.
Сам не делал, но коллеги вокруг применяют просто массово. Кто-то сделал управление грузовым лифтом, кто-то сделал блок выносных кнопок, кто-то часы с прогнозом погоды на большом матричном индикаторе на рабочее место, кто-то агрегат для полировки биллиардных шаров в офис(и продает на фацебуке задорого).
И это всё в рамках фирмы производящей электронику.
Никто не спрашивает разрешения у руководства пользовать ардуино или нет, просто берут молча и делают, потому что решение стоит копейки.Zuy
27.07.2022 00:03Я тоже видел много практического применения. Отработав 4 года эмбедером в Tesla я видел и Arduino, Raspberry PI и кучу других "конструкторов". Но это все были как-бы проекты на стороне, чтобы облегчить жизнь тестировщикам или электронщикам. Ни о какой серии или ответственном применении даже речь не шла. Да и не понятно зачем.
Вопрос же не в том нужно разрешение или нет. Вопрос в том, зачем фирме производящей электронику использовать Arduino для устройств, которые идут в массовое производство. Какой вообще профит от этого.
Indemsys
27.07.2022 00:14Сам Arduino и есть пример массового, даже очень массового производства.
Не забываем о бесчисленных производителях клонов.
А я всего лишь добавил примеры мелкосерийного производства.
Ответственное применение для Arduino не запрещено. Те же желтые или красные ПЛК с SIL 4 делаются не тех же самых чипах.Zuy
27.07.2022 00:21Сам Arduino это всего лишь конструктор, он не является конечным устройством не для промышленного ни для потребительского рынка.
Ответственное применение Arduino запрещено пока оно не пройдет соответствующую сертификацию.
К чипам претензий никаких нет, но чипы это и не Arduino. В любой компании занимающейся профессионально электроникой есть свои электронщики и программисты. Ну вот что там такого в этом Arduino, что его обязательно нужно копировать в свои устройства?
Indemsys
27.07.2022 00:52Я не так глубоко в теме Arduino что бы прямо так разобрать по полочкам все ценности этой платформы.
Но кое какие сорсы полезные для себя из Arduino брал. Да и сами идеи применения там очень интересные бывают.
Брал драйвера для разных дисплеев, работу с какой-то еще хитрой периферией. С программируемыми LED лентами работу от туда брал. Там это обычно очень лаконично и доходчиво представлено.
Не то что из под линукса чего-нибудь выковыривать.
Serge78rus
26.07.2022 23:46Надежно оно или нет, это надо бы тестирование какое-то провести.
Достаточно взглянуть на плату, и уже не нужно никакого тестирования. Всего один вывод земли на всю кучу внешних сигналов — серьезно?Indemsys
27.07.2022 00:09Надо смотреть на J1 и J2, а не на отверстия по периметру.
Кстати, весьма умно они оставили только один пин земли на тех отверстиях.
Ибо если плата не ставится на материнку со своим плэйном земли, то подсоединять землю к такой плате следует только в одной точке.Serge78rus
27.07.2022 00:43Надо смотреть на J1 и J2, а не на отверстия по периметру.
Ой… Каюсь, я их и не заметил. Приношу извинения.Кстати, весьма умно они оставили только один пин земли на тех отверстиях.
Только при таком подходе вообще непонятно, зачем использовать такую плату. Например, зачем быстрый 16-разрядный АЦП, если его потенциал нельзя реализовать в полной мере.
Ибо если плата не ставится на материнку со своим плэйном земли, то подсоединять землю к такой плате следует только в одной точке.
Pavel_nobranch
26.07.2022 15:28Чем непрофессиональнее разработчик изделия, тем профессиональнее должен быть инженер в эксплуатации. При желании все изделия можно сделать легоподобными, с беспроводными интерфейсами, с индуктивным питанием. То есть полностью изолироваными от внешнего мира. И собираться как блоки лего обычным человеком с улицы. Есть же осциллограф у которого щупы подключаются через оптику.
woddy
26.07.2022 23:47+1И причем тут ардуина?
Обеспечить питание, обеспечить фильтрацию помех, научиться включать вотчдог — можно и на ардуине.
А для защиты от ЧП желается вторичный независимый контур (датчики перегрева, давления, затопления,..) который сам всё выключает когда надо.
Я причастен к выпуску десятков тысяч разных приборов «на ардуине». И пока что все проблемы были с кодом (я отвечаю за железо, программист отдельный)
ruomserg
27.07.2022 07:00+1Заголовок — правильный, статья — нет. Поехали по-пунктам:
— Конструкторы не подходят для реальной автоматизации — да. В первую очередь потому что конструктор имеет много точек соединения на скользящих контактах. Это хорошо для быстрого прототипирования, и ужасно в производственной среде. Потому что влажность, изменения температур, вибрация — все это ослабляет контакты и рано или поздно оно начнет глючить.
Можно сделать прототип и поставить его на линию на контактах. Но после опытной эксплуатации надо делать нормальные схемы с пайкой, покрытием лаком и т.д.
— Все рассуждения о температурных диапазонах, по-сути хрень. Да, если вы собираетесь поставляться в нефтегаз или в тропики, то это отдельные климатические исполнения. бОльшая часть того что вы сможете сделать в жизни — будет жить в цехах, где по нормативу температура около +20. И какая разница вам, гарантирует ли производитель диапазон от -70 или от -50 ?!
— Все рассуждения о безопасности — не хрень, но если вы поставляете для РЖД или авиакосмоса, то там есть достаточное количество руководящих документов по которым макет на ардуино не пройдет и так. Аналогично про медицину.
— И да, даже если вы ставите прототип — то почему бы не подумать о безопасности? Например, в проекте был частотник, который крутил конвейер. Несмотря на защиты в прошивке, в частотнике были активированы функции безопасности: установлены лимиты на скорость, и внутренний keepalive (если контроллер перестает периодически засылать через modbus скорость в регистр, то через 5 секунд все останавливается). Но это же не зависит от контроллера! Хоть там сименс, хоть ардуино — это свойства частотника и здравый смысл!
— Я имел вскрывать промышленные контроллеры. Они принципиально ничем не отличаются от ардуины, хотя построены на других процессорах. Точнее, у них два преимущества — защита входных/выходных цепей и минимизация расстояния между компонентами (+ground plane). Первое вы можете сделать и сами на внешних микросхемах, и прицепить к ардуине. Второе — влияет на устойчивость к ЭМИ, и ничего сделать с этим нельзя если не развести специальную печатную плату. Но специальная печатная плата — это уже не ардуино… Это будет промышленный контроллер на AVR8. Непонятно зачем, но в принципе будет работать не хуже и не лучше промышленного контролера на STM или x86 или 51-й серии…
А вообще, с точки зрения энтерпрайза — софт для контроллеров пишется ужасно. Unit-тестов нет. Нормального управления версиями — как правило, нет. Отладка на эмуляторе через костыли и постоянную работу руками. Деплой только руками, а то и через вскрытие машины и подключение шнурков. Когда идет отладка на реальной машине с «временной» блокировкой функций безопасности — я вообще молчу. И в отрасли это норма, потому что «а как иначе?» и «все так делают...».AndreyDmitriev
27.07.2022 08:53+2с точки зрения энтерпрайза — софт для контроллеров пишется ужасно.
Ну, не всё так уж плохо в современном мире. Мы в рамках оптимизации года три как переехали с Сименса на B&R и в общем следуем классическим методологиям разработки - исходники у нас в гите (мы эти ПЛК на плюсплюсах в основном программируем), с CI мы справились - там проект из командной строки собирается, юнит тесты тоже завезли. За Сименсом я давно не следил, но в TIA вроде тоже всё это можно реализовать. Но в целом вы правы, да, эта область довольно консервативна.
ruomserg
27.07.2022 09:37+1WTG, и побольше заказов вам, как говорится. Чтобы хорошие практики выживали, а плохие — отмирали!..
У меня на пищевых производствах перед глазами проходило всякое преимущественно программируемое по IEC да под Codesys. Я не говорю про графические языки — там принципиально невозможно изолированное тестирование. IL тоже как бы мимо. Остается ST — но и там не завезли. Мало того, еще же все завязано на библиотеки которые упаковал производитель контроллера. И там тоже никто не собирался думать о том, что это должно быть тестируемым. Поэтому отлаживают уважаемые сервисники производителя как? Либо мышкой в codesys триггеря сигналы, либо собирая подобие стенда на коленке, и тыкая в кнопки (непонятно, что хуже...). В некоторых продвинутых случаях на другом контроллере (опять в codesys) делается какой-то эмулятор интерфейса отлаживаемой системы, и тогда что-то можно автоматизировать. Но библиотеки тестов опять ни у кого нет толком — тест и отлаживаемая процедура модифицируются параллельно — и когда заработало — ненужное выбрасывается (шутка, переконфигурируется под новую задачу).
Но это я описываю если не хороший, то хотя б годный вариант. А негодный, но обычный выглядит так: суем шнурок в автомат для розлива, обновляем прошивку, запускаемся… Ой, а оно не хочет запускаться потому что из-за шнурка не закрыт кожух — замотаем концевик безопасности скотчем… Ой, а оно не хочет запускаться потому что нет продукта — блокируем датчик продукта… Ой, а оно не хочет запускаться потому что не помылось — блокируем защиту по стерильности… А как блокируем? А в коде комментируем, да и все! А когда специально обученный специалист сервиса заканчивает и уходит, все производство молится чтобы он там не забыл раскомментировать то, что ранее закомментировал… Хорошо что производитель тоже не дурак (особенно на европейских машинах) — и вся механика идет с отдельными концевиками, которые не дают ей разнести саму себя. А китайские аппараты идут волшебно — все концевики на контроллер, и вся логика включая безопасность внутри. Ну-ну, как говорится, ну-ну…AndreyDmitriev
27.07.2022 11:57все концевики на контроллер, и вся логика включая безопасность внутри
Это-то как раз нормально, мы тоже так делаем. Раньше весь шкаф был забит Pilz Pnoz релейной автоматикой, а теперь мы заводим все критические цепи прямо в ПЛК, включая экстренный останов и т.д. Другое дело, что там цепи двухканальные (там где надо), применяются специальные безопасные модули (мы их "жёлтые" на жаргоне называем), ну и логика программируется в SafeDESIGNER (что добавляет немного головной боли с точки зрения системы контроля версий). У нас ещё и рентген используется, так что требования довольно высокие.
ruomserg
27.07.2022 12:20Не знаю, я последователь старой школы — концевики линейных актуаторов заводятся в limits драйверов, или на аварийную остановку ПЛК (уж как бы оно там внутри не зависало — а схемотехника сброса/аварийного останова таки должна отработать).
Я не говорю сейчас о спец.контроллерах с мажорированием. Но мне кажется, что отработка примитивных функций безопасности программно — во-первых, не требуется; во-вторых ненадежна. Если у вас стоит драйвер шаговика, то нет проблем limit switches до него пробросить. Копию сигнала можно завести и на контроллер для диагностики. А контроллер пусть мониторит по вторичным параметрам: актуатор запущен, сработки датчика положения нет (или ненормальная задержка) — он уводит устройство в аварию (если допустимо по техпроцессу, или хотя бы регистрирует). Это позволяет поймать ситуации, когда что-то уже начало ломаться но еще не до конца…AndreyDmitriev
27.07.2022 13:06+1Да я в общем тоже - начинал я с ещё STEP5, но когда мне в руки попали вот эти современные игрушки, то теперь меня от них не оттащить. Но всё хорошо в меру, конечно. Зависит от системы, бюджета и т.д.
Indemsys
27.07.2022 11:08Походу, что вы, что автор ополчились на Arduino Uno и её первые версии с первой версией IDE. Это выглядит также, как если бы сейчас принялись остро критиковать Windows 3.1
А на самом деле большинство последних Arduino - это мезонинные модули с возможностями превосходящими возможности процессоров ПЛК среднего сегмента.
Я сам прямо сейчас работаю с мезонинными модулями подобными Arduino -
Контроллер с функцией системы управления доступом с мезонинным модулем Если бы была гарантия, что производство конкретного модуля Arduino будет стабильным я бы применял Arduino и никакая сертификация бы меня не остановила
ruomserg
27.07.2022 12:12Ну нет, тогда давайте договариваться о терминологии… Если речь идет об Ардуино — то я себе представляю именно какие-то платы на AVR8 с выводами на гребенках для быстрого прототипирования с arduino bootloader и IDE. Если вы взяли себе просто AVR8 (например, tiny13 или 328) — это не ардуино. Это именно что 8-бит контроллер общего назначения. Если вы берете ESP-series и программируете их в ардуино IDE — то это тоже такое себе, не вполне ардуино. Даже если вы берете AVR и программируете в Arduino, но не пользуетесь библиотеками ардуинщиков и используете доступ к железу помимо системных функций, то это тоже не ардуино.
А вот если вы берете схемотехнику ардуино, приправляете ее библиотеками ардуино — ну, тогда я не знаю зачем вы это делаете. Качество библиотек там может быть… разным.
А если у вас просто ПЛК на базе AVR8, то еще раз повторюсь — у меня нет сомнений, что это будет работать. Так же как работают системы на базе STM, MCS51, embedded x86 и что угодно еще.
Я просто не знаю зачем это вам может быть нужно? Полно же вокруг платформ ПЛК готовых… Но если душа просит именно AVR8 — не вижу препятствий…Indemsys
27.07.2022 12:37Тут вы явно отходите от посыла статьи. А там упоминается и Raspberry Pi в контексте некой недоделанности.
ruomserg
27.07.2022 12:45Ну тут уже я пас. Сама по себе Raspberry — это не ПЛК, потому что голые GPIO на гребенке — это маловато будет. Можно из Raspberry сделать ПЛК — я не пробовал. Наверное, можно. Но в чем прикол иметь ПЛК с HDMI, я сказать не могу. Мне пока ни разу не понадобился HDMI, и если бы туда вместо этого поставили RS485, входы 20ma, и прочие полезности — я был бы более счастлив. Можно, конечно, приколоться и реализовать это все на плате расширения, пихнуть туда отдельный контроллер, организовать связь по i2c… Но опять не вижу — зачем?..
Indemsys
27.07.2022 13:21Прикол в том что SoC на Raspberry вообще полузакрытая архитектура.
И есть сомнения что в ИТМО могут провести её адекватный анализ.
Для меня Raspberry образец недоступной технологии.
И как тогда можно утверждать, что дескать, а вот наша контора все делает круче и индустриальней.
Да не круче, а выкручивается как может. На освоение экосистемы Arduino просто нет сил и интереса, вот и лепят своё. Сотрудничать с Arduino тоже не могут поскольку там высоки требования к преемственности и портируемости софта.
Разные бизнес-модели и не более.ruomserg
27.07.2022 13:42Ну да, согласен. И желательно понимать бы им еще, что ПЛК не ограничивается платой, на котрой распаян процессор. Если речь о нормальных контроллерах, то там есть всегда какая-то шина расширения, на которую можно навешивать экстендеры. И есть какие-то описанные временные гарантии относительно устройств непосредственно заведенных в ПЛК и на экстендеры. В общем, я еще раз обращусь в начало: использовать конструктор-прототип для автоматизации производственного объекта — нельзя. Но не по причинам, которые приводят авторы.
Indemsys
27.07.2022 19:44Немного не соглашусь.
На Arduino не нужно делать прототип, потому что если сделали что-то почти работающее, то ничто не останавливает и все остальное доделать на Arduino. Т.е. Arduino это не прототипирование.
Семейство Arduino Portenta H7 идеально подходит под промышленную автоматизацию. Там есть все ходовые межмодульные интерфейсы: Ethernet, FDCAN, QSPI, SDIO и прочие мелкие. Единственная проблема только в том что ребята из Arduino сами не хотят чтобы их дивайсы так массово и специализировано применялись. Они нашли свой бизнес в другом и маркетинг соответственно строят.Хотя если ограничить понятие Arduino только на Arduino Uno старых версий и старую IDE , то с вами могу согласиться. Но тогда автор должен был это явно указать, и тогда его статья имела бы ещё меньше смысла.
Isiirk
27.07.2022 12:11+1Китайская ESP на улице трудится уже 3 года и зимой и летом (-45 + 40 ), без специальных мер по герметизации, ничего не отказывает, яйца не "печот". Как показала практика, весьма надежная штука. Думаю вполне себе решение для производства при должном тестировании и подготовке.
4sense
27.07.2022 16:26Вкину я немного жизни, хотя не уверен, что многие его прочитают)
Учился я у этого профессора и могу сказать, что там очень интересный и богатый опыт разработки с полным понимаем всех нюансов встраиваемых систем, который продолжается до сих пор параллельно с работой в ВУЗе.Проблема статьи в том, что, как я понимаю, писалась она под широкую аудиторию, а не для профильных специалистов, поэтому многое упрощалось и тут возникает вопрос стоит ли подобное выкладывать в сеть?)
С одной стороны - это полезно и бегло даёт понимание, с другой, судя по комментариям, все хотят больше тонких нюансов для обоснования позиции, но тут тогда и аудитория статьи станет резко меньше и массового читателя не привлечёт.ruomserg
27.07.2022 17:24+1Такое — однозначно, нет. С тем же успехом можно было написать — что "… не надо строить реальную автоматизацию на ардуино, потому что эти платы в основном синего цвета, а для нормальной работы нужен зеленый цвет плат". Идея верная, а аргументация куда-то не туда.
Если есть желание отвратить публику строить реальную автоматизацию на ардуино, следует доступным языком рассказать, почему. А не кивать на температуру и не высасывать из пальца странные примеры… Которые — как раз, будучи прочитаны непрофессионалами — могут вызвать обратную реакцию: «ух ты — у меня же не загорается в руках светодиод, значит помех нету, и оно будет работать!». Вообще, если речь идет о том, чтобы направить «среднего разработчика» — не следует говорить о том, чего не надо делать. Рассказывайте как надо! То есть если у ардуинщика получился макет, который заработал — то что ему дальше делать? Дадите работающий рецепт, люди пойдут…4sense
27.07.2022 17:43Абсолютно согласен с Вами согласен)
Ибо в рабочих проектах очень часто удобно что-то попробовать быстро и просто именно вот на ардуино подобных платах. и это не отменяет их пригодность в ряде случаев общего назначения, тем более, если разработчик отдаёт себе отчёт какие ограничения накладывает на него используемая программно-аппаратная платформа.
А по поводу выхода таких статей в свет, то я думаю тут повторяется давняя история со студентами, которым нужно было для зачёта писать статьи на хабр, но с нюансом, что уже ВУЗу нужна некоторая цитируемость в техническом блоге, вот и пытается кружок журналистов по поводу и без что-то печатать в сеть, а большинству опрашиваемых не очень удобно тратить время на лекции журналистов... Вот так, наверное, и выходит что-то сюда порой в сыром виде)
leshin_papa
29.07.2022 11:23Как красиво высосана проблема из пальца. Создатель системы не учел основную проблему, значит Ардуино омно!
randomsimplenumber
Целый профессор не в курсе про watchdog в древнем микроконтроллере.
Z2K
нэа, он теоретик. Тут побольше апломба нагнать надо.
juramehanik
Нагнал много чего полезного (и вредного ) но вот как мне кажется важного не сказал.
Проблема все таки не в самой Ардуине (как семейства железок и софта) а в ЦА на которую оно рассчитано. И это, если что, не оскорбление ни первых ни вторых =).
Это гениальный конструктор для тех, кто слабо знаком с электроникой. Для тех кому надо решить с помощью нее какую-то интересную задачу. Электроника тут не самоцель, а лишь инструмент, и максимальной быстрый в применимости инструмент из всех, что есть на рынке.
Но вот чтоб эффект Даннинга — Крюгера не завладел теми, кто научился включать ватчдог и думает, что теперь он сделает серийную железку на основе своего пет-проекта как раз и рассчитана эта статья, ну и дополнения в комментах.
smoluks4096
watchdog не работает на ардуинах со старым бутлоадером (читай: на всех китайских), потому что старый бутлоадер его не сбрасывает, и оно уходит в бутлуп