Природа ошибок может быть самой разнообразной, и первое, что должен сделать разработчик, столкнувшись с ошибкой – классифицировать её. В рамках АСУ ТП можно выделить следующие характерные типы ошибок:
• аппаратные неисправности;
• ошибки в прошивке;
• ошибки в системе исполнения/среде программирования;
• ошибки в пользовательском проекте;
• ошибки, вызванные внешними условиями и человеческим фактором;
• ошибки, которые не являются ошибками.
Аппаратные неисправности могут возникать как по вине производителя (например, из-за непропая элементов платы на производстве), так и по вине пользователя (например, случайно подали 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 обычно отловить довольно просто – они проявляются в виде сообщений об ошибках, неактивности отдельных кнопок и т.д. Ошибки рантайма отловить гораздо сложнее и проявляться они могут совсем по-разному – например, такой ошибкой может быть отсутствие возможности подключения к контроллеру, сброс значений энергонезависимых переменных в начальные значения после перезагрузки устройства (да, мы уже использовали этот пример в пункте про ошибки прошивки – но причиной подобной ошибки могут быть и проблемы рантайма), неработоспособность конкретного функционала (например, определенных коммуникационных драйверов) и т.д.
Как и в случае прошивок – обычно производителя ПЛК регулярно выпускают обновления для своих IDE и рантайма. Если вы подозреваете, что наблюдаемая ошибка связана с ними – то вам следует связаться с технической поддержкой производителя и уточнить, известна ли она им и не была ли исправлена в одной из следующих версий ПО. Вы должны понимать, что даже если производитель ПЛК не занимается разработкой своей IDE/рантайма, а использует по лицензии ПО другой компании – то он все равно имеет контакты с лицензиаром (через OEM-техподдержку, доступ к баг-трекеру и т.д.), и может получить информацию о вашей ошибке или же передать информацию о ней разработчикам для последующего исправления.
При разработке проекта для ПЛК пользователь может допустить ошибки. Проявления этих ошибок могут быть самыми разнообразными – спорадическая перезагрузка контроллера, некорректное выполнение алгоритма, срабатывание сторожевого таймера из-за исключений и т.д. Способ определения ошибок в проекте: если проблема не проявляется на этом же приборе c той же версией прошивки, находящимся в тех же условиях эксплуатации, но с другой версией пользовательского проекта (например, более ранней версией или «пустым» тестовым проектом) – то, вероятно, причиной наблюдаемой ошибки являются ошибки в проекте. В этом случае пользователю следует приступить к отладке. Большинство современных сред разработки предоставляют инструменты, упрощающие процесс отладки. В п. 3 мы расскажем о таких инструментах, имеющихся в среде CODESYS V3.5. Также упростить отладку может грамотный подход к разработке проекта: • наличие детализированного ТЗ; • следование корпоративным или иным стандартам разработки ПО; • регулярное и тщательное тестирование по ходу разработки (когда проект сначала несколько недель пишется «в стол» и только потом запускается на реальном оборудовании – отладка может стать довольно мучительным занятием). Оптимальным, на наш взгляд, вариантом является совмещение модульного тестирования (для отдельных функциональных блоков и других законченных фрагментов приложения) и интеграционного (тестирование всего проекта в рамках системы – с подключением периферии, имитаций условий эксплуатации с помощью генерации помех и т.д.)
Очень часто условия эксплуатации оборудования на промышленных объектах сильно отличаются от офисных. Эти условия можно разделить на две основные группы:
• условия окружающей среды (температура, влажность, вибрация, механическое воздействие);
• помехи (кондуктивные, импульсные, радиопомехи и т.д.).
Обычно эти вопросы регламентируются отраслевым стандартами. Если требования этих стандартов не выполняются (например, если организация заземления и прокладка сигнальных линий не соответствует требованиям ПУЭ) или на объекте используется оборудование, характеристики которого не соответствуют его условиям – то это может стать причиной появления ошибок в работе приборов (например, периодических ошибок передачи данных во время действия на линию связи электромагнитной помехи).
Кроме того, эксплуатацией оборудования обычно занимается персонал объекта (операторы, дежурные, инженеры КИПиА и т.д.). Некорректные действия персонала также могут являться причиной ошибок. Очевидно, что эксплуатацией оборудования должны заниматься люди с соответствующей квалификацией и прошедшие обучение/инструктаж. Характерный пример из этой статьи на Хабре:
«В пики жары пропадает связь с одним из локальных серверов. На объектах таких серверов много, смонтированы они довольно компактно в техпомещениях, и везде сложности с охлаждением, причём часто используется внешнее принудительное. Ну то есть мощный вентилятор, направленный прямо на стойку. Коллеги называют это модным словом «фрикулинг», но это именно вентилятор, направленный на стойку.
Но случается такое не каждый день по жаре, а примерно только каждый второй. Начинаем разбираться — иногда, как в детективе: оказывается, там в этом же помещении работают два человека. Один специалист знает, что такое стойка, или близко догадывается о таинственной связи мигающих лампочек и вентилятора. Второй специалист — бабушка. Она не знает. И когда жара доходит до максимума, бабушка чувствует thermal threshold, затем берёт и поворачивает вентилятор на себя. Потому что её маленький вентилятор не такой мощный.
Логичное следствие — бабушка охлаждается, стойка перегревается. Дальше по порогу температуры происходит штатный thermal shutdown. А у нас — очередной тикет.»
Способ определения ошибок, связанных с условиями эксплуатации и человеческим фактором: если проблема не проявляется на этом же приборе c той же версией прошивки и тем же проектом, но находящемся в других условиях эксплуатации (например, офисных условиях вместо промышленных) – то, вероятно, причиной наблюдаемой ошибки являются особенности внешней среды объекта или человеческий фактор.
Последний из известных нам типов ошибок – это ошибки, которые, как ни странно, не являются ошибками. В некоторых случаях пользователь может принять за ошибку предсказанное поведение ПО. Особенно это характерно для проектов, для которых отсутствует ТЗ – пользователь может считать, что опрос «слишком медленный», но в реальности такой период опроса может просто являться данностью для конкретных slave-устройств или коммуникационных драйверов.
Еще один пример – ошибки в логе контроллера в CODESYS V3.5, приведенные на этом скриншоте:
Пользователь может интуитивно воспринять такие сообщения как индикацию каких-то проблем с контроллером или проектом, но они являются просто констатацией факта отсутствия в ПЛК сертификатов HTTPS для сервера web-визуализации. В случае необходимости эти сертификаты могут быть сгенерированы или импортированы в ПЛК, но их отсутствие влияет только на невозможность подключения к web-визуализации по HTTPS. Зачастую отличить настоящую ошибку от «ошибки» довольно сложно – этот навык приходит лишь с опытом использования конкретных устройств и изучения особенностей их работы.
Источник: https://oscat.ru/?p=382