Природа ошибок может быть самой разнообразной, и первое, что должен сделать
разработчик, столкнувшись с ошибкой – классифицировать её. В рамках АСУ ТП можно выделить следующие характерные типы ошибок:
Аппаратные неисправности могут возникать как по вине производителя (например, из-за непропая элементов платы на производстве), так и по вине пользователя (например, случайно подали 220 В на RS-485).
Способ определения аппаратной неисправности: если проблема не проявляется на другом приборе идентичной модели с той же версией прошивки, тем же пользовательским проектом и находящимся в тех же условиях эксплуатации – то, вероятно, причиной наблюдаемой ошибки является аппаратная неисправность.
В этом случае следует связаться с производителем и организовать отправку прибора в сервисный центр или запросить инструкции для проведения самостоятельного ремонта.
Под прошивкой ПЛК подразумевается низкоуровневое (с точки зрения пользователя) ПО, непосредственно управляющее аппаратной частью контроллера. В состав прошивки обычно входит начальный загрузчик, операционная система, драйвера для периферии, дополнительные службы и сервисы, не связанные с основными задачами ПЛК (например, web-конфигуратор, NTP клиент, FTPсервер и т.д.).
Как и любое другое ПО, прошивка может содержать баги различной степени критичности, которые могут иметь совершенно разные проявления – например, сброс значений энергонезависимых переменных в начальные значения после перезагрузки устройства, неработоспособность конкретного функционала (например, того же NTP-клиента), «зависание» ПЛК на этапе загрузки и т.д.
Обычно производители с некоторой периодичностью выпускают новые версии прошивок для своих ПЛК, в которых исправляют существующие ошибки (и, к сожалению, иногда добавляют новые). Если техподдержка производителя ПЛК точно знает или подозревает, что наблюдаемая клиентом проблема связана с конкретной версией прошивки – то она даст рекомендации по ее обновлению до актуальной версии. Часто совет по обновлению прошивки до актуальной является универсальным (примерно как совет «попробуйте выключить и включить» в техподдержке интернет-провайдера) и используется техподдержкой вообще в любой ситуации.
Это можно понять – обычно инженер техподдержки предпочитает быть в равных условиях с клиентом, а сама техподдержка обычно использует только самые свежие версии прошивок своих приборов.
Способ определения ошибок в прошивке: если проблема не проявляется на этом же приборе, прошитом другой версией прошивки (причем в различных случаях может помочь как обновление прошивки до свежей версии, так и откат до более старой), тем же пользовательским проектом и находящимся в тех же условиях эксплуатации – то, вероятно, причиной наблюдаемой ошибки является ошибка прошивки. В этом случае следует связаться с производителем ПЛК для получения рекомендаций по решению проблемы.
В значительном количестве случаев ПЛК программируются в специализированных средах разработки (IDE) на языках стандарта МЭК 61131-3. Некоторые производители сами разрабатывают IDE для своих ПЛК (например, TIA Portal от Siemens, RSLogix 5000 от Rockwell Automation, КОНГРАФ от МЗТА и т.д.), другие же лицензируют «вендоро-независимые» IDE (CODESYS, ISaGRAF, MasterSCADA 4D).
Созданный в IDE проект загружается в контроллер, где его выполнение обеспечивает система исполнения (runtime). Рантайм обычно также включает в себя библиотеки, конфигурационные файлы, сервисы для отладки и другие элементы инфраструктуры, которые упрощают разработку и отладку ПО.
Ошибки в среде исполнения
И среда программирования, и система исполнения могут содержать ошибки. Ошибки IDE обычно отловить довольно просто – они проявляются в виде сообщений об ошибках, неактивности
отдельных кнопок и т.д.
Ошибки рантайма отловить гораздо сложнее и проявляться они могут совсем по-разному – например, такой ошибкой может быть отсутствие возможности подключения к контроллеру, сброс значений энергонезависимых переменных в начальные значения после перезагрузки устройства (да, мы уже использовали этот пример в пункте про ошибки прошивки – но причиной подобной ошибки могут быть и проблемы рантайма), неработоспособность конкретного функционала (например, определенных коммуникационных драйверов) и т.д.
При разработке проекта для ПЛК пользователь может допустить ошибки. Проявления этих ошибок могут быть самыми разнообразными – спорадическая перезагрузка контроллера, некорректное выполнение алгоритма, срабатывание сторожевого таймера из-за исключений и т.д.
Способ определения ошибок в проекте: если проблема не проявляется на этом же приборе c той же версией прошивки, находящимся в тех же условиях эксплуатации, но с другой версией пользовательского проекта (например, более ранней версией или «пустым» тестовым проектом) то, вероятно, причиной наблюдаемой ошибки являются ошибки в проекте. В этом случае пользователю следует приступить к отладке.
Грамотный подход к разработке проекта
Также упростить отладку может грамотный подход к разработке проекта:
наличие детализированного ТЗ;
следование корпоративным или иным стандартам разработки ПО;
регулярное и тщательное тестирование по ходу разработки (когда проект сначала несколько недель пишется «в стол» и только потом запускается на реальном оборудовании – отладка может стать довольно мучительным занятием). Оптимальным, на наш взгляд, вариантом является совмещение модульного тестирования (для отдельных функциональных блоков и других законченных фрагментов приложения) и интеграционного (тестирование всего проекта в рамках системы – с подключением периферии, имитаций условий эксплуатации с помощью генерации помех и т.д.).
Пример ошибки в проекте CODESYS V3.5
Очень часто условия эксплуатации оборудования на промышленных объектах сильно отличаются от офисных. Эти условия можно разделить на две основные группы:
условия окружающей среды (температура, влажность, вибрация, механическое
воздействие);
помехи (кондуктивные, импульсные, радиопомехи и т.д.).
Способ определения ошибок, связанных с условиями эксплуатации и человеческим
фактором: если проблема не проявляется на этом же приборе c той же версией прошивки и тем же проектом, но находящемся в других условиях эксплуатации (например, офисных условиях вместо промышленных) – то, вероятно, причиной наблюдаемой ошибки являются особенности внешней среды объекта или человеческий фактор.
Последний из известных нам типов ошибок – это ошибки, которые, как ни странно, не являются ошибками. В некоторых случаях пользователь может принять за ошибку предсказанное поведение ПО. Особенно это характерно для проектов, для которых отсутствует ТЗ – пользователь может считать, что опрос «слишком медленный», но в реальности такой период опроса может просто являться данностью для конкретных slave-устройств или коммуникационных драйверов.
Еще один пример – ошибки в логе контроллера в CODESYS V3.5, приведенные на этом скриншоте:
Пример «ошибок» в логе CODESYS V3.5, связанных с отсутствием сертификатов HTTPS
С уважением, Гридин Семен
