локальная сеть внутри контроллера

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

Кому адресована эта статья? В первую очередь, конечно, специалистам в области АСУ ТП, как умудренным практическим опытом, так и студентам, видящим АСУ ТП как свою будущую профессию. Однако и другим специалистам есть смысл ознакомиться с материалом. Во-первых, он содержит базовые сведения об автоматизации крупных предприятий. Если вы, новичок без опыта в этой области, задумаете «сунуться» в отдел автоматизации ТЭЦ – знайте, что вам «грозит» ;) Традиционным же сетевикам просто будет любопытно посмотреть на давно знакомые вещи (пакетная передача данных, множественный доступ к сети) с иной точки зрения, в непривычном им контексте ;)

введение

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

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

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

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

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

наименование уровня	усредненное кол-во каналов
уровень подсистем	2000
уровень функциональных узлов	65
уровень технологического оборудования	3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Большинство параллельных шин являются одномастерными (однопроцессорными). Многомастерные (многопроцессорные) шины существенно сложней и более дорогостоящи. Если для решения задач, потребуется многопроцессорная обработка, то необходимо использовать относительно дорогие многопроцессорные шины типа VME или аналогичные.
2. Многопроцессорные параллельные шины имеют централизованную схему арбитража. Арбитр - это отдельное самостоятельное устройство, которое управляет доступом процессоров к шине. Выход из строя единственного элемента - арбитра, приведет выходу из строя всего контроллера.
3. Шинные циклы на параллельной магистрали являются элементарными операциями чтения/записи операндов с точно заданными адресами. Шинные циклы не обладают свойством транзакции, т.е. невозможно корректно "откатиться" в состояние до выполнения неудачного цикла и попытаться повторить его вновь. Из этого следует сразу несколько проблем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• микропроцессор должен поддерживать широко распространенные операционные системы реального времени;
• иметь встроенные средства для предотвращения зацикливания программ (watch-dog), развитая системная диагностика;
• развитые средства отладки и тестирования;
• поддержка инструментальных средств разработки;
• наличие интерфейса Ethernet;
• достаточно высокая производительность - не менее нескольких MIPs;
• оптимальное соотношение стоимость/функциональность.

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

Сердюков Олег Викторович - заведующий Инженерным Центром ИЦ-6 Института автоматики и электрометрии СО РАН; ; директор "Торнадо Модульные Системы".