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

Автоматическую систему сделать можно, в том случае если у нас будет полная база всех РДУ и полная схема сетей

В этом случае можно уже будет прогнозировать что будет работать и как оно будет работать.

Все дело в том что: В каждом РДУ есть алгоритм развода линий, причем он в каждом РДУ одинаковый если не ошибаюсь.

Но есть опять же одно единственное но.. а именно как мы можем утверждать что при разводе линий мы не попадем в противовес с другим РДУ? Отсюда вывод если делать полностью автоматизированную систему то надо полные базы, желательно собранные в одном месте и канал связи что бы каждое РДУ работало с одной базой..ну и так далее..

Впринципе ничего сложного и не возможного в этом нет..

ТЗ я смотрел и если честно там это и воплощается, тока почему такие задержки не понятно...

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

Моя программа пока написана на MS Acsess, так как он есть в каждом РДУ лицензионный.

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

~<Krab>~ писал(а) Mon, 14 December 2009 23:07

...Все дело в том что: В каждом РДУ есть алгоритм развода линий, причем он в каждом РДУ одинаковый если не ошибаюсь. Но есть опять же одно единственное но.. а именно как мы можем утверждать что при разводе линий мы не попадем в противовес с другим РДУ?...

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

1. Сбор предложений от субъектов, составление сводного графика, выделение из него оборудования для вышестоящего диспетчерского центра и его оптимизация.

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



2. На уровне ОДУ (с учетом утвержденного графика от вышестоящего дисп. центра) происходит своя оптимизация. Именно сдесь решается задача как не попасть в противовес с другими РДУ.



3. Теперь для РДУ начинается самое интересное (впрочем, как и для ОДУ, после получения графика от вышестояших командиров).

Пусть имеем несрвместимые ремонты оборудования А,В и С. Ремонт А несовместим с В, причем А двигать нельзя, т.к. он утвержден вышестоящим дисп.центром.

Начинаем двигать ремонт Б, хоп, он "налазиет" на ремонт С, с которым тоже несовместим. Что дальше двигаем А или С (имею в виду именно программуную раздвижку)? По логике, надо продолжать двигать В, чтобы закончить цикл и начать новый для С.

Для ремонта С выявляются несовместимости с другими, причем ремонт В трогать для устранения несовместимости с С нельзя, т.к. он (В) разнесен с ремонтом А.

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

В итоге получается путанница из условий If..Then..Else, в которой уже и сам не можешь разобраться.



Поэтому в каждом РДУ алгоритм развода линий практически одинаковый (как в одном из постов писал Alex) - "На основе личного опыта, знаний и интуиции".

Кратко о задачах, которые мы поставили перед ~<Krab>~:

1. Единый интерфейс для подачи предложений в графики от всех предприятий. Единый и простой. (Сейчас много времени уходит на простое причесывание всех заявок - разные форматы, ошибки. Наример - все оформляют заявки в соотв. с утв. формой, но кто в ворде, кто в экселе, а в экселе - так даты не в формате даты, и пр. и пр. Заявки бывает подают не на объекты диспетчеризации - на ЛР ВЛ, например. И прошу вас о "воспитании" предприятий не говорить - фик их воспитаешь. Пока не исключить возможность неправильного ввода - накосячат обязательно). Реализовано.

2. Построение наглядного сетевого графика с возможностью гибких фильтраций и разнообразных выборок (например - требуется выделить для наглядности в отдельный сетевой график некий район с разными предприятиями, ПС, ВЛ, разных классов напряжения. Сейчас, в принципе, я все это легко и просто делаю в excel - сетевой график автоматом и прочее. например - см. вложение). Реализовано.

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



"Синтез" графика в задачу не ставили, т.к. нет четкого видения путей решения.



Теперь о насущном - ~<Krab>у, естественно, хочется профит с работы поиметь. У нас, к сожалению, не получилось. Я посоветовал здесь и запостить - если кто заинтересуется.

Это все не спорю интересно..

1) во первых мы рассматривали ремонты месячные

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

3) Жизнь РДУ можно даже просто облегчить тем что просто показать то что уже менять нельзя (если оно у них будет хотя бы перед глазами все это и будут возможности проверок и то это я думаю будет им большим плюсом)

4) если делать автоматический развод то в "If..Then..Else" и прочем путаться тоже нечего, да может конечно и так получиться что их не хватать будет и придется вводить искуственный интелект (Нейронные сети и прочее)

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

а не как это бывает : числится тока на бумаге и больше нигде..

Michael все дело в основном в том, что:

1) если отдать прогу то это то не проблема, проблема в том что ее доработать надо (подумаем на практике преддипломной, которая еще не началась:))

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

вопрос только в том что какой кусочек они урвут)))

Michael писал(а) Tue, 15 December 2009 08:17

Кратко о задачах, которые мы поставили перед ~<Krab>~: 1. Единый интерфейс для подачи предложений в графики от всех предприятий. Единый и простой. (Сейчас много времени уходит на простое причесывание всех заявок - разные форматы, ошибки. Наример - все оформляют заявки в соотв. с утв. формой, но кто в ворде, кто в экселе, а в экселе - так даты не в формате даты, и пр. и пр. Заявки бывает подают не на объекты диспетчеризации - на ЛР ВЛ, например. И прошу вас о "воспитании" предприятий не говорить - фик их воспитаешь. Пока не исключить возможность неправильного ввода - накосячат обязательно). Реализовано. 2. Построение наглядного сетевого графика с возможностью гибких фильтраций и разнообразных выборок (например - требуется выделить для наглядности в отдельный сетевой график некий район с разными предприятиями, ПС, ВЛ, разных классов напряжения. Сейчас, в принципе, я все это легко и просто делаю в excel - сетевой график автоматом и прочее. например - см. вложение). Реализовано. 3. Анализ графика на недопустимые совпадения (костыль для "личного опыта, знаний и интуиции"). Реализовано. "Синтез" графика в задачу не ставили, т.к. нет четкого видения путей решения. Теперь о насущном - ~<Krab>у, естественно, хочется профит с работы поиметь. У нас, к сожалению, не получилось. Я посоветовал здесь и запостить - если кто заинтересуется.

Да это у меня и так реализовано, вся изюминка как раз в том, чтоб программа сама разносила ремонты!

А так, что имеем, график и несовместимости. Перенесли какой-либо ремонт - прогнали вновь на совместимость, и так до полного устранения последних.

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



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

SinAlbert писал(а) Tue, 15 December 2009 09:23

Да это у меня и так реализовано...

Вы в шоколаде а мы еще нет. Вы стираете Тайдом, а мы кипятим

И если у вас эта подзадача уже решена - может поделитесь?

SinAlbert писал(а) Tue, 15 December 2009 09:23

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

Дык разнос по месяцу осуществить можно в автомат режиме, вопрос какие условия расставлять

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

ну и так далее)) вопрос сколько еще и каких именно условий на это дело накладывать...))

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

SinAlbert писал(а) Tue, 15 December 2009 09:23 Хочется полной автоматизации процесса, хоть по месячным, хоть по годовым графикам. Дык разнос по месяцу осуществить можно в автомат режиме, вопрос какие условия расставлять Например можно сделать что бы не возможных соединений не было, прога подумает но сделает, но опять же есть еще и линии которые отмечают по номиналу, соответственно 500 Кв в первую очередь будет раскидываться.. ну и так далее)) вопрос сколько еще и каких именно условий на это дело накладывать...))

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

Michael писал(а) Tue, 15 December 2009 10:15

SinAlbert писал(а) Tue, 15 December 2009 09:23 Да это у меня и так реализовано... Вы в шоколаде а мы еще нет. Вы стираете Тайдом, а мы кипятим И если у вас эта подзадача уже решена - может поделитесь?

Поделиться не проблема, но есть одно маленькое "но": я не писал к ней никаких HELPов, если у моего персонала возникали вопросы - объяснял на месте. Попробую в выходные сваять инсталяшку.

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

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

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

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

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

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