Факт: ТЗ экономит до 80% времени на создание системы автоматизации (АСУ) любого объекта или процесса.
Поэтому давайте в этой статье подробно поговорим о техническом задании - ТЗ, как его составить и почему без него проект по автоматизации лучше даже не начинать. Я приведу пункты, которые обязательно должны быть в хорошем ТЗ, чтобы он сэкономил время и нервы всем сторонам проекта.
Техническое задание - документ в ворде или просто на бумаге, рукописный или набранный на ПК, где заказчик автоматизации какого-либо объекта - индивидуального теплового пункта (ИТП), станка, печи и т.д. - расписывает все подробности этого объекта и то, что он хочет получить. Например, я выполнял проект в ИТП одного московского ЖК по замене вышедших из строя программируемого реле Siemens Logo и частотного преобразователя Mitsubishi на отечественные аналоги. Сименс через ПЧ управлял переключением насосов холодного водоснабжения, а ПЧ поддерживал давление в контуре ХВС постоянным. Также на Лого были заведены различные кнопки и переключатели, и он еще управлял рядом аварий и отправлял ряд сигналов в диспетчерскую:
Для написания программы для аналога Лого было необходимо ТЗ. Заказчик был в недоумении - они же предоставили нам схемы подключения, что еще нужно? Но тогда схем было недостаточно - для написания алгоритма работы программируемого реле под конкретную систему нужно было описание логики работы и всех входящих и исходящих сигналов. Заказчик сопротивлялся, но недолго - им были важны сроки, на носу был Новый Год. В итоге их инженер с нашей помощью составил понятное ТЗ, и мы с напарником очень быстро написали алгоритм для миниконтроллера, выехали на установку и пуско-наладку. В итоге все работы заняли 3 дня, заказчик остался очень доволен.
Такой быстрый результат не в последнюю очередь получился благодаря наличию четкого ТЗ.
И был другой опыт - позвонил заказчик, которому нужно было написать небольшую программу для такого же программируемого реле Овен. Но управлял ПР уже не насосами, а вентиляцией на парковке и аварийной сигнализацией о превышении порогов СО. Ему тоже нужно было срочно, он прислал просто схему без технического задания и без описания алгоритма работы. И я нарушил свои принципы. "Ладно" - подумал я - "алгоритм простой, только дискретная логика. Напишу программу с его слов и ориентируясь на схему". Написал, выслал заказчику. Он "залил" ее в ПР и промоделировал работу системы. Прислал правку - этот сигнал должен включаться и выключаться тогда-то, а вот тут давайте изменим время включенного состояния сирены. Ок, я исправил программу. Прошел еще день или два, заказчик попытался сдать систему Ростехнадзору. Не приняли - нет кнопки "Сброс". Заказчик ко мне - опять нужно править программу. Ладно, исправил. Думаю, вы догадались, что таких правок было еще несколько. Доп.плату за правки мы не обговаривали, хотя это моя обычная практика. Итог: почти месяц доработок и беготни заказчика, претензий Ростехнадзора к нему. И трата нашего времени - каждая правка требовала работы по переделке программы. Было бы четкое ТЗ - все было бы сделано за один день.
"Ахиллесова пята" со стороны заказчика в работе по составлению ТЗ - незнание самим заказчиком, как должна работать система. Непонимание с его стороны и отсутствие с его стороны инженера или технолога, который знает, как все должно работать. Это может стать проблемой - исполнитель, даже опытный, не может знать все варианты всех систем во всех отраслях промышленности. Это даже звучит абсурдно. Но в ряде случаев даже незнающий заказчик и опытный исполнитель путем использования четкого ТЗ и консультаций друг с другом или с каким-то сторонним экспертом могут составить вменяемое ТЗ.
Итак, ТЗ сильно экономит время и нервы и исполнителю, и заказчику. Но часто это самый сложный этап - например, один мой коллега-программист ПЛК (программируемых логических контроллеров) даже перестал брать проекты, т.к. устал согласовывать неделями и месяцами ТЗ с заказчиком. В чем секрет успеха - быстрого создания ТЗ, помимо знания заказчиком своего тех.процесса? Грамотный шаблон документа, учитывающий все нюансы. Рассмотри пункты ТЗ для написания программы управления АСУ ТП с помощью ПЛК:
а) Описание системы. Что это и для чего она нужна?
б) Типы и назначение входных и выходных сигналов. Какие датчики будут подключаться к ПЛК и участвовать в программе, сколько исполнительных механизмов и какие именно будут участвовать в работе системы?
в) Настройки системы. Тут надо перечислить все изменяемые параметры, которые могут изменяться оператором и/или наладчиком обрудования в процессе эксплуатации установки.
г) Желаемый алгоритм работы системы. Здесь нужно описать, как должно работать система, пошагово. Желательно четко и без "воды".
д) Если будет визуализация на ПК - SCADA или облако, WEB-визацлизация, или это панель оператора или СПК - желательно нарисовать наполнение экранов. Прямо на бумаге, сколько должно быть экранов и что там надо изобразить.
е) Аварии и нештатные ситуации. Какие и куда надо выводить, кто будет сбрасывать и по каким условиям?
Все. Также любая доп.информация - мощность двигателей или ТЭНов, особые условия и т.д. - также стоит написать в конце ТЗ.
Я помогаю заказчикам в составлении ТЗ, если это требуется.
Если вам нужна диагностика неисправностей оборудования и его настройка, или проектирование АСУ ТП "с нуля" и все "под ключ" - можете обращаться к мне. Мы с партнерами реализовали более 50 проектов по автоматизации: отопление, вентиляция, "умные дома" теплицы, печи, конвейеры, автоклавы, специфические установки... Также мы можем сделать только часть работ: например, написать программу для программируемого реле или контроллера по Вашему ТЗ. Можем только собрать шкаф автоматики и начертить его электрическую схему. У нас большой опыт, обращайтесь на почту master_owen.msk@mail.ru
Ставьте лайк и подписывайтесь на канал, тут много полезного и интересного!