Нажмите "Enter", чтобы перейти к контенту

Операции и обслуживание Взаимодействие с использованием открытого стандарта MIMOSA

Зачем нам нужен стандарт MIMOSA?

На сегодняшнем рынке программного обеспечения для производства существует множество поставщиков, участвующих в интеллектуальном обслуживании (мониторинг состояния и прогнозная оценка здоровья активов). Это настоящий пример фрагментированного рынка, где нет четкого лидера с доминирующей долей рынка. Такая же ситуация существует в меньшей степени на стороне обслуживания; в то время как есть несколько крупных поставщиков, ни одна из них не имеет доминирующей доли на рынке EAM, оценивается в 2,1 млрд. долл.

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

Протокол MIMOSA стандартизирует интерфейс между системами напольных систем (включая PdM) и EAM. Стандарт MIMOSA дополняет OPC, который обрабатывает коммуникационный аспект взаимодействия в реальном времени с устройствами завода. Существует глобальная организация под названием OpenO & M, которая является сотрудничеством между MIMOSA, OPC Foundation и комитетом ISA SP95.

Сравнение OPC

. Хороший способ понять, что происходит с MIMOSA сегодня, — это посмотреть на аналогичную эволюцию стандарта OPC в новейшей истории. Десять лет назад у оперативного персонала возникла проблема — у них было гетерогенное оборудование для пола, включая распределенные системы управления (DCS), ПЛК, двигатели, клапаны и т. Д. Вниз по цепочке. С таким количеством разных поставщиков устройств производители должны были беспокоиться о том, какие поставщики поддерживались для своих консолей HMI, какие протоколы низкого уровня могут использоваться для устранения разрыва. В дополнение к этому был установлен стандарт OPC (основанный на предварительных успехах стандартов шины), который обеспечил стандартизированный протокол связи в устройствах на заводе.

. По той причине, что стандарт OPC стал основным приемом, являются сторонними поставщиками, которые вошли в систему и создали мостовые продукты для обеспечения совместимости устройств. С этими мостами клиентам не приходилось ждать, пока ПЛК Allen Bradley станут совместимыми; они могут быть адаптером OPC для этого устройства. То же самое происходит и с системами EAM. В то время как некоторые поставщики EAM затащили ногу, сторонние поставщики вступили и построили MIMOSA-совместимые мосты.

Протокол MIMOSA Messaging

. Одним из важных шагов в эволюции MIMOSA был переход от протокола, ориентированного на хранилище, к протокол, ориентированный на обмен сообщениями. Первоначальная версия MIMOSA была основана на модели данных CRIS или Common Relational Information Schema. Это была модель данных, которая включала сценарии базы данных для реализации SQL Server и Oracle. Были созданы схемы XSD, сопоставленные с схемами CRIS, но многие производители сосредоточили внимание на аспекте хранения протокола.

Сравнивая протокол с OPC, стало ясно, что существует потребность в протоколе обмена сообщениями для стандартизации интерфейса между установкой напольные системы и системы EAM. OPC стандартизовал интерфейс для установки напольных устройств для получения данных в режиме реального времени. То, что необходимо для систем EAM, было протоколом обмена сообщениями, который мог бы сделать то же самое, для случаев использования, таких как автоматическое создание рабочего заказа, загрузка счетчиков и точек измерения, получение информации об активах и статус аудита сгенерированной работы и истории работ. Поскольку у каждого поставщика EAM была своя собственная реализация базы данных, интерес был в основном на уровне обмена сообщениями, а не на дополнительном уровне хранения. Спецификации веб-сервисов Tech-Xml XSD и Tech-Xml-Services сместили фокус на уровень обмена сообщениями для интеграции.

Хорошие новости о сегодняшних решениях заключаются в том, что они могут использовать связь веб-сервисов на основе Tech-Xml для привязки к EAM а также использовать базу данных CRIS для стандартизованных возможностей отчетности. Поскольку все больше поставщиков строят инструменты анализа надежности и создания отчетов в дополнение к CRIS, им не все приходится беспокоиться о том, чтобы сантехника подключалась к каждой собственной базе данных EAM для отчетности.

Сколько систем управления активами предприятия (EAM) сегодня совместимы?

Почти все основные системы EAM на рынке сегодня, включая SAP, Maximo, Datastream и Indus, имеют адаптеры на основе MIMOSA (в некоторых случаях адаптеры принадлежат компаниям-партнерам). Эти адаптеры делают системы EAM MIMOSA совместимыми, поэтому прогнозирование обслуживания и поставщиков активов может сосредоточиться на их добавлении стоимости, сокращении незапланированных простоев и устранении затрат на техническое обслуживание, а не на том, чтобы сосредоточиться на сантехнике для всех систем EAM. Это также приносит пользу клиенту, который защищен от риска обновления и миграции для интеграции EAM. Клиент также выигрывает от более низкой стоимости интеграции.

Будьте первым, кто оставит комментарий!

Добавить комментарий