Роль АРМ в концепции АСУП

 

Содержание

 

 

Интеграция  АСУТ

Еще до недавнего  времени две подсистемы автоматизации  промышленных предприятий: АСУТ (системы автоматизации управленческой и финансово-хозяйственной деятельностью, планирования ресурсов предприятия) и АСУТП (системы автоматизации технологических и производственных процессов) развивались обособленно и независимо друг от друга (рис. 1).

 

Рис. 1. Основные подсистемы автоматизации на предприятии.

 

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

Технологические данные как исходная информация позволяют  принять качественные стратегические управленческие решения многих задач:

• повышение качества продукта;
• повышение объемов производства;
• повышение эффективности производства;
• снижение длительности простоев;
• снижение себестоимости;
• сохранение инвестиций.

Объем и степень  доступа к технологической информации зависят от типа программного обеспечения, используемого в управленческих структурах предприятия и от категории сотрудников-потребителей данной информации. Ниже указаны цели и типовые вопросы различных служб предприятия, которым все это нужно:

• управление производством;
• службы контроля;
• технологические службы;
• ремонтные службы;
• службы контроля качества;
• операторы оборудования;
• плановые службы;
• бухгалтерия;
• прочие.

Ситуация  усугубляется еще и тем, что программное  обеспечение, используемое в АСУТ и АСУТП, достаточно долго развивалось независимо и не предусматривалась возможность стандартизации каналов обмена между двумя системами. Поэтому до детального обсуждения вопросов интеграции двух подсистем отметим общие свойства и различия в организации программного обеспечения для них.

Сходство и  различие систем

Рассматриваемые подсистемы являются распределенными, поэтому протоколы локальных  сетей и протоколы Internet позволяют интегрировать информационные и управляющие потоки в узлах каждой подсистемы. Объединение узлов возможно как в режиме n-tier (равные с равными), так и клиент – сервер. Кроме этого, на сегодняшний день определились категории программных средств, используемых в подсистемах АСУТ и АСУТП, причем каждая категория в АСУТ зависит от степени интеграции систем (таблица 1).

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

• визуализация технологического процесса;
• сбор данных от различных источников информации по DDE (Dynamic Data Exchange), OPC (OLE for Process Control) и частным протоколам;
• поддержка языка SQL для создания, удаления, чтения, записи и модификации информации в таблицы баз данных.

Теперь о  различиях. Отношение к реальному  времени в подсистемах АСУТП  принципиально важно – негарантированное  время реакции на событие в  технологическом процессе недопустимо. Различные каналы обмена (а соответственно, и протоколы) характеризуются соответствующими приоритетами, и определяются степенью критичности выполняемых задач.

Из всего  этого следует объективная необходимость  интеграции – сегодня созданы  для этого необходимые предпосылки. Рассмотрим теперь возможные пути интеграции подсистем уровней АСУТ и АСУТП:

• использование баз данных в качестве буфера для обмена и бизнес-приложения для организации передачи данных между двумя подсистемами. Причем базы данных могут быть как основой функционирования самих подсистем, так и средством, используемым для хранения функциональных данных. Именно базы данных, скорее всего, могут стать основным средством интеграции двух подсистем;
• применение класса продуктов, импортирующих и экспортирующих объекты из одной подсистемы в другую (например, ПО VisualFlow);
• использование готовых решений, образуемых при объединении компаний-разработчиков продуктов АСУТ и АСУТП (например, Wonderware и Marcom).

Базы данных

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

Производственные  процессы генерируют данные очень быстро. Чтобы хранить производственный архив системы, например, с 7500 рабочими переменными, в базу данных каждую секунду  необходимо включать 7500 строк. Обычные базы данных не могут выдержать подобную нагрузку.

Производственная  информация имеет большой объем. Многомесячный архив завода с 7500 рабочими переменными требует под  базу данных около 1 Тбайт дисковой памяти. Сегодняшние технологии такими объемами манипулировать не могут.

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

Для преодоления этих ограничений был предложен новый класс продуктов – базы данных реального времени (БДРВ), созданные независимо, либо разработанные на основе существующих реляционных СУБД. Более перспективным представляется второй подход, поскольку, во-первых, в стоимостном отношении он дешевле, во-вторых, технологичнее. В качестве примера реализации базы данных реального времени отметим, например, IndustrialSQL Server (компания Wonderware) и Plant2SQL (Ci Technologies). Основные функции баз данных реального времени, построенной на основе Microsoft SQL Server, заключаются в следующем.

1. Сохранение  некритичной ко времени информации  в Microsoft SQL Server. В то время как вся технологическая информация сохраняется в специальном формате.

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

3. Поддержка  целостности данных для обеспечения  записи больших объемов информации  без потерь.

4. Добавление  в Microsoft SQL Server свойств сервера реального времени.

Сегодня базы данных реального времени ориентированы  на хранение технологической информации, обеспечение связи с управленческими  данными, на использование уже ставших  стандартными в подсистемах АСУТ компонентов OLE DB, а также Internet-интерфейсов (рис. 2). С одной стороны, им приходится иметь дело с данными, которые поступают в базы данных реального времени из различных технологических источников, с другой – с данными, запрашиваемыми потребителями через интерфейс SQL-сервера.

 

Рис. 2. База данных реального времени на основе Microsoft SQL Server.

 

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

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

Следует подчеркнуть, что в зависимости от требований создаваемой системы возможны следующие  варианты решений:

• использование только реляционных баз данных, в таблицы которых подсистема АСУТП по SQL-запросам записывает технологические данные, которые в дальнейшем могут быть использованы обеими подсистемами;
• использование баз данных реального времени, которые обеспечивают более высокие характеристики регистрации данных и упрощают (без использования SQL) процесс внесения данных в таблицы;
• построение комбинированного решения, предполагающего использование баз данных реального времени для технологических первичных данных и таблиц реляционных баз для вторичных.

Специальные технологии

Как уже было отмечено, существует устоявшийся набор  стандартных протоколов, позволяющий  назвать практически любую SCADA-систему открытой. Большинство SCADA-систем «живет» сегодня на платформе Microsoft Windows и поддерживая соответствующие технологии межпрограммного взаимодействия внутри подсистем АСУТП.

ПО подсистем АСУТ, разработанное для платформы Windows, не могло избежать влияния технологий Microsoft – построенные на их основе каналы связи позволяют обеспечить обмен, а стандартные программные протоколы DDE, OLE и OPC могут стать основой интеграции подсистем (рис. 3).

 

Рис. 3. Обобщенная схема  взаимодействия двух типов служб.

Новый класс  продуктов

Для организации  информационного потока технологических данных в системы АСУТ ряд крупных разработчиков инструментальных систем (прежде всего, SCADA) предложили использовать специальный тип программных продуктов, например, VisualFlow компании Envisionlt.

Рис. 4. Возможности интеграции VisualFlow.

 

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

Так, для интеграции с  системами SAP R/3 определены в VisualFlow следующие интерфейсы:

• интерфейс PPPI (PI-PCS BAPI);
• интерфейсы, сертифицированные компанией SAP (R/3 RFC, Access 10,000+RFC, CALL_TRANSACTION RFC, IDOC, ABAP/4);
• интерфейс баз данных (доступ к таблице/полю и поддержка всех баз данных R/3).

Однако VisualFlow — это только продукт, способный интегрировать, а что интегрировать определяется конкретной задачей. Разработчик приложения VisualFlow определяет из каких подсистем принимаются объекты (например, из SCADA-приложений), каким образом полученная через объекты информация преобразуется и передается в целевые подсистемы (например, АСУТ). Формирование SCADA-объектов или объектов баз данных реального времени позволяет на базе VisualFlow транспортировать объект с технологическими данными управленцам.

 

Автоматизированные места

Рабочие места  бухгалтеров могут быть оснащены персональными компьютерами и на их основе созданы автоматизированные рабочие места бухгалтера (АРМ). Они  позволяют автоматически формировать первичные документы и машинограммы по различным участкам учета и передавать полученные результаты в ВЦ, чтобы составить сводные регистры бухгалтерского учета и отчетности. Их внедрение поможет решить проблему полной и комплексной автоматизации бухгалтерского учета.

 

Таблично-автоматизированная форма бухгалтерского учета

 

 

 

 

                                      Условные обозначения:

• ручная передача информации
• автоматическая передача и обработка информации
• диалог с ЭВМ

 

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

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

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