asup-shp-8-14
.docxВ объектно-ориентированном программировании используют три основных принципа: инкапсуляция, наследование, полиморфизм.
Инкапсуляция — выделение класса с доступом к нему через свойства или методы.
Наследование — трансформация класса путем изменения свойств и методов с помощью методов, называемых конструктором и деструктором.
Полиморфизм позволяет использовать метод с одним именем как в базовом, так и в производных классах. Дело в том, что количество классов значительно: уже сейчас оно приближается к ста и продолжает расти. Если для производных классов применять для однотипных, «похожих» методов (например, начертание квадрата и окружности) разные имена, пользователю, особенно начинающему, будет сложно освоиться с таким разнообразием имен.
Таким образом, чтобы воспользоваться объектно-ориентированным подходом в построении собственно БД, необходимо:
1) провести инкапсуляцию данных, т. е. выделить классы и объекты;
2) определить возможные виды структуры реализуемых таблиц:
3) создать наследование классов данных;
4) обеспечить полиморфизм.
Объектно-реляционная модель (ОРБД), появление которой вызвано двумя причинами:
— сложностью построения новой модели данных «с листа». Удобнее это делать на основе имеющихся проверенных разработок;
— преемственностью с широко используемыми реляционными моделями, которые нельзя мгновенно заменить на объектно-ориентированные БД.
Различают две разновидности ОРБД — гибридные и расширенные.
В гибридных ОРБД интерфейс пользователя и алгоритм приложения выполнены с учетом объектно-ориентированного подхода, тогда как собственно БД является реляционной.
В расширенных (постреляционных) ОРБД предполагается объектно-ориентированное построение собственно базы данных путем использования известных и введения новых типов данных, связанных между собой.
К достоинствам ОРБД следует отнести:
— устранение ряда недостатков реляционных БД;
— повторное использование компонентов;
— использование накопленных знаний по реляционным БД.
К недостаткам ОРБД можно отнести:
— усложнение структуры БД и частичную утрату простой обозримости результатов, как в реляционных БД;
— сложность построения абстрактных типов данных и методов, связывающих типы в иерархию;
— менее широкий набор типов связей, определяемых языком программирования SQL, чем в объектно-ориентированных БД;
— менее продуманный, отлаженный и стандартизованный набор типов данных, чем в ООБД.
10-2. Основные механизмы обработки информации в SCADA-системах: протоколирование и обработка особых состояний.
Характерной особенностью SCADA-систем является встроенный механизм обработки особых состояний (Тревоги и События) с обеспечением их отображения, записи и печати:
• тревоги – предупреждения о ненормальном ходе технологического процесса, как правило, требующие немедленной реакции оператора. Типичным примером тревоги является превышение какой-либо переменной (например, температурой) заранее заданного предела (уставки), неожиданное отключение механизма, пропадание давления рабочей жидкости и т.п. Сообщения об этих тревогах передаются оператору, который должен подтвердить факт получения данного сообщения («квитировать» сообщение).
• события – информация об изменениях в статусе технологического процесса (например, возврат параметра из аварийного состояния в нормальное) или о действиях обслуживающего персонала (например, регистрация оператора) и не предполагают немедленной реакции оператора.
На основании тревог и событий формируется аварийная сигнализация (alarm) – это оповещение оператора о наступлении определенного состояния, связанного с нарушением или угрозой нарушения регламентного течения технологического процесса.
Аварийные сигнализации настраиваются путем задания предельных значений (границ, thresholds) индивидуально для каждой процессной переменной. Система автоматически отслеживает изменение процессной переменной и сопоставляет ее значение с заранее настроенными границами. В случае выхода переменной за нормальные границы система генерирует оповещение и фиксирует его в журнале аварийных сигнализаций.
Важность (или критичность) аварийной сигнализации определяется приоритетом (целое число). Как правило, чем выше приоритет у аварийной сигнализации, тем критичнее она для производства, и тем быстрее на нее надо обратить внимание.
Совершенно очевидно, что различные тревоги имеют различную степень опасности – превышение давления в котле может вызвать взрыв, в то время как превышение уровня воды может вызвать только протечку. Поэтому каждой конкретной тревоге присваивается приоритет, определяющий ее опасность. Далее по этому приоритету можно фильтровать тревоги, например, при появлении наиболее опасных – включать сирену, а по менее опасным – только менять цвет соответствующего объекта или выдавать текстовое сообщение. Другим способом фильтрации тревог может быть вывод их на различные табло (на различные рабочие места).
Аварийные сигнализации и оповещения регистрируются сразу после их появления в специальном архиве – журнале аварийных сигнализаций (alarm journal, alarm list).
10-3. ERP-системы: управление запасами (независимые системы).
В ходе управления производством сталкиваются две тенденции. Первая заключается в том, что запасы материальных ресурсов различного вида необходимы. Вторая заключается в том, что они нежелательны. Каждая из них порождена определенными причинами и находит отражение в методах управления запасами. Подходы к управлению во многом зависят от вида материального ресурса. В роли такого ресурса могут выступать: конечная продукция, незавершенное производство, материалы и полуфабрикаты.
Существует ряд причин, по которым целесообразно стремиться к снижению уровня запасов. С ростом запасов увеличиваются следующие затраты и потери: прямые и косвенные затраты, связанные с хранением; затраты на управление запасами; потери, связанные со снижением отдачи от вложения в материальные ресурсы; затраты, которые рассматриваются как скрытое падение мощностей, поскольку часть мощностей используется на производство запасов, а не готовой продукции; потери, связанные со снижением качества при хранении.
В основу систем управления запасами в ERP-системах положен ряд моделей и методов, которые пользователи могут применять по собственному выбору.
Спрос на материальные ресурсы может быть независимым и зависимым. Независимым называется спрос, который не зависит от спроса на другие материальные ресурсы, проходящие через запасы. В частности, независимым всегда является спрос на конечную продукцию, поскольку он определяется исходя из прогноза и/или заказов потребителей. Зависимым называется спрос, который зависит от спроса на другие материальные ресурсы, проходящие через запасы. Зависимым является спрос на изделия, являющиеся компонентами готовой продукции. В то же время независимым является спрос на те же самые изделия, если они становятся конечной продукцией, например запасными частями. В данном подразделе обсуждаются подходы к управлению запасами в условиях независимого спроса. Описание систем с зависимым спросом содержится в следующем разделе.
Основной задачей управления запасами является определение оптимального размера заказа на материальные ресурсы при пополнении запасов.
Рис. 2.4 иллюстрирует решение задачи об оптимальном объеме заказа на качественном уровне. С ростом объема одного заказа увеличиваются затраты на хранение и снижаются затраты на приобретение и обработку заказов. Суммарные затраты на складирование могут иметь точку минимума, соответствующую оптимальному объему заказа (EOQ — Economic order quantity).
11
11-1. Информационное обеспечение АСУ на основе распределенных баз данных.
Распределенные базы данных (РБД) находят все более широкое применение в связи с массовым распространением «сетевых» технологий.
Теория создания, использования и функционирования РБД имеет свои особенности по сравнению с централизованными БД.
Базы данных явились в значительной мере следствием развития АСУ. Первоначально АСУ строились по централизованному принципу: данные из источников передавались в центральный вычислительный центр с суперЭВМ и там обрабатывались. В силу этого базы данных первоначально назывались банками данных.
К концу 1980-х годов возникли новые условия работы для БД: большие объемы информации возникли во многих местах; источником большого количества данных мог быть и центр, но к этим данным требовался быстрый доступ с периферии (географически распределенное производство, работающее по одному графику). К тому же данные могли запрашиваться и центром, и удаленными потребителями. Появилось большое количество данных, которые должны использоваться в срочных запросах.
К достоинствам РБД относятся:
— соответствие структуры РБД структуре организаций;
— гибкое взаимодействие локальных БД;
— широкие возможности централизации узлов;
— непосредственный доступ к информации, снижение стоимости передач (за счет уплотнения и концентрации данных);
— высокие системные характеристики (малое время отклика за счет распараллеливания процессов, высокая надежность);
— модульная реализация взаимодействия, расширения аппаратных средств, возможность использования объектно-ориентированного подхода в программировании;
— возможность распределения файлов в соответствии с их активностью;
— независимые разработки локальных БД через стандартный интерфейс.
Вместе с тем РБД обладают более сложной структурой, что вызывает появление дополнительных проблем (избыточность, несогласованность данных по времени, согласование процессов обновления и запросов, использования телекоммуникационных ресурсов, учет работы дополнительно подсоединенных локальных БД, стандартизация общего интерфейса, усложнение защиты данных) согласования работы элементов.
Распределенная база данных (РБД) — система логически интегрированных и территориально распределенных БД, языковых, программных, технических и организационных средств, предназначенных для создания, ведения и обработки информации. Это означает, что информация физически хранится на разных компьютерах, связанных сетью передачи данных. Любой узел (участок) может выполнять приложение и участвовать в работе по крайней мере одного приложения.
Большинство требований, предъявляемых к РБД, аналогично требованиям к централизованным БД, но их реализация имеет свою, рассмотренную ниже, специфику. В частности, в РБД иногда полезна избыточность.
Дополнительными специфическими требованиями являются:
— доступ должен быть коллективным к любой области РБД с соответствующей защитой информации;
— подсхемы должны быть определены в месте сосредоточения алгоритмов (приложений, процессов) пользователя;
— степень централизации должна быть разумной;
— необходимы сбор и обработка информации об эффективности функционирования РБД.
11-2. Архитектура системы архивирования в SCADA-системах.
Для работы с базами данных истории в большинстве систем управления используются СУБД MS SQL Server или MySQL (Oracle).
Наиболее часто применяются следующие схемы архивирования:
1. Каждая операторская станция накапливает на своем жестком диске собственный архив (или определенную часть архива) независимо от работы других станций. При этом станция имеет доступ как к своему архиву, так и к архиву, хранящемуся на соседней станции. Как правило, на каждой операторской станции устанавливается СУБД на базе SQL для ведения журнала аварийных сигнализаций и журнала действий оператора. Во многих системах архив процессных переменных также записывается в локальную базу данных и обслуживается движком на базе SQL. При такой схеме архивы, хранящиеся на разных станциях, не синхронизируются и поэтому могут значительно отличаться друг от друга. Такая организация архивирования больше характерна для систем с одиночными операторскими станциями.
2. При клиент-серверной архитектуре операторского уровня история накапливается и хранится на общем сервере. В случае использования резервированной пары серверов система обеспечивает идентичность хранящихся на них экземпляров архива, проводя их периодическую синхронизацию. Операторские станции получают по запросу архивные данные от общего сервера (или серверов). Работа с архивами организуется с помощью СУБД на базе SQL.
3. Для долговременного хранения истории часто выделяют отдельный центральный сервер архива (central archive server, CAS). Как правило, это мощная серверная платформа с дисками большой емкости или даже RAID-массивом. Главное предназначение CAS – это сбор и хранение технологической истории в течение нескольких лет.
CAS берет исторические данные с общего сервера, обеспечивает их хранения и поставляет их операторским станциям (как, впрочем, и любому другому обратившемуся к ним клиенту). Такая схема архивирования позволяет освободить общий сервер и операторские станции от такой ресурсоемкой задачи как сбор истории. В некоторых системах сервер CAS резервируется.
Система архивирования должна отвечать следующим требованиям:
1. Большая глубина (продолжительность) архива. Выражается в способности непрерывного архивирования технологических переменных в течение нескольких лет. Архив накапливается в виде последовательно создаваемых частей определенного размера. Когда суммарный размер всех частей достигает угрожающего размера, система автоматически пересылает самые старые части на Backup-сервер или осуществляет их запись на съемный накопитель, тем самым высвобождая место под новые.
2. Производительность (скорость архивирования) и максимальное количество архивируемых переменных. Это достигается путем модификации стандартной СУБД (например, надстройки над SQL-сервером), что позволяет добиться более высокой скорости работы с базой данных, чем в обычных офисных приложениях. Например, продукт Wonderware Industrial SQL Server версии 9.0 позволяет записывать до 2000 аналоговых переменных в секунду и поддерживает в сумме до 60000 переменных, а система SIMATIC PCS7 Central Archive Server – до 120000 переменных.
3. Поддержка открытых коммуникационных протоколов. Доступ к архиву со стороны клиентов должен быть возможен с использованием стандартных, всем известных протоколов (например, OPC) или с использованием SQL-запросов. Это требование связано с тем, что архивом пользуются не только операторские станции, входящие непосредственно в состав SCADA-систем, но и сторонние пользователи такие как: удаленные клиенты, серверы приложений MES-систем (рабочая станция начальника цеха) и т. д.
11-3. ERP-системы. Планирование потребности в ресурсах.
Системы планирования потребностей в ресурсах определяют количество и время всех производственных ресурсов, необходимых, чтобы произвести конечную продукцию, заданную в графике выпуска продукции. Производственные ресурсы включают материалы и полуфабрикаты, покупные изделия, изделия собственного производства, персонал, финансы и производственные мощности.
На рис. 2.5 показаны основные элементы систем планирования потребностей в ресурсах. Здесь выясняется, можно ли получить необходимые материальные ресурсы от поставщиков и достаточны ли производственные мощности, чтобы обеспечить выполнение графика выпуска продукции. Если экономически обоснованные возможности недостаточны, то график должен быть изменен. После того как определено, что график выпуска продукции допустим, планы потребностей в материальных ресурсах и мощностях становятся ядром краткосрочного плана производства. Исходя из плана потребностей в материальных ресурсах службы снабжения формируют план поставок всех приобретаемых материальных ресурсов, а службы управления производством составляют оперативные производственные планы.
Ниже описываются два основных элемента систем планирования потребностей в ресурсах — планирование материальных потребностей (MRP) и планирование потребностей в мощностях (CRP).
Планирование материальных потребностей базируется на том, что они определяются как зависимые. Спрос на ресурсы определяется как сумма потребностей по всем видам продукции, которые должны быть произведены.
Подсистема MRP выполняет следующие функции:
— воспринимает информацию MPS (графика выпуска продукции - Master Production Scheduling);
— рассчитывает на основе MPS потребности в материалах, полуфабрикатах, DCE по интервалам планового горизонта;
— уменьшает эти потребности для тех материальных ресурсов, которые есть в запасах;
— строит график заказов на приобретение и производство в планируемом периоде.
MRP обеспечивает управленцев информацией, которая позволяет выдерживать сроки поставки продукции заказчикам и обеспечивает своевременность выполнения внутренних заказов в ходе производственного процесса.
Подсистема CRP выбирает информацию о заказах, порожденную в планах MRP, и приписывает заказы к рабочим местам в соответствии с маршрутными технологиями. В маршрутных технологиях задана последовательность производственных процессов для каждого заказа. Затем информация о партиях материальных ресурсов преобразуется в данные о нагрузке на мощности на основе норм затрат труда и времени работы оборудования. Затем составляются графики нагрузки по всем заказам для каждого рабочего места. Если мощность достаточна по всем рабочим местам во всех временных периодах, то график MPS утверждается. Если нет, то должно быть выяснено, нельзя ли изменить мощности каким-либо рациональным способом — за счет сверхурочных, установки дополнительного оборудования или передачей заказов на сторону по субконтракту. Если таких возможностей нет, то необходимо пересмотреть маршруты с целью снижения нагрузки на «узкие места» или пересмотреть график выпуска с точки зрения изменения в первую очередь сроков запуска и, если возможно, сроков выпуска.
12
12-1. Концепция MRP, MRP-2
На предприятиях со сложным многономенклатурным производством, была основной задачей является расчет материальных потребностей на производственную программу.
Ранние системы, решавшие эту задачу, получили название MRP (Material Requirements Planning — «Планирование материальных потребностей»). Постепенно был совершен переход от автоматизации управления производством на уровне локальных задач к интегрированным системам, охватывающим выполнение всех функций управления производством. Итогом этого процесса явились системы, получившие название MRP-2 (Manufacturing Resource Planning — «Планирование производственных ресурсов»).
Бизнес-планирование. Процесс формирования плана предприятия наиболее высокого уровня. Планирование долгосрочное, план составляется в стоимостном выражении. Наименее формализованный процесс выработки решений.
Планирование продаж и деятельности предприятия в целом. Бизнес-план преобразуется в планы продаж основных видов продукции (как правило, от 5 до 10). При этом производственные мощности могут не учитываться или учитываться укрупненно. План носит среднесрочный характер.
Планирование производства. План продаж по видам продукции (семейства однородной продукции) преобразуется в объемный или объемно-календарный план производства видов продукции. В этом плане впервые в качестве планово-учетных единиц выступают изделия, но представления о них носят усредненный характер. Например, речь может идти обо всех легковых переднеприводных автомобилях, выпускаемых на заводе, без уточнения моделей. Часто этот модуль объединяется с предыдущим.
Формирование графика выпуска продукции. План производства преобразуется в график выпуска продукции. Как правило, это среднесрочный объемно-календарный план, задающий количества конкретных изделий (или партий) со сроками их изготовления.
Планирование потребностей в материальных ресурсах. В ходе планирования на этом уровне определяются, в количественном выражении и по срокам, потребности в материальных ресурсах, необходимых для обеспечения графика выпуска продукции.
Планирование производственных мощностей. Как правило, в этом модуле выполняются расчеты по определению и сравнению располагаемых и потребных производственных мощностей. С небольшими изменениями этот модуль может применяться не только для производственных мощностей, но и для других видов производственных ресурсов, способных повлиять на пропускную способность предприятия. Подобные расчеты, как правило, производятся после формирования планов практически всех предыдущих уровней с целью повышения надежности системы планирования. Иногда решение данной задачи включают в модуль соответствующего уровня.
Оперативное управление производством. Здесь формируются оперативные планы-графики. В качестве планово-учетных единиц могут выступать детали (партии), сборочные единицы глубокого уровня, детале-(партие) операции и т. п. Период, охватываемый планированием, невелик (от нескольких дней до месяца).
12-2. Инструментальное обеспечение АСУ.
Один из основных факторов успешного развития и внедрения автоматизированного управления — рациональное использование инструментальной базы, включающей технические, программные и телекоммуникационные средства. Определяющим моментом является унификация и стандартизация всех компонентов, в том числе и инструментальной базы. Проведенный анализ всех составляющих инструментальной базы автоматизированного управления показывает сложившиеся тенденции их развития, позволяет ориентироваться на сложившемся рынке вычислительных и сетевых видов продукции.
Основу технического обеспечения автоматизированных систем составляют компьютеры, являющиеся ядром любой информационной системы.
Базовым аппаратным средством уровня непосредственного цифрового управления является автономное программируемое устройство сбора и обработки информации — промышленный контроллер.
В отличие от персонального компьютера он рассчитан на решение ограниченного круга задач и должен обладать следующими основными свойствами:
1) работа в режиме реального времени, т.е. обеспечение высокой реактивности на запросы обслуживания со стороны объекта управления;
2) повышенные требования к надежности функционирования;
3) автоматический перезапуск в случае «зависания» программы;
4) конструкция, приспособленная для работы в цеховых («полевых») условиях (повышенные вибрации, электромагнитные помехи, запыленность, перепады температуры, иногда взрывоопасность);
5) возможность встраивания дополнительных блоков управляющей, регистрирующей, сопрягающей аппаратуры, что помимо специальных конструкторских решений обеспечивается использованием стандартных шин и увеличением числа плат расширения;
6) минимальное потребление энергии и рассеяние тепла в условиях ограниченной мощности источника питания и отсутствия элементов принудительной вентиляции и охлаждения.
Основные требования к программному обеспечению для PLC:
— автономность;
— поддержка процессов сбора, анализа информации и управления, а также локальных баз данных в реальном времени;
— возможность дистанционного управления со стороны центрального диспетчерского пункта (станции);
— сетевая поддержка.
Программное обеспечение распределенной системы (компьютер-PLC) включает следующие основные компоненты:
— тестовое программное обеспечение;
— базовое программное обеспечение;
— прикладное технологическое программное обеспечение.
Телекоммуникационные средства АСУ. Информационный обмен между различными уровнями АСУ осуществляются посредством локальных вычислительных сетей. Сети охватывают относительно небольшие территории (до 5-10 км) внутри отдельных предприятий и объединяют с помощью общего канала связи сотни абонентских узлов (сетевой абонентский узел — это компьютер, PLC, панель визуализации и т. д.). Они могут подключаться к другим локальным сетям, а также региональным и глобальным сетям.
Локальные вычислительные сети, обеспечивающие физическую и логическую связь между распределенными промышленными контроллерами, измерительными преобразователями и исполнительными механизмами и их интеграцию в единую систему управления технологическим процессом, называются локальными промышленными сетями (ЛПС) (Fieldbus — «полевая» шина).
Основными требованиями к сетям, эксплуатирующимся в промышленных условиях, являются:
— высокая надежность;
— высокая скорость передачи данных (что отличает их, например, от глобальных сетей, которые могут вносить в передачу данных значительные задержки);
— простота монтажа.
12-3. ERP-системы. Оперативное управление производством.
Практически во всех базовых ERP-системах можно встретить две обособленные подсистемы для оперативного управления производством. Первая предназначена для мелкосерийного и индивидуального производства, организованного по технологическому принципу, а вторая — крупносерийного и массового — производства, организованного по предметному принципу.
В ходе оперативного управления выполняются следующие действия:
1. Каждому заказу приписывается приоритет, который определяет относительную важность заказа. Это позволяет задать очередность обработки заказов в участках.
2. Выдаются диспетчерские списки (dispatching list) для каждого участка. В диспетчерских списках задается следующая информация: перечень заказов, приоритеты, сроки выпуска заказа из участка. Иногда диспетчерские списки формируются только для отстающих позиций.