19493

Требования к надёжности системы управления

Доклад

Информатика, кибернетика и программирование

Требования к надёжности Уровень надежности АС в существенной степени зависит от следующих основных факторов: Состав и уровень надежности используемых технических средств их взаимодействие и взаимосвязь в структуре Комплекса Технических Средств АС. Состав ...

Русский

2013-07-12

45.5 KB

5 чел.

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

Уровень надежности АС в существенной степени зависит от следующих основных факторов:

  1.  Состав и уровень надежности используемых технических средств, их взаимодействие и взаимосвязь в структуре Комплекса Технических Средств АС.
  2.  Состав и уровень надежности используемых программных средств, их содержание (возможности), взаимосвязь и взаимодействие в структуре программного обеспечения АС.
  3.  Уровень квалификации, организации работы, и уровень надежности технологического, эксплуатационного и обслуживающего персонала.
  4.  Рациональность распределения задач, решаемых Системой, между КТС, программным обеспечением, и персоналом.
  5.  Режимы и организационные формы эксплуатации КТС АС.
  6.  Степень использования различных видов резервирования (структурного, информационного, алгоритмического, функционального, временного и др.).
  7.  Степень использования методов и средств технической диагностики.
  8.  Реальные условия функционирования АС.

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

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

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

  1.  Виды и критерии отказов по всем рассматриваемым функциям АС;
  2.  Уровень эффективности по всем функциям Системы и величины ущербов по всем видам отказов;
  3.  Состав персонала, технических и программных элементов, участвующих в выполнении каждой функции Системы;
  4.  Возможные пути повышения надежности для каждой функции АС и связанные с ним затраты;
  5.  Величины ущербов, связанные с возникновением в АС аварийных ситуаций.

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

  1.  Анализ состава и содержания функций разрабатываемой АС.
  2.  Определение конкретного содержания понятия ОТКАЗ, и критериев отказа по каждому виду отказов для всех функций Системы.
  3.  Определение конкретного содержания понятия АВАРИЙНАЯ СИТУАЦИЯ для данной Системы и критериев аварийной ситуации по каждой из рассматриваемых ситуаций.
  4.  Анализ аварийных ситуаций в АС.
  5.  Выбор состава показателей надежности по всем функциям АС, указанным в Техническом Задании на АС и, при необходимости, по всем аварийным ситуациям и определение требований к уровню их значений.
  6.  Выбор методов оценки надежности АС на различных стадиях ее создания и функционирования.
  7.  Проведение проектной оценки надежности АС при разработке Технического проекта Системы. Общий порядок оценки надежности Автоматизированных Систем приведен в Разделе 4  ГОСТа  24.701-86.
  8.  Определение режимов и параметров технической эксплуатации АС.

НАДЕЖНОСТЬ СИСТЕМ ПАЗ должна обеспечиваться:  

АППАРАТУРНЫМ  РЕЗЕРВИРОВАНИЕМ:

  •  Модулей центрального процессора (управляющих модулей);
  •  Модулей ввода вывода;
  •  Промышленных сетей;
  •  Источников питания.

ВРЕМЕННÓЙ, АЛГОРИТМИЧЕСКОЙ, ИНФОРМАЦИОННОЙ И ФУНЦИОНАЛЬНОЙ ИЗБЫТОЧНОСТЬЮ, и

наличием систем  ДИАГНОСТИКИ  И САМОДИАГНОСТИКИ.

Согласно ПБ 09-540-03, пункт 6.3.13, контроль над параметрами, определяющими взрывоопасность технологических процессов с блоками I категории взрывоопасности, должен осуществляться не менее чем от двух независимых датчиков с раздельными точками отбора.

Далее приводятся основные меры и показатели, которые необходимо предусмотреть для обеспечения надежности Комплекса Технических Средств и Программного Обеспечения:

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

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

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

Перечень задач системы ПАЗ (только для АСУТП)

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

  1.  Автоматизированный сбор аналоговой и дискретной информации от датчиков технологических параметров и параметров состояния исполнительных механизмов, а также дискретных параметров ДВК, ПДК, состояния аварийной вентиляции
  2.  Выделение достоверной входной информации.
  3.  Анализ и логическую обработку входной информации.
  4.  Автоматическую выдачу сигналов двухпозиционного управления на исполнительные механизмы.
  5.  Дистанционное («ручное») управление исполнительными механизмами при условии санкционированного доступа.
  6.  Определение первопричины срабатывания системы защиты и останова технологического процесса.
  7.  Передачу оперативной информации от системы ПАЗ в РСУ для сигнализации, регистрации и архивирования (отклонения параметров, срабатывания исполнительных механизмов ПАЗ, действия персонала и т.п.).
  8.  Самодиагностику  технических средств системы ПАЗ, обеспечивающих выполнение функций логической обработки входной и выходной информации и идентификацию неисправностей с точностью до модуля (блока).


 

А также другие работы, которые могут Вас заинтересовать

31129. Модели качества процесса конструирования. Архитектура программных систем 41.02 KB
  Архитектура программной системы ПС – это набор внутренних структур ПС которые видны с различных точек зрения и состоят из компонентов их связей и возможных взаимодействий между компонентами а также доступных извне свойств этих компонентов. Вид с точки зрения прецедентов Use cse view охватывает прецеденты которые описывают поведение системы наблюдаемое конечными пользователями аналитиками и тестировщиками. Вид с точки зрения проектирования Design view охватывает классы интерфейсы и кооперации формирующие словарь задачи и ее...
31130. Базис языка UML 249.01 KB
  Словарь UML образуют 3 разновидности строительных блоков это предметы отношения и диаграммы. Предметы – это абстракции основные элементы в модели отношения связывают предметы а диаграммы группируют коллекции предметов. Структурные предметы это существительные в UML моделях статические части. Предметы поведения Предметы поведения – это динамические части глаголы модели поведение объектов во времени.
31131. Унифицированный процесс разработки программных систем 45.19 KB
  Прецеденты должны быть основным артефактом на основании которого устанавливается желаемое поведение системы проверяется и подтверждается правильность выбранной системной архитектуры производится тестирование. Системная архитектура является решающим фактором при разработке концепций конструировании управлении и развитии создаваемой системы. Итеративным называется процесс который предполагает управление потоком исполняемых версий системы. Разработка стабильной базовой архитектуры продукта которая позволяет решать поставленные перед...
31132. Основы объектно-ориентированного представления программных систем 169.01 KB
  Сцепление модулей. Сцепление – это мера взаимозависимости модулей по данным внешняя характеристика модуля которую желательно уменьшить. Измеряется сцепление степенью сцепления. Выделяют 6 видов степени сцепления: Сцепление по данным; Сцепление по образцу; Сцепление по управлению; Сцепление по внешним ссылкам; Сцепление по общей области; Сцепление по содержанию.
31133. Статические модели объектно-ориентированного представления программных систем 142.29 KB
  Диаграмма классов это набор классов и связей между ними. Диаграммы классов используются: в ходе анализа – для указания ролей и обязанностей сущностей которые обеспечивают поведение системы; в ходе проектирования – для фиксации структуры классов которые формируют системную архитектуру. Отношения в диаграммах класса. Ассоциации отображают структурные отношения между экземплярами классов.
31134. Динамические модели объектно-ориентированного представления программных систем: автоматы 336.98 KB
  Динамические модели обеспечивают представление поведения системы путем отображения изменения состояний в процессе работы системы в зависимости от времени. Автомат – описывает поведение в терминах последовательности состояний через которые проходит объект в течение своей жизни. Диаграмма схем состояний – отображает конечный автомат выделяя поток управления от состояния к состоянию. Конечный автомат – поведение определяющее последовательность состояний в ходе существования объекта.
31135. Динамические модели объектно-ориентированных программных систем: диаграммы взаимодействия Use Case 14.52 KB
  Диаграмма сотрудничества – это диаграмма взаимодействия выделяющая структурную организацию объектов посылающих и принимающих сообщения. Иначе диаграмму сотрудничества называют диаграмма кооперации. Диаграмма последовательности это диаграмма взаимодействия отображающая сценарий поведения в системе и обеспечивающая более наглядное представление порядка передачи сообщений. Графически диаграмма последовательности – это разновидность таблицы которая показывает объекты размешенные вдоль оси икс и сообщения упорядоченные во времени вдоль оси...
31136. Модели реализации объектно-ориентированных программных систем 34.82 KB
  Модели реализации обеспечивают представление системы в физическом мире рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. Рисунок 1 – обозначение компонента Сходные характеристики: наличие имени; реализация набора интерфейсов; участие в отношения зависимости; возможность быть вложенными; наличие экземпляров экземпляры у компонентов только у диаграмм размещения № Описание различий 1 Классы – логические абстракции компоненты – физические предметы. 2 Компоненты являются...
31137. Стандартные методы совместного доступа к базам и программам в сложных информационных системах 150.16 KB
  ODBC – это программный интерфейс PI доступа к базам данных разработанный фирмой X Open. ODBC – это широко распространенный комплекс драйверов фирмы Microsoft для связи с разнородными базами данных удовлетворяющий стандартом ISO. Технологии связи с разнородными базами данных в условиях архитектуры клиент – сервер с использованием ODBC. Клиентская часть состоит из: Управляющий модуль ODBC.