Нужен ли стандарт и какой? Опции

[Кузник]

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

[Масляева Анна]

По просьбе Никитина Павла Борисовича, публикую

Заключение ЗАО «ТЭМ» на "Концепцию стандарта обмена данными теплосчетчиков с устройствами и системами посредством цифрового интерфейса"

Основной, но не объявленной явно целью разработки и внедрения предполагаемого стан-дарта является упрощение интегрирования различных типов теплосчетчиков в некую гипоте-тическую информационную систему, о которой имеет представление только автор рассмат-риваемой концепции.
С этой целью предлагается стандартизировать базовые свойства теплосчетчиков:
- структуру многоканального теплосчетчика как комбинацию фиктивных одноканальных (возможность этого подразумевается, но не доказана);
- ограниченный набор аппаратных интерфейсов;
- ограниченный набор параметров.
За счет предлагаемых мер предполагается сделать процесс сбора данных с теплосчетчиков различных производителей единообразным и, следовательно, упростить задачу создания системы сбора и обработки данных.
Однако упрощения будут достигнуты только для этой гипотетической системы, поддер-живающей теплосчетчики только с базовыми свойствами.
Для множества существующих автоматизированных систем все только усложнится, по-скольку они оперируют данными, соответствующими реальной конфигурации схемы тепло-снабжения, – данные фиктивных одноканальных теплосчетчиков никого не интересуют.
Попытка подогнать свойства существующих многоканальных теплосчетчиков под нужды гипотетической (вновь разрабатываемой) системы ведет к их усложнению. Кроме формиро-вания измерительной информации (в том числе о количестве теплоносителя и тепловой энер-гии) в соответствии с описанием типа, необходимо будет поддерживать структуру данных фиктивных одноканальных теплосчетчиков для передачи на верхний уровень (для расчета количества теплоносителя и тепловой энергии, соответствующих реальной схеме тепло-снабжения).
Выполнение расчета одних и тех же показателей и на верхнем уровне, и в теплосчетчике, является принципиально неверным решением.
Предлагаемый промежуточный вариант – создание неких сервисных программ, собираю-щих данные с теплосчетчиков разных типов и конвертирующих их в файл известной струк-туры с последующей передачей на верхний уровень, реализуем. Однако и в этом случае речь идет об одной гипотетической системе, поскольку для различных систем верхнего уровня потребуется формировать различные (неунифицированные) файлы. Кстати, создание таких сервисных программ решает все вопросы – основной стандарт становится вообще ненуж-ным, равно как и переделка существующего парка приборов и прикладного ПО.
И все же пожалуй самое важное – цена вопроса. Если поддержать предлагаемую концеп-цию, то в кратчайшие сроки все производители теплосчетчиков должны обновить свою про-дукцию. Нужно учесть, что потребуется переработать не только резидентное ПО теплосчет-чиков, но и, как правило, схемотехнические решения вычислителей. Потребуется также пе-реработка собственных программных средства для сбора данных. С учетом сертификации на это потребуется как минимум 2-3 года и большие финансовые расходы. Дополнительного дохода от такой деятельности при этом не предвидится.
Все сказанное выше позволяет сделать вывод о нецелесообразности разработки предла-гаемого стандарта, тем более что решение поставленной задачи интегрирования разнород-ных средств измерений в автоматизированные системы существует. Стандартом де-факто на обмен информацией в гетерогенных системах автоматизации является OPC. Основные про-изводители приборов давно реализовали OPC-серверы. Задача унификации доступа к дан-ным решается на стороне клиентского приложения отображением переменных из OPC-серверов в некий стандартизованный набор (состав которого в частном случае может совпа-дать с предложенным в рассматриваемой концепции).


Генеральный директор ЗАО «ТЭМ» П.Б. Никитин

[baget]

По просьбе Никитина Павла Борисовича, публикую


Генеральный директор ЗАО «ТЭМ» П.Б. Никитин

Браво Павел Борисович, все по делу.

Хочется отметить некоторую неадекватность управленцев, поручивших г-ну Логинову разработать стандарт... У меня перед глазами плоды 4 х летнего труда этого деятеля со товарищи - уникальное г-но, стоимостью под 60 млн. рублей, которое и близко не дотягивает до продукта который она поменяла, и который был разработан за 5 месяцев. Причин этому много, например, идиотская концепция представления/описания объектов. Есть ведь все возможности получить информацию об этом чуде у эксплуатантов - например, Лупей категорически отверг возможность взять на себя ответственность за это чудо. Неужели не было возможности навести справки?

[Кузник]

В ответ на baget:
Давайте не про личности, а про содержание (по существу), и без ссылок на Лупея (он сам если сочтет нужным скажет).
А выбор разработчика был утвержден Партнерством, соответственно виновен не "Жираф"... а управленцы... обратись к управляющему партнерства П.Б.Никитину, он даст вам пояснение почему была создана для разработки стандарта группа под руководством Логинова.

[baget]

В ответ на baget:
Давайте не про личности, а про содержание (по существу), и без ссылок на Лупея (он сам если сочтет нужным скажет).
А выбор разработчика был утвержден Партнерством, соответственно виновен не "Жираф"... а управленцы... обратись к управляющему партнерства П.Б.Никитину, он даст вам пояснение почему была создана для разработки стандарта группа под руководством Логинова.

Уважаемый г-н Кузник, проблема действительно не в личности, а в тех знаниях которыми оная личность "со товарищи" обладает.
Очень кратко, разработка стандарта требует знаний в нескольких областях знаний. У меня есть несколько официальных документов от Логинова, кот. показывают, что сабж в вопросах программного обеспечения даже не 0 - это просто клиника.
Есть утверждения сабжа, что его продукт на базе С65 позволяет надежно работать с приборами поддерживающими Modbus - Ru, этими утверждениями он более года морочил ТГК-1, но ничего работающего продемострировать не мог, что говорит что в вопросах устройства самих приборов и организации связи с ними он нихрена не понимает.
У меня есть ТЗ системы кот. он разрабатывал более 3 лет и в которой более 10 самых важных пунктов не реализованы до сих пор... И т.д. Он элементарно не может реализовать возможности "Взлет - СП", а вы ему стандарт доверили разрабатывать...


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

То что разработку такого стандарт доверили разрабатывать некомпетентному шарлатану, как Вы понимаете ничего хорошого в пользу руководства НП не говорит.

И по мне пусть не будет вообще стандарта, чем то куда вас пытается сабж засунуть.

[Кузник]

Уважаемый г-н Кузник, проблема действительно не в личности, а в тех знаниях которыми оная личность "со товарищи" обладает.
Очень кратко, разработка стандарта требует знаний в нескольких областях знаний. У меня есть несколько официальных документов от Логинова, кот. показывают, что сабж в вопросах программного обеспечения даже не 0 - это просто клиника.
Есть утверждения сабжа, что его продукт на базе С65 позволяет надежно работать с приборами поддерживающими Modbus - Ru, этими утверждениями он более года морочил ТГК-1, но ничего работающего продемострировать не мог, что говорит что в вопросах устройства самих приборов и организации связи с ними он нихрена не понимает.
У меня есть ТЗ системы кот. он разрабатывал более 3 лет и в которой более 10 самых важных пунктов не реализованы до сих пор... И т.д. Он элементарно не может реализовать возможности "Взлет - СП", а вы ему стандарт доверили разрабатывать...


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

То что разработку такого стандарт доверили разрабатывать некомпетентному шарлатану, как Вы понимаете ничего хорошого в пользу руководства НП не говорит.

И по мне пусть не будет вообще стандарта, чем то куда вас пытается сабж засунуть.

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