Уважаемые коллеги, есть ли у кого успешно подготовленный и сданный Заказчику раздел Б1 проекта SCADA "Проектная оценка надёжности системы"? Думал отвертеться, но Заказчик больно въедливый - надо ему что-то написать. Интересен любой имеющийся вариант.

Надежность системы = произведению надежности отдельных компонентов. Берете надежность жесткого диска, ИБП, монитора и перемножаете. Недежность рассчитываете исходя из наработки на отказ (указывается по крайней мере для жеского диска).

Надежность Windows не поддается каким-либо вычислениям

Это высокотехнологичная область знаний...

Я конечно "дико" извиняюсь, но если Вам поможет...См. вложение.
В "лоб" конечно не пройдет, но буду благодарен Вам за любые мнения и улучшения документа по поводу данной проблемы... Вдруг свое изобретете, поделитесь?
2Abysmo:
Шутка понятна. А по делу? Ведь если Ваш постик проанализировать, то выйдет, что ни одна СКАДА (пардон, за мой русский) на платформе W абсолютно не НАДЕЖНА!
Факты в "студию"! Ибо с другими Осями разнообразие жидкое...
Можно в Вашу формулу добавить мой "кусочек"?
P=P_АРМхP_WхP_СКАДА
Есть над чем подумать, не находите?

Спасибо за конструктивный ответ. Если удасться что-то путное родить - обязательно поделюсь.

Насколько понял 2Abysmo: имел ввиду (в ироничной форме ), что расчет надежности выполняется для технических объектов (устройств, единиц, систем ит.п.). Программное обеспечение не является техническим объектом ПО не стареет (физически), не деградирует, не изнашивается. И дело не в ОС. Оно либо работает, либо надо исправлять .

1. Посмотрим, что Abysmo ответит. Может Вы лучше его знаете и он действительно это имел в виду...
2. Кто ж спорит. Но по поводу старения и деградации это Вы зря так, безапелляционно...
3. У Вас, простите, Ос никогда не висла?

Давайте еще раз. Формально Martin должен послать Зака или расчитать надежность сервера с установленной СКАДой?
А если он рассчитает только надежность ПК, не принимая во внимание ИБП, ОСь, саму СКАДУ, то на Ваш взгляд это правильно?
Надежность СКАДЫ=надежность устройства ПК?
Хорошо. Если так нельзя, хотя почему нельзя? То как надо оценивать надежность СКАДы?? Про АРМ понятно, но не АРМом единым...
Вдогонку. Если Вам мои вопросы кажутся простыми. Получается взяли новый комп, более надежный, старую СКАДу, поставили и надежность возросла? Опа!
А надежность контроллера Вы тоже предлагаете учитывать только как технического объекта(без ПО)? Опа2?

1.Может и не это
2. Проводится оценка качества программных средств.
3. Есть такие, Win2k Server Sp2. Единственное НО - условия эксплуатации идеальные (температура, влажность, СГЭП), крутится 1 задача (оперативно-информационный комплекс). Вывод из работы 1 раз в год на ТО сервера, в это время работает резервный. ОСь не слетала.

Если серьезно, для программных средств -
Вероятность безотказной работы P=1-Q/N
где Q - число зарегистрированных отказов;
N- число экспериментов.
Кто бы их проводил? И где взять показатели безотказности и время восстановления ПО? Проводить эксперименты? Заказчику проще, он по статистическим данным может расчеты произвести.
А ГОСТ есть - 28195-89 "Оценка качества программных средств. Общие положения"
Основные положения читаем http://www.i-mash.ru/normatdok/gosty/g_4_3...st_2730195.html


Традиционно проводится расчет надежности системы, для этого строится модель системы, и используются данные изготовителя по безотказности MTBF. Время восстановления и показатели надежности должен заказчик установить в ТЗ, или определено в отраслевых нормативах. Программное обеспечение обычно опускают. ИБП не приравнивайте к ПО, у него MTBF изготовителем дано, это устройство. Если ЗАК хочет расчет ПО пусть нормативный документ приведет, поможет хоть немного


Если взяли новый комп, то почему нет - у него износа пока нет, надежность выше. Правда, есть период приработки. А старая СКАДА - Вы считаете, что у нее за годы программный код изменился, или процессы старения пошли? Как был так и остался. Зато по ней уже есть статистика работы, можно расчет произвести


Вы свой пример посмотрите, где там ПО в "пульте управления"? По ушам читателям проехались? В расчете установили показатели 1) вероятность безотказной работы 2) наработка до отказа. 2-ой показатель, в ходе расчета вообще не рассматривали. Поленились модель нарисовать, рассмотрели только последовательное и параллельное соединение элементов, есть еще комбинированное. Они его и использовали при вводе резервированного реле уровня, но расчет сделали по параллельному элементу.

У меня нет примеров расчета надежности проектируемой системы, считаю по статистическим данным коэфф. готовности систем находящихся в эксплуатации (ИСО 9001:2001 покоя не дает ) Как делаю - ссылка

Спасибо за материальный ответ и по существу!
Странненько, что другие проплывают мимо темы...
1. Вот-вот сами про идеальные условия... ЦОД и серверные не везде на просторах наших есть.
2. Согласен. Но ведь на самом деле мы говорим про программно-аппаратный комплекс. Почему я формулку и накорябал.
3. Опять согласен. Но как например сравнивать только СКАДы или АРМы с ними? Как самому себе ответь на вопрос по надежности?
4. Он много что должен, спора нет. Но какой он бываете и что у него больше - прав или "должен" можно не обсуждать. Отклонимся от темы. За Гостик отдельное гранд-мерси!
5. Да нет. Не в этом направлении. Несовместимость нового железа со старым ПО. И бабай....
6. Да никому я не проезжал. Пример не мой (в авторах нету). Он прост, поэтому привел для Martin, для начала.
А так конечно, ему Вас читать НАДО.
7. Да жаль! Но с другой стороны понятно. Ссылочку не смог открыть....
Еще раз спасибо за конструктивное обсуждение.

Тут вопрос, как выкрутиться? Наши разглагольствования Martin не помогают
Мои предложения - для расчета надежности программных средств нужна средняя наработка между отказами - MTBF. Которую необходимо взять по данным от производителя (я подобных данных не нашел), либо действовать в соответствии с приведенным ГОСТ 28195-89. Что ведет к длительному периоду испытаний и т.д. Думаю что в текущих условиях экономической ситуации это бестолковая трата времени. По формулировке в википедии .
"Для программных продуктов обычно подразумевается срок до полного перезапуска программы или полной перезагрузки операционной системы." Ввести "допущение" Вопрос, на который у меня нет ответа - подвести нормативную базу под это "допущение". Ну а сам расчет - постановка задачи (какие показатели нужны и их количественное значение), составление моделей по функциям системы. Типа - Информационная функция: датчик-контроллер- АРМ; Управляющая: АРМ-контроллер-ИМ и т.д. дальше куча методик в гугле.

Ух, как на народе все сложно! Сначала цифирки ввести, затем галочку снять надо "Установить Яндекс-бар". После чего скачается.
ЗЫ: только серьезно не стоит воспринимать этот "пример", создавал под ситуацию

2CHANt
Спасибо за ссылки - буду вникать ...

1. Это его надо спросить. Похоже он выкрутиться...
2. Я не только подобных данных, но и более простых не нахожу у производителей...
3. Спасибо за прямой ответ.
4. Между АРМ и контроллером еще сеть будет. А этого многие бояться, как потенциально ненадежной инфраструктуры... Даже здесь по форуму такие мысли как "блохи бегают"...
З.Ы. Про получение "злоумышленником" логина и пароля и "вскрытие" СКАДы - вообще молчу, понаписали такого, что АГАТА позавидует...

Вообще говоря иногда выгодно чтобы что-нибудь из "неответственного" оборудования сломалось...

С возвращением в тему!
У нас тут с уважаемым CHANt наметился маленький диалог по поводу Вашего личного мнения. Плязя, низя прояснить?
Про выгодность для инсталлятора, история знает достаточно много жизненных примеров. Вот тока будет ли это интересно широкой публике? Или она поймет только про "сломалось"?
А если Ваш намек в сторону надежности СКАДы, то хотелось бы по-конкретней.. Или Вы всегда ее считали и считаете неответственной?

У кого-нибудь есть мануал по Trace Mode 6 проф ? В обмен могу поделиться МРВ на 511 каналов и ключиком к нему

Мы все делаем по нормам и правилам ГАН. Вы нигде более не найдете такой полной информации как в:
http://www.gan.ru/vestnik/2003/vestnik-01.2003.htm

Евгений Александрович, спасибо за полезную информацию. В Ваших системах, насколько я понимаю, программные средства имеют полностью открытый код куда включается ОС, среда программирования (фирменное обеспечение) и сам проект (среда исполнения и код АСУТП). Мы тут пытались обсудить, как посчитать надежность покупного изделия - SCADA. Вот тут, честно не хватает информации. Как Вы считаете?

Мы применяем методики расчета, сертифицированные ГАН и В\О "Безопасность".
К сожалению, передать другим организациям не имеем права. Но можем провести анализ на основании этих методик.

Методику я не спрашиваю. Интересует, какие функции СУ (для программных средств) исследуете в своих расчетах, и какие показатели надежности, безотказности и т.п. являются результатами расчета по Вашей методике?

В целом процедура проверки надежности проистекает из требования принципа разнообразия. Самый страшный отказ АСУ ТП - это отказ "по общей причине".
Для подтверждения маловероятности отказа "по общей причине" производятся испытания ПО, реализованного на 3-х разных ОС, под 3-мя компилляторами.
Генератор случайных чисел задает входные параметры в ПО, а выход фиксируется в соответствующую базу.
Кроме того генерируется тестовая )ожидаемая) база выходов для последующего сравнения результатов.
Серии по входам варьируются по количеству.
В результате получаем данные для:
1. Робастности ПО;
2. Данные по отказу ПО (либо неправильный отклик, либо АВОСТ).
Далее статистическая обработка результатов (это тривиально) с выдачей показателя робастности и вероятности отказа ПО.

Спасибо за конкретику! По устойчивости функционирования ПО понятно. Жалко, что смайлика "присвистнуть" нет.
А работоспособность ПО как исследуете? По критериям "Функционирование в заданных режимах" и " Обеспечение обработки заданного объема информации". Это меня как эксплуатацию интересует.

Смешно, но мы сами ничего не исследуем. Всё делаем только "из-под палки". Есть требования регулирующих и контролирующих органов: " Сделайте так и так, предъявите нам результаты на МВИ, тогда получите разрешение на применение". Мы требуем от них четкий перечень тестов и проверок, выполняем, но не перевыполняем! Комиссия на МВИ сверяется с перечнями и ТЗ и контролирует только то, что записано в инструкциях и ТЗ.
Наша задача - пройти всё с наименьшими затратами (все эти испытания - весьма дорогое "удовольствие").