Рецензия на метод. рекомендации по проектированию АС

[san]

Сейчас нашел время поковыряться в методичке по ТЗ. Наткнулся на тот факт, что в требованиях к показателям назначения в разных ТЗ пишут разные вещи. Так в стандарте написано:

2.6.1.3. В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы по назначению.
Для АСУ указывают:
- степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;
- допустимые пределы модернизации и развития системы;
- вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

Я так понимаю с этих немногочисленных предложений, что нужно указать те параметры при которых система будет выполнять возложенные на нее функции а также возможность ее модернизации. Тоесть:
- время работоспособности системы, при ее постоянном обслуживании (требования к обслуживанию должно даваться в эксплуатационной документации);
- возможность измениния алгоритмов управления (модернизация на програмном уровне);
- возможность модернизации и наращивания системы (добавление новых узлов или подсистем).
Нужно ли приводить тут перечень технологических параметров объекта управления, при которых система должна обеспечивать свою работоспособность (например амплитуды и частоты колебаний технологических параметров, принимаемых как возмущение; требования к параметрам енерго/водо/воздухо/.../снабжения)?
CHANt, Вы предложили сюда указывать

С какой периодичностью обновлять данные на мнемосхеме, измерять в контроллере? Время реакции на аварийные сигналы?

Может стоит это все вынести в требования к функциям и задачам системы?
Можно ли в этом разделе ТЗ написать общие положения подобно первому варианту методички и сослаться на конкретный раздел требований к функциям и задачам системы?
Хотя, я четко понимаю, что многие вещи (например параметры возмущений, при которых система справится) зачастую определяются в процессе пусконаладки. По этой причине в ТЗ их вынести юудет тяжеловато. Но в любом случае минимальные гарантированные требования должны конечно же прозвучать. Можно конечно взять эти минимальные требования как за максимальные показатели....
Вобщем, какие ваши советы по этому поводу?

[san]

Примеры на
- Требования к надежности и
- Требования к безопасности
есть. Может кто б теорией снабдил. Знаю что у Фёдорова целый том есть, но думаю что за такой короткий срок неосилю. Может есть какие-то методичики или основополагающие ГОСТы. Поделитесь ссылочками плиз.

[san]

Примеры на
- Требования к надежности и
- Требования к безопасности
есть. Может кто б теорией снабдил. Знаю что у Фёдорова целый том есть, но думаю что за такой короткий срок неосилю. Может есть какие-то методичики или основополагающие ГОСТы. Поделитесь ссылочками плиз.

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

[CHANt]

Я так понимаю с этих немногочисленных предложений, что нужно указать те параметры при которых система будет выполнять возложенные на нее функции а также возможность ее модернизации. Тоесть:
- время работоспособности системы, при ее постоянном обслуживании (требования к обслуживанию должно даваться в эксплуатационной документации);
- возможность измениния алгоритмов управления (модернизация на програмном уровне);
- возможность модернизации и наращивания системы (добавление новых узлов или подсистем).
Нужно ли приводить тут перечень технологических параметров объекта управления, при которых система должна обеспечивать свою работоспособность (например амплитуды и частоты колебаний технологических параметров, принимаемых как возмущение; требования к параметрам енерго/водо/воздухо/.../снабжения)?
CHANt, Вы предложили сюда указывать

С какой периодичностью обновлять данные на мнемосхеме, измерять в контроллере? Время реакции на аварийные сигналы?

Может стоит это все вынести в требования к функциям и задачам системы?
Можно ли в этом разделе ТЗ написать общие положения подобно первому варианту методички и сослаться на конкретный раздел требований к функциям и задачам системы?

Одно дело когда это типовое техзадание или тех требования, другое дело когда Вы на конкретную систему даете конкретные цифры. Ведь обновление видеокадра по факту настраивается в самой СКАДе, в настройках окна. Тоже самое, если есть определенные требования к измерениям и, например, к ведению массива информации с заданной периодичностью, то самое место указать цифры. Если хотите отнести к другим разделам, тогда резонный вопрос - зачем оставлять этот? Чтоб по ГОСТу было? Это формализм. Зачем учить этому?

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

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

[san]

Одно дело когда это типовое техзадание или тех требования, другое дело когда Вы на конкретную систему даете конкретные цифры. Ведь обновление видеокадра по факту настраивается в самой СКАДе, в настройках окна. Тоже самое, если есть определенные требования к измерениям и, например, к ведению массива информации с заданной периодичностью, то самое место указать цифры. Если хотите отнести к другим разделам, тогда резонный вопрос - зачем оставлять этот? Чтоб по ГОСТу было? Это формализм. Зачем учить этому?

Следовательно описанию в стандарте к ТЗ - это вроде как не тот раздел, чтоб указывать периодичность обновления переменных. Это вроде как относится к функции индикации, и должно быть отображенно в требованиях к функциям системы, ИМХО. Во многих примерах, высланых Вами, периодичность обновления перемнных тоже в требованиях к функциям приведены. А этот раздел, я так понимаю нужен для определения тех границ, в каких система справляется со своей задачей. Это типа, если газа не будет - яишницу наша сковородка, оснащенная автоматикой, не приготовит; а если газ будет с очень низким давлением - то яишница не приготивится за 2 минуты, как обещано разработчиками; яишница заданого качества (с голубой корочкой сверху, не поджарена снизу) будет готовится 2 минуты только в пределах температуры в комнате -10...40 град цельсия. ИМХО

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

Привод - это как пример? Я что имел ввиду - если мои понимания предназначения раздела верны, то при постановке задачи, параметры объекта определяется при описании объекта управления. Так, для примера высше (не знаю что меня на яишницу потянуло :-) ), температура в комнате определена от 20 до 30 град цельсия. В этих пределах система должна обеспечить нормальное приготовление яишницы. Но если в батареях зимой совсем не будет горячей воды, то в каких пределах температуры система справится со своей задачей.

[CHANt]

Я думаю, Вы этот ресурс видели (в т.ч. ТЗ с краткими примерами)
http://www.rugost.com/index.php?option= ... d=62#4_1_3


Вспомнилась древняя реклама Би Лайна:
Женщина: Колбаски свешайте.
Продавец: Скока?
Ж.: Ну, грамм двести-триста.
П.: Говорите точно, скоко вешать?
Ж.: Ну не знаю, сколько получится.
П.: Скока вешать в граммах?
Ж.: А к чему такая точность?
П.: Точность никогда не бывает лишней!

[san]

Я этот ресурс видел. Примеры применительно к нашим системам не очень пригодны. Даже при этом, примеры мне не нравятся. Мне больше понравились примеры, которые Вы мне выслали.
Я за "точность в граммах", только вот где их приводить. Характеристики каналов измерения (точности, периодичности) и регулирования (статическая, динамическая ошибка, время переходного процесса) и много другого, я думаю нужно приводить в требованиях к функциям. Это же функции АСУТП (КИСУ), и требования к ним есть смысл приводить именно в этом разделе. В примере на АИИС КУЭ ... где-то так и сделано. Может я и не прав. Хочу услышать также мнение других специалистов.
Если я не прав, то что тогда нужно приводить в требованиях к функциям(задачам), обще бла-бла, наподобии предлагамеых а требованиях к видам обеспечения типа как вырезки из стандарта (не помню уже какого) типа "Общие требования к видам обеспечения". Переечнь функций и задач не является достаточным требование к ним. Точность, периодичность ... и т.д. их реализации это и есть требования к ним. А условия при которых, это должна делать система указывать в показателях назначения. Вобщем, я начал спорить, хоть и собак то не ел... Просто я сомневаюсь, хотел бы услышать еще мнения

[san]

Вот еще что хотел спросить. Аж неловко как-то. Все наши проектные работы вместе с ТЗ мы делали после заключения контрактов. Тоесть ТЗ было уже после заключения контракта. Но как обычно делается, какая последовательность? Если роботы по ТЗ отдельно оплачиваются, значит кто-то выигрывает тендр по созданию системы до создания ТЗ (как и у нас было). А как тогда называется цена, если все нюансы прописуются в ТЗ. Мы залаживали какой-то % сверху. Если же сначала ТЗ, потом тендер, значит исполнителю надо оплатить несколько ТЗ от разных организаций. Или это классическая проблема яйца и курицы?

[CHANt]

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

[Никита]

Смотрю людям не отдыхается на праздники. Мне вот тоже кой-чего поделать пришлось, правда все больше руками...
CHANt, по уставкам: условие невскипания для неперегретой воды в условиях обычной застройки выполняется почти всегда, тут оно больше для проформы:) А вот насчет давления - не доводилосб бывать в ваших краях, а у нас ввиду особенностей рельефа надо смотреть перепад между самой верхней точкой и точкой врезки подпитки. Разница бывает ощутимой, собачья будка на сопке выше девятиэтажки внизу. Хотя думаю, это терминология и Вы и сами не хуже меня знаете о чем речь.
А вот насчет максимального давления в статике надо подумать - как и где его контролировать. В диамике-то картина совсем другая получается - тут и насосы и трубы и шайбы и учет... Перепады высот опять же...Для обратки - вроде как много, ибо в динамике на радиаторах будет больше, для подающей - ну может и нормально, но надо пьезометрию смотреть. Если считаем точкой отсчета обратку и перепад 50м между экстремумами неплох, то на реальных значениях, может быть и хуже. В общем, или я чего-то недопонял или еще чего, но как-то мне это не нравится, хоть и объяснить не могу пока. Обычно все сводится к тому что изучается система и принимается решение типа "х.. с ним, ставим столько-то". Да, и одинаковые уставки минимума в подаче и обратке могут привести к тому, что система не почувствует остановки циркуляции с возможными последствиями в виде раскопок... Тут бы дельту на трубы добавить, да только как ее высчитать...
Не знаю, честно говоря, насколько оправдан подход с учетом класса точности приборов. На мой косой взгляд, проще ввести, как в сопромате, "коэффициент запаса" с лихвой покрывающий все погрешности и форс-мажоры и этим ограничиться.
По обратке ГВС и холодной - ну тоже самое примерно. Смысл городить систему с пятью знаками после запятой, когда можно обойтись ЭКМами - ибо думаю что номограммы насосов имеют на два порядка худшую точность чем расчитанные значения...
Ну а по температуре вроде все просто и понятно. Хотя нам значения прописывают энергетики в ТУ - 55 для закрытых и 60 для открытого разбора. А уж как они потом с населением и управляющими борются - это их дело.

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

[CHANt]

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

Не так много работы предлагают в году, чтобы отказываться. Пусть растет семейный бюджет :)

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

Ах, да! Я со своим равнинным городом совсем упустил из виду перепады высот. Так как все микрорайоны у нас практически в одной плоскости. Да и по городу максиму 60 метров перепад - это актуально только для магистральный сетей большой протяженности со своей гидравликой. В плане одного объекта пренебрегаю.
По статике - попадаются объекты, где надо душить приходящий режим - т.е. он выше чем требуется. Для этого ставятся насосы на обратке зависимой схемы и понижается давление в обратке квартальных сетей, а на выходе насосов выше чем в обратке теплосети. При остановке насосов надо отстроить сбросные клапана и поддерживать статику до включения насосов в рабочий режим, иначе теплоноситель "вылезет с выпученными глазами" из радиаторов отопления :D

Обычно все сводится к тому что изучается система и принимается решение типа "х.. с ним, ставим столько-то". Да, и одинаковые уставки минимума в подаче и обратке могут привести к тому, что система не почувствует остановки циркуляции с возможными последствиями в виде раскопок... Тут бы дельту на трубы добавить, да только как ее высчитать...

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

Не знаю, честно говоря, насколько оправдан подход с учетом класса точности приборов. На мой косой взгляд, проще ввести, как в сопромате, "коэффициент запаса" с лихвой покрывающий все погрешности и форс-мажоры и этим ограничиться.
По обратке ГВС и холодной - ну тоже самое примерно. Смысл городить систему с пятью знаками после запятой, когда можно обойтись ЭКМами - ибо думаю что номограммы насосов имеют на два порядка худшую точность чем расчитанные значения...

Расчет и карта уставок. хм, несколько разные вещи, там уже округленно озвучивается и подписывается главным инженером заказчика.
ЭКМ? Ктоб их проверял, эти ЭКМы? Друзья госповерители, только водку кушать в гостях, да штампики на чистое помытое стеклышко ставить, даже не спрашивая откуда прибор... Не, этот класс приборов пусть на КИПиА ставят, я функции ЭКМ в контроллере сделаю. Это всего лишь местные условия. :)

Ну а по температуре вроде все просто и понятно. Хотя нам значения прописывают энергетики в ТУ - 55 для закрытых и 60 для открытого разбора. А уж как они потом с населением и управляющими борются - это их дело.

Код: Выделить всё

САНПИН 4723-88 c с изм. от 2008 г.
"Санитарные правила устройства и эксплуатации систем централизованного горячего 
водоснабжения"
1.7. Температура горячей воды в местах водоразбора независимо от применяемой 
системы теплоснабжения должна быть не ниже 60°С и не выше 75°С.

Пусть заказчик ставит что хочет. В проекте и при сдаче объекта будет сколько положено нормами. Не помню номер, но было даже Постановление правительства на эту тему - в каком-то городе куча народу заблолело от лемонеллы. Из-за недогрева - 50 град. было в ГВС.

Спасибо! Смысл понятен, есть над чем подумать.

[Никита]

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

При наличии конверта с деньгами странно наличие зависимой схемы. Явно ж просятся теплообменники - чем из автоматики такие "подпорки" строить, лучше гидравлику приличную сделать... У нас до такого еще не дошло, выше 7кг обратки нигде нет.

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

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

Пусть заказчик ставит что хочет. В проекте и при сдаче объекта будет сколько положено нормами. Не помню номер, но было даже Постановление правительства на эту тему - в каком-то городе куча народу заблолело от лемонеллы. Из-за недогрева - 50 град. было в ГВС.

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

[san]

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

[CHANt]

Объем работ для курсового действительно грандиозен )))
В таблицах В1 и В2 я обычно ввожу столбец с наименованием тега. так как КИПовские и обозначения электриков не всегда подходят, и практически никогда не имеют идентификационного кода объекта/установки и т.п. а если расширять систему придется?...

Да, San, я обещал показать как выглядит абонентское оборудование WiMax:

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

[san]

Покритикуйте раздел 6.7 и рис.10. Напомню, что студенты заканчивают по направлению "Компьютерно-интегрированные технолог. процессы и производства". Интересуют следующие вопросы:
1) на сколько нужны схемы соединений проводок пром. сетей (нигде просто не встречал);
2) если нужны, то как правильно их выполнять, согласно стандартам ГОСТ, в примерах видел только схемы соединений внешиних проводок, где к щиту подлючаются датчики, ИМ; тоесть щит является центром, а тут центральных щитов несколько;
3) как правильно согласно ГОСТ показывать соединители, распиновка которых неизвестна (готовый кабель);