Ответы в темах
-
Записи
-
Ну это не совсем тоже самое. Вы жёстко не завязаны на номера каналов. И достаточно одного драйвера для главного сервера.
да, это было круто …
Почему на точках сбора ставятся компьютеры с Коммуникатором, а не аппаратный шлюз типа Moxa Nport?
Во первых это компьютеры не только для коммуникаторов, обычно это АРМ оператора где крутится и другие системы, во вторых при аппаратном шлюзе качество связи никуда не денется, наоборот появляется больше риска потери данных.
Если компьютер только для коммуникатора, то уместно было бы поставить малинку, но у нас нету опыта …
Может проще сделать драйвер для подключения к другому серверу RapidScada через API? Будете делать выборку текущих данных и архивов нужных Вам каналов с каждого экземпляра. Поставить частоту архивирования в минутном срезе раз в секунду в подчинённых экземплярах .
но это то же что и быстрый шлюз но в обратном направлении, если будет доработка шлюза мы так и сделаем, но придется каждый раз покупать
Причем точки сбора (коммуникаторы) разбросаны по цехам где-то беспроводка, где-то телефонный кабель, где-то радио антенна в шахтных условиях ситуация еще тяжелее. Поэтому кэширование между коммуникатором и сервером (RS) это необходимость, особенно для горно металлургических предприятии. Обычно подобных предпринятых сложно поддерживать сетевую инфраструктуру из-за масштаба, там только-только осознает необходимость вложения в IT инфраструктуру.
Если работа происходит на одном компьютере, это всё равно, что объединить 2 программы, Сервер и Коммуникатор в одну.
у нас коммуникаторы всегда отдельно от сервера, на данный момент сбор данных производится с 9-ти точек
При выкачивании архивов из приборов учёта гарантированность доставки обеспечивается тем, что архивы из прибора не удаляются. В случае прерывания скачивания, скачивание возобновляется с того же места.
У нас в основном не приборы учёта а состояние оборудование.
Получается, единственный выход это везде поставить быстрый шлюз
IF (@CnlNum = 270) then
INSERT INTO cnldata (datetime, cnlnum, val, stat) VALUES (@dateTime, @cnlnum, @val, @stat);
END IF;в эпоху BigDATA каждая информация на счету, даже оперативные данные нужны для дальнейший аналитики …
Может то, что вы пишете тут важно, но я совсем не это имел ввиду, про счетчики сказал чисто для примера.
То что я хочу видеть, это — универсальный механизм кэширование, в независимости от источника данных с единственной целю — сохранность важных данных, если сервер не отвечает.
— Кэширование начинается только в том случае если сервер не отвечает
— Кэширование работает принципу кольцевой записи, как бы пробка данных когда сервер на отвечает. Если это длится долго, то начинается удалиться записи по принципу FIFO только не OUT а DELTE
— Количество записи для кэширование, если указано 1000, то журнал запоминает последние 1000 записей для каждого канала или укажем просто размер файла кэша 10Mb
— Фильтр, какие каналы кэшировать
— Интенсивность, например опрос идет с интервалом 1 сек, но кэшировать каждый мин
— После восстановление связи и передачи всех данных журнал удаляетсяЕсли данные дальше передается в другой сервер, то за кэширование отвечает сам быстрый шлюз. При передаче данных в БД за кэширование отвечает модуль экспорта в БД
