Журнал «ИСУП». (Информатизация и системы управления в промышленности)
ИТ, КИПиА, метрология, АСУ ТП, энергетика, АСКУЭ, промышленный интернет, контроллеры, экология, электротехника, автоматизации в промышленности, испытательные системы, промышленная безопасность

Проблемы информатизации управления ТОиР электрических сетей

Статья продолжает публикацию автора в номере 1(13) журнала «ИСУП» за 2007 год «Информационная поддержка эксплуатации энергооборудования», в которой рассматривалось два проекта внедрения ИСУ ТОиР сетевого энергетического оборудования предприятий ОАО «Юганскнефтегаз» и ОАО «Самаранефтегаз».

НПП «СпецТек», г. Санкт-Петербург 

Spectek.gif

На текущий момент электроэнергетика как отрасль у всех на слуху. Кроме эмиссии акций и громких приобретений энергетических компаний инвесторами, в июле 2008 года состоялось еще одно знаковое событие — прекращение деятельности РАО «ЕЭС России». Между тем в такой принципиально монополистической сфере, как распределительные электрические сети, происходят не менее значимые изменения, а именно: создание квазиконкурентной среды.

Основным инструментом реформ здесь становится новый порядок формирования тарифов RAB (Regulatory Asset Base), который, как ожидается, позволит привлечь кредитные организации к участию в обновлении основных фондов, преодолеть негативные тенденции в этой сфере. Новшество RAB состоит в том, что стоимость обслуживания кредита (норма доходности) и плата за возврат самого кредита будет отражаться в тарифе в явном виде — то есть появится определенность в платежеспособности сетевой компании по кредиту. В перспективе при переходе к пятилетнему периоду регулирования тариф станет более стабильным, и инвесторы смогут снизить свои риски при долгосрочном кредитовании. Отраженная в тарифе база, предназначенная для оплаты по кредиту, будет определяться рыночной стоимостью активов сетевой компании с учетом их износа — это даст стимул направлять акционерный и заемный капитал на обновление и восстановительные ремонты основных фондов. Регулятор в лице государства, задавая тренд снижения затрат и оставляя «сверхплановую» экономию за компанией, будет тем самым стимулировать снижение издержек. Участие регулятора, как предполагается, будет также проявляться в применении  повышающих коэффициентов или вычетов к тарифам в зависимости от показателей надежности энергоснабжения и удовлетворенности потребителей. Базовые значения показателей будут определяться путем их сравнения и усреднения в 11 сопоставимых по размерам операционных Межрегиональных распределительных сетевых компаниях (МРСК). Это приведет к тому, что компании данного монопольного сектора будут вынуждены конкурировать за надежность и качество сервиса.

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

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

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


Проблемы внедрения ИСУ ТОиР

Прежде всего, предприятие должно уйти от подхода, при котором руководство считает: мы оплатили программный продукт, оплатили услуги подрядчика по его внедрению, и теперь пусть он сам сделает нам все как надо, это теперь исключительно его забота. Каким бы опытным ни был подрядчик, без организационной поддержки, административного ресурса и активного участия заказчика ему не справиться с «человеческим фактором» в проекте. Приведем примеры, известные нам из проектов ИСУ ТОиР в сетях, которые мы внедряем на основе программного обеспечения TRIM собственной разработки.


Проблемы обучения

Обязательным этапом является обучение пользователей ИСУ ТОиР. Негативный факт состоит в том, что пользователи среднего и низшего звена идут на обучение, как на каторгу, со словами: «Нам и так не хватает времени, а тут еще сверху какой-то TRIM спустили»; отсюда соответствующее отношение к занятиям. В этом случае заказчик и подрядчик должны совместно найти такие точки соприкосновения интересов, которые позволили бы убедить пользователей, что в конечном счете благодаря использованию системы, их время наоборот высвободится — то есть указать на трудоемкие моменты из повседневной практики, на которые за счет автоматизации будет затрачиваться меньше времени.

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

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


Текучесть кадров

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

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


Проблемы развертывания системы

Проект усложняется из-за принципиальной распределенности сетевой компании по большой территории и, как правило, низкого качества каналов связи между офисом и сетевыми районами. Для того чтобы удаленные пользователи не испытывали проблем с доступом к информации, приходится создавать распределенную базу данных, с локальными базами, разбивать ИСУ ТОиР на узлы (о распределенной базе данных и узлах см. на сайте www.trim.ru).

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

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


Проблемы использования системы

Эксплуатация подсистемы нарядов и допусков, например в TRIM, предполагает, что сначала в ИСУ ТОиР создается работа как объект, а к ней привязывается наряд — пользователям бывает трудно привыкнуть к тому, что именно в таком порядке, а не наоборот. В состав наряда автоматически вписываются условия безопасности, которые извлекаются из базы данных по условиям безопасности с привязкой к оборудованию и работе. Проблема возникает тогда, когда условий безопасности нет в готовом виде и соответствующую базу данных приходится накапливать по мере эксплуатации ИСУ ТОиР, в ходе выполнения работ. При этом записи в базу несут на себе отпечаток конкретного исполнителя, вносившего запись, и не всегда другие пользователи могут точно понять, что имелось в виду. В данном случае требуется разработать строгий регламент ведения базы данных по условиям безопасности или другие меры.

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

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


Функциональность программного продукта

Программное обеспечение, на основе которого строятся ИСУ ТОиР, представлено в России достаточно широко, в том числе от российских разработчиков. Это специализированные программные продукты,  относящиеся к классу EAM (Enterprise Asset Management) или CMMS (Computerized Maintenance Management System), изначально созданные под потребности автоматизации процессов ТОиР. К базовым возможностям таких продуктов относятся ведение структуры оборудования; создание и ведение справочника запчастей; автоматическое планирование работ; автоматизированное составление ремонтных ведомостей; заказ запчастей; формирование заявок на закупку запчастей; формирование приходных и расходных документов; ведение журнала выполненных работ; списание запчастей; формирование актов инвентаризации; учет состояний оборудования; управление эксплуатационной документацией и другие.

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

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

C функциональной точки зрения проектная документация должна содержать ряд требований к возможностям продукта и соответственно, ИСУ ТОиР, которые делятся на базовые и отраслевые. Основываясь на накопленной функциональности отраслевого решения на базе TRIM и на опыте взаимодействия с сетевыми компаниями при внедрении ИСУ ТОиР на базе TRIM, можно выделить ряд основных возможностей, составляющих отраслевую специфику программного продукта.


Паспортизация оборудования сетей

- Инструмент формирования дерева объектов сети должен обеспечивать достаточную степень детализации, многоуровневости учета, с возможностью группирования оборудования по районам, фидерам и т.д;

- в ИСУ ТОиР каждая учитываемая единица оборудования привязывается к схемам сетей (нормальным, оперативным, поопорным, расчетным и т.п.); изображения учтенных объектов на схемах сетей используются как точки оперативного доступа к полным данным по каждому объекту — формулярам, узлам и запчастям, работам по ТОиР, присоединенным к нему потребителям, паспортам, документации по объекту; 

- пользуясь взаимосвязью объекта и схемы, а также накапливая историю перемещений, можно в каждый момент времени определять место нахождения, техническое и эксплуатационное состояние (рис. 1) каждой единицы оборудования; 

pic1.jpg

Рис. 1. Учет эксплуатационного состояния оборудования

- из удаленных подразделений в единую базу данных стекается оперативная информация  — об изменении состава оборудования в районах сетей; об изменении схем сетей, передаются актуальные схемы, измененные параметры сетей и т.д. (рис. 2); обеспечивается согласованное ведение схем и описаний по одним и тем же объектам в разных службах;

pic2.jpg

Рис. 2. Состав оборудования и актуальные схемы сетей

- в управляющем офисе централизованно формируется база нормативно-справочной информации по объектам учета и передается в удаленные подразделения.


Управление надежностью энергоснабжения

- В ИСУ ТОиР реализуется автоматизированное планирование ремонтов не только по календарю, наработке, но и по критерию важности оборудования, чтобы в первую очередь выполнять ремонт того оборудования, выход из строя которого достаточно вероятен по его состоянию и нанесет наибольший ущерб надежности работы всей сети; 

- в ИСУ ТОиР ведется контроль планирования и выполнения осмотров и обследований, автоматизируется сбор и анализ данных о дефектах, выявленных в ходе их проведения (рис. 3); анализ дефектов (повреждаемости) может быть проведен  в разных разрезах — в масштабе всей сети, предприятия, района сети, филиала, отдельной подстанции, фидера, по виду оборудования и т.д.; это позволяет своевременно отреагировать на дефект, устранить его и предотвратить возможное отключение потребителей;

pic3.jpg

Рис. 3. Информация о дефектах и обследованиях

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

- для тепловых сетей ИСУ ТОиР обеспечивает информационную поддержку подготовки к отопительному сезону; весь необходимый объем работ готовится заранее (объект, наименование и содержание работы, привлекаемые ресурсы, сроки, статус, связи между работами); сформированный массив данных каждый сезон можно использовать в качестве типового, к нему добавляются нетиповые работы; в итоге все необходимые к определенной дате работы будут запланированы, все требуемые для них ресурсы предусмотрены; анализ хода выполнения работ может быть проведен в разрезе районов сетей, предприятий, филиалов; на основе поступающих в систему отчетов можно формировать сводные отчеты; в системе хранится и может быть оперативно извлечена справочная информация к тепловым комиссиям; аналогичный механизм формирования типовых ремонтных ведомостей реализуется в ИСУ ТОиР электрических сетей (рис. 4);

pic4.jpg

Рис. 4. Формирование ремонтных ведомостей

- в ИСУ ТОиР формируется и поддерживается в актуальном состоянии база данных о правильном и безопасном выполнении работ по ТОиР, с привязкой к конкретным типовым работам; при выдаче наряда (распоряжения) на работу все условия ее выполнения автоматически попадают в наряд и распечатываются для выдачи исполнителям; тем самым снижается количество ошибок персонала при ТОиР, уменьшается число отключений потребителей по этим причинам; 

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

- в ИСУ ТОиР доступна актуальная информация о наличии запчастей, материалов, оснастки, имеется возможность дозаказывать недостающие позиции с автоматическим учетом остатков;  минимизируется длительность отключения потребителей за счет сокращения времени подготовки ресурсов к аварийно-восстановительным работам.


Управление издержками на ТОиР

- Имеется возможность сопоставлять потери от недопоставки энергии и ремонтные затраты, требуемые для предотвращения этих потерь, находить баланс между ними; имеется возможность выбирать допустимую стратегию ТОиР для разных групп оборудования — ремонт по отказу, предупредительное, прогнозируемое, замена оборудования, и обеспечивать работоспособность при минимально возможном уровне затрат;

- в ИСУ ТОиР хранится история использования товарно-материальных ценностей (ТМЦ), имеются возможности ретроспективного анализа и определения необходимого объема запаса ТМЦ для аварийно-восстановительных работ; объем закупок ТМЦ для планового ТОиР автоматически формируется непосредственно из графика ТОиР благодаря информационной связи «работа — запчасть», с учетом остатков ТМЦ на складах; секвестирование плана работ ведет к автоматической коррекции плана закупок ТМЦ; в итоге устраняются необоснованные объемы закупок и складских запасов;

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

- работы информационно связаны  со складскими данными, видны расхождения в складском и ремонтном учете, можно получать фактические данные по материально-ответственным лицам, контролировать обоснованность списания ТМЦ; 

- обеспечивается учет наработки — автоматически, путем конвертирования данных АСУ ТП об эксплуатационном состоянии оборудования и при ручном вводе диспетчерских данных; автоматическое планирование ТОиР имеет опцию планирования и перепланирования по наработке, что дает возможность перейти на практике к циклам, учитывающим достигнутые наработки по конкретным типам оборудования; 

- имеется модуль интеграции ИСУ ТОиР с системами диагностики, позволяющий автоматически получать данные о техническом состоянии; имеются средства предварительного ввода критических и аварийных значений параметров, а также средства автоматического мониторинга и визуального представления их текущих значений; имеется возможность коррекции плана-графика работ и плана закупок ТМЦ с учетом технического состояния; 

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


Заключение

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

Статья опубликована в журнале «ИСУП», № 3(19)_2008

И.Н. Антоненко, начальник отдела маркетинга,
НПП «СпецТек», г. Санкт-Петербург,