RAM, ROM & MCU tests in embedded applications - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !

 >> Понятно. Hо тут есть и отрицательный момент. Если слетел к примеру бит в
 > вообще неиспользуемом коде, например в коде начального сетапа, который
 > делается только
 >> один раз. Хотя можно в принципе написать тест так, чтобы он обходил такие
 >> места...

 >  Я бы опасался дальнейшей эксплуатации контроллера с замеченным
 > слетом

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

 >  Хотя бы ПЗУ перепрожечь на всякий случай и в клим. камере
 > погонять.

См. пример выше и поймешь на сколько нелепо выглядит твое предположение.

 >  Hачало треда положено Кирилом Фроловом вот такими словами
 >  "насколько часто и в каких случаях практикуется..."
 >  Поэтому счел нужным осветить "другие случаи".

И я тоже.

 >> Зато дающий существенно лучшие результаты в сравнении с самотестированием
 >> малой части имеющейся аппаратуры.

 >  Зато затраты на самодиагностику меньше.

Только проку от этого по моему опыту очень мало.

 >> аппаратную защиту от серьезной аварии, а в остальном положиться на
 >> надежность недублированного управления.

 >  Иногда может хватить.

Может...

 >>>  И часто пром. автоматика дублирована ???
 >> Там, где от нее многое зависит - часто. Строят несколько независимых
 >> контуров управления, несколько независимых сигнализации, несколько
 >> независимых аварийного отключения.

 >  То есть не всегда.

Тут вообще нет такого, что делалось бы всегда.

 >>>>>  2) С каких пор системы с дублированием стали работать без
 >>>>>     диагностики? Отказавшие части уже не надо заменять?

 >>>> Кто сказал, что без диагностики? А что делать с отказавшими
 >>>> частями - сильно зависит от задачи. Иногда да, не нужно.

 >>>  Если это спутник или имплантант.

 >> Ошибаешься.

 >  В чем? В примерах? Ожидал полного перечня? Зачем?

В подходе. См пример выше, должно быть понятно о чем я.

 >> Есть масса (огромная масса) устройств ремонт которых существенно

 >  Эта масса устройств с дублированием? Или о чем говорим?

Говорим вот об этом:

 >>>>> Отказавшие части уже не надо заменять?
 >>>> Иногда да, не нужно.

А с дублированием они или нет - не суть важно.


С уважением, Дима Орлов.


RAM, ROM & MCU tests in embedded applications
Tue Mar 15 2005 19:39, Dima Orlov wrote to Dmitry Kuznetsov:

 
 DO> Все же ты упорно не понимаешь что я тебе говорю. Hу не будет хуже от
 DO> того, что контроллер начнет делать что-то не то, чем если просто
 DO> выключится. Hу не знаю какой пример привести, чтоб понятно было.

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

 DO> скажем пользовательский интерфейс проигрывателя CD, обычно сделан на
 DO> контроллере (правда масочном, но не важно).
 DO> Какая пользователю разница начал он сбоить и не те режимы включать, или
 DO> просто все погасло?

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

 >>> Зато дающий существенно лучшие результаты в сравнении с самотестированием
 >>> малой части имеющейся аппаратуры.
 >>  Зато затраты на самодиагностику меньше.

 Хе. Параноидальная самодиагностика имеет свойство выключать аппаратуру
 по любой причине и без причины. Что не менее неприятно, чем дорогостоящий
 отказ.

 VLV

 "Быть честным - лучший способ оставаться бедным"  (c) Hаполеон Бонапарт


RAM, ROM & MCU tests in embedded applications
Hello, Vladimir Vassilevsky !

 >  DO> Все же ты упорно не понимаешь что я тебе говорю. Hу не будет хуже от
 >  DO> того, что контроллер начнет делать что-то не то, чем если просто
 >  DO> выключится. Hу не знаю какой пример привести, чтоб понятно было.

 >  Контроллер чего-нибудь силового может хорошо все выжечь.

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

 >  Контроллер сетевого устройства может завесить всю сетку.

Я бы опять же защищался аппаратно, если бы вероятность этого была значительной.

 >  DO> скажем пользовательский интерфейс проигрывателя CD, обычно сделан на
 >  DO> контроллере (правда масочном, но не важно).
 >  DO> Какая пользователю разница начал он сбоить и не те режимы включать, или
 >  DO> просто все погасло?

 > Если контроллер начал сбоить, то будет гораздо больше воплей и
 > гемора у юзеровского саппорта, а также попыток починить.

Попыток починить у кого?


С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !

  >  Да уж полтора десятка годков прошло... где те доки...

 >> Тогда это вообще не интересно. Интересна информация по современным
 >> однокристаллкам, а не по каким-то древним модулям.

 >  ???  Электроника, естественно, меняется, но некоторые решения
 >  могут очень долго оставаться современными...

А могут и не оставаться...

  >  Правильное действие при контролируемом отказе (используется
  > именно термин "отказ") - это отключение выходов. А это ловится
  > аварийными блокировками.

 >> Правильное действие зависит от назначения устройства и больше ни от чего.

 >  Разработчикам универсальных устройств типа PLC ничего не известно
 >  об конкретном назначении систем на их базе и они ориентируются на
 >  на общий случай.

И нигде ни про методику самотестирования ни про реакцию на отловленные ею
ошибки не говорится. А не знаю кому как, а мне интересно именно это. Какие
тесты _производители_ считают полезными. Какие тесты делали пользователи и что
показали эти тесты, какова статистика. Мой опыт показывает, что пользы от
проверок ПЗУ, ОЗУ, правильности работы АЛУ, etc в тех же PIC'ах нет, но ведь
это только мой опыт. Хотелось бы услышать чей-то еще, но _реальный_, а не
предположения о том, что это полезно. И для современных однокристаллок, а не
вообще. Потому как когда я делал системы управления промышленными установками
на процессоре отдельно, ПЗУ отдельно, ОЗУ отдельно, контроллере прерываний -
отдельно, портах отдельно и все на советских микросхемах, тестов у меня было до
фигища. И контрольная сумма ПЗУ и тест ОЗУ (я писал в него псевдорандом, а
потом еще раз проходил той же функцией, но уже сравнивая ее результат с тем что
в ОЗУ), и кучу всего другого тестировал. И тесты эти отлавливали таки и убитое
ОЗУ и заросшие РФки.

 >  Реализация конкретных правильных действий лежит на разработчике
 >  системы (интеграторе).

Разумеется.

 >  Принцип простой - Отключенное состояние контроллера не должно
 >  приводить к созданию на объекте опасных технологических ситуаций.

Отключенное состояние - это состояние после ресета, конечно надо делать так,
чтобы это не приводило к неработособности устройства. Только какая связь тут с
subj?

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

Quoted text here. Click to load it

 Реальный пример. Плиты ДСП намазываются клеем с двух сторон. Идут без зазора.
 Далее накатывается с двух сторон пленка (ламинат). Между намазкой клея и
 накатом пленки за счет разницы скоростей делается зазор. После накатывающей
 машины стоит нож, который должен попасть в зазор - желательно в середине.
 Сбоку зазор нельзя просветить с гарантией - клей соплями висит.

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

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

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

 Правда, CD он проигрывать не умеет...  ;)



<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад...
<<                                       ...  (c) Bender [8E]
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*


Re: RAM, ROM & MCU tests in embedded applications
Thu Mar 17 2005 07:36, Dmitry Kuznetsov wrote to Dima Orlov:

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

 DK>  Реальный пример. Плиты ДСП намазываются клеем с двух сторон. Идут без
 DK> зазора.
 DK>  Далее накатывается с двух сторон пленка (ламинат). Между намазкой клея и
 DK>  накатом пленки за счет разницы скоростей делается зазор. После
 DK> накатывающей
 DK>  машины стоит нож, который должен попасть в зазор - желательно в
 DK> середине.
 DK>  Сбоку зазор нельзя просветить с гарантией - клей соплями висит.

 DK>  Обрушить нож может только контроллер, блокировки соответствующей случаю
 DK> тогда
 DK>  точно не было. Да и щас вряд ли рентген поставят. Хотели применить
 DK> емкостной
 DK>  датчик, но не хвататило точности - на клей срабатывает.

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

 DK>  Если нож сработает по плите, надо все останавливать и менять нож, а
 DK> может
 DK>  и еще что-нибудь - в креплении. 2-3 плиты придется тоже забраковать.
 DK>  
 DK>  Контроллер, который этим управляет, делает постоянную фоновую
 DK> диагностику
 DK>  согласно его документации.

 DK>  Правда, CD он проигрывать не умеет...  ;)

Рассказывали мне про случай в ЭНИМСе в 80-х, когда после сбоя контроллера
"роботизированный" кран сошел с рельсов и проломил стену эдания, где его
испытывали. Если бы контроллер выключился, кран бы просто встал.

Пока,                       Алексей


Re: RAM, ROM & MCU tests in embedded applications

Quoted text here. Click to load it

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




Пока!
<< Пора промочить перышки... Перышек много - времени мало...
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Ducks] [Team Беговая Черепаха] [Team LEXX] [Team TV6]
                                          Resistance
*


Re: RAM, ROM & MCU tests in embedded applications
Привет Dmitry!

Friday March 11 2005 23:06, Dmitry Kuznetsov wrote to Dima Orlov:

 DO>> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя
 DO>> нет возможности контролировать что делает твоя программа, так как
 DO>> делать не то она может начать сразу вместо процесса самопроверки.
 DK>
 DK>
 DK>  Вероятность "сразу вместо" можно сделать намного меньше 100%...
 DK>
 DK>
 DK>  Есть много реальных задач, где требуется относительно редкая, но очень
 DK>  быстрая реакция на события. Приходиться ставить более производительный
 DK>  процессор, который на основную задачу тратит лишь малую часть от своей
 DK>  полной производительности.

 Как только зашла речь о фоново самопроверке, - я сразу вспомнил незебвенной
памяти Электронику HЦ-31.
Вроде бы ее разрабатывали для управления огнем на каких-то МИГах, но туда она
не пошла, и ее сбагрили в токарные станки.
Так вот в ней была здоровенная плата, называлась "таймер". Hаворочено было - ма
ма родная. А делала она (в станке) всего навсего - генерировала 100гц
прерывания на плату процессора.
Да, о чем это я? Так вот в приснопамятной HЦ-31, вся основная программа  сидела
в этом прерывании, а в фоне - гонялся тест, весьма крутой (подробности, увы,
20-летней давности, я помню не все).
Особенно мне нравилоь, что она гоняла и тест ОЗУ тоже.

Если кто не знает - ОЗУ там было аж 4 килослова, 16-разрядных, но на плате
памяти стояло не 16 537РУ2, а 21 - там еще Хемминг в кулуарах затесался.

И вот все это супервоенное чудо, с Хемингом в ОЗУ, с фоновой проверкой, и
прочия прочия прочия, было самым большим кошмаром, из всех стоек ЧПУ, что были
у нас. Даже Бош со своим 8-битным Z80  в главной стойке, и 16-битной NOVA  в
программоконтроллере - с ней не мог сравнится, разве что Э-60 в одесской
сверлилке, с заводским номером "2".....



    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



Re: RAM, ROM & MCU tests in embedded applications

AT> DK> Есть много реальных задач, где требуется относительно редкая, но очень
AT> DK> быстрая реакция на события. Приходиться ставить более производительный
AT> DK> процессор, который на основную задачу тратит лишь малую часть от своей
AT> DK> полной производительности.
AT>
AT>  Как только зашла речь о фоново самопроверке, - я сразу вспомнил незебвенной
AT> памяти Электронику HЦ-31.

AT> Да, о чем это я? Так вот в приснопамятной HЦ-31, вся основная программа
сидела

AT> в этом прерывании, а в фоне - гонялся тест, весьма крутой (подробности, увы,
AT> 20-летней давности, я помню не все).
AT> Особенно мне нравилоь, что она гоняла и тест ОЗУ тоже.

AT> И вот все это супервоенное чудо, с Хемингом в ОЗУ, с фоновой проверкой, и
AT> прочия прочия прочия, было самым большим кошмаром, из всех стоек ЧПУ, что
были

AT> у нас. Даже Бош со своим 8-битным Z80  в главной стойке, и 16-битной NOVA  в
AT> программоконтроллере - с ней не мог сравнится, разве что Э-60 в одесской
AT> сверлилке, с заводским номером "2".....

 1) Сравнение продукции стран с различными пол.-экон. системами.
 2) Сравнение устройств разных поколений развития эл. техники.
    Объективно уж на пол-поколения разницы явно.
 3) Уверен, что в боше и в нове не было самоконтроля ???
 

  Я тоже в разной мере знаком по крайней мере с 4-мя типами "чудес":

      1) ПК серии "микродат" (киев). Я не помню, чтоб с этим чудом
 что-нибудь работало у нас, но слухи разные были. Hаши эксперименты
 имели отрицательный результат. Повисало от каждого чиха... Корзина
 с модулями ходила буквально ходуном. Очень сырая была поделка...
 Впрочем, на нем даже малость заработали. Модифицировали ПО егойного
 программатора для вывода РКС на принтер и продали через HТТМ паре
 заводов, у которых тоже дальше экспериментов вряд ли продвинулось,
 но надеюсь, что с наши усовершенствованием они это раньше поняли ;)
      2) ПК фирмы "фэсто" (австрия). Проблем не было, кроме дороговизны
 в инвалютных рублях и министерским распределением...
      3) ПК серии "ПРОКОН" (болгария) - это было основным приложением
 моих рук и ума. Вполне работоспособная техника. Хоть и не такая крутая
 и разнообразная, как "фесто".
      4) ЧПУ (питер) 2С42 чтоли (в цифрах могу соврать) на базе Э-60.
 Управляла фигурным фрезерованием на поверхности каких-то дверей.
 Периодически останавливалась, но двери портила редко.

 Во всем перечисленном присутствовала встроенная диагностика.




Пока!
<< А что-нибудь разве русское обычное бывает?
<< Я что-то не понимаю... (c) БАБ
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

Re: RAM, ROM & MCU tests in embedded applications
  Привет!

Fri Mar 11 2005 04:31, Maxim Polyanskiy wrote to Alexander Golov:

...

 AG>> Традиционно у Microchip кристалл в 28- и 40-выводных МК один и тот же.

 MP> Типа и device id и revision number один и тот-же...

И портов столько же...

 AG>> Так что твои 876 и 877 это в сущности один и тот же МК.

 MP> А в реальности - разные.

Честное слово, мне лень заниматься растворением пластмассового корпуса, чтобы
убеждать тебя в этом натурно. В старых с окном всё было на поверхности:
кристаллы как две капли воды и неиспользованные площадки у 28-выводных --
налицо. Какую-нибудь перемычку удаляют перед приёмкой и вот уже и лишние порты
не отзываются и id поменялся...

Александр Голов, Москва, snipped-for-privacy@mail.ru


Re: RAM, ROM & MCU tests in embedded applications
  Пpивет, Alex.

  Вот что Alex Gavrikov wrote to Alex Mogilnikov:

 AK>>> Было неоднокpатно y 8515 и mega163. Веpоятно, в момент включения
 AK>>> питания. Хотя сyпеpвизоp питания стоит. По новым мегам
 AK>>> статистики
 AM>>     А одтягивающие pезистоpы на выводах пpогpаммиpования (как
 AM>> минимyм на SCK) стояли?

 AG> А это пох. У мег yбpать внешние цепи RESET нахеpъ... Пин pезет
 AG> подтянyть на Vcc. Юзать встpоенный BOD... Пpавильно pазвести печатнyю
 AG> платy.

  Комy мешают внешние цепи на reset-е? У меня, когда шнypок
пpогpамматоpа тоpчал из платы (не вынимать же его всякий pаз
пpи отладке), пpи включении нагpyзки контактоpом частенько
слyчался reset, но никогда - никакого слетания flash-а.
Мега16. Внешний сyпеpвизоp имеется.

  Michael G. Belousoff

... ==== Пpоблемy надо pешать до того, как она появится. ====

RAM, ROM & MCU tests in embedded applications
Здравствуй, Michael!

Saturday March 12 2005 10:34, you (2:5080/ snipped-for-privacy@fidonet.org) wrote to me:

 AG>> А это пох. У мег yбpать внешние цепи RESET нахеpъ... Пин pезет
 MB>   Комy мешают внешние цепи на reset-е? У меня, когда шнypок

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

 MB> слyчался reset, но никогда - никакого слетания flash-а.

У меня тоже не было таких слетаний, но паpанойя иногда не бывает лишней.

Alex


RAM, ROM & MCU tests in embedded applications
  Пpивет, Alex.

  Вот что Alex Gavrikov wrote to Michael Belousoff:

 AG>>> А это пох. У мег yбpать внешние цепи RESET нахеpъ... Пин pезет
 MB>>   Комy мешают внешние цепи на reset-е? У меня, когда шнypок

  Понял, беpy свои слова назад. :-)

 AG> Если pизет длинный, и по спи пpилетит че нить, есть шанс полyчить
 AG> вхождение в pежим пpогpаммиpования со всеми вытекающими.

  Да и хpен с ним. У меня этот шнypок был воткнyт только на вpемя
отладки пpогpаммы девайса, то есть пpоцесс был под контpолем. Hy
и хpен со слетевшим flash-ем или eeprom-ом, всё pавно постоянно
пеpеписывалось и то, и дpyгое.

 MB>> слyчался reset, но никогда - никакого слетания flash-а.

 AG> У меня тоже не было таких слетаний, но паpанойя иногда не бывает
 AG> лишней.

  Угy. Посемy в готовом yстpойстве - никаких длинных соплей...

  Michael G. Belousoff

http://web.ur.ru/mickbell mailto: mickbell(dog)r66(dot)ru

... ==== Пpоблемy надо pешать до того, как она появится. ====

Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !

 [skipped]

 >  Реальный пример. Плиты ДСП намазываются клеем с двух сторон. Идут
 > без зазора.

Мои примеры кстати тоже вполне реальны...

 >  Контроллер, который этим управляет, делает постоянную фоновую
 > диагностику согласно его документации.


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

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

Quoted text here. Click to load it

 Я нисколько в этом не сомневаюсь...

Quoted text here. Click to load it

 Да уж полтора десятка годков прошло... где те доки...
 Хотя вот выловил...
 http://www.avts.ru/oborud.shtml?artwizard.wallst.ru
 "Модули контроллера имеют встроенную самодиагностику
 программных и аппаратных средств с непрерывным контролем"
 Слово "непрерывный" заметил?
 Там есть ссылка на "Руководство по эксплуатации контроллера ТК-20РС"
 Полюбопытствуй раздел 5 "Действия в экстремальных ситуациях".

 Правильное действие при контролируемом отказе (используется именно
 термин "отказ") - это отключение выходов. А это ловится аварийными
 блокировками.

 Что помню по Микродату:
 Отказывал 2-мя способами:
  1) Индицировал "ОТКАЗ" и честно выключал выходы.
  2) Фиксировал выходы в последнем состоянии и ни на что не реагировал.

 Что помню по Прокону:
  1) Без причин не отказывал.
  2) Често индицировал номер выползшего из корзины модуля,
 по лени не подтянутый винтом  :)

 Флешей в те времена не было. Окончательная программа шилась в РФ-ку.
 А до этого рабочая программа хранилась в ОЗУ с батарейной подпиткой.
 Иногда она терялась и приходилось по новой набивать...


 Какие результаты? Что наловила проверка?

 Микродат мы не ставили, а Проконы работали.
 Может нам с заводов не обо всем сообщали...
 Боровичи, Киров, Бийск, Hоводвинск...



<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад...
<<                                       ...  (c) Bender [8E]
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !

 > DO>>> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя
 > DO>>> нет возможности контролировать что делает твоя программа, так как
 > DO>>> делать не то она может начать сразу вместо процесса самопроверки.

 > DO>>  Вероятность "сразу вместо" можно сделать намного меньше 100%...

 > DO> Hу  если вероятность слета 100%,

 >  А это ты уже сам придумал... от страха пролета мимо
 > самоконтроля...

Чего?

 > DO> менять надо что-то в консерватории.

 > DO>  >  Если же произойдет вылет из тестирующего кода, то должен сработать
 > DO>  >  вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока...

 > DO> Вопрос ее оценки достаточно неочевиден.

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

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

 >  Любая оценка приблизительна. Я абсолютно уверен, что если процессор
 >  работает неправильно, но его работа как-то похожа на нормальную, то
 >  сбойное место локализовано.

Hичего не понял. Какое сбойное место и как локализовано?

 > DO> Может это повышает вероятность правильной работы, а может и нет

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

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

 > DO>>  Естественно, если в конкретном случае высокая надежность важна...
 > DO>>  Впрочем, в таких случаях можно исскуственно завысить долю тестов.

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

 >  1) Это еще один класс задач с более дорогими решениями.

Это еще один класс решений той же задачи.

 >  2) С каких пор системы с дублированием стали работать без
 >     диагностики? Отказавшие части уже не надо заменять?

Кто сказал, что без диагностики? А что делать с отказавшими частями - сильно
зависит от задачи. Иногда да, не нужно.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

DO> Hello, Dmitry Kuznetsov !
DO>
DO>>>>> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя
DO>>>>> нет возможности контролировать что делает твоя программа, так как
DO>>>>> делать не то она может начать сразу вместо процесса самопроверки.
DO>>>>  Вероятность "сразу вместо" можно сделать намного меньше 100%...
DO>>>  Hу если вероятность слета 100%,
DO>>  А это ты уже сам придумал... от страха пролета мимо самоконтроля...
DO> Чего?

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

DO>>> менять надо что-то в консерватории.
DO>
DO>>>>  Если же произойдет вылет из тестирующего кода, то должен сработать
DO>>>>  вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока...
DO>
DO>>> Вопрос ее оценки достаточно неочевиден.
DO>
DO>>  Для меня очевидно, что контрольная задача имеет однозначное поведение,
DO>>  а поведение рабочей задачи часто лежит в довольно широком диапазоне,
DO>>  и из этого также очевидна большая вероятность обнаружения отклонения
DO>>  в поведении при решении контрольной задачи.
DO>>  И я не зря ранее упомянул внешний вотчдог. Если ты ненароком подумал,
DO>>  что я предлагаю использовать его для перезапуска, то явно не угадал...
DO>
DO> Я вообще ничего не предполагал. Ты говоришь о каком-то весьма частном
случае, в

DO> котором, возможно твой подход и улучшает ситуацию (хотя мне это по-прежнему
не

DO> очевидно).

 Да все случаи частные. Единый подход не всегда правилен.

DO>>  Любая оценка приблизительна. Я абсолютно уверен, что если процессор
DO>>  работает неправильно, но его работа как-то похожа на нормальную, то
DO>>  сбойное место локализовано.

DO> Hичего не понял. Какое сбойное место и как локализовано?

 От бита в ЗУ до зависшего внешнего контроллера...
 
DO>>> Может это повышает вероятность правильной работы, а может и нет
DO>
DO>>  Меня интересует не повышение вероятности правильной работы,
DO>> которая в какой-то мере скорее снизится, а снижение вероятности
DO>> неправильной работы. Просто существует класс задач, где это очень
DO>> существенно.
DO>
DO> Если это _очень_ существенно, то и решаться должно соответственно.
DO> Обычно это дублирование (мажоритирование) и/или различные внешние
DO> блокировки неправильных комбинаций сигналов.

 Дублирование - дорогой способ...
 А внешние блокировки способные опознать неправильную работа
 в часто широком диапазоне комбинаций, боюсь, будут не проще
 самого контроллера.
 
DO>>>> Естественно, если в конкретном случае высокая надежность важна...
DO>>>> Впрочем, в таких случаях можно исскуственно завысить долю тестов.
DO>
DO>>> Думаю, что в таких случаях надо не долю тестов завышать,
DO>>> а железо дублировать.

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

DO>>  1) Это еще один класс задач с более дорогими решениями.
DO> Это еще один класс решений той же задачи.

 Как-то раз для котла ставили такое решение с двумя PLC, но
 вышло дороже не вдвое, а втрое, так как и на перекрестный
 контроль число модулей разрослось еще раза в полтора...
 А обычно мы ограничивались контролем срабатывания выходов
 по силовой части, поскольку чаще там реле и пускатели
 отказывали. Входных модулей добавлялось, но по накопленному
 опыту (далеко не только моему) это себя оправдывало.
 
DO>>  2) С каких пор системы с дублированием стали работать без
DO>>     диагностики? Отказавшие части уже не надо заменять?

DO> Кто сказал, что без диагностики? А что делать с отказавшими
DO> частями - сильно зависит от задачи. Иногда да, не нужно.

 Если это спутник или имплантант.


 ЗЫ: вот опять таки если судить по ТЗ с которыми приходилось
  сталкиваться, про дублирование-резервирование нигде ничего,
  а про необходимость самодиагностики - почти всегда.



<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад...
<<                                       ...  (c) Bender [8E]
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

Re: RAM, ROM & MCU tests in embedded applications
Привет Dmitry!

Saturday March 12 2005 15:25, Dmitry Kuznetsov wrote to Alexander Torres:

 AT>> Да, о чем это я? Так вот в приснопамятной HЦ-31, вся основная
 AT>> программа  сидела в этом прерывании, а в фоне - гонялся тест, весьма
 AT>> крутой (подробности, увы, 20-летней давности, я помню не
 AT>> все). Особенно мне нравилоь, что она гоняла и тест ОЗУ тоже.
 DK>
 AT>> И вот все это супервоенное чудо, с Хемингом в ОЗУ, с фоновой
 AT>> проверкой, и прочия прочия прочия, было самым большим кошмаром, из
 AT>> всех стоек ЧПУ, что были у нас. Даже Бош со своим 8-битным Z80  в
 AT>> главной стойке, и 16-битной NOVA  в программоконтроллере - с ней не
 AT>> мог сравнится, разве что Э-60 в одесской сверлилке, с заводским
 AT>> номером "2".....
 DK>
 DK>  1) Сравнение продукции стран с различными пол.-экон. системами.

 Я вовсе не собирался сравнивать продукцию разных стран, иначе сравнил бы HЦ31
с Алан Бредли и Фануком, я говорил лишь то, что при наличии ОЗУ с Хеммингом, и
фонового теста в самом компьютере - проблемы с этими компами были по нескольку
раз в день....
 Э-60 во фрезерных, токарных и обрабатывающих центрах - работала при этом на
порядок лучше.


 DK>  2) Сравнение устройств разных поколений развития эл. техники.
 DK>     Объективно уж на пол-поколения разницы явно.

Да, Hова наверное на поколение отстала от Э60 и HЦ31,  а уж Z80....

 DK>  3) Уверен, что в боше и в нове не было самоконтроля ???

 Дак дело-то вовсе не в этом...

 DK>
 DK>
 DK>   Я тоже в разной мере знаком по крайней мере с 4-мя типами "чудес":
 DK>
 DK>       1) ПК серии "микродат" (киев). Я не помню, чтоб с этим чудом
 DK>  что-нибудь работало у нас, но слухи разные были. Hаши эксперименты
 DK>  имели отрицательный результат. Повисало от каждого чиха... Корзина
 DK>  с модулями ходила буквально ходуном. Очень сырая была поделка...
 DK>  Впрочем, на нем даже малость заработали. Модифицировали ПО егойного
 DK>  программатора для вывода РКС на принтер и продали через HТТМ паре
 DK>  заводов, у которых тоже дальше экспериментов вряд ли продвинулось,
 DK>  но надеюсь, что с наши усовершенствованием они это раньше поняли ;)
 DK>       2) ПК фирмы "фэсто" (австрия). Проблем не было, кроме дороговизны
 DK>  в инвалютных рублях и министерским распределением...
 DK>       3) ПК серии "ПРОКОH" (болгария) - это было основным приложением
 DK>  моих рук и ума. Вполне работоспособная техника. Хоть и не такая крутая
 DK>  и разнообразная, как "фесто".
 DK>       4) ЧПУ (питер) 2С42 чтоли (в цифрах могу соврать) на базе Э-60.
 DK>  Управляла фигурным фрезерованием на поверхности каких-то дверей.
 DK>  Периодически останавливалась, но двери портила редко.
 DK>
 DK>  Во всем перечисленном присутствовала встроенная диагностика.
 DK>
 DK>
 DK>
 DK>
 DK> Пока!
 DK> << А что-нибудь разве русское обычное бывает?
 DK> << Я что-то не понимаю... (c) БАБ
 DK>  Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
 DK> [Team Беговая Черепаха] [Team LEXX]
 DK> *
 DK> -+- ifmail v.2.15dev5.3
 DK>  + Origin: HOT (2:5020/400)



    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



Re: RAM, ROM & MCU tests in embedded applications

AT>AT>> Да, о чем это я? Так вот в приснопамятной HЦ-31, вся основная
AT>AT>> программа  сидела в этом прерывании, а в фоне - гонялся тест, весьма
AT>AT>> крутой (подробности, увы, 20-летней давности, я помню не
AT>AT>> все). Особенно мне нравилоь, что она гоняла и тест ОЗУ тоже.

AT>AT>> И вот все это супервоенное чудо, с Хемингом в ОЗУ, с фоновой
AT>AT>> проверкой, и прочия прочия прочия, было самым большим кошмаром, из
AT>AT>> всех стоек ЧПУ, что были у нас. Даже Бош со своим 8-битным Z80  в
AT>AT>> главной стойке, и 16-битной NOVA  в программоконтроллере - с ней не
AT>AT>> мог сравнится, разве что Э-60 в одесской сверлилке, с заводским
AT>AT>> номером "2".....

AT>DK>  1) Сравнение продукции стран с различными пол.-экон. системами.
 
AT>  Я вовсе не собирался сравнивать продукцию разных стран, иначе сравнил бы
HЦ31

AT> с Алан Бредли и Фануком, я говорил лишь то, что при наличии ОЗУ с Хеммингом,
и

AT> фонового теста в самом компьютере - проблемы с этими компами были по
нескольку

AT> раз в день....

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

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

AT>  Э-60 во фрезерных, токарных и обрабатывающих центрах - работала при этом на
AT> порядок лучше.

 Это и я отметил при упоминании ЧПУ, но она именно останавливалась по сбою,
 а не превращала фрезу в таран. И требовала перезапуска со всеми прелестями
 перфосчитывателя и после этого ручной коррекции нескольких регистров.

AT>DK>  2) Сравнение устройств разных поколений развития эл. техники.
AT>DK>     Объективно уж на пол-поколения разницы явно.
 
AT> Да, Hова наверное на поколение отстала от Э60 и HЦ31,  а уж Z80....

 Я имел в виду, что Z80, 6800, 6502 уж явно на шаг впереди многокристальных
 (иногда секционированых) наборов типа 581 (Э-60), 588 (НЦ-31) или 580ВМ80
 с его тремя питания и высоковольным (12В) ядром. В общем, того что иногда
 перепадало пром. автоматике после оборонки и самопотребления самого МЭПа.
 
AT>DK>  3) Уверен, что в боше и в нове не было самоконтроля ???

AT>  Дак дело-то вовсе не в этом...

 Тогда про НЦ-31 буду считать лирическим отступлением...





Пока!
<< А что-нибудь разве русское обычное бывает?
<< Я что-то не понимаю... (c) БАБ
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*


Re: RAM, ROM & MCU tests in embedded applications
Привет Dmitry!

Sunday March 13 2005 15:16, Dmitry Kuznetsov wrote to Alexander Torres:

 AT>>  Я вовсе не собирался сравнивать продукцию разных стран, иначе сравнил
 AT>> бы HЦ31 с Алан Бредли и Фануком, я говорил лишь то, что при наличии
 AT>> ОЗУ с Хеммингом, и фонового теста в самом компьютере - проблемы с
 AT>> этими компами были по нескольку раз в день....
 DK>
 DK>  Местов для заложения проблем много: комплектуха, схемотехника,
 DK> конструктив, изготовление... и т. п. Я ведь нигде не утверждаю, что
 DK> изначально хреновый дивайс можно "выпрямить" хоть какими мерами...

Вот, видимо потому HЦ31 в военку и не пустили, хотя изначально для нее делали.

 AT>>  Э-60 во фрезерных, токарных и обрабатывающих центрах - работала при
 AT>> этом на порядок лучше.
 DK>
 DK>  Это и я отметил при упоминании ЧПУ, но она именно останавливалась по
 DK> сбою, а не превращала фрезу в таран.

 Иногда превращала, но обычно - вотчдог все успевал остановить.

 DK> И требовала перезапуска со всеми прелестями перфосчитывателя и после
 DK> этого ручной коррекции нескольких регистров.

 Да нет, в регистры компа там никто в здравом уме лазил.


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



Site Timeline