Перейти к содержимому
Калькуляторы

АСКУЭ: провайдерам стоит задуматься

Если импульс приходит реже, чем раз в 10 секунд (точно не помню, так что навскидку) - ни о какой метрологии даже по получасовкам речь уже не идёт.

Да? А если потребление такой профиль имеет? А если фидер отключен?

А водяной счётчик, импульс вообще может длиться месяц? Геркон замкнулся, и кран закрыли, и на месяц нет разбора воды?

Если отключен - вопросов нет.

Во всех остальных случаях дискретность импульсов стОит учитывать.

 

Прошу ссылку, прочитать про сиё требование подробнее.

Требования такого нет, это из личного опыта. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, псевдо-3Д выглядит красивше. Гравное не переборщить с украшательствами, а то информативность пострадает.

 

Нормально, имхо, перебора нет. Развитие ПО для наших сумматоров остановилось несколько лет назад. Все добавленные отчёты и вкусности, на данный момент в основном нас устраивают. Невозможно решить вновь назревшие хотелки. Например, я попытался им объяснить, что надо бы как-то избавиться от отчётов в Эксель, сделать экспорт данных в ОО Calc. Меня просто не поняли, чего я хочу, и зачем мне это надо. Приходится держать на этом компе Эксель.

 

Или вот введённые в апреле прошлого года почасовки. Мосэнергосбыт уверял, что они работают только с Меркуриями-счётчиками, что файл отчёта по почасовкам будет представлять собой чуть ли не стандартный отчёт Меркурия-230. Ан нет, файл почасовок, используемый ныне Мосэнергосбытом , представляет собой файл отчета СЭТ-4. Или, по крайней мере, основан на его формате. И какого, спрашивается, мы планово меняли наши счётчики на Меркурий-230? Заплатив пол-лимона тому же Мосэнергосбыту? Они нам при замене счётчиков ТП взорвали, чужую, шины поплавились. Хорошо, что сети местные, решили с ними всё полюбовно.

 

Ну и вот.)) Программеров нет, либо они более не хотят вникать в нужды клиентов. И файл почасовок мне завтра делать вручную, как всегда.))

Изменено пользователем Николай Александрович

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ОО эксельные файлы открывает без проблем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ОО эксельные файлы открывает без проблем.

 

Ага, а мужики-то и не знают, ага.

Не смешно, если честно. Прошу быть серъёзнее, спасибо за понимание.

 

Поделие братских программеров не файл *.xls создаёт, а открывает excel.exe, и закидывает туда цифирь. Выглядит, конечно, феерически. Сразу видно, что компьютер делом занят, цифры мелькают с бешеной скоростью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделие братских программеров не файл *.xls создаёт, а открывает excel.exe, и закидывает туда цифирь. Выглядит, конечно, феерически.

Да, это феерически, согласен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Разрабочики АСКУЭ редко опускаются до предметного разговора с теми, кому это может быть нужно.

Ключевая фраза топика!

 

это решается подключением соответствующих библиотек, которые пишутся по запросу клиента.

Простите, по запросу клиента или за деньги клиента? ;)

 

Видите ли, одна из серьезных бед наших отечественных компаний в том, что они прекрасно работают в модальности "любой каприз за Ваши деньги" вместо осмысленного развития своего продукта. Как-то раз было прикольно, пришли одни перцы мне продавать свой продукт. 40 минут мы выясняли, что продукта-то по сути прикладного нет, есть некий набор компетенций по созданию чего-изволите на определенном наборе платформ. Что тоже по своему ценно, но изначальный посыл-то был не в этом.

 

Поделие братских программеров не файл *.xls создаёт, а открывает excel.exe, и закидывает туда цифирь. Выглядит, конечно, феерически. Сразу видно, что компьютер делом занят, цифры мелькают с бешеной скоростью.

Wow! Какой феерический хай-тек! Ручкой от швабры бить пробовали? Если пробовали просто ручкой от швабры и не помогло - попробуйте намотать на нее 2..3 метра колючей проволоки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Сбор и обработка данных счетчиков - вторичны. Т.е. это не цель, а досадная необходимость. Не бизнес-функция, а накладные расходы. Ведь тот же главный энергетик работает не с массивом счетчиков, а с главной схемой распределения энергии предприятия. И на этой схеме решает ряд своих задач - технологических, экономических и т.д., так вот сразу вопрос: ну вот где я в Садко вижу эту самую главную схему, точки контроля, где мне сразу показывают обнаруженные потери в схеме? Где я могу посмотреть отклонения текущего профиля потребления по ресурсу от стандартного среднесуточного? Пошлет ли система мне СМС, если оно случилось? Где у меня "виртуальный мега-счетчик" предприятия, показывающий сколько всего и каких ресурсов я трачу в моменте? ;) Ой, вот только не надо про настраиваимые отчеты...

 

Системная ошибка в том, что людям не нужна Автоматизированная Система Коммерческого Учета Энергии. Людям нужна Автоматизированная Система Анализа и Управления Энергией.

 

Полагаю, Николай Александрович меня поддержит ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

to Прохожий.

есть такая байка

приходит президент в роскосмос и спрашивает

-что можете сделать?

ему отвечают

-а что надо сделать?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

идеальный случай когда разработчик сам и есть заказчик.

Как же. Когда разработчик - внешний, то заказчик хоть чуть-чуть думает над тем, что ему надо, и что ему хочется.

А вот когда для себя пишется - начинаются дергания "а давайте вот это быстро-быстро сделаем. А теперь это..". Причем хочушки

не документируются нигде.

 

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

выкинуть, или надо пылинки сдувать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Дмитрий, я вот так понял, что Вы имеете прямое отношение к продукту Садко, так?

 

Скажите мне пожалуйста, есть ли у Вас в штате хотя бы один сильно тертый жизнью бывший главный энергетик какого ни будь мало-мальски серьезного предприятия? Хотя бы один не менее тертый жизнью руководитель ТСЖ? Это один вопрос.

 

Второй вопрос, являющийся следствием первого: если я попрошу Вас прямо здесь опубликовать несколько Use Case диаграмм Вашей системы, Вы сможете просто взять их и приаттачить, или Вам для начала придется их рисовать ;) Моя ставка на то, что их у Вас нет.

 

Представляете ли Вы хотя бы приблизительно как облегчаются продажи, если потенциальному клиенту на конкретных и понятных ЕГО кейсах демонстрируется как изменится его каждодневная жизнь? Вы заметили, что просто по ходу топика Николай Александрович показал несколько вот таких вот кейсов ;) И мне почему-то кажется, что они стали для Вас если не откровением, то как минимум - новым знанием.

 

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

 

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

 

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

 

идеальный случай когда разработчик сам и есть заказчик.

Нет. Это самый неэффективный по интегральным критериям путь. И и на микро и на макро уровне.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

А они не знают. Они 20 лет какие-то отчеты делали и что-то считали. Ибо 'так тут принято'. А для чего это, собственно, делается - это все потерялось

в забытых документах Госплана СССР.

 

Тут можно вспомнить байку о том, что уже никто не знает, почему и как остатки управляющей системы ЕЭС работают так, как они работают. Но вот только я пока сомневаюсь в ее правдивости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А они не знают. Они 20 лет какие-то отчеты делали и что-то считали. Ибо 'так тут принято'. А для чего это, собственно, делается - это все потерялось

в забытых документах Госплана СССР.

Не поверишь, каждый фермер знает, как стать в два раза лучшим фермером. Никто не обращал внимания на то, что самым долговременным успехом пользуются продукты, разработчики которых по сути становятся концентраторами отраслевой экспертизы? ;) Поэтому каждый по отдельности вряд ли тебе представит исчерпывающую картину. Но собрать эту картину можно только оттуда.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не поверишь, каждый фермер знает, как стать в два раза лучшим фермером.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

to Прохожий.

 

Я не разработчик и не программист Садко, но некоторое отношение имею.

 

У НАГа в штате нет бывшего энергетика и руководителя ТСЖ. Хотя могу ошибаться.

 

Беда в том что заказчик сам не знает что ему надо, а уж исполнитель тем более. Поэтому программисты предлагают более менее понятный продукт, то как они сами это видят. Не вижу в ваших словах противоречие моим, вы, как бы расшифровали мою мысль, кроме "Нет. Это самый неэффективный по интегральным критериям путь. И и на микро и на макро уровне."

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Сбор и обработка данных счетчиков - вторичны. Т.е. это не цель, а досадная необходимость. Не бизнес-функция, а накладные расходы. Ведь тот же главный энергетик работает не с массивом счетчиков, а с главной схемой распределения энергии предприятия. И на этой схеме решает ряд своих задач - технологических, экономических и т.д., так вот сразу вопрос: ну вот где я в Садко вижу эту самую главную схему, точки контроля, где мне сразу показывают обнаруженные потери в схеме? Где я могу посмотреть отклонения текущего профиля потребления по ресурсу от стандартного среднесуточного? Пошлет ли система мне СМС, если оно случилось? Где у меня "виртуальный мега-счетчик" предприятия, показывающий сколько всего и каких ресурсов я трачу в моменте? ;) Ой, вот только не надо про настраиваимые отчеты...

 

Системная ошибка в том, что людям не нужна Автоматизированная Система Коммерческого Учета Энергии. Людям нужна Автоматизированная Система Анализа и Управления Энергией.

 

Полагаю, Николай Александрович меня поддержит ;)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Беда в том что заказчик сам не знает что ему надо, а уж исполнитель тем более.

Э, нет, дорогой друг. Заказчик ВСЕГДА знает, чего он хочет. Другой вопрос, сможете ли Вы, подобно опытному психотерапевту, вскрыть не поверхностные, а глубинные потребности индивида, помочь ему осознать их и через это сделать его счастливым? ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wow! Какой феерический хай-тек! Ручкой от швабры бить пробовали? Если пробовали просто ручкой от швабры и не помогло - попробуйте намотать на нее 2..3 метра колючей проволоки.

 

ПО покупалось в составе системы десять лет назад, и они нам более ничего не должны. Корни этого ПО писались ещё под Win95, на BDE. Сответственно, как они нам ранее объяснили, им такой экспорт в Эксель очень удобен, и переписывать ПО никто не будет. Да и ладно, лишь бы работало. И так замучались с этим поделием, пока не выяснили, что для безглючной работы ему надо Win не старше 2000, и процессор АМД Атлон. На P4 оно вылетает каждые пять минут, куроча при этом базу. Тем не менее, как инструмент энергетической службы предприятия, наше ПО очень даже устраивает. Про отчёты по соответствующим формам, в Энергосбыт, я уже писал. Хорошая аналитика, очень близкая к реалиям электроэнергетики. "Оперативный контроль", это когда практически в режиме реального времени, каждые три минуты, опрашивается сумматор. Эта фича вообще нам миллионы съэкономила, путём контроля непревышения заявленной мощности, в часы утреннего максимума. Суть в том, что штрафуют за превышение в получасовых интервалах, а энергетик смотрит в трёхминутных. И если вдруг мощность выпрыгнула за заявленную, надо срочно остановить какое-либо оборудование, с запасом по мощности. Мощность в трёхминутках провалится, а в итоге, по получасу, превышения не будет. Снивелируется, короче.

 

Всё правильно здесь писали уважаемые участники, обязательно должна быть связка клиента, с его "хотелками", и разработчика системы / ПО. И уж если есть некий "супервайзер", смотрящий на эту тему сбоку / со стороны, и вполне понимающий и клиента, и разрабочика, то это вообще будет великолепно.

 

ПО, с которым сейчас работаем, разрабатывалось непосредственно для Мосэнергосбыта. Там, как видится, сцепка клиент-разработчик, вполне себе присутствовала. Потому, что все необходимые инструменты анализа и контроля присутствуют. Мы помогли разработчику прикрутить к системе учёт воды, они сами как-бы об этом и не задумывались даже. Потом их осенило, что и вырабатываемое тепло/пар (если есть котельная) тоже можно считать, теплосчётчиком/расходомером с импульсным выходом. Да вообще всё КИПовское, что выдаёт импульс. Импульс важен, ибо только с импульсом можно вести "оперативный контроль", в трёхминутных интервалах. Сливом профиля мощностей электросчётчика, того же Меркурия, увидишь только усреднённые расходы в получасовых интервалах. А если этот же Меркурий подсоединить импульсом, то уже появляется возможность оперативного контроля.

 

Необходимо учитывать, что я излагаю некоторые моменты эксплуатации системы АСКУЭ промышленного предприятия. Возможно, кому-то не будет нужен подобный инструментарий главного энергетика. Вероятно, есть много людей, кому действительно надо только удалённо снимать показания электросчётчиков, размещённых географически далеко друг от друга? Банально, чтобы заполнить бланки показаний счётчиков, и сдать их в свой Энергосбыт? Проскакивала же подобная тема на форуме, люди тратят по несколько рабочих дней и массу бензина, только для того, чтобы снять ежемесячные показаний электросчётчиков, питающих их оборудование.

 

Или УК жилого многоквартирного сектора? Нужна ли им подобная аналитика? Не уверен. А вот снимать удалённо расходы на квартирных водосчётчиках, хотелось бы каждой УК, полагаю?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Полагаю, для УК станет основным критерием цена вопроса: погонять девочку по подъездам один-два дня станет для УК тыщей-двумя, не более, стало быть для двухлетней окупаемости такая система для всей группы домов должна стоить ну 50 тыщ...

А если прибавить то что обслуживать электрик УК весь зоопарк не осилит, экономика станет сомнительной.

И это еще не говоря о том что "отмотать" такие показания станет проще, например оторвав проволочку на полмесяца.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

погонять девочку по подъездам один-два дня станет для УК тыщей-двумя

 

А сколько в среднем подъезде квартир? В каждой по два или по четыре водосчётчика.

В скольких квартирах откроют сверщику, за "один-два дня" обхода? Народ-то днём работает, как бы.

И так далее, по вкусу. За тыщу-то не каждый на единичный вызов пойдёт, а тут за пару тыщ предлагаете обходить тысячи счётчиков? Ну-ну.

 

И это еще не говоря о том что "отмотать" такие показания станет проще, например оторвав проволочку на полмесяца.

 

Провод от геркона счётчика - в коробку, под пломбу. Расписать клиента об ответственности за повреждение пломбы, или провода. Как у Энергосбыта, нет пломбы, значит выставляют по расчёту. С момента предыдущей сверки показаний. Год назад сверяли, значит за год, два года, значит за два года заплатишь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Эта фича вообще нам миллионы съэкономила,

;)

 

Полагаю, для УК станет основным критерием цена вопроса: погонять девочку по подъездам один-два дня станет для УК тыщей-двумя, не более, стало быть для двухлетней окупаемости такая система для всей группы домов должна стоить ну 50 тыщ...

Вообще-то у УК есть так же свои задачи общедомового плана. Крупная УК, конечно, может и забить, но вот любой внятный ТСЖ, например, будет заинтересован, чтобы знать разницу набегающего суммарно на счетчиках жильцов и на общедомовом счетчике. Потому что ТСЖ платит за "итого", а жильцы - каждый за свое. Разница - она или общедомовые расходы, как свет например, или потери из за дырок в трубах ;)

 

Все таки эти системы нужны не для того, чтобы "девочку не гонять". Например, многие ТСЖ решают проблему просто: жильцы до какого-то числа кидают в ящик бланк с 4 цифрами: номером квартиры, электричеством, ХВ и ГВ. И этого вполне хватает. Кто не кинул - получает начисление "по среднему" на этот месяц и все дела.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вот снимать удалённо расходы на квартирных водосчётчиках, хотелось бы каждой УК, полагаю?

С электричеством прекрасно обходятся без ежемесячного снятия показаний. А сверку раз в год и так и так делать.

 

Вообще-то у УК есть так же свои задачи общедомового плана. Крупная УК, конечно, может и забить, но вот любой внятный ТСЖ, например, будет заинтересован, чтобы знать разницу набегающего суммарно на счетчиках жильцов и на общедомовом счетчике. Потому что ТСЖ платит за "итого", а жильцы - каждый за свое. Разница - она или общедомовые расходы, как свет например, или потери из за дырок в трубах ;)

У нас последнее время переходят на оплату напрямую поставщику. Подозреваю, что ТСЖ устало бороться с неплательщиками своими силами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Видите ли, одна из серьезных бед наших отечественных компаний в том, что они прекрасно работают в модальности "любой каприз за Ваши деньги" вместо осмысленного развития своего продукта. Как-то раз было прикольно, пришли одни перцы мне продавать свой продукт. 40 минут мы выясняли, что продукта-то по сути прикладного нет, есть некий набор компетенций по созданию чего-изволите на определенном наборе платформ

почти оффтоп. пару лет назад ИПТВ активно развивался. к нами пришли представители разработчика. и не спрашивали "что вам надо и мы вам за деньги напишем". а сказали "у нас есть вот такая ИПТВ приставка. она уже заточена под ваш API, мы его посмотрели и реализовали. потестируйте, если понравится покупайте". и действительно приставка работала, за пол года выловили баги и закупаем теперь тысячами ежемесячно. вот такие приятные исключения бывают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какое ПО более менее для разных типов эл.счетчиков подходит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какое ПО более менее для разных типов эл.счетчиков подходит?

 

OPC + SCADA обычно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какое ПО более менее для разных типов эл.счетчиков подходит?

OPC + SCADA обычно.

OPC то тут причём? OPC - это всего лишь интерфейс обмена данными между OPC-сервером на Win-машине и клиентами на ней же (или удалёнными в случае DCOM). Сам OPC-сервер опрашивает устройства по какому-либо протоколу обмена.

 

Если вернуться к начальному вопросу, то я бы ориентировался на счётчики с поддержкой унифицированных протоколов обмена (IEC 60870-5-101/104, Modbus).

Очень нравятся приборы Satec - адекватная тех.поддержка и цены (правда, у нас объёмы хорошие).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.