Интеграция SCADA-систем и систем управления предприятием

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

Солдатов Сергей

316
В ЗАКЛАДКИ

Введение

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

Информационная система предприятия

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

Первый уровень иерархии – различные автоматизированные системы учёта и управления (АСУ ТП – автоматизированная система управления технологическим процессом, АСУ Э – автоматизированная система управления электроснабжением, АСКУЭ – автоматизированная система коммерческого учёта энергоресурсов). Их задача – сбор и первичная обработка данных о техпроцессах и ресурсах предприятия, а также обеспечение диспетчерского контроля и управления оборудованием.
Второй уровень – производственные исполнительные системы, или системы управления производственными процессами (MES – manufacturing execution system). Их предназначение – решение задач синхронизации, координации, анализа и оптимизации выпуска продукции. Также к этим системам относят программное обеспечение для планирования ремонтных работ, поддержания складского резерва запасных частей и управления персоналом, выполняющим сервисное обслуживание.
Третий уровень – системы управления ресурсами предприятия (ERP – enterprise resource planning). Системы данного уровня выполняют управление финансовыми ресурсами предприятия, отслеживают запасы материалов, управляют трудовыми ресурсами компании. Также они предназначены для поддержки среднесрочного и стратегического планирования деятельности предприятия.
Зачастую на большинстве отечественных предприятий присутствуют лишь первый и второй уровень, третий представлен отрывочно. При этом стоит отметить, что наличие первого уровня – обязательное условие построения качественной информационной системы компании. Без получения всеобъемлющей информации о выполняемых техпроцессах невозможно формирование целостной картины о деятельности предприятия. Второй уровень не менее важен, но часто выполняется не с помощью специализированных приложений, использующих данные с предыдущего уровня, а представлен разрозненными приложениями, автоматизирующими деятельность планового отдела предприятия. Третий, последний уровень иерархии нашёл активное применение лишь в последние десять лет. Но внедрение ERP-систем проходило и до сих пор очень часто осуществляется без связи с предыдущими уровнями, а сами ERP-системы, состоящие из большого количества разрозненных модулей, не учитывают специфики предприятий. Лишь в последние несколько лет у заказчиков стало появляться понимание сути ERP-систем и, как следствие, возникли требования к интеграторам об организации взаимосвязи между ERP и системами нижестоящих уровней.

Некоторые проблемы интеграции

Традиционно внедрением SCADA-систем в России занимаются фирмы-интеграторы, которые на базе разработок своих партнёров, производителей программного и аппаратного обеспечения, создают готовые решения для конечных потребителей [1]. Иногда конкуренцию им составляют ИТ-отделы предприятий. При этом используется самое разнообразное программно-аппаратное обеспечение российских и зарубежных производителей, а также собственные программные разработки. Часто задачи решаются локально, без системного подхода и учёта требований к дальнейшей интеграции этих подсистем в КИС, за что в конечном счёте приходится дорого расплачиваться.
Большинство известных и популярных SCADА-систем, на первый взгляд, уже содержат реализацию всех необходимых функций оперативного контроля и управления технологическим процессом (сбор, обработка, хранение и визуализация данных, оповещение персонала о событиях и тревогах, передача команд управления). В то же время наблюдается ситуация, когда использование того или иного SCADA-пакета вызывает проблемы при интеграции с другими системами.
Одна из таких проблем – отсутствие в SCADA-системе модулей, ответственных за агрегацию данных из разнородных источников (самой SCADA-системы, OPC, SQL-базы и ряда других). Без наличия подобного функционала невозможно будет подготовить и передать данные в MES- и ERP-системы. Модуль должен поддерживать следующие функции агрегирования: усреднение, выборка max/min значений, суммирование, определение процентных соотношений и др. При этом необходимо поддерживать высокоуровневое пространство имён (формирование полного имени переменной, например, завод-цех-линия-станок-параметр) и организацию доступа к данным через системы управления базами данных (СУБД): MS SQL Server, Oracle и т.д. В этом случае системы MES и ERP посредством обычных SQL-запросов к СУБД могут легко получить доступ к истории и оперативным данным с уровня SCADA-системы.
Другой аспект интеграции внутри КИС – неоднородность информационных потоков в современных диспетчерских системах. Среди информационных потоков можно выделить два типа: технологические обмены и обмены бизнес-информацией [2]. Первые – это обмены в реальном времени значениями измеренных и контролируемых параметров. Такие обмены касаются SCADA-систем и осуществляются диспетчерскими пунктами с локальными системами автоматизации, а также идут между диспетчерскими пунктами. Бизнес-обмены – это обмены во временноˆм режиме процессов хозяйственной деятельности (не процессов работы технологического оборудования) показателями, касающимися производственной деятельности предприятия. Иначе говоря, это обмены данными в основном между компонентами MES-системы, обмены MES- с ERP-системой, обмены с системами автоматизации внешних организаций.
Однако основной сложностью в организации информационного обмена между нижним и верхним уровнем КИС является однозначное определение перечней сигналов для обмена, согласование логик, кодировок, состояния и других вопросов. Как для технологических обменов, так и для обменов бизнес-информацией перечисленные вопросы могут привести к большим проблемам. Для технологических обменов это, прежде всего, традиционная несогласованность логик, кодировок, представления информации для отдельных установок, объектов, диспетчерских комплексов локального уровня и корпоративного. Даже на уровне установки и объекта один и тот же параметр может иметь различное наименование, например, по причине поставки разными производителями SCADA-системы и локальной системы автоматизации.
Ещё более серьёзной проблемой является определение соответствия между параметрами и объектами в MES- и ERP-системах. В силу большого числа причин в ряде случаев имеются расхождения в определении (и описании) объекта предприятия в бухгалтерских документах и в диспетчерской отчётности, не говоря уже о привязке значения к средствам измерения и контроля в SCADA-системе. Большую путаницу вносят ремонты, замены оборудования. Имеющиеся разночтения приводят к существенному усложнению интеграционных проектов и повышают затраты как на внедрение системы, так и на её сопровождение и расширение. Для решения этой проблемы предлагается однозначное определение места источника данных в иерархии предприятия. Источник данных может изменяться (а также добавляться, удаляться) только в рамках реконструкции всего предприятия, а не ремонтов или замены технологического оборудования (то есть, например, замена задвижки в результате ремонта не должна приводить к изменению кодировок параметров давления и температуры, измеряемых на данной задвижке). Для этих целей предлагается введение паспортизации параметров, выполняемое ещё на этапе проектирования.
Также зачастую при попытке заказчика получить целостную КИС интегратор сталкивается со следующей проблемой – неготовность предприятия к внедрению MES- и ERP-системы. Как бы ни хотелось, но практика показывает: чтобы на предприятии заработала стандартизованная система управления, оно должно вписываться в эти стандарты, то есть выполняемые бизнес-процессы должны удовлетворять ряду требований (имеются в виду требования стандартов MES- и ERP-систем). На этот случай интегратору стоит обратить внимание на системы диспетчерского управления (СДУ, ADSC – automated dispatching control systems) [3].
Очень часто на предприятии отдельно существуют ERP, системы цехового уровня и АСУ ТП. Выстраивание связанной иерархии средствами системы, взятой с одного из уровней управления, не даёт эффекта – слишком узкую область она охватывает.
Системы диспетчерского управления способны заполнить бреши в автоматизации. Они работают на стыке разных систем, и в их арсенале есть всё необходимое для интеграции данных разного уровня. Основа подобной системы – сбор и консолидация данных, под которой понимается комплекс методов и процедур, направленных на извлечение данных из различных источников, обеспечение необходимого уровня их информативности и качества, преобразование в единый формат, в котором они могут быть загружены в хранилище данных или аналитическую систему. Подобный функционал очень похож на возможности модулей агрегирования в современных SCADA-системах.
На каждом из уровней СДУ используется своя система показателей, отображаемая в виде графиков и индикаторов. Из табл. 1 видно, что основными источниками информации являются общепринятые классы систем: SCADA, MES, ERP. Однако и сами системы диспетчерского управления имеют соответствующие возможности. 
Безусловно, СДУ – это не панацея, но они способны эмулировать некоторые отсутствующие системы до их появления. Для целого ряда предприятий полный функционал бывает и не нужен, даже в продуктах от грандов систем управления предприятием, таких как SAP, Microsoft, Oracle и других, используются далеко не все модули.
Известно, что руководители практически не работают в учётных системах. И уж точно не работают в тех, где нет средств анализа или мониторинга. Важнейшая цель СДУ – донести до руководителя сводную информацию о работе его подотчётного подразделения в простом и понятном виде. Именно поэтому СДУ и внедряются легче – ведь в них заинтересованы руководители.
В целом можно сказать, что основа эффективной организации информационных обменов – полная проработка данных вопросов на этапе проектных работ [2]. Роль проектных организаций крайне велика, в случае эффективного решения проблемы информационных обменов на стадии проектирования достигается существенная экономия всех видов ресурсов при реализации и расширении системы и, главное, обеспечивается эффективное решение всех классов задач на всех уровнях управления.

Преодоление проблем интеграции

Одним из способов решения ряда указанных проблем является использование «правильного» программного обеспечения (ПО). К такому ПО смело можно отнести приложения компании ICONICS. Истории их успешного внедрения и интеграции с другими системами наглядно показывают, что интеграторы, вооружённые «правильными» решениями, могут справиться с самыми разнообразными проектами.
Одним из таких проектов была интеграция производственных процессов с ERP-системами в компании «Почта Италии» (Poste Italiane). Это национальная почтовая система Италии, которая обрабатывает более 7 миллиардов почтовых отправлений в год и управляет тысячами сотрудников и отделений.
Проект был направлен на повышение качества оперативного управления почтовой инфраструктурой и улучшение следующих бизнес-процессов:
  • контроль, мониторинг и управление производственными операциями;
  • мониторинг хода выполняемых работ;
  • поддержка управленческих решений;
  • отслеживание потоков корреспонденции в рамках сортировочного центра;
  • сбор данных с полевого уровня (датчики, исполнительные механизмы);
  • интеграция с административными системами.
В ходе выполнения проекта были внедрены следующие программные продукты ICONICS: пакет SCADA-системы GENESIS32, включающий GraphWorX32, TrendWorX32, AlarmWorX32 и DataWorX32; интеллектуальное решение BizViz и программы для бизнес-представления информации, в том числе PortalWorX, ReportWorX, BridgeWorX и MobileHMI.
Были получены следующие результаты внедрения и интеграции:
  • полная интеграция всей цепочки создания стоимости, от уровня производства до уровня предприятия;
  • организация доступа к информации в режиме реального времени, что позволило сотрудникам и менеджерам работать и взаимодействовать с большей производительностью;
  • предоставление управленческому персоналу информации для принятия более качественных оперативных решений;
  • предоставление широких возможностей по интеграции и использованию информации из нескольких источников данных, в том числе из систем: сортировочных, распознавания адресов, складских, взвешивания и упаковки, финансовых и планирования производства;
  • прекрасные коммуникационные возможности, гибкость полученного проекта и качественная визуализация.
Была получена дополнительная прибыль за счёт интеграции интеллектуальной системы управления производством со всеми модулями, используемыми в цепочке формирования стоимости. Решение интегрировано с SAP (PP/DS, EM, BW-SEM, SD & LES), системами RFID и уже существующими системами.

Продукт ICONICS BizViz (рис. 2) обеспечил выполнение жёстких требований по визуализации и подключению, что позволило:
  • создать персонализированные информационные панели с соответствующим содержанием от различных систем;
  • ввести настраиваемые ключевые показатели эффективности для отслеживания производительности в режиме реального времени по заданным целям;
  • обеспечить формирование отчётности (автоматической и по запросу) с передовыми аналитическими функциями.
Начавшись в 2004 году, проект постепенно охватил все 23 сортировочных центра. В течение всего процесса внедрения уровень автоматизации бизнес-процессов неуклонно рос от первоначальных 40% к запланированным 85%. Стоит отметить, что критическим фактором успеха и быстрого развёртывания было тесное сотрудничество заказчика с местным системным интегратором.
Другим интересным проектом, где требовалось построение комплексной информационной системы предприятия, был проект в Metal Trade Comax (Чехия). Это предприятие расположено примерно в 30 километрах от Праги и работает в области цветной металлургии, выпуская как сплавы, так и металлопрокат (рис. 3).

Используя технологию Coil Coating (нанесение покрытия на рулонный прокат), металлургическое предприятие выполняет нанесение органических покрытий и тиснения на алюминий, алюминиевые сплавы, холоднокатаную сталь и горячеоцинкованную сталь. Покрытый специальным составом металлопрокат имеет широкую область применения: кровля, листовой металл, перила, окна, прицепы, облицовка зданий и т.д.
ICONICS GENESIS32 с GraphWorX32 обеспечивает визуализацию процесса нанесения покрытия на металл. WebHMI позволяет контролировать процессы через Интернет. ReportWorX32 и TrendWorX32 обеспечивают запись данных, графиков, отчётов и простую аналитику, в то время как AlarmWorX32 предоставляет информацию о неисправностях. Для полной интеграции данных о производстве и бизнес-процессах в компании обеспечивается обмен данными между ПО ICONICS и системой планирования ресурсов предприятия Microsoft Dynamics NAV.
GENESIS32 для Metal Trade Comax был предложен системным интегратором ADAX, который уже реализовал несколько успешных проектов в Чехии. После 8 месяцев внедрения заказчик получил полный мониторинг и контроль производственных процессов.
Поддержка открытых стандартов в ICONICS позволила заказчику обеспечить совместимость с устройствами от самых разных поставщиков. Решение от ICONICS легко взаимодействует и с SIEMENS SIMOTION PLC, управляющими двигателями производственной линии, и с SIEMENS SIMATIC S7-300, связанными через Industrial Ethernet.
DataWorX32 обеспечивает агрегацию данных из различных источников OPC. Также проводится мониторинг по SNMP-протоколу устройств измерения потреблённой электроэнергии. Компонент TrendWorX позволил компании сохранять большие объёмы исторических данных в Microsoft SQL 2005 Server, а ReportWorX предоставил возможность генерации технологических и клиентских отчётов. Технологические отчёты включают в себя информацию об условиях и событиях во время производства, например, о дефектах на поверхности рулона металла или аварийных событиях во время нанесения покрытия. Клиентские отчёты содержат бизнес-информацию из Microsoft Dynamics NAV и краткое описание продукта, включая длину полосы, вес, материал и результаты лабораторных исследований.
Решения от ICONICS позволили гарантированно обеспечить необходимый уровень качества металлического покрытия на выходе с конвейера. Компания имеет систему для автоматической оценки поверхностных дефектов в рулонах. Для этого на линии установлены три быстрые промышленные камеры, которые могут обнаружить поверхностные дефекты на металлических пластинах. Результаты работы камер передаются в ReportWorX (рис. 4), где данные визуализируются и сохраняются на сервере. 

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

Заключение

Долгое время системные интеграторы из области АСУ ТП не сталкивались с необходимостью разбираться со смежными системами и обеспечивать интерфейсы обмена информацией. Проблемы обработки и использования накопленной в базах данных SCADA-систем информации в сфере бизнес-процессов были взвалены на тех, кому эти данные нужны. Но сейчас им брошен серьёзный вызов: потенциальным и бывшим клиентам уже не нужен только хорошо отлаженный технологический процесс, им нужен бизнес-процесс, увязанный с технологией. А для этого надо гораздо серьёзнее отнестись к проектированию новых систем, а также к выбору «правильного» инструментария. ●

Литература

1. Прошин Д.И., Гурьянов Л.В. Проблемы выбора инструментальных средств построения SCADA-систем // ИСУП. – 2010. – № 1.
2. Зельдин Ю.М., Ковалёв А.А. Концепция построения современной информационно-управляющей системы в диспетчерском центре газотранспортного общества ОАО «Газпром» [Электронный ресурс] // Сайт ЗАО «АтлантикТрансгазСистема». – Режим доступа : http://www.atgs.ru/Sites/atgs_ru/Uploads/samara.9E337D05265F4BC8B9ABC82460B50988.pdf.
3. Системы диспетчерского управления [Электронный ресурс] // Сайт компании SIAMS. – Режим доступа : http://www.siams.com/disp.htm.

E-mail: ssa-company@rambler.ru


ПОДПИСАТЬСЯ НА НОВОСТИ

Будьте всегда в курсе самых свежих новостей
и узнавайте первыми о содержании нового номера

Подписка на новости