Действия по обслуживанию и реализация хороших программ

Все компьютерные программные средства (независимо от того, для чего они используются — для обработки данных, в коммерческих целях или для управления) должны:

• надежно выполнять свои функции;
• работать предсказуемым образом, даже если входные данные повреждены (такое поведение на жаргонном языке называется «ро-бастным», т. е. устойчивым к нарушениям исходных данных);
• быть простыми для понимания и сопровождения.

Первое из этих требований очевидно, и большинство программ для ПЛК будут (как мы надеемся) выполнять ту работу, ради которой они были созданы. Два других требования, однако, часто игнорируются, и их важность не учитывается до тех пор, пока не возникнут определенные проблемы спустя месяцы (или даже годы) после того, как система сдана в эксплуатацию, а группа проектировщиков расформирована.

Робастная программа имеет внутренние средства защиты от испорченных данных, причиной которых могут быть повреждения датчиков или ошибочные действия оператора с клавиатурой. На рис. 3.14 приведен пример системы, действующей на предприятии, где работает автор. Заказчику поставляется материал определенного веса, но разрезается он по длине, измеряемой количеством импульсов, поступающих от вращающихся валков. Оператор вводит желаемый вес, и ПЛК преобразует его в эквивалентную длину. Полученный после резки материал взвешивается, его вес сравнивается с желаемым значением, а ошибка используется для коррекции следующей резки.

Ошибочные данные могут появиться в различных местах этой системы: это ввод оператором неправильного значения веса, искажения при считывании показаний системы взвешивания, электрические помехи, наложенные на импульсы от вращающихся валков, — этот перечень можно было бы продолжить. Каждый из этих случаев может вызвать проблемы, если полученные входные искаженные данные были обработаны как якобы правильные.

Необходимо использовать некоторый вид проверки. Оператор в системе на рис. 3.14 может вводить значения веса только в определенном диапазоне, а для точной настройки длины используются лишь те данные системы взвешивания, которые находятся в пределах «окна», задаваемого как определенная доля от заданного веса. Ошибка оператора при вводе или вес. выходящий за пределы «окна», идентифицируются как аварийные ситуации. Подобным же образом можно рассчитать временное окно для отрезания: когда инициируемый импульсами момент резки попадает в пределы этого окна, тогда процесс идет в нормальном режиме, если же истекает максимальное время, а импульсы не дают разрешения на резку, то появляется сигнал об аварийной ситуации.

Естественно, что робастная программа является более длинной и сложной; около 25% всей программы для системы на рис. 3.14 используется в нормальном режиме, а остальные 75% относятся к ненормальным ситуациям, которые редко (если вообще когда-либо) могут возникнуть. Тем не менее защита необходима, чтобы операторы и производственный персонал были уверены в надлежащей работе системы.

Программисты иногда упрямствуют в правоте по поводу своего изящества в попытках минимизации количества используемых инструкций. Таким тенденциям следует противостоять в большей степени, чем в коммерческом программировании, поскольку реальный процесс и сопровождение программы подлежат обслуживанию людьми, которые должны ясно понимать все операции. «Делай как можно проще» — таким должен быть девиз; не используйте сложные приемы и старайтесь избегать самых бестолковых инструкций, которые находятся в наборе данного ПЛК. Помните, что какой-то неквалифицированный работник захочет посмотреть, как все это работает, где-то в три часа ночи.

На рис. 3.15 приведен пример из моей практики, показывающий, как не надо писать программу для ПЛК. В этом примере один ПЛК управляет тремя идентичными объектами. Программист начал с создания мультиплексора, представляющего собой трехпозиционный галетный переключатель, с помощью которого все входные данные для одного выбранного объекта записывались во внутренние ячейки памяти. Одна программа (общая для всех трех объектов) обрабатывала данные, хранящиеся во внутренней памяти, формировала выходные данные и снова записывала их во внутреннюю память, чтобы затем вывести их во внешние устройства через демультиплексор. Мультиплексор и демультиплексор пошагово переключались при каждом прогоне программы, так что программа имела дело с объектом А при прогоне 1, с объектом В при прогоне 2, с объектом С при прогоне 3, затем возвращалась снова к объекту А при прогоне 4 и т. д. Такое решение было изящным и экономило память, но делало невозможным понять причину возникновения ошибки и обнаружить ее. В нормальном режиме нельзя было проследить за выполнением операций, и все, что можно было наблюдать на терминале для программирования, это расплывшееся пятно, так как мультиплексоры циклически подключали ПЛК к различным объектам. Когда в каком-либо объекте возникала неисправность, мультиплексоры должны были быть подключены именно к этому объекту (и отключены от исправных объектов), чтобы дать возможность наблюдать ход процесса. Подобных приемов следует избегать (и надо заметить, что данная программа была полностью изменена в течение года).

Программа по возможности должна также отражать режим работы объекта. На рис. 2.48 была приведена распространенная ситуация, когда с помощью переключателя, расположенного на пульте управления, можно заставить работать либо один, либо оба насоса. В целях экономии был использован далеко не лучший переключатель. Наиболее простой программой является однозвенная схема на рис. 2.48 (г), но я полагаю, что двухзвенная схема на рис. 2.48 (в) более понятна для человека, впервые встречающегося с подобной ситуацией.

Для большей ясности программа должна иметь хорошую документацию. Большинство ПЛК могут быть запрограммированы автономно на компьютере в MSDOS. причем необходимо предусмотреть средства для описания отдельных сигналов и добавления комментариев, поясняющих, как работает программа. Эту возможность следует использовать в полной мере; сравните, например, недокументированную программу на рис. 8.38 с ее аннотированной версией на рис. 8.39.

Одно из общепринятых правил программирования гласит: «Когда вы помещаете в память некоторые данные, обязательно запишите, куда вы их поместили». Не сделать этого — все равно, что засунуть что-то в шкаф и спустя несколько недель быть не в состоянии найти это. То. как используются входы, выходы и внутренняя память, должно быть зарегистрировано. В этом вопросе помощь могут оказать комментарии к программе; если вы выбрали внутренний бит памяти для аварийной сигнализации об опасном превышении температуры воды и в программе снабдили его комментарием «Выключить насос 1», то знайте, что тот же самый адрес, возможно, был использован дважды или где-то была нарушена схема распределения памяти.

Производители ПЛК предлагают пользователям карты распределения памяти и входов/выходов, подобные изображенной на рис. 3.16. К их использованию следует относиться со всей тщательностью. Программные средства, ориентированные на MSDOS, позволяют получать распечатку использования памяти, пример которой (для Allen Bradley PLC-5) приведен на рис. 3.17.

Если взаимодействие между данными в программе является сложным, то предпочтительно составлять диаграммы потока данных наподобие представленной на рис. 3.18. Такие диаграммы помогают планировать программу и очень полезны в ее сопровождении и обнаружении ошибок.

Всегда надо ставить цель насколько возможно облегчить работу людей, которые будут иметь дело с ПЛК. Одним из способов достижения этого является постоянство в стиле программирования. Если пусковое устройство двигателя было запрограммировано опре-

деленным образом в одном месте программы (например, это может быть проверка отключения защиты двигателя и действия вспомогательного контакта), этот стиль и метод надо дублировать и для всех остальных пусковых устройств. Постоянство стиля особенно важно тогда, когда различные части программы пишутся разными людьми, и здесь лучше всего разработать свой «фирменный» стиль. Одним из примеров такого подхода является разработанная в компании Ford концепция EDDI, рассматриваемая в Практические вопросы.