Как-то на кофе-брейке один из сотрудников спросил инженеров по автоматизации: «Что из рабочего опыта вы реализовали для удобства в своей квартире?». К его большому удивлению, самым популярным ответом оказалось «ничего», а на втором и последнем месте был «датчик движения для света». Вроде бы парадокс на тему «сапожника без сапог», но на самом деле любой из автоматчиков умеет отличать профессиональное заболевание («а не замутить ли сенсорный кран в туалете, прикольно же») от настоящей потребности.
Другой вопрос, если речь идёт об удобстве эксплуатации чего-нибудь побольше, чем дачный домик, да еще и чтоб инженерных систем было много. Если этажей больше одного, а помещений хотя бы десятка два, то для бесперебойного и безаварийного обслуживания такого здания приходится содержать целый взвод дяденек. В плохие дни они будут бегать со стремянкой, ругательствами и отверткой и прикладывать все силы, чтобы клиенты не заметили протекающий унитаз или погасший светильник. В спокойные дни они будут играть в Counter-Strike, а вам — если вы вдруг директор — будет казаться, что вы зря платите им деньги.
Если кто думает, что такой работы уже не осталось, так я сам в аналогичном месте имел третье место в общем зачёте за терроров. А если вы вдруг директор, ваши деньги вам дороги, а траффик от игрушек валит работу офисной почты, то наличие автоматики инженерных систем — это неиллюзорная возможность сократить персонал до 2 человек и одного монитора, хотя и большого, не меньше, чем на 50 дюймов.
Я не ручаюсь за точность формулировок, но, возможно, по схожим причинам нас позвали помочь с проектированием автоматики для одного объекта. Не так уж важно, куда именно, наверняка клиенты с подобным «легким» подходом к стройке имеются в портфеле историй каждой компании. При этом заказчик захотел себе достаточно много инженерных систем: тут тебе и холодильные центры, и вентиляция, и теплоснабжение, а еще фанкойлы, водоснабжение, дренаж и несколько специфических систем, связанных с технологией объекта. Как видите, причин захотеть управлять этим «зоопарком» из одного места имелось больше одной. Точнее говоря, этих причин хватило на целых 8 разделов документации. Но возможно, им просто хотелось снизить пропаганду насилия через компьютерные игры инженерам не говорят всей правды.
Тут надо сделать оговорку: всё, что я буду рассказывать дальше, случается на многих проектах. Начинается, как правило, тривиально: а вот вам наше стандартное техзадание, вы же профессионалы, поправьте по своему усмотрению, подписываем и начинаем работать. Правда, в этом конкретном проекте торжественных подписей золотым паркером никто не ставил, все коммуникации велись удалённо. Пандемия жеж.
На наше усмотрение и без котят мы видели свои задачи так:
дистанционное управление включением/отключением оборудования согласно часовым графикам или по команде диспетчера;
накопление и вывод на экран статистической информации о работе оборудования;
формирование и вывод на экран журналов и отчётов из накопленных данных системы диспетчеризации;
возможность проведения ситуационного анализа по оптимизации использования энергоносителей в каждый конкретный отрезок времени;
своевременное применение мер по предотвращению опасных или аварийных ситуаций в текущий период времени и разработка соответствующих управленческих решений на будущий период времени.
Ну и кроме этого стандартная в таких случаях трёхуровневая архитектура (датчики — контроллеры — компьютеры операторов), 10% резервирование всех частей системы (оборудование, точки подключения), наработка на отказ не меньше 30000 часов. Приятным бонусом чисто профессионально и исполнительски было решение о разделении шкафов на шкафы управления (пускатели, переключатели режимов, органы местного регулирования) и непосредственно шкафы автоматики (датчики, контроллеры, коммутаторы). Фломастеры на вкус у всех разные, а я больше люблю этот вариант как с точки зрения проектирования, так и с точки последующих обновлений линейки контроллеров.
Реализация проекта
В общем, кто бы из коллег отказался? Проект приятный, цели достижимые, задачи чёткие. Но как уже было сказано, с «правдой» все было сложно. Хочу пояснить — никто из нас обычно и не рассчитывает на идеальные условия. В среде проектировщиков даже есть такой термин как «проектирование с колес», т.е. когда твои чертежи сразу отправляются на стройку. Но тут использование этой технологии перешло все разумные границы.
Первый раз мы напряглись, когда через месяц после выдачи старой спецификации фанкойлов нам прислали новый вариант не надо так В новом варианте всё оказалось настолько новаторским, что изменилось не просто количество оборудования, а даже вендор. Попытки аккуратно прояснить ситуацию в дальнейшем напомнили мне сюжет тех видосов, где герой выдёргивает какой-нибудь блокнотик из шаткой пирамиды вещей, а через секунду оказывается погребён под ними.
Выяснилось, что половину данных нам дали на старое оборудование, вторая половина оборудования уже находится в закупке, а на «третью половину» мы вообще повлиять никак не в силах, потому что она куплена с отступлениями от техзадания. «Просто затребуйте новые исходные данные и сдвиньте срок проектирования», — наивно посоветовал мне один из моих друзей, когда я при встрече поплакался ему на такое отношение. Можно подумать, мы не догадались. Но лучше не стало, обновления данных стали посылаться с такой скоростью, что мы едва успевали их анализировать. И какие это были исходники! Представители инженерных разделов очень хотели, чтобы мы догадались о функционале их систем по кускам чертежей, вырезанным windows-ножницами из основного листа. Нам предлагали получить информацию о схемах подключения оборудования «просто вбив названия с чертежа в гугл, неужели это сложно?».
Здесь самое время поговорить о том, что спасло нас как непосредственных исполнителей работ. Ведь заказчик хотел проект в срок, несмотря оригинальную трактовку понятия «финальные исходные данные». А если есть среди читателей автоматчики, то они представляют себе объём документации в бумаге конкретно по нашему разделу. Ну и не будем забывать о том, что версия выходит не одна, ведь ошибки никто не отменял. И если предыдущих «если» вам было недостаточно, и вы продолжаете считать, что ошибок уж точно можно избежать, применив программный комплекс «Х-plan», «Y-electrical» или какой-то еще, то… Возможно, вам повезло. Мы честно пробовали «удалять гланды» по–разному, но решили, что стоит бороться с причиной болезни, а не с симптомами.
И вот что мы сделали.
На первом этапе мы посадили отдельного инженера разгребать и систематизировать поток информации от заказчика, отвечать на его запросы и задавать встречные. Когда всё было более-менее систематизировано, стало понятно, о чём следует спросить еще раз, с чем стоит подождать и не работать вовсе, а что не сильно поменяется даже после уточнения. Так у нас наконец появились чёткие понятия об объёмах работ в виде: тут 15 датчиков на этот шкаф, здесь снятие сигналов с комплектной установки, а там предусматриваем кабель и шлюз и так далее. Это не первый наш большой проект и практика показала, что в системно насыщенных проектах важно разбить весь большой объём работ на мелкие функциональные блоки задач. Если отладить все взаимосвязи внутри блока, заранее подумать, как с минимальными корректировками можно создавать большие чертежи из таких же маленьких, отлаженных кусочков, то в пределе у конечного исполнителя даже нет необходимости понимать, с чего всё начиналось и как конкретно этот блок работает.
Так мы добрались до второго этапа. По изначальному замыслу ГИПа вся автоматизация этого объекта помещалась в один том. Вместо этого мы разбили один том на разные разделы и выделили некоторое количество совпадающих узлов. Далее, как известно, основной объём бумаги и проектного времени отнимают электрические схемы шкафов и их эскизы.
Тут у нас были:
данные, определившие количество точек ввода/вывода как результат первого этапа;
зарисовки (уже очень давно разработанные) всей начинки шкафов от автоматического выключателя и клеммы до модуля контроллера.
Совместив их, мы получили эскизы всех основных шкафов автоматизации в проекте. Конечно, по этим эскизам нельзя строить, но получившиеся размеры шкафов и их основную начинку можно было выдать на обсчёт стоимости. А габариты можно было вполне уверенно заявлять заказчику, чтобы его инженеры зарезервировали нам место по принципу: «здесь будет стоять махина точно не больше, чем вот эта».
Третьим этапом стала шлифовка получившихся эскизов. На базе них мы отрисовали прототипы: шаблонные чертежи для основных типоразмеров шкафов. И оказалось, что шкафы автоматизации вентиляции для некоторых типов установок похожи на шкафы контроля системы электроснабжения. А вообще во всем проекте, благодаря адекватному распределению объемов точек ввода/вывода, удалось применить всего два типоразмера шкафов.
После согласования с заказчиком решений на этом этапе, нам оставалось только применить полученные прототипы с незначительными изменениями для разных разделов проекта (автоматика вентиляции, автоматика теплоснабжения и т.д.). И, как я сказал, в этом случае конечному исполнителю уже не требовалось понимания, каким чудом полученный прототип работает. Он просто брал первый типоразмер, приводил в соответствие исходные данные по точкам ввода/вывода и количеству модулей в чертеже, расставлял подписи к сигналам («выключен автомат 1», «сработал датчик температуры TE15») — и переходил к следующему.
Четвёртым этапом в идеальном мире должна быть стыковка шкафов силового управления и шкафов автоматики в единую систему. Мне одинаково нравятся как вариант размещения модулей ввода/вывода с обеих сторон этой цепочки и последующего объединения их по сети, так и вариант связи межшкафными многожильными кабелями. Но идеальный мир остался в сферическом вакууме, где-то вместе с небезызвестным конём, а шкафы силового управления заказчик пожелал забрать в свою зону ответственности. Тогда мы договорились о маркировке клеммных колодок с обеих сторон так, чтобы при монтаже можно было разобраться, какая из клемм в обоих шкафах относится к одной технологической установке. К слову, маркировка межшкафных кабелей в нашем проекте имеет сложную многосоставную структуру и даёт возможность идентифицировать подключение вплоть до модуля контроллера. Передаю привет проектировщикам, именующим кабели в своих проектах как «Линия1», «Линия2» и желаю им… Ну, хотя бы разок самим монтировать свой же проект.
Где-то на пятом этапе полагалось открывать шампанское и нарезать сыр «Российский», но тут случилась вишенка на торте — расширение объёмов проектирования в виде добавления ещё одного раздела. Даже с учётом адекватного сдвига сроков по причине добавки раздела было понятно, что мы не успеваем.
Наверное, всем известны истории неприятного опыта работы с «субчиками», особенно если надо, чтобы они приступили к работе вчера срочно. Но тут наш проверенный пул подрядчиков не подвёл. Изначально чётко обозначенная задача: «делать в рамках единого с нашим шаблона и не допускать отсебятины» оказалась вполне посильной, и дополнительный раздел был сдан вовремя. Если скаламбурить известное высказывание: может, и не мы придумали нанимать субподрядчиков, но зато мы умеем даже их запихнуть в наши шаблоны.
И даже когда на «пять с половинном» этапе потребовалось внести корректировки в уже выполненные экземпляры чертежей, достаточно было исправить одну типовую ошибку вместо нескольких разных. Потому что когда наши блоки работают так, как надо, то нет необходимости понимать принципы их работы. Если из-за изменения исходных данных вдруг потребуется менять что-то в базовом элементе, то достаточно разобраться и исправить один изначальный, чтобы потом, опять-таки без понимания, поправить все over 9000, что были созданы на его основе.
Результат
А что же в итоге? Перефразируя Галилея: «В итоге, оно завертелось». И этим примером я хотел бы продемонстрировать, что вера в волшебную кнопку «сделать круто» по-прежнему не основана ни на чём, кроме лени. Autocad Electrical, Eplan, E-куб (он же e3 series), SmartPlant Instrumentation — тысячи их. Но ни один из них не поможет бороться с плохим качеством исходных данных, не сделает за вас работу по чисто инженерному определению объёмов проектирования, не примет решение о выборе типа контроллера. В нашем случае построение работы по принципу конструирования сложных блоков из простых отлаженных операций позволило всем инженерам работать в едином пространстве, контролировать и проверять друг друга, доделывать работу за других в случаях болезни или отсутствия.
Без сомнения, известное «проектировочное» ПО способно автоматизировать рутинные операции, но идеи по сокращению количества самих операций, по принятию решений, позволяющих снизить бесполезную часть работы большего числа людей — это то, с чем машины пока не справляются. Что к лучшему, а то бы нас всех давно уволили.
Но хватит хвалить себя. Вы - заказчик и хотите, чтобы на проекте не было сюрпризов. Что ж, говорят — это лютый челлендж, но запишите на всякий случай рецепт. Итак, вам понадобится:
четко обозначить задачу — вы должны хотя бы в очертаниях представлять, что хотите получить на выходе: речной трамвайчик или ледокол, а уж с точностью формулировок мы поможем. Звучит банально, но сколько раз нас просили переделать одно в другое;
не строить крышу без фундамента — нельзя проектировать раздел автоматики в вакууме, пока не приняты базовые концептуальные решения по инженерным системам, которыми мы и будем управлять. Если вы заставите нас проектировать шкаф управления для вентиляции, когда ещё нет ясности, какой именно тип вентиляции будет на объекте, то вас ждут только переделки и срыв сроков. Важна разумная последовательная работа;
всегда помнить, что крыша обязательно будет — да, тут мы слегка издеваемся. И все же, постарайтесь вспомнить про нас на старте проекта. Нам будет удобнее договориться со смежниками «на берегу», разделить зоны ответственности, обсудить концептуальные решения;
не играть в ЦРУ — давайте, пожалуйста, все исходные данные, которые попросят специалисты, не надо думать, что мы воруем результаты труда ваших инженеров. Да, нам действительно нужно ВСЁ ЭТО, а не кусочек проекта. А ещё мы практически бесплатно сделаем аудит совместимости разделов, которые вы пришлёте. И обязательно вас удивим, да-да. Потому что это электрику все равно, что творится в разделе вентиляции, а мы обычно увязываем их всех во что-то целое и работающее;
не заниматься клинописью – мы просим определённый формат данных, чтобы уложиться в назначенные сроки. Планы проекта в PDF вместо исходников? Полный каталог вместо конкретного листа данных на оборудование? Выбивать из ваших вендоров нужную нам информацию? Мы всё это можем, но для этого мы потратим время, которое вы выделяли на проектные работы;
доверять профессионалам – если вы наняли кого-то выполнять работы, не стоит учить, как делать правильно. Или рассказывать, что кто-нибудь сделал кому-то из ваших знакомых иначе. Вы же с врачом не торгуетесь?
снять розовые очки — факапы всегда будут, принтер зажуёт лист, уборщица положит сервер, что-то непременно забудут внести в проект. Важно закладывать реальные сроки в днях, а не трудозатраты в часах с точностью до десятого знака после запятой.
Этого достаточно, поверьте. Остальное мы берем на субподряд себя.
Ну а если кому по душе сухие цифры, то 8 разделов автоматизации инженерных систем, в сумме около 1200 листов (если перевести в формат А3), выпущено за 2 месяца.
Остались вопросы? Моя почта - KVoronkov@croc.ru