Использование скады не по назначению

[Teodor]

Есть задача (пока теоретическая) собрать и логировать данные с нескольких сотен электрических счетчиков(через разные ОРС), с последующей передачей уже перепакованных данных в глобальную скаду. То-есть, фактически, я хочу вашу скаду попользовать именно в к-ве софтового контроллера, чего вы так не любите

Насколько вы видите такое использование реальным?
Задача сводится к записи полученных регистров в БД и отправке их в другую скаду, но уже в ужатом виде (у ханивела точки дико дорогие).
Если есть такая возможность, то организовать доступ к конкретным данным для конкретных юзеров (вопрос в к-ве клиентов, которые могут подключиться и забыть отключиться). Есть ли возможноть насильно отключать клиентов через 5-10 минут.

[Simple-Scada]

хочу вашу скаду попользовать именно в к-ве софтового контроллера, чего вы так не любите... Насколько вы видите такое использование реальным?

Это точно . В принципе это вполне реально, но если скорость не критична, ведь данные идут в БД не сразу. Как мы поняли должно получиться так: данные берутся с OPC-сервера, пакуются средствами скриптов скады и упакованные теги идут в архив БД. Затем другая скада достает данные из БД и работает с ними как угодно. Скада при архивации сначала накапливает данные в буферы и оптимизирует их, поэтому данные не сразу идут в БД, а каждые 10 минут (для основного слоя), поэтому постоянно брать актуальные данные из БД не получится и придется дожидаться их добавления в БД.

Производительность при этом во многом будет зависеть от скорости жесткого диска и общей производительности компьютера и от количества упаковываемых тегов и частоты записи этих тегов в архив.

Есть ли возможноть насильно отключать клиентов через 5-10 минут.

Принудительно отключать нельзя, можно только ограничить доступ к серверу по IP или паролю через Options.exe. А для чего? Ведь если другая скада будет брать данные из БД, то Simple-Scada по сути с ней не будет связана и сервер Simple-Scada можно оставить без клиентов, просто активировать проект, чтобы шла упаковка тегов и запись в БД. Или нужно ещё чтобы обычные клиенты периодически работали со скадой?

[Teodor]

Я, видимо, неправильно выразился. Данные в другую скаду уходят назад модбас регистрами через ОРС. Но, в виду дикой цены регистра, тут они будут паковаться в виде "данные счетчика Х" При получении подтверждения считывания, в те-же регистры "данные счетчика Х+1" и т.д. Там в зависимости от Х данные уходят во внутренние переменные. Так за пару минут подробные данные ВСЕХ счетчиков уйдут десятком-вторым регистров. В то же время оперативные данные идут своими регистрами, но только они.

БД - это другая история. Она даст возможность смотреть логи "хозяевам" конкретных счетчиков, которые к скаде 2 доступа и отношения в принципе не имеют. Брать для этого лицензию на 100 рабочих мест - тупо. Тогда проще будет что-то на вебе сварганить. Но, если клиента можно пнуть, то и одного места хватит. Т.к. Не будут-же они все вместе ломиться.

Грубо говоря есть ТЦ и электросчетчики в нем с МВТСР и MBRTU. Cкада ТЦ, вещь в себе, но для контроля общего потребления и поиска "потерь" данные там должны быть.  Логи и контроль пользователями - совсем другой уровень и другие права. Рассматриваются 2 решения. Железное и софтовое. Железо - это очень хорошо, но там все то что тут уже прописано, надо реализовывать самому, а это не радует.

[Teodor]

Если можно еще один глупый вопрос... А какое количество "Активных тегов" является еще вменяемым? У меня их в проекте уже 4 700... Будет около 7 000.  Следующий еще больше будет. Там за 10 000 перевалит. Это еще в рамках нормы?

[Simple-Scada]

Если можно еще один глупый вопрос... А какое количество "Активных тегов" является еще вменяемым?

Это напрямую зависит от производительности компьютера-сервера и следующих факторов:

• производительности OPC-сервера;
• частоты опроса OPC-тегов;
• количества архивируемых тегов, частоты их архивации и производительности СУБД;
• количества скриптов (OnDataChange и Таймеров) и частоты их выполнения;
• от скорости сети (если используется подключение к серверу через клиенты);

На практике мы внедрили несколько крупных проектов. Один из них на 8000 тегов, информация собирается с 22 контроллеров Schneider Electric и 4 контроллеров Siemens S-300, через OPC-сервер KepServerEx. Проект включает 42 мненосхемы (около 14 тыс. объектов в сумме на всех мнемосхемах и окнах), 279 окон, 163 сообщения. Скриптов всего 28, но почти все универсальные и используются большим количеством объектов, поэтому выполняются часто. Архивируется 1200 переменных в MySQL, по большей части с частотой 5-10 секунд. Клиентских компьютеров - 10 штук, все подключены к одной сети (100Mb). Проект работает по сезонам (по пол года) в круглосуточном режиме. На данный момент отработал 3 сезона без сбоев, с ощутимым запасом производительности.

В качестве сервера использовали средний по производительности компьютер, 4 Гб. оперативной памяти (DDR3), видеокарта Asus за 3 тыс. рублей., процессор Core-i5 (в работе задействуется на 10-15% максимум), жесткий диск со скоростью 7200 rpm. Проект запускается за 4 секунды (не считая времени подключения OPC-сервера к устройствам). За девять секунд, если ждать пока OPC-сервер подключится и вернет данные.

Также уже несколько пользователей используют Simple-Scada 2 около года в проектах от 10000 тегов. Один из них на 15000 тегов, также с KepServer'ом. Архивируется 3500 переменных в MySQL, частота архивации 5 секунд и чаще (на компьютере-сервере используется рейд массив из двух жестких дисков). Проблем с производительностью не возникало.