Реферат: Контроллеры для автоматизации крупных промышленных объектов

Контроллеры для автоматизации крупных промышленных объектов

Выбор адекватной решаемым задачам архитектуры системы автоматизации является актуальной проблемой. Ошибочные решения, принятые на этом этапе проектирования систем автоматизации, могут стать причиной провала всего проекта. Актуальность этой проблемы существенно возрастает, когда речь идет об автоматизации крупных промышленных объектов, например энергоблоков ТЭС.

Требования к системам автоматизации крупных неоднородных объектов

Многоуровневость функционально-технологической структуры объекта

Известно, что для решения крупной и сложной задачи, часто ее разбивают на совокупность более мелких и простых задач. Сложный объект автоматизации представляется совокупностью технологических подсистем, которые, в свою очередь, состоят из более мелких технологических функциональных узлов, а те из совокупности агрегатов и т.д. Определение количества уровней и их границ является несколько условным. Тем ни менее, можно сослаться на сложившуюся практику классификации объектов с точки зрения технологии и опыт разделения реальных объектов на технологические уровни [1]. Выделяют пять основных технологических уровней:

I. уровень предприятия (например, ТЭС);

II. уровень технологического объекта (энергоблоки ТЭС);

III. уровень технологических подсистем (котел, турбина, генератор и т.д.);

IV. уровень технологических функциональных узлов (пылесистемы, пароперегреватели и т.д.)

V. уровень технологического оборудования внутри функционального узла (задвижки, механизмы, датчики и т.д.)

Нас интересует деление технологического объекта, внутри которого выделено три основных уровня. Например, на пылеугольном энергоблоке 200 МВт выделяют всего несколько технологических подсистем, около 100 функциональных узлов (далее ФУ) и несколько тысяч датчиков и исполнительных механизмов. Количество каналов на таком объекте составляет порядка шести тысяч. В таблице 1 показано усредненное число каналов в элементе для каждого из уровней на примере конкретной системы управления энергоблоком 200 МВт [2].

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

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

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

Повышенные требования по надежности

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

Основные принципы, продиктованные самой задачей автоматизации крупных объектов, из которых целесообразно исходить при проектировании архитектуры системы следующие [3]:

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

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

Также существуют общие принципы, вытекающие из методов повышения надежности любых систем [4]:

1. система должна состоять из минимального числа образующих ее элементов;

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

3. автономность иерархических уровней в системе;

4. минимальные размеры и простота прикладных программ - увеличение размеров программ ведет к экспоненциальному росту числа ошибок и сложности проверки правильности ее функционирования/

Быстрое восстановление функций

Для крупных объектов автоматизации предъявляются жесткие требования по времени восстановления функции. Вышедшая из строя функция должна быть восстановлена без влияния на остальную функционирующую часть системы, т.е. восстановление должно осуществляться в режиме "горячей" замены за минимальное время. Для крупных объектов типа ТЭС по нормативным документам это время составляет в среднем не более 30 минут [3].

Повышенные требования к устойчивости функционирования

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

Архитектура контроллера, адекватного объекту автоматизации

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

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

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

Анализ архитектур контроллеров с параллельной шиной

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

Охарактеризуем основные свойства большинства классических контроллеров:

1. классический контроллер образуется набором модулей, установленных в каркас (крейт) и объединенных традиционной параллельной шиной;

2. контроллер имеет один (очень редко несколько) модуль центрального процессора, взаимодействующего с остальными модулями контроллера через параллельную шину;

3. остальные модули выполняют в контроллере функции устройств сопряжения с объектом (УСО) или другие вспомогательные функции;

4. все модули, кроме процессорного, не являются интеллектуальными;

5. взаимодействие между модулями осуществляется на уровне циклов обращений микропроцессора к внутренним регистрам и ячейкам памяти модулей;

6. взаимодействие по параллельной шине характеризуется высокими скоростями передачи;

7. относительно высокое число каналов в контроллере.

Адекватность функционально-технологической структуре объекта. Из опыта проектирования реальных объектов и анализа различных проектов, объем ФУ составляет в среднем порядка 50 каналов [2]. С этой точки зрения использование традиционных контроллеров вполне возможно. Модульность позволяет скомпоновать контроллеры с необходимым объемом каналов и процессорной производительностью, развитые сетевые средства без труда позволяют объединить их в единую систему и т.д., но при практической реализации возникают некоторые проблемы:

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

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

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

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

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

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

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

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

Взаимовлияние программ может привести к чрезвычайно высокой трудоемкости технологической наладки объекта.

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

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

Недостатки классической параллельной шины

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

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

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

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

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

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

3. ряд ограничений в адресации на параллельных шинах - отсутствуют широковещательные сообщения.

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

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

Контроллер с последовательной шиной

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

Локальная сеть внутри контроллера вместо параллельной шины

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

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

На "цеховом" уровне, где представлено несколько контроллеров, стоит задача их объединения в единую систему. Это означает, что сеть интеллектуальных модулей должна быть двухуровневой и включать сеть первого ранга, образующую контроллеры ФУ из интеллектуальных модулей и сеть второго ранга, объединяющую контроллеры (кластеры) в единую систему (рис 1).

Кластер модулей, объединенных сетью первого ранга, можно назвать контроллером функциональных узлов (далее КФУ).

Важной особенностью этой архитектуры является то, что сетевой шлюз в КФУ является абсолютно прозрачным для модулей. Таким образом, система выглядит для модулей как одноранговая сеть, т.е. для любого отправителя (модуля) не имеет значения, где физически находится получатель сообщения - в том же КФУ, или в другом. Это еще одно неоспоримое достоинство предлагаемой архитектуры.

Рис. 1. Сеть интеллектуальных модулей

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

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

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

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

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

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

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

В-шестых, скорости передачи. Параллельные шины пока считаются самыми быстродействующими. Сегодня появилось несколько технологий последовательной передачи данных, которые превосходят по быстродействию любые существующие параллельные шины и обеспечивают передачу данных со скоростью до 400 Мбайт/сек и даже более [4]. Тот факт, что последовательные шины заменят в ближайшем будущем сегодняшние параллельные шины межмодульного взаимодействия в компьютерных системах, был осознан еще в начале 90-х годов. Сегодня видна определенная тенденция развития средств вычислительной техники в этом направлении [4].

В контроллерах для автоматизации типичных технологических процессов такие скорости не требуются - шина с производительностью в 2 Мбайта/сек вполне достаточна для традиционного контроллера с неинтеллектуальными модулями. Эта оценка скорости основана на нашем практическом опыте и опыте использования рядом фирм технических средств с такими показателями производительности шины, например PC-совместимые контроллеры с 8-ми разрядной ISA-bus. Если же все модули в контроллере будут иметь достаточный интеллект для автономного решения прикладных задач управления, сбора и обработки информации, то требуемый поток обмена данными между такими модулями снизится примерно на два порядка. Анализ исходных текстов программ "драйверов" ввода/вывода позволяет оценить количество элементарных операций, выполняемых процессором, для считывания и первичной обработки, например, одного аналогового преобразования. Как правило, для обработки одного измерения, в "драйвере" исполняется около сотни процессорных инструкций. Таким образом для межмодульной коммуникации будет достаточно иметь среду передачи с производительность порядка 20 Кбайт/сек или что тоже самое 200 Кбод с учетом 20% накладных расходов протоколов последовательной передачи данных. Эта оценка говорит о том, что с точки зрения скоростных характеристик в качестве среды передачи внутри контроллера может использоваться практически любая из стандартных детерминированных локальных сетей.

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

Результаты разработки и реализации контроллера с последовательной шиной

В Институте автоматики и электрометрии СО РАН при участии партнеров, компаний PEP Modular Computers и UniControls, был разработан универсальный контроллер для автоматизации различных объектов, включая крупные и особо ответственные объекты типа ТЭС и аналогичные. Общие требования к разрабатываемому оборудованию были сформулированы одной из ведущих в Сибирском регионе технологических организаций "Сибтехэнерго". Реализация контроллера, опытно-конструкторская документация и серийное производство осуществлены фирмой "Торнадо Модульные Системы". Разработанное оборудование внедрено на ряде объектов тепло-энергетики.

Архитектура разрабатываемого контроллера базировалась на идее распределения технологических функций объекта по небольшим автономным или слабосвязанным технологическим узлам. Задачи каждого функционального узла решаются одним или несколькими интеллектуальными модулями, получивших название модулей интеллектуальных функций "Modules of Intellectual Functions" или MIF-модулями, а контроллеры на их основе - MIF-контроллерами. Объем отдельного MIF-модуля соответствует объему небольшого ФУ - т.е. 30-60 каналов.

Ключевые задачи и этапы разработки

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

При разработке контроллера помимо ключевых задач, описанных выше, обращалось внимание на ряд инженерных решений, таких как:

1. конструктивное исполнение;

2. способы подключения "полевых" кабелей;

3. удобство и простота обслуживания контроллера;

4. гибкость компоновки;

5. сочетание с другими техническими средствами в рамках одного контроллера;

6. программная совместимость и поддержка стандартного программного обеспечения - операционных систем реального времени, систем технологического программирования в соответствии с международным стандартом IEC1131-3, поддержка сетевых протоколов;

7. дублирование модулей;

8. "горячая" замена модулей без отключения питания контроллера;

9. авто-конфигурирование модулей при замене;

10. обеспечение отказоустойчивости контроллера.

Первым этапом разработки явился анализ существующих технических средств, в том числе специализированных Программно Технических Комплексов (ПТК) для ТЭС. Он показал, что многие фирмы предлагают системы на базе традиционных контроллеров, но существуют и другие ПТК, которые в полной мере учитывают ключевые требования со стороны объекта автоматизации. Примерами таких систем могут служить хорошо известные системы "TELEPERM-ME" фирмы Siemens, "PROCONTROL-P" фирмы ABB и некоторые другие.

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

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

Далее была разработана конкретная архитектура и структурная схема контроллера с описанием основных свойств на основе выбранных технических решений. После чего были разработаны необходимые модули.

Серийное производство модулей размещено на предприятиях, обеспечивающих высокое качество производства электронных устройств.

Технические решения, использованные в MIF-контроллере

Внутренняя последовательная шина MIF-контроллера

По причинам, подробно описанным выше, в качестве средств коммуникации между модулями контроллера было решено использовать последовательную шину, а точнее сказать сеть, так как она должна обеспечивать:

1. множественный доступ к среде передачи;

2. контроль ошибок при передаче;

3. стандартный электрический интерфейс к среде передачи;

4. автоматическую конфигурацию логической топологии среды передачи;

5. гарантированное время доставки сообщений;

6. соответствие какому либо из распространенных стандартов.

Внутренняя шина MIF-контроллера выбиралась из так называемых "полевых" шин (сетей). При выборе анализировались следующие стандартные сети из числа наиболее распространенных "полевых" сетей: Profibus, CAN-bus и другие.

CAN-bus проектировался для обеспечения взаимодействия тесно связанных по управлению контроллеров. CAN-bus идеально подходит для задач управления агрегатного уровня, хотя и имеет ряд ограничений: по скорости передачи (до 1Мбод), что может оказаться недостаточным для цехового уровня; по топологии сети, по протяженности (до 40 м при максимальной скорости передачи), по передаче крупных массивов информации [6].

Profibus сегодня - стандарт номер один в автоматизации цехового уровня: имеет высокие скорости до 12Мбод; разнообразные варианты топологий, допускающей комбинации различных технологий, как на медном кабеле, так и на оптоволоконном; большую протяженность сегментов. Для задач управления на уровне агрегата, механизма и т.п. он является несколько громоздким и избыточным. Он прекрасно подходит в качестве сети более высокого "цехового" уровня для объединения контроллеров.

В качестве внутренней шины контроллера была выбрана шина CAN-bus. С нашей точки зрения для внутренних коммуникаций контроллера она подходит наилучшим образом [5].

Сеть CAN-bus является одним из наиболее зрелых стандартов. Он реализован в виде специализированных СБИС более чем 20 ведущими компаниями, поддерживает разнообразные среды передачи, контролирует целостность и отсутствие ошибок при передаче/приеме сообщения без получения специального ответа от "получателя". Жесткая детерминированность протокола, динамическое распределение приоритетов, многомастерность, поддержка совместной обработки управляемой событиями, смысловая адресация сообщений и событий вместо традиционной физической адресации получателя/отправителя сетевых пакетов, все это делает его подходящим средством межмодульной коммуникации в контроллере [5].

Итак, взаимодействие MIF-модулей внутри MIF-контроллера осуществляется по дублированной шине CAN-bus. Конструктивно сеть CAN-bus выполнена в MIF-контроллере на объединительной печатной плате, в которую устанавливаются MIF-модули. Дублирование шины повышает надежность MIF-контроллера до уровня, который никогда не достижим в традиционных контроллерах - MIF-контроллер не может отказать ни при каком любом единичном отказе среды передачи контроллера.

Решения по организации ввода/вывода

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

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

Для удовлетворения всех перечисленных требований была выбрана "мезонинная" технология организации ввода/вывода, которая основана на выделении целевых функций ввода/вывода в отдельные субмодули (мезонины), устанавливаемые на модуль-носитель.

Нами была выбрана "мезонинная" технология ModPack, разработанная в 80-х годах компанией PEP Modular Computers [7]. Эта технология получила широкое распространение в мире и является сегодня открытым международным стандартом. Сегодня в мире выпускается различными независимыми производителями около ста типов субмодулей в стандарте ModPack. Это означает, что на рынке средств автоматизации можно найти функциональный субмодуль для решения практически любой задачи.

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

Сопряжение с "полевым" уровнем

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

Остальная часть задач сопряжения, таких как подключение "полевых" кабельных связей сечением до 2,5 мм2, согласование с конкретными измерительными схемами (2, 3, 4-х проводные, переход из термокомпенсационного кабеля в медный, и т.д.), дополнительные преобразования (24В в 220В и наоборот) и т.п., решается в Блоках Полевых Интерфейсов (БПИ).

БПИ могут устанавливаться в шкафу как отдельно, так и вместе с крейтом контроллера. БПИ монтируются на стандартную DIN-рейку. В верхней части БПИ размещаются клеммы для подключения "полевых" кабелей, а в нижней - разъем для подключения плоского 24 жильного кабеля к MIF-модулям с установленными на них субмодулями ModPack.

Рис. 2. Типовой пример компоновки шкафа КФУ

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

Выбор элементной базы MIF-модуля

При выборе элементной базы для MIF-модуля мы руководствовались следующим:

1. микропроцессор должен поддерживать широко распространенные операционные системы реального времени;

2. иметь встроенные средства для предотвращения зацикливания программ (watch-dog), развитая системная диагностика;

3. развитые средства отладки и тестирования;

4. поддержка инструментальных средств разработки;

5. наличие интерфейса Ethernet;

6. достаточно высокая производительность - не менее нескольких MIPs;

7. оптимальное соотношение стоимость/функциональность.

При выборе микропроцессора, ввиду незначительной разницы в стоимости между 32-х разрядными и 8-ми разрядными микроконтроллерами в сравнение со стоимостью модуля, мы сразу исключили из рассмотрения 8-ми и 16-ти разрядные микроконтроллеры.

Безусловным лидером на рынке 32-х разрядных микроконтроллеров для встраиваемых систем, сегодня является компания Motorola с ее известными микроконтроллерами серий MC68300 на базе ядра CPU32, совместимого с 68000, и новыми микроконтроллерами MPC500, 800, 600 и другие на базе нового RISC-ядра PowerPC.

Мы остановили свой выбор на микроконтроллере MC68EN360 по следующим причинам:

1. наличие полного спектра хорошо отлаженного проверенного системного ПО реального времени и инструментальных средств разработки для микропроцессоров совместимых с 68000;

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

3. развитые средства отладки, не доступные в других микроконтроллерах - встроенный в микроконтроллер аппаратный отладчик BDM;

4. встроенный специализированный коммуникационный со-процессор QUIC с поддержкой ряда стандартных сетевых протоколов, включая Ethernet;

5. высокая производительность до 10 MIPS;

6. невысокая стоимость.

Рис. 3. Вид спереди крейта MIF-контроллера

Рис. 4. Логическая структура MIF-контроллера

Краткое описание MIF-контроллера

MIF-контроллер состоит из двух основных подсистем - кластера MIF-модулей и сетевых шлюзов (одного или двух, в зависимости от требований по дублированию "цеховой" сети). MIF-модули объединяется в кластер внутри MIF-контроллера детерминированной локальной сетью CAN-bus. MIF-контроллер может состоять из двух крейтов, содержащих до 32 MIF-модулей. Для обеспечения взаимодействия MIF-модулей с другими контроллерами, MIF-контроллер имеет один или два сетевых шлюза в "цеховую" сеть, реализуемую на Profibus или Ethernet.

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

Основная часть сообщений не выходит за пределы MIF-контроллера, что дает фактически пропорциональный числу установленных в системе MIF-контроллеров рост производительности коммуникационной среды.

На рис 3 и 4 показана структура КФУ на примере однокрейтового MIF-контроллера с "цеховой" сетью Profibus.

Заключение

Сформулированы требования к системам управления крупными технологическими объектами учитывающие технологическую структуру объекта, особенности правил его эксплуатации и ввода в действие.

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

Литература

1. Информационная технология: Рекомендации Р50-34.119-90. Архитектура локальных вычислительных сетей в системах промышленной автоматизации. М.: Госстандарт, 1991.

2. ЗАО "МСТ", Материалы Технического Проекта АСУ ТП 6-го энергоблока 200 МВт Новосибирской ТЭЦ-5, 1998.

3. Информационная технология: Руководящие документы РД 34.35.127-93. Общие технические требования к программно-техническим комплексам для АСУ ТП тепловых электростанций. РАО ЕЭС России, Департамент науки и техники, 1995.

4. Ray S.Alderman, VITA. Future vision // Open Bus Systems'93. P. 15

5. Robert Bosch GmbH, CAN specification Ver 2.0, 1995

6. С.А. Третьяков, CAN на пороге нового столетия // Мир компьютерной автоматизации, №2'99

7. VITA, CXC-MPI draft specification rev.3.10 // VITA 14-199x, September 1997