Очевидно, что конструкция "WITH CODE = А*. В* AND TYPE = AI" соответствует операции выбора, "PRINT CODE, DESCRIPTION, VALUE, UNITS" ~ это проекция, a "ORDERED BY CODE" - сортировка. Для неопытных пользователей необходимо отметить, что сортировка может потребовать достаточно много времени в зависимости от количества сортируемых записей, качества программного обеспечения и производительности ЭВМ. Большие запросы к базе данных не рекомендуется делать в спешке.

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

Для эффективного использования программ доступа к базе данных необходимо заранее выбрать подмножество интересующих данных. Бессмысленно выводить список состояния всех объектов системы, если заранее известно, где сосредоточена интересующая информация. Обычно для каждой конкретной ситуации интерес может представлять лишь очень ограниченное число выборок из базы данных, поэтому заранее можно определить небольшой набор стандартных запросов. Такие запросы называются протоколами (не путать с протоколами как наборами правил и процедур для обмена информацией, описанными в главах 8 и 9; могут быть и другие названия). Протоколы - это обычно запросы, в которых предопределены операции проекции и сортировки (какую информацию вывести и в каком порядке), а перед их запуском требуется указать только конкретные параметры (рис. 12.5). Отметим, что поля вывода и порядок сортировки при запуске запроса явно не указываются.

STATE PROTOCOL SELECTION = К.,

BEGIN ON 01-APR-01 10:30:05

DI DI DI DI DI DI DI DI DI AI AI AI AI

K010 KOI 2 KOI 4 KOI 6 K023 K024 K025 K098 K099 T439 T442 T444 T445

STATE PROTOCOL

PRIMARY CIRCUIT PUMP = ON

PRIMARY CIRCUIT PUMP = NORMAL

SECONDARY CIRCUIT PUMP = ON

SECUNDARY CIRCUIT PUMP = NORMAL

SAFETY SWITCH 1 = OFF

SAFETY SWITCH 2 = OFF

SAFETY SWITCH 3 = OFF

FIRE SENSOR = OK

PLANT VENTILATION = OK

PRIMARY CIRCUIT TEMP.IN = 78.8 (75)

PRIMARY CIRCUIT TEMP.OUT = 59.4 (60)

SECUNDARY CIRCUIT TEMP.IN = 38.8 (45)

SECUNDARY CIRCUIT TEMP.OUT = 54.0 (60) END ON 01-APR-01 10:30:12

Протоколы аварийной сигнализации

Важнейшей функцией системы управления является быстрое выявление недопустимых режимов и оповещение об этом оператора. Каждое изменение состояния, классифицированное как аварийное, должно быть зафиксировано в специальном файле - журнале аварий - с указанием времени события.

Специальный запрос - аварийный протокол - используется для поиска и вывода всех объектов базы данных, которые находятся в данный момент времени в аварийном состоянии. Этот протокол чрезвычайно важен для обслуживания и ремонта.

Протоколы обслуживания

Еще одной важной составляющей работы производственного предприятия является техническое обслуживание приборов и оборудования. Примеры обслуживания - замена изношенных инструментов, калибровка датчиков, контроль уровней горючего и смазки. Операции по обслуживанию могут быть еще сложнее, вплоть до разборки целых агрегатов для проверки состояния и очистки их узлов. Этот тип обслуживания называется предупредительным ремонтом (preventive maintenance) и выполняется для поддержания оборудования в оптимальном рабочем состоянии. Ремонт дефектных или вышедших из строя устройств называется восстановительным ремонтом (corrective maintenance).

В зависимости от типа устройства предупредительный ремонт выполняется либо в соответствии с определенным расписанием, например каждые тридцать дней, или после определенного времени работы, например, инструмент должен быть заменен после 200 рабочих часов. На больших производствах требуется обслуживать сотни или даже тысячи устройств. Вести вручную график обслуживания - сложная и неблагодарная задача.

Очевидным решением является подготовка графиков планового обслуживания на каждый день или другой период исходя из информации, хранящейся в базе данных процесса. Ремонт у.зла, вышедшего из строя, конечно, нельзя предвидеть заранее, но информацию по незапланированным мероприятиям можно фиксировать в базе данных, чтобы впоследствии избавиться от избыточных операций. Если какой-либо агрегат был отремонтирован после поломки в понедельник, то вряд ли есть необходимость в выполнении планового годового технического осмотра в среду. Пример графика предупредительного обслуживания приведен на рис. 12.6.

MAINTENANCE PLAN FOR: THU 05-APR-01 BEGIN ON 01-APR-01 09:05:12

K022 MAI 2 LAOS C037 C038 P101 P102

DRILL VERIFY TOOLS (200 HRS). ACCTD =228.4 HRS DIESEL GEN. VERIFY OIL LEVEL (50 HRS).ACCTD = 47.2 HRS LATHE MAIN REVISION (1500 HRS). ACCTD = 1502.0 HRS COMPRESSOR 01 XCHG AIR FILTER (1 MTH). LATEST = 2B-FEB-01 COMPRESSOR 02 XCHG AIR FILTER (1 MTH). LATEST = 28-FEB-01 WATER PUMP MAIN INLET, CHECK (100 HRS). ACCTD = 98.2 HRS WATER PUMP MAIN INLET, CHECK (100 HRS). ACCTD = 102.7 HRS

MAINTENANCE PLAN END ON 01-APR-oi 09:05:18

Рис. 12.5. Пример протокола состояния процесса

Рис. 12.6. Пример графика обслуживания

Анализ данных и тренды

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

12.4.8. Операции управления, выполняемые с использованием базы данных

В некоторых системах управления в базе данных хранятся указания на автоматические действия, которые выполняются в определенных ситуациях. Специальная таблица базы данных указывает, при каком значении некоторого параметра вызывается исполнительная команда. Эта таблица работает подобно ПЛК, хотя данные, которые она использует, находятся на более высоком уровне абстракции и могут включать производные величины. Поля в таблице имеют формат

when (variable = value) -> action.

[когда (переменная = значение) -> выполнить действие]

Частным случаем события является наступление некоторого момента времени (абсолютного) или истечение заданного интервала. Таблица действий имеет вид

when time(preclefined) -> action

[когда время (заданное) -> выполнить действие]

Таким образом, например, можно включить освещение и подать питание к станкам перед началом рабочего дня. В базе данных можно использовать дополнительные параметры для более точной интерпретации. Например, список праздничных дней, которые будут восприниматься как воскресенье, чтобы не включать отопление предприятия и не запускать автоматически оборудование в 6:30 в понедельник 8 марта.

В базу данных можно включить описание параметров цифровых регуляторов. Наиболее типичный вид цифровых регуляторов - это дискретные ПИД-регуляторов, для которых операции интегрирования и дифференцирования аппроксимируются численными методами. В системах прямого цифрового управления регуляторы встроены в базу данных. Программное обеспечение ПЦУ реализовано в виде одного модуля, который исполняется для каждого контура управления на основе параметров, хранящихся в базе данных. Примеры таких структур данных и программа для ПИД-регулятора были приведены в главе 6.

Существует важное практическое различие в автоматизированных функциях и управлении процессом с использованием базы данных и системами на основе ПЛ К или местных регуляторов. Последние установлены непосредственно возле входов и выходов процесса и могут быстро реагировать на изменения во входных данных. База данных иерархической системы управления, напротив, имеет большое время реакции, поскольку информация должна проследовать по коммуникационным кана-

лам вверх и вниз и пройти через несколько этапов обработки. Поэтому целесообразно программировать автоматические реакции на уровне центральной ЭВМ только в том случае, когда нужно сравнить несколько параметров и эту операцию нельзя выполнить локально. Связанные контуры управления нельзя реализовать в виде системы распределенного прямого цифрового управления. В этом случае нужно принимать во внимание вероятность значительной перегрузки каналов связи.

12.4.9. Расширенные языки для управления процессами

Долгое время программное обеспечение для систем управления писалось почти исключительно на ассемблере. Две главные причины этого - необходимость максимально эффективно использовать все ограниченные ресурсы ЭВМ и отсутствие соответствующих языков для программирования систем реального времени.

Современные языки программирования для систем управления можно разделить на два основных типа - процедурные и описательные. Процедурные языки (procedure language) - к этому типу относится большинство обычных языков программирования - требуют, чтобы была явно указана каждая команда, которую ЦП должен выполнить. Описательные языки (descriptive language) требуют только определения данных, отношений и параметров, которые будут храниться в разных базах данных. Отношения вход/выход описываются в табличной форме, а внутренние детали исполнения программы определяются компилятором или интерпретатором. Пример описательного языка - это база данных, рассмотренная выше в этом разделе; другой пример - это языки последовательностного программирования для ПЛК (раздел 7.4). Использовать описательные языки в общем случае проще, чем процедурные. С другой стороны, они являются менее гибкими, но это можно компенсировать применением небольших программ, разработанных для специальных задач с помощью процедурных языков.

Для программирования и эксплуатации системы управления на основе описательного языка не требуется детальных знаний ВТ. Гораздо важнее хорошее понимание управляемого процесса и представление о том, что управляющая система может, а что нет. Успех конкретной реализации во многом зависит от качества модели физического процесса и определения входных/выходных параметров. Описательное программирование требует также правильной настройки рабочих параметров для того, чтобы система управления как можно лучше соответствовала управляемому процессу. В этом может помочь распределение приоритетов между задачами. Не имеет смысла пытаться собрать сотни данных в секунду для ЭВМ с ограниченными возможностями, задавая для каждой переменной очень малый интервал выборки. Такая система в конце концов будет работать в режиме "карусели" (раздел 10.2.5), а почти вся информация будет собираться напрасно. Именно производительность ЭВМ устанавливает практическую величину интервала выборки.

12.5. Внедрение проектов и управление качеством 12.5.1. Организация работы над проектом

Система УпР-;"",!ГиГл"д™:° программного обеспечения, ет процессоры, сети, термин датчики, исполнительные механизмы и,

авключа-массу дру-

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

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

К сожалению, нет "оптимальных" решений; они существуют только как математические идеи, которые можно использовать лишь в специальных случаях для конкретных задач. Внешние факторы - многие из них носят весьма неочевидный, эзотерический характер: от климата до доступности запасных частей и возможности повышения квалификации обслуживающего персонала - тем не менее влияют на успех всего комплексного решения. Необходимо учитывать все, во избежание сбоев в работе и непредвиденных затрат на завершающей стадии проекта.

Среди нетехнических факторов, непосредственно определяющих успех автоматизации, следует назвать общую организацию работы, которая должна быть тем лучше, чем более масштабным является проект. Обычно работы по проекту подразделяются на планирование (planning), разработку (implementation), документирование (documentation), испытания (testing) и эксплуатацию (operation). Каждая стадия важна для успеха разработки в целом.

Фаза планирования включает общий анализ проблемы. В завершение планирования выпускается документ, называемый техническим заданием проекта (ТЗ, project specification). Обычно ему предшествует предпроектное обследование - анализ наличия и способов решения проблемы и предварительная оценка стоимости возможных вариантов, - которое завершается выпуском технико-экономического обоснования (ТЭО, feasibility study) предлагаемого решения. Отчет о предпроектном обследовании ТЭО обычно не столь детализирован, как техническое задание: он предназначен для руководства компании, а техническое задание - в основном для внешних поставщиков и разработчиков.

Окончательные контракты должны точно определять, что из себя представляет система. Если они основаны на слишком общих определениях типа "мониторинг , "управление процессом" и тому подобных, то обязательно возникнут неудовлетворенность и конфликты. Общие идеи должны быть сформулированы как можно рань ше и как можно яснее. Вместо "мониторинг процесса" должно быть указано, какие именно величины должны обрабатываться, в какой именно форме они должны быть представлены, должны ли данные отображаться в "исходном" виде или с помощью определенных графических интерфейсов и т. д.

За рабочие спецификации в первую очередь отвечает покупатель системы управления, и лишь во вторую - поставщик. Чтобы избежать конфликтов, лучше заранее определить соответствующие сферы ответственности. Полезно, если ответственное лицо или группа, представляющие заказчика, следят за выполнением проекта. Поставщик предлагает общую информацию о системах управления, а заказчик должен проверить, что все его запросы и требования выполняются.

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

- выполнение цели;

- надежность;

- безопасность (система в непредвиденных обстоятельствах не должна вести себя угрожающим образом);

- ремонтопригодность (практически все системы нуждаются в периодическом вмешательстве человека для проверки, калибровки, пополнения расходных материалов и т. д.; эти операции должны быть предусмотрены);

- экономичность (более в смысле реальной отдачи вложений, чем в стремлении потратить как можно меньше).

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

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

Теоретически фазы планирования, проектирования, внедрения и испытаний должны быть разделены, но в действительности между ними существуют взаимосвязь и взаимное влияние. Во время проектирования могут появиться новые факты, которые потребуют изменений в планировании. Практические, заранее не известные, ограничения на этапе реального внедрения могут также повлиять на выполнение проекта. После приобретения опыта практической работы системы может возникнуть необходимость снова внести изменения в элементы, которые считались завершенными. К сожалению, чем позже вносятся изменения в описания и спецификации, тем труднее и дороже это обходится, но с другой стороны, любая сложная система постоянно находится в состоянии модификации. Окончательного варианта системы как такового не существует, а есть только разные степени функциональности.

Разработчик и инженер, проводящие испытания, имеют противоположные цели. Первый должен создать устойчивую и эффективную систему. Второй должен придумать всевозможные тесты, чтобы выявить как можно больше ошибок. Оба должны следовать руководящим документам, хотя и в них могут быть внесены изменения, диктуемые практикой и здравым смыслом.

12.5.2. Управление качеством как часть проектирования системы

В последние годы существенно возросло внимание к управлению качеством промышленной PZreeTent причины этого - международная конкуренция, высокие требования потреь™ оптимального использования

истощающихся матер>-« ввГне™ Р-УР-в- Таким образом, управле-пие качеством превра шую составляющую технических процессов