Программа ПЛК живёт годами. Её читают не только авторы: наладчики, электрики, следующий программист. Плохая структура превращает простую правку в многочасовой разбор, а хорошая — позволяет найти причину за минуты. Структура — это не эстетика, а стоимость владения.
Уровни программы
- Ввод-вывод: чтение датчиков, запись выходов.
- Обработка сигналов: фильтрация, масштабирование, диагностика.
- Логика: блокировки, последовательности, режимы.
- Интерфейс: HMI, сообщения, уставки.
- Диагностика: журнал, счётчики, контроль связи.
Разделение по уровням позволяет менять один слой, не ломая остальные.
Модульность
Функциональные блоки и функции для повторяющихся операций: привод, клапан, дозатор, ось. Один блок — одна ответственность. Тогда исправление в одном месте применяется везде, а не копируется по всей программе.
Именование
Правило: имя должно отвечать на вопрос «что это». PrivodPodachi_Perezgruzka понятнее, чем M12.3. Для сигналов полезно включать направление и зону: DI_Conveyor_Ready, DO_Pump_Start. Единицы измерения — в имени или комментарии: Pressure_bar.
Режимы работы
Явно разделяйте: ручной, автоматический, наладочный, аварийный. Каждый режим должен иметь понятные условия входа и выхода, а также блокировки, которые не позволяют включить несовместимые действия. Неявные режимы — источник опасных ситуаций.
Обработка ошибок
Ошибки должны быть классифицированы: предупреждение, останов, авария. Для каждой — определённая реакция. Не стоит «глотать» ошибки: если датчик отказал, программа должна знать об этом, а не работать с фиктивным значением.
Комментарии
Комментарий объясняет «почему», а не «что». Код показывает, что происходит; комментарий — зачем так сделано. Особенно полезны комментарии к неочевидным блокировкам и к расчётам с коэффициентами.
Версионирование
Каждая версия программы должна быть идентифицируема: номер, дата, список изменений. Перед правкой — резервная копия. В идеале — система контроля версий или хотя бы архив с понятными именами. «Финальная_новая_2» — плохой способ хранения.
Документация
Схема, таблица сигналов, описание режимов, список сообщений. Документация обновляется вместе с программой, иначе она вредит больше, чем помогает. Проверка: может ли новый человек разобраться по документации без автора.
Типичные ошибки
- «плоская» программа на тысячи строк;
- имена вида M12.3;
- копирование блоков вместо функций;
- неявные режимы;
- отсутствие обработки ошибок;
- версии «финал_финал»;
- документация «потом».
Итог
Хорошая структура программы — это вложенные уровни, модули, понятные имена, явные режимы, обработка ошибок, комментарии и версии. Всё вместе снижает стоимость поддержки и риск аварий при изменениях.
Частые вопросы
Нужны ли функциональные блоки?
Да, для повторяющихся операций.
Как называть переменные?
По смыслу, с единицами измерения.
Сколько комментариев?
Столько, чтобы объяснить «почему».
Как хранить версии?
С номерами и списком изменений.
Что важнее — структура или скорость?
Структура окупается при первой правке.
Как начать наводить порядок
Не переписывайте всё сразу. Начните с имён: переименуйте ключевые сигналы и добавьте комментарии к блокировкам. Затем выделите одну повторяющуюся операцию в блок. Постепенно программа станет читаемой, а риск при правках снизится.
Про ревью
Даже короткое ревью вторым специалистом находит ошибки, которые автор не видит. Полезно проверять не только логику, но и имена, обработку ошибок и документацию. Это дешевле, чем исправлять на пуске.
Про передачу проекта
Если программу передают другому подрядчику, комплект должен включать исходники, схему, таблицу сигналов, описание режимов и версии. Без этого сопровождение начинается с восстановления по догадкам.
Про типичные конфликты
Программист хочет гибкости, наладчик — простоты, эксплуатация — стабильности. Хорошая структура учитывает всех: параметры вынесены в интерфейс, логика защищена от случайных изменений, диагностика понятна. Это результат договорённостей, а не только техники.
Про обучение новых сотрудников
Программа с понятными именами и документацией позволяет новому человеку разобраться за дни, а не недели. Это прямой экономический эффект структуры, который редко считают, но он реален.
Про итог для практики
Структура программы определяет, сколько будет стоить каждая следующая правка. Уровни, модули, имена и версии — инвестиция, которая окупается при первом же изменении.
Как оценить свою программу
Простой тест: откройте случайный участок и попробуйте объяснить, что он делает, за минуту. Если не получается, структура требует внимания. Второй тест: попросите коллегу найти, где включается конкретный выход. Если он ищет дольше пары минут — имена и структура не помогают.
Про постепенные улучшения
Не нужно переписывать всё: начните с одного модуля, доведите его до понятного вида и используйте как образец. Через несколько итераций программа станет однородной.
Про шаблон проекта
Полезно иметь собственный шаблон: структура папок, набор блоков, стиль имён, заготовки сообщений. Новый проект начинается не с пустого файла, а с проверенной основы. Это экономит время и снижает разнобой между проектами.
Про код-ревью чек-лист
Проверьте: имена понятны, блокировки явные, ошибки обрабатываются, режимы разделены, версия зафиксирована. Пять пунктов, которые ловят большинство проблем сопровождения.
Про выбор языка
Мнемоника удобна для логики, структурный текст — для расчётов, функциональные блоки — для повторяемых узлов. Смешивать всё в одном месте не стоит: читаемость падает. Выбирайте язык под задачу, а не под привычку.
Про взаимодействие с электриками
Схема и программа должны использовать одинаковые обозначения. Если в схеме Q1.3, а в программе PumpStart, поиск неисправности усложняется. Договорённость об именах между проектировщиком и программистом экономит время всем.
Про итог по сопровождению
Программа без структуры живёт, пока её автор рядом. Программа со структурой живёт дольше.
Про частые вопросы
«Нужно ли документировать каждую строку?» — нет, документируйте решения. «Сколько модулей делать?» — столько, чтобы каждый отвечал за одну функцию. «Как быть с наследием?» — улучшать постепенно, а не переписывать всё.
Про типичную ошибку проекта
Экономят на именах и документации, чтобы «успеть к сроку». Через полгода каждая правка занимает втрое больше времени. Стоимость владения закладывается с первого дня.
Про итог для команды
Единый стиль делает программу понятной любому участнику. Это особенно важно, когда проект ведут несколько человек.
Про хранение исходников
Исходники — часть производственного актива. Храните их отдельно от машины, с резервной копией. Потеря исходников означает, что любая правка начнётся с восстановления логики по поведению.