IPB

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

5 страниц V  < 1 2 3 4 > »   
Ответить в данную темуНачать новую тему
> Отказоустойчивое ПО для МК, Обсуждение правил и приемов при для повышения надежности устройств
Гость_MrYuran_*
сообщение 17.8.2010, 11:47
Сообщение #21





Гости






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

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


Админ с Элха
***

Группа: Пользователи
Сообщений: 735
Регистрация: 28.7.2010
Из: Москва
Пользователь №: 188



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

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

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

оговариваюсь, что все это естесственно мы делаем на фоне использования аппаратного внешнего WDT с единственным местом, где происходит его сброс.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 17.8.2010, 13:49
Сообщение #23


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

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



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

Разбор полетов на каком уровне? В смысле "работа комиссии по расследованию причин?"
Перейти в начало страницы
 
+Цитировать сообщение
one_man_show
сообщение 17.8.2010, 13:51
Сообщение #24


Админ с Элха
***

Группа: Пользователи
Сообщений: 735
Регистрация: 28.7.2010
Из: Москва
Пользователь №: 188



В смысле предоставление возможности считать последние микросостояния системы для того, чтобы выявить причины сбоя или выхода из строя. На какаом уровне это будет делаться, обычно зависит от конкретных эксплуатационных норм. Главное, на мой взгляд, обеспечить такую возможность.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 17.8.2010, 14:05
Сообщение #25


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

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



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


Я сперва подумал, Вы имеете ввиду разборки "кто виноват и кого посадить". А то, о чем Вы пишете, я в оглавлении назвал "6.5 Протоколирование". Без него, естественно, никак.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 17.8.2010, 19:17
Сообщение #26


сундук
***

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



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

К стати, интересен был бы вопрос по взаимодействию с внешним миром.
В настоящий момент он сводится к наблюдению за питанием и частотой.
Но при проектировании девайса с самого начала известен объект управления.
И его особенности.
В некоторых случаях, действия по защите могут привести к неустойчивой работе объекта.
Как будет рассматриваться этот аспект надежности софта?
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 17.8.2010, 19:41
Сообщение #27


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

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



Цитата(Прохожий @ 17.8.2010, 21:17) *
К стати, интересен был бы вопрос по взаимодействию с внешним миром.
В настоящий момент он сводится к наблюдению за питанием и частотой.

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

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

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

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

-----------------
Добавлено: подредактировал оглавление в первом посте, добавил расшифровки, о чем каждый параграф
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 17.8.2010, 20:49
Сообщение #28


сундук
***

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



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

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

В целом, все выглядит достаточно пристойно. Такую книгу буду брать однозначно.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 17.8.2010, 21:11
Сообщение #29


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

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



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

В данном случае, на мой взгляд, должно применяться аппаратное резервирование. Дело даже не в скорости, а в том, что обнаружение сбоя влечет за собой какие-то действия (в ответственных системах - перевод в безопасный режим, чтобы чего не испортить), на время которых можно потерять контроль над оборудованием. Где-то само оборудование может быть само переведено в нейтральный режим, а где-то его нельзя останавливать. тут только аппаратное резервирование.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 17.8.2010, 21:16
Сообщение #30


сундук
***

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



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

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

К примеру, управляем неким процессом.
В описание закона управления (в математическом смысле) включены, объект и сам регулятор.
Понятно, что надежное ПО потребует введения неких ограничений.
Так вот, вопрос.
Как это дело отразится на математической модели системы в целом?
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 18.8.2010, 10:05
Сообщение #31


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

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



Цитата(Прохожий @ 17.8.2010, 23:16) *
Я немного не о том.

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


Мне думается, что никак. Мат.модель сама по себе абстрагирована от конкретной платформы и даже от языка программирования.
Или Вы к тому, какими данными руководствоваться при выборе элементной базы (МК) для реализации мат.модели с поправками на проверки отказов? Вопрос интересный, надо подумать...
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 18.8.2010, 16:06
Сообщение #32


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



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

Или тогда дублированием называть, типа мажоритарного.
Или это не резервирование в любом случае, а всегда перевод в более-менее нейтральный режим с частичной потерей функций.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 18.8.2010, 16:56
Сообщение #33


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

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



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

Да, имеется ввиду мажоритарное дублирование (только многократное) с полным или частичным сохранением функционала управляемого оборудования. Тут сам МК (или процессор) мало участия принимает в выборе решения. Но это аппаратные средства, и их описание выходит за рамки моей статьи.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_Максим Зиновьев_*
сообщение 18.8.2010, 18:34
Сообщение #34





Гости






Цитата
5.3. run-time контроль


Надо полагать, то, что мы делали в АОН на Z80 относится сюда.
Если есть какая-то цикличность, например динамическая индикация, на вывод строба можно ставить буфер, емкость и выпрямитель. При зависании - ресет (завести на вход супервизора, например).
При необходимости, можно просто вывести последовательность на свободный пин, который изменять в цикле, и провернуть такой же фокус.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 18.8.2010, 19:23
Сообщение #35


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

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



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

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

А run-time проверки - это:
- контроль времени выполнения
- проверка параметров функций (прежде чем обрабатывать данные, надо убедиться в том, что они не левые)
- проверка периферии
- перепроверка обратными расчетами (грубо говоря, если x=y*z => z д.б. = x/y)
- контроль состояния стека
- RAM-сигнатуры
- обработчики трапов
- настройки прерываний
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 18.8.2010, 22:31
Сообщение #36


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



А что творится вообще в мире в данной теме?
какая литература есть?
для меня вопрос жизненно важный, вхожу в тему МК, жызнь заставляет.
Но терять надежность при этом неохота.

Кстати, некоторое развитие надо бы дать теме физической защиты от самих причин сбоев,
помех всяких и прочего. Чаще бывает, чем случайные сбои... Хоть вроде и не совсем в тему,
к ПО прямого отношения не имеет... Но находится рядом...
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 19.8.2010, 11:13
Сообщение #37


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

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



Цитата(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
сообщение 19.8.2010, 13:17
Сообщение #38


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



Спасибо.

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

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

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

Собственно. наверно отдельная книга нужна, но я пока не потяну, мне еще учиться и учиться...
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 19.8.2010, 13:59
Сообщение #39





Гости






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

Когда я ещё разрабатывал военную технику, заметил одну характерную особенность.
Любое действие, любую команду обязательно нужно было квитировать.
То есть, был прямой командный канал и был обратный канал для квитанций.
Ни одна лампочка, ни один индикатор не загорался, пока не пришло подтверждение выполнения команды непосредственно с исполнительного устройства или модуля. Видимо, отказоустойчивые программы и системы необходимо проектировать схожим образом.
Перейти в начало страницы
 
+Цитировать сообщение
novichok
сообщение 19.8.2010, 14:58
Сообщение #40


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

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



Разрабатывали автономные устройства учета электроэнергии. Видели будки трансформаторные. Вот внутри на стенку наше устройство. Связь по GSM. Напрыгались мы с ними конкретно. Сделали. Заработало надежно. Бабки попилили, проект закрыли. А кому нужен учет? Никому.
В итоге все рассосалось, но три устройства так и остались работать внутри будок. Про них все забыли, кроме меня. В итоге с 2004 года без обслуживания, без какого либо надзора и прочее, молотят они статистику в полной автономке уже шесть лет. Во как.
Перейти в начало страницы
 
+Цитировать сообщение

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

 



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