ТЗ на автоматику вентиляции, /прошу скинуть, у кого имеется Опции

[kord]

To ss.23
Я бы перевел эти понятия так:
"чертежи видеокадров" - дампы экрана или примеры мнемосхем которые выводятся на рабочее место оператора
"БД системы" - структура архива т.е какие параметры с какой дискретностью архивируются и в каком виде выводятся на экран и распечатку
Все это - как правильно заметил уважаемый cthutq - вторичные вещи. которые идут в процессе проектирования системы.
А большинство заказчиков, когда оценят стоимость запрашиваемой диспетчеризации, откажутся от этой идеи.
имхо - на первом этапе ТЗ должно помещаться на 1 листе.
Михаил

[kord]

To ss.23
Я бы перевел эти понятия так:
"чертежи видеокадров" - дампы экрана или примеры мнемосхем которые выводятся на рабочее место оператора
"БД системы" - структура архива т.е какие параметры с какой дискретностью архивируются и в каком виде выводятся на экран и распечатку
Все это - как правильно заметил уважаемый cthutq - вторичные вещи. которые идут в процессе проектирования системы.
А большинство заказчиков, когда оценят стоимость запрашиваемой диспетчеризации, откажутся от этой идеи.
имхо - на первом этапе ТЗ должно помещаться на 1 листе.
Михаил

[Гость_cthutq_*]

Русское слово- "Скриншот"- это точнее. 1 страница - это "высший пилотаж", с первого раза, думаю,
не получится ( в свое время я уместил ТЗ на модернизацию АСУ АЗЛК на 5 страниц при "офигительной"
стоимости этапа). На этапе ТЗ надо руководствоваться одним принципом - "за базар отвечаю", но
"тему надо перетереть".

[Гость_ss.23_*]

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

[Гость_cthutq_*]

Не скажите, не скажите.... "Автоматчик" Вам такое "выдаст", что ваш проект полетит "коту по хвост",
но свои деньги он "вышибит" по-любому. Я бы так и поступил. Стыдно, но факт.

[Гость_ss.23_*]

Ну, и хорошо. Он же не будет делать проект автоматики в ущерб управляемому оборудованию (?!).
А деньги башляет Заказчик. Мне по-барабану.
------------------------
Прошу прокомментировать следующий раздел ТЗ:

2. Требования к проекту системы автоматического управления вентиляцией и кондиционированием АБК


2.1. Проект системы автоматического управления вентиляцией и кондиционированием АБК (далее по тексту «АСУ») должен отвечать требованиям существующих российских и московских руководящих и нормативных документов, пособий к ним, правил и указаний.
2.2. На предварительном этапе разработать концепцию проекта АСУ. Она должна быть согласована и утверждена у заказчика. Желательно применение типовых решений.
2.3. Разработку рабочей документации АСУ вести в соответствие с ГОСТ 21.408-93, ГОСТ 34.201-89, ГОСТ 24.206-80, ГОСТ 21.404-85, ГОСТ 34.602-89, СНиП 41-01-2003, СНиП 21-01-97.
2.4. Проект АСУ должен содержать:
- выработку детальных технических требований;
- выработку проектных решений по функциональной архитектуре системы;
- решения по структуре и составу ее программных и технических средств;
- решения по организационной структуре и функциям персонала и т. д.;
- выбор оптимального по критерию "цена-качество" состава технических средств, необходимых для решения поставленных задач;
- подготовку проектной документации по ГОСТу 34.602-89 (схемы автоматизации, электрические принципиальные схемы и схемы соединений, чертежи видеокадров, схемы компоновки оборудования, описания БД системы, алгоритмов управления);
- разработку, описание и/или адаптацию ПО;
- руководство по эксплуатации; руководство программиста; руководство пользователя; руководство по системной поддержке;
- ведомость эксплуатационных документов;
- ведомость машинных носителей информации;
- сертификаты и гарантийные обязательства.
2.5. Блоки управления системы автоматического управления (локальное управление вентоборудованием) желательно применить, как готовые изделия, поставляемые вместе с вентоборудованием. К блокам управления системы автоматического управления предоставить документы:
- сертификат соответствия требованиям нормативных документов, выданный государственным органом Российской Федерации по сертификации продукции;
- требования к условиям эксплуатации;
- перечень регулируемых и контролируемых агрегатов и узлов;
- функциональную схему или пояснительную записку, в которой разъяснить принципы работы и взаимодействия регулятора температуры, модуля управления логических и временных процессов, задействованных защит теплообменников и электродвигателей;
- схема электроподключения всех электропотребителей;
- спецификацию соединительных кабелей;
- пояснительную записку и инструкции по монтажу, по настройке и пользованию;
- гарантийные обязательства.

[Гость_ss.23_*]

И если будет время, прошу дать комментарий к следующему разделу:

4. Функции системы диспетчеризации.

4.1. Станция АСУ обеспечивает общий надзор и обмен информацией по сетевому каналу связи (шина C-Bus) с независимыми системами локального управления, установленными в различных помещениях объекта. Приём информации о текущем состоянии локальных систем и оперативное предоставление её оператору в простом и удобном виде.
4.2. Возможность работы в системе диспетчеризации, как со станции, так и с любого компьютера в локальной сети.
4.3. Интерактивный обмен информацией системы АСУ с оператором с использованием многоканального графического интерфейса.
4.4. Возможность индикации параметров отдельных узлов локальных систем с возможностью настройки функций контроля пользователем.
4.5. Иерархическая структура доступа к контролируемым параметрам элементов вентустановок и вентиляторов. Быстрый доступ к требуемой информации.
4.6. Непосредственный доступ оператора через систему диспетчеризации к параметрам регулирования вентустановок.
4.7. Отображение графиков переходных процессов для каждой локальной системы управления.
4.8. АСУ должна отправлять извещение на станцию диспетчеру об отказе отдельных устройств и агрегатов (например, на двигатель вентилятора подан сигнал включения, но двигатель не работает), а также о возникших аварийных ситуациях (например, о снижении температуры воды на выходе калорифера ниже допустимой, или - на фильтре слишком велик перепад давлений). Показывать аварийную информацию операторам при работе в системе диспетчеризации с любого компьютера в локальной сети.
4.9. АСУ должно извещать диспетчера или оператора в случае, если какое-либо вентоборудование находится в рабочем состоянии, хотя по регламенту оно должно быть выключенным.
4.10. АСУ производит запуск вытяжной вентиляции удаления дыма при пожаре в соответствующем коридоре АБК при срабатывании в нём пожарной сигнализации.
4.11. АСУ производит отключение всех агрегатов приточной и вытяжной вентиляции и кондиционеров при срабатывании в корпусе АБК пожарной сигнализации. При этом электропитание систем регулирования мощности водяных воздухонагревателей остаётся включённым. Подаётся электропитание на закрытие огнезадерживающих клапанов на воздуховодах у стены между помещениями №106 и №108 в случае срабатывания пожарной сигнализации в этих помещениях, в вестибюле №112 или в коридоре №113.
4.12. Регистрация заданных параметров локальных систем управления.
4.13. Протоколирование и архивация всех изменений параметров и состояний вентустановок и вентиляторов, а также действий оператора.
4.14. Возможность печати регистрируемых параметров, поступивших сообщений и сигналов аварийного состояния, и действиях операторов.
4.15. Обеспечить защиту АСУ от несанкционированного доступа.

[Vasiliy]

4.1. Станция АСУ ... (шина C-Bus) ....

Лучше не указывать шину. С-bus подразумевает оборудование только Honeywell, а автоматика может быть на чем угодно.

4.2. Возможность работы в системе диспетчеризации, как со станции, так и с любого компьютера в локальной сети.

Это, наверное, надо преобразовать во что-нибудь подобное: "Предусмотреть подключение основной станции АСУ к локальной сети АБК для возможности организации дополнительных станций АСУ на любом из компьютеров сети"

[Гость_ss.23_*]

Замечательно. Сейчас внесу изменения. Спасибо.

[Гость_ss.23_*]

Здесь ТЗ на автоматику (начало), =250 кб.

Прикрепленные файлы

 TZ_ABK.doc ( 218,5 килобайт ) Кол-во скачиваний: 1118

 

[Гость_ibogush_*]

Времени нет, но проверьте 4.10. АСУ производит запуск вытяжной вентиляции удаления дыма при пожаре в соответствующем коридоре АБК при срабатывании в нём пожарной сигнализации. По "мировым" стандартам это не допустимо. Дымоудаление должно управляться системой пожарной автоматики.

[Гость_ss.23_*]

Не понял. Впервые слышу о такой.
Приходит сигнал от системы оповещения о пожаре, а дальше вентилятор дымоудаления запускается обычным пускателем. В СНИПе особых требований я не нашёл.
Что значит пожарная автоматика?
Странно...
Или Вы имеете в виду, что надо на слаботочников переложить заботу по автоматизации системы дымоудаления? Этот номер не пройдёт. У них ответ один: ваш вентилятор, вот вы им и занимайтесь. Мы, мол, вам сигнал подали, а дальше хоть трава не расти...

[Гость_ibogush_*]

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

[Гость_ss.23_*]

Понятно. Существенное замечание.
Изменения внёс. Спасибо.
-------------
Надеюсь контроль состояния систем противодымной защиты системой диспетчеризации допускается.

[ttt]

Разрешите навести критику на раздел 4.
4.1 Что такое станция АСУ (а локальные устройства - контроллеры АСУ?), я бы назвал - рабочее место оператора на основе ПК и локальные контроллеры. И еще - управление и защита оборудования должна производиться от контроллеров и не зависеть от работы ПО рабочего места оператора. Я бы это где-то указал.
4.2 Вообще непонятно. Станция АСУ это сервер? А любой компьютер в локальной сети это рабочая станция? На крутые деньги ставите заказчика. Я бы прописал структуру АСУ (типовую) с требованиями по расширению.
4.3 Многоканальный граф... - это что такое?
4.4. 4 раза перечитал - недопонял
4.5. Догадываюсь о чем речь кроме иерархического доступа
4.6. Я бы просто перечислил эти параметры
4.8. Появилась станция диспетчера. Я бы просто перечислил аварийные сообщения - в вентустановках их не так много, перечень давно устаканился.
4.10, 4.11 Такая АСУ должна иметь пожарный сертификат. Пункты скользкие.
4.12 Размыто, регистрация когда, в каком виде, каких параметров?
4.13 Не встречал систему способную на такое.

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

Понимаю Ваши трудности и сочувствую.
С уважением

[Гость_cthutq_*]

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

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

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

Извините, подробнее не могу - нет времени.

[AlexSch]

Ну, вот например.
Нашел на своем компе такую бумагу.

Прикрепленные файлы

 Techdoc.doc ( 100 килобайт ) Кол-во скачиваний: 769

 

[Гость_ss.23_*]

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

Хорошее ТЗ от AlexSch. Давно ждал такое. Его бы на пару дней раньше... Можно будет многое почерпнуть.

Сообщение отредактировал ss.23 - 13.9.2006, 12:47

[Гость_ibogush_*]

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

Естественно, но не подача команд.

[Гость_Гость_130906_*]

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

А оно Вам надо?
Я это к тому что лучше поручить это все специалисту

[Гость_ss.23_*]

Господа, можно ли Автоматизированное Рабочее Место оператора (т.е. компьютер), с которого он имеет возможность войти в Систему Диспетчеризации Здания назвать
ТЕРМИНАЛ ?
Применим ли такой термин?

[Гость_ibogush_*]

Можно, но зачем? Общеупотребимый термин - Operator's Workstation (OWS),что в переводе означает Рабочая Станция Оператора.

[Гость_ss.23_*]

Тогда понятно, почему заказчик применяет понятие "станция". Вот откуда "ноги растут".
Спасибо.

[Гость_cthutq_*]

ТЗ от AlexSch интересное, если бы я по нему принимал систему (имею опыт работы "с той стороны"),
то ее не сдали бы без приличного отката (без обид, сами сейчас "влетаем" с иностранцами). Если Тз для России, то наличие иностранных слов и терминов, имеющих российский аналог - это ....
Такая терминология доказывает "продвинутость" того, кто писал, но облегчает жизнь Заказчику.
Если встречается фраза "и т.д.", до я токое ТЗ подписал бы сразу, т.к. это просто "подарок" для Заказчика. Есть и другие "залепухи" - параметры указаны без допусков, надежда на СНиПы слабая,
т.к. прямая ссылка отсутствует и Заказчик не ОБЯЗЯН помнить о них - это проблема Исполнителя.
Красивый текст - не залог защищенности Исполнителя. Еще раз прошу - без обид.

[Гость_ibogush_*]

Занятный тугамент от AlexSch . Добротня западная рыба (а это именно рыба - см. Введение) достаточно качественно переведенная.
О терминологии - один мелкий огрех - Frost Alarm -термин применим как предупреждение о намораживании льда/инея на рекуператоре. Freeze Alarm- собственно угроза разморозки. (Кстати может кто обьяснит почему профессиональный сленг переворачивает все вверх ногами?. РАЗморжавить придется калорифер после его ЗАморозки)

[Pasekov]

Кстати может кто обьяснит почему профессиональный сленг переворачивает все вверх ногами?

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

[Гость_ibogush_*]

Причем тут запад? Раз/заморозка, говорит о том, что для начала неплохо было бы разобраться с тем, что в переводе не нуждается. Хотя бы из уважения к русскому языку.
Превед.

[Гость_cthutq_*]

"Западные" документы ЮРИДИЧЕСКОГО характера ( а ТЗ именно ЮРИДИЧЕСКИЙ документ, ТЕХНИЧЕСКИЕ будут на других этапах ) напрочь не годятся для России. И дело не в терминологии,
дело в той базе (юрилической), но которую они опираются. В России надо пользоваться нашей
нормативной (технической и юридической). Под нее "подгонять" терминологию и идеологию,
никакого "сленга", т.к. этот документ подписывают не технические специалисты, а люди,
отвечающие за деньги. Конечно, технический аудит применяется, но "воевать" будут не "спецы",
а юристы и начальство (в случай чего).

[Гость_Гость_kord_*]

Думаю, что уважаемый cthutq глубоко прав: ТЗ - это в первую очередь юридический документ, после ознакомления с которым Заказчик должен понять две важные вещи: 1. скока это стоит; 2. что это дает ему.
Я сталкивался несколько раз с систуациями, когда ТЗ писали автоматчики (а выложенные документы составлены именно ими), и каждый раз оказывлось, что в итоге получается "разводилово", т.е. система диспетчеризации Заказчику не очень то и нужна...
имхо - та заготовка ТЗ, которую я предложил выше полностью этому соответствует. Согласен, что это - "крестьянский вариант", но по ней можно посчитать экономию от внедрения АСУ. А все требования к "топологии, шине, иерархии доступа" должны быть в приложениях. А уж в ТЗ прлописывать алгоритмы управления влапанами, путая при этом нагреватель и охладитель - просто смешно.
Михаил

[ttt]

"ТЗ - это в первую очередь юридический документ, после ознакомления с которым Заказчик должен понять две важные вещи: 1. скока это стоит; 2. что это дает ему."
Надо перевернуть наоборот: сначала заказчик осознает "что это дает ему", сопостовляет свои желания с "скоко это стоит" потом пишет ТЗ.
В нашей действительности все перепутано, отсюда и разброд во мнениях.
Кстати в документах 80-90х, регламентирующих процесс создания АСДУ первым пунктом (и обязательным) было - Технические требования, а только потом ТЗ. И в ТЗ прописывалась конкретика.
Сейчас это все позабыто (но не в промавтоматике, там все нормально) и каждый ваяет в меру своего понимания.
ТЗ должен писать Заказчик, тогда не будет разговоров - "юридический - технический".

[Гость_cthutq_*]

Технические требования - >Тактико-Техническое задание, в котором производится ОБЩАЯ постановка
задачи и указываются НЕЗЫБЛЕМЫЕ параметры (аналог Договора в наше время). ТЗ- это методы решения поставленной задачи, т.к выбор оборудования и других средвств и, соответственно, вся терминология, определяются чуть позже. Если охота "с шашкой на танки", то можно привязываться на этапе ТЗ, (например, работа уже выполнена, нужно просто "одокументить" деньги). Не путать ТЗ с коммерческим предложением на тендер - там другие правила, хотя есть и общие вещи. Заказчик
ТЗ писать не любит (нужны специалисты), но легко привлечет (если умный) специалистов со стороны
(если сумма приличная). Застолбите конкретику - устаните расхлебывать, коли что не так пойдет,
или список форс-мажора будет больше самого ТЗ - напугаете Заказчика. Хотя всякое бывает....