Язык программирования (и ОС) ФОРТ (FORTH) Система “РАПС” или автоматизация по-русски.

Система “РАПС” или автоматизация по-русски. [http://raps-technol.narod.ru]

История возникновения проекта. (Почему автоматизация по-русски?). 
Базовые идеи предлагаемого Вашему вниманию проекта были разработаны авторами
в 89-92 г.г. прошлого века. Однако основные ее положения остаются актуальными
и на сегодняшний день. Концептуальные идеи появляются на свет, к счастью, несколько
реже, чем новые поколения “интеловских” процессоров. Так наиболее популярная
на сегодняшний день операционная система реального времени - QNX увидела свет
еще в 1982 году.

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

Однако взрывное развитие мощности вычислительных средств, связанное с их стремительным
вторжением в сферу бизнеса и развлечений, а также искусственно высокими финансовыми
вливаниями акционерного капитала в “высокие технологии” в ожидании сверхприбылей,
привело к тому, что были созданы все предпосылки для развития именно первого
направления. Разработчики средств автоматизации как бы питались “объедками с
барского стола”, им предлагались уже готовые технические решения которые они
и приспосабливали для своих
нужд. Так в сфере управления появились и РС-совместимые контроллеры и средства
связи на базе концепции построения глобальных сетей (Ethernet). Развитие аппаратно-программных
средств пошло, по нашему мнению, если не по тупиковой, то не по наилучшей из
ветвей. 

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

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

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

Главным препятствием на пути внедрения этого подхода можно считать отсутствие
развитых средств программирования распределенных систем, поскольку все силы были
брошены на ударное развитие первого направления.

И здесь нам, россиянам, предоставляется уникальная возможность восстановить статус-кво,
ибо наша техническая мысль остановилась именно в тот момент, когда предпочтение
отдавалось распределенным системам ( мир развивается по спирали, а в гонках по
кругу можно оказаться впереди лидера и отстав от него на 1 круг). 

Если вернуться в начало 90-ых годов, то в первый момент времени, когда на нас
обрушилась информационная волна, казалось, что действительно все, что только
можно было придумать, уже сделано “там у них”. Кроме того, до 1996 года соотношение
рубля и доллара установилось таким, что было вообще бессмысленно что-либо производить
и разрабатывать в нашей стране. Поэтому все это время мы находились в тени и
имели только возможность сравнивать наш проект с аналогичными разработками западных
фирм. За это время мы приобрели
опыт успешной реализации систем АСУ ТП на технических средствах большинства известных
производителей средств автоматизации. 

И вот теперь, спустя десять лет, мы берем на себя смелость сделать следующий
вывод. Хотя возможно на сегодняшний день наш проект уже и не блещет новизной
идей (многие из них за прошедшее время в той или иной форме уже реализованы в
других подобных системах), но если вспомнить время его возникновения, то надо
отдать должное тому, что “попадание” было почти стопроцентным. Если же говорить
о комплексном решении проблемы, то предлагаемый Вашему вниманию проект и на сегодняшний
день ничем не уступает, а с учетом
специфики нашего рынка и превосходит западные аналоги. Трудность его восприятия
заключается только в том, что он идет несколько в разрез с установившимися на
сегодняшний день “канонами” программистской мысли. Но возможно уже через несколько
лет вы получите нечто подобное, упакованное в красивую коробку с надписью “made
in …”, и те же люди, которые сегодня готовы поднять нас на смех будут с умным
видом говорить: “Да, вот это круто …”.

Почему наш проект был назван “автоматизация по-русски”? Это не дань псевдопатриотической
волне, захлестнувшей в последнее время наши средства массовой информации, а результат
трезвого анализа и поиска своего “места под солнцем”. Если попытаться проанализировать
наши самые выдающиеся достижения в области технической мысли, то можно сформулировать
следующий алгоритм успеха: взять самое лучшее, из всего известного на сегодняшний
день, и попытаться реализовать максимально простыми средствами. Именно таковыми
являлись,
например, танк Т-34 или автомат Калашникова. Поэтому главным лозунгом нашего
проекта стал девиз: “просто, еще проще, просто, насколько это возможно … еще
проще”. 

Мы попытались решить основные, на наш взгляд, проблемы, стоящие перед любым разработчиком
АСУ ТП. Назовем их три проклятия: проклятие поколений, проклятие программистов
и проклятие заказчика.

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

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

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

Далее мы предлагаем Вашему вниманию краткое изложение нашего варианта решения
этих проблем. 

2. Общие положения.

В самом общем виде Распределенная Аппаратно-Программная Среда (“Система РАПС”)
представляет собой идеологию построения программно и аппаратно совместимых информационно-управляющих
вычислительных систем промышленного и бытового назначения и включает в свой состав
средства для их проектирования, отладки и физической реализации. Ее главным отличием
от большинства западных аналогов является то, что она представляет собой не конгломерат
ранее разработанных языков и средств проектирования систем реального времени,
а единый системный подход, основанный на базовых понятиях теории управления.


Отличительными чертами предлагаемой системы являются: 

предоставление возможностей любому пользователю, знакомому с принципами организации
системы и правилами проектирования, разрабатывать и реализовывать аппаратно-программные
комплексы практически без привлечения профессиональных программистов; 
максимально возможная независимость проекта от конкретной аппаратной реализации,
позволяющая говорить о пожизненной гарантии работоспособности реализованной информационно-управляющей
системы; 
многократное сокращение затрат на проектирование за счет широкого использования
типовых проектных решений и типовых программных блоков; 
исключительная простота технической реализации, позволяющая организовать производство
на отечественных предприятиях, и дающая возможность полноценной эксплуатации
в условиях отсутствия налаженной системы сервисного обслуживания, с предоставлением
пользователю развитой системы диагностики; 
Первая задача решается предоставлением пользователю максимально широкого спектра
языковых средств. Эти средства включают в свой состав, как язык блок-схем, являющийся
де-факто самым общепринятым способом описания алгоритма и делающий любой, приведенный
в технической литературе, рисунок исходным текстом программы, так и Форт-компилятор,
представляющий собой машинно-независимый структурированный ассемблер. В процессе
проектирования пользователь может последовательно, шаг за шагом, описывать и
отлаживать программное
обеспечение, двигаясь от общей структуры к все более и более подробному описанию
ее составных частей.

Вторая задача решается путем использования в качестве базиса “виртуальной РАПС-машины”.
Ее основу составляет компактное, написанное в кодах ядро объемом 6-8 Кб, легко
переносимое на любой новый тип микропроцессора. Программное обеспечение проекта
(РАПС-процесс) оформлено в виде аппаратно-независимого “шитого кода”, и может
быть загружено в память любого вычислительного устройства, на котором установлена
РАПС-машина. Поэтому замена аппаратных средств не потребует сколько-нибудь значительной
переработки программной
части проекта. В идеале вы сможете просто извлечь одну процессорную плату, вставить
на ее место другую, более совершенную, и нажать кнопку “рестарт”. На этом процесс
модернизации будет успешно завершен. 

Кроме того, блочно-модульный принцип построения самого программного обеспечения
позволяет легко расширять и дополнять программную и аппаратную части проекта
уже в процессе функционирования системы, практически не затрагивая ранее созданные
фрагменты. Причем для этого совсем не обязательно привлекать специалистов участвовавших
в предыдущих этапах разработки. Если в вашем контроллере остались неиспользованные
ресурсы в виде свободных входов/выходов и памяти, а процессор загружен не на
все 100 процентов, Вы просто
разрабатываете на хост-машине новый программный фрагмент, дозагружаете его в
память контроллера и даете команду “включить фрагмент”. При этом Вам может даже
и не потребуется останавливать текущую работу контроллера. 

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

Особо следует выделить ориентацию на максимальное использование типовых программных
блоков и типовых проектных решений. Любая реализация автоматизированной системы
собирается из типовых элементов и узлов (датчиков, выключателей, вентилей, пускателей,
насосов и т.п.). Проектировщик просто выбирает из каталога те из них, которые
по своим параметрам наиболее соответствуют предъявляемым требованиям. Было бы
логично каждому такому типовому элементу поставить в соответствие типовой программный
блок (программу управления),
который раз и навсегда взял бы на себя все детали, связанные непосредственно
с управлением данным типовым элементом или узлом и который, в идеальном случае,
был бы написан самим производителем оборудования. В этом случае проектировщик,
параллельно с выбором типовых элементов и узлов, включал бы в программную часть
проекта соответствующие им типовые программные блоки. Это позволит избежать значительной
части программирования, связанной с управлением типовыми объектами. Пользователю
остается описать только ту
часть проекта, где принимаются общие решения по управлению на уровне: “автомат
1 включить”, “вентиль 5 закрыть” и т.п. Отметим, что, по нашему многолетнему
опыту проектирования систем, именно разработка и отладка программ управления
типовыми объектами составляет до 70-80 процентов общих трудозатрат на разработку
проекта.

В свою очередь, и сами задачи управления, как правило, могут быть сведены к тому
или иному типовому алгоритму решения. Эти типовые алгоритмы оформляются в виде
блок-схем и включаются в “библиотеку типовых проектных решений”. Проектировщик
выбирает типовое решение, наиболее соответствующее его конкретной задаче и, внеся
в него некоторые изменения и дополнения, включает в свой проект. В идеале весь
процесс проектирования может быть сведен к выбору типовых программных блоков
и типовых проектных решений, которые
лишь привязываются к конкретным входам/выходам контроллера. Это может на порядок
сократить затраты на проектирование.

Последний пункт реализуется за счет правильного распределения функций между аппаратной
и программной частями системы. Если проектировать аппаратную часть не в погоне
за абстрактными наносекундами и гигабайтами, а под конкретную программную среду,
то при этом аппаратные средства упрощаются настолько, что вполне могут быть реализованы
отечественными производителями. Уступая западным аналогам в некоторых абстрактных
тестах на производительность они ни сколько не уступят им при реализации конкретных
задач управления,
а по главному тесту: “каждая задача должна быть решена с минимальными суммарными
затратами”, могут даже и значительно превзойти их. 

3. АППАРАТНЫЕ СРЕДСТВА СИСТЕМЫ “РАПС”

В системе проводится четкое разделение функций между отдельными вычислительными
устройствами. Основной принцип идеологии построения системы: одно устройство
– одна функция (один процесс). 

Любая типовая система управления в том или ином объеме реализует три основных
функции: управление в реальном масштабе времени, отображение текущего состояния
процесса и связь с обслуживающим персоналом, а так же сохранение и документирование
истории функционирования системы и объекта управления. В соответствии с этим
средства системы “РАПС” можно условно разделить на следующие категорий: контроллеры,
пульты управления и серверы баз данных (сетевые узлы).            

Типовой Контроллер – состоит из одноплатной микроЭВМ (РАПС-машины) и набора ФМ,
которые смонтированы на одной платформе. Он устанавливается непосредственно на
объекте управления, и реализует предписанный ему алгоритм управления, снимая
информацию с датчиков, выдавая управляющие воздействия на исполнительные устройства
и взаимодействуя с другими контроллерами пультами управления и серверами по каналам
связи.         

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

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

Если попытаться совместить все эти функции в одном вычислительном устройстве,
то возникает необходимость в специальном программном обеспечении. Так появились
многочисленные SCADA-системы, каждая из которых состоит из трех основных частей:
система сбора данных и управления, системы визуализации и связи с оператором
и системы накопления данных (тренды, алармы и пр.). Однако на сегодняшний день
существуют стандартные де-факто программные средства наилучшим образом решающие
две из трех перечисленных выше задач.
Имеется в виду Delfi, Builder и Kylix в качестве средств разработки пультов управления,
реализованных на базе рабочих станций и промышленных компьютеров, и хорошо взаимодействующие
с ними SQL-серверы как средства реализации сетевых баз данных. 

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


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

3.1 РАПС-КОНТРОЛЛЕРЫ

Четыре основных компонента составляют аппаратную часть контроллеров:

Рапс-машины 
Функциональные модули (ФМ) и интеллектуальные датчики (ИД); 
платформы; 
средства связи. 
В самом общем виде конкретная аппаратная реализация вычислительной системы управления
реального времени, построенной на базе “системы РАПС”, представляет собой совокупность
Рапс-машин и функциональных модулей, смонтированных на платформах различной конфигурации,
и объединенных средствами связи в распределенную сетевую структуру, выполняющую
единую задачу управления и обработки информации в реальном масштабе времени.

3.1.1. РАПС-МАШИНЫ

В основу построения системы положено понятие “виртуальной Рапс-машины”, т.е.
машины, функциональные свойства которой не зависят от ее аппаратной реализации.


По аналогии с классической вычислительной машиной, РАПС-машина имеет:

- память для хранения данных и память алгоритма, в которую загружается аппаратно-независимый
“шитый код”; 

- собственную систему команд, роль которой исполняет, реализованный в кодах конкретного
вычислительного устройства, базовый набор функций (слов ядра РАПС-машины в терминах
системы); 

аналогом центрального процессора можно считать интерпретатор “шитого кода”. 
РАПС-машина является специализированным вычислительным устройством. Она предназначена
конкретно для реализации алгоритмов управления в реальном масштабе времени (РАПС-процессов).
В основу ее функционирования заложен самый понятный специалистам в области управления
вариант реализации подобных алгоритмов – принцип квантования по времени. Процесс
управления разбивается на последовательные шаги – кванты, в каждом из которых
реализуется один цикл управления, состоящий из следующих шагов:

сбор информации о текущем состоянии объекта управления и прием сигналов от органов
управления и других РАПС-машин;

анализ полученной информации и принятие решения о приведении объекта в соответствие
с требованиями управления;

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

Этот цикл называется “основным циклом монитора РАПС-машины”. В начале каждого
цикла производится прием информации от модулей ввода/вывода и из буферов каналов
связи, после чего монитор передает управление интерпретатору “шитого кода” реализующему
пользовательский алгоритм управления, который может быть разбит на ряд (до 16)
независимых фрагментов. Это позволяет гибко изменять его в процессе управления
и легко добавлять новые фрагменты, даже не прерывая работы контроллера (развивающаяся
система).

РАПС-машина использует некоторые аппаратные ресурсы, такие как таймер и каналы
ввода/вывода, того вычислительного устройства (ВУ), на котором она устанавливается.


В принципе, РАПС-машина может быть реализована (установлена) на любом вычислительном
устройстве, которое предоставляет требуемые аппаратные ресурсы, необходимый объем
памяти, а так же возможность хранения, загрузки и интерпретации шитого кода.
В качестве Рапс-машин могут использоваться как ПЭВМ, так и любые одноплатные
микроЭВМ, отвечающие приведенным выше требованиям. Принцип виртуальности выражается
в том, что с точки зрения реализации алгоритмов управления совершенно не важно,
на каком В.У. будет установлена
Рапс-машина, т.к. любое из них, имеющее нужный интерфейсный блок и необходимое
быстродействие, будет взаимодействовать с подключенными к нему ФМ и другими РАПС-машинами
одинаково. 

Это предоставляет самые широкие возможности по отладке систем. Аппаратные средства
системы спроектированы таким образом, что к внутренней шине платформ через стандартные
устройства ввода/вывода и переходные платы может быть подключена ПЭВМ, выполняющая
функции эмулятора центральной РАПС-машины контроллера. При этом разработчику
предоставляются развитые средства диагностики и отладки ПО. По мере отладки системы
эти ПЭВМ заменяются на штатные РАПС-машины.

 

2.2. ФУНКЦИОНАЛЬНЫЕ МОДУЛИ

Входящие в состав системы контроллеры строятся по блочно-модульному принципу
и состоят из вычислителя (центральной РАПС-машины) и набора функциональных модулей,
каждый из которых представляет собой частный случай РАПС-машины и выполняет определенные
(заранее оговоренные) функции по измерению, контролю, управлению или передаче
информации. С одной стороны такой модуль может быть подключен, как и обычная
РАПС-машина, к сетевому фрагменту, реализующему внутриблочный интерфейс, а с
другой – к датчикам и исполнительным
устройствам.

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

Отличие ФМ от обычной РАПС-машины заключается в том, что реализованный в нем
алгоритм обработки информации закладывается на этапе проектирования модуля и
не может быть изменен в процессе эксплуатации путем загрузки в него нового РАПС-процеса
(за исключением быстрых каналов). ФМ имеет заранее оговоренный набор программных
разъемов и может выполнять набор заранее оговоренных команд по управлению свойствами
входов/выходов.

ФМ может быть выполнен в виде обычного модуля ввода/вывода (МВВы) или в виде
интеллектуального датчика (ИД). Различие между ними - в конструктивном исполнении.


МВВы устанавливается на одной платформе с центральной РАПС-машиной и подключается
к датчикам и исполнительным устройствам непосредственно через контакты платформы.

Интеллектуальный датчик является вариантом функционального модуля, подключаемого
к обычному сетевому фрагменту, что позволяет удалять его от платформы контроллера
на расстояние до нескольких сот метров. При этом в позицию МВВы на платформе
устанавливается РАПС-машина, осуществляющая опрос ИД. 

Разница заключается в скорости опроса ФМ. Для МВВы, устанавливаемых на платформе,
она значительно выше.

 

2.3 ПЛАТФОРМЫ

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

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

2.4.     СРЕДСТВА СВЯЗИ “РАПС”

Средства связи (среда передачи данных) предназначены для объединения аппаратных
компонентов в единые вычислительные системы различной структуры, состоящие из
контроллеров, пультов управления и серверов. Как показал опыт, идеология построения
глобальных сетей, специально разработанная для передачи значительных массивов
информации по большим сетям, плохо подходит для реализации систем управления
реального времени, в которых происходит интенсивный обмен короткими сообщениями
с обязательным требованием гарантированной
доставки за короткие промежутки времени. Приводимые в некоторых публикациях цифры
реальной пропускной способности промышленных сетей в 7-11 процентов от максимальной,
хорошо согласуется и с собственным опытом авторов. 

Поэтому в системе РАПС среда передачи данных разделена на два уровня: сильносвязанный
и слабосвязанный. На первом уровне предлагается использовать для обмена данными
простейшие сетевые фрагменты на базе обычных последовательных каналов связи (пропускная
способность которых на сегодняшний день может быть доведена до 1мбод и более)
и внутриблочных интерфейсов. Каждый такой сегмент может объединять до 16 РАПС-машин
и ФМ. Одна, из машин является активным абонентом и управляет процессом обмена
информацией в данном
сетевом фрагменте, а остальные представляют собой пассивных абонентов. Каждая
РАПС-машина имеет 2 линии связи. Это позволяет подключать ее одновременно к двум
сетевым фрагментам, в каждом из которых она может выступать как активный или
пассивный абонент. В пределах одной платформы может быть объединено до 9 РАПС-машин,
что позволяет подключить к ней от 9 до 32 сетевых сегментов. При этом можно создавать
произвольную среду передачи информации, построенные по принципу связанных деревьев,
что соответствует реальной
структуре большинства систем управления. Если внимательно присмотреться к такому
варианту реализации среды передачи данных, то нетрудно увидеть ее подобие со
структурой мозга, состоящей из нейронных слоев, в которых каждый нейрон (в нашем
случае –РАПС-процесс) имеет многочисленные связи с другими нейронами. Это позволяет
реализовывать на них алгоритмы отличные от общепринятых. Например, алгоритмы
распознавания образов. Реальная пропускная способность такой среды передачи данных
намного выше любой традиционной
сети при том, что реализована она может быть с помощью очень простых аппаратных
средств. 

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

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

3. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ “РАПС”

С точки зрения разработчика, программное обеспечение любой вычислительной системы,
реализованной средствами “РАПС”, представляет собой множество взаимодействующих
между собой Рапс-процессов, установленных на множестве аппаратных средств (Рапс-машин),
объединенных в единую вычислительную систему с помощью распределенной среды передачи
информации. 

Можно выделить несколько уровней ПО, реализующего Рапс-процессы: 

Монитор РАПС-процесса, включающий: ядро реального времени с поддержкой подсистемы
переменных-таймеров, подсистему ввода/вывода, обслуживающую каналы связи, командный
интерфейс, администратор главного цикла монитора, интерпретатор шитого кода и
базовый набор слов Форт-подобного языка. 
Пользовательская оболочка - набор слов Форт-подобного языка, представленных в
виде аппаратно-независимого “шитого кода”, реализующий конкретные алгоритмы управления
и обработки информации. Эти слова определяются непосредственно пользователем
или выбираются из базы типовых программных элементов и типовых проектных решений
и включаются, по мере их отладки, в словарь рабочей программы. 
Реализованная на ПЭВМ система автоматизированного проектирования РАПС-процессов
(хост-машина). 
3.1.     РАПС-ПРОЦЕССЫ

Каждый Рапс-процесс (РП) представляет собой законченную и готовую к исполнению
программу оформленную в виде аппаратно-независимого шитого кода. Эта программа
может быть загружена в память любой Рапс-машины, включенной в состав аппаратных
средств “РАПС”. 

РП получает исходную информацию, необходимую для функционирования заложенных
в него алгоритмов управления по каналам связи от функциональных модулей и других
РАПС-процессов. Пользователь освобожден от необходимости подробно описывать процесс
ввода/вывода. Он исходит из того, что на момент запуска очередного цикла Монитора
вся необходимая информация уже находится во внутренней памяти РАПС-машины в указанных
им ячейках, а в конце этого цикла информация из указанных им ячеек памяти будет
передана в другие РАПС-процессы.
Это делает РАПС-процесс полностью независимым от аппаратной реализации РАПС-машины.
В самом РАПС-процессе содержаться только “таблицы описания программных разъемов”
указывающие, в какие ячейки внутренней памяти необходимо поместить информацию,
поступающую во входные буферы Монитора, и из каких ячеек памяти взять информацию,
необходимую для заполнения выходных буферов. 

4.1.2.   ЛОГИЧЕСКИЕ КАНАЛЫ СВЯЗИ.

            Типовая РАПС-машина имеет  физические линии связи (верхнего и нижнего
уровней). К каждой их них подключен сетевой сегмент. 

В пределах каждой РАПС-машины с одной физической линией может быть связано несколько
логических каналов связи. Все, установленные в системе, РАПС-процессы взаимодействуют
между собой через эти логические каналы связи. С каждым логическим каналом связана
определенная дисциплина обслуживания (набор правил обмена данными) которая указывается
в таблице настройки канала. Основными дисциплинами являются: “программный разъем”,
“командный интерфейс” и “транзитный канал”.

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

Данные из входного разъема автоматически переносятся в память РП, после того,
как он был полностью принят драйвером канала и его КС совпала. Данные из памяти
ФП автоматически переносятся в выходной буфер логического канала после того,
как из него были считаны все байты предыдущей копии. 

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

“транзитный канал” позволяет устанавливать соединения между РАПС-машинами принадлежащими
различным сегментам связи (осуществлять маршрутизацию сообшений). 

 

4. СИСТЕМА АВТОМАТИЗИРОВАННОГО ПРЕКТИРОВАНИЯ РАПС-ПРОЦЕССОВ КОНТРОЛЛЕРОВ.

САПР представляет собой систему графического проектирования. Она рассчитана на
непрофессиональных пользователей различной квалификации, поэтому не предусматривает
обязательного владения каким-либо языком программирования. 

При описании ввода/вывода пользователь непосредственно указывает путь от входного
контакта датчика или выходного контакта исполнительного устройства до ячейки
памяти РАПС-машины в которой хранится текущее значение этого контакта и присваивает
ему логическое имя, что практически исключает ошибки. Точно также, для каналов
имеющих дисциплину обслуживания "программный разъем", он просто указывает связь
между ячейками памяти и ячейками входных и выходных буферов каналов связи с другими
РАПС-процессами (заполняя
соответствующие таблицы). Для "командного интерфейса" пользователь, путем заполнения
специальной таблицы, может поставить в соответствие каждой поступающей команде
программу, обсуживающую данную команду.

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

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

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


БЛОК-СХЕМА является самым распространенным и традиционным способом наглядного
представления алгоритма функционирования программы. В самом общем виде блок-схема
это набор блоков (программных элементов), связанных между собой соединительными
линиями, описывающий логику выполнения фрагмента программного проекта. Следует
выделить 2 типа блоков: исполняемый блок и блок условного перехода. 

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

Блок условного перехода позволяет изменять линейную логику выполнения исполняемых
блоков. Общая логика работы блока условного перехода описывается языковой конструкцией:
Если <выполняется логическое условие>, То <перейти к исполнению блока №Х>, Иначе
<перейти к исполнению блока №Y>. Каждый такой блок содержит программу вычисления
логической формулы, результатом вычисления могут быть значения "истина" или "ложь".
Сам блок имеет соответственно 1 вход и 2 выхода (по значению "истина" и по значению
"ложь" соответственно).
Выход по значению "истина" всегда направлен вниз, а по значению "ложь" - вправо.


Блок-схема наглядно представляет общую логику работы алгоритма но не является
конечным окном в том смысле, что не описывает конкретных действий, поэтому с
каждым блоком, в свою очередь, должно быть связано новое языковое окно, или цепочка
таких окон, которые раскрывают предписываемые данному блоку программные функции.
Выбор языкового окна для описания исполняемого блока является произвольным. Языковое
окно блока условного перехода должно описывать логическую функцию и оставлять
на стеке данных единственное
значение - "истина" или "ложь". Для входа в окно достаточно нажать кнопку "Enter"
при маркере установленном над любым из блоков. Если данный блок открывается впервые,
то будет высвечен экран выбора языкового окна. 

Граф-переходов. Многие объекты автоматизации могут быть представлены как автомат,
который характеризуется конечным числом состояний в которых он может устойчиво
находиться и конечным множеством условий переходов из одного состояния в другое.
Каждому состоянию автомата соответствует набор выходных и внутренних логических
переменных и действий. С каждым условием перехода связан определенный набор входных
и внутренних переменных, делающих его истинным. В каждый момент времени автомат
находится в одном из состояний,
называемом активным, из которого он может перейти в одно или несколько других
состояний, связанных с данным условными переходами. Как только одно из условий
становится истинным, автомат переходит в новое состояние и остается в нем до
тех пор, пока одно из условий перехода, из этого состояния в свою очередь не
станет истинным и т.д.

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

ЯЗЫК ФОРМУЛ. Описание алгоритма функционирования Рапс-процесса в терминах языка
формул представляет собой набор выражений двух типов: ЕСЛИ <набор условий> ТО
<набор действий>; ЕСЛИ <набор условий> ТО <набор действий> ИНАЧЕ <набор действий>;

В одном языковом окне может содержаться до 256 строк, состоящих из таких выражений.
Одно выражение может занимать несколько строк. Результатом трансляции каждого
<набора условий> является программа оставляющая на стеке логическое значение
"ИСТИНА" или "ЛОЖЬ". Для выражений первого типа программа, являющаяся результатом
трансляции <набора действий>, следующих за словом ТО, выполняется в том случае,
если на вершине стеке лежит значение "ИСТИНА", в противном случае никакие действия
не выполняются. Для выражений
второго типа, в случае, если результатом вычислений является значение "ЛОЖЬ",
выполняется <набор действий>, следующих за словом ИНАЧЕ. Таким образом каждая
формула является аналогом условного оператора IF(выражение) <оператор1> ELSE
<оператор2> являющегося принадлежностью практически любого языка программирования.

Каждый <набор условий> это совокупность логических примитивов, объединенных с
помощью слов “И” и “ИЛИ”, а также открывающих "(" и закрывающих ")" скобок, в
логические формулы, правила написания которых не отличаются от общепринятых в
математике. В качестве логических примитивов могут, в принципе, выступать любые
слова Рапс-процесса, оставляющие на стеке значения "ИСТИНА" или "ЛОЖЬ", а также
любые элементарные выражения имеющие логический результат. В корректно составленной
логической формуле используются:

- имена входных логических сигналов и внутренних логических переменных;

- выражения вида слово1 слово2 <логический оператор>.

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

Предлагаемая версия “языка формул” способна оперировать с объектами многозначной
логики. Любая дискретная система состоит из набора взаимодействующих между собой
объектов, каждый из которых может находиться в одном из конечного набора возможных
состояний. Таким образом, с каждой логической переменной, обозначающей объект,
связывается конечный набор значений – состояний. Например: объект “задвижка”
может находиться в одном из следующих состояний: “закрыта”, “открывается”, “открыта”,
“закрывается”, “неможетбыть_открыта”
и “неможетбыть_закрыта”. В языке формул допускаются условные выражения типа:
ЕСЛИ задвижка_N1 открыта ТО…

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

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

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

В процессе функционирования системы управления над этими элементами должны совершаться
определенные действия: двигатели и насосы запускаются и останавливаются, контакторы
замыкаются и размыкаются, задвижки открываются и закрываются и т.д. Решения об
этих действиях принимаются программами реализации алгоритмов управления узлами
и агрегатами объекта автоматизации формирующими сигналы на запуск и остановку
двигателей и насосов, открытие и закрытие задвижек и т.п. Эти сигналы поступают
на соответствующие входы
типовых программных элементов, а сами алгоритмы управления могут быть оформлены
в виде библиотеки типовых проектных решений с разной степенью детализации выполняемых
функций.

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

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