В документе

Государственный Университет Аэрокосмического Приборостроения
Дипломная работа
РАСПРЕДЕЛЕННАЯ ИНФОРМАЦИОННОУПРАВЛЯЮЩАЯ СИСТЕМА ПОТОК-С
Руководитель: к.т.н., начальник СКБ ГУАП
Студент:
Рочев М.С.
Астапкович А. М.
СОДЕРЖАНИЕ
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ…………………………………………………………………3
ВВЕДЕНИЕ……………………………………………………………………………………….……4
1 ОБЗОР НАУЧНО-ТЕХНИЧЕСКОЙ ЛИТЕРАТУРЫ И ПАТЕНТОВ…………….…….…….6
1.1 Обзор систем мониторинга и управления распределенными объектами ……….…....6
1.2 Обзор контроллеров и встраиваемых компьютеров ……………………………………..21
2 ПОСТАНОВКА ЗАДАЧИ…………………………………………………………………………40
2.1 Описание проблематики……………………………………………………………………40
2.2 Общие требования к системам класса ИУС (СДМУ)…………………………………….41
2.3 Особенности построения и концепция РИУС ПоТок-С………………………………….43
2.4 Требования к программному обеспечению системы……………………………………..46
3 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ…………………………………….……..48
3.1 Низкоуровневое ПО контроллера ASK-Lab……………………….……………………...48
3.2 Высокоуровневое ПО системы видеоконтроля……………….………………………….68
4 ОЦЕНКА РЕЗУЛЬТАТОВ РАЗРАБОТКИ…………………………………………….…….......76
4.1 Оценка результатов разработанной системы…………………………………………….76
4.2 Оценка результатов разработанного ПО контроллера ASK-Lab……………………….78
4.3 Результаты применения системы видеоконтроля ……………………………….………80
ЗАКЛЮЧЕНИЕ…………………………………………………………………………………...….83
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ………………….……………………………..85
2
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
ПТК
– программно-технический комплекс;
АПК
– аппаратно-программный комплекс;
ИС
– информационная система;
ИИС
– информационно-измерительная система;
ИУС
– информационно-управляющая система;
РИУС
– распределенная информационно-управляющая система;
ПК
– персональный компьютер;
КИП
– контрольно-измерительный прибор;
УСО
– устройствами связи с объектом;
АСУТП
– автоматическая система управления технологическим процессом;
ЭЦРТ
– Электронный Цифровой Регулятор Температуры;
ТК
– технологический контроллер;
СДМУ
– система дистанционного мониторинга и управления;
ББП
– блок бесперебойного питания;
«ГТС»
– «Городские Тепловые Сети»;
ПД
– пульт диспетчера;
АРМ
– автоматизированные рабочие места;
АТС
– автоматическая телефонная станция;
ДПС
– диспетчерский пункт системы;
АУЭ
– автоматизированный учет энергии;
ЖК
– жидкокристаллический;
ПО
– программное обеспечение;
СУБД
– система управления базой данных;
ОСРВ
– операционная система реального времени;
мОСРВ
– микрооперационная система реального времени;
3
ВВЕДЕНИЕ
В промышленности и жилищно-коммунальном хозяйстве страны имеется огромное
количество таких объектов, как котельные, теплопункты, канализационные насосные
станции, водоподкачивающие станции и т.п. Функциональные обязанности персонала
подобных объектов (часто малоквалифицированного) сводятся, как правило, к наблюдению
за
работой
агрегатов
и
механизмов
и
простейшим
функциям
управления
(включение/выключение оборудования в заданные моменты времени и т. п.). Для
устранения возникших нештатных ситуаций или аварий обслуживающий персонал
вынужден вызывать квалифицированных специалистов. Для обеспечения работы таких
объектов требуется большая численность персонала, и в целом, весь комплекс
эксплуатационных и противоаварийных мероприятий является дорогостоящим.
Современный уровень развития вычислительной техники и средств связи позволяет
перевести большинство подобных объектов на автоматический режим работы с предоставлением
возможности дистанционного мониторинга и управления сетью объектов с единых
диспетчерских пунктов [13]. Такой подход приводит к снижению затрат на эксплуатацию
объектов, позволяет сократить численность их персонала при одновременном существенном
улучшении
оптимизации
качества
обслуживания,
управления
решении
технологическими
задачи
автоматизированного
процессами.
Получение
учета
и
объективной
информации позволяет реально оценивать истинное состояние объектов и их оборудования,
что обеспечивает принятие обоснованных решений для планирования opганизационнотехнических мероприятий.
Реформа ЖКХ, проводимая в России, делает чрезвычайно актуальной проблематику,
связанную с распределенными информационно-управляющими системами, предназначенными
для управления системами жизнеобеспечения объектов городского хозяйства. В России работы
по созданию экспериментальных систем такого рода ведутся на протяжении последних десяти
лет. Толчком к их развитию послужило принятие в 1996 году закона РФ “Об
энергосбережении”.
Анализ сложившейся ситуации к началу работ по созданию коммерческих систем учета
был выполнен в работах [1], [2]. В этих работах рассмотрена специфика и системные аспекты
создания чисто информационных систем.
Дипломная
работа
посвящена
описанию
опыта
создания
распределенной
информационно-управляющей системы ПоТок-С для филиала ПТС ОАО “Северо-Западный
Телеком”, которая в настоящее время сдана в опытную эксплуатацию. Следует сказать, что
ОАО “Северо-Западный Телеком” была одной из первых организаций в России, в которой в
4
1996
году начались
работы
по
использованию
систем
для
мониторинга
режимов
теплоснабжения и коммерческого учета потребления тепла сооружениями этой организации.
Сложившаяся инфраструктура позволила в рамках выполнения этого проекта провести ряд
исследований и демонстрационных экспериментов, результаты которых представляют интерес
для системных интеграторов подобного рода проектов, а также для целого ряда смежных
областей.
5
1
ОБЗОР
НАУЧНО-ТЕХНИЧЕСКОЙ
ЛИТЕРАТУРЫ
И
ПАТЕНТОВ
1.1 Обзор систем мониторинга и управления распределенными
объектами
Научно-библиографический поиск проводился для обзора современных идей, методов
и примеров практического построения информационных и информационно-управляющих
систем для диспетчерского контроля и управления распределенными объектами. Поиск
вёлся
по
следующим
источникам:
журнал
«Датчики
и
системы»,
журнал
«Энергосбережение», журнал «Системная интеграция», труды конференции «Коммерческий
учет энергоносителей», журнал «Системы Технологической автоматизации», материалы
сайтов www.rtservice.ru, www.logika.spb.ru за период с 2000 по 2005 год.
1.1.1 “КРУГ-2000”
В работе [3] приведено описание программно-технического комплекса серии "Круг2000",
предназначенного
для
автоматизированных
систем
учета
и
диспетчеризации
отпускаемой или потребляемой тепловой энергии ("Круг-2000/Т"), а также добываемого,
перерабатываемого, транспортируемого и потребляемого газа и его компонентов ("Круг2000/Г"). Дано описание преимуществ, функций, типовой структуры комплекса, приведены
технические характеристики и данные об опыте внедрения.
Преимущества, отличительные особенности
- ПТК серии "Круг-2000" сертифицированы, занесены в Гос-реестр средств измерений и
имеют свидетельства об утверждении типа;
- высокая точность расчета энергоносителей;
- быстрая адаптация учета к изменяющемуся гидравлическому режиму контролируемых
сред;
- широкий динамический диапазон измерения расхода;
- возможность проведения метрологической поверки отдельных измерительных каналов
системы в рабочем состоянии, без останова всей системы в целом;
- широкий спектр и масштабируемость выполняемых задач вследствие модульного
6
принципа построения программного обеспечения и однородных технических средств;
- минимизация затрат при монтаже системы и ее дальнейшем развитии за счет
возможности ее поэтапного ввода в эксплуатацию, что обеспечивается модульным
принципом построения ПТК и его распределенной архитектурой;
- снижение издержек на эксплуатацию системы вследствие применения однородных программных и технических средств.
Функции
Коммерческий и технический учет энергоносителей:
- измерение аналоговых электрических сигналов от устройств нижнего уровня и
преобразование их в эквивалентное значение физической величины;
- автоматическое переключение диапазонов измерения составных измерительных
каналов;
- прием цифровой информации от интеллектуальных датчиков по интерфейсам RS-232,
RS-48S и Ethernet, Radio Ethernet.
- вычисление теплофизических параметров теплоносителя;
- вычисление расхода теплоносителя, природного газа и его компонентов в рабочих и
нормальных условиях в трубопроводе или узлах учета любой конфигурации методом
переменного перепада давлений в соответствии с ГОСТ 8.563.2 или методом измерения
по скорости в одной точке сечения трубы в соответствии с ГОСТ 8.361;
- автоматическое определение фазы теплоносителя (воды, перегретого или насыщенного
пара) в узлах учета с нестабильным состоянием измеряемой среды;
- вычисление массы и объема теплоносителя, природного газа и его компонентов;
- вычисление тепловой энергии, отпускаемой или потребляемой с теплоносителем;
- восстановление учетных данных за время простоя системы;
- формирование и вывод на печать отчетных ведомостей в форме, регламентированной
"Правилами учета тепловой энергии и теплоносителя", а также в произвольной форме,
задаваемой самим пользователем.
Регулирование, контроль и управление технологическим оборудованием:
- контроль, дистанционное управление и регулирование по известным законам (ПИ, ПД,
ПИД) исполнительными механизмами;
- реализация противоаварийных защит и блокировок технологического оборудования;
- охранная сигнализация, контроль загазованности и поддержка других функций жизнеобеспечения технологических помещений.
7
Взаимодействие с обслуживающим персоналом:
- визуализация на экранах мониторов операторских станций общих мнемосхем с
динамической индикацией выведенных на них измеряемых и вычисляемых параметров
в цифровом, табличном виде или в виде графиков изменения во времени (трендов);
- ввод в режиме реального времени исходных данных для учета (договорные значения,
коэффициенты и т. п.);
- ведение протокола событий системы;
- формирование световой и звуковой сигнализации при выходе текущих значений
параметров за регламентируемые границы, а также при других нештатных ситуациях
(обрыв связи, выход из строя отдельного модуля и т.п.);
- архивация информации (тренды, отчетные ведомости, протокол событий) на магнитооптический диск, на CDR/RW-диск и на жесткий диск ПК;
- удаленное проведение работ по сервисному обслуживанию абонентов сети системы
(удаленное программирование, работа с файловыми операциями, вызов удаленного
терминала);
- предоставление
информации
пользователям
сети
предприятия
посредством
программного обеспечения "WEB-Контроль";
- передача/прием данных в сторонние системы посредством файл-сервера и ОРС
технологий.
Архитектура
В общем случае автоматизированная система учета энергоресурсов на базе ПТК серии
"Круг-2000"
представляет
собой
многоуровневую
систему
распределенного
типа,
интегрированную в сеть предприятия. Типовая структурная схема такой системы показана на
рисунке 1.1.
Нижний уровень — условно уровень КИП, может быть представлен любыми
устройствами, обладающими выходными аналоговыми сигналами по ГОСТ 26.011 и ГОСТ
6651 или имеющих стандартные интерфейсы RS-232, RS-485 или Ethernet. Такими
устройствами могут быть датчики температуры, давления и разности давлений, газовые
анализаторы и хроматографы, плотномеры, измерители влажности. Кроме того, в устройства
нижнего уровня могут входить различные типы исполнительных механизмов, обладающие
входными/выходными
дискретными
сигналами,
электрозадвижки,
клапаны,
насосное
оборудование, датчики загазованности и т. д.
Средний уровень представлен микропроцессорными контроллерами и/или устройствами
связи с объектом (УСО), которые представляют собой совокупность измерительных модулей
8
ввода/вывода сигналов нижнего уровня. УСО размещаются непосредственно вблизи объекта
автоматизации (узла учета), и выдают управляющие сигналы на исполнительные механизмы,
собирают информацию с датчиков и устройств нижнего уровня, после чего в цифровом формате передают ее в контроллер. Полученные данные обрабатываются в контроллере, где осуществляется вычисление тепло-физических и количественных параметров энергоносителя, а
также реализуются алгоритмы управления исполнительными механизмами.
Верхний уровень — условно операторский, в общем случае выполнен с использованием
архитектуры клиент-сервер и может быть представлен серверами станций оператора-архивирования, станциями оператора-клиентами (СА, СО), станцией инжиниринга и станцией Webконтроля.
Серверы станции оператора-архивирования, обычно выполненные по схеме 100 % "горячего" резервирования и зеркализации, осуществляют ведение сервера базы данных в режиме
реального времени, хранение и заданную обработку данных, поступающих с контроллера.
Станции оператора-клиенты не имеют своего сервера базы данных и предназначены
для визуализации данных с сервера станции оператора-архивирования, обеспечивают
оперативный контроль и диспетчеризацию отпускаемого или потребляемого энергоносителя, а
также дистанционное
управление исполнительными механизмами
и
технологическим
процессом в целом.
Станция инжиниринга и станция Web-Контроля реализуют функции удаленного доступа
к абонентам системы.
Рисунок 1.1 – Типовая структурная схема интегрированной автоматизированной системы
коммерческого учета энергоносителей
9
Технические характеристики ПТК
Период опроса измерительных каналов, с....................................... До 1
Период вычисления количественных параметров
энергоносителя, с............................................................................... 1
Общее количество входных/вьнодных измерительных каналов ... До 30000
Пределы допускаемой основной приведенной погрешности
измерительных каналов ПТК для стандартных сигналов тока,
напряжения, сопротивления в зависимости от типа
используемых УСО, % ....................................................................... 0,025..0,3
Пределы допускаемой основной абсолютной погрешности
преобразования сигналов термопреобразователей сопротивления
в значения температуры в зависимости от типа используемого
контроллера, 'С...............................................................................… 0,2..1
Пределы допускаемой основной абсолютной погрешности
преобразования сигналов термопар в значения температуры в
зависимости от типа используемого контроллера и
нормированной статической характеристики термопары, °С.…… 0,5..5
Пределы допускаемой основной приведенной погрешности
выходных аналоговых сигналов постоянного тока в
зависимости от типа используемых УСО, %............................….. 0,1...0,5
1.1.2 “СИНТАЛ ТЕЛЕТЕРМ”
В работе [4] приведено описание АСУТП нового типа, в которой управление режимами
отопления в распределенных объектах осуществляется дистанционно по радиоканалу.
Преимущества, отличительные особенности
- главная концепция в построения системы — строгий адресный учет отдельных
потребителей электроэнергии и энергосберегающее, с месячной программой, адресное
регулирование подачи электроэнергии к высокоэффективным обогревателям на основе
электродных котлов или длинноволновых потолочных излучателей;
- использование радиоканала для связи управляющего ПК с системой;
- система "СИНТАЛ-ТЕЛЕТЕРМ" предназначена для автоматического поддержания заданной температуры в крупных промышленных и жилых объектах с множеством
помещений или зданий (заводские корпуса, жилые поселки, военные городки);
10
- сбережение
энергии
обеспечивается
автоматическим
выбором
более
низких
температурных уставок в отдельных зданиях, домах и помещениях в отмеченные часы
и дни текущего месяца;
- система работает, используя два уровня автоматического регулирования температуры
объектов. Верхний уровень регулирования в системе осуществляется центральным
компьютером и имеет наивысший приоритет относительно подключенных через GSM
радиоканал локальных терморегуляторов, которые определяют температуру объектов
нижнего уровня управления;
- гибкая архитектура системы СИНТАЛ-ТЕЛЕТЕРМ вытекает из модульности ее
построения.
Функции
- управление локальными объектными модулями от центрального компьютера с GSM
модемом по сотовому каналу;
- прием запросов и команд от центрального компьютера контроллерами ЭЦРТТЕЛЕТЕРМ с помощью GSM модемов и формирование управляющего сигнала для
регуляторов ЭЦРТ-ХРОНО;
- мониторинг состояния сети, напряжения резервного аккумулятора,
температуры
электрооборудования и несанкционированного доступа на теплопункт объекта;
передача на центральный компьютер сообщений о критических ситуациях на объекте;
- измерение температуры объектным модулем по трем каналам;
- управление работой котла с двухтарифным диапазоном регулируемых температур;
- учет суммарных энергозатрат с помощью интерфейса как энергосчетчиками
центрального компьютера, так и путем подсчета времени работы котлов во
включенном состоянии в каждом объектном модуле;
- коммутация силовых цепей котла;
Архитектура
Система состоит из центрального компьютера (сервера), и объектных модулей,
включающих в себя цифровые регуляторы ЭЦРТ-ХРОНО, которые управляют работой котлов в
отдельных зданиях (помещениях). Регуляторы объединены с центральным компьютером через
сотовые каналы связи с помощью GSM модемов, подключенных к контроллерам ЭЦРТТЕЛЕТЕРМ, которые, в свою очередь, управляют работой энергосберегающих регуляторов
ЭЦРТ-ХРОНО. Температура в отопительной системе и в помещениях измеряется цифровыми
датчиками температуры DS18S20 (США).
11
Центральным элементом объектного модуля является контроллер ЭЦРТ-ТЕЛЕТЕРМ.
Фактически — это регулятор температуры с температурной уставкой, задаваемой дистанционно
от компьютера через радиомодем или в простейшем случае от сотового телефона.
Функциональная схема системы СИГНАЛ-ТЕЛЕТЕРМ приведена на рисунке 1.2.
Рисунок 1.2 – Функциональная схема системы СИГНАЛ-ТЕЛЕТЕРМ (объектный модуль)
1.1.3 “КАРАТ”
В работе [5] рассматривается система дистанционного мониторинга и управления
объектами, реализованная для сети тепловых пунктов г. Калининграда. Описана структура
системы
и
её
функциональные
возможности.
Приведены
некоторые
специфические
особенности использования микроконтроллеров фирмы Advantech.
Преимущества, отличительные особенности
- система имеет пространственно распределенную структуру, позволяющую включать в
свой состав до 50 ТК и ДПС (ведущий и резервный диспетчерские пульты,
реализованные на персональных компьютерах);
- осуществление обмена информацией по сети сотовой связи стандарта GSM (дуплексная
связь и SMS-сообщения);
12
- система обеспечивает на нижнем уровне (ТК теплопункта) контроль входных
параметров и формирование аварийных запросов;
Функции
- сбор статистической информации на уровне ТК, формирование буфера параметров
объекта по временным отметкам и хранение записанных в нём данных при отключении
питания;
- реализация функции «черноте ящика» для анализа динамики развития нештатных
ситуаций;
- поддержка ТК протокола системного мониторинга и управления по запросам от ДПС;
- возможность мониторинга любого теплопункта по выбору диспетчера в произвольный
момент времени и постоянный прием аварийных сообщений от ТК (постоянного
мониторинга нет ввиду экономической и функциональной нецелесообразности);
- запрос и прием статистической информации и данных «черного ящика» по инициативе
диспетчера ДПС в любое время или автоматически в заданное время;
- передача аварийных сообщений с ТК на ДПС в течение не менее двух часов при
отсутствии электропитания на теплопункте.
Архитектура
Структура СДМУ, соответствующая выбранной архитектуре, приведена на рисунке 1.3.
Аппаратура СДМУ, устанавливаемая непосредственно на объектах, должна обладать
возможностью гибкого конфигурировании в зависимости от технических особенностей
объекта. Основой такой аппаратуры, как правило, являются технологические контроллеры (ТК).
ТК включает в свой состав:
- программируемый
микроконтроллер
ADAM-55IO
с
8-канальными
модулями
аналогового ввода ADAM-5IH7H и 16-канальными универсальными модулями
дискретного ввода-вывода ADAM-5050 (Advantech);
- модули 4-канального релейного вывода ADAM-3854 (Advantech);
- модем сотовой связи Siemens TC35 Terminal;
- антенну AM M-590 (5 дБ);
- блок питания контроллера и модема PWR-242 (Advamech);
- блок питания датчиков PWR-242;
- преобразователь интерфейса M-bus/ RS-4S5 для связи с теплосчетчиками SKM-I;
- клеммные соединители фирмы WAGО для подключении датчиков и исполнительных
устройств;
13
- блок бесперебойного питания (расположен вне шкафа ТК).
К достоинствам выбранного контроллера следует отнести возможность подключения
достаточно широкого набора модулей промышленного ввода-вывода, что позволяет легко
адаптировать контроллер к особенностям объекта.
В диспетчерском пункте системы теплопунктов г. Калининграда установлены два
компьютера, принтер и блок связи, объединенные локальной сетью. На компьютерах
реализованы диспетчерские пульты (ведущий и резервный). Каждый компьютер получает
информацию со всех теплопунктов, поэтому при отказе одного из компьютеров, в работающем
сохраняется полная картина протекания технологических процессов. Принтер служит для
получения отчетных форм о работе теплопунктов. Блок бесперебойного питания позволяет
функционировать в нормальном режиме при кратковременных сбоях в системе электропитания.
Обозначения: Д1-Дт — дискретные и аналоговые датчики (охранной и пожарной сигнализации, давления,
температуры и др.); ПУЭ1-ПУЭn — приборы контроля и учета потребления энергоресурсов со
стандартным интерфейсом RS-485 (теплосчетчики, электросчетчики и т.п.); 0У 1--0Уi, —
агрегаты и механизмы объекта со стандартными интерфейсами (например частотные
приводы); ОУj -0Уp — коммутационная аппаратура (пусковые контакторы электроприводов
насосов и задвижек); Рм — рабочий модем; ТрМ — «тревожный» модем.
Рисунок 1.3 – Структура системы дистанционного мониторинга и управления
14
1.1.4 “Телескоп +”
В работе [6] рассматривается аппаратно-программный комплекс “Телескоп +” для
дистанционного учета энергоресурсов жилых домов и прочих объектов городского хозяйства.
Преимущества, отличительные особенности
- система имеет пространственно распределенную структуру, позволяющую включать в
свой состав около 100 объектов. Связь со всеми объектами осуществляется с единого
диспетчерского пункта;
- осуществление обмена информацией по радиоканалу (УКВ диапазон), городской оптоволоконной сети и коммутируемой телефонной линии;
- получение информации и ее обработка в реальном времени;
- учет различных видов энергоресурсов;
- использование универсальных вычислителей, что позволяет программировать их
использование на различных конфигурациях трубопроводов;
- дистанционное изменение параметров любого контура регулирования системы.
Архитектура
В настоящее время в «ГТС» эксплуатируются узлы учета энергоресурсов:
- 14 узлов на котельных города, где осуществляется учет произведенной тепловой
энергий и количество затраченного на это газа;
- 52 узла на центральных тепловых пунктах (ЦТП), подмешивающих станциях и
контрольно-распределительных пунктах, обеспечивающих теплом и водой жилые
микрорайоны города;
- 25 узлов общедомового учета (потребляемая тепловая энергия, холодная и горячая
вода).
Использование АПК «Телескоп+» обеспечивает сбор информации со всех объектов в
единый диспетчерский пункт по радиоканалу (УКВ диапазон), городской оптоволоконной сети
и коммутируемая телефонная линия. АПК «Телескоп+» обеспечивает мониторинг процессов на
объектах. Информация отображается на экране ПД в числовой, текстовой или графической
форме на фоне мнемосхемы объектов в режиме реального времени.
АРМ, объединенных с ПД по сети ЛВС, дают возможность получать всю информацию о
состоянии узлов учета и обрабатывать базу данных по всем объектам, в реальном времени.
Пользователь системы может дистанционно изменить параметры регулирования любого
контура регулирования ЦТП (тепловая сеть, холодное водоснабжение, горячее водоснабжение).
15
1.1.5 “ИНТЕК”
В работе [14] описывается новая измерительная система коммерческого учета «ИНТЕК»
(Сертификат об утверждении типа средств измерений RU.C.32.004.A № 14858). Эта система
была разработана при участии ведущих специалистов в области теплотехники, систем
водоучета
и
гидродинамики.
Система
представляет
собой
программно-аппаратный
информационно-вычислительный комплекс, способный решить большинство прикладных
задач.
Преимущества, отличительные особенности
- система «ИНТЕК» полностью сертифицирована и рекомендована к применению
Госстандартом РФ;
- область применения системы не ограничивается только тепло- и водоучетом. Вторая
часть системы «ИНТЕК» — диспетчеризация различных промышленных объектов;
- система
«ИНТЕК» развернута
уже на
многих
объектах
города Москвы и
зарекомендовала себя как простая и надежная система коммерческого учета;
- передача данных по каналам проводной связи, ADSL, GSM, GPRS;
- все протоколы передачи данных являются открытыми. Кроме того, применяются
протоколы,
только
хорошо
зарекомендовавшие
себя
с
точки
зрения
помехозащищенности и устойчивости к сбоям (MODBUS, ProfiBUS);
- все ПО специально разработано для создания подобных приложений. На базе
программного продукта FactorySuite InTouch, который является базовым при
разработке системы «ИНТЕК», построено более 70% проектов АСУ ТП в мире.
Архитектура
Принципиально всю систему можно разделить на две части. Первая отвечает за сбор
данных с приборов учета. Специалистами фирмы «РеалТехноСервис» была разработана
распределенная структура сбора информации с таких элементарных счетчиков. Количество
импульсов, выданных счетчиком, преобразуется в величину потребленной энергии (м3, литры,
КВт) и передается на центральный компьютер. Система функционирует в автономном режиме,
и при отключении ПК информация с приборов учета не теряется. Кроме того, на данный
момент система «ИНТЕК» поддерживает большую номенклатуру приборов учета воды и тепла.
Количество поддерживаемых приборов постоянно растет. Система «ИНТЕК» формирует
отчеты о потреблении энергоносителей за любой промежуток времени и производит
самодиагностику аппаратуры.
16
Система может быть настроена для решения любых задач АСУ ТП, обеспечивая полный
контроль за технологическими процессами производств. Более того, программное обеспечение
настраивается так, что кроме контроля технологических параметров контролируется также и
работа
обслуживающего
персонала.
Наличие
кнопок
дисциплинирующего
контроля,
определение присутствия оператора на рабочем месте —снижает вероятность ошибки
персонала.
В качестве базовых средств среднего уровня автоматизации в системе «ИНТЕК»
использованы высоконадежные контроллеры SCADAPack или DirectLOGIC, выбор которых
осуществляется исходя из условий эксплуатации.
При организации передачи данных в системе «ИНТЕК» предусмотрено несколько
вариантов. Так, например, возможно использование обычных каналов передачи данных (по
проводным линиям связи). Однако в этом случае на реализацию системы накладываются
некоторые ограничения, такие как длина линии (до 1200 метров без повторителей) и сложности
по
прокладке
кабеля.
Поэтому
система
«ИНТЕК»
предусматривает
использование
альтернативных каналов передачи данных, таких как ADSL, GSM, GPRS.
1.1.6 “Логика”
В источнике [15] описывается новая информационно-измерительная система “Логика”
для коммерческого и технического учета энергоресурсов.
Назначение
- коммерческий и технический учет электрической энергии и мощности;
- учет тепловой энергии и массы теплоносителя (воды и пара);
- учет водопотребления и водоотведения;
- учет природного газа и других технически важных газов: воздуха, кислорода, аргона,
азота, ацетилена, окиси углерода, двуокиси углерода, аммиака, водорода, гелия, хлора,
метана, этилена, доменных и коксовых газов;
- учет стабильных и нестабильных газовых конденсатов и широких фракции легких
углеводородов.
Преимущества, отличительные особенности
- ИИС ЛОГИКА компонуется на объекте из серийно-выпускаемых агрегатных средств;
- преобразования выходных сигналов датчиков физических величин в цифровую форму
и вычислительные функции тех или иных подсистем или узлов учета (например,
17
подсистемы учета электрической энергии или узла
выполняются
специализированными
вычислителями
учета природного газа)
производства
ЗАО
НПФ
ЛОГИКА;
- сбор
и
соответствующее
представление
информации
обеспечивается
единым
программным комплексом СПСеть;
- температура окружающего воздуха - от минус 10 до 50 °С;
- ИИС ЛОГИКА отвечает современным стандартам и другим нормативным документам;
- при применении метода переменного перепада давления, вычисления расхода
измеряемой среды ведутся по ГОСТ 8.563.1-97.
Функциональные возможности
- все необходимые количественные данные, на основании
которых
возможно
осуществление взаимных расчетов между поставщиками и потребителями того или
иного
ресурса
или
услуги,
в
ИИС
ЛОГИКА
формируются
на
уровне
специализированных вычислителей: приборов типа СПЕ для учета электрической
энергии, СПТ для учета тепловой энергии и теплоносителя, СПГ для учета технически
важных газов и газоконденсатных смесей;
- глубина хранения получасовых архивов от 7 до 45 суток в зависимости от количества
обслуживаемых каналов; суточных архивов от 35 до 185 суток; месячных архивов 6
месяцев;
- поддерживается обмен данными между каждым прибором типа СПЕ, СПТ, СПГ и
локальным компьютером по стандарту RS232C или, с применением специальных
адаптеров, по RS485;
- поддерживается обмен данными между каждым прибором СПЕ, СПТ, СПГ и
удаленным компьютером по коммутируемым и некоммутируемым линиям связи, а
также по радиоканалу. Модем подключается к приборам по стандарту RS232;.
- при подключении нескольких компьютеров к группе приборов, пользователям
обеспечивается одинаковый уровень доступа к данным, если иное специально не
оговорено.
Аппаратное обеспечение ИИС ЛОГИКА показано на рисунке 1.4.
18
Рисунок 1.4 – Аппаратное обеспечение ИИС ЛОГИКА
1.1.7 Выводы
В таблице 1.1 приведено краткое описание ряда эксплуатирующихся в настоящее время
систем класса ИС и ИУС.
Примеры систем, представленные в обзоре, отражают ряд характерных тенденций в
развитии систем коммерческого учета. Отобранные примеры отражают отчетливую тенденцию
перехода от чисто информационных систем (ИС) к информационно-управляющим системам
(ИУС), так как только последние обеспечивают возможность реальной экономии средств.
Второй вывод, который следует из обзора, заключается в том, что до настоящего
времени ведется как выбор каналов связи для сбора информации с объектов и передачи команд
управления, так и аппаратного обеспечения нижнего уровня.
Следует отметить одну важную особенность систем подобного рода. В силу
значительного масштаба и
достаточно большой
стоимости эти
значительной
смысле
изменения
инерцией
в
возможности
в
системы обладают
однажды
принятых
концептуальных решениях. В силу этого с практической точки зрения представляет интерес
анализ особенностей систем, используемых на практике.
19
Таблица 1.1 – Характеристика систем
Название
Назначение
КРУГ
2000
ИУС для коммерческого
учета тепловой энергии и
газопотребления
для крупных
промышленных
предприятий
Синтал
Телетерм
ИУС для автоматического
регулирования тепловых
режимов крупного
сооружения
(Дворец спорта в г.
Волгограде),
отапливаемого
электрокотлами
КАРАТ
Автоматизированная
система
контроля
и
коммерческого
учета
режимов теплоснабжения
городских
объектов
городской
инфраструктуры
(г.Калининград).
Телескоп+ Автоматизированная ИУС
для коммерческого учета
потребляемых
энергоресурсов и воды и
регулирования тепловых
режимов объектов ЖКХ
(г.Сургут)
Верхний
уровень
системы
ЛВС (сеть
предприятия) с
возможностью
входа сторонних
пользователей
посредством
браузера Internet
ПК c ПО,
обеспечивающем
мониторинг
состояния
объектов,
задание режимов
регулирования,
дистантное
управление,
обработку
учетной
информации
Ведущий и
резервный
диспетчерский
пульты,
реализованные на
ПК, об. по ЛВС
Нижний
уровень
системы
Цифровые
интеллект.
датчики и
контроллеры с
интерфейсами
RS-232,RS485,Ethernet
Цифровые
регуляторы
ЭЦР-ХРОНО
подкл. к
контролл.
ЭЦРТТЕЛЕТЕРМ
Коммуникация
Количество
узлов
Витая пара и
локальные
проводные
соединения
Проектная
спецификация
- до 30 000.
Радиоканал на
GSM модемах
В системе
используется
96 датчиков
DS18S20 и
17 силовых
шкафов
управления
электрокотлами.
Шкаф
управления
На базе
ADAM –5510
ADAM-501H
ADAM-5050
ADAM3854
сети сотовой
связи GSM на
модемах
Siemens TC35
Terminal
Проектная
спецификация
до 50
теплопунктов
АРМ ы
диспетчеров,
операторов и
пользователей
системы
Контроллеры
ПИК-УВП,
ПИК2
Сбор
информации
осуществляетс
я по
радиоканалу
(УКВ), комм.
тел. линия,
оптоволокно
100 узлов
«Интек»
ИУС тепло- и водоучета,
диспетчеризация
различных промышленных
объектов.
центральный
компьютер с ПО
обеспечивающим
мониторинг.
Возможно
управление
процессами
контроллеры
SCADAPack
или
DirectLOGIC,
приборы учета
воды и тепла,
оборудование
SonyEriccson,
Wavecom для
передачи по
GSM каналу
каналы
проводной
связи, ADSL,
GSM, GPRS
До 500 (по
GSM каналу)
Логика
Информационноизмерительная система
коммерческого и
технического учета
энергоресурсов
сбор и
соответствующее
представление
информации
обеспечивается
единым
программным
комплексом
СПСеть
серийновыпускаемые
спец.
вычислители,
преобразовател
и, счетчики
ЗАО НПФ
ЛОГИКА
Коммутируем
ые и
некоммутируе
мые линии
связи,
радиоканал.
неизвестно
20
1.2 Обзор контроллеров и встраиваемых компьютеров
Научно-библиографический поиск проводился для обзора современных контроллеров и
встраиваемых компьютеров (включая примеры использования специализированных роботов),
используемых для работы в составе информационно-управляющих системах. Поиск вёлся по
следующим источникам: каталог «RTSoft Средства и системы автоматизации. Каталог
продукции», журнал «Системная интеграция», труды конференции «Коммерческий учет
энергоносителей», материалы сайтов www.English.Eastday.com, www.Tral.ru, www.mzta.ru,
www.Prosoft.ru, www.nevabls.ru за период с 2002 по 2005 год.
1.2.1 Контроллер ThinkIO
В источнике [16] рассмотрен контроллер ThinkIO. ThinkIO— это комбинация
стандартного компьютера (на базе процессора класса Intel® Pentium MMX 266 МГц) с
модульными системами WAGO-IO/-SYSTEM 750 и 753.
WAGO-I/O-SYSTEM 750 и 753 — миниатюрные модульные системы ввода/вывода для
распределенных систем управления, не зависящие от типа промышленных шин. Они позволяют
создавать экономичные и компактные узлы ввода/ вывода на базе сочетающихся друг с другом
специализированных модулей цифрового и аналогового ввода/ вывода.
Конфигурирование
ThinklO
может
осуществляться
с
помощью
системы
программирования PLC CoDeSys, удовлетворяющей требованиям стандарта IEC 61131-1.
В контроллере ThinklO имеются порты USB, 2xEthernet, RS232, DV1 и внешний
сторожевой таймер, обеспечивая поддержку промышленных шин типа PROFUBUS-DP,
CANopen или DeviceNet.
Внешний вид контроллера ThinkIO представлен на рисунке 1.5.
Технические характеристики
Подключение устройств
- Два канала цифрового ввода и вывода с опторазвязкой
Коммутационные модули (интерфейсы)
- 2x USB 1.1;
- 1x nopTRS232;
- 2x 10Base-T/lOOBase-TX Fast Ethernet;
- 1x DVI-I.
Системные устройства
21
- Внешний сторожевой таймер;
- Кнопка пуска/останова;
- Кнопка сброса.
Системный процессор
- Geode 5C1200 (266 МГц) и интегрированный микропроцессорный набор AMD;
- Кэш: 16 Кбайт L1.
Память
- Загрузочный встроенный флэш-диск 32/128 Мбайт;
- SDRAM:
32/128 Мбайт;
- RAM:
128 Кбайт с аккумуляторным питанием;
- CompactFlash Type I/II.
Внешние шины
- PROFIBUS-DP Master/Slave;
- CANopen Master/Slave;
- DeviceNet Master/Slave.
Корпус
- Размеры 160 x 70 x 95 мм
Операционная система
- Поддержка Windows CE;
- Поддержка Linux.
Программное обеспечение
- Среда программирования CoDeSys со средствами визуализации целевых систем;
- IEC 61131-З/lSaGraf;
- ОРС Driver;
- SOPH.I.A.;
- CFC 6 (вариант языка FBD).
Рисунок 1.5 – Внешний вид контроллера ThinkIO
22
1.2.2 Роботы для слежения за электрической сетью
В источнике [17] говорится о том, что в Китае разработан работ для слежения за
электрической сетью.
Ученые
восточной
провинции
Китай
Шандонг
объявили,
что
закончились
десятидневные испытания робота, следившего за трансформаторной подстанцией напряжения
500000 Вольт.
Четырехколесный робот, разработанный Шандонгским научно-исследовательским
центром электрической энергии, - первый робот в стране, который был использован для
ведения наблюдения поблизости от сильных магнитных полей трансформаторной подстанции,
работающей под высоким напряжением.
В Китае до сих пор трансформаторные подстанции обслуживались только людьми,
безопасность которых не была гарантирована из-за сетей, постоянно находящихся под высоким
напряжением, и часто тяжелых погодных условий.
Ученые из Шандонгского центра заявили, что во время проведения эксперимента робот
мог как выполнять функции рабочих самостоятельно, так и подчиняться командам рабочих. Он
сразу же реагировал на перегревы, любое постороннее тело, попадавшее на провода и т.д.
После того, как технология будет отлажена, вероятно, будет налажено массовое
производство робота, заявила группа ученых.
1.2.3 Контроллер SCADAPack
В работе [18] рассмотрены контроллеры SCADAPack, поставляемые компанией
«ПЛКСистемы», благодаря своим характеристикам и возможностям, успешно применяются в
системах коммерческого учета самого различного назначения.
Контроллеры
сертифицированных
SCADAPack
системах
стали
«ЭКОТЭЛ»
базовым
(ООО
средством
«Фирма
РКК»),
автоматизации
«ИНТЭК»
в
(ООО
«Реалтехносервис»), предназначенных для сбора данных и диспетчерского управления в
коммунальном хозяйстве, химической, газовой и нефтяной промышленности, а так же на
других
объектах
энергопотребления
(энергоснабжения),
требующих
комплексной
автоматизации при ведении многотарифного учета для оптимизации финансовых затрат по
оплате полученных (оглушенных) энергоресурсов. Эти системы позволяют вести оперативный
учет потребленных энергоносителей, осуществлять контроль параметров горячего и холодного
водоснабжения, отопления.
23
Четыре серии контроллеров SCADAPack позволяют строить системы телемеханики и
SCADA-системы, различные по своим функциям и возможностям. К одному котроллеру
SCADAPack может быть подключено до 40 дополнительных модулей, что позволяет
обрабатывать свыше 1100 каналов ввода/вывода.
Коммутационные возможности позволяют организовывать
устойчивую
связь
с
технологическими объектами по любым каналам связи.
Помехозащищенное исполнение позволяет размещать контроллеры SCADAPack вблизи
силового оборудования.
Контроллеры SCADAPAck сочетают свойства RTU, высокую производительность и
возможность свободного программирования современных промышленных компьютеров, что
отличает их от традиционных контроллеров телемеханики.
Контроллеры SCADAPack соответствуют требованиям открытых систем, легко
интегрируются в существующие комплексы АСУТП и взаимодействуют со средствами
автоматизации других производителей.
Надежность,
возможность
дистанционной
диагностики
и
программирования
существенно снижают затраты при эксплуатации автоматизированной системы. Контроллеры
SCADAPack рассчитаны на применение в долгосрочных проектах.
Технические характеристики
Подключение устройств
- до 40 дополнительных модулей;
- возможность обрабатывать свыше 1100 каналов ввода/вывода.
Коммутационные модули
- радиомодемы;
- модемы для выделенных и коммутируемых телефонных линий;
- модули Ethernet;
- возможно подключение различных типов радиостанций;
- работа через спутниковую и сотовую связь;
- возможность программирования на переключение на альтернативный канал связи в
случае необходимости.
Системный процессор
- 32-разрядный процессор 120 МГц
Память
- RAM:
8 Мбайт с аккумуляторным питанием;
- Flash:
4 Мбайт;
24
Поддерживаемые протоколы
- Modbus RTU/ASC1I/TCP/UDP;
- DNP3;
- DF1;
- HART;
- На языке C/C++ возможно написание собственных протоколов для подключения
интеллектуальных устройств с нестандартными интерфейсами.
Рабочий температурный диапазон:
- 40 .. +70 °C
Операционная система
- нет
Программное обеспечение
- язык релейной логики;
- C/C++;
- IEC 61131-З/lSaGraf.
1.2.4 Одноплатный компьютер NetCore
В источнике [19] рассмотрен вычислитель NetCore - одноплатный компьютер на базе
процессора AMD Alchemy Au1000 - процессор класса «система на кристалле» (SOC) с набором
инструкций MIPS32™, включающий усовершенствованное ядро центрального процессора,
адаптированный
контроллер
памяти
и
комплект
стандартных
коммуникационных
периферийных модулей.
Применение одноплатных компьютеров NetCore в таких областях, как автоматизация
технологических
процессов,
сбор
и
обработка
данных,
управление
оборудованием,
испытательные системы, общественный транспорт, информационные системы и мобильная
техника делают его экономически-эффективной встраиваемой платформой. Операционная
система Linux 2.4 позволяет компьютеру реализовать перечисленные задачи.
Устройство
позволяет
обрабатывать
и
накапливать
потоки,
поступающие
по
последовательным интерфейсам и передавать их в локальную сеть. NetCore обладает мощными
вычислительными ресурсами и ОС Linux это позволяет решать прикладные задачи с
поступающими потоками (ведение баз данных и их первичная обработка). В частности в
проекте "интеллектуальное здание" устройство используется для сбора информации с электрои теплосчетчиков.
Внешний вид одноплатного компьютера NetCore представлен на рисунке 1.6.
25
Особенности одноплатных компьютеров NetCore
-
низкая потребляемая мощность;
-
повышенная эксплуатационная надежность;
-
безвентиляторное охлаждение;
-
расширенный диапазон рабочих температур;
-
малые габаритные размеры;
-
наличие аппаратного Watchdog.
Технические характеристики
Коммутационные модули (интерфейсы)
- Ethernet 10/100;
- RS232;
- RS485;
- USB-A/B (USB 1.1);
- IDE.
Системный процессор
- 300/500MHz, MIPS32™
Память
- RAM:
до 64 Мбайт;
- Flash:
до 16 Мбайт.
Корпус (печатная плата)
- печатная плата размерами 120x93x14мм;
- печатная плата, смонтированная в металлическом корпусе 180x100x30мм;
- большой корпус 240x160x100мм с возможность установки RACK для 2" или 3.5"
винчестера.
Операционная система
- Linux 2.4
Программное обеспечение
- C/C++;
- ПО совместимое с Linux.
Рисунок 1.6 – Внешний вид одноплатного компьютера NetCore
26
1.2.5 Микроконтроллер InorTek µC-Series
В источнике [20] представлен микроконтроллер iNorTek µC-Series. iNorTek µC-Series это
мощный
программно-аппаратный
комплекс,
состоящий
из
промышленного
микроконтроллерного комплекта и системы разработки целевых приложений на языках
программирования C/C++.
Внешний вид контроллера InorTek µC-Series представлен на рисунке 1.7.
Преимущества применения
- высокая надёжность;
- простое тиражирование, расширение и обслуживание устройств управления;
- упрощение монтажа и ввода в эксплуатацию целевых систем;
- быстрое обновление алгоритмов управления (в том числе и на работающем оборудовании);
- высокая функциональность;
- открытое программное обеспечение, разработка целевых приложений на языках C/C++;
- наличие 3-х независимых шин расширения, что позволяет использовать данный контроллер
как для построения локальных систем регулирования, так и для сложных, распределенных
систем АСУТП.
Технические характеристики
Подключение устройств
- до 8-и 12-ти разрядных встроенных универсальных каналов аналогового ввода
(напряжение/ток/сопротивление
-
определяется
типом
мезонинной
платы
расширения);
- до 4-х 12-ти разрядных встроенных каналов аналогового вывода (4..20mA);
- до 10-ти встроенных каналов дискретного ввода, типа "сухой контакт"
(гальваническая развязка, 3 - 50В);
- до 10-ти встроенных каналов дискретного вывода, типа "открытый коллектор"
(гальваническая развязка, до 250мА);
Коммутационные модули (интерфейсы)
- Широкие сетевые возможности (Web-сервер, e-mail, SMS, FTP);
- шина расширения MODBUS/TCP (Ethernet, XPort™ LANTRONIX);
- MODBUS/RS (оптически изолированный интерфейс RS-485, до 254 узлов сети,
витая пара, до 115200 Бод) для организации распределенных систем сбора данных
и управления объектами с визуализацией данных на диспетчерских системах
27
верхнего уровня (SCADA системы).
Системные устройства
- Сторожевой таймер;
- Часы реального времени и календарь.
Системный процессор
- микроконтроллер i80C188
Память
- RAM:
до 512/256 Кбайт;
- EEPROM:
до 64 Кбайт.
Корпус
- 157мм x 86мм x 59мм;
- монтаж на DIN-рейку.
Рабочий температурный диапазон
- -25...+55°C
Питание
- ~12B;
- потребляемая мощность - до 3Вт.
Пользовательский интерфейс
- 2-х строчный дисплей;
- 9-ти кнопочная клавиатура для диагностики.
Операционная система
- нет
Программное обеспечение
- C/C++;
- Встроенные стандартизованные библиотеки адаптивного ПИ/ПИД-регулирования,
ШИМ-управления и пр.
Рисунок 1.7 – Внешний вид контроллера InorTek µC-Series
28
1.2.6 Контроллер измерительный "КОНТАР" МС8
В источнике [21] представлен контроллер измерительный "КОНТАР" МС8. Комплекс
модулей "КОНТАР" — совместная российско-американская разработка (МЗТА – Arecont
Systems, Inc) — основан на новейших информационных технологиях и уже проверен во многих
проектах
различной
сложности
(системы
жизнеобеспечения
зданий,
объекты
ЖКХ,
автоматизация цехов и т.п. в России и США).
Контроллеры измерительные МС8 (далее МС8) предназначены для сбора информации и
реализации разнообразных алгоритмов автоматизированного управления технологическими
процессами. Контроллеры МС8 являются основным (базовым) элементом комплекса КОНТАР.
Контроллеры комплекса "КОНТАР" прошли сертификационные испытания как средство
измерения и на электромагнитную совместимость в России и США. Имеется разрешение на их
использование на объектах, подведомственных ГОСГОРТЕХНАДЗОРу.
Идеология построения MC8 позволяет использовать его как в качестве автономного
контроллера, так и объединять нужное количество контроллеров в локальные сети и сложные
иерархические системы, осуществлять управление и сбор информации от разнообразных
источников,передачу ее по единому каналу связи, в том числе с использованием сети Интернет.
Внешний вид контроллера "КОНТАР" МС8 представлен на рисунке 1.8.
Основные функции
- измерение и преобразование в цифровую форму сигналов, поступающих от аналоговых и
дискретных датчиков технологических параметров;
- формирование дискретных и аналоговых выходных сигналов для воздействия на
технологический процесс;
- реализация алгоритмов функционирования, необходимых для управления конкретными
технологическими процессами (например, аналоговое или импульсное ПИД-регулирование,
различные виды формирования задания, в том числе с возможностью изменения в реальном
времени, программно-логическое управление, автоматическое включение резервного
оборудования и т.д.);
- архивирование событий во внутренней памяти контроллера;
- вывод информации на дисплей встроенного пульта оператора, карманного компьютера
(PDA) или на экран монитора персонального компьютера через интерфейс RS232C, Ethernet;
- обеспечение связи через различные интерфейсы (RS485 между контроллерами и другими
модулями, RS232С с периферийными устройствами, Ethernet при работе в локальной сети и
сети Интернет).
29
Технические характеристики
Подключение устройств
- 4 дискретных входов;
- 8 аналоговых входов;
- 8 дискретных выходов;
- 8 аналоговых выходов.
Коммутационные модули (интерфейсы)
-RS232С;
- RS485, с гальванической изоляцией;
- Ethernet.
Модули расширения
- Интерфейсный субмодуль WebLinker (Ethernet и RS232C);
- коммуникационный модуль (GPRS/CDMA);
- Пульт MD8.2 (внешний) Применяется для щитового утопленного монтажа.
Соединение
пульта
с
контроллером
осуществляется
через
интерфейсный
субмодуль SPI.
Системные устройства
- Часы реального времени и календарь;
Системный процессор
- Информация отсутствует;
Память
- 60кБайт - для алгоритма и его описания;
- 30кБайт - для архивирования.
Корпус
- 157мм x 86мм x 58,5мм;
- Монтаж на DIN-рейку по стандарту DIN EN 50 022; Степень защиты IP20.
Питание
- ~220B (~24В);
- потребляемая мощность не более 6ВA.
Пользовательский интерфейс
- 2-х строчный дисплей;
- 4-х кнопочная клавиатура для диагностики;
- Индикация – 8 светодиодов состояния дискретных выходов.
Операционная система
- ОС записывается в контроллер производителем и не может быть изменена
30
потребителем;
- обеспечивает связь с другими контроллерами внутри сети, между контроллером и
оборудованием;
- функция самодиагностики.
Программное обеспечение
-
Функциональный
алгоритм
разрабатывается
при
помощи
графической
инструментальной системы КОНГРАФ;
- Алгоритмы функционирования, необходимых для управления конкретными
технологическими процессами (например, аналоговое или импульсное ПИДрегулирование).
Рисунок 1.8 – Внешний вид контроллера "КОНТАР" МС8
1.2.7 Встраиваемый компьютер (контроллер) UN0-2160
В источнике [22] рассмотрен UN0-2160 – встраиваемый компьютер (контроллер) с двумя
слотами расширения PCI/104.
Внешний вид встраиваемого компьютера UN0-2160 представлен на рисунке 1.9.
Технические характеристики
Подключение устройств
- 4 канала дискретного ввода с гальванической изоляцией;
- 4 канала дискретного вывода с гальванической изоляцией;
- Поддержка протоколов ModBus/RTU и ModBusACP.
Коммутационные модули (интерфейсы)
- 2x Ethernet 10/100;
- 2x RS232;
- 2x RS232/ RS422/RS485;
- 2x USB-A/B.
Системные устройства
31
- 2 слота расширения PCI/104;
- Гнездо для установки карт PCMCIA типа I/II;
- Встроенная поддержка модулей серии ADAM;
- 2 счетчика/таймера (16 разрядов).
Системный процессор
- Celeron 400/650 МГц
Память
- RAM:
256/512 Мбайт;
- SRAM: 512 Rбайт с резервным питанием от батарейки.
Операционная система
- Windows CE .NET 4.2;
- Windows XP Embedded.
Программное обеспечение
- Драйверы устройств для Windows 2000/XP;
- ПО совместимое с Windows XP Embedded/CE.
Рисунок 1.9 – Внешний вид встраиваемого компьютера UN0-2160
1.2.8 Встраиваемый компьютер (контроллер) UN0-2050
В источнике [22] рассмотрен UN0-2050 – встраиваемый компьютер (контроллер) UNO
со встроенными каналами ввода-вывода.
Внешний вид встраиваемого компьютера UN0-2050 представлен на рисунке 1.10.
Технические характеристики
Подключение устройств
- 8 изолированных дискретных входов с поддержкой счетчиков/таймеров;
- 8 изолированных дискретных выходов;
- Поддержка протоколов ModBus/RTU и ModBusACP.
32
Коммутационные модули (интерфейсы)
- 2x Ethernet 10/100;
- 2x RS232;
- 2x RS232/ RS485 с гальванической изоляцией до 2000 В.
Системные устройства
- Соединитель DB-15 VGA;
- 2 счетчика/таймера (16 разрядов).
Системный процессор
- GX1 300 МГц
Память
- RAM:
64/128 Мбайт
Операционная система
- Windows CE .NET
Программное обеспечение
- ПО совместимое с Windows CE .NET
Рисунок 1.10 – Внешний вид встраиваемого компьютера UN0-2050
1.2.9 Встраиваемый компьютер (контроллер) UN0-2052
В источнике [22] рассмотрен UN0-2052 – встраиваемый компьютер (контроллер) UNO
со встроенными каналами ввода-вывода и CAN-интерфейсом.
Внешний вид встраиваемого компьютера UN0-2052 представлен на рисунке 1.11.
Технические характеристики
Подключение устройств
- 4 канала дискретного ввода с гальванической изоляцией;
- 4 канала дискретного вывода с гальванической изоляцией;
- 2 канала аналогового ввода;
- 2 порта с интерфейсом CAN;
33
- Поддержка протоколов ModBus/RTU и ModBusACP.
Коммутационные модули (интерфейсы)
- Ethernet 10/100;
- RS232.
Системные устройства
- Соединитель DB-15 VGA;
- Встроенная поддержка модулей серии ADAM;
- 2 счетчика/таймера (16 разрядов).
Системный процессор
- GX1 300 МГц
Память
- RAM:
64/128 Мбайт
Операционная система
- Windows CE .NET
Программное обеспечение
- ПО совместимое с Windows CE .NET
Рисунок 1.11 – Внешний вид встраиваемого компьютера UN0-2052
1.2.10 Универсальный логический модуль Siemens LOGO!
В источнике [22] рассмотрены логические модули LOGO!. Универсальные логические
модули LOGO! предназначены для замены традиционных схем управления, выполненных на
основе реле, контакторов и подобных им устройств. Алгоритм функционирования модулей
задаётся программой, составленной из набора встроенных функций, который включает в себя
самые распространённые на практике логические функции, в том числе шесть базовых (AND,
OR, NOT, NAND, NOR, XOR), а также ряд специализированных функций (задержка включения
и выключения, импульсное реле, выключатель с часовым механизмом, реле с самоблокировкой,
тактовый генератор и др.).
Для хранения управляющей программы в модуле имеется встроенное энергонезависимое
34
запоминающее устройство (EEPROM). Создание резервной копии программы, а также перенос
её на другие модули LOGO! могут быть осуществлены с помощью специального модуля
памяти.
Внешний вид логического модуля Siemens LOGO! представлен на рисунке 1.12.
Преимущества применения
- высокая надёжность;
- упрощение монтажа и ввода в эксплуатацию целевых систем;
- увеличение количества обслуживаемых входов/выходов обеспечивается с помощью модулей
расширения;
- модули LOGO! имеют морские сертификаты (ABS, BV, DNV, GL, LRS), сертификаты UL,
CSA и FM, маркировку СЕ, отвечают требованиям стандартов VDE 0631, IEC 1131, EN 55011
(класс В), ГОСТ Р 50377-92, ГОСТ 28244-89, ГОСТ 29216-91 (сертификат № РОСС
DE.ME20.B00820).
Технические характеристики
Подключение устройств
- 8 каналов дискретного ввода (релейные или транзисторные);
- 4 канала дискретного вывода (релейные или транзисторные);
- Релейные выходы имеют нагрузочную способность до 10 А для активной и до 3 А для
индуктивной нагрузки, а транзисторные выходы -до 0,3 А при 24В;
- разъём для подключения модуля памяти или компьютера.
Коммутационные модули (интерфейсы)
- Интерфейс для связи с ПК
Модули расширения
Увеличение
-
количества
обслуживаемых
входов/выходов
(Максимальная
конфигурация при этом: 24 дискретных и 8 аналоговых входов, 16 дискретных и 2
аналоговых выхода)
Системные устройства
- встроенные часы реального времени
Системный процессор
- Информация отсутствует
Память
- встроенное энергонезависимое запоминающее устройство (EEPROM);
- максимальный объём программы до 130 функциональных блоков.
35
Корпус
- 72 x 90 x 55 мм (ШхВхГ);
- крепёжный узел для монтажа на 35 мм профильную DIN-шину;
- степень защиты корпуса IP20.
Рабочий температурный диапазон
- 0...+55°C
Пользовательский интерфейс
- ЖК дисплей;
- клавиатура.
Операционная система
- нет
Программное обеспечение
- 8 основных и 28 специальных функций;
- для разработки и отладки программ предназначен программный пакет LOGOISoft
Comfort. Пакет позволяет осуществлять графический ввод и редактирование
программы, а также отладку программы в режиме эмуляции логического модуля.
Готовая программа может загружаться в память логического модуля через
специальный кабель или записываться в модуль памяти через специальное
устройство LOGOIProm.
Рисунок 1.12 – Внешний вид логического модуля Siemens LOGO!
1.2.11 Программируемый контроллер Siemens Simatic S7-200 CPU226
В источнике [22] рассмотрены логические контроллеры SIMATIC S7-200, которые
предназначены для построения относительно простых систем автоматического управления,
отличающихся минимальными затратами на приобретение аппаратуры и разработку системы.
Контроллеры способны работать в реальном масштабе времени и могут быть использованы как
для построения узлов локальной автоматики, так и узлов, поддерживающих интенсивный
коммуникационный обмен данными через сети Industrial Ethernet, PROFIBUS-DP, МPI, AS-
36
lnterface, PPI, а также через модемы.
Внешний вид контроллера Siemens Simatic S7-200 представлен на рисунке 1.13.
Технические характеристики
Подключение устройств
- 24 канала дискретного ввода;
- 16 каналов дискретного вывода;
- поддержка протоколов USS или ModBus.
Модули расширения
- увеличение количества входов/выходов (Максимальная конфигурация: 128 дискретных и 28 аналоговых входов, 112 дискретных и 7 аналоговых выхода)
Коммутационные модули (интерфейсы)
- 2x RS485
Системные устройства
- 6 счетчиков/таймеров (30 кГц);
- встроенные часы реального времени.
Системный процессор
- процессор, способный выполнять операции над числами с плавающей запятой и
поддерживающие алгоритм ПИД-регулирования;
- время выполнения логической команды 0,22 мкс.
Память
- EEPROM:
24 КБайт;
- Память данных:
10 КБайт;
- Буферизация данных: 100 ч.
Корпус
- Размеры: 196мм x 80мм x 62мм;
- Монтаж на 35 мм DIN-шину или на плоскую поверхность;
- Степень защиты корпуса IP20.
Рабочий температурный диапазон
- 0...+55°C
Питание
- ~115/230B;
- 24В (постоянный ток).
Операционная система
- Информация отсутствует
37
Программное обеспечение
- Для разработки и отладки программ предназначен программный пакет STEP 7
Micro/Win. Поддержка языков LAD (релейно-контактные схемы), STL (список
инчтрукций), FBD (функциональных блоковых диаграмм)
Рисунок 1.13 – Внешний вид контроллера Siemens Simatic S7-200 CPU226
2.2.12 Выводы
В современных системах коммерческого учета контроллеры становятся одним из
наиболее важных компонентов, промежуточным звеном в цепи обмена данными между
полевым оборудованием (теплосчетчиками, электросчетчиками, датчиками и исполнительными
механизмами) и средствами АСУ ТП верхнего уровня (рабочими станциями технологов,
серверами, офисными компьютерами управленческих, коммерческих и технических отделов). В
таблице 1.2 приведена сравнительная характеристика различных контроллеров и встраиваемых
компьютеров.
Обзор контроллеров и встраиваемых компьютеров показал, что в настоящее время
существует множество аппаратно-программных решений для применения в системах
дистантного мониторинга и управления. Продукция различных производителей обладает
схожими функциональными возможностями, однако отличается в аппаратной реализации и
стоимости.
Ключевым звеном подобных устройств является микропроцессорная платформа
(совокупность аппаратно-программных возможностей устройства, используемой операционной
системы и средств разработки программного обеспечения), от которой часто зависит
возможность применения устройства в конкретной системе. Одним из основных факторов
выбора контроллера или встраиваемого компьютера является возможность простой, быстрой и
качественной разработки программного обеспечения (ПО). Производители предлагают
широкий ассортимент программно-инструментальных средств разработки ПО для их
продукции. Однако, эти средства, как правило, для устройств конкретного производителя
уникальные, и стоимость их может быть на порядок дороже самих устройств.
38
Таблица 1.2 – Сравнение характеристик различных контроллеров и встраиваемых компьютеров
Название Тип Процессор
ThinkIO
К
Коммуникация
2xUSB1.1, RS232,
2xEthernet 10/100,
PROFIBUS-DP,
CANopen,
SCADAPack К 32RAM: 8 Мб,
Ethernet, модули для
разрядный, Flash: 4 Мб
работы с
120 МГц
радиомодемами,
спутниковой и
сотовой связью
NetCore
ВК 300/500
RAM: до 64 Мб, Ethernet 10/100,
МГц,
Flash: до 16 Мб RS232, RS485,
MIPS32
USB 1.1, IDE
InorTek
К МикроRAM: до 512
MODBUS/RS, Ethernet
контроллер Кб,
10/100
i80C188
EEPROM: до
64 Кб
"Контар"
К неизвестно Flash: 60 Кб,
RS232, RS485
МС8
RAM: 30Кб
Ethernet 10/100,
UN0-2052
Siemens
Simatic S7200
Geode
5C1200,
266 МГц
Память
ВК GX1 300
МГц
К
20 МГц
SDRAM: 128
Мб
RAM: 128 Кб
RAM: 64/128
Мб
EEPROM: 24
Кб,
SRAM: 10 Кб
ModBus/ RTU, 2x
CAN, Ethernet 10/100,
RS232
2x RS485
К – контроллер; ВК – встраиваемый компьютер.
39
Вводы/
выводы
2xDI,
2xDO
ОС/мОСРВ
до 40
модулей
нет
язык релейной логики,
C/C++, lSaGraf
~300
нет
Linux 2.4
C/C++, ПО совместимое с
Linux
250 - 300
8xAI,
4xAO,
10xDI,
10xDO
8xAI,
8xAO,
4xDI,
8xDO
нет
2xAI,4xDI
4xDO
24xDI,
16xDO
Windows CE,
Linux
Средства разработки
ПО
CoDeSys, lSaGraf, ОРС
Driver, SOPH.I.A., CFC 6
Цена, $
~1000
C/C++, встроенные
библиотеки ПИ/ПИДрегулирования, ШИМуправления
Уникальная, КОНГРАФ, Алгоритмы
записана
для управления
производи- конкретными
телем
технологическими
процессами
Windows CE ПО совместимое с
.NET
Windows CE .NET
215 - 359
неизвестно
неизвестно
STEP 7 Micro/Win, LAD,
STL (список инструкций),
FBD
400 - 550
неизвестно
2 ПОСТАНОВКА ЗАДАЧИ
Дипломная работа была выполнена в рамках проекта по модернизации существующей (и
эксплуатирующейся) распределенной информационной системы ПТС-1 для филиала ПТС
(Петербургские Телефонные Сети) ОАО “Северо-Западный Телеком”. Проект предусматривал:
-
обновление существующего ПО и СУБД;
-
перевод системы на качественно новый уровень, в разряд распределенных
информационно-управляющих систем (новое название системы ПоТок-С);
-
обновление аппаратного обеспечения на всех уровнях системы;
-
проведение различных сопутствующих экспериментов;
-
монтажные и пуско-наладочные работы.
Естественно, что в данном проекте было задействовано большое количество
разработчиков, поэтому далее будут рассматриваться только те вопросы и задачи, которые
непосредственно решались автором дипломной работы.
Задачи дипломной работы:
-
разработка
специализированного
низкоуровнего
программного
обеспечения
контроллера ASK-Lab;
-
разработка высокоуровнего программного обеспечения системы видеоконтроля для
визуального мониторинга состояния объектов управления;
-
проведение различных поддерживающих экспериментов на объектах системы.
Для большего понимания сути проекта и важности задач, решаемых в рамках дипломной
работы, в следующих разделах приведено описание проблематики (система ПТС-1 и ее
недостатки), общие требования к системам класса ИУС и концепция РИУС ПоТок-С.
2.1 Описание проблематики
В филиале ПТС ОАО “Северо-Западный Телеком” с 2000 г. запущена в эксплуатацию
распределенная информационная система (РИС) ПТС-1. Система обеспечивает возможность
мониторинга режима теплоснабжения зданий автоматических телефонных станций (АТС)
путем получения данных с датчиков теплосчетчиков. Одной из ключевых задач системы
является предупреждение выхода из строя телекоммуникационного оборудования.
Здания АТС расположены в разных районах города. Эти здания отапливаются с
использованием городских ТЭЦ и оборудованы средствами учета и регулировки подачи
горячей воды в отопительную систему АТС. В настоящее время количество объектов порядка
100.
40
К моменту начала работ по модернизации РИС ПТС-1, верхний уровень системы
(диспетчерский пункт) был реализован на базе программных комплексов Кливер и АСТРУМ [7]
с использованием СУБД ACCESS. Нижний уровень системы (оборудование на объектах АТС)
реализован
на
теплосчетчиках
отечественного
производства
(средства
учета
тепла),
подключенных посредством модема в качестве узла РИС. Коммуникационная составляющая
реализована на стандартных модемах с использованием телефонных линий общего
пользования.
Контроль параметров теплоносителя на объектах осуществляется диспетчером цеха
автоматизированного учета энергии (АУЭ) ПТС. Параметры, измеряемые и вычисляемые
теплосчетчиками:
-
температура и давление воды;
-
объемный либо массовый расход воды;
-
перенесенная тепловая энергия в подающем и обратном трубопроводе (на входе и
выходе системы отопления АТС).
Текущие параметры используются для выявления нештатных ситуаций, например
нарушение температурного режима АТС, нарушение договорных показателей отопления,
прорыв трубопровода и т.д. В ее нынешнем виде диспетчер является неотъемлемой
составляющей контура управления, так как именно он принимает решение о наличии
нештатных ситуаций.
В режиме автоматического опроса сбор данных о текущих параметрах системы
теплоснабжения дистанционно снимаются с теплосчетчиков в соответствии с предписанным
расписанием опроса.
В целом можно констатировать, что сложившаяся к 2004 году система морально (по
функциям) и физически (по состоянию оборудования) устарела, что и предопределило
необходимость работ по модернизации данной системы. Начавшееся использование локальных
систем автоматического управления привело к необходимости введения ряда новых функций,
которые переводят систему из ИС в разряд ИУС.
2.2 Общие требования к системам класса ИУС (СДМУ)
Требования к системам дистанционного мониторинга и управления (СДМУ) [5] в
зависимости от сферы их применения могут, естественно, отличаться. Типовая СДМУ должна
обеспечивать:
-
немедленное получение в едином диспетчерском пункте системы (ДПС) сигналов
тревоги при возникновении аварийных ситуаций на объекте,
41
-
получение на мнемосхеме пульта диспетчера (ПД) ДПС в режиме реального времени
полной информации о технологическом процессе и состоянии оборудования объекта;
-
представление в графическом виде и отображение в удобной для восприятия форме
состояния контролируемых объектов, а также принятой и сохраненной информации;
-
возможность оперативного вмешательства из ДПС в работу оборудования объекта при
возникновении нештатных ситуаций;
-
контроль прохождения команд управления и генерацию сигналов тревоги при их
невыполнении;
-
возможность анализа работы отдельных объектов или группы объектов по любым
технологическим параметрам за произвольный промежуток времени;
-
возможность дистанционной настройки и диагностики технологических контроллеров
(ТК) объектов;
-
возможность ведения отчетных документов (журналов действий оператора, аварийных
ситуаций, связи и т.п.) и др.
Специфика
создания
СДМУ
определяется
разнообразием
конструктивных
и
технологических особенностей объектов, применяемых на них локальных систем управления и
контроля. Это разнообразие простирается от обслуживаемых объектов, оснащенных измерительными приборами для визуального контроля и простейшей пускорегулируюшей
аппаратурой, до автоматизированных объектов, оборудованных современными контроллерами
с системами датчиков и регулирующей аппаратуры, включая частотные приводы.
Аппаратура СДМУ, устанавливаемая непосредственно на объектах, должна обладать
возможностью гибкого конфигурировании в зависимости от технических особенностей
объекта. Основой такой аппаратуры, как правило, являются технологические контроллеры (ТК).
Каждый ТК должен иметь возможность подключения:
-
аналоговых датчиков для контроля температуры, давления, уровня, положения
исполнительных механизмов и т.п.;
-
дискретных
датчиков
охранной
и
пожарной
сигнализации,
срабатывания
исполнительных механизмов и т.п.;
-
измерительных приборов, имеющих стандартный интерфейс и открытые протоколы
связи;
-
контроллеров локальных систем автоматики, имеющих стандартный интерфейс и
открытые протоколы связи;
-
дискретных силовых устройств сопряжения с исполнительными устройствами и
механизмами.
42
Соответствие таким требованиям позволит сделать универсальный контроллер для
достаточно широкой области применений и решения различных задач, легко «вписать»
контроллер в технологические схемы разнообразных объектов.
2.3 Особенности построения и концепция РИУС ПоТок-С
При разработке архитектуры РИУС ПоТок-С, наряду с общими требованиями,
изложенными ранее, были учтены дополнительные требования заказчика.
С концептуальной точки зрения требовалось расширить функции системы с целью
перевода из класса ИС в класс ИУС, а также существенно увеличить потенциал по числу
обслуживаемых объектов. Вместе с тем требовалось по возможности сохранить имевшееся
оборудование теплопунктов.
В соответствии с принятой в настоящее время технологией обслуживания зданий
требуется обеспечить съем показаний с датчиков с периодом 1 час при общем количестве
контролируемых узлов порядка 100. В каждом узле имеется 6-12 датчиков подключенных к
теплосчетчику и контроллеру нижнего уровня. При этом функции контроля за нештатными
ситуациями целиком возлагаются на оператора, а система должна обеспечивать автоматический
опрос узлов теплоснабжения в соответствии с задаваемым описанием.
Второй по важности задачей являлась создание эффективной по затратам на ее
эксплуатацию системы коммерческого учета. Эффективность системы, обеспечивалась
возможностью дистантного съема архивных данных с теплосчетчиков посредством модемной
связи, что обеспечивает оперативность и существенную экономию транспортных затрат, так
как радиус системы измеряется несколькими десятками километров.
Сложность ситуации заключалась в том, что к моменту принятия о начале работ по
созданию системы, в России имелись лишь опытные партии теплосчетчиков и, фактически,
отсутствовал опыт их эксплуатации. В силу этого вплоть до настоящего времени в системе
эксплуатируется 10 типов теплосчетчиков, каждый со своими уникальными протоколами
информационного обмена и кодами нештатных ситуаций. При этом ситуация усугублялась
разнородностью используемого коммуникационного оборудования и плохим состоянием
телефонных линий общего пользования.
Вектор развития систем подобного назначения направлен в сторону создания
информационно-управляющих систем, обеспечивающих возможность контроля возникающих
нештатных ситуаций в автоматическом режиме. За счет автоматизации широкого круга
операций такие системы должны существенно снизить нагрузку на диспетчера и одновременно
повысить вероятность обнаружения нештатных ситуаций. При этом за диспетчером системы
43
должны остаться контрольные функции за верхним уровнем системы, а также функции
обеспечения организационных мероприятий, связанных с устранением возникших нештатных
ситуаций и/или минимизацией возможного ущерба для дорогостоящего оборудования
телефонных станций.
Структура системы представлена на рисунках 2.1–2.2. В системе имеется возможность
использования четырех типов АРМов. В настоящее время объекты ПТС можно разделить на
две группы по признаку наличия автономного контура регулирования. Автономное
регулирование тепловым режимом ряда станций осуществляется контроллером ECL Comfort
300 (DANFOSS). Верхний уровень системы включает в себя две подсистемы: чисто
информационную ПТС-1 и информационно-управляющую ПТС-2, обслуживающую станции с
контуром автономного регулирования.
С учетом опыта эксплуатации предыдущей версии системы, использование которой
становится проблематичным при числе узлов порядка 100, в концепцию проекта РИУС ПоТокС заложено требование обеспечения возможности развития системы по числу контролируемых
объектов. Для реализации этого требования в подсистеме ПТС-1 используется СУБД ORACLE
и мультиплицированный модемный канал.
Одним из ограничивающих требований к этой подсистеме являлась необходимость
сохранения структуры коммуникационной компоненты в смысле использования не более одной
телефонной линии на один узел теплоснабжения и теплорегуляторов ECL COMFORT-300
(DANFOSS) в качестве контроллеров локальной системы автоматического регулирования
тепловых режимов.
Эти требования предопределили необходимость использования на теплопунктах
станций, входящих в подсистему ПТС-2, контроллеров ASK-Lab верхнего уровня. Этот
контроллер был разработан в СКБ Государственного Университета Аэрокосмического
Приборостроения
Узлы теплоснабжения, входящие в подсистему ПТС-2 снабжены автоматизированными
задвижками (рисунок 2.2а), управление которыми может осуществляться как теплорегулятором
ECL COMFORT-300 в автономном режиме, так и в режиме ручного управления с АРМ
инженера. Контроллер ASK-Lab кроме обеспечения работы с теплорегулятором ECL
COMFORT-300, обеспечивает работу с теплосчетчиком. Обмен с верхним уровнем системы
осуществляется по унифицированному протоколу ASK bus 3.1.
Одним из дополнительных требований к программному обеспечению контроллера ASKLab являлась необходимость обеспечения режима “прозрачности” при опросе его фирменным
программным обеспечением контролирующими организациями.
44
Л
ВС
Сервер
Базы
Данных
АРМ
диспетчера
ПТС-1
Мультиплицированный
модемный канал
АРМ
администратора
ПТС-1
Модем
Модем
Модем
Модем
Коммутируемые
линии связи
АРМ
ком.учета
ПТС-1
АРМ
инженера
ПТС-2
Модем
о
дем
Узел
учета
Узел
учета
Узел
учета
Узел
учета
Узел
учета
Узел
учета
Узлы учета ПТС-1
Узел
учета
Узлы учета ПТС2
Рисунок 2.1 – Структура РИУС ПоТок-С
Модем
Теплосчетчик
Датчик
Контроллер
ASK- Lab
Модем
Теплосчетчик
ECL
COMFORT300
Датчики
Датчики
Исп. устр-ва
Исп. устр-ва
Датчик
a) Структура оборудования
узла учета ПТС-1
б) Структура оборудования узла учета ПТС-2
Рисунок 2.2 – Два типа структуры оборудования теплопунктов (станций) ПТС
45
Следует отметить, что ошибка оператора при операциях управления может привести к
серьезным материальным потерям, особенно, если учесть, что такие действия по определению
выполняются в экстремальной ситуации. Соответственно, возникает ряд проблем системного
характера, связанных с необходимостью обеспечения контроля за выполнением команд
оператора в аварийных режимах и режимах с нарушениями нормальных условий эксплуатации.
В рамках первого этапа реализации проекта в первом полугодии 2005 г. проводились
инженерные эксперименты для проверки ряда новых концептуальных подходов по
обеспечению
надежности
управляющей
подсистемы в режимах
ручного
управления
исполнительными механизмами. Одним из таких подходов является применение систем
видеоконтроля непосредственно на объекте управления. В рамках дипломной работы
разрабатывалось высокоуровневое ПО для этой системы.
2.4 Требования к программному обеспечению системы
В рамках дипломной работы автором разрабатывалось следующее программное
обеспечение:
-
специализированное низкоуровнеаое программное обеспечение для контроллера ASKLab;
-
высокоуровневое программное обеспечение для системы видеоконтроля;
2.4.1 Требования к низкоуровнему программному обеспечению
Разрабатываемое
программное
обеспечение
контроллера
должно
обеспечить
выполнение следующих функций:
-
возможность обращения к 3-м устройствам по одной линии связи (контроллер ASKLab, теплосчетчик и теплорегулятор ECL Comfort 300);
-
дистантная и местная настройка параметров контроллера;
-
энергонезависимое хранение параметров контроллера;
-
обмен данными с ПК по линии связи (телефонная линия или прямое соединение
контроллера и ПК);
-
использование протокола ASK bus 3.1 в качестве протокола сетевого и транспортного
уровня для обмена данными с ПК;
-
обеспечение режима “прозрачности” (поддержка работы программного обеспечения
предыдущей версии системы (РИС ПТС-1) для обмена данными с теплосчетчиками)
46
-
защита данных (использование алгоритма ГОСТ 28147-89 для кодированиядекодирования команд управления и особо важных данных);
-
считывание данных (параметров) с теплосчетчиков и теплорегулятора ECL Comfort
300;
-
изменения параметров теплорегулятора ECL Comfort 300;
-
управление силовыми устройствами (до 8-и);
-
протоколирование событий;
-
контроль времени выполнения задач.
2.4.2 Требования к высокоуровнему программному обеспечению
Разрабатываемое
высокоуровневое
программное
обеспечение
для
системы
видеоконтроля за объектами управления предназначено для работы совместно с модулем IPвидеокамеры [11] и должно обеспечить выполнение следующих функций:
-
прием видео- и аудио- потоков с IP-видеокамеры на ПК, с воспроизведением
изображения и звука;
-
управление параметрами изображения и звука;
-
возможность переключения между подключенными к IP-видеокамере источниками
видеосигнала (до 4-х камер);
-
обеспечение функции программного квадратора (циклическое переключение между
указанными источниками видеосигнала с заданным периодом; при этом на
виртуальной панели отображаются изображения от всех видеоисточников и время
получения последнего кадра от каждого видеоисточника);
-
возможность записи аудио-видео потока на жесткий диск ПК;
-
возможность управления режимами работы программного обеспечения с помощью
“горячих” клавиш.
47
3 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.1 Низкоуровневое ПО контроллера ASK-Lab
3.1.1 Обоснование выбора инструментальных средств для разработки
ПО
3.1.1.1 Выбор необходимых аппаратных средств
Для разработки низкоуровнего ПО выбираются следующие аппаратные средства:
-
Контроллер;
-
Устройство программирования (далее программатор) для данного типа контроллера;
-
Аппаратной эмулятор для данного типа контроллера;
-
ПК для создания и отладки ПО;
Контроллер выбирается исходя из требований, предъявляемых к функциональности
данного устройства. Требования к функциям контроллера были приведены в пункте 2.4.1. Для
выбора контроллера возможно несколько вариантов.
Во-первых, использовать готовые решения на базе программируемых контроллеров или
встраиваемых одноплатных компьютеров доступных на рынке. Подразумевается, что в этом
случае будет использоваться одно универсальное устройство.
Во-вторых,
использовать
специализированных модулей
комбинацию
из
нескольких
расширения. Подразумевается, что
контроллеров
будет
или
использовано
несколько простых устройств (выполняющих некоторые базовые функции).
В-третьих, разработать в рамках проекта собственный специализированный контроллер
для решения необходимых задач.
Как показал обзор существующих решений по контроллерам и встраиваемым
компьютерам (смотри подраздел 1.2), среди всего многообразия предлагаемых и доступных
устройств нет готовых решений на базе одного устройства. Как правило, основным
ограничивающим фактором является требование на наличие 3-х интерфейсов RS-232 и до 8-и
каналов дискретного вывода в выбираемом контроллере.
Возможен второй вариант, когда берется существующий контроллер или встраиваемый
компьютер и дополняется различными модулями расширения. В общем случае получается
комплекс устройств, обладающий достаточно большой избыточностью дополнительных
функциональных возможностей, и как следствие, большой стоимостью. Цена таких решений
48
зависит от производителя компонентов и разнообразия предлагаемых функций, и, как правило,
начинается от 1000 $.В рамках проекта требуется постепенное введение в эксплуатацию до 100
контроллеров, поэтому данный вариант не подходит с точки зрения большой стоимости
аппаратной части.
Для реализации требуемых функций был выбран третий вариант – разработка
собственного специализированного контроллера ASK-Lab (с перспективой дальнейшего
коммерческого использования). Нельзя сказать, что данный контроллер предназначен только
для работы в составе РИУС ПоТок-С. Контроллер ASK-Lab сочетает в себе универсальность и
большую функциональность для целого ряда различных применений, а также невысокую
стоимость. Технические характеристики контроллера ASK-Lab приведены в Приложении А.
Контроллер ASK-Lab построен на базе 4-х микропроцессоров PIC18F458, поэтому
программатор следует выбирать из устройств, способных программировать микропроцессоры
семейства PIC18XXX. В настоящее время доступны следующие программаторы: PICSTART
Plus, MPLAB ICD 2, PRO MATE II. Программатор PRO MATE II сочетает в себе невысокую
стоимость и возможность программировать различные типы и корпуса микропроцессоров
семейства PIC16XXX и PIC18XXX. Поэтому PRO MATE II был выбран в качестве
программатора.
Аппаратный эмулятор для контроллера – очень важный инструмент при разработке и
отладке ПО. Эмулятор, подключенный к ПК, позволяет при помощи специализированного ПО
(установленного на ПК) эмулировать работу реального контроллера. Программисту может быть
предоставлена информация о текущем состоянии портов ввода-вывода, регистрах, переменных,
памяти и т.д.
В данном случае требуется выбрать аппаратный эмулятор для микропроцессоров
PIC18F458,
так
как
логика
работы
контроллера
ASK-Lab
обеспечивается
работой
микропроцессоров PIC18F458. В настоящее время доступны следующие аппаратные
эмуляторы: MPLAB ICD 2, MPLAB ICE 2000, MPLAB ICE 4000. Эмуляторы MPLAB ICE
отличаются стабильностью работы и большой функциональностью. Эмулятор MPLAB ICE
4000 стоит дороже и имеет некоторые функции, которых нет у MPLAB ICE 2000, и которые не
используются при разработкеПО в данном проекте. Поэтому MPLAB ICE 2000 был выбран в
качестве аппаратного эмулятора.
В настоящее время в России подавляющее большинство рынка ПК представлено
машинами на базе IBM PC совместимой архитектуры. Существует множество операционных
49
сред, программных комплексов и технических средств, нацеленных именно на работу в составе
ПК этого класса.
Разработка потребует меньше ресурсов и времени, если она будет вестись на IBM PC,
вследствие наличия значительного опыта разработки на ПК именно этой архитектуры, наличия
достаточного количества программного инструментария разработчика, а также печатной и
электронной литературы.
Разработка ПО для контроллера будет вестись при помощи различных программноинструментальных средств, установленных на ПК. Следует отметить, что эффективность
использования этих средств не сильно зависит от характеристик используемого ПК.
Рациональным будет выбор ПК с аппаратной базой, удовлетворяющей требованиям
используемой операционной системы и необходимых программно-инструментальных средств.
Для разработки низкоуровнего ПО контроллера был выбран ПК следующей
конфигурации:
-
Процессор:
-
Тактовая частота:
600 МГц;
-
Объем оперативной памяти:
128 Мб;
-
Объем дискового пространства HDD:
10 Гб;
-
Видеокарта:
-
Звуковая карта:
нет;
-
Монитор:
15”.
Intel Pentium 3;
встроенная;
3.1.1.2 Выбор метода разработки ПО и среды программирования
В работе [8] приведена классификация и сравнительный анализ методов разработки
специализированного прикладного ПО.
Линейный подход подразумевает, что для реализации любого участка программы, даже
если он многократно повторяется, используется конкретный код. Основной недостаток такого
подхода – большой объем кода и плохая структурированность программы. Такой метод
подходит лишь для разработки ПО для простейших устройств
Процедурный подход подразумевает использование задач и функций. В данном
подходе
возможно
неоднократное
использование
вызовов
функций,
выполняющих
определенный программный код. На основе функций могут формироваться библиотеки, для
последующего использования данных функций в других программах. Объем кода существенно
ниже, а структурированность программы выше, чем при линейном подходе. Этот метод может
50
быть использован для разработки ПО для устройств и встраиваемых систем, обладающих
небольшой функциональностью.
Наличие развитой среды разработки в сочетании с системой библиотек, наработанных в
результате систематического применения процедурного подхода, обеспечивает возможность
создания узкоспециализированных эффективных ОСРВ (мОСРВ). Использование технологии
ОСРВ ускоряет процесс разработки, обеспечивает некую внутреннюю структуру и упрощает
понимание принципов работы ПО. Технология ОСРВ позволяет в каждом новом проекте
использовать одно и тоже ядро ОСРВ (написанное и отлаженное единожды), а также
различные библиотеки и драйвера.
Из-за ограниченности ресурсов микропроцессора, как правило, для встраиваемых систем
управления нецелесообразно использовать полномасштабную ОСРВ, так как сама ОСРВ
требует ресурсов для реализации своих базовых функций. В силу этого приходится решать
задачу многокритериальной
прикладными
задачами
оптимизации
применительно
по
к
разделению
конкретной
ресурсов
реализации.
между
Бурное
ОСРВ
и
развитие
встраиваемых систем управления позволяет выделить из ОСРВ общего назначения некое
подмножество - мОСРВ, предназначенных для управления заранее определенным на этапе
проектирования количеством задач. мОСРВ имеют жесткие ограничения по ресурсам
микропроцессора на реализацию базовых функций.
Линейный и процедурный подходы к разработке ПО являются традиционными.
Скорость разработки специализированного ПО для микропроцессорных систем управления
при использовании традиционных методов не может быть существенно увеличена из-за
естественных ограничений на способность человека контролировать многосвязные проблемы.
Таким образом, можно констатировать тот факт, что в настоящее время широко
начинают применяться платформенно-ориентированные мОСРВ, являющиеся неотъемлемой
частью современных сред разработки прикладного ПО. Следовательно, для разработки ПО
контроллера был выбран метод использования мОСРВ.
мОСРВ имеют жесткие ограничения по ресурсам микропроцессора. Так, например,
считается, что эффективным будет использование той мОСРВ, которая отнимает не более
30% объема памяти программ и не более 10% процессорного времени при выполнении. В
нашем случае выбран микропроцессор PIC18F458 (краткие технические характеристики
приведены в Приложении Б). Для данного микропроцессора объем памяти программ
составляет 32 Кбайта, объем памяти данных 1 Кбайт, тактовая частота до 40 МГц.
Помимо аппаратных ограничений при выборе конкретной мОСРВ, следует обратить
внимание на доступность мОСРВ, практики ее использования и удобства написания ПО под
51
нее. В СКБ ГУАП разработана мОСРВ А3 для микропроцессоров семейства PIC18XXX.
мОСРВ
А3
сочетает
микропроцессора,
в
широкие
себе
малую
требовательность
возможности
по
к
аппаратным
диспетчеризации
использования. Имеется специализированный инструментарий
задач
и
ресурсам
простоту
Конструктор А3 для
описания ПО под данную мОСРВ. Состав библиотек и драйверов постоянно обновляется.
Конструктор А3 позволяет описать структуру взаимосвязей модулей системы, определить
временные интервалы и условия запуска задач, а также описание межзадачного обмена. Код
ядра мОСРВ A3 генерируется Конструктором А3 при трансляции проекта. Проект
транслируется в проект для среды программирования Microchip MPLab IDE v6.xx. В
Приложениях В, Г приведено краткое описание мОСРВ А3 и Конструктора А3.
В настоящее время накапливается опыт использования мОСРВ А3 для встраиваемых
систем управления. А3 была успешно применена в качестве мОСРВ для многотарифного
счетчика электроэнергии ЦЭ27XX. Учитывая простоту использования А3, эффективность ее
работы и доступность инструментария, в качестве базовой мОСРВ была выбрана А3.
В качестве среды программирования была выбрана Microchip MPLab IDE v6xx (далее
MPLab), т.к. именно в данную среду может быть транслирован проект из Конструктора А3.
Данная среда программирования поддерживает все микропроцессоры семейства PICXXX, а
также все типы программаторов и аппаратных эмуляторов, перечисленных выше. MPLab
имеет удобный интерфейс, качественные средства отладки и мониторинга памяти и других
ресурсов.
3.1.2 Разработка структуры ПО
Выше упоминалось, что контроллер ASK-Lab построен на базе 4-х микропроцессоров
PIC18F458. На этих микропроцессорах построена внутриплатная одномастерная сеть на базе
интерфейса I2С. Мастером сети является один из микропроцессоров, все остальные работают по
отношению к мастеру одинаково как периферия. Каждый микропроцессор имеет набор
стандартных аппаратно реализованных коммуникационных интерфейсов с оптической
развязкой. Кроме стандартных коммуникационных интерфейсов, контроллер имеет внешний
разъем, на который выведены порты с периферийных микропроцессоров. Эти особенности
аппаратной
составляющей
контроллера
необходимо
учитывать
Структурная схема контроллера ASK-Lab приведена на рисунке 3.1.
52
при
разработке
ПО.
Keyb
LCD
P18
М
D
I/O
D
I/O
A/D
I/O
D
I/O
P18
SL
P18
SL
P18
SL
ALT
ERA
Q, 20MHz
RST supervisor
I2C
CLK
RTC
RST
Опто
развязка
Опто
развязка
Опто
развязка
Опто
развязка
BAT
3V
Q, 32.768
CANbus 2.0, CANbus 2.0, CANbus 2.0, CANbus 2.0,
USART
USART
USART
USART
RS232,
RS232,
RS232,
RS232,
RS422,
RS422,
RS422,
RS422,
RS485
RS485
RS485
RS485
Рисунок 3.1 – Структурная схема контроллера ASK-Lab
Программное обеспечение контроллера ASK-Lab было разработано на основе мОСРВ
A3. Ядро мОСРВ, драйвера и библиотеки являются неизменной частью каждой системы. Для
удобства проектирования систем под мОСРВ A3 используется специальное инструментальное
программное обеспечение Конструктор А3.
Структура ПО контроллера ASK-Lab представлена на рисунке 3.2.
Системное ПО
Прикладное
ПО
Ядро мОСРВ
Драйвера
устройств
Высокий
приоритет
прерываний
Фоновые задачи
Ядро мОСРВ A3
I2C
LCD
USART (RS 232)
Прерывание 1
…
Прерывание K
Задача 1
…
Задача N
Рисунок 3.2 – Структура ПО контроллера ASK-Lab
Код ядра мОСРВ A3 генерируется программным обеспечением Конструктор А3 при
трансляции проекта.
Модули с кодами драйверов устройств собраны в универсальную библиотеку драйверов.
Библиотека предназначена для использования в составе мОСРВ A3. Основной функцией
библиотеки является программная поддержка аппаратных модулей микропроцессора PIC18 и
53
поддержка аппаратно-программных интерфейсов между микропроцессором и другими
устройствами. Описание библиотеки драйверов приведено в Приложении Д.
Изменяемой частью ПО контроллера является прикладное ПО – это программные
модули, реализующие функции, специфичные для конкретного приложения контроллера.
Прикладное ПО от версии к версии может изменяться, и дополняться новыми программными
модулями. Системное ПО, как правило, остается неизменным (состав драйверов может
меняться).
Функции, предъявляемые к ПО контроллера были описаны выше. Учитывая специфику
аппаратной части контроллера ASK-Lab, функции разделяются между микропроцессорами,
входящими в его состав (условные обозначения микропроцессоров: PIC_Master – мастер сети,
PIC_SPT и PIC_Danf – переферийные микропроцессоры). При написании ПО всей системы в
целом следует особое внимание уделить вопросу межпроцессорного взаимодействия.
Функции микропроцессора PIC_Master;
Обмен с ПК по интерфейсу RS-232 и протоколу Ask-Bus v 3.1 (выполнение команд,
-
принятых с ПК, поддержка информационного обмена между ПК и процессорами
PIC_SPT и PIC_Danf);
Обмен с микропроцессорами PIC_SPT и PIC_Danf по интерфейсу I2С (PIC_Master –
-
мастер сети);
Реализация процедуры ввода пароля (используется клавиатура и ЖК-индикатор,
-
хранение пароля в энергонезависимой памяти EEPROM);
-
Ведение журнала событий (хранение в памяти программ);
-
Преобразование данных согласно алгоритму ГОСТ 28147-89 при выполнении команд,
требующих разграничения доступа.
В
ПО
микропроцессора
PIC_Master
(и
всех
остальных)
были
использованы
существующие модули и библиотеки (системное ПО) и разработаны новые (прикладное ПО).
Список всех модулей, входящих в состав ПО микропроцессора PIC_Master представлен в
таблице 3.1.
Таблица 3.1 – Список модулей, входящих в состав ПО микропроцессора PIC_Master
Модуль
Main.asm
AskBus31.inc
AskTrans.inc
Тип
ПО
СА
С*
С*
Описание
Главный модуль проекта.
Формирование/разбор пакетов протокола ASK-Bus v.3.1
Формирование контрольной информации сетевого пакета на
уровне ASK-Bus, являющегося ответным на запросный пакет с
ПК
54
Crypt.inc
С
Define.inc
Enter_Pswd.inc
СА
П+
Ex_Flash.inc
Init.inc
С+
СА
Продолжение таблицы 3.1
Прямое и обратное преобразование данных по алгоритму Гост
28147-89 в режиме простой замены
Модуль констант и объявлений.
Ввод пароля с помощью клавиатуры, с отображением всей
необходимой информации на LCD индикаторе
Работа с памятью программ микропроцессора
Процедуры начальной инициализации микропроцессора
Kernvar.inc
СА
Модуль объявления переменных ядра.
Keyboard.inc
С
LCD.inc
Macros.inc
С*
С*
MasterCMD.inc
П+
MI2C.inc
С
Procs.inc
С*
Resetbufsbyto.inc
Setaskdevaddr.inc
Spt_strt.inc
П+
П*
П+
TaskCond.inc
СА
Опрос по требованию матричной клавиатуры с возвратом кода
последней нажатой и отжатой клавиши
Настройка и вывод на ЖКД текстовой информации
Набор макросов, используемых ядром мОСРВ и библиотечными
модулями.
Выполнение команд (пришедших с ПК), предназначенных для
выполнения микропроцессором PIC_Master
Обмен данными по интерфейсу I2С в режиме мастер с PIC18,
работающими в режиме слэйв, либо другими внешними I2С
слэйв-устройствами
Набор стандартных процедур, используемых ядром мОСРВ и
библиотечными модулями.
Сброс буферов межзадачного обмена по условию
Установка адреса устройства для протокола ASK-Bus v3.1
Формирование/разбор сетевых пакетов для обмена с СПТ 942
(посредством PIC_SPT) в режиме прозрачности
Условия запуска задач в мОСРВ.
UsartD.inc
С*
Userdef.inc
СА
ViewLevel.inc
П+
Обмен данными по интерфейсу RS-232 с внешним устройством с
формированием пакета по символам границ пакета и по
таймауту
Модуль констант и объявлений пользователя.
Формирование/разбор сетевых пакетов на уровне представления
данных
Примечания к таблице:
С – системное ПО;
П – прикладное ПО;
А – код модуля (возможно частично) генерируется автоматически Конструктором А3
на основе схемы межзадачного обмена или других настроек;
* – код модуля модифицирован для данного проекта;
+ – код модуля заново разработан.
Описание структуры межзадачного обмена всех микропроцессоров для Конструктора
А3 приведено в Приложении Е.
55
Функции микропроцессора PIC_SPT:
-
Обмен с теплосчетчиком по интерфейсу RS-232;
-
Обмен с микропроцессором PIC_Master по интерфейсу I2С (выполнение команд,
принятых микропроцессором PIC_Master с ПК, поддержка информационного обмена
между ПК и теплосчетчиком);
-
Управление силовыми устройствами (по командам с PIC_Master).
Список всех модулей, входящих в состав ПО микропроцессора PIC_SPT представлен в
таблице 3.2.
Таблица 3.2 – Список модулей, входящих в состав ПО микропроцессора PIC_SPT
Модуль
Main.asm
CmdDisp.inc
Define.inc
Init.inc
Тип
ПО
СА
П+
СА
СА
Kernvar.inc
Macros.inc
СА
С*
Procs.inc
С*
Resetbufsbytos.inc
П+
SI2C.inc
С
SlaveCMD.inc
П+
TaskCond.inc
Usart.inc
СА
С*
Userdef.inc
СА
Описание
Главный модуль проекта.
Диспетчер команд, пришедших от PIC_Master
Модуль констант и объявлений.
Процедуры начальной инициализации микропроцессора
Модуль объявления переменных ядра.
Набор макросов, используемых ядром мОСРВ и
библиотечными модулями.
Набор стандартных процедур, используемых ядром мОСРВ и
библиотечными модулями.
Сброс буферов межзадачного обмена по условию
Обмен данными по интерфейсу I2С в режиме слейв с PIC18,
работающим в режиме мастер
Выполнение команд пользователя (пришедших с ПК),
предназначенных для выполнения микропроцессором PIC_SPT
Условия запуска задач в мОСРВ.
Обмен данными по интерфейсу RS-232 с внешним устройством
с формированием пакета по таймауту
Модуль констант и объявлений пользователя.
Функции микропроцессора PIC_Danf:
-
Обмен с терморегулятором ECL Comfort 300 по интерфейсу RS-232;
-
Обмен с процессором PIC_Master по интерфейсу I2С (выполнение команд, принятых
процессором PIC_Master с ПК, поддержка информационного обмена между ПК и
терморегулятором).
Состав модулей ПО микропроцессора PIC_Danf аналогичен составу модулей PIC_SPT.
Отличие модулей в различных константах и определениях.
56
3.1.3 Обмен данными
3.1.3.1 Обмен данными между контроллером и ПК
Структурная схема обмена данными между контроллером ASK-Lab и ПК приведена на
Прикл. Уров.
Уров. Предст
Сеанс. Уров.
Трансп. Уров. Модем
Прикл. Уров.
Уров. Предст
Сеанс. Уров.
Модем Трансп. Уров.
Контроллер
ПК
рисунке 3.3.
Окончание
транспортного
уровня
Заголовок
транспортного
уровня
Тр.В.
х
х
х
х
х
Тр.Е.
Передаваемые данные
- канальный уровень, обеспечивается модемом.
Рисунок 3.3 – Структурная схема обмена данными
Контроллер ASK-Lab поддерживает необходимые уровни протокола обмена до
сетевого уровня. Остальные уровни поддерживаются внешним модемом. Как видно из
рисунка 3.3, независимо от режима работы контроллера, данные, всегда проходят через
транспортный уровень, который обеспечивает доставку сообщений. Режим простой
трансляции данных (от ПК к периферии контроллера и обратно) реализован таким же
способом. За основу транспортного уровня протокола взят протокол ASK-Bus v3.1. Описание
протокола ASK-Bus v3.1 приведено в Приложении Ж.
Параметры обмена:
-
скорость передачи данных
2400 бит/сек (до 115200 бит/сек);
-
Биты данных
8;
-
Четность
нет;
-
Стоповые биты
1;
-
Управление потоком
нет.
57
3.1.3.2 Обмен данными между контроллером и периферийными
устройствами
Связь ПК с теплосчетчиком и теплорегулятором обеспечивается в режиме трансляции
данных. Формирование/разбор пакетов при обмене данными
с теплосчетчиком и
теплорегулятором в данном режиме производится непосредственно на ПК.
Сформированный
пакет
на
ПК
для
теплосчетчика
(либо
теплорегулятора)
вкладывается в поле данных пакета ASK-Bus. После разбора принятого контроллером ASKLab пакета поле данных передается на конечное устройство. Ответ от устройства
принимается контроллером и без дополнительной обработки так же вкладывается в поле
данных пакета ASK-Bus, и отправляется обратно на ПК, где и происходит разбор ответа
устройства.
Примечание – данный режим работы контроллера ASK-Lab позволяет относительно
быстро
собрать
систему
на
базе
практически
любых
устройств
с
поддержкой
последовательного интерфейса USART, т.к. весь протокол обмена с данным устройством
будет реализован на ПК. Этот режим может быть так же использован как отладочный.
Работа контроллера ASK-Lab с теплосчетчиком СПТ942
Режимы обмена данных контроллера с теплосчетчиком:
-
Режим прозрачности – данные с ПК передаются на контроллер по интерфейсу RS-232
и протоколу обмена с теплосчетчиком. Контроллер, распознав начальный и конечный
символы данного протокола, передает полученный пакет на теплосчетчик.
-
Режим команд – данные с ПК передаются на контроллер по интерфейсу RS-232 и
протоколу ASK-Bus. Пакет данных для теплосчетчика вкладывается в поле данных
пакета ASK-Bus. Команда 0x00 протокола ASK-Bus - передача данных на
периферийное устройство. Контроллер, по этой команде извлекает поле данных из
пакета и передает на периферийное устройство.
Параметры обмена:
-
скорость передачи данных
2400 бит/сек.;
-
Биты данных
8;
-
Четность
нет;
-
Стоповые биты
1;
-
Управление потоком
сигнал DTR (всегда активен).
58
Работа контроллера с ECL Comfort 300
Регулятор температуры ECL Comfort 300 Danfoss является полностью самостоятельным
устройством, регулирующим температуру воды в контуре горячего водоснабжения и в контуре
водяного отопления. Основными функциями контроллера при работе с ECL Comfort 300
являются функции удаленного мониторинга и изменения режимов работы регулятора. При
наличии дополнительного коммуникационного модуля ECA87 для ECL Comfort 300 появляется
возможность получать дополнительную информацию с ECL Comfort 300 и непосредственно
управлять исполнительными устройствами данного регулятора.
Для обмена данными контроллера с регулятором температуры ECL Comfort 300 Danfoss
используется режим команд (описан выше).
Параметры обмена:
-
скорость передачи данных
1200 бит/сек.;
-
Биты данных
8;
-
Четность
да;
-
Стоповые биты
1;
-
Управление потоком
нет.
3.1.4 Обеспечение робастности и защита информации
Важность аспекта защиты информации применительно к ИС обсуждалась в работах [1],
[2]. Там же была предложена концепция использования многоуровневой системы защиты
информации в распределенных системах коммерческого учета. Эта концепция с рядом
модификаций была реализована в проекте.
При посылке команд записи (изменения) сетевые пакеты с командами и ответные пакеты
должны быть преобразованы. Пакет, посылаемый с ПК, преобразуется с использованием ключа,
производного от пароля, введенного инженером АРМ.
При
получении
пакета
ПО
контроллера
делает
обратное
преобразование
с
использованием ключа, производного от пользовательского пароля (введенного на контроллере,
аналогичному паролю ПО АРМ). Если контрольная сумма преобразованного блока корректна,
производится проверка условия: принятое значение времени больше записанного в памяти
контроллера. Если условие выполняется, контроллер выполняет команду. Ответный пакет
преобразуется с использованием того же (пользовательского) ключа, содержит значение
времени контроллера (значение системного таймера микропроцессора мастера сети).
59
Для преобразования данных используется алгоритм ГОСТ 28147-89 с постоянной
таблицей замен. Контроллер ASK-Lab обеспечивает реализацию преобразования данных в
режиме реального времени.
При передаче сообщений длина посылки искусственно увеличивается для обеспечения
зашиты от сканирования. Для защиты от перехвата команд применен ряд дополнительных мер.
Ключи шифрации в контроллер ASK-Lab вводит администратор системы, и он же имеет
возможность его изменения. Разработчики системы обеспечивают лишь первоначальный код
доступа и лишены возможности считывания использованных кодов шифрации после введения
ключей администратором системы.
Для защиты от атак при наличии сообщника в составе персонала, в контроллере ведется
журнал, учета команд управления. Журнал доступен лишь для просмотра с АРМ инженера, но
не может быть откорректирован. Эта информация позволяет фиксировать время и источник
команд управления. Эта же информация обеспечивает возможность арбитража в случае
незлонамеренных ошибок персонала.
3.1.4.1 Преобразование данных
Выше было сказано, что для передачи информации используется протокол ASK-Bus.
Далее все упоминания полей касаются только протокола ASK-Bus.
Преобразованию подвергается поле STA (статус), CD (код команды) и поле DATA. Поле
флагов протокола ASK-Bus должно содержать только признак необходимости преобразования,
одинаковый для всех команд, требующих преобразования (старший бит = 1).
Состав преобразуемой информации приведен в таблице 3.3.
Таблица 3.3 – Состав преобразуемой информации
информация
Поле статуса
код команды
параметры команды или пакет для
внешнего устройства
системное время
дополнение до кратности 8 байт
Длина параметров команды N
контрольная сумма
поле ASK-Bus
STA
CD
DATA
длина
1
1
N
DATA
DATA
DATA
DATA
4
L
1
2
Для длины преобразуемых данных Len должны выполняться условия: Len mod 8 = 0 и
Len >= 16. Контрольная сумма – это сумма всех байтов данных, подвергаемых преобразованию,
60
расположенных до нее (младшими вперед). Дополнение до кратности 8 байт производится
заполнением пространства значением системного таймера.
3.1.4.1.1 Служебный и пользовательский пароль
Пароль, вводимый администратором в контроллер с помощью клавиатуры и дисплея,
используется для получения ключа преобразования данных. Тот же пароль вводится при работе
с инженерным ПО верхнего уровня.
Существует два типа пароля: служебный и пользовательский. Служебный пароль
записывается при программировании контроллера и не подлежит изменению. Он используется
при первоначальной настройке и техническом обслуживании системы, а также для смены
пользовательского пароля. Пользовательский пароль задается с клавиатуры контроллера, и
используется при формировании ключа для преобразования данных, передаваемых по сети при
командах записи.
При изменении пароля сначала вводится старый пароль, при его правильности (т.е. при
совпадении введенного значения с пользовательским паролем) предлагается ввести новый
пользовательский пароль. Длина пароля – от 3 до 6 символов, пароль хранится в
энергонезависимой памяти EEPROM контроллера. При успешном изменении пароля
обнуляется счетчик времени, служащий для проверки корректности приходящих сетевых
пакетов (при приеме каждой новой корректной команды, имеющей преобразованные данные,
данный счетчик изменяется на значение поля «время сетевого пакета»).
3.1.4.1.2 Ключ преобразования данных
Для получения ключа преобразования данных должен использоваться пароль, вводимый
пользователем в контроллер с помощью клавиатуры и дисплея.
На основе пароля формируется ключ, используемый для преобразования данных. Длина
ключа – 256 бит. Расширение пароля до длины ключа осуществляется следующим образом:
1) преобразование пароля в BCD;
2) копирование получившейся строки на всю длину ключа;
3) выполнение
операции
XOR
с
неизменяемой
константой,
хранимой
энергонезависимой памяти контроллера, длина которой равна длине ключа.
61
в
3.1.4.1.3 Системное время
Текущее время вычисляет ПО на ПК, посылающее команду, это время должно
возрастать для каждой следующей команды (например, число секунд с начала 2000 года). ПО
контроллера проверяет порядок следования времени в командах и выполняет только команду со
значением времени большим, чем предыдущая. Принятое значение времени хранится в
энергонезависимой памяти контроллера. Механизм записи времени исключает порчу значения
при пропадании питания. Значение времени записывается до начала реакции на команду.
3.1.4.2 Защита от сбоев и протоколирование событий
мОСРВ A3 обеспечивает некоторые функции по защите от сбоев и протоколированию
событий, а именно:
-
контроль корректности функционирования программной системы;
-
контроль времени выполнения задач;
-
запись контекста ПО контроллера в случае исключительной ситуации для
последующего анализа;
-
запись дампа памяти;
-
ведение журнала событий.
3.1.5 Методы отладки программного продукта
Очевидно, что написание работоспособного ПО – весьма трудоемкая задача. Написать
сложное ПО без ошибок с первого раза практически невозможно. Поэтому очень важным
является вопрос отладки ПО с целью быстрого, эффективного и надежного поиска и
исправления ошибок. В следующих подразделах будут рассмотрены вопросы технических
возможностей и особенностей отладки, используя среду программирования Microchip MPLab
IDE v6.xx и специализированный инструментарий Конструктор А3.
3.1.5.1 Основные средства отладки среды программирования
Среда программирования Microchip MPLab IDE v6.xx предоставляет программисту
довольно мощные средства отладки. В частности, MPLab содержит интегрированный отладчик
и Object Browser для контроля за результатом процесса компиляции, а также ряд других
62
сервисов нацеленных на поддержку процесса отладки. Использованные при разработке сервисы
и методы отладки перечислены и описаны ниже.
Режимы запуска программы:
-
программная симуляция микропроцессора (MPLAB SIM)
-
использование аппаратного эмулятора (MPLAB ICE 2000)
Первый режим позволяет симулировать работу реального микропроцессора, но имеет
ряд существенных ограничений. Так, например, отсутствует возможность работы с
прерываниями, периферийными устройствами, встроенной энергонезависимой памятью
(EEPROM) и памятью программ для операций чтения и записи. Этот режим можно
использовать для запуска и отладки программ (фрагментов кода), не использующих
вышеперечисленных ресурсов. Например, этот способ будет хорош при отладке различных
математических функций, функций непосредственной обработки данных и д.р. При этом,
процесс написания и отладки ПО может происходить с использованием одного ПК, без какихлибо других аппаратных средств.
Второй режим подразумевает, что к ПК через специальный интерфейс подключен
аппаратный эмулятор, в данном случае MPLAB ICE 2000. Этот режим позволяет практически
полностью
воспроизвести
работу
реального
микропроцессора.
Запуск
программ
с
использованием аппаратного эмулятора позволяет проводить отладку и тестирование ПО при
работе с любыми аппаратными ресурсами микропроцессора и подключенными периферийными
устройствами.
Режимы запуска программы выбираются из меню Debugger->Select Tool
По своей сути, работа с остальными инструментами и сервисами отладки, практически
не зависит от режима запуска программы (нужно лишь учитывать ограничения для режима
симуляции, приведенные выше).
Запуск и останов программы. Запуск программы осуществляется из меню Debugger>Run. Останов выполнения программы осуществляется из меню Debugger->Pause. После
останова программы, средствами среды программирования могут быть доступны для просмотра
и изменения данные (переменные), содержимое встроенной памяти EEPROM, значение
регистров и портов ввода-вывода, а также положение программного указателя. Программа
может быть запущена вновь с того места, в котором произошел останов из меню Debugger>Run. Полный останов программы осуществляется из меню Debugger->Halt. В этом случае, при
запуске, программа выполняется с начала.
63
Пошаговое выполнение программы. После остановки программы можно осуществить
пошаговое ее выполнение. Возможно два варианта:
-
Пошаговое выполнение всех без исключения команд (Debugger->Step Into)
-
Пошаговое выполнение команд без “захода” в тело функций (Debugger->Step Over)
В первом случае выполняются все без исключения команды по очереди, один шаг – одна
команда. Это удобно при полной отладке какой либо части программы. Во втором случае, если
встречается вызов функции, то она выполняется за один шаг. Этот способ удобен при отладке
части программы, в которой используются заранее отлаженные функции и правильность их
выполнения не вызывает сомнения.
Указание точек останова. Точки останова программы позволяют установить те места
программы, при выполнении которых будет сделан останов. Этот способ похож на
пошаговый, однако позволяет более рационально использовать временные ресурсы при
отладке. Программа при выполнении останавливается только в тех местах, которые
непосредственно подлежат проверке, и уже в этих местах можно применять пошаговый
способ отладки.
Существует два способа для указания точек останова в MPLab. Первый заключается в
следующем: щелкнуть в окне редактора слева от кода (между текстом и рамкой окна). При
этом появляется пиктограмма (красная точка) в окне редактирования, и данная строка
отображается другим цветом. Установка точки останова допустимо, если в данной строке
выполняется какой-либо код.
При размещении множества точек останова можно использовать пункт меню
Debugger->Breakpoints, чтобы открыть окно Breakpoint List. Окно Breakpoint List позволяет
управлять присутствующими точками останова (добавлять, удалять, разрешать, запрещать).
Программный указатель. При любом останове программы, в левой части окна
редактирования появляется пиктограмма (зеленая стрелка). Она указывает на строку (команду),
на которой остановилось выполнение программы. Это и есть программный указатель.
Программный указатель можно выставить в любом месте программы, нажав правую кнопку
мыши в нужной строке программы в окне редактора и выбрав в контекстном меню пункт Set PC
at Cursor. Таким образом, после запуска программы, она будет выполнятся с места, в котором
установлен программный указатель.
Проверка значений. Если программа остановлена в отладчике, можно проверить, а
также изменить значение любого идентификатора, регистра, порта ввода-вывода, ячейки
64
памяти EEPROM и памяти данных и т.д. Для этого в MPLab существуют несколько панелей,
вызываемых из меню View:
-
Hardware stack;
-
Watch;
-
Program memory;
-
File Registers;
-
EEPROM.
Hardware stack – позволяет просмотреть последовательность точек возврата после
прерываний и вызова функций. Отображается номер точки и адрес возврата.
Watch – позволяет установить наблюдение за любой ячейкой памяти данных
(переменные, регистры, значение портов ввода-вывода). Объекты для наблюдения можно
добавлять и удалять. Значения объектов можно изменять.
Program memory – позволяет просмотреть память программ микропроцессора. В панели
может отображаться номер команды, ее физический адрес в памяти программ, код команды и ее
текст на языке ассемблера (с входными параметрами), а также программный указатель на
текущую команду (на которой остановилось выполнение программы).
File Registers – позволяет просмотреть память данных. В памяти данных размещаются
все регистры, порты ввода-вывода, пользовательские переменные. Имеется возможность
задавать ячейкам памяти данных новые значения.
EEPROM – позволяет просмотреть и изменить значение ячеек памяти EEPROM.
3.1.5.2 Особенности отладки, связанные с использованием технологии
мОСРВ
Использование технологии мОСРВ при разработке ПО контроллера приносит некоторые
особенности процесса отладки конечного кода.
Выше было сказано, что для описания структуры ПО под мОСРВ А3 используется
специализированный инструментарий Конструктор А3. В конечном счете, Конструктор А3
позволяет описать взаимодействие задач системы, сделать настройку параметров их
выполнения и т.д. Код самих задач пишется отдельно (например, в текстовом редакторе или
в среде MPLab), задачи собираются в библиотеку или отдельные модули. Проект из
Конструктора А3 транслируется в среду MPLab, и уже там может быть окончательно отлажен
и протестирован.
Таким образом, целесообразным будет использование следующей схемы написания и
отладки ПО контролера:
65
1) Определение укрупненной структуры ПО и необходимых задач;
2) Написание в текстовом редакторе или среде MPLab задач-заглушек (т.е. задачи,
которые не выполняют полезного действия, а просто на входное воздействие отвечают
некоторым выходным, и которые впоследствии будут заменены другими задачами);
3) Описание структуры взаимодействия задач в Конструкторе А3 и трансляция проекта в
среду MPLab;
4) Отладка получившейся структуры ПО в среде MPLab, проверка того, что все
взаимосвязи правильные и используются все ветви алгоритма;
5) Детализация структуры ПО, разбиение задач на подзадачи;
6) Замена некоторых задач-заглушек на задачи, выполняющие требуемые функции;
7) Переход к пункту 3 до тех пор, пока не будет описана полная структура ПО и
задействованы все необходимые задачи (совместно с задачами-заглушками);
8) Окончательная замена всех задач-заглушек на задачи, выполняющие требуемые
функции;
9) Окончательная отладка ПО в среде MPLab. Возможное исправление кода задач;
10) Формирование (изменение) библиотеки функции и драйверов на основе задач
отлаженного ПО.
3.1.5.3 Проверка работоспособности ПО на примере серийного
изделия “контроллер ASK-Lab”
На некотором этапе создания ПО возникает необходимость производить его отладку и
тестирование с использованием реальных устройств в условиях их эксплуатации. В нашем
случае это контроллер ASL-Lab, который программируется разрабатываемым ПО при помощи
программатора PRO MATE II. Тестирование контроллера проходит в два этапа:
1) Тестирование и отладка ПО на “столе”, т.е. в помещении, где ведется разработка ПО, с
использованием специализированного стенда-макета;
2) Тестирование на объекте Заказчика в реальных условиях эксплуатации.
Для тестирования контроллера применялось специально разработанное сотрудником
СКБ приложение “Тестирование”, установленное на ПК. Приложение “Тестирование”
обеспечивает обмен данными между ПК и контроллером ASK-Lab, а также позволяет
проверить обмен данными со всеми устройствами, подключенными к контроллеру, и д.р.
функциональные возможности контроллера.
На первом этапе проводились следующие типы тестирования:
-
Функциональное тестирование;
66
Нагрузочное тестирование.
-
Функциональное тестирование – тестирование функций ПО для поиска различий между
разработанным ПО и его внешней спецификацией. Проверяются наличие всех функциональных
требований технического задания; корректность и полнота выполняемых функций. Проводятся
многократное тестирование каждой функции системы, множества их сочетаний, имитация и
проверка на наличие сбоев применительно к каждому функциональному требованию.
В
рамках
функционального
тестирования
выполнялись
следующие
проверки
(многократные):
-
Обмен данными между ПК и контроллером (проверка линии связи);
-
Обмен данными между ПК и периферийными устройствами, подключенными к
контроллеру – теплосчетчик и теплорегулятор ECL Comfort 300 (проверка линии связи
и интерфейса I2C);
Ввод пароля на контроллере (проверка клавиатуры, дисплея и энергонезависимой
-
памяти EEPROM);
Проверка правильности выполнения управляющих команд при разных паролях
-
(проверка работоспособности портов ввода-вывода и алгоритмов шифрования и
дешифрования);
Чтение
-
и
запись
параметров
контроллера
(проверка
памяти
программ
и
энергонезависимой памяти EEPROM);
Проверка всех остальных функций, описанных в спецификации.
-
Нагрузочное тестирование – испытания для определения рабочих характеристик.
Выполняется тестирование в предельных режимах, нагрузочные испытания. Проводится
тестирование операций обработки больших массивов данных с оценкой изменения времени
отклика, контроль синхронизации. Испытания на надежность и эксплуатационную готовность.
В
рамках
нагрузочного
тестирования
выполнялись
следующие
проверки
(многократные):
-
Передача с ПК на контроллер беспорядочного набора пакетов (проверка устойчивости
к переполнению входного буфера);
-
Передача с ПК на контроллер беспорядочного набора команд чтения (проверка
времени отклика и устойчивой работы системы);
-
Передача с ПК на контроллер беспорядочного набора команд записи с неправильным
ключом (проверка устойчивости от сканирования);
67
-
Передача с периферийных устройств на контроллер беспорядочного набора любых
пакетов (подразумевается, что вместо периферийного устройства подключается ПК;
проверка устойчивости к переполнению входного буфера, проверка отсутствия
реакции на эти воздействия, т.к. только контролер может инициировать обмен с
периферийными устройствами);
-
Многократный ввод пароля и запись параметров контроллера (проверка памяти
программ и энергонезависимой памяти EEPROM).
После любого типа тестирования, ПО могло быть модифицировано, вследствие
выявления каких-либо ошибок или неправильного функционирования.
На втором этапе проводилось длительное тестирование контроллера ASK-Lab на
объектах ПТС в реальных условиях эксплуатации. Длительность тестирования составляла 1-7
суток.
В настоящее время, после многократного тестирования и различных испытаний, ПО
контроллера доведено до требуемой функциональности, устранено большинство ошибок. Всего
на объектах ПТС установлено 10 контроллеров ASK-Lab, которые около полугода
функционируют в качестве основного звена в различных узлах учета. За все время
эксплуатации, контроллеры показали хорошую функциональность и надежность работы.
3.2 Высокоуровневое ПО системы видеоконтроля
3.2.1 Обоснование выбора инструментальных средств для разработки
ПО
3.2.1.1 Выбор необходимых аппаратных средств
Обоснование выбора ПК IBM PC совместимой архитектуры было приведено выше.
Разработка ПО для системы видеоконтроля будет вестись при помощи различных программноинструментальных средств, установленных на ПК. Следует отметить, что эффективность
использования этих средств зависит от характеристик используемого ПК, в наибольшей
степени, быстродействия и объема оперативной памяти. С другой стороны, использование
слишком дорогостоящей аппаратной базы ведет к неоправданному росту стоимости разработки
программного продукта. Рациональным будет выбор ПК с аппаратной базой следующей
конфигурации:
68
-
Процессор:
-
Тактовая частота:
1000 МГц
-
Объем оперативной памяти:
256 Мб
-
Объем дискового пространства HDD:
10 Гб
-
Видеокарта:
-
Звуковая карта:
встроенная
-
Монитор:
15”
Intel Pentium 3
32 Мб
С учетом того, что для разработки низкоуровнего ПО контроллера требуется ПК с
меньшими требованиями к аппаратным ресурсам, для всего проекта (дипломной работы)
выбирается один ПК с большими требованиями к аппаратным ресурсам. Т.е. выбирается ПК с
конфигурацией, приведенной в данном разделе.
3.2.1.2 Выбор базовой операционной системы
Операционная система Windows в применении на персональных компьютерах является в
настоящее время преобладающей перед прочими ОС для IBM PC совместимых компьютеров.
Причем наибольшее распространение на территории России имеют следующие версии:
Windows 98 и ставшая очень популярной в последнее время Windows XP. К тому же Windows
XP является одной из самых удачных операционных систем компании Microsoft, так как она
объединяет в себе две концепции, которые компания Microsoft развивала до выпуска Windows
XP параллельно: интерфейс, удобный для пользователя и работа в сети. Разрабатываемое
программно обеспечение будет совместимо с несколькими операционными системами, а
именно Windows 98, Me, 2000, XP.
Ввиду указанных выше причин можно констатировать, что разрабатываемый
программный продукт найдет наибольший спрос при работе под управлением операционных
систем Windows 98, XP, и его разработка в данном случае займет наименьшее количество таких
ресурсов, как время, затраты на программное обеспечение и оплату времени разработчика.
3.2.1.3 Выбор среды программирования
Критерии выбора среды программирования:
1) Базовая операционная система – Windows XP для IBM PC совместимых ПК.
2) Наибольшая скорость разработки, подразумевающая использование преимущественно
готовых компонентов, наличие опыта в разработке и доступность электронной и
69
обычной литературы для быстрого разрешения вопросов, возникающих в процессе
разработки.
3) Поддержка объектно-ориентированного программирования.
4) Возможность использования динамически подключаемых библиотек.
Перечисленным критериям удовлетворяют среды визуального программирования, такие,
как «Microsoft Visual C++», «Borland C++ Builder» и «Borland Delphi».
По каждой из этих сред накоплен большой опыт разработок. Перечисленные продукты
компании Borland являются представителями RAD-сред (Rapid Application Development –
быстрая разработка приложений), которые обладают широкими средствами быстрого создания
интерфейса пользователя. Безусловно, используя среду разработки «Microsoft Visual C++»
возможно создать более богатый интерфейс, чем позволяют продукты компании Borland, но
использование данной среды для разработки интерфейса зачастую требует дополнительных
временных затрат на поиск решения. Соответственно, разумным решением является
использование для разработки одного из продуктов компании Borland.
В виду того что, для разработки программного обеспечения выбрана операционная
система Windows, следует учесть, что большинство документации по системным функциям и
функциям Windows API (Application Programming Interface – прикладной программный
интерфейс) приведены на языке C. Не исключается использование данных функций и в других
языках, но это может вызывать дополнительные неудобства при проектировании. К тому же
при разработке планируется использование библиотек Microsoft DirectX®, работа с которыми
наиболее удобна с использованием языков C/C++. Соответственно в качестве языка
программирования для разработки целесообразно использование языка C++ и продукта
компании Borland – «C++ Builder».
В настоящее время последняя версия для разработки 32-х разрядных Windows
приложений - шестая версия среды C++ Builder. Однако для разработки необходимого нам
программного обеспечения достаточно функциональных возможностей пятой версии. Таким
образом, представляется целесообразным выбор в качестве среды программирования «Borland
C++ Builder 5» (далее CBuilder).
3.2.2 Разработка структуры высокоуровнего ПО
Высокоуровневое ПО системы видеоконтроля за объектами управления предназначено
для работы совместно с модулем IP-видеокамеры. Структура системы видеоконтроля приведена
на рисунке 3.4.
70
Следует отметить, что модуль IP-видеокамера (вместе с видеокамерами и микрофоном)
устанавливается непосредственно на объекте, за которым необходимо установить видео
наблюдение. Разрабатываемое высокоуровневое ПО должно быть установлено на ПК в
диспетчерском пункте (на АРМ инженера или оперетора).
ПК
ПК
модем
ЛВС
switch
Модуль
“IP-видеокамера”
Телефонная
линия
Модуль
“IP-видеокамера”
микрофон
модем
микрофон
камеры
камеры
a) Использование ЛВС в качестве канала
передачи данных
б) Использование телефонной линии в качестве
канала передачи данных
Рисунок 3.4 – Два типа структуры системы видеоконтроля
Требования к функциям высокоуровнего ПО были приведены в пункте 2.4.2. ПО
системы видеоконтроля может работать в трех режимах:
-
режим оператора;
-
режим инженера;
-
режим администратора.
Режим оператора – это основной режим работы приложения. В данном режиме
осуществляется:
-
трансляция видео- и аудио- потока с IP-видеокамеры, назначенной диспетчером, на
ПК, с воспроизведением изображения и звука;
-
управление параметрами изображения и звука;
-
управление переключением источников видеосигнала;
-
запись аудио-видео потока на диск.
71
Управление всеми функциями приложения в режиме оператора может осуществляться с
помощью клавиатуры и «мыши».
Режим инженера служит для настройки приложения, настройка режимов работы
IP-камеры. В данном режиме осуществляется:
-
выбор и настройка канала наблюдения;
-
выбор
источников
видеосигнала
для
режима
автоматического
циклического
переключения;
-
задание периода переключения источников видеосигнала;
-
выбор директории для записи аудио-видео информации;
-
выбор размера отображения видео информации;
-
выбор горячих клавиш для переключения активности канала наблюдения.
Вход в режим инженера осуществляется по нажатию специальной кнопки на панели
управления и возможен только при выключенной видеотрансляции.
Режим администратора предназначен для просмотра журнала событий и настройки его
параметров. ПО обеспечение может быть настроено таким образом, что в журнале событий
будут фиксироваться все действия оператора и инженера (нажатие кнопок, запуск/останов
видео и т.д.).
Внешний вид ПО системы видеоконтроля представлен на рисунке 3.5. ПО обеспечение
системы видеоконтроля состоит из следующих панелей:
-
Панель управления (панель оператора);
-
Панель инженера (появляется при входе в режим инженера);
-
Панель администратора (появляется при входе в режим администратора);
-
До 4-х панелей видеонаблюдения (зависит от настройки ПО).
Рисунок 3.6 – Внешний вид ПО системы видеоконтроля
72
Среда программирования CBuilder предоставляет программисту широкие возможости по
использованию готовых компонентов, классов и функций, так и созданию собственных.
Использование компонентов позволяет быстро создавать приложения из готовых “кубиков”,
добавляя в них требуемые функции.
Для разработки ПО системы видеоконтроля были использованы как стандартные, так и
разработанные в СКБ специализированные компоненты. Список используемых компонентов:
TButton – стандартные компонент “кнопка”;
TComboBox – стандартные компонент “выпадающий список”;
TCheckBox – стандартные компонент “флажок (переключатель)”;
TEdit – стандартные компонент “текстовое поле”;
TLabel – стандартные компонент “надпись”;
TTimer – стандартные компонент “таймер”;
– разработанный в СКБ компонент для работы с устройством IP-
TUDPCamera
видеокамера (обмен данными);
TVideoDec
–
разработанный
в
СКБ
компонент
для
декомпрессии
сжатого
видеоизображения;
TSoundPlay – разработанный в СКБ компонент для работы со звуком;
TMovieRec – разработанный в СКБ компонент для записи видео- и аудиофрагментов на
жесткий диск (или носитель);
TLogWrite – разработанный в СКБ компонент для записи файла журнала событий;
TLogRead – разработанный в СКБ компонент для чтения файла журнала событий;
3.2.3 Методы отладки программного продукта
Среда программирования CBuilder предоставляет программисту мощные средства
отладки, в том числе связанные некоторыми особенностями разработки кода под
мультипрограммную ОС. В частности, CBuilder содержит интегрированный отладчик и Object
Browser для контроля за результатом процесса компиляции двумя способами, а также ряд
других сервисов нацеленных на поддержку процесса отладки. Использованные при разработке
сервисы отладки перечислены и описаны ниже.
Отладка с помощью Integrated Debugger. Каждый раз, когда программа запускается из
среды CBuilder, она выполняется под управлением отладчика. Это происходит, пока включена
опция Integrated Debugger в странице Preferences диалоговой панели Environment Options. Когда
73
программа выполняется под управлением отладчика, щелкнув по кнопке Pause в линейке
SpeedBar, можно остановить выполнение. После остановки программы можно выполнять ее
шаг за шагом, щелкнув по кнопке Step Over.
Но поскольку приложения Windows управляются сообщениями, нельзя выполнять код
приложения шаг за шагом от начала до конца, как это можно сделать с приложением DOS.
Поэтому основной способ отладки приложения CBuilder или любого другого приложения
Windows состоит в том, чтобы установить точки останова в определенных местах кода,
который нужно исследовать.
Указание точек останова. Существует ряд способов для указания точек останова в
CBuilder. Самый простой метод заключается в следующем: щелкнуть в окне редактора слева от
кода (между текстом и рамкой окна). При этом появляется пиктограмма (красная точка) и
данная строка отображается другим цветом.
Установка точки останова допустимо, если в данной строке выполняется какой-либо
код. Это исключает, например, объявления переменных или процедур, а также участки,
которые лишены кода из-за оптимизации компилятора. При указании точки останова на одной
из таких строк компилятор помечает ее как недоступную и не анализирует ее во время
выполнения.
При размещении множества точек останова можно использовать команду Breakpoints
меню View, чтобы открыть окно Breakpoint List. Один из пунктов в верхней части окна
Breakpoint List предполагает добавление условия в точке останова, так чтобы программа
останавливалась только при выполнении данного условия. Подобная возможность оказывается
чрезвычайно полезной в тех случаях когда, выполнение кода, отмеченного точкой останова,
может происходить многократно, однако при отладке интересует только определенное
состояние программы и ее данных в этот момент.
Кроме того, окно Breakpoint List позволяет управлять присутствующими точками
останова (добавлять, удалять, разрешать, запрещать).
Проверка значений. Если программа остановлена в отладчике, можно проверить
значение любого идентификатора, который доступен в этой точке программы. Для этого в
CBuilder существуют три способа: использовать диалоговую панель Evaluate/Modify, добавить
элемент в окно Watch List или подвести курсор мыши к соответствующему имени
идентификатора в тексте и увидеть его содержимое в появляющейся строке.
74
Диалоговая панель Evaluate/Modify имеет два режима работы. Можно использовать ее
для проверки значения данного идентификатора или выражения, а также для изменения
значения переменной.
Если же необходимо изменять значение переменной много раз, использование этой
диалоговой панели замедляет процесс. Можно также установить наблюдение за любой
переменной, свойством или компонентом, используя группы команд Add Watch. Список
наблюдаемых объектов и их значения после остановки можно просмотреть в окне Watch List.
75
4 ОЦЕНКА РЕЗУЛЬТАТОВ РАЗРАБОТКИ
В данном разделе будут рассмотрены следующие вопросы:
-
Оценка результатов разработанной системы;
-
Оценка результатов разработанного ПО контроллера ASK-Lab;
-
Результаты применения системы видеоконтроля.
4.1 Оценка результатов разработанной системы
Выполняя оценку разработанной системы, рассматриваются аспекты использования как
результатов разработки в дипломной работе (использование контроллера ASK-Lab и системы
видеоконтроля), так и результатов работы других участников проекта (высокоуровневое ПО
диспетчерского пункта и т.д.).
4.1.1 Основные технические характеристики
Количество распределенных объектов (узлов теплоучета)
- до 400
Радиус системы (удаленность объектов от ДПС)
- до 50 км.
Способ обмена данными
- телефонные линии общего пользования (использование стандартных модемов);
- прямое подключение через интерфейс RS-232 устройств (теплосчетчики,
контроллеры) к ПК для тестирования.
Время опроса узлов
- полный цикл опроса всех узлов:
не более 1 часа;
- загрузка архивов с теплосчетчиков:
от 1 часа до 1 суток.
Аппаратура верхнего уровня системы (ДПС)
- сервер БД;
- ПК (АРМы) диспетчеров, объединенные в ЛВС;
- модемы с выходом в городскую телефонную сеть.
Аппаратура нижнего уровня системы (узел теплоучета)
- 10 типов теплосчетчиков;
- контроллер ASK-Lab;
- теплорегулятор ECL-300 COMFORT;
76
- модемы с выходом в городскую телефонную сеть;
- аппаратура системы видеоконтроля.
ПО верхнего уровня системы
- СУБД ORACLE;
- ПО системы видеоконтроля;
- ПО для опроса теплосчетчиков;
- ПО для опроса теплорегулятора и задания его настроек;
Функции мониторинга
- считывание текущих и архивных данных теплосчетчиков;
- считывание данных и настроек теплорегулятора;
- считывание данных и настроек контроллера ASK-Lab;
- видеоконтроль за состоянием объекта.
Функции управления
- управление силовыми устройствами, подключенными к контролеру ASK-Lab;
- задание режимов теплорегулирования (настройка параметров теплорегулятора).
Функции автоматизации
- контроль ПО верхнего уровня системы нештатных ситуаций в автоматическом
режиме
4.1.2 Сравнение с существующими аналогами
Обзор систем класса ИС и ИУС для автоматизации, мониторинга и управления
показал, что в настоящее время идет большой спрос на подобного рода системы в
различных областях промышленности и жилищно-коммунального хозяйства страны. Всвязи с
этим, на рынке представлено большое количество систем класса ИС и ИУС. Большинство
систем класса ИУС обладают схожими функциональными возможностями. Основные
недостатки существующих систем:
-
Большой объем работ по адаптации системы к существующей архитектуре объектов
(замена большинства аппаратной части оборудования)
-
Ограничение на количество распределенных объектов (многие системы позволяют
обслуживать не более 100 объектов)
-
Высокая стоимость аппаратно-программных ресурсов;
Разработанная в рамках проекта РИУС ПоТок-С, отчасти лишена этих недостатков.
Разработанная система ПоТок-С для дистантного мониторинга и управления режимами
теплоснабжения объектов отвечает всем требованиями к подобного рода системам,
77
изложенными ранее. Также в системе используется ряд интересных решений и уникальных
разработок.
4.1.3 Использование продукта
Данные продукт, прежде всего, предназначен для использования в филиале ПТС ОАО
“Северо-Западный Телеком”. Однако многие компоненты системы являются универсальными,
и система, в целом, может использоваться во многих областях жилищно-коммунального
хозяйства. РИУС ПоТок-С может быть легко переконфигурирована для различной топологии
объектов в системе; в качестве узлов может быть использовано любое оборудование,
поддерживающее соединение по стандартным интерфейсам RS232 или CANBus.
4.2 Оценка результатов разработанного ПО контроллера ASK-Lab
Разработанное низкоуровневое ПО предназначено для конкретного типа контроллера
(ASK-Lab). Выполняя оценку разработанного ПО контроллера, рассматриваются в основном
функциональные
возможности
контроллера
ASK-Lab,
которые
обеспечиваются
использованием данного ПО в контроллере.
4.2.1 Основные технические характеристики
Основные технические характеристики ПО контроллера ASK-Lab:
-
Возможность обращения к 3-м устройствам по одной линии связи (контроллер ASKLab, теплосчетчик и теплорегулятор ECL Comfort 300);
-
Настройка параметров контроллера;
-
Энергонезависимое хранение параметров контроллера;
-
Обмен данными с ПК по линии связи (телефонная линия или прямое соединение
контроллера и ПК);
-
Использование протокола ASK-bus 3.1 в качестве протокола сетевого и транспортного
уровня для обмена данными с ПК;
-
Обеспечение режима “прозрачности” (поддержка работы программного обеспечения
предыдущей версии системы (РИС ПТС-1) для обмена данными с теплосчетчиками)
-
Защита данных. Использование алгоритма ГОСТ 28147-89 для кодированиядекодирования команд управления и особо важных данных;
78
-
Считывание данных (параметров) с теплосчетчиков и теплорегулятора ECL Comfort
300;
-
Изменения параметров теплорегулятора ECL Comfort 300;
-
Управление силовыми устройствами (до 8-и);
-
Протоколирование событий;
-
Контроль времени выполнения задач.
4.2.2 Сравнение с существующими аналогами
В настоящее время существует много различных предложений контроллеров и
встраиваемых компьютеров таких известных производителей, как Siemens, Advantech,
SCADAPack, WAGO, Контар. Продукция большинства этих производителей обладает
многофункциональностью,
универсальностью,
модульностью.
Продукция
разных
производителей имеет свои преимущества и недостатки. Большинство устройств являются
универсальными, сочетая в себе большую избыточную функциональность, и как следствие
большую стоимость.
В РИУС ПоТок-С требовалось устройство, обеспечивающее возможность работы с 3-мя
устройствами по одной линии связи, работы со стандартными 56К модемами и выполняющее
функции коммуникации, мониторинга, управления и защиты информации. Разработанное ПО
позволило использовать контроллер ASK-Lab в качестве такого устройства. Использование
продукции других производителей существенно увеличило бы стоимость устройства,
поскольку для реализации требуемых функции потребовалось бы использование нескольких
аппаратных модулей и дорогостоящих средств разработки ПО.
4.2.3 Использование продукта
Основным
назначением
разрабатываемого
программного
продукта
(запрограммированного в контроллер ASK-Lab) является обеспечение возможности работы
контроллера ASK-Lab в составе РИУС ПоТок-С в качестве основного узла объектов,
оснащенных теплорегулирующим оборудованием (теплорегулятор ECL-300 Comfort, датчики и
исполнительные механизмы), и выполнение им коммуникационных и управляющих функций.
Разрабатываемый программный продукт позволяет сделать контроллер ASK-Lab
недорогим, надежным и многофункциональным устройством для построения большинства
систем коммерческого учета на бытовых и промышленных объектах. Программный продукт
разработан на основе мОСРВ А3. В дальнейшем возможно совершенствование данной мОСРВ,
79
добавление новых библиотек функций и драйверов. Конструктор А3 позволяет легко описать
структуру ПО под мОСРВ А3, предоставляя простые возможности по модификации ПО. Тем
самым, возможна быстрая и простая доработка ПО контроллера для использования в различных
применениях, с возможностью построения распределенных систем на его основе, или
автономной работы.
Так, например, за время работы над проектом контроллер ASK-Lab был использован в
качестве контроллера системы управления движением автономного робота (некое подобие 4-х
колесной тележки), а также основного звена в контуре управления тепловым режимом здания.
4.3 Результаты применения системы видеоконтроля
В рамках первого этапа реализации проекта в первом полугодии 2005 г. проводились
инженерные эксперименты для проверки ряда новых подходов по обеспечению надежности
управляющей подсистемы ПТС-2 в режимах ручного управления исполнительными
механизмами с ДПС (с АРМ инженера). Для экспериментов была применена система видео
контроля (высокоуровневое ПО для этой системы разработано в рамках дипломной работы),
которая находился в одном здании с центральным ДПС. Структурная схема эксперимента
представлена на рисунке 4.2.
Оператор подсистемы ПТС-2 с АРМ инженера может контролировать положение
вентилей с помощью четырех камер, и таким образом у него появляется возможность
контролировать результат собственных действий. Для передачи данных использовался 4-х
канальный IP-видео контроллер с вейвлетовским сжатием.
Для
отработки
вопросов
системной
интеграции
для
передачи
изображений
использовалась локальная сеть и четыре малогабаритных черно-белых камеры. Принимаемая с
видеокамер информация отображалась на виртуальной панели АРМ инженера.
ПО системы видеоконтроля АРМ инженера обеспечивает широкий спектр возможностей
для оператора по управлению, как дистантного управления режимами работы камер, так и
режимами отображения видеоинформации на виртуальной панели.
Контроллер ASK-Lab обеспечивает возможность дистантного управления 8 каналами
дискретного выхода (подключены силовые устройства). Для визуализации используется
видеоизображение текущего состояния исполнительных механизмов.
80
ЛВС
АРМ
Инженера
модем
Модуль
“IP-идеокамера”
Канал видеоконтроля
Телефонная
линия

модем
Контроллер
ASK-Lab


Канал управления
Автоматизированные
задвижки (входная и
выходная)
Клапан слива
Освещение
Объект управления
Рисунок 4.2 – Структура экспериментального фрагмента подсистемы
ПТС-2
При проведении экспериментов выявилась необходимость обеспечить должный уровень
освещенности контролируемых зон. Для этого был использован один из каналов управления
контроллера ASK-Lab, что обеспечило возможность оператору дистанционно управлять
освещением. Возможной альтернативой такому подходу является использование видеокамер со
встроенной, либо специально организованной ИК-подсветкой объекта наблюдения.
К настоящему времени проведен ряд эксперименты как по визуальному контролю за
текущими положением задвижек, так и по визуальному способу съема показаний с манометров.
При этом сжатый видеопоток передавался по 100 Мбитной локальной сети на АРМ инженера,
так как эксперимент проводился в теплопункте здания, в котором размещается диспетчерский
пункт филиала ПТС ОАО “Северо-Западный Телеком”. При отображении информации с одной
контрольной точки оператору представлялась возможность отслеживать ситуацию на объекте в
телевизионном режиме, т.е. 25 кадров в секунду.
Следует
отметить,
что
использованный
модуль
“IP-Видеокамера”
использует
мультиплицированный видеовход и при необходимости отображения двух и более точек
возникают задержки, обусловленные тем, что минимальное время переключения между
каналами составляет 250-300 мсек, что соответствующим образом ограничивает качество видео.
Таким образом, при передаче команд управления по одному из каналов оказалось
целесообразным отслеживать ее выполнение с помощью закрепленной за этим каналом камеры.
При необходимости отслеживать ситуацию в 2-х и более контрольных точках разработанное
ПО обеспечивало две возможности.
81
Во-первых, можно сканировать каналы по очереди с задаваемым оператором периодом
переключения каналов, а во-вторых, использовать режим программного квадратора. В этом
режиме на виртуальной панели экране отображается от двух до четырех видеопотоков с
отображением времени получения последнего кадра с объекта. При расширении этого способа
контроля на все объекты архитектура системы несколько усложниться. В этом случае
потребуется обеспечить возможность подключения IP-контроллера к сети Интернет, что в
условиях ОАО “Северо-Западный Телеком” не составляет проблемы, так как объекты ПТС
сами образуют коммуникационную среду мегаполиса.
Был также выполнен ряд поддерживающих экспериментов по использованию модемов
для передачи видеоизображений по коммутируемым линиям общего пользования. Как показали
проведенные эксперименты, в этом случае в условиях г. Санкт-Петербурга имеется
возможность передавать видеоизображение со скоростью 0.5-1 кадр/сек, что обеспечивает
возможность контроля по видеоканалу в реальном времени.
Фактически,
проведенные
эксперименты
продемонстрировали
состоятельность
подобного подхода, и открывают дорогу к широкому использованию визуального способа
контроля за состоянием объекта управления в РИУС, реализованных на коммутируемых линиях
общего пользования. Одним из дополнительных аргументов в пользу предлагаемого решения
является тот факт, что в связи с бурным развитием цифровых технологий в настоящее время
аппаратная составляющая такого рода систем в настоящее время стремительно дешевеет.
В настоящее время этот компонент системы передан в опытную эксплуатацию в филиал
ПТС ОАО “Северо-Западный Телеком”.
82
ЗАКЛЮЧЕНИЕ
Начавшаяся вторая волна цифровой революции привела к резкому сокращению сроков
морального старения, как приборов учета, так и телекоммуникационного оборудования. Из-за
того, что использование новой элементной базы является экономично более выгодным, при
запуске новых образцов, производители, как правило, прекращают выпускать изделия старых
моделей. В системах учета и автоматизации, в которых имеется большое число объектов,
замена всего оборудования представляет собой весьма проблематичную задачу, из-за большого
объема работ и высокой стоимости. С точки зрения системной интеграции это обстоятельство
приводит к необходимости обеспечения возможности замены аппаратных средств без коренной
модернизации, что и обеспечивается использованием контроллеров и программного
обеспечения собственной разработки, при условии, что может быть обеспечено их
сопровождение на всем жизненном цикле.
В настоящее время существуют разные подходы к выбору аппаратного и программного
обеспечения нижнего уровня для систем промышленной автоматизации, диспетчерского
мониторинга и контроля. Есть примеры использования как готовых ПЛК [5], так и разработки
собственных контроллеров [4], [6], [7]. Разработка уникальных контроллеров и программного
обеспечения для них обеспечивает требуемую гибкость проекта, что является необходимым
условием при реализации пилотных проектов и обеспечивает возможность эффективной
поддержки системы за счет унификации ряда решений в коммуникационной составляющей
систем.
Верификация разработанного ПО и работоспособности всей системы осуществлялась на
протяжении отопительного сезона 2004-2005 посредством параллельной работы с комплексами
Аструм и Кливер. При этом представляется важным подчеркнуть, что полученные с этих
комплексов учетные данные использовались в качестве эталонных, что позволило существенно
сократить время отладки и, соответственно, снизить стоимость разработки ПО.
Разработанное ПО (низкоуровневое ПО контроллера ASK-Lab и высокоуровневое ПО
системы видеоконтроля), рассматриваемое в рамках всего проекта в целом, позволило
выполнить ряд особо важных функций по переводу существующей РИС ПТС-1 в разряд РИУС
(ПоТок-С). Предложенные решения имеют универсальный характер и легко масштабируются
для аналогичных применений в предприятиях жилищно-коммунального хозяйства, крупных
компаниях с сетевой структурой. РИУС ПоТок-С отвечает всем требованиям к системам
дистанционного мониторинга и управления [5], и имеет ряд интересных решений, таких как
использование системы видеоконтроля на объектах (контроль действий оператора при
83
выполнении им функций управления, визуальный мониторинг состояния объекта), применение
алгоритмов шифрации при обмене конфиденциальной информацией и д.р.
В настоящее время РИУС ПоТок-С передан в опытно-промышленную эксплуатацию в
диспетчерский центр АУЭ филиала ПТC ОАО “Северо-Западный Телеком”. При этом к системе
подключено около сотни станций, из которых 10 оснащены автономными узлами
регулирования, оборудованных контроллерами ASK-Lab. Одна станция оборудована системой
видеоконтроля. На 2006 год запланировано подключение к этой подсистеме еще 14 узлов с
автономным регулированием, и последующей установкой на всех таких узлах системы
видеоконтроля.
Результаты работы были представлены на первый европейский конкурс студенческих
работ ESPC-2005, проводимый под эгидой ISA (21.05.2005, Корк, Ирландия) и удостоены
Золотой медали. Демонстрационный показ работы РИУС ПоТок-С представителям ГК ОАО
“Ленэнерго” получил положительный отзыв. 12.12.2005 был подписан акт внедрения системы
ПоТок-С. В настоящее время по результатам выполненной работы готовится серия публикаций
с целью популяризации полученного при разработке опыта.
84
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Анисимов А.Л., Астапкович А.М., Дмитриев С.В. и др. Проблемы и перспективы создания
интегрированных коммунальных систем учета потребления энергоресурсов. // Cборник
Информационно-управляющие системы и сети. Структуры. Моделирование. Алгоритмы.
Политехника, СПб., 1999, с. 165-185.
2. Шумилов И.А., Анисимов А.Л., Астапкович А.М. и др. Перспективы создания
интегрированных коммунальных систем учета потребления энергоресурсов. // Труды
конференции Коммерческий учет энергоносителей 10-я конференция. Совершенствование
измерений расхода жидкости газа и пара, Политехника, СПб., 1999, с. 340-360.
3. Ладугин Д.В. Интегрированная система коммерческого учета тепловой энергии и
природного газа на базе программно-технических комплексов серии “КРУГ-2000”// Журнал
Датчики и системы № 5, 2005, c. 2-5
4. Бартенев В.Г., Бартенев М.В Энергосберегающая модульная АСУТП для распределенных
объектов “СИНТАЛ ТЕЛЕТЕРМ” // Журнал Датчики и системы, № 2, 2005, c. 32-35
5. Плющаев В., Грошева Л., Мерзляков В., Перевезенцев С., Зуев А., Пахомов А. Система
дистанционного
мониторинга
и
управления
объектами.
//
Журнал
Системы
Технологической Автоматизации, № 2, 2003, с. 6-15.
6. Карташев А.А., Мартынов В.И. Организация учета энергоносителей на источниках теплоты
в бюджетной и жилищно-коммунальной сфере г.Сургута // Труды конференции
“Коммерческий
учет
энергоносителей” XX1-я
международная
научно-практическая
конференция Санкт-Петербург, май, 2005, с. 321-324.
7. Титович Ю.В., Барашков В.М., Астапкович А.М., Касаткин А.А. Обслуживание
индивидуальных тепловых пунктов в филиале “Петербургская Телефонная Сеть” ОАО
“Северо-Западный Телеком”// Журнал “Энергосбережение”, № 4, 2005, с. 2- 6 .
8. Астапкович А.М. Микрооперационные системы реального времени // Монография, СПб:
Политехника, 2002.
9. Астапкович А.М. (2003) Формализм адресно-временных карт для описания алгоритмов
функционирования многоканальных систем управления. Введение в формализм адресновременных карт. // Журнал Информационно-управляющие системы, № 4, 2003, с. 6-14.
10. Астапкович А.М. (2004) Формализм адресно-временных карт для описания алгоритмов
функционирования многоканальных систем управления. Базовые объекты и операции с АТкартами. // Журнал Информационно-управляющие системы, 2004, № 2, с. 26-37.
85
11. Астапкович А.М., Востриков А.А., Касаткин А.А, Чудиновский Ю.Г., Bishop R. Опыт
использования
информационно-управляющих
сетевых
систем
для
передачи
видеоизображений. // Сборник Семинары ASK Lab 2001, с. 180-197.
12. Анисимов А.Л., Астапкович А.М., Востриков А.А., Елисеенко А.Г. ,
Кравченко Д.А.,
Плигин М.В., Сергеев М.Б., Суханов И.О. Система предоплаты за потребляемую энергию
Кредо-Смарт 500 //Сборник: Микропроцессорные информационно-управляющие системы
реального времени / Под общ. ред. М.Б.Сергеева. - СПб: Политехника, 2000, с.198 – 215.
13. ГригорьевМ.В., Шафер Е.С., Балихин И.Н., Плюшаев В.И. Аппаратно-программный
комплекс для канализационных насосных станций // Журнал Водоснабжение и санитарная
техника, №6, 2000.
14. Галузов М. В. Комплексная диспетчеризация объектов различного назначения // материалы
сайта www.rtservice.ru, Информационные системы учета энергоресурсов.
15. Материалы сайта www.logika.spb.ru.
16. ThinkIO – универсальное решение для промышленной автоматизации // RTSoft Средства и
системы автоматизации, Каталог продукции, 2005.
17. Роботы для слежения за электрической сетью // материалы сайта www.English.Eastday.com.
18. Соловьев С.А. Контроллеры SCADAPack в системах коммерческого учета энергоресурсов //
в трудах конференции “Коммерческий учет энергоносителей” XX1-я международная
научно-практическая конференция Санкт-Петербург, май 2005, стр.277-279.
19. NetCore - одноплатный компьютер // материалы сайта www.Trail.ru.
20. InorTek µC-Series – микроконтроллеры // материалы сайта www.nevabls.ru.
21. Контроллеры измерительные "КОНТАР" МС8 // материалы сайта www.mzta.ru.
22. материалы сайта www.Prosoft.ru.
86