Мы поможем вам стать лучшими в отрасли Тел./факс +7(495)737-60-28, +7(499)151-06-54     e‑mail: info@citycom.ru

Комментарии к статье "Сравнение программных продуктов..." (НТ №2-2018)

А.Р. Ексаев, генеральный директор ООО ИВЦ «Поток» (г. Москва)


Комментарии разработчика

к статье 

"Сравнение программных продуктов для создания электронных моделей систем теплоснабжения на примере поселений Чукотского АО"

(«Новости теплоснабжения», №2-2018)


Свои комментарии к статье В.С.Пузакова («Энсис Технологии») и его коллег я хочу начать со слов благодарности – от лица компании ИВЦ «Поток», разработчика линейки продуктов CityCom, с одной стороны, и от лица всего сообщества специалистов систем централизованного ресурсообеспечения, с другой стороны.

Подобный сравнительный анализ нужен был уже очень давно, но ни у кого до сих пор не дошли до этого руки, и причины тому есть как объективные, так и субъективные. Объективная причина имеет корни в «традиционализме» и состоит в том, что в стране крайне мало компаний и специалистов, имеющих существенный профессиональный опыт работы и с тем, и с другим инструментарием, и, соответственно, способных провести качественный сравнительный анализ продуктов. Если говорить о компаниях «проектного» профиля, то наиболее распространенное суждение примерно таково: «Мы работаем с программой Х, хорошо ее знаем, привыкли к ней, и нет нужды осваивать что-то иное». Позиция вполне понятная и укладывается как в логику «традиционализма», так и в логику «минимизации телодвижений». Однако едва ли не подавляющую долю рынка проектировщиков занимают работы, связанные с разработкой и актуализацией схем теплоснабжения и водоснабжения/водоотведения, торгуемые на открытых конкурсах и аукционах. А в ТЗ в составе конкурсной документации к таким закупкам все чаще появляются требования о том, что электронная модель как раздел Схемы должна быть выполнена и представлена в формате конкретного инструментария, в связи с тем, что именно этот инструментарий внедрен и используется в ресурсоснабжающем предприятии, являющемся в конечном счете главным бенефициаром Схемы. И это далеко не всегда тот продукт «Х», которым владеет и к которому привык проектировщик. В таком случае есть всего три варианта развития событий:

(а) принять и освоить альтернативный инструментарий;

(б) на свой страх и риск проигнорировать требование ТЗ и реализовать проект на инструментарии «Х», а потом как-то попытаться выкрутиться, «авось пропустят»;

(в) отказаться вовсе от участия в такой закупке

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

Субъективная же причина отсутствия открытой и честной сравнительной аналитики по программному обеспечению для электронного моделирования систем ресурсоснабжения состоит в том, что специалисты предметной области, имеющие опыт профессиональной работы с разными инструментальными средствами создания и эксплуатации электронных моделей, очень и очень «закрыты». Из них, что называется, «слова не вытянешь». Устно и неформально – еще возможно, хоть и с трудом, а уж в формате открытой публикации – ни за что! Это трудно объяснимый эффект, но уж как есть... И рынок имеет то, что имеет – ноль информации в широком открытом доступе.


Теперь собственно комментарии к статье (в порядке следования в тексте).

Цитата: «Из рисунков видно, что в ИГС CityCom такие элементы, как тепловая камера, насосная и ЦТП представлены с большей деталировкой, чем в электронной модели на базе ГИС ZuluGIS и это является необходимым условием, – иначе «запустить» расчёт электронной модели в ИГС CityCom не представляется возможным...». И в другом месте: «...также в CityCom нужно забивать полную внутреннюю структуру тепловых камер...»

Это чистая правда: расчет будет невозможен до тех пор, пока не описана полная топологическая структура связности сети, включая описание внутренних схем всех узлов, в том числе (и особенно) сложных узлов, каковыми являются насосные станции, ЦТП и некоторые тепловые камеры с множеством запорной арматуры и сложной схемой коммутации трубопроводов. Для «облегчения жизни» операторов ввода в CityCom имеются две «зеркальных» процедуры: (а) автоматическое создание топологического описания по нарисованной в специальном графредакторе схеме сложного узла и (б) автоматическое воссоздание графического представления внутренней схемы узла по его имеющемуся топологическому описанию. Но, внимание: это нужно только для действительно сложных узлов или тепловых камер с «нестандартной» структурой. В случаях же, когда внутренняя структура камеры стандартна (все входящие трубопроводы сходятся в одной точке – разумеется, отдельно для подачи и обратки), достаточно для такого узла указать признак «структура стандартная» и поставить или убрать признак наличия запорной арматуры на всех ребрах. И ничего не надо больше – ни рисовать, ни описывать. Топологическая структура будет описана автоматически, сама «прорисуется» на внешней схеме сети и, разумеется, с учетом этой структуры рассчитается гидравлика. Если авторы статьи об этих возможностях просто не знали (не читали документацию?), то можно им лишь посочувствовать, представив себе, сколько времени и сил они убили на «забивание внутренних структур тепловых камер» (с), вместо того, чтобы просто поставить галочку «структура стандартная».

Но к чему такие сложности, спросите вы? Поясним. Представьте себе, что у вас есть тепловая камера, внутри которой проходят (перекрещиваются) две пары линий трубопроводов на разных уровнях, которые вообще никак не пересекаются между собой. Таких камер полно в жизни, особенно в системах водоснабжения. Вообще не изображать эту камеру? Но она же ЕСТЬ, как-то поименована, имеет строительную конструкцию, стоит на чьем-то балансе и обслуживается! Модель с отсутствующим механизмом топологического описания схем узлов в такой ситуации неизбежно приведет к грубейшим ошибкам, «соединив несоединяемое» внутри такого узла. Это самый простой пример, первым приходящий на ум. По некоторому размышлению любой технолог приведет с десяток аналогичных примеров, противоречащих принципу «автоматического» формирования структуры связности лишь на основании принципа смежности нескольких линий трубопроводов с одним узлом сети.

В качестве иллюстрации приводим графическое представление в CityCom действительно сложного узла тепловой сети – ЦТП (Рис.1). Все задвижки, насосные агрегаты и регуляторы в этой схеме ЦТП являются структурными динамическими элементами модели, состояние которых можно менять, и от состояния которых сильно зависит гидравлика в сети. Ящик марочного коньяка тому, кто расскажет, как моделировать изменение гидравлики в сети при изменении состояний динамических элементов схемы подобного узла без исчерпывающего описания топологической связности этих элементов с сетью!

Пример графического представления в CityCom узла тепловой сети со сложной внутренней структурой (ЦТП)
Рис. 1. Пример графического представления в CityCom узла тепловой сети со сложной внутренней структурой (ЦТП).

 

Авторы пишут: «...по нашему мнению, сегодня ООО «ИВЦ «Поток» отдает большее предпочтение работе в облаке CityCom(Cloud)...»

Это так, но лишь отчасти. Правда состоит в том, что сегодня технически и технологически равно доступны обе возможности – как лицензионная поставка ПО CityCom, так и безлицензионный облачный сервис CityCom(Cloud), и нам, разработчикам, все равно, что выберет покупатель. Более того, лицензионная поставка разработчику существенно выгоднее, поскольку обеспечивает гораздо больший доход. Однако отработанная нами технология предоставления удаленного доступа к ПО посредством сервиса CityCom(Cloud) позволила значительно уменьшить собственные издержки, связанные с авторским сопровождением, поддержкой и внедрением конечных решений. Как следствие, это позволило сильно снизить стоимость использования программ CityCom для конечных приобретателей. В особенности это касается именно проектных организаций, поскольку оплата облачного доступа к программному обеспечению в течение срока реализации проекта обходится в разы дешевле, чем покупка лицензий. Кроме того, платежи в счет оплаты доступа накапливаются на «счетчике» в счет стоимости лицензий, и по истечении времени, необходимого для накопления соответствующей «виртуальной» суммы, такой клиент получает право на собственную лицензию для развертывания на своем сервере без дополнительной оплаты. То есть, фактически, это беспроцентная лизинговая схема приобретения лицензий. Таким образом, получается, что не столько ИВЦ «Поток» отдает предпочтение работе в облаке CityCom(Cloud), сколько Его Величество Рынок.


Далее, авторы пишут: «Вызывает вопрос степень надёжности хранения данных на удаленных серверах» и «Что делать, если произойдет катастрофа?».

Поскольку есть вопросы, то вот и ответы:

Данные пользовательского проекта в CityCom(Cloud) ежесуточно архивируются двумя различными средствами резервного копирования и направляются для резервного хранения в два физически отделенных от сервера и удаленных от него дисковых хранилища. Хранятся: ежесуточные архивы за последние 25 суток, плюс еженедельные копии за три последних месяца, плюс ежемесячные копии за последний год. Кроме того, если пользователю и этого недостаточно, он имеет штатную возможность выгрузки последнего архива собственных данных из облака CityCom(Cloud) на свой локальный диск в любой момент времени, когда пожелает. Как нам представляется, сложно придумать что-то более надежное в части сохранности данных.

Таким образом, если произойдет катастрофа, то последнее, что пострадает – это пользовательские данные. Весь серверный кластер в фоновом режиме зеркалируется в шифрованном виде на альтернативные ЦОДы, физически отдаленные от «рабочего» на сотни и даже тысячи километров. Даже в случае полного разрушения рабочего ЦОДа «подъем» виртуального сервера со всеми пользовательскими данными на альтернативном ЦОДе займет не более суток. В случае катастрофы гораздо больше времени уйдет на спасение пользователями самих себя.


Пару слов про «карты». Цитата из статьи: «...Первичная настройка слоя карты осуществлялась специалистами ООО «ИВЦ «Поток».

Это правда, так оно и было, поскольку в облачном варианте CityCom на момент начала «чукотского» проекта у пользователей еще не было технической возможности загрузки растровых образов карт для их дальнейшей привязки и обработки. Но справедливости ради следует отметить, что на сегодняшний день пользователю CityCom(Cloud) при необходимости доступна загрузка любых картографических материалов со всех открытых интернет-ресурсов, от Яндекс и Google до картографических серверов NASA – в любом масштабе, степени детализации и наборе тайлов. Однако это никак не исключает возможности пользователя обратиться за оказанием помощи по загрузке и координированию подходящих карт к разработчикам, если ему самому лень этим заниматься. Мы за это даже денег не возьмем.


А вот еще один важный нюанс, на который обратили внимание авторы статьи: « ... в CityCom штатными средствами, к сожалению, не получается выделить всех потребителей, имеющих открытую систему ГВС, и закрыть её».

Здесь затронут крайне важный и болезненный вопрос реализации некоторых «массовых» операций над объектами в базе данных. Принципиальная позиция разработчика CityCom по этому вопросу следующая: массовые изменения критически важных паспортных характеристик объектов пользователем подлежат запрету. По той простой причине, что при массовом отборе изменяемых объектов очень высока вероятность того, что в отбор для изменений попадут «лишние» объекты, либо, наоборот, не попадут какие-то из тех, которые должны были в него попасть. Последующий анализ полноты и адекватности произведенных изменений крайне затруднителен, у допущенных ошибок есть немалая вероятность не быть обнаруженными никогда. И если для «одноразовой» проектной работы это, возможно, не слишком принципиально, то для промышленной эксплуатации – совершенно недопустимо, поскольку искажаются данные, востребованные в ежедневном производственном процессе принятия решений. Поэтому в ПО CityCom разработчики пошли по компромиссному пути: в целях моделирования разрешены лишь ограниченные и регламентированные массовые изменения, по которым возможно: (а) сформулировать очень четкий критерий отбора, поддающийся контролю; (б) при необходимости «одним кликом» вернуться в исходное (паспортное) состояние.

В тех случаях, когда пользователю действительно совершенно необходимо выполнить некое четко формулируемое массовое изменение (как в примере, упомянутом в статье), мы предпочитаем, чтобы пользователь обратился к этим запросом к разработчикам. Мы выполним такую просьбу собственными нештатными средствами, и пользователь будет удовлетворен. В этом случае, по крайней мере, есть некоторая уверенность, что массовое изменение проделано максимально корректно, без внесения ошибок и искажений в модель. За услуги такого рода мы не требуем оплаты, они входят в состав технической поддержки и авторского сопровождения, а в случае CityCom(Cloud) – в тарификацию доступа.

Следует отметить, что такая, достаточно жесткая, позиция разработчиков CityCom по вопросу возможности реализации «массовых» операций над объектами цифровой модели обусловлена практикой. За историю развития продукта было несколько прецедентов фактической порчи данных на объектах промышленного внедрения – именно по упомянутым выше причинам. Случайно обнаруженные по прошествии длительного времени искажения данных приводили к необходимости вернуться к адекватным данным из «давней» резервной копии. И при этом либо потерять информацию, накопленную за промежуток упущенного времени, либо привлекать недешевый ресурс разработчика для восстановления данных без потерь. Таким образом, запрет на плохо контролируемые массовые операции в CityCom продиктован интересами защиты адекватности и целостности данных, то есть, интересами самих пользователей.


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

Скриншот фрагмента проекта, описанного в статье В.С.Пузакова, после незначительной «косметической» обработки графического представления модели в CityCom

Рис. 2. Скриншот фрагмента проекта, описанного в статье В.С.Пузакова, после незначительной «косметической» обработки графического представления модели в CityCom.


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

Скачать публикацию статьи в журнале "Новости теплоснабжения" (№2-2018) в формате PDF


Задать вопрос или отправить запрос