Интерфейс wcc 100 до 1 км

Система сбора данных (для понимания процессов, но не для управления и ото­бражения) 1024 временных изменяемых отметки

Двухконтурная станция управления процессами   – 4 анал. вх., 4 дискр. вх. – 2 анал. вых., 2 дискр. вых.

Восьмиконтурная станция управления процессами

Программируемый контроллер

До 256 станций управления, систем сбора данных,
програм-х контр-ов

¨ 46 внутр. взаимосвязей;

¨ вторичные коммуникационные (горизонтальные) связи обмена данными на уровне процессоров с 31-Р100;

¨ вертикальные связи с центральной СКТ-управляющей системой до 5 км;

¨ передняя DlN-панель: контроль, управление, элементы защиты;

¨ боковая панель для изменения конфигурации (90 фирменных функций в EPROM, до 80 ступеней)

Рис. 12.13. AСУTП MICON MDC – 200 (GMBH)

Таблица 12.2

Алгоритмы MICON MDC P100 (GMBH)

Аналоговые вх./вых.	28-руководство станции	Функции логические
01-преобразование	29-выход слежения	69-калькулятор логич.
02-ХМТК-авария вых.		70-И; 71-ИЛИ; 72-НЕ
03-нейтрализация неисправности (изменение конфигурации)	Математические ф-ии	73-LATCH; 74-таймер
04-сумма входов	30-х; 31-:; 32+; 33-	75-выход дискр-й
05-T/C, RTD-линеар-ия	34-; 35-калькулятор	76-виртуал. дискр. вых.
Дискретные вх./вых.	36- | |; 37- lg; 38-exp	77-результир. счетчик
07-норм. состояние	39-полином	78-вых. пуск \ стоп
08-авария выхода	Групповые функции	79-дискр. вых. регистра
Конфигурация контура	40-последовательное управление	Аварийные выходы
10-загрузка (внутр. сигн.)	41-процесс защ. блок-ки	80- MSY авар. вых.
11-загрузка анал. вх.	42-защитная блокировка при аварии	81- отклонение авар. вых.
12-компенсация темп-ры	43-дискретный массив	82- PY авар. вых.
13-компенсация давления	44-последовательность	83-скорость авар. вых.
14-входной сигнал переключения	MSY функции изменения	Специальные ф-ии
15-загрузка дискр. вх.	46-MSV функция на дискр. основе	99-FILLER
16-ПКА	47-MSY функции на анал. основе	00-Terminator (признак конца)
ПИD-функции	49-селектор
17-ограничение	Динамические ф-ии
18-ПИД пакет переключения	50-опережение\ запаздывание
19-ПИД измеряющий	51-законченное время
20-ПИД BASIC контроллер	52-скоростной задел
21-ПИД cмeщeниe\BIAS	53-подведенне итогов
22-ПИД авто \ смещение	Выводные функции
23-ПИД авто \ BIAS	54-аналог. вых. безусловный
24-ПИД каскад	55-анал. вых. (VALYЕ)
25-ПИД интервал	56-дискр. вых. безусловный
26-адаптация PID параметров
27-загрузка PID параметров

– до 10 системных модулей; – до 100 ремиконтов; – BITBUS фирмы INTEL; – физ. уровень– RS485; – канальный уровень – SPLC; – до 4 сегментов по 300 м; – RASCON – – физ. и кан. уровень MIL– 1553 В; – сеть NETBIOS с ОС «Clarynet»; – до 4 сегментов по 800 м; – до 2–3 тыс. аналоговых сигналов; – до 3–5 тыс. дискретных сигналов

– до 200 контуров регулирования; – до 20 шаговых программ; – Р210 – многоцелевой универсальный контроллер; – Р215 – управляющий контроллер; – Р201 – сбор и предварительная обработка информации; – Р203 – регистрационный контроллер; – Р205 – управляющий с резервированием

Рис. 12.14. Программно-технический комплекс «Квинт»

– ISP FIELPBUS-INTER operable Sistems Profect (системный проект по взаимодействию);

– протокол, открытый, промышленный, HART фирмы HART Communication Foundation;

– ПО: «FILPYUE» фирмы FIHSER – ROSEMOUNT для многофункционального цифрового регулирования клапаном;

– «Cornerstone» – управление измерениями;

– IIS (Instrument Infоrmаtion System) – управление документированием.

Рис. 12.15. Система управления процессом RS3
(FISER-ROSEMOUNT SYSTEM)

Рис. 12.16. Открытая промышленная система
АСУТП «FOXBORD-ЕCKADТ»

– основной процессор i386; – ОСРВ RMX, RTX; – прикладные программы на Паскале и СИ

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

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

Рис. 12.17. АСИ «LOGITEST»

12.2. ЛВС: доступ к каналу, способы кодирования,
типы сообщений, сетевые системы

Остановимся на локальных сетях, большое значение которых для АСУ ТП после знакомства со структурой АСУ ТП становится ясным.

Канал связи магистрального типа (общая шина или кольцо) получает преимущественное распространение в настоящее время (в локальных сетях), поскольку позволяет предоставлять всем абонентам сети равноправные возможности для установления связи, потенциально обладает более высоким быстродействием. Такой канал связи называют также разделяемым моноканалом (в отличие от выделяемых «точка – точка»), поскольку он обеспечивает одновременную передачу информации от одной станции сразу ко всем станциям. Однотипное подключение абонентов через блок доступа (адаптер) к моноканалу создает свободно связанную и свободно наращиваемую систему с чрезвычайно гибкими возможностями. Именно такая система наиболее перспективна для целей управления ГПС. Моноканал не накладывает принципиальных ограничений на свойства подключаемых к нему машин и систем управления. Сеть может быть гетерогенной (т.е. состоящей из разнородных, не совместимых по системе команд ЭВМ) или гомогенной (ЭВМ одной ветви вычислительной техники). Сеть может быть одноранговая (наличие централизации – серверы, хостмашины) и многоранговая (с невыделенным сервером).

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

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

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

¨ тактирование моментов допустимых передач;

¨ «Слушай, прежде чем говорить» – прослушивание несущей частоты канала, начало передачи лишь тогда, когда канал свободен;

¨ «Слушай, пока говоришь» – если во время начала передачи одного сообщения делается попытка передать другое, то передача всех абонентов прекращается с задержкой, определенной для каждого абонента (приоритет все же есть).

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

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

Метод временного синхронного разделения канала – каждому абоненту свой интервал передачи.

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

Метод централизованного управления – моноканал предоставляется абоненту арбитром сети.

В настоящее время наибольшее распространение нашли два метода доступа:

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

¨ жезловый (маркерный) доступ.

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

В качестве физической среды для передачи сигналов используют многожильный электрический кабель (плоский или 16-про­водный кабель-жгут), одножильный кабель (витая пара), коаксиальный кабель, оптоволоконный кабель. Для резервирования и живучести ГПС прокладывают двойной комплект физических линий связи.

Последовательный код сообщения может быть представлен при передаче по-разному. Обычно способ представления «1» и «0» уровнем напряжения или тока не может быть использован ввиду малой скорости передачи.

Требования к коду:

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

¨ за один синхроимпульс передачи одного бита нужен хотя бы один переход 1®0 или 0®1, иначе трудно выделить синхроимпульсы при приеме.

Из различных правил кодирования в настоящее время получил наибольшее распространение код «Манчестер» (типа BIF-L), по которому при «1» осуществляется переход 1®0 в середине синхроимпульса (передатчика), при «0» – переход 0®1. Ниже на примере показан принцип кодирования:

Из кода на приемном устройстве легко выделить синхроимпульсы. По фронту синхроимпульса 1®0 выделяем «1», по фронту 0®1 выделяем «0».

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

Принимающая сторона должна дешифрировать еще 4 символа, дополнительно включенных в манчестерский код:

N (non – data) – не данные;

P (pad – idle) – холостой наполнитель;

B (bad signal) – искаженный сигнал;

S (silence) – молчание.

Назначение этих символов:

N – начальный и конечный флажок сообщения, имеет формат:

Р – преамбула сообщения (период синхроимпульса);

В – искажаемый сигнал, принимаемый код не соответствует манчестерскому коду;

S – молчание (канал свободен), по каналу следует только несущая (модулирующая) частота.

Сетевой контроллер (адаптер) реализует следующие функции:

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

¨ поддерживает дисциплину доступа к каналу, поддержку протоколов сети;

¨ контроль корректности принимаемых из сети сообщений;

¨ выполняет диагностические функции;

¨ строит передаваемые в сеть кадры сообщений;

¨ осуществляет буферизацию информации, связь с МП и памятью абонента и другие функции.

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

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

Таким образом, главный принцип построения большой интегрированной системы – декомпозиция на подсистемы при сохранении информационной совместимости подсистем.

Выделим в составе интегрированной системы 4 группы локальных сетей: административные сети, сети инженерных служб, сети управления производством, сети реального времени.

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

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

Сети управления производством характеризуются небольшим объемом административной и организационной информации, но объемной информацией проблемно-ориентированного управляющего характера. По сети передаются большие файлы управляющих программ и технологических заданий, меньшие по объему файлы статусов и конкретные команды управления. Пользователями сети являются и люди, и автоматические устройства. Реактивность сети должна соответствовать потребностям автоматических устройств, а не людей (время доступа 0,5–2 с). В таких сетях считается более целесообразным маркерный метод доступа. Стоимость сетей управления в силу требований высокой надежности в несколько раз выше, чем стоимость административных сетей и сетей инженерных служб.

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

Таблица 12.3

Вид сообщения	Размер сообщения	Средняя периодичность передачи, мин	Допустимая задержка, с	Требуемая скорость передачи, кбод
Удаленная загрузка операционной системы Удаленная загрузка программ ЧПУ, данные отчетности (массивы) Инструкции оператору Цеховой диалог   Запросы от одной системы управления к другой на обслуживание Отчеты, статусы, сообщения регистрации Аварийные сигналы (наивысший приоритет) Команды прямого управления – ответы (наибольшее число сообщений)	500 кбайт   1–5 кбайт     1,5 кбайт 1,5 кбайт   64 байта     0,5–3 кбайта   32 байта   50 байт	0,5 интерактивный режим 0,5       нерегулярная	0,1       0,01   0,1	50–100   4,8     4,8 9,6   9,6         9,6

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

Специфика системы управления гибким производством в том, что она объединяет ряд характеристик, присущих сетям различных групп. Здесь имеется СУБД, производится удаленная загрузка операционных систем, решаются задачи оперативного управления и прямого управления оборудованием в реальном времени и т.д. Характер информационных сообщений в сетях ГПС приведен в табл. 12.3.

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

Рис. 12.17. Структура полей информационного сообщения в ГПС

Представим один из популярных вариантов такого языка для ГПС. Единица сообщения – кадр, длина которого не превышает 512 байт. Структура полей информационного сообщения представлена на рис. 12.17.

Х – тип передачи, в числе которых A, C, D, E, N, U:

A – уведомление об отказе передатчика от передачи;

C – передача команды запроса;

D – передача данных, причем не последнего блока передаваемого по частям файла;

E – передача данных, причем последнего или единственного блока;

N – отказ от передачи по инициативе приемника по причине невозможности выполнить какую-то команду или неверно принятой информации;

U – запрос на незапланированную передачу по инициативе передатчика (запланированная передача – по инициативе приемника, нуждающегося в передаче).

Дальнейшая детализация содержания сообщения осуществляется введением подтипов передачи:

NAM (name) – имя файла или программы;

STA (status) – статус, т.е. описание состояния объекта;

MSG (message) – электронная почта (экранное сообщение);

EXE (execution) – инициация выполнения;

FIL (file) – признак файла.

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

BCL (binary cutter location data) – информация об инструменте;

BIN (binary data) – информация в двоичном коде;

ISO – управляющая программа в коде ISO;

INS (inspection data) – результаты измерения;

TST (test data) – тесты.

Расширения команды привязаны к подтипам передачи.

Так, подтип STA имеет расширения: ALL (передается полный набор данных); CYC (состояние автоматического цикла); INH
(состояние блокировки); PRG (состояние отработки программы); ALM (признак аварийного останова) и др.

Подтип EXE имеет расширения: ARP (обращение к локальной системе ГПМ); CCP (задание коррекций на инструмент); CRT (обращение к устройству управления транспортным робокаром); AUT (обращение к режиму «автомат»); CYC (обращение к автоматическому циклу); LDR (задание роботу на загрузку заготовки); PLT (задание на идентификацию определенной палеты); PRT (задание на идентификацию определенной детали); UGP (разжим); ULP (разгрузка) и т.д.

Подтип FIL имеет расширения: CLO (закрыть файл); DEL (стереть файл); DIR (обращение к справочнику); RED (считать файл); REN (переименовать файл); WRT (записать файл).

Расширения имеет и тип N (подтипы в этом случае не используются): CNE (команда не выполнена); DNA (данные недоступны); DNR (данные не готовы); FLU (файл в работе); FNA (файл недоступен); FNF (файл не найден); FNI (функция не реализована); FNO (файл не открыт); MNQ (сообщение отсутствует); PNF (пакет, т.е. блок сообщений, не найден); SMF (запоминающее устройство заполнено); SNQ (данные о состоянии неизвестны); SNR (система не готова).

Синтаксические диаграммы передач и сессий см. в [12].

Более подробно о ЛВС и промышленных шинах можно узнать из пособия [10].

Контрольные вопросы

1. Приведите структурную схему типовой АСУТП на основе рассмотренных различных примеров реальных АСУТП.

2. Как реализуется нижний уровень АСУТП?

3. Каковы принципы доступа к локальной сети в АСУТП?

4. Перечислите принципы организации физического, канального сетевого уровня локальных сетей.

5. Приведите примеры синтаксиса в промышленных ГПС для транспортного и сессионного уровней передачи информации.

6. Каковы характерные особенности АСУТП «Проконтроль», «Даматис ХР», «ТДС 3000», «Micon», «Квинт»?

13. Автоматизированные системы
контроля и учета энергоресурсов (АСКУЭ)

13.1. Требования к автоматизированным
системам контроля и учета энергоресурсов

Высокая стоимость энергоресурсов в последние годы стала причиной того, что отношение к организации энергоучета в промышленности и других энергоемких отраслях (транспорт и жилищно-коммунальное хозяйство) кардинально изменилось. Потребители начинают осознавать, что в их интересах рассчитываться с поставщиком энергоресурсов не по каким-то условным нормам, договорным величинам или устаревшим и неточным приборам, а на основе современного и высокоточного приборного учета. Промышленные предприятия пытаются как-то реорганизовать свой энергоучет «вчерашнего дня», сделав его адекватным требованиям дня сегодняшнего. Под давлением рынка энергоресурсов потребители приходят к пониманию той простой истины, что первым шагом в экономии энергоресурсов и снижении финансовых потерь является точный учет. С этой целью как поставщики, так и потребители создают на своих объектах автоматизированные системы контроля и учета энергоресурсов (АСКУЭ). При наличии современной АСКУЭ промышленное предприятие полностью контролирует весь свой процесс энергопотребления и имеет возможность по согласованию с поставщиками энергоресурсов гибко переходить к разным тарифным системам, минимизируя свои энергозатраты.

На ряде предприятий АСКУЭ функционируют уже не один год, на других предприятиях начинается их внедрение, а руководители третьих только размышляют, нужно ли им это. Ход развития мировой энергетики и промышленности показывает, что альтернативы принципу «все надо учитывать и за все надо платить» нет. И если сегодня где-то еще удается бесконтрольно пользоваться энергоресурсами или списывать потери в сетях на потребителя, то завтра это станет попросту невозможно. Преимущества будут у того, кто все процессы энергопотребления полносью контролирует.

Постоянное удорожание энергоресурсов требует от промышленных предприятий разработки и внедрения комплекса мероприятий по энергосбережению, включающих жесткий контроль поставки/потребления всех видов энергоресурсов, ограничение и снижение их доли в себестоимости продукции. Современная АСКУЭ является измерительным инструментом, позволяющим это осуществить, и лежит в основе системы энергосбережения промышленных предприятий. Первый и самый необходимый шаг в этом направлении, который надо сделать уже сегодня, – это внедрить автоматизированный учет энергоресурсов, позволяющий контролировать параметры всех энергоносителей по всей структурной иерархии предприятия с доведением этого контроля до каждого рабочего места. Благодаря этому будут сведены к минимуму производственные и непроизводственные затраты на энергоресурсы; это позволит решать спорные вопросы между поставщиком и потребителем энергоресурсов не волевыми, директивными мерами, а на основании объективного автоматизированного учета.

Итак, можно выделить следующие основные цели создания АСКУЭ.

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

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

3. По результатам анализа энергопотребления при использовании современных СУБД можно составлять энергобалансы на год, 5 лет и более с целью определения потребности в энергии предприятия в целом и наиболее энергоемких агрегатов и цехов, проводить анализ эффективности использования энергоресурсов, выявлять непроизводительные расходы и потери, находить норму расхода энергии на единицу продукции и обеспечивать снижение энергопотребления.

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

До последнего времени под АСКУЭ понимались в основном контроль и учет электроэнергии. Поэтому иногда АСКУЭ распознают как «Автоматизированные системы контроля и учета электроэнергии» или «Автоматизированные системы коммерческого учета электроэнергии». Однако в перспективе на предприятиях и в сфере ЖКХ будет востребован контроль и учет всех видов энергоресурсов: тепловой энергии, холодной и горячей воды, природного газа, сжатого воздуха и т.д. Системы контроля и учета отдельных энергоресурсов различаются между собой незначительно. Поэтому принимаем под АСКУЭ «Автоматизированные системы контроля и учета энергоресурсов».

В настоящее время выпускается множество систем АСКУЭ. Имеется тенденция в каждом регионе разработать «свою» АСКУЭ. Учитывая множество устройств сбора информации от датчиков с импульсными, аналоговыми, цифровыми выходами, множество систем передачи информации, комплексов программного обеспечения для систем сбора, обработки, хранения, визуализации, передачи информации, пользователи АСКУЭ бывают в затруднении при выборе КТС и ПО.

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

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

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

¨ коммерческий учет энергоресурсов, отпускаемых субабонентам;

¨ технический учет энергоресурсов на вводе в отдельные цеха или на входе/выходе отдельных энергопроизводств (котельных, компрессорных, насосных и т.д.);

¨ контроль (телемеханика) режимов работы оборудования и состояния электрических сетей (ток, напряжение, частота) на заводских подстанциях;

¨ контроль за теплотехническим оборудованием завода (положение задвижек, состояние клапанов);

¨ телеуправление (возможно автоматическое) электротехническим и теплотехническим оборудованием.

К этим требованиям добавляются требования от энергетиков цехов и мастеров (технических руководителей) различных энергообъектов (котельных, компрессорных и т.д.) по организации учета расхода энергоресурсов и контроля параметров энергоресурсов на конкретных технологических объектах (например, расход газа на металлургическую печь или котел, электроэнергии на насос и т.д.). При этом необходимо, чтобы, с одной стороны, система учета включала в себя функции оперативного контроля параметров энергоносителей, а с другой стороны – чтобы функции оперативного контроля состояния оборудования и сетей (функции телемеханики) были дополнены возможностью ретроспективы (восстановления) состояния оборудования и параметров за любой период времени. Фактически получается, что к системе учета и к системе телемеханики предъявляются во многом схожие требования: возможность оперативного контроля и архивирования параметров энергоресурсов и состояния оборудования. Несомненно, эти функции могут выполняться любой стандартной системой сбора данных.

Но коммерческий учет предъявляет повышенные требования к сохранности и достоверности информации. Выражается это в том, что:

¨ системы учета должны вести расчеты и архивирование информации на нижнем уровне (уровень счетчиков или тепловычислителей),

¨ системы учета должны иметь сертификаты Госреестра на измерение параметров энергоносителей,

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

На этапе обследования предприятия, изучения установленного парка счетчиков, датчиков, преобразователей (полевой уровень), условий эксплуатации вместе со специалистами КИПиА (или АСУ ТП) появляются требования и к среднему уровню – уровню тепловычислителей, устройств телемеханики, УСПД; для упрощения назовем все это контроллерами:

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

¨ контроллеры должны работать с очень широким спектром входных сигналов – от «естественных» сигналов термопар и термосопротивлений до «кодовых» сигналов «интеллектуальных» датчиков, счетчиков, модулей ввода-вывода;

¨ контроллеры должны уметь считать расходы по различным алгоритмам, в зависимости от типов установленных преобразователей и счетчиков (от диафрагм до ультразвуковых расходомеров);

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

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

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

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

¨ контроллеры должны иметь развитые коммуникационные возможности. «Джентльменский набор» – это промышленная сеть на базе RS-485 и дополнительно еще один последовательный порт для локального подключения или использования с модемами различных типов. Желательна поддержка основных промышленных сетей FieldBus (Modbus, Profibus, CANopen, AS-i и др.), ЛВС типа Ethernet с протоколом TCP/IP.

Разрабатываемая АСКУЭ должна интегрировать существующие «локальные» системы учета, если они работают и не стоит вопрос об их замене.

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

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

¨ используемые операционные системы – в большинстве случаев это Windows 98/NT/2000 и выше;

¨ единая база данных на стандартных СУБД, причем все чаще требуются не «настольные» СУБД (Paradox, Access), а мощные SQL базы данных (MS SQL 7.0, Oracle), которые могут одновременно обслуживать десятки АРМ и гарантируют достоверность и сохранность информации;

¨ использование клиент-серверной технологии взаимодействия между АРМ и сервером баз данных, причем клиенты должны быть «тонкими», то есть все основные вычисления (бизнес-логика) происходят на сервере баз данных или на специализированном сервере приложений, а АРМ конкретных приложений больше используются как терминалы, что также гарантирует сохранность и достоверность данных;

¨ встроенные возможности администрирования и конфигурирования программного обеспечения, обеспечение защиты от несанкционированного доступа к информации (дополнительно к стандартным возможностям Windows NT и SQL сервера);

¨ полная и подробная документация, позволяющая программистам предприятия разрабатывать собственные приложения, используя существующие «хранимые процедуры» и базы данных;

¨ интеграция существующих узлов учета в систему, причем на верхнем уровне это должна быть полная интеграция, то есть единые базы данных, единые АРМ, единые отчеты;

¨ разделение доступа клиентов (АРМ) к базе данных.

Дата добавления: 2015-05-29