- В этой теме 66 ответов, 4 участника, последнее обновление 4 года, 9 месяцев назад сделано
.
-
Сообщения
-
Причем точки сбора (коммуникаторы) разбросаны по цехам где-то беспроводка, где-то телефонный кабель, где-то радио антенна в шахтных условиях ситуация еще тяжелее. Поэтому кэширование между коммуникатором и сервером (RS) это необходимость, особенно для горно металлургических предприятии. Обычно подобных предпринятых сложно поддерживать сетевую инфраструктуру из-за масштаба, там только-только осознает необходимость вложения в IT инфраструктуру.
Может проще сделать драйвер для подключения к другому серверу RapidScada через API? Будете делать выборку текущих данных и архивов нужных Вам каналов с каждого экземпляра. Поставить частоту архивирования в минутном срезе раз в секунду в подчинённых экземплярах .
Может проще сделать драйвер для подключения к другому серверу RapidScada через API? Будете делать выборку текущих данных и архивов нужных Вам каналов с каждого экземпляра. Поставить частоту архивирования в минутном срезе раз в секунду в подчинённых экземплярах .
но это то же что и быстрый шлюз но в обратном направлении, если будет доработка шлюза мы так и сделаем, но придется каждый раз покупать
Ну это не совсем тоже самое. Вы жёстко не завязаны на номера каналов. И достаточно одного драйвера для главного сервера.
Причем точки сбора (коммуникаторы) разбросаны по цехам где-то беспроводка, где-то телефонный кабель, где-то радио антенна в шахтных условиях ситуация еще тяжелее. Поэтому кэширование между коммуникатором и сервером (RS) это необходимость, особенно для горно металлургических предприятии.
Почему на точках сбора ставятся компьютеры с Коммуникатором, а не аппаратный шлюз типа Moxa Nport?
Также хочется понять, временная ли такая ситуация или она сохранится в течение длительного времени?
Может быть здесь будет оптимально другое решение, например, сделать отдельное приложение для кэширования, которое поставить вместе с Коммуникатором, чтобы не перегружать Коммуникатор функционалом, используемым лишь в отдельных случаях.Отличие от RapidScada в том, что теги имеют текстовое обозначение и благодаря правилам кодирования, они для каждого филиала всегда уникальны. В RapidScada этого можно добиться наверное только распределив кому какой диапазон номеров каналов использовать.
Можно обсудить в отдельной теме. Интересный вопрос.
тут полнота и достоверность играет важную роль, так-как каждый час простоя обходиться в несколько тысячи долларов. Будет плохо если из-за отсутствия данных мы рисуем недостоверную картину
Уверен, что в процессе совместной работы, решим вопрос гарантированной доставки данных.
но это то же что и быстрый шлюз но в обратном направлении, если будет доработка шлюза мы так и сделаем, но придется каждый раз покупать
Вопрос с покупкой решаемый. Тут более важен вопрос архитектуры. Если полная Rapid SCADA не нужна на точках сбора, то случше её и не ставить, чтобы минимизировать обслуживание. Но как я написал выше, нужны ли вообще ПК даже с Коммуникатором на точках сбора?
Почему на точках сбора ставятся компьютеры с Коммуникатором, а не аппаратный шлюз типа Moxa Nport?
Во первых это компьютеры не только для коммуникаторов, обычно это АРМ оператора где крутится и другие системы, во вторых при аппаратном шлюзе качество связи никуда не денется, наоборот появляется больше риска потери данных.
Если компьютер только для коммуникатора, то уместно было бы поставить малинку, но у нас нету опыта …
Ну это не совсем тоже самое. Вы жёстко не завязаны на номера каналов. И достаточно одного драйвера для главного сервера.
да, это было круто …
мы бы хотели сделать timeline статус оборудования
еще есть задача моточасы (грубый расчет), но мы не беремся реализовать подобные задачи на RS из-за этой проблемы (кэширование между коммуникатором и сервером RS)
Ну на Малинку можно вкорячить и всю Scada. Вот только сложность со шлюзами, они гонят из подчиненной в главную все скопом без возможности выбора и главное направления.
типа эти каналы передаем а эти нет. И то, что передаем должны положить в такие-то каналы а не в те же самые, на которых настроена подчиненная Scada/p.s. Особо большого опыта не надо, небольшого работы с Linux хватит.
Во первых это компьютеры не только для коммуникаторов, обычно это АРМ оператора где крутится и другие системы, во вторых при аппаратном шлюзе качество связи никуда не денется, наоборот появляется больше риска потери данных.
Да, в такой ситуации кэш на Коммуникаторе имеет большое значение. В то же время полностью Rapid SCADA нет смысла ставить на АРМ, т.к. будет сложнее поддерживать все приложения, архив и конфигурацию. Напишу для Вас предложение по реализации кэша на Коммуникатор.
- Вы должны авторизироваться для ответа в этой теме.