Форум РадиоКот

Собственно, вопрос простой: каким образом достопочтенные коты решают проблемы качества в процессе разработки нетривиальных устройств? Какие используете методики, приемы, инструменты?

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

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

Итак, аксиома: системы со встроенными МК в целом и софт для них в частности должны иметь уровень качества на голову выше, чем принято для обычных десктопных систем. Это очень легко сказать и неимоверно трудно сделать. Кто и как решает эти задачи (и с каким успехом)?

Здесь на форуме человек рассказывал про то, как у него все автоматизировано : разработка программы, тестирование, управление версиями и т.п. Ник его, дай бог память, Goldsmith
А для тех, кто таких наук не превзошел ( как тискающий эти строки ) , остается банальное : вычитывать тексты исходников на свежую голову ( как Чехов ) и тестировать, тестировать... На симуляторе, макете, образце. Все равно 100% гарантии никакая зуперсверхархинаучная система не дает. И ракеты падают, и подлодки тонут...
Я ретроград, мое мнение следует игнорировать неоднократно.

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

Кажется, об этом я здесь уже того... Впрочем, как и стартертопик -- о своем тоже.

мне вообще кажется, что проблема "беспокойства о надежности МК-систем" несколько преувеличена... сдается, что очень мало кто об этом ДЕЙСТВИТЕЛЬНО беспокоится. во всяком случае для бытовых устройств вся забота в пределе заканчивается на возможности быстрого обновления прошивки - иногда даже без ведома пользователя, как в некоторых мобильниках: утром включаешь - оба-на! не работает, т.к. "version of softvare XXX.XXX.XXX upgraded to last version".

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

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

ARV писал(а):сдается, что очень мало кто об этом ДЕЙСТВИТЕЛЬНО беспокоится.

Беспокоятся все. Только тут встает проблема компромисса между отлаженностью и оттестированостью изделия и выходом продукта на рынок, дабы он был конкурентноспособным.
Сейчас жизненный цикл массовых электронных изделий совсем не большой.

Satyr писал(а):

ARV писал(а):сдается, что очень мало кто об этом ДЕЙСТВИТЕЛЬНО беспокоится.

Беспокоятся все. Только тут встает проблема компромисса между отлаженностью и оттестированостью изделия и выходом продукта на рынок, дабы он был конкурентноспособным.
Сейчас жизненный цикл массовых электронных изделий совсем не большой.

я так понял, вы типа возразили мне? но ведь в вашем возражении есть дикое противоречие, которое превращает ВОЗРАЖЕНИЕ в СОГЛАСИЕ
НАДЕЖНОЕ УСТРОЙСТВО нет никакого смысла делать С МАЛЫМ ЖИЗНЕННЫМ ЦИКЛОМ (если это не военное оборудование, конечно). и наоборот: если срок жизни девайса соизмерим со сроком обнаружения багов в нем - ЗАЧЕМ ДУМАТЬ ОБ ИХ ИСПРАВЛЕНИИ? это ничего, кроме затрат не несет - следовательно, на этом можно экономить. и экономят. увы, это реальность, а рассуждения о надежности - лишь способ выбить очередную порцию денег у заказчика/инвестора/спонсора (ну или создать себе имя - диссертации, симпозиумы и т.п.)
нет никакого компромисса - ЕСТЬ ГОТОВОЕ РЕШЕНИЕ: делать [почти] как угодно, лишь бы быстро.

Jack_A писал(а):Здесь на форуме человек рассказывал про то, как у него все автоматизировано : разработка программы, тестирование, управление версиями и т.п. Ник его, дай бог память, Goldsmith

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

Модульное тестирование - да, автоматизировано полностью. Интеграционное - близко к тому. Системное - еще конь не валялся, только собираю материал. Ну а управление версиями автоматизировано уж не один десяток лет, это не бином Ньютона.

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

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

Jack_A писал(а):Все равно 100% гарантии никакая зуперсверхархинаучная система не дает. И ракеты падают, и подлодки тонут...

Верно, достичь 100% так же нереально, как и скорости света - чем ближе подбираешься, тем труднее и дороже следующий шаг. Но и полностью игнорировать проблемы качества на этом основании тоже нельзя.

ARV писал(а): я так понял, вы типа возразили мне? но ведь в вашем возражении есть дикое противоречие, которое превращает ВОЗРАЖЕНИЕ в СОГЛАСИЕ

Нет противоречия. Но нет и этакого намека на максимализм.
"ДЕЙСТВИТЕЛЬНО беспокойство" в смысле полной вылизанности кода вдоль и поперек на предмет отсутствия ошибок сейчас не возможно по маркетинговым соображениям.
Беспокойство сейчас выражается восновном в обеспечении минимизации последствий ошибок и возможности внесения исправлений после передачи потребителю.

У нас разное понимание беспокойства -)))

Satyr писал(а):У нас разное понимание беспокойства -)))

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

других вариантов не встречал и не слышал даже, что они существуют. все сказанное отлично укладывается в мои высказывания, и как-то с натягом - в ваши возможно, где-то в глубине недр фирм-разработчиков сидит какой-нибудь товарищ вроде вас и переживает, что его программа может сбойнуть... но рядом сидит менеджер, который его утешает: "не бзди, напишем в инструкции - так и должно быть, и все! никто не придерется!" и по-моему, так оно и есть. у меня телеку чуть больше 3-х лет - модель считается устаревшей, обновления ПО для него отсутствуют, поддержки вообще никакой нет через сайт... глюки прошивки есть - а поддержки нет.

Satyr писал(а):Вобще, возможность апдейта надо оставлять всегда в том или ином виде.
Пусть это какое то промышленное автономное оборудование, ну уж разъем для SD карточки, дип-свич "обновление" можно прилепить.

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

Goldsmith писал(а):А вот в случае той же бытовой техники все сложнее - если вылезет ошибка в контроллере навороченной стиральной машины или телевизора, организовать исправление будет уже не так просто, не ходить же по квартирам с программатором.

Это делается через сменный носитель. SD/USB дырка и короткий пункт в инструкции -))

Goldsmith писал(а): Написать качественную программу для МК - труд тяжкий в кубе, поскольку, помимо сложности самой по себе программы, мы должны еще и обеспечить среду для ее выполнения (встроенная ОС есть далеко не во всякой разработке), да еще и реализовать это все на языке невысокого уровня - ассемблере или недалеко ушедшем от него по выразительности С.

Я в микроконтроллеры пришел из VС++ и разработки полноценных Виндовс программ. С микроконтроллерами и С просто отдыхаю.

Goldsmith писал(а):если вылезет ошибка в контроллере навороченной стиральной машины или телевизора

У меня есть опыт создания контроллера стиральной машины и программы "с нуля", замечаю, что проблема описанная в теме действительно приувеличина. Мои приборы работают, если и возникают проблемы, процент отказов не выше процента отказов заводских образцов.

Goldsmith писал(а):Если бы у меня хватило ума автоматизировать разработку программ, я бы уже давно включил свой автомат на полную мощность и сгенерировал бы все программы лет на 100 вперед, заработав все деньги и оставив без работы армии программистов, включая орды индийских...

Это лишний раз говорит о том, что интерфейсы сред программирования ещё очень далеки от нормальных. Посредник между умом и софтом это неизвестная ещё пока фигура, формула, программа.
Это ещё и дело языка.. русский, английский - здесь выполняют функцию шахматного поля 8х8, вне которого ни-ни. Это ограничивает восприятие вопроса.
Кроме того, есть связь между мощностью железа(ценой) и решаемой им задачи. Например, одно дело задать два математических и два логических действия МК типа PIC10F.., а другое дело задать ту же задачу монолитному блоку в виде iPAD, который может в идеале общаться голосом с человеком. Да, цена пока слишком велика, для того, что бы на пару простейших функций использовать дорогой, пока ещё, iPAD, но визуализация и голосовые функции могут служить более удобной средой программирования МК.
Мне кажется, что уместно воспринимать iPAD как функциональный и мощный МК, тем более, что у китайцев аналоги этих iPAD стоят около 200 долларов (это 10 дюймовые), а 7-ми дюймовые и того дешевле.

КАР. Китайский 10" планшет на Android - Zenithink Epad ZT-180 (обзор)
Недавно я вертел в руках такой планшетник и меня не покидала мысль, что я держу в руках МК с ЖК и АКБ. Что-то вроде более совершенного и упакованного PIC18F4550.

НАДЕЖНОЕ УСТРОЙСТВО нет никакого смысла делать С МАЛЫМ ЖИЗНЕННЫМ ЦИКЛОМ (если это не военное оборудование, конечно). и наоборот: если срок жизни девайса соизмерим со сроком обнаружения багов в нем - ЗАЧЕМ ДУМАТЬ ОБ ИХ ИСПРАВЛЕНИИ?

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

ARV писал(а):..я так понял, вы типа возразили мне? но ведь в вашем возражении есть дикое противоречие, которое превращает ВОЗРАЖЕНИЕ в СОГЛАСИЕ

Узнаю характер.

Satyr писал(а):Это делается через сменный носитель. SD/USB дырка и короткий пункт в инструкции -))

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

Плюс остается проблема закрытых прошивок, которые не должны попадать в чужие руки.

MIF писал(а): Узнаю характер.

вредный и противный?

Слесарь писал(а): У меня есть опыт создания контроллера стиральной машины и программы "с нуля", замечаю, что проблема описанная в теме действительно приувеличина.

Контроллер стир машины - мелочь, кроха. Какие там проблемы.
Есть у меня проект на МК, исходников 2.8Mb. Да я поручиться могу, что ошибки там точно ЕСТЬ -)))
При том что большинство могут никогда не вылезти, не то что в синтетических тестах.

Goldsmith писал(а): Плюс остается проблема закрытых прошивок, которые не должны попадать в чужие руки.

Это проблема простых устройств с ограниченными ресурсами.
В более менее жирных устройствах не проблема шифрование прошивки стойкими алгоритмами для защиты своей интеллектуальной собственности.
И даже наложение ЭЦП для защиты устройства от влива левой прошивки не от производителя.

MIF писал(а):Это лишний раз говорит о том, что интерфейсы сред программирования ещё очень далеки от нормальных. Посредник между умом и софтом это неизвестная ещё пока фигура, формула, программа.
Это ещё и дело языка.. русский, английский - здесь выполняют функцию шахматного поля 8х8, вне которого ни-ни. Это ограничивает восприятие вопроса.

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

Впрочем, не все так мрачно. Развиваются относительно новые, достаточно выразительные нотации, например, UML. Вот только не очень они спешат добраться до firmware...

MIF писал(а):Недавно я вертел в руках такой планшетник и меня не покидала мысль, что я держу в руках МК с ЖК и АКБ. Что-то вроде более совершенного и упакованного PIC18F4550.

Так по сути оно так и есть - ARM, ЖК и АКБ.

MIF писал(а):Мне кажется, что надёжность связана напрямую с основательностью подхода. То есть, использование освоенных технологий, кодов и т.п.

Логично. Чего стоят хорошие технологии (точнее, их отсутствие), можно оценить на примере славного российского автопрома. Берем исходное сырье, обрабатываем левой задней ногой, не заморачиваясь качеством, и получаем...

Satyr писал(а):Это проблема простых устройств с ограниченными ресурсами.

Конечно. Но такие устройства занимают довольно обширную нишу, игнорировать ее сложно. Так что проблему все равно нужно как-то решать.

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