IPB

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

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





Гости






Цитата(novichok @ 19.8.2010, 16:58) *
В итоге с 2004 года без обслуживания, без какого либо надзора и прочее, молотят они статистику в полной автономке уже шесть лет. Во как.

Ну так, поделитесь секретами, чтобы другие тоже могли такое сделать.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 19.8.2010, 16:13
Сообщение #42


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

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



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

Как бы секретом не оказалось просто аккуратное программирование без лишних фокусов,
и правильная схемотехника, с хорошим помехоподавлением...
Говорю, нельзя сбрасывать этот фактор, сам по себе часто ну очень доставляет.
Перейти в начало страницы
 
+Цитировать сообщение
novichok
сообщение 19.8.2010, 16:34
Сообщение #43


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

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



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

Секретов нет, сам подход я описал в начале топика. Смотрите на первой странице. А по делу, тупое вылавливание багов.
Принцип простой чем дотошнее вылизывается устройство, тем надежнее работает.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 19.8.2010, 16:36
Сообщение #44


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

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



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

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

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

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

Только почему Вы тепличные условия рассматриваете? Устройство-то будет в реальных работать.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 19.8.2010, 16:42
Сообщение #45


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

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



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

+550



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


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


Собственно, на сертификации всем этим и занимаются, но лучше ее использовать как контроль того что натворили...
А то ненадежно получится...
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 19.8.2010, 16:44
Сообщение #46


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

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



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

Методичность и усидчивость - хорошие помощники в таком деле. Но только помощники. Неужели Вам ни разу не приходилось сталкиваться с ошибками компиляторов?
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 19.8.2010, 16:47
Сообщение #47


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

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



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


Да ничо, поможем...
Вы пишите, лишь бы получилось...
нужные главки в виде планчика, а мы заполним пробелы...
И пробелы в планчике - тоже smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 19.8.2010, 16:47
Сообщение #48


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

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



Цитата(orthodox @ 19.8.2010, 18:42) *
Собственно, на сертификации всем этим и занимаются, но лучше ее использовать как контроль того что натворили...

На сертификации занимаются получением индульгенций smile.gif (Шутка, конечно)
Перейти в начало страницы
 
+Цитировать сообщение
novichok
сообщение 19.8.2010, 16:54
Сообщение #49


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

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




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



PS: Ошибки компиляторов это зверь который удивляет когда горе программист умудряется в течение дня писать в 10 разных средах на семи языках. Тогда это проблема. А когда извините полгода корячишься над одним дизайном где не то, что схему плату, царапины на резисторах запомнил, там ошибки компиляторов неактуальны, потому что при отладке c JTAG контроль идет над содержимым регистров в онлайн режиме, и никто не смотрит на программу, а исключительно на результат. И когда компилятор подсовывает свои левые команды или кривые флаги, это отсекается в первый месяц работы.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 19.8.2010, 17:23
Сообщение #50


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

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



Цитата(tester @ 19.8.2010, 17:47) *
На сертификации занимаются получением индульгенций smile.gif (Шутка, конечно)

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

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


Самое оно.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 19.8.2010, 17:24
Сообщение #51


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

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



Цитата(novichok @ 19.8.2010, 18:54) *
Мне кажется, надо не просто писать про оторванное от реальности "отказоустойчивое ПО", а проделать колоссальную работу по созданию сложного устройства, которое должно работать годами без обслуживания. То, что я описал, там простенький микроконтроллер AVR и для книги не пойдет.
Надо замутить нечто на Linux, ARM какой нибудь навороченный. И оно безусловно свалится очень быстро работая в автономке.

Зря считаете, что устройство на контроллере AVR не достойно описания.
Какие Вы устройства делали на Linux+ARM? Попробуйте по одному из них (любому, на Ваше усмотрение) составить план статьи (или книги). Какие бы темы Вы охватили?

Цитата
Вот доведение этого устройства до ума, вылизывание платы, схемы и софта в комплексе в режиме онлайн. А софт, так прямо правка исходников с учетом требований надежности, и наглядной демонстрацией, где, как и почему поправили.

Я по профессии занимаюсь именно этим, и именно над софтом. Я, конечно, понимаю, что про правку исходников с наглядной демонстрацией результата Вы пошутили, но складывается впечатление, что Вы не очень знакомы с вопросом.

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

Безотказных девайсов не бывает. Бывают девайсы, которые переживают отказы с минимальными потерями, даже ценой потери работоспособности. Если не секрет, в кокой области применяете устройства под Linux'ом?

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

Не приведете пример ошибки компилятора, выловленной таким способом?
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 20.8.2010, 7:01
Сообщение #52


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Цитата(orthodox @ 19.8.2010, 17:13) *
аккуратное программирование без лишних фокусов,

Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 20.8.2010, 7:13
Сообщение #53





Гости






Цитата(_pasha @ 20.8.2010, 9:01) *
Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет.

drinks.gif
А вот бывает так:
Работает пару лет, а потом вдруг перестаёт...
Вот в моей теме есть раздел про тестирование.
В настоящее время у нас тестирования ПО как такового вообще нет.
То есть проводится тестирование всего изделия в комплексе на соответствие ТУ, РЭ и заявленным параметрам, а отдельно ПО - не тестируется вообще.
В "большом" программировании тесты - это основа. То есть, поменяв что-то где-то, можно прогнать серию тестов и убедиться, что нигде ничего не сломалось. Иначе потом это найти будет очень сложно.
Вот в связи с этим у меня конкретный вопрос. Как формализовать процедуру тестирования модулей встраиваемого ПО.
Выход вижу такой:
1. Должна быть чёткая грань между верхним (платформо-независимым) уровнем и нижним, который привязан к железу.
2. Нижний уровень тестируем в железе, подавая специальные команды и контролируя исполнение осциллографом и др. измерительным оборудованием.
3. Верхний уровень может быть первоначально отлажен и протестирован на ПК, а потом дополнительно - на целевой платформе. Видимо, тоже через какой-то технологический интерфейс или монитор.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 20.8.2010, 12:25
Сообщение #54


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

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



Цитата(_pasha @ 20.8.2010, 8:01) *
Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет.

Ну, например, один из фокусов - предположение о том, что входные данные не будут никогда выходить за некий умозрительно представленный диапазон smile.gif. Здорово экономит обычно на контроле данных...
Применяется даже в авиа - и космических программах... Известен по результатам , из прессы, сообщения об авариях...
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 20.8.2010, 17:37
Сообщение #55


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Цитата(MrYuran @ 20.8.2010, 7:13) *
1. Должна быть чёткая грань между верхним (платформо-независимым) уровнем и нижним, который привязан к железу.

Есть такая бяка - переполнение стека. Вот ее бы как-то вылавливать наверху - цены б не было.


Цитата(orthodox @ 20.8.2010, 12:25) *
Ну, например, один из фокусов - предположение о том, что входные данные не будут никогда выходить за некий умозрительно представленный диапазон

Это не предположение, а "закладка" pardon.gif на случай кидалова. Если программаст не страдает аутизмом.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 21.8.2010, 11:48
Сообщение #56


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

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



Цитата(_pasha @ 20.8.2010, 9:01) *
Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет.

Работоспособность программы и мнение программиста о работоспособности программы - разные вещи.

А "фокусами" можно назвать любые приемы профессионала с точки зрения дилетанта. Я уж не говорю о таких вещах как атомарность или volatile (хотя и они у некоторых вызывают непонятки), но ведь и проверка причин сброса при включении тоже может восприниматься как "фокус".

Сообщение отредактировал tester - 21.8.2010, 13:42
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 21.8.2010, 12:20
Сообщение #57


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

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



Цитата(_pasha @ 20.8.2010, 18:37) *
Это не предположение, а "закладка" pardon.gif на случай кидалова. Если программаст не страдает аутизмом.

Бомба с взрывателем, установленным на случайно выбранное время.
Может рвануть, пока программист как раз в кассе у окошка...
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 21.8.2010, 13:39
Сообщение #58


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

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



Цитата(orthodox @ 21.8.2010, 14:20) *
Бомба с взрывателем, установленным на случайно выбранное время.
Может рвануть, пока программист как раз в кассе у окошка...


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

Чтобы не было кидалова, нужно, во-первых, уметь общаться с заказчиком, а не соглашаться на первые же его условия "сначала программа, потом деньги"; во-вторых, забыть об амбициях насчет процента с прибыли, а то программист начинает мыслить категорями экономиса: "в первый месяц продастся 10 тыс. устройств, во второй - 20 тыс. и т.д. Ура!"; в-третьих, как это ни печально, следует знать себе цену, а не точить зло на весь мир, что его не оценили по достоинству.

А если хирурги начнут свои амбиции через профессию выражать? "Отавлю-ка я зажимы у него в животе, вдруг не расплатится". Или диспетчеры на аэродромах, или строители?
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 21.8.2010, 13:44
Сообщение #59


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

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



Цитата(tester @ 21.8.2010, 14:39) *
А если хирурги начнут свои амбиции через профессию выражать? "Отавлю-ка я зажимы у него в животе, вдруг не расплатится". Или диспетчеры на аэродромах, или строители?

Однако, кидалово существует и деться от этого некуда.
Каждый сам решает, что его устроит.

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

А лекарство только одно - работать в команде однотипно мыслящих людей.
То есть с одинаковым уровнем этики, тогда или все друг друга кидают, или никто никого, в зависимости
от уровня этики и морали команды.
Перейти в начало страницы
 
+Цитировать сообщение
tester
сообщение 21.8.2010, 13:57
Сообщение #60


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

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



Цитата(orthodox @ 21.8.2010, 15:44) *
обычно сводится к тому, что кидающий программиста
может кидать любого.

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

Цитата
А лекарство только одно - работать в команде однотипно мыслящих людей.

Хе-хе smile.gif Все в команде мыслят однотипно: "В конце проекта я всех кину!"

Цитата(Огурцов @ 21.8.2010, 15:45) *
Ох уж эта молодежь. Оне еще не знают, что чтобы прога упала, закладки не нужны.

biggrin.gif
Перейти в начало страницы
 
+Цитировать сообщение

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

 



Текстовая версия Сейчас: 29.3.2024, 2:50