Статья посвящена подходам к организации пользовательских типов данных в проектах АСУ ТП. Автор делится практическими рекомендациями по разделению структур, работе с внешними данными и построению логики обмена.
- Настройки, уставки и режимы работ следует выносить в отдельную структуру, а не упаковывать всё в одну большую.
- Доступ к настройкам организуется через входную переменную функционального блока или ссылку на структуру с адресом в блоке инициализации.
- Операции выполняются только с внешними данными: во входные переменные пишутся внешние данные, напрямую к внутренним полям функционального блока обращаться нельзя.
- Output функционального блока формируется в одном месте — это правило подтверждается статическими анализаторами.
- Стоит отказаться от управления с верхнего уровня без прослойки: посредник принимает данные с визуализации, обрабатывает и передаёт в модель.
- Проверка получаемых данных должна выполняться как на стороне визуализации, так и на стороне ПЛК.
- структура
- функциональный блок
- Output
- ПЛК
Кому полезно: Инженерам АСУ ТП, разрабатывающим проекты и работающим со структурами данных
- Библиотека Qysche: XB6-P04A Pulse output module User Manual V1.15
- Статья Функциональный блок + METHOD в Codesys 3.5
- Статья Как один маленький функциональный блок влияет на обслуживание промышленного оборудования
Первоисточник: blog.engcore.ru
Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.
Полезный материал на нашем официальном Telegram канале https://t.me/asutp_best
Сегодня я бы хотел поговорить об организации структур или пользовательских типов данных, или составных типов данных и работы с ними.
У многих есть свои подходы, свои приемы. Что-то я поддерживаю, что-то считаю неправильным, но как по мне это очень плодотворная тема для обсуждения, так что я тут поделюсь кое какими выводами, считай что бест практис(нет)
Разделяйте структуры настроек и логики для объекта.
Не надо всё упаковывать в одну огромную структуру, чтоб потом искать способы работы с этим. Сейчас объясню на примере.
Выше вашему вниманию представлена типичная структура в типичном проекте и вот так делать не надо. Все что относится к таким вещам как настройки, уставки, режимы работ, выносите в отдельную структуру.
Для доступа к настройкам вы можете организовать либо входную переменную в функциональном блоке, либо в структуре с обычными параметрами просто укажите ссылку на эту структура и потом укажите адрес в блоке инициализации системы.
Производи операции только с внешними данными.
Во входные переменные мы можем указывать только внешние данные, писать мы можем только во внешние данные. Никогда не обращайтесь напрямую к внутренним данным функционального блока.
Например у нас есть функциональный блок с внутренним полем.
И мы хотим что-то сделать с этим внутренним полем. Некоторые среды разработки позволяют нам достучаться напрямую к этому полю, вот так делать не надо.
Формируй Output в структуре.
Вот тут стоит вспомнить великое правило.
OUTPUT функционального блока пишутся в одном месте
И будет вам и нам счастье. И чтобы вы понимали что это не моя фантазия, то вот вам немного от статических анализаторов.
Откажись от управления с верхнего уровня без прослойки.
Я понимаю, что очень удобно, в некоторых экосистемах, сразу подцеплять теги и управлять объектом напрямую, сам грешу таким же.
Но надо приучать себя к посреднику. Который бы забирал данные с верхнего уровня(визуализации), обрабатывал их, а уже потом отдавал в модель или дальше по логике.
Тут еще стоит отметить, что проверка получаемых данных должна происходить как на стороне визуализации, так и на стороне ПЛК.
Зачем?
Ну все это требуется, для обмена знаниями, подходами и обычный обмен опытом. Так как в среде АСУТП есть только материалы, как подключиться или как управлять чем-то, что в основном представляет собой пересказ мануала. Тут же я хочу затронуть более абстрактные темы.
Источник: https://blog.engcore.ru/2022/01/17/организация-работы-с-данными-в-проект/
