Табличный ПЛК.Табличное программирование контроллеров

Предисловие

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

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

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

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

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

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

Решение данной проблемы – не новая задача, и в программируемых логических контроллерах (ПЛК) наряду с текстовыми языками применяются графические языки программирования: LD (Ladder Diagram) – язык релейных схем, FBD (Function Block Diagram) – язык функциональных блоков, SFC (Sequential Function Chart) – язык диаграмм состояний. Данные языки стандартизованы для применения в программируемых контроллерах в МЭК 61131-3[1]. Чтобы увидеть графическое отображение работы программы, созданной на одном из этих языков, необходимо подключить к ПЛК компьютер с установленной на нем средой разработки, в которую загружен исходный файл программы. Далее нужно синхронизировать программу в компьютере с программой в ПЛК. Тут опять возникает множество вопросов, не всегда имеющих адекватное решение:

– поставляется ли с оборудованием файл исходной программы?

– имеется ли в оперативном доступе компьютер с установленной средой разработки?

– есть ли возможность для подключения компьютера к ПЛК?

– необходима ли лицензия на использование среды разработки?

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

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

Из приведенных в пример графических языков у специалиста по информационным технологиям, не знакомого с ПЛК, только язык диаграмм состояний может не вызвать вопросов. Для небольших алгоритмов достаточно прост и понятен язык релейных схем LD, но программы с большим количеством блоков, написанные на нем, могут вызвать серьезные затруднения. Язык функциональных блоков FBD похож на принципиальную схему на логических микросхемах и более понятен специалистам по электронике, чем программистам.

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

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

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

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

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

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

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