Мне многие говорили, кто со мной знаком, открой Донаты, тебе помогут. А я вечно в каких-то сомнениях. Кто будет заинтересован помогать со стороны? Видите какие проблемы с экономикой в стране, а тут я ещё со своими Донатами. Кому это интересно? И вот я решился. Я открыл первый свой сбор в жизни на Пикабу. Не знаю что из этого выйдет. Сам я люблю проектировать и создавать различные устройства на базе микроконтроллеров. Что-то получается, что-то ограничен в средствах и откладывается на неопределённый срок, но стараюсь, пытаюсь, создаю, шевелюсь так сказать. Сейчас сижу над проектом Робота доставщика и завис на проектировании печатной платы для драйвера бесщёточного двигателя.
EasyEDA кудаж без неё, Пытаешься сделать всё по правилам, но нарушил всё что можно нарушить в трассировке. Экономия средств... Нужно уложиться в габариты 50х100 мм. Не настолько богатый, чтобы делать произвольные печатные платы.
Вообще проектировка это затратное дело. Создать робота это не просто идея, это выбрать моторы, заказать электронные компоненты. Придумать блок схему, начертить схему, и сделать печатные платы под них, а это снова заказать. Ждать, ждать и снова ждать. Придумать механику и продумать, как всё должно шевелиться и двигаться. Придумать из чего сделать. И самое главное найти компромисс между тем, что должно в теории работать и тем, что стоит дорого.
Зацените мой редуктор GT2 - 2:1 в 3D. это не просто модель, он ещё и крутится, и причём без багов и тормозов :)
Вот например. Для того чтобы создать механику, нужно создать все 3D модели узлов, посмотреть, как это всё взаимодействует друг с другом. А ещё спасибо блин РКН, без него никуда. Хочешь найти информацию о сопряжениях, а фигли "тытруба" заблокирован, и ничего не посмотришь. А на русских платформах только несколько видео, и то, алгоритм одинаковый. Сделал редуктор GT2, посидел с калькулятором, При вращении зависает. Проанализировал, понял, где программа спотыкается. Казалось бы, обычная передача GT2... Но пришлось написать около 1500 строк кода, чтобы автоматически производить расчёт любого шкива, и самое главное обойти баги в программе 3D моделирования.
потратил целую неделю, на написание кода и геометрические расчёты, вспомнил синусы, косинусы и прочее геометрическое, и понял, что "геометрия пригодилась". Мой друг мне сказал: "Да не бойся ты ошибаться, это нормально". И с ним можно согласится, может быть я не тратил бы так много времени, но любая ошибка это удар по бюджету. Спроектировал корпус, отдал на производство, сделали, а ось подшипника смещена, или вообще не тот диаметр, и что? Покупать другие подшипники или всё переделывать? Ошибаться это нормально, вот только в моём случае накладно. Порой не хватает рук, а ещё сильнее не хватает времени, ну и средств. И если первое и второе имеет взаимосвязь, то вот последнее порой играет решающую роль. Ох были бы средства, нанял бы команду....... Влажные мечты проектировщика цифровых устройств))) Чтож с помощью людей или без, я буду биться, видимо как муха об говно стекло, но я проектировщик, может не такой сильный, но проектировщик, это видимо у меня в крови, причём с детства. Спасибо тем, кто дочитал до конца. Я надеюсь что через год-два, мне удастся воплотить главный мой проект.
На алике сейчас продают гиковские часы производства небезызвестной LCTech (компания разрабатывает SBC и всякие DIY ништяки). Их основная фишка в том, что с ними в комплекте нет прошивки (кроме референсной) - предполагается что гик напишет ее сам под свои нужды.
Схемотехника часов предельно простая, но в целом грамотная. На доске расположился сам микроконтроллер RP2040, состоящий из двух ядер Cortex-M0+, способных работать на частоте до ~300МГц, SPI-флэшка объемом аж в 4МБ (это хороший объем), чарджер литиевых аккумуляторов TP4056, LDO, опорный кварц и гироскоп QMI8658. Fuel gauge нет - вместо него VBat подключен к ADC микроконтроллера через 10k делитель.
Референсная прошивка написана на C, есть также сэмпл на MicroPython. Но как мы с вами знаем, я не пишу прошивки на китайских фреймворках и для DIY пилю все с нуля - в том числе и драйверы для периферии. Сейчас буду потихоньку разбираться, писать для них прошивку и затем выпущу здоровенный материал. Такой же, как в свое время про GamePi :)
Цена таких часиков - 1900 рублей, в комплекте есть ремешок, но нет корпуса. Очевидно что это устройство исключительно для гиков и не подойдёт обычному юзеру.
Кто разбирался в данном вопросе посвятите. Производетель без разницы хоть Kugoo хоть Teverun или любой другой. Либо производители свою пишут ОС под свой микроконтроллер? Или может используется FreeRTOS?
Ранее делился тут своими успехами по части разработки/доработки/исследования светодиодных ламп.
За 5 месяцев в ванной сгорело две из четырех светодиодных ламп. А в других комнатах лампы как горели, так и горят. У меня закралось подозрение, что частота их сгорания зависит от периодичности включения и выключения. В итоге решил проверить догадки, для этого мне нужно собрать на столе стенд с кнопкой, подключить лампу. Ну и включать-выключать ее до победного т.е. пока лампа не сгорит.
Я, конечно, не президент ЛЛ, но в какой-то степени в ней состою. По этой причине решил, что кнопку будет тыкать за меня кто-то другой. Кот отказался это делать, тараканы слишком легкие чтобы нажимать на кнопку... В итоге пришлось поручить эту задачу боту. Но бота-тыкателя кнопки почему-то за меня никто не собрал и даже за деньги его не продают. Кстати, ранее писал такого полезного бота: Бот-сборщик информации, (которого почему-то мало кто оценил, а зря) но он умеет только тыкать сайты. Физические выключатели переключать не умеет.
Но мне было бы лень если бы не заметил как мой отец очень часто смотрит телек, в котором в последнее время показывают политические шоу, обильно обмазанные непонятно чем с рекламой с двух сторон. В итоге отрываем отца от телека, сажаю его рядом с собой и вместе с ним собираю это устройство.
Для устройства нам понадобится всего лишь...
Много чего понадобится на самом деле, в основном азы программирования микроконтроллеров, азы радиоэлектроники и много радиоэлементов. Ниже уточню конкретнее что именно было использовано
Как должно работать устройство
Устройство должно работать следующим образом: подключаешь к устройству лампу или другой тестируемый прибор, включаешь устойство и оно начинает включать-выключать прибор пока он не сгорит.
Должен быть индикатор на котором отображается поптыка включения устройства. Если тестируемое устройство (лампа) сгорело, то счестчик попыток должен остановиться и точно показать на какой попытке произошел выход из строя тестируемого оборудования.
Плюсом была бы возможность регулировать частоту включения-выключения / настраивать продолжительность удержания устройства во включенном или выключенном состоянии. Пока это все требования.
Микроконтроллер и программатор
Устройство будем собирать на базе МК 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 включений-выключений в день. Уже тайминги настроил разные на случай, если встроенный БП лампы не успевает разрядиться после снятия питания, но лампа на стенде так и не сгорела. Да что такое ! 😂😂😂 Значит дело не в циклах включения/отключения. Нужно изучать процессы в лампе чем-то более серьезным чем мультиметр 😂
Осцилограф пока приобретать не планирую, как-нибудь после покупки сервера займусь этим. Но им было бы очень здорово проверить что происходит с лампой на каждом этапе ее работы.
Пока в процессе работы над чатами. Дело движется медленно, но уверенно. В основном работаю над обменом сообщениями, удалением сообщений, удалением чатов и прочими ситуациями.
-- Вообще, по вечерам больше не паяю, а делаю отечественный сервис для общения. Кому интересно, можете подписаться куда-нибудь на меня, попробуете сервис в числе первых. Постепенно буду продолжать делиться успехами разработки.
Про железку: купил я вот такую штуку - STM32H723ZGT6 (https://www.ozon.ru/product/1-sht-modul-otladochnoy-platy-s-...). Здоровая, сука! И программатор к ней - клон ST-link V2 (https://www.ozon.ru/product/programmator-st-link-stlink-st-l...). Через CUbeIDE прошить не могу - он наотрез отказывается скачивать что-то с интернета. В PlatformIO такой камень отсутствует, но есть Nucleo H723. Попробовал его с ST-link - не идет - ошибка. Вшитая с завода "мигалка светодиодом" успешно слетела, новая не встает, камень в защите. Выходит из защиты только если сделать st-info --probe с зажатым RESET, а потом отпустить и еще раз. Попытка стирания флеша проваливается. Или стирается, но новую прошивку не принимает. Прошил rpi-pico на picoprobe, подключил через SWD, шил через openocd. Перешил на micropython, шил скриптом через uart. Никак. Info : Listening on port 3333 for gdb connections [stm32h7x.cpu0] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc Info : Device: STM32H72x/73x Info : flash size probed value 1024k Info : STM32H7 flash has a single bank Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Bank (0) size is 1024 kb, base address is 0x08000000 Error: [stm32h7x.cpu0] clearing lockup after double fault [stm32h7x.cpu0] halted due to debug-request, current mode: Handler HardFault xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
В общем вот так. Основная проблема - не получается зашить в этот камень хоть что-то. Чего делать то, выкинуть нахер? Кто-нибудь уже успешно шил такую фигню?
Привет, Пикабу. Учусь в филиале Бауманки на «Биотехнических системах» (12.03.04)
В свободное время сам ковыряю занимаюсь английским и пытаюсь подружиться с контроллерами, но есть вопрос: а не фигней ли я страдаю?
Инженеры, расскажите: В этой стране реально заниматься разработкой протезов, если ты не в Москве или Томске? Или мой потолок без перевода в топовый вуз — это обслуживание аппаратуры в местной больнице? И что сейчас важнее «ботать» первокурснику, чтобы через 3 года не остаться за бортом: схемотехнику, 3D-моделирование или сразу забивать на железо и уходить в чистый код?
Если тут есть кто из Моторики или подобных контор — дайте знак, к чему готовиться. Хочется делать вещи, а не просто диплом получить
Вторая часть работы по моей разработке отказоустойчивых ПЛК.
Кто читает впервые:
Я, автор , независимый исследователь ( тот который не работает за счет фондов, институтов и организаций), разработчик 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 три инструкции который вкладывается в формулу :
|∆P C| ≤ l/N
смотри рисунок, одно ядро окажется на инструкции iD а второе на инструкции iE . Пропуск будет детектирован и ошибка наблюдаема.
В моем методе есть недостатки, вставка NOP - увеличивает память, и в моем компиляторе есть возможность выбирать критические участки кода где это используется:
Разная плотность NOP - разная детекция пропуска иснтрукций.
То есть, мы можем перемешать адреса функций и блоков, и получить детекцию целого класса ошибок ( от бага компилятора, до кривой программы и и физических помех которые изменяют ход программы - при переходах между функциями и в стеках).
Но так же усиливаем бдительность в критических участках кода , переводя систему в безопасный режим, даже если будет пропущена 1 инструкция (ПИД регуляторы и другие какие то системы).
Наш интерфейс. Тяжелые функциональные блоки, в тестах мы выставляли режим Detection of Small-Magnitude Program Counter Faults.
И, что важно, никаких грубых методов типа WDT ( таймера) или выдернуть шнур питания на 10 секунд и перезагрузить. Решается вопрос сбоя программы тонко, а его детекция - быстро , в течении - наносекунд при первом же расхождении программной трассы.
В данный момент, я тестировал эти повреждения указателя программного счетчика - изменяя его программно. Система тестировалась на FPGA и исправно фиксировала каждый пропуск. На микроконтроллере это не имеет смысла так как программный счетчик - виртуальный, а этот метод может работать только в многоядерных системах или FPGA.
Тестируемые.
В следующий раз, когда вернусь к вопросу отказоустойчивости - проведем уже эксперимент с физическим воздействием.
Задавайте вопросы в комментариях и на почту zoshytlogic@gmail.com.
Придумываем, рисуем и запускаем в моей SCADA Gatherlog - какой то тестовый сценарий.
Прошло три месяца с последних постов о ходе разработки, с того времени все кардинально изменилось в плане архитектуры. Это время я занимался - наукой, и определил направление работы дальше.
Сейчас перешел к общению с исследователями и научными руководителями. Пишу собственную научную работу по отказоустойчивым системам, но сам я - независимый исследователь, так как не работаю за счет фондов, институтов или организаций.
Кто читает впервые:
Я, автор , независимый исследователь, разработчик 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.
Интерфейс. Тяжелые функциональные блоки внутри LD прекрасно подходят под тесты отказоустойчивости
Несколько выполняющихся копий, на одном дешевом микроконтроллере, от чего может защитить? Против тяжелого поражения питания, это - не защитит(вопрос к аппаратной части), но стать устойчивее к программным ошибкам, радиации или умеренным временным электромагнитным помехам, сильно компенсируя аппаратную часть - получится.
Настройка компиляции в 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++ не важно, состоит из блоков кода и функций. Мой компилятор их и перемешивает по разным адресам и разным знакам (+-) направлениям перехода. Если мы скомпилируем программу, то получим пространственные -разные версии одной программы:
N компиляций, и расположение программы в памяти. Один и тот же блок или функция - по разным адресам.
Если мы присмотримся к адресам функций на скрине, то увидим в одной копии например Main будет по адресу - 0 (ноль) в другой копии она же будет по адресу - 144. Так и со всеми остальными. Выполняется главный принцип DME - усиление ошибки программы через структурную декорреляцию адресного пространства.
На рисунке видно, несмотря на то что участки кода перемешаны (перемешаны на уровне функций и блоков кода имеется ввиду), и соответственно скомпилированы - траектория программы, логика будет идентичная (в штатном режиме работы).
Теперь, предположим в системе произошел коррелированый сбой, то есть такой который задевает все ядра или все копии программы. Чаще это возможно когда программа криво написана, затерла адрес возврата, или другого участка программы. Проблемы с питанием - тоже может повредить все ядра одинаково. Радиация, или помехи - риск минимален в атмосфере на Земле. В самолете на высоте 10 000м вероятность сильно возрастает, а в космических аппаратах бомбардировка процессоров частицами которые вызывают сбои происходит несколько десятков раз в сутки.
Давайте предположим, что сбой произошел (неважно по какой причине) , адрес возврата или какого либо перехода ветки , установлен в случайное значение 148:
Просмотр результата компиляции в 3o|||sheet. Одна программа - разные адреса ее компонентов.
Был бы это обычный отказоустойчивый ПЛК типа Lockset или TMR за 5000$ , они бы не заметили фатальной ошибки, так как бинарники одинаковы. Система бы увидела у всех копиях одинаковое значение и подумала что все хорошо.
Но наша система декоррелирована по адресам , это вызовет - Дивергенцию. Система фиксирует - две разные инструкции одновременно: CALL и SDPHY. Несовпадение. Компаратор вызовет программу X (типа обработчик ошибки) или осуществит переход в безопасное состояние.
Детекция - сразу, что очень важно, так как обычный ПЛК - слетит с концами и не успеет передать на каком месте авария. Либо вообще может слететь через какое то время долго притворяясь что все хорошо.
Ошибка может быть более сложной, напримеррадиация или электромагнитная помеха может не изменить весь адрес полностью, а только один бит (так называемый bit flip), тем самым добавив к адресу одинаковое - число. То есть, адреса продолжат быть разные, но смещенные на константу. Для этого мой компилятор и делает переходы с разными знаками между функциями и некоторые другие приемы для локальной асимметрии адресов..
Ошибка из за физических процессов: bit flip может привести к тому что в копиях, адрес изменится на константу. В методе DME это приведет к разным участкам кода, и ошибка будет детектированна.
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.
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 годов, и гораздо производительнее наверное чем вся электроника корабля летавшего на Луну.
Altera Cyclone |V EP4CE6E22C8, STM32F722, STM32G030C8
Скорость выполнения базовых логических операций в микросекундах:
Mitsubishi (китайский клон) STM32F103------------------------------------2.7---------------математика int 8.6
Allen Bradley Micro 810 -----------------------------------------------------------------2.5---------------математика int 8.5
Наш ПЛК, название не придумал , пишу с названия среды моей разработки 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
