Форум режимщиков

**SinAlbert** » 16 дек 2009, 11:01

~<Krab>~ писал(а) Tue, 15 December 2009 21:13

SinAlbert для начала давай определимся для кого именно пишем,

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

ведь я думаю приорететы у линий тоже есть толи пускать сначала 500 а потом 110 или наоборот, разница есть??? я думаю есть, третье запланированные ремонты (в годовом графике) они не могут "переезжать" правильно я понимаю??.

пока я думаю и трех хватит вот когда будут внятные объяснения по этим хотя бы трем вопросам то можно будет продолжить работу над проектом такого плана.. а не полагаться на интуицию и все остальное..

А какая разница для кого, алгоритм должен работать на всех уровнях. Если у тебя получится программа, которая оптимизирует только по трем-четырем условиям, то мне, например, она не подойдет (также может не подойти и другим РДУ, все зависит от от особенностей схемы ЭС). Несколькими постами выше я наглядно разбирал этапы формирования годового графика, какие условия и т.д.

Еще раз на пальцах что у меня получалось: задаю теже 3 ограничения - в результате все несовместимости переносятся на январь-апрель и декабрь. Но в апреле у нас паводок => для всех транзитов и их шунтов, участвующих в выдаче мощности ГЭС, задаю ограничения с апреля по июнь. В результате прога их опять же двигает на зиму ( а куда еще? весна - паводок, лето и осень - ремонтная компания с кучей несовместимостей). Но имея опыт работы в сетевом предприятии, я прекрасно понимаю, что в этот период ремонт данной ВЛ и не только данной ВЛ не может быть выполнен (сдесь и низкие температуры, и заснеженные зимой и раскисшие весной поля, по которым техника к ВЛ не подойдет и т.д.). Задаю ограничения на ремонт ВЛ зимой - и все, в худщем случае висяк, в лучшем выдается инфа типа "Не могу разнести ремонт ... Задайте период ремонта вручную".

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

~<Krab>~ писал(а) Tue, 15 December 2009 21:13

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

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

~<Krab>~ писал(а) Tue, 15 December 2009 21:13

... мысль конечно есть объединить все РДУ с общей базай на SQL сервере, но есть ли уверенность что у каждого РДУ, ОДУ и так далее есть нормальный канал ineta? при помощи SQL и одной машины можно уже сделать что то похожее на правду, так как там уже можно сделать что то наподобие сводной проверочной таблицы(в базе) что бы мы уже представляли что двигать будут РДУ после ОДУ не попадая с ними в конфликт...

Все эти SQL, серверы, каналы ineta, это все "примочки". Отбрось все лишнее, не распыляйся, есть задача оптимизировать ремонты - надо ее решить (написать рабочий алгоритм) в первую очередь, остальное потом.

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

P.S. Кстати, была у меня мысль заложить приоритет оптимизации (какие ремонты обязательно надо разнести и в ущерб каким). Попробуй, на мой взгляд, это более реально.

**Alex** » 17 дек 2009, 10:56

Мое почтение уважаемому и достопочтейнейшему SinAlbertу.

~<Krab>~у: Создаение единой базы РДУ-ОДУ-ЦДУ утопия. База должна быть у каждой операционной зоны своя. Иначе ЦДУ будет планировать ремонты 110-ок (вот в РДУ уайф будет).

ИМХО. Без расстановки приоритетов ремонтов, задачка их раскидывания не решиться.

**Michael** » 17 дек 2009, 12:00

Alex писал(а) Thu, 17 December 2009 10:56

Создаение единой базы РДУ-ОДУ-ЦДУ утопия. База должна быть у каждой операционной зоны своя

Отнюдь.

Например, жизненный цикл графика:

1. Формирование графика ремонтов на «своем» уровне.

2. Рассмотрение графика ремонтов на «своем» уровне.

3. Согласование графика ремонтов на «параллельном» уровне диспетчеризации.

4. Рассмотрение графика ремонтов после согласования на «своем» уровне.

5. Предварительное утверждение на «своем» уровне.

6. Рассмотрение и утверждение графика ремонтов на «верхнем» уровне.

7. Окончательное рассмотрение и утверждение графика ремонтов на «своем» уровне.

Все это делается при наличии сквозной базы - в ОДУ есть все "своё" из ЦДУ и "своё" из смежных ОДУ, в РДУ есть все "своё" из ОДУ и "своё" из смежных РДУ.

Приоритетность оттуда же растет - все, что утверждено вверху - имеет высший приоритет. Что согласовано с смежниками - второй приоритет по отношению к верхнему и т.д.

Плюс свои внутренние приоритеты - "весовые коэффициенты"

**Alex** » 17 дек 2009, 12:48

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

Объединение уровней можно будет сделать самым последним-препоследним моментом, когда на всех уровнях все будет работать как надо.

ЗЫ: а что такое "Согласование графика ремонтов на «параллельном» уровне диспетчеризации"??? Это когда график ремонта одно РДУ согласовывает с другим и после этого направляет в ОДУ, а ОДУ с ОДУ и в ЦДУ?? Неужто у вас так все происходит?

ЗЗЫ: если уж единую базу то для всех! ЦДУ-ОДУ-РДУ-Субъекты-Филиалы субъектов - и т.д. )))

**Krutya** » 17 дек 2009, 13:03

Alex писал(а) Thu, 17 December 2009 12:48

ЗЫ: а что такое "Согласование графика ремонтов на «параллельном» уровне диспетчеризации"??? Это когда график ремонта одно РДУ согласовывает с другим и после этого направляет в ОДУ, а ОДУ с ОДУ и в ЦДУ?? Неужто у вас так все происходит?

В общем-то, приходится.

Пару раз на грабли наступали, теперь согласовываем.

Alex писал(а) Thu, 17 December 2009 12:48

ЗЗЫ: если уж единую базу то для всех! ЦДУ-ОДУ-РДУ-Субъекты-Филиалы субъектов - и т.д. )))

Гыыы. Зочод! Креативно!!! Laughing

**Michael** » 17 дек 2009, 13:22

Alex писал(а) Thu, 17 December 2009 12:48

а что такое "Согласование графика ремонтов на «параллельном» уровне диспетчеризации"??? Это когда график ремонта одно РДУ согласовывает с другим и после этого направляет в ОДУ...??

А как же иначе??? Удивили...

Хотя, может в изолированной системе работаете?

**Michael** » 17 дек 2009, 13:35

ПО Ремонты в функциях должно иметь то же, что есть в ПК Заявки - в том числе и дерево объектов с подчиненностью и разделением прав на изменения. Верхний уровень дает и редактирует свои объекты, смежники свои, низы - свои. И таки да - это и будет единой базой

**Alex** » 18 дек 2009, 08:06

Michael писал(а) Thu, 17 December 2009 13:22

А как же иначе??? Удивили...

Хотя, может в изолированной системе работаете?

Да вовсе не в изолированной, только вот я чтото такого порядка в регламентах не встречал...

Эт получается, что наше РДУ перед утверждением должно согласовать свой допустим месячный график с четырьмя РДУ и одним государством, и это сделать в три-пять дней, и ОДУ должно согласовать свой график с тремя ОДУ и одним государством и тоже в сжатые сроки. Насколько я знаю, такого у нас не происходит.... да и виз согласования я ниразу не видел...

**Michael** » 18 дек 2009, 08:55

Отсутствие согласования с соседями в регламентах - эпикфейл разработчиков.

Вот мое видение проблемы (сорри многа букф):

Проблемы при формировании годовых графиков:

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

После получения графика ОДУ рассмотрение годового графика РДУ (12 месячных) всего за 5 дней затруднительно. Кроме того, в этот же срок необходимо провести согласование со смежными РДУ по изменившимся срокам ремонтов межсистемных связей. При этом срок направления в организации утвержденных графиков растянут на 15 дней.

Предложение – поменять местами сроки рассмотрения графика и направления в организации – на рассмотрение 15 дней (с 25 сентября до 10 октября), на отправку 5 дней (до 15 октября).

2. Несоблюдение сроков получения графика из ОДУ – в 2008 году график на 2009 год получен 5 ноября.

Проблемы при формировании месячных графиков:

1. Очень сжатые сроки для организаций – при получении организациями графиков 30-го числа, подать плановые заявки на первые дни месяца невозможно – заявки должны подаваться не менее чем за 5 дней (также противоречие с мониторингом ремонтов). Также у организаций часто возникают проблемы при переносе в графике работ, выполняемых подрядными организациями, иногда – до полного срыва работ.

Предложение – изменить сроки формирования графиков для высвобождения запаса времени для изменения планов организаций.

2. Как и в процедуре годового графика – недостаточный срок для рассмотрения и формирования графика в РДУ с учетом графика ОДУ – всего 2 дня. В период ремонтной кампании рассмотрение графика может проходить в 5 «чтениях» и согласованиях со смежниками.

И то же предложение – поменять местами сроки рассмотрения графика и направления в организации – на рассмотрение 6 дней, на отправку 2 дня.

Общие проблемы для годовых и месячных графиков:

1. В Регламенте СО не установлена процедура согласования со смежными РДУ. В некоторых РДУ такое согласование записали в свой регламент, но общего срока и процедуры нет.

Ремонты межсистемных связей сейчас проходят через РДУ в ОДУ по принципу - «чей ПМЭС ремонтирует – то РДУ и подает». Например, ВЛ 220 кВ Костромская ГРЭС – Ярославская. Заявка от Волго-Окского ПМЭС идет через Костромское РДУ с предварительным согласованием с Ярославским, а заявка от Валдайского ПМЭС – через Ярославское РДУ с костромским согласованием.

Также были случаи, когда заявки вообще проходили мимо РДУ. Например, та же ВЛ 220 кВ Костромская ГРЭС – Ярославская в феврале запланирована в графике ОДУ на ремонт с 9 по 13. Причем ни от Ярославского, ни от Костромского РДУ заявок не было. В старых положениях по ремонтам было указано, что «ПМЭС предложения в план ремонта также направляют в МЭС». Возможно, параллельная цепочка ПМЭС-МЭС-ОДУ до сих пор действует.

Предложение – упорядочить процедуру рассмотрения заявок, возможно следующим образом:

- организации направляют заявки в диспетчерский центр, в чьем управлении находятся ЛЭП и оборудование;

- «управляющий» диспетчерский центр согласовывает сроки с РДУ, в чьем ведении находятся ЛЭП и оборудование, изменяет сроки при необходимости;

- предварительный график в ОДУ направляет всегда «управляющее» РДУ после обязательного согласования с «ведающими» РДУ. Заявки из МЭС ОДУ не рассматривает.

3. Сетевые компании, в первую очередь Волго-Окское ПМЭС, практикуют «вбрасывание» заявок в графики вообще без какой-либо предварительной проработки и обдумывания. Например, был случай, когда ВОПМЭС одновременно запросило отключение трёх из трёх питающих энергорайон ВЛ 220 кВ (Мотордеталь – Борок, Кострома – Галич и Рыжково – Мантурово, последний источник для этого района – АТ-1 500/110 кВ ПС 500 кВ Звезда через ВЛ 110 кВ, тоже приходящих на подстанцию ВОПМЭС). Часто требуется много времени на развод по срокам очевидных несовместимых отключений. Рычагов воздействия на компании нет.

4. В графиках ОДУ не указываются причины отказов или переносов сроков.

5. Необходимо однотипное программное обеспечение для формирования графиков ремонтов с обменом информации с ПК «Заявки» (или вообще на базе ПК «Заявки»). Формат Microsoft Project крайне неудобен для анализа, выборок и другой обработки информации.

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

7. Желательно, чтобы в регламентах было такое положение:

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

По РЗА подобное положение в регламенте есть.

Говорил с ОДУ, отправлял им это - всем пох.

**Krutya** » 18 дек 2009, 16:08