
Комментарии 11
Интересное зоо shit)))
Не только с Хабра попадают на Пикабу, но и наоборот :)
готовый плк видимо будет иметь рабочее название shufliadka
че то как то чудесато. с первого взгляда это впечатляет, хотя бы потому что большой объем работы. но при ближайшем рассмотрении вызывает больше недоумения.
Первая версия моего компилятора давала сбой - то одно не верно посчитает, то другое.
И вместо того чтобы отлаживать компилятор начинаем бороться с последствиями генетическими методами. Понятно дело что выловить все очень не просто, и даже у солидных производителей встречается неадекватное поведение программы, но как бы с этим борються, всякие тесты и верификации делают. и сертификации, чтобы неповадно косячить было. тратиться много ресурсов (человеческих и временных). Но за это и платим. "Типовой" пользователь ПЛК хочет получить черный ящик который будет хорошо исполнять его код.
единый виртуальный ассемблер (собственный синтаксис и инструкции, см. прошлые посты) который выполняется внутри на голом железе Микроконтроллера, FPGA или любого CPU
всегда хотел что то эдакое, с одной стороны это шикарно. если работает. четко. на FPGA можно реализовать любой микро/макрокод. На "любом CPU" вероятно нужен еще и рантайм для исполнения такого байт кода? В любом случае это требует массу отладки. И доказательного доказания надежности еще и рантайма/софт процессора.
Lockstep и TMR - уязвимы к коррелированным сбоям.
ну так потому что это рассчитано не глючные компиляторы, а но шальные заряженные частицы и ЭМИ вражеского происхождения. микроконтроллеры Мультиклет реализовываеют эту фишку аппаратно, вроде даже 4 и более ядра одновременно... я думал они закрылись, но нет.. а в 24 завод мечтали строить. ПЛК могли бы быть прикольные на них, но наверное дорого.
В общем, полагаю что старым (уж во всех смыслах) программистам на языках МЭК не стоит рассказывать что некий ПЛК работает недетерминировано, это их явно не порадует. Это даже в генерации картинок не всегда дает хороший эффект :)
С точки зрения трудозатрат на это все тоже непонятно, возможно отладить просто компилятор для рантайма будет попроще чем этот вот все. И куча рабочих образцов для сравнения. И вообще тогда, зачем еще один компилятор... open plc (beremiz) годами уже пилят и похоже допилили до более менее рабочего состояния.
Эта работа, по отказоустойчивости, она не привязана конкретно к меоему ПЛК, но моя экосистема, скажем так, позволяет все это тестировать (перемешивать адреса функциям, переменным, указателям и т.д). Я не представляю как это реализовать обычным компилятором. Если он (GCC например) расскладывает в памяти так как код обьявлен в тексте - тогда годится, можно использовать и GCC , но в ручную меняя обьявления местами (чисто для эксперимента , чтоб смотреть в ассемблере потом что и как).
Но кроме перемешивания адресов, в моей работе есть еще слом локальной ассиметрии, который тут в статье не описан, но который позволяет наблюдать ошибки сбоя указателя инструкций внутри функций и блоков, тут конечно GCC сделать подобное сможет, но сам процессор это не выполнит, так как нужна уже аппаратная реализация (ее я тестировал на FPGA).
В общем, мой метод это целая архитектура, она протестирована механически. Например что будет если повредить адрес возврата или указатель, переменную, или внезапно - счетчик команд. То есть самые популярные программные ошибки. И эти ошибки - ловятся из за адресной декорреляции (ни один другой метод насколько знаю это не ловят).
Что касается радиации, то мой метод вполне логично ловит ошибки и стандартные, когда повреждены биты памяти только одного потока/ядра, то есть, есть все преимущества от стандартного дублирования.
Beremiz, это насколько знаю просто транслятор в СИ. В Моей среде вертится полноценный рантайм позволяющий менять программу на лету, а диспетчер задач позволяет устанавливать дополнительные приложения/задачи на лету без перепрошивки, как в обыных ОС просто записав байты переданные по UART и записав в массив указатель на новую задачу, с следующего цикла на одну задачу работать будет больше.
А методов отказоустойчивости в Beremiz (и большинства ПЛК) нет никаких.
Да и вообще я сомнительно смотрю на "возраст" той или другой компании, разработчика, и открытых проектов ПЛК - все они исправляют баги которые сами и создали своей архитектурой. Так что я б не расчитывал на 10 лет шлифования какой либо архитектуры, это ниочем не говорит, в отличии от компиляторов который один на всех и все его совершенствуют. Но и в компиляторов есть проблемы.
Я так же смотрю свежие списки багов современных компиляторов , и там есть много таких, которые мой метод - детектирует (например свежий " if(false)" ) так как в архитектуре разработанной мной, баг компилятора, приравнен к багу программмы, с точки зрения математики (в следующих статьях поделюсь как это выглядит). Потому что улиткам в теплицах всеровно из за чего слетит ПЛК , из за компилятора или программы пользователя, и им жарко станет или сухо. Главно - не допустить плохого настроения улиток,ловить и обрабатывать все ошибки.
В общем с одной статьи тут многое чего не понять, кроме общей концепции.
Немножечко путаница у меня в компиляторах иже с ними образовалась, но не суть. Мне непонятно почему одна и таже программа на одних и тех же условиях, без внешнего (физического) воздействия, может вести себя по разному, при каждом, скажем, запуске:
Первая версия моего компилятора давала сбой - то одно не верно посчитает, то другое. Я столкнулся "паразитными" смещениями по адресам, а точнее - в сложных местах программа могла не туда перейти, не то прочитать или не туда записать.
Как отдельный момент, непонятно, а какой результат тогда будет считаться "истинным". Если представить себе решение типа очень навороченного теста (суть которого получение заведомо известного результата на основе заведомо корректной обработки заведомо известных данных), то будет натурально гипервизор, сторож над сторожем.
И если уж таковое происходит, то выявленные ошибки надо исправлять (тут кстати можно удумать еще и автоматическое исправление на уровне патчинга байткода, но не на уровне же "железной" прошивки во флеше/fpga), а если поправки не заносить в исходники то быстро дойдет до известной ситуации "никто не знает как оно работает"
Я пока вижу подобные сбои скорее как результат внешнего воздействия, по сути аппаратные, а не софтовые , т.е. сменой софта их не поправить, но можно учесть это явление и принять меры чтобы это не влияло.
Первая версия моего компилятора давала сбой - то одно не верно посчитает, то другое. " например, в одной реплике переменные записаны так: F A B C E, в другой наоборот B C A E F - представьте, что компилятор ошибся, не верно посчитав адрес, (новый компилятор, неопытный разработчик я). Кода переменные - сложные структуры ( как матрешки, внутри которых другие структуры, внутри которых еще структуры и т.д) криво написан механизм просчета смещений, может приплюсовать или отминусовать от истинного адреса, например 1. Мы хотели прочитать или записать переменную A, но компилятор ошибся с адресом, и что то приплюсовал к адресу A + 1 Первая копия прочитает B а вторая E , компаратор во время выполнения сразу заметит что в одном и том же месте LDR R1 B != LDR R1 E. Они прочитают разные места. То же самое с указателями, ошибка программы приведет к одинаковым значениям указателям, то есть указатель будет указывать на одно и то же адресное место двух копий, и соответственно в разные логические места : в одном случае там может быть совершенно другая переменная, в другом пустое место - возникнет расхождение, которое будет - наблюдаемо. Это экспериментально проверено. Но у меня в FPGA компаратор сразу проверяет адреса (до чтения или записи)- если они одинаковы - это сразу вызовет ошибку, так как в моей дивергентной системы не могут быть одинаковые адреса ни кода ни переменных. Даже если программа прыгнет в пустое место или попытается прочитать ложное место данных (например где в двух копиях будет одинаковое FFFFFF) - сработает "адресный коллапс" , это должно приводить к исключению ( в моем случае на FPGA есть компаратор который следит не совпали ли адреса). Чтение периферии (которая может быть по одному адресу) достигается другими методами.
В общем, можно сказать что это - теория, но экспериментально испытана и подтверждена. Чтоб в полной мере это работало - нужен специальный CPU переделанный существующий lockstep.
будет такой CPU создан, или нет - другое дело, для научного звания и научной работы - достаточно созданных прототипов на FPGA и микроконтроллерах с математическим документальным описанием идеи.
т.е . изначально сразу речь шла именно про реплики, одновременное исполнение кода в нескольких экземплярах и вот этого вот всего? поскольку все это дуплицирование и было основной задачей. а я то понял что единичная прогона глючила на разных прогонах.
получается конечно лютая защита от криворуких программистов на всех уровнях, но кто же усторожит сторожей :)
Хотите отказоустойчивость, ваш выбор H система от сименса :)
Как я разрабатывал отказоустойчивый промышленный контроллер. Ч1