Системное формирование циклических технологических процессов, страница 4

номером;

текстом сообщения, выдаваемого оператору;

действием (командой управления процессом выполнения операций либо правилом преобразования событий);

обрабатываемыми данными;

проверяемым условием;

правилами перехода в новые позиции.

Из изложенного вытекают следующие виды связей между позициями:

- временные (через временные события);

- параметрические (через статические события);

- управляющие (через динамические события);

- информационные (через данные).

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

- правил планирования реального времени;

- сценария диалога оператор - система автоматизации;

- правил планирования выполнения операций обработки данных.

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

В соответствии с выбранной структурой системы исходных данных  для их подготовки используется метод событийной декомпозиции [14,49], базирующийся на следующих предположениях:

- проектирование процессов осуществляется в направлении "извне вовнутрь", т.е. от хода реального времени, команд оператора-технолога и хода ЦТП к прикладным процессам;

- система автоматизации с УВМ рассматривается как устройство переработки событий (в том числе и команд оператора) с помощью операций.

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

Для облегчения декомпозиции общего процесса функционирования АСУ ЦТП предусмотрены различные способы графического и табличного представления результатов.

Методику декомпозиции рассмотрим на иллюстративном примере. Алгоритм планирования реального времени конструируется поэтапно, в соответствии с числом временных горизонтов. Рассмотрим метод подготовки ИД на примере 1-го временного горизонта, в частности, интервала времени, соответствующего временному событию Д2 (фаза "Загрузка").

В позициях 500, 700 (рис.1.1.4) система управления ожидает наступления временного события Д2 (начала фазы "Загрузка").

Если событие Д2 наступило, оно преобразуется в динамическое событие С1 и система переходит в позицию 910, иначе, (при событии аа) выдерживается пауза 1 с. и контроль наличия события Д2 повторяется. Таким образом, позиция 910 будет достигнута в момент начала фазы "Загрузка" с точностью 0,...,1 с.

Аналогично в позиции 910 фиксируется начало интервала опроса датчиков, соответствующего событию Д5. Момент завершения этого интервала фиксируется в позиции 1200, а завершение фазы "Загрузка" - в позиции 1100. Дополнительно в виде прямоугольного блока изображены действия, подлежащие детализации на следующих этапах декомпозиции. Эти действия система должна выполнять в интервалах времени, соответствующих событиям Д2 - Д5, т.е. между позициями 910 и 1200.

Кроме графического представления правил функционирования АСТД в реальном времени в форме диаграммы позиций, они могут быть представлены в форме функциональной схемы и спецификаций [32].

Сценарий диалога проектируется путем детализации и конкретизации полученных правил планирования реального времени в следующем порядке:

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

в позициях, требующих ответа (квитирования), предусматривают выполнение стандартной операции ОПЕРАТОР ввода команды оператора по инициативе системы  (команды рассматриваются как динамические события);

предусматривают переходы в следующие позиции в зависимости от введения команд;

в новых позициях при необходимости запоминают команду оператора путем преобразования ее в статическое событие.

Оператор имеет также возможность вводить команды по собственной инициативе. Такие команды воспринимаются системой как статические события, порождаемые операцией ОПЕРАТОР.

Для описания реакций на такие команды в соответствующих позициях:

предусматривают преобразование статических событий-команд в динамические;

описывают переходы в новые позиции в зависимости от исхода преобразования (т.е., наличия или отсутствия команды).

Расшифруем выполнение операции "Ввод Х" (рис.1.1.4), т.е. введем позицию 1120, в которой по инициативе системы выдается ответ оператору и принимается его квитирующая команда "ДА".

Аналогично проводится детализация при диалоге по инициативе оператора.

Алгоритм планирования выполнения функций получается путем детализации и конкретизации полученного ранее сценария диалога оператор-система в условиях реального времени. Схема декомпозиции следующая:

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

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

в) для каждой вновь введенной позиции повторяют пп. 2,3.

На заключительном этапе проводят статический анализ структуры процессов и динамический - имитационное моделирование.

Проектирование компонентов

Эта процедура определяется ТЗ на проектирование компонента, которое генерируется при проектировании процессов. На этом уровне отдельные действия описываются как вызовы подпрограмм.

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

В конечном итоге получают:

- формальное описание логической структуры программы, задающей ее алгоритм с точностью до вызовов подпрограмм, обращений к операционной системе, СУБД и т.д.;

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