Господа автоматчики, будьте так добры, выложите здесь кто-нибудь ТЗ на разработку проекта системы управления вентиляцией и кондиционированием.
Думаю, по роду деятельности Вам приходилось такое задание самим себе составлять и согласовывать у заказчика. Либо Вы таковое получали от "продвинутого" заказчика (что встречается гораздо реже).
Как специалистам, Вам виднее, как и из каких разделов оно должно состоять. Сейчас сижу, сочиняю ТЗ на автоматику. Не хотелось бы написать нечто несуразное, или что-то упустить.
Да, упустил… Конечный Заказчик хочет иметь диспетчеризацию, и вообще, полный комплекс автоматики (как в турбизнесе, по принципу: "все включено").
Скажу сразу, что системой поиска здесь на форуме я воспользовался, но никакого ТЗ не обнаружил.
Господа, ещё раз прошу всех обратить внимание на мою просьбу.
Я понимаю, что автоматика - раздел специфический, и редко кто составляет техническое задание на его разработку.
И всё же...
Взводатор
8.9.2006, 11:06
Да в общем то требования как-то сами сформировались - так и делаем. В формальный/печатный вид их не переводили.
Думаю, более правильным будет выложить Вашу заготовку и обсудить ее.
С уважением Взводатор.
Коллега, вынужден огорчить - вряд ли кто выложит. И не столько потому что " коммерческая тайна", просто многие вещи специфичны, и сильно зависят от типа объекта , возмоможностей (финансовых) Заказчика и Исполнителя (технических). При этом придется "выдирать" всю информацию
о Заказчике и Исполнителе, т.к. неприятностей никто не хочет. Могу дать "утешительный" совет -
не "закладывайте" в ТЗ того, что вызывает сомнения и постарайтесь поставить себя на место Службы
Эксплуатации Заказчика. Есть ГОСТЫ и СНиПы. Удачи.
ну вот ТЗ на систему вентиляции только не приточка (95 кило):
Ну, с почином. ss.23 - вы хоть "намекните", что за объект, что планируете сделать ?
я редко пишу то, что вообще можно назвать словом ТЗ, но всегда в в свободном стиле, и даже не пишу, а скорее устно обсуждаю с поставщиком.
главное что в ТЗ должно быть - постановка задачи и пути решения.
блок-схема узлов которые надо объавтоматить.
например:
приточка.
заслонка, фильтр, эл.нагр., вент
рисуем четыре кубика.
пишем:
1. эл.привод заслонки. должен открыться по включению вента и закрыться после выключения.
2. датчик дифф.давления для фильтра. только индикация состояния, разомкнуто - лампа не горит, замкнуто - светится. лампочку вывести на панель, цвет лампы - желтый.
3. эл.нагреватель, питалово 3фазы/400В, мощность 10кВт, встроенные НЗ сухие контакты тепловой защиты. управление мощностью нагрева по температуре воздуха в канале за вентом. сблокировать с работой вента.
4. вент. питалово - три фазы 400В. мощность 1кВт. ступенчатая регулировка скорости, 3ступени. сблокирован с эл.нагревателем и заслонкой.
на панель ЩУ вывести переключатель типа on/off, подписать положения ВКЛ. ОТКЛ.
на панель вынести индикацию:
"работа" - зеленый
"авария" - красный
"фильтр" - желтый
на панель вывести переключатель скорости вента, подписать I-II-III,
с этого переключателя вент не должен отключаться ни в коем разе!
на панель вывести крутилку для уставки температуры. подписать шкалу от 0 до 30 гр. с шагом 5.
алгоритм работы автоматики:
по включению запускается вент, открывается заслонка, подается питание на регулятор нагрева и нагреватели.
по выключению снимается питание с регулятора нагрева и нагревателей. через три минуты снимается питание с вента и закрывается привод заслонки.
во время работы - по размыканию теплух в венте или в эл.нагревателе обесточиваются вент, нагреватель, закрывается заслонка, на панели зажигатеся красная лампочка. переключатель on/off д.б. схемно заблокирован, чтоб шаловливые ручки не смогли включить приточку. сброс аварии д.б. устроен во внутрях ЩУ незаметным образом для любопытного юзера.
ну и в таком духе описывается то что вы хотите видеть от этой самой автоматики.
Я в свое время получил ТЗ на автоматизацию приточно-вытяжных установок аж на 8-ми листах жаль документ не сохранился ....
На автоматику, имхо, лучше не ТЗ писать словами, а опросный лист заполнить. Для специалиста заполнить его особого труда не составит, а автоматчику вполне достаточно. Какие-то дополнительные требования, например, про возможность диспетчеризации на LonWorks можно отметить внизу.
Приложенный файл нашел при помощи яндекса
тут
Цитата
На автоматику, имхо, лучше не ТЗ писать словами, а опросный лист заполнить.
Вообще-то подбор Квс и Ду регулирующего клапана всегда было вопрсом автоматики с тех времен когда она, атоматика была еще механическая ...
ТЗ утверждает заказчик а проект делают на основе проекта вентиляции, так же в ТЗ описываеся алгоритм работы основных агрегатов: насосов, вентиляторов, клапанов... Опросник не совсем потянет ...
Спасибо, господа.
По крайней мере, наметился состав ТЗ. Уже хорошо.
To SS.23
Порылся в своем архиве - обнаружил кучу ТЗ, но на локальные системы. Такого обширного ТЗ на вентиляция+кондиционирование - нет. Думаю, что найти его вряд ли удастся - слишком неопределенная задача.
В последнее время такие задачи обсуждем на учебных занятиях. Например: "система управления HVAC гостиницей на 100 номеров с применеием LON"
или: "система управления HVAC офисного здания 3,5 тыс м кв"
Обменяться такими материалами можно, но нужно знать тип объекта, поскольку требования к системам разные.
Михаил
Объект: АБК (1000 м2) одного завода в Подмосковье.
Проект вент. и конд. выложен
здесь.
проект посмотрел частично.
Думаю, что действительно здесь речь может идти о автоматике приточки.
А из кондиционирования - 5 внутренних блоков мультика - некритично. Можно на комплектную автоматику кондиционра сослаться...
Михаил
Несомненно. Я так и сделаю.
А в отношении ТЗ... Просто, последнее время Заказчики стали какие-то продвинутые. Стали всё чаще требовать ТЗ на автоматику.
Поэтому хотелось накропать некую всеоблемлющую "рыбу", которую можно было бы периодически использовать, перекроив немного под конкретный объект.
Цитата
А в отношении ТЗ... Просто, последнее время Заказчики стали какие-то продвинутые. Стали всё чаще требовать ТЗ на автоматику.
Так они , заказчики, должны сами участвовать в составлении ТЗ... им же блин это все потом эксплуатировать и принимать еще то же...
Про мультик тоже аккуратней - есть много способов управления системой, пульты индивидуальные, пульт общий и компьютерная программа...
К тому же мне это ТЗ дальше на этом заводе пригодится.
Т.к. Заказчик хочет всю вентиляцию завода завязать на единый диспетчерский пункт. А вентиляция там очень серьёзная будет. Экструдеры, дробилки пластика, цеха по выпуску и упаковке профиля с общими габаритами по 180х22х10 м каждый (несколько шт.), цех смешивания, инструментальный цех...
АБК - это так, для разогрева...
Цитата
Т.к. Заказчик хочет всю вентиляцию завода завязать на единый диспетчерский пункт
затребуй от заказчика человека, кторый всю технологию завода ясно представляет в своей голове и может дать представление о ней тебе. вот с таким человеком уже можно сначала описать словами а потом построить алгоритм.
советую не поддаваться на всякие анкеты, т.к. анкет на все случАи в жизни - не бывает.
только словами.
Если интересно - вот англоязычный документец.
Спасибо. Интересно. Но дожили...
Уже и ТЗ на английском....
Понятно, что нашему рынку всего ничего и он "страшно" закрытый...
Цитата(Pasekov @ Sep 8 2006, 22:03 )
Но дожили...
Уже и ТЗ на английском....
Это живой документ с живого объекта в штатах.
Нормальный документ, сразу Союзом повеяло. Здравствуй, любимый ГОСТ-34.602-89. в принципе, стараюсь ему следовать и сейчас (еслм это не подработка). Самое смешное, что "тупое" следование
ГОСТУ спасает от кучи проблем.
ГОСТ известный. Но если в ТЗ на проект вент. и конд. по объекту записано, что я должен выдать ТЗ на автоматику, значит надо выдавать.
-------------
к LordN
Да. Несомненно, так и сделаем. Собственно, Заказчик сам до этой мысли уже дошёл и приглашает нас для проработки основных вопросов ТЗ по автоматике (наверное, Вы с ним сговорились).
------------
Спасибо всем за активную помощь и предложенные документы.
Хуже нет сочинять указания в том, в чём совершенно не разбираешься, и просто не знаешь применяемых терминов.
Получается не ТЗ, а юмористический опус.
С диспетчеризацией до сих пор - никаким боком...
И списать неоткуда, посоветоваться не с кем. Да, и времени уже нет.
Далась им эта диспетчеризация... Можно подумать, в обычной приточке на заводе надо менять параметры каждый час. Наверняка, раз в сезон уставки введут и забудут про неё.
Один раз в жизни видел настоящую диспетчеризацию - на космодроме в Плесецке, вентиляция чистых помещений. Там действительно для поддержания требуемого ТВР в огромном ЧП высотой 20 м, куда закатывали для сборки сразу несколько спутников, офицерам приходилось отслеживать множество параметров. И работала система из рук вон плохо. Постоянно шли какие-то сбои и отказы.
А для обычной вентиляции... Я так понимаю, что людям просто деньги девать некуда.
Мне хотелось бы помочь - но не могу, причины указал в своем посте. Возьмите ГОСТ 34.602-89. Если вы разбираетесь в выбранной SCADA, до диспетчеризация - это не проблема, следуйте ГОСТ. Не стоит
указывать КОНКРЕТНО, что и как отображается и управляется, это дело Пояснительной записки и Программы Испытаний. Что касается схематических решений ("оформления" щитов) - пишите только ОЧЕВИДНЫЕ вещи (типа, лампочек аварий и понятных блокировок ).
To ss.23
Думаю, что диспетчерихзация - это просто (на данном этапе)
Попробуйте так:
напишите на листе:
1. диспетчеризация потребителей.
Здесь прописать какой контроль по помещениям - температура, влажность, СО, запыленность и все , что сможете придумать. Ненужное - вычеркнуть. Перечислить помещения, в которых нужно контролировать. Это мониторинг.
Управление. Теперь прописать, что нужно делать, если какой либо параметр выйдет за пределы: открыть заслонку, закрыть заслонку, увеличить обороты, включить что-нибудь. Ненужное вычеркнуть. Расписать помещения, в которых надо управлять параметрами.
Контроль. Теперь прописать средства визуализации: информация лампочками, инфо на РС, вообще нет информации.
2. Диспетчеризация воздухообрабатывающего оборудования.
Мониторинг. Здесь прописать, какие параметры мониторить: температура, давление, влажность, степень открытия заслонок, перепад давления, моточасы и все, что сможете придумать
Управление. Теперь прописать, чем нужно управлять на ЦК, не вдаваясь в подробности . Например - регулировать температуру на выходе ЦК в заданных пределах с заданной точностью.
Контроль. Теперь прописать среддства визуализации: лампочками, на РС, вообще никак, штатная сигнализация контроллера.
Определить место диспетчера и действия при срабатывании предупредительной и аварийной сигнализации.
Все утвердить у Заказчика.
Имхо. Примерно так.
Михаил
Спасибо Михаил.
Я решил не высасывать информацию из пальца. Всё равно ничего не получится (если не имеешь об этом и малейшего представления).
Натаскал из Интернета различных предложений от фирм и сижу, комбинирую из них понравившиеся пункты. При этом ещё напряг самого Заказчика, он прислал свои пожелания. Учитываю ещё их.
Хотя многое не понятно. Некоторые термины забрали кучу времени, чтобы разобраться с их значением, толкованием. Порой объяснения бывают настолько расплывчаты, что ещё больше запутывают. Так было с понятиями "интерактивный обмен", "топология объекта"...
Может, не "париться" ? Количество коньяка определит качество ТЗ. Если вопрос РЕАЛЬНО не понятен,
тут было предложение о встрече форумчан, там это можно и обсудить. Ничего сложного нет в ТЗ,
но безумно тяжело объяснить это дело заочно. Я написал туеву хучу ТЗ по разным объектам (не инженерка !!!!!!), но "был в теме". Грамотное ТЗ- залог получение денег, но этот документ НИКОГДА не идет один - тут тонкости составления договора. Не зная взаимоотношений Заказчик-Исполнитель
можно выглядеть полным дураком, не прикладывая к этому никаких усилий вообще.
Кстати, применение лампочек желтого цвета нежелательно, "проблесковые маячки" желтого цвета используются как аварийные сигналы в условиях определенной освещенности (исключено попадание солнечного света на источник сигнала) и только в комбинации с другими формами оповещения персонала о возникшей АВАРИЙНОЙ ситуации, обычно - звуковое оповещение,"резко отличающееся от типового звукового фона для территории, на которой установлен звуковой оповещатель".
Спасибо за предложение. Встретиться всем, в любом случае, было бы неплохо.
Раздел "4. Функции системы диспетчеризации" с божьей помощью состряпал.
Дальше будет легче, хотя бы представляю, о чем должна идти речь.

-----------------
Наткнулся на интересный документ в процессе поиска:
аннотацию статьи Ирины Кузовкиной в журнале "Автоматизация в промышленности " (№ 12, 2005 г., Москва).Мне кажется, она, как подспорье в составлении ТЗ по автоматизации.

Кто-нибудь может пояснить фразы из раздела требований к АСУТП:
- чертежи видеокадров;
- описания БД системы...?
Маленький бесплатный совет - будьте ЧРЕЗВЫЧАЙНО осторожны с промышленностью (хотя Ваш объект из этой серии), т.к есть вещи, которые обуславливаются конкретной ТЕХНОЛОГИЕЙ. Если есть намек на
привязку HVAC к технологии Заказчика (плавали, знаем), НЕ отражайте этого напрямую (ловушка для дураков), а постарайтесь "мягко" обойти это ("согласуется в рабочем порядке" или работа по ЧТЗ ), старайтесь МАКСИМАЛЬНО перенести конкретику на последующие этапы, и СОГЛАСОВЫВАЙТЕ, СОГЛАСОВЫВАЙТЕ....... Не ловитесь на подколки, типа "сейчас запишем, потом уточним". Никто не вправе ЗАСТАВИТЬ Вас прописывать в ТЗ то, что не очевидно на данный момент. ТЗ- это документ,
количество приложений к которому (в том числе и корректировок) НИКЕМ и НИЧЕМ не ограничено, просто план-график привязывается к нему, но это легко обходится. У Вас впереди много этапов,
там и все определится ....
To ss.23
Я бы перевел эти понятия так:
"чертежи видеокадров" - дампы экрана или примеры мнемосхем которые выводятся на рабочее место оператора
"БД системы" - структура архива т.е какие параметры с какой дискретностью архивируются и в каком виде выводятся на экран и распечатку
Все это - как правильно заметил уважаемый cthutq - вторичные вещи. которые идут в процессе проектирования системы.
А большинство заказчиков, когда оценят стоимость запрашиваемой диспетчеризации, откажутся от этой идеи.
имхо - на первом этапе ТЗ должно помещаться на 1 листе.
Михаил
Русское слово- "Скриншот"- это точнее. 1 страница - это "высший пилотаж", с первого раза, думаю,
не получится ( в свое время я уместил ТЗ на модернизацию АСУ АЗЛК на 5 страниц при "офигительной"
стоимости этапа). На этапе ТЗ надо руководствоваться одним принципом - "за базар отвечаю", но
"тему надо перетереть".
У меня положение несколько лучше.
Я не специалист в области автоматизации, и не конечный заказчик, а значит могу написать всякую ахинею. Пусть заказчик редактирует эти фантазии и согласовывает (или не согласовывает).
А значит и спрос будет с самого заказчика. Тем более, выбор подрядчика на проектирование автоматики и договор на проектирование будет заключать непосредственно сам заказчик.
Не скажите, не скажите.... "Автоматчик" Вам такое "выдаст", что ваш проект полетит "коту по хвост",
но свои деньги он "вышибит" по-любому. Я бы так и поступил. Стыдно, но факт.
Ну, и хорошо. Он же не будет делать проект автоматики в ущерб управляемому оборудованию (?!).
А деньги башляет Заказчик. Мне по-барабану.
------------------------
Прошу прокомментировать следующий раздел ТЗ:
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. Блоки управления системы автоматического управления (локальное управление вентоборудованием) желательно применить, как готовые изделия, поставляемые вместе с вентоборудованием. К блокам управления системы автоматического управления предоставить документы:
- сертификат соответствия требованиям нормативных документов, выданный государственным органом Российской Федерации по сертификации продукции;
- требования к условиям эксплуатации;
- перечень регулируемых и контролируемых агрегатов и узлов;
- функциональную схему или пояснительную записку, в которой разъяснить принципы работы и взаимодействия регулятора температуры, модуля управления логических и временных процессов, задействованных защит теплообменников и электродвигателей;
- схема электроподключения всех электропотребителей;
- спецификацию соединительных кабелей;
- пояснительную записку и инструкции по монтажу, по настройке и пользованию;
- гарантийные обязательства.
И если будет время, прошу дать комментарий к следующему разделу:
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. Обеспечить защиту АСУ от несанкционированного доступа.
Цитата(ss.23 @ Sep 12 2006, 16:07 )
4.1. Станция АСУ ... (шина C-Bus) ....
Лучше не указывать шину. С-bus подразумевает оборудование только Honeywell, а автоматика может быть на чем угодно.
Цитата
4.2. Возможность работы в системе диспетчеризации, как со станции, так и с любого компьютера в локальной сети.
Это, наверное, надо преобразовать во что-нибудь подобное: "Предусмотреть подключение основной станции АСУ к локальной сети АБК для возможности организации дополнительных станций АСУ на любом из компьютеров сети"
Замечательно. Сейчас внесу изменения. Спасибо.
Здесь ТЗ на автоматику (начало), =250 кб.
Времени нет, но проверьте 4.10. АСУ производит запуск вытяжной вентиляции удаления дыма при пожаре в соответствующем коридоре АБК при срабатывании в нём пожарной сигнализации. По "мировым" стандартам это не допустимо. Дымоудаление должно управляться системой пожарной автоматики.
Не понял. Впервые слышу о такой.
Приходит сигнал от системы оповещения о пожаре, а дальше вентилятор дымоудаления запускается обычным пускателем. В СНИПе особых требований я не нашёл.
Что значит пожарная автоматика?
Странно...

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

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

------------
Хорошее ТЗ от AlexSch. Давно ждал такое. Его бы на пару дней раньше... Можно будет многое почерпнуть.
Цитата(ss.23 @ Sep 13 2006, 03:02 )
Надеюсь контроль состояния систем противодымной защиты системой диспетчеризации допускается.

Естественно, но не подача команд.
Гость_130906
13.9.2006, 15:32
Цитата
4.7. Отображение графиков переходных процессов для каждой локальной системы управления
А оно Вам надо?
Я это к тому что лучше поручить это все специалисту
Господа, можно ли Автоматизированное Рабочее Место оператора (т.е. компьютер), с которого он имеет возможность войти в Систему Диспетчеризации Здания назвать
ТЕРМИНАЛ ?
Применим ли такой термин?