ЖУРНАЛ «СТА» 4/2016

● profile7.auxiliary – пакетный файл, со- стоящий из команд, распознаваемых средой. Основные действия, выпол- няемые их обработчиками, – создание, заполнение и десериализация объ- ектов. Содержит свою таблицу строк, ссылки на которые могут присутство- вать в отдельных полях команд; ● *.object – контейнер, хранящий опре- делённый пользовательский объект. К таковым могут относиться програм- мы (POU), интерфейсы (Interfaces), наборы картинок (Image Pool), на- стройки проекта (Project Settings), внешние файлы (External Files), биб- лиотечные модули (Libraries). В объ- ектных файлах содержатся экземпля- ры классов, описанных в схеме, яв- ляющихся, по сути, строительными единицами минимального размера. На рис. 8 показано устройство такого экземпляра. Общий алгоритм обработки проекта при загрузке его средой разработки: 1)открытие архива; 2)обработка файлов с глобальной таб- лицей строк и схемой; 3)создание пользовательских объектов из файлов объектов; 4)обработка вспомогательных файлов при их наличии; 5)выполнение команд из пакетного файла profile7.auxiliary. М ЕТОДЫ ЧАСТИЧНОЙ АВТОМАТИЗАЦИИ ПРОЦЕССА МИГРАЦИИ ТП Немалая часть проблем, кроющихся в миграции, была упомянута ранее в том или ином виде, поэтому необходимо подвести итоги и выделить задачи в этом процессе, которые можно решать без привлечения инженера АСУ ТП. Но вначале нужно определить ряд допол- нительных терминов. Назовем исход- ным контроллером (ИК) ПЛК, с кото- рого производится миграция, а целе- вым контроллером (ЦК) ПЛК, на кото- рый она производится. Миграционной парой (МП) обозначим совокупность конкретных ИК и ЦК. В данном разде- ле под миграцией будем понимать толь- ко перенос программ управления ТП, работающих на ПЛК. В табл. 1 пере- числен наиболее полный, с точки зре- ния авторов, список проблем, получен- ный в результате исследования широ- кого спектра устройств, а также указана примерная оценка сложности разработ- ки средства автоматизации по десяти- балльной шкале. В первую очередь нужно обозначить части работы, трудно поддающиеся ав- томатизации, конкретно – проблемы 7 и 8. Они эффективнее решаются с участи- ем эксперта, способного самостоятель- но доработать программу управления, – настроить конфигурацию контроллера, дописать недостающий код или заме- нить некорректный. Все же остальные задачи могут (теоретически) решаться не вручную, а с использованием специ- ального программного обеспечения. Рассматривая способы автоматизации миграции, стоит начать с закрытия пер- вой проблемы, так как без этого не по- лучится справиться с любой другой из заявленного авторами списка. Задача за- ключается в том, что имеется набор объ- ектов разных типов, хранящихся в ИПП или ПУ и имеющих отношение к техни- ческому процессу, и их нужно научиться извлекать. Желательно, чтобы в резуль- тате проведения этой операции они бы- ли восстановлены в первозданном виде. В случае, когда имеются файлы ИПП, она всегда возможна, поскольку её про- водит сама среда разработки при откры- тии ранее сохранённого проекта, но до- статочно часто он отсутствует. Так как к ПУ, как правило, предъявляются до- вольно жёсткие требования – ограниче- ния по размеру и представление кода программы в удобном для исполнения виде, то извлечение объектов из неё мо- жет быть произведено не полностью, а с потерей информации. Например, на ПЛК S5-101U при загрузке ПУ не пере- даётся ряд блоков, в том числе содержа- щих комментарии и имена входов-вы- ходов. Ещё более неприятным является факт отсутствия на устройстве описания типов переменных, хранящихся в бло- ках данных (DB, DX). Это вынуждает выводить их из инструкций MC5-кода, что требует полного анализа программы (и вовсе не обязательно будет получена первоначальная структура DB-блока). Для контроллеров, построенных на ба- зе платформы CODESYS, дела обстоят ещё печальнее: в ПУ не содержится ка- кой-либо вспомогательной информа- ции для среды разработки (по умолча- нию исходные коды проекта на устрой- ство не загружаются), поэтому одно- значно получить объекты не удастся. Несмотря на количество их типов и сложность реализации корректного из- влечения каждого из них, технологиче- ски наиболее трудоёмким этапом рабо- ты является восстановление оригиналь- ного кода программы ПЛК. Если среда исполнения представлена виртуальной машиной, то необходим, как минимум, дисассемблер её байт-кода. В случае с SIEMENS его будет достаточно (выда- ваемые им мнемоники аналогичны ис- пользуемым в языке STL), а для реше- 62 СТА 4/2016 ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ www.cta.ru Рис. 8. Разбор содержимого пользовательского объекта POU Таблица 1 Список проблем, возникающих при автоматизации процесса миграции № Краткая характеристика проблемы Оценка сложности 1 Различное внутреннее устройство ПУ и ИПП у ПЛК, участвующих в миграции 7 2 Небольшие отличия в синтаксисах одних и тех же МЭК-языков в контроллерах МП 3 3 Отсутствие в ЦК некоторых составных структур данных, доступных в ИК 1 4 Отсутствие в ЦК поддержки МЭК-языка, на котором написана часть исходных программ 5 5 Отсутствие в ЦК некоторых библиотечных функций, доступных в ИК 6 6 Отсутствие в ЦК ряда высокоуровневых абстракций, имеющихся в ИК 7 7 Различия в поддерживаемом контроллерами периферийном оборудовании 9 8 Различия в поддерживаемых контроллерами протоколах взаимодействия с компонентами АСУ ТП 9