ЖУРНАЛ СТА №3/2023

timeout и tick не объявляются, так как являются защищёнными (недоступны- ми снаружи объекта). Листинг 5 содержит XML-описание типа (класса) BoilerModelM1 (рис. 1), ко- торый унаследован от типа NaturalPull- GasBoiler и не является абстрактным. Да- лее переопределяется уровень доступа к атрибутам объекта burner : переменные spark и gasValve становятся доступными только для чтения. Реализация всех методов ( startHeat- ing , stopHeating , timeout , tick ) в нашем случае определяется на языке C#. При создании объекта сервер должен на- значить всем методам соответствую- щую реализацию (подгрузить драйвер). Пусть имеется три газовых котла раз- ных моделей ( BoilerModelM1…Boiler- ModelM3 ). Создадим экземпляры этих классов (см. листинг 6 ). Тег opc:Object задаёт объект BoilerM1 типа BoilerMode- lM1 , находящийся в корневой папке объектов ( ObjectsFolder ) в дереве уз- лов. Аналогичным образом задаются объекты BoilerM2 и BoilerM3 . При за- пуске OPC-сервер создаст соответ- ствующие им узлы (рис. 4, 5, 6). OPC- клиент может работать с объектами BoilerM1…BoilerM3 – вызывать их мето- ды, а также читать их атрибуты (за- пись напрямую недоступна). Заключение В статье с помощью технологии OPC UA выполнено ООП цифровых коммуни- каций с котельным оборудованием. Про- ведена декомпозиция задачи проекти- рования – представлена двухуровневая архитектура ПО: верхний уровень – тех- нологический алгоритм управления тепловыми процессами, нижний уро- вень – алгоритм непосредственного управления котельным оборудованием (драйвер устройства – котла). Техноло- гический алгоритм управления нахо- дится в контроллере, который является OPC-клиентом. OPC-сервер предостав- ляет сервис для работы с котлом OPC- клиенту. Клиент взаимодействует с объ- ектом, в который встроен драйвер котла. Объект на сервере представлен в виде узла типа Object . Данная декомпозиция упрощает про- грамму контроллера, так как сложный алгоритм управления оборудованием заменяется простой абстракцией, кото- рую предоставляет и поддерживает объект на OPC-сервере. Становится возможным раздельное проектирование: верхний и нижний уровни могут проектироваться разны- ми людьми, командами и даже органи- зациями. Также драйвер для оборудования мо- жет предоставляться самим произво- дителем. В данном случае особую акту- альность приобретает проблема отрас- левой стандартизации информацион- ных моделей. Также снижается общая трудоёмкость разработки, так как воз- можно переиспользование драйверов устройств в другом проекте. Наличие драйверного слоя повыша- ет надёжность и безопасность работы оборудования, так как технологиче- ский алгоритм управляет оборудова- нием не напрямую, а через посредни- ка – драйвер устройства, который обес- печивает корректное управление обо- рудованием и не допускает нарушения требований надёжности и безопасно- сти, даже если в технологическом алго- ритме допущены ошибки. Становится возможной «горячая» замена оборудо- вания, так как OPC-сервер поддержива- ет динамическое создание объектов (узлов). Технология OPC UA позволяет при- держиваться следующих принципов ООП: абстракция, иерархичность (на- следование, композиция), инкапсуля- ция и полиморфизм. Абстракция предназначена для упро- щения проектных решений, иерархич- ность – для упорядочивания абстрак- ций по уровням. В итоге это облегчает процесс проектирования. Всё много- образие котельного оборудования бы- ло упорядочено иерархически. Инкапсуляция предназначена для скрытия внутреннего устройства (реа- лизации) класса. Это позволяет легко и безболезненно менять реализацию – внесение изменений в драйвер котла прозрачно для технологического алго- ритма. Интерфейс, предоставляемый аб- стракцией, и полиморфизм позволяют использовать разнотипные объекты – изменение модели котла (типа объ- екта) не приводит к изменению техно- логического алгоритма. ООП – достаточно мощная парадигма проектирования, основанная на объ- ектной модели. Технология OPC UA под- держивает возможности полноценно- го объектно-ориентированного про- ектирования цифровых коммуника- ций промышленного оборудования. ● Литература 1. Mahnke W., Leitner S.-H., Damm M. OPC Unifi- ed Architecture. Berlin: Springer, 2009. 2. Буч Г., Максимчук Р.А., Энгл М.У. и др. Объ- ектно-ориентированный анализ и про- ектирование с примерами приложений. 3-е изд. / пер. с англ. М.: ООО «И.Д. Вильямс», 2008. 3. URL: http://opcfoundation.github.io/UA-.NE- TStandard. 4. URL: https://github.com/OPCFoundation/UA- ModelCompiler. Автор – сотрудник ФГБУН «Институт автоматики и электрометрии» СО РАН E-mail: neyzov.max@gmail.com СТА 3/2023 60 www.cta.ru НОУ - ХАУ Рис. 4. Узел котла модели М1 Рис. 6. Узел котла модели М3 Рис. 5. Узел котла модели М2