Количество каналов сопряжения измерялось тысячами, длина кабельных трасс достигала тысяч метров.

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

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

Всё это ведёт к постепенной смене подходов как разработчиков, так и потребителей, отражаясь в заметных тенденциях рынка решений для АСУТП.

Подходы, лежащие в основе новых инструментальных, технических и программных средств ИНЭУМ – обобщение опыта комплексного обеспечения надёжности и эффективности решения конечной задачи при жёстких ограничениях интегральных затрат. Кратко эти подходы [1, 3, 4, 5] можно определить так:

На этапе проектирования реализация этих подходов основана на соответствующем структуре задачи [множественном] применении коммуникационных каналов и процессоров, позволяющих обеспечить независимость и надёжность контуров управления за счёт предоставления им отдельных ресурсов, сформировать надёжную среду передачи и преобразования информации каждого контура, сократить ненадёжные и дорогие элементы (кабельные трассы, клеммники), объёмы документации и работ, а также обеспечить глубокую диагностическую прозрачность системы.

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

Микроконтроллеры позволяют создать ПЛК произвольной конфигурации для полной реализации целого контура управления минимальным числом элементов, приближая надёжность реализации к надёжности “одного чипа”. Минимальные потребление и габариты сокращают ограничения по размещению, что позволяет приблизить управление к объекту, исключая передачу ответственной и интенсивной (по объёму или темпу) информации на расстояние. Наибольшие возможности обеспечивают миниатюрные и микропотребляющие исполнения, встраиваемые в оборудование, размещаемые непосредственно во взрывоопасных зонах без взрывозащитной оболочки, обеспечивающие непрерывность функционирования при минимальных требованиях к внешнему питанию.

Однако, на фоне значительного роста надёжности и снижения стоимости разработки и производства аппаратной части таких ПЛК, а также вполне достаточных ресурсов для надёжности внутреннего программного обеспечения (ПО), надёжность конечного результата долгое время была сопряжена с проблемой человеческого фактора, острота которой определялась высокой концентрацией ответственности на одном (не самом надёжном) элементе “системы” – программисте.

Дело в том, что получившие широкое распространение CASE-системы, удовлетворяющие принципам (МЭК 1131-3) открытых технологий программирования автоматики (позволяющие ограничить участие программиста созданием “заготовок” и инструментов), подобные ISaGraf, отрабатывались длительное время на одном архитектурном решении – магистрально-модульной архитектуре с единственным [и поэтому] мощным центральным процессором. Естественно, что это повлияло на подход CASE-систем к организации ПО процессоров и установило высокие требования к их ресурсам памяти и вычислительной мощности, “отрезав” широкую номенклатуру недорогих 8-и и 16-и разрядных микроконтроллеров, достаточных для реализации выделенного контура управления.

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

Одной из первых CASE-систем нового типа стала созданная ИНЭУМ в конце 90-х инструментальная система Gx2000 [2], получившая с первыми модельными рядами контроллеров СМ9107 [2, 3, 5] определённое распространение на объектах Магнитогорского металлургического и Михайловского горно-обогатительного комбинатов. Однако Gx2000 создавался в основном усилиями “чистых” программистов со свойственным им приоритетом средств перед целью, что сократило время жизни продукта. Тем не менее, был накоплен ценный практический опыт.

КИПовский подход к автоматизации воплотился в CASE-системе CONField [1,3,4]. “Боевое крещение” первых версий базового состава (ядра) CONField и третьего модельного ряда контроллеров СМ9107 [4] прошло в ноябре 2003 года в суровых условиях Приобского нефтяного месторождения между Сургутом и Нефтеюганском на установках дозирования химреагента Лениногорского опытного завода ”Нефтеавтоматика”. В 2005 году CONField получил первые версии собственного графического редактора.

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

Конструирование решений автоматизации без программистов, ориентация на опыт и видение технологий автоматизации специалистов КИПиА

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

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

Очевидно, полный учёт всей специфики условий решаемой задачи достижим только в последовательных приближениях (тем более при изменении условий со временем) и доступентольколокальному персоналу, отвечающему за автоматизацию объекта, или выполняющей его роль инжиниринговой компании. Основным звеном служб автоматизации отечественных предприятий были и продолжают оставаться службы КИПиА. В их ведении – основные функции автоматики: контура защиты и регулирования объекта. Свойственное им понимание условий задач этого уровня – основа жизнеспособности любого проекта автоматизации.

CASE-система CONField следует стандартам открытых технологий программирования автоматики (МЭК 1131-3) и обеспечивает возможность массового применения без привлечения программистов-профессионалов. При этом инструмент выражено ориентирован на опыт и видение технологий автоматизации специалистов КИПиА. CONField позволяет конструировать комфортную автоматизированную среду для выполнения комплекса работ по автоматизации, не требуя от КИПовцев знаний, выходящих за рамки их повседневной деятельности, но и не ограничивая возможностей проявления свойственной этим людям находчивости.

Разработка прикладного ПО в CONField основана на графическом конструировании контуров управления на языке функциональных блок-схем (рис. 1). Такая возможность соответствует спецификациям языка FBD МЭК 1131-3.

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

Рис. 1 Функциональная блок-схема в графической среде CONField

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

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

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

Образцом понимания всех перечисленных условий мы считаем систему программирования контроллеров Ремиконт, созданную ещё в начале 80-х (стандарт МЭК 1131-3 был утверждён только в 1992-м году).Конечно, в то время ещё были невозможны (и не нужны) такие обобщения, как платформонезависимость и CASE-технологии (система программирования была частью контроллера). Тем не менее, мы считаем CONField продолжением и развитием КИПовского подхода Ремиконта.

Обширная библиотека алгоблоков CONField и её открытость (возможность неограниченного расширения) ориентированы на полное использование указанных достоинств языка блок-схем. В настоящее время библиотека насчитывает более 300 элементов аналоговой, дискретной и комбинированной обработки сигналов (таких как счётчики, детекторы (уровня, длительности, изменения, порядка), динамические звенья (интеграторы, дифференциаторы, фильтры и др.), логические операции (OR, AND, XOR) для логических сигналов и их массивов, логические функции (шифраторы, дешифраторы, таблицы истинности, сдвига и др.), элементы памяти (триггеры, защёлки), мультиплексоры и демультиплексоры, арифметические операции (в том числе с астрономическим временем), алгебраические функции (sin, cos, log, sqrt, линейные, кусочно-линейные, полиномиальные преобразования и др.), блоки времени (таймеры, задержки, хронометры, мультивибраторы, одновибраторы) и др.), знакомых КИПовцам по опыту применения различных платформ и технологий автоматизации.

Обеспечение надёжности прикладного ПО на этапе проектирования

Свобода выбора методов тестирования и отладки на этапе проектирования

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

Для тестирования работы алгоритма и его отладки, а также в целях автоматизации этого этапа, наряду с традиционными базовыми средствами среды разработки (прогон в реальном времени, пошаговый, поалгоблочной, с использованием точек останова) CONField предоставляет неограниченные возможности построения единой среды визуализации, архивации, эмуляции, моделирования и анализа в произвольной конфигурации на модульной основе с привлечением аппаратных ПЛК, эмулируемых в программной среде PC ПЛК, программных модулей CONField и широкодоступного ПО.

Надёжность организации прикладного ПО

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

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

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

Иерархическое проектирование со “свёрткой”

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

Выполняемые транслятором CONField преобразование блок-схемы в таблицу с исполняющим автоматом и последующая их компиляция в объектный модуль обеспечивают альтернативный способ создания новых алгоблоков. Такая операция называется “свёрткой”. Для пользователя и самого CONField алгоблоки, имеющие различное происхождение, неотличимы. CONField, выполняя cвёртку блок-схемы, “стирает историю” происхождения алгоблока, обеспечивая равную защиту и надёжность простого и синтезированного пользователем алгоблоков.

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

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

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

Распределённое иерархическое проектирование

Наряду со средствами изоляции ПО контуров на стадии проектирования CONField предоставляет два механизма усиления изоляции ПО на стадии исполнения, обеспечиваемые выбором способа исполнения. Наиболее мощный механизм изоляции на стадии исполнения – раздельная реализация независимых контуров в отдельных ПЛК, то есть, распределённая реализация общего проекта автоматизации (рис. 2).

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

Рис. 2 Единичный контур управления (слева)

Для распределения иерархического проекта внутренняя реализация алгоблока-свёртки размещается в одном контроллере, а сам алгоблок-свёртка входит в проект другого контроллера, обеспечивая связь со своей “удалённой” реализацией.

С точки зрения возможностей CONField не существует ограничений на общее количество уровней иерархии проекта и количество уровней вычислительной среды (на базе сетей ПЛК). Также не существует ограничений на количество алгоблоков любого уровня иерархии.

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

Локализация ответственности

Изолированная реализация контура управления подсистемы объекта позволяет “локализовать ответственность” – ограничить область распространения требований надёжной реализации набором элементов, принадлежащих контуру безраздельно. Локализация ответственности упрощаетеё обеспечение.

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

Поэтому построение систем автоматизации на базе интеллектуализации подсистем объекта становится нормой проектирования при решении задач с приоритетом надёжности.

Надёжность аппаратно-программной среды и контроль расхода ресурсов

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

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

Разработанное в ИНЭУМ семейство промышленных контроллеров СМ9107 обеспечивает возможность построения надёжной среды сигнального ввода-вывода, коммуникационной и вычислительной в произвольной конфигурации и с низким порогом применимости аппаратных компонентов по техническим и экономическим характеристикам. В основе полученного результата – принципы применения и построения аппаратных и программных средств ПЛК семейства СМ9107, именуемые в совокупности технологией “СМ9107”.

Суть технологии “СМ9107” состоит в следующем.

Свобода выбора решений

Технология “СМ9107”, резко сокращая требования к вычислительным ресурсам ПЛК, обеспечивает широту выбора процессорных и микроконтроллерных платформ, что в совокупности с ограничением функциональной нагрузки ПЛК обеспечивает радикальное уменьшение стоимости, габаритов и потребления ПЛК, расширяет свободу выбора решений. Именно на такую свободу выбора ориентирована CASE-система CONField.

CONField является открытой системой с точки зрения поддерживаемых процессорных и микроконтроллерных платформ и вариантов аппаратной конфигурации ПЛК. В настоящее время поддерживаются:

Таким образом, CONField-у доступны не только мощные контроллеры, но также недорогие универсальные и специализированные контроллеры, встраиваемая в оборудование спецавтоматика, интеллектуальные датчики и исполнительные механизмы, для разработки ПО которых (из-за неприменимости распространённых CASE-систем) ранее требовалось привлечение профессиональных программистов.

Применение технологии “СМ9107” и CASE-системы CONField позволяет создать как отдельный ПЛК, так и аппаратно-программную среду высокой надёжности, произвольной архитектуры и с заданным распределением ресурсов в широком диапазоне вариантов.

Сведение решения новых задач к компоновке на базе надёжных апробированных решений

Находящиеся в состоянии непрерывного развития вариантов конструкций, конфигураций и размерных групп модельные ряды ПЛК СМ9107 (рис. 3) используют апробированные подходы своей базовой технологии “СМ9107” как фундамент.

Рис. 3 Вариант конструкции, конфигурации и размерности ПЛК СМ9107

То есть, технология “СМ9107” – общая фундаментальная основа всего разнообразия контроллеров СМ9107. На этой общности основаны высокий уровень взаимозаменяемости и совместимости различных поколений и модельных рядов СМ9107. В свою очередь, приоритет надёжности, заложенный в фундамент, и толерантность фундамента к вариантам исполнения гарантирует высокий уровень надёжности новых разработок в семействе ПЛК СМ9107.

Контроллеры СМ9107 объединены также общностью и частных апробированных решений (компоновочных, схемотехнических и эксплуатационных), которые можно считать традициями реализации СМ9107. Преемственность традициям также вносит вклад в надёжность новых решений.

Традиции реализации контроллеров СМ9107

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

Для ввода ответственных дискретных сигналов во многих случаях используются каналы аналогового ввода, позволяющие на программном уровне выполнить анализ достоверности информации (выявить КЗ и обрыв).

Предпочтительным для ПЛК СМ9107 является микроблочное исполнение с монтажом на рейку DIN-35, исключающее свойственные крейтам территориальные и количественные ограничения. В частности, модули ПЛК СМ9107 благодаря малым габаритам и низкому потреблению могут размещаться “по-месту”. Габаритный и ценовой фактор модулей наименьшей размерной группы СМ9107 позволяет рассматривать их как недорогую интеллектуальную (цифровую) гальваническую развязку.

Предпочтительным средством коммуникаций для ПЛК СМ9107 являются надёжный, широкодоступный и распространённый интерфейс RS485 с протоколом Modbus (RTU или ASCII) и скоростью обмена до 115,2 кБит/c. Подключение к инженерной/операторской станции отдельных ПЛК и систем на базе ПЛК СМ9107 производится с помощью сетевых переходников RS485-Ethernet или RS485-USB. Необходимое сочетание вертикального и горизонтального потоков информации в сети устройств СМ9107 может быть определено проектно выбором программно реализуемой стратегии управления сетью (“ведущий-подчинённый”, “издатель-подписчик”, передача функций (маркера) ведущего узла).

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

ормой электропитания ПЛК СМ9107 являетсянестабилизированное напряжение 9 … 40 В постоянного тока. Применяемая реализация выдерживает перерывы питания до 100 мс со скважностью до 50 % (для исполнения без дисплея с подсветкой). Это, в частности, позволяет использовать для питания сеть переменного тока 12 … 30 В (действующее значение). Потребляемый ток блоков в базовом исполнении 30…60 мА, что позволяет компоновать территориально-распределённые системы с единым удалённым источником питания и общим недорогим кабелем питания и связи.

Сетевые средства обеспечивают синхронизацию бортового времени всех устройств сети с точностью до 1 мс. Реактивность контура управления на уровне одного ПЛК СМ9107 составляет 1…100 мс, на базе сети устройств – 50…500 мс.

CONField обеспечивает возможность программирования ПЛК в составе системы (без демонтажа). Схемотехника устройств СМ9107 позволяет осуществлять их “горячую” замену.

Лёгкость переноса решений в специальные исполнения

Благодаря экономичности, миниатюризации и микропотреблению апробированные решения СМ9107 легко переносятся в специальные исполнения.

Примером применения решений СМ9107 и инструментальной системы CONField является разработка ПО интеллектуальных первичных преобразователей (рис. 4) [6] (датчиков/исполнительных механизмов) силами специалистов опытного завода без привлечения профессиональных программистов.

Рис. 4 Интеллектуальный датчик турбинного счётчика нефти и газа – апробированные решения на базе CONField и СМ9107 в специальном исполнении

Применение технологии “СМ9107” и CONField при создании компактных микропотребляющих и энергонезависимых решений на базе соответствующих моделей микроконтроллеров позволяет преодолеть последнее преимущество старой автоматики на базе механики (ограничивающее внедрение электроники) – независимость от электропитания. Многие системы защиты (например, противопожарной) должны быть энергонезависимыми. То же касается систем (счётчиков) коммерческого учёта ресурсов.

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

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

Надёжная информативность

Важная особенность CONField – возможность сквозной разработки и обслуживания системы автоматики от уровня встраиваемого в датчик контроллера до уровня человеко-машинного интерфейса (HMI) в единой инструментальной среде, рассчитанной на возможность ответственности за конечный результат одного КИПовца или инженера КБ. Возможность программирования средствами CONField инженерных и технологических АРМ обеспечивает независимость служб автоматизации в вопросах информационной поддержки их повседневной работы.

Для ПЛК, средой исполнения которых является программная среда PC, CONField предоставляет визуальные аналоги элементов отображения и управления, встречающиеся в “железе” (такие как индикаторы, кнопки, лампы, табло, самописцы, задатчики, элементы мнемосхем и пр.). Так обеспечивается возможность программировать операторский интерфейс (HMI) на базе PC (рис. 5) средствами программирования аппаратных ПЛК.

Блок-схема алгоритма включает алгоблоки связи с пультовыми элементами. Реализация этой связи – задача подсистемы ввода-вывода (независимой от алгоритмического проекта). Поэтому созданная блок-схема алгоритма управления переносится в аппаратный пульт (со своей подсистемой ввода-вывода) без каких-либо изменений. Мы этим пользуемся при “макетировании” аппаратных пультов (контроллеров с пультом) средствами CONField, начиная разработку прикладного ПО задолго до готовности ”железа”.

Но самое главное, что для организации HMI больше не требуется тратить время на изучение сложных SCADA-систем!

Рис. 5 Операторский интерфейс в PC, управляемый блок-схемой

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

Для обеспечения функциональной законченности и информационной независимости отдельных подсистем в состав ПЛК семейства СМ9107 включены унифицированные инженерные пульты (рис. 6) и компоненты для построения технологических пультов [7], обеспечивающие минимизацию ценовых и компоновочных аспектов для снижения порога применимости на уровне полевого оборудования.

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

Рис. 6 Контроллер с пультом в номенклатуре ПЛК СМ9107

Дополнительный уровень информационной надёжности может быть обеспечен на основе комплектования контроллеров СМ9107 алфавитно-цифровыми или графическими дисплеями (рис. 3).

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

Надёжность и гибкость инструментальной и исполнительной среды

В CONField нет разделения “инструментальной” и “исполнительной” сред: элементы исполнительной среды становятся частью инструментальной среды при отладке и моделировании, равно как элементы инструментальной среды могут использоваться в исполнительной среде (как средства визуализации и пр.).

CONField является открытой модульной системой (рис. 7), ориентированной на развитие и возможность модульного конструирования единойинструментальной и исполнительной средыпроизвольной конфигурации на базе аппаратных ПЛК, ПЛК в среде PC, программных модулей CONField и массово доступного ПО.

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

Больше нет необходимости в мучительном выборе “комплесного обеда в одной тарелке” (традиционной SCADA-системы) с долгим усваиванием особенностей выбранной смеси, можно выбирать наиболее полезные и надёжные “блюда” независимо.

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

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

Рис. 7 Структура единой инструментальной и исполнительной среды CONField

Элементы модульной интеграции

VRE реализуется в виде платформонезависимой библиотеки языка C++.

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

В набор средств включена также утилита экспортав базу данных на базе технологии ODBC.ODBC-export позволяет экспортировать данные в любой SQL-сервер,DBF и текстовые файлы. Среди SQL-серверов, которые могут быть использованы для архивации данных: Oracle SQL server, Sybase SQL Server, Microsoft SQL Server, свобно распространяемый PostgreSQL и MySQL. С используемой базой данных можно работать из множества программ, например, из программ пакета Microsoft Office (или Open Office).

Среда эмуляции и моделирования

Частью распределённой аппаратно-программной среды автоматизации может быть сам PC. В программной среде PC средствами CONField может быть сформирована сеть ПЛК, связанных между собой и с аппаратными ПЛК в произвольной конфигурации (через VRE).

Такая возможность CONField позволяет выполнить эмуляцию аппаратного ПЛК (в том числе и его пультовых средств), эмуляцию любой части целой системы автоматизации любой конфигурации с любым сочетанием аппаратной и эмуляционной реализации, моделирование взаимодействия автоматики и объекта управления (на основе имитации объекта проектом или проектами сети ПЛК).

Ядро CONField

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

Развитие в направлении сквозного проектирования

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

Развитие CONField основано на идее использования языка блок-схем не только как языка программирования ПЛК, но и как единого средства сквозного проектирования комплексных аппаратно-программных решений автоматизации, единого средства описания всей системы “объект-автоматика” в аппаратных и программных аспектах.

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

Развитие CONField идёт в направлении сквозного проектирования.

Заключение

Рассмотрена лишь часть подходов, определяющих надёжность конечного решения.

Однако, как нетрудно заметить, эффект применения этих подходов ограничен их некоторой противоречивостью и неоднозначностью.

С одной стороны, привлечение дополнительных ресурсов в направлении избыточности (отдельных ПЛК и каналов связи для каждого контура, крупных алгоблоков вместо средств языка Си, множества уровней иерархии для изоляции ПО, гальванических развязок для электрической изоляции и т.д.) способствует росту надёжности системы (недостаток ресурсов и есть причина ненадёжности), но, с другой стороны, привлечённые дополнительные ресурсы … также потребуют поддержки ресурсами, что может вызывать их вторичный дефицит. Если учесть, что конечный “источник ресурсов” всегда ограничен (как например, ограничена мощность источника питания), то произойдёт либо снижающее его надёжность увеличение нагрузки, либо дополнительные элементы “заберут” часть ресурсов у основной системы. Например, увеличение числа уровней иерархии и количества элементов может увеличить надёжность и темп [обработки и передачи информации] одних контуров за счёт других.

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

Итог: априори конечный результат неизвестен. Это значит, что конечная надёжность решения – результат процесса последовательных приближений, ”отклонения” и “скорость сходимости” которого во многом определяются широтой выбора путей решения конечной задачи и удачным выбором первого приближения.

Основная цель создания и развития технологии “СМ9107” и CASE-системы CONField состоит в обеспечении широких возможностей выбора решений для конструирования надёжности и исследования её закономерностей.

Литература

Назад