Jump to content

    

Целостность конфигурации ПЛИС

26 minutes ago, DeadCadDance said:

Это значит что за миллиард часов произойдёт в среднем 9,5 сбоев

Это значит, что 1 отказ происходит в среднем за 12 тысяч лет

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

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

Опять таки, можно оперировать разными понятиями и статистикой. Можно сказать, что девайс включили, а потом выключили на миллиард лет, а потом он сбойнул. Нужно понимать как производилось тестирование: на 100 MHz или на 1MHz. Вероятность обнаружить сбой во втором случае всего в 100 раз меньше. Что тестировалось? Весь тракт данных или отдельно каждый регистр. Пока компания не выдаст методику, по которой происходило тестирование и параметры, FIT будет означать количество тренирующихся в спортзале.

Share this post


Link to post
Share on other sites
12 минут назад, Nick_K сказал:

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

Вот именно. А если оставить только отказы, то MTTF вообще миллионы лет будет

14 минут назад, Nick_K сказал:

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

Меня тоже такая "статистика" мягко говоря смущает.

Поэтому я спрашиваю тут народ, который имеет большой опыт работы с ПЛИС, о РЕАЛЬНОЙ, а не полученной математическим путём, статистике сбоев ПЛИС

Share this post


Link to post
Share on other sites
3 minutes ago, DeadCadDance said:

Поэтому я спрашиваю тут народ, который имеет большой опыт работы с ПЛИС, о РЕАЛЬНОЙ, а не полученной математическим путём, статистике сбоев ПЛИС

Вот вам @RobFPGA ответил по реальной статистике. Я со своей стороны могу сказать, что спроектированная нами система эксплуатируется на ряде ЖД станций и безопасного отказа по вине ПЛИС за последние года 3-4 не было. В данном случае подразумевается глобальная проверка как элементов памяти, так и комбинационных схем.

Share this post


Link to post
Share on other sites
7 минут назад, Nick_K сказал:

отказа по вине ПЛИС за последние года 3-4 не было

Тут ещё такое дело...

Что считать отказом.

 

Вот если у Вас ПЛИСина мониторя CRC обнаружила, что один битик в блоке CRAM "битый" и быстренько перезгрузила конфиг и на работе системе в целом это никак не отразилось - такие отказы у Вас считаются отказами? Счетчики их считают?

Меня интересуют ВСЕ виды сбоев, а не только опасные

Edited by DeadCadDance

Share this post


Link to post
Share on other sites
5 minutes ago, DeadCadDance said:

Что считать отказом.

У нас всё честно. Есть дублированная система из 2х девайсов. Циклически они запускают полную проверку элементов памяти и комбинаторики (понятное дело, что в алгоритмы проверки с самотестированием). После чего обмениваются полученными результатами (по сути некие дампы). Если один из "братьев" находит несовпадение хотя-бы в одном бите, он переходит в безопасный отказ. Никаких восстановлений, исправлений ошибок и т.п.

З.Ы. Забыл добавить, система раз в пол года меняется (железо) на такой же комплект, но после проверки в РЭА. Старый комплект везётся в РЭА, проверяется по новой и возвращается назад как резерв. По сути получается, что система не всё время 24/7 педалила, но комплекты старые остаются и не меняются на другие, соответственно надёжность системи можно оценить в половину времени.

Share this post


Link to post
Share on other sites
24 минуты назад, Nick_K сказал:

отказа по вине ПЛИС за последние года 3-4 не было

Тут ещё зависит что за приложение, в котором Вы используете ПЛИС.

Одно дело какие-то медленные процессы.

А другое дело когда плис молотит на Гигагерцах сложнейшую логику и сдвиг (или пропалание) сигнала даже на 1 мкс на любом из 400  I/O пинов означает катастрофу.

 

 

Edited by DeadCadDance

Share this post


Link to post
Share on other sites
1 minute ago, DeadCadDance said:

А другое дело когда плис молотит на Гигагерцах сложнейшую логикк и сдвиг (или пропалание) сигнала даже на 1 мкс на любой из I/O означает катастрофу.

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

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

Упомянутая мною система работает на 100MHz.

Share this post


Link to post
Share on other sites
В 01.12.2019 в 16:04, Nick_K сказал:

Ну тут Вы загнули уже. В жизни не видел критических систем с гигагерцовыми клоками. Может на Атомных где-то и то сомневаюсь. Обычно все критические системы отличаются надёжностью и относительно медлительностью

А как же системы ведения цели? Есть и другие системы где требуется жесткий реалтайм с маленьким циклом.

У нас, к примеру, время главного цикла 20 мкс

Edited by DeadCadDance

Share this post


Link to post
Share on other sites
On 12/7/2019 at 9:03 AM, DeadCadDance said:

А как же системы ведения цели? Есть и другие системы где требуется жесткий реалтайм с маленьким циклом.

У нас, к примеру, время главного цикла 20 мкс

Согласен, погорячился. Не бывает критических безопасных систем с гигагерцовыми клоками. В случае ведения цели или других "военных" вопросов именно термин безопасность отходит на второй план. Там главное безотказность, что можно достичь... десятичным мажоритированием или ещё каким-то интересным резервированием. Там ведь главное, чтобы оно не потерялось, а то что будет сбой (а он скорее всего будет, потому что мир не идеален + противник может использовать системы подавления), так это особо не колышит. Главное восстановить работу "сбойного" узла, до гипотетического появления сбоя на другом узле.

Короче говоря это всё демагогия.

А вот с точки зрения Вашего этого цикла, то 20 микросекунда - это как-бы и много и в то же время мало. Смотря что нужно достичь, что проверить, где сравнить состояния и т.д. Если это несколько каналов с загруженными Виртексами - то увы этого времени для дублированной системы, не хватит даже для обмена сервисными пакетами или проведения самотестирования, как одно их состояний главного цикла. Тут можно много гадать, но реально, как я понимаю, подойдёт только эксперимент. Реальный с прогоном. А тут таким особо никто не занимается :wink:

Share this post


Link to post
Share on other sites
9 часов назад, Nick_K сказал:

тут таким особо никто не занимается

Понял.

Спасибо за ответ.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 час назад, Koluchiy сказал:

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

"Гладко было на бумаге, а реально откуда не возьмись выросли буераки"©

Теоретически много чего возможно. Только на практике мало чего РЕАЛЬНО полезно и работает

Edited by DeadCadDance

Share this post


Link to post
Share on other sites
On 12/1/2019 at 1:46 PM, DeadCadDance said:

Что считать отказом.

Вот если у Вас ПЛИСина мониторя CRC обнаружила, что один битик в блоке CRAM "битый" и быстренько перезгрузила конфиг и на работе системе в целом это никак не отразилось - такие отказы у Вас считаются отказами? Счетчики их считают?

Меня интересуют ВСЕ виды сбоев, а не только опасные

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

On 12/8/2019 at 10:05 AM, Nick_K said:

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

У нас дублированная система на виртексах и ДСП с циклом 20мкс. Обмен диагностическими словами в 20мкс укладывается спокойно и распознавание проблем и переход на резерв происходит за 3 цикла максимум. Так как управляющее слово на объект уходит каждые 100мкс - это не успевает вызвать негативную реакцию системы.

 

Share this post


Link to post
Share on other sites
On 11/30/2019 at 12:56 PM, DeadCadDance said:

Тоже такая мысль пришла, когда почитал отчёты производителей (интел, ксайлинкс, актель) по надёжности, из которых вытекает, что среднее время работы до первого сбоя у ПЛИС составляет сотни, тысячи и десятки тысяч лет :dash2:

Это не ложь, это просто статистика :)  К химии и физике эти теоретические параметры надежности отношения не имеют. Наработка на отказ равная 10 млн. часов (1141 год) означает, что если включить одновременно 1141 ПЛИС, то за год работы примерно одна выйдет из строя. И под отказом, вроде как, понимается не сбой, а полный отказ микросхемы.

Edited by lembrix

Share this post


Link to post
Share on other sites
В 17.12.2019 в 17:26, lembrix сказал:

И под отказом, вроде как, понимается не сбой, а полный отказ микросхемы.

Если хотя бы один битик в CRAM "перевернулся" из-за прилетевшего из космоса нейтрона - это отказ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now