Показания счетчиков по сети

[DirectRaw]

Приветствую, Уважаемые!
У Компании множество филиалов в нескольких городах. Между филиалами VPN. Требуется снимать показания счетчиком «Энергомера 303» во всех филиалах и отправлять в центральный офис для обработки на ТМ.
В голову приходят два варианта:
1) В филиале ставить преобразователь из RS232/485 в Ethernet, маршрутизировать на такой же преобразователь в центральном офисе и в COM-порт сервера. Но, так как общее количество счетчиков порядка 500, придется ставить много преобразователей. И к тому же на один COM-порт сервера очень большая нагрузка.
Можно ли преобразованный сигнал (RS232-Ethernrt) сразу завести в сервер, а там программно вытащить данные из пакетов и обработать?
2) В филиалах подключать счетчики непосредственно к местным серверам, а потом каким то образов центральный сервер будет эти данные собирать и обрабатывать. TM так может?
Или может быть есть еще какие то варианты?
Буду очень признателен за совет.
Заранее спасибо!

[alex_ugrumov]

1) В филиале ставить преобразователь из RS232/485 в Ethernet, маршрутизировать на такой же преобразователь в центральном офисе и в COM-порт сервера. Но, так как общее количество счетчиков порядка 500, придется ставить много преобразователей. И к тому же на один COM-порт сервера очень большая нагрузка.
Можно ли преобразованный сигнал (RS232-Ethernrt) сразу завести в сервер, а там программно вытащить данные из пакетов и обработать?
Заранее спасибо!

Да конечно можно. Скажу за MOXA. У них есть RealCOM Driver для Windows и RealTTY Device для *nix (но нужно уточнить для конкретной ОС). Только есть такой момент. Про *nix не помню, а вот для Windows точно есть ограничение максимального числа СОМ портов на одном ПК - 256 (или вообще 128).
Чтобы это работало (да и в случае двух преобразователей на канал) удалённые устройства и сервер д.б. в одной IP сети.

2) В филиалах подключать счетчики непосредственно к местным серверам, а потом каким то образов центральный сервер будет эти данные собирать и обрабатывать. TM так может?
Заранее спасибо!

Да должна мочь... MasterSCADA точно может (но опять же в одной IP сети. если сети разные - нужно уточнять). Такое решение лучше, если Вам критично иметь картину потребления при пропадании, а потом восстановлении связи с филиалом, за период отсутствия связи. Если счётчик умеет отдавать исторические данные, а серверная часть может их принимать и складывать в архивную БД с правильными метками времени, то такой проблемы нет и при отсутствии локальных серверов.

Система-то технического учёта? Если коммерческая история, то у сбытовых есть свой взгляд на организацию этого дела.

[Dmitry Isaev]

при организации АИИС КУЭ в данных случаях подключаем счётчики через Moxa OnCell G3251 на порт сервака.
по поводу сбора лучше проконсультируйтесь с Энергомерой http://www.energomera.ru/ru/software/meters/ce303-all.
с СЭ 303 не работали. а вот с 301-х пришлось уйти (горят при резких перепадах напряжения).
а все сбытовые, по опыту, работают с присылаемыми файлами XML формата прекрасно

[alex_ugrumov]

при организации АИИС КУЭ в данных случаях подключаем счётчики через Moxa OnCell G3251 на порт сервака.

а зачем им GSM, если у них Инет на точках есть, раз VPN поднят?

[Dmitry Isaev]

резервный канал связи никогда не повредит

[Romcheg]

На форуме Адастры видел Ваше сообщение, но там забанен :), поэтому не мог ответить, и подозреваю, что мой ответ все равно затерли бы.
Очень хорошо знаю ТМ, поэтому у меня по Вашим вопросам следующие комментарии:
1) Считывать напрямую пакет TCP от преобразователя RS232 вполне возможно, вот только если известен его формат, только тогда Вы сможете написать драйвер для ТМ, в противном случа все равно придется ставить на сервера с ТМ ответный драйвер преобразователя, который создаст виртуальные СОМ-порты, через которые будете работать в ТМ. А вот в последнем варианте, когда через виртуальные порты - очень рекомендую сначала проверить работу ТМ с количеством портов более 32-х штук, я очень сомневаюсь, что заработает. К тому же если работать с пакетом TCP - драйвер придется писать с нуля, или просить Адастру модифицировать их текущий: отдельные деньги, отдельное время на модификацию и отладку.

Даже если будуте разбивать на несколько серверов наверху, по несколько десятков СОМ-портов - все равно в итоге получите забавную штуку: все накопленные данные по счетчикам будут автоматом МРВ ТМ складываться в его родной СПАД-архив, и если сверху будет стоять единый сервер по сбору и обработке данных со всех этих серверов - он не сможет объединить эти данные в единый архив, ТМ этого просто не умеет. Адастра конечно же ответит - без проблем: для формирования отчетов и обработки архивных данных делайте удаленные запросы в архивы всех серверов - но если почитаете описание как работает этот механизм и его настройку в ТМ, то поймете, что обеспечили себя проблемами на долгую жизнь, тем более при таком количестве точек учета. Даже ради эксперимента - попробуйте сделать тестовый проект по взятию архивной выборки из одно МРВ в другой и попробуйте ее потом обработать: сделать отчет, математически просчитать алгоритмом, сразу поймете что я имею в виду. Но это будет проблемой только при работе с накопленными данными, если только с мгновенными значениями - то тут все будет много проще.

2) По варианту подключения счетчиков по местам, а потом по сети на центральный сервер - если работа только с мгновенными значениями, то получится, хоть и не сразу. Почему не сразу - узнаете, когда по сети этой в ТМ начнете работать. Дело в том, что у ТМ сетевой протокол обмена - это UDP, широковещательные пакеты. В рамках одной сети - еще боле-менее терпимо, даже если сложная сеть - приходится танцевать с бубном и играть с настройками сетевого оборудования, но когда такая распределенная сеть, да еще и через VPN - тут я могу пожелать только удачи, чтобы заставить сеть нормально работать на широковещательных пакетах. :) Даже если заставите работать - те, кто этой сетью пользуется, будут вас все время поминать добрым словом, а вы их, потому что широковещательный пакет в сети и его обработка, тем более такого масштаба - это будет песня.

Ну и в довесок снова ложка дёгтя: если необходимо будет работать с накопленными данными со счетчиков - они опять таки будут сохраняться локальными МРВ в свои локальные архивы, дальше - читаем мое описание в пункте №1...

В общем - по-хорошему для работы такой системы, если подразумевается работа с накопленными данными - они должны сохраняться в единую архивную систему, штатными средствами ТМ Вы этого не сделаете, что бы Вам ТП и маркетинг Адастры в уши не пел.

В принципе - Вы оба варианта озвучили вполне работоспособные: можно и локальные шлюзовые ПК наставить, а потом по сети на центральный сервер данные тянуть и мгновенные и накопленные на единый сервер и вести их обработку, а можно внизу преобразователи поставить, а наверху сервера с драйвером виртуальных СОМ-портов этих преобразователей и единый сервер консолидации данных с них. Оба решения адекватные, неадекватным в Вашем случае является только одно - инструмент (скада) на которой Вы хотите это сделать... На ТМ Вы еще долго будете опрашивать интернет по всем асутпшным форумам и бесконечно ждать конкретного ответа от Адасты, его не будет... Выбирайте адекватный инструмент (скаду), или Вам придется писать заплатки на ТМ, могу даже перечислить какие именно придется написать, чтобы "это" хоть как-то заработало:
1) Архив надо будет переделать на реляционную СУБД, чтобы он был единым для системы (штатные SQL-запросы в ТМ вам в этом не помогут никак, не верьте маркетингу)
2) Если архив переделывать на СУБД и в системе надо будет работать с накопленными данными - надо будет писать свой драйвер для работы со счетчиками, если через преобразователи, или даже через TCP, если будет известен формат пакета преобразователей. Если внизу ставить МРВ ТМ как некие RTU, то тут еще сложнее - придется такой архиватор в СУБД на каждую RTU написать, а наверху службу, которая из удаленных СУБД будет архив в единую СУБД собирать.
3) Если нужны будут отчеты, при таком подходе в штатных модулях ДокМРВ или Документаторе ТМ вы по СУБД отчеты уже не сделаете, придется ставить что-то профессиональное по построению отчетов по данным СУБД, или писать свое.

Если на ТМ подсажены и слезть не можете, то у вас два варианта: ждать решения от Адастры и попробовать его, или пойти по моему сценарию. По части работ у меня под ТМ уже есть некоторые решения как по архивации в реляционную СУБД, так и по сетевым взаимодействиям по методу "точка-точка" между узлами ТМ в обход штатных их протоколов и механизмов. С драйвером - придется подумать тогда еще немного, но уверен, что можно найти решение в обход штатного драйвера ТМ.

Если не жестко подсажены на ТМ, то мой вам совет инженера: рассмотрите более адекватный инструмент!

Пессимистично, жестко, зато правдиво... ;)

[Romcheg]

Свою скаду не предлагаю, у меня пока по электросчетчикам есть поддержка только СЭТ-4ТМ02 (с ПСЧ работает) и Меркурий-230, Энергомера пока еще только в разработке... :)