Работы по реверс-инжинирингу программного обеспечения логических контроллеров, как правило, выполняются при следующих обстоятельствах:
- имеется функционирующее технологическое оборудование, в котором используется микропроцессорное устройство;
- у эксплуатирующей организации отсутствуют резервные копии или редактируемый проект программного обеспечения микропроцессорного устройства.
Одновременное наличие двух указанных условий предъявляет повышенные требования к персоналу, который выполняет работы по реверс-инжинирингу софта из ПЛК. Дело в том, что в случае неверных действий инженера оригинальное ПО ПЛК может быть потеряно без возможности восстановления. Как следствие этого, система автоматизации не сможет функционировать. Это значит, что технологическое оборудование превратится в набор неработающих элементов.
Невозвратные потери оригинального софта, как правило, связаны с загрузкой в контроллер «битой», неработающей, неверно откорректированной версии программного обеспечения. Причины отказов ПЛК после обновления ПО могут быть как в несоответствии версии среды программирования, которой скачивалось или загружалось ПО, с версией среды, которой это ПО было разработано. Также в основе проблем может быть сбой связи при выгрузке ПО или при его загрузке, наличие аппаратных устройств контроля версии загружаемого ПО или лицензии. И это неполный перечень причин, которые могут привести к фатальному отказу микропроцессорного устройства.
Следует отметить, что к нам неоднократно обращались клиенты с подобными проблемами, когда после работы «специалистов» системы автоматизации переставали функционировать. При этом возможности «откатить» систему на оригинальное заводское программное обеспечение уже не было, так как не было того самого оригинального программного обеспечения. Для исключения таких печальных результатов работы мы рекомендуем:
- Первоначально выполнять выгрузку ПО из ПЛК хоть в виде исполняемого программного кода, хоть в редактируемом формате (так называемый проект).
- Для тестирования работоспособности выгруженного софта использовать иной резервный, но полностью идентичный основному, процессорный модуль контроллера.
- Выполнить тестовую проверку работоспособности системы автоматизации с загруженным программным обеспечением в резервный процессорный модуль.
- Только после продолжительного периода работы, при котором не выявлены отказы и неисправности в работе резервного контроллера с загруженным ПО, принимать решение о загрузке этого проекта в основной контроллер.
- Аналогично пункту 3 выполнить тестовую работу системы автоматизации с использованием основного контроллера с загруженным программным обеспечением.
Только такой подход гарантирует, что работы по обратному инжинирингу ПО не выведут из строя действующую систему автоматизации. Если вы не состоянии выполнить какой-то из указанных выше пунктов, знайте, что всегда присутствует риск того, что вместо реверс-инжиниринга программного обеспечения заказчик получит «тыкву» из работающего технологического оборудования.
Обращайтесь к профессионалам!
