- В этой теме 66 ответов, 4 участника, последнее обновление 4 года, 10 месяцев назад сделано
.
-
Сообщения
-
хм, надо запустить свой 236-й Меркурий в работу, посмотреть что там вообще с архивами. Просто читать их даже раз в сутки как-то глупо. Можно конечно, но надо понять как эти данные вести в обход минутных срезов, там они точно не нужны.
Если поможете разобраться, то я прикручу чтение архивов в драйвере. Все равно собирался им заняться, чтобы облагородить 🙂Не получится вести данные в обход минутных срезов. Если канал заведён, то он существует во всех срезах. Здесь что-то изменить можно только механизмами в самой скаде, то есть что-то типа свойства канала «не архивировать». Допустим у нас в скаде (не Rapid) это сделано в виде шаблонов архивирования, которые присваиваются тегам. В самом шаблоне мы уже прописываем как архивировать (текущее, среднее, сумма) и в какие периоды (секунда, минута, 5 минут, час, день, месяц, год). Т.е. если мне нужно экономить место, я могу очень гибко настроить архив. Плюс разные величины архивируются по разному. Допустим давление пишется среднее во всех срезах, а расход средний до часового архива, а дальше идёт сумма (за сутки, месяц, год).
Вот я о том и говорю, заводить кучу бесполезных в рабочем режиме данных глупо.
Пока что выход за счет того, что некоторые данные можно изменить на Windows в Коммуникаторе.
Но другая часть все равно занимает место, например потребленная электроэнергия, часто достаточно раз в час снимать данные, что можно сделать с некоторой оговоркой, но в минутных срезах вся эта однотипная пачка будет все равно храниться…Не получится вести данные в обход минутных срезов. Если канал заведён, то он существует во всех срезах. Здесь что-то изменить можно только механизмами в самой скаде
Это так.
Может то, что вы пишете тут важно, но я совсем не это имел ввиду, про счетчики сказал чисто для примера.
То что я хочу видеть, это — универсальный механизм кэширование, в независимости от источника данных с единственной целю — сохранность важных данных, если сервер не отвечает.
— Кэширование начинается только в том случае если сервер не отвечает
— Кэширование работает принципу кольцевой записи, как бы пробка данных когда сервер на отвечает. Если это длится долго, то начинается удалиться записи по принципу FIFO только не OUT а DELTE
— Количество записи для кэширование, если указано 1000, то журнал запоминает последние 1000 записей для каждого канала или укажем просто размер файла кэша 10Mb
— Фильтр, какие каналы кэшировать
— Интенсивность, например опрос идет с интервалом 1 сек, но кэшировать каждый мин
— После восстановление связи и передачи всех данных журнал удаляетсяЕсли данные дальше передается в другой сервер, то за кэширование отвечает сам быстрый шлюз. При передаче данных в БД за кэширование отвечает модуль экспорта в БД
в эпоху BigDATA каждая информация на счету, даже оперативные данные нужны для дальнейший аналитики …
Для Быстрого шлюза:
По поводу организации очереди согласен, что текущий вариант с её переполнением не оптимален. Хочу развить и несколько модифицировать Вашу идею.В настоящее время модуль Быстрый шлюз передаёт текущие данных по мере их поступления (обычно от Коммуникатора).
— Достаточно в кэше хранить номера каналов, текущие данные которых ещё не переданы, а также метку времени для определения устаревших данных, чтобы ограничить размер кэша.
— Периодически записывать кэш в файл. В случае перезапуска Сервера загрузить кэш и взять данные по номерам каналов из текущего среза и добавить в очередь на передачу.
— Если Сервер был остановлен на длительное время, текущие данные не передавать.
— Определять и сохранять в файл период отсутствия связи, чтобы после восстановления закачать архив минутных данных.P.S. Возможно, с точки зрения быстродействия, лучше оставить простую очередь с очисткой «хвоста». На момент реализации нужно будет проанализировать.
Для модуля эспорта в БД:
— Очередь текущих данных нужна с метками времени. В настройках модуля указать отдельные SQL-запросы по обработке данных в случае восстановления связи. Эти запросы могут отличаться от запросов в обычном режиме.
— Если очередь переполняется, то удалять из неё наиболее старые записи.
— Запись кэша в файл с заданным периодом.размер файла кэша 10Mb
Размер файла неудобно контролировать. На мой взгляд, лучше указывать количество записей в кэше. Размер является следствием и зависит от количества записей и формата вывода в файл.
Хотя это тоже зависит от подхода:
1. Дописывать каждую новую запись в конец файла. Когда файл достиг заданного размера начинать 2-й файл. Когда 2-й файл достиг размера, затирается 1-й файл. И так по кругу.
2. Хранить кэш в памяти и периодически скидывать его снимок на диск целиком, в том числе при остановке службы Сервера.1-й вариант гарантирует доставку всех данных.
2-й вариант быстрее, если скидывать на диск не часто.
Кроме того, нужно учитывать, если мы ведём экспорт в несколько БД, то у каждой своя очередь и кэш. Работа может существенно замедлиться из-за записи на диск.Интенсивность, например опрос идет с интервалом 1 сек, но кэшировать каждый мин
Чтобы не было путаницы, лучше, чтобы очередь данных содержала то же самое, что кэш. Данный вопрос можно решить параметром настройки, который определяет, что текущие данные добавляются в очередь (и кэш) с заданным интервалом.
Так Коммуникатор вообще ничего не хранит, у него даже очереди нет. Принял от устройства — и сразу передал Серверу.
Если работа происходит на одном компьютере, это всё равно, что объединить 2 программы, Сервер и Коммуникатор в одну.При выкачивании архивов из приборов учёта гарантированность доставки обеспечивается тем, что архивы из прибора не удаляются. В случае прерывания скачивания, скачивание возобновляется с того же места.
При запросе текущих данных, они записываются в файл текущих данных сразу после получения.
Вставлю свои пять копеек. Со счётчикам мы правда далеко ушли от темы. Опишу как устроен механизм передачи данных у нас, может что пригодится.
В разных филиалах установлены однотипные scada, которые работают и настраиваются независимо друг от друга. Отличие от RapidScada в том, что теги имеют текстовое обозначение и благодаря правилам кодирования, они для каждого филиала всегда уникальны. В RapidScada этого можно добиться наверное только распределив кому какой диапазон номеров каналов использовать.
Далее, если я хочу передавать информацию в другой филиал, то делаю экспорт конфигурации нужных тегов(каналов в RapidScada), а в другом филиале эту конфигурацию импортируют. Таким образом, часть тегов у нас получается полностью идентичная. Далее тем тегам, которые я буду передавать, в базе присваиваю шаблон передачи данных. В шаблоне прописывается источник (мой сервер), приемники (сервера в которые я хочу отдавать) и срезы (текущие, минутные или часовые и т.д.) которые нужно отправлять.
После этого сервер начинает автоматически по мере появления данных их передавать. Паралельно я могу точно также получать данные от других филиалов, но соответственно в другие теги. Кроме того мой сервер может быть посредником, принимать данные от одного филиала и передавать их в другой. Применяется когда они не могут взаимодействовать напрямую.
В случае если происходит обрыв связи, передающий сервер начинает складывать данные в кэш с ёмкостью в несколько миллионов записей. После восстановления связи пропущенные данные автоматически передаются из кэша.
Если потеря связи продолжительна, в кэше самые старые записи начинают затираться при поступлении новых. При восстановлении связи, если кэш не смог вместить все без потерь, принимающий сервер может вручную дать команду на загрузку нужного диапазона данных напрямую из передающего сервера. Таким образом, данные всегда будут полные.
Естественно текущие данные в системе тоже архивируются в секундном срезе, поэтому их можно вытащить из БД.Если работа происходит на одном компьютере, это всё равно, что объединить 2 программы, Сервер и Коммуникатор в одну.
у нас коммуникаторы всегда отдельно от сервера, на данный момент сбор данных производится с 9-ти точек
При выкачивании архивов из приборов учёта гарантированность доставки обеспечивается тем, что архивы из прибора не удаляются. В случае прерывания скачивания, скачивание возобновляется с того же места.
У нас в основном не приборы учёта а состояние оборудование.
Получается, единственный выход это везде поставить быстрый шлюз
- Вы должны авторизироваться для ответа в этой теме.