CC BY
133
СПИСОК ЛИТЕРАТУРЫ
1. Коровин Г.Н., Андреев Н.А. Авиационная охрана лесов. - М.: Агропромиздат, 1988. - 220 с.
2. Сонькин М.А., Печерская Е.И., Семыкин С.В. и др. Информационно-телекоммуникационная система мониторинга лесопожарной обстановки субъекта РФ (ИТС «Ясень») // Федеральная служба по интеллектуальной собственности, патентам и товарным знакам. Свидетельство о государственной регистрации программы для ЭВМ № 2011614800. - 2011.
3. Беляев А.И., Коровин Г.Н., Лупян Е.А. Состояние и перспективы развития Российской системы дистанционного мониторинга лесных пожаров // Современные проблемы дистанцион-
ного зондирования Земли из космоса: Труды III открытой Все-рос. конф. - М.: ИКИ РАН, 2006. - С. 341-350.
4. Глобальная спутниковая радионавигационная система ГЛО-НАСС / под ред. В.Н. Харисова, А.И. Петрова, В.А. Болдина. -М.: ИПРЖР, 1999. - 400 с.
5. Сонькин М.А., Печерская Е.И., Комлев А.Н. и др. Программное обеспечение бортового комплекса подвижного объекта для мониторинга лесных пожаров // Федеральная служба по интеллектуальной собственности, патентам и товарным знакам. Свидетельство о государственной регистрации программы для ЭВМ № 2011614798. - 2011.
Поступила 26.10.2011 г.
УДК 004.62
ЗАДАЧА СБОРА И ПЕРЕДАЧИ ТЕХНОЛОГИЧЕСКОЙ ИНФОРМАЦИИ РАСПРЕДЕЛЕННОГО
ПРОМЫШЛЕННОГО ПРЕДПРИЯТИЯ
В.В. Вейбер, А.В. Кудинов, Н.Г. Марков*
Томский политехнический университет *ОАО «ВостокГазпром», г. Томск E-mail: [email protected]
Рассмотрены задачи сбора технологической информации промышленного предприятия и ее передачи на уровень управления и принятия решений. Проанализированы проблемы использования стандарта ОРСдля решения указанных задач. Предложена оригинальная архитектура и функции разработанного программного пакета для сбора первичных технологических данных на основе принципов SOA, приведены результаты исследования эффективности предложенных решений по сравнению с аналогами.
Ключевые слова:
Интеграция производственных данных, стандарт OPC, веб-сервис.
Key words:
Manufacturing data integration, OPC standard, Web-service.
Актуальной задачей автоматизации промышленных предприятий является создание единого информационного пространства для объективной и оперативной оценки текущей ситуации на производстве, быстрого принятия оптимальных управленческих решений, ликвидации информационных и организационных барьеров между управленческим и технологическим уровнями. В свою очередь, организация единого информационного пространства невозможна без создания надежного механизма сбора первичной технологической информации и ее передачи на вышестоящие уровни управления и принятия решений. Задача сбора детальных технологических данных и оперативного управления производством на их основе традиционно решается с применением разного рода автоматизированных систем управления технологическими процессами (АСУТП).
Это не означает, что потребность в первичных технологических данных испытывают только специалисты, находящиеся на уровне оперативного управления. Как сами детальные данные, так производные от них (например, рассчитанные на их
основе агрегатные показатели), являются необходимой и существенной частью информационного обеспечения процессов управления производством как на среднем уровне (по модели С1М), так и на уровне стратегического управления предприятием. Автоматизация процессов управления на этих уровнях ведется при помощи систем классов МЕ^, ЕАМ, ЕЯР, В1 и других. Таким образом, построение единого информационного пространства промышленного предприятия предполагает, в том числе, организацию оперативного и надежного доступа к технологическим данным, контролируемым при помощи АСУТП, со стороны внешних информационных систем.
Решение этой, интеграционной по сути, задачи сопряжено с целым рядом как технических, так и организационных проблем, анализу которых, а также поиску возможных вариантов их преодоления посвящена эта работа.
Нетривиальность задачи вертикальной интеграции по данным информационных систем промышленного предприятия и АСУТП обусловлена следующими факторами:
• большой объем первичных данных, и, как следствие, проблемы с производительным доступом к ним, каналами связи и системами хранения, сложности с администрированием интеграционных процессов и т. д.;
• разная (и, зачастую, избыточная) гранулярность первичных данных;
• необходимость поддержки большого числа промышленных протоколов для доступа к данным АСУТП различных фирм-производителей;
• необходимость обеспечения информационной безопасности при обмене данными на стыке офисной и технологической сетей.
Необходимо отметить, что в подавляющем
большинстве случаев требуется вертикальная однонаправленная интеграция, где АСУТП является источником, а внешняя информационная система -приемником данных. Редким исключением является случай интеграции АСУТП с лабораторными информационными системами, когда в АСУТП передаются данные химического анализа продукции, выступающие в качестве параметров-регуляторов технологического процесса, но, по мнению многих исследователей, в данном случае, все же, реализуется горизонтальная интеграция.
Несмотря на то, что существуют решения для вертикальной интеграции, основанные на поддержке большого числа wartve-протоколов (например, SAP xMII [1]), большинство идет по пути унификации доступа к технологическим данным, в которой стандартом де-факто является OPC (OLE for Process Control) [2, 3].
Использование стандарта OPC
OPC - является технологией, обеспечивающей универсальный механизм обмена данными, который устанавливает требования к классам объектов доступа к данным и их специализированным интерфейсам для использования разработчиками клиентских и серверных приложений. На сегодня технология OPC своего рода стандарт в области построения систем автоматизации. Создание и поддержку спецификаций OPC координирует международная некоммерческая организация OPC Foundation, созданная в 1994 г. ведущими производителями средств промышленной автоматизации [4]. Как и всякий единый открытый стандарт, OPC позволяет сделать систему модульной и, следовательно, масштабируемой и легко модернизируемой. OPC состоит из ряда спецификаций. Основная и наиболее широко используемая спецификация -OPC DA (OPC Data Access), которая описывает набор функций обмена данными в реальном времени с различными устройствами. В то время как OPC DA предоставляет доступ к данным изменяющимся в реальном времени, OPC HDA (Historical Data Access) предоставляет доступ к уже сохраненным, историческим данным.
Существенной проблемой стандарта ОРС в целом долгое время оставалось использование в качестве основы протокола DCOM, что, очевидно,
затрудняло создание кросс-платформенных решений и не соответствовало современным требованиям в области информационной безопасности [5]. Первым ответом на эти современные вызовы стало проявление спецификации OPC XML Data Access (XML DA) - она является частью стратегии развития совместимости систем, созданных на базе различных платформ, а также всеобщей поддержки Web-сервисов [6]. Применение XML DA позволяет создание шлюзов для передачи информации через Internet между оборудованием, поддерживающим OPC-технологию, обеспечивая использование OPC-протокола обмена данными независимо от операционных систем и сетевых технологий, применяемых в конкретных системах автоматизации.
Несмотря на объявленные возможности, создатели OPC XML DA так и не смогли полностью уйти от использования DCOM, поэтому существенная часть проблем стандарта осталось характерной и для этой спецификации. В 2004 г. вышла статья технического директора OPC Foundation Джима Ласа (Jim Luth) «Unified architecture - The future of OPC», в которой впервые была представлена вновь разрабатывающаяся спецификация ОРС Unified Architecture (UA). Ее отличительными особенностями, кроме «истинных» кросс-платформенности и безопасности, стали поддержка резервирования, возможность распознавания соединения в обоих направлениях (как клиентом, так и сервером), а также буферизация и подтверждение передачи данных [7]. Разработка нового стандарта и прототипирование заняли еще 4 года. Таким образом, с 2008 г. производители аппаратного и программного обеспечения имеют возможность использовать очевидные преимущества спецификации ОРС UA в своих продуктах.
Программное обеспечение для доступа к данным АСУТП по протоколу ОРС реализуется в клиент-серверной архитектуре. Причем большинство известных компаний-разработчиков АСУТП чаще всего предлагает в составе ее программных средств оригинальный ОРС-сервер того же производителя, а использование сторонних продуктов не является типичным [8]. В то же время хорошо развит рынок программных продуктов, реализующих клиентскую сторону стандарта ОРС (ОРС-клиентов). Вследствие поддержки в более поздних спецификациях ОРС обратной совместимости, возможно использование ОРС-клиента, реализующего, например, спецификацию ОРС UA, для доступа к данным через ОРС-сервер, реализующий спецификацию ОРС DA. Однако все преимущества ОРС UA в этом случае остаются невостребованными. Таким образом, для эффективного и безопасного обмена данными по протоколу ОРС необходима поддержка современных его спецификаций производителями как ОРС-клиентов, так и ОРС-серве-ров.
Однако с реализацией современных спецификаций ОРС производители не спешат. По данным
OPC Foundation на рынке представлено более 100 сертифицированных ОРС-серверов с поддержкой ОРС DA (по данным на сентябрь 2011г.), но только 21 из них поддерживает ОРС XML DA и лишь один - ОРС UA (Siemens SIMATIC NET OPC Server). Из порядка 50 полностью сертифицированных OPC-клиентов 20 поддерживают спецификацию XML DA, в то время как клиенты, реализующие спецификацию ОРС UA, находятся только в стадии тестирования. Таким образом, в ближайшем будущем решения большинства проблем использования стандарта ОРС в рамках рассматриваемой задачи можно ожидать только для промышленных предприятий, внедряющих новейшие АСУТП от ведущих фирм-производителей. В тоже время для компаний, обремененных наследием более старых средств автоматизации с поддержкой только ОРС DA и не готовых к масштабной технической модернизации, требуется компромиссное, с точки зрения цена/качество, решение.
Представим ситуацию, типичную для большинства промышленных предприятий с распределенной структурой, таких как, например, нефтегазодобывающие компании. Главный офис компании и добычные промыслы территориально удалены друг от друга (рис. 1). В соответствии со стандартами безопасности локальные вычислительные сети (ЛВС) компании разделены на, так называемые, технологические и офисные. Технологическая сеть объединяет датчики, контроллеры и другое оборудование, обеспечивающее работу АСУТП, а также рабочие станции, при помощи которых осуществляется управление процессом. Офисная сеть обеспечивает доступ к данным ИС уровня всего предприятия, систем класса MES, ERP и т. д. В свою очередь, доступ к технологическим данным со стороны этих систем осуществляется через обращение по спецификации OPC DA к OPC-серверу, расположенному в пределах технологической сети. Так как эта спецификация построена на базе DCOM, современные межсетевые экраны не позволяют эффективно разделять его пакеты, что делает ОРС-сервер потенциально уязвимым для злоумышленника - такой способ передачи технологических данных не соответствует современному уровню безопасности промышленного предприятия [5].
Особого внимания требует стыковка технологической и офисной сетей. Дело в том, что шлюзом
является, как правило, интеграционная рабочая станция с двумя сетевыми картами, включенная, таким образом, в обе сети. ОРС-клиент внешней ИС должен иметь доступ как к ОРС-серверу, так и к ИС, для которой он производит сбор технологических данных, при этом необходимо избежать использования технологии DCOM для обращения в технологическую сеть - пользуясь только спецификацией OPC DA это невозможно.
Решение проблемы безопасности предлагают как спецификация OPC XML DA, так и OPC UA. Причем, реализация доступа по спецификации XML DA (текстовый протокол SOAP) является более медленной по сравнению с OPC DA (RPC).
Учитывая естественную в реальных производственных условиях удаленность объектов технологической сети, и, соответственно, возможность перебоев в каналах связи, требуется наличие механизма защиты технологических данных от потерь. Спецификация OPC DA не обеспечивает такого механизма. Для этих целей разработана спецификация OPC HDA, но она не поддерживается практически ни одним из OPC-серверов для широко распространенных АСУТП и SCADA-систем. Кроме того, как упоминалось выше, ее не поддерживают представленные на рынке OPC-клиенты, реализующие XML DA.
Для обеспечения сбора и передачи больших объемов данных, с учетом ширины канала передачи, необходима высокая производительность. Авторами была исследована спецификация OPC XML DA и представленные на рынке OPC-клиенты, реализующие эту спецификацию, с точки зрения производительности. Был сделан вывод, что организация передачи данных в соответствии с XML DA не является оптимальной.
Из всего вышесказанного следует, что современное средство сбора и передачи технологической информации должно обладать тремя качествами: надежность, безопасность и производительность. Несмотря на обилие OPC-продуктов, представленных на рынке, нет программного продукта для решения выше поставленной задачи в полном объеме.
Предлагаемое решение
Разработанный OPC-клиент использует сервисно-ориентированную архитектуру (Services-Orien-
Рис. 1. Распределенное промышленное предприятие
ted Architecture, SOA) [9], элементом которой являются веб-сервисы [10]. При использовании этой архитектуры все предъявляемые требования к безопасности передачи технологической информации на промышленном предприятии могут быть выполнены. Протоколом обмена данными при использовании веб-сервисов является SOAP (Simple Object Access Protocol), реализованный на базе XML, поэтому есть возможность фильтрации всего трафика OPC-клиента межсетевым экраном по заданной XML-схеме. Принимающая сторона (вебсервис), находящаяся в офисной сети, является «пассивной», все действия инициируются передающей частью OPC-клиента, расположенной в технологической сети.
В OPC-клиенте реализована буферизация данных с целью исключения потери при отсутствии связи между технологической и офисной сетями (аналог OPC HDA). Для этого организован файловый буфер, накапливающий технологические данные до восстановления соединения.
Для повышения производительности разрабатываемого OPC-клиента был использован ряд приемов.
Сокращение тегов в SOAP пакетах. Реализована не XML DA спецификация, а разработана структура пакетов с короткими именами тегов, следовательно XML-пакеты упрощены, объем трафика значительно уменьшен.
Группировка значений параметров в SOAP-пакете по времени. Это позволяет уменьшить размеры передаваемых пакетов, т. к. при съеме значений параметров по подписке параметр Timestamp (время снятия значения) одинаков.
Оптимизация размеров передаваемых пакетов. Разработанный OPC-клиент позволяет подобрать оптимальное количество значений параметров в одном пакете для обеспечения наиболее высокой производительности.
Возможность агрегации данных до момента передачи их по каналу связи позволяет не передавать ненужные исходные данные адресату, а передать лишь результат агрегации: сумму, интеграл, наработку оборудования и т. п.
На рис. 2 изображена архитектурная схема разработанного OPC-клиента. Модули чтения данных, транспортировки/обработки и OPC-сервер находятся в одной технологической ЛВС, обмен данными между модулями чтения данных и OPC-сервером осуществляется по протоколу OPC DA (RPC). Веб-сервисы, выполняющие функции приемника технологической информации, и адаптеры, отвечающие за доставку данных информационным системам, находится в офисной ЛВС. Соединение технологической ЛВС и офисной осуществляется через межсетевой экран, поддерживающий фильтрацию XML-пакетов.
Основные компоненты приложения содержат модули:
• сбора данных для сбора значений параметров
с OPC-сервера и помещения их в буфер;
Рис. 2. Архитектура разработанного OPC-клиента
• транспортировки и обработки данных для передачи значений параметров, их предварительной агрегации и удаления отправленных значений из буфера;
• конфигурирования OPC-клиента для управления OPC-клиентом из офисной ЛВС (остановка/запуск модулей чтения данных, удаление/добавление параметров), конфигурирования OPC-клиента из офисной ЛВС.
Модули реализованы в виде Windows-служб, имеющих свои конфигурационные файлы и синхронизирующиеся между собой по событиям. Интерфейс консоли управления OPC-клиентом представлен на рис. 3.
Разработанный OPC-клиент позволяет в полной мере решить поставленную выше задачу надежного, безопасного и производительного сбора и передачи технологической информации.
Исследование производительности
Для того, чтобы убедиться, что разработанный OPC-клиент имеет более высокую производительность по сравнению с OPC-клиентами, реализующими спецификацию OPC XML DA, была проведена оценка производительности двух сторонних OPC-клиентов и разработанного. Для сравнения были выбраны программные продукты Softing OPC Easy Connect Suite [11] и Advosol XML-Data Access Gateway [12]. Эксперименты были проведены
Рис. 3. Интерфейс консоли управления OPC-клиентом
в единой тестовой среде на скоростях от 14,4 кбит/с до 1 Мбит/с, для ограничения пропускной способности канала использовался продукт Traffic Shaper [13]. Целью эксперимента являлось определение максимального количества значений параметров, передачу которых может обеспечить OPC-клиент за одну минуту. Ситуация, когда необходимо единовременно доставить большое количество значений параметров, является очень распространенной на производстве, т. к. большинство значений параметров снимается синхронно, т. е. в определенные моменты времени.
Результаты экспериментов представлены на рис. 4. Из графика видно, что разработанный OPC-клиент имеет значительный выигрыш в произво-
дительности по сравнению с выбранными аналогами. К примеру, при скорости канала передачи данных 1 Мбит/с разработанный OPC-клиент может доставить 8 тыс. значений параметров за 1 мин. против 4-6 тыс. значений, обеспечиваемых Easy Connect Suite и Data Access Gateway.
Внедрение
Разработка OPC-клиента проведена в рамках проекта корпоративной геоинформационной системы управления производством «Магистраль-Восток» [14]. «Магистраль-Восток» - система класса MES внедрена на нефтегазодобывающем предприятии ОАО «ВостокГазпром», г. Томск, для автоматизации деятельности большинства произ-
щ
о
Си
Н
О
2
ГС
о.
ГС
S о
І Ї гс ^ = h
X 5 х го го го сі
о
0 ш
1 §
Скоростьканала передачи данных, кбит/с
^^Разработанный OPC-KJiHeHT^^Softing OPC Easy Connect Suite^Wkdvosol Inc. XML-Data Access Gateway Рис. 4. Сравнение производительности разработанного OPC-клиента со сторонними продуктами
водственных служб предприятия. Первая версия OPC-клиента, реализующая только спецификацию OPC DA, была внедрена в 2004 г. Новая версия, реализованная с использованием технологии вебсервисов, внедрена в 2007 г., что позволило ОАО «ВостокГазпром» в 2008 г. успешно пройти аудит информационной безопасности «Газпром».
В настоящий момент разработанный OPC-клиент используется на предприятии для сбора и передачи данных, представляющих собой значения параметров технологических процессов (дебит, давление, температура и т. д.) через заданные промежутки времени. При помощи OPC-клиента получаются данные из 8 разных АСУТП (DeltaV, RS3, ROC, Siemens Simatic) трех месторождений и одного узла учета стабильного конденсата, всего порядка 6,6 тыс. параметров. Обеспечивается доставка примерно 880 тыс. значений параметров в день. Использование механизма буферизации, реализованного в OPC-клиенте, в течении последних трех лет позволило не потерять 1,3 млн значений пара-
СПИСОК ЛИТЕРАТУРЫ
1. SAP Manufacturing Integration And Intelligence // SAP. 2011. URL: http://www.sap.com/solutions/manufacturing/manufactu-ring-intelligence-software/index.epx (дата обращения:
28.08.2011).
2. OPC Overview 1.00 // OPC Foundation 2011. URL: http://www.opcfoundation.org/DownloadFile.aspx (дата обращения: 28.08.2011).
3. Чыонг Динь Тяу, Давыдов В.Г. Организация обмена данными между OPC-приложениями // Автоматизация в промышленности. - 2003. - № 10. - С. 23-27.
4. Using OPC via DCOM with Windows XP Service Pack 2 // OPC Foundation 2011. URL: http://www.opcfoundation.org/Download-File.aspx (дата обращения: 28.08.2011).
5. OPC, DCOM and Security // OPC Foundation 2011. URL: http://www.opcfoundation.org/DownloadFile.aspx (дата обращения: 28.08.2011).
6. OPC XMLDA 1.01 Specification // OPC Foundation 2011. URL: http://www.opcfoundation.org/DownloadFile.aspx (дата обращения: 28.08.2011).
7. Unified Architecture Collaboration Overview // OPC Foundation 2011. URL: http://www.opcfoundation.org/DownloadFile.aspx (дата обращения: 28.08.2011).
метров, что соответствует 15 дням беспрерывной передачи значений. Как показала практика, организация сбора и передачи значений параметров с вводимых в эксплуатацию новых АСУТП производится в короткие сроки.
Выводы
Исследована проблема сбора и передачи технологической информации промышленного предприятия на уровень управления и принятия решений. На основе проведенного исследования предложен подход к ее решению, базирующийся на принципах сервисно-ориентированной архитектуры и стандарте OPC. Показано, что разработанный OPC-клиент обеспечивает высокопроизводительный, надежный и удовлетворяющий требованиям безопасности современных промышленных предприятий сбор и передачу технологических данных, что подтверждается результатами его эксплуатации на нефтегазодобывающем предприятии ОАО «ВостокГазпром».
8. Козлецов А.П., Решетников И.С. Современные способы организации обмена данными с системами управления // Информационные технологии в проектировании и производстве. -2010. - № 2. - С. 17-23.
9. Juric M. SOA approach to integration. - Birmingham: Packt Publishing Ltd., 2007. - Збб p.
10. Ньюкомер Э. Веб-сервисы: XML, WSDL, SOAP и UDDI. -СПб.: Питер, 2003. - 25б с.
11. OPC Easy Connect Suite - Making OPC connectivity easy // Sof-ting. 2011. URL: http://www.softing.com/home/en/industrial-au-tomation/products/opc/easy-connect-suite/index.php (дата обращения: 28.08.2011).
12. XMLDA.NET White Paper // Advosol. 2011. URL: http://www.ad-vosol.com/t-whitepaperxmldanet.aspx (дата обращения:
28.08.2011).
13. Traffic Shaper XP // Bandwidth Controller. 2011. URL: http://bandwidthcontroller.com/trafficShaperXp.html (дата обращения: 28.08.2011).
14. Богдан С.А., Кудинов А.В., Марков Н.Г. Опыт внедрения MES «Магистраль-Восток» в нефтегазодобывающей компании // Автоматизация в промышленности. - 2010. - № 8. - С. 53-58.
Поступила 26.09.2011 г.
