Архитектура промышленного архива данных: локальный сбор или сбор на сервере

Почему важна архитектура системы сбора истории?

Системы промышленной автоматизации непрерывно генерируют потоки измерений, состояний оборудования, аварийных сигналов и производственных событий. Эти записи помогают инженерам расследовать отказы, проверять условия процесса и оценивать работу оборудования.

Однако сбор данных сам по себе не гарантирует полноту и полезность исторических записей. Перебои в сети, техническое обслуживание серверов, ограниченный объём хранилища и неподходящие настройки сбора могут приводить к пробелам.

Выбор между системой сбора истории на уровне машины и серверной системой следует начинать с определения предполагаемого применения. Каждая архитектура отвечает разным требованиям к сбору, хранению и анализу данных.

Система сбора истории на уровне машины собирает подробные сведения непосредственно рядом с производственным оборудованием. Серверная система сбора истории объединяет записи из нескольких источников и позволяет проводить более широкий анализ.

Что такое система сбора истории на уровне машины?

Система сбора истории на уровне машины собирает и хранит временные ряды данных рядом с отдельной машиной, производственной ячейкой или системой управления. В зависимости от реализации она может получать данные от ПЛК и поддерживаемых промышленных сетей. К распространённым источникам данных относятся контроллеры, такие как ПЛК-контроллер Allen-Bradley 1756-L1 ControlLogix и модуль ПЛК-контроллера Siemens 6ES7214.

Такая схема полезна, когда инженерам нужны подробные записи событий, предшествовавших остановке, неисправности оборудования или неожиданной последовательности событий и последовавших за ними.

• Диагностика оборудования: Сохранять выбранные значения контроллера до и после сбоев и остановок производства.
• Прослеживаемость: Связывать измерения процесса с производственными циклами, партиями или отдельными изделиями.
• Проверка процессов: Сохранять записи, используемые для проверки соответствия рабочих условий заданным требованиям.
• Локальный сбор данных: Снизить зависимость от постоянной связи с удалённым сервером системы сбора истории.

Локальный сбор данных может повысить отказоустойчивость при недоступности вышестоящего сервера или сетевого подключения. Однако это преимущество зависит от фактической архитектуры системы сбора истории и доступного объёма хранилища.

Инженерам необходимо проверить емкость для хранения данных, способы их экспорта, производительность сбора и поведение системы при восстановлении. Локальное хранение не исключает все возможные виды сбоев.

Что такое архиватор данных на сервере?

Архиватор данных на сервере собирает историческую информацию с нескольких производственных объектов и других поддерживаемых источников данных. Обычно он предоставляет более широкие возможности для составления отчетов, построения трендов, хранения и анализа данных.

Инженеры предприятия могут сравнивать производительность оборудования, выявлять повторяющиеся причины снижения выпуска и сопоставлять технологические измерения разных машин.

Централизованные архиваторы также поддерживают приложения, объединяющие эксплуатационные данные с производственной и деловой информацией. Это помогает сопоставлять работу технологического процесса с производственными графиками, партиями продукции и результатами контроля качества.

Однако путь сбора данных создает дополнительные зависимости. Сбои сети, обслуживание сервера, проблемы с интерфейсами и ограничения хранилища могут прервать сбор данных. Подключение на уровне оборудования часто осуществляется через модули связи Ethernet, такие как модуль связи Ethernet Yokogawa ALE111-S51, модуль связи Ethernet Schneider 140NOE21100 или модуль связи Ethernet Foxboro FBM232, поэтому их конфигурация и состояние важны для ведения записей.

Не следует считать, что каждый архиватор данных автоматически буферизует данные при сбое. Уточните, поддерживает ли буферизацию конкретный сборщик данных, как долго он хранит ожидающие записи и как обрабатывает восстановление.

Чем отличаются эти две архитектуры?

Это общие архитектурные тенденции, а не универсальные гарантии продукта. Прежде чем окончательно утверждать проект, проверьте поведение выбранной платформы.

Как выбрать подходящую историческую систему?

На какой инженерный вопрос должны отвечать данные?

Сначала определите, какие решения должны основываться на исторических данных. Для расследования неисправности могут потребоваться записи с высоким разрешением за короткий период вокруг события. Для анализа производства может понадобиться более длительное хранение и согласованные данные по нескольким объектам.

Задокументируйте необходимые теги, интервалы сбора, условия регистрации событий, точность временных меток, срок хранения и требования к отчётности.

На каких участках пути сбора данных возможна их потеря?

Проследите путь сбора данных от каждого контроллера до места хранения. Определите сетевые коммутаторы, шлюзы, службы сбора данных, серверы и другие компоненты, из-за которых запись может прерваться.

Уточните, что происходит при сбое сети, перезагрузке сервера или плановом обслуживании. Убедитесь, что данные остаются в локальном буфере и система может восстановить пропущенные интервалы после возобновления работы.

Сколько места для хранения требуется?

Оцените объём хранилища с учётом количества точек, частоты сбора, размера записей, эффективности сжатия и требуемого срока хранения. Учтите эксплуатационные накладные расходы и предусмотрите достаточный запас ёмкости.

Не рассчитывайте объём хранилища только по количеству тегов. Две системы с одинаковым количеством тегов могут генерировать разные объёмы данных из-за настроек сбора и особенностей технологического процесса.

Согласованы ли временные метки и понятен ли их смысл?

Анализ исторических данных становится менее надёжным, если связанные записи используют несинхронизированные часы или источники временных меток, смысл которых неясен. Проверьте синхронизацию времени контроллеров, сборщиков данных и серверов.

Определите, обозначают ли временные метки момент получения данных источником, их сбора или приёма сервером. Это различие важно при восстановлении порядка событий, произошедших с небольшим интервалом.

Обеспечены ли кибербезопасность и восстановление?

Проверьте аутентификацию, контроль доступа, сегментацию сети, управление исправлениями, процедуры резервного копирования и тестирование восстановления. Историческая система может содержать ценную оперативную информацию, поэтому её следует надлежащим образом защищать.

Проверьте фактический процесс восстановления. Резервная копия полезна, только если необходимые данные и конфигурацию можно восстановить в допустимые сроки.

Когда следует сочетать локальный и централизованный сбор данных?

В некоторых случаях полезны обе архитектуры. Архиватор на уровне оборудования может сохранять подробные записи рядом с ним, а архиватор на сервере — объединять выбранные данные для анализа всего предприятия.

Например, производственной линии на базе таких контроллеров, как модуль ПЛК-контроллера GE Mark VIe IS400AEBMH3A, могут понадобиться подробные записи событий для диагностики неисправностей и централизованные истории партий для проверки качества. Локальное хранение и централизованное агрегирование данных вместе отвечают этим требованиям.

Тщательно продумайте механизм передачи данных. Определите, какие записи передаются на верхний уровень, как сохраняются временные метки, как обрабатываются дубликаты и что происходит при прерывании связи.

Также проверьте, сохраняют ли локальная и центральная системы одинаковую степень детализации. Агрегирование или сжатие могут изменить информацию, доступную для последующих расследований.

Что следует включить в контрольный список ввода в эксплуатацию и обслуживания?

• Убедитесь, что данные необходимых тегов контроллера собираются.
• Сравните значения в архиваторе с достоверными исходными значениями.
• Подтвердите интервалы сбора данных и поведение при срабатывании событий.
• Проверьте синхронизацию времени на соответствующих устройствах.
• Проверьте поведение системы при сетевых сбоях и восстановлении связи.
• Проверьте ёмкость хранилища, политики хранения и ротацию архивов.
• Проверьте средства контроля доступа, резервное копирование и процедуры восстановления.
• Задокументируйте пути сбора данных и ответственных за каждый компонент.

Зафиксируйте результаты испытаний и критерии приёмки. Повторяйте важные проверки после существенных изменений сети, контроллера или конфигурации архиватора.

Заключение: превращение исторических данных в надёжный инженерный ресурс

Выбирайте промышленный архиватор данных с учётом того, какие свидетельства необходимо сохранять и какие решения должны опираться на эти данные. Локальный сбор полезен для подробной диагностики оборудования, а сбор на сервере обеспечивает более широкую отчётность и анализ нескольких объектов. Сочетание обоих подходов может дать взаимодополняющие преимущества, если тщательно продумать передачу, хранение и восстановление данных. До внедрения задокументируйте требования к данным, проверьте поведение системы при сбоях, подтвердите точность временных меток и убедитесь, что резервные копии можно восстановить. Эти шаги помогут превратить исторические данные в надёжный инженерный ресурс.