Закралась у меня идея вспомнить былые времена типа этих (Как я делал шпору, а в итоге получилась игра "змейка"), взять паяльник в руки и спаять все самому.

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

Для устройства нам понадобится всего лишь...

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

Как должно работать устройство

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

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

Плюсом была бы возможность регулировать частоту включения-выключения / настраивать продолжительность удержания устройства во включенном или выключенном состоянии. Пока это все требования.

Микроконтроллер и программатор

Устройство будем собирать на базе МК Atmega32 в таком вот корпусе как на картинке (рублей 160 стоит на Али). В качестве програматора использую программатор USB ISP v2.0:

Программатор стоил рублей 200 Авито. Хороший он или нет... Да мне это не так важно, задачу свою выполнил и ладно. Ну и мелочевку заказал: разьемы за 60 руб с Али и штук 5 индикаторов за 150 руб с того же Али.

Вроде пока ничего сложного, ну разве что у индикатора 4 разряда с точками и на все это дело 12 ног. А это значит что в индикатор уже вшита идея переключения разрядов через 4 ноги.

Разряды переключаются минусом, а сегменты зажигаются плюсом. Мультиметром прозваниваем и находим что к чему относится. У МК потребуется 11 ног на отображение счетчика: 7 на цифру и 4 на переключение между цифрами.

Подключаем индикатор, пробуем, видим как все работает:

Единственное что тайминг на мультиплексирование нужно настроить. Приложу программный код, сможете глянуть на него подробнее кому интересно. Мультиплексирование - это как раз то, как будет выводится счетчик, вернее разряды числа: МК быстро меняет разряд переключая плюс на минус (одна из 4-х общих ног разряда) и выставляет плюсами цифру на сегменте (другие 7 ног цифры). Так он проходит быстро по всем цифрам и мы видим итоговое число.

Работа с лампой

Был такой канал на ютуб где человека сильно било током когда он ошибался. Или его устройство полностью сгорало. Это происходило и у меня пока я собирал свой блок питания. Сжег много чего в т.ч. и конденсаторы на 50В 100мкФ. Хлопали они знатно, теперь мне известно для чего делают эти насечки на крышках:

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

Счетчик работает (проект на Github), далее нужно включать-выключать лампу и узнавать когда она перегорела. Идей насчет того как это сделать особо много не было и пытался наколхозить что-то типа реле из своего соленоида:

Но придумывать велосипед - это дело такое себе. Через пару попыток решил просто купить реле в магазине, а вернее 2 реле:
- работает от 12В (доп. блок питания), коммутитрует переменные 220В для включения и выключения лампы
- работает от 24в (блок питания лампы) и будет индикатором работы лампы
И да, нужен транзистор для запуска реле (КТ817Б), который получает сигнал на базу от МК (используем +1 ногу МК) через резистор 1кОм. На видео его ноги в центре.

Красивую схему рисовать не буду, извиняйте, но вот видео того, что получилось:

Это не фоновая музыка, а щелчки реле, коммутирующего 220 В с частотой 1 раз в 0,5 секунды.

Серая коробочка справа — это блок питания (220 В → 12 В). Сверху расположено силовое реле, которое коммутирует 220 В и включает лампу. В цепи лампы находится катушка вспомогательного реле (снизу). Блок питания питает лампу через это вспомогательное реле.

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

Итого по ногам: 4+7 (LED) + 1 (на транзистор для коммутации лампы) + 1 (на замыкания ноги МК для уведомления о состоянии лампы) = 13 ног.

Первое время пробовал коммутировать лампу таким реле:

Это качественное реле с атомной подлодки. Корпус латунный, снизу контакты в стекле, конструкция надежнейшая, провода мгтф, смотрите сами. Ему, наверно, более 50 лет и чего оно только не пережило, но не меня 😂 Мне примерно так и было это все сказано после того как сломал его 😂

Так удалось сжечь лампу или нет?

Нет, не удалось. Счетчик натикал 9999, потом еще раз 9999. В сумме (примерно) 2 года работы лампы сымитировал по 30 включений-выключений в день.
Уже тайминги настроил разные на случай, если встроенный БП лампы не успевает разрядиться после снятия питания, но лампа на стенде так и не сгорела. Да что такое ! 😂😂😂 Значит дело не в циклах включения/отключения. Нужно изучать процессы в лампе чем-то более серьезным чем мультиметр 😂

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

Ссылка на проект на Github

Что с сервисом для общения?

Пока в процессе работы над чатами. Дело движется медленно, но уверенно. В основном работаю над обменом сообщениями, удалением сообщений, удалением чатов и прочими ситуациями.

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

Вторая часть работы по моей разработке отказоустойчивых ПЛК.

Кто читает впервые:

Я, автор , независимый исследователь ( тот который не работает за счет фондов, институтов и организаций), разработчик SCADA системы Gatherlog.

А так же автор комплекса по разработке Промышленных Контроллеров под названием 3o|||sheet. Среда, IDE читается как Зошыт - тетрадь, но так как для компилятора и среды выполнения названия не придумал, пока все называю 3o|||sheet.

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

В прошлый раз, показал свой научный метод Дивергентного Многоверсионного Выполнения Программ для усиления ошибок, которые пропускают классические методы типа lockstep\TMR.

Суть моего метода в - декорреляции адресного пространства. Мы компилируем программу N раз (смотря сколько ядер или какую точность детекции выбрать) перемешав в памяти код: функции, блоки, и переменные. То есть, если на первом ядре функция Main будет по адресу 1000 то на втором ядре она будет по адресу 2000. Точно так же с переменными - они перемешиваются по разным местам (но не случайным образом).

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

Это совершенно не влияет на ход программы. Каждое ядро, его счетчик команд, будет синхронно прыгать по своим адресам, но траектории программы - будут абсолютно одинаковы.

То есть, при корректной работе, - программы будут идентичны, а при сбое - каждое ядро будет сходить сума по своему из за декорреляции адресов. Это ключевой принцип, так как современные методы lockstep/TMR при сбое (одинаковом сбое всех ядер) сходят сума - одинаково, а значит согласовано, система не заметит сбоя. Это реальная проблема признанная в промышленности. Которую я решил.

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

В прошлом посте, были сообщения, что я все эти ошибки - придумал (радиацию, электромагнитные импульсы), и сам их победил. А в системе достаточно - таймера, который сбросит если все зависло. Так говорит - старая школа, но так было раньше. Почему старые процессоры x386 x486 выпускались 30 лет и до сих пор летают в самолетах? Грубый тех процесс более устойчив к физическим помехам (радиации и электромагнитным полям) на высоте 10 000 метров. Чувствительность современных микроконтроллеров и процессоров к физическим сбоям из за мелкого тех-процесса обсуждается, изучается и все признают эту проблему которая будет только увеличиваться.

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

В своей работе они описывают следующее:

Теперь, когда мы разобрались, что повреждение счетчика команд из за физического воздействия - не моя выдумка, а минимум выдумка еще несколько десятков профессоров,

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

Второе дополнение под названием: Detection of Small-Magnitude Program Counter Faults. Где я предложил следующий подход. Наш компилятор - вставляет пустые инструкции NOP , периодически, и сдвинуты по фазе в разных репликах(ядрах).

Шаг этих вставок NOP соответствует - детекции пропуску инструкций. То есть, если бы ученые пытались взломать мой ПЛК, а я бы в настройках компилятора установил шаг 6(L)/2(N) - наша система бы зафиксировала пропуск 3 и больше инструкций.

В моем ПЛК в системе есть модуль канонизации инструкций (которая выбирает - что в 32 битной инструкции, какие биты отслеживаем в траектории программы). Этот модуль инструкции NOP просто игнорирует. NOP - инструкция ничего не делает, и их вставка не влияет на программу, но - раздвигает адреса. А теперь хитрость.

Хитрость в том что, если программа идет последовательно - все ядра покажут идентичный ход выполнения. Но , если было физическое воздействие, и счетчик перепрыгнул допустим на 3 три инструкции который вкладывается в формулу :

смотри рисунок, одно ядро окажется на инструкции iD а второе на инструкции iE . Пропуск будет детектирован и ошибка наблюдаема.

В моем методе есть недостатки, вставка NOP - увеличивает память, и в моем компиляторе есть возможность выбирать критические участки кода где это используется:

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

Но так же усиливаем бдительность в критических участках кода , переводя систему в безопасный режим, даже если будет пропущена 1 инструкция (ПИД регуляторы и другие какие то системы).

И, что важно, никаких грубых методов типа WDT ( таймера) или выдернуть шнур питания на 10 секунд и перезагрузить. Решается вопрос сбоя программы тонко, а его детекция - быстро , в течении - наносекунд при первом же расхождении программной трассы.

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

В следующий раз, когда вернусь к вопросу отказоустойчивости - проведем уже эксперимент с физическим воздействием.

Задавайте вопросы в комментариях и на почту zoshytlogic@gmail.com.

Не забывайте читать прошлые посты.

Прошло три месяца с последних постов о ходе разработки, с того времени все кардинально изменилось в плане архитектуры. Это время я занимался - наукой, и определил направление работы дальше.

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

Кто читает впервые:

Я, автор , независимый исследователь, разработчик SCADA системы Gatherlog

А так же автор комплекса по разработке Промышленных Контроллеров под названием 3o|||sheet. Среда, IDE читается как Зошыт - тетрадь, но так как для компилятора и среды выполнения названия не придумал, пока все называю 3o|||sheet.

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

3o|||sheet теперь использую для научного звания, по теме нового метода - отказоустойчивых систем. Собственный компилятор предоставляет широкое поле для экспериментов, а среда разработки с графической системой - делает демонстрации по всяким институтам - интереснее. В прошлых постах - есть все (описание компиляторов, и сред, концепций и прочее).

В этом посте расскажу как из простого микроконтроллера типа STM32G030 создать отказоустойчивую исполнительную систему внутри Промышленного Контроллера.

В прошлом посте частично коснулся разработанного мной метода отказоустойчивости -

Дивергентного Многоверсионного Выполнения Программ (DME). Суть ее в множественной N компиляции одной программы. Так называемая - программная (а если это на FPGA или многоядерных CPU) аппаратная избыточность типа Lockstep / TMR.

Как все начиналось

Чтоб сделать ПЛК который поддерживает много языков и функций (например - замена участков кода на лету и прочее) нужен собственный рантайм и компилятор который будет переводить любые языки ( LD FBD ST) в собственные инструкции. Первая версия моего компилятора давала сбой - то одно не верно посчитает, то другое. Я столкнулся "паразитными" смещениями по адресам, а точнее - в сложных местах программа могла не туда перейти, не то прочитать или не туда записать. Программа слетала, и не понятно в каком месте была ошибка - так как при тихом повреждении данных (silent corruption), и физическим вылетом могло пройти много времени, - замучаешься пошагово следить в отладке.

Тут я подумал, а что если компилировать одну и ту же программу - два раза? Но вторую копию - перемешивать адреса функциям, блокам, переменным чтоб аналогичные по названиям переменные и функции второго экземпляра были не на том месте как в первой компиляции. Если компилятор все верно считает, нет никаких паразитных смещений, то каждая инструкция будет совпадать во всех копиях. Адреса у них хоть будут разные, но ход программы будет логически идентичен (смотри рисунок выше). А если адрес не верно просчитан - то в каждой копии программа запишет/прочитает или перейдет в логически разные - места. Тем самым детекция ошибки произойдет сразу.

Так и было, - две компиляции но разные структурно в памяти - все паразитные смещения из за бага компилятора - всплывали сразу. Так называемые silent corruption (скрытые ошибки) - стали наблюдаемы. Это позволило точно отточить алгоритмы просчета адресов, и больше компилятор не ошибался. Ну а дальше вы знаете: писал посты, тестировал разные микроконтроллеры как ПЛК.

Тогда я даже сам не понял что я придумал, и широкие возможности применения своего метода DME.

Отказоустойчивые системы

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

Lockstep - две копии (одинаковые бинарники) программы на двух процессорах работают и сверяют друг друга на каждом шаге.

TMR - три копии (одинаковые бинарники) программы на трех процессорах. Если одна отличается, происходит голосование , кто не прав и работа выполняется дальше.

Оба метода применяются в авиации, атомной энергетике и прочее. Стандарт.

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

И тут я заметил, мой метод с деккореляцией адресного пространства который я применял в отлаживании компилятора - решает эту задачу!

Если система Lockstep и TMR "одинаковость" воспринимают как ОК, мой метод наоборот - одинаковость воспринимает как как - осторожность. А разность - как нормальную работу. Но у моего метода есть два типа разности:

• Допустимая разность - это адреса (адреса функций, счетчика команд, переменных и т.д).

• Не допустимая разность - в последовательности инструкций ( семантика ).

То есть, в системах Lockstep и TMR сводится к 1/2 :

• Либо одна из копий программы ведет себя по другому - это ошибка.

• Либо ведут себя одинаково - значит все хорошо. Но тут и проблема одинаковых бинарников, если все копии выполняются одинаково не верно, система будет думать что все хорошо.

В моем методе DME, соотношение 1/3 . Где:

• одинаковая логика/инструкции - это Хорошо.

• одинаковость адресов -Плохо.

• разная логика/инструкции - Плохо.

Я сделал более узким коридор для корректности , и расширил коридор для прохождения ошибок (усилил ошибку).

Lockstep и TMR - совсем не ловят программные ошибки. Если в компиляторе есть специфический баг из за оптимизации или просто программа так написана - это не покрывается. Копии идентичны и поведут себя одинаково , а значит система не заметит. Проблему решают N-Version Programming - когда нанимают две группы программистов, и они пишут программу по разным вариантам (Airbus/Boeing). Очень дорогое, и медленное удовольствие. В общем не для ПЛК за 30$.

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

Практика

Создаем - тестовый проект в языке LD. Моя среда поддерживает  FBD но так же пока только внутри LD. ST язык я не реализовал в полной мере, но на каком бы языке программа ни была, она переводится в единый виртуальный ассемблер (собственный синтаксис и инструкции, см. прошлые посты) который выполняется внутри на голом железе Микроконтроллера, FPGA  или любого CPU.

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

Настройка компиляции в 3o|||sheet:

N - количество копий программы и количество соответственно компиляций. N Должно соответствовать количеству ядер, или ПЛК если они работают в режиме похожему на Lockstep\TMR. На STM32G030 эти ядра эмулируются, в чем смысл - дальше.

+1 -1 это команда разнесения адресов в разные по знаку стороны. Если в одной копии переход из функции А к функции Б изменяет программный счетчик например PC+=94, то в второй копии компилятор организует этот переход PC-=64. Усиливает декорреляцию адресного пространства, соответственно увеличивает область детектируемых программных багов и программных ошибок из-за физического влияния среды.

Canonical trace hash: Инкрементальный хеш выполнения программы (если есть аппаратный хеш как у Cortex M4) , но на слабом железе вместо хеша может подойти обычное сравнение каждой инструкции (опкода или результата) каждой копии программы простым "=", или хеш может быть банальным XOR с степенью ( за 2 такта, это + 10..20 наносекунд к выполнению инструкции, дешево ).

Тут принцип тот же что и Lockstep\TMR - N копий программы на ядрах, только в Lockstep\TMR сравниваются идентичные бинарники и состояние на каждом такте, у меня только логическая траектория, потому что адреса переменных и инструкций в копиях разные - они (адреса) исключаются из уравнений.

Любая программа, LD ST C++ не важно, состоит из блоков кода и функций. Мой компилятор их и перемешивает по разным адресам и разным знакам (+-) направлениям перехода. Если мы скомпилируем программу, то получим пространственные -разные версии одной программы:

Если мы присмотримся к адресам функций на скрине, то увидим в одной копии например Main будет по адресу - 0 (ноль) в другой копии она же будет по адресу - 144. Так и со всеми остальными. Выполняется главный принцип DME - усиление ошибки программы через структурную декорреляцию адресного пространства.

Теперь, предположим в системе произошел коррелированый сбой, то есть такой который задевает все ядра или все копии программы. Чаще это возможно  когда программа криво написана, затерла адрес возврата, или  другого участка программы. Проблемы с питанием - тоже может повредить все ядра одинаково. Радиация, или помехи -  риск минимален в атмосфере на Земле. В самолете на высоте 10 000м вероятность сильно возрастает, а в космических аппаратах бомбардировка процессоров частицами которые вызывают сбои происходит несколько десятков раз в сутки.

Давайте предположим, что сбой произошел (неважно по какой причине) ,  адрес возврата или какого либо перехода ветки , установлен в случайное значение 148:

Был бы это обычный отказоустойчивый ПЛК типа Lockset или TMR за 5000$ , они бы не заметили фатальной ошибки, так как бинарники одинаковы. Система бы увидела у всех копиях одинаковое значение и подумала что все хорошо.

Но наша система декоррелирована по адресам , это вызовет - Дивергенцию. Система фиксирует - две разные инструкции одновременно: CALL и  SDPHY. Несовпадение. Компаратор вызовет программу X (типа обработчик ошибки) или  осуществит переход в безопасное состояние.

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

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

Codesys, Siemens не имеют компиляторов с декорреляцией адресного пространства, их детекция ошибок сработает только если один ПЛК или ядро и отличаться от другого. А когда оба ошибаются - программа благополучно  упадет и до этого может наделать много лишнего.

Что отказоустойчивого можно выжать с дешевого слабого МК STM32G030.

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

Time redundancy, EDDI/SWIFT

В моем методе DME, в одноядерной системе инструкции N копий выполняются по очереди псевдо-параллельно, а следовательно, каждая инструкция выполняется N раз и получается с задержкой по времени.

Есть такой метод отказоустойчивости Time redundancy - выполнения идентичных инструкций с задержкой по времени. Вот как это описывается:

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

Тип ошибок: Этот метод наиболее эффективен против кратковременных (перемежающихся) сбоев, вызванных внешними помехами (космические лучи, электромагнитные шумы).

EDDI и SWIFT - известные методы дублирования . Все эти Time redundancy, EDDI/SWIFT являются у нас побочным эффектом из псевдопарралельности нашего ПЛК в одноядерной системе.  Наш ПЛК с  DME перестаёт быть “чисто структурной” DME защитой с перемешанной памятью, а превращается в гибрид:

time redundancy + DME + семантический анализ и контроль данных

Таким образом, DME  защищает программу от программных и коррелированных  багов, которые не детектируются вообще Codesys, Siemens, а вторичный эффект  Time redundancy, EDDI/SWIFT которые вытекают из псевдо-параллельности  дает устойчивость к физическим влияниям на систему. И делает наш ПЛК устойчивым к:

Transient faults (SEU, EMI, glitches) одиночный бит-флип в регистре, кратковременный сбой ALU, помеха на шине. Сработает эффект DME , Time redundancy, EDDI/SWIFT.

Control-flow faults (PC corruption, jump errors) повреждение PC, бит-флип в адресе возврата , неправильная ветка. Сработает DME защита.

Memory corruption (stack/heap, out-of-bounds) переполнение буфера, повреждение указателя , повреждение данных в RAM. Сработает DME защита.

Повреждения данных\ переменных (для дешевых микроконтроллеров у которых нет ECC это критично).

Исследователи указывают что метод SWIFT имеет "чрезвычайный широкий охват детектируемых ошибок" , но SWIFT требует наличие в памяти коррекции ошибок ECC, которого нет в простых микроконтроллерах. Да и ECC поможет только если фзика изменила только один бит, если изменены несколько бит, ECC (а значит и SWIFT ) бессилен, потому что не восстановит данные. А еще, SWIFT в отличии от моего метода DME  - не видит ложные переходы программы.

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

Производительность ПЛК на STM32G030 в режиме отказоустойчивости

У моего метода DME конечно есть недостатки (если он работает на одном ядре) . Дублирование программы на N реплик соответственно замедляет ПЛК в N раз.

Как то видел в домашних производителей ПЛК, STM32G030 использовался просто как микроконтроллер для модулей расширения вводов\выводов . А ведь этот Микроконтроллер производительнее ПК на i486 1992-1994 годов, и гораздо производительнее наверное чем вся электроника корабля летавшего на Луну.

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

Mitsubishi (китайский клон) STM32F103------------------------------------2.7---------------математика int 8.6

Allen Bradley Micro 810 -----------------------------------------------------------------2.5---------------математика int 8.5

Siemens LOGO!------------------------------------------------------------------------------ 5.0

Schneider Electric Zelio Logic --------------------------------------------------------10.

====================================3o|||sheet==================================

3o|||sheet STM32G030 (N=2) отказоустойчивый режим---------- 4.5 --------математика int 13.5

3o|||sheet STM32F407(N=2) отказоустойчивый режим------------ 2.1 --математика int/float5.2

3o|||sheet STM32F722(N=2) отказоустойчивый режим-------------0.9 --математика int/float2.3

3o|||sheet Cyclone |V 50 MHz (N=2) отказоустойчивый режим-- 0.1 ---------математика int 0.1

Наш ПЛК, название не придумал , пишу с названия среды моей разработки 3o|||sheet.

В режиме отказоустойчивости, с циклом 10 миллисекунд, наш ПЛК 3o|||sheet STM32G030 отработает примерно 1100 операций: 550 - логические (контакты катушки) + 550 математические. Если брать ST, то математика и булевые операции так и остаются, а каждое условие типа if(a== > < ! b) займет в памяти и по времени выполнения - максимум как две логические операции (в зависимости от "регистрового давления", насколько далеко a, b в программе использовались до этого).

Я бы не сказал что это мало от микроконтроллера который другие компании ставят просто в качестве расширяющего вводы выводы. В этом отказоустойчивом режиме он производительнее обычных программируемых реле Siemens и Schneider .

Какие MCU в реле Siemens и Schneider неизвестно, может и 16 МГц ( в нашем STM32G030 64 MHz) , я только констатирую факт.

3o|||sheet STM32F722х - вытянет в быстрых (по меркам промышленности) ПИД регуляторах в режиме отказоустойчивости.

Altera Cyclone |V EP4CE6E22C8 даже на 50 МНz , в отказоустойчивом режиме, показывает впечатляющий результат, в цикле 1 миллисекунды отработает 8000 логических или математических (целочисленных) операций. .

Часто пишут что - главное не скорость, а надежность. Но чем быстрее выполнение инструкций, тем меньше можно сделать цикл, или тем сложнее программу можно втиснуть в один цикл.

Вернемся к отказоустойчивости. Интерпретируемость байткода дает серьезный отказоустойчивый эффект:

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

В то время, 1 виртуальная инструкция "размазана" по нескольким десяткам или сотням тактов, и состоит соответственно из десятков нативных инструкций. Есть проигрыш в скорости, но воздействие в месте X изменит только логику самой инструкции (например 2+2 станет = 5, и переход на ветку В вместо А) но не повредит программу в целом. А так как у нас еще работает вторая копия программы , наш метод DME - зафиксирует и проконтролирует ошибку.

Из за дополнительного рантайма (например моего 3o|||sheet) память программ увеличивается на 45-50 килобайт, в отличии от программы которая допустим написана на СИ, и с точки зрения вероятности - возрастает событие из за помех которое что то подпортит внутри процессора.

Но, если и подпортит, то последствия не такие катастрофичные как если физика подпортит - нативный код, без контекста рантайма. Потому что "логическая плотность" нативного кода сильно ужата. Как петарда которая при взрыве разбросает плотно стоящие спичечные коробки (логику) возле эпицентра, но имеет меньше влияния если эти коробки далеко друг от друга и по площади дальше от эпицентра. Что то зацепит и упадет, но разрушимость логики не та, потому что 1 виртуальная инструкция, ее логика состоит из десятков нативных инструкций, а результат ее - всего лишь - одно число в конце, и его ошибочность будет замечено дальше.

А чем твой ПЛК отличается от других. Или про изобретения велосипедов.

Это частый вопрос гастролирующего читателя. Вот в каждом комментарии есть такое.

Во первых, китайцев существующие немецкие велосипеды Codesys, Siemens  не останавливали, китайцы начали делать свои ПЛК (наверно разработчикам в Китае трудно было всем отвечать, зачем делать ПЛК создавая велосипеды, если уже были готовые где то в Германии).

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

Извиняюсь за нескромность, но я не вижу себе конкурентов по инновациям в этом направлении, в первую очередь среди местных производителей. Я видел их сертификаты SIL3 SIL4 , но вряд ли там что то новое чем Lockstep/ TMR.

У меня проработан, конкретный , особенный, нигде ранее не встречающийся метод DME.

Во вторых - в Beremiz , китайских клонах Mitsubishi, и прочих дешевых ПЛК  до 100$ ( а может и до 500$) близко нет никакой отказоустойчивости.

Устойчивость к  коррелированным сбоям - вообще ни один ПЛК ни одного мирового бренда не имеет , в мире этот вопрос решается - дорогими специальными CPU - разнесением ядер на кристалле максимально удаленно друг от друга. Или N Variant Programming с разными группами программистов. Мой метод первый решает эту задачу структурно/программно (то есть - дешево).

В следующий раз расскажу часть моего метода DME "Periodic Layout Diversity" , который призван бороться с малыми глюками потока программ, тот самый Periodic Layout Diversity , когда из за внешнего воздействия может быть пропуск инструкции или несколько инструкций. Ни одна система в мире такое не детектирует, а это критично если в ПИД  регуляторе или каком то автомате будет пропуск команды.

В ней четко прописана математика. Больше всего у меня претензии к  мировым  и домашним брендам, по -  доказательствам надежности. У них это - тесты в лабораториях, которые не факт что будут соответствовать на 100% рабочей обстановке. Я подошел к вопросу - математически, что кстати дешевле и легче для сертификации так как легче доказать надежность.

Мой метод DME , гарантирует   математически -  либо код отработает корректно, либо сразу остановится и контролировано перейдет в безопасное состояние. Но никакого неопределенного поведения.

Еще вопросы можно задавать в комментариях и на почту  zoshytlogic@gmail.com

Недавно в моих руках оказался уникальный кнопочный телефон - Маском Н2. Сначала я подумал что это просто китайский NoName-телефон по типу DEXP'а, или Fly'я, однако сняв заднюю крышку - я обомлел... И в том числе из-за использования корпуса от неприметной раскладушки - Samsung GT-C3520. Интересно узнать, что он скрывает у себя внутри?

Что за девайс?

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

Казалось бы, на первый взгляд это просто китайский бюджетный NoName-телефон с переклеенным шильдиком и кастомным логотипом, где из чипов только система на кристалле от MediaTek/Spreadtrum, микросхема флэш-памяти и усилитель мощности. Однако здесь внимание сразу привлекает использование внешнего радиомодуля Telit, который сам по себе стоит около двух-трех тысяч рублей. Не слишком похоже на обычный кнопочник...

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

Комплект поставки максимально простой: сам телефон, зарядное устройство и небольшой мануал. Если честно, упаковка немного напоминает советскую - и этому есть своя причина.

Дело в том, что данный телефон стоил целых 34 тысячи рублей и предназначался специально для государственных служб. В мануале указано что устройство является защищенным и физически отключает микрофон при закрытии флипа, благодаря чему его можно использовать на закрытых собраниях. Если честно, я так и не понял почему телефон нельзя использовать для обработки чувствительной информации, но можно ходить с ним на собрания. Если кто-то шарит - расскажите пожалуйста в комментариях :)

Что внутри?

Увидев модем от Telit, я просто не смог удержаться и не разобрать Н2, дабы узнать что-же он там скрывает внутри. Серийный телефон на нестандартной платформе, да ещё и разработанный в РФ... У меня аж мурашки по коже были от потенциальной крутости такого устройства :)

Схемотехника и инженерные решения оказались очень необычными по меркам телефона. Например за питание в обычных кнопочных отвечает отдельный чип - так называемый контроллер питания, который совмещает в себе чарджер, DC-DC преобразователи, набор LDO, а также Watchdog. В Маском Н2 же используются отдельные чипы, выполняющие схожую функцию: например за зарядку отвечает модуль TP4056 разработки TPower, за питание микроконтроллера (процессора) - обычный 3.3v/300mA ULDO-регулятор по типу AMS1117, а в качестве драйвера, формирующего питание подсветки дисплея - Texas Instruments LM2733YMF. В качестве того самого механизма защиты с отключением микрофона используется аппаратный SPDT-свитч Analog Devices ADG884, Input-сигнал для которого идёт с датчика Холла флипа устройства. Решение весьма изящное :)

Радиомодуль Telit GE866-QUAD достоин отдельного разговора. Это по сути почти готовый внешний телефон, который общается с микроконтроллером или AP-процессором посредством шины UART. Общение происходит обычными AT-командами, как и в случае с радиомодулем вашего смартфона. Внутри него скрывается:

• Неизвестный Baseband-процессор, состоящий из обычного ARM (?) ядра и DSP-сопроцессора для работы с GSM-модулем. Именно он выполняет основные функции телефона: звонки, СМС, работа с SIM-картой, хранение телефонной книги и даже выход в интернет. В обычных кнопочных телефонах, Baseband сразу же выполняет функции центрального процессора и отвечает за пользовательский интерфейс, Java и другие функции.
  
  Baseband возможно собственной разработки Telit, а возможно и что-то от MediaTek/Qualcomm - как в случае с SIMCOM SIM800 (по крайней мере, Telit использует Qualcomm'овские MSM'ки в своих LTE-модемах).

• RF-фронтэнд (может быть как частью бейсбенда, так и отдельным чипом). Он отвечает за всю "магию" под капотом аналоговой части и перегоняет исходящие цифровые GSM-пакеты от DSP в аналоговый сигнал на усилитель, а входящие из эфира - в цифровой. Если я не ошибаюсь, именно фронтэнд считает число палочек качества связи :)

• Усилитель мощности. Тут думаю всё очевидно.

• Возможно микросхема флэш-памяти с прошивкой модема, однако флэшка может быть и частью Baseband'а.

Интересно и то, что Telit сама когда-то делала ODM-телефоны для других брендов. У нас некоторые из них продавались под брендом RoverPC (RoverPC M1 - Telit SP600) и i-Mate (JAMA). Наверняка есть ещё какие-то интересные модели :)

Самое интересное у Н2 скрывается под металлическим экраном... и это микроконтроллер STM32F427 производства компании STMicroelectronics, который используется в качестве центрального процессора. Это очень "жирный" и крутой микроконтроллер, который состоит из:

• Одного ARM-ядра Cortex-M4F, которое способно работать на частоте до 180МГц. Это в три раза больше, чем у ARM7TDMI в Motorola E398, в полтора раза больше, чем ARM926EJ-S в Siemens S65 и примерно на уровне Nokia времен C2 и X3. Однако M4F - куда более современное ядро и выдаёт 225 DMIPS в бенчмарке Dhrystone, что ставит его примерно на уровне Pentium MMX 200 (Dhrystone 2 с оптимизациями) и Pentium III 450 (без оптимизаций). Кроме того, у M4F есть FPU - заметно помогает с отрисовкой графики.

• 2 мегабайта встроенной Flash-памяти и 256 килобайт оперативной SRAM-памяти. Для сравнения, в Siemens C65 32 мегабайта NOR-памяти и 4 мегабайта SDRAM (но в Н2 основная память в модеме).

• Большого числа периферийных ядер: FSMC для подключения внешней памяти, контроллер 8080-дисплеев, три 12-битных ADC, два 12-битных DAC'а, 4 UART'а, 3 I2C... прямо таки мечта эмдбеддщика :)

Основная изюминка здесь в том, что обычно в кнопочных телефонах не используют микроконтроллеры общего назначения. В них используются однокристальные ASIC'и, которые были разработаны специально для использования в мобильных гаджетах в целях максимального удешевления производства. Здесь же используется дорогущая STM'ка, которая сама по себе стоит не меньше 400-500 рублей (MediaTek MT6261DA стоит около 300 рублей при мелком опте, а это уже почти готовый телефон), что и намекает на мелкосерийную и российскую натуру разработки устройства.

С обратной стороны платы расположился копирайт (в ODM-устройствах информация о производителе обычно не указывается, ограничиваясь маркировкой модели). Мой экземпляр произведен в 2019 году.

В целом, конструктивно телефон прост и надежен как автомат АК-47. Он собран из обычных компонентов, которые можно найти в любом более-менее крупном радиомагазине, все чипы используют выводные корпуса, а не BGA, что делает телефон устойчивее к падениям, а вся схемотехника устройства считывается глазами инженера за пару минут. Единственное действительно слабое место устройства - модуль зарядки TP4056. Дело в том, что у этого чипа очень много подделок и контрафактные экземпляры банально не держат ток зарядки в 500мА и выше, сильно нагреваясь и перегорая. Но учитывая емкость родного Samsung-овского аккумулятора в 800мА, вряд-ли чарджер здесь подвержен серьезным нагрузкам...

Включаем

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

Поскольку в качестве основного процессора здесь используется микроконтроллер общего назначения, прошивку инженерам пришлось написать с нуля. Вся UI-часть телефона, плюс управление модемом разработано в РФ, что иронично - ведь когда-то у нас частично разрабатывали Motorola E398, CDMA-телефоны LG и по слухам некоторые телефоны Samsung.

Основное меню устройства состоит всего из четырех пунктов: настройки, журнал звонков, контакты и СМС. Функционал беднее чем в Nokia 3310, но учитывая назначение Н2 этому особо не удивляешься. Нет даже змейки, хотя процессор устройства способен потянуть Doom и даже Quake!

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

У Н2 также есть некая программа для синхронизации с ПК, которую мне найти не удалось. В пункте Настройки можно найти специальный пункт для этого, а софт показывает число переданных данных (байтов? Пакетов? Контактов?)

Интересен и тот факт, что данные хранятся только на SIM. Это чётко можно заметить по окну "пожалуйста, подождите" при запуске меню сообщений, поскольку в это время телефон запрашивает данные из модема.

В целом, по программной части телефон очень простой и в нем реализован лишь базовый функционал. Однако это не делает его плохим или бесперспективным: я думаю что если бы Н2 был более массовым (пусть даже при цене в 6-7к рублей), то его давным давно бы уже замоддили, запилили кастомные прошивки и возможно даже написали свою с нуля. Но увы, к сожалению этих телефонов очень мало, на авито их не найти и телефон, который может по праву называться российским, так и канул в лету. Может хоть я оставлю небольшой след на скрижалях истории? :)

Заключение

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

А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.

Если вам понравилась статья и вы хотите меня поддержать, у меня есть Boosty, а также виджет на Пикабу ниже. А ещё мне можно отправить какое-нибудь интересное железо: устройства на WinCE/WinMobile, смартфоны на Symbian, китайские кнопочники, китайские подделки на iPhone/Samsung из начала 2010-х, ретро-ПК железо - всё это я очень люблю, коллекционирую и пишу о них интересные статьи - как, например, эта :) Всем огромное спасибо!

В основе лежит проект: https://github.com/VolosR/tDisplayS3WeatherStation
Автор оригинальной прошивки VolosR

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

Ниже инструкция, как это все собрать и прошить. Можно пойти по пути оригинала, можно прошить мой кастом - выбирай, что больше нравится.

Ссылка на мой кастом: https://disk.yandex.ru/d/O7YIKCXI5yJWFw

Прошивка осуществляется через Arduino IDE.

Что понадобится

• модуль LilyGO T-Display S3 (можно заказать на Ozon, или на AliExpress)

• Arduino IDE на вашем компе

• кабель USB-C (желательно не длиннее метра, иначе могут быть отвалы при прошивке)

• интернет (для погоды и времени)

Подготовка Arduino IDE

1. Добавляем поддержку ESP32

Открой "Файл - Параметры". В поле Additional boards manager URLs добавь:

https://raw.githubusercontent.com/espressif/arduino-esp32/gh...

Сохрани.

2. Устанавливаем esp32 (важно!)

Зайди в "Инструменты - Плата - Менеджер плат".

Найди esp32 by Espressif Systems и установи версию 2.0.5 (другие версии могут ломать работу дисплея).

Затем в "Инструменты - Плата - esp32" выбери ESP32-S3-BOX.

В разделе "Инструменты - Partition Scheme" выбираем 8M with spiffs.

3. Библиотеки (ставить строго эти версии, так как на других были проблемы)

Через "Скетч - Подключить библиотеку - Управление библиотеками"

Установи:

• TFT_eSPI - 2.5.0

• WiFiManager - 2.0.17

• ArduinoJson - 7.1.0

• ESP32Time - 2.0.6

4. Файлы прошивки

Открой скетч WeatherTDisplayS3.ino

Рядом с ним (в папке проекта) должны лежать шрифты:

• NotoSansBold15.h

• tinyFont.h

• smallFont.h

• midleFont.h

• bigFont.h

• font18.h

Если они рядом со скетчем - Arduino IDE должен их подхватить автоматически. Если не подхватил - загружай вручную через "Скетч - Добавить файл".

Получаем API-ключ OpenWeatherMap

Без этого погоды не будет.

1. Зайди на: https://openweathermap.org/

2. Зарегистрируйся

3. После входа открой "Профиль - My API keys"

4. Создай ключ, задав любое имя и нажми Generate

5. Скопируй ключ

6. Вставь его в код:

String myAPI = "ВАШ_API_КЛЮЧ";

Ключ может активироваться до 10-15 минут - это нормально.

Настройка прошивки под себя

В начале кода есть блок:

int zone = 3;

String town = "Moscow";

String myAPI = "ВАШ_API_КЛЮЧ";

String units = "metric";

Что поменять:

• zone - твоя таймзона

• town —- город (латиницей, как в OpenWeather)

• myAPI - твой API-ключ

• units - оставь metric

Прошивка платы

1. Подключи T-Display S3 по USB-C

2. Выбери в Arduino IDE COM-порт твоего S3

3. Нажми Upload

Начнется компиляция и в случае успеха пойдет прошивка.

После прошивки

Если устройство запустилось, на экране должно появиться сообщение "Connecting to Wi-Fi" и устройство должно поднять точку доступа WeatherStationSetup, пароль такой же как название точки.

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

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

Кнопки и экран

Нижняя кнопка (если держать устройство USB разъемом справа) переворачивает экран.

После перезагрузки экран остаётся в выбранном положении.

Если что-то пошло не так

• чёрный экран - почти всегда не та версия esp32 или TFT_eSPI

• погода не обновляется - проверь API-ключ и город

• не прошивается - переведи устройство в режим BOOT

Всегда можно написать автору прошивки на его странице проекта в гитхабе: https://github.com/VolosR/tDisplayS3WeatherStation/issues

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

Тег "Моё" я сознательно не ставлю, так как автором проекта не являюсь. Это не моя идея и не мой продукт. Я лишь постарался простым и понятным языком описать процесс создания устройства, чтобы с ним было легче разобраться. Да, в прошивку были внесены небольшие кастомные правки, но это скорее личные улучшения под свои задачи, а не повод выдавать проект за собственную разработку))

Надеюсь, что и у вас все получится. Удачи!