- В этой теме 34 ответа, 6 участников, последнее обновление 1 год назад сделано
.
-
Записи
-
«И то что Роснефть взяла у Михаила основу, натянута сверху свой WEB, и БД заменила на Influx. И спустила дочками на установку.
Вы думаете кто-то спрашивал про ГОСТ? 😂»
Можно поподробнее?Ну хорошо. Подробнее так подробнее.
Сижу я на работе. Никого не трогаю. Пью чай с козинаками. У нас задача вывести на верхний уровень узлы нефти. Вдруг приходит письмо о том, что в Сибинтек разработчики придумали свою систему БДРВ (база данных реального времени) и уже внедрили в нескольких сообществах.
Я такой: Блин… Нам такая тоже нужна. А то я складываю в MS SQL через KepServer v6, из Firebird написал перегрузчик данных, с Абак выгружаю отчеты через их приложение и после формирование отчета, эти данные записываются в SQL… А там у них и Modbus, и ODBC, база данных быстрая…
Вот бы посмотреть… Да кто ж нам даст в Мухосранск из Москвы… Да и кому писать…
В это время я ищу разные варианты… Попалась Rapid Scada, скачал, порисовал мнемосхемы через Silverlight, очень интересно, но не понятно… Удалил.
Проходит год, на газозавод в принудительном порядке подписывают на проект об внедрении БДРВ. Я такой ОПА! Можно и посмотреть и скомуниздить под мой проект с узлами нефти. Проблема с размерами баз данных исчезнет. Они уже за 2 года весили 120гб.
Идем на вебинар от разработчиков по обучению БДРВ. Там красивые картиночки, показано как в Visio можно рисовать схемы, потом сохранять в SVG и загружать на Web. А вот когда показали коммуникатор, то у меня в мозгу щелкнуло, что где — то я уже видел такие папки с такими же названиями и самое главное названиями библиотек KP*.
Закончилось обучение.
Начались этапы внедрения.
Из того что я помню как отче наш:
— Сервер Rapid крутился на Linux. Там же крутился Influx.
— Influx данные удалять не позволял т.к. разработчики писали данные через Get запросы Web-сервиса.
— Коммуникатор при пропажи связи с сервером историю тегов сохранял локально, при восстановление связи с Сервером передавал данные. !Я, кстати, не знаю умеет ли так делать оригинальный коммуникатор или нет.
— Создавать теги в веб-форме — 1 адрес Регистра = 1 тег — мама роди меня обратно! До сих пор с ужасом вспоминаю.
— Проект Xml с проектами драйверов генерировал Web c номером версии. И если при загрузке коммуникатор по ссылке видел файл с новой версией, то по другой ссылке он скачивал архив zip, распаковывал проект и дальше использовал новые конфиги.
— Самая вишенка. Расчёт часовых и суточных. На заводе были контроллеры ABB, Siemens и УВП-280. Москва и разработчики БДРВ требовали, чтобы часовки на устройствах появлялись ровно в 00 минут. А там часы то спешат, то опаздывают. Сервера синхронизации времени нет. Решили на всех контролерах перевести на 5 минут назад, чтобы на контроллере было 14:00, в жизни 13:55, и пока он формирует отчет или время уходит вперёд потихоньку, то в 13:57 часовой отчет готов и цифра попадает правильно. Но! Чем больше становилось тегов, а приходилось для каждого тега использовать формулу пересчёта, то уже на 5000 теле, скрипты пересчёта переставали успевать и на контроллере двухчасовка уже есть, а в influx перерасчитаная часовка появляется на 3 или 5 минуте… При этом тег рандомный естественно. Разработчики запилили отдельный сервис, который часовки и суточные пересчитывались.
Естественно заказчик матерился… Грубо говоря заплатили 100 млн, обещали 500000 тегов обработки, а он уже на 5000 не успевает. За что заплачено?Может ещё что вспомню.
Что вспомнил. Первая версия коммуникатора у них была 2017 года версия 5.0.0.1. Там стандартный О программе были заменен на корявый.
На заводе мы участвовали в проекте 2021 году.
Ещё у коммуникатора помимо папки Config была папка Config.Out, оттуда сайт забирал актуальные версию коммуникатора.Хм, а вот тут тоже подробнее про всего 5000 тегов и тупняк при пересчёте.
Китаец тут недавно жаловался на подобное 😀Но в моем случае версия 5 была.
Про китайца на английском форуме я тоже читал.
Просто для пояснения.
Как происходит.
Коммуникатор записывает данные в influx напрямую в Influx через Get запрос web сервиса.
Сервер Rapid делает запрос в influx, выдергивает теги, рассчитывает и заново записывает.Двойная работа? я вот смотрю, что много примитивных расчетов можно и нужно возлагать на драйвера, те же приведения поделить на 100, умножить при команде и т.д.
В том числе и для драйвера Modbus.Для однотипных устройств достаточно в большинстве случаев. И меньше всяких формул в каналах.
Зачем драйверу то считать? Его дело данные принять… А то ведь может и не успеть. С расчетами пусть дальше система разбирается…
@a80808 с множителями драйвер все прекрасно успевает, потому что кроме принятия данных у него есть и отправка в Сервер. Как раз при которой можно применить формулу.
Так же и при получении данных он может выполнить обратные действия, которые и так всегда есть, потому что БД у нас double, а регистр прибора у нас предположим int.Лично меня начинают бесить Cnl/100, Cmd*100 и так далее 🙂
Без обид, но все эти примитивы можно и очень нужно сплавлять в драйвер.Меньше портянка каналов с формулами.
И мое личное мнение — для Scada БД в чистом виде давно устарели, если можно так выразиться. ни реляционные, ни БДВР в чистоте давно не подходят в нынешних реалиях, и ситуацию будет со временем ухудшаться от объема данных.
Тут гибрид нужен, Графовая — Реляционная — БДРВ. Кто бы придумал? 🙂
Просто надо сделать многоуровневое хранение. Уровень драйверов — БДРВ с небольшой глубиной хранения (возможно текущие и предыдущее), далее уже Реляционная. А вот что такое Графовая я не знаю (((
Вот тут возможно и для драйвера расчетная работа. Т.е. Приемная часть приняла данные и положила как есть в БДРВ. Расчетная часть взяла из БДРВ (или напрямую), нормировала, обсчитала и положила в РБД.
Графовая позволяет добавлять сущности, в отличии от реляционных и БДВР…
Скажем так она больше подходит не для данных от приборов, а для разработки проекта.
Имея набор предопределенных параметров, позволяет еще добавлять параметры.
+ она создает связи между другими объектами.Вроде как и РБД с этим справляется, но добавлять таблицы это еще надо ее научить.
Ну и нельзя в существующие таблицы добавить параметры без изменения кода в принципе.
Собственно чего стоило добавить параметры в существующие таблицы при переходе с 5-й на 6-ю версию как пример.
- Для ответа в этой теме необходимо авторизоваться.