Распределенная информационно- управляющая система поток-С

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

Аппаратура СДМУ, устанавливаемая  непосредственно на объектах, должна обладать возможностью гибкого конфигурировании в зависимости от технических особенностей объекта. Основой такой аппаратуры, как правило, являются технологические контроллеры (ТК). Каждый ТК должен иметь возможность подключения:

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

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

 

2.3 Особенности  построения и концепция РИУС  ПоТок-С

 

При разработке архитектуры РИУС ПоТок-С, наряду с общими требованиями, изложенными ранее, были учтены дополнительные требования заказчика.

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

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

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

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

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

Структура системы представлена на рисунках 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.

Одним из дополнительных требований к программному обеспечению  контроллера ASK-Lab являлась необходимость обеспечения режима “прозрачности” при опросе его фирменным программным обеспечением контролирующими организациями.

 

 

 

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

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

 

2.4 Требования  к программному обеспечению системы

 

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

• специализированное низкоуровнеаое программное обеспечение для контроллера ASK-Lab;
• высокоуровневое программное обеспечение для системы видеоконтроля;

 

2.4.1 Требования  к низкоуровнему программному  обеспечению

 

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

• возможность обращения к 3-м устройствам по одной линии связи (контроллер ASK-Lab, теплосчетчик и теплорегулятор ECL Comfort 300);
• дистантная и местная настройка параметров контроллера;
• энергонезависимое хранение параметров контроллера;
• обмен данными с ПК по линии связи (телефонная линия или прямое соединение контроллера и ПК);
• использование протокола ASK bus 3.1 в качестве протокола сетевого и транспортного уровня для обмена данными с ПК;
• обеспечение режима “прозрачности” (поддержка работы программного обеспечения предыдущей версии системы (РИС ПТС-1) для обмена данными с теплосчетчиками)
• защита данных (использование алгоритма ГОСТ 28147-89 для кодирования-декодирования команд управления и особо важных данных);
• считывание данных (параметров) с теплосчетчиков и теплорегулятора ECL Comfort 300;
• изменения параметров теплорегулятора ECL Comfort 300;
• управление силовыми устройствами (до 8-и);
• протоколирование событий;
• контроль времени выполнения задач.

 

2.4.2 Требования к высокоуровнему программному обеспечению

 

Разрабатываемое высокоуровневое  программное обеспечение для  системы видеоконтроля за объектами  управления предназначено для работы совместно с модулем IP-видеокамеры [11] и должно обеспечить выполнение следующих функций:

• прием видео- и аудио- потоков с IP-видеокамеры на ПК, с воспроизведением изображения и звука;
• управление параметрами изображения и звука;
• возможность переключения между подключенными к IP-видеокамере источниками видеосигнала (до 4-х камер);
• обеспечение функции программного квадратора (циклическое переключение между указанными источниками видеосигнала с заданным периодом; при этом на виртуальной панели отображаются изображения от всех видеоисточников и время получения последнего кадра от каждого видеоисточника);
• возможность записи аудио-видео потока на жесткий диск ПК;
• возможность управления режимами работы программного обеспечения с помощью “горячих” клавиш.

 

3 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

3.1 Низкоуровневое  ПО контроллера ASK-Lab

 

3.1.1 Обоснование  выбора инструментальных средств  для разработки ПО

 

3.1.1.1 Выбор  необходимых аппаратных средств

 

Для разработки низкоуровнего  ПО выбираются следующие аппаратные средства:

• Контроллер;
• Устройство программирования (далее программатор) для данного типа контроллера;
• Аппаратной эмулятор для данного типа контроллера;
• ПК для создания и отладки ПО;

Контроллер выбирается исходя из требований, предъявляемых  к функциональности данного устройства. Требования к функциям контроллера  были приведены в пункте 2.4.1. Для выбора контроллера возможно несколько вариантов.

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

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

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

Как показал обзор существующих решений по контроллерам и встраиваемым компьютерам (смотри подраздел 1.2), среди всего многообразия предлагаемых и доступных устройств нет готовых решений на базе одного устройства. Как правило, основным ограничивающим фактором является требование на наличие 3-х интерфейсов RS-232 и до 8-и каналов дискретного вывода в выбираемом контроллере.

Возможен второй вариант, когда берется существующий контроллер или встраиваемый компьютер и  дополняется различными модулями расширения. В общем случае получается комплекс устройств, обладающий достаточно большой  избыточностью дополнительных функциональных возможностей, и как следствие, большой стоимостью. Цена таких решений зависит от производителя компонентов и разнообразия предлагаемых функций, и, как правило, начинается от 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 был выбран в качестве аппаратного эмулятора.