Уважаемые специалисты,

Строится здание - где то 25 этажей

На этажах (почти на всех в той или иной степени) будут предусмотрены водомерные (ГВС/ХВС ), тепломерные, холодомерные, электромерные узлы.

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

Систему планирую строить так:

1. Выдать тех. задание смежникам, что бы предусмотрели на борту узлов учета телеметрические средства коммуникации. В принципе во многие узлы учета можно заложить интерфейсные связи – но возится с протоколами не хочу преднамеренно, уж лучше пусть со стороны узлов учета все будет импульсное, а информационная сеть только между IO.


2. На каждый этаж заложить распределенный ввод вывод (IO) со счетными каналами, причем один шкаф на этаж внутри которого и разместить все IO. То есть по горизонтали (между узлами учета и IO) исключительно телеметрические связи, а по вертикали (между этажами) - шина, например, RS-485 ModBus.
Можно IO заложить и возле каждого узла учета, но растягивать шину и плодить модуля IO (хоть и кабельных трас меньше) не хочу.

(Просуммировал полное количество IO – получилось около 50 16 канальных корпусов. Если шина, например, RS-485 ModBus, то будет 2 сегмента сети)


3. На каждый сегмент заложить преобразователь RS-485 в ETHERNET (например MOXA) и один свитч.

4. Заложить ПО на АРМ оператора.
ПО должно опрашивать каждый сегмент раз в минимально установленный срез времени (например, один час), записывать данные в базу и обнулять счетные регистры модулей IO

Движек опроса шины и записи полученных данных в БД можно написать и самому или взять SCADA. А вот механизмы формирования РАЗВИТЫХ отчетов (с фильтрами, выборкой суммированием и т.д.) в родных средствах всевозможных SCADA уж очень бедные. Поэтому, думаю, вполне подойдет ПО “SQL reporting services” – хотя тут придется много писать руками.
Кстати многие репорт сервисы SCADA используют не свою, а стороннюю СУБД – например, «Citect Report» использует «SQL Server Reporting Services 2005».

Вопросы

1. Жывая ли вообще структура (опыта построения такого рода систем еще не имел) ?

2. Если да,
- посоветуйте оборудование (что бы не менее 16 счетных каналов в одном корпусе и с
интерфейсом на борту, например, ModBus, LON и т.д.). ?
- Какое ПО для разработки отчетностей посоветуете

C импульсными выходами и обычными приемниками типа Адвантечь есть одна особенность - в случае обрыва связи будет пропуск счета, т.е. придется ходить по квартирам и корректировать показания.

Почему Вы не хотите воспользоваться старой доброй европейской разработкой - шиной M-Bus? Вот например полный набор счетчиков:

http://www.kamstrup.ru

вот решение подешевле, близкое к тому, что вы хотите получить:

http://www.uraltech.ru/view_text_cat/id/34

на эльфе можете полностью учет рганизовать. к ним есть адаптеры m-bus и rs-485.

Не у всех. В MasterSCADA в последних версиях появился очень мощный редактор отчетов. И фильтры и суммирование - все имеется.

1. Структура вполне жизнеспособна.
Стоит продумать схему питания (и резервного питания) всех модулей. Как уже сказали, с импульсами главная проблема -- пропускание их при пропадании питания.
Счётчики со встроенным M-bus сильно увеличат надёжность считывания, но и стоимость системы.

2. Можно посмотреть модули Lonix, Пульсар, ICP-DAS.
Кто-нибудь знает, где взять подобный M-bus модуль (на 8-16 входов)?

С ПО варианта два: или воспользовать чем-нибудь готовым от производителей подобных систем -- такое предлагают очень многие, рекомендовать ничего не могу.
Или, если программирование не пугает, сделать самому. В этом случае может подойти стандартный набор сайторазработчика LAMP: Linux, Apache, MySQL, PHP.

Если это система коммерческого учета, то самый интимный момент будет не в программно-аппарной реализации системы, а в ее сертификации как едичного средства измерения.

Если это технический учет, то рекомендую обратить внимание на беспроводные технолггии связи линии "Счетчик-УСПД", типа ZigBee, чтоб не бегать по квартирам в поисках обрывов.
Тогда на этажах будут стоять УСПД Zigbee-Ethernet, и вертикальный эзернет.