Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Отказоустойчивое ПО для МК
Шарага > Soft - НЕ железо > Программирование МК
Страницы: 1, 2
tester
Приветствую участников!

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

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

Все остальное считаю безнадежным флудом , типа "вектора тестирования, методики оптимизации и прочая лабудень". Отказоустойчивая система это софт плюс схемотехника плюс физика плюс здравый смысл.
И писать книжку про голый отказоустойчивый софт это тратить время на очередной опус "на тему".
stells
Цитата(novichok @ 16.8.2010, 9:31) *
эти вопросы решаются совместно электрической схемой и алгоритмами отработки аварийных сбросов по питанию

мало того, в старых совковых микропроцессорах серии 1801ВМ1(2,3) и их "боевой" версии 1806ВМ2 предусматривалась подача двух сигналов от супервизора питания - ACLO и DCLO (провал по переменке и по постоянке), что теоретически позволяло предпринять некоторые действия до полного пропадания питания.
так что вопрос комплексный
MrYuran
А меня вот пп. 3,4 очень даже интересуют.
Ну, я уже писал.
Особенно тестирование и верификация, поскольку у нас тестирование проводится только на техпрогоне перед отправкой пользователям и некоторые глубинные проблемы всплывают спустя годы успешной эксплуатации
tester
Цитата(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
..Ну, такую книжку я бы приобрел.
Хотя, даже собаку не использую.. smile.gif
MrYuran
Цитата(Wise @ 16.8.2010, 14:20) *
Хотя, даже собаку не использую.. smile.gif

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

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

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

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

К тому же есть разные виды WDT:простой (встроенный), оконный, внешний, комбинированный. Алгоритм обработки WDT - это не тривиальная задача, имеющая множество нюансов, один из которых, как ни печально: WDT - это набор триггеров, один из которых (в том числе и отвечающий за режим работы) может изменить состояние под действием внешних помех.
MrYuran
Цитата(Wise @ 16.8.2010, 14:44) *
А чем поможет собака, если программа зациклится (тьфу-тьфу, не было ни разу..), но, сбрасывая собаку..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот...
У меня тоже грешок водится - при сохранении параметров во флеше не использую никаких защит, даже банальный ЦРЦ.
То есть, сбой во время записи - и полный Пэ. Калибровочные константы, параметры, режимы - всё что нажито...
Есть, конечно, команда восстановления заводских параметров, которые можно убить только вместе с прошивкой, но всё-таки это уже аварийное восстановление, которого можно было избежать.
tester
Цитата(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
Цитата(tester @ 17.8.2010, 12:35) *
Пока еще не решено насчет формата (т.е. что это будет книга).

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

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

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

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

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

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

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

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


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

Кстати, среди прочих проверок реалтайма (п. 5.3) есть проверки длительности выполнения конкретных узлов кода. Это, конечно к WDT не имеет отношения: мало ли, почему код выполнялся в три раза дольше, это не повод обрывать работу программы ресетом. Хотя в некоторых случаях - повод (в частности оконные WDT введены именно для этих целей)
MrYuran
Цитата(tester @ 16.8.2010, 13:39) *
smile.gif Обратите внимание, что у нас с Вами противоположный взгляд на повторное использование модулей (у меня п. 3.2, у Вас п. 1.5). Я считаю это как раз понижением надежности, т.к. применяться могут не только разные платформы или разные компиляторы, но иногда достаточно той же платформу, работающей на другой частоте. Мы используем модуль, который считаем надежным, а он сбоит, и ошибку будем искать везде, только не в нем. Хороший пример, который получил огласку, - Arian 5. (Проблема была в повторном использовании модуля).

Вот поэтому первым пунктом у меня стоит спецификация.
То есть детальное описание модуля, его возможностей, интерфейсов, области применения и ограничений.
Модно даже в тексте заголовочного файла, типа самодокументация.
Неплохо, если в стиле doxygen - тоже самодокументация.
Я вот полдня искал "10 отличий", почему мой Init() работает не так, как бывший в чужой программе.
Нашёл smile.gif Отличие в одной строчке - _EINT().
one_man_show
Попробую влиться, хотя сразу скажу, что создание отказоустойчивых и катастрофоустойчивых систем вызывает всегда неприятные воспоминания. Всегда хочется либо отказаться от их проектирования, либо заложиться на какие-то существующие для этого подсистемы, чтобы самому не изобретать велосипед. К сожалению, это не всегда удается.

Я бы добавил в пунктуацию будущей статьи/книги понятие "разбора полетов" и отдельной подготовки к возможности разбора этих полетов. Именно эта часть работы отказоустойчивых систем требует вносить огромное количество избыточных элементов как в аппаратную, так и программную части. По опыту: требую от своих разработчиков в подобных системах уделить отдельное внимание на инициализационную часть прошивки. Она обязательно должна содержать разбор ситуации "А с чего это мы перезапустились". То есть требуется довести систему до того, чтобы все возможные ситуации были для нее штатными. Например, пусть наш МК позволяет определять причину ресета (wdt, питание и т.п.). Даже с включением питания нужно разбираться в самом начале, пока дальше программа не убежала. Чтобы иметь такую возможность, необходимо во время работы иметь страховку в виде энергонезависимой памяти и постоянного туда прописывания того чем мы заняты в данный момент. Это речь о порграммной избыточности, которая имеет отношение к подготовке информации для возможных разборов ситуаций, если они вдруг случатся.

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

оговариваюсь, что все это естесственно мы делаем на фоне использования аппаратного внешнего WDT с единственным местом, где происходит его сброс.
tester
Цитата(one_man_show @ 17.8.2010, 15:29) *
Я бы добавил в пунктуацию будущей статьи/книги понятие "разбора полетов" и отдельной подготовки к возможности разбора этих полетов.

Разбор полетов на каком уровне? В смысле "работа комиссии по расследованию причин?"
one_man_show
В смысле предоставление возможности считать последние микросостояния системы для того, чтобы выявить причины сбоя или выхода из строя. На какаом уровне это будет делаться, обычно зависит от конкретных эксплуатационных норм. Главное, на мой взгляд, обеспечить такую возможность.
tester
Цитата(one_man_show @ 17.8.2010, 15:51) *
В смысле предоставление возможности считать последние микросостояния системы для того, чтобы выявить причины сбоя или выхода из строя. На какаом уровне это будет делаться, обычно зависит от конкретных эксплуатационных норм. Главное, на мой взгляд, обеспечить такую возможность.


Я сперва подумал, Вы имеете ввиду разборки "кто виноват и кого посадить". А то, о чем Вы пишете, я в оглавлении назвал "6.5 Протоколирование". Без него, естественно, никак.
Прохожий
Цитата(tester @ 17.8.2010, 16:05) *
Я сперва подумал, Вы имеете ввиду разборки "кто виноват и кого посадить". А то, о чем Вы пишете, я в оглавлении назвал "6.5 Протоколирование". Без него, естественно, никак.

К стати, интересен был бы вопрос по взаимодействию с внешним миром.
В настоящий момент он сводится к наблюдению за питанием и частотой.
Но при проектировании девайса с самого начала известен объект управления.
И его особенности.
В некоторых случаях, действия по защите могут привести к неустойчивой работе объекта.
Как будет рассматриваться этот аспект надежности софта?
tester
Цитата(Прохожий @ 17.8.2010, 21:17) *
К стати, интересен был бы вопрос по взаимодействию с внешним миром.
В настоящий момент он сводится к наблюдению за питанием и частотой.

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

Цитата
Но при проектировании девайса с самого начала известен объект управления.
И его особенности.
В некоторых случаях, действия по защите могут привести к неустойчивой работе объекта.
Как будет рассматриваться этот аспект надежности софта?

Если объект начинает вести себя неустойчиво, то защита реализована неправильно. Вообще этим действиям собирался посвятить параграфы:
"5.3. run-time контроль",
"5.5. что делать при обнаружении сбоя",
"6.6. безопасный режим" и
"9.1. резервирование"
(я понимаю, что практически на каждый вопрос всего лишь отписываюсь номерами будущих глав, но, поверьте, у меня есть что в них написать; в частности черновик к WDT уже пишется).

Если Вы рассматриваете этот вопрос в рамках "что если не хватит скорости", значит была допущена ошибка на стадии выбора элементной базы. Функции по обеспечению надежности должны быть учтены при распределении ресурсов: время, ROM, RAM, EEPROM. (Немного схожую проблему я описывал здесь в главе "Отладка и тестирование")

-----------------
Добавлено: подредактировал оглавление в первом посте, добавил расшифровки, о чем каждый параграф
Прохожий
Цитата(tester @ 17.8.2010, 21:41) *
Конкретно влияющим на выполнение программы, наверное, можно добавить температуру. А так, в зависимости от области применения можно получать и контролировать любой параметр внешнего мира: от простых контактных датчиков до сложных внешних модулей.

Тут еще один момент - влияние ограничений, обеспечивающих надежность, на основную задачу.
К примеру, надо ли их будет учитывать при расчете коэффициентов PID-регулятора?
Особенно, когда их целая матрица?
Цитата(tester @ 17.8.2010, 21:41) *
Добавлено: подредактировал оглавление в первом посте, добавил расшифровки, о чем каждый параграф

В целом, все выглядит достаточно пристойно. Такую книгу буду брать однозначно.
tester
Цитата(Прохожий @ 17.8.2010, 22:49) *
Тут еще один момент - влияние ограничений, обеспечивающих надежность, на основную задачу.
К примеру, надо ли их будет учитывать при расчете коэффициентов PID-регулятора?
Особенно, когда их целая матрица?

В данном случае, на мой взгляд, должно применяться аппаратное резервирование. Дело даже не в скорости, а в том, что обнаружение сбоя влечет за собой какие-то действия (в ответственных системах - перевод в безопасный режим, чтобы чего не испортить), на время которых можно потерять контроль над оборудованием. Где-то само оборудование может быть само переведено в нейтральный режим, а где-то его нельзя останавливать. тут только аппаратное резервирование.
Прохожий
Цитата(tester @ 17.8.2010, 23:11) *
В данном случае, на мой взгляд, должно применяться аппаратное резервирование. Дело даже не в скорости, а в том, что обнаружение сбоя влечет за собой какие-то действия (в ответственных системах - перевод в безопасный режим, чтобы чего не испортить), на время которых можно потерять контроль над оборудованием. Где-то само оборудование может быть само переведено в нейтральный режим, а где-то его нельзя останавливать. тут только аппаратное резервирование.

Я немного не о том.

К примеру, управляем неким процессом.
В описание закона управления (в математическом смысле) включены, объект и сам регулятор.
Понятно, что надежное ПО потребует введения неких ограничений.
Так вот, вопрос.
Как это дело отразится на математической модели системы в целом?
tester
Цитата(Прохожий @ 17.8.2010, 23:16) *
Я немного не о том.

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


Мне думается, что никак. Мат.модель сама по себе абстрагирована от конкретной платформы и даже от языка программирования.
Или Вы к тому, какими данными руководствоваться при выборе элементной базы (МК) для реализации мат.модели с поправками на проверки отказов? Вопрос интересный, надо подумать...
orthodox
Цитата(tester @ 17.8.2010, 22:11) *
Где-то само оборудование может быть само переведено в нейтральный режим, а где-то его нельзя останавливать. тут только аппаратное резервирование.

Или тогда дублированием называть, типа мажоритарного.
Или это не резервирование в любом случае, а всегда перевод в более-менее нейтральный режим с частичной потерей функций.
tester
Цитата(orthodox @ 18.8.2010, 18:06) *
Или тогда дублированием называть, типа мажоритарного.
Или это не резервирование в любом случае, а всегда перевод в более-менее нейтральный режим с частичной потерей функций.

Да, имеется ввиду мажоритарное дублирование (только многократное) с полным или частичным сохранением функционала управляемого оборудования. Тут сам МК (или процессор) мало участия принимает в выборе решения. Но это аппаратные средства, и их описание выходит за рамки моей статьи.
Максим Зиновьев
Цитата
5.3. run-time контроль


Надо полагать, то, что мы делали в АОН на Z80 относится сюда.
Если есть какая-то цикличность, например динамическая индикация, на вывод строба можно ставить буфер, емкость и выпрямитель. При зависании - ресет (завести на вход супервизора, например).
При необходимости, можно просто вывести последовательность на свободный пин, который изменять в цикле, и провернуть такой же фокус.
tester
Цитата(Максим Зиновьев @ 18.8.2010, 20:34) *
Надо полагать, то, что мы делали в АОН на Z80 относится сюда.
Если есть какая-то цикличность, например динамическая индикация, на вывод строба можно ставить буфер, емкость и выпрямитель. При зависании - ресет (завести на вход супервизора, например).
При необходимости, можно просто вывести последовательность на свободный пин, который изменять в цикле, и провернуть такой же фокус.

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

А run-time проверки - это:
- контроль времени выполнения
- проверка параметров функций (прежде чем обрабатывать данные, надо убедиться в том, что они не левые)
- проверка периферии
- перепроверка обратными расчетами (грубо говоря, если x=y*z => z д.б. = x/y)
- контроль состояния стека
- RAM-сигнатуры
- обработчики трапов
- настройки прерываний
orthodox
А что творится вообще в мире в данной теме?
какая литература есть?
для меня вопрос жизненно важный, вхожу в тему МК, жызнь заставляет.
Но терять надежность при этом неохота.

Кстати, некоторое развитие надо бы дать теме физической защиты от самих причин сбоев,
помех всяких и прочего. Чаще бывает, чем случайные сбои... Хоть вроде и не совсем в тему,
к ПО прямого отношения не имеет... Но находится рядом...
tester
Цитата(orthodox @ 19.8.2010, 0:31) *
А что творится вообще в мире в данной теме?
какая литература есть?


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

Есть книга Nancy Levenson "Software safety in embedded computer systems", но на русский перевода нет, да и на английском я ее так и не нашел. Это первая книга, посвященная данной тематике.
Есть неплохая статья "Immunity Aware Programming" (оригинал не найти, но вот она же на wiki , бегло просмотрел, вроде, один в один).
Интресеная и поучительная статья по WDT: "Building a Great Watchdog"

Ну, а так, в нете попадаются статьи, но только на английском, надо искать в связке с embedded слова: reliability, safety, redundancy.

ГОСТы:
ГОСТ 28195-89 "Оценка качества программных средств. Общие положения"
ГОСТ Р ИСО-МЭК 9126-93 "Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению"
МЭК 60730-1-2002 (приложение H) "Автоматические электрические управляющие устройства бытового и аналогичного назначения. Общие требования и методы испытаний"
МЭК 61508-3-2007 "Функциональная безопасность систем электрических, електронных, программируемых электронных связанных с безопасностью"

По практическим приемам можно пошукать на сайтах производителей библиотеки с функциями для соответствия IEC 60730, например:
Atmel - AVR998
Cortex - AN10918
Microchip - AN1229

Ну, и хорошие книги, пересекающиеся с темой:
П. Гудлиф "Ремесло программиста"
И. Соммервилл "Инженерия программного обеспечения"
Керниган, Пайк "Практика программирования"


Цитата
Кстати, некоторое развитие надо бы дать теме физической защиты от самих причин сбоев,
помех всяких и прочего. Чаще бывает, чем случайные сбои... Хоть вроде и не совсем в тему,
к ПО прямого отношения не имеет... Но находится рядом...

Этих тем я буду касаться только когда без них никак (например, внешний WDT).
orthodox
Спасибо.

Цитата(tester @ 19.8.2010, 12:13) *
Этих тем я буду касаться только когда без них никак (например, внешний WDT).

ну, тут сложности.
С одной стороны, тема у Вас определена, с другой - вопрос важный и освещен тоже мало, а по результатам
они сходны. И главное, что это вопрос может так помешать основной теме... Что как ни програмируй..

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

Собственно. наверно отдельная книга нужна, но я пока не потяну, мне еще учиться и учиться...
MrYuran
Цитата(orthodox @ 19.8.2010, 15:17) *
С одной стороны, тема у Вас определена, с другой - вопрос важный и освещен тоже мало, а по результатам
они сходны. И главное, что это вопрос может так помешать основной теме... Что как ни программируй..

Когда я ещё разрабатывал военную технику, заметил одну характерную особенность.
Любое действие, любую команду обязательно нужно было квитировать.
То есть, был прямой командный канал и был обратный канал для квитанций.
Ни одна лампочка, ни один индикатор не загорался, пока не пришло подтверждение выполнения команды непосредственно с исполнительного устройства или модуля. Видимо, отказоустойчивые программы и системы необходимо проектировать схожим образом.
novichok
Разрабатывали автономные устройства учета электроэнергии. Видели будки трансформаторные. Вот внутри на стенку наше устройство. Связь по GSM. Напрыгались мы с ними конкретно. Сделали. Заработало надежно. Бабки попилили, проект закрыли. А кому нужен учет? Никому.
В итоге все рассосалось, но три устройства так и остались работать внутри будок. Про них все забыли, кроме меня. В итоге с 2004 года без обслуживания, без какого либо надзора и прочее, молотят они статистику в полной автономке уже шесть лет. Во как.
MrYuran
Цитата(novichok @ 19.8.2010, 16:58) *
В итоге с 2004 года без обслуживания, без какого либо надзора и прочее, молотят они статистику в полной автономке уже шесть лет. Во как.

Ну так, поделитесь секретами, чтобы другие тоже могли такое сделать.
orthodox
Цитата(MrYuran @ 19.8.2010, 16:27) *
Ну так, поделитесь секретами, чтобы другие тоже могли такое сделать.

Как бы секретом не оказалось просто аккуратное программирование без лишних фокусов,
и правильная схемотехника, с хорошим помехоподавлением...
Говорю, нельзя сбрасывать этот фактор, сам по себе часто ну очень доставляет.
novichok
Цитата(MrYuran @ 19.8.2010, 15:27) *
Ну так, поделитесь секретами, чтобы другие тоже могли такое сделать.

Секретов нет, сам подход я описал в начале топика. Смотрите на первой странице. А по делу, тупое вылавливание багов.
Принцип простой чем дотошнее вылизывается устройство, тем надежнее работает.
tester
Цитата(orthodox @ 19.8.2010, 15:17) *
ну, тут сложности.
С одной стороны, тема у Вас определена, с другой - вопрос важный и освещен тоже мало, а по результатам
они сходны. И главное, что это вопрос может так помешать основной теме... Что как ни програмируй..

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

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

Совсем-совсем без помех? Ну, тогда тривиальный пример: через 10-15 лет сойдет заряд в затворе одного из транзисторов Flash памяти программы. После этого программа может начать сбоить раз в минуту. Или еще тривиальнее: поставили Вы его работать, а в доме электричество пропало на 10 секунд (если оно выполняло какое-то действие, то данные будут потеряны). И т.д.

Только почему Вы тепличные условия рассматриваете? Устройство-то будет в реальных работать.
orthodox
Цитата(novichok @ 19.8.2010, 17:34) *
Секретов нет, сам подход я описал в начале топика. Смотрите на первой странице. А по делу, тупое вылавливание багов.
Принцип простой чем дотошнее вылизывается устройство, тем надежнее работает.

+550



Цитата
Только почему Вы тепличные условия рассматриваете? Устройство-то будет в реальных работать.


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


Собственно, на сертификации всем этим и занимаются, но лучше ее использовать как контроль того что натворили...
А то ненадежно получится...
tester
Цитата(novichok @ 19.8.2010, 18:34) *
Секретов нет, сам подход я описал в начале топика. Смотрите на первой странице. А по делу, тупое вылавливание багов.
Принцип простой чем дотошнее вылизывается устройство, тем надежнее работает.

Методичность и усидчивость - хорошие помощники в таком деле. Но только помощники. Неужели Вам ни разу не приходилось сталкиваться с ошибками компиляторов?
orthodox
Цитата(tester @ 19.8.2010, 17:36) *
Правильная схемотехника - это основа. Без нее, действительно, нет смысла заниматься вылизыванием ПО. (Хотя, надо признать, что тенденция замены электроники программой присутствует.) Но схемотехника не моя тема, я не смогу ее описать толково и многогранно. Я знаю только общие правила по обеспечению питания, по разводке и пр. Но пока не могу претендовать на то, чтобы других этому учить.


Да ничо, поможем...
Вы пишите, лишь бы получилось...
нужные главки в виде планчика, а мы заполним пробелы...
И пробелы в планчике - тоже smile.gif
tester
Цитата(orthodox @ 19.8.2010, 18:42) *
Собственно, на сертификации всем этим и занимаются, но лучше ее использовать как контроль того что натворили...

На сертификации занимаются получением индульгенций smile.gif (Шутка, конечно)
novichok

Мне кажется, надо не просто писать про оторванное от реальности "отказоустойчивое ПО", а проделать колоссальную работу по созданию сложного устройства, которое должно работать годами без обслуживания. То, что я описал, там простенький микроконтроллер AVR и для книги не пойдет.
Надо замутить нечто на Linux, ARM какой нибудь навороченный. И оно безусловно свалится очень быстро работая в автономке.
Вот доведение этого устройства до ума, вылизывание платы, схемы и софта в комплексе в режиме онлайн.
А софт, так прямо правка исходников с учетом требований надежности, и наглядной демонстрацией, где, как и почему поправили.
Плюс интерфейсы коммуникационные, которые наверняка тоже станут источником проблем, плюс температурные дела, из за которых NAND например расшилась раньше времени и так далее... В итоге, получив по настоящему безотказный дивайс, которые не боится ни минусов, ни плюсов, ни статических разрядов. А в комплекте к нему непробиваемый дизайн и такой же непробиваемый переработанный на низком уровне Linux, на котором можно в Космос полететь.
Вот это да, это будет по настоящему ценный комплект. Можно затем отдельно продавать свои контроллеры, которые в поле в режиме онлайн показывают стройки Путина, потребляя в десятки раз меньше энергии и денег, как на обслуживание, так и на трафик.
Такую книгу можно и купить в оригинале, потому что за ней несколько лет реального труда и практическая ценность отказоустойчивого дизайна.
Можно пойти дальше, и расширить понятие отказоустойчивости, и создать серию дизайнов, каждый из которых отказоустойчив по своему.



PS: Ошибки компиляторов это зверь который удивляет когда горе программист умудряется в течение дня писать в 10 разных средах на семи языках. Тогда это проблема. А когда извините полгода корячишься над одним дизайном где не то, что схему плату, царапины на резисторах запомнил, там ошибки компиляторов неактуальны, потому что при отладке c JTAG контроль идет над содержимым регистров в онлайн режиме, и никто не смотрит на программу, а исключительно на результат. И когда компилятор подсовывает свои левые команды или кривые флаги, это отсекается в первый месяц работы.
orthodox
Цитата(tester @ 19.8.2010, 17:47) *
На сертификации занимаются получением индульгенций smile.gif (Шутка, конечно)

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

Цитата(novichok @ 19.8.2010, 17:54) *
PS: Ошибки компиляторов это зверь который удивляет когда горе программист умудряется в течение дня писать в 10 разных средах на семи языках. Тогда это проблема. А когда извините полгода корячишься над одним дизайном где не то, что схему плату, царапины на резисторах запомнил, там ошибки компиляторов неактуальны, потому что при отладке c JTAG контроль идет над содержимым регистров в онлайн режиме, и никто не смотрит на программу, а исключительно на результат. И когда компилятор подсовывает свои левые команды или кривые флаги, это отсекается в первый месяц работы.


Самое оно.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2020 IPS, Inc.