Состояние информатизации инженерных коммуникаций: симптоматика, диагноз, исцеление

А.Р. Ексаев, генеральный директор, М.Г. Шумяцкий, технический директор, ИВЦ «Поток», г. Москва

3-я научно-практическая конференция «Тепловые сети. Современные практические решения»

Введение

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

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

Но фактически во всех без исключения предприятиях, эксплуатирующих сети инженерных коммуникаций, в том числе даже и в «образцовых», информатизация в целом очень мучается приобретенными отраслевыми и общесистемными «заболеваниями». Развитие и усугубление этих «недугов» безизбежно понижают общую эффективность управления, приводит к прямым денежным потерям и завышенному риску появления аварийных ситуаций. Если не поставить «правильный диагноз» и не «вылечить» эти трудности впору, неизбежен момент перевоплощения информатики и IT-технологий из инструмента увеличения надежности, свойства и эффективности производства в суровый тормоз либо даже детонатор коллапса в процессе организационно-технологического управления.

Имеющиеся трудности

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

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

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

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

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

Часто случается так, что дешевый программный продукт «хоронит» данные ценой в 10-ки и сотки миллионов рублей. Ситуация феноминальная и невообразимая исходя из убеждений здравого смысла, но все же обычный аудит «прозрачности данных» проявит наличие этой трудности для 70-100% программных систем, применяемых на любом предприятии.

3. Рассогласованность задач и информационных потоков. Фактически все технические, технологические и организационные задачки, которые могут (и должны) решаться при помощи информационных технологий и вычислительных систем, неразрывно связаны вместе по потокам инфы.

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

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

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

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

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

Решение заморочек

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

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

1. Единое информационное место. Информационной основой всего комплекса подсистем, из которых строится разыскиваемая информационная система, должна служить единая база данных общего доступа с кропотливо разработанной структурой, специально созданной для решения очень вероятного количества содержательных эксплуатационных задач. Даже если на исходных шагах какие-то из этих задач кажутся лишними либо заранее заблаговременны, структура информационной модели должна, все же, предугадывать возможность их подключения в следующем без значимой реорганизации уже включенных в систему данных. База данных должна быть снабжена всеми необходимыми пополняемыми и расширяемыми справочниками и классификаторами для адекватного описания сетей и объектов системы инженерных коммуникаций, с полным учетом их технологической специфичности.

Целостность, непротиворечивость и достоверность всей хранимой инфы обеспечивается основным принципом организации информационного места: «Каждая единица инфы должна храниться единственный раз в единственном месте». Все прикладные подсистемы – от паспортизации до ситуационного моделирования – должны получать начальные из общей БД и туда же помещать результаты, которые сразу становятся доступны всем заинтересованным (и допущенным) службам и сотрудникам.

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

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

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

4. Отраслевая специфичность: от «технологического частного» к «информационному общему». Фактически неважно какая предметная область техники и технологии такая, что для «глубокого проникновения» в нее в смысле решения содержательных задач нужно использовать спец средства, разработанные мотивированным предназначением для этой предметной области. Так именуемые «универсальные» IT-инструментарии могут только очень поверхностно, в самом общем виде посодействовать решить более обыкновенные и «универсальные» же задачки, и менее того. И карьерный грузовик, и автобус, и спорткар – имеют движок, коробку и колеса, и на любом из их можно, в принципе, доехать по асфальтированной прямой дороге из пт А в пункт Б. Но не напрасно же есть конкретно эти специальные виды тс, каждое из которых предназначено в точности для решения тех задач, для которых они сделаны. Работая с несколькими упомянутыми выше предметными областями инженерных коммуникаций, мы неоднократно и неоспоримо удостоверились в том, что, даже несмотря на кажущуюся общность задач, любая из их просит совсем специфичных информационных описаний, алгоритмов функционирования и математических моделей. К примеру, методы решения задачки гидравлического расчета, используемые для водопровода, полностью неприменимы для термических сетей, и напротив (очевидно, идет речь не об «академической задачке» из учебника для начинающего гидравлика-теоретика, а о реальной эксплуатационной задачке); вточности такая же картина по подавляющему большинству снаружи «сходных» эксплуатационных и производственно-технических задач. И, если попробовать «собрать» огромное количество личных решений в общее информационное место средством некоторой IT-платформы «универсального назначения», то в 9 случаях из 10 окажется, что эта «универсальная» платформа оказывается неприменима в качестве интеграционной среды из-за отсутствия в ее инструментарии специфичных конструкций, позволяющих правильно отразить аспекты «отраслевых» решений. Во всяком случае, нам не удалось за много лет отыскать довольно действенной и не безрассудно дорогой интеграционной платформы для объединения всей совокупы задач и информационных структур, соответствующих для предметных областей инженерных сетей, и пришлось создавать свою платформу, владеющую признаками традиционной ГИС, CAD-системы и промышленной СУБД. До сего времени этот подход себя стопроцентно оправдывал во всех случаях без исключений.

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

recuperatio.ru