Виртуальное проектирование АСУ ТП

Введение

Вы решили создать современную АСУ ТП? Очень хорошо! Подготовленный и вдумчивый читатель журнала «СТА» понимает, что для этого нужно. Создание любой АСУ ТП — это комплекс работ, который предполагает, если, конечно, у вас на руках уже есть техническое задание (ТЗ) от заказчика, выполнение, как минимум, следующих этапов:

• выбор комплекса технических средств и разработка функциональной структуры будущей системы;

• собственно проектирование или разработка конструкторской и проектной документации на систему;

• разработка логики построения программного обеспечения и алгоритмов обработки информации;

• составление заказных спецификаций и оценка стоимости проекта, согласование её с заказчиком;

• приобретение комплектующих, сборка и наладка технических средств системы;

• отладка и тестирование алгоритмов программ (желательно до установки системы на объекте);

• сборка системы на объекте и метрологическая аттестация, «прогонка» системы, корректировка ранее принятых решений и схем после «обкатки» и т.д. в соответствии с действующими стандартами [1, 2, 3].

Перед разработчиком системы сразу возникает множество вопросов: взяться за всю работу самостоятельно или разделить её между субподрядчиками? сколько времени для этого потребуется? можно ли каким-то образом ускорить весь процесс? где взять комплектующие и желательно все сразу? кто будет вести сборку и отладку системы? сколько это будет стоить? и т.д. Поверьте авторам статьи с 30-летним стажем работы в этой области, собственноручно сдавшим не одну систему заказчику, что далеко не всегда на эти повторяющиеся от проекта к проекту вопросы находятся одни и те же решения и ответы. Это связано прежде всего с тем, что полностью повторить один и тот же проект дважды практически невозможно, так как с течением времени изменяются ваши собственные подходы к решению тех или иных задач, изменяются (причём значительно) номенклатура и функциональные возможности самих технических средств, и наконец, изменяются и требования заказчика.

Как бы то ни было, вам в итоге придётся ответить на главные вопросы: цена, качество и сроки реализации проекта. Сегодня заказчик, вкладывая средства в проект, желает получить быструю отдачу, и на реализацию проекта вам, как правило, отводят не больше года. Читатели, работающие в данной области, могут сказать, что это невозможно, и будут правы, если ориентироваться на стадии создания АСУ ТП по стандарту и рассчитывать сроки разработки в соответствии с нормативными трудоёмкостями [4]. Для полной реализации проекта обычно требуется больший срок — 2–3 года! И это справедливо, так как в обычной практике проектировщики АСУ ТП привязывались к конкретным характеристикам конкретных объектов и начинали разработку только после согласования ТЗ. Анализ характеристик конкретных объектов, изучение и последующее согласование своих способов проектирования и требований и особенно убеждение заказчика и состыковка его понимания проблем с выбранными вами решениями «съедают» значительную часть времени, отведённого на реализацию проекта в целом. Такой способ создания АСУ ТП назван авторами решением прямой задачи и предусматривает последовательное выполнение всех необходимых стадий создания системы для конкретного объекта (по ТЗ заказчика) в соответствии с требованиями нормативной документации.

Между тем, для сокращения общего времени создания АСУ ТП можно попробовать решить так называемую обратную задачу и уменьшить общее время реализации любого проекта. Смысл её состоит в том, что проектировщик сознательно абстрагируется от конкретных характеристик объекта управления, для которого разработывается АСУ ТП, и пользуется лишь формализованным описанием структуры и принципов взаимодействия объекта управления и системы управления. Такой подход позволяет наработать и материализовать ряд решений для неких виртуальных объектов по ТЗ, которое вы написали сами себе. Естественно, в нём учитываются почти все возможные требования будущего заказчика и известные требования нормативной документации. Впоследствии созданные вами проектные документы, программные и конструкторские решения для абстрактного объекта управления могут быть адаптированы к конкретным требованиям реального заказчика, что значительно сократит общее время реализации проекта.

Специалисты ФГУП ФНПЦ «Алтай» на протяжении ряда лет успешно применяют такой подход. Возможно, излагаемый далее материал поможет и вам решить собственные проблемы и най-ти свои оригинальные способы разработки.

Немного теории, или как заранее предусмотреть большинство требований заказчиков

Основная идея используемого нами подхода состоит в том, что значительная часть процессов инженерной деятельности или операций, которые реализуются при создании АСУ ТП, может быть формализована по определённым признакам. На рис. 1 представлена формализованная модель взаимодействия структур, входящих в любую АСУ ТП. 

Здесь Н — наблюдатель, Т — технологическая система, U — техническая система, С — входной информационный поток, Е — выходной информационный поток. Наличие в этой структуре блока Н свидетельствует о том, что это именно автоматизированная система, в которой наблюдатель может влиять на информационный поток С и даже корректировать его. Когда вы избавитесь от блока Н, то можете смело утверждать, что построили автоматическую систему управления.

С точки зрения наблюдателя Н система Т просто преобразует входной поток С в выходной поток Е. Однако если учесть тот фактор, что системе Т потребуется некоторое время для преобразования С в Е, то объект управления можно рассматривать как объект, характеризируемый некой функцией времени, преобразующей потоки информации. Тогда для любого j-го единичного сигнала в любой момент времени t должно выполняться соотношение (1): 

где j = 1, 2….m, а T — оператор, реализующий функцию преобразования сигнала с_j(t) в e_j(t).

Физическая природа сигналов, с помощью которых осуществляются автоматизированное управление и наблюдение (контроль) состояния, известна и, в конечном итоге, сводится к сигналам двух видов:

• сигналы, непрерывно меняющиеся во времени (аналоговые);

• сигналы, скачкообразно меняющиеся во времени (дискретные).

Известно, что большинство современных технических средств автоматизации (ТСА) и вычислительные устройства ориентированы в основном на генерацию и обработку сигналов дискретной природы. В этом случае оператор перехода Т реализует функцию, которая известна как Булева. Таким образом, можно формально охарактеризовать некоторый класс виртуальных технологических систем Т и давать им реальные количественные характеристики, например, время преобразования сигналов.

Аналогичным образом можно дать количественные оценки и технической системе U, например по перечню типов сигналов, которыми она оперирует. Перечень всех сигналов, составляющих информационный поток С, назовём системотехнической характеристикой (СТХ) объекта, так как, в конечном итоге, эти сигналы определяют набор системных технических средств, предназначенных для их обработки. Задавать формализованные СТХ для виртуальных объектов можно в виде таблицы (табл. 1).

На основе СТХ можно условно классифицировать различные технические системы. Общую сумму сигналов N1, N2, N3 и N4 назовём информационной мощностью системы, которая определяется выражением (2): 

 

Тогда определённый класс технических систем (тут имеются в виду технические системы, создаваемые только для автоматизированного управления пожароопасными объектами категории П-IIа, взрывоопасными класса В-Iа или экологически опасными объектами) можно условно разделить на несколько различных типов:

I_m ≤ 256 — система малой информационной мощности;

I_m ≤ 512 — система средней информационной мощности;

I_m ≤× 1024 — система большой информационной мощности.

Известны и другие способы классификации систем: по уровням информационной, аппаратной или объектной сложности, по уровням охвата (глубина разработки, возможность тиражирования), по назначению (общие, технологические) и др. [5].

Применяемая здесь классификация, по мнению авторов, наиболее точно отражает сущность подхода, который позволяет только на основе предлагаемых способов описания информационных потоков формализованно характеризовать как существующие, так и виртуальные, ещё не созданные АСУ ТП. Очевидно, что на основании этой условной классификации можно строить структуры, содержащие любое количество систем различной информационной мощности. Такие системы обычно разъединены конструкционно (реализованы в разных шкафах, на разных щитах и т.п.) и/или распределены пространственно (по разным участкам, цехам, объектам и т.д.), но объединены логически по совокупной сумме информационных потоков. В конечном итоге, конфигурация системы будет зависеть от требований заказчика и расположения потенциально опасных объектов на его промышленной площадке. Информационные потоки и их количественные характеристики при таком подходе являются единственной материальной субстанцией, на основе которой вами разрабатывается ТЗ на создание виртуальной АСУ ТП, имеющей вполне конкретные характеристики, и решается обратная задача создания АСУ ТП.

Теперь до реализации предлагаемой идеи остаётся один шаг, так как две составляющие структуры U и Т имеют количественные характеристики, которыми мы можем варьировать и на основе которых мы можем проектировать, программировать, конструировать и тестировать различные АСУ ТП, заказчиком коих сами и являемся. Необходимо ответить лишь на один вопрос: а что делать с аналоговыми сигналами в потоке С?

Из (1) следует, что с точки зрения технического устройства U объект Т функционирует как дискретный цифровой автомат, который характеризируется единственным параметром, а именно временем преобразования потока входных сигналов С в поток выходных сигналов Е. Тогда взаимодействие технической системы U и технологической системы Т можно рассматривать как взаимодействие двух цифровых автоматов при одном обоснованном допущении, что любой поток непрерывных сигналов необходимо рассматривать как последовательность сигналов пуска и останова примитивных непрерывных процессов [6]. Это допущение достаточно справедливо с учётом того фактора, что любое регулирование непрерывной величины (например, температуры в реакторе) можно выполнять с помощью автономного устройства (локального регулятора, контроллера и т.п.). А со стороны U надо генерировать только дискретные сигналы на запуск или остановку такого устройства, которое техническая система рассматривает как некий чёрный ящик, воспринимающий только дискретные сигналы. Это в большей степени справедливо для процессов и операций, обычно реализуемых при управлении потенциально опасными, пожароопасными или взрывоопасными процессами, где до 80% сигналов информационного потока С составляют именно дискретные сигналы. Специфика реализации таких процессов во многом определяет именно такую структуру сигналов информационных потоков. Согласитесь с тем, что таких технологических систем из всех вам известных достаточно много!

Таким образом, на основании собственного ТЗ вы нарабатываете и реально материализуете часть необходимых процедур и процессов создания АСУ ТП в документах, конкретных устройствах, программах, регламентах, методиках, руководствах по эксплуатации и т.п. Опыт показывает, что до 70% от необходимого объёма инженерных процедур можно выполнить до начала конкретной разработки.

Впоследствии, когда вам придёт конкретное задание на разработку АСУ ТП, эти наработки могут быть адаптированы к системе напрямую, без значительных трудозатрат. Вам останется оговорить и согласовать с заказчиком часть дополнительных требований, которые не удалось формализовать, а на это понадобиться очень немного времени, и вы смело на вопрос заказчика: «Сколько времени потребуется?» — можете гарантировать ему внедрение системы через 9–11 месяцев после составления договора на разработку!

Практическая реализация или формализация процедур инженерной деятельности

Возьмите какой-либо существующий комплект проектной документации на АСУ ТП и внимательно его проанализируйте. В любом «хорошем» проекте вы обнаружите, как минимум, следующие документы и схемы: эскизный проект, структурную схему системы управления и контроля, структурную схему комплекса технических средств, структурные схемы комплексов средств автоматизации, функциональные схемы автоматизации, принципиальные схемы автоматизации, принципиальные пневматические схемы, принципиальные электрические схемы питания, схемы питания и управления двигателями, схемы размещения оборудования, конструкторскую документацию на щиты, пульты и планы их расположения, заявочные ведомости материалов и средств автоматизации, пояснительную записку к проекту, сметы на оборудование и монтажные работы [1–4].

Анализ структурных и функциональных схем проекта свидетельствует о том, что они достаточно формализованы и не привязаны к конкретным материальным объектам. Они указывают только на функциональные связи между формальными графическими структурами, каждая из которых представляется в виде какого-либо блока или элемента управления и контроля. Иными словами, если вы их разработаете для своего виртуального объекта, то в полной мере можете затем применить и для реальных объектов.

Очевидно, что и принципиальные схемы автоматизации не привязаны к конкретным объектам — они обычно привязаны к конкретным средствам автоматизации.

Труднее формализовать принципиальные схемы питания, особенно схемы питания двигателей, ввиду того что они всегда конкретные и приходится считаться с такими параметрами, как род тока (постоянный, переменный), напряжение питания (220 В, 380 В или даже 415 В), мощность и тип двигателей, тип пускателей, сечение питающего кабеля и т.д. Тем не менее, при желании вы можете наработать ряд типовых схем подключения различных двигателей с учётом перечисленных особенностей и хранить их в своей электронной базе данных, для того чтобы впоследствии использовать в конкретных разработках. Это вполне реально, так как способы автоматизированного управления двигателями практически идентичны.

Наиболее трудно формализуемой процедурой в выбранном нами подходе была процедура создания таких технических систем U, которые можно относительно легко адаптировать к различным структурам АСУ ТП. Здесь, на наш взгляд, существует достаточно простой выход, о котором упоминалось ранее: необходимо разработать несколько типовых конструкций технических систем U с различной информационной мощностью и полным комплектом проектной и эксплуатационной документации, программного обеспечения, тестовых программ для отладки и настройки таких систем. Имея в наличии такие технические системы, можно, варьируя ими, создать любую, сколь угодно сложную структуру АСУ ТП с полной уверенностью, что эти структурные единицы полностью выполнят возложенные на них функции и вам не придётся заниматься дополнительным их конструированием и отладкой — всё это вы уже сделали заранее.

Используя эту идею, наши специалисты разработали и реализовали в конкретных конструкциях три типовых модуля (М256, М512 и М1024), которые применяются для построения различных систем автоматизации как на собственном производстве, так и при создании систем автоматизации для других заказчиков. Каждый модуль конструктивно представляет собой шкаф, в котором размещены устройства связи с объектом (УСО): модули ввода/вывода, релейные сборки, контроллеры, барьеры искрозащиты (табл. 2). Здесь же находятся источники питания для УСО и вспомогательное оборудование (клеммные соединители, кабельные вводы и пр.).

Несколько неудачных попыток реализации изложенной идеи показали, что для её положительного решения целесообразно применять одну и ту же номенклатуру технических средств автоматизации, что значительно упрощает большинство процедур создания АСУ ТП.

Для типового конструирования шкафа УСО в ФГУП ФНПЦ «Алтай» разработан программный продукт, ориентированный полностью на продукцию известной российской компании ПРОСОФТ. Eё очевидное преимущество перед другими компаниями состоит в том, что она не только поставляет новые технические решения, но и предлагает разработчикам эволюционные методы совершенствования морально устаревших систем автоматизации и полностью обеспечивает даже самого взыскательного разработчика АСУ ТП необходимыми ТСА и программными средствами.

При разработке программного продукта с условным названием ВОХ 2004 учитывалось, что моделирование и исследование конструкций шкафа УСО будет выполняться в трёхмерной графике. Базовая конфигурация шкафа УСО предполагает, что все элементы автоматики будут располагаться на пяти параллельно расположенных шинах (DIN-рейках) со следующим размещением элементов автоматики сверху вниз:

1. модули ввода/вывода, контроллеры;

2. нормирующие преобразователи для искробезопасных цепей;

3. элементы релейной автоматики;

4. источники питания и автоматические выключатели;

5. клеммные соединители.

Основным источником входных данных для программы является только СТХ виртуального (задаваемого вами) объекта управления. При автоматизированном конструировании по заданной СТХ программа самостоятельно выбирает из базы данных ТСА, необходимые для полной конфигурации шкафов УСО. База данных содержит номенклатуру современных технических средств (около 5000 наименований), сертифицированных для применения в системах управления потенциально опасными технологическими объектами. Сегодня в базе данных содержится номенклатура изделий таких известных фирм, как Advantech, RST, WAGO, Siеmens, Rittal, Schroff, Finder, Schneider Electric, Pepperl+Fuchs, ЭлеСи, «Сенсор», Теплоприбор, Belden и др. База данных является открытой и может быть дополнена или полностью заменена пользователем на номенклатуру устройств, которые он намеревается использовать при автоматизированном конфигурировании шкафов УСО. Активный диалоговый режим обеспечивает редактирование и свободное перемещение ТСА внутри конструкции и в случае необходимости может использоваться для корректирования конфигурации шкафов УСО.

Функционально программа состоит из двух рабочих окон.

Первое окно (рис. 2) предназначено для просмотра в трёхмерном изображении создаваемой конструкции и её редактирования (например, для добавления новых устройств). Пользователь имеет возможность работать со следующими параметрами: «боковые отступы от стенок шкафа» (их можно изменять), «установить элементы друг на друга» (имеется в виду — в два слоя, если это предусмотрено конструкцией устройства), «изменить монтажное пространство» (это расстояние по вертикали между модулями, расположенными друг над другом). Сервисные функции программы позволяют в режиме редактирования максимально уплотнять расположение элементов автоматики внутри шкафа без ухудшения эксплуатационных и эргономических характеристик конструкции. При однорамной компоновке все элементы автоматики располагаются на одной фронтальной плоскости шкафа, что значительно увеличивает его габаритные размеры. Авторы чаще применяют двухрамную компоновку, при которой все элементы автоматики располагаются на двух плоскостях DIN-реек, расположенных с внешней и с внутренней стороны шкафа. Для этих целей используется шкаф с двумя открывающимися дверями. Кстати, это позволяет сэкономить средства на реализацию проекта, создаёт определённые удобства при перемещении конструкций на объекте или при отправке их потребителю. В случае необходимости выполняется оптимизация созданной конструкции за счёт допустимого уплотнения элементов по высоте и ширине. Выводится отчёт о результатах работы программы. В нём помимо служебной информации о размерах устройств находится отчёт о геометрических размерах требуемого шкафа с приведением стоимости всех указанных модулей, используемых в проекте, а также линейной и объёмной плотности монтажа.

Второе рабочее окно программы (рис. 3) — это окно базы данных.

В этом окне расположен список всех доступных на текущий момент устройств. Каждому устройству соответствует набор следующих параметров: «имя модуля», «тип», «геометрические размеры», «монтажные допуски», «количество доступных каналов по типу», «мощность», «сила тока», «напряжение», «масса», «цвет модели», «трёхмерная модель», «признак дополнительного монтажа», «признак предпочтения», «поставщик», «производитель», «дополнительные заметки», «цена», «единица измерения стоимости». Назначение большинства параметров понятно без пояснений; следует отметить только то, что наличие такого параметра, как «признак предпочтения», позволяет каждому разработчику создавать свои базы данных, содержащие такие наборы ТСА (не обязательно от одного поставщика), которым отдаёт предпочтение тот или иной проектировщик.

Кроме того, в режиме редактирования обеспечивается вращение конструкции вокруг её центра масс для наиболее полного обзора редактируемого участка. Для перемещения устройств внутри конструкции используется технология drag-and-drop, обеспечивающая захват устройства кнопкой мыши и его свободное перемещение.

На рис. 4 приведена фотография шкафа УСО, конструкция которого выполнена с помощью программы ВОХ 2004.

При постановке задачи на разработку программы нами сознательно были усложнены требования по структуре информационных потоков. Учитывая опыт предыдущих разработок и специфику потенциально опасных объектов, где используются контуры управления, построенные по принципу «искробезопасная электрическая цепь», было решено максимально усложнить СТХ и считать, что в общем информационном потоке сигналов таких контуров может быть до 80%. Это значительно расширило номенклатуру используемых ТСА (за счёт, например, барьеров искрозащиты), потребовало увеличения сервисных возможностей программы и повлияло на определяемые базовые габаритные размеры конструктивов для трёх типов модулей УСО (М256, М512 и М1024). Полученные при помощи программы результаты показали, что модуль М256 может быть собран в шкафу компании Rittal с размерами (Ш×Г×В) 600×800×1000 мм (с двумя открывающимися дверями), а модули М512 и М1024 — в шкафу Rittal с размерами 600×800×1200 мм и 600×800×1500 мм соответственно.

Заключение

Недостатки предлагаемого подхода очевидны ввиду того, что значительно сужена область применения, но при определённых условиях они могут превратиться в достоинства.

Если вы хотите автоматизировать всё и вся, например, сегодня создаёте АСУ ТП для упаковки молочных продуктов, а завтра пытаетесь разработать АСУ ТП для управления домной или прокатным станом, то, скорее всего, ничего хорошего для себя вы в этой статье не обнаружите. Но если вы на протяжении ряда лет потеете над созданием или модернизацией АСУ ТП для промышленных предприятий, где реализуются многофазные технологические процессы в рассредоточенных на площадке зданиях и где применяются потенциально опасные технологии, материал этой статьи будет вам полезен.

Попробуйте реализовать описанный подход для какой-либо несложной АСУ ТП (на 50 или 100 сигналов), и вы увидите, что это возможно. А когда вы набьёте руку, вам будут по силам и более сложные проекты.

Чем больше процедур и процессов инженерной деятельности вам удастся формализовать, тем быстрее и качественнее вы будете создавать АСУ ТП.

С готовыми наработками на руках вы всегда сможете поторговаться с заказчиком и получить лучшие для себя условия договора, зная наперёд, что значительную часть работы вы гарантированно выполните и главное — сделаете это в срок, оговоренный вами.

Используя описанный подход, специалисты ФГУП ФНПЦ «Алтай» на протяжении ряда лет успешно создают и сдают заказчику «под ключ» системы автоматизации различной информационной мощности. При этом весь комплекс работ от ТЗ до сдачи системы выполняется самостоятельно группой специалистов всего из 10–12 человек.

По предлагаемому методу были созданы и внедрены системы автоматизации различного назначения. Так, например, за работы, описанные в [7], коллектив разработчиков ФНПЦ «Алтай» (Петров Е.А., Звольский Л.С. и др.) получил премию Правительства РФ в области науки и техники за 2003 год, а в 2008 году другой коллектив авторов (Звольский Л.С., Масютин Е.А. и др.) получил премию Алтайского края в области науки и техники за работы, описанные в [8]. ●

Литература

1. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. — М. : Издательство стандартов, 1991. – С. 45–52.

2. ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. — М. : Издательство стандартов, 1991. — С. 3–14.

3. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. — М. : Издательство стандартов, 1999. — С. 15–28.

4. Нормы времени на выполнение конструкторских работ по системам автоматизации технологических процессов. — М. : Проектмонтажавтоматика, 1992. — 46 с.

5. Рапопорт Г.Н., Солин Ю.В., Гривцов С.П. Автоматизированные системы управления технологическими процессами. — М. : Машиностроение, 1977. — 246 с.

6. Глушков В.М. Синтез цифровых автоматов. — М. : Физматгиз, 1962. — 476 с.

7. Жарков А.С., Петров Е.А., Звольский Л.С. и др. Автоматизированный технологический комплекс производства высокопредохранительных ВВ // Вопросы специального машиностроения. — 2000. — № 5–6. — С. 441-442.

8. Жарков А.С., Потапов М.Г., Звольский Л.С. и др. Современная автоматизированная система управления взрывоопасным технологическим процессом // Современные технологии автоматизации. — 2001. — № 1. — С. 40–46. 

E-mail: zls52@mail.ru