В «Открытых системах» №8/2009 опубликована статья о внедрении решения для управления мастер-данными (IBM InfoSphere MDM Server for PIM) в X5 Retail Group.
Что интересно в описанном внедрении – что проектирование (включая разработку модели данных) вела французская фирма Edifixio, собственно внедрение выполняла «Крок» (включая «разработку бизнес-правил работы с мастер-данными»), передача уведомлений об изменениях в мастер-данных обеспечивается IBM WebSphere MQ (гарантированная доставка сообщений) , плюс ИТ-специалисты X5 разработали адаптеры для стыковки MDM и MQ со своими существующими ERP-системами.
Но ситуация, когда на одном предприятии сосуществуют несколько систем, которые служат для сбора, хранения, обработки данных – пусть в разных ракурсах, но об одном и том же – эта ситуация есть и на производстве, в том же транспорте газа!
Использовать MDM-систему для хранения справочника технологического и измерительного оборудования, всей производственной НСИ, и автоматизировать настройку SCADA и MES, и в частности обмен SCADA – MES, опираясь на master data… Мечта!
* * *
Еще статья о мастер-данных в «Открытых системах» №5/2007…
воскресенье, 8 ноября 2009 г.
вторник, 3 ноября 2009 г.
открытость Xi
Исключительно полезной для осознания факта "неотвратимости" Xi оказалась запись в блоге Jim Cahill'а из Emerson.
А именно - он привел перечень "инициативных" компаний: Advosol, Emerson Process Management, Honeywell, Iconics,
InduSoft, Matrikon, Mobiform, Mynah Technologies, OSIsoft, Smar and TiPS.
Опять же, он пишет, что уже существует 10 Xi-серверов и 15 Xi-клиентов, представленных на конференции Emerson Exchange.
То есть открытость технологии (исходные тексты и документацию можно скачать с www.expressinterface.com -> Downloads, даже не регистрируясь, - делает свое дело.
Возможно, не только она, но общедоступность - это осознанная позиция разработчиков Xi. В разделе "Новости" на том же
сайте они пишут, что их позвали "под зонтик" OPCFoundation. Возможно, они и согласятся, но будут настаивать, чтобы
спецификации и демо-примеры оставались общедоступны.
(Сравните с тем, что OPCFoundation не предоставляет свободного доступа к спецификации и демо-кодам OPC UA, считая, то только компании-члены смогут квалифицированно реализовать OPC UA-продукты. И сколько сейчас OPC UA-клиентов и серверов доступно, после 5 лет изысканий?)
А именно - он привел перечень "инициативных" компаний: Advosol, Emerson Process Management, Honeywell, Iconics,
InduSoft, Matrikon, Mobiform, Mynah Technologies, OSIsoft, Smar and TiPS.
Опять же, он пишет, что уже существует 10 Xi-серверов и 15 Xi-клиентов, представленных на конференции Emerson Exchange.
То есть открытость технологии (исходные тексты и документацию можно скачать с www.expressinterface.com -> Downloads, даже не регистрируясь, - делает свое дело.
Возможно, не только она, но общедоступность - это осознанная позиция разработчиков Xi. В разделе "Новости" на том же
сайте они пишут, что их позвали "под зонтик" OPCFoundation. Возможно, они и согласятся, но будут настаивать, чтобы
спецификации и демо-примеры оставались общедоступны.
(Сравните с тем, что OPCFoundation не предоставляет свободного доступа к спецификации и демо-кодам OPC UA, считая, то только компании-члены смогут квалифицированно реализовать OPC UA-продукты. И сколько сейчас OPC UA-клиентов и серверов доступно, после 5 лет изысканий?)
понедельник, 2 ноября 2009 г.
Xi
Из сообщения в TAC Blog от 29 октября я узнал о существовании технологии Xi (express interface).
Что это? (источник информации - http://expressinterface.com/)
Данная технология претендует на то, чтобы выступить заменой "классическому" OPC. При этом она разрабатывается
не "официальным держателем" OPC (OPC Foundation), а неким консорциумом фирм...
Преимущество Xi - то, что это по-прежнему на 100% использование технологий Microsoft. OPC использует DCOM (а тот,
в свою очередь, универсальный TCP/IP); COM/DCOM сейчас является устаревшей технологией, а современной заменой
выступает .NET c WCF (Windows Communication Foundation).
И вот, если сохранить концепцию OPC* - но реализовать ее современными средствами,
то можно претендовать на то, чтобы стать наследником - и получить процент от наследства...
==========
* - наличие сервера, взаимодействующего с оборудованием по нестандартному протоколу, и клиента,
взаимодействующего
с одним или несколькими серверами стандартным образом и, т.о., избавленного от необходимости "знать" протокол
каждого конкретного производителя средств автоматики.
==========
OPC Foundation, в свою очередь, развитие OPC видит в OPC UA - технологии, полностью "отвязанной" от Microsoft.
Но они опасаются, видимо, что для многих заказчиков, для которых платформа Microsoft - корпоративный стандарт
и в сфере автоматизации (а, например, для автоматики SIEMENS норма - это пункт управления под Windows) - Xi
может оказаться привлекательнее OPC UA (к сложности развертывания и реализации которого много вопросов...).
Читаем: Microsoft is migrating from COM to .NET based applications, so a .NET-based replacement was needed for existing applications.
С другой стороны, Xi - это не разработка Microsoft. На сайте Microsoft нет никаких упоминаний об Xi.
Что это? (источник информации - http://expressinterface.com/)
Данная технология претендует на то, чтобы выступить заменой "классическому" OPC. При этом она разрабатывается
не "официальным держателем" OPC (OPC Foundation), а неким консорциумом фирм...
Преимущество Xi - то, что это по-прежнему на 100% использование технологий Microsoft. OPC использует DCOM (а тот,
в свою очередь, универсальный TCP/IP); COM/DCOM сейчас является устаревшей технологией, а современной заменой
выступает .NET c WCF (Windows Communication Foundation).
И вот, если сохранить концепцию OPC* - но реализовать ее современными средствами,
то можно претендовать на то, чтобы стать наследником - и получить процент от наследства...
==========
* - наличие сервера, взаимодействующего с оборудованием по нестандартному протоколу, и клиента,
взаимодействующего
с одним или несколькими серверами стандартным образом и, т.о., избавленного от необходимости "знать" протокол
каждого конкретного производителя средств автоматики.
==========
OPC Foundation, в свою очередь, развитие OPC видит в OPC UA - технологии, полностью "отвязанной" от Microsoft.
Но они опасаются, видимо, что для многих заказчиков, для которых платформа Microsoft - корпоративный стандарт
и в сфере автоматизации (а, например, для автоматики SIEMENS норма - это пункт управления под Windows) - Xi
может оказаться привлекательнее OPC UA (к сложности развертывания и реализации которого много вопросов...).
Читаем: Microsoft is migrating from COM to .NET based applications, so a .NET-based replacement was needed for existing applications.
С другой стороны, Xi - это не разработка Microsoft. На сайте Microsoft нет никаких упоминаний об Xi.
четверг, 14 мая 2009 г.
Дождался!
Наконец-то получил от Amazon.com анонсированную еще прошлой осенью книгу: OPC Unified Architecture (W. Mahnke, S.-H. Leiter, M. Damm).
понедельник, 30 марта 2009 г.
Объекты OPC UA
К сожалению, я пока так и не "потрогал" ни одного OPC UA сервера/клиента, заказанная книга (Mahnke, Leitner, Damm. "OPC Unified Architecture") все еще не отгружена с Amazon, так что читаем материалы в сети. Например, "OPC UA: An End-User’s Perspective" (я скачал экземпляр с сайта OPC TI).
В частности, читаем:
"OPC UA also provides the ability to create more complex objects. For example, one could create a pump that is composed of various temperature, level, pressure, flow, and vibration readings. Included would be the history of all values as well as a picture of the pump. One could even associate P&ID schematic diagrams and maintenance orders. This presents a powerful mechanism for integrators from various companies to share data without having to recreate it in their different proprietary software applications."
Фактически, OPC-сервер становится SCADA-системой и...
1) Мы приходим к тому, что было 10 лет назад? Когда SCADA-система по некоторому закрытому или стандартному протоколу стыковалась с оборудованием (ПЛК)?
2) Мы сможем встраивать в интегрирующий модуль (например, web-коллаж) объекты, т.е. фактически наборы данных от различных OPC-серверов, без создания копии отображаемых данных в приложении-интеграторе ("... without having to recreate it in their different proprietary software applications.")
Это все интересно, но что совершенно неясно - это как OPC UA-клиент сможет оперировать этими объектами, если цель все-таки - не сделать HMI-картинку, а передать данные в другую информационную систему.
Все-таки, получится перейти от списка сигналов к типизированному списку групп сигналов? (а именно так я бы пока вижу OPC UA-объект).
В частности, читаем:
"OPC UA also provides the ability to create more complex objects. For example, one could create a pump that is composed of various temperature, level, pressure, flow, and vibration readings. Included would be the history of all values as well as a picture of the pump. One could even associate P&ID schematic diagrams and maintenance orders. This presents a powerful mechanism for integrators from various companies to share data without having to recreate it in their different proprietary software applications."
Фактически, OPC-сервер становится SCADA-системой и...
1) Мы приходим к тому, что было 10 лет назад? Когда SCADA-система по некоторому закрытому или стандартному протоколу стыковалась с оборудованием (ПЛК)?
2) Мы сможем встраивать в интегрирующий модуль (например, web-коллаж) объекты, т.е. фактически наборы данных от различных OPC-серверов, без создания копии отображаемых данных в приложении-интеграторе ("... without having to recreate it in their different proprietary software applications.")
Это все интересно, но что совершенно неясно - это как OPC UA-клиент сможет оперировать этими объектами, если цель все-таки - не сделать HMI-картинку, а передать данные в другую информационную систему.
Все-таки, получится перейти от списка сигналов к типизированному списку групп сигналов? (а именно так я бы пока вижу OPC UA-объект).
понедельник, 9 февраля 2009 г.
Взаимодействие с поставщиком газа: стек протоколов
Если Вы - предприятие в Германии и используете природный газ, то взаимодействие с газотранспортной компанией, оперирующей в вашем регионе и с которой у вас заключен контракт, в ежедневном режиме может осуществляться путем электронного обмена данными (EDI - Electronic Data Interchange).
Как именно?
Пример приведен в документе на сайте крупнейшей такой компании: E.ON (ее подразделения E.ON Gastransport).
Транспортный протокол: AS2.
Протокол, определяющий кодировку сообщений: EDIG@S (построенный на базе EDIFACT).
Как формировать свои и анализировать получаемые сообщения согласно этому протоколу
(в частности: NOMINT - заявки, NOMRES - их подтверждения, ALOCAT - балансирование)
описано на сайте специализированной консалтинговой фирмы DVGW и опять же E.ON Gastransport.
(Интересно, что DVGW разрабатывает систему кодирования объектов газотранспортной системы, и справочник кодов так просто с сайта загрузить нельзя - цена 240 евро).
Аналогично и в Соединенных Штатах - прекрасный анализ ситуации (по состоящию еще на 2002 год!) приведен в документе "Utitlity Deregulation Requires Effective E-Business Standards".
Как именно?
Пример приведен в документе на сайте крупнейшей такой компании: E.ON (ее подразделения E.ON Gastransport).
Транспортный протокол: AS2.
Протокол, определяющий кодировку сообщений: EDIG@S (построенный на базе EDIFACT).
Как формировать свои и анализировать получаемые сообщения согласно этому протоколу
(в частности: NOMINT - заявки, NOMRES - их подтверждения, ALOCAT - балансирование)
описано на сайте специализированной консалтинговой фирмы DVGW и опять же E.ON Gastransport.
(Интересно, что DVGW разрабатывает систему кодирования объектов газотранспортной системы, и справочник кодов так просто с сайта загрузить нельзя - цена 240 евро).
Аналогично и в Соединенных Штатах - прекрасный анализ ситуации (по состоящию еще на 2002 год!) приведен в документе "Utitlity Deregulation Requires Effective E-Business Standards".
воскресенье, 11 января 2009 г.
Итоги 2008
Чем запомнился 2008 год с точки зрения человека, интересующегося информационными стыками?
1. Знак "-". OPC UA так и не перешел в стадию реально доступного и эксплуатирующегося протокола. Новая версия Genesis64, в которой заявлена его поддержка - возможно, является работающим OPC UA-клиентом, но проверить его возможности не удалось - не нашлось OPC UA-сервера (как получить анонсированную разработку Kepware, не знаю...)
2. Знак "+". AMQP. Впервые услышал о нем только в середине декабря. Но движение к использованию промежуточного ПО для обмена сообщениями в системах диспетчерского управления для газовой отрасли - обозначилось и ранее (вспомнить хотя бы приглашения специалистов IBM с докладом по WebSphere на одно из совещаний).
3. Знак "?". Protocol Buffers от Google. Шансы на то, что эта технология будет использоваться для взаимодействия систем разных разработчиков между собой, невелики. Но идея хорошая.
4. Знак "+". Отход от Modbus/RTU. В 2008 году не было ни одного случая стыка с новой (для нас) системой, с которой ее разработчик предложил бы стыковаться по Modbus/RTU. Если уж и не OPC, то Modbus/TCP! (Нужно только быть готовым к тому, что некоторые считают, что Modbus/TCP = пакеты Modbus/RTU в сети TCP/IP. Впрочем, я к этому готов).
1. Знак "-". OPC UA так и не перешел в стадию реально доступного и эксплуатирующегося протокола. Новая версия Genesis64, в которой заявлена его поддержка - возможно, является работающим OPC UA-клиентом, но проверить его возможности не удалось - не нашлось OPC UA-сервера (как получить анонсированную разработку Kepware, не знаю...)
2. Знак "+". AMQP. Впервые услышал о нем только в середине декабря. Но движение к использованию промежуточного ПО для обмена сообщениями в системах диспетчерского управления для газовой отрасли - обозначилось и ранее (вспомнить хотя бы приглашения специалистов IBM с докладом по WebSphere на одно из совещаний).
3. Знак "?". Protocol Buffers от Google. Шансы на то, что эта технология будет использоваться для взаимодействия систем разных разработчиков между собой, невелики. Но идея хорошая.
4. Знак "+". Отход от Modbus/RTU. В 2008 году не было ни одного случая стыка с новой (для нас) системой, с которой ее разработчик предложил бы стыковаться по Modbus/RTU. Если уж и не OPC, то Modbus/TCP! (Нужно только быть готовым к тому, что некоторые считают, что Modbus/TCP = пакеты Modbus/RTU в сети TCP/IP. Впрочем, я к этому готов).
Подписаться на:
Сообщения (Atom)