Учет потребления тепловой энергии в жилом комплексе

[Sasha8111]

Дорогие специалисты! Помогите с решением вот какой проблемы.


Есть современный жилой комплекс (25 этажей), инженерные системы которого управляеются комплексной системой автоматики. Параметры систем регистрируются

Одной из подсистем системы является технический учет теплоэнергии. Структура подсистемы следующая:
- По квартирам установлены теплосчетчики с телеметрическим выходом.
- На каждом этаже установлены 16-ти канальные устройства сбора данных (УСД), опрашивающие теплосчетчики. Каждый канал УСД это фактически счетный регистр. Получается 15 задействованных каналов на этаж.
- Все УСД «висят» на шине RS-485 (протокол «DCON»).
- В диспетчерской осуществляется преобразование RS-485 в ETHERNET через конвертор, который в конечном счете и выдает информацию рабочей станции (РС).
- К данной подсистеме с программной стороны поставлен OPC Server, с помощью которого можно без проблем просматривать текущее значения конкретного канала. Разумеется, что любое значение канала можно переслать OPC Клиенту.

Проблема:
OPC SERVER не пишет в базу данных (БД).

Задача:
Нужно сохранять показания от каждого канала в БД и предоставить пользователю приложение с помощью которого он сможет осуществлять выборку.


Мое видение решения:

1. БД будет преставлять перечень файлов (например , dbf, или вообще txt).
• Обращение к БД будет осуществляться через драйвер OLEDB.
• Каждый следующий файл будет создаваться, если объем текущего превысил, к примеру, 400 Mb. Думаю, что один файл вполне охватит год, а то и больше: 375 записей за час, 9000 записей за сутки, 3285000 записей за год.

2. Писать в БД будет приложение поток, написанное средствами MFC или др. С началом каждого нового часа поток будет запускать приблизительно следующий регламент.
• Опросили каждый канал через OPC Server.
• Записали накопленные значения от каналов в БД через OLEDB. То есть в некую таблицу БД добавили запись:
Этаж / Квартира / УСД/ Канал / Значение канала/ Дата / Время
• Обнулили каждый канал

3. Обращение к БД будет реализовано через приложение пользователя. Функционал приложение будет заключаться в формировании отчета за период времени по выбранным зонам.
Например результат запроса «вывести посуточный ИЛИ почасовой отчет за период времени T = [01.02.2009 00:00:00…08.03.2009 12:00:00] по этажам с 1-го по 8-й» должен будет вывести суммарное посуточное ИЛИ почасовое потребление выбранной зоны (с 1-го по 8-й этажи) за период времени T, а также общее суммарное потребление за весь период T выбранной зоны.
Сам отчет будет выводиться в какой-нибудь стандартный DataGrid вьювер поддерживающий механизм ADODC.
Все хорошо, но вот если пользователю понадобиться отчет за период времени, который выходит за рамки одного файла, например на два или три года, тогда придется склеивать (UNION ALL) файлы (таблицы). Я пробовал склевать три четыре таблицы таких размеров – результат не очень хороший. Перепробовал несколько DataGrid’ов - все долго грузились, а некоторые даже зависли.

Вопросы ВАМ!
Я автоматчик и В БД особо не разбираюсь. Поэтому все выше описанное может показаться профессионалу полным бредом.
Проверьте сам подход ?
Может выбор связи через OLEDB вообще не верный ?
Может, стоит для данной задачи поискать бесплатные СУБД ?

[Naeel Maqsudov]

Забудьте про DBF. Перейдите на нормальный SQL-сервер.
Выбор даже бесплатного ПО весьма широк: MySQL, FireBird.

[somewhere]

ХХХХХХХХХХ

[Laba]

Вопросы ВАМ!
Я автоматчик и В БД особо не разбираюсь. Поэтому все выше описанное может показаться профессионалу полным бредом.
Проверьте сам подход ?
Может выбор связи через OLEDB вообще не верный ?
Может, стоит для данной задачи поискать бесплатные СУБД ?

Бредом это не кажется. Вполне приемлемо. Все так или иначе это делают.

На этапе сбора данных, где данные пишуться потоком, всё равно какой формат использовать. Можно использовать и dbf, и текстовый файл с разделителями. Последний способ даже проще будет и не потребует OLEDB.

Бороться с избыточностью на этапе съёма данных тоже не следует. Писать нужно всё.

Бесплатные СУБД стоит искать. И вот почему. Делать запросы к данным в первичном виде не есть хорошо. Запрос написать можно, но ожидание результата может превысить терпение пользователя. Даже dbf с индексами не спасёт.

Лучше сделать так.

Подобрать СУБД. Определить возможные срезы данных (день, неделя, этаж, канал и т.д.) Создать таблицы для хранения агрегированных данных по нужным срезам.

Далее: стандартными средствами СУБД импортировать первичные данные, делать суммирование по нужным срезам, результат записывать в таблицы.

Пользовательское приложение будет работать с СУБД, отчеты будут выдаваться быстро, пользователи будут довольны.

Для отчетов использовать одну таблицу с первичными данными не практично. Она будет только расти, каждый день на чуть-чуть и в один из этих дней она станет БОЛЬШОЙ и начнёт порождать кучу мелких проблем.

В этом варианте нет проблемы с распределением данных по физическим файлам.

Что использовать в пользовательском приложении для доступа к СУБД? Без разницы. Лишь бы самому понравилось.

[somewhere]

ХХХХХХХХХХ

[Laba]

Может вообще нафига все эти форматы придумали, будем слушать MP3 через SQL, JPG будем в DBF хранить... мы здесь имеем дело с RAW-данными, т.е. тупыми значениями в разрезе времени с одинаковой периодикой. Я не побоюсь сказать что любая выборка будет работать в тысячи раз быстрее в любых разрезах - времени, каналах, этажах...

Кстати, в базе давно уже хранят и mp3, и видео, ну а показ картинок из sql-базы это в инете святое дело. Каждый день смотрим.

Прослушивание Mp3 и формирование пользовательских отчетов это разные классы задач. Речь идёт про сопряжение информационной задачи с АСУТП.

Читайте внимательно и вдумчиво пост.

На этапе переноса данных из АСУ в базу сокращать ничего не надо, дабы не потерять по дороге или со временем. А вот в базе предлагаю устранить избыточность, хранить только предварительно суммированные данные.

Чем меньше разрезов, тем меньше таблиц.

Советую всё-таки "побояться" отстаивать столь спорные утверждения про скорость работы в тысячи раз.

[somewhere]

Ладно, все равно вам СУБД-шникам ничего не докажешь, дело ваше

[Naeel Maqsudov]

Не отклоняйтесь от темы, товарищи

Разрабатываемая автором темы система напоминает биллинг.

В биллинговых системах (из тех нескольких с которыми мне приходилось иметь дело на практике) как правило тарификационные данные загружаются в БД сразу. И сразу же тарифицируются. Т.е. превращаются в изменения балансов на лицевых счетах абонентов.

Есть другая точка зрения: если счета надо выставлять раз в месяц (и в перспективе не планируется возможность выставления внеочередного счета за любой период), то в этом случае есть очень рациональное зерно в том, чтобы месяц копить "сырые" данные в виде RAW-файлов. И только раз в расчетный период выполнять их обработку. Но надо учесть ограничения такой схемы. Она уже не realtime.

Третья позиция:
Можно конечно вообще не загружать данные от регистраторов в базу данных и оставить их в сырых файлах. Вполне вероятно, что для работы с этими сырыми данными будет разработан софт весьма и весьма эффективный. Но разработка системы при этом несколько удорожается.

Выбирайте.