Comments 27
Так какой посыл статьи?
На всех скриншотах даже крестик Автокада поленились убрать, а ошибки в русском не делают документацию краше.
После таких проектов, как правило, здания сгорают лет через пять, к большому сожалению.
В этом проекте в части АСУД нормы пожаробезопасности нарушены не были
Где на структурной схеме АУГПТ? У Вас указан объект управления Система газового пожаротушения, но не автоматический, судя по названию, и вы с ним только DI сигналами обмениваетесь. Также не понятно как вы ее запускаете от ИПР на входе или непосредственной близости к помещению по визуальным признакам пожара.
Не буду множить все здесь спрошу.
На плане отсутствует указание категории и класса пожароопасности помещений. Вы главгос не проходите?
Почему на плане нет трасс кабельных проводок?
Почему на плане расположения нет выноски материала для закладных крепления шкафа ЭКГ на стене?
Какой смысл в высотной отметке для не требующего монтажа и перемещаемого монитора, который стоит судя по всему на столе (догадка)?
И уже вопрос, просто ради интереса.... Как человек, сидящий за двумя мониторами на весь, стол общается с 4 сотрудниками, расположившимися в креслах?
Добрый день.
Данная структурная схема выполнена для проекта АСУД, где в части АУГПТ учтена только диспетчеризация (отображение состояний на мониторе: Пожар, Неисправность, Газ подан...). Сам проект газового пожаротушения выполняется отдельным томом.
На скриншоте отображен не весь план, а фрагмент.
Кабельные трассы выполнены на стадии Р.
Выноски материала на стадии П не выполняю.
Высотная отметка подгружена из конструктива. Действительно прилипла не к месту.
Данное решение согласовано с сотрудниками ТХ и АР.
Стадия П на АСУД по постановлению состоит из одного абзаца в текстовой части разделов ИОС1...ИОС4, ТХ. Всё остальное - отсебятина или излишняя инициатива заказчика.
Вы правы, согласно 87 ПП раздела АСУД не существует. Решения входят в соответствующие тома технологов
То что авторы 87 постановления не озаботились нормально расписать раздел ИОС5 не значит, что нужно сводить с ума экспертизу и распихивать решения по смежным разделам. Во всяком случае Московская государственная экспертиза (МГЭ) желает видеть это отдельным томом. Так же непонятно как по паре абзацев потом считать сметы и тому подобное.
А желание экспертизы, не подкрепленное нормативными требованиями, вообще никого волновать не должно. К сожалению, на них нет управы, поэтому приходится терпеть. Сметы считаются по спецификации, подготовленной проектировщиком для сметчика. Чисто по чертежам вы и освещение, например, не посчитаете, так как планов освещения в постановлении 87 тоже нет. Да и другие инженерные разделы можно только очень приблизительно посчитать.
Сталкивались как с требованием "включить всё слаботочное и сигнализирующе - автоматизирующее в ИОС5", в. т.ч. например квартирные звонки на 220 В, так и с лояльным отношением к тому, что автоматизация ИТП например учтена в разделе ИОС4. Второй подход более нормативно и логически обоснован и исповедуется многими опытными проектировщиками. Но первый вариант видимо удобнее для экспертов и они продавливают, что надо именно так. И в одной и той же экспертизе, но у разных экспертов, может пройти как первый вариант так и второй.
Вот все бы проектировщики так к проектам относились - цены бы вам не было!!! Я как бывший АСУТПшник говорю. Многие проектные институты клепают проекты на "отъебись". А потом, при разработке и пусконаладке вылезает куча проблем. Мне кажется проблема в том, что нет связи проектировщик <-> АСУТП на стадии создания проекта. Я не видел еще ни одного проектировщика, кто реально был бы на объекте внедрения и своими глазами видел ту "боль", что проходит АСУТПшник и пусконаладчик.
я бы, все таки, посоветовал Вам начать не с того, как АСУ видит рядовой проектировщик (нацелена на... разработку некого комплекта документации), а с того как он ее должен представлять, чтобы запроектировать, а именно с цели создания самой автоматизированной системы. Если вы затронули состав документации, то почему вы не упомянули полный комплект на АС по ГОСТ 34 серии? Вы описали только одну часть - техническое обеспечение. Вы главный специалистом по автоматизации возможно у вас в организации есть разделение и вы не занимаетесь АСУ, а только КИП? Тогда в серии статей вам сразу стоит определить чего ждать и чего нет. У вас же есть план статей? Также напрасно вы упомянули возраст. Это указывает или на текучку в коллективе или на низкие требования к компетенциям для большинства читателей. Логика рассуждений такова, что если у вас есть высшее образование то вы приступили к работе в 23. Реализация проекта до момента ввода в эксплуатацию включая экспертизы это минимум 3 года. Т.е. по вашей работе недостаточно обратной связи и завершенных строительств, не говоря уже об этапности карьерного роста инж, инж. Х категории, ведущий, рук. рабочей группы, гл. спец. Правильно ли можно понять, что за 4 года вы прошли 5 должностей? Что же касается фразы: "в этой профессии вообще нет ничего сложного" она думаю задела многих АСУшников, имеющих соответствующее образование (буквально АСУ). Если вы не столкнулись с сложностью, то значит ваша организация делает типовые проекты сложности в которых решило предыдущее поколение. И в частности, ваш пример вентиляции давно уже не проектируется в полном смысле этого слова, а тиражируется на базе типовых альбомов 90г. https://meganorm.ru/Index2/1/4293800/4293800914.htm не стоит обобщать с реальным проектирование, к примеру, технологических процессов опасных производственных процессов, с элементами критической инфраструктуры, системами ПАЗ по технологиям которых еще нет, то что в типовых проектах, но даже в НТД государства. .где решения принимаются коллегиально "на мозговом штурме" и фиксируется ответственность за их безопасность.
Так по примеру документации видно, что это датацентр. АСУ там больше на мониторинг заточен, чем на управление (управляется как правило локальными контроллерами самих подсистем). Соответственно сложность проекта имхо низкая (но щеки надувать позволяет).
Я решил не разводить демагогию про цель создания системы, чтобы не засорять эфир информацией из методичек. Эта статья, просто мой конспект. Основная часть проектов нашего департамента все же гражданское строительство, из которого мы сознательно убираем упоминание о 34 ГОСТ. Мы занимаемся и КИП тоже. План статей есть. Далее я расскажу про стадию Р. Потом углублюсь в схемы электрические принципиальные, потом в планы. Я начал работу на последнем курсе бакалавриата, то есть на 4м году обучения, поменял несколько компаний, а в последней уже 5 лет, где прошел 3 должности (старший, ведущий и последний) (Возраст указал для того, чтобы дать понять начинающему специалисту, что рост имеет место быть в инженерной среде. А в проектных институтах обосновались не только дедушки). Понравилось выражение про сложности, с которыми разобралось предыдущее поколение... Я в каком то роде тоже хочу поставить засечку для будущих. По поводу критических инфраструктур, полностью с вами согласен - более интересная форма проектирования, которую я отчасти затрагивал и надеюсь в дальнейшем, если меня одобрят в другой проектный институт с подобным опытом, я законспектирую, как выглядит "мозговой штурм"
Вся сложность АСУТП заключается в правильности проектирования с соответствующим запасом входов-выходов для последующего исправления ошибок проектирования. Остальная сложность в теме - незнание АСУ-шников своей профессии. Это устраняется опытом или обучением. Лучше всего проектировать, зная что тебе потом придется это строить. Что я не один десяток раз и проделывал. И таки получается нормально.
За деревьями леса не видно.
Желание обобщать и упрощать это способ выполнять работу, не вникая во все нюансы и не имея достаточного опыта и знаний. Если удобнее воспринимать не более одной сложности, то я сформулирую, что вся сложность проектирования АС состоит в том, что нельзя обобщить сложности разработки АС для разных объектов управления. Железо со вводами это мертвый груз на объекте без математического обеспечения и корректной и своевременной информации о параметрах. Все что отражено в статье, в том числе и на схемах автоматизации это россыпь отдельных типовых контуров. Чтобы собрать их в систему нужно понимать цель функционирования АС и в том числе цель функционирования объекта управления. Со времен унификации типов сигналов управления и измерения составлять схемы можно с базовыми знаниями электротехники. Раньше схема принципиальная на релейные шкафы содержала ПРИНЦИП работы и полную информацию, теперь это вынесено в МО и те кто разрабатывает схемы также должен понимать, что будет с их решениями дальше в системе потому что контура могут быть или каскадными(иерархическими) или дополняющими (грубо/точно), а выходной параметр может быть в решениях другого разработчика. К примеру, у Вас завод в 5 последовательных технологий (цехов). Вы каждый цех проектируете как самостоятельную единицу потому что не понимаете, что делает весь завод. В то время как на производстве есть как минимум один расчетный плановый показатель, который устанавливается на выход всего производства и его надо реверсом декомпозировать на все предшествующие технологии и предусмотреть входы данного ключевого расчетного показателя в каждой самодостаточной САУ. Вот вам и сложность. Напишите формулу для всех производств. Если они еще и взаимовлияющие. А если показателей больше и если они взаимоисключающие? Кому нужна система, не выполняющая поставленную цель с запасом по входам/выходам?
Автоматизация вообще заключается в автоматизации отдельных агрегатов. Потом это увязывается в общую систему. Нельзя спроектировать автоматизацию завода сверху. Так что мое решение работает. Автоматизировал заводы. Не гиганты конечно, но тем не менее.
Здесь нет предмета для спора и это не моя личная точка зрения. Есть общеизвестные факты из области фундаментальных основ АС, с которыми вы возможно не знакомились, проектируя заводы.
Вот Wikipedia
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:
Техническое задание
Разработка и утверждение технического задания на создание АС
Рабочая документация
Разработка рабочей документации на АС и её части
Сам ГОСТ 34.602:
2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
Мне кажется нужно различать "автоматизацию заводов" и предмет данной статьи. А статья описывает, что из себя представляет АСУД в применении к небольшим общественным зданиям, тем же офисным, или например жилью, и к тому же на стадии "П". Если условный "завод" без продуманной АСУТП просто не заработает, то на объектах попроще действительно все автоматизируется локально, отдельно и по минимуму\возможности\необходимости. В соответствии с нормативами, заданием на проектирование, ТУ, вИдением экспертизы и заказчика, и отпущенными сроками на проектирование. Каковые факторы обычно противоречат друг другу. В процессе увязки всего этого, упомянутый ГОСТ 34.601-90 это последнее, к чему захотят аппелировать все участники процесса.
Согласен. Нужно различать, так и писал ранее на фразу "в этой профессии вообще нет ничего сложного. ".
Также как и термины "Автоматизация" и "АСУ". Если СИСТЕМА, то вы попадаете под ГОСТ 34.601.
Ну и другое утверждение, что нельзя автоматизировать сверху! Больше для юмора никого не хочу обидеть....
Если вы "автоматизируете" унитаз как просто набор четко работающих контуров: нажал - спустил воду и набрал воды до перелива, то будете ли вы довольны, если не смылось? Как без изначальной цели функционирования всего объекта управления создать пусть даже не систему, а просто автоматизацию....
Последняя цифра в обозначении ГОСТ - год разработки. Я в 97 году автоматизировал городскую котельную при переводе ее на газ с применением PLC. Прикрылся при проектировании ГипроНИИГаз-ом местным. А узаконил проект ГЕНЕРАЛОМ из ГосГорТехнадзора. Ни тот ни другой в глаза такой подход к автоматизации не встречали. Генерал сказал, что первая на просторах СНГ. Я лично не проверял. То есть ГОСТ не актуален был уже тогда. Хотя и придерживались. Только это стоило сильно усложненной системой обозначений. При вольной интерпретации можно было бы сделать существенно проще и понятнее. Понятно, что последовательность ТЗ->ПД->РД не оспаривается. Только при отсутствии компетенции у заказчика(пишется как правило с большой буквы З) . Одностадийный вариант - кто проектирует, тот строит существенно облегчают и удешевляют реализацию.
Был и такой случай, когда строили агрегат, и построили его. Результат был существенно лучше заданного ТЗ, но неумение оценить результат на фоне мелкой, но сильно видимой ошибки, свели работу к нулю. А возобновить нельзя из-за авторских прав.
Не оправдывайтесь за протеже на будущее. Это глупо, так скоро в минцифре кресло будет, а все равно будете юродничать.
А вообще у вас видимо "самозванец" заиграл, решили эксперта изобразить. Так и надо! Без иронии.
Работаю на стороне заказчика, нефтегазовый сектор, каждый день взаимодействую с проектироващиком (подрядчик EPC), и вижу, как такие и похожие "проекты", проходят разработку, реализацию, пуско-наладку, ну и вижу дальнейшую эксплуатацию. Изложенный подход оторван от современных реалий, когда используются типовые решения на всех уровнях - сети, контроллеры, поле, отработанные и опробованные не только проектировщиками, но и интеграторами, и поставщиками, с коими надо бы консультироваться на самых ранних стадиях проекта.
Но зато, то о чем говорит автор, выполненно по ГОСТу.
Кстати, это не камень в личный огород автора, а в огород нашей нормативной базы и федеральных регуляторов.
Буду благодарен за развитие темы. Автору пожелание – не останавливаться.
Проектирование АСУД — Автоматизированная система управления и диспетчеризации (стадия Проект)