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