Горячее резервирование Arduino
- Войдите на сайт для отправки комментариев
Пнд, 21/03/2016 - 19:49
Здравствуйте,
Подскажите, есть ли у кого нибудь готовые проекты реализации горячего резервирования для микроконтроллеров ATmega
Или посоветуйте, в какую сторону копать и имеется ли вообще возможность это реализовать?
Атмега тут не является чем-то особенным, а сама тема резерования управляющих контроллеров давно существует в рамках АСУ/АСУТП.
Если вы знаете, где можно найти информацию о том, как организовать резервирование контроллера, поделитесь пожалуйста. Ничего внятного найти не могу
Канечно гарячее! Паяльник держим горячим, спалили очередное тело от криворукости, быстро, пока не остыло перепаиваем.
Вячеслав21, настоящее резервирование, как в промышленных контроллерах, весьма сложная штука. О принципах статьи можно найти, а о конкретных реализациях - вряд ли. Успешные производители не делятся своими результатами из-за их дороговизны, а менее успешные не делятся, чтобы не открылась кривизна решений.
Резервирование ни каким образом не относится к теории ау, к которой я имею самое прямое отношение. Вопросы резервирования затронуты в теории нажедности, но не рассмотрены технические средства реализации.
Я кажется начинаю понимать, что задача, которую вы решаете, называется "Как сдать курсовик вовремя". Если так, то с этим лучше сразу проследовать в тему "Ищу исполнителя". Ардуиино -- платформа любительская, где вопросами резервирования интересуются редко и мало, чтобы искать здесь различные работающие примеры такого рода.
То есть ,возможность организовать хоть сколько нибудь надежный и не дорогой конечный продукт не интересна как таковая? Вы сильно зациклены на причине, почему меня это интересует, а тут принято излагать свои мысли, как это реализовать. В любом случае спасибо.
что вы подразумеваете под "горячим резервированием"? Замену платы с МК без снятия питания со схемы, или параллельную работу двух МК?
Параллельную работу двух МК
Параллельную работу двух МК
а смысл??? При грамотом проектировании устройства надежность работы МК сопоставима с надежностью переферии, очень часто намного выше источников питания
резервировать сам МК лишено какой либо практической логики. Для критичных приожений во первых надо забыть об ардуино, во вторых выбирать индустриальные компоненты, в третьих быть профи которому не надо искать ответы на любительских форумах.....в пятидесятых резервировать придется целые модули
То есть ,возможность организовать хоть сколько нибудь надежный и не дорогой конечный продукт не интересна как таковая? Вы сильно зациклены на причине, почему меня это интересует, а тут принято излагать свои мысли, как это реализовать. В любом случае спасибо.
МК с хорошо написанной и отлаженой программой это не виндовс - работать будет бесконечно.
А теория, собственно, в двух словах такая: два идентичных устройства по входам включены параллельно, выходы выбирает некий автомат, проверяющий состояние устройств любым возможным способом, например пинг. Делать управляющим автоматом одно из устройст можно, если есть 100% уверенность в надёжности кода, например, если это плис неповисающая. Ну, и не забыть про обрабутку переключения туда обратно с учётом синхронизации накопленных данных.
Адля АВРки вполне достаточно сторожевого таймера и платы в ЗИП. :)
можно ли это назвать резервированием? Допустим, они подключены параллельно, один МК накрылся/завис, в реультате на пине 9 имеем GND, другой МК продолжает работать, на этом же 9-м пине имеем +5В, получаем КЗ и второй МК присоединяется к первому.
можно ли это назвать резервированием? Допустим, они подключены параллельно, один МК накрылся/завис, в реультате на пине 9 имеем GND, другой МК продолжает работать, на этом же 9-м пине имеем +5В, получаем КЗ и второй МК присоединяется к первому.
По входам параллельно, а выходы выбирает и коммутирует автомат резервирования. И под словами "по входам параллельно" совершенно очевидно кроется некоторая развязка тоже.
Почему же не интересна? Очень интересна. Только почему вы решили, что именно горячее резервирование обещает здесь невиданный доселе прорыв? Это уж не говоря о том, что резервирование, само по себе, как-то подозрительно выглядит рядом с определением "не дорогой". По сути, вы предлагаете увеличение стоимости того самого "конечного продукта" от двух раз и выше, причем, сразу, а вот с надежностью получается какой-то туман в отдаленной перспективе. Попахивает законами Мерфи с небезызвестным "Система обеспечения надежности выйдет из строя первой, разрушив все остальные системы". Не выглядит ваша "возможность" ни интересной, ни сколь-нибудь востребованной. Мне, во всяком случае
Не выглядит ваша "возможность" ни интересной, ни сколь-нибудь востребованной. Мне, во всяком случае
соглашусь. Это очень похоже на попытку приделать к легковому автомобилю 8 колес. Зачем? Ну как же....
Мне доводилось делать подобное резервирование промышленных контроллеров. Контроллеры были максимально изолированы друг от друга, вся периферия на коммуникационных портах. Контроллеры сами договаривались, кто будет активным. Некое устройство - арбитр переключало порты между контроллерами. Один порт использовался для синхронизации данных.
То есть ,возможность организовать хоть сколько нибудь надежный и не дорогой конечный продукт не интересна как таковая? Вы сильно зациклены на причине, почему меня это интересует, а тут принято излагать свои мысли, как это реализовать. В любом случае спасибо.
Вопросы надежности работы оборудования для промышленности и специальных применений отработаны до "не могу". Тысячи ученых котов десятки лет вылизывали этот... вопрос до ослепительного блеска... международных стандартов. Взять хотя бы
IEC 61131-6 Программируемые контроллеры Часть 6: Функциональная безопасность
А это с гулькин носовая часть из целой группы стандартов, посвященных данному вопросу. Вы просто взгляните, "приоткройте капот" - сколько там всего... На мой взгляд, серьезно обсуждать этот вопрос на форуме - не серьезно. :)
Из моей (и не только моей) практики для маленького и надежного устройства нужно взять высоконадежные комплектующие, сделать им термо- и электропрогоны, отобрать наилучшие по результатам оных, собрать по устойчивой технологии. Снова проверить и отобрать уже готовое изделие. Аналогично с ПО. Тогда изделие безо всякого резервирования выдерживает рикошет. А без этого... Если случайно толкнуть стол, на котором стояла работающая настольная версия устройства, то с результатми шедших там расчетов можно было распрощаться.
ИТОГО: Надежность с Ардуино - это чисто "на удачу". "Дуня" придумана, сделана и хороша совершенно для другого... :))
Здравствуйте,
Подскажите, есть ли у кого нибудь готовые проекты реализации горячего резервирования для микроконтроллеров ATmega
Вот чисто с т.з. русского языка "резерв" это то, что держится в запасе на "черный день", а "горячий резерв", т.е. запас готовый к мгновенному использованию.
Т.е. это совсем не то, что мажоритарное голосование и многократное дублирование.
В первом случае имеется элемент, который принимаает решение о переходе на резерв, человек или соотв. автомат, а во втором, решение принимается на уровне исполнительных устройств мгновенно.
На мой взгляд, серьезно обсуждать этот вопрос на форуме - не серьезно. :)
Точно. ТС просто глумится. Или неудачно выбрал форум для сбора инфы на курсовую.
ИТОГО: Надежность с Ардуино - это чисто "на удачу". "Дуня" придумана, сделана и хороша совершенно для другого... :))
Ну не преувеличивайте. Сама железяка МК, если она не китайский фейк и експлуатируется при нормальных температурах, напряжении и токах (не максимально допустимых, как некоторые любят!!) штука очень надежная, случаев чтоб работала, работала и при нормальных условиях сдохла я не помню. Надежность ПО - отдельная песня, резерв здесь не поможет.
И главное, критерий необходимости горячего резерва - отказ блока за время необходимое для замены этого блока наносит ущерб сильно превышающий затраты на организацию и поддержание гарячего резерва. Откройте раздел проекты и покажите где такое есть.
Для ардуино таких проектов нет, а если появляется намек на такое, типа АКПП сделать, то проект зарубается прежде всего по надежности ПО.
Для ардуино таких проектов нет, а если появляется намек на такое, типа АКПП сделать, то проект зарубается прежде всего по надежности ПО.
Можно подумать, фирменное закрытое проприетарное ПО в этом плане лучше. В ходе расследования проишествий с автомобилями Тойота Камри в США, было установлено, что исходные коды софта для бортового компьютера содержат десять тысяч глобальных переменных. Да ардуиновские скетчи, по сравнению с этим, -- укрепленный железобетонный бункер, расчитанный на прямое попадание ядерной боеголовки.
Можно подумать, фирменное закрытое проприетарное ПО в этом плане лучше.
Лучше и намного, т.к. Вы забыли его одно важное свойство. Фирменное ПО тестировано. И не автором на коленке. Тут нужен коллектив, методика, стенды и статистика.
Вам я так понимаю не нравится факт наличия именно глобальных переменных в тоетовском ПО? Та ради бога, на МК глобальные переменные очень невеликое зло. Наоборот существует практика избегать динамическое распределение памяти, как раз для повышения надежности софта. А где же тогда буфера делать, как не глобально. Специфика не ПК.
ПС. Как раз долбусь с динамическим выделением памяти для Maple. Похоже там бажища. Если буфер глобальный - все работает, а вместо него динамически столько же выделяю - выделяется нормально, но в какойто момент при записи крах. Вот Вам и бункер. А ведь это базовый функционал. Он жеж такого напороть может...
Лучше и намного, т.к. Вы забыли его одно важное свойство. Фирменное ПО тестировано. И не автором на коленке. Тут нужен коллектив, методика, стенды и статистика.
Вы как-то упускаете из виду, что популярный код для ардуины может быть протестирован в объемах, которые в самых радужных снах не снились никаким коллективам помноженным на методики. Сколько того методического тестирования, если длится оно лишь в пределах сроков вывода на рынок новой модели, а сроки эти весьма жесткие?
Мое мнение тут вообще роли не играет. На хабре было довольно обширное обсуждение этого "феномена", но я не припомню ни одного отзыва, смысл которого бы звучал, что страшного в этом ничего нет. Это даже не дурной тон. Это катастрофа. Отследить правильность использования десяти тысяч переменных не по зубам даже оравам программистов, месяцами скачущих верхом на стендах.
Особенно, когда стоит задача представить дело так, будто земля имеет форму чемодана. Есть правила хорошего тона, есть методики сокращения числа грубых ошибок при написании кода. А еще есть десять тысяч глобальных переменных, которые отправляют первое и второе к чертям собачьим.
Можно подумать, фирменное закрытое проприетарное ПО в этом плане лучше. В ходе расследования проишествий с автомобилями Тойота Камри в США, было установлено, что исходные коды софта для бортового компьютера содержат десять тысяч глобальных переменных. Да ардуиновские скетчи, по сравнению с этим, -- укрепленный железобетонный бункер, расчитанный на прямое попадание ядерной боеголовки.
Либо фантазия у программеров хорошая, либо оно написано различными генераторами типа как раз скетчей самой дуни, ну, или каждую строчку писал отдельный чел из большого коллектива. :)))
Кстати, фирменное ПО пишут тоже люди и они далеко не всегда спецы и увлечённые люди. Не редко выпускники... Тем более, современный программисты, делающие быстро в два клика всё подряд, заюзав библиотеки, глюкавое, но думать при создании надо мало. Этот подход и у дуни. :)))
Ну не преувеличивайте. Сама железяка МК, если она не китайский фейк и експлуатируется при нормальных температурах, напряжении и токах (не максимально допустимых, как некоторые любят!!) штука очень надежная, случаев чтоб работала, работала и при нормальных условиях сдохла я не помню.
Так ведь Ардуино это не голый атмеловский МК, а аппаратно-программная платформа. И даже в чисто аппаратной части там другие деталюшки есть "критическим образом влияющие на функционирование устройства". Даже чтобы платка в тепличных условиях работала длительное время, её частенько приходиться предварительно заново пропаять. Да что далеко ходить http://arduino.ru/forum/apparatnye-voprosy/nano-3-effekt-raznoi-zemli#co... И сам я и пропаивал, и от флюса китайского отмывал, прежде чем включить надолго. Если хочешь на даче на зиму оставить, паяйся к дорожкам, минюя разъёмы. Можно разными рукоприкладными способами добиться длительного функционирования конкретного экземпляра в кокретных условиях, но говорить в целом о надежности платформы... Для учебных целей в домашних условиях надежность Ардуино вполне достаточна. :)) А по другим характеристикам для этой задачи Ардуино существенно удобнее других, аппаратно более надежных средств. :))
Чего вы расшумелись? :) ТС, похоже, слился.....
Чего вы расшумелись? :) ТС, похоже, слился.....
Да мы шумим культурно, по-тихому, зрителям на попкорне экономим. :)) А ТС, похоже, пошел добывать курсовик классическими методами - из архива ранее зачтенных. Так надежность выше. :))
Лучше и намного, т.к. Вы забыли его одно важное свойство. Фирменное ПО тестировано. И не автором на коленке. Тут нужен коллектив, методика, стенды и статистика.
Вы как-то упускаете из виду, что популярный код для ардуины может быть протестирован в объемах, которые в самых радужных снах не снились никаким коллективам помноженным на методики.
В рассуждениях о надежности слова "может быть протестирован" вобще не пременимы. Это как автомобиль на выходе с конвеера может быть с колесами. Тестирование - это часть процесса разработки. Обычная судьба ардуиновского приложения - использует автор и те кому автор отдал или продал. Даже если оно выложено в инет, то повторят его еденицы и если оно заглючит совсем не факт что будет отзыв, стопудово не будет нормального описания ошибки а уж исправления и подавно. Скорей повторивший тихо продолжит поиск чего работающего дальше.
Воще о чем реч?! Я или Вы написали приложение, надо использовать. Что будем публиковать и ждать пусть кто протестит? А код достаточно популярный? Это бред.
Профессиональный подход предполагает, что софт перед выдачей тестируется, и тестируется всегда. В нормальных фирмах так по факту. В шарагах - нет. Это одно из различий этих форм. Причем тестируется на наборах тестов, значительной степени автоматизации. При этом обязательно тестируется не разработчиком. Я удивлен, что приходится это пояснять. Я понимаю что у каждого свой опыт, и возможно Вам это неизвестно, но лично я такие системы управления качеством видел, по ним работал. Поверьте наслово, Самсунг заказчику без тестирования ПО не выдаст, если только это не оговорено отдельно. Разумеется работал и без всего этого ;) Ни один домашний софт такого обема тестирования отродясь не видит. Для справки - затраты на тестирование нормируют от 25 до 50% от общего времени разработки. Иногда и выше, но не ниже.
[/quote]
Сколько того методического тестирования, если длится оно лишь в пределах сроков вывода на рынок новой модели, а сроки эти весьма жесткие?
Софт очень редко пишется с нуля (не про ардуину ясно сказано). И после выпуска, дорабатывается, исправляется, тестируется обновляется. Это естественный процес, в первых версиях багов больше. Но даже в этом виде оно стабильней аналогичного по сложности ардуиновского. Посмотрите на версии ПО Вашего броузера, ОС, ИДЕ. В софтверном бизнесе знакомый вариант: написал, продал, забыл - удел кустарей-надомщиков, да и то не всегда.
Мое мнение тут вообще роли не играет. На хабре было довольно обширное обсуждение этого "феномена", но я не припомню ни одного отзыва, смысл которого бы звучал, что страшного в этом ничего нет. Это даже не дурной тон. Это катастрофа. Отследить правильность использования десяти тысяч переменных не по зубам даже оравам программистов, месяцами скачущих верхом на стендах.
Тестированием занимаются не "оравам программистов, месяцами скачущих верхом на стендах." Тестируют в основном тестировщики. Вы вобще знакомы с текущим состоянием дел в плане организации процесса разработок в софтверных компаниях или так рассуждаете?
Особенно, когда стоит задача представить дело так, будто земля имеет форму чемодана. Есть правила хорошего тона, есть методики сокращения числа грубых ошибок при написании кода. А еще есть десять тысяч глобальных переменных, которые отправляют первое и второе к чертям собачьим.
Правила хорошего тона - не догмы. Их соблюдение или нарушение в конкретном случае решает разработчик. К тому же сформулированы они в среде ПК и на неё же распостраняются. В МК немного подругому, попробую Вам пояснить кратко на примере проектирования распределения памяти под несколько довольно крупных обектов. Собственно есть 3 варианта: глобально, локально (на стеке) и куча. Понятно для ПК глобально мы исключаем по хорошему тону, не буду останавливатся подробно. Для МК на примере атмеги328 рассмотрим.
Стек, допустим все обекты влазят в стек вместе гарантирует ли это безглючность? Нет, так как стек активно используется ещё и прерываниями, и возможно при редком стечении (прерывание из глубины вызовов при всех обектах в стеке) и переполнение стека. Что будет на ПК? - ничего страшного, исключение обработает ОС и продолжит работу. Что будет на МК - очень редко выявляемый плавающий практически нерлокализуемый глюк. Чувствуете разницу? К стати как обеспечить взаимодействие обработчика прерываний с основной программой без глобальных? В ПК такой проблемы нет со времен ДОС.
Куча. Что такое фрагментация писать не буду, думаю знаете. Что делать если распределение памяти не выполнилось на МК? На ПК опять жепочти нет проблемы со времен ДОС. Боротся с фрагментацией можна, распределить сразу (указатели таки глобально хранить ) все и не трогать (в чем отличие от глобльного - не вижу) или жестко следить за порядком распределения и освобождения, только это сложней чем контролировать глобальные обекты.
Вот и выходит что на МК глобальные - не такое уж зло. Специфика повторяю своя. А Вы её не видете, но тут Вам не джава! Остается правда проблема возможности переполнения стека при прерывании из дальнего угла, т.к. память мы "отели" всеравно в том же обеме. Но она теперь будет возникать стабильней, т.к. при прочих равных устранен вероятностностный фактор необходимости распределения всех обектов сразу. А значить проверка свободного места для стека выявит проблему. Ну и тестирование тоже обнаружит.
Для некоторых случаев - вобще свои нюансы, например почему правильней сохранить millis() в глобальную в начале лупа и затем брать её везде где надо вместо вызова. Недавно расписывал на форуме.
А то, что Serial глобальная Вас не смущает, удобно вызвать откуда угодно, локальной можете себе представить? Очевидно есть её отличие от компорта на ПК.
Мало того, есть МК у которых стека нет или пошти нет, как там быть с локальными? И ОЗУ пару десятков байт, кучи тоже нет, что делать. А есть DSP где каждый тик на счету и через стек или кучу там просто безсмысленно. Куда там правила хорошего тона сунуть?
ПС. Готов дальше подискутировать на тему, но только предметно, аргументы гдето когдато на хабре шото сказал - простите несерезно, там щас школоты пишущей свою ОС выше крыши, мне это не интересно. И общие соображения мне не интересны тоже, я их четверть века как знаю, и других учил, только вот они потому и правила тона а не законы, что не везде работают.
Вы написали гору текста, не содержащего никакой конкретики. Где-то там, что-то там, как-то там делается. Все основано на ваших представлениях, как оно должно быть. Мне это не интересно.
себе шо ли какую-нибудь хуйню написать сюда - кратко, но без конкретики.
Вы написали гору текста, не содержащего никакой конкретики. Где-то там, что-то там, как-то там делается. Все основано на ваших представлениях, как оно должно быть. Мне это не интересно.
Хее.. очередной слился. успехов.
ПС. если уж у меня конкретики нет - Вы её ни где не найдете.
Logik - Вы, уж простите, отъявленный демагог.
Атмел - обычный промыщленный контроллер. Мини или Дигиспарк - вообще ничего не содержит, даже разъемов пиновых, которые Вы, немного выше, критиковали, только пайка. Так что - Ардуино - это возможность, зависящая от програмиста, сделать как дерьмо, так и нормальный экземпляр промавтоматики.
---- ----------------------------
Теперь по томе ТС.
Которко о себе - мне 46 и я большую часть жизни занимался проектированием и строительством сетей связи. И интернет и телефония.
90% проектировщиков до сих пор мой расчет провиса воздушек пихают в проекты без редактирования ;) (потому, что он экспертизу проходит - ;)).
Так вот в нашей среде было полно таких как Вы - "старообрадцев", которые на всех форумах, на той же "электросвязи", постоянно писали, что наш езернет и IP - это детский лепет и любительство, а "настоящие!" сети - это SDH (слава Б..гу не ТЧ каналы), ну в крайнем случае ATM, и где наш IP будет тогда, когда потребуется телеметрия, критичная к реплаю и прочее и прочее.
Простите, если задену, но и где теперь эти мудаки? Где SDH и ATM? Где новые решение в синхре? Все таки решилось на "любительском" езере и IP! Причем минимальной косметикой протоколов.
Так и с промавтоматикой. Ардуинка - пример популяризации МК, как IP - популяризация сетей. 10 лет назад - PIC был "золотым стандартом" и тоже благодаря открытой экосистеме разработки. Атмел и Ардуинка - перекрыла PIC, как бык овцу. Кстати, "Малина" интересная тема, если нужна вычислительная мощьность и много GPIO.
И именно тут будет развитие. Если Вы немного понимаете в теме, заданной ТопикСтартером, то на "Малине" написать горячее резервирование - плевое дело, так как там уже есть нормальная ОС (ОперационнаСистема), а на Linuxe уже есть решения по горячему резервированию. На маленьких Уно - может и не так просто будет - придется многим пожетртвовать, ради возможности синхронизации, но на Меге написать пакет для горячего резервирование - уже гораздо проще. Тем более, что есть уже несколько микроОС с нормальными планировщиками процессов, на которые можно операться при построении резервируемой схемы программирования, библиотек и классов для нее.
Logik - Вы, уж простите, отъявленный демагог.
Атмел - обычный промыщленный контроллер. Мини или Дигиспарк - вообще ничего не содержит, даже разъемов пиновых, которые Вы, немного выше, критиковали
Вы не демагог?! Отлично. Цитаточку где я, именно я, критиковал пины.
Так что - Ардуино - это возможность, зависящая от програмиста, сделать как дерьмо, так и нормальный экземпляр промавтоматики.
Угу. Цитирую себя. http://arduino.ru/forum/apparatnye-voprosy/goryachee-rezervirovanie-arduino#comment-180142
Сама железяка МК, если она не китайский фейк и експлуатируется при нормальных температурах, напряжении и токах (не максимально допустимых, как некоторые любят!!) штука очень надежная, случаев чтоб работала, работала и при нормальных условиях сдохла я не помню. Надежность ПО - отдельная песня, резерв здесь не поможет. "
Вы бы прежде чем бирки клеить, сразу тему бы почитали, а то как-то совсем некрасиво, два раза облажатся в одном абзаце.
Где эти мудаки теперь я честно не знаю, даже где они тогда были - не знаю. Вы связист - Вам видней. Но то, что IP ниразу, никогда любительским не был известно всем.
Смешались в кучу кони овцы.. Хотите холивар PIC/Атмел и еще "Малина"? Я нет. Мне все в них ясно, писал на все платформы. Сейчас предпочитаю Атмел хоть начинал с PIC. Почему так - точно не из за резервирования )))