IPB

Здравствуйте, гость ( Вход | Регистрация )

5 страниц V   1 2 3 > »   
Ответить в данную темуНачать новую тему
> Отказоустойчивое ПО для МК, Обсуждение правил и приемов при для повышения надежности устройств
tester
сообщение 15.8.2010, 23:43
Сообщение #1


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Приветствую участников!

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

Примерный набросок оглавления:
Код
1. Введение
    1. предпосылки                              (о чем статья и когда нужно применять написанное в ней)
    2. определения                              (классификация, определения надежности, отказоустойчивости)
    3. сложности                                (с чем сталкиваемся при обеспечении отказоустойчивости ПО)
    4. стандарты                                (два слова о ГОСТах на эту тему и их содержаниях)
2. Причины и последствия сбоев
    1. причины
        - инструментальные                      (транслятор, контроллер, библиотеки)
        - программные                           (сложное ПО может выходить на рынок "недотестированными")
        - эксплуатационные                      (монтаж, транспортировка, "кривые руки" и пр.)
        - внешние                               (EMC, питание, генерация, температура, вибрации и пр.)
        - экономические                         (где граница между стоимостью и целесообразностью)
        - срок службы                           (утечка заряда, старение деталей, износ контактов)
    2. последствия
        - частичный выход МК из строя           (сгорание портов, отдельных периферийных модулей)
        - порча программной мамяти              (при случайной записи, от времени, из-за помех во время записи)
        - потеря данных                         (сбой данных в EEPROM, сбой RealTimeClock и т.д.)
        - изменение состояния триггеров         (любой триггер при мощных помехах может изменить состояние)
        - порча компонентов                     (изменение структуры под действием температур, поломка
                                                 из-за вибраций и пр.)
3. Проектирование и кодирование
    1. алгоримы, графы состояний                (не делать тупиковых или циклических ветвей;
                                                 предусматривать "неизвестное состояние")
    2. повторное использование модулей          (разные платформы, компиляторы, частоты, напряжение,
                                                 используемые порты)
    3. периферия                                (соответствие стандартам, коллизии на шинах, "мусор" извне,
                                                 помехи)
    4. трапы                                    (начинать программу с описания трапов; что делать в трапах)
    5. прерывания                               (запрещать неиспользуемые; минимальное время обработки; вложенные
                                                 запреты; повисание в прерывании; счетчики событй и пр.)
    6. совместный доступ из параллельных процессов (атомарность, valatile, RTOS)
    7. сторонние библиотеки                     (вопрос надежности, оценка средств контроля чужого кода)
    8. RTOS                                     (сертифицированные, честные)
4. Тестирование и отладка
    1. верификация                              (соответсвие поведения программы требованиям)
    2. валидация                                (правильность поведения программы в реальных условиях)
    3. полные тесты                             (где применяются, зачем, что является результатом)
    4. неполные тесты                           (применяются там, где нельзя применить полные)
    5. доказательство                           (некоторые фрагменты, которые нельзя полностью протестировать,
                                                 можно доказать)
    6. тестирование на другой платформе         (тестирование узлов программы на PC или в симуляторе)
5. Контроль программы в работе
    1. включение питания и ресет                (проверка причин сброса, вспоминание предыдущего состояния)
    2. самодиагностика                          (ROM, RAM, регистры, периферия, стек)
    3. run-time контроль                        (проверка результатов функций, времени их выполнения, стек,
                                                 сигнатуры, входные данные, трапы, настройка периферии и пр.)
    4. WDT                                      (типы, порядок обработки, проблемы, интервалы, сторонние
                                                 библиотеки, RTOS)
    5. что делать при обнаружении сбоя          (адекватная степени ошибки реакция, скорость реакции,
                                                 незаконченные процессы, восстановление/сброс/безопасный режим)
6. Работа
    1. индикация состояния                      (инф. для оператора или управляющего оборудования)
    2. подсказки                                (зачастую могут предотвратить некорректные действия оператора)
    3. предупреждения                           (формултровка предупреждений, поведение во время предаварийной
                                                 ситуации)
    4. сообщения об ошибках                     (формулировка сообщений, поведение, документирование)
    5. протоколирование                         (журнал состояний, событий, действий с указанием времени и пр.)
    6. безопасный режим                         (зачем нужен, что в нем делаем, как его обеспечиваем, вход в
                                                 режим после сброса)
7. Bootloader - узкое место
    1. физическая блокировка основной программы     (получает управление первым)
    2. контроль соответствия загружаемой программы  (сигнатуры, размеры, соответствие шифрования, CRC)
    3. гарантия правильности                        (CRC, пересчитывание)
    4. имеет функции записи в программныю память    (механизмы блокировки от случайного попадания PC в
                                                     функцию записи)
    5. защита от пропадания питания                 (учесть, что ячейки могут оказаться недостретыми)
    6. проблемы при записи                          (помехи во время записи, "недозаряд" ячейки памяти)
8. Обработка данных
    1. контрольные суммы                            (методы подсчета, разрядность, вредные привычки)
    2. проверка достоверности                       (время 24ч:68м, вес человека -3 грамма и пр.)
    3. энергонезависимая память                     (типы, особенности, выбор памяти в зависимости от типа
                                                     хранимых данных, защита от сбоев)
9. Особо ответственные системы
    1. резервирование                           (хранение двух экземпляров одной и той же функции, CRC)
    2. n-версирование                           (перепроверка данных обратным вычислением или вычислением
                                                 по другим формулам)
    3. троирование                              (чем лучше дублирования, чем хуже четверирования; метод
                                                 обработки, проблемы контрольных сумм)
    4. самодиагностика                          (периодическая проверка; требует время)
    5. оповещение                               (оповещение)
Перейти в начало страницы
 
+Цитировать сообщение
novichok
сообщение 16.8.2010, 7:31
Сообщение #2


Активный участник
***

Группа: Пользователи
Сообщений: 40
Регистрация: 30.7.2010
Пользователь №: 189



Я напишу свои рецепты, это не истина в последней инстанции, а только мысли на тему "как бы сделал я".
1. В первых питание, в него упирается все, сказать что "схема сделана правильно" не сказать ничего. Отказоустойчивое ПО в своей отказоустойчивости опирается именно на питание. Поэтому надо прям отдельную главу или даже треть книжки посвятить построению питания для устройств с отказоустойчивым ПО. Что я имею ввиду.
Питание это не просто DCDC с хорошей фильтрацией. И не просто стабильное питание с красивой петлей ОС. Это впервую очередь полная отработка цикла "просадка по питанию => рестарт софта => возврат к работе". А если мы говорим о батарейном устройстве, то оно должно в автономном режиме восстановить работоспособность после разморозки аккумулятора и подаче общей сети, после того как произошло полное отключение из за аварии при минус 40, и через месяц полной заморозки, при подаче питания устройство оттаивает аккумуляторы, заряжает их и восстанавливает работоспособность в полном объеме. И поскольку химия аккумуляторов не имеет непосредственно, никакого отношения к отказоустойчивому ПО, в конечно счете именно неверная отработка таких ситуаций может угробить батареи и привести к краху системы в целом. Когда есть внешнее питание, но из за убитой батареи устройство не может выйти на связь.
Плюс куча ситуаций когда в устройство подается скачком выброс или просадка, разряды снаружи и много всяких интересных вещей, который способны поменять битики в RAM.
Все эти вопросы решаются совместно электрической схемой и алгоритмами отработки аварийных сбросов по питанию.
2. Собственно софт. Надежный софт тот, который написал сам. Отсюда правило простое. Берем RTOS и начинаем его жестко тестировать по модулям, не забывая просмотреть и проанализировать каждую строчку кода. Если считаете это дело утомительным, тогда это будет какой угодно софт, только не "отказоустойчивый".
3. Резервирование в масштабе устройства, то есть 10 устройств работают параллельно с одним и тем же софтом, а лучше с разным софтом, выполняя одну и ту же задачу, при взрыве 9 устройств, десятое таки выполняет то, что требуется. При нынешней миниатюризации это вполне по силам сделать, и стоить будет относительно недорого.

Все остальное считаю безнадежным флудом , типа "вектора тестирования, методики оптимизации и прочая лабудень". Отказоустойчивая система это софт плюс схемотехника плюс физика плюс здравый смысл.
И писать книжку про голый отказоустойчивый софт это тратить время на очередной опус "на тему".
Перейти в начало страницы
 
+Цитировать сообщение
stells
сообщение 16.8.2010, 8:27
Сообщение #3


внештатный сотрудник
***

Группа: Пользователи
Сообщений: 1568
Регистрация: 21.11.2009
Из: МО, Медвежьи озера
Пользователь №: 12



Цитата(novichok @ 16.8.2010, 9:31) *
эти вопросы решаются совместно электрической схемой и алгоритмами отработки аварийных сбросов по питанию

мало того, в старых совковых микропроцессорах серии 1801ВМ1(2,3) и их "боевой" версии 1806ВМ2 предусматривалась подача двух сигналов от супервизора питания - ACLO и DCLO (провал по переменке и по постоянке), что теоретически позволяло предпринять некоторые действия до полного пропадания питания.
так что вопрос комплексный
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 16.8.2010, 8:39
Сообщение #4





Гости






А меня вот пп. 3,4 очень даже интересуют.
Ну, я уже писал.
Особенно тестирование и верификация, поскольку у нас тестирование проводится только на техпрогоне перед отправкой пользователям и некоторые глубинные проблемы всплывают спустя годы успешной эксплуатации
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 16.8.2010, 11:39
Сообщение #5


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Цитата(novichok @ 16.8.2010, 9:31) *
Я напишу свои рецепты, это не истина в последней инстанции


1. Согласен с Вами насчет многозначимости качественного источника питания. Но его изготовление выходит за рамки данной темы. Кроме того, каким бы качественным он ни был, он может быть отключен от сети (или аккумулятор может быть вынут, или механическим воздействием разорвется связь между источником и схемой; при попадании влаги получим ток, который может прожечь предохранитель и т.д.). Моя задача - описать поведение программы в случае такого вида сбоя (как во время его возникновения, так и после восстановления питания). Тема с питанием включена в параграф: "2.1.4 Внешние причины". Перечень причин сбоев:
- питание (отключение питания)
- помехи на ресете
- помехи на сигнальных линиях
- срыв генерации
- механические воздействия
- запредельные температуры
- агрессивная среда
- радиация

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

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

Цитата
Все эти вопросы решаются совместно электрической схемой и алгоритмами отработки аварийных сбросов по питанию.

Об этом будет п. 5.1

2. Как-то все в одну кучу...
Цитата
Надежный софт тот, который написал сам.

По такому определению получается, что любая программа, написанная одним человеком, надежна? Я бы Вас перефразировал: "уверенность в надежности софта может появиться только тогда, когда его полностью написал сам". Но не факт, что она появится, т.к. написать можно было криво. И этой темы я конснусь в главе 2 (пп. 1..6). А еще хуже, когда она появится, а софт останется ненадежным. Классический пример - безусловный сброс WDT где ни попадя. Человек считает, что раз он сбрасывает WDT, то все, программа надежна и никогда не зависнет. Эта иллюзия может потом аукнуться.

Цитата
Берем RTOS и начинаем его жестко тестировать по модулям, не забывая просмотреть и проанализировать каждую строчку кода. Если считаете это дело утомительным, тогда это будет какой угодно софт, только не "отказоустойчивый".

Дело не в утомительности. Напиание отказоустойчивого софта - само по себе дело утомительное и дорогое. Но проанализировать код RTOS можно тогда, когда есть исходники (коммерческие RTOS поставляются без исходников). Это первое. Второе: для работы такого рода (анализ чужого кода) надо обладать квалификацией не ниже (а лучше намного выше), чем автор кода, иначе можно проглядеть то, что проглядел сам автор. То же самое касается сторонних библиотек. Этих вопросов я собирался коснуться в главе 2 (пп 7 и 8 ) .

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


Цитата
3. Резервирование в масштабе устройства

3. У меня речь пойдет не про аппаратное резервирование, а про программное.

Цитата
Все остальное считаю безнадежным флудом , типа "вектора тестирования, методики оптимизации и прочая лабудень".

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


Цитата
Отказоустойчивая система это софт плюс схемотехника плюс физика плюс здравый смысл. И писать книжку про голый отказоустойчивый софт это тратить время на очередной опус "на тему".

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

Цитата(stells @ 16.8.2010, 10:27) *
мало того, в старых совковых микропроцессорах серии 1801ВМ1(2,3) и их "боевой" версии 1806ВМ2 предусматривалась подача двух сигналов от супервизора питания - ACLO и DCLO (провал по переменке и по постоянке), что теоретически позволяло предпринять некоторые действия до полного пропадания питания.
так что вопрос комплексный

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

Цитата(MrYuran @ 16.8.2010, 10:39) *
А меня вот пп. 3,4 очень даже интересуют.
Ну, я уже писал.
Особенно тестирование и верификация, поскольку у нас тестирование проводится только на техпрогоне перед отправкой пользователям и некоторые глубинные проблемы всплывают спустя годы успешной эксплуатации


smile.gif Обратите внимание, что у нас с Вами противоположный взгляд на повторное использование модулей (у меня п. 3.2, у Вас п. 1.5). Я считаю это как раз понижением надежности, т.к. применяться могут не только разные платформы или разные компиляторы, но иногда достаточно той же платформу, работающей на другой частоте. Мы используем модуль, который считаем надежным, а он сбоит, и ошибку будем искать везде, только не в нем. Хороший пример, который получил огласку, - Arian 5. (Проблема была в повторном использовании модуля).
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 16.8.2010, 12:20
Сообщение #6


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



..Ну, такую книжку я бы приобрел.
Хотя, даже собаку не использую.. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 16.8.2010, 12:35
Сообщение #7





Гости






Цитата(Wise @ 16.8.2010, 14:20) *
Хотя, даже собаку не использую.. smile.gif

Это очень зря. Были случаи.
Без нормального вочдога-супервизора ни о какой надёжности речи не идёт.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 16.8.2010, 12:44
Сообщение #8


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



Внешний супервизор - да, всегда.
Этого достаточно, для проблем с питанием.
А чем поможет собака, если программа зациклится (тьфу-тьфу, не было ни разу..), но, сбрасывая собаку..
..Думаю, пока, что, в правильной программе для МК собака не актуальна. Хотя, возможность ея выпустить и натравить, пусть будет..
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 16.8.2010, 13:03
Сообщение #9


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Цитата(Wise @ 16.8.2010, 14:44) *
Внешний супервизор - да, всегда. Этого достаточно, для проблем с питанием.

Кстати, тоже не панацея. Известны случаи, когда только выключение питания выводило МК из глухого зависания. Да и потом, супервизор, хоть и полезен, вводит дополнительную энтропию: ресет может произойти раньше, чем контроллер успеет заметить падение напряжения.

Цитата
А чем поможет собака, если программа зациклится (тьфу-тьфу, не было ни разу..), но, сбрасывая собаку..
..Думаю, пока, что, в правильной программе для МК собака не актуальна. Хотя, возможность ея выпустить и натравить, пусть будет..

Собственно, Вы сами на свой вопрос и ответили. Т.е. "чем поможет собака, если программа зациклится, но сбрасывая собаку?" имеет такой ответ: "не допускайте сброса собаки в зациклившейся программе". Программа - это последовательность действий. Если она не выполняется (повисли в одном действии), значит, что-то не так и собаку сбрасывать нельзя.

К тому же есть разные виды WDT:простой (встроенный), оконный, внешний, комбинированный. Алгоритм обработки WDT - это не тривиальная задача, имеющая множество нюансов, один из которых, как ни печально: WDT - это набор триггеров, один из которых (в том числе и отвечающий за режим работы) может изменить состояние под действием внешних помех.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 16.8.2010, 13:13
Сообщение #10





Гости






Цитата(Wise @ 16.8.2010, 14:44) *
А чем поможет собака, если программа зациклится (тьфу-тьфу, не было ни разу..), но, сбрасывая собаку..

Вот для этого её надо в правильном месте выпускать. Например, в середине суперцикла.
По крайней мере, если не восстановится работоспособность, иногда бросается в глаза неадекватное поведение устройства из-за регулярных сбросов с периодом 200-800мс (зависит от), в отличие от тихого зависания, при котором может сохраняться частичная работоспособность (например, обмен по UART, особенно если всё реализовано на прерываниях, как пропагандирует Прохожий).
Мне хватило одного раза, когда полиэтиленовая банка с аммиаком вследствие нерегулируемого подогрева раздулась и приняла шарообразную форму. Слава богу, это были испытания, причём целенаправленные именно на этот дефект. Но программу я потом поправил, ибо взрыв литровой ёмкости с аммиаком в лаборатории - это ЧП. А потом и железо подправили, добавив "железный вочдог" по цепи силового питания

Цитата(tester @ 16.8.2010, 15:03) *
WDT - это набор триггеров, один из которых (в том числе и отвечающий за режим работы) может изменить состояние под действием внешних помех.

Было дело, накололись однажды. Теперь вход WDI внешнего вочдога подтягиваем к цепям питания.

Цитата(Wise @ 16.8.2010, 14:44) *
..Думаю, пока, что, в правильной программе для МК собака не актуальна. Хотя, возможность ея выпустить и натравить, пусть будет..

У вас ещё есть выбор - выпускать или нет. А нас по условиям сертификации принудительно заставляют ставить внешний.
Вочдог - это не защита от неправильной программы, а скорее от сбоев памяти. Питание дрогнуло, битик скакнул, и ваша программа потекла по неизведанному маршруту...
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 16.8.2010, 21:25
Сообщение #11


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(MrYuran @ 16.8.2010, 15:13) *
Вот для этого её надо в правильном месте выпускать. Например, в середине суперцикла.
По крайней мере, если не восстановится работоспособность, иногда бросается в глаза неадекватное поведение устройства из-за регулярных сбросов с периодом 200-800мс (зависит от), в отличие от тихого зависания, при котором может сохраняться частичная работоспособность (например, обмен по UART, особенно если всё реализовано на прерываниях, как пропагандирует Прохожий).

Такое может произойти не только при работе, построенной на прерываниях.
Но и при вытясняющей многозадачной ОС.
К примеру Винда. Куча задач на ходу, а одна висит.
Такое сплошь и рядом.
Или еще.
Даже в простой RTOS возможны нарушения в описателях задач.
По разным причинам, которые пока не рассматриваем.
И что будет?
В соседней ветке уважаемый tester написал, что в конечном счете, все упирается в человеческий фактор.
Но при работе, основанной исключительно на прерываниях, можно организовать процесс "хранитель".
Или два таких процесса, или даже три. Причем, у них будет наивысший приоритет и вполне возможно - другие векторы прерываний.
Выводы о работоспособности девайса в целом, такие процессы могут принимать на разных основаниях.
Сейчас я обдумываю подобные процессы с максимальным приоритетом и с мажоритарным принципом принятия решения.
Вполне вероятно, что это дело будет завязано на внешнюю службу времени.
Хочу заметить, что при моем (чисто условно, на самом деле все придумано до меня) подходе - решение будет программно-аппаратным.
А в случае, если это делать из-под RTOS - чисто программным, в конечном счете.
А это не есть гуд.
Вообще-то я не против РТОС. Но она должна "знать свое место".
Даже в моем "творчестве" получается следующее:
Нижний уровень, где творится всякое безобразие, описанное выше.
Верхний уровень в виде суперлупа, где обрабатываются медленные процессы.
Никто не мешает для них применить РТОС.
Просто в настоящий момент у меня нет потребности делать это в силу особенностей самих задач.
И ввиду отсутствия творческого коллектива.
Но, если такая потребность возникнет, или появятся соратники, то...
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 16.8.2010, 22:36
Сообщение #12


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Я вижу, пока обсуждается только WDT. Тогда начну с него. Вот предварительный план главы "5.4 WDT":

- предпосылки
- типы WDT
- алгоритм обработки
- выбор интервала
- поведение при сбросе
- зависание и преждевременный сброс WDT
- RC-генератор и температура
- работа со сторонними библиотеками
- работа под RTOS

В скором времени набросаю черновик по этой главе.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 16.8.2010, 23:12
Сообщение #13


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



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

Это еще один повод держать пса в будке. smile.gif
Скорей всего, мой опыт программирования МК слишком мал (всего-то лет 5), но, пока гром не грянул, буду держать собаку на привязи. Ленивы мы и не любопытны.
Я прагматичен в написании программ. Прерывания стараюсь обходить, а если ставлю, то, когда они логически уместны.
Например, некий сигнал заведен на компаратор, и срабатывание этого мудреного устройства ожидается не чаще раза в месяц. Тогда, мы обнажим данный орт прерывания. А вот конца работы АЦП я лучше подожду, зацикленно опрашивая флажок, нежели пойду по делам, ожидая, когда прерывание вышвырнет меня, в самый разгар моих скорбных занятий.. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 16.8.2010, 23:18
Сообщение #14


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Цитата(Wise @ 17.8.2010, 1:12) *
Это еще один повод держать пса в будке.
...
А вот конца работы АЦП я лучше подожду, зацикленно опрашивая флажок, нежели пойду по делам, ожидая, когда прерывание вышвырнет меня, в самый разгар моих скорбных занятий..

Хм... А АЦП - разве не набор триггеров? smile.gif Собъется его настройка - и повиснете в вечном ожидании.

Тут на помощь может прийти внешний WDT.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 16.8.2010, 23:24
Сообщение #15


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



Цитата
Хм... А АЦП - разве не набор триггеров? Собъется его настройка - и повиснете в вечном ожидании.

Хм.. А что не набор триггеров? регистры, разве..
WDT подобен страховому полису жизни, который стараются всучить при поездке на поезде..
Спора нет, вещь полезная..

..Можно сказать и по-другому.
Если, проектируя схему БП, например, я буду долго думать, что произойдет, когда откажет любой из чип-резисторов 0805, входящих в состав схемы..
то, вряд ли когда-нибудь эту схему спроектирую.
Вот, переполюсовка по входу, КЗ или превышение напряжения по выходу - дело совсем другое. Объективно, это реально опасные возможности. Но, даже и от них совсем не всегда мы делаем защиты.
То же и с программой. Страховать каждый бит - это надо очень быть опасливым.. и в какие же объемы программной памяти такая страховка уместится.. smile.gif

..Возможно, скрипка актуальности резервирования/страхования, как в целом, так и по разделам, должна пропиликать первой в оркестре вашей будущей книги. И эта мелодия не должна быть слишком умозрительной и академичной. Иначе, не будут покупать. Впрочем, один покупатель у вас уже есть.. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 16.8.2010, 23:34
Сообщение #16


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(Wise @ 17.8.2010, 1:12) *
Это еще один повод держать пса в будке. smile.gif

Сознаюсь в страшном грехе.
Я тоже не использую WDT.
Но на полном серьезе думаю, что это неправильно.
Но у меня пока нет концепции по этому поводу.
Тем более, ПМСМ, надо увязывать WDT, монитор питания, контроль частоты в единую систему, наблюдающую за МК.
Сюда бы еще наблюдатель за памятью...
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 17.8.2010, 7:44
Сообщение #17





Гости






Цитата(Прохожий @ 16.8.2010, 23:25) *
Такое может произойти не только при работе, построенной на прерываниях.
Но и при вытясняющей многозадачной ОС.
К примеру Винда. Куча задач на ходу, а одна висит.
Такое сплошь и рядом.
Или еще.
Даже в простой RTOS возможны нарушения в описателях задач.
По разным причинам, которые пока не рассматриваем.
И что будет?

В вытесняющих ОС можно в каждой задаче сбрасывать свой маленький флажок, а в центральном цикле сбрасывать вочдог только в том случае, если все флаги сброшены.
И после этого опять поднять флаги и всё сначала.
Кстати, мысль!
Хотя я в боевых проектах вытесняющие РТОС не использовал, но на будущее надо поиметь в виду.

Цитата(Прохожий @ 17.8.2010, 1:34) *
Сюда бы еще наблюдатель за памятью...

Вот...
У меня тоже грешок водится - при сохранении параметров во флеше не использую никаких защит, даже банальный ЦРЦ.
То есть, сбой во время записи - и полный Пэ. Калибровочные константы, параметры, режимы - всё что нажито...
Есть, конечно, команда восстановления заводских параметров, которые можно убить только вместе с прошивкой, но всё-таки это уже аварийное восстановление, которого можно было избежать.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 17.8.2010, 10:35
Сообщение #18


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Цитата(Wise)
Хм.. А что не набор триггеров? регистры, разве..
WDT подобен страховому полису жизни, который стараются всучить при поездке на поезде..
Спора нет, вещь полезная..


Да все не так страшно с порчей состояния триггера (есть и более страшные сбои, вроде эффекта защелкивания).
1. Во-первых, явление очень редкое (но не невозможное, даже в тепличных условиях)
2. Во-вторых, есть способы восстановления триггеров. С момента сбоя триггера до момента, когда это скажется на программе, может пройти какое-то время, и за это время можно восстановить работоспособность программы. В частности, я периодически перепроверяю настройки периферии и прерываний. Цитата отсюда: "не надейтесь что железо инициализированное при включении питания сохранит свое состояние через 10 лет круглосуточной работы"
3. В-третьих, насчет внутреннего WDT не уверен, но скорее всего он на кристалле выполнен более толстыми проводниками и более "жирными" транзисторами, отчего значительно меньше подвержен помехам, чем остальная память контроллера. (По крайнем мере, это точно относится к микросхемам внешних WDT)

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

(Кстати, сами регистры тоже предписано проверять при старте программы)

Цитата(Wise)
..Можно сказать и по-другому.
Если, проектируя схему БП, например, я буду долго думать, что произойдет, когда откажет любой из чип-резисторов 0805, входящих в состав схемы..
то, вряд ли когда-нибудь эту схему спроектирую.

А у меня на старой работе человек делал устройство (включая БП) по таким условиям: что будет, если откажет любой компонент в нем. Там были повышенные требования по искробезопасности, и он делал по ГОСТу (кажется номер 51330)

Цитата(Wise)
То же и с программой. Страховать каждый бит - это надо очень быть опасливым.. и в какие же объемы программной памяти такая страховка уместится..

Дело не в опасливости программиста, а в требованиях по отказоустойчивости. Если цена сбоя высока, то программиста обяжут "страховать каждый бит". Если нет, то, конечно же, до фанатизма опускаться не следует. Насчет объемов программ проверок все не так страшно, т.к. нам в конечном итоге важно не то, чтобы бит имел правильное состояние, а то, чтобы программа не начала вести себя неправильно; еще точнее: чтобы неправильные действия программы не привели к печальным последствиям. Эти проверки я опишу в "5.3 run-time контроль"

Цитата(Wise)
И эта мелодия не должна быть слишком умозрительной и академичной. Иначе, не будут покупать. Впрочем, один покупатель у вас уже есть..

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

Цитата(Прохожий)
Тем более, ПМСМ, надо увязывать WDT, монитор питания, контроль частоты в единую систему, наблюдающую за МК.

Конечно, все проверки должны делаться вкупе. Всему этому я посвящу гл. "5. Контроль программы в работе". Просто тема с WDT затронулась первой, можно начать с нее.

Цитата(MrYuran)
В вытесняющих ОС можно в каждой задаче сбрасывать свой маленький флажок, а в центральном цикле сбрасывать вочдог только в том случае, если все флаги сброшены.
И после этого опять поднять флаги и всё сначала.

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


Цитата(MrYuran)
У меня тоже грешок водится - при сохранении параметров во флеше не использую никаких защит, даже банальный ЦРЦ.
То есть, сбой во время записи - и полный Пэ. Калибровочные константы, параметры, режимы - всё что нажито...

Этому будет посвящен параграф "8.3 Энергонезависимая память"
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 17.8.2010, 10:58
Сообщение #19





Гости






Цитата(tester @ 17.8.2010, 12:35) *
Пока еще не решено насчет формата (т.е. что это будет книга).

Формат простой, как format С:
smile.gif
*.tex - переформатирование статьи в книгу и обратно - просто применением соответствующего шаблона.
Кстати, у меня это уже висит в стеке будущих задач (разобраться с tex-ом)

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

Цитата(tester @ 17.8.2010, 12:35) *
Для суперлупа такой подход еще менее удачен, т.к. оганичивает время выполнения одной функции периодом WDT.

Во-от...
Это может быть не баг, а фича!
Значит, программист должен следить, чтобы его задачи не захватывали слишком много времени.
Я, например, все громоздкие вычисления разбиваю на части и выполняю в автомате с возвратом управления после каждого действия.
И никаких __delay_cycles(30000) !

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

Меня по условиям безопасности заставляют на испытаниях вводить одиночные неисправности.
Например, закоротить транзистор, управляющий нагревом аммиака (кто не в курсе, греть его свыше 40 градусов крайне нежелательно)
И таким образом - по всем критическим параметрам.
Включая отказ процессора.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 17.8.2010, 11:26
Сообщение #20


Активный участник
***

Группа: Пользователи
Сообщений: 41
Регистрация: 15.8.2010
Из: SPb
Пользователь №: 197



Цитата(MrYuran @ 17.8.2010, 12:58) *
Кстати, у меня это уже висит в стеке будущих задач (разобраться с tex-ом)
У меня тоже. Как-то разбирался, но тогда было не нужно, поэтому забросил.

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

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


Цитата( @ 17.8.2010, 12:58) *
Во-от...
Это может быть не баг, а фича!
Значит, программист должен следить, чтобы его задачи не захватывали слишком много времени.
Я, например, все громоздкие вычисления разбиваю на части и выполняю в автомате с возвратом управления после каждого действия.
И никаких __delay_cycles(30000) !

Кстати, среди прочих проверок реалтайма (п. 5.3) есть проверки длительности выполнения конкретных узлов кода. Это, конечно к WDT не имеет отношения: мало ли, почему код выполнялся в три раза дольше, это не повод обрывать работу программы ресетом. Хотя в некоторых случаях - повод (в частности оконные WDT введены именно для этих целей)
Перейти в начало страницы
 
+Цитировать сообщение

5 страниц V   1 2 3 > » 
Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 28.3.2024, 15:24