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

Коллеги, если не жалко поделитесь опытом написания ТЗ на ПА. Прежде всего интересуют АОПО, АОСН, кнопки САОН. Интересует состав информации, форма ТЗ, всякие мелочи, которые можно прощёлкать. Ну, например, не делал ли кто-нить изменения уставок АОПО в зависимости от фактического изменения температуры. Вроде полезно и не сложно. вдруг делали... Ну и т.д. Вдруг полезные решения лежат под ногами.

Оптимальный вариант - дайте сами ТЗшки. Не знаю секретная ли это информация, если что - работаю в СО. Можно через ЛС. Icq в личной информации присутствует. Буду благодарен.

Тут больше вопросы СРЗА. СЭР должен в ТЗ определить алгоритм (фактор срабатывания) и УВ (вид, объем). Уже на основании этого СРЗА должно предусматривать где что контролировать (ТТ ВЛ?, ТН?)где и как учитывать переход на ОВ и другие оперативнык переводы. Обратить внимание нужен ли УРОВ по факту ПА.



примерно по пунктам

1. Основание для проектирования - документ какой-нибудь, например протокол совещания.

2. Обоснование для проектирования. краткое описание ЗАЧЕМ



3. Цель работы.

Разработка проектной документации на ввод в эксплуатацию нового устройства ..... на ПС ......



4. Основные характеристики устройства .... ПС 110 .....

Собственно описание устройства



5. Основное содержание работы.

Выполнить Принципиальную схему, выбор устройства, схемы вторичных соединени, предварительный расчет уставок, .....



6. Основные нормативно-технические документы (НТД), определяющие требования к проекту:



7. Перечень и комплектность результатов работы, подлежащих приемке Заказчиком.



8. Необходимые исходные данные, предоставляемые заказчиком.

Также в ТЗ следует добавить следуещее:

1. Предусмотреть схему расстановки УПАСК и устройств ПА в сети N кВ (в районе реконструируемой ПС)

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

3. Привести алгоритмы используемых ПА

4. Привести привязку устройств ПА к УПАСК

5. Провести модернизацию ЦКПА (если имеется) и ее каналов связи в соответствии с внесенными изменениями системы ПА

п.1 и п.2 лучше делать на одной схеме, нагляднее получается. это и называется принципиальная схема системы ПА. И "Предусмотреть схему" ИМХО как то не красиво, уж лучше "Выполнить принципиальную схему системы ПА на которой указать: расстановку УПАСК, ПА, передаваемые и принимаемые команды ПА, сбор доаварийной информации, .........."



п.3 если ПА микропроцессорные програмируемые - ОБЯЗАТЕЛЬНО надо. Для электромеханики??? ИМХО принципиальной схемы устройства и описания достаточно.



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



А вот если необходимо построение новых каналавов связи или реконструкция старых, необходимо в ТЗ заложить "выполнить схемы организации каналов связи", а то все сделают а каналы забудут, и чего без них делать

По поводу алгоритмов устройств могу сказать как проектировщик:

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

Иначе, в результате наличия требования в ТЗ в виде "Представить алгоритмы устройств" приходится вносить в проект какую-то ерунду, не имеющей технической ценности.

Че то вы не то говорите. Во первых почти все устройства ПА имеют свободную логику (например в МКПА Прософт-систем может зашить что скажите) и Алгоритмы для них разрабатывают проектировщики по составленным тех требованиям. Жесткую логику обычно имеют устройства РЗА,

Цитата:

Ведь никто не требует привести алгоритмы всех защитных функций терминалов РЗ???

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

Цитата:

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

Зачем городить городьбу вокруг устройства когда можно перепрограмировать само устройство. Кстати слышал про случии когда и в устройствах РЗА подстраивали логику, например делали не 4, а 5-7 ступеней ТЗНП.

Цитата:

Иначе, в результате наличия требования в ТЗ в виде "Представить алгоритмы устройств" приходится вносить в проект какую-то ерунду, не имеющей технической ценности.

Обычная практика работы с проектировщиками, говоришь им сделать нормальные вещи, а они ерунду делают.

Lexxa писал(а) Fri, 23 July 2010 05:47

Обычная практика работы с проектировщиками, говоришь им сделать нормальные вещи, а они ерунду делают.

Золотые слова (с)

Добрый день!

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

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

Отобразить это можно блок-схемами, либо подобием логических схем типа Softconstructor но без детализации. Чего в принципе достаточно для стадии П?

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

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

ИМХО на стадии проектирования недостаточно определить только технические требования, надо еще как минимум:

1. выполнить предварительный расчет уставок,для подтверждения принципов выполнения и уточнения количественного состава устройств.

2. Выполнить выбор оборудования.



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

Ну и выполнить ориентировочный расчет затрат на оборудование и СМР не повредит.

Просто часто основной вопрос возникает именно в алгоритмах. Могу на ваш суд привести подобную ситуацию:

1. По ТЗ на стадии П требуется описание алгоритма, что выполнено словами, н-р (простейший случай, при понижении напряжения с выдержкой времни вкл 1 БСК, потом вторая БСК, а потом откл нагрузки и приписка, на стадии Р разработать полные схемы алгоритма со всеми влияющими блокировками). Описаны все ТТ к оборудованию АОСН, Места подключений к ТТ и ТН, места куда поставить панель и даже двери в ОПУ, чтобы панель пролезла)) Вот к сожалению выбрать оборудование на стадии П не получится, а в тендере это определится.

2. Начинается рабочка, следующий исполнитель читает фразы про блокировки и задает непонятно кому вопрос - так а что заводить то?? и как это вписывать в алгоритм?? И начинается перепалка между стадиями П и Р, кто и что должен. А хуже всего, что вроде как нет единой нормы - где и как должны быть описаны эти пункты.

3. Бывали случаи - видел я даже рабочку без полных алгоритмов - типа, "пусконаладка сама сделает".

Вопрос : Что и в каком виде алгоритмов должно быть на стадии П и Р????