Технологичекие контроллеры. Вчера, сегодня, завтра
Е. Кузнецов
инженер НВП «Болид»,
В. Макеев
инженер НВП «Болид»
Еще сравнительно недавно при решении задач управления технологическими процессами широко применялись аналоговые контроллеры ведущих мировых лидеров: Siemens, TAC, Regin... Относительно недорогие, простые, надежные и удобные в настройке, они были «заточены» под решение ограниченного круга типовых задач и были весьма критичными к выбору оборудования в своей «обвязке». Совсем нередкой была ситуация, когда стоимость одного недорогого контроллера соизмерялась со стоимостью трех-четырех температурных датчиков, которые не допускали замены. Если в процессе эксплуатации возникала необходимость внести минимальные изменения в работу установок или просто переместить подальше датчик, а это не было предусмотрено на этапе проектирования, то инсталлятор получал головную боль, а заказчик сталкивался с новой сметой расходов.
На смену аналоговым контроллерам стали приходить первые цифровые контроллеры, которые с легкой руки незатейливых специалистов получили название «программируемых». Эти контроллеры действительно программировались, но только не проектировщиком или инсталлятором, а производителем на заводе-изготовителе или в специализированных центрах. Возможностей у цифровых контроллеров стало больше, но, как и раньше, при попытке изменить что-либо в алгоритме их работы, ситуация повторялась, однако уже была возможность, хоть и не всегда, «перепрошить» контроллер, что требовало демонтажа и обращения (не бесплатно) к изготовителю. В том случае, когда появлялась необходимость в добавлении аналоговых или дискретных входов или выходов контроллера, ситуация оставалась по-прежнему тупиковой. Этот период ознаменовался появлением дорогих, громоздких контроллеров с двух- и трехрядным расположением клемм, в которые производители старались встроить как можно больше входов и выходов, стремясь обеспечить запас на все возможные случаи. Чтобы обеспечить возможно больший ассортимент обрабатываемых типов датчиков, на плате контроллера устанавливался «частокол» перемычек, переустанавливать которые можно было только вскрывая контроллер. При этом на дисках или на сайтах размещались рисунки и фотографии с расположением этих перемычек и большие библиотеки всевозможных алгоритмов, отличия в которых порой не могли определить и квалифицированные специалисты. На этом этапе конкретные входы и выходы были по-прежнему жестко привязаны к алгоритмам, и если происходила поломка клеммы, например, дискретного входа, а рядом оставалось несколько точно таких же свободных дискретных входов, то дорогой контроллер все равно требовал демонтажа и замены.
Следующий этап характеризовался появлением конфигурируемых контроллеров, в которые загружалось несколько алгоритмов, и пользователь мог активировать один или одновременно несколько из них, если было достаточно входов и выходов. Кроме того, сами алгоритмы могли также конфигурироваться пользователем путем выбора и активации необходимых режимов и опций, а с ними и соответствующих входов и выходов, заложенных в алгоритм. Конфигурируемые контроллеры, как правило, позволяли пользователю переназначать расположение входов и выходов. Несмотря на то, что проектировщик и инсталлятор оставались в полной зависимости от алгоритмов, заложенных в контроллер, конфигурируемый контроллер уже позволял значительную свободу выбора и меньшую зависимость от производителя.
Действительно, программируемые контроллеры (или свободно программируемые контроллеры, или программируемые логические контроллеры) явились логическим продолжением конфигурируемых и предоставляли возможность пользователю начинать работу над проектом «с чистого листа». Пользователь получал программные оболочки для создания, редактирования, компиляции, тестирования своего проекта, а вместе с ними и возможность разработки собственных алгоритмов и прошивок в зависимости от поставленной задачи. Казалось бы, на этом этапе можно было бы и поставить точку, но все оказалось не так просто. Выяснилось, что весь проект ложится, фактически, на одного-единствен-ного проектировщика, который должен был уяснить задачу,составить и откомпилировать проект и протестировать его. Казалось, что запроектировать типовые алгоритмы сложности не составляет, проектирование имеет удобный интерфейс и автоматизировано, а тестирование можно выполнить и на объекте. Действительность разрушила все иллюзии. Выяснилось, что выполнить все этапы одному-единствен-ному проектировщику, при этом учесть все нюансы и не допустить ни одной ошибки не так-то и просто, а тестирование проекта - процедура, по трудоемкости соизмеримая с разработкой самого проекта. Кроме того, и само программирование требовало квалификации значительно более высокой, чем конфигурирование. Реализация алгоритмов производителями контроллеров проводилась коллективно, в режиме обратной связи с многочисленными клиентами, большими тиражами и постоянно обкатывалась и тестировалась. Алгоритмы производителей буквально обрастали всевозможными блокировками, задержками, дополнительными, не очевидными на первый взгляд опциями и реакциями на различные штатные и нештатные ситуации. Таких возможностей у проектировщиков и инсталляторов, как правило, не было. Дополнительные программные оболочки внесли удобство и наглядность для проектировщика, но, как и любое промежуточное звено, не внесли быстродействия и, главное, надежности. Вторым важным промежуточным звеном стал программист-проектировщик, как правило, молодой, эрудированный, не искушенный в нюансах автоматики, но амбициозный.
Как следствие, программируемые контроллеры, более дорогостоящие, со сложным дополнительным программным обеспечением, будучи установлены в конкретную систему у конечного потребителя, в итоге оказывались медлительными и капризными, менее надежными, а сопровождать такую систему приходилось именно тому, кто ее и разрабатывал. Любые, даже минимальные, изменения в системе автоматически требовали доработки исходного проекта, перекомпиляции и тестирования тем же самым программистом. Увольнение такого проектировщика-программиста превращалось для фирмы-инсталлятора в настоящую проблему. Для нового программиста было проще спроектировать все самому с нуля, нежели разбираться в том, что было сделано предшественником, и, как следствие, процесс пуско-наладки повторялся снова и снова.
Вопрос еще более обострялся, когда возникала необходимость «добавить железа». Разные производители по-разному предлагали решать эту проблему. Одни выпускали дополнительные линейки модулей расширения, другие предлагали воспользоваться встроенным в контроллер стандартным интерфейсом и подключать оборудование сторонних производителей. И тот, и другой вариант в большей или меньшей степени усложнял и процедуру проектирования системы. Таким образом, зависимость инсталляторов и проектировщиков от производителя уменьшилась, но увеличилась зависимость от собственного программиста - возросло влияние человеческого фактора. Интересной, поучительной и символичной в этой связи представляется реакция посетителей выставочного стенда на одной из выставок, когда на вопрос о том, как вам с новыми программируемыми контроллерами,неод-нократно звучал один и тот же ответ: «Спасибо... наелись...»
Чтобы хоть как-то унифицировать программирование контроллеров, появились международные стандарты на среды разработки. Показавшие себя наиболее востребованными, близкие группы языков скомпоновались в шесть, а потом в пять языков, ориентированных на программистов, электриков, электронщиков и технологов. Появилась возможность использовать в одном проекте несколько языков одновременно, и, что особенно важно, появилась переносимость кода и преемственность, хотя бы внутри одной группы процессоров. Совершенно естественно, что унификация повлекла за собой избыточность, которая еще больше возросла с появлением кроссплатформенности и установкой в контроллеры различных операционных систем. Но за все приходится платить. Как результат, требования к микропроцессорам таких контроллеров возрастают на порядки и на смену восьмиразрядным Atmel-ам или даже PIC-ам приходят АРМ-ы. Но это еще полбеды. Вторая половина - это программное обеспечение. Для полного следования стандартам, а это для одного, даже крупного производителя очень накладно, приходится устанавливать платное ПО и, возможно, платную операционную систему, а это автоматически увеличивает, и весьма ощутимо, стоимость контроллера.
Промышленные объекты, административные здания, крупные торговые комплексы заполнялись многочисленными, полученными от разных производителей и разных инсталляторов системами кондиционирования, вентиляции, отопления, контроля доступа, охранной и пожарной сигнализации, а постоянный рост стоимости энергоресурсов требовал внедрения энергосберегающих технологий и, как минимум, мониторинга систем на объекте. В сложившейся ситуации не только доработка, не только обслуживание, но даже просто включение или выключение всего этого оборудования превращалось в продолжительный и ответственный ритуал, а уж определение виновника какой-либо аварии превращалось в настоящее расследование. Как итог, эксплуатирующие организации буквально превращались в заложников разнообразного оборудования и человеческого фактора, а инсталляторы за такие, казалось бы, выгодные объекты просто не брались. Все более очевидной становилась необходимость комплексного решения с интеграцией различных систем в единую и появлением сетевых контроллеров. Инсталляторы, пытавшиеся объединить инженерные системы с охранно-пожарными от разных производителей, вынуждены были прибегать к различным ухищрениям и пытались связывать их на сигнальном уровне при помощи дополнительных тумблеров, шлейфов или реле. Некоторые положительные результаты давало использование стандартных интерфейсов, но при всем их многообразии, чем более универсален и открыт интерфейс инженерных систем, тем он медленнее и доступнее, и использование его в охранно-пожарной системе или тем более в системе контроля и управления доступом весьма спорно, да и сертифицировать такую систему в целом проблематично. При этом все равно требовалось приобретать программное обеспечение для каждой из систем отдельно, а информацию выводить на разные рабочие места.
При совмещении в одном контроллере конфигурируемости, программируемо-сти и поддержки сети у проектировщика и инсталлятора качественно расширяются возможности при реализации как простых, так и сложных проектов, и значительно сокращается время разработки. Все рутинные, ответственные, трудоемкие процедуры уже реализованы во встроенных алгоритмах и сетевой поддержке. Все, что остается пользователю - это либо взять готовое, либо «довести» проект до завершения, объединив отдельные, уже готовые фрагменты, подчас не написав ни строчки кода на Си или другом языке программирования.
Отдельно остаются актуальными вопросы, связанные с метрологией, поверкой и сертификацией.
