Стартовая страница (единая точка входа) раздела автоматизированных систем управления доступна по ссылке: общий обзор и структурированный перечень статей по теме.
Работа должна иметь цель
Любая создаваемая система должна разрабатываться на основании задания. А техническая система — на основании Технического задания (ТЗ). Это ведь только у самурая нет цели, один сплошной путь. Ему потом результаты пути никому сдавать не требуется, разве только душам предков.
На тему названия документа в комментариях к статье «Об архитектурно-строительном проектировании серьезно и не очень» была дискуссия. Но мое мнение не поменялось, и оно совпадает с большинством экспертных — не так важно, как называется документ, главное, чтобы он имел статус (был приложением к договору и содержал требования, на основании которых будет определяться совпадет ли результат с тем, что было оговорено «на берегу»), а также был подписан ответственными лицами всех заинтересованных сторон. Знаете, сколько было спорных ситуаций и конфликтов на финише. Когда по мнению Заказчика еще надо кучу всего сделать, а исходя из понимания Подрядчика — нет. И только ТЗ ставило точку в споре. Ну или суд, он тоже умеет его читать.
Не очень добропорядочные, но крупные и нежелающие брать на себя какую-либо ответственность переложить все риски проекта на исполнителя одно время повадились прилагать к договору «Технические требования». В одном из первых пунктов там было указано, что Подрядчик обязан разработать и утвердить ТЗ на основании этого самого документа. При том Технические требования всеми родинками напоминали «классическое» ТЗ на автоматизированную систему (АС). Нюанс состоял в том, что АС уже могла работать в полный рост, а этап согласования ТЗ еще не был закрыт, обрастая различными приписками, дополнениями и «хотелками».
А ведь у нас как часто организована работа? Как иллюстрация к картинке из учебника биологии про пищевую цепочку. Договор обычно Заказчик заключает с некоторой дружественной компанией, которая все риски в цене, конечно, учитывает. Дружелюбная компания заключает договор с другой, менее дружелюбной, но скажем так — не чуждой ласковости. Та еще с одной. А делает все в итоге небольшая фирма, практически по себестоимости и хорошо, если не группа фрилансеров из Новой Ляли (да, есть такой город, там стоит допотопный, еще до революции построенный ЦБК и я там был… а еще в этом году у города юбилей). Для тех, кто в конце цепочки любое изменение, да будет известно, очень болезненно. А то и просто неприемлемо: легче все бросить к чертям, чем пытаться реализовать.
В виде простой формулы я напомню, что такое АС.
Автоматизированная система = целевая деятельность + технические средства + программные средства + информация + персонал.
Как вы начинаете догадываться, все компоненты должны быть определены в ТЗ так, чтобы у разработчика не возникло ни грамма сомнения, что он должен в его рамках сделать.
Впрочем, в случае с АС все теоретически просто, ведь есть цельный ГОСТ, который так и называется «ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Касалось бы, открывай официальный документ, да начинай разрабатывать по нему задание. Тут даже читать много не надо, всего 13 страниц, где полезный текст содержится только на семи. И документ сей заменяет редакцию от 1989 года, которую многие ранее читали и морщились — ну кто так пишет, ну что за термины из прошлого века.
АСУТП (автоматизированная система управления технологическим процессом) — одна из разновидностей АС.
Я не буду заниматься сравнением редакций ГОСТ, благо эта работа многократно проделана и выложена в сеть — Яндекс Вам в помощь. Скажу только, что изменения не глобальные, но совсем уж устаревшую дичь убрали. И в данном случае это правильно, подход сохранен, он доказал свою состоятельность, но жизнь не стоит на месте.
Давайте что ли ГОСТ почитаем.
О чем говорит ГОСТ
1. Авторы, конечно, вспомнили, что документ могут использовать идиоты. Иначе, как объяснить специальное упоминание, что требования ТЗ должны быть единичными, непротиворечивыми, актуальными, выполнимыми, проверяемыми и однозначными. А еще максимально детализированными. Не надо было мелочиться, надо было дописать, что критерий выполнимости — возможность реализации всех функций на продукции фирмы ОВЕН. И это что же, в ТЗ перестанут писать что-то типа «на стадии подготовки спецификаций проекта необходимо предусмотреть достаточное количество резерва по оперативной и дисковой памяти, а также по быстродействию микропроцессорных устройств и промышленных сетей, которые (резервы) потребуются для развития функций Системы»? А вот возьмут сразу и напишут — сколько чего вешать в граммах?
Но если серьезно, то так и представляю себе картину, как ты начинаешь рассказывать представителю Заказчика, что тот документ, который он три недели разрабатывал и еще три месяца согласовывал со смежными службами, убирая в их угоду всю конкретику (иначе они не согласовывали) тлен и не ГОСТ. Ответственность они страсть как не любят, в большинстве своем. И вроде бы правильной дорогой идет товарищ, но может нарваться на «ну вот сам и пиши, и согласовывай». Или вот это «вы же будете проектировать, вот и определите в процессе».
2. Указано, что отдельное ТЗ можно не готовить, если требования к Автоматизированной Системе (АС) включены, например, в задание на проектирование Объекта капитального строительства (ОКС). Собственно, было так всегда. Да и сдача ОКС осуществляется в комплексе. Но интересен практический вопрос — а вот что делать, если в общем задании АСУТП посвящено две строчки и мелким подчерком. Даже больше скажу — так часто и бывает: приходится выкручиваться, писать протоколы, выпускать основные технические решения, а чаще просто — свое видение вписывать в проектную документация, а дальше: что получилось, то и получилось. Нравится, не нравится, но это прошло экспертизу, моя красавица.
3. Приведен минимальный перечень разделов, который необходим для описания любой разрабатываемой системы и должен присутствовать в документе. Проблема тут всего лишь в том, что разделы должны быть заполнены конкретными и выполнимыми пунктами. Ну мы про это выше писали. В природе встречается категорически редко.
Я очень не люблю, когда мне приходят ТЗ на АСУТП, как правило с каких-то тендерных площадок, где разработчики, уж не знаю причин, идут по пути точнейшего соответствия их творения ГОСТу. Ну как они это понимают. То есть ГОСТу соответствует только структура документа, а дух его безвозвратно утерян. Я называют такой документ «вульгарным». В разных редакциях он преследует всех разработчиков систем АСУТП.
Делается он, видимо, так. Сначала кто-то грамотный, но очень занятой формулирует кратко то, что должна делать система по факту. Затем это попадает в какую-то службу, где с ужасом обнаруживают, что в таком виде документ не пройдет верификацию с видением высшего разума или с корпоративными стандартами. Из всех мест Интернета, а может даже из каких-то, как правило, устаревших, учебников, аккумулируются самые общие требования типа «система должна быть надежной», куда как-то вставляются изначальные требования, затем все это причесывается и оформляется в форме документа, похожего на ТЗ с разделами «строго по ГОСТ». Чтобы продраться через дебри бессмысленных фраз нужно обладать опытом, как минимум, Шерлока Холмса. Я знаю десятки вариантов сделать систему надежной, но за большие с нюансами, и за очень большие деньги гарантированно — вам какой?
Впрочем, есть и иная крайность, когда ТЗ состоит из одной-двух страничек, на которых отображена информация хоть и по делу, но крайне в сжатом виде. Тут только поддаваться экстремизму и все пропущенное принимать волевым усилием и из опыта, тщательно прописывать в техническом предложении, в надежде, что его кто-то прочитает, осмыслит и даст обратную связь.
4. Со времен институтов и всяких там лабораторных у нас не любят формулировать цели создания АС. Подозреваю, что просто не умеют. Могут написать что-то расплывчатое, разбавленное «улучшением показателей производительности». А между тем это важнейший пункт, который не только определяет то, зачем это все, но и позволяет понять, достигнуто требуемое в результате или нет. Цели вообще должны быть сформулированы с учетом критериев SMART — пока это лучшая методика их формулирования. Кстати, ГОСТ пишет прямо: «указываются критерии оценки достижения целей создания АС».
5. Характеристика объектов автоматизации — это про то, что именно мы автоматизируем. Пункт важен тем, что реализацией системы занимаются инженеры-автоматчики, ни в одном глазу не технологи. Они ничего не знают, как это работает и как должно функционировать потом. По-хорошему — к такой характеристике должно идти куча приложений, которые позволяют познать технологический Дзен. А у нас как: напишут несколько слов про состав системы, а дальше езжайте, смотрите, общайтесь с эксплуатирующим персоналом. Все это очень хорошо и даже полезно, но как может понять увиденное в литейном цеха инженер-программист, который теперь специалист АСУТП, даже меня иногда удивляет.
Кстати, когда мы выполняем работы только по АСУ, то не можем оценить эффективность того, что получится с точки зрения технологии. Реализовать — пожалуйста, а в части сопутствующего эффекта — это к другим людям. Глупо потом выставлять претензии, что мы не достигли требуемого эффекта «с вашей системой». Подождите, коллеги, но ведь все требования ТЗ выполнены, разве нет? На это другая сторона любит вспоминать «ну вы же специалисты!». Ну да, специалисты по реализации систем автоматики, но не режимной наладке на данном оборудовании. И когда иногда вспоминают про гарантийные параметры системы (благо очень редко), то подписаться можем только под скоростью прохождения сигналов и еще чем-то связанным с нашим оборудованием. И то, если сами его подбираем, а не тупо реализуем на элементной базе Заказчика.
6. Структура системы должна быть определена в ТЗ. Это не самый трудный вопрос: обычно сколько уровней должно быть все прекрасно понимают. Полевой, средний, верхний. Иногда не нужен верхний уровень, порой появляются промежуточные подуровни, а бывает, что АСУТП является частью какой-либо распределенной системы управления производственными процессами. Тогда простого понимания структуры недостаточно: требуется определить взаимодействие системы со всеми смежными АС, вплоть до способов обмена информацией, описания состава и структуры данных. Вот где и начинаются трудности.
Нужно указать разработчику и режимы функционирования, и как будет обеспечиваться диагностирование, и даже как планируется осуществлять модернизацию всей системы когда-то в будущем.
7. Требования к АС должны включать расширенное описание реализуемых ею функций, требования к различному обеспечению, а также различные подробные технические требования.
Опять же, функции — это не безликие «формирование отчетов (текущих, сменных, месячных), их распечатки», а конкретный перечень, включая отображаемую информацию. В ГОСТ написано «для каждой функции должен быть указан результат ее выполнения и, при необходимости, приведены основные характеристики результата».
Что такое виды обеспечения? Если простыми словами, то это то, что не является АС, но используется для ее создания и эксплуатации. Это математическое, информационное, метрологическое и все такое прочее обеспечение. В том числе комплектующие, которые допускаются к использованию в конкретной АС.
8. Все системы обладают своими особенностями, но важно обратить внимание на то, что следует приводить ссылки на действующие НТД, если хотите, чтобы АС им соответствовала. Дело в том, что на территории РФ применение НТД является добровольным. Это не означает, что АС может не удовлетворять никаким стандартам, но подразумевает, что разработчик их может определять сам. А все иное — это от лукавого. Не один раз на это обращали внимание на всяческих мероприятиях по техническому регулированию различные экспертизы и даже органы исполнительной власти. В ТЗ должен быть конкретный список документов, которым объект должен соответствовать. Точка.
Только это… не надо вписывать вообще все документы, которые вы знаете на тему АСУ. Это крайность, которая также чревата. Тут стоит упомянуть, что нормативные документы имеют очень много противоречий. И не все, что там написано, может вам понравиться. Это к тому, что прежде чем их записывать, неплохо бы почитать о чем они.
9. ТЗ определяет и то, какой персонал будет ее эксплуатировать. Количество, квалификация. Это важно как на этапе разработки интерфейса, так и при написании различных инструкций. Про сами инструкции и требованиях к ним не стоит стыдливо умалчивать, а включать в раздел «Требования к документированию».
10. Одним из самых крупных разделов, который должен быть обязательно — это требования по безопасности. В ГОСТ ему уделено совсем мало, но по факту это и подробное описание всех реализуемых мероприятий, блокировок, аварийных событий и запускаемых алгоритмов безопасности. От детализации и содержания будут зависеть жизни тех, кто работает с оборудованием и даже стоит рядом, как бы это банально не звучало.
11. Не стоит забывать про требования к эксплуатации, техническому обслуживанию, будущим ремонтам. Может так случиться, что в инструкции по эксплуатации напишут, что систему необходимо протирать спиртом ежедневно утром и вечером — на радость обслуживающему персоналу. А иначе она снимается с гарантии.
12. Ну и про порядок контроля и приемки автоматизированной системы, который порой является настоящей болью, когда недостаточно конкретен. Ибо аппетиты Заказчика имеют свойства расти с каждой новой успешно автоматизированной функцией. А мотивация Исполнителя падает с каждым днем, который идет свыше договорного графика, так как тут начинается для него финансовый убыток. И это простой инженер может не видеть ничего страшного, что пришлось чуть-чуть попотеть больше, а вот его руководство начинает судорожно считать, сможет ли оно ему заплатить заработную плату. Я утрирую, но смысл тут примерно такой. Поэтому прозрачные процедуры, которые определены «на берегу» и позволяют сдать объект в срок и максимально безболезненно очень важны.
И о нюансах
Система нужна сейчас, а исходных данных нет. Это актуально в последнее время, когда сроки поставки ПЛК стали космическими. Поэтому договор на разработку и поставку нужен тогда, когда кроме названия АС больше ничего и нет. И недостаток данных начинают замыливать под общие и обтекаемые фразы даже матерые специалисты. А между тем, это также нарушение ГОСТ, где написано, что в этом случае для требований «следует сделать запись о порядке установления и согласования показателей и требований». Если этого не будет, то создаются предпосылки для целого букета ситуаций, которые могут негативно сказаться на результат. И кому это надо?
Заказчик забыл передать ранее отсутствующие исходные данные. Или передал после проектирования и изготовления системы. Не было согласования, и разработчик принял ключевой параметр на свое усмотрение, отчего система работает не так, как хотелось бы. И еще много-много разных ситуаций.
Есть нюанс, который пришел к нам со времен СССР. Для опытных бойцов нашего фронта вещь известная. Дело в том, что система может разрабатываться, проектироваться аж на основании трех групп стандартов: ЕСКД (2.ХХХ), СПДС (21.408) и ГОСТов группы ЕКС АС или ИТ (34.ХХХ) с примкнувшими к ним рекомендациями и руководящими документами (РД). Я надеюсь, что расшифровывать эти милые сердцу аббревиатуры не нужно. Какая будет документация по итогу разработки обязательно должно быть зафиксировано в ТЗ. Случай, который показывает, как это важно описан в статье «Об архитектурно-строительном проектировании серьезно и не очень». И мне заранее жалко тех авторов, которые копируют всю им известную нормативно-техническую базу в свое ТЗ.
АС может разрабатываться для определенного технического комплекса, который поставляется в сборе. Комплекс создают конструктора, они не специалисты в автоматизации, но выпускают свою документацию, частью которой будет являться АС по ЕСКД. Извольте, так сказать, соответствовать. Если это указано в ТЗ, конечно.
Большинство АС, которые АСУТП, разрабатываются для нового строительства и реконструкции в рамках СПДС. Результат проектирования определен в ГОСТ 21.408-2013 «СПДС. Правила выполнения рабочей документации автоматизации технологических процессов». И это все в основном про железо: шкафы автоматики, КИПиА, кабели и кабеленесущие системы. На этом проектное сопровождение заканчивается. Программное обеспечение — боль для той компании, которая будет систему запускать. И в этом есть логика. Лучше этим занимается один исполнитель, чем несколько. Тем более, что для проектирования систем по ГОСТ 34* нужно и код разрабатывать, а кто его проверить-то сможет?
Ну и когда АС выполняется отдельно, как правило, для уже действующей установки и производственной линии, то возможно, что ТЗ будет по стандартам 34 группы. Опять же, здравый смысл подсказывает, что разрабатывать, изготавливать и запускать все должна одна компания. А если этого не происходит, то жадный Заказчик потеряет очень много времени и денег дополнительно. Благо каждому исполнителю будет на кого валить.
Вместо заключения
ТЗ — это серьезный документ, который, как и в случае с заданием на архитектурно-строительное проектирование — результат кропотливой работы большой команды. По крайней мере так думали все те умные люди, которые создавали методологию разработки технических систем в нашей стране.
Давайте я напомню Вам стадии создания АС, как это предполагалось изначально:
1. Формирование требований к АС, как правило, по результату некоторой предпроектной-практической работы или даже научно-исследовательской работы. Задачи: определение целей и задач автоматизации, формирование бизнес-требований к системе.
2. Определение концепции, в рамках которой рассматриваются варианты реализации системы, которые сравниваются и выбираются наилучшие. Выполняются также в рамках технического обследования или научно-исследовательской работы.
3. Разработка технического задания, где окончательно для наилучшего варианта формируются требования к АС, выполняется их утверждение всеми заинтересованными сторонами.
Далее уже банально:
4. Технорабочее проектирование (может включать несколько стадий: эскизный проект, технический проект, рабочая документация).
5. Ввод в действие (пусконаладочные работы, подготовка персонала, испытания системы и т. д).
6. Сопровождение АС (эксплуатация).
ТЗ пишется не с чистого листа и не должно содержать лишних слов и воды. Для меня показатель качественности документа, когда можно брать каждый пункт и преобразовывать его в конкретные задачи, которые необходимо учесть при реализации системы.
Ну, например, написано: «Обеспечивать выдачу звукового и визуального сигнала при отклонении технологических параметров от нормы и аварийных ситуациях / системы ПАЗ по месту», а я себе записываю: а) в электрических шкафа ПЛК схемах предусмотреть подключение светозвуковой колонны, б) в спецификации учесть светозвуковую колонну, динамики для АРМ оператора. Правда и тут авторы обошлись без так нужной конкретики. Если с АРМом понятно, то куда ставить колонну и одну ли, это надо придумывать самому.
Кстати, ниже в источниках указан ряд новых ГОСТов на АС, которые вступили в действие совсем недавно. Рекомендованы к ознакомлению.
Многое, о чем написано выше, это размышления о неблагоприятных сценариях, которые, к сожалению, очень часто любят случаться на практике. Часто, но не всегда, что внушает некоторый оптимизм. Благо умных и понимающих специалистов у нас еще достаточно, они ничего такого не допускают. В том случае, когда заинтересованы в конечном результате. Беда в том, что у нас много людей работают, которые в результате не заинтересованы, деньги они получают за процесс. И это такая подсказка для их руководства.
А как вы написали свое ТЗ на АСУТП? Учли все требования действующего ГОСТ?
Источники
1. ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»
2. ГОСТ Р 59793–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»
3. ГОСТ Р 59792–2021 «Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»
4. ГОСТ 34.201–2020 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Виды, комплектность и обозначение документов»
5. ГОСТ Р 59795–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»
6. ГОСТ Р 59853–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»
Уважаемые коллеги, желаю хорошего дня. Подписывайтесь, чтобы иметь возможность обсудить со мной вашу задачу в комментариях. Буду рад лайку, альтернативному мнению или истории по теме статьи.
ПРЕДУПРЕЖДЕНИЕ №1: Оценки, суждения и предложения по рассматриваемым вопросам являются личным мнением автора.
ПРЕДУПРЕЖДЕНИЕ №2: Техническая информация, представленная на сайте, не является официальной и предоставлена только в целях ознакомления. Владелец сайта не несет никакой ответственности за риски, связанные с использованием информации, полученной из данного источника.
Все изображения, если не указано иное, либо выполнены автором, либо взяты из открытых источников.