Проектирование и внедрение ИТ систем

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

четверг, 3 ноября 2011 г.

Пишем ТЗ: Требования к надежности

Этот раздел на вой взгляд самый не нужный в современных АС общего назначения, то есть 90-а% всех АС разрабатываемых сейчас.

2.6.1.4. В требования к надежности включают:

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

И вот почему — потому что надежность АС «в общем» на данный момент обеспечивается следующими надежностью следующих элементов:

  1. Инфраструктурой (здание, помещение, кондиционирование, электропитание)
  2. Сетью (коммутаторы, маршрутизаторы, системы хранения данных и тп)
  3. Железо или формально — КТС (сервера, Диски и тп)
  4. ОС, СУБД, файловые системы и прочее сопутствующее ПО
  5. Языки программирования и платформы разработки
  6. и НАКОНЕЦ — ваше программирование. И то, на этот пункт влиять никак нельзя в силу всего того что ограничивает сверху -)

Думаю теперь понятно, что если не брать разработку системы управления самолетом «целиком», то рядовая проектная команда внедряющая типовой программный продукт, будь то SAP, или Exchange, никоим образом на надежность АС влиять не может.


И соответственно, предъявлять требования в ТЗ к надежности глупо, ибо надежность определяется тем что купим и поставим. Но некоторые упертые заказчики желают чтобы это требование в ТЗ було. Ну требуют, значит будет:


Специальные требования к надежности технических средств АС не предъявляются. Сроки службы и среднее время наработки на отказ определяются следующими характеристиками:

  • (звоните своему вендору и спрашиваете какие параметры надежности (наработки на отказ) технических средств АС они декларируют)
  • характеристиками используемых для построения АС технических средств

и добиваете
На стадии «ввод в действие» должен производиться анализ отказов и неисправностей АС и предприниматься меры по их предупреждению и устранению.


————————————————————
Есть еще мнение, что надежность:

  • не относится к отказоустойчивости,
  • не относится к катастрофоустойчивости

А надежность относится к такому показателю как наработка «железа» на отказ. То есть железками которые есть на рынке.

Требования к надежности

4.1.3.1. Состав показателей надежности для системы в целом

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

Надежность должна обеспечиваться за счет:

— применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;

— своевременного выполнения процессов администрирования Системы;

— соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

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

Время устранения отказа должно быть следующим:

— при перерыве и выходе за установленные пределы параметров электропитания — не более 30 минут.

— при перерыве и выходе за установленные пределы параметров программного обеспечением — не более 2 часов.

— при выходе из строя — не более 4 часов.

Система должна соответствовать следующим параметрам:

— среднее время восстановления 2 часов — определяется как сумма всех времен восстановления за заданный календарный период, поделенные на продолжительность этого периода;

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

При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:

— сбой в электроснабжении сервера;

— сбой в электроснабжении рабочей станции пользователей системы;

— сбой в электроснабжении обеспечения локальной сети (поломка сети);

— ошибки Системы Text Mining, не выявленные при отладке и испытании системы;

— сбои программного обеспечения сервера.

4.1.3.3. Требования к надежности технических средств и программного обеспечения

К надежности оборудования предъявляются следующие требования:

— в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;

— применение технических средств соответствующих классу решаемых задач;

— аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев.

К надежности электроснабжения предъявляются следующие требования:

— с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация серверов источником бесперебойного питания с возможностью автономной работы системы не менее 20 минут;

— система должна быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;

— должно быть обеспечено бесперебойное питание активного сетевого оборудования.

Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:

— предварительного обучения пользователей и обслуживающего персонала;

— своевременного выполнения процессов администрирования;

— соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

Надежность программного обеспечения подсистем должна обеспечиваться за счет:

— надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;

— проведением комплекса мероприятий отладки, поиска и исключения ошибок.

— ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.

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

Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации — по методике Разработчика, согласованной с Заказчиком.

studopedia.org — Студопедия.Орг — 2014-2019 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.003 с) .

Требования к надежности программного обеспечения;

Перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности технических средств и программного обеспечения

Требования к надежности технических средств, программного и информационного обеспечения

Показатели назначения

Требования по диагностированию Системы

Требования к режимам функционирования Системы

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

Отдельные АРМ Системы работают в сеансах, количество и продолжительность которых определяется потребностями конкретных пользователей.

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

Диагностика осуществляется как внутрисистемным механизмом, обеспечивающим сбор информации о возникающих ошибках, так и обеспечиваемой СКБД согласно руководству по эксплуатации СКБД.

4.4.1.5 Допустимые пределы модернизации и развития Системы

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

Перенастройка Системы, связанная с изменением количества и состава информации, должна осуществляться службой сопровождения Заказчика.

Система должна обеспечивать:

— учет особенностей отраслевой специфики предприятия;

— соответствие требованиям отраслевых нормативных документов в соответствии с требованиями настоящего Технического задания;

— возможность настройки для обеспечения автоматизации бизнес-процессов Заказчика в случае их изменений, а также внесение изменений в настройки структуры организации Заказчика в Системе;

Смотрите так же:  Какие есть льготы молодым семьям в 2019 году

— устойчивость по отношению к ошибкам пользователей.

Должны быть регламентированы следующие максимальные показатели по отказам компонент ЛВС ЛПУ:

— время замены активного сетевого оборудования;

— время восстановления монтажных компонент;

— время устранения неисправностей в работе сетевого оборудования ЛВС;

— время восстановления работы ЛВС после сбоев по энергопитанию;

— время восстановления энергопитания компонент ЛВС при авариях.

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

— время устранения неисправностей в работе оборудования сервера Системы;

— время устранения неисправностей в работе ПО сервера Системы;

— время устранения неисправностей в работе SQL сервера БД Системы;

— время устранения неисправностей в работе оборудования рабочих станций;

— время устранения сбоев в работе системного и прикладного ПО рабочих станций.

4.4.3.2 Требования к надежности технических средств

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

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

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

Прикладные программы не должны во время работы модифицировать свой код или коды других программ.

4.4.3.4 Требования к надежности информационного обеспечения

Надежность функционирования компонентов ИО обеспечивается использованием сертифицированных систем управления базами данных, средств приема, обработки и передачи данных.

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

Средства ввода данных в систему должны обеспечивать контроль правильности данных по их типу.

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

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

4.4.4 Требования по безопасности

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

Прикладные программы не должны во время работы модифицировать свой код или коды других программ.

Требования к надежности технических средств и программного обеспечения

К надежности оборудования предъявляются следующие требования:

  • — в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;
  • — применение технических средств соответствующих классу решаемых задач;
  • — аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев.

К надежности электроснабжения предъявляются следующие требования:

  • — с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация серверов источником бесперебойного питания с возможностью автономной работы системы не менее X минут;
  • — система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;
  • — система должны быть укомплектована агентами автоматической остановки операционной системы в случае, если перебой электропитания превышает Y минут;
  • — должно быть обеспечено бесперебойное питание активного сетевого оборудования. Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:
  • — предварительного обучения пользователей и обслуживающего персонала;
  • — своевременного выполнения процессов администрирования;
  • — соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
  • — своевременное выполнение процедур резервного копирования данных.

Надежность программного обеспечения подсистем должна обеспечиваться за счет:

  • — надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;
  • — проведением комплекса мероприятий отладки, поиска и исключения ошибок.
  • — ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.

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

Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации — по методике Разработчика, согласованной с Заказчиком.

Требования к надежности

Состав показателей надежности для системы в целом

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

Надежность должна обеспечиваться за счет:

  • — применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
  • — своевременного выполнения процессов администрирования Системы;
  • — соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

Система должна соответствовать следующим параметрам:

Вероятность безотказной работы системы за 500 часов должна быть не менее 0,95

Достоверность выдаваемой информации 0.98

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

В ходе функционирования системы могут возникнуть следующие аварийные ситуации:

  • — сбой в электроснабжении сервера
  • — ошибки СУЗ, не выявленные при отладке и испытании системы
  • — сбои программного обеспечения сервера

Требования к надежности технических средств и программного обеспечения

К надежности оборудования предъявляются следующие требования:

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

К надежности электроснабжения предъявляются следующие требования:

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

Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:

  • — своевременного выполнения процессов администрирования;
  • — соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
  • — своевременное выполнение процедур резервного копирования данных.

Надежность программного обеспечения подсистем должна обеспечиваться за счет:

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

ООО «Техническая документация»

разработка техдокументации

Требования к надежности — пункт технического задания на АС, разрабатываемого согласно ГОСТ 34.602. Как элемент иерархической структуры ТЗ может быть представлен так: Требования к системе (разд. 4) ⇨ . в целом (подр. 4.1) ⇨ ..к надежности (п. 4.1.4). Каким содержимым заполнять данный пункт? Редакция от 20.06.2018.

Требования к надежности

Создан 31.03.2018 9:49:25

Итак, общие вводные требования — Надежность АСУ в целом и каждой ее автоматизированной функции должна быть достаточна для достижения установленных целей функционирования системы при заданных условиях применения [из п. 1.1.7 ГОСТ 24.104-85].

При решении вопросов, связанных с обеспечением требуемого уровня надежности АСУ, необходимо учитывать следующие особенности АСУ:

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

[из п. 1.2 ГОСТ 24.701-86].

Перечень функций и видов их отказов, по которым задаются требования к надежности конкретной АСУ, а также критерии этих отказов устанавливает заказчик АСУ по согласованию с разработчиком АСУ и вносит в техническое задание на АСУ (ТЗ на АСУ).

Для установления критериев отказов составляют перечень признаков или параметров, по которым может быть обнаружен факт возникновения каждого отказа, а при необходимости — количественные (критериальные) значения этих параметров [из п. 1.3.2 ГОСТ 24.701-86].

Смотрите так же:  При продаже квартиры с какой суммы берут налог

Если для некоторой функции АСУ определено несколько видов отказов, существенно различающихся по причинам возникновения или по вызываемым ими последствиям, то безотказность и ремонтопригодность по этой функции задают отдельно по каждому виду отказов. При этом критерии отказов устанавливают по каждому виду отказов [из п. 1.3.3 ГОСТ 24.701-86].

Установление требований к надежности конкретной разрабатываемой АСУ состоит в выборе состава (номенклатуры) показателей, используемых для количественного описания надежностных свойств системы и определении требуемых числовых значений (норм) этих показателей [из п. 3.1 ГОСТ 24.701-86].

Показатели надежности вводят по каждой функции системы и по каждому виду их отказов, а также по установленным для рассматриваемой системы аварийным ситуациям.

Состав показателей надежности определяют на основе включенных в ТЗ на АСУ перечней функций, видов их отказов и тех аварийных ситуаций, для которых следует устанавливать требования к надежности [из п. 3.2 ГОСТ 24.701-86].

Исходными данными для определения обоснованных требований к надежности АСУ являются:

  • виды и критерии отказов по всем рассматриваемым функциям системы;
  • уровень эффективности по всем функциям системы и величины ущербов по всем видам отказов (ориентировочно);
  • состав технических, программных и эргатических элементов, участвующих в выполнении каждой функции системы (ориентировочно);
  • возможные пути повышения надежности для каждой ФП АСУ и связанные с ними затраты (ориентировочно);
  • величины ущербов, связанных с возникновением возможных в АСУ аварийных ситуаций (ориентировочно);
  • возможные пути снижения опасности возникновения аварийных ситуаций и связанные с ними затраты (ориентировочно).

[из п. 3.3.1 ГОСТ 24.701-86].

Критерии отказов и предельных состояний должны обеспечивать простоту обнаружения факта отказа или перехода в предельное состояние визуальным путем или с помощью предусмотренных средств технического диагностирования (контроля технического состояния) [из п. 5.2 ГОСТ 27.003-90].

Требования к надежности АСУ определяют в основном путем сопоставления потерь, связанных с отказами АСУ в выполнении функций и возникновением аварийных ситуаций, и затрат, связанных с обеспечением и повышением надежности АСУ (включая удорожание обслуживания) [из п. 3.3.2 ГОСТ 24.701-86].

Требования к надежности АСУ устанавливают по согласованию между разработчиком и заказчиком АСУ при разработке ТЗ на АСУ [из п. 3.4 ГОСТ 24.701-86].

  • при разработке системы с целью прогноза ожидаемого уровня надежности АСУ (проектная, априорная оценка);
  • при вводе системы в эксплуатацию и в процессе ее функционирования с целью определения фактически достигнутого уровня надежности АСУ и проверки его соответствия требованиям к надежности, установленным в ТЗ на АСУ (экспериментальная, апостериорная оценка).

[из п. 4.1 ГОСТ 24.701-86].

Проектную оценку надежности АСУ с учетом КТС АСУ и ПО АСУ проводят при разработке технического проекта и используют для уточнения состава и структуры КТС АСУ, определения требований к надежности, а также выбора способов повышения надежности функционирования технического и программного обеспечения системы [из п. 4.2.3 ГОСТ 24.701-86].

К обязательным работам по обеспечению надежности АСУ, которые следует выполнять в процессе создания любой АСУ, относят:

  • анализ состава и содержания функций разрабатываемой (модернизируемой) АСУ, определение конкретного содержания понятия «отказ» и критериев отказа по каждому виду отказов для всех функций системы;
  • анализ, при необходимости, аварийных ситуаций в АСУ, определение конкретного содержания понятия «аварийная ситуация» для данной АСУ и критериев аварийной ситуации по каждой из рассматриваемых ситуаций;
  • выбор состава показателей надежности по всем функциям АСУ, указанным в ТЗ на АСУ и, при необходимости, по всем аварийным ситуациям и определение требований к уровню их значений;
  • выбор методов оценки надежности АСУ на различных стадиях ее создания и функционирования;
  • проведение проектной оценки надежности АСУ при разработке технического проекта системы;
  • определение режимов и параметров технической эксплуатации АСУ.

[из п. 5.2 ГОСТ 24.701-86].

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

Требования к надежности технических средств и программного обеспечения

1.1.66 Техническое обеспечение.

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

Для оценки надежности компонентов ТО используются следующие показатели и их значения:

− время наработки на отказ процессоров и оперативной памяти ЭВМ не должно быть меньше 1000 часов;

− вероятность потери сообщения при передаче данных в локальных сетях не должна превышать 10*(-6)

1.1.67 Программное обеспечение.

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

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

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

Прикладная программа не должна во время работы модифицировать свой код или коды других программ.

Для программ со сложным алгоритмом управления и вычислительных программ со временем работы более 1 часа должна быть предусмотрена возможность продолжения функционирования после аппаратного сбоя.

Количество отказов прикладного ПО из-за не выявленных ошибок не должно превышать 1 отказа на 1000 сеансов работы с программой.

Состав общесистемного ПО, устанавливаемого на рабочих местах пользователей, определяется на этапе рабочего проектирования, оформляется в виде отдельного документа и утверждается Заказчиком. В этом же документе определяется типовая конфигурация общесистемного ПО (основные параметры файлов инициализации).

Разработчик не несет ответственности за совместную работу компонентов АС ГИР/ПОГИР с другим программным обеспечением, конфликты программных и технических средств, связанные с изменением утвержденной конфигурации из-за инсталляции другого ПО, либо в случае использования не сертифицированных технических средств.

1.1.68 Информационное обеспечение.

Надежность функционирования компонентов ИО обеспечивается использованием сертифицированных систем управления базами данных, средств приема, обработки и выдачи данных.

Полнота и непротиворечивость данных АС ГИР обеспечивается использованием единой системы классификации и кодирования, унифицированной системы документов, концептуальной и логической модели данных, описывающей единое информационное пространство АС ГИР.

Средства ввода данных в систему должны обеспечивать контроль правильности данных по типу.

При модификации и удалении данных средства ведения ИО должны запрашивать подтверждении правильности выданных команд и временно сохранять предыдущую версию данных.

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

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

Сбои в работе ИО, связанные с недоработкой структур баз данных, системы классификации и кодирования, унифицированной системы документации не допускаются. Возможны сбои, обусловленные не выявленными ошибками в управляющих программных средствах, – их интенсивность определяется соответствующими сертификатами.

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

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

Деятельность по оценке и контролю показателей надежности (далее по тексту используется термин «контроль надежности») должна проводиться в комплексе работ по управлению качеством и испытаниям ГИР.

1.1.70 Виды контроля надежности

В зависимости от типа контролируемого компонента информационной системы и этапности его создания различаются следующие виды контроля:

а) по уровню обобщения:

б) по видам обеспечения:

1) технического обеспечения,

2) программного обеспечения,

3) информационного обеспечения;

в) по стадиям создания системы:

г) по месту проведения:

д) по условиям проведения:

2) нештатные ситуации.

Автономный контроль надежности предназначен для определения показателей надежности отдельных компонентов АС ГИР.

Комплексный контроль надежности предназначен для определения показателей надежности функциональных подсистем и всей АС ОГИР в целом.

Смотрите так же:  Причина для отказа в удо

По видам обеспечения необходимо проведение как автономного так и комплексного контроля.

Действия по контролю надежности на разных стадиях создания системы должны быть запланированы при формировании технологии создания системы.

Предварительный контроль производится Заказчиком при формировании требований к компонентам АС ГИР и заключается в обосновании задаваемых значений показателей надежности.

Исследовательский контроль производится проектировщиком АС ГИР и заключается в моделировании возможных значений показателей надежности и их сравнении с требуемыми.

Доводочный контроль производится в процессе разработки системы: монтажа аппаратуры, разработке компонентов ПО и ИО, и заключается в экспериментальном определении значений показателей.

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

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

Лабораторный контроль надежности проводится в организации разработчика; стендовый – на специализированных испытательных стендах АС ГИР; эксплуатационный – в эксплуатирующих организациях.

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

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

1.1.71 Методы контроля надежности

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

При контроле надежности АС ГИР должны использоваться следующие методы:

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

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

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

− ошибки оператора при вводе данных и подаче команд,

− сбой в работе технических устройств,

− ошибки в программном обеспечении,

− намеренное искажение информации и нарушение целостности структур баз данных.

Размещение и использование оборудования АС ГИР должно соответствовать требованиям НТД по обеспечению безопасной эксплуатации информационных систем и обеспечивать безопасность пользователей и эксплуатационного персонала информационной системы при всех видах работ, и на всех режимах эксплуатации.

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

Все оборудование АС ГИР должно быть заземлено.

В помещениях должны поддерживаться следующие параметры микроклимата:

− в холодные периоды года температура воздуха, скорость его движения и относительная влажность воздуха должны соответственно составлять: 22-25 градусов Цельсия; 0,1 м/с; 40-60%; температура воздуха может колебаться в пределах от 21 до 25 гр. С при сохранении остальных параметров микроклимата в указанных выше пределах;

− в теплые периоды года температура воздуха, его подвижность и относительная влажность должны соответственно составлять: 23-25 гр. С; 0,1-0,2 м/с; 40-60%; температура воздуха может колебаться от 22 до 26 гр. С при сохранении остальных параметров микроклимата в указанных выше пределах.

Уровни звука и эквивалентные уровни шума в помещениях с установленными СВТ не должны превышать:

− в помещениях, где работают инженерно-технические работники – 60 дБА;

− на рабочих местах в помещениях для размещения шумных агрегатов СВТ (устройства печати) -75 дБА.

Допускаемые уровни напряженности электростатических полей не должны превышать 20 кВ в течение часа (ГОСТ 12.1045-84).

Величина освещенности при искусственном освещении люминесцентными лампами должна быть в горизонтальной плоскости не ниже 300 лк – для системы общего освещения и не ниже 750 лк для системы комбинированного освещения. С учетом зрительной работы высокой точности величина освещенности для системы комбинированного освещения может быть увеличена до 1000 лк.

1.1.72 Требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения)

Комплекс средств автоматизации информационной системы ГИР должен эксплуатироваться в стационарных помещениях обычного типа, без воздействия агрессивных сред.

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

1.1.73 Требования к эргономике и технической эстетике

СВТ устанавливаются и размещаются в соответствии с требованиями технических условий изготовителей.

На постоянных рабочих местах персонала АС ГИР должны быть обеспечены микроклиматические параметры, уровни освещенности, шума и состояние воздушной среды, определенные действующими санитарными правилами и нормами. Системы вентиляции, отопления и кондиционирования воздуха должны быть выполнены в соответствии со СНиП 11-33-75 «Отопление, вентиляция и кондиционирование воздуха».

Организацию рабочих мест необходимо осуществлять на основе современных эргономических требований.

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Условия и регламент (режим) эксплуатации

АС ГИР должна обеспечивать круглосуточный режим работы, с плановыми перерывами на обслуживание технических, программных и информационных ресурсов. Как правило, операции по обслуживанию системы должны выполняться в нерабочее время.

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

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

Требования к допустимым площадям для размещения персонала и технических средств АС ГИР, а также параметрам сетей энергоснабжения определяются на этапе рабочего проектирования.

1.1.74 Требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов

На каждом объекте автоматизации, входящем в состав АС ГИР должно быть предусмотрено наличие запасных ЭВМ. Запасные ЭВМ должны быть полностью подготовлены к работе в качестве рабочих станций пользователей АС ГИР, на них должно быть проинсталлировано общесистемное и прикладное программное обеспечение, установлены сетевые адаптеры. Количество запасных ЭВМ для каждого объекта автоматизации и их конфигурация определяются на этапе рабочего проектирования. В общем случае необходимо предусматривать 5% запасных ЭВМ, но не менее одной.

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

На каждом объекте автоматизации также должно быть предусмотрено наличие запасного устройства печати.

1.1.75 Требования к регламенту обслуживания

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

В оперативное обслуживание должны входить:

− функции администрирования информационной безопасности;

− функции администрирования автоматизированной системы;

− восстановление работоспособности технических и программных средств после возникновения аварийных ситуаций.

Все виды регламента должны выполняться в конце соответствующего временного периода, как правило – в нерабочее время. Еженедельный регламент включает в себя все операции ежедневного, ежемесячный – еженедельного, а ежеквартальный и годовой – ежемесячного (Таблица И.2).

Таблица И.2 – Состав основных операций и продолжительность проведения регламента