2015-05-13
1252
С точки зрения инженера, создающего комплекс средств систем автоматики, прикладное ПО можно разбить на следующие важнейшие группы:дополнение к операционной системе (драйверы и т.п.);программы управления, снятия (получения), передачи данных, обработки данных, планирования и т.п., то есть прикладные вычислительные задачи; ПО локальных регуляторов. Эта часть программного обеспечения часто создаётся для специализированных микроконтроллеров и поэтому имеет свои особенности.
Важно также учитывать то обстоятельство, что для создания этих разнородных частей прикладного программного обеспечения используются совершенно разные методы программирования. Наиболее традиционной частью являются прикладные вычислительные задачи. Решать эти задачи стремятся традиционными методами и для этого стараются использовать программирование на языках высокого уровня, не упуская при этом из видимости тот факт, что работа программы должна вестись в реальном времени. Обычно удаётся здесь обойтись программированием на языке С, С++, Pascal, привлекая для этого (по возможности быстродействия) интегрированные среды типа
Visual C, Builder или Delphi.
Если это удаётся, то имеется возможность создания мощного современного программного обеспечения, удовлетворяющего всем требованиям к интерфейсам пользователя.
При создании программного обеспечения для локальных контроллеров важно придерживаться следующих принципов:
При разработке систем управления стараются обеспечить однородность вычислительной платформы, что позволит в дальнейшем упростить программирование. В настоящее время реально это означает, что целесообразно в локальных системах использовать не специализированные микроконтроллеры, а PC‑совместимые контроллеры.
Это требование, конечно, не является императивным, так как имеется достаточное количество примеров, когда наиболее эффективны именно специализированные контроллеры. Например, в задачах цифровой обработки сигналов используются специальные DSP-процессоры. Но при этом следует понимать, что обслуживание узкоспециализированного программного обеспечения часто накладно.
При разработке микропрограмм для локальных контроллеров тщательно обосновывать выбор контроллеров, исходя из перспективности той или иной микроконтроллерной платформы. Причём, основным аспектом является не экономический, так как стоимость современных микроконтроллеров стремительно снижается, а системный. Использование устаревающих контроллеров нецелесообразно. Кросс-средства программирования для различных контроллеров существенно отличаются с точки зрения универсальности, стандартизованности и ориентированности на интеграцию в состав более сложных иерархических систем.
Библиотеки программ, созданные для микроконтроллеров, с трудом поддаются повторному использованию и передаче другим пользователям, часто оказывается проще создать программы заново. К сожалению, объектно-ориентированный подход здесь применим далеко не всегда, так как влечёт резкое увеличение объёмов кодов.
Альтернативой традиционному программированию микроконтроллеров, в принципе, является технология Java, предполагающая сетевую загрузку исполняемых программ (апплетов) в контроллеры. Здесь следует отметить, что это не вполне безопасно и не всегда надёжно.
Международная Электротехническая Комиссия (МЭК) в 1993 г. утвердила стандарт IEC 1131 часть 3 (IEC 1131-3). Этот международный стандарт входит в группу IEC 1131 стандартов, которые охватывают различные аспекты использования программируемых логических контроллеров (ПЛК). Стандартом МЭК предусмотрено 5 языков программирования ПЛК: IL, LD, FBD, ST, SFC. При разработке проекта пользователь может выбрать любой из языков для написания конкретного программного модуля (POU). В рамках одного проекта могут присутствовать программные модули, написанные на разных языках. Так, например, в среде программирования CoDeSys поддержаны все
5 языков, а также один дополнительный:
IL (Instruction List) – Список инструкций – язык программирования, напоминающий ассемблер Siemens STEP7. Все операции производятся через ячейку памяти, «аккумулятор», в который программа записывает результаты произведенных действий.
LD (Ladder Diagram) – Релейные диаграммы – графический язык программирования, использующий принципы построения электрических схем. С помощью элементов «контакт» и «катушка» пользователь собирает схему прохождения сигнала. Язык удобен для реализации логических алгоритмов работы с дискретными сигналами.
FBD (Functional Block Diagram) – Диаграмма функциональных блоков – графический язык программирования. Все действия и операторы, используемые в данном языке, представляются в виде функциональных блоков (ФБ). ФБ имеют входы и выходы определенных типов, которые могут быть связаны между собой. Помимо стандартных ФБ пользователь может вставлять в алгоритм собственные POU, созданные в рамках данного проекта или реализованные в подключенных к проекту библиотеках. В CoDeSys реализован улучшенный язык программирования с помощью функциональных блоков, получивший обозначение CFC.
ST (Structured Text) – Структурный текст – текстовый язык программирования, схожий с языком высокого уровня (С, Pascal). Язык ST удобен для реализации сложных вычислений, циклов и условий, для работы с аналоговыми сигналами.
SFC (Sequentional Functional Chart) – Последовательные функциональные схемы – графический язык, приспособленный для создания последовательности этапов алгоритма работы. Каждый этап реализуется на любом удобном для пользователя языке. Язык удобен для создания алгоритмов управления сложными процессами, имеющими несколько ступеней, написания моделей автоматов.
Перечисленные языки IEC 1131-3 используются ведущими фирмами изготовителями ПЛК, имеют длительную историю применения, достаточно распространены и известны пользователям. Но, к сожалению, имеются многочисленные модификации, несущественные по смыслу, но влекущие определенные неудобства при работе с ПЛК различных фирм-изготовителей. С этой точки зрения, стандарт IEC 1131-3 несомненно прогрессивен, поскольку позволяет сделать процедуру внедрения конкретной платформы автоматизации более эффективной.
С другой стороны, в области автоматизации работает значительное количество инженеров-программистов, для которых более привычными являются обычные блок-схемы алгоритмов, с помощью которых, конечно, можно достаточно эффективно отобразить необходимые алгоритмы. Видимо постепенно будет достигнуто некоторое компромиссное решение, учитывающее как потребности автоматчиков-непрограммистов, так и навыки программистов.
В настоящее время визуализацию в контроллерах ОВЕН ПЛК можно просматривать с помощью CoDeSys HMI.
Библиотеки CoDeSys часто содержат следующие программные модули: реализованные функции стандартных вычислений (сложение, вычитание, умножение, счетчики времени, триггеры и т. д.); реализованные функции сложных алгебраических вычислений (тригонометрические и логарифмические функции, преобразования типов данных, генераторы сигналов, П-, ПИ-, ПИД-регуляторы, интеграторы, графики); реализованные функции, позволяющие работать со специализированными и низкоуровневыми функциями контроллера.
Библиотеки могут быть созданы: создателем среды программирования CoDeSys (Standart.lib, Util.lib, SysLibTime.lib и т. д.); производителем контроллеров (компанией ОВЕН созданы библиотеки PID_Regulator.lib, UNM.lib); непосредственно конечным пользователем – пользователь сам может создавать библиотеки, включая в них программные модули, написанные единожды, но которые ему могут в дальнейшем понадобиться. Элементы библиотек становятся доступны для использования при подключении библиотеки к конкретному проекту. Подключение библиотек производится с помощью ресурса Library manager (Менеджер библиотек).
Library Manager (Менеджер библиотек) Служит для подключения в проект библиотек – как стандартных, так и пользовательских. Содержит список всех библиотек, которые связаны с проектом. Взятые из библиотек POU (программные модули), типы данных и глобальные переменные можно использовать так же, как определенные пользователем.
Пользовательская память встроенная в контроллер. Объем доступной памяти составляет порядка 3 Мб. Может быть использована пользователем для ведения архивов данных и событий, для хранения исходных файлов проекта, созданного в среде программирования CoDeSys, и любых других файлов. При отключении питания все файлы сохраняются и могут быть выгружены из контроллера при последующем включении (например, с помощью PLC_IO или PLC Browser).
Аппаратные часы реального времени встроены в ПЛК. Работают даже при выключенном питании контроллера благодаря встроенному в ПЛК аккумулятору.
5.5.4. Инструментальные средства разработки,
отладки и сопровождения программного обеспечения
В настоящее время утвердилось тенденция перехода на интуитивно-понятные разработчику средства визуального проектирования в области автоматизации.
В любой предметной области, в том числе и в автоматике, визуальные средства предполагают, что проектировщик не должен создавать практически никакого кода программы ни на одном из языков программирования. Вместо этого он производит размещение тех или иных наглядных графических образов (обычно пиктограмм) на рабочем поле. Эти образы представляют собой отображение некоторых стандартных блоков, алгоритмов, устройств. Соединяя эти образы в соответствии с требуемой структурой, и задавая свойства отдельных компонент, разработчик получает требуемое представление своей системы. Практически избежать программирования удаётся за счёт объектно-ориентированного характера такой модели, при котором необходимые коды программ уже размещены в стандартных блоках. То есть программирование заменяется заданием параметров в стандартных алгоритмах.
Одним из типичных средств визуального проектирования является применение SCADA-систем, то есть таких систем, которые в основном предназначены для диспетчерского отображения разнородной информации, в состав которых входит человек-оператор. В таких системах, когда реальное быстродействие объекта управления гораздо выше быстродействия человека-оператора, последнему отводится роль наблюдателя, принимающего стратегические решения. И практика показывает, что для подобных систем применение визуальных средств и объектно-ориентированных подходов в программировании эффективно. В качестве примера можно привести систему TraceMode. Наряду со специализированными визуальными средствами программирования, широко распространено и применение таких визуальных сред, как Delphi или Builder от фирмы Borland, Visual C++ от Microsoft и т.п.
Однако, чтобы добиться более предсказуемого поведения программного обеспечения с учётом работы в режиме реального времени разработчик автоматических систем всё же вынужден в ряде случаев создавать собственное ПО. Наиболее целесообразный подход здесь следующий: по мере возможности пользоваться языками высокого уровня, позволяющими быстро создавать и отлаживать ПОи лишь в явных случаях нехватки быстродействия или надёжности использовать программирование на Ассемблере.
Именно такой подход позволяет инженеру в области автоматики решить сразу две задачи: обеспечить реальную возможность передачи исходных кодов программ другим разработчикам, в том числе, и при смене вычислительной платформы, а также добиться существенной экономии времени разработки программного обеспечения.
Стандартными средствами во всех случаях являются специальные программные продукты, предназначенные для разработки программного обеспечения: редакторы, трансляторы, компоновщики, отладчики. Однако наиболее целесообразно использовать специальные интегрированные среды разработки, объединяющие все эти средства. Такие среды разработки имеются практически для всех языков программирования, в том числе, и для ассемблеров микроконтроллеров.
Некоторые производители, например, китайская фирма
Octagon Systems включают поддержку разработки прикладного программного обеспечения средствами, находящимися в ПЗУ контроллеров. Такой подход позволяет оперативно перепрограммировать контроллеры даже в том случае, когда отсутствует специальная среда программирования, нет сетевой поддержки переноса программных модулей и даже отсутствуют дисковые устройства, пригодные для переноса программы. Решение фирмы Octagon Systems заключается в том, что во флэш-памяти контроллера имеется интерпретатор языка CAMBasic, полностью совместимого например, со стандартным Microsoft Basic, но имеющим существенно расширенную систему команд, включающих множество нестандартных команд, пригодных для использования в системах управления, метрологических системах и т.п.
