Kitobni o'qish: «Табличный ПЛК.Табличное программирование контроллеров»

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Введение в табличное программирование контроллеров

1.1. Почему таблица?

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

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

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

Появление Microsoft Excel версии 3.0 и выше отодвинуло существовавшие на то время программы электронных таблиц других производителей на задний план. Хотя необходимо отметить, что электронная таблица Quattro Pro 9, входящая в Corel WordPerfect Office 2000, по своим возможностям не уступала аналогичной версии Microsoft Excel, но к этому времени MS Excel фактически стал стандартом. Особенно порадовала возможность заморозки части таблицы, как по вертикали, так и по горизонтали. Теперь можно было работать с довольно большими таблицами, используя замороженную часть как многострочный заголовок с возможностью видеть большое количество вычисляемых параметров. К примеру, таблица прихода и расхода комплектующих после появления MS Excel была сделана за пару часов и учитывала жизненный цикл каждой партии товара. Недостаток таких решений, состоящий в невысокой защищенности данных от случайных изменений, с лихвой покрывался скоростью получения интересующей вас информации и ее наглядностью.

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

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

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

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