Создание информационной модели OPC UA - PullRequest
0 голосов
/ 08 мая 2018

Предварительным условием для создания сервера OPC-UA является создание соответствующей информационной модели. Я взглянул на образцы, представленные на GitRep группы OPC UA (Boiler). Создание информационной модели с нуля кажется нетривиальной задачей. Каков наилучший подход для создания такой модели? Вы рекомендуете полезные инструменты?

Ответы [ 2 ]

0 голосов
/ 02 мая 2019

Существует несколько коммерческих и открытых инструментов для создания информационных моделей OPC UA. По сути, вам нужен файл NodeSet2.xml, который можно загрузить во множество различных реализаций OPC UA.

Для создания такого файла NodeSet2.xml существуют различные инструменты. Вот краткий список.

Графические инструменты:

Текстовые инструменты:

  • Вы всегда можете просто написать файл NodeSet2.xml вручную. Это не рекомендуется.
  • Используйте открытый источник OPC Foundation UA-ModelCompiler . Здесь вы пишете простые файлы Model.xml, которые конвертируются в файлы NodeSet2.xml.

Инструментом с большинством функций является UA-ModelCompiler, поскольку он используется OPC Foundation для создания файлов NodeSet2.xml для основной спецификации и сопутствующих спецификаций.

Я также написал руководство по созданию вашей пользовательской информационной модели с помощью UA-ModelCompiler здесь: https://opcua.rocks/custom-information-models/

0 голосов
/ 21 ноября 2018

Я знаю, что это старый вопрос, но я отвечу на него так же для тех людей, которые читают его в будущем

Лучший подход существует и родился до стандарта OPC UA. Это «Домен Управляемый Дизайн. Поговорите с инженерами, чтобы понять состав и техническое решение машины / установки / процесса, которые вы собираетесь смоделировать. Определите модель домена, которая содержит термины домена, которые моделируют компоненты, каждый из которых имеет свои свойства (например, имя, серийный номер) и переменные (например, температуру). Определите иерархию между компонентами, но помните, что это «статическая» модель: когда вы разрабатываете модель предметной области для веб-приложения, вы знаете, что у сущности может быть ноль, один экземпляр другой сущности / VO или один слишком много. В информационной модели OPC UA кардинальность ассоциаций фиксирована, и это вполне разумно только потому, что робот или труба не изменяют свою структуру во время выполнения ... но если это происходит, вы должны сделать возможным уведомление всех клиентов этого изменения

Ваша информационная модель будет содержать данные, но каждый компонент также может создавать события. Событие сообщает, что какое-то состояние изменилось, даже если это состояние не представлено в модели данных. Аварийные сигналы - это примеры событий, которыми вы должны управлять. OPC UA определил стандарт для аварийных сигналов и условий (тогда как условия подобны аварийным сигналам, но не представляют состояние отказа), которые представляют собой определенный тип событий. Теперь вам нужно выбрать, какие компоненты могут быть «источниками событий», и какой компонент может уведомлять о событиях, которые генерируются от него самого или от поддерева компонентов, корневым компонентом которых он является

Подтвердите вашу модель экспертами в области, не ожидайте, что они поймут, вероятно, они инженеры-механики, химики, электрики, поэтому я предлагаю вам абстрагировать их от части моделирования и сделать их предметно-ориентированным вопросом, например, "is правильно ли утверждать, что у автомобиля есть колеса foru? "

...