На пути к технологиям высокой надёжности Г.А. Егоров, В.Е. Красовский, М.А. Островский, Я.А. РейзманCASE-система CONField и ПЛК СМ9107 – новые продукты ИНЭУМ, демонстрирующие развитие подходов к созданию технологий высокой надёжности.Длительное время традиционной считалась практика передачи “сырых” сигналов от распределённых по цеху первичных преобразователей к размещённому централизованно контроллеру, выполняющему различные по темпу и объёму информации задачи множества контуров управления. Контроллер имел значительные габариты и стоимость общесистемной части (ЦП, модульная магистраль, крейт) и монтировался в специальных шкафах в машинных залах. Количество каналов сопряжения измерялось тысячами, длина кабельных трасс достигала тысяч метров. Сегодня, входя в состав большинства создаваемых систем и устройств, автоматика концентрирует на себе ответственность за безопасность, надёжность и эффективность их функционирования. Соответственно, качественно меняются требования к надёжности самой автоматики. И это происходит на фоне ужесточения ограничений затрат на её разработку, развёртывание и обслуживание, определяемых условиями массовой доступности. Однако уходят и многие ограничения, длительное время сужавшие выбор структуры решений. Микроконтроллеры и элементы коммуникационных интерфейсов превратились в абсолютно доступный многовариантный “стройматериал” для “индивидуального” строительства по любому “архитектурному” проекту. Всё это ведёт к постепенной смене подходов как разработчиков, так и потребителей, отражаясь в заметных тенденциях рынка решений для АСУТП. Подходы, лежащие в основе новых инструментальных, технических и программных средств ИНЭУМ – обобщение опыта комплексного обеспечения надёжности и эффективности решения конечной задачи при жёстких ограничениях интегральных затрат. Кратко эти подходы [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 возможно неограниченное иерархическое проектирование не только в рамках проекта одного ПЛК, но и в рамках распределённой вычислительной среды, то есть возможность распределённого иерархического проектирования: внутренняя реализация любого алгоблока любого уровня иерархии общего проекта автоматизации может быть размещена в отдельном ПЛК и тем самым изолирована. ^ КОНТУР ДИСПЕТЧЕРИЗАЦИИ Блок-схема алгоритмауправленияP1P2ЗАДАНИЕP2P1P1P2P2P1РЕЗУЛЬТАТУПРАВЛЕНИЕСОСТОЯНИЕОператорКОНТУРуправленияКОНТУР в ПЛКPАЦЕЛЬФАКТРЕШЕНИЕРЕЗУЛЬТАТКОНТУР в ПЛККОНТУР в ПЛКPОPО – процесс объекта (технологический) P1 – элементы межуровневого сопряжения: первичные преобразователи (актуаторы и сенсоры, алгоблоки-свёртки (обеспечивающие связь с локальной или удалённой реализацией процесса ввода- вывода или обработки информации) P2 – вторичные преобразователи (модули УСО, алгоблоки анализа и синтеза информации) PA – процесс управления (автоматизации), определяемый функциональной блок-схемойРис. 2 Единичный контур управления (слева) и вариант иерархии контуров (справа)Для распределения иерархического проекта внутренняя реализация алгоблока-свёртки размещается в одном контроллере, а сам алгоблок-свёртка входит в проект другого контроллера, обеспечивая связь со своей “удалённой” реализацией. С точки зрения возможностей CONField не существует ограничений на общее количество уровней иерархии проекта и количество уровней вычислительной среды (на базе сетей ПЛК). Также не существует ограничений на количество алгоблоков любого уровня иерархии. Основанием для раздельной реализации контуров обычно является различная территориальная привязанность (территориальное распределение), высокий уровень ответственности (статусное распределение), различные интенсивности процессов (по объёму и темпу - параметрическое распределение), несовместность требований контуров к ресурсам (ресурсное распределение).^ Локализация ответственностиИзолированная реализация контура управления подсистемы объекта позволяет “локализовать ответственность” – ограничить область распространения требований надёжной реализации набором элементов, принадлежащих контуру безраздельно. Локализация ответственности упрощает её обеспечение. Возможность создания интеллектуальных подсистем на основе изолированной реализации их контуров управления во многих случаях является наиболее эффективной стратегией автоматизации сложных технологических объектов, упрощающей планирование, согласование и организацию всех видов работ и мероприятий по вводу систем в эксплуатацию. Кроме того, такой подход всегда является более комфортным психологически для локального персонала, и часто единственно возможным, когда решается задача поэтапной замены устаревшего оборудования КИПиА без прерывания технологических процессов и без снижения уровня производства. Поэтому построение систем автоматизации на базе интеллектуализации подсистем объекта становится нормой проектирования при решении задач с приоритетом надёжности. Распределённое иерархическое проектирование в CONField позволяет создавать решения с необходимой локализацией ответственности при заданных ограничениях на расход вычислительных и прочих ресурсов. ^ Надёжность аппаратно-программной среды и контроль расхода ресурсовУровень достижимой надёжности реализации автоматики определяется свободой выбора представленных структурных решений, и, в конце концов, собственно надёжностью выбранной структуры аппаратно-программной среды и всех её процессов. Разработанное в ИНЭУМ семейство промышленных контроллеров СМ9107 обеспечивает возможность построения надёжной среды сигнального ввода-вывода, коммуникационной и вычислительной в произвольной конфигурации и с низким порогом применимости аппаратных компонентов по техническим и экономическим характеристикам. В основе полученного результата – принципы применения и построения аппаратных и программных средств ПЛК семейства СМ9107, именуемые в совокупности технологией “СМ9107”. Суть технологии “СМ9107” состоит в следующем.^ Выбор структуры аппаратно-программных средств, сокращающей совместное использование общих ресурсов независимыми контурами. Структура аппаратно-программной среды должна обеспечивать такую реализацию контуров, которая бы исключала или минимизировала раздельное использование контурами с различной локализацией ответственности (территориальной, статусной, параметрической и ресурсной) общих ресурсов сигнального ввода-вывода, коммуникационных и вычислительных. Такая организация среды реализации обеспечивает изоляцию контуров и на уровне ПО, и на уровне коммуникационных связей и сигналов сопряжения с объектом. Тем самым, сокращаются риски взаимовлияния контуров и риски возможного поражения аппаратуры и/или аппаратных и программных процессов.^ Ограничение функциональной нагрузки каждого ПЛК. В соответствии с принципами локализации ответственности контуру автоматизации подсистемы объекта выделяется отдельный ПЛК СМ9107 (или распределённая аппаратно-программная среда в виде группы ПЛК СМ9107, объединённой внутренней сетью контура). Выбор ПЛК (или группы) определяется уровнем допустимой функциональной нагрузки (п. D). Соответственно, функциональная нагрузка каждого ПЛК – ниже допустимой.^ Ограничение коммуникационной нагрузки каналов связи ПЛК. Локализация ответственности отдельных контуров (или их частей) в отдельных ПЛК снижает требования к темпу и объёму информационного обмена между ПЛК, и соответственно, расширяет диапазон применимых коммуникационных интерфейсов и возможности их [множественного] использования для организации надёжной среды передачи информации между контурами и внутри контура (в случае его распределённой реализации). Исключается необходимость параллельных шин для связи ПЛК.Приближение аппаратной надёжности каждого ПЛК к надёжности чипа.^ Уровень допустимой функциональной нагрузки на отдельный ПЛК определяется условием его аппаратной надёжности, которая обеспечивается сведением реализации ПЛК практически к “одному чипу” (8-, 16- или 32- разрядному микроконтроллеру, обладающему ресурсами ввода-вывода, вычислительными и коммуникационными, достаточными во многих случаях для полной реализации одного контура) с минимизацией аппаратной обработки сигналов (за счёт программной обработки), с исключением необходимости параллельных шин вне микроконтроллера, и, соответственно, с предельным сокращением числа аппаратных элементов и связей (что упрощает топологию печатной платы, сокращает число паек, контактных соединений и т.д.).^ Надёжность способа исполнения ПО в ПЛК. Ограничение функциональной нагрузки ПЛК небольшим набором тесно связанных “нитей активности” одного контура управления позволяет радикально упростить способ исполнения ПО. Исключается операционная система (самый сложный и ответственный элемент, отказ которого ведёт к отказу всей системы). Простейшее управление нитями активности распределяется по самим нитям активности. Реализация основана на естественном для каждого конкретного программного процесса фазировании – исполнении до “точки” с минимальным сохраняемым контекстом. В частности, естественным фазированием прикладного ПО являются алгоблоки. От ОС остаётся лишь простой супервизор защиты, который вмешивается только при нарушении правил занятия ресурса в процессе такой самоорганизации. Исправность супервизора контролируется аппаратным сторожевым таймером (watchdog), который выполнит аппаратный рестарт в случае отказа супервизора. Сокращение сохраняемого контекста при фазированном исполнении позволяет выделить всю необходимую память каждой нити активности статически (на этапе подготовки ПО контроллера). Исключается использование прерываний на прикладном уровне: работа приложения организуется как простой циклический автомат. Прерывания на уровне ввода-вывода и системные детерминированы привязкой ко времени, коммуникационные прерывания детерминированы ограничением темпа обмена. В результате исключаются такие проявления недетерминизма, как динамическое выделение памяти, загрузка некорректного приложения, сложность процессов управления контекстами, планирования и активизации ниток активности, событийное управление и другие. Организация вычислительного процесса становится элементарной, а сам процесс – детерминированным. Минимизируется и упрощается системное ПО, уменьшаются риски взаимовлияния отдельных частей ПО, обеспечивается простота отладки и радикально снижаются требования к ресурсам. В этом и состоит второй механизм изоляции ПО на этапе исполнения, реализуемый CONField.^ Свобода выбора решенийТехнология “СМ9107”, резко сокращая требования к вычислительным ресурсам ПЛК, обеспечивает широту выбора процессорных и микроконтроллерных платформ, что в совокупности с ограничением функциональной нагрузки ПЛК обеспечивает радикальное уменьшение стоимости, габаритов и потребления ПЛК, расширяет свободу выбора решений. Именно на такую свободу выбора ориентирована CASE-система CONField. CONField является открытой системой с точки зрения поддерживаемых процессорных и микроконтроллерных платформ и вариантов аппаратной конфигурации ПЛК. В настоящее время поддерживаются:8-разрядные микроконтроллеры с ядром Intel51, микроконтроллеры семейства AVR Atmel (в частности, 32-выводный Atmega8, 44-выводные Atmega16 и Atmega32);16-разрядные микропотребляющие (менее 10 мВт) микроконтроллеры DSP Texas Instruments (MSP430F135, MSP430F149, 28-выводный MSP430F1232, 20-выводный MSP430F1121), микроконтроллеры Fujitsu (MB90F***);32-разрядные ARM7 (44-выводный Phillips LPC 210*, Atmel AT91SAM7*), DSP (DSC) Texas Instruments TMS320F28*;Intel X86-совместимые и собственно PC.Таким образом, 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 и инстру