Использование современных эффективных методов и способов проверки программ АСУ с целью обнаружения критических ошибок способствует ускорению процесса отладки и, как следствие, более качественной работе системы автоматизации.

Автором предлагается следующий способ проверки программного кода АСУ, основанный на концепции семантического, или смыслового, анализа системы продукционных правил (СПП) многомерного логического регулятора (МЛР) с переменными в виде совокупности аргументов двузначной логики.

МЛР, разработанный автором, является разновидностью нечётких регуляторов (НР), где каждому терму непрерывной физической величины на каком-либо отрезке числовой оси отводится отдельный участок, который не перекрывается соседними термами.

Это позволяет каждое значение непрерывной физической величины представить одним и только одним термом T, что наиболее адекватно идентифицирует данную величину в виде совокупности аргументов двузначной логики.

На рис. 1 представлена упрощенная блок-схема МЛР, где И₁, И₂, …, И_n и Д₁, Д₂, …, Д_k – интервализаторы и деинтервализаторы МЛР соответственно, объединенные в блоки БИ и БД; X₁, X₂, …, X_n и Z₁, Z₂, …, Z_k – входные и выходные переменные МЛР соответственно; БЛВ – блок логического вывода МЛР; T (X₁), T (X₂), …, T (X_n) и T (Z₁), T (Z₂), …, T (Z_k) –номера термов, значения которых равны логической единице; N_тек – идентификационный номер (ID-номер) продукционного правила в текущий момент t; # – составляющая ID-номера правила, формируемого из порядковых номеров термов T (X₁), T (X₂), …, T (X_n) и T (Z₁), T (Z₂), …, T (Z_k) [1].

Рисунок 1 – Упрощенная блок-схема МЛР

Семантический анализ системы правил МЛР с целью выявления пустых, противоречащих и дополняющих друг друга правил, а также неиспользуемых термов, основан на концепции, состоящей из следующих основных положений [2]:

а) если продукционное правило не содержит термы переменных МЛР, то это аварийное правило или правило защиты. В МЛР может быть только одно такое правило;

б) если правило или только консеквент (заключение) не содержит термы переменных МЛР, то это пустое правило;

в) если правило A соответствует правилу B, то это повторяющиеся правила;

г) если консеквенты правил A и B идентичны, но их условные части (антецеденты) – нет, то это взаимодополняющие правила. Их можно и нужно объединять при возможности;

д) если антецеденты правил A и B идентичны, но при этом значения их консеквентов не равны друг другу и не содержат одинаковых номеров термов для каждого из используемых блоков МЛР, то это противоречащие правила, иначе это взаимодополняющие правила;

е) если правило A не равно правилу B, то:

– если условные части правил не содержат одинаковых порядковых номеров термов для каждого из используемых блоков, то правила A и B – нормальные, т. е. они удовлетворяют структуре МЛР;

– если правила A и B не нормальные, но при этом значения их консеквентов не равны друг другу и не содержат одинаковых порядковых номеров термов для каждого из блоков МЛР, то это противоречащие правила, иначе это взаимодополняющие правила.

Далее введем понятия полной, частично полной и неполной системы правил.

Предположим, что значение переменной x может меняться в диапазоне [0; 100]. Тогда для системы правил S (здесь и далее примеры программ приведены в синтаксисе языка Pascal):

if x < 70 then begin <блок операторов 1> end

else if x < 80 then begin <блок операторов 2> end

else begin <блок операторов 3> end;

термы переменной x соответствуют следующим интервалам: [0; 70), [70; 80) и (80; 100].

Такая система правил является полной, то есть она описывает все возможные действия при всех возможных вариантах значений переменной x.

В общем виде полная система правил S_п для непрерывной переменной x, представленной совокупностью n термов T, имеет вид

if T1 then begin <блок операторов 1> end

else if T2 then begin <блок операторов 2> end

…

else begin <блок операторов n> end;

СПП S_чп для непрерывной переменной x является частично полной, если её можно считать полной, но при этом в ней отсутствует проверка истинности некоторых термов. Например, в системе правил S:

if T1 then begin <блок операторов 1> end

else if T3 then begin <блок операторов 2> end

…

else begin <блок операторов n – 1> end;

отсутствует проверка истинности терма T₂, но, если нахождение x в пространстве значений данного терма не влияет на значения других переменных АСУ, то такая система правил является частично полной.

Если система правил не включает все возможные действия при всех возможных вариантах значений переменной x, то она является неполной и обозначается как S_н.

Решить, является ли некоторая СПП полной, частично полной или неполной может только эксперт [5].

Предлагаемый автором способ анализа программ АСУ заключается в следующем:

1. Для того чтобы в полной мере использовать преимущества описанных выше подходов, следует представить АСУ в виде МЛР, а все ее параметры (переменные) интерпретировать эквивалентной совокупностью аргументов двузначной логики (термами).

2. Выделить в программном коде АСУ системы правил для каждой из её переменных, термы которых содержатся в антецедентах правил.

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

4. Выполнить семантический анализ МЛР, согласно приведенной выше концепции.

Шаги п. 1 и п. 2 можно объединить.

Рассмотрим пример использования данного способа для АСУ дистилляционной колонны, важной составляющей которой является конденсатор дистилляции (КДС). Автоматическое поддержание температурного режима колонны выполняется путём изменения расхода пара в дистиллер [3]. Блок-схема алгоритма регулирования представлена на рисунке 3, где T_КДС – температура газа из КДС [4].

Рисунок 3 – Блок-схема алгоритма регулирования температурного режима колонны

Пример интерпретации T_КДС совокупностью термов представлен на рис. 4, где термы T₂, T₃, T₅ и T₆ позволяют осуществить более плавное регулирование, а термы T₁ и T₇ – какие-либо защитные действия.

Рисунок 4 – Пример интерпретации T_КДС совокупностью термов

Шаги п. 3 и п. 4 можно выполнять в любой последовательности и неоднократно.

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

Рисунок 5 – Скриншот программы семантического анализа системы автоматизированной разработки многомерных логических регуляторов

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

Рассмотрим часто встречающиеся проблемные ситуации в коде программ. Для упрощения понимания все примеры программ приведены на языке Pascal.

1) переменная (логического или числового типа) многократно (n раз) инициализируется на некотором участке (фрагменте) программы без использования ее значения в каком-либо выражении (логическом или функциональном). Например,

a := 5;

b := 7;

a := 8;

…

a := 9;

В такой ситуации возможны следующие варианты:

а) переменная не связана с каким-либо внешним по отношению к программе параметром и/или базой данных. В данном случае можно утверждать, что первые n –1 инициализаций избыточны и следует оставить лишь последнюю (n) инициализацию данной переменной;

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

в) операторы инициализации следуют один за другим без каких-либо других операторов между ними. В данном случае следует поступить так же, как в п. 1, а), т. е. удалить первые n –1 инициализаций, т. к. иметь вес будет лишь последняя.

2) антецеденты продукционных правил условных операторов полностью идентичны друг другу. Например,

if a > 5 then inc(b);

…

if a > 5 then dec(c);

В этой ситуации возможны следующие варианты:

а) условные операторы следуют один за другим без каких-либо других операторов между ними. Если переменные, содержащиеся в антецедентах продукционных правил второго и последующих операторов, не содержатся в консеквентах правил первого и предыдущих операторов соответственно, то можно утверждать, что это взаимодополняющие операторы и их следует объединить в один условный оператор. Иначе, это будут разные операторы.

Если операторы, приведенные выше, являются взаимодополняющими, то их объединение будет иметь вид

if a > 5 then

begin

inc(b);

dec(c);

end;

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

б) между условными операторами находится n других операторов. Для того чтобы отнести данные операторы к п. 2, а) необходимо выполнение следующих условий:

– переменные, включенные в антецеденты правил обоих условных операторов, не должны менять свои значения на всем участке программы между операторами;

– переменные, включенные в консеквенты правил второго и последующего операторов, не должны использоваться на протяжении всего участка программы между операторами.

3) консеквенты продукционных правил условных операторов полностью идентичны друг другу. Если антецеденты продукционных правил второго и последующего операторов не содержат переменных, значения которых могут меняться на всем промежутке программы между операторами, включая консеквенты их продукционных правил, то такие операторы можно объединить в один условный оператор путем дизъюнкции антецедентов.

Например, операторы

if a > 5 then inc(b);

if a < 9 then inc(b);

можно объединить в один условный оператор

if (a > 5) or (a < 9) then inc(b);

4) предусловия, постусловия или параметры операторов цикла полностью идентичны друг другу. Например,

while a > 5 do (или for i := 0 to 5 do)

begin

…

end;

…

while a > 5 do (или for i := 0 to 5 do)

begin

…

end;

В этой ситуации варианты будут аналогичны п. 2, а) и б).

5) переменные, значения которых изменяются в теле операторов цикла [3], одновременно используются в качестве их параметров (оператор for), в предусловиях или постусловиях (операторы while … do и do … while соответственно).

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

В подобной ситуации необходим строгий контроль над возможными вариантами значений переменных, способных дать начало бесконечному циклу, как, например, в случае

for i := 0 to 10 do

begin

…

dec(i);

…

end;

где переменная i на каждой итерации цикла одновременно увеличивает и уменьшает (в процессе выполнения оператора декремента dec(i)) свое значение на единицу.

В ряде случаев бывает полезен анализ значений, которые могут принимать переменные и которые по факту используются в антецедентах правил, что позволит выявить избыточные операторы и своевременно удалить их из программы.

Некоторые из описанных выше ситуаций можно избежать, используя современные версии компиляторов и сред разработки программ. Так, разработчики Pascal ABC и Embarcadero Delphi XE3 установили запрет по умолчанию на компиляцию программы при изменении в теле операторов цикла их параметров, как в примере, приведенном в п. 5.

В то же время следующий код в Pascal ABC (версия 2.0, сборка 529) и Embarcadero Delphi XE3 (version 17.0.4770.56661) был откомпилирован без ошибок:

i := -1;

while i < 0 do

begin

i := i – 0;

end;

В результате выполнения программ с указанным кодом будет запущен бесконечный цикл вычислений, способный привести к зависанию операционной системы.

Все перечисленные ситуации объединяет одно – это необходимость в разработке методов и/или правил, которых необходимо придерживаться для создания семантически верного программного кода. Автором предлагается использовать в процессе разработки программ методику анализа структуры многомерного интервально-логического регулятора (МИЛР), отличительной особенностью которого является [4, 5] строгое задание на начальном этапе проектирования системы автоматического регулирования интервалов значений, которые могут принимать переменные-параметры в процессе эксплуатации, что дает возможность просчитать все возможные ситуации и выявить повторяющиеся, взаимодополняющие или противоречащие друг другу операторы. Семантический анализ программ МИЛР при этом выполняется автоматически при помощи специального программного обеспечения [6].

Необходимость создания систем для автоматизированного проектирования и/или разработки МИЛР возникает вследствие высокой сложности программной реализации системы продукционных правил (СПП), которая напрямую зависит от количества термов, используемых для представления переменных [2].

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

Отличительной особенностью структуры МИЛР является отсутствие в ней элементов обработки продукционных правил. Так, в каждом цикле работы МИЛР в процессе сканирования значений непрерывных величин формируется ID-номер, или ключ, продукционного правила, используемый для определения комбинации значений управляющих воздействий в текущий момент t. Комбинации значений управляющих воздействий МИЛР хранятся в массиве или базе данных (зависит от технических характеристик используемых устройств автоматизации).

На рисунке 1 приведена блок-схема МИЛР с n входными параметрами X, k и m выходными параметрами Z и Y, где И₁, …, И_n – интервализаторы, а Д₁^(Z), …, Д_k^(Z) и Д₁^(Y), …, Д_m^(Y) – деинтервализаторы МИЛР; N_min, N_тек и N_max – минимальный, текущий и максимальный ID-номер продукционного правила в массиве значений управляющих воздействий в блоке логического вывода (БЛВ) с регулирующей и компенсационной СПП (РСПП и КСПП соответственно); # – элемент ID-номера продукционного правила БЛВ, формируемого из номеров термов T(X₁), …, T(X_n) и T(Z₁), …, T (Z_k).

Рисунок 1 – Блок-схема МИЛР с минимизированным временем отклика

В МИЛР, в связи со спецификой работы, взамен стандартных для нечетких регуляторов (НР) понятий “фаззификации” и “дефаззификации”, введены понятия “интервализации” и “деинтервализации”, определенные ниже [3].

Интервализация представляет собой процесс определения принадлежности значения непрерывной величины МИЛР тому или иному интервалу, входящему в диапазон значений данной величины.

Деинтервализация – процесс, обратный интервализации, то есть выделение требуемого значения непрерывной величины из интервала, входящего в диапазон значений данной величины.

Интервализаторы и деинтервализаторы МИЛР представляют собой блоки, реализующие процессы интервализации и деинтервализации соответственно.

ID-номера продукционных правил МИЛР с n входными, k и m выходными параметрами будут расположены в диапазоне от N_min до N_max. Правило, ID-номер которого равен 0 предназначено для контроля состояний непрерывных величин и называется “нулевым”, или аварийным, правилом.

На рисунке 2 изображена структурная схема системы автоматизированной разработки МИЛР “САР МИЛР”, разработанной автором (стрелками обозначены внутренние связи между отдельными блоками “САР МИЛР”, каждый из которых является самостоятельным элементом).

Рисунок 2 – Структурная схема системы автоматизированной разработки МИЛР

Редакторы блоков интервализации и деинтервализации предназначены для создания или редактирования параметров интервализаторов и деинтервализаторов непрерывных физических величин МИЛР с целью дальнейшего преобразования их кода в форматы языков программирования международного стандарта IEC 61131-3 [4].

Редактор правил и управляющих воздействий предназначен для создания и редактирования СПП МИЛР и выполняет следующие основные функции:

– создание и/или редактирование СПП МИЛР с учётом логических связей с редакторами интервализаторов и деинтервализаторов;

– интегрирование СПП в структуру МИЛР;

– проверка правильности вводимых с клавиатуры данных;

– преобразование программы МИЛР в форматы языков программирования, описанных в стандарте IEC 61131-3;

– графическое отображение СПП МИЛР.

Для создания СПП в редакторе реализован собственный графический язык программирования, получивший название STEP GRAPH и основанный на системе интервализаторов и деинтервализаторов МИЛР. При создании правила в редактор продукционных правил добавляются отрезки числовых осей всех входных блоков МИЛР, которые поделены на области, или термы, отмеченные красным цветом. В редактор управляющих воздействий при этом будут добавлены отрезки числовых осей всех выходных блоков МИЛР. Логические переменные будут представлены в виде отрезков, разбитых на две области, которые соответствуют состояниям “0″ и “1″ соответственно [5].

Принцип работы со STEP GRAPH базируется на создании продукционных правил путём выделения необходимых областей, или термов, переменных МИЛР [6]. Для этого надо кликнуть мышью по требуемой области отрезка числовой оси, при этом термы будут автоматически окрашены в зелёный цвет.

На рисунке 3 представлен скриншот главного окна “САР МИЛР”.

Рисунок 3 – Скриншот главного окна “САР МИЛР”

Проектирование и разработка МИЛР с использованием программы “САР МИЛР” позволяет снизить затраты времени в плане:

– создания систем интервализаторов/деинтервализаторов МИЛР с нужным числом, характером и порядком распределения термов непрерывных величин;

– создания и редактирования СПП в графическом языке программирования STEP GRAPH;

– проведения семантического анализа структуры МИЛР с целью выявления логических ошибок или отклонений от концепции построения;

– генерации программ МИЛР для промышленных контроллеров в формате языков программирования, описанных в международном стандарте IEC 61131-3.