книги / Проектирование систем управления технологическими процессами и производствами
..pdfРис. 4.1. Блок-схема алгоритма разработки эскизного проекта новой СУ
Разработка операционных диаграмм производится на основе декомпозиции диаграмм существующей системы в операционные диаграммы новой системы управления. Декомпозиция диаграмм старой системы в диаграммы новой системы проводится с учетом внешних объектов и хранилищ данных и требований заказчика.
При определении границ автоматизации необходимо для каж дого возможного логического варианта решить, какие операции сле дует автоматизировать, а какие должны выполняться в ручном виде, то есть не подлежат автоматизации или их автоматизация лишена здравого смысла. В общем случае автоматизации подлежат:
-операции, в которых другими способами нельзя повысить точность и скорость обработки данных с одновременным снижением требований к квалификации обслуживающего персонала заказчика;
-операции, которые приводят единственным способом к достижению поставленных целей;
-операции, которые используют для обработки большие хра нилища данных и являются монотонными и трудоемкими.
4.1.Организация процесса проектирования автоматизированных систем
Внастоящее время на отечественном рынке преобладают две основные тенденции разработки АС.
Первая тенденция заключается в том, что предприятие пытается постепенно внедрять системы автоматизации на отдельных участках своей деятельности, предполагая в дальнейшем объединить их в единую систему, либо довольствуются частичной (кусочной) авто матизацией. Несмотря на то, что этот путь, на первый взгляд, кажется менее затратным, опыт внедрения таких систем показывает, что минимальные затраты в подобных проектах чаще всего оборачи ваются их минимальной отдачей, а то и вовсе не приносят желаемого результата.
Вторая тенденция - это комплексное внедрение систем авто матизации, позволяющее охватить все звенья системы менеджмента от низового уровня производственных подразделений до верхнего управленческого уровня. В общем случае такая система включает в себя следующие компоненты:
- автоматизацию общехозяйственной деятельности пред приятия (бухгалтерский учет, управление персоналом, сбыт/снабжение и т. д.);
-автоматизацию основных технологических процессов пред приятия;
-автоматизацию собственно управленческих процессов, ана лиза и стратегического планирования.
Необходимо учитывать, что автоматизация управления должна накладываться на хорошо работающую, отлаженную структуру управ ления производством (технологическим процессом). Всеобъемлю щий анализ совокупности конкретных бизнес-процессов предпри ятия, определение и исключение узких мест существующей СУ - вот задачи, решение которых является одним из основных этапов при создании комплексной АС. Разумеется, такая система не может быть создана в одночасье. Поэтому на всех этапах жизненного цикла систе мы (разработки, внедрения, развития и сопровождения) особенно важен выбор исполнителя работ.
Наличие единого исполнителя при создании комплексной СУ означает для заказчика (пользователя) устранение массы традицион ных стыковочных проблем, возникающих при объединении различ ных подсистем в общую инфраструктуру, а совместимость отдельных составных частей системы обеспечивает возможность поэтапного финансирования. В то же время технические решения должны пол ностью соответствовать открытым международным стандартам, что обеспечивает заказчику надежные гарантии эффективности и защиты его капиталовложений.
В автоматизированных системах практически невозможно учесть все разнообразие существующих моделей технологических процес сов. Однако инструментальные средства АСУТП позволяют настро ить систему на специфику технологических процессов любого предприятия.
При конкретной реализации проектов автоматизированных си стем возникает ряд дополнительных организационных и технических проблем. Организационные вопросы решаются, как правило, взаим ным лицензированием, а в случае разработки совместного “ноу-хау”
-выработкой соглашения о правах каждой из сторон при его исполь
зовании.
В реализации любого проекта автоматизированной системы необходимо особое внимание уделять техническим вопросам, к которым, в первую очередь, следует отнести определение объема информационного потока между АСУП и АСУТП.
Мнения на этот счет высказываются самые разные, вплоть до утверждения, что это слабосвязанные системы и поэтому достаточен обмен между ними в виде сводок, передаваемых по телефону или через дискеты. Управление технологическими процессами и уп равление финансово-хозяйственной деятельностью (бизнес-про цессами производства) должны строиться в рамках единой системы на основе единого информационного пространства. Только такая еди ная система позволяет поддерживать интегрированную модель про мышленного предприятия и на основе этой модели строить управ ление в соответствии с главным критерием - рентабельностью про изводства.
Единое информационное пространство подразумевает опера тивный доступ (при наличии, разумеется, соответствующих прав доступа) с любого рабочего места ко всем видам данных, возни кающих и накапливаемых в системе. Информация, порождаемая в любой точке предприятия, тут же становится доступной всем заинте ресованным службам и отделам. Например, сведения по состоянию технологических установок, их загрузке, параметрам и объему исходной и конечной продукции, поступающие непосредственно с контрольно-измерительной аппаратуры, могут быть сразу же обра ботаны как на уровне диспетчера цеха, так и на уровне экономической или производственно-технической службы завода. Приказы и распо ряжения руководства предприятия, решения и выводы специалистов доставляются средствами электронной почты до всех адресатов (с подтверждением приема).
Становится возможной групповая работа специалистов одного или нескольких отделов над общими проектами или документами на их рабочих местах.
Создание единого информационного пространства позволяет поновому поставить вопрос о накоплении и дальнейшем использовании для исследования, диагностики и прогнозирования массивов пер вичных технологических данных. Структура этих данных при ее должной обработке может дать много дополнительной информации
об особенностях работы оборудования и технологических процессах, но она обычно теряется на уровне диспетчерского управления после интегрирования и агрегирования. Наличие вертикальных инфор мационных каналов для данных реального времени между техноло гическими агрегатами и верхними уровнями системы управления дает возможность проведения различных специальных измерений и экспериментов без непосредственного доступа к опасным или трудно доступным объектам, возможность использования современной, быстро развивающейся технологии оперативной аналитической обработки данных - OLAP.
На практике при организации процесса проектирования АС надо иметь ввиду следующее.
1. При проектировании единой базы данных возникают сущест венные трудности, связанные с тем, что системы кодификации объектов на различных уровнях управления, как правило, различны и специалисты разных уровней управления одного и того же предпри ятия часто не могут договориться даже о единой терминологии (в качестве примера можно привести частое смешение таких понятий как “технологическое оборудование” и “технологический объект” или “параметры технологического объекта” и “показатели работы пред приятия”). Для унификации способов доступа к данным в много уровневых организационно-технологических системах приходится основательно перестраивать сложившееся информационное обес печение, менять структуру классификации и кодирования.
2. Структурная сложность технологических процессов, не усту пающая сложности бизнес-процессов, требует адекватных средств для их представления и обработки. Использование для этих целей современных реляционных СУБД наталкивается на такие трудности, как отсутствие стандартных средств прямой записи потока техно логических данных реального времени в БД с помощью SQL-за просов, необходимость написания каждый раз соответствующих процедур, учитывающих особенности формата данных, протокола передачи и т. д. Появление систем SCADA, несмотря на большие первоначальные надежды, не устраняет эти проблемы, так как полноценное ведение БД (хотя бы параметров собственно технологических процессов) в них отсутствует: нет, например, таких стандартных средств, как произвольный запрос, группировка данных,
усреднение, суммирование и т. д. Практика проектирования показы вает, что только эффективная интеграция продуктов типа SCADA и СУБД уровня Oracle или MS SQL Server может дать платформу для создания единой системы управления.
3. Распределенный характер и сетевая структура средств управ ления как технологическими процессами, так и бизнес-процессами приводит к необходимости установки современных информационно вычислительных сетей и систем телекоммуникаций.
Таким образом, организация проектирования систем управления производством является многофункциональной и многокрите риальной задачей. Для ее решения необходимо владение механизмом структурного анализа исследования требуемой предметной области (производства).
Целью проведения структурного анализа является выявление недостатков существующей системы', уточнение необходимых изменений и нововведений, определение характеристик и специ фикации проектируемой автоматизированной системы.
Главной задачей структурного анализа является полное логичес кое описание новой системы управления, определение всех существу ющих операций, подлежащих автоматизации, определение хранимых, входных и выходных данных.
Процесс структурного анализа включает восемь стадий (рис. 4.2):
Рис. 4.2. Структурный анализ предметной области (объекта автоматизации)
1)формирование первоначальных планов;
2)обследование существующей системы;
3)определение требований к новой системе;
4)анализ данных;
5)разработка эскизного проекта;
6)проработка новой системы;
7)составление плана проектирования системы;
8)подготовка спецификации новой системы.
4.2.Формирование первоначальных планов проектирования автоматизированных систем.
Обследование существующей системы, анализ предметной области
Формирование первоначальных планов включает в себя комплекс организационных мероприятий:
-назначается руководитель проекта, определяется план разра
ботки;
-проводится совещание с заказчиком, определяются задачи проектирования и объект анализа;
-устанавливаются деловые, хорошие контакты с пользова телями (заказчиками) проектируемой системы;
-разрабатывается нормативная база, регламентирующая ход проектирования системы.
Обследование существующей системы проводится с целью изу чения прикладной области, подлежащей автоматизации, выявления насущных проблем и получения детальных сведений о существующей системе. Исходными данными для проведения обследования является подготовленный отчет о реализуемости системы. Алгоритм обследо вания существующей системы приведен на рис. 4.3. В общем случае обследование существующей системы включает в себя:
-сбор детальной информации;
-определение операций и подготовку операционных диаграмм;
-документирование операций;
-определение данных;
-выявление недостатков в существующей системе;
-осуществление компоновки документации;
-критический анализ обследования существующей системы.
Рис. 4.3. Блок-схема алгоритма обследования существующей системы
Сбор детальной информации по существующей системе осу ществляется методом опроса пользователей, методом анкетирования и методом изучения документации. Изучается организационно штатная структура, положения о подразделениях, должностные инст рукции, приказы, распоряжения и другие регламентирующие произ водственный процесс организации документы. Сфера обязанностей подразделений и сотрудников описывается при помощи операций, а взаимосвязь между ними - при помощи операционных диаграмм с указанием входных и выходных потоков данных.
Определение операций и подготовка операционных диаграмм яв ляются одними из самых трудоемких задач структурного анализа. Необходимо иметь в виду, что любая система управления должна рассматриваться как сеть взаимосвязанных, взаимодействующих процессов, хранилищ и потоков данных. Разработчикам системы необходимо вникать во все сферы деятельности организации, опре делять все возможные документальные, управленческие, мате риальные, технологические, финансовые и другие потоки данных, что, безусловно, влечет за собой большие временные затраты. Разработчики должны хорошо представлять полное техническое описание существующей системы с целью выявления узких мест, подлежащих в дальнейшем автоматизации. При подготовке операци онных диаграмм (схем) необходимо учитывать возможную декомпо зицию спецификации системы, для чего схемы, детализирующие любой уровень представления системы, должны быть понятны всем (пользователям и разработчикам).
Для описания операционных диаграмм используются следующие методы:
-вербальный метод, то есть словесное описание всех операций
ивсех процессов в системе;
-метод HIPO, применяемый фирмой IBM. В его основе лежат иерархические схемы функций, где каждый блок общей схемы далее детализируется на более подробные диаграммы;
-метод SADT' где процессам обработки данных соответствуют прямоугольные блоки, которые соединяются стрелками, изобра жающими информационные потоки;
-структурный графический метод, отражающий операции, выполняемые в рамках информационной системы, а также потоки,
показывающие взаимодействие между операциями и объектами, находящимися вне автоматизированной системы.
Для описания результатов обследования существующей системы наиболее приспособлен структурный графический метод. Основными его элементами являются операции и потоки.
Операцией называется любое действие, связанное с преобра зованием одного или нескольких входных потоков в один или несколь ко выходных потоков. Любая операция должна однозначно определять конкретное действие. Например: “Сравнение квартальных отчетных показателей затрат” является верной операцией, так как в ней четко (однозначно) определены операция и действие над конкретным потоком входных данных, а “Обработка входных данных” является некорректной операцией, так как не определена конкретная операция обработки и не определены конкретные входные данные.
Поток данных обозначается стрелками, указывающими направле ние от одной операции к другой. Как правило, потоки данных соответ ствуют движению документов, отчетов, распоряжений, материальных средств или некоторой другой информации. Управляющие потоки представляют или внешнее управляющее воздействие на систему, или внутреннее управляющее воздействие одной операции на другую.
Обычно в структурном графическом методе применяют сле дующие графические обозначения:
внешний объект
операция в отношении данных
иматериальных объектов
-операция выбора
- отчеты и выходные документы