|
| |
|
Главная -> Экология
Веб-базированный доступ к технол. Переработка и вывоз строительного мусораОлег Кильницкий 7 отечественных энергоснабжающих компаний планируют полностью ликвидировать сверхнормативные потери электроэнергии до конца 2004г. В украинской энергосистеме теряется каждый 5-й киловатт-час. Столь прискорбный факт свидетельствует прежде всего о высокой энергозатратности отрасли. Кроме того, в общем объеме потерь электроэнергии высокую долю занимают сверхнормативные потери, которые для энергокомпаний выливаются в многомиллионные убытки, а также снижают уровень расчетов. Все это в конечном итоге вносит финансовую дестабилизацию в работу топливно-энергетического комплекса страны. В то же время руководители 7-ми облэнерго и обслуживающей их компании «Укрэнергоконсалтинг» считают, что избавиться от «сверхнорматива» можно достаточно быстро. Фактор желания «Для того, чтобы успешно бороться со сверхнормативными потерями, первое, что нужно сделать - это захотеть, а второе — заболеть этой проблемой». Эти слова директор департамента энергосбытовой политики ООО «Укрэнергоконсалтинг» Анатолий Скиба произнес на специальной сентябрьской конференции по подготовке 7-ми энергоснабжающих компаний — ОАО «Запорожьеоблэнерго», ОАО «Полтаваоблэнерго», ОАО «Львовоблэнерго», ОАО «Прикарпатьеоблэнерго», ОАО «Тернопольоблэнерго», ОАО «Черниговоблэнерго» и ОАО «Сумыоблэнерго» — к осеннезимнему периоду. Конференция проводилась для первых руководителей районов электросетей (РЭС) перечисленных облэнерго. На первый взгляд смысл сказанного А. Скибой может показаться банальным. Но это только на первый взгляд. Опыт приватизированных компаний «Полтаваоблэнерго», «Сумыоблэнерго» и «Черниговоблэнерго» наглядно свидетельствует, что сверхнормативные потери электроэнергии сложились не только из-за объективных факторов, к которым поставщики обычно относят несовершенную систему образования тарифов на передачу электроэнергии, воровские наклонности потребителей, а также морально и физически изношенную энергосбытовую инфраструктуру. Существует еще один фактор, сокрытый в субъективной плоскости, а именно - в отсутствии надлежащих усилий по преодолению потерь электроэнергии со стороны менеджмента и персонала компаний. Подтверждением являются показатели работы «Полтаваоблэнерго», «Сумыоблэнерго» и «Черниговоблэнерго» в январе-августе этого года. С начала 2003г. сверхнормативные потери электроэнергии в этих компаниях полностью отсутствуют. Более того, они получили 9,8 млн. грн. общей прибыли за счет того, что фактические потери в сетях оказались ниже установленного норматива. Наилучший результат зафиксирован в «Сумыоблэнерго» - 8 млн. грн. прибыли при фактических потерях 13,5% транспортированной электроэнергии и нормативе 16,3%. Можно возразить, что тарифы на передачу электроэнергии для «Полтаваоблэнерго» по украинским меркам всегда были достаточно высокими, а уровень сверхнормативных потерь в «Черниговоблэнерго» всегда был более низким, чем у других энергопоставляющих компаний. Однако, как утверждает А. Скиба, 3 областных поставщика смогли войти «в норму» прежде всего благодаря целенаправленной и системной работе по снижению потерь, к которой эти ОАО приступили гораздо раньше других компаний. У остальных 4-х облэнерго из вышеперечисленных дела с потерями обстоят несколько иначе: общий размер убытков «Запорожьеоблэнерго», «Львовоблэнерго», «Прикарпатьеоблэнерго» и «Тернопольоблэнерго» от сверхнормативных потерь за 8 месяцев составил 86,9 млн. грн. Столь существенную разницу в показателях между этими 2-мя группами А. Скиба объясняет, в частности, тем, что последние 4 компании приступили к системной работе по борьбе с потерями относительно недавно: в конце прошлого — начале нынешнего года. Если результаты всех 7-ми компаний сложить, то за 8 месяцев этого года получится 2872,8 млн. кВтч (14,8%) технологических потерь электроэнергии (ТПЭ), купленной в оптовом рынке электроэнергии. Из этого объема сверх норматива было утеряно 429,8 млн. кВтч (2,2%) транспортированной электроэнергии. Общий размер убытков 7-ми облэнерго - 77,1 млн. грн. И [это по группе лучших компаний! А что творится по Украине? За 2002г. сверхнормативные потери составили около 11 млрд. кВтч, или 2,2 млрд. грн. Цена потерь Cотрудничество 7-и облэнерго с ООО «Укроконсалтинг» началось в 2002г. Консалтинг компания призвана помочь дистрибьюторам решить такие задачи, как снижение потерь электроэнергии до нормативного уровня, обеспечение стабильных 100%-ных расчетов за электроэнергию, возвращение старых долгов потребителей, а также обоснование перед Национальной комиссией регулирования электроэнергетики (НКРЭ) тарифов на передачу электроэнергии, достаточных для рентабельной работы облэнерго. Кроме того, «Укрэнергоконсалтинг» предоставляет и другие услуги технического, финансового и юридического характера. Однако главной совместной целью облэнерго и «Укрэнергоконсалтинга» является ликвидация сверхнормативных потерь. Как разъяснил А. Скиба, проблема расчетов потребителей за электроэнергию, которая ранее являлась наиболее острой и актуальной, в перечисленных энергопоставляющих компаниях практически решена. Что касается тарифов на передачу и поставку электроэнергии, то их нынешний уровень позволяет облэнерго работать с рентабельностью 3-5%. Это не 15%, но расценки на услуги по передаче и поставке электроэнергии пока покрывают эксплуатационные затраты и позволяют компаниям реализовывать инвестиционные программы, хотя и в ограничиваемых НКРЭ размерах. У облэнерго, конечно, немало претензий к действующей системе тарифообразования на их услуги, недостатки которой оборачиваются финансовыми потерями. Однако в «Укрэнергоконсалтинге» считают, что в тарифных вопросах на помощь должно прийти правовое и нормативное регулирование. Поэтому основной проблемой для дистрибьюторов остаются сверхнормативные потери, основную долю которых составляют потери коммерческие в виде неучтенного потребления электроэнергии. Специалисты «Укрэнергоконсалтинга» в ходе конференции подробно остановились на негативных последствиях сверхнормативных потерь. Размер получаемых материальных убытков был проиллюстрирован на простом примере: сколько и что может купить облэнерго за 1 млн. грн. Среди множества вариантов это могут быть: 6,7 тыс. однофазных счетчиков, 2,2 тыс. трехфазных счетчиков, 20,8 тыс. трансформаторов тока 0,4 кВ, 154 силовых трансформатора 40 кВА, 902 км провода АС-25, 323 мобильные радиостанции, 33 автомобиля УАЗ. Или можно построить 17 км линий электропередач напряжением 10 кВ, или 17 разгрузочных подстанций 10/0,4 кВ, или обеспечить санаторными путевками 1,25 тыс. человек. Достаточно напомнить, что размер общих убытков 4-х облэнерго от сверхлимитных потерь электроэнергии составляет 86,9 млн. грн., чтобы представить, чего недосчитались в своем хозяйстве эти компании. А каковы потери в целом по Украине? Не следует забывать и о негативных политических последствиях на уровне отношений энергетиков с местными органами власти. Председатели облгосадминистраций при наличии у энергоснабжающей компании сверхнормативных потерь электроэнергии советуют, прежде чем садиться за стол переговоров с властями, навести сначала порядок в своем доме. Существуют также отрицательные правовые последствия в виде недоразумений с прокуратурой и, конечно же, последствия морально-психологического характера. Алгоритм решения Руководители облэнерго и «Укрэнергоконсалтинга» считают своей основной целью скорейшую ликвидацию сверхнормативных потерь в максимально сжатые сроки и планируют полностью войти «в норму» к концу 2004г. При этом «Полтаваоблэнерго», «Сумыоблэнерго» и «Черниговоблэнерго» должны удержаться на достигнутых позициях и остаться в рамках норматива, а за 2002г. сверхнормативные потери составили около 11 млрд. кВтч, или 2,2 млрд. грн. 4 остальных из перечисленных ранее облэнерго -ликвидировать существующие сверхнормативные потери. «Укрэнергоконсалтинг» в общей программе борьбы с потерями выполняет функции аналитического центра и координатора работ. Консалтинговая компания аккумулирует и обобщает поступающую из облэнерго информацию, разрабатывая для своих клиентов общие рекомендации организации работы по борьбе с потерями, которые содержат положительный опыт отдельных облэнерго, успевших пройти в этом направлении определенный путь. На конференции специалисты «Укрэнергоконсалтинга» изложили перед руководителями РЭС суть данных рекомендаций в систематизированном виде. Согласно этим рекомендациям, первый этап борьбы с потерями электроэнергии представляет собой подготовительные мероприятия. Сначала перед правлением энергопоставляющей компании обозначается суть проблемы и степень ее значимости, после чего правление озвучивает проблему перед управленческим персоналом. Затем службы исполнительной дирекции вместе с соответствующими рабочими группами детально анализируют состояние дел в компании, а также изучают передовой опыт по борьбе с потерями электроэнергии в других облэнерго. Важной частью на подготовительном этапе является изучение факторов, которые влияют на разрешение проблемы ТПЭ. Всего насчитывается до 50-ти таких факторов. Некоторые из них касаются технического обеспечения: транспорт, приборы учета, оборудование, программное обеспечение. Некоторые - идеологического сопровождения (разъяснительная работа с персоналом и потребителями, работа со СМИ). В перечень факторов входят также юридическая поддержка, обучение персонала, материальное стимулирование. Анализ состояния компании вместе с изучением передового опыта и факторов, влияющих на решение проблемы ТПЭ, позволяют разработать программу действий. Эта программа доводится до структурных подразделений облэнерго и руководителей соответствующих служб, после чего правление назначает ответственных лиц по ее реализации. По мнению А. Скибы, основная часть программы должна включать комплекс организационных мероприятий с максимальным использованием внутреннего административного ресурса. К организационным мероприятиям можно отнести формирование специальных участков и бригад по выявлению фактов воровства электроэнергии, закрепление инспекторов за отдельными секторами энергопотребления, организацию ночных рейдов, предупредительную работу с проблемными потребителями. Следующие направления программы - техническое и финансовое обеспечение. Под техническими мероприятиями подразумеваются действия, направленные на предотвращение несанкционированного доступа потребителя к линиям электропередач и приборам учета: установка изолированных вводов к потребителю, вынос счетчиков на фасад дома, пломбирование приборов учета, замена индукционных счетчиков на электронные. Как сообщил на конференции директор Черниговских городских сетей Юрий Калюжный, только установка электронных счетчиков вместо индукционных, не учитывающих т.н. малых токов, позволяет энергетикам ежемесячно экономить 10 кВтч на каждом бытовом абоненте. «Учет малых токов, которых не чувствует индукционный счетчик, имеет большое значение в условиях города, где потребители просто напичканы бытовой техникой», — сказал Ю. Калюжный. Как правило, под сверхнормативными потерями электроэнергии подразумевают прежде всего т.н. коммерческие потери, представляющие собой неконтролируемое энергопотребление и просто элементарное воровство. Поэтому программа устранения таких потерь в первую очередь предусматривает наведение порядка в системе энергосбыта. Однако более дорогостоящей и долгосрочной задачей для поставщиков является снижение технических потерь электроэнергии, которые тоже могут быть как нормативными, так и сверхнормативными. Задача эта чрезвычайно обширна и касается модернизации электросетевой инфраструктуры в целом: оптимизации структуры сетевого хозяйства, сокращения длины линий электропередач путем строительства разгрузочных подстанций, демонтажа невостребованных линий, расчистки трасс, замены недогруженных трансформаторов на менее мощные. В частности, как сообщил Ю. Калюжный, общая установленная мощность трансформаторов в Чернигове составляет 520 МВт и используется не более чем на 30%. И это не удивительно, поскольку существующая сетевая инфраструктура проектировалась в свое время под гораздо большие объемы потребления. «Львиная доля потерь — в режимах работы наших трансформаторов», — заметил Ю. Калюжный. Основная часть сверхнормативных потерь — потери коммерческие в виде неучтенного потребления электроэнергии. Пока же Черниговские городские сети пытаются снизить потери за счет прекращения обдува трансформаторов с загрузкой 15-30%. На одной из подстанций начата также замена трансформатора мощностью 40 МВт на трансформатор 16 МВт. Обмен опытом Как пояснил А. Скиба, основная цель проведения конференции для 7-ми облэнерго заключалась в обмене опытом между руководителями РЭС, что является отдельной составляющей в программе борьбы с потерями. «Укрэнергоконсалтинг» уделяет много внимания налаживанию контактов между энергоснабжающими компаниями по 2-м причинам. Во-первых, одни облэнерго страны ушли не много вперед, и им есть чем поделиться со своими коллегами из других регионов. Во-вторых, областные энергопоставщики имеют разные технико-экономические характеристики и различную структуру потребителей. Несмотря на общность факторов, влияющих на снижение потерь электроэнергии, каждая из компаний в работе может использовать индивидуальные наработки, о которых небезынтересно узнать всем энергопоставщикам. Участников конференции, к примеру, заинтересовала информация директора энергосбыта «Прикарпатьеоблэнерго» Алексея Шекеты о привлечении компанией к сотрудничеству т.н. энергомилиции. Это сотрудники МВД, которые на договорных условиях работают в облэнерго в сфере энергосбыта. По словам А. Шекеты, появление милиционеров в роли энергетических контролеров имеет неизгладимый воспитательный эффект на потребителя. Еще одно изобретение ивано-франковцев -создание специальных групп, способных выезжать в проблемные административные районы и принимать на себя временное руководство РЭС с целью стабилизации ситуации. С помощью такой группы удалось снизить потери электроэнергии с 75% до 25% в одном из наиболее проблемных РЭС — Верховинском, расположенном в горной местности. Не обошлось на конференции и без дискуссий. К примеру, руководители «Чернигов-облэнерго» считают, что борьба с потерями электроэнергии — это война с ворами, приравниваемая к чрезвычайной ситуации, и в ней должны принимать участие все сотрудники облэнерго без исключения - как сбытовики, так и эксплуатационщики. Поэтому внутренние корпоративные отношения в одразделениях «Черниговоблэнерго» строятся по принципу единой команды. В то же время заместитель председателя правления «Сумыоблэнерго» Виктор Середа — решительный противник привлечения эксплуатационщиков к решению проблем энергосбыта. По его мнению, каждая из служб должна заниматься своим делом. В принципе, «Сумыоблэнерго» вполне может позволить себе подобный подход, учитывая, что фактические потери электроэнергии в сетях компании в абсолютном выражении ниже нормативных. В целом участники конференции считают, что опыт их совместной работы по снижению потерь был бы полезен всем отечественным энер-гопопоставщикам. Для этого есть свои причины. По данным «Укрэнергоконсалтинга», общие технологические потери электроэнергии в 7-ми облэнерго за 8 месяцев этого года, по сравнению с аналогичным периодом прошлого года, с 15,60% снизились до 14,77%, в то время как у остальных 20-ти зафиксировано их возрастание с 19,41% до 20,38%. А. Скиба считает, что опыт «Полтаваоблэнерго», «Сумыоблэнерго» и «Черниговоблэнерго» по силам повторить любой отечественной энергопоставляющей компании. В целом проблему сверхнормативных потерь электроэнергии, по его мнению, реально разрешить в Украине в течение 2-3-х лет. Если на это будет соответствующее желание со стороны дистрибьюторов. Сейчас для появления такого желания наиболее подходящее время. Во-первых, согласно постановлению НКРЭ, до 7% сверхнормативных потерь компенсируется из тарифов на электроэнергию тем облэнерго, которые снижают их уровень. Вряд ли это будет продолжаться вечно. Во-вторых, рано или поздно сама экономика заставит энергетиков снижать нормативные потери электроэнергии, т.к. их уровень в Украине слишком высок.
А. Тимербаев, С-Петербургский государственный электротехнический университет ЛЭТИ (СПбГЭТУ), Р. Лангманн, высшая техническая школа г. Дюссельдорфа (Германия), University of Applied Sciences Duesseldorf В данной статье рассматриваются три технологии программирования для реализации веб-базированного доступа к технологической информации: IIS-приложения, Remote Scripting и применение Java. Первая часть посвящена IIS-приложениям, одной из серверных технологий веб-программирования фирмы Microsoft, легко применимой для эффективного доступа к технологическим данным. Обсуждаются преимущества и недостатки этой технологии, рассматривается пример программного приложения, а также особенности практического использования таких приложений. Во второй части обсуждается технология веб-программирования Remote Scripting или удаленное исполнение сценариев. Эта технология фирмы Microsoft, малоизвестная даже среди специалистов, позволяет создавать стабильные, надежные и прежде всего прозрачные решения для прикладного доступа к технологическим данным через Интернет/интранет. В качестве примера применения Remote Scripting рассматривается виртуальный лабораторный практикум, в котором изучаются основы технологии INTERBUS.Третья часть посвящена применению языка Java для реализации веб-базированного доступа к технологическому оборудованию. Сетевые возможности Java позволяют создавать гибкие и быстродействующие программные решения для удаленного обслуживания и диагностики. В отличие от двух предыдущих решений, Java позволяет осуществить динамическое представление технологической информации на веб-странице, причем несколькими способами. Приводятся особенности каждого из способов, а также результаты собственного опыта разработки. Одним из основных условий для осуществления веб-базированного удаленного обслуживания установок, оборудования и устройств является реализация непосредственного доступа к технологической информации. Данная статья посвящена трем характерным программным решениям этой проблемы и рассматривает преимущества и недостатки каждого из них. Часть 1: IIS-приложения Часть 1 посвящена программной технологии, в которой веб-приложение выполняется на сервере, динамически генерируя веб-страницы в ответ на запросы клиентов, и использует для обмена данными стандартный веб-протокол HTTP. В отличие от других серверных технологий программирования, использующих сценарии (CGI, PHP и т.п.), это решение является прикладным расширением веб-сервера Internet Information Server (IIS) фирмы Microsoft и называется IIS- или WebClass-приложением. По сравнению с веб-базированными решениями, создаваемыми на языках сценариев, IIS-приложения обеспечивают более быстрый и эффективный доступ к технологическим данным. Принцип работы IIS-приложения Приложения IIS появились как новый тип проекта в среде разработки Microsoft Visual Basic (VB) 6.0. Приложение IIS представляет собой комбинацию текстовой разметки HTML и ActiveX DLL-библиотеки, которая выполняется сервером IIS (рис. 2). Рис. 1. WebOPCClient: IIS-приложение для веб-базированного доступа к технологическим данным через OPC-интерфейс. Технологические данные котельной установки гибко встраиваются в пользовательский интерфейс веб-страницы Приложения IIS состоят в родстве с приложениями ASP (ASP Active Server Pages): к услугам разработчика IIS-приложений предоставляются все объекты ASP с их функциональными возможностями. Однако в отличие от ASP-страниц, IIS-приложения создаются в среде разработки VB и выполняются сервером быстрее, поскольку на исполнение компилированного кода ActiveX DLL-библиотеки IIS-приложения затрачивается меньше вычислительных ресурсов процессора, чем на интерпретацию сценария [1]. На объектном уровне IIS-приложение состоит из одного или нескольких объектов типа WebClass, каждый из которых содержит ряд элементов WebItem. Эти объектные классы описаны в динамической библиотеке Microsoft WebClass Library (mswcrun.dll), которая является также модулем времени выполнения IIS-приложений. Объект WebClass является основной функциональной единицей приложения. Он обрабатывает запросы, приходящие от веб-браузера и формирует полностью или частично исходный код HTML-страницы для ответной отправки пользователю. Реакция объекта WebClass на запросы клиента описывается разработчиком в специальных процедурах. Элементы WebItems могут быть двух типов: HTML Template и Custom WebItem. Первый тип это HTML-шаблоны, содержащие специальные дескрипторы (теги), которые обозначают места динамической вставки актуального содержания, формируемого IIS-приложением. Ко второму типу относятся программные блоки обработки запросов, которые используются для динамического формирования полного HTML-кода веб-страниц, высылаемых объектом WebClass браузеру в качестве ответа на его запрос [2]. Доступ веб-клиента к IIS-приложению начинается с вызова ASP-страницы, которая автоматически создается средой разработки VB при компиляции IIS-проекта. Этот ASP-файл является, по сути, интерфейсом между веб-клиентом и IIS-приложением. Веб-сервер IIS загружает библиотеку ActiveX DLL данного IIS-приложения в свое адресное пространство и затем исполняет в зависимости от запроса веб-клиента компилированный VB-код. Формируемая при этом HTML-страница отправляется клиенту в качестве результата запроса. Чтобы предоставить веб-клиенту актуальную информацию о технологическом процессе автоматизированной установки, IIS-приложение должно осуществить доступ к интерфейсу технологических данных, считать необходимые данные реального времени и отправить их клиенту вместе с остальным содержанием HTML-страницы. Доступ к переменным процесса на технологическом сервере с целью чтения или изменения их значений может быть реализован либо через специфичный для данного оборудования автоматизации драйвер, либо через имеющийся в распоряжении OPC-сервер (OPC OLE for Process Control). Для обмена оперативными данными на основе стандарта ОРС приложение IIS может использовать интерфейс ОРС Automation Interface, специально предназначенный для VB-приложений [3]. Преимущества и недостатки Как и все чисто серверные программные решения IIS-приложения выполняются полностью на веб-сервере. Поэтому для работы с IIS-приложением из специального программного обеспечения клиенту необходим лишь стандартный веб-браузер. При этом к браузеру не предъявляется никаких особых требований. В практическом применении IIS-приложения зарекомендовали себя как стабильное прикладное программное обеспечение, на базе которого можно создавать надежные решения для веб-базированного доступа к технологической информации. Создание и отладка IIS-приложений осуществляются в комфортабельной среде разработки VB, что намного удобнее по сравнению с разработкой приложений на языках сценариев. Другим достоинством IIS-приложений является физическое разнесение пользовательского интерфейса веб-страницы и прикладной логики, чего нет, например, в ASP-приложениях, в которых программный код сценария и текстовая разметка HTML находятся в одном файле. Такое разнесение упрощает отладку приложения, обеспечивает возможность создания повторно используемых программных компонентов, а также решает проблему разделения труда между веб-дизайнером и программистом. Однако IIS-приложения, формирующие в ответ на запрос пользователя статические веб-страницы, не позволяют осуществить динамического обновления (а значит, и представления) данных на стороне веб-клиента. Кроме того, они могут быть использованы только совместно с веб-сервером IIS фирмы Microsoft. Еще один недостаток заключается в непрозрачности IIS-приложений. Приложение ActiveX DLL представляет собой закрытый объект, недоступный для дальнейшей обработки и использующий HTML-шаблоны или программно генерируемые HTML-страницы, определенные программистом на этапе разработки. Хотя HTML-файлы шаблонов и являются отличной возможностью для пользователя, владеющего HTML, создать собственный дизайн для динамически генерируемых веб-страниц, на основе одного шаблона может создаваться только одна веб-страница, причем количество динамических вставок также заранее определено программистом. Таким образом, набор функций конкретного IIS-приложения узко специфичен и, в отличие от веб-приложений на языках сценариев, уже недоступен для последующей доработки пользователю, не располагающему исходным VB-кодом IIS-приложения. Пример приложения: WebOPCClient Программное обеспечение WebOPCClient представляет собой несложное IIS-приложение и служит для отображения актуальных технологических данных на веб-странице в виде таблицы (рис. 1). В качестве интерфейса доступа к данным технологического процесса используется ОРС. Доступ к технологической информации с помощью WebOPCClient в целях мониторинга или управления защищен соответствующими паролями. Рис. 2. Веб-базированный доступ к технологической информации с помощью IIS-приложения В столбцах HTML-таблицы, отображающей актуальную технологическую информацию, помещаются идентификаторы элементов данных OPC (OPC-переменных), информация о типе данных и правах доступа переменных (только для чтения, для чтения и записи), а также актуальные значения переменных процесса и сообщения, которыми сопровождаются операции чтения или записи значений по каждой из переменных. Имя OPC-сервера, с помощью которого осуществляется доступ к технологической информации, а также список идентификаторов ОРС-переменных, необходимых для мониторинга и управления процессом, предварительно задается в файле инициализации с расширением INI, который находится в каталоге IIS-приложения. В INI-файле могут быть также заданы и другие настройки приложения: символические имена, под которыми ОРС-переменные должны фигурировать в таблице на веб-странице, пароли для доступа к данным в режиме чтения и записи значений переменных, необходимость отображения отдельных столбцов таблицы и т.п. Таблица с технологической информацией, также как и некоторые другие элементы веб-страницы, создается IIS-приложением динамически. Динамическая вставка отдельных фрагментов HTML-страницы происходит в местах расположения определенных тегов в файле-шаблоне, на базе которого строится отправляемая клиенту страница. По умолчанию это тег WC@, хотя по желанию разработчика он может быть переопределен. Например, веб-страница, представленная на рис. 1, создается на основе HTML-шаблона Tmpl1, в котором вместо тела таблицы присутствует только тег WC@ с текстом Table_Body (см. фрагмент 1 на рис.3). Рис.3 Фрагмент 1 HTML-кода При нажатии на веб-странице кнопки обновления или записи значений технологических переменных сервер IIS получает запрос на посылку клиенту обновленной HTML-страницы, сформированной на базе того же шаблона. В файле-шаблоне IIS производит поиск тегов WC@ и вызывает для каждого найденного тега специальную процедуру ProcessTag. Шаблону Tmpl1 соответствует процедура Tmpl1_ProcessTag (см. фрагмент VB-кода 2 на рис.4). В этой процедуре сервер IIS динамически создает новое HTML-содержание для данного тега WC@ и сохраняет его в строковой переменной (в приведенном примере в переменной html). Рис.4 Фрагмент 2 HTML-кода Доступ к необходимой технологической информации WebOPCClient осуществляет через OPC-сервер, соответствующий используемому оборудованию автоматизации. После установления связи с OPC-сервером веб-приложение создает группу переменных, содержащую необходимые элементы данных OPC, и выполняет в зависимости от запроса клиента чтение или запись значений переменных процесса. Благодаря поддержке распределенной компонентной модели объектов DCOM (Distributed Component Object Model), предусмотренной в OPC, веб-сервер с приложением WebOPCClient и OPC-сервер могут находиться как на одном, так и на разных компьютерах, находящихся в локальной вычислительной сети. Таким образом, функции веб-сервера может выполнять как технологический сервер, так и специально выделенный для этого компьютер. Результаты доступа к технологическим переменным оформляются IIS-приложением WebOPCClient в виде HTML-таблицы и затем отправляются клиенту в составе обновленной веб-страницы. Демонстрационная версия приложения WebOPCClient доступна для загрузки по адресу: http://www.mitec-buero.de. Опыт практического использования Приложения IIS особенно предпочтительны для VB-разработчиков, поскольку создавать веб-приложения они могут в привычной для них среде разработки Visual Basic. На первый взгляд, технология создания IIS-приложений кажется громоздкой и не всегда логичной, из-за того, что для решения определенной задачи имеется, как правило, не один, а, как минимум три альтернативных способа. Например, веб-страница, динамически генерируемая IIS-приложением, может быть сформирована как на основе готового HTML-шаблона, так и полностью за счет программного кода приложения. Для достижения максимально возможной прозрачности решения в приложении WebOPCClient были использованы HTML-шаблоны. Благодаря этому пользовательский интерфейс веб-приложения может быть графически оформлен любым необходимым образом (например, для адаптации веб-страниц приложения к корпоративному дизайну предприятия), логика приложения при этом затронута не будет. В ответ на запросы, направляемые IIS-приложению, веб-клиент получает от сервера HTML-страницы со статическим представлением технологической информации. По этой причине IIS-приложения могут эффективно применяться при решении только таких задач, в которых необходимость в непрерывном доступе к данным реального времени отсутствует. К таким задачам относится, например, анализ неполадок при проведении удаленного обслуживания или параметризация технологического оборудования с использованием сетевого доступа. Часть 2: Remote Scripting В методе прикладных расширений веб-сервера (IIS-приложений), описанном в части 1, при каждом требовании клиента выполнить чтение или запись значений технологических переменных происходит новая загрузка актуализированной HTML-страницы. Чтобы избежать повторной загрузки, нежелательной хотя бы по той причине, что на загрузку графических файлов иногда тратится слишком много времени, необходим механизм, который по требованию клиента целенаправленно изменял бы только некоторые элементы HTML-страницы. Таким механизмом является Remote Scripting (RS) фирмы Microsoft. Принцип работы Remote Scripting Механизм Remote Scripting базируется на технологии ASP (Active Server Pages) и использует как клиентские, так и серверные сценарии. С помощью Remote Scripting на стороне клиента могут удаленно вызываться функции, реализованные в сценарии ASP-страницы, хранящейся на веб-сервере. Значения, возвращаемые этими функциями, могут быть получены и использованы в клиентском сценарии на языке JavaScript (или JScript по версии Microsoft) без перезагрузки веб-страницы. Механизм Remote Scripting использует для этого три компонента, представленные тремя различными файлами: RSPROXY.class; RS.htm; RS.asp. Основным компонентом технологии Remote Scripting является Java-апплет RSPROXY.class, обеспечивающий взаимодействие клиентского и серверного сценариев. Ни пользователь, ни программист с этим апплетом непосредственно не работают. Вместо этого для инициализации RS, исполнения удаленных методов, проверки состояния вызова и получения возвращаемых значений в клиентских сценариях используются функции, реализованные на языке JavaScript в файле RS.htm, которые и осуществляют доступ к соответствующим методам апплета. Таким образом, HTML-страница, в которой должен быть осуществлен удаленный вызов сценариев, должна включать файл RS.htm, а также вызов функции RSEnableRemoteScripting, назначением которой является загрузка и инициализация апплета RSPROXY (см. фрагмент 1 клиентского сценария на рис.7). Рис. 8 фрагмент 1 серверного сценария На рис.6 показаны потоки информации при обмене данными между клиентом и сервером при использовании Remote Scripting. Рис. 6. Потоки передаваемых данных между веб-браузером и сервером при использовании Remote Scripting Через сценарий в RS.htm происходит обращение к методам апплета RSPROXY, который обеспечивает доступ к функциям пользовательского сценария ASP-файла, находящегося на сервере. С помощью директивы INCLUDE к этому файлу подключается серверный компонент технологии Remote Scripting, файл RS.asp (см. фрагмент 1 серверного сценария на рис.8). Позднее он будет использован для вызова необходимых функций серверного сценария. Вызов метода RSDispatch необходим для поиска в сценарии нужной клиенту функции или процедуры. Далее в пользовательском ASP-файле необходимо реализовать функции и процедуры, предназначенные для удаленного вызова, а также объявить их общедоступными, чтобы механизм Remote Scripting мог их использовать в качестве серверных методов (см. фрагмент 2 серверного сценария на рис.9). Рис.9 Фрагмент 2 серверного сценария Удаленный вызов функций и процедур, реализованных на веб-сервере, теперь может быть осуществлен в прикладном клиентском сценарии на языке JavaScript (см. фрагмент 2 клиентского сценария на рис. 10). После выполнения нужной пользователю функции серверная часть веб-приложения отправляет результаты обратно апплету, находящемуся у клиента. При этом клиентский сценарий работает с возвращаемыми значениями, полученными от сервера, так же, как с результатами локальных вызовов функций. Таким образом, Remote Scripting обеспечивает прозрачность доступа к серверным методам. Рис.10 Фрагмент 2 клиентского сценария Для удаленного вызова серверных методов используется функция RSExecute, также относящаяся к механизму Remote Scripting. В качестве параметров она ожидает относительный унифицированный указатель ресурса (URL Uniform Resource Locator) ASP-файла, содержащего пользовательский серверный сценарий, а также имя и параметры удаленно вызываемой функции или процедуры. В приведенном примере с помощью RSExecute вызывается функция myFunction, не имеющая параметров и реализованная в файле remote.asp, который находится в той же директории сервера, что и файл RS.asp. Вызов функции myFunction возвращает вместо нормального результата выполнения функции объект, инкапсулирующий результаты вызова (со в приведенном примере). В свойствах этого объекта содержится возвращаемое функцией значение (свойство return_value), а также информация о состоянии выполнения удаленного метода. Обработка значения, полученного с сервера, происходит в функции клиентского сценария myCallback. В примере удаленный вызов сценария происходит синхронно, т.е. сценарий, вызывающий удаленную процедуру, ожидает завершения ее выполнения, прежде чем продолжить свою работу. Однако технология Remote Scripting позволяет осуществлять и асинхронные вызовы. Для этого в параметрах функции RSExecute необходимо передать также ссылку на функцию, которая должна быть вызвана по завершении выполнения удаленного метода (см. фрагмент 3 клиентского сценария на рис.11). Рис.11 Фрагмент 3 клиентского сценария При асинхронном вызове функции myFunction с приведенными в примере параметрами, вызов функции обработки возвращаемого значения myCallback будет инициирован механизмом Remote Scripting непосредственно после получения сообщения о завершении выполнения функции на сервере. Технология Remote Scripting позволяет осуществить и передачу параметров для удаленно вызываемых методов, как это, например, необходимо в случае присвоения технологическим переменным новых значений. Более подробную информацию об этом, а также о технологии Remote Scripting вообще можно найти в источниках [4, 5]. Механизм Remote Scripting применим совместно с веб-сервером IIS 4.0 фирмы Microsoft (IIS Internet Information Server) и его более поздними версиями, а также со стандартными браузерами, такими как Internet Explorer или Netscape версии 4.х и выше. Актуальная версия программных компонентов Remote Scripting может быть загружена с веб-сайта компании Microsoft [6]. Преимущества и недостатки Основными преимуществами Remote Scripting для разработчика являются прозрачность, простота и гибкость решений для веб-базированного доступа к технологической информации. Для написания таких веб-приложений не нужны комплексные среды разработки, требующие больших ресурсов и сложные для освоения. Необходимые сценарии в HTML- и ASP-страницах могут создаваться и дорабатываться с помощью любого текстового редактора. Особенные преимущества проявляются при использовании Remote Scripting в веб-приложениях, которые осуществляют доступ к технологическим данным, предоставляемым OPC-сервером. Для реализации связи и обмена данными при таком доступе в серверном сценарии необходимы лишь несколько строчек кода на языке VBScript. К дальнейшим преимуществам также относятся: стабильность и надежность; простота установки (на веб-сервере необходимо лишь разместить каталог _ScriptLibrary); использование JavaScript или VBScript на выбор. Хотя Remote Scripting и осуществляет динамическое встраивание данных в веб-страницу, находящуюся у клиента, для этого так же, как и в IIS-приложениях, необходим предварительный запрос клиента. Механизм Remote Scripting не позволяет событийно-управляемо оповещать клиента о случайном изменении значений технологических переменных на сервере. К недостаткам технологии относится также и то, что на этапе создания веб-приложений на ее основе разработчик имеет весьма скудные возможности отладки взаимодействия клиентского и серверного сценариев. Кроме того, использование в Remote Scripting технологии ASP-страниц фирмы Microsoft делает этот механизм применимым только совместно с веб-сервером этой же фирмы (IIS). Пример применения: виртуальный практикум на базе INTERBUS С февраля 2001 года в высшей технической школе города Дюссельдорфа действует виртуальный лабораторный практикум для изучения основ технологии INTERBUS, в котором используется реальная учебная установка (Telepraktikum mit INTERBUS). Веб-базированный доступ к технологической информации установки реализован с помощью механизма Remote Scripting. Учебная установка представляет собой станцию автоматизированного контроля размеров и материала заготовок. В лабораторном практикуме в качестве учебного задания предлагается выполнить через Интернет анализ установки и оформление соответствующего отчета в электронной форме. Для выполнения каждого из заданий учащийся управляет установкой через Интернет, наблюдает за действующими узлами с помощью позиционируемой видеокамеры и одновременно имеет возможность мониторинга всей установки, благодаря визуализации ее входных и выходных сигналов, расположенной на веб-странице. В качестве сервера в практикуме использована двухпроцессорная система с платформой Windows NT 4.0. Управляющая программа установки также исполняется на этом компьютере (рис.12). Рис. 12. Веб-базированный доступ к технологнческим данным в виртуальном лабораторном практикуме для изучения основ технологии INTERBUS Веб-базированный доступ к технологической информации установки осуществляется с помощью Remote Scripting и OPC-сервера для полевой шины INTERBUS. Каждой HTML-странице веб-сайта практикума (см. рис. 5), с которой осуществляется доступ к технологическим данным с целью чтения или записи значений переменных процесса, на сервере соответствует свой ASP-файл со сценарием, реализующим необходимые операции. Рис. 5. Виртуальный лабораторный практикум, построенный на основе Remote Scripting. Один из фреймов представленной веб-страницы использует Remote Scripting для доступа к технологическим данным реальной лабораторной установки Таким образом, в веб-браузере клиента реализуются следующие пользовательские функции: управление установкой с помощью соответствующих кнопок пользовательского интерфейса; отображение входных и выходных сигналов с помощью графически изображенных светодиодов; визуализация установки с помощью трехмерной графической VRML-модели установки (VRML Virtual Reality Modeling Language). Доступ к установке может быть осуществлен в любое время суток по адресу http://www.telepraktikum.de. Выполнению практикума предшествует регистрация пользователя. Опыт практического использования Более чем однолетний опыт эксплуатации описанного лабораторного практикума позволяет подвести следующие итоги: Механизм Remote Scripting работает надежно и стабильно даже при низких скоростях передачи данных в сети Интернет; Используемый в практикуме сервер должен обладать достаточной вычислительной мощностью, поскольку ASP и Remote Scripting относятся к относительно ресурсоемким технологиям построения веб-приложений; При выходе в Интернет со скоростью передачи данных порядка 10 Кбит/с обновление технологических данных на веб-странице, находящейся на стороне клиента, после отправки соответствующего запроса осуществляется за 1-2 с; В случае Remote Scripting отпадают часто возникающие при использовании веб-приложений проблемы, связанные с определенными ограничениями использования Интернета в корпоративных сетях из соображений безопасности (например, разрешены для обмена только TCP-порты со стандартными номерами, запрещено использование ActiveX-объектов и т.п.). Для работы с веб-приложением, использующим RS, необходим лишь стандартный браузер с поддержкой Java и JavaScript. При этом обмен данными осуществляется на сервере через стандартный TCP-порт 80, соответствующий протоколу HTTP. В общем и целом, механизм Remote Scripting является хорошим средством для быстрой и гибкой реализации веб-базированного доступа к технологической информации, динамического с точки зрения обработки запросов клиента, но все же не позволяющего осуществить событийно-управляемое оповещение клиента. Часть 3: Применение Java Когда необходимо организовать событийно-управляемую передачу технологических данных от веб-сервера к клиенту (например, для динамического отображения на стороне веб-клиента изменяющихся значений технологических переменных), применяются технологии, позволяющие реализовать непрерывный поток данных между сервером и клиентом. В существующих сегодня программных решениях для этой цели используются компоненты ActiveX или апплеты на языке Java, однако лишь при использовании Java-базированных решений достигается платформенная независимость и высокая степень безопасности. Одно из решений, реализующих динамический веб-базированный доступ к технологической информации, рассматривается в данной статье. Создание веб-приложения на языке Java Существует несколько технологий создания веб-базированных приложений на языке Java. К основным технологиям относятся Java-апплеты, сервлеты (Servlets) и серверные страницы на языке Java (JSP Java Server Pages). Сервлеты и JSP, которые являются серверными технологиями программирования, высылают в качестве ответа на клиентский запрос веб-страницу со статическим содержанием. Динамическое представление информации на стороне клиента реализуется с помощью Java-апплетов, т.е. приложений на языке Java, которые могут выполняться в среде веб-браузера. Для реализации непрерывного потока данных между сервером и клиентом Java-апплет, встроенный в веб-страницу, после загрузки в браузер устанавливает TCP-соединение с серверным Java-приложением, имеющим доступ к актуальным технологическим данным, и затем динамически отображает получаемую от него информацию, используя свой графический интерфейс. При этом веб-клиенту не нужно загружать новых веб-страниц. Такое использование программных объектов на языке Java можно рассматривать как комбинацию веб-приложения и распределенного приложения. В простейшем случае обмен данными между частями распределенного приложения может быть реализован с помощью программного интерфейса сокетов (рис. 14). Обмен данными между Java-апплетом, загруженным и выполняемым браузером, и соответствующей серверной частью распределенного приложения на языке Java (которая будет называться далее Java-сервером) осуществляется при этом через TCP-порт с нестандартным номером, не занятый другими приложениями [7]. Технология программного интерфейса сокетов отличается простотой, универсальностью и легкостью в применении. Альтернативой программному интерфейсу сокетов в языке Java является технология удаленного вызова методов RMI (Remote Method Invocation). Этот механизм предлагается разработчикам, начиная с JDK 1.1 (JDK Java Development Kit), позволяя делать методы локальных программных объектов доступными для удаленных приложений. Преимущество RMI состоит в том, что написание программных модулей, участвующих в обмене данными, происходит на более высоком уровне абстракции, т.е. разработчику не нужно заботиться о том, как именно реализована транспортировка данных между частями распределенного приложения. Методы, реализованные на удаленной машине, этот механизм вызывает в своей программе точно также как и локальные [8]. Как и в распределенных приложениях, использующих сокеты, обмен данными на основе RMI также осуществляется через TCP-порт с нестандартным номером. Только в этом случае номер используемого порта каждый раз случайно выбирается RMI-реестром из числа незанятых и поэтому разработчику заранее неизвестен. По этой причине реализация обмена данными с использованием RMI через сетевой экран крайне проблематична. Кроме того, к недостаткам RMI относится и не всегда одинаковая стабильность RMI-соединения. Непосредственный доступ к переменным процесса на технологическом сервере может быть осуществлен либо через программный интерфейс коммуникационного драйвера, специфичного для конкретного оборудования автоматизации, либо посредством соединения с OPC-сервером. Подобные программные модули, как правило, обладают программным интерфейсом для приложений на языке С. Чтобы иметь возможность использовать такой программный интерфейс в приложении на языке Java, можно пойти одним из двух путей: Сделать программный модуль на языке С, осуществляющий работу с этим интерфейсом, доступным в сети как CORBA-объект; Работать с интерфейсом, поддерживающим С, непосредственно, используя Java Native Interface (JNI). Общая архитектура брокера объектных запросов CORBA (Common Object Request Broker Architecture) позволяет осуществить связь между объектами, даже созданными на различных языках программирования. Решение с использованием CORBA является универсальным, но в то же время и достаточно сложным. В распределенном приложении, полностью написанном на языке Java, использование CORBA не приносит никаких дополнительных выгод, поэтому чаще предпочтение отдается технологии JNI. В этом случае реализация необходимых Java-приложению методов для работы с программным интерфейсом, поддерживающим язык С, осуществляется на языке C или C++ [3]. Таким способом может быть также реализован доступ к технологическим данным через OPC-интерфейс. Преимущества и недостатки Язык программирования Java специально создавался для разработки сетевых приложений и обладает всеми средствами для реализации динамического обмена данными между компонентами распределенного приложения. Поэтому Java наилучшим образом подходит для разработки программного обеспечения для удаленной диагностики, мониторинга и управления. Для работы с программными решениями на языке Java, осуществляющими веб-базированный доступ к технологическим данным, на компьютере клиента из специального программного обеспечения должен быть установлен лишь стандартный веб-браузер с поддержкой Java. Кроме того, Java-базированные решения обладают следующими преимуществами. Java является сравнительно простым языком программирования. Быстрому созданию надежного программного кода способствует автоматическое управление памятью, отсутствие многократного наследования и указателей. Байтовый код Java в большой степени независим от операционной системы или процессора. Благодаря этому приложения на языке Java легко портируются на другие платформы. С помощью технологий JNI и CORBA может быть реализована связь с объектами, созданными на других языках программирования. В сравнении с другими программными решениями (например, с Remote Scripting) веб-базированное приложение на языке Java, использующее для обмена данными сокеты, позволяет достичь меньшего времени реакции при оповещении клиента. Недостатком этого способа обмена является, однако, использование TCP-порта с нестандартным номером, который при доступе веб-клиента, находящегося за пределами защищенной сети, к данным технологического сервера, лежащего в ее пределах, должен быть сначала разрешен системным администратором для обмена. Другой недостаток Java заключается в том, что для эффективного выполнения Java-приложений, система пользователя должна обладать достаточно мощными вычислительными ресурсами, особенно при работе с приложениями, содержащими сложные пользовательские интерфейсы. Пример приложения: Web Access Kit for Process Data На базе обобщенной схемы распределенного приложения, представленной на рис. 14, было разработано программное обеспечение Web Access Kit (WAK) V1.0, предназначенное для веб-базированного мониторинга и управления. ПО WAK состоит в общей сложности из четырех гибко применяемых Java-апплетов (WAK-апплетов) и серверной части приложения, WAK-сервера. Апплеты служат для чтения и записи значений цифровых и аналоговых технологических переменных. На рис. 15 изображен графический интерфейс апплета для чтения и отображения значений аналоговых технологических переменных. Рис. 14. Доступ к данным процесса технологической установки с помощью веб-базированного распределенного приложения на языке Java Обмен данными между WAK-сервером и каждым из апплетов реализован на основе TCP-соединения с помощью программного интерфейса сокетов. Доступ к данным процесса технологической установки WAK-сервер осуществляет через ОРС-интерфейс. Рис. 15. WAK-апплет для чтения значений аналоговых технологических переменных, используемый в данном случае для мониторинга параметров ветроэнергетической установки Апплеты WAK могут быть гибко и просто встроены пользователем в собственные веб-страницы с помощью обыкновенного HTML-редактора. На одной веб-странице может располагаться сразу несколько WAK-апплетов. Пример на рис. 13 показывает использование WAK в экспериментальном приложении Веб-программируемое устройство управления WPS (WPS Web-programmierbare Steuerung). Модули ввода/вывода учебной сверлильной установки с поворотным столом соединены сетью Ethernet с сервером технологических данных. Таким образом, технологический сервер имеет прямой доступ к сигналам сверлильной установки, который и использует серверная часть приложения WAK. Управление установкой осуществляется на стороне веб-клиента посредством управляющей программы, которая составляется пользователем на веб-странице с помощью языка функциональных блоков (FBD Functional Block Diagram) и выполняется в среде браузера. Рис. 13. Пример применения распределенного приложения Web Access Kit для веб-базированного управления учебной сверлильной установкой с поворотным столом Распределенное приложение Web Access Kit разрешает одновременный доступ к технологической информации сразу нескольких веб-клиентов, число которых программно не ограничено. Таким образом, осуществлять мониторинг и управление технологическим процессом одновременно может сразу несколько операторских станций. Список технологических переменных, подлежащих мониторингу и управлению, а также настройки визуального представления данных на веб-странице цвета, тип и размер шрифта задаются в списке параметров каждого из апплетов. Список параметров апплета, изображенного на рис. 15, представлен во фрагменте HTML-кода 1 (рис.16). Рис.16 Список параметров апплета, изображенного на рис.15 Апплеты WAK могут быть использованы также в качестве агентов-посредников proxy, предоставляющих другим программным объектам веб-страницы интерфейс к технологической информации удаленного устройства автоматизации. В этом случае обработка технологических данных, получаемых через прикладной программный интерфейс (API Application Programming Interface) прокси-апплета, может быть осуществлена с помощью сценариев на языках, соответствующих стандарту ECMAScript (JavaScript, JScript и т.п.). Программный интерфейс апплетов WAK содержит методы для чтения или записи значений технологических переменных. Апплеты, предназначенные для чтения значений цифровых и аналоговых переменных, содержат, например общедоступный метод readItem() (см. фрагмент кода 2 на рис. 17). Рис. 17 Фрагмент кода апплета, предназначенного для чтения значений цифровых и аналоговых переменных В этом примере в функции read() JavaScript-сценария происходит считывание актуального значения переменной процесса, представляемой апплетом с именем ARead_01 и имеющей порядковый номер index в рамках этого апплета. Считанное значение отображается в текстовом поле HTML-формы, расположенной на данной веб-странице. Доступ серверной части Java-базированного распределенного приложения WAK к данным OPC-интерфейса осуществляется с помощью специальной библиотеки J2OPC (Java to OPC), которая является связующим звеном между Java-приложениями и OPC. Использование библиотеки J2OPC, созданной на основе технологии JNI, в приложениях на языке Java позволяет программисту работать с OPC-интерфейсом с таким же удобством, как и в проектах на Visual Basic. В отличие от известных комплексных программных продуктов для веб-базированного удаленного доступа к технологической информации распределенное приложение WAK позволяет создавать гибкие, компактные и недорогие программные решения. Демонстрационная версия приложения Web Access Kit доступна для загрузки по адресу: http://www.telefabrik.de. Опыт практического использования При использовании описанного выше Java-базированного решения, реализованного в распределенном приложении WAK, были сделаны следующие наблюдения. Распределенные приложения на языке Java, осуществляющие динамический обмен данными, могут эффективно применяться в некритичных по времени задачах автоматизации уже при скорости передачи данных в сети Интернет порядка 10 Кбит/с. Сервер, выполняющий приложение на языке Java, должен обладать достаточной вычислительной мощностью. В пробном применении WAK для управления учебной сверлильной установкой с поворотным столом через Интернет, проиллюстрированном на рис. 13, была достигнута частота обновления технологических данных в экранной форме на стороне веб-клиента порядка 100 мс. Обмен данными в распределенном приложении, построенном на использовании программного интерфейса сокетов, осуществляется через TCP-порт с нестандартным номером, назначаемым пользователем. При доступе к данным защищенной сети извне этот номер порта должен быть разрешен для обмена на соответствующем сетевом экране. Веб-базированный доступ к технологической информации с помощью Java является, несомненно, одним из наиболее эффективных решений. Java-базированные распределенные приложения для мониторинга и управления обладают малым временем реакции, позволяют реализовать динамическое отображение технологической информации на экране операторской станции и являются платформенно-независимыми. С помощью подобных решений в пределах корпоративной сети интранет или через Интернет может быть осуществлен удаленный анализ критичных по времени данных или удаленное управление установками и оборудованием, при котором должно быть обеспечено заданное, сравнительно малое время реакции. Заключение Все три решения находятся сегодня в практическом применении. Решение, использующее технологию Remote Scripting (часть 2), можно протестировать через Интернет. Решения, описанные в частях 2 и 3, могут быть получены в виде демонстрационных или полных версий для ознакомления или использования. Литература 1. Kofler, M. Visual Basic 6. Programmiertechniken, Datenbanken, Internet. Bonn: Addison-Wesley-Longman Verlag, 1998. 2. Колесов А., Павлова О. Visual Basic 6.0 упрощает разработку для Web. Часть 2: Создание IIS(WebClass)-приложений// КомпьютерПресс. 1999. 5. С.108-112. 3. OPC Data Access Automation Interface Specification, Version 2.02. Instead of version 2.01; released 03.02.99. OPC Foundation, 1999. 4. Койнов Е. Remote Scripting удаленное исполнение скрипта. Сервер Центра Информационных Технологий , 1998. 5. Using Remote Scripting. Documentation about Microsoft Remote Scripting. MSDN Library. Microsoft Corp. 6. Download of Remote Scripting 1.0b. Updated 09.10.2001. MSDN Downloads. Microsoft Corp. 7. Ноутон П., Шилдт Г. Java 2 / Пер. с англ. СПб.: БХВ Санкт-Петербург, 2000. 8. Java Remote Method Invocation Specification, Version 1.3. Sun Microsystems, Inc., 1999. 9. Java Native Interface Specification, Version 1.1. Sun Microsystems, Inc., 1997.
Будущее энергетического сектора. 2. Высокие опоры со спускными. Концепция развития работ поэнергосбережению путем привлечения к учетуэнергоресурсов специализированныхрасчетно. Научные основы проектированияэнергоэффективных зданий. Главная -> Экология 
|