Отказоустойчивое ПО для МК, Обсуждение правил и приемов при для повышения надежности устройств |
Здравствуйте, гость ( Вход | Регистрация )
Отказоустойчивое ПО для МК, Обсуждение правил и приемов при для повышения надежности устройств |
Гость_MrYuran_* |
19.8.2010, 15:27
Сообщение
#41
|
Гости |
|
|
|
19.8.2010, 16:13
Сообщение
#42
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Ну так, поделитесь секретами, чтобы другие тоже могли такое сделать. Как бы секретом не оказалось просто аккуратное программирование без лишних фокусов, и правильная схемотехника, с хорошим помехоподавлением... Говорю, нельзя сбрасывать этот фактор, сам по себе часто ну очень доставляет. |
|
|
19.8.2010, 16:34
Сообщение
#43
|
|
Активный участник Группа: Пользователи Сообщений: 40 Регистрация: 30.7.2010 Пользователь №: 189 |
|
|
|
19.8.2010, 16:36
Сообщение
#44
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
ну, тут сложности. С одной стороны, тема у Вас определена, с другой - вопрос важный и освещен тоже мало, а по результатам они сходны. И главное, что это вопрос может так помешать основной теме... Что как ни програмируй.. Правильная схемотехника - это основа. Без нее, действительно, нет смысла заниматься вылизыванием ПО. (Хотя, надо признать, что тенденция замены электроники программой присутствует.) Но схемотехника не моя тема, я не смогу ее описать толково и многогранно. Я знаю только общие правила по обеспечению питания, по разводке и пр. Но пока не могу претендовать на то, чтобы других этому учить. Цитата Однако, насколько часто он способен сбиваться в тепличных условиях? Например на столе в макете без помех? раз в три года? При правильном программировании и пр. Совсем-совсем без помех? Ну, тогда тривиальный пример: через 10-15 лет сойдет заряд в затворе одного из транзисторов Flash памяти программы. После этого программа может начать сбоить раз в минуту. Или еще тривиальнее: поставили Вы его работать, а в доме электричество пропало на 10 секунд (если оно выполняло какое-то действие, то данные будут потеряны). И т.д. Только почему Вы тепличные условия рассматриваете? Устройство-то будет в реальных работать. |
|
|
19.8.2010, 16:42
Сообщение
#45
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Секретов нет, сам подход я описал в начале топика. Смотрите на первой странице. А по делу, тупое вылавливание багов. Принцип простой чем дотошнее вылизывается устройство, тем надежнее работает. +550 Цитата Только почему Вы тепличные условия рассматриваете? Устройство-то будет в реальных работать. В тепличных ловим свои баги , после добавляем проверки по температуре и что там еще (которые перед тем обязательно в модели тоже сделать). А после создаем помехи значительно больше реальных , и начинаем искать глюки , связанные с ними (все это тоже надо вначале отмоделировать, так что не столько искать, сколько проверять уже нормальую работу). если сначала не обкатывать в тепличных условиях - можно начать метаццо , помеха виновата или что не так написано/спаяно... Собственно, на сертификации всем этим и занимаются, но лучше ее использовать как контроль того что натворили... А то ненадежно получится... |
|
|
19.8.2010, 16:44
Сообщение
#46
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
Секретов нет, сам подход я описал в начале топика. Смотрите на первой странице. А по делу, тупое вылавливание багов. Принцип простой чем дотошнее вылизывается устройство, тем надежнее работает. Методичность и усидчивость - хорошие помощники в таком деле. Но только помощники. Неужели Вам ни разу не приходилось сталкиваться с ошибками компиляторов? |
|
|
19.8.2010, 16:47
Сообщение
#47
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Правильная схемотехника - это основа. Без нее, действительно, нет смысла заниматься вылизыванием ПО. (Хотя, надо признать, что тенденция замены электроники программой присутствует.) Но схемотехника не моя тема, я не смогу ее описать толково и многогранно. Я знаю только общие правила по обеспечению питания, по разводке и пр. Но пока не могу претендовать на то, чтобы других этому учить. Да ничо, поможем... Вы пишите, лишь бы получилось... нужные главки в виде планчика, а мы заполним пробелы... И пробелы в планчике - тоже |
|
|
19.8.2010, 16:47
Сообщение
#48
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
|
|
|
19.8.2010, 16:54
Сообщение
#49
|
|
Активный участник Группа: Пользователи Сообщений: 40 Регистрация: 30.7.2010 Пользователь №: 189 |
Мне кажется, надо не просто писать про оторванное от реальности "отказоустойчивое ПО", а проделать колоссальную работу по созданию сложного устройства, которое должно работать годами без обслуживания. То, что я описал, там простенький микроконтроллер AVR и для книги не пойдет. Надо замутить нечто на Linux, ARM какой нибудь навороченный. И оно безусловно свалится очень быстро работая в автономке. Вот доведение этого устройства до ума, вылизывание платы, схемы и софта в комплексе в режиме онлайн. А софт, так прямо правка исходников с учетом требований надежности, и наглядной демонстрацией, где, как и почему поправили. Плюс интерфейсы коммуникационные, которые наверняка тоже станут источником проблем, плюс температурные дела, из за которых NAND например расшилась раньше времени и так далее... В итоге, получив по настоящему безотказный дивайс, которые не боится ни минусов, ни плюсов, ни статических разрядов. А в комплекте к нему непробиваемый дизайн и такой же непробиваемый переработанный на низком уровне Linux, на котором можно в Космос полететь. Вот это да, это будет по настоящему ценный комплект. Можно затем отдельно продавать свои контроллеры, которые в поле в режиме онлайн показывают стройки Путина, потребляя в десятки раз меньше энергии и денег, как на обслуживание, так и на трафик. Такую книгу можно и купить в оригинале, потому что за ней несколько лет реального труда и практическая ценность отказоустойчивого дизайна. Можно пойти дальше, и расширить понятие отказоустойчивости, и создать серию дизайнов, каждый из которых отказоустойчив по своему. PS: Ошибки компиляторов это зверь который удивляет когда горе программист умудряется в течение дня писать в 10 разных средах на семи языках. Тогда это проблема. А когда извините полгода корячишься над одним дизайном где не то, что схему плату, царапины на резисторах запомнил, там ошибки компиляторов неактуальны, потому что при отладке c JTAG контроль идет над содержимым регистров в онлайн режиме, и никто не смотрит на программу, а исключительно на результат. И когда компилятор подсовывает свои левые команды или кривые флаги, это отсекается в первый месяц работы. |
|
|
19.8.2010, 17:23
Сообщение
#50
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
На сертификации занимаются получением индульгенций (Шутка, конечно) Конечно, шутка. Я люблю проходить честно, это доставляет. И главное, что аккуратное прохождение дает дополнительные гарантии именно надежности... PS: Ошибки компиляторов это зверь который удивляет когда горе программист умудряется в течение дня писать в 10 разных средах на семи языках. Тогда это проблема. А когда извините полгода корячишься над одним дизайном где не то, что схему плату, царапины на резисторах запомнил, там ошибки компиляторов неактуальны, потому что при отладке c JTAG контроль идет над содержимым регистров в онлайн режиме, и никто не смотрит на программу, а исключительно на результат. И когда компилятор подсовывает свои левые команды или кривые флаги, это отсекается в первый месяц работы. Самое оно. |
|
|
19.8.2010, 17:24
Сообщение
#51
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
Мне кажется, надо не просто писать про оторванное от реальности "отказоустойчивое ПО", а проделать колоссальную работу по созданию сложного устройства, которое должно работать годами без обслуживания. То, что я описал, там простенький микроконтроллер AVR и для книги не пойдет. Надо замутить нечто на Linux, ARM какой нибудь навороченный. И оно безусловно свалится очень быстро работая в автономке. Зря считаете, что устройство на контроллере AVR не достойно описания. Какие Вы устройства делали на Linux+ARM? Попробуйте по одному из них (любому, на Ваше усмотрение) составить план статьи (или книги). Какие бы темы Вы охватили? Цитата Вот доведение этого устройства до ума, вылизывание платы, схемы и софта в комплексе в режиме онлайн. А софт, так прямо правка исходников с учетом требований надежности, и наглядной демонстрацией, где, как и почему поправили. Я по профессии занимаюсь именно этим, и именно над софтом. Я, конечно, понимаю, что про правку исходников с наглядной демонстрацией результата Вы пошутили, но складывается впечатление, что Вы не очень знакомы с вопросом. Цитата В итоге, получив по настоящему безотказный дивайс, которые не боится ни минусов, ни плюсов, ни статических разрядов. А в комплекте к нему непробиваемый дизайн и такой же непробиваемый переработанный на низком уровне Linux, на котором можно в Космос полететь. Безотказных девайсов не бывает. Бывают девайсы, которые переживают отказы с минимальными потерями, даже ценой потери работоспособности. Если не секрет, в кокой области применяете устройства под Linux'ом? Цитата PS: Ошибки компиляторов это зверь который удивляет когда горе программист умудряется в течение дня писать в 10 разных средах на семи языках. Тогда это проблема. А когда извините полгода корячишься над одним дизайном где не то, что схему плату, царапины на резисторах запомнил, там ошибки компиляторов неактуальны, потому что при отладке c JTAG контроль идет над содержимым регистров в онлайн режиме, и никто не смотрит на программу, а исключительно на результат. И когда компилятор подсовывает свои левые команды или кривые флаги, это отсекается в первый месяц работы. Не приведете пример ошибки компилятора, выловленной таким способом? |
|
|
20.8.2010, 7:01
Сообщение
#52
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
|
|
|
Гость_MrYuran_* |
20.8.2010, 7:13
Сообщение
#53
|
Гости |
Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет. А вот бывает так: Работает пару лет, а потом вдруг перестаёт... Вот в моей теме есть раздел про тестирование. В настоящее время у нас тестирования ПО как такового вообще нет. То есть проводится тестирование всего изделия в комплексе на соответствие ТУ, РЭ и заявленным параметрам, а отдельно ПО - не тестируется вообще. В "большом" программировании тесты - это основа. То есть, поменяв что-то где-то, можно прогнать серию тестов и убедиться, что нигде ничего не сломалось. Иначе потом это найти будет очень сложно. Вот в связи с этим у меня конкретный вопрос. Как формализовать процедуру тестирования модулей встраиваемого ПО. Выход вижу такой: 1. Должна быть чёткая грань между верхним (платформо-независимым) уровнем и нижним, который привязан к железу. 2. Нижний уровень тестируем в железе, подавая специальные команды и контролируя исполнение осциллографом и др. измерительным оборудованием. 3. Верхний уровень может быть первоначально отлажен и протестирован на ПК, а потом дополнительно - на целевой платформе. Видимо, тоже через какой-то технологический интерфейс или монитор. |
|
|
20.8.2010, 12:25
Сообщение
#54
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет. Ну, например, один из фокусов - предположение о том, что входные данные не будут никогда выходить за некий умозрительно представленный диапазон . Здорово экономит обычно на контроле данных... Применяется даже в авиа - и космических программах... Известен по результатам , из прессы, сообщения об авариях... |
|
|
20.8.2010, 17:37
Сообщение
#55
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
1. Должна быть чёткая грань между верхним (платформо-независимым) уровнем и нижним, который привязан к железу. Есть такая бяка - переполнение стека. Вот ее бы как-то вылавливать наверху - цены б не было. Ну, например, один из фокусов - предположение о том, что входные данные не будут никогда выходить за некий умозрительно представленный диапазон Это не предположение, а "закладка" на случай кидалова. Если программаст не страдает аутизмом. |
|
|
21.8.2010, 11:48
Сообщение
#56
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
Стесняюсь спросить, а какие в программировании могут быть фокусы? Программа или работает при любых комбинациях и над всеми множествами входных данных, или нет. Работоспособность программы и мнение программиста о работоспособности программы - разные вещи. А "фокусами" можно назвать любые приемы профессионала с точки зрения дилетанта. Я уж не говорю о таких вещах как атомарность или volatile (хотя и они у некоторых вызывают непонятки), но ведь и проверка причин сброса при включении тоже может восприниматься как "фокус". Сообщение отредактировал tester - 21.8.2010, 13:42 |
|
|
21.8.2010, 12:20
Сообщение
#57
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
|
|
|
21.8.2010, 13:39
Сообщение
#58
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
Бомба с взрывателем, установленным на случайно выбранное время. Может рвануть, пока программист как раз в кассе у окошка... Добавлю, что вообще все эти "мины", "закладки" и пр. считаю ребячеством и дешевым западлом в попытках отстоять свои чрезмерно завышенные амбиции (практика показывает, что частенько программисты о себе особо высокого мнения). К тому же эти средства обычно приводят к убыткам у совершенно непричастных людей. Я уже сталкивался с "минами" в программах, которые программист заложил на случай кидалова, а потом, после получения гонорара, просто забыл их убрать. Чтобы не было кидалова, нужно, во-первых, уметь общаться с заказчиком, а не соглашаться на первые же его условия "сначала программа, потом деньги"; во-вторых, забыть об амбициях насчет процента с прибыли, а то программист начинает мыслить категорями экономиса: "в первый месяц продастся 10 тыс. устройств, во второй - 20 тыс. и т.д. Ура!"; в-третьих, как это ни печально, следует знать себе цену, а не точить зло на весь мир, что его не оценили по достоинству. А если хирурги начнут свои амбиции через профессию выражать? "Отавлю-ка я зажимы у него в животе, вдруг не расплатится". Или диспетчеры на аэродромах, или строители? |
|
|
21.8.2010, 13:44
Сообщение
#59
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
А если хирурги начнут свои амбиции через профессию выражать? "Отавлю-ка я зажимы у него в животе, вдруг не расплатится". Или диспетчеры на аэродромах, или строители? Однако, кидалово существует и деться от этого некуда. Каждый сам решает, что его устроит. обычно сводится к тому, что кидающий программиста может кидать любого. Потому его устраивают и закладки, если не удалось их избежать. В случае чего, кинет и потребителя - и все на этом. Свалит на того же программиста, если получится. ну или по другому как-то... Этика человека не меняется в разных ситуациях. А лекарство только одно - работать в команде однотипно мыслящих людей. То есть с одинаковым уровнем этики, тогда или все друг друга кидают, или никто никого, в зависимости от уровня этики и морали команды. |
|
|
21.8.2010, 13:57
Сообщение
#60
|
|
Активный участник Группа: Пользователи Сообщений: 41 Регистрация: 15.8.2010 Из: SPb Пользователь №: 197 |
обычно сводится к тому, что кидающий программиста может кидать любого. У каждого своя правда. Поведение заказчика не всегда можно назвать однозначным кидаловом (в наглую редко опрокидывают; чаще это происходит от недоговоренностей насчет кто, кому и что должен), а вот действия программиста по закладке закладок - это однозначное кидалово, причем делается еще до того, как его кинули. В кустарных разработках, обычно, оба хороши (и заказчик и программист). Цитата А лекарство только одно - работать в команде однотипно мыслящих людей. Хе-хе Все в команде мыслят однотипно: "В конце проекта я всех кину!" Ох уж эта молодежь. Оне еще не знают, что чтобы прога упала, закладки не нужны. |
|
|
Текстовая версия | Сейчас: 29.3.2024, 2:50 |